Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang xây một sản phẩm AI và bạn quyết định "dùng luôn GPT-4o cho mọi thứ cho chắc". Sản phẩm chạy được, người dùng hài lòng. Nhưng đến cuối tháng, hoá đơn API gửi về làm bạn giật mình: chi phí gấp 8–10 lần so với dự tính. Khi mổ xẻ ra, bạn phát hiện 70% lượng request gửi đến mô hình đắt tiền nhất chỉ để làm những việc cực kỳ đơn giản: phân loại email là "spam hay không", trích xuất một số điện thoại từ đoạn text, hay trả lời câu "Giờ mở cửa của shop là mấy giờ?".
Đó chính là vấn đề mà bài học hôm nay giải quyết. Model Selection (chọn mô hình) và Routing Strategy (chiến lược định tuyến) là kỹ năng quyết định: với mỗi loại yêu cầu khác nhau, ta nên đẩy nó tới mô hình nào để vừa đảm bảo chất lượng, vừa tối ưu chi phí và tốc độ.
Đây là một trong những đòn bẩy lớn nhất mà một AI Product Manager có trong tay. Bạn không cần viết một dòng code mô hình nào, nhưng chỉ một quyết định kiến trúc routing đúng đắn có thể cắt giảm 60–80% chi phí vận hành mà người dùng gần như không nhận ra sự khác biệt. Trong khi đối thủ vẫn "đốt tiền" vì dùng một mô hình duy nhất cho mọi việc, bạn có biên lợi nhuận tốt hơn hẳn để tái đầu tư vào sản phẩm.
Lưu ý: bài này tập trung vào chọn và định tuyến giữa nhiều mô hình. Cách tính chi phí token chi tiết đã có ở Bài 40, còn chuyện fine-tuning hay không sẽ nằm ở Bài 42 — ở đây ta giả định bạn đang chọn giữa các mô hình có sẵn.
Khái niệm cốt lõi
Vì sao "một mô hình cho tất cả" là một cái bẫy
Trực giác tự nhiên của nhiều đội ngũ là chọn mô hình mạnh nhất rồi dùng nó ở mọi nơi, với suy nghĩ "mạnh thì lúc nào cũng tốt hơn yếu". Nhưng trong thực tế sản phẩm, ba yếu tố luôn kéo nhau theo hướng đối nghịch:
- Chất lượng (quality): mô hình lớn trả lời sâu, lập luận tốt, ít sai.
- Chi phí (cost): mô hình lớn có thể đắt hơn mô hình nhỏ tới 20–50 lần trên cùng một số token.
- Tốc độ / độ trễ (latency): mô hình lớn thường trả lời chậm hơn, ảnh hưởng trực tiếp đến trải nghiệm.
Phân tầng mô hình theo nhu cầu
Cách tư duy thực dụng nhất là chia danh mục mô hình của bạn thành các tầng (tiers):
Tầng nhanh & rẻ (fast/cheap): các mô hình như Llama 3.1 8B, Claude Haiku, GPT-4o-mini, Gemini Flash. Phù hợp cho: phân loại (classification), trích xuất thông tin có cấu trúc, định tuyến nội bộ, trả lời câu hỏi đơn giản, tóm tắt ngắn, kiểm tra định dạng. Đặc điểm: độ trễ thấp (thường dưới 1 giây), giá rẻ, đủ thông minh cho 60–80% lượng việc thực tế.
Tầng cân bằng (balanced): các mô hình tầm trung như Claude Sonnet, GPT-4o, Gemini Pro. Phù hợp cho: hội thoại chính với người dùng, viết nội dung chất lượng, lập luận nhiều bước vừa phải, tổng hợp từ nhiều nguồn (RAG). Đây thường là "con ngựa kéo cày" chủ lực của sản phẩm.
Tầng cao cấp (frontier/premium): các mô hình mạnh nhất như Claude Opus, GPT-4.5/o-series, Gemini Ultra. Chỉ dành cho: bài toán lập luận khó, phân tích phức tạp, viết code khó, các tình huống mà sai lầm tốn kém. Đắt nhất, chậm nhất, nên dùng có chọn lọc.
Routing là gì và các kiểu routing
Routing là cơ chế quyết định request này nên đi tới mô hình nào. Có vài chiến lược phổ biến:
- Rule-based routing (định tuyến theo luật): dùng quy tắc cứng. Ví dụ: nếu loại tác vụ là "phân loại" → tầng rẻ; nếu là "soạn email cho khách VIP" → tầng cân bằng. Đơn giản, dễ kiểm soát, dễ debug. Đây là điểm khởi đầu tốt nhất cho hầu hết sản phẩm.
- Classifier-based routing (định tuyến bằng bộ phân loại): dùng một mô hình nhỏ, rẻ làm "người gác cổng" để đánh giá độ phức tạp của request rồi quyết định gửi nó đi đâu. Linh hoạt hơn luật cứng nhưng phức tạp hơn.
- Cascade / fallback routing (định tuyến bậc thang): thử mô hình rẻ trước; nếu kết quả không đạt ngưỡng tin cậy (confidence thấp, không parse được, người dùng bấm "câu trả lời chưa đúng") thì leo thang lên mô hình mạnh hơn. Tối ưu chi phí rất tốt vì phần lớn request được giải quyết ở tầng rẻ.
- Semantic routing (định tuyến theo ngữ nghĩa): dựa vào ý nghĩa của câu hỏi (thường qua embeddings) để đẩy về mô hình hoặc pipeline chuyên biệt. Ví dụ câu hỏi về pháp lý đi một đường, câu hỏi tán gẫu đi đường khác.
Vendor diversification — không bỏ trứng vào một giỏ
Một khía cạnh ít người nói tới: routing còn là chiến lược giảm rủi ro. Nếu toàn bộ sản phẩm phụ thuộc một nhà cung cấp duy nhất, khi họ sập dịch vụ, đổi giá, hay siết rate limit, bạn chết theo. Có khả năng route sang nhà cung cấp dự phòng (ví dụ chính là OpenAI, dự phòng là Anthropic hoặc một mô hình mở host nội bộ) giúp sản phẩm bền vững hơn. Với thị trường Việt Nam, đây còn là cách để có phương án khi cần đáp ứng yêu cầu lưu trú dữ liệu trong nước.
Tình huống thực tế
Tình huống 1: Nền tảng chăm sóc khách hàng tự động cho sàn TMĐT
Một startup giả định tên TrợLý.vn xây chatbot chăm sóc khách hàng cho các shop bán hàng trên Shopee, TikTok Shop. Ban đầu họ dùng GPT-4o cho mọi tin nhắn. Với khoảng 500.000 tin nhắn mỗi tháng, hoá đơn API lên tới khoảng 9.000 USD/tháng — quá sức với một startup giai đoạn đầu.
Khi phân tích log, đội sản phẩm phát hiện cấu trúc tin nhắn rất rõ ràng: 65% là câu hỏi lặp đi lặp lại ("Còn hàng không shop?", "Bao giờ giao tới Đà Nẵng?", "Mã giảm giá còn dùng được không?"), 25% là yêu cầu cần ngữ cảnh đơn hàng cụ thể, và chỉ 10% là khiếu nại phức tạp cần xử lý khéo léo.
Họ thiết kế routing ba tầng: một bộ phân loại nhỏ (chạy Llama 3.1 8B self-host) đọc tin nhắn đầu vào và gán nhãn. Câu hỏi lặp đơn giản → trả lời bằng RAG + Haiku. Yêu cầu cần ngữ cảnh đơn hàng → Sonnet/GPT-4o. Khiếu nại nhạy cảm → mô hình tầng cao kèm cờ chuyển cho nhân viên người thật.
Kết quả: chi phí giảm từ 9.000 xuống còn khoảng 2.100 USD/tháng (giảm ~77%), trong khi điểm hài lòng (CSAT) thậm chí tăng nhẹ vì câu hỏi đơn giản giờ được trả lời nhanh hơn (dưới 1 giây thay vì 3–4 giây). Bài học: phần lớn lượng việc thực tế là việc dễ — nhận diện đúng "tỷ lệ việc dễ" trong sản phẩm của bạn chính là mỏ vàng tối ưu.
Tình huống 2: Cascade fallback trong một sản phẩm tóm tắt tài liệu
Một công ty fintech ở Singapore xây tính năng tóm tắt hợp đồng và báo cáo tài chính. Họ áp dụng cascade routing: mọi tài liệu đi qua Gemini Flash trước. Sau khi có bản tóm tắt, một bước kiểm tra tự động chấm điểm: bản tóm tắt có bỏ sót con số quan trọng không, có mâu thuẫn nội tại không, độ dài có hợp lý không. Nếu điểm tin cậy dưới ngưỡng (khoảng 12% số tài liệu, thường là hợp đồng dài và nhiều điều khoản chéo), request mới được leo thang lên Claude Opus để làm lại.
Kết quả: 88% tài liệu được xử lý hoàn toàn ở tầng rẻ. Chi phí trung bình mỗi tài liệu thấp hơn khoảng 6 lần so với phương án "Opus cho tất cả", nhưng chất lượng trên những tài liệu khó vẫn được đảm bảo nhờ cơ chế leo thang. Bài học: cascade đặc biệt hiệu quả khi bạn có cách đo được chất lượng đầu ra một cách tự động. Không có thước đo, cascade trở thành đoán mò.
Tình huống 3: Cái bẫy "tối ưu quá đà" làm hỏng sản phẩm
Một đội làm trợ lý viết content marketing tiếng Việt quyết tâm tiết kiệm, route gần như toàn bộ request sang mô hình nhỏ nhất. Trên giấy tờ, chi phí cực thấp. Nhưng tỷ lệ người dùng huỷ gói trả phí (churn) tăng vọt trong hai tháng. Khi phỏng vấn, người dùng phàn nàn nội dung "nhạt", "máy móc", "không bằng tự viết". Mô hình nhỏ xử lý tiếng Việt kém tự nhiên hơn nhiều ở các tác vụ sáng tạo.
Họ phải đảo ngược: route các tác vụ sáng tạo cốt lõi (vốn là giá trị người dùng trả tiền) lên tầng cân bằng, chỉ giữ tầng rẻ cho các việc phụ trợ như gợi ý tiêu đề, đếm từ, kiểm tra chính tả. Bài học: đừng tối ưu chi phí ở chính nơi tạo ra giá trị mà người dùng sẵn sàng trả tiền. Tiết kiệm sai chỗ đắt hơn nhiều so với khoản chi phí bạn cắt được.
Hướng dẫn từng bước
Đây là quy trình thực tế để thiết kế chiến lược routing cho sản phẩm của bạn:
Bước 1 — Lập bản đồ các loại tác vụ (task taxonomy). Lấy log thật (hoặc dữ liệu giả lập sát thực tế) và phân loại các request thành nhóm: phân loại/trích xuất, hỏi-đáp đơn giản, hội thoại chính, lập luận phức tạp, tác vụ sáng tạo cốt lõi. Ước lượng tỷ lệ phần trăm mỗi nhóm. Đây là dữ liệu nền cho mọi quyết định sau.
Bước 2 — Xác định ràng buộc cho từng nhóm. Với mỗi nhóm, hỏi: ngưỡng chất lượng tối thiểu chấp nhận được là bao nhiêu? Độ trễ tối đa người dùng chịu được? Mức độ "tốn kém nếu sai" thế nào? Một câu trả lời giờ mở cửa sai thì vô hại; một tư vấn sai về liều thuốc thì nghiêm trọng.
Bước 3 — Gán mô hình ứng viên cho mỗi nhóm và chạy đánh giá. Đừng chọn theo cảm tính. Lấy 50–100 ví dụ thật của mỗi nhóm, chạy qua vài mô hình ứng viên, chấm điểm chất lượng (có thể dùng LLM-as-judge kết hợp người chấm). Mục tiêu: tìm mô hình rẻ nhất vẫn vượt ngưỡng chất lượng cho từng nhóm.
Bước 4 — Chọn cơ chế routing. Bắt đầu bằng rule-based vì dễ hiểu, dễ debug. Chỉ nâng cấp lên classifier-based hoặc cascade khi luật cứng không còn đủ tinh tế. Đừng xây hệ thống routing phức tạp ngay từ ngày đầu.
Bước 5 — Thêm fallback và xử lý lỗi. Luôn có phương án khi mô hình chính lỗi, quá tải, hay timeout: route sang nhà cung cấp dự phòng hoặc xuống tầng thấp hơn. Một sản phẩm "vẫn chạy với chất lượng thấp hơn" tốt hơn nhiều một sản phẩm "sập hoàn toàn".
Bước 6 — Giám sát và lặp lại. Theo dõi ba chỉ số cốt lõi theo từng route: chi phí trung bình/request, độ trễ p95, và điểm chất lượng/tỷ lệ leo thang. Khi mô hình mới ra mắt (thị trường này thay đổi vài tháng một lần), chạy lại đánh giá vì một mô hình rẻ hơn có thể đã đủ tốt cho tầng cao hơn.
Lỗi thường gặp & mẹo
Lỗi 1 — Mặc định dùng mô hình mạnh nhất "cho chắc". Đây là lỗi đắt tiền nhất và phổ biến nhất. Hãy đảo ngược tư duy: mặc định dùng mô hình rẻ nhất đủ tốt, chỉ leo thang khi có lý do.
Lỗi 2 — Tối ưu chi phí ở chính chỗ tạo giá trị. Như tình huống 3, đừng cắt giảm ở tính năng cốt lõi mà người dùng trả tiền. Phân biệt rõ "việc cốt lõi" và "việc phụ trợ".
Lỗi 3 — Không có cách đo chất lượng tự động. Cascade và classifier routing chỉ hoạt động nếu bạn đo được chất lượng. Đầu tư vào một bộ eval (đánh giá) là điều kiện tiên quyết, không phải tuỳ chọn.
Lỗi 4 — Quên chi phí ẩn của routing. Bản thân bộ classifier hay bước chấm điểm cũng tốn token và độ trễ. Đảm bảo khoản tiết kiệm lớn hơn nhiều chi phí của lớp routing.
Lỗi 5 — Hardcode tên mô hình khắp codebase. Khi cần đổi mô hình, bạn sẽ phải sửa hàng chục chỗ. Hãy tách routing thành một lớp cấu hình tập trung để đổi mô hình chỉ trong một file.
Mẹo: Dùng router phía hạ tầng (như các thư viện/cổng LiteLLM, OpenRouter) để chuẩn hoá việc gọi nhiều nhà cung cấp qua một giao diện chung — giúp đổi và thử nghiệm mô hình dễ hơn nhiều.
Mẹo: Kết hợp routing với caching. Nhiều câu hỏi lặp lại có thể trả lời từ cache, thậm chí còn rẻ hơn cả mô hình rẻ nhất.
Bài tập thực hành
- Lập task taxonomy. Lấy một sản phẩm AI bạn biết (hoặc đang làm). Liệt kê 5–7 loại tác vụ mà nó xử lý, ước lượng tỷ lệ phần trăm lượng request của mỗi loại. Loại nào chiếm nhiều nhất nhưng lại đơn giản nhất?
- Thiết kế bảng routing. Tạo một bảng ba cột: Loại tác vụ | Mô hình đề xuất (tầng nào) | Lý do. Điền cho từng loại ở bài 1. Ghi rõ ngưỡng chất lượng tối thiểu cho mỗi dòng.
- Tính toán tiết kiệm. Giả sử sản phẩm có 300.000 request/tháng, hiện đang dùng một mô hình giá 5 USD/triệu token đầu vào với trung bình 800 token/request. Tính chi phí hiện tại. Sau đó giả định bạn route 70% lượng request sang một mô hình rẻ hơn 25 lần. Chi phí mới là bao nhiêu? Phần trăm tiết kiệm?
- Thiết kế cascade. Cho tính năng tóm tắt văn bản, hãy mô tả: tiêu chí nào để quyết định một bản tóm tắt "đạt" hay phải leo thang lên mô hình mạnh hơn? Liệt kê ít nhất 3 tiêu chí đo được tự động.
Tóm tắt
Model Selection và Routing Strategy là một trong những đòn bẩy mạnh nhất mà AI Product Manager có thể kéo để cân bằng giữa chất lượng, chi phí và tốc độ. Ý tưởng cốt lõi rất giản dị: độ phức tạp của tác vụ khác nhau, nên mô hình xử lý chúng cũng phải khác nhau. Hãy phân tầng mô hình (nhanh-rẻ, cân bằng, cao cấp), lập bản đồ các loại tác vụ trong sản phẩm, rồi định tuyến mỗi loại tới mô hình rẻ nhất mà vẫn đủ tốt.
Bắt đầu bằng rule-based routing đơn giản, thêm cascade/fallback khi bạn đã có cách đo chất lượng tự động, và đừng bao giờ tối ưu chi phí ngay tại nơi tạo ra giá trị cho người dùng. Cuối cùng, hãy coi routing là một hệ thống sống: giám sát chi phí, độ trễ, chất lượng theo từng route và chạy lại đánh giá mỗi khi thị trường mô hình thay đổi. Làm tốt việc này, bạn có thể cắt 60–80% chi phí mà người dùng gần như không nhận ra — một lợi thế cạnh tranh thực sự bền vững.