LLM observability giúp theo dõi ứng dụng sử dụng mô hình ngôn ngữ qua các yếu tố như trace, log, metric, phiên bản prompt, nguồn truy xuất, lỗi và độ trễ. Nó hỗ trợ việc xác định nguyên nhân sự cố. Để đánh giá chất lượng, cần kết hợp telemetry với eval và phản hồi từ người dùng. Trace giúp liên kết lỗi ở từng bước của một request.
Nội dung chính
LLM observability là gì?
Trace, span, log và metric
Thuộc tính cần theo dõi trong ứng dụng LLM
Bảng chỉ số và câu hỏi vận hành
Ví dụ trace cho chatbot RAG
Thiết kế instrumentation an toàn
Observability và đánh giá chất lượng
Câu hỏi thường gặp
LLM observability là gì?
Observability là khả năng hiểu trạng thái bên trong hệ thống từ tín hiệu mà hệ thống phát ra. OpenTelemetry mô tả các tín hiệu phổ biến gồm trace, metric và log. Với ứng dụng LLM, mỗi lần gọi model thường nằm trong một chuỗi bước: nhận request, lấy dữ liệu, dựng prompt, gọi model, parse kết quả, gọi công cụ và trả lời. Nếu chỉ lưu câu trả lời cuối, đội vận hành khó biết bước nào gây ra lỗi. LLM observability mở rộng telemetry vận hành bằng ngữ cảnh liên quan tới model và pipeline: tên/version model, phiên bản prompt, thời gian từng bước, lỗi provider, mức token, nguồn retrieval, kết quả tool và trạng thái kiểm tra đầu ra. Những thuộc tính giúp phân biệt “model chậm” với “retriever trả quá nhiều context” hoặc “tool timeout”. Cách instrument cụ thể tùy kiến trúc; nên dùng schema ổn định và hạn chế lưu nội dung nhạy cảm. Observability không đồng nghĩa với một dashboard hoặc một sản phẩm trả phí. Đó là khả năng đặt câu hỏi mới từ telemetry đã thiết kế. Một dashboard có hàng chục biểu đồ vẫn thiếu observability nếu không liên kết request, phiên bản và lỗi. Ngược lại, trace có cấu trúc, vài metric phù hợp và log được bảo vệ có thể đủ để giải quyết nhiều sự cố.
Trace, span, log và metric
Trace: Đường đi của một request qua các dịch vụ và thao tác. Trace ID giúp nhóm log và bước cùng một lần xử lý.
Span: Một đơn vị công việc trong trace, có thời gian bắt đầu/kết thúc, trạng thái và thuộc tính; ví dụ “retrieval”, “model call” hay “tool execution”.
Log: Thông điệp theo thời gian ghi một sự kiện hoặc lỗi. Log hữu ích hơn khi gắn trace/span ID để xem trong đúng ngữ cảnh.
Metric: Số đo tổng hợp qua thời gian như request/giây, tỷ lệ lỗi, p95 latency hoặc token/request. Metric giúp nhìn xu hướng, nhưng không tự cho biết nội dung cụ thể gây lỗi.
Event: Sự kiện có thời điểm trong span, như retry hoặc bước fallback; dùng khi cần chỉ ra việc xảy ra trong một hoạt động.
Đừng để trace chứa toàn bộ cuộc hội thoại theo mặc định. Thay vào đó ghi kích thước context, ID nguồn đã phân quyền, checksum/version hoặc thuộc tính đủ để tái hiện vấn đề khi được phép. Nếu nội dung prompt phải lưu để debug, áp dụng redaction, encryption, access control, retention và quy trình xóa tương ứng.
Thuộc tính cần theo dõi trong ứng dụng LLM
- Request: trace ID, loại tác vụ, môi trường, thời điểm, tenant/account đã giả danh và phiên bản ứng dụng.
- Model invocation: nhà cung cấp, model ID/version nếu có, timeout, status, retry, input/output token hoặc đơn vị mà provider trả.
- Prompt: template ID/version, loại message, kích thước, cache hit nếu sử dụng; nội dung thô chỉ khi có nhu cầu và được phép.
- Retrieval: query ID, kho/index và phiên bản, số tài liệu lấy, score range, thời gian, trạng thái ACL; tránh ghi đầy đủ nội dung tài liệu nhạy cảm.
- Tool: tên tool, validation result, quyền được cấp, thời gian thực hiện, mã lỗi và có cần approval hay không.
- Output: parse/schema status, policy check, citation check, độ dài và feedback; đừng suy ra chất lượng chỉ từ độ tự tin do model tự báo.
- Cost/latency: token hoặc chi phí provider trả, thời gian từng span, thời gian end-to-end và số lần retry.
Tránh đưa giá trị duy nhất cho mỗi user, prompt hoặc tài liệu thành nhãn metric vì điều đó tạo cardinality rất cao và có thể lộ thông tin. Dùng ID đã giả danh trong trace hoặc log có kiểm soát; tổng hợp metric theo model, tác vụ, phiên bản và trạng thái. Tách dữ liệu vận hành khỏi dữ liệu ứng dụng để khi cần xóa hoặc giữ riêng tư dễ dàng xử lý.