RAG详解：让大模型看见你的私有知识

本文已收录至GitHub，推荐阅读 👉 Java随想录

微信公众号：Java随想录

在把大语言模型用到实际业务时，开发者很快会遇到一个问题：通用模型很难满足特定场景的需求。

主要卡在三个地方：

知识过时：模型的训练数据有截止日期，问它最近发生的事基本白问。
幻觉严重：模型经常一本正经地胡说八道，在需要准确性的场景这是致命的。
数据安全：企业不可能把内部文档上传给第三方，但不上传模型又不会。

基于这个问题，RAG（检索增强生成） 出现了。它的思路很简单：不把数据交给模型，而是让模型"看到"它需要的部分。

用户提问时，系统从私有知识库中检索相关片段，把这些片段和问题一起发给大模型。模型结合真实信息来回答，而不是靠"记忆"里不知道哪来的东西生成。

为什么需要 RAG

知识的局限性

大语言模型的知识完全来自训练数据。GPT-4、文心一言、通义千问这些主流模型，训练数据主要来自网络公开数据。这带来两个问题：

时效性：模型的"知识"被定格在训练截止时间点。GPT-4 的知识库可能停在 2023 年 12 月，之后的新事件、新政策、新技术，它无法直接给出准确答案。
私有领域缺失：企业的产品规格文档、内部流程规范、医疗机构的诊断指南、法律机构的判例汇编------这些数据从没出现在公开网络上，通用大模型对此一无所知。不借助外部手段，模型在这些领域的回答质量会大打折扣。

幻觉问题

大语言模型在生成文本时，实际上是在计算下一个 token 出现的概率分布。这种机制导致模型在面对不确定性问题时，经常编造看似合理实则错误的答案------学名叫"幻觉"（Hallucination）。

更麻烦的是，模型不具备某一方面知识时，它不会选择"不知道"，而是倾向于根据训练数据中学习到的语言模式，自信满满地瞎编。在需要高度准确性的生产环境中，这绝对不可接受。

数据安全

对企业来说，数据安全是生死攸关的议题。没人愿意承担核心商业机密泄露的风险，因此几乎没有企业愿意将私有数据上传到第三方平台进行模型训练或推理。

这意味着，完全依赖通用大模型自身能力的应用方案，不得不在数据安全 和应用效果之间做取舍。传统方案要么保数据安全牺牲模型能力，要么提升模型能力却承担数据泄露风险。

RAG 的破局思路

RAG 提供了第三条路：不把数据交给模型，而是让模型"看到"它需要的那部分数据。

用户提问时，系统从私有知识库中检索相关片段，把这些片段作为上下文提供给大模型。大模型在回答时，既能"参考"检索到的真实信息，又能结合自身的语言理解能力生成流畅的回答。数据始终留在本地，模型获得了"感知"私有知识的能力。

RAG 的技术架构

RAG 的完整工作流程分为两个阶段：数据准备阶段（离线索引） 和 应用阶段（在线推理）。

数据准备阶段：构建知识的向量化索引

数据准备是离线过程，目标是将私有数据转化为可高效检索的向量形式。流程包含四个环节：

数据提取。从多种格式的原始文件中提取纯文本内容，包括 PDF、Word、HTML、数据库记录等。技术挑战在于处理各种格式解析、特殊字符清理、无用内容过滤。常用 LangChain 的 DocumentLoaders 来统一处理不同来源的数据。

文本分割（Chunking）。直接影响检索质量。需要综合考虑两个因素：一是 embedding 模型对 token 长度的限制；二是语义完整性对检索效果的影响。

固定长度分割实现简单，但容易切断语义边界，导致检索时丢失关键上下文。语义分割通过识别句子边界或段落结构来进行切分，能更好地保留语义完整性，但实现复杂度更高。业界常用策略是设置合适的 chunk size（如 512 tokens）和 overlap（如 50-100 tokens），在保证语义完整性的同时避免边界效应。

向量化（Embedding）。将文本转化为高维向量，让语义相似的文本在向量空间中具有相近的位置关系。常见的 embedding 模型：

模型名称	特点	适用场景
OpenAI text-embedding-3	API 调用，稳定可靠	通用场景
BGE (BAAI)	开源、支持中英文	自部署场景
M3E (MokaAI)	开源、多语言支持	中文场景
ERNIE-Embedding	百度自研、中文优化	国产化需求

数据入库。将向量及其关联的原始文本、元数据写入向量数据库。主流选择包括 FAISS、Chroma、Milvus、Weaviate 和 Qdrant 等。这些数据库采用近似最近邻（ANN）算法，能够在海量向量中快速找到与查询向量最相似的结果。

应用阶段

用户提出问题时，RAG 系统进入在线推理阶段，包含四个关键步骤：

查询向量化。使用与索引阶段相同的 embedding 模型，将用户的自然语言问题转化为语义向量。这个向量的质量直接决定后续检索的准确性。

信息检索（Retrieval）。通过计算查询向量与所有存储向量的相似度（如余弦相似度、欧氏距离），找出 top-k 个最相关的文档片段。现代向量数据库通常采用 HNSW（Hierarchical Navigable Small World）等算法，在保证检索精度的同时实现毫秒级响应。

上下文构建。将检索到的相关片段与原始问题组装成完整的提示模板。一个典型的 RAG 提示模板：

diff 复制代码

【任务描述】
假如你是一个专业的客服机器人，请参考【背景知识】中的内容，准确回答用户的问题。

【背景知识】
{检索到的相关文档片段}

【用户问题】
{用户原始问题}

【回答要求】
- 仅根据【背景知识】中的内容回答
- 如果【背景知识】中没有相关信息，请明确告知
- 回答要简洁、准确、有条理

答案生成（Generation）。大语言模型接收包含问题和上下文的提示后，结合检索到的真实信息生成最终答案。由于有明确的参考资料作为约束，模型产生幻觉的概率大大降低。

高级 RAG 技术

基础 RAG 流程能工作，但在实际应用中往往面临检索质量不足、生成效果不稳定等问题。业界发展出一系列高级 RAG 技术来优化系统性能。

搜索索引的演进

平面索引（Flat Index） 直接计算查询向量与所有存储向量的相似度。实现简单，但数据规模达到数万条时，线性扫描的计算开销变得不可接受。

向量索引 采用近似最近邻算法来解决效率问题。FAISS 库提供了多种索引类型：

IVF（Inverted File Index）：通过聚类将向量分组，检索时只搜索最相关的聚类中心，显著减少计算量。
HNSW（Hierarchical Navigable Small World）：构建多层图结构，实现对数级别的检索复杂度。
PQ（Product Quantization）：对高维向量进行压缩，大幅降低内存占用。

分层索引 应对大型知识库。系统维护两个层级的索引：一个由文档摘要组成，用于快速过滤；另一个由文档块组成，用于精确检索。这种设计在保证检索召回率的同时，大幅提升检索效率。

混合搜索

单纯的向量检索在处理精确术语匹配时往往表现不佳。比如用户搜索"如何重置密码"，向量检索可能无法准确识别"重置"和"修改"之间的细微差别。

混合搜索 结合传统关键词检索（如 BM25、TF-IDF）和现代语义向量检索。两种检索结果通过 Reciprocal Rank Fusion（RRF）算法 进行融合：对不同检索方法的结果按排名赋分，综合排名最高的文档被选中。

关键词检索确保精确匹配的召回，语义检索捕捉同义词和语义关联。两者互补，能够应对更广泛的查询类型。

内容增强

语句窗口检索器（Sentence Window Retriever） 采用"小块索引、大窗口上下文"的策略。文档中的每个句子单独嵌入向量索引以保证检索精度，但检索后扩展上下文窗口，额外获取前后各 k 个句子，提供更完整的语义信息给大模型。

自动合并检索器（Parent Document Retriever） 采用层级分割策略：文档被递归分割为较小的子块，每个子块与较大的父块存在引用关系。检索时获取相关子块，当多个相关子块指向同一父块时，自动升级为使用父块作为上下文。这种设计让系统同时获得精确检索和宏观语义。

HyDE：假设性答案增强检索

HyDE（Hypothetical Document Embeddings） 是一种逆向思维的方法：不直接用问题检索，而是先用大模型根据问题生成一个假设性的答案，然后用这个假设答案去检索相关文档。

前提假设是：假设答案与真实文档在语义空间中可能更接近，因为两者都是"回答性"的文本。HyDE 在处理抽象概念或模糊查询时表现尤为出色。

查询转换

用户的原始问题往往不够"检索友好"。查询转换 系列技术利用大模型的推理能力来优化查询：

查询分解（Query Decomposition） 将复杂问题拆分为多个简单子问题。例如，"LangChain 和 LlamaIndex 哪个更适合做 RAG 开发？"这个问题难以直接检索，但可以拆分为"LangChain 做 RAG 开发的优缺点"和"LlamaIndex 做 RAG 开发的优缺点"两个子问题，分别检索后再综合回答。

Step-back Prompting 生成更通用的查询来获取高层次上下文，与原始查询的检索结果一起输入模型，实现"由面到点"的推理。

查询重写（Query Rewriting） 使用大模型改写问题表达，尝试用不同的表述方式检索，提高召回率。

重排与过滤

检索返回的 top-k 结果可能存在质量问题：相关性参差不齐、信息冗余、噪声干扰。重排（Reranking） 技术应运而生。

交叉编码器重排 将查询和每个候选文档一起输入专门的交叉编码模型，输出精细化的相关性评分。这种方法比向量相似度计算更准确，但计算开销更大，通常用于对初始检索结果的二次筛选。

基于元数据的过滤 利用文档的元数据（时间、来源、类别等）进行条件筛选，快速排除不相关的结果。

RAG 融合

RAG 融合（RAG Fusion） 通过 LLM 生成多个变体查询来增强检索效果。单一查询可能无法覆盖用户问题的所有方面，通过让 LLM 生成多个不同角度的查询，可以从知识库中召回更丰富、更多样化的相关信息。

技术流程

多查询生成：使用 LLM 根据用户原始问题生成 n 个相关查询。
并行向量搜索：用所有生成的查询分别进行向量检索。
结果融合排序：应用 RRF 算法对所有检索结果进行综合排名。
上下文注入：将融合后的相关文档注入提示模板。
答案生成：LLM 基于融合后的上下文生成最终答案。

优势

多样性增强：不同查询从不同角度切入问题，最终结果涵盖更广泛的视角，减少单一视角带来的偏差。

鲁棒性提升：某个查询因表述偏差导致检索不佳时，其他查询可以弥补缺陷，提升整体系统的稳定性。

语义纠偏：LLM 生成的查询往往是对原始问题的语义扩展，能够捕捉隐含的语义关联。

注意事项

延迟增加：额外的 LLM 调用会引入额外延迟，在延迟敏感的场景中需要权衡。

专业术语处理：如果知识库包含大量内部术语或行话，LLM 可能因不了解这些术语而产生无关查询，此时需要针对性优化提示词。

成本考量：额外的 LLM 调用意味着额外的 token 消耗，需要评估 ROI。

评估体系

RAG 系统的质量评估是工程实践中的重要环节。业界通常采用 RAG 三元组 评估框架：

检索内容相关性（Context Relevance）：评估检索到的文档与用户问题的相关程度。高相关性意味着检索阶段工作良好，能够召回真正有用的信息。常用指标包括召回率（Recall）和精确率（Precision）。
答案基于性（Answer Groundedness）：衡量 LLM 的回答是否基于检索到的上下文，而非依赖自身知识或产生幻觉。这一指标直接反映 RAG 机制的有效性。
答案相关性（Answer Relevance）：评估生成的回答是否有效解决了用户的问题。高相关性意味着即使检索和基于性都良好，最终答案也能真正满足用户需求。

评估框架与工具

RAGAs 是当前流行的 RAG 评估框架，提供标准化的评估流程和指标计算方法。

LangSmith 是 LangChain 官方提供的评估平台，支持自定义评估器、运行时监控和调试追踪。

Truelens 由 LlamaIndex 团队推出，专注于 RAG 系统的可观测性和评估。

发展趋势

RAG 技术正在快速演进，几个方向值得关注：

端到端优化 。传统 RAG 将检索和生成视为独立环节，但最新研究开始探索联合优化的可能性。Meta AI 提出的 RA-DIT 技术同时微调 LLM 和 Retriever，让两个组件在学习过程中相互适应，在知识密集型任务上取得了显著提升。

多模态 RAG。随着多模态大模型的发展，RAG 的边界正在从纯文本扩展到图像、视频、音频等多种模态。未来的 RAG 系统需要能够处理跨模态的知识检索和生成。

主动学习与持续优化。结合用户反馈和评估结果，构建自适应优化机制，让 RAG 系统能够从实际使用中持续学习和改进。

轻量化与边缘部署。随着模型压缩技术的发展，更小、更快的 LLM 将成为 RAG 系统的新选择。Mistral Mixtral、Microsoft Phi-2 等小参数模型的崛起，为 RAG 在边缘设备上的部署开辟了新的可能性。

结语

RAG 技术通过将检索能力与大语言模型的生成能力相结合，为 LLM 的实际应用提供了一条切实可行的路。它解决了知识时效性、私有数据访问和幻觉抑制等核心问题。

当然，RAG 不是万能药。检索质量、响应延迟、系统复杂度等挑战依然存在。开发者需要根据具体场景权衡利弊，选择合适的技术组合。

至于未来会怎样，让时间来检验。