S02 检索范式对照矩阵

一个知识产品的 PM 真正要回答的问题，从来不是”我们要不要做 RAG”，而是这一类查询，应该把信息从哪里取——是去模型权重里取（parametric）、去向量库取、去知识图谱取、去实时 web 取，还是让 Agent 在多源之间动态决定。本节点要解决的问题是：把这六条检索范式放在同一张可对照的矩阵里，给出一棵能在选型会上当场画出来的决策树，并标清每条分支在什么场景会失效。这是「知识作为产品」的设计视角，不是 RAG 的工程实现细节——后者请直接读 c09 - RAG 架构与 m203 - RAG 生产环境：Embedding 与文档解析 m204 - RAG 生产环境：Chunking 与范式演进 m205 - RAG 生产环境：索引运维与评估体系，本节点不复述。

§0 为什么是”检索去向”而不是”检索算法”

大多数检索对照文章比的是算法：BM25 vs 向量 vs 重排序，谁的召回高。这是工程框架，对 PM 是错的默认框架。PM 要比的是检索去向（where does the knowledge live）——因为去向决定了产品的五个根本属性：时效性、可溯源性、成本结构、合规表面积、失效模式。一个把”是否需要最新信息”和”是否需要可审计”这两条搞清楚的 PM，比一个能背出 RRF 融合公式的 PM 更早做对选型决策。

所以本矩阵的横轴是六条检索去向，纵轴是五个产品维度。先说清这六条不是同一层的东西：parametric（参数记忆）和 non-parametric（向量/KG/web）是记忆类型的根本分野（Wang et al., Knowledge Mechanisms in LLMs, EMNLP 2024 Findings, arXiv:2407.15017）；向量、KG、web-search 是 non-parametric 内部的三种数据形态；混合检索（hybrid）和 Agentic 检索是组合策略，不是第七种数据源。把这层次理清，矩阵才不会变成苹果和橙子的乱炖。

§1 六条范式的一句话定位

范式	知识住在哪	一句话产品定位
Parametric Memory	模型权重里	零外部依赖、最低延迟，但知识冻结在训练截止点、不可审计
关键词检索（BM25/词法）	倒排索引	精确匹配专有名词/产品代码的”老技术不死”
向量检索（Embedding）	向量库	语义相似匹配，“找意思像的”，非结构文本主力
知识图谱（KG/GraphRAG）	实体-关系图	多跳推理与”联通性”问题，可溯源性强
混合检索（Hybrid）	词法+向量+图双/三路	2025 生产共识，互补各自盲区
实时 Web Search	公开互联网	时效性天花板，但引用质量是硬伤

注意：Agentic 检索不在此表，它是让模型动态决定调用上面哪几条的元策略，单列于 §4。

§2 五维对照矩阵（决策的核心证据）

维度	Parametric	关键词/BM25	向量检索	知识图谱	实时 Web
时效性	最差（冻结于训练截止）	取决于索引刷新	取决于索引刷新	最差（图谱构建滞后，动态数据维护难）	最强（反映当前状态）
可溯源性	几乎无（难审计、难定位来源）	中（命中文档可见）	中（chunk 可见，但语义命中难解释）	强（实体路径可追溯，受监管行业首选）	弱-中（引用存在但常错位，见 §3）
成本结构	推理成本，更新须重训（周-月级）	索引廉价，查询极廉	前期高（摄入+嵌入），边际低	构建成本最高，“写少读多”才划算	每次查询成本高（实时 API/爬取）
精度	通用常识强，专业细节易幻觉	专有名词/精确匹配最优	语义模糊查询最优	多跳/关系推理最优	取决于检索源质量，噪声大
适用场景	通用推理、无时效要求的常识	产品代码、团队名、专名查询	非结构文本语义问答	关系明确+合规可审计	新闻、股价、实时数据

这张矩阵里有三个反共识判断，值得 PM 钉在墙上：

判断一：向量检索不是默认答案，关键词检索在企业里常常赢。 业界把”做 RAG”几乎等同于”做向量库”，但实测显示，混合检索（BM25 词法 + 向量语义）比纯向量搜索 Precision@5 平均高 12–19%（largitdata.com, 2025），且企业特有实体查询（产品代码、团队名称、专有名词）中 BM25 词法排序优于 embedding（tianpan.co, 2026）。Microsoft 自家披露，约 60–70% 企业查询用传统词法搜索（BM25 + 时效性）已足够（Glean 架构分析，ZenML LLMOps Database, 2023）。把所有查询都送进向量库，是用最贵的工具解最便宜的问题。

判断二：知识图谱的精度优势有明确的成本对价，不是免费午餐。 Microsoft GraphRAG（Edge et al., From Local to Global, arXiv:2404.16130, 2024）在综合性（comprehensiveness）上比传统 RAG 提升 72–83%、多样性提升 62–82%，根级摘要 token 减少最高 97%——数字很漂亮。但同一份研究的边界是：GraphRAG 构建成本高，对频繁变化的数据维护困难，只适合”写少读多”的稳定知识库。LinkedIn 的 KG-RAG 客服系统（Xu et al., arXiv:2404.17723, SIGIR 2024）MRR 提升 77.6%、问题中位解决时间降低 28.6%，但前提是它建在历史工单这种结构稳定的语料上。频繁更新的知识库用 KG，维护成本会吃掉精度收益。

判断三：实时 Web Search 的时效性最强，但可溯源性是它最被高估的属性。 Tow Center / Columbia Journalism Review 的研究（2025-03，200 条新闻查询，8 个 AI 搜索引擎，经 Nieman Lab 报道）发现：超过 60% 的查询返回不正确引用；表现最好的 Perplexity 失败率仍达 37%，最差的 Grok-3 Search 高达 94%。“AI 能给你引用”和”引用是对的”是两件事——这是知识产品信任设计的核心裂缝，详见 A03 Citation 与 Attribution 产品设计（同专题·引用与归属）与 c13 - 幻觉的不可消除性。

§3 判断主轴：选检索范式时 90% 的人会搞错的五个点

这是本节点的命门——每点带”症状 → 为什么会错 → 正确做法 → 真实反例”。

错位一：把”长上下文窗口”当成检索范式的替代品。

症状：PM 说”现在 1M token 窗口了，把全文塞进去就行，不用做检索。”
为什么会错：注意力成本随上下文长度近似 O(N²)，且 lost-in-the-middle 问题持续存在——长文档中部信息被系统性忽略。RAGFlow 2025 年评述直接把”全文塞入”称为”暴力策略”，会导致”信息洪水（information flooding）“效应，成本禁止性高。
正确做法：长上下文是检索的补充（放置已检索的精排结果），不是替代。
真实反例：“RAG is DEAD”论点在 2024–2025 反复出现，但 RAGFlow 年终回顾（2025）记录到，主流是 RAG 演化为”上下文引擎（Context Engine）“，而非消失。

错位二：把”Agents 替代 RAG”当成已发生的事实。

症状：“我们上 Agent，就不用 RAG 了。”
为什么会错：Agents 恰恰依赖检索做三类事——领域知识、对话历史、工具元数据。RAGFlow 把”Agents 替代 RAG”评为”市场营销话术（market-driven stunt）“，会误导非专家。
正确做法：Agentic 检索是 RAG 的演化形态（动态决定何时检索什么），是补充非替代。
真实反例：Modular / Agentic RAG 架构（Self-RAG、FLARE、A-RAG）全部以检索为核心算子，没有一个抛弃了检索。

错位三：用参数记忆答需要时效性的问题。

症状：直接问模型”最新的 X 政策是什么”，拿回一个自信但过时的答案。
为什么会错：参数知识冻结于训练截止点，且更隐蔽的是——训练数据混排（shuffled）会稀释时序信号，模型对近期事实的准确率甚至骤降至接近随机（Fabre et al., Understanding Data Temporality Impact on LLM Pre-training, arXiv:2605.22769, 2026，已 WebFetch 核实）。用户感知到的”模型不知道近期事情”，部分不是截止日期问题，而是训练分布问题。
正确做法：任何带时效性的查询强制走 web-search 或实时检索分支。
真实反例：HoH 基准（Ouyang et al., arXiv:2503.04800, 2025）发现，即使知识库中同时存在当前正确信息，过时事实仍可诱导模型生成错误甚至有害输出——时效性不只是”有没有最新数据”，还是”检索排序和生成提示是否注入时序约束”。

错位四：把”引用数量多”等同于”可信”。

症状：选 Perplexity 因为它引用最多（每响应均 21.87 条，vs ChatGPT 7.92，来源 Whitehat SEO, 2025）。
为什么会错：引用数量 ≠ 引用质量。Liu et al.（EMNLP 2023, arXiv:2304.09848）的基础研究发现，生成式搜索引擎中仅 51.5% 的句子被引用完全支撑，74.5% 的引用确实支撑对应声明——斯坦福 HAI 称这些系统有”虚假可信度的表象（facade of trustworthiness）”。
正确做法：把引用准确率（而非数量）作为选型指标，并在产品层做来源核验。
真实反例：Perplexity 46.7% 引用来自 Reddit（DiscoveredLabs, 2026），数量碾压但来源质量分歧巨大。

错位五：在企业场景用纯参数记忆，绕过权限。

症状：“让模型直接答员工问题，省去检索基础设施。”
为什么会错：参数记忆不可审计、不可删除，违反企业合规（数据可删除性、可审计性）要求；且向量层本身可能成为权限提升向量（privilege escalation vector）——权限受限用户可通过查询触发对无权限文档的检索（tianpan.co, 2026-05）。
正确做法：企业生产场景禁用纯参数记忆，走 non-parametric（RAG/KG）+ 查询时 ACL 过滤（query-time access control），文档检索时即过滤，不进入模型视野。
真实反例：Glean 采用查询时 ACL 过滤而非应用层事后过滤，正是为了避免无权限文档进入模型处理流程。

§4 Agentic 检索：第七条路是”让模型自己选路”

传统 RAG 有两条死路：单次检索拼接（single-shot concatenation）和刚性预定义工作流。Agentic 检索的突破是让模型主动参与检索决策——何时检索、检索什么、用什么策略。三个里程碑：

方法	机制	关键创新
Self-RAG（Asai et al., 2023/2024）	反思 token（IsREL/IsSUP/IsUSE）评估是否需检索及检索质量	检索按需触发，非每次都查
FLARE（Jiang et al., 2023）	生成置信度下降时主动触发检索	预判未来信息需求
A-RAG（Du et al., Scaling Agentic RAG via Hierarchical Retrieval Interfaces, arXiv:2602.03442, 2026）	暴露三工具（关键词/语义/chunk 读取），代理分层选择	可随模型规模扩展的层级检索接口

A-RAG 据称以同等或更少 token 持续优于现有方法，并随模型规模提升而系统性增强。需要标注边界：Self-RAG 的反思 token 训练成本高，在小模型上效果不稳定，仍是活跃研究领域，无定论。Agentic 检索不是银弹——它把”选路”的复杂度从工程显式逻辑搬进了模型黑盒，调试更难。

§5 决策树：这一类查询，该用哪种检索

这是本节点对 PM 的核心交付物——一棵能在选型会上当场画出来的树（综合 GraphRAG 研究、RAGFlow 评述、A-RAG、Salfati Group 指南）：

用户查询
│
├─ 需要最新信息（新闻/实时数据/股价）？
│   └─ 是 → 实时 Web Search（Perplexity / ChatGPT Search）
│           ⚠ 产品层必须做引用核验，失败率 37%+
│
├─ 是内部/私有知识库问答？
│   ├─ 关系结构清晰 + 多跳推理 + 需可审计 → 知识图谱 / GraphRAG
│   │       ⚠ 仅限"写少读多"的稳定语料
│   ├─ 含专有名词/产品代码/精确匹配 → 关键词 BM25（或混合）
│   ├─ 语义模糊 + 非结构文本 → 向量检索
│   └─ 以上皆有（多数真实场景）→ 混合检索（词法+向量[+图]）
│
├─ 通用常识 / 无时效性推理？
│   └─ 是 → Parametric Memory（直接调用模型，最低成本）
│
├─ 需要多步跨源合成研究？
│   └─ 是 → Agentic / Deep Research（Self-RAG / A-RAG / Deep Research 产品）
│
└─ 企业生产（合规/可审计/可删除）？
    └─ 强制 → Non-Parametric（RAG 或 KG）+ 查询时 ACL，禁用纯参数记忆

关键提醒：现实里**“双轨架构是工业现实”**——静态内容用索引（低延迟），高频变化数据用实时检索（无快照滞后）。单纯缓存或单纯实时都有严重短板（Unified.to, 2025；RAGFlow 年终回顾, 2025）。决策树的叶子节点常常不是单选，而是按查询类型路由到不同分支。

§6 产品 PM 视角补盲

工程 PM 看检索看召回率，产品 PM 要看三个”看走眼”点：

用户心理模型错配：用户对”AI 给的答案”和”搜索给的链接”信任度不同——zero-click 时代，“AI 的回答 = 用户对品牌的直接体验”（aiopsschool.com, 2026）。检索范式选错（如 web-search 引用错位）直接污染品牌信任，不只是技术 bug。
成本结构决定商业模式：Perplexity 产品形态领先但单位经济亏损（搜索+LLM 双成本）。实时 web-search 的每查询成本高，是 PM 必须在定价时算清的账，不是工程细节。
合规表面积是隐性约束：缓存索引把数据复制进向量库，需单独权限管控；实时检索继承源系统权限，合规表面积小。这条在受监管行业（金融/医疗）是一票否决级约束。

§7 对手框架回应

接受 + 边界，不是反驳：

接受”长上下文派”对的部分：当文档总量小、且查询需要全局理解时，全文塞入确实优于碎片化检索。边界：一旦语料规模超过单次窗口经济区间，或查询是精确定位型，检索的成本和精度优势压倒长上下文——“information flooding”已被实验记录（RAGFlow, 2025）。我赌的是：未来 2–3 年，绝大多数生产知识产品仍以检索为核心，长上下文是其辅助而非替代。
接受”GraphRAG 怀疑派”（Gartner 分析师 Matt Aslett：“我在数据领域 20 年，至少一半时间有人说知识图谱是未来的路”；Infosys 的 Anant Adya 指多数企业 KG PoC 未进生产）对的部分：KG 的讨论热度确实远高于落地率。边界：在 Novartis（药物发现）、Intuit（安全平台）这类关系密集+可审计要求高的场景，KG 已规模化——它不是普适解，但在它该赢的窄场景里没有替代品。

§8 PM 决策启示

面试怎么用：被问”你怎么做 RAG”时，先反问”什么类型的查询、要不要时效性、要不要可审计”——把单维技术问题升维成检索去向决策，立刻显出框架高度。
选型怎么用：把 §2 矩阵和 §5 决策树打印出来，在选型会上对着真实查询样本逐条走分支，而不是泛泛比 feature list。
复现怎么用：先用最便宜的范式（BM25/参数记忆）建 baseline，只在它失效的查询子集上升级到向量/KG/web——成本梯队由低到高，不要一上来就上 GraphRAG。

§9 与已有节点的关系

对照 c09 - RAG 架构：c09 讲 RAG 的工程解构（非参数化记忆管线、分块、混合检索、Reranker）。本节点做的是升维补缺——把 RAG 放回”六条检索去向”的更大对照系里，回答”何时根本不该用 RAG（而用参数记忆/web/KG）“。不复述 c09 的 RRF 融合、HyDE 等技术细节。
对照 m203 - RAG 生产环境：Embedding 与文档解析与 m204 - RAG 生产环境：Chunking 与范式演进：m203/m204 讲 embedding 选型与 chunking 工程。本节点是前置决策——在决定 chunk 之前，先决定”这类查询要不要走向量检索”。做的是对话+前置，不是深化其工程内容。
对照 c13 - 幻觉的不可消除性：c13 论证幻觉是架构性特征。本节点把它落到检索层——web-search 的引用错位（37% 失败率）是 c13”引用幻觉”在产品层的实证，二者交叉引用。

§10 关联节点

核心（必读）

延伸（可选）

修订日志

2026-06-07 R0：首稿。建立六范式 × 五维对照矩阵 + 决策树，判断主轴五点（长上下文/Agents 替代/参数记忆时效/引用数量≠质量/企业权限），接地至 EMNLP 2024、GraphRAG arXiv:2404.16130、SIGIR 2024、Tow Center 2025、HoH arXiv:2503.04800、Fabre arXiv:2605.22769。A-RAG arXiv:2602.03442 经 WebFetch 验证（Du et al., 2026，标题与作者确认）。