Jev là cái quái gì? Tin được không ?

Trong log CLINC150 công khai của một người thử Jev, có một câu mang nhãn reminder_update. Jev chọn reminder, kèm confidence: 1. Cả hai đều là lựa chọn hợp lệ. Phần mềm nhận response sẽ không gặp lỗi parse, nhưng có thể tạo lời nhắc mới khi người dùng muốn sửa lời nhắc cũ. ^[1]

Trong log đó, 102/200 câu có confidence bằng 1, và sáu câu trong số đó sai so với nhãn tham chiếu.

Nếu bạn định dùng Jev để chia ticket, kiểm tra câu trả lời RAG hay chọn bước tiếp theo của agent, loại lỗi này đáng đo riêng. Người vận hành cần biết bao nhiêu câu sai vẫn lọt qua ngưỡng tự động xử lý. Accuracy chung chưa trả lời được câu hỏi ấy.

Một API cho những chỗ chỉ cần chọn

Giả sử khách hàng viết: "Tôi không hỏi giá. Trang thanh toán báo lỗi và không tải được."

Bạn có bốn nơi để chuyển tin nhắn: billing, technical, sales, other. Với một chatbot, bạn thường yêu cầu nó xuất JSON rồi đọc nhãn từ chuỗi trả về. Với Jev, bạn gửi sẵn bốn lựa chọn và mô tả từng lựa chọn trong một câu hỏi Choice. Trong quy tắc đang dùng ở đây, lỗi trang thanh toán thuộc technical.

Jev của TypeSafe nhận state cùng các câu hỏi có kiểu. Ngoài Choice, nó có Noul cho xác suất một mệnh đề đúng và Score cho vị trí trên một thang đánh giá. Người viết ứng dụng vẫn phải định nghĩa nhãn, quy tắc và cách xử lý kết quả. ^[2]

Tôi chạy thử ngày 05/10/2026 trên jev-1.13.0, bản ổn định lúc đó. Giá là 0,042 USD mỗi triệu input token, không tính tiền output, và tới ngày 19/10 vẫn chưa đổi. Hãng cho biết Jev đọc state một lần rồi đánh giá các câu hỏi song song. Cách này hợp với một ticket cần kiểm tra nhiều điều độc lập, chẳng hạn bộ phận phụ trách, yêu cầu hoàn tiền và mức độ khẩn cấp. ^[3]

Sự thuận tiện của interface có thể giải thích vì sao lập trình viên muốn thử nó. Bạn không cần thu thập một tập huấn luyện riêng chỉ để kiểm tra ý tưởng routing ban đầu.

Ngày 14/10, TypeSafe phát hành jev-1.14.0 dưới alias jev-preview và nói sẽ chuyển jev-latest sang bản này sau khoảng một tuần. Hãng kỳ vọng bản này khá lên nhiều nhất ở các ngôn ngữ ngoài tiếng Anh, nhưng bài phát hành không đưa số đo nào. Ba tính năng mới là ảnh, kiểu câu hỏi thứ tư Box và context dài; cả ba phải bật bằng header có tiền tố TypeSafe-Danger-Zone, và hãng chưa khuyên dùng chúng cho production. ^[4]

Box trả về khung chữ nhật nhỏ nhất bao quanh một vật trong ảnh. Kiểu này không có đáp án "không tìm thấy": hỏi về một vật không có trong ảnh vẫn nhận về một khung. Mặc định Jev nhận 64k token mỗi request và 32k mỗi câu hỏi. Header mở lên 262k, nhưng theo chính trang Models, model khi đó chậm hơn và kém chính xác hơn. ^{[5] [3]}

Bài phát hành còn viết rằng ngay từ jev-1.13.0, model đã nhận được ảnh. Tới ngày 19/10, trang Models vẫn chỉ nói input là văn bản, không nhắc tới ảnh. Tài liệu có thể chưa theo kịp model, nên tính năng nào định dùng thì bạn tự thử, và ghi lại trường model của từng response. ^{[4] [3]}

Số 0% của TypeSafe đang đo điều gì?

Trong bài ra mắt ngày 15/9, TypeSafe đặt các biểu đồ lỗi bên dưới heading "Hallucination and Type-safety". Hãng nói rõ số 0% của Jev xuất phát từ bảo đảm khớp schema, không phải kết quả đo thực nghiệm. ^[6]

TypeSafe suy ra số 0% từ bảo đảm khớp schema. Bài ra mắt ngày 15/9/2026.

Với ví dụ ticket ở trên, schema guarantee ngăn response chứa một bộ phận không có trong danh sách. Jev vẫn có thể chọn billing thay vì technical. Chương trình sẽ nhận một nhãn đúng kiểu và chuyển khách hàng đến sai nơi.

Trả lời trên Hacker News, nhà sáng lập TypeSafe đồng ý rằng type safety khác factual correctness. Nhiều người vẫn hỏi tiếp vì sao hãng dùng chữ "không hallucinate" cho một bảo đảm hẹp hơn điều người đọc thường hiểu. ^[7]

Bạn có thể chọn một định nghĩa hẹp cho hallucination. Chi phí chuyển nhầm ticket thì vẫn cần tính.

Cộng đồng muốn so Jev với đối thủ nào?

Vài người cho rằng các model chuyên dụng vẫn làm việc này tốt và rẻ hơn, và muốn thấy Jev được so với zero-shot classifier, NLI hay reranker, chứ không chỉ với LLM sinh văn bản. Người khác thì thích có sẵn một API dễ dùng cho những bộ nhãn đổi theo từng request. API dễ dùng chưa chứng minh được Jev có kiến trúc mới. ^{[8] [9]}

Một dự án mã nguồn mở thử đọc logits của chữ cái lựa chọn trên Qwen3-4B đóng băng, thay cho việc sinh cả JSON. Tác giả báo accuracy hai cách gần như bằng nhau, khoảng 0,91, và cách đọc logits nhanh hơn khoảng bốn lần với text ngắn. ^[10]

Đó là một baseline nên thử. Nó chưa cho biết Jev dùng head, decoder hay sampler nào, và hãng chưa công bố đủ chi tiết để xác định cấu trúc bên trong. ^[11]

Nhà sáng lập nói chưa công khai kiến trúc Jev. Trao đổi trên Hacker News.

So sánh cũng phải giữ nguyên điều kiện học. Trên 208 câu Banking77, Jev đúng 173 câu, còn encoder đúng 194 câu. Encoder ở đây dùng embedding BGE-small và logistic regression đã học từ khoảng 10 nghìn mẫu có nhãn. Jev chạy zero-shot. Với một bài toán đã có nhiều dữ liệu huấn luyện, bạn nên thử baseline supervised này; kết quả chưa đủ để kết luận nó sẽ thắng khi nhãn đổi theo từng request. ^[1]

Tới giữa tháng 10 đã có vài model mở dùng cùng kiểu interface. JevK5 là một model 4B gắn LoRA, học từ câu trả lời của một model lớn hơn và một tập do người gán nhãn, rồi hiệu chỉnh lại xác suất. Tác giả cho biết mỗi quyết định với input ngắn mất khoảng 13 ms trên một GPU H100. Có người dùng kể nó chỉ kém Jev khoảng một điểm trên bộ test riêng. ^{[12] [9]}

Trên Hacker News, nhiều người kể đã dùng Jev thay LLM cho việc lọc và phân loại trong pipeline, và thấy rẻ, nhanh hơn mà chất lượng gần như không đổi; vài người còn so với các lựa chọn tự host lẫn dịch vụ mà chưa thấy cái nào rẻ và tốt bằng. Vài người coi data residency và thời hạn lưu dữ liệu là điều kiện bắt buộc, và kể phải chờ hãng trả lời nhiều tuần; một người được báo sau hai tuần rằng zero data retention đã bật. Có người hỏi tung đồng xu thì ra sấp hay ngửa và chưa thấy decision model nào trả về 50/50, nên họ khó tin các xác suất khác. ^[9]

Kết quả trên benchmark và hội thoại thật

Một preprint đánh giá Jev 1.13.0 trên 37 dataset, tổng cộng khoảng 346 nghìn request. Nhóm tác giả báo pooled ECE của xác suất Choice là 0,028; với Noul đa nhãn, con số lên 0,168. ECE tóm tắt độ lệch giữa xác suất dự đoán và tần suất đúng theo các nhóm dự đoán. ^[13]

Choice gần đường chéo hơn Noul đa nhãn: xác suất dự đoán khớp tần suất đúng tốt hơn. Hình 2, trang 9.

Đây là bằng chứng rộng hơn các demo lúc ra mắt. Tác giả không loại trừ contamination và chỉ so với hai open model, chưa bao quát mọi classifier. Với UNFAIR-ToS, họ báo micro-F1 tăng từ 0,499 lên 0,748 khi tune ngưỡng trên train/validation thay vì cố định 0,5. ^[13]

Bảng 4, trang 10: kết quả khi giữ ngưỡng 0,5 và khi tune ngưỡng trên train/validation.

Một công ty làm routing cho hội thoại chăm sóc khách hàng báo accuracy 98,5% cho Jev trên 1.357 quyết định có nhãn, trải trên 13 ngôn ngữ, so với 99,0% của một model Gemini. Đến bước replay hội thoại thật, Jev kém hệ thống cũ khi cần chọn đúng chuyên viên đang phụ trách. Hệ thống cũ biết ai đang phụ trách cuộc hội thoại, còn bản replay không đưa thông tin đó cho Jev. ^[14]

Ở một benchmark RAG khác, tác giả báo Jev và Astra task-optimised gần nhau về mean per-dataset balanced accuracy, khoảng 73-74%. Jev xác nhận nhầm 23,2% claim không có căn cứ, so với 14,1% của Astra. Với bộ kiểm chứng RAG, lỗi cho qua một claim sai có thể đáng ngại hơn việc yêu cầu kiểm tra lại một claim đúng. ^[15]

Chạy thử bằng tiếng Anh và tiếng Việt

Tôi chạy bộ kiểm tra qua playground với tin nhắn tôi tự soạn, chốt nhãn trước khi xem kết quả. Chưa có người thứ hai soát lại nhãn.

Có 24 tin nhắn routing, tạo thành 12 cặp Anh/Việt. Mỗi tin chạy hai lần với thứ tự lựa chọn đảo ngược. Jev chọn đúng cả 48 lượt theo quy tắc đã viết và không đổi nhãn khi đảo thứ tự. Đây là các câu ngắn với yêu cầu rõ, không phải 48 mẫu độc lập lấy từ traffic khách hàng.

Tin nhắn "Tôi không hỏi giá. Trang thanh toán báo lỗi và không tải được" nhận nhãn technical với confidence bằng 1. Bản tiếng Anh tương ứng cũng nhận cùng nhãn. Quy tắc đã mô tả rõ lỗi trên trang thanh toán thuộc nhóm kỹ thuật.

Jev xếp lỗi trang thanh toán vào technical, đúng với quy tắc đã cho. Playground TypeSafe.

Với 16 claim đối chiếu một đoạn nguồn, Jev chọn đúng nhãn ở cả 16 trường hợp; bộ nhãn gồm supported, contradicted, unknown. Câu hỏi Noul về việc nguồn có hỗ trợ claim cũng đúng 16/16 ở ngưỡng 0,5. Chẳng hạn, nguồn không nêu thành phố nhưng claim nói nhóm làm việc tại Hà Nội: Jev chọn unknown. Thêm nhãn này cho phép code giữ lại sự thiếu thông tin.

Bộ kiểm tra quá dễ để dùng kết quả đúng hết làm bằng chứng về calibration hay khả năng tiếng Việt nói chung. Nó chỉ xác nhận Jev xử lý được những quy tắc và cách diễn đạt đã thử; chưa có model khác chạy cùng bộ để so chất lượng.

Ngày 19/10, tôi chạy lại 48 lượt routing và 16 claim trên jev-1.14.0, giữ nguyên từng chữ của input. Cả 64 câu trả lời trùng nhãn với bản 1.13, kể cả khi đảo thứ tự lựa chọn. Confidence chỉ đổi ở ba câu, lệch tối đa 0,03; xác suất Noul lệch tối đa 0,02, không đổi quyết định nào ở ngưỡng 0,5. Ở các câu tiếng Việt, chỉ tin nhắn và claim viết bằng tiếng Việt; hướng dẫn và mô tả nhãn vẫn là tiếng Anh. Bản 1.13 đã đúng hết nên lượt này không đo được bản 1.14 tiến bộ bao nhiêu ở tiếng Việt.

Phần batching đem lại một phép so chi phí cụ thể hơn. Cùng một state tự soạn có thêm ghi chú lặp, hỏi bốn câu riêng tốn tổng cộng 4.838 input token. Gộp vào một request tốn 1.262 token, giảm khoảng 74%. Ba lần thử cho cùng lượng token; xác suất Noul giữa hai cách chênh nhiều nhất 0,01 và không đổi quyết định ở ngưỡng 0,5.

Gộp bốn câu hỏi tránh gửi lại cùng state. Mức tiết kiệm phụ thuộc độ dài state so với phần câu hỏi.

Lượt đầu dùng khoảng 46 nghìn input token, chưa tới 0,002 USD theo giá niêm yết. Thời gian đánh giá trung vị do server báo khoảng 70 ms. Tôi chạy qua UI nên không đo HTTP latency, và con số này không kiểm được lời quảng cáo về tốc độ. Với 64 request chạy lại, server báo trung vị khoảng 28 ms, so với khoảng 69 ms của chính 64 request đó ở lượt đầu. Tải và hạ tầng hai hôm có thể khác nhau.

Ngưỡng tự động xử lý đổi theo mục tiêu

Quay lại 200 câu CLINC150. Một cách dùng Jev là giữ đáp án khi confidence đủ cao, còn lại hỏi model lớn hơn. Trong log này, model thứ hai là GPT-5.6 Terra, đúng 183/200 câu.

Confidence quyết định khi nào cần hỏi thêm. Code vẫn kiểm tra quy tắc trước khi thực hiện hành động.

Tôi quét các ngưỡng để tìm tỷ lệ chuyển sang Terra thấp nhất mà vẫn đạt mục tiêu accuracy. Nếu chấp nhận mục tiêu 90,5%, cách Jev trước rồi Terra sau chỉ cần chuyển 22% số câu. Khi yêu cầu đạt đúng mức 91,5% của Terra, code phải chuyển toàn bộ. ^[1]

Ngưỡng được chọn trên chính tập đánh giá, chưa đo trên traffic mới. Dữ liệu: jev-baselines-eval.

Những câu sai có confidence bằng 1 khiến quy tắc threshold khó xử lý: muốn loại chúng, quy tắc cũng phải loại các câu đúng có cùng confidence. Hỏi model lớn hơn cũng chỉ giúp nếu model ấy sửa được lỗi. Trong sáu lỗi confidence bằng 1 đã nêu, Terra chỉ trả lời đúng một câu.

Tỷ lệ 22% này cũng là kết quả chính mà tác giả repo dùng, khi so cách Jev trước rồi Terra sau với cách dùng một LLM nhỏ giá rẻ trước rồi Terra sau; cách thứ hai phải chuyển 48,5%. Tác giả vẫn kết luận là chưa phân định được, vì khoảng tin cậy 95% của chênh lệch hai tỷ lệ chuyển là từ -0,530 tới 0,595. Họ dặn hiểu 22% là tỷ lệ phải chuyển để tiến gần accuracy của Terra, chưa đủ để bằng Terra. ^[1]

Cùng tác giả còn thử xem ngưỡng confidence có chặn được prompt injection không. Đề là routing ticket với tám bộ phận. Tác giả chèn vào mỗi ticket một đoạn nói rằng cấp trên đã quyết định chuyển nó sang một bộ phận, luôn là bộ phận sai. Jev nghe theo 247 trên 300 lần. Khi đoạn chèn chỉ là một lệnh cộc lốc kiểu "chuyển sang X", hoặc một đoạn trung tính dài tương đương, không lần nào Jev chọn bộ phận sai đó. ^[16]

Trong 300 ticket đó, confidence của Jev lại cao hơn ở những lần nó nghe theo đoạn chèn: trung vị 0,730, so với 0,570 ở những lần nó giữ nhãn đúng. AUROC là 0,261, khoảng tin cậy 95% từ 0,190 tới 0,336, nghĩa là confidence càng cao thì càng dễ là một lần Jev bị lái. Ngưỡng 0,85 chặn được 171 lần bị lái, nhưng 76 lần khác lọt qua, trong khi chỉ 4 lần giữ nhãn đúng qua được ngưỡng. Tác giả không kết luận rằng ngưỡng này gây hại khi triển khai thật. ^[16]

Nghiên cứu này còn chạy hai model mở. Một encoder kiểu classifier truyền thống chỉ bị lái 34,3% số lần, một decoder 2B học từ model lớn hơn bị lái 57,0%, so với 82,3% của Jev. Đổi lại, ở ngưỡng 0,85 model encoder chặn 73% số quyết định đúng trên ticket sạch, còn Jev chỉ chặn 3,3%. ^[16]

Bởi vậy, chi phí của hệ thống còn phụ thuộc bạn chấp nhận bỏ sót gì. Một nhãn để thống kê xu hướng có thể chịu mức sai khác với một nhãn quyết định có gửi câu trả lời đến khách hàng hay không.

Ngưỡng tune trên bản này chưa chắc còn đúng ở bản sau. Trang Models khuyên ai đã tune ngưỡng confidence thì gửi ID phiên bản cụ thể thay cho alias, vì khi alias trỏ sang bản mới, câu trả lời có thể đổi dù code không sửa dòng nào. ^[3]

Trước khi giao cho Jev một bước tự động, phần còn thiếu thường là tập tin nhắn thật, nhãn mà nhóm vận hành đồng ý, và phép đếm những lỗi vẫn lọt qua ngưỡng. Chính tập dữ liệu đó mới cho biết có thể bỏ bớt bao nhiêu lần gọi model lớn.

Đào sâu: confidence không phải một lần kiểm chứng thứ hai

TypeSafe tính confidence của Choice từ số lựa chọn \(n\) và xác suất lớn nhất \(p_{\max}\):

\[\text{confidence}=\frac{n p_{\max}-1}{n-1},\qquad n\gt 1.\]

Lấy ví dụ minh họa có ba lựa chọn với xác suất 0,6, 0,3 và 0,1:

\[\text{confidence}=\frac{3\times 0{,}6-1}{3-1}=0{,}4.\]

Nó diễn tả mức lựa chọn cao nhất vượt lên trên phân phối đều. Nó không phải một mô hình khác đã kiểm tra đáp án và đưa ra xác suất đúng độc lập. ^[17]

Khi đánh giá calibration, phải nói rõ đang đo \(p_{\max}\), xác suất của Noul, hay trường confidence. Dùng nhầm số sẽ khiến cả biểu đồ và ngưỡng không còn đúng nghĩa.

Bạn có thể tải bộ đề, kết quả từng request của cả hai lượt chạy và script phân tích.

Tài liệu của hãng cũng liệt kê các điểm yếu về số học, so sánh ngày, input dài nhiều chi tiết thừa và nội dung có chủ đích thao túng. Với phép cộng, so ngày hay kiểm tra điều kiện chính xác, viết code thường giúp bạn kiểm chứng kết quả dễ hơn. ^[18]

Bình