# Mô hình ra quyết định Jev của TypeSafe chính thức có mặt trên OpenRouter

- Nguồn: OpenRouter: Announcements
- Thời gian phát hành: 2026-09-21 07:00 (giờ Việt Nam)
- Điểm AI: 62/100
- Nhãn AIHOT: Tinh chọn
- Link AIHOT.vn: https://aihot.vn/items/4ae3a63fa0557699
- Nguồn dữ liệu AI HOT: https://aihot.news/items/cmudpvn230nxmroggdp0jx9uj
- Link gốc: https://openrouter.ai/blog/insights/what-is-jev

## Lý do tinh chọn

Đây là bản cập nhật quan trọng cho các nhà phát triển cần mô hình chuyên biệt về logic ra quyết định, tuy nhiên độ phổ biến của Jev vẫn còn khá mới.

## Tóm tắt AI

Mô hình Jev (phiên bản 1.13) từ TypeSafe hiện đã khả dụng thông qua OpenRouter Decisions API, cho phép các nhà phát triển tích hợp khả năng ra quyết định chuyên sâu vào ứng dụng.

## Thân bài

![What Is Jev? TypeSafe's Decision Model Explained for Developers](https://openrouter.ai/blog/images/what-is-jev.png)

Jev là gì? Và bạn nên sử dụng nó để làm gì? Đây là mô hình ra quyết định của TypeSafe, nhận đầu vào là một đoạn văn bản kèm theo câu hỏi đã được định kiểu, sau đó trả về một câu trả lời đã được định kiểu, vốn là một trong những lựa chọn nằm trong tập hợp các câu trả lời được xác định trước của bạn. Vì vậy, nếu tôi có một câu hỏi về việc phân loại phiếu hỗ trợ (ticket), chẳng hạn như phiếu này nên gửi đến bộ phận thanh toán, kỹ thuật hay tài khoản, Jev sẽ xem xét nội dung của phiếu và trả lời bằng một trong các lựa chọn đã định trước, ví dụ như "thanh toán". Nhưng điều thú vị hơn nữa là nó còn cung cấp cho bạn xác suất đã hiệu chỉnh của lựa chọn đó cũng như xác suất của từng lựa chọn còn lại. Ồ, và còn có một điểm số tin cậy tổng thể nữa (chúng ta sẽ nói thêm về điều này sau). TypeSafe gọi đây là các mô hình System One, và Jev là mô hình đầu tiên trong số đó.

Nhưng Jev thực sự trả về những gì? Hãy cùng tìm hiểu! Nó trả về ba nguyên hàm (primitives), và dưới đây là các phản hồi API thực tế cho từng loại. Đây là cách đọc các xác suất mà không tự đánh lừa bản thân. Và đây là cách gọi Jev bằng khóa API OpenRouter.

### Mô hình ra quyết định (mô hình System One) là gì?

Jev là một mô hình ra quyết định. Mô hình System One là mô hình tiếp nhận một trạng thái và dựa trên trạng thái đó để đưa ra quyết định. Trong trường hợp này, quyết định của Jev luôn là một giá trị đã được định kiểu mà bạn đã xác định trước, cộng với một con số xác suất thực tế từ 0 đến 1. Tên gọi này bắt nguồn từ khái niệm System One mà Daniel Kahneman đã đề cập trong cuốn *Thinking, Fast and Slow*: tư duy nhanh, khớp mẫu, trong khi System Two là tư duy chậm và có cân nhắc.

Vậy điều gì khiến đây là một mô hình ra quyết định chứ không phải một nhà tiên tri? Một mô hình ra quyết định phải trả về kết quả từ một tập hợp nhỏ các giá trị mà bạn đã quyết định trước đó. Không có văn bản tự do, vì vậy bạn không cần phải phân tích cú pháp hay lo lắng về vấn đề ảo giác (hallucination).

TypeSafe đã hiệu chỉnh Jev sao cho khi nó đưa ra con số 0.8 (xác suất 80%), điều đó có nghĩa là, giống như xác suất mưa 80%, Jev đúng với loại câu trả lời đó khoảng 80% thời gian (các khái niệm System One).

Điều đó chỉ đúng khi bạn tính trung bình trên nhiều câu trả lời. Bất kỳ câu trả lời đơn lẻ nào cũng có thể sai. Điều này tạo ra sự khác biệt trong thực tế; đây là một điểm mà chúng ta sẽ quay lại sau.

### Jev so với LLM: mỗi loại trả về những gì

Sự khác biệt giữa Jev và các LLM trở nên rõ ràng khi bạn hiểu cả hai làm gì. Cả hai đều có thể đọc ngôn ngữ tự nhiên, nhưng sự phân tách nằm hoàn toàn ở phía đầu ra.

Dưới đây là cách so sánh hai hệ thống này cạnh nhau:

Bất cứ khi nào bạn cần từ ngữ làm đầu ra chính, ví dụ như câu trả lời, tóm tắt hoặc bản vá mã, hãy chọn LLM. Khi bạn cần đưa ra một quyết định có thể thực thi bằng mã, hãy sử dụng Jev. Trong hầu hết các trường hợp thực tế, hai hệ thống này hoạt động cùng nhau: Jev định tuyến và xác minh mọi thứ, trong khi LLM cung cấp ngôn ngữ. Và đó chính là nội dung của bài viết đi kèm "Jev vs LLM: when to use each". Bài viết đó đánh giá sự phân tách này trên 140 trường hợp hỗ trợ và kết nối cả hai trong TypeScript.

### Ba nguyên hàm của Jev: Choice, Score và Noul

Mỗi câu hỏi bạn đặt ra cho Jev thuộc một trong ba loại. Một yêu cầu có hai phần: state (trạng thái), văn bản cần đánh giá, và một đối tượng questions chứa một hoặc nhiều câu hỏi đã được định kiểu. Jev trả lời tất cả trong một lần xử lý, mỗi câu trả lời được trả về dưới khóa mà bạn đã cung cấp.

Các ví dụ dưới đây là các lệnh gọi thực tế tôi đã thực hiện vào ngày 21 tháng 9 năm 2026. Chúng chạy trên typesafe/jev-1.13 thông qua Decisions API của OpenRouter, và nếu bạn thiết lập OPENROUTER_API_KEY, bạn có thể chạy các ví dụ như đã viết.

### Choice: chọn một tùy chọn từ một tập hợp cố định

Khi bạn nhận được một Choice từ API, nó luôn có ba thành phần: tùy chọn đã chọn, xác suất cho mọi tùy chọn và giá trị tin cậy.

Lệnh này gửi yêu cầu:

Phản hồi này cho thấy những gì API đã trả về:

Jev đọc các mô tả tiêu chí trước khi đưa ra lựa chọn, vì vậy hãy viết chúng như cách bạn hướng dẫn một nhân viên mới. Tài liệu tham khảo API của TypeSafe cho biết id câu hỏi (ở đây là team) không bao giờ được gửi đến mô hình. Tất cả ý nghĩa phải nằm trong các mô tả. Thứ hai, trường model đặt tên cho chính xác bản snapshot mà OpenRouter đã cung cấp.

### Score: xếp hạng trên các cấp độ có thứ tự mà bạn mô tả

Score nhận một mảng có thứ tự các mô tả cấp độ. Nó trả về một con số đại diện cho điểm số của văn bản và một chú giải ánh xạ từng chỉ mục trong mảng tới mô tả của nó, cộng với xác suất của Jev cho từng cấp độ và giá trị tin cậy.

Điểm số 1.15 là trung bình có trọng số xác suất của các cấp độ, 0.85 nhân 1 cộng 0.15 nhân 2, như hiển thị trong phản hồi trên. Lần chạy của riêng bạn sẽ chênh lệch vài phần trăm vì xác suất của Jev thay đổi nhẹ giữa các lần gọi. Khi đọc "chúng tôi vẫn có thể tải xuống các tệp xuất JSON" như một giải pháp thay thế, Jev chủ yếu rơi vào cấp độ 1. Nó cũng dành một phần trọng số cho "blocking" vì bộ phận tài chính không thể sử dụng giải pháp thay thế đó.

Vì điểm số nằm trên thang đo thứ tự, bạn phải giữ các cấp độ theo thứ tự thực tế từ thấp đến cao và mô tả từng cấp độ bằng từ ngữ. Tài liệu của TypeSafe liệt kê các chi tiết về nguyên hàm Score, bao gồm giới hạn tối đa 10 cấp độ.

### Noul: xác suất để một mệnh đề có/không là đúng

Noul là nguyên hàm đơn giản nhất trong ba loại. Nó nhận đầu vào là một mệnh đề và trả về xác suất câu trả lời là "có".

Lệnh dưới đây gửi yêu cầu:

Đây là phản hồi mà API đã trả về:

Hãy nhớ rằng câu trả lời Noul không có trường tin cậy riêng biệt. Xác suất chính là toàn bộ câu trả lời. Phần tiếp theo giải thích cách diễn giải nó.

### Hỏi cả ba trong một lệnh gọi

Bạn có thể tự hỏi, này, có bao nhiêu câu hỏi có thể nằm trong đối tượng questions đó? Bao nhiêu tùy thích. State không nhất thiết phải là một chuỗi đơn thuần: nó có thể là một đối tượng JSON với tất cả sự linh hoạt mà nó mang lại. Các hướng dẫn của bạn sau đó có thể tham chiếu đến các trường của nó bằng tên trong dấu backtick.

Giả sử bạn muốn hỏi một Choice, một Score và một Noul cùng lúc từ cùng một miền phiếu hỗ trợ trong một lần gửi yêu cầu.

Lệnh gửi yêu cầu này được hiển thị bên dưới.

Phản hồi hiển thị bên dưới là phản hồi mà API đã trả về.

Nếu mọi thứ diễn ra suôn sẻ, mỗi câu trả lời sẽ nằm dưới khóa mà bạn đã đặt cho nó. Trong mã, bạn sẽ có thể truy cập trực tiếp vào answers.team.choice và answers.refund.noul.

### Cách đọc xác suất và độ tin cậy của Jev

Có ba nguyên tắc cần ghi nhớ khi đọc xác suất và độ tin cậy của Jev.

Khi Noul gần mức 0.5, đó là cách Jev nói rằng nó không biết nên nghĩ gì. Hãy đọc nó như một trạng thái không chắc chắn. Hãy làm một thí nghiệm nhanh để thấy cách hoạt động. Tôi đã hỏi cùng một câu hỏi hoàn tiền, "Khách hàng có đang yêu cầu hoàn lại tiền không?", về trạng thái "Có hai khoản phí trên thẻ của tôi trong tháng này. Nếu một trong số đó là sai sót, các lựa chọn của tôi là gì?" trong hai lần gọi riêng biệt. Một lần trả về Noul là 0.52, và trên cùng một tin nhắn đó (vâng, nguyên văn), Jev trả về Noul là 0.49. Nếu bạn định nói, "Ồ, khách hàng chỉ đang yêu cầu hoàn tiền thôi mà", hãy cân nhắc rằng khách hàng chưa bao giờ yêu cầu hoàn tiền trong tin nhắn đó. Họ đang vòng vo, nhưng Jev cảm thấy sự giằng co theo hai hướng, và cả bạn lẫn tôi cũng sẽ không chắc chắn. Trong khi đó, yêu cầu hoàn tiền rõ ràng trong lệnh gọi Noul trước đó đạt 0.99. Bạn thấy quy luật chưa? Khi kết quả nằm ở giữa, hãy coi đó là một kết quả thứ ba, một kết quả mà bạn có thể hành động. Hãy đặt câu hỏi tiếp theo hoặc chuyển phiếu cho nhân viên xử lý.

Độ tin cậy của Choice và Score là thước đo mức độ tập trung của phân phối. Trọng số của phân phối càng dồn vào một kết quả thì độ tin cậy càng cao. Một lựa chọn tập trung quanh một tùy chọn duy nhất mang lại con số tin cậy cao, trên thang điểm từ 0 đến 1. Con số tin cậy càng cao, sự do dự giữa các tùy chọn càng ít. Nhưng chỉ vì Jev tập trung sự chú ý vào một tùy chọn không có nghĩa là câu trả lời đó đúng. TypeSafe rút ra các con số tin cậy từ hình dạng của các xác suất, không phải từ tính đúng đắn thực tế của chúng (tài liệu về độ tin cậy). Trong trường hợp cực đoan, một mô hình gán toàn bộ trọng số của nó cho một kết quả sẽ có độ tin cậy là 1.0, trong khi mức độ tập trung thấp hơn sẽ làm giảm con số đó.

Bạn có thể xác minh điều đó với ví dụ về thanh toán. Trạng thái này mơ hồ hơn: "Tôi đã nâng cấp lên Pro ngày hôm qua nhưng bảng điều khiển vẫn báo Free và tôi đã bị tính phí. Cái nào mới đúng?" Phản hồi dưới đây cho bạn thấy chính xác những gì API đã trả về: