مدل‌های زبانی بزرگ در سه بُعد آشنا رشد کرده‌اند. ما پیش‌آموزش (pre-training) را با دادن متن‌های بیشتر به آن‌ها گسترش می‌دهیم. ما آن‌ها را با پس‌آموزش (post-training) اصلاح می‌کنیم تا توانایی پیروی از دستورالعمل‌ها را تقویت کنیم. ما محاسبات زمان تست (test-time compute) را افزایش می‌دهیم تا سرعت پاسخ‌دهی را بالا ببریم. هر یک از این‌ها مدل را به سمت تولید متنی بهتر، سریع‌تر و منسجم‌تر سوق می‌دهد. اما هیچ‌کدام مستقیماً به یک مشکل دشوارتر نمی‌پردازند: اینکه بدانیم آیا آن متن واقعاً درست است یا خیر.

این شکاف در حال تبدیل شدن به یک خطر است. یک مدل می‌تواند اسکریپت پایتونی با تورفتگی (indentation) بی‌نقص و ساختار منطقی تولید کند که به محض اجرا با خطا مواجه شود. می‌تواند یک علامت پزشکی را با اقتداری آرام توضیح دهد، اما تشخیص را برعکس ارائه کند. برای چت‌بات‌ها، این‌ها باگ‌های خجالت‌آوری هستند؛ اما برای عامل‌های خودمختار (autonomous agents) که بدون نظارت انسانی عمل می‌کنند، این‌ها شکست‌هایی با پیامدهای واقعی هستند. تولید کردن و حقیقت داشتن، دو مهارت متفاوت هستند و تشخیص این تمایز، اولین قدم برای ساخت سیستم‌هایی است که بتوان به آن‌ها اعتماد کرد.

تله‌ی تولید

سه مسیر استاندارد مقیاس‌پذیری، بر اساس روانی متن و تکمیل وظیفه بهینه‌سازی شده‌اند، نه دقت معرفت‌شناختی (epistemic accuracy). پیش‌آموزش، الگوهای آماری گسترده‌ای را در میان تریلیون‌ها توکن ایجاد می‌کند. پس‌آموزش، مدل را با ترجیحات انسانی همسو می‌کند، که اغلب به جای صحت دقیق، به ادب و اعتمادبه‌نفس پاداش می‌دهد. محاسبات زمان تست، توکن‌های فکری بیشتری را در هر درخواست به مدل اختصاص می‌دهد و باعث بهبود قالب‌بندی و ساختار گام‌به‌گام می‌شود، اما همچنان با خروجی نهایی مانند یک تک‌گویی (monologue) برخورد می‌کند تا یک پاسخ بازبینی‌شده.

نتیجه، یک «تله‌ی روانی» است. کد تمیز به نظر می‌رسد. توضیحات مقتدرانه به گوش می‌رسند. واقعیت‌ها درست به نظر می‌آیند. اما صیقل ظاهری، خطاهای زیربنایی را پنهان می‌کند. توسعه‌دهنده‌ای که کد تولیدشده را بدون بررسی دقیق در یک خط تولید (production pipeline) قرار می‌دهد، با خطر از کار افتادن سیستم مواجه است. پزشک‌ای که از یک دستیار هوش مصنوعی استفاده می‌کند، اگر مدل دو تداخل دارویی مشابه را با هم اشتباه بگیرد، با مسئولیت‌های حقوقی جدی روبرو می‌شود. ما مدل‌ها را برای اجرا کردن آموزش داده‌ایم، نه برای حسابرسی (audit) خودشان.

تأیید به عنوان یک محور مقیاس‌پذیری

چارچوبی به نام LLM-as-a-Verifier مسئله را کاملاً بازتعریف می‌کند. این چارچوب به جای اینکه تأیید را به عنوان یک موضوع ثانویه یا یک مرحله‌ی بررسی انسانی جداگانه در نظر بگیرد، خودارزیابی را به عنوان چهارمین محور مقیاس‌پذیری در کنار پیش‌آموزش، پس‌آموزش و شتاب‌دهی استنتاج (inference acceleration) قلمداد می‌کند.

ایده این است که از ظرفیت استدلال موجود در مدل برای قضاوت درباره خروجی‌های خودش استفاده شود. پس از تولید یک پاسخ احتمالی، همان مدل یک قدم به عقب برمی‌دارد و آن را ارزیابی می‌کند. این کار یک حلقه‌ی بسته ایجاد می‌کند: تولید، امتیازدهی، بازبینی، تکرار. مدل با وزن‌ها یا مجموعه‌داده‌های جدید بازآموزی نمی‌شود؛ بلکه صرفاً هوشی را که از قبل دارد، در قالب یک الگوی دستورالعمل (prompt template) متفاوت به کار می‌گیرد؛ یعنی در نقش یک منتقد به جای یک نویسنده.

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

قدرت امتیازدهی احتمالی

اکثر تلاش‌ها برای تأیید شکست می‌خورند زیرا خواهان یک حکم دوگانه (binary) هستند. آیا این پاسخ درست بود؟ بله یا خیر. این سیگنال خام، اطلاعات را هدر می‌دهد. یک پاسخ ممکن است عمدتاً درست باشد اما یک نقص مرگبار داشته باشد، یا عمدتاً غلط باشد اما یک نکته‌ی ارزشمند در آن باشد. یک امتیاز دوگانه تمام این ظرافت‌ها را در یک بیت خلاصه می‌کند.

LLM-as-a-Verifier این روش را با امتیازدهی احتمالی جایگزین می‌کند. به جای لایک یا دیس‌لایک، مدل یک عدد پیوسته مانند 0.92 برمی‌گرداند. آن عدد اعشاری معنایی با خود دارد. این عدد به شما می‌گوید که مدل تقریباً مطمئن است پاسخ درست است، یا اینکه در عدد 0.34 شک دارد که چیزی اشتباه است. انسان‌هایی که سیستم را مدیریت می‌کنند می‌توانند آستانه‌ها را تعیین کنند. هر چیزی زیر 0.60 ممکن است باعث بازتولید خودکار شود. بازه‌ای بین 0.60 تا 0.85 ممکن است برای بررسی انسانی علامت‌گذاری شود. بالای 0.90، سیستم به صورت خودمختار عمل می‌کند.

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

سه مزیت کاربردی

این چارچوب قدرت خود را از سه ویژگی خاص می‌گیرد.

جزئی‌نگری. امتیاز ۰.۸۲ چیزی را منتقل می‌کند که واژه «درست» نمی‌تواند بیان کند. این امتیاز نشان‌دهنده اطمینانِ نزدیک به صددرصد، همراه با مقداری تردید باقی‌مانده است. در مهندسی نرم‌افزار، این ممکن است به این معنا باشد که کد کامپایل می‌شود و حالت اصلی را مدیریت می‌کند، اما احتمالاً یک حالت مرزی (edge condition) را نادیده گرفته است. در استدلال پزشکی، این می‌تواند نشان‌دهنده یک تشخیص احتمالی باشد که همچنان به یک آزمایش تأییدی نیاز دارد. امتیازهای جزئی‌نگرانه به سیستم‌های پایین‌دستی اجازه می‌دهند تا به جای برخورد یکسان با تمام موفقیت‌ها، پاسخ خود را کالیبره کنند.

تکرار. از آنجایی که تأیید (verification) در مقایسه با تولید (generation) ارزان است، می‌توانید آن را چندین بار با تغییرات جزئی در پرامپت یا تنظیمات دما (temperature) اجرا کنید. اگر سه بررسی مستقل، نتایج ۰.۹۱، ۰.۸۹ و ۰.۹۳ را برگردانند، شما به یک اجماع رسیده‌اید. اگر نتایج پراکندگی زیادی داشته باشند، مثلاً ۰.۹۱، ۰.۴۲ و ۰.۸۷، می‌دانید که مدل مردد است و پاسخ نیاز به اصلاح دارد. رأی‌گیری اکثریت در میان داوران باینری، ابزاری زمخت است. میانگین‌گیری از امتیازهای پیوسته، ابهام را آشکار می‌کند.

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

نتایج در حوزه‌های دشوار

کاربرد این چارچوب نمایان می‌شود