آنچه از اجرای عاملهای هوش مصنوعی در محیط عملیاتی آموختم
من سیستمهای هوش مصنوعی میسازم. با مهندسانی که کد را به مرحله عرضه میرسانند صحبت میکنم. شکافی میان دموهای پرزرقوبرق و سیستمهای واقعی عملیاتی وجود دارد.
امروزه مردم هر چیزی را «عامل» (agent) مینامند. یک اسکریپت با یک حلقه، یک عامل است. یک چتبات با حافظه، یک عامل است. این اشتباه منجر به مهندسی ضعیف میشود.
تیمها وظایف ساده را بیش از حد پیچیده میکنند (over-engineer). آنها مدیریت هماهنگی (orchestration) پیچیدهای را به جریانهای کاری اضافه میکنند که تنها به یک پرامپت خوب نیاز دارند.
یک عامل باید هدف داشته باشد، نه فقط یک دستورالعمل. باید تصمیم بگیرد که قدم بعدی چیست. باید بتواند خطاها را مدیریت کند. باید بداند چه زمانی کارش تمام شده است.
هر چیز دیگری صرفاً یک فراخوانی تابع (function call) است.
• اگر یک انسان مجبور باشد هر مرحله را هدایت کند، آن یک رابط چت است. • اگر سیستمی از یک فراخوانی ابزارِ شکستخورده بازیابی شود، آن یک عامل است. • اگر سیستمی یک هدف را به زیروظایف تقسیم کند، آن یک عامل واقعی است.
استقرار واقعی عاملها محدود و تخصصی است. آنها یک کار را به خوبی انجام میدهند، مانند استخراج اسناد یا بازبینی کد. آنها موتورهای استدلال عمومی نیستند.
تیمهای موفق بر سه مورد تمرکز میکنند:
- طراحی ابزار: رابطهای تمیز برای آنچه عامل فراخوانی میکند.
- مدیریت خطا: وقتی یک ابزار هیچ خروجیای برنمیگرداند، چه اتفاقی میافتد.
- مشاهدهپذیری (Observability): ردیابی اینکه چرا یک عامل تصمیم خاصی گرفته است.
فریمورکهایی مانند LangChain یا CrewAI هر ماه تغییر میکنند. فریمورک اهمیت کمتری نسبت به الگوها (patterns) دارد.
برای موفقیت از این الگوها استفاده کنید:
- برنامهریزی و سپس اجرا: از یک مرحله برای برنامهریزی و یک مرحله مجزا برای اجرا استفاده کنید.
- جداسازی بازیابی از استدلال: واکشی متن (fetching context) و استفاده از آن، دو وظیفه متفاوت هستند.
- تحویل صریح: وقتی یک عامل کار را به عامل دیگری میسپارد، از لاگهای ساختاریافته استفاده کنید.
RAG یک استاندارد است، اما اکثر افراد در مرحله تکهبندی (chunking) شکست میخورند. اگر متن را به درستی تقسیم نکنید، مدل بافتار (context) را از دست میدهد. اگر نتایج RAG شما بیفایده است، قبل از سرزنش کردن مدل، متادیتا و استراتژی تکهبندی خود را بررسی کنید.
مدلها بهتر و ارزانتر خواهند شد. این موضوع چالش اصلی مهندسی را تغییر نمیدهد. شما باید سیستمهایی بسازید که وقتی نظارتی بر آنها نیست، به درستی رفتار کنند.
بر حاکمیت (governance) و مشاهدهپذیری تمرکز کنید. مهندسانی که اهمیت دارند، کسانی خواهند بود که سیستمهایی میسازند که دیگران بتوانند به آنها اعتماد کنند. این طراحی سیستم است، نه تحقیق روی مدل.
Source: https://dev.to/aibughunter/what-i-learned-after-running-ai-agents-in-production-for-a-year-49n