在智能体记忆测试中，grep优于向量搜索，且结果呈现方式同样重要。
对116道LongMemEval题目的研究显示，grep在向量检索之前更为有效，但结果呈现方式对准确率的影响与检索器本身相当。由此可得出什么结论？
基于检索增强的系统长期以来一直基于一个信念：向量检索优于关键词搜索，因为它能够捕捉语义。当用户查询“关于季度收益的文档”时，即使这两个短语没有共同的词汇，系统也能找到“Q3营收报告”，因为嵌入空间会将它们视为相近的。这一信念推动了大量基础设施的投资，从Pinecone和Weaviate到Chroma和Qdrant。早期关于密集段落检索的研究表明，它在开放领域问答任务中的表现优于稀疏的BM25算法，该领域接受了这一结果，向量检索也因此成为默认选择。
2026年的一项研究设计了不同的实验。实验中，智能体需要完成LongMemEval基准测试中的检索任务，该测试要求智能体通过搜索长对话历史来回答问题。测试将简单的精确字符串匹配算法grep与向量检索技术进行了对比，测试平台包括名为Chronos的自定义工具，以及Claude Code、Codex和Gemini CLI等厂商原生的命令行工具。
在所有测试平台上，grep在准确率方面均优于向量检索，而不仅仅是在某一个平台上。
简述
- 测试设置：116道LongMemEval题目，grep与向量检索对比，四种测试平台，相同的对话数据。
- 主要结果：在所有测试场景中，当结果直接显示时，grep的准确率均高于向量检索。
为何grep适合处理记忆相关问题
其机制很简单。LongMemEval会询问诸如在特定日期的对话中某人提到的最喜欢的餐厅是什么，或是某人推荐的书籍标题之类的问题。每个答案都是历史记录中的某条特定字符串。
向量检索会将问题进行嵌入处理，找出嵌入值相近的对话片段并返回这些片段。问题在于，语义相近并不等同于包含确切的事实。关于食物的内容在嵌入空间中会与“最喜欢的餐厅”相近，虽然它可能从未提及具体餐厅名称，但依然会排名靠前，且不包含任何答案。
使用grep搜索“restaurant”会返回所有包含该词的片段，其中也包括提到最喜欢的餐厅的片段。grep是精确匹配的，而向量检索是近似匹配的，对于需要确切事实的查询而言，近似匹配只会增加干扰信息。
Vector retrieval: high recall on semantically related segments
lower precision on exact-fact queries
noise from semantically similar but fact-absent segments
grep: perfect precision on string matches
lower recall on paraphrased or implicit facts
no noise from semantic neighbors
该基准测试的题目设计要求精确召回，因此评估结果更偏向于精确的字符串匹配。这并不能证明 grep 通常比向量检索更优，只能说明是任务类型决定了哪种方法更胜一筹。值得探讨的问题是，在实际的应用程序部署中，检索任务的实际组合是怎样的，以及在这种组合下哪种方法会更具优势。
工具包效应
更重要的发现并非是对向量进行 grep 检索，而是检索框架的作用。在相同的检索方法、相同的数据和相同的问题条件下，准确率会因检索框架的不同而出现很大差异。报告中的数据展示了这一差距：在 Chronos 环境下，Claude Opus 模型的准确率为 93.1%，而在 Claude Code 环境下仅为 76.7%，因此更换检索框架所带来的提升幅度，大致相当于在固定框架内更换检索工具所带来的提升幅度。在 Chronos 环境下使用 Gemini 3.1 Flash-Lite 时，grep 检索与向量检索之间的最大差距为 86.2% 对 62.9%。
检索框架具有四项功能：
- 它使用查询语句调用检索工具。
- 它接收检索结果。
- 它将这些结果呈现给模型。
- 模型基于这些结果进行推理以给出答案。
对于某种特定的检索方法，第一步、第二步和第四步在所有情况下都是相同的。第三步则有所不同，而结果呈现方式会影响模型对这些结果的处理方式。呈现方式包括以下几种：
- 格式：排序列表、仅显示最佳结果或将所有结果合并显示。
- 上下文：每个检索结果是否包含其来源、时间戳及周围文本。
- 高亮显示：是否标出相关部分，还是让模型在内容中自行查找。
- 过滤：是否丢弃置信度较低的检索结果，还是全部显示。
目前还没有人对这些选项进行标准化，各家提供商的命令行界面都是自行设计的。交付方式被证明至关重要：直接在原文中返回结果更有利于使用 grep，而将结果以文件形式传递则让模型需要单独读取，从而改变了比较结果——在大约一半的测试组合中，向量检索的表现优于 grep。有一组 Codex 设置在使用直接返回结果的 grep 时准确率为 93.1%，而将 grep 结果以文件形式传递后则降至 55.2%。
如果是这样，那些在保持测试环境不变的情况下比较检索方法的研究可能测量的其实是错误变量。在较差的测试环境中使用更好的检索器，也有可能输给在较好环境中使用较差检索器的结果。
混入干扰内容
第二个实验从正确的对话段落开始，逐渐加入越来越多的无关对话历史，然后随着干扰内容的增加来监测准确率的变化。
随着干扰项的增加，两种方法的准确率都会下降，这是意料之中的。不过两者的曲线表现有所不同：在针对精确事实的查询中，grep的性能下降更为平缓。当相关段落中包含查询字符串时，无论周围有多少干扰项，grep都能找到它，因为这些干扰项与查询字符串不匹配，因此不会出现在结果中。
向量检索的性能下降速度更快。那些在语义上与查询相似的干扰项确实会出现在结果中，因此随着干扰项增多，顶级结果中有用结果的比例就会下降，模型不得不从更加杂乱的候选项中筛选出答案。
Accuracy = f(retrieval_precision × harness_quality)
grep retrieval precision: high for exact facts, stable with distractors
vector retrieval precision: moderate, degrades with semantically similar distractors
对于那些需要处理大规模、混合上下文存储、长对话历史、多种文档类型且相关性不均的智能体而言，在需要精确事实的任务中，这种抵御干扰的能力确实具有重要的实际优势。
这对检索研究意味着什么
那些比较密集检索与稀疏检索、嵌入模型或重排策略的论文，通常会将检索框架视为常数，仅改变检索器本身。但这里的研究结果表明它并非常数，而是会与检索方法相互影响。为向量检索优化的检索框架可能无法很好地呈现grep的搜索结果，反之亦然。
有可能现有的检索方法是为那些偏向向量检索方式的框架而优化的。绝对比较结果或许仍然成立，但相对排名则未必如此。
在实际应用中，构建代理式RAG系统的团队会花费大量精力挑选嵌入模型、向量数据库供应商以及相似度度量方法，却很少有团队在用于向模型展示检索结果的工具上投入同等精力。这些情况表明，这类工具至少应与检索组件获得同等程度的工程关注，但目前的工程实践尚未跟上这一需求。
谨慎解读这些结果
这类技术很可能无法获得应有的重视，但这并非因为其效果不佳。问题在于，对于一个以向量搜索为基础发展的行业而言，这类工具使用起来很不方便，因为有时简单搜索就能得到结果，同时人们也低估了工具设计的重要性。
这些内容仍需仔细阅读。LongMemEval具有特定的任务分配方式，更侧重于精确事实检索，而grep在该领域的优势并不意味着它在所有场景下都能胜出。在包含大量意译的内容、跨语言检索以及概念级查询等任务中，语义检索的表现更为出色。该研究还分析了逐字记录的多会话聊天数据，但并未涉及混合检索或更强大的词汇基线方法。
关键点并非要使用grep，而是要根据检索任务的特点选择合适的检索方法，并像设计检索器一样精心设计配套系统。目前这两种做法都尚未成为标准，但都应当如此。
针对您自身系统的问题
在您的生产系统中的智能检索任务中，有多少比例需要精确的事实检索，又有多少比例需要语义概念匹配？您上一次仔细检查过结果呈现方式是在何时？是否像选择嵌入模型时那样用心对待？
相关阅读
- 智能 RAG：让大语言模型决定何时何地检索 —— 为什么静态 RAG 无法处理多跳查询和时效性强的问题，以及 LangGraph 智能体如何在 Qdrant 和网络搜索之间进行路由，同时附有相关限制与注意事项。