Як оцінити галюцинації LLM: практичний чекліст

Слово «галюцинація» об'єднує різні дефекти, тому один hallucination rate не є надійним контрактом. Closed-book factuality питає, чи правильне твердження щодо перевіреного зовнішнього факту. Groundedness перевіряє, чи підтримує твердження надане джерело. Instruction faithfulness виявляє відхилення від вхідних даних, а self-consistency — суперечності між частинами однієї відповіді. Відповідь може бути grounded у помилковому документі або фактично правильною завдяки пам'яті моделі, хоча наданий контекст її не підтримує.

Почніть із decision contract: сценарій, типи claims, допустимі джерела, дата зрізу знань, ціна помилки, правильна abstention і дія після невпевненого результату. NIST використовує точніший термін confabulation для впевнено поданого помилкового контенту та наголошує, що ризик особливо важливий у довгих і доменно складних відповідях. Eval повинен називати конкретний failure mode, а не приписувати моделі людський намір.

• Factuality → claim відповідає авторитетному зовнішньому факту на зафіксовану дату.
• Groundedness → конкретний evidence span підтримує весь scope твердження.
• Consistency → відповідь не суперечить сама собі, історії діалогу чи структурованому input.
• Calibration → confidence або рішення відповісти узгоджується з фактичною частотою помилок.

Для коротких fact-seeking задач використовуйте питання з однозначною, стабільною відповіддю та evidence record, який містить URL або document ID, точний span, revision, verifiedAt і reviewer. SimpleQA демонструє корисний вузький дизайн: коротка відповідь і окремі verdicts correct, incorrect та not attempted. Але цей benchmark не доводить якість довгих відповідей, RAG або вашого домену, тому публічний набір є лише baseline, а не release certificate.

Додайте власні slices: відомий факт, рідкісний факт, неоднозначне питання, false premise, інформація після cutoff, застарілий документ, конфлікт джерел, no-answer та питання з кількома правильними формами. Для grounded workflow включіть supportive, irrelevant, partially supportive і contradictory context. Не генеруйте всі питання з тих самих chunks без перевірки: синтетичний набір часто повторює лексику джерела й робить retrieval та grading неприродно легкими.

Один verdict для абзацу приховує частково правильні відповіді. Claim extractor має виділити зовнішньо перевірні твердження, числа, дати, сутності, причинні зв'язки й attribution, зберігаючи їхній scope і qualifiers. Для кожного claim grader повертає supported, contradicted, unverifiable або not-in-context разом із evidence IDs. Citation existence не є доказом: span повинен entail-ити саме твердження, а не просто бути тематично близьким.

Перевіряйте claim coverage, factual precision, unsupported critical claims і contradiction rate окремо. Completeness extractor також треба калібрувати: якщо він пропустив вигадану дату, downstream score буде хибно високим. Вручну розмітьте representative slice, виміряйте agreement reviewers і розберіть disagreement taxonomy. Model grader корисний для масштабу, але його prompt, версія, порядок доказів і retry policy є частиною versioned eval, а не невидимою інфраструктурою.

Eval має дати моделі безпечний вихід: поставити уточнювальне питання, сказати, що доказів недостатньо, або передати задачу людині. Рахуйте correct, incorrect і abstained як окремі outcomes, а потім будуйте risk-coverage curve: як змінюється помилка серед відповідей, коли система обслуговує більшу частку запитів. Висока accuracy після відмови майже на все не є корисною без coverage, а високий answer rate може приховувати небезпечне вгадування.

Не покладайтеся лише на заявлений моделлю confidence. Калібруйте його на held-out cases через reliability bins або Brier score і порівнюйте з простими сигналами: наявністю достатнього evidence, disagreement кількох samples та verifier verdict. Semantic entropy досліджує variation на рівні значення й може виявляти confabulations, але автори прямо відмежовують їх від систематично однакових помилок. Тому uncertainty detector доповнює перевірку фактів, а не замінює її.

Порівнюйте candidate і baseline на тих самих frozen cases, окремо за мовою, доменом, довжиною, freshness, джерелом, наявністю retrieval і шкодою помилки. Загальний середній score може зрости завдяки простим trivia-питанням, поки фінансові дати або медичні qualifiers деградують. Для high-risk slice встановіть critical invariants: жодної вигаданої сутності, числа чи citation у фінальному результаті без перевірки або human review.

Тестуйте не лише модель. Pin версії corpus, retriever, search API, prompt, citation resolver, claim extractor, verifier і renderer. Ін'єктуйте empty retrieval, stale cache, broken source, partial document, суперечливі revisions і timeout verifier. Якщо evidence недоступний, UI не повинен перетворювати unverifiable claim на впевнену відповідь. Зберігайте redacted trace від input до rendered output, щоб розрізняти retrieval miss, generation defect, grader error і presentation bug.

• Dataset health → label agreement, source freshness, leakage і slice coverage.
• Answer quality → correct, incorrect, abstained та risk-weighted critical failures.
• Evidence quality → claim coverage, citation entailment і unsupported-claim rate.
• Operations → latency, grader disagreement і cost per verified answer.

Decision record фіксує dataset revision, джерела, model, prompt, pipeline versions, primary metric, segment thresholds, critical failures, owner і known-good rollback bundle. Promote вимагає практично значущої paired non-regression, проходження critical slices і прийнятної вартості перевіреної відповіді. Не оголошуйте універсальний безпечний threshold або перемогу моделі за vendor benchmark: ваші джерела, мови, traffic mix і наслідки помилки інші.

Rollout починається з offline replay, переходить у shadow evaluation, малий canary та risk-bounded production. Confirmed user correction після privacy review стає regression fixture; implicit click або відсутність скарги не доводять factuality. Якщо critical unsupported claim проходить до користувача, звузьте coverage, вимкніть affected model чи retrieval revision, поверніть known-good bundle і перевірте вже видані відповіді, де це вимагає домен. Production monitor має використовувати ту саму taxonomy, що й offline eval, щоб incident не губився між різними назвами метрик.