掘金上推荐的那些开源知识库，解的是另一道题

掘金上那批推荐，解的是同一道题

这几个开源知识库项目看着像 4 个方向，其实都在做同一件事：你给文档，它给问答，文档从哪来没人问。

上个月我把掘金上关于企业知识库的高赞文章翻了一遍，前后 17 篇，提到的工具翻来覆去就那 4 个：Dify、FastGPT、RAGFlow、WeKnora。每篇的结构几乎一样，先讲大模型多强，再贴一张架构图，最后给一段启动命令。看完的感受不是学到了什么，而是这 17 篇其实在回答同一个问题，只是标题各不相同。

这个问题是：如果我手里已经有一堆文档，怎么让它们变得能问能答。切片多大、召回几条、要不要加重排、选哪个向量库，文章里讲得很细。它们的起点统一是上传文档那个按钮，讨论的全是按钮按下之后的事。按钮之前发生了什么，没有人写，也很少有人问。

我不是说这条路不对。Dify 我用过 3 个月，搭过 2 个内部问答，从装到能提问只花了 1 个下午，工作流编排也确实省事。FastGPT 的知识库配置更直白，RAGFlow 解析扫描件更有耐心。单看工程完成度，这 4 个项目都比我预期的高，文档也比我见过的多数商业产品诚实，更新也勤，社区回得也快。

但它们有一个共同前提，而且几乎没人在文章里提：文档已经整理好了。PDF 是干净的，目录是清楚的，术语是一致的。现实里我待过、看过的 6 个团队，没有一个满足这条。他们的资料不是没有，是没有收拢，散在 4 种系统里，谁也说不清哪份是最新的，也没人愿意承认这一点。

真正的缺口不在检索，在语料还没收拢

一个 8 人团队一年 1.5 万封邮件，里面全是答案，却没有一份能被上传的文档。引擎再好，也接不住这一步。

我待过一个 8 人的外贸团队，一天来回 60 多封邮件，一年差不多 1.5 万封。报价改到第 4 版、交期往后推 2 次、客户口头答应又反悔，这些过程全在邮件里。要说内容质量，它比事后补写的纪要准得多，因为写的时候没有人在总结，只是在办事，也没人打算把它当资料存下来。

我试过把它们变成能上传的文档。挑了 1 个合作 2 年的客户，导出 83 封邮件，整理成 1 份 9 页的 PDF，花了 3 个晚上。第 4 个晚上我放弃了，因为另外还有 41 个客户。按这个速度，把全公司邮箱整理完要 4 个多月，而整理完那天，新的 500 封又进来了，这个循环没有出口，我算了 2 次都一样。

这件事没人愿意做，也不该有人做。让 3 个销售每周花半天导出邮件、贴进文档、统一格式，他们宁可去打电话。我统计过一次，团队里真正愿意干这活的人数是 0。开源知识库不会替你解决这个 0，它只在你把文档放进去之后，把检索做得更聪明，放进去这一步它管不了。

Gartner 有个估算，企业数据里 35% 到 40% 从来没被有效利用。我以前以为这是分析能力不够，后来觉得更像入口问题：数据在，但没有进入任何一个能被检索的系统。邮箱就是最典型的一处，它每天都在产生，却几乎不参与任何知识库，那 35% 里有很大一块就躺在这里。

引擎和燃料，是两门手艺

开源知识库解决的是怎么烧，没人管柴从哪来。多数公司缺的不是炉子，是堆在院子里还没劈的木头。

把这两类东西放在一起比功能，很容易比歪。Dify 那类项目做的是引擎：切片、向量化、召回、重排、工作流、权限，每一项都值得单独研究。它们假设燃料已经堆在门口，剩下的是怎么烧得更充分。这个假设在互联网公司成立，在多数中小企业不成立，两种公司的资料来源不同。

我见过一个 12 人的公司买了显卡服务器，装好 RAGFlow，导入了 30 份产品手册和 5 份制度，问答很准。但销售问上一个客户最后压到几折，系统答不出来，因为答案在一封 2023 年的邮件里。服务器开着，电费照付，半年里真正用过的人只有 2 个，后来我把它关了，现在它只用来跑测试。

发动机再好，没有燃料也只是个摆件；燃料再多，没有发动机也只能看着。差别在于这两件事的难度不同：买发动机是一次性的，准备燃料是每天都要做的。多数团队不是卡在第一次，而是卡在每天。这句话我写在选型表的第一行，比任何参数都先看。

所以我后来选工具，先问燃料在哪，再问引擎怎么样。资料都在共享盘里、结构清楚、每周有人更新，开源方案的收益会很快显现。资料主要在邮件和聊天里，先补燃料这一环，比先研究切片参数实际得多。顺序不同，花的时间能差 3 倍，得到的结论也可能正好相反。

什么情况下，该选开源方案自己搭

有研发、有已整理的语料、要做对外客服机器人，这 3 种情况自己搭更合适，别被开箱即用这四个字劝退。

第一种，公司有研发，哪怕只有 1 个后端。Dify 和 FastGPT 的部署门槛不高，1 台 4 核 8G 的机器就能跑起来，接口、鉴权、日志都能接进现有系统。有人的时候，开源带来的可控性是真的，改一行代码就能改行为，这在闭源产品里做不到，也不用等排期，改完当天就能上线，这点我很看重。

第二种，语料已经整理好。我见过一家做工业设备的公司，产品手册 400 多页、故障码 2000 多条、维修记录按型号归档，全是结构化文本。这种公司上 RAGFlow，2 周就能跑出可用问答，因为最难的那一步他们过去 5 年一直在做，导入只是把已有的秩序搬进新系统，不需要重新分一次类。

第三种，要做对外的客服机器人。这类场景要求答案稳定、口径统一、能拦住敏感问题，还需要把每次对话留档。开源方案的流程编排和权限控制更细，可以按渠道、按产品线分别配置，出了问题能查到是哪一步。对外场景值得多花 2 周，猜错的代价比工钱高。

反过来说，团队没有研发、语料散在邮箱、需求只是内部查资料，自己搭通常会停在部署成功那一步。我见过 3 个这样的项目，最后的共同结局是容器还在跑，没人再用。不是技术失败，是没有人负责喂它，也没有人愿意每天花 1 小时喂它，这是最常见的失败方式。

我现在的用法：先收拢，再谈问答

邮箱这边先做收拢，把散落的往来变成能查的东西；真要对外做机器人，再上开源引擎，两边接得上。

我现在把顺序倒过来。先解决燃料，把邮箱里的往来收拢成能问的索引，再决定要不要搭引擎。这件事我交给牛油局做，它在浏览器本地处理邮件，只有我主动提问时才把必要的几段上下文发给 AI，原文不上传服务器，不用了一键删除。装到出第一份结果，我用了 3 分钟。

效果上它不神奇。我问这家客户去年为什么砍单，它给的是一段带日期的往来摘录，不是结论，判断还是我自己做。但这一步省掉了我翻 20 分钟邮件的动作。一年 60 个客户，粗算能省 20 多个小时，这个数我自己记了 3 个月，误差不超过 2 小时，比我预估的还多一点。

它也不替代 CRM，不自动发信，只做还原。哪天我们要做对外客服机器人，我会去看 Dify 或 RAGFlow，那时候语料已经被收拢过一轮，导入就是现成的。开源方案和牛油局不冲突，一个管烧，一个管捡柴，硬要二选一反而两头都做不好，我现在就是两边各管一段，不硬凑在一起。

掘金上那些文章值得看，讲切片和召回的部分我抄过 2 次笔记，也确实帮我省了试错。但要先认清自己站在哪一步：文档已经齐了，去挑引擎；文档还散着，先想办法收拢。顺序搞反，投入再多也只会得到一个跑得很顺的空库，这是我第 2 次踩同一个坑，所以这次先看燃料。

相关阅读