Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: AI Observability là khả năng tái dựng một lượt chạy AI từ đầu đến cuối bằng dữ liệu liên kết, để biết chuyện gì xảy ra, vì sao xảy ra, phiên bản dữ liệu hay công cụ nào tham gia, hệ thống tốn bao lâu và kết quả có đúng, an toàn, tạo tác động bên ngoài hay không.

Đọc xong, bạn sẽ hiểu:

  • Vì sao một bảng chỉ số chưa đủ để điều tra hệ thống AI.
  • Cách nối log, metric, trace và đánh giá chất lượng bằng cùng một mã lượt chạy.
  • Cách lập Trace Card miễn phí và xử lý một sự cố demo trong 15 phút.

1. AI Observability khác monitoring ở điểm nào?

Monitoring, hay giám sát, trả lời câu đã biết trước: lỗi có vượt ngưỡng, phản hồi có chậm, hàng đợi có dài không. Nó giống bảng đèn trên xe: báo động cơ có vấn đề nhưng chưa chỉ ra nguyên nhân.

Observability, hay khả năng quan sát và tái dựng, giúp hỏi tiếp câu chưa dự đoán lúc thiết kế. Với một đầu ra kém, đội vận hành phải lần lại chính sách, tài liệu truy xuất, phiên bản model/prompt, công cụ và bước kiểm chứng. Microsoft cũng phân biệt tín hiệu vận hành với tín hiệu AI như truy xuất, tool, chất lượng và quản trị (Microsoft Security).

Vì thế, dashboard không đồng nghĩa với observability. Dashboard là màn hình tổng hợp; observability là năng lực dùng bằng chứng để tái dựng một hành trình. Một dashboard đẹp có thể báo “độ trễ tăng”, nhưng nếu không nối được cảnh báo đó với đúng phiên bản model, kho tri thức và chính sách, ta vẫn chỉ đang đoán.

Hình 1 — Một trace xuyên suốt giúp nối nguyên nhân, phiên bản, chi phí, chất lượng và tác động của cùng một lượt chạy.

2. Hợp đồng telemetry: log, metric, trace và evaluation

Telemetry là dữ liệu hệ thống tự ghi lại khi hoạt động. Muốn các nhóm không đặt tên mỗi nơi một kiểu, cần một hợp đồng telemetry: quy ước trường nào bắt buộc, tên gọi ra sao, được giữ bao lâu và ai được xem. OpenTelemetry gọi semantic conventions là bộ tên chung cho các khái niệm và dữ liệu quan sát, giúp trace, metric, log cùng nói một ngôn ngữ (OpenTelemetry).

Bốn loại bằng chứng thường đi cùng nhau:

  • Log là bản ghi một sự kiện, chẳng hạn “retrieval trả về 4 tài liệu” hoặc “tool bị policy từ chối”.
  • Metric là số được tổng hợp theo thời gian, chẳng hạn độ trễ p95, tỷ lệ lỗi, số token hoặc tỷ lệ trích dẫn đạt.
  • Trace là toàn bộ đường đi của một yêu cầu. Mỗi công đoạn nhỏ bên trong gọi là span; ví dụ retrieve, model và verify là ba span cùng thuộc một trace.
  • Evaluation, hay đánh giá, kiểm tra đầu ra theo tiêu chí như bám nguồn, phù hợp, an toàn hoặc đúng định dạng.

Mỗi lượt chạy cần một trace_id hoặc run_id chung; mỗi span giữ parent_id để biết bước cha. Hệ thống cũng nên ghi mã phiên bản của prompt, model route, index, tool, policy và bộ đánh giá. Không nên mặc định đổ tên người dùng, nội dung nhạy cảm hay prompt thô vào log.

Hình 2 — Tín hiệu vận hành, model và chi phí, chất lượng, bảo mật chỉ hữu ích khi cùng quy về một lượt chạy.

3. Một trace cần trả lời năm câu hỏi

Đừng bắt đầu bằng câu “cần bao nhiêu dashboard?”. Hãy bắt đầu bằng năm câu hỏi mà người trực sự cố phải trả lời:

  1. Chuyện gì đã xảy ra? Yêu cầu thành công, lỗi, bị từ chối hay bị giữ lại?
  2. Vì sao xảy ra? Span nào chậm, điều kiện nào kích hoạt fallback, evaluator nào đánh trượt?
  3. Phiên bản nào tham gia? Prompt, model, dữ liệu truy xuất, tool và policy có đúng bản phát hành dự kiến không?
  4. Tốn bao lâu và bao nhiêu? Độ trễ nằm ở bước nào, số token và chi phí thuộc model hay tool nào?
  5. Kết quả có đúng và an toàn không? Có đủ bằng chứng, vi phạm chính sách, lộ dữ liệu hay tạo tác động bên ngoài không?

Năm câu hỏi này cần bốn nhóm tín hiệu. Vận hành gồm độ trễ, lỗi và hàng đợi. Model và chi phí gồm route, token, fallback và chi phí. Chất lượng gồm độ bám nguồn và evaluator. Bảo mật và quản trị gồm quyền truy cập, tool, phê duyệt và che dữ liệu.

AWS khuyến nghị một lớp trace xuyên suốt agent, model, tool và nguồn tri thức để cùng phân tích chất lượng, hiệu năng, chi phí và bảo mật (AWS Prescriptive Guidance). Điểm quan trọng không phải thu thật nhiều dữ liệu, mà là nối đúng dữ liệu cần thiết.

Hãy hình dung việc giao hàng. trace_id giống mã đơn nối kho, tài xế và người nhận; phiên bản artifact giống mã lô hàng. Thiếu một trong hai, cuộc điều tra dễ dừng ở “có vẻ là”.

4. Case OBS-23: một cảnh báo, hai nguyên nhân

Đây là tình huống demo, không phải số liệu production. Hệ thống hỏi đáp nội bộ đặt mục tiêu minh họa: độ trễ p95 không quá 6 giây và tỷ lệ câu trả lời đạt kiểm tra trích dẫn tối thiểu 90%. Sau một bản phát hành, p95 lên 7,8 giây, còn tỷ lệ đạt trích dẫn giảm từ 92% xuống 74%.

Nếu chỉ xem biểu đồ độ trễ, đội vận hành có thể đổ hết lỗi cho model. Trace mẫu TRACE-2301 kể câu chuyện đầy đủ hơn:

Span Thời lượng Artifact Bằng chứng
EDGE + POLICY 0,2 giây policy@v8 Quyền hợp lệ, không phát hiện injection
RETRIEVE 0,6 giây index@v17 Lấy 4 đoạn; production lẽ ra dùng index@v18
MODEL 5,9 giây route@v5 Model chính trả 429; fallback chạy 1/1
VERIFY 0,7 giây evaluator@v6 Chỉ 1/2 trích dẫn khớp bằng chứng
RESPONSE 0,4 giây response-policy@v4 Giữ câu trả lời, không tạo tác động ngoài

Tổng cộng là 7,8 giây. Cấu hình cũ khiến một nhóm máy đọc index@v17, làm chất lượng nguồn giảm. Lỗi giới hạn tốc độ kích hoạt fallback, làm độ trễ tăng. Sửa quota không tự nâng chất lượng; cập nhật index không tự giảm thời gian model.

Quyết định an toàn của case là answer_withheld_insufficient_evidence: hệ thống giữ câu trả lời vì chỉ xác nhận được 1/2 trích dẫn. Số thao tác bên ngoài là 0. Đội vận hành đưa toàn bộ máy về index@v18, điều chỉnh backpressure để giảm yêu cầu dồn vào model chính, rồi chạy lại bộ đánh giá trước khi mở hoàn toàn.

Hình 3 — OBS-23 tách lỗi chất lượng do index cũ khỏi lỗi độ trễ do model chính bị giới hạn tốc độ.

“Model chậm nên mọi thứ hỏng” là phỏng đoán. “MODEL chiếm 5,9/7,8 giây sau lỗi 429; RETRIEVE dùng sai index@v17; VERIFY đạt 1/2 trích dẫn” là kết luận có bằng chứng và có chỗ để nhận sai.

5. Sai lầm, giới hạn và checklist áp dụng

Sai lầm thứ nhất là ghi mọi thứ để phòng khi cần. Prompt thô, tài liệu riêng tư hay mã truy cập có thể biến log thành kho rủi ro. Microsoft yêu cầu telemetry AI đi cùng giảm thiểu dữ liệu, kiểm soát truy cập và thời hạn lưu phù hợp (Microsoft Foundry). Ưu tiên ID, hash hoặc metadata đủ điều tra.

Sai lầm thứ hai là chỉ đo uptime và độ trễ: hệ thống vẫn có thể trả lời nhanh nhưng sai nguồn hoặc vượt quyền. Sai lầm thứ ba là cảnh báo không gắn owner, runbook và trace mẫu.

Observability có giới hạn. Trace cho thấy hệ thống đã làm gì, không tự chứng minh đầu ra đúng. Evaluator có thể sai; span bị thiếu có thể làm kết luận lệch. Quyết định quan trọng vẫn cần kiểm thử, chuyên gia và phê duyệt.

Checklist triển khai theo thứ tự:

  1. Chọn 3-5 hành trình quan trọng.
  2. Định nghĩa trạng thái cuối hợp lệ và tác động bên ngoài được phép cho từng hành trình.
  3. Chuẩn hóa trace_id, span_id, parent_id, thời lượng, trạng thái và artifact version.
  4. Thêm bốn nhóm tín hiệu: vận hành, model/chi phí, chất lượng, bảo mật/quản trị.
  5. Đặt ngưỡng từ baseline, ghi owner và runbook.
  6. Lấy một trace thật, thử trả lời đủ năm câu hỏi và ghi phần chưa thể kết luận.
  7. Kiểm tra che dữ liệu, phân quyền và thời hạn lưu trước khi tăng độ chi tiết.

Đứng ngoài nếu chưa rõ dữ liệu nào được phép ghi hoặc chưa có người xử lý cảnh báo. Dừng và xem lại khi trace thiếu bước, version lệch, evaluator chưa được kiểm định hoặc dữ liệu nhạy cảm xuất hiện.

6. Bắt đầu từ đâu: lập Trace Card trong 15 phút

Dùng Google Sheets miễn phí, tạo hai bảng bằng dữ liệu giả; chưa nối production và chưa dùng dữ liệu thật.

a. Mẫu đối chiếu Trace Card

Span Parent Start Duration Input version Output version Status Cost Quality Security Evidence
EDGE ROOT 10:00:00.0 0,1s request@demo request@clean OK 0 n/a ACL pass log-01
RETRIEVE POLICY 10:00:00.2 0,6s index@v17 docs@4 WARN 0 stale version clean log-03
MODEL RETRIEVE 10:00:00.8 5,9s route@v5 answer@draft WARN 0,03 pending fallback 1/1 log-04
VERIFY MODEL 10:00:06.7 0,7s evaluator@v6 score@1/2 FAIL 0,01 citation fail clean eval-01
RESPONSE VERIFY 10:00:07.4 0,4s policy@v4 withheld SAFE 0 withheld actions 0 log-06

Bảng hai ghi cảnh báo, baseline, trace, nguyên nhân, owner, cách sửa và phép kiểm tra lại. Mẫu: p95 7,8s > 6s; độ trễ do fallback sau 429; chất lượng do index@v17; owner là Platform và Knowledge; kiểm tra bằng 20 yêu cầu demo trên index@v18, citation pass tối thiểu 90%, thao tác ngoài bằng 0.

Sau 15 phút, hãy chỉ ra span chậm nhất, phiên bản lệch, quyết định an toàn và bằng chứng. Tô đỏ ô chưa trả lời được; đó là backlog telemetry tiếp theo.

7. Tổng kết

a. Năm ý chính

  • Monitoring báo điều đã biết; observability giúp tái dựng và hỏi tiếp điều chưa biết.
  • Log, metric, trace và evaluation phải nối bằng cùng trace_id và phiên bản artifact.
  • Một trace tốt trả lời chuyện gì, vì sao, phiên bản nào, tốn bao nhiêu, đúng và an toàn không.
  • OBS-23 tách được lỗi index cũ khỏi lỗi model fallback thay vì gom thành một phỏng đoán.
  • Thu thập tối thiểu, che dữ liệu, phân quyền và kiểm định evaluator là phần của thiết kế.

b. Câu hỏi tự kiểm tra

  • Vì sao có dashboard chưa có nghĩa là hệ thống đã có observability?
  • trace_id và artifact version giải quyết hai việc khác nhau nào?
  • Trong OBS-23, vì sao sửa quota chưa đủ để phục hồi chất lượng?
  • Khi nào cần dừng tăng mức ghi log?

c. Gợi ý đáp án

Xem gợi ý câu 1

Dashboard tổng hợp chỉ số nhưng có thể không tái dựng được một lượt chạy cụ thể. Xem mục 1.

Xem gợi ý câu 2

trace_id nối các bước của một lượt chạy; artifact version xác định chính xác dữ liệu, model, prompt hay policy đã tham gia. Xem mục 2-3.

Xem gợi ý câu 3

Quota và fallback gây chậm, còn index cũ làm bằng chứng truy xuất kém. Hai nguyên nhân cần hai cách sửa. Xem mục 4.

Xem gợi ý câu 4

Dừng khi chưa rõ quyền thu thập, dữ liệu nhạy cảm lọt vào log hoặc chưa có chính sách giữ và xóa. Xem mục 5.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Monitoring Giám sát các chỉ số và điều kiện đã định nghĩa trước
Observability Khả năng tái dựng hành vi hệ thống từ bằng chứng liên kết
Telemetry Dữ liệu hệ thống tự ghi khi hoạt động
Log Bản ghi về một sự kiện cụ thể
Metric Số đo được tổng hợp theo thời gian
Trace Toàn bộ đường đi của một yêu cầu
Span Một công đoạn riêng bên trong trace
Evaluation Phép đánh giá đầu ra theo tiêu chí
Artifact version Mã phiên bản của dữ liệu, prompt, model, tool hoặc policy

e. Nguồn tham khảo

Điều hướng: Ôn lại AI Infrastructure gồm những gì? #22 để hiểu lớp vận hành bên dưới. Bài tiếp theo là AI Security: Bảo mật hệ thống AI #24.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.