Test AI routing bằng ca trực, không bằng user

Khi premium model là tài nguyên chung, A/B test theo user có thể làm sai kết luận. Đây là playbook nhỏ để thử AI routing mà không tự phá hiện trường.

Bụi Wire

2026-07-02

Có một kiểu họp release rất quen ở team AI: offline eval xanh lè, demo chạy mượt, mọi người bắt đầu hỏi “bao giờ bật production?”. Rồi một bạn platform ngồi cuối bàn giơ tay: nếu bật cho một nhóm user, nhóm còn lại có bị thiếu capacity không?

Cả phòng im một nhịp.

Đây không phải câu hỏi bi quan. Đây là câu hỏi của người từng phải trực hệ thống lúc 11 giờ đêm.

Luận điểm của mình hôm nay rất gọn: với các feature AI dùng chung tài nguyên inference, đừng mặc định A/B test theo user là công bằng. Đôi khi cách test đúng là randomize theo thời gian, không phải theo người dùng.

Sau bài này, điều bạn nên nghĩ khác là: experiment design không chỉ là đo conversion hay task success. Với LLM platform, nó còn là cách bạn bảo vệ equilibrium — trạng thái cân bằng tài nguyên giữa các nhóm user — để không tự tạo ra kết quả sai rồi tưởng feature thắng thật.

Sơ đồ minh họa cho bài Test AI routing bằng ca trực, không bằng user

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: đo feature, không đo cảnh chen tài nguyên

Giả sử team bạn vừa làm intelligent routing — lớp quyết định request nào đi model tiêu chuẩn, request nào được đẩy sang premium model. Offline evaluation cho thấy completion rate tăng 6 điểm phần trăm. Con số này có trong kịch bản nguồn chính, và đủ hấp dẫn để ai cũng muốn bật thử.

Vấn đề nằm ở premium capacity. Nếu treatment group được routing thông minh, họ có thể dùng premium model sớm hơn, nhiều hơn, đúng lúc hơn. Control group không chỉ thiếu feature; họ còn đang sống trong môi trường tài nguyên đã bị treatment group làm thay đổi.

Đây là lúc hiện trường bị xáo trộn. Bạn tưởng mình đang so sánh “có routing” với “không routing”, nhưng thật ra đang so sánh “có routing và được ưu tiên chạm premium capacity” với “không routing và có thể bị hụt capacity”. Kết quả bị confounded — nhiễu nhân quả, nghĩa là effect bạn đo bị trộn với yếu tố khác.

Switchback experiment là thiết kế thử nghiệm randomize theo time slot: toàn hệ thống bật feature trong một khoảng thời gian, rồi tắt trong khoảng tiếp theo, lặp lại đủ nhiều phiên. Thay vì chia user thành hai nhóm, bạn chia thời gian vận hành thành các ca.

Nói thẳng ra thì: nếu tài nguyên là hồ chung, đừng chia người đứng quanh hồ rồi bảo nhóm này múc trước, nhóm kia múc sau. Hãy đổi trạng thái cả hồ theo từng ca rồi đo.

Checklist trước khi viết một dòng Python

Trước khi mở notebook, bạn cần trả lời 7 câu hỏi này. Nếu chưa trả lời được, đừng vội chạy experiment:

Tài nguyên chung là gì? Premium model capacity, GPU pool, rate limit API, queue worker, cache nóng, hay vector search throughput?
Feature có đổi cách tiêu thụ tài nguyên không? Routing, batching, caching, reranking, fallback, tool calling đều có thể làm đổi pattern tiêu thụ.
Metric chính là gì? Task completion, latency p95, cost per successful task, error rate, hoặc số request bị fallback.
Có carryover không? Carryover là hiệu ứng sót lại từ slot trước sang slot sau, ví dụ queue chưa xả hết hoặc cache vẫn nóng.
Slot dài bao lâu? Quá ngắn thì nhiễu; quá dài thì ít mẫu. Nguồn chính dùng ví dụ 30 phút, nhưng team bạn phải chọn theo traffic và chu kỳ tải thật.
Có fairness guardrail không? Serving fairness là đảm bảo tenant hoặc nhóm user không bị ăn hết compute bởi nhóm khác.
Tiêu chí dừng là gì? Dừng vì metric xấu, vì cost vượt ngưỡng, vì queue backlog, hoặc vì carryover quá nặng để kết luận.

Ví dụ cụ thể: team SaaS ở Việt Nam có 3 gói khách hàng — free, pro, enterprise. Nếu routing mới đẩy request khó của enterprise sang premium model nhiều hơn, nhóm free có thể thấy latency tăng vì cùng dùng một backend pool. Nếu bạn randomize theo user, manh mối về tác động thật sẽ bị lẫn với tác động tranh tài nguyên.

Một buổi chiều triển khai bản thử nhỏ

Mục tiêu không phải dựng hệ thống experiment hoàn hảo. Mục tiêu là có bản pilot đủ sạch để biết nên scale hay dừng.

Bước 1: đóng băng feature flag theo time slot

Dùng feature flag ở cấp platform, không phải cấp user. Ví dụ:

experiment: ai_router_switchback
slot_minutes: 30
states: [router_on, router_off]
randomization_unit: time_slot

Điểm quan trọng: trong một slot, toàn bộ request đi cùng một trạng thái. Đừng lén bật theo tenant VIP, vì lúc đó bạn lại mở thêm một lớp nhiễu.

Bước 2: log event đủ để điều tra lại

Mỗi request nên có tối thiểu:

{
  "slot_id": "2026-07-01T10:00Z",
  "experiment_state": "router_on",
  "tenant_tier": "pro",
  "model_used": "premium",
  "latency_ms": 1840,
  "success": true,
  "fallback_reason": null
}

Đừng chỉ log outcome. Bạn cần dấu vân tay của đường đi: router chọn gì, model nào được dùng, có fallback không, queue lúc đó ra sao.

Bước 3: đo cả metric sản phẩm lẫn metric vận hành

Metric sản phẩm cho biết user có làm xong việc không. Metric vận hành cho biết hệ thống có đang trả giá quá đắt không.

Bảng tối thiểu:

| Nhóm đo | Metric nên có | Câu hỏi cần trả lời |
|---|---|---|
| Chất lượng | task success, retry rate | Router có giúp hoàn thành việc không? |
| Độ trễ | p50, p95, timeout rate | Có làm trải nghiệm chậm đi không? |
| Chi phí | premium calls per success | Có đốt model xịn quá tay không? |
| Công bằng | usage theo tenant tier | Có nhóm nào bị đẩy ra rìa không? |
| Ổn định | queue depth, fallback rate | Có tạo áp lực dây chuyền không? |

Bước 4: kiểm tra carryover trước khi tin kết quả

Nếu slot router_on vừa kết thúc mà queue vẫn đầy, slot router_off kế tiếp sẽ bị ảnh hưởng. Khi đó, trạng thái off không còn sạch.

Cách làm thực dụng: bỏ vài phút đầu mỗi slot khỏi phân tích, hoặc thêm biến chỉ báo “slot trước là gì” vào model phân tích. Với dữ liệu time series — chuỗi dữ liệu theo thời gian — bạn cũng nên dùng standard error phù hợp như HAC standard errors, tức cách ước lượng sai số chịu được tự tương quan theo thời gian.

Bạn không cần biến buổi chiều thành seminar causal inference. Nhưng bạn cần đủ kỷ luật để không kết luận từ dữ liệu bẩn.

Guardrail: khi nào scale, khi nào dừng

Một switchback pilot tốt phải có cửa thoát rõ. Không có tiêu chí dừng, experiment dễ biến thành cuộc điều tra kéo dài mà ai cũng chọn bằng cảm giác.

Mình sẽ đặt ngưỡng theo hướng này:

Scale nếu task success tăng ổn định qua nhiều slot, latency p95 không xấu đi rõ rệt, cost per successful task chấp nhận được, và fairness theo tenant không lệch đáng kể.
Giữ ở pilot nếu chất lượng tăng nhưng cost hoặc latency dao động mạnh. Lúc này cần tuning router, thêm quota, hoặc tách pool.
Dừng nếu router thắng trên average nhưng làm một nhóm tenant chịu timeout nhiều hơn, hoặc carryover quá nặng khiến slot off/on không còn phân biệt được.

Điểm dễ sai: chỉ nhìn average. LLM serving fairness nhắc mình rằng một hệ thống inference không chỉ cần nhanh, mà còn phải chia compute hợp lý giữa các tenant. Average đẹp có thể che việc một nhóm khách hàng bị thiệt.

Hình dung thế này: bạn là tech lead ký duyệt rollout. Dashboard tổng báo xanh, nhưng enterprise tenant A bị tăng timeout vào giờ cao điểm. Nếu chỉ nhìn mean latency, bạn bỏ sót vụ án. Nếu nhìn theo tenant tier, slot, queue depth, bạn thấy đường đi của vấn đề.

Bẫy hay gặp ở team builder

Bẫy 1: offline eval thắng nên production sẽ thắng. Offline eval giúp lọc ý tưởng, không chứng minh được tác động trong môi trường tài nguyên chung. Routing thay đổi hành vi hệ thống, không chỉ thay đổi câu trả lời của model.

Bẫy 2: randomize user vì tool A/B mặc định làm vậy. Công cụ experiment phổ biến thường giả định user độc lập. Với LLM platform dùng chung capacity, giả định này có thể sai ngay từ đầu.

Bẫy 3: thiếu test data đủ giống thật. Nguồn về Pinecone nhắc một chuyện rất đời: dữ liệu test phải đủ lớn, đủ realistic, và tái sử dụng được. Với AI routing, bạn cũng cần replay traffic hoặc synthetic workload có phân phối gần thật, không chỉ vài prompt đẹp.

Bẫy 4: không có cảnh báo khi upstream thay đổi. Mẫu git scraping của Simon Willison đáng học ở chỗ: khi dependency bên ngoài đổi, mở issue tự động để người phụ trách xem. Với LLM routing, bạn có thể theo dõi model pricing, rate limit, model card, hoặc config quota. Khi file cấu hình đổi, tạo issue thay vì chờ production tự báo.

Bẫy 5: quên nhóm user yếu thế. Nếu feature mới làm premium capacity bị chiếm bởi request “có vẻ quan trọng”, các request nhỏ có thể bị đẩy xuống. Fairness không phải khẩu hiệu đạo đức; nó là yêu cầu vận hành để hệ thống không tự thiên vị theo traffic pattern.

Nếu là mình, mình sẽ làm thế này

Trong tuần đầu, mình không rollout theo user. Mình sẽ chạy switchback nhỏ ở một cluster hoặc một region ít rủi ro, với slot cố định, feature flag đơn giản, và dashboard tách rõ theo tenant tier.

Trong một buổi chiều, team có thể làm bản tối thiểu:

Chọn một feature routing có thể bật/tắt toàn cục.
Định nghĩa slot 30 phút hoặc theo nhịp traffic thật của hệ thống.
Log slot_id, experiment_state, model_used, tenant_tier, latency, success, fallback.
Vẽ dashboard so sánh on/off theo slot, không chỉ theo user.
Đặt trước điều kiện scale, giữ pilot, hoặc dừng.

Bản chất thật sự: bạn không chỉ đang thử một AI feature. Bạn đang thử xem feature đó làm hệ thống đổi hành vi thế nào khi mọi người cùng dùng chung tài nguyên.

Takeaway chốt lại: với LLM platform, experiment tốt không phải là chia user cho đều; experiment tốt là không làm hỏng hiện trường trước khi đo. Đo sai thì router có thể trông như thiên tài, nhưng production lại là người phải ký biên bản.

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