RAG 不是把文档塞进向量库

很多团队做 RAG 的第一步是选向量数据库，第二步是把 PDF、网页和知识库全部切块入库，然后期待模型能稳定回答。真正上线后才发现：答案找不到重点、引用不准确、同一个问题多次回答不一致、过期文档和新文档混在一起。

RAG 的核心不是“有没有向量库”，而是知识进入、召回、排序、回答和评估这一整条链路是否可控。

文档切分决定上限

切分太大，召回结果里包含太多无关信息；切分太小，关键上下文被拆散。更好的方式是按文档结构切分：标题、段落、表格、代码块、FAQ 分开处理。技术文档尤其要保留标题层级，否则模型不知道某段内容属于哪个功能。

切分后还要保留元数据，例如来源、更新时间、产品版本、权限范围和章节路径。没有元数据，后续很难过滤过期内容或做引用展示。

召回要评估，不要凭感觉

RAG 系统至少要有一批测试问题。每个问题标注期望召回的文档或答案要点，然后看系统是否能把正确片段排在前面。只看最终回答，很难判断问题出在召回、重排还是生成。

常见做法是先看 top-k 召回命中率，再看重排后的前几条是否包含答案。评估集不需要一开始很大，几十个真实问题就能暴露很多问题。

答案边界必须明确

模型应该基于召回内容回答，而不是自由发挥。产品文档、合同、售后政策、价格规则这类场景尤其要克制。找不到依据时，应该回答“当前资料没有明确说明”，而不是编一个看似合理的答案。

前端也要展示引用来源，让用户能回到原文确认。没有引用的 RAG，更像聊天机器人；有引用和边界的 RAG，才适合知识查询。

更新和权限不要后补

文档会过期，权限也会变化。入库时要记录版本和权限范围。删除或更新文档后，要确保索引同步更新。否则用户可能问到已经废弃的政策，或者看到不该看到的内部资料。

总结

RAG 的难点不在“接一个向量库”，而在文档治理和质量评估。切分合理、召回可测、答案有边界、引用可追溯、权限可控制，这些做好后，RAG 才能从演示变成可用系统。