AI大模型与BI数据分析的5种实现路径

首先分享几个关键洞察：大模型自身难以构成竞争壁垒，真正的价值在于长期深耕特定场景所积累的数据处理能力。那么，为什么AI结合BI在B端市场近期如此火热？不妨看看GPT4给出的总结：

除了GPT4那些官方口径外，几个来自实践的观察可能更具说服力：

• 用户对自然语言交互类产品的使用习惯正逐步养成——尽管仍处于早期阶段，但这种人机交互方式的转变，就像从按键手机过渡到触摸屏手机，是本质性的跃迁。
• 传统BI厂商开始激烈内卷，自然语言数据分析功能已几乎成为标配，不再是可选特性。
• 无论出于被动试水还是主动推进智能化升级，企业在智能化方面都有实际预算投入，特别是与数据智能直接相关的领域。

近期我们调研了多家厂商的AI+BI技术路线，汇总后发现一些有意思的趋势。最终谁能胜出，是多厂商共存还是仅剩头部玩家，让市场来投票。核心发现如下：

• 无论选择哪条路线，各厂商都基于自身原有数据架构构建智能体系，发挥各自最擅长的部分。
• 大模型之路是一场持久战，当前AI+BI整体仍处于产品形态探索期，不少成果其实只是花架子。
• 如果仅依赖大模型本身，很难形成真正的竞争壁垒——即使是Agent也不例外。

回到技术层面，除了被广泛讨论的Text2Sql，还有哪些路径值得关注？逐一来看。

一. Text2Sql

Text2Sql，顾名思义，就是输入一句自然语言，自动翻译成SQL代码，省去手动编写查询语句的过程。这条路径是基于大模型做数据分析时最主流的技术方案，但要做好并不容易。前不久一位业内人士在技术大会上详细介绍了整个系统的搭建流程，从模型基座、构造数据、领域训练、精准评测四个关键环节逐一拆解，干货满满。最后关于未来展望的总结也极具参考价值，附上截图：

《ChatBI—NL2SQL领域大模型的研发及在数据分析产品中的落地》

分析的最终目标还是要落到决策上——也就是图中提到的“指导型”阶段，这才是数据真正产生价值的落脚点。

二. Text2Graph

与Text2Sql的不同在于，大模型不是将自然语言翻译成关系型数据库的SQL语句，而是图数据库查询语句，例如常见的SPARQL语句（用于查询RDF数据），或NebulaGraph中的Cypher查询语言。通常采用这种方案的企业，底层一定是以图数据库为核心的，比如欧拉智能。该方案的最大优势在于能充分发挥图数据库的多跳推理能力，在处理复杂推理问题时，比SQL多表关联查询的性能高出不少。以下截取了Neo4j公司做的一组对比：在一个包含100万人、每人有50个朋友的社交网络中，寻找最大深度为5的朋友关系，两种数据库的查询性能差异一目了然。 《美团图数据库平台建设及业务实践》

三. 代码编写类

如果只做自然语言到查询语句的翻译，功能确实略显单调。面对更复杂的分析场景怎么办？干脆“聘请”一位既会写SQL又会写Python的数据分析师，随时通过编写代码来满足各种需求。这里有两个典型代表：一个是开源社区的Data-Copilot，另一个是商业产品——九章云极的TableAgent。 Data-Copilot主要分为两个阶段。第一阶段是离线过程，通过self-request构建大量接口，相当于预先生成了一批工具（例如图形渲染、数据查询、排序、数值计算等），供在线过程调用；第二阶段类似autoGPT，进行任务规划和工具调用。整体流程如下： 《Data-Copilot: Bridging Billions of Data and Humans with Autonomous Workflow》 九章云极不久前发布了TableAgent数据分析智能体，可在官网试用。整体思路与Data-Copilot非常相似，此处不再赘述，感兴趣可亲自上手体验。附一张实例截图供参考：

来自九章云极TableAgent 其亮点在于能够清晰呈现Agent的思考过程、数据流图以及代码编写过程。当前的问题主要是界面略显简陋，以及数据源仅支持上传Excel文件——推测内部只能对Python的DataFrame对象编程。如果需要对接企业级数据库，这套流程可能就不太适用了。

四. 指标平台+大模型

此前在一篇文章中简要分析过：从宽表到大模型应用之间，如果增加一层语义封装，很多原本棘手的问题就会豁然开朗。行业分析机构爱分析举办的《大模型+数据分析》主题研讨会也明确提出了类似方案： 爱分析 · 《大模型+数据分析》 这种技术方案适合已经在指标层有一定积累的厂商。因为这一层需要解决语义统一（例如“销售额”到底是什么、口径如何计算）、体系构建（销售额如何拆解、怎样关联其他指标）、指标管理（今天张三建一个指标，明天李四又建一个，如何协调）、查询优化（同一个查询需求存在多种实现路径，哪条最快最好）等一系列基础性问题。这些功能原本散落在系统各处，大模型的出现将它们有机链接起来，主动呈现在业务人员面前。

五. 数据虚拟化+大模型

数据虚拟化并非AI+BI领域特有的技术，在大模型出现之前，它就被用来缓解业务快速发展与数据有序增长之间的矛盾。这里引用Aloudata技术团队的解释： 虚拟化是一种设计思路，它尽可能对使用者屏蔽物理运转的细节，将原来需要使用者手动给出的指令，由机器通过恰当的规则和算法自动实现。虚拟化的本质，就是在绝大多数场景中让用户可以按照业务本身的需求去操作，而不必为物理引擎的特性做额外优化。 下图为数据虚拟化的概念表达： Aloudata技术团队《数据无序增长的终结者-数据模型虚拟化》 数据虚拟化位于物理数据层和用户接口层之间。顺着这个思路，大模型的位置自然就落在了用户接口层和虚拟层之间——虚拟层为上层的业务屏蔽了底层表的过多细节。那么“数据虚拟化”和“指标平台”是什么关系？两者并不冲突。“指标平台”主要解决业务侧的问题，“数据虚拟化”专注解决底层表无序增长的问题。它们完全可以融合，诞生出第六种技术方案。

回顾

大模型的出现，实际上将各数据智能厂商原有的核心竞争力进一步放大和增强。这也印证了开头那句话：仅靠大模型本身很难形成壁垒，真正有价值的是结合多年深耕的场景和数据处理技术。每种方案都有各自的优势和适用场景，而大模型的出现，好像改变了很多东西，又好像什么都没改变。就像这个突然降温的季节，外界温度似乎在提醒我们自然的沉默与恒定——万物在不断变化，但有些东西永远不会改变。在技术领域，一股由人类智慧燃起的暖流正在悄然升起，它在自然的包容中闪耀，与宇宙长河的亘古定律和谐共生。