Оцінка впевненості LLM корисна лише після того, як ви визначите, що саме вона прогнозує, зафіксуєте протокол вимірювання та перевірите її на розмічених результатах власного завдання. Самозвітне «90%», логарифмічна ймовірність токена та дев’ять однакових відповідей із десяти семплів — це три різні сигнали. Жоден із них не дає універсальної ймовірності 0.9, що відповідь правильна.
Аудиторія: середній рівень — продуктові інженери, команди даних і технічні керівники, яким потрібно, щоб LLM відповідала, передавала запит на перевірку або утримувалася від відповіді.
Розглядайте необроблене число як ознаку, а не як рішення. Калібруйте його на відкладеному наборі даних, перевіряйте, як змінюється кількість помилок, коли ви відхиляєте відповіді з низькими оцінками, і встановлюйте детерміновані обмеження для будь-якої дії, яка може переміщувати кошти, розкривати дані або змінювати стан production.
Що вимірює оцінка впевненості LLM?
Оцінка впевненості LLM — це числовий сигнал, призначений для ранжування або оцінювання надійності результату моделі. Його значення залежить від способу отримання.
Щоб оцінка поводилася як калібрована ймовірність, результати, яким призначено 0.8, мають бути правильними приблизно у 80% випадків для того самого типу роботи. Це твердження потребує чотирьох деталей:
Приберіть будь-яку з цих деталей — і «впевненість 0.8» стає неоднозначною. Це може означати, що модель вважає формулювання ймовірним, послідовно повторює себе, виконала інструкцію надрукувати число або поставила одну відповідь вище за альтернативи. Ці властивості можуть корелювати з правильністю. Але вони не є самою правильністю.
Калібрування також відрізняється від дискримінації. Оцінка має добру дискримінацію, коли правильні відповіді зазвичай ранжуються вище за неправильні. Вона має добре калібрування, коли числові значення відповідають спостережуваним частотам. Система може бути корисною для ранжування, хоча її відсотки неправильні, або демонструвати прийнятне середнє калібрування, але не розділяти правильні й неправильні відповіді.
Три сигнали, які часто називають упевненістю
| Сигнал | Що він насправді спостерігає | Головна перевага | Основний режим відмови |
|---|---|---|---|
| --- | --- | --- | --- |
| Вербалізована впевненість | Число, яке модель генерує в тексті | Працює з black-box chat API | Чутливість до prompt, формату та походження відповіді |
| Log probabilities токенів | Умовна ймовірність згенерованих токенів | Дешево, коли API надає logprobs | Вимірює ймовірність послідовності, а не істинність |
| Узгодженість повторних семплів | Як часто семпльовані відповіді семантично збігаються | Працює без доступу до внутрішніх даних моделі | Дорожче й може стабільно помилятися |
Вибір між ними — інженерне рішення. Поєднання може допомогти, але ensemble все одно потребує оцінювання на цільовому завданні.
Вербалізована впевненість — це відповідь, яку потрібно отримати від моделі
Найпростіший підхід — запитати:
text Return your answer and the probability that it is correct from 0 to 1.
Це працює майже з будь-якою моделлю. Але значення впевненості стає частиною генерації. Формулювання prompt, шкала відповіді, наданий контекст і те, чи модель сама створила відповідь, можуть змінити результат.
Дослідження 2026 року перевірило три відкриті сімейства базових моделей та instruction-tuned моделей розміру 7–8B на чотирьох бенчмарках question-answering. Дослідники залишали prompt для вербальної впевненості незмінним, водночас змінюючи відповідь, яку оцінювали, токени відповіді, що надавали token score, і контекст перед цими токенами. Зміна контексту conditioning вплинула на порівняння калібрування вербальних оцінок і token score сильніше, ніж зміна estimator калібрування, і змінила сигнал, який виглядав кращим, у 9 із 12 instruction-tuned налаштувань за порівняннями ECE та Brier score. Коли моделі оцінювали надані відповіді, правдоподібні неправильні відповіді отримували майже таку саму вербальну впевненість, як і правильні надані відповіді. Тому автори описують обидва сигнали як поведінкові вимірювання, залежні від протоколу, а не як пряме зчитування невизначеності (Kim and Kang, 2026).
Цей результат не доводить, що кожна вербальна оцінка марна. Він показує, чому prompt на кшталт «чесно оцінюй свою впевненість» не може замінити набір даних для калібрування.
Token logprobs вимірюють імовірність наступного токена
Log probability фіксує, наскільки ймовірним був токен за умовного розподілу генерації моделі. Документація OpenAI визначає її як імовірність токена в певній позиції з огляду на попередній контекст; log probabilities послідовності можна підсумовувати для оцінювання або ранжування (OpenAI Cookbook). Відповідь GenerateContent у Google також надає середні log probabilities кандидатів і результати logprob на рівні токенів, коли вибрані API та модель це підтримують (Gemini API reference).
Це цінно для закритого вибору, наприклад `approve` проти `reject`. Ви можете зібрати масу ймовірності, призначену дозволеним міткам, а потім відкалібрувати цю оцінку. Інтерпретувати довгу вільну відповідь значно складніше. Токенізація, довжина відповіді, перефразування та prompt conditioning впливають на ймовірність послідовності.
Плавно сформульоване хибне твердження може мати високу ймовірність. Правильне, але незвичне ім’я може мати низьку ймовірність. Оцінка відповідає на запитання «Наскільки очікуваною була ця послідовність токенів тут?». Вона автоматично не відповідає на запитання «Чи правдиве це твердження?»
Повторне семплювання вимірює узгодженість
Кілька семплів моделі дають black-box сигнал послідовності. Якщо вісім із десяти відповідей виражають одну й ту саму відповідь, емпірична оцінка узгодженості дорівнює 0.8. Для вільних відповідей зазвичай потрібна семантична кластеризація, щоб перефразування рахувалися як одна відповідь.
Цей сигнал часто містить більше інформації, ніж один самозвіт, але має дві ціни. По-перше, десять генерацій коштують приблизно в десять разів більше output calls, перш ніж batching, caching або коротші prompt змінять арифметику. По-друге, узгодженість може бути впевнено неправильною, коли модель повторює ту саму помилкову думку.
Недавні дослідження демонструють обидва моменти. В одній роботі за липень 2026 року порівнювали вербальну впевненість, logit-based verifier і метод на основі семплювання під назвою SliCK для короткого factual та multi-hop question answering. У цьому середовищі SliCK досяг нижчої помилки калібрування та кращого ранжування правильних і неправильних відповідей, ніж два інші методи. Водночас він порушив тест узгодженості ймовірності на основі entailment у 31% оцінених випадків. Дослідження спиралося на семантичну кластеризацію за допомогою LLM judge, короткі answer benchmarks, одну основну модель із меншими cross-model підмножинами та припущення, що частота семплювання відображає переконання (Matta, Naphade, and Zou, 2026).
Практична інтерпретація вужча за твердження «семплювання розв’язує проблему впевненості». Узгодженість — корисний необроблений сигнал. Він усе одно залишається сигналом, який потрібно перевіряти за результатами.
*Production threshold має з’являтися після task-specific labels і перевірок калібрування, а не безпосередньо після output моделі.*
Чому правдоподібне число впевненості все одно може вводити в оману
Три недавні результати мають змінити те, як команди читають відсоток поруч із відповіддю LLM.
Точність і калібрування можуть змінюватися незалежно
ConfidenceBench оцінював prompted probabilities 15 frontier models на 200 приватних англомовних multiple-choice запитаннях із просторового міркування, високоточної математики, пошуку слів і питань, на які неможливо знати відповідь. Кожна модель відповідала на набір тричі. Бенчмарк використовував Brier score, який штрафує квадрат відстані між заявленою ймовірністю та бінарним результатом.
Ранжування моделей за калібруванням не просто повторювало ранжування за точністю. Автори повідомляють про найкращий Brier score 0.103, тоді як деякі оцінені системи отримали результат гірший за калібрований random baseline для чотирьох варіантів відповіді — 0.1875. Бенчмарк навмисно малий, приватний, лише англомовний і multiple-choice. Його вербальні оцінки можуть відображати instruction following і framing prompt, тому ці числа не слід узагальнювати на long-form або multi-turn роботу (ffrench-Constant et al., 2026).
Вимірюйте калібрування безпосередньо. Не виводьте його із загальної benchmark accuracy.
Протокол вимірювання може змінити висновок
Оцінка прив’язана до конкретного pipeline. Якщо команда змінює prompt, snapshot моделі, формат відповіді, candidate labels, context window, temperature або агрегацію logprob, вона змінила вимірювальний інструмент.
Фіксуйте ці рішення з кожним результатом оцінювання. Необроблені метрики активності code-agent також потребують системного та evaluation context, перш ніж вони щось скажуть про надійність. Якщо змінюється prompt або модель, повторне калібрування — це release check, а не необов’язкове прибирання.
Калібрована оцінка все одно може провалитися на окремому зрізі
Середнє значення може приховати проблеми в одній мові, продукті, клієнтському сегменті, типі документа або довжині відповіді. Класифікатор звернень до служби підтримки може виглядати загалом каліброваним, оскільки поширені питання про billing домінують у test set, тоді як рідкісні security tickets залишаються надмірно впевненими.
Завжди перевіряйте зрізи з достатньою кількістю прикладів для обґрунтованого висновку. Якщо вибірки малі, повідомляйте про невизначеність, а не сприймайте шумний показник як факт.
Відтворюваний workflow калібрування впевненості LLM
Наведений нижче workflow навмисно невеликий. Його можна виконати до впровадження складнішої framework для невизначеності.
1. Визначте подію та дію
Напишіть одне речення, завершивши цей шаблон:
Приклади:
Уникайте подій на кшталт «відповідь хороша». Їх неможливо послідовно розмічати.
Для дій із незворотними наслідками впевненість не повинна замінювати authorization. Модель може допомогти вибрати шлях, але AI agent permissions усе одно мають забезпечувати дозволені ресурси, аргументи, правила approval і receipts.
2. Створіть task-specific holdout set
Зберіть репрезентативні inputs, які не використовувалися для налаштування prompt або mapping калібрування. Додайте:
За можливості маркуйте правильність детермінованим verifier. Для суб’єктивних завдань використовуйте письмову rubric та adjudication. Оцінка впевненості не може бути більш обґрунтованою, ніж її outcome labels.
Почніть із достатнього обсягу даних, щоб виявити грубе неправильне калібрування, а потім розширюйте набір навколо важливих зрізів і thresholds. Малий benchmark може спрямувати дослідження, але не може виправдати production threshold для high-stakes сценарію.
3. Зберігайте необроблений сигнал, не змінюючи протокол
Зберігайте:
Не округлюйте значення до оцінювання. Модель, яка видає лише `0.7`, `0.8` і `0.9`, має оцінюватися як три грубі buckets, а не подаватися як точне вимірювання ймовірності.
4. Обчисліть Brier score і reliability table
Для бінарної правильності Brier score має вигляд:
text mean((confidence - outcome)²)
Менше — краще, але показнику потрібні baseline і порівнюваний dataset. Reliability table полегшує виявлення помилки: згрупуйте схожі оцінки, а потім порівняйте середню оцінку кожної групи з її observed accuracy.
Цей Python script без зовнішніх залежностей читає `id,score,correct` із CSV-файлу:
python import csv
with open("predictions.csv", newline="") as source: rows = [ (float(row["score"]), int(row["correct"])) for row in csv.DictReader(source) ]
if not rows: raise SystemExit("predictions.csv has no rows")
brier = sum((score - correct) ** 2 for score, correct in rows) / len(rows) print(f"Brier score: {brier:.4f}")
bin_count = 10 bins = [[] for _ in range(bin_count)]
for score, correct in rows: if not 0 <= score <= 1 or correct not in (0, 1): raise ValueError("score must be 0..1 and correct must be 0 or 1") index = min(int(score * bin_count), bin_count - 1) bins[index].append((score, correct))
print("range,count,mean_score,accuracy,gap") for index, values in enumerate(bins): if not values: continue mean_score = sum(score for score, _ in values) / len(values) accuracy = sum(correct for _, correct in values) / len(values) lower = index / bin_count upper = (index + 1) / bin_count print( f"{lower:.1f}-{upper:.1f},{len(values)}," f"{mean_score:.3f},{accuracy:.3f},{mean_score - accuracy:+.3f}" )
Таблиця має описовий характер. Межі bins можуть змінювати підсумки на кшталт ECE, особливо на малих наборах. Використовуйте разом Brier score, reliability view і metric, орієнтовану на дію, замість оптимізації одного графіка.
5. Обирайте thresholds з огляду на ризик і coverage
Threshold 0.8 не має універсального значення. Оцініть, що відбувається, коли система приймає лише outputs із оцінкою не нижче кожного candidate threshold:
python print("threshold,coverage,accepted_accuracy") for threshold in (0.5, 0.6, 0.7, 0.8, 0.9): accepted = [ correct for score, correct in rows if score >= threshold ] coverage = len(accepted) / len(rows) accuracy = sum(accepted) / len(accepted) if accepted else float("nan") print(f"{threshold:.1f},{coverage:.3f},{accuracy:.3f}")
Це створює базове уявлення про risk–coverage. Підвищення threshold може зменшити кількість помилок серед прийнятих випадків, але водночас передає більше роботи fallback handling. Обирайте threshold з огляду на вартість false acceptance, false rejection, review, latency та шкоди користувачеві.
Використовуйте щонайменше три результати, якщо продукт це підтримує:
6. Перевіряйте drift і зміни протоколу
Запускайте holdout після:
Повторне семплювання та глибше reasoning також додають compute. Цей компроміс має бути частиною evaluation: порівнюйте зменшення кількості помилок із latency і token cost, а не припускайте, що більше reasoning tokens завжди варті витрат.
Який метод оцінювання впевненості обрати?
| Ситуація | Почніть із | Перевірте перед deployment |
|---|---|---|
| --- | --- | --- |
| Closed-label classification із logprobs | Масу ймовірності дозволених labels | Калібрування, class imbalance, чутливість до prompt і label-token |
| Black-box short-answer QA | Repeated sampling плюс semantic agreement | Стабільно неправильні відповіді, помилки кластеризації, додаткові витрати |
| Обмеження latency одного виклику | Raw score плюс learned calibration mapping | Drift, performance на зрізах, retraining mapping |
| Long-form answers | Claim-level support і перевірки невизначеності | Повноту, якість citations, unsupported confident claims |
| Незворотна tool action | Deterministic policy та human approval за потреби | Ніколи не авторизуйте дію лише на основі confidence |
Open-source libraries можуть зменшити обсяг реалізації. Наприклад, UQLM надає black-box consistency, white-box token-probability, judge, ensemble і scorers для long text. Його документація також чітко показує компроміси latency та доступу: consistency methods потребують більше calls, тоді як white-box methods вимагають logprobs (UQLM documentation). У липні 2026 року repository усе ще отримував releases, зокрема fixes у v0.6.4, що є сильнішим сигналом підтримки, ніж сама кількість lifetime stars (UQLM v0.6.4).
Library надає estimators. Вона не надає labels, визначення завдання, tolerance до ризику або production monitoring, які роблять threshold обґрунтованим.
Чого поточні дослідження не встановлюють
Наведені дослідження не доводять, що один метод перемагає в усіх застосуваннях LLM.
Research може визначити candidate signals. Перевіряйте повну систему на роботі, яку вона фактично виконуватиме.
Часті запитання
Чи точні оцінки впевненості LLM?
Іноді вони корелюють із правильністю, але точність залежить від моделі, завдання, методу оцінювання, prompt і evaluation distribution. Розглядайте необроблену оцінку без калібрування як ranking feature. Перевірте її на розмічених результатах, перш ніж трактувати як ймовірність.
Чи є token logprobs тим самим, що й confidence?
Ні. Token logprob — це умовна ймовірність токена з огляду на його контекст. Вона може підтримувати оцінку впевненості, особливо для closed-label tasks, але автоматично не є ймовірністю того, що вільна відповідь фактично правильна.
Який LLM confidence threshold слід використовувати?
Універсального threshold не існує. Обирайте його на основі held-out risk–coverage analysis, яка враховує вартість неправильного прийняття, manual review, abstention і втраченої автоматизації. Повторно перевіряйте його після змін моделі, prompt або розподілу даних.
Перевірка тверджень
| Твердження | Статус | Докази та уточнення |
|---|---|---|
| --- | --- | --- |
| Вербальна впевненість і token probability — це вимірювання, залежні від протоколу | Підтверджено | Kim and Kang змінювали походження відповіді, token readout, conditioning context і estimator у open model families та QA datasets. |
| Conditioning context змінив перевагу сигналу в 9 із 12 instruction-tuned settings за порівняннями ECE та Brier | Підтверджено | Повідомляється в multi-metric analysis роботи *Asking Is Not Enough*. |
| Logprobs вимірюють умовну ймовірність токенів | Підтверджено | Документація OpenAI та Google API визначає поля token/candidate log-likelihood. |
| Sampling agreement може перевершувати single self-reports у short factual QA | Із застереженням | SliCK продемонстрував це в описаних експериментах 2026 року; результат не є універсальним і залежить від clustering та sampling assumptions. |
| SliCK порушив entailment consistency test у 31% оцінених випадків | Підтверджено | Повідомляється в *Rethinking Uncertainty Evaluation in Large Language Models*. |
| Accuracy не визначає calibration | Підтверджено | ConfidenceBench повідомляє rankings і Brier scores, які не просто відповідають model accuracy. |
| Найкращий заявлений Brier score ConfidenceBench становив 0.103 | Підтверджено | Результат є середнім за трьома запусками на приватному benchmark із 200 запитань, а не загальною оцінкою моделі. |
| Brier score — це mean squared error між probability та binary outcome | Підтверджено | ConfidenceBench визначає binary Brier score, використаний у своєму evaluation. |
| UQLM активно підтримувався в липні 2026 року | Підтверджено | GitHub release v0.6.4 опубліковано 26 липня 2026 року. |
| Production threshold має бути task-specific | Із застереженням | Це практична інтерпретація доказів protocol sensitivity і calibration, а не універсальна теорема для кожного застосування. |