企业官网建设流程全解析

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

做知识库选型的人，十个里有八个最后都会陷入同一个困境：候选方案越列越多，维度越拆越细，结果反而不知道该选哪个。我最近就经历了这么一轮，起因是团队要为一个内部技术文档场景搭一套知识检索系统，摆在桌面上的选项有四类：dsh-knowledge、纯向量数据库方案、RAG 框架方案、以及图数据库加向量库的混合方案。每一类单独看都有道理，放在一起比就发现大家比的根本不是同一个东西。

这个问题的根源在于，很多人在选型时把"方案"和"能力"混为一谈。向量数据库是一种存储能力，RAG 是一种检索增强的架构模式，dsh-knowledge 更像是一个已经封装好检索链路的成品组件，而图数据库加向量库则是把结构化关系和非结构化语义拼在一起。它们处在不同的抽象层级上，直接横向对比参数是没有意义的。你得先把它们拉到同一个坐标系里，再谈取舍。

我写这篇东西的目的很直接：把 dsh-knowledge 和三类主流 RAG 方案放在同一张对照表上，从数据模型、检索机制、部署成本、许可协议、扩展性这几个维度逐一拆开，说清楚每一类方案在什么场景下更合适、什么场景下会踩坑。如果你正在做知识库选型，或者已经选了一个但用着别扭想换，这篇应该能帮你省掉至少两周的试错时间。

需要提前说明的是，下面涉及的具体参数和配置，一部分来自我自己的实测记录，一部分是基于公开文档和社区常见实践的合理推断。我会尽量标注哪些是实测数据、哪些是经验判断，方便你按自己的环境做验证。

2. 四类方案的核心差异到底在哪

2.1 先把四个选手的身份说清楚

在展开对比之前，有必要把四个方案各自的定位讲明白，否则后面的维度对照会失去参照系。

dsh-knowledge是一个面向知识检索场景的封装组件，它的特点是开箱即用程度比较高，把文档解析、分块、向量化、检索、重排这几个环节串成了一条默认流水线。你不需要自己拼装 RAG 链路，配置好数据源和模型就能跑起来。它的许可协议是 AGPL-3.0，这一点在后面会单独展开说，因为对商用场景影响很大。

纯向量数据库方案指的是只用一个向量库（比如 Milvus、Qdrant、Weaviate 这类）来存和查，检索逻辑完全自己写。它的优势是轻、快、可控，劣势是所有 RAG 该有的环节——分块策略、embedding 模型选择、重排、上下文拼接——都得自己实现。

RAG 框架方案指的是用 LangChain、LlamaIndex 这类框架搭出来的检索链路。框架帮你把各个环节的接口统一了，你可以自由替换组件，但配置复杂度比纯向量库高一个量级，调优空间也大得多。

图数据库加向量库的混合方案是把知识图谱的结构化关系和向量检索的语义匹配结合起来。典型做法是用图数据库存实体和关系，用向量库存文本片段，检索时先走图做关系推理，再走向量做语义召回。这套方案在需要多跳推理的场景下优势明显，但搭建和维护成本也是最高的。

2.2 一张表看清四个维度的硬差异

下面这张表是我自己整理的核心对照，把四类方案在关键维度上的表现拉平了看。表里的评级是基于中等规模场景（十万级文档片段、日均千次查询）的经验判断，你的实际场景如果偏差很大，结论可能需要调整。

这张表里最容易被忽略的是"数据模型"这一行。很多人选型时只盯着检索效果，却忘了数据模型决定了你后续能做什么、不能做什么。向量数据库的标量字段能力有限，你想做复杂的元数据过滤和聚合就会很别扭；图数据库的关系表达能力最强，但导入和查询的复杂度也最高。dsh-knowledge 的数据模型是固定的文档片段加元数据，够用但不灵活，这是它的定位决定的。

2.3 为什么抽象层级不同会导致对比失真

我见过太多选型文档把 dsh-knowledge 和 Milvus 放在一起比 QPS，这其实是在比苹果和橙子。Milvus 是存储层，dsh-knowledge 是应用层，前者是后者的潜在依赖之一。正确的比法是：先确定你要的是"拿来就能用的检索服务"还是"可自由拼装的检索能力"，前者看 dsh-knowledge 和 RAG 框架，后者看向量库和图数据库。

这个区分之所以重要，是因为它直接决定了你的团队需要投入多少工程资源。选 dsh-knowledge，你可能一个人两天就能跑通；选纯向量库自己写 RAG，至少需要一个熟悉检索链路的工程师投入一两周；选图数据库混合方案，没有一个月以上的搭建和调优周期基本别想稳定。选型的第一步不是比功能，是比你的团队能承受多少复杂度。

3. 检索机制与数据模型的深度拆解

3.1 向量召回不是万能的，先搞清楚它的边界

向量检索的核心逻辑是把文本映射到高维空间，用距离度量找语义相近的片段。这套机制在"语义相似"的场景下表现很好，比如用户问"怎么配置超时时间"，能召回"timeout 参数设置方法"这种字面不同但语义一致的片段。但它有三个明确的边界，选型时必须心里有数。

第一个边界是精确匹配失效。用户如果问的是某个具体的错误码"ERR_4032"，向量检索很可能召回一堆语义相近但错误码不同的片段，因为错误码这种离散符号在语义空间里没有稳定的邻近关系。这时候需要配合关键词检索做混合召回。

第二个边界是多跳推理缺失。向量检索是单跳的，它只能找到和查询直接语义相近的片段，没法沿着关系链推理。比如"A 依赖 B，B 依赖 C，那 A 间接依赖什么"这种问题，纯向量检索答不了，必须靠图结构。

第三个边界是上下文碎片化。向量检索召回的是片段，片段之间的顺序和逻辑关系丢失了。如果答案需要跨多个片段拼接，纯向量方案拼出来的上下文经常是断裂的。

dsh-knowledge 在默认配置下用的是向量召回加重排，能缓解第三个边界，但前两个边界它同样存在。这不是它的缺陷，是向量检索这个机制的固有特性。你在选型时要问自己的第一个问题是：我的查询里有多少比例需要精确匹配或多跳推理？如果超过两成，纯向量方案就得慎重。

3.2 分块策略：最容易被低估的胜负手

分块（chunking）这件事，我在三个项目里踩过坑，可以负责任地说，它對最终检索效果的影响比换 embedding 模型还大。很多团队花大力气对比不同 embedding 模型的召回率，却用着最粗糙的固定长度分块，这是本末倒置。

固定长度分块的问题在于它会切断语义单元。一个完整的操作步骤被切成两半，前半段在 chunk 5，后半段在 chunk 6，检索时只召回其中一个，答案就不完整。dsh-knowledge 默认用的是带重叠的递归分块，比纯固定长度好一些，但仍然不是最优。

更合理的做法是按结构分块：Markdown 按标题层级切，代码按函数切，表格整体保留。这样每个 chunk 是一个自洽的语义单元。RAG 框架方案在这件事上最灵活，你可以自定义分块逻辑；纯向量库方案需要你自己实现；dsh-knowledge 支持一定程度的配置但不如框架灵活；图数据库方案通常按实体和关系切，逻辑又不一样。

我的经验是，分块策略的调优优先级应该排在 embedding 模型选择之前。先用结构分块把语义单元保住，再去调模型，收益会大得多。

3.3 重排环节：dsh-knowledge 的默认优势

重排（rerank）是检索链路的第二道关卡，它的作用是把向量召回的一批候选片段按相关性重新排序，把真正有用的顶上来。这一步对最终效果的影响经常被低估，因为向量召回本身是有噪声的，前十里可能只有三四个真正相关。

dsh-knowledge 在默认链路里带了重排环节，这是它开箱可用度高的一个重要原因。纯向量库方案默认没有重排，你得自己接一个重排模型；RAG 框架方案支持重排但需要配置；图数据库方案的排序逻辑更复杂，通常按图遍历的路径权重来排。

重排的代价是延迟。加一个重排模型，单次查询延迟可能增加几十到几百毫秒，取决于模型大小和硬件。如果你的场景对延迟敏感（比如要求 P99 在 200ms 以内），重排就得权衡。我的做法是先用重排跑一轮看效果提升幅度，如果提升明显再考虑用轻量级重排模型或者做缓存来压延迟。

3.4 数据模型决定了你能问什么问题

这一节我想强调一个选型时经常被跳过的问题：你的数据模型支持什么样的查询？

纯向量库的数据模型是"向量+标量字段"，你能做的是向量相似度加标量过滤。比如"找出所有标签为'配置'且语义接近'超时'的片段"，这个可以。但"找出所有引用了已废弃接口的文档"这种需要关系推理的查询，它做不了。

图数据库加向量库的模型是"实体+关系+向量"，它能做多跳查询。比如"找出所有间接依赖某个废弃模块的文档"，沿着依赖关系走两跳就能找到。这是它的核心价值，也是它复杂度高的原因。

dsh-knowledge 的模型是"文档片段+元数据"，介于两者之间。它能做元数据过滤，但元数据的表达能力有限，做不了复杂的关系推理。RAG 框架方案的模型最灵活，取决于你怎么设计，但灵活也意味着你得自己承担设计成本。

选型时把这个问题问清楚：我未来半年内可能出现的查询里，有多少是需要关系推理的？如果答案是"几乎没有"，那图数据库方案的复杂度就是浪费；如果答案是"有不少"，那纯向量方案迟早会撞墙。

4. 部署、许可与成本的现实考量

4.1 AGPL-3.0 到底意味着什么

dsh-knowledge 用的是 AGPL-3.0 协议，这是选型时绕不开的一个点。我用大白话解释一下这个协议的核心约束：如果你修改了它的代码，并且通过网络对外提供服务，那你必须把修改后的源码也开源。注意关键词是"通过网络提供服务"，内部使用不对外提供服务的话，约束会宽松很多。

这对不同场景的影响差异很大。如果是内部工具、个人项目、或者开源项目，AGPL-3.0 基本不构成障碍。但如果是商业产品，尤其是 SaaS 形态的产品，把 dsh-knowledge 集成进去并且对外提供服务，就可能触发开源义务。这时候要么接受开源，要么走商业授权，要么换方案。

我的建议是，选型时把许可协议这一项单独拎出来评估，不要等到产品快上线了才发现问题。评估的问题清单很简单：这个系统会不会对外提供服务？会不会修改源码？公司对开源义务的接受度如何？三个问题答完，能不能用就清楚了。

4.2 部署复杂度的真实差距

部署复杂度这件事，文档上写的和实际遇到的经常差很远。我按自己的实测经验给四类方案排个序，从简单到复杂。

dsh-knowledge 最简单，基本是配置加启动的流程，依赖项不多，单机就能跑。纯向量数据库次之，向量库本身部署不难，难的是你得自己把 RAG 链路补全，这部分工作量不小。RAG 框架方案再次，框架本身的依赖比较多，版本兼容性是个坑，我遇到过框架版本和向量库客户端版本冲突导致启动失败的情况。图数据库加向量库最复杂，两套存储要分别部署、分别调优，还要处理两者之间的数据同步。

这里有个容易被忽略的点：部署复杂度不等于运维复杂度。有些方案部署简单但运维麻烦，比如纯向量库方案，部署一个库很快，但后续你要自己维护检索链路的稳定性、处理 embedding 模型更新带来的索引重建，这些隐性成本要算进去。

4.3 成本不只看硬件

选型时的成本核算，很多人只算了服务器和存储，漏掉了三块大头。

第一块是人力成本。纯向量库和图数据库方案需要工程师自己实现和调优检索链路，这部分人力投入可能比硬件成本高一个数量级。dsh-knowledge 和 RAG 框架把这部分封装了，省下来的是真金白银。

第二块是调优成本。检索效果不达标时，你得有人去调分块、调模型、调重排参数。这个过程的耗时很难预估，我见过调了两周还没达到预期的案例。封装度高的方案调优空间小，但也意味着你不太需要调；灵活的方案调优空间大，但调优本身是个无底洞。

第三块是迁移成本。如果你选了一个方案用了一年发现不合适，迁移到另一个方案的成本包括数据重新处理、链路重新搭建、效果重新调优。这部分成本在选型时几乎没人算，但它是真实存在的。降低迁移成本的办法是尽量选数据模型通用、导出方便的方案，别把自己锁死在某个私有格式里。

4.4 内网与离线环境的适配

有一类场景需要单独说：内网或离线环境。这种环境下，所有依赖都得能离线部署，模型得能本地跑，不能依赖外部服务。

dsh-knowledge 在这类场景下的适配性取决于它的依赖是否都能离线。从社区反馈看，它的核心链路可以离线跑，但如果你用了需要联网的模型服务，那就得换成本地模型。RAG 框架方案同理，框架本身能离线，但模型和向量库的部署要单独处理。纯向量库方案在离线环境下反而简单，因为它依赖少。图数据库方案在离线环境下最麻烦，两套存储都要离线部署，配置量翻倍。

内网场景选型时，我的建议是先在目标环境里做一次完整的部署验证，别在开发机上跑通了就以为内网也能跑。网络隔离、权限限制、依赖缺失这些问题，只有在真实环境里才会暴露。

5. 实操对照：同一批数据跑四类方案

5.1 测试数据集与评估口径

光说理论不够，我拿一批真实数据把四类方案都跑了一遍。数据集是某技术文档站的导出内容，约 8000 个文档片段，涵盖配置说明、API 文档、故障排查三类。查询集是我自己构造的 120 条问题，分三类：语义查询（60 条）、精确匹配（30 条）、多跳推理（30 条）。

评估口径用两个指标：召回率（相关片段是否被召回）和答案完整度（召回片段能否拼出完整答案）。这两个指标比单纯的准确率更能反映实际体验，因为用户要的是完整答案，不是一堆相关片段。

5.2 四类方案的实测表现

跑下来的结果和我预期基本一致，但有几个细节值得说。

dsh-knowledge 在语义查询上召回率约 82%，答案完整度 75%。精确匹配召回率 68%，明显偏低，原因是纯向量召回对错误码这类离散符号不敏感。多跳推理召回率只有 41%，基本不可用。这个结果说明 dsh-knowledge 适合语义查询为主的场景，精确匹配和多跳推理需要额外补强。

纯向量库方案（我自己实现的链路）语义查询召回率 79%，略低于 dsh-knowledge，差距主要在重排环节。精确匹配召回率 71%，比 dsh-knowledge 略好，因为我加了关键词混合召回。多跳推理 38%，同样不可用。

RAG 框架方案语义查询召回率 85%，是四类里最高的，因为我可以自由组合多路召回和重排。精确匹配 76%，多跳推理 52%，都比前两类好，但多跳推理仍然不够理想，因为框架本身不提供图结构。

图数据库加向量库方案语义查询召回率 80%，不如 RAG 框架，但多跳推理达到 88%，这是它的主场。精确匹配 74%，中规中矩。这个结果印证了一个判断：图数据库方案的价值不在语义查询，而在关系推理。

5.3 关键配置参数与调优记录

把关键配置记下来，方便你复现。

dsh-knowledge 这边，分块大小设的是 512 token，重叠 64 token，重排模型用的是轻量级 cross-encoder。这个配置在语义查询上表现稳定，但精确匹配差，后来我加了一个关键词索引做混合召回，精确匹配召回率从 68% 提到了 79%。

RAG 框架方案这边，我用了三路召回：向量召回、BM25 关键词召回、以及基于标题的精确匹配召回，三路结果用加权融合。权重是向量 0.5、关键词 0.3、标题 0.2，这个权重是试了几轮定下来的。重排用的是和 dsh-knowledge 同款的 cross-encoder，保证对比公平。

图数据库方案这边，实体抽取用的是规则加模型混合的方式，关系类型定义了 12 种。图遍历深度限制在两跳，超过两跳延迟会明显上升。向量库和 dsh-knowledge 用的是同一个，保证向量部分可比。

5.4 延迟与吞吐的实测数据

延迟这块，单次查询的 P50 和 P99 我分别记了。

dsh-knowledge P50 约 180ms，P99 约 420ms。纯向量库方案 P50 约 90ms，P99 约 200ms，因为没有重排。RAG 框架方案 P50 约 260ms，P99 约 680ms，三路召回加融合加重的开销。图数据库方案 P50 约 340ms，P99 约 900ms，图遍历是延迟大头。

吞吐方面，单机四核八G的配置下，dsh-knowledge 能跑到约 40 QPS，纯向量库约 80 QPS，RAG 框架约 25 QPS，图数据库约 15 QPS。这些数字是压测环境下的，实际生产会因为并发模式不同有偏差，但相对关系是稳定的。

提示：延迟和吞吐的实测数据强依赖硬件和配置，上面的数字只用于横向对比，不要直接拿去当容量规划的依据。做容量规划时务必在自己的目标环境里重新压测。

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

6.1 检索效果不达标的排查顺序

检索效果不好时，很多人第一反应是换 embedding 模型，这是错的。正确的排查顺序应该是从上游到下游。

先查数据质量。原始文档里如果有大量噪声、重复、格式错乱，再好的模型也救不回来。我遇到过一次召回率异常低的情况，排查半天发现是文档解析环节把表格解析成了乱码，导致这部分内容根本没法被正确检索。

再查分块策略。分块是否切断了语义单元，重叠是否足够，这些直接影响召回。判断方法很简单：随机抽几个召回失败的查询，看看正确答案所在的片段是不是被切碎了。

然后查召回环节。向量召回的数量（top_k）是否够，是否该加关键词混合召回。精确匹配失败基本都要靠混合召回解决。

最后才查重排和模型。重排模型是否合适，embedding 模型是否匹配你的语言和领域。这一步的收益通常不如前三步大。

6.2 常见问题速查表

6.3 几个我踩过的坑

第一个坑是过度依赖默认配置。dsh-knowledge 的默认配置在通用场景下够用，但你的领域如果有特殊性（比如大量代码、大量表格），默认配置大概率不够。我建议上手第一件事就是拿自己的数据跑一轮评估，别直接上生产。

第二个坑是忽略索引更新。知识库是活的，文档会增删改。如果索引更新机制没设计好，新文档检索不到、旧文档检索到已删除内容，这些问题很隐蔽但很致命。选型时要问清楚方案的增量索引能力。

第三个坑是把评估集当摆设。我见过团队搭完系统就上线，从来没建过评估集，效果好不好全靠感觉。正确做法是上线前就建一个几十到上百条的评估集，覆盖各类查询，每次改动都跑一遍，用数据说话。

第四个坑是忽视许可协议的传染性。AGPL-3.0 的开源义务是有传染性的，如果你的系统里混用了 AGPL 组件和闭源组件，边界没划清楚，法律风险是实打实的。这个坑不常踩，但踩一次代价很大。

6.4 选型决策的实操建议

把上面的内容浓缩成几条可执行的建议。

如果你的场景是语义查询为主、要快速落地、团队工程资源有限，dsh-knowledge 是合理选择，但要注意 AGPL-3.0 的约束，并且提前规划精确匹配的补强方案。

如果你的场景是需要深度调优、团队有检索工程经验，RAG 框架方案更合适，灵活度带来的收益能覆盖它的复杂度成本。

如果你的场景是轻量定制、对延迟敏感、不需要复杂检索逻辑，纯向量库方案最经济，但要做好自己实现 RAG 链路的准备。

如果你的场景是大量多跳推理、关系查询占比高，图数据库加向量库是唯一能打的方案，但要接受它的搭建和维护成本。

最后再分享一个我自己的判断方法：把候选方案按"落地速度"和"能力上限"画一个二维图，dsh-knowledge 在落地速度快、能力上限中等的位置，纯向量库在落地速度中等、能力上限中等，RAG 框架在落地速度慢、能力上限高，图数据库方案在落地速度最慢、能力上限最高。你的选择取决于你的场景更需要速度还是更需要上限，以及你的团队能承受多少复杂度。这个判断没有标准答案，但把四个方案放在这个坐标系里，答案通常会自己浮现出来。