Closed-loop evaluation для LLM agents
У LLM-agent продукта уже есть offline benchmark: для каждого изменения видно, стала ли метрика лучше или хуже. Как превратить результаты evaluation в цикл улучшения системы, не скатываясь в слепую автоматическую оптимизацию под шумный benchmark?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Нужен не один benchmark, а controlled improvement loop: фиксируем product goal, строим versioned eval set и rubric, генерируем гипотезы, прогоняем offline eval, вручную проверяем спорные случаи, затем выпускаем canary/A-B только для изменений, которые улучшают качество без регрессий по latency, safety и cost.
Полный разбор
Начать нужно с границы применимости benchmark. Он должен измерять конкретное product quality: например, correctness, faithfulness, visual/design quality, tool-use success, user satisfaction proxy, latency и cost. Если benchmark состоит только из LLM-as-judge score без калибровки на human labels, его нельзя использовать как единственный оптимизационный сигнал.
Практичный loop выглядит так. Каждая версия prompts, policies, retriever, tool planner, model choice или post-processing получает version id. Для нее запускается offline suite: golden tasks, regression cases из production failures, adversarial cases, latency/cost checks и safety checks. Результаты сравниваются с baseline, но решение принимается не только по average score: нужно смотреть per-slice regressions, confidence judge-а, disagreement between judges и ручную выборку спорных примеров.
Дальше evaluation должен порождать гипотезы: где агент ошибается, какой компонент виноват, что можно поменять. LLM можно использовать для генерации candidate fixes или experiment ideas, но не для автодеплоя. Для каждого fix-а запускается тот же eval suite. Если улучшение устойчивое, оно идет в canary или A/B test с online метриками: user success, escalation rate, rework rate, thumbs up/down, p95 latency, cost per task. Если offline улучшение не подтверждается online, кейсы добавляются обратно в regression set.
Ключевые guardrails: holdout eval set, запрет подглядывания в gold answers при prompt search, human calibration для LLM-as-judge, versioned datasets, rollback plan, quality gates по safety/latency/cost и monitoring после выката. Тогда closed loop ускоряет итерации, но не превращает продукт в систему, которая переобучается на собственный шумный тест.
Теория
LLM-agent evaluation обычно состоит из offline regression suite, LLM/human judging, component metrics и online product metrics. Closed loop полезен только когда offline signal калиброван и связан с реальным пользовательским outcome.
Типичные ошибки
- Оптимизировать только общий LLM-as-judge score без human calibration и slice analysis.
- Автоматически выкатывать prompt/model changes из-за небольшого offline улучшения.
- Не хранить versioned eval sets, prompts and model configs, поэтому результаты нельзя воспроизвести.
- Игнорировать regressions по latency, cost, safety и редким production failure cases.
Как отвечать на собеседовании
- Сначала отдели eval signal, hypothesis generation и deployment decision.
- Обязательно назови holdout/regression set и ручную проверку спорных примеров.
- Заверши online validation: canary или A/B test с product metrics.