BDSGPHẠM VĂN THƯNHÀ SÁNG LẬP BDSG
ENTài khoản
Kết nối
Menu
Trí tuệ nhân tạo AI · Nội dung có hỗ trợ AI

Định tuyến mô hình AI: chọn theo việc, kiểm đường chuyển

Đăng ngày 27/10/2026

Mục lục bài nghiên cứu
Định tuyến mô hình AI: chọn theo việc, kiểm đường chuyển

Định tuyến mô hình AI phải giữ được công việc khi chọn sai

Định tuyến mô hình AI là chọn đường xử lý cho một yêu cầu, dựa trên mục tiêu chất lượng, tài nguyên và giới hạn đã đặt. Quyết định ấy có thể sai: gửi việc đơn giản tới mô hình đắt hơn, hoặc gửi việc khó tới mô hình chưa đủ khả năng. Hệ thống cần nhận biết kết quả chưa dùng được và giữ một đường xử lý tiếp. Giá trị của bộ chọn phải được đánh giá cùng tầng kiểm, hàng chờ và người tiếp nhận, thay vì chỉ đếm số lần dùng mô hình nhỏ.

Bài dùng tình huống giả định một chuỗi phân phối tại Việt Nam nhận nhiều ghi chú xin đổi lịch giao. Có ghi chú chỉ cần nhận diện mã đơn, có yêu cầu phải đối chiếu nhiều thông báo và có việc cần người có thẩm quyền xác nhận. Trợ lý chỉ phân loại, tra cứu được phép và chuẩn bị nháp nội bộ. Nó không tự hứa lịch mới với khách. Công cụ đề xuất là sổ chuyển tuyến ghi lý do chọn, kết quả kiểm và trạng thái bàn giao.

RouteLLM nghiên cứu cách học bộ chọn từ dữ liệu so sánh sự ưa thích giữa câu trả lời, rồi chọn một trong hai nhóm mô hình trước khi sinh kết quả. FrugalGPT lại có cơ chế gọi tuần tự, chấm kết quả rồi quyết định dừng hoặc gọi tiếp. Cả hai cung cấp hướng thiết kế đáng xem, nhưng là những cấu hình nghiên cứu có dữ liệu và tiêu chí riêng. Không thể chuyển kết quả tiết kiệm của chúng thành cam kết cho chuỗi phân phối giả định[1][2].

Chia đường theo việc có thể quan sát và kiểm

Trước khi học một bộ chọn phức tạp, hãy mô tả những việc thực sự đi qua hệ thống. Một ghi chú có mã đơn hợp lệ và hỏi tình trạng hiện tại có thể đi qua tra cứu có quyền. Một nội dung cần gán nhãn trong danh mục đã chốt có thể thử mô hình gọn. Một yêu cầu đối chiếu các lần thay lịch cần phép xử lý khác. Nội dung thiếu mã đơn hoặc yêu cầu cam kết vẫn cần hỏi lại hoặc chuyển người, bất kể mô hình nào đang sẵn.

Điều kiện đầu vào nên quan sát được: có mã định danh hay chưa, nguồn nào được dùng, có mâu thuẫn cần giải quyết không và đầu ra cần điền những trường nào. Độ dài câu chỉ là một tín hiệu có thể thử, chưa định nghĩa độ khó. “Không đổi lịch” là một câu ngắn nhưng một từ phủ định có thể quyết định toàn bộ nhãn. Ngược lại, một ghi chú dài lặp thông tin có thể vẫn là việc đơn giản sau khi tách phần dư.

Trong Hybrid LLM, truy vấn “dễ” được định nghĩa theo mức chênh lệch chất lượng giữa hai mô hình, không đồng nhất với việc câu ngắn hoặc xử lý rẻ. Nghiên cứu dùng thước đo chất lượng riêng và đánh giá trên tập chỉ dẫn đã chọn. Cách định nghĩa nhắc rằng độ khó luôn liên quan tới ứng viên cùng tiêu chí chấm. Doanh nghiệp cần xác định “đủ dùng cho trường việc này” bằng phép kiểm nghiệp vụ, thay cho một nhãn dễ chung chung[3].

Bốn đường xử lý yêu cầu phân phối theo phạm vi công việc và điều kiện dữ liệu
Hình 1. Tra cứu, mô hình theo phạm vi và chuyển người là các lựa chọn riêng trong đường xử lý.

Độ khó và hậu quả phải được ghi thành hai câu hỏi

Độ khó nói về khả năng xử lý đúng với dữ liệu và mô hình đang có. Hậu quả nói về chuyện gì xảy ra nếu kết quả sai được dùng. Một việc dễ trích số nhưng liên quan cam kết giao hàng vẫn có thể cần kiểm chặt. Một bản tóm tắt phức tạp để đọc nội bộ có thể chỉ cần giữ nhãn nháp cùng nguồn. Nếu trộn hai câu hỏi, bộ chọn có thể đưa việc có hậu quả lớn vào đường ít kiểm chỉ vì nó thấy câu hỏi quen.

Trong ca giả định, trích một mã đơn từ ghi chú khác với xác nhận khách đã đồng ý lịch thay thế. Phần đầu có thể đối chiếu bằng ký tự và danh mục; phần sau cần bằng chứng tương ứng cùng thẩm quyền. Đưa cả hai sang mô hình lớn hơn không tạo ra sự đồng ý còn thiếu. Vì vậy, sổ tuyến nên có cột loại việc và cột điều kiện được phép sử dụng kết quả. Hai cột này giữ vai trò khác nhau khi người vận hành xem lại lỗi.

Một quy tắc đề xuất là xác định trước các đường bị chặn theo quyền, độ mới và mức tác động. Bộ chọn chỉ tối ưu giữa những đường còn được phép. Nếu dữ liệu không được đưa ra một nơi phục vụ, đường đó phải bị loại trước khi xét điểm mô hình. Nếu kết quả chuẩn bị thành cam kết, nó cần bước duyệt tương ứng sau xử lý. Không để một điểm dự đoán chất lượng được diễn giải thành quyền truy cập hoặc quyền thực hiện công việc.

Chọn trước khi sinh cần biết tín hiệu dự đoán điều gì

Một bộ chọn trước có thể dùng quy tắc, đặc trưng yêu cầu hoặc mô hình được học từ các ca đã chấm. Nó cần dự đoán lợi ích của việc dùng ứng viên khác trong phạm vi nhiệm vụ. Điểm ấy không tự là xác suất toàn bộ câu trả lời sẽ đúng. Nếu dữ liệu học chủ yếu phản ánh người dùng thích cách trình bày nào, bộ chọn có thể học sở thích hơn là khả năng giữ mã đơn. Nhãn huấn luyện phải phù hợp điều mà doanh nghiệp muốn quyết định.

RouteLLM đặt bài toán dự đoán ứng viên mạnh hơn có được ưa thích hơn ứng viên kia cho một truy vấn hay không, rồi áp ngưỡng để chọn đường. Cấu hình đó khác với chấm câu trả lời sau khi đã thấy nó. Khi áp dụng ý tưởng, nhóm cần ghi rõ đầu vào của bộ chọn và ý nghĩa điểm trả về. Không dùng một điểm thắng tương đối làm bằng chứng rằng đầu ra đạt mọi quy tắc nghiệp vụ hoặc không cần người kiểm[1].

Sổ chuyển tuyến nên giữ phiên bản quy tắc hoặc bộ chọn, tín hiệu dùng và lý do chặn các đường không đủ điều kiện. Khi một ca bị chuyển sai, nhóm có thể hỏi do nhận diện loại việc, do ứng viên hoặc do phép chấm. Nếu chỉ lưu tên mô hình cuối, rất khó tách nguyên nhân. Điều này cũng giúp người quản lý biết một lần cải thiện đến từ chọn đường tốt hơn hay đơn giản từ việc đưa thêm nguồn chính xác vào đầu vào.

Chạy theo tầng cần một lý do để dừng hoặc chuyển tiếp

Ở cách chạy theo tầng, hệ thống có thể thử một mô hình rồi kiểm kết quả trước khi gọi ứng viên tiếp. FrugalGPT mô tả bộ chấm nhận truy vấn cùng câu trả lời, dùng điểm chất lượng và ngưỡng dừng trong một chuỗi có giới hạn. Cơ chế ấy cần cả chất lượng bộ chấm lẫn cấu hình chuỗi. Nó không có nghĩa mọi phản hồi tự xưng chắc chắn đều đủ để dừng, hoặc cứ gọi thêm mô hình là chất lượng sẽ tăng[2].

Nghiên cứu hai tầng của Ramírez và cộng sự xem xét tín hiệu bất định từ kết quả của mô hình nhỏ, trong các nhiệm vụ sinh ngắn như phân loại, trắc nghiệm và trả lời câu hỏi. Phạm vi nghiên cứu không gồm toàn bộ sinh văn bản dài. Đây là một lựa chọn tín hiệu để kiểm, không phải quy tắc mặc định cho mọi ứng dụng. Với ghi chú phân phối nhiều nguồn, doanh nghiệp vẫn phải xây phép đánh giá phù hợp đầu ra cần dùng[4].

Trong đường giả định, chuyển tiếp chỉ có ý nghĩa nếu ứng viên tiếp có cơ hội giải quyết nguyên nhân thất bại. Nếu thiếu mã đơn, cần hỏi thêm dữ liệu. Nếu nguồn mâu thuẫn, cần người xác định bản có hiệu lực. Nếu mô hình không giữ được cấu trúc dù đầu vào đủ, có thể thử ứng viên khác trong ngân sách cho phép. Mỗi lần chuyển phải giữ cùng mã việc và trạng thái, tránh biến một yêu cầu chưa xong thành nhiều công việc độc lập.

Quy trình chọn đường, kiểm kết quả và chuyển có giới hạn cho yêu cầu đổi lịch giao
Hình 2. Xác định nguyên nhân thất bại trước khi chọn gọi thêm, hỏi lại hoặc chuyển người.

Dùng độ tự tin sau khi hiểu giới hạn của nó

Độ tự tin tự khai không nên bị coi là vô dụng trong mọi trường hợp, cũng không nên được tin ngay. Nghiên cứu Just Ask for Calibration tìm thấy cách hỏi để mô hình diễn đạt mức tin cậy có thể cải thiện hiệu chuẩn trong những bộ câu hỏi và mô hình được thử. Tác giả cũng giới hạn kết luận ở các nhiệm vụ nhớ lại thông tin, câu trả lời ngắn và nêu vấn đề phụ thuộc lời yêu cầu, miền dữ liệu. Tín hiệu cần được đối chiếu trước khi làm ngưỡng tuyến[5].

Nếu muốn dùng điểm tự tin cho phân loại ghi chú, nhóm cần xem những ca có điểm tương tự thực tế đúng sai ra sao trên dữ liệu chưa dùng để chỉnh. Kiểm riêng câu phủ định, mã hiếm và ghi chú thiếu thông tin. Một điểm được hiệu chỉnh cho bộ nhãn cũ chưa tự giữ nghĩa khi thêm nhãn mới hoặc đổi mô hình. Không dùng câu “tôi chắc chắn” làm một bằng chứng độc lập với chính câu trả lời mà mô hình vừa tạo.

Có thể phối hợp tín hiệu tự tin với những kiểm tra quan sát được: mã đơn tồn tại trong nguồn được phép, trường bắt buộc có đủ và căn cứ được dẫn đúng. Nếu tín hiệu mâu thuẫn, đường xử lý nên giữ trạng thái cần xem lại. Việc chọn ngưỡng cần bám hậu quả chấp nhận nhầm và chi phí chuyển không cần thiết. Một ngưỡng chung cho mọi loại yêu cầu sẽ che khác biệt giữa phân loại ghi chú nội bộ và chuẩn bị một thông báo có thể gửi ra ngoài.

Tầng kiểm không được lặp lại cùng một nhận định

Tầng kiểm nên có phần độc lập với khả năng viết của mô hình tạo. Với mã đơn, có thể đối chiếu ký tự và nguồn; với trường lịch, kiểm có thời điểm và trạng thái xác nhận phù hợp; với phân loại, so nhãn theo hướng dẫn đã chốt. Câu văn trôi chảy không vượt qua những kiểm ấy thay cho dữ kiện. Nếu một kết quả thất bại ở điều kiện quyết định, phải giữ nguyên lý do lỗi để người tiếp nhận biết cần sửa chỗ nào.

Dùng một mô hình làm người chấm có thể hỗ trợ xem đầu ra mở, nhưng cũng cần kiểm người chấm. Nghiên cứu MT-Bench và Chatbot Arena phân tích thiên lệch theo vị trí, độ dài, sự thiên vị bản thân và giới hạn suy luận. Các biện pháp như đổi thứ tự có thể giảm một số lệch; nhất quán vẫn chưa đồng nghĩa chính xác. Không để mô hình tạo và mô hình chấm cùng đồng ý thay cho đối chiếu mã đơn hoặc bằng chứng lịch đã được xác nhận[6].

Trong bộ kiểm kín, nên có cả phản hồi nghe hợp lý nhưng sai một trường quan trọng. Người chấm phải chỉ ra trường sai và căn cứ, không chỉ cho điểm ưa thích chung. Những ca mà hai cách kiểm bất đồng cần được xem riêng. Nếu chỉnh người chấm, phải kiểm lại đường chuyển vì ngưỡng dừng phụ thuộc nó. Một thay đổi làm người chấm dễ hài lòng có thể giảm số chuyển tầng mà không cải thiện kết quả thực sự tới tay nhân viên.

Tính tổng chi trên công việc hoàn thành theo điều kiện

Trong Hybrid LLM, một thước đo lợi thế chi phí là tỷ lệ truy vấn được đưa sang mô hình nhỏ, dưới giả định hiệu quả của tổ hợp nghiên cứu. Nó không trực tiếp là hóa đơn hoặc thời gian nhân viên. Khi lập hồ sơ doanh nghiệp, cần tách tỷ lệ chọn đường khỏi chi phí đã đo. Giá gọi, độ dài đầu vào, bộ chọn, tầng kiểm và các lần gọi thêm đều có thể làm tổng chi thay đổi theo cách khác[3].

Sổ chi đề xuất ghi tài nguyên của từng lần xử lý, số lần thử lại, thời gian chờ và công sức sửa tới khi đạt điều kiện bàn giao. Những yêu cầu bị dừng hoặc chuyển người vẫn phải hiện trong báo cáo, không bị loại khỏi mẫu để chi phí trông thấp. Có thể báo riêng chi phí phát sinh trên yêu cầu nhận vào và chi phí trên công việc đã hoàn tất. Khi chưa có đủ dữ liệu, chỉ báo các thành phần quan sát được cùng phần còn thiếu.

Cần so với đường nền hợp lý, chẳng hạn tra cứu có cấu trúc hoặc nhân viên phân loại bằng biểu mẫu. Nếu thêm bộ chọn cùng mô hình chấm cho một nhiệm vụ vốn giải được bằng danh mục nhỏ, phần điều phối có thể nhiều hơn phần sinh. Ngược lại, nếu nhiều loại việc có nhu cầu khác nhau, tách đường có thể đáng thử. Bài không đưa tỷ lệ tiết kiệm giả định; quyết định đầu tư chỉ nên dựa trên phép đo cùng phạm vi và cùng tiêu chí hoàn thành.

Đo chờ, xử lý và chất lượng ở những nơi khác nhau

Tài liệu vLLM tách các chỉ số hàng chờ, suy luận, thời gian toàn yêu cầu, thời điểm có token đầu và số yêu cầu xử lý thành công. Các chỉ số phản ánh phần phục vụ kỹ thuật, không tự đánh giá đầu ra đúng nghiệp vụ. Một yêu cầu được xử lý thành công có thể vẫn bị nhân viên từ chối vì sai mã. Hệ thống cần nối nhật ký kỹ thuật với kết quả kiểm bằng mã việc, đồng thời giữ giới hạn dữ liệu phù hợp[7].

Ở chuỗi phân phối, nên đo từ lúc nhân viên gửi ghi chú tới lúc có nháp dùng được hoặc thông báo hỏi lại rõ ràng. Thời gian thấy ký tự đầu tiên chỉ giải thích một phần trải nghiệm. Nếu nháp xuất hiện nhanh nhưng người dùng chờ lâu để kiểm nguồn, cần cải thiện toàn đường xử lý. Báo cáo cũng nên tách công việc thường gặp với những ca chờ dài, không chỉ trình một số trung bình làm mất nhóm người dùng bị ảnh hưởng.

Các mốc đo cần cùng định nghĩa và được gắn cấu hình đang chạy. Khi đổi mô hình hoặc tầng kiểm, xem cả độ đúng, hàng chờ và số lần chuyển. Không suy từ việc giảm lượt tới một mô hình rằng mọi nút đều bớt tải. Chính bộ chọn, nơi tra cứu hoặc hàng chờ người duyệt có thể trở thành điểm nghẽn. Cần quan sát từng phần đủ để xác định nơi chậm, rồi đối chiếu với kết quả mà nhân viên thực sự nhận.

Giữ đường xử lý khi bộ chọn sai hoặc nơi phục vụ quá tải

Hướng dẫn xử lý quá tải của Google SRE nhấn mạnh các yêu cầu có thể tiêu thụ tài nguyên rất khác nhau, nên số truy vấn mỗi giây chưa đủ mô tả năng lực. Tài liệu cũng bàn giới hạn phía khách và việc chính phản hồi từ chối vẫn tiêu tốn tài nguyên. Đây là nguyên tắc vận hành hệ phân tán, không phải kết quả thử LLM cho chuỗi phân phối. Nó gợi lý do phải quản lý hàng chờ và số lần gọi tiếp[8].

Một đường dự phòng cần được phép dùng cùng dữ liệu và đáp ứng điều kiện tối thiểu. Khi mô hình phân tích bận, không âm thầm trả nháp ít kiểm rồi gắn trạng thái hoàn tất. Có thể giữ hàng chờ, thông báo thời điểm cần người xem hoặc quay về tra cứu đã kiểm trong phạm vi hẹp. Lựa chọn nào cần được thiết kế trước. Mô hình nhỏ không phải đường dự phòng hợp lệ cho mọi việc chỉ vì nó còn phản hồi nhanh.

Ngân sách cho một mã việc nên gồm thời gian, lượt xử lý và điểm chuyển người. Khi đã hết giới hạn, hệ thống giữ bản gốc cùng lý do dừng thay vì gọi vòng qua các mô hình. Nếu bộ chọn gặp nội dung ngoài phạm vi đã thử, cần một tuyến chưa biết. Người quản lý phải thấy số ca chưa biết và năng lực của hàng chờ tiếp nhận. Chuyển người chỉ có ý nghĩa khi có người nhận, đủ thông tin và một cách theo dõi tới lúc xử lý xong.

Sáu mục cần giữ trong sổ chuyển tuyến của yêu cầu phân phối
Hình 3. Sổ chuyển tuyến nối loại việc, quyền, lý do chọn, lỗi kiểm, ngân sách và trạng thái bàn giao.

Thử có đối chứng và mở từng phạm vi công việc

Bộ ca nên tách thành phần dùng để điều chỉnh bộ chọn và phần kiểm cuối chưa mở đáp án trước. Mỗi ca giữ kết quả của các đường nền, các ứng viên và tầng kiểm để nhìn ra chọn sai theo hai hướng. Có ca mô hình gọn đủ dùng nhưng bị chuyển thêm; có ca đáng chuyển lại bị giữ ở đường không đạt. Cần xem những lỗi này theo loại việc và hậu quả, thay vì chỉ tính bao nhiêu lượt được gán đúng tên mô hình.

Trước khi dùng kết quả thật, nhóm có thể đề xuất chạy quan sát song song mà chưa tác động tới nghiệp vụ, trên dữ liệu đã được phép. Người kiểm vẫn dùng đường hiện tại để giải quyết công việc. Ghi nhận chênh lệch mà không gọi đó là hiệu quả đã đạt cho đến khi phép thử có thiết kế và dữ liệu đầy đủ. Bài chỉ mô tả phương án kiểm, chưa thực hiện chạy quan sát hoặc thử trên khách hàng nào.

Nếu đủ bằng chứng, quyết định mở chỉ nên nêu đúng nhóm việc đã kiểm và người phụ trách theo dõi. Khi danh mục nhãn, dữ liệu, mô hình, bộ chọn hoặc tầng chấm đổi, cần biết bộ ca nào phải chạy lại. Tổ chức nhỏ có thể bắt đầu bằng các quy tắc rõ trước khi học bộ chọn. Tổ chức có nhiều nhóm cần giữ trách nhiệm chung cho kết quả bàn giao; không để mỗi bộ phận tối ưu chỉ số riêng khiến cả chuỗi tốn thêm việc sửa.

Hỏi đáp về chọn mô hình nhỏ, lớn và chuyển tuyến

Có phải mô hình lớn luôn là tuyến cuối đúng hơn không? Không; ứng viên lớn hơn vẫn có thể thiếu nguồn, hiểu sai dữ kiện hoặc không được phép nhận dữ liệu đó. Tuyến cuối cần được định nghĩa bằng điều kiện bàn giao, có thể là hỏi lại hoặc người xử lý. Chỉ gọi thêm khi có lý do ứng viên tiếp giải quyết được nguyên nhân thất bại. Nếu thiếu xác nhận lịch, tăng năng lực suy luận không tạo ra xác nhận ấy.

Có cần học một bộ chọn ngay từ đầu không? Không; với ít loại việc và quy tắc rõ, phân luồng xác định trước có thể là đường nền hữu ích. Học bộ chọn chỉ đáng thử khi có dữ liệu chấm phù hợp, ứng viên khác nhau và lợi ích đủ bù phần điều phối. Dù dùng cách nào, phải giữ lý do chọn cùng phép kiểm kết quả. Bài không có dữ liệu đo để kết luận một công nghệ bộ chọn cụ thể phù hợp mọi doanh nghiệp.

Tỷ lệ chuyển sang mô hình lớn giảm có chứng minh tiết kiệm không? Chưa; cần tính thêm bộ chọn, tầng kiểm, thử lại, chờ và công sức sửa tới khi hoàn tất. Đồng thời phải xem có tăng ca sai bị chấp nhận hoặc ca bị bỏ dở không. Một báo cáo hữu ích giữ cả yêu cầu nhận vào, công việc đạt điều kiện và công việc còn chờ. Không loại những ca thất bại khỏi mẫu chỉ để chi phí bình quân nhìn thấp hơn.

Có thể dùng mức tự tin để tự động chấp nhận kết quả không? Chỉ nên xem xét trong phạm vi đã đối chiếu tín hiệu với đúng sai thực tế và có tầng kiểm phù hợp. Nghiên cứu hiệu chuẩn có kết quả tích cực trong một số thiết lập, đồng thời nêu giới hạn về miền và kiểu câu trả lời. Khi đổi mô hình, lời yêu cầu hoặc danh mục nhãn, cần xem lại tín hiệu. Điểm tự tin chưa được kiểm không thay căn cứ nghiệp vụ hoặc quyền duyệt.

Nguồn, phương pháp và giới hạn suy luận

Bài được biên soạn có hỗ trợ AI từ tám nguồn gốc mở đọc ngày 27/10/2026, gồm sáu nghiên cứu và hai tài liệu vận hành, trong phạm vi ghi tại hồ sơ nguồn. Các nghiên cứu dùng mô hình, dữ liệu, thước đo và cấu hình lịch sử riêng; bài giữ cơ chế cùng giới hạn, không chuyển tỷ lệ tiết kiệm hoặc độ đúng sang doanh nghiệp Việt Nam. Tài liệu Google SRE và vLLM là nguồn kỹ thuật của bên phát triển hoặc hệ sinh thái, chưa phải kiểm chứng độc lập hệ thống giả định.

Sổ chuyển tuyến và các quy tắc công việc là đề xuất phân tích của bài. Chuỗi phân phối, ghi chú đổi lịch và các đường xử lý đều giả định; chưa gọi mô hình, chạy tải, thử doanh nghiệp hay đo hiệu quả nhân sự. Chưa tái lập các thí nghiệm nghiên cứu hoặc có thẩm định chuyên gia. Trước triển khai, cần đối chiếu phiên bản, điều kiện dữ liệu, chất lượng tầng kiểm và năng lực tiếp nhận ca chuyển; bài không xác nhận tính tuân thủ pháp lý của một cấu hình cụ thể.