了解了 RAG 的定义、设计思想和优势之后，很自然会关心一个问题：在真实的业务环境中，RAG 到底适合用来做什么，又不适合做什么。明确适用范围，是避免项目走弯路的必要前提。
1.6.1 适用场景：哪些问题最适合用 RAG 解决
RAG 的强项在于“基于已有文档生成高质量、可溯源的回答”。以下几种场景几乎是为 RAG 量身定做的：
企业知识库与内部问答
公司内部的制度、流程、产品资料、技术文档等通常是结构化的文本，且更新频繁。员工希望用自然语言提问就能得到准确答案，而不是翻找多个文档。RAG 可以直接构建在内部 wiki、SharePoint、制度手册之上，提供“一问一答+原文链接”的体验。对 HR、IT 运维、法务等部门来说，可显著减少重复答疑的工作量。
客服与售后支持
客服场景中，用户问题往往是标准产品手册或故障处理指南中已经写明的内容。RAG 能将手册、FAQ、历史工单摘要作为知识库，辅助人工客服快速查询，甚至直接作为自助服务的对话机器人。回答附带“参考文档”链接，可以让用户自行验证，减少客诉升级。
合规与审计辅助
金融、医疗、法律等行业需要频繁引用规章制度和法规条款。RAG 系统可以根据提问返回具体条款内容，并明确标注出处。审计人员可以查看回答依据的原文，确认是否有遗漏或曲解，使 AI 输出从“仅供参考”上升到“可归档的工作底稿”。
产品说明书与技术文档查询
消费电子、工业设备的用户手册动辄几百页。用户只想知道“怎么设置定时关机”或“错误代码 E03 什么意思”。RAG 可以直击相关段落，节省翻阅时间，并且可以支持多语言文档的跨语言问答。
动态内容聚合
当信息分散在不同来源（如多个政策公告、不同产品的参数表）时，RAG 可以跨文档综合回答，例如：“A 产品和 B 产品在电池续航、重量上有什么区别？”只要两产品的参数文档都被索引，模型就能基于检索到的片段进行对比回答。
1.6.2 技术边界：RAG 不能做什么
将 RAG 视为万能方案会引起不切实际的期待。明确它的边界，同样重要。
不是实时决策引擎
RAG 擅长回答“文档里写了什么”，但不擅长“现在应该怎么做”这类需要实时数据和复杂推理的问题。例如，根据实时库存和价格波动给出下单建议，RAG 本身无法完成，除非知识库中已经包含了由其他系统生成的、有关当前状态的文字描述。它不能替代业务规则引擎或数据分析平台。
不是数据库查询工具
如果问题可以精确地通过 SQL 从结构化数据库中得出（如“上月销售额总计多少”），那么直接用 NL2SQL 或报表系统效率更高。RAG 去“阅读”大量数据库导出的文本报告来回答数字型问题，既不稳定也不高效。它的强项是非结构化文本，而非精确数值计算。
不保证零幻觉
虽然 RAG 大幅降低了幻觉概率，但不能完全消除。当检索结果不完整、文档相互矛盾，或问题需要多跳推理时，模型仍可能对信息进行不准确的整合。将 RAG 用于医疗诊断建议、完全自动化法律判决等高后果场景时，必须保留人工审核环节。
不替代深度定制模型的专业任务
对于高度专业化且需要内部隐含经验的领域（如特定设备的故障预测、需要从图像中识别缺陷），单纯依靠文本检索难以达到专业模型的精度。RAG 适用于传达已有知识，而不是从零发现新规律。
对知识库质量高度敏感
如果文档本身过时、矛盾、零散，或者索引切分不合理，RAG 的输出质量会直接下降。RAG 并不“聪明”到可以自动纠正文档错误，它只能忠实呈现检索到的内容，或者被错误内容误导。因此，启用 RAG 的前提是存在一套相对可信、可维护的文档体系。
1.6.3 选择合适的时机
一个实用的判断方法：如果你的团队已经维护着一批结构化或半结构化的文档，且经常有人需要从这些文档中查找答案，那么 RAG 往往是投入产出比最高的方案。 而如果需要的是复杂的数值分析、图像识别、实时决策，RAG 更适合作为系统中的一个组件，与其他技术搭配使用。
认清适用场景和技术边界，能够帮助团队在立项阶段就设定合理的预期，避免后续投入大量精力后才发现选错了技术路线。在接下来的章节中，我们将根据这些场景需求，一步步讲解 RAG 系统的实际搭建方法。