Sai lầm tốn kém phổ biến nhất: dùng model lớn nhất cho mọi thứ. Phần lớn công việc trong một agent (phân loại intent, trích xuất trường, định tuyến, tóm tắt ngắn) không cần model đắt nhất. Routing là nghệ thuật đưa mỗi tác vụ tới model vừa đủ giỏi.
Nguyên tắc: phân tầng năng lực
Chia model thành 3 tầng:
- Nhỏ/rẻ/nhanh (Haiku, mini...): phân loại, trích xuất, kiểm tra định dạng, câu hỏi đơn giản.
- Trung bình: viết trả lời thông thường, tóm tắt, đa số hội thoại.
- Lớn/đắt/chậm (Opus, model reasoning): bài toán suy luận nhiều bước, code phức tạp, quyết định rủi ro cao.
Ví dụ: agent hỗ trợ đơn hàng
Mỗi lượt hiện dùng model lớn. Nhưng thực tế:
- 60% là intent đơn giản ("đơn tới đâu rồi?") → tầng nhỏ trả lời hoàn hảo.
- 30% cần soạn trả lời có ngữ cảnh → tầng trung bình.
- 10% là khiếu nại phức tạp cần suy luận → tầng lớn.
Ba kiểu routing
- Static routing theo use-case: bạn biết trước tác vụ nào ở tầng nào (intent-classify → luôn tầng nhỏ). Đơn giản, an toàn, làm trước.
- Router bằng model nhỏ: một model rẻ đọc yêu cầu và quyết định độ khó → chọn tầng. Linh hoạt hơn, thêm 1 lệnh gọi rẻ.
- Escalation (leo thang): thử tầng thấp trước; nếu model tự báo "không đủ tự tin" hoặc kết quả không đạt kiểm tra → leo tầng.
def route(task):
if task.type in ("classify", "extract", "format_check"):
return "small"
if task.needs_deep_reasoning or task.risk == "high":
return "large"
return "medium"
resp = call_llm(route(task), messages, task.use_case, trace_id)
Escalation an toàn
resp = call_llm("small", msgs, uc, tid)
if not passes_check(resp): # schema sai, confidence thấp
resp = call_llm("large", msgs, uc, tid) # leo thang
Mẹo: chỉ nên leo thang khi tỉ lệ fail của tầng nhỏ thấp (ví dụ <15%), nếu không bạn trả tiền hai lần cho phần lớn traffic.
Các bước triển khai
- Liệt kê mọi lệnh gọi LLM và gắn tầng tối thiểu cần thiết (static routing trước).
- Chạy A/B: so tầng nhỏ vs lớn trên cùng tập mẫu, chấm bằng bộ kiểm định (Bài 8).
- Đặt cổng chất lượng: chỉ hạ tầng nếu chất lượng giảm dưới ngưỡng chấp nhận.
- Thêm escalation cho use-case biên (đôi khi khó đôi khi dễ).
- Theo dõi tỉ lệ mỗi tầng và chi phí — cảnh báo nếu traffic tầng lớn tăng bất thường.
Khung tư duy: "Model nhỏ nhất vượt qua bài kiểm tra"
Với mỗi tác vụ, câu hỏi không phải "model nào tốt nhất?" mà "model rẻ nhất nào vẫn đạt ngưỡng chất lượng?". Chọn nó.
Sai lầm thường gặp
- Downgrade mù không đo chất lượng → tiết kiệm tiền nhưng tăng lỗi, mất khách.
- Escalation cho traffic dễ-fail → trả tiền hai model cho đa số lượt, đắt hơn cả dùng thẳng model lớn.
- Router phức tạp cho hệ đơn giản → static routing đã đủ, router-bằng-model chỉ thêm độ trễ và điểm hỏng.
- Không có cổng rollback → hạ tầng gây sự cố mà không quay lại nhanh được.
- Bỏ qua khác biệt định dạng output giữa các model → parser vỡ khi đổi tầng.
Ví dụ tính toán lợi ích
Giả sử tầng lớn giá gấp 10 lần tầng nhỏ, và bạn chuyển được 60% traffic (nhóm intent đơn giản) xuống tầng nhỏ. Nếu trước đây 100% ở tầng lớn (chi phí quy ước = 100 đơn vị), sau routing bạn còn: 40% × 10 + 60% × 1 = 4,6 đơn vị trên mỗi 'phần', tức chỉ ~46 đơn vị — cắt hơn một nửa. Đó là lý do routing thường là đòn bẩy chi phí mạnh nhất khi phân bố độ khó lệch về phía dễ.
Lưu ý thực chiến: hãy giữ một 'bản đồ tầng' bằng bảng cấu hình (config) thay vì hard-code trong mã. Khi nhà cung cấp ra model mới rẻ hơn hoặc đổi giá, bạn chỉ sửa bảng cấu hình và chạy lại eval — không phải viết lại logic. Đồng thời chuẩn hóa output (ví dụ luôn yêu cầu JSON theo schema) để đổi tầng không làm parser vỡ.