Проверка достоверности фактов в ИИ-сводках: почему сдвиг парадигмы меняет контроль качества

Можно подобрать знакомые формулировки и всё равно перепутать причину со следствием, потерять оговорку или добавить подробность, которой в материале не было.

Исследования показывают, что до 30% автоматически созданных абстрактивных сводок могут содержать фактические несоответствия или галлюцинации. Это не значит, что каждая третья сводка обязательно опасна для читателя: речь идёт о результатах исследований, а качество зависит от задачи и способа оценки. Но сигнал понятен: проверка достоверности фактов в ИИ-сводках должна смотреть на смысл утверждений и их опору в исходном тексте. Именно поэтому контроль постепенно смещается от подсчёта совпадающих слов к семантической проверке.

Почему ROUGE и BLEU не замечают ошибку факта

ROUGE и BLEU появились как способы сравнивать сгенерированный текст с эталонным. В упрощённом виде они измеряют лексическое перекрытие: сколько слов или последовательностей слов совпало. Для оценки того, насколько система воспроизводит формулировки и содержание в среднем по набору примеров, это может быть полезно. Но совпадение слов ещё не подтверждает, что каждое утверждение в сводке следует из источника.

Допустим, в статье сказано, что ведомство предложило меру, которую ещё должен рассмотреть парламент. Сводка пишет, что ведомство меру уже ввело. В ней останется большая часть ключевых слов, а глагол и статус решения изменятся. Читатель получит совсем другой факт, хотя текст по-прежнему будет выглядеть близким к оригиналу.

Есть и обратная ситуация. Хороший пересказ может передавать мысль другими словами и потому иметь меньше буквальных совпадений с эталоном. Лексическая метрика сочтёт его хуже, хотя смысл сохранён. Получается, ROUGE и BLEU оценивают полезное, но ограниченное свойство текста: сходство формулировок. Фактическая правильность требует отдельной проверки.

Совпадение слов помогает оценить сходство текстов. Оно не отвечает на вопрос, правда ли утверждение в сводке.

Поэтому высокий балл ROUGE или BLEU не стоит читать как сертификат достоверности. Это скорее повод посмотреть, как система справилась с формой пересказа. Чтобы заметить ошибку факта в автоматическом дайджесте, нужно проверить, подтверждается ли каждое важное утверждение источником и не поменялся ли смысл по дороге к короткой версии.

Откуда берутся фактические искажения

Абстрактивная суммаризация создаёт новый текст, а не просто вырезает из статьи готовые предложения. Модель может сжать несколько фрагментов в одну фразу, заменить термин более привычным, связать факты, которые в источнике стояли рядом, но относились к разным событиям. На выходе получается гладкий текст, в котором одна деталь звучит правдоподобно, но не подтверждается исходником.

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

Сжатие само по себе тоже требует аккуратности. Если в статье приведены и результат исследования, и его ограничения, короткая версия может оставить результат, но выбросить оговорку о маленькой выборке или предварительном характере данных. Отдельные предложения тогда могут быть формально верны, однако общая картина для читателя окажется искажённой. Полнота и достоверность связаны, но это разные вещи: короткий текст способен содержать только подтверждённые факты и при этом упустить контекст, без которого их легко понять неправильно.

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

Как работает семантическая проверка

Современный подход начинается с разложения сводки на отдельные утверждения, или клеймы. Затем каждое из них сопоставляют с исходным материалом: подтверждает ли источник утверждение, противоречит ему или не даёт достаточных оснований для ответа. Здесь применяют методы естественного логического вывода — NLI.

На пальцах: система получает исходный фрагмент и утверждение из сводки, после чего оценивает отношение между ними. Если источник говорит, что запуск возможен в будущем, а сводка сообщает, что запуск уже состоялся, это противоречие. Если источник подтверждает факт прямо или смыслом, который из него следует, утверждение получает поддержку. Если в материале этого просто нет, надёжная проверка должна отличать отсутствие подтверждения от явного опровержения.

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

В фреймворках вроде Ragas результаты можно сводить к метрикам точности, полноты и F1. Здесь названия легко перепутать с бытовым смыслом, поэтому поясню. Точность показывает, насколько часто проверяемые утверждения получают поддержку источника. Полнота оценивает, насколько хорошо система охватывает нужные утверждения или обнаруживает релевантные элементы. F1 объединяет эти два показателя. Ни один из них сам по себе не гарантирует, что сводка сохранила весь критически важный контекст.

В Ragas сообщается о корреляции Пирсона 0,89 между оценками верности, выставленными моделью-судьёй, и экспертной человеческой разметкой. Это сильный результат для сопоставления оценок в конкретном бенчмарке, а не обещание, что любой дайджест будет проверен с такой же точностью. Метрика описывает связь между двумя наборами оценок, а не долю безошибочных сводок в реальной ленте новостей.

Что меняет LLM-судья

LLM-as-a-judge — подход, при котором языковую модель используют как оценщика: она сравнивает утверждения сводки с источником и выносит суждение по заданным правилам. По имеющимся данным, такой способ оценки с помощью промптинга превзошёл прежние специализированные классификаторы согласованности до 12,2 процентного пункта по точности бинарного определения ошибок. Для контроля качества это важный сдвиг: проверяющая модель может работать с перефразированными фразами и смысловыми связями, которые ускользают от простого сравнения слов.

Но слово «судья» не должно создавать иллюзию беспристрастного арбитра. Модель-оценщик сама может ошибиться, принять правдоподобный ответ за подтверждённый или не заметить важную оговорку. На решение влияют формулировка задания, порядок предъявления вариантов и то, насколько хорошо модель понимает предметную область. Если генератор и оценщик опираются на похожие языковые закономерности, одна ошибка может пройти мимо обеих систем.

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

Модель-судья полезна как дополнительный слой контроля. Последнее слово за тем, кто умеет увидеть, что именно источник подтверждает.

В рабочем потоке можно разделить проверку на несколько шагов:

1. Сначала выделить из сводки утверждения, которые можно проверить по источнику: числа, даты, действующих лиц, статусы решений и причинные связи.

2. Для каждого утверждения найти подтверждающий фрагмент или отметить, что опоры в исходном материале нет.

3. Отдельно проверить модальность и оговорки: «может», «предлагает», «планирует» не должны превращаться в «сделал» или «вступило в силу».

4. Перед публикацией просмотреть спорные и критически важные случаи, где ошибка заметно меняет картину события.

Этот процесс похож на проверку груза после выпуска: сам факт прохождения одного этапа ещё не закрывает вопрос о содержимом и документах. Если нужен отдельный разбор этой логики на примере таможни, можно посмотреть материал о проверке грузов после выпуска. Для новостной сводки смысл тот же: автоматическая отметка не заменяет понимания того, что именно проверяли и на каком основании.

Где алгоритмы пока теряют уверенность

В узкоспециализированных темах проверка даётся труднее. Медицинский, юридический или технический текст может содержать термины, оговорки и связи, которые требуют профильного знания. Исследования на клиническом наборе TreatFact показали, что современные методы фактчекинга и LLM-оценщики хуже выявляли несоответствия в медицинских сводках, чем в новостных текстах. Это важное предупреждение для команд, которые хотят одним универсальным оценщиком закрыть все разделы дайджеста.

Риск есть и в самом источнике. Если исходный материал неполный, противоречивый или пересказывает чужие данные без контекста, проверяющая система может подтвердить лишь соответствие сводки этому тексту. Она не устанавливает автоматически, верно ли утверждение в первоисточнике и отражает ли тот реальное положение дел. Проверка согласованности отвечает на вопрос о связи пересказа с источником; полноценная проверка факта может потребовать нескольких источников и редакторского решения.

Наконец, сводка может быть точной по каждому отдельному утверждению, но вводить в заблуждение выбором того, что оставить. Если из сложного материала взять только один подтверждённый тезис и опустить важные ограничения, семантическая согласованность не спасёт читателя от неполной картины. Здесь нужны отдельные критерии полноты и редакционная оценка значимости контекста.

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

Как читать показатели контроля качества

Если сервис сообщает, что проверяет сводки на достоверность, полезно выяснить, что именно означает его оценка. Один общий балл может объединять разные вещи или скрывать отдельные слабые места. Хорошая схема контроля показывает связь между утверждением и исходным фрагментом, а не просто выдаёт уверенное число.

При сравнении систем я бы обращала внимание на несколько вопросов:

• Разбирает ли система сводку на проверяемые утверждения или оценивает абзац целиком?
• Показывает ли она фрагмент источника, на который опирается?
• Различает ли противоречие и отсутствие подтверждения?
• Проверяет ли числа, даты, имена и статус события отдельно от общего смысла?
• Предусмотрен ли просмотр человеком для чувствительных тем и спорных случаев?

Ответы помогают понять, подходит ли оценка для редакционной работы. Высокая метрика на тестовом наборе полезна, но условия теста могут отличаться от реальной ленты: в ней меняются источники, тематика, длина материалов и характер формулировок. Отдельно нужно следить, чтобы автоматическая система не выдавала предположение за подтверждённый факт и не маскировала неопределённость красивой формулировкой.

Сдвиг от ROUGE и BLEU к NLI и LLM-судьям не отменяет старые метрики: они по-прежнему могут помогать оценивать форму и сходство пересказа. Просто у них появилась более подходящая компания для проверки смысла. Для читателя это хорошая новость, но не повод доверять любому сводному баллу вслепую. Если сервис показывает, откуда взялось утверждение, честно отмечает пробелы и оставляет человеку спорные случаи, такой контроль уже похож на заботу о качестве, а не на очередную красивую галочку в интерфейсе.