引言

大语言模型很会聊天，但它有两个弱点：容易胡编、知识不更新。而在电商客服、企业知识问答、医疗咨询等现实业务中，我们迫切需要模型能依据最新、真实的资料来给出准确回答。这时，RAG（Retrieval - Augmented Generation，检索增强生成）技术便应运而生，它就像给大模型插上了一块可以实时更新的 “外脑”，让模型具备了 “随用随查” 的能力。

一、RAG 的基本思想

• 语言模型：擅长表达，但记忆有限。

• 检索引擎：擅长找信息，但不会解释。

• RAG：把两者结合。用户提问 → 资料检索 → 模型用资料回答。

    一句话概括：模型不再死记硬背，而是边查边答。

二、RAG 的核心流程

1.数据准备与切分（Chunking）

为什么要对原始文档进行切分呢？因为原始文档往往比较长，而当前主流AI模型（如GPT-4）通常有32k tokens的上下文限制，这超出了模型的处理能力。

一般会把文档切成 200–800 tokens 的小块，并且要保证每块都保持语义完整。比如一篇关于某款智能手机的详细介绍文档，我们可以把它切成小块，每块分别介绍手机的一个功能，像摄像头功能、电池续航、处理器性能等，这样既符合切分长度要求，又保证了每块语义的完整性。

同时，给每块加上标签，比如来源（是来自官方网站的产品介绍，还是用户评价）、更新时间、类别（属于功能介绍还是价格信息）等，方便以后在检索时进行过滤。

2.向量化（Embedding）

向量化就是把文本转成 “语义指纹”—— 高维向量。语义相似的内容，反映在向量上就是距离更近。

比如，你写代码时，会遇到这样一行：

embedding = model.embed("跑鞋支持 7 天无理由退货")

输出结果是一串几百维的数字，比如：

[0.23, -0.98, 0.45, … , 0.11]

这就是 向量表示。

• “能退货吗？” → 向量 [0.21, -0.95, 0.47…]（接近上面的“退货政策”向量）

• “能换颜色吗？” → 向量 [0.83, -0.10, 0.05…]（距离就远了）

这样，用户问“能退货吗”，系统就能在向量数据库里，找到最接近的文本块：

开发时要注意：

• 切分粒度（chunking）：FAQ、政策、文档要切分成合理大小的块（比如 200~500 字），才能让向量表示足够准确。

• 模型选择：

  • OpenAI text-embedding-3-small：便宜，快，适合通用。

  • bge-large-zh：中文场景更强，电商客服常用。

  • 本地模型（如 m3e）：省钱，但需要显卡。

3.向量数据库与检索

所有通过向量化得到的语义指纹都会存入向量库，常见的向量库有 FAISS、Pinecone、Milvus 等。FAISS 是 Facebook 推出的，在处理大规模向量时性能较好；Pinecone 是一款云原生向量数据库，使用起来比较方便；Milvus 则是一款开源的向量数据库，灵活性较高。

当用户提问时，系统会先把问题进行向量化处理，然后在向量库中寻找与问题向量距离最近的片段。常见的做法是 top - k 检索，比如取最相关的 5 条片段，这样既能保证有足够的参考信息，又不会因为信息过多而影响后续处理。

4.增强（Augment）

模型自己不会主动去查数据库，需要我们把检索到的结果拼进 Prompt 中。

例子：
用户问：“这双跑鞋能退吗？”向量检索返回 FAQ 里的知识块：“跑鞋支持 7 天无理由退货。”

增强后的 Prompt 可能是这样：

• 你是电商客服。以下是退货政策：

  【跑鞋支持 7 天无理由退货。】

• 用户问题：这双跑鞋能退吗？
• 请严格根据退货政策回答。

结果：模型回答 —— “可以，这双跑鞋支持 7 天无理由退货。”

常见的拼接方式有直接拼接、摘要后拼接、强制引用来源等。

直接拼接就是把检索到的片段原封不动地放进去；摘要后拼接是先对检索到的片段进行总结，再放进 Prompt；强制引用来源则是在拼接时明确指出每个片段的来源。不同的拼接方式各有优缺点，直接拼接信息完整但可能冗余，摘要后拼接简洁但可能丢失部分信息，强制引用来源则有利于后续的溯源和验证。

增强的目标是让模型在回答问题时有足够的上下文支撑，从而避免胡编乱造。

5.生成（Generation）

模型会根据 “用户问题 + 检索片段” 生成最终的答案。一个好的设计是，当检索到的资料不足以回答用户问题时，模型要学会说 “不知道”，而不是强行编造答案。

在一些高级场景里，模型还能调用 API，比如在电商客服场景中，当用户询问某件商品的库存时，模型可以调用库存查询 API，获取实时库存信息后再回答用户。

三、RAG 的优势

知识实时性

当有新的文档更新时，只需要将新文档按照前面的流程进行处理，存入向量库，系统就可以立刻使用这些新信息来回答问题。比如在电商平台，当有新产品上线时，只需将产品信息更新到数据库，RAG 系统就能让客服模型立刻掌握新信息，准确回答客户问题。

领域覆盖广

RAG 不依赖模型内部的知识，只要有相关的资料，它就可以在相应的领域发挥作用。无论是医疗、法律还是金融等专业领域，只要准备好该领域的资料，RAG 就能让模型基于这些资料进行回答。

成本低

相比于训练或微调整个模型，RAG 的成本要低很多。它不需要对模型本身进行大规模的修改，只需要做好数据的准备、切分、向量化等工作，以及搭建好检索和生成的流程即可。

可追溯

RAG 生成的答案可以指向原始文档，便于审计。如果对某个答案有疑问，可以通过追溯找到对应的原始资料，查看答案的依据是否可靠。

四、常见挑战

切分粒度

切分粒度是一个比较棘手的问题。如果切得太碎，可能会导致信息丢失，比如一个完整的产品功能介绍被拆分成多个小块后，每个小块都无法完整表达该功能；如果切得太大，又会包含很多无关内容，影响检索的准确性，增加模型处理的难度。解决办法可以是根据文本类型和业务需求调整切分粒度，对于逻辑性强、内容连贯的文本，可以适当切大一些，对于信息点分散的文本，可以切小一些。

embedding 模型选择

不同的语言和领域，对 embedding 模型的要求不同。有些模型在通用语言处理上表现较好，但在特定领域，如医学、法律等，可能表现不佳。因此，需要根据实际的应用场景选择合适的 embedding 模型，必要时可以对模型进行微调，以提高其在特定领域的表现。

检索结果冗余

在进行 top - k 检索时，如果 k 值设置得太大，可能会导致检索结果冗余，大量的信息会塞爆模型的上下文，影响模型的生成效果。可以通过优化检索算法，提高检索的准确性，减少冗余信息，或者合理设置 k 值，在保证信息足够的前提下，尽量减少冗余。

幻觉问题

即使有资料作为参考，模型也可能会编造信息，也就是出现幻觉问题。这可能是因为模型对资料的理解不够透彻，或者在生成过程中受到了其他因素的干扰。解决办法可以是加强对模型生成过程的监督和约束，比如让模型在生成答案时明确指出哪些内容是来自资料，哪些是自己的推断，或者通过增加训练数据，提高模型对资料的理解和应用能力。

五、进阶方向

混合检索

混合检索是结合关键词检索和语义检索的优势。关键词检索可以快速找到包含特定关键词的内容，语义检索则能理解文本的含义，找到语义相关的内容。将两者结合，可以提高检索的准确性和全面性。

重排（Rerank）

重排是先通过粗筛得到一批可能相关的片段，然后再进行精筛，对这些片段进行重新排序，选出最相关的几个片段。这样可以进一步提高检索结果的质量，让模型基于更相关的信息进行生成。

Agent 化

Agent 化是让模型不仅能回答问题，还能采取行动。比如在电商客服场景中，模型不仅能回答用户关于产品的问题，还能调用库存查询 API 查库存、提交工单等，为用户提供更全面的服务。

评估与监控

上线后，需要对 RAG 系统进行评估和监控，包括准确率、延迟、grounding rate（答案与检索资料的匹配程度）等指标。通过评估可以了解系统的性能，发现存在的问题，进而进行优化；监控则可以实时掌握系统的运行状态，及时处理异常情况。

总之，RAG 技术为大模型在实际业务中的应用提供了一种有效的解决方案，它让大模型具备了 “带外脑” 回答问题的能力。虽然目前还存在一些挑战，但随着技术的不断发展，RAG 的性能会不断提升，应用场景也会越来越广泛。