BatchDAG：面向企业数据的可扩展即席分析的LLM规划执行图

# LLM规划的执行图：面向企业数据的可扩展即席分析
来源：https://arxiv.org/html/2607.18241
###### 摘要

大型语言模型\(LLMs\)擅长分析单个文档，但在处理企业级数据集上的、需要跨实体进行穷尽分析的查询时，会因上下文溢出、每个实体归属信息的丢失以及顺序工具调用带来的线性延迟而失效。我们提出了BatchDAG，一个系统，其中LLM生成一个类型化的操作有向无环图\(DAG\)——包括SQL查询、语义搜索、内存转换、并行扇出和单次分析——并由一个确定性引擎通过拓扑波并行和结构化JSON数据流来执行。一项关键优化，*实体感知批处理*，在扇出前按逻辑实体对行进行分组，将LLM调用减少了47倍。BatchDAG主要并非在质量上超越手工优化的流水线；相反，它是一个通用编排层，通过一个单一系统，能够从自然语言生成合适的执行策略，从而替代多个手工设计的工作流。在针对12个大量会议记录查询的受控实验中，BatchDAG\(3.74/5\)的质量与专家设计的流水线\(3.25/5\)相当，并显著优于ReAct智能体\(3.09/5, p<0.01\)，同时具有更优的溯源能力\(77%的会议记录证据率，而基线为46–60%\)。一个受控消融实验表明，结构化JSON中间件相比散文式摘要，减少了27%的幻觉\(配对t检验, p=0.107, n=12\)。规划器在300次规划调用中实现了98.8%的有效DAG率。在Brevian.ai的生产环境中，BatchDAG在60秒内处理超过50，000次会议记录的查询，根据已公布的GPT-5.1定价，每次查询的测量成本为0.02–0.24美元。

BatchDAG: 面向企业数据的LLM规划执行图用于可扩展即席分析

Anupreet Walia Brevian.ai [email protected]

## 1 引言

工具增强的LLM智能体已成为企业问答系统的标准架构。在这种范式中，LLM推理用户问题，选择工具\(数据库查询、语义搜索、API调用\)，处理结果，并生成答案。诸如ReAct\(Yao 等人, 2023\)、Toolformer\(Schick 等人, 2023\)以及LangChain\(Chase, 2022\)和LlamaIndex\(Liu, 2022\)的商业实现，已在针对单个实体或小型文档集的查询上展现出强大性能。

然而，企业用户越来越多地提出另一类问题：需要进行穷尽性、跨实体分析的查询，这需要处理数百到数千个实体，每个实体都需要自己的检索、上下文分析和每个实体的归属信息。例如：

- “客户经理是否在会议开始时提出了好的发现性问题？” \(需要分析每次会议的记录\)
- “分析每笔交易，看是否涉及安全保险” \(需要按交易进行会议记录搜索和分类\)
- “对于每次会议，检查关键利益相关者是否就价格进行了谈判” \(需要跨3，000+笔交易的实体级归因\)

这些查询暴露了单一智能体循环的三个根本限制：

#### 上下文窗口溢出

50，000次会议 × 25条顶部会议记录结果 == 1.25M 个token，超过了即使是最大的商业上下文窗口。

#### 每个实体归因信息的丢失

全局Top-N搜索返回整个*所有*实体中与查询最相关的N个结果。系统可以报告某个主题在某处被讨论过，但无法将发现归因于特定的交易。

#### 线性挂钟时间

顺序工具调用意味着延迟与实体数量成比例增长，使得大规模语料库分析变得不切实际地缓慢。

我们提出了BatchDAG，一个通过将问题分解为两个阶段来解决这些限制的系统：(1) 一个LLM规划器，它从自然语言查询生成一个类型化的操作DAG，以及 (2) 一个确定性执行引擎，它通过拓扑波并行、结构化数据流和实体感知批处理来评估DAG。关键的见解是，大多数分析查询可以分解为一小组类型化的操作\(SQL、搜索、转换、扇出、分析、比较\)，其中大部分在执行期间*无需*任何LLM调用。只有扇出——即按实体批次应用LLM推理的操作——会产生LLM成本，而实体感知批处理极大地最小化了这一成本。

BatchDAG的主要贡献不在于提高任何单个流水线的质量，而在于消除了设计流水线的需求——用单个系统替换一组手工设计的工作流，该系统能从自然语言生成合适的执行策略。与先前改善单个流水线或智能体推理的工作不同，BatchDAG解决了一个不同的问题：从自然语言中自动选择并组合针对每个查询的正确执行流水线。

我们的贡献是：

1. 1. 一个用于将即席分析查询分解为可组合操作（带有结构化步骤间数据流）的类型化DAG形式化模型。
2. 2. 一种实体感知批处理算法，在扇出前按逻辑实体对行进行分组，与按行批处理相比，实现了高达47倍的LLM调用减少。
3. 3. 一种基于目标的规划提示架构，在生成正确的DAG方面优于穷举规则和少样本示例。
4. 4. 一份生产部署报告，涵盖了企业级数据\(50K+次会议, 3K+个机会\)上的成本、延迟和正确性。
5. 5. 一个受控的实证评估，证明自动生成的DAG流水线能达到与专家设计的基线相当的质量，具有更优的溯源能力\(77%的会议记录证据率\)，并通过结构化中间件减少了27%的幻觉。

## 2 相关工作

### 2.1 工具增强的LLM智能体

ReAct\(Yao 等人, 2023\)在单个LLM循环中交织推理和行动步骤。Toolformer\(Schick 等人, 2023\)微调语言模型以插入API调用。两者都针对单一查询操作，未能解决跨语料库分析所需的实体级并行性。包括LangChain、LlamaIndex和Semantic Kernel在内的商业框架提供了工具调用抽象，但将执行规划委托给LLM在每个步骤中处理，继承了顺序执行的瓶颈。

### 2.2 查询规划与分解

Least-to-Most提示\(Zhou 等人, 2023\)将复杂问题分解为子问题，但生成的是自然语言中间结果，丢失了结构化的可组合性。Plan-and-Solve\(Wang 等人, 2023\)生成多步骤计划，但在单个上下文内顺序执行。Self-Discover\(Zhou 等人, 2024\)为任务组合选择推理模块，但目标是单实例推理，而非数据并行分析。SQL生成方法，如DIN-SQL\(Pourreza and Rafiei, 2023\)和其他方法\(Gao 等人, 2023\)，处理结构化查询，但无法在同一执行图中将SQL与非结构化检索和基于LLM的分析结合起来。

### 2.3 用于LLM工作负载的Map-Reduce

Map-Reduce模式已被应用于LLM摘要和文档分析。然而，这些方法使用固定的两阶段流水线\(映射所有文档，然后归约\)，并且不支持复杂分析查询所需的异构操作图\(SQL → 搜索 → 转换 → 扇出 → 分析\)。BatchDAG通过允许具有类型化操作和步骤间结构化数据流的任意DAG结构，泛化了Map-Reduce模式。

## 3 系统设计

BatchDAG在三个阶段运行：规划、执行和合成。图1说明了整体架构。

请参考图标题图1: BatchDAG系统架构。阶段1：一个LLM规划器生成一个类型化的DAG。阶段2：一个确定性引擎按拓扑波执行步骤。阶段3：一个合成LLM编译带有引用的结果。### 3.1 架构概览

用户查询进入系统，并在一个持久化执行引擎上启动BatchDAG工作流。该工作流通过三个阶段进行：

阶段1 \(规划\)：一个规划器LLM接收用户查询以及可用操作和数据源的架构描述。它生成一个类型化的步骤DAG，每个步骤都有明确的输入规范，声明要消费哪个先前步骤的输出以及如何连接或过滤它。

阶段2 \(执行\)：执行引擎对DAG进行拓扑排序，并按波次执行步骤。在同一波次内\(无相互依赖关系\)的步骤并行执行。SQL、搜索、转换和比较步骤是确定性的，无需任何LLM调用。扇出步骤生成并行的子任务，这些子任务并发处理实体批次。分析步骤在聚合数据上进行一次LLM调用。

阶段3 \(合成\)：一个合成LLM将所有步骤的结果编译成一个连贯的最终答案，并带有每个实体的引用和归因信息。

### 3.2 类型化操作DAG

DAG中的每个步骤都有一个从固定六种操作集合中提取的类型。表1总结了步骤类型、它们的计算后端以及LLM成本。

表1: BatchDAG步骤类型。六种类型中有四种在执行期间不需要任何LLM调用。关键的设计决策是，六种步骤类型中的四种\(sql, search, transform, compare\)在执行期间不需要任何LLM调用。只有`fan_out`和`analyze`会调用LLM，而`analyze`始终是单次调用。这意味着，对于可以通过SQL + 转换 + 分析回答的查询，规划后的总LLM成本恰好是一次调用。

### 3.3 结构化步骤间数据流

步骤之间传递的是结构化的JSON行，而不是散文式摘要。这是BatchDAG中最重要的一个架构决策。每个步骤通过一个`InputSpec`声明其输入：

- •直接引用：`{step: 1, key: "meeting_id"}`从先前步骤的输出中提取特定列。
- •合并连接：`{merge: [{step: 1, key: "id"}, {step: 3, key: "meeting_id"}]}`执行两个先前步骤之间的左连接。
- •依赖解析：`depends_on: [1, 2]`自动从第一个有可用数据的依赖项解析。

当我们最初允许LLM用自然语言总结中间结果时，下游步骤会产生幻觉数据并丢失归因信息。结构化行的表达能力稍弱，但完全可组合：它们支持步骤之间真正的数据库式连接、过滤和分组，并保留了从源数据到最终答案的溯源链。

### 3.4 实体感知批处理

`fan_out`步骤是唯一操作成本随实体数量增长的步骤。天真的按行批处理会导致灾难性的低效率。考虑一个处理121次会议记录的查询，每次会议大约有48行记录，总共产生5，824行。批处理大小为5行时：

按行批处理：⌈5824 / 5⌉ = 1，165个批次。同一个会议被分析5–50次，每次只分析其记录的一个不完整片段。

实体感知批处理：首先按`meeting_id`分组 → 121个实体。⌈121 / 5⌉ = 25个批次。每个批次接收5个完整会议及其所有记录行。这使得LLM调用减少了47倍，同时确保每个实体在完整的上下文中得到整体分析。

图2说明了这种差异。

请参考图标题图2: 按行批处理与实体感知批处理。实体感知批处理按分析的逻辑单元\(会议\)进行分组，实现47倍更少的LLM调用，并带有完整的每个实体上下文。
### 3.5 拓扑波执行

执行引擎计算DAG的拓扑顺序，并将步骤分组为相互独立操作的波次。同一波次内的步骤并行执行；引擎在波次之间阻塞。对于一个典型的5步骤分析查询：

- •波1: [sql, search] → 并行数据检索
- •波2: [transform] → 连接来自波1的结果
- •波3: [fan_out] → 并行实体批次LLM调用
- •波4: [analyze] → 综合发现

扇出步骤在持久化执行引擎上生成子任务，启用基于批次的重试语义。如果单个批次失败\(LLM超时，速率限制\)，仅重试该批次——而非整个扇出。

### 3.6 存储层

步骤间数据根据数据量存储。表2总结了三个层级。

表2: 步骤间数据的存储层级选择。

## 4 基于LLM的DAG规划

### 4.1 基于目标的提示

规划器提示在开发过程中经历了三次迭代，产生了关于代码生成任务提示架构的一个重要实证发现：

迭代1：穷举规则。明确列出了每一种可能的计划模式。LLM仍然生成了规则未覆盖的意外结构。

迭代2：少样本示例。提供了五个查询→DAG对示例。LLM复制了示例，即使它们不匹配该查询，产生了过度设计的12步骤计划，带有不必要的SQL派生。

迭代3：基于目标\(已部署\)。描述了每个操作类型的功能、其成本特性及其数据模型。LLM从基本原理出发推理应该组合哪些操作。这种方法对新颖的查询更鲁棒，因为LLM是在推理问题，而不是对示例进行模式匹配。

规划器接收可用数据源的架构描述、可用操作类型集合及其参数规范，以及明确的成本注释\(“fan_out是昂贵的那个”\)。它输出一个带有类型化步骤、输入规范和依赖声明的JSON DAG。

### 4.2 防范LLM过度指定

规划器LLM经常生成系统中类型定义不存在的规范字段\(例如，`output_mode`, `max_tokens`\)。我们没有迭代地约束提示，而是实现了一个安全规范过滤器，在构造时剥离未知字段。LLM可以产生任意参数的幻觉；系统会忽略它不理解的部分。这使得系统能够鲁棒地应对模型升级和提示变化，而无需进行提示级别的迭代。

### 4.3 输出格式约束

一个关键的实际发现：LLM输出格式比提示质量更重要。规划器最初返回Markdown包裹的JSON，导致解析失败和静默回退到单步骤计划。强制使用结构化JSON输出模式立即解决了这个问题。然而，结构化输出模式将数组响应包裹在对象容器中，需要一个解包步骤来提取实际结果。我们建议始终测试LLM返回的原始字节，而不是提示暗示它应返回的内容。

## 5 生产部署

### 5.1 部署背景

BatchDAG已在Brevian.ai（一个人工智能驱动的企业销售情报平台）生产环境中部署。该系统服务于对组织数据的分析查询，包括会议记录、CRM记录、结构化销售方法论提取、利益相关者数据和知识库文档。