标准答案
- RAG 适合企业文档、产品政策、代码库和频繁更新的知识。典型流程是解析资料、建立索引、召回片段、重排序、拼接上下文并生成带依据的回答。
- RAG 不能替代实时交易查询、权限系统、精确计算或需要模型本身能力的复杂推理；这些场景应通过数据库、业务 API 或确定性代码解决。
- RAG 的质量要拆成召回质量、上下文使用质量、答案事实性和引用正确性分别评测，不能只看最终文本是否通顺。
题目解析
RAG 的优势是知识与模型解耦：资料更新时可以重建或增量更新索引，不必重新训练模型。但索引延迟、解析错误、权限过滤和版本冲突都会影响结果。
如果问题要求“当前账户余额是多少”，检索历史文档不可靠；应调用账户服务。模型可以负责理解用户问题和组织解释，但权威事实来自工具。
RAG 也不等于“把搜索结果塞给模型”。召回片段要有来源、版本、租户和权限元数据，生成阶段要限制使用范围，并在无法找到依据时明确说资料不足。
常见误区
- 认为接入向量数据库后就不会幻觉。检索错误和模型误读仍会产生错误答案。
- 用 RAG 查询实时业务状态，忽略数据更新延迟。
- 只验收答案流畅度，不检查引用是否真正支持结论。