AI Agent Observability: Hướng dẫn giám sát, SLA và RFP cho nhà máy

AI Agent Observability là khả năng dựng lại không chỉ việc đã có câu trả lời hay chưa, mà còn cách một yêu cầu nghiệp vụ đi qua model, dữ liệu, tool và phê duyệt để tạo ra kết quả vận hành. Trong sản xuất, conversation log là chưa đủ. Thiết bị, mã sản phẩm, lot, work order, ca, thời gian nhà máy, tool execution, chỉnh sửa của nhân viên và chi phí phải được nối bằng một correlation ID rồi chuyển thành bằng chứng cho phát hiện bất thường, phân tích nguyên nhân, kiểm tra SLA và cải tiến. Bài này trình bày thiết kế telemetry, RFP, lộ trình 90 ngày đề xuất và nghiệm thu cho vận hành nhiều site, bao gồm nhà máy tại Thái Lan.

Kết luận trước: quan sát toàn bộ business session, không chỉ model

Thời gian đáp ứng LLM API không cho biết chất lượng nghiệp vụ của AI Agent. Agent kết hợp retrieval, planning, chọn tool, truy vấn ERP/MES, chờ duyệt, retry và handoff. Câu trả lời cuối có thể trông đúng trong khi agent đã đọc dữ liệu cấm, truy vấn sai asset, thực hiện một yêu cầu hai lần hoặc buộc operator sửa cùng một điểm trong mọi ca.

Vì vậy, đơn vị quan sát tối thiểu không phải một model call mà là session có mục đích nghiệp vụ. Dưới session có một hoặc nhiều trace; model generation, retrieval, tool call, approval, guardrail, external API và human intervention được biểu diễn thành span. Tài liệu chính thức OpenAI Agents SDK cũng mô tả trace là end-to-end workflow gồm các span có thời điểm bắt đầu/kết thúc và quan hệ cha-con. Đây là ví dụ triển khai hữu ích, không phải yêu cầu sao chép định dạng một nhà cung cấp thành tiêu chuẩn nội bộ.

Bài này tập trung vào telemetry và đo lường vận hành. Vận hành API cho AI Agent tập trung platform/API, đánh giá liên tục và audit AI Agent tập trung evaluation/reapproval, còn AI Agent incident response tập trung containment/recovery sau sự cố. Observability là lớp xuyên suốt cung cấp bằng chứng theo thời gian cho tất cả các phần đó.

Mô hình cơ bản của AI Agent tracing

Session: mục đích nghiệp vụ và bối cảnh người dùng

Session không chỉ là thời gian ở cửa sổ chat. Nó đại diện mục tiêu như “phân tích nguyên nhân Line 3 dừng và chuẩn bị maintenance request” hoặc “xác định linh kiện thiếu và đưa purchase request sang trạng thái chờ duyệt”. Session nên có business case ID, site, user role, thời gian bắt đầu/kết thúc, outcome, plant business date, data classification và policy version.

Nếu case tiếp tục sang ngày hôm sau, hãy nối bằng business ID dù ứng dụng tạo conversation mới. Nếu một chat xử lý nhiều work order, mỗi work order nên có trace riêng. Việc tách đơn vị được UI dùng để thuận tiện khỏi đơn vị bằng chứng là cần thiết để phân tích cost, quality và accountability.

Trace: đường thực thi đến một kết quả

Trace là đường từ yêu cầu nghiệp vụ đến outcome. Nó nên chứa session ID, actor khởi tạo, agent version, model configuration, start/end, status, outcome và external transaction liên quan. Khi giao việc cho agent khác, giữ parent trace hoặc trace link để tìm lại toàn bộ đường đi.

Không nên tuyên bố tracing cho thấy toàn bộ suy luận bên trong model. Thứ quan sát được là input/output được phép, nguồn retrieval, tool request, policy decision, approval, external response, thời gian và usage. Việc trộn sự thật quan sát được với giả định về hidden reasoning sẽ làm audit yếu đi.

Span: đơn vị operation để tách delay, failure và trách nhiệm

Span là operation có đầu và cuối: model generation, RAG retrieval, data transformation, tool execution, approval wait hoặc human override. Tối thiểu lưu span ID, parent span ID, operation, timestamp, status, error type, attempt, service, site, tool/model và input/output reference.

Nhiều span hơn chưa chắc tốt hơn. Quá chi tiết làm tăng storage và thời gian điều tra; quá thô che mất nguyên nhân. Nên tách span khi service chịu trách nhiệm đổi, recovery method đổi, charging unit đổi, hoặc phát sinh approval/external side effect.

Nối bối cảnh nhà máy vào bằng chứng

Bối cảnh vật lý là khác biệt giữa monitor agent trong nhà máy và chatbot thông thường. Cùng output “bất thường” nhưng ý nghĩa thay đổi theo asset, product, lot, recipe, machine mode, shift, sensor freshness và maintenance state. Hãy nối trace với:

• site, area, line và asset ID;
• work order, batch, lot và product code;
• shift, UTC và giờ nhà máy cùng time zone;
• recipe/version và PLC/MES/ERP transaction ID;
• sensor snapshot, thời điểm lấy, quality flag và missing-data state;
• model, prompt, policy, tool, connector và knowledge-base version;
• operator ID hoặc pseudonymous ID, role và approval ID; và
• final business outcome cùng quality/downtime/delivery record dùng xác minh sau đó.

Không sao chép toàn bộ sensor data và document vào trace store. Đặt snapshot trong evidence repository; trong trace chỉ lưu hash, timestamp, schema version và access-controlled reference. Như vậy telemetry không biến thành confidential data lake mới nhưng vẫn reconstruct được.

Clock quality cũng quan trọng. Nếu cloud, terminal, MES, PLC và camera không đồng bộ, một sự kiện có thể xuất hiện trước nguyên nhân. Hãy lưu time source và synchronization state, dùng UTC làm trục chung và hiển thị ICT cho vận hành. Sự bất định được ghi rõ là bằng chứng tốt hơn thứ tự thời gian chính xác giả tạo.

Thiết kế LLM observability metrics theo năm lớp

1. Usage: ai dùng gì và cho mục đích nào

Đếm session, active user, business process, site, shift, agent version và completion state. Volume cao tự nó không phải thành công. Kết hợp với quality, elapsed time, human effort và outcome. Một đợt tăng có thể do adoption nhưng cũng có thể do retry loop hoặc UI fault.

2. Reliability: completion, error, retry và duplicate

Tách error, timeout, retry, partial completion, duplicate side effect, dead letter, tool denial, fallback và abstention. Abstain an toàn không giống system error. Abstention tăng có thể là tín hiệu sớm của dữ liệu thiếu hoặc yêu cầu ngoài scope.

3. Responsiveness: tách thời gian con người phải chờ

Đo end-to-end latency, time to first response, model, retrieval, tool, approval và queue time. Average che peak và long tail, nên dùng percentile và distribution. Target phải theo use case: hỗ trợ điều tra chất lượng và xử lý ban đầu khi line dừng không thể có cùng thời gian chấp nhận.

4. Human collaboration: override, approval và handoff

Lưu approval request/outcome, human handoff, operator edit, override reason, số lần nhập lại và thời gian chưa xử lý. Override cao có thể do model, nhưng cũng có thể do master data kém, quyền thiếu, màn hình khó review hoặc thuật ngữ địa phương không khớp. Hãy giữ reason code và structured diff, không chỉ free text.

5. Value and cost: nối phí model với kết quả nghiệp vụ

Phân bổ input/output token, model call, retrieval, external API, telemetry storage, evaluation và thời gian human review cho business case. Ngoài cost per session, có thể thiết kế cost per completed case, per approved action hoặc per avoided manual minute thành metric nội bộ đề xuất. Phải thống nhất baseline và nghĩa của “avoided” trước, đồng thời tách estimate khỏi actual.

OpenTelemetry GenAI semantic conventions có attribute cho model, operation, token, response ID, finish reason, time to first chunk, retrieval và tool call. Đây là điểm khởi đầu interoperability, nhưng registry có version và attribute có thể di chuyển hoặc deprecated. RFP nên pin semantic-convention version và yêu cầu mapping table sang canonical field nội bộ.

Chia AI Agent SLA thành ba lớp

“Availability 99,9%” không chứng minh agent hoàn thành nghiệp vụ. Nên chia SLA/SLO thành:

1. Technical service level: API availability, trace ingestion, tool connection, queue processing và monitoring delay.
2. Agent execution level: session completion, end-to-end latency, error, abstention, duplicate side effect và approval wait.
3. Business outcome level: liên kết work order đúng, operator correction, processing time, deadline completion và quality result.

Các giá trị sau là ví dụ thiết kế, không phải chuẩn chung.

Thay số theo loss, volume, acceptable delay và supervision. Với nghiệp vụ ít case, báo cáo cả số lượng và tỷ lệ vì một case có thể chi phối phần trăm. NIST AI 600-1 cảnh báo việc dựa quá mức vào định lượng mà không hiểu context và limitation. Dashboard là điểm bắt đầu của quyết định, không phải quyết định.

Xem tool call như sổ cái của side effect

Bằng chứng quan trọng thường không phải agent nói gì mà là đã làm gì. Mỗi tool call nên lưu tool name/version, caller, target, operation, argument reference, policy decision, approval, idempotency key, request/response state, external transaction, retry và compensation.

Tool argument có thể chứa supplier, giá, asset, dữ liệu cá nhân hoặc token. Không giữ raw argument vô hạn. Định nghĩa allow, mask, hash, drop hoặc secure-reference theo field. Asset ID có thể tìm kiếm, free-text comment cần classified storage, secret không được log, purchase amount có thể cần giới hạn role.

Đặt approval thành span riêng và so sánh proposed payload hash với executed payload hash. Nếu target, quantity hoặc asset state đổi sau duyệt, không dùng lại approval. Với rejection, lưu reason, wait time và alternative vì chúng giúp cải tiến permission và UI.

Không trộn error, abstention và override

Cần phân biệt trạng thái:

• system error: lỗi service, network, authentication hoặc schema;
• task failure: không hoàn thành nghiệp vụ;
• policy denial: policy chặn đúng như thiết kế;
• abstention: agent không trả lời/thực hiện vì thiếu bằng chứng hoặc ngoài scope;
• human override: người sửa hoặc hủy đề xuất;
• user abandonment: người dùng rời đi trong lúc chờ; và
• partial completion: chỉ hoàn thành một phần.

Nếu mọi trạng thái đều là failure, safe refusal trở thành KPI xấu và nhóm sẽ tối ưu để giảm từ chối. Nếu mọi abstention đều được xem là an toàn, agent có thể che việc không làm được. Đặt expected range cho từng use case và kết hợp reason code với sample review.

Quyết định redaction, minimization và retention trước

Tài liệu OpenAI Agents SDK giải thích generation span có thể giữ model input/output và function span có thể giữ tool input/output, đồng thời có setting tắt sensitive-data capture. Microsoft Foundry cũng cảnh báo input, output và tool arguments/results có thể nhạy cảm; tài liệu khuyên không đưa secret vào, redact/minimize trước telemetry và dùng access/retention như production.

Dùng bốn điểm kiểm soát:

1. Trước thu thập: không chuyển secret qua prompt/tool; inject tại broker nếu cần.
2. Khi ingest: phát hiện tên, liên hệ, khách hàng, giá, credential pattern rồi drop/tokenize.
3. Sau lưu: encryption, tenant/site separation, role access, audit và expiry.
4. Khi hiển thị: operation thường xem summary; chi tiết mật cần request access.

Tránh “giữ tất cả rồi tính sau”. Đặt retention theo investigation, contract, quality, privacy, cost và learning use. Ví dụ ordinary span 30 ngày, aggregate 13 tháng, serious event giữ theo case chỉ là một phương án đề xuất. Cần thống nhất với tư vấn địa phương, hợp đồng khách hàng và quy định công ty.

OpenAI cũng nêu built-in tracing không có cho tổ chức dùng OpenAI API theo Zero Data Retention policy. Hãy xác minh contract, configuration và exporter thực tế. Nếu không dùng được, cung cấp internal OpenTelemetry collector hoặc business-event ledger; không giả định thấy dashboard nghĩa là evidence được lưu.

Thay đổi sampling theo rủi ro và giá trị bằng chứng

Một tỷ lệ duy nhất khiến success log ít giá trị chiếm dung lượng còn failure quan trọng có thể mất. Chính sách nhiều tầng đề xuất:

• giữ prohibited action, write tool, approval, override, error, policy denial và critical asset 100%;
• tạm tăng new release, first site hoặc night shift lên 100%;
• giữ detailed trace ví dụ 10–20% routine read-only success, nhưng đếm metrics toàn bộ;
• dùng tail-based sampling để giữ trace có latency, token, cost hoặc span count bất thường; và
• bảo đảm đại diện của process, language, site và shift.

Các tỷ lệ này chỉ là ví dụ. Ngay cả trace bị sample out vẫn nên giữ case ID, result, main metric và external-transaction reference tối thiểu. Version sampling rule để giải thích vì sao chi tiết vắng mặt tại thời điểm đó.

Kiến trúc observability trung lập nhà cung cấp

Kiến trúc thực tế gửi telemetry từ agent runtime đến collector bằng OpenTelemetry hoặc định dạng tương đương. Collector normalize schema, redact, sample rồi route đến trace, metric và log/evidence store. Business DB, MES, ERP và quality system được nối qua transaction/case ID. Một UI có thể tổng hợp, nhưng original evidence tách khỏi aggregate.

AWS AgentCore là ví dụ lưu metrics, spans và logs vào CloudWatch với trace visualization, custom span metrics và error breakdown. Microsoft Foundry cho xem theo span và gửi vào Application Insights. Hai ví dụ không phải bảo đảm chọn sản phẩm. RFP cần trung lập với export format, schema, location/region, encryption, search, cost, outage behavior và portability.

Cũng phải thiết kế khi collector hỏng. Với write quan trọng, quyết định evidence thiếu thì block, local buffer hay degraded mode. Thử buffer đầy, network loss, replay, duplicate ingestion và clock skew. Dùng idempotency key riêng cho business side effect và telemetry delivery.

Câu hỏi cho AI Agent observability RFP

Data model và correlation

• Session, trace, span, business case và external transaction liên hệ ra sao?
• Biểu diễn multi-agent handoff, parallel tool, retry và long-running job thế nào?
• Site, line, asset, work order, lot và shift nào là field chuẩn?
• Pin và migrate schema/semantic-convention version ra sao?

Collection và confidentiality

• Model/tool input/output có được giữ mặc định không; có loại từng field được không?
• Redaction trước khi gửi hay sau lưu; khi thất bại default behavior là gì?
• Residency, encryption, key, access, retention và legal hold được xử lý thế nào?
• Ai duyệt tăng capture tạm thời để debug và tự hết hạn ra sao?

Performance, cost và availability

• Đo overhead telemetry lên latency, CPU, network thế nào?
• Peak ingestion, buffer, backpressure và drop policy là gì?
• Phân bổ token, tool, storage, query, egress theo case được không?
• High-risk write có dừng khi observability không hoạt động không?

Operations và evidence

• Từ alert đến trace, tool và external transaction mất bao nhiêu bước?
• Có bàn giao raw export, API, schema, dashboard, runbook và training không?
• Thay đổi alert, redaction, sampling và dashboard có audit được không?
• Khi kết thúc hợp đồng có xuất evidence/settings ở định dạng chuẩn không?

Đánh giá bằng screen, export sample, failure test, search time và responsibility, không phải checkbox “supported”. Đưa telemetry loss, correlation, redaction, sampling và cost reproduction vào cổng nghiệm thu AI Agent. Với OT write, cần đáp ứng riêng privilege, execution broker và safety layer trong hướng dẫn bảo mật Industrial AI Agent.

Lộ trình triển khai 90 ngày đề xuất

Đây là lịch đề xuất, không phải quy tắc chung.

Ngày 0–15: định nghĩa business ID và câu hỏi vận hành

Giới hạn ở một process và một site. Viết câu hỏi operation phải trả lời: Vì sao chậm? Tool nào lỗi? Ai sửa? Một case tốn bao nhiêu? ERP transaction có hoàn thành không? Kiểm kê log, data classification, clock, transaction ID, owner rồi định nghĩa minimum session/trace/span schema.

Không bắt đầu bằng việc trang trí dashboard. Nếu case ID không nối UI, agent, tool và external system, graph đẹp cũng không hỗ trợ điều tra.

Ngày 16–30: triển khai instrumentation, redaction và time

Thêm span cho model, retrieval, tool, approval, handoff. Normalize vào internal schema tại collector. Làm field policy cho secret, personal data, customer và price. Xác nhận UTC/local time, clock source và tách development, validation, production.

Ngày 31–45: nối metric/alert với outcome

Tổng hợp latency, error, retry, abstention, override, approval, token và tool cost rồi reconcile với ERP/MES completion. Bắt đầu bằng threshold ghi rõ là đề xuất và tinh chỉnh trên baseline hai tuần. Mỗi alert có owner, runbook, severity, acknowledge expectation và close condition.

Ngày 46–60: inject failure và reconstruct evidence

Inject tool timeout, auth hết hạn, schema mismatch, collector outage, buffer đầy, approval hết hạn, duplicate retry và clock skew. Xác nhận một business case bất kỳ có thể lần theo trace, span, external transaction và operator action. Dùng negative test để bảo đảm nội dung mật không rò qua search/export.

Ngày 61–75: chỉnh SLO, sampling và cost

Đề xuất p95, error budget, override review, cost anomaly theo use case và duyệt bằng số đo/loss impact. Thử full capture cho high risk và sample low-risk success. Cân bằng storage/query cost, network và alert workload với giá trị evidence.

Ngày 76–90: nghiệm thu và handover

Hoàn thành evidence tương đương FAT/SAT với ca ngày/đêm, input Thái/Anh/Nhật, network địa phương và đổi người phụ trách. Xác nhận operation tự search, lập cause hypothesis, kiểm redaction, close alert và export mà không cần supplier. Với gap nhỏ dùng conditional acceptance có owner, deadline, workaround, retest; nếu thiếu evidence quan trọng thì dừng production.

Làm bằng chứng nghiệm thu có thể tái tạo

Tối thiểu gồm các case:

1. Theo một yêu cầu từ session đến external transaction.
2. Giữ quan hệ parallel tool, handoff và retry.
3. Xác định model/tool version, policy và knowledge snapshot.
4. Tách latency thành queue, model, retrieval, tool và approval.
5. Phân loại error, abstention, denial, override và abandonment.
6. Đối chiếu write argument, approval, idempotency và result.
7. Secret/field chỉ định không xuất hiện trong trace, log, dashboard, export.
8. Phát hiện loss/duplicate qua collector outage và reconnect.
9. Detail sample out vẫn còn minimum case/result reference.
10. Tính lại cost per case kèm dữ liệu.
11. Nối đúng UTC/plant time, asset, work order và lot.
12. Operator dùng runbook và lưu close reason.

Nối requirement ID, test ID, trace ID, expected/actual, evidence, reviewer, defect và retest. Giữ machine-readable export và query, không chỉ screenshot. Phải chạy lại được cùng case sau khi đổi dashboard/platform.

Khác biệt vận hành cần xác minh tại site Thái Lan

ETDA Generative AI Governance Guideline thảo luận giới hạn về domain context, freshness, explainability và output consistency, khuyến nghị human participation và cập nhật công nghệ. Tài liệu cũng phân adopter, customizer, maker. Nhà máy dùng SaaS, nhà máy tự làm RAG/tool và tổ chức tự phát triển model không sở hữu cùng telemetry scope.

Tại site Thái, đưa tên/từ viết tắt thiết bị địa phương, shift, approver tại chỗ, giờ ICT và network condition vào đo lường, không chỉ policy tiếng Nhật. Không thể so abstention/override theo ngôn ngữ nếu bỏ qua volume và độ khó. Human-review case đại diện rồi phân nguyên nhân thành translation, master data, UI hoặc permission.

Access cũng nên phân tầng. Trụ sở có thể xem aggregate/cross-site, site owner xem local detail, security xin access trace mật và supplier chỉ nhận subset đã pseudonymize. Đây là ví dụ thiết kế; hợp đồng, privacy và yêu cầu lao động quyết định mô hình cuối.

Lỗi thường gặp

Lưu toàn bộ conversation và gọi đó là monitoring

Conversation không cho thấy tool side effect, approval hay external outcome, nhưng làm tăng dữ liệu mật. Hãy lấy structured ID/event làm trung tâm và minimize content.

Chỉ xem average model API latency

Người dùng còn chờ queue, retrieval, tool và approval. Average che peak/long tail; cần end-to-end và span percentile.

Có dashboard nhưng không có hành động

Graph đỏ không cải tiến quy trình. Mỗi metric cần owner, threshold, runbook, deadline và close condition. Loại alert nhiễu cũng là một phần operation.

Chọn giữa giữ toàn bộ hoặc một sample rate chung

Đối xử risky write và routine read giống nhau sẽ mất evidence hoặc budget. Kết hợp risk-, tail- và release-based sampling.

Chỉ dựa vendor UI làm evidence

Evidence có thể mất khi hết hợp đồng, outage hoặc đổi sản phẩm. Hợp đồng phải có raw export, schema, query, setting, retention và migration.

FAQ: AI Agent monitoring và SLA

AI Agent Observability khác monitoring thông thường thế nào?

Nó bổ sung session, generation, retrieval, tool, approval, human correction, business outcome và cost lên CPU, memory, API availability. Nó mở rộng APM chứ không thay thế APM.

Tracing có cho thấy chain of thought không?

Không nhất thiết. Nó cho thấy input/output, event, retrieval, tool, approval, policy, timing và version được chủ động thu thập. Tách observed fact khỏi causal hypothesis.

Nên ghi 100% những gì?

Không có đáp án chung. High-risk write, approval, prohibited action, error, override và critical asset là ứng viên giữ structured evidence đầy đủ. Không có nghĩa là giữ mọi raw text.

Đặt số AI Agent SLA thế nào?

Dùng business loss, volume, acceptable delay, human fallback và data quality. Lấy baseline và đặt theo ba lớp technical, execution, business outcome thay vì sao chép benchmark.

Khi log quá đắt nên giảm gì trước?

Giảm duplicate content, low-value success detail và retention quá dài. Giữ metric quan trọng/correlation ID; dùng risk-based sampling, compression, tiered storage. Minimize trước collection giảm cả privacy risk và cost.

Observability có làm agent an toàn không?

Không. Nó cải thiện detection, reconstruction và learning. Permission, deterministic constraint, approval, safety PLC, incident response và continuous evaluation vẫn là control riêng. Observability không phải control.

Kết luận: theo một business case đến bằng chứng và chi phí

AI Agent Observability không phải dự án tạo thêm log. Nó nối session, trace, span với business case, asset, work order, lot, tool, approval, human intervention, external transaction và cost để operation dựng lại một case. Tách error, abstention, override; phân rã latency; minimize dữ liệu nhạy cảm trước collection; sample theo risk. RFP phải yêu cầu schema, export, redaction, retention, outage behavior và portability, sau đó xác minh correlation, fault injection, SLO và handover trong kế hoạch 90 ngày đề xuất.

TOMAS TECH có thể giúp cấu trúc ID, permission và log hiện có của nhà máy thành AI Agent Observability RFP, kế hoạch 90 ngày và acceptance case trước khi chọn sản phẩm. Nếu cần bắt đầu từ việc xác định process, evidence và operating owner, hãy liên hệ TOMAS TECH.

Tài liệu tham khảo

• OpenAI Agents SDK, Tracing: https://openai.github.io/openai-agents-python/tracing/
• OpenTelemetry, GenAI semantic conventions attribute registry: https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
• AWS, Amazon Bedrock AgentCore Observability: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html
• Microsoft, Set Up Tracing for AI Agents in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/observability/how-to/trace-agent-setup
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, AI 600-1: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• ETDA, Generative AI Governance Guideline for Organizations v2.0: https://www.etda.or.th/getattachment/6050a4b7-defd-4dba-8cbc-ff6a444a3d08/20241125-Generative-AI-Guideline_V2-0.pdf.aspx