TwinBI：面向商业智能仪表盘高效增强交互的代理式数字孪生体

# TwinBI：一种用于商业智能仪表板高效增强交互的自主数字孪生框架

来源：https://arxiv.org/html/2606.13731

11数据科学研究生院，首尔国立大学  
电子邮件：[email protected] & [email protected]

###### 摘要

商业智能（BI）日益将仪表板交互与基于LLM的辅助结合起来，但这两种模式在多步骤分析过程中常常不同步。当用户在直接仪表板操作和自然语言查询之间切换时，保持过滤器、层级、度量和图表上下文的一致性分析状态变得困难。我们提出TwinBI，一种自主数字孪生框架，将基于LLM的智能体系统与可执行的BI仪表板状态耦合。TwinBI通过从统一交互日志重建的共享分析状态，统一了对话交互、仪表板操作、语义基础和溯源跟踪。它还暴露了模式视图、SQL、日志以及用于状态基础分析摘要的`/insights`命令等产物。我们通过两种互补方式评估TwinBI。在相同后端智能体的对照组A/B基准测试中，与仅使用仪表板相比，TwinBI将精确匹配准确率从43.3%提升至63.3%，部分匹配准确率从48.3%提升至70.8%，并将超时率从40.0%显著降低至10.0%。在可用性研究中，参与者从集成的仪表板和聊天工作流中受益，任务准确率高，工作负载适中，对状态感知交互机制评价良好。这些结果表明，TwinBI通过将可见的仪表板状态转化为更丰富的可操作上下文，提升了智能体级别的分析可靠性和用户面向的分析支持。我们的数据集和源代码可在以下地址获取：

https://github.com/simonjisu/TwinBI

## 1 引言

商业智能（BI）系统构成了现代组织中数据驱动决策的核心基础设施。它们使分析师和决策者能够调查结构化数据、跟踪组织绩效，并将其决策建立在可衡量的证据上。最近自然语言处理领域的进展，特别是基于LLM的智能体架构，为BI引入了一种新的交互范式。这些系统通常被呈现为传统仪表板和分析工具的潜在继承者，将自然语言请求转化为工具执行和结构化查询语言（SQL）语句。

然而，这种新兴的替代叙事忽略了一个长期存在的脱节：流畅的自然语言生成与分析合理的决策支持之间的差距。企业商业智能（BI）建立在精确定义的语义之上——如度量定义、时间假设、聚合粒度和过滤范围——这些语义通常仅在仪表板和语义层中隐式编码。基于LLM的智能体可能偏离这些约束，产生读起来不错但系统实际状态不一致的答案。因此，我们建议，健壮的“自主BI”可能受益于通过显式的协调层将交互式BI工具与LLM辅助相结合，该协调层对齐用户意图、语义定义和查询执行，而不是仅仅依赖自然语言作为界面。

为应对这一挑战，我们提出TwinBI，一个通过两个相互连接的数字孪生实现BI的框架：一个对用户意图和推理进行建模的LLM智能体孪生，以及一个表示可执行分析状态的BI孪生，两个孪生在交互过程中保持同步。TwinBI将自然语言交互与机器可读的分析模式、层级、度量维度映射、可执行查询规范及其关联结果集的显式表示融合在一起，同时基于从仪表板交互推断出的用户当前分析上下文来约束智能体的行为。该系统暴露中间分析状态（包括工具调用和查询参数），并通过统一事件日志和持久化标识符捕获完整的溯源信息。这种设计提升了用户交互和系统层面推理的透明度与可追溯性。通过这种方式，BI-Twins将LLM智能体的角色从“替代BI”转变为“与BI协同工作”，从而增强了面向业务用户的决策支持的健壮性和可靠性。

在本文中，我们介绍了TwinBI的设计，并通过两种互补方式对其进行评估。在相同后端智能体的对照组A/B基准测试中，与仅使用仪表板相比，TwinBI提升了精确匹配准确率、部分匹配准确率和完成可靠性。我们还报告了一项可用性研究，表明用户从集成的仪表板和聊天工作流中受益，能够更好地完成分析任务并解释结果。

## 2 背景

商业智能（BI）涵盖了将组织数据转化为可操作洞察的方法、工具和技术。许多BI平台依赖于在线分析处理（OLAP），其中数据立方体在度量（例如销售额或销售数量）和维度（例如时间、地理位置或产品）上组织多维聚合。维度通常包含层级，例如年≻季度≻月，支持在不同粒度级别进行分析。

数据立方体上的分析探索通常通过切块、切片、上卷、下钻和旋转等操作来描述。在BI仪表板中，这些操作对应常见的动作，例如过滤、更改时间粒度、交叉过滤、更改分组字段和重新配置图表视图，从而构成了导航底层多维空间的交互词汇。

大语言模型（LLM）使自然语言与数据交互成为可能，通过将用户问题转化为结构化表示，并生成基于检索证据的解释。延续这一思路，LLM智能体超越了单轮提示，创建了工具增强的工作流，其中智能体分解请求、调用外部工具，并将其输出组合成最终响应。

构建基于LLM的BI助手的一种广泛使用的策略是自然语言到SQL（NL2SQL）管道，它将用户请求转换为SQL查询，执行该查询，并以自然语言返回结果。这种方法很实用，因为它将用户意图直接映射为对底层数据库的可执行分析查询。

尽管取得了这些进展，LLM智能体仍远未达到完整的BI平台，因为运营分析需要的远不止SQL生成。特别是，BI系统必须在自然语言交互和直接仪表板操作之间保持分析状态的一致，同时在整个多步骤探索过程中保持度量、过滤器和层级语义的对齐。

参见标题图1：TwinBI用户界面：(1) 用于自然语言分析查询的聊天界面，(2) 用于交互式探索的嵌入式仪表板，以及(3) 暴露SQL和层级模式等产物的检查面板，以支持模式理解。

参见标题图2：TwinBI的系统架构。

## 3 系统架构

TwinBI采用分层架构，将基于LLM的智能体系统与可执行的BI仪表板状态同步。该架构在对话交互和直接仪表板操作之间保持分析状态的一致，同时通过统一日志维护端到端的可追溯性。

图1（https://arxiv.org/html/2606.13731#S2.F1）展示了TwinBI界面，该界面结合了自然语言交互、嵌入式仪表板以及用于模式和查询级别产物的检查视图。图2（https://arxiv.org/html/2606.13731#S2.F2）展示了系统的整体设计。该系统使用Docker进行容器化，以确保隔离和可重复的部署。该架构由五层组成：(1) 表示层，(2) 编排层，(3) 语义层，(4) BI工具层，以及(5) 数据层。

### 3.1 表示层

表示层提供面向用户的体验，将聊天界面与嵌入式BI仪表板相结合。用户可以通过过滤、切换标签、交叉过滤和下钻操作，提交自然语言查询或直接与可视化内容进行交互。

为了保持两种模态的对齐，界面跟踪活动分析上下文，包括选定的图表、标签和最近的仪表板交互，并将这些信号发送到后端进行状态重建。

该界面使用Streamlit构建，并整合了Apache Superset仪表板以提供交互式可视化。

表1：用于统一交互日志的主要用户界面活动。

### 3.2 后端编排与智能层

后端编排与智能层管理多LLM智能体系统和可执行的仪表板状态。使用FastAPI实现，它将最近的对话历史、仪表板交互日志和工具输出整合为统一的分析上下文，将子任务路由到专门的智能体，并将其结果合并为锚定在当前状态的响应。

所有与外部系统的交互都通过后端管理的工具进行。后端还维护一个统一交互日志，记录会话交流、仪表板操作和工具元数据，作为状态重建和溯源的可信记录。表1（https://arxiv.org/html/2606.13731#S3.T1）总结了该日志中记录的主要仪表板交互事件。

### 3.3 语义层

语义层使用度量、维度、层级和连接路径的声明性模型来捕获业务含义。它为对话输出和仪表板查询提供共享的语义模型，强制执行兼容的粒度和有效的连接。我们还从事实表和维度层级推导出层级模式图，为模式探索智能体提供结构化和可导航的分析模式视图。

该层构建在Cube之上，Cube提供REST和SQL接口来执行模型驱动的查询。

### 3.4 BI工具

BI工具层提供交互式仪表板用于可视化数据探索。TwinBI使用Apache Superset来渲染可视化，并捕获详细的交互事件，这些事件被纳入统一日志中，并在需要上下文基础时通过图表数据API重放。

### 3.5 数据层

数据层作为领域特定数据的分析存储。分析数据集存储在DuckDB中，并且仅通过语义层访问，从而保持统一的度量定义和聚合行为，同时将存储与交互处理解耦。

## 4 TwinBI系统的功能

TwinBI旨在满足常见的BI工作流，即用户交替点击现有仪表板并用自然语言提出后续问题。系统并不将这两种模式分开处理，而是重用通过交互累积的仪表板状态，并将其应用于后续的聊天请求。实际上，这意味着图表、过滤器和后续问题是在同一个重建的分析状态上解析的，而不是在孤立的提示中。

参见标题图3：（左）示例查询，请求第四季度单位销售额环比增长超过15%的产品类别。（右）示例`/insights`输出，总结高增长产品类别、关于百分比解释的注意事项以及建议的下一步分析步骤。

### 4.1 查找和创建图表

用户可以通过两种互补机制访问或生成图表：(1) 直接与BI仪表板交互，(2) 通过聊天界面使用自然语言提示。

在以仪表板为中心的交互中，用户通过应用过滤器、切换标签、使用交叉过滤、下钻和切换系列可见性来导航和完善现有可视化。我们明确记录这些操作，因为仅凭后续的聊天轮次往往无法恢复结果状态。例如，像“为什么这个类别增加了？”这样的后续问题，除非系统能恢复哪个图表处于活动状态、已应用了哪些过滤器以及用户达到了哪个层级级别，否则就是未指定的。因此，TwinBI将仪表板操作编码为结构化事件，并在解释新的对话请求之前，使用它们重建当前分析状态。

在对话交互中，用户可以请求新的可视化，而无需指定模式名称或从头重建仪表板上下文。系统通过语义层解析请求，并保持生成的图表与当前分析切片对齐。我们发现这在用户希望从现有仪表板视图分支出去，而不是从空白状态开始新查询的情况下非常重要。

### 4.2 层级模式图、SQL和日志

TwinBI暴露三种检查产物，供那些希望验证系统正在做什么而不是盲目接受最终答案的用户使用。首先，层级模式图通过模式探索器提供了度量、维度和层级的紧凑视图。这在用户知道他们想要的业务概念但不确定语义模型支持的精确字段名时特别有用。其次，TwinBI暴露与每个图表查询关联的SQL，以便用户检查连接、过滤器和聚合选择。第三，可以直接检查统一交互日志，以追溯对话答案与早期仪表板操作和工具调用之间的关系。我们包含这些产物，因为调试BI答案通常需要检查错误来自模式选择、过滤器传递还是答案生成。

### 4.3 通过智能体发现洞察

如图3（https://arxiv.org/html/2606.13731#S4.F3）右侧所示，TwinBI提供了一个专用的`/insights`命令，用于用户需要当前视图的状态感知摘要而不是回答新问题时。当执行此命令时，后端从统一交互日志中组合一个紧凑的执行上下文，包括最近的对话、工具痕迹、活动图表及其当前过滤器。该上下文被传递给一个专门的洞察智能体，该智能体返回一个简短摘要，围绕三个要素组织：当前分析切片、该切片中可见的主要定量观察结果，以及建议用户下一步检查的内容。

此功能有意保持约束，使得摘要风格的输出始终基于当前可见的分析证据。它仅总结当前分析状态支持的信息，并且必须在证据不足以支持更强结论时予以说明。图3（https://arxiv.org/html/2606.13731#S4.F3）通过显示一个绑定到当前仪表板上下文而不是新探索性查询的摘要来说明这一点。

## 5 实验

我们设计了一个基准风格的A/B评估，以衡量TwinBI的状态基础编排是否能在匹配模型和环境条件下，相比仅仪表板系统提高分析任务的完成度。与第6节（https://arxiv.org/html/2606.13731#S6）的可用性研究不同，本实验针对受控智能体……