基于大模型的RAG应用中的四个常见问题及方案探讨

RAG（检索增强生成）是构建大模型企业应用的一种常见解决方案。其基本思想是通过语义搜索，在大模型输入时携带企业私有知识库中相关的上下文，从而让大模型在理解企业私有知识的基础上输出结果。目的是解决以下问题：

• 弥补通用模型在企业私有知识上的不足

• 降低大模型存在的幻觉问题，减少胡编乱造

• 无需通过代价高昂的微调即可实现一定程度的“模型私有”

• 实现简单，可适应私有知识的快速迭代与变更

• 能够在大模型输出时给出原文引用

RAG或许是大模型在企业应用方向上最快落地的解决方案之一。其应用场景与价值明确，技术上易于理解且相对成熟。借助LLM（大模型）、Embedding（嵌入模型）、Vector Store（向量数据库）、Document Splitter（文档切割）几个核心技术的组合，能够在较快的时间内用相对低廉的成本来实现一个基本可用的RAG应用。

不过，正如当前绝大部分的大模型应用，构建能够真正投入生产的RAG应用也并非像构建一个原型那样简单。实际的用户需求往往是复杂多变的，特别在企业应用场景中往往有着有更高的一致性与准确性的要求。当我们真正以生产级应用的要求来评估一个RAG应用时，更多的问题就会体现出来。

本文分两篇来重点探讨RAG应用构建时的四个常见问题：

• **语义检索的精度问题
  **

• **基于上下文理解的知识检索
  **

• 多模态内容的处理

• RAG应用输出的质量评估

01

语义检索的精度问题

RAG应用输出质量的最关键的一步是能够借助向量检索出与用户问题语义最相关的知识“块”，然后交给LLM进行理解与输出。这里的知识检索是通过对知识的向量化存储并索引以及向量距离的算法来完成。因此影响这个检索结果的相关性即向量召回精度的因素就包括：

• 被索引的知识内容质量

**即原始知识经过分割后的知识块的粒度与语义的清晰度。**事实是，拆分后的知识块所表达的语义越单一、越清晰、越完整，粒度越小，其越容易被精确的检索到。因此，我们在设计知识分割的算法时，需要对内容与粒度做更精确的控制与测试，特别是对于Word/PDF/Html这类没有清晰内容结构的数据；而相对来说，一个结构化的Q/A格式的Excel/CSV文档处理会更简单，比如你可以直接针对问题部分进行索引。

• 基于相似向量检索出知识块的算法

最简单的方法当然是直接检索出相似向量的原始数据块。但是这里的问题是：**一个数据块语义捕获的精准性与其携带上下文信息的完整性往往是矛盾的。**通常来说，包含的内容越少越单一，语义捕获精准度越高；但是由于内容太少，其能携带的上下文信息就越少。那么如何在两者之间取得平衡呢？

• 生成向量的嵌入模型质量

由于向量的生成需要依赖于嵌入模型，无论是利用开源的中文嵌入模型，还是百度或者OpenAI的嵌入模型，不同模型的嵌入质量是存在差异的。应用开发者应尽量使用对中文语义更友好更丰富的嵌入模型。

• 用户输入问题的质量

这是决定检索质量的另一个侧面，即用户输入的问题。与嵌入知识的质量类似，输入问题的表达越完整、越清晰、歧义性越小，那么检索出相关知识的精度就会越高。一个过于简单或者模糊的问题可能会检索出不相关的知识，从而影响输出质量。

下面介绍常见的三种提高向量召回即语义检索精度的方案。这些方案既可以借助已有的LLM开发框架，比如LangChain，也可以自行实现优化算法。

【“父子”块方案】

在知识分割的时候，同时分割成小块（子块）与大块（父块），小块用来做嵌入与索引，确保语义检索更精确；大块通过小块关联获得，确保包含更多的上下文信息。从而在向量召回的精度与上下文的丰富性之间取得平衡。其实现的概念架构如下（注意大块不做嵌入）：

基于这种方案的用户问答处理过程为：

1. 用户输入问题

2. 对用户输入问题生成embedding向量

3. 通过输入问题向量做语义检索，获得N个最相似的小块

4. 通过相似块的元数据信息，访问关联的大块内容

5. 将包含更多上下文的多个大块组装到Prompt中，交给大模型理解与输出

如果你对LangChain有所了解，推荐参考其ParentDocumentRetriever的实现。

【多向量检索】

通过对分割后的知识块做进一步处理，使得在嵌入时生成更多的向量，从而能够包含更丰富的语义信息，使其能够在检索时更容易被捕获，提高知识块被召回的精度。

对分割的知识作进一步处理的常见方式有两种：

• **假设性问题生成。**即根据知识块借助于大模型生成更多的假设性提问或者相似问题，这些生成的问题与原知识块一起嵌入。

• **知识摘要生成。**即根据知识块借助于大模型生成更具提炼性与总结性的知识摘要信息，并与原知识块一起嵌入。

我们结合上述的父子块方案，一个更完善的实现架构如下：

基于这种方案的问答过程与上述父子块方案中的描述完全一致。

【多查询检索】

相对于上述两种方案侧重在提高知识向量化的语义精准性与丰富性，该方案则侧重在输入侧：基于用户的输入问题，首先借助于大模型从不同的角度来生成多个补充输入问题，然后使用生成的多个问题同时语义检索，并采用合适的算法对多个问题检索的结果进行合并与重新排序，最终获得最相关的知识块。

这种方案的原理来自于我们在日常提问时的问题往往具有一定的局限性。比如表达的范围太宽泛，导致无法获得更精准的结果（如：“新办企业如何设立税户？")；或者表达的范围太狭小，导致无法获得更全面的结果(如：“新办企业设计税户需要带哪些公司资料”）。因此，通过生成多个不同角度或者视角的问题（如：“新办企业设立税户需要携带哪些资料”，“新办企业设立税户的办理流程是怎样的”，“新办企业设立税户可以在哪些渠道办理”），**来获得更丰富的相关知识结果集。**其基本实现架构如下：

这种方案的实施点是在用户问题侧，因此用户问答的处理过程变化为：

1. 用户输入问题

2. 借助大语言模型与Prompt，生成用户问题相关的多个不同视角的问题

3. 使用生成的这些问题进行并行的语义检索，并对多个问题检索的结果通过算法进行重新排名，得出最相关的知识块

4. 根据相关知识块访问关联的大块（如果需要），并交给大模型进行理解与最终输出

由于这种多查询检索的方案在用户使用侧进行优化，因此也会带来一些可能会影响用户感知的副作用，实际应用时需要权衡：

• 可能导致过于啰嗦冗长的输出：由于对输入进行了多角度扩展，因此对应的输出内容也会增加。

• 可能会导致响应性能下降：由于该方案是在用户提问过程中实施，因此生成多个不同角度的问题可能需要一定的时间代价。

• 可能导致上下文窗口溢出与成本升高：过多的输入问题及其召回的相关知识，会带来输入大模型的上下文信息过多，要小心窗口的溢出及成本升高。

关于对多问题检索出的结果排名算法，即如何通过算法进行重新的统一排名，进而获取最终关联的top_K。可以参考以下文章中的RRF算法（倒数排序融合）的介绍。

02

基于上下文理解的知识检索

我们在演示环境进行RAG应用的测试时，往往会针对已有的私有知识库进行针对性的提问，测试向量的召回及其精准度，这时候往往都能收到不错的效果。但是在实际应用时，使用者的输入往往是无法预测的，很多时候会需要结合当时的上下文理解后，来召回私有知识库的关联内容，否则将无法达到预期的效果。

比如下面这样一个问答过程，假设我们已经很好的对私有的知识库进行分割、丰富与向量化存储，我们期望大模型能够在回答问题时优先基于召回的私有知识来理解与回答：

**这里的问题在于最后的问题“详细介绍下第六项”。**很显然这个问题是一个有着明确参考上下文环境的问题（类似的问题形式还比如：上一个问题是“请简单介绍下xxxx产品的参数“，下一个问题是”那它有什么优缺点“），简单说：当一个输入问题需要基于上下文来理解其真实含义，或替换其中的一些指示词时，那么就不能直接用这个输入问题来进行语义的检索与召回，否则会引入不相关的召回内容，导致无法回答或者回答错误。

一个可行的解决办法是：在进行检索之前，优先通过大语言模型对输入问题进行完善与优化，填充必要的上下文信息或者转换成新的语义完整的问题，再基于新的问题进行知识检索。

比如上文的问题会被转化为：

详细介绍下个人所得税专项附加扣除中的赡养老人项目

很显然，基于这样的输入问题进行语义检索，则可以获得更加精准的结果。当然，这个转换需要也借助于大语言模型来完成：输入本轮的用户问题与对话历史，并借助类似如下的提示词，来要求大语言模型进行问题完善与转化：

你是一个理解用户问题的智能助手。你会根据对话历史，对本轮用户提问进行完善，并输出完善后的问题；如果没有对话历史或者不需要完善，请直接输出原用户问题。要求：  
1. 不要输出空问题  
2. 任何时候都不要直接回答问题  
3. 不要编造问题和改变语义  
例1：  
========  
用户历史提问：北京是哪一个国家的城市？  
本次用户提问：那纽约呢？  
完善后的输出：{"new_question":"纽约是哪个国家的城市？"}  
==========  
例2：  
========  
用户历史提问：个人所得税怎么计算？  
本次用户提问：年收入100万，帮我计算下？  
完善后的输出：{"new_question":"年收入100万，请帮我计算下个人所得税"}  
==========  
请用JSON格式输出完善后的问题，不要有任何多余说明。注意new_question不能为空。

通过这种方式，我们可以测试完善后的效果如下，可以看到基于完善后的输入问题召回相关知识后，应用可以很好的输出期望的结果：

当然，在实际测试中，我们也发现一些大模型的不确定性带来的问题，比如有时大模型会倾向于直接回答问题而非优化原问题；或者一些无需优化的闲聊式问题会被优化成业务问题等。因此，在实际上线之前，需要根据使用的大模型更精确的优化提示词，来减少模型的输出不确定性。

在下篇中，我们会介绍RAG应用中对多模态内容的输入输出处理，以及对RAG效果的批量评估方法。

可能大家都想学习AI大模型技术，也想通过这项技能真正达到升职加薪，就业或是副业的目的，但是不知道该如何开始学习，因为网上的资料太多太杂乱了，如果不能系统的学习就相当于是白学。为了让大家少走弯路，少碰壁，这里我直接把全套AI技术和大模型入门资料、操作变现玩法都打包整理好，希望能够真正帮助到大家。

👉AI大模型学习路线汇总👈
大模型学习路线图，整体分为7个大的阶段：（全套教程文末领取哈）

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉大模型实战案例👈
光学理论是没用的，要学会跟着一起做，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

👉大模型视频和PDF合集👈
观看零基础学习书籍和视频，看书籍和视频学习是最快捷也是最有效果的方式，跟着视频中老师的思路，从基础到深入，还是很容易入门的。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓