为什么很多知识库项目只停在演示阶段
过去一年，很多团队都尝试把企业文档、产品手册、售后记录和内部制度接入大模型。第一次演示通常很惊艳：上传几份 PDF，提一个问题，模型很快给出一段像样的回答。但真正投入业务时，问题会马上出现。回答依据不稳定、过期文档被引用、权限边界不清晰、长文档召回片段不完整，都会让用户从“好像很智能”变成“不敢相信它”。
因此，企业知识库不是简单把文档丢进向量库，而是一套围绕数据、检索、生成、权限和评估的工程系统。RAG 的目标也不是让模型替人编答案，而是让模型在可靠资料范围内组织答案，并把引用来源交代清楚。
第一步：先把数据治理做好
知识库质量的上限，往往由原始数据决定。文档入库前要先处理三个问题：格式是否统一，内容是否有效，版本是否可追踪。比如同一份产品说明书可能同时存在 Word、PDF、网页和历史备份，如果不做版本管理，模型很容易引用旧版本。再比如会议纪要、售后工单、FAQ 中常有重复内容，如果不去重，召回结果会被相似片段挤占。
比较稳妥的做法是给每份文档建立元数据，包括来源、业务线、更新时间、负责人、可见范围和文档状态。后续检索时先按元数据过滤，再做语义召回，这比单纯依赖向量相似度更可靠。
第二步：切分策略比模型参数更重要
很多 RAG 效果不好，不是模型差，而是切分太粗或太碎。切得太粗，召回片段里噪声太多；切得太碎，上下文断裂，模型看不到完整逻辑。企业文档适合按标题层级、段落语义和表格结构混合切分，而不是固定每 500 字一刀。
对于政策制度类文档，可以保留章节标题和条款编号；对于接口文档，要把请求参数、返回字段和示例放在同一块里；对于 FAQ，则可以用问题和答案作为天然切分单元。切分后的片段还应保留父级标题，这样模型回答时能知道内容属于哪个产品、哪个版本、哪个场景。
第三步：检索要做组合拳
纯向量检索适合理解语义，但不擅长处理精确词、型号、编号和专有名词。企业场景里，用户经常问“某个 SKU 怎么配置”“错误码 E103 是什么”“合同模板第 8 条怎么解释”。这类问题如果只靠向量相似度，很容易召回相近但不准确的内容。
更实用的方案是混合检索：关键词检索保证精确匹配，向量检索负责语义扩展，再用重排序模型把候选片段重新打分。最后还可以根据文档时间、权限、业务线做加权，让最新、最相关、最可信的内容排在前面。
第四步：回答必须带引用和边界
企业知识库最重要的是可信度。回答里最好展示引用来源，例如文档名称、章节、更新时间和原文片段。遇到资料不足时，模型应该明确说“当前知识库没有找到依据”，而不是补充看似合理的猜测。
提示词也要围绕这个原则设计：只基于检索内容回答；无法确认时说明缺失信息；涉及流程、价格、合规条款时必须引用来源；不要把多个文档的冲突内容强行合并。这样做会让回答显得保守一些，但更符合企业使用场景。
第五步：用评估集持续优化
RAG 系统一上线就结束，是最常见的误区。真正稳定的知识库需要一套评估集，包括高频问题、边界问题、权限问题、旧版本问题和长文档问题。每次调整切分、检索、重排序或提示词后，都用同一批问题回归测试，看准确率、引用命中率和拒答质量是否提升。
同时，前端要允许用户反馈“有帮助”“没解决”“引用错误”。这些反馈不是摆设，而是后续补文档、调权重、修切分规则的重要依据。
总结
企业知识库接入大模型，难点不在于搭一个聊天框，而在于把信息变成可检索、可追踪、可验证的资产。一个可落地的 RAG 系统，应该从数据治理开始，用合理切分保证上下文完整，用混合检索提升命中率，用引用机制建立信任，再通过评估集持续迭代。做到这些，知识库才会从一次漂亮的演示，变成真正能服务员工、客户和业务流程的生产工具。