Запуск агента — это только первый шаг.Автор статьи: elune
Статья скомпилирована, источник: ME News
Запуск агента — это только первый шаг.
Самое сложное — определить: стабильна ли она, корректна ли она и не произошло ли незаметного ухудшения из-за одного промпта или обновления модели.
Следующие 10 методов оценки стоит знать каждому инженеру по ИИ.
1. Золотой набор тестов | Golden Set
Подготовьте набор фиксированных и замороженных тестовых случаев.
После каждого изменения подсказки, модели, инструмента или рабочего процесса повторно запускайте этот набор примеров, чтобы определить, улучшилась ли система или она тайно перестала работать в некоторых сценариях.
Это базовая линия в системе оценки агентов.
Рекомендуемый инструмент: OpenAI Evals
Может использоваться для создания набора повторяемых тестов и сравнения производительности различных моделей или версий систем.
2. Судья на основе ИИ | ИИ как судья
Используйте другую большую языковую модель для оценки открытых ответов на основе заранее заданных критериев.
Этот метод особенно эффективен, когда задача не имеет единственного правильного ответа и не может быть оценена по совпадению строк или фиксированному выводу.
Например, модель-судья может оценить, насколько ответ точен, полон, релевантен и соответствует требованиям пользователя.
Рекомендуемый инструмент: OpenEvals
Предоставляем готовые оценщики для приложений на основе LLM, позволяющие быстро настроить автоматизированные процессы рецензирования.
3. Многомерная оценка | Rubric Scoring
Не давайте агенту только обобщённую «оценку качества».
Следует оценивать отдельно:
- Correctness
- Integrity
- Стиль выражения
- Безопасность
- Время отклика
- Стоимость вызова
Комплексная оценка может скрывать настоящие проблемы.
Например, снижение общего балла может быть вызвано не ошибкой в ответе, а внезапным ростом стоимости вызова инструментов; повышение общего балла также может быть достигнуто за счет снижения безопасности.
Рекомендуемый инструмент: DeepEval
Поддержка создания пользовательских индикаторов и независимой оценки по различным измерениям качества.
4. Оценка траектории｜Trajectory Eval
Оценивайте не только окончательный ответ, предоставленный агентом, но и весь процесс выполнения задачи.
Включая:
- Выбран ли правильный инструмент?
- Вызываются ли инструменты в правильном порядке?
- Повторное выполнение неэффективных действий
- Пропущены ли необходимые шаги?
- Правильно ли вы скорректировали решение на основе результатов инструмента?
Агент может в конечном итоге получить правильный ответ, но промежуточные этапы будут неэффективными, хрупкими и даже рискованными.
Рекомендуемый инструмент: AgentEvals
Можно проверить действия, решения и вызовы инструментов агента в полной траектории выполнения.
5. Юнит-тесты инструментов | Tool Unit Tests
Напишите отдельные тесты для каждого инструмента, используемого агентом.
Use fixed input to verify fixed output, without involving the model.
Так можно разделить проблему:
Проблема в выводе агента или в базовых инструментах, интерфейсах или сервере MCP?
Только убедившись в надежности самого инструмента, имеет смысл оценивать, правильно ли Agent вызвал инструмент.
Рекомендуемый инструмент: MCP Inspector
Может использоваться для проверки и тестирования MCP Server, параметров инструментов и результатов возврата.
6. Набор регрессионных тестов｜Regression Suite
Save past real execution cases and re-run after each update to prompts, models, or toolsets.
Затем сравните результаты новой и старой версий, проверьте:
- Была ли изначально правильная задача провалена?
- Изменился ли формат вывода?
- Does the tool call increase?
- Повысились ли задержки и стоимость?
- Деградируют ли некоторые крайние случаи?
Более высокая средняя производительность новой версии не означает, что она не нарушила старые функции.
Рекомендуемый инструмент: Promptfoo
Поддержка запуска повторяемых наборов оценок, выявление регрессионных проблем и интеграция процессов проверки в CI.
7. A/B-тестирование в продакшене｜A/B Testing in Production
Случайным образом распределите реальный пользовательский трафик между двумя различными версиями и сравните их производительность в реальных условиях.
Можно протестировать:
- Два набора подсказок
- Две модели
- Два рабочих процесса агентов
- Различные комбинации инструментов
- Различные стратегии ответов
Более высокая оффлайн-оценка не обязательно приводит к более высокому успеху пользователей.
На самом деле важны реальные результаты, такие как процент выполнения задач, уровень принятия пользователями, коэффициент конверсии, процент передачи на оператора и процент решения проблем.
Рекомендуемый инструмент: GrowthBook
Предоставляет функции включения/выключения, контролируемые эксперименты и анализ продуктов.
8. Ручная проверка｜Human Review
Периодическая выборка реальных записей выполнения с оценкой человеческими рецензентами.
Ручная проверка позволяет выявить проблемы, упущенные автоматизированной оценкой, а также использовать их для калибровки судей на основе LLM.
Требуется особое внимание:
- Соответствуют ли оценки модели суждениям людей
- Are the rating criteria clear enough?
- Справедлива ли модель-судья в отношении длинных ответов?
- Автоматическая оценка на наличие пропущенных серьезных ошибок
Automated evaluation cannot fully replace human judgment.
Рекомендуемый инструмент: Argilla
Помогите команде собирать ручные отзывы, проверять выводы модели и преобразовывать результаты в высококачественные наборы данных.
9. Теневой запуск｜Shadow Run
Запустите кандидатскую версию в реальном трафике, но не отображайте её вывод пользователям.
В производственной среде по-прежнему используется старая версия, а новая версия выполняется только на фоне для сравнения их производительности.
Этот метод подходит для высокорискованных обновлений, например:
- Заменить основную модель
- Перепишите системный промт
- Подключение новых внешних инструментов
- Изменить логику принятия решений агентом
- Расширить права инструментов
Shadow running helps the team identify issues in real traffic before the official release, while avoiding direct impact on users.
Рекомендуемый инструмент: Langfuse
Отслеживайте производственные запуски, сравнивайте кандидатские версии и мониторьте результаты оценки.
10. Тестирование красной команды | Red Teaming
Атакуйте свою собственную систему до того, как это сделают злоумышленники.
Область тестирования включает:
- Jailbreak attack
- Prompt injection
- Утечка конфиденциальных данных
- Обход прав доступа
- Злоупотребление инструментами
- Вредоносные файлы или содержимое веб-страниц
- Неожиданное внешнее действие
Красные команды особенно важны для агентов, которые могут вызывать базы данных, отправлять электронные письма, изменять файлы, выполнять код или получать доступ к внутренним системам.
Рекомендуемый инструмент: Garak
Обнаруживает уязвимости безопасности и небезопасные действия в системе LLM.
Offline evaluation tells you: the system works properly in the testing environment.
Онлайн-оценка показывает: система продолжает работать нормально после запуска.
Вам сейчас, возможно, не нужно сразу настраивать все 10 механизмов оценки.
Более практичный подход:
Вернитесь к последнему сбою агента и приоритизируйте развертывание двух методов оценки, которые могли бы выявить проблему заранее.
Часто достаточно сначала создать золотой набор тестов, а затем дополнить его регрессионными тестами или ручной проверкой, чтобы избежать большого количества элементарных инцидентов.
Стоит сохранить.