很多 RAG 项目一开始看起来很简单：把文档向量化，检索相似片段，再交给模型回答。但真正进入业务场景后，问题会很快变复杂：文档版本不一致、答案引用不准确、召回片段太碎、用户问题跨多个知识域、模型无法判断资料是否过期。
RAG 的目标不是“搜到相关文档”，而是稳定地产生可追溯、可验证、可维护的答案。
1. 文档切分决定信息边界
切分粒度过小，模型拿不到完整语义；切分过大，检索噪声会增多。更可靠的做法是按文档结构切分：标题、章节、表格、FAQ、代码块都应该保留自己的上下文。对制度、合同、手册这类文本，还要把版本号、生效时间、适用对象作为元数据写入索引。
2. 召回不是一次搜索
生产级检索通常需要混合策略：关键词检索处理专有名词和编号，向量检索处理语义表达，过滤条件处理权限和业务范围。初次召回后，再用重排模型或规则把真正可回答问题的片段放到前面。
3. 上下文组装要有预算意识
上下文窗口不是越满越好。应该优先放入直接证据、定义性材料、约束条款和最新版本，避免把相似但无关的历史文档塞进去。对复杂问题，可以先让模型生成检索计划，再分步查询不同资料源。
4. 答案需要引用和不确定性表达
RAG 系统必须告诉用户答案来自哪里。引用不只是体验优化，也是错误排查入口。如果检索结果不足，模型应该明确说明缺少依据，而不是用语言流畅度掩盖证据不足。
5. 权限过滤要发生在检索前
不要把用户无权访问的内容交给模型后再要求模型“不要泄露”。权限过滤应当作为数据查询层的硬约束，并在日志中记录检索范围、命中文档和答案引用。
6. 评估要覆盖召回和生成
只看最终答案评分不够。你需要分别评估召回是否命中、排序是否合理、答案是否忠于资料、引用是否准确、拒答是否恰当。这样才能知道系统问题出在索引、检索还是生成阶段。
7. 更新机制决定长期质量
知识库不是一次性导入。文档新增、删除、改版、撤回都要触发索引更新，并保留可回滚记录。对高风险领域，建议建立“待确认答案”队列，让业务专家持续校准样例集。
常见误区
第一个误区是只优化向量库参数，却不清理原始文档。文档标题混乱、版本冲突、图片表格丢失，都会让检索质量下降。第二个误区是把引用交给模型自由生成，结果看似有来源，实际引用不到对应段落。第三个误区是只在上线前评估一次，后续文档变化后没有回归。
一个更稳的迭代节奏
建议先选 30-50 个真实问题做基准集，手工标注标准答案和必要证据；再调整切分、召回和重排；最后观察答案忠实度与引用准确率。每次只改一个环节，才能知道质量变化来自哪里。
落地清单
- 每个片段带上来源、版本、时间、权限和业务标签。
- 检索链路保留可观测日志，能复盘每个答案。
- 建立固定问题集，覆盖高频、边界和拒答场景。
- 把引用准确率和用户反馈作为长期运营指标。
- 对过期文档、重复文档和冲突文档建立清理规则。
- 为无依据回答、证据不足和权限不足分别设计拒答模板。