
Tại sao cửa sổ ngữ cảnh (Context Window) lớn không giúp hệ thống RAG của bạn thông minh hơn?
Nhiều người lầm tưởng rằng cửa sổ ngữ cảnh lớn của các mô hình LLM hiện đại sẽ thay thế cho kỹ thuật RAG chất lượng. Tuy nhiên, thực tế cho thấy việc nhồi nhét dữ liệu không giúp mô hình hiểu sâu hơn, mà ngược lại còn làm giảm độ chính xác. Bài viết phân tích tại sao việc tối ưu hóa truy xuất (retrieval) quan trọng hơn kích thước context window.
Tại sao cửa sổ ngữ cảnh lớn không giúp hệ thống RAG của bạn thông minh hơn?
Trong cộng đồng phát triển AI, chúng ta đã từng có một giả định sai lầm: "Nếu LLM có thể đọc 128K tokens, thì việc truy xuất dữ liệu (retrieval) trở nên ít quan trọng hơn". Tại sao phải mất thời gian chọn lọc tài liệu kỹ lưỡng nếu mô hình có thể "nuốt chửng" toàn bộ dữ liệu?
Nghe có vẻ hợp lý, nhưng trong thực tế, nó lại phản tác dụng.

Khi ngữ cảnh càng nhiều, câu trả lời càng tệ
Hãy tưởng tượng bạn hỏi trợ lý AI của mình: *"Tại sao chúng ta lại từ bỏ kiến trúc microservices?"
Hệ thống RAG của bạn trả về 30 tài liệu, bao gồm:
- Các bản ghi quyết định kiến trúc (ADR).
- Một vài ticket Jira.
- Các đoạn thảo luận trên Slack.
- Ghi chú cuộc họp.
- Một trang thuật ngữ.
Tất cả đều liên quan đến chủ đề, nhưng hầu như không có cái nào trả lời trực tiếp câu hỏi. Quyết định thực sự nằm ở một bản ADR duy nhất được viết từ nhiều tháng trước, nơi giải thích rõ các đánh đổi về quy mô đội ngũ, độ trễ, độ phức tạp khi triển khai và chi phí vận hành.
Tuy nhiên, tài liệu đó lại không có nhiều từ khóa trùng khớp với câu hỏi của bạn, nên nó bị "chôn vùi" dưới hàng loạt tài liệu khác. Kết quả là mô hình nhận được 30 tài liệu "có vẻ liên quan" và bắt đầu tổng hợp câu trả lời. Vấn đề nằm ở chỗ: Sự mạch lạc (coherence) không đồng nghĩa với sự trung thực (faithfulness).
Thay vì tìm ra quyết định gốc, mô hình thường tổng hợp một câu trả lời dựa trên các chủ đề lặp đi lặp lại trong các tài liệu được truy xuất. Câu trả lời nghe rất thuyết phục, nhưng lại hoàn toàn sai lệch so với thực tế.
Cửa sổ ngữ cảnh lớn không giải quyết được vấn đề truy xuất
Nghiên cứu đã chỉ ra rằng các mô hình ngôn ngữ lớn gặp khó khăn khi phải xử lý thông tin bị chôn vùi ở giữa các đoạn văn bản dài (ví dụ điển hình là bài báo nghiên cứu "Lost in the Middle").
Kinh nghiệm thực tế cho thấy:
- Sự nhầm lẫn: Đôi khi thông tin bị mất không phải vì ngữ cảnh quá dài, mà vì giai đoạn truy xuất không thể phân biệt được tài liệu chứa câu trả lời thực sự với những tài liệu chỉ đơn thuần thảo luận về cùng một chủ đề.
- Hiệu ứng trung bình cộng: Việc thêm nhiều ngữ cảnh đôi khi chỉ làm cho mô hình lấy trung bình cộng các thông tin, thay vì trích xuất thông tin chính xác nhất.
Chúng ta đã tối ưu hóa sai mục tiêu
Trong một thời gian dài, chúng ta coi RAG như một bài toán "đóng gói": Làm sao để nhồi nhét nhiều đoạn văn (chunks) nhất có thể vào prompt?
Nhưng câu hỏi thực sự cần đặt ra là:
- Tại sao tài liệu này lại xuất hiện ở đây?
- Nó có thực sự cần thiết không?
- Nó giải thích được quyết định, hay chỉ đơn thuần nhắc đến công nghệ đó?
Việc trả lời những câu hỏi này quan trọng hơn nhiều so với việc tăng kích thước cửa sổ ngữ cảnh.
Truy xuất là bài toán lựa chọn
Sự thay đổi lớn nhất không nằm ở việc chuyển từ 8K lên 128K tokens. Nó nằm ở việc nhận ra rằng: Truy xuất không phải là nhồi nhét thông tin, mà là chọn lọc những mảnh ghép thực sự giải thích được câu trả lời.
Cửa sổ ngữ cảnh lớn cực kỳ hữu ích, nhưng chúng không thể bù đắp cho một hệ thống truy xuất yếu kém. Nếu hệ thống truy xuất của bạn không tốt, cửa sổ ngữ cảnh lớn chỉ làm cho những câu trả lời sai lệch trở nên "thuyết phục" hơn mà thôi.
Trong bài viết tới, chúng ta sẽ cùng xem xét một giả định sai lầm khác: "Tài liệu nên được coi là các túi chứa các đoạn văn (bags of chunks)".
Do you like this post?
Upvote to push this post higher on the community feed
