Decision model: nhánh mới bên cạnh LLM sinh văn bản

Mấy năm qua, cách phổ biến nhất để “gắn AI” vào một phần mềm là gọi một Large Language Model. Cần phân loại ticket? Gọi LLM. Cần biết một email có phải phishing không? Gọi LLM. Cần chấm mức độ khẩn cấp của một sự cố? Vẫn gọi LLM, rồi dặn nó “chỉ trả về JSON”.

Nhưng nếu nhìn kỹ những chỗ đó, phần mềm không cần một đoạn văn. Nó cần một quyết định: route ticket này sang team nào, có chặn giao dịch này không, có cần một người xem lại không. Văn bản chỉ là lớp vỏ mà ta buộc model phải viết ra, để rồi code lại bóc lớp vỏ đó đi.

Series này nói về một hướng đi đang nổi lên để bỏ lớp vỏ ấy: decision model — model không sinh chuỗi, mà nhận vào trạng thái của chương trình cùng các câu hỏi có miền đáp án khai báo trước, rồi trả về quyết định có kiểu kèm phân phối xác suất. Đại diện rõ nhất hiện nay là JEV của TypeSafe AI, ra mắt ngày 15/09/2026.

Bài mở đầu này trả lời bốn câu hỏi: decision model là gì, nó khác LLM sinh văn bản và structured output ở đâu, JEV thực sự đã công bố những gì, và một decision model nên đứng ở đâu trong một hệ thống thật. Cơ chế bên trong — ba kiểu câu hỏi, parallel sampler, RLCD, calibration — để dành cho bài 2.

01Một quyết định bị bọc trong văn bản

Lấy một ví dụ rất quen: hệ thống chăm sóc khách hàng nhận được tin nhắn

“I was charged twice. Please fix this ASAP.”

và cần làm hai việc: chuyển ticket cho đúng team (billing, technical hay other), và quyết định có cần escalate gấp không.

Cách làm quen thuộc với LLM

Cách phổ biến là viết một prompt đại loại: “Đọc tin nhắn sau, cho biết nó thuộc team nào trong billing / technical / other và có khẩn cấp không. Trả lời bằng JSON có hai field department và urgent.” Model trả về một chuỗi. Code parse chuỗi đó, kiểm tra field có đủ không, giá trị có nằm trong danh sách không, rồi mới if/else.

Cách này chạy được — rất nhiều hệ thống production đang chạy đúng như vậy. Nhưng nó mang theo bốn điểm đau khá cụ thể.

Lệch format. Model có thể trả về "Billing" thay vì "billing", thêm một câu giải thích trước khối JSON, bịa ra một team "payments" không có trong danh sách, hoặc quên một field. Code phải có lớp parse, validate và retry cho tất cả những trường hợp đó.

Chậm. LLM sinh từng token, token sau phụ thuộc token trước. Ngay cả khi thứ ta cần chỉ là một nhãn, model vẫn phải đi hết chuỗi token của khối JSON, và thường còn “nghĩ” thêm trước đó nếu là reasoning model. Khi lời gọi này nằm trong một vòng lặp hay một chuỗi phụ thuộc, latency cộng dồn rất nhanh.

Tốn. Output token thường đắt hơn input token nhiều lần. Trả tiền cho những token dấu ngoặc, tên field và câu giải thích mà code sẽ vứt đi là một khoản chi khó biện minh khi số lời gọi lên tới hàng triệu.

Confidence không dùng được. Đây là điểm đau quan trọng nhất và cũng ít được nói tới nhất. Muốn tự động hoá, ta cần biết khi nào model không chắc: trường hợp chắc chắn thì cho chạy luôn, trường hợp mơ hồ thì chuyển người. Ta có thể bảo LLM “kèm theo confidence từ 0 đến 1”, nhưng con số đó là một chuỗi model tự viết ra, không phải một xác suất được đo. TypeSafe tóm điểm này rất gọn trong bài ra mắt: nếu một model làm đúng một task 95% số lần nhưng không nói được khi nào nó đang ở trong 5% còn lại, thì task đó không tự động hoá được.

Vấn đề không nằm ở độ thông minh

Để ý rằng không điểm đau nào ở trên là do model “không đủ thông minh”. Một LLM mạnh gần như chắc chắn phân loại đúng tin nhắn “charged twice” vào billing. Vấn đề nằm ở giao diện: ta đang dùng một model được tối ưu để viết văn bản cho con người đọc, rồi ép nó đóng vai một hàm trả về giá trị cho chương trình đọc.

Nói cách khác, tầng quyết định trong phần mềm cần ba thứ: đầu ra có kiểu để code dùng thẳng, xác suất đáng tin để đặt ngưỡng, và đủ nhanh, đủ rẻ để xuất hiện ở nhiều nhánh nhỏ trong chương trình. Nó không cần câu chữ hay.

Đó chính là khoảng trống mà decision model nhắm tới.

02Decision model là gì

Cách dễ nhất để hình dung decision model là so sánh giao diện của nó với giao diện của một LLM. Ghi chú gốc của series dùng đúng phép so sánh này:

LLM            : text / context            ->  một chuỗi bất kỳ
Decision model : state + typed questions   ->  typed probabilistic decisions

TypeSafe mô tả JEV bằng một câu gần như trùng khớp: “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out” — một lời gọi hàm có trí tuệ ở mức frontier, đầu vào là trạng thái không cấu trúc, đầu ra là quyết định có kiểu kèm xác suất.

Định nghĩa dùng trong series

Trong series này, decision model là model:

1. nhận vào một state — nội dung cần đánh giá, có thể là text, một object JSON hay một mảng;
2. cùng một hoặc nhiều câu hỏi có kiểu (typed questions), mỗi câu có miền đáp án khai báo trước khi gọi model;
3. và trả về, cho từng câu hỏi, một giá trị có kiểu nằm trong miền đó, kèm phân phối xác suất trên các đáp án.

Điểm then chốt nằm ở chữ “khai báo trước”. Với LLM, model quyết định nó sẽ viết gì; ta chỉ có thể dặn dò và hy vọng. Với decision model, chính ứng dụng định nghĩa không gian đáp án, và model chỉ được phân bổ xác suất lên không gian đó.

Ba kiểu câu hỏi

JEV định nghĩa ba kiểu câu hỏi. Bài này chỉ điểm tên để có từ vựng chung; cách mỗi kiểu hoạt động và đọc output ra sao là chủ đề của bài 2.

• Choice — chọn một trong các phương án đã biết. Hợp với routing, intent classification, chọn tool.
• Score — đặt trường hợp lên một thang có thứ tự. Hợp với mức khẩn cấp, mức rủi ro, độ liên quan.
• Noul — câu hỏi có/không, nhưng đầu ra không phải true/false mà là xác suất “có”. Hợp với guardrail, cổng duyệt, tín hiệu spam.

Ví dụ ticket ở trên, viết lại theo kiểu decision model

Ví dụ ở phần 1 trở thành một request gồm state và hai câu hỏi — một Choice và một Noul:

{
  "model": "jev-latest",
  "state": {
    "message": "I was charged twice. Please fix this ASAP."
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payment, invoice or refund problem",
        "technical": "Bug or product failure",
        "other": "None of the above"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Does this require urgent escalation?"
    }
  }
}

Và response có dạng:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "confidence": 0.95,
      "probabilities": { "billing": 0.95, "technical": 0.03, "other": 0.02 }
    },
    "urgent": {
      "type": "noul",
      "noul": 0.82
    }
  },
  "usage": { "input_tokens": 120, "output_tokens": 12 }
}

Có mấy điều đáng để ý trong ví dụ này.

Thứ nhất, câu trả lời cho department không thể là "payments" hay "Billing". Miền đáp án là ba key billing, technical, other — model chỉ được phân bổ xác suất lên đúng ba key đó.

Thứ hai, không có dòng nào cần parse. answers.department.choice đã là một giá trị trong enum của chương trình.

Thứ ba, và quan trọng nhất, mỗi câu trả lời đi kèm một con số mà code có thể đặt ngưỡng: confidence và probabilities với Choice, noul với câu hỏi có/không. Chuyển ticket sang billing khi confidence là 0.95 là một quyết định rất khác so với khi confidence là 0.55.

Hình 1 ở đầu bài đặt hai cách làm cạnh nhau. Hàng trên là đường đi quen thuộc qua LLM: prompt, sinh token tuần tự, ra chuỗi text hoặc JSON, parse và validate, rồi mới tới nhánh if/else. Hàng dưới là đường đi qua decision model: một request chứa state và các câu hỏi, model trả lời song song, đầu ra đã đúng schema, policy trong code đọc confidence rồi rẽ nhánh.

03Khác gì LLM sinh văn bản và JSON mode

Phản biện đầu tiên thường là: “Nhưng LLM bây giờ đã có JSON mode và structured output rồi mà?” Đúng vậy, và đây là chỗ cần tách bạch cẩn thận.

Structured output giải quyết được gì

JSON mode ở thế hệ đầu chỉ đảm bảo output là JSON hợp lệ. Structured output ở thế hệ sau đi xa hơn: một số nhà cung cấp dùng constrained decoding để đảm bảo output luôn khớp JSON Schema mà ta cung cấp. Tài liệu Structured Outputs của OpenAI chẳng hạn mô tả tính năng này là đảm bảo model “will always generate responses that adhere to your supplied JSON Schema”.

Như vậy, riêng điểm đau lệch format đã được structured output giải quyết khá tốt ở những API hỗ trợ nó. Nếu decision model chỉ khác LLM ở chỗ “đúng schema”, thì nó không đáng một series.

Structured output không giải quyết được gì

Những gì structured output không thay đổi nằm ở tầng sâu hơn:

• Cơ chế sinh vẫn là tuần tự. Constrained decoding chỉ giới hạn những token nào được phép ở mỗi bước; model vẫn sinh từng token một. Latency và chi phí vẫn tăng theo độ dài output.
• Mục tiêu tối ưu vẫn là văn bản. Model được huấn luyện để viết ra chuỗi mà con người ưa thích (RLHF) hoặc lời giải kiểm chứng được (RLVR). Việc nó điền đúng khuôn JSON là do ta ép từ bên ngoài, không phải điều nó được tối ưu để làm.
• Không có xác suất là đầu ra hạng nhất. Muốn có confidence, ta hoặc bắt model tự viết một con số, hoặc tự tính từ logprob của token (khi API cho phép). Cả hai đều không phải thứ model được huấn luyện để làm cho đúng. TypeSafe nhận xét rằng ngay cả khi được yêu cầu ước lượng confidence, LLM có xu hướng quá tự tin và thiếu nhất quán.

Bảng so sánh

Tổng hợp lại, dựa trên bảng so sánh trong bài ra mắt của TypeSafe và ghi chú gốc của series:

Hàng cuối không phải chi tiết phụ. Tài liệu của TypeSafe về điểm yếu của phiên bản jev-1.13 ghi thẳng: “jev-1.13 is not trained to generate text”, và lời khuyên cho trường hợp cần sinh văn bản là “Use a generative model”. Decision model không phải LLM tốt hơn — nó là một công cụ khác, bỏ hẳn khả năng viết để đổi lấy những thứ ở các hàng phía trên.

Đó cũng là lý do series dùng cách gọi “nhánh mới bên cạnh LLM”, không phải “nhánh mới của LLM”. TypeSafe gọi JEV là “a new class of frontier models” với “a new model architecture”, và FAQ của bài ra mắt nói thẳng “Jev is neither small nor an LLM”. Điều hãng chưa công bố là JEV được xây từ đâu và bên trong có phải transformer hay không. Gọi JEV là một loại LLM là đi ngược mô tả của chính TypeSafe.

Type safety không phải correctness

Có một cụm từ trong bài ra mắt của TypeSafe rất dễ bị đọc sai: JEV “can’t hallucinate”, và “the model never makes type errors”.

Vế thứ hai đúng theo nghĩa chặt: vì miền đáp án được định nghĩa trước, model không thể trả về một giá trị ngoài miền đó. TypeSafe gọi việc tìm một phản ví dụ là “mathematically impossible”, và trong biểu đồ so sánh tỉ lệ hallucination, hãng ghi chú rằng con số 0% của mình “is not empirical” — nó đến từ việc khớp schema được đảm bảo, không phải từ đo đạc.

Nhưng hãy quay lại ví dụ ticket. Giả sử tin nhắn là “The app crashed right after I paid, and now I see two charges”. Nó thuộc billing hay technical? Một decision model có thể trả về technical với confidence 0.7. Câu trả lời đó đúng kiểu — nó là một trong ba key hợp lệ — nhưng hoàn toàn có thể sai về mặt nghiệp vụ.

well-typed  !=  true

Cách đọc an toàn cho production, theo ghi chú gốc của series: “không hallucinate” nên hiểu theo nghĩa hẹp là không trả lời ngoài schema, chứ không phải “luôn đúng về thế giới”. Type safety loại bỏ một lớp lỗi — lỗi về hình dạng output. Xác suất đã calibrate giúp quản lý lớp lỗi còn lại — chọn sai một đáp án hợp lệ — bằng cách cho ta biết khi nào nên nghi ngờ. Nó không xoá lớp lỗi đó đi.

Bài 2 sẽ đào sâu phần này: calibration nghĩa là gì, vì sao nó là thuộc tính của một tập dự đoán chứ không phải của từng câu trả lời, và làm sao chọn ngưỡng trên traffic của chính mình.

04JEV — đại diện đầu tiên

Ngày 15/09/2026, TypeSafe AI công bố System One models — “a new class of frontier models built to make fast, structured decisions that software can use directly” — và model công khai đầu tiên của lớp này là JEV, mở ở dạng early access. Bài ra mắt do Diogo Almeida, founder của TypeSafe, viết. Tác giả bài ra mắt kể rằng từng tham gia xây dựng các phương pháp giúp language model biết làm theo chỉ dẫn ở OpenAI, và câu hỏi thúc đẩy cả dự án là: model đã giỏi chat hơn người từ lâu, vậy tự động hoá đang ở đâu?

Vì sao chọn JEV làm đại diện

Series chọn JEV vì bốn lý do:

• Đây là model thương mại đầu tiên định vị rõ lớp này. Không phải một head phân loại gắn lên LLM hay một thư viện prompt, mà là một model được thiết kế, huấn luyện và bán riêng cho việc ra quyết định có kiểu.
• Có API và SDK công khai. Mọi model đều đi qua endpoint POST /v1/systemone; có SDK chính thức cho Python và JavaScript. Nhờ đó các khẳng định về giao diện có thể kiểm chứng bằng source code, không chỉ bằng bài marketing.
• Có tài liệu điểm yếu theo từng phiên bản. TypeSafe duy trì một trang “model jaggedness” liệt kê những chỗ jev-1.13 làm kém — một thực hành hiếm thấy và rất hữu ích khi thiết kế hệ thống.
• Đã có hệ sinh thái. Ngoài SDK chính thức, TypeSafe có một adapter cho phép dùng LLM phía sau cùng giao diện; cộng đồng đã có các dự án phỏng theo giao diện của JEV. Bài 3 sẽ đi qua phần này.

Kèm theo đó là hai lưu ý lớn: JEV là model đóng — không có weights công khai — và các con số benchmark đều do chính hãng công bố.

Những gì TypeSafe đã công bố

Dưới đây là các điểm lấy trực tiếp từ bài ra mắt và trang tài liệu model của TypeSafe:

• Stack gồm ba phần: “a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD)”. Bài 2 sẽ giải thích từng phần ở mức mà tài liệu công khai cho phép.
• Choice tối đa 255 phương án: “Jev supports a cardinality up to 255”. Với tập lớn hơn, demo Wikiracing của hãng dùng hai tầng: chấm điểm độc lập để thu hẹp trước, rồi mới Choice.
• Latency: thời gian phản hồi end-to-end “70ms-500ms”, so với “3 to 329 seconds” cho các frontier model theo đo đạc của hãng; hãng nói mức này có thể nhanh hơn khoảng 40–200 lần “for System One shaped queries”.
• Giá: $0.042 cho một triệu input token ($42 cho một tỷ), output token “FREE (too cheap to meter)”. Để so sánh, hãng dẫn giá input của LLM từ $0.20 đến $10 cho một triệu token, và output token đắt hơn input khoảng 5 lần.
• Phiên bản hiện tại: trang tài liệu model liệt kê jev-1.13.0, context 64k token cho mỗi request, đầu vào chỉ là text (string, object JSON hoặc mảng). Alias jev-latest trỏ tới bản ổn định mới nhất; hãng khuyên pin ID phiên bản cụ thể nếu đã tinh chỉnh ngưỡng confidence theo phiên bản đó.

Benchmark 193.6× và 444.6× — đọc kèm lưu ý của chính hãng

Con số nổi bật nhất trên trang chủ TypeSafe là JEV nhanh hơn 193.6 lần và rẻ hơn 444.6 lần. Điều đáng ghi nhận là chính bài ra mắt đã tự nêu khá đủ các lưu ý đi kèm con số này:

• Các con số đến từ bộ workflow evals do hãng tự xây; hãng nói chúng “are on the higher end of real world gains” — tức là phía cao của mức cải thiện kỳ vọng ngoài thực tế.
• Các workflow không được chọn để làm JEV trông đẹp và không nằm trong dữ liệu huấn luyện, nhưng do người trong team model capabilities của hãng tạo, nên “some bias could exist”.
• Không có nhãn ground truth: đáp án tham chiếu là trung bình dự đoán của GPT-6 Astra và Fable 5.1, mà theo hãng thì thiên về các model của OpenAI và Anthropic.
• Các LLM trong so sánh được bọc qua wrapper “System One LLM” của hãng để trả về quyết định cùng định dạng — hãng nói đây là cách chính xác nhất để lấy quyết định từ LLM nhưng cũng chậm và tốn hơn so với để LLM trả quyết định không kèm xác suất.
• Các eval thường được chạy từ laptop của team ở Bờ Tây, nơi dịch vụ đang đặt.

Cách đọc hợp lý: đây là bằng chứng rằng chuyên môn hoá có thể đem lại cải thiện rất lớn trên đúng loại task mà nó nhắm tới — các câu hỏi hẹp, có miền đáp án, nằm trong workflow của phần mềm. Nó không phải bằng chứng rằng JEV “thông minh hơn LLM” nói chung, và không thay được việc đo trên workload của chính mình.

Vì sao tên là “System One” và “Jev”

Phần FAQ của bài ra mắt giải thích nguồn gốc hai cái tên. System One lấy cảm hứng từ cuốn Thinking, Fast and Slow của Daniel Kahneman, với phân biệt giữa System 1 — lối nghĩ nhanh, trực giác — và System 2 — lối suy luận chậm, có cân nhắc. Jev được đặt theo William Stanley Jevons: hãng kỳ vọng trí tuệ máy đi theo con đường giống than đá sau khi động cơ hơi nước hiệu quả hơn — chi phí giảm thì nhu cầu tăng, và mỗi bậc giảm chi phí mở ra thêm nhiều bậc use case.

Hãng cũng tự nhận rằng “System 1” thường mang hàm ý dễ sai, và nói sẽ giải thích sau vì sao họ tin System One models có thể đáng tin hơn các lựa chọn khác.

Cách hiểu của blog: nên đọc tên này như một ẩn dụ cho lớp sản phẩm — model tập trung vào các phán đoán nhanh, cục bộ, có biên — chứ không phải một khẳng định rằng JEV có “bộ não System 1 giống người”. Ẩn dụ này cũng gợi ra cách phân vai ở phần sau: decision model cho phán đoán nhanh, LLM cho phần suy luận chậm và mở.

Những gì chưa được công bố

Để giữ ranh giới giữa sự thật và suy đoán, cần nói rõ những gì hiện chưa có trong tài liệu công khai của TypeSafe:

• số tham số, số layer, thiết kế attention, và backbone có phải transformer hay không;
• cách hiện thực cụ thể của parallel sampler;
• loss và reward cụ thể của RLCD, cách tạo nhãn cho calibration;
• dữ liệu huấn luyện và compute;
• weights để tự host.

Vì vậy, series sẽ không khẳng định JEV “thực chất là một head phân loại gắn trên LLM”, “một encoder-only transformer” hay “một LLM bị bỏ decoder” — trừ khi TypeSafe công bố điều đó. Các dự án mã nguồn mở phỏng theo giao diện của JEV cũng không chứng minh được rằng kiến trúc bên trong JEV giống chúng.

05Decision model đứng ở đâu trong hệ thống

Nếu decision model không viết được văn bản, còn LLM thì chậm và không cho xác suất đáng tin, thì câu hỏi thực tế là: trong một hệ thống thật, ai làm việc gì?

Hình 2 chia hệ thống thành bốn vai. Mỗi vai giữ đúng phần việc mà nó có lợi thế.

Code giữ phần xác định

Mọi thứ có thể viết thành quy tắc chính xác thì để code làm: số học, đếm, so sánh ngày giờ, kiểm tra quyền, kiểm tra ID khớp chính xác, và mọi side effect như hoàn tiền hay khoá thẻ. Đây không chỉ là lời khuyên chung chung: danh sách điểm yếu của jev-1.13 ghi rõ “Jev is not a calculator”, khuyên để phép tính trong code, và cho biết model đọc ngày tháng như text chứ không như đại lượng có thứ tự.

Code cũng làm bước tiền xử lý: lọc state xuống đúng những gì câu hỏi cần. Tài liệu của TypeSafe cho biết độ chính xác giảm khi state phình ra với nội dung không liên quan tới quyết định.

Decision model giữ các phán đoán mờ có biên

Decision model trả lời những câu hỏi mà if/else viết tay không làm nổi nhưng miền đáp án thì đã rõ: ý định chính của khách hàng là gì, tin nhắn này có dấu hiệu gian lận không, mức bực bội bao nhiêu, đoạn văn này có liên quan tới câu hỏi không.

Ghi chú gốc của series và bài ra mắt của TypeSafe cùng gợi ý một nguyên tắc: tách nhỏ câu hỏi. Thay vì hỏi “case này nên xử lý thế nào?”, hãy hỏi riêng từng tín hiệu — intent, fraud, urgency — rồi để code kết hợp. Business rule vì vậy vẫn nằm trong code, còn model chỉ cung cấp các tín hiệu ngữ nghĩa.

Policy trong code đọc xác suất

Đây là chỗ xác suất trở nên có giá trị. Thay vì một ngưỡng chung cho mọi việc, policy đặt ngưỡng theo hậu quả của hành động. Gợi ý một bài viết cho khách thì sai cũng không sao, có thể tự động ở confidence vừa phải. Hoàn tiền thì cần ngưỡng cao hơn nhiều, hoặc luôn có người xem. Con số cụ thể phải chọn dựa trên traffic thật và chi phí của mỗi loại sai — bài 2 sẽ nói kỹ về chuyện này.

LLM giữ phần viết và lý luận mở

Khi quyết định là “cần trả lời khách một email”, “cần tóm tắt lịch sử case”, hay “cần lập kế hoạch nhiều bước”, đó là việc của LLM. Decision model còn có thể đứng trước LLM để quyết định có cần gọi nó hay không, và đứng sau LLM để chấm hay kiểm tra output của nó — bài ra mắt của TypeSafe liệt kê “Score, judge, verify, guardrail” output của LLM như một use case.

Con người giữ các ca khó

Ca có hậu quả lớn, hoặc confidence thấp, đi tới người duyệt. Đây không phải điểm yếu của thiết kế mà là mục đích của nó: vì decision model trả về xác suất, hệ thống biết ca nào cần người, thay vì đưa mọi thứ cho người hoặc không đưa gì cả.

Quay lại ví dụ ticket

Với tin nhắn “I was charged twice. Please fix this ASAP.”, luồng hybrid có thể trông như sau:

1. Code lấy tin nhắn và vài field cần thiết của tài khoản; không gửi cả lịch sử giao dịch.
2. Decision model trả lời department (Choice) và urgent (Noul).
3. Policy: nếu department là billing với confidence cao thì route thẳng; nếu urgent vượt ngưỡng thì gắn cờ ưu tiên.
4. Nếu cần soạn một phản hồi cho khách, gọi LLM viết bản nháp.
5. Nếu confidence của department thấp, hoặc hành động tiếp theo là hoàn tiền, chuyển người xem.

Không bước nào cần parse văn bản để lấy ra quyết định. Và ở mỗi nhánh, hệ thống có một con số để giải thích vì sao nó đi nhánh đó.

06Tổng kết

Decision model không phải một LLM tốt hơn. Nó là một câu trả lời khác cho câu hỏi “làm sao để phần mềm dùng được AI”: thay vì để model viết một chuỗi rồi cầu mong chương trình hiểu được nó, hãy định nghĩa trước miền quyết định và để model trả về xác suất mà code dùng trực tiếp.

Những gì nên mang theo:

• phần lớn chỗ gắn LLM vào phần mềm thực ra chỉ cần một quyết định — route, gate, score, escalate — chứ không cần một đoạn văn;
• decision model nhận state cùng các câu hỏi có miền đáp án khai báo trước, và trả về quyết định có kiểu kèm phân phối xác suất;
• structured output của LLM giải quyết được chuyện lệch schema, nhưng không đổi cơ chế sinh tuần tự và không biến xác suất thành đầu ra hạng nhất;
• đúng schema không có nghĩa là đúng — type safety loại một lớp lỗi, calibration giúp quản lý lớp còn lại, không xoá nó;
• JEV của TypeSafe AI là đại diện đầu tiên có API, SDK và tài liệu điểm yếu công khai, nhưng là model đóng và benchmark do hãng tự công bố, kèm các lưu ý chính hãng nêu;
• “decision model” là cách gọi của blog; TypeSafe gọi lớp này là System One models, lấy từ System 1 / System 2 của Kahneman;
• trong một hệ thống thật, code giữ phần xác định, decision model giữ phán đoán mờ có biên, LLM giữ phần viết và lý luận mở, con người giữ các ca khó.

Bài tiếp theo trong series mở hộp JEV ở mức tài liệu công khai cho phép: vòng request/response đầy đủ, ba kiểu câu hỏi Choice, Score, Noul và cách đọc output của từng kiểu, parallel sampler và RLCD là gì, calibration nghĩa là gì trong thực tế, danh sách điểm yếu của jev-1.13, và một mục riêng cho những gì TypeSafe chưa công bố. Sau đó, bài 3 đi qua hệ sinh thái quanh JEV, và bài 4 áp dụng decision model vào một bài toán cụ thể: thiết kế một Chrome extension trích xuất dữ liệu web.

Tài liệu tham khảo

• TypeSafe AI — Introducing System One Models & Jev, 15/09/2026 (bài ra mắt, bảng so sánh với LLM, workflow evals và các lưu ý, FAQ về tên gọi)
• TypeSafe AI — Models (phiên bản jev-1.13.0, giá, context, alias jev-latest)
• TypeSafe AI — Jev 1.13 jaggedness (điểm yếu của jev-1.13, gồm mục Generation)
• TypeSafe AI — typesafe-sdk-python và schema request/response
• TypeSafe AI — API reference
• TypeSafe AI — Workflow evals
• TypeSafe AI — system-one-adapter-python
• OpenAI — Structured Outputs
• Daniel Kahneman — Thinking, Fast and Slow, 2011
• Ghi chú gốc của tác giả: “JEV Deep Dive — Cách model System One hoạt động” (Notion, 30/09/2026)