# Production Evals For Agentic AI Systems

Nishant Gupta · Meta · AI Engineer World's Fair 2026: Online Track

> Eval cho agent phải đo hành vi cả hệ thống: scenario offline, production telemetry, human review, drift, trace và metric reliability gắn với kết quả kinh doanh.

Topics: Evals, Agents, Distributed Systems

Canonical: https://homus.dev/talks/production-evals-for-agentic-ai-systems

## 1. Từ benchmark sang câu hỏi "hệ thống có hành xử đúng không"

Nishant Gupta là software engineering tech lead tại Meta, làm phần training infrastructure và inference infrastructure cho Meta Superintelligence Labs và tổ chức infrastructure của nhóm này. Chủ đề hôm nay của anh là production eval cho hệ thống agentic.

![Slide tiêu đề Production Evals for Agentic Systems, Nishant Gupta, Tech Lead @ Meta](https://homus.dev/photos/vljxQZfJ9wY-0000.jpg)

Slide mở đầu: "Production Evals for Agentic Systems", với dòng phụ "Measuring reliability beyond accuracy. Building evaluation systems for autonomous AI workflows", tức là đo reliability vượt ra ngoài accuracy và xây hệ thống evaluation cho các workflow AI tự hành. Góc dưới ghi Nishant Gupta, Tech Lead @ Meta.

Khi nghe chữ evaluation, phần lớn mọi người nghĩ ngay tới benchmark. Một model đạt 90% trên benchmark, bản mới đạt 92%, cả team ăn mừng. Nhưng hệ thống agentic đã thay đổi tận gốc ý nghĩa của evaluation. Ngày nay hệ thống không chỉ sinh ra câu trả lời. Chúng lập plan, gọi tool, truy xuất thông tin (retrieval), chạy workflow, và tương tác với chính hạ tầng production.

Vì thế câu hỏi không còn là "model có sinh ra câu trả lời đúng không?". Câu hỏi giờ là "hệ thống có hành xử đúng không?". Điều Nishant muốn bàn trong talk là evaluation đang tiến hoá từ việc benchmark model thành một phần của production infrastructure.

## 2. Benchmark tăng, production vẫn khó đoán

Đây là vấn đề mà gần như mọi tổ chức AI đang gặp: benchmark offline cứ tiếp tục tăng, vậy mà reliability trên production thường vẫn khó đoán. Tại sao? Vì benchmark đo capability của model, còn production đo hành vi của cả hệ thống.

Một benchmark không bắt được tool failure, API sập, context thay đổi, sự khác biệt giữa các user, hay những workflow chạy rất lâu. Và khi hệ thống càng tự hành, khoảng cách giữa điểm benchmark và hiệu năng thực trên production càng giãn ra. Kết quả là thứ nhiều team đang trải qua: điểm benchmark cao, nhưng hành vi trên production không đáng tin.

![Slide AI systems evolved faster than our evaluation methods: đồng hồ 90% benchmark accuracy bên trái, đồ thị reliability sụt mạnh bên phải](https://homus.dev/photos/vljxQZfJ9wY-0104.jpg)

"AI systems evolved faster than our evaluation methods". Bên trái là "The Illusion": một đồng hồ chỉ 90% Benchmark Accuracy. Bên phải là "The Reality": một đường đi ngang quanh mức cao rồi sụt mạnh sau T+10ms, dao động và rơi xuống sát đáy về phía T+100ms, với các nhãn Invisible Failure Modes, Degraded Production Behavior và Unpredictable User Reliability Gaps.

## 3. Paradigm shift: từ output sang behavior

LLM evaluation truyền thống tập trung vào output: model có tạo ra đáp án đúng không? Hệ thống agentic buộc ta hỏi một câu khác: hệ thống có hành xử đúng không?

Behavior ở đây gồm chất lượng planning, cách dùng tool, việc thực thi, việc chạy hết workflow, khả năng phục hồi sau lỗi, và cách ra quyết định. Nói cách khác, ta đang chuyển từ đánh giá câu trả lời sang đánh giá workflow, và điều đó đòi hỏi những kiến trúc evaluation khác hẳn về bản chất.

![Bảng The Paradigm Shift: Output vs. Behavior so sánh Traditional LLM Evaluation với Agent Evaluation](https://homus.dev/photos/vljxQZfJ9wY-0136.jpg)

"The Paradigm Shift: Output vs. Behavior". Bảng so bốn dòng giữa Traditional LLM Evaluation và Agent Evaluation: mục tiêu đi từ Output Accuracy sang Workflow Behavior; môi trường từ Static Datasets sang Dynamic Contexts; cách thực thi từ Single-path Processing sang Multi-path & Tool Dependent; kiểu lỗi từ Hallucination sang Cascading Workflow Failure (lỗi dây chuyền trong workflow, được tô màu cam để nhấn mạnh).

## 4. Giải phẫu các kiểu failure của agent

Nhiều team vẫn nghĩ hallucination là failure mode chính của AI. Trên production, hallucination thường chỉ là một hạng mục. Hệ thống agentic sinh ra cả một hệ thứ bậc failure mode.

Ở tầng nền là memory failure, retrieval failure và safety failure. Đi lên trên, ta phải tính tới reasoning sai, planning kém, và thực thi tool sai. Ở tầng cao nhất là failure trong việc phối hợp nhiều agent (multi-agent coordination). Đó là lý do việc chỉ đánh giá output của model bỏ sót phần lớn những rủi ro production mà Nishant quan sát được.

![Kim tự tháp The Anatomy of Agentic Failure với các vết nứt màu cam lan từ đáy lên đỉnh](https://homus.dev/photos/vljxQZfJ9wY-0208.jpg)

"The Anatomy of Agentic Failure": một kim tự tháp bằng gạch có vết nứt màu cam lan từ dưới lên. Nhãn từ đáy lên: Foundation là Memory (Incorrect retrieval) và Safety (Unsafe actions); tiếp theo là Reasoning (Wrong decisions), Planning (Bad task decomposition), Tool Usage (Wrong API execution); trên đỉnh là Apex: Coordination (Multi-agent conflicts).

## 5. Nghĩ như một SRE: reliability thay cho accuracy

Một trong những thay đổi tư duy hữu ích nhất là thôi nghĩ như nhà nghiên cứu, và bắt đầu nghĩ như một SRE (Site Reliability Engineer) hay một production engineer. SRE không đo thành công bằng accuracy. Họ đo reliability, availability, latency, cost, và khả năng recovery. Hệ thống agentic cần đúng cách tiếp cận đó.

Mục tiêu không phải là tối đa hoá điểm benchmark, mà là tối đa hoá những kết quả có thể tin cậy được. Reliability trở thành North Star metric (chỉ số kim chỉ nam). Accuracy chỉ còn là một input trong số nhiều input.

![Slide Think like an SRE: một trục Accuracy đơn lẻ chuyển thành biểu đồ radar System Reliability bảy chiều](https://homus.dev/photos/vljxQZfJ9wY-0240.jpg)

"Think like an SRE: Accuracy gives way to Reliability". Bên trái là một trục đơn lẻ mang nhãn Accuracy; mũi tên dẫn sang biểu đồ radar bảy chiều có tâm là System Reliability: Task Success, Tool Success, Planning Quality, Latency, Cost, Safety và Human Satisfaction. Accuracy từ một con số duy nhất trở thành chỉ một phần của bức tranh.

Nếu muốn đọc thêm về cách SRE nghĩ về reliability, [cuốn Site Reliability Engineering của Google](https://sre.google/sre-book/table-of-contents/) là tài liệu gốc của cách tiếp cận này.

## 6. Kim tự tháp tín hiệu evaluation

Kim tự tháp này là cách Nishant tự mình nghĩ về các hệ thống AI evaluation hiện đại.

Ở đáy là benchmark. Chúng hữu ích, scale được, lặp lại được (repeatable), nhưng giá trị vận hành của chúng có giới hạn. Ở giữa là scenario-based evaluation, tức những bài đánh giá mô phỏng các workflow thực tế. Ở đỉnh là production telemetry. Đây là nơi sinh ra những tín hiệu evaluation có giá trị cao nhất.

Điều bất ngờ, theo Nishant, là phần lớn dữ liệu evaluation thường đến từ chính user thật tương tác với hệ thống thật.

![Kim tự tháp The Evaluation Signal Hierarchy: Benchmarks ở đáy, Scenario Evals ở giữa, Production Telemetry ở đỉnh](https://homus.dev/photos/vljxQZfJ9wY-0312.jpg)

"The Evaluation Signal Hierarchy". Đáy là Benchmarks: "High volume, low operational value. The foundation, not the destination" (nhiều về số lượng, ít giá trị vận hành, là nền móng chứ không phải đích đến). Giữa là Scenario Evals: Targeted workflows. Đỉnh tô xanh đậm là Production Telemetry, mà trên slide ghi là "Low volume, maximum signal value". Mũi tên Volume chỉ xuống phía đáy, mũi tên Operational Value chỉ lên phía đỉnh.

## 7. Offline eval: chạy theo scenario, không theo prompt

Offline evaluation vẫn quan trọng, nhưng phương pháp thay đổi. Thay vì đánh giá từng prompt, ta đánh giá cả scenario. Ví dụ: một workflow customer support, một workflow code generation, một workflow research.

Agent hoạt động bên trong môi trường mô phỏng đó. Ta đo task completion rate, độ đúng khi dùng tool (tool correctness), chất lượng planning, và resource usage, thứ mà ở quy mô lớn sẽ tăng theo cấp số nhân. Điểm cần nhớ: agent evaluation phải scenario-driven, không phải prompt-driven.

![Sơ đồ Offline Evals: Scenario-Driven Simulation, Test Runner chạy vào Agent Sandbox rồi ra Discrete Outputs và bảng Metrics](https://homus.dev/photos/vljxQZfJ9wY-0344.jpg)

"Offline Evals: Scenario-Driven Simulation". Một Test Runner đẩy việc vào Agent Sandbox (khung nét đứt), bên trong là Simulated Tools, Execution Steps và State Update, rồi ra Discrete Outputs. Bảng Metrics ví dụ: Completion Rate 98.5%, Tool Correctness 100%, Plan Quality High, Simulated Cost $0.05. Dòng chốt dưới đáy: "Scenario-driven, not prompt-driven."

## 8. Online eval: production là dataset lớn nhất

Khi một hệ thống đã lên production, mọi tương tác đều trở thành tín hiệu. Đây là một trong những thay đổi lớn nhất trong tư duy về evaluation: traffic trên production không còn chỉ là traffic, nó trở thành dữ liệu evaluation.

Ta thu thập execution trace, kết quả cuối cùng của user, các lần escalation (chuyển lên người xử lý), các lần thất bại, và các tín hiệu feedback. Production là dataset evaluation lớn nhất và mang tính đại diện nhất mà bất kỳ tổ chức nào từng có.

![Sơ đồ Online Evals: The Production Stream, nhiều luồng User Interactions đi qua Evaluation Gateway, tách ra Metadata & Telemetry và Analytics Database](https://homus.dev/photos/vljxQZfJ9wY-0416.jpg)

"Online Evals: The Production Stream". Rất nhiều luồng User Interactions gom lại, đi qua một Evaluation Gateway; sau cổng này dòng chính tiếp tục chạy, đồng thời tách ra một nhánh Metadata & Telemetry đổ xuống Analytics Database. Băng chữ dưới cùng: "Production is your largest evaluation dataset. Every interaction is signal."

## 9. Con người là evaluator, không phải fallback

Nhiều tổ chức coi con người là hệ thống dự phòng (fallback): khi máy không xử lý được thì đẩy cho người. Nishant cho rằng cách đóng khung đó sai. Con người chính là evaluator.

Họ cho ra những tín hiệu mà hệ thống tự động không tạo được: họ đánh giá độ đúng (correctness), mức độ tin tưởng (trust), mức hữu ích (usefulness) và độ an toàn (safety). Những tín hiệu này trở nên cực kỳ quan trọng để hiệu chỉnh (calibrate) evaluation pipeline và để tìm ra những điểm mù của các metric tự động. Những hệ thống thành công nhất kết hợp automated evaluation với human review có chủ đích, nhắm vào đúng chỗ cần.

![Sơ đồ Human-in-the-Loop Calibration: Automated Alert vào Review Node rồi quay về Core Model, cạnh bốn đồng hồ Correctness, Usefulness, Trust, Safety](https://homus.dev/photos/vljxQZfJ9wY-0440.jpg)

"Human-in-the-Loop Calibration". Một Automated Alert đi vào Review Node (có hình một người), từ đó một vòng cong dẫn feedback quay về Core Model. Bên phải là bốn đồng hồ đo: Correctness, Usefulness, Trust, Safety. Câu chốt: "Humans are evaluators, not merely fallback systems."

## 10. Sát thủ thầm lặng: agent drift

Hệ thống agent drift liên tục. Model thay đổi: cứ vài tuần hay vài tháng lại có một version mới. Prompt có thể đổi, tool có thể đổi, hành vi của user có thể đổi.

Cái khó là không một thay đổi đơn lẻ nào trông giống thảm hoạ. Reliability xuống cấp từ từ: success rate giảm dần, escalation tăng lên, tool failure nhích lên. Không có evaluation liên tục, các team thường không phát hiện drift cho tới khi user bắt đầu phàn nàn. Vì vậy continuous monitoring trở thành điều bắt buộc.

![Đồ thị The Silent Killer: Agent Drift, đường System Reliability đi ngang 100% rồi tụt bậc qua từng thay đổi](https://homus.dev/photos/vljxQZfJ9wY-0504.jpg)

"The Silent Killer: Agent Drift". Degradation Curve: trục dọc là System Reliability, trục ngang là Time. Đường reliability đi ngang ở 100%, rồi tụt dần qua bốn điểm đánh dấu Model Updates, Prompt Changes, Tool/API Changes và User Behavior Shifts, xuống còn khoảng 40%. Hộp cảnh báo: Dropping success rates, Rising escalation rates, Spiking tool errors.

## 11. Observability là điều kiện tiên quyết

Observability và evaluation không thể tách rời. Để đánh giá một agent, ta cần nhìn thấy reasoning path, các tool call, các lần truy cập memory, timeline thực thi, và các lần chuyển trạng thái (state transition), như trong biểu đồ trên slide.

Log truyền thống là không đủ. Ta cần trace chi tiết, giống hệt như với bất kỳ kiến trúc microservice lồng nhau sâu nào, cho bất kỳ ứng dụng hay service nào. Agent trace trở thành thứ tương đương với distributed tracing, nhưng cho các workflow tự hành. Không có observability, evaluation trở thành phỏng đoán.

![Slide Observability is the Prerequisite: trace waterfall của một agent và bảng Live Metrics Dashboard](https://homus.dev/photos/vljxQZfJ9wY-0536.jpg)

"Observability is the Prerequisite". Bên trái là The Trace Waterfall của một lượt chạy: thanh User Prompt dài bao trùm, bên dưới là Planner Iteration, Vector DB Lookup, rồi ba Parallel API Tool Calls (API A 45ms, API B 38ms, API C 52ms) chạy song song. Bên phải là Live Metrics Dashboard: Latency 345 ms, Retries 2.5%, Step Costs $0.014, Memory Usage 480 MB. Câu dưới đáy: "You cannot evaluate what you cannot observe."

Với ai muốn bắt đầu, khái niệm trace và span trong [tài liệu OpenTelemetry](https://opentelemetry.io/docs/concepts/signals/traces/) chính là nền của distributed tracing mà Nishant so sánh.

## 12. Vòng lặp evaluation liên tục

Nishant nói về continuous evaluation loop, vì evaluation là một service luôn chạy, không phải một giai đoạn test. Trước đây evaluation luôn diễn ra trước khi deploy. Giờ evaluation tiếp tục cả sau khi deploy.

Vòng lặp đi như sau. Telemetry phát hiện vấn đề, ở điểm A. Con người review các edge case. Feedback cải thiện các dataset. Các offline scenario kiểm chứng những bản cập nhật. Vòng lặp không bao giờ dừng. Evaluation không còn chỉ là một giai đoạn, nó là một năng lực vận hành.

![Sơ đồ vòng tròn The Continuous Evaluation Loop với bốn điểm A, B, C, D](https://homus.dev/photos/vljxQZfJ9wY-0608.jpg)

"The Continuous Evaluation Loop". Giữa vòng tròn: "Evaluation is an always-running service, not a testing phase." Bốn điểm theo chiều kim đồng hồ: A, Online Telemetry detects drift/errors; B, Triggers HITL review for edge cases; C, Human feedback feeds into Offline Datasets; D, Offline Scenario Evals validate system updates before pushing back to Production. Từ D, vòng quay lại A.

## 13. Reliability scorecard: metric nào nối với kết quả kinh doanh nào

Nishant gọi đây có lẽ là slide quan trọng nhất của bài. Mỗi metric trên đó nối thẳng vào một kết quả kinh doanh:

- **Task completion** đo giá trị được tạo ra.

- **Tool success** đo reliability vận hành.

- **Escalation rate** đo gánh nặng đè lên con người.

- **Safety evaluation** đo mức độ phơi nhiễm rủi ro.

- **Latency** ảnh hưởng tới trải nghiệm user.

- **Cost** quyết định khả năng scale.

- **Recovery rate** phản ánh độ bền bỉ (resilience).

Và hãy để ý: accuracy không có trong danh sách. Không phải vì accuracy không quan trọng, mà vì thành công về kinh doanh phụ thuộc vào nhiều thứ hơn hẳn accuracy.

![Bảng The Reliability Scorecard nối Engineering Metric với Business & Operational Impact](https://homus.dev/photos/vljxQZfJ9wY-0640.jpg)

"The Reliability Scorecard": cột trái là Engineering Metric, cột phải là Business & Operational Impact. Task Completion nối với Business Outcome, Tool Success với Operational Reliability, Escalation Rate với Human Burden, Safety Violations với Risk Exposure, Latency với User Experience, Cost per Task với System Scalability, Recovery Rate với System Resilience.

## 14. Agentic control plane: kiến trúc tham chiếu

Đây là kiến trúc mà ngành đang đi tới, ở mức độ nhiều hay ít. Evaluation trở thành một phần của control plane, không phải một tool riêng, cũng không phải một quy trình offline.

Control plane liên tục quan sát hệ thống, thu thập telemetry, chạy simulation, và điều phối human review, còn execution plane là nơi thực hiện công việc. Control plane đo lường và điều tiết (govern) hành vi. Sự tách bạch này đang trở thành một pattern nền tảng cho các hệ thống AI trên production.

![Sơ đồ The Agentic Control Plane Reference Architecture: Control Plane bốn khối ở trên, Execution Plane với LLM, Agent Orchestrator, External Tools ở dưới](https://homus.dev/photos/vljxQZfJ9wY-0712.jpg)

"The Agentic Control Plane Reference Architecture". Tầng trên, Control Plane, có bốn khối: Tracing & Observability, Telemetry Stream Analytics, Scenario Simulators (Offline), HITL Calibration UI. Một đường nét đứt ngăn với tầng dưới, Execution Plane, gồm LLM, Agent Orchestrator và External Tools. Các mũi tên từ cả bốn khối control plane đổ xuống execution plane, phần lớn dồn vào Agent Orchestrator.

Nishant cũng có một talk khác trong cùng Online Track đi sâu vào agent control plane từ góc độ hạ tầng: Building Deterministic Infrastructure for Non-Deterministic AI Agents.

## 15. Năm bài học: evaluation đang trở thành infrastructure

Nishant tóm lại các bài học chính:

- Benchmark vẫn cần thiết, nhưng không đủ.

- Hệ thống agent phải được đánh giá như những workflow, không phải như từng output riêng lẻ.

- Production telemetry là tín hiệu evaluation quan trọng nhất.

- Rốt cuộc, reliability quan trọng hơn raw accuracy của model.

- Và cuối cùng, evaluation đang trở thành infrastructure. Không phải testing, không phải QA, mà là infrastructure.

Đây là sự chuyển dịch mà mọi tổ chức đang xây AI agentic rồi sẽ phải thực hiện.

![Slide Architectural Imperatives với năm điểm đánh số và câu trích dưới cùng](https://homus.dev/photos/vljxQZfJ9wY-0736.jpg)

"Architectural Imperatives", năm điểm: offline benchmark cần nhưng chưa đủ; hệ thống agentic phải được đánh giá như workflow trọn vẹn; production telemetry là tín hiệu evaluation tối hậu; reliability luôn đặt trên raw model accuracy; eval không còn là test, chúng là core infrastructure. Câu trích dưới cùng: "You can't improve what you don't continuously evaluate."

## Nguồn và liên kết

- Trang talk chính thức: [ai.engineer/talks/vljxQZfJ9wY](https://ai.engineer/talks/vljxQZfJ9wY)

- Video gốc: [youtube.com/watch?v=vljxQZfJ9wY](https://www.youtube.com/watch?v=vljxQZfJ9wY)

- Talk cùng tác giả trong Online Track: Building Deterministic Infrastructure for Non-Deterministic AI Agents

- Google, Site Reliability Engineering: [sre.google/sre-book](https://sre.google/sre-book/table-of-contents/)

- OpenTelemetry, khái niệm trace: [opentelemetry.io/docs/concepts/signals/traces](https://opentelemetry.io/docs/concepts/signals/traces/)

- Nishant Gupta trên GitHub: [github.com/nishantgpt-lab](https://github.com/nishantgpt-lab) · LinkedIn: linkedin.com/in/nishantgupta-ai