Stop running fresh model benchmarks and start watching your agent try to cancel a subscription. The gap between those two activities is where production systems die. A single-turn test can tell you if a response sounds pleasant. It cannot tell you whether the agent just refunded the wrong customer, looped fourteen times against a calendar API, or decided to skip the fraud check entirely. Text is the least dangerous thing an agent produces. The real risks hide in the tools it touches, the data it mutates, and the moments when it should have asked for help but kept going.
Why Text Benchmarks Fail in Production
High scores on standard benchmarks have become a misleading form of comfort. An agent that writes elegant prose might still be an operational hazard. When your system books appointments, edits database records, or files support tickets, the generated text is only the visible surface of the workflow. Underneath, the agent is making concrete decisions about which endpoint to hit, what payload to send, and when to stop. It can top a reading-comprehension leaderboard while costing you money by double-booking resources, mutating the wrong row, or leaking sensitive state into a log file. You need to verify the mechanics of the work, not just the polish of the output. If an agent can score well on an offline QA test and still fail your workflow by looping or misusing a tool, your evaluation is looking at the wrong signals.
Mapping the Five Dependencies
The team at Van Data Team starts every evaluation by mapping five specific control points. This changes the question entirely. You stop asking if one model is smarter than another. You start asking if the agent can actually finish a production task under your real constraints.
Business outcomes. Define what "done" means in dollars and customer impact. A task is not complete because the agent emitted a summary. It is complete when the inventory record is accurate, the appointment is confirmed, and the customer received a valid tracking number.
Mutable state. Know exactly what the agent is allowed to change. Which tables, which statuses, which account flags? If the agent can issue refunds, reschedule jobs, or update billing addresses, you need to inventory every field it touches.
Tool permissions. Be explicit about which API endpoints and functions are in scope. An agent with access to a search tool, a write tool, and a notification tool will mix them up if the boundaries are fuzzy. Map each permission to a specific operational need.
Failure recovery. Decide what happens when the calendar API times out, returns a 500, or hands back malformed JSON. The agent should not panic, hallucinate a success message, or retry forever. It needs a clear fallback path.
Human review gates. Identify the moments where a person must sign off before the agent proceeds. This is not a sign of weakness in the automation. It is a safety valve for high-impact changes and a source of ground-truth labels for your rubrics.
What a Real Evaluation Plan Looks Like
Once the dependencies are mapped, you need an evaluation plan that matches the messiness of production. Slide-deck metrics will not help you here.
Build test sets from real production failures, not from synthetic question banks. If your agent failed last Tuesday by confusing two similar SKUs, that exact confusion should be a permanent test case. Your evaluation suite should grow every time an incident teaches you something new.
Write rubrics that define successful completion in operational terms. Vague criteria like "helpful" or "accurate" are useless. A useful rubric states that a refund task is only successful if the original payment ID was referenced, the amount matched the request, a confirmation email was queued, and the transaction ID was logged.
Define trace specs for tool calls and retries. You need observability into what the agent planned, what it actually called, how many times it retried, and whether the retry strategy was appropriate. A trace without tool-level granularity is just a pretty story.
Set policies for when to alert a human. The agent should know its own boundaries. If a request exceeds a dollar threshold, references a VIP account, or encounters a state it has never seen before, it should escalate rather than guess.
Установите release gates, чтобы блокировать неудачные обновления моделей. Новая модель является обновлением только в том случае, если она улучшает ваши конкретные показатели. Если она чаще галлюцинирует аргументами инструментов, увеличивает задержку (latency) или создает новые риски безопасности, она не должна выпускаться. Такой барьер обеспечивает стабильность продакшена, даже когда поставщик базовой модели выпускает новую версию.
Runtime Grading: наблюдение за работой агента в реальном времени
Anthropic подталкивает индустрию к переходу от офлайн-тестов к runtime grading (оценке в реальном времени). Вместо того чтобы оценивать транскрипт постфактум, runtime grading позволяет системе оценивать работу агента прямо в процессе выполнения задачи. Это дает возможность отловить ошибки до того, как они перерастут в реальные проблемы.
Добавление оценщика (grader) стоит токенов и увеличивает задержку. Вы не можете позволить себе оценивать каждый мелкий шаг. Размещение каждого оценщика — это проектное решение. Ставьте их там, где ошибки обходятся дорого. Самые ценные контрольные точки находятся непосредственно перед фиксацией изменения состояния в базе данных, перед проведением платежа и перед отправкой сообщения клиенту. Это те моменты, когда неверное решение превращается в необратимое действие.
Остерегайтесь одной специфической «слепой зоны». Если одна и та же модель выполняет работу и одновременно оценивает её, она может не заметить те же самые ошибки. Логика, породившая ошибку, может легко оправдать её в процессе проверки. Для критически важных задач сохраняйте участие человека (human-in-the-loop). Позвольте людям проверять суждения самого оценщика, особенно когда на кону стоят деньги или доверие клиентов.
Цель здесь — операционный контроль. Объедините данные об инцидентах, критерии оценки задач (rubrics) и трассировку выполнения (runtime traces) в единый цикл обратной связи. Оценивайте весь путь: план, использование инструментов, поведение при восстановлении и конечный результат. Используйте офлайн-тесты, чтобы отловить известные, воспроизводимые ошибки перед релизом. Используйте runtime traces, чтобы находить новые сбои, которые вы не предусмотрели. Используйте проверку человеком, чтобы понять, где ваши критерии слишком упрощены и требуют ужесточения.
Так спросите себя: где бы вы разместили runtime grader в своем рабочем процессе? Перед вызовом инструмента, после вызова или только перед рискованным изменением? Большинство команд начинают слишком масштабно, оценивая всё подряд, а затем замирают из-за высокой стоимости. Начните с узкого сегмента. Выберите одно действие, ошибка в котором нанесет самый большой ущерб. Поставьте оценщика именно туда.
Начните с одной дорогостоящей ошибки
Операционная оценка — это не исследовательское упражнение. Это способ спать спокойнее, когда агент запущен в работу. Вам не нужна идеальная структура с первого дня. Вам нужен один четко определенный рабочий процесс, критерии оценки, сформулированные простым деловым языком, и оценщик, размещенный именно в тот момент, когда ошибка становится дорогостоящей. Сделайте это правильно, и у вас появится фундамент, которому действительно можно доверять.
Если вы хотите глубже изучить оценку агентов и runtime grading вместе с сообществом практиков, вы можете найти обучающее сообщество GyaanSetu по ссылке https://t.me/GyaanSetuAi.