知识库选型实战：dsh-knowledge与三类RAG方案的代价结构对照

1. 选型对照的起点：先把"比什么"这件事说清楚

做知识库选型的人，十个里有八个会掉进同一个坑：拿一堆方案的功能清单横向拉表，比谁支持的格式多、谁的界面好看、谁的文档写得全，最后选出来的东西上线三个月就开始难受。原因很简单，功能清单是"能力上限"，而真正决定你能不能长期用下去的，是"能力边界"和"代价结构"。

我这次要对照的四个对象，分别是 dsh-knowledge，以及三类常见的 RAG 方案：纯向量检索型、图增强型（也就是常说的 KG 知识库 / ontology rag）、以及结构化知识库。这四者不是同一层的东西，硬拉一张表比"谁更强"是没有意义的。正确的比法是先确定你的知识形态和查询形态，再看哪种方案的代价结构你能接受。

先把四个对象的定位摆清楚，这是后面所有对照的基础：

这张表里最关键的一列是最后一列——"知识形态假设"。任何 RAG 方案的效果上限，本质上由你的知识是否符合它的形态假设决定，而不是由模型多强、向量维度多高决定。我见过太多团队在向量库上砸了几十万，最后发现自己的知识是强关系的设备台账，向量检索根本召回不准，这就是形态假设错配。

dsh-knowledge 的定位比较特殊，它不是一个纯粹的检索库，更像是一个"知识 + 技能"的调度层。从热词里能看到 DeepSeek Harness 这个体系，dsh-knowledge 是它生态里的知识组件，配合 skill（技能）机制使用。这意味着它的比较维度里多了一项：知识如何被消费。传统 RAG 是"检索出来喂给模型"，dsh-knowledge 是"检索出来交给技能执行"，这个差别在选型时经常被忽略，但影响很大。

所以这篇对照我不打算给你一个"选 X"的结论，而是给你一套判断路径：先看你的知识长什么样，再看你的查询长什么样，最后看你的运维能力撑得住哪种代价。下面按这个顺序展开。

2. 知识形态决定方案上限：四种知识长什么样

2.1 扁平文本型知识：向量 RAG 的主场

如果你的知识是大量非结构化文档——产品手册、客服话术、政策文件、技术博客——切片之后彼此独立，查询主要是"找相关内容"，那纯向量 RAG 就是最自然的选择。它的核心假设是：语义相近的文本片段，在向量空间里距离也近。

这个假设在什么情况下成立？文本片段本身信息自足、不依赖上下文关系的时候。比如"退货流程是什么"这种查询，召回的片段只要包含退货步骤就够了，不需要知道这个步骤属于哪个订单、哪个客户。

但它的边界也很清楚：一旦查询需要跨片段推理，向量检索就露怯了。比如"哪些客户的订单同时满足 A 条件和 B 条件"，这是集合运算，不是语义相似度能解决的。我实测过一个案例，问"上季度投诉过物流又复购的客户有哪些"，纯向量方案召回的全是"物流投诉处理流程"这类文档，因为它匹配的是"物流""投诉"这些词的语义，而不是真的在做集合筛选。

2.2 实体关系型知识：图增强 RAG 的战场

当你的知识里"谁和谁有关系"比"某段话说了什么"更重要时，图增强方案的价值就出来了。典型场景是设备运维、供应链、组织架构、医疗诊断这类领域——实体之间的连接本身就是知识。

图增强 RAG 的做法是先把文档里的实体和关系抽出来，建成图，查询时先在图上游走找到相关实体子图，再把子图对应的文本召回给模型。热词里提到的 ontology rag 就是这个思路的进阶版，用本体（ontology）来约束实体类型和关系类型，避免抽取出来的图乱七八糟。

它的代价在于构建成本。抽取实体关系这一步，要么靠规则（准但覆盖窄），要么靠模型（覆盖广但会抽错），要么人工标注（准但贵）。我做过一个中等规模的设备知识图谱，三千多份文档，光实体对齐和关系校验就花了将近两周，这还不算后续的维护。所以图增强方案适合"关系查询是刚需"的场景，如果只是偶尔需要，不值得为它付出这个构建成本。

2.3 字段约束型知识：结构化知识库的领域

结构化知识库听起来最"土"，但它在特定场景下是唯一正确答案。当你的知识天然就是表格——库存、价格、排班、工单状态——任何 RAG 方案都不如直接查库来得准和快。

这里有个常见误区：很多人觉得结构化知识库"不够 AI"。其实恰恰相反，在字段明确的查询上，精确查询的准确率是 100%，而任何语义检索方案都做不到。真正的问题不是"要不要用结构化"，而是"结构化能覆盖多少查询"。如果 80% 的查询都能用字段表达，那剩下 20% 才需要 RAG 兜底，这时候正确的架构是"结构化为主 + RAG 为辅"，而不是反过来。

2.4 混合形态：dsh-knowledge 想解决的问题

现实中的知识库很少是单一形态。一个企业知识库往往同时有：产品文档（扁平文本）、客户关系（实体关系）、订单数据（结构化字段）。传统做法是拼三套系统，查询时人工判断走哪条路，或者写一堆路由规则。

dsh-knowledge 这类方案的价值主张，就是把这几种形态统一到一个检索层里，再通过 skill 机制决定"检索出来的东西怎么用"。从热词里"deepseek harness 附带 skill 怎么部署到内网服务器"这类问题能看出来，它的使用场景偏向私有化、内网、需要和具体业务动作绑定的环境。

但要注意，统一检索层不等于统一存储。底层该用向量库还是图库还是关系库，还是得按知识形态选，dsh-knowledge 解决的是"上层怎么调度"，不是"底层存什么"。这个区分在选型时特别重要，很多人以为用了 dsh-knowledge 就不用管底层了，结果发现检索质量还是取决于底层建得好不好。

3. 查询形态决定方案下限：你的用户到底在问什么

3.1 把真实查询捞出来分类，比看方案文档有用十倍

选型最容易犯的错，是拿方案文档里的"示例查询"去对比。那些示例都是精心设计的，当然每个方案都能答好。正确做法是把你系统里真实的查询日志捞出来，随机抽 200 条，人工分类。

我一般按这四个维度分：

• 单跳 vs 多跳：一次检索能答，还是需要串几次
• 语义 vs 精确：靠意思匹配，还是靠字段筛选
• 关系 vs 内容：问的是"谁和谁"，还是"说了什么"
• 有答案 vs 无答案：知识库里到底有没有

分完之后你会发现，很多团队以为自己的查询很"AI"，其实 60% 以上是精确查询，用结构化就能解决。这个发现能直接帮你省掉一大笔向量库的钱。

3.2 多跳查询是分水岭

多跳查询是区分方案能力的关键。什么叫多跳？"张三负责的项目里，哪些用了 A 供应商的零件"——先找张三负责的项目，再找这些项目用的零件，再筛 A 供应商。这是三跳。

纯向量 RAG 处理多跳查询基本靠运气，因为它没有"跳"的概念，只能把整个查询编码成一个向量去匹配，匹配到的往往是包含所有关键词的某段文本，而不是真的做了三次筛选。图增强方案天然适合多跳，因为图遍历就是跳。结构化方案也能做多跳，就是写 SQL join。

dsh-knowledge 在这块的做法是通过 skill 编排来实现多跳——把一次复杂查询拆成多个检索步骤，每步的结果喂给下一步。这个思路和 agent 的 tool use 很像，好处是灵活，坏处是每一步都可能出错，误差会累积。所以如果你的查询多跳很深（超过三跳），要么用图，要么用结构化，靠 skill 编排串太多步，稳定性会下降。

3.3 无答案查询的处理，暴露方案的成熟度

还有一个容易被忽略的维度：当知识库里没有答案时，方案怎么表现。好的方案会明确说"没找到"，差的方案会硬凑一个看起来相关的答案。

纯向量 RAG 在这块最危险，因为向量检索永远会返回 top-k，哪怕这 k 个都不相关。图增强方案相对好一点，因为图遍历找不到路径就是找不到。结构化方案最诚实，查不到就是空结果。

dsh-knowledge 这类带 skill 的方案，理论上可以在 skill 里加"置信度判断"逻辑，低于阈值就不返回。但这需要你自己写，不是开箱即用的。选型时要问清楚：无答案场景的默认行为是什么，能不能配置。

4. 代价结构对照：构建、运行、维护三笔账

4.1 构建成本：一次性投入差多少

构建成本这块，四个方案的差距是数量级的。

纯向量 RAG 最便宜，文档切片、调 embedding 接口、灌库，一个下午能跑通 demo。但"跑通 demo"和"能用"之间差着十万八千里，后面调切片策略、调召回阈值、处理各种格式的文档，才是真正花时间的地方。

图增强 RAG 最贵，实体抽取、关系校验、本体设计，每一步都是硬功夫。而且这个成本不是一次性的，知识更新时图也要更新，增量维护比全量重建还麻烦。

结构化知识库的构建成本取决于你的数据本来有多规整。如果本来就是表格，导入就行；如果散落在文档里，那抽取字段的工作量和建图差不多。

dsh-knowledge 的构建成本介于中间，它本身不强制你建图，但如果你要用它的 skill 能力，得把知识组织成 skill 能消费的格式，这部分有学习成本。热词里"deepseek harness 无法安装""skill 读取文件报权限问题"这类问题，说明它的部署和配置本身就有门槛，尤其是在内网、离线环境下。

4.2 运行成本：每次查询花多少

运行成本主要是算力和延迟。

纯向量 RAG 每次查询就是一次向量检索加一次模型调用，延迟低，算力可控。图增强 RAG 每次查询要图遍历，如果图很大、跳数很多，延迟会明显上升。结构化查询最快，毫秒级。

dsh-knowledge 的运行成本取决于 skill 编排的复杂度。简单的单跳检索和纯 RAG 差不多，但如果 skill 里串了好几步，每步都要调模型，延迟和成本会成倍增长。这点在选型时要有预期：skill 编排的灵活性是用运行成本换来的。

4.3 维护成本：知识更新时谁更省心

维护成本是最容易被低估的一笔账。

向量库的维护相对简单，文档更新就重新切片灌库，旧向量删掉。但有个坑：如果切片策略变了，整个库要重建，因为向量和切片是一一对应的。

图库的维护最麻烦，新增一个实体可能要连带着更新一堆关系，还要处理实体消歧（同一个东西在不同文档里叫不同名字）。我见过一个图库项目，上线半年后因为实体命名不统一，图里同一个设备有三四个节点，查询结果开始出现重复和矛盾。

结构化库的维护最成熟，有现成的 ETL 工具和版本管理。dsh-knowledge 的维护成本取决于你用了多少 skill，skill 越多，知识格式变更时的影响面越大。

5. dsh-knowledge 的差异化：它到底解决的是哪一层问题

5.1 它不是检索库，是调度层

把 dsh-knowledge 和三类 RAG 方案并列比较，本身就有点错位。三类 RAG 方案解决的是"怎么存、怎么检"，dsh-knowledge 解决的是"检出来之后怎么用"。

从热词里能看出它的使用场景：内网部署、skill 机制、和 coding 开发结合、插件生态。这些关键词指向的是一个"知识驱动的自动化执行"场景，而不是单纯的问答。比如"deepseek harness 用于 coding 开发最应该装哪些插件"这个问题，背后是希望知识库能直接参与到开发流程里，而不只是回答"这个 API 怎么用"。

所以选型时，如果你的需求只是"问答"，dsh-knowledge 可能有点重；如果你的需求是"知识要驱动具体动作"，那它的 skill 机制就是核心价值。

5.2 skill 机制的双刃剑

skill 机制的好处是把"检索"和"执行"解耦了。检索层只管把相关知识找出来，skill 决定拿这些知识干什么——可以是回答，可以是生成代码，可以是触发一个流程。

坏处是它引入了新的复杂度。skill 本身要写、要测、要维护，而且 skill 之间的依赖关系会形成一张隐形的网。热词里"deepseek harness 代码回退"这个问题，很可能就是 skill 执行出错后需要回滚的场景。这类问题在纯 RAG 方案里不存在，因为纯 RAG 没有"执行"这一步。

我的建议是：如果你的团队没有能力维护 skill 这套东西，就别为了"看起来先进"上 dsh-knowledge，老老实实用纯 RAG 加一层业务逻辑，反而更稳。

5.3 许可与部署的现实约束

热词里出现了 AGPL-3.0，这是 dsh-knowledge 相关组件的许可协议。AGPL 的特点是：如果你把它作为网络服务提供给别人用，你必须开源你的修改。这对商业闭源产品是个硬约束。

选型时一定要把许可看清楚。如果你的场景是内部使用，AGPL 影响不大；如果是对外提供服务，要么接受开源，要么找替代方案。这个决策要在技术选型之前做，不要等系统建好了才发现许可有问题。

部署方面，热词里"deepseek harness 可以在离线局域网使用吗""怎么部署到内网服务器"这类问题很集中，说明它的目标场景就是私有化。私有化部署的好处是数据不出内网，坏处是升级、排错都靠自己。热词里"无法安装""权限问题"这些，都是私有化部署的典型痛点。

6. 一张决策路径图：按顺序问自己五个问题

与其给你一张对比表让你自己纠结，不如给你一条决策路径。按顺序问，问到哪个问题有明确答案，方案基本就定了。

第一个问题：你的知识里，关系查询占比多少？

如果超过 30% 的查询涉及"谁和谁有关系"，优先考虑图增强或结构化。如果低于 10%，纯向量 RAG 或 dsh-knowledge 就够。

第二个问题：你的查询里，精确筛选占比多少？

如果超过一半的查询能用字段表达，先建结构化库，RAG 作为补充。别一上来就上向量库。

第三个问题：你需要知识驱动动作，还是只需要问答？

只需要问答，纯 RAG 最省事。需要驱动动作（生成代码、触发流程、执行任务），才考虑 dsh-knowledge 这类带 skill 的方案。

第四个问题：你的团队能维护什么？

图库需要持续的实体治理能力，skill 需要持续的开发和测试能力，向量库需要调优能力。选你团队撑得住的，别选看起来最强的。

第五个问题：许可和部署约束是什么？

AGPL 能不能接受，内网部署有没有运维能力，离线环境怎么更新。这些是硬约束，不满足就直接排除。

这五个问题问完，方案基本就收敛到一两个了。剩下的就是小规模验证——拿真实查询跑一遍，看召回率和延迟能不能接受。

7. 实测中容易翻车的几个点

7.1 切片策略一变，向量库全废

这是纯向量 RAG 最经典的坑。切片大小、重叠长度、是否按语义切，这些参数一变，所有向量都要重算。我建议在选型阶段就把切片策略定下来，并且预留"重新灌库"的运维流程。如果知识更新频繁，这个成本要算进去。

7.2 图库的实体消歧是个无底洞

建图的时候觉得实体抽取挺准，用起来发现同一个东西有多个名字，查询结果开始打架。解决办法是在抽取阶段就做实体归一化，建一个别名词典。这个词典要持续维护，不是建完就完事。

7.3 skill 编排的误差累积

dsh-knowledge 的 skill 如果串了多步，每步的误差会累积。三步之后，最终结果的准确率可能只有单步的立方。所以 skill 编排要尽量扁平，能一步做完的别拆两步。如果必须多步，每步都要有校验和回退机制。

7.4 无答案场景的默认行为

前面提过，纯向量 RAG 永远返回 top-k，这在无答案场景下会误导用户。选型时要确认方案能不能配置"置信度阈值"，低于阈值返回空。dsh-knowledge 可以在 skill 里加这个逻辑，但要自己写。

7.5 许可和依赖的隐性成本

AGPL 这类许可，以及各种插件的依赖，在选型时容易被忽略。等系统建好了发现某个核心依赖的许可不允许商用，返工成本极高。建议在选型第一阶段就把所有依赖的许可列出来审一遍。

8. 我个人的选型体会

做了这么多知识库项目，我最大的体会是：没有最好的方案，只有代价结构你能接受的方案。纯向量 RAG 便宜但上限低，图增强强但贵，结构化准但覆盖窄，dsh-knowledge 灵活但复杂。选型的本质是在这四个维度上找平衡点。

如果非要给一个默认建议：先用结构化把能覆盖的查询覆盖掉，剩下的用纯向量 RAG 兜底，等关系查询真的成为瓶颈了再上图。dsh-knowledge 适合那些知识要驱动动作、且团队有 skill 开发能力的场景，不要为了"先进"而上。

最后分享一个实操技巧：选型验证阶段，别用方案自带的示例数据，用你自己最脏的那批真实数据。示例数据都是干净的，真实数据里的格式混乱、错别字、重复内容，才是真正考验方案的地方。我每次选型都会拿一批"最烂的文档"去测，能扛住这批的，才值得进入下一轮。