Semantic Routing: Định tuyến theo ý nghĩa, không theo từ khoá

Trong hai bài viết trước của cụm chuyên đề định tuyến LLM, chúng ta đã mổ xẻ hai triết lý trái ngược nhau: Model Cascading dựa trên cơ chế thử sai (chạy thử model rẻ rồi kiểm tra kết quả), còn Classifier-based Router dựa trên cơ chế phán đoán trước (dùng một model siêu nhẹ đọc prompt để ra phán quyết có cấu trúc).

Cả hai kỹ thuật đó đều có một điểm chung: chúng đều phải gọi một mô hình ngôn ngữ (LLM) để suy luận hoặc sinh text.

Semantic Routing (định tuyến theo ngữ nghĩa) mở ra một hướng đi hoàn toàn khác: nó loại bỏ hoàn toàn bước suy luận của LLM ở cửa ngõ. Thay vì hỏi một model xem câu hỏi này thuộc về đâu, semantic routing biến văn bản thành các tọa độ toán học (vector embedding) và so khớp khoảng cách hình học trong không gian nhiều chiều. Quá trình này diễn ra chỉ trong 5 đến 10 mili-giây với chi phí token gần như bằng 0.

Nhưng hình học không gian có những điểm mù chết người mà nếu không hiểu rõ, hệ thống của bạn sẽ đưa ra những quyết định điều hướng ngớ ngẩn mà không hề hay biết.

Cơ chế thực tế: Không phải "Suy Luận", mà là Khoảng Cách Hình Học

Rất nhiều tài liệu tiếp thị mô tả semantic router như một "AI thông minh hiểu được ý định người dùng". Trên thực tế kỹ thuật, bên dưới lớp vỏ bọc đó hoàn toàn không có một trí thông minh nào đang "suy nghĩ" hay "đọc hiểu".

Cơ chế thực sự của Semantic Routing là phép đo khoảng cách hình học (Geometric Nearest-Neighbor) thuần túy:

1. Khởi tạo danh mục Route (Route Catalog): Bạn xác định trước các nhóm chủ đề nghiệp vụ trong sản phẩm (ví dụ: billing, shipping, account_security). Với mỗi route, bạn cung cấp từ 5 đến 20 câu ví dụ mẫu đại diện cho ý định đó.
2. Tính toán Vector Đại diện (Centroid): Hệ thống đưa các câu mẫu qua một model embedding (như text-embedding-3-small của OpenAI hay bge-small) để chuyển thành các vector 1536 chiều, sau đó tính vector trung bình (centroid) đại diện cho tọa độ trung tâm của route đó trong không gian vector.
3. Mã hoá và So khớp (Inference-Free Matching): Khi người dùng gửi request, router chỉ làm hai việc:
   • Gọi API embedding để chuyển prompt thành 1 vector duy nhất (tốn khoảng 100 token input, không sinh output token).
   • Tính tích vô hướng (Cosine Similarity) giữa vector này với tọa độ của các centroid đã lưu trong RAM.
   • Chọn route có điểm số tương đồng cao nhất (Nearest-Neighbor).

Toàn bộ bước so khớp diễn ra bằng các phép nhân ma trận cơ bản trên CPU trong vòng chưa đầy 1 mili-giây. Tổng thời gian từ lúc nhận prompt đến khi ra quyết định chỉ mất khoảng 6–10ms (chủ yếu là thời gian mạng gọi embedding API), với chi phí khoảng $0,00002 — rẻ hơn 20 lần và nhanh hơn 15 lần so với việc gọi một Classifier LLM như ở bài trước.

Vì sao mạnh ở nhận diện loại việc, nhưng lại mù về độ khó?

Ưu thế lớn nhất của semantic routing nằm ở khả năng nhận diện ý định (Intent) mà không bị phụ thuộc vào từ khóa cụ thể.

Ví dụ kinh điển trong bài viết pillar: "Sao tôi bị tính tiền hai lần?" và "Thẻ của tôi có một giao dịch trùng lặp hôm qua" không chung nhau một từ khóa nào. Nhưng trong không gian embedding, các mô hình vector được huấn luyện trên hàng tỷ văn bản đã học được rằng hai ngữ cảnh này nói về cùng một khái niệm tài chính. Tọa độ của chúng tự nhiên rơi sát cạnh cụm billing.

Tuy nhiên, chính cơ chế hình học này lại tạo ra một nghịch lý tai hại đối với kiến trúc model routing:

Các câu nói về cùng một chủ đề luôn nằm cạnh nhau trong không gian vector, nhưng độ phức tạp tính toán (Reasoning Difficulty) thì không hề tạo ra các cụm hình học tách biệt.

Hãy so sánh hai yêu cầu sau:

• Request A: "Hoá đơn VAT tháng 8 của tôi trị giá bao nhiêu tiền?"
• Request B: "Hãy đối chiếu 14 phụ lục thanh toán quốc tế này và giải quyết tranh chấp mâu thuẫn khấu trừ thuế nhà thầu 50.000 USD..."

Cả hai câu này đều "nói về thanh toán và hoá đơn" (Billing). Trong không gian vector, vector của cả Request A và Request B đều có độ tương đồng Cosine trên 0.86 so với centroid của nhóm billing.

Semantic router sẽ vui vẻ gán cả hai câu vào cùng một route. Nhưng về mặt tài nguyên xử lý:

• Request A chỉ cần một câu lệnh SQL hoặc một model nhỏ siêu rẻ ($0,0005) trong 200ms.
• Request B đòi hỏi một Frontier Reasoning Model ($0,0300) đọc hiểu đa tài liệu trong 3.000ms.

Nếu bạn dùng Semantic Routing độc lập để chọn model đích, bạn sẽ liên tục gặp lỗi: hoặc là đẩy Request B vào model nhỏ khiến nó bị ảo giác (Under-routing), hoặc đẩy cả Request A lên model lớn gây lãng phí 97% chi phí (Over-routing).

Đây là lý do sống còn: Semantic Routing không phải đối thủ cạnh tranh của Classifier Router, mà là hai nửa của một lời giải hoàn chỉnh. Semantic Routing trả lời câu hỏi "Đây là loại việc gì?" (Domain/Intent), còn Classifier Router trả lời câu hỏi "Việc này khó tới mức nào?" (Cognitive Difficulty).

Chi phí ẩn: Quản trị danh mục Route và bài toán Trôi dạt (Route Drift)

Ở bài Model Cascading và Classifier-based Router, hệ thống không đòi hỏi bạn phải liệt kê trước mọi chủ đề có thể xảy ra trong vũ trụ của người dùng. Chúng chỉ quan tâm đến tính đúng sai của code hoặc độ khó trừu tượng (nhỏ, vừa, mạnh).

Semantic Routing thì ngược lại: Hệ thống bắt buộc phải có một danh mục các route tĩnh được định nghĩa từ trước.

Và danh mục này không bao giờ đứng yên:

• Khi công ty bạn ra mắt tính năng mới (ví dụ: tính năng hoàn tiền tự động qua ví điện tử), một nhóm câu hỏi hoàn toàn mới xuất hiện.
• Nếu không có kỹ sư nào chủ động thu thập câu mẫu, tạo vector embedding mới và đưa vào danh mục, các câu hỏi về ví điện tử sẽ rơi vào trạng thái "vô gia cư".
• Ngôn ngữ người dùng biến đổi theo thời gian (slang, thuật ngữ mới, mã sản phẩm mới) khiến các vector câu hỏi dần dần trôi dạt ra xa khỏi centroid ban đầu.

Chi phí của Semantic Routing vì vậy không nằm ở hóa đơn API token mỗi tháng. Nó nằm ở chi phí vận hành (Operational Overhead): bạn cần quy trình giám sát các câu hỏi nằm ở vùng biên, định kỳ chạy thuật toán phân cụm (clustering) để phát hiện chủ đề mới, và liên tục tinh chỉnh lại tập vector centroid.

Lỗi đặc trưng: Bẫy Nearest-Neighbor và Sự cần thiết của Ngưỡng Cosine

Trong toán học, thuật toán tìm kiếm láng giềng gần nhất ($k=1$ Nearest-Neighbor) có một đặc tính nguy hiểm: Nó luôn luôn trả về một kết quả, bất kể kết quả đó có ý nghĩa hay không.

Nếu một người dùng gửi vào chatbot hỗ trợ khách hàng của bạn một bài thơ tình, một đoạn code độc hại, hay một câu hỏi triết học về vũ trụ:

• Hệ thống vẫn tính toán khoảng cách hình học tới 3 cụm billing, shipping, và security.
• Giả sử khoảng cách tới shipping là 0.72 (tức là rất xa), trong khi hai cụm kia là 0.75 và 0.80.
• Thuật toán nearest-neighbor cơ bản sẽ thản nhiên tuyên bố: "Route chiến thắng là Shipping!" và tống bài thơ vào quy trình tra cứu mã vận đơn.

Hệ thống hoàn toàn không biết rằng nó đang ngoại suy trong vùng không gian rỗng (out-of-distribution).

Giải pháp bắt buộc: Ngưỡng Tương Đồng Tối Thiểu (Cosine Threshold Cutoff)

Để khắc phục bẫy hình học này, một semantic router chuẩn mực bắt buộc phải thiết lập ngưỡng tương đồng tối thiểu (thường dao động từ 0.75 đến 0.82 tùy thuộc vào embedding model):

similarity(query_vector, centroid_vector) >= theta_threshold

• Nếu điểm tương đồng vượt qua ngưỡng: Chấp nhận route và điều hướng.
• Nếu điểm tương đồng nằm dưới ngưỡng: Router coi đây là yêu cầu không xác định (Unknown Intent), từ chối gán bừa và chuyển sang tuyến xử lý dự phòng (General Fallback Handler) hoặc chuyển tiếp cho Classifier LLM thẩm định lại.

Đây là dạng lỗi hình học đặc thù của Semantic Routing: nó không phải là một phán đoán sai có chủ ý như của LLM, mà là một khoảng cách toán học bị ép buộc thành một quyết định thực thi.

Hình dạng chi phí: Phí Token siêu rẻ đối đầu với Hạ tầng Vector

Khi so sánh bài toán kinh tế giữa ba kỹ thuật routing, Semantic Routing sở hữu một cấu trúc chi phí rất khác biệt:

Phân tích kinh tế đơn vị làm sáng tỏ hai khía cạnh:

1. Phí biến đổi (Variable Token Cost) cực thấp: Chi phí mã hóa vector chỉ khoảng $0,00002 trên mỗi request (dùng model như OpenAI text-embedding-3-small với giá $0,02 trên 1 triệu token). Con số này gần như vô hình trên bảng kê chi phí.
2. Phí cố định và hạ tầng (Fixed Infrastructure Cost): Khác với cascading (chỉ dùng code logic if/else) hay classifier router (chỉ gọi 1 API model), semantic router đòi hỏi hạ tầng để lưu trữ và tìm kiếm vector (như Cloudflare Vectorize, Qdrant, Pinecone, hoặc mảng in-memory index HNSW). Dù ở quy mô nhỏ chi phí này không lớn, nó vẫn là một thành phần hạ tầng cần được triển khai và duy trì độ sẵn sàng cao (High Availability).

Mô hình lý tưởng: Kiến trúc lai hai tầng (Hybrid Routing Pipeline)

Tại các hệ thống quy mô hàng triệu request mỗi ngày, các kiến trúc sư không chọn một trong hai, mà phối hợp chúng thành một đường ống tối ưu (Pipeline):

• Tầng 1 - Semantic Filter (6ms, $0,00002): Lọc ngay 60–70% lưu lượng thuộc các nhóm việc thường quy đã rõ chủ đề (tra cứu đơn hàng, chính sách đổi trả, câu hỏi thường gặp) để gửi thẳng vào các Tool chuyên biệt hoặc Model nhỏ được tinh chỉnh (Fine-tuned SLM).
• Tầng 2 - Classifier Triage (120ms, $0,00040): Chỉ kích hoạt khi request rơi vào vùng rủi ro, câu hỏi mơ hồ, hoặc khi cần phân định mức độ phức tạp suy luận trước khi quyết định gọi Frontier Model.

Mô hình lai này mang lại trải nghiệm tối thượng: đa số người dùng nhận phản hồi tức thì với chi phí tối thiểu, trong khi các tác vụ hóc búa vẫn được đảm bảo độ an toàn tuyệt đối.

Bản đồ tổng kết 3 kỹ thuật: Khi nào AI PM nên chọn giải pháp nào?

Khép lại cụm chuyên đề 3 bài viết chuyên sâu về Model Routing, bảng ma trận dưới đây là kim chỉ nam giúp Product Manager và Tech Lead lựa chọn chính xác kỹ thuật cho sản phẩm của mình:

Cầu nối bài học thực chiến: Từ Semantic Routing đến Semantic Caching

Trong Bài 14 của khóa AI Product Management, khi phân tích các đòn bẩy kinh tế để tối ưu hóa chi phí vận hành định kỳ (Token Inference Cost & OpEx), chúng ta đã làm quen với khái niệm Semantic Caching.

Mặc dù Semantic Routing và Semantic Caching phục vụ hai mục đích sản phẩm khác nhau:

• Semantic Routing dùng khoảng cách vector để quyết định model nào sẽ nhận request;
• Semantic Caching dùng khoảng cách vector để tái sử dụng câu trả lời có sẵn, bỏ qua hoàn toàn việc gọi model.

Nhưng cả hai kỹ thuật đều vận hành trên cùng một nền tảng toán học: đo lường độ tương đồng ngữ nghĩa trong không gian embedding. Hiểu rõ cơ chế đặt ngưỡng Cosine, ranh giới trôi dạt dữ liệu và điểm mù độ khó trong bài viết này chính là chìa khóa giúp bạn làm chủ cả hai công cụ tối ưu chi phí mạnh mẽ nhất của một AI Product Manager hiện đại.