RAG（检索增强生成）目前是实际上最重要的AI架构模式之一。以下是它实际上是什么，为什么重要，以及何时使用它与替代方案。
RAG解决的核心问题
大型语言模型有知识截止日期，无法访问你的私有数据。如果你想要AI回答关于公司内部文件、最近事件、数据库或其训练数据中没有的任何信息的问题，基础模型无法准确地做到——它要么说它不知道，要么更糟，产生听起来合理但错误的答案。微调（在你的数据上重新训练模型）解决了部分问题，但很贵、很慢，且不能实时更新。RAG提供了一种更便宜、更快、可动态更新的解决方案。
RAG如何工作
RAG将问题分解为两个阶段。索引（离线）：文档被分割成块，每个块被转换为向量嵌入（捕获语义含义的密集数值表示），嵌入存储在向量数据库中（Pinecone、Weaviate、Chroma、Postgres中的pgvector）。检索（查询时）：用户的问题被转换到相同的嵌入空间，向量数据库找到k个最相似的块（语义搜索），这些块作为上下文传递给LLM。生成：LLM在其提示中看到用户的问题和检索到的上下文块，并生成基于该检索信息的答案。结果：模型使用你的数据回答，而不仅仅是其训练数据，并且可以通过向索引添加新文档来更新。
实施基础
框架：LangChain和LlamaIndex是用于构建RAG管道最常用的Python框架——两者都处理文档加载、分块、嵌入和检索。嵌入模型：OpenAI的text-embedding-3-small/large、Cohere的Embed或开源模型（sentence-transformers）。分块策略：最重要且最常被优化不足的步骤。太小的块失去上下文；太大的块稀释相关性。常见默认值：每个块512到1024个令牌，10到20%的重叠。检索质量：仅相似度搜索通常不够——混合搜索（结合向量相似度与关键词BM25搜索）通常优于纯向量搜索。重新排序（使用交叉编码器重新评分检索到的块）进一步提高精度。评估：没有评估，你不知道你的RAG是否真的在工作。RAGAs（检索增强生成评估）是测量忠实度、答案相关性和上下文精度的标准框架。
RAG是正确选择的时候
在以下情况使用RAG：你有一个大型、频繁更新的文档语料库需要用自然语言搜索；你需要引用（RAG可以返回源块，使答案可审计）；你的数据是专有的，不能发送去训练模型；或者你的知识频繁变化。RAG不是正确选择的时候：如果你的数据适合现代LLM的上下文窗口（Claude的200k令牌上下文可以直接处理许多知识库而不需要RAG）；如果查询延迟是关键（RAG增加检索时间）；或者任务以推理为主而不是知识检索为主（编码助手或数学问题解决器不需要RAG）。RAG的新兴替代方案：”长上下文作为上下文”——对于某些用例，简单地将整个文档或知识库放入非常长的上下文窗口，让模型直接关注它，现在与RAG竞争，特别是因为检索可能错过长上下文注意力会捕捉到的相关信息。
