RAG 知识库怎么搭：文档、切分、检索和回答复核

RAG 知识库的核心不是“把文档丢给 AI”，而是让模型在回答前先检索相关资料，再基于资料生成回答。它适合 FAQ、内部文档、产品说明、客户支持、学习资料和项目 SOP。但要做好 RAG，需要整理文档、切分内容、建立索引、控制权限、评测结果和人工复核。

这篇是草稿，发布前需要核对具体工具。向量库基础可以看 向量数据库怎么选，Agent 部署可以看 Agent 部署怎么做。

适合谁

适合想做“问文档”的人。比如把公司 FAQ、产品手册、课程资料、客服文档、项目记录变成可查询知识库。

也适合接 AI 知识库需求的新手。客户说“搭一个知识库”，你要确认文档来源、权限、更新频率、回答格式和验收标准。

不适合谁

不适合文档本身混乱、过期、互相矛盾，却希望 AI 自动解决的人。RAG 只能帮你检索和生成，不能替你整理组织知识。

如果文档包含机密、客户资料、合同、账号信息或个人隐私，必须先做权限和脱敏设计。

第一步：整理资料

先收集知识库要包含哪些资料：FAQ、PDF、网页、Notion、飞书文档、客服记录、产品说明。每份资料都要有来源、负责人和更新时间。

过期文档不要直接塞进去。模型检索到旧资料后，可能会给出错误回答。

第二步：文档切分

RAG 通常会把长文档切成较小片段，再做检索。切得太大，检索不准；切得太小，缺少上下文。

新手可以先按标题、段落和语义块切分。不要只按固定字数切，因为一个完整流程被切断后，回答质量会下降。

第三步：向量化和检索

文档片段会通过 embedding 模型转成向量，再存入向量数据库或支持向量检索的存储系统。用户提问时，系统检索最相关片段，再交给大模型生成答案。

检索不是越多越好。返回太多片段会增加成本，也可能让模型抓不住重点。要测试 top k、相似度阈值和过滤条件。

第四步：引用和来源

知识库回答最好带来源，让用户知道答案基于哪份文档。没有来源的回答，很难被信任，也不方便纠错。

引用可以是文档标题、章节、链接、更新时间或片段编号。内部系统尤其需要这个能力。

来源也能帮助维护。用户发现答案不对时，可以回到具体文档修改，而不是只调提示词。很多 RAG 项目真正的问题不在模型，而在文档没人负责、资料长期不更新、相互矛盾的说明没有清理。

第五步：评测和更新

上线前准备一组问题：常见问题、边界问题、过期资料问题、权限问题、找不到答案的问题。看系统是否能回答、是否会拒绝、是否给来源。

知识库不是一次性项目。文档更新后，索引也要更新。客户要知道谁负责维护。

评测时可以给每个问题打三类标签：是否找到了正确资料，回答是否忠于资料，用户是否能看懂。只找到资料但回答很差，说明生成提示词需要改；回答流畅但来源不对，说明检索或权限过滤需要改。把问题拆开，优化才有方向。

还要专门测试“找不到答案”的情况。一个靠谱的知识库不应该在没有资料时硬编答案，而应该说明当前资料里没有找到依据，并提示用户换个问法、补充文档或联系人工。能正确拒绝，比每次都回答更重要。

风险提醒

RAG 最大风险是资料不可靠。模型看起来引用了资料，但资料本身可能过期、错误或不适合当前用户权限。

另一个风险是权限泄漏。不同用户不一定能看同一批文档，检索层必须考虑权限过滤。

具体步骤

第一步，列出知识库范围、文档来源和负责人。

第二步，清理过期、重复和敏感资料。

第三步，设计切分规则、向量化方案和检索参数。

第四步，要求回答带来源，并准备测试问题。

第五步，写上线和维护清单。需要模板或人工协助设计，可以从 工具导航 进入。

免责声明

本文是 RAG 知识库入门草稿，不构成具体架构或合规建议。正式发布前需要人工核对模型、向量库、文档工具和权限方案。涉及企业资料和客户数据时，请由专业人员复核。