فین‌تیون کردن مدل خود را متوقف کنید. مشکل از معماری شماست.

دموها عالی به نظر می‌رسند. سیستم‌های عملیاتی متفاوت هستند. شکافی بین این دو وجود دارد.

امروزه مردم هر چیزی را عامل (agent) می‌نامند. یک چت‌بات با حافظه، یک عامل است. یک اسکریپت با یک حلقه، یک عامل است. این اشتباه باعث بروز خطاهای مهندسی می‌شود. در نهایت، شما کارهای ساده را بیش از حد پیچیده (over-engineering) و کارهای پیچیده را بیش از حد ساده (under-engineering) طراحی می‌کنید.

یک عامل به یک هدف نیاز دارد. او فقط از یک دستور پیروی نمی‌کند، بلکه تصمیم می‌گیرد که مرحله بعد چه کاری انجام دهد. او با شکست‌ها مقابله می‌کند و می‌داند چه زمانی باید متوقف شود.

از این قوانین برای بررسی سیستم خود استفاده کنید:

  • اگر یک انسان باید هر مرحله را هدایت کند، این یک رابط چت است.
  • اگر سیستم از یک فراخوانی ابزار (tool call) ناموفق بازیابی شود، یک عامل است.
  • اگر یک هدف را به زیروظایف تقسیم کند، یک عامل واقعی است.

تیم‌های موفق به دنبال مدل‌های جدید نمی‌دوند. آن‌ها خط‌لوله‌های (pipelines) محدود و هدفمند می‌سازند. آن‌ها بر این سه مورد تمرکز می‌کنند:

  • طراحی ابزار: رابط کاربری چقدر تمیز است؟
  • مدیریت شکست: وقتی یک ابزار هیچ نتیجه‌ای بر نمی‌گرداند، چه اتفاقی می‌افتد؟
  • مشاهده‌پذیری (Observability): آیا می‌توانید هر تصمیم را ردیابی کنید؟

فریم‌ورکی که استفاده می‌کنید اهمیت کمتری نسبت به الگوهای شما دارد. من معماری‌ها را در فریم‌ورک‌های مختلف بازسازی کرده‌ام و نتایج همیشه یکسان است. فریم‌ورک مانند داربست است؛ معماری، خودِ ساختمان است.

این الگوها را دنبال کنید:

  • ابتدا برنامه‌ریزی کنید، سپس اجرا کنید. از یک مرحله برای استدلال (reasoning) و یک مرحله مجزا برای اقدام (action) استفاده کنید.
  • بازیابی (retrieval) را از استدلال جدا کنید. واکشی بافتار (context) و استفاده از آن، دو وظیفه متفاوت هستند.
  • از تحویل‌های صریح (explicit handoffs) استفاده کنید. وقتی یک عامل کار را به عامل دیگری می‌سپارد، از لاگ‌های ساختاریافته استفاده کنید.

RAG یک استاندارد است، اما تکه‌تکه کردن (chunking) اغلب اشتباه انجام می‌شود. اگر اسناد را به درستی تقسیم نکنید، مدل بافتار (context) را از دست می‌دهد. این امر باعث توهم (hallucinations) می‌شود.

اگر خط‌لوله RAG شما نتایج بی‌فایده‌ای برمی‌گرداند، به تکه‌تکه کردن و متاداده‌های خود نگاه کنید. مدل جاسازی (embedding model) را مقصر ندانید.

چالش مهندسی، ساختن سیستم‌هایی است که بتوان به آن‌ها اعتماد کرد. بر حاکمیت (governance)، مشاهده‌پذیری و استفاده قابل اعتماد از ابزارها تمرکز کنید. فقط به دنبال بنچمارک‌ها نباشید.

بهترین مهندسان بر طراحی سیستم تمرکز خواهند کرد. آن‌ها سیستم‌های هوش مصنوعی‌ای می‌سازند که دیگران بتوانند آن‌ها را نگهداری کرده و به آن‌ها اعتماد کنند.

Source: https://dev.to/aibughunter/stop-fine-tuning-your-model-your-architecture-is-the-problem-3kkg