“ RAG最终的评判标准只有一个——召回精度，RAG所有的技术都是围绕着怎么更快更准确的召回数据。”
RAG增强检索的核心指标只有一个——召回准确率；对于RAG技术来说，最重要的事情就是其召回数据的准确性；而怎么提升其召回准确率，方法只有两个，一个是左侧增强，一个是右侧增强。
所谓的左侧增强就是文档处理处理，怎么更好的处理复杂文档；而右侧增强就是召回侧的召回策略。
今天，我们就来讨论一下RAG的召回策略问题。
RAG的召回策略
数据召回本质上就是数据查询的一种方式，RAG比较特殊的一点就是不仅仅支持传统的字符匹配检索，同时支持基于向量计算的语义检索方式。
对RAG技术刚入门的人来说，召回方式很简单；不就是把用户问题通过嵌入模型进行向量化，然后把向量化的结果去向量数据库中进行匹配即可。
这种方式虽然没错，但其效果往往却不尽人意；因此，在企业级应用中会有更多的召回策略。
今天，我们就来列举几个常见的召回策略。
意图识别
对RAG应用来说有一个非常不可控的因素就是——用户；因为没人能控制用户的输入行为，因此这里就会有一个问题。就是用户的提问很不专业，比如说可能存在错别字，词不达意，或者一堆废话的长篇大论。
由于上述原因就会导致一个问题，由于用户的意图不清晰，导致进行语义匹配时，无法准确命中目标，甚至无法召回数据；这也是为什么有些新手会遇到明明库中有数据，但获取的结果却是空的。
因此，在用户提出问题时，我们首先要做的并不是直接embedding，然后进行相似度计算；而是应该把用户的输入提交给模型，让模型去优化用户的问题，以此来获取更精确的问题，然后提升召回准确度。
问题分解成多个子问题
当然，只对用户问题进行优化虽然能部分提升召回准确度，但有一个问题就是一个问题的覆盖范围有限；简单来说就是，同一句话可以有多个不同的表达方式，我们应该针对一个问题，从多个维度进行召回。
而这就需要用到问题分解的方法论，具体执行流程就是，把用户的问题输入给模型，然后让模型去理解问题，然后再围绕这个问题，再提出多个相似性的问题。
然后再通过这多个问题，从多个维度去数据库中进行召回，这样就能大大提升召回精度，并且能够覆盖更广的范围。
假设性文档召回——hyDE
所谓的假设性文档召回，就是大模型和人类一样，通过训练之后它有一定的知识基础；一些常识性问题，不需要RAG大模型也可以进行简单回答；因此，为了提升召回的准确率，我们可以先让大模型对用户的问题进行简单的回答，然后用大模型回答的结果当做条件(问题)，去数据库中进行检索。
这种方式就类似于，你遇到一个问题，老师给你提供了一个大概的思路，然后你按照这个思路去找资料，解决问题；这样找资料的方向更明确，结果也更准确。
上下文召回
所谓的上下文召回就类似于大模型的记忆功能；我们都知道大模型是没有记忆的，因此需要把每轮对话给保存下来，然后作为上下文让大模型来回答问题。
同样，在RAG中也可以使用这种方式；举例来说，用户连续两个问题可能语义上并不相关，但内在上却有联系；比如说，用户的第一个问题是现在的油价情况，第二个问题是国产车的市场价；从语义上来说，两个问题关联性不大，毕竟一个是问油价，一个是问车价；但通过这两句话我们应该都能明白，用户大概率是想买车或者换车。
但对大模型来说，这两个问题的虽然有一定的关联性，但关联性并不强，因此如果把两个问题放一块；然后让模型根据这两个问题，去优化出一个新的相关性问题，这样准确度是不是会更高。
而这就是上下文召回，通过给模型提供上下文，让模型能够更好地生成新的问题或相关性问题，这样就能大概率提升召回的准确度。
rerank——重排序
通过以上多个召回策略召回数据之后，可能会面临一个问题那就是召回的数据太多，甚至很多可能是重复的数据；因此，我们需要对召回数据进行去重，并进行重排，以此来提升召回数据的准确性。
当然，虽然以上召回策略能够提升RAG的准确度，但同样也会带来很多问题，因此我们在使用的过程中需要多注意和调整。
比如说，由于召回的链路过长，导致响应慢的问题 ，因此我们需要控制模型的输出长度，以及生成问题的个数和问题长度等。比如拆分子问题时，只需要生成三到五条问题，且每个问题的长度不超过十个字等等。
当然，关于RAG的召回策略还有很多，我们可以在不同的业务场景中选择合适的召回策略；而以上几个策略，相对来说比较简单，且易于实现，成本可控。
