Великі мовні моделі розвивалися за трьома знайомими напрямами. Ми масштабуємо попереднє навчання (pre-training), подаючи їм більше тексту. Ми вдосконалюємо їх за допомогою постнавчання (post-training), щоб покращити здатність дотримуватися інструкцій. Ми вкладаємо обчислювальні ресурси під час тестування (test-time compute), щоб прискорити відповіді. Кожен із цих підходів спонукає модель генерувати кращу, швидшу та більш зв'язну прозу. Але жоден із них не вирішує складнішу проблему: як дізнатися, чи є ця проза насправді правильною.
Ця прогалина стає небезпечною. Модель може видати Python-скрипт із ідеальними відступами та логічною структурою, який видасть помилку в ту ж мить, як його запустять. Вона може з упевненим авторитетом пояснити медичний симптом і при цьому переплутати діагноз. Для чат-ботів це просто прикрі помилки. Для автономних агентів, що діють без нагляду людини, це критичні збої з реальними наслідками. Генерація та істина — це різні навички, і усвідомлення цієї різниці є першим кроком до створення систем, на які ми зможемо покластися.
Пастка генерації
Три стандартні шляхи масштабування оптимізують плинність мови та виконання завдань, а не епістемічну точність. Попереднє навчання формує широкі статистичні закономірності на трильйонах токенів. Постнавчання узгоджує модель із людськими вподобаннями, що часто винагороджує ввічливість і впевненість замість суворої правильності. Обчислення під час тестування надають моделі більше «токенів для роздумів» на запит, покращуючи форматування та покрокову структуру, але все одно сприймають кінцевий результат як монолог, а не перевірену відповідь.
Результатом є пастка плинності. Код виглядає чистим. Пояснення звучать авторитетно. Факти здаються правильними. Але зовнішній блиск маскує приховані помилки. Розробник, який без перевірки вставляє згенерований код у робочий конвеєр (production pipeline), ризикує зупинкою системи. Лікар, який використовує ШІ-асистента, несе серйозну відповідальність, якщо модель переплутає дві схожі взаємодії препаратів. Ми навчили моделі виконувати завдання, а не проводити аудит власних результатів.
Верифікація як вісь масштабування
Фреймворк під назвою LLM-as-a-Verifier повністю змінює підхід до проблеми. Замість того, щоб розглядати верифікацію як другорядну дію або окремий етап перевірки людиною, він розглядає самооцінку як четверту вісь масштабування поряд із попереднім навчанням, постнавчанням та прискоренням виведення (inference acceleration).
Ідея полягає в тому, щоб використовувати наявні логічні здібності моделі для оцінки власних результатів. Після генерації варіанту відповіді та сама модель робить крок назад і оцінює її. Це створює замкнений цикл: генерація, оцінювання, перегляд, повторення. Модель не перенавчається з новими вагами чи наборами даних. Вона просто застосовує свій інтелект до іншого шаблону запиту — на роль критика, а не автора.
Цей зсув важливий, оскільки він відокремлює можливості від надійності. Менша модель, яка добре верифікує, може перевершити більшу модель, яка цього не робить. Ви масштабуєте здатність до судження, а не лише кількість параметрів, і це змінює те, що система може безпечно виконувати.
Сила ймовірнісного оцінювання
Більшість спроб верифікації зазнають невдачі, тому що вони вимагають бінарного вердикту. Чи була ця відповідь правильною? Так чи ні. Такий грубий сигнал марнує інформацію. Відповідь може бути переважно правильною, але містити одну фатальну помилку, або переважно хибною, але мати одну слушну думку. Бінарна оцінка зводить усю цю нюансованість до одного біта.
LLM-as-a-Verifier замінює це ймовірнісним оцінюванням. Замість «пальця вгору» чи «пальця вниз» модель повертає безперервне число, наприклад 0,92. Ця десяткова частина має значення. Вона вказує на те, що модель майже впевнена у правильності відповіді, або ж відчуває щось підозріле при значенні 0,34. Люди, які керують системою, можуть встановлювати пороги. Усе, що нижче 0,60, може спровокувати автоматичну регенерацію. Діапазон від 0,60 до 0,85 може бути позна
Granularity. A score of 0.82 communicates something that "correct" does not. It implies near-certainty with residual doubt. In software engineering, that might mean the code compiles and handles the main case but possibly misses an edge condition. In medical reasoning, it might indicate a likely diagnosis that still requires a confirmatory test. Granular scores let downstream systems calibrate their response rather than treating all successes as equal.
Repetition. Because verification is cheap compared to generation, you can run it multiple times with slight prompt variations or temperature settings. If three independent checks return 0.91, 0.89, and 0.93, you have a consensus. If they scatter widely, say 0.91, 0.42, and 0.87, you know the model is uncertain and the answer needs work. Majority voting among binary judges is blunt. Averaging continuous scores surfaces ambiguity.
Decomposition. Complex tasks rarely fail everywhere at once. A robotics task might break down into perception, planning, and motor execution. A software engineering task might separate into algorithm design, implementation, and testing coverage. Probabilistic scoring lets the verifier assess each sub-component individually. You learn not just that the answer is weak, but where it is weak. That diagnostic precision makes repair faster and more targeted.
Results in Difficult Domains
The framework's utility shows up