Hướng dẫn dùng Jev AI để tự động phân loại yêu cầu khách hàng

Phần lớn các mô hình AI hiện nay được thiết kế để trò chuyện, bạn hỏi, mô hình trả lời bằng văn bản. Nhưng có một loại công việc khác hoàn toàn: phần mềm của bạn không cần một câu trả lời dài dòng, nó chỉ cần một quyết định nhanh, có cấu trúc, để tự động đi tiếp bước sau. Đây chính là bài toán mà Jev, mô hình AI đầu tiên của công ty TypeSafe, được sinh ra để giải quyết.

Bài viết này hướng dẫn bạn dùng Jev để xây một hệ thống phân loại yêu cầu gửi đến, từ bước thử nghiệm đơn giản trên trình duyệt cho đến việc nhờ một agent lập trình biến nó thành một ứng dụng nhỏ hoàn chỉnh.

Giới thiệu: Jev AI là gì và khác gì với ChatGPT hay Claude?

TypeSafe ra mắt Jev vào ngày 15/9/2026, gọi đây là mô hình thuộc lớp "System One" (Hệ thống Một), lấy cảm hứng từ khái niệm tư duy nhanh, trực giác trong lý thuyết "System 1" của nhà tâm lý học Daniel Kahneman.

Điểm khác biệt cốt lõi: Jev không tạo ra văn bản. Thay vì trả lời bằng một đoạn hội thoại, bạn đưa cho Jev một khối "trạng thái" (state, có thể là văn bản thường hoặc dữ liệu có cấu trúc như JSON) cùng một vài câu hỏi được định nghĩa sẵn kiểu dữ liệu trả về. Jev xử lý tất cả câu hỏi cùng lúc trong một lượt và trả về kết quả dạng có kiểu (typed), kèm theo xác suất tin cậy cho mỗi câu trả lời.

Ví dụ, thay vì nhờ một AI viết hẳn một email trả lời khách hàng, bạn có thể hỏi Jev: Đây là vấn đề truy cập hay câu hỏi về thanh toán? Mức độ khẩn cấp ra sao? Người gửi có yêu cầu nói chuyện với nhân viên thật không? Phần mềm của bạn sẽ dùng các câu trả lời đó để tự động gợi ý hàng đợi xử lý phù hợp hoặc gắn cờ tin nhắn cần xem xét thêm. Jev chỉ cung cấp phán đoán; phần mềm của bạn quyết định bước tiếp theo.

Cần nhấn mạnh: Jev không phải chatbot và không phải trợ lý lập trình. Nó không viết email, không tạo mã nguồn, và không thay thế mô hình đứng sau các công cụ như Claude Code. Bạn hoàn toàn có thể dùng một agent lập trình (như Claude Code) để xây một ứng dụng gọi đến Jev, nhưng đó là hai công việc tách biệt: agent viết ứng dụng, còn Jev là công cụ ra quyết định bên trong ứng dụng đó.

Theo các nguồn thông tin công bố, tốc độ phản hồi của Jev chỉ khoảng 70-500 mili giây cho mỗi lượt gọi, nhanh hơn đáng kể so với các mô hình ngôn ngữ lớn thông thường vốn có thể mất từ vài giây đến vài chục giây.

Cách làm dưới đây phù hợp với các đội vận hành cần phân loại yêu cầu gửi đến, người sáng lập đang xây công cụ nội bộ nhỏ, và bất kỳ ai muốn thử một mô hình ra quyết định mà chưa cần học sâu về API trước.

Bạn sẽ xây được gì?

Một bộ phân loại yêu cầu, trả lời ba câu hỏi cho mỗi tin nhắn gửi đến:

Đây chính là ba kiểu câu hỏi cơ bản của Jev: Choice chọn một trong các phương án bạn định nghĩa, Score chấm điểm theo các mức bạn mô tả, và Noul trả về xác suất ước tính cho câu trả lời "có". Bản demo trong bài này sẽ không tự gửi tin nhắn, không thay đổi tài khoản, và không xử lý hoàn tiền.

Bạn sẽ phải chuẩn bị những gì?

Bạn cần một tài khoản TypeSafe và truy cập vào TypeSafe Playground chính thức để thử nghiệm câu hỏi và văn bản mẫu trước khi viết bất kỳ dòng mã nào. Ở lần thử đầu tiên, hãy dùng tin nhắn tự đặt ra hoặc đã được ẩn danh, chưa nên đưa thông tin khách hàng thật hay dữ liệu nội bộ nhạy cảm vào cho đến khi đội của bạn đã duyệt công cụ này.

Hướng dẫn từng bước dùng Jev trong Playground

Bước 1: Cung cấp một tin nhắn để Jev đọc

Mở Playground và đăng nhập. Dán một tin nhắn mẫu vào ô trạng thái (state), ví dụ:

"Nhóm chúng tôi không đăng nhập được vào buổi workshop đã đặt trước. Buổi học sắp bắt đầu rồi, và liên kết đặt lại mật khẩu không hoạt động. Xin cho tôi nói chuyện với một nhân viên hỗ trợ."

"Trạng thái" ở đây là khối thông tin mà Jev sẽ đánh giá. Nó có thể là văn bản thuần túy hoặc dữ liệu có cấu trúc như một đối tượng JSON chứa tin nhắn kèm các dữ kiện liên quan. Với lần thử đầu tiên, một tin nhắn ngắn như vậy là đủ.

Lưu ý quan trọng: đừng thêm chỉ dẫn kiểu "hãy viết một câu trả lời". Các bước tiếp theo mới là nơi bạn định nghĩa những quyết định bạn muốn Jev đưa ra.

Bước 2: Yêu cầu Jev chọn một phân loại

Thêm một câu hỏi kiểu Choice, đặt tên là topic (chủ đề), với nội dung hướng dẫn:

"Yêu cầu chính trong tin nhắn này là gì? Chọn 'other' (khác) nếu tin nhắn quá mơ hồ hoặc không khớp với bất kỳ phương án nào."

Định nghĩa các phương án như sau:

Chạy câu hỏi và xem kết quả: phân loại được chọn, xác suất gán cho từng phương án, và giá trị độ tin cậy. Câu hỏi kiểu Choice trả về đầy đủ cả ba thông tin này. Với ví dụ trên, phương án access là kết quả bạn nên kỳ vọng, nhưng đây là mục tiêu để bạn kiểm tra, không phải kết quả được đảm bảo tuyệt đối từ mô hình.

Mẹo: luôn giữ lại phương án other. Nếu không, một tin nhắn mơ hồ vẫn buộc phải bị ép vào một trong các nhóm bạn đã đặt tên, dù không thực sự khớp.

Bước 3: Thêm câu hỏi về mức độ khẩn cấp và yêu cầu gặp người thật

Thêm một câu hỏi kiểu Score, đặt tên urgency (mức khẩn cấp), với hướng dẫn:

"Người gửi thể hiện áp lực thời gian ở mức nào? Hãy đánh giá dựa trên hạn chót được nêu hoặc yêu cầu về tốc độ xử lý, không dựa vào giọng điệu tức giận hay chữ viết hoa."

Định nghĩa các mức theo đúng thứ tự:

• Không có áp lực thời gian, hoặc người gửi nói rõ không cần gấp.
• Yêu cầu phản hồi nhanh, nhưng không nói cần hỗ trợ ngay lập tức.
• Nói rõ cần hỗ trợ ngay lập tức hoặc trước một hạn chót sắp đến.

Jev đánh số các mức này là 0, 1 và 2. Điểm trả về có thể nằm giữa các mức, ví dụ 1.6 sẽ rơi vào khoảng giữa mức thứ hai và thứ ba. Đây không phải thang điểm 10 như cách chấm điểm thông thường.

Tiếp theo, thêm một câu hỏi kiểu Noul, đặt tên human_requested (yêu cầu người thật), với hướng dẫn:

"Người gửi có yêu cầu rõ ràng muốn nói chuyện với một nhân viên hỗ trợ không? Yêu cầu gặp một người hoặc một nhân viên hỗ trợ đều được tính. Chỉ thể hiện sự bực bội thôi thì không được tính."

Câu hỏi kiểu Noul trả về một con số từ 0 đến 1. Gần 1 nghĩa là mô hình nghiêng về câu trả lời "có"; gần 0 nghĩa là nghiêng về "không"; khoảng 0,5 nghĩa là không rõ ràng. Khác với Choice, Noul không có trường độ tin cậy riêng.

Với tin nhắn mẫu ở trên, bạn nên kỳ vọng mức khẩn cấp cao và giá trị Noul gần 1 cho yêu cầu gặp người thật. Hãy ghi lại đúng kết quả Jev thực sự trả về, thay vì giả định trước một con số cụ thể.

Bước 4: Kiểm tra các trường hợp Jev có thể trả lời sai

Thay đổi trạng thái và chạy lại đúng các câu hỏi trên với những tin nhắn mới, ví dụ:

• "Một gói dịch vụ cho cả nhóm chúng tôi giá bao nhiêu? Không cần gấp." → nên là sales , mức khẩn cấp thấp, không yêu cầu gặp người.
• "Tôi không mở được bài giảng đã ghi hình. Có thể chờ đến tuần sau." → nên là access , mức khẩn cấp thấp, không yêu cầu gặp người.
• "Đây không phải điều tôi mong đợi. Bạn giúp được không?" → một phân loại không rõ ràng nên rơi vào other hoặc bị đánh dấu cần xem lại.

Đây đều là dữ liệu kiểm thử và mục tiêu để bạn đối chiếu, không phải kết quả từ một lượt chạy thật đã có sẵn. Sau đó, hãy thử thêm những trường hợp khó hơn: một tin nhắn chứa hai yêu cầu cùng lúc, một tin nhắn giận dữ nhưng không nêu hạn chót, và một tin nhắn cố gắng "mách" cho mô hình biết nên chọn nhãn nào. Lưu lại những câu trả lời sai và xem lại liệu hướng dẫn câu hỏi của bạn đã đủ rõ ràng chưa.

TypeSafe cũng ghi nhận rõ những điểm yếu của mô hình, hướng dẫn mơ hồ hoặc mâu thuẫn, ngữ cảnh gây nhiễu, các phép tính đòi hỏi độ chính xác cao, và văn bản mang tính "tấn công" cố tình đánh lừa mô hình. Vì vậy, hãy giữ câu hỏi hẹp và cụ thể, chỉ gửi thông tin thực sự liên quan, và để các phép tính chính xác cho mã lập trình xử lý thay vì giao cho mô hình.

Mười ví dụ là đủ để có một bước kiểm tra ban đầu hữu ích, nhưng chưa đủ để chứng minh hệ thống đã sẵn sàng phân loại toàn bộ hộp thư thật của bạn. Trước khi tin tưởng đưa vào vận hành, hãy thử nghiệm trên một tập dữ liệu lớn hơn, phản ánh đúng các tin nhắn thực tế bạn nhận được, bao gồm cả những trường hợp khó mà bạn chưa từng dùng khi tinh chỉnh câu hỏi.

Bước 5: Quyết định khi nào cần con người xem lại kết quả

Đừng coi một nhãn được trả về là "giấy phép" để hệ thống tự hành động. Với bản demo này, hãy áp dụng một quy tắc đơn giản: hiển thị gợi ý phân loại, nhưng đánh dấu tin nhắn cần xem lại khi chủ đề là other hoặc độ tin cậy của Choice thấp hơn 0,8. Ngưỡng này chỉ là giả định khởi đầu cho bài tập, chưa phải cấu hình đã được kiểm chứng để đưa vào sản xuất thật.

Độ tin cậy của Choice và Score mô tả mức độ "tập trung" trong phân bố xác suất của mô hình, chứ không đảm bảo rằng hệ thống sẽ đúng 80% số lần trên chính dữ liệu tin nhắn của bạn nếu ngưỡng đặt là 0,8.

Một yêu cầu rõ ràng muốn gặp người thật nên luôn được hiển thị, ngay cả khi chủ đề trông có vẻ rõ ràng. Đừng để độ tin cậy của mô hình ghi đè lên yêu cầu này.

Một kết quả hợp lệ về mặt kỹ thuật vẫn có thể sai về nội dung. Hãy giữ phiên bản đầu tiên ở chế độ chỉ đọc: gợi ý nhãn và mức ưu tiên, sau đó để con người kiểm tra lại trước khi hành động.

Cách biến bản demo thành một ứng dụng nhỏ với agent lập trình

Khi đã tự tin với cách đặt câu hỏi trong Playground, bạn có thể nhờ một agent lập trình (chẳng hạn Claude Code) xây một ứng dụng nội bộ đơn giản gọi đến Jev. TypeSafe cung cấp sẵn một gói tiện ích (skill) hỗ trợ các agent lập trình làm việc với API của Jev. Hãy xem lại nội dung gói này trước khi cài đặt, vì đây là mã bên thứ ba sẽ chạy trong môi trường của bạn.

Khi giao việc cho agent, có vài nguyên tắc bảo mật và vận hành cần luôn đưa vào yêu cầu:

• Lưu khóa API dưới dạng biến môi trường phía máy chủ, tuyệt đối không để lộ trong mã phía trình duyệt, prompt chia sẻ, ảnh chụp màn hình hay hệ thống quản lý mã nguồn.
• Không gọi API cho đến khi người dùng chủ động bấm nút phân tích.
• Không tự động kết nối email, gửi phản hồi, xử lý hoàn tiền hay thay đổi tài khoản.
• Thêm xử lý cho các trường hợp đang tải, lỗi, hết thời gian chờ và giới hạn tần suất gọi.
• Giữ danh sách câu hỏi và ngưỡng xem lại trong một tệp dễ chỉnh sửa.
• Phân biệt rõ ràng giữa dữ liệu kiểm thử giả lập và kết quả gọi thật từ Jev, không bao giờ hiển thị kết quả giả lập như thể đó là kết quả thật.

Cần nhớ: agent lập trình chỉ đảm nhận việc viết ứng dụng, còn Jev là công cụ đánh giá tin nhắn bên trong ứng dụng đó. Đây là hai vai trò tách biệt, không nên nhầm lẫn.

Chi phí sử dụng Jev là bao nhiêu?

Theo thông tin công bố, TypeSafe niêm yết giá cho phiên bản Jev khoảng 0,042 USD cho mỗi triệu token đầu vào, không tính phí cho token đầu ra. Phần token đầu vào bao gồm cả nội dung trạng thái và các câu hỏi bạn gửi kèm.

Để hình dung quy mô: với 10.000 lượt gọi, mỗi lượt trung bình khoảng 1.000 token đầu vào được tính phí, tổng chi phí chỉ vào khoảng 0,42 USD tiền phí mô hình. Đây chỉ là con số ước tính để tham khảo quy mô, không phải chi phí đo được thực tế cho bài hướng dẫn này, và chưa bao gồm chi phí lưu trữ ứng dụng hay các dịch vụ khác đi kèm.

Trước khi chạy một lô xử lý lớn, hãy luôn kiểm tra lại bảng giá hiện hành và bất kỳ khoản tín dụng nào tài khoản của bạn đang có.

Nên nhớ gì khi đưa loại mô hình này vào vận hành thật?

• Đây là công cụ ra quyết định, không phải công cụ trả lời khách hàng. Kết quả từ Jev nên dùng để định tuyến, sắp xếp ưu tiên hoặc gắn cờ, chứ không phải để tự động soạn và gửi phản hồi.
• Độ tin cậy cao không đồng nghĩa với chính xác tuyệt đối trên dữ liệu của bạn. Luôn kiểm thử trên chính tập tin nhắn thực tế trước khi tin tưởng đưa vào quy trình tự động hoàn toàn.
• Giữ một bước con người xem lại , đặc biệt với các trường hợp không rõ ràng hoặc có yêu cầu gặp người thật rõ ràng.
• Đây là mô hình còn rất mới , được công bố công khai lần đầu vào tháng 9/2026. Trước khi áp dụng cho công việc quan trọng, hãy theo dõi thêm phản hồi thực tế từ cộng đồng và tài liệu cập nhật từ chính nhà phát triển.

Kết luận

Jev đại diện cho một hướng đi khác biệt so với xu hướng "mô hình trò chuyện" quen thuộc: thay vì tạo ra văn bản, nó tập trung vào việc đưa ra quyết định có cấu trúc, nhanh và rẻ, để phần mềm của bạn tự động xử lý bước tiếp theo. Cách tiếp cận an toàn nhất khi bắt đầu là giữ hệ thống ở chế độ chỉ gợi ý, luôn có bước con người kiểm tra lại, và kiểm thử kỹ trên chính dữ liệu thực tế của bạn trước khi để bất kỳ quyết định nào được thực thi tự động hoàn toàn.