Jev và mô hình System One: Hiệu chuẩn quan trọng hơn độ chính xác

Tuần trước, TypeSafe AI đã ra mắt Jev, sản phẩm mà họ gọi là "mô hình System One" đầu tiên: một mô hình không trò chuyện, không viết văn và không suy luận từng bước. Nó trả lời các câu hỏi có cấu trúc về một đầu vào, trong một lượt truyền xuôi duy nhất, với xác suất đi kèm cho mỗi câu trả lời.

Phần lớn các bài viết về Jev tập trung vào tốc độ. Nhưng theo tôi, tuyên bố thú vị hơn cả nằm ở khả năng hiệu chuẩn (calibration), bởi đây chính là yếu tố âm thầm giới hạn mọi bộ phân loại mà tôi từng triển khai trong môi trường sản xuất.

Jev thực chất là gì?

Jev được xây dựng quanh ba ý tưởng chính:

• Đầu ra phi tự hồi quy (non-autoregressive): Một LLM thông thường tạo câu trả lời từng token một, mỗi token phụ thuộc vào token trước đó. Jev phát ra toàn bộ câu trả lời có cấu trúc cùng lúc. Đây là nguồn gốc của tốc độ — TypeSafe công bố thời gian phản hồi từ 70–500 ms, nhanh hơn 40–200 lần so với các LLM tiên tiến nhất ở các tác vụ tương đương.

• Câu hỏi có kiểu, không phải prompt: Bạn gửi một trạng thái (văn bản, dữ liệu có cấu trúc hoặc lịch sử tin nhắn) cùng một tập câu hỏi. Mỗi câu hỏi thuộc một trong ba loại — choice (chọn từ một tập hợp, nhận xác suất cho mỗi lựa chọn), score (đánh giá theo các mức có thứ tự, nhận điểm liên tục và phân phối), hoặc noul (câu hỏi có/không, trả về xác suất câu đó đúng). Mọi câu hỏi trong một yêu cầu được đánh giá song song, nên thêm câu hỏi gần như không làm tăng độ trễ.

• Huấn luyện vì hiệu chuẩn: Mô hình được huấn luyện bằng phương pháp mà TypeSafe gọi là học tăng cường cho quyết định được hiệu chuẩn (Reinforcement Learning for Calibrated Decisions — RLCD). Mục tiêu được tuyên bố là "xác suất trung thực về mặt nhận thức", thay vì các mục tiêu dựa trên sở thích con người hay phần thưởng có thể kiểm chứng mà các mô hình trò chuyện thường được tinh chỉnh.

Các giới hạn cũng quan trọng không kém các tính năng. Jev không thể tạo văn bản tự do. Câu hỏi dạng lựa chọn hỗ trợ tối đa 255 tùy chọn. Chưa có đầu vào hình ảnh. Giá hiện tại là 0,042 USD cho mỗi triệu token đầu vào, token đầu ra miễn phí, và truy cập qua danh sách chờ.

Vậy nên Jev không phải một GPT thu nhỏ. Nó gần hơn với một bộ phân loại dạng bảng rất nhanh và rất tổng quát, đọc đầu vào phi cấu trúc và trả về một quyết định có kiểu kèm độ tin cậy mà bạn được kỳ vọng có thể tin tưởng.

Vì sao hiệu chuẩn, không phải độ chính xác, mới là nút thắt thật sự

Trong nghiên cứu của chính mình, chúng tôi dự đoán liệu một pull request có được hợp nhất hay không, chỉ dùng các tín hiệu có sẵn tại thời điểm gửi. Random Forest đạt F1 là 0,958. Đường cơ sở đa số (dự đoán "hợp nhất" cho mọi trường hợp) đạt 0,957. Chỉ số thực sự phân biệt được một mô hình hữu ích với một mô hình vô dụng là ROC-AUC: 0,676 cho Random Forest so với 0,500 cho đường cơ sở.

Đó không phải là đặc thù của một bộ dữ liệu. Đó là hình dạng bình thường của một bộ phân loại trong sản xuất:

• Độ chính xác bão hòa sớm: Với các bài toán mất cân bằng, phần lớn độ chính xác có sẵn gần như miễn phí. Phần khó nằm ở xếp hạng và độ tin cậy.

• Logic phía sau cần xác suất, không cần nhãn: Câu lệnh "chuyển đơn hàng này sang kiểm tra thủ công nếu mô hình chưa chắc chắn 80%" chỉ hoạt động nếu con số 80% thực sự có nghĩa là 80%. Nếu mô hình nói 0,95 cho những trường hợp đúng chỉ 70% số lần, thì mọi ngưỡng bạn đặt ra đều là một lời nói dối.

• Hiệu chuẩn sai không hiện ra trong các chỉ số thông thường: F1, độ chính xác, thậm chí cả AUC đều là các chỉ số về ngưỡng hoặc thứ hạng. Một mô hình có thể có AUC tốt nhưng hiệu chuẩn tệ, và bạn sẽ không biết cho đến khi quy tắc nghiệp vụ xây trên nó bắt đầu sai.

Các giải pháp tiêu chuẩn hiện nay đều là hậu kiểm: Platt scaling, hồi quy isotonic, temperature scaling. Chúng hiệu quả, nhưng là một thành phần được khớp thêm vào và sẽ trôi dạt khi dữ liệu thay đổi. Điều Jev tuyên bố, nếu tôi hiểu đúng, là các xác suất đầu ra đã trung thực ngay từ mô hình, bởi vì tính trung thực chính là mục tiêu huấn luyện. Nếu điều đó đúng trên các tác vụ ngoài bộ đánh giá của chính TypeSafe, nó loại bỏ cả một lớp keo dính khỏi hệ thống ML sản xuất.

Mô hình System One phù hợp ở đâu trong hệ thống thực tế?

Trong lĩnh vực phân phối bán buôn, gần như không có tác vụ nào là trò chuyện. Phần lớn là những quyết định nhỏ, lặp đi lặp lại, nằm giữa hai hệ thống:

• Đơn hàng đến có phải là ngoại lệ cần con người xử lý? → Hiện dùng quy tắc cộng bộ phân loại nhỏ. Quy tắc bị mục nát, huấn luyện lại là cả một dự án. Jev phù hợp: một câu hỏi noul với ngưỡng.

• SKU mới thuộc danh mục sản phẩm quy định nào? → Hiện dùng quy tắc từ khóa, dọn dẹp thủ công. Mô tả nhà cung cấp là văn bản tự do lộn xộn. Jev phù hợp nếu số danh mục nằm trong 255 lựa chọn.

• Tin nhắn hỗ trợ khách hàng này gấp đến mức nào? → Hiện không làm gì, hoặc gọi LLM mất vài giây. Độ trễ và chi phí khiến khó chạy trên mọi tin nhắn. Jev phù hợp: một câu hỏi score theo các mức có thứ tự.

• Tuyến giao hàng nào nên nhận đơn trễ này? → Hiện dùng bộ giải ràng buộc. Đây không phải bài toán phân loại. Jev không phù hợp.

• Viết ghi chú giải thích sản phẩm thay thế cho khách → Hiện dùng LLM. Cần văn bản được tạo. Jev không phù hợp.

Mô hình rất rõ ràng. Ở đâu có LLM đang làm công việc thực chất là phân loại khoác áo trò chuyện, mô hình System One là lựa chọn thay thế hợp lý với độ trễ và chi phí thấp hơn hai bậc độ lớn. Ở đâu có quy tắc viết tay liên tục hỏng vì đầu vào là văn bản tự do, nó cũng là lựa chọn thay thế hợp lý. Ở đâu công việc là tạo sinh hoặc tối ưu hóa, nó là công cụ sai — và chính TypeSafe cũng thừa nhận điều đó.

Những tuyên bố tôi chưa sẵn sàng chấp nhận

Một vài điểm trong tài liệu ra mắt cần được đọc với thái độ hoài nghi.

"Không ảo giác." Điều TypeSafe có thể đảm bảo là kiểu đầu ra luôn hợp lệ: bạn yêu cầu một trong năm danh mục, bạn nhận được một trong năm danh mục, với xác suất cộng lại bằng một. Điều đó là thật và hữu ích. Nhưng nó không nói gì về việc danh mục được chọn có đúng hay không. Một câu trả lời sai đầy tự tin trong một schema hợp lệ vẫn là câu trả lời sai. Cách diễn đạt trung thực là "không có lỗi schema", còn hiệu chuẩn mới là thứ phải gánh phần còn lại.

Hiệu chuẩn trên phân phối của ai? Một mô hình có thể được hiệu chuẩn tốt trên phân phối huấn luyện và đánh giá của nhà phát triển, nhưng trôi dạt nghiêm trọng trên dữ liệu của bạn. Hiệu chuẩn là thuộc tính của cả mô hình lẫn bộ dữ liệu. Con số duy nhất tôi tin là con số đo trên dữ liệu của chính mình.

Đường cơ sở so sánh. Tuyên bố "nhanh hơn LLM 200 lần khi phân loại" là đúng, nhưng cũng hơi không công bằng, vì đường cơ sở đúng cho nhiều tác vụ không phải là LLM. Nó là một cây tăng cường gradient trên các đặc trưng được thiết kế — cũng dưới một mili giây và miễn phí. So sánh thú vị là ba chiều: mô hình dạng bảng cổ điển, LLM làm bộ phân loại, và Jev, trên cùng một tác vụ, về độ chính xác, xếp hạng, hiệu chuẩn, độ trễ và chi phí.

Thử nghiệm tôi muốn thực hiện ở Việt Nam

Với các đội ngũ kỹ thuật tại Việt Nam đang cân nhắc tích hợp Jev, tôi đề xuất cách tiếp cận sau:

• Kiểm kê các lệnh gọi LLM hiện có: Đánh dấu mỗi lệnh gọi là tạo sinh hay quyết định. Những lệnh gọi thuộc loại quyết định là ứng viên cho Jev. Theo kinh nghiệm của tôi, đó là phần lớn trong số đó.

• Đo hiệu chuẩn trên những gì bạn đang có: Tính điểm Brier và sai số hiệu chuẩn kỳ vọng (ECE) cho các bộ phân loại hiện tại. Nếu chúng tệ, bạn có một vấn đề mà Jev có thể giải quyết. Nếu chúng ổn, bạn chủ yếu đối mặt với câu hỏi về độ trễ và chi phí.

• Đừng bỏ qua đường cơ sở cổ điển: Một cây tăng cường gradient trên các đặc trưng tốt là mức chuẩn. Bất kỳ mô hình mới nào cũng phải vượt qua nó trên dữ liệu của bạn, với quy tắc chống rò rỉ dữ liệu của bạn, nếu không thì không phải là nâng cấp.

• Coi "đã hiệu chuẩn" như một giả thuyết: Kiểm chứng nó trên phân phối của bạn trước khi một quy tắc nghiệp vụ phụ thuộc vào nó.

Ý tưởng đằng sau các mô hình System One là hợp lý: phần lớn các quyết định mà phần mềm cần từ ML đều nhỏ, có cấu trúc và nhạy cảm với độ trễ, và một mô hình trò chuyện là công cụ kỳ lạ cho chúng. Liệu Jev có thực hiện được lời hứa về hiệu chuẩn hay không là một câu hỏi thực nghiệm. Tôi đã có bộ dữ liệu để trả lời, và tôi có ý định làm điều đó.