我用OpenClaw搭了个企业知识库,说说真正的坑和甜头-夜雨聆风

我用OpenClaw搭了个企业知识库,说说真正的坑和甜头

今年年初我在自己的服务器上搭了一套 OpenClaw，跑了几个月之后，干了一件事：把团队的历史文档、API 说明、项目复盘笔记全喂进去，接上 RAG。

当时想法很简单——别再让同事在群里问”那个XX配置在哪”了。

现在跑了一个多月，有些话想说说。

先说结论

这玩意儿有甜头，但跟很多人想象的不太一样。

甜头不在”AI能自动回答所有问题”，而在它让”找东西”这件事变得不需要技巧了。

以前翻文档靠两样东西：搜索引擎和人的记忆。搜索引擎搜不到你要的，你得知道文件大概在哪、谁写的、什么关键词。这些对新人来说门槛太高。

现在直接问就行。虽然偶尔答错，但至少方向对。

但坑也有。我踩了三个。

这个其实很多人说过，但只有自己试了才知道有多疼。

我把五年前的几十篇项目复盘 PDF 丢进去，想着”这些是团队的经验沉淀啊，喂给 AI 肯定能用”。结果一测——AI 的回答充满了”基于项目复盘，我们建议……”这种模板话，完全没法直接用。

后来我才反应过来：那些文档本身就是口水中带着信息写的，东拉西扯，一段话里有一句有用的、五句是感叹。

RAG 不是魔法。它只能放大你给它的东西。你喂的是垃圾，它吐的就是加了调味料的垃圾。

解决方法是：我把文档重新整理了一遍，每篇只保留了核心事实、时间节点和决策原因，去掉所有感想和修饰。 效果直接上了一个台阶。

很多人以为 RAG 的瓶颈在模型——模型不够聪明，回答才会跑偏。

我的体验是：大部分跑偏不是因为模型不行，是因为它没找到对的文档。

OpenClaw 用的是混合检索——向量语义搜索 + 关键词 BM25。刚开始我天真地以为”语义搜索能理解意图，肯定比关键词准”。

结果试了几天发现，语义搜索有时候太”发散”了。我在测试环境问”部署配置”，它能搜出三个月前我写过的一篇博客，因为博客里也提到了”部署”这个词。

后来我调了一件事：给不同文档打标签，让召回可以按标签过滤。 比如”只有标记为技术文档的资料，才能作为回答”部署”类问题的依据。”这样准确率高了不少。

OpenClaw 的 agent 机制让 RAG 可以用在对话流里。但有个问题——你给的资料越多，越容易把真正有用的信息顶出上下文窗口。

我刚开始做的是把所有相关文档摘要都塞给 agent，让它自己挑。结果 agent 经常被干扰，尤其是当两个项目有相似技术栈的时候，它会混淆 A 项目的配置和 B 项目的 API。

现在的做法是：先检索出大概 5-8 个关键片段，只把这些片段放进上下文。 不是越多越好，是越对越好。

说了这么多坑，说说值不值得。

最让我觉得值的一刻是：一个新来的同事，第一天自己问出了”这个 API 的上次重构是什么时候、为什么改的”——那些写在三个月前的技术评审文档里的内容。

没有 RAG 的话，他要么来问我（我不一定记得），要么靠缘分搜到。

知识不至于烂在文件夹里，这就是 RAG 对企业的价值。

目前我跑的是 OpenClaw 的默认 RAG 方案：LanceDB 做向量存储，混合检索，搭配 DeepSeek 模型。

日常使用的体验是——70% 的问题能直接命中，20% 的方向对但细节需要人工核对，10% 完全跑偏。

这个比例对生产环境还不够，但作为”辅助搜索”已经能省不少时间了。

建议从小范围开始。别幻想一步到位建一个”企业大脑”。

先挑一个痛点最明确的文档集——比如新人的 FAQ、运维的常见问题、某个 API 的更新历史——把这个做透了，再逐步扩展。

还有一点：别让员工觉得”这玩意儿会替代我”。 我们在推的时候把它定位成”帮你少翻文档的工具”，不是”能回答问题的人工智能”。接受度完全不一样。

最后说一句：工具只是工具。把文档写好、把知识管好，才是底子的事。RAG 能帮你放大这些，但不能替你造这些。

现阶段我对 RAG 的态度是：有用，但用得克制。开源方案的门槛比想象中低，但调好的耐心比想象中要多。

如果你也在试，欢迎聊聊你的体验——我很想知道同行踩的坑是不是跟我一样。