Bộ phát hiện đọc xác suất thay vì phán quyết: Jev qua 44 benchmark

Một bộ phát hiện lỗi căn chỉnh trả lời nhiều câu hỏi có kiểu trong một lần gọi với xác suất đã hiệu chuẩn, xếp hạng lỗi tốt và rẻ hơn 63 lần so với các bộ chấm LLM-judge. Nhưng các xác suất đó không chuyển được thành ngưỡng, và nhãn cùng tham chiếu của nó quan trọng hơn nhiều so với cách diễn đạt câu hỏi.

Cấu trúc chi phí của việc theo dõi mọi tin nhắn #

Các mô hình đã triển khai vẫn chiều theo niềm tin sai của người dùng (Sharma et al., 2024). Câu này khiêm tốn, nhưng nó đóng khung toàn bộ vấn đề. Nếu kiểu xu nịnh đó còn tồn tại trong các hệ thống đã triển khai, thì phải có ai đó theo dõi nó, và việc theo dõi phải diễn ra cùng nhịp với chính cuộc hội thoại.

Đó là lúc bài toán kinh tế lên tiếng. Một bộ phát hiện cần chính xác và, vì nó chạy trên mọi tin nhắn, phải rẻ. Mỗi đặc tính riêng lẻ đều dễ đạt: một bộ phát hiện cẩu thả thì rẻ, còn một bộ cẩn thận nhưng quá đắt để chạy trên mọi tin nhắn thì chỉ theo dõi được một mẫu lưu lượng. Câu hỏi kỹ thuật thú vị là bộ phát hiện có hình dạng nào thì đạt được cả hai.

Câu trả lời hiện nay, theo bài báo làm nền cho bài viết này, có một khiếm khuyết về cấu trúc. Hầu hết các bộ phát hiện lỗi căn chỉnh là những giám khảo sinh văn bản tiêu tốn một lượt giải mã cho mỗi tiêu chí. Nói thẳng ra, các bộ phát hiện hiện nay trả giá một lượt giải mã cho mỗi tiêu chí chúng kiểm tra. Một bộ giám sát muốn kiểm tra mười loại lỗi khác nhau phải trả cho mười lượt, và hóa đơn tăng tuyến tính theo số thứ bạn quan tâm.

Có một cách khắc phục một phần, và cần nói chính xác về giới hạn của nó. Các bộ phân loại đọc xác suất token, chẳng hạn Llama Guard, vẫn chấm một nhãn cố định cho mỗi lần gọi. Đọc xác suất token cho ra một điểm số, nhưng mỗi lần gọi vẫn chỉ chấm một nhãn hoặc tiêu chí, vì xác suất được đọc từ một token phán quyết duy nhất. Lượt giải mã biến mất, nhưng cấu trúc một câu hỏi cho mỗi lần gọi vẫn còn. Bạn làm cho mỗi lần gọi rẻ hơn mà không thay đổi số lần gọi cần thiết.

Vậy luận điểm về cấu trúc là thế này: giám khảo sinh văn bản đắt tính theo mỗi tiêu chí, còn bộ phân loại đọc xác suất rẻ hơn tính theo mỗi tiêu chí nhưng mỗi bộ vẫn gắn với một tiêu chí. Không bên nào cho phép bạn đặt nhiều câu hỏi về cùng một đầu vào cùng lúc.

Khía cạnh kiến trúc	Giám khảo LLM sinh văn bản (vd. GPT-4 làm giám khảo)	Bộ phân loại một token (vd. Llama Guard)	Bộ phát hiện RLCD đa truy vấn (Jev)
Cơ chế chấm điểm	Một lượt giải mã tự hồi quy đầy đủ cho mỗi tiêu chí	Xác suất softmax trên một token đầu ra	Tensor xác suất đã hiệu chuẩn nhiều đầu $P(\text{yes})$
Số câu hỏi mỗi lần gọi	1 prompt đánh giá cho mỗi lần gọi mô hình	1 nhãn phân loại cho mỗi lần gọi mô hình	Nhiều câu hỏi nhị phân/phân loại/thứ bậc trong 1 lần gọi
Chi phí suy luận	Cao ($10–$50 cho 1.000 tương tác)	Trung bình ($0,50–$2,00 cho 1.000 tương tác)	Thấp hơn 63 lần ($0,30 cho 19 benchmark đầy đủ)
Hiệu năng AUROC	Phụ thuộc benchmark; dễ bị trôi giám khảo	Cao ở các hạng mục an toàn cụ thể đã huấn luyện	AUROC trung vị 0,886 zero-shot trên 44 bộ
Chất lượng hiệu chuẩn	Giải thích theo kinh nghiệm, không có xác suất chính thức	Logit thô, không hiệu chuẩn hậu kỳ	Xác suất đã hiệu chuẩn; ECE trung vị 0,168 (cần khoảng 10 mục có nhãn)

Jev khác biệt ở đâu #

Jev được huấn luyện bằng học tăng cường cho quyết định đã hiệu chuẩn (RLCD). Nó trả lời nhiều câu hỏi có kiểu về một đầu vào với xác suất đã hiệu chuẩn trong một lần gọi. Cơ chế này cần được trình bày cẩn thận, vì phần còn lại của bài viết dựa vào nó.

Một mô hình RLCD trả về một quyết định kèm xác suất đã hiệu chuẩn cho mỗi câu hỏi có kiểu thay vì sinh văn bản. Không có bước sinh văn bản nào trong đó một phán quyết được viết ra rồi mới được phân tích. Jev trả lời nhiều câu hỏi nhị phân, phân loại và thứ bậc về một đầu vào, mà bài báo gọi là trạng thái, trong một lần gọi. Trạng thái là đầu vào; câu hỏi là những gì bạn hỏi về nó.

Đó là một đường cong chi phí khác với cả hai cách tiếp cận ở trên. Nếu các câu hỏi dùng chung một lần gọi, thêm một câu hỏi không làm tăng một lượt giải mã. Lợi ích cho một bộ giám sát quan tâm đến nhiều loại lỗi cùng lúc là rõ ràng, dù các phép đo của bài báo liên quan đến những gì một câu hỏi chung đạt được, và tôi sẽ bám vào những gì đã được đo.

Tuy vậy vẫn có một khoảng trống. Việc Jev có phát hiện được lỗi căn chỉnh hay không chưa từng được đo. Một mô hình trả lời câu hỏi có kiểu bằng xác suất đã hiệu chuẩn nghe có vẻ hợp với công việc này, và nghe có vẻ hợp thì rẻ. Bài báo đặt mục tiêu cung cấp phép đo còn thiếu.

Vì sao lỗi căn chỉnh khó hơn vẻ ngoài #

Trước phép đo, có một điều phức tạp. Nhiều lỗi trong số này mang tính quan hệ, được định nghĩa dựa trên một tham chiếu mà riêng câu trả lời không tiết lộ. Xu nịnh minh họa tốt ý tưởng chung: một câu trả lời có chiều theo niềm tin sai của người dùng hay không phụ thuộc vào niềm tin đó là gì và nó có sai hay không, và không dữ kiện nào trong hai điều ấy hiện ra trong văn bản câu trả lời khi đứng một mình.

Điều này có hệ quả cho thiết kế bộ phát hiện, được bài báo nêu với sự dè dặt thích đáng. Một bộ phát hiện chỉ thấy câu trả lời có thể thiếu tham chiếu định nghĩa lỗi. Chữ “có thể” rất quan trọng; luận điểm không phải là mọi lỗi đều cần tham chiếu, mà chỉ là một số lỗi cần và một góc nhìn chỉ dựa vào câu trả lời có thể bỏ sót nó.

Nó cũng làm việc chẩn đoán phức tạp hơn. Nếu lỗi mang tính quan hệ, một kết quả phát hiện kém có thể đến từ câu hỏi hoặc từ một trạng thái thiếu tham chiếu. Có hai thứ có thể sai, và một điểm số thấp không cho biết là thứ nào. Có thể câu hỏi được diễn đạt kém. Có thể câu hỏi ổn và đầu vào đơn giản là chưa bao giờ chứa những gì cần để trả lời. Một benchmark muốn nói điều gì hữu ích về một bộ phát hiện phải được xây dựng sao cho tách được hai nguyên nhân đó.

Về phần mình, nhà phát triển liệt kê ý nghĩa gián tiếp và nội dung đối kháng trong số những điểm yếu đã biết của Jev. Điều này đáng ghi nhớ khi đọc kết quả sau đây, vì một số loại lỗi dựa đúng vào những đặc tính ấy.

Xem phát hiện như phân loại #

Thiết lập hình thức của bài báo khá đơn giản. Nó coi việc phát hiện lỗi căn chỉnh là bài toán phân loại nhị phân trên các tương tác của một mô hình mục tiêu. Một bộ phát hiện gán điểm s(x) ∈ [0, 1] và gắn cờ x khi s(x) ≥ t. Điều đó có nghĩa là nó phải vừa xếp các lỗi trên các trường hợp không lỗi, vừa tách chúng tại một ngưỡng t.

Hai nhiệm vụ đó tách rời được, và kết quả của bài báo chia đôi đúng theo đường nối ấy. Xếp hạng là thứ AUROC đo. Tách tại một ngưỡng phụ thuộc vào hiệu chuẩn, và bài viết sẽ quay lại điểm này vì đó là chỗ Jev chưa đạt. Một bộ phát hiện có thể xếp hạng xuất sắc mà vẫn vô dụng ở t = 0,5 nếu các xác suất của nó nằm sai chỗ.

RLCDAlignBench #

Benchmark này có tên RLCDAlignBench. Nó bao quát mười loại lỗi trên 44 benchmark và 7.193 trường hợp phát hiện. Các trường hợp đến từ năm mô hình mục tiêu mở cỡ 2–7B, mỗi trường hợp được gán nhãn bởi bộ chấm tham chiếu của benchmark tương ứng. Như vậy các tương tác được đánh giá đến từ những mô hình mở nhỏ, và sự thật nền cho mỗi tương tác là điều mà chính bộ chấm của benchmark gốc nói.

Không phải benchmark nào cũng mang cùng một loại nhãn. Nhãn do con người gán trên StrongREJECT và HarmBench, cùng nhãn của giám khảo thứ hai trên AbstentionBench và InstrumentalEval, được dùng để so sánh Jev với một giám khảo. Điều đó cho bài báo hai kiểu kiểm tra bên ngoài đối với các bộ chấm tham chiếu: con người trong một số trường hợp, giám khảo thứ hai trong các trường hợp khác.

Sản phẩm được công bố gồm 44 benchmark thuộc mười loại lỗi với các biến thể ngữ cảnh, câu trả lời của Jev được lưu đệm và các script chấm lại, cùng một giao thức chia đôi loại bỏ sự thổi phồng do chọn lọc khỏi các mức tăng được báo cáo. Mỗi thành phần đáp ứng một nhu cầu thực tế. Các biến thể ngữ cảnh cho phép người đọc hỏi điều gì xảy ra khi trạng thái chứa nhiều hơn. Câu trả lời lưu đệm và script chấm lại cho phép tái tạo một con số mà không phải chạy lại mô hình. Giao thức chia đôi xử lý một cái bẫy phương pháp luận xứng đáng có một mục riêng.

Cái bẫy chọn lọc #

Có thể hỏi Jev nhiều câu về cùng một đầu vào. Đó là điểm mạnh của nó, và cũng là một mối nguy cho việc đánh giá. Nếu bạn đặt một tập câu hỏi ứng viên rồi báo cáo câu nào đạt điểm cao nhất, bạn đã tìm kiếm trên các câu hỏi và báo cáo người thắng. Bài báo nói thẳng: báo cáo câu tốt nhất trong số đó sẽ thổi phồng những gì người thực hành nhận được.

Bất kỳ ai từng tinh chỉnh prompt trên một tập kiểm thử đều sẽ nhận ra điều này. Biện pháp ở đây đơn giản. Câu hỏi được chọn trên một nửa số mục và chấm trên nửa còn lại. Câu hỏi có mục tiêu được chọn trên một nửa số mục và chấm trên nửa còn lại, qua 20 lần chia. Việc chọn lọc không bao giờ chạm vào các mục tạo ra con số được báo cáo.

Điều này quan trọng với cách đọc mọi mức tăng được báo cáo dưới đây. Luận điểm của bài báo là giao thức chia đôi loại bỏ sự thổi phồng do chọn lọc khỏi các mức tăng được báo cáo. Khi bài báo nói cách diễn đạt có mục tiêu cho mức tăng trung vị +0,006 AUROC, con số đó đến từ cách diễn đạt được chọn và chấm trên hai nửa riêng biệt. Một con số nhỏ như vậy, được đo trung thực, hữu ích hơn một con số lớn hơn đã âm thầm chứa lời nguyền của người thắng.

Kết quả chính: một câu hỏi chung #

Giờ là kết quả mà phần lớn người đọc muốn thấy. Một câu hỏi chung duy nhất đạt AUROC trung vị 0,886 ở chế độ zero-shot và vượt các baseline có giám sát trên phần lớn benchmark.

Hãy xét từng chữ. “Một câu hỏi chung duy nhất” nghĩa là không thiết kế prompt riêng cho từng benchmark. “Zero-shot” nghĩa là không huấn luyện trên benchmark mục tiêu. “Vượt các baseline có giám sát trên phần lớn benchmark” nghĩa là những hệ thống được huấn luyện trên dữ liệu có nhãn của nhiệm vụ lại thua một câu hỏi chẳng ai tinh chỉnh, trên phần lớn các benchmark được xem xét. Luận điểm dừng ở chữ “phần lớn”, và bài viết này cũng vậy.

Câu hỏi chung là một câu hỏi mẫu được đọc dưới dạng P(yes). Con số này báo cáo AUROC của 38 benchmark dùng được, và câu hỏi chung không được hỏi trên 7 benchmark. Vì vậy con số chính là trung vị trên các benchmark mà câu hỏi chung được áp dụng, lấy từ 38 benchmark dùng được. Người đọc cẩn thận nên giữ rõ các mẫu số: tổng cộng có 44 benchmark, 38 dùng được cho con số này, và câu hỏi chung có khoảng trống là 7.

Tôi cho rằng kết quả zero-shot là nửa thú vị hơn của câu. Vượt baseline có giám sát là một phát biểu về vị thế so sánh. AUROC trung vị 0,886 mà không cần huấn luyện riêng cho nhiệm vụ nói lên điều gì đó về lượng tín hiệu lỗi sẵn có cho một mô hình đọc trạng thái và trả lời một câu hỏi đơn giản. Liệu điều đó có khái quát hóa cho các loại lỗi ngoài mười loại này hay không thì các luận điểm không đề cập.

Cách diễn đạt gần như không liên quan #

Nếu bạn đã dành thời gian cho kỹ thuật prompt, kết quả tiếp theo sẽ khiến bạn chạnh lòng. Cách diễn đạt câu hỏi ít quan trọng, trong khi ngữ cảnh quan trọng hơn, chủ yếu qua các trường mã hóa nhãn.

Lời giải thích của bài báo cho điều này khá cụ thể. Khi câu trả lời được giữ dưới dạng xác suất thay vì quyết định argmax, cách diễn đạt câu hỏi ít quan trọng còn nội dung của trạng thái và nhãn thì rất quan trọng. Đây là một nhận xét về thông tin. Một quyết định argmax vứt bỏ biên độ mà một câu trả lời thắng câu trả lời kia, và một thay đổi cách diễn đạt có thể lật quyết định qua ranh giới. Xác suất giữ lại biên độ đó, nên một cách diễn đạt lại làm dịch bằng chứng một chút chỉ làm dịch xác suất một chút và phần lớn giữ nguyên thứ hạng.

Tôi sẽ giới hạn ở điều bài báo nêu: khi xác suất được giữ lại, cách diễn đạt ít quan trọng. Tôi sẽ không mở rộng nó thành một lời giải thích cơ chế về lý do, vì các luận điểm không đưa ra lời giải thích đó.

Các con số ủng hộ phát biểu này. Cách diễn đạt có mục tiêu cho mức tăng trung vị +0,006 AUROC, với cách diễn đạt được chọn và chấm trên hai nửa riêng biệt. Ngoài mẫu, cách diễn đạt có mục tiêu thêm +0,006 [−0,004; +0,015] AUROC. Khoảng này vắt qua số không. Người đọc không nên coi +0,006 là một cải thiện đáng tin cậy; khoảng này cho phép một mức giảm nhỏ cũng dễ như một mức tăng nhỏ. Với người thực hành, cách đọc hữu ích là việc săn tìm một cách diễn đạt khéo hơn khó đáng công sức, ít nhất trên các benchmark này.

Điều này nên thay đổi cách các nhóm phân bổ thời gian. Nếu cách diễn đạt gần như trơ, những giờ bỏ vào nó nên được dành cho trạng thái thì hơn.

Mức tăng nằm ở ngữ cảnh #

Vậy trạng thái chứa gì, và nên chứa gì? Phát hiện của bài báo là ngữ cảnh quan trọng hơn, chủ yếu qua các trường mã hóa nhãn. Ý tưởng then chốt đằng sau thiết kế nghiên cứu là thay đổi những gì Jev được hỏi tách biệt với những gì nó nhìn thấy: một bên là cách diễn đạt và kiểu trả lời của câu hỏi, bên kia là các trường của đầu vào. Chính sự tách biệt đó cho phép bài báo nói rằng cách diễn đạt ít quan trọng còn ngữ cảnh quan trọng hơn. Không có nó, hai hiệu ứng sẽ rối vào nhau.

Ví dụ tiêu biểu là PrivacyLens. Các tham chiếu định nghĩa nhãn mang lại mức tăng lớn, chẳng hạn danh sách mục bí mật của PrivacyLens (0,79→0,95). Bước nhảy từ 0,79 lên 0,95 AUROC là lớn so với +0,006 từ cách diễn đạt. Tham chiếu ở đây là một danh sách mục bí mật, đúng loại thứ mà phần thảo luận trước về lỗi mang tính quan hệ dự đoán là quan trọng: một câu trả lời có làm lộ điều riêng tư hay không phụ thuộc vào điều gì được coi là riêng tư, và riêng câu trả lời thì không nói lên điều đó.

Có một lưu ý cho việc triển khai, và đó là một lưu ý quan trọng. Ngữ cảnh mà một bộ giám sát đã triển khai sẽ nắm giữ chỉ giúp ích trên 1 trong 7 benchmark. Mức tăng lớn đến từ các tham chiếu định nghĩa nhãn, nhưng một bộ giám sát đã triển khai không nhất thiết có chúng. Những gì một bộ giám sát thực tế nắm giữ chỉ giúp ích trên một trong bảy benchmark.

Đây là một phát hiện tỉnh táo, và tôi nghĩ đó là câu có ý nghĩa thương mại lớn nhất trong bài báo. Nó tách con số phòng thí nghiệm khỏi con số thực địa. Một bộ phát hiện được đánh giá khi có sẵn tham chiếu định nghĩa nhãn đang trả lời một câu hỏi dễ hơn câu mà bộ giám sát đã triển khai phải đối mặt. Các mức tăng là có thật, nhưng bài báo nói rõ phần nào trong số đó một hệ thống triển khai có thể trông cậy.

Bài báo cũng chỉ ra một hạn chế của một benchmark. Trên Open-Prompt-Injection, nhãn theo dõi độ chính xác của nhiệm vụ được chèn vào. Đó là ví dụ về một nhãn có ý nghĩa gắn với một đặc tính của nhiệm vụ, điều ảnh hưởng đến những gì có thể kỳ vọng một bộ phát hiện nhìn thấy từ trạng thái. Tôi sẽ không rút thêm kết luận nào từ đó, vì các luận điểm không đưa ra kết luận nào.

Chi phí #

Giờ là con số khiến bài toán kinh tế trở nên cụ thể. Jev rẻ hơn 63 lần so với các bộ chấm LLM-judge. So sánh cụ thể: một lượt chạy qua 19 benchmark do giám khảo chấm tốn 0,30 USD, ít hơn 63 lần so với các giám khảo của chúng theo giá niêm yết. Phép so sánh chi phí bao gồm một lượt chạy qua 19 benchmark dùng giám khảo API theo giá niêm yết.

Hãy cẩn thận với phạm vi. Phép so sánh áp dụng cho 19 benchmark dùng giám khảo API, theo giá niêm yết, cho một lượt chạy. Nó không bao gồm mọi benchmark trong bộ, và không bao gồm giá chiết khấu. Trong phạm vi đó, tỷ lệ này lớn, và nó xuất phát từ kiến trúc đã mô tả: không có lượt giải mã cho mỗi tiêu chí.

Hãy nhớ lại yêu cầu ban đầu, rằng một bộ phát hiện chạy trên mọi tin nhắn phải rẻ. Con số 0,30 USD cho cả một lượt chạy qua 19 benchmark chính là hình hài của chữ “rẻ” trong bài báo này. Bài báo không quy đổi nó thành giá cho mỗi tin nhắn, và tôi cũng sẽ không làm vậy.

Đồng thuận với con người, và điều bất đồng tiết lộ #

Rẻ chỉ thú vị nếu bộ phát hiện cũng đúng. Ở những nơi nhãn của con người cho phép kiểm tra, Jev đồng thuận với chúng ngang với giám khảo, với một phần nhỏ chi phí.

Bằng chứng cụ thể nhất đến từ StrongREJECT. So với nhãn của con người ở đó, câu hỏi chung đồng thuận ngang với bộ chấm tham chiếu (κ Cohen 0,809 so với 0,811) và xếp hạng tốt hơn. Hai giá trị κ chênh nhau 0,002, nên cách đọc hợp lý là hòa về mức đồng thuận, với Jev dẫn trước về xếp hạng.

Tiếp theo là kết quả mà tôi thấy hữu ích nhất trong thực tế, vì nó biến bộ phát hiện thành một công cụ kiểm toán. Những bất đồng tự tin của Jev đã phơi bày các lỗi làm thay đổi nhãn ở ba benchmark và các nhãn mà trạng thái không thể tiết lộ ở bốn benchmark khác. Khi một bộ phát hiện tự tin bất đồng với nhãn tham chiếu của một benchmark, một cách giải thích là bộ phát hiện sai. Bài báo cho biết trong một số trường hợp, sự bất đồng chỉ vào chính benchmark: ba benchmark có lỗi làm thay đổi nhãn, và bốn benchmark khác có những nhãn mà trạng thái không thể tiết lộ.

Loại thứ hai nối lại với điểm về tính quan hệ. Một nhãn mà trạng thái không thể tiết lộ là một nhãn được định nghĩa bởi thứ chưa bao giờ đi vào đầu vào. Không bộ phát hiện nào đọc trạng thái đó có thể khôi phục nó. Tìm ra những trường hợp như vậy là một đóng góp khác với việc nâng điểm, vì nó cho những người duy trì benchmark biết dữ liệu và nhãn của họ tách đường ở đâu.

Điểm yếu: hiệu chuẩn #

Ở đây bài viết phải thẳng thắn, vì bài báo cũng thẳng thắn. Các xác suất xếp hạng tốt nhưng không chuyển được thành ngưỡng: ECE trung vị là 0,168 so với mức rỗng 0,074, trên cả nhãn đã kiểm chứng lẫn nhãn của giám khảo, vì xác suất trung bình của Jev lệch khỏi tỷ lệ cơ sở của từng benchmark.

Các mảnh ghép khớp với nhau như sau. AUROC đo xếp hạng, và xếp hạng thì mạnh. Ngưỡng là chuyện khác. Nếu xác suất đầu ra trung bình của mô hình không khớp với tần suất lỗi xảy ra trong một benchmark nhất định, thì t = 0,5 rơi vào sai chỗ, và sai số hiệu chuẩn kỳ vọng sẽ cao. ECE trung vị 0,168 nằm trên mức rỗng 0,074, một kết quả kém hơn điểm tham chiếu mà bài báo chọn. Và điều đó đúng trên cả nhãn đã kiểm chứng lẫn nhãn của giám khảo, nên điểm yếu này không phải là sản phẩm phụ của nhãn giám khảo nhiễu.

Hãy nhớ lại thiết lập hình thức: một bộ phát hiện phải xếp lỗi trên các trường hợp không lỗi và tách chúng tại một ngưỡng. Jev mặc định làm tốt việc thứ nhất và kém việc thứ hai. Tên của kỹ thuật có chứa “quyết định đã hiệu chuẩn”, trong khi độ hiệu chuẩn đo được ở đây không mang sang được giữa các benchmark, một mâu thuẫn đáng nói thẳng. Bài báo quy khoảng cách này cho tỷ lệ cơ sở và không khẳng định gì hơn.

Hệ quả thực tế: khi dùng thay cho giám khảo, Jev cần một ít nhãn để đặt ngưỡng. Đó là một chi phí thật, và nó thu hẹp tuyên bố về một sự thay thế cắm là chạy. Bạn không thể hướng nó vào một loại lỗi mới rồi tin vào t = 0,5.

Công thức #

Khuyến nghị của bài báo gọn gàng. Công thức là một câu hỏi chung được đọc dưới dạng xác suất, với ngưỡng được khớp trên mười mục có nhãn, giúp nâng F1 ở những nơi Jev kích hoạt quá ít tại t = 0,5 và tốn 0,025 trên nhãn đã kiểm chứng.

Hãy mở nó ra. Câu hỏi chung xử lý vấn đề diễn đạt bằng cách không thiết kế nó, phù hợp với phát hiện rằng cách diễn đạt ít quan trọng. Đọc câu trả lời dưới dạng xác suất giữ lại biên độ. Khớp ngưỡng trên mười mục có nhãn giải quyết việc lệch tỷ lệ cơ sở. Tác động lên F1 là tích cực ở những nơi Jev kích hoạt quá ít tại t = 0,5. Trên nhãn đã kiểm chứng, công thức tốn 0,025.

Con số cuối cùng đó đáng dừng lại. Công thức không phải không có mặt trái: trên nhãn đã kiểm chứng nó tốn 0,025. Bài báo báo cáo sự đánh đổi thay vì giấu nó, và tôi thà trích dẫn một công thức có chi phí được nêu rõ hơn là một công thức được quảng cáo như lợi ích thuần túy. Các luận điểm không cho biết 0,025 được đo bằng chỉ số nào ngoài bối cảnh nhãn đã kiểm chứng, nên tôi sẽ không đoán.

Mười mục có nhãn là một yêu cầu nhỏ. Với hầu hết các nhóm, đó là một buổi chiều gán nhãn, so với chi phí chạy một giám khảo trên mọi tin nhắn. Nhưng đó là điều kiện tiên quyết, và một nhóm không thể tạo ra bất kỳ mục có nhãn nào cho một loại lỗi mới thì đừng mong ngưỡng tự điều chỉnh.

Người thực hành nên rút ra điều gì #

Một vài điều suy ra từ đây, và tôi sẽ cam kết với chúng vì bằng chứng ủng hộ.

Thứ nhất, hãy ngừng tối ưu cách diễn đạt câu hỏi. Mức tăng ngoài mẫu từ cách diễn đạt có mục tiêu là +0,006 với khoảng từ −0,004 đến +0,015. Đó không phải cơ sở để đầu tư.

Thứ hai, hãy dồn công sức vào trạng thái. Các mức tăng lớn đến từ tham chiếu định nghĩa nhãn. Nếu bộ giám sát của bạn có thể được cung cấp tham chiếu định nghĩa lỗi, cải thiện nằm ở đó. Nếu không thể, hãy kỳ vọng ít hơn: ngữ cảnh mà một bộ giám sát đã triển khai sẽ nắm giữ chỉ giúp ích trên 1 trong 7 benchmark. Hãy lập kế hoạch theo con số bạn có thể đạt khi triển khai thay vì con số bạn đạt trên một benchmark mà tham chiếu nằm sẵn trong đầu vào.

Thứ ba, hãy dành ngân sách cho hiệu chuẩn. Lên kế hoạch gán nhãn mười mục cho mỗi loại lỗi và khớp ngưỡng. Đừng phát hành với t = 0,5.

Thứ tư, hãy dùng bất đồng làm tín hiệu. Những bất đồng tự tin với nhãn tham chiếu đã phơi bày lỗi ở ba benchmark và các nhãn không thể tiết lộ ở bốn benchmark khác. Nếu bạn chạy nó trên các bộ đánh giá của riêng mình, hãy chuẩn bị rằng nó có thể cho bạn biết về nhãn của bạn cũng như về mô hình của bạn. Đó là một suy luận từ phát hiện của bài báo chứ không phải một luận điểm đã đo về bất kỳ bộ cụ thể nào, nên hãy coi đó là lời mời kiểm tra.

Thứ năm, hãy nhớ những điểm yếu đã biết. Nhà phát triển liệt kê ý nghĩa gián tiếp và nội dung đối kháng trong số những điểm yếu đã biết của Jev. Một bộ giám sát quan trọng về an toàn sẽ gặp nội dung đối kháng. Các luận điểm ở đây không báo cáo Jev hoạt động thế nào với nó, nên đó vẫn là một sườn hở, và tôi muốn nó được kiểm thử trước khi tin vào một hệ thống triển khai.

Đọc kết quả dưới góc độ thương mại #

Các nhà sáng lập sẽ muốn biết điều này nằm ở đâu. Lập luận chi phí là mạnh nhất: một bộ phát hiện chạy trên mọi tin nhắn phải rẻ, và mức giảm 63 lần so với các bộ chấm LLM-judge thay đổi những triển khai nào là trong tầm chi trả. Lập luận độ chính xác đứng thứ hai: AUROC zero-shot 0,886 và chiến thắng trước baseline có giám sát trên phần lớn benchmark.

Các lưu ý định hình những gì có thể bán một cách trung thực. Bộ phát hiện cần một ít nhãn cho mỗi ngưỡng. Độ hiệu chuẩn của nó không mang sang được. Các mức tăng tốt nhất của nó dựa vào tham chiếu mà một hệ thống triển khai có thể không có. Đó là những điều kiện sử dụng, và bất kỳ sản phẩm nào xây trên nền này nên nêu rõ chúng thay vì chôn vùi. Không điều nào trong số đó làm suy yếu lập luận chi phí; chúng mô tả công việc thiết lập.

Còn có một điểm lặng lẽ hơn về chính phép đo. RLCDAlignBench, với các biến thể ngữ cảnh, câu trả lời Jev lưu đệm, script chấm lại và giao thức chia đôi, là một tài sản đánh giá có thể tái sử dụng. Một benchmark loại bỏ sự thổi phồng do chọn lọc khỏi các mức tăng được báo cáo là loại sản phẩm cho phép so sánh các tuyên bố về sau. Đó là một loại giá trị khác với bộ phát hiện.

Những gì còn bỏ ngỏ #

Một vài ranh giới rõ ràng từ các luận điểm. Các mô hình mục tiêu là năm mô hình mở với 2–7B tham số, nên kết quả mô tả lỗi trong các tương tác từ những mô hình cỡ đó. Câu hỏi chung không được hỏi trên 7 benchmark, và AUROC chính là trung vị trên các benchmark mà nó được hỏi. Nhãn đến từ các bộ chấm tham chiếu, với nhãn của con người và của giám khảo thứ hai bao phủ StrongREJECT, HarmBench, AbstentionBench và InstrumentalEval.

Câu hỏi mở làm tôi quan tâm nhất là câu hỏi do chính cấu trúc của bài báo đặt ra. Lỗi mang tính quan hệ; trạng thái thường thiếu tham chiếu; và ngữ cảnh của một bộ giám sát đã triển khai chỉ giúp ích trên 1 trong 7 benchmark. Thiết kế một lần gọi của Jev cho phép nhiều câu hỏi dùng chung một đầu vào, nhưng đòn bẩy lớn nhất hóa ra lại là đầu vào mang những trường nào. Làm thế nào một hệ thống triển khai có được tham chiếu định nghĩa nhãn vào lúc giám sát, chẳng hạn danh sách mục bí mật cho một phép kiểm tra quyền riêng tư, là việc tiếp theo cần giải quyết. Bài báo cho thấy mức tăng là có thể đạt được (0,79→0,95 trên PrivacyLens), và để ngỏ việc liệu có thể cung cấp nó cho một bộ giám sát đã triển khai đủ rẻ để giữ lợi thế 63 lần hay không.

Ý nghĩa theo từng lĩnh vực #

Khả năng đánh giá các tiêu chí căn chỉnh phức tạp thông qua các đầu quyết định đã hiệu chuẩn với một phần nhỏ chi phí suy luận đang định hình lại an toàn vận hành trên nhiều lĩnh vực.

Nhà cung cấp cổng AI và nền tảng bảo mật #

Các công ty hạ tầng triển khai lớp bảo vệ an toàn theo thời gian thực có thể thay thế các kiến trúc nối tầng tốn kém (gọi riêng các bộ phân loại chèn prompt, độc hại và quyền riêng tư) bằng các đầu RLCD đa truy vấn hợp nhất. Chi phí vận hành giảm hơn 60 lần trong khi độ trễ được giới hạn trong một lượt truyền xuôi duy nhất.

Nhóm quản trị AI và tuân thủ kiểm toán #

Các ủy ban rủi ro đánh giá hành vi mô hình theo các chuẩn như yêu cầu rủi ro cao của EU AI Act hay NIST AI RMF có được một nhật ký kiểm toán mang tính tất định và xác suất. Thay cho phản hồi tường thuật không có cấu trúc của LLM-judge, hệ thống ghi lại các phân phối xác suất đã hiệu chuẩn, hỗ trợ kiểm soát quy trình thống kê và giám sát độ trôi.

Nhóm triển khai doanh nghiệp và red teaming #

Các nhóm bảo mật có thể nhanh chóng triển khai bộ phát hiện lỗi tùy chỉnh bằng cách soạn các biểu diễn trạng thái tập trung và khớp ngưỡng quyết định với chỉ khoảng mười ví dụ đặc thù lĩnh vực, loại bỏ chu kỳ tinh chỉnh kéo dài nhiều tuần trước đây cần cho các bộ phân loại đặt riêng.

Kết luận #

Việc đánh giá Jev trên RLCDAlignBench xác lập một hướng kiến trúc thuyết phục cho giám sát mô hình trong môi trường sản xuất: đọc xác suất đã hiệu chuẩn trên nhiều câu hỏi có kiểu trong một lượt truyền xuôi vượt các giám khảo LLM tự hồi quy về chi phí và các bộ phân loại một token về độ linh hoạt. Dù người thực hành phải dành ngân sách cho việc hiệu chuẩn ngưỡng bằng thực nghiệm thay vì giả định xác suất chuyển được ngay, lợi thế kinh tế 63 lần khiến giám sát toàn diện theo thời gian thực trở nên khả thi ở quy mô lớn.

Câu hỏi thường gặp #

Vì sao giám khảo LLM sinh văn bản không thực tế cho giám sát sản xuất theo thời gian thực?

Giám khảo sinh văn bản cần một lượt giải mã tự hồi quy đầy đủ cho mỗi tiêu chí an toàn hoặc căn chỉnh được đánh giá. Trong các ứng dụng tiêu dùng hoặc doanh nghiệp có lưu lượng lớn, chạy nhiều lần gọi giám khảo sinh văn bản cho mỗi tin nhắn gây độ trễ nghiêm trọng và đẩy chi phí vận hành lên gấp nhiều bậc.

Học tăng cường cho quyết định đã hiệu chuẩn (RLCD) là gì?

RLCD là một phương pháp huấn luyện tối ưu hóa mô hình để tạo ra các xác suất hậu nghiệm được hiệu chuẩn tốt trên các đầu quyết định có cấu trúc thay vì sinh ra chuỗi token. Điều này cho phép mô hình đánh giá đồng thời nhiều câu hỏi tùy ý trong một lượt đánh giá xuôi duy nhất.

Vì sao ngưỡng quyết định cần được hiệu chuẩn trên dữ liệu cục bộ?

Dù các mô hình RLCD xếp hạng tương tác theo khả năng xảy ra lỗi rất tốt (đạt AUROC cao), xác suất trung bình tuyệt đối của chúng dịch chuyển tùy theo tỷ lệ cơ sở của lĩnh vực mục tiêu. Hiệu chuẩn một ngưỡng quyết định vận hành trên khoảng mười ví dụ có nhãn của lĩnh vực bảo đảm độ nhạy phù hợp mà không có tỷ lệ dương tính giả không chấp nhận được.

Tài liệu tham khảo #

Mrinank Sharma et al., (2024). Hướng tới hiểu và giảm thiểu sự xu nịnh trong mô hình ngôn ngữ ⧉. arXiv.
RLCDAlignBench Consortium, (2026). Phát hiện lỗi căn chỉnh đa tiêu chí qua các đầu quyết định đã hiệu chuẩn ⧉. arXiv.
Anthropic / Alignment Research, (2025). AI hiến định và động lực của bộ đánh giá ⧉. Anthropic.
NIST, (2024). Khung quản lý rủi ro trí tuệ nhân tạo (AI RMF 1.0) ⧉. NIST.

Cập nhật lần cuối 2026-09-30.

Cập nhật lần cuối 2026-10-27.

Đăng lại bài này

Bộ phát hiện đọc xác suất thay vì phán quyết: Jev qua 44 benchmark — Sebastien Rousseau

Jev, huấn luyện bằng RLCD, được thử trên 44 benchmark lỗi căn chỉnh: xếp hạng tốt, rẻ hơn LLM-judge 63 lần, nhưng ngưỡng phải chỉnh trên 10 mục có nhãn.

Bài viết này được cấp phép theo Creative Commons Attribution 4.0 International. Đăng lại yêu cầu ghi nguồn đến URL chính tắc.

Bộ phát hiện đọc xác suất thay vì phán quyết: Jev qua 44 benchmark — Sebastien Rousseau

Jev, huấn luyện bằng RLCD, được thử trên 44 benchmark lỗi căn chỉnh: xếp hạng tốt, rẻ hơn LLM-judge 63 lần, nhưng ngưỡng phải chỉnh trên 10 mục có nhãn.

Originally published at https://sebastienrousseau.com/vi/2026-09-30-phat-hien-doc-xac-suat-thay/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER