这页先把判断说清楚，再说明什么时候适用、如何开始，以及哪些地方仍然需要人的专业责任。
两者不是同一个东西
知识库更像资料的组织和管理方式：有哪些文件、谁能看、哪个版本有效、它们属于什么项目或主题。RAG是一条运行机制：收到问题后，系统检索相关内容，把结果交给模型，再生成回答。
RAG 能不能工作，取决于它是否拿到了适用、完整、被允许使用的材料，以及回答能否回到原文核对。
资料都在，仍然答错的五个原因
- 找错资料：关键词相似，但业务对象、项目或适用条件不同。
- 版本冲突：旧方案、临时例外和最新确认没有明确优先级。
- 关系丢失：相关事实分散在多个文件里，检索到了片段却没有把关系带回来。
- 权限不清：系统能搜到不应被当前人看到的内容，或为了安全漏掉了必要材料。
- 没有证据回链：回答写得流畅，却无法指出关键说法来自哪里。
先做什么，而不是先换模型
- 给资料增加项目、主题、时间、版本和适用范围。
- 把最新有效版本、历史版本和例外规则分开处理。
- 让关键回答带回来源位置，并把找不到依据的部分标为待确认。
- 用真实问题测试：不仅测试“能不能答”，还测试“能不能拒答、能不能说出依据”。
什么时候不必先建 RAG
如果资料很少、任务只发生一次，或者一条清楚的指令和人工查阅就能完成，不必为了技术完整而先建系统。值得投入的通常是那些反复查找、经常交接、版本容易混淆、结果需要留痕的工作。
一份可交付的准备稿应该长什么样
它不只给结论，还应说明使用了哪些资料、哪些说法有直接依据、哪些地方存在缺口、哪些判断需要负责人确认。专业工作里，“不知道”说得清楚，往往比一个没有依据的完整答案更有价值。