RAG 很容易被讲成“把文档塞给大模型”。但从后端视角看，它更像一条检索系统：文档如何入库、如何切分、如何召回、如何过滤、如何拼上下文、如何回溯来源。
我的判断： RAG 的价值不在于回答更长，而在于回答能追溯、能控权、能持续更新。没有引用和权限边界的 RAG，在企业系统里很难让人放心使用。
文档切分决定召回质量
切得太大，召回内容噪声高；切得太小，语义不完整。技术文档可以按标题层级切，接口文档可以按接口粒度切，FAQ 可以按问答对切。
向量检索不是唯一检索
实际系统里，向量检索常常要和关键词检索、标签过滤、时间过滤、权限过滤结合。只靠相似度分数，很容易把不该看的内容召回。
引用来源比回答更重要
企业知识库里的 AI 回答，最好能给出引用段落或文档链接。没有来源的回答，用户很难判断可信度。
权限要进检索阶段
不要等模型回答完再做权限过滤。权限应该在召回前或召回时生效，避免敏感内容进入上下文。
实际场景：把内部知识库接给后端助手
如果要给 Java 后端团队做一个研发助手，RAG 最适合解决的问题不是“让模型更聪明”，而是让模型能基于当前项目的真实资料回答。比如接口文档、数据库字段说明、媒体平台对接文档、BI 指标口径、错误码说明、上线流程、故障复盘，这些信息都在团队内部，而且会持续变化。直接靠模型训练知识肯定不够。
文档入库前要先定义粒度。接口文档适合按接口切分，因为每个接口都有 URL、入参、出参、错误码和权限；故障复盘适合按问题背景、影响范围、原因、处理过程、后续改进切分；业务指标文档适合按指标口径切分。切分不是越小越好，太小会丢上下文，太大又会把无关内容召回。
检索阶段不能只靠向量相似度。比如用户问“批创提交失败怎么查”，可能需要同时召回批创接口文档、任务表字段、媒体错误码和补偿流程。这里可以组合关键词检索、标签过滤和向量检索：关键词保证命中专有名词，标签过滤保证只看广告平台资料，向量检索补充语义相近内容。后端要把这些策略封装起来，而不是把一堆文档直接塞给模型。
权限是 RAG 很容易出问题的地方。内部文档可能包含媒体账号、项目 ID、业务数据、客户信息或接口密钥说明。检索时就应该按用户权限过滤文档集合，不能先召回再让模型“不要说”。一旦敏感内容进入 prompt，就已经存在泄露风险。对企业系统来说，RAG 的权限控制应该和普通业务接口一致。
回答结果最好带引用。比如模型说“批创失败可以先看任务状态，再看媒体返回错误，再对失败项重提”，后面应该能列出引用文档或片段。没有引用的回答看起来很顺，但用户不知道它是从哪里来的，也无法判断是否适用于当前项目。
从后端视角看，RAG 是一条完整的数据链路：文档采集、清洗、切分、向量化、索引、召回、重排、权限过滤、上下文拼接、回答生成和引用回传。每一环都可能影响最终效果。把它当成检索系统来设计，才不会把问题都甩给“提示词不够好”。
评估也要工程化。可以准备一批真实问题，比如“媒体 token 过期怎么处理”“批创失败如何重提”“路径分析保存结果分群的限制是什么”“标签历史版本为什么没数据”。每个问题都标注期望引用来源和关键答案点。上线后定期跑这批问题，观察召回文档是否正确、回答是否引用、是否出现越权内容。没有评估集的 RAG，很难判断是变好了还是只是回答更长了。
当 RAG 和 Agent 结合时，边界更要清楚。RAG 负责提供上下文，Agent 工具负责执行动作。模型在没有足够依据时，应该继续检索或提示用户补参数，而不是直接调用工具。这样才能避免“资料没找全，但动作已经执行”的风险。