گزارش BotCritic: افزایش ۵ واحدی استواری مدل با بهینه‌سازی منطق

اگر فکر می‌کنید برای ارتقای عملکرد عامل‌های هوش مصنوعی حتماً باید مدل را عوض کنید، سخت در اشتباهید. یک بازرسی فنی و بازطراحی هدفمند پرامپت‌ها در ۱۴ ژوئیه ۲۰۲۶، امتیاز عملکرد یک بات پشتیبانی فروشگاهی را از ۸۶ به ۹۱ رساند. این تغییر نشان می‌دهد که بهبودهای قابل‌اندازه‌گیری اغلب از طریق بستن شکاف‌های منطقی به‌دست می‌آیند، نه لزوماً با جایگزینی مدل‌های زیرساختی گران‌قیمت یا پیچیده‌تر.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت و استقرار مدل‌های بازمتن اشاره کردیم، لایه‌ی دستورالعمل‌ها (Instruction Layer) نقشی حیاتی در خروجی نهایی ایفا می‌کند. بسیاری از تحلیل‌های چت‌بات‌ها تنها به شناسایی نقاط شکست بسنده می‌کنند؛ یعنی فقط می‌گویند چه چیزی خراب است. در همین راستا، بررسی‌های اخیر BotCritic روی چت‌بات‌های Groq نشان داد که حتی مدل‌های سریع نیز در مواجهه با توهمات منطقی دچار افت امتیاز شدید می‌شوند. اما در این آزمایش، تمرکز روی «تأیید» بود: اعمال اصلاحات پیشنهادی و اجرای دوباره‌ی دقیق همان مجموعه‌ی آزمون برای اثبات نتایج. برای کسب‌وکارها، این یعنی گذار از تست‌های «حسی» (Vibes-based) — که در آن تصمیمات بر اساس احساس کاربر گرفته می‌شود — به یک جریان کاری سخت‌گیرانه و مبتنی بر شواهد.

بستر آزمایش و ارزیابی

تیم توسعه برای ایجاد یک خط‌کشی مبنا (Baseline)، از ابزار BotCritic استفاده کرد تا بات را در برابر چهار شخصیت (Persona) مختلف مشتری به چالش بکشد: «کنجک» (Curious)، «عصبانی» (Frustrated)، «گیج» (Confused) و «فنی» (Technical). اجرای اولیه منجر به نمره‌ی ۸۶ از ۱۰۰ (رتبه‌ی B) شد و نقاط اصطکاک بحرانی در مسیر مشتری را آشکار کرد.

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

جزئیات بازرسی و نقاط شکست

به نقل از گزارش وب‌سایت dev.to، اجرای اول چهار شکست اصلی و ساختاری را شناسایی کرد:

• توقعات کاذب (False Expectations): بات شماره‌هایی را درخواست می‌کرد که در واقعیت نمی‌توانست آن‌ها را جست‌وجو کند. برای مثال، وقتی یک کاربر عصبانی گزارش داد که بسته‌اش دو هفته است گم شده، بات ابتدا داده‌ها و شماره سفارش را جمع‌آوری کرد، اما در نهایت اعتراف کرد که دسترسی لحظه‌ای به سیستم رهگیری ندارد. این توالیِ «درخواست داده و سپس ناتوانی در پاسخ»، یک سکانس عقب‌نشینی ایجاد می‌کرد که اضطراب و خشم مشتری را افزایش می‌داد. این نوع عدم استقرار صحیح منطق می‌تواند مشابه خطاهای بحرانی API در استارت‌آپ‌های فین‌تکی باشد که منجر به ضررهای مالی سنگین می‌گردد.
• شکاف‌های اطلاعاتی (Information Gaps): سیاست‌های مرجوعی در پاسخ‌های بات به بازه‌ی ۳۰ روزه اشاره می‌کرد اما شرایط لازم برای پذیرش کالا را حذف کرده بود. بات هرگز ذکر نمی‌کرد که کالاها باید «بدون استفاده»، «نشسته/نشست‌نشده» و «دارای تگ‌های اصلی» باشند. این شکاف اطلاعاتی در دنیای واقعی منجر به رد کالا در انبار و ایجاد اختلافات شدید بین مشتری و فروشگاه می‌شود.
• محرک‌های مبهم (Ambiguous Triggers): بات اعلام می‌کرد که بازپرداخت وجه «پس از دریافت کالا» انجام می‌شود، اما نمی‌توانست محرک (Trigger) دقیق این اتفاق را شفاف کند. بات قادر نبود بین «اسکن بسته توسط شرکت حمل‌ونقل» و «تأییدیه نهایی انبار» تفکیک قائل شود، که باعث سردرگمی مشتری در مورد زمان دریافت پول می‌شد.
• منطق واکنشی (Reactive Logic): بات مراحل مرجوعی را توضیح می‌داد، بدون اینکه ابتدا بررسی کند آیا کاربر از مهلت قانونی ۳۰ روزه گذشته است یا خیر. برای نمونه، وقتی شخصیت «کنجک» اشاره کرد که سفارش را «حدود یک ماه پیش» ثبت کرده است، بات نتوانست پیش‌دستانه ریسک عدم صلاحیت (Eligibility Risk) را هشدار دهد و کاربر را به مسیر طولانی مرجوعی برد تا در نهایت متوجه شود مهلتش تمام شده است.

اجرای اصلاحات و نتایج

راهکار جایگزین، یک به‌روزرسانی واحد در پرامپت سیستمی (System Prompt) — یعنی همان دستورالعمل بنیادینی که مثل یک قانون اساسی برای رفتار مدل عمل می‌کند — بر اساس پیشنهادات BotCritic بود. دستورات جدید صریحاً mandate (الزام) کردند که:

• «اگر نمی‌توانی شماره سفارش را جست‌وجو کنی، هرگز آن را نخواه؛ کاربر را فوراً به لینک رهگیری وب‌سایت بفرست.»
• «در هر توضیح مربوط به مرجوعی، حتماً شرایط کالا (بدون استفاده، بدون شستشو، همراه با تگ‌ها) را ذکر کن.»
• «به طور دقیق تصریح کن که پنجره‌ی بازپرداخت از لحظه‌ی تأیید انبار شروع می‌شود، نه از لحظه‌ی اسکن توسط شرکت حمل‌ونقل.»
• «اگر کاربر به بازه‌ی زمانی مبهم یا طولانی از زمان سفارش اشاره کرد، پیش از هر اقدامی و پیش از هدایت کاربر به مراحل بعدی، ریسک پایان مهلت ۳۰ روزه را هشدار بده.»

بر اساس مستندات این پروژه، بازآزمایی در ۱۴ ژوئیه نتایج فوری و ملموسی را نشان داد. شخصیت «عصبانی» دیگر با مرحله‌ی بیهوده و خشم‌آور جمع‌آوری داده‌ها مواجه نشد و مستقیماً به لینک رهگیری هدایت شد. همچنین، بازپرداخت وجه به‌طور دقیق در یک بازه‌ی ۵ تا ۷ روز کاری تعریف شد که از زمان تأیید انبار شروع می‌شود؛ این تغییر تمام ابهامات مالی مشتریان در مورد زمان بازگشت پول را برطرف کرد.

تحلیل نمرات

توزیع امتیازات نشان می‌دهد بیشترین پیشرفت در کدام بخش رخ داده است:

• صحت (Accuracy): ۸۵ ← ۹۱
• پایبندی به شخصیت (Persona Adherence): ۸۸ ← ۹۳
• استواری (Robustness): ۷۸ ← ۸۸
• ایمنی و انطباق (Safety/Compliance): ۹۱ ← ۹۲

بیشترین جهش در بخش «استواری» (Robustness) رخ داد. دلیل این امر آن بود که اصلاحات به‌جای دانش پایه (که از همان اجرای اول درست بود)، روی نحوه مدیریت ابهامات، لبه‌های زمانی (Edge cases) و سناریوهای پیچیده تمرکز داشت.

جالب است که حتی در نمره‌ی ۹۱ از ۱۰۰، بازرسان عمداً برخی موارد جزئی را دست‌نخورده گذاشتند. این موارد شامل زبانِ کمی محتاطانه (Hedged language) در پاسخ به سؤالاتی درباره APIهای توسعه‌دهنده که وجود نداشتند، و همچنین از دست دادن فرصت برای ذکر سریع‌تر آستانه‌های ارجاع (Escalation Thresholds) در گفتگوهای عصبانی بود. این کار عمداً انجام شد تا نشان دهند بازرسی‌ها یک فرآیند مستمر و چرخه‌ای هستند، نه یک اتفاق یک‌باره و نهایی.

برای متخصصان هوش مصنوعی، این مورد تأیید می‌کند که ارزش واقعی یک بازرسی در تهیه لیست باگ‌ها نیست، بلکه در اثبات این است که یک تغییر مشخص و کوچک در پرامپت، دقیقاً کدام مشکل را حل کرده است. این رویکرد، استاندارد ارزیابی را از «پیشنهادات معقول» به «شواهد اندازه‌پذیر» تغییر می‌دهد.

کاربرانی که به‌دنبال اعتبارسنجی عامل‌های خود هستند، می‌توانند از طریق botcritic.pro گزارش‌های رتبه‌بندی شده (از A تا F)، لیست دقیق باگ‌های یافته شده و پرامپت‌های بازنویسی شده را در سطح رایگان (بدون نیاز به کارت بانکی) دریافت کنند.

گام بعدی شما

• اگر عامل پشتیبانی دارید، یک مجموعه‌ی تست با شخصیت‌های مختلف (عصبانی، گیج، فنی) طراحی کنید تا نقاط شکست منطقی را بیابید.
• به جای تغییر مدل، ابتدا روی «بستن شکاف‌های اطلاعاتی» در پرامپت سیستمی تمرکز کنید.
• خروجی‌های مدل را با یک معیار عددی (مانند نمره‌ی BotCritic) بسنجید تا اثر تغییرات پرامپت را مستند کنید.

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