Fact-checking AI: где ломается достоверность ответов
Генеративная модель предсказывает правдоподобное продолжение, а не истинное утверждение. Поэтому недостоверные ответы модели приходят тем же тоном и с той же уверенностью, что и верные, и ошибку не видно ни по формулировке, ни по структуре — для читателя это готовый факт.
Ломается достоверность в предсказуемых местах: модель подставляет название нормативного акта или номера пункта договора, которых не существует, пересказывает устаревшую редакцию документа, смешивает двух клиентов или две версии регламента, достраивает цифры и даты, которых нет во входных данных. Галлюцинации в ответах редко выглядят абсурдно — обычно это аккуратно оформленная справка.
Дороже всего обходится то, что источник ответа отсутствует. Модель не показывает фрагмент, из которого взяла утверждение, а приведённая цитата может оказаться перефразом или выдумкой целиком. Проверка фактов в AI-ответах превращается в ручной поиск: каждое утверждение нужно найти в первоисточнике и сверить.
Оценка уверенности, которую возвращает модель, не помогает: она слабо связана с правильностью, поэтому порог «отбрасывать сомнительное» не настраивается. Дальше развилка — либо сотрудник перепроверяет каждый абзац и инструмент теряет смысл, либо ответ уходит клиенту непроверенным.
Разбираем, где именно теряется достоверность — при извлечении данных из документов, ответах по базе знаний и сжатии длинных текстов — и что закрывает каждое из этих мест.
Что даёт проверка фактов: измеримые эффекты внедрения
Метрики считаем на размеченной контрольной выборке вопросов — той же, на которой потом принимаем релиз. Так эффект от проверки фактов видно до выката в прод, а не по жалобам пользователей.
- Доля недостоверных ответов. На контрольной выборке из нескольких сотен вопросов она падает с 10-20% до 2-4%: каждое утверждение в ответе либо подтверждено фрагментом базы, либо помечено как предположение и переформулировано.
- Доля утверждений с подтверждённым источником. Целевой уровень — 90% и выше: у каждого факта в ответе есть ссылка на конкретный документ или раздел, и её видно в интерфейсе. Остаток — не «галлюцинации», а явно помеченные пробелы в данных.
- Разбор спорных ответов. В отдельную очередь попадает 3-6% ответов — те, где проверка не смогла подтвердить факт или оценка уверенности ниже порога. Разбор идёт по журналу с сохранённым контекстом, среднее время реакции — часы, а не дни.
- Качество базы знаний. Проверка подсвечивает, какие фрагменты базы чаще всего опровергают ответы: устаревшие регламенты, дубли, обрывки таблиц. После чистки доля ответов, требующих ручной правки, снижается в разы — это уже работа с причиной, а не со следствием.
- Скорость и предсказуемость выпуска. Оценка на размеченном наборе (RAGAS и аналогичные метрики верности источнику) встраивается в контур выката: регресс видно до релиза, и обновление модели или базы не проходит, если доля подтверждённых ответов просела.
Способы проверки фактов: сравнение технических подходов
Подход выбирают по двум параметрам: на каком шаге конвейера стоит проверка и какой запас времени есть до выдачи ответа. Проверка на лету укладывается в задержку диалога, но успевает сверить только заранее размеченные утверждения — многошаговые выводы она не разбирает.
Проверка по базе знаний даёт предсказуемую точность на закрытом домене: регламенты и справочники лежат у заказчика, ответ сверяется с ними, а не с открытым интернетом. Внешние источники расширяют охват, но добавляют зависимость от доступности и разметки чужих страниц. Проверка постфактум снимает ограничение по времени и разбирает ответ целиком, зато не защищает от уже отданной формулировки.
| Подход | Когда подходит | Где упирается в ограничения |
|---|---|---|
| Проверка на лету | Диалог, где важна задержка: поддержка, ассистент по регламентам | Сверяет только размеченные утверждения; с ростом глубины растёт и задержка |
| Проверка по базе знаний | Закрытый домен с устойчивым набором фактов и правил | Нужна постоянная актуализация базы; вне домена молчит |
| Внешние источники | Открытые темы, где факты часто меняются и нужен широкий охват | Зависит от доступности чужих страниц, даёт ложные срабатывания |
| Проверка постфактум | Массовые генерации, отчёты, публикации с вычиткой | Не спасает уже выданный ответ, требует очереди и разбора спорных случаев |
На практике подходы комбинируют: быстрый слой закрывает типовые утверждения, а спорные уходят в отложенную сверку с базой и внешними источниками. Как именно распределяются слои под ваш сценарий — разбираем на этапе проектирования.
Этапы внедрения системы проверки фактов
Работу начинаем с аудита контура ответов: смотрим, на каких запросах модель выдаёт проверяемые утверждения — числа, даты, имена, цитаты, ссылки на нормы, — и какова их доля. Дальше фиксируем, где у ответа есть источник истины, а где его нет: без этого система проверки фактов начнёт спорить с корректными ответами. По итогам аудита согласуем схему проверки: какие утверждения извлекаются из текста, по каким источникам сверяются и какой вердикт считается достаточным.
- Разметка набора для оценки. Собираем ответы из реальных сценариев, размечаем утверждения как подтверждённые, опровергнутые и непроверяемые; расхождения между аннотаторами разбираем отдельно, иначе метрика приёмки будет измерять шум.
- Схема проверки. Определяем порядок: извлечение утверждений, поиск по корпусу источников, сверка с фрагментом, ранжирование совпадений. Каждый вердикт хранит ссылку на фрагмент-основание.
- Настройка правил. Пороги уверенности и поведение при неоднозначности: ответ переформулируется, получает оговорку, ссылку или уходит на ручную проверку. Тон ответа понижается вместо категоричного утверждения.
- Встраивание в контур ответов. Проверка запускается до выдачи, кэширует повторяющиеся утверждения и журналирует вердикты, чтобы инцидент можно было разобрать постфактум.
- Приёмка на размеченном наборе. Считаем долю верных вердиктов, ложные подтверждения и долю отказов от утверждения — по ним и принимаем работу.
- Передача регламентов. Отдаём правила пополнения источников, порядок обновления корпуса и разбор инцидентов, чтобы система не расходилась с реальностью.
Что передаём вместе с решением: конфигурации и регламенты
Решение передаётся не как «чёрный ящик», который можно только целиком заменить. Вместе с системой остаётся набор артефактов: конфигурации, правила разметки, эталонные примеры и регламент сопровождения. Команда заказчика может сама править список источников, менять порог достоверности и добавлять спорные случаи — без нас и без переписывания логики.
- Конфигурации проверки — какие утверждения извлекаются из ответа, какие источники считаются авторитетными и в каком приоритете, что делать при расхождении между ними. Поведение при нехватке данных задаётся явно: пометка «требует подтверждения» вместо уверенного тона.
- Правила разметки — единый словарь меток: подтверждено источником, опровергнуто, данных нет. Фиксируем, как оформляется ссылка и как размечается частично верное утверждение, чтобы вердикты разных людей сходились.
- Порог достоверности и матрица решений — при каком значении ответ уходит пользователю, при каком уходит на доработку или к оператору. Порог настраивается отдельно по типам запросов: там, где цена ошибки выше, планка жёстче.
- Эталонный набор для регрессии — несколько сотен вопросов с заранее согласованными вердиктами. Прогон после каждой правки правил или источников показывает, не просела ли точность и на каких темах появились новые расхождения.
- Документация по проверке фактов — где лежат источники, как и с какой периодичностью обновляются, как читается отчёт о срабатываниях, что означает каждая метка в ответе.
- Регламент сопровождения — кто пересматривает источники, в каком порядке заводится спорный случай, срок реакции и порядок отката к предыдущей версии правил.
- Журнал срабатываний и отчётность — доля ответов с пометкой, частые расхождения, темы, где система чаще всего отправляет на проверку. На этих данных пересматриваются правила, а не на ощущениях.
Всё перечисленное хранится в репозитории заказчика и версионируется: видно, что и когда менялось и к какому результату привело. Опишите задачу — вернёмся с оценкой и планом, включая состав этих артефактов под ваш контекст.
Кейс: как снизили долю недостоверных ответов вдвое
Клиент — сервис поддержки с ассистентом по внутренней базе знаний: регламенты, договоры, инструкции. На старте мы взяли выборку из 400 спорных вопросов — тех, где документы противоречат друг другу или часть версий устарела. Доля недостоверных ответов на ней держалась около 19%: модель уверенно смешивала действующую редакцию с архивной. Каждый пятый пользователь возвращался с переспросом — прямой индикатор, что ответ ему не помог.
Что изменили: ответ не уходит в чат, пока каждое утверждение не привязано к фрагменту-источнику. Система хранит для него документ, раздел и дату актуализации, а при конфликте версий выбирает действующую и помечает расхождение. Если подтверждения нет, ассистент отвечает «в базе нет подтверждения» и передаёт вопрос владельцу документа — вместо того чтобы достроить ответ по догадке.
Метрики после: недостоверных ответов — 8%, доля ответов с явным источником — 96%, повторные обращения с переспросом упали почти втрое. Около 7% запросов закрываются честным отказом, и это осознанный обмен: разобрать пробел в базе надёжнее, чем объяснять пользователю неверную цифру. Достоверность считаем на регресс-наборе из тех же спорных вопросов, разметку ведём вручную — RAGAS даёт метрики привязки к контексту, но решение «достоверно или нет» остаётся за человеком.
Набор пополняется из реальных обращений: спорный ответ уходит в разметку и в следующий прогон. Поэтому при обновлении базы доля недостоверных не откатывается назад — новые документы приходят уже с проверкой на привязку к источнику.
Чем fact-checking AI на лету отличается от проверки постфактум?
Проверка в момент ответа встроена в сам цикл генерации: система формирует утверждение, ищет подтверждение в подключённых источниках, сверяет фрагмент и только затем отдаёт текст пользователю. Если опоры нет — формулировка переписывается или ответ честно помечается как неподтверждённый. Плата за это — задержка ответа: каждое утверждение добавляет обращение к базе, а иногда и повторную генерацию, поэтому в потоковом выводе пауза становится заметной.
Отложенная проверка развязывает эти узлы: ответ уходит сразу, а разбор идёт асинхронно — по логам, с разметкой спорных фрагментов, поиском источников и, где нужно, ревью специалиста. Полнота здесь выше: можно разобрать ответ целиком, а не первые абзацы, и оценить его в контексте всей сессии. Ограничение другое — ошибка уже дошла до пользователя.
Отсюда разная цена ошибки. Там, где неверный факт видит клиент или проверяющий — в справке, расчёте, отраслевой подсказке — дешевле задержать ответ, чем отзывать его. Во внутренних сценариях: черновики, выжимки, сортировка обращений — отложенная проверка даёт приемлемое качество без паузы в интерфейсе.
На практике режимы комбинируют: быстрые правила-ограничители ловят явные расхождения и заставляют систему честно сказать «не знаю», а полный разбор идёт асинхронно и возвращается в настройки — в набор источников, в формулировки, в пороги уверенности. Метрики сравнения простые: доля ответов с неподтверждёнными утверждениями и доля случаев, когда ответ пришлось перегенерировать.
Частые технические вопросы по системе проверки фактов
Перед стартом инженерная команда проверяет одно и то же: откуда берутся подтверждения, сколько проверка добавляет к времени ответа, как встраивается в работающий ассистент и по каким метрикам считать результат. Ниже — пять сомнений, которые всплывают чаще всего.
Чем подтверждается утверждение?
Утверждение помечается только при точном совпадении с фрагментом источника, ссылка на него сохраняется рядом с ответом. Если документ изменился, связанные ответы уходят на повторную сверку, а не остаются в силе.
Вырастет ли время ответа?
Быстрые правила и сверка с кэшем уже подтверждённых утверждений идут в общем потоке, тяжёлые случаи уходят в фоновую очередь. Типовой ответ остаётся в прежнем диапазоне времени отклика.
Подключится ли к готовому ассистенту?
Генерацию переписывать не нужно: проверка ставится после неё и получает текст ответа с метаданными запроса. Первый этап — теневой режим, где проверка только логирует результат и ничего не блокирует.
Как измерить результат?
До старта фиксируем базовые значения на размеченном наборе: доля подтверждённых утверждений, доля ложных срабатываний, доля ответов, ушедших на доработку. После запуска считаем те же метрики на том же наборе.
Что если проверка мешает?
Переключатель на уровне запроса и списка исключений возвращает прежнее поведение без отката релиза. Срабатывания логируются, поэтому слишком строгое правило правится точечно, а не отключением всей системы.
Обсудим вашу задачу: с чего начнём проверку фактов
Чтобы обсудить задачу предметно, готовый технический документ не нужен — достаточно контекста: где живут ответы модели, кто отвечает за их качество и что в вашем случае считается ошибкой. Первый разговор ведёт инженер, который будет внедрение сопровождать, а не менеджер — так оценка и план работ получаются реалистичными.
На первом разговоре уточняем входные данные:
- Где генерируются ответы: чат поддержки, поиск по базе знаний, внутренний ассистент — и на каком языке идёт общение с пользователем.
- Какие источники считаем эталонными: регламенты, документация, отраслевые базы — и есть ли к ним программный доступ.
- Что считать ошибкой: выдуманный факт, устаревшая цифра, ссылка на несуществующий документ — и насколько критичен каждый класс.
- В каком режиме проверять: до выдачи ответа или пометкой сомнительных фрагментов уже после.
- Что уже накоплено: логи запросов и ответов, разметка, правила модерации — из них собираем набор проверок и тестовый корпус.
- Какие ограничения по данным: хранение, разграничение доступов, куда решение не должно отправлять запросы.
Опишите задачу в свободной форме — вернёмся с оценкой и планом работ: этапы, сроки и то, что потребуется с вашей стороны. Если часть входных данных пока не определена, это не блокирует старт: начинаем с доступного, остальное фиксируем по ходу проекта.
