Командам, разрабатывающим ИИ-агентов, недостаточно проверять только итоговый ответ, чтобы понять, работает ли система должным образом. В приложениях, объединяющих поиск, генерацию и вызов инструментов, неправильный результат может быть вызван выбором неверной базы данных или извлечением нерелевантных документов, даже если внешне проблема проявляется лишь в финальном тексте. Во время презентации, проведённой через InfoQ, Susan Chang, ведущий специалист по данным в Elastic, объяснила, как компания разработала общий фреймворк для оценки своих агентов, используемых в сфере кибербезопасности и корпоративных чат-ботах.
От изолированных оценок к общим инструментам
Команды Elastic начали с создания отдельных наборов данных, оценщиков и процессов трассировки для каждого агента. В случае агента обнаружения атак тесты включали сценарии атак и нормального поведения, подготовленные аналитиками и исследователями в области безопасности, а также такие метрики, как точность, полнота, фактологическая корректность, сходство и классификация тактик MITRE. Корпоративные чат-боты, работающие с данными организации, проверяли вопросы и поиск по документам, уделяя внимание релевантности и полноте ответа, корректности идентификаторов продуктов и формированию запросов ES|QL.
Различия между этими сценариями привели к значительному дублированию работы. Поэтому Elastic создала общий фреймворк, способный импортировать разные типы наборов данных по единой схеме, запускать оценки на основе трасс выполнения и использовать общие оценщики для приложений RAG наряду с компонентами, специфичными для каждого продукта. Процесс можно запустить локально, загрузить данные, запустить агента, собрать результаты, а затем показать разработчикам полученные баллы.
Трассировка необходима для понимания причины сбоя
Опыт показывает, что трассировка агента не должна ограничиваться его итоговым выводом. Необходимо регистрировать вызванные инструменты, векторный и полнотекстовый поиск, извлечённые данные, расход токенов, время отклика и последовательность решений. Такой уровень детализации позволяет оценить вызов конкретного инструмента или обнаружить, что агент использовал неверный источник, ещё до того, как проблема проявится в финальном ответе.
Неудачные случаи, о которых сообщают пользователи, например негативные оценки, также можно превращать в новые примеры для тестового набора. Благодаря этому производственная обратная связь становится частью регрессионных тестов в последующих версиях, а не остаётся отдельными ручными заметками, не связанными с циклом разработки.
Почему LLM-as-a-judge недостаточно?
Elastic использовала языковые модели для оценки результатов других моделей в открытых или неоднозначных задачах, таких как стиль, согласованность и соответствие ответа контексту. Такой подход позволяет масштабировать оценку, когда трудно написать точное правило для проверки длинного текста. Однако он может выдавать разные результаты от одного запуска к другому и не всегда обнаруживает конкретные ошибки, например отсутствующий идентификатор продукта или недействительный запрос.
Поэтому Elastic объединила LLM-as-a-judge с детерминированными оценками на основе правил и программного кода. Такие оценки проверяют структуру JSON или YAML, корректность синтаксиса, наличие необходимых сущностей, возможность выполнения кода или запроса, а также такие метрики, как точность, полнота и фактологическая корректность. Это сочетание снижает стоимость и ускоряет оценку в случаях, когда существует однозначный ответ, оставляя семантическое суждение для задач, которые трудно свести к правилам.
Что нельзя обобщить?
Elastic не считала создание специализированных тестовых данных процессом, который можно полностью автоматизировать. В сфере кибербезопасности команде нужны аналитики и исследователи, определяющие, что является реальной атакой и какое поведение допустимо для конечного пользователя. Кроме того, определение регрессии различается у разных агентов: после определённого обновления агент безопасности может чаще объявлять об атаках даже при вводе корректных данных.
Калибровка оценщиков по-прежнему остаётся ответственностью каждой команды. Если языковой оценщик выставляет разные баллы одному и тому же случаю или не согласуется с целевой оценкой человека, общий фреймворк будет выдавать вводящие в заблуждение числа независимо от качества программной архитектуры. Chang также указала на риск смещения оценщика, когда для генерации и оценки используются представители одного семейства моделей: в таком случае он может завышать эффективность этих моделей.
Что практически меняется для команд?
Опыт Elastic рекомендует начинать с небольшого набора тестовых примеров — от 20 до 50 случаев — вместо ожидания идеального набора. На ранних этапах разрозненная работа может быть приемлемой для ускорения обучения, особенно когда сценарии использования и метрики ещё находятся на стадии выявления. Однако по мере выхода нескольких агентов в продакшен базовые трассировка и оценка становятся необходимыми для ответа на вопросы об эффективности и диагностики проблем пользователей.
Elastic также перенесла некоторые инструменты оценки с Python на TypeScript, чтобы соответствовать написанному на TypeScript производственному коду и использовать Playwright, а также специальный внутренний инструмент под названием Scout. Этот шаг не означает, что необходимо переносить все оценки, связанные с анализом данных; он отражает конкретную потребность сократить разрыв между тем, что тестирует команда, и тем, что фактически выполняет система. Практический вывод заключается в том, что общий фреймворк может унифицировать схему, запуск, общие метрики, но не способен заменить экспертные знания в предметной области или суждение о том, что считать успехом и неудачей.