企业官网建设流程全解析

（本文是对 SAGE: Benchmarking and Improving Retrieval for Deep Research Agents，arXiv:2602.05975，2026-02 的技術解读。所有数字与结论均来自论文原文；文中凡涉及具体产品能力，仅以公开 README 已写明的事实为准，未核实处不做推断。）

一、为什么写这篇

过去一年，"deep research agent"几乎是每个大模型厂商都在讲的故事：给模型一个复杂问题，它自己拆解子问题、自己检索、自己综合出一份带引用的报告。Kimi、Gemini、GPT 都推出了这类能力。

但有一个底层问题很少被认真评测过：这类 agent 在检索这一步，到底用哪种检索器更靠谱？

直觉上，既然 LLM-based retriever（比如用大模型做语义检索、甚至做推理式检索）能力那么强，用它替换传统的 BM25 关键词检索，应该全面更好。很多系统的默认做法也确实是上稠密向量检索，甚至直接把检索交给 LLM 去"理解"。

2026 年 2 月，一篇来自 Yale / Arman Cohan 组的论文 SAGE（Submission to ACL ARR 2026 January）给出了一记反直觉的结论：在 deep research agent 的真实工作流里，老派的 BM25 比 LLM-based retriever 好了大约 30%。

这篇值得写，不只因为它反直觉，更因为它替一类被低估的工程选择正了名——其中就包括我们一直坚持的"BM25 + 稠密向量"混合检索。

二、论文是谁，解决什么病

论文全名：SAGE: Benchmarking and Improving Retrieval for Deep Research Agents
作者：Tiansheng Hu, Yilun Zhao, Canyu Zhang, Arman Cohan, Chen Zhao
提交时间：2026-02-05（v1），2026-02-06（v2）
方向：Information Retrieval (cs.IR) + Computation and Language (cs.CL)

它要回答的核心问题是：LLM-based retriever 能不能有效嵌入 deep research agent 的工作流？如果不能直接替换，有没有低成本的办法补？

论文先搭了一个受控基准 SAGE，再拿它做两组实验：第一组评 6 个真实 deep research agent 的检索能力，第二组在固定 agent 骨架上替换不同检索器做对比。

三、SAGE 基准是怎么搭的

这是一个封闭的、可控的检索评测，刻意避开开放网页搜索的噪声，专门研究 agent 在固定语料上的检索行为。

基准构成：

这个设计很讲究：short-form 逼着 agent 在元数据、跨论文关系、多模态内容上做细粒度推理；open-ended 模拟真实文献调研，ground-truth 是一组按相关度分级的文档。两类问题分别测"精确命中"和"广覆盖"，正好能区分不同检索器的长短板。

四、发现一：所有 agent 在推理密集检索上都吃力

第一组实验评了 6 个 deep research agent，既有闭源（论文提到 GPT-5、Gemini-2.5 Pro/Flash 这类）也有开源（DR Tulu）。

结论很一致：所有系统在 reasoning-intensive retrieval 上都明显吃力。即便是表现最好的闭源 agent，在 short-form 上的 EM 也没超过 80%。也就是说，agent 会推理、会拆问题，但真到"从 20 万篇里精确捞出那一篇"这一步，全军覆没。

这本身就给行业泼了冷水：deep research 的瓶颈不在生成，在检索。

五、发现二：BM25 比 LLM 检索器强约 30%

第二组实验是全文最值得记的结论。论文以开源的 DR Tulu 为固定骨架，把底层检索器换成三种：

• BM25（经典稀疏、关键词匹配）
• gte-Qwen2-7B-instruct（稠密语义检索）
• ReasonIR（推理专用检索器）

结果：BM25 在 short-form 查询上，比 LLM-based retriever 显著高出约 30%（原文：BM25 significantly outperforms LLM-based retrievers by approximately 30%）。

为什么？论文给出的根因解释很关键，也很容易被误读，这里精确表述：

现有 deep research agent 在推理过程中生成的子查询，大量是 keyword-oriented（关键词导向）的。这种子查询天然更适合 BM25 的表面形式匹配，而不适合稠密 embedding 检索——因为后者的训练分布更偏向自然语言表述和广覆盖语义。换句话说，不是 BM25 变强了，而是 agent 自己的查询分解方式和 BM25 更对得上。

还有一个细节：在 open-ended 查询上，BM25 的优势明显收窄。论文解释，开放式问题需要更广的证据覆盖，这部分缓解了"稀疏 vs 稠密"的差距。所以"BM25 强 30%“是严格限定在 short-form、且 agent 子查询偏关键词这个条件下的，不能泛化成"BM25 全面碾压 LLM 检索”。

对比小结：

六、改进方法：corpus-level test-time scaling

发现 BM25 赢，不代表论文推荐退回纯 BM25。它给了一个低成本的补法，叫 corpus-level test-time scaling（语料级测试时缩放）。

做法：在检索发生之前，用 LLM 给语料里的每一篇文档预先补充 metadata 和 keywords（可以理解为给每篇文档自动生成一组"检索友好"的标签和关键词）。这样，后续的子查询哪怕还是关键词导向，也能更容易地命中目标文档——因为文档侧被人为"补齐"了关键词信号。

效果：short-form 提升约 8% EM，open-ended 提升约 2% Weighted Recall。而且它不需要重训检索器、不需要端到端微调 agent，纯粹在语料侧做增强。

这个方法论上有个很朴素的启示：与其赌检索器变聪明，不如把文档本身变得更好被检索。这个思路和"给知识库建好元数据、关键词、目录结构"是同一件事。

检索链路示意：

【用户问题】 │ ▼ 【Agent 推理分解】── 生成 keyword-oriented 子查询 │ ▼ 【Retriever】 BM25 匹配表面词 ┐ 稠密向量 匹配语义 ├─ 两者互补 reranker 重排 ┘ │ ▼ 【Corpus（已预补充 metadata + keywords）】 ← corpus-level scaling 在这里生效 │ ▼ 【答案 + 出处】

七、SAGE 给工程者的三个启示

1. 别盲目用 LLM 检索器替换关键词检索。在 agent 子查询偏关键词的场景下，BM25 不是过时方案，反而是更稳的默认。是否上 LLM 检索，取决于你的查询是怎么生成的。

2. 元数据与关键词是廉价杠杆。SAGE 的 corpus-level scaling 只用"给文档补 metadata + keywords"就拿到了稳定增益，且零重训。对自建知识库来说，把文件来源、类型、标签、章节这些结构化信息建好，比换更贵的检索模型性价比高得多。

3. 混合检索是默认答案。BM25 赢在精确匹配，稠密检索赢在语义泛化，两者错配的不是"谁更好"，而是"问题长什么样"。工程上把两者叠加再加一层 reranker，是对"子查询风格不确定"最稳健的应对。

八、和 CoreNote 检索层设计的对照

下面这部分只基于 CoreNote 公开 README 已写明的事实，不做推断。

CoreNote 的检索层正是"混合检索"路线：BM25 与稠密向量（bge-m3 的稠密+稀疏双路，dimension 1024）并用，再经 bge-reranker-v2-m3 重排保留 Top 8，子块命中后回取父块作答。也就是说，SAGE 论文从学术基准上验证的那条路线——“稀疏+稠密混合、不迷信 LLM 检索”——和 CoreNote 的工程设计是同向的。

更具体地说，SAGE 的 corpus-level scaling（用 LLM 给文档补 metadata + keywords）对应的是 CoreNote 对"元数据 / 关键词"索引的重视：文件来源、类型、标题、章节等结构化信号，本身就是低成本提升检索命中率的手段，和论文的"语料侧增强"思路一致。

但要注意两个边界，不能把论文结论直接当成产品广告：

• SAGE 的结论限定在"deep research agent + 子查询偏关键词 + 封闭语料"这一具体设定。CoreNote 是面向个人知识库的问答，查询风格、语料规模、是否走 agent 化检索都不同，不能直接套用"BM25 强 30%"这个具体数字。
• CoreNote 的知识图谱在 README 中明确是"基于文件结构、标题、关键词建立关系，支持手动创建节点"，不是实体抽取图谱，不具备 SAGE 讨论的跨文档推理能力。论文里的"推理密集检索"短板，CoreNote 当前架构并不声称解决。

九、论文自身的局限

客观地说，SAGE 也有边界，写技术解读不能只捡好听的：

• 实验主要基于 DR Tulu 和 SearchR1-32B 两个 agent 骨架，泛化到其他 agent 类型存疑。
• 没有做 instruction fine-tuning 或 retriever-aware training，因此无法评估"让 agent 查询生成去适配检索器类型"后的上限。
• "BM25 强 30%"严格限定在 short-form 和 keyword-oriented 子查询；open-ended 上优势已收窄，不能泛化。
• 论文没有给出幻觉率或端到端回答质量的下降幅度，只测了检索层。

十、小结

SAGE 的价值不在"BM25 翻盘"这个标题，而在于它用一个受控基准，把一句工程直觉变成了可引用的结论：检索器选型的答案，取决于你的查询是怎么生成的，而不是"越新越贵越好"。

对正在搭个人知识库、或在做 RAG 系统的开发者，这篇值得一读的三个点是：混合检索仍是默认稳妥解；元数据与关键词是被低估的廉价杠杆；在换更贵的模型之前，先把文档本身的检索信号建好。

（常见问题）

问：SAGE 这篇论文说 BM25 全面优于 LLM 检索吗？
答：不是。论文原文限定在 deep research agent 工作流、且子查询偏关键词的 short-form 场景下，BM25 相对 LLM-based retriever 高出约 30%；在 open-ended 场景下优势明显收窄。结论不能泛化为"BM25 全面更强"。

问：什么是 corpus-level test-time scaling？
答：论文提出的方法：在检索发生前，用 LLM 给语料中每篇文档预补充 metadata 和 keywords，使现成检索器更容易命中。short-form 提约 8% EM、open-ended 提约 2% Weighted Recall，且无需重训检索器或微调 agent。

问：Deep research agent 检索差，是不是模型不够强？
答：SAGE 评了 6 个 agent（含闭源前沿模型），全部在推理密集检索上吃力，最好也没超过 80% EM。瓶颈在检索环节，不在生成环节。

问：SAGE 基准的规模和指标是什么？
答：1,200 条查询（600 短答案 + 600 开放式），覆盖 CS / 自然科学 / 医疗 / 人文 4 领域，20 万篇论文语料；short-form 用 Exact Match，open-ended 用 Weighted Recall。

问：这篇和我已经发的 bge-m3 混合检索文章有什么关系？
答：那篇讲 CoreNote 怎么把 BM25 和稠密向量（bge-m3）叠加并加重排；SAGE 从学术基准上证明了"混合检索、不迷信 LLM 检索"这条路线的合理性，是那篇的工程依据补强。

问：个人知识库一定要上 LLM 检索器吗？
答：SAGE 的启示是，先取决于你的查询风格。大多数个人知识库的查询偏关键词和元数据，BM25 加稠密混合通常就够；盲目上 LLM 检索器可能不增反降，且更贵。