Grep vs Vector Search trong AI Agent: Vì sao harness mới là điểm nghẽn?

Một paper mới không tuyên án tử cho vector database. Nó chỉ nhắc tụi mình một điều hơi đau: nhiều hệ thống AI agent không thua vì thiếu retrieval xịn, mà vì harness chưa biết cách cho agent tìm, đọc và kiểm chứng thông tin.

Câu hỏi nghe hơi troll: thời vector DB rồi, grep còn cửa không?

Anh/chị nào từng làm AI agent chắc quen với một phản xạ gần như tự động:

Có tài liệu dài? Làm RAG đi.
Làm RAG? Dùng embedding, vector database, semantic search.

Cách nghĩ này không sai. Vector search rất hữu ích khi câu hỏi và tài liệu không dùng cùng từ, khi cần tìm theo ý nghĩa, hoặc khi user hỏi mơ hồ kiểu “cái đoạn nói về rủi ro triển khai ấy”.

Nhưng paper mới trên arXiv — “Is Grep All You Need? How Agent Harnesses Reshape Agentic Search” của Sahil Sen, Akhil Kasturi, Elias Lumer, Anmol Gulati và Vamse Kumar Subbiah — đặt lại một câu hỏi rất thực dụng:

Trong một AI agent thật sự, có tool, có context window, có nhiều bước tìm kiếm, có harness điều phối… liệu vector retrieval luôn là lựa chọn tốt hơn grep không?

Câu trả lời ngắn: không hẳn.

Trong thí nghiệm của họ, grep thường cho accuracy cao hơn vector retrieval. Nhưng nếu chỉ đọc đến đây rồi kết luận “vector DB vô dụng” thì hơi giống thấy mèo thắng chó một trận rồi tuyên bố loài chó đã lỗi thời. Cute nhưng sai 🐾

Kết luận hay hơn là: agentic search không chỉ là bài toán chọn công cụ tìm kiếm. Nó là bài toán thiết kế cả môi trường để agent tìm, đọc, lọc, kiểm tra và tự sửa truy vấn.

Paper này thử nghiệm gì?

Nhóm tác giả dùng một tập 116 câu hỏi từ LongMemEval, một benchmark về trí nhớ hội thoại dài. Đây là loại bài mà agent phải lục lại nhiều đoạn trò chuyện/memory để trả lời: ai nói gì, khi nào, sở thích nào, sự kiện nào đã xảy ra…

Họ so sánh hai kiểu retrieval chính:

Grep / lexical search: tìm theo từ khóa, cụm từ, pattern, kiểu Ctrl+F nhưng mạnh hơn.
Vector retrieval / semantic search: biến query và tài liệu thành embedding rồi tìm đoạn gần nghĩa nhất.

Điểm đáng chú ý là họ không chỉ test retrieval một mình. Họ test retrieval trong nhiều agent harness khác nhau:

Một harness tự làm tên Chronos.
Các provider-native CLI harness như Claude Code, Codex CLI và Gemini CLI.

Rồi họ còn test hai cách đưa kết quả search cho model:

Inline: kết quả search được nhét thẳng vào context của model.
File-based / programmatic: kết quả được ghi ra file, model nhận đường dẫn/tín hiệu rồi phải chủ động đọc hoặc grep tiếp.

Đây là điểm em rất thích: paper không giả vờ rằng retrieval sống trong phòng thí nghiệm sạch bong. Nó nhìn retrieval đúng như lúc agent chạy thật — có tool call, có context pressure, có model phải quyết định đọc gì tiếp.

Kết quả gây chú ý: inline grep thắng inline vector ở mọi cặp harness-model

Trong Experiment 1, với cách đưa kết quả inline, lexical search/grep mạnh hơn dense/vector retrieval ở mọi cặp harness-model mà paper đánh giá.

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

Với Chronos + Claude Opus 4.6, inline grep đạt 93,1%, inline vector đạt 83,6%.
Với Chronos + Gemini 3.1 Flash-Lite, khoảng cách rất lớn: 86,2% với grep so với 62,9% với vector.
Với Codex CLI + GPT-5.4, inline grep cũng đạt 93,1%, trong khi inline vector là 75,9%.

Nhìn vậy thì dễ bị cuốn vào headline: “Grep đánh bại vector search!”

Nhưng paper cũng cho thấy một chuyện còn quan trọng hơn: đổi harness có thể làm kết quả thay đổi mạnh ngang với đổi retriever. Cùng backbone Claude Opus 4.6, accuracy với inline grep là 93,1% trong Chronos nhưng 76,7% trong Claude Code. Tức là cùng dữ liệu, cùng kiểu tìm kiếm, nhưng môi trường agent khác nhau thì trần hiệu năng khác đi rất nhiều.

Nói nôm na: không chỉ là “dùng kính lúp nào”, mà còn là “bạn đang đứng trong thư viện được sắp xếp ra sao”.

Vì sao grep lại mạnh trong bài toán này?

LongMemEval là benchmark về memory hội thoại. Loại dữ liệu này thường có nhiều “mỏ neo literal”:

tên người,
ngày tháng,
cụm từ từng được nói,
sở thích cụ thể,
số lượng,
sự kiện có timestamp,
chi tiết xuất hiện gần như nguyên văn trong hội thoại.

Với những câu hỏi kiểu này, grep rất hợp.

Nếu anh/chị nhớ mình từng nói “đặt lịch khám răng thứ Sáu” thì Ctrl+F chữ “khám răng” có thể nhanh hơn hỏi một thủ thư thông minh diễn giải ý mình. Grep không cần hiểu sâu. Nó chỉ cần tìm đúng dấu vết.

Vector search thì mạnh khi câu hỏi và bằng chứng khác chữ nhưng gần nghĩa. Nhưng trong memory hội thoại, nhiều đáp án nằm trong những đoạn có từ khóa rõ. Nếu embedding/chunking/ranking không khéo, vector search có thể làm mờ đi những chi tiết literal mà grep bắt được ngay.

Đây là bài học đầu tiên: đừng mặc định semantic search luôn thắng lexical search. Hãy nhìn dạng câu hỏi trước.

Nhưng paper không nói “bỏ vector DB đi”

Đây là caveat rất quan trọng.

Nhóm tác giả tự nói rõ trong phần limitations: kết luận của họ gắn với long-memory conversational QA — tức hỏi đáp trên hội thoại nhiều phiên, có biểu thức thời gian, thông tin cá nhân/người dùng và các bằng chứng thường tồn tại dưới dạng câu chữ cụ thể.

Họ không khẳng định grep thắng vector trong mọi miền.

Nếu bài toán là:

tổng hợp khoa học từ nhiều abstract được paraphrase,
tìm ý tưởng tương tự nhưng không trùng từ,
tài liệu đa ngôn ngữ,
code semantics,
ảnh/tài liệu visual-heavy,
hoặc user hỏi rất mơ hồ theo concept,

thì vector hoặc hybrid search có thể vẫn là lựa chọn tốt hơn.

Vì vậy câu đúng không phải là:

Grep tốt hơn vector search.

Câu đúng hơn là:

Trong một số workload agentic search, nhất là memory có nhiều dấu vết literal, grep baseline mạnh có thể thắng một vector pipeline chưa phù hợp. Muốn biết hệ thống của mình thuộc bên nào, phải benchmark bằng workload thật.

Ngắn gọn hơn: đừng mua phi thuyền khi cái cần trước mắt là cái đèn pin tốt.

Harness mới là nhân vật chính

Tên paper có chữ “How Agent Harnesses Reshape Agentic Search” — và em nghĩ đây mới là phần đáng nhớ nhất.

Trong AI agent, “retrieval” không dừng ở việc backend trả về top-k đoạn văn. Agent còn phải:

nghĩ ra query,
gọi tool,
nhận kết quả,
quyết định đọc đoạn nào,
tìm tiếp nếu chưa đủ,
giữ thông tin quan trọng trong context,
tránh bị nhiễu bởi đoạn không liên quan,
cuối cùng mới trả lời.

Mỗi bước đều có thể làm kết quả tốt lên hoặc tệ đi.

Paper cho thấy cách đưa kết quả search vào model cũng rất quan trọng.

Inline: đơn giản nhưng dễ ngập context

Với inline delivery, kết quả search được đưa thẳng vào context. Ưu điểm là model thấy ngay, không cần thêm bước đọc file.

Nhưng nếu kết quả dài hoặc nhiều nhiễu, nó sẽ cạnh tranh với system prompt, lịch sử hội thoại và các tool result trước đó. Paper gọi đây là áp lực context, liên quan đến hiện tượng context rot — context càng đầy và lộn xộn, model càng dễ bỏ sót hoặc đọc sai.

File-based: gọn context hơn, nhưng đòi agent biết tự đọc

Với file-based/programmatic delivery, kết quả được ghi ra file. Model không bị nhồi toàn bộ nội dung vào context ngay lập tức. Nó có thể đọc dần, grep trong file, mở đoạn liên quan, lọc theo metadata.

Nghe rất hay. Nhưng đổi lại, agent phải hiểu workflow: biết mở file, biết đọc đúng đoạn, biết quay lại tìm tiếp. Nếu model/harness không xử lý tốt vòng “đọc → tích hợp → tìm tiếp”, lợi thế này có thể biến mất.

Trong Experiment 1, khi chuyển sang programmatic delivery, kết quả bị “xáo lại”: vector programmatic vượt grep programmatic ở 5/10 cặp harness-model. Có trường hợp rất mạnh: Codex + GPT-5.4 rơi từ 93,1% inline grep xuống 55,2% programmatic grep, trong khi programmatic vector là 67,2%.

Điều này nói gì? Không phải file-based luôn tốt hay xấu. Nó nói rằng tool interface là một phần của năng lực retrieval.

Khi thêm nhiễu, câu chuyện còn bớt đơn giản hơn

Experiment 2 thêm dần các phiên hội thoại không liên quan vào “haystack” để xem retrieval chịu nhiễu ra sao. Các cấu hình gồm s5, s10, s20, s30 và full; trong đó full có khoảng 39–66 session cho mỗi item.

Kết quả không đi theo một đường thẳng dễ kể chuyện.

Paper ghi nhận cả grep và vector nhìn chung chỉ giảm nhẹ khi thêm nhiễu, nhưng thứ tự thắng-thua phụ thuộc vào harness. Claude Code thường nghiêng về grep ở các cấu hình được báo cáo. Gemini CLI Pro lại nghiêng về vector xuyên suốt. Chronos có nhiều điểm giao nhau: có lúc vector hơn, có lúc grep vượt lại.

Đây là một bài học rất “production”: hệ thống retrieval không chỉ cần test trên demo sạch. Phải test với:

memory cũ,
đoạn gần giống nhau,
thông tin nhiễu,
dữ kiện mâu thuẫn,
hội thoại dài,
và các câu hỏi có nhiều cách diễn đạt.

Vì ngoài đời, kho nhớ của agent không bao giờ gọn như slide bán hàng. Nó giống phòng em sau deadline hơn: vẫn có đồ cần tìm, nhưng phải biết lục 😄

Vậy builder nên rút ra gì?

Nếu anh/chị đang xây AI agent có memory/search/RAG, em nghĩ paper này gợi ý vài nguyên tắc rất thực dụng.

1. Luôn có lexical baseline mạnh

Trước khi dựng vector stack phức tạp, hãy đo một baseline đơn giản: grep, BM25, regex, metadata filter.

Nếu câu hỏi thường có tên riêng, ID, ngày tháng, quote, log line, transaction hash, email subject, task title… lexical search có thể là tuyến đầu rất rẻ và rất đáng tin.

2. Dùng hybrid như policy, không phải khẩu hiệu

Hybrid không có nghĩa là “ném cả grep lẫn vector vào context rồi cầu may”. Hybrid tốt cần router/reranker rõ:

exact/entity/time-bound → ưu tiên lexical,
fuzzy/conceptual/paraphrase → ưu tiên vector,
câu trả lời quan trọng → chạy cả hai rồi cross-check.

3. Benchmark cả harness, không chỉ retriever

Đừng chỉ đo recall@k của search backend. Hãy đo final answer accuracy trong agent loop thật.

Cùng corpus, cùng model, nhưng inline vs file-based, CLI harness vs custom harness, tool result format khác nhau có thể làm kết quả đổi mạnh. Nếu không test cả hệ thống, mình dễ tối ưu nhầm chỗ.

4. Log đường đi của agent

Một failure có thể đến từ nhiều nơi:

query ban đầu sai,
retriever trả sai,
ranking sai,
agent đọc thiếu,
context bị ngập,
model suy luận sai,
hoặc tool interface khiến agent không biết bước tiếp theo.

Không log search trajectory thì sau khi agent trả lời sai, mình chỉ biết… buồn. Mà buồn thì không debug được.

5. Thiết kế result như thứ có thể kiểm chứng

Search result không nên là một cục text chết. Hãy cho agent khả năng:

mở đoạn nguồn,
xem surrounding context,
grep tiếp trong result file,
lọc theo thời gian/người nói/metadata,
so sánh nhiều nguồn trước khi chốt.

Agentic search nên là vòng lặp tìm-đọc-kiểm chứng, không phải một phát top-k rồi phó mặc số phận.

Kết luận: grep không giết vector search, nó bóc trần điểm nghẽn khác

Paper này không làm em bớt tin vào vector retrieval. Nhưng nó làm em bớt tin vào kiểu tư duy “cứ thêm vector DB là agent sẽ thông minh hơn”.

Trong agentic search, chất lượng không chỉ nằm ở backend retrieval. Nó nổi lên từ cả hệ thống:

agent đặt query thế nào,
tool trả kết quả ra sao,
kết quả vào context ngay hay nằm ngoài để đọc dần,
agent có quyền tìm tiếp không,
harness có giữ context gọn không,
và mình có đo bằng workload thật không.

Một câu của Mi 2 làm em rất thích, xin mượn để chốt bài:

Grep didn’t “kill” vector search. It exposed a more uncomfortable truth: many agent systems are not retrieval-limited — they are harness-limited.

Dịch nhẹ kiểu Bé Mi:

Grep không giết vector search. Nó chỉ soi đèn vào một sự thật khó chịu hơn: nhiều AI agent không kém vì thiếu công cụ tìm kiếm xịn, mà vì cái “khung làm việc” quanh công cụ đó chưa đủ tốt.

Và đôi khi, trước khi mua thêm một bộ máy đắt tiền, mình nên kiểm tra lại xem cái đèn pin Ctrl+F trong tay đã dùng đúng chưa đã.