Định tuyến và rào chắn cho LLM nên làm thế nào? Ví dụ về cộng tác giữa Jev và mô hình ngôn ngữ lớn

Công bố lợi ích và bằng chứng: PandaNpc đang phát triển lớp ra quyết định của Agent sử dụng Jev. Phần dưới đây lần lượt trích dẫn tài liệu chính thức của TypeSafe, cookbook chính thức, cùng các lệnh gọi Jev thực tế và hiệu chuẩn kịch bản tổng hợp trong kho của chúng tôi. Việc hiệu chuẩn của chúng tôi sử dụng nhà cung cấp LLM giả được kịch bản hóa, không thể đại diện cho lưu lượng người dùng thực hoặc hiệu năng của toàn bộ chuỗi sản xuất.

Định tuyến LLM có thể làm như sau: trước tiên để Jev phán đoán yêu cầu thuộc loại nào, rủi ro cao đến đâu, sau đó mã code quyết định giao cho hàm thông thường, LLM chuyên biệt, hay con người xem xét. Jev cũng có thể được đặt giữa truy xuất và sinh để sàng lọc bằng chứng, hoặc đặt sau đầu ra của LLM để kiểm tra kết quả. Nó trả về các lựa chọn đóng, điểm số và xác suất; trả lời mở, sinh mã và suy luận dài vẫn do LLM đảm nhiệm. Mô tả của TypeSafe về tác nhân viết mã chỉ rõ rằng Jev không thể thay thế trực tiếp mô hình trò chuyện đằng sau Claude Code hoặc Codex.

Bài viết này sử dụng một yêu cầu chăm sóc khách hàng, một pipeline hỏi đáp RAG và hồ sơ hiệu chuẩn Agent của chúng tôi, để giải thích hai loại mô hình thực sự bàn giao ở đâu, và vì sao kết quả có độ tin cậy thấp phải có nơi đến rõ ràng.

Jev có thể phán đoán gì, LLM tiếp tục đảm nhiệm gì?

Tính đến ngày 23 tháng 9 năm 2026, trang mô hình của TypeSafe liệt kê mô hình ổn định là jev-1.13.0. API nhận một state và một tập questions, thông qua POST /v1/systemone trả về answers có cấu trúc tương ứng. jev-latest vào ngày đó trỏ tới 1.13.0, nhưng bí danh sẽ thay đổi theo phiên bản; hệ thống đã hiệu chuẩn ngưỡng nên cố định phiên bản và ghi lại ID mô hình thực tế trong phản hồi.

Noul không có trường confidence độc lập; không thể viết trực tiếp một xác suất Noul thành “độ tin cậy của mô hình”. Score cũng không nên được dùng để tính số tiền chính xác. Số tiền, so sánh ngày tháng, hạn ngạch và kiểm tra quyền nên nằm trong chương trình tất định, tài liệu chính thức đã liệt kê các ranh giới này của Jev 1.13.

Hình dạng tối thiểu của một lệnh gọi

Hình dạng yêu cầu dưới đây nhất quán với tham chiếu API chính thức, câu hỏi ví dụ là cấu hình minh họa do bài viết này tạo, không có thử nghiệm trực tuyến nào được thực hiện cho nó trong bài này:

Đoạn JSON dưới đây sử dụng thông điệp khách hàng bằng tiếng Anh; trong tiếng Việt, khách hàng sẽ nói “Đơn hàng bị trừ tiền trùng, xin giúp tôi hoàn tiền.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Hệ thống thực tế cũng nên dùng mã code kiểm tra trước xem bản ghi trừ tiền có thuộc cùng một đơn hàng không, có cho phép hoàn tiền không. Ví dụ trên chỉ dùng đểọc ý định người dùng; người dùng yêu cầu hoàn tiền không có nghĩa là tư cách hoàn tiền đã được chứng minh, càng không cấu thành ủy quyền thực hiện hoàn tiền trực tiếp.

Dùng Jev để định tuyến LLM: ba đường bàn giao

Ví dụ định tuyến ý định chính thức của TypeSafe giao yêu cầu chăm sóc khách hàng cho Jev phán đoán ý định và độ phức tạp trước, sau đó mã code phân luồng: tra trạng thái đơn hàng đi qua hàm cơ sở dữ liệu; câu hỏi sản phẩm và đổi trả hàng lần lượt đi qua LLM chuyên biệt đã nạp tài liệu khác nhau; khiếu nại phức tạp hoặc kết quả có độ tin cậy thấp vào hàng đợi con người. Đây chính là sự cộng tác dễ hiểu nhất giữa Jev và LLM: bên trước đa ra phán đoán có cấu trúc, bên sau chỉ xuất hiện khi cần sinh giải thích hoặc hội thoại.

Khi triển khai có thể thiết kế theo trình tự dưới đây, thay vì để mô hình tự do quyết định mọi hành động:

1. Định nghĩa đường đi trước: Liệt kê rõ ràng các yêu cầu mà hàm thông thường, từng LLM chuyên biệt, con người xem xét có thể xử lý, và để Choice có other hoặc lựa chọn dự phòng tương tự.
2. Đưa sự thật vào state: Lời nói gốc của người dùng, trạng thái tài khoản, bản ghi đơn hàng tách thành các trường riêng; đừng coi văn bản trang web không rõ nguồn gốc là chỉ thị hệ thống.
3. Hỏi câu hỏi hẹp mỗi lần: Ý định dùng Choice, rủi ro hoặc mức khẩn cấp dùng Score, sự thật đơn điểm cần xác nhận dùng Noul. Tài liệu chính thức khuyến nghị nhiều câu hỏi độc lập cùng chia sẻ một state có thể được đánh giá song song trong cùng một yêu cầu.
4. Để mã code định tuyến cuối cùng: Kiểm tra quyền và quy tắc cứng trước, sau đó xem xác suất của Jev và ngưỡng đã hiệu chuẩn theo nghiệp vụ này; yêu cầu có độ tin cậy thấp hoặc thiếu bằng chứng đi qua con người hoặc hỏi bổ sung.
5. Ghi lại kết quả và xem xét lại: Lưu phiên bản mô hình, phiên bản câu hỏi, xác suất, đích đến cuối cùng và kết quả sửa lỗi của con người, mới có thể đánh giá ngưỡng có phù hợp không.

Nguồn hình: TypeSafe AI《Giới thiệu System One Models & Jev》, 2026-09-15. Bốn workflow do TypeSafe tự xây dựng, chỉ số được tổng hợp theo trọng số bằng nhau giữa các workflow; phương pháp đánh giá xem tại đánh giá workflow TypeSafe.

Biểu đồ chính thức này có thể giúp hiểu vì sao họ nhấn mạnh “đưa nhiều phán đoán hẹp vào workflow chương trình”. Trục tung trên biểu đồ giữ cách gọi “accuracy” của nhà cung cấp, nhưng đáp án tham chiếu đến từ đồng thuận xác suất dự đoán của hai mô hình lớn, không phải đáp án đúng duy nhất đã được con người xác minh; chi phí và chỉ số cũng phụ thuộc vào bốn workflow này và phương pháp đánh giá của nhà cung cấp, không thể quy đổi thành “tiết kiệm được bao nhiêu trong mọi tình huống”.

Sinh tăng cường truy xuất: Jev sàng lọc bằng chứng trước khi LLM trả lời

Cookbook phân loại đoạn RAG của TypeSafe cung cấp ví dụ đa mô hình cụ thể hơn: OpenAI embedding truy xuất đoạn trước, Jev hỏi bốn Noul cho mỗi “câu hỏi + đoạn” — có liên quan không, có chứa bằng chứng dùng được để trả lời không, có phản bác tiền đề trong câu hỏi không, có cố gắng ra chỉ thị cho mô hình trả lời không. Mã code xử lý bốn xác suất theo thứ tự, quyết định đặt đoạn đó vào vùng bằng chứng, vùng bằng chứng xung đột, hoặc loại bỏ; cuối cùng Claude Sonnet 5 viết câu trả lời.

Bước này giải quyết một vấn đề phổ biến: đoạn có độ tương đồng vector cao chưa chắc dùng được. Nó có thể chỉ dùng từ tương tự, cũng có thể là một bài đăng diễn đàn có cài prompt injection “bỏ qua phần trước”. Ví dụ trong cookbook đặt kiểm tra injection lên đầu quy tắc định tuyến, đồng thời nhắc rằng ngưỡng là điểm khởi đầu được chọn cho ngữ liệu đó, không phải giá trị mặc định cho mọi ứng dụng RAG. Các con số trình diễn của nó đến từ jev-1.12 ngày 2026-08-27, không thể coi là kết quả đánh giá mới của jev-1.13.0 hiện tại.

Sau khi sinh cũng có thể làm một lớp đối chiếu. Cookbook kiểm tra trích dẫn của TypeSafe dùng chương trình tìm nguyên văn trích dẫn trước, sau đó dùng Jev phán đoán đoạn đó có ủng hộ, phản bác hay không đề cập đến luận điểm được sinh ra. Nó có thể chọn ra những trích dẫn đáng xem xét lại; bản thân phán đoán của mô hình vẫn có thể sai, không thể viết “đã qua kiểm tra” thành bảo đảm sự thật.

Hiệu chuẩn Agent của chúng tôi: nâng cấp khi độ tin cậy thấp sẽ tắc ở đâu?

Trong kho PandaNpc, client Jev, ngân hàng câu hỏi và bộ điều phối dùng Jev cho nhận diện ý định của Agent, chấm điểm sửa đổi ứng viên, đối chiếu điều kiện hoàn thành và phán đoán gửi. Client cũng thực hiện thử lại có giới hạn với timeout, 429, 5xx, đặt giới hạn cho ngân sách yêu cầu và kết quả quá hạn; quyền thực thi do bộ điều phối và lớp công cụ được kiểm soát nắm giữ, không do một câu phán đoán của Jev trực tiếp cấp.

Chúng tôi vào ngày 2026-09-22 dùng jev-1.13.0 chạy 19 turn tổng hợp mỗi turn một lần shadow, một lần enforce, tổng cộng 38 lần chạy, ghi lại 165 quyết định Jev thực tế. Báo cáo hiệu chuẩn nội bộ này và các phản hồi máy thật được lưu giữ sử dụng nhà cung cấp LLM giả được kịchản hóa, vì vậy những dữ li này chỉ cho thấy biểu hiện quy định trong kịch bản được kiểm soát. Chúng không thể chứng minh tỷ lệ thành công tổ thể, tỷ lệ tiết kiệm hay độ trễ đầu cuối dưới yêu cầu người dùng thực.

Phátện có giá trị nhất không phải tốc độung bình, mà là một ngưỡng “trông có vẻ an toàn” gây tắc nghẽn: trong 19 turn enforce, có 13 turn tại Q2 “thông tin có đủ để bắt đầu sửa đổi không” bị nâng cấp vì xác suất Noul rơi vào khoảng không chắc chắn 0.15–0.85 đã định; LLM Worker không có cơ hội thực hiện các bước tiếp theo. Bản ghi hiệu chuẩn cho thấy, trong 34 quyết định Q2 được gắn nhãn là thông tin đầy đủ, nhiều xác suất nằm ở đoạn giữa. Báo cáo đề xuất tách Q2 phức tạp thành các phán đoán nguyên tử hơn, hoặc điều chỉnh quy tắc nâng cấp; đây là đề xuất, không phải ngưỡng đã được triển khai.

Ngân hàng câu hỏi của chúng tôi phán đoán lối vào thành answer_only, inspect, modify hoặc out_of_scope; trên đường ghi, các sửa đổi ứng viên do Worker đề xuất trước tiên được Score sắp xếp, nội dung và tóm tắt thay đổi cuối cùng mới qua nghiệm thu và phán đoán gửi. Đây chỉ là các điểm quyết định: có thể thực sự đọc ghi đối tượng hay không, vẫn do bộ thực thi được kiểm soát cấp quyền theo giai đoạn. Jev không có quyền tự nới lỏng whitelist công cụ, cũng không thể bỏ qua kiểm tra nhất quán trước khi gửi.

Dữ liệu hiệu chuẩn tiết lộ một đánh đổi khác. Ở chế độ shadow, Jev đưa câu trả lời và phân phối đầy đủ, nhưng không thay đổi đường thực thi ban đầu của Worker; ở chế enforce, câu trả lời ảnh hưởng đến việc tiếp tục, nâng cấp hay loại bỏ. Lấy độ chính xác của shadow trực tiếp làm tỷ lệ hoàn thành của enforce sẽ nhìn sai hệ thống: việc nâng cấp ở Q2 sẽ chặn nhiệm vụ từ sớm, khiến các câu hỏi chấm điểm ứng viên, nghiệm thu và gửi sau đó hoàn toàn không có cơ hội xuất hiện. Vì vậy báo cáo này đọc riêng phân phối từng câu hỏi, hướng nâng cấp và trạng thái cuối cùng.

Trong các sửa đổi ứng viên có một đối chiếu cụ thể: trong cùng một turn, ứng viên sửa đổi mục tiêu chính xác được 2.94 điểm, còn ứng viên ghi đè toàn bộ tệp được 0.38 điểm; ứng viên điểm cao được chọn. Ví dụ này chỉ cho thấy trong tình huống tổng hợp đó, câu hỏi chấm điểm phân biệt được hai phương án. Ngược lại, một ứng viên có bằng chứng bị cắt ngắn được 2.27 điểm, không thể vì con số trông “cũng được” mà bỏ qua độ tin cậy thấp và dấu hiệu cắt ngắn của nó. Mã code của chúng tôi đánh dấu riêng bằng chứng không đầy đủ, tránh để mô hình chỉ dựa vào phần tiền tố được giữ lại đưa ra phán đoán ghi xác định.

Chúng tôi còn tách “chọn ứng viên nào” và “cho phép nó ghi” thành hai bước khác nhau. Sau khi ứng viên được Jev chấm điểm, bộ thực thi được kiểm soát chỉ mở công cụ ghi ở giai đoạn ACT/modify; phiếu một lần được phát hành liên kết với ID gọi công cụ, số hiệu bản sửa đổi hiện tại, hash đối tượngục tiêu và tóm tắt tham số.ể cả văn bản ứng viên dụ m hình “bỏ qua giới hạn”, nó cũng không lấy được quyền công cụ vượt qua các kiểm tra này. Đây là kinh nghiệm chúng tôi rút ra từ tích hợp cấp mã code: phán đoán xác suất quyết định con đường nào đáng đi, quyền tác dụng phụ do điều kiện chương trình có thể xem xét lại quyết định.

Đường thất bại cũng phải được thiết kế. Client chỉ thử lại có giới hạn khi timeout, lỗi mạng, 429 hoặc 5xx; câu trả lời sau khi hủy hoặc vượt thời hạn turn bị loại bỏ trực tiếp. Nếu Jev không khả dụng ở chế độ enforce, khi chưa được ủy quyền giảm cấp thì không thể tiếp tục; khi được phép đi llm_only, bộ thực thi khóa chỉ đọc. Nếu nhánh đã xảy ra sửa đổi rồi mới mất Jev, bộ điều phối đánh dấu toàn bộ lượt là thất bại, thay vì để LLM tiếp theo bù ghi trong tình huống thiếu lớp quyết định. Những đường này có cái giá với trải nghiệm người dùng, nhưng khiến “mô hình tạm thời không khả dụng” không âm thầm biến thành “quyền ghi vẫn nhưũ”.

Báo cáo hiệu chuẩn còn phân biệt “nâng cấp do độ tin cậy thấp” và “từ chối thực thi”. Ví dụ một discard đúng nếu độ tin cậy không đạt ngưỡng 0.85 thống nhất, sẽ bị ghi là cần người dùng nhập; điều này không đồng nghĩa với việc cho qua sai. Báo cáo dựa vào đó đề xuất tách ngưỡng gửi và loại bỏ, nhưng hiện vẫn là đề xuất. Khi viết workflow phải phân biệt ba kết quả: cho qua sai, từ chối sai và chờ xét duyệt, nếu không cùng một tập dữ liệu sẽ dẫn đến kết luận ngưỡng sai.

Ca này cho chúng tôi biết, sự phối hợp giữa Jev và LLM không thể chỉ vẽ thành “Jev phán đoán trước, LLM làm việc sau”. Mỗi phán đoán đều phải hỏi: khoảng không chắc chắn rộng đến đâu? Liệu có khiến bộ xử lý tiếp theo mãi mãi không nhận được nhiệm vụ? Nếu bằng chứng đầu vào bị cắt ngắn, có thể nâng cấp rõ ràng thay vì đoán không? Trong triển khai của chúng tôi, trình tạo state ghi lại evidence_truncated, và để bên gọi coi đường thiếu bằng chứng là không chắc chắn; các tính toán tất định như đếm, sắp xếp được hoàn thành trước trong mã code, không giao cho Jev đoán. Các giới hạn đã biết của Jev 1.13 chính thức cũng khuyến nghị giữ phép đếm và số học trong mã code.

Nên đặt rào chắn LLM ở đâu?

Cookbook rào chắn LLM của TypeSafe đặt Jev ở hai bên đầu vào và đầu ra của LLM. Nó dùng một tập Noul để nhận diện các rủi ro khác nhau, dùng Score để đo mức độ nghiêm trọng, sau đó mã code dựa trên chính sách quyết định cho qua, con người xem xét lại, chặn hoặc chuyển hỗ trợ. Đầu ra cũng phải kiểm tra, vì đầu vào thông thường vẫn có thể tạo ra kết quả sinh không phù hợp.

Ranh giới của loại rào chắn này cũng rõ ràng: Jev có thể kiểm tra nội dung theo các câu hỏi được viết sẵn, nhưng không phải chứng minh an toàn vạn năng. Tài liệu giới hạn chính thức đề cập rõ rằng nội dung độc hại có thể ảnh hưởng đến phán đoán, yêu cầu viết rõ criteria và kiểm thử ranh giới. Trong mẫu tổng hợp của chúng tôi từng làm 16 lần thăm dò injection nhắm vào tham số ứng viên, ghi nhận 0 lần đảo thứ tự; mẫu quá nhỏ, không thể suy ra “chống prompt injection đã được giải quyết”. Thứ thực sự quyết định công cụ có thể làm gì, vẫn là danh sách cho phép, cổng giai đoạn và kiểm tra trước khi gửi trong mã code.

Khi nào phù hợp để dùng, khi nào không nên dùng?

Phù hợp với Jev là: tập ứng viên đã biết, vấn đề có thể tách thành vài phán đoán ngắn, phần mềm cần xác suất để quyết định tự động xử lý hoặc nâng cấp con người. Ví dụ định tuyến chăm sóc khách hàng, sàng lọc đoạn RAG, chấm điểm hành động ứng viên của Agent, kiểm tra trích dẫn trong kết quả sinh. Nếu nhiệm vụ yêu cầu viết một thư trả lời, sửa một đoạn mã hoặc giải thích quá trình suy luận phức tạp, thì do LLM đảm nhiệm. Nếu nhiệm vụ là tính tiền chính xác, so sánh ngày tháng hoặc kiểm tra kiểm soát truy cập, chương trình nên tính trực tiếp. Trang mô hình còn nêu rõ Jev chỉ nhận văn bản, tiếng Anh là ngôn ngữ huấn luyện hiện có biểu hiện tốt nhất; kịch bản tiếng Trung cần dùng dữ liệu của riêng mình để đánh giá, không thể bê nguyên ngưỡng của cookbook tiếng Anh.

Nếu muốn quan sát Agent thực tế xử lý quyền và gọi công cụ như thế nào, có thể xem trước PandaNpc Agent; về ranh giới và tình huống sử dụng của coding Agent, cũng có thể tham khảo So sánh Claude Code và Codex.

Độc giả có thể bắt đầu với một tập xác minh rất nhỏ: chun bị bốn loại mẫu “rõ ràng có thể tự động xử lý”, “rõ ràng nên từ chối”, “ngữ nghĩa mơ hồ”, “chứa chỉ thị độc hại”; trước tiên xác định nhãn do con người gán, sau đó ghi lại xác suất từng câu hỏi và kết quả định tuyến của Jev. Tiêu chí thành công không phải mọi mục đều tự động đạt, mà là tỷ lệ lỗi của đường tự động xử lý và lượng nâng cấp con người đều nằm trong phạm vi bạn có thể chấp nhận. Nếu mẫu mơ hồ tắc hàng loạt ở cùng một câu hỏi, trước tiên kiểm tra câu hỏi có lẫn nhiều phán đoán không, state có quá dài không hoặc ngưỡng có được hiệu chuẩn theo dữ liệu cục bộ không.

FAQ

Jev có thể thay thế Claude Code, Codex hoặc mô hình trò chuyện không? Không. TypeSafe định vị nó là mô hình quyết định có cấu trúc trong phần mềm; trò chuyện, viết lách và sinh mã vẫn cần LLM.

Loại trả về cố định, có phải sẽ không mắc lỗi? Không. Loại cố định giảm vấn đề phân tích cú pháp và đầu ra vượt phạm vi, nhưng phân loại, chấm điểm và phán đoán sự thật vẫn có thể sai. Đường có độ tin cậy thấp và rủi ro cao nên giữ lại con người xem xét lại.

Có thể hỏi mấy câu hỏi trong cùng một yêu cầu? Có thể đặt nhiều Choice, Score, Noul độc lập cùng chia sẻ một state vào một yêu cầu. Các câu hỏi được đánh giá riêng, phán đoán phức tạp vẫn nên tách ra, rồi do mã code kết hợp.

Tiếng Trung có dùng được không? Tài liệu chính thức nói hỗ trợ ngôn ngữ tự nhiên bao gồm chữ Trung, Nhật, Hàn, nhưng độ chính xác tiếng Anh hiện tốt nhất. Khối lượng công việc tiếng Trung cần xác minh và hiệu chuẩn riêng.