تصور کنید مشتری شما در ششمین پیام از شدت عصبانیت گفتگو را قطع می‌کند، در حالی که داشبورد ارزیابی شما نرخ موفقیت ۹۴ درصدی را برای عامل هوش مصنوعی نشان می‌دهد. این شکاف عمیق به این دلیل رخ می‌دهد که اکثر تیم‌ها، عامل‌ها را «پاسخ‌به‌پاسخ» می‌سنجند و یک گفتگو را مجموعه‌ای از نقاط انتهایی مجزا می‌بینند، نه یک جلسه پیوسته.
یک عامل پشتیبانی را در نظر بگیرید که درخواست استرداد وجه را مدیریت می‌کند. در مرحله اول، او درخواست را درست تشخیص می‌دهد. در مرحله چهارم، کاربر تأکید می‌کند که استرداد باید «جزئی» باشد و عامل آن را تأیید می‌کند. اما در مرحله ششم، عامل دوباره مبلغ کل را ذکر می‌کند. چون هر پاسخ به‌تنهایی از نظر ساختاری درست است و بر اساس داده‌ها استدلال شده، ارزیابی‌های تک‌مرحله‌ای هر گام را «موفق» علامت می‌زنند، در حالی که کل جلسه از نظر کاربر شکست خورده است.
نقطه کور ارزیابی‌های تک‌مرحله‌ای
این شکست به این دلیل رخ می‌دهد که خطا در رابطه بین خروجی‌هاست، نه در خودِ یک پاسخ منفرد. عامل ممکن است در هر گام روی موضوع متمرکز باشد و فرمت درستی داشته باشد، اما به‌طور خاموش یکی از محدودیت‌ها را رها کرده یا با وعده قبلی خود تناقض ایجاد کرده است.
به نقل از راهنمای فنی منتشر شده در ۷ اوت ۲۰۲۶ در وب‌سایت dev.to، این «زوال محدودیت‌ها» (Constraint Decay) — در کنار تناقضات درونی و فراموش کردن تعهدات — اصلی‌ترین دلیل شکست عامل‌های چندمرحله‌ای است. نویسنده استدلال می‌کند که واحد شکست باید «جلسه» باشد، نه «پاسخ»، و معماری‌های فعلی به‌طور ساختاری نسبت به این الگوها کور هستند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زبانی اشاره کردیم، تکیه بر معیارهای سطحی می‌تواند منجر به اعتماد کاذب به سیستم‌های پیچیده شود. در همین راستا، بررسی نحوه شناسایی افت کیفیت پرامپت‌ها به عنوان باگ‌های نرم‌افزاری نشان می‌دهد که چگونه نقص‌های کوچک در ورودی‌ها می‌تواند منجر به شکست‌های سیستمی در خروجی شود.
نردبان شواهد: از اثبات تا عقیده
برای حل این مشکل، این راهنما یک «نردبان شواهد» پیشنهاد می‌دهد که سیگنال‌ها را بر اساس محور استقلال (و نه هزینه) رتبه‌بندی می‌کند. هدف این است که از شواهدی که عامل نمی‌تواند جعل کند، به سمت نظراتی حرکت کنیم که با مدل زیرساختی مشترک هستند:
- سطح ۱ (اثبات قطعی): شواهدی که از بیرون قابل مشاهده‌اند و عامل نمی‌تواند آن‌ها را جعل کند. مثال‌ها شامل خروجی JSON معتبر، وجود یک فایل، پاس شدن تست‌ها، اتمام عملیات در بازه زمانی تعیین‌شده (Timeout) یا خروجی‌های غیرخالی است. همچنین شامل تفاوت‌های قطعی (Deterministic Diffs) روی استخراج‌های ساختاریافته است؛ مثلاً بررسی اینکه آیا پاسخ مرحله ۶ با مقداری که در مرحله ۴ متعهد شده بود تناقض دارد یا خیر.
- سطح ۲ (سیگنال آماری): سیگنال‌هایی که در برابر یک خط مبنای خارجی (که توسط خود عامل نوشته نشده) سنجیده می‌شوند. این شامل بردار معنایی (Embedding) برای بررسی شباهت، بررسی‌های تکرار برای تشخیص اینکه آیا عامل در حال لوپ زدن است یا پیشروی در گفتگو، یا بررسی اینکه آیا یک تغییر (Diff) واقعاً چیزی را تغییر داده است یا خیر.
- سطح ۳ (مدل‌به‌مثابه-داور): نظراتی که بر پایه زیرساخت مشترک هستند. این یک سیگنال است، نه حکم نهایی. برای موارد ذهنی و «دم‌های» جلسه (Session Tails) استفاده می‌شود؛ مثلاً اینکه آیا لحن گفتگو در طول یک فرآیند ارجاع به پشتیبانی انسانی (Escalation) مناسب بوده است یا خیر.
بسیاری از تیم‌ها به‌اشتباه ارزیابی جلسه را یک مسئله سطح ۳ می‌بینند و فقط از یک داور می‌پرسند «آیا گفتگو منسجم بود؟». اما بخش بزرگی از شکست‌های جلسه در واقع در سطح ۱ و ۲ هستند. برای مثال، بررسی اینکه آیا یک محدودیت (مانند «پرداخت به یورو» یا «قبل از جمعه») تا خروجی نهایی باقی مانده است، یک بررسی عضویت ساده روی اسلات‌های حل‌شده (Resolved Slots) در سطح ۱ و ۲ است. همچنین شمارش اینکه آیا هر سؤال کاربر پاسخ متناظر دریافت کرده است یا خیر، یک بررسی پوشش (Coverage Check) در سطح ۱ است.
نقش ردیابی (Tracing)
بررسی‌های قطعی جلسه بدون یک ردیابی کامل غیرممکن است؛ شما نمی‌توانید مسیری را که ثبت نکرده‌اید، تحلیل کنید. این بررسی‌ها به ورودی‌های پردازش‌شده، مقادیر متعهد شده و خروجی ابزارها در هر گام نیاز دارند، نه خلاصه‌ای که توسط خود عامل نوشته شده است.
نویسنده برای ثبت این ردپا، ابزار AgentLens را معرفی می‌کند تا هر گام مدل و ابزار، ورودی‌های پردازش‌شده و خروجی‌های خام را ثبت کند. این‌ها رکوردهایی غیرقابل جعل از اتفاقات واقعی هستند. در همین حال، agent-eval بر اساس دکترین نردبان شواهد، این ردپاها را امتیازدهی و گیت‌گذاری می‌کند. بدون ردیابی، ارزیابی صرفاً حدس زدنِ یک داور است؛ اما با ردیابی، به یک رکورد قابل تأیید تبدیل می‌شود. ردیابی بدون ارزیابی نیز صرفاً یک لاگ دیباگ است.
پیاده‌سازی گیت سطح ۱
به‌عنوان مثال، یک گیت سطح ۱ می‌تواند تناقض در مبالغ استرداد را با یک بررسی ساده در طرحواره Zod تشخیص دهد. با تعریف یک شیء RefundCommitment شامل شماره مرحله، مبلغ و دامنه (کل یا جزئی)، سیستم می‌تواند تعهدات را در طول مسیر مقایسه کند.
اگر در مرحله‌ای بعد، دامنه به‌طور خاموش تغییر کند اما مبلغ ثابت بماند، سیستم یک «مقدار منقضی» (Stale Value) را گزارش می‌کند. این فرآیند به هیچ فراخوانی مدل نیاز ندارد، هزینه آن تقریباً صفر است و آن‌قدر سریع است که پاسخ بد را قبل از رسیدن به کاربر مسدود می‌کند. در اینجا هیچ داوری نیاز نیست، زیرا ما با یک تفاوت (Diff) روی داده‌های ردیابی سروکار داریم که عامل قادر به جعل آن نبوده است. این رویکرد سخت‌گیرانه برای جلوگیری از توهمات، مشابه استراتژی‌هایی است که IntelliBooks برای تضمین دقت پاسخ‌ها در حوزه سلامت به کار می‌گیرد تا ریسک‌های عملیاتی را به حداقل برساند.
تحویل ۸۰ درصدِ نتایج
توسعه‌دهندگان باید از وسوسه استفاده از «داورهای هوشمند» برای حل مشکل انسجام گفتگوهای چندمرحله‌ای دوری کنند. تقریباً ۸۰ درصد از شکست‌های جلسه — از جمله رها کردن محدودیت‌ها، تناقضات، پاسخ‌های تکراری و سؤالات بی‌پاسخ — را می‌توان به‌صورت قطعی در سطح ۱ و ۲ روی مسیر (Trajectory) شناسایی کرد.
مدل زبانی به‌مثابه داور (LLM-as-a-judge) باید برای ۲۰ درصد باقی‌مانده از مسائل ذهنی «دم» (Tail Issues) مثل همدلی یا اینکه آیا فرآیند ارجاع به پشتیبانی درست مدیریت شده است، رزرو شود. این موارد باید به‌صورت آفلاین، اندازه‌گیری شده و به‌وضوح با برچسب «نظر» و نه «شواهد» مدیریت شوند. این موضوع حیاتی است زیرا داوری یک مدل توسط مدل دیگر، دایره‌وار است؛ آن‌ها پیش‌فرض‌های خطای مشابهی دارند و هیچ حقیقت مستقل (Ground Truth) وجود ندارد.
با نمره دادن به «جلسه» به‌جای «جمله»، تیم‌ها می‌توانند جلوی توهمِ موفقیت را بگیرند و گفتگوهایی که در لحظه در حال فروپاشی هستند را شناسایی کنند.
گام بعدی شما
- ارزیابی‌های فعلی خود را بررسی کنید و ببینید چند درصد از آن‌ها «تک‌مرحله‌ای» هستند و کل جلسه را نادیده می‌گیرند.
- برای محدودیت‌های حیاتی (مانند واحد پولی یا تاریخ)، گیت‌های سطح ۱ (Deterministic) را جایگزین داورهای مدل کنید.
- زیرساخت ردیابی (Tracing) را در محیط توسعه پیاده کنید تا بتوانید مسیر تصمیم‌گیری عامل را بدون خلاصه کردن مدل، بازبینی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو