数据之于企业决策，重要性已经是老生常谈了。

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简洁），但内部数据处理与分析逻辑较复杂的任务。