RAG让大模型在回答前检索企业资料，已经成为知识问答的常见方案。最初的原型往往很顺利：准备一批文档，完成切分和索引，再接上模型，就能得到带有业务信息的答案。
真正进入使用后，问题才慢慢出现。旧制度和新制度同时被检索，部门内部材料越过权限边界，用户换一种说法就找不到同一份内容。这些情况通常不是靠更换模型就能解决。
文档边界比文档数量重要
知识库不是资料仓库的简单复制。每份文档需要明确适用对象、业务范围、有效时间和优先级。缺少这些元数据时，检索系统只能根据文字相似度选择内容，很难判断哪一条规则更可信。
相互冲突的资料不应悄悄共存。系统可以保留历史版本，但对当前问答只开放有效版本，并在答案中给出来源和更新时间。
知识库的可靠性，首先来自内容管理，其次才是检索技巧。
更新责任必须能找到人
知识过期并不是技术异常，而是组织日常变化的结果。产品升级、流程调整、人员变动都会让原有资料失效。关键内容应有明确责任人和复核周期，修改后自动触发重新索引。
用户发现错误时，也要有短路径反馈到内容维护者。只给答案点“有用”或“没用”，无法说明是检索错了、资料旧了，还是问题本身含糊。
评估要来自真实提问
项目团队自拟的问题通常贴近文档标题，检索自然容易成功。真实用户会使用简称、口语和不完整描述，还会把多个意图写在一句话里。评估集需要持续收集这些表达，同时去除敏感信息。
除了答案是否正确，还要检查引用是否支持结论、无资料时能否明确拒答、权限变更是否即时生效。RAG工程化并不神秘，它是把内容、检索和反馈当成一个长期运营的系统。