深度｜基于大模型的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算法（倒数排序融合）的介绍。文章：

https://towardsdatascience.com/forget-rag-the-future-is-rag-fusion-1147298d8ad1

02

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

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

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

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

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

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

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

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

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

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

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

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