前两篇讲的是一条流水线：query → embedding → 混合召回 → rerank → top-k → 放进 prompt → 生成。它是 2023 年以来 RAG（retrieval-augmented generation）的标准形态，优点是每一步确定、延迟可控、成本固定。它的弱点也来自”确定”：一次检索没找到就没找到，查询与文档不匹配时没有第二次机会，多跳问题（”A 的供应商的母公司在哪”）要先查 A 再查供应商再查母公司，流水线做不到。

2025 年之后另一种形态成为主流：检索是 agent 的一个工具。模型看到问题，决定查什么（改写、拆分）、用哪类检索（grep 还是向量还是 SQL）、查几轮、结果够不够、要不要换个词再来——第二篇讲的 coding agent 用 grep 多轮搜索就是它；深度研究类产品是它的极端形态。它把检索的召回压力变小（一次没找到可以再来），把对工具描述、上下文预算、循环控制的要求变大。两种形态不是替代关系，本篇讲各自适合什么、中间的改进手段、以及供应商内置的 file search 在协议上是什么。

本篇要回答的核心问题是：

固定流水线与 agentic retrieval 各适合什么？¹ query 改写、多查询、多跳各解决什么问题？² agentic 检索对工具描述、上下文预算、循环控制有什么要求，供应商内置的 file search 在协议上是什么？³

术语与缩写

本文用到的术语与缩写

缩写	全称	一句话解释
query	—	用户的查询
embedding	—	把文本变成向量，意思相近的文本向量也相近
rerank	—	对召回的候选重新精排打分
top-k	—	按分数取前 k 个结果
prompt	—	发给模型的提示词与上下文
RAG	retrieval-augmented generation	检索增强生成：先检索相关内容放进上下文，再让模型回答
agent	—	能自己调工具、多步完成任务的模型程序
grep / glob	—	grep 按内容搜文本，glob 按通配符找文件
coding agent	—	能读写代码、跑命令的编程 agent
file search	—	供应商内置的托管检索：上传文件，自动建索引，模型调用
agentic	—	由模型自己决定查什么、查几轮的做法
agentic retrieval	—	把检索做成 agent 的工具，由模型决定查什么、查几轮
token	—	模型处理文本的基本单位
trace	—	记录每一步输入、输出和决策的调用轨迹
FAQ	frequently asked questions	常见问题列表
HyDE	Hypothetical Document Embeddings	先让模型写一段假想答案，再用它去检索
RRF	Reciprocal Rank Fusion	倒数排名融合：只按排名合并多路结果
schema	—	数据的结构定义：表、字段、类型
L4	—	应用地图第四层：工具、Agent 与运行时
LSP	Language Server Protocol	编辑器和语言服务之间的协议，能查定义与引用
p50 / p95	50th / 95th percentile	延迟的中位数与 95 分位
L5	—	应用地图第五层：评测、可观测与可追溯
OpenAI Responses	—	OpenAI 的新一代对话 API，内置 file search
ACL	access control list	访问控制列表：记录谁能看这份文档
A/B	A/B testing	把流量分成两组、对比两个版本的实验
L2	—	应用地图第二层：Prompt 与上下文工程

一、总览

1. 两种形态

%%{init: {"flowchart": {"wrappingWidth": 190}}}%%
%% 图：流水线 RAG 与 agentic retrieval 两种形态的取舍
flowchart TB
    subgraph P["流水线 RAG（2023 起的标准形态）"]
        direction TB
        P1["query"] --> P2["embedding → 混合召回 → rerank"] --> P3["top-k 放进 prompt"] --> P4["生成"]
    end
    subgraph AG["agentic retrieval（检索是 agent 的一个工具）"]
        direction TB
        A1["模型读问题，决定先查什么"] --> A2["调 search_docs / grep / sql / read"] --> A3["看结果：够不够？<br/>不够 → 换查询再查 / 顺着线索查下一跳"] --> A1
        A3 -- "够了" --> A4["生成（带引用）"]
    end
    P -. "每步确定、延迟可控、成本固定<br/>一次没找到就没找到，多跳做不到" .-> X["取舍"]
    AG -. "召回压力小、能多跳、能自纠<br/>延迟与 token 不可预测，要预算与上限" .-> X

流水线 RAG 与 agentic retrieval 的对照

	流水线 RAG	agentic retrieval
谁决定查什么	代码：用户问题（或固定改写）就是查询	模型：读问题后决定查询词、检索类型、轮数
检索次数	1（或固定几次）	不定，1 到几十
模型调用次数	1	多（每轮一次）
延迟	可控：检索几百毫秒 + 一次生成	不定：轮数 × （模型 + 检索）
成本	固定：一次输入几千 token	不定；上下文随轮增长（《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》）
召回压力	高：一次要找对	低：没找到再来
多跳	做不到（除非预设）	天然支持
可预测性	高，易调试	低，靠 trace
适合	高并发、定位型问答、延迟敏感、问题形态稳定	复杂任务、多跳、探索型、问题形态多变、agent 场景
代表	客服 FAQ、文档问答、搜索增强	coding agent、深度研究、数据分析 agent

2. 中间地带

两者之间有一条渐进的路：流水线加 query 改写（模型先改写查询再检索一次）、加多查询（拆成几个查询并行检索再合并）、加自检（生成后判断”检索结果够不够”，不够再来一轮，上限两轮）——每加一步就更接近 agentic 一点、延迟与成本也涨一点。多数生产系统停在这条路的中段。

%% 图：从流水线到 agentic 的渐进路——每往右加一步（query 改写 → 多查询 → 元数据路由 → 自检 + 有限重试 → 模型自主的工具循环），决策权从代码多交给模型一点、延迟与成本也涨一点；多数生产系统停在中段
flowchart TB
    P0["流水线<br/>用户问题 = 查询<br/>1 次检索 · 1 次生成"] --> P1["+ query 改写<br/>小模型补指代、抽关键词<br/>+ 几百毫秒"]
    P1 --> P2["+ 多查询 / HyDE<br/>拆成几个并行检索，RRF 合并<br/>检索次数 × 几"]
    P2 --> P3["+ 元数据路由<br/>抽「2025 年」「华东区」成过滤条件"]
    P3 --> P4["+ 自检 + 有限重试<br/>sufficient 字段不够 → 再一轮<br/>代码控制，上限 1–2 轮"]
    P4 --> P5["agentic retrieval<br/>模型决定查什么、用哪类、查几轮<br/>1 到几十轮"]
    P0 -.- N1["代码决定一切 · 延迟可控 · 召回压力高"]
    P5 -.- N2["模型决定 · 延迟成本不定 · 召回压力低 · 多跳"]
    classDef a fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef b fill:#fff7e0,stroke:#c98a00,color:#222
    classDef c fill:#fdecea,stroke:#c0392b,color:#222
    classDef n fill:#eef6ff,stroke:#5b8fd6,color:#222
    class P0,P1 a
    class P2,P3,P4 b
    class P5 c
    class N1,N2 n

3. 本文的章节安排

第二章讲流水线的改进手段；第三章讲 agentic retrieval 的形态与它对系统的要求；第四章讲供应商内置的 file search；第五章讲决策；第六章实践建议。

二、流水线的改进

1. query 改写

用户的问题不是好的查询：”那个东西上个月为什么坏了”没有关键词、有指代、有时间词。改写让模型先把问题变成检索友好的形式：补全指代（从对话历史）、抽取关键词、加同义词、去掉寒暄。一次额外的小模型调用（Luna / Haiku 级，《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》的分流），几百毫秒，对对话式 RAG 几乎是必需的——第三轮的”它呢？”不改写就没法检索。

2. HyDE：先写假想答案

Hypothetical Document Embeddings：让模型先对问题写一段假想的答案（不管对不对），用这段答案去做向量检索。原理是答案与文档在同一”回答”的语义空间里，比问题与文档的距离更近——问题”退货要多久”与文档”逆向流程通常在七个工作日内完成”词汇不同，但假想答案”退货一般需要 7 个工作日”与文档很近。代价是一次生成；风险是假想答案跑偏时检索跟着偏。对词汇不匹配严重的语料有效。

%% 图：HyDE 为什么有效——问题「退货要多久」是提问句式，文档「逆向流程通常在七个工作日内完成」是陈述句式，两者在向量空间里离得远；让模型先写一段假想答案「退货一般需要 7 个工作日」，它与文档同是陈述、词汇更接近，用它去检索距离更近；风险是假想答案跑偏时检索跟着偏
flowchart TB
    Q["问题：退货要多久？"] -->|"直接 embedding"| QV["提问空间里的一个点<br/>与文档距离远（词汇：退货 / 多久）"]
    Q -->|"先让模型写假想答案"| H["假想答案：<br/>「退货一般需要 7 个工作日」"]
    H -->|"embedding"| HV["陈述空间里的一个点<br/>与文档距离近（工作日 · 7 · 完成）"]
    D["文档：「逆向流程通常在<br/>七个工作日内完成」"]
    QV -.->|"召回：✗"| D
    HV -->|"召回：✓"| D
    R["风险：假想答案写成「退货需要 30 天」<br/>→ 检索跟着偏"] -.-> H
    classDef q fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef bad fill:#fdecea,stroke:#c0392b,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef doc fill:#f0f0f0,stroke:#888,color:#222
    class Q q
    class QV,R bad
    class H,HV ok
    class D doc

3. 多查询与拆分

一个问题拆成几个子查询并行检索，结果合并（RRF，Reciprocal Rank Fusion）：比较类问题（”A 与 B 的保修有什么区别”拆成 A 的保修、B 的保修）、多面问题（”这个产品的价格、交期和售后”）。也可以让模型生成同一问题的三种改写并行检索，提高召回的鲁棒性。代价是检索次数乘几倍——检索便宜，这通常值得。

4. 按元数据路由

问题里有”2025 年”、”华东区”、”合同”这类信号时，先抽取成过滤条件再检索——把语义问题变成结构化过滤 + 语义检索（第四篇的带过滤搜索）。模型抽过滤条件（结构化输出，《Prompt 与上下文工程（03）：结构化输出——约束解码、schema 设计与失败修复》），比让 embedding 去”理解”时间范围可靠得多。

5. 自检与有限重试

生成之前加一步判断：”这些检索结果能回答问题吗？”（一次小模型调用或让主模型在结构化输出里给一个 sufficient 字段）——不能则改写再检索一轮，上限一到两轮。这是流水线向 agentic 迈的最后半步：有循环，但循环是代码控制的、有硬上限、延迟可算。

三、agentic retrieval

1. 形态

检索做成一个或几个工具（《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》的工具调用协议）：search_docs(query, filters)、grep(pattern, path)、sql(query)、read(doc_id, range)。模型在 agent 循环里（L4）自己决定：先用哪个、查什么词、看到结果后是回答还是再查、要不要换检索类型。第二篇的 coding agent 是它最成熟的实例：grep 找字面 → 读文件 → 发现线索 → 再 grep → LSP（Language Server Protocol）找引用，几轮到几十轮。深度研究产品是另一端：几十次网页搜索与阅读、逐步收窄、最后综合成报告。

2. 它换到了什么

• 召回压力下降：流水线要求 top-5 里有答案；agentic 只要求”有线索”，模型顺着线索再查。第二篇里 grep 的词汇不匹配问题在多轮下被缓解——猜三次通常能猜到。
• 多跳成为可能：每一跳是一轮。
• 检索类型可选：三类检索都做成工具，模型按问题选（精确标识符 grep、自然语言向量、关系 SQL）。
• 问题形态不用预设：流水线要为每类问题设计改写与路由，agentic 让模型临场决定。

3. 它要付什么

• 成本与延迟不定：一个任务 1 轮还是 30 轮由模型决定；《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》讲的”按任务看分布”在这里是必需的——p95（95th percentile）常是 p50（median）的 5–10 倍。
• 上下文增长：每轮的检索结果进入上下文，《Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切》的 \(S + (k-1)(r + o)\) 里 \(r\) 就是它；《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》的卸载（大结果写文件留引用）、清理（旧结果删掉）、预算（每轮返回上限）在 agentic 检索里是必需品不是选项。
• 工具描述决定行为：模型用不用对工具、用对参数，取决于描述（《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》「三、工具调用是一个协议」）：”search_docs：对制度、合同等非结构化文档做语义检索，适合自然语言问题；已知条款编号时用 grep_docs；查客户 / 订单等结构化数据用 sql”——不写清，模型会用向量搜编号、用 SQL 搜段落。
• 循环控制：步数上限、token 预算、循环检测、”没有进展”的判断——L4 运行时的责任。没有上限的 agentic 检索会在找不到答案时无限换词。

%% 图：一次 agentic 检索的真实轨迹（coding agent 找「支付失败怎么处理」）——grep payment 无结果 → 换词 grep charge 找到 3 处 → read 其中一个文件发现 handleDeclined → LSP 找它的引用 → 读到重试逻辑 → 回答；每一轮的结果进上下文，大结果要卸载；步数上限与循环检测在外面兜着
flowchart TB
    Q["任务：支付失败在哪里处理？"] --> S1["① grep 'payment' → 无结果"]
    S1 --> S2["② 换词：grep 'charge' → 3 个文件"]
    S2 --> S3["③ read billing/charge.py（4K token → 超阈值，卸载留路径 + 预览）<br/>发现 handleDeclined()"]
    S3 --> S4["④ LSP：find references handleDeclined → 2 个调用者"]
    S4 --> S5["⑤ read retry/policy.py → 找到重试与降级逻辑"]
    S5 --> A["回答：在 retry/policy.py 的 on_declined，带文件路径与行号"]
    G["卫士：步数 ≤ 20 · token 预算 · 同一查询重复 3 次即停 · 「没有进展」检测"] -.-> S1
    G -.-> S5
    classDef step fill:#fff7e0,stroke:#c98a00,color:#222
    classDef miss fill:#fdecea,stroke:#c0392b,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef g fill:#eef6ff,stroke:#5b8fd6,color:#222
    class Q,S2,S3,S4,S5 step
    class S1 miss
    class A ok
    class G g

• 可预测性低：同一个问题两次走的路径不同（《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》的非确定性）；调试靠 trace（L5）：每一轮查了什么、返回了什么、为什么决定再查。

4. 检索工具的设计

检索工具的设计要素

要素	做法
粒度	一个工具一类检索；不要把所有检索合成一个”万能搜索”
返回	摘要 + 引用而不是全文：每条结果给标题、一两句摘要、id、相关分；全文用 read(id) 另取——这是 《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》卸载原则的应用
数量	每次返回上限（5–10 条），让模型翻页而不是一次吐 50 条
过滤	参数里暴露元数据过滤（时间、类型、来源），让模型能收窄
权限	工具内部按调用用户过滤（第四篇），模型无法绕过
失败	返回”无结果 + 建议”（”没有匹配，试试同义词 X 或去掉时间限制”）而不是空——帮模型决定下一步
幂等与缓存	同一查询重复调用返回缓存结果，省钱且防止模型反复查同一件事

5. 与 rerank 的关系

agentic 检索里 rerank 的收益变小：模型自己在多轮里筛选，且每轮只需”有线索”。但每轮返回的排序仍影响模型看到什么——保留轻量 rerank 或用 RRF 的排序即可。

四、供应商内置的 file search

OpenAI Responses 的 file search、Gemini 的 file search、Anthropic 的 files 与相关工具，都提供”上传文件、供应商建索引、模型调用检索”的一体化能力。在协议上它们是服务端工具（《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》「三、工具调用是一个协议」）：模型决定调用、供应商执行、结果直接回到模型、你的代码不经手。

供应商内置 file search 的得与失

你得到	你失去
零基础设施：不用管解析、分块、embedding、向量库	解析与分块的控制（第三篇的三个失败你看不到也修不了）
与模型的紧密集成，几行代码上线	embedding 与 rerank 的选择
供应商维护的更新	权限过滤：多数内置 file search 以”文件集合”为粒度，细粒度 ACL 要靠你按用户建不同集合
	检索过程的可观测（返回了什么、为什么）
	可移植性：换供应商索引要重建

适合：单用户或小团队的文档问答、原型、语料小且权限简单的场景。不适合：企业级权限、需要调解析与分块、多供应商策略。一个务实的路径是用它做原型验证价值，需要控制时再换自建流水线——两者对模型的接口（工具调用）相同，切换成本主要在索引侧。

五、决策

1. 三问

选流水线还是 agentic 的三问

问	倾向流水线	倾向 agentic
问题形态稳定吗？	稳定（FAQ、文档定位）	多变（分析、研究、调试）
需要多跳吗？	不需要	需要
延迟与成本要可预测吗？	要（面向用户的同步问答）	可接受不定（后台任务、专业用户等得起）

三问都倾向流水线就用流水线加第二章的改进；都倾向 agentic 就做工具；混合时——最常见——流水线做默认路径，agentic 做兜底：先一次检索生成，自检不够时升级到 agent 循环（有步数上限），把不定的成本只花在难题上。这与 《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》的级联分流是同一个思路。

%% 图：级联——流水线做默认路径（一次改写 + 混合检索 + rerank + 生成，结构化输出里带 sufficient 字段），自检够了直接返回；不够才升级到 agent 循环（有步数上限、卸载、清理），把不定的成本只花在难题上；大多数请求走上面那条便宜可预测的路
flowchart TB
    Q["用户问题"] --> P["流水线：改写 → 混合召回 → RRF → rerank → 生成<br/>输出含 sufficient 字段"]
    P --> C{"sufficient？"}
    C -->|"是（多数请求）"| A1["返回：延迟几百毫秒 + 一次生成，成本固定"]
    C -->|"否（难题）"| AG["agent 循环：三类检索工具<br/>步数上限 · 每轮返回上限 · 卸载 · 清理"]
    AG --> A2["返回：延迟与成本不定，只花在这部分"]
    classDef step fill:#fff7e0,stroke:#c98a00,color:#222
    classDef dec fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef exp fill:#fdecea,stroke:#c0392b,color:#222
    class Q,P step
    class C dec
    class A1 ok
    class AG,A2 exp

2. 与 《Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索》的决策表接上

L2 给了全放上下文 / 流水线检索 / agentic 三选一的四个维度（语料大小、变化频率、查询类型、缓存后成本）；本篇补的是后两者之间怎么选、以及中间的渐进路。合起来：小而稳定全放；大语料 + 定位型 → 流水线 + 改写 + 混合 + rerank；大语料 + 多跳 / 探索 → agentic 工具 + 卸载 + 步数上限；混合 → 级联。

六、实践建议

1. 先把流水线做好：混合 + rerank + query 改写 + 元数据路由，这四步解决大多数问题，且延迟成本可控。
2. 加自检一轮：结构化输出里加 sufficient 字段，不够改写再查一次，上限一轮；看它解决了多少之前答不出的问题。
3. 把三类检索做成工具再给 agent：描述写清各自适合什么，返回摘要 + 引用、有上限、有过滤、有失败建议、有缓存。
4. agentic 检索必配：步数上限、每轮返回上限、大结果卸载、旧结果清理、按任务的成本分布监控。
5. 级联：流水线默认、agentic 兜底，只在难题上花不定的成本。
6. 内置 file search 用于原型，需要权限与控制时换自建；两者的模型接口相同。

七、本文小结

• 流水线（一次检索、代码决定、可预测、召回压力高、无多跳）与 agentic retrieval（模型决定查什么查几轮、召回压力低、天然多跳、成本延迟不定）各有适用；中间有一条渐进的路：query 改写、HyDE、多查询与拆分、元数据路由、自检加有限重试。
• agentic 换到召回压力下降、多跳、检索类型可选、问题形态不用预设；付出成本延迟不定（按任务看分布）、上下文增长（卸载清理必需）、工具描述决定行为、循环控制、可预测性低（靠 trace）。
• 检索工具的设计：一类一工具、返回摘要 + 引用、有上限、暴露过滤、内部做权限、失败给建议、幂等缓存。
• 供应商内置 file search 是服务端工具：零基础设施换失去解析、分块、embedding、权限、可观测的控制；适合原型与简单场景。
• 决策三问（形态稳定？多跳？可预测？）；最常见的答案是级联——流水线默认、agentic 兜底。

八、自测

1. 对话式 RAG 里用户第三轮问”那它呢？”，直接拿这句话检索会怎样？该加哪一步？

   答案

   “那它呢”没有关键词、有指代，检索结果随机。加 query 改写：让模型结合对话历史把它改写成完整的检索查询（”产品 B 的保修期”），一次小模型调用几百毫秒。对话式 RAG 几乎必需。详见第二章。

2. HyDE 为什么能缓解词汇不匹配？它的风险是什么？

   答案

   问题与文档在不同的语义空间（提问 vs 陈述），假想答案与文档都是陈述、词汇更接近，向量距离更小。风险：假想答案跑偏（编造了错误的方向）时检索跟着偏；且多一次生成。适合词汇不匹配严重、问题简短的语料。详见第二章。

3. 一个 agentic 检索工具每次返回 50 条结果的全文。按第三章列出至少四个问题与修法。

   答案

   （1）上下文爆炸：50 条全文每轮进上下文，几轮后触顶——改为返回摘要 + 引用，全文用 read(id) 另取（卸载）；（2）没有上限：模型无法翻页收窄——每次 5–10 条，支持分页；（3）没有过滤参数：模型不能按时间 / 类型收窄——暴露元数据过滤；（4）可能没做权限——工具内部按调用用户过滤；（5）失败时返回空让模型无从下手——返回建议；（6）重复查询重复花钱——加缓存。详见第三章。

4. 一个面向公众的客服问答，p95 延迟要求 3 秒，问题多为定位型但 15% 需要两跳。该用什么架构？

   答案

   级联：流水线做默认（混合 + rerank + query 改写 + 元数据路由，延迟可控），生成前自检，不够时升级到有步数上限（如 2–3 轮）的 agentic 循环——把不定的成本只花在 15% 的难题上；对超出延迟预算的难题降级为”转人工 / 稍后回复”。不要全量 agentic（延迟不可预测），也不要纯流水线（15% 答不了）。详见第五章。

5. 团队用 OpenAI 的内置 file search 做了一个全公司文档问答，上线后发现员工能搜到不属于自己部门的合同。原因与修法？

   答案

   内置 file search 以文件集合为粒度，没有按用户的细粒度 ACL（access control list）；所有文档在一个集合里，检索对所有人一样。修法：按权限组建不同的文件集合并按用户路由（粗粒度、维护成本高），或换自建流水线在召回时按块的 ACL 过滤（第四篇）。这是内置工具”失去权限控制”的具体代价。详见第四章。

---

• 上一篇
  检索与知识接入（04）：索引、混合检索与 rerank

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。