Tác giả: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev là một mô hình dùng để đưa ra các quyết định đã được định kiểu (typed decisions). Bạn gửi cho nó ngữ cảnh cùng một tập hợp cố định các câu hỏi và lựa chọn, sau đó nó sẽ trả về các quyết định, điểm số và xác suất thay vì sinh ra văn bản. Đây chính là một mô hình “System One”!
Nhưng phân loại vốn chẳng phải điều mới mẻ, cũng giống như structured output, các mô hình nhỏ hay việc đọc xác suất từ logits. Chính lịch sử này đã phần nào giải thích những phản ứng trái chiều dành cho Jev...
Những người hoài nghi có lý của họ, nhưng Jev vẫn thực sự có chỗ đứng trong hệ sinh thái này. Để hiểu rõ hơn, chúng ta nên phác họa toàn bộ không gian giải pháp.
Có những lựa chọn thay thế nào?
Khi một hệ thống cần nhãn, điểm số hoặc câu trả lời có/không, có bốn phương án hợp lý:
Phương pháp
Lý do nên dùng
Đánh đổi
Một LLM đa dụng
Zero-shot, linh hoạt, đồng thời có thể sinh ra lập luận hoặc lời giải thích. Có thể coi là “thông minh hơn” nhờ compute tại thời điểm suy luận (reasoning).
Phải chịu độ trễ và chi phí của mô hình autoregressive chỉ cho một quyết định nhỏ
Một trình phân loại zero-shot mã nguồn mở
Rẻ, chạy local và dễ kiểm soát
Chất lượng không ổn định; bạn phải tự lo việc chọn mô hình và triển khai serving
Một trình phân loại đã fine-tune
Thường là lựa chọn tốt nhất cho các tác vụ ổn định, khối lượng lớn và có nhãn chất lượng
Phải thu thập dữ liệu, huấn luyện, triển khai, xử lý data drift và hệ thống phân loại kém linh hoạt hơn
Jev
Sự linh hoạt của zero-shot đằng sau một API hosted gọn gàng
Chất lượng phụ thuộc vào tác vụ, không sinh văn bản và phụ thuộc vào nhà cung cấp
Lợi thế của Jev: một đội ngũ có thể thay đổi câu hỏi và các lựa chọn mà không cần thu thập tập dữ liệu huấn luyện mới, đồng thời tránh được công sức vận hành serving mô hình sao cho chuẩn chỉnh. Chẳng ai nên xem nhẹ điều đó. Câu nói “Chúng tôi tự build cũng được” luôn đúng với hầu hết các sản phẩm hạ tầng.
Các bản tái hiện mã nguồn mở giúp giữ cho tuyên bố về tính mới mẻ ở mức thực tế. Những bản triển khai bằng Qwen và SGLang, DiffusionGemma và vLLM, cùng Kev đã tái tạo lại phần lớn cấu trúc API hoặc mô hình.
85.7% đối với Jev và 79.6% đối với Kev-8B trên n=764
Các bài kiểm thử độc lập của Parallel cũng cho thấy Jev rất cạnh tranh ở tác vụ reranking, trong khi các mô hình chuyên biệt vẫn chiến thắng ở hai tác vụ phân loại.
Những gì chúng tôi quan sát được tại Glean
Điều đó dẫn đến một câu hỏi thực tế: khi nào thì sự kết hợp giữa tính linh hoạt zero-shot và inference hosted của Jev thực sự vượt trội hơn các phương án khác? Chúng tôi đã thử nghiệm bốn quyết định giới hạn (bounded decision) tại Glean — nơi đã có sẵn baseline để so sánh chất lượng thực tế trong môi trường doanh nghiệp. Phần lớn các baseline này đều là hệ thống dựa trên LLM, nên với những thử nghiệm đó, chúng tôi kỳ vọng mức cải thiện gấp khoảng 100 lần về cả chi phí lẫn độ trễ. Kết quả dao động từ mức kém hơn đáng kể so với production cho đến nhanh hơn và chính xác hơn hẳn một router dùng LLM.
Phân loại truy vấn (Query classification)
Phân loại truy vấn là việc ánh xạ một request tới một tác vụ tổng quát để các hệ thống phía sau xử lý. Đây là workload cực kỳ phù hợp với Jev, bởi dù ở từng request riêng lẻ thì không gian nhãn đã được biết trước, hệ thống phân loại vẫn có thể thay đổi nhanh hơn tốc độ retrain một mô hình đã fine-tune.
Trong thử nghiệm này, chúng tôi tập trung đo lường mức độ đồng thuận của Jev so với dự đoán từ hệ thống production / baseline (vốn dùng LLM). Chúng tôi kỳ vọng và đã quan sát thấy tốc độ throughput offline tăng mạnh khi dùng Jev, nên dùng tỷ lệ đồng thuận làm thước đo đại diện đơn giản cho chất lượng. Chúng tôi cũng so sánh với Laya — một mô hình ra quyết định open-weight — và một phiên bản Laya đã fine-tune. Quá trình fine-tune này chỉ mất vài giờ chạy local, và mô hình đủ nhỏ để serving ngay trên máy của developer.
Thử nghiệm
Mức độ đồng thuận tác vụ tổng quát
Hiệu năng
Jev zero-shot
66.8%
~
12 phút (concurrency = 4
)
Laya gốc
35.9%
~
90 giây (máy dev local)
Laya đã fine-tune
74.5%
~
90 giây (máy dev local)
Là một mô hình có sẵn tiện lợi, không cần huấn luyện, Jev rõ ràng vượt trội hơn Laya gốc. Nhưng không quá bất ngờ khi fine-tune lại giúp Laya tỏa sáng, đặc biệt nếu nhìn vào các con số hiệu năng. Sự đánh đổi nằm ở công sức thu thập nhãn chất lượng và thiết lập pipeline huấn luyện. Jev có lẽ vẫn hấp dẫn hơn khi tác vụ còn mới hoặc nhãn liên tục thay đổi.
Định tuyến mô hình: expert transfer
Định tuyến mô hình (model routing) là bài toán có liên quan mật thiết đến phân loại truy vấn. Ở đây, chúng tôi đặt model routing dưới góc độ expert transfer, tức là hệ thống sẽ chọn expert / model nào để xử lý request. Baseline production hiện tại đang yêu cầu một LLM tự đưa ra quyết định đó ngay bên trong agentic loop của harness. Dù đây là phép thử tự nhiên để xem Jev có thể thay thế một lệnh gọi generative bằng một quyết định giới hạn hay không, một hạn chế kỹ thuật quan trọng là Jev chắc chắn sẽ thêm một lệnh gọi trong trường hợp không cần transfer. Điều này trái ngược với baseline production — vốn có thể bắt đầu luôn việc gọi tool ngay từ lệnh gọi LLM đầu tiên duy nhất nếu không cần transfer.
Chúng tôi dùng một phiên bản đơn giản hóa của luồng routing production với chỉ 3 expert, chạy lại 751 bản ghi golden tương đồng qua router Jev mới, so sánh tuyến đường nó chọn với router dựa trên prompt hiện tại (chạy bằng một LLM truyền thống) và đo độ chính xác so với nhãn golden.
Chúng tôi cũng tách riêng 40 bản ghi mà luồng cũ thực sự phát sinh lệnh gọi expert-transfer (n nhỏ hơn) để so sánh độ trễ trên chính những bản ghi đó.
Tốc độ xử lý trung vị trên mỗi bản ghi nhanh hơn 8.1×. Đây là một trong những kết quả nội bộ ấn tượng nhất của Jev tính đến nay: với tác vụ routing giới hạn này, Jev vừa chính xác hơn vừa nhanh hơn đáng kể. Độ lớn của mức chênh lệch cho thấy cái giá “chặn luồng” mà chúng tôi phải trả cho các request không cần expert-transfer có thể là một sự đánh đổi xứng đáng. Lưu ý rằng đây vẫn chỉ là so sánh offline trên tập golden, và mẫu đo độ trễ chỉ gồm 40 ca transfer thành công, nên vẫn còn rất nhiều thứ cần kiểm chứng và giảm thiểu rủi ro!
Reranking
Một bài toán vô cùng thân thuộc với Glean! Dưới đây, baseline production chính là thứ tự kết quả do stack tìm kiếm hiện tại của Glean tạo ra. Thử nghiệm này yêu cầu Jev sắp xếp lại tối đa 50 kết quả.
Chúng tôi thử bốn cách biểu diễn mức độ liên quan thông qua typed output của Jev:
Cách tiếp cận
Cách biểu diễn mức độ liên quan
Pointwise Noul
Đặt một câu hỏi có/không riêng biệt về độ liên quan cho từng kết quả, sau đó sắp xếp theo xác suất “có”.
Shared-state Noul
Đưa toàn bộ tập ứng viên cho Jev làm ngữ cảnh chung, rồi đặt cùng câu hỏi có/không đó cho từng kết quả.
Score
Yêu cầu Jev gán cho mỗi ứng viên một điểm số liên quan dạng số.
Choice
Coi tất cả ứng viên là các lựa chọn trong cùng một quyết định, sau đó xếp hạng chúng theo xác suất trả về.
Chúng tôi chạy thử nghiệm này trên một evalset nội bộ mà người dùng không có quyền truy cập vào toàn bộ canonical, nên các con số tuyệt đối không phản ánh đúng thứ hạng production – nhưng các con số tương đối lại rất đáng chú ý.
“Choice” của Jev là cách tiếp cận hiệu quả nhất. Trên tập đối chứng ghép cặp gồm 4,855 truy vấn tìm kiếm thu thập được, sau khi loại bỏ cơ chế phá vỡ thế hòa dựa trên production, kết quả là:
Jev Choice tốn khoảng $0.00044 cho mỗi truy vấn và mất 0.195 giây ở p50 trong bài test offline. Nhưng nó lại gán điểm giống hệt nhau cho khoảng 37 trên 41 ứng viên trong một truy vấn trung bình. Việc dùng thứ tự production để xử lý các trường hợp hòa điểm này đã đẩy Recall@6 từ 40.2% lên 44.3%, khiến kết quả chưa hiệu chỉnh trông có vẻ tốt hơn mức mà điểm số thuần túy của Jev mang lại. Như thường lệ, có rất nhiều lưu ý ở đây, nhưng xét về mặt xu hướng, Jev là một baseline rẻ và hiệu quả, chứ không phải bản thay thế cho ranker production của Glean.
Đánh giá mức độ hỗ trợ của trích dẫn
Việc đánh giá trích dẫn đặt ra hai câu hỏi liên quan: những khẳng định cần bằng chứng đã có trích dẫn đầy đủ chưa (citation recall), và các nguồn được trích dẫn có thực sự hỗ trợ cho khẳng định đó không (citation precision)? Thoạt nhìn, vì không gian output / nhãn bị giới hạn (giống phần lớn các thiết lập judge), đây dường như là sân chơi hiển nhiên của Jev. Tuy nhiên, rubric lại khá phức tạp và có thể đòi hỏi phải tách nhỏ nhiều khẳng định — thêm vào đó, Jev không sinh ra phần giải thích mà chúng tôi thường dùng để phân tích lỗi, nên tiềm ẩn rủi ro về cả chất lượng lẫn tính khả dụng.
Chúng tôi thử nghiệm Jev trên một response production-eval thực tế dài 1,448 từ, giữ nguyên response và bằng chứng trích dẫn. Chúng tôi so sánh lượt đánh giá precision-và-recall kết hợp của nó với GPT-5.6 Luna ở chế độ không reasoning và xhigh reasoning. Để giảm phương sai, mỗi judge được chạy ba lần.
Judge
Thời gian đo được ban đầu trên mỗi response
Chi phí đo được ban đầu trên mỗi response
Jev
6.6 s
$
0.014
GPT-5.6 Luna, không reasoning
81.3–85.5 s
$
0.030–
$
0.047
GPT-5.6 Luna,
xhigh
227.4–259.7 s
$
0.047–
$
0.060
Lưu ý rằng thời gian chỉ mang tính tham khảo xu hướng chứ không phải end-to-end: Jev báo cáo wall time tuần tự ở phía client, trong khi các dòng của Luna là tổng thời gian gọi mô hình. Chi phí đã bao gồm caching quan sát được.
Chúng tôi cũng so sánh tính nhất quán trên cùng 28 đoạn văn. Một mục bị thay đổi nghĩa là judge đổi phán quyết về việc đoạn văn đó có đủ trích dẫn hay không trong ít nhất một trên ba lần chạy với input y hệt. Số bất đồng cặp đôi đếm từng đoạn văn qua ba cặp lần chạy, tổng cộng 84 phép so sánh cho mỗi judge.
Judge
Số đoạn văn thay đổi phán quyết recall
Số bất đồng recall theo cặp
Jev
1 trên 28 (3.6%)
2 trên 84 (2.4%)
GPT-5.6 Luna, không reasoning
7 trên 28 (25.0%)
15 trên 84 (17.9%)
GPT-5.6 Luna,
xhigh
5 trên 28 (17.9%)
10 trên 84 (11.9%)
Thay đổi duy nhất của Jev là việc một đoạn văn có được tính là cần trích dẫn hay không; hạng mục recall thô của nó không hề đổi. Do đó, phán quyết về độ phủ trích dẫn ở cấp đoạn văn của Jev có tính lặp lại cao hơn cả hai cấu hình Luna.
Chúng tôi không kết luận rằng điều này biến Jev thành judge chính xác hơn (các hệ thống áp dụng tiêu chí hỗ trợ và mẫu số tính điểm khác nhau, và chúng tôi chưa kịp làm nhãn người độc lập). Nhưng ngay cả khi dùng xhigh reasoning (khiến thời gian mô hình của Luna tăng gần gấp ba), Luna vẫn kém nhất quán hơn Jev. Kết quả này củng cố vai trò của Jev như một cách nhanh chóng, rẻ và có tính lặp lại khá cao để triển khai một chính sách trích dẫn hẹp.
Bài học từ thử nghiệm và Hướng dẫn thực hành
Trong một số trường hợp, Jev tỏa sáng như một giải pháp thay thế mượt mà cho cả LLM truyền thống lẫn các trình phân loại đã fine-tune. Khi baseline đã mạnh (reranking), hoặc khi việc fine-tune một mô hình nhỏ khá dễ dàng (phân loại truy vấn), lợi thế sẽ mờ nhạt hơn. Có dấu hiệu cho thấy chất lượng tốt hơn ở một số tác vụ (định tuyến mô hình) cũng như tính nhất quán và ổn định cao hơn (citation judge). Ở một số workload quan trọng nhất của chúng tôi, nó mang lại mức cải thiện về chi phí và độ trễ đúng như kỳ vọng so với LLM truyền thống.
Những kết quả trên mang lại định hướng rất tốt, và tại Glean, chúng tôi đang vô cùng hào hứng với Jev. Sau vài bước nữa (chủ yếu là khâu sẵn sàng vận hành như data residency và các cam kết SLA), chúng tôi dự định đưa Jev vào một số use case này. Ngoài ra, Jev sẽ đóng vai trò lớn trong hackathon nội bộ tuần này và chúng tôi rất nóng lòng chia sẻ thêm kết quả!
Vài lời khuyên chung để chốt lại – nếu output có thể liệt kê trước, hãy benchmark Jev. Nếu tác vụ và nhãn ổn định cùng khối lượng lớn, hãy benchmark thêm cả một trình phân loại đã fine-tune. Nếu lệnh gọi cần sinh ra truy vấn, lời giải thích hoặc văn bản động nào khác, hãy giữ một mô hình generative trong vòng lặp. Tool calling là ví dụ điển hình: Jev có thể giúp chọn tool, nhưng phần lớn tool của Glean vẫn cần argument được sinh động (như truy vấn tìm kiếm).
Jev không thay đổi sự thật rằng các trình phân loại vốn đã tồn tại. Nó chỉ giúp việc sử dụng một trình phân loại zero-shot chất lượng trở nên dễ dàng hơn rất nhiều. Đó là một sản phẩm vững vàng, dù không phải nền tảng mới cho mọi hệ thống AI.
