Hồ sơ điều tra cho endpoint LLM

Hồ sơ điều tra cho endpoint LLM

Triển khai LLM không chỉ là nhìn GPU và latency. Playbook này giúp team builder quyết định cần đo gì trước khi endpoint bắt đầu nói sai rất tự tin.

Có một cảnh mình thấy hơi quen ở team làm AI: endpoint vừa lên production, dashboard xanh mướt, GPU còn thở được, latency nhìn không quá xấu. Cả nhóm thở phào. Rồi sáng thứ Hai, sales báo chatbot trả lời sai policy hoàn tiền cho khách VIP.

Không có crash. Không có error 500. Không có alarm đỏ. Chỉ có một câu trả lời sai, trôi qua hệ thống như dấu chân nhẹ trên nền nhà mới lau.

Đây là tín hiệu thị trường đáng để ý: các cloud provider đang bắt đầu nói nhiều hơn về LLM observability — quan sát hệ thống LLM không chỉ ở hạ tầng, mà cả chất lượng câu trả lời. AWS viết khá rõ về hướng này với SageMaker AI Inference: theo dõi GPU utilization, latency, token usage là chưa đủ; phải thêm quality monitoring để phát hiện drift, degradation, compliance issue.

Luận điểm của mình: khi triển khai LLM, dashboard hạ tầng chỉ cho bạn biết “máy còn chạy”; nó không cho biết “model còn đáng tin”. Sau bài này, bạn nên đổi cách nghĩ từ “monitor endpoint” sang “lập hồ sơ điều tra cho từng loại lỗi production”.

Tín hiệu lạ: observability đang chuyển từ SRE sang AI governance

Trước đây, khi deploy backend, bạn nhìn mấy thứ kinh điển: latency, throughput, error rate, CPU, memory. Với LLM inference, nhóm chỉ số đó vẫn cần, nhưng không còn đủ.

Vì sao? LLM không trả về output deterministic — tức không phải cùng input lúc nào cũng ra cùng output theo kiểu hàm truyền thống. Nó sinh câu chữ tự do, có thể đúng, gần đúng, sai nhẹ, sai nặng, hoặc sai nhưng nghe rất thuyết phục.

AWS tách bài toán thành hai lớp:

Điểm đáng chú ý không nằm ở việc SageMaker có thêm vài dashboard. Tín hiệu thị trường là: nhà cung cấp hạ tầng đang phải bán thêm niềm tin vận hành, không chỉ bán compute. Khi LLM đi vào production, câu hỏi của khách hàng không còn là “chạy được không?” mà là “khi nó bắt đầu lệch, tôi biết bằng cách nào?”.

Ai hưởng lợi? Cloud platform, tool observability, team MLOps. Ai bị ép đổi cách làm? Các team builder vẫn đang deploy LLM như một REST API bình thường.

Checklist hiện trường: đừng đo mọi thứ ngay từ ngày đầu

Nói thẳng ra thì, nhiều team thất bại không phải vì thiếu metric, mà vì metric nào cũng đo nhưng không biết quyết định gì từ nó.

Nếu bạn là tech lead cho một team Việt Nam khoảng vài người, đang chuẩn bị đưa LLM endpoint lên staging hoặc production, mình sẽ bắt đầu bằng checklist này:

Nhóm hạ tầng cần có trước:

Nhóm chất lượng nên thêm ngay sau đó:

Ví dụ cụ thể: giả sử team bạn triển khai chatbot hỗ trợ khách hàng cho một sàn thương mại điện tử nhỏ. Endpoint chạy ổn, nhưng sau chiến dịch sale, khách hỏi nhiều về đổi trả theo combo. Nếu bạn chỉ nhìn latency, mọi thứ vẫn đẹp. Nếu có sampling và evaluation theo nhóm intent “đổi trả”, bạn sẽ thấy model bắt đầu trả lời lẫn giữa chính sách hàng thường và hàng khuyến mãi.

Đó là dấu vân tay của lỗi chất lượng, không phải lỗi hạ tầng.

Playbook một buổi: dựng lớp quan sát tối thiểu

Mục tiêu ở đây không phải xây observability platform hoành tráng. Mục tiêu là có đủ tín hiệu để trả lời ba câu hỏi:

  1. Endpoint có đang nghẽn không?
  2. Chi phí có đang trôi khỏi dự kiến không?
  3. Output có đang xuống chất lượng không?

Bước 1: Gắn request ID xuyên suốt

Mỗi request cần có một request_id đi từ API gateway, inference endpoint, tool gọi ngoài, đến log response. Không có request ID thì lúc sự cố xảy ra, bạn giống người đi tìm manh mối trong căn phòng đã bị dọn sạch.

Log tối thiểu:

{
  "request_id": "req_abc123",
  "user_segment": "paid_customer",
  "model": "your-llm-name",
  "input_tokens": 842,
  "output_tokens": 311,
  "latency_ms": 1840,
  "status": "success",
  "route": "refund_policy"
}

Không cần log toàn bộ nội dung nhạy cảm. Với production thật, hãy mask PII — thông tin định danh cá nhân — trước khi lưu.

Bước 2: Tách dashboard quantity và quality

Đừng nhét mọi thứ vào một màn hình. Dashboard hạ tầng phục vụ SRE: latency, error, GPU, throughput. Dashboard chất lượng phục vụ product/AI engineer: score theo intent, tỷ lệ fail policy, nhóm câu hỏi bị giảm chất lượng.

Quy tắc đơn giản: metric nào dẫn tới hành động giống nhau thì đặt cùng nhau.

Bước 3: Sampling có chủ đích, không random cho vui

Random sampling tốt để nhìn tổng quan, nhưng LLM production cần sampling theo rủi ro.

Ưu tiên lấy mẫu các nhóm:

Nếu nguồn lực ít, bắt đầu bằng 2 nhóm: intent nhạy cảm và request có feedback xấu. Đừng cố chấm mọi thứ rồi kiệt sức sau một tuần.

Bước 4: Đặt threshold theo hành động, không theo cảm giác

Threshold — ngưỡng cảnh báo — chỉ có giá trị nếu đi kèm hành động. “Quality giảm” là câu mơ hồ. “Intent refund có tỷ lệ fail policy tăng rõ rệt sau deploy prompt mới, rollback prompt” thì dùng được.

Một khung đơn giản:

| Tín hiệu | Câu hỏi cần trả lời | Hành động có thể làm |
|---|---|---|
| Latency tăng | Nghẽn ở compute hay token? | Giảm max tokens, chỉnh concurrency, scale endpoint |
| GPU memory căng | Model/config có quá nặng? | Kiểm tra batch size, quantization, instance type |
| Output dài bất thường | Prompt có đang mở van quá rộng? | Siết instruction, giới hạn format |
| Quality giảm theo intent | Lỗi do dữ liệu, prompt hay model? | Review mẫu, cập nhật eval set, rollback nếu cần |
| Compliance fail | Có rủi ro vận hành không? | Chặn response, escalation, sửa policy guardrail |

Hai bẫy builder hay dính

Bẫy thứ nhất: đồng nhất healthy endpoint với good answer. Một endpoint có thể xanh toàn bộ mà vẫn trả lời sai. Đây là kiểu lỗi khó chịu nhất vì dashboard truyền thống không la lên.

Bẫy thứ hai: dùng model-as-judge như phán quyết cuối cùng. Model-as-judge — dùng một model khác để chấm output — có ích khi cần scale evaluation, nhưng nó cũng có bias và blind spot. Với các case nhạy cảm, hãy giữ một phần human review hoặc rule-based check. Không phải vì con người hoàn hảo, mà vì bạn cần một lớp đối chứng khác.

Còn một bẫy nhỏ nhưng đau ví: chỉ nhìn request count mà quên token consumption. Hai request nhìn như nhau ở API level có thể khác nhau rất xa về chi phí nếu một request kéo context dài và sinh output lê thê.

Nếu là mình, mình sẽ triển khai theo thứ tự này

Với team đang build thật, mình không khuyên nhảy ngay vào full observability stack. Thứ tự thực dụng hơn:

  1. Tuần đầu: log request ID, latency, error, input/output tokens, model version, prompt version.
  2. Tuần hai: dashboard hạ tầng riêng, alert cho latency/error/GPU memory/token spike.
  3. Tuần ba: sampling theo intent rủi ro và feedback xấu.
  4. Tuần bốn: evaluation set nhỏ nhưng sống, cập nhật từ lỗi thật ngoài production.
  5. Sau đó: so sánh model/prompt/config dựa trên tam giác cost, latency, quality.

Điểm cần nghĩ khác sau bài này: observability cho LLM không phải camera an ninh gắn ở cửa server; nó là hồ sơ điều tra nối hạ tầng, chi phí và chất lượng câu trả lời vào cùng một vụ án.

Deploy LLM mà chỉ nhìn GPU thì giống điều tra hiện trường nhưng chỉ đếm số bóng đèn còn sáng — có ích, nhưng thủ phạm thường để lại dấu ở chỗ khác.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo