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