⚠️ Галлюцинации и надёжность

Галлюцинация (hallucination) — это ситуация, когда LLM выдаёт фактически неверное утверждение так, будто оно бесспорно верно. Не «ошибку» с извинением, а уверенную, гладкую неправду. Для чат-бота это раздражает; для юридического или финансового сценария — недопустимо. Поэтому умение строить достаточно надёжные системы — это и есть то, что отличает production-решение от демо.

Корень проблемы

Модель не различает «я знаю» и «я правдоподобно продолжил». Для неё любой ответ — это статистически вероятное продолжение текста. Уверенность тона ≠ достоверность, и именно этот разрыв порождает галлюцинации. См. 01-chto-takoe-llm.

---

Виды галлюцинаций

Вид	Пример	Чем опасно
Фактологическая	Несуществующая норма закона, выдуманный прецедент	Прямой риск в праве/финансах
Цитатная	Ссылка на пункт договора, которого нет	Юрист доверяет «своему» тексту
Числовая	Перепутанная сумма, дата, срок	Критично в расчётах и сроках
«Согласительная»	Модель поддакивает ошибочной предпосылке пользователя	Подрывает доверие к системе
Источник/ссылка	Выдуманный URL, несуществующая статья	Опасно в research-задачах

Согласительность (sycophancy)

Модели обучены быть «полезными», и это иногда выливается в то, что они соглашаются с пользователем, даже если тот неправ. Задавая модели вопрос с заложенным в него неверным утверждением, вы часто получите подтверждение, а не поправку. Поэтому вопрос пользователя нельзя считать нейтральным входом.

Откуда берутся галлюцинации

• Данные обучающиеся на правдоподобии, а не на истинности (01-chto-takoe-llm).
• Устаревание знаний — модель не знает того, что произошло после её обучения (03-kak-sozdayutsya-modeli).
• Длинный контекст — модель хуже помнит середину длинного документа (02-tokens-context-window).
• Высокая температура — больше разнообразия, больше риска (07-prompt-engineering).
• Отсутствие заземления — модель отвечает «из головы», а не по предоставленным источникам.

Многослойная защита

Надёжность — не одна кнопка, а слои, каждый из которых закрывает свою часть риска:

flowchart TD
    L1["1. Заземление (grounding)<br/>через RAG по проверенным источникам"]:::layer
    L2["2. Правильный промпт<br/>«не выдумывай, ссылайся на источник»"]:::layer
    L3["3. Низкая температура + structured output"]:::layer
    L4["4. Guardrails — проверки входа и выхода"]:::layer
    L5["5. Валидация фактов и цифр программно"]:::layer
    L6["6. Human-in-the-loop на критичных решениях"]:::layer
    L7["7. Мониторинг и сбор обратной связи в prod"]:::layer
    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7
    classDef layer fill:#e8f5e9,stroke:#4caf50;

1. Заземление (grounding) через RAG

Самый сильный рычаг: заставить модель отвечать по предоставленным документам, а не из памяти. RAG ([[09-rag]]) даёт модели «источник истины» и резко снижает выдумки — при условии, что промпт явно требует опираться только на извлечённые фрагменты.

2. Промпт против выдумок

Прямо запретите фантазировать и задайте поведение при нехватке данных:

Фраза, которая спасает

«Отвечай только на основе приведённых ниже документов. Если ответа в них нет — ответь: “В предоставленных документах нет достаточной информации”. Не выдумывай нормы, даты и суммы. После каждого утверждения указывай источник (название документа, пункт).»

3. Низкая температура и structured output

Для фактологических задач — temperature ≈ 0 и вывод в фиксированной схеме (11-tools-mcp). Это убирает «творческий» шум и делает ответы предсказуемыми.

4. Guardrails

Guardrails (ограждения) — программные проверки вокруг модели: фильтрация входа (запретные темы, инъекции), проверка выхода (соответствие схеме, отсутствие запрещённой информации), классификация «безопасно/опасно». Реализуются отдельными (часто лёгкими) моделями-классификаторами или правилами.

5. Программная валидация фактов

То, что модель сказала «цифра», не значит, что цифра верна. Критичные числа, даты, расчёты проверяйте кодом, а не моделью: модель извлекает значение «срок — 30 дней», а калькулятор/парсер проверяет арифметику и календарь. См. инструменты.

6. Human-in-the-loop

В высокорисковых сценариях модель не принимает решение сама: она готовит черновик, а решение утверждает человек. Это не слабость архитектуры, а её зрелость — особенно в праве и медицине.

7. Мониторинг

В production нужно видеть, где модель ошибается: логирование, трассировка, сбор «дизлайков» пользователей, регулярный прогон eval-выборок. Без обратной связи надёжность деградирует незаметно.

Калибровка уверенности

Калибровка — это соответствие между тем, насколько модель «уверена», и тем, насколько она реально права. LLM по умолчанию плохо откалиброваны: они одинаково уверенно говорят и правду, и ложь. Поэтому:

• Не доверяйте «уверенности тона» как сигналу качества.
• Если нужно ранжировать ответы по надёжности — используйте явные метрики (оценка второй моделью, голосование нескольких прогонов — self-consistency).

Self-consistency

Для сложной задачи модель запускают несколько раз с одной и той же (или чуть разной) постановкой и смотрят, сходятся ли ответы. Если 9 из 10 прогонов дают один результат — он надёжнее, чем единичный ответ. Это дорого, поэтому применяется точечно — на критичных решениях.

Сколько надёжности достаточно

Нельзя требовать 100%

Нулевого риска у LLM-систем не бывает. Вопрос не «убрать галлюцинации полностью», а «снизить их до уровня, приемлемого для задачи, и поймать остаточные людьми/процессом». Для черновика письма хватит 95%; для автоматического расчёта пени — нужен human-in-the-loop и аудит. Цель — знать свою долю ошибок и проектировать процесс вокруг неё.

flowchart LR
    Risk{"Цена ошибки?"}
    Risk -->|Низкая<br/>(черновик, summary)| Auto["🤖 Полная автоматизация"]
    Risk -->|Средняя<br/>(классификация обращений)| Review["👁 Авто + выборочная проверка"]
    Risk -->|Высокая<br/>(юрзаключение, платёж)| Hitl["✋ Human-in-the-loop<br/>обязательно"]

---

📌 Что запомнить

• Галлюцинация — уверенная неправда; корень — в том, что правдоподобие для модели важнее истины.
• Виды: фактологические, цитатные, числовые, согласительные, выдуманные источники.
• Защита многослойная: grounding (RAG) → промпт → низкая температура/structured → guardrails → программная валидация → human-in-the-loop → мониторинг.
• Модель не должна считать критичные числа — их проверяет код.
• LLM плохо откалиброваны: не доверяйте тону уверенности; для ранжирования — self-consistency или оценка второй моделью.
• Цель — не «ноль ошибок», а приемлемый уровень + процесс для остаточных.

Дальше: 🔎 RAG → — главный механизм заземления модели в ваших данных и снижения галлюцинаций.