Фактчекинг ответов AI-систем
Задача не в том, чтобы «улучшить качество модели» — задача в том, чтобы ни один фактический ответ системы не попал к пользователю без верификации. Это инженерная задача с конкретной архитектурой, а не дообучение модели.
Почему модельная уверенность не равна точности
GPT-4, Claude 3.5, Gemini — все современные LLM генерируют ответы с субъективно высокой уверенностью даже при ошибочных фактах. Logprob близкий к 0 на галлюцинированном утверждении — стандартная ситуация. RLHF-дообучение усугубляет: модели обучены давать полные связные ответы, а не говорить «не знаю».
Это значит, что уверенность модели непригодна как сигнал для фильтрации. Нужен внешний верификатор.
Архитектура фактчекинга для продакшена
Декомпозиция на атомарные утверждения
Перед верификацией ответ разбивается на минимальные проверяемые утверждения (claims). «Компания основана в 1998 году и занимает 40% рынка» — это два утверждения. Используем LLM-вызов с structured output (JSON Schema) или NLP-пайплайн на основе spaCy + coreference resolution.
Без декомпозиции верификатор работает на уровне документа — теряет точность и не локализует конкретную ошибку.
NLI-верификация по источнику
Если источник известен (RAG-база, загруженный документ), каждое утверждение проверяется через NLI (Natural Language Inference). Применяем cross-encoder/nli-deberta-v3-base: на входе — пара (утверждение, контекст из источника), на выходе — entailment / neutral / contradiction с вероятностями.
Порог entailment > 0.75 для принятия утверждения. Contradiction > 0.5 — немедленный флаг. Neutral — помечаем как «не подтверждено источником».
Внешняя верификация через поиск
Для утверждений без известного источника — поиск по внешним API: Tavily Search, Bing Web Search API, или специализированные базы (PubMed для медицины, SEC EDGAR для финансов, Wikidata SPARQL для общих фактов).
Схема: извлечь именованные сущности (NER) → сформировать верификационный запрос → получить топ-3 результата → прогнать NLI между утверждением и каждым результатом → агрегировать.
Практический кейс
Клиент — новостной агрегатор, система автоматического реферирования статей с GPT-4o. После запуска обнаружили: в 12% саммари появляются даты, цифры и имена, которых нет в исходном тексте (проверка на выборке 500 саммари).
Внедрили пайплайн: claim extraction через функции OpenAI (structured output) → для каждого claim NLI-проверка против исходного текста (deberta-v3-large-mnli) → claims с entailment < 0.70 помечаются в UI жёлтым цветом с отсылкой к исходнику.
Результат: доля непроверенных утверждений в финальном выводе снизилась с 12% до 1.8%. Latency добавила 180–220ms на саммари (батчевый NLI на GPU T4).
Сравнение методов верификации
| Метод | Когда применять | Точность | Latency |
|---|---|---|---|
| NLI по источнику | RAG, document QA | Высокая | 50–150ms |
| Self-consistency (N=5) | Без источника | Средняя | ×N стоимость LLM |
| Внешний поиск + NLI | Общие факты | Средняя–высокая | 500–1500ms |
| Специализированный API | Медицина, право | Высокая в домене | Зависит от API |
Что нужно для запуска
Минимум: доступ к продакшн-логам (500+ запросов для baseline), описание домена и критичности ошибок, информация о существующем пайплайне (RAG или нет).
Оптимально: ground truth датасет из 100–300 вопрос-ответ пар с верификацией экспертом. Без него метрики измеряем косвенно.
Этапы: аудит текущих ответов и классификация типов ошибок → выбор метода верификации под домен → разработка claim extraction → интеграция верификатора в пайплайн → A/B тест на 10% трафика → мониторинг precision/recall верификатора.
Сроки: 2–4 недели для интеграции в существующий пайплайн. Сложные домены с внешними API — до 6 недель.