Evaluation: как понять что LLM не сломался после деплоя

Цели урока

• Понять, почему LLM нельзя тестировать как обычный software (недетерминизм, отсутствие единственного правильного ответа)
• Разобраться, почему BLEU/ROUGE не работают для open-ended generation - и что использовать вместо них
• Построить LLM-as-Judge evaluation с structured output, pairwise comparison и защитой от position bias
• Освоить RAGAS для оценки RAG-систем и Langfuse для production evaluation pipeline
• Встроить eval в CI/CD с regression detection и threshold-based blocking на каждый PR

Как понять что LLM стал хуже после смены промпта? Интуиция не работает - модель стохастична. Нужен eval suite. Без него каждый деплой - русская рулетка. Notion AI обнаружили это болезненно: обновили system prompt, все ручные тесты зелёные, деплой прошёл - а через два дня support захлёбывается жалобами. Ответы стали на 40% длиннее. User satisfaction упал на 15%. Команда не измеряла conciseness. Systematic evaluation - это страховка от того, что не знаешь что не знаешь.

• LMSYS Chatbot Arena - крупнейший public benchmark, 500K+ голосов. ELO-рейтинг моделей обновляется в реальном времени на основе pairwise human evaluation
• OpenAI использует LLM-as-Judge + human eval + red teaming для каждого релиза модели. Eval suite для GPT-4o занимал месяцы
• RAGAS (RAG Assessment) стал стандартом для оценки RAG-систем: faithfulness, answer relevancy, context precision, context recall - четыре независимых LLM-judge вызова
• Langfuse собрал USD 4M seed (2023) на open-source LLM observability + evaluation platform. Self-hosted бесплатно, cloud USD 0.01 per 1K events

Как сложилась оценка LLM

Систематическая оценка языковых моделей - молодая практика. **HELM (Stanford CRFM, 2022)**, Holistic Evaluation of Language Models, продвинул идею измерять модели по множеству задач и метрик, а не по одному бенчмарку. По мере того как ответы моделей становились всё более свободными, фиксированных эталонов перестало хватать. **LLM-as-a-judge, популяризированный Zheng et al. вместе с MT-Bench (2023)**, использовал сильную модель для оценки ответов другой модели, сделав практичной оценку свободного текста в масштабе. Вместе эти идеи лежат в основе разделения на offline-оценку на фиксированном наборе и online-оценку на живом трафике.

Предварительные знания

• Production Prompt Patterns: system/user/assistant, Few-Shot, Chain-of-Thought

Почему тестирование LLM - нерешённая проблема

Промпт изменился. Все ручные тесты зелёные. Деплой прошёл. Через два дня support захлёбывается: ответы стали на 40% длиннее, одну мысль повторяют разными словами, user satisfaction упал на 15%. Команда не заметила деградацию - потому что не измеряла conciseness. Это реальный кейс Notion AI, ноябрь 2023.

Интуиция не работает - модель стохастична. Один и тот же промпт при `temperature > 0` даёт разные ответы каждый раз. Нет единственного "правильного" ответа. Ответ может быть **фактически верным, но плохо сформулированным** - или **идеально написанным, но содержащим галлюцинацию**. Без eval suite каждый деплой - русская рулетка.

LLM-система оценивается по нескольким **измерениям одновременно**: factual correctness (нет галлюцинаций), relevance (ответ соответствует вопросу), conciseness (не слишком длинный), tone (стиль бренда), safety (нет вредного контента). Улучшение по одному измерению легко вызывает деградацию по другому - именно поэтому нужен eval suite, а не ручная проверка.

BLEU, ROUGE, BERTScore - и почему они не работают для LLM

BLEU придумали в 2002 году для машинного перевода. Идея проста: считать, сколько n-gram из hypothesis встречается в reference. Работает, когда есть один "правильный" перевод. Но у LLM ответов нет единственно правильного варианта - и именно здесь BLEU ломается. Высокий BLEU score не значит хороший ответ. Низкий BLEU не значит плохой.

ROUGE - та же идея, но для summarization: recall вместо precision. ROUGE-L измеряет longest common subsequence между reference и generated. Проблема та же: метрика считает пересечение токенов, не смысл. "14 дней" и "две недели" - ROUGE скажет: разные. BERTScore через embeddings скажет: одно и то же.

BERTScore решает проблему синонимов: вместо сравнения токенов - сравнение embeddings. В production удобно использовать `text-embedding-3-small` (`0.02/1M` tokens) как proxy. Cosine similarity между embedding reference и embedding generated - это и есть семантическая близость. "14 дней" и "две недели" получат similarity ~0.92. Бессмысленный ответ - ~0.30.

**ROUGE-L = 0.85 не означает "ответ хороший".** Ответ может содержать все ключевые слова эталона, но быть бессмысленным - или наоборот, давать правильный ответ другими словами и получить ROUGE 0.20. Автоматические метрики - фильтр для regression testing, не финальная оценка качества.

LLM-as-Judge и RAGAS: модель оценивает модель

Исследование LMSYS (2023): оценки GPT-4 коррелируют с человеческими на **85%+** - сопоставимо с inter-annotator agreement между людьми. Это прорыв. Значит, GPT-4o как судья - почти человек, но дешевле в 1000 раз и не устаёт.

Для RAG-систем стандарт - **RAGAS** (RAG Assessment). Он измеряет четыре компонента: faithfulness (ответ не противоречит контексту), answer relevancy (ответ релевантен вопросу), context precision (в контексте нет лишнего шума), context recall (контекст покрывает нужную информацию). Каждый компонент - отдельный LLM-as-judge вызов. Langfuse интегрирует RAGAS прямо в observability pipeline.

**G-Eval** (LMSYS, 2023) - более надёжный вариант LLM-as-judge: модель генерирует chain-of-thought reasoning перед финальным score. Это снижает variance оценок и повышает корреляцию с человеком до 88%+. Для pairwise comparison - обязательна рандомизация порядка ответов: GPT-4 и Claude документально склонны давать более высокий score первому ответу в prompt (position bias).

**Position bias** - задокументированная проблема LLM-as-Judge. GPT-4 и Claude склонны давать более высокие оценки первому ответу в prompt. Решение: запускать каждую оценку дважды с перестановкой порядка и усреднять результат. Если при (A,B) победил A, а при (B,A) победил B - это tie.

Human Evaluation: когда модель не может оценить модель

LLM-as-Judge не работает там, где модель-судья имеет те же слепые пятна, что и оцениваемая модель. Галлюцинации: судья может не знать правильный ответ и оценить ложь высоко. Safety в медицине: "это лекарство безопасно" - судья не врач. Культурные нюансы: тон, уместность, идиомы - модель не чувствует контекст. Здесь нужен человек.

Eval Pipeline в CI/CD: Langfuse и автоматические проверки

Eval pipeline в CI/CD - это та же идея, что и обычные тесты: **не мержить PR, если eval score упал ниже порога**. Разница - LLM eval использует scoring вместо pass/fail. Каждое изменение промпта, модели или конфигурации проверяется автоматически на golden dataset.

**Langfuse** (open-source, USD 0 self-hosted) интегрирует evaluation прямо в observability. Каждый trace в production можно пометить eval score: LLM-judge запускается async после response, результаты агрегируются в дашборде. При падении avg score ниже threshold - алерт в Slack. Это закрывает петлю: деплой -> трекинг -> evaluation -> алерт.

Рекомендуемый ритм для production: **при каждом PR** - автоматические метрики + LLM-judge на golden dataset из 50-200 cases (~USD 1-8 на прогон). **Еженедельно** - расширенный eval на 500+ cases + RAGAS для RAG-компонент. **Ежемесячно** - human eval на 50-100 cases для калибровки LLM-judge и выявления blind spots.

BLEU score показывает качество LLM ответа

BLEU создан для машинного перевода (2002), где есть один правильный перевод. Для open-ended generation он бесполезен: высокий BLEU не значит хороший ответ, низкий - не значит плохой

BLEU считает пересечение n-gram между hypothesis и reference. Если модель дала правильный ответ другими словами - BLEU накажет. Если скопировала бессмысленный reference - BLEU похвалит. В академических paper-ах BLEU ещё встречается для сравнения translation систем. В production LLM evaluation - это антипаттерн. Используй LLM-as-Judge или embedding similarity.

Evaluation LLM-систем

• LLM нельзя тестировать exact match: один промпт - много корректных ответов. Нужен scoring по измерениям
• BLEU/ROUGE - для машинного перевода и summarization. Для open-ended LLM generation - неправильный инструмент
• BERTScore через embeddings (text-embedding-3-small, 1536 dim) видит синонимы - лучшая автоматическая метрика
• LLM-as-Judge: GPT-4o коррелирует с человеком на 85%+. G-Eval + chain-of-thought поднимает до 88%+. Position bias устраняется рандомизацией
• RAGAS - стандарт для RAG: faithfulness, answer relevancy, context precision, context recall
• CI/CD eval pipeline: каждый PR с изменением промпта - automated metrics + LLM-judge. Langfuse для production monitoring

Что дальше

Evaluation показывает проблемы. Следующий шаг - обработка ошибок и сбоев, которые evaluation выявляет.

• Error Handling для LLM — Eval обнаруживает деградацию, error handling обрабатывает runtime failures: hallucinations, timeouts, malformed output
• Guardrails — Eval + guardrails = defense in depth: eval ловит quality issues, guardrails - safety issues
• Observability — Eval scores - часть observability dashboard. Langfuse связывает evaluation с production monitoring

Связанные уроки

• aie-06-prompt-patterns — Eval измеряет, работают ли промпты на деле
• aie-32-error-handling-llm — Eval вскрывает режимы отказа для обработки
• aie-33-guardrails — Eval подтверждает эффективность guardrails
• aie-35-observability — Production-трейсы питают офлайн-оценку
• ml-05-evaluation — Та же дисциплина train/test для качества модели
• stat-05-hypothesis