RAG（检索增强生成）技术正成为AI应用落地的关键支撑。本文从底层原理到工程实践，系统梳理RAG的架构演进、技术挑战与应用场景，帮助读者全面理解其在智能问答、企业知识库等领域的价值与落地路径。

最近，RAG这个词在网络中爆火，特别是一些AI方向的小伙伴，网上铺天盖地的文章、视频等教程，但是他们都各有各的不同看法，接下来就让我从我身为一名AI产品经理角度来带你们来彻底的了解什么RAG、他的前世今生是什么、实用场景、工作原理、具体应用。

RAG是什么

RAG全称是Retrieval-Augmented Generation，翻译成中文是检索增强生成。是一种将信息检索与自然语言生成相结合的AI架构模式。让大模型在回答问题时能够先去查找相关的外部知识，然后再基于这些知识来生成答案。

核心是把“先找资料（检索）”和“再用大模型写答案。它是一种技术框架，它通过在生成回答之前主动检索外部知识源中的相关信息，然后将这些信息作为上下文输入给大语言模型，从而让大语言模型（LLM）生成更准确、更有依据的回答。在于弥补大语言模型的知识边界。虽然大语言模型在训练过程中学习了海量数据，但它们的知识是固定在训练时间点的，无法获取实时信息，也难以覆盖所有专业领域的深度知识。RAG通过动态检索外部信息，有效解决了这一局限性。

简单说：在模型回答前，先从你的知识库/网页里找出最相关的片段，把这些片段连同问题一起喂给大模型，让它基于证据作答，并标注来源。

RAG把“外部检索到的资料”接到“生成式大模型”上，模型先检索相关文档，再读懂与综合这些证据来生成回答。这样既能减少幻觉、提供可溯源的引用，又能用更新的知识而不必频繁重训参数。这个名字来自 2020 年 Meta/FAIR 的论文，提出了两种经典配方：RAG-Sequence 与 RAG-Token（按序列或按 token 融合检索证据）。

RAG的前世今生

RAG的发展历程可以追溯到多个研究领域的交汇，它的起源可以追溯到2020年，由Facebook AI Research (FAIR) 团队发表的一篇开创性论文。以下是RAG从概念诞生到成为主流范式的关键时间线和重大事件：接下来就详细介绍一下它的起源和演变过程。

第一阶段：RAG的“史前”时代（2010 – 2019年）

在RAG这个术语出现之前，相关的技术和思想就已经存在，但它们是分散和独立的。

• 信息检索技术的发展：关键词检索：传统的搜索算法如TF-IDF、BM25等，已广泛用于从文档库中快速匹配和召回相关内容。
• 大型语言模型的崛起：Transformer架构的诞生（2017年）：Google发布的Transformer模型奠定了后续所有大型语言模型的基础。
• BERT(2018)和GPT-2/3(2019/2020)：这些模型展示了强大的文本生成能力，但它们存在一个致命缺陷——“闭卷（closed-book）”。它们只能依赖训练数据中的内部知识来回答问题，无法获取实时或特定领域的外部信息，容易出现“幻觉”（Hallucination，即生成不实信息）。
• 这个阶段的特点是：检索可以找到信息，但无法进行复杂的推理和生成；而生成模型虽然能流畅地创造文本，但缺乏事实的准确性。这为RAG的诞生创造了需求。

早期理论基础（2000-2010初期）

RAG的概念源于几个关键的研究方向：

• 信息检索（IR）领域：传统的搜索引擎和文档检索系统为RAG提供了基础架构。早期的TF-IDF、BM25等算法建立了文本相似性匹配的理论基础。
• 问答系统：IBM的Watson系统（2011年在Jeopardy!中获胜）展示了结合知识库和推理能力的可能性，虽然当时还不是现代意义上的RAG。
• 知识图谱：Google的KnowledgeGraph（2012年发布）等结构化知识表示方法，为后来的外部知识整合提供了思路。

深度学习时代的铺垫（2010中期）

• 神经网络语言模型：Word2Vec（2013）、GloVe等词嵌入技术为文本的向量化表示奠定基础。
• 序列到序列模型：Seq2Seq架构（2014）和注意力机制（2015）为生成式任务提供了新的范式。
• 记忆网络：FacebookAI的MemoryNetworks（2014）首次提出了外部记忆模块的概念，允许模型访问和更新外部知识库。

Transformer革命（2017-2019）

• Transformer架构：2017年”AttentionIsAllYouNeed”论文发布，为后续的大规模预训练模型铺平道路。
• 预训练语言模型：BERT（2018）、GPT（2018）等模型展示了预训练的巨大潜力，但也暴露出知识更新困难、幻觉等问题。
• 知识增强模型：研究者开始探索如何将外部知识整合到预训练模型中，如KnowBERT、ERNIE等。

第二阶段：RAG概念的诞生（2020年）

这是一个里程碑式的时刻，RAG作为一种全新的范式被正式提出。

重大事件：

• 2020年，FacebookAIResearch(FAIR)团队发表了论文《Retrieval-AugmentedGenerationforKnowledge-IntensiveNLPTasks》。
• 这篇论文首次提出了“Retrieval-AugmentedGeneration”这一术语，并构建了一个端到端（end-to-end）可训练的RAG模型。

核心创新：

• 将“检索器（Retriever）”和“生成器（Generator）”无缝集成。论文中的模型使用了一个基于BERT的检索器，从外部维基百科数据中查找相关段落；并使用一个基于T5的生成器，将检索到的信息和用户问题一起作为输入，生成最终答案。
• 可端到端训练：与简单地将检索结果作为提示词（prompt）不同，FAIR的RAG模型是一个可联合训练的深度学习模型。这意味着检索器会“学习”如何更好地为生成器提供信息，而生成器也会“学习”如何更有效地利用这些信息。
• 这个事件标志着RAG从一个朴素的“检索+生成”流程，正式升级为一种具有理论基础和可优化空间的AI架构。

RAG的正式提出（2020）

里程碑论文：Facebook AI Research在2020年发表了”Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”，正式提出RAG架构。

核心创新：

• 将密集检索器（通常基于BERT）与生成器（基于BART）结合
• 端到端训练整个系统
• 在多个知识密集型任务上取得显著提升

技术特点：

• 使用DPR（DensePassageRetrieval）进行文档检索
• 将检索到的文档与输入问题拼接后输入生成器
• 支持对检索器和生成器的联合优化

第三阶段：RAG的发展与应用（2021年至今）

RAG的概念提出后，迅速在AI社区和工业界引起轰动，并进入了快速发展的快车道。

2021年：

• 向量数据库的兴起：随着RAG的普及，专门用于存储和检索高维向量的向量数据库（如Pinecone,Milvus,Weaviate）开始流行，极大地提升了RAG系统的检索效率。

2022年 – 2023年：

• RAG技术成为主流：OpenAI发布了ChatGPT，引发了LLM热潮。与此同时，企业开始面临数据安全和模型幻觉的挑战。RAG因其能够利用企业内部私有数据、有效减少幻觉、并且成本远低于模型微调（Fine-tuning）等优点，迅速成为构建企业级AI应用的首选范式。
• RAG框架与工具的繁荣：LangChain、LlamaIndex等开源框架的出现，大大简化了RAG应用的开发过程，使得开发者可以快速集成不同的检索器、LLM和数据源，进一步推动了RAG的普及。

2024年至今：

• RAG架构的深度演进：研究者们开始探索更复杂的RAG变体，如Self-RAG（模型能够自我评估检索到的信息质量并决定是否需要更多信息）、Multi-hopRAG（模型能够进行多轮检索来回答复杂问题）。
• RAG与多模态的融合：RAG的应用不再局限于文本，开始与图像、音频等多模态数据结合，实现跨模态的检索和生成。

快速发展期（2021-2023）

检索方法改进：

• 从稀疏检索（BM25）到密集检索（DPR）
• 混合检索方法的探索
• 更高效的向量检索技术（如FAISS优化）

架构变体：

• FiD（Fusion-in-Decoder）：在解码器中融合多个检索文档
• RAG-TokenvsRAG-Sequence：不同的生成策略
• IterativeRAG：多轮检索和生成的迭代过程

应用拓展：

• 从问答扩展到对话、摘要、代码生成等任务
• 多模态RAG：整合图像、表格等非文本信息

大模型时代的RAG（2023至今）

与大语言模型结合：

• ChatGPT、GPT-4等大模型的出现重新定义了RAG的价值
• RAG成为缓解大模型幻觉、知识更新问题的重要方案

技术突破：

• AdvancedRAG：引入查询重写、文档重排序、答案合成等复杂流程
• ModularRAG：模块化设计，支持灵活的检索和生成策略
• Self-RAG：模型自我反思和批判检索内容的质量

工程化进展：

• LangChain、LlamaIndex等开源框架的普及
• 向量数据库（Pinecone、Weaviate、Chroma等）的成熟
• 企业级RAG解决方案的商业化

• 多智能体RAG：多个专门化的检索和生成智能体协作。
• GraphRAG：结合知识图谱的结构化信息进行检索和推理。
• Long-contextRAG：利用长上下文模型减少检索依赖。
• 实时RAG：支持动态知识更新和实时检索。

RAG的演变反映了AI领域从单一模型能力向组合式、模块化系统的转变，它不仅解决了大模型的一些固有限制，也为构建更可靠、更可控的AI应用提供了重要范式。

RAG的工作原理

前面提到了都是关于RAG的重要性，那么他的工作原理是什么样的呢，或者换句话来说，他的什么能力才使得RAG在如今有不可代替的重要性呢？

先说结论：RAG 的原理可以分解为两个主要阶段：检索（Retrieval）和生成（Generation）。而检测和生成这两个步骤里面又分为很多细小内容。

标准架构（一步步的流水线）

• 数据准备：把PDF、网页、FAQ、产品库、类目表等汇总成文档集。
• 切块（Chunking）：把文档按段落/标题切成小块（比如300–800字符，适度重叠）。
• 向量化（Embedding）：用向量模型把每个块变成向量，存进向量数据库（FAISS/Milvus/PGVector/Elastic等）。
• 检索：收到用户问题→在库里找Top-k相关块（可“向量+关键字BM25的混合检索”）。
• 重排（Rerank，可选）：用更强的交叉编码器把候选块重新打分，提升命中质量。
• 组合提示（Prompt）：把问题+选中的证据块拼成提示词，明确“只能依据以下资料回答”。
• 生成：大模型基于证据作答，并引用来源。
• 反馈与评估：记录命中率/准确率，持续优化“切块、检索、提示”。

RAG的核心原理

首先我们来讲RAG的核心流程，主要分为以下五个方面，

分片、索引、召回、重排、生成

RAG的基本架构

典型的RAG系统包含三个核心组件：

1. 检索器（Retriever）：负责从外部知识库中找到与查询相关的信息片段
2. 生成器（Generator）：通常是大语言模型，负责基于检索到的信息生成最终回答
3. 知识库（KnowledgeBase）：存储外部信息的数据库，通常以向量形式索引（分片，索引，召回，重排，生成）

RAG 的工作流程

RAG 的工作流程可以分为两大阶段：离线阶段（数据准备）和在线阶段（实际问答）。

离线阶段：数据准备（Indexing）

这一阶段的目标是为你的知识库（例如，公司内部文档、PDF、网页、书籍等）构建一个高效的索引，以便后续能快速检索。这个过程通常包括以下步骤：

1）数据加载与分片（Loading & Chunking）

数据加载：首先，你需要将各种格式的非结构化数据加载进来。这可能需要不同的加载器来处理 PDF、DOCX、Markdown、HTML 等文件。

分片：加载进来的文档通常很长，无法直接处理。因此，需要将它们分割成更小、更易于管理的文本块（Chunks）。分片是 RAG 成功的关键之一，分片太大会导致检索不精确（包含太多无关信息），分片太小又可能丢失上下文。常用的分片策略包括按固定大小分片、按句子或段落分片、或者基于语义内容分片。

2）向量化与索引（Embedding & Indexing）

向量化：将每个分片后的文本块使用一个嵌入模型（EmbeddingModel）转换成一个向量（Vector）。这个向量是文本在多维空间中的数学表示，它捕捉了文本的语义信息。语义上相似的文本块，其对应的向量在空间中的距离会非常接近。

索引：所有这些向量会被存储到一个向量数据库（VectorDatabase）中。向量数据库专门为高效的相似性搜索而设计，它使用如HNSW（
HierarchicalNavigableSmallWorld）等算法来快速找到与给定向量最相似的其他向量。这个过程就像是为图书馆的每一本书建立一个精确的坐标索引。

在线阶段：问答流程

当用户提出一个问题时，RAG 系统会立即启动，完成召回、重排、生成这几个关键步骤：

1.召回（Retrieval）

• 查询向量化：系统首先使用与离线阶段相同的嵌入模型，将用户的查询（例如，“公司的报销流程是什么？”）转换成一个查询向量。
• 向量搜索：系统拿着这个查询向量，在向量数据库中进行相似性搜索。它会找出与查询向量最接近的几个文档块向量。这些向量对应的原始文本块就是系统认为最相关的候选项，它们被召回以供下一步使用。

2.重排（Re-ranking）

• 召回阶段通常会返回几十甚至上百个潜在相关的文档块。但其中有些可能相关性不强，或者存在冗余。重排的目的是对这些召回的文档块进行二次排序，以选出真正最相关、最优质的少数几个。
• 重排模型：通常使用一个专门的重排模型（Re-ranker），它比嵌入模型更复杂，能更深入地理解查询和文档块之间的语义关系。重排模型会对每个召回的文档块打分，得分最高的几个（比如前3-5个）将被选出作为最终的上下文。这个步骤极大地提高了最终答案的质量和精确度。

3. 生成（Generation）

• 构建提示：系统将用户的原始问题与经过重排筛选出的高质量文档块拼接在一起，形成一个完整的、结构化的提示（Prompt）。这个提示通常会明确告诉LLM：“根据以下提供的上下文信息，回答这个问题：[用户问题]”。
• LLM推理：这个包含丰富上下文的提示被发送给LLM。LLM会利用其强大的语言理解和生成能力，仅基于提供的外部知识，来生成一个连贯、准确且相关的最终答案。
• 输出答案：LLM生成的答案被返回给用户。由于答案是基于可追溯的外部知识生成的，这大大降低了模型“幻觉”（编造事实）的可能性，并且让答案更具可信度。

它们其实就是把 RAG拆开的 5 个关键环节，从“把资料喂得合适”到“让模型基于证据作答”的整条流水线

RAG步骤拆分

1. 分片（Chunking）

分片（Chunking）是 RAG工作流程中离线阶段的第一个关键步骤，它的核心作用是：将大型、非结构化的原始文档，切分成更小、更易于管理的文本片段。

这个过程就像是图书馆管理员在整理一批新书时，不是把整本书作为一个整体来处理，而是把每本书的内容拆解成章节、段落或知识卡片，并对每张卡片进行单独的索引和编号。这样做是为了方便读者在查找特定信息时，能快速定位到最小、最相关的部分，而不是被迫去阅读整本书。

分片步骤的主要工作内容

• 在做什么：把长文档切成较小的“知识块”（chunks），避免语义被截断、也便于精确检索。
• 做法：结构：把标题+正文放同一块；对目录型/表格型内容用Parent-Child（命中child，上下文补parent）。

数据加载（Data Loading）

• 在分片之前，首先需要将不同格式的原始数据加载到系统中。这些数据可以是PDF文件、Word文档、网页、Markdown文件，甚至是纯文本或JSON文件。
• 不同的文件类型需要特定的加载器（Loader）来处理，将它们的内容提取出来，准备进行切分。

文本切分（Text Splitting）

• 这是分片的核心。加载进来的长文本被切分成多个“块（chunks）”。切分的方式有很多种，具体选择哪种取决于数据类型和应用场景
• 按固定大小切分（Fixed-sizeChunking）：这是最简单也最常用的方法。你设定一个固定的大小（例如，512个字符或256个词），然后沿着这个大小切分文本。为了避免切断句子的中间，通常会设置一个重（overlap）即相邻的两个块之间有一部分内容是重合的。
• 长度：≈300–800中文字符（或200–500tokens），10–20%重叠。
• 按分隔符切分（RecursiveCharacterTextSplitting）：这种方法会根据一系列分隔符（如\n\n\n、.、）来递归地切分文本。这是一种更智能的方法，它会优先按段落切分，如果段落太长再按句子切分，直到满足设定的块大小。这种方式能更好地保留文本的语义完整性。
• 语义切分（SemanticChunking）：这是更高级的方法。它会使用嵌入模型来分析文本的语义，然后根据文本主题或思想的变化来切分。例如，当文本从介绍RAG的原理转到讨论它的优点时，就在这里进行切分。

优劣势

为什么需要：切得好，检索才“命中要点”；切得差，RAG 后面再强也难救。

• 克服上下文窗口限制：大型语言模型（LLM）的输入长度是有限的（通常几千到几万个token）。如果文档太长，直接将整个文档喂给LLM是不可行的。分片让我们可以只向LLM提供最相关的、小块的信息。
• 提高检索准确性：一个大文档可能包含多个主题。如果将整个文档作为一个整体进行向量化，它的向量会变得“模糊”，因为它代表了多个主题的混合。而将文档切分成小块后，每个块的向量会更精确地代表其内容，从而在检索时能更准确地匹配用户的查询。
• 降低“噪音”：在一个长文档中，真正与查询相关的可能只有一两个段落。如果将整个文档都送给LLM，无关的信息可能会干扰LLM的判断，甚至导致它“分心”，从而生成一个质量较低或不准确的答案。分片确保了只有最相关的部分被用来生成答案，减少了“噪音”的干扰。

常见坑：块太长（噪声大、成本高）、太短（语义丢失）、无重叠（句子被劈断）。

总结，分片是将一个大问题拆解成小问题，将复杂信息细化为可管理单元的过程，为后续的向量化、索引和高效检索奠定了坚实的基础。

2. 索引（Indexing）

索引（Indexing）是 RAG工作流程中离线阶段的第二个关键步骤。在分片（Chunking）之后，索引的核心任务是：将分片后的文本数据，转换为一种可以被计算机快速搜索和检索的格式，并进行存储。

这个过程就像是图书馆管理员给每张知识卡片（即分片）打上一个独一无二的、包含了其内容精髓的“编码”，然后把这些编码放入一个特制的卡片柜（向量数据库）中，以便在未来需要时，能通过这个编码快速找到对应的卡片。

1）索引步骤的主要工作内容

在做什么：把分片后的块“编目入库”，以便快速查找。 两类索引（实际常“混合用”）：

• 向量索引：用嵌入模型把块转成向量，存FAISS/Milvus/pgvector等；擅长同义表达的语义匹配。
• 关键词倒排索引：BM25/Elastic；擅长精确词匹配、数字/代号/条款号检索。
• 元数据（metadata）：给每块打标签（语种、时间、类目路径、权限等），便于检索时过滤。
• 向量化（Embedding）
• 核心动作：使用一个嵌入模型（EmbeddingModel），将每一个分片好的文本块转换成一个向量（Vector）。
• 为什么这样做：这个向量是文本在多维空间中的数学表示。它捕捉了文本的语义信息。在向量空间中，语义上相似的文本块（即使它们使用的词语不完全相同），其对应的向量在空间中的位置也更接近。
• 重要性：向量化是索引的核心，它将人类可读的语言信息转化成了计算机可以高效处理的数值信息。没有这个步骤，后续的相似性搜索就无法进行。

2）存储与构建索引（Storing & Index Building）

• 核心动作：将所有分片文本的向量，连同其原始文本内容和元数据（如文档ID、章节名等），一起存储到一个专门的**向量数据库（VectorDatabase）**中。
• 为什么这样做：传统的数据库（如关系型数据库）不擅长处理高维向量的相似性搜索。向量数据库则专门为此类任务而设计。它利用先进的索引算法，如HNSW（HierarchicalNavigableSmallWorld）、Faiss或ScaNN，来构建一个高效的索引结构。
• 技术细节：这些索引结构允许向量数据库在处理数百万甚至数十亿个向量时，依然能以毫秒级的速度找到与给定向量最相似的邻居。它们通过牺牲极小的精确度（这就是近似最近邻搜索）来换取巨大的搜索速度提升，这对于实时响应的用户查询至关重要。

优劣势

为什么需要：索引是 RAG 系统性能和可扩展性的关键，它解决了以下几个问题：

• 高效检索：索引使得系统能够快速地从海量数据中找到相关信息，而不是进行耗时的线性搜索。
• 语义匹配：传统的关键词搜索（如BM25）无法理解语义，它只能匹配字面上的词汇。而向量索引能够进行语义匹配，即使查询和文档使用的词汇不同，只要它们表达的是相同的意思，也能被正确地检索出来。
• 可扩展性：随着知识库的增长，索引能够确保系统的检索性能不会急剧下降。

常见坑：用错嵌入模型（跨语种偏差）、没做去重/清洗、缺权限过滤导致越权命中。

总结，索引是将经过分片的文本数据从原始状态转化为可检索的“知识资产”，为后续的召回、重排和生成奠定了坚实的技术基础。

3. 召回（Retrieval / 粗排）

召回（Retrieval）是 RAG 工作流程中至关重要的第一步，其核心目标是：从庞大的外部知识库中，快速且准确地找到与用户查询最相关的少数几个文档片段。

这个过程可以形象地比喻为：当一个图书馆管理员接到一个主题请求时，他不会去逐字逐句地阅读图书馆里的每一本书，而是会根据主题关键词，快速地在目录或索引卡片上进行查找，找出最有可能包含相关信息的几本书。

1.召回步骤的主要工作内容

在做什么：收到用户问题，先从索引里找一批候选块。

策略：

• Hybrid检索最稳：向量+BM25合并（可各取Top-k，再归一化打分合并）。
• 固定Top-k（例如20）；过小会漏召，过大后续噪声多。
• 可加metadatafilter（例如language=zh、category=”车品”、更新时间≥2025-06）。与“召回率”区别：这里“召回”是一个动作阶段；评估里“召回率(recall@k)”是一个指标。

2.查询向量化（Query Embedding）

• 核心动作：使用一个嵌入模型（EmbeddingModel），将用户的自然语言查询（例如：“RAG的工作流程是什么？”）转换成一个查询向量（QueryVector）。
• 为什么这样做：这个查询向量是查询在多维空间中的数学表示。它捕捉了查询的语义信息。在向量空间中，语义相似的文本（无论词汇是否相同），其对应的向量在空间中的位置也更接近。
• 重要性：这个向量是进行后续相似性搜索的“钥匙”，它把用户的语言问题转换成了计算机可以高效处理的数字格式。

3.向量数据库搜索（Vector Database Search）

• 核心动作：将上一步生成的查询向量作为输入，在预先构建好的向量数据库中进行搜索。
• 为什么这样做：向量数据库专门为高效的相似性搜索而优化。它不进行传统的文本匹配（如关键词搜索），而是计算查询向量与数据库中所有文档块向量之间的距离或相似度（例如，余弦相似度）。距离越近，相似度越高。
• 技术细节：为了在海量数据中实现快速搜索，向量数据库通常不进行精确搜索，而是使用**近似最近邻（ApproximateNearestNeighbor,ANN）**算法，如HNSW、Faiss、ScaNN等。这些算法牺牲了极小的精确度，换取了指数级的搜索速度提升。
• 搜索结果：系统会返回与查询向量最相似的Top-K个文档块向量，通常是几十到几百个。这些向量对应的原始文本块就是初步召回的结果。

4.结果筛选与返回

• 核心动作：将召回的Top-K向量转换回它们对应的原始文本片段。
• 为什么这样做：这些文本片段包含了与用户查询相关的潜在信息。它们被打包成一个列表，作为召回结果，传递给RAG工作流的下一个步骤：重排（Re-ranking）。

优劣势

为什么需要

• 召回率（Recall）：如何确保召回的结果中包含了所有真正相关的文档片段？
• 效率（Efficiency）：如何在面对数百万甚至数十亿个文档片段时，依然能做到毫秒级的搜索响应？
• 质量（Quality）：如何避免召回那些虽然词汇相似但语义上不相关的“噪声”文档片段？

常见坑：只用向量不管关键词 → 数值/缩写查不准；只用关键词不管语义 → 换个说法就找不到。

为了应对这些难题，实践中通常会结合多种召回方法，例如除了基于向量相似度的稠密召回（Dense Retrieval），还可以结合传统的稀疏召回（Sparse Retrieval），如关键词搜索（BM25），以提高召回的全面性。

4) 重排（Re-ranking / 精排）

重排（Re-ranking）是 RAG 工作流程中的一个关键步骤，它发生在召回（Retrieval）之后、生成（Generation）之前。它的核心作用是：对召回阶段初步筛选出的文档片段进行二次精炼，选出真正最相关、最优质的少数几个，作为最终的上下文输入给大型语言模型（LLM）

可以把重排比作一个编辑，它的任务是从一个包含几十篇可能相关的文章草稿中，挑选出最核心、最能支持主题观点的几段内容，然后将它们呈交给最终的作者（LLM）。

1.重排步骤的主要工作内容

在做什么：对“召回的一批候选”做更细的相关性判定，把最相关的 3–8 条放前面。

方法：

• 交叉编码器（cross-encoder）：如Cohere/BAAI/MTEB系列、或LLM-as-reranker；效果最好但算力更贵。
• 简单融合：把向量分+BM25分做ReciprocalRankFusion(RRF)也有奇效。

2.接收召回结果

• 重排阶段接收来自召回模块的输入。这个输入通常是一个包含Top-K个（比如50到100个）文档片段的列表。这些片段都是通过向量相似度搜索找到的，它们虽然与查询相关，但相关性有高有低，甚至可能存在冗余信息。

3.深度语义分析与打分

这是重排的核心。重排模型（通常是一个比嵌入模型更复杂、更强大的模型）会同时分析用户查询和每个召回的文档片段。

它不像召回阶段那样只关注向量距离，而是进行更细致的**交叉注意力（cross-attention）**计算，深度理解查询和文档片段之间的语义关系。这能捕捉到更微妙的关联性，例如：

• 某个文档片段虽然与查询的关键词不完全匹配，但其语义是完美的答案。
• 某个文档片段虽然包含关键词，但实际上是在讨论一个不相关的概念。
• 重排模型会为每个文档片段计算一个新的相关性得分。

4.重新排序与精选

根据上一步计算出的新得分，对所有召回的文档片段进行重新排序。

最终，只选择得分最高的少数几个（比如 3-5 个）文档片段。这些被精选出的片段就是最终会作为上下文，送给 LLM 进行生成。

优劣势

为什么重要：RAG 的质量上限，很大程度由重排是否把“对的证据”放到最前决定。重排是提高 RAG 系统质量的关键，它解决了召回阶段的一些固有局限性：

• 召回的“噪音”问题：向量搜索虽然快，但有时会因为语义的微妙差异或多义性，召回一些相关性不高的文档。重排可以过滤掉这些“噪音”。
• 上下文的限制：大型语言模型的输入窗口（上下文长度）是有限的。如果直接把召回的几十个文档片段都塞进去，不仅会浪费计算资源，还可能稀释掉真正有用的信息，导致LLM生成的答案不够精确。
• 提升答案质量：通过精选出最相关的文档片段，重排确保了LLM在生成答案时所依赖的上下文是最高质量的，这直接提高了最终答案的准确性和可信度，并有效减少了“幻觉”的发生。

常见坑：直接把召回的 Top-20 全塞给大模型——贵且乱；或重排阈值太严导致“没证据”。

总结，重排是一个“去粗取精”的过程，它将召回阶段的“广撒网”结果，通过更精细的“二次筛选”，转化为高质量的、可以直接用于生成的上下文。

5) 生成（Generation）

生成（Generation）是 RAG 工作流程的最后一个关键步骤，也是将所有前期准备工作转化为最终用户答案的环节。简单来说，这是 RAG 系统的核心产出阶段。

可以把这个步骤想象成：一位作家（LLM）从图书馆管理员（检索与重排）那里拿到了所有最相关的参考资料（上下文），然后根据这些资料，撰写出最终的文章（答案）。

1.生成的主要工作内容

在做什么：把“问题 + 最终证据块们”放进提示词，让大模型严格依据证据组织答案，并引用来源。最佳实践：

• 明确规则：“若证据不足，要直说不知道/需人工；必须引用[文档名§小节]”。
• 控制长度与结构化输出（如JSON），避免模型自由发挥。

2. 构建增强提示（Prompt Construction）

这是生成阶段的第一步，也是最重要的一步。系统会将用户的原始问题和重排后精选出的高质量文档片段（上下文）结合起来，形成一个完整的、结构化的提示（Prompt）。

这个提示的设计至关重要，它会清晰地告诉 LLM 应该做什么。一个好的提示通常会包含：

• 明确的指令：例如，“根据以下提供的上下文信息，回答这个问题。”
• 注入的上下文：重排后筛选出的3-5个最相关的文档片段。
• 用户的原始问题：例如，“RAG有什么优点？”

3.LLM 推理（LLM Inference）

• 构建好的增强提示被发送给一个大型语言模型（LLM）。
• LLM会利用其强大的语言理解和生成能力，严格地基于提供的上下文来生成答案。它不再依赖其自身训练时的参数记忆，而是将外部知识作为唯一的事实来源。
• 这个过程就像是LLM在一个“受限的环境”中工作，它被明确告知“你只能从给定的文本中寻找答案，不能编造任何信息”。这大大降低了“幻觉”（Hallucination，即模型编造或虚构事实）的风险。

4.格式化与输出

• LLM生成的答案通常是纯文本形式。
• 系统可能会对答案进行一些后处理，例如格式化为Markdown（加粗、列表、标题等）、检查语法或逻辑流畅度，以确保最终呈现给用户的答案清晰、易读。
• 最后，将格式化好的答案返回给用户。

优劣势

为什么重要

• 准确性与可信度：生成阶段的答案是基于可验证的、外部的知识源，而不是LLM的“记忆”，这使得答案更加准确，用户可以信任其内容。
• 可溯源性：由于答案的生成依赖于特定的上下文，RAG系统可以轻松地提供这些来源文档的链接或引用，让用户可以追溯和验证答案的真实性。
• 弥补LLM知识的不足：LLM的知识是静态的，停留在其训练数据的截止日期。而生成阶段依赖于外部知识库，这意味着系统可以回答关于最新事件、公司内部文档或任何新信息的问题，而无需重新训练模型。
• 减少幻觉：这是RAG最核心的价值之一。通过提供精确的、相关的上下文，RAG几乎消除了LLM编造事实的可能性，因为模型知道自己有可靠的信息可以依赖。

常见坑：提示词没设约束 → 幻觉；把太多噪声证据塞进去 → 答案漂移。

总结，生成是 RAG 整个流程的终点，它将前两个阶段（召回和重排）精心准备好的“原材料”转化为一个高质量、可信赖的最终产品，为用户提供了所需的答案。

总结：（一句话版）

• 分片：决定检索的“颗粒度”。
• 索引：决定能否“快速且可过滤地”找到候选。
• 召回：先捞到“可能相关”的那一批（粗排）。
• 重排：把真正有用的证据排在最前（精排）。
• 生成：让模型在证据的“护栏里”完成回答/分类/摘要，并产出可审计的结果。

缺了任何一个环节，RAG 的“基于证据回答”就不稳；做得越好，准确率、可解释性、时效性越高。

RAG使用场景

使用场景一

问：假设你是一名汽车工程师，正在开发一款新型电动汽车，并且想让大模型回答一个非常具体的问题：“特斯拉 Model 3 最新款的电池热管理系统有什么创新？”

没有 RAG 的情况

如果没有 RAG，大模型只能依靠它在训练时所接触到的通用知识。它可能知道一些关于特斯拉和热管理系统的基本信息，但很可能不知道最新款的 Model 3 有哪些具体的创新。它可能会给出一些泛泛而谈的答案，甚至会“一本正经地胡说八道”，因为它没有访问到最新的、具体的文档。

使用 RAG 的情况

现在，假设我们为大模型部署了 RAG，并且它的外部知识库包含了所有特斯拉官方发布的最新技术文档、新闻稿和专业评测文章。

1.检索：当你提出“特斯拉 Model 3 最新款的电池热管理系统有什么创新？”这个问题时，RAG 会立即去知识库中搜索与“Model 3”、“电池”、“热管理系统”和“创新”等关键词相关的文档。它会找到几篇描述最新款 Model 3 热管理系统改进的官方技术文档和新闻报道。

2.增强：RAG 会将你的问题和这些文档片段组合成一个提示，发送给大模型，例如：

“请根据以下提供的文档内容，回答问题：特斯拉 Model 3 最新款的电池热管理系统有什么创新？

文档片段 1：‘最新款 Model 3 引入了集成式热泵系统，能够更高效地在制冷和制热模式之间切换，相比老款提升了 50% 的效率…’

文档片段 2：‘电池管理系统（BMS）的软件算法也得到了升级，能够根据驾驶习惯和环境温度动态调整电池温度，从而延长电池寿命…’

文档片段 3：…（其他相关信息）”

3.生成：大模型收到这个包含具体信息的提示后，就会利用这些信息来生成一个准确且详细的答案，例如：

“根据最新的技术文档，特斯拉 Model 3 最新款的电池热管理系统主要有两大创新：

1）集成式热泵系统：车辆引入了新的热泵系统，提高了在不同温度下的制冷和制热效率，相比老款提升了 50%。

2）升级的软件算法：电池管理系统的软件算法也得到了优化，能够更智能地管理电池温度，从而有助于延长电池的整体寿命。”

通过这个例子可以看出，RAG 极大地提升了大模型回答特定或最新问题的能力，使其不再局限于训练数据，而是能够像一个真正的专家一样，在查阅了最新资料后给出权威的回答。

使用场景二

给企业内部搭建一个智能客服助手

不使用RAG情况下

传统流程产品知识手册➡️LLM➡️输出

弊端：

1.模型无法读取所有内容（产品手册如果几十上百页，字数过多，超过上下文窗口大小，模型容易只读后面、不读前面，造成信息不准确）

2.模型推理成本高（输入内容过多，所消耗tokens也过多）

3.模型推理慢（输入越多、模型需要消化的内容就越多，模型的输出就会越慢）

使用RAG的情况下

当企业希望利用 RAG 搭建一个智能客服助手时，整个流程会比通用 RAG 流程更加具体和有针对性。这个过程可以分为两大阶段：离线阶段（知识库构建）和在线阶段（实时问答）。

第一阶段：离线知识库构建

这个阶段的目标是让智能客服助手“学习”企业的所有内部知识，从而能够回答客户的各种问题。

1.数据源收集与加载

• 收集数据：首先，你需要确定所有可能包含客服所需知识的数据源。这可能包括：
• 公司内部文档：产品手册、服务协议、技术文档、FAQ、内部知识库文章等。
• 历史客服记录：将过去的客服对话记录（电话录音转录、聊天记录等）进行脱敏处理，作为问答的语料库。
• 网页信息：公司官网、帮助中心、博客、社交媒体上的常见问题。
• 数据加载：使用特定的工具（如LlamaIndex或LangChain的文档加载器）将这些不同格式的数据（PDF、DOCX、HTML、JSON等）提取出来，为后续处理做准备。

2.数据处理与分片

• 清理与预处理：对加载的数据进行清洗，去除无关信息（如页眉、页脚、广告等），并进行统一格式化。
• 分片（Chunking）：将清理后的长文档切分成更小的文本块。对于客服场景，分片策略至关重要。例如，可以按段落或问答对进行分片，确保每个片段都包含一个完整的、有意义的知识点。

3.索引构建

• 向量化（Embedding）：使用一个高质量的嵌入模型将每一个文本块转换成一个向量。对于客服助手，选择一个能理解问答语义的嵌入模型非常重要，确保用户的问题能准确匹配到对应的答案片段。
• 元数据添加：除了文本向量，你还应该为每个文档块添加元数据，如来源文档的URL、文档类型、创建日期等。这对于后续的答案溯源和审计非常有帮助。
• 向量数据库存储：将向量和元数据存储到向量数据库中。这一步是为了实现毫秒级的检索速度，确保客服助手能够快速响应客户。

第二阶段：在线实时问答

当客户在官网或 App 上发起咨询时，智能客服助手会立即启动，完成以下流程：

1.用户查询处理

查询向量化：当客户输入问题时（例如，“如何申请退款？”），系统会立即使用与离线阶段相同的嵌入模型，将这个问题转换成一个查询向量。

2.召回与重排

• 召回（Retrieval）：系统在向量数据库中进行相似性搜索，根据查询向量找到最相似的Top-K个文档块（例如20个）。这些文档块包含了潜在的答案信息。
• 重排（Re-ranking）：为了提升答案质量，重排模型会对这20个文档块进行二次排序，选择其中最相关、最核心的几个（例如3个）作为最终的上下文。这能有效排除无关信息，让LLM获得最干净的输入。

3.增强生成

• 构建提示：系统将客户的原始问题、重排后精选出的上下文以及一个明确的指令（例如，“根据提供的客服知识，回答客户的退款问题。”）组合成一个增强提示。
• LLM推理：将这个增强提示发送给大型语言模型。LLM将严格依据提供的上下文来生成一个连贯、专业的回答。

4.答案输出与后处理

• 格式化：LLM生成的答案会被格式化，以增强可读性（如使用粗体、列表等）。
• 溯源：在答案的底部，可以添加一个链接或引用，指向原始的知识文档，让客户可以点击查看完整信息，增加透明度和信任。
• 转人工选项：如果智能助手无法给出满意的答案，或客户提出更复杂的问题，系统应提供无缝转接人工客服的选项，确保服务不中断。

为什么 RAG 会成为“默认选项”

• 知识随时更新：不需重训模型就可更新知识库（RAG/Atlas/RETRO强调的核心卖点）
• 可解释/可溯源：外部证据可被展示与审计，便于企业合规与人工复核。
• 成本效率：把“长尾知识”放在索引里，用更小模型也能打过超大模型（Atlas的少样本结果尤为典型）

为什么要用 RAG？

前面讲到了RAG的起源、用法等，现在来讲一下，为什么要用RAG，不使用RAG直接通过大语言模型不可以呢？主要从以下几个方面要讲一下RAG的重要性。

1）解决 LLM 局限性（幻觉、过时知识、成本）

尽管LLM具有强大的生成能力，但其存在以下固有局限：

• 时效性问题：LLM的训练数据是静态的，训练完成后无法获取新信息，这意味着它们可能基于旧信息生成响应
• 专业性不足：没有RAG，LLM无法引用信息来源，用户难以验证其生成内容的真实性，难以涵盖所有专业领域的深度知识
• 幻觉：LLM可能生成看似合理但事实上不正确或具有误导性的信息，即所谓的“幻觉”。这种不可预测性会削弱用户信任。
• 成本和可扩展性：使用新数据重新训练LLM的计算和财务成本极高。对于庞大且动态的知识库，扩展传统LLM也面临挑战。

RAG通过向LLM提供实时、权威的外部信息，直接缓解了这些问题，从而使响应基于事实并减少幻觉 。

2）提升企业AI应用价值

对于企业而言，RAG技术具有重要意义：

• 知识资产利用：将企业内部文档、流程、经验转化为可查询的知识库
• 降低部署成本：无需重新训练大模型，通过更新知识库即可获得最新知识
• 增强可信度：提供信息来源，增加AI回答的可追溯性和可信度
• 定制化能力：针对特定行业和场景构建专门的知识库

3）RAG 的核心优势：事实依据、时效性、信任和控制

RAG技术为生成式AI带来了多项显著优势：

• 事实依据：RAG确保LLM的输出基于来自外部来源的已验证事实，显著减少了“生成式AI幻觉”。
• 时效性：它能够动态整合最新的研究、统计数据或新闻，克服了LLM训练数据静态的局限性。
• 增强用户信任：RAG允许提供来源归属（引用或参考文献），使用户能够验证信息，从而增强对AI解决方案的信心。
• 成本效益：与为新数据进行大规模微调或重新训练LLM相比，RAG是一种更经济的方法。
• 更强的开发者控制：开发者对LLM的信息来源拥有更大的控制权，从而更容易进行测试、适应不断变化的需求以及限制敏感信息的检索。

4）降低运营成本与提高效率

训练一个大型语言模型需要巨大的计算资源和时间，成本高达数百万甚至数千万美元。

允许你使用一个通用的、预训练好的LLM，通过在其外部知识库中添加特定领域的知识，就能让模型回答专业领域的问题。这比微调（Fine-tuning）模型更加高效且经济，因为你不需要修改模型的权重，只需更新数据库即可。

5）适用于特定领域和私有数据

LLM 是通用模型，无法访问企业的内部数据，例如公司文档、客户服务记录或专有技术手册。

允许你将这些私有和特定领域的数据作为知识库，让LLM能够安全地访问和利用这些信息，从而构建强大的企业内部知识库问答系统或智能客服。

总结，RAG 就像是给一个聪明但记忆有限的大脑（LLM）安装了一个可以随时更新、随时查阅的“外部硬盘”。这使得 LLM 不仅能够回答通用问题，还能处理特定、最新且私有的信息，大大扩展了其应用范围和可靠性。

RAG系统的挑战与局限性

上边讲到了RAG的重要性，但是RAG是万能的么，并不是，他也有许多的局限性。

1）知识库质量问题（不准确、偏见、格式）

核心问题：RAG系统的输出质量直接取决于其知识库的质量 。

主要问题：

• “垃圾进，垃圾出”：不准确、过时或有偏见的源内容会导致AI生成不正确或不完整的答案。系统缺乏固有的“谎言检测器”，会传播现有的偏见或错误。
• 覆盖空白：缺失的关键主题会造成系统无法提供帮助的盲点。
• 信息过时：在技术等快速变化的领域，昨天的“事实”很快就会变成误导性信息，如果未能及时更新。
• 明显偏见：如果知识库严重倾向于某些观点，RAG系统将成为一个回音室，将这些偏见传递给用户。
• 格式混乱：文档结构不一致可能导致检索系统遗漏隐藏在格式不佳内容中的重要细节。

“垃圾进，垃圾出”原则在RAG中被放大。虽然这适用于任何AI系统，但RAG对外部知识的直接依赖意味着知识库中的缺陷（不准确性、偏见、过时、格式不佳）会立即传播，并可能导致自信但错误的答案，从而损害用户信任并增加合规风险 。LLM对于检索到的上下文缺乏固有的“谎言检测器”。因此，数据治理、质量控制和知识库的持续更新对于RAG的成功至关重要，通常需要大量的人工验证 。

2）信息检索挑战（语义不匹配、分块错误、排序问题）

核心问题：即使知识库完美无缺，检索组件也可能无法找到正确的信息 。

检索难题：

• 语言脱节/同义词盲区：用户查询的措辞与文档内容不同，例如，“远程办公”可能导致检索失败。
• 分块噩梦：不正确的分块大小（太小导致上下文丢失，太大导致噪声）会影响检索效率。
• 排序错误：系统可能优先考虑表面上的词语匹配而非实际相关性。
• 复杂查询：带有多个条件或细微差别的复杂问题可能被过度简化，返回通用信息。
• 低精度/低召回率：检索到的块不匹配（低精度）或未能检索到所有相关块（低召回率）。

检索精度存在“最后一公里”问题。研究反复强调，即使采用高级嵌入技术，初始检索也常常不完美 。语义不匹配、分块问题和排序错误意味着即使存在相关信息，也可能无法有效地呈现或正确地优先提供给LLM。

确保最相关信息到达LLM的“最后一公里”至关重要。这解释了混合搜索以及最关键的重排序技术的必要性，它们能够优化初始检索结果并克服这些固有的局限性。

3）生成与连贯性问题（冲突来源、上下文遗忘）

核心问题：检索到信息后，生成模型可能难以将其合成为连贯、有用的答案，尤其是在处理冲突来源或长时间对话时 。

生成难题：

• 冲突来源：知识库中相互矛盾的信息可能导致不一致或令人困惑的答案。
• 上下文遗忘：在长时间对话中，系统可能忘记之前的上下文，导致不相关的响应。
• “弗兰肯斯坦式响应”：将来自多个来源的内容拼凑在一起可能导致不合逻辑或排序混乱的答案。
• 自信但错误的答案：模型可能生成流畅但事实上不正确且未出现在源文件中的文本。
• 合成瘫痪：难以将细微、冲突的信息整合为简单答案。
• 过度依赖增强信息：模型可能仅仅重复检索到的内容，而没有进行适当的合成。

LLM的角色从纯粹的生成转向“智能合成”。通过RAG，LLM不再是凭空生成，而是受限于检索到的上下文 。这将其主要挑战从生成合理文本转变为将可能分散甚至矛盾的检索信息合成为连贯、准确且符合上下文的答案 。

“弗兰肯斯坦式响应”的局限性突出了这一新挑战。因此，优化RAG中的生成阶段需要关注LLM整合、协调和重述来自多个来源信息的能力，这可能通过针对RAG特定任务的微调或高级提示工程来实现。

4）性能、可扩展性和维护开销

核心问题：随着知识库的增长和用户流量的增加，RAG系统性能可能显著下降，导致响应时间变慢和基础设施成本增加 。

扩展噩梦：

• 搜索时间慢：大型知识库导致搜索速度变慢。
• 高GPU成本：高维嵌入和复杂模型计算密集。
• 指数级基础设施成本：扩展以支持更多文档和用户通常需要昂贵的硬件升级。
• 延迟瓶颈：应用程序和数据库之间的网络跳跃会增加响应时间（10万文档可能增加150-300毫秒）
• 维护开销：更新文档涉及计算密集型的重新嵌入、重新索引和重新平衡。这可能导致更新缓慢、版本控制混乱、同步问题和潜在的服务中断。
• 量化损失：高维嵌入的精度下降。

RAG从概念验证到生产就绪存在运营差距。虽然RAG提供了显著的理论优势，但研究明确指出在规模化部署和维护RAG系统方面存在巨大的实际挑战。管理动态知识库和大型向量索引的成本、延迟和复杂性是巨大的。这表明学术研究与实际企业对性能、效率和持续运营的需求之间存在差距。因此，构建一个“合格”的RAG系统不仅涉及选择正确的算法，还需要稳健的工程实践、基础设施规划以及持续集成和更新的策略。透明度、可解释性和伦理问题

5）透明度与可解释性局限性

核心问题：RAG系统的决策过程通常不透明，难以理解答案是如何得出的或追溯其来源。

透明度难题：

• 不透明的选择逻辑：不清楚系统为何选择某些文档而非其他文档。
• “幽灵来源”：难以追溯哪些文档对响应的特定部分做出了贡献。
• 信任问题：用户和审计人员无法验证合成的响应。
• 隐藏偏见：不透明的过程使得系统性偏见难以被发现和修复。
• 问责制和透明度：AI系统的普遍伦理问题也适用于RAG。

可解释性是RAG中的伦理要求。RAG在事实依据和来源归属方面的承诺因其在信息检索和合成方式上的不透明性而受到损害。这带来了关键的伦理和实践挑战，尤其是在信任和可审计性至关重要的高风险领域（例如法律、医疗）。“幽灵来源”问题直接与出处的好处相悖。因此，未来的RAG开发必须优先考虑可解释AI（XAI）技术，以提供清晰的检索逻辑和来源归属，从而增强用户信任并实现合规性。

工程实施挑战

成本考量

• 存储成本：大规模向量数据库的存储成本
• 计算成本：实时向量检索和模型推理的计算开销
• 维护成本：知识库更新和系统维护的人力成本

性能瓶颈

• 检索延迟：大规模向量检索的响应时间
• 并发处理：高并发场景下的系统性能
• 一致性问题：分布式系统的数据一致性

应用场景限制

知识类型限制

• 难以处理高度抽象或创造性的问题
• 对隐性知识的捕获和表达能力有限
• 在需要常识推理的场景中表现不佳

实时性要求

• 知识更新存在延迟
• 难以处理快速变化的信息
• 在危机响应等场景中可能不够及时

什么是“合格的 RAG”（Checklist + 目标线）

1）合格 RAG 系统的特征

一个合格的RAG系统能够有效地解决LLM的局限性，通过提供准确、相关和最新的信息，同时保持效率和用户信任

关键特征：

• 高检索质量：确保检索到最相关和最精确的块。这涉及优化分块策略、嵌入模型和索引结构。
• 事实依据和幻觉缓解：持续生成基于检索事实的响应，最大限度地减少不准确性。
• 上下文相关性和连贯性：提供的响应不仅事实正确，而且与用户意图相关，并以连贯的方式呈现。
• 可扩展性和效率：随着数据和用户流量的增长，系统表现良好，具有可接受的延迟和成本。
• 可维护性和时效性：允许轻松频繁地更新知识库，无需昂贵的再训练或显著停机。
• 透明度和可解释性：提供来源归属，理想情况下，还能提供对检索和生成过程的洞察。
• 对噪声和歧义的鲁棒性：能够优雅地处理不完善的查询和有噪声的检索文档。
• 适应性：能够适应不断变化的用户期望和特定领域的需求。

2）RAG 性能的关键评估指标

1.答案质量（Generation Quality）

这是最直观的指标，直接关系到用户体验。它衡量 RAG 系统最终生成的答案有多好。

• 相关性（Relevance）：答案是否与用户的查询高度相关？它是否准确地回答了用户的问题？
• 准确性（Faithfulness）：答案中的信息是否完全来源于提供的上下文？系统是否添加了任何不属于源文档的“幻觉”信息？这是RAG系统的核心优势，也是必须严格评估的指标。
• 完整性（Completeness）：答案是否包含了所有从上下文可以得出的相关信息？它是否遗漏了任何关键点？
• 流畅性与可读性（Fluency&Readability）：答案的语法是否正确、表述是否流畅、结构是否清晰易读？

2.检索性能（Retrieval Performance）

这是 RAG 系统有效性的基础。如果检索环节出了问题，后续的生成环节再优秀也无济于事。

• 命中率（HitRate）：在召回的Top-K文档中，是否包含了能回答问题的正确文档？这是一个二元指标（是或否），用来评估召回的有效性。
• 排名位置（Rank）：正确文档在召回列表中的排名位置如何？排名越靠前，说明检索越准确。一个好的RAG系统应该将最相关的文档放在Top1。
• 上下文相关性（ContextRelevance）：召回的文档片段有多相关？评估所有召回文档与查询的平均相关性。如果召回了大量不相关的文档，那会增加“噪音”，影响生成质量。

3.系统效率（System Efficiency）

合格的 RAG 系统不仅要准确，还要快。

• 延迟（Latency）：从用户提问到收到答案所需要的时间。这包括查询向量化、召回、重排和生成的所有时间。对于实时交互的智能客服，延迟是至关重要的指标。
• 吞吐量（Throughput）：系统在单位时间内能处理的请求数量。这决定了系统在高并发场景下的承载能力。
• 资源消耗（ResourceUsage）：系统在运行时所需的CPU、GPU和内存等资源。一个高效的系统应该在保证性能的前提下，尽可能节省资源。

4.稳健性与可扩展性（Robustness & Scalability）

一个合格的 RAG 系统应该能够应对各种复杂情况。

• 鲁棒性（Robustness）：系统在面对不同类型、不同风格的查询时（例如，口语化、长问题、复杂问题等），是否能保持稳定的性能？
• 可扩展性（Scalability）：随着知识库的不断增长（例如，从1000个文档到1000万个文档），系统的检索性能和响应时间是否能保持稳定？这主要取决于索引和向量数据库的性能。

提高RAG准确性

关键设计要点（把准确率做上去）

切块（Chunking）

• 300–800字符常见；图表/长条目用“父子文档”（child块检索、parent块作为上下文）。
• 重叠10–20%以防语义被截断；标题要与正文一起入块。

检索（Retrieval）

• Hybrid=向量+关键字往往最稳。
• Top-k不宜过大（常见8–20）；过大=噪声多，过小=漏召。
• 用Reranker（交叉编码器）精排前3–8条，召回准度会肉眼提升。

提示（Prompt）

• 明确“只基于以下资料回答；无法支持时要直说”。
• 要求引用来源（文档名+行/节），并说明“不引用=不得分”。
• 对分类场景用受限候选+结构化输出（JSON）。

模型与向量

• 尽量用与你语种/领域贴合的嵌入模型（中文/跨境电商可选多语种嵌入）。
• 向量库选型关注：延迟、并发、过滤条件（metadatafilter）、可扩展。

权限与合规

• 在检索层做权限过滤（只能看到有权看的块），避免“越权泄露”。

进阶玩法（当基础版跑通后）

• QueryRewriting：拼写纠错、同义词扩展、HyDE（先生成假想答案再检索）。
• Multi-hop/分步检索：先找定义，再找数据，再综合。
• Multi-vector/ColBERT：更细粒度的词-词交互，提高精排效果。
• GraphRAG：把实体与关系抽成图，适合多跳推理与纵览。
• 长上下文模型+压缩：先用“总结/抽取器”把证据压成要点再喂给生成模型。
• 缓存（Caching）：对高频问法、稳定文档做答案缓存，降本提速。

评估与监控（别跳过）

• 检索层：Recall@k、MRR、NDCG（看“该找的有没有被找回来”）。
• 生成层：Faithfulness（与证据一致性）、Correctness（答案对不对）、Conciseness（是否啰嗦）。
• 常用工具思路：构造带标准答案的评测集（含易混样本），离线对比不同切块/Top-k/重排策略；线上做A/B。
• 对“类目预测”特别关注：Top-1/Top-3、拒判率、审阅耗时；把错例回灌到类目卡。

RAG 与 Agent 的关系

RAG 是“知识工具”，Agent 是“调度与决策大脑”。

Agent 的能力很大程度上取决于它能调用和使用的“工具”。RAG 就是 Agent 可以使用的、用来处理特定“知识密集型”任务的强大工具。

工作流程

1.规划（Planning）：Agent 接收到用户指令，例如：“帮我分析下公司最新的销售报告，并总结出关键增长点。”

2.工具选择（Tool Selection）：Agent 意识到这个任务需要查阅内部文档，而它自己没有这些信息。这时，它会选择使用它的**“RAG 工具”**。

3. 工具执行（Tool Execution）：

• Agent调用RAG工具，将“公司最新的销售报告”作为查询输入。
• RAG工具启动其内部流程：分片、索引、召回、重排。
• RAG工具从公司的内部知识库（如SharePoint、Confluence）中检索出所有相关的销售报告片段。
• RAG工具将这些检索到的片段，连同原始查询，传递给一个LLM。

4. 结果解析与行动：

• LLM基于RAG提供的上下文，生成一份关于销售报告关键增长点的总结。
• Agent接收到这份总结，可能会进一步分析，或者直接将其作为最终答案返回给用户。

在这个过程中，RAG 并不是 Agent 的全部，而是 Agent 实现特定任务目标的有效手段之一。Agent 还可以使用其他工具来完成不同类型的任务，例如：

• 代码解释器：用于数据分析和图表生成。
• API调用工具：用于查询天气、发送邮件或执行外部命令。
• 网络搜索工具：用于获取最新公开信息。

多Agent协作中的RAG

在多Agent系统中，RAG可以实现：

• 知识共享：多个Agent共享同一个知识库
• 专业分工：不同Agent访问不同的专业知识库
• 协同学习：Agent通过RAG系统交换学习成果

总结：关系和区别

所以，你可以这样理解：Agent 是一个“全能型选手”，它拥有多个工具箱来完成不同的任务。而 RAG 就是其中一个非常重要的“专业工具箱”，专门用来解决 Agent 在执行任务时遇到的知识瓶颈。两者结合，能够让 Agent 变得更加聪明、强大、且能够应对现实世界中更复杂的挑战。

RAG 与 MCP 的关系

MCP（Model Context Protocol）是把数据源与工具“标准化接入 LLM/Agent”的开放协议——像给 AI 装了“USB-C”。在 MCP 下，RAG 的“资源（索引/搜索）”与“工具（检索、重排、摘要）”都可以通过统一接口暴露给模型/代理调用，降低集成成本并增强可观测性与安全性。

这让你能把多数据域（文件库、Git、工单、CRM、数据库）接成统一检索层，再由 Agent 调用实现跨源 RAG。

RAG 和 MCP 的关系可以从以下几个角度理解

RAG 是 MCP 的一个工具：MCP 的核心是让 LLM 调用工具。如果这个工具是用来进行文档检索的，那么它就是 RAG。因此，一个更高级的 Agent (智能体) 可以使用 MCP 协议，将 RAG 作为其众多工具之一，来解决需要知识检索的任务。

共同增强 LLM 的上下文：两者都旨在为 LLM 提供外部上下文，但方式不同。RAG 侧重于静态、非结构化的知识，而 MCP 更侧重于动态、结构化的实时数据和操作。

结合使用以获得更全面的能力：在实际应用中，RAG 和 MCP 常常被结合使用。例如，一个客服智能助手可能会：

• 使用RAG从公司的知识库中检索产品使用说明和常见问题解答。
• 使用MCP调用一个CRM系统的API，获取客户当前的订单状态和账户信息。
• 最终将这些信息整合起来，提供一个既包含通用知识又针对个人情况的个性化答案。

RAG在MCP框架中的角色

数据连接标准化

• MCP为RAG系统提供了标准化的数据接入方式
• 支持多种数据源的统一接入：数据库、API、文件系统
• 简化了RAG系统与不同数据源的集成复杂度

安全性增强

• 通过MCP协议管理访问权限
• 提供数据使用的审计跟踪
• 确保敏感数据的安全访问

可扩展性提升

• 支持RAG系统的水平扩展
• 便于添加新的数据源和知识库
• 实现跨系统的知识共享

总结

RAG 和 MCP 在 AI 生态中扮演着不同的角色。RAG 是一种特定的检索技术，用于增强 LLM 对非结构化文档的理解。而 MCP 是一种更通用的协议，用于让 LLM 能够与各种外部系统交互。

将它们结合起来，可以构建出功能更强大的 Agent，让 AI 系统不仅能知道（通过 RAG），还能行动（通过 MCP），从而解决更复杂、更现实的任务。

RAG在知识库中的作用

RAG在知识库中的作用是：将静态、庞大的知识库，转化为一个动态的、能够被大语言模型（LLM）高效利用的“活”知识来源。

简单来说，RAG 就像是为你的知识库安装了一个智能的“搜索引擎”和“翻译器”，它能让 LLM 轻松地从海量数据中找到答案，并以人类可理解的语言流畅地表达出来。

具体作用

1. 赋予知识库“可搜索性”和“可理解性”

传统知识库：传统的知识库（如PDF文件、维基百科、公司文档）是静态的、非结构化的数据，人类可以阅读，但机器无法直接理解其语义。

RAG的作用：RAG通过向量化技术，将知识库中的每个文档片段都转换成一个代表其语义的向量。这个向量就如同一个独特的“指纹”，让计算机能够理解和搜索文本的内在含义，而不仅仅是匹配关键词。这使得知识库中的信息变得可搜索、可索引，并且能够被LLM所理解。

2. 将知识库“武装”给 LLM

• LLM的局限：LLM本身没有访问外部知识的能力，它的知识仅限于训练时的数据。这导致它无法回答关于最新信息或私有数据的问题，并且可能出现“幻觉”（编造事实）。
• RAG的作用：RAG充当了LLM和知识库之间的“桥梁”。当用户提出问题时，RAG会主动从知识库中检索最相关的知识片段，并将这些片段作为上下文提供给LLM。LLM借助这些外部信息，能够生成准确、可靠且有事实依据的答案。这解决了LLM自身的知识瓶颈，让它能够利用一个外部的、可信的知识源。

3. 提高知识库的利用效率和价值

• 传统利用方式：在没有RAG的情况下，要想从一个庞大的知识库中找到答案，可能需要人工进行大量搜索和阅读。
• RAG的作用：RAG自动化了这一过程。它能够快速地从海量数据中精准定位到用户所需的信息，并直接将其提炼成一个简洁、完整的答案。这极大地提升了知识库的利用效率，将一个原本被动存储数据的“仓库”，变成了能够主动提供智能问答的“服务中心”。

总结

RAG 在知识库中的作用是变革性的。它将一个沉睡的、静态的知识宝库，转变为一个能够与 LLM 协同工作的动态、智能的知识助手。

通过 RAG，你的知识库不再仅仅是信息的存储地，而是能够：

• 实时更新，无需重新训练LLM。
• 准确回答，减少“幻觉”和错误。
• 高效利用，快速将知识转化为价值。

简而言之，RAG 是让知识库“活”起来的关键技术，它赋予了 LLM 访问、理解和利用外部知识的能力。

总结

RAG 是一种强大的 AI 技术，它通过检索外部知识库（如企业文档、网页）并将其作为上下文注入大型语言模型（LLM）的提示中，从而生成更准确、时效性更高、且无“幻觉”的答案。

相较于单纯使用 LLM，RAG 避免了模型知识陈旧和编造事实的问题，其答案可溯源且成本更低，特别适用于需要处理特定领域或私有数据的场景。

RAG 并非独立存在，它在更宏大的 AI 生态中扮演着关键角色：

在Agent中，RAG 作为一个核心工具，赋予 Agent 访问外部知识的能力；

而在MCP（模型上下文协议）中，RAG 则是其实现知识检索功能的一种具体方式。通过这种互补协作，RAG 极大地扩展了 LLM 的应用边界，让其从一个通用知识的“记忆者”转变为一个能够利用特定信息解决实际问题的“专家”。

本文由 @A ad钙 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务