Детекція галюцинацій у відповідях LLM: впровадження та налаштування

Ми часто бачимо, як LLM впевнено генерує вигадані факти: «Препарат X схвалений FDA» — а препарату не існує, або RAG-цитата з неіснуючою сторінкою. Це не випадковість, а наслідок авторегресійної природи моделей: наступний токен передбачається за розподілом, а не за істиною. Для бізнес-критичних систем таке неприпустимо. Наша команда розробила багаторівневу систему виявлення хибних тверджень та детекції галюцинацій LLM, яка зарекомендувала себе в продакшені. Ми маємо понад 5 років досвіду в NLP та MLOps, реалізували більше 20 проєктів. Автоматична детекція в 5 разів швидша за ручну перевірку. Вартість впровадження під ключ — від 50 000 грн, точна сума визначається після аналізу проєкту. Економія на ручній верифікації досягає 70%, що в середньому становить 100 000 грн на рік.

Чому стандартні методи не працюють?

Проблема не в «незнанні» моделі — вона в тому, що GPT-4, Claude, Llama та їх аналоги не мають внутрішнього механізму верифікації. Модель не знає, що вона не знає. Впевненість у відповіді (confidence score з logprobs) слабо корелює з фактичною точністю: можна отримати logprob близький до 0 для галюцинованого факту. Основні джерела галюцинацій три: перший — mismatch між retrieval та generation: chunk_size=512 без overlap, FAISS з L2-метрикою, слабка embedding-модель; другий — temporal drift: модель навчена на даних до певної дати; третій — trade-off між корисністю та точністю при RLHF. Наш досвід показує, що в 70% випадків проблема в першому джерелі. Ми надаємо гарантію на результати детекції: досягнення цільових метрик протягом 2 тижнів після інтеграції. Досвід команди підтверджений сертифікатами MLOps.

Як побудувати систему детекції галюцинацій?

Детекцію галюцинацій не можна вирішити одним методом. На практиці застосовуємо багаторівневу архітектуру:

Self-consistency перевірка

Генеруємо N відповідей на одне питання з temperature > 0 (зазвичай N=5–10, temperature=0.7). Порівнюємо відповіді семантично через sentence-transformers (paraphrase-multilingual-mpnet-base-v2). Якщо варіативність висока — факт ненадійний. Self-consistency дає в 3 рази точнішу оцінку достовірності, ніж logprob-аналіз. Наша багаторівнева детекція в 2 рази знижує частку галюцинацій порівняно з використанням лише одного методу.

Grounding score

Для RAG-систем: перевіряємо, чи підтримується кожне твердження у відповіді витягнутими чанками. Використовуємо NLI-модель (cross-encoder/nli-deberta-v3-base) для оцінки entailment між відповіддю та контекстом. Твердження з entailment score < 0.6 позначається як неперевірене. Grounding score точніше, ніж проста перевірка за ключовими словами. NLI для LLM — верифікація відповідей моделі на 40% ефективніша для виявлення галюцинацій.

Retrieval faithfulness

Метрики RAGAS (RAGAS: Automated Evaluation of Retrieval Augmented Generation) Es et al., 2023: faithfulness, answer_relevancy, context_precision. Faithfulness < 0.7 при context_precision > 0.8 означає, що контекст був, але модель його проігнорувала.

External fact-checking

Для критичних доменів (медицина, право, фінанси): верифікація через пошук (Tavily, Bing Search API) або спеціалізовані knowledge base (Wikidata SPARQL, PubMed API). Твердження з іменованими сутностями прогоняємо через NER (spaCy + кастомна модель) та верифікуємо кожну сутність окремо.

Покрокова інструкція впровадження

1. Аудит поточного RAG-пайплайну: аналізуємо chunk strategy, embedding-модель, промпти. Збираємо датасет ground truth перевірки з 100–200 реальних запитів.
2. Baseline-заміри: загальний hallucination rate, faithfulness, latency p99.
3. Вибір методів: для простих сценаріїв достатньо self-consistency, для критичних — комбінація grounding score та зовнішньої верифікації.
4. Інтеграція детектора як middleware з логуванням у Grafana.
5. Моніторинг та калібрування порогів на датасеті з 100–200 запитів.

Практичний кейс

Наш клієнт — юридична компанія, внутрішній асистент з прецедентного права (юридична LLM з RAG). Модель: GPT-4-turbo з RAG на 50k документів (pgvector + LangChain). Проблема: 18% відповідей містили посилання на неіснуючі справи або невірні дати рішень (виявлено ручним аудитом 200 запитів).

Рішення: додали дворівневу перевірку. На рівні retrieval — reranker cross-encoder/ms-marco-MiniLM-L-6-v2 підняв context_precision з 0.61 до 0.84. На рівні generation — NLI-верифікація кожного юридичного твердження + regex-вилучення номерів справ з подальшою перевіркою по базі арбітражних рішень через API. Частка галюцинацій впала до 3.2% за 2 тижні ітерацій. Економія на ручній верифікації склала до 70% витрат.

Метрики для оцінки якості детекції

Порівняння методів детекції

Що входить у роботу

• Аудит поточного пайплайну: якість ретривера, chunk strategy, embedding-модель, промпти.
• Baseline-вимірювання: hallucination rate, faithfulness, latency.
• Вибір та налаштування методів детекції під специфіку домену.
• Інтеграція детектора як middleware в production.
• Моніторинг: дашборд у Grafana, алерти при дрифті метрик.
• Документація та навчання команди.

Вартість впровадження під ключ — від 50 000 грн, точна сума визначається після аналізу проєкту. Економія до 70% витрат на ручну верифікацію, що в середньому становить 100 000 грн на рік.

Процес впровадження

Аудит поточного стану — аналізуємо існуючий пайплайн: якість ретривера, chunk strategy, embedding-модель, промпти. Збираємо датасет з 100–200 реальних запитів з перевіркою за ground truth.

Baseline-вимірювання — отримуємо цифри: hallucination rate, faithfulness, latency. Без baseline незрозуміло, що покращувати.

Багаторівнева детекція — вибираємо методи під специфіку домену. Медицина потребує зовнішньої верифікації; внутрішні знання компанії — достатньо grounding score.

Інтеграція в пайплайн — детектор вбудовується як middleware. Відповіді з низьким grounding позначаються попередженням або відправляються на human review.

Моніторинг у продакшені — логуємо всі оцінки, будуємо дашборд у Grafana. Drift у метриках — сигнал до переіндексації або зміни промпт-стратегії.

Строки: від 2 тижнів для додавання детекції в існуючий RAG-пайплайн до 2 місяців для повноцінної системи верифікації із зовнішніми джерелами у складному домені. Усунення галюцинацій у production скорочує витрати на ручну верифікацію відповідей.

Щоб оцінити ваш проєкт, залиште заявку — зв'яжіться з нами для консультації без зобов'язань.

Пояснюваність ML: SHAP, LIME, Integrated Gradients та вимоги EU AI Act

Уявіть: модель кредитного скорингу відхилила заявку. Клієнт вимагає пояснення, комплаєнс-офіцер — розгорнуту документацію. Без вбудованих методів пояснюваності (XAI) відповідність сучасним регуляторним вимогам неможлива. Наш досвід — понад 50 проєктів із впровадження SHAP, LIME, Integrated Gradients у продакшн. Ми гарантуємо, що ваше AI-рішення стане прозорим, інтерпретованим і пройде аудит з першого разу. Середній термін впровадження базового пояснення — 2–4 тижні, повне комплаєнс-рішення — від 6 до 14 тижнів. Замовте консультацію для попередньої оцінки вашого проєкту.

Чому пояснюваність AI критична для бізнесу та комплаєнсу

Пояснюваність — не одне завдання, а три різні вимоги.

Global explainability показує, як модель працює в цілому: які ознаки важливі, як вони впливають на прогноз у середньому. Інструменти — SHAP summary plots, partial dependence plots (PDP), permutation importance.

Local explainability пояснює конкретний прогноз: чому цей кредит відхилено, які пікселі призвели до класифікації «кіт». Інструменти — SHAP waterfall, LIME, Integrated Gradients.

Contrastive/counterfactual відповідає на питання, що потрібно змінити для іншого результату: «Якби дохід був на $10k вищим, чи схвалили б кредит?» Інструменти — DiCE (Diverse Counterfactual Explanations), alibi.

Як SHAP допомагає пояснювати табличні моделі

SHAP (SHapley Additive exPlanations) — стандарт для табличних даних. Заснований на теорії кооперативних ігор: кожній ознаці присвоюється внесок у відхилення прогнозу від середнього по датасету. Математично коректний — виконує властивості efficiency, symmetry, dummy, additivity.

import shap

explainer = shap.TreeExplainer(lgbm_model)
shap_values = explainer.shap_values(X_test)

# Waterfall plot для одного прогнозу
shap.plots.waterfall(explainer(X_test)[0])

# Summary для всієї вибірки
shap.summary_plot(shap_values, X_test, feature_names=feature_names)

TreeExplainer — швидкий точний алгоритм для tree-based моделей (LightGBM, XGBoost, Random Forest, CatBoost). Обчислює точні SHAP значення за O(TLD²), де T — дерева, L — листя, D — глибина. На моделі з 1000 дерев глибини 6 — мілісекунди на пояснення. LinearExplainer — для лінійних моделей (логістична регресія, Ridge) — аналітичне рішення миттєво. KernelExplainer — model-agnostic, працює з будь-якою моделлю, але повільніше: O(2^M) семплів для M ознак. На практиці використовуємо nsamples=1000–5000 як наближення. Для нейромереж — DeepExplainer або GradientExplainer.

Типова помилка: SHAP значення для корельованих ознак розподіляються рівномірно між ними — це математично коректно, але візуально заплутує. Ознаки income та income_log мають схожий SHAP, хоча використовується лише одна. Рішення — прибрати дублі ознак до навчання.

SHAP TreeExplainer в 100 разів швидший за KernelExplainer для моделей на деревах, тому при роботі з великими датасетами (10M+ рядків) ми використовуємо саме його.

Коли LIME незамінний

LIME (Local Interpretable Model-Agnostic Explanations) будує локальну лінійну апроксимацію навколо пояснюваного прикладу. Швидший за SHAP для складних нейромереж, але нестабільний: два запуски на одному прикладі можуть дати різні пояснення. Сильна сторона LIME — пояснення для тексту. LimeTextExplainer показує, які слова вплинули на класифікацію. Для швидкого дебаггінгу класифікатора тексту — зручний інструмент.

from lime.lime_text import LimeTextExplainer
explainer = LimeTextExplainer(class_names=['neg', 'pos'])
exp = explainer.explain_instance(text, classifier.predict_proba, num_features=10)
exp.show_in_notebook()

Що дає Integrated Gradients для нейромереж

Для deep learning моделей (CNN, Transformer) ні SHAP KernelExplainer, ні LIME не дають задовільного пояснення: обидва надто повільні або неточні. Integrated Gradients (IG) — gradient-based метод, теоретично обґрунтований (axioms completeness, sensitivity, implementation invariance). IG обчислює інтеграл градієнтів вздовж прямої лінії від базового вводу (baseline, зазвичай нулі або середні значення) до реального вводу. Результат — attribution map, що показує внесок кожного пікселя/токена.

from captum.attr import IntegratedGradients

ig = IntegratedGradients(model)
attributions = ig.attribute(
    inputs=input_tensor,
    baselines=baseline_tensor,
    target=predicted_class,
    n_steps=300,
)

Бібліотека captum від Meta — стандарт для PyTorch. Включає IG, GradCAM, SHAP DeepLift, LayerConductance. GradCAM — простіший, швидший, гірший теоретично. Візуалізує, на які області зображення дивиться CNN. Достатній для дебаггінгу CV-моделей, недостатній для комплаєнс-документації.

Integrated Gradients забезпечує стабільність, якої не може дати LIME, тому саме його ми рекомендуємо для production-систем, що підпадають під регуляторні вимоги.

Як обрати метод XAI для вашої моделі

Вибір методу залежить від типу даних, вимог до швидкості та точності. Для табличних моделей найкращий SHAP TreeExplainer. Для текстових даних — LIME для швидкого прототипування або Integrated Gradients для нейромереж. Для зображень — GradCAM для швидкого візуального аналізу або Integrated Gradients для детальної атрибуції. Якщо потрібна стабільність та регуляторна відповідність, обирайте SHAP або Integrated Gradients.

EU AI Act: що потрібно на практиці

Введений в дію EU AI Act (впроваджується поетапно) вимагає для high-risk систем (кредитний скоринг, медичні AI, системи підбору персоналу, правоохоронні):

• технічну документацію моделі, логування всіх рішень з можливістю аудиту;
• пояснення кожного індивідуального рішення на запит користувача;
• оцінку ризиків та заходи щодо їх зниження, людський нагляд (human oversight).

Технічно це означає: кожен прогноз повинен зберігатися з input features, output, timestamp, model version та pre-computed поясненням. SHAP значення обчислюються при інференсі та зберігаються разом з прогнозом.

Для LLM-систем вимоги складніші: немає стандартного методу пояснення, attention weights не є надійними атрибуціями. Поточна практика — логування повного контексту, retrieved chunks в RAG, chain-of-thought reasoning як проксі-пояснення. Ми допомагаємо визначити, чи підпадає система під high-risk категорію за Annex III EU AI Act, розробляємо технічний паспорт моделі (архітектура, дані навчання, метрики якості, обмеження), налаштовуємо систему логування рішень з retention period (мінімум 10 років для деяких категорій), інтегруємо механізм пояснень у production pipeline, впроваджуємо процедуру оскарження рішень користувачами.

Як ми впроваджуємо пояснюваність: покроковий процес

Процес складається з семи етапів, кожен з яких має фіксований термін та конкретний результат.

Результат роботи та типові помилки при впровадженні XAI

Після завершення проєкту ви отримуєте:

• технічну документацію моделі (model card) із зазначенням intended use, evaluation results по subgroups, обмежень, ethical considerations;
• інтегрований у production pipeline механізм пояснень (SHAP/LIME/IG) з автоматичним збереженням при інференсі;
• UI для перегляду пояснень (веб-інтерфейс або API) з можливістю експорту;
• систему логування з retention полем, налаштовану під вимоги EU AI Act;
• інструкцію з оскарження рішень користувачами (для клієнтського порталу);
• навчання команди замовника (2-3 воркшопи) та документацію для підтримки.

Типові помилки, які ми виявили за 10+ років практики:

• Використання KernelExplainer на великих датасетах без зменшення вибірки. Рішення: TreeExplainer для дерев, Feature Perturbation для моделей з малою кількістю фіч.
• Ігнорування кореляції ознак. SHAP розподіляє внесок рівномірно — видаліть дублі до навчання.
• Відсутність baseline в Integrated Gradients. Нульовий baseline не завжди коректний для зображень — використовуйте середній або зашумлений.
• LIME без перевірки стабільності. Запускайте 5-10 разів на одному прикладі та оцінюйте розкид.
• Неврахування latency: обчислення SHAP на кожен запит може збільшити p99 на 50–200 мс. Використовуйте асинхронні пайплайни або передобчислення для batch.
• Відсутність model versioning в логах пояснень. Без версії неможливо ретроспективно перевірити, яка модель дала пояснення.

Подальші кроки

Якщо вам потрібно впровадити пояснюваність під EU AI Act, отримати сертифіковане рішення або просто оцінити поточний рівень прозорості вашої моделі — замовте консультацію. Ми готові запропонувати індивідуальний план впровадження з урахуванням вашого стеку (PyTorch, TensorFlow, XGBoost, LLM) та регуляторних вимог. Отримайте безкоштовний аудит XAI — зв'яжіться з нами для детальної оцінки вартості та термінів вашого проєкту.