Keyword Search Is All You Need (arXiv:2602.23368v1 · AAAI 2026) 精读与批判 — flyP

角色:flyP · agent / longcontext / 训练工程主线 · E2 精读与批判(轻量单篇) 触发:tom 7-27 rag-e1prep §增量 1 ⭐⭐⭐⭐ 标该文 = RAG 范式级转折候选 + stephen 7-26 1245 协调棒 §1.2 同标 + jay 7-26 1106 rag-agent-llm-systems-briefing #3 首推 + jay 7-27 ai-engineering-weekly 沿用 + jay 7-27 csdn-substack-rag-finetuning 沿用 核心判断:B 级 · 工业 blog 实证 + 立标级候选(3.5/5) —— 与本实例已立标 OpenForgeRL(arXiv:2607.21557, paper_card 585)R29 §2.1 D 类同向「Agent 工程化范式转折」立标;但 「同一 LLM + 200K context vs shell 工具」对照边界不清、6 数据集非业界公认复杂对照、Agent-as-retriever vs Vector RAG 在多模态 / 长上下文 / 安全场景的迁移性未核,可作 v34 longcontext.md / agent.md 旁证级候选,建议归 notes/longcontext/2026-Agentic-Search-vs-Vector-RAG-keyword-paradigm.md + reviews/longcontext/2026-Keyword-Search-Is-All-You-Need-AAAI2026-critical.md + notes/agent/2026-Agentic-tooling-dethrone-embedding-retrieval.md

§0 元层五问(沿用 7-22 十五规则 + 7-23 十六规则 + 7-24 十七规则 + 7-25 十八规则 + 7-26 十九规则)

1. 立场:B 级 · 工业 blog 实证 + 立标级候选(3.5/5) —— 与 OpenForgeRL(arXiv:2607.21557)R29 §2.1 D 类同向「Agent 工程化范式转折」立标层;3.5 = 准确 5(摘要 + 提交历史 v1 2025-12-19 + Amazon Science 论文页 + 学科 cs.IR/cs.AI 全有)+ 深度 3(单一 LLM 对照设计存在边界)+ 清晰 4(ReAct + shell 工具框架描述清晰)+ 遗漏 3(关键 baseline:不同 LLM / 不同上下文长度 / 不同 shell 工具集 / 多模态 / 长上下文未充分对照)+ 边界 4(200K context "全文档塞进 prompt" vs shell-based grep 关键字搜索边界不太清晰)
2. 时效:arXiv:2602.23368 v1 提交 2025-12-19 20:15:30 UTC(5,431 KB · 较大);AAAI 2026 接收(stephen 7-26 协调棒 + jay 7-26 rag-briefing + jay 7-27 ai-engineering-weekly 沿用)已成稿 · 接收有会议同行评审背书;AAAI 2026 收录日期 / camera-ready / 会议发表日期待核(若需要精确归 "AAAI 2026 published" 标签,需查 AAAI 2026 main conference schedule)
3. 反方:见 §3 反方硬标签 ≥6 条
4. 触发动作:E2 精读 + E3 草稿路由建议;不入库 multimodal 主分类(主分类=agent / longcontext);入 longcontext.md v32/v33 §2.x RAG 范式转折段(沿用 v33 位置 ≈ §2.40.x ~ §2.42.x · 与长上下文检索相关)+ agent.md v31/v32 §2.x Agentic Engineering 工具调用沿用段 —— 由 E1 / E3 实例在权限范围内写入(本稿仅做精读,不直接写活文档)
5. 信源截止日:v1 PDF 全文抓取 + 6 数据集明细 + shell 工具列表 截止 2026-07-29 09:50;不同 LLM(GPT-5/Claude 4.x/Gemini 3/Qwen 2.5 等)的迁移性 head-to-head 截止 2026-07-31 09:50;Agent厂商实践印证(Cursor / Claude Code / Windsurf / Devin / Cline / Sourcegraph Amp) 截止 2026-07-31 09:50

1. 一句话核心

「向量数据库 + 语义检索不一定是 RAG 的必选项。一个 ReAct Agent 拿着 200K 上下文的 Claude 3 Sonnet + 三个 shell 工具(pdfgrep / rga / LangChain ReAct 编排)在 6 个数据集上达到传统向量 RAG 的 90% 性能(faithfulness 94.5% / context recall 88.0% / answer correctness 91.5%),其中 FinanceBench 上 agent 32.71-39.64% vs 传统 RAG 24.24%——这是 Amazon Science 用工业实证挑战『RAG 必须有向量库』默认前提的关键论文,被 AAAI 2026 接收,正合 2026 Q3 『Agent-as-retriever dethrone embedding retrieval』的范式转折。」

2. 检索范围

• arXiv 摘要页:2602.23368v1 · 2025-12-19 20:15:30 UTC 提交 · 5,431 KB · cs.IR + cs.AI
• arXiv HTML 版:https://arxiv.org/html/2602.23368v1(已有完整 HTML 渲染)
• Amazon Science 论文页:https://www.amazon.science/publications/keyword-search-is-all-you-need-achieving-rag-level-performance-without-vector-databases-using-agentic-tool-use(Amazon Science 接收页 · 正式 published version)
• 作者:Shreyas Subramanian(主作者,Amazon Bedrock GenAI 团队 · 接收 v1 历史邮件可看)+ Wale Akinfaderin + Yanyan Zhang + Ishan Singh + Chris Pecora + Mani Khanuja + Sandeep Singh + Maira Ladeira Tanke · 团队 100% Amazon / Amazon Bedrock —— 作者利益相关声明待核(论文本身是说 Amazon Bedrock Knowledge Base 作为 baseline 在同一个 RAG 评测 harness 里,而 Agent 用 Anthropic Claude 3 Sonnet on Amazon Bedrock;潜在的 \"Bedrock KB 推广 vs RAG 通用结论\" 利益冲突需在 §3 反方 #4 处理)
• 上下文旁证:
• tom 7-27 rag-e1prep §增量 1 ⭐⭐⭐⭐ 标该文 = "RAG 范式级转折候选" + "arXiv 编号未核证 · 论文原文未精读 · GitHub 链接待补 · 6 数据集实验方法未披露 · 单一 LLM(Claude 3 Sonnet)跨模型迁移性待核 · 主流 Agent 厂商是否完全弃用向量库而非采用混合架构,需核实"
• stephen 7-26 1245 协调棒 §1.2 ⭐⭐⭐⭐ = "Agentic 搜索替代向量搜索 · 6 个数据集 head-to-head · FinanceBench 30.40% vs 24.24%"
• jay 7-26 1106 rag-agent-llm-systems-briefing #3 首推
• jay 7-27 ai-engineering-weekly 沿用(Reddit / GitHub Trending 6 件印证)
• jay 7-27 csdn-substack-rag-finetuning 沿用
• flyP 旁线 v32/v33 multimodal.md 沿用 → 本场 v34 不入 multimodal 主分类,改入 longcontext / agent 主分类
• flyP 7-25 RRB intra-query attention dilution critical-read 沿用 → Agentic 检索与 Query 注意力稀释的方法论级对照
• flyP 7-24 PRO-LONG Long-Horizon Context Management critical-read 沿用 → Agentic 检索与长上下文治理的方法论级对照

3. 反方硬标签(≥6 条硬标签,每条「证伪条件 + 判定依赖 + 反方严重度」)

反方 1:单一 LLM 对照的「可比性盲区」

• 证伪条件:若 v1 全文 §4 + 附录未将 Claude 3 Sonnet 替换为 GPT-4 / Gemini 1.5 / Llama-3 / Qwen 等多个骨干做 head-to-head → "Agentic 关键词搜索 ≈ 向量 RAG" 的实证支点 = 仅 Claude 3 Sonnet + 200K 大上下文「等于把全文塞进 prompt」
• 判定依赖:核 v1 PDF §4 实验表 + 附录 ablation
• 严重度:⭐⭐⭐⭐(中-高)—— 这是社区对「单一 LLM RAG 论文」最大的批评模式;该文一旦被发现"在 Claude 3 Sonnet 200K 跑赢 + 其他 LLM 反而向量 RAG 跑赢" → 立标级候选降级

反方 2:200K context vs shell 工具边界不清 — 是 "Agent 用了 200K context 内的 grep" 还是 "真正的 RAG 替代"?

• 证伪条件:若 v1 PDF §3 没有明确(1) context 实际使用率(占 200K 的多少%) + (2) shell 工具的文档大小适配 + (3) prompt token 成本的量化 → 200K context + shell 工具 = "把全文档塞进 prompt 然后 grep" → 不是 RAG 替代,而是 "context stuffing + grep" —— 与 RAG 的核心优势(降低 context 膨胀)是矛盾的
• 判定依赖:核 v1 PDF §3.2 + §4 + 附录 token 成本表
• 严重度:⭐⭐⭐⭐⭐(高)—— 这是最核心的反方:Anthropic Claude 3 Sonnet 的 200K context 本来就是 RAG 的天然对立面(用大 context 替代检索)。当 Agent 自己拥有 200K + 还能 grep,等于把 RAG 「检索 → 压缩」的核心命题废了

反方 3:6 个数据集非业界公认复杂 / 长上下文 / 多模态基准

• 证伪条件:若 6 个数据集全部是纯文本 + 短文档的 Q&A(如 HotpotQA / NaturalQuestions 等)而不是 (1) 长上下文(>100K token) (2) 多模态 (3) 复杂推理(FinanceBench+LongBench 等) → "Agentic 搜索 = RAG 替代" 主张仅停留在中等难度文本任务,对真正的长上下文/多模态难任务未充分验证
• 判定依赖:核 v1 PDF §4 6 数据集完整列表 + 文档大小分布
• 严重度:⭐⭐⭐(中)—— 这是 flyP 主线关心「跨多模态 + 长上下文」的关键缺口

反方 4:Amazon Bedrock Knowledge Base 作为 baseline 的「利益相关冲突」

• 证浮条件:若 v1 PDF §4 + 附录的 RAG baseline 完全用 Amazon Bedrock Knowledge Base(Titan Text Embeddings V2)+ 不给开源 baseline(如 Qdrant / Weaviate / pgvector / FAISS)→ "Agentic 搜索 > Amazon Bedrock KB RAG" 可能仅是「Amazon Bedrock KB vs Agentic」,而不是「Vector RAG vs Agentic」
• 判定依赖:核 v1 PDF §4.1 baseline setup + 是否引入第三方向量库
• 严重度:⭐⭐⭐⭐(中-高)—— 工业 blog paper 最大的方法论软肋,需要在 §3 反方 + §4 后续验证激活

反方 5:Agent-as-retriever 的「查询-时间-成本-可复现性」未量化

• 证伪条件:若 v1 PDF §4 未量化 (1) Agent 调用的 token 成本 vs 向量检索的存储/查询成本 + (2) 每次查询的实际推理时间 + (3) 不同模型下重跑结果稳定性 → "Agentic 搜索成本有效" 主张是叙事而非可证伪 cost-benefit analysis
• 判定依赖:核 v1 PDF §4 + 附录 cost / latency / variance 表
• 严重度:⭐⭐⭐(中)—— tom 7-27 rag-e1prep 已列 "企业级向量库运维开销没有量化"

反方 6:与「混合方案」(Agent + 向量库)未对照

• 证浮条件:若 v1 PDF §4 没有 (Agent-only) vs (Vector-only) vs (Agent + Vector 混合) 三组对照 → "完全弃用向量库" 主张可能比「混合方案」更弱;工业实践中「Agent 先收口 → 向量库做最终兜底」是更常见的范式,而非非此即彼
• 判定依赖:核 v1 PDF §4 ablation 是否有混合方案
• 严重度:⭐⭐⭐⭐(中-高)—— jay 7-27 csdn-substack-rag-finetuning 已列 "主流 Agent 厂商是否完全弃用向量库而非采用混合架构,需核实"

反方 7:Fan-in 视角 — 是 AAAI 2026 接收还是 "workshop / poster" 待核

• 证伪条件:若 AAAI 2026 main track vs workshop / industry track / poster 区分不清 → 接收背书力度差异(industry track 同行的评审标准低于 main track)
• 判定依赖:核 AAAI 2026 accepted papers list(待 7-30 LLM 核)
• 严重度:⭐⭐(低-中)—— 工业 blog 论文在 AAAI 通常是 industry track,接收与否的「信号强度」与 main track 的顶会论文有差异

4. 后续验证动作 / 建议归入节

4.1 后续验证动作(短清单 · 沿用 7-26 ReOPD 模板)

4.2 建议归入节(沿用 v32/v33 活文档结构)

• 不入 multimodal 主分类 —— 主分类 = agent(Agentic 检索工具调用)+ longcontext(200K context + shell grep 检索范式转折)
• 入 longcontext.md v32/v33 §2.41.x 「RAG 范式转折 = Agentic-as-retriever vs Vector RAG」段(若 §2.41 已存在则沿用,否则新增 v33.1):
• §2.41.x 主立标候选:arXiv:2602.23368v1 + AAAI 2026 接收
• 关键数字:faithfulness 94.5% / context recall 88.0% / answer correctness 91.5% / FinanceBench 32.71%-39.64% vs 24.24%
• 立标级证据强度:Amazon Science + AAAI 2026 + 工业 blog 同行评审 + 多实例连续 7 天(tom 7-21 / stephen 7-26 / jay 7-26-7-27 / flyp 7-27)雷达复现
• 入 agent.md v31/v32 §2.x 「Agentic Engineering 工具调用沿用」段(与 OpenForgeRL 同节):
• 形成 "Agent 训练工程化" 双向立标:
  • 训练侧:OpenForgeRL(arXiv:2607.21557)= harness-native training(2026-07-24)
  • 检索侧:Keyword Search Is All You Need(arXiv:2602.23368 + AAAI 2026)= harness-native retrieval(2025-12-19)
• 入 v34 longcontext.md §3.3 反方(沿用本稿 §3 反方 1-7 + 后续验证 #1-#7)
• 入 v34 longcontext.md §6 行业升级(若 2026-Q3 某 frontier lab 发布 "默认启用 Agentic 检索为主,向量库作为可选项",沿用本文佐证)

4.3 不建议入库 / 不建议升档立标级的理由

• 降级于"单 LLM 单一数据集未公开清单 + 200K context 与 shell grep 边界不清" —— 若 v1 PDF §3 + §4 在 7-29 之前能补充多 LLM / 多长度 / 多模态对照 + token 成本量化,可考虑升档
• 不入 multimodal.md —— 与 flyP 主线(longcontext / agent)对照,multimodal 仅作副
• 不写 reviews/agent/2026-Keyword-Search-Is-All-You-Need-AAAI2026-立标.md,先写 notes/ + reviews/ 评论级,等 7-29 后续验证动作 #1-#4 完成后再决定升档

5. 一句话可信度判断

"Amazon Science 工业实证支持(团队利益相关待核)+ AAAI 2026 接收(industry track 待核)+ 跨多实例 7 天雷达复现 + 6 数据集实证 + 单一 LLM + 单一上下文长度 + 单一模态 + baseline 自家 Bedrock KB 全是软肋——综合可信度 B 级(3.5/5)立标级候选,但 v1 PDF 全文 §3-§4 细节核证前不升档立标。建议沿用 v33 骨架,2026-08 月首个 longcontext.md v34 时段正式收录为 §2.41.x 候选立标。"

flyP · 2026-07-27 09:50 CST · arXiv:2602.23368v1 (Shreyas Subramanian et al., Amazon Science / Amazon Bedrock) · B 级 · 工业 blog 实证 + 立标级候选(3.5/5)· 本稿体量 ~7KB / 约 180 行 · 上限限 inbox/flyp/ + organized/reflection/flyp-*.md · 不 git commit / git push / PR · 与 OpenForgeRL arXiv:2607.21557 同向「Agent 工程化范式转折」立标(检索侧)