检索增强生成（RAG）是构建能够处理特定、最新或专有信息的AI应用程序最广泛部署的模式之一。以下是它实际上是什么以及何时使用它。
RAG解决的问题
大型语言模型（LLM）有训练截止点——它们不了解训练数据结束后的事件。它们也不知道你公司的内部文档、你的产品文档或你的数据库内容。你可以在你的数据上微调模型，但微调昂贵、更新缓慢，并且对特定事实的检索效果不佳。RAG以不同方式解决这个问题：在查询时，从你的知识库检索相关文档，然后将其作为上下文包含在提示词中。模型基于检索到的上下文回答，不只是基于其训练数据。
RAG如何工作
架构有两个阶段。索引：你的文档被分成块（通常500到1000个令牌），每个块被转换为嵌入（使用像OpenAI的text-embedding-3-small或sentence-transformers这样的模型代表语义意义的数字向量），这些嵌入存储在向量数据库中（Pinecone、Chroma、Weaviate、pgvector）。检索和生成：当用户问一个问题时，问题被转换为嵌入，向量数据库找到最相似的块（余弦相似度搜索），前k个块作为上下文包含在提示词中，LLM基于上下文生成答案。关键：模型现在可以回答关于它从未被训练过的文档的问题，你可以更新你的知识库而无需重新训练。
RAG何时是正确选择
使用RAG当：你的应用程序需要来自特定、定期更新的知识库的答案；你需要模型引用或参考特定文档；你的数据是专有的，无法包含在微调中；或者数据量超过单个提示词上下文可以容纳的内容。不要使用RAG当：信息已经在模型的训练数据中；你需要同时对多个文档进行复杂推理（RAG检索相关块，不是全部）；或者你需要模型从数据中学习模式而不是检索事实。
构建简单的RAG系统
最小技术栈：文档分块器（LangChain的RecursiveCharacterTextSplitter或简单Python分割）、嵌入模型（OpenAI text-embedding-3-small，每百万令牌0.02美元）、向量存储（本地开发用Chroma，生产PostgreSQL集成用pgvector）和LLM（Claude或GPT-4用于生成）。提示词模板：”使用以下上下文回答问题。上下文：{retrieved_chunks}。问题：{user_question}。”添加来源引用：在元数据中包含文档名称和块位置，以便模型可以引用其来源。这种基本架构处理知识库问答、文档搜索和内部聊天机器人的大多数生产RAG需求。
