你的 RAG 系统是不是太重了?——Amazon Science 说:扔掉向量库,只靠关键词搜索就够用

关联论文：2602.23368

"query → embedding → 向量库 ANN 检索 top-k → prompt → answer"——这是过去三年所有 AI 工程师闭着眼都能写出的 RAG 默认公式。但如果你正维护着一个向量库(Pinecone、Qdrant、Milvus、pgvector 任选其一),花了钱、花了人、每天为索引重建和版本回滚焦虑,那这篇来自 Amazon Science 的工作(arXiv:2602.23368,AAAI 2026 接收,被引 6,影响力被引 3)可能会让你松一口气:

不用向量库,只用关键词搜索 + 一个能调用工具的 Agent,就能在多数 QA 任务上达到传统 RAG 90% 以上的性能。

这不是民科野路子,这是 Amazon Science 在 AAAI 2026 同行评审通过的工作。它的工程含义很直接——你的 RAG 系统可能从头到尾都不需要那个向量库。

一、传统 RAG 的四个结构性痛点

在你决定是否真的需要向量库之前,先承认这四件事:

embedding 对领域漂移、口语化 query、小语种极敏感——同一段 query,改个表述 embedding 召回率掉一半是常事。
集成复杂度高——向量库选型、embedding 服务、re-ranker、chunking 策略……每多一个组件都多一个故障面。
运维成本高——常驻向量库需要索引维护、版本管理、回滚预案、扩容,中小项目尤其不友好。
频繁更新场景下成本爆炸——当你的知识库每天都在变(客服 FAQ、产品文档、政策法规、运维 runbook),要么重建索引(昂贵),要么接受陈旧向量(业务不可接受)。

这四个痛点不是"调调 embedding 模型"能解决的——是范式本身的代价。

二、极简方案:Agent + 关键词工具

整个系统由三块构成:

底层文档语料:纯文本或结构化文档,不需要预先建向量索引。
关键词检索工具:暴露给 Agent 的工具接口,可以是 grep、BM25、OpenSearch 的 match query、SQL LIKE、Elasticsearch 的 keyword query——任意经典 IR 工具都行。
工具增强 Agent:基于 function calling 的 LLM Agent,按 ReAct 或 Plan-and-Execute 风格自主决定"搜什么关键词、搜几次、怎么基于结果反思、什么时候停止"。

伪代码本质就一个循环:

while step < max_steps and not done:
    action = llm.decide(history, tools=[keyword_search])
    if action.type == "keyword_search":
        chunks = keyword_search(query, top_k, filters)
        history.append((action, chunks))
    elif action.type == "answer":
        return llm.compose(history)

要点:没有向量库、没有 embedding 服务、没有 re-ranker。Agent 自己写 query、自己加 filter、自己决定何时停止。这种"agentic"灵活性的本质是把"检索策略"从固定的 pipeline 抽出来,让 LLM 自己决定。

三、关键数字:≥ 90% 性能是什么意思?

论文核心论断:工具式关键词检索 Agent 在多个 QA 基准上的加权调和均值,达到传统 RAG 的 90% 以上。

怎么理解这 90%?——意味着在多数任务上,向量库的边际贡献不到 10%。换句话说,如果你花了 6 个月搭建的复杂 RAG 链路只比"Agent + BM25"高 5-10 个百分点,那基础设施投入大概率不值得。

但有几个边界要诚实标出(⚠️ 来自 abstract):

"90%"是聚合值——不同 QA 基准、不同难度的任务上可能有显著差异,论文未在 abstract 披露逐数据集明细。
使用的 LLM 型号、token 成本对比、延迟对比——abstract 未明确。
跨语言、长文档、多 hop 推理场景——abstract 未覆盖。
"90%"不是"100%"——这不是"关键词检索永远胜过 RAG",而是"在不依赖向量库的前提下达到 ≥ 90% 性能"。

所以这个数字应该被理解为:方向可信,粒度未知。你的业务场景需要自己跑一遍分层评估。

四、三档最小可跑部署路径

档 1:本地文件 + BM25(零基础设施,30 分钟跑通)

pip install rank-bm25 langchain-openai langchain-community
# 1. 加载文档
docs = DirectoryLoader('./docs', glob='**/*.txt').load()
# 2. 内存 BM25 索引(无需服务)
retriever = BM25Retriever.from_documents(docs, k=5)
# 3. 封装关键词检索工具给 Agent
# 4. ReAct Agent + GPT-4o 或 Claude 3.5 Sonnet

⚠️ max_steps 建议 ≤ 5,超出即强制 answer,防止无限循环把 token 烧光。

档 2:OpenSearch / Elasticsearch(生产级关键词检索)

docker run -d -p 9200:9200 elasticsearch:8.12.0
curl -X PUT 'http://localhost:9200/my_kb' -d '{
  "mappings": {
    "properties": {
      "content": {"type": "text"},
      "source": {"type": "keyword"},
      "updated_at": {"type": "date"}
    }
  }
}'

生产环境天然支持 filter(时间/类别/来源),比内存 BM25 强很多。

档 3:关键词 + 向量混合(当 90% 基线不够时)

先 BM25 召回 top-50,再 cosine rerank 取 top-5。这是工业界多年的最佳实践——本论文不是否定这种混合,而是说"如果只能选一种,关键词 + Agent 已经够用"。

五、生产环境五个最关键坑点

90% 是聚合数字,单任务可能差异巨大——BM25 对"找包含 X 的段落"有效,对"找与 X 语义相关但不包含 X 的段落"天然劣势。多跳推理、长文档摘要、跨语言检索上 BM25 天花板很明显。上线前必须分任务类型做分层评估。
Agent 循环的 token 成本是隐形成本——向量 RAG 成本在 embedding(一次性)+ LLM 推理(每次);Agent + 关键词成本在每次 query 的 LLM 调用次数(max_steps 次工具调用 + 1 次 answer)。高频场景下,Agent 循环的 token 消耗可能抵消向量库节省。
function calling 能力是硬依赖——如果你的 LLM function calling 能力弱(某些开源小模型),Agent 循环质量会严重退化。上线前必须测 LLM 的 tool use 准确率。
中文 BM25 效果弱于英文——中文无空格分词、英文空分词差异导致效果显著差。中文场景建议用 jieba 分词 + 自定义 analyzer,不要直接套英文 pipeline。
>10 万文档时单机 BM25 可能成瓶颈——必须升级到 Elasticsearch 分布式版或 OpenSearch,不能用内存 BM25。

六、生产配置推荐

参数	推荐值	说明
`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`	生产环境多维过滤

七、对工程团队的实际建议

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

⚠️ 关键数据与必须警惕的边界

"≥ 90% 性能"是 abstract 聚合数字,无逐数据集明细,无 baseline → mask 之间的各档对比明细。
使用的 LLM 型号未明确——直接决定 90% 是否在你真实生产环境成立。
token 成本对比未明确——Agent 多次循环 vs 向量库单次检索的折中,abstract 未量化。
跨语言/长文档/多 hop 推理场景未明确——BM25 在这些场景有结构性短板。
"90%" 不是"100%"——这不是"关键词永远胜过 RAG",而是"在多数 QA 任务上达到 ≥ 90%"。

三个标题变体

《扔掉向量库!Amazon Science 告诉你:90% 的 RAG 场景,一个 BM25 + Agent 就够了》
《别再花半年搭向量库了——AAAI 2026 接收论文说,关键词搜索就是新 RAG》
《你的 RAG 系统 90% 的价值,可能都被"关键词 + Agent"覆盖了——一项来自 Amazon Science 的反直觉研究》

小红书风格卡片文案

🧠 你的 RAG 系统是不是又慢又贵?——向量库索引重建、embedding 计算、Pinecone 账单,这些隐性成本你可能已经扛了快一年了。

最新来自 Amazon Science 的研究(AAAI 2026 接收,被引 6)给出了一个反主流但有数据支撑的结论:

✅ 不用向量库,只用关键词搜索 + 一个能调用工具的 Agent,就能在多数 QA 任务上达到传统 RAG 90% 以上的性能。

✅ 三档最小可跑部署: - 档 1:本地文件 + BM25(零基础设施,30 分钟跑通) - 档 2:OpenSearch / Elasticsearch(生产级关键词检索) - 档 3:关键词 + 向量混合(当 90% 基线不够时叠加)

⚠️ 关键边界: - "90%" 是聚合数字,不同任务差异巨大 - LLM 型号 + token 成本对比未明确,需自己实测 - 中文 BM25 效果弱于英文(建议 jieba 分词) - 高频场景 Agent 循环 token 消耗可能抵消向量库节省

💡 给团队的 3 条速记: 1. 新项目默认从关键词 + Agent 起步,再决定是否上向量库 2. 这条基线是任何 RAG 优化的压力测试对照组 3. 知识库每周变几次的场景,关键词方案明显胜出

互动话题:你的 RAG 系统里向量库是不可替代的,还是只是"大家都这么搭所以我也搭了"?如果让你扔掉向量库重搭,最担心哪类 query 翻车?评论区聊聊 👇

RAG #向量数据库 #LLM #AIAgent #Amazon #技术架构 #降本增效