RAG
RAG 让模型在回答前先检索你的资料，而不是只依赖训练记忆。它是文档问答、知识库助手和 Agent 工作流里的常见架构。
RAG（Retrieval-Augmented Generation）解决的核心问题是：模型需要基于你的私有或最新资料回答，而不是凭空编造。典型做法是先把文档切块、向量化并建立索引，再在用户提问时检索相关片段，把它们放进 prompt 里生成答案。
要真正搭建一套 RAG 工作流，通常会同时涉及文档处理、Embedding、检索、生成模型和编排框架。下面按这些环节整理相关指南、模型与工具。
RAG 解决什么问题
当你要让 AI 回答「这份 PDF 里写了什么」「我们内部文档怎么规定」或「这批笔记里有哪些矛盾说法」时，单纯对话模型往往缺少可靠上下文。RAG 把「找材料」和「写答案」拆开：先检索，再生成。
它适合知识库问答、客服辅助、研究笔记整理和需要引用来源的 Agent。不适合所有场景：如果问题只需要通用常识，或你能接受把全文直接塞进上下文，未必需要完整 RAG 管线。
- 适合：私有文档、易更新资料、需要可追溯引用的问答
- 不一定需要：极短上下文、纯创意写作、已有托管 File Search 的简单场景
一个典型 RAG 流程
自建 RAG 时，官方文档通常会把流程拆成几个可独立替换的步骤。不同框架命名略有差异，但逻辑相近。
- Ingestion：导入 PDF、网页、数据库记录等原始资料
- Chunking：把长文档切成适合检索的片段
- Embedding：用 Embedding 模型把片段转成向量
- Indexing：写入向量库或托管检索服务
- Retrieval：按用户问题召回最相关片段
- Generation：把片段与问题一起交给 LLM 生成答案
关键组成
一套可运行的 RAG 至少涉及：Embedding 模型（或托管检索服务）、检索层、生成用 LLM，以及把各步串起来的框架或 Agent 编排。
OpenAI、Google、LangChain 等官方路径也提供托管 File Search / Vector Store，把切块与索引托管在 API 侧，适合你不想自建向量库时快速验证。
- Embedding models：把文本映射到向量空间，用于语义检索
- Retrieval layer：向量库、托管 File Search 或混合检索
- LLM：在检索结果基础上生成答案
- Orchestration：LangChain、LangGraph、Agents SDK 等串联流程
什么时候不一定需要完整 RAG
如果资料很短，可以直接放进模型上下文；如果平台已提供托管文档检索（如 File Search），可能不必自建向量索引。
RAG 质量很大程度取决于检索是否召回正确片段，而不是生成模型单独决定。上线前应用自己的文档集做召回与引用检查。
推荐阅读路径
相关指南
- 用 LangChain 搭一条最小 RAG 链路LangChain 官方 RAG 最小闭环。
- 用 Responses API File Search 检索 PDF 知识库OpenAI 托管检索示例。
- 用 Gemini File Search 做托管文档检索Gemini 托管 File Search store 流程。
- 用 LangGraph 构建可定制的 RAG Agent可路由、可评判相关性的 Agentic RAG。
- 用 Deep Agents 做文档 RAG Agentretrieve → offload → delegate 模式。
- 用 Vercel AI SDK 生成 EmbeddingsAI SDK embed / embedMany 与相似度。