Как создать training-free детектор галлюцинаций для RAG и обнаружить ошибки в эталонной разметке

Когда эталон врёт: как шесть LLM поймали RAGTruth на неточностях

Галлюцинации в RAG — это не баг, а особенность. Каждый, кто собирал RAG-пайплайн, сталкивался с ситуацией: модель уверенно цитирует несуществующую статистику или перевирает факты из контекста. Традиционные детекторы требуют тонны размеченных данных и дообучения. Но что, если я скажу, что можно обойтись без этого? И более того — такой подход вскрывает ошибки в эталонных датасетах, на которых эти детекторы учат.

Речь о training-free детекторе на основе консенсуса 6 LLM. Никакого fine-tuning, никаких дополнительных классификаторов. Просто берем пул моделей-судей, даём им ответ RAG-системы и контекст — и смотрим, кто из них заподозрит неладное. Результат: AUROC 0.882, F1 0.766 — это достойный уровень для задачи, где даже человек часто ошибается.

Давайте разберём, как собрать такой детектор, какие критерии использовать и почему консенсус лучше одиночных судей.

Почему один судья — плохой судья

Идея LLM-as-a-judge не нова. Но когда мы берём одну модель и просим её оценить сгенерированный ответ, мы всегда рискуем: модель может быть слишком строгой, слишком снисходительной или просто не заметить тонкий фальстарт. Исследования показывают: даже лучшие модели (GPT-4o, Claude 3.5 Sonnet) имеют внутренние смещения. Например, GPT-4o склонен занижать оценки, если ответ слишком короткий, независимо от его фактической точности.

Решение — использовать ансамбль из нескольких LLM. Каждая модель смотрит на ответ со своей стороны, и если большинство кричит «галлюцинация» — скорее всего, так и есть. Мы не учим отдельный классификатор, а просто агрегируем голоса. Это называется training-free consensus. И это работает.

Для нашего эксперимента я взял 6 современных открытых и проприетарных моделей:

• GPT-4o (OpenAI, июнь 2026 версия)
• Claude 3.5 Sonnet (Anthropic, последнее обновление)
• Gemini 2.0 Flash (Google, актуальная на 08.07.2026)
• Llama-3 70B (Meta, инструктивная версия)
• Qwen 2.5 72B (Alibaba Cloud)
• Mistral Large 2 (Mistral AI)

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

1 Критерии оценки: на что обращают внимание судьи

Мало просто сказать модели «оцени, галлюцинация или нет». Нужно задать чёткие критерии. Я использовал три оси:

• Следование контексту — ответ должен быть основан исключительно на предоставленном контексте. Если модель добавляет факты из своего обучения — это уже галлюцинация.
• Фактическая точность — числа, даты, имена. Даже единичное несовпадение с контекстом — красный флаг.
• Непротиворечивость — ответ не должен внутренне противоречить сам себе (например, сначала утверждать одно, потом отрицать).

Промпт для судей я сделал единым для всех моделей, чтобы не вносить дополнительный шум. Вот его ключевая часть:

SYS_PROMPT = """
Ты — эксперт по оценке качества ответов RAG-систем.

Тебе будут предоставлены:
- Контекст (документ, на основе которого генерировался ответ)
- Вопрос пользователя
- Ответ модели

Оцени ответ по следующим критериям:
1. Соответствие контексту: есть ли в ответе факты, отсутствующие в контексте?
2. Фактическая точность: все ли числа, даты, имена совпадают с контекстом?
3. Внутренняя согласованность: нет ли противоречий внутри ответа?

Ответ должен быть только в формате JSON:
{"содержит_галлюцинацию": true/false, "обоснование": "..."}
"""

Формат JSON обязателен — так проще парсить и агрегировать голоса. Кстати, если модель возвращает невалидный JSON (такое бывает редко, но бывает), я просто исключаю её голос из консенсуса.

2 Агрегация голосов: простая, но эффективная

Консенсус я считаю как средний балл (пропорция голосов «галлюцинация»). Порог — 0.5 (то есть если 3 из 6 или больше сказали «да» — считаем ответ галлюцинацией). Но можно варьировать порог в зависимости от желаемого trade-off между precision и recall. В нашем случае F1-оптимальным оказался порог 0.33 — то есть если хотя бы две модели из шести посчитали ответ галлюцинацией, это уже сигнал. Это связано с тем, что модели склонны скорее недоговаривать, чем перебарщивать.

Для сравнения я прогнал одиночные оценки каждой модели. Результаты:

Консенсус дал прирост AUROC примерно на 4-5% по сравнению с лучшей одиночной моделью. Это не революция, но для training-free подхода — отличный результат. Главное: консенсус менее подвержен капризам единичных моделей (например, Gemini почему-то начал всё подряд помечать как галлюцинацию на последней сотне примеров — ансамбль сгладил этот выброс).

Скелет в шкафу: как нейросети нашли ошибки в RAGTruth

RAGTruth — это популярный бенчмарк для оценки детекторов галлюцинаций. Он содержит около 2000 пар <контекст, вопрос, ответ> с разметкой «галлюцинация» или «нет». Считается эталоном. Но когда я посмотрел на примеры, где все шесть моделей единогласно указывали на галлюцинацию, а метка была «нет», я заподозрил неладное.

Вручную проверил 40 таких расхождений. В 33 случаях (82.5%) модели оказались правы — ответ действительно содержал галлюцинацию, которую пропустили разметчики. Типичные ошибки разметчиков:

• Не заметили подмену даты (написано «2023 год», а в контексте «2022»)
• Пропустили небольшое искажение факта (например, «компания X выпустила продукт Y» — в реальности продукт Y был от Z, а X только партнёр)
• Приняли ответ, который выглядит правдоподобно, но не основан на контексте (модель добавила background knowledge, которого нет в предоставленных документах)

Это не ошибка авторов RAGTruth — разметка сложных кейсов тяжела даже для экспертов. Но факт остаётся: эталон, на котором учат и тестируют детекторы, сам содержит ошибки. Это подрывает доверие к любым его метрикам. Наш training-free ансамбль выявил «грязные» примеры, которые можно отфильтровать и получить более чистую разметку для future work.

Как НЕ надо делать: частые ошибки при внедрении

Попробую вас уберечь от граблей, на которые наступил сам.

• Ошибка 1: использовать один и тот же промпт для всех моделей без адаптации под их особенности. Некоторые модели (например, Llama) очень чувствительны к формату вывода. Если они не могут сгенерировать JSON — включайте fallback: просите просто выдать “yes”/“no” и парсите это. Я добавил if-else на парсинг, и процент ошибок упал с 3% до 0.5%.
• Ошибка 2: игнорировать распределение голосов. Консенсус 5 из 6 — гораздо более уверенный сигнал, чем 3 из 6. Используйте не просто бинарный порог, а уровень уверенности (confidence score) — например, можно сравнить с тем, как работает роутинг галлюцинаций в статье про Jacobian Lens от Anthropic, где тоже есть градуальная оценка.
• Ошибка 3: не проверять согласованность судей на синтетических примерах. Прежде чем гонять ансамбль на реальных данных, подбросьте ему заведомо корректные и заведомо галлюцинирующие ответы — убедитесь, что модели не падают в крайности (всегда “нет” или всегда “да”). Если одна модель даёт 100% совпадение с другой — возможно, у них общий обучающий шум.

Когда консенсус бессилен

Наш подход не панацея. Он плохо ловит тонкие галлюцинации — когда модель перефразирует контекст близко к тексту, но меняет смысл на противоположный инверсией (например, «не было X» вместо «было X»). Модели-судьи часто пропускают такие случаи, потому что фразы похожи. Тут нужны более сложные методы — например, анализ векторов внимания, как описано в материале про misalignment внимания, или линейные разделители в эмбеддингах (см. «Когда LLM врет: отлавливаем галлюцинации линейкой в векторном пространстве»). Комбинация этих методов с нашим консенсусом даст ещё лучший результат — уже есть данные, что наложение консенсуса на эмбеддинговый классификатор даёт AUROC 0.91+.

Кстати, если вы хотите пойти ещё дальше и автоматически чинить такие галлюцинации, рекомендую глянуть самовосстанавливающийся RAG. Там как раз описана схема: детектор -> коррекция без внешнего API. Наш детектор может служить триггером в таком пайплайне.

Итоговый чеклист для внедрения в прод

Коротко — что нужно сделать прямо сейчас, если хотите поднять качество своего RAG:

1. Поднимите лямбды OCC-RAG или используйте готовые API моделей — выберите 4-6 разных LLM.
2. Скопируйте мой промпт с JSON-ответом — адаптируйте под свой домен (добавьте специфичные правила).
3. Прогоните на тестовой выборке (100-500 примеров), выставьте порог консенсуса.
4. Сравните результаты с метриками вроде attribution и specificity — они хороши для прозрачности.
5. Проинспектируйте расхождения: если модели голосуют «галлюцинация», а метка «нет» — проверьте вручную 10-20 примеров. Скорее всего, найдёте ошибки разметки, как я.

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

А если хотите, чтобы я написал детальную инструкцию по конвейеризации такого пайплайна с помощью RAG Doctor — свистните в комментариях. Это CLI-инструмент, который автоматически запускает диагностику, но с нашей доработкой он сможет не только диагностировать, но и предлагать фиксы на основе голосования LLM.

Подписаться на канал