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.
Встановіть gate-контролі релізів, щоб блокувати невдалі оновлення моделей. Нова модель є оновленням лише тоді, коли вона покращує ваші конкретні результати. Якщо вона частіше галюцинує аргументами інструментів, збільшує затримку (latency) або створює нові ризики безпеки, вона не випускається. Такий контроль забезпечує стабільність продакшену, навіть коли постачальник базової моделі випускає нову версію.
Runtime Grading: спостереження за роботою агента
Anthropic спонукає індустрію виходити за межі офлайн-тестів у бік runtime grading (оцінювання під час виконання). Замість того, щоб оцінювати транскрипт постфактум, runtime grading дозволяє системі оцінювати роботу агента безпосередньо під час виконання завдання. Це дає можливість виявити помилки до того, як вони переростуть у реальні проблеми.
Додавання оцінювача (grader) коштує токенів і збільшує затримку. Ви не можете дозволити собі оцінювати кожен дрібний крок. Розміщення кожного оцінювача — це архітектурне рішення. Розміщуйте їх там, де помилки є найдорожчими. Найцінніші контрольні точки знаходяться безпосередньо перед фіксацією зміни стану в базі даних, перед здійсненням платежу та перед надсиланням повідомлення клієнту. Це ті моменти, коли невдале рішення стає незворотною дією.
Зверніть увагу на певне «сліпе місце». Якщо одна й та сама модель виконує роботу і водночас оцінює її, вона може пропустити ті самі помилки. Логіка, яка призвела до помилки, може легко виправдати цю помилку під час перевірки. Для завдань з високим рівнем впливу залучайте людину до процесу перевірки (human-in-the-loop). Дозвольте людям перевіряти рішення самого оцінювача, особливо коли на кону стоять гроші або довіра клієнтів.
Мета тут — операційний контроль. Поєднайте ваші дані про інциденти, рубрики завдань і runtime traces (трасування під час виконання) в один цикл зворотного зв'язку. Оцінюйте весь шлях: план, використання інструментів, поведінку під час відновлення та кінцевий результат. Використовуйте офлайн-тести, щоб виявити відомі, відтворювані помилки перед релізом. Використовуйте runtime traces, щоб знайти нові збої, які ви не передбачили. Використовуйте перевірку людьми, щоб зрозуміти, де ваші рубрики занадто спрощені та потребують уточнення.
Тож запитайте себе: де б ви розмістили runtime grader у своєму робочому процесі? Перед викликом інструменту, після нього чи лише перед ризикованою зміною? Більшість команд починають занадто масштабно, оцінюючи все підряд, а потім зупиняються через високу вартість. Починайте з вузького сегмента. Оберіть одну дію, помилка в якій завдасть найбільшої шкоди. Поставте оцінювача саме туди насамперед.
Почніть з однієї дорогої помилки
Операційна оцінка — це не наукове дослідження. Це спосіб спати спокійніше, коли агент уже працює в реальному середовищі. Вам не потрібна ідеальна структура з першого дня. Вам потрібен один чітко визначений робочий процес, рубрика, написана зрозумілою бізнес-термінологією, і оцінювач, розміщений саме в той момент, коли помилка стає дорогою. Зробіть це правильно, і ви отримаєте фундамент, якому справді зможете довіряти.
Якщо ви хочете глибше зануритися в оцінювання агентів та runtime grading разом із спільнотою практиків, ви можете знайти навчальну спільноту GyaanSetu за посиланням https://t.me/GyaanSetuAi.