Checklist triển khai AI Observability: 20 bước cho production
Một checklist triển khai AI observability nên trả lời một câu hỏi khó hơn “API có đang hoạt động không?” Một tính năng AI trong production có thể trả về HTTP 200 nhưng lại đưa ra câu trả lời sai, dùng ngữ cảnh truy xuất cũ, gọi nhầm công cụ, retry qua cơ chế dự phòng tốn kém, làm rò rỉ dữ liệu prompt nhạy cảm vào log, hoặc mất quá nhiều thời gian để trở nên hữu ích.
Mục tiêu thực tế là kết nối từng kết quả mà người dùng nhìn thấy với các lần thử của mô hình, các bước truy xuất, các lời gọi công cụ, quyết định chính sách, độ trễ, mức sử dụng token và chi phí đã tạo ra kết quả đó. Điều này đòi hỏi telemetry ứng dụng thông thường cộng với ngữ cảnh và tín hiệu đánh giá đặc thù cho AI.
Hướng dẫn này cung cấp một kế hoạch triển khai theo giai đoạn cho các ứng dụng LLM, agent, hệ thống retrieval-augmented generation và multi-model gateway. Nội dung không phụ thuộc nhà cung cấp và sử dụng các khái niệm OpenTelemetry khi có thể. Nó cũng bao gồm bản đồ tín hiệu-đến-quyết định, ma trận kiểm thử chấp nhận, kế hoạch rollout bảy ngày, telemetry contract, mẫu instrumentation, alert runbook và vendor scorecard để một nhóm có thể đi từ yêu cầu đến một lần ra mắt vận hành được.
AI Observability trong một câu
AI observability là khả năng giải thích hành vi, chất lượng, độ tin cậy, an toàn và chi phí của một workflow AI từ một tập hợp các trace, metric, log, evaluation và kết quả người dùng có liên quan với nhau.
Monitoring cho bạn biết một ngưỡng đã thay đổi. Observability giúp bạn xác định vì sao nó thay đổi và những request, model, prompt, kết quả truy xuất, công cụ, tenant hoặc bản phát hành nào có liên quan.
Hãy dùng checklist triển khai AI observability trong hướng dẫn này như một cổng phát hành, chứ không phải như một bài tập tài liệu làm một lần. Chạy lại checklist bất cứ khi nào bạn thay đổi model, prompt, retrieval index, tool schema, routing policy hoặc evaluator.
Đối với một ứng dụng AI, một request có thể chứa nhiều lần thử riêng biệt:
user action
└─ application workflow
├─ retrieval query
├─ model attempt 1
├─ tool call
├─ model attempt 2
└─ validation and user-visible result
Nếu những bước này không thể được ghép nối dưới cùng một trace hoặc một request identity, việc debug sẽ trở thành phỏng đoán.
Mô hình dữ liệu AI Observability tối thiểu
Mô hình dữ liệu là nền tảng của checklist triển khai AI observability vì mọi dashboard, alert, evaluation và truy vấn sự cố đều phụ thuộc vào các trường correlation nhất quán.
Bắt đầu với một trace ở cấp workflow và các span con cho mỗi thao tác quan trọng. OpenTelemetry định nghĩa trace, metric, log và baggage là các tín hiệu cốt lõi. Bộ semantic conventions cho generative AI của nó cung cấp một từ vựng đang phát triển cho các thao tác model và agent và, tính đến ngày 4 tháng 8 năm 2026, được duy trì trong kho OpenTelemetry semantic conventions chuyên dụng. Vì các conventions đó có thể thay đổi, hãy cố định phiên bản bạn triển khai và giữ một lớp tương thích nội bộ nhỏ thay vì rải tên trường đặc thù của từng nhà cung cấp khắp mã nguồn của bạn.
Tối thiểu, hãy thu thập các nhóm trường sau.
| Nhóm trường | Cần ghi lại | Vì sao điều này quan trọng |
|---|---|---|
| Liên kết tương quan | trace_id, request_id, session ID, workflow, environment, release |
Kết nối toàn bộ đường đi của request |
| Route | provider, requested model, resolved model, region, endpoint or route alias | Giải thích request thực sự chạy ở đâu |
| Lần thử | attempt number, retry reason, fallback source and destination | Tách một request của người dùng khỏi nhiều lần gọi tính phí |
| Hiệu năng | queue time, time to first token, total latency, tool and retrieval latency | Xác định giai đoạn chậm |
| Sử dụng | input, cached input, output, reasoning or provider-specific usage fields | Giải thích năng lực và chi phí |
| Kết quả | status, normalized error class, finish reason, validation result | Phân biệt thành công về truyền tải với thành công của tác vụ |
| Chất lượng | evaluator version, score, pass/fail, user feedback, accepted outcome | Theo dõi liệu phản hồi có hữu ích hay không |
| Quản trị | tenant, policy decision, redaction status, retention class | Hỗ trợ các kiểm soát về quyền riêng tư và kiểm toán |
Tránh coi prompt và response thô là các trường bắt buộc. Trong nhiều hệ thống, chúng nên bị tắt theo mặc định hoặc chỉ được lưu trong một bộ dữ liệu đánh giá được kiểm soát riêng.
Ánh xạ mọi tín hiệu tới một quyết định vận hành
Nhiều telemetry hơn không tự động tốt hơn. Trước khi thêm một thuộc tính, metric hoặc dashboard, hãy nêu rõ quyết định mà nó hỗ trợ và người chịu trách nhiệm cho quyết định đó.
| Tín hiệu | Câu hỏi mà nó trả lời | Quyết định điển hình | Chủ sở hữu chính |
|---|---|---|---|
| Tỷ lệ completion được chấp nhận | Workflow có giải quyết được tác vụ của khách hàng không? | Rollback, thay đổi prompt/model, hoặc điều tra các lỗi downstream | Product và AI engineering |
| Độ trễ end-to-end p95 | Trải nghiệm hoàn chỉnh có đủ nhanh không? | Thay đổi route, giảm độ trễ retrieval/tool, hoặc điều chỉnh streaming | Platform engineering |
| Thời gian đến token đầu tiên | Streaming có tạo cảm giác phản hồi nhanh không? | Tinh chỉnh queueing, provider route, hoặc kích thước prompt | Platform engineering |
| Tỷ lệ fallback | Route chính có khỏe mạnh và kinh tế không? | Điều tra tình trạng provider, capacity, hoặc route policy | Reliability engineering |
| Chi phí trên mỗi kết quả được chấp nhận | Các lần retry và kết quả chất lượng thấp có xóa sạch khoản tiết kiệm không? | Thay đổi cơ cấu model, caching, kích thước prompt, hoặc validation | Engineering và FinOps |
| Tỷ lệ đạt grounding khi retrieval | Câu trả lời có sử dụng ngữ cảnh liên quan, được phép không? | Xây dựng lại index, filters, reranker, hoặc citation validation | Search/RAG owner |
| Lỗi đối soát tool | Một tác động phụ bên ngoài có hoàn tất an toàn không? | Tạm dừng tool, đối soát trạng thái, hoặc sửa idempotency | Application owner |
| Số lần redaction thất bại | Dữ liệu nhạy cảm có đang đi tới exporter không? | Dừng export, cách ly telemetry, hoặc cập nhật policy | Security/privacy |
Bảng này ngăn chặn chế độ lỗi phổ biến khi một dashboard chứa hàng chục biểu đồ nhưng không ai biết một thay đổi thì nên kích hoạt hành động gì.
Một dạng trace thực tế
Hãy dùng một trace cho toàn bộ workflow mà người dùng nhìn thấy, không phải một trace rời rạc cho mỗi lời gọi tới provider. Nút gốc nên mô tả tác vụ của khách hàng, còn các span con mô tả những thao tác đã góp phần tạo ra kết quả.
workflow: answer_support_question
attributes: tenant_class, release, accepted_outcome, final_status
├─ retrieval.search
│ attributes: index_version, top_k, authorization_result
├─ gen_ai.attempt
│ attributes: provider, requested_model, resolved_model, attempt=1
├─ tool.lookup_order
│ attributes: tool_schema_version, idempotency_key, result
├─ gen_ai.attempt
│ attributes: provider, resolved_model, attempt=2, fallback_reason
└─ evaluation.validate_answer
attributes: evaluator_version, pass, score_band
Các quy ước ngữ nghĩa AI sinh của OpenTelemetry vẫn đang tiếp tục phát triển. Hãy xem chúng như một từ vựng chung, nhưng cố định phiên bản quy ước, ghi lại mọi phần mở rộng cục bộ, và kiểm thử các nâng cấp trong staging. Giữ các kết quả kinh doanh như accepted_outcome trong namespace ứng dụng ổn định của riêng bạn để một thay đổi ở semantic convention không làm hỏng báo cáo sản phẩm.
Giai đoạn 1: Xác định kết quả trước khi thêm dashboard
1. Đặt tên workflow và kết quả chấp nhận được
Đừng bắt đầu với các biểu đồ token trên toàn bộ provider. Hãy bắt đầu bằng một tác vụ của khách hàng như:
- câu trả lời hỗ trợ được chấp nhận mà không cần escalated;
- bản vá code vượt qua kiểm thử;
- kết quả trích xuất khớp với schema yêu cầu;
- agent hoàn thành hành động được yêu cầu mà không cần khôi phục thủ công;
- media được tạo ra vượt qua cổng rà soát sản phẩm.
Tạo một tên workflow có thể đọc bằng máy và một accepted_outcome hoặc kết quả tương đương. Điều này sẽ trở thành mẫu số cho các chỉ số chất lượng, chi phí và độ tin cậy.
2. Xác định taxonomy lỗi
Tách ít nhất các nhóm sau:
- lỗi truyền tải: timeout, lỗi kết nối, hoặc upstream 5xx;
- lỗi năng lực: rate limit, quota, queue saturation, hoặc context limit;
- lỗi hợp đồng: JSON không hợp lệ, thiếu field, không hỗ trợ schema của tool, hoặc broken stream;
- lỗi chất lượng: câu trả lời không liên quan, sai, không đầy đủ, hoặc không có grounding;
- lỗi an toàn: vi phạm chính sách, tấn công prompt injection thành công, hoặc thực thi tool không an toàn;
- lỗi kinh doanh: đầu ra hợp lệ về mặt kỹ thuật nhưng người dùng từ chối hoặc bỏ dở.
Chỉ một dimension error=true là không đủ. Nó che mất việc bạn cần cải thiện hạ tầng, thay đổi prompt, thay đổi model, hay thay đổi sản phẩm.
3. Chọn các chỉ số mức dịch vụ ban đầu
Bắt đầu với một bộ nhỏ phản ánh trải nghiệm người dùng:
workflow availability = accepted workflow completions / eligible workflow starts
quality pass rate = evaluator-passing completions / evaluated completions
p95 end-to-end latency = p95(workflow completed - workflow started)
cost per accepted outcome = total workflow cost / accepted outcomes
Giữ tính khả dụng của nhà cung cấp như một chỉ số chẩn đoán, không phải SLI của sản phẩm. Một nhà cung cấp có thể vẫn hoạt động bình thường trong khi workflow của bạn thất bại vì truy xuất, công cụ, xác thực hoặc định tuyến bị lỗi.
Giai đoạn 2: Gắn đo lường cho toàn bộ đường đi của request
4. Tạo một root span cho mỗi workflow mà người dùng nhìn thấy
Tạo root trace tại ranh giới ứng dụng, trước khi bắt đầu truy xuất hoặc định tuyến model. Truyền context đó qua các queue, worker, gateway, dịch vụ công cụ và callback.
Sử dụng child span cho:
- truy xuất và reranking;
- mỗi lần thử model;
- mỗi lần gọi công cụ;
- kiểm tra guardrail hoặc chính sách;
- phân tích và xác thực đầu ra;
- lựa chọn fallback;
- lưu trữ và phân phối downstream.
5. Ghi lại route được yêu cầu và route đã được giải quyết
Model được client chỉ định không phải lúc nào cũng là model thực sự phục vụ request. Ghi lại cả hai:
{
"ai.requested_model": "support-balanced",
"ai.resolved_provider": "provider-b",
"ai.resolved_model": "model-version-2026-07",
"ai.route_reason": "primary_rate_limited",
"ai.attempt": 2
}
Điều này là thiết yếu cho các hệ thống đa nhà cung cấp. Nó cũng khiến chiến lược fallback của model có thể kiểm toán thay vì bị ẩn đi.
6. Đo riêng streaming
Chỉ độ trễ tổng không đủ để mô tả trải nghiệm streaming. Hãy ghi nhận:
- thời lượng hàng đợi;
- độ trễ kết nối và nhà cung cấp;
- thời gian đến token đầu tiên hoặc sự kiện hữu ích đầu tiên;
- thời lượng tạo sinh;
- thời gian hoàn tất end-to-end;
- thời gian client hủy.
Một request có thể có độ trễ tổng chấp nhận được nhưng thời gian đến token đầu tiên lại kém. Nó cũng có thể tạo token đầu tiên rất nhanh rồi sau đó bị treo.
7. Xem retries và fallbacks như các lần thử hạng nhất
Không bao giờ ghi đè lần thử đầu tiên thất bại bằng lần thành công cuối cùng. Một workflow span nên chứa hoặc liên kết tới mọi lần thử tính phí, bao gồm:
- số lần retry;
- trigger;
- thời lượng backoff;
- nhà cung cấp và model;
- token và chi phí;
- trạng thái đầu ra một phần;
- kết luận cuối cùng.
Điều này ngăn một cơn bão retry trông như “thành công 100%.”
Giai đoạn 3: Thêm ngữ cảnh chất lượng đặc thù cho AI
8. Phiên bản hóa prompts, công cụ, chính sách và evaluators
Lưu các định danh ổn định thay vì chỉ nội dung thô:
prompt_version
tool_schema_version
retrieval_index_version
policy_version
evaluator_version
route_policy_version
Các chiều này cho phép bạn so sánh một bản phát hành trước và sau một thay đổi. Nếu không có versioning, việc truy nguyên nguyên nhân suy giảm chất lượng sẽ trở nên khó khăn.
9. Gắn trace cho chất lượng truy xuất
Đối với sinh tăng cường truy xuất, hãy ghi lại:
- phiên bản truy vấn và các bộ lọc;
- độ trễ truy xuất;
- document hoặc chunk ID;
- độ mới của nguồn;
- top-k và phiên bản reranker;
- tỷ lệ kết quả rỗng;
- quyết định kiểm soát truy cập;
- kết quả xác thực trích dẫn hoặc grounding.
Không đặt toàn bộ tài liệu riêng tư vào bộ lưu trữ trace đa dụng. Hãy lưu các tham chiếu được kiểm soát hoặc hash, trừ khi chính sách gỡ lỗi cho phép rõ ràng việc ghi nhận nội dung.
10. Gắn trace cho các lần gọi công cụ và side effect
Mỗi span công cụ nên bao gồm tên công cụ, phiên bản schema, quyết định cấp quyền, độ trễ, kết quả đã chuẩn hóa, và việc nó có tạo ra một tác động phụ bên ngoài hay không.
Đối với các công cụ có tác động phụ, cũng hãy ghi lại idempotency key và trạng thái đối soát. Điều này rất quan trọng khi một lần gọi mô hình bị timeout sau khi công cụ đã hoàn tất.
11. Kết hợp đánh giá online và offline
Các tín hiệu online nhanh nhưng nhiễu: thumbs-up, bỏ dở, tạo lại, sửa chữa, leo thang, hoặc hoàn thành tác vụ. Các đánh giá offline chậm hơn nhưng được kiểm soát: bộ test được tuyển chọn, bộ chấm điểm theo rubric, test thực thi được, và đánh giá của con người.
Kết nối cả hai với cùng workflow và các định danh phiên bản. Không trộn điểm từ các phiên bản evaluator khác nhau vào một đường xu hướng nếu không gắn nhãn cho sự thay đổi.
Giai đoạn 4: Kiểm soát quyền riêng tư, bảo mật và lưu giữ
12. Phân loại telemetry trước khi thu thập
Xác định ba mức:
- Siêu dữ liệu: tuyến, thời gian, token, trạng thái, phiên bản và ID.
- Tín hiệu nội dung suy diễn: độ dài, ngôn ngữ, danh mục an toàn, điểm evaluator, hoặc hash.
- Nội dung thô: prompt, phản hồi, văn bản được truy xuất, đối số công cụ, và kết quả công cụ.
Thu thập siêu dữ liệu trên diện rộng. Chỉ thu thập nội dung thô khi trường hợp sử dụng, thông báo cho người dùng, kiểm soát truy cập và chính sách lưu giữ hỗ trợ điều đó.
13. Che dữ liệu tại ranh giới thu thập
Nên che dữ liệu trước khi xuất ra bất cứ khi nào có thể. Bao gồm:
- API key, bearer token, cookie và các authorization header;
- địa chỉ email, số điện thoại, số tài khoản và mã định danh do chính phủ cấp;
- secret bên trong đối số công cụ hoặc tài liệu được truy xuất;
- URL đã ký và chuỗi kết nối cơ sở dữ liệu;
- nội dung cụ thể theo tenant bị cấm trong các kho observability dùng chung.
Sử dụng allowlist cho các thuộc tính được xuất. Một denylist cuối cùng sẽ bỏ sót một trường mới chứa bí mật. Áp dụng cùng kỷ luật được mô tả trong hướng dẫn quản lý AI API key này.
14. Thiết lập lưu giữ và quyền truy cập theo lớp dữ liệu
Nội dung thô không nên kế thừa cùng thời hạn lưu giữ như các chỉ số ít rủi ro. Xác định riêng storage, mã hóa, vai trò truy cập, audit log và quy trình xóa. Hãy kiểm thử việc xóa thay vì cho rằng chỉ một tài liệu chính sách là đủ.
NIST AI Risk Management Framework và Generative AI Profile của nó nhấn mạnh việc đo lường, tài liệu hóa và quản lý rủi ro liên tục trong suốt vòng đời hệ thống. Observability giúp cung cấp bằng chứng, nhưng việc ghi log bừa bãi có thể tạo ra một rủi ro mới về quyền riêng tư và bảo mật.
15. Kiểm soát các chiều có độ cardinality cao
Đừng biến user ID, trace ID, prompt text, document ID hoặc thông báo lỗi thô thành nhãn metric. Giữ dữ liệu có cardinality cao trong trace hoặc log, rồi suy ra các metric có giới hạn như workflow, họ mô hình, loại lỗi, môi trường và khu vực.
Giai đoạn 5: Xây dựng cảnh báo hướng tới hành động
16. Cảnh báo theo các triệu chứng ảnh hưởng đến người dùng
Tạo page khi có các triệu chứng như:
- tỷ lệ hoàn thành được chấp nhận thấp hơn mục tiêu;
- tỷ lệ đạt chất lượng giảm vượt quá guardrail của bản phát hành;
- độ trễ p95 hoặc thời gian đến token đầu tiên tiêu thụ hết error budget;
- chi phí trên mỗi kết quả được chấp nhận vượt quá giới hạn;
- tác động phụ không an toàn hoặc lỗi chính sách;
- tỷ lệ fallback tăng cao hơn dải bình thường.
Hãy dùng lỗi từ nhà cung cấp, các đợt tăng đột biến token và các lần truy xuất không tìm thấy làm cảnh báo chẩn đoán hoặc tín hiệu trên dashboard, trừ khi chúng trực tiếp đe dọa mục tiêu mà người dùng nhìn thấy.
17. Sử dụng cửa sổ burn-rate cho cảnh báo SLO
Một ngưỡng tĩnh có thể gây nhiễu. Cảnh báo burn-rate của error budget hỏi dịch vụ đang tiêu thụ ngân sách lỗi được phép nhanh đến mức nào. Hướng dẫn SRE của Google khuyến nghị kết hợp một cửa sổ nhanh với một cửa sổ xác nhận chậm hơn để các sự cố nghiêm trọng được gọi cảnh báo nhanh mà không biến mọi đợt tăng ngắn thành hành động phải xử lý.
18. Thêm chú thích cho bản phát hành và route
Mọi dashboard nên hiển thị các bản phát hành của prompt, ứng dụng, routing, model và evaluator. Thêm chú thích triển khai và so sánh các cohort canary với control. Nếu không, đội ngũ sẽ thấy một đường biểu đồ thay đổi mà không biết điều gì đã đổi.
Giai đoạn 6: Xác thực trước khi triển khai toàn diện
19. Thực hiện diễn tập sự cố
Kiểm thử ít nhất:
- timeout từ upstream;
- rate limit và cạn quota;
- đầu ra có cấu trúc bị lỗi định dạng;
- gián đoạn một phần luồng streaming;
- retrieval trả về không có ngữ cảnh được phép;
- tool thành công nhưng phản hồi bị mất;
- fallback làm thay đổi hành vi của model;
- telemetry exporter không khả dụng;
- quy tắc redaction nhận một field không xác định.
Xác nhận rằng workflow thất bại một cách an toàn, trace vẫn nhất quán, và alert chỉ đúng chủ sở hữu.
20. Triển khai theo bốn giai đoạn
- Shadow: xuất telemetry mà không thay đổi routing hoặc hành vi của người dùng.
- Canary: bật cho một phần nhỏ traffic và so sánh overhead, cardinality, và chất lượng dữ liệu.
- Guarded production: gắn các ngưỡng phát hành và quy tắc rollback.
- Full production: mở rộng sau khi các kiểm tra về quyền riêng tư, độ tin cậy và chi phí đạt yêu cầu.
OpenTelemetry hỗ trợ các mẫu head và tail sampling. Hãy giữ lại mọi lỗi và các lớp lỗi hiếm khi có thể, sau đó sample traffic thành công thông thường để kiểm soát chi phí. Các quy tắc sampling không được loại bỏ chính những trace cần để giải thích một sự cố.
Production Acceptance-Test Matrix
Các bài kiểm thử chấp nhận chứng minh rằng AI observability implementation checklist hoạt động trong các kịch bản lỗi, quyền riêng tư và mất telemetry thay vì chỉ trên các yêu cầu thành công.
Đừng tuyên bố observability đã hoàn tất chỉ vì các span xuất hiện trong trace viewer. Hãy chạy các kiểm thử có kiểm soát và lưu bằng chứng cho từng cổng phát hành.
| Kiểm thử | Điều kiện được chèn vào | Bằng chứng telemetry bắt buộc | Điều kiện đạt |
|---|---|---|---|
| Timeout upstream | Bắt tuyến mô hình chính vượt quá deadline | Span lần thử đầu tiên, lớp timeout, quyết định retry hoặc fallback, kết quả cuối cùng | Không có span mồ côi; trạng thái cuối cùng và tổng chi phí đều hiển thị |
| Giới hạn tần suất | Trả về mã 429 từ nhà cung cấp hoặc làm cạn một hạn ngạch kiểm thử | Mã gốc của nhà cung cấp, lớp dung lượng đã chuẩn hóa, thời lượng backoff, thay đổi tuyến | Ngân sách retry được giới hạn và cảnh báo trỏ đến chủ sở hữu của tuyến |
| Đầu ra có cấu trúc không hợp lệ | Trả về JSON lỗi định dạng hoặc thiếu một trường bắt buộc | Span xác thực hợp đồng, phiên bản validator, nỗ lực sửa, kết quả pass/fail cuối cùng | HTTP thành công không được tính là thành công được chấp nhận |
| Luồng bị gián đoạn | Ngắt đầu ra sau token đầu tiên | Thời gian đến token đầu tiên, cờ đầu ra một phần, mức sử dụng tính phí, quyết định retry | Ngăn chặn nội dung trùng lặp và thực thi công cụ hai lần |
| Retrieval rỗng | Trả về không có tài liệu nào được phép truy cập | Bộ lọc retrieval, kết quả xác thực quyền, lý do kết quả rỗng, chính sách trả lời | Hệ thống tuân theo hành vi không có ngữ cảnh đã được phê duyệt |
| Mơ hồ về công cụ | Để một công cụ hoàn tất trong khi yêu cầu mô hình bị timeout | Idempotency key, trạng thái side effect, kết quả đối soát | Công cụ không được thực thi hai lần và trạng thái có thể khôi phục |
| Redaction canary | Chèn một bí mật tổng hợp vào một trường kiểm thử | Sự kiện phát hiện cục bộ mà không có giá trị bí mật được xuất ra | Export bị chặn hoặc được redaction trước khi rời khỏi ranh giới |
| Exporter outage | Dừng đích telemetry | Metrics hàng đợi/drop của exporter và tình trạng ứng dụng | Lưu lượng người dùng vẫn nằm trong ngân sách độ tin cậy của nó |
| Kiểm tra sampling | Tạo các lỗi hiếm gặp giữa lưu lượng thành công cao | Trace lỗi được giữ lại; các thành công thông thường được sampling theo cấu hình | Các ví dụ sự cố vẫn có thể tìm kiếm được sau khi sampling |
| Hồi quy phát hành | Triển khai một canary với độ trễ hoặc chất lượng suy giảm đã biết | Chú thích phát hành, nhóm canary, nhóm đối chứng, so sánh SLI | Ngưỡng rollback kích hoạt với một chủ sở hữu thay đổi có thể xác định |
Đối với mỗi kiểm thử, hãy ghi lại chủ sở hữu, ngày kiểm thử, trace ID, cảnh báo kỳ vọng, cảnh báo quan sát được và ticket khắc phục. Điều này biến observability thành một kiểm soát phát hành có thể lặp lại thay vì một dự án instrumentation chỉ thực hiện một lần.
Kế hoạch triển khai bảy ngày
Đối với một nhóm tập trung, checklist triển khai AI observability có thể được triển khai như một chuỗi bảy ngày, trong đó mỗi ngày đều để lại bằng chứng có thể xem xét.
Chuỗi này được chủ đích thu hẹp. Nó cung cấp một lát cắt dọc đáng tin cậy trước khi nhóm mở rộng phạm vi bao phủ.
- Ngày 1 — Hợp đồng kết quả: chọn một workflow có giá trị cao, xác định các điểm bắt đầu đủ điều kiện, kết quả được chấp nhận, các lớp lỗi, và công thức SLI.
- Ngày 2 — Khung trace: tạo span workflow gốc và truyền context xuyên suốt application, queue, gateway, retrieval layer, và tools.
- Ngày 3 — Các lần thử model: ghi lại route được yêu cầu và route đã được phân giải, số lần thử, độ trễ, lý do kết thúc, mức sử dụng của provider, các lần retry, và các phương án fallback.
- Ngày 4 — Chất lượng và chi phí: ghép kết quả validator, các phiên bản evaluator, kết quả người dùng, và chi phí workflow đã chuẩn hóa.
- Ngày 5 — Kiểm soát quyền riêng tư: phân loại các trường, triển khai xuất dữ liệu theo allowlist, kiểm thử redaction, thiết lập thời gian lưu giữ, và xác minh ranh giới truy cập.
- Ngày 6 — SLO và dashboard: xây dựng dashboard tối thiểu, thêm chú thích release, xác định cảnh báo burn-rate, và phân công người phụ trách.
- Ngày 7 — Diễn tập sự cố: chạy ma trận chấp nhận, khắc phục các khoảng trống, bắt đầu canary, và tài liệu hóa các điều kiện rollback.
Đến cuối ngày thứ bảy, mục tiêu không phải là instrumentation toàn diện. Mục tiêu là một workflow production mà hành vi, chất lượng, độ tin cậy, an toàn, và chi phí của nó có thể được giải thích từ đầu đến cuối.
Dashboard tối thiểu cho Launch
Dashboard là góc nhìn vận hành của AI observability implementation checklist. Nó nên hiển thị trước tiên các kết quả khách hàng và thông tin hạ tầng ở phía sau.
Giữ chế độ xem vận hành đầu tiên đủ nhỏ để sử dụng trong lúc có sự cố:
- Hàng kết quả: các lượt bắt đầu đủ điều kiện, số lượt hoàn tất được chấp nhận, tỷ lệ pass chất lượng, và số lượt bỏ dở hoặc escalations.
- Hàng độ tin cậy: lỗi đã chuẩn hóa, tỷ lệ fallback, mức khuếch đại retry, và mức burn của error budget.
- Hàng độ trễ: p50/p95/p99 end-to-end, thời gian chờ trong queue, thời gian đến token đầu tiên, độ trễ retrieval, và độ trễ tool.
- Hàng kinh tế: tokens input/output/cached, tổng chi phí workflow, và chi phí cho mỗi kết quả được chấp nhận.
- Hàng thay đổi: application, prompt, route policy, model, retrieval index, tool schema, và các bản phát hành evaluator.
- Liên kết điều tra: các trace đại diện cho từng lớp lỗi, release, route, và workflow bị ảnh hưởng.
Dashboard nên hỗ trợ một lộ trình từ triệu chứng đến trace. Nếu một cảnh báo cho thấy chất lượng giảm nhưng đội ngũ không thể truy cập các trace workflow bị ảnh hưởng chỉ trong vài cú nhấp chuột, vòng lặp điều tra vẫn chưa hoàn chỉnh.
Bảng điểm đánh giá nền tảng AI Observability
Đánh giá thương mại nên kiểm tra liệu một nền tảng có hỗ trợ mô hình vận hành của bạn hay không, chứ không phải nó có danh sách tính năng dài nhất hay không. Chấm điểm các ứng viên dựa trên cùng một workload pilot đã được instrument.
| Tiêu chí | Trọng số | Những gì cần xác minh trong pilot |
|---|---|---|
| Liên kết quy trình làm việc | 20% | Một trace liên kết các lần thử model, retrieval, tools, validation và kết quả người dùng |
| Tương thích OpenTelemetry | 15% | Export/import tiêu chuẩn hoạt động; các extension cục bộ vẫn có thể truy vấn; dữ liệu có tính di động |
| Liên kết chất lượng và đánh giá | 15% | Phản hồi online và các đánh giá offline có version kết nối với các trace production |
| Quyền riêng tư và quản trị | 15% | Allowlist field, redaction, kiểm soát theo khu vực, vai trò truy cập, audit log và kiểm thử xóa |
| Vận hành độ tin cậy | 15% | SLO, cảnh báo burn-rate, kiểm soát sampling, chú thích release và hỗ trợ diễn tập sự cố |
| Phân bổ chi phí | 10% | Usage của nhà cung cấp, retries, fallbacks, token được cache và chi phí trên mỗi kết quả được chấp nhận được đối soát |
| Phạm vi bao phủ Agent/RAG/tool | 5% | Các thao tác retrieval và tool có tác động phụ có spans và bộ lọc dạng first-class |
| Chi phí vận hành | 5% | Ingestion, lưu trữ, truy vấn, lưu giữ và chi phí kỹ thuật phù hợp với khối lượng kỳ vọng |
Hãy dùng thang điểm 1–5 cho từng tiêu chí, nhân với trọng số và yêu cầu bằng chứng bằng văn bản từ pilot. Một nền tảng không thể bảo toàn telemetry contract của bạn hoặc export dữ liệu của bạn sẽ tạo ra tình trạng khóa chặt vận hành, ngay cả khi dashboard trông rất bóng bẩy.
Telemetry Contract Có Thể Sao Chép
Cách nhanh nhất để biến một AI observability implementation checklist thành thứ có thể vận hành là chuyển nó thành một telemetry contract có version. Contract này xác định mọi workflow và lần thử model phải phát ra gì, field nào là tùy chọn, giá trị nào được phép và field nào bị cấm trong các chỉ mục có lưu lượng cao.
Ví dụ dưới đây dùng một namespace nội bộ. Hãy ánh xạ nó vào các convention OpenTelemetry GenAI đã ghim trong một adapter duy nhất thay vì để mã ứng dụng phải đối mặt với các thay đổi về convention.
telemetry_contract:
version: "2026-08-04"
workflow_span:
required:
- ai.workflow.name
- ai.workflow.version
- ai.request.id
- deployment.environment
- service.version
- ai.outcome.status
- ai.outcome.accepted
- ai.latency.total_ms
optional:
- ai.tenant.tier
- ai.experiment.id
- ai.user.feedback
prohibited:
- end_user.email
- end_user.name
- raw.authorization_header
model_attempt_span:
required:
- ai.attempt.number
- ai.route.requested_model
- ai.route.resolved_provider
- ai.route.resolved_model
- ai.result.status
- ai.usage.input_tokens
- ai.usage.output_tokens
- ai.latency.first_token_ms
- ai.latency.total_ms
conditional:
- ai.fallback.reason
- ai.error.class
- ai.error.provider_code
- ai.usage.cached_input_tokens
content_capture:
default: "off"
allowed_when:
- approved_evaluation_dataset
- explicit_debug_session
controls:
- redact_before_export
- access_logged
- retention_approved
Rà soát hợp đồng này trong code review giống như một API schema. Một nhà cung cấp model mới, tool của agent, chính sách fallback, hoặc evaluator không nên được đưa lên production cho đến khi các trường telemetry của chúng ánh xạ đúng với hợp đồng và vượt qua cùng bộ acceptance tests.
Mẫu Instrumentation cho Một AI Workflow
Đừng để mỗi team tự nghĩ ra tên span và thuộc tính một cách độc lập. Hãy cung cấp một wrapper nhỏ tạo span workflow gốc, ghi lại các lần thử con, thu thập các outcome đã chuẩn hóa, và áp dụng redaction trước khi export.
Ví dụ Python này cố ý trung lập với nhà cung cấp. Các tên thuộc tính nội bộ nên được chuyển sang phiên bản semantic convention OpenTelemetry đã ghim của bạn trong lớp wrapper hoặc collector.
from opentelemetry import trace
tracer = trace.get_tracer("checkout-assistant")
def run_ai_workflow(request, router, evaluator):
with tracer.start_as_current_span("ai.workflow.checkout_help") as workflow_span:
workflow_span.set_attribute("ai.workflow.name", "checkout_help")
workflow_span.set_attribute("ai.workflow.version", "2026-08-04")
workflow_span.set_attribute("ai.request.id", request.request_id)
result = None
for attempt_number in range(1, 3):
with tracer.start_as_current_span("ai.model.attempt") as attempt_span:
route = router.resolve(request, attempt_number)
attempt_span.set_attribute("ai.attempt.number", attempt_number)
attempt_span.set_attribute("ai.route.requested_model", request.model)
attempt_span.set_attribute("ai.route.resolved_provider", route.provider)
attempt_span.set_attribute("ai.route.resolved_model", route.model)
result = route.generate(request)
attempt_span.set_attribute("ai.result.status", result.status)
attempt_span.set_attribute("ai.usage.input_tokens", result.input_tokens)
attempt_span.set_attribute("ai.usage.output_tokens", result.output_tokens)
if result.status == "ok":
break
attempt_span.set_attribute("ai.error.class", result.error_class)
evaluation = evaluator.score(request, result)
workflow_span.set_attribute("ai.outcome.status", result.status)
workflow_span.set_attribute("ai.outcome.accepted", evaluation.accepted)
workflow_span.set_attribute("ai.evaluator.version", evaluation.version)
workflow_span.set_attribute("ai.quality.score", evaluation.score)
return result
Mã production cũng nên ghi lại duration, thời gian đến token đầu tiên, lý do fallback, hủy, lỗi streaming, và ngoại lệ. Điểm thiết kế quan trọng là cấu trúc phân cấp: một workflow của khách hàng chứa một hoặc nhiều lần thử có tính billable, và workflow ghi lại outcome cuối cùng được chấp nhận.
Chính sách Alert và Runbook Phản hồi Đầu tiên
Một AI observability implementation checklist là chưa đầy đủ nếu dashboard không có quy tắc phản hồi. Mỗi metric launch cần một trigger, một owner, và một truy vấn chẩn đoán đầu tiên.
| Cảnh báo | Ví dụ kích hoạt | Câu hỏi đầu tiên | Hành động ngay lập tức |
|---|---|---|---|
| Burn của kết quả được chấp nhận | Burn error budget nhanh và chậm | Workflow, bản phát hành, route hay tenant nào đã thay đổi? | Tạm dừng rollout hoặc hoàn nguyên bản phát hành liên quan |
| Thoái lui độ trễ | Độ trễ workflow p95 vượt SLO | Độ trễ của queue, retrieval, model hay tool có thay đổi không? | Đi đường vòng quanh giai đoạn chậm hoặc giảm tải |
| Tăng đột biến fallback | Tỷ lệ fallback vượt biên độ bình thường | Nhà cung cấp chính có đang lỗi, bị throttling hay timeout không? | Kiểm tra lỗi provider đã chuẩn hóa và lỗi thô |
| Đột biến chi phí trên mỗi kết quả | Chi phí tăng trong khi tỷ lệ chấp nhận giữ nguyên hoặc giảm | Retry, độ dài output hay các route tốn kém có đang tăng không? | Giới hạn retry và khôi phục chính sách route trước đó |
| Giảm điểm chất lượng | Tỷ lệ đạt của evaluator online hoặc được lấy mẫu giảm | Prompt, retrieval, model hay phiên bản evaluator có thay đổi không? | So sánh cohort của bản phát hành với cohort khỏe mạnh gần nhất |
| Độ không chắc chắn của tool | Kết quả side-effect không thể đối chiếu | Tool đã hoàn tất trước timeout hoặc bị hủy chưa? | Dừng retry tự động và chuyển sang đối chiếu |
| Mất telemetry | Độ đầy đủ span hoặc usage kỳ vọng giảm | Instrumentation có bị hỏng hay backpressure của export đang tăng không? | Xem telemetry bị thiếu như một sự cố vận hành |
Chế độ xem on-call nên liên kết trực tiếp từ một cảnh báo đến các trace đã lọc theo workflow, bản phát hành, model được yêu cầu, route đã phân giải và lớp lỗi. Nếu người phản hồi phải tự dựng lại các bộ lọc đó trong lúc sự cố xảy ra, hệ thống vẫn chưa sẵn sàng để ra mắt.
Ownership và Bàn giao Production
Giao checklist cho các vai trò được nêu tên trước khi rollout. Quyền sở hữu chung mà không có người ra quyết định rõ ràng thường tạo ra các dashboard mà ai cũng xem được nhưng không ai duy trì.
| Trách nhiệm | Vai trò chịu trách nhiệm | Bằng chứng bàn giao bắt buộc |
|---|---|---|
| Định nghĩa kết quả workflow | Sản phẩm hoặc chủ sở hữu tính năng AI | Quy tắc kết quả được chấp nhận và ví dụ bị từ chối |
| Lược đồ span và metric | Chủ sở hữu nền tảng hoặc observability | Hợp đồng telemetry có phiên bản và các kiểm thử schema |
| Trường route và fallback | Chủ sở hữu gateway hoặc độ tin cậy | Xác thực route được yêu cầu/đã phân giải và số lần thử |
| Evaluator chất lượng | Chủ sở hữu kỹ thuật AI | Phiên bản evaluator, dataset, ngưỡng, giới hạn đã biết |
| Quyền riêng tư và lưu giữ | Chủ sở hữu bảo mật hoặc quyền riêng tư | Phân loại dữ liệu, kiểm thử redaction, phê duyệt lưu giữ |
| SLO và cảnh báo | Chủ sở hữu dịch vụ | Tài liệu SLO, quy tắc paging, dashboard, runbook |
| Phân bổ chi phí | Chủ sở hữu tài chính kỹ thuật | Tính đầy đủ usage và đối chiếu chi phí trên mỗi kết quả |
| Sẵn sàng phát hành | Lead kỹ thuật | Ma trận chấp nhận đã hoàn thành và trigger rollback |
Lên lịch rà soát sau 30 ngày kể từ khi ra mắt. Xóa các trường không dùng, đưa các truy vấn debug hữu ích lặp đi lặp lại vào các chế độ xem dashboard, xem lại cardinality và chi phí lưu trữ, và cập nhật contract khi hành vi của workflow thay đổi.
Danh sách kiểm tra triển khai AI Observability có thể sao chép
Sử dụng danh sách này như một cổng chặn trước khi ra mắt:
- [ ] Xác định từng workflow và kết quả khách hàng được chấp nhận.
- [ ] Xác định các lỗi về truyền tải, năng lực, contract, chất lượng, an toàn và business.
- [ ] Chọn các SLI về availability, chất lượng, latency và chi phí trên mỗi kết quả.
- [ ] Phê duyệt một telemetry contract có version, với các trường bắt buộc, tùy chọn và bị cấm.
- [ ] Tạo một root trace cho mỗi workflow mà người dùng có thể nhìn thấy.
- [ ] Truyền context xuyên qua hàng đợi, công cụ, retrieval và gateways.
- [ ] Ghi lại các route provider/model được yêu cầu và route đã được giải quyết.
- [ ] Tạo một span riêng cho mỗi lần retry và mỗi lần fallback.
- [ ] Ghi nhận thời gian chờ hàng đợi, thời gian đến token đầu tiên và tổng latency.
- [ ] Ghi nhận mức sử dụng token do provider báo cáo và chi phí chuẩn hóa.
- [ ] Version prompts, tools, retrieval indexes, policies, routes và evaluators.
- [ ] Ghi lại các tham chiếu retrieval, độ mới, ủy quyền và kết quả grounding.
- [ ] Ghi lại ủy quyền công cụ, idempotency, kết quả và trạng thái side effect.
- [ ] Kết nối phản hồi của người dùng và kết quả đánh giá offline vào traces.
- [ ] Phân loại telemetry thành metadata, tín hiệu dẫn xuất hoặc nội dung thô.
- [ ] Che giấu secrets và các trường nhạy cảm trước khi export.
- [ ] Áp dụng chính sách lưu giữ và truy cập riêng theo từng loại dữ liệu.
- [ ] Giữ các giá trị có cardinality cao ra khỏi nhãn metric.
- [ ] Thiết lập cảnh báo cho các SLO ảnh hưởng đến người dùng và mức tiêu hao error budget.
- [ ] Gắn chú thích cho các bản phát hành và so sánh canary với control.
- [ ] Chạy diễn tập lỗi, quyền riêng tư, sampling và sự cố ngưng hoạt động của exporter.
- [ ] Lưu bằng chứng kiểm thử chấp nhận và trace IDs cho cổng chặn phát hành.
- [ ] So sánh các nền tảng observability bằng một scorecard pilot có trọng số duy nhất.
- [ ] Chỉ định rõ người chịu trách nhiệm cho outcomes, schema, quyền riêng tư, SLO, chất lượng và chi phí.
- [ ] Liên kết mọi cảnh báo cần phản hồi ngay với một runbook và trace query cho phản ứng đầu tiên.
Các sai lầm phổ biến khi triển khai AI Observability
Ghi log prompts mà không có chính sách dữ liệu
Raw prompts có vẻ hữu ích trong quá trình debug, nhưng chúng có thể chứa dữ liệu khách hàng, secrets, tài liệu có bản quyền hoặc thông tin được quản lý. Hãy bắt đầu với metadata và chỉ bật thu thập nội dung có kiểm soát ở những nơi được biện minh rõ ràng.
Đo chi phí trên mỗi request thay vì chi phí trên mỗi kết quả
Một request rẻ nhưng thất bại khi xác thực thì không hề rẻ. Các lần retry, fallback và sửa chữa của con người đều thuộc về chi phí của workflow. Nguyên tắc tương tự cũng áp dụng cho ROI của prompt caching: tối ưu cho nhiệm vụ được chấp nhận, không phải một tốc độ token tách biệt.
Coi mọi lần gọi model là độc lập
Agents và hệ thống RAG là các workflow. Nếu các span của model, retrieval và công cụ không được liên kết, đội ngũ sẽ không thể tái dựng được quan hệ nhân quả.
Phụ thuộc vào một dashboard của provider
Dashboard của provider hữu ích cho mức sử dụng và lỗi ở upstream, nhưng chúng không nhìn thấy toàn bộ kết quả ứng dụng của bạn, hệ thống retrieval, việc thực thi công cụ, phản hồi người dùng hay đường fallback xuyên qua nhiều provider.
Gắn instrumentation cho mọi thứ trước khi xác định quyết định
Telemetry có chi phí vận hành. Mỗi trường dữ liệu nên phục vụ một quyết định về gỡ lỗi, cảnh báo, đánh giá, quản trị hoặc tối ưu hóa. Hãy loại bỏ những trường không ai sử dụng.
Where an AI Gateway Fits
Một LLM gateway có thể là một ranh giới hữu ích cho correlation và policy vì nhiều ứng dụng và nhà cung cấp đi qua một điểm kiểm soát duy nhất. Nó có thể chuẩn hóa metadata về route, attempt, usage, latency và error trước khi xuất telemetry sang observability stack của bạn.
Gateway không phải là toàn bộ giải pháp. Mã ứng dụng vẫn chịu trách nhiệm về kết quả workflow, retrieval context, semantics của tool, phản hồi của người dùng và chuyển đổi kinh doanh. Thiết kế mạnh nhất là kết hợp telemetry từ gateway với các tín hiệu ở cấp ứng dụng đó.
Flatkey cung cấp một lớp truy cập tương thích với OpenAI cho nhiều mô hình AI. Nếu đội ngũ của bạn đang hợp nhất các tích hợp với nhà cung cấp, hãy khám phá Flatkey và dùng checklist này để xác định telemetry contract xung quanh ứng dụng và lớp routing của bạn.
Frequently Asked Questions
What should I implement first for AI observability?
Bắt đầu AI observability implementation checklist với một root trace cho mỗi workflow khách hàng, các child span cho từng model-attempt, các trường model được yêu cầu và model được chọn cuối cùng, latency, usage, lỗi đã chuẩn hóa, và một tín hiệu outcome đã được chấp nhận. Thêm raw prompt capture sau, nếu chính sách quyền riêng tư của bạn cho phép.
Is OpenTelemetry enough for LLM observability?
OpenTelemetry cung cấp nền tảng trung lập về transport cho traces, metrics và logs, cùng với các semantic convention cho generative AI đang phát triển. Bạn vẫn cần định nghĩa workflow, đánh giá, kiểm soát quyền riêng tư, SLO, dashboard và quy trình xử lý sự cố.
Should prompts and responses be stored in traces?
Không mặc định. Trước hết hãy dùng metadata, phiên bản, hash và các tín hiệu chất lượng suy ra. Chỉ lưu raw content trong các hệ thống được kiểm soát, với mục đích rõ ràng, chính sách truy cập, thời hạn lưu trữ và quy trình xóa.
Which AI observability metrics matter most?
Bắt đầu với tỷ lệ completion được chấp nhận, tỷ lệ pass chất lượng, p95 end-to-end latency, time to first token đối với streaming, tỷ lệ fallback và chi phí trên mỗi outcome được chấp nhận. Thêm các metric đặc thù theo workflow sau khi những metric này đã đáng tin cậy.
How do I monitor multiple AI providers?
Sử dụng một telemetry schema ổn định cho mọi nhà cung cấp. Ghi lại cả route được yêu cầu và provider/model được chọn cuối cùng ở mỗi attempt, chuẩn hóa lỗi mà không loại bỏ mã lỗi gốc từ nhà cung cấp, và ghép tất cả các attempt dưới cùng một workflow trace.
