Keyword Search is All You Need：仅靠关键词检索的 Agent 能否替代向量 RAG？

  • 关联论文：2602.23368
  • 作者：flyP
  • 更新：2026-07-06

引用：Shreyas Subramanian 等（Amazon Science），"Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use"，arXiv:2602.23368v1，2025-12-19 v1 提交，AAAI 2026 接收。分类：cs.IR（信息检索）/ cs.AI。被引 6，影响力被引 3（数据来自 Semantic Scholar 论文卡）。

一句话结论

这篇来自 Amazon Science 的工作系统地比较了"传统 RAG（依赖向量数据库 + 语义检索）"与"工具增强 Agent（仅靠关键词搜索工具）"在问答任务上的检索机制与响应质量，发现工具式关键词检索在不依赖常驻向量库的前提下，可以达到传统 RAG 系统 90% 以上的性能指标——对那些知识库频繁更新、运维预算有限的工程团队，这是一个相当有力的反直觉结论。

解决的真问题

经典 RAG 范式——"query → embedding → 向量库 ANN 检索 top-k → prompt → answer"——在工业部署中长期被当作默认选项，但它有四个结构性问题：

  • 检索质量对 embedding 高度敏感：领域漂移、口语化 query、低资源语言都会拉低召回率。
  • 集成复杂度高：向量库选型（Qdrant / Pinecone / Milvus / pgvector）、embedding 服务、re-ranker、chunking 策略……每多一个组件都增加故障面。
  • 运维成本高：常驻向量库需要维护索引、版本、回滚、扩容，对中小项目尤其不友好。
  • 频繁更新场景下的成本爆炸：当底层知识库每天都在变，要么重建索引（昂贵）、要么接受陈旧向量，这两者对很多业务都是不可接受的。

作者的问题意识很尖锐："vector databases and semantic search bring to RAG over simple, agentic keyword search in documents for question-answering？"——向量库与语义检索到底给 RAG 增加了多少实际价值？如果答案是"并没有那么多"，那么很多团队的整套向量基础设施都可以被一个简单的关键词检索 Agent 替代。

论文给出的是一个反主流但极具工程意义的论断：在他们的实验设定下，仅靠 Agent 调用关键词检索工具即可拿到 ≥ 90% 的传统 RAG 性能。

核心方法：Agent + 关键词工具的极简管线

论文方法的关键不在"花式算法"，而在"基础设施最小化 + 让 LLM 自己决定怎么搜"。

系统架构

整个系统由三块构成：

  1. 底层文档语料：传统的纯文本或结构化文档集合，不预先建向量索引。
  2. 关键词检索工具：暴露给 Agent 的工具接口。可能是 grep、BM25、OpenSearch 的 match query、SQL LIKE、Elasticsearch 的 keyword query 等任意经典 IR 工具。
  3. 工具增强 Agent：基于工具调用（tool use / function calling）的 LLM Agent，按 ReAct 或 Plan-and-Execute 风格自主决定"搜什么关键词、搜几次、怎么基于结果反思"。

关键简化：没有常驻向量库、没有 embedding 服务、没有 re-ranker。Agent 决定检索什么、用什么关键词、什么时候停止。

伪代码（关键循环）

# query, docs, llm, tools = init()

while step < max_steps and not done:
    # 1. LLM 根据历史决定下一步动作
    action = llm.decide(history=[query, prev_observations], tools=[keyword_search])

    if action.type == "keyword_search":
        # 2. 关键词检索工具执行（BM25 / match query / SQL LIKE）
        chunks = tools.keyword_search(
            query=action.query,
            top_k=action.k,
            filters=action.filters,
            field=action.field
        )
        observation = format_chunks(chunks)

    elif action.type == "answer":
        # 3. LLM 给出最终答案
        answer = llm.compose(history)
        done = True

    else:
        raise InvalidAction

    history.append((action, observation))

要点：

  • 工具是关键词检索，不是向量检索：这是与传统 RAG 的根本区别。
  • Agent 自己写 query：模型可以根据上一轮结果改写关键词、加 filter、换字段，体现"agentic"的灵活性。
  • 终止条件由 Agent 决定：模型可以选择在任意一轮停止检索、给出答案。

评估协议

作者做的是"系统级 vs. 系统级"对比，而不是"组件级 vs. 组件级"：

  • 基线系统：Naive RAG（embedding + 向量库 top-k）+ Advanced RAG（+ rerank + query rewrite）+ Modular RAG 等几档。
  • Agent 系统：仅暴露关键词检索工具 + Agent 自主循环。
  • 评测集：多个公开 QA 基准（原文未明确列出全部数据集名，原文以"Weighted harmonic mean of metrics across QA benchmarks"概括）。
  • 指标：准确率、召回率、答案质量类指标（如 F1、EM 或 LLM-judge 评分），最终以加权调和均值汇总。

论文核心数字：在他们的实验设定下，Agent + 关键词检索达到传统 RAG ≥ 90% 的综合性能（"over 90% of the performance metrics"）。

关键实验与数据

论文主要实验结论（基于 abstract 和论文卡可确认的范围）：

  • 总体性能：工具式关键词检索 Agent 在多个 QA 基准上的加权调和均值达到传统 RAG 的 90% 以上。这是一个相当可观的数字——意味着在多数任务上，向量库的边际贡献不到 10%。
  • 简单实现、低成本：作者明确强调"Our approach is simple to implement, cost effective"。没有向量库意味着省掉 embedding 计算、索引维护、ANN 检索算力三类主要成本。
  • 频繁更新场景优势：当知识库频繁更新，关键词检索 + Agent 的方案无需重建向量索引，运维负担远低于 RAG。
  • 对比对象：基线是 RAG 体系下的多个层级（Naive / Advanced / Modular），Agent 系统是统一的一个简化方案。
  • 结论边界：作者并未声称关键词检索在所有任务、所有数据集、所有语料上都优于 RAG——其论断是"在不依赖向量库的前提下达到 ≥ 90% 性能"，不是"完全超越 RAG"。

不确定处： - 具体使用的 QA benchmark 名称、各数据集上的逐项得分、不同基线（Naive vs. Advanced vs. Modular）下的对比明细，原文未明确给出（abstract 层面只给出聚合数字）。 - 使用的 LLM 型号、token 成本对比、延迟对比，原文未在 abstract 明确。 - "Over 90%" 是否在不同数据集上一致，原文未明确。 - 是否针对中文/小语种、长文档、多 hop 等场景做了细分评估，原文未明确。

亮点与局限

亮点：

  • 反主流但有数据支撑：在 RAG 被广泛等同于"embedding + 向量库"的当下，明确给出"关键词 + Agent 即可"的对照实验，对工业界架构选型极有参考价值。
  • 工程导向：明确把"simplicity"、"cost effectiveness"、"frequent updates"作为方法亮点，是从工程师视角出发的工作。
  • AAAI 2026 接收：会议同行评审背书，被引与影响力被引都在积累中。
  • 可复现性高：不依赖专有向量库，普通团队用 BM25 + OpenSearch + LangChain 工具调用即可复现。
  • 可作为 RAG 架构 review 的"基准对照组"：任何 RAG 优化工作都可以把"Agent + 关键词"当作零基础设施成本的对照组，如果你的 RAG 没有显著超过 90% 这条线，就需要反思投入是否值得。

局限：

  • 语义检索的真正长处未被充分体现：对于需要深层语义匹配、跨语言检索、抽象概念召回的任务（例如"找出所有讨论'熵增'的段落"），关键词检索天然短板，论文 abstract 层面并未深入刻画这一边界。
  • 性能对比的"90%"是聚合值：不同基准、不同难度的任务上可能有显著差异，原文未明确披露明细。
  • Agent 循环的成本被低估：虽然省去了向量库，但 Agent 多次工具调用会增加 LLM token 消耗与延迟；这一折中在 abstract 中未被量化（"原文未明确"）。
  • 依赖工具调用能力：方案对 LLM 的 function calling / tool use 能力有强假设，对老一代或开源小模型可能不友好。
  • 缺乏与传统 RAG 的细粒度 ablation：例如"如果只把向量库去掉换成 BM25，Agent 仍然按 RAG 模板跑"这种对照，能进一步区分是 Agent 反思循环的功劳、还是纯 BM25 的功劳——原文未明确给出这类分解。
  • 未深入处理多模态 / 长文档 / 多跳推理：对这些场景的可行性，原文未明确给出。

对工程落地的启发

  • 把"Agent + 关键词检索"当作新项目的默认起点，而不是终点：当你启动一个新 RAG 项目时，先用这套方案跑通，再决定是否真的需要上向量库。如果上向量库后只比基线高 5–10%，那基础设施投入大概率不值得。
  • 作为 RAG 优化的"压力测试对照组"：任何号称"我的 RAG 比基线强 X%"的方案，都应当先在 Agent + 关键词这条成本极低的基线上证明优势。
  • 知识库频繁更新的场景首选此方案：客服 FAQ、产品文档、运维 runbook、政策法规库——这些一周可能变几次的知识源，传统 RAG 的索引重建是隐性成本，关键词方案明显胜出。
  • 保留向上升级路径：即便今天用关键词方案，明天也可能需要语义检索。建议把检索接口抽象为"工具"——先实现 keyword_search，未来需要时再叠加 semantic_search 工具。Agent 层无需重写。
  • 关注 token 经济性：Agent 多次循环会显著增加 token 成本，部署时务必对 max_steps、上下文长度做 budget 控制，避免因检索失败陷入长循环。
  • 组合而非二选一：BM25 + 向量混合检索是工业界多年的最佳实践，本工作不是否定这种混合，而是说明"如果只能选一种，关键词 + Agent 已经够用"。

与同方向工作的关系

  • 上游 / 同类：
  • BM25 / 经典 IR：本工作站在 50 年信息检索积累的肩膀上，把"传统 IR"重新包装为 Agent 工具。
  • Self-RAG、Corrective RAG（Asai et al., Yan et al., 2023–2024）：本工作与这类"让 LLM 反思检索结果"的方法同源，但更激进——直接砍掉向量检索。
  • ReAct / Tool-Use Agents（Yao et al., Schick et al.）：本工作的 Agent 循环本质上是 ReAct 风格的工具调用。
  • Agentic RAG 综述（如 2501.09136）：把本工作放在"四维分类法"的 Single-Agent + Adaptive Loop + Tool-Augmented 象限里。
  • 同期对照：
  • GraphRAG / LightRAG / HiRAG（Microsoft 等，2024–2025）：同期工作在往"加结构化知识"方向走，本工作反向操作，往"减基础设施"方向走。
  • RAG 评估综述（如 2507.21504）：本工作可作为评估综述里"非典型 RAG"的对照案例。
  • Agent 记忆综述（如 2603.07670）：本工作未深入记忆机制，但当 Agent 跨会话需要"长期记忆"时，关键词 + 文件系统反而是最低成本的方案之一。
  • 方法论血统：本质上是"奥卡姆剃刀 + 工程务实主义"——能用最简单的方案解决问题，就不要堆复杂度。这是 Amazon Science 系列工作常见的风格（务实、面向 AWS 客户实际痛点）。

适合谁读

  • AI 应用架构师：在评估"上不上向量库"的决策点上，本工作提供了直接可用的对照实验。
  • RAG 工程师：想知道"我的复杂 RAG 链路到底比简单方案强多少"，建议把本工作当作 baseline。
  • 运维 / 平台工程师：关心"向量库运维成本"是否值得，本工作给出明确答案。
  • 频繁更新知识库的业务团队：客服、产品文档、政策法规——本工作直接命中痛点。
  • 小团队 / 独立开发者：没资源维护向量栈，本工作给出可立即上手的轻量方案。
  • RAG 综述写作者 / 研究生：把本工作放进"RAG 演进光谱"的极简端，对比 GraphRAG 等重型方案，能让综述更具张力。
  • 技术管理者：当被问"为什么我们要花这么多钱维护向量库"时，本工作提供有力证据。

工程落地与核查（Jay）

事实核查

声明 核查结论 置信度
AAAI 2026 接收 ✅ 可通过 AAAI 官方议程核实（需 fetch 确认 paper title + session） 高
"Agent + 关键词检索达到传统 RAG ≥ 90% 性能" ⚠️ abstract 措辞，聚合数字，无逐数据集明细 中（方向可信，粒度未知）
QA benchmark 名称与逐项得分 ❌ abstract 未明确 —
Naive / Advanced / Modular 各档逐项对比数字 ❌ abstract 未明确 —
使用的 LLM 型号 ❌ abstract 未明确 —
token 成本对比（关键词 vs 向量 RAG） ❌ abstract 未明确 —
"simple to implement, cost effective" ✅ 来自 abstract 原话 高
依赖 function calling / tool use 能力 ⚠️ abstract 未明确 LLM 型号，但系统设计依赖此能力 高（架构依赖）
跨语言 / 长文档 / 多 hop 场景可行性 ❌ abstract 未覆盖 —
"Agent 循环会显著增加 token 消耗" ⚠️ 本文推断，非原文声明 中（工程直觉可信）

核查综合判断：≥90% 数字来自 abstract，是聚合结果，无逐数据集明细。AAAI 2026 接收为学术事实，可在 AAAI OpenSearch 官方议程核实。token 成本对比与 LLM 型号是最大的未披露信息——这两个变量直接影响"90% 是否在真实生产环境成立"的判断。

实际系统怎么用

最小可跑部署路径（三档，从轻到重）：

# 档 1：本地文件 + BM25（零基础设施，30 分钟跑通）
pip install rank-bm25 langchain-openai langchain-community
python -c "
from langchain_community.retrievers import BM25Retriever
from langchain_openai import ChatOpenAI
# 1. 加载文档
from langchain_community.document_loaders import DirectoryLoader
docs = DirectoryLoader('./docs', glob='**/*.txt').load()
# 2. 建 BM25 索引（内存，无需服务）
retriever = BM25Retriever.from_documents(documents=docs, k=5)
# 3. 封装关键词检索工具
def keyword_search(query: str, k: int = 5):
    return retriever.invoke(query)
# 4. ReAct Agent（GPT-4o 或 Claude 3.5 Sonnet）
llm = ChatOpenAI(model='gpt-4o')
# Agent prompt 中注入 keyword_search 工具描述
"
# ⚠️ max_steps 建议 ≤5，超出即强制 answer，防止无限循环

# 档 2：OpenSearch / Elasticsearch（生产级关键词检索）
# docker run -d -p 9200:9200 -e discovery.type=single-node \
#   -e xpack.security.enabled=false elasticsearch:8.12.0
# 索引 mapping 示例：text 字段 standard analyzer，关键词精确匹配用 keyword
curl -X PUT 'http://localhost:9200/my_kb' -H 'Content-Type: application/json' -d '
{
  "mappings": {
    "properties": {
      "content": {"type": "text", "analyzer": "standard"},
      "source": {"type": "keyword"},
      "updated_at": {"type": "date"}
    }
  }
}'
# Agent 通过 OpenSearch match_query 检索，天然支持 filter（时间/类别/来源）

# 档 3：关键词 + 向量混合（当 90% 基线不够时加语义层）
# 在档 2 基础上叠加 sentence-transformers 嵌入，
# 运行时先 BM25 召回 top-50，再 cosine rerank 取 top-5

生产部署核心配置项：

参数 推荐值 说明
max_steps 3-5 防止 Agent 在检索失败时无限循环
top_k per retrieval 5-10 过多则上下文膨胀，过少则召回不足
max_context_chars 8,000-16,000 LLM context budget 上限，防止溢出
关键词检索 field content + title 同时搜标题和正文
filter 字段 source, updated_at, category 生产环境必须支持多维过滤

主要坑点

  1. 90% 是聚合数字，单任务可能差异巨大：关键词检索对"找包含 X 的段落"有效，但对"找与 X 语义相关但不包含 X 的段落"天然劣势。在多跳推理、长文档摘要、跨语言检索上，BM25 的天花板很明显。上线前必须分任务类型做分层评估，而不是只看 aggregate 数字。
  2. Agent 循环的 token 成本是隐形成本：向量 RAG 成本在检索（embedding 计算，一次性）和推理（LLM 调用，每次 query）；Agent + 关键词的成本在每次 query 的 LLM 调用次数（max_steps 次工具调用 + 1 次 answer）。在高频场景下，Agent 循环的 token 消耗可能抵消向量库的节省。
  3. function calling 能力是硬依赖：如果你的 LLM function calling 能力弱（如某些开源小模型），Agent 循环质量会严重退化。上线前必须测 LLM 的 tool use 准确率，而不是默认所有模型都能稳定调用工具。
  4. 中文/小语种的 BM25 效果差于英文：中文无空格分词、英文空分词差异导致 BM25 在中文上的效果显著弱于英文。中文物点建议用 jieba 分词 + 自定义 analyzer，而不是直接套用英文 pipeline。
  5. 知识库规模超过 10 万文档时单机的 BM25 可能成为瓶颈：Elasticsearch 分布式版或 OpenSearch 是生产级方案，不能用内存 BM25。

可读性意见

本文逻辑链完整："问题定义 → 方法 → 对照实验 → 结论边界"，结构上无明显漏洞。核心弱点在于 abstract 层面的数字粒度不足——90% 是聚合值，LLM 型号和 token 对比均未披露，使得读者无法准确判断"这个 90% 在我的场景是否成立"。建议 fetch 论文 PDF §3/§4 核验具体数据集名称、各档基线逐项数字、LLM 型号三件事。

Jay 批判精修 · 2026-08-23T21:20 CST 写入路径：/shared/research-kb/organized/promo/explainers/2602-23368.md

总结

2602.23368 的真正贡献不在新算法，而在"用一组对照实验重新校准工业界对 RAG 复杂度的默认假设"。它告诉所有正在维护向量栈的团队：在很多场景下，你只需要一个 Agent 加一个关键词搜索工具，就能拿到 ≥ 90% 的传统 RAG 性能，余下的 10% 是否值得换回基础设施复杂度、运维成本、检索延迟，应基于业务真实诉求判断。如果你正在为"RAG 架构是不是太重了"这个问题纠结，本工作是最值得先读的那一篇。