سیستمی که با اعتمادبه‌نفس کامل پاسخی توهم‌آمیز می‌دهد، بسیار خطرناک‌تر از سیستمی است که صادقانه نبودِ پاسخ را می‌پذیرد. برای جلوگیری از این بحران، شرکت Geminate Solutions توصیه می‌کند پیش از عرضه هر قابلیت هوش مصنوعی، یک مجموعهٔ ارزیابی اختصاصی شامل ۵۰ تا ۱۰۰ پرسش واقعی ایجاد کنید.
این رویکرد، روش سنتی «تست در محیط بازی» (Playground) — که در آن توسعه‌دهنده سه سؤال می‌پرسد و بر اساس «حس خوب» تصمیم به انتشار می‌گیرد — را با یک معیار ثابت و صادقانه جایگزین می‌کند. بدون این مجموعه، هر تغییر در تکه‌بندی (Chunking)، بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — یا پرامپت‌ها، صرفاً یک حدس است. ممکن است تغییر در اندازه تکه‌ها در چند تست اولیه بهتر به نظر برسد، اما پس‌رفت‌های فنی تا زمانی که مشتری با آن‌ها برخورد نکند، پنهان می‌مانند.
بسیاری از تیم‌ها با پرسیدن سؤالاتی که پاسخ آن‌ها را از قبل می‌دانند، تست تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را به یک نمایش تبدیل می‌کنند. این کار باعث سوگیری به سمت موارد ساده شده و پایداری سیستم را در نسخه‌های مختلف از بین می‌برد. با ایجاد یک مجموعهٔ ثابت از پرس‌وجوها، توسعه‌دهندگان می‌توانند دقیقاً تشخیص دهند شکست در کجا رخ داده است: آیا موتور بازیابی (Retrieval) سند درست را پیدا نکرده یا مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در پردازش بستر متنی دچار خطا شده است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر نتایج ظاهری بدون داشتن یک محک (Benchmark) سخت‌گیرانه، ریسک عملیاتی را افزایش می‌دهد. این چالش با رویکرد گوگل در چارچوب ADK برای کاهش نرخ خطاهای عملیاتی هم‌سو است که بر اهمیت شناسایی نقاط شکست در عامل‌های هوش مصنوعی تأکید دارد.
به نقل از راهنمای منتشر شده در ۷ اکتبر ۲۰۲۶، نخستین گام، جمع‌آوری ۵۰ تا ۱۰۰ پرسش واقعی است. نوشتن این سؤالات توسط خود توسعه‌دهنده یک اشتباه است؛ زیرا به‌طور طبیعی از کلمات موجود در مستندات استفاده می‌کنید و این کار باعث بالا رفتن مصنوعی امتیاز بازیابی می‌شود. در عوض، توسعه‌دهندگان باید داده‌ها را از منابع زیر استخراج کنند:
- تیکت‌های پشتیبانی و متن چت‌های زنده
- یادداشت‌های تماس‌های فروش (مثلاً: «آیا با X یکپارچه می‌شود؟»)
- کانال‌های داخلی Slack یا Teams که کارکنان از متخصصان محصول کمک می‌گیرند
- لاگ‌های جست‌وجوی مراکز راهنمای موجود
- بازخوردهای کاربران نسخه بتا
این مجموعه باید ترکیبی از جست‌وجوهای ساده، سؤالاتی که نیاز به ترکیب دو سند دارند و موارد خصمانه مانند تزریق پرامپت (Prompt Injection) یا سیاست‌های متناقض باشد. نکته حیاتی این است که سؤالات «پاسخ‌ناپذیر» نیز گنجانده شوند تا اطمینان حاصل شود مدل در این موارد به‌جای ساختن پاسخ، می‌گوید «نمی‌دانم».
انتخاب تعداد ۵۰ تا ۱۰۰ سؤال، توازنی میان اهمیت آماری و هزینه نگهداری است. اگر تعداد سؤالات زیر ۵۰ مورد باشد، یک نتیجهٔ ناپایدار می‌تواند امتیاز کلی را به‌شدت جابه‌جا کند و نویز ایجاد کند. از سوی دیگر، اگر تعداد از ۱۰۰ مورد فراتر رود، برچسب‌گذاری (Labeling) به یک کار طاقت‌فرسا تبدیل شده و احتمال به‌روزرسانی مجموعه توسط تیم کاهش می‌یابد. بهترین روش این است که کوچک شروع کنید و بر اساس شکست‌های واقعی در محیط عملیاتی، مجموعه را گسترش دهید.
برای هر مورد، تیم باید متن دقیق سؤال، حتی با غلط‌های املایی را ثبت کند. هر ورودی به یک پاسخ مورد انتظار، شناسه‌های منبع (ID سند یا عنوان بخش) و فهرستی از حقایق «الزامی» نیاز دارد. ذخیره این داده‌ها در یک فایل JSONL در مخزن کد، ارزیابی را به منطق برنامه نزدیک می‌کند. یک ورودی نمونه به این شکل است:
{"id": "q017", "question": "how long do u keep deleted files", "expected_answer": "Deleted files stay in the trash for 30 days, then they are removed permanently.", "source_ids": ["data-retention#trash"], "must_include": ["30 days", "permanently"], "answerable": true}
استفاده از شناسه‌های منبع ثابت حیاتی است؛ اگر یک تکه‌بند (Chunker) در هر بار ایندکس‌گذاری شناسه‌های جدید تولید کند، امتیازات بازیابی فارغ از عملکرد واقعی، خراب خواهند شد. در چنین مواردی، بهتر است هر مورد را به ترکیب سند به‌علاوه عنوان بخش (Section Heading) متصل کنید.
طبق اعلام Geminate Solutions، یکی از رایج‌ترین اشتباهات، اندازه‌گیری صرفاً پاسخ نهایی است. آن‌ها استدلال می‌کنند که برای شناسایی دقیق نقطه شکست، باید بازیابی و پاسخ‌ها را به‌طور جداگانه امتیازدهی کرد.
معیارهای بازیابی ارزان و قطعی هستند زیرا نیازی به LLM ندارند. شاخص‌های کلیدی عبارتند از:
- Hit rate @k: آیا هر یک از منابع مورد انتظار در k نتیجه برتر ظاهر شدند؟
- Recall @k: چه درصدی از منابع مورد انتظار بازیابی شدند؟
- MRR (Mean Reciprocal Rank): اولین منبع درست در چه رتبه‌ای قرار گرفت؟
سپس معیارهای پاسخ، خروجی LLM را ارزیابی می‌کنند:
- پوشش حقایق (Fact Coverage): بررسی حضور حقایق الزامی از طریق تطبیق رشته‌ای ساده.
- وفاداری (Faithfulness): استفاده از یک مدل داور با دستورالعمل سخت‌گیرانه برای اطمینان از اینکه هر ادعا توسط بستر بازیابی‌شده پشتیبانی می‌شود.
- صحت رد کردن (Refusal Correctness): برای سؤالات پاسخ‌ناپذیر، آیا سیستم به‌جای ساختن پاسخ، از جواب دادن امتناع کرد؟
در این راستا، استفاده از روباریک JudgeMyAI می‌تواند به استانداردسازی ارزیابی‌های انسانی کمک کند تا توهمات مدل با دقت بیشتری شناسایی و حذف شوند.
مقایسه این دو امتیاز، یک ماتریس تشخیصی ایجاد می‌کند که دقیقاً اصلاح مورد نیاز را نشان می‌دهد:
- بازیابی خوب / پاسخ خوب: سیستم طبق انتظار کار می‌کند.
- بازیابی خوب / پاسخ بد: مشکل در پرامپت، مدل یا نحوه قالب‌بندی بستر است.
- بازیابی بد / پاسخ خوب: این مورد اغلب حاصل شانس است یا مدل از داده‌های آموزش خود پاسخ می‌دهد — رفتاری ریسک‌پذیر که هنگام تغییر داده‌ها منجر به توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شود.
- بازیابی بد / پاسخ بد: اولویت با اصلاح تکه‌بندی، بردارها یا بازنویسی پرس‌وجو است.
برای پایداری این روند، ارزیابی باید خودکار شود. یک اسکریپت پایتون کوچک می‌تواند با جایگزینی توابع بازیابی و تولید، کل چرخه را پوشش دهد. برای کنترل انتشار (Gate)، سیستم باید اجرای فعلی را با یک خط مبنا (Baseline) — مثلاً آخرین اجرای موفق روی شاخه اصلی (Main Branch) — مقایسه کند. در این مقایسه از یک سطح تحمل (Tolerance) مانند ۰.۰۲ استفاده می‌شود. اگر امتیاز بیش از این حد افت کند، بیلد (Build) باید با یک کد غیرصفر (Non-zero code) متوقف شود.
هنگام استفاده از مدل زبانی به‌مثابه داور (LLM-as-a-judge)، دستورالعمل را محدود نگه دارید. مثلاً: «آیا هر ادعای واقعی در پاسخ توسط بستر پشتیبانی می‌شود؟ با یک دلیل، PASS یا FAIL پاسخ دهید.» ضروری است که نسخه مدل داور ثابت (Pin) بماند و نمونه‌ای از احکام آن هر چند اجرا به‌طور دستی بررسی شود تا خودِ داور به نقطه شکست تبدیل نشود.
معیارهای بازیابی باید در هر Pull Request که منطق ایندکس‌گذاری یا پرس‌وجو را تغییر می‌دهد، اجرا شوند. ارزیابی‌های کامل پاسخ‌ها را می‌توان برای تغییرات پرامپت یا به‌صورت بیلد شبانه اجرا کرد. نتایج هر اجرا را به‌عنوان یک Artifact ذخیره کنید تا مقایسه موردبه‌مورد ممکن شود؛ زیرا یک امتیاز کلی تخت می‌تواند این حقیقت را پنهان کند که ۵ سؤال اصلاح شده‌اند اما ۵ مورد دیگر خراب شده‌اند.
بیلدها نباید بر اساس یک عدد ثابت، بلکه بر اساس افت امتیاز نسبت به خط مبنا شکست بخورند. افت در Hit Rate نسبت به آخرین اجرای شاخه اصلی، سیگنالی عینی برای بررسی است. برای جلوگیری از بیش‌برازش (Overfitting) — حالتی که مدل فقط روی داده‌های تست خوب عمل می‌کند و در دنیای واقعی شکست می‌خورد — توسعه‌دهندگان باید بخشی از موارد را کنار بگذارند و در طول تنظیم پرامپت به‌ندرت به آن‌ها دست بزنند.
این چرخه سخت‌گیرانه، مجموعه ارزیابی را به بخشی از خودِ قابلیت تبدیل می‌کند. با تبدیل هر باگ عملیاتی به یک مورد تست جدید و بازبینی مجموعه هنگام تغییر مستندات، سیستم به‌جای تکیه بر فرض‌های توسعه‌دهنده، برای مدیریت لبه‌های خاصِ کاربران تکامل می‌یابد. اگر نمی‌توانید با یک عدد و فهرستی از سؤالات متأثر پاسخ دهید که «آیا این تغییر قابلیت را بهتر کرد یا بدتر»، هنوز برای انتشار آماده نیستید.
گام بعدی شما
- از تیکت‌های پشتیبانی ماه گذشته، ۵۰ سؤال پرتکرار را استخراج و در یک فایل JSONL ذخیره کنید.
- معیارهای بازیابی (Hit Rate و Recall) را به‌طور جداگانه از کیفیت پاسخ نهایی تفکیک کنید تا گلوگاه سیستم را بشناسید.
- یک مدل داور (LLM Judge) با دستورالعمل تک‌کلمه‌ای (PASS/FAIL) برای سنجش وفاداری پاسخ‌ها پیاده‌سازی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو