اگر امروز یک دموی خیرهکننده از عامل هوش مصنوعی خود را به مشتری نمایش میدهید، احتمالاً در تلهای افتادهاید که شکست ریاضی آن قطعی است. باید بدانید تفاوت میان یک «مسیر سبز» (Happy Path) که همه چیز در آن درست میگذرد و یک محیط عملیاتی واقعی، همان تفاوت میان یک آزمایشگاه استریل و دنیای پرهرجومرج است. در دنیای واقعی، ورودیهای نامیزان و زنجیرههای طولانیتر باعث تخریب قابلیت اطمینان میشوند، زیرا احتمال خطا به صورت تجمعی افزایش مییابد.
این شکاف عملکردی، سدی حیاتی برای شرکتهایی است که میخواهند از نمونههای اولیه به سمت جذب کاربر واقعی حرکت کنند. برای یک توسعهدهنده، مشکل این نیست که مدل «خراب» است، بلکه معماری سیستم فاقد سختگیریهای مهندسی نرمافزارهای سنتی است. این وضعیت شبیه به یک خط تولید دیجیتال است که کوچکترین کجی در ابتدای مسیر، محصولی میسازد که در ظاهر درست است اما در نهایت بنیاداً معیوب است.
همانطور که در تحلیلهای پیشین ما دربارهی پایداری مدلهای زبانی اشاره کردیم، اتکا به خروجیهای تصادفی بدون لایهی کنترل، ریسک سیستم را بهشدت بالا میبرد.
ریاضیات شکستهای تجمعی
به نقل از گزارشی که در ۲۳ ژوئن ۲۰۲۶ توسط Shanti Infosoft منتشر شد، ریاضیاتِ قابلیت اطمینان در عاملها بسیار بیرحم است. شکاف میان دمو و تولید، اساساً یک مسئله حساب ساده است.
اگر هر گام در گردش کار یک عامل (Agent) — سیستمی که میتواند هدف را بفهمد و برای رسیدن به آن برنامهریزی کند — ۹۵ درصد قابل اطمینان باشد، یک زنجیره ۱۰ مرحلهای (که استاندارد سال ۲۰۲۶ است) تنها ۶۰ درصد نرخ موفقیت کلی خواهد داشت (۰.۹۵ ^ ۱۰). اگر این زنجیره به ۲۰ مرحله برسد، نرخ موفقیت به ۳۶ درصد سقوط میکند.
در سناریوهای واقعی با ورودیهای نامیزان، حتی فرض موفقیت ۹۵ درصدی در هر گام، بیش از حد خوشبینانه است. نرخ خطای هر مرحله اغلب بین ۱۰ تا ۲۰ درصد است. اگر اعداد را بر اساس نرخ موفقیت ۸۵ درصد برای یک زنجیره ۸ مرحلهای محاسبه کنیم، نتیجه تقریباً ۰.۲۷ است. این بدان معناست که تقریباً سه مورد از هر چهار اجرای سیستم در نقطهای از مسیر شکست میخورند. این شکستِ مدل نیست، بلکه اثر احتمالات تجمعی است که دقیقاً همان کاری را میکند که از نظر ریاضی باید بکند.
چرا دموها دروغ میگویند؟
یک دمو واقعیتهای سخت را کاملاً پنهان میکند. دمو تنها یک مسیر موفق است: یک ورودی پاک، یک زنجیره کوتاه، نبود محدودیت نرخ درخواست (Rate Limit) و دادههای بدون ابهام. در بسیاری از موارد، دمو نتیجه پنج بار اجرای یک فرآیند است تا یک بار خروجی مناسب برای ضبط ویدیو بهدست بیاید.
اما محیط عملیاتی متفاوت است. اینجا صدها کاربر دادههایی «زباله» به سیستم میدهند که توسعهدهنده هرگز تصورشان را نمیکرد. علاوه بر این، زنجیرهها اغلب طولانیتر از آن چیزی هستند که به نظر میرسند؛ هر اکشن ساده مثل «فراخوانی ابزار و تحلیل نتیجه»، در واقع سه یا چهار گام زیرپوستی است که هر کدام شانس شکست خود را دارند.
کالبدشکافی پسرویهای خاموش
شکستها در این سیستمها بهندرت بهصورت «کرش» یا توقف کامل ظاهر میشوند؛ در عوض ما با «پسرویهای خاموش» (Silent Regressions) روبهرو هستیم. شکست تجمعی بهصورت یک کرش دیده نمیشود زیرا هر گام بهتنهایی در انزو، منطقی به نظر میرسد.
مثلاً در گام سوم، مدل یک فیلد را کمی اشتباه میخواند، اما خروجی همچنان یک JSON سالم و با ساختار درست است. این خروجی به گام چهارم میرود و مدل با اطمینان کامل بر اساس یک متن فاسد استدلال میکند. گامهای ۵ تا ۸ روی این خطا بنا میشوند. پاسخ نهایی غلط است اما ظاهر متقاعدکنندهای دارد و هیچ اثر خطایی (Stack Trace) وجود ندارد که شما را به گام سوم بازگرداند.
یافتن این خطا نیازمند ردیابی دستی کل زنجیره علی است، آن هم معمولاً زمانی که مشتری اسکرینشاتی از یک اشتباه شرمآور میفرستد. چون مدل صرفاً آنچه را که به او تحویل داده شده منتشر کرده است، تشخیص رایج «مدل توهم (Hallucination) زده است» — یعنی وقتی مدل با اطمینان چیزی میگوید که وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند — در اینجا غلط است. مشکل واقعی، نبود نقاط بازرسی یا گیتهای اعتبارسنجی برای متوقف کردن انحراف (Drift) پیش از مسموم کردن گامهای پاییندستی است.
بحران کیفیت زمینه
شرکت Shanti Infosoft یک «قاتل خاموش» دیگر را شناسایی کرده است: کیفیت زمینه. بسیاری از توسعهدهندگان با شنیدن عبارت «پنجره زمینه (Context Window) ۲۰۰ هزار توکنی» — که مثل میز کاری است که جا برای چند ورق دارد، نه کل کتابخانه — تصور میکنند ۲۰۰ هزار توکن حافظه فعال در اختیار دارند.
در عمل، عاملها بسیار پیش از رسیدن به این حد، رشته کلام را گم میکنند. دستورالعملهای قدیمی زیر خروجیهای ابزارها و زبالههای میانی دفن میشوند. اندازه زمینه یک عامل پرت است؛ کیفیت زمینه است که محدودیت واقعی را تعیین میکند. ۸ هزار توکن مرتبط و دقیق، همیشه بر ۸۰ هزار توکن پر از نویز پیروز میشود.
گذار به مهندسی سیستمها
برای حل این مسائل، این شرکت توصیه میکند از نگاه «تولید پرامپت» فاصله بگیرید و با عاملها مانند سیستمهای توزیعشده برخورد کنید. این یعنی اعمال انضباط مهندسی خشکِ سیستمهای توزیعشده روی یک کارگر غیرقطعی (Non-deterministic). چارچوب پیشنهادی آنها شامل موارد زیر است:
- نقطه بازرسی وضعیت خارجی: وضعیت (State) را بهجای حافظه گفتگو، در یک ذخیرهساز اختصاصی نگه دارید. وضعیت باید در یک Store باشد، نه در جریان گفتگو. این کار اجازه میدهد فرآیندی که در گام ۶ میمیرد، دقیقاً از همانجا ادامه یابد، نه اینکه کل زنجیره تکرار شود و هزینه توکنها دو بار پرداخت گردد.
- اعتبارسنجی مرزی: برای هر ورودی و خروجی ابزار، اعتبارسنجی سختگیرانه (مانند Pydantic) پیاده کنید. هر تعامل باید با یک قرارداد، یک طرحواره (Schema) یا یک ادعانامه (Assertion) چک شود (مثلاً اطمینان از اینکه یک عدد در محدوده مجاز است). این کار باعث میشود خروجی فاسد گام ۳، بهجای اینکه در گام ۸ تبدیل به یک معمای پیچیده شود، همان لحظه بهعنوان یک خطای قابل بازیابی شناسایی شود.
- اثرات جانبی Idempotent: چون تکرار در سیستمهای غیرقطعی اجتنابناپذیر است، یک گام ممکن است دو بار اجرا شود. برای کارهای حساس مثل کسر وجه از کارت یا ارسال ایمیل، از کلیدهای Idempotency استفاده کنید تا تکرار درخواست باعث اجرای چندباره عملیات نشود. چون یک پرامپت یکسان میتواند پاسخهای متفاوتی بدهد، ویژگی Idempotency باید در لایه اثر جانبی (Side Effect) باشد، نه در فراخوانی مدل.
- ارزیابیهای یکپارچه با CI: تغییرات پرامپت را مانند رگرسیون کد مدیریت کنید. اصلاح یک پرامپت برای حل یک مورد خاص، ممکن است بهطور خاموش پنج مورد دیگر را خراب کند. از مجموعهای از تستهای واقعی در خط لولهی CI استفاده کنید تا این پسرویهای خاموش که بازبینیهای دستی آنها را نمیبینند، شکار شوند.
این چرخش به معنای آن است که بخش بزرگی از توسعه در Shanti Infosoft دیگر «کلنجار رفتن با مدل» نیست، بلکه مهندسی خشک و بیزرقوبرق است: مدیریت خطا، مشاهدهپذیری و کنترل وضعیت.
برای کسانی که با دموی لرزانی در محیط عملیاتی دستوپنجه نرم میکنند، راهکار مدل بزرگتر نیست. اولین قدم این است که یک ردیاب (Trace) باز کنید، نقطهی دقیق انحراف زنجیره را بیابید و یک گیت اعتبارسنجی برای مهار آن قرار دهید. در نه از ده مورد، مشکل نبود هوش نیست؛ مشکل این است که یک «مسیر سبز» ساخته شده و به اشتباه آن را یک «سیستم» نامیدهاند.
گام بعدی شما
- به جای افزایش طول پرامپت، یک لایه اعتبارسنجی سختگیرانه برای خروجی هر ابزار (Tool) تعریف کنید.
- وضعیت عامل خود را از تاریخچه گفتگو جدا کرده و در یک پایگاه داده یا Cache خارجی ذخیره کنید.
- یک مجموعه تست (Eval Set) از ورودیهای «زباله» و نامیزان بسازید و آن را در هر تغییر پرامپت اجرا کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو