7 cách dùng Jev giúp giảm công việc thực tế trong phần mềm

Có người hỏi trang web của chúng tôi hiện có bao nhiêu tích hợp. Nó trả lời bằng lời khuyên về số trường nên có trong biểu mẫu đăng ký.

Câu trả lời đến rất nhanh. Nhưng vô ích.

Cả hai câu hỏi đều có từ “bao nhiêu”. Mã tìm kiếm của chúng tôi gán điểm tối thiểu 0,86 cho một mục FAQ được chấp nhận là trùng khớp, khiến một kết quả khớp yếu trông có vẻ đáng tin. Tốc độ đã che đi quyết định sai.

Đó là kiểu thất bại đáng suy nghĩ khi xem Ship with Jev. Vào ngày 26 tháng 9 năm 2026, danh mục này liệt kê 551 sản phẩm do cộng đồng xây dựng. Trò chơi nằm cạnh thành phần tìm kiếm, tác nhân trình duyệt, công cụ nghiên cứu và thử nghiệm định tuyến. Danh mục ghi nhận số liệu hiệu năng do tác giả cung cấp; đây là công cụ khám phá, không phải chuẩn đánh giá độc lập.

Câu hỏi thú vị là mẫu nào trong số đó thực sự giảm việc cho một sản phẩm.

Với các nhóm xây dựng tích hợp và phần mềm doanh nghiệp, đây là bảy hướng tôi sẽ đánh giá trước. Thứ tự thể hiện nhận định biên tập về mức hữu ích và khả năng kiểm thử. Những quy trình dưới đây là thiết kế đề xuất, trừ trường hợp có nêu rõ bản triển khai kèm liên kết.

Jev mang lại điều gì cho ứng dụng

TypeSafe mô tả Jev là mô hình dành cho những phán đoán có kiểu dữ liệu rõ ràng. Cung cấp trạng thái liên quan và một câu hỏi, bạn nhận về lựa chọn, xác suất hoặc điểm số để mã sử dụng. Bản đồ trường hợp sử dụng của họ bao gồm định tuyến, truy xuất, xác minh và trích xuất.

Sự phân biệt này có tiền đề hữu ích trong các tài liệu YouTube chúng tôi đã thu thập. Trong bài nói chuyện của Diogo Almeida tại AI Engineer, người đồng sáng lập TypeSafe lập luận rằng các khối cấu thành phần mềm nên có khả năng thể hiện nhiều trí thông minh hơn. Ông đối chiếu tham vọng đó với việc gắn thêm trợ lý vào phần mềm sẵn có. Đây là quan điểm của ông về hướng đi của AI, không phải phép đo hiệu năng hiện tại của Jev.

Hãy hình dung một chỗ rẽ đường ray. Kết quả hữu ích là xác định đoàn tàu nên đi vào đường ray nào đang dùng được. Một đoạn văn mô tả các đường ray không giúp gạt ghi.

Phản đối này có lý: “LLM thông thường cũng trả về JSON được.” Đúng. Lý do dùng một thành phần khác phải dựa trên chất lượng, chi phí và độ trễ đã đo cho chính quyết định đó. Chỉ trả về dữ liệu có kiểu rõ ràng không chứng minh được yếu tố nào.

Cần xem xét thách thức từ CLM trước tiên

Ngày 23 tháng 9, Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré và Azalia Mirhoseini công bố Contrastive Language Models. Công trình của họ thách thức giả định rằng Jev là con đường thực tế duy nhất dẫn tới các quyết định ngữ nghĩa nhanh.

Các tác giả báo cáo kết quả zero-shot tương đương Jev trên các tác vụ dùng máy tính, trò chơi và gọi công cụ, với độ trễ thấp hơn tới 9 lần. Họ báo cáo riêng mức 81,6% trên 38 tác vụ DeepSWE được giữ lại và 87,6% trên 30 tác vụ Terminal-Bench 2.1. Những kết quả lập trình này dùng bộ xác minh CLM đã tinh chỉnh để chọn giữa các lời giải do mô hình khác tạo ra. Họ cũng báo cáo Jev thấp hơn mốc chọn ngẫu nhiên trong thiết lập xác minh đó. Độ trễ được đo trên H100. Đây là kết quả của các tác giả, chúng tôi chưa tái lập độc lập. Xem đánh giá gốc và phương pháp.

So sánh này thay đổi điều chúng ta cần thử. Chọn hàng đợi hỗ trợ, chọn đoạn tài liệu tìm kiếm và đánh giá cả quá trình lập trình dài là các tác vụ khác nhau. Kết quả tốt ở việc này không quyết định việc kia.

CLM mã hóa trạng thái và hành động ứng viên riêng, cho phép lưu bộ nhớ đệm các biểu diễn hành động tái sử dụng. Kho mã mô tả giao diện tương thích TypeSafe và giới hạn trạng thái mặc định là 2.048 token; trạng thái dài hơn sẽ bị cắt nếu không cấu hình khác đi. Tương thích ở ranh giới API không chứng minh hai mô hình đưa ra quyết định tương đương.

Thẻ mô hình đã phát hành chỉ rõ các biểu diễn từ Qwen3-8B và cảnh báo rằng kết quả xác minh tốt cần các đầu mô hình đã tinh chỉnh. Thẻ cũng nói rõ CLM chấm điểm những ứng viên được cung cấp, không tạo ra lời giải. Trọng số mở tạo thêm lựa chọn đánh giá; phần cứng, vận hành dịch vụ và bảo trì vẫn có chi phí.

Với Tajo, bài học rất cụ thể: so sánh các mô hình ra quyết định trên cùng trường hợp, ghi riêng độ trễ khi gọi lần đầu và khi gọi lại, và thử các ứng viên sai nhưng có vẻ hợp lý. Cố định phiên bản mô hình và bộ mã hóa hoặc đầu chiếu nếu có. Từ chối cấu hình nhà cung cấp không được hỗ trợ thay vì âm thầm chọn nhà cung cấp khác. Kiểm tra lại việc hiệu chỉnh khi mô hình hoặc tập ứng viên đổi.

Bảy quy trình dưới đây vẫn đáng để đánh giá. Giá trị của chúng không phụ thuộc vào việc Jev thắng mọi phép so sánh.

1. Tìm kiếm có kiểm tra kết quả có trả lời câu hỏi không

Đây là lựa chọn đầu tiên của tôi vì lỗi dễ thấy và kết quả dễ gắn nhãn. Đoạn văn được trả về có trả lời đúng điều khách hỏi không?

Truy xuất một nhóm ứng viên nhỏ bằng tìm kiếm từ khóa, biểu diễn vector hoặc cả hai. Sau đó hỏi Jev xem mỗi đoạn có cung cấp dữ kiện được yêu cầu không. Hướng dẫn xếp hạng lại của TypeSafe minh họa cấu trúc hai bước này. Nó cũng cho thấy giới hạn: bộ xếp hạng lại không thể chọn tài liệu mà bước truy xuất đã bỏ sót.

1. Truy xuất

   từ khóa, biểu diễn vector

   Nhóm ứng viên nhỏ

   Không thêm được thứ đã bỏ sót
2. Jev

   phán đoán có kiểu dữ liệu

   Đoạn này có

   cung cấp dữ kiện không?
3. Câu trả lời

   hoặc không có câu trả lời

   Đúng hoặc chưa trả lời

   Đo tổng độ trễ

Với ví dụ đếm tích hợp của chúng tôi, đường ngắn nhất còn đơn giản hơn. Đếm các mục trong danh mục có thẩm quyền và nói rõ con số đó có nghĩa gì. Một trình kết nối có tài liệu và một kết nối do khách hàng thiết lập là hai thứ khác nhau.

Chỉ dùng phán đoán ngữ nghĩa cho câu hỏi cần hiểu ý, chẳng hạn “Có thể chỉ chuyển những khách hàng thay đổi từ hôm qua không?”. Truy xuất tài liệu đồng bộ phù hợp rồi kiểm tra nó có nói về cập nhật tăng dần không.

Bản triển khai jevsearch của Kyle McLaren thể hiện rõ thứ tự: kết quả từ khóa đến trước, tiếp đó là xếp hạng của Jev. Bộ đánh giá được công bố sử dụng chính kho tài liệu của dự án và các truy vấn có nhãn. Đó là bằng chứng hữu ích cho thử nghiệm ấy, không phải lời hứa với trang web hoặc ngôn ngữ khác.

Đo câu trả lời đúng, câu trả lời không có căn cứ, câu hỏi chưa được trả lời và tổng độ trễ. Bao gồm lỗi chính tả và truy vấn đã dịch. Kết quả không liên quan dù nhanh vẫn là không liên quan.

2. Định tuyến yêu cầu đến đúng trang, hàng đợi hoặc tác nhân

Một người dùng viết: “Tôi đổi tài khoản xong thì các liên hệ không chuyển sang nữa.” Ứng dụng cần phân biệt sự cố kết nối với thanh toán, ánh xạ trường và yêu cầu tạo đồng bộ mới.

Cung cấp màn hình hiện tại, cuộc hội thoại gần đây và các đích mà người dùng này được phép truy cập. Yêu cầu chọn đích phù hợp nhất, kèm lựa chọn rõ ràng là “không khớp”. Giữ mã định danh đích dưới quyền kiểm soát của ứng dụng.

Nhiều phán đoán có thể hữu ích cùng lúc: ý định, đích đến, mức khẩn cấp và liệu tin nhắn có chứa yêu cầu có thể thực hiện hay không. Mẫu fan-out của TypeSafe cho phép các câu hỏi độc lập dùng chung một yêu cầu. Sau đó mã sử dụng các câu trả lời liên quan.

Đề xuất điều hướng vô hại và quyền thực hiện công việc là hai quyết định riêng. Tìm đúng trang thanh toán không cấp quyền hoàn tiền. Tìm đúng tác nhân không cấp thông tin đăng nhập cho tác nhân đó.

Lợi ích thực tế là ít chuyển giao và ít vòng hỏi lại. Đo tần suất người dùng đến đúng nơi trong lần đầu. Giữ một bộ tình huống để chạy lại gồm những câu tiếp theo như “đúng”, “việc mới” và “những việc đó đã xong chưa?”. Chúng chỉ có nghĩa khi có bối cảnh.

3. Biến dữ liệu lộn xộn thành tích hợp đáng tin cậy

Đây là quy trình tích hợp được đề xuất. Bản xuất dữ liệu nguồn có customer_email, billing_email và account_owner_email. Hệ thống đích cần địa chỉ email của liên hệ.

So khớp chuỗi vẫn để lại sự mơ hồ thực sự. Mô tả trường, giá trị mẫu và mục đích kinh doanh giúp giải quyết. Jev có thể chọn trong các trường nguồn thực tế, còn mã kiểm tra kiểu, giá trị bắt buộc và ràng buộc của đích.

Hướng dẫn trích xuất giá trị đã phân tích sẵn liên quan dùng một thiết kế đặc biệt hữu ích: mã tìm các giá trị ứng viên, mô hình chọn một giá trị, rồi mã sao chép nguyên giá trị gốc. Cách này tránh tạo ra địa chỉ hoặc số tiền thay thế.

1. Mã

   tìm ứng viên

   customer_email

   billing_email

   account_owner_email
2. Jev

   chọn một trường

   Mô tả trường

   Giá trị mẫu, mục đích
3. Mã

   sao chép giá trị gốc

   Kiểu, giá trị bắt buộc

   Ràng buộc của đích

Với tích hợp CRM và email, giữ trường nguồn và quyết định ánh xạ cùng nhau. Hiển thị bản xem trước các bản ghi bị ảnh hưởng. Để những ánh xạ chưa chắc chắn ở trạng thái chờ cho đến khi được rà soát.

Ở đây còn có lợi thế kinh tế: ánh xạ lược đồ đã được chấp thuận có thể dùng lại. Khi ý nghĩa của trường không đổi, không cần gọi mô hình cho từng hàng.

Đo bản ghi bị từ chối và ánh xạ sai so với mẫu đã được con người xem xét. Yêu cầu API thành công chứng minh dữ liệu gửi đi được chấp nhận; nó không chứng minh đúng email đã đến đúng liên hệ.

4. Chọn mô hình nhỏ nhất vẫn hoàn thành nhiệm vụ

Định tuyến mô hình hấp dẫn khi ứng dụng gửi mọi việc cho mô hình đắt nhất. Đổi nhãn, đánh giá kết quả tìm kiếm và điều tra kiến trúc khó có yêu cầu khác nhau.

Trước tiên xác định các mô hình đã cấu hình và được phép nhận dữ liệu của nhiệm vụ. Ghi công cụ chúng hỗ trợ và hiệu năng đã quan sát. Sau đó một phán đoán hẹp có thể đề xuất lựa chọn phù hợp trong tập đó. TypeSafe đưa mẫu này vào ví dụ định tuyến mô hình.

Jev Router của OpenRouter cung cấp mẫu này qua API trò chuyện với mã mô hình typesafe/jev-router. Trang liệt kê mô tả việc chọn cả mô hình lẫn mức nỗ lực suy luận khi cuộc hội thoại thay đổi. Trước khi dùng, hãy đánh giá các mô hình đích được phép, phí thực tế, cách xử lý dữ liệu và hành vi khi gọi công cụ. Chúng tôi đã xác minh trang liệt kê, chưa đo hiệu năng bộ định tuyến này.

Chính sách đề xuất của chúng tôi bắt đầu bằng mã thông thường cho quy tắc và dữ kiện chính xác. Dùng mô hình ra quyết định cho câu hỏi ngữ nghĩa có giới hạn, mô hình tạo sinh phù hợp cho viết hoặc triển khai, và chuyển lên mức cao hơn khi bằng chứng cho thấy cần thiết.

Nhiệm vụ cần gì?

1. Quy tắc và dữ kiện chính xác

   Mã thông thường

2. Câu hỏi ngữ nghĩa có giới hạn

   Mô hình ra quyết định

3. Viết hoặc triển khai

   Mô hình tạo sinh phù hợp

4. Bằng chứng cho thấy cần nhiều hơn

   Chuyển lên mức cao hơn

Bản thân bộ định tuyến cũng tốn thời gian và tiền. Với việc lặp lại, rõ ràng, quy tắc cố định có thể tốt hơn. Với việc mơ hồ, hãy so sánh cách định tuyến với mốc dùng một mô hình cố định trên công việc đã hoàn thành.

Theo dõi chi phí cho mỗi kết quả được chấp nhận, số lần thử lại, tỷ lệ chuyển lên mức cao hơn và lỗi phát hiện về sau. Lượt gọi đầu rẻ hơn có thể thành quy trình tốn kém nếu ai đó phải sửa đầu ra.

5. Kiểm tra khẳng định trước khi chúng thành câu trả lời cho khách hàng

Một trích dẫn có thể tồn tại nhưng không hỗ trợ câu bên cạnh. Nguồn có thể mô tả tính năng dự kiến, trong khi câu trả lời bảo tính năng đã có hôm nay.

Hướng dẫn kiểm tra trích dẫn của TypeSafe tách hai bước. So khớp chuỗi thông thường phát hiện phần trích dẫn thiếu. Phán đoán ngữ nghĩa đánh giá liệu ngữ cảnh nguồn có ủng hộ khẳng định không.

Áp dụng cùng thiết kế cho phản hồi hỗ trợ, hướng dẫn tích hợp được tạo tự động hoặc báo cáo hoàn thành do tác nhân đề xuất. Giữ khẳng định, đoạn nguồn và kết luận để có thể rà soát.

Hoàn thành vẫn cần bằng chứng trực tiếp. Kiểm thử xác nhận hành vi đã kiểm thử. Nhật ký triển khai xác nhận việc triển khai. Phán đoán ngữ nghĩa có thể chỉ ra báo cáo không khớp bằng chứng; nó không tạo được bằng chứng bị thiếu.

Trường hợp này hấp dẫn vì có thể đặt trước bước xuất bản đang có. Đo các khẳng định thiếu căn cứ lọt qua, các khẳng định có căn cứ bị chặn không cần thiết và công sức rà soát phát sinh. Bắt đầu với những lỗi rõ ràng mà hệ thống đã mắc.

6. Biến bản ghi lời nói và phản hồi khách hàng thành danh sách ngắn hữu ích

Kho bản ghi lời nói hữu ích khi ai đó tìm được đoạn quan trọng. Bộ lọc “chứa từ tích hợp” yếu nếu mục tiêu là “giải thích vì sao khách hàng bỏ dở thiết lập”.

Một cách là truy xuất các đoạn có khả năng liên quan rồi đánh giá vài thuộc tính cụ thể: đoạn này có mô tả trở ngại khi thiết lập, có ví dụ rõ ràng, hoặc có thể hiểu riêng mà không thiếu bối cảnh không?

Gắn URL nguồn và dấu thời gian vào mọi đoạn được chọn. Dấu thời gian lấy từ bản ghi. Mô hình đánh giá mức liên quan.

Với biên tập viên video, các tín hiệu này tạo danh sách ngắn những clip cần xem. Với nhóm sản phẩm, chúng giúp sắp xếp những phản đối lặp lại. Với người làm tiếp thị, chúng tách bằng chứng từ khách hàng khỏi lời khẳng định chiến dịch không có căn cứ.

Mẫu chấm điểm tổng hợp của TypeSafe giữ các chiều đánh giá tách biệt để mã có thể đổi trọng số. Một clip hợp với hướng dẫn có thể khác clip hợp với bản giới thiệu sản phẩm ngắn. Dùng lại các phán đoán khi bằng chứng và tiêu chí nền không đổi.

JevQL là một bản triển khai cộng đồng liên quan: các điều kiện ngữ nghĩa trên hàng PostgreSQL được đánh giá bên ngoài cơ sở dữ liệu. Tài liệu của nó cho thấy bộ lọc thông thường ảnh hưởng đến chi phí. Giảm số hàng đủ điều kiện trước khi yêu cầu phán đoán ngữ nghĩa.

Đo tỷ lệ được người rà soát chấp nhận và thời gian tiết kiệm khi tìm tư liệu có thể dùng. Điểm sức hút của phần mở đầu không phải dự báo lượt xem.

7. Giao diện chọn thao tác hữu ích tiếp theo

Màn hình cài đặt có thể nhận yêu cầu “Dừng đồng bộ này đến ngày mai”. Tác nhân trình duyệt có thể cần chọn trong số nút điều khiển đang thấy trên trang hiện tại.

Trong thiết kế giao diện được đề xuất, ứng dụng cung cấp các hành động được phép và trạng thái hiện tại. Jev chọn trong số đó. Giao diện hiển thị nút điều khiển phù hợp hoặc đề xuất có thể duyệt lại.

Ship with Jev có bản demo tìm chuyến bay qua trình duyệt của Gregor Zunic. Thời gian chạy và chi phí được báo cáo chỉ thuộc về bản demo đó. Ý tưởng có thể chuyển sang nơi khác là chọn trong các hành động có sẵn ở từng bước; một luồng trình duyệt khác cần được xác minh riêng.

Trạng thái phải còn mới. Nếu tài khoản hoặc trang đang chọn thay đổi trong lúc phán đoán đang chạy, hãy bỏ kết quả cũ. Ràng buộc hành động với tài khoản và trạng thái đã được rà soát.

Cách này cũng khiến danh mục giao diện có kiểu dữ liệu hữu ích. Mô hình chọn một màn hình đã biết cùng dữ liệu giới hạn; mã hiển thị thông thường tạo giao diện. Đo tỷ lệ hoàn thành nhiệm vụ và thao tác nhầm, đặc biệt xem các nút điều khiển còn dễ hiểu không.

Tôi sẽ bắt đầu ở đâu

Chọn quyết định lặp lại đang tạo lãng phí nhìn thấy được. Dùng những thất bại thực tế của nó để tạo bộ đánh giá.

Vấn đề hiện có	Thử nghiệm đầu tiên	Bằng chứng đáng thu thập
Tìm kiếm trả lời sai câu hỏi	Đánh giá danh sách ngắn đã truy xuất	Câu trả lời đúng, từ chối trả lời, độ trễ
Yêu cầu bị chuyển qua nhiều nhóm	Chọn trong các hàng đợi được phép	Độ chính xác định tuyến lần đầu, số lần chuyển
Nhập dữ liệu cần ánh xạ thủ công	Chọn các trường nguồn thật	Lỗi ánh xạ, thời gian rà soát
Mọi việc dùng mô hình lớn nhất	Định tuyến các nhiệm vụ đủ điều kiện	Chi phí mỗi kết quả được chấp nhận
Câu trả lời tạo tự động khẳng định quá mức	Đối chiếu khẳng định với nguồn	Khẳng định thiếu căn cứ lọt qua
Không ai dùng kho bản ghi lời nói	Trả về đoạn kèm dấu thời gian	Tỷ lệ chấp nhận, thời gian tìm bằng chứng
Người dùng không tìm thấy nút điều khiển	Gợi ý hành động có sẵn	Tỷ lệ hoàn thành, lựa chọn sai

Đừng sao chép ngưỡng tin cậy từ bản demo. Tài liệu về độ tin cậy của TypeSafe giải thích rằng độ tin cậy Choice và Score chỉ tóm tắt một phân phối. Nó không chứng minh đầu vào đầy đủ hoặc hành động được chọn đã được cho phép.

Bao gồm trường hợp không ứng viên nào phù hợp. Bao gồm dịch vụ không khả dụng. Bao gồm mọi ngôn ngữ bạn dự định hỗ trợ. Lưu phiên bản mô hình và định nghĩa câu hỏi cùng kết quả để có thể so sánh công bằng khi thay đổi sau này.

Với sản phẩm tích hợp, tôi sẽ bắt đầu từ mức liên quan của tìm kiếm và ánh xạ trường. Cả hai rút ngắn đường tới một lượt đồng bộ hoạt động. Cả hai cho phép nhìn thấy lỗi trước khi nó trở thành vấn đề của khách hàng.

Chọn một câu trả lời sai mà phần mềm của bạn đưa ra hôm nay. Khiến nó đáng tin cậy hơn ở bước đúng tiếp theo.