Chúng ta đã dùng LLM như một chiếc búa để giải quyết mọi vấn đề AI, kể cả những quyết định đơn giản. Jev xử lý các quyết định đó trong vài mili giây với chi phí chỉ bằng một phần nhỏ. Hãy cùng tìm hiểu cách nó hoạt động và vị trí của nó trong hệ sinh thái.
TypeSafe AI ra mắt Jev vào ngày 15 tháng 9 năm 2026, và phản ứng dành cho mô hình này mạnh mẽ bất thường, dù nó không thể trò chuyện, viết code hay tạo ra một đoạn văn hữu ích nào.
Thực ra, chính giới hạn đó mới là điểm mấu chốt.
Phần lớn phần mềm không cần thêm một chatbot. Chúng cần đưa ra hàng nghìn phán đoán nhỏ, ví dụ: Ticket này có khẩn cấp không? Mô hình nào nên xử lý yêu cầu này? Lệnh shell này có nguy hiểm không? Đoạn văn bản được truy xuất có trả lời đúng câu hỏi không?
Các đội ngũ thường gửi từng phán đoán đến một LLM đa năng. Mô hình tạo ra câu trả lời từng token một, ứng dụng phân tích cú pháp, xác thực và thử lại khi cấu trúc không đúng. Cách này hiệu quả, nhưng chậm và tốn kém đối với một quyết định chỉ có năm lựa chọn khả thi.
Jev được xây dựng đặc biệt cho những quyết định đó. TypeSafe gọi đây là mô hình System One (Hệ thống Một): trạng thái phi cấu trúc đi vào, câu trả lời có kiểu dữ liệu rõ ràng và xác suất đi ra.
Hãy cùng phân tích ý nghĩa điều đó, vị trí phù hợp của nó, và đâu là lúc cần thận trọng hơn với các tuyên bố marketing.
Trước hết là vấn đề mà Jev đang giải quyết
LLM trở nên dễ dàng kết nối với phần mềm hơn nhiều sau khi tính năng tool calling (gọi công cụ) và structured outputs (đầu ra có cấu trúc) xuất hiện.
Tool calling cho phép mô hình yêu cầu một hàm theo định dạng dự đoán được. Structured outputs cho phép nó trả về JSON tuân thủ schema. Cả hai đều loại bỏ đáng kể việc phân tích cú pháp mong manh.
Nhưng mô hình nền tảng vẫn là mô hình sinh (generative). Ngay cả khi câu trả lời chỉ là một từ duy nhất "billing", nó vẫn tạo ra các token tuần tự. Bạn phải trả tiền cho đầu vào, chờ quá trình tạo sinh hoàn tất, và thường trả thêm phí cho đầu ra.
Bây giờ hãy đặt điều đó vào trong một vòng lặp agent.
1while not done:2 action = llm(context)3 result = run_tool(action)4 context += result
Mô hình có thể được gọi lại để chọn công cụ, đánh giá kết quả, phát hiện rủi ro, quyết định xem nhiệm vụ đã hoàn thành chưa, và chọn mô hình tiếp theo. Một lần chạy agent duy nhất có thể chứa nhiều lệnh gọi đòi hỏi phán đoán nhưng không cần tạo ra văn bản.
Jev nhắm mục tiêu vào những lệnh gọi đó.
Cược của họ rất đơn giản: tạo sinh ngôn ngữ là giao diện sai lầm khi code đã biết trước các câu trả lời khả thi.
Jev thực sự là gì?
Mô tả ngắn gọn và chính xác nhất là một engine quyết định ngữ nghĩa (semantic decision engine).
Bạn gửi cho Jev hai thứ:
- State (Trạng thái): Văn bản hoặc JSON mô tả tình huống hiện tại.
- Questions (Câu hỏi): Các quyết định bạn muốn nó đưa ra dựa trên trạng thái đó.
Mỗi câu hỏi khai báo trước hình thức câu trả lời. Jev hỗ trợ ba nguyên thủy (primitives):
- Choice chọn một tùy chọn từ danh sách bạn định nghĩa và trả về xác suất cho mỗi tùy chọn.
- Score đặt đầu vào lên một thang đo có thứ tự bạn định nghĩa, chẳng hạn như thấp, trung bình và cao.
- Noul trả lời câu hỏi có/không bằng cách trả về xác suất rằng điều đó là đúng.
Noul là tên gọi của TypeSafe cho nguyên thủy kiểu Boolean. Cái tên lạ lẫm ít quan trọng hơn so với đầu ra (một số giữa 0 và 1 mà code của bạn có thể hành động dựa trên đó).
1{2 "model": "jev-latest",3 "state": "The deploy failed twice and customers are seeing 500s.",4 "questions": {5 "urgent": {6 "type": "noul",7 "instructions": "Does this need attention right now?"8 },9 "owner": {10 "type": "choice",11 "instructions": "Which team should handle this?",12 "criteria": {13 "engineering": "Product failures and outages",14 "billing": "Charges, invoices, and refunds",15 "sales": "Pricing and new accounts"16 }17 }18 }19}
Phản hồi chứa xác suất mức độ khẩn cấp và phân phối xác suất cho ba nhóm. Không có đoạn văn nào cần diễn giải và không có nhóm thứ tư nào để mô hình tự sáng tạo ra.
Chương trình của bạn giữ quyền kiểm soát:
1if urgent > 0.9 and owner == "engineering":2 page_on_call()3elif confidence < 0.6:4 send_to_human_review()5else:6 add_to_queue(owner)
Đây là lý do mọi người liên tục gọi Jev là một câu lệnh switch thông minh. Cụm từ này nghe có vẻ coi thường, nhưng nó nắm bắt đúng phần hữu ích của thiết kế. Code thông thường sở hữu các nhánh rẽ. Mô hình cung cấp phán đoán mơ hồ mà code thông thường không thể tính toán một cách đáng tin cậy.
Sự khác biệt quan trọng so với LLM
Một LLM truyền thống và Jev đều có thể phân loại ticket hỗ trợ. Họ đạt đến câu trả lời theo cách khác nhau và hữu ích ở các phần khác nhau của hệ thống.
TypeSafe cho biết Jev đánh giá song song mọi câu hỏi trong một yêu cầu. Điều này thay đổi cách bạn thiết kế quy trình làm việc. Thay vì hỏi một câu, chờ đợi và quyết định câu hỏi tiếp theo là gì, bạn có thể hỏi tất cả các câu hỏi độc lập về cùng một trạng thái trong một yêu cầu và để code sử dụng những câu trả lời nó cần.
Công ty báo cáo độ trễ end-to-end từ 70 đến 500 mili giây và giá $0.042 cho mỗi triệu token đầu vào, với đầu ra miễn phí. Các tuyên bố nổi bật cho biết nhanh gấp khoảng 200 lần và rẻ hơn 400 lần so với các quy trình làm việc LLM tương đương.
Những bội số lớn này đến từ các đánh giá quy trình làm việc nội bộ của TypeSafe và nằm ở phía thuận lợi nhất của so sánh. Hãy coi chúng là trần hiệu suất, không phải cam kết cho mọi ứng dụng. Lợi thế cơ bản vẫn đáng tin cậy, vì Jev tránh các chuỗi suy luận dài và đầu ra được tạo sinh vì nó được thiết kế cho các quyết định có phạm vi giới hạn.
Tại sao xác suất lại quan trọng
Một câu trả lời có kiểu dữ liệu rõ ràng chỉ giải quyết một nửa vấn đề.
Giả sử Jev chuyển hướng một ticket sang bộ phận billing. Nhãn được chọn cho bạn biết ai thắng. Phân phối xác suất cho bạn biết cuộc đua sít sao đến mức nào.
1{2 "choice": "billing",3 "probabilities": {4 "billing": 0.52,5 "technical": 0.46,6 "sales": 0.027 },8 "confidence": 0.189}
Việc tự động chuyển hướng ticket đó sẽ là liều lĩnh. Billing thắng, nhưng chỉ vừa đủ. Câu trả lời có độ tin cậy thấp nên kích hoạt một nhánh xử lý khác.
Điều này mang lại cho các nhà phát triển một mẫu hình thực tế:
- Độ tin cậy cao: Hành động tự động khi hậu quả nhỏ.
- Độ tin cậy trung bình: Yêu cầu xác nhận hoặc gọi một mô hình mạnh hơn.
- Độ tin cậy thấp: Gửi trường hợp này cho con người hoặc thu thập thêm thông tin.
Các ngưỡng này thuộc về code, nơi chúng có thể được xem xét và thay đổi. Một nhãn trên dashboard có thể chấp nhận dự đoán yếu. Một lệnh xóa dữ liệu nên yêu cầu tiêu chuẩn cao hơn nhiều.
TypeSafe huấn luyện Jev bằng Reinforcement Learning for Calibrated Decisions (Học tăng cường cho các quyết định được hiệu chuẩn), hay RLCD. Mục tiêu là để độ tin cậy phản ánh độ chính xác qua nhiều dự đoán. Nếu một mô hình gán 90% xác suất cho một tập hợp câu trả lời, thì khoảng 90% trong số những câu trả lời đó nên đúng.
Tuyên bố về ảo giác (hallucination) cần sự chính xác
TypeSafe nói rằng Jev không thể bị ảo giác. Tuyên bố này chỉ đúng dưới một định nghĩa hẹp.
Jev không thể trả về một tùy chọn ngoài schema. Nếu bạn định nghĩa billing, technical và sales, phản hồi không thể tự sáng tạo ra legal. Nó cũng không thể tạo ra văn bản sai định dạng khi code của bạn mong đợi một nhãn.
Nhưng nó có thể tự tin chọn sai một tùy chọn hợp lệ.
Tính an toàn kiểu (type safety) ngăn chặn các hình thức không hợp lệ. Nó không đảm bảo phán đoán đúng đắn. Sự khác biệt này quan trọng vì một lỗi tuân thủ schema vẫn có thể hoàn tiền nhầm khách hàng, chuyển hướng sự cố sai hoặc phê duyệt một lệnh nguy hiểm.
Một câu an toàn hơn là "Jev không thể phá vỡ schema đầu ra đã khai báo, nhưng nó vẫn có thể sai".
Vị trí của Jev bên trong một agent
Jev hoạt động tốt nhất khi được sử dụng cùng với một LLM thay vì thay thế nó.
LLM xử lý công việc đòi hỏi ngôn ngữ hoặc suy luận sâu hơn. Nó lập kế hoạch, viết, giải thích và sử dụng công cụ. Jev xử lý các quyết định thường xuyên xoay quanh công việc đó.
Ba vị trí đặc biệt hấp dẫn.
Model routing (Định tuyến mô hình)
Một tra cứu đơn giản không cần cùng một mô hình như một đánh giá kiến trúc. Jev có thể chấm điểm yêu cầu và chọn mô hình ít tốn kém nhất có khả năng hoàn thành nó.
1route = jev.choice(2 state=user_request,3 options={4 "fast": "Lookups, extraction, and small local edits",5 "powerful": "Architecture, ambiguity, and high-stakes work",6 },7)89model = fast_model if route == "fast" else powerful_model
Bộ định tuyến không trả lời yêu cầu. Nó quyết định mô hình nào nên làm điều đó.
Tool risk gating (Kiểm soát rủi ro công cụ)
Trước khi một agent chạy lệnh shell, Jev có thể phân loại nó là chỉ đọc, có thể đảo ngược hoặc phá hủy. Các câu hỏi riêng biệt có thể kiểm tra xem nó có xóa tệp, thay đổi lịch sử Git, chạm vào môi trường production hay rời khỏi repository không.
Các hành động chỉ đọc có độ tin cậy cao có thể tiếp tục. Các hành động phá hủy hoặc không chắc chắn có thể tạm dừng để chờ phê duyệt của con người. Tích hợp Jev của LangChain áp dụng mẫu hình này thông qua middleware kiểm tra lệnh gọi công cụ trước khi thực thi.
Verification and supervision (Xác minh và giám sát)
Một agent có thể tuyên bố rằng nhiệm vụ đã hoàn thành trong khi các bài kiểm tra vẫn thất bại. Jev có thể kiểm tra trạng thái và trả lời các câu hỏi có phạm vi giới hạn: Bài kiểm tra có pass không? Agent có đang lặp lại cùng một hành động không? Đầu ra có tuân thủ chính sách không? Kết quả này có cần được xem xét lại không?
Nó sẽ không thay thế một bài kiểm tra cứng (hard test) khi bài kiểm tra đó tồn tại. Nó bổ sung một bước kiểm tra ngữ nghĩa ở nơi quy tắc phụ thuộc vào ý nghĩa.
Các vấn đề Jev có thể giải quyết ngay hôm nay
Các trường hợp sử dụng tốt nhất chia sẻ ba đặc điểm. Bạn có thể liệt kê các câu trả lời khả thi, một con người cẩn thận có thể đánh giá đầu vào nhanh chóng, và quyết định xảy ra đủ thường xuyên để độ trễ hoặc chi phí trở nên quan trọng.
Support and operations (Hỗ trợ và vận hành)
- Phân loại ý định, mức độ khẩn cấp, phòng ban, spam và sự khó chịu của khách hàng.
- Chuyển hướng hoàn tiền và ngoại lệ chính sách thông qua nhiều bước kiểm tra nhỏ.
- Xếp hạng log và sự cố theo mức độ nghiêm trọng ngữ nghĩa trước khi con người đọc chúng.
Một yêu cầu duy nhất có thể hỏi tất cả những câu hỏi này về cùng một ticket. Sau đó, code kết hợp các câu trả lời vào chính sách định tuyến thực tế của công ty.
Search and retrieval (Tìm kiếm và truy xuất)
- Sắp xếp lại các đoạn văn bản truy xuất dựa trên việc chúng có trả lời truy vấn hay không.
- Kiểm tra xem trích dẫn có hỗ trợ cho một tuyên bố hay không.
- Lọc các chunk không liên quan trước khi gửi ngữ cảnh đến một LLM đắt đỏ.
Embeddings rất tuyệt vời trong việc tìm kiếm văn bản liên quan về mặt ngữ nghĩa. Jev có thể đưa ra quyết định hẹp hơn về việc liệu một đoạn văn bản cụ thể có hữu ích cho câu hỏi này hay không.
Quality and safety (Chất lượng và an toàn)
- Sàng lọc prompt để tìm jailbreak hoặc prompt injection.
- Kiểm tra nội dung được tạo sinh so với chính sách hoặc rubric.
- Đánh dấu các thay đổi code hoặc lệnh gọi công cụ rủi ro trước khi chúng thực thi.
Các bước kiểm tra này nên nằm cạnh các biện pháp kiểm soát xác định (deterministic controls). Bộ phân loại ngữ nghĩa hữu ích cho rủi ro mơ hồ, trong khi quyền hạn, sandbox và bài kiểm tra thực thi các quy tắc mà phần mềm có thể xác minh chính xác.
High volume classification (Phân loại khối lượng lớn)
- Gắn nhãn tài liệu, bài nghiên cứu, danh sách sản phẩm hoặc tin nhắn khách hàng.
- Chuyển đổi văn bản tự do thành các đặc trưng cho một mô hình machine learning truyền thống.
- Chấm điểm mọi mục trong một kho dữ liệu lớn theo cùng một rubric.
Đây là nơi chi phí thấp cho mỗi lệnh gọi trở nên quan trọng hơn một con số benchmark. Một phán đoán quá đắt đỏ để chạy trên mọi dòng dữ liệu có thể di chuyển vào pipeline dữ liệu thông thường.
Real time interfaces (Giao diện thời gian thực)
- Chọn hành động trình duyệt tiếp theo từ các phần tử trang đã biết.
- Chấm điểm giọng điệu hoặc sự rõ ràng trong khi một người đang viết.
- Chọn một hành động từ trạng thái game hoặc simulator có cấu trúc.
Jev hiện tại chỉ xử lý văn bản, vì vậy các hệ thống này phải chuyển đổi môi trường thành văn bản hoặc JSON trước. Nó không nhìn vào màn hình hay chơi từ các pixel.
Khi nào Jev là lựa chọn sai
Jev trở nên ít hữu ích ngay khi không gian câu trả lời không còn được biết trước.
- Nó không thể viết phản hồi, tóm tắt tài liệu, tạo code hoặc giải thích lý lẽ của mình.
- Nó không đáng tin cậy cho số học, đếm, so sánh ngày tháng hoặc thao tác chuỗi chính xác. Giữ các phép toán đó trong code.
- Nó gặp khó khăn khi một quyết định đòi hỏi nhiều bước suy luận ẩn. Chia phán đoán thành các câu hỏi nhỏ hơn hoặc sử dụng một mô hình suy luận.
- Nó không thể trực tiếp trích xuất một giá trị không xác định. Tìm các giá trị ứng viên trước, sau đó để Jev chọn trong số chúng.
- Ngữ cảnh không liên quan có thể làm giảm độ chính xác. Chỉ gửi trạng thái cần thiết cho quyết định.
- Trọng số đóng, quyền truy cập sớm, đầu vào chỉ văn bản và dữ liệu hiệu chuẩn độc lập hạn chế khiến nó quá sớm để tin tưởng mù quáng.
Cũng có một quy tắc đơn giản hơn: nếu code xác định đã giải quyết vấn đề đúng cách, hãy giữ code đó. Một câu lệnh if thông thường nhanh hơn, rẻ hơn và dễ kiểm thử hơn bất kỳ mô hình nào.
Cách sử dụng Jev mà không tạo ra chế độ thất bại mới
Một mô hình rẻ vẫn có thể đắt đỏ nếu các lỗi của nó tạo ra việc thử lại, xem xét thủ công hoặc sự cố production. Hãy đo lường toàn bộ quy trình làm việc, không chỉ giá token.
Một đợt triển khai hợp lý trông như thế này:
- Chọn một quyết định có phạm vi giới hạn, rủi ro thấp với các câu trả lời khả thi rõ ràng.
- Viết rubric trước khi gọi mô hình. Định nghĩa những gì thuộc về mỗi tùy chọn.
- Thu thập các ví dụ đại diện với câu trả lời mong đợi, bao gồm cả các trường hợp mơ hồ và đối kháng.
- Chạy Jev ở chế độ shadow (bóng) bên cạnh quy trình làm việc hiện tại mà không để nó thay đổi hành vi.
- Vẽ biểu đồ độ chính xác so với độ tin cậy và đặt các ngưỡng từ dữ liệu của bạn.
- Tự động hóa nhánh an toàn nhất trước tiên và giữ con người hoặc mô hình mạnh hơn cho các trường hợp không chắc chắn.
- Cố định hoặc ghi nhật ký phiên bản mô hình, câu hỏi, tiêu chí và ngưỡng để các thay đổi có thể được phát lại trên cùng một tập đánh giá.
Các câu hỏi là một phần của chương trình. Hãy đối xử với chúng như code: quản lý phiên bản, xem xét và kiểm thử chúng bất cứ khi nào mô hình hoặc rubric thay đổi.
Sự thay đổi thực sự
Jev không thú vị vì nó đánh bại LLM trong việc viết lách. Nó từ chối viết.
Đóng góp của nó là một giao diện mô hình được định hình giống phần mềm: các loại câu trả lời cố định, sự không chắc chắn tường minh, các câu hỏi song song và phân nhánh do code kiểm soát.
Điều này biến nó thành một người bạn đồng hành hữu ích cho các mô hình sinh. LLM tạo ra kế hoạch, giải thích hoặc code. Jev định tuyến yêu cầu, kiểm soát hành động rủi ro, kiểm tra kết quả và quyết định khi nào sự không chắc chắn đủ cao để leo thang.
Ý tưởng rộng lớn hơn vẫn quan trọng ngay cả khi một mô hình khác cuối cùng thay thế Jev. Chúng ta đã dành nhiều năm yêu cầu các mô hình sinh thực hiện mọi loại trí thông minh thông qua văn bản. Nhiều hệ thống production không cần thêm từ ngữ. Chúng cần một phán đoán nhỏ, nhanh mà phần mềm thông thường có thể sử dụng một cách an toàn.
Đó là danh mục mà Jev đang cố gắng xây dựng.
Nơi để bắt đầu
Đừng bắt đầu bằng cách tái cấu trúc agent của bạn xung quanh Jev. Hãy tìm một quyết định hiện đang đòi hỏi một lệnh gọi LLM chậm hoặc một regex liên tục bị hỏng.
Cung cấp cho Jev trạng thái tối thiểu, định nghĩa các câu trả lời khả thi và ghi lại xác suất của nó bên cạnh kết quả hiện tại. Hãy để nó chứng minh rằng nó xứng đáng với một nhánh trước khi bạn giao cho nó toàn bộ quy trình làm việc.
Mô hình tinh thần hữu ích nhất vẫn là mô hình đơn giản nhất → Jev thêm phán đoán vào những nơi mà một câu lệnh if thông thường hiểu các giá trị nhưng không hiểu ý nghĩa của chúng.
Nguồn và tài liệu tham khảo thêm
- TypeSafe AI: Giới thiệu về các mô hình System One và Jev
- LangChain: Xây dựng Harness với Jev
- Flavio Copes: Đi sâu vào Jev
Hy vọng bạn đã thích bài viết này.
Hẹn gặp lại bạn ở bài viết tiếp theo.
Chúc vui! :)
