构建Data Agent：企业大模型交互式数据分析方案（上）

在企业管理与商业决策中，数据的重要性早已不言而喻。作为中大型企业数据分析与决策支持的核心工具，BI系统（商业智能系统）的价值已经得到广泛认可。广义上的BI是一个涵盖ETL、数据仓库与数据集市、BI分析与可视化、数据挖掘工具等环节的完整技术链路。本文不追求面面俱到，而是聚焦于BI应用的“最后一公里”——即面向最终用户的交互式数据分析、挖掘与呈现环节（以结构化数据为主），探讨大语言模型（LLM）在这一领域能够带来的实际价值，以及当前可行的技术实现方案。

大模型在企业数据分析中的核心价值

当前企业数据分析应用，无论是中小企业自主开发的简单报表查询，还是大型企业基于专业数据仓库与BI工具构建的经营分析系统，尽管在辅助决策方面功不可没，但在实际使用中仍然暴露出一些明显短板。这也解释了为何许多BI项目难以完全实现预期的建设目标。瓶颈究竟在哪里？让我们看看几个典型场景：

• 业务部门查询数据前，往往需要与技术部门反复沟通需求。业务人员有分析思路，技术侧理解却容易产生偏差，一来二去，大量时间耗费在需求对接上。

• 系统中存在大量“沉睡”的功能模块。需求持续迭代，功能不断叠加，尤其是一些定制化的分析应用，超过八成功能可能从未被使用。

• BI工具本身的操作门槛较高。即使即席查询、多维分析等功能具备灵活性，但对业务人员而言，操作体验依然不够友好。

而大语言模型的崛起，恰好为这些痛点带来了全新的解决思路：

• 它提供了一种基于自然语言的交互方式，且语义理解能力相比传统方法有了质的飞跃。

• 在理解用户意图的基础上，借助海量语料训练或微调后的模型，能够推理并生成所需结果——例如一段文字描述或一段可执行代码。

那么，能否利用大语言模型的自然语言处理能力，弥合非技术背景的业务人员与复杂企业数据之间的鸿沟，从而大幅简化数据分析的整体流程？

我们不妨设想一下：基于大语言模型构建一个数据分析智能体（暂称为Data-Agent），重新定义人与数据的交互方式。不再需要冗长的开发周期，也无需学习繁琐的专业工具，用户只需通过自然语言“说”出需求——毕竟，没有任何沟通方式比自然语言更直观、更高效。

这样一来，企业内部的数据分析场景（至少是其中一部分）未来可以演变为：业务人员直接通过自然语言与Agent对话（例如：“帮我查看上季度各大区的销售与增长情况”），系统自动完成数据查询、统计、分析乃至洞察输出。这一转变带来的优势十分显著：

• 简单：将分析需求用自然语言直接表达即可。

• 快速：无需漫长的定制开发，也无需在BI工具中手动拖拽组件。

• 交互：采用对话式交互，无需查找菜单或按钮。

• 节约：不再被大量不常用的报表所淹没。

值得注意的一点是，在企业分析领域尝试以LLM进行升级，存在一个客观优势——相较于关键的OLTP交易系统，分析型应用对错误的容忍度通常更高，这为我们提供了更广阔的探索空间。

Data Agent的合理定位

尽管如此，我们仍需保持理性。大语言模型的能力虽然日益增强，但面对商业智能这类企业级应用，其复杂程度远非分析一个Excel文件或总结一篇PDF所能比拟：

• 数据结构复杂：企业信息系统的数据表结构往往包含数百甚至上千个数据实体，这与简单的Excel文件完全不在同一量级。正因如此，大型BI系统通常会在前端进行数据汇聚、简化与抽象，形成专门的语义层，方便业务人员理解和使用。

• 数据量大：分析类应用面对的是海量历史数据，即使经过多级汇总，也无法简单地将数据脱机为文件进行处理。

• 分析需求复杂：从即席查询到多维度报表指标展示，从数据上下钻到潜在信息挖掘，许多需求背后都涉及相当复杂的处理逻辑。

这些特性决定了，现阶段的大语言模型在企业数据分析中尚无法完全取代现有的分析工具。它更合适的角色或许是：作为现有数据分析手段的有效补充，在特定需求场景下，为经营决策人员提供一种更易用、更自然的交互式分析工具。

具体来看，比较适合的应用场景包括：

• 即席数据查询：利用自然语言即可完成对运营或统计数据的简单自定义查询。

• 传统BI工具的能力升级：许多BI工具本身就具备抽象语义层，目的之一就是降低数据分析对业务人员的门槛。大模型天然的语义理解能力，可以顺理成章地将传统BI的某些功能升级为自然语言交互式分析。

• 简单的数据挖掘与洞察：在某些场景下，借助大模型生成代码（Code）的能力与算法，实现交互式数据挖掘，发现数据中隐藏的模式与规律。

Data Agent的三种基础技术方案

接下来，我们从技术层面进行思考：如何将一段自然语言（例如“看一下上个季度不同销售大区的销售额分布与增长情况”）转换为对软件系统的操作，最终输出决策人员所需的报告（如一张表格或柱状图）？基于当前大模型的能力，大致有以下几种实现路径：

• 自然语言转数据分析API，text2API： 许多BI工具会基于自身的语义层开放API用于扩展。如果能将自然语言转换为对这些数据分析API的调用，是一种很自然的实现方式。当然，也可以自行实现这一API层。该方案的特点是受限于API层的能力范围，后续会详细讨论。

• 自然语言转关系数据库SQL，text2SQL： 这是当前最受关注的大模型应用方向之一（本质上属于特殊的text2code）。SQL是标准化的数据库查询语言，完全由数据库自身解释执行，因此将自然语言转换为SQL，思路最直接、实现路径也最短。部分关系型数据库已经开始集成此类功能，例如Oracle最新的Select AI。

• 自然语言转数据分析代码，即text2Code： 也就是代码解释器方案。简而言之，让AI自行编写代码（通常是Python），然后在本地或沙箱环境中自动运行，得到分析结果。当然，当前的Code Interpreter大多针对本地数据（如CSV文件）进行分析处理，因此面对企业数据库中的数据时，需要在使用场景上进行特别设计。该方案的优势在于可以利用Python强大的数据科学库，同时不依赖数据库本身。

方案一：text2API

下图展示了text2API的大致架构：

基本流程

• 首先，需要定义好数据分析的API接口（例如现有BI系统的开放API），这需要基于各自业务场景进行充分设计和实现，并形成API的“使用说明书”（即JSON Schema描述，对应Agent中的Tools工具描述）。
• 用户输入自然语言后，系统借助LLM将其转化为对API工具的调用，包括API名称以及提取的参数。
• 根据LLM的响应调用指定API，获取返回的数据。有时，还需要将返回的数据重新拼接回用户输入，再次提交给LLM，由其最终输出完整的分析结果。

问题一：Text2API的实现探讨

如何具体实现大语言模型的text2API能力？由于这是企业私有的定制API，无法借助那些已经基于互联网公开API训练好的text2Tool模型。

• 如果能够使用OpenAI的模型，可以借助其Function Call功能来实现。
• 如果无法使用OpenAI或需要连接私有模型，则需要借助提示工程（Prompt Engineering）来引导大语言模型完成这种转换，例如可以设计类似如下的Prompt：

"""
请遵循如下要求与约束：
1.参考以下的工具列表，找到需要使用的工具，并输出以下JSON格式内容用来使用工具。注意要确保下面内容在输出结果中只出现一次:
{"api_calls":[{"name":name of tool,"args":{"arg1":value1,"arg2":value2...}}]}
2.请根据工具的定义与参数描述来生成调用文本, 参考案例如下:
工具列表：
[
    {
      "name": "get_current_weather",
      "description": "获取给定位置的当前天气信息",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {
            "type": "string",
            "description": "需要查询天气的城市"
          }
        },
        "required": ["location"]
      }
    }
  ],
用户输入：查询北京的天气
返回调用JSON文本:
{"api_calls":[{"name":"get_current_weather","args":{"location":"Beijing"}}]}
3.如果无法理解用户意图，请回复“我无法理解您的意图”。
4.请根据用户问题与上下文来推理与提取本次工具调用需要的参数内容。
5.直接输出上述的JSON结果，不要有多余解释。
上下文:
{context}
工具列表:
{tools}
用户问题:
{question}
"""

借助LLM将自然语言转化为API调用及参数后，解析输出结果，即可调用对应API获取数据。当然，实际使用中需要精细调优并反复测试，才能保证准确率与稳定性。

问题二：企业APIs数量过多

大型企业BI系统中的数据分析需求可能极为复杂，即使只考虑部分场景，潜在的API数量也相当庞大。由于大模型的无状态特性，每次输入用户问题时，理论上都需要携带全部的API规格说明，这很容易超出模型的最大上下文限制。一种可行的解决方案是：

借助向量数据库的语义搜索能力，对所有APIs进行一次预过滤。每次需要LLM进行text2API转换时，只携带与用户问题最相关的API Schema，从而大幅减少输入的tokens和上下文长度。

大致流程如下：

1. 将所有API的功能描述进行嵌入（Embedding）处理，存入向量数据库。
2. 根据用户输入的问题进行语义搜索，找到与之相关的API描述。
3. 通过检索到的chunk的元数据，关联获取需要携带的API Schema。
4. 最终发送给大模型的提示中，只包含这些关联的API Schema，从而节省上下文资源。

问题三：输出与可视化处理

获取数据分析结果后，前端呈现方式可以是简单的列表，也可以是可视化的图表。如果是后者，就需要结合可视化方案，甚至借助LLM实现智能图表呈现。

例如，将API调用结果重新加入用户输入，再次提交给大模型，要求其根据用户需求输出最佳的图表类型建议及所需数据。调用端再根据大模型的输出，结合本地可视化方案进行处理。具体图表的绘制，既可以在服务端（如使用matplotlib）完成并返回图片，也可以在客户端直接渲染（如使用Ant的G2）。

text2API总结

text2API方案本质上是在传统数据分析系统之上增加了一层自然语言UI，核心分析功能需要自行设计API来实现。其优势在于：

核心分析逻辑不依赖于大模型（封装在API中），因此更可控。对于涉及复杂分析逻辑的任务（比如需要处理多个数据源、大量逻辑判断和数据实体，或者分析逻辑频繁变更的任务），可以将内部复杂性对大模型隐藏起来，减少对输出稳定性的影响。

不足之处包括：

• 核心分析逻辑的API实现，需要极高的业务理解与抽象能力。

• 灵活性和扩展性较差，受限于已经实现和开放的API库。

因此，该方案更适合输入输出结构相对简单（API简洁），但内部数据处理与分析逻辑较为复杂的任务。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：构建Data Agent：企业大模型交互式数据分析方案（上）要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题