如果RAG的“检索端问题占90%”已经被反复验证，而GraphRAG、Vectorless RAG、Adaptive RAG又各自在“多跳、结构化定位、按问题类型路由”上开出新路，一个现在要建企业知识库的人，到底该先回答“我的用户到底在问什么类型的问题”（单跳事实、多跳关系、还是从复杂文档里精确定位），再反推架构，而不是从“选哪个最先进的技术”开始——这个从问题分布出发的选型顺序，在实际项目里到底

摘要

检索增强生成（Retrieval-Augmented Generation, RAG）在企业知识库场景中的失败，越来越多地被归因于检索端而非生成端。与此同时，GraphRAG、Vectorless RAG、Adaptive RAG 三条技术路线分别在多跳关系推理、结构化精确定位、按问题类型动态路由上给出了新解法。本文的核心主张是：企业知识库选型的正确顺序不是“挑最先进的技术”，而是先量化自身用户的问题分布——单跳事实、多跳关系、复杂文档精确定位各占多少——再反推架构组合。围绕这条主线，本文给出问题分布的可操作测量方法、三类架构的机制与边界条件、路由层的工程设计、以及一套防止被 Demo 效果误导的离线评测与上线灰度流程。全文强调：架构选择的本质是对问题分布的先验估计，而不是对技术热度的追随。

目录

一、导语：被“检索端占90%”反复验证的选型焦虑

在企业知识库的 RAG 项目复盘中，一个被反复引用的经验判断是：系统回答错误中约九成可以追溯到检索环节——要么没召回正确片段，要么召回了但排序靠后，要么召回的片段本身不足以回答问题。这个比例在不同团队、不同语料、不同模型下会有浮动，但它指向的工程事实是稳定的：生成模型的能力在近两年提升很快，而检索质量受制于语料结构、切分策略、查询表达与索引方式，改善更慢、更依赖场景。

于是出现了一个典型的选型困境。团队 A 在 Demo 里看到 GraphRAG 能把“某供应商的二级供应商是否涉及某类合规风险”这类多跳问题答得头头是道，决定上图谱；团队 B 看到 Vectorless RAG 在长表格、条款编号、专利权利要求这类结构化文档上定位精准，决定弃用向量库；团队 C 看到 Adaptive RAG 能按问题类型自动路由，觉得这才是“终极形态”。三个团队都做了漂亮的 POC，三个月后，A 发现自己的用户 80% 的问题其实是单跳事实查询，图谱构建与维护成本压垮了收益；B 发现自己的用户大量在问跨文档的关系问题，纯结构化定位召回不足；C 发现路由分类器本身成了新的错误来源，且延迟翻倍。

本文评述：上述困境的根源不是技术选错了，而是选型的起点错了。从“哪个技术最先进”出发，得到的是技术的能力清单；从“我的用户到底在问什么类型的问题”出发，得到的才是需求的分布函数。前者是供给视角，后者是需求视角。企业知识库是一个需求高度异质的系统，用单一供给去匹配异质需求，必然在某个子分布上过度投入、在另一个子分布上投入不足。

本文要回答的正是这个被跳过的中间环节：如何把“用户到底在问什么类型的问题”变成可测量、可验证、可指导架构决策的东西，并在实际项目中不被 Demo 效果带偏。全文的分析主线是一条“需求分布 → 失败模式 → 架构匹配 → 路由与评测闭环”的因果链，每一环都给出可操作的步骤与可验证的依据。

二、问题定义：三类问题、三种检索失败模式

2.1 三类问题的准确定义

在讨论架构之前，必须先把“问题类型”定义清楚。企业知识库中的用户问题，按回答所需的最小证据结构，可以划分为三类：

（1）单跳事实型（single-hop factual）。回答只需一个文档片段中的一条或几条相邻事实，例如“报销标准里差旅住宿的上限是多少”“某产品的保修期是多久”。其证据结构是“一个片段 → 一个答案”，检索的目标是命中率（recall@k）。

（2）多跳关系型（multi-hop relational）。回答需要跨两个及以上片段、沿实体或关系链条组合证据，例如“负责某项目的团队负责人，其上一级汇报对象还分管哪些预算”。其证据结构是“多个片段 + 连接关系 → 一个答案”，检索的目标不仅是命中，还要保证连接路径完整。

（3）复杂文档精确定位型（structured pinpointing）。回答所需证据存在于长文档的特定结构位置——条款编号、表格单元格、权利要求项、附录条目——问题本身带有强结构线索，例如“第 7.3 条第（二）款对违约金上限是怎么规定的”。其证据结构是“结构坐标 → 精确片段”，检索的目标是定位精度（precision）与结构对齐。

2.2 三种检索失败模式的对应关系

把问题类型与检索失败模式对齐，是理解“为什么不同架构有效”的关键。笔者认为，三类问题分别对应三种可区分的失败模式，且这三种失败模式无法用同一种检索机制同时压到很低——这是架构必须组合而非单选的深层原因。

本文评述：这张表的价值在于，它把“技术选型”翻译成了“失败模式覆盖问题”。当你选择 GraphRAG 时，你真正买到的是对“路径断裂”的覆盖；选择 Vectorless RAG，买到的是对“定位漂移”的覆盖；选择 Adaptive RAG，买到的是“按问题切换覆盖策略”的能力。如果一个团队连自己的失败模式分布都没测过，那么任何架构选择都是盲选。

三、问题分布测量：把“用户到底在问什么”变成可计算指标

3.1 数据来源：三类真实查询的采集

问题分布不能靠拍脑袋，必须来自真实查询日志。可用的来源按可信度排序为：（a）现有系统的查询日志（如有客服工单、内部搜索、IM 机器人记录）；（b）业务专家的访谈与历史问答对（用于补充低频但高价值的问题）；（c）冷启动阶段的受控采样（让真实用户在试用环境中提问，而非让团队自造问题）。

一个常见的错误是用“团队自己想到的问题”作为分布样本。这类样本系统性偏向技术团队熟悉的知识域，且倾向于构造“看起来有难度”的多跳问题，从而高估多跳需求占比。工程上应明确：分布估计的样本必须来自真实用户，且要覆盖不同角色、不同资历、不同业务线。

3.2 标注方案：软标签与多标签

对每条查询，让标注者给出三类成分的软标签（例如单跳 0.8、多跳 0.2、定位 0.0），而非硬分类。软标签的好处是保留了问题的混合性，后续可以用加权方式计算分布。标注指南应给出可判定的操作定义，例如：

标注规则（示例）
1. 若回答所需证据可在单个 ≤512 token 片段内完整获得 → 单跳成分 ≥ 0.7
2. 若回答必须连接 ≥2 个不同文档/章节的实体或事实 → 多跳成分 ≥ 0.6
3. 若问题中出现条款号、表格名、附录编号、权利要求序号等结构坐标
   且答案依赖该坐标 → 定位成分 ≥ 0.6
4. 三类成分之和归一化为 1.0；无法判定时标记为 uncertain，单独统计

标注一致性用 Cohen's κ 或 Krippendorff's α 检验，工程上建议 α ≥ 0.65 才可用于决策；低于此值说明标注指南需要迭代。样本量方面，若希望三类占比的估计误差控制在 ±5%（95% 置信），按比例估计的样本量公式 n = z²p(1−p)/e²，取 p=0.5 的最坏情况，约需 385 条；考虑分层与不确定样本，实际建议采集 800–1500 条真实查询。

3.3 从分布到架构权重

得到分布后，不要直接“占比最高的类型决定架构”，而应结合业务价值权重。一个可操作的公式是：

Score(type) = Σ_i  w_i × p_i(type) × v_i

其中：
  p_i(type) = 第 i 个业务线中该问题类型的占比
  v_i       = 该业务线单次错误回答的业务代价（可货币化或分级）
  w_i       = 业务线查询量权重

本文评述：这个公式的意义在于把“占比”升级为“期望损失覆盖”。一个占比只有 15% 但单次错误代价极高的多跳问题（如合规风险传导），其架构优先级可能高于占比 60% 但错误代价低的单跳查询。很多团队在选型时只看占比，忽略了代价维度，导致在高价值子分布上投入不足。

四、三条技术路线的机制拆解与适用边界

4.1 GraphRAG：把“关系”显式化

GraphRAG 的核心机制是在离线阶段用大模型从语料中抽取实体与关系，构建知识图谱，并在查询时沿图结构做社区摘要或子图检索。微软研究院在 2024 年提出的 GraphRAG 方法（Edge et al., 2024）系统化了这一路线：先做实体/关系抽取与社区检测，再为每个社区生成摘要，查询时结合社区摘要与局部子图。其公开报告显示，在“全局性、需要跨文档综合”的问题上，相比朴素向量 RAG 有可观测的提升。

适用边界很明确：当多跳问题占比显著、且实体关系相对稳定时，图谱的边际收益最高。反之，若语料更新频繁、实体抽取质量不稳定、或问题以单跳为主，图谱的构建与维护成本（抽取、消歧、增量更新、社区重算）会成为负担。工程上尤其要注意实体消歧——同一实体在不同文档中的别名、缩写、指代，是图谱质量的最大杀手。

本文评述：GraphRAG 常被误解为“更高级的 RAG”，其实它是一种用离线计算换在线推理的架构：把“跨文档连接”这件在线难以做好的事，提前在离线图谱里做好。因此它的经济性取决于“同一批关系被复用的次数”。如果多跳问题高度分散、每次涉及的关系都不同，离线图谱的复用率低，性价比就下降。这一点在选型时常被忽略。

4.2 Vectorless RAG：把“结构”当索引

Vectorless RAG 是一类方法的统称，其共同点是不依赖稠密向量相似度作为主检索通道，而是利用文档的显式结构（标题层级、条款编号、表格、页面坐标、关键词倒排）做定位。典型实现包括：基于文档树的结构化检索、基于 BM25/稀疏检索的精确匹配、基于布局解析的表格定位、以及“先定位章节再在章节内检索”的两级策略。

它的优势在于可解释、可精确、对结构线索敏感。当用户问题里带有“第几条”“哪个表”“附录几”这类坐标时，结构化定位的精度远高于语义相似度。其局限也同样明显：对表述多样性鲁棒性差——用户不会总用文档里的原词提问，同义改写、口语化表达会让纯关键词/结构匹配失效。因此工程上更现实的做法是混合：结构定位负责“缩小范围”，语义检索负责“在范围内找对片段”。

关于稀疏检索的经典依据，可参考 BM25 的原始工作（Robertson & Zaragoza, 2009）以及稀疏-稠密混合检索的实证研究（如 Karpukhin et al., 2020 的 DPR 对比、Thakur et al., 2021 的 BEIR 基准）。BEIR 的一个重要结论是：没有单一检索方法在所有任务上占优，域外泛化时 BM25 常是强基线。这一结论直接支持“按问题类型组合检索通道”的思路。

4.3 Adaptive RAG：把“选择”本身做成系统

Adaptive RAG 的核心思想是按查询难度或类型动态选择检索策略。代表性工作包括 Self-RAG（Asai et al., 2024）通过反思令牌决定是否检索与如何检索，以及 Adaptive-RAG（Jeong et al., 2024）训练一个查询复杂度分类器，将查询路由到“不检索 / 单步检索 / 多步检索”三条路径。其价值在于避免用重策略处理简单问题，从而在整体上平衡质量与成本。

但路由本身引入新的失败面：分类器误判会把问题送到不合适的通道，且路由延迟叠加在检索延迟之上。工程上必须回答三个问题：路由分类器的准确率与混淆矩阵如何？误判的代价是否可接受？是否有“兜底通道”（如误判时回退到混合检索）？没有这三问的答案，Adaptive RAG 就只是一个更复杂的单通道系统。

本文评述：Adaptive RAG 常被当作“终极形态”，但笔者认为它更像架构的编排层而非替代层。它不生产新的检索能力，只决定何时用哪种能力。因此它的上限由被编排的各通道决定，它的风险则由路由错误率决定。把 Adaptive RAG 当作起点而非终点，是避免“为了自适应而自适应”的关键。

4.4 三条路线的机制对照

五、从问题分布反推架构：决策矩阵与工程步骤

5.1 决策矩阵

把第三章的分布结果与第四章的机制对照，可以得到一个可操作的决策矩阵。矩阵的行是主导问题类型，列是推荐的基础架构与增强项：

本文评述：矩阵中“暂缓项”一列比“推荐项”更重要。工程实践里最常见的浪费，是在单跳为主的场景里上图谱、在定位为主的场景里上大规模语义索引。明确“现在不做什么”，是防止被 Demo 带偏的第一道闸门。

5.2 工程步骤：一个可执行的六步路径

步骤一：采集与标注。按 3.1–3.2 的方法采集 800–1500 条真实查询，完成软标签标注与一致性检验。产出：问题分布估计与置信区间。

步骤二：建立基线。先搭一个“混合检索 + 重排”的最小基线，在标注集上测 recall@k、nDCG@10、答案正确率。这一步的目的是拿到可比较的参照系，而不是追求最好。

步骤三：按失败模式归因。对基线答错的样本逐条归因到“召回缺失 / 路径断裂 / 定位漂移”三类，统计各自占比。这一步把“问题分布”转化为“失败模式分布”，是架构决策的直接输入。

步骤四：单点增强与消融。针对占比最高的失败模式，引入对应增强（图谱 / 结构定位），并做消融实验：只加该增强，其他不变，看指标变化。避免“一次上多个改动”导致无法归因。

步骤五：路由化。当多个增强并存且各自有适用子分布时，再引入路由层（见第六章），并单独评测路由准确率与误判代价。

步骤六：灰度与回流。上线后持续采集真实查询，定期重估分布，形成“分布漂移 → 架构再校准”的闭环（见第七章）。

六、路由层设计：Adaptive RAG 的工程化落地

6.1 路由器的三种实现与取舍

路由层是 Adaptive RAG 的工程核心。按实现复杂度，可分为三类：

（a）规则路由。用问题中的结构线索（是否含条款号、是否含“对比/关联/上级”等关系词、长度、实体数量）做启发式判定。优点是零训练成本、可解释；缺点是对表述变化敏感、规则维护成本随场景增长。

（b）分类器路由。训练一个小型分类模型（如基于编码器的多标签分类），输入查询，输出三类成分概率。优点是泛化好；缺点是需要标注数据、存在误判、需要持续监控漂移。

（c）LLM 路由。用大模型直接判断问题类型并选择通道。优点是灵活、可处理复杂表述；缺点是延迟与成本高、输出不稳定，需约束解码或结构化输出。

本文评述：三类实现不是替代关系，而是分层关系。工程上更稳的做法是“规则兜底 + 分类器主路由 + LLM 处理低置信样本”：规则处理高确定性的结构线索，分类器处理大多数查询，低置信时交给 LLM 或直接回退到混合检索。这样既控制了延迟，又保留了灵活性。

6.2 路由的评测：混淆矩阵与代价矩阵

路由器的评测不能只看准确率，必须看混淆矩阵与代价矩阵。因为不同误判的代价不对称：把多跳问题误判为单跳，会导致路径断裂、答案缺失；把单跳误判为多跳，只是多花一点计算。工程上应给每个误判格赋代价，计算期望代价，并据此设定阈值与兜底策略。

路由评测输出（示例结构）
混淆矩阵（行=真实，列=预测）：
            单跳   多跳   定位
  单跳       412     18     9
  多跳        27    156    11
  定位        14     12    98

代价矩阵（示例，单位：相对代价）：
            单跳   多跳   定位
  单跳        0      1      1
  多跳        5      0      3
  定位        4      3      0

期望代价 = Σ 混淆计数 × 对应代价 / 总样本数

上例中，把多跳误判为单跳的代价设为 5，是因为它直接导致答案缺失；而把单跳误判为多跳代价为 1，只是多算。这种非对称代价设计，能避免路由器为了“整体准确率”而牺牲高代价类别。

6.3 兜底与降级

任何路由系统都必须有兜底通道。可操作的降级策略包括：（1）低置信回退——分类器最大概率低于阈值时，走混合检索；（2）结果校验回退——目标通道返回的证据不足（如召回片段数低于阈值、答案置信度低）时，自动升级到更重的通道；（3）超时降级——重通道超时则返回轻通道结果并标注“可能不完整”。

这些策略的价值在于把“路由错误”从硬失败转化为软降级。工程上，软降级的用户体验损失远小于直接答错或超时。

七、防“Demo偏差”：离线评测集、指标与灰度流程

7.1 Demo 偏差的四种来源

Demo 之所以容易误导，是因为它在四个方面系统性偏离真实：（1）样本选择偏差——Demo 用的是精心挑选的、技术上有展示度的问题；（2）语料洁净偏差——Demo 语料通常经过清洗、结构规整，而企业真实语料充满扫描件、旧版本、矛盾表述；（3）评价偏差——Demo 只看“答对的那几个”，不看整体分布；（4）成本隐藏——Demo 不计离线构建成本与在线延迟。

本文评述：对抗 Demo 偏差最有效的手段不是“更谨慎地看 Demo”，而是建立一套与真实分布同构的离线评测集。评测集是架构决策的“计量标准”，没有它，所有比较都是印象比较。

7.2 评测集的构建原则

评测集应满足四条原则：分布同构（三类问题占比与真实分布一致）、语料真实（包含脏数据、旧版本、矛盾表述）、标注可验证（每条有标准答案与证据片段）、可分层报告（按问题类型分别报告指标，而非只报总体）。

关于检索评测的指标选择，可参考 BEIR 基准（Thakur et al., 2021）的做法：用 nDCG@10 作为主指标，辅以 Recall@k 与 MRR。生成侧可用答案正确率、忠实度（faithfulness）与证据覆盖率。RAGAS（Es et al., 2023）提出了一套面向 RAG 的自动评测指标（上下文相关性、答案忠实度、答案相关性），工程上可作为补充，但需注意其依赖 LLM 评判，存在评判偏差，应抽样人工校验。

7.3 灰度与回流

上线阶段建议采用影子模式 + 小流量灰度：影子模式下新架构与旧架构并行，只记录不展示，对比两者在同一批真实查询上的表现；小流量灰度下按用户/业务线分流，观察真实满意度与失败工单。回流机制应把线上失败样本自动进入评测集候选池，经人工确认后补充，形成“评测集随分布漂移而更新”的闭环。

关于 RAG 系统评测与失败分析的工程方法，可参考以下公开资源：RAGAS 官方文档、BEIR 基准代码库、微软 GraphRAG 项目页、Adaptive RAG 相关技术讲解视频。

八、关键数据与案例：公开基准与工业实践的可验证证据

8.1 公开基准上的可验证结论

为避免主观臆测，本节只引用可公开查证的基准与结论。需要说明的是，不同论文的实验设置（语料、模型、指标）差异很大，跨论文比较需谨慎；以下数据用于说明机制层面的趋势，不作为绝对性能承诺。

关于“检索端问题占比”的经验数字，公开文献中并无统一的、可复现的“90%”统计。工程界常引用的类似判断，多来自团队内部复盘，属于经验性估计而非严格统计。本文在引用时明确标注其性质：它是一个有用的启发式，提示团队优先排查检索，但不应被当作精确常数。若要用于决策，应在自有数据上重新统计。

8.2 一个模拟的工业案例（标注为模拟数据）

为说明方法如何落地，构造一个模拟案例（以下数据为模拟整合，用于演示分析流程，非真实企业数据）：某制造企业知识库含 12 万份文档（制度、合同、技术手册、工单），采集 1000 条真实查询并软标签标注，得到分布：单跳 58%、多跳 22%、定位 20%。基线混合检索的失败模式归因为：召回缺失 61%、路径断裂 24%、定位漂移 15%。按第五章步骤，先优化切分与查询改写（针对召回缺失），再对多跳子集引入迭代检索与轻量实体图，对定位子集引入结构感知解析与条款坐标索引。模拟结果显示（模拟数据）：单跳子集 recall@10 提升约 9 个百分点，多跳子集答案正确率提升约 14 个百分点，定位子集精确匹配率提升约 18 个百分点；整体延迟增加约 220ms，离线构建成本增加约 30%。

本文评述：这个模拟案例的重点不在数字，而在归因顺序：先解决占比最大的召回缺失，再处理多跳与定位。若顺序颠倒，先上图谱，则 61% 的召回缺失问题依然存在，整体收益被稀释，团队会误以为“图谱没用”。这正是“从问题分布出发”相对于“从技术出发”的实操价值。

九、对比与局限：三条路线的成本、延迟与失效条件

9.1 成本结构对比

三条路线的成本结构差异显著，且成本发生在不同阶段。GraphRAG 的成本主要在离线构建与增量更新：实体抽取需要调用大模型，社区检测与摘要需要重复计算，语料更新时需处理图的增量一致性。Vectorless RAG 的成本主要在文档解析与结构索引：扫描件 OCR、表格结构还原、条款层级识别，这些在脏语料上成本很高。Adaptive RAG 的成本主要在路由标注与持续监控：分类器需要标注数据，上线后需要监控漂移。

延迟方面，GraphRAG 的在线查询涉及子图检索与摘要，通常高于单次向量检索；Vectorless RAG 的两级检索在结构清晰时很快，但结构解析失败时会退化；Adaptive RAG 在检索延迟上叠加路由延迟，若路由用 LLM，延迟增幅更明显。工程上应把延迟预算作为硬约束，先定预算再选架构，而不是选完再优化。

9.2 各自的失效条件

GraphRAG 的失效条件：实体消歧质量差、语料高频变动导致图过期、多跳问题分散导致图谱复用率低、抽取成本超出预算。Vectorless RAG 的失效条件：用户表述与文档用词差异大、问题需要跨文档关系推理、文档结构本身混乱（无清晰层级）。Adaptive RAG 的失效条件：路由分类器在分布漂移后准确率下降、误判代价高的类别被系统性误判、延迟预算不足以支撑多通道。

本文评述：把失效条件写清楚，比把优势写清楚更有工程价值。因为优势决定“值不值得试”，失效条件决定“什么时候会翻车”。一个负责任的架构方案，应当同时给出监控指标：图谱的实体消歧准确率、结构解析的成功率、路由的混淆矩阵漂移。这些指标是架构的“体检项”。

9.3 组合而非替代

综合来看，三条路线不是互斥的替代关系，而是覆盖不同失败模式的组合件。一个成熟的企业知识库架构，通常是“混合检索为底座 + 按分布接入图谱/结构通道 + 路由层编排 + 兜底降级”。这个组合的复杂度应随问题分布的异质程度增长，而非一开始就全量上齐。

十、结论与展望：把架构决策变成持续校准的闭环

回到文章开头的问题：一个现在要建企业知识库的人，到底该先回答什么？本文的答案是——先回答“我的用户到底在问什么类型的问题”，并把它变成可测量的分布；再回答“我的失败模式分布是什么”；最后才回答“用哪个架构组合去覆盖这些失败模式”。这个顺序的价值不在于它更“正确”，而在于它让每一步决策都有可验证的依据，从而不被 Demo 的展示效果带偏。

具体到操作层面，本文给出的路径是：采集真实查询并软标签标注 → 建立混合检索基线 → 按失败模式归因 → 单点增强与消融 → 路由化与兜底 → 灰度与回流。这条路径的每一环都有明确的产出物与验收标准，可以嵌入项目管理。

展望未来，三个方向值得关注：（1）分布感知的自动化——用线上日志自动估计问题分布漂移，触发架构再校准；（2）评测集的自演化——把线上失败样本自动转化为评测样本，降低人工维护成本；（3）成本感知的路由——在质量与延迟/成本之间做显式优化，而非隐式权衡。这些方向的共同点是：把“架构选择”从一个一次性决策，变成一个持续校准的闭环。

最后需要强调边界：本文的方法论适用于需求异质、语料复杂、错误代价不对称的企业知识库场景。对于需求高度同质、语料规整的场景，简单混合检索可能已足够，过度设计反而增加维护负担。架构的复杂度应当由问题分布的异质程度来“授权”，而不是由技术热度来驱动。

主要参考文献