LLM как судья
Тема дорожной карты · Большие языковые модели (LLM)
LLM-as-judge использует сильную модель (обычно уровня GPT-4) как судью для оценки выходов другой модели по рубрикам корректности, полезности или стиля — попарно (A vs B) или одиночной оценкой по шкале. Это дёшево масштабирует эвал, но наследует смещения: позиционное, к многословности, self-preference, дрейф рубрики. Смягчайте перестановкой пар, обоснованиями chain-of-thought, калибровкой по небольшому human-labeled срезу и эталонными ответами. Используйте для регрессионных тестов на итерациях промпта и модели, но не как единственный критерий релиза.
Как это работает
LLM как судья — как вы меряете, хороша ли LLM-powered система. Типы eval: ground-truth (есть правильные ответы — считаете accuracy/F1/BLEU/ROUGE), LLM-as-judge (сильная модель оценивает output по критериям — дёшево + масштабируется), human eval (gold standard, дорого), pairwise preference, online-метрики (A/B-тест conversion, task completion). Инструменты: OpenAI Evals, Promptfoo, LangSmith, Inspect AI, кастомные harness. Стройте eval-сет ДО релиза; итерируйте промпты против него.
Когда применять
Стройте eval с первого дня — они превращают "vibes" в измерение. Начните с 50-200 hand-curated примеров, покрывающих поверхность задачи (happy path, edge cases, adversarial). LLM-as-judge для быстрой итерации; периодически валидируйте human eval. Трекайте regression (изменение промпта не должно тихо ухудшать существующие кейсы). Пиньте eval-результаты к версиям модели + промпта — A/B-дебаг возможен.
Типичные ошибки
Ловушки LLM как судья: BLEU/ROUGE как мера качества (слабо коррелируют с человеческим суждением); LLM-judge biased к многословным ответам (pairwise вместо absolute); eval-сет не отражает production-распределение (lab-good, prod-bad); нет автоматического CI на изменения промптов (regression-ы едут незаметно).