Проектирование плана управления оценкой для производственных ИИ-агентов

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

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

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

Плоскость управления оценкой

Оценка не должна быть этапом постобработки, при котором оцениваются готовые ответы. В производственной среде она является частью плоскости управления, отвечающей за автономную эксплуатацию. Каждое решение, связанное с планированием, каждый вызов инструмента, каждое изменение состояния, каждая проверка политики и любой внешний эффект должны генерировать технические сигналы, которые можно проверять до, во время и после выполнения операций. Цель заключается не в оценке выводов модели, а в непрерывной проверке того, что процесс выполнения соблюдает детерминистические свойства системы.

Дизайн строго разделяет плоскость выполнения и плоскость управления. Модель языка, независимо от её размера, отвечает за планирование и принятие решений. Окружающая платформа отвечает за выполнение, состояние, обеспечение соблюдения правил, возможности наблюдения, оценку и управление процессом выпуска. У каждого слоя есть чётко определённый контракт, что позволяет изолировать сбои, воспроизводить их и анализировать по отдельности, не рассматривая модель как источник истины.

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

Временная среда агента отвечает за выполнение

Среда выполнения создаёт и запускает граф рассуждений для отдельного запроса. Она включает планирование, сбор контекста, организацию получения данных, выбор инструментов, промежуточные рассуждения и состояние выполнения. Её следует рассматривать как временные вычисления, выполняющие рабочие процессы, но не хранящие постоянного бизнес-состояния. Каждое решение, влияющее на последующее поведение, должно быть выведено в виде структурированного события выполнения до того, как управление перейдёт дальше. Поэтому среда выполнения остаётся горизонтально масштабируемой, безсостоянийной и временной, причём её выполнение можно повторить независимо от машины, на которой оно было впервые выполнено.

Слой инструментов отвечает за детерминированные побочные эффекты

Время выполнения никогда не взаимодействует напрямую с производственной инфраструктурой. Каждая внешняя функциональность предоставляется через слой детерминированной обработки с строго типизированными контрактами; MCP является одним из примеров. Этот слой проверяет схемы, аутентифицирует вызывающие стороны, авторизует действия, обеспечивает соблюдение политики выполнения, применяет лимиты на попытки повтора, гарантирует идемпотентность там, где это необходимо, и отделяет сбои инфраструктуры от сбоев в логике обработки. Он также определяет границы доверия системы: модель предлагает намерение, а слой обработки решает, может ли это намерение безопасно привести к побочному эффекту.

Слой телеметрии хранит каноническую запись

Каждое изменение состояния, способствующее автономному поведению, фиксируется в виде неизменяемых данных телеметрии, к которым можно только добавлять новую информацию. Решения по планированию, запросы к данным, вызовы моделей, вызовы инструментов, попытки повтора, задержки, использование токенов, решения политик и внешние ответы — всё это хранится в виде структурированных записей с постоянными идентификаторами. Эта запись представляет собой канонический отчет о действиях системы. Она обеспечивает возможность детерминистического воспроизведения событий, судебной отладки, анализа причинно-следственных связей и оценки долгосрочной надежности, причем при этом не требуется использование генерируемого текста.

Слой оценки отвечает за проверку поведения

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

Хранилище оценок хранит институциональную память

Результаты оценки сохраняются дольше, чем отдельные запуски. Хранилище постоянно пополняется за счёт типичных нагрузок, сбоев, возникающих в производстве, исправлений, внесённых людьми, агрессивных запросов, сохранённых траекторий, а также базовых значений для оценки регрессии в более ранних версиях. Оно становится основой для сравнения новых версий, воспроизведения старых сбоев, выявления отклонений и предотвращения возвращения уже устранённых дефектов. Надёжность повышается благодаря тому, что операционный опыт постепенно преобразуется в готовые к использованию ресурсы для оценки.

Плоскость управления развертыванием отвечает за регулирование выпусков

Решение о выпуске принимается на основе оценки, а не только с учетом изменений в коде. Любые изменения в запросах, логике оркестрации, стратегии поиска, версии модели или политике выполнения автоматически вновь применяют типовые наборы для оценки перед ее публикацией. Кандидатка проходит дальше только в том случае, если качество поведения, ограничения безопасности, лимиты задержек и пороги регрессии остаются в установленных пределах. Развертывание становится решением, основанным на политике и подкрепленным непрерывной проверкой поведения, а не ручным анализом результатов.

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

Создание конвейера

Оценка агента — это не один единственный тест. Это непрерывная система обратной связи, действующая на протяжении всего цикла: от разработки до выпуска и ввода в эксплуатацию. Опытные команды рассматривают её как часть процесса доставки продукта, а не как отдельное задание по сравнению показателей. Цель заключается в постоянной проверке того, что автономное поведение остаётся надёжным, эффективным, безопасным и воспроизводимым по мере изменений системы, причём получение одного правильного результата — это лишь часть этого процесса.

Каждый запрос проходит определённый жизненный цикл. Через агента проходит типичная нагрузка, реальная или имитированная. Полная траектория выполнения фиксируется, а затем оценивается с помощью детерминистичных утверждений и семантических инструментов. На основе результатов выполнения вычисляются технические показатели, а новообнаруженные моди работы, приводящие к сбоям, добавляются в репозиторий оценок, чтобы они вошли в будущие наборы тестов на регрессию. Трафик в производственной среде способствует улучшению последующих версий.

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

dataset:
  id: refund-policy-v2

input:
  query: "Refund my cancelled subscription."

expected_tools:
  - customer.lookup
   - refund.policy

forbidden_tools:
  - payment.capture

constraints:
  max_latency_ms: 3000
  max_tool_calls: 3

success:
  task_completed: true

В отличие от традиционного теста единицы, сценарий определяет ожидаемое поведение, а не ожидаемую формулировку.

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

{ "trace_id": "9ab3...",
"span": "tool.crm.lookup",
"latency_ms": 214,
"tokens_input": 684,
"retry_count": 0,
"status": "success"
}

Любую операцию следует возможность воспроизвести исключительно на основе данных телеметрии.

Затем система анализа преобразует эти данные в технические сигналы. Детерминистические проверки оценивают объективные инварианты: корректность схем, соблюдение лимитов авторизации, нахождение задержек в установленных пределах, ограничение количества попыток повтора и соблюдение требований к инфраструктуре. Семантические оценщики определяют качество логики, соответствие фактам, соблюдение инструкций и завершение задачи. Человеческие эксперты сосредотачиваются на неоднозначных или критически важных для бизнеса случаях, когда уровень уверенности автоматизированных систем недостаточен.

Рассмотрим два варианта обработки запроса на возврат средств. В первом варианте планировщик вызывает модуль получения данных, затем API для возврата средств, и процесс завершается: это правильно и эффективно. Во втором варианте планировщик вызывает модуль получения данных, дважды пытается выполнить операцию заново, после чего обращается к API для возврата средств и завершает процесс: результат остается правильным, но из-за чрезмерного количества попыток возникает более высокая задержка и увеличиваются затраты. Два разных подхода могут привести у клиента к одинаковому видимому результату, но существенно отличаться по качеству реализации. Надежные системы оценивают весь путь выполнения операции, а не только конечный результат.

Наконец цикл завершается. Каждый инцидент в производстве, неудачная оценка, обращение клиента или новообнаруженный крайний случай попадает в репозиторий оценок и включается в будущие наборы тестов на регрессию. Со временем опыт превращается в практические инженерные знания, поэтому устраненные ошибки не могут снова возникнуть после оперативных правок, изменений в оркестрации или обновлений моделей. Зрелая платформа превращает треки в измеримые сигналы, сигналы — в инженерные решения, а решения — в постоянные тесты на регрессию.

Тестирование на протяжении всего жизненного цикла разработки

Создание платформы — это лишь первый шаг. Более важная задача — интегрировать процессы оценки в жизненный цикл разработки, чтобы автономное поведение системы проверялось по мере её развития. Каждый этап направлен на устранение определенного класса рисков и постепенно повышает уверенность в стабильности перед тем, как изменения попадут в производство.

Локальная разработка основана на детерминистической корректности. Обычные тесты на единицы и интеграцию покрывают код оркестрации, пайплайны получения данных, интерфейсы памяти, контракты инструментов, проверки политик и ограничения авторизации — всё это до того, как в игру вступает модель. Раннее выявление детерминистических сбоев упрощает отладку, а поведение модели оценивается только после того, как становится ясно, что сопутствующая инфраструктура работает корректно.

Запросы на слияние запускают набор тестов для оценки в рамках непрерывной интеграции. Этот набор воспроизводит эталонные наборы данных, выполняет детерминистические проверки контрактов инфраструктуры и применяет инструменты оценки поведения, которые выявляют любые проблемы с качеством логики, выбором инструментов, задержками или уровнем безопасности ещё до слияния кода:

name: Agent Evaluation
on:
  pull_request:
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Replay Evaluation Suite
        run: deepeval test run evaluation/
      - name: Fail on Regression
        run: promptfoo eval --config promptfooconfig.yaml

Запросы на интеграцию следует оценивать по их поведению, а не только по исходному коду.

Этап тестирования проверяет изменения в реалистичных условиях. Исторические данные анализируются с учётом обновлённых инструкций, механизмов оркестрации, стратегий получения данных и версий моделей, чтобы убедиться, что ранее работавшие решения продолжают функционировать. Кандидат на внедрение переходит на следующий этап только в том случае, если качество его поведения остаётся в пределах установленных порогов.

Продакшн перестаёт быть полигоном для тестирования и превращается в среду непрерывной верификации. Автономная работа отслеживается с помощью реального времени данных, распределённых трейсов, обратной связи от пользователей, сигналов безопасности и детекторов отклонений. Каждый инцидент становится кандидатом на тест на регрессию. Продакшн никогда не должен быть местом первоначального обнаружения сбоев, но всегда должен служить источником будущих тестов на регрессию.

Важные показатели

Ни один показатель не может полностью отразить надежность автономной системы. Оценка производительности учитывает противоречивые цели. Улучшение алгоритмов принятия решений может увеличить задержки и затраты, а агрессивная настройка пропускной способности может снизить уровень безопасности или эффективность выполнения задач. Поэтому корректность является лишь одним из аспектов наряду с надежностью, задержками, затратами, качеством и безопасностью. Команды устанавливают бюджеты для каждого из этих аспектов и рассматривают ухудшение показателей в любом из них как препятствие для выпуска продукта. Надежные агенты — это те, которые соблюдают допустимые бюджеты по всем критическим показателям, причем целью не является максимизация одного конкретного числа.

Ситуация с инструментами

Ни один отдельный продукт не обеспечивает оценку уровня производства. Команды создают такую систему из специализированных компонентов, охватывающих инструментирование, оценку поведения, возможности наблюдения за работой системы и непрерывное тестирование на регрессию. Экосистема быстро меняется, но схема остаётся прежней: инструментирование фиксирует процесс выполнения, оценка преобразует его в сигналы, возможности наблюдения позволяют отслеживать динамику поведения, а тестирование на регрессию предотвращает возвращение старых ошибок. Отдельные инструменты появляются и исчезают, но эти четыре компонента остаются необходимыми. Надёжность обеспечивается инженерными решениями, а не каким-либо конкретным инструментом.

Чек-лист перед запуском

Перед тем как автономный агент попадёт в производственную среду, команда должна иметь возможность дать утвердительный ответ на каждый из этих вопросов.

Структура

• Является ли сама модель безсостоянийной?
• Сохраняется ли операционное состояние вне неё?
• Являются ли графы выполнения ограниченными?
• Соблюдаются ли лимиты и сроки повторных попыток?
• Являются ли все интерфейсы инструментов детерминированными?

Видимость

• Можно ли перезапустить любую задачу?
• Выпускает ли каждый вызов инструмента структурированные телеметрические данные?
• Можно ли проследить траектории обработки с начала до конца?
• Передаются ли идентификаторы трейсов через все компоненты?

Оценка

• Отражают ли эталонные наборы данных реальные сценарии производства?
• Превращается ли каждая ошибка в производстве в тест на регрессию?
• Оцениваются ли изменения в промптах, моделях и механизмах оркестрации перед внедрением?
• Были ли судьи на основе больших языковых моделей откалиброваны по сравнению с человеческими рецензентами?

Безопасность

• Проводятся ли автоматически тесты на внедрение промптов?
• Проверяются ли политики авторизации независимым механизмом?
• Изолирована ли память между пользователями?
• Проводится ли непрерывный мониторинг утечек личных или конфиденциальных данных?

Устойчивость

• Проводятся ли эксперименты с хаосом в рамках каждой версии обновления?
• Восстанавливается ли работа агента при сбое инструмента?
• Осуществляется ли круглосуточный отслеживание отклонений?
• Могут ли автономные действия быть безопасно отменены?

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

Что это означает для команды

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

Платформа основана на нескольких повторяемых механизмах. Трейсы представляют собой стандартный формат записи данных. Репрезентативные нагрузки превращаются в наборы тестов на обнаружение ухудшений качества. Детерминистичные утверждения и семантические оценщики генерируют измеримые сигналы. Системы CI/CD используют эти сигналы для контроля выпусков, в то время как телеметрия из режима работы постоянно поставляет новую информацию общему репозиторию.

По мере того как агенты становятся всё более автономными, внимание смещается от совершенствования командных запросов к созданию более эффективных циклов обратной связи. Команда, способная постоянно наблюдать за автономным поведением, оценивать его, воспроизводить сценарии и улучшать его, может с уверенностью постоянно модифицировать свою систему, независимо от того, какая инструментальная платформа или базовая модель появится в будущем.