大模型在数据分析场景的落地应用
在调研中我们发现，从趋势上看，像银行、保险、证券、消费品零售、美妆等领域各个头部企业，都在落地实施大模型和数据分析工具的深度融合。
从大模型实际能力的边界来看，它在企业内部的用户落地过程中，大致分为生成类应用、决策类应用和多模态应用这三类。在数据分析场景中，它涉及到生成类应用和决策类应用这两种。
2.1 生成类应用
目前，大家谈论的主要是生成类应用主要体现在以下几个方面：
第一，对话式交互，这也是最常见的应用体现，即通过自然语言取代原来拖拉的方式并自动完成整个数据分析和相关报表的生成。
第二，内容生成，就是自动地生成分析报告和相关报表。
第三，代码开发，这项应用在数据分析中非常重要，其中之一是编写SQL查询语句以查看底层宽表的数据。因此，大型模型本身可以自动地生成SQL查询语句。
第四，智能体，也就是大模型本身可以去做任务的分解。例如，你需要查询利润率，那利润率可能本身是由营收减成本来计算的，那么大模型其实要去做任务的分解和指标的分解。
这些是我们看到的生成类应用是现在比较落地比较多的场景，相对进展也跑得比较快。
2.2 决策类应用
另一类是决策类应用的。之前BI可以实现数据辅助决策，基于返回的数据结果进行一些分析和预警。例如，如果指标有异常变化，它会进行提示和执行一些简单的数据分析，基于增长率的变化进行分析。
但辅助决策实际上无法对该指标背后的结果进行深度分析，找出影响因素，智能决策我们认为是大型模型在BI和数据分析中的重点应用。具有一些理解能力后，可以对指标和结果背后的原因进行一些归因，进行下钻分析，找出深度影响因子。
2.3 未来价值
具体落实到分析场景中，一般自助分析都需要宽表，完成宽表后会涉及数据清洗和建模。由于从去年开始大家都在做指标平台，也就是去做中间指标的定义、计算、管理，然后再到交互层怎么样去实现自助式的分析。
在自助分析中，我们可以看到第一个环节是生成对话式的交互内容和任务分解，这些都是在自助分析中实现的。在指标平台中可以生成并分解指标；而在宽表中，大家通常会使用代码开发，即自动生成SQL查询语句以及生成内容，例如在定义宽表时，字段可以让大型模型先给你一版定义，然后你可以基于它持续优化。
现如今，我们所见到的应用大多都是在自助式分析层面，旨在提升用户的交互体验，让用户可以直接感受到互动的优势。然而这种方法存在一个问题：如果在数据分析的底层，也就是在宽表、数据治理、数据清洗、数据建模等方面不做足够成熟的工作，那么想要得到正确的结果是非常困难的。也就是说，数据底层如果没做好，想要进行数据提取也是非常困难的。
因此，我们认为未来最大的价值在于底层，即如何更好地进行整个数据治理和数据清理工作，这无疑是我们认为最关键的切入点，这也是现在我们看到的一些实际的实践方式。
2.4 当前挑战
就目前而言，我们认为最大的挑战仍然是数据分析一直面临的一个问题：如何准确取得所需数据。业务部门的数据提取需求始终存在，但到目前为止并没有得以很好地解决。我们认为，在不同的场景下，该问题应该有一些行之有效的实践落地。
第一类场景是面向管理层的经营决策。在该场景下，问题的核心是如何确保数据的可靠性和准确性，以及如何降低信息偏差。要提高数据的可靠性和准确性，首要解决的事如何减少中间的交互次数，提升成功率。对于管理层或者经营部门而言，他们很难在持续等待很长时间后才能得到回复。我们认为，具体的实践方式是使用大模型加指标平台，这也是目前许多公司在企业内部实现的方式之一。
第二类场景是业务探索，其中一个关键点是如何能够查询到宽表中的数据。这个问题对于业务探索来说是一个非常大的挑战。
对于经营部门而言，他们只需要关注这几个指标，因此只需确保通过自然语言理解后，他们能够快速查看这些指标并反馈结果，这基本上已经满足了经营决策的需求。因为实际上经营管理部门的管理层通常只会关注一些常规指标，只要你能够满足他们的需求即可。
但是当涉及到业务部门时情况就有所不同，因为在业务探索过程中往往存在大量指标。例如，有些银行可能会有两万个指标，甚至有数千或数万人使用这些指标进行数据提取和应用。因此不光需要查询这些指标的结果，同时由于其业务持续变化，因此现有的指标可能是不足够的。我们需要获取底层宽表中的数据，以查找除指标内数据之外的宽表中的数据。这是一大应用需求。
而另一个需求则是在宽表之上构建宽表，这是可以通过自助分析来实现的。然而，当存在多个不同的宽表时，如何进行join处理和跨宽表查询，就变成了相当大的挑战。在业务探索过程中，这些都是核心问题和关注点，因此我们认为实现路径应该是使用大型模型加上知识库，再加上数据虚拟化引擎来实现。而数据虚拟化引擎在市场上尚未十分成熟。
大模型在数据分析场景的落地应用 
75
0
