Thẻ tiêu đề ghi 'Jev: Một mô hình từ chối viết' với phụ đề 'Mô hình quyết định của TypeSafe AI trả về câu trả lời có kiểu thay vì văn bản', ba thẻ có nhãn cho các primitive Choice, Score và Noul, và một khối số liệu hiển thị 777 phán đoán trong chưa đầy 0,7 giây với chi phí $0,042 cho mỗi triệu token đầu vào.
Guides & Insights

Jev từ chối viết một chữ nào: Mô hình ra quyết định của TypeSafe AI làm gì, và điều mà chưa ai xác minh cho đến nay

Tác giả

Magnus Corvin

Ngày đăng

Mô hình mới nhất · 20Xem tất cả mô hình
Benchmark: Artificial Analysis · cập nhật hằng ngày
Quay lại tất cả bài viết

Jev là mô hình đầu tiên của TypeSafe AI mà người đọc có khả năng gặp qua một bảng chi phí hơn là qua một hộp trò chuyện, bởi vì không có hộp trò chuyện nào cả. Được ra mắt vào ngày 15 tháng 9 năm 2026 bởi Diogo Almeida — một đồng tác giả của bài báo InstructGPT, công trình đã khiến ChatGPT hành xử như một trợ lý — Jev hoàn toàn không tạo sinh văn bản. Nó nhận một mẩu trạng thái (một email, một dòng log, một phiếu hỗ trợ, một khối JSON tọa độ trò chơi) cùng một danh sách các câu hỏi có kiểu, và trả về các câu trả lời có kiểu: một lựa chọn từ tập hợp bạn cung cấp, một điểm số theo một thang đánh giá, hoặc một xác suất có/không, mỗi câu trả lời đều mang giá trị độ tin cậy riêng. Không có văn xuôi, không có mã, không có giải thích. Điểm nhấn của TypeSafe là chính sự hẹp này lại là sản phẩm, bởi vì nó đổi lấy tốc độ và mức giá mà một mô hình tạo sinh không thể sánh bằng — nhanh hơn 20 đến 200 lần và rẻ hơn 40 đến 400 lần so với "các LLM tương đương" trên chính tài liệu ra mắt của công ty, với mức $0.042 cho mỗi triệu token đầu vào và đầu ra được tính phí bằng không.

Con số hữu ích nhất được công bố trong 48 giờ đầu tiên không nằm trong số đó. Nó đến từ Every, nơi trưởng bộ phận đánh giá đã chạy Jev trên 27 bài viết đã xuất bản của Every cùng 10 bài đối chiếu mang phong cách AI, đặt 21 câu hỏi cho cả 37 tài liệu cùng một lúc: 777 phán đoán trong chưa đầy 0,7 giây, với chi phí khoảng một phần tư xu. Một thử nghiệm thứ hai, do CEO của Every thực hiện, đưa 12 đoạn văn tổng hợp — sáu đoạn sạch, sáu đoạn có lỗi được cố tình cài vào — đối chiếu với bốn phép kiểm tra văn phong. Jev trả về kết quả với trung vị 0,35 giây mỗi đoạn, so với 8,83 giây của Claude Fable 5.1 ở mức nỗ lực cao: nhanh hơn khoảng 25 lần với chi phí chỉ bằng khoảng 1/580. Nó phát hiện được sáu trong bảy lỗi được cài. Claude Fable 5.1 phát hiện được cả bảy. Phán quyết của Every là "tốt nhưng chưa hoàn hảo", và đó chính là cách đọc trung thực trong một câu về Jev từ bài kiểm tra độc lập duy nhất mà đến nay có ai đó công bố — những tuyên bố về tốc độ và chi phí vẫn đứng vững khi tiếp xúc với bên thứ ba, tuyên bố về độ chính xác thì nằm thấp hơn mức tiên tiến một bậc, và mẫu thử nhỏ đến mức không ai nên rút ra kết luận cho môi trường sản xuất từ đó.

Một lưu ý về kiểu bằng chứng mà bài viết này đang sử dụng, vì các tầng bằng chứng cách xa nhau một cách bất thường đối với một mô hình mới như thế này. Jev là thật và có thể gọi tới: có một endpoint được tài liệu hóa, một SDK Python, một alias mô hình và một mức giá đã công bố. Việc ra mắt do nhà cung cấp công bố, không phải bị rò rỉ, và không ai phải đoán xem nó có tồn tại hay không. Nhưng mọi tuyên bố về hiệu năng mà TypeSafe đưa lên hàng đầu đều là của chính TypeSafe, kiến trúc chưa được công bố, trọng số chưa được phát hành, và bảng điều khiển benchmark đằng sau con số 20-200x gây chú ý là một tập hợp các đánh giá quy trình làm việc nội bộ chứ không phải một bảng xếp hạng công khai. Một bên bên ngoài đã kiểm thử nó. Bài viết này giữ số liệu của nhà cung cấp, số liệu độc lập và các câu hỏi mở tách biệt một cách rõ ràng, thay vì lấy trung bình chúng thành một sự đồng thuận vốn không tồn tại.

Những gì TypeSafe thực sự đã phát hành

Jev là mô hình đầu tiên trong cái mà TypeSafe gọi là các mô hình System One — cái tên vay mượn từ nửa nhận thức nhanh nhạy, trực giác của Daniel Kahneman, trái ngược với chế độ chậm hơn, có suy xét mà các chatbot mô phỏng. Sự đối lập mà TypeSafe đưa ra là với mô thức tiêu chuẩn: ép một trình tạo văn bản phát ra đầu ra có cấu trúc rồi phân tích cú pháp văn bản đó trở lại thành thứ mà mã có thể tin cậy. Jev bỏ qua hoàn toàn văn bản. Tài liệu của chính TypeSafe khẳng định thẳng thừng: "Các mô hình ngôn ngữ lớn (LLMs) được thiết kế để tạo ra văn bản cho con người đọc. Khi bạn cần một mô hình đưa ra phán đoán mà mã của bạn sẽ tiêu thụ, điều đó tạo ra sự không khớp."

Bề mặt đầu ra là ba nguyên thuỷ, và không có gì khác. Mọi câu hỏi bạn đặt ra đều phải là một trong số đó:

• Lựa chọn — chọn một tùy chọn từ danh sách bạn cung cấp, trả về tùy chọn đã chọn cùng xác suất cho từng ứng viên và một độ tin cậy. Các tùy chọn bị giới hạn ở 255 mỗi trường; vượt quá mức đó, TypeSafe mô tả một mô thức hai giai đoạn là chấm điểm từng ứng viên một cách độc lập rồi sau đó chọn.

• Điểm số — đặt trạng thái lên một thang đánh giá có thứ tự, trả về mức, xác suất cho từng mức và độ tin cậy. Rủi ro rời bỏ trên thang điểm 0-1 là ví dụ trong tài liệu.

• Noul — một từ ghép của “no” và “null” — một tuyên bố có/không duy nhất, trả về xác suất đã hiệu chỉnh rằng nó đúng.

A capture of TypeSafe's own documentation introduction page, showing the sentence 'Jev is TypeSafe's flagship model and the first System One model', a table of the three primitives Choice, Score and Noul with what each returns, and the line that adding questions to a call barely changes the response time.

Thuộc tính thú vị không nằm ở bất kỳ nguyên thủy đơn lẻ nào mà ở cách chúng kết hợp với nhau. Cả ba đều có thể được trộn trong một lời gọi API duy nhất, và mọi câu hỏi đều được đánh giá song song dựa trên một lần đọc chung cùng một trạng thái. Tài liệu của TypeSafe nói rằng việc thêm câu hỏi "hầu như không thay đổi thời gian phản hồi", và bài kiểm tra độc lập xác nhận điều đó trên thực tế — 21 câu hỏi trên 37 tài liệu vẫn nằm trong cùng 0,7 giây. Đó chính là điều khiến giá cho mỗi phán đoán sụp đổ: bạn không trả tiền cho một lần sinh dài hơn, mà trả tiền cho một lượt xử lý duy nhất.

Phạm vi thực tế, như được ghi trong tài liệu và như những người dùng đầu tiên báo cáo: ngân sách yêu cầu khoảng 32.000 token, được mô tả trong tài liệu của TypeSafe là khoảng 150.000 ký tự tiếng Anh; không có đầu vào hình ảnh hay âm thanh khi ra mắt; và cấu trúc yêu cầu – phản hồi không theo quy ước chat-completions của OpenAI, nên để gọi nó cần một client riêng thay vì chỉ đổi base URL. Quyền truy cập là danh sách chờ early-access cùng một playground trên trình duyệt, với code>jev-latest/code> là bí danh của model.

RLCD có nghĩa là đã hiệu chuẩn, không phải là ưu tiên

TypeSafe huấn luyện Jev bằng một phương pháp mà họ gọi là RLCD — Học tăng cường cho các Quyết định được Hiệu chỉnh, theo tài liệu của chính công ty. Từ viết tắt này còn quá mới đến mức các bài đưa tin ban đầu đã mở rộng nó một cách không nhất quán, nên đáng để xác định chính xác nó thực sự đặt tên cho điều gì, bởi vì sự phân biệt ấy chính là toàn bộ luận điểm nghiên cứu.

RLHF tối ưu hóa cho đầu ra được con người ưa thích. RLVR tối ưu hóa cho tính đúng đắn có thể kiểm chứng, kiểu vượt qua ca kiểm thử. RLCD tối ưu hóa cho hiệu chuẩn: một mô hình nói nó tự tin 70% thì nên đúng khoảng 70% số lần. Đó là một mục tiêu khác với việc đúng, và đó là lý do mọi câu trả lời của Jev đều đi kèm một phân phối xác suất thay vì chỉ một câu trả lời. Kiểu thất bại dự kiến là một mô hình biết khi nào nó không biết, để mã của bạn có thể quyết định phải làm gì với điều đó.

Điều mà nó mang lại cho bạn trong thực tế là một bề mặt điều khiển. Mẫu được tài liệu hóa gồm ba dải độ tin cậy — hành động tự động ở mức cao nhất, gắn cờ hoặc xác nhận ở giữa, chuyển cho con người ở mức thấp nhất — với các ngưỡng nằm trong mã của bạn chứ không phải trong mô hình. Liệu các dải này có trung thực hay không là một câu hỏi thực nghiệm về dữ liệu của bạn, và đó là câu hỏi mà TypeSafe nói rõ rằng bạn phải tự trả lời, lưu ý rằng các ngưỡng độ tin cậy mang tính đặc thù theo từng trường hợp sử dụng và nên được kiểm thử dựa trên các ví dụ đã gán nhãn của chính bạn. Hướng dẫn đó là câu quan trọng nhất trong tài liệu, và là lý do phần tiếp theo tồn tại.

Những con số, được sắp xếp theo người tạo ra chúng

Đây là chỗ mà hầu hết các bài viết về Jev trở nên thiếu chặt chẽ, nên đáng để nói rõ ràng về nguồn gốc. Đây là những gì đến từ nhà cung cấp, những gì đến từ một kiểm thử viên độc lập, và những gì đơn giản là chưa biết.

• Do nhà cung cấp báo cáo, chưa được tái lập — những tuyên bố nổi bật về tốc độ và chi phí. Độ trễ đầu-cuối 70-500ms so với 3-329 giây đối với các lệnh gọi LLM tiên tiến; nhanh hơn 20-200 lần và rẻ hơn 40-400 lần; một kết quả quy trình trong trường hợp tốt nhất được quảng cáo là nhanh hơn 193,6 lần và rẻ hơn 444,6 lần. TypeSafe thừa nhận đây là những con số trong trường hợp tốt nhất chứ không phải phổ quát.

• Do nhà cung cấp báo cáo và có thể kiểm chứng trên bảng giá — 0,042 đô la cho mỗi triệu token đầu vào, tức 42 đô la cho mỗi tỷ token, với đầu ra miễn phí. Lý do đầu ra miễn phí nằm ở cơ chế vận hành chứ không phải ở chiêu khuyến mãi: không có giải mã tự hồi quy để đo đếm, nên không có token đầu ra nào để tính tiền. Để hình dung quy mô, cùng tài liệu ra mắt đó đặt mức giá đầu vào điển hình cho các mô hình tiên tiến ở khoảng 0,20 đến 10 đô la mỗi triệu token, với giá đầu ra thường gấp khoảng năm lần giá đầu vào.

Được nhà cung cấp báo cáo, từ một benchmark nội bộ — bảng điều khiển quy trình làm việc của chính TypeSafe, 711 trường hợp trong bốn tác vụ, với các câu trả lời tham chiếu được lấy từ đánh giá trung bình của GPT-6 Astra và Claude Fable 5.1 thay vì đáp án đúng. Trên bảng điều khiển đó, Jev đạt mức tổng hợp 67.8% so với 74.1% của đối thủ so sánh tốt nhất. Chi tiết: sự cố bảo mật 61.7% so với 66.2% của Opus 5; khả năng quan sát dấu vết tác nhân 71.6% so với 76.6%; xử lý hóa đơn 61.8% so với 79.1%; dịch vụ khách hàng 76.0% so với 78.3%. Jev thắng ở cột chi phí và độ trễ trên biểu đồ đó và thua ở cột độ chính xác. Bản thân bảng điều khiển ghi nhận khả năng thiên lệch của hệ thống đánh giá, và TypeSafe đã nói rằng họ cố ý bỏ qua các bảng xếp hạng công khai để thay bằng các đánh giá một lần gắn với các bản cập nhật sản phẩm.

• Đo lường độc lập, mẫu nhỏ — các thử nghiệm Every được mô tả ở trên: 777 phán đoán trong dưới 0,7 giây với chi phí khoảng một phần tư xu; 1.709 phán đoán qua 11 thí nghiệm với tổng chi phí dưới một xu; nhanh hơn khoảng 25 lần và chỉ bằng 1/580 chi phí của Claude Fable 5.1 trên một tác vụ phân loại 12 đoạn, nhưng bỏ sót một trong bảy lỗi được cài sẵn mà đối thủ so sánh phát hiện được. Kết luận của chính Every là họ sẽ muốn kiểm tra độ chính xác kỹ lưỡng hơn nhiều trước khi đưa nó vào sản xuất.

• Không rõ — kiến trúc. Không có bài báo khi ra mắt, không có số lượng tham số, không tiết lộ tính toán huấn luyện, không có trọng số. TypeSafe cho biết các chi tiết đang được giữ "kín như bưng trong lúc này", và có thể sẽ có một bài báo sau này.

A single-column scoreboard titled 'Jev - the scoreboard' listing six dimensions: latency 70-500 ms claimed, price $0.042 per million input with output free, accuracy 67.8% on the vendor dashboard, independent test 6 of 7 defects caught, context about 32K tokens with no image input, and weights not released.

Quy luật xuyên suốt các bậc đó là nhất quán, và đó không phải là quy luật mà tiêu đề 200x gợi ra. Mọi con số độc lập và từ nhà cung cấp đều nhất trí rằng Jev rẻ hơn rất nhiều và nhanh hơn rất nhiều. Không có con số nào ở bất cứ đâu, kể cả của chính TypeSafe, cho thấy nó chính xác hơn các mô hình tiên phong mà nó được định giá để so kè. Trên bảng điều khiển của chính nhà cung cấp, nó nằm quanh mức của một mô hình tầm trung tốt. Phép so sánh còn đứng vững không phải là “thông minh ngang một mô hình tiên phong với giá bằng một phần trăm” — mà là “gần với khả năng phán đoán của một mô hình tầm trung với chi phí chỉ bằng một phần nhỏ của một xu mỗi lần gọi, đủ nhanh để chạy trong từng lượt.”

“zero hallucination” nghĩa là gì và không nghĩa là gì

Tài liệu ra mắt của TypeSafe bao gồm một biểu đồ cho thấy tỷ lệ lỗi gọi công cụ là 0% đối với Jev, so với tỷ lệ khác 0 ở các mô hình đối chứng, và cụm từ "kháng ảo giác" luôn đi kèm với mô hình. Cả hai đều đúng, và cả hai đều hẹp hơn những gì chúng gợi ra khi đọc.

Sự bảo đảm này mang tính cấu trúc. Mọi câu trả lời khả dĩ đều được liệt kê trước khi mô hình chạy — bạn đã cung cấp danh sách lựa chọn, bộ tiêu chí chấm, hoặc phát biểu đúng/sai — nên không có khoảng trống nào để xuất ra một giá trị nằm ngoài kiểu đã khai báo. Một lời gọi công cụ sai định dạng là điều Jev không thể tạo ra. Đó là một thuộc tính kỹ thuật đích thực, và với bất kỳ ai đã dành cả tuần viết logic thử lại xoay quanh các lỗi phân tích cú pháp JSON, nó đáng giá bằng tiền thật.

Đó không phải là một khẳng định về việc đúng hay sai. Một câu trả lời hợp lệ theo schema vẫn có thể sai: Jev có thể tự tin định tuyến một khiếu nại về thanh toán đến hàng đợi kỹ thuật, và đầu ra sẽ hoàn toàn đúng định dạng trong khi vô dụng. Almeida cũng đã nói điều tương tự, thừa nhận rằng hoàn toàn có thể sai một cách tự tin. Cách hữu ích để dung hòa cả hai sự thật là Jev loại bỏ nhóm lỗi đến từ định dạng đầu ra, và không làm gì cả đối với nhóm lỗi đến từ phán đoán. Điều đó có nghĩa là câu hỏi về độ chính xác hoàn toàn là câu hỏi về hiệu chuẩn, và hiệu chuẩn chính xác là thứ bạn phải tự đo lường.

Cách kiểm chứng tuyên bố hiệu chuẩn trên dữ liệu của riêng bạn

Hiệu chuẩn là một trong số ít thuộc tính mô hình mà bạn có thể kiểm tra đúng cách chỉ với vài trăm ví dụ và không cần hạ tầng ML, và đó là phép kiểm tra duy nhất quan trọng trước khi Jev chạm vào một luồng production. Quy trình rất ngắn.

Hãy lấy vài trăm trường hợp bạn đã có nhãn. Hỏi Jev câu hỏi quan trọng — quyết định định tuyến, điểm rủi ro, kiểm tra khiếm khuyết — và nhóm các câu trả lời theo độ tin cậy mà nó báo cáo. Sau đó kiểm tra xem nhóm độ tin cậy 0,9 có đúng khoảng 90% số lần không, nhóm 0,7 khoảng 70%, v.v. Một mô hình được hiệu chỉnh tốt sẽ vẽ nên một đường chéo. Một mô hình chỉ đơn thuần tự tin sẽ dồn mọi thứ lên trên 0,9 và đúng 70% số lần, và đó chính là hình dạng âm thầm phá hỏng một pipeline tự động.

Cùng phép kiểm tra đó cho bạn biết nên dùng những ngưỡng nào. Nếu nhóm 0,9 thực sự chính xác 90% trên dữ liệu của bạn, bạn có thể tự động hóa nó. Nếu dải ở giữa của bạn nhão nhoét, bạn chuyển nó cho con người hoặc giao nó cho một mô hình sinh và để đường tốn kém xử lý sự mơ hồ. Sự phân tách đó — mô hình rẻ trên phần đa số tự tin, mô hình đắt trên phần còn lại không chắc chắn — chính là kiến trúc thực sự mà Jev đang lập luận, và đó là lý do mô hình được hiểu đúng nhất như một thành phần thay vì một thứ thay thế.

Chi phí là bao nhiêu, được tính toán chi tiết

Cách tính giá đơn giản đến mức dễ suy luận, điều này rất hiếm gặp. Đầu vào là 0,042 đô la mỗi triệu token. Đầu ra miễn phí. Với ngân sách yêu cầu được ghi trong tài liệu là khoảng 150.000 ký tự, một lần gọi có kích thước tối đa tốn chưa đến một xu.

Hai con số được báo cáo cho thấy phần nào quy mô. Một người dùng ban đầu đã chạy khoảng 5.000 yêu cầu với chi phí chỉ khoảng 2 đô la. Buổi trình diễn Doom — Jev điều khiển một bot bằng cách dùng mô tả văn bản về trạng thái trò chơi thay vì pixel thô — chạy ở khoảng 10 lệnh gọi mỗi giây với chi phí khoảng 7 đô la một giờ. Và 777 phán quyết của Every trên 37 tài liệu có chi phí xấp xỉ một phần tư xu, và đây chính là con số khiến trường hợp sử dụng thú vị trở nên rõ ràng: ở mức giá đó, việc kiểm tra từng lượt một của một vòng lặp agent không còn là một quyết định về chi phí nữa mà trở thành mặc định.

Đó là lập luận thực sự dành cho Jev. Một lượt kiểm chứng theo từng lượt — lệnh gọi công cụ này có mâu thuẫn với lệnh trước đó không, đầu ra này có nhất quán với ý định đã nêu của người dùng không, điều này có nên dựng cờ cảnh báo không — luôn khả thi về mặt kỹ thuật với một mô hình tiên tiến và phi lý về mặt kinh tế ở quy mô lớn. Với mức 0,042 USD mỗi triệu token và không tính phí đầu ra, cùng lượt kiểm chứng ấy trở nên khả thi về chi phí ở mọi lượt. Giá trị ở đây không nằm ở việc Jev suy nghĩ tốt hơn một mô hình tiên tiến, bởi vì nó không như vậy. Giá trị nằm ở chỗ nó suy nghĩ đủ rẻ và đủ nhanh để được hỏi ý liên tục.

Cần nói thẳng, vì đây là câu hỏi hiển nhiên tiếp theo: OrcaRouter không phục vụ Jev. Mô hình của TypeSafe đang ở giai đoạn truy cập sớm, có danh sách chờ, và dùng hình thức yêu cầu riêng của nó, nên bất kỳ ai muốn thử đều phải đi trực tiếp qua TypeSafe. Nơi một lớp định tuyến thực sự phù hợp là nửa còn lại của quy trình. Mô hình mà Jev được thiết kế hướng tới là hai mô hình, không phải một — Jev đưa ra quyết định có kiểu, còn một mô hình sinh sẽ xử lý phần cần văn xuôi, mã nguồn hoặc giải thích. Nửa sinh đó chính là phần OrcaRouter đảm nhiệm: 197 mô hình từ 15 nhà cung cấp phía sau một khóa tương thích OpenAI, với mức giá niêm yết của nhà cung cấp được chuyển nguyên qua cùng mức chênh 0%, nên khi nhà cung cấp giảm giá thì bên chúng tôi nhận được ngay trong ngày họ phát hành. Cả hai nửa của một quy trình mang dáng Jev đều có thể kiểm thử mà không cần hợp đồng thứ hai, và khi thành phần ra quyết định chưa được chứng minh, đường dự phòng chính là thứ giữ cho một kết quả hiệu chỉnh tồi không biến thành sự cố trong môi trường vận hành.

A capture of the OrcaRouter models catalogue showing the header '197 models - 15 providers - one API key, one bill', an OpenAI-compatible chat-completions request example, and model cards for DeepSeek V4.1 Flash, OpenAI GPT-6 Astra and Google Gemini 3.8 Flash with their per-million-token input and output prices.

Nơi Jev không phù hợp

Các hạn chế được nhà cung cấp nêu rõ một cách bất thường, khiến phần này dễ viết trung thực. Jev không thể tạo văn bản tự do. Nó không thể viết mã. Nó không thể duy trì một cuộc trò chuyện. Nó không có giao diện trò chuyện, không có đầu vào hình ảnh và ngân sách ngữ cảnh khoảng 32.000 token — thấp hơn một bậc độ lớn so với các mô hình ngữ cảnh dài mà nó đang bị đem ra so sánh về giá. Các trường lựa chọn giới hạn ở 255 tùy chọn. Và thuộc tính "không ảo giác", như trên, liên quan đến định dạng đầu ra chứ không phải tính đúng thật.

Mạng này có mức độ phù hợp khá hẹp. Tốt: phân loại và định tuyến khối lượng lớn, các lượt kiểm tra rào chắn và xác minh, các quyết định nhạy cảm với độ trễ, chấm điểm song song các tập tài liệu lớn, bất cứ đâu mà câu trả lời đúng thực sự là một lựa chọn, một con số trên thang điểm, hoặc một giá trị boolean. Kém: tạo sinh mở dưới bất kỳ hình thức nào, suy luận ngữ cảnh dài, đối thoại nhiều lượt, hoặc bất kỳ tác vụ nào mà câu trả lời đúng là cả một câu. Nếu vấn đề của bạn không thể quy về một câu hỏi có kiểu, thì Jev không phải là một cách rẻ hơn để giải quyết nó — nó hoàn toàn không phải là một cách giải quyết nó.

Cũng có một lời chỉ trích chính đáng về cách định khung này đáng để tiếp tục ghi nhớ. Gọi Jev là một mô hình tiên phong là vay mượn uy tín mà mô hình này chưa giành được: nó không thể viết mã, trò chuyện hay viết nổi một câu, và các biểu đồ so sánh dựa vào những mô hình tiên phong làm đường cơ sở trong khi cột độ chính xác lại kể một câu chuyện khác. Tuyên bố dễ bảo vệ hơn, và là điều mà bằng chứng thực sự ủng hộ, là TypeSafe đã đẩy xa giới hạn về tốc độ và chi phí cho các quyết định có cấu trúc. Đó là một điều đáng kể đã làm được. Đó là một việc khác với việc xây dựng một mô hình sánh ngang với GPT-6 Astra hay Claude Fable 5.1.

Điều gì sẽ thay đổi bức tranh này

Ba điều, theo thứ tự đại khái về mức độ chúng sẽ có ý nghĩa.

• Một bài báo kiến trúc được công bố hoặc trọng số mở. Mọi thứ về cách Jev đạt được tốc độ của nó hiện vẫn là một hộp đen, và tuyên bố rằng đánh giá song song chính là cơ chế — phép loại suy mà Almeida đưa ra là việc thay thế tính toán tuần tự theo cách các transformer đã thay thế mạng hồi tiếp — chỉ là một khẳng định chứ không phải một kết quả được chứng minh. Cho đến khi thiết kế được công bố, tốc độ là sự thật còn lời giải thích là tiếp thị.

• Một đánh giá độc lập thứ hai với mẫu lớn hơn. Các bài kiểm tra của Every là bằng chứng mạnh nhất hiện có và chúng bao quát 12 đoạn về câu hỏi độ chính xác mang tính quyết định. Thêm một lần chạy độc lập nữa, trên vài trăm trường hợp đã được gán nhãn, sẽ phân định liệu việc bỏ sót một khiếm khuyết trong bảy có phải là nhiễu hay là tỷ lệ lỗi thực sự.

• Một cuộc kiểm toán hiệu chuẩn trên dữ liệu đầu vào thực tế, lộn xộn. Mọi thứ được công bố cho đến nay đều sử dụng các khung kiểm thử sạch sẽ. Câu hỏi bỏ ngỏ đối với một mô hình mà toàn bộ giá trị đề xuất của nó dựa vào các điểm số độ tin cậy đáng tin cậy là những điểm số đó hoạt động ra sao trên những trường hợp thực sự mơ hồ — những trường hợp mà một người đánh giá cũng sẽ do dự. Đó chính là con số quyết định liệu Jev có an toàn để tự động hóa dựa vào hay không, và chưa ai công bố nó.

Cho đến lúc đó, lập trường hợp lý là cụ thể thay vì chung chung. Jev là một mô hình thật, đã ra mắt, rẻ bất thường với lợi thế cấu trúc thực sự về độ tin cậy đầu ra, hồ sơ độ chính xác nằm quanh tầm trung, và một tuyên bố hiệu chuẩn vừa hợp lý, vừa được chính nhà cung cấp của nó khuyến nghị rõ ràng nên tự kiểm thử, vừa chỉ được xác thực độc lập trên một mẫu nhỏ. Nếu quy trình làm việc của bạn có một bước quy về một câu hỏi gõ ra được hỏi đủ thường xuyên đến mức dùng một mô hình tiên tiến sẽ là lãng phí, thì đây là một trong những cách rẻ nhất để hỏi nó — và giá trị độ tin cậy mà nó trả về mới là phần cần kiểm tra trước khi bạn tin, chứ không phải tốc độ.

So sánh trong bài viết này1

Phát hiện từ bài viết này · Benchmark: Artificial Analysis · cập nhật hằng ngày