当AI从“生成”走向“检索增强”，RAG（Retrieval-Augmented Generation）正成为连接知识库与智能交互的关键桥梁。它不仅是技术研究的热点，更在企业应用中展现出巨大潜力，尤其是在销售场景中，正在重塑客户沟通、内容响应与知识调用的方式。本文将从RAG的底层原理讲起，结合真实案例，深入解析其在销售助手中的实战应用路径。

当你问模型一个专业领域问题，它要么给你一个看似权威实则胡编的答案，要么给你说“可能、我猜测这块的技术是…“ 它自己都不确定

像这种还好，起码你知道它可能是错的，就怕它非常确定的说：这个就是xx，追溯于xx，由xx所发明… 但是！都是错的，乱说一通还非常笃定，这就非常容易将使用者带跑偏。

为什么要做RAG？

幻觉的诞生

要深入理解这个问题，我们需要澄清一个根本性的误解：大语言模型并非真正”理解”它所表达的内容，它学习的核心机制仅仅是从海量文本中提取词汇间的统计关联模式。

想象一下，当我们看到一个句子时，在GPT等大语言模型的”视角”中，这究竟是什么？

实际上，对它而言，这不过是一串毫无温度的数字编码。

模型会事先构建一个庞大的词汇映射表，将每个词汇转换为相应的数字标识符。每个句子在模型眼中都是一串神秘符号的数字序列。

大模型的学习过程就是通过分析这些已知的、合理的句子所对应的数字串，从中发现隐藏的内在规律。一旦掌握了这些模式，当给定一串数字时，它就能推算出接下来最有可能出现的数字是什么。

这听起来是有些不可思议，但这确实是当今所有大语言模型运行的根本原理：统计语言模型

统计语言模型的本质是：通过分析前文词汇的分布模式，借助深度学习的强大拟合能力，在见识过海量数据后，计算出最有可能紧随其后的数字编码，也就是对应的词汇。

它就像我们在用手机时打出一个字后输入法会推荐下一个字，通过学习天文数字般的文本数据，精确计算出词汇间的接续概率。

它不知道”心情”的真实含义是什么，但它清楚地知道”心情”这个词后面通常会接”愉悦”、”低落”、”不好”等特定词汇。我在这里刻意使用”数字串”这样的表述，是为了说明一个事实：

AI从未在这个真实世界中生活过，它自始至终都只是一台根据前序数字来预测后续数字的精密机器。

这就像观看皮影戏一样：

舞台后的艺人操控着各种道具，在幕布后创造出丰富多彩的故事世界，而观众看到的只是光影投射在白布上的二维轮廓。

AI就如同这样的观众，它从未接触过幕布后面的真实世界，只能通过分析这些平面影像的移动规律来理解和模仿”剧情”的发展。它通过学习这些”影像”的规律来模拟真实世界，并产生看似合理的语言续接。

大部分情况下，这种机制运转良好。但当遇到训练数据中罕见的”影像组合”，或者语境发生微妙变化时，问题就暴露出来了。

举个🌰：如果你问AI：

“请介绍一下孔子的《哈姆雷特》创作背景”

它很可能会一本正经地开始阐述这个根本不存在的作品。

我们都知道，《哈姆雷特》是莎士比亚的经典悲剧，而孔子是春秋时期的中国思想家，两者在时空上毫无关联。

但由于AI在训练过程中频繁接触到关于”经典文学作品创作背景”的讨论模式，当面对这样的错误组合时，它依然会按照既有的语言模式强行生成内容，编织出一个看似有理有据却完全虚假的解释。

当面对未知或错误的概念组合时，模型依然会基于统计规律强行生成内容

这就是AI幻觉。

模型的“幻觉”问题确实让人头疼——像GPT-4、Deepseek都会出现这样的问题。为什么后来大家都觉得Deepseek不好用了，就是因为脏数据太多了，各种幻觉问题频出…

模型越大，参数越多，我们越难控制它的输出是否准确。

那如果让模型查资料再回答，会不会就不乱说了？就像我们读书时考试，开卷总比闭卷稳妥吧？所以，RAG就是干这个的。

举个🌰，RAG让LLM在回答问题前先去“翻书”，从外部知识库中检索相关信息，再结合这些信息来生成答案。这就好比给模型配备了一个随身图书馆，遇到不懂的问题先查资料再作答，大大降低了“幻觉”的概率，但注意仅仅是降低，而不是解决，这个很重要。

那RAG到底是怎么工作的？它背后有哪些关键技术？实际应用中效果如何？又有哪些挑战和未来方向呢？

RAG是什么？

检索增强生成，让AI在回答问题之前先检索相关知识，再根据知识生成答案。

它是一种将信息检索和LLM相结合的新范式。就是给大模型接上一个外部“大脑”——知识库，当模型被问到问题时，先让它去知识库中“查资料”，找到相关的片段，然后再基于这些资料给出回答。

任何新技术的出现都不是凭空的，RAG也有自己的“前身”和演进过程。

早期探索

在RAG概念正式提出之前，开放域问答系统（ODQA）可以说是RAG的雏形。

比如IBM Watson系统，都是采用“检索+阅读”的两阶段流水线：

• 先通过搜索引擎从海量文档中检索出相关段落
• 再用阅读理解模型从中抽取或生成答案

这种“先检索、后生成”的模式已经体现了RAG技术的核心逻辑。不过早期系统也有局限，比如检索和生成是分开训练的，彼此无法交流，检索质量不高时生成也会跟着错。这些问题促使后来的研究者去改进。

技术突破

2017年Transformer架构横空出世，可谓是NLP领域的革命。

Transformer的自注意力机制让模型能够理解上下文，生成高质量的词向量表示。这直接推动了检索技术从传统的关键词匹配（稀疏检索）转向语义检索（密集检索）。

举个🌰，以前搜“汽车”只能找到带“汽车”这个词的文档，而语义检索能理解“汽车”和“车辆”是一回事，即使文档里没有“汽车”这个词，只要意思相关也能找到。

这大大提升了检索的相关性。当强大的生成模型（如GPT）遇到了智能的检索模型，RAG的诞生就水到渠成了。

RAG正式提出

2020年，Facebook AI（现Meta AI）的研究者Lewis等人发表了论文：

《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》

正式提出并命名了RAG框架。

这篇论文的核心贡献是提出了一个统一的端到端训练方法，把预训练模型的参数化记忆和外部知识库的非参数化记忆结合在一起。

举个🌰，就是让模型在训练时同时学习“检索”和“生成”两件事，而不是分开处理。这样检索器和生成器可以互相配合，一起优化。

RAG框架的提出标志着知识密集型NLP任务的一个新范式诞生。至此RAG的架构又有了很多不同方向的演变。比如：

• 高级RAG在传统流程基础上增加了查询改写、结果重排序等步骤来提升效果；
• 模块化RAG将系统拆分为检索、推理、记忆、生成等独立模块，更灵活可扩展。
• Agent式RAG，让模型像代理一样自主决定何时检索、检索什么，甚至多轮检索逐步逼近答案。
• 多模态RAG也开始出现，让模型不仅能检索文本，还能检索图像、表格等不同类型的数据。

我们正从一味追求“更大的模型”，转向构建“更聪明、更高效的混合系统”！

RAG标准架构和流程

RAG系统的基本架构可以分为两大阶段：离线索引阶段和在线推理阶段。

离线阶段负责准备知识库，在线阶段则是用户提问时实时检索并生成答案。

1. 离线索引阶段：知识库构建

离线索引阶段是在用户提问之前，就是在准备数据库的环节。

将海量的原始数据转化为一个高效可搜索的知识块索引，可以叫Chunk，也可以叫做小块。就是将投喂的数据（结构化&非结构化）分割成一个一个小体量

这一阶段通常包括以下几个步骤：

1. 数据收集：从各种数据源获取原始数据。这些数据源可以是文件系统里的文档、数据库中的记录，或者通过API抓取的网络数据等等。比如在电商场景中，我们可能加载产品手册、FAQ文档、销售话术、客户沟通记录等作为知识来源。
2. 数据分块：将长文档切割成较小的、语义相对完整的文本片段（chunk）。为什么要分块呢？因为一方面，大模型的上下文窗口有限，太长的文本塞不进去；另一方面，小块文本主题更集中，检索起来更精准。例如一本100页的产品手册，可以按章节或段落拆成若干段。不过分块也要注意别把一句话腰斩，否则会影响后续理解。
3. 向量化嵌入：使用EmbeddingModel将每个文本块转换成向量表示。嵌入模型就好比一个“翻译官”，把人类的语言翻译成机器能理解的数学向量。这样一来，意思相近的文本在向量空间中会离得很近，方便后续计算相似度。业界有很多成熟的嵌入模型可以选择，比如OpenAI的text-embedding-ada-002、Sentence-BERT模型，或者NVIDIA的多语言嵌入模型等。需要注意的是，索引文档和编码查询必须使用同一个嵌入模型，这样才能保证查询和文档在同一个语义空间中比较。
4. 向量存储：将生成的文本向量及其对应的原始文本一起存入向量数据库，并建立索引。向量数据库是专门为存储和快速查询高维向量而设计的数据库，支持ANN。举个例子：如果我们有上百万段文本向量，要找到和用户问题最相似的那几个，向量数据库可以在毫秒级完成，而不用傻乎乎地逐一比对每一个向量。常见的开源向量库有Pinecone、Milvus、Chroma、Weaviate等。通过这一步，我们就建立好了一个知识库索引：它就像图书馆的目录卡，记录了每本书的位置，只不过这里的“目录”是向量形式的，可以按语义快速查找。

经过离线阶段的处理，你可以理解这批数据就变成了随时待命的知识库。当用户提问时，系统就能在这个知识库里快速检索答案。

2. 在线推理阶段：检索与生成

在线推理阶段是当用户提交查询时，会先在知识库中找到相关知识，并生成准确的回答。

这个阶段也可以进一步细分为三个关键步骤：

1. 检索：系统接收到用户的问题后，首先将问题用与索引时相同的嵌入模型转换成向量。然后利用这个查询向量在向量数据库中进行相似性搜索，找出与问题语义最相关的Top-{K}个文本块。举个例子，用户问这款手机有防水功能吗？，系统会在知识库中找到和“手机防水”意思最相关的几个段落，比如产品规格里关于防水等级的说明、常见问题里的相关解答等。这一步相当于让AI去知识库中“翻书”，把可能有用的资料找出来。
2. Query增强：将检索到的K个文本块作为上下文信息，与用户的原始问题拼接在一起，形成一个增强提示。把问题和找到的资料一起喂给大模型看。例如，提示可能是这样的：用户问：‘这款手机有防水功能吗？’已知信息：‘[段落1]…[段落2]…’根据以上信息，请回答用户的问题。通过这种方式，模型在回答时就能看到相关资料，而不再是“两眼一抹黑”地凭空作答。
3. 生成：将增强提示输入大型语言模型（LLM），让模型基于自身的语言能力和提供的上下文信息，生成最终的回答。模型会仔细阅读用户的问题和提供的资料，然后组织语言给出一个人类可读且有事实依据的答案。比如上面的例子，模型可能回答：这款手机支持IP68级防水防尘，可在1.5米深水中浸泡30分钟。这个答案显然是从知识库资料中来的，而不是模型自己瞎编的。

以上就是RAG在线推理的完整流程：检索 → 增强 → 生成。简单来说，就是先搜后答。

通过这个流程，用户的问题最终被转化为一个有根有据的答复。

需要强调的是，RAG系统的效果取决于各个环节的紧密配合。正如有句话所说：“RAG的性能如同一条环环相扣的链条，其最终强度取决于最薄弱的一环。”哪怕你用了最牛的大模型，如果检索器找错了资料，模型也会给出错误答案；反过来，检索器找到了正确资料，但如果分块时把关键信息截断了，模型也无从获取。所以，构建一个高性能的RAG系统，需要从数据预处理、索引构建到模型生成每一步都精心打磨，任何一个环节掉链子都会影响最终结果。

了解了RAG的工作原理后，我们再看看RAG系统通常由哪些核心组件构成，以及每个组件扮演什么角色。

3. RAG的核心组件

一个完整的RAG系统由多个模块协同工作，主要包括以下几个核心组件：

• 数据源：数据的来源。RAG可以接入多种类型的数据，既包括非结构化数据（如PDF、Word文档、网页、纯文本等），也包括结构化数据（如数据库表格、知识图谱），甚至半结构化或多模态数据（如包含图片、表格的混合文档，或者独立的图像、音频等）。不同的数据源需要不同的处理方式，比如结构化数据可能需要用Text-to-SQL等技术将其纳入检索，多模态数据需要用多模态模型处理。总的来说，数据源决定了RAG系统“知道”哪些知识。
• 数据加载与分块模块：负责从数据源提取数据并进行预处理。它首先读取原始数据（比如解析PDF、爬取网页），然后将长文档切分成合适大小的文本块。分块策略很重要：块太小可能丢失上下文，块太大又影响检索效率和模型输入长度。理想的分块是让每个块包含一个相对独立的语义单元，例如一个段落、一节内容等。此外，这个模块还可能对文本进行清洗（去除乱码、噪音）和标准化处理，为后续步骤做好准备。
• 嵌入模型：将文本转换为向量。嵌入模型的选择会直接影响检索的准确性。目前常用的嵌入模型大都是基于Transformer的预训练模型，能够生成高质量的语义向量表示。例如，OpenAI提供的text-embedding-ada-002模型在英文和多种其他语言上都表现很好，而像sentence-transformers这样的开源库也提供了多语言的嵌入模型。嵌入模型的一个关键要求是一致性：无论是索引文档还是编码用户查询，都必须使用相同的模型，这样向量空间才有可比性。
• 向量数据库：用于存储向量索引并执行快速检索。向量数据库与传统数据库不同，它的核心功能是在高维向量空间中进行ANN。当我们有海量向量时，直接计算每个向量与查询的距离会非常慢，而向量数据库通过建立特殊的索引结构（如树结构、图结构），可以在亚线性时间内找到最相似的向量。例如，在拥有数百万文档向量的系统中，向量数据库可以在几十毫秒内返回最相关的几个结果，从而保证RAG系统的实时性。目前业界有多种向量数据库实现，包括开源的（如Milvus、FAISS、Elasticsearch向量搜索）和云服务（如Pinecone、Redisearch等）。选择合适的向量库并根据数据规模调整参数，是RAG系统工程中的重要一环。
• 大型语言模型（LLM）：通常我们会选择一个强大的预训练语言模型作为生成器，如OpenAI的GPT-3.5/GPT-4、Anthropic的Claude，或者开源的LLaMA系列模型等。LLM的作用是在接收到增强提示后，利用自身的语言理解和生成能力，把检索到的信息整合成通顺的回答。一个好的LLM应该既善于理解上下文（能够从提供的资料中提炼关键信息），又善于表达（生成自然流畅、符合人类语言习惯的答案）。需要注意的是，LLM本身并不存储额外的知识，它主要依赖提示中提供的信息来作答，这正是RAG设计的初衷——让模型做它擅长的语言处理，而把知识部分交给外部知识库来提供。
• 提示构造与后处理模块：这部分虽然在上面的流程中没有单独列出，但实际很重要。它负责将检索结果和问题组合成合适的提示格式，并在模型生成后对答案进行必要的处理。例如，提示构造需要考虑如何组织资料和问题，使模型容易理解（可能需要加入一些指令，如“根据以下资料回答问题”）。后处理可能包括对答案进行格式美化、过滤掉不必要的内容，或者在答案中引用资料来源以增加可信度（有些RAG系统会在回答末尾附上信息出处）。

以上组件各司其职，又相互配合，共同构成了RAG系统。数据源和向量库就像一个大型图书馆，嵌入模型是图书管理员，根据语义给每本书贴上“坐标标签”，检索模块则是读者的助手，能根据读者提问快速找到相关的几本书，而LLM就像一位博学的解说员，拿到书后为读者讲解其中的内容。这一切协同运作，才能产生我们最终看到的准确回答。

我们通过一个实际案例，看看RAG是如何在电商售前场景中落地应用的，以及它带来了哪些价值。

RAG在电商售前场景的实战应用案例

我们以电商售前场景为例，介绍一个AI销售助手的项目。看一下如何利用RAG技术，帮助电商公司的销售团队更好地与客户沟通，提高销售效率和成交率。

场景背景

某大型电商公司的销售团队每天要面对大量客户咨询，内容涉及产品功能、价格、物流、售后等方方面面。销售人员经常需要在公司内部的产品手册、FAQ文档、历史聊天记录中查找信息来回答客户。不仅耗时，而且容易出现信息不一致或遗漏的情况。

新入职的销售对产品不熟悉，回答客户问题时信心不足，影响客户体验。公司希望引入AI助手来自动回答客户提问、生成销售话术，从而减轻销售负担、提升客户满意度。

RAG方案设计

针对背景&痛点，我们要做一个AI销售助手。方案的大体思路是：将公司的产品知识、销售话术等建立知识库，当客户提问时，AI助手先检索知识库找到相关答案片段，再结合这些片段生成自然语言回复。这样，AI就能像资深销售一样，对答如流地解答客户疑问。

知识库构建

首先，团队整理了丰富的知识来源，包括公司内部文档和资料、CRM系统数据、销售过程数据以及市场和外部数据等。这些数据经过数据处理流程，包括采集、清洗、结构化、存储和更新等，最终构建成一个全面且准确的销售知识库。

在收集环节，手机了公司所有产品的详细资料（规格、功能、卖点等）、常见问题解答（FAQ）、销售话术模板、成功案例、合同样本等，作为知识库的核心内容。

同时，还接入了公司的CRM系统，获取客户的基本信息、历史沟通记录、购买记录等数据。这样AI助手在与客户对话时，可以了解客户的背景（比如是否老客户、之前问过什么问题），从而提供更贴心的回答。

还有就是销售日常工作中的邮件往来、日程安排、聊天记录等也被纳入数据来源，因为这些能反映客户需求和关注点。

也可以引入了一些外部数据，如行业报告、竞品信息、社交媒体上关于客户的舆情等，以便AI掌握更全面的市场动态。

所有这些数据通过ETL和数据清洗流程整合到一起，构建出一个销售知识库。

知识库采用知识图谱+向量数据库的方式存储：既用知识图谱把产品、客户、问题等概念及其关系表示出来，方便复杂查询推理，又用向量数据库存储文本片段的向量表示，用于语义检索。

检索机制

在检索环节，系统采用混合检索策略来提高准确性。

首先，对于用户的问题，先通过关键词匹配（例如基于倒排索引的BM25算法）进行初步筛选，快速缩小范围。

比如客户问这款手机有什么颜色？，关键词检索会先找到包含“手机”“颜色”等词的文档段落。

然后，再在这些候选段落中，使用向量语义检索（如Sentence-BERT或OpenAI Embeddings模型）计算语义相似度，找到意思最相关的片段。

这样做的好处是兼顾召回率和准确率：关键词检索保证了包含明确术语的文档不会漏掉，向量检索则补充了那些关键词不同但语义相关的内容。

并且可以采用Re-ranking。先由向量检索返回Top-{K}个候选片段，然后用Rerank模型对这些片段进行二次打分排序，会让排序结果更准确。

你可以理解为Top-{K}这一步更像是简历初筛，Rerank是面试。

生成与响应

有了检索到的相关知识片段，接下来由生成模型来组装答案。

选择一个LLM作为生成引擎，并结合PE来引导模型输出。

提示模板通常包括：

指令（告诉模型要回答客户的问题）

上下文知识（检索到的资料片段）

客户的问题（例如：请根据以下产品说明回答客户的问题。产品说明：‘[资料片段]’。客户问题：‘[问题]’）

模型收到提示后，会将客户的问题与资料片段结合起来理解，然后生成一个自然流畅的回答。

生成过程中，可以进行策略优化：比如控制回答的语气和风格，使其礼貌专业且易于理解，避免使用生硬的机器语气或过于技术化的术语；

又如根据客户的身份和对话历史进行个性化回答，如果知道客户是老用户，可以在回答中提及他之前购买的产品以示关注。

模型生成回答后，系统还会对输出进行校验和过滤：检查是否遗漏了资料中的关键信息、是否出现不当言论，或者有没有泄露公司机密。如果发现问题（比如模型生成了错误的数据），系统会让模型根据知识库再生成一次，或者直接从资料中提取正确数据插入回答。

训练了一个小型判别模型，给生成的回答打分，分数过低的就要求模型重写。通过多轮校验，确保最终回复给客户的内容准确无误、语气恰当、符合公司规范。

交互流程

AI销售助手可以嵌入到多种渠道中与客户交互，例如公司官网的在线客服聊天窗口、企业微信/钉钉等IM工具中的机器人，或者作为销售的侧边栏助手。

当客户发送一条消息过来，系统后台立刻触发上述RAG流程：

先检索知识库找到答案，再生成回复，最后将回答呈现给客户。

整个过程通常在几秒内完成，客户几乎感觉不到延迟。

如果客户的问题比较复杂，AI助手还能通过多轮对话逐步澄清需求。

例如客户问我想给父母买手机，有什么推荐？

AI可能先询问您父母主要用手机做什么？预算大概多少？

待客户回答后，再检索符合条件的产品资料进行推荐。

这种对话管理能力由系统的对话状态跟踪模块实现，它可以记住多轮对话的上下文，确保AI的回复连贯，且有针对性。

结语

回顾全文，我们从大模型的“幻觉”问题引出了RAG，介绍了RAG的概念和由来，剖析了它的系统架构和工作流程，并通过电商售前的案例见证了RAG的实战价值。

可以看到，RAG为解决AI的知识瓶颈和可靠性问题确确实实是提供了一条切实可行的路径。

但RAG就一定是最好的选择么？并不是。有的场景可以用RAG，但是有的场景反而用微调会更合适。主要还是看场景。

我们正从一味追求更大的模型，转向构建更聪明的系统。RAG是这个转变的缩影——它没有试图让模型记住全世界的知识，而是教会模型如何去利用外部的知识。

既提升了性能，又降低了成本，还增强了可控性和可解释性。

面向未来的话，，随着Agent技术、多模态技术的融入，RAG系统架构其实是有很多不同类型的。这里就不再展开讲了，可以去探索一下Agentic RAG、多模RAG以及知识图谱的RAG。其实不能说哪个更好，还是要和具体业务做结合。

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

题图来自 Unsplash，基于CC0协议

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