Jev lựa chọn thay vì trò chuyện: ba bản demo và những giới hạn phía sau

Sơ đồ giải thích do chúng tôi biên soạn, không phải kết quả đo chuẩn của nhà cung cấp. Mô hình lựa chọn trong một không gian đã xác định; mã ứng dụng vẫn chịu trách nhiệm về quyền hạn, kiểm tra tính hợp lệ và thực thi.

Bộ phân loại hộp thư đến không cần viết một bài luận rồi mới chọn thư mục. Bộ điều khiển trình duyệt thường chỉ cần chọn một nút có sẵn, không cần nghĩ ra lệnh mới. Chính ở những quyết định nhỏ như vậy, Jev, mô hình System One đầu tiên của TypeSafe AI, thể hiện giá trị đáng chú ý nhất của mình.

TypeSafe giới thiệu Jev vào ngày 15 tháng 9 năm 2026. Điểm khác biệt hữu ích không đơn thuần là có thêm một mô hình nhanh: Jev trả về các quyết định trong phạm vi giới hạn thay vì văn bản tự do. Điều đó thay đổi cách bạn xây dựng chương trình bao quanh mô hình, nhưng không loại bỏ khả năng chọn sai câu trả lời. Xem thông báo ra mắt chính thức để hiểu cách nhà cung cấp định vị mô hình này.

Bài hướng dẫn này xem xét ba minh chứng công khai: một tác vụ trình duyệt có ảnh GIF và video làm bằng chứng có thể tải xuống, báo cáo của một tác giả về việc phân loại 1,500 email và các bản demo trò chơi của TypeSafe. Chúng tôi cũng chuyển những ví dụ đó thành một kế hoạch đánh giá cụ thể. Bài viết về các trường hợp sử dụng trên Tistory, xuất bản ngày 18 tháng 9, là điểm khởi đầu của quá trình nghiên cứu; những ứng dụng được đề xuất trong bài đó không được coi ở đây là các triển khai tại khách hàng đã qua xác minh độc lập.

Tóm tắt nhanh:

• Jev có thể lựa chọn, chấm điểm hoặc đánh giá một mệnh đề dựa trên văn bản; nó không thay thế mô hình viết văn bản tùy ý.
• Một kết quả hợp lệ về kiểu dữ liệu vẫn có thể sai về ngữ nghĩa. Hãy để mã chương trình đảm nhiệm việc kiểm tra và cấp quyền cuối cùng.
• Bản ghi thao tác trình duyệt là có thật, nhưng một tác vụ không phải phép đo chuẩn tổng quát. Ví dụ về email là báo cáo của tác giả, không phải nghiên cứu độ chính xác đã công bố.
• Bắt đầu bằng việc phân loại có thể đảo ngược, đo lỗi trên dữ liệu của chính bạn và cho phép mô hình không đưa ra lựa chọn như một kết quả được hỗ trợ.

Một câu trả lời ngắn có thể đòi hỏi một câu hỏi thật rõ ràng

Ba thành phần cơ bản của API là Choice, Score và Noul. Choice chọn trong số các phương án được đặt tên. Score đánh giá theo các mức đã được mô tả và sắp thứ tự. Noul trả về xác suất cho một mệnh đề có thể trả lời có hoặc không; giá trị gần giữa thang thể hiện sự không chắc chắn về mệnh đề đó, chứ không phải mức độ nghiêm trọng trung bình. Tài liệu về các thành phần cơ bản xác định những quy ước này.

Thay đổi trong thực hành là xác định các kết quả có thể xảy ra trước khi yêu cầu mô hình quyết định. Thay vì yêu cầu một đoạn văn về tin nhắn hỗ trợ vừa nhận, bạn có thể hỏi liệu tin nhắn đó liên quan đến thanh toán, quyền truy cập tài khoản, lỗi sản phẩm hay một nhóm chưa xác định được. Sau đó, ứng dụng của bạn quyết định hiển thị hàng đợi nào. Kết quả giống như ghi chuyển hướng trên đường ray, không phải cả đoàn tàu: nó giúp định hướng công việc nhưng không cung cấp mọi khả năng cần thiết để hoàn thành công việc đó.

Viết các phương án tốt là một phần của công việc kỹ thuật. Nếu hai nhãn chồng lấn về nghĩa, một lựa chọn có vẻ chắc chắn có thể che giấu vấn đề trong hệ thống phân loại của bạn. Nếu không nhãn nào phù hợp, việc buộc phải chọn sẽ biến sự thiếu bao quát thành vẻ chắc chắn giả tạo. Phương án chuyển sang kiểm tra thường có giá trị hơn việc thêm một nhóm với tên gọi quá hẹp, vì nó chỉ ra nơi cần cải thiện đặc tả quyết định.

Theo kiểm tra vào ngày 30 tháng 9 năm 2026, tài liệu tham chiếu mô hình liệt kê jev-1.13.0, đầu vào chỉ có văn bản và giá $0.042 cho mỗi triệu token đầu vào, còn token đầu ra miễn phí. Đó là giá token của mô hình, không phải tổng chi phí vận hành một tác nhân. Trình duyệt, việc trích xuất, mô hình hỗ trợ, các lần thử lại và việc kiểm tra của con người cũng phải được tính vào ngân sách vận hành.

Ảnh GIF trình duyệt cho thấy một lần tìm kiếm thực tế, không phải đặt vé máy bay

Kho mã jev-ultrafast công khai của Browser Use có bản ghi một tác vụ tìm chuyến bay từ Zurich đến London trên Google Flights. Jev chọn thao tác và đối tượng đích từ biểu diễn hiện tại của trang. Một thành phần hỗ trợ sinh văn bản riêng cung cấp nội dung khi thao tác đã chọn yêu cầu nhập chữ. Đây là một hệ thống kết hợp nhiều thành phần, không phải bằng chứng cho thấy bản thân Jev sinh ra mọi chuỗi ký tự hay diễn giải các khung hình video.

Ảnh GIF thực tế do tác giả phía Browser Use ghi lại, gắn với commit 1231850a0bf1a0c0341fe408ef1668dbbfdfac46. Copyright 2026 Browser Use, giấy phép MIT. Ảnh minh họa quy trình tìm kiếm, không phải mua vé. Có thể phát cùng bản ghi đó bên dưới.

Tệp MP4 của tác giả, hiển thị ở tốc độ ghi hình gốc với các nút điều khiển của trình duyệt. Bản ghi gốc và ghi chú đo lường; giấy phép MIT được lưu giữ. Chúng tôi đã xem xét các tài liệu công khai; chúng tôi không chạy lại phép đo chuẩn này.

Thời gian hoàn thành mà tác giả đo được cho bản ghi là 7.073 giây. Đồng hồ bắt đầu ở lần dự đoán đầu tiên sau khi quan sát trang chủ ban đầu, không phải khi khởi chạy một trình duyệt mới. Việc thiết lập, điều hướng ban đầu và một lượt xác minh độc lập mới sau khi chạy đều nằm ngoài khoảng thời gian được đo. Kết quả tìm kiếm được kiểm tra; không có vé nào được chọn hay mua. Những ranh giới đó là điều thiết yếu để hiểu ý nghĩa của con số.

Cùng báo cáo đó so sánh sáu lượt chạy luân phiên, ba lượt cho mỗi môi trường thực thi. Thời gian tác vụ trung vị giảm từ 9.450 giây xuống 7.092 giây, trong khi số lần gọi giao thức trình duyệt trung vị giảm từ 1,092 xuống 101. Cả hai nhánh đều dùng Jev và cùng một thành phần hỗ trợ văn bản, nên đây chủ yếu là so sánh môi trường thực thi, không phải cuộc so tài giữa hai họ mô hình. Tác giả nêu rõ cỡ mẫu nhỏ và tính biến động của web đang hoạt động trong báo cáo hiệu năng.

Theo cách hiểu của chúng tôi, vòng lặp trình duyệt bao quanh mô hình xứng đáng được chú ý ngang với bản thân mô hình. Việc liên tục thu thập thông tin trang, xác định đối tượng đích và vô hiệu hóa các quyết định có thể tốn kém hơn vẻ đơn giản của một cú nhấp chuột. Bộ máy quyết định nhanh hơn không bù đắp được một mô tả thiếu tin cậy về nút mà nó cần chọn. Kho mã vẫn giữ bước xác minh kết quả độc lập, vì việc mô hình nói rằng đã xong không chứng minh tác vụ đã hoàn thành.

Đây cũng là lúc những giới hạn của bản demo trở nên hữu ích. Bản triển khai được mô tả trong tài liệu không bao quát mọi khung trang, phần tử canvas, quy trình tải lên hay mọi tiện ích giao diện điều khiển bằng bàn phím. Nhóm đánh giá nên tái hiện tác vụ đại diện và các tình huống lỗi của chính mình, thay vì suy ra rằng tìm chuyến bay thành công đồng nghĩa với khả năng thao tác trình duyệt nói chung. Hãy xem bản ghi là bằng chứng có thể kiểm tra được về một cách kết hợp thành phần đang hoạt động.

Bài đăng về 1,500 email là ví dụ hứa hẹn nhưng còn thiếu cơ sở tính tỷ lệ

Vào ngày 16 tháng 9 năm 2026, vogel (@ryanvogel) đăng trên X rằng anh đã thử Jev trên 1,500 email của chính mình và ấn tượng với kết quả phân loại. Bài đăng gốc có kèm video. Đây là một ví dụ hữu ích từ người dùng thực tế vì khối lượng công việc cụ thể và nguồn chính là người báo cáo thử nghiệm, thay vì một danh sách ứng dụng giả định không rõ tác giả.

Tuy nhiên, đó không phải báo cáo về độ chính xác. Bài đăng không cung cấp bộ kiểm thử đã gán nhãn công khai, tỷ lệ lỗi đã đo, mức độ đồng thuận giữa những người đánh giá hay chi phí của các sai sót. Số lượng thư được xử lý cho biết quy mô thử nghiệm, không cho biết tính đúng đắn. Người đọc nên xem bản demo gốc trên X với sự phân biệt đó trong đầu; video được dẫn liên kết thay vì sao chép khi chưa có giấy phép phân phối lại.

Dù vậy, phân loại email vẫn là điểm bắt đầu hợp lý cho việc đánh giá vì có thể thiết kế nó theo cách đảo ngược được. Hiển thị các nhãn đề xuất bên cạnh hộp thư hiện có, giữ nguyên thư gốc và ghi lại các lần sửa. So sánh những cặp dễ nhầm lẫn, chẳng hạn hóa đơn với thư nhắc thanh toán, hoặc yêu cầu hủy với một lời phàn nàn chỉ nhắc đến việc hủy. Những trường hợp đó cho thấy các nhóm phân loại có phù hợp với quy trình thực tế của bạn hay không.

Một triển khai ban đầu không nên tự động xóa thư, gửi phản hồi hoặc phê duyệt giao dịch chỉ vì kết quả phân loại có vẻ chắc chắn. Những hành động đó đòi hỏi quyền hạn khác và kéo theo hệ quả khác. Hãy bắt đầu bằng đề xuất hoặc hàng đợi kiểm tra; chỉ cho phép một hành động có phạm vi hẹp sau khi đã đo được đặc điểm lỗi của nó. Đây là quy trình đánh giá do chúng tôi đề xuất, không phải khẳng định về cách tác giả trên X triển khai hệ thống.

Doom và Wikiracing giúp nhìn rõ vòng lặp quyết định

Trong đợt ra mắt của TypeSafe có bản demo Doom và bản demo Wikiracing, cả hai đều được dẫn từ bài giới thiệu chính thức. Chúng là những cách giải thích trực quan hữu ích về việc đưa ra quyết định lặp đi lặp lại. Chúng không chứng minh Jev là mô hình thị giác đa dụng hay có thể giải quyết các bài toán lập kế hoạch tùy ý.

Trong ví dụ Doom, mô hình nhận mô tả trạng thái bằng văn bản có cấu trúc, không phải ảnh chụp màn hình. Trong Wikiracing, nó chọn từ các liên kết sẵn có thay vì tự nghĩ ra URL đích. Cơ chế đáng chú ý là chu kỳ lặp lại gồm quan sát, lựa chọn trong phạm vi giới hạn và hành động. Các bản demo trò chơi giúp nhìn rõ chu kỳ đó, nhưng vẫn để ngỏ câu hỏi nó chuyển sang một môi trường khác tốt đến đâu.

Cách phân tách tương tự xuất hiện trong tài liệu demo nhà thông minh của TypeSafe. Các câu hỏi khác nhau có thể phân loại từng khía cạnh của một yêu cầu, trong khi một thành phần khác xử lý trò chuyện tự do hoặc tách yêu cầu gồm nhiều phần. Không nên mô tả kiến trúc đó như một mô hình duy nhất vừa sinh ngôn ngữ vừa thực thi mọi quyết định. Những tên gọi như trợ lý hay tác nhân thường che khuất các ranh giới này nếu bản triển khai không thể hiện chúng rõ ràng.

Sơ đồ do chúng tôi biên soạn dựa trên quy ước fan-out đã được mô tả trong tài liệu. Các câu hỏi đồng thời dùng chung trạng thái; chúng không âm thầm đọc câu trả lời của nhau.

Mẫu fan-out có thể giảm thời gian chờ tuần tự khi nhiều câu hỏi phụ thuộc vào cùng một nguồn. Ví dụ, chủ đề của một tin nhắn và việc nó có yêu cầu gọi lại một cách rõ ràng hay không có thể được đánh giá độc lập. Một câu hỏi phụ thuộc vào chủ đề vừa được chọn không thể giả định rằng câu trả lời đó đã tồn tại trong cùng một lần gọi. Hãy chuyển phần phụ thuộc ấy sang bước sau hoặc kết hợp các kết quả độc lập bằng logic xác định trong mã.

Câu trả lời đúng kiểu dữ liệu chưa đồng nghĩa với câu trả lời đúng

Cách hiểu nguy hiểm nhất về mô hình có đầu ra giới hạn là cho rằng câu trả lời đúng định dạng không thể sai. Nó vẫn có thể sai. Bộ phân loại có thể chọn một nhãn được phép nhưng không phù hợp, và bộ chọn hành động có thể chọn một nút hợp lệ trên nhầm biểu mẫu. Loại bỏ văn bản sai định dạng khỏi giao diện là có giá trị, nhưng điều đó xử lý một loại lỗi khác với việc hiểu sai tác vụ.

Ghi chú về năng lực không đồng đều của Jev 1.13 do TypeSafe cung cấp, được rà soát lần cuối ngày 17 tháng 9, mô tả những điểm yếu về số học, đếm, so sánh ngày, ngữ cảnh gây xao nhãng và đầu vào cố tình đánh lừa mô hình. Khi cần so sánh chính xác, hãy phân tích ngày tháng và tính toán số lượng bằng mã thông thường. Đừng biến một quy tắc xác định thành phán đoán ngữ nghĩa chỉ vì mô hình có thể nhận câu hỏi đó.

Tài liệu về độ tin cậy cũng quan trọng: Choice và Score cung cấp phân phối xác suất cùng một giá trị độ tin cậy được suy ra; Noul không có trường độ tin cậy riêng. Con số đó không phải xác suất đúng của câu trả lời có thể áp dụng phổ quát. Các ngưỡng cần được kiểm chứng trên tác vụ của chính bạn, đặc biệt khi hệ quả của dương tính giả khác với hệ quả của âm tính giả.

Sơ đồ đánh giá do chúng tôi biên soạn. Vượt qua một cửa kiểm tra không đồng nghĩa với vượt qua cửa tiếp theo; một đầu ra được phép vẫn đòi hỏi cách diễn giải đúng và hành động được cấp quyền.

Với công việc đa ngôn ngữ, hãy kiểm thử từng ngôn ngữ mà bạn thực sự phục vụ. Tài liệu mô hình cho biết tiếng Anh là ngôn ngữ huấn luyện chính và chất lượng không đồng đều giữa các ngôn ngữ khác, bao gồm cả các hệ chữ CJK. Vì thế, hàng đợi hỗ trợ bằng tiếng Hàn hoặc kho bản tin gồm nhiều ngôn ngữ cần được đánh giá như một nhóm riêng, chứ không mặc nhiên được coi là phần mở rộng của điểm số tiếng Anh. Bản dịch cũng có thể làm thay đổi bằng chứng, nên hãy giữ nguyên bản nếu bạn đánh giá một phiên bản đã dịch.

Thiết kế một thử nghiệm có thể thất bại một cách trung thực

Một đợt thử nghiệm thí điểm hữu ích bắt đầu từ quyết định mà nhóm của bạn có thể gán nhãn nhất quán. Chọn tác vụ có thể đảo ngược, như đề xuất hàng đợi hỗ trợ, đánh dấu một mục có thể bị trùng hoặc gán nhãn tài liệu để kiểm tra sau. Tránh lấy việc bản demo trông mượt mà hay không làm định nghĩa thành công. Hãy xác định những kết quả sai mà bạn sẽ nhận ra, những kết quả có thể bị bỏ sót và cái giá mà mỗi loại gây ra cho người dùng.

1. Viết đặc tả quyết định. Liệt kê các kết quả có thể xảy ra, những trường dữ liệu nguồn cần thiết và phương án chuyển sang kiểm tra. Tách diễn giải ngữ nghĩa khỏi tính toán và quyền hạn.
2. Tạo bộ dữ liệu đánh giá. Dùng tài liệu mà bạn được phép xử lý. Bao gồm các trường hợp điển hình, ranh giới phân loại mơ hồ, nhiều ngôn ngữ xen lẫn, trường trống và chỉ dẫn độc hại bên trong văn bản nguồn.
3. Giữ riêng một phần dữ liệu chưa dùng để tinh chỉnh. Điều chỉnh tiêu chí trên một bộ dữ liệu, sau đó đo trên tài liệu không tham gia định hình cách diễn đạt tiêu chí. Ghi lại những bất đồng thay vì âm thầm định nghĩa lại câu trả lời kỳ vọng.
4. Đo lường quy trình. Theo dõi lỗi theo từng nhóm, tỷ lệ cần kiểm tra, độ trễ từ đầu đến cuối, số lần thử lại và tổng chi phí. Một lần gọi mô hình nhanh nằm trong vòng lặp truy xuất chậm vẫn tạo ra sản phẩm chậm.
5. Chạy ở chế độ đề xuất. Ghi lại phương án đã chọn, các xác suất liên quan, phiên bản mô hình và chỉnh sửa của con người mà không tự động thực hiện những hành động có hệ quả đáng kể.
6. Đưa một hành động có phạm vi giới hạn vào thực thi. Yêu cầu cấp quyền rõ ràng ở nơi phù hợp, lưu dấu vết kiểm toán và giữ cách quay lui khi nguồn hoặc phiên bản mô hình thay đổi.

Quy trình này được chủ ý thiết kế nghiêm ngặt hơn việc xem một bản ghi. Nó kiểm tra xem mô hình có giúp ích với phân bố các trường hợp của bạn hay không, kể cả những trường hợp khó xử lý. Tỷ lệ cần kiểm tra tưởng như cao vẫn có thể đáng chọn hơn một số ít sai sót âm thầm nhưng tốn kém. Hãy quyết định sự đánh đổi đó trước khi chọn ngưỡng, không phải sau khi phát hiện sự cố.

Cố định một phiên bản để có thể tái lập việc đánh giá và ghi lại phiên bản được trả về cùng mỗi kết quả. Các bí danh trỏ đến phiên bản thay đổi rất tiện khi khám phá, nhưng có thể làm thay đổi hành vi dù mã nguồn ứng dụng không thay đổi. Tài liệu đánh giá cần cho phép người khác tái dựng tiêu chí, đầu vào, kết quả kỳ vọng và phạm vi thực thi. Đó là cách một thử nghiệm hứa hẹn trở thành tính năng có thể duy trì lâu dài, thay vì chỉ là bộ sưu tập các đoạn video ấn tượng.

Điều cốt lõi: đưa phán đoán vào một đặc tả có giới hạn

Jev đáng chú ý nhất khi đưa ra một quyết định nhỏ, có thể kiểm tra, bên trong chương trình đã biết rõ các quy tắc của mình. Video trình duyệt cho thấy một hệ thống kết hợp đang hoạt động, bài đăng về email cung cấp thử nghiệm cụ thể đáng kiểm chứng và các bản demo chính thức cho thấy vòng lặp bên trong. Câu hỏi tiếp theo không phải là mô hình có chọn được câu trả lời hay không, mà là hệ thống của bạn có nhận ra lựa chọn sai trước khi nó gây ảnh hưởng hay không.

Nguồn và ghi công nội dung đa phương tiện

• TypeSafe: Giới thiệu các mô hình System One và Jev, ngày 15 tháng 9 năm 2026; thông báo ra mắt chính thức và bối cảnh các video trò chơi.
• Browser Use: jev-ultrafast, nguồn được cố định phiên bản, xem xét ngày 30 tháng 9 năm 2026. GIF và MP4: copyright 2026 Browser Use, giấy phép MIT; không hàm ý quan hệ liên kết.
• Browser Use: bản ghi và số đo từ các lượt chạy đối sánh, xem xét ngày 30 tháng 9 năm 2026; số đo của tác giả, không phải kết quả chúng tôi tái lập.
• vogel trên X: thử nghiệm phân loại 1,500 email, ngày 16 tháng 9 năm 2026; trường hợp sử dụng do tác giả tự báo cáo, kèm video gốc.
• Các thành phần cơ bản của TypeSafe, mô hình, độ tin cậy, fan-out và demo nhà thông minh, kiểm tra ngày 30 tháng 9 năm 2026.
• Năng lực không đồng đều của Jev 1.13, rà soát lần cuối ngày 17 tháng 9 năm 2026; kiểm tra ngày 30 tháng 9.
• Bài viết về các trường hợp sử dụng Jev trên Tistory, ngày 18 tháng 9 năm 2026; điểm khởi đầu nghiên cứu, không phải xác minh triển khai.

Giữ bằng chứng bên cạnh ghi chú

Khi nghiên cứu một mô hình mới, hãy lưu nguồn, ngày tháng của nguồn và điều mà bản demo thực sự chứng minh. Tạo tài khoản Telli.sh để sắp xếp tài liệu nghiên cứu và các ghi chú được tạo từ đó của riêng bạn mà không nhầm lẫn bản tóm tắt với bằng chứng gốc.