LLM-as-a-judge: как оценивать RAG-системы и находить слабые места

Ваша RAG-система врет. И вы об этом даже не догадываетесь

Вы потратили три месяца на построение идеального конвейера: чанкинг, эмбеддинги, семантический поиск. Запускаете первый промпт - ответ выглядит адекватно. Второй - тоже. Десятый - уже сомнения. Сотый - полная катастрофа. Пользователи жалуются, что система то генерирует откровенный бред, то цитирует устаревшие документы, то просто молчит, когда должна говорить.

Классические метрики вас обманывают. BLEU, ROUGE, точность совпадения токенов - все это мертвые цифры, которые не имеют отношения к смыслу. Вы можете получить 95% по ROUGE-L и при этом полностью исказить факты из найденных документов. Проблема в том, что RAG - это не поисковая система и не генеративная модель по отдельности. Это сложный симбиоз, где ошибка в одном компоненте каскадом разрушает весь результат.

LLM-судья: не замена эксперту, а его тысячекратное умножение

Забудьте про "объективную оценку". Ее не существует. Любой эксперт субъективен. Но если он последователен в своей субъективности - его оценки можно использовать для сравнения. LLM-as-a-judge работает по тому же принципу: это не истина в последней инстанции, а эталонный измерительный инструмент с известной погрешностью.

На 17 марта 2026 года модель GPT-4.5 Turbo достигает 91-94% согласия с человеческими экспертами в оценке релевантности ответов RAG. Claude 3.7 Opus показывает 89-92% на тех же задачах. Даже открытые модели типа Llama 3.1 405B выдают 83-87% - достаточно для скрининга тысяч ответов с последующей ручной проверкой спорных случаев.

Пять критериев, которые покажут, где ваша RAG истекает кровью

Прежде чем запускать оценку, определите - что именно вы хотите измерить. Вот критерии, которые реально работают в 2026 году:

• Семантическая точность (Semantic Faithfulness): Ответ фактологически соответствует извлеченному контексту? Нет ли галлюцинаций или добавления фактов "от себя"?
• Контекстуальная релевантность (Contextual Relevance): Найденные документы действительно отвечают на вопрос? Или поисковый модуль притащил мусор?
• Полнота ответа (Answer Completeness): Ответ покрывает все аспекты вопроса или упускает ключевые детали?
• Консистентность ссылок (Citation Consistency): Каждое утверждение в ответе подкреплено конкретным фрагментом контекста? Нет ли цитирования "для галочки"?
• Временная актуальность (Temporal Relevance): Использует ли система самые свежие данные при их наличии? Не цитирует ли устаревшие документы, когда есть новые?

1Готовим тестовый набор: не делайте эту ошибку

Самый частый промах - тестировать RAG на случайных вопросах. Ваш набор должен отражать реальные use cases с известной сложностью. Разделите вопросы на категории:

• Простые фактологические: "Какая дата подписания договора?". Здесь должен работать даже базовый RAG
• Многоаспектные: "Какие условия расторжения договора и какие штрафные санкции?". Проверяет полноту
• Контекстуальные: "Как изменились правила с марта 2025 года?". Тест на временную актуальность
• Сложные, требующие Reasoning: "Если поставщик нарушил п.3.2, какие у нас варианты действий?". Здесь часто ломаются даже продвинутые системы

Для каждого вопроса подготовьте "идеальный контекст" - документы, которые точно содержат ответ. Это не ground truth ответ, а эталонные источники. LLM-судья будет сравнивать реальный ответ RAG с тем, что можно извлечь из этих источников.

# Пример структуры тестового набора
test_cases = [
    {
        \"question\": \"Каков размер штрафа за просрочку поставки по договору №123?\",
        \"category\": \"factual\",
        \"ideal_contexts\": [\"doc_contract_123.txt\", \"doc_penalties.pdf\"],
        \"difficulty\": \"easy\"
    },
    {
        \"question\": \"Сравните условия досрочного расторжения в договорах 2024 и 2025 годов\",
        \"category\": \"temporal\",
        \"ideal_contexts\": [\"contract_2024.md\", \"contract_2025.md\", \"amendment_2025.pdf\"],
        \"difficulty\": \"hard\"
    }
]

2Промпт для судьи: одна запятая может все испортить

Качество оценки на 70% определяется промптом. Распространенная ошибка - просить LLM \"оценить ответ от 1 до 5\". Результат будет случайным. Вместо этого задайте четкую схему оценки с бинарными или категориальными решениями.

Вот промпт, который реально работает в 2026 году (адаптируйте под свои критерии):

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

ВОПРОС: {question}

КОНТЕКСТ, предоставленный RAG (источники):
{retrieved_context}

ОТВЕТ RAG-системы:
{generated_answer}

Проанализируй ответ относительно контекста по следующим критериям:

1. СЕМАНТИЧЕСКАЯ ТОЧНОСТЬ: Все факты в ответе непосредственно следуют из предоставленного контекста?
   - ДА: Если каждое утверждение можно явно вывести из контекста
   - ЧАСТИЧНО: Если есть небольшие дополнения или интерпретация, но без искажения фактов
   - НЕТ: Если ответ содержит утверждения, отсутствующие в контексте или противоречащие ему

2. КОНТЕКСТУАЛЬНАЯ РЕЛЕВАНТНОСТЬ: Предоставленный контекст достаточен для ответа на вопрос?
   - ДА: Контекст полностью покрывает вопрос
   - ЧАСТИЧНО: Контекст покрывает только часть вопроса
   - НЕТ: Контекст нерелевантен или недостаточен

3. ПОЛНОТА: Ответ покрывает все аспекты вопроса, имеющиеся в контексте?
   - ПОЛНЫЙ: Использованы все релевантные части контекста
   - ЧАСТИЧНЫЙ: Упущены некоторые важные аспекты
   - ПОВЕРХНОСТНЫЙ: Ответ слишком краток и пропускает ключевые детали

Верни ответ строго в формате JSON:
{
  \"semantic_faithfulness\": \"ДА|ЧАСТИЧНО|НЕТ\",
  \"contextual_relevance\": \"ДА|ЧАСТИЧНО|НЕТ\",
  \"completeness\": \"ПОЛНЫЙ|ЧАСТИЧНЫЙ|ПОВЕРХНОСТНЫЙ\",
  \"explanation\": \"Краткое обоснование по каждому критерию\"
}

3Запускаем конвейер оценки: автоматизация или смерть

Ручной запуск сотен оценок - самоубийство. Пишите скрипт, который:

1. Берет вопрос из тестового набора
2. Пропускает его через вашу RAG-систему, фиксируя ответ и использованный контекст
3. Отправляет триаду (вопрос, контекст, ответ) в LLM-судью
4. Парсит результат и сохраняет с метаданными

import json
from openai import OpenAI  # Используем актуальный клиент на 2026 год

client = OpenAI(api_key=api_key)

def evaluate_rag_response(question, retrieved_context, generated_answer):
    prompt = f\"\"\"...промпт из предыдущего шага...\"\"\"
    
    try:
        # GPT-4.5 Turbo - самая стабильная модель для оценки на март 2026
        response = client.chat.completions.create(
            model=\"gpt-4.5-turbo\",
            messages=[{\"role\": \"user\", \"content\": prompt}],
            temperature=0.1,  # Минимальная случайность для согласованности
            response_format={ \"type\": \"json_object\" }  # JSON режим
        )
        
        evaluation = json.loads(response.choices[0].message.content)
        return evaluation
    except Exception as e:
        print(f\"Ошибка оценки: {e}\")
        return None

# Запуск для всех тестовых случаев
evaluation_results = []
for test_case in test_cases:
    # 1. Получаем ответ от вашей RAG
    rag_answer, used_context = call_your_rag_system(test_case['question'])
    
    # 2. Оцениваем
    eval_result = evaluate_rag_response(
        question=test_case['question'],
        retrieved_context=used_context,
        generated_answer=rag_answer
    )
    
    # 3. Сохраняем с метаданными
    evaluation_results.append({
        'question': test_case['question'],
        'category': test_case['category'],
        'rag_answer': rag_answer,
        'evaluation': eval_result,
        'timestamp': datetime.now().isoformat()
    })

4Анализируем слабые места: где ваша система дырявая как решето

Собрали 500 оценок. Что дальше? Сводите результаты в наглядную таблицу по категориям вопросов. Ищите паттерны:

• Если семантическая точность падает на сложных вопросах - проблема в reasoning-способностях LLM. Модель не умеет правильно интерпретировать сложный контекст
• Если контекстуальная релевантность низкая - горит поисковый модуль. Векторная база возвращает не то, что нужно
• Если полнота страдает на многоаспектных вопросах - возможно, нужно увеличить количество извлекаемых чанков или улучшить суммаризацию

Пример анализа на Python:

import pandas as pd
from collections import Counter

# Преобразуем результаты в DataFrame
df = pd.DataFrame([
    {
        'question': r['question'],
        'category': r['category'],
        'faithfulness': r['evaluation']['semantic_faithfulness'],
        'relevance': r['evaluation']['contextual_relevance'],
        'completeness': r['evaluation']['completeness']
    }
    for r in evaluation_results
])

# Агрегируем по категориям
weak_spots = {}
for category in df['category'].unique():
    category_df = df[df['category'] == category]
    
    faithfulness_fail_rate = (category_df['faithfulness'] == 'НЕТ').mean() * 100
    relevance_fail_rate = (category_df['relevance'] == 'НЕТ').mean() * 100
    
    weak_spots[category] = {
        'faithfulness_fail_%': faithfulness_fail_rate,
        'relevance_fail_%': relevance_fail_rate,
        'sample_questions': category_df['question'].tolist()[:3]  # Примеры вопросов
    }

print(\"Слабые места:\")
for category, stats in weak_spots.items():
    print(f\"{category}: точность падает в {stats['faithfulness_fail_%']:.1f}% случаев, \"
          f\"релевантность - в {stats['relevance_fail_%']:.1f}%\")
    if stats['faithfulness_fail_%'] > 20:
        print(f\"  КРИТИЧЕСКОЕ: вопросы типа '{stats['sample_questions'][0]}'\")

5Итеративное улучшение: фиксим то, что сломано

Нашли проблему? Не пытайтесь чинить все сразу. Приоритезируйте:

1. Критические ошибки семантической точности (галлюцинации) - это убивает доверие к системе. Решения: добавьте верификацию ответов через модели-детекторы, уменьшите temperature, добавьте промптинговые ограничения (\"отвечай только на основе контекста\").
2. Проблемы релевантности поиска - модернизируйте поисковый модуль. Попробуйте гибридный поиск (семантический + ключевые слова), пересмотрите чанкинг, добавьте re-ranking модель. На 2026 год исследования показывают, что улучшение поиска дает в 2.1 раза больше прироста качества, чем улучшение генерации.
3. Неполные ответы - увеличьте количество извлекаемых чанков, поэкспериментируйте с методами суммаризации, добавьте пострпроцессинг, который проверяет покрытие всех аспектов вопроса.

Три смертельные ошибки при использовании LLM-судьи (и как их избежать)

1. Использование одной модели и для RAG, и для оценки. Если ваша RAG использует GPT-4.5, а судья - тоже GPT-4.5, вы получите систематическую ошибку. Модель будет более снисходительна к своим же \"типичным\" ошибкам. Решение: используйте разные модели семейств. Например, RAG на GPT-4.5, оценку на Claude 3.7 Opus.

2. Оценка без эталонного контекста. Помните: LLM-судья не проверяет фактологическую правильность ответа в абсолютном смысле. Он проверяет соответствие между ответом и тем контекстом, который вы ему предоставили. Если вы не фиксируете, какие именно документы нашел RAG, оценка теряет смысл.

3. Слепая вера в оценки. LLM-судья ошибается. На март 2026 года даже лучшие модели ошибаются в 6-15% случаев, в зависимости от сложности. Всегда выделяйте 5-10% бюджета на ручную проверку случайной выборки оценок. Особенно тех, которые помечены как \"критические ошибки\".

Что дальше? RAG-оценка в 2027 году

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

Но главное останется неизменным: без систематической оценки ваша RAG-система - черный ящик, который рано или поздно начнет врать в самый неподходящий момент. Начните с малого: 50 тестовых вопросов, три критерия, еженедельный прогон. Через месяц вы будете знать о слабых местах своей системы больше, чем 90% команд на рынке.

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

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