Виявлення галюцинацій у відповідях мовних моделей
LLM впевнено пише "Препарат X затверджено FDA у 2021 році" — а препарату не існує. Або RAG-система цитує документ з точним номером сторінки, якої немає в джерелі. Галюцинації — не рідкісна помилка, а системна властивість авторегресивних моделей: наступний токен передбачується за розподілом імовірностей, а не за базою фактів. При роботі з критичними для бізнесу завданнями це неприйнятно.
Звідки беруться галюцинації та чому їх складно виявити
Проблема не в "невіданні" моделі — вона в тому, що GPT-4, Claude, Llama та їхні аналоги не мають внутрішнього механізму верифікації. Модель не знає, що вона не знає. Впевненість у відповіді (confidence score з logprobs) слабо корелює з фактичною точністю: можна отримати logprob близькій до 0 для галюцинованого факту.
Три основних джерела галюцинацій в production:
Невідповідність між retrieval та generation. У RAG-пайплайні ретривер повертає топ-5 чанків за cosine similarity, але вони не містять відповіді. Модель все одно генерує — заповнює прогалину паттернами з pretraining. Типова ситуація: chunk_size=512 без overlap, FAISS з L2-метрикою замість cosine, слаба embedding-модель (all-MiniLM-L6-v2 замість text-embedding-3-large або E5-mistral-7b).
Temporal drift. Модель навчена на даних до певної дати. Запити про поточні події, змінені регуляції чи нові продукти гарантовано породжують галюцинації без актуального контексту.
Instruction-following vs factuality trade-off. При RLHF-дообучанні моделі навчаються бути "корисними" — давати відповідь, навіть якщо даних недостатньо. Це безпосередньо стимулює галюцинації при невизначеності.
Як будується система виявлення
Виявлення галюцинацій неможливо вирішити одним методом. На практиці застосовуємо багаторівневу архітектуру:
Рівень 1 — Self-Consistency перевірка
Генеруємо N відповідей на одне запитання з temperature > 0 (зазвичай N=5–10, temperature=0.7). Порівнюємо відповіді семантично через sentence-transformers (paraphrase-multilingual-mpnet-base-v2). Якщо варіативність висока — факт ненадійний. Метрика: середня попарна cosine similarity < 0.75 сигналізує про нестабільність.
Рівень 2 — Grounding score
Для RAG-систем: перевіряємо, чи підтримується кожне твердження у відповіді вилученими чанками. Використовуємо NLI-модель (cross-encoder/nli-deberta-v3-base) для оцінки entailment між відповіддю та контекстом. Твердження з entailment score < 0.6 помічається як неперевірене.
Рівень 3 — Retrieval faithfulness
Метрики RAGAS: faithfulness, answer_relevancy, context_precision. Faithfulness < 0.7 при context_precision > 0.8 означає, що контекст був, але модель його проігнорувала — класична генеративна галюцинація.
Рівень 4 — External fact-checking
Для критичних доменів (медицина, право, фінанси): верифікація через пошук (Tavily, Bing Search API) або спеціалізовані knowledge bases (Wikidata SPARQL, PubMed API). Твердження з іменованими сутностями прогоняємо через NER (spaCy + користувацька модель) та верифікуємо кожну сутність окремо.
Практичний кейс
Клієнт — юридична компанія, внутрішній асистент з прецедентного права. Модель: 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 тижні ітерацій.
Метрики для оцінки якості виявлення
| Метрика | Інструмент | Цільове значення |
|---|---|---|
| Hallucination rate | Ручний аудит + NLI | < 5% для production |
| Faithfulness (RAGAS) | ragas library | > 0.80 |
| Grounding score | NLI deberta | > 0.65 per claim |
| Self-consistency | sentence-transformers | cosine sim > 0.75 |
| Latency overhead | — | < 500ms на виявлення |
Процес впровадження
Аудит поточного стану — аналізуємо існуючий пайплайн: якість ретривера, chunk strategy, embedding-модель, промпти. Збираємо датасет з 100–200 реальних запитів з ground truth.
Baseline-вимірювання — отримуємо цифри: hallucination rate, faithfulness, latency. Без baseline незрозуміло, що поліпшувати.
Багаторівнева детекція — вибираємо методи під специфіку домену. Медицина вимагає зовнішньої верифікації; внутрішні знання компанії — достатньо grounding score.
Інтеграція у пайплайн — детектор вбудовується як middleware. Відповіді з низьким grounding помічаються попередженням або відправляються на human review.
Моніторинг у production — логуємо всі оцінки, будуємо дашборд у Grafana. Drift у метриках — сигнал до переіндексації або зміни промпт-стратегії.
Терміни: від 2 тижнів для додавання виявлення до існуючого RAG-пайплайну до 2 місяців для повної системи верифікації зі зовнішніми джерелами у складному домені.