Blog / AI / Deep Article
Giải thích hiện tượng Lost in the Middle, giới hạn của cửa sổ ngữ cảnh dài và cách kiểm thử AI đọc tài liệu bằng vị trí bằng chứng, RAG và trích dẫn nguồn.
Một chatbot được quảng bá hỗ trợ hàng chục nghìn hoặc hàng trăm nghìn token ngữ cảnh. Người dùng tải lên một tập hồ sơ dài, hỏi một chi tiết nằm ở trang giữa và nhận câu trả lời tự tin nhưng sai. Vấn đề không nhất thiết là tài liệu vượt quá giới hạn kỹ thuật. Đọc được toàn bộ đầu vào và sử dụng chính xác mọi phần của đầu vào là hai năng lực khác nhau.
Nghiên cứu *Lost in the Middle: How Language Models Use Long Contexts* của Nelson F. Liu và cộng sự, công bố năm 2023, đã kiểm tra điều này bằng hai nhóm nhiệm vụ: hỏi đáp dựa trên nhiều tài liệu và truy xuất cặp khóa–giá trị. Nhóm tác giả nhận thấy hiệu suất có thể giảm đáng kể khi thông tin liên quan được đặt ở giữa ngữ cảnh dài, trong khi vị trí đầu hoặc cuối thường thuận lợi hơn. Đây là một phát hiện có điều kiện từ các mô hình và thiết lập được thử nghiệm, không phải định luật cho mọi mô hình hiện tại.
Trong mô hình ngôn ngữ, token là đơn vị văn bản được xử lý, có thể là một từ, một phần từ hoặc ký hiệu. Cửa sổ ngữ cảnh quy định lượng token mô hình có thể nhận trong một lượt xử lý, bao gồm hướng dẫn, lịch sử hội thoại, tài liệu đính kèm và phần nội dung liên quan khác. Một cửa sổ lớn cho phép đưa thêm dữ liệu vào, nhưng không tự chứng minh rằng mô hình sẽ chú ý đúng chi tiết cần tìm.
Có thể hình dung hai vấn đề riêng. Vấn đề thứ nhất là capacity: tài liệu có nằm trong giới hạn đầu vào hay không. Vấn đề thứ hai là retrieval and use: sau khi đã nhận dữ liệu, mô hình có định vị, kết hợp và suy luận chính xác từ đoạn liên quan hay không. Một hệ thống có thể vượt qua bài kiểm tra thứ nhất nhưng thất bại ở bài kiểm tra thứ hai.
Chẳng hạn, một hợp đồng gồm 120 trang có điều khoản phạt ở trang 61. Mô hình nhận đủ 120 trang không đồng nghĩa câu trả lời về mức phạt sẽ đúng. Nó có thể nhầm với điều khoản tương tự ở trang 12, bỏ sót ngoại lệ ở trang 62 hoặc suy diễn khi văn bản không quy định rõ. Đây là tình huống minh họa, không phải kết quả của một thử nghiệm thực tế.
Nhóm nghiên cứu thay đổi vị trí của thông tin liên quan trong đầu vào rồi quan sát chất lượng thực hiện nhiệm vụ. Trong bài toán hỏi đáp nhiều tài liệu, một tài liệu chứa bằng chứng cần thiết có thể nằm ở đầu, giữa hoặc cuối danh sách. Trong bài toán truy xuất khóa–giá trị, mô hình phải tìm một giá trị cụ thể giữa nhiều cặp dữ liệu.
Khi độ chính xác thay đổi theo vị trí bằng chứng, ta có dấu hiệu rằng việc sử dụng ngữ cảnh chưa ổn định. Bài báo mô tả xu hướng kết quả tốt hơn khi thông tin liên quan nằm gần đầu hoặc cuối, và kém hơn khi nằm giữa. Cách kiểm tra này hữu ích vì nó giữ trọng tâm vào khả năng truy xuất thông tin, thay vì chỉ hỏi mô hình có chấp nhận chuỗi dài hay không.
Tuy nhiên, không thể lấy một biểu đồ trong nghiên cứu năm 2023 để khẳng định mọi mô hình năm 2026 đều có đường cong giống nhau. Kiến trúc, dữ liệu huấn luyện, cách căn chỉnh, phương pháp truy xuất và kỹ thuật xử lý ngữ cảnh đã thay đổi. Điều cần kế thừa là phương pháp kiểm thử theo vị trí, chứ không phải một kết luận tuyệt đối về mọi sản phẩm.
Cơ chế attention cho phép token tương tác với các token khác theo những ràng buộc của mô hình. Nhưng có quyền truy cập thông tin không có nghĩa mô hình luôn phân bổ sự chú ý hữu ích hoặc thực hiện suy luận chính xác. Nhiều đoạn văn có nội dung tương tự có thể cạnh tranh nhau; hướng dẫn và câu hỏi nằm ở vị trí khác nhau cũng ảnh hưởng cách mô hình diễn giải nhiệm vụ.
Một tài liệu dài thường chứa cả thông tin thiết yếu, phần nền, phụ lục và dữ liệu gây nhiễu. Khi câu hỏi yêu cầu ghép hai điều kiện cách xa nhau, độ khó tăng hơn so với việc chép một giá trị rõ ràng. Vì thế, lỗi trong ngữ cảnh dài có thể đến từ truy xuất, đối chiếu điều kiện, diễn giải hoặc tổng hợp. Không nên quy mọi lỗi cho riêng hiệu ứng vị trí giữa.
Ví dụ, câu hỏi “ngày nào hợp đồng có hiệu lực?” có thể cần đọc điều khoản ký kết và một phụ lục gia hạn. Nếu mô hình tìm đúng ngày ký nhưng bỏ qua điều kiện phê duyệt, câu trả lời vẫn sai. Đặt đoạn liên quan lên đầu có thể giúp một số trường hợp, nhưng không thay thế bước kiểm tra điều kiện và nguồn.
Trong bài viết về Claude 2.1 công bố ngày 6/12/2023, Anthropic mô tả một trường hợp mô hình ngần ngại trả lời khi câu chứa thông tin liên quan bị chèn lạc chỗ trong văn bản dài. Trong thử nghiệm nội bộ của họ, hướng mô hình xác định câu liên quan trước khi trả lời đã cải thiện kết quả truy xuất. Đây là kết quả gắn với Claude 2.1 và thiết lập thử nghiệm năm 2023, không phải một quy tắc chắc chắn cho mọi mô hình.
Có thể áp dụng nguyên tắc đơn giản: ghi rõ nguồn, số trang hoặc mã đoạn; phân tách tài liệu; chỉ rõ câu hỏi và tiêu chí trả lời; yêu cầu mô hình nêu bằng chứng cụ thể trước khi kết luận. Nếu không tìm thấy thông tin, đầu ra nên nói không đủ bằng chứng thay vì tự điền chỗ trống.
Cách sắp xếp này cũng có đánh đổi. Đưa tất cả đoạn quan trọng lên đầu có thể khiến thứ tự thời gian hoặc cấu trúc gốc của tài liệu bị xáo trộn. Nếu hệ thống tự lựa chọn đoạn quan trọng sai, người dùng sẽ không biết thông tin nào bị loại. Vì vậy, cần lưu dấu vết từ đoạn đã chọn trở lại tài liệu ban đầu.
Retrieval-augmented generation (RAG) tìm những đoạn tài liệu liên quan trước khi đưa chúng vào mô hình. Điều này có thể giảm lượng ngữ cảnh gây nhiễu, nhưng tạo ra một điểm lỗi mới: bộ truy xuất có thể bỏ qua đoạn đúng. Nếu câu hỏi cần hai đoạn nằm ở hai tài liệu, chỉ truy xuất một đoạn cũng có thể khiến mô hình trả lời thiếu.
Một hệ thống RAG cần đánh giá riêng retrieval recall — tỷ lệ bằng chứng cần thiết được tìm thấy — và answer correctness — mức độ câu trả lời đúng dựa trên bằng chứng. Khi có câu trả lời sai, phải xác định lỗi xảy ra trước hay sau bước truy xuất. Thay đổi độ dài cửa sổ ngữ cảnh không tự động chữa được cả hai.
Ví dụ, một trợ lý nội bộ được hỏi quy định hoàn trả công tác phí. Bộ truy xuất tìm đúng bảng mức tiền nhưng bỏ qua ngoại lệ dành cho chuyến công tác kéo dài. Mô hình có thể trích dẫn bảng chính xác mà vẫn đưa ra kết luận sai. Đó là lý do cần kiểm tra sự đầy đủ của nguồn, không chỉ sự tồn tại của một đường dẫn trích dẫn.
Đội phát triển có thể tạo một bộ câu hỏi mà đáp án được xác định chắc chắn từ tài liệu, rồi lần lượt đặt đoạn chứa đáp án ở đầu, giữa và cuối đầu vào. Giữ nguyên câu hỏi, mô hình, nhiệt độ lấy mẫu và tổng độ dài càng sát nhau càng tốt. Chạy nhiều lần nếu hệ thống có tính ngẫu nhiên, ghi cả tỷ lệ trả lời đúng và tỷ lệ từ chối khi thiếu bằng chứng.
Nên chia bài kiểm tra thành ba nhóm: tìm một dữ kiện đơn, kết hợp nhiều dữ kiện và phát hiện mâu thuẫn. Nhóm thứ nhất đo khả năng truy xuất; nhóm thứ hai đo tổng hợp; nhóm thứ ba kiểm tra liệu mô hình có nhận ra rằng không thể kết luận từ một đoạn đơn lẻ hay không. Kết quả cần được phân tích theo vị trí, độ dài ngữ cảnh và loại câu hỏi.
Ngoài độ chính xác, ghi lại thời gian đến câu trả lời, số token đầu vào và chi phí. Đưa toàn bộ tài liệu vào một lượt có thể đơn giản về kiến trúc nhưng tốn token; chia nhỏ và truy xuất có thể tiết kiệm hơn nhưng tăng độ phức tạp và rủi ro bỏ sót. Quyết định phải dựa trên đặc điểm tài liệu và mức độ chấp nhận lỗi của ứng dụng.
Nghiên cứu Lost in the Middle kiểm tra các nhiệm vụ và mô hình cụ thể của giai đoạn công bố. Nó không đo mọi kiến trúc mới, mọi ngôn ngữ hoặc mọi loại tài liệu. Thử nghiệm Anthropic năm 2023 là báo cáo của chính nhà cung cấp về Claude 2.1, không phải đối chứng độc lập trên mọi mô hình hiện nay.
Không có một con số cửa sổ ngữ cảnh nào tự bảo đảm câu trả lời chính xác. Cũng không có thủ thuật prompt đơn lẻ nào thay thế kiểm thử bằng chứng, kiểm soát dữ liệu đầu vào và đánh giá chất lượng đầu ra. Với tài liệu pháp lý, tài chính hoặc kỹ thuật quan trọng, người dùng vẫn cần đối chiếu nguồn gốc và quy trình kiểm tra phù hợp.
Kết luận: Cửa sổ ngữ cảnh dài giúp mô hình nhận thêm tài liệu, nhưng câu hỏi quan trọng là mô hình có tìm và sử dụng đúng bằng chứng hay không. Thử nghiệm theo vị trí đoạn liên quan, tách chất lượng truy xuất khỏi chất lượng trả lời và giữ liên kết tới nguồn gốc sẽ cho câu trả lời đáng tin cậy hơn một con số token quảng cáo.