选型时怎么比：dsh-knowledge 与三类 RAG 方案的维度对照

把「dsh-knowledge / 独立向量数据库服务 / 云托管 RAG / 纯关键词全文检索」摆在一起比，很容易变成参数堆砌。但这些数字往往只在各自的评测口径下成立，更可用的做法是换一批结构性维度去比：部署形态、运行位置、检索方式、许可证、资源门槛、数据落盘、证据组织。这篇只做维度对照，不做排名。想先看看同类插件的中文形态，可参考 完整插件清单与汉化避坑指南。

先交代 dsh-knowledge 的定位：DeepSeek Harness 的独立、可开源 bundle 插件，README 原文说它「既可以零向量配置运行，也可以完全使用本地模型，不要求额外部署独立的知识库服务」。当前发布版 v0.4.1，npm 包名 dsh-knowledge，许可 AGPL-3.0，详情页显示 57★、综合分 53.2、周下载 749（数据截至 2026/9/29），并已在 dsh 0.2.0-rc.2 下完成 L4 真实安装验证。

维度一：部署形态

dsh-knowledge 是 bundle 插件，命令 dsh plugin –profile web add dsh-knowledge，装在 profile 层，无论 DSH 来自 npm 还是源码 checkout 都用同一条。独立向量数据库服务（自建 Milvus / Qdrant 这类）要单独部署、扩容、备份，换来清晰的服务边界与多应用共享。云托管 RAG 走托管 API，部署成本最低，代价是数据出境与按量计费。纯关键词全文检索可以只是一个索引文件加查询库。

倾向：只服务 DSH 里的一次会话，插件形态摩擦最小；同一份向量要被多个业务系统复用，独立服务的共享边界更值钱；没有运维能力又接受数据上云，托管更省事。

维度二：运行位置

dsh-knowledge 覆盖本地 embedding、本地 rerank、本地 OCR，也支持 OpenAI 兼容接口和 Ollama，可以只把算力放远端、索引留在本地。独立向量数据库服务通常不含模型推理，embedding 由谁算取决于你另外接的服务；云托管 RAG 几乎把模型一并托管；纯关键词全文检索完全不涉及模型。

倾向：有数据不出机要求时，本地 embedding 与 OCR 是刚需；算力紧张但允许文本经过远端接口，可以只把 embedding 放出去；文档量不大又对延迟敏感，纯关键词省掉整个模型环节。

维度三：检索方式

这是差异最大的一维。dsh-knowledge 走混合路线：FTS5 BM25 词法召回 + 向量召回 + RRF 融合 + MMR 去冗余 + 可选 cross-encoder 重排，未配置 embedding 时退化为 CJK 二元组与拉丁词 BM25。独立向量数据库服务大多以纯向量检索为主，近年也补上稀疏向量或关键词混合，但策略与调参面各不相同。云托管 RAG 通常把混合封装成默认能力，可调空间小。纯关键词全文检索只有词法一路，没有语义命中。

倾向：文档里专有名词、编号、代码符号多，纯向量容易漏召回；查询与文档用词差异大（口语问法 vs 书面文档）时，向量路才值钱。可调项（向量路权重、相似度阈值、MMR）摆在明面上的方案适合反复调优，把混合封装成默认行为的适合不想调参的人。

维度四：许可证

dsh-knowledge 的许可是 AGPL-3.0，属于强 copyleft，二次分发与闭源集成需要评估——计划把包含它的产品打包分发，或作为闭源服务对外提供，先让法务过一遍通常比事后返工便宜。独立向量数据库服务的许可证各不相同（Apache-2.0、SSPL、商业授权都有），云托管 RAG 的约束主要在服务条款，纯关键词全文检索取决于你用的那个库。

倾向：内部自用、不分发，许可证一般不构成障碍；要对外分发闭源产品，就得把许可证当作一等的选型条件，而不是附注。

维度五：资源门槛

dsh-knowledge 的运行要求写得很直白：Node.js ^22.19.0 || >=24.0.0、pnpm >=10、已安装并初始化 DSH。磁盘上，默认本地 embedding 模型 onnx-community/Qwen3-Embedding-0.6B-ONNX 约 585 MB、1024 维，扫描件 OCR 模型约 21 MB，而且都是「下载了才占用」——不下载也能用关键词检索。独立向量数据库服务按索引规模预留内存与磁盘，云托管 RAG 把这块转成调用费，纯关键词全文检索的占用与索引文本量基本线性。

倾向：磁盘宽裕、愿意为语义检索多付几百 MB，本地模型很好安排；机器紧凑或按量计费更划算时，纯关键词或纯托管更省心。Node 版本不够的人在这一维直接出局，因为这是硬门槛，不是可以绕过的建议值。

维度六：数据落盘

dsh-knowledge 把知识库、文档和运行时配置通过 DSH 的 storageDomain 持久化，分块保存在独立 SQLite 文件 knowledge-chunks.sqlite（可用 chunkStorePath 调整）；词法检索用 FTS5 trigram 索引，向量用 Float32Array 常驻缓存并精确失效，旧 JSON 分块首次启动执行幂等迁移。必须知道的边界：没有存储后端时会自动退化为内存模式——进程重启后状态不再持久，选型阶段就该确认。独立向量数据库服务的数据在自己的存储引擎里，备份迁移是另一套流程；云托管 RAG 的数据在云端；纯关键词全文检索的索引文件可以直接拷贝。

倾向：需要「索引和业务数据一起备份」，独立 SQLite 文件更直观；需要跨环境热迁移整套向量库，独立服务的导出能力更成熟。

维度七：证据组织

dsh-knowledge 为每个命中动态生成有序的 ContextWindow，按 before → anchor → after 组织证据，并默认不跨标题路径，不会把相邻章节误当成本章节的延续；桥接文本不写入索引或 embedding，只在组装时临时拼装。独立向量数据库服务通常只返回 top-K 片段，上下文拼接由调用方自己做；云托管 RAG 的拼装策略由平台决定；纯关键词全文检索同样只给片段。

倾向：要让模型基于「命中前后一段完整论述」作答、而不是零散片段时，内置 ContextWindow 省掉一层自研拼装；如果本来就有成熟的 prompt 组装逻辑、只想要裸片段，这层能力的价值有限。

总结

七个维度看下来，每一类方案都有自己的适配面：插件形态胜在摩擦小，本地模型胜在数据不出机，独立服务胜在共享与迁移，托管方案胜在省运维，纯关键词胜在零模型成本。选型的动作不是排名次，而是把自己最不能被妥协的一两条维度先圈出来，再看哪一类天然满足它。想把这些插件放在同一张清单里横向看，可参考 完整插件清单与汉化避坑指南。

适合与不适合

适合：正在为 DSH 选知识库方案、需要一份结构化对照维度的人；要判断「自建向量库 vs 直接装插件」哪个摩擦更小的人；需要把许可证、数据落盘这类硬约束提前摆到台面上讨论的团队；想搞清 585 MB 级本地模型与「零向量配置」两条路线差别的人。

不适合：想要一个「哪个最好」的排名结论、不打算按自身约束做取舍的人（这篇只给维度，不给排名）；Node 版本低于 ^22.19.0 又不想升级的人；要把插件打包进闭源产品对外分发、又不愿评估 AGPL-3.0 义务的人；数据必须留在云端、完全没有本地磁盘可用的环境；需要跨多个业务系统共享同一份向量、插件形态满足不了的场景。

标签：dsh-knowledge、DeepSeek Harness、RAG 选型、方案对比、AGPL-3.0

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。