Оценка ИИ-агентов: детерминированные метрики + LLM-судья

Вы запускаете множество небольших ИИ-агентов. У вас есть агенты для backend, frontend, mobile и devops. У каждого агента одна задача.

Когда агентов становится много, возникает проблема. Вы не знаете, насколько они хороши. Вы не знаете, делает ли правка промпта их лучше или хуже. Фраза «выглядит нормально» не работает в масштабе.

Я создал фреймворк для решения этой задачи. Он использует числа для измерения производительности и автоматически улучшает промпты.

Стратегия

Сначала измеряйте то, что можно измерить математически. Используйте LLM-судью только тогда, когда это необходимо. Детерминированные метрики работают быстро и бесплатно. LLM-судья работает медленно и стоит денег.

Как работает система:

• Оболочка (harness) запускает каждого агента как отдельный процесс. • Она передает задачу агенту. • Она перехватывает вывод. • Она оценивает результат на основе ожидаемых данных.

Агенту нужно только читать из stdin и писать в stdout. Это может быть Python-скрипт или shell-скрипт. Оболочке (harness) всё равно.

Пять основных метрик для отслеживания:

  • Accuracy: Соответствует ли результат цели?
  • Fuzzy score: Насколько текст похож на целевой?
  • Timeout rate: Как часто агент не успевает завершить работу?
  • Safety violations: Соответствует ли вывод небезопасным паттернам?
  • Reproducibility variance: Выдает ли агент один и тот же ответ каждый раз?

Если агент дает правильный ответ, но делает это непоследовательно — это баг.

LLM-судья

Некоторые вещи трудно измерить математически. Вам нужно знать, придерживался ли агент своей роли или соблюдал ли он ограничения.

В таких случаях работу проверяет LLM-судья. Он получает критерии оценки (rubric) и вывод агента. Затем он возвращает структурированный вердикт. Я проверяю этот вердикт на соответствие JSON-схеме, чтобы он не нарушил структуру отчета.

Судья делает больше, чем просто ставит оценку. Он должен предлагать исправления. Критика вроде «это слабо» бесполезна. Критика вроде «добавьте блок JSON в промпт» — это конкретное действие.

Цикл улучшения

Ошибки записываются в файл. Этот файл служит входными данными для автоматизированного цикла. Система находит самое слабое место в промпте и пытается его исправить. Она поддерживает пул хороших вариантов и записывает лучшие версии обратно в код.

Одиночный показатель — это лишь моментальный снимок. Используйте историю для отслеживания трендов. Это покажет, становитесь ли вы лучше со временем.

Стройте свой фундамент на детерминированных метриках. Используйте судью как скальпель, а не как молот.

Оценка ИИ-агентов: детерминированные метрики против LLM-судьи

Оценка ИИ-агентов — задача не из легких. В отличие от традиционного программного обеспечения, где на вход подаются определенные данные и ожидается конкретный результат, ИИ-агенты работают в условиях неопределенности. Их ответы могут варьироваться, даже если входные данные остаются прежними.

Как же нам понять, насколько хорошо работает наш агент? Существует два основных подхода: использование детерминированных метрик и использование LLM в качестве судьи (LLM-as-a-Judge).

Детерминированные метрики

Детерминированные метрики — это правила, основанные на жестких условиях. Они проверяют, соответствует ли результат определенному формату или значению.

Примеры детерминированных метрик:

  • Точное совпадение (Exact Match): Проверка того, совпадает ли ответ агента с эталонным ответом символ в символ.
  • Регулярные выражения (Regex): Проверка того, соответствует ли ответ определенному шаблону (например, формат даты, email или JSON).
  • Выполнение кода (Code Execution): Если агент должен написать код, мы можем запустить его и проверить, выдает ли он правильный результат.
  • Математическая проверка: Если агент решает математические задачи, мы можем проверить правильность вычислений.

Плюсы:

  • Скорость: Работают мгновенно.
  • Стоимость: Практически бесплатны.
  • Надежность: Результат всегда воспроизводим и не зависит от «настроения» модели.

Минусы:

  • Отсутствие гибкости: Не могут оценить нюансы, тон или стиль ответа.
  • Хрупкость: Малейшее изменение в форматировании (например, лишний пробел) может привести к провалу теста, даже если ответ по сути верен.

LLM-судья (LLM-as-a-Judge)

Подход «LLM-судья» предполагает использование более мощной и продвинутой языковой модели (например, GPT-4o или Claude 3.5 Sonnet) для оценки ответов вашего агента. Вы предоставляете судье критерии (рубрики), по которым он должен выставить оценку.

Как это работает:

Вы подаете судье:

  1. Входной запрос (Prompt).
  2. Ответ агента.
  3. Эталонный ответ (опционально).
  4. Инструкции по оценке (например: «Оцени полезность, точность и тон ответа по шкале от 1 до 5»).

Плюсы:

  • Понимание контекста: Способность оценивать нюансы, логику и естественность языка.
  • Гибкость: Можно оценивать практически любые аспекты: от вежливости до глубины анализа.

Минусы:

  • Стоимость: Использование мощных моделей для оценки каждого ответа может быть дорогим.
  • Скорость: Оценка занимает значительно больше времени, чем проверка регулярным выражением.
  • Предвзятость (Bias): LLM-судьи могут быть предвзяты (например, отдавать предпочтение более длинным ответам или ответам, похожим на их собственные).

Сравнение: Детерминированные метрики vs LLM-судья

Характеристика Детерминированные метрики LLM-судья
Скорость Очень высокая Низкая
Стоимость Очень низкая Высокая
Гибкость Низкая Высокая
Оценка нюансов Невозможна Отличная
Воспроизводимость 100% Вероятностная

Гибридный подход: Лучшее из двух миров

Для создания надежной системы оценки ИИ-агентов лучше всего использовать гибридный подход.

  1. Используйте детерминированные метрики для проверки структуры, формата и фактической точности (например, проверка, что агент вернул валидный JSON или правильное число).
  2. Используйте LLM-судью для оценки качества контента, логики рассуждений и соответствия тональности бренда.

Комбинируя эти методы, вы получаете систему, которая одновременно быстрая, экономичная и способная понимать сложные аспекты человеческого языка.