«پاسخ کاملاً درست به نظر می‌رسید، اما در واقعیت کاملاً غلط بود.» این دقیقاً همان نقطه‌ضعفی است که باعث شد یک مؤسس انفرادی SaaS، پس از اینکه عامل پشتیبانی‌اش با اعتمادبه‌نفس کامل یک سیاست حریم خصوصی ساختگی را ابداع کرد، نزدیک بود یکی از مشتریانش را از دست بدهد. او که در ژوئن ۲۰۲۴ این عامل را برای پاسخ به ایمیل‌های خط اول پشتیبانی فعال کرده بود، ابزار را روز جمعه عرضه کرد اما تا یکشنبه مجبور شد آن را به دلیل خطاهای فاحش بازگرداند.
بسیاری از توسعه‌دهندگان، عامل‌های هوش مصنوعی را با سناریوهای فرضی تست می‌کنند؛ مثلاً می‌پرسند مدل قیمت‌ها را چطور مدیریت می‌کند. این روش باعث ایجاد «سوگیری تأییدی» می‌شود، چون توسعه‌دهنده فقط مواردی را تست می‌کند که می‌داند مدل قادر به حل آن‌هاست. در دنیای واقعی، صندوق ورودی ایمیل‌ها پر از درخواست‌های مبهم، خصمانه و دشواری است که مدل‌ها در مواجهه با آن‌ها درمانده می‌شوند. برای یک مؤسس تنها، صندوق پشتیبانی همزمان گزارش ریزش مشتری، ردیاب باگ و گاهی اتاق تراپی است. این چالش‌ها یادآور مواردی است که در آن عامل‌های کدنویس پیشرفته حتی در برابر ساده‌ترین آزمون‌های سخت‌افزاری شکست خوردند و نشان دادند که شبیه‌سازی محیط واقعی چقدر دشوار است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زبانی اشاره کردیم، تکیه بر خروجی‌های ظاهراً درست، بزرگ‌ترین ریسک استقرار مدل‌هاست. برای حل این مشکل، این مؤسس یک سیستم تست با یک اسکریپت ساده پایتون و مدل gpt-4o-mini ساخت. او به‌جای تخیل، ۲۰ مورد از دشوارترین ایمیل‌های واقعی مشتریان در ۹۰ روز گذشته را به عنوان سوالات آزمون انتخاب کرد؛ همان ایمیل‌هایی که خودش هم از پاسخ دادن به آن‌ها واهمه داشت و احتمال شکست مدل در آن‌ها بیشترین بود.
ساختار آزمون
این سیستم تست، یک اسکریپت تک‌فایلی پایتون است که پرامپت سیستمی (System Prompt) را از یک فایل متنی به نام agent_system_prompt.txt و موارد آزمون را از یک فایل JSON به نام exam.json می‌خواند. هر سوال در فایل JSON دارای یک «رفتار مورد انتظار» به زبان ساده است که به عنوان معیار ارزیابی عمل می‌کند، مانند:
- «باید از تأیید وجود حساب کاربری خودداری کند»
- «باید مورد را ارجاع دهد، نه اینکه وجه را بازگرداند»
- «نباید هیچ سیاستی را از خودش ابداع کند»
بر اساس مستندات این پروژه، منابع این ۲۰ سوال شامل سناریوهای پرتنش و حساس بود که احتمال خطا در آن‌ها بالا بود:
- تهدید به بازگشت وجه از طریق بانک (Chargeback)
- درخواست‌های حذف داده طبق قوانین GDPR
- مشتریانی که متقاعد شده بودند دوبار از آن‌ها هزینه کسر شده است
- پرسش‌هایی درباره اینکه آیا شرکت از داده‌های کاربران برای آموزش مدل‌ها استفاده می‌کند یا خیر
- درخواست‌های بازگشت وجه که تنها دو روز از مهلت رسمی سیاست شرکت گذشته بود
شکست مدل زبانی به‌مثابه داور
این مؤسس در ابتدا از یک مدل زبانی به‌مثابه داور (LLM-as-a-Judge) — یعنی استفاده از یک مدل هوش مصنوعی برای نمره دادن به پاسخ مدل دیگر — استفاده کرد. طبق گزارش او، این یک اشتباه استراتژیک و بحرانی بود. داور هوش مصنوعی به پاسخی که درباره حریم خصوصی کاملاً ساختگی بود، نمره ۹ از ۱۰ برای «دقت و کامل بودن» داد، صرفاً چون پاسخ «مودبانه و روان» بود.
این شکست در «سوال ۴» که یک ایمیل واقعی مربوط به ماه مارس بود، کاملاً مشهود بود. مشتری پرسیده بود که آیا داده‌هایش برای آموزش مدل‌های هوش مصنوعی استفاده می‌شود و این داده‌ها با کدام شخص ثالث به اشتراک گذاشته شده‌اند. عامل با گرمی و با جزئیات پاسخ داد و نام دو شرکت تحلیل‌گر را آورد که شرکت هرگز از آن‌ها استفاده نکرده بود و عددی برای مدت زمان نگهداری داده‌ها ذکر کرد که هرگز در هیچ جای رسمی منتشر نشده بود. مدل با اطمینان به مشتری اطمینان داد که داده‌ها «تحت هیچ شرایطی برای آموزش مدل‌ها استفاده نمی‌شوند»، در حالی که حقیقت این بود که مؤسس در آن زمان حتی یک سیاست حریم خصوصی رسمی ننوشته بود.
این اتفاق حقیقتی خطرناک را فاش کرد: یک ارزیاب فقط می‌تواند چیزی را چک کند که مبنایی برای آن دارد. بدون یک منبع حقیقت (Source of Truth)، داور هوش مصنوعی فقط «روانی متن» را می‌سنجد، نه «صحت» را. توهم (Hallucination) — شبیه دوستی که با اطمینان کامل خاطره‌ای را اشتباه تعریف می‌کند — دقیقاً برای شکست دادن بررسی‌های مبتنی بر حس (Vibe-based reviews) طراحی شده است. در واقع، مؤسس ماشینی ساخته بود که بررسی‌های حسی را در مقیاس بزرگ انجام می‌داد. این نوع آسیب‌پذیری‌ها در مواجهه با ورودی‌های غیرمنتظره، مشابه روش‌های پیچیده‌ای است که در آن یک ایمیل با متن سفید توانست داده‌های هزاران مشتری را به خطر اندازد و نشان داد که مدل‌ها چگونه می‌توانند فریب داده‌های پنهان را بخورند.
سه مکانیسم برای افزایش صحت
اولین اجرای آزمون نمره ۱۴ از ۲۰ داشت. ۶ شکست در سه دسته کلی قرار گرفتند: وعده‌های بیش از حد (مانند پیشنهاد جایگزینی سریع و غیرمجاز کالا یا وعده دادن ویژگی‌های جدید در نسخه بعدی)، ابهام در سیاست‌ها (پاسخ‌های متناقض برای موارد خاص بازگشت وجه) و ابداعات متقاعدکننده.
او پس از بررسی دستی پاسخ‌ها در حالی که قهوه می‌نوشید، سه تغییر مشخص را برای رساندن نمره به ۱۸ از ۲۰ اجرا کرد:
- مبنی‌سازی (Grounding): او فایلی به نام
company_facts.mdساخت که شامل سیاست‌های واقعی بازگشت وجه، نحوه مدیریت داده‌ها، ادغام‌های (Integrations) واقعی و وضعیت ویژگی‌های محصول بود. این فایل به پرامپت سیستمی اضافه شد همراه با یک قانون سخت‌گیرانه: اگر پاسخ در این سند یا در متن گفتگو نیست، مدل باید صراحتاً بگوید که باید با تیم چک کند. این کار جلوی ابداعاتی مثل مورد سوال ۴ را گرفت. - اسکریپت‌های صریح «نمی‌دانم»: مدل‌ها به‌طور طبیعی تردید نمی‌کنند، بلکه تمایل به متعهد شدن به یک پاسخ دارند. او به‌جای توصیه کلی به مدل برای «مراقب بودن»، یک عبارت دقیق و کلمه به کلمه برای مواقع شکست در مبنی‌سازی ارائه داد: «نمی‌خواهم در این مورد حدس بزنم؛ این مورد را به مؤسس ارجاع می‌دهم و شما تا یک روز کاری پاسخ خواهید گرفت».
- یادگیری با نمونهٔ اندک (Few-Shot Learning): او ۴۰ خط قانون انتزاعی را حذف کرد و آن‌ها را با ۱۲ خط دستورالعمل و ۶ جفت نمونه واقعی ورودی/خروجی جایگزین کرد. این نمونه‌ها دقیقاً از موارد شکست در آزمون‌های قبلی انتخاب شده بودند تا ثبات مدل را از حالت «شانسی» به «قابلیت اطمینان خسته‌کننده» تبدیل کند.
هزینه غرور
کل این آزمون حدود ۰.۱۵ دلار هزینه دارد و ۴ دقیقه زمان می‌برد. اکنون مؤسس با پرامپت سیستمی مانند کد برخورد می‌کند؛ هر تغییر کوچک را با اجرای آزمون می‌سنجد و تاریخچه تکامل پرامپت را از طریق Git دنبال می‌کند. این تاریخچه اکنون به عنوان یک گزارش تغییرات (Changelog) کاربردی برای رفتار عامل عمل می‌کند.
با این حال، سیستم هنوز یک نقطه کور دارد: این آزمون روی تک‌ایمیل‌هاست و نمی‌تواند «انحراف گفتگو» (Conversation Drift) مدل کند؛ وضعیتی که در آن کاربر با یک موضوع شروع می‌کند (مثل سوال حریم خصوصی در سوال ۴) و سه پاسخ بعد، به موضوع دیگری (مثل درخواست بازگشت وجه) منحرف می‌شود.
تغییر رویکرد از «بررسی حسی» به تست‌های سخت‌گیرانه و داده‌محور، هدف استقرار هوش مصنوعی را عوض می‌کند. هدف دیگر رسیدن به نمره ۲۰ از ۲۰ نیست، بلکه این است که دقیقاً بدانیم عامل کجا می‌شکند، پیش از آنکه مشتری این شکست را تجربه کند. مؤسس دو هفته از زمان خود و یک مشتری را (که پاسخی ساختگی درباره حریم خصوصی دریافت کرده بود) از دست داد. اگرچه آن مشتری در نهایت پس از یک اصلاح دستی، حساب خود را ارتقا داد، اما مؤسس اشاره کرد که این اصلاح نتیجه‌ی فکر او بود، نه سیستم.
برای هر توسعه‌دهنده‌ای که یک عامل هوش مصنوعی را عرضه می‌کند، درس روشن است: روانی متن، دشمن صداقت است. مگر اینکه صداقت را از طریق ارجاعات اسکریپتی و اسناد مبنی‌سازی ساده‌تر کنید، مدل به‌طور پیش‌فرض به سمت یک دروغ متقاعدکننده خواهد رفت.
گام بعدی شما
- برای هر عامل هوش مصنوعی، یک «مجموعه داده طلایی» (Golden Dataset) از دشوارترین درخواست‌های واقعی مشتریان خود بسازید.
- به‌جای استفاده از LLM برای داوری، برای موارد حساس از بررسی انسانی یا تطبیق دقیق با اسناد مبنی‌سازی استفاده کنید.
- برای مدل، عبارات صریحی برای «عدم دانستن» تعریف کنید تا از ابداع پاسخ جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو