数据，在如今企业商业决策中的重要性毋庸置疑。正如BI（商业智能）系统已经成为众多中大型企业数据分析、预测与决策支持的关键IT设施。当然，广义上的BI是一个庞大的IT体系，并非一句简单的数据分析就能概括，ETL、数据仓库与集市、BI分析与可视化、数据挖掘工具等构成一个完整的端到端系统。本文聚焦在企业BI应用的最后“一公里”，即面向最终使用者的交互式数据分析、挖掘与呈现的环节（结构化数据为主），探讨大语言模型（LLM）的应用价值与相关方案。
大模型在企业数据分析的价值
在现有的企业数据分析应用中，无论是中小型企业自定义的简单报表查询，还是大型企业基于专业数据仓库与BI工具的经营分析系统，尽管在决策支持中发挥了重大作用，但是在使用中仍然存在一些可见的不足，这也常常使得BI类的应用很难达到预期的建设目标。一些常见的问题包括：
业务部门的数据分析过度依赖于技术部门。而业务与技术之间由于对分析需求理解上的差异，往往需要繁琐的沟通与确认，效率较低。
较多的“沉睡”功能。不断的业务需求迭代的结果可能是大量功能的堆积，特别是一些定制的分析型应用，可能80%以上的功能使用频率较低。
过于专业的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是最简单合理、实现路径最短的一种解决方案。
有的关系型数据库已经推出了内置的SQL AI增强，比如Oralce最新的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，由LLM来输出最终响应给客户的分析结果。
问题一：Text2API的实现探讨
如何实现大语言模型的text2API能力？由于这是私有企业应用的定制API，无法借助于一些已经对互联网公开API训练过的一些text2Tool模型。
如果你能够使用OpenAI的模型，可以借助OpenAI的Function Call功能来实现。
如果无法使用OpenAI的接口或需要连接私有模型，则需要借助提示工程来让大语言模型为你实现这种转换，比如类似这样的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取得结果。当然，实际使用时需要对Prompt进行细致的调优与反复测试来验证准确率与稳定性。
问题二：企业的APIs过多的问题
在大型的企业BI应用系统中，数据分析的需求可能非常复杂，即使只考虑部分的需求实现，其潜在的API数量也可能非常庞大。由于在大语言模型的无状态特征，每次我们在输入用户问题时，理论上需要携带全部的API规格说明。这就可能导致上下文超出模型的最大允许tokens。一种可能的解决方案是：
借助于向量数据库的语义搜索能力对所有的工具即APIs进行一次过滤，在每次需要LLM进行text2API的转换时，只携带与用户问题相关的API Schema，这样可以大大减少输入的tokens与上下文大小。
大致过程为：
对所有的工具即API的功能描述做嵌入存储到向量数据库
根据用户输入问题进行语义搜索，获取到相关的API描述
借助检索到chunk的元数据关联获取需要携带的API Schema
在发送给大模型的提示中仅携带关联的API Schema，从而节省上下文长度
问题三：输出与可视化处理
获取到数据分析结果后，通常的前端呈现有简单的结果或列表，也可能要求采用可视化的图表来展现。针对后一种情况，需要考虑结合一些可视化的解决方案，甚至借助LLM来实现智能的图表展现。
比如把API调用结果加入到用户输入，重新输入大模型，并要求大模型根据用户要求输出最佳的图表建议类型以及所需数据。调用端根据大模型的输出，结合本地的可视化方案进行处理。具体的图表绘制可以在服务端（比如借助matplotlib）完成后返回图片，也可以在客户端直接渲染生成（比如借助Ant的G2）。
text2API总结
text2API方案本质上是在传统的数据分析系统之上增加一层自然语言的UI，核心的数据分析功能需要自行设计API来实现。所以这种方案的好处是：
核心的分析逻辑不依赖于大模型（在API中），因此更可控。对于一些包含了复杂分析逻辑的任务（涉及不同的数据源、较多的逻辑判断和数据实体等），或者分析逻辑经常变化的任务，可以把内部的复杂性对大模型屏蔽，从而减少对输出稳定性的影响。
而这种方案的不足是：
核心分析逻辑API实现，需要极高的业务理解与抽象能力。
灵活性与扩展能力差，受限于已经实现与开放的API库。
因此，可以认为这种方案更适合用在输入输出结构上较简单（决定了API更简洁），但是内部数据处理与分析逻辑较复杂的任务。
