چرا مهندسی بیش از حد عامل‌ها باعث شکست سیستم‌های RAG می‌شود؟

اگر فکر می‌کنید با جایگزین کردن مدل GPT-4 با نسخه‌ای جدیدتر، پیچیدگی‌های عملیاتی سیستم خود را حل کرده‌اید، احتمالاً در تله‌ی «دموهای درخشان» افتاده‌اید. بسیاری از تیم‌ها هفته‌ها وقت خود را صرف افزودن لایه‌های ارکستراسیون عامل‌محور (Agentic) به گردش‌کارهایی می‌کنند که با یک پرامپت ساختاریافته و ساده، به‌طور کامل اجرا می‌شدند.

این رویکرد منجر به «مهندسی بیش از حد» (Over-engineering) می‌شود؛ جایی که هر اسکریپتی با یک حلقه تکرار، به اشتباه یک «عامل» نامیده می‌شود. این تفرق معنایی، شکافی خطرناک ایجاد می‌کند که در لحظه‌ی انتقال از یک دموی صیقل‌خورده به یک سیستم تولیدی — که باید بدون نظارت انسانی و به‌صورت پیش‌بینی‌پذیر عمل کند — به شکست‌های بحرانی منجر می‌شود. این چالش‌ها دقیقاً همان موانعی هستند که در تحلیل ما پیرامون شکاف میان دمو و واقعیت در محیط‌های عملیاتی مورد بررسی قرار گرفتند.

همان‌طور که در تحلیل قبلی ما درباره‌ی مدل‌های ذهنی فنی برای مدیران محصول اشاره کردیم، صنعت اکنون به دیواری رسیده است که در آن مهندسی پرامپت به پایان می‌رسد و طراحی سیستم آغاز می‌شود. اکثر توسعه‌دهندگان با هوش مصنوعی مانند یک جعبه جادویی برخورد می‌کنند، اما مقیاس‌پذیری مستلزم این است که با آن به‌عنوان یک مؤلفه‌ی شکننده در یک معماری نرم‌افزاری بزرگ‌تر تعامل کنیم.

بحران تعریف عامل

به نقل از گزارشی که در ۱۸ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، یک عامل واقعی با داشتن «هدف» تعریف می‌شود، نه صرفاً «دستورالعمل». یک عامل باید بتواند حرکت بعدی خود را تصمیم بگیرد، شکست‌هایش را مدیریت کند و تشخیص دهد چه زمانی وظیفه به پایان رسیده است.

اگر سیستمی نیاز دارد که انسان هر گام را دیکته کند، آن سیستم یک عامل نیست، بلکه صرفاً یک رابط چت است. ویژگی اصلی یک عامل واقعی، توانایی تجزیه یک هدف سطح‌بالا به زیروظایف کوچک‌تر و تفویض آن‌هاست. علاوه بر این، اگر سیستمی بتواند پس از شکست در فراخوانی یک ابزار، با روشی متفاوت تلاش کند، در مسیر رسیدن به عاملیت واقعی است؛ در غیر این صورت، ما فقط با فراخوانی‌های پیشرفته‌ی توابع طرف هستیم.

در حال حاضر، اکثر استقرارها استدلال‌گرهای عمومی نیستند، بلکه خط لوله‌های (Pipelines) محدود و هدفمندی هستند که معمولاً در سه حوزه برتری دارند:

• دسته‌بندی درخواست‌های پشتیبانی مشتریان
• استخراج داده از اسناد
• بازبینی کد برای پایگاه‌های کد مشخص

واقعیت‌های محیط تولید

تیم‌هایی که به نتایج واقعی در دنیای عملی رسیده‌اند، هایپِ مدل‌های جدید را نادیده گرفته‌اند. در عوض، آن‌ها بر سه ستون مهندسی تمرکز می‌کنند:
۱. طراحی ابزار: ایجاد رابط‌های سخت‌گیرانه و تمیز برای آنچه عامل واقعاً می‌تواند فراخوانی کند.
۲. مدیریت شکست: تعریف دقیق اتفاقاتی که هنگام عدم دریافت داده‌های مفید از یک ابزار رخ می‌دهد.
۳. قابلیت مشاهده (Observability): ساخت ردپاهایی (Traces) برای درک اینکه چرا یک عامل تصمیم خاصی گرفته است.

در مقابل، تیم‌هایی که صرفاً مدل GPT-4 را با یک مدل پیشروتر جایگزین می‌کنند بدون آنکه معماری خود را تغییر دهند، هیچ بهبودی در رفتار سیستم نمی‌بینند. آن‌ها به‌اشتباه انتظار دارند مدل به‌تنهایی رفتار را اصلاح کند و ضرورت تغییرات ساختاری را نادیده می‌گیرند. این رویکرد تأیید می‌کند که طراحی سیستمی به جای تعویض مدل، کلید دستیابی به پایداری در مقیاس است.

زیرساخت و بستر صنعت

در حالی که الگوهای نرم‌افزاری تکامل می‌یابند، زیرساخت‌های فیزیکی هوش مصنوعی با سرعت خیره‌کننده‌ای در حال گسترش هستند. بر اساس بررسی منابع متعدد، تغییرات سرمایه‌ای و پژوهشی عظیمی در پس‌زمینه در حال رخ دادن است:

• مقیاس‌بندی زیرساخت: شرکت Crusoe به‌تازگی ۳.۹ میلیارد دلار برای ساخت مراکز داده عظیم و «کارخانه‌های هوش مصنوعی» ماژولار جذب کرد؛ دور سرمایه‌گذاری‌ای که ارزش این غول مراکز داده را به ۳۰.۹ میلیارد دلار رساند.
• گفتمان AGI: شرکت Google DeepMind مؤسسه‌ای جدید برای گسترش بحث‌های مربوط به هوش مصنوعی عمومی (AGI) راه‌اندازی کرده است تا تفاوت دیدگاه‌های بین گوگل، دیپ‌مایند و جامعه پژوهشی جهانی را برجسته کند.
• کارایی مدل‌ها: بازیگران جدیدی مانند PrismML در حال معرفی «مدل‌های زبانی کوچک» (SLM) هستند که با اولویت دادن به کارایی به‌جای اندازه، قصد دارند نحوه تعامل کاربران با هوش مصنوعی را تغییر دهند.

چارچوب‌ها در برابر الگوها

ابزارهایی مانند LangChain، LangGraph، CrewAI، AutoGen و Semantic Kernel فضای گفتگو را اشغال کرده‌اند، اما این چارچوب‌ها صرفاً داربست هستند. هر ماه چارچوب جدیدی با ادعای مرگ نسخه‌های قبلی ظهور می‌کند، اما الگوهای مورد استفاده بسیار مهم‌تر از خودِ چارچوب هستند.

معماری زیربنایی است که موفقیت را تعیین می‌کند. الگوهای اثبات‌شده‌ای که در تمام چارچوب‌ها جواب می‌دهند عبارتند از:

• برنامه‌ریزی سپس اجرا: جداسازی گام استدلال (ایجاد برنامه) از گام اجرا. ترکیب این دو معمولاً منجر به ناپایداری می‌شود.
• جداسازی بازیابی: متمایز نگه داشتن فرآیند دریافت زمینه (Context) از فرآیند استفاده از آن.
• تحویل ساختاریافته: استفاده از داده‌های ثبت‌شده و ساختاریافته هنگام انتقال کار بین عامل‌ها، به‌جای استفاده از رشته‌های متنی خام.

مسئله حل‌نشده RAG

تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اکنون به یک استاندارد تبدیل شده است، اما اکثر آموزش‌ها مشکل «مرز تکه‌بندی» را نادیده می‌گیرند. وقتی اسناد به تکه‌های کوچک تقسیم و به بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگی آن با کلمات دیگر را می‌گوید — تبدیل می‌شوند، مهندسان فرض می‌کنند کدام قطعات زمینه به هم تعلق دارند؛ فرضی که اغلب غلط است.

وقتی پاراگرافی که فقط در کنار پاراگراف قبلی معنا می‌دهد، به‌تنهایی بازیابی شود، مدل به‌کرات دچار توهم (Hallucination) — یعنی با اطمینان چیزی را می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شود. اگر یک خط لوله RAG نتایجی برگرداند که از نظر فنی درست اما از نظر زمینه‌ای بی‌فایده است، مشکل معمولاً در تکه‌بندی یا متادیتا است، نه در مدل بردار معنایی.

برای حل این مشکل، مهندسان به سمت رویکردهای زیر حرکت می‌کنند:

• پنجره‌های هم‌پوشان و تکه‌بندی معنایی.
• بازیابی سند والد (Parent-document retrieval).
• ذخیره نمایش‌های ساختاریافته از اطلاعات به‌جای متن خام.

چرخش به سمت طراحی سیستم

با گسترش پنجره‌های زمینه و کاهش هزینه استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره آموزش آشپز — چالش بنیادین همچنان «اعتماد» است. باارزش‌ترین مهندسان دو سال آینده، کسانی نخواهند بود که در تنظیم دقیق (Fine-tuning) — مثل تخصص دادن به یک پزشک عمومی در حوزه پوست — یا مهندسی پرامپت استادند، بلکه کسانی هستند که می‌توانند سیستم‌های قابل نگهداری و مشاهده‌ای بسازند که سایر مهندسان بتوانند به آن‌ها اعتماد کنند.

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

گام بعدی شما

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.