RAG选型核心对照：向量检索、知识图谱与dsh-knowledge对比

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 的八维对比表先把我常用的对照表放出来后面每个维度逐一展开。这张表是我做选型评审时用的底稿参数基于常见业务场景的实测经验不同团队可以根据自己数据调整。维度纯向量 RAG图谱增强 RAGAgentic RAGdsh-knowledge知识组织方式文本分块向量化实体/关系图多工具多库编排结构化知识条目建设周期1~2 周可上线1~3 个月起步2~6 周2~4 周检索准确率事实型中低依赖分块中依赖抽取质量中高但波动大高字段级精准多跳/关联查询弱强强中可解释性弱看召回的文本块中能看到关系路径弱链路不确定强能看到命中的条目字段知识更新成本低重灌即可高需更新关系中视底层而定中低条目级更新运行延迟低200~500ms中1~3s高3~10s低300~800ms团队门槛低会调接口即可高需 NLP/本体设计中高需流程设计中需理解业务字段这张表只能当方向参考真正选型的时候要在你自己的数据上重新测原因我后面说。但先把维度拆开讲透你才知道每一项背后到底发生了什么。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 RecallK 高不代表答案就对很多人选型第一件事是跑 RecallK其实这个指标在 RAG 场景里参考价值有限。K5 召回率 95% 看着好看但如果正确答案排在第 6 位或者召回的 5 块里只有一句话沾边、其他全是干扰LLM 照样会答错。我在一个供应商合同问答项目里就吃过这个亏向量检索的 Recall5 做到了 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 本地搭纯向量方案做对比基线图谱方案用云端的 Neo4jdsh-knowledge 直接部署 Docker 版三套并行跑成本可控。POC 结果和纸面判断经常不一样我遇到过图谱方案理论分最高、实测却因为数据清洗不充分准确率垫底的情况。所以结论一律以 POC 为准。6.4 留出演进空间最后一步想长远一点现在的需求解决了半年后呢我建议在选型时至少问自己一个问题如果以后知识量翻十倍这个方案撑得住吗纯向量方案扩容容易加节点就行图谱方案在图规模变大后查询复杂度会明显上升dsh-knowledge 的瓶颈在模型层面如果业务域从 3 个扩到 30 个要确认领域建模的扩展方式是否顺畅。另外还要考虑能不能做混合很多成熟项目最终都是 dsh-knowledge 或者结构化知识库处理事实型问题纯向量 RAG 处理开放型问题Agent 只承担编排角色。把“演进路径”写进选型报告上线后就不会被业务追着骂。7. 常见问题速查与避坑记录最后整理几个我在交流群里被反复问到的问题按速查表的形式放在这里方便你对照。7.1 常见问题速查表问题建议只有 PDF 制度文档没有其他数据源适合用什么先试纯向量 RAG 快速验证如果事实型问答准确率低于 80%考虑抽字段到 dsh-knowledge知识每天更新用图谱方案靠谱吗不推荐图谱关系维护跟不上更新节奏优先纯向量 定时重建索引团队没有人懂知识建模能用结构化知识库吗能但要有心理准备首次建模阶段需要一个懂业务的人配合梳理字段这个人不能缺查询里有很多“对比 XX 和 YY”的问题优先 Agentic RAG 或者混合编排纯向量很难同时精确召回两个对象的结构化信息想在 Mac 上先搭个 rag知识库做验证推荐 Docker 起向量库配合本地 embedding 模型跑通后再考虑迁服务器或换方案dsh-knowledge 可不可以和向量检索一起用可以这也是我最推荐的架构结构化条目管事实向量管开放问答外面套一层路由7.2 几条踩过坑之后的经验第一不要迷信“技术栈越新越好”。有段时间满屏都是 Agent我也跟风给项目加 Agent 层后来发现 80% 的问题根本不需要规划一个固定检索流程就能答得更好。新技术应该被用在它真正创造价值的地方而不是为了写进 PPT。第二评测集要持续维护。我的习惯是每上线一个新知识领域就追加 20~30 条真实问题进评测集每周跑一次回归这样方案退化能及时发现。第三知识库的上线不是终点是运维的起点。无论选哪个方案都要配一个内容负责人职责是保证知识结构不腐烂——这一点比任何技术选型都重要。纯向量方案烂了只是答不准结构化知识库如果没人维护字段和实际业务对不上会给出无比自信的错误答案那个场面比检索不到更可怕我已经近距离体验过好几回了。回到选型本身。我个人的习惯是每接到一个知识库项目先把问题清单和知识清单列出来再拿这两份清单去对照方案而不是先打开 GitHub 找 rag框架。结构化的 dsh-knowledge、文本检索的纯向量、关系推理的图谱、灵活编排的 Agent它们不是竞争关系各自适合的知识组织方式和问题类型不一样。真正聪明的做法是看清楚自己手里的问题分布再决定哪一块作为主引擎、哪一块做辅助。用这套维度对照走完一轮你的选型大概率会比大多数只看宣传材料的团队做得更踏实。