Jev hữu ích, nhưng đừng vội tin vào xác suất "đã hiệu chỉnh"

Jev — mô hình "System One" đầu tiên của TypeSafe — đang gây chú ý trong giới phát triển AI nhờ khả năng nhận đầu vào phi cấu trúc và trả về các quyết định có kiểu dữ liệu, kèm theo xác suất cho từng lựa chọn. TypeSafe quảng cáo rằng mọi câu trả lời đều đi kèm xác suất đã hiệu chỉnh và điểm tin cậy.

Nhưng theo Alex Molas, tuyên bố đó không thể đúng một cách tổng quát. Jev vẫn rất hữu ích, chỉ có điều ta nên coi đầu ra của nó là điểm số (score) thay vì xác suất thật.

Jev là gì và vì sao nó đáng dùng?

Nếu bạn chưa theo dõi, Jev hoạt động khác biệt so với các mô hình ngôn ngữ lớn thông thường: thay vì sinh văn bản, nó nhận đầu vào phi cấu trúc và trả về một quyết định có kiểu dữ liệu nằm trong tập đầu ra bạn định nghĩa trước, mỗi quyết định kèm một xác suất.

Điểm mạnh dễ thấy nhất: bạn có thể dùng nó cho bất kỳ bài toán phân loại nào mà không cần thu thập dữ liệu huấn luyện trước.

Nhiều người trên Twitter cho rằng "đây chẳng qua là một BERT được tinh chỉnh". Nhưng tinh chỉnh BERT đòi hỏi dữ liệu — nếu bạn không có dữ liệu, Jev là lựa chọn thay thế tuyệt vời. Hơn nữa, Jev là một bộ phân loại phổ quát, trong khi BERT tinh chỉnh chỉ dùng được cho đúng tác vụ nó được huấn luyện.

Tuy nhiên, chính khả năng "dùng được mà không cần dữ liệu" lại là lý do khiến xác suất của nó không thể hiệu chỉnh cho trường hợp của bạn.

Hiệu chỉnh là thuộc tính của cả mô hình lẫn dữ liệu

TypeSafe nói Jev được huấn luyện bằng RLCD (học tăng cường cho các quyết định đã hiệu chỉnh), và xác suất nó tạo ra đã được hiệu chỉnh. Molas không đồng tình.

Một mô hình được gọi là hiệu chỉnh khi với mọi xác suất dự đoán p, xác suất thật của lớp dương tính ứng với dự đoán đó cũng bằng p.

Nói cách khác, nếu bạn gom tất cả các trường hợp mô hình dự đoán 70%, thì khoảng 70% trong số đó phải thực sự đúng. Ví dụ: trong số các email mà Jev gán spam_probability = 0.7, bạn kỳ vọng khoảng 70% thực sự là thư rác.

Vấn đề mấu chốt nằm ở chỗ: hiệu chỉnh không chỉ là thuộc tính của mô hình, mà còn của phân phối dữ liệu. Cùng một mô hình có thể hiệu chỉnh trên bộ dữ liệu này nhưng lại lệch trên bộ dữ liệu khác.

Hai công ty có thể định nghĩa "thư rác" giống hệt nhau nhưng phân phối dữ liệu hoàn toàn khác. Trong khi đó, với cùng một đầu vào và cùng một prompt, Jev trả về cùng một xác suất cho cả hai — bất kể nền tảng dữ liệu khác nhau ra sao. Kết quả là mô hình có thể hiệu chỉnh với công ty này nhưng sai lệch với công ty kia.

Ngay cả khi RLCD huấn luyện thành công để Jev hiệu chỉnh trên phân phối huấn luyện/đánh giá của TypeSafe, xác suất của nó vẫn có thể mất tính hiệu chỉnh trên phân phối thực tế của bạn.

Bằng chứng cho thấy vấn đề còn tệ hơn dịch chuyển phân phối

Molas dẫn một số tweet cho thấy Jev nói rằng một đồng xu cân đối có xác suất ra mặt ngửa là 0.92. Điều này tệ hơn hẳn so với việc chỉ lệch do dịch chuyển phân phối — xác suất đúng đã nằm ngay trong prompt mà mô hình vẫn không báo cáo đúng.

Một thử nghiệm gần đây cũng cho thấy Noul hiệu chỉnh tốt hơn nhiều so với Choice trên cùng một bài toán. Vậy nếu xác suất của Jev mang ngữ nghĩa khác nhau tùy theo primitive bạn dùng, thì "xác suất đã hiệu chỉnh" thực sự nghĩa là gì?

Vậy nên làm gì?

Tin tốt là việc hiệu chỉnh lại không hề đắt. Nếu bạn cần xác suất thực sự đáng tin, bạn vẫn phải hiệu chỉnh lại đầu ra của Jev trên dữ liệu của chính mình. Chỉ vài trăm mẫu đã gán nhãn từ dữ liệu thực tế có thể đủ để áp dụng Platt scaling lên trên điểm số của Jev.

• Coi đầu ra của Jev là điểm số tốt (xếp hạng ví dụ tốt) hơn là xác suất tốt.
• Nếu hệ thống của bạn phụ thuộc vào con số cụ thể — như ngưỡng cắt, chi phí kỳ vọng, hay kết hợp với mô hình khác — hãy đo hiệu chỉnh trên dữ liệu của bạn trước khi tin dùng.

Với các đội ngũ ở Việt Nam đang thử nghiệm Jev cho các bài toán phân loại nội bộ như phân loại ticket hỗ trợ, gắn nhãn văn bản hay lọc nội dung, lời khuyên này đặc biệt đáng lưu tâm: dữ liệu tiếng Việt và đặc thù nghiệp vụ tại mỗi công ty rất khác so với phân phối huấn luyện gốc, nên đừng mặc định rằng con số Jev trả về đã đúng ngay từ đầu.