Jev là gì, và Product Manager cần quan tâm điều gì?

Jev là một model AI dùng để đưa ra quyết định có cấu trúc cho phần mềm. “Có cấu trúc” nghĩa là team định nghĩa sẵn những câu trả lời hợp lệ, còn Jev chọn hoặc chấm điểm trong phạm vi đó.

Bạn đưa cho Jev dữ liệu đang có và một số câu hỏi. Jev trả về lựa chọn, điểm số hoặc xác suất để code xử lý tiếp. Nó được dùng ở những đoạn phần mềm cần quyết định đường đi tiếp theo, thay vì cần một đoạn văn cho user đọc.

Ví dụ, Cloudflare đưa cho Jev câu ticket này:

Help! My payouts have been failing for 3 days.

Sau đó họ hỏi ba việc:

• Ticket có thể hiện sự khẩn cấp không?
• Billing, Technical hay Sales nên nhận ticket?
• Khách hàng đang bình tĩnh, bực hay rất tức giận?

Jev chọn Billing, đánh giá ticket khá khẩn cấp và cho rằng khách đang bực. Kết quả được trả về dưới dạng số và lựa chọn.

1. Khách gửi ticket.
2. Jev đọc và phân loại: department là billing, urgency là 0.95.
3. Code chuyển ticket vào hàng đợi Billing.

Đến đây Jev đã làm xong việc. Khách vẫn chưa biết vì sao payout bị lỗi; đội Billing hoặc một hệ thống khác sẽ phải xử lý phần đó.

Nguồn: Cloudflare AI - Jev model documentation

Jev nhận gì và trả gì?

Một request gửi cho Jev có hai phần chính.

Phần đầu là dữ liệu đầu vào, TypeSafe gọi là state. Nó có thể là một câu ticket, lịch sử trò chuyện, thông tin giao dịch hoặc một object chứa nhiều loại dữ liệu.

Phần thứ hai là các câu hỏi. Jev hỗ trợ ba kiểu:

• Choice: chọn một phương án trong danh sách. Ví dụ: Billing, Technical hay Sales?
• Noul: đánh giá một nhận định đúng hay sai. Ví dụ: Ticket này có thể hiện sự khẩn cấp không?
• Score: chấm theo một thang đã định nghĩa. Ví dụ: Khách đang bình tĩnh, bực hay rất tức giận?

Với Choice, Jev trả về phương án được chọn và xác suất của từng phương án. Trong demo Cloudflare, Billing nhận 0.87, Technical nhận 0.13, Sales nhận 0.

Noul trả về xác suất một nhận định là đúng. Kết quả urgency 0.95 có nghĩa Jev nghiêng mạnh về việc câu ticket đang thể hiện sự khẩn cấp.

Score dùng cho một thang có thứ tự. Cloudflare đặt Calm ở mức 0, Frustrated ở mức 1 và Very angry ở mức 2. Jev trả điểm 1.04, vì phần lớn xác suất nằm ở Frustrated và một phần nhỏ nằm ở Very angry.

Các câu hỏi trong cùng request được Jev đánh giá độc lập trên cùng dữ liệu đầu vào. Kết quả “Billing” không tự trở thành dữ liệu cho câu hỏi về cảm xúc. Nếu một bước sau cần dùng kết quả của bước trước, code phải nối hai bước lại.

Nguồn: TypeSafe AI - Introduction, TypeSafe AI - Primitives

Jev khác một LLM ở đâu?

LLM có structured output cũng làm được nhiều việc tương tự. Team hoàn toàn có thể yêu cầu một LLM chọn department rồi trả JSON đúng schema.

TypeSafe xây Jev riêng cho những quyết định kiểu chọn, chấm điểm và đánh giá đúng sai. Model bỏ khả năng sinh văn bản tự do, trả các xác suất song song và giữ output trong tập phương án đã được khai báo.

Bởi vậy, Jev hợp với những đoạn code cần một kết quả để rẽ nhánh:

• Chuyển ticket vào đúng hàng đợi.
• Chọn tool cho AI agent.
• Đánh giá một giao dịch có cần review.
• Chấm output theo rubric.
• Phân loại tài liệu trước khi đưa vào một flow khác.

Jev đang ở giai đoạn early access. Những tuyên bố về tốc độ, chi phí và chất lượng hiện chủ yếu đến từ TypeSafe, nên team vẫn phải thử trên dữ liệu của mình trước khi dùng trong production.

Nguồn: TypeSafe AI - Introducing System One Models & Jev

Jev thay đổi phần việc của PM như thế nào?

Jev chỉ có thể chọn trong những phương án team đưa cho nó. Trước khi gọi model, team phải viết rõ bốn thứ:

1. Phần mềm đang cần quyết định điều gì?
2. Model được đọc những dữ liệu nào?
3. Các kết quả hợp lệ là gì?
4. Mỗi kết quả sẽ khiến phần mềm làm gì tiếp theo?

Với bài toán chuyển ticket, PM có thể viết một danh sách như sau:

• Quyết định: Ticket thuộc department nào?
• Dữ liệu model được đọc: Nội dung ticket.
• Kết quả hợp lệ: billing, technical, sales, other.
• Hành động: Chuyển ticket vào hàng đợi tương ứng.
• Khi model không chắc: Đưa ticket cho người phân loại.
• Cách đo: Tỷ lệ đến đúng department ngay lần đầu; thời gian đến đúng owner.

Mình gọi danh sách này là decision spec để tiện nhắc đến trong bài. Đây không phải tên do TypeSafe đặt.

Danh sách này giúp engineer biết output được nối vào đâu, đội support biết mình sẽ nhận loại ticket nào, còn PM có metric để kiểm tra sau khi release.

Nó cũng bắt team xử lý một việc rất thực tế: danh sách department có bao phủ hết ticket không?

Demo đầu tiên của Cloudflare chỉ có Billing, Technical và Sales. Một ticket pháp lý vẫn bị Jev phân xác suất vào ba lựa chọn đó. Trong một ví dụ routing khác, tài liệu thêm other cho những nội dung không thuộc các department đã biết.

Thêm other chưa hoàn thành flow. Ticket ấy phải đi đến một hàng chờ có người sở hữu và có thời gian xử lý rõ ràng. Đội support cần tham gia viết danh sách lựa chọn, vì họ biết loại ticket nào thường bị chuyển qua lại và trường hợp nào chưa có owner.

Jev đọc câu chữ, code kiểm tra sự việc

Câu ticket nói payout đã lỗi ba ngày. Jev có thể dựa vào cụm này để đánh giá lời nhắn khá khẩn cấp.

Nó chưa biết ticket vừa được tạo hay đã nằm trong hàng chờ ba ngày. Nó cũng chưa biết payout có thực sự thất bại, bao nhiêu giao dịch bị ảnh hưởng và số tiền đang bị kẹt là bao nhiêu. Những dữ liệu này phải được lấy từ hệ thống.

Vì thế, requirement “tự động ưu tiên ticket” có thể chia thành ba phần:

• Jev đọc nội dung để đánh giá loại vấn đề và cách khách đang diễn đạt.
• Code lấy thời gian tạo ticket, số giao dịch lỗi và trạng thái tài khoản.
• Policy của công ty quyết định trường hợp nào được tăng priority hoặc chuyển cho người kiểm tra.

TypeSafe cũng khuyên chia một phán đoán lớn thành nhiều câu hỏi hẹp rồi ghép kết quả bằng code. Khi policy đổi, team sửa rule hoặc trọng số thay vì cố viết lại một prompt bao trọn mọi trường hợp.

Cách chia này còn giúp team tìm lỗi. Ticket bị xử lý sai có thể do model hiểu nhầm câu khách viết, dữ liệu giao dịch bị thiếu hoặc policy ưu tiên chưa hợp lý. Một câu hỏi chung chung kiểu “Ticket này có nên được ưu tiên không?” chỉ trả về kết quả cuối, team sẽ khó biết phần nào cần sửa.

Confidence không phải tỷ lệ đúng

Trong response Cloudflare, Billing có xác suất 0.87, còn confidence của câu trả lời là 0.8.

0.87 là phần xác suất Jev phân cho Billing trong ba lựa chọn. Confidence được tính từ cả phân bố xác suất; các xác suất càng tập trung vào một lựa chọn thì confidence càng cao.

Confidence: 0.8 không có nghĩa model sẽ phân loại đúng 80% ticket. Muốn biết tỷ lệ đúng, team phải chạy Jev trên một tập ticket đã có đáp án rồi so sánh.

Nguồn: TypeSafe AI - Confidence

Kết quả thử nghiệm sẽ giúp PM chọn ngưỡng để tự động chuyển ticket. Những ca model còn phân vân được đưa cho người phân loại. Hàng chờ thủ công này cũng cần owner, SLA và metric; nếu không, ticket chỉ bị chuyển từ chỗ model chưa chắc sang một chỗ khác để nằm chờ.

Sau khi release, mình sẽ theo dõi bốn chỉ số:

• Tỷ lệ ticket đến đúng department ngay lần đầu.
• Tỷ lệ ticket bị chuyển lại.
• Thời gian đến khi đúng owner bắt đầu xử lý.
• Tỷ lệ và thời gian tồn của hàng chờ thủ công.

Học được gì từ Jev

Jev có thể trở thành một model phổ biến, cũng có thể không. Nhưng cách nó buộc team mô tả một quyết định thì dùng được với cả LLM structured output và các model phân loại khác.

Khi backlog có item “dùng AI để tự động hóa X”, PM có thể viết sáu dòng trong decision spec: quyết định, dữ liệu đầu vào, kết quả hợp lệ, hành động tương ứng, đường lui và metric.

Chúc các bạn thành công.