同名文件不是同一份知识
企业里常见“销售报价规范”“客户服务制度”“费用报销办法”这样的文件名，不同部门、不同地区和不同年份都可能使用。员工查文件时会看目录和上下文，知识库检索如果只有标题和正文，很容易把几份相似内容一起召回，再拼成一条谁都没批准过的答案。
因此，知识库的第一步不是把所有文件上传，而是给文件补身份。它属于哪个部门，覆盖什么业务，什么时候生效，是否仍然有效，替代了哪个版本，哪些人可以使用，这些信息比“文件里出现多少关键词”更能决定答案是否适用。
文档入库前先补一张身份卡
每份资料可以配一张简单身份卡，字段包括正式名称、归属部门、适用地区或业务线、发布日期、生效日期、失效日期、版本号、维护人、密级和状态。对于临时通知、培训材料和正式制度，也要区分资料类型。不同类型可以提供参考，但不能用同样的权威级别回答。
字段不必一次设计得很复杂，先解决最容易错的几件事：谁发布的、适用于谁、现在是否生效、如果和另一份资料冲突听谁的。对无法确认的资料，不要直接进入高优先级检索范围，可以先标记待核对。
- 同名文件必须有版本号、归属部门或业务范围。
- 明确正式制度、草稿、培训材料和历史文件的状态。
- 为每类资料指定维护人和冲突处理规则。
版本状态要能影响检索，而不是只显示在列表里
如果失效文件仍然参与召回，页面上写“已过期”并不能防止 AI 引用。检索层要根据状态和生效日期过滤，或者在答案生成前明确告诉系统哪些版本优先、哪些只能作为历史参考。技术实现可以不同，但业务规则必须被真正执行，而不是停留在元数据表。
同一制度发生局部修改时，也要决定是替换整份文件，还是保留主文件并关联修订通知。两种方式都可以，但要让使用者知道最终应以哪份为准。知识库的目标不是保存最多资料，而是在需要时找出当前有效、范围匹配的资料。
答案要把适用范围说出来
知识助手回答制度问题时，不能只给结论，还应在必要时带出适用部门、地区、版本或生效时间。员工问“这个流程怎么走”，如果系统只说步骤，却不说明这是某业务线的版本，最容易造成跨部门误用。引用来源时也要显示文档名称和版本，方便员工核对。
当多个文件都可能适用时，系统不要强行合并。可以列出需要确认的差异，并把问题转给制度维护人。宁可给出“请确认所属部门和生效地区”，也不要生成一段看起来完整但没有适用范围的混合流程。
验收要专门测试同名、旧版和跨部门问题
测试集不能只用标准问题，还要加入同名文件、旧版本、地区差异、临时通知覆盖正式制度和资料缺少归属等场景。检查系统是否选对文件，是否解释适用范围，是否在无法判断时提出必要追问，是否能提供原始来源。
资料发生变更后，再做一次删除或停用验证，确认旧文件不会继续被当作当前答案。文档身份和元数据是知识库的基础工程，做好之后，模型能力才有可靠的资料边界。
如果企业暂时没有完整的文档管理系统，也可以先用一份受控清单管理身份字段。关键是清单和实际检索规则要保持同步，不能只在入库时填一次。每次制度变更都指定一个核对动作，确认新旧版本、引用链接和知识库状态已经同时更新。
文档身份还应进入日常上传流程。员工提交资料时先选择部门、类型和状态，缺少关键字段就进入待整理队列，而不是直接成为高优先级知识。这样知识库质量不会完全依赖后期人工清理，也能让资料维护人更早发现重复和冲突。
对于扫描件、表格和附件，也要保留原始文件与处理后的文本之间的对应关系。文字识别或格式转换发生变化时，维护人可以回到原文件核对，而不是只相信一段已经被系统抽取的文本。来源链条清楚，答错后才有可能快速定位是资料本身、抽取过程还是检索规则出了问题。
要点总结
- 不一定，但必须补充归属、版本、适用范围和状态，让系统能区分它们。
- 可以作为历史参考，但要明确标记，避免参与当前制度回答。
- 应由资料归属部门指定维护人，技术团队负责执行检索规则。
参考来源说明
本文围绕“知识库里有三份同名制度，AI 为什么答错：先补文档身份和版本元数据”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。