iRAG：用RAG来理解视频内容

发布时间：2024 年 04 月 18 日RAG

检索增强生成（RAG）系统融合了语言生成与信息检索的长处，广泛应用于聊天机器人等实际应用。RAG 在整合理解多模态数据，如文本、图像和视频方面颇具潜力，但面临两大挑战：一是将大量多模态数据一次性转换为文本描述，处理耗时；二是文本描述往往无法涵盖所有多模态数据中的信息。鉴于用户查询无法预先知晓，构建一个能够将多模态数据转换为文本并进行交互式查询的系统颇具难度。为应对这些挑战，我们提出了 iRAG，这是一种创新的增量式工作流程，它扩展了 RAG 系统，使其能够交互式地查询大规模多模态数据集。与传统 RAG 相比，iRAG 能够迅速构建大型多模态数据库的索引，并在增量式工作流程中，利用索引从多模态数据的选定部分提取更多细节，以响应用户的交互式查询。这种方法避免了长时间的多模态到文本的转换，通过按需提取多模态数据中的细节，解决了信息丢失问题，并确保了对用户查询的响应质量。据我们所知，iRAG 是首个采用增量式工作流程增强 RAG 系统的案例，旨在高效地支持大规模现实世界多模态数据的交互式查询。在现实世界长视频上的实验结果显示，视频转文本的速度提升了 23 至 25 倍，同时保证了交互式用户查询的响应质量，与传统 RAG 系统相比毫不逊色。

为什么要提出iRAG

随着短视频、监控等视频相关的应用的兴起，视频资料正以非常快的速度增长着。比如：监控系统的摄像头监控的公共场所、机场。与之对应的视频分析需求和应用也与日俱增，比如：医院和医疗保健设施中用于病人监护的应用；比如为了交通监控、拥堵管理、事故检测，分析交通摄像头也是十分有必要的。

而随着ChatGPT等这类型大语言模型的崛起，以及他们在模仿人类进行基于文本的对话方面也显示出了超强的能力。受到LLM在理解海量文本资料方面的启发，作者开始尝试利用LLM来理解视频中的内容。通过视觉AI来分析视频内的每一帧内容，并将这些视频信息以文字的形式输出。比如，物体视频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 成为了深入、交互式理解多模态数据的关键工具。