Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
Người dùng báo trợ lý trả lời sai, dashboard lại cho thấy tất cả request đều thành công. HTTP 200 chỉ chứng minh máy chủ trả phản hồi. Nó không cho biết tài liệu đúng có được tìm thấy, mô hình có dùng đúng tài liệu, hay công cụ đã hoàn thành hành động yêu cầu.
Tiên quyết: hiểu log, metric, trace và RAG. Ví dụ trong bài là một hệ thống hỏi đáp tài liệu giả; các trường và ngưỡng là thiết kế minh họa, không phải chuẩn bắt buộc.
Một request cần một câu chuyện có thể nối lại
Gán trace_id cho yêu cầu, rồi tạo span cho truy xuất, gọi mô hình, dùng công cụ và xác minh. Mỗi span có thời gian bắt đầu/kết thúc, trạng thái, mã lỗi và phiên bản thành phần. Các bước chạy lại cần liên kết với cùng tác vụ để không bị nhìn thành nhiều người dùng độc lập.
OpenTelemetry GenAI Semantic Conventions cung cấp quy ước cho spans, metrics và events liên quan hệ sinh AI. Dùng quy ước chung giúp ghép dữ liệu từ nhiều thành phần; vẫn phải kiểm tra phiên bản tài liệu khi triển khai vì các tên và phạm vi có thể thay đổi.
Một trace minh họa có thể trông như sau:
request r42
retrieve: index=v7, results=5, duration=120ms
generate: prompt=v4, model=version_a, output_tokens=310
verify: supported_claims=3, unsupported_claims=1
respond: outcome=needs_reviewNhững con số này chỉ phục vụ cách đọc trace. Điểm quan trọng là kết quả nghiệp vụ needs_review khác với việc các request kỹ thuật đều chạy thành công.
Metric dùng để phát hiện; trace dùng để điều tra
Metric trả lời câu hỏi “có bao nhiêu yêu cầu đang có vấn đề?”. Theo dõi tỷ lệ công cụ thất bại, thời gian đến token đầu, thời gian hoàn tất, tổng token và tỷ lệ đầu ra qua được bước kiểm tra. Chia theo phiên bản phát hành và loại nhiệm vụ có ý nghĩa hơn một số trung bình toàn hệ thống.
Trace giúp tìm lý do: truy xuất không có kết quả, mô hình chờ lâu, công cụ retry nhiều hay bộ kiểm tra từ chối. Một hệ thống có độ trễ trung bình tốt vẫn có thể khiến một nhóm người dùng chờ rất lâu; xem phân vị và nhóm nhiệm vụ trước khi tối ưu.
Chạy các mô hình trên cùng bộ thử, đọc cả điểm tổng lẫn kiểu lỗi, rồi cân nhắc tốc độ và chi phí. Một chênh lệch nhỏ chưa chứng minh mô hình nào luôn tốt hơn.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Cùng bộ thử
Dùng cùng các trường hợp và quy tắc chấm đã xác định trước cho cả hai mô hình.
02 / Đọc điểm số
Trong ví dụ giả định, A đúng 18/20, B đúng 17/20. Chênh lệch một trường hợp chưa đủ kết luận chung.
03 / Xem kiểu lỗi
Mở các trường hợp thất bại: sai tên người và vượt độ dài có mức ảnh hưởng khác nhau.
04 / Đánh giá nhiều chiều
Đo thêm tốc độ, chi phí và độ ổn định trên dữ liệu phù hợp với công việc thực tế.
A đúng 18/20 và B đúng 17/20 là số liệu giả định để giải thích cách đọc kết quả, không phải benchmark của mô hình có thật.
Sơ đồ minh họa các chiều đánh giá. Quan sát vận hành bổ sung thời gian và ngữ cảnh từng yêu cầu; nó không thay thế bộ thử có đáp án hoặc đánh giá chất lượng định kỳ.
Ghi đủ bằng chứng mà không thu gom mọi nội dung
Lưu toàn bộ prompt và tài liệu làm debug thuận tiện nhưng tăng rủi ro dữ liệu và chi phí. Mặc định lưu định danh nguồn, hash, số lượng và kết quả kiểm tra; chỉ lưu nội dung được phép theo chính sách rõ ràng. Cần thời hạn lưu, phân quyền người xem và cơ chế xóa tương ứng.
Không dùng user_id hoặc toàn bộ câu hỏi làm nhãn metric. Số giá trị nhãn lớn có thể làm kho metric phình nhanh; những chi tiết đó phù hợp với trace được bảo vệ hơn. Cũng tránh ghi khóa API, token phiên và dữ liệu bí mật vào mã lỗi tùy biến.
Sampling giảm chi phí nhưng có thể bỏ mất lỗi hiếm. Có thể giữ toàn bộ trace lỗi hoặc chậm và lấy mẫu nhóm thành công, đồng thời ghi rõ chính sách lấy mẫu. Dashboard xây từ mẫu không đồng đều cần được diễn giải đúng, tránh coi tỷ lệ trong log là tỷ lệ toàn bộ lưu lượng.
Diễn tập một cuộc điều tra nhỏ
Bài tập: tạo ba lỗi có chủ đích trong môi trường của bạn: chỉ mục cũ, công cụ timeout và câu trả lời có một kết luận không được nguồn hỗ trợ. Từ mỗi báo cáo người dùng, tìm đúng trace rồi xác định lớp gây lỗi mà không mở toàn bộ dữ liệu nhạy cảm.
Tự kiểm: nối được request tới phiên bản prompt và nguồn; phân biệt lỗi kỹ thuật với lỗi chất lượng; tính được chi phí của retry; biết trường nào bị che và vì sao. Sau đó đọc drift sau triển khai để biến tín hiệu quan sát thành hành động bảo trì có căn cứ.