LLMs在BI中的运用-编程知识

现有的BI分析存在以下一些问题：

原始数据入库规整要求比较高。业务过程产生的数据需要经过一些清洗等前置处理后才能够进行后续的BI分析使用。
业务部门的数据分析过度依赖于技术部门。而业务与技术之间由于对分析需求理解上的差异，往往需要繁琐的沟通与确认，效率较低。
较多的“沉睡”功能。不断的业务需求迭代的结果可能是大量功能的堆积，特别是一些定制的分析型应用，可能80%以上的功能使用频率较低。
过于专业的BI工具。虽然能够灵活的即席查询、多维分析、数据洞察等，在一定程度上增强了灵活性，但是对业务人员仍然不够友好。

Text2API

首先需要定义良好的数据分析API接口，形成API的使用“说明书”（JSON Schema描述，也就是Agent里面的Tools工具描述）。
使用者输入自然语言，系统借助LLM将使用者的输入问题转化为对API工具的调用，包括API的名称与提取的参数。
根据LLM的响应调用指定的API，取得返回的数据。根据情况需要，可能还需要将返回的数据再附加到用户输入，再次交给LLM，由LLM来输出最终响应给客户的分析结果。

"""
请遵循如下要求与约束：
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}
"""

由于API定制化处理，采用Text2API方法存在一些问题：

（1）由于API是企业应用的定制API，无法借助于公开API训练过的Text2Tool模型，需要通过模型微调或是需要借助提示工程来让大语言模型实现转换。

（2）企业的APIs过多的问题。由于大语言模型的无状态特征，每次在输入用户问题时，理论上需要携带全部的API规格说明。这就可能导致上下文超出模型的最大允许tokens。借助于向量数据库的语义搜索能力对所有的工具即APIs进行一次过滤，在每次需要LLM进行Text2API的转换时，只携带与用户问题相关的API Schema，这样可以大大减少输入的tokens与上下文大小。

大致过程为：

对所有的工具即API的功能描述做嵌入存储到向量数据库
根据用户输入问题进行语义搜索，获取到相关的API描述
借助检索到chunk的元数据关联获取需要携带的API Schema
在发送给大模型的提示中仅携带关联的API Schema，从而节省上下文长度

（3）如何实现可视化。图表绘制可以在服务端（比如借助matplotlib）完成后返回图片，也可以在客户端直接渲染生成（比如借助Ant的G2）。

Text2SQL

Text2SQL就是把自然语言转化为数据库能够执行的SQL，获得数据查询或统计结果。

Text2SQL的核心在于如何把自然语言组装成Prompt，并交给LLM转化成SQL。

指令（Instruction）：比如，“你是一个SQL生成专家。请参考如下的表格结构，直接输出SQL语句，不要多余的解释。”
数据结构（Table Schema）：类似于语言翻译中的“词汇表”。即需要使用的数据库表结构，由于大模型无法直接访问数据库，你需要把数据的结构组装进入Prompt，这通常包括表名、列名、列的类型、列的含义、主外键信息。
用户问题（Questions）：自然语言表达的问题，比如，“统计上个月的平均订单额”。
参考样例（Few-shot）：这是一个可选项，当然也是提示工程的常见技巧。即指导大模型生成本次SQL的参考样例。
其他提示（Tips）：其他你认为有必要的指示。比如要求生成的SQL中不允许出现的表达式，或者要求列名必须用“table.column"的形式等。

当前AI模型输出SQL的准确性还远无法达到人类工程师的输出精度。深度学习的AI模型预测本身就有置信度的问题，无法确保绝对可靠性，这点在LLM中依然存在。输出的不确定性也是目前限制大模型在关键企业系统应用最大的障碍。除了模型自身的知识能力以外，还有些客观原因：

自然语言表达本身的歧义性，而SQL是一种精确编程语言。因此在实际应用中，可能会出现无法理解，或者错误理解的情况。比如，“谁是这个月最厉害的销售”，那么AI是理解成订单数量最多，还是订单金额最大呢？
尽管可以通过Prompt输入数据结构信息帮助AI模型来理解，但有时候AI可能会由于缺乏外部行业知识导致错误。比如，“分析去年的整体客户流失率？”，那么如果AI缺乏对“客户流失率”的理解，自然就会出错或者编造。
对于复杂关联表查询，目前LLMS还无法很好处理。

从当前的一些模型测试结果看，让大语言模型能够在这些场景下完全胜任，达到人类工程师的精度是不现实的。但是可以在几个方面考虑其优化：

选择或者微调合适的大模型
提示词工程优化
应用场景的限制与设计

Text2Code

借助于大模型的代码生成能力，在理解客户自然语言描述的问题基础上，通过输出代码（常见的是Python）并自动迭代执行与调整，最终完成客户任务。在完成数据分析任务时，通常可以通过上传文件，然后要求Code Interpreter完成相关任务，其任务能力主要包括：

加载与读取文件内容，数据结构识别（Data Profiling）
数据质量检查，比如一致性、缺失值处理等
数据建模，如构建BI常见的多维星型模型
数据分析与洞察，如给出常见的KPI或回归分析
数据可视化，通过合适的图表对分析结果做展示

以Python语言代码为例，Code Interpreter一般会借助于其强大的数据分析组件numpy，pandas，matplotlib等进行自动化编程，并在服务器端安全执行后输出结果。针对合适的场景与分析主题，从企业数据仓库/数据库提取与同步数据到临时的数据分析存储区（如文件），借助于LLM的能力向决策者提供交互式数据分析与洞察能力。

基于代码解释器的数据分析与现有的BI工具不是取代而是互补。
代码解释器适合的工作层为经过汇总、建模与抽象过的数据层，物理形式最好是文件。
与Text2SQL输出针对数据库的代码不一样，代码解释器并不直接针对数据库：从海量的数据中快速检索与操作数据是SQL而非代码解释器的强项。
建议代码解释器针对的应用场景限制为：
- 较小或者中等规模的数据集
- 有着灵活、交互式数据查询分析需求的主题
- 相对规范与简单的数据模型，比如星型模型
- 涉及较复杂的数据挖掘算法与模型，如回归分析

两种用于数据分析的代码解释器方案：

借助Assistants API实现
基于Open Interpreter+LLM实现

TableGPT

TableGPT 的架构如下图所示，由一个表格编码器和一个大模型组成。当用户给出一个表格，并提出查询时，表格编码器会从用户所给的表格里提取矢量表征，并把它们和用户的查询文本一起一起喂给大模型来做推理。

把表格中的信息分成两部分：

（1）表格的元数据表征，即表格的呈现形式、表格内容的行业背景，每一列的栏目名称等。这样可以大模型对表格结构有一个整体的把握。

（2）学习表格中的数字信息表征，比如每一列中数值的分布和变化趋势。这里将表格的行和列视为一组元素，并学习整个集合的整体表征。而表格编码器的主干来自修饰过的集合转换器（modified set transformer）。编码器通过注意力机制加强之后可以理解不同行和列之间的相互关系。

大模型具有思维链（chain-of-thought），可以把复杂的推理过程分解成一系列中间步骤。而在这里，研究团队提出指令链（chain-of-command），为思维链的这一系列中间步骤提供逐步的指示。例如当用户提出：“列出 5 部利润最高的电影。” 大模型会先检查列表里面有没有利润这一栏，如果没有这一栏，那么它会生成一套指示来指导自己通过票房和成本数据计算出利润，再根据指示按照利润高低排列电影，找出利润最高的那 5 部。指令链增强了大模型的多跳推理（multi-hop reasoning）能力，使其能够把用户的诉求拆解成一系列指令，这样更易于进行复杂的跨表格操作。此外，当用户的请求太过模糊、宽泛的时候，比如用户说“给我一些数据”，那么指令链还会提醒用户把请求变得具体、明确。

TableGPT 能够与用户以自然语言交互，还可以做数据可视化和生成报告等等。与现有的会使用工具的大模型相比，功能更加齐全：