写在最后的

# iRAG：用RAG来理解视频内容 发布时间：2024年04月18日 RAG 检索增强生成（RAG）系统，说白了就是把语言生成和信息检索结合起来，这在聊天机器人这类应用里已经用得挺多了。但RAG在多模态数据处理——比如文本、图像、视频的整合理解这件事上，潜力很大，挑战也不小。最大的两个问题：一是要把海量多模态数据一次性转成文本描述，处理起来太耗时；二是文本描述很难把多模态数据里的所有信息都覆盖到。而且用户查什么事先又不知道，所以构建一个能把多模态数据转为文本、还能交互式查询的系统，难度可想而知。 怎么解决呢？这就需要iRAG了。这是一种增量式工作流程，它把RAG系统扩展了一下，让系统能交互式地查询大规模多模态数据集。和传统RAG不一样的是，iRAG可以快速构建大型多模态数据库的索引，然后在增量式流程里，根据用户交互式查询的需求，利用索引从多模态数据的特定部分提取更多细节。这样一来，就不用花大量时间做多模态到文本的转换了，按需提取细节也解决了信息丢失的问题，用户查询的响应质量也有保障。据我们所知，iRAG是第一个用增量式工作流程来增强RAG系统的案例，目标就是高效支持大规模现实世界多模态数据的交互式查询。实验用的是真实世界的长视频，结果显示视频转文本的速度提升了23到25倍，交互式用户查询的响应质量一点也不比传统RAG系统差。 ## 为什么要提出iRAG 短视频、监控这些视频应用一兴起，视频资料的增长速度可以说是飞快。比如监控系统在公共场所、机场的摄像头，对应的视频分析需求和应用也在持续增长。医院和医疗设施里需要病人监护的应用，交通监控、拥堵管理、事故检测也离不开交通摄像头的分析。 而且随着ChatGPT这类大语言模型的崛起，它们在模仿人类进行文本对话方面表现出了超强能力。既然LLM能理解海量文本，那能不能拿来理解视频内容呢？作者开始尝试这条路——通过视觉AI分析视频的每一帧，把视频信息以文字形式输出。比如物体检测模型识别视频中每一帧里的物体，像汽车、卡车、自行车、行人，然后用人类能理解的文本描述它们在帧里的位置。把多个帧的内容处理完后，串联成一篇文章。最后LLM利用这些文本文档，采用检索增强等技术对视频内容进行交互式查询。 ### 交互式查询的局限性 坦白说，之前用交互式查询理解视频内容的尝试，有两个硬伤。 - 首先，用复杂的AI模型处理整个长视频、生成文本描述，时间可能非常长。分析一段24小时的监控视频可能需要超过一天，这对警方及时分析视频里的犯罪事件来说，显然太慢了。 - 其次，就算用了最先进的复杂视觉AI模型，视频里还是有很多视觉信息可能没有被捕捉到文本描述中。而且用户具体查什么通常是未知的，很难提前决定该用哪些AI模型来把视觉内容转成文本。 为了解决这些关键限制，作者提出了iRAG（Incremental RAG）。和之前的方法不同，iRAG不依赖多个AI模型提前提取文本信息，而是用轻量级AI模型快速为长视频内容准备索引。在长视频的预处理阶段，主要目标是从视频里提取足够的信息来建立索引——这样的索引有助于根据交互式用户查询，高效提取和检索视频中特定部分的更详细信息。 当然，用轻量级AI模型能减少索引时间，但文本描述可能不够详尽，导致很多用户查询因为文本描述里缺乏事实而得不到LLM的回答。所以作者提出了一种增量式工作流程：当索引阶段提取的信息不足以成功响应用户查询时，系统会根据需求使用额外的模型，从长视频中选择性地提取更多细节。这种策略确保iRAG按需提取必要的详细文本信息，针对性地解决特定查询，而不是在不知道用户具体要什么的情况下提前收集所有信息。 ## iRAG预处理步骤 iRAG预处理阶段的目标是为长视频快速建立索引。以轻量级物体检测模型DETR为例，它能逐帧分析视频内容，识别物体及其类型、位置和大小（通过边界框标注）。这些数据天然就构成了一个索引，便于快速定位视频中与用户查询相关的关键片段。视频里的每一帧都承载着时间线上的信息，使得搜索特定片段来响应用户查询成为可能。 举个例子，如果用户问“长视频里有没有出现FedEx卡车？”，就可以利用索引（也就是物体检测得到的数据）快速定位到检测出卡车的片段。然后用能识别图像文本的AI模型，对这些选定片段进行更详细的文本信息提取，确认FedEx卡车在长视频里出现的位置。值得一提的是，利用轻量级视觉AI模型可以快速构建多种索引，这些索引不需要是人眼可读或容易理解的。未来，构建索引所需的特征很可能由AI模型自动生成。为了便于理解作者的方法，全文讨论限定在iRAG预处理阶段使用的两种流行轻量级模型（DETR和CLIP）。这种索引方式不仅容易理解，还提高了iRAG对用户查询响应的透明度和可解释性。 ## iRAG回答 当用户提问时，iRAG利用传统RAG方法，从预处理阶段收集的数据中抽取相关联的上下文。下图展示了iRAG使用的Prompt模板： 一旦大语言模型Agent应用难以回应某个用户查询，系统就会启动增量式工作流程。 ## iRAG核心模块 iRAG核心模块包括三个关键组件：查询规划器、索引器、提取器。上图系统性地展示了iRAG系统的架构。只有在LLM应用无法响应查询时，才会启动虚线示意的增量流程。 - 查询规划器：负责从预处理阶段收集的信息中提取与用户查询相关的上下文，并给出建议——应该用哪些AI模型从长视频中的特定片段里抽取更多细节。这些细节对充分回答用户的查询至关重要。规划器提取的上下文分为两部分：在TextDB中与用户查询最相似的Top N片段（包含来自DETR模型的信息），以及在ImageDB中与用户查询最相似的Top F片段（包含来自CLIP模型的信息）。这里N和F是iRAG系统的配置参数。 - 索引器：进一步优化规划器提供的上下文，并将其缩减到最多K个视频片段，这些片段随后由提取器分析。这些视频片段就是上下文片段。K同样是iRAG系统的配置参数。iRAG将K视为发送至提取器的上下文片段数量的上限。由于从上下文片段中提取信息的详细程度是查询处理时间的主要决定因素，所以K的选择直接影响交互式查询体验的质量。另外，配置参数F和N通常比K大一个数量级。 - 提取器：利用规划器推荐的AI模型从上下文片段中抽取更多细节。从上下文片段提取的文本和图像向量分别被添加到TextDB和ImageDB中，以此来更新索引。然后通过检索更新后的上下文重新执行用户查询，从而增加从大语言模型获得有用响应的几率。 iRAG系统可以在预设的最大次数内循环执行增量流程，如果超过次数仍无法回答用户查询，系统会报告无法提供答案。实际操作中，增量流程的单一循环通常就足以成功回应大多数查询。 对用户查询的响应包括两个部分： - 对用户查询的文本回复 - 以及支持文本回复的来自长视频的一系列视频片段 这使用户能够识别出LLM的错误响应（或幻想）。未来，还可以构建自动响应验证器，判断人类可理解的文本回复和视频片段是否相互印证。 ### 索引器 前面提到，K是iRAG系统中的一个关键配置参数。 - 较高的K设置意味着对上下文片段数量的更大限制，而对大量片段进行详细提取既耗时又可能降低交互式查询的品质。 - 过低的K设置则可能导致可供详细提取的片段数量不足，更新后的索引缺乏足够的上下文信息，LLM难以给用户查询提供有用的反馈。 所以参数K的选择，在交互性和LLM响应的实用性之间保持平衡至关重要。 合并处理：规划器产出的前N个块通过重新排名算法进一步筛选，减少上下文块的数量。索引器中的合并组件通过将前F个帧和对应上下文块的片段进行串联，生成最多K个上下文片段供提取器处理。 如果不采用重新排名算法，那么与前N个块对应的片段会与前F个帧合并，形成最多K个上下文片段。但如果采用新的重新排名算法，就能显著减少前N个片段的数量。 重新排名：利用KNN分类器对前N个块进行筛选，把它们分为“接受”或“拒绝”两类。上图展示了重新排名的工作流程。前N个向量中的每一个都与查询向量串联，然后由KNN分类器赋予“接受”或“拒绝”的标签。任何被标记为“拒绝”的TopN个向量都会被排除。剩余的向量构成一个新的有序列表，对应的块也形成一个新的有序列表，输入到合并模块。 KNN分类器的训练：使用基线系统和iRAG规划器的数据来训练分类器。对于给定的查询和长视频，分析基线系统和iRAG检索的上下文。如果iRAG检索的块与基线系统检索的块相匹配，就把这个iRAG块打上“1”（接受）的标签；否则打上“0”（拒绝）的标签。这样就创建了标记数据，将用户查询向量与iRAG块向量的串联与“1”或“0”的标签关联起来。通过利用VQA-2数据集中的测试查询，创建了用于训练KNN分类器的标记训练数据。经过训练，如果一个未标记的iRAG上下文块的串联查询-块向量的5个邻居中有3个带有“1”的标签，KNN分类器就会给它打上“1”的标签。 ## 效果测试 作者用了上图四个数据集进行效果测试。 虽然部分测试数据集（VQA-v2和MSRVTT）自带查询，但像StreetAware和MODI这样的现实世界数据集常常不提供查询。为此，利用大语言模型Agent应用创造性地生成合适的查询。通过在两个视频上运行GRiT模型生成标题，这些标题随后被用作后续提示的上下文。通过不断用不同的上下文向大语言模型Agent应用提问，为StreetAware数据集创造了40个查询，为MODI数据集生成了16个查询。 作者采用Langchain框架来实现iRAG。所使用的向量数据库（包括FAISS索引）均源自Langchain，大语言模型则是OpenAI提供的gpt-3.5-turbo模型API。在iRAG的视频快速预处理阶段，使用了DETR，一个高效的物体检测器。在增量式流程中，还利用了GRiT，一个广受欢迎的图像字幕生成器。值得注意的是，与DETR物体检测器相比（平均每帧约70毫秒），GRiT模型在计算资源上的需求要大得多（平均每帧约1500毫秒）。实验在配备AMD Ryzen 5950X 16核处理器和NVIDIA GeForce RTX 3090 GPU的服务器上进行。 利用imageDB的优势：如上图所示，通过运用类似CLIP这样的轻量级视觉-语言模型，在iRAG的预处理阶段能够构建更丰富的索引。如表II所示，当预处理阶段同时采用CLIP和DETR模型时，iRAG获取的上下文视频片段质量优于仅使用DETR的情况。 块重新排序的优势：上图的结果并未考虑规划器模块检索的块通过索引器重新排序以筛除较不重要块的情况。上下文块的重新排序优势在下面两个图中有所体现。 处理时间：采用DETR对长视频进行预处理的速度远远快于GRiT预处理。如表V所示，iRAG的预处理所需时间仅为基线系统所需时间的23到25分之一。 从展示前200个查询处理时间的图表中可以看出，最初几个查询的处理时间相对较长。但随着处理查询数量的增加，处理时间急剧下降。这是因为最初几个查询的片段详细提取信息已被整合进文本和图像向量数据库，减少了后续查询的详细提取需求。 其次，随着α参数的增大，涉及的上下文片段数量增多，增量提取的时间也随之增长，导致查询处理时间变长。例如，当α=2时，前几个查询的处理时间大约需要25到30秒。而当α=4时，相同查询的处理时间则跃升至70到75秒。然而，不论α的值如何，如图表所示，在处理200至1000号查询时，查询处理时间迅速降至5秒以下。还多次对这1000个查询进行了重新排序，发现上述现象依然存在。 下图展示了iRAG系统和基线系统针对一系列查询所检索到的上下文片段中的帧。通过直观比较可以发现，iRAG检索出的上下文与基线系统的结果大体相似，但有一个例外。当查询“有白色面包车吗？”时，iRAG提供的上下文与基线系统的结果并不吻合。 ## 写在最后的 作者已构建了一个原型系统，使用户能够与iRAG系统进行互动。上图展示了iRAG系统的操作界面。用户首先上传视频，然后点击“开始预处理”按钮，利用高效的AI模型启动预处理程序。预处理完成后，iRAG系统便可以开始处理用户查询。 以本例而言，采用DETR物体检测模型进行视频预处理。对于基于检测的简单查询，例如“视频中有公共汽车吗？”，索引器能够迅速索引视频内容并给出答案。而对于更复杂的查询，比如“公共汽车是什么颜色？”，索引器会推荐相关的视频片段。之后，提取器利用GRiT模型从推荐片段中抽取详细的文本信息。这些文本信息随后作为上下文，与用户查询一同输入LLM API，以生成最终的回复。 iRAG的核心思路在于：不是一开始就用众多AI模型提取整个多模态数据集合中的文本数据，而是先利用轻量级AI模型快速为多模态数据集合建立索引。在索引创建阶段，可能会遇到一些用户查询，它们所需的信息在多模态数据中提取的信息并不足够。面对这种情况，iRAG会启动增量式工作流程，针对性地从与查询紧密相关的多模态数据中抽取更详尽的信息。这些新增信息随后用于检索更新后的上下文，生成对用户查询的有用回应。 尽管目前在交互式视频理解领域对iRAG进行了评估，但该系统同样适用于综合理解其他类型的多模态数据，比如音频、激光雷达和时间序列数据。虽然捕捉这些多模态数据内容并将其作为文本、或快速构建索引所需的AI模型各有不同，但它们在时间标记、以及将多模态内容嵌入向量方面与视频类似。这使得iRAG成为深入、交互式理解多模态数据的关键工具。