agent-platform-eval-flywheel

Скилл Agent Platform Eval Flywheel предназначен для оценки и последовательного улучшения качества GenAI-моделей и агентов с помощью Agent Platform GenAI Evaluation SDK. Он охватывает подготовку evaluation dataset, запуск inference, выбор метрик, разбор неудач и повторные итерации после исправления промпта, кода или инструмента. Область применения включает оценку агента, модели, модели на Agent Platform endpoint и Model-as-a-Service; для endpoint и MaaS исходный workflow отдельно отсылает к процедурам deployment. Первый этап — подготовка данных. Если есть готовые одноходовые или многоходовые случаи, используется EvaluationDataset с EvalCase, prompt, responses и reference. Табличные данные можно передать из CSV, BigQuery или Sheets через pandas DataFrame с колонками prompt, response и reference. При отсутствии данных скилл допускает серверную генерацию сценариев через client.evals.generate_conversation_scenarios; для этого нужен agent или agent_info, обязательный config и user_scenario_count от 1 до 100. Для ADK session dumps рекомендуется отдельный parse_adk_traces.py, а не ручное преобразование структуры. Второй этап — inference. Его можно пропустить, если traces уже получены из production logs или replay. Для оценки агента передаётся callable, оборачивающий ADK Agent или App; для оценки модели — идентификатор модели. Для синтетических многоходовых сценариев предусмотрен user_simulator_config с ограничением max_turn. DataFrame также может быть src напрямую, без ручного оборачивания каждой строки в EvalCase. Третий этап обязателен: dataset передаётся в client.evals.evaluate вместе с метриками. Для многоходового агента доступны multi_turn_task_success, multi_turn_trajectory_quality, multi_turn_tool_use_quality, multi_turn_general_quality, final_response_quality и final_response_match. Для одноходовой модели скилл предлагает general_quality, text_quality и instruction_following. Фиксированные rubric-метрики дополняют проверку hallucination, grounding и safety. Если готовой метрики недостаточно, используется RubricMetric, LLMMetric или CodeExecutionMetric. Для LLMMetric необходимо явно задать judge_model, иначе случаи завершаются ошибкой INVALID_ARGUMENT. Результат нельзя пересказывать по памяти или по одному удачному примеру. Его следует сохранить в JSON для машинного сравнения и HTML для просмотра, затем прочитать summary_metrics и eval_case_results. Встроенный inspect_results.py умеет отфильтровать failing-only. Низкий multi_turn_task_success указывает на незавершение цели, неправильный tool call или раннее завершение. Низкое качество trajectory говорит об избыточных вызовах или слабом планировании. Ошибки grounding требуют привязки ответа к переданному контексту, а hallucination — проверки, что инструмент действительно вернул заявленные данные. Низкое instruction_following обычно исправляется явным повторением ограничений в system instruction. Четвёртый этап — анализ повторяющихся отказов. Если на одной метрике накопилось десять и более failures, скилл предлагает Error Analysis service, который группирует их в темы; сервис поддерживает multi_turn_task_success и multi_turn_tool_use_quality и работает в global region. Пятый этап — оптимизация: исправление должно целиться в измеренную метрику, после чего выполняется повторная оценка и compare_results.py с baseline и candidate. Успешным считается не единичный pass, а улучшение целевой метрики без регрессии остальных и прохождение всех кейсов. Workflow ожидает несколько итераций, а не снижение порога или удаление нестабильных случаев.