Как оценивать галлюцинации 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 не доказывает качество long-form ответов, RAG или вашего домена, поэтому публичный набор — лишь baseline, а не сертификат release.

Добавляйте собственные 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 не является доказательством: 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 slices задайте critical invariants: ни одна вымышленная сущность, число или citation не должны попадать в финальный результат без проверки или human review.

Тестируйте не только модель. Зафиксируйте версии corpus, retriever, search API, prompt, citation resolver, claim extractor, verifier и renderer. Инъецируйте empty retrieval, stale cache, broken source, partial document, конфликтующие revisions и verifier timeout. Если 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. Подтвержденная user correction после privacy review может стать regression fixture; implicit click или отсутствие жалобы не доказывают factuality. Если critical unsupported claim дошел до пользователя, сузьте coverage, отключите затронутую model или retrieval revision, верните known-good bundle и проверьте уже выданные ответы там, где этого требует домен. Production monitor должен использовать ту же taxonomy, что и offline eval.