Rule-Based Routing: Luật Tất Định Trước Khi Model Vào Cuộc

Mọi kỹ thuật đã nhắc tới trong loạt bài này - Model Cascading, Classifier-based Router, Semantic Routing - đều quyết định request đi đâu bằng cách đánh giá nó, dù phép đánh giá đó chạy một model, một bài test, hay một phép so khớp vector. Rule-Based Routing là kỹ thuật duy nhất trong loạt bài này đôi khi ra quyết định mà không cần đánh giá gì cả.

Một rule là một điều kiện tường minh, được viết tay: một header của request bằng một giá trị đã biết, hạng tài khoản của người dùng khớp một danh mục đã biết, một từ khoá hoặc regex xuất hiện trong văn bản. Khi một rule khớp, quyết định định tuyến được đưa ra ngay trong code ứng dụng gốc, trước khi bất kỳ model nào - dù rẻ hay đắt - kịp nhìn thấy request. Bài viết Classifier-based Router đã giới thiệu ý tưởng này ở quy mô nhỏ, gọi nó là luật ghi đè cứng cho rủi ro bất đối xứng. Bài viết này lập luận rằng rule xứng đáng có một vị trí ở đầu toàn bộ chuỗi routing, chứ không chỉ là một lưới an toàn gắn thêm vào một kỹ thuật duy nhất.

Thế nào được tính là một Rule

Rule chia thành hai nhóm, và sự khác biệt này quyết định mức độ bạn nên tin tưởng chúng.

Rule metadata khớp trên các trường có cấu trúc, do ứng dụng kiểm soát: một header request, hạng đăng ký của người dùng đã xác thực, một feature flag, một endpoint API mà request đi qua. Loại này gần như không thể sai - chính ứng dụng đã đặt giá trị đó, nên không có gì mơ hồ để phán đoán nhầm.

Rule nội dung khớp trên chính văn bản của request, thường qua regex hoặc danh sách từ khoá: "hoàn tiền" định tuyến tới handler thanh toán, "khẩn cấp" kết hợp với một số thuật ngữ chuyên ngành kích hoạt luật ghi đè cứng, một định dạng câu cụ thể báo hiệu một ý định đã biết. Rule nội dung yếu hơn hẳn rule metadata, vì ngôn ngữ tự nhiên là kiểu đầu vào duy nhất mà một pattern cố định không thể lường trước hết được. Người dùng sớm muộn sẽ diễn đạt một yêu cầu bình thường theo cách vô tình chứa đúng từ khoá kích hoạt của bạn, và rule không có cách nào nhận ra có điều gì đó đã sai.

{
  "rule_id": "RULE_META_01",
  "matched": true,
  "match_type": "Khớp chính xác Metadata Header"
}

Vì sao Rule luôn đứng đầu chuỗi định tuyến

Lập luận kinh tế cho việc đặt một rule engine trước mọi kỹ thuật routing khác gần như đơn giản đến mức khó tin: một rule khớp đúng không tốn gì cả và mất khoảng một mili-giây. Không gọi LLM, không tính embedding, không có bước kiểm tra nào. Nếu một phần đáng kể traffic của bạn có thể phân loại với độ chắc chắn tuyệt đối chỉ từ metadata - request telemetry nội bộ của một app mobile, cuộc gọi API từ một đối tác tích hợp đã biết, một người dùng đã chọn "thanh toán" từ dropdown trước khi gõ chữ nào - thì việc đưa phần traffic đó qua một classifier hay một semantic router là lãng phí thuần tuý.

Đây cũng là lý do rule kết hợp tự nhiên với mọi kỹ thuật khác thay vì cạnh tranh với chúng. Một rule engine không phải là lựa chọn thay thế cho Classifier Router hay Semantic Routing - nó là lớp lọc đứng trước cả hai, hấp thụ phần traffic nó có thể phân loại chắc chắn và nhường lại phần còn lại nguyên vẹn.

Bài toán dễ vỡ: Không có điểm tin cậy nào để bắt lỗi khớp sai

Điểm mạnh lớn nhất của rule - nó không bao giờ do dự - cũng chính là điểm yếu cấu trúc của nó. Một classifier phán đoán sai request vẫn trả về một điểm tin cậy; một người review telemetry production có thể phát hiện những lượt gọi có độ tin cậy thấp rồi điều tra. Một rule không có khái niệm "tôi không chắc". Nó chỉ khớp hoặc không khớp, và khi nó khớp sai lý do, không có gì trong hệ thống báo hiệu rằng có điều gì đó bất thường vừa xảy ra.

Điều này tạo ra hai dạng lỗi khác biệt. False negative - một rule lẽ ra phải khớp nhưng lại không, vì người dùng diễn đạt hơi khác so với pattern đã lường trước - đơn giản là rơi xuống tầng kế tiếp, một kiểu thất bại nhẹ nhàng không tốn gì ngoài một khoản phí triage nhích lên đôi chút. False positive - một rule khớp với văn bản mà nó chưa bao giờ được viết ra để khớp - mới là dạng nguy hiểm. Một từ khoá viết cho luật ghi đè khẩn cấp y tế vô tình khớp với một câu không liên quan chỉ vì tình cờ chứa cùng từ đó sẽ đẩy một request bình thường đi theo một đường tốn kém, và đôi khi không phù hợp, mà không có cơ chế tự sửa nào trong toàn bộ pipeline.

Rule-Based Routing so với Classifier Routing

Cái giá không bao giờ xuất hiện trên hoá đơn token

Mọi kỹ thuật khác trong loạt bài này đều có một khoản chi phí bạn có thể đọc thẳng trên hoá đơn API. Chi phí thật của rule-based routing lại nằm ở một nơi hoàn toàn khác: số giờ kỹ sư bỏ ra để viết, kiểm thử và cập nhật bảng rule khi bề mặt sản phẩm mở rộng. Một danh sách rule bao phủ đầy đủ mọi danh mục rõ ràng lúc ra mắt sẽ âm thầm tích tụ điểm mù khi tính năng mới ra đời, phân khúc người dùng mới xuất hiện, và ngôn ngữ trôi dạt theo thời gian - và khác với classifier tự thích ứng ngay khi bạn sửa prompt của nó, một bảng rule chỉ an toàn hơn khi có ai đó nhận ra khoảng trống và tự tay lấp nó.

Đây không phải lý do để tránh dùng rule - khoản tiết kiệm $0/request là có thật và, ở quy mô lớn, rất đáng kể. Đây là lý do để dự trù chi phí bảo trì liên tục giống như bạn dự trù cho hạ tầng, thay vì coi "chúng ta đã viết rule một lần rồi" là một việc đã xong.

Khi nào Rule-Based Routing thắng thế

Rule là lựa chọn mặc định đúng đắn bất cứ khi nào một danh mục có thể xác định từ thứ mà ứng dụng đã biết chắc chắn: một hạng tài khoản đã xác thực, một feature flag, một endpoint API, một phần tử UI người dùng đã chọn tường minh. Trong những trường hợp này, chạy một classifier không chỉ lãng phí - nó còn tệ hơn, vì nó đưa vào một bước xác suất để suy lại một thông tin hệ thống đã biết chắc chắn từ trước.

Khi nào nó không phù hợp

Ngôn ngữ tự nhiên mở là mục tiêu sai cho một rule engine nếu dùng làm cơ chế duy nhất, chính vì lý do đã nêu ở trên: cách diễn đạt biến đổi theo những cách không danh sách pattern cố định nào lường trước hết được, và các lượt khớp trượt diễn ra trong im lặng. Những sản phẩm có ngôn ngữ thay đổi nhanh - slang mới, tên tính năng mới, cách người dùng mô tả cùng một yêu cầu theo những cách mới - sẽ thấy độ bao phủ của rule suy giảm liên tục trừ khi việc bảo trì theo kịp, điều hiếm khi bền vững quá một vài danh mục đã định nghĩa rõ ràng.

Checklist thẩm định của AI PM cho Rule-Based Routing

Như đã trình bày trong chương trình AI Product Management (Lesson 53), một kiến trúc guardrail được thiết kế tốt xếp lớp phòng vệ trên cả ranh giới đầu vào lẫn đầu ra thay vì dựa vào một cơ chế duy nhất - cùng nguyên tắc quyết định vị trí của một rule engine trong chuỗi routing.

Trước khi triển khai một rule làm cơ chế routing duy nhất cho một danh mục, hãy kiểm tra qua 4 câu hỏi sau:

1. Đây là rule metadata hay rule nội dung? Rule metadata (header, hạng tài khoản, feature flag) gần như không có rủi ro. Rule nội dung (khớp từ khoá và regex) cần được review tường minh xem văn bản không liên quan nào có thể vô tình kích hoạt chúng.
2. Điều gì xảy ra khi false negative? Nếu câu trả lời là "nó rơi xuống một tầng thông minh hơn", rule đó an toàn để triển khai dù chưa hoàn hảo. Nếu một lượt trượt nghĩa là request bị xử lý sai trong im lặng mà không có fallback, rule đó chưa sẵn sàng.
3. Điều gì xảy ra khi false positive? Với các rule ghi đè cứng cụ thể, một false positive đưa một request bình thường lên tầng đắt tiền - lãng phí, nhưng không nguy hiểm. Với các rule định tuyến vào một đường ít bị kiểm soát hơn, một false positive có thể là rủi ro thật sự; hãy audit kỹ hơn với những pattern đó.
4. Ai chịu trách nhiệm giữ bảng rule này luôn cập nhật, và họ sẽ biết khi nào nó lỗi thời bằng cách nào? Một rule không có người sở hữu bảo trì và không có quy trình phát hiện trôi dạt sẽ suy thoái một cách vô hình. Hãy coi bảng rule là một tài liệu sống, cần kỷ luật giám sát tương đương mọi tầng routing khác trong chuỗi.

Rule-based routing là kỹ thuật rẻ nhất, nhanh nhất và dễ audit nhất trong cả loạt bài - và cũng là kỹ thuật dễ âm thầm ngừng khớp với thực tế nhất nếu không có ai theo dõi nó.