Biến LLM thông thường thành mô hình ra quyết định kiểu Jev chỉ với một lượt suy luận

Các mô hình ngôn ngữ lớn (LLM) vốn không được thiết kế để ra quyết định nhanh. Nhưng một nhóm kỹ sư vừa chứng minh rằng chỉ cần một lượt forward pass duy nhất, GLM-5.3-Flash có thể đưa ra quyết định có xác suất cho từng lựa chọn với độ chính xác và tốc độ ngang ngửa Jev của TypeSafe. Điểm thú vị là giải pháp này còn xử lý được cả hình ảnh — điều mà Jev và Laya hoàn toàn không làm được.

Phần lớn những gì phần mềm hỏi LLM thực chất là một quyết định: "Đội nào nên xử lý ticket này?", hay "Điều khoản hợp đồng này có thuộc mục trách nhiệm không?". Trong những trường hợp như vậy, phần mềm thường yêu cầu phản hồi của LLM tuân theo một định dạng nhất định như JSON, và phải nằm trong một tập hợp định sẵn như "có" và "không".

Sơ đồ mô hình quyết định System One với GLM Flash

Bài toán chi phí và tốc độ của cách tiếp cận truyền thống

Với hướng dẫn phù hợp, LLM thường có thể đáp ứng yêu cầu này một cách đáng tin cậy. Tuy nhiên, cách tiếp cận cơ bản lại khiến tốc độ và chi phí trở thành vấn đề lớn: với mỗi quyết định, LLM cần viết ra cả một đối tượng JSON, và một mô hình có khả năng suy luận (reasoning model) có thể "suy nghĩ" hàng trăm token trước khi đưa ra câu trả lời. Ngoài ra, bạn cũng không biết được độ tự tin thực sự của mô hình trừ khi hỏi trực tiếp. Tất cả những yếu tố này khiến LLM chưa thể được ứng dụng rộng rãi cho việc ra quyết định trong các kịch bản khối lượng lớn.

Các mô hình ra quyết định chuyên dụng — hay còn gọi là mô hình "System One" — như Jev và Laya được thiết kế để giải quyết chính xác bài toán này. Bạn truyền vào một trạng thái và một tập lựa chọn có tên, rồi nhận về lựa chọn được chọn kèm giá trị độ tự tin (tức xác suất) cho từng phương án.

Ý tưởng cốt lõi: khai thác phân phối xác suất của token đầu tiên

Điểm mấu chốt cần hiểu về cách LLM hoạt động: mô hình không bao giờ viết văn bản trực tiếp. Từ một prompt, LLM đưa ra phân phối xác suất trên toàn bộ từ vựng token của nó. Trong sinh văn bản thông thường, token có xác suất cao nhất được chọn làm token tiếp theo, rồi được nối vào prompt và toàn bộ quá trình lặp lại. Đây chính là lý do khiến cách làm truyền thống vừa tốn kém vừa chậm chạp nếu bạn chỉ cần điền vài trường vào một đối tượng JSON.

Ý tưởng cốt lõi của nhóm nghiên cứu: không cần để LLM dự đoán cả đối tượng JSON, vì hình dạng của nó đã biết trước. Điều duy nhất ta quan tâm là phán đoán có kiểu (typed judgement) của mô hình cho một đầu vào nhất định.

Có thể thiết kế prompt sao cho phán đoán có kiểu xuất hiện chỉ trong một lần chạy mô hình — không cần tinh chỉnh (fine-tuning), trên đúng phiên bản mô hình được phát hành. Đây chính là điểm khác biệt so với Jev và Laya, vốn là những mô hình được huấn luyện chuyên cho mục đích này.

Các bước cơ bản như sau:

• Đánh số các lựa chọn. Trạng thái, câu hỏi và các lựa chọn đầu ra được đưa vào prompt dưới dạng JSON, mỗi lựa chọn có một chỉ số (index).
• Tiền điền câu trả lời (prefill). Prompt kết thúc bằng choice_index:. Nhờ vậy, token đầu tiên mô hình tạo ra sẽ chính là chỉ số trỏ vào một lựa chọn đã định nghĩa.
• Đọc phân phối xác suất. Thay vì đọc token mô hình phát ra, ta đọc xác suất mà nó gán cho tất cả chỉ số lựa chọn tại vị trí duy nhất đó. Chuẩn hóa trên tập lựa chọn, ta thu được xác suất cho từng câu trả lời và chỉ cần chọn phương án có xác suất cao nhất.

Giao diện playground minh họa quyết định của GLM trên Privatemode

Triển khai thực tế với vLLM và GLM-5.3-Flash

Nhóm nghiên cứu đã hiện thực hóa các bước trên cho GLM-5.3-Flash chạy trên vLLM (trong môi trường Privatemode). Họ sử dụng endpoint /chat/completions với hai tham số continue_final_message và add_generation_prompt: false, nhờ đó mô hình tiếp tục lượt trợ lý đã được tiền điền thay vì bắt đầu lượt mới. Hai tham số này cũng cho phép truyền hình ảnh song song với văn bản — chính là yếu tố mở ra khả năng ra quyết định trên hình ảnh.

Mỗi câu trả lời trở về dưới dạng phân phối xác suất trên các lựa chọn, thường chỉ trong vài trăm mili giây. Phân phối này đặc biệt hữu ích khi cần quyết định có nên đưa con người vào vòng kiểm soát (human-in-the-loop) hay không.

So sánh với Jev và Laya trên 29 bộ dữ liệu

Nhóm nghiên cứu đã xây dựng một benchmark tùy chỉnh và so sánh ba hệ thống trên 29 bộ dữ liệu công khai có nhãn: GLM-5.3-Flash trên Privatemode, Jev của TypeSafe và Laya của Convai. Các bộ dữ liệu có từ 2 đến 151 lựa chọn, bao phủ nhiều tác vụ như định tuyến ý định, phân tích cảm xúc, phân loại chủ đề, kiểm duyệt nội dung, suy luận kéo theo (entailment), hỏi đáp, văn bản pháp lý và tài liệu quét. Corpus bao gồm cả tiếng Anh lẫn tiếng Đức.

Kết quả chính:

• Trên 28 bộ dữ liệu văn bản, GLM-5.3-Flash và Jev ngang nhau. Mỗi hệ thống chính xác hơn trên 10 bộ, 8 bộ còn lại chênh lệch dưới một điểm phần trăm.
• Khoảng cách trung vị là 0,7 điểm phần trăm nghiêng về Jev — không có ý nghĩa thống kê (p = 0,64). Hai hệ thống có độ chính xác tương đương sẽ cho khoảng cách ít nhất như vậy trong khoảng 6 trên 10 lần so sánh, nên đây hoàn toàn nằm trong ngưỡng ngẫu nhiên.
• Laya thấp hơn rõ rệt, với khoảng cách trung vị 13 đến 15 điểm phần trăm (p < 0,001). Đây là mô hình 421 triệu tham số chạy cục bộ.

Đáng chú ý, số lượng lựa chọn ảnh hưởng đến độ chính xác nhiều hơn là việc chọn Jev hay GLM-5.3-Flash. Trên bộ TREC, khi tăng từ 6 lên 42 lựa chọn, Jev giảm từ 92,1% xuống 85,6%, GLM-5.3-Flash từ 91,2% xuống 79,6%, còn Laya rơi từ 88,4% xuống 51,2%.

Tốc độ và chi phí: điểm yếu của giải pháp mới

Về độ trễ, nhóm nghiên cứu đo riêng lẻ từng request một vì thời gian đo dưới tải phản ánh hàng đợi chứ không phải mô hình. Do Privatemode đặt tại EU còn Jev đặt tại Mỹ, họ chạy bốn bộ dữ liệu đồng thời từ Đức và từ Mỹ. Từ Đức, Privatemode trả lời trong 180 ms, Jev trong 264 ms. Từ Mỹ, thứ tự đảo ngược: 164 ms cho Jev so với 299 ms cho Privatemode.

Về chi phí, Jev rẻ hơn đáng kể: một triệu quyết định tốn khoảng 62 EUR với GLM-5.3-Flash và khoảng 16 EUR với Jev, theo giá niêm yết của mỗi dịch vụ. Phần lớn chênh lệch đến từ giá mỗi token đầu vào. Jev thêm khoảng 270 token cố định và khoảng 10 token mỗi lựa chọn, trong khi prompt GLM-5.3-Flash thêm khoảng 55 token cố định và khoảng 20 token mỗi lựa chọn. Dưới khoảng 21 lựa chọn, GLM-5.3-Flash gửi ít token hơn Jev; trên ngưỡng đó thì ngược lại.

Lợi thế độc quyền: quyết định trên hình ảnh

Khác biệt lớn nhất nằm ở khả năng xử lý đầu vào phi văn bản. GLM-5.3-Flash là mô hình có khả năng thị giác, nên câu hỏi có thể đi kèm hình ảnh như hóa đơn quét, ảnh bưu kiện hư hỏng hay ảnh chụp màn hình. Hình ảnh đi vào cùng một prompt, và câu trả lời vẫn là một token duy nhất với xác suất cho từng lựa chọn.

Theo tài liệu của mình, Jev chỉ hoạt động trên văn bản, còn Laya là bộ mã hóa văn bản, nên cả hai đều không nhận hình ảnh đầu vào. Trên bộ RVL-CDIP gồm 1.600 tài liệu doanh nghiệp được quét thuộc 16 lớp, GLM-5.3-Flash đạt độ chính xác 70,2% và là hệ thống duy nhất trong ba hệ thống có thể trả lời.

Tuy nhiên, chi phí cho tài liệu cao hơn hẳn câu văn: hình ảnh thêm khoảng 1.350 token đầu vào, nên một triệu quyết định trên tài liệu tốn khoảng 270 EUR.

Giới hạn và những lưu ý kỹ thuật

Khi số lựa chọn tăng cao, mỗi hệ thống đều chạm trần. Tên lựa chọn của Laya chia sẻ ngân sách 192 token — đủ cho 77 ý định của banking77 nhưng không đủ cho 151 ý định của CLINC150. Trong khi đó, triển khai GLM-5.3-Flash trên Privatemode chỉ báo tối đa 128 mục trong logprob_token_ids, buộc thư viện phải gửi câu hỏi có 151 lựa chọn hai lần giống hệt nhau: đọc xác suất của 128 lựa chọn từ phản hồi đầu và 23 lựa chọn còn lại từ phản hồi sau. Trên CLINC150, GLM-5.3-Flash đạt 87,5% theo cách này, so với 78,4% của Jev — nhưng mỗi quyết định tốn 719 ms thay vì 249 ms.

Một số phát hiện thú vị khác:

• Suy luận giúp tăng độ chính xác nhưng đắt đỏ. Khi cho GLM-5.3-Flash suy luận trước khi trả lời, độ chính xác tăng ở mọi dải số lựa chọn, nhưng chi phí vọt lên khoảng 350 EUR mỗi triệu quyết định so với 62 EUR.
• So khớp embedding đơn thuần chỉ đạt từ 45,9% đến 72,8% tùy dải, cho thấy vai trò cần thiết của mô hình ra quyết định.
• Đổi tên lựa chọn ảnh hưởng khác nhau. Trên boolq, khi đổi "true/false" thành "correct/wrong", GLM-5.3-Flash mất 20 điểm trong khi hai hệ thống kia mất dưới 3 điểm.
• Một phần lỗi nằm ở nhãn dữ liệu. Khoảng 17% ví dụ của banking77 thuộc dạng có hai đáp án đều hợp lý, nên điểm tối đa khả thi ở đó chỉ khoảng 85% thay vì 100%.

Bảo mật và khả năng tái lập

Thư viện của nhóm được viết bằng Python và hoạt động với mọi endpoint hỗ trợ vLLM, dựa trên các phần mở rộng của vLLM cho OpenAI API như allowed_token_ids và logprob_token_ids. Repository benchmark chứa đầy đủ phương pháp luận, đặc tả bộ dữ liệu, harness kiểm thử, phần tổng hợp và mọi lần chạy thô, cho phép tái lập toàn bộ số liệu trong bài mà không cần chạy lại.

Với Privatemode, các quyết định này được bảo vệ bằng điện toán mật (confidential computing): dữ liệu vẫn được mã hóa trong bộ nhớ ngay cả trong quá trình xử lý, và phía client xác minh báo cáo chứng thực (attestation report) của triển khai trước khi gửi bất cứ thứ gì.

Cách tiếp cận này cho thấy LLM phổ thông có thể đảm nhận vai trò mô hình ra quyết định chuyên dụng mà không cần huấn luyện lại — mở ra hướng ứng dụng mới cho các hệ thống cần ra quyết định khối lượng lớn, đặc biệt khi đầu vào là hình ảnh.

Đối với các nhà phát triển tại Việt Nam đang cân nhắc tích hợp ra quyết định tự động vào sản phẩm, đây là một lựa chọn đáng tham khảo: chi phí cao hơn Jev nhưng đổi lại là khả năng xử lý đa phương thức và tính linh hoạt của một LLM thông thường, cùng lớp bảo vệ dữ liệu phù hợp với các yêu cầu tuân thủ ngày càng chặt chẽ.