检索增强生成（RAG）折腾手记

开源模型如 BGE、M3E 在中文场景下表现优异，而 OpenAI text-embedding-3 在英文上更精准。

大语言模型（LLM）的出现彻底改变了人机交互的方式，但纯生成式模型固有的局限性——知识截止时间、幻觉现象和缺乏私有数据访问能力——限制了其在企业级应用中的直接落地。

引言

大语言模型（LLM）的出现彻底改变了人机交互的方式，但纯生成式模型固有的局限性——知识截止时间、幻觉现象和缺乏私有数据访问能力——限制了其在企业级应用中的直接落地。

检索增强生成（RAG，Retrieval-Augmented Generation）应运而生。它并非简单的"外挂知识库"，而是一种精密的工程架构，旨在将大模型的语义理解能力与外部世界的准确信息完美融合。本文将深入剖析 RAG 的架构设计、核心挑战以及工程化落地的最佳实践。

一、为何需要 RAG：纯生成模型的困境

要理解 RAG，首先要直面纯生成式模型的三个核心困境：

知识截止与滞后性

模型的知识固化在训练结束的那一刻。模型无法感知训练数据生成之后发生的世界变化。对于实时性要求高的场景（如股价查询、政策解读），仅靠模型参数是完全不够的。

幻觉现象

模型基于概率分布生成文本，而非基于事实检索。在缺乏足够信息时，模型会"一本正经地胡说八道"。这种不可控性在医疗、法律等高风险领域是不可接受的。

数据隐私与安全

将企业私有数据（代码库、文档、合同）通过 API 发送给公共大模型，存在严重的数据泄露风险。同时，公有模型也无法访问企业内网的非公开数据。

RAG 的核心价值在于：不修改模型参数，仅通过改变"提示上下文"来引导模型生成准确、实时、私有化的答案。

二、RAG 架构的核心组件

一个成熟的 RAG 系统通常由数据摄取（Ingestion）、检索（Retrieval）、增强（Augmentation）和生成（Generation）四个阶段组成。

1. 数据摄取与向量化管道

这是 RAG 系统的地基，其质量直接决定了检索效果。

文档解析与清洗

非结构化数据（PDF、Word、网页）需要经过 OCR、格式转换、去噪等步骤。工程上需处理图表解析、页眉页脚去除、公式识别等复杂边缘情况。

分块策略

将长文档切分成小段落是关键步骤。切分过细则丢失语义上下文，切分过长则引入噪声。

• 固定窗口切分：简单但易切断语义。
• 递归字符切分：优先按段落、句子切分，保持语义完整性。
• 语义切分：基于嵌入向量的相似度进行切分，确保每个块在语义上是独立的。

向量嵌入模型

选择合适的 Embedding 模型至关重要。开源模型如 BGE、M3E 在中文场景下表现优异，而 OpenAI text-embedding-3 在英文上更精准。需根据场景权衡模型维度（影响性能与精度）和语言覆盖能力。

2. 检索策略的演进

检索是 RAG 的心脏。早期简单的向量搜索已无法满足复杂需求，现代 RAG 采用多种策略组合。

向量检索与 HNSW 索引

将文本块转换为高维向量（如 1536 维）并存储在向量数据库中。查询时，将用户问题向量化，计算与库中向量的余弦相似度。

工程上，使用 HNSW（Hierarchical Navigable Small World）算法构建索引。HNSW 通过多层图结构实现近似最近邻（ANN）搜索，将检索复杂度从线性降低到对数级，是目前的工业标准。

混合检索

纯向量检索对专有名词、ID 等硬匹配不友好。混合检索结合了向量检索（语义理解）与关键词检索（如 BM25、TF-IDF）。

• RRF（Reciprocal Rank Fusion）：将向量检索和关键词检索的归一化分数进行融合，综合排序。
• 这能有效缓解语义漂移问题，提升相关性。

重排序

初步检索（Top-K）后，使用精度更高的 Cross-Encoder 模型（如 Cohere Rerank、BGE-Reranker）对结果进行重打分。虽然重排序增加了几十毫秒的延迟，但能显著提升 Top-3 的准确性。

查询转换与理解

用户的问题往往是不清晰的。

• 查询重写：利用 LLM 将用户问题改写为更适合检索的形式。
• 多路查询：将一个复杂问题拆解为多个子问题并行检索。
• HyDE（Hypothetical Document Embeddings）：先生成"假设性的理想回答"，再检索与此回答相似的文档。

3. 上下文注入与生成

检索到的文档片段需要经过精心处理后注入 LLM。

上下文窗口管理

LLM 的上下文窗口是有限资源（如 128K tokens）。

• 长上下文 vs 检索精度：窗口越大，能塞入的信息越多，但中间的内容可能被模型"迷失"（Lost-in-the-Middle 现象）。
• 动态截断：根据上下文窗口大小，动态调整检索返回的文档数量。
• 压缩与摘要：对检索到的长文档进行摘要压缩，保留关键信息。

Prompt 工程与系统提示词

RAG 系统的 System Prompt 是其灵魂。典型的指令包括：

• “请仅基于以下提供的上下文回答问题。如果上下文中没有答案，请明确告知。”
• “当回答引用上下文内容时，请标注来源。” 这能有效引导模型减少幻觉，遵循检索约束。

流式输出与引用标注

为了提升用户体验，生成过程通常采用流式输出（Server-Sent Events）。同时，系统需生成答案与原文档片段的引用映射，让用户可以点击"来源"追溯信息的出处，这是构建可信 AI 的关键。

三、进阶架构：从 RAG 到 Agent

传统的 RAG 是检索即回答，而 Agent 架构允许模型通过工具调用主动规划任务。

多跳推理

回答复杂问题往往需要多次检索。

• 用户：“Compare the revenue growth of Google and Apple in 2023.”
• Agent 思维链：
  1. 检索 Google 2023 财报 -> 提取收入数据。
  2. 检索 Apple 2023 财报 -> 提取收入数据。
  3. 对比数据 -> 生成总结。 LangChain、AutoGPT 等框架为实现这种多跳推理提供了抽象层。

GraphRAG：知识图谱增强

传统的 RAG 依赖关键词和向量相似度，容易丢失实体间的结构化关系。

• 知识图谱构建：从文档中提取实体（人名、地名、公司名）和关系（任职、投资、合作）。
• 图遍历检索：在图数据库（如 Neo4j）中进行多跳查询，找回具有结构关联的实体信息。
• 场景优势：在处理"关系型"问题时（如"列出某人的所有投资公司及其创始人"），GraphRAG 的效果远超传统 RAG。

四、工程化挑战与最佳实践

将 RAG 从原型推向生产环境，面临着一系列工程化挑战。

1. 评估体系构建

如何评价 RAG 的质量？这是最难的一环。

• RAGAS 框架：引入了 Faithfulness（忠实度）、Answer Relevancy（答案相关性）、Context Precision（上下文精准度）等指标。
• 人工评估：对于高风险领域，人工抽检依然是必要手段。
• 自动化测试：构建 Golden Dataset（标准问答集），通过 LLM-as-a-Judge 的方式进行自动化回归测试。

2. 性能与延迟优化

用户无法忍受超过 3 秒的响应延迟。

• 查询并行化：向量化查询和关键词检索并行执行。
• 模型量化：将 Embedding 模型和重排序模型进行 FP16/INT8 量化，减少计算时间。
• 缓存策略：对常见问题建立 LRU 缓存，甚至对检索结果进行缓存。

3. 成本控制

Embedding 和 LLM 推理成本随调用量线性增长。

• 模型分层：对简单问题使用小模型（如 GPT-3.5、Mistral），对复杂问题使用大模型（如 GPT-4、Claude 3 Opus）。
• 本地化部署：对于隐私敏感或高频场景，使用开源模型（Llama 3、Qwen）在本地 GPU 集群上部署，消除 API 调用成本。

4. 数据漂移与监控

知识库在不断更新，Embedding 模型也在迭代。

• 持续索引：建立流水线，自动检测文档变更并增量更新向量索引。
• 检索质量监控：监控检索结果的相关性分数、空结果率，及时发现检索退化。

五、结论与展望

RAG 架构是连接通用大模型与垂直领域知识的桥梁。它不仅降低了模型微调的成本，更提供了一种可解释、可审计的 AI 应用构建范式。

未来的 RAG 系统将不再是被动的"检索-生成"管道，而是演变为具备自我修正、主动规划和多模态理解能力的智能体。随着向量数据库、长上下文模型和多模态技术的发展，RAG 将成为构建下一代 AI 应用的标准基础设施。

对于工程团队而言，构建 RAG 系统的关键不在于集成 API，而在于对数据的深度理解、对检索策略的精细打磨以及对评估体系的持续投入。只有将 AI 能力与软件工程的严谨性相结合，才能交付真正可靠的智能应用。

本文深入探讨了 RAG 的架构设计、核心技术及其工程化实践，希望能为构建企业级 AI 应用提供深度参考。

版权声明: 本文首发于 指尖魔法屋-检索增强生成（RAG）折腾手记（https://blog.thinkmoon.cn/post/7-rag-retrieval-augmented-generation-notes/） 转载或引用必须申明原指尖魔法屋来源及源地址！