Как измеряют галлюцинации LLM: бенчмарки на фактичность

Языковая модель на вопрос «когда родился вымышленный писатель Иван Петровский» с равной уверенностью назовёт дату, город и название дебютного романа. Ни одного из этих фактов не существует. Проблему называют галлюцинациями, и именно её пытаются измерить бенчмарки фактичности — наборы задач, где ответ модели сверяют с проверяемой правдой. Google, OpenAI и независимые исследователи публикуют такие тесты один за другим, но единой методики, по которой можно сказать «эта модель врёт в X% случаев», пока нет.

Что именно проверяют бенчмарки фактичности

Фактичность (factuality) — это не одно свойство, а несколько разных. Модель может знать верный факт, но не удержать его в длинном ответе. Может знать, но исказить под давлением наводящего вопроса. Может честно не знать и всё равно выдумать. Каждый из этих случаев проверяется по-своему, поэтому бенчмарки делятся на группы.

Проверка знаний против выдумки

Самый известный ранний тест такого рода — TruthfulQA. Он собирает вопросы, на которые люди часто отвечают неверно из-за распространённых заблуждений, и смотрит, повторит ли модель миф или даст корректный ответ. Идея в том, что модель, обученная на текстах из интернета, впитывает и ошибки этих текстов.

Удержание фактов в длинном ответе

Отдельная категория проверяет не единичный факт, а насыщенный ответ на открытый вопрос вроде «расскажи биографию такого-то». Здесь ответ разбивают на отдельные утверждения и каждое сверяют с источником. Метрика показывает долю подтверждённых утверждений от общего числа — то есть насколько плотно ответ набит правдой, а не сколько раз модель угадала одно слово.

Опора на предоставленный контекст

Третий тип задач ближе к реальным продуктам с поиском и RAG^*. Модели дают документ и вопрос по нему, а затем проверяют, взяла ли она ответ из документа или дофантазировала из внутренних «знаний». Это критично для корпоративных сценариев: если ассистент по внутренней базе знаний придумывает пункты договора, которых в договоре нет, цена ошибки измеряется не баллами, а судебными исками.

Модель, которая честно говорит «я не знаю», по метрикам фактичности часто выигрывает у модели, которая знает больше, но не умеет молчать.

Почему одной цифры не хватает

Соблазн свести фактичность к проценту велик, но он обманчив. Результат сильно зависит от того, как устроена оценка.

• Кто судья. Часть ответов проверяют люди-разметчики, часть — другая языковая модель в роли арбитра. Модель-судья дешевле и быстрее, но у неё свои слепые зоны, и она может засчитать правдоподобную выдумку как факт.
• Как считают отказ. Если модель отказалась отвечать, это ошибка или разумная осторожность? Разные бенчмарки решают это по-разному, и итоговые баллы из-за этого несопоставимы напрямую.
• Свежесть данных. Факт «столица государства такая-то» стабилен, а «глава компании такой-то» устаревает за месяцы. Тест, собранный год назад, может штрафовать модель за верный по нынешним меркам ответ.
• Утечка в обучение. Если вопросы бенчмарка попали в обучающую выборку, модель их просто запомнила, а не «знает». Высокий балл тогда говорит о зубрёжке, а не о фактичности.

Как читать таблицы сравнения

Когда вендор публикует, что его модель набрала условные 90% на бенчмарке фактичности, важно понимать, что именно за этим стоит. Ниже — типы тестов и то, что реально измеряет каждый из них.

Практический вывод: сравнивать модели можно только на одном и том же бенчмарке с одной и той же методикой судейства. Цифра «90% на тесте A» и «85% на тесте B» ничего не говорят о том, какая модель честнее.

Что это значит для тех, кто внедряет LLM

Если вы строите продукт на языковой модели, чужие бенчмарки — только отправная точка. Реальную фактичность в вашем сценарии придётся мерить самостоятельно. Порядок примерно такой:

1. Соберите свой набор вопросов из настоящих запросов пользователей, а не из абстрактных примеров.
2. Зафиксируйте эталонные ответы с проверяемыми источниками.
3. Прогоните кандидатов на моделях и разметьте результаты — сначала руками, чтобы понять характер ошибок.
4. Отдельно считайте два числа: долю выдумок и долю неоправданных отказов. Оптимизация только по одному портит другое.
5. Повторяйте прогон после каждого обновления модели: поставщики меняют веса без предупреждения, и вчерашние результаты могут не воспроизвестись.

Для сценариев с поиском по своей базе фактичность повышается не сменой модели, а качеством извлечения документов. Если ассистент получает правильный фрагмент, соблазн выдумывать резко падает — и это дешевле, чем гнаться за самой большой моделью.

^* RAG (retrieval-augmented generation) — подход, при котором модель перед ответом получает релевантные документы из внешнего источника и опирается на них, а не только на знания, зашитые в её веса.