KG与大模型之三问三答及Agent遇见RAG：PersonalRAG及长文本压缩新策略CompAct

今天是2024年7月17日，星期三，北京，天气晴。

我们来看看老刘说NLP20240715大模型进展早报，很有趣，其中提到了几个最新的RAG工作。

早上，看到知识图谱与大模型的一些科普性的总结，来自OpenKG的SIGData小组(SIGData兴趣组：利用大模型构建LLM需要的知识图谱，https://mp.weixin.qq.com/s/cFZZzRjJAeeMgz296nYKlQ)，很有趣，引用出来，确定为三问三答:‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

回到正题，我们今天来看PersonaRAG以及关于RAG中的文本压缩CompAct: 压缩检索到的文档以增强问答能力这两个工作，会有一些思路。

供大家一起思考并参考。

一、关于RAG中的文本压缩CompAct: 压缩检索到的文档以增强问答能力

《CompAct: Compressing Retrieved Documents Actively for Question Answering》：(https://arxiv.org/pdf/2407.09014)很有意思，提出一个名为COMPACT的新型框架，它旨在通过主动策略压缩检索到的大量文档，以便在问答（QA）系统中更有效地使用这些文档。

1、具体实现思路‍‍‍‍

在检索器和文档分段阶段，检索器首先从文档库中检索出一系列相关文档，这些文档随后被分割成多个段落（Segment-size documents）。每个段落包含一定数量的文档，例如，如果每个段落包含5个文档，那么第一个段落（S1）将包含前5个文档。

在压缩流程阶段：COMPACT 框架顺序地压缩这些段落，生成压缩文本（Compressed Text）。这个过程是迭代进行的，每个段落在压缩时都会与之前压缩的上下文（Previous Output）联合分析，以确保保留与问题相关的信息。

在评估和终止条件阶段：在每个压缩步骤之后，COMPACT 会进行评估（Evaluation），判断当前的压缩文本是否包含了回答查询所需的所有必要信息。如果评估结果表明信息不完整（例如，第一个和第二个段落的情况），则继续进行下一步，获取新的信息。如果所有支持性线索都被完全捕获（例如，N-th 段落），则迭代结束。

在信息整合阶段：在压缩过程中，COMPACT 会积极地整合与问题相关的信息，通过分析先前压缩的上下文与新提供的段落，确保每一步只保留最相关的信息，从而创建一个密集且紧凑的上下文。

具象化地，图中示例展示了一个关于 "Virtual Choir" 知名指挥家为奥斯汀的合唱团 Conspirare 创作作品的问题。为了回答这个问题，需要检索到问题中隐含的信息（即 "指挥家为奥斯汀的合唱团 Conspirare 工作"），并且需要全面地连接和综合多个文档中的信息（即 "Virtual Choir" 知名的指挥家）。

在迭代过程中，COMPACT 生成了几个版本的压缩文本，每个版本都基于当前的段落和之前压缩的上下文。如果某个版本的压缩文本没有提供足够的细节来回答问题（例如，第一个和第二个段落的压缩文本），则会标记为 [INCOMPLETE]。

一旦压缩文本包含了回答所需的所有必要细节（例如，N-th 段落的压缩文本），则会标记为 [COMPLETE]。

在每次迭代中，COMPACT 框架都会对当前的文档段落和之前压缩的上下文进行分析，并生成一个新的压缩文本（Compressed Text）。

此外，与压缩文本同时生成的还有一个评估（Evaluation），这个评估是由模型内部进行的，用以判断当前的压缩文本是否包含了回答查询所需的全部信息。

因此，我们可以看看这块评估怎么做的。

2、具体评估阶段如何进行？‍‍‍‍‍‍‍‍‍‍‍

评估阶段，主要有评估组成、条件判断、迭代终止三方面的内容：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

1）评估组成：评估由两部分组成： 理由（Rationale）：解释为什么认为压缩文本是完整或不完整的。 条件标记（Condition Token）：一个明确的标记，比如 [COMPLETE] 或 [INCOMPLETE]，指示当前的压缩文本是否提供了足够的信息来回答问题。

2）条件判断：如果条件标记为 [COMPLETE]，则表示模型认为当前的压缩文本已经包含了足够的信息来回答问题，迭代可以提前终止。如果为 [INCOMPLETE]，则表示还需要更多的信息，模型将继续进行下一轮迭代，获取并压缩更多的文档段落。

3）迭代终止：评估过程还包括一个早期终止条件，以确保一旦获得足够的信息就不再进行不必要的迭代。这有助于避免冗余信息的干扰，减少计算负担，并根据问题的复杂性和文档的信息密度动态调整。

为了训练模型进行这种评估，使用了一个高级的语言模型（LLM）来遵循一个三步过程，包括句子级选择、基于问题的压缩，以及确定迭代的早期终止点。这个过程帮助模型学习如何根据问题和提供的文档有效地更新上下文，并做出正确的评估。

3、点评？‍‍

但是，问题还是来了。COMPACT在处理检索到的文档时比其他压缩器有更长的推理时间，但作者认为，鉴于COMPACT在压缩领域的开创性工作，未来的研究可以在COMPACT的基础上进一步改进这些问题。

此外，在实际应用中，评估的准确性直接影响到模型压缩的效果。如果评估过早地判定为 [COMPLETE]，可能会导致丢失关键信息；如果评估一直判定为 [INCOMPLETE]，则可能导致不必要的迭代，增加计算成本。

二、PersonaRAG的基本实现思路

PersonaRAG，增强检索增强生成系统以使用户为中心的Agent，这个也很有趣，来自《PersonaRAG: Enhancing Retrieval-Augmented Generation Systems with User-Centric Agents》：https://arxiv.org/pdf/2407.09394，该工作介绍了一个名为PersonaRAG的新框架，旨在通过结合用户中心的智能代理（agents）来增强检索增强型生成系统，使得系统能够根据实时用户数据和交互来定制检索和生成的内容。

分成三步，包括检索召回->用户交互分析->认知动态适配，其中检索召回是RAG中最基本的检索召回阶段，示意图如下：

可以重点来看用户交互分析的设计，如下：

1、用户交互分析

用户交互，主要是为了根据用户的偏好，对检索到的文档进行二次排序，可以理解是精排。此外，其实际上是面向多轮的一个框架，将每个步骤生产出来的结果纳入到新的检索和生成步骤当中，如偏好上下文、之前的搜索记录、推荐等等，使用一个golbal message pool进行处理。

用原文的话来说，就是系统通过不同的代理（如用户画像代理、上下文检索代理、实时会话代理等）分析用户的实时交互数据，包括点击行为、在文档上花费的时间、查询的修改以及提供的任何反馈。

采用高度专业化的代理架构，每个代理专注于信息检索过程的特定方面。

1）用户画像代理（User Profile Agent）

该组件管理和更新用户画像数据，整合历史用户交互和偏好。它监控用户与搜索结果的交互方式，例如点击率和导航路径。用户画像代理帮助系统理解什么能吸引用户的兴趣并导致更深入的参与，从而实现个性化的搜索体验。

prompt如下：

2）上下文检索代理（Contextual Retrieval Agent）

这个Agent负责根据用户当前的查询初步检索文档。它既可以访问传统搜索索引，也可以访问更具动态性的上下文感知系统，后者可以考虑查询环境的更广泛方面。它利用用户画像数据来修改和优化搜索查询或优先排序搜索结果。

例如，如果用户持续更多地参与某些类型的文档或主题，检索代理可以在搜索结果中提升这些文档类型的权重，确保向用户展示最相关的信息。

prompt如下：

3）实时会话代理（Live Session Agent）

这个Agent实时分析当前会话，观察用户行为，如点击、在文档上花费的时间、对查询的修改以及提供的任何反馈。它创建了一个会话特定的上下文模型，捕捉用户立即的需求和兴趣。

prompt如下：

4）文档排名代理（Document Ranking Agent）

此代理负责对上下文检索代理检索到的文档进行重新排序。它整合了来自用户画像代理和实时会话代理的洞察，以更有效地对文档进行评分和排序。

prompt如下：

5）反馈代理（Feedback Agent）

此代理在用户交互期间和之后收集隐式和显式的反馈。隐式反馈包括行为数据，如在文档上花费的时间、点击次数和导航模式。显式反馈涉及直接的用户输入，关于文档的相关性和质量，通过评分、调查或评论收集。

prompt如下：

2、Cognitive Dynamic Adaptation，认知动态适配

这一步主要包括Chain-of-Thought以及Cognitive Agent两个部分，实际上做的是RAG中G的部分，根据用户交互分析得到的结果，系统动态调整其检索和生成的响应。这可能包括重新排列检索到的文档、根据用户偏好调整搜索查询或根据用户的即时需求推荐新的查询。

1）Chain-of-Thought

2）Cognitive Agent

3、一个具体的例子

我们来看看，一个具体的例子。给定问题，先做COT分解，看包括哪些步骤：

这一步用来检索query相关的文档。

Step 2: User Interaction Analysis

这一步涉及到这里面的几个agent的执行

Step 3: Cognitive Dynamic Adaptation并拿到答案

这一步涉及到对整个答案的回顾。

具体的项目代码放在：https://github.com/padas-lab-de/PersonaRAG.

4、工作点评‍‍‍‍

但是，通过动态整合来自用户画像代理、上下文检索代理、实时会话代理、文档排名代理和反馈代理的洞察，PersonaRAG不仅适应了即时用户需求，而且随着时间的推移更好地预测和满足用户期望。

这种多代理方法使PersonaRAG成为一个真正具有适应性和用户中心的信息检索系统，利用专门代理从不同行为角度分析用户交互，并提供高度个性化和上下文相关的搜索体验。

文档排名代理的加入确保了最相关的文档被识别并呈现给用户，进一步增强了系统有效满足用户信息需求的能力。

但这种系统实际上很难上实际生产，尽管认知动态适应机制能够提供个性化的响应，但该过程可能需要多次调用大型语言模型（LLM）的 API，这可能会增加时间延迟和成本。

参考文献

1、https://arxiv.org/pdf/2407.09394

2、https://mp.weixin.qq.com/s/cFZZzRjJAeeMgz296nYKlQ)‍

总结

本文主要介绍了PersonaRAG，增强检索增强生成系统以使用户为中心的Agent，及关于RAG中的文本压缩CompAct: 压缩检索到的文档以增强问答能力两个工作。

很明显的是，这两个工作还是以时间换指标空间，在具体落地可能性上其实不大，但其是想值得借鉴。

关于我们

老刘，刘焕勇，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。

老刘说NLP，将定期围绕大模型&知识图谱&RAG&文档理解四大主题，进行前沿技术、实践项目等总结等内容，欢迎关注。

对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。

加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入