我要投稿

大模型BI：商业智能背后的3大关键技术

发布日期：2025-05-26 07:45:34 浏览次数： 1736

作者：瀚海方舟

微信搜一搜，关注“瀚海方舟”

前言

回看上周的文章，已觉多有不足和过时。这也是我开通公众号的目的 —— 用最慢的书写记录这个最快变化的AI时代，记录我从无知到更无知的蜕变。

上周写完5种大模型BI的实现路径后，群友马上对这种分类方式发问：无论写sql还是写代码，应该都归为Text2Code。单纯从技术角度看，是有道理的，但仔细分析后，这5种路径不在一个维度上，难免引发争论。

再结合这周频繁的行业交流和思考，最重要的是学习新的知识（有幸听了字节北美大模型研发负责人杨红霞博士的一堂课，在此推荐他们最近的infi-coder工作：https://infi-coder.github.io/），我梳理了大模型BI的3个兵家必争之地，对大模型的能力要求递增：

1. 数据的获取

2. 深度的分析

3. 内在的推理

这3点终究还是偏技术的，如果这三点构成了智能BI的“理性”，那么基于NUI的人机交互架构和用户体验设计就是不可或缺的“感性”，但这足够独立写一整篇了，因此此次暂不讨论。

一. 数据的获取

即从企业分布式数仓中拿到想要的数据，典型的技术例如Text2Sql，但之前的文章讨论了B端某些场景下、某些角色使用过程中的局限性，以及如何突破这些局限，所以提出Text2DSL这一中间态，结合已有的很成熟的查询优化引擎，来实现企业级数据查询的最佳效果和性能。

在大模型能力要求评级上，个人观点是一颗星（后续的评级均以三颗星为最高），目前市面上能实现该能力的产品也比较多，成熟度可勉强评为两颗星。这个阶段主要存在的技术难点是：

1. 语义对齐

企业中存在大量的相似指标、数据字段，但指标口径千差万别，可谓差之毫厘谬以千里，如何匹配用户语义？目前常见做法是“语义澄清”，通过给出多个相似选项让用户来选择，这只是下策，还是以工具为本的旧方法。

以用户为本，应该基于不同用户、基于历史长窗口的查数习惯，主动、完整地实现查数请求。

2. 查询优化

这部分目前交给底层成熟的查询优化引擎来实现，暂不讨论（未来可能会出现基于大模型的数据查询优化Topic）。

只实现“取数”还远远不够，更深度“诊断”、“预测”、“指导”能力，需要第二和第三部分来分析。

二. 深度的分析

为什么叫“深度”呢，因为上个部分“数据的获取”也是一种分析，是“浅度”的分析，是数据明细的罗列（包括group by、sort等），从用户查询需求来看，更进一步的分析是缺失的。

比如：“预测未来一周的销量趋势”、“如果我加大某类理财产品的营销力度，对另一种产品的影响是什么？”

这种能力以前在GPT4中称为Code Interpreter代码解释器，后来为了让大家知道这个功能不只是给程序员用的，改为Advanced Data Analysis高级数据分析，到现在更加简洁的All in one，将GPT4中的所有工具（数据分析、在线检索、图像生成、数据分析等）合为一体。

以下是我尝试的一个案例：

我一口气提出了3个分析需求，首先做预测，然后做相关性分析，最后做因果推断，从GPT4输出的代码和描述来推断背后的逻辑：

1. 用head方法（Python的pandas库）先看一眼数据基本信息，有个大概的了解；

2. 分析任务&分解任务，虽然我提了3个需求，但GPT4拆解为4个，因为我的需求是只看“中国”，所以预先有一步数据过滤操作；

3. 逐个任务写代码执行。

不得不说，太像人的思考过程了。再来看他对我提出每个分析任务的完成情况：

预测：GPT4使用了sklearn里的LinearRegression，从绘图效果上看着怪怪的，毕竟是线性预测，算是勉勉强强完成吧；
相关性分析：生成的相关性矩阵很清晰，虽然我没有明确让他画相关性分析的图，但他绘制的很不错；
因果推断：直接罢工了，并找了一堆理由（Given the complexity of causal inference and the limitations of the dataset and analysis tools at hand, a comprehensive causal analysis may not be feasible here.）我试了几次都没有成功。

随着多轮对话，以上LLM的结果中不尽如人意的地方可能会逐个解决，感兴趣的话大家可以试试。

如同infi-coder工作中提到的，code LLMs在评估基准上还存在许多不足，因此基于StackOverflow，他们构建了高质量QA-Benchmark。同样的，在BI方向，也缺失这样的Benchmark，这是当下面临的第一个问题。

第二个问题是，在企业真实使用过程中，分析需求可能是具有头部效应的，每次实时写代码效率低且稳定性不高，不如内置若干API，以Function Call的方式来调用，等遇到长尾问题，再使用代码实时编写，兼顾企业应用的稳定性和灵活性。

这类能力在市面上确实看了一些公开的产品，但还比较初级，离真正能在企业中落地、结合大规模分布式数仓来赋能数据分析还有较大距离，大模型能力要求评级两颗星，市场成熟度一颗星。

三. 内在的推理

在上述的GPT4数据分析案例中，我们已经初步看到了大模型的任务推理能力，他能将需求拆解为若干子步骤，依次写代码来解决问题。

但前提是，提出的问题足够清晰可执行，就像一个刚进公司的实习生，名牌大学毕业，基础知识储备扎实，但还是需要一个老师傅告诉他每一步该怎么做，他才可能完成任务执行。

如果我提出这样的问题：“我该怎么做才能提高整体销量？”，那就要看是零售行业还是制造行业，每个行业的分析思路差别巨大。

再比如金融领域，一位投资经理提出：“我希望帮助我的客户的优化投资组合并做好风险管理”，那就需要分别完成：