Bài 8 — Vận hành, đặt ngân sách & giữ chất lượng khi tối ưu

Tối ưu không phải việc làm một lần rồi quên. Traffic đổi, prompt đổi, model đổi giá — nếu không có vận hành kỷ luật, chi phí sẽ bò lên lại và chất lượng có thể tụt âm thầm. Bài cuối này về giữ thành quả.

Ba trụ cột vận hành

• Ngân sách & guardrail chi phí — chặn chi tiêu vượt tầm.
• Cổng chất lượng (eval) — đảm bảo cắt chi phí không làm hỏng câu trả lời.
• Cảnh báo & phản ứng — phát hiện và xử lý drift nhanh.

1) Guardrail chi phí

Đặt trần cứng, đừng chờ hóa đơn cuối tháng:

def guard(user_id, trace_id):
    if daily_spend(user_id) > USER_DAILY_CAP:
        raise BudgetExceeded            # từ chối/hạ tầng
    if tokens_in_session(trace_id) > SESSION_TOKEN_CAP:
        force_summarize_or_stop()       # chống lặp vòng đốt tiền

Các guardrail thiết yếu: trần token/phiên (chống agent lặp vô hạn), trần chi tiêu/người dùng/ngày, trần số bước agent, và trần đồng thời (chống bùng rate limit).

2) Cổng chất lượng (eval offline)

Mỗi thay đổi tối ưu phải qua một bộ eval trước khi lên production:

• Xây tập vàng (golden set) 50–200 ca đại diện, có đáp án/tiêu chí đúng.
• Chấm tự động: khớp chính xác (cho trích xuất/phân loại) hoặc LLM-as-judge (cho câu trả lời tự do), kèm vài ca người rà.
• So baseline vs biến thể: chỉ merge nếu chất lượng ≥ ngưỡng và rẻ/nhanh hơn.
• Chặn merge nếu chất lượng tụt quá ngưỡng cho phép (ví dụ >2%).

res_base = run_eval(golden, config="baseline")
res_new  = run_eval(golden, config="routing_v2")
assert res_new.quality >= res_base.quality - 0.02  # cổng
assert res_new.cost    <  res_base.cost            # phải rẻ hơn

3) Cảnh báo drift

Các cảnh báo nên có (dựng trên metric Bài 2):

• Cost/1.000 phiên tăng >20% tuần → điều tra.
• Cache hit rate rơi đột ngột → có thể prompt đổi phá prefix cache.
• p95 latency vượt SLA.
• Tỉ lệ output rỗng/parser-fail tăng → downgrade làm hỏng định dạng.
• Traffic tầng lớn tăng bất thường → router lệch hoặc escalation quá nhiều.

Khung tư duy: "Rẻ hơn nhưng không tệ hơn"

Mọi thay đổi tối ưu phải trả lời được cả hai: (1) nó tiết kiệm bao nhiêu? (2) chất lượng có tụt không? Thiếu vế (2), bạn đang đánh đổi mù. Chỉ giữ thay đổi khi rẻ hơn VÀ chất lượng trong ngưỡng.

Checklist vận hành hằng tuần

• [ ] Xem dashboard cost/use-case: có use-case nào bò lên?
• [ ] Cache hit rate còn ổn định?
• [ ] p95/p99 latency trong SLA?
• [ ] Tỉ lệ mỗi tầng model hợp lý (không dồn lên tầng lớn)?
• [ ] Eval golden set còn xanh sau các thay đổi prompt/model?
• [ ] Guardrail đã chặn được ca bất thường nào chưa (kiểm log)?
• [ ] Giá nhà cung cấp có đổi không (đổi thì tính lại routing)?

Quy trình thay đổi an toàn

• Đề xuất thay đổi (đổi tầng, nén thêm, ngưỡng cache mới).
• Chạy eval offline trên golden set.
• Canary 5–10% traffic, theo dõi chất lượng + cost thực tế.
• Mở rộng dần nếu ổn; rollback tức thì nếu cảnh báo bật.

Sai lầm thường gặp

• Tối ưu một lần rồi bỏ mặc → chi phí bò lại sau vài tháng.
• Không có golden set → không phát hiện chất lượng tụt cho tới khi khách phàn nàn.
• Guardrail chỉ ở mức ngày/tháng, thiếu trần token/phiên → một agent lặp vòng đốt sạch ngân sách trong vài phút.
• Deploy thẳng không canary → thay đổi tối ưu gây sự cố diện rộng.
• Chỉ eval bằng LLM-judge, không có ca người rà → judge thiên lệch mà không ai biết.

Kết thúc khóa: bạn có vòng lặp hoàn chỉnh — đo, tối ưu bằng caching/routing/nén/batching, và vận hành để giữ cả chi phí lẫn chất lượng ổn định lâu dài.