Giải thích RLCD: Vì sao TypeSafe huấn luyện Jev trung thực về sự tự tin thay vì được yêu thích

Jev 1.13 (typesafe/jev-1.13) được huấn luyện bằng một phương pháp mà nhà sản xuất gọi là Reinforcement Learning for Calibrated Decisions — RLCD — và từ viết tắt đó là do TypeSafe tự đặt ra chứ không phải một thuật ngữ ngành mà bạn được cho là đã biết. Bài đăng ra mắt nói thẳng điều đó: công ty đã xây dựng "một kiến trúc mô hình mới, bộ lấy mẫu song song để đạt hiệu suất tối đa, và phương pháp huấn luyện mà chúng tôi gọi là Reinforcement Learning for Calibrated Decisions (RLCD)". Đây là câu trả lời thứ ba cho một câu hỏi từng chỉ có hai, và lý do nó tồn tại là sự không khớp mà hầu hết các nhóm gặp phải lần đầu khi cố đưa một mô hình ngôn ngữ vào một quyết định. Trước khi đi vào điều đó, có hai mốc thời gian quan trọng, bởi vì trang này không phải là một bài ra mắt. TypeSafe đã phát hành chính mô hình này vào 2026-09-15, nằm ngoài cửa sổ bảy ngày mà blog này viết tới, và không nên đọc bất cứ điều gì ở đây như thể đang coi Jev là mới. Sự kiện có ngày tháng là 2026-09-24, khi OrcaRouter thêm typesafe/jev-1.13 vào danh mục của chính mình và mở model card cho nó — lần đầu tiên Jev có thể được gọi qua một gateway bên thứ ba thay vì chỉ qua endpoint riêng của TypeSafe. Đó là thay đổi mà trang này dựa vào, và hệ quả thực tế là kỹ thuật bên dưới giờ đây là thứ bạn có thể thử trong mã nguồn bằng một khóa bạn có thể đã có sẵn, thay vì một ý tưởng nghiên cứu mà bạn đọc được.

Những gì sau đây là khái niệm, không phải mô hình. Một phần ba đầu của trang này nói về hai phương pháp huấn luyện mà RLCD được thiết kế để chống lại, bởi vì RLCD chỉ dễ hiểu khi được xem như một cách khắc phục những gì hai phương pháp kia làm khi tác vụ không còn là một cuộc trò chuyện nữa mà trở thành một sự phán xét. Nếu bạn đã biết RLHF và RLVR tối ưu hóa cho điều gì, phần bạn muốn là phần thứ ba, nơi bảng ba hướng của chính TypeSafe đảm nhiệm công việc.

RLHF tối ưu hóa cho câu trả lời mà một người ưa thích

Học tăng cường từ phản hồi của con người là phương pháp đã biến các mô hình ngôn ngữ được huấn luyện trước thành trợ lý. Tài liệu nhập môn của chính TypeSafe nêu mục tiêu này một cách thẳng thừng, trong một thẻ có tiêu đề RLHF: nó “đã biến các mô hình được huấn luyện trước thành chatbot. Nó huấn luyện các mô hình tạo ra những phản hồi mà con người ưa thích.” InstructGPT và ChatGPT đã được huấn luyện bằng phương pháp này, và tài liệu nhập môn bổ sung một chi tiết liên quan ở đây vì một lý do khác — cách tiếp cận này được đồng phát minh bởi Diogo Almeida, người đồng sáng lập TypeSafe và là tác giả bài đăng ra mắt của Jev. Công ty không hề gạt bỏ phương pháp này; nó được thành lập bởi một người đã góp phần xây dựng nên phương pháp đó. Công ty đang lập luận rằng mục tiêu ấy là sai đối với một nhiệm vụ cụ thể.

Cách rõ ràng để thấy sự không khớp là hỏi tín hiệu phần thưởng thực sự đo lường điều gì. Dưới RLHF, nó đo mức độ ưu tiên của người chấm giữa hai phản hồi ứng viên. Đó là một đại diện thay thế xuất sắc khi sản phẩm là một cuộc trò chuyện, bởi tiêu chí thành công của một cuộc trò chuyện thực sự là liệu một người có thấy câu trả lời tốt hay không. Đó là một đại diện thay thế hỏng khi sản phẩm là một quyết định, bởi tiêu chí thành công ở đó là liệu độ tự tin được nêu có khớp với thực tế hay không, và một người chấm so sánh hai đoạn văn nghe hợp lý không có cách nào để thấy khác biệt giữa mức 0.6 được hiệu chỉnh tốt và mức 0.95 nghe đầy tự tin. Hai câu trả lời có thể được ưu tiên như nhau nhưng khác nhau rất nhiều về mức độ mà một phần mềm nên tin chúng.

Các dạng lỗi mà TypeSafe nêu tên trong tài liệu nhập môn đều bắt nguồn trực tiếp từ điều đó:

• Sự nịnh hót — mô hình học cách tạo ra những gì người đánh giá muốn nghe, một mục tiêu khác biệt so với sự thật.

• Ảo giác nghe có vẻ đầy tự tin — độ lưu loát và sự chắc chắn được ưu tiên tưởng thưởng ngay cả khi chúng không được hậu thuẫn bởi bất cứ điều gì.

• Mất mát mode — tối ưu hóa sở thích thu hẹp phân phối đầu ra, "ưu tiên một phong cách cụ thể, chẳng hạn như tuân theo chỉ dẫn, đồng thời giảm xác suất của các đầu ra khả thi khác." Mất mát mode là phiên bản nhẹ của lỗi sụp đổ mode kinh điển vốn thường gặp trong các mạng đối kháng tạo sinh, nơi bộ sinh hội tụ về một đầu ra liên tục đánh lừa bộ phân biệt.

Đoạn cảnh báo của chính tài liệu nhập môn là câu đáng giữ lại: “Một đầu ra có thể lôi cuốn một người mà vẫn không đủ đáng tin cậy để tự động hóa không cần giám sát. Sở thích của con người và độ đáng tin cậy của máy móc là những mục tiêu tối ưu hóa khác nhau.” Đó không phải là sự chỉ trích RLHF với tư cách một phương pháp. Đó là nhận định rằng một mô hình được huấn luyện theo sở thích chưa bao giờ được hỏi câu hỏi mà tự động hóa cần được trả lời — chính xác thì thứ này đúng được bao nhiêu lần khi nó nói rằng nó chắc chắn.

RLVR tối ưu hoá cho những đầu ra mà một chương trình có thể kiểm tra — và các quyết định hiếm khi có một đầu ra như vậy

Học tăng cường với phần thưởng có thể kiểm chứng là thích ứng thứ hai, và nó là thứ đằng sau các mô hình suy luận. Tài liệu nhập môn của TypeSafe mô tả những gì nó tạo ra: những mô hình "mạnh ở các tác vụ như toán học, nhưng chậm hơn và đắt hơn." Cơ chế là một trình kiểm tra. Nếu một tác vụ có đáp án mà một chương trình có thể kiểm tra — một unit test, một trình kiểm tra chứng minh, một đáp án số — thì có thể tính được phần thưởng mà không cần hỏi con người bất cứ điều gì, và mô hình có thể được huấn luyện dựa trên tín hiệu đó ở quy mô lớn. Nó hiệu quả, và đó là lý do các mô hình suy luận trở nên giỏi đúng ở những lĩnh vực nơi tồn tại việc kiểm chứng tự động rẻ.

Hạn chế nằm ở hình dạng của từ “verifiable”. Một phần thưởng có thể xác minh được đòi hỏi một trình xác minh, và một trình xác minh đòi hỏi rằng nhiệm vụ có một đáp án đúng mà ai đó có thể tính toán. Hãy xét những câu hỏi mà một hệ thống vận hành thực tế thật sự đặt ra. Phiếu hỗ trợ này nên được chuyển đến bộ phận thanh toán hay bộ phận kỹ thuật? Yêu cầu hoàn tiền này có nằm trong chính sách không? Giao dịch này trông có giống gian lận không? Mỗi câu đều có một đáp án có thể biện luận được trong hầu hết trường hợp, không câu nào có đáp án mà một chương trình có thể kiểm tra, và những trường hợp quan trọng nhất lại chính là những trường hợp mà những người có kinh nghiệm bất đồng với nhau. Không có hàm nào để chạy. RLVR không có gì để thưởng, nên nó chẳng đóng góp gì.

Cách lách đầy cám dỗ là tạo ra một trình xác minh bằng cách gán nhãn cho một tập dữ liệu rồi huấn luyện dựa trên các nhãn đó. Điều này cho phương pháp một thứ để nghiền ngẫm, nhưng nó thay đổi mục tiêu theo một cách quan trọng. Nhãn mã hóa một quyết định, chứ không phải sự bất định xung quanh quyết định đó. Một mô hình được huấn luyện để tái tạo phán đoán của một nhóm trên các ca khó sẽ học cách tự tin đúng như các nhãn đó — nghĩa là quá tự tin y hệt những con người đã viết chúng. Và ngay cả khi tồn tại một trình xác minh thực sự, vẫn có khoảng trống thứ hai. Một trình xác minh chấm điểm câu trả lời. Nó không chấm điểm độ tin cậy được nêu ra. Một mô hình đúng trong 95% trường hợp và báo rằng chắc chắn trong tất cả các trường hợp đó sẽ nhận được điểm thưởng hoàn hảo, và xét như một thành phần trong một pipeline tự động, nó vô dụng — bởi vì 5% đó là phần duy nhất mà pipeline cần được cho biết. Tài liệu ra mắt của TypeSafe đưa ra cùng luận điểm từ hướng ngược lại: "Nếu một mô hình có thể làm một tác vụ 95% thời gian nhưng không nói khi nào nó nằm trong 5%, nó không thể tự động hóa tác vụ đó."

RLCD làm gì, theo cách diễn đạt của chính TypeSafe

RLCD thay đổi hợp đồng đầu ra thay vì chất lượng câu trả lời. Thẻ của primer viết: "Học tăng cường cho các quyết định được hiệu chỉnh huấn luyện TypeSafe trả về các quyết định và xác suất được hiệu chỉnh thay vì văn bản được tạo sinh." Phiên bản ngắn gọn trong bài đăng ra mắt là "các quyết định được hiệu chỉnh: câu trả lời với xác suất trung thực về mặt nhận thức luận trên các tác vụ System One." Cả hai đều mô tả cùng một bước đi: huấn luyện mô hình dựa trên việc xác suất mà nó đưa ra có khớp với tần suất mà câu trả lời đó hóa ra là đúng hay không, thay vì dựa trên việc một người hay một trình kiểm tra có thích câu trả lời đó hay không.

Bài đăng ra mắt đặt ba phương pháp cạnh nhau, và sự tương phản là phát biểu rõ ràng nhất về ý tưởng hiện có. Hãy đọc như một tập hợp các tương phản thay vì một bảng:

• Nó tối ưu hóa cho điều gì — RLHF tối ưu hóa sở thích của con người, "các bài viết và phản hồi trò chuyện mà người đánh giá con người ưa thích"; RLVR tối ưu hóa "các đầu ra có thể được xác minh bằng chương trình"; RLCD tối ưu hóa hiệu chuẩn, "các câu trả lời với xác suất trung thực về mặt nhận thức luận trên các nhiệm vụ Hệ thống Một."

• Đầu vào gồm những gì — hai mô hình cũ hơn nhận dữ liệu phi cấu trúc "với trọng tâm là các thông điệp tuần tự"; một mô hình quyết định đã được hiệu chỉnh nhận dữ liệu phi cấu trúc "với trọng tâm là trạng thái chương trình có cấu trúc."

• Kết quả đầu ra — những chuỗi được tạo ra "cần phải được phân tích cú pháp + xác thực," với "luôn có một số rủi ro rằng AI đi chệch hướng," so với các giá trị có cấu trúc an toàn về kiểu, nơi "các đầu ra khả thi và cấu trúc được xác định trước," mô hình "không bao giờ mắc lỗi kiểu," và "mọi câu trả lời đều đi kèm với xác suất đã hiệu chỉnh và điểm tin cậy."

• Cách nó được lấy mẫu — từng token một, mỗi token được điều kiện hóa dựa trên token trước đó, so với toàn bộ đầu ra được sinh ra trong một truy vấn duy nhất. Đây là lý do cơ học khiến phương pháp thứ ba rẻ: không có vòng lặp giải mã nào phải trả chi phí.

• Chi phí ra sao — token đầu vào từ $0,20 đến $10 mỗi triệu đối với các mô hình so sánh, với đầu ra có giá khoảng gấp năm lần giá đầu vào, so với $0,042 mỗi triệu token đầu vào với đầu ra được tính phí bằng 0 đối với Jev.

• Tốc độ trả lời — từ 3 đến 329 giây từ đầu đến cuối đối với các mô hình tiên phong, so với 70 ms đến 500 ms, mà nhà cung cấp mô tả là nhanh hơn từ 40x đến 200x đối với các truy vấn có dạng System One.

• Điều nó nói về độ tin cậy của chính nó — hai mô hình cũ hơn "có xu hướng quá tự tin và thiếu nhất quán" ngay cả khi được nhắc ước lượng độ tin cậy; RLCD "luôn truyền đạt độ tin cậy và sự không chắc chắn trong mọi đầu ra," trong đó "độ tin cậy cao hơn đồng nghĩa với độ chính xác cao hơn."

Dòng cuối cùng là tuyên bố sản phẩm thực sự, và nó có thể bị phản bác theo cách mà những dòng khác không có. “Độ tin cậy cao hơn đồng nghĩa với độ chính xác cao hơn” là một phát biểu về một đường cong: hãy phân nhóm câu trả lời của một mô hình theo xác suất mà nó đã gán, và các nhóm đó phải đúng với tỷ lệ xấp xỉ mức mà các xác suất tuyên bố. Tài liệu về độ tin cậy của TypeSafe trình bày rõ cam kết này bằng những con số cụ thể một cách bất thường:

• Các kết quả được gán xác suất 0,2 sẽ xảy ra khoảng 20% số lần.

• Các kết quả được gán xác suất 0,8 sẽ xảy ra khoảng 80% số lần.

• Các kết quả được gán xác suất 1,0 nên xảy ra 100% số lần.

Và rồi, câu nói giữ cho lời khẳng định ấy được trung thực, bằng chính lời của nhà cung cấp: "Những tỷ lệ này mô tả các nhóm dự đoán, không phải sự bảo đảm cho bất kỳ câu trả lời đơn lẻ nào." Đó không phải là một lời rào đón gắn thêm vì lý do pháp lý. Đó là toàn bộ ý nghĩa của việc hiệu chuẩn. Một mô hình được hiệu chuẩn tốt đưa ra con số 0,8 không hứa rằng lần này nó sẽ đúng; nó hứa rằng trong mọi câu trả lời mà nó đã gán nhãn 0,8, khoảng bốn trong năm câu là đúng. Một câu trả lời chẳng nói lên điều gì. Một nghìn câu trả lời trong suốt một tuần sẽ cho bạn biết đường cong đó có thật hay không.

Sự tương phản ba thẻ tương tự nằm trên tài liệu riêng của TypeSafe, đây là nguồn cho phần so sánh ở trên và là nơi rõ ràng nhất để kiểm tra cách diễn đạt thay vì tin vào lời tóm tắt. Ảnh chụp bên dưới là trang đó ở trạng thái hiện tại: ba thẻ cho ba phương pháp sau huấn luyện, với thẻ thứ ba ghi tên đầy đủ của RLCD.

Hai chi tiết nữa trong tài liệu của nhà cung cấp cho thấy phương pháp này thâm nhập vào sản phẩm sâu đến mức nào. Thứ nhất là độ tin cậy được suy ra chứ không phải được tạo ra: mô hình trả về một phân phối xác suất đầy đủ trên các lựa chọn hoặc mức độ mà bạn cung cấp, và giá trị độ tin cậy là một thống kê được tính từ hình dạng của phân phối đó. Đó là lý do tài liệu có thể nói với bạn rằng định nghĩa đó không mang tính quyết định — dù thế nào bạn vẫn nhận được phân phối thô và có thể tự tính thống kê của riêng mình nếu thống kê của bạn phù hợp hơn. Thứ hai là RLCD là thứ duy nhất định hình các trọng số. Trang models của TypeSafe nêu rõ: "Jev không được tinh chỉnh hay điều chỉnh bằng LoRA với dữ liệu của khách hàng. Nó được huấn luyện bằng RLCD để đưa ra các quyết định đã hiệu chỉnh, và cùng một bộ trọng số phục vụ mọi tài khoản." Việc thích ứng miền diễn ra trong yêu cầu — trạng thái của bạn, tiêu chí của bạn — chứ không nằm trong một checkpoint riêng cho từng khách hàng. Bất kỳ hiệu chỉnh nào mà phương pháp tạo ra cũng chính là hiệu chỉnh mà mọi khách hàng đều nhận được.

Vì sao hiệu chuẩn là thứ khiến một mô hình ra quyết định rẻ trở nên dùng được

Một xác suất đã được hiệu chỉnh không tự thân mà thú vị. Nó trở thành kiến trúc vào đúng thời điểm mã của bạn rẽ nhánh dựa trên nó, và tài liệu về confidence của TypeSafe mô tả chính xác mẫu đó dưới dạng ba khoảng, mỗi khoảng tạo ra một hành vi hệ thống khác nhau.

• Độ tin cậy cao — hành động tự động. Mô hình đã nắm rõ tình hình và bạn có thể tiến hành mà không cần sự tham gia của con người.

• Độ tin cậy trung bình — hãy tiến hành thận trọng. Mô hình có câu trả lời hợp lý nhưng chưa chắc chắn, vì vậy bạn xác nhận với người dùng, gắn cờ để xem xét hoặc thu thập thêm thông tin trước khi hành động.

• Độ tin cậy thấp — đừng hành động. Hãy chuyển cho con người, yêu cầu làm rõ hoặc chuyển sang một hệ thống khác, vì mô hình đang cho bạn biết rằng nó không có đủ cơ sở để tiếp tục.

Tài liệu nói rõ rằng ranh giới là do bạn vạch ra và nên khác nhau tùy theo hậu quả: "Ngưỡng độ tin cậy không phải là một con số. Các hành động khác nhau trong cùng một hệ thống nên được kiểm soát ở các mức khác nhau tùy thuộc vào hậu quả của việc sai." Ví dụ thực tế của họ đặt mức sàn cứng ở 0,5 — bất cứ điều gì mô hình báo cáo dưới mức đó đều được chuyển cho con người mà không cần kiểm tra thêm — và sau đó áp dụng tiêu chuẩn cao hơn cho một hành động mang tính phá hủy so với một hành động chỉ đọc. Mã của bạn mã hóa mức chấp nhận rủi ro; mô hình cung cấp đầu vào trung thực cho nó.

Mô thức đó chính là toàn bộ lý lẽ cho một quy trình làm việc hai mô hình, và đáng được nêu ra như một lý lẽ thay vì một danh sách tính năng. Giả sử bạn muốn một pipeline tự động xử lý phần lớn các trường hợp mà nó tự tin, và chuyển phần còn lại lên một mô hình lớn hơn hoặc cho một con người. Quyết định chuyển lên cấp cao hơn phải xuất phát từ đâu đó. Nếu mô hình rẻ báo 0,98 cho mọi thứ, kể cả những trường hợp nó đang đoán mò, thì nhánh đó không có gì để kiểm tra, và bạn hoặc tự động hóa mọi thứ — kể cả những trường hợp lẽ ra nó phải chuyển lên cấp cao hơn — hoặc bạn không tự động hóa gì cả. Một mô hình có độ tự tin mang tính thông tin là loại duy nhất cho phép bạn tự động hóa một tập hợp con một cách an toàn, bởi vì chỉ có loại đó mới có thể cho bạn biết tập hợp con nào mà nó không an toàn. Tài liệu diễn đạt cùng ý đó bằng một câu đáng trích dẫn vì sự thẳng thừng của nó: "Nếu một hệ thống thông minh, dù là con người hay máy móc, không thể diễn đạt sự không chắc chắn một cách trung thực, thì hệ thống đó không thể được tin cậy."

Có một lý do thứ hai khiến điều này quan trọng hơn đối với một mô hình rẻ so với một mô hình đắt tiền, và đó chính là lý do câu chuyện định tuyến và câu chuyện RLCD là cùng một câu chuyện. Một mô hình có giá $0.042 cho mỗi triệu token đầu vào và không tính phí đầu ra thì đủ rẻ để được tham vấn liên tục — ở mọi lượt của vòng lặp tác tử, trên mọi bản ghi trong một lô, trên mọi ticket ngay khi nó đến. Được tham vấn liên tục chính xác là tình huống mà trong đó sai sót của một mô hình sẽ chồng chất, bởi vì không ai đọc kết quả của nó trước khi nó được đem ra hành động. Sự tự tin chính là thứ khiến điều đó trở nên an toàn. Cái rẻ chính là thứ khiến nhánh leo thang trở nên khả thi về chi phí, vì con đường đắt đỏ chỉ chạy trên phần nhỏ các trường hợp mà mô hình rẻ đã từ chối. Không nửa nào hoạt động được nếu thiếu nửa kia, và quyết định định tuyến nối hai nửa đó lại chính là một ngưỡng trên một con số mà RLCD là lý do để tin vào.

Giới hạn trung thực: được hiệu chuẩn không có nghĩa là đúng.

Điều quan trọng nhất cần nắm đúng về RLCD là những gì nó không tuyên bố. Hiệu chỉnh là một thuộc tính của các độ tin cậy, không phải một bảo đảm về các câu trả lời, và chính nhà cung cấp nói như vậy trong tài liệu của mình thay vì để mặc cho các nhà phê bình. Trang System One viết: "Các mô hình System One được huấn luyện để đưa ra quyết định đã hiệu chỉnh: xác suất của chúng được tối ưu hóa dựa trên các kết quả để phản ánh mức độ bất định. Hiệu chỉnh được đo lường trên các nhóm dự đoán; nó không bảo đảm rằng một câu trả lời riêng lẻ là đúng." Một mô hình có thể được hiệu chỉnh hoàn hảo mà vẫn đưa ra phán đoán sai về ticket của bạn, bởi vì 0,9 nghĩa là chín trên mười, và đây có thể chính là trường hợp thứ mười.

Các số liệu phục vụ của chính chúng tôi là đối trọng hữu ích ở đây, chính xác vì chúng là các phép đo mô hình trong môi trường sản xuất chứ không phải những tuyên bố về điều mà phương pháp đạt được. Trong bảy ngày kết thúc vào 2026-09-30, trên lưu lượng truy cập qua playground của OrcaRouter kể từ khi mô hình được thêm vào danh mục, thẻ Jev 1.13 báo cáo tỷ lệ lỗi 0,49% trên 76,2 triệu token, cùng với thời gian đến token đầu tiên p50 là 151 ms, p95 là 247 ms, và khoảng 349 token đầu ra mỗi giây. Hai điều về con số đó đáng được nói thẳng. Nó là của chúng tôi, không phải của nhà cung cấp, và nó là một cửa sổ trượt chứ không phải một tập kiểm thử cố định — cùng trường đó đọc là 0,57% sớm hơn trong cửa sổ, vì nó được tính toán lại trên bảy ngày gần nhất của lưu lượng trực tiếp và các cuộc gọi của ngày hôm qua sẽ rơi ra ngoài. Nó cũng không phải là một phép đo hiệu chuẩn. Tỷ lệ lỗi cho bạn biết tần suất có điều gì đó sai trên lưu lượng của chúng tôi; nó không cho bạn biết liệu các giá trị độ tin cậy có trung thực hay không, đó là một câu hỏi khác và là câu hỏi cần dữ liệu được gán nhãn để trả lời.

Đó cũng là hướng dẫn thực tế mà nhà cung cấp đưa ra, trong một ghi chú đính kèm với hướng dẫn ngưỡng của nó: "Các giá trị ngưỡng chính xác phụ thuộc vào lĩnh vực của bạn và hiệu suất của mô hình cho trường hợp sử dụng của bạn. Hãy bắt đầu với các ngưỡng thận trọng, kiểm tra với dữ liệu của riêng bạn và điều chỉnh khi bạn quan sát kết quả." RLCD là một tuyên bố về cách mô hình được huấn luyện. Liệu tuyên bố đó có đúng trên đầu vào của bạn hay không là một câu hỏi thực nghiệm, và đó là một trong số ít các thuộc tính mô hình mà bạn có thể kiểm tra mà không cần bất kỳ cơ sở hạ tầng học máy nào — hãy lấy vài trăm trường hợp bạn đã có nhãn, phân nhóm các câu trả lời theo độ tin cậy mà mô hình báo cáo, và kiểm tra xem các nhóm có đúng với tỷ lệ mà chúng tuyên bố hay không. Nếu nhóm 0.9 đúng khoảng 90% thời gian trên lưu lượng truy cập của bạn, thì ngưỡng là thực và bạn có thể tự động hóa ở trên nó. Nếu mọi thứ đều tập trung trên 0.9 và độ chính xác không theo sau, bạn đã học được điều gì đó hữu ích hơn bất kỳ con số tiêu đề nào.

Hai giới hạn bổ sung cần được nhắc đến cùng lúc. Thứ nhất là không có thẻ benchmark công khai nào cho mô hình này để đối chiếu bất kỳ điều gì trong đó — nhà cung cấp chưa công bố một thẻ như vậy, và không có bảng xếp hạng bên thứ ba nào có mô hình này; trang mô hình Artificial Analysis dành cho nó trả về 404 tính đến ngày 2026-09-30. Vì vậy, lập luận hiệu chuẩn dựa vào mô tả huấn luyện, hợp đồng đã được tài liệu hóa, và bất cứ điều gì bạn tự đo lường, chứ không dựa vào một đường cong đã công bố. Thứ hai là những tuyên bố về hiệu năng của chính nhà cung cấp là do chính họ đưa ra: bài đăng ra mắt nói rõ rằng các đánh giá quy trình làm việc đằng sau tiêu đề về tốc độ và chi phí được xây dựng bởi đội ngũ năng lực mô hình của họ, rằng các câu trả lời tham chiếu mà chúng được đo lường dựa trên là mức trung bình của hai mô hình bên ngoài, và rằng các con số nằm “ở mức cao hơn trong các cải thiện thực tế”. Bài đăng cũng nói rằng không thể chứng minh rằng mức giá này không được trợ cấp. Không điều nào trong số đó làm suy yếu phương pháp huấn luyện, vốn là một tuyên bố tách biệt với tuyên bố về tốc độ, nhưng điều đó có nghĩa là luận cứ ủng hộ RLCD là một lập luận về thiết kế mục tiêu chứ không phải một kết quả thực nghiệm đã ngã ngũ. Hãy coi đó là một giả thuyết mà bạn có thể kiểm nghiệm với chi phí thấp, một vị thế tốt hơn so với vị thế mà hầu hết các tuyên bố về phương pháp huấn luyện để lại cho bạn.

Bạn có thể làm gì với điều này ngay hôm nay

Hai vế của lập luận gặp nhau tại một chỗ. RLCD là lý do khiến độ tin cậy của một mô hình ra quyết định đáng để phân nhánh; một ngưỡng trong mã của bạn chính là nơi nhánh đó nằm; và việc leo thang chỉ có thể chi trả nổi nếu đường đi thông thường đủ rẻ để chạy ở mọi nơi. Jev 1.13 có thể được gọi dưới dạng typesafe/jev-1.13 trên OrcaRouter — một API cho hơn 200 mô hình, 0% phụ phí, giá niêm yết của nhà cung cấp được chuyển nguyên, nên việc nhà cung cấp cắt giảm giá có hiệu lực ở đây ngay trong cùng ngày — nghĩa là đường đi của đa số tự tin và đường leo thang sinh tạo cùng tính phí trên một khóa duy nhất thay vì hai hợp đồng nhà cung cấp. Bạn vẫn gọi nó theo hình dạng riêng của nó, POST /v1/systemone, không streaming, với ngữ cảnh 65.536 token, bởi vì đó không phải là tuyến chat-completions của OpenAI và nó không được gộp vào endpoint chat. Hai ghi chú có ghi ngày từ các bản phát hành SDK của nhà cung cấp đáng để biết nếu bạn đang kết nối nó: phiên bản 0.7.1, phát hành ngày 2026-09-21, đã bổ sung các ví dụ sử dụng với các cổng AI, và phiên bản 0.7.2, phát hành ngày 2026-09-26, đã bổ sung một extra http2 vào gói Python. Điều thứ hai là kiểu chi tiết chỉ xuất hiện trong ghi chú phát hành — một client HTTP/2 là thứ đáng có đối với một mô hình mà toàn bộ giá trị đề xuất của nó nằm ở các vòng khứ hồi dưới 200 mili giây.

Nếu bạn chỉ lấy một điều từ trang này, hãy lấy hình dạng của câu hỏi mà RLCD trả lời. Đó không phải là “liệu một mô hình có thể thông minh hơn không”. Đó là “liệu một mô hình có thể cho tôi biết khi nào nó chưa đủ thông minh, đủ thường xuyên và đủ chính xác để tôi có thể tự động hóa phần còn lại hay không”. Đó là một mục tiêu nghiên cứu khác với hai mục tiêu mà lĩnh vực này đã dành vài năm qua để theo đuổi, và nó là mục tiêu duy nhất tạo ra một con số mà mã của bạn có thể hành động dựa trên đó. Giá trị độ tin cậy chính là con số đó. Hãy kiểm thử nó trên nhãn của chính bạn trước khi tin nó, và hãy bắt đầu với một ngưỡng mà bạn sẽ thấy xấu hổ nếu sai về nó, thay vì một ngưỡng mà bạn muốn mình đúng về nó.

Một mảnh ghép cuối cùng của bức tranh vẫn đáng được mang theo bên cạnh tất cả những thứ trên, bởi vì đó là con số mà toàn bộ lập luận đang nhắm tới, và nó được đo lường chứ không phải chỉ được khẳng định. Thẻ bên dưới là bản ghi phục vụ bảy ngày của chúng tôi cho typesafe/jev-1.13 — mô hình đang chạy thực tế, không phải phương pháp huấn luyện, và cũng không phải một benchmark. Hãy đọc nó như nửa còn lại của câu hỏi hiệu chỉnh: các độ tin cậy cho bạn biết những lời gọi nào cần hành động, còn thông tin này cho bạn biết phần còn lại của quyết định định tuyến đang gần với một hệ thống mà bạn sẵn sàng để chạy không giám sát đến mức nào.