知识库选型实战：dsh-knowledge与三类RAG方案横向对比

1. 选型这件事，为什么越比越糊涂

做知识库项目的人大概都有过这种体验：一开始只是想给团队搭一个能问答的内部知识助手，结果调研着调研着，面前摆了一堆名词——向量数据库、图数据库、RAG、KG、Ontology、结构知识库，还有像 dsh-knowledge 这种把整套东西打包好的方案。每个看起来都能解决问题，每个的官网和文档都写得头头是道，但真到了要拍板选型的那一刻，反而不知道该拿什么维度去比。

我自己在这个坑里来回折腾过好几轮。最早做的是一个纯文档问答的场景，几百份 PDF 加一堆 Markdown，用最朴素的向量检索加 LLM 拼答案，跑起来效果还行。后来业务方提了新需求：要能回答"某个零件的供应商是谁，这个供应商还供了哪些其他零件，这些零件里哪些出过质量问题"——这种多跳关系问题，纯向量检索直接歇菜，检索出来的片段全是零散的，LLM 拼不出完整链路。这时候才意识到，选型不是选"哪个方案更强"，而是选"哪个方案匹配你当前的问题形态"。

这篇东西就是把我踩过的这些坑整理成一套可对照的维度框架。核心是拿dsh-knowledge这个相对完整的方案，去和三类主流 RAG 方案做横向对照：纯向量 RAG、图增强 RAG（KG-RAG）、结构化知识库 RAG。我会把每个维度的判断标准、背后的原理、以及实际选型时容易忽略的细节都摊开讲。适合正在做知识库选型的技术负责人、独立开发者，也适合已经搭了一套 RAG 但发现效果卡在瓶颈、想搞清楚该往哪个方向演进的人。

先说清楚一个前提：没有银弹。dsh-knowledge 不是万能的，向量 RAG 也不是过时的东西。选型的本质是在"问题复杂度""数据形态""团队维护能力""合规要求"这几个约束下找最优解。下面我按维度一个个拆。

2. 先把四个选手摆上台面：各自到底是什么

在比维度之前，得先把四个方案的核心定位说清楚，不然后面对照的时候容易鸡同鸭讲。这里我尽量用大白话，不堆术语。

2.1 dsh-knowledge：打包好的知识库方案

dsh-knowledge 是围绕 DeepSeek Harness 生态构建的一套知识库方案。它的定位不是"一个检索库"，而是"从数据接入、切分、索引、检索到答案生成的一整条链路"。你可以理解成一个已经帮你把 RAG 流水线搭好的框架，你只需要把数据喂进去、配置好检索策略，它就能跑起来。

它比较有特点的地方在于：同时支持向量检索和结构化/图谱检索的混合模式，并且和 DeepSeek Harness 的插件体系打通。这意味着你在做 coding 开发或者写综述类任务时，可以直接把知识库作为 skill 挂载进去，让模型在生成过程中主动调用知识库。另外它的开源协议是AGPL-3.0，这一点在选型时是个硬约束，后面会专门讲。

注意：AGPL-3.0 是强传染性协议，如果你的项目要对外提供服务（哪怕是 SaaS 形式），修改后的代码也需要开源。商业闭源产品选型时这条必须先过法务。

2.2 纯向量 RAG：最主流也最容易被低估

纯向量 RAG 的链路很清晰：文档切分成 chunk → 用 embedding 模型编码成向量 → 存进向量数据库 → 查询时把问题也编码成向量 → 做相似度检索 → 把 top-k 片段塞给 LLM 生成答案。

它的优势是上手快、生态成熟、对非结构化文本友好。你有一堆杂乱的文档、聊天记录、网页，向量 RAG 能很快跑出一个"看起来能用"的效果。但它的短板也很明显：它只懂"语义相似"，不懂"关系"和"结构"。你问"张三的直属领导是谁"，如果文档里恰好有一句"张三向李四汇报"，它能检索到；但如果这个信息散落在三份文档里，需要跨文档推理，它就无能为力了。

2.3 图增强 RAG（KG-RAG）：为关系而生

KG-RAG 在向量检索的基础上，引入了一个知识图谱层。数据入库时，除了做向量化，还会做实体识别和关系抽取，把"张三—汇报—李四""李四—负责—项目A"这类三元组抽出来存进图数据库。查询时，先定位到相关实体，然后沿着图的边做多跳遍历，把关联的子图捞出来，再交给 LLM 生成答案。

它解决的核心问题是多跳推理和关系查询。代价是：数据预处理成本高（要做实体抽取、关系抽取、消歧），图 schema 需要设计，维护复杂度上一个台阶。而且实体抽取的质量直接决定整个系统的上限，抽错了后面全错。

2.4 结构化知识库 RAG：把数据当数据看

结构化知识库 RAG 走的是另一条路：它假设你的核心知识本来就存在结构化数据里——数据库表、Excel、CSV、API 返回的 JSON。它不强行把结构化数据"文本化"再向量化，而是保留结构，用 Text-to-SQL 或 Text-to-API 的方式让 LLM 直接查询。

比如你问"上个月华东区销售额最高的三个产品"，它不会去检索文档片段，而是生成一条 SQL 打到数据库上，拿回结果再组织成自然语言。这种方式在数值精确、聚合统计、条件筛选类问题上碾压向量 RAG，但对非结构化文本无能为力，而且 Text-to-SQL 的准确率高度依赖 schema 设计和模型能力。

把这四个摆在一起，你会发现它们其实覆盖了不同的"问题形态"。下面进入正题，逐个维度对照。

3. 维度一：数据形态适配——你的数据长什么样，决定了你能选谁

选型第一步永远是看数据。我见过太多人上来就纠结"用哪个框架"，结果数据形态根本没搞清楚，选完发现一半数据喂不进去。

3.1 非结构化文本：向量 RAG 的主场

如果你的数据是 PDF、Word、Markdown、网页、聊天记录这类非结构化文本，纯向量 RAG 是最自然的起点。切分策略、embedding 模型、检索参数这些都有大量成熟实践可以抄。

dsh-knowledge 在这类数据上同样能打，而且它的切分和索引链路是打包好的，省去了自己拼 LangChain 或者 LlamaIndex 的功夫。但要注意：打包方案意味着可调参数可能不如自己拼的灵活。如果你的切分逻辑有特殊需求（比如按代码块边界切、按表格结构切），得先确认 dsh-knowledge 是否暴露了对应的配置项。

KG-RAG 处理非结构化文本时，多了一道实体抽取的工序。这一步是双刃剑：抽得好，关系查询能力直接拉满；抽得差，噪音比纯向量还多。我的经验是，领域术语密集、实体边界清晰的文本（比如法律条文、医疗记录、设备手册）适合上 KG；口语化、实体模糊的文本（比如客服对话、社交媒体）上 KG 性价比很低。

3.2 结构化数据：别硬塞进向量库

这是最容易踩的坑。很多人手里明明是一张张数据库表，非要把它转成自然语言描述再向量化，然后抱怨"为什么问数值问题总是答不准"。结构化数据就该用结构化方式查。

结构化知识库 RAG 在这里是正解。Text-to-SQL 的准确率，在 schema 设计清晰、字段命名规范的前提下，用现在的模型能到相当可用的水平。dsh-knowledge 如果支持结构化数据源接入，那它在混合场景下就有优势——同一套系统里，文本走向量、表格走 SQL。

3.3 混合数据：现实里最常见的情况

真实项目里，数据几乎从来不是单一形态。一个企业内部知识库，可能同时有产品文档（非结构化）、客户表（结构化）、工单记录（半结构化）。这时候选型要考虑的是方案能不能统一管理多种数据源，而不是为每种数据单独搭一套。

dsh-knowledge 这类打包方案的价值就在这里体现：如果它原生支持多数据源接入和统一检索路由，那你省下的是大量胶水代码。但代价是你对每一层的控制力下降，出问题时排查链路更长。我个人的取舍是：早期验证阶段用打包方案快速跑通，规模化阶段再考虑拆开自建。

4. 维度二：查询能力——你的用户到底会问什么

数据形态决定了"能喂什么"，查询能力决定了"能答什么"。这两个维度经常被混为一谈，其实要分开看。

4.1 单跳事实查询：大家都行

"公司的年假政策是什么""某个 API 的参数怎么传"——这类问题只需要检索到一个相关片段就能回答。四个方案都能处理，差别只在检索质量和响应速度。纯向量 RAG 在这里性价比最高，没必要上图谱。

4.2 多跳关系查询：向量 RAG 的瓶颈所在

"张三负责的项目里，哪些用到了李四团队维护的组件"——这种问题需要跨多个实体、多条关系推理。纯向量 RAG 的失败模式很典型：它可能检索到"张三负责项目A"和"项目A用到组件X"和"组件X由李四团队维护"三个片段，但它不知道这三个片段是连在一起的，LLM 拿到零散片段后要么漏答，要么编造。

这就是热词里说的rag瓶颈。KG-RAG 正是为突破这个瓶颈设计的。它把关系显式建模成图的边，查询时沿边遍历，天然支持多跳。dsh-knowledge 如果内置了图谱层，那它在多跳场景下就有结构性优势。

实操心得：判断你的场景是否需要 KG，有个简单测试——随机抽 50 个真实用户问题，统计其中需要跨 2 个以上文档才能回答的比例。低于 20%，向量 RAG 够用；高于 40%，认真考虑 KG。

4.3 聚合统计查询：结构化 RAG 的专属领域

"上季度各部门的预算执行率排名""过去三个月故障率最高的设备型号"——这类问题本质是数据库聚合查询。向量 RAG 在这里几乎必然翻车，因为它检索的是"语义相似片段"，而聚合需要的是"全量精确计算"。结构化 RAG 通过 Text-to-SQL 直接打到数据库，结果精确。

4.4 查询能力对照表

这张表的核心信息是：没有哪个方案在所有查询类型上都强。选型时要先摸清你的查询分布，再决定主攻方向。如果查询类型高度混合，那 dsh-knowledge 这种支持混合检索的方案，或者自己搭一套路由层，才是现实解。

5. 维度三：部署与运维成本——选型时最容易被低估的部分

技术选型讨论时大家最爱聊能力，最不爱聊成本。但实际项目里，运维成本往往是压垮方案的最后一根稻草。

5.1 纯向量 RAG：运维最轻

一个向量数据库（Milvus、Qdrant、pgvector 都行）加一个 embedding 服务，基本就齐活了。数据更新就是重新 embedding 入库，没有复杂的 schema 要维护。团队里一个人就能扛起来。

5.2 KG-RAG：运维复杂度陡增

图数据库（Neo4j、NebulaGraph 等）本身要运维，实体抽取和关系抽取的 pipeline 要维护，图 schema 变更时要处理历史数据迁移。更麻烦的是数据一致性：向量库和图库是两套存储，文档更新时两边都要同步，同步逻辑写不好就会出现"向量库有新数据、图库还是旧的"这种脏状态。

5.3 结构化 RAG：schema 是双刃剑

结构化 RAG 的运维成本主要在 schema 管理。schema 稳定时很省心，但业务一变、表结构一改，Text-to-SQL 的 prompt 和示例都要跟着调。而且权限控制在这里格外重要——让 LLM 直接生成 SQL 打数据库，必须做好行级权限和 SQL 注入防护，否则是个安全隐患。

5.4 dsh-knowledge：打包的代价与收益

dsh-knowledge 把上面这些复杂度封装起来了，收益是上手快、链路统一。但代价是：出问题时你要在它的抽象层里排查，而不是直接看底层组件。另外 AGPL-3.0 协议在商业场景下是个实打实的约束，如果你的产品要闭源对外，这条基本就否决了它作为核心依赖的可能。

注意：部署到内网服务器时，打包方案对离线环境的支持程度要提前验证。很多方案在联网环境下跑得好好的，一到纯离线环境就卡在依赖下载、模型加载这些环节。

6. 维度四：合规与协议——别等上线才发现问题

这一条我单独拎出来讲，因为它是一票否决项。技术再好，协议不兼容就是白搭。

6.1 AGPL-3.0 的实际影响

dsh-knowledge 采用 AGPL-3.0。这个协议的关键点在于：只要你通过网络向用户提供服务，且修改了代码，就必须开源你的修改。注意是"修改了代码"，如果你原样使用、不做修改，那只需要保留版权声明。但实际项目里，几乎不可能完全不改——配置调整、bug 修复、功能扩展，都算修改。

所以判断标准很简单：你的项目是否闭源对外提供服务。是，则 AGPL-3.0 方案基本出局；否（内部使用、或本身开源），则可以放心用。

6.2 其他方案的协议情况

纯向量 RAG 涉及的组件大多是 Apache-2.0 或 MIT，商用友好。图数据库要看具体产品，Neo4j 社区版是 GPL，企业版是商业授权。结构化 RAG 主要看你用的数据库和 LLM 服务，协议相对清晰。

6.3 数据合规

如果知识库里涉及用户隐私数据、商业机密，那数据不出内网是硬要求。这时候要确认：方案是否支持完全离线部署、embedding 模型能否本地跑、LLM 能否用本地部署的模型。dsh-knowledge 如果支持接入本地模型，那在内网场景下是可用的，但离线安装的坑要提前踩。

7. 维度五：生态与扩展性——你未来想往哪走

选型不能只看当下，还要看这套东西能不能跟着你一起长大。

7.1 插件与集成能力

dsh-knowledge 背靠 DeepSeek Harness 生态，插件体系是它的加分项。如果你已经在用 Harness 做 coding 开发或者写综述，那知识库作为 skill 挂载进去，工作流是打通的。热词里提到的"deepseek harness 插件推荐""skill 部署到内网服务器"这些，反映的正是这类集成需求。

但要注意：生态绑定是双刃剑。绑得越深，迁移成本越高。如果哪天你想换掉 Harness，知识库这层能不能独立出来，要提前想清楚。

7.2 模型可替换性

好的方案应该把 embedding 模型和生成模型都做成可替换的。向量 RAG 在这点上最灵活，换 embedding 模型就是重新编码一遍。打包方案要确认它是否锁定了特定模型，锁定的话，模型升级或替换时会很被动。

7.3 扩展路径

从纯向量 RAG 起步的团队，常见的演进路径是：向量 RAG → 加 rerank → 加混合检索（BM25+向量）→ 加图谱层。每一步都是在原有基础上叠加，不用推倒重来。dsh-knowledge 如果一开始就提供了这些层的开关，那演进成本会低很多。

8. 实操：怎么用一张表把选型决策落地

讲了这么多维度，最后落到实操。我自己的做法是做一个加权评分表，把上面五个维度按项目实际情况赋权重，然后给四个方案打分。

8.1 评分表模板

权重不是拍脑袋定的。查询能力匹配给最高权重，因为这是知识库的核心价值；合规协议虽然权重不高，但是一票否决项，不满足直接排除，不参与加权。

8.2 打分的一个真实例子

假设场景是：企业内部技术文档问答，数据以 Markdown 和 PDF 为主，查询以单跳事实为主、少量多跳，团队 2 人，内部使用不对外，已经在用 Harness 做开发。

• 数据形态：非结构化为主，向量 RAG 和 dsh-knowledge 都得高分
• 查询能力：单跳为主，向量 RAG 够用，KG 属于过度设计
• 运维成本：团队小，向量 RAG 和 dsh-knowledge 占优
• 合规：内部使用，AGPL 不构成障碍，dsh-knowledge 可用
• 生态：已用 Harness，dsh-knowledge 加分

结论：dsh-knowledge 和纯向量 RAG 都是合理选择。如果追求快速上线和生态打通，选 dsh-knowledge；如果追求最大灵活性和可控性，选纯向量 RAG 自建。

8.3 几个容易打错分的地方

第一，别高估自己的查询复杂度。很多团队一上来就说"我们要支持复杂推理"，结果真实用户 90% 的问题都是单跳事实。先上简单的，不够再加。

第二，别低估数据预处理的成本。KG-RAG 的实体抽取，在领域数据上往往需要大量标注和调优，这部分工作量经常被漏算。

第三，协议问题要提前问法务。别等开发完了才发现协议不兼容，返工成本极高。

9. 常见问题与排查技巧实录

这一节整理我在实际选型和落地过程中遇到的高频问题，都是文档里不会写的。

9.1 向量检索召回率低怎么办

先别急着换方案。按这个顺序排查：切分粒度是否合理（太大信息稀释，太小上下文断裂）→ embedding 模型是否匹配语种和领域 → 是否加了 rerank → 是否该上混合检索（BM25 补语义检索的短板）。八成的问题出在切分和 rerank，而不是向量库本身。

9.2 多跳问题答不准，一定要上图谱吗

不一定。先试试查询改写 + 迭代检索：让 LLM 先把复杂问题拆成子问题，逐个检索再汇总。这个方案成本远低于建图谱，能解决相当一部分多跳问题。只有当关系查询成为核心需求、且迭代检索也搞不定时，再考虑 KG。

9.3 离线内网部署卡在依赖上

打包方案在内网部署时，最常见的坑是依赖下载和模型加载。提前做这几件事：把所有依赖打成离线包、确认模型文件能本地加载、验证许可证校验是否需要联网。在联网环境先完整跑一遍部署流程，记录所有网络请求，再搬到内网。

9.4 Text-to-SQL 准确率上不去

三个方向：schema 命名规范化（别用拼音缩写）、给模型提供 few-shot 示例、加一层 SQL 校验和纠错。另外，把复杂查询拆成多步往往比让模型一次生成复杂 SQL 更可靠。

9.5 问题速查表

10. 我个人的选型体会

折腾了这么多轮，我最大的体会是：选型不是选最强的，是选最匹配的。dsh-knowledge 适合想要快速跑通、且已经在 Harness 生态里的团队；纯向量 RAG 适合追求灵活可控、查询以单跳为主的场景；KG-RAG 适合关系查询是核心需求的领域；结构化 RAG 适合数据本来就是表格、查询以统计筛选为主的场景。

还有一个反直觉的经验：先用最简单的方案跑起来，比花两周做选型对比更有价值。因为真实的问题分布，往往和你拍脑袋想的不一样。我见过太多团队在选型阶段纠结一个月，结果上线后发现 80% 的查询都是最简单的单跳事实，前面那些复杂设计全白搭。

最后分享一个小技巧：做选型对比时，别只看方案的能力清单，拿你自己的 20 个真实问题去实测。同一批问题喂给不同方案，看哪个答得准、答得快、答得稳。这比任何维度对照表都管用。数据不会骗人，实测出来的差距才是真差距。