完整版本：搭建 AI 知识库前，先完成这 7 步需求分析
目录
一、AI 知识库解决的是什么问题？
二、第一步：选择一个值得做的场景
三、第二步：明确用户、问题和边界
四、第三步：盘点知识来源
1. 资料是否有效
2. 是否存在冲突
3. 是否有负责人
4. 是否涉及敏感信息
5. 是否允许不同用户访问
五、第四步：建立一组真实问题
六、第五步：设计文档处理方式
文档解析
文本切块
添加元数据
七、第六步：设计回答流程
八、第七步：确定评估指标和业务价值
检索指标
回答指标
使用指标
业务指标
九、知识库的三类核心价值
1. 让 AI 回答有依据
2. 让知识能够持续复用
3. 降低重复查找和咨询成本
十、最小可行知识库怎么做？
十一、常见误区
误区一：先把所有文档上传再说
误区二：只测试几个演示问题
误区三：只做向量检索
误区四：认为知识库能彻底消除幻觉
误区五：上线后不再维护
总结
很多团队决定做 AI 知识库后，第一反应是：
选哪个大模型？
用哪个向量数据库？
文档应该切成多大？
这些问题当然重要，但不是第一步。
真正应该先回答的是：
谁会使用这个知识库？
他们要解决什么问题？
哪些资料可以作为答案依据？
怎样才算回答正确？
知识库上线后能产生什么业务价值？
如果这些问题没有想清楚，即使技术链路全部跑通，最后也可能只是做出一个“可以聊天，但没人愿意用”的系统。
一、AI 知识库解决的是什么问题？
企业内部通常不缺文档，真正缺少的是快速、准确地使用文档的能力。
常见情况包括：
文档散落在飞书、Wiki、网盘和聊天记录中；
同一个问题在不同文档中存在多个版本；
员工知道答案存在，但不知道应该搜索什么关键词；
新员工频繁询问重复问题；
客服、研发和运维需要反复查找处理流程；
大模型不了解企业内部资料，只能根据通用知识回答。
AI 知识库的作用，是把这些分散的资料整理成可以检索、引用和持续更新的知识来源。
当用户提问时，系统先查找相关资料，再让大模型根据资料生成答案，并尽量给出引用来源。
它的目标不是“把所有文件都上传”，而是：
让特定用户在特定场景下，更快地获得有依据的答案。
二、第一步：选择一个值得做的场景
知识库不适合从“全公司所有文档”开始。
更合理的做法，是先选择一个范围明确、问题高频、资料相对完整的场景。
可以从四个维度判断：
| 判断维度 | 需要回答的问题 |
|---|---|
| 使用频率 | 这个问题每周会出现多少次？ |
| 时间成本 | 当前每次查找或咨询需要多久？ |
| 知识质量 | 是否存在相对可靠的标准文档？ |
| 错误成本 | 回答错误会带来多大影响？ |
适合作为第一个知识库的场景包括：
新员工制度问答；
产品使用手册问答；
内部 API 文档查询；
常见故障处理；
客服标准问答；
销售产品资料查询。
不适合作为第一个场景的情况包括：
问题一年只出现几次；
答案主要依赖个人判断；
资料严重缺失或互相矛盾；
每次处理都必须访问实时业务系统；
回答错误可能直接导致严重安全事故。
例如，“公司报销制度问答”通常比“自动诊断所有线上故障”更适合作为第一个知识库项目。
三、第二步：明确用户、问题和边界
场景确定后，需要写清楚谁会用、问什么、系统不能做什么。
可以填写下面这张需求卡：
知识库名称： 目标用户： 主要使用场景： 用户最常问的问题： 答案来自哪些资料： 系统可以回答什么： 系统不能回答什么： 资料不足时应该怎么处理： 是否必须显示引用来源：
例如：
知识库名称：研发故障处理知识库 目标用户：开发工程师和值班人员 主要场景：线上出现告警后查询处理方法 常见问题： 1. API返回401应该如何处理？ 2. Redis连接超时应该检查什么？ 3. 消息积压时应该如何排查？ 答案来源： 故障处理手册、历史复盘报告、值班记录 可以回答： 已有文档中明确记录的排查步骤 不能回答： 直接修改生产数据、自动执行高风险命令 资料不足时： 明确提示“现有资料中没有找到可靠答案”，并建议联系负责人 引用要求： 必须显示文档名称和更新时间
这一步非常重要。
如果不规定边界，知识库很容易把“没找到资料”变成“根据经验编一个答案”。
四、第三步：盘点知识来源
知识库的效果上限，首先取决于原始资料，而不是模型。
建议建立一份资料清单：
| 资料名称 | 存储位置 | 负责人 | 更新时间 | 可信度 | 权限 |
|---|---|---|---|---|---|
| 故障处理手册 | 内部 Wiki | 运维组 | 2026-07 | 高 | 研发可见 |
| 历史工单 | 工单系统 | 客服组 | 持续更新 | 中 | 客服可见 |
| 聊天记录 | 群聊 | 无明确负责人 | 不确定 | 低 | 不建议直接入库 |
盘点时重点检查五件事。
1. 资料是否有效
过期流程、废弃接口和旧制度不能与新版本同时作为答案依据。
2. 是否存在冲突
如果两份文档对同一问题给出不同答案，需要先确定哪个版本有效。
3. 是否有负责人
每类知识都应该有维护人。没有负责人，知识库很快就会变成过期资料仓库。
4. 是否涉及敏感信息
客户资料、员工隐私、密钥、生产账号等内容不能不加处理地进入知识库。
5. 是否允许不同用户访问
权限不能只在聊天页面控制，还必须在检索阶段进行过滤。
普通员工不应该检索到管理层文档，外部客户也不能看到内部处理记录。
五、第四步：建立一组真实问题
很多团队先上传文档，最后才开始测试。
更好的顺序是：在开发知识库之前，先收集一批真实问题。
可以从以下地方整理：
员工历史咨询；
客服工单；
搜索记录；
新人培训问题；
运维告警记录；
群聊中的重复提问。
第一版可以准备 30～100 个问题，每个问题记录：
问题： 标准答案要点： 答案来源： 允许引用的文档： 不应该返回的内容： 资料不足时是否应该拒答：
例如：
问题：API返回401应该怎么办？ 标准答案要点： 1. 检查Token是否过期 2. 调用刷新接口获取新Token 3. 刷新失败时重新登录 答案来源： 《API鉴权手册》第3章 不应该返回： 生产环境账号、密钥或未经确认的接口地址
这组问题就是知识库的最小评测集。
以后更换 Embedding 模型、调整切块方式或者修改提示词，都应该重新运行这组问题，而不是只挑一两个成功案例展示。
六、第五步：设计文档处理方式
需求和资料确定后，才进入文档处理阶段。
一个基本流程是：
文档采集 → 文档解析 → 清洗与去重 → 文本切块 → 生成向量 → 保存向量和元数据 → 建立检索索引
文档解析
系统需要从 PDF、Word、网页或 Markdown 中提取正文。
扫描版 PDF 还需要 OCR。
解析完成后，要检查：
标题是否保留；
表格是否错位；
代码块是否完整；
页眉页脚是否被当成正文；
图片中的关键信息是否丢失。
文本切块
不要简单按照固定字符数机械切分。
一个文本块最好能够独立表达完整知识。
例如下面这段内容不应该被拆开：
问题：API返回401。 原因：Token可能已经过期。 处理方法：调用刷新接口获取新Token。
如果只检索到“调用刷新接口”，却没有问题背景，模型可能无法正确使用。
切块时可以优先按照：
标题；
章节；
段落；
问答对；
操作步骤；
代码或表格边界。
进行拆分。
添加元数据
每个文本块至少应该保存：
文档名称；
章节标题；
原文地址；
更新时间；
文档版本；
负责人；
部门；
访问权限；
内容类型。
元数据不仅用于展示引用，也用于权限过滤、版本控制和限定搜索范围。
七、第六步：设计回答流程
知识库不是把文档存入向量数据库后就结束了。
一次完整问答通常包括：
用户提问 → 判断问题类型 → 检索相关资料 → 关键词与向量结果融合 → 对候选资料重新排序 → 根据权限过滤 → 大模型生成答案 → 返回引用来源
生产环境还应明确以下规则：
只能根据检索资料回答；
资料不足时必须拒答；
不能把猜测写成确定事实；
必须显示来源和更新时间；
多个资料互相冲突时，应该提示冲突；
高风险操作必须要求人工确认。
可以使用这样的回答提示词：
请只根据参考资料回答用户问题。 要求： 1. 不得补充参考资料中不存在的事实。 2. 如果资料不足，请回答“现有知识库中没有找到可靠答案”。 3. 如果资料存在冲突，请分别说明不同版本。 4. 回答后列出引用文档名称。 5. 涉及删除数据、修改权限或生产操作时，只提供检查建议，不直接生成执行指令。
八、第七步：确定评估指标和业务价值
知识库上线后，不能只看“回答听起来不错”。
至少应该评估四类指标。
检索指标
正确资料是否进入前 k 条结果；
第一条结果是否相关；
权限过滤是否正确；
过期资料是否仍被召回。
回答指标
答案是否覆盖关键要点；
是否忠于原文；
是否正确引用来源；
资料不足时是否拒答；
是否泄露无权访问的信息。
使用指标
有多少目标用户真正使用；
用户是否继续追问；
用户是否点击引用来源；
问题是否最终解决。
业务指标
平均查找时间是否降低；
重复咨询数量是否减少；
客服平均处理时长是否下降；
新人独立解决问题的时间是否缩短；
人工转接率是否下降。
例如，可以设定这样的 MVP 目标：
目标用户：20名值班开发人员 评测问题：50个真实故障问题 目标： 80%以上的问题能召回正确文档 回答必须附带来源 高风险问题必须拒绝自动执行 平均资料查找时间从15分钟降低到3分钟
有了明确指标，才能判断知识库是否真的创造了价值。
九、知识库的三类核心价值
1. 让 AI 回答有依据
知识库为 RAG 提供可检索资料，使大模型可以根据企业内部文档回答，并展示来源。
它可以降低幻觉风险，但不能完全消除幻觉，因此仍然需要评测、权限和拒答机制。
2. 让知识能够持续复用
一份经过清洗、分类和权限处理的资料，可以被多个应用使用，例如：
内部问答助手；
客服助手；
运维助手；
销售资料助手；
员工培训助手。
但“一次入库”并不代表永远不需要维护。文档更新后，知识库也必须同步更新。
3. 降低重复查找和咨询成本
知识库可以减少查找文档、重复回答和人工转接的时间。
它更适合处理高频、标准化、有可靠资料依据的问题，而不是替代所有专家判断。
十、最小可行知识库怎么做？
第一版不要追求覆盖所有部门。
可以按照下面的范围启动：
一个明确场景 一类目标用户 一批可靠资料 30～100个真实问题 一个检索入口 一套引用和拒答规则 一组可以量化的指标
推荐实施顺序：
选择一个高频场景；
收集真实问题；
整理对应文档；
清理过期和冲突内容；
设计切块和元数据；
建立检索与回答流程；
使用真实问题评测；
小范围邀请用户试用；
根据失败案例持续优化；
证明价值后再扩大范围。
十一、常见误区
误区一：先把所有文档上传再说
文档越多不一定越好。
大量过期、重复和无关资料会降低检索质量。
误区二：只测试几个演示问题
演示问题通常经过精心挑选，不能代表真实使用效果。
应该使用历史咨询和真实工单建立评测集。
误区三：只做向量检索
产品编号、错误码、接口名和专业缩写，可能更适合关键词检索。
实际项目通常需要关键词与向量相结合。
误区四：认为知识库能彻底消除幻觉
知识库只能为模型提供参考资料。
如果检索结果错误、资料过期或者提示词约束不足，模型仍然可能生成错误答案。
误区五：上线后不再维护
知识库不是一次性项目。
文档更新、权限变化和业务流程调整后，都需要重新处理相应数据。
总结
搭建 AI 知识库的第一步，不是选择模型或者向量数据库，而是回答下面几个问题：
谁会使用？
解决什么问题？
答案来自哪里？
哪些内容不能回答？
怎样判断答案正确？
资料由谁维护？
上线后创造什么价值？
先完成场景、资料、权限和评测设计，再进入切块、向量化和数据库选型，知识库才更可能从“可以演示”变成“真正有人使用”。