تصور کنید مهندسی که یک ارزیابی ثابت را دو بار روی بنچمارک‌های یک مدل اجرا می‌کند و هر بار نمره‌ای متفاوت دریافت می‌کند. این نوسان ثابت می‌کند که ارزیابی در مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — نه اندازه‌گیری صحت، بلکه پیش‌بینی میزان اطمینان است. به نقل از یک راهنمای فنی مفصل که در ۲۲ جولای ۲۰۲۶ در وب‌سایت dev.to منتشر شد، تلقی این نمرات به‌عنوان نتایج قطعی «قبول یا رد»، باعث می‌شود تیم‌ها وقت خود را صرف تعقیب «روح‌های خیالی» در پرامپت‌های خود کنند.
دهه‌ها بود که رضایت از یک مجموعه تست سبز‌رنگ، ستون فقرات مهندسی نرم‌افزار بود: کد را تغییر دهید، تست را اجرا کنید و تأیید کنید که همه چیز درست کار می‌کند. اما مدل‌های زبانی به‌سادگی این چرخه بازخوردی مورد اعتماد را شکستند. وقتی هیچ تغییری در کد یا ورودی ایجاد نشده اما خروجی متفاوت است، مهندسان با «مغالطه تابلوی امتیازات» روبرو می‌شوند.
این تغییر دیدگاه برای توسعه‌کنندگانی که از مرحله نمونه‌اول به تولید انبوه می‌روند، حیاتی است. با تکیه بر پوشش‌های قبلی ما درباره موازنه میان قطعیت و انعطاف‌پذیری، مشخص می‌شود که پیش‌بینی‌ناپذیری مدل‌ها صرفاً یک نقص فنی در مدل نیست، بلکه بخشی جدانشدنی از خودِ فرآیند اندازه‌گیری است. در نرم‌افزارهای سنتی، یک مجموعه تست سبز مطلق است. اما در هوش مصنوعی، نمره ۸۴٪ صرفاً یک تخمین است. این رویکرد دقیقاً مشابه تفکر آماری مورد نیاز برای تست‌های A/B، بنچمارک‌های عملکرد و سیستم‌های توزیع‌شده است.
منبع اول نویز: ابهام در تکلیف
اولین مشکل، «عدم قطعیت تصادفی» (Aleatoric Uncertainty) است؛ جایی که ورودی به‌تنهایی اطلاعات کافی برای تولید یک پاسخ واحد و صحیح ندارد. طبق گزارش مذکور، این یک نقص در گفتگو است، نه در مدل.
برای مثال، کاربر با یک کلمه «بسه» (Stop) به دستیار پاسخ می‌دهد. بسته به زمینه، چندین تفسیر معتبر وجود دارد:
- درخواست لغو عضویت از طریق پیامک: «عضویت شما لغو شد.»
- توقف موقت گفتگو: «برای امروز کافی است. هر زمان خواستید ادامه دهیم خبر دهید.»
- ابراز ناراحتی و کلافگی: «متأسفم، بیایید روش دیگری را امتحان کنیم.»
- تغییر موضوع بحث: «بسیار خب، بیایید درباره این موضوع صحبت نکنیم و چیز دیگری را امتحان کنیم.»
چون چندین تفسیر درست است، ارزیابان انسانی هم بر سر بهترین پاسخ اختلاف نظر دارند. هیچ مقدار مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب از یک مشاور — یا تنظیمات مدل (Model Tuning) نمی‌تواند این نویز را حذف کند چون ابهام در خودِ گفتگو است. شما نمی‌توانید با عیب‌یابی یا کدنویسی از این وضعیت خارج شوید زیرا ورودی فاقد اطلاعات لازم برای یک پاسخ قطعی است.
کاهش اثر ابهام در تکلیف
برای حل این چالش، این گزارش چهار استراتژی مشخص برای بهبود کیفیت داده‌های تست (Fixtures) پیشنهاد می‌دهد:
- پیاده‌سازی زمینه گفتگوی غنی‌تر: اطمینان حاصل کنید که داده‌های تست شامل تاریخچه چندمرحله‌ای (Multi-turn history) باشند، زیرا زمینه است که ابهام را برطرف می‌کند.
- ساخت بنچمارک‌ها با داده‌های واقعی تولید: به‌جای تکیه بر داده‌های تست مصنوعی، از گزارش‌های (Logs) پاک‌سازی‌شده و بی‌نام‌شده محیط تولید استفاده کنید که نماینده واقعی استفاده‌های دنیای واقعی است.
- برچسب‌گذاری صریح ابهامات: مواردی که چندین پاسخ معتبر دارند را علامت بزنید تا با مقیاس باینری (صفر و یک) به‌طور غیرمنصفانه قضاوت نشوند.
- اندازه‌گیری کیفیت داده‌های تست: به‌جای تمرکز صرف روی نمره نهایی مدل، میزان وفاداری (Fidelity) و پوشش داده‌های تست را ردیابی کنید.
منبع دوم نویز: ناسازگاری داور
مشکل دوم «عدم قطعیت معرفتی» (Epistemic Uncertainty) است؛ جایی که تکلیف ثابت است اما ابزار اندازه‌گیری — یعنی مدل زبانی به‌مثابه داور (LLM-as-a-judge) — نوسان دارد. در این سناریو، مدل کاندید پاسخی تولید می‌کند که به‌وضوح درست است، اما داور ممکن است در یک اجرا نمره ۴ از ۵ و پنج دقیقه بعد نمره ۵ از ۵ بدهد.
این نویز از چندین منبع فنی نشأت می‌گیرد:
- رفتار تصادفی API: حتی با دمای (Temperature) صفر، APIهای مدل‌های میزبان ممکن است به دلیل جزئیات پیاده‌سازی ناشناخته در سمت ارائه‌دهنده، خروجی‌های متفاوتی بدهند.
- ابهام در معیارها (Rubric): پرسیدن اینکه آیا پاسخی «مفید» است، داور را مجبور می‌کند در هر بار اجرا تعریف جدیدی از مفید بودن ابداع کند.
- سوگیری‌های مدل: مدل‌ها تمایل به «ترجیح خود» (Self-preference) دارند (سلیقه در سبک نوشتاری خودشان)، دچار «سوگیری موقعیتی» هستند (ترجیح اولین گزینه ارائه شده) و «سوگیری طول» دارند (ترجیح پاسخ‌های طولانی‌تر).
مقاوم‌سازی چارچوب ارزیابی
برای کاهش عدم قطعیت داور، راهنما مداخلات فنی زیر را پیشنهاد می‌کند تا معماری به سمت یک سیستم اندازه‌گیری واقعی حرکت کند:
- مجموعه داوران (Judge Ensembling): ارزیابی‌ها را روی چندین مدل مختلف مثل Claude، GPT-4 و Gemini اجرا کنید تا نقاط کور هر مدل خنثی شود. این کار در صورتی که نتایج بر تصمیمات تولید (Production) اثر بگذارند، ضروری است.
- توافق بین داوران: نرخ توافق را با معیارهایی مثل «کاپا کوهن» (Cohen’s Kappa) ردیابی کنید تا دقیقاً شناسایی شود که داوران در کجا با هم اختلاف نظر دارند.
- ردیابی واریانس: ورودی‌های کاملاً یکسان را به‌صورت دوره‌ای چندین بار به داوران بدهید تا انحراف معیار پایه (Baseline Standard Deviation) سیستم محاسبه شود.
- امتیازدهی چندمحوره: بازه‌های ذهنی ۱ تا ۵ را با محورهای عینی و مجزا (مانند صحت، ایمنی و ایجاز) جایگزین کنید و از مقیاس‌های باینری یا ساختاریافته استفاده نمایید.
- پرچم‌گذاری داده‌های حساس: مواردی که نوسان نمره غیرعادی در اجراهای مختلف دارند را به‌طور خودکار برای بازبینی دستی (Manual Auditing) علامت بزنید.
پیامدهای مهندسی
تمایز بین این دو نوع نویز، معماری سیستم را تغییر می‌دهد. اگر نمره‌ای از ۸۴٪ به ۸۱٪ کاهش یابد، لزوماً یک پس‌رفت (Regression) نیست؛ بلکه ممکن است صرفاً واریانس مورد انتظار سیستم باشد. در نتیجه، مفیدترین عدد در یک گزارش نه «۸۴٪»، بلکه «۳٪ ± ۸۴٪» است. این رویکرد به ویژه در سیستم‌های پیچیده اهمیت دارد؛ برای مثال، استقرار خط لول‌های ارزیابی خودکار توانسته است با مدیریت دقیق‌تر این متغیرها، نرخ توهمات مدل‌ها را به‌شدت کاهش دهد.
وقتی اندازه‌گیری بازتاب‌دهنده بی‌ثباتی داور است، راهکار بهبود زیرساخت ارزیابی است. اما وقتی بازتاب‌دهنده ابهام در تکلیف است، باید داده‌های تست و زمینه را بهبود بخشید. اشتباه گرفتن این دو منجر به هفته‌ها اتلاف وقت در تغییر پرامپت‌هایی می‌شود که نمی‌توانند ورودی‌های اساساً مبهم را اصلاح کنند. از سوی دیگر، در سیستم‌های بازیابی اطلاعات، گاهی نوسان نتایج ناشی از مدل نیست، بلکه خطای بازیابی در معماری‌های RAG باعث ایجاد نتایجی فریب‌دهنده در مراحل ارزیابی می‌شود.
با پذیرش این تمایز، چندین تغییر معماری آشکار می‌شوند: بازرسی داده‌های تست ابهام را کم می‌کند؛ امتیازدهی چندمحوره باعث می‌شود اختلافات قابل‌توضیح باشند؛ مجموعه داوران عدم قطعیت را کاهش می‌دهد؛ و گزارش میزان اطمینان به تیم‌ها کمک می‌کند تا پس‌رفت‌های واقعی را از نویز تشخیص دهند. در نهایت، معیارهای پوشش (Coverage) میزان کلی اطمینان آماری ارزیابی را منتقل می‌کنند.
در نهایت، هدف گذار از ذهنیت «تابلوی امتیازات» به «ابزار تصمیم‌گیری» است. تست‌های سنتی برای اثبات صحت بودند، اما ارزیابی مدل‌های زبانی برای تخمین اطمینان است. ارزیابی قابل‌اعتماد به معنای حذف کامل عدم قطعیت نیست، بلکه درک درست آن برای اتخاذ تصمیمات مهندسی بهتر است.
برای پیاده‌سازی این موارد از امروز، داده‌های تست فعلی خود را برای یافتن موارد مبهم بازبینی کنید و ثبات داور خود را با اجرای سه باره ورودی‌های یکسان تست کنید تا واریانس پایه خود را بیابید.
گام بعدی شما
- داده‌های تست فعلی خود را برای یافتن موارد مبهم بازبینی کنید.
- ثبات داور خود را با اجرای سه باره ورودی‌های یکسان تست کنید تا واریانس پایه بیابید.
- سیستم امتیازدهی خود را از بازه‌های ذهنی به محورهای عینی و باینری تغییر دهید.
اما تأثیر این عدم قطعیت بر هزینه‌های استنتاج در مقیاس بالا حتی پیچیده‌تر است — به تحلیل ما درباره بهینه‌سازی هزینه‌های GPU مراجعه کنید.
گفتگو