夜雨聆风
最近整理一份 AI 产品课程转写时，我重新理解了企业知识库这件事。
很多团队做知识库的流程都很像。先把散落在公司里的 PDF、Word、PRD 和操作手册收集起来，批量上传到一个 RAG 工具，再接上大模型。看到聊天框能够回答问题，项目似乎就算完成了。
可真正交给同事使用以后，问题很快就会出现。明明文档里写过，AI 就是找不到；同一个问题换种说法，答案完全不同；几份资料互相冲突，它却很自然地拼成了一个新答案。
大家很容易把原因归到模型不够强、向量库不够先进，或者提示词写得不够长。
但更常见的问题发生在更前面。
知识库应该从问题开始，而不是从文档开始
假设公司已经有几千份需求文档。现在要把它们做成知识库，第一反应往往是研究怎么批量导入、每段切多少字、选哪个嵌入模型。
更应该先问的是，我们准备用这些文档解决什么问题？
用户是想查某个功能现在怎么用，还是想追溯它过去为什么这样设计？遇到两个版本的需求文档时，应该只返回最新版，还是把差异一起展示？答案里需要完整操作步骤，还是只需要定位原文？
这些问题不先想清楚，后面的切分、检索和提示词都没有稳定标准。
如果用户只想查一个确定答案，一条 FAQ 可以直接作为一个知识单元。如果用户想了解一个功能的完整业务逻辑，一段孤立的文字就不够，还要保留它属于哪个产品、哪个模块、哪一层功能，以及文档版本和更新时间。
所以，构建知识库的起点不是“我们有什么资料”，而是“用户会带着什么问题来”。
不同资料，不能使用同一把刀
知识库建设里最容易被低估的工作，是把原始资料加工成模型可以使用的结构。
PDF 可能有分栏、表格和图片，直接解析后会出现错乱换行。操作手册里的一张图片可能就是关键步骤，但模型拿到的只是没有含义的长链接。几十万字的文档如果按固定字数切分，还可能把问题留在上一段，把答案切到下一段。
这时即使检索到了“正确分段”，交给模型的仍然可能是半个答案。
更可靠的方法，是按照资料原本的语义结构处理。
FAQ 按“问题和答案”切分。产品手册按章节和完整操作步骤切分。PRD 按最小标题切分，但每一段都带上父级标题、产品模块、版本等信息。代码除了函数内容，还要保留调用关系和依赖关系，必要时再引入知识图谱。
固定长度可以作为超长内容的兜底，却不应该成为第一原则。每个分段最重要的标准，是脱离原文后仍然能够表达一件完整的事。
检索不是搜一下，而是一条处理链
资料处理完，才真正进入检索环节。
用户的问题可能只有一句“这个怎么开”。如果系统不知道用户从哪个页面进来、正在查看哪个产品，这句话几乎没有可检索的信息。因此在检索前，还需要补充入口、对象和历史对话，完成指代消解。
有些问题还需要查询改写。例如用户说“富贵竹叶子发黄”，知识库里写的可能是“水培植物营养不足”。系统可以提取实体，补充上位词和相近表达，再去检索。
但查询改写不是越多越好。原问题本来可以命中三个准确结果，扩写成十几个方向后，反而可能带回来一堆似是而非的内容。
检索方式也要跟问题匹配。型号、编号和公司内部专有名词，更适合关键词检索；口语化长句、同义表达和跨语言问题，更适合语义检索。企业场景通常需要把两者组合起来，再对候选内容重新排序。
召回结果也不是越多越安全。给模型十段资料，其中只有三段相关，剩下七段就可能成为干扰。真正需要调试的是召回数量、匹配阈值、重排策略，以及最后到底把哪几段交给模型。
找到资料，也不代表模型会正确回答
很多知识库做到检索这一步就停了。系统找到几段文字，把它们和用户问题一起发给大模型，然后等待一个看起来通顺的答案。
这里还有最后一道护栏。
如果没有召回结果，模型应该怎么回答？如果五段资料里只有两段相关，能不能忽略其他内容？如果两个版本互相冲突，是自行判断，还是分别展示？如果召回的步骤只有前半段，能不能继续补写？
这些情况都不应该留给模型临场发挥。
在知识库问答里，模型更适合扮演“资料编辑者”，而不是无所不知的回答者。系统需要明确告诉它，只使用相关资料，没有答案就说明暂时无法确认；资料冲突时保留差异；内容残缺时不要擅自补全；图片和必要链接需要原样保留。
这样做的目的不是写一份更长的提示词，而是给模型准备明确的工作边界和失败出口。
真正要优化的是整条链路
回头看，一个知识库最终是否好用，至少受这些环节影响。
用户问题有没有补全，原始资料是否干净，分段是否保持语义完整，检索方式是否匹配，候选结果有没有重排，最终模型是否受到正确约束。
任何一个环节出错，都可能表现为“AI 回答不准”。如果只盯着模型升级，很容易在错误的位置反复投入。
我现在更愿意把企业知识库理解成一条上下文生产线。
用户提出一个问题，系统负责把模糊问题补全，从干净的资料中找到候选内容，筛掉干扰信息，再把少量、完整、可信的上下文交给模型。模型完成的，只是最后一步编辑和表达。
如果公司准备开始做知识库，可以先别急着问用哪个工具。
先找出十个真实、高频、值得回答的问题，用现有资料跑完整条链路。等这十个问题能够稳定答对，再逐步扩大资料范围。
这条路看起来没有“一键导入几千份文档”那么热闹，却更接近一个真正能被使用的产品。
