什么是RAG？Retrieval-Augmented Generation — 让AI学会查阅文档

RAG——Retrieval-Augmented Generation（检索增强生成）的缩写——是一种将LLM的语言生成能力与回答前实时查阅文档相结合的技术，让AI不再需要单纯依赖固定参数中存储的"记忆"来"猜测"答案。本文将逐步拆解RAG的完整架构、构建方式，以及与微调的对比和在企业中的应用。

什么是RAG？

**RAG（Retrieval-Augmented Generation，检索增强生成）**是一种通过自动检索相关文档、并在模型生成回答前将这些内容注入提示词（prompt）的方式来增强大语言模型知识的方法。与仅依赖训练过程中"烘焙"进参数的知识不同，RAG模型额外拥有一个外部信息源——灵活、可更新且可溯源。

最直观的类比：想象一次开卷考试。闭卷考试的学生必须全凭记忆作答——容易出错，甚至可能编造答案。开卷考试的学生则可以在回答前查阅教材——答案更准确，来源更清晰。RAG正是让LLM从"闭卷"变为"开卷"。

RAG解决了哪些问题

在理解RAG的工作原理之前，先看看它针对的三个核心痛点。

幻觉（Hallucination）——AI编造信息

LLM通过基于概率预测下一个token来生成文本。当参数中缺乏足够信息时，模型仍可能自信地给出完全错误的回答——这种现象被称为"幻觉"（hallucination）。在企业环境中，这会带来严重风险：错误报告、不准确的法律建议、导致故障的技术支持。

知识截止日期——知识被"冻结"

所有LLM都有训练截止日期（cutoff）。此后发生的事件、新出台的法规或新产品，模型一概不知。对于企业而言，内部文档（合同、政策、产品目录）持续更新——每次更新都重新训练模型，无论从成本还是时间上都不现实。

企业私有知识不在模型中

企业内部数据（内部技术文档、客服历史记录、业务报告）从未出现在公开训练集中。LLM无法了解它从未"读过"的内容。

RAG架构逐步解析

典型的RAG系统分为两个阶段：索引（Indexing）（文档加载与建立索引）离线运行，**检索+生成（Retrieval + Generation）**在用户提问时在线运行。

阶段一——索引（离线）

步骤1：文档加载（Document Loading） 来自多种来源（PDF、Word、网页、数据库、Confluence、Notion等）的文档被读取并标准化为纯文本格式。

步骤2：分块（Chunking）——将文档切分为小段 长文档被切分为更小的片段，称为chunk（块）。这是RAG中最关键的步骤——块太长会引入噪音，块太短则丢失上下文。通常每块使用256至512个token，并保留10%至20%的重叠，以确保语义连贯。

步骤3：嵌入（Embedding）——生成向量 每个chunk通过嵌入模型（如OpenAI的text-embedding-3-large、Google的embedding-001）转换为多维实数向量。语义相近的片段在向量空间中距离更近。

步骤4：存入向量数据库 （chunk文本，向量）对存入向量数据库，如Pinecone、Weaviate、Qdrant或pgvector，随时备查。

阶段二——检索+生成（在线）

步骤5：用户问题嵌入 用户提问后，该问题同样通过相同的嵌入模型转换为查询向量。

步骤6：检索top-k个块 向量数据库找出与查询向量最相近的k个chunk（通常k=3至10），使用余弦相似度或点积计算。

步骤7：注入提示词（Context Augmentation） 检索到的chunk被拼入用户问题前的提示词，形成包含完整上下文的提示词。

步骤8：LLM生成回答 LLM接收到已补充文档的提示词，生成有据可查、来源清晰的回答。

 1[提示词示例]
 2
 3你是一名技术支持助理。请根据以下文档回答问题：
 4
 5--- 文档内容 ---
 6{chunk_1}
 7{chunk_2}
 8{chunk_3}
 9--- 文档结束 ---
10
11问题：{user_question}
12请简洁、准确地作答。如果文档信息不足，请明确说明。

嵌入与向量数据库——简明解释

什么是嵌入？

想象一张语义地图："狗"和"猫"因为都是宠物而彼此相近；"银行"（金融机构）和"河岸"虽然写法相同，含义却相距甚远。嵌入技术将文本表示为该语义地图上的坐标——以数千维的向量形式呈现。

嵌入模型在数十亿对相似句子上训练，学习如何放置向量：即使"产品出现电源故障"和"机器无法开机"没有任何相同词汇，它们的向量也会彼此相近。

什么是向量数据库？

向量数据库是专为向量数据而构建的搜索工具。与SQL依靠等于/大于/小于条件检索不同，向量数据库计算查询向量与库中所有向量之间的相似度，并返回最近的k个结果。HNSW等近似最近邻（ANN）算法即使面对数百万个向量也能实现极速检索。

如何构建高效的RAG系统

分块策略

分块策略是决定RAG质量最关键的环节。常见策略包括：

• 固定大小分块（Fixed-size chunking）：按固定token数切分，简单但可能在句中截断。
• 句子/段落分块（Sentence / Paragraph chunking）：按句子或段落边界切分——上下文更自然。
• 递归分块（Recursive chunking）：先尝试按较大段落切分，过长时再进一步细分——保留文档结构。
• 语义分块（Semantic chunking）：利用嵌入自动检测话题转换点并在此切分——质量最高，但成本也更高。

重排序（Re-ranking）——提升top-k质量

初步向量检索优先考虑速度（ANN），有时返回的chunk相关但精度不足。重排序器（如Cohere Rerank或交叉编码器）逐对读取（查询，chunk）并进行更精细的打分，在注入提示词前重新排列列表。重排序可显著提升准确性，但会增加约100至300毫秒的延迟。

调整top-k数量

k越大，LLM获得的上下文越多——但提示词也越长、消耗token越多，有时还会导致"迷失在中间"（LLM忽略长提示词中间的信息）。实践中通常从k=5开始，再根据实际回答质量进行调整。

RAG vs 微调——实际对比

RAG的实际应用

内部文档问答机器人

这是最常见的使用场景：员工可以直接询问公司政策、运营流程、技术规范——无需在数百个文件中手动翻找。系统检索出准确的文档片段，生成简洁、附有引用的回答。

自动化客户支持

客服机器人加载了完整的FAQ、产品目录和保修政策。当客户询问具体故障时，系统找到对应的处理指引并准确作答——无需手动编写所有对话场景。

法律与医疗查询

在法律或医疗等对准确性要求极高的领域，RAG使AI能够引用具体的法规条文或治疗方案——更重要的是，可以显示来源供用户核实。

结合RAG的企业数据分析

RAG不仅限于静态文本。结合Apache Spark等大数据管道批量处理和更新语料库，或通过API集成让RAG系统自动从多个来源拉取最新数据，是企业实际部署中的常见方向。

希望快速从内部业务报告中挖掘洞察的企业，可以将RAG与AlgoData等分析平台结合使用——该平台的市场与运营数据已经过组织整理，可直接接入检索管道。

RAG的局限性

RAG并非万能解药。以下几点局限性值得关注：

输出质量完全取决于输入文档的质量。"垃圾进，垃圾出"——如果源文档过时、存在矛盾或写作质量低下，RAG的回答质量也会随之下降。

**难以处理综合性问题。**需要整合分散在多份文档中的信息，或涉及多步推理的问题，简单的top-k检索难以胜任。Advanced RAG（多跳检索、HyDE、查询分解）正是为解决这一局限而发展起来的。

**增加额外延迟。**每个请求都需要先进行查询嵌入、向量检索，以及可选的重排序，然后才调用LLM。对于低延迟系统，这可能额外增加200至500毫秒。

**token成本增加。**由于上下文被注入提示词，每次请求的提示词更长，消耗的token也更多，规模化部署时会直接影响成本。

结论： RAG是将LLM引入企业环境最务实的一步——它将一个强大却缺乏上下文的语言模型，转变为真正能够查阅组织文档、给出准确且可溯源回答的智能助理。

常见问题