RAG（Retrieval-Augmented Generation，检索增强生成）解决的是一个很实在的问题：模型训练时没有你的内部文档、实时数据或专有知识，却要在回答里用到它们。与其指望模型「记住一切」，不如在生成前把相关片段检索出来，当作上下文喂进去。
流程可以想成三步
- 切块与索引：把 PDF、Wiki、工单等切成合适大小的文本块，用嵌入模型变成向量，存进向量库。
- 检索：用户提问同样变成向量，在库里找最相近的一批块（可加关键词过滤、元数据过滤）。
- 生成：把「用户问题 + 检索到的片段」写进提示，让模型只依据这些材料组织答案。
这样答案能贴紧你的资料，更新文档后重新索引即可，不必整模型重训。
和「微调」不是二选一
- 微调：更像教模型一种能力或风格（格式、领域术语偏好、特定任务模式），成本高、迭代慢。
- RAG：像开卷考试，强项是可解释、可更新、可追溯——你能看到模型读了哪几段再回答。
实务里常见组合：通用能力靠基础模型 + 规范靠提示词 + 事实靠 RAG，必要时再对部分场景微调。
常见坑
- 块太大：噪声多，检索不准；太小：上下文断裂。需要按标题、段落或语义边界调。
- 只检索不问路：复杂问题可先让模型把问题拆成子查询，再分别检索合并。
- 没有引用：产品侧最好展示「参考片段」或链接，方便用户与审计核对。
小结
RAG 的核心不是「向量数据库很酷」，而是把生成绑在可更新的证据上。若你的场景是内部知识库、客服、文档助手，它通常是比单纯提示词更稳的一块拼图。
