HallucinationLLM APIProduction

Как предотвратить галлюцинации LLM в продакшне (2026)

15 авг. 2026 г.1 мин чтения

Агент подтвердил возврат, пометил тикет как решённый и так и не вызвал API возврата. Бегло, уверенно — и полностью неверно в отношении действия, которого никогда не было. Главный тезис этого гайда: галлюцинации LLM нельзя устранить, ими можно только управлять — и любой вендор, продающий вам «ноль галлюцинаций», продаёт вам демо.

Вот паттерн, который повторяется снова и снова: команда выпускает LLM-фичу, видит ответ-галлюцинацию в продакшне и реагирует сменой модели. Через три недели — другая галлюцинация. Потом prompt engineering. Потом RAG. Потом «guardrail»-продукт. Каждый шаг ощущается прогрессом; каждый шаг лечит симптом системы, у которой нет бюджета на галлюцинации, нет слоя обнаружения и нет политики смягчения.

Этот гайд предлагает альтернативу: галлюцинация — это управляемый риск, а не исправимый баг. Продакшн-ответ — трёхуровневый фреймворк — обнаружение, предотвращение, смягчение — с бюджетом мониторинга, который относится к частоте галлюцинаций как к SLO, а не как к скандалу. Мы разберём данные бенчмарков, показывающие, почему одна лишь смена модели не работает, уровни фреймворка с их стоимостью, бюджетные числа, делающие управление конкретным, и контраргументы — потому что «просто смените модель» заслуживает честного ответа.

Почему трёхуровневый фреймворк бьёт «серебряные пули»

Ключевой вывод: каждое точечное «решение» — модели получше, больше промптинга, RAG — закрывает один класс отказов и оставляет остальные нетронутыми.

База доказательств публична и растёт: независимые лидерборды вроде лидерборда галлюцинаций Vectara измеряют семейства моделей по галлюцинациям в суммаризации, а исследование бенчмарков Presenc 2026 года отслеживает ситуацию по типам задач. Что данные стабильно показывают:

Частота галлюцинаций зависит от задачи, а не от модели. Модель, которая меньше всего галлюцинирует на суммаризации, может быть в середине списка на коде или извлечении. «Переключитесь на лучшую модель» предполагает, что лучшая модель существует, а бенчмарки такой не дают.
Разброс между моделями реален, но ограничен. Фронтирные модели отличаются друг от друга на единицы процентов по большинству задач — а от бюджетных моделей больше. Выбор модели сдвигает частоту; он не обнуляет её.
У галлюцинаций есть подтипы, и им нужно разное лечение. Фабрикация (выдумывание фактов), противоречие (изменение фактов по ходу разговора) и галлюцинация действий (утверждение, что действие было выполнено, хотя его не было). RAG закрывает источники фабрикации; для галлюцинаций действий он бесполезен. Промптинг исправляет стилистические ошибки; для фактического вымысла он бесполезен.

Режим отказа каждой «серебряной пули» одинаков: она оптимизирует один подтип и оставляет слепую зону мониторинга нетронутой — именно поэтому следующая галлюцинация приходит как сюрприз.

Что это значит: обнаружение, предотвращение и смягчение

Ключевой вывод: три уровня, у каждого своя задача и измеримая стоимость — и это не опциональные дополнения, а архитектура.

Слой 1 — Обнаружение. Нельзя управлять тем, чего не видишь. Варианты обнаружения по возрастанию стоимости: оценка LLM-as-judge на выборке (самый дешёвый и распространённый), специализированные детекторы галлюцинаций, проверки самосогласованности (сгенерировать дважды, сравнить) и принудительное цитирование (требовать источники и проверять их). У каждого свой профиль задержки и стоимости; частота выборки — регулятор бюджета. Дисциплина evals за этим слоем — это CI-стиль оценки, применяемый непрерывно, а не только перед запуском.

Четыре варианта с компромиссами, которые реально решают:

Вариант	Что проверяет	Доп. задержка	Доп. стоимость	Лучше всего для
LLM-as-judge (на выборке)	вывод против рубрики задачи	офлайн, пакетно	минимальная	большинства продакшн-трафика
Специализированный детектор	оценка фактической согласованности	10-100 мс	низкая	пайплайнов суммаризации
Самосогласованность	сгенерировать дважды, сравнить	2× времени генерации	2× токенов	ответов с высокими ставками
Принудительное цитирование	источники существуют и совпадают	retrieval + верификация	средняя	фич с grounding

Цикл судьи в простейшей продакшн-форме:

import random
import re
from openai import OpenAI

client = OpenAI()
SAMPLE_RATE = 0.05  # 5% of traffic; raise toward 1.0 for high-risk features

def maybe_judge(question: str, answer: str, rubric: str) -> float | None:
    if random.random() > SAMPLE_RATE:
        return None
    verdict = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content":
            "Rate 0-10: is the answer factual per this rubric? "
            "Reply with a single number.\n"
            f"Rubric: {rubric}\nQ: {question}\nA: {answer}"}],
    )
    match = re.search(r"(\d+(?:\.\d+)?)", verdict.choices[0].message.content)
    return float(match.group(1)) if match else None

Слой 2 — Предотвращение. Снижайте частоту до генерации: grounding с полученными или живыми данными (гайд по grounding этой серии описывает реализацию), ограниченное декодирование с режимами структурированного вывода, гигиена контекста (что отправляете, то модель и может противоречить) и подбор модели под задачу (не просите бюджетную модель рассуждать за пределами её класса). Именно сюда относится RAG — для класса отказов с поиском фактов, и только для него.

Слой 3 — Смягчение. Когда неверный ответ всё равно уходит в продакшн (а он уйдёт), система должна корректно деградировать: скоринг уверенности с путём отказа, цепочки fallback на вторую модель или человека (кастомная маршрутизация делает fallback конфигурацией) и цикл обратной связи, возвращающий обнаруженные сбои в eval-набор. Смягчение — уровень, превращающий галлюцинацию из инцидента в точку телеметрии.

Что это значит для вашего продакшн-бюджета

Ключевой вывод: управление — это бюджет, а не политика — частоты выборки, пороги и алертинг делают фреймворк конкретным, а CFO довольным.

Операционный перевод фреймворка:

Частота выборки по уровню риска. Фичи с низким риском (саммари, классификация): выборка 1-5% трафика для детекции судьёй. Фичи с высоким риском (медицина, юриспруденция, финансы, действия агента): 100%, с проверками цитирования на каждый запрос, где применимо. Частота выборки — регулятор стоимости: детекция дёшева именно потому, что это выборка.
Пороги и алертинг. Определите SLO по частоте галлюцинаций для каждой фичи (число зависит от вашей задачи и класса риска — лидерборды служат ориентиром достижимого). Алертите по частоте, а не по отдельным плохим ответам; отдельные ответы — для цикла обратной связи.
Выбор модели как вход управления. Каталог моделей и данные бенчмарков вместе определяют базовую частоту, от которой вы отталкиваетесь в управлении, — подбор под задачу — это самый дешёвый слой предотвращения, и он усиливает всё остальное.

Форма бюджета: детекция с выборкой 5% обычно добавляет единицы процентов к вашему API-счёту; предотвращение ничего не добавляет во время генерации (grounding и маршрутизация — конфигурация); смягчение время от времени стоит отказа или fallback. Управление галлюцинациями — одна из самых дешёвых инвестиций в надёжность во всём LLM-стеке — документация по производственной оптимизации описывает окружающий стек, — и именно поэтому его отсутствие так заметно.

Подробный расчёт бюджета. Допустим, фича выполняет 100,000 вызовов в день на фронтирном уровне. Выборка 5% для детекции судьёй: 5,000 вызовов судьи, каждый примерно с пятую часть стоимости основного вызова — около 1% к счёту за полную видимость. Задайте SLO на уровне p90 вашей eval-базовой линии («частота галлюцинаций ниже 3% за последнюю неделю», например) и алертите, когда скользящая частота его пересекает. Фича с действиями агента и высоким риском оправдывает выборку 100% и более жёсткий SLO. Регулятор выборки — вот как вы обмениваете копейки на уверенность.

Контраргументы: «просто смените модель» и другие мифы

Ключевой вывод: четыре популярных ответа, и в каждом дыра в форме данных.

«Переключитесь на флагманскую модель». Лидерборды показывают: флагман не лучший в каждой задаче — и его частота, хоть и ниже, всё равно не нулевая. Смена модели сдвигает базовую частоту; она не убирает необходимость в обнаружении и смягчении.
«RAG решает проблему». RAG закрывает факты, полученные через retrieval. Он не касается галлюцинаций действий, не помогает, когда сам корпус неверен, и приносит собственный класс отказов — retrieval с правдоподобным, но неверным чанком. Наш гайд по RAG документирует оба направления.
«Prompt engineering всё исправит». Промпты формируют стиль и структуру, а не фактичность. Гайд по prompt engineering чётко обозначает границу: лучший промпт делает вывод чище, а не правдивее.
«Частота низкая, мониторинг не нужен». Низкая частота × высокий объём = гарантированные инциденты. Точность 99.5% на 10,000 ежедневных вызовов — это 50 неверных ответов в день — и «низкая частота» как раз то утверждение, которое для проверки требует мониторинга.

FAQ

Можно ли полностью устранить галлюцинации?

Нет — и любой вендор, заявляющий о нуле галлюцинаций, описывает демо. Продакшн-цель — управляемая частота: обнаруженная, предотвращённая где возможно и смягчённая, когда уходит в продакшн. Фреймворк в этом гайде — как строится такое управление.

Какая модель галлюцинирует меньше всего?

Зависит от задачи, по данным лидербордов — лидер суммаризации не обязательно лидер по коду. Подбирайте под задачу и проверяйте на собственном eval-наборе на своих данных, потому что важно именно ваше распределение задач.

Сколько стоит обнаружение галлюцинаций?

При выборке 5% с LLM-as-judge детекция обычно добавляет единицы процентов к вашему API-счёту. Фичи с высоким риском при выборке 100% стоят дороже — но это цена класса риска, и это всё равно дешевле инцидента.

Останавливает ли RAG галлюцинации?

Он закрывает класс отказов с поиском фактов — ответы с grounding по известному корпусу. Он не останавливает галлюцинации действий или ошибки, порождённые самим корпусом, а retrieval приносит собственные режимы отказа. Слой предотвращения, а не «серебряная пуля».

Какой SLO по частоте галлюцинаций реалистичен?

Задавайте его по собственному eval-набору и публичным лидербордам для вашего класса задач — единицы процентов достижимы для большинства продакшн-задач при работающей детекции; число ниже этого — это решение об управлении, а не свойство модели.

Как обнаруживать именно галлюцинации действий?

Проверкой действия, а не текста: убедитесь, что вызов инструмента реально выполнился и состояние изменилось так, как заявлено. Текстовые судьи не видят действий — журналы выполнения агентного фреймворка и есть слой детекции для этого подтипа.

Итоги

Галлюцинации LLM — это управляемый риск: обнаружение через выборку, предотвращение через grounding и подбор под задачу, смягчение через отказ и fallback — с бюджетом мониторинга, который делает управление конкретным. Смена модели сдвигает базовую частоту; фреймворк превращает галлюцинацию из инцидента в точку телеметрии. Стройте уровни, задавайте SLO — и следующая галлюцинация станет точкой данных, а не сюрпризом.

Держите этот фреймворк под рукой — когда будете задавать собственные SLO по галлюцинациям, лидерборды, на которые мы ссылались, послужат ориентиром, а ваш eval-набор — арбитром. Следите за нашим блогом — мы ежеквартально обновляем данные бенчмарков по мере выхода новых семейств моделей. Именно этот фреймворк превращает дискуссию в дашборд, которым можно управлять.