LLM халюцинации — как да ги откриваме, ограничаваме и управляваме риска в production

Какво са халюцинациите и защо се появяват

Халюцинация в LLM е генерирането на информация, която звучи правдоподобно, но е фактически невярна или необоснована. Това не е „грешка” в смисъл на системна повреда — това е следствие от начина на работа на езиковите модели. LLM не „знае” по начина, по който знае базата данни — той прогнозира най-вероятния следващ token въз основа на статистика от обучението. Когато в промпта се появи въпрос, за който моделът няма добро покритие в тренировъчните данни, той генерира „най-вероятно звучащия” отговор. Често този отговор е правилен. Понякога — не.

Типични сценарии на халюцинации в бизнес приложения:

Цитиране на несъществуващи съдебни решения или параграфи на закони при юридически съвети
Измисляне на имена на функции, класове или библиотеки при генериране на код
Подаване на неверни статистики или дати в отчети
Измисляне на контакти, адреси, телефонни номера
Смесване на факти за различни компании или хора с подобни имена

Слой 1 — Grounding (RAG)

Най-ефективната единична техника за намаляване на халюцинациите е grounding — предоставяне на модела на конкретни документи или данни като контекст, от който да черпи отговори. Класически RAG (Retrieval-Augmented Generation):

Въпрос на потребителя → търсене на най-релевантните фрагменти от документи (vector search в база pgvector / Qdrant / Milvus)
Фрагменти + въпрос → prompt с инструкция „отговори единствено въз основа на следните документи”
Отговор на модела → верификация, че съдържа цитати/референции към източници

RAG намалява халюцинациите типично с 60-80% в приложения от типа „отговаряй на въпроси за нашата база знания”. Не ги елиминира напълно — моделът може все още да „интерпретира” документите по неоснователен начин. Затова са необходими следващи слоеве.

Слой 2 — Self-consistency и ensemble

Self-consistency е техника, която се състои в задаване на един и същи въпрос многократно (или на няколко различни модела) и сравняване на отговорите. Когато отговорите са последователни — високо доверие. Когато се различават — сигнал, че темата е несигурна.

Практически вариант: запитайте Claude Sonnet, Llama 70B и Bielik за един и същ въпрос. Ако и трите връщат същото число, дата, факт — вероятно правилно. Ако се различават — ескалация до човек или до по-скъп модел (Opus). Този модел, имплементиран в 8-степенен LLM routing, съчетава намаляване на разходите с повишаване на надеждността.

Слой 3 — Evaluation pipelines

Production внедряване на LLM без evaluation pipeline е като писане на код без тестове. Конкретни метрики:

Faithfulness — дали отговорът произтича от предоставените документи. Измервано от втори AI модел (LLM-as-judge) или библиотека от типа RAGAS, deepeval.
Answer relevance — дали отговорът адресира въпроса на потребителя.
Context precision — дали най-добрите фрагменти са върнати от retrieval (качество на vector search).
Groundedness score — процент от твърденията в отговора, за които може да се посочи източник в контекста.

Всеки нов build на приложение, базирано на LLM, трябва да преминава комплект от 50-500 evaluation въпроса с известен ground truth. Ако faithfulness падне под 90% — deployment blocked.

Слой 4 — Guardrails и валидация на output

Guardrails са правила, валидиращи output на LLM преди доставяне до потребителя. Примери:

Schema validation — output трябва да отговаря на конкретна схема (JSON Schema, Pydantic). Халюцинации от типа „измислени полета” се откриват механично.
Forbidden patterns — откриване и блокиране на недопустими модели (PII без маскиране, финансови данни извън контекст, потенциално вредно съдържание).
Citation enforcement — всяко фактическо твърдение трябва да има цитат на източник. Ако моделът не цитира — отговорът се отхвърля.
Numeric range validation — числата в output се проверяват за смисъл (например цена > 0, дата ≤ днес, процент в диапазон 0-100).
Cross-reference check — сравняване на output с база факти (например KRS, речник на цитати на закони).

Библиотеки: Guardrails AI, NeMo Guardrails, instructor (за schema enforcement). Собствена имплементация често е по-проста и по-евтина за поддръжка.

Слой 5 — Human-in-the-loop

За high-risk приложения (юридически, медицински, финансови, HR решения) слоят human-in-the-loop е незаменим. AI моделите не вземат финалното решение — поддържат човека. Конкретни модели:

Draft + review — AI генерира първа версия на документ/отговор, човекът верифицира и приема преди изпращане.
Confidence threshold — отговори с ниско confidence (от self-consistency или explicit confidence asking) автоматично се ескалират до човек.
Random sampling QA — 5-10% от всички LLM отговори се одитират ръчно, независимо от confidence — базова метрика за качество във времето.
Feedback loop — потребителят може да маркира грешен отговор; системата се учи и подобрява retrieval, prompts, параметри.

Измерване — как да знаем, че намаляването работи

Конкретни production метрики, които си струва да се наблюдават:

Hallucination rate — процент отговори, класифицирани като халюцинация в ръчна evaluation (sampling). Цел: под 2% за business-critical приложения.
User feedback rate — процент потребители, които са маркирали отговор като грешен.
Escalation rate — процент заявки, ескалирани до човек. Твърде нисък (под 5%) — системата вероятно пропуска несигурни случаи. Твърде висок (над 30%) — системата не доставя автоматизационна стойност.
Faithfulness score в регресионни тестове — месечен тренд.
Time-to-correction — от откриване на халюцинация до внедряване на корекция (по-добър retrieval, нов guardrail, fine-tuning).

Изводи за вземащите решения

Халюцинациите са управляеми — изискват инвестиция в защитна архитектура на много слоеве. Фирмите, които внедряват LLM без тази архитектура, рано или късно ще се сблъскат със сериозен инцидент (публикуване на грешна информация до клиент, грешно решение въз основа на халюцинирани данни, репутационна щета). Разходът за изграждане на пълен защитен stack (RAG + evaluation + guardrails + human-in-the-loop) е типично 15-30% от разхода за самото внедряване на LLM — и това е инвестиция, абсолютно необходима за production приложения. Последствията от пропускането са асиметрични: нисък разход за бездействие в 95% от случаите, катастрофален в 5%.