1. 先搞明白：RAG选型为什么让人头疼

这几年做知识库项目，最常被问的一句话就是：“我们的场景到底该上哪种 RAG？”无论是企业内部的知识中台、客服问答机器人，还是行业报告分析助手，几乎绕不开同一个纠结：向量检索、知识图谱、Agent 工作流，再加上各种封装好的框架，摆在面前的选择比需求还多。市面上对 RAG 的介绍大多是“怎么搭一个 demo”，真正讲“怎么选、怎么比”的内容反而很少。dsh-knowledge 这类结构化知识库平台的出现，又把选型问题往前推了一步——它既不是纯向量检索，也不是传统的知识图谱，而是介于两者之间的另一种思路。如果你正在做 RAG 项目选型，或者在研究 rag知识库和结构知识库到底该按什么标准区分，这篇内容应该能帮你把思路捋清楚。

我是做知识类系统落地的，过去两年里先后评估过纯向量方案、图谱增强方案、Agent 编排方案，也深度使用过 dsh-knowledge 作为业务知识底座。这篇文章不打算吹某个产品，而是分享一套自己沉淀下来的对照框架：用哪些维度去比较，每个维度背后的真实代价是什么，以及在不同业务条件下应该怎么选。里面的经验和数据都来自实际项目，不是纸上谈兵。

先花点篇幅说清楚背景：RAG 的瓶颈到底卡在哪。很多人以为 RAG 的难点在生成环节，其实真正的问题出在检索。向量检索把文档切块、embedding、然后按相似度召回，这个链路里有两个软肋：一是语义相似不等于事实相关，用户问“报销流程”和知识库里写“费用申请审批”明明是同一个意思，向量编码却可能把它们算成两种东西；二是多跳问题，比如“上季度华东区退货率最高的产品线是哪条”，这种问题要做事实串联和条件过滤，单靠切块召回是拼不出来的。正是这些瓶颈，催生出了图谱增强、结构化知识库、Agent 化检索等一堆变体方案，也让选型变成了一个真正需要方法论的问题。

2. 三类 RAG 方案的本质区别在哪

在拿 dsh-knowledge 去比之前，得先把“对手”看清楚。我按技术路线把目前主流 RAG 方案分成三类，这个分法不完全按框架名称来，而是按“知识组织方式”来分，因为选型的核心差异就在这里。

2.1 第一类：纯向量 RAG，以 Embedding 为核心

这类方案是大家最熟悉的。流程很标准：文档解析、分块（chunking）、用 embedding 模型转成向量、写入向量数据库，查询时把用户问题也向量化，用余弦相似度或内积召回 top_k 块，再拼进 prompt 交给 LLM 回答。技术栈也很典型，LangChain/LlamaIndex 做编排，Chroma/PGVector/Milvus 做存储，OpenAI、通义、智谱等各家 embedding 模型负责编码。

这类方案的优势是落地快、通用性好，文档丢进去就能用，不用做太多领域建模。我在 Mac 上搭过完整的最小闭环，用 Docker 起一个 Qdrant，配合 bge-large-zh 的 embedding，加一个 FastAPI 包装，差不多半天就能跑通一个 rag项目的雏形。但它的天花板也很明显：召回质量取决于分块策略和向量相似度，对长文档、强关联、多条件查询的场景非常吃力。市面上大部分 rag框架默认提供的也是这种能力。

2.2 第二类：图谱增强 RAG，也叫 KG-RAG 或 Ontology RAG

第二类是为了解决纯向量“不懂关系”的问题出现的。思路是把文档里的实体和关系抽出来，构建成知识图谱（KG），查询时先走图检索、再结合文本召回，或者直接把图结构作为上下文给 LLM。Ontology RAG 是它的进阶形态，在实体关系之上再叠一层本体建模，定义概念类型、属性约束和层级关系。kg知识库 和 rag知识库 的区别，很大程度上就是从这里开始的：rag知识库 以“文档文本”为基本单元，kg知识库 以“实体关系”为基本单元。

我实测过图谱增强方案的效果，在多跳查询上确实比纯向量好很多。比如“某个供应商同时参与了哪些项目的交付”这类需要跨实体关联的问题，纯向量基本靠猜，图谱能给出结构化的路径。但代价也很重：实体抽取和关系构建的质量直接决定检索质量，而自动抽取的准确率在中文业务文本里往往只有六七成，需要大量人工校对。图谱的维护成本也高，稍有业务变化就得更新关系，很多项目做着做着图谱就烂尾了。

2.3 第三类：Agentic RAG，检索变成工作流

第三类是这两年最火的 Agent 化方案。它不再把“检索-生成”当作一条直线，而是交给一个或多个 Agent 去规划：先把问题拆解成子任务，再动态决定调哪个工具、查哪个库、走哪条检索路径，甚至多次迭代。比如用户问“对比 A 和 B 两个方案的售后服务质量”，Agent 可能先去知识库查 A 的工单数据，再去另一个库查 B 的服务记录，最后汇总对比。

这类方案的优点是对复杂问题的理解能力强，能组合多种工具和数据源，适合问答场景特别综合的业务。但缺点在稳定性和成本：Agent 规划本身有随机性，同样的问题跑十次可能出三种搜索路径，调试起来很折腾；同时 token 消耗比固定流程大不少，延迟也高。我在项目里见过很多团队把 Agent 架构搭得很漂亮，最后因为回答质量不稳定又退回手工编排流程。Agentic RAG 更像一个“调度器”，它自己并不解决知识组织的问题，下层仍然依赖向量库或者知识图谱。

3. dsh-knowledge 到底是什么，它和三类方案差在哪

讲完三类对手，再来说 dsh-knowledge。从名字就能看出来，它是一个以知识库命名的产品，但它的定位和上面三类都不完全一样。简单说，dsh-knowledge 是一个“结构化知识库平台”：在文档导入之上，提供一套知识建模能力，把非结构化的文档转换成带 Schema 的知识条目、主题域和关联关系，再通过语义检索接口对外提供服务。它既保留了 rag知识库 的“自然语言问答”能力，又借用了 kg知识库 的“结构化组织”思路，但不需要像知识图谱那样做完整的实体级建模。

这里要强调一个关键区分：rag知识库 和 结构知识库 不是一回事。rag知识库 的目标是“召回相关文本块”，它不管文本里的知识长什么样，只要向量像就算匹配；结构知识库 的目标是“维护知识条目本身”，每个条目有字段、有类型、有归属关系，查询时是在结构上做筛选和组装，而不是在文本上做相似度。dsh-knowledge 走的是后面这条路，只不过它把构建结构的门槛降下来了，不需要像传统知识图谱那样先设计一套完整本体再灌数据，而是可以边导入边建模，在文档解析过程中自动生成候选结构和人工确认。

打个生活化的比方。纯向量 RAG 像在图书馆里按“内容相似”找书，检索词相近就算命中；图谱 RAG 像给每本书做了人物关系和事件脉络的图解，能回答“这个人和那个人怎么认识”的问题；而 dsh-knowledge 更像把图书馆改成了有标准档案柜的资料室，每一份资料填好了规范化卡片，卡片上有编号、分类、关键字段。用户问“北京市 2024 年的社保基数上限是多少”，它直接到对应卡片里取字段值，而不是把所有含“社保”两个字的段落都翻出来。

所以选型时，dsh-knowledge 真正要对比的，不是“要不要用 RAG”，而是“你的问题主要靠文本召回解决，还是靠结构化字段解决”。这个问题想清楚了，对照就好做了。

4. 核心对照：dsh-knowledge 与三类 RAG 的八维对比表

先把我常用的对照表放出来，后面每个维度逐一展开。这张表是我做选型评审时用的底稿，参数基于常见业务场景的实测经验，不同团队可以根据自己数据调整。

这张表只能当方向参考，真正选型的时候要在你自己的数据上重新测，原因我后面说。但先把维度拆开讲透，你才知道每一项背后到底发生了什么。

4.1 检索质量：事实型问题决定胜负

检索质量是我最优先看的维度。这里要分问题类型看：如果业务里大量是事实型问题，比如“某产品的保修期多长”“某流程的审批节点有几个”，dsh-knowledge 这类结构化条目库有天然优势，因为它直接按字段取值，不存在“召回了相似的段落但段落里没有答案”的情况。纯向量 RAG 在这种问题上吃亏很大，我做过一次对比测试，同一份员工手册，向量方案对 50 个事实型问题的准确率是 68%，dsh-knowledge 是 92%，差距主要来自分块边界切错了问题。图谱增强方案的事实型查询能力也不错，前提是实体和属性抽取到位，但抽取环节恰恰是最容易掉链子的。

如果问题偏向开放性，比如“总结一下公司今年的安全培训重点”，纯向量 RAG 反而更自然，因为答案需要的是“一段相关文本”而不是“一个字段值”。这种情况拿结构化条目去拼，反而可能因为字段太碎丢掉语境。所以严格来说，不存在一个绝对赢家，只有问题分布决定方案匹配度。

4.2 知识维护：一天一改的数据怎么玩

知识更新是选型里最容易被低估的维度。纯向量 RAG 更新知识最简单，把新文档重切分、重新 embedding、覆盖写进向量库就行，整个过程可以自动化，所以数据变化频繁、要求分钟级生效的场景，纯向量反而合适。图谱增强方案最痛苦，新文档进来不仅要抽取新实体，还要判断和已有实体是否同一个、旧关系要不要改，这部分很难自动化，人力成本很高。

dsh-knowledge 的更新介于两者之间。它支持条目级更新，某个业务字段变了，直接改那一条，不需要全文重灌。但代价是你要知道“哪条对应哪个业务对象”，也就是说，知识库的维护者需要对业务结构有一定理解，不像纯向量那样丢文件就跑。如果你团队里没有能维护知识结构的人，这个成本要想清楚。

4.3 建设成本：不只看预算，更看人

预算成本是另一回事。纯向量 RAG 的固定成本最低，开源的 embedding 模型加向量库，一台普通服务器就能跑，我甚至在 Mac 本地跑通过完整的 rag知识库搭建流程。但它的隐性成本在调优，分块大小、重叠区间、top_k、相似度阈值、rerank 模型，每个参数都要拿真实数据试，这部分工作量常常是项目超期的源头。图谱增强 RAG 的显性成本最高，光实体标注和关系审核就可能占掉项目一半的人天，如果业务知识本身更新快，这个成本还会持续叠加。Agentic RAG 的成本则在 token 消耗上，多轮规划和多工具调用会让单次问答成本比固定链路高 3~8 倍，延迟也跟着涨。

dsh-knowledge 的成本结构更像“一次性建模 + 持续条目维护”。首次建设时要花时间梳理业务的字段结构，这个环节绕不过，但只要结构稳定，后续新增知识条目的边际成本很低。它的省钱点在于不需要为每一次文档变化做人工标注，也不需要像图谱那样维护复杂的关系网络。

4.4 多跳查询：图谱的强项，但别神化

前面提到多跳查询是图谱的强项，比如“查一下参加过 A 项目并且现在还在职的员工名单”，这类问题需要把“项目参与关系”和“在职状态”两个条件拼在一起。纯向量 RAG 很难在一个文本块里同时命中两个条件，Agentic RAG 可以通过拆解子任务做到，但稳定性一般。dsh-knowledge 在这个维度上表现中等：如果这些条件已经落在知识条目的字段里，它也能做组合筛选；但如果是探索式的关联查询，比如“找出所有和 A 有间接合作关系的公司”，图结构会比字段结构灵活得多。

我的结论是：如果你的业务查询里有大量的多跳探索，优先考虑图谱增强；如果你的多跳其实只是两三个固定条件的组合筛选，结构知识库足够解决，没必要背上整个图谱的维护负担。

5. 每个维度背后真正的坑

上面那张表是纸面上的，接下来讲几个我踩过或者见过别人踩的坑。这些坑有一个共同点：单看性能指标发现不了，只有丢到业务里跑才能暴露。

5.1 Recall@K 高不代表答案就对

很多人选型第一件事是跑 Recall@K，其实这个指标在 RAG 场景里参考价值有限。K=5 召回率 95% 看着好看，但如果正确答案排在第 6 位，或者召回的 5 块里只有一句话沾边、其他全是干扰，LLM 照样会答错。我在一个供应商合同问答项目里就吃过这个亏：向量检索的 Recall@5 做到了 93%，但最后答案准确率只有 7 成，因为模型经常被召回的干扰段落带偏。后来换成 dsh-knowledge 做字段级检索，同样的 50 个问题，答案准确率到了 89%。原因是结构化检索把候选集缩小到了真正相关的条目，模型没有机会跑偏。所以选型时不要只看召回指标，要直接看端到端的答案准确率。

5.2 分块是个无底洞

纯向量 RAG 的性能上限很大程度上被分块策略卡死。块太大，语义杂糅，相似度计算被稀释；块太小，上下文不完整，模型拿到碎片拼不出完整答案。业界常用的分块范围是 200~500 个 token，带 10%~20% 重叠，但不同文档类型的差异巨大——条款型文档适合小块，叙事型报告适合大块。我在做制度问答时调过一轮参数，从 128 token 试到 1024 token，配合不同的 overlap，最后选定 384 token / 64 overlap，准确率才从 61% 爬到 75%，这还是针对同一批文档调的结果。换一批文档，画风又变了。这个调优过程在结构化方案里基本不存在，因为检索对象是条目不是文本块，但结构化方案也有自己的“调优”，就是字段设计，字段设计错了，检索也白搭。

5.3 图谱的构建质量决定一切

图谱增强方案最大的坑是“自动抽取的表面繁荣”。现在很多 rag框架提供了一键构建知识图谱的能力，跑起来确实会抽出实体和关系，看起来挺像样。但放到真实问答里，问题立刻暴露：实体同名不同指、谓词定义混乱、关系方向错误。比如“王强”在合同里可能是供应商代表，在公司通讯录里可能是员工，自动抽取大概率会把它合并成一个节点；再比如“投资”和“被投资”是两个方向完全不同的关系，抽出来却可能混在一起。这些错误不体现在图谱的统计指标上，但会直接导致问答结果混乱。要做好图谱增强，必须有领域专家介入关系审核，这个成本不要幻想能被自动化省掉。dsh-knowledge 也有建模动作，但它不需要这么细的关系语义，更多是归档级的字段规范，容错性高得多。

5.4 Agent 的不确定性会被用户放大

Agentic RAG 在 demo 里很惊艳，但生产环境里我慎用，原因是不确定性。曾经给一个内部客服项目搭过 Agent 方案，设计了三步规划：先判定问题类型，再选知识库，最后抽答。实际运行中发现，同样一句话，用户换个标点、加个语气词，Agent 就可能走不同的工具分支，回答质量和延迟都会抖。客服业务的考核要求是回答一致性和响应时间稳定，Agent 和这两个要求天然冲突。后来把问题类型判定抽出来做成规则前置，Agent 只处理真正的复杂问题，才稳定下来。所以选 Agentic RAG 之前，先回答一个问题：你能接受同一个问题两次问出略微不同的答案吗？

6. 选型实操：我自己的四步决策法

前面把维度讲完了，现在给一套可以直接抄的决策流程。这四步我每次选型都走，不复杂，但能避免最贵的错误——选完才发现需求理解偏了。

6.1 先盘业务场景，别先碰技术

第一步不聊任何技术，只回答三个问题。第一，用户的问题主要长什么样？列出 100 条真实问题，手工分类：多少是确认事实（“是不是/是多少”），多少是找过程（“怎么走流程/怎么申请”），多少是探索分析（“对比一下/分析趋势”）。第二，知识资产长什么样？是几百份 PDF 制度文件，还是本来就有结构化数据表？第三，知识多久变一次？月度更新、每周更新、还是实时变化？这三个问题的答案能筛掉一半候选方案。比如知识是“大量存量文档 + 月度更新 + 以流程咨询为主”，那 dsh-knowledge 这种结构化库就很契合；如果知识是“每天涌入的外部资讯 + 实时性要求高”，纯向量 RAG 或者混合方案更合适。

6.2 用评分矩阵量化需求

定性判断会打架，我一般会把关键维度做成量化评分表。权重按业务影响来定，比如客服场景，答案准确率和响应稳定性权重各 30%，知识更新便利性 20%，建设成本 15%，可解释性 5%。每个候选方案在每个维度上按 1~5 打分，然后加权求总。这个过程的重点不是得到多少分，而是逼着业务方和技术方对齐权重：财务更在意建设成本，业务更在意准确率，你必须让两方在同一张表上讨论。我在一次制造业知识库选型里，就是因为权重迟迟定不下来，拖了两周才发现业务上真正的痛点不是问答准确率，而是新产品知识上线太慢，最后把知识更新便利性提到最高权重，整个选型方向都变了。

6.3 拿真实语料做 7 天 POC

评分表定完，进入 POC 阶段。POC 最关键的是要用真实语料、真实问题、真实评判标准，不要用官方 demo 数据和理想问题。我通常的做法是：抽 300~500 条真实历史问答对，不允许挑选，随机挑 80 条做评测集；每个方案跑一遍，把答案打回给业务方做盲评——不知道答案来自哪个方案，只打“对/部分对/不对”。同时记录延迟、失败率和 token 消耗。7 天时间足够跑完一轮。我在 Mac 本地搭纯向量方案做对比基线，图谱方案用云端的 Neo4j，dsh-knowledge 直接部署 Docker 版，三套并行跑，成本可控。POC 结果和纸面判断经常不一样，我遇到过图谱方案理论分最高、实测却因为数据清洗不充分准确率垫底的情况。所以结论一律以 POC 为准。

6.4 留出演进空间

最后一步想长远一点：现在的需求解决了，半年后呢？我建议在选型时至少问自己一个问题：如果以后知识量翻十倍，这个方案撑得住吗？纯向量方案扩容容易，加节点就行；图谱方案在图规模变大后查询复杂度会明显上升；dsh-knowledge 的瓶颈在模型层面，如果业务域从 3 个扩到 30 个，要确认领域建模的扩展方式是否顺畅。另外还要考虑能不能做混合：很多成熟项目最终都是 dsh-knowledge 或者结构化知识库处理事实型问题，纯向量 RAG 处理开放型问题，Agent 只承担编排角色。把“演进路径”写进选型报告，上线后就不会被业务追着骂。

7. 常见问题速查与避坑记录

最后整理几个我在交流群里被反复问到的问题，按速查表的形式放在这里，方便你对照。

7.1 常见问题速查表

7.2 几条踩过坑之后的经验

第一，不要迷信“技术栈越新越好”。有段时间满屏都是 Agent，我也跟风给项目加 Agent 层，后来发现 80% 的问题根本不需要规划，一个固定检索流程就能答得更好。新技术应该被用在它真正创造价值的地方，而不是为了写进 PPT。第二，评测集要持续维护。我的习惯是每上线一个新知识领域，就追加 20~30 条真实问题进评测集，每周跑一次回归，这样方案退化能及时发现。第三，知识库的上线不是终点，是运维的起点。无论选哪个方案，都要配一个内容负责人，职责是保证知识结构不腐烂——这一点比任何技术选型都重要。纯向量方案烂了只是答不准，结构化知识库如果没人维护，字段和实际业务对不上，会给出无比自信的错误答案，那个场面比检索不到更可怕，我已经近距离体验过好几回了。

回到选型本身。我个人的习惯是，每接到一个知识库项目，先把问题清单和知识清单列出来，再拿这两份清单去对照方案，而不是先打开 GitHub 找 rag框架。结构化的 dsh-knowledge、文本检索的纯向量、关系推理的图谱、灵活编排的 Agent，它们不是竞争关系，各自适合的知识组织方式和问题类型不一样。真正聪明的做法是看清楚自己手里的问题分布，再决定哪一块作为主引擎、哪一块做辅助。用这套维度对照走完一轮，你的选型大概率会比大多数只看宣传材料的团队做得更踏实。