扣子知识库搭建：上传只是第一步，能被检索到才算数
在扣子里建知识库很简单：建一个库、传文档、挂到 Bot 上。三步就完了。
难的是让它答得准。 而这件事的成败，七成在你上传之前就决定了。
扣子的界面、配置项和功能会随版本调整，本文讲的是方法和判断标准，具体操作以官方文档为准。
上传之前先做三件事
一、确认文档真的能被读进去
扫描版 PDF 是最大的坑。 它本质上是图片，没有文字层——传进去系统读到的是空的，你以为传成功了，实际什么都没有。
判断方法：用 PDF 阅读器打开，试着选中一段文字。选不中就是扫描件，需要先做 OCR。
表格是第二个坑。 一个二维表被拉平成一行文字之后，行列的对应关系就丢了。「张三的分机号是多少」这类问题，在丢了表头关系的文本里答不出来。表格不多的话，手工转成问答形式最可靠。
二、把过期内容清掉
这条最容易被跳过，后果也最严重。
新旧两版制度都在库里，系统会随机挑一个来答，而你无法预测它挑哪个。用户拿到三年前作废的规定——这比答「我不知道」危险得多，因为它看起来是对的。
上传前先确认哪些还有效。 这个整理工作看起来枯燥，但它决定了系统可不可信。
三、按用户的问法补充表述
内部文档写「差旅费报销标准」，用户问「出差住宿能报多少」。这两句话字面没有重叠，语义上也不算很近。
最省事的解法不是调参数，是改文档——直接把用户的常见问法写进去。一句话的事，比任何调优都见效快。
内容怎么组织
一个片段回答一个问题。 这是最核心的一条。
把十条政策塞进一大段，检索时相似度会被稀释，而且模型拿到的材料里混着九条无关内容，容易被带偏。拆成一问一答的形式，效果完全不同。
别让片段依赖上下文。 「上述三种情况均需提前申请」——这句话被单独检索出来时，没人知道「上述」指什么。写的时候要假设每一段都会被单独拿出来读。
朴素的验证标准：随便挑几个片段自己读一读。你自己读不懂的，模型也读不懂。 这个判断比任何参数都管用。
「按需调用」是什么意思
扣子的知识库可以配置成不同的调用方式，这里有个概念值得说清楚。
一种是每次对话都去查知识库。 好处是不会漏，坏处是用户随便聊一句「你好」也会触发检索，既浪费也可能把无关内容塞进上下文。
另一种是让模型自己判断要不要查。 也就是「按需调用」——模型觉得这个问题需要查资料才去查。好处是省，坏处是它可能判断失误：该查的时候没查，然后凭自己的知识编了一个答案。
怎么选：
- 如果你的 Bot 就是专门回答某个领域的问题（制度问答、产品咨询），倾向每次都查。用户来这里就是为了问这个，没必要让模型判断。
- 如果 Bot 承担多种任务（既闲聊又查资料又做别的），按需调用更合理。
- 越是不能答错的场景，越不要把「要不要查资料」这个决定交给模型。
建好之后怎么验
不要凭感觉说「好像还行」。做一个小测试集：
收集 20-30 个真实问题。 关键是真实——让业务同事写下他们平时怎么问，而不是你想象中他们会怎么问。这两者差别很大，我们每次做项目都会发现这一点。
人工标出每个问题的答案在哪个文档里。
逐个测，记录答对没有。 答错的分三类看：
- 根本没检索到正确文档 → 问题在知识库这一层，回去看切块和表述
- 检索到了但答错 → 问题在提示词，需要约束模型只依据资料回答
- 文档里压根没有答案 → 这不是系统问题，是知识缺口，得补资料
第三类比想象中多。 很多组织的真实情况是：一部分知识在文档里，一大部分在老员工脑子里。上知识库只是把这个问题暴露出来了。
答不上来时的兜底
这是客服类 Bot 必须处理的一环。
大模型有个天然倾向：它会尽力给出一个答案，而不是承认不知道。 在闲聊场景里这是优点，在知识库问答里是隐患。
在提示词里明确要求：只依据提供的资料回答，资料里没有的就说不知道，并告诉用户可以怎么办（转人工、留言、去哪查）。
只说「抱歉我不知道」的 Bot 体验比乱答还差——用户卡在对话框前面，不知道下一步该干什么。
但要清楚一点：提示词约束是概率性的，不是保证。 测试一百次都正常，第一百零一次遇到刁钻问法可能就绕过去了。越是不能出错的场景，越不能只靠提示词——需要在系统层面做机制。这类兜底机制的设计，我们写在用扣子搭客服机器人：答不上来的时候该怎么办。
多个知识库还是一个大库
文档一多就会遇到这个选择。
一个大库的问题：不同主题的内容混在一起，检索时容易串味。用户问考勤制度，检索出来的可能混着财务报销的条款——因为在向量空间里，两份都是「公司制度」，看起来挺像。
拆成多个库的好处：每个库主题集中，检索准确率明显更高。而且可以按库控制权限——人事制度库只给 HR 相关的 Bot 用。
拆的代价：要决定「这个问题该查哪个库」。如果让模型自己判断，它可能判断错；如果每个库都查，又回到了串味的问题。
实际建议：
- 主题差异大、用户群不同 → 拆开，并且拆成多个 Bot，每个 Bot 挂自己的库。用户从不同入口进来，根本不用判断查哪个。
- 主题相关、用户会交叉问 → 放一个库里，靠切块和表述优化解决串味。
最省事的往往是拆 Bot 而不是拆库——把判断的负担从模型转移到入口设计上。用户点「人事咨询」进来，就只会查到人事的内容，不存在判断失误。
什么时候扣子的知识库不够用
数据不能出网时。 扣子是托管平台，文档要传到平台上。这条是硬约束，绕不过去。需要数据留在内网的，得看 Dify、FastGPT 这类可自部署的——而且要注意，自部署也不等于不出网，如果配的是在线模型，数据照样发给模型厂商。
检索需要深度调优时。 平台提供的调整空间总是有限的。当你需要针对特定文档结构设计切块策略、需要换嵌入模型、需要混合检索时，就到了平台的边界。
判断标准见低代码 Agent 平台的能力边界。文档整理这件事本身的方法，见知识库项目七成工作量在文档。
需要把知识库能力接进自己系统的，也可以找我们聊聊。