RetrievalAugmentor整体概念

简单总结一下

LangChain4j中对于RetrievalAugmentor这里官方描述的比较模糊, 只在 DefaultRetrievalAugmentor章节给出来了一个灵感来源的文章(LangChain框架中的设计思路)和一个研究报告, 有兴趣可以看一下:

• Deconstructing RAG
• https://arxiv.org/pdf/2312.10997

通常，RAG 系统涉及：确定要检索哪些信息的问题（通常来自用户）、从数据源（或多个数据源）检索信息的过程以及将检索到的信息直接传递到LLM作为提示的一部分。

这里的设计理念就是将用户的提问进行转换为具体的子问题，再根据子问题的描述路由到不同的数据源进行检索，将检索的内从进行重新合并达到检索增强的结果，最后再根据检索内容来回答用户的问题。

下面是具体的一些设计理念。

Query Transformations 查询转换

考虑 RAG 时要问的第一个问题：我们如何才能使RAG系统对用户输入的不同问题的回答具有健壮性？例如，对于具有挑战性的检索任务，用户问题的措辞可能很糟糕。查询转换是一组专注于修改用户输入以改进检索的方法。

Query expansion 查询扩展

查询扩展将输入分解为子问题，每个子问题都是一个更狭窄的检索挑战。多查询检索器执行子问题生成、检索，并返回检索到的文档的唯一并集。 RAG 融合通过对每个子问题返回的文档进行排名来构建。后退提示提供了第三种方法，即生成后退问题，以更高层次的概念或原则为答案综合奠定基础。

一种称为“后退”提示的提示技术可以通过首先提出“后退”问题来提高复杂问题的表现。这可以与常规问答应用程序结合起来，然后对原始问题和后退问题进行检索。

例如, 用户提出的一个物理问题, 可以退回到一个物理原理的问题(LLM生成的回答)，再进一步根据原理的问题和用户的原始问题来进行回答。

“后退”问题示例:

考虑一下这个问题：“红袜队和爱国者队谁最近赢得了冠军？”提出两个具体的子问题可以帮助回答这个问题：

• “红袜队上次赢得冠军是什么时候？”
• “爱国者队上次夺冠是什么时候？”

最后根据两个问题分别检索后得到对应的结果，最后再进行排名和合并回答用户的问题。

可以按照官方的流程图进行理解：

Query re-writing 查询重写

为了解决框架或措辞不当的用户输入，重写-检索-读取 是一种重写用户问题以改进检索的方法。

Query compression 查询压缩

在某些 RAG 应用程序中。为了正确回答问题，可能需要完整的对话上下文。为了解决这个问题，将聊天记录压缩为最终问题以供检索。

Routing 路由

考虑 RAG 时要问的第二个问题：数据存放在哪里？在许多 RAG 演示中，数据位于单个向量存储中，但在生产环境中通常并非如此。当跨一组不同的数据存储进行操作时，需要路由传入的查询。LLMs可用于有效支持动态查询路由。

Query Construction 查询构造

考虑 RAG 时要问的第三个问题：查询数据需要什么语法？虽然路由问题采用自然语言，但数据存储在需要特定语法才能检索的关系数据库或图形数据库等源中。甚至矢量存储也利用结构化元数据进行过滤。在所有情况下，查询中的自然语言都需要转换为查询语法以供检索。