A Domain-Specific Language for LLM-Driven Trigger Generation in Multimodal Data Collection

这是一份关于论文《A Domain-Specific Language for LLM-Driven Trigger Generation in Multimodal Data Collection》（用于多模态数据收集的 LLM 驱动触发器生成的领域特定语言）的详细技术总结。

1. 研究背景与问题 (Problem)

在数据驱动的开发中，数据质量直接决定了系统的性能。然而，现有的多模态数据收集（如自动驾驶车辆和机器人）面临以下核心挑战：

• 被动且无差别的日志记录：当前的系统通常连续记录所有传感器数据（摄像头、LiDAR、遥测等），导致存储成本高昂且包含大量无关数据。
• 筛选滞后与成本：事后过滤（Post-hoc filtering）会引入决策延迟，且下游团队需要花费大量时间清洗无关样本。
• 现有触发策略的局限性：
  1. 依赖专家代码：现有的选择性捕获策略通常依赖专家编写的低级代码，难以跨平台审计、复用和维护。
  2. 缺乏模块化与定义：多个独立实现的触发器并行执行效率低，且交互逻辑未定义，容易导致事件遗漏或重复捕获。
  3. 相关性定义僵化：现有方法通常将“相关性”等同于通用的异常信号，而忽略了相关性是用户特定和任务特定的（例如，感知鲁棒性所需的数据与控制评估所需的数据不同）。

核心问题：如何将从非结构化自然语言描述的高层数据需求，转化为可验证、可组合且能在资源受限的边缘设备上高效执行的触发逻辑，同时解决从“意图”到“部署代码”之间的鸿沟？

2. 方法论 (Methodology)

该论文提出了一种基于声明式领域特定语言（DSL）的框架，利用大语言模型（LLM）将用户意图转化为可执行的触发器配置。

A. 核心组件

1. 领域特定语言 (DSL)：

   • 定义了一种形式化的语法（基于扩展巴科斯 - 诺尔范式 EBNF），用于描述多模态数据触发器。
   • 基本单元：
     • 场景 (Scene, S)：由具有空间和语义属性的元素组成。
     • 车辆状态 (Vehicle State, V)：车辆内部信号（如速度、控制指令）的元组。
     • 情境 (Situation)：场景与车辆状态的集合。
     • 谓词 (Predicate, P)：对情境中特定条件进行布尔判断的函数（如“检测到行人”、“距离<5 米”）。
     • 触发器 (Trigger, T)：通过逻辑运算符（AND, NOT）组合多个谓词形成的布尔函数。
   • 优势：支持条件逻辑、组合性，并允许形式化验证和高效执行。

2. LLM 集成与 RAG：

   • 利用大语言模型（LLM）作为翻译器，将用户的自然语言需求（如“收集雨天城市中的行人交互数据”）转换为符合 DSL 语法的结构化 JSON 配置。
   • 采用检索增强生成 (RAG) 技术，向 LLM 提供车辆信号描述、控制逻辑和传感器映射等系统特定知识，确保生成的代码符合实际硬件接口。

3. 车载触发架构 (In-Vehicle Trigger Architecture)：

   • 基于 ROS 环境，包含三个主要组件：
     • 数据管理器 (Data Manager)：负责数据供给、过滤和预处理，维护包含当前车辆情境的“数据缓存”。
     • 触发引擎 (Trigger Engine)：每个触发器对应一个实例。它从缓存中读取数据，实时评估逻辑条件。仅在数据更新且满足频率要求时执行，若结果为真则激活数据采集。
     • 触发管理器 (Trigger Manager)：协调所有触发引擎的执行调度，监控资源使用情况。

B. 工作流程

1. 需求定义：用户以自然语言提出数据收集需求。
2. 自动转换：LLM 结合系统上下文和 DSL 语法，生成结构化的 JSON 触发配置。
3. 部署与执行：配置被部署到车载系统，触发引擎在运行时实时评估条件，仅在满足特定情境时记录数据。

3. 主要贡献 (Key Contributions)

1. 多模态数据触发 DSL：提出了一种支持条件逻辑和组合性的形式化语言，实现了触发器在设备上的可验证和高效执行。
2. LLM 驱动的触发框架：构建了一个框架，利用 LLM 将用户请求转化为可审计、可复用的捕获程序，降低了对专业系统编程知识的依赖。
3. 实证评估：在车辆和机器人感知任务上进行了评估，证明了该方法在生成一致性、执行延迟和减少冗余捕获方面的优势。

4. 实验结果 (Results)

研究在自动驾驶和机器人感知任务上，对比了三种方法：DSL 方法（本文提出）、无约束代码生成（Plain Code）和视觉语言模型直接推理（VLM）。

• 检测能力 (Detection Capability)：
  • 三种方法在检测性能（F1 分数）上总体相当。VLM 略高（0.67），DSL 为 0.66，无约束代码为 0.62。
  • 这表明 DSL 方法在保持检测精度的同时，没有牺牲核心的感知能力。
• 生成一致性 (Generation Consistency)：
  • DSL 方法显著优于无约束代码。在序列相似度、Levenshtein 距离和余弦相似度指标上，DSL 生成的触发器具有更高的一致性（例如序列相似度 0.966 vs 0.392）。
  • 这意味着 DSL 限制了 LLM 的幻觉，确保了不同次生成结果的结构稳定性，便于维护和验证。
• 运行时性能 (Runtime Performance)：
  • DSL 方法执行延迟最低。由于 DSL 生成的逻辑经过优化且直接映射到高效的谓词函数，其端到端执行时间优于无约束代码（后者常包含冗余检查）和 VLM（推理成本高且与查询无关）。
  • 这使得 DSL 方法更适合在资源受限的边缘设备上并发运行多个触发器。

5. 意义与结论 (Significance & Conclusion)

• 范式转变：将数据收集从“被动日志记录”转变为“基于意图的主动捕获”。
• 可扩展性与模块化：DSL 的模块化设计允许独立添加、移除或修改触发器，无需重构整个系统，适应了车队数据需求的动态变化。
• 降低门槛：通过自然语言接口，使验证工程师和数据分析师等非编程专家也能定义复杂的数据收集策略。
• 边缘部署友好：相比直接运行 VLM 或生成复杂的 Python 脚本，DSL 方案在嵌入式硬件上具有更低的延迟和更高的能效，是构建高效、以数据为中心的 AI 系统的实用路径。

局限性：检测性能仍受限于底层的感知模型（如 YOLO, CLIP）和 LLM 的推理能力。未来的工作将致力于在保持结构保证的同时，进一步增加 DSL 的表达灵活性，并结合更自适应的推理机制。

总结：该论文通过引入 DSL 作为 LLM 与边缘设备之间的“中间层”，成功解决了多模态数据收集中的效率、一致性和可维护性问题，为自动驾驶和机器人领域的数据闭环提供了新的技术路线。