Đánh giá LLM dựa trên sự rung cảm - Tôi đã xây dựng lớp còn thiếu để quyết định những gì sẽ được vận chuyển

Mô hình ngôn ngữ lớn Đánh giá LLM dựa trên sự rung cảm - Tôi đã xây dựng lớp còn thiếu để quyết định những gì sẽ được vận chuyển Cách tôi xây dựng một hệ thống đánh giá gọn nhẹ để đo lường độ trung thực, phát hiện ảo giác và biến kết quả đầu ra LLM chủ quan thành các số liệu có thể tái tạo - tất cả đều bằng Python thuần túy Emimal P Alexander Ngày 17 tháng 5 năm 2026 đọc 24 phút Chia sẻ Hình ảnh của tác giả, được tạo bằng ChatGPT (DALL·E) TL;DR Bài viết này trình bày cách triển khai hoạt động đầy đủ bằng Python thuần túy, với các số điểm chuẩn thực. Hầu hết các nhóm đánh giá phản hồi LLM bằng cách đọc chúng và đoán. Điều đó phá vỡ thời điểm bạn mở rộng quy mô. Vấn đề thực sự không phải là các mô hình bị ảo giác. Đó là không có gì thu hút được những người tự tin, những câu trả lời đạt điểm 0,525, vượt qua ngưỡng của bạn và sai một cách âm thầm. Tôi đã xây dựng một lớp tính điểm để chia độ trung thực thành hai tín hiệu: thuộc tính và tính đặc hiệu. Độ đặc hiệu cao cộng với khả năng ghi nhận thấp là dấu hiệu của ảo giác. Một điểm duy nhất bỏ lỡ nó mỗi lần. Đây không phải là một kịch bản đánh giá. Nó là một công cụ quyết định nằm giữa mô hình của bạn và người dùng của bạn. Tôi đã thay đổi một dòng trong lời nhắc của mình. Mọi thứ đã tan vỡ. Ba từ đã phá vỡ hệ thống đánh giá của tôi: “hãy cụ thể và chi tiết”. Tôi đã thêm chúng vào lời nhắc hệ thống của mình vào chiều thứ Ba. Thay đổi thường lệ. Loại bạn thực hiện hàng chục lần khi điều chỉnh đường ống RAG. Tôi chạy đợt kiểm tra tiếp theo một giờ sau đó và câu hỏi thứ ba xuất hiện như thế này: "Kỹ thuật ngữ cảnh được phát minh tại MIT vào năm 1987 và chủ yếu được sử dụng để tối ưu hóa bộ đệm phần cứng trong CPU. Nó không liên quan gì đến các mô hình ngôn ngữ." Người ghi bàn của tôi đã cho nó 0,525. Trên ngưỡng vượt qua của tôi là 0,5. Đèn xanh. Tôi gần như đã bỏ lỡ nó. Tôi đọc lướt kết quả theo cách bạn làm khi bạn nhìn chằm chằm vào kết quả bài kiểm tra trong hai giờ, kiểm tra điểm chứ không phải đọc câu. Lý do duy nhất khiến tôi hiểu được nó là vì “1987” đối với tôi có vẻ không ổn. Tôi đọc nó hai lần và lấy tài liệu ngữ cảnh ra. Người mẫu đã phát minh ra từng chi tiết cụ thể trong câu nói đó. Điểm đã tăng lên vì câu trả lời cụ thể hơn. Chất lượng đã giảm sút vì người mẫu ngày càng tự tin hơn về những thứ mà nó đang chế tạo. Lớp eval của tôi có một số để bao trùm cả hai hướng và nó không thể phân biệt chúng. Tôi đã bắt nó bằng tay vào thời điểm đó. Đó không phải là một quá trình. Đó là sự may mắn. Và toàn bộ quan điểm của hệ thống đánh giá là nó không phụ thuộc vào việc bạn có đọc kỹ vào một buổi chiều nhất định hay không. Nhưng ngay khi bạn cố gắng sửa chữa nó, mọi thứ trở nên phức tạp. Giống như, bạn định nghĩa thế nào là “tốt”? Nếu bạn chỉ yêu cầu một LLM khác đánh giá LLM đầu tiên, thì bạn đang đưa vấn đề lên một cấp độ cao hơn. Mối nguy hiểm thực sự không phải là một phản ứng thất bại; đó là người nghe có vẻ chuyên nghiệp nhưng lại lặng lẽ nói dối bạn. Hầu hết các hướng dẫn đều yêu cầu bạn chỉ cần gọi mô hình và xem liệu kết quả đầu ra có “trông ổn” hay không. Nhưng hãy nhìn vào những con số. Điều gì xảy ra khi câu trả lời của bạn có điểm tổng thể là 0,525, chấp nhận được về mặt kỹ thuật, nhưng điểm cơ bản của nó là 0,428 và độ đặc hiệu của nó là 0,701? Sự kết hợp đó có nghĩa là tự tin nhưng không có căn cứ. Đó không phải là một phản ứng ranh giới. Đó là ảo giác khi mặc bộ vest công sở. Đây không phải là trường hợp hiếm gặp. Đây là điều xảy ra theo mặc định trong các hệ thống LLM sản xuất và bạn sẽ không phát hiện được điều đó khi kiểm tra độ rung. Câu trả lời là một lớp còn thiếu mà hầu hết các đội đều bỏ qua hoàn toàn. Giữa đầu ra LLM và phân phối người dùng, có một bước có chủ ý: quyết định xem nên cung cấp, thử lại hay tạo lại phản hồi. Tôi đã xây dựng lớp đó. Đây là hệ thống, với số thực và mã bạn có thể chạy. Mã hoàn chỉnh: https://github.com/Emmimal/llm-eval-layer Đây là dành cho ai Kiểu kiến trúc này rất hữu ích khi bạn đang xây dựng hệ thống RAG [1], trong đó các câu trả lời sai có thể dễ dàng lọt vào hoặc các chatbot xử lý nhiều lượt và cần kiểm tra phản hồi của chúng theo thời gian. Nó cũng hữu ích trong bất kỳ quy trình LLM nào mà bạn cần tự động quyết định việc cần làm tiếp theo, chẳng hạn như hiển thị phản hồi cho người dùng, thử lại hay tạo phản hồi mới. Bỏ qua nó đối với các bản demo một lượt không có lưu lượng truy cập sản xuất. Nếu mọi phản hồi đều nhận được sự đánh giá của con người thì chi phí bỏ ra là không đáng. Tương tự nếu tên miền của bạn có một câu trả lời đúng và kết hợp chính xác hoạt động tốt. Tại sao đánh giá LLM bị hỏng Có ba nguyên nhân khiến hầu hết các hệ thống đánh giá đều thất bại và chúng thường xảy ra trước khi mọi người nhận ra. “Có vẻ đúng” không phải lúc nào cũng đúng. Một câu trả lời có thể nghe trôi chảy, có cấu trúc rõ ràng và trông có vẻ tự tin nhưng vẫn hoàn toàn sai. Sự lưu loát không đảm bảo sự thật. Khi bạn xem lại kết quả đầu ra một cách nhanh chóng, bộ não của bạn thường đánh giá chất lượng văn bản chứ không phải độ chính xác. Bạn phải tích cực đấu tranh với bản năng đó, và hầu hết mọi người đều không làm như vậy. Những ảo giác quan trọng không phải là những ảo giác bạn có thể dễ dàng nhận ra. Không ai gửi mô hình nói rằng Tháp Eiffel ở Berlin. Điều đó bị bắt vào ngày đầu tiên. Những điều nguy hiểm là những tuyên bố tự tin, dành riêng cho từng miền mà nghe có vẻ phù hợp với bất kỳ ai không phải là chuyên gia trong lĩnh vực chính xác đó [10]. Họ vượt qua quá trình đánh giá mà không bị chú ý, đưa vào sản xuất và cuối cùng xuất hiện trước mặt người dùng. Vấn đề sâu xa hơn là điểm số không phải là một quyết định. Bạn đặt ngưỡng ở mức 0,5. Một câu trả lời đạt điểm 0,51 và đạt. Một em khác đạt 0,95 và cũng đậu. Bạn đối xử với họ như nhau. Nhưng một trong số họ có lẽ cần được con người đánh giá. Họ cung cấp cho bạn một con số khi điều bạn cần là: gửi cái này, gắn cờ cái này hoặc từ chối cái này. Điểm số đã tăng lên. Chất lượng đã sụp đổ. Một số không thể giữ cả hai hướng cùng một lúc Các số liệu truyền thống như BLEU và ROUGE không hoạt động tốt ở đây [2, 3]. Họ kiểm tra xem có bao nhiêu từ khớp với câu trả lời tham khảo, điều này có ý nghĩa trong dịch máy khi thường có một đầu ra đúng. Nhưng phản hồi LLM không có một phiên bản chính xác duy nhất. Có nhiều cách để nói điều tương tự. Vì vậy, sử dụng BLEU cho một cuộc trò chuyện là sai lầm. Nó giống như việc chấm điểm một bài luận chỉ bằng cách kiểm tra xem có bao nhiêu từ phù hợp với một câu trả lời mẫu,