agent-evaluation

Agent Evaluation — скилл MLflow для систематической проверки и улучшения качества GenAI-агентов. Он подходит, когда нужно понять, почему агент выбирает неподходящие инструменты, даёт неполные ответы, расходует слишком много ресурсов или нестабильно выполняет одну и ту же задачу. Источник описывает полный цикл оценки: сначала запускается агент и анализируются traces, затем выбираются критерии качества и scorers, подготавливаются datasets, выполняется пробная проверка и только после этого запускается основная оценка. Скилл можно применять как для всей цепочки, так и для отдельного этапа — настройки трассировки, подготовки набора данных, определения scorer или разбора результата. Ключевое ограничение workflow — использование штатных API MLflow. Для датасетов предлагается mlflow.genai.datasets.create_dataset(), для готовых и зарегистрированных оценщиков — mlflow.genai.scorers, для судей — mlflow.genai.judges.make_judge(), а запуск выполняется через mlflow.genai.evaluate(). Скилл специально запрещает собирать собственный мини-фреймворк из тестовых файлов и самописных циклов: такой подход теряет наблюдаемость датасетов, traces, scorers и результатов внутри эксперимента. Для командных или повторяемых проверок это важно, потому что результат должен быть связан с экспериментом и оставаться доступным для следующих итераций. Перед началом нужны MLflow версии 3.8 или новее, настроенная среда и рабочая интеграция трассировки. В инструкции отдельно проверяются MLFLOW_TRACKING_URI и MLFLOW_EXPERIMENT_ID; если они уже заданы, дополнительная настройка не требуется. Трассировка должна работать до оценки, иначе нельзя надёжно объяснить, какие действия привели к ответу агента. В автоматизированном режиме назначение агента берётся из его документации или кода, а критерии не следует выдумывать: сначала фиксируются задачи и ожидаемое поведение, затем из них выводятся названия и правила scorers. Зарегистрированные в эксперименте scorers нужно использовать, а новые — зарегистрировать до запуска оценки. Подготовка данных начинается с поиска уже существующих datasets, чтобы не создавать дубликаты. Если подходящего набора нет, скилл предлагает сначала провести небольшую sanity-проверку, затем собрать полноценный набор из реальных данных. Для проектов с корпусом могут использоваться генераторы evals, а если корпуса нет, предпочтительны 50–100 репрезентативных запросов из production-логов или истории использования. Очень маленькие наборы не дают статистически надёжных выводов: менее тридцати вопросов годятся лишь для локальной проверки, но не для уверенного сравнения версий. Перед дорогим полным прогоном обязателен dry run на трёх вопросах. Нужно проверить, что ответы непустые, требуемые tools действительно вызываются, а значения scorers не превращаются в нули или None. В исходной инструкции отдельно отмечено, что возвращаемые строки pass/fail могут быть молча отброшены как неподходящие значения; для безопасной регистрации судьи нужны yes/no, boolean или числовой результат. Если dry run выявил ошибку авторизации, сломанный tool, пустые ответы или неверно настроенный scorer, полный прогон запускать нельзя. Поэтому скилл полезен как проверяемый процесс регрессионной оценки, но не заменяет сам MLflow, tracing-инструментирование, production-наблюдаемость или ручную интерпретацию спорных результатов.