多模态数据流洞察难题待解，创新框架StreamingRAG显著提升实时分析效能！

未来先知

发布于 2025-03-11 21:23:21

1100

本篇论文对人工智能领域的研究进展进行了综述，重点探讨了深度学习、强化学习、自然语言处理等关键技术的最新发展及其在各个应用领域的应用情况。通过对现有研究成果的分析和总结，本文旨在为人工智能领域的进一步研究提供参考和启示。从多个领域的多模态数据流（如医疗保健、智能交通和卫星遥感）中提取实时洞察仍然是一项挑战。高计算需求和有限的知识范围限制了多模态大语言模型（MM-LLMs）在这些数据流中的应用。传统的检索增强生成（RAG）系统解决了这些模型的认知局限，但预处理速度慢，使其不适用于实时分析。作者提出了StreamingRAG，这是一种为流数据设计的创新RAG框架。StreamingRAG构建实时演变的知识图谱，捕捉场景-目标-实体关系。该知识图谱通过使用MM-LLMs实现时间感知的场景表示，并能够对特定事件或用户 Query 做出及时响应。 StreamingRAG克服了现有方法的局限，在实时分析（吞吐量提高5-6倍）、上下文准确性（通过时间知识图谱）和资源消耗减少（使用轻量级模型减少2-3倍）方面取得了显著改进。

1. 引言

随着 Stream 数据的不断增长，它在医疗保健等众多领域提供了实时分析医学图像的巨大机遇[6]；智能交通系统可以理解交通流量模式[17]；以及遥感领域，卫星星座为环境监测、经济活动测量和灾害响应等应用提供了图像流[4, 14]。这些领域都存在一个共同的根本需求：从视频、图像和其他多模态传感器流中提取实时洞察的能力。在这些领域中，动态情况和异常现象是常见的需要立即关注的事件。由于MM-LLMs [9, 13, 18] 能够高效地从多模态流中提取信息，因此它们经常被使用。传统上，RAG框架[8]被用于通过收集有关情况的知识来理解静态数据，这依赖于检索、索引和将外部数据转换为结构化格式的过程——这是一个耗时的工作。因此，它不适合实时应用，可能导致在数据流中理解关键事件时存在潜在差距。使用MM-LLMs提取信息需要大量的资源，这增加了成本。例如，在GPT-4V [12]的情况下，MM-LLM每处理一帧视频可能需要3-5秒，这对于实时 Stream 应用来说是不切实际的，因为它可能会错过关键事件的发展过程。

为了解决现有方法的局限性并实现实时理解，作者提出了StreamingRAG框架，该框架利用高效模型构建一个关于流内容的动态知识图谱[7]。StreamingRAG通过提取上下文场景-目标-实体关系来实现这一目标。此知识图谱具有两个关键作用：

（1）提供高效的场景表示；

（2）促进实时和上下文信息检索。在实时场景中提取所有演员及其关系是计算成本高昂的。

因此，作者的研究提出了一种基于动态优先级的知识提取方法。作者根据用户限制、演变的事件和当前环境，优先处理特定行动者和关系的信息。调度器负责协调这种动态优先级，并利用多模态问题生成器在特定时间提出相关的问题。这种方法确保了在规定时间内提取出优先级较高的行动者和关系的关键信息，最终构建反映最关键方面的知识图谱，实现实时构建。作者做出了以下关键贡献。

StreamingRAG，一种针对流数据的检索增强生成（RAG）系统，通过构建轻量级模型实现的场景感知时空知识图谱，应对了实时数据流 Query 的挑战。它采用了以上下文驱动的动态优先级知识提取过程，从而能够高效地构建知识图谱。作者在智能交通系统中评估了StreamingRAG监控视频流的有效性。

它带来了显著的优势：相较于以往工作，处理速度（吞吐量）提高了5-6倍，确保了实时分析。它利用时空知识图谱在动态场景中保持了上下文准确性。最后，使用轻量级模型将资源利用率降低了2-3倍。

动机

在人工智能领域的研究中，动机是一个至关重要的概念。它指的是推动研究者探索新方法、解决问题或实现特定目标的内在驱动力。在人工智能的发展过程中，明确的研究动机有助于指导研究方向，提高研究效率，并确保研究成果能够对人工智能领域产生实质性贡献。具体而言，以下动机在人工智能研究中尤为突出：

技术挑战：人工智能领域存在许多尚未解决的技术难题，如深度学习中的过拟合问题、强化学习中的样本效率问题等。这些技术挑战激发研究者不断探索新的理论和方法，以克服这些难题。
应用需求：随着人工智能技术的广泛应用，越来越多的行业对人工智能提出了新的应用需求。例如，在医疗领域，人工智能可以帮助医生进行疾病诊断；在金融领域，人工智能可以辅助风险管理。满足这些应用需求成为推动人工智能研究的重要动机。
伦理与安全：随着人工智能技术的不断发展，其伦理和安全问题也日益凸显。研究者需要关注人工智能的潜在风险，如算法偏见、隐私泄露等，以确保人工智能技术的健康发展。
跨学科融合：人工智能是一个多学科交叉的领域，涉及计算机科学、心理学、生物学等多个学科。跨学科的研究有助于推动人工智能技术的创新和发展。
人才培养：人工智能领域需要大量专业人才。培养具有创新精神和实践能力的人工智能人才，对于推动人工智能领域的发展具有重要意义。

综上所述，动机在人工智能研究中发挥着重要作用。明确的研究动机有助于指导研究方向，提高研究效率，并确保研究成果能够对人工智能领域产生实质性贡献。

传统的RAG系统通过补充外部数据源的知识来增强多模态-长语言模型（MM-LLMs）的能力。通过语义搜索，检索模块从外部来源获取相关信息，构建丰富化的上下文，并将其融入 Query 上下文中，使LLM能够通过结合多模态输入和检索到的相关信息来回答问题、创建描述和完成任务。现有系统依赖于计算成本高昂的MM-LLMs来处理数据和存储提取的信息。这种方法的有效性通过三个因素来衡量：处理时间导致的信息损失、响应延迟以及所需的计算资源。

图1： Baseline 架构

2.1 基准架构的局限性

重型多模态大语言模型具有较长的处理时间，这限制了它们在批量处理系统中的应用，其中离线处理是进行的。这种方法不适合实时流场景，在这些场景中，需要在对流数据进行分析时立即得到结果。流应用的几个关键指标如下。

准确度： Baseline 模型无法生成针对正在发生事件的准确响应，遗漏了关键细节，且未能适应不断变化的环境。由于未能处理足够的数据块，导致时间同步和顺序出现不准确，打乱了事件顺序，产生了时间空缺，并可能导致对事件流程的误解。异常检测变得具有挑战性，因为关键的非正常偏差可能被缺失数据所掩盖。

延迟与吞吐量：强大的重型模型需要大量资源，导致执行时间较长，从而降低了吞吐量和响应速度。此外，获取空间细节需要生成模型产生更复杂的响应，可能超过50个 Token 。例如，对于视觉到语言模型，ShareGPT4V VLM [2]各种输出响应 Token 大小的延迟在图2中展示。显然，为了实现实时运行，输出 Token 的大小必须最小化，这进一步强调了使用定制的轻量级模型来处理描述性 Query 相关问题的必要性。

成本：MM-LLMs具有巨大的计算需求，这需要最先进的硬件加速器。对于像智能城市应用这样的部署，实时处理数百个传感器数据流很快就会超出现有硬件的处理能力。延迟的增加阻碍了系统提供及时洞察的能力，而上下文准确性的降低则损害了生成响应的质量和实用性。

图2：ShareGPT4V[2]的延迟与输出 Token 大小关系。红色阴影区域表示描述性回答，使用更大的输出 Token 大小会提高延迟。绿色共享区域生成更少描述性的输出，通过使用较小的输出 Token 大小满足实时约束。需要向模型提出描述性问题，以便提取帧之间的时空信息。

2.2 作者的方法

StreamingRAG不是使用重型模型从实时流媒体内容中提取信息，如图3所示，它应对了这一挑战。与受重型模型拖累的传统方法不同，StreamingRAG通过系统的提取和动态知识 Pipeline ，优先考虑时间和效率，如第3节所述。这是通过提取低级目标信息及其关系，而不是高级场景，通过动态优先考虑特定实体-属性-关系的信息，并随后构建知识图来实现的。StreamingRAG利用时间知识图，在动态场景中保持上下文准确性。通过优先考虑效率和上下文感知，StreamingRAG能够高效地探索实时数据流。

图3：StreamingRAG方法

3.1 概述

StreamRAG框架处理实时连续监控，包括静态 Query 和交互式 Query 。静态 Query （又称持久 Query ）是持续进行、不断扫描实时流以寻找特定更新/条件的 Query 。它们与一次性的、有限响应的 Query 不同，能够提供对数据中特定事件或模式持续的了解。

图4：StreamingRAG系统架构

交互式 Query ，即用户按需提交的 Query ，需要实时和历史数据。这些 Query 允许用户根据初始响应来细化他们的 Query ，然后深入特定方面。StreamingRAG（如图4所示）由四个主要组件构成：（a）提取 Pipeline ，（b）知识 Pipeline ，（c）流处理平台和（d）Lambda引擎，具体如下所示。

3.2 提取流程

空间元数据通过多种推理引擎（例如，VLMs、LLMs和MM-LLMs等）从帧中提取，受到实时约束。由于处理每个传入的数据块不切实际，因此根据不断演变的事件动态优先选择数据流中的数据。

3.2.1 帧调度器：来自流媒体视频源的帧被送入提取流程的输入阶段，该流程运行在流处理平台之上（3.4）。随后，这些帧被导向不同能力的模型（3.2.3）。调度器会分析 incoming frames以评估其内容和复杂性，考虑的因素包括运动和场景细节。同时，系统级约束由约束解析器（3.2.2）进行监控。这种综合分析使帧调度器能够通过优先级规则和自适应算法，选择向推理引擎输入数据的最优帧率。

3.2.2 约束解算器：约束解算器通过优化实时提取 Pipeline 中模型间的帧动态调度，以提升系统响应速度。在优化过程中考虑了用户指定的约束（如每秒帧数、模型处理延迟、推理成本）以及系统层面的操作约束（如CPU使用率、GPU负载、内存可用性），旨在在确保延迟约束的前提下，最大化吞吐量。

3.2.3 推理引擎：实时提取 Pipeline 采用了重型和轻型多模态大语言模型的组合。这些模型接收帧和要处理于指定帧上的 Query 列表。VLMs（视觉语言模型）专门用于处理分层分析的问题库中的问题，充当任何事件检测的过滤器，通过优化计算资源来实现。

3.3 知识 Pipeline

在提取 Pipeline 仅从输入流中提取元数据的同时，知识 Pipeline 将元数据转化为可执行的知识，使系统能够回答用户 Query ，更重要的是，向提取 Pipeline 提供反馈，引导其从 incoming streams 中提取元数据。这包括分析当前响应，利用跨帧的空间细节构建时间上下文，监视事件的发展过程，以及细化后续帧的 Query 。知识 Pipeline 中的功能组件如下所述。

3.3.1 知识库：知识库（KB）是一个常识知识的基础存储库，为理解接收到的流数据提供初始上下文。它有助于知识图谱的初始化[1, 11, 15, 16]，形成动态上下文构建的起点。KB依赖于具体的应用场景。例如，在交通场景中，KB包含有关不同参与者（如行人、驾驶员、车辆等）及其关系、交通规则和历史交通模式等信息。

3.3.2 知识图谱：知识图谱（KG）通过包含三个元素的语义三元组来表示：主语、谓语和宾语。主语和宾语代表一个实体对，例如人-地点或目标-属性。谓语指定了连接这些实体之间的关系。KG作为动态记忆，捕捉生成响应所需的上下文细节。KG中的信息取决于特定用例的上下文，并可以来自知识库（KB）。

3.3.3 知识构建器：知识构建器（KB）实时更新和优化KG，基于KB和用户引导的上下文。它从KB中组装实体、关系和上下文相关的细节到不断演化的KG中。它持续更新图谱，反映演变的上下文，并适应流数据的涌入，确保图谱始终反映实时事件，使下游组件，如检索器和语言模型，能够在最新的上下文中运行。从场景级空间理解生成KG是通过建模实现的，其中是输入帧，是期望的图谱，是图像中的边界框，是目标标签，是目标之间的关系。

3.3.4 时间上下文识别器：理解传入流需要建立时间上下文（例如，事件或事故）。这个上下文作为触发器来调度资源分配，如处理能力（CPU/GPU）或更高的帧率，确保在关键时刻不会错过关键细节。将提取 Pipeline 中每帧提取的空间信息相结合，提供对时间上下文的全面理解。提取时间上下文涉及以下步骤的迭代：识别用户 Query 的具体需求；从数据存储中检索相关记录；通过排名和过滤进行审查，优先处理检索内容。识别上下文并从传入帧中提取必要信息涉及 Query 知识库（KB）以识别相关实体和关系。选择概率最高的实体， Prompt 在提取 Pipeline 中的VLM推理引擎后续迭代问题的构建。一旦事件结束或处于稳态条件，KG将重置，以确保与当前状态保持一致，并为后续事件和 Query 做准备。

3.3.5 视觉 Query 生成器：是提取和知识 Pipeline 之间的接口，它结合当前视频响应从中提取相关信息。给定当前视频响应和问题，它在时间点通过时间上下文标识符与进行交互。 Query 生成器将与整合以更新问题集，（其中）基于时间线索。这个过程优化了 Query ，融入了不断变化的环境。优化后的问题，，随后被安排在后续帧中，并嵌入到当前的 Prompt 中，然后由调度器发送到提取 Pipeline 。

3.3.6 用户 Query 处理器： Query 处理器将非结构化、多模态的用户 Query 转化为可执行的 Pipeline 操作器。除了解析和解释用户 Query 外，处理器还会根据不断变化的环境和知识库（）对 Query 进行细化。

3.4 S流处理平台

系统组件托管在实时流处理平台DataX上[3]。它通过简化数据交换、转换和融合，解决了构建分布式流处理应用的复杂性。DataX提供了一种抽象，通过揭示微服务之间的并行性和依赖关系，简化了应用规格的指定。这使得DataX运行时能够自动管理数据通信，并提供动态扩展和优化。

3.5 拉姆达引擎

Lambda引擎被用于支持实时 Query 和交互式 Query 。该框架需要访问实时和历史数据，并通过三层结构：批量层、服务层和速度层，来加速访问以最小化 Query 响应时间。批量层通过历史背景对进行预处理和更新，为上下文理解提供基础。然后，这一结果被注入到实时提取和知识 Pipeline 中。服务层能够高效地从中检索相关数据，从而增强用户交互 Query 的检索过程。速度层处理实时数据流，使系统能够适应并响应不断变化的环境。

4. 实验 & 评估

4.1 设置

StreamingRAG在智能交通系统（ITS）的异常事件检测方面进行了评估，通过生成事件描述，使用了公开[19]和专有数据集，针对不同的事件复杂性进行测试，特别关注通过跟踪静态 Query 来评估实时演变事件。（1）当发生涉及车辆与行人碰撞的事故时发出警报。（2）在发现处于困境中的行人时通知我。

作者的实验设置包括一组服务器，每台服务器配备32核心的英特尔至强CPU、256GB内存和24GB的NVIDIA GeForce RTX 3090 Ti显卡。作者的评估方法涉及将IP摄像头捕获的视频进行 Stream 传输。

作者的提取 Pipeline 利用ShareGPTV4 [2]这一描述性图像标题模型进行 Baseline 系统的推理。VQA模型BLIP [10]和BLIP-2[9]被用于提取空间信息。

Stream 处理平台是基于DataX [3] 实时流处理框架构建的。它使作者能够高效地管理来自摄像头数据的持续数据流，使用所选的VLM模型对其进行处理，并将其与知识 Pipeline 集成。

在知识 Pipeline 内部，为了作者的交通监控用例，知识库（KB）是手动创建的，目前它被实现为实体、潜在属性及其之间关系之间的映射。KG的维护采用NetworkX [5]。在接收到VLM对之前生成的一组VQG Query 的响应后，生成器从中检索相关的实体、属性以及实体间必要的关系。随后，它根据场景上下文，制定包含最多五个问题的 Prompt ，以确保符合实时延迟要求。

图5：吞吐量

4.2 评估指标

作者的评估既考虑了事件持续的时间，也考虑了其复杂性。事件持续时间对于实时分析至关重要，因为如果处理一帧需要更长的时间，短时事件可能会被完全错过。由于系统能够观察和为后续帧提出问题，长时间事件在实时提取阶段更容易管理。系统性能通过以下指标进行评估。

延迟与吞吐量——生成响应所需的时间。

成本（GPU资源利用率）以GPU内存使用量为衡量标准，这是决定系统可扩展性的一个因素。

生成的响应的准确性通过人工检查来评估，重点在于系统识别不断变化的环境和生成响应的能力。在作者的用例中，评估基于两个因素：（a）情境感知的事件检测；（b）响应生成。例如，在肇事逃逸的情况下，系统需要识别确切的序列：车辆与人的碰撞、碰撞后人的不动和车辆逃离现场。遗漏任何事件都会失去情境，导致错误的响应。生成阶段评估模型响应的准确性和适宜性（包括大语言模型和视觉语言模型）。

4.3 结果

4.3.1 延迟与吞吐量：图中（图5）的阴影区域表示异常事件实例，如肇事逃逸和车辆碰撞。在 Baseline 情况下，较高的推理时间会导致关键时间信息损失，当将帧级响应汇总以创建响应时。然而，StreamingRAG以大约8帧/秒（视频帧率的1/3^r d）的速度运行，有效地提取了上下文空间信息。

4.3.2 GPU资源利用率：虽然表1突出了StreamingRAG在单摄像头流和专用GPU下的效率提升，但实际部署中涉及数百个分布在广阔区域内的摄像头。作者的架构支持GPU共享，可根据每个流的变化情况动态调整资源分配，确保即使在复杂和地理分布广泛的部署中，也能实现高效的资源利用率。

表1：GPU资源利用率 4.3.3 准确性：在实时场景中，迅速检测正在发生的事件的能力至关重要。正如表2所示，作者实现了显著更高的检测率，这得益于其更快的处理能力和对历史帧级响应的利用。尽管取得了这一改进，但两个系统在及时检测短期事件方面都遇到了挑战，尽管与 Baseline 相比，作者的成功率相对较高。生成的响应是根据事件时间累积的时序准确性进行评估的。表3展示了4个事件（如肇事逃逸、车辆间碰撞、车辆与行人碰撞和人潮）的响应。 Baseline 在处理帧时难以迅速响应，导致无法收集关于涉及的个人和车辆的信息，最终完全错过了碰撞事件。例如，在车辆间碰撞中， Baseline 正确地识别出汽车着火了，但它未能捕捉到车辆碰撞的上下文，导致汽车着火。在车辆与行人碰撞中， Baseline 不仅未能检测到碰撞事件，还将情况错误分类，将其解释为游戏而非交通场景的一部分。使用StreamingRAG，在肇事逃逸案例中，错过了事故的确切时刻。然而，通过分析多个帧，它发现有人在汽车附近的道路上躺着，这表明发生了事故（用红色突出显示）。