Những điểm Jev 1.13 hỏng: Danh sách giới hạn của chính TypeSafe

Jev 1.13 (typesafe/jev-1.13) được phát hành vào ngày 2026-09-15, tức là cách mốc bảy ngày gần nhất hai tuần, nên việc ra mắt của nó không phải là câu chuyện chính. Sự kiện được ghi ngày là 2026-09-24: đó là ngày OrcaRouter thêm typesafe/jev-1.13 vào danh mục của mình và mở model card cho nó — hỗ trợ phục vụ đầu tiên cho Jev tại một cổng gateway của bên thứ ba, sau hai tuần mà cách duy nhất để gọi nó là endpoint riêng của TypeSafe. Điều đó quan trọng ở đây vì một lý do cụ thể. Jev khác thường ở chỗ nhà cung cấp của nó công bố danh sách những cách nó thất bại, và một danh sách bạn chỉ có thể đọc thì dễ bị bỏ qua hơn nhiều so với một mô hình bạn thực sự có thể gọi.

Trang này chính là danh sách đó, chỉ giới hạn ở những gì TypeSafe tự nói, cộng với các giới hạn vận hành và hoá đơn.

TypeSafe công bố danh sách jaggedness của riêng mình

docs.typesafe.ai có một trang mang tiêu đề Độ lởm chởm của Jev 1.13. Trang này áp dụng rõ ràng cho jev-1.13, có ngày đánh giá là 2026-09-17, và mở đầu bằng cách đặt vấn đề của chính nhà cung cấp: "Jev không hoàn hảo. Dưới đây là một số cạnh lởm chởm mà chúng tôi biết ở jev-1.13. Nhiều điểm trong số này sẽ được sửa trong các phiên bản sau." Tiếp theo là chín chế độ được đặt tên, mỗi chế độ có một trường hợp cụ thể và một biện pháp khắc phục "Thay vào đó:". Không có nội dung nào dưới đây là suy diễn, và không có gì bị làm nhẹ đi — cách diễn đạt là của TypeSafe, và ở những chỗ công ty đưa ra ví dụ của chính mình, các con số trong đó là của họ.

Cách đọc theo nghĩa đen: nó trả lời câu hỏi mà bạn đã viết

Các từ giới hạn phạm vi, phủ định và điều kiện ngụ ý được hiểu theo nghĩa bề mặt. Một câu hỏi được trả lời dựa trên các từ trong chỉ dẫn, "trong khi một người có thể đã đọc ý định đằng sau các chỉ dẫn."

Phần hữu ích nằm ở chẩn đoán của nhà cung cấp: khi bạn nhìn vào một câu trả lời sai và thấy mình đang giải thích điều mình thực sự muốn nói, thì lời giải thích đó chính là nửa còn thiếu của chỉ dẫn. Cách khắc phục là nêu điều kiện chính xác trong chỉ dẫn, đưa các trường hợp biên vào tiêu chí, và ở những chỗ việc diễn giải thực sự không thể tránh khỏi, hãy tách câu hỏi thành hai câu theo nghĩa đen rồi kết hợp chúng trong mã.

Toán học và các con số: nó không phải là một chiếc máy tính.

TypeSafe nói thẳng rằng hãy triển khai logic toán học trong mã. Ba lỗi cụ thể nằm bên dưới điều đó:

• Việc đếm không đáng tin cậy. Điều này bao gồm các ký tự trong một từ, số lần xuất hiện của một thuật ngữ trong một đoạn văn, và các mục trong một danh sách dài. "Mô hình nhận diện hình dạng của câu trả lời thay vì kiểm đếm, và sai số tăng theo kích thước của thứ đang được đếm." Phép thử của chính nhà cung cấp để quyết định có nên hỏi hay không: nếu một biểu thức chính quy hoặc một trình phân tích cú pháp có thể tìm thấy đơn vị, thì việc đếm thuộc về mã và mô hình không bổ sung gì.

• Biểu diễn dạng số cho kết quả kém hơn biểu diễn ngữ nghĩa. Các câu hỏi về màu sắc dùng giá trị hex sẽ tệ hơn so với chính những câu hỏi đó dùng tên màu tiếng Anh; khi đưa bộ ba RGB hoặc hex, Jev không thể đánh giá một cách đáng tin cậy liệu hai giá trị có gần nhau hay không. Khoảng cách tương tự cũng xuất hiện ở mã cấp thấp — hợp ngữ, hoặc các lệnh mã hóa nhị phân — so với các ngôn ngữ cấp cao. Hãy chuyển đổi hoặc gom nhóm bằng mã, và giữ mô hình cho phần thực sự là phán đoán.

• Đầu ra điểm số không mang độ lớn chính xác. Nhà cung cấp nói rằng các mức điểm của Jev yếu về hiệu chuẩn số. Một kỳ vọng có thể được dùng để kiểm tra liệu một thứ gì đó có vượt qua ngưỡng hay không; nó không thể được dùng để tái dựng con số bằng cách nội suy giữa hai mức gần nhất. Đó là một lời từ chối dứt khoát đối với cả một loại lạm dụng — coi điểm số như một phép đo.

Ngày và giờ: ngày tháng được đọc dưới dạng văn bản, không phải dưới dạng số lượng

Việc sắp thứ tự hai ngày, đo khoảng cách giữa chúng, hoặc quyết định xem một ngày có nằm trong một cửa sổ hay không là không đáng tin cậy, và còn suy giảm hơn nữa với các định dạng hỗn hợp, tham chiếu tương đối, và ranh giới miền như quý, cửa sổ tất toán, và kỳ tích lũy.

Cách phân chia được đề xuất là gọn gàng. Việc trích xuất là một phán đoán, vì vậy hãy giao nó cho mô hình. Mỗi thành phần của một ngày là một tập hợp đóng nhỏ — mười hai tháng, ba mươi mốt ngày có thể, một khoảng năm có giới hạn — điều này biến việc trích xuất thành một lựa chọn giữa các tùy chọn được liệt kê thay vì phân tích cú pháp tự do, và cho bạn một chỗ để đặt một "không được nêu rõ" tường minh để một phần bị thiếu được báo cáo thay vì bị đoán. Mã nguồn lắp ráp các phần và sở hữu mọi thứ sau đó, bao gồm thứ tự, thời lượng, độ lệch và thứ trong tuần.

Gián tiếp: phủ định kép và các bước trung gian làm giảm độ chính xác

Các chỉ dẫn chứa phủ định kép hoặc sự gián tiếp nhiều lớp sẽ được trả lời kém tin cậy hơn. Một câu hỏi về thuộc tính của một thuộc tính, hoặc một câu hỏi đòi hỏi nhiều bước suy luận, sẽ làm giảm độ chính xác. Cách khắc phục là viết chỉ dẫn càng trực tiếp càng tốt và gọi tên các phần liên quan của trạng thái thay vì mô tả chúng.

Một trạng thái lớn chứa đầy chi tiết không liên quan sẽ làm giảm độ chính xác.

Độ chính xác giảm khi trạng thái phình to với nội dung không liên quan đến quyết định. Chi tiết không liên quan đóng vai trò gây nhiễu, và một trạng thái lớn khiến khó nhận ra phần nào của đầu vào đã tạo ra câu trả lời sai. Lời nhắc của chính TypeSafe trong ghi chú kết thúc thẳng thắn: "Jev mắc chứng mục nát ngữ cảnh, nên tài liệu không liên quan trong trạng thái khiến bạn mất độ chính xác."

Trước tiên, hãy truy xuất và lọc trong mã, rồi chỉ gửi những trường mà câu hỏi cần. Ở những trường hợp không thể lọc trước khi gửi yêu cầu, nhà cung cấp đề xuất dùng một noul để lọc theo mức độ liên quan, sau đó đánh giá những kết quả còn lại.

Nội dung đối kháng trong trạng thái làm thay đổi câu trả lời

State là dữ liệu, và jev-1.13 không coi nó là thù địch theo mặc định. Một chỉ thị được chèn vào, một cách định khung cố ý gây hiểu lầm, hoặc văn bản lập luận cho việc phân loại của chính nó đều có thể làm thay đổi kết quả. Đây là chế độ duy nhất mà nhà cung cấp định khung rõ ràng việc sửa lỗi như công việc trong tương lai — “Chúng tôi kỳ vọng sẽ cải thiện điều này trong tương lai” — và lời khuyên tạm thời là hãy nêu rõ các tiêu chí và kiểm thử tích hợp một cách kỹ lưỡng trước khi đưa nó ra trước nhiều người dùng.

Những chỉ dẫn và tiêu chí mâu thuẫn khiến nó bối rối.

Khi các chỉ dẫn và các tiêu chí yêu cầu những điều khác nhau, mô hình có thể bị nhầm lẫn. Ví dụ của TypeSafe là một quy tắc trong đó true ánh xạ thành no và false ánh xạ thành yes, cách này hoạt động kém hơn so với cùng câu hỏi được diễn đạt một cách nhất quán. Chỉ dẫn là hãy coi các tiêu chí như một phần mở rộng của chỉ dẫn và căn chỉnh cả hai bằng ngôn ngữ mà một người bình thường có thể đọc và hiểu.

Các bất biến cấu trúc mà nó không đảm bảo

Đây là chế độ có nhiều khả năng phá vỡ một hệ thống được xây dựng trên một giả định mà không ai ghi lại nhất. Jev cực kỳ nhất quán theo nghĩa thông thường — các đầu vào tương tự về ngữ nghĩa tạo ra các đầu ra tương tự về mặt định lượng — nhưng những đồng nhất thức cấu trúc mà bạn có thể kỳ vọng sẽ đúng lại không được bảo đảm. Nhà cung cấp công bố hai trường hợp đã được xử lý.

• Một câu hỏi, hai kiểu câu hỏi. "Khách hàng có đang yêu cầu hoàn tiền không?" được hỏi dưới dạng noul và được hỏi dưới dạng lựa chọn yes/no, trên ticket "Tôi không hài lòng với độ vừa vặn. Tôi có những lựa chọn nào ở đây?" trả về một noul là 0.22, và một lựa chọn yes 0.01, no 0.99, độ tin cậy 0.97. Đó là những câu trả lời cho cùng một câu hỏi.

• Một câu hỏi và phủ định của nó. "Khách hàng có đang yêu cầu hoàn tiền không?" và "Khách hàng có đang yêu cầu thứ gì đó khác ngoài việc hoàn tiền không?", được hỏi dưới dạng hai nouls trên ticket "Tôi bị tính phí hai lần cho cùng một đơn hàng. Có ai đó xem xét việc này không?", trả về 0,72 và 0,47. Chúng cộng lại thành 1,19.

Các biện pháp khắc phục mang tính vận hành, không phải tu từ: đừng dựa vào tính bất biến cấu trúc được kỳ vọng, đừng mang một ngưỡng được tinh chỉnh trên một noul áp sang một lựa chọn, và đừng bắt mô hình phải tuân theo các đồng nhất thức số học giữa các câu hỏi riêng biệt. Lý do là một lựa chọn có tính tương đối — nó xác định phương án nào — trong khi mỗi noul là tuyệt đối và có thể trả về thấp đối với tất cả các phương án đó.

Tạo sinh: nó không được huấn luyện để viết

jev-1.13 không được huấn luyện để sinh văn bản. Bạn có thể ép tạo đầu ra bằng cách xâu chuỗi các lựa chọn, và TypeSafe nói thẳng rằng điều này "sẽ không hoạt động tốt và sẽ rất chậm." Đối với việc trích xuất, hướng dẫn là trích các giá trị ứng viên ra bằng biểu thức chính quy hoặc một mô hình sinh rồi để Jev chọn giá trị đúng, hoặc — khi không gian đáp án bị giới hạn — biến việc trích xuất thành một lựa chọn trên các tùy chọn thay vì hỏi chính giá trị đó.

Giới hạn trần 255 lựa chọn đối với câu hỏi lựa chọn

Một câu hỏi lựa chọn: tích hợp Jev không phải là một cạnh lởm chởm, mà là hình dạng của sản phẩm. Những điểm này đáng được tách riêng ra vì dù có làm prompt đến đâu cũng không thể thay đổi chúng:

• Không tạo văn bản. Nó trả về một quyết định, không phải văn xuôi. Đó là thiết kế, không phải lỗi.

• Không có hội thoại. Jev là một mô hình quyết định có cấu trúc chứ không phải mô hình trò chuyện. Bạn gửi một trạng thái và một tập hợp các câu hỏi được đặt tên; nó trả về một câu trả lời có cấu trúc cho mỗi câu hỏi. Không có việc luân phiên lượt để thiết kế xung quanh.

• Không có đầu vào đa phương thức. Đầu vào chỉ là văn bản — chuỗi, đối tượng JSON hoặc mảng các giá trị văn bản, không có hình ảnh, âm thanh hay video. Tài liệu phi văn bản phải được tiền xử lý thành văn bản hoặc các trường có cấu trúc trước khi nó trở thành một phần của trạng thái.

• Phản hồi không streaming. Chỉ có một phản hồi có cấu trúc duy nhất và không có chế độ streaming. Lý do điều này không quan trọng cũng chính là lý do đáng để nói rõ: không có gì để truyền phát. Một quyết định có kiểu — một boolean kèm xác suất, một nhãn trong một tập hợp, hoặc một mức trên một thang đo — không có dạng từng phần nào đáng để tiết lộ từng token một.

• Tiếng Anh là ngôn ngữ chính. Các ngôn ngữ khác, bao gồm cả chữ CJK, vẫn được xử lý nhưng không tốt như nhau. Lời khuyên của TypeSafe là hãy kiểm thử trên nội dung của chính bạn trước khi dựa vào Jev cho một khối lượng công việc không phải tiếng Anh, và hãy dựa vào độ tin cậy khi định tuyến.

Giới hạn trần 255 lựa chọn đối với câu hỏi lựa chọn

Một câu hỏi lựa chọn chọn một trong tối đa 255 tùy chọn có nhãn, và giới hạn trần đó là một giới hạn cứng. TypeSafe cũng giải thích lý do vì sao các tập lựa chọn lớn chạy chậm hơn, bằng chính lời của nhà cung cấp: "Đối với các lựa chọn có số lượng lớn hơn, chúng tôi dùng hệ thống 2 giai đoạn là chấm điểm độc lập rồi đưa ra lựa chọn rõ ràng, do đó đôi khi bị chậm lại." Vì vậy, chi phí độ trễ của một tập tùy chọn lớn là mang tính cấu trúc chứ không phải ngẫu nhiên, và chính nhà cung cấp đang nói cho bạn biết nó đến từ đâu.

Cửa sổ phục vụ của riêng chúng tôi cho typesafe/jev-1.13, đọc từ thẻ mô hình vào ngày 2026-09-30, cho thấy điều đó trông như thế nào trong thực tế qua bảy ngày lưu lượng của chính chúng tôi: trung vị là 151 ms và p95 là 247 ms, 348 token đầu ra mỗi giây, và tỷ lệ lỗi 0,49% trên 76,2 triệu token được phục vụ. Các trung vị hằng ngày dao động trong một dải hẹp — 175, 170, 163, 161, 170, 147 và 143 ms từ 2026-09-24 đến 2026-09-30 — nhưng p95 hằng ngày cho 2026-09-28 là 2.448 ms, gần gấp mười lần các ngày ở hai bên ngày đó. Chúng tôi không thể quy ngoại lệ của một ngày đó cho bản số lựa chọn và sẽ không làm vậy; cách hiểu trung thực là đuôi tồn tại, và một quy trình nhạy cảm với độ trễ nên được thiết kế dựa trên đuôi thay vì trung vị.

Hóa đơn đầu vào là toàn bộ hóa đơn.

Đầu ra được tính phí ở mức không trên Jev, điều đôi khi bị hiểu thành "Jev miễn phí". Không phải vậy, bởi đầu vào được đo đếm và một trạng thái lớn không tự nhiên miễn phí chỉ vì không có gì ở phía đầu ra. Giá của nhà cung cấp là 0,042 đô-la cho mỗi triệu token đầu vào — cùng con số mà TypeSafe nêu là 42 đô-la cho mỗi tỷ — và OrcaRouter chuyển tiếp nguyên giá niêm yết của nhà cung cấp với mức chênh lệch 0%, nên khi nhà cung cấp giảm giá thì ở đây cũng cập nhật ngay trong cùng ngày.

Đây là tác động của điều đó đối với một hình dạng thực tế, khi dùng chính tỷ lệ của nhà cung cấp:

• Một yêu cầu nhỏ. Một phiếu hỗ trợ 1.200 token cộng với khoảng 300 token cho bảng tiêu chí và câu hỏi là 1.500 token đầu vào, tức là $0,000063 mỗi lần gọi.

• Một yêu cầu lớn. Một hợp đồng 55.000 token cộng với các câu hỏi đưa yêu cầu lên 60.000 token là gấp 40 lần số token, vậy $0.0025 mỗi lần gọi — vẫn nhỏ mỗi lần gọi, và lớn hơn 40 lần so với trường hợp đầu tiên cho cùng một câu trả lời.

• Ở khối lượng lớn. 60.000 token một lần gọi và 10.000 lần gọi một ngày là 600 triệu token đầu vào một ngày, tức 0,6 tỷ, do đó $25,20 một ngày và khoảng $756 trong một tháng 30 ngày. Cùng số lần gọi đó với yêu cầu 1.500 token là 15 triệu token một ngày: $0,63 một ngày, khoảng $18,90 một tháng.

Khoảng cách giữa hai dòng cuối đó không phải là một mẹo định giá, mà là trạng thái được đo đếm. Đó là lý do vì sao lời khuyên về lọc trong phần context-rot không chỉ là một biện pháp đảm bảo độ chính xác — cắt gọt trạng thái cũng là đòn bẩy duy nhất làm thay đổi hóa đơn.

Các giới hạn vận hành đã được công bố, để không ai phải đoán.

Các mô hình của TypeSafe công bố những con số cụ thể, vì vậy người lập kế hoạch không cần phải đoán:

• Thông lượng và tốc độ. 100K token mỗi giây và 40 yêu cầu mỗi giây, theo docs.typesafe.ai/models.md. Một yêu cầu vượt quá một trong hai giới hạn sẽ trả về 429 Too Many Requests; các SDK máy khách của nhà cung cấp mặc định thử lại với backoff và tuân theo tiêu đề retry-after khi phản hồi có tiêu đề này.

• Các giới hạn luôn thay đổi. Nhà cung cấp cho biết các giới hạn tốc độ đang được điều chỉnh linh hoạt và "có thể thay đổi mà không cần thông báo" khi năng lực được đưa vào vận hành, với các giới hạn cao hơn có sẵn trong gói tùy chỉnh và gói doanh nghiệp. Hãy coi 100K/40 là con số của hiện tại chứ không phải một hợp đồng.

• Ngân sách ngữ cảnh. Ngân sách yêu cầu vào khoảng 64.000 token tính trên trạng thái kết hợp cùng toàn bộ câu hỏi — thẻ mô hình công bố 65.536 — và trang mô hình của nhà cung cấp lại giới hạn riêng trạng thái cộng với một câu hỏi dài nhất ở mức 32.000 token. Con số thứ hai đó là ngân sách trạng thái, chứ không phải một phiên bản nhỏ hơn của con số thứ nhất; cả hai đều có thật và không con số nào mâu thuẫn với con số kia.

• Các alias có thể thay đổi ngay dưới chân bạn. Hiện tại, cả jev-latest và jev-preview đều trỏ đến jev-1.13.0, và nhà cung cấp lưu ý rằng hiện không có bản dựng preview nào khả dụng. Một alias sẽ thay đổi khi có bản phát hành mới ra mắt, vì vậy nếu bạn đã tinh chỉnh ngưỡng độ tin cậy dựa trên một phiên bản cụ thể, hãy ghim ID có gắn phiên bản và chuyển theo lịch trình của riêng bạn.

Use case của bạn cần trông như thế nào

Đọc từ đầu đến cuối, danh sách của chính nhà cung cấp mô tả một công cụ hẹp nhưng hữu ích. Jev phù hợp khi phán đoán có giới hạn và phần tính toán không phải là việc của mô hình: bản ghi này có nằm trong chính sách không, nhãn nào trong số bốn mươi nhãn này được áp dụng, điều này đọc ra sao trên thang năm mức — được hỏi dựa trên trạng thái do chính bạn lọc, với một chỉ dẫn nguyên văn và các tiêu chí khớp với nó, và với mọi phép đếm, so sánh và đo ngày tháng đều được thực hiện bằng mã xung quanh nó.

Đó không phải là sự phù hợp khi tác vụ cần đếm, sắp xếp thứ tự hoặc tính toán ngày tháng, khi nó cần nhiều bước suy luận, khi tài liệu đầu vào không phải là văn bản, khi trạng thái là một đống cỏ khô và câu hỏi là cây kim, hoặc khi bất cứ điều gì về nguồn đều mang tính thù địch. Đó không phải là những lỗ hổng trong một prompt; chúng là những chỗ mô hình không hoạt động, và TypeSafe là bên nói như vậy.

Một điều nữa đáng biết trước khi bạn kết nối nó: sự khác biệt thực chất trong cách Jev được gọi. Trên OrcaRouter, danh mục truy cập Jev thông qua endpoint systemone chuyên dụng, POST /v1/systemone, thay vì thông qua dạng chat-completions của OpenAI. Đó là một khác biệt thực sự trong yêu cầu bạn viết, và đó là phiên bản đúng của tuyên bố cũ rằng Jev "nói theo dạng yêu cầu riêng của nó". Mọi thứ khác đều giống như bất kỳ mô hình nào khác trên tài khoản — một khóa cho 200+ mô hình, không có phí theo token từ phía chúng tôi, và tự động chuyển đổi dự phòng nếu một tuyến gặp sự cố. TypeSafe đã gỡ bỏ danh sách chờ vào 2026-09-21; trang chủ của chính nhà cung cấp vẫn mô tả Jev là quyền truy cập sớm, và trang benchmark của chính họ vẫn được đánh dấu là đang chờ, nên những số liệu hiệu năng duy nhất trên trang này là các con số phục vụ do chính chúng tôi đo được và các tuyên bố của chính nhà cung cấp, được ghi nhãn là của họ.