Model Cascading: Thử rẻ trước, escalate khi cần

Trong bài viết về Smart Model Routing, chúng ta đã điểm qua ba kỹ thuật định tuyến LLM phổ biến nhất: dùng model nhỏ làm classifier, cascading, và semantic routing. Trong đó, cascading được tóm lược bằng một ý niệm trực quan: thử model rẻ trước, kiểm tra kết quả bằng máy, nếu đạt thì giữ lại, nếu không đạt thì escalate lên model mạnh hơn.

Về mặt lý thuyết, ý niệm này hấp dẫn vô cùng. Bạn không cần huấn luyện một bộ phân loại riêng, không cần đoán trước độ khó của prompt, và có thể triển khai ngay trong một buổi chiều. Nhưng trên môi trường production, "thử rẻ trước" không phải lúc nào cũng rẻ hơn. Kỹ thuật này đi kèm một cái giá ẩn: mọi request đều phải trả phí cho tầng model đầu tiên, và nếu không hiểu rõ ranh giới kiểm định, hệ thống của bạn có thể vừa tốn thêm tiền vừa làm suy giảm nghiêm trọng trải nghiệm người dùng.

Bài viết này bóc tách toàn bộ cơ chế kỹ thuật và kinh tế học đằng sau Model Cascading: từ cách xây dựng bộ kiểm định tự động theo từng loại dữ liệu, bài toán đánh đổi ngưỡng an toàn, cho đến công thức tính điểm hòa vốn thực tế.

Bốn cơ chế kiểm tra tự động theo từng loại output

Hiệu quả kinh tế của Model Cascading phụ thuộc sống còn vào một yếu tố: bước kiểm định đầu ra (Quality Gate) có đủ nhanh, đủ rẻ và đủ chính xác hay không. Nếu bước kiểm tra tốn nhiều chi phí token hoặc tốn thời gian tương đương một lượt gọi LLM, toàn bộ luận điểm tiết kiệm của cascading lập tức sụp đổ.

Trong thực tế kỹ thuật, các bài kiểm tra tự động được chia thành bốn cơ chế tương ứng với từng định dạng dữ liệu:

1. JSON Schema Validation (Đầu ra có cấu trúc)

Đây là vùng đất lý tưởng nhất của Model Cascading. Khi bạn yêu cầu LLM trích xuất dữ liệu từ email, hợp đồng hay văn bản y tế vào một schema định sẵn (Pydantic model trong Python hoặc Zod schema trong TypeScript), tính đúng đắn có thể xác thực bằng chương trình biên dịch tĩnh:

• Kiểm tra cú pháp JSON hợp lệ (parseable).
• Kiểm tra sự hiện diện của các trường bắt buộc (required keys).
• Kiểm tra kiểu dữ liệu (string, integer, boolean, ISO 8601 timestamp).
• Kiểm tra giá trị nằm trong tập cho phép (enum validation) hoặc khớp biểu thức chính quy (regex pattern).

Toàn bộ quá trình này diễn ra trực tiếp trong RAM ở tầng backend ứng dụng, mất chưa tới 2 phần nghìn giây (2ms) và tốn $0 chi phí token. Nếu model nhỏ (như Claude Haiku hay GPT-4o-mini) trả về một chuỗi JSON thiếu trường tax_id hoặc để kiểu amount là string thay vì integer, bộ kiểm tra Pydantic bắt lỗi ngay lập tức và kích hoạt lệnh escalate lên model mạnh hơn kèm theo thông điệp lỗi cụ thể.

2. Sandbox Execution (Code sinh ra từ LLM)

Với các sản phẩm hỗ trợ viết code hoặc trợ lý phân tích dữ liệu (sinh mã SQL, Python pandas), tính đúng đắn của output không phụ thuộc vào cảm tính người đọc mà phụ thuộc vào việc code có chạy được hay không.

Cơ chế kiểm tra ở đây là đưa đoạn code của model rẻ vào một môi trường cô lập (sandbox container hoặc WebAssembly) và thực thi một bộ kiểm thử tự động (unit test suite hoặc property-based test):

• Mã nguồn có vượt qua bước phân tích cú pháp (AST parse) và linting không?
• Đoạn code có ném ra lỗi ngoại lệ thời gian chạy (runtime exception) không?
• Với các giá trị đầu vào biên (edge cases), kết quả trả về có khớp với các câu lệnh assertion không?

Chi phí cho bước kiểm định này chỉ là tài nguyên compute nội bộ (vài chục mili-giây CPU). Nếu code do model nhỏ sinh ra gặp lỗi AssertionError ở một case biên phức tạp, hệ thống đóng gói toàn bộ prompt ban đầu kèm theo traceback lỗi gửi lên Frontier Model để giải quyết dứt điểm.

3. Heuristic & Semantic Scorer (Văn bản tự do)

Mọi thứ bắt đầu trở nên mong manh khi bạn áp dụng cascading cho văn bản tự do (tóm tắt văn bản, viết email, trả lời câu hỏi hỗ trợ khách hàng). Bạn không thể dùng Pydantic để kiểm tra một đoạn tóm tắt có hay không, và cũng không thể chạy unit test cho một câu trả lời tư vấn.

Các kỹ sư thường phải dùng các chỉ số phỏng đoán (heuristics) để chấm điểm:

• Ràng buộc bề mặt (Surface constraints): Kiểm tra độ dài tối thiểu/tối đa, sự hiện diện của các từ khóa bắt buộc, cấm chứa các cụm từ chối trách nhiệm mẫu ("As an AI language model...").
• Độ tương đồng ngữ nghĩa (Embedding similarity): Chuyển câu trả lời của model rẻ thành vector và đo khoảng cách cosine với tài liệu nguồn để đảm bảo câu trả lời không bay ra ngoài ngữ cảnh.
• Tỷ lệ giữ lại thực thể (Entity Retention / Overlap Score): Dùng biểu thức chính quy hoặc thuật toán NER (Named Entity Recognition) nhẹ để đếm xem bao nhiêu con số, tên riêng, và thuật ngữ quan trọng trong tài liệu nguồn xuất hiện trong câu trả lời.

4. Vì sao kiểm định văn bản tự do luôn có nguy cơ phản tác dụng

Sự khác biệt cốt lõi nằm ở chỗ: hai cơ chế đầu là kiểm định tiền định (deterministic), còn hai cơ chế sau là kiểm định xác suất (probabilistic).

Một model nhỏ có thể sinh ra một đoạn văn xuôi trôi chảy tuyệt đối, câu cú gãy gọn, chứa đầy đủ từ khóa và con số từ tài liệu nguồn, nhưng lại đảo lộn hoàn toàn mối quan hệ nhân quả giữa chúng. Các bộ lọc heuristic bề mặt sẽ chấm đoạn văn này 95/100 điểm và cho qua (tạo ra lỗi lọt lưới - False Pass). Người dùng cuối là người đầu tiên phát hiện ra sự thật bị bóp méo.

Để đối phó với hiện tượng này, một số team tìm cách dùng thêm một LLM thứ hai làm giám khảo ("LLM-as-a-judge") để chấm điểm chất lượng câu trả lời của model rẻ. Nhưng một khi bạn phải gọi thêm một model để kiểm tra model trước đó, bạn đã tự tay triệt tiêu lợi thế chi phí của cascading — điều chúng ta sẽ thấy rõ trong phần kinh tế học bên dưới.

{
  "order_id": "VN-8821",
  "currency": "VND",
  "total_cents": 450000,
  "items": [{"sku": "KEY-RGB", "qty": 1}]
}

Đặt ngưỡng (Threshold) ở đâu: Sự đánh đổi giữa an toàn và lãng phí

Mọi hệ thống cascading có bước kiểm định xác suất đều phải đối mặt với một quyết định mang tính chiến lược của Product Manager: Đặt ngưỡng chấp nhận (acceptance threshold) ở mức nào?

Ngưỡng này phân chia output của model rẻ thành hai nhánh: đủ tốt để trả về cho người dùng, hoặc chưa đủ tốt và phải gửi lên model đắt hơn. Nhưng không có ngưỡng nào là hoàn hảo:

Ngưỡng quá chặt (Strict Threshold - ví dụ: score >= 0.85)

• Mục tiêu: Tối đa hóa độ an toàn, triệt tiêu lỗi sai tinh vi trước khi đến tay người dùng.
• Hệ quả kinh tế: Tỷ lệ escalate tăng vọt. Rất nhiều câu trả lời của model rẻ thực chất đã đạt mức "đủ tốt cho người dùng" nhưng vẫn bị đánh rớt vì thiếu một vài chỉ số máy móc.
• Chi phí thực tế: Ứng dụng phải trả tiền gấp đôi cho những request này — vừa trả tiền cho model rẻ ở tầng 1, vừa trả tiền cho model mạnh ở tầng 2. Lợi ích tiết kiệm ngân sách gần như bị xóa sạch.

Ngưỡng quá lỏng (Loose Threshold - ví dụ: score >= 0.65)

• Mục tiêu: Tối đa hóa tỷ lệ giữ lại của model rẻ (retention rate), giảm tối đa số lần phải gọi model đắt.
• Hệ quả kinh tế: Chi phí API giảm rất đẹp trên báo cáo tài chính tháng đầu tiên.
• Rủi ro sản phẩm: Các lỗi sai tinh vi (hallucination, sai số liệu nhỏ, mất sắc thái) lọt lưới và hiển thị thẳng tới khách hàng. Trong các lĩnh vực có mức chịu lỗi thấp như kế toán thuế, y tế hay pháp lý, chi phí khắc phục hậu quả của một câu trả lời sai lọt lưới thường lớn gấp hàng nghìn lần số tiền token tiết kiệm được.

Như được nhấn mạnh trong khung tư duy của bài học về kinh tế học AI (Lesson 14), PM không được đặt ngưỡng theo cảm tính. Ngưỡng thẩm định phải được thiết lập dựa trên mức độ chấp nhận sai sót của tác vụ (Task Error Tolerance): với các luồng rủi ro cao, bắt buộc phải nâng ngưỡng chặt hoặc bypass hoàn toàn khỏi cascading; với các luồng sáng tạo nội dung nội bộ, ngưỡng có thể nới lỏng để ưu tiên tối ưu chi phí.

Cascading khác gì với Routing đánh giá trước (Pre-call Routing)

Rất nhiều người nhầm lẫn Model Cascading với Model Routing nói chung. Bài viết pillar đã mô tả cơ chế Routing đánh giá trước (Pre-call Predictive Routing): một router đứng trước phân tích prompt, đoán xem tác vụ này khó hay dễ, rồi gửi thẳng tới đúng model. Cascading lại đi theo triết lý hoàn toàn khác: không đoán trước, cứ để model rẻ làm thử rồi mới quyết định.

Sự khác biệt căn bản này tạo ra hai cán cân đánh đổi trái ngược:

Điểm mấu chốt mà các tài liệu quảng bá thường bỏ qua: Cascading áp đặt một khoản "thuế model rẻ" lên 100% request của bạn. Kể cả những request cực khó mà ai nhìn vào cũng biết model rẻ không thể làm được, cascading vẫn bắt request đó chạy qua model rẻ trước, rồi mới chuyển lên model lớn.

Nếu hệ thống của bạn có 30% request thuộc dạng phức tạp, điều đó có nghĩa là 30% lượng người dùng của bạn phải chờ đợi lâu hơn đáng kể vì phải trải qua 2 lượt gọi API nối tiếp nhau, và bạn đang trả thêm 30% chi phí vô ích cho tầng model rẻ.

Kinh tế học của Cascading: Công thức Blended Cost & Điểm hòa vốn

Để xác định xem Model Cascading có thực sự đem lại lợi nhuận cho sản phẩm hay không, PM cần nắm vững công thức chi phí trung bình (Blended Cost per Request):

Mỗi request trong hệ thống cascading luôn tiêu tốn chi phí của model rẻ, cộng với chi phí của bộ kiểm tra, và một phần chi phí của model mạnh tỷ lệ thuận với tỷ lệ escalate.

Từ bảng phân rã kinh tế trên, chúng ta rút ra ba quy luật sống còn cho thiết kế hệ thống:

1. Điểm hòa vốn (Breakeven point): Khi tỷ lệ escalate vượt qua ngưỡng 45–50%, tổng chi phí của cascading sẽ tiệm cận việc gọi thẳng model mạnh ngay từ đầu, trong khi độ trễ trung bình tăng gấp đôi.
2. Chi phí kiểm định phải tiệm cận bằng 0: Nếu bạn dùng một model trung bình (ví dụ giá $0,006) để làm giám khảo cho model nhỏ ($0,0012), khoản phí kiểm định này tự nó đã cao gấp 5 lần tiền chạy model rẻ. Chi phí thẩm định lập tức phá hủy toàn bộ bài toán tiết kiệm.
3. Độ trễ P95 là cái bẫy lớn nhất: Kể cả khi Blended Cost nhìn rất hấp dẫn (giảm 60%), nếu 40% người dùng của bạn phải chịu độ trễ P95 trên 3 giây vì chạy hai vòng model, tỷ lệ rời bỏ sản phẩm (churn rate) có thể gây thiệt hại doanh thu lớn hơn nhiều số tiền API tiết kiệm được.

Khi nào Cascading thua các kỹ thuật khác

Từ những phân tích trên, chúng ta có thể chỉ rõ những tình huống cụ thể mà Model Cascading chắc chắn thất bại và nên nhường chỗ cho kỹ thuật khác:

1. Tác vụ phụ thuộc vào chất lượng chủ quan (Văn phong, Thuyết phục, Tone of Voice)

Hãy hình dung một tính năng hỗ trợ nhân viên kinh doanh viết email phản hồi khách hàng VIP. Độ khó ở đây không nằm ở ngữ pháp hay định dạng, mà nằm ở: sự đồng cảm, mức độ thuyết phục, tính khéo léo trong xử lý từ chối và giọng điệu chuẩn mực của thương hiệu.

Không có bộ kiểm tra regex hay thuật toán heuristic nào đo đếm được "sự khéo léo". Nếu dùng model rẻ, kết quả sinh ra sẽ nghe như một bản tin máy móc. Để phát hiện ra sự máy móc đó, bạn buộc phải gọi một model lớn hơn để đánh giá. Lúc này, chuỗi xử lý trở thành: Gọi model rẻ → Gọi model lớn để thẩm định → Thấy chưa đạt → Gọi model lớn viết lại. Chi phí lúc này đắt gấp 2,5 lần so với việc dùng một bộ phân loại ngữ cảnh đơn giản để đưa thẳng việc này cho model lớn xử lý ngay từ đầu.

2. Workload có tỷ lệ tác vụ khó áp đảo

Nếu sản phẩm của bạn là một công cụ phân tích hợp đồng pháp lý phức tạp hoặc gỡ lỗi kiến trúc hệ thống phân tán, nơi mà 70% yêu cầu đòi hỏi khả năng suy luận logic sâu. Việc áp dụng cascading đồng nghĩa với việc bạn cố tình bắt 70% request phải chạy thử và thất bại ở model rẻ.

Trong trường hợp này, Classifier-based Router (dùng một model siêu nhẹ đọc metadata và phân loại ngay từ đầu) hoặc Semantic Router sẽ vượt trội hoàn toàn: chúng bỏ qua model rẻ và chuyển thẳng 70% request khó tới Frontier Model, loại bỏ độ trễ kép và khoản phí vô ích.

3. Giao diện người dùng thời gian thực (Real-time Interactive UX)

Trong các giao diện mà người dùng đang chờ từng token streaming hiển thị trên màn hình (như ô chat tương tác trực tiếp), việc chạy cascading tạo ra trải nghiệm rất giật cục: người dùng thấy màn hình loading 500ms, sau đó hệ thống phát hiện fail, hủy kết quả cũ, và bắt đầu loading lại từ đầu thêm 2.000ms nữa. Người dùng sẽ cảm thấy sản phẩm chậm chạp và không ổn định.

Khung quyết định: Khi nào AI PM nên chọn Model Cascading

Trước khi phê duyệt áp dụng Model Cascading vào tính năng AI của sản phẩm, PM và Tech Lead nên cùng trả lời bản checklist 4 câu hỏi sau:

1. Tiêu chuẩn "Đủ tốt" có kiểm tra được bằng code tiền định (Deterministic Code) không? Nếu câu trả lời là CÓ (JSON Schema, SQL parse, Unit test, Regex format) với chi phí $0 token, cascading là ứng viên hàng đầu. Nếu câu trả lời là KHÔNG (cần đọc hiểu, đánh giá cảm xúc, thẩm định chuyên gia), hãy loại bỏ cascading.
2. Tỷ lệ vượt qua tự nhiên (Base Pass Rate) của model rẻ có đạt trên 75% không? Hãy đo đạc trên tập dữ liệu đánh giá (Eval Set). Nếu model rẻ thất bại quá 25% số ca, chi phí kép và độ trễ sẽ bắt đầu vượt khỏi tầm kiểm soát.
3. Trải nghiệm người dùng có chịu được độ trễ kép ở phân vị P95 không? Tác vụ nền (background job, batch processing, queue worker) cực kỳ phù hợp với cascading vì người dùng không phải nhìn spinner chờ đợi. Ngược lại, tác vụ trực diện người dùng cần được cân nhắc cẩn trọng.
4. Hệ quả của một lỗi lọt lưới (False Pass) là gì? Nếu một câu trả lời sai sót có thể dẫn tới kiện tụng, thất thoát tài chính hoặc rò rỉ an toàn, chi phí rủi ro là bất đối xứng. Lúc đó, giải pháp an toàn là sử dụng quy tắc bypass cứng (Hard Override) lên model mạnh hoặc sử dụng bộ phân loại rủi ro độc lập.

Model Cascading là một vũ khí tối ưu chi phí cực kỳ sắc bén — nhưng chỉ khi bạn đặt nó vào đúng vị trí: nơi mà máy móc có thể dễ dàng phân định đúng sai, và nơi mà sự tiết kiệm không phải trả giá bằng độ tin cậy của sản phẩm.