Наблюдаемость и оценка агентов
Финальный ответ не показывает, почему агент оказался успешным или сломался. Для разбора нужен trace всей траектории: вход, решения, tool calls, результаты, изменения состояния и завершение.
Trace и spans
Один trace соответствует run или пользовательской задаче. Внутри него spans отражают отдельные операции:
- вызов модели с точным идентификатором и настройками;
- выбор и вызов инструмента;
- получение и обработку результата;
- retrieval и выбранные фрагменты;
- handoff или запуск worker;
- ожидание подтверждения;
- проверку и финальное состояние.
Используй устойчивые run_id, trace_id, tool_call_id и версию workflow, чтобы связывать события после retries и перезапусков.
Что записывать
- цель, критерии готовности и ограничения;
- версии модели, инструкций, tools и workflow;
- аргументы и результат вызова с длительностью;
- изменение state и внешние side effects;
- источники, ошибки, retries и подтверждения;
- токены, стоимость и общую задержку;
- итоговый статус и причину остановки.
Логи не должны бесконтрольно сохранять секреты и персональные данные. Применяй redaction, разграничение доступа и срок хранения.
Два уровня оценки
Outcome
Достигнута ли реальная цель: файл изменён правильно, заявка создана один раз, ответ подтверждён источниками, пользователь получил нужный результат.
Trajectory
Насколько разумно агент пришёл к результату: выбрал ли подходящий инструмент, не выполнил ли лишние действия, соблюдал ли права, корректно ли обработал ошибку и вовремя ли остановился.
Хорошая траектория не компенсирует неправильный outcome, а случайно успешный итог не доказывает надёжность процесса.
Набор evals
Включай:
- обычные задачи;
- пограничные и неоднозначные входы;
- недоступный инструмент и таймаут;
- частично выполненное внешнее действие;
- отклонённое подтверждение;
- prompt injection в документе или tool output;
- пустой и противоречивый контекст;
- превышение бюджета и корректную отмену.
Метрики
- task success rate;
- точность выбора инструмента и аргументов;
- число ненужных tool calls;
- частота небезопасных попыток и корректных блокировок;
- доля успешного возобновления;
- стоимость и latency по успешной задаче;
- качество источников и полнота подтверждений.
LLM-as-a-Judge подходит для части качественных критериев, но должен быть откалиброван на человеческих оценках и дополнен детерминированными проверками.
Рабочий цикл
- Собрать traces реальных успехов и сбоев.
- Превратить важные сбои в регрессионные кейсы.
- Изменить один компонент: prompt, tool schema, routing, модель или policy.
- Прогнать одинаковый набор и сравнить outcome, trajectory, стоимость и задержку.
- Выпустить изменение только без критических регрессий.
См. также: Observability and Tracing, Evals, LLM-as-a-Judge, Тестирование промптов, Жизненный цикл агентной задачи.