Інженерне дослідження fact-checking системи: що працює, а що ні

Практичні висновки з розробки open-source рушія Spectrue

Цей текст буде цікавий інженерам, які працюють з LLM, RAG-системами, складним пошуком або будують архітектури, де відповідь «недостатньо даних» — це не помилка, а нормальний результат.

Це не історія стартапу і не туторіал. Це R&D-звіт про те, які очевидні підходи ламаються в реальному пайплайні, а які дають стабільність і прогнозовану вартість.

1. Чому класичний RAG для фактчекінгу «сиплеться»

Більшість проєктів стартують однаково: локальний індекс (часто Wikipedia на FAISS), sentence-embeddings, пошук фрагментів, LLM у ролі «судді». Мій перший прототип був саме таким: ~300k статей Wikipedia, розбитих на речення, локальний пошук + fallback у Google Search API.

Це дає швидкий «вау-ефект», але дуже швидко виявляються системні проблеми.

По-перше, старіння даних.

Фактчекінг майже завжди про «вчора» або «сьогодні». Підтримувати актуальний локальний індекс — це окрема інфраструктурна робота, яка ніколи не закінчується.

По-друге, Google Search дає шум.

Він оптимізований під людей і SEO. Для claim-орієнтованої перевірки фактів це означає забагато нерелевантного контенту, який просто забиває контекстне вікно.

Практичне рішення: я перейшов на пошук, оптимізований під AI-агентів (наприклад, Tavily). Він повертає не просто список сторінок, а вже очищений текстовий контент.

Різниця в співвідношенні сигнал/шум — відчутна.

2. Найважливіший архітектурний зсув: LLM як сенсор, а не суддя

Ключова помилка, яку я зробив на старті — просив LLM сказати «правда чи брехня».

У Spectrue нейромережа не має права бути суддею істини. Вона виконує роль сенсора й анотаційного інструмента:

• витягує атомарні твердження (мінімальні факти на кшталт «X сталося Y-го числа»);
• класифікує позицію джерела щодо конкретного твердження (підтверджує, спростовує, просто згадує);
• додає структурні метадані до фрагментів тексту.

Важливо: фільтрація релевантності — це не робота LLM.

Вона відбувається окремо, на embedding-рівні, через поріг семантичної схожості. Embeddings не «доводять правду», вони лише допомагають швидко відсіяти шум і знайти текст, який може містити доказ.

Фінальний висновок обчислюється детермінованим кодом, поверх структури тверджень, структури доказів і лічильників.

Якщо даних недостатньо — система так і пише: «недостатньо даних». Без спроб вигадати середнє число.

3. Чому «кількість джерел» — дуже оманлива метрика

У якийсь момент стало очевидно, що три сайти з однаковим текстом — це одне підтвердження, а не три.

Тому система розрізняє:

• незалежні підтвердження (різні джерела з різним походженням інформації);
• залежні підтвердження (передруки, агрегати, копіпасти).

Залежні підтвердження не підвищують впевненість, але вони не зникають. Вони залишаються для пояснюваності — користувач має бачити, звідки взялася інформація і як вона поширювалась. Цей момент дуже легко зламати неправильною дедуплікацією.

4. Дедуплікація: де її ставити і чому це тонко

У fact-checking не можна просто «прибрати дублі» і заспокоїтись.

У Spectrue дедуплікація працює у двох формах:

• точні дублі (однаковий URL або контент) — не збільшують кількість підтверджень;
• семантичні дублі — не зникають, а групуються в кластери.

Це важливо, бо в claim-графі різні твердження часто тягнуть ті самі джерела.

Дедуп має працювати після збору кандидатів, але до підрахунку незалежності, і при цьому не ламати можливість повторно використати доказ там, де це логічно.

5. Evidence spillover: економія без втрати якості

Фактчекінг великого тексту — це дорого. Якщо робити окремий пошуковий запит під кожне твердження — бюджет згорає миттєво. Одна з найсильніших оптимізацій — контрольований обмін доказами між сумісними твердженнями.

Якщо два твердження про той самий об’єкт, час або подію, частину доказів можна використовувати повторно — але лише якщо метадані це дозволяють і немає конфлікту.

Це дає:

• менше пошукових запитів;
• більше релевантних доказів без додаткової вартості.

6. Роль надійності джерел: асиметрична логіка

Раніше низька довіра до джерела штрафувала результат. Це виявилось нелогічним.

Після рефактору логіка стала асиметричною:

• якщо джерело достатньо надійне — воно додає плюс до впевненості;
• якщо джерело слабке — воно не мінус, а нуль користі.

Наявність сумнівного джерела не робить твердження хибним, вона просто не допомагає його довести.

Це прибирає дивний ефект, коли сильне підтвердження «просідає» лише через присутність шуму.

7. Економіка інтелекту: моделі, інваріанти і fallback

Я тестував локальні LLM (Mistral, Qwen та інші). На практиці вони вперлись у три проблеми:

• ламали JSON-структури на складних схемах;
• гірше працювали з українською мовою;
• вимагали дорожчої інфраструктури, ніж очікувалось.

В результаті пайплайн побудований каскадом:

• дешевші моделі — для утилітарних кроків;
• дорожчі — лише там, де критична стабільність.

Ключовий патерн — інваріанти.

Якщо модель не проходить schema-валідацію, це не «дивний результат», а сигнал пайплайну: крок повторюється через стабільнішу модель. Система не очікує ідеалу від LLM, вона очікує контрольовану деградацію, а не хаос.

8. Вартість як частина рушія

У Spectrue вартість — не післядумка. Кожен аналіз має реальну ціну: пошук, токени, обробка. Витрати рахуються і конвертуються у внутрішні кредити.

Це дозволяє чесно відповідати на питання: «Скільки коштує підвищити впевненість ще на один крок?»

Підсумкові практичні висновки

Що не працює:

• LLM як суддя істини поверх шумного пошуку;
• «більше пошуку = кращий результат» без структури тверджень;
• агресивна дедуплікація, яка знищує незалежні підтвердження.

Що працює:

• атомарні твердження як базова одиниця перевірки;
• доказ як опорний фрагмент, а не просто лінк;
• розділення незалежних і залежних підтверджень;
• контрольований evidence spillover;
• багаторівневий відсів + інваріанти + fallback;
• вбудований облік вартості як частина інженерної чесності.

Spectrue — це спроба відповісти не на питання «чи можна перевіряти факти автоматично», а на питання «як робити це чесно, стабільно і без ілюзій».

Посилання:

Сайт: spectrue.net

GitHub: github.com/wivanw/spectrue-engine

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев