تصور کنید یک هوش مصنوعی در محیط عملیاتی، کالای اشتباهی را ارسال کند یا یک پایگاه داده را به‌طور کامل پاک کند؛ یک خطای «مرگبار» در این سطح می‌تواند غیرقابل بازگشت باشد. برای جلوگیری از این فجایع، توسعه‌دهنده‌ای به نام ramses203 چارچوبی را منتشر کرده است که نمرات کلی صحت را با یک آزمون هدفمند «حادثه‌محور» جایگزین می‌کند.
بسیاری از توسعه‌دهندگان، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — را با چند مورد ساده و ایده‌آل تست می‌کنند که مدل احتمالاً در آن‌ها موفق می‌شود. این رویکرد «مسیر خوش‌بینانه» (Happy Path) شکست می‌خورد چون مدل‌ها به‌ندرت در کارهای ساده اشتباه می‌کنند؛ آن‌ها دقیقاً در لبه‌های سیستم و موارد خاصی می‌لغزند که منجر به فاجعه‌های تجاری می‌شود. هدف یک آزمون حرفه‌ای، تماشای موفقیت مدل نیست، بلکه یافتن دقیق نقطه‌ای است که مدل در آن می‌شکند. این چالش با یافته‌های اخیر همسو است که نشان می‌دهد حتی مدل‌های پیشرو نیز در اجرای دقیق سیاست‌های سازمانی با نرخ شکست بالایی روبرو هستند و نمی‌توان صرفاً به توانایی‌های کلی آن‌ها اعتماد کرد.
در یک سیستم پردازش سفارش، یک پاسخ غلط صرفاً یک «نمره پایین» نیست، بلکه کامیونی است که با کالای اشتباه بارگیری شده است. این «کامیون» نماد بدترین سناریوی ممکن برای هر خط لوله‌ای است. چه یک هوش مصنوعی ایمیل باشد که پاسخی غیرقابل بازگشت و غلط ارسال می‌کند، یا یک هوش مصنوعی پژوهشی که عددی ساختگی را در گزارش هیئت مدیره می‌نویسد، الگو یکسان است: داده‌هایی که ارسال، حذف یا ارتقا شده‌اند، دیگر باز نمی‌گردند.
گام اول: تعریف «کامیون»
پیش از نوشتن اولین سؤال آزمون، باید پیامدهایی را که قابل بازگشت نیستند شناسایی کنید. از خود بپرسید: «وقتی این هوش مصنوعی اشتباه کند، کدام پیامدها غیرقابل جبران هستند؟»
بسته به حوزه کاری شما، «کامیون» شما متفاوت خواهد بود:
- هوش مصنوعی پاسخ‌دهی ایمیل: پاسخی غلط به مشتری ارسال می‌شود و نمی‌توان آن را پس گرفت.
- هوش مصنوعی صورت‌جلسات: مدل روی موضوعی که در واقع هنوز تصمیم‌گیری نشده، برچسب «تصمیم شد» می‌زند؛ وقتی این متن به اشتراک گذاشته شود، تیم بر اساس یک فرض غلط پیش می‌رود.
- هوش مصنوعی پژوهشی: یک عدد ساختگی وارد گزارش می‌شود و از طریق سلسله‌مراتب مدیریتی به سطوح بالا می‌رود.
- هوش مصنوعی پاک‌سازی داده: مدل فایل اصلی را بدون داشتن پشتیبان یا امکان بازیابی، بازنویسی می‌کند.
گام دوم: جدول درجهٔ شدت
پس از تعریف بدترین سناریو، درجه‌بندی‌ها به‌طور خودکار مشخص می‌شوند. معیار اصلی این است که آیا یک انسان می‌تواند اثر آن اقدام را خنثی کند یا خیر. به جای درصد، نتایج بر اساس شدت شمارش می‌شوند:
- مرگبار (FATAL): غیرقابل بازگشت؛ مانند مواردی که ارسال، حذف، گزارش یا پرداخت شده‌اند.
- پرریسک (RISKY): مدل چیزی مبهم را تأیید کرده است. این بار اتفاقی درست بود، اما دفعه بعد مرگبار خواهد بود.
- از دست رفته (MISSED): مدل موردی را نادیده گرفته یا جا انداخته است، اما انسان هنوز می‌تواند خطا را شناسایی و اصلاح کند.
- بی‌ضرر (HARMLESS): مدل بیش از حد درخواست تأیید می‌کند (مثلاً «لطفاً تأیید کنید»)، که فقط باعث کندتر شدن فرآیند می‌شود.
تنها خطی که باید خودتان تعریف کنید، خط «مرگبار» است؛ سه درجه دیگر تقریباً برای هر پروژه‌ای کاربرد دارند. قاعده طلایی این است: یک تأیید اشتباه، همیشه بدتر از عدم تأیید است.
گام سوم: کاشتن تله‌ها
آزمون‌های مؤثر به‌جای موارد عادی، از «تله‌ها» استفاده می‌کنند. این چارچوب چهار نوع تله جهانی را شناسایی کرده است که در هر حوزه‌ای وجود دارند:
- جفت‌های مشابه: مواردی که آن‌قدر شبیه هم هستند که مدل را گیج می‌کنند.
- در سفارشات: نوار چسب ۴۸ میلی‌متری در برابر ۶۰ میلی‌متری.
- در صورت‌جلسات: دو شرکت‌کننده به نام «کیم» (یکی کارمند، یکی مدیر).
- در ایمیل: تفاوت بین «پاسخ» (Reply) و «ارسال مجدد» (Forward).
- غیرهدف‌های پذیرفتنی: متنی که شبیه هدف است اما در واقع نیست.
- در سفارشات: «مشخصات جعبه ارسال ۲۵۰ چیست؟» (نام محصول دارد اما سفارش نیست).
- در صورت‌جلسات: «بیایید دفعه بعد درباره‌اش تصمیم بگیریم» (این یک تصمیم نیست).
- در ایمیل: یک ایمیل تبلیغاتی (چیزی نیست که نیاز به پاسخ داشته باشد).
- تغییر مسیر در میانه پیام: دستوراتی که در وسط راه عوض می‌شوند.
- در سفارشات: «۵ عدد جعبه لطفاً... نه صبر کنید، ۳ عدد کنید».
- در صورت‌جلسات: «بیایید با گزینه A پیش برویم $\rightarrow$ در واقع B بهتر است».
- حوادث پس از یادگیری: برای سیستم‌های دارای حافظه الزامی است. این تست می‌کند که آیا اطلاعات تازه بر مقادیر ذخیره‌شده (مثلاً «چسب ۶۰») غلبه می‌کند یا حافظه به‌اشتباه حکم را تغییر می‌دهد (مثلاً تبدیل یک سؤال به یک پاسخ قطعی).
تعداد سؤالات باید بر اساس لیست حوادث گام اول باشد. برای هر نوع حادثه، حداقل یک سؤال طراحی کنید که دقیقاً همان حادثه را ایجاد کند. برای مثال، اگر اشتباه گرفتن یک استعلام با یک سفارش منجر به ارسال کالای ناخواسته می‌شود، باید سؤالی مثل «مشخصات جعبه ارسال ۲۵۰ چیست؟» را بگنجانید.
در حالی که آزمون نویسنده به ۲۹ مورد رسید، ۱۰ مورد برای شروع کافی است. در انتها چند مورد عادی و «خوش‌رفتار» اضافه کنید، اما آن‌ها را به حداقل برسانید؛ چون به‌ندرت چیزی را شکار می‌کنند.
گام چهارم: تردید در کلید پاسخ‌ها
بر اساس مستندات این متدولوژی، کلیدهای پاسخ اغلب اشتباه هستند. نویسنده متوجه شد که کلیدها سه بار در پاسخ‌نامه و دو بار در سیستم درجه‌بندی اشتباه بوده‌اند. برای حفظ یکپارچگی، سه قانون را دنبال کنید:
۱. ابهام نیاز به تأیید دارد: پاسخ درست برای هر سؤال مبهم، «نیاز به تأیید» است، نه یک حکم احتمالی که شبیه درست به نظر برسد.
۲. بازخوانی پیش از جریمه: اگر مدل با کلید پاسخ مخالف است، داده‌ها را دوباره بخوانید؛ شاید مدل درست گفته باشد. اما اگر اصلاح شما، یک «نیاز به تأیید» را به یک حکم قطعی تبدیل می‌کند، به آن اصلاح مشکوک شوید.
۳. پرچم مرجع: برای هر سؤال از پیش ثبت کنید: «آیا داده‌های مرجع به‌تنهایی پاسخ را دقیقاً به یک گزینه واحد محدود می‌کنند؟»
این پرچم نقش داور را دارد. مثلاً اگر ورودی «چسب ۶۰، ۲ عدد» باشد و کاتالوگ چسب ۶۰ میلی‌متری داشته باشد، داده‌ها پاسخ را تثبیت می‌کنند و اگر مدل شکست بخورد، مدل غلط است. اما اگر ورودی «چسب شفاف، ۲ عدد» باشد بدون ذکر عرض، داده‌ها نمی‌توانند پاسخ را تثبیت کنند. پاسخ درست باید «نیاز به تأیید» باشد. اگر کلید پاسخ چیز دیگری می‌گوید، کلید خراب است.
گام پنجم: دفتر کل سه خطی
اعتبارسنجی نهایی نیازمند یک دفتر کل صادقانه است. نتایج را بر اساس شدت درجه‌بندی کرده و پاسخ‌های خام مدل را در فایل‌ها ذخیره کنید. این کار اجازه می‌دهد در صورت تغییر معیارها، بدون فراخوانی مجدد مدل، دوباره درجه‌بندی کنید.
یک سیستم تنها زمانی آماده استقرار است که این سه شرط را داشته باشد:
۱. تأیید شده (VERIFIED): هر نوع حادثه حداقل یک بار پاس شده و خطاهای مرگبار (FATAL) روی صفر نگه داشته شده باشند.
۲. تأیید نشده (NOT VERIFIED): اعتراف به اینکه داده‌های واقعی محیط عملیاتی هرگز از این تست رد نشده‌اند و هر جمله توسط نویسنده ابداع شده است.
۳. محافظت شده (GUARDED): قانونی که طبق آن، مدل در هر مورد مشکوک نباید تأیید کند و باید کار را به انسان بسپارد.
آنچه استقرار را توجیه می‌کند، صرفاً تست‌های تأیید شده نیست، بلکه ترکیب آزمون و حفاظ‌ها (Guardrails) است. آزمون مواردی را می‌پوشاند که می‌توانید تصور کنید و حفاظ‌ها مواردی را که تصورشان غیرممکن است مدیریت می‌کنند.
برای کسانی که قصد پیاده‌سازی دارند، ابزار اجراکننده و درجه‌بندی در گیت‌هاب در آدرس github.com/ramses203/llm-test-harness در دسترس است.
گام بعدی شما
- لیست «حوادث مرگبار» (کامیون‌ها) را برای محصول خود بنویسید.
- برای هر حادثه، یک «تله» طراحی کنید که مدل را به اشتباه بین دو گزینه مشابه بیندازد.
- یک لایه حفاظتی اضافه کنید که در صورت عدم اطمینان مدل، خروجی را به جای تأیید، به اپراتور انسانی ارجاع دهد.
اما برای اینکه این حفاظ‌ها در مقیاس بالا کار کنند، باید استراتژی‌های پیشرفته‌تری در مدیریت توکن‌ها داشته باشید — به تحلیل ما درباره‌ی فایل llms.txt مراجعه کنید.
گفتگو