Как посчитать hallucination rate в SQL

Что такое hallucination rate

Hallucination rate — доля ответов LLM, в которых модель выдумала факты: сослалась на несуществующий документ, привела неверную цифру, придумала функцию API. Это ключевая метрика доверия к AI-продукту: пользователь, поймавший ассистента на уверенной лжи один раз, перестаёт верить и правильным ответам тоже.

Метрику спрашивают на собеседованиях AI-аналитика и AI-продакта в связке с вопросом «как вы поймёте, что ваш ассистент можно выпускать в прод». В отличие от retention или конверсии, hallucination rate нельзя вытащить чистым запросом из сырых логов — сначала ответы нужно разметить на «достоверно / галлюцинация», и только потом агрегировать в SQL. Разберём весь путь: разметка, формула, запрос, разбивка по сегментам.

Формула и как размечать

Формула простая, вся сложность — в разметке числителя.

Hallucination rate = ответы с галлюцинацией / всего оценённых ответов × 100%

Разметить ответ как галлюцинацию можно тремя способами. Первый — ручная разметка асессорами: точно, но дорого и медленно, годится для небольшого эталонного набора. Второй — модель-судья (LLM-as-a-judge): отдельная модель проверяет, подтверждаются ли утверждения ответа предоставленным контекстом; масштабируется, но сама шумит, поэтому её калибруют по ручной разметке. Третий — автоматическая сверка с источником для RAG: проверяем, что каждое фактическое утверждение выводится из извлечённых документов (это и есть groundedness).

Результат разметки складывают в таблицу оценки — примерно такую:

llm_evals(response_id, user_id, model, prompt_type,
          is_hallucination BOOLEAN, judged_at, source)

Дальше метрика — обычная агрегация по этой таблице.

Как посчитать в SQL

Базовый расчёт — доля ответов с галлюцинацией за период. Важно не наступить на классические грабли SQL: целочисленное деление в PostgreSQL усекает результат, поэтому числитель приводим к NUMERIC.

-- Hallucination rate за июнь 2026
SELECT
    100.0 * COUNT(*) FILTER (WHERE is_hallucination)
        / NULLIF(COUNT(*), 0) AS hallucination_rate_pct,
    COUNT(*) AS evaluated
FROM llm_evals
WHERE judged_at >= '2026-06-01'
  AND judged_at <  '2026-07-01';

COUNT(*) FILTER (WHERE is_hallucination) считает только галлюцинации, NULLIF(..., 0) страхует от деления на ноль на пустой выборке. Поле evaluated выводим рядом намеренно: процент без размера выборки легко ввести в заблуждение — 20% на 10 ответах и на 10 000 это очень разная уверенность.

Чтобы отслеживать динамику после релизов промптов или смены модели, считают метрику по дням:

-- Динамика hallucination rate по дням
SELECT
    judged_at::DATE AS day,
    COUNT(*) AS evaluated,
    ROUND(100.0 * COUNT(*) FILTER (WHERE is_hallucination)
        / NULLIF(COUNT(*), 0), 2) AS hallucination_rate_pct
FROM llm_evals
WHERE judged_at >= CURRENT_DATE - 30
GROUP BY day
ORDER BY day;

Hallucination rate по сегментам

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

-- Где модель галлюцинирует чаще: разбивка по типу запроса
SELECT
    prompt_type,
    COUNT(*) AS evaluated,
    ROUND(100.0 * COUNT(*) FILTER (WHERE is_hallucination)
        / NULLIF(COUNT(*), 0), 2) AS hallucination_rate_pct
FROM llm_evals
WHERE judged_at >= '2026-06-01'
GROUP BY prompt_type
HAVING COUNT(*) >= 30            -- отсекаем шумные сегменты с малой выборкой
ORDER BY hallucination_rate_pct DESC;

HAVING COUNT(*) >= 30 здесь принципиален: без порога сегменты с двумя-тремя оценками дадут 0% или 100% и уведут внимание не туда. Разбивка почти всегда обнаруживает конкретный класс запросов, где модель врёт систематически, — это и есть рабочая точка для улучшения промпта или базы знаний. Как устроена оценка галлюцинаций глубже — в разборе LLM-evals.

Онлайн- и офлайн-оценка

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

Здоровый процесс использует оба: офлайн для регрессионного контроля («новый промпт не стал галлюцинировать больше»), онлайн — для мониторинга реального качества. Собрать эту систему метрик AI-продукта целиком помогает разбор в хабе метрик AI-продукта, а потренировать вопросы с собеса — Карьерник.

Частые ошибки

Первая ошибка — считать процент без размера выборки. Hallucination rate 5% звучит одинаково на 20 и на 20 000 оценках, но доверие к этим цифрам несопоставимо. Всегда выводите evaluated рядом с процентом и ставьте порог на сегменты.

Вторая ошибка — доверять модели-судье без калибровки. LLM-as-a-judge сам ошибается и имеет свои смещения. Прежде чем масштабировать оценку на весь трафик, его сверяют с ручной разметкой на выборке и оценивают согласованность.

Третья ошибка — смотреть только средний rate. Именно разбивка по типу запроса и источнику вскрывает, где модель врёт систематически. Средняя цифра нужна для трекинга динамики, а решения принимают по сегментам.

Связанные темы

• Метрики AI-продукта и LLM
• LLM-evals и галлюцинации на собесе
• Оценка качества RAG
• Prompt engineering на собеседовании

FAQ

Можно ли посчитать hallucination rate чистым SQL из логов?

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

Что такое хороший hallucination rate?

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

Чем hallucination rate отличается от groundedness?

Это две стороны одной монеты. Groundedness измеряет долю утверждений, подтверждённых контекстом, — чем она выше, тем лучше. Hallucination rate измеряет долю ответов с неподтверждёнными выдумками — чем ниже, тем лучше. В RAG-системах их часто считают вместе: низкая groundedness обычно означает высокий hallucination rate.

Как отслеживать hallucination rate после смены модели?

Через ежедневную разбивку и офлайн-регрессию на эталонном наборе. Перед выкаткой новой модели или промпта прогоняют фиксированный набор вопросов и сравнивают hallucination rate с предыдущей версией. После выкатки следят за онлайн-метрикой по дням, чтобы поймать рост галлюцинаций на реальном трафике.