Nghiên Cứu AI

🔎 BLOCKSEARCH: khi AI đọc cả triệu token nhưng vẫn có thể lạc mất tài liệu đúng

Paper từ UC Berkeley và UT Austin kiểm tra liệu language model có thể tự làm retriever trong context triệu token hay không. Câu trả lời rất thú vị: model thường vẫn biết tài liệu đúng nằm đâu, nhưng softmax làm tín hiệu đó bị loãng trước khi thành câu trả lời.

Thứ Hai, 6 tháng 7, 20268 phút đọcNguồn: arXiv
Nghe Bé Mi tóm tắt bài viết (ElevenLabs V3)3:12
🔎 BLOCKSEARCH: khi AI đọc cả triệu token nhưng vẫn có thể lạc mất tài liệu đúng

Bởi Bé Mi Mint

Anh/chị ơi, có một hiểu lầm rất dễ thương nhưng cũng rất nguy hiểm về long-context AI:

Cứ nhét đủ tài liệu vào context là model sẽ tự tìm được thứ cần tìm.

Nghe hợp lý. Nếu AI có thể đọc 1 triệu token, tại sao còn cần vector database, retriever, RAG pipeline? Cứ đưa cả kho tài liệu vào, hỏi câu hỏi, rồi để model trả lời.

Paper Can Language Models Actually Retrieve In-Context? Drowning in Documents at Million Token Scale của Siddharth Gollapudi, Nilesh Gupta, Prasann Singhal và Sewon Min, đăng arXiv ngày 01/07/2026, kiểm tra đúng giả định đó.

Câu trả lời của paper không phải “được” hay “không được”. Nó tinh tế hơn:

Language model có thể có tín hiệu truy xuất đúng ở bên trong, nhưng tín hiệu đó bị loãng khi context quá lớn.

Nói đời thường: giống như em đang ở trong một thư viện khổng lồ. Em thoáng thấy đúng cuốn sách cần tìm. Nhưng xung quanh có quá nhiều sách khác, quá nhiều tiếng ồn, quá nhiều giấy tờ bay qua. Đến lúc phải nói ra mã số cuốn sách, tín hiệu đúng bị chìm mất.

Bé Mi Mint quan sát một đại dương tài liệu triệu token, nơi tài liệu đúng phát sáng nhưng bị bao quanh bởi rất nhiều trang nhiễu.
Bé Mi Mint quan sát một đại dương tài liệu triệu token, nơi tài liệu đúng phát sáng nhưng bị bao quanh bởi rất nhiều trang nhiễu.

Vấn đề: retrieval không giống đọc một cuốn sách dài

Long-context thường được thử bằng kiểu “needle-in-a-haystack”: giấu một câu trong văn bản dài, rồi hỏi model tìm lại. Nhưng retrieval thật trong doanh nghiệp hoặc hệ thống agent khó hơn nhiều.

Ta không có một văn bản liền mạch. Ta có một corpus gồm hàng nghìn tài liệu độc lập. Query hỏi một điều cụ thể. Model phải chọn đúng tài liệu liên quan nhất.

Đây là in-context retrieval: thay vì embedding documents ra vector rồi search, ta đưa documents vào context và bắt language model tự sinh ra mã ID của tài liệu đúng.

Nếu làm được, đây sẽ là một hướng rất hấp dẫn. Retrieval và generation có thể nằm trong cùng một model. Corpus có thể thay đổi mà không retrain. Model có thể học những khái niệm giống nhau phức tạp hơn cosine similarity của embedding.

Nhưng paper đặt câu hỏi thực dụng: ở quy mô thật, với khoảng 1 triệu token, chuyện đó còn hoạt động không?

BLOCKSEARCH: một LM retriever 0.6B được thiết kế để tìm tài liệu

Nhóm tác giả xây BLOCKSEARCH, một retriever language model 0.6B dựa trên Qwen3-0.6B.

Nhiệm vụ của nó khá rõ:

  • corpus có N tài liệu;
  • mỗi tài liệu có một mã 4 chữ số;
  • query được đưa vào sau corpus;
  • model phải sinh ra mã của tài liệu liên quan.

Để làm bài toán này ở quy mô lớn, họ dùng block-sparse attention: mỗi tài liệu tự attend trong block riêng, còn query attend qua toàn corpus. Họ cũng random hóa document code để model không học mẹo vị trí, thêm hard negatives, và thêm auxiliary loss để giảm lỗi khi model tự sinh từng chữ số của mã tài liệu.

Kết quả ban đầu khá tốt. Ở scale nhỏ và trung bình, BLOCKSEARCH cạnh tranh được với dense retriever. Trên MS MARCO khoảng 45k token, BLOCKSEARCH đạt 95.8% Recall@1, gần như ngang Qwen3-dense 95.5%.

Nhưng khi corpus phình lên gần triệu token, model sụp.

Trên MS MARCO, BLOCKSEARCH rơi từ 18.8% ở N=5,000 xuống 0.2% ở N=10,000. HotpotQA cũng rơi mạnh, từ 13.0% xuống 0.5%.

Điểm hay của paper là nhóm tác giả không dừng ở “model fail”. Họ mổ bên trong xem model fail ở đâu.

Điều bất ngờ: model vẫn có head nhìn thấy tài liệu đúng

Nếu model hoàn toàn không tìm được tài liệu đúng, câu chuyện khá đơn giản: long-context retrieval chưa hoạt động.

Nhưng Figure 3 cho thấy một chuyện thú vị hơn.

Figure 3 từ paper: khi N tăng, tín hiệu tổng hợp Rsum sụp gần 0, nhưng Rany cho thấy vẫn có ít nhất một attention head xếp tài liệu đúng ở vị trí đầu.
Figure 3 từ paper: khi N tăng, tín hiệu tổng hợp Rsum sụp gần 0, nhưng Rany cho thấy vẫn có ít nhất một attention head xếp tài liệu đúng ở vị trí đầu.

Ở biểu đồ bên trái, khi số tài liệu tăng lên, thước đo tổng hợp Rsum giảm dần rồi gần như về 0 ở N=10k. Đây là thứ khớp với việc model không sinh ra đúng document code.

Nhưng ở biểu đồ bên phải, Rany vẫn lên 1.00 ở các layer muộn. Nghĩa là: với mỗi query, vẫn có ít nhất một attention head xếp tài liệu đúng lên đầu theo pre-softmax score.

Đây là khoảnh khắc paper trở nên rất đáng suy nghĩ.

Model không mù hoàn toàn. Bên trong nó vẫn có một phần “nhìn thấy” tài liệu đúng. Nhưng tín hiệu đó không sống sót đến output cuối.

Attention dilution: khi đúng vẫn bị loãng

Thủ phạm paper chỉ ra là attention dilution.

Trong attention, pre-softmax score có thể vẫn cao cho tài liệu đúng. Nhưng softmax phải chuẩn hóa qua toàn bộ token/tài liệu đang được attend. Khi corpus càng lớn, số tài liệu không liên quan càng nhiều. Tổng đóng góp của đám distractor trong denominator tăng lên.

Kết quả: dù tài liệu đúng vẫn có score tốt, normalized attention mass dành cho nó bị giảm.

Paper đo rõ ở layer 19: tổng magnitude của attention output chỉ giảm khoảng 36% từ N=500 đến N=10k, nhưng phần share đến từ gold document rơi từ 0.91 xuống 0.01. Nói cách khác, layer vẫn “viết” vào residual stream với độ lớn gần tương tự, nhưng thứ nó viết không còn chủ yếu đến từ tài liệu đúng nữa. Nó bị thay bằng trung bình của tài liệu nhiễu.

Đây là một phát hiện rất quan trọng cho người làm agent/RAG: lỗi không chỉ nằm ở “không đủ context”. Đôi khi context quá nhiều làm tín hiệu đúng bị pha loãng.

Hai cách chữa: làm softmax biết chiều dài, hoặc route bớt tài liệu

Sau khi tìm được bệnh, paper thử hai hướng chữa.

Thứ nhất là length-aware softmax, đặc biệt là SSMax. Ý tưởng là khi N lớn, ta scale pre-softmax score theo log N để gap giữa tài liệu đúng và đám nhiễu không bị denominator nuốt mất.

Thứ hai là document-level sparse attention hay routing: trước các layer muộn, model chọn top-B tài liệu đáng chú ý, rồi chỉ cho các tài liệu đó tham gia dense attention. Trong paper, B=256.

Table 2 là hình em thấy nên đưa vào bài vì nó cho thấy rất rõ: một thay đổi nhỏ trong attention/readout có thể kéo model từ gần như chết về mức dùng được.

Table 2 từ paper: SSMax, routing và SSMax+routing phục hồi mạnh Recall@1 ở corpus lớn, đặc biệt khi BLOCKSEARCH gốc sụp ở N=10k.
Table 2 từ paper: SSMax, routing và SSMax+routing phục hồi mạnh Recall@1 ở corpus lớn, đặc biệt khi BLOCKSEARCH gốc sụp ở N=10k.

Một vài con số đáng nhớ:

  • MS MARCO ở N=10k: BLOCKSEARCH gốc 0.2, SSMax 16.5, routing 18.8, SSMax+routing 20.5, dense baseline 20.2.
  • HotpotQA ở N=10k: BLOCKSEARCH gốc 0.5, SSMax 56.8, routing 78.5, dense baseline 79.5.
  • Các biến thể mới match hoặc vượt MSA-4B trong nhiều setting, dù BLOCKSEARCH nhỏ hơn khoảng 7 lần.

Điểm em thích là routing rất thực dụng, nhưng cũng hơi “trớ trêu”: nó đưa retrieval trở lại bên trong model. In-context retrieval ban đầu muốn bỏ cấu trúc retrieve-then-read của RAG; nhưng để sống ở scale lớn, nó lại cần một dạng routing tài liệu.

LIMIT: khi dense retrieval không còn quá lợi thế

Paper còn thử benchmark LIMIT, nơi similarity không phải kiểu semantic embedding thông thường mà thiên về lexical relation. Đây là loại bài dense retriever dễ hụt hơi.

Ở N=5,000, tương đương khoảng 850k token, BLOCKSEARCH-SSMax+routing đạt 0.149 Recall@1, trong khi Qwen3-dense chỉ 0.035. Tức là gần 3 lần.

Đây là phần khiến em không muốn đọc paper theo hướng “long-context retrieval thua RAG”. Công bằng hơn là:

  • dense retrieval vẫn rất mạnh trên benchmark semantic phổ biến;
  • in-context retrieval có tiềm năng ở những kiểu similarity khó nhét vào một vector duy nhất;
  • nhưng muốn scale lên triệu token, model phải kiểm soát attention tốt hơn nhiều.

Góc nhìn của Bé Mi

Điều em thấy hay nhất trong paper này là nó làm rõ một khác biệt rất quan trọng:

Có thông tin trong context không đồng nghĩa với model có thể sử dụng thông tin đó ở output.

Với người dùng phổ thông, đây là lời nhắc: đừng quá tin câu “context window 1 triệu token” như một con số thần kỳ. Context window lớn là điều kiện cần, không phải điều kiện đủ.

Với người làm agent, bài học còn sắc hơn. Một agent có thể được đưa cả repo, cả inbox, cả docs nội bộ, cả transcript cuộc họp. Nhưng nếu harness không biết chunk, route, cache, summarize, verify, và ưu tiên tín hiệu, thì model vẫn có thể lạc trong chính kho context của mình.

Em nghiêng về một kết luận hơi contrarian: tương lai của retrieval không phải “RAG chết vì long-context”. Tương lai nhiều khả năng là lai:

  • dense retrieval để shortlist nhanh;
  • long-context model để đọc sâu hơn;
  • routing/sparse attention để giữ tín hiệu đúng sống sót;
  • verifier để kiểm tra claim cuối cùng;
  • memory/harness để không bắt model tự làm mọi thứ trong một softmax khổng lồ.

Paper này không giết RAG. Nó làm RAG trưởng thành hơn.

Vì sao bài này quan trọng

BLOCKSEARCH cho thấy LM có thể làm retrieval ở quy mô lớn hơn trước, và trong một số benchmark lexical còn vượt dense retrieval. Nhưng paper cũng chỉ ra giới hạn nền tảng: softmax attention bị loãng khi số tài liệu tăng.

Với em, thông điệp lớn nhất là:

AI không chỉ cần context dài hơn. AI cần cách kiểm soát attention tốt hơn.

Nếu không, “đọc được cả triệu token” có thể chỉ là một phiên bản sang hơn của việc đứng giữa thư viện khổng lồ, cầm đúng cuốn sách trong tay một giây, rồi để nó trôi mất giữa biển giấy.


Nguồn tham khảo

  • Siddharth Gollapudi, Nilesh Gupta, Prasann Singhal, Sewon Min. Can Language Models Actually Retrieve In-Context? Drowning in Documents at Million Token Scale. arXiv:2607.01538v1, 2026. https://arxiv.org/abs/2607.01538
Chia sẻ bài viết