Chuyện gì đã xảy ra
Bản in trước arXiv mới xem xét lý do tại sao các mô hình ngôn ngữ được trang bị công cụ đôi khi đưa ra những tuyên bố không được hỗ trợ bởi bằng chứng có sẵn cho chúng. Nghiên cứu tách vấn đề thành tần suất xảy ra các khiếu nại không được hỗ trợ và tần suất chúng có thể được sửa chữa khi cung cấp bằng chứng còn thiếu.
Bài viết nghiên cứu các mô hình ngôn ngữ có thể gọi các công cụ để giải quyết sự không chắc chắn. Phát hiện trọng tâm của nó là việc chỉ truy cập công cụ không phải lúc nào cũng dẫn đến việc kiểm tra mô hình. Trong một thiết lập Qwen3-32B cố định, 33 trong số 512 phản hồi đầu tiên cho 256 mẫu lời nhắc mới đã kết thúc bằng một xác nhận quyền sở hữu đã được thiết lập không được hỗ trợ, mặc dù một lệnh gọi công cụ sẵn có có thể đã giải quyết được sự không chắc chắn và các hướng dẫn rõ ràng cấm các giả định và phỏng đoán. Các tác giả xác định một tuyên bố không được hỗ trợ bằng cách sử dụng bằng chứng hiển thị cho mô hình và câu trả lời cuối cùng của nó mà không dựa vào câu trả lời đúng ẩn.
Sau đó, các nhà nghiên cứu đã phát lại từng trường hợp trong số 33 trường hợp đó từ một bản sao chính xác của trạng thái xảy ra khiếu nại. Các phản hồi của công cụ thay thế giống nhau về cấu trúc và độ dài và chỉ khác nhau ở mã phản hồi một ký tự. Theo bài báo, việc cung cấp bằng chứng giải quyết đã sửa chữa tất cả 33 khiếu nại không được hỗ trợ. Một phản hồi phù hợp nhưng không mang lại thông tin hữu ích nào đã không giải quyết được vấn đề nào. Khi bằng chứng ủng hộ câu trả lời ban đầu của mô hình, mô hình vẫn giữ lại câu trả lời đó trong tất cả 33 trường hợp và không thấy có tác hại nào trong thử nghiệm này.
Một thử nghiệm riêng biệt đã kiểm tra quy tắc kiểm tra tự động trên 64 trường hợp cần có bằng chứng. Quy tắc này đã kích hoạt 21 cuộc gọi bằng chứng bổ sung. Bài báo báo cáo rằng nó đã sửa tất cả 10 tuyên bố sai không được hỗ trợ, bảo tồn 11 câu trả lời đúng một cách tình cờ và không bao giờ thay đổi câu trả lời đúng thành câu trả lời sai. Những kết quả này cho thấy rằng biện pháp can thiệp đã được nhắm mục tiêu trong bối cảnh được thử nghiệm, nhưng chúng không xác định quy tắc sẽ thực hiện như thế nào với các gợi ý, mô hình, công cụ hoặc loại bằng chứng khác nhau.
Mô hình so sánh tạo ra một kết quả hoàn toàn khác biệt. Trên thiết lập Gemma 4 cố định bằng cách sử dụng cùng cài đặt lấy mẫu, mô hình đã gọi công cụ này trong tất cả 512 phản hồi đầu tiên và chưa bao giờ đưa ra xác nhận quyền sở hữu cuối cùng không được hỗ trợ. Vì không có khiếu nại không được hỗ trợ nào xuất hiện một cách tự nhiên trong thiết lập đó nên các tác giả không thể đo lường khả năng sửa chữa có điều kiện cho nó. Nguồn xác định các thử nghiệm là hai thiết lập mô hình cố định cục bộ trên hai nhóm nhiệm vụ tổng hợp.
Tại sao nó quan trọng
Các phát hiện này chỉ ra một vấn đề về độ tin cậy thực tế đối với các hệ thống AI có thể tham khảo các công cụ, cơ sở dữ liệu hoặc dịch vụ bên ngoài: quyền truy cập vào xác minh không đảm bảo rằng mô hình sẽ sử dụng nó trước khi đưa ra yêu cầu bồi thường. Bài báo cũng báo cáo rằng một quy tắc kiểm tra tự động đơn giản đã sửa các lỗi quan sát được trong một thiết lập được thử nghiệm, mặc dù bằng chứng còn hạn chế.
Vấn đề thực tế không chỉ đơn giản là liệu một mô hình có công cụ hay không. Một hệ thống có thể được kết nối với chức năng tìm kiếm, cơ sở dữ liệu hoặc máy tính và vẫn trả lời trước khi thu được thông tin giải quyết vấn đề không chắc chắn. Đối với các ứng dụng mà khiếu nại không được hỗ trợ có thể đánh lừa người dùng, thì sự khác biệt giữa tính khả dụng của công cụ và việc sử dụng công cụ là hệ quả. Kết quả của bài báo đưa ra một cách cụ thể để mô tả sự khác biệt đó thay vì coi độ tin cậy là một điểm số duy nhất.
Nghiên cứu này cũng đưa ra một khung đánh giá có thể hữu ích. Việc đo lường sự xuất hiện hỏi tần suất một mô hình độc lập đưa ra tuyên bố không được hỗ trợ. Đo lường mức độ sửa chữa có điều kiện hỏi liệu yêu cầu bồi thường tương tự có thay đổi hay không khi cung cấp bằng chứng còn thiếu. Sự tách biệt đó có thể giúp người đánh giá xác định xem vấn đề của mô hình là do không kiểm tra được, không cập nhật được sau khi kiểm tra hay cả hai. Trong thử nghiệm này, thiết lập Qwen cho thấy lỗi kiểm tra nhưng phản hồi chính xác khi giải quyết bằng chứng được cung cấp.
Kết quả kiểm tra tự động có ý nghĩa quan trọng vì nó kiểm tra biện pháp bảo vệ vận hành khả thi thay vì chỉ ghi lại lỗi. Trong thử nghiệm 64 trường hợp được báo cáo, quy tắc đã thêm 21 cuộc gọi bằng chứng và sửa 10 tuyên bố sai không được hỗ trợ mà không thay đổi bất kỳ câu trả lời đúng nào. Sự kết hợp đó rất đáng khích lệ trong thử nghiệm, đặc biệt đối với các hệ thống trong đó cuộc gọi xác minh rẻ hơn so với việc cho phép người dùng nhận được câu trả lời không được hỗ trợ.
Các giới hạn đều quan trọng như nhau. Nguồn mô tả một bản in trước, không phải một nghiên cứu được đánh giá ngang hàng và chỉ báo cáo kết quả từ hai thiết lập mô hình cố định và hai nhóm nhiệm vụ tổng hợp. Các tác giả nói rõ ràng rằng những phát hiện này không cho thấy mức độ phổ biến của lỗi trong quá trình triển khai trong thế giới thực hoặc nó phản ánh một cơ chế chung được chia sẻ giữa các mô hình. Do đó, các con số hỗ trợ một phát hiện có độ tin cậy hẹp chứ không phải là một tuyên bố rộng rãi về toàn bộ các mô hình ngôn ngữ.
Các kết quả khác nhau từ Qwen3-32B và Gemma 4 cũng cảnh báo việc khái quát hóa. Một mô hình đôi khi không kiểm tra được, trong khi mô hình kia gọi công cụ trong mọi phản hồi đầu tiên theo thiết lập đã nêu. Nguồn không xác định được yếu tố kiến trúc, đào tạo, nhắc nhở hoặc nhiệm vụ cụ thể nào đã gây ra sự khác biệt đó. Nó cũng không báo cáo liệu các mô hình đã được thử nghiệm với bằng chứng ồn ào, mâu thuẫn, chậm trễ hay tốn kém hay không.
Cơ chế tương tác: Nó thực sự hoạt động như thế nào
Khám phá công nghệ cơ bản đằng sau sự phát triển này một cách tương tác.
crm_get_transaction(id='4092').Which component of an AI application is the machine-learning model itself?
Xem gì tiếp theo
Câu hỏi quan trọng là liệu hành vi được báo cáo có xuất hiện ngoài hai cấu hình mô hình cố định và nhóm nhiệm vụ tổng hợp của nghiên cứu hay không. Công việc tiếp theo nên kiểm tra nhiều mô hình, công cụ thực tế và điều kiện triển khai hơn, đồng thời xác định xem các quy tắc kiểm tra có còn an toàn và hữu ích hay không khi việc thu thập bằng chứng không rõ ràng, không đầy đủ hoặc tốn kém.
Nhân rộng là bước tiếp theo quan trọng nhất. Các nhà nghiên cứu nên kiểm tra các biện pháp xảy ra và sửa chữa trên các họ mô hình bổ sung, kích thước mô hình, cài đặt lấy mẫu và chính sách sử dụng công cụ. Nguồn hiện tại không xác định liệu 33 tuyên bố không được hỗ trợ là điển hình, thường xuyên bất thường hay hiếm gặp bất thường. Nó cũng không cho biết liệu quy tắc kiểm tra tự động có hoạt động hay không khi các mô hình phải đối mặt với các hướng dẫn đa dạng hơn hoặc chuỗi lệnh gọi công cụ dài hơn.
Nhiệm vụ thực tế sẽ là một bài kiểm tra quan trọng. Bài viết sử dụng các nhóm tác vụ tổng hợp, trong khi các hệ thống được triển khai có thể tìm kiếm trên web, truy vấn hồ sơ kinh doanh, truy xuất tài liệu, thực thi mã hoặc tương tác với API. Những môi trường đó có thể tạo ra một phần bằng chứng, các nguồn mâu thuẫn và lỗi trong chính các công cụ. Vẫn chưa biết liệu việc cung cấp mã phân giải một ký tự có nắm bắt được khó khăn trong việc quyết định thời điểm kiểm tra trong cài đặt thực tế hay không.
Người đánh giá cũng nên xem xét chi phí và tác dụng phụ của việc kiểm tra. Nguồn báo cáo có 21 cuộc gọi bằng chứng bổ sung trong thử nghiệm riêng biệt, nhưng nó không cung cấp phân tích chi phí rộng hơn hoặc cho thấy quy tắc hoạt động như thế nào khi các công cụ chậm, bị giới hạn tốc độ hoặc không có sẵn. Một biện pháp bảo vệ giúp cải thiện khả năng hỗ trợ thực tế vẫn có thể ảnh hưởng đến độ trễ, việc sử dụng điện toán hoặc trải nghiệm người dùng. Những sự đánh đổi đó không được đo lường ở đây.
Trường này sẽ theo dõi xem các quy tắc kiểm tra có còn bảo thủ trong điều kiện không chắc chắn hay không. Trong thử nghiệm được báo cáo, quy tắc không bao giờ chuyển câu trả lời đúng thành câu trả lời sai, nhưng kết quả đó đến từ một mẫu nhỏ được kiểm soát. Các thử nghiệm lớn hơn nên tìm kiếm các biện pháp can thiệp sai, thất bại trong việc sửa chữa và các trường hợp có bằng chứng về mặt kỹ thuật nhưng bản thân nó không đáng tin cậy. Nguồn không cung cấp bằng chứng về những điều kiện đó.
Cuối cùng, các định nghĩa của bài báo có thể hỗ trợ nhiều báo cáo có thể so sánh hơn. Việc tách biệt trường hợp khiếu nại không được hỗ trợ khỏi việc sửa chữa có điều kiện giúp có thể nói liệu hệ thống không tìm kiếm bằng chứng hay không sử dụng bằng chứng sau khi thu được. Việc các biện pháp đó có trở thành tiêu chuẩn hay không sẽ phụ thuộc vào việc nhân rộng và chứng minh rằng chúng dự đoán được lỗi mà người dùng gặp phải bên ngoài các đánh giá tổng hợp.