AI4DATA，生成式BI能力现状观察和业界实践探讨

背景

DATA for AI，还是AI for DATA，BI要不要抱AI的大腿，对于大数据领域从业者来说，这是个问题。

要谈生成式BI，那还是得先提一下生成式AI，作为近两年科技圈的当红小生，Generative AI可谓风头无俩。什么是生成式AI呢，宽泛的来说，Generative AI泛指各种能够进行自主内容创作和生成（AIGC）的人工智能技术和产品。

这其中最典型的代表，当然是以大语言模型（LLM）为核心基础能力的各种文本生成类应用，以及以Diffusion模型（LDM）为基础的各类图像生成类应用。

在这些生成式AI以及过往的各类传统机器学习算法的场景链路中，AI和Data的关系，基本上是一个BI数据加工链路（数据采集，加工，可视化）服务于AI业务应用（训练，验证，Serving，结果采集，反馈）的过程。Data for AI，用BI的能力来辅助AI，这个相对关系，在过去的十几年里，基本没有变化。

只是三十年河东三十年河西，所以当AI风头正劲，一票大佬喊出所有的应用都值得用AI重新改造一遍的时候，BI也就不甘于只是替人打工，为他人做嫁衣了，很自然的也希望能抱上AI的大腿，分享一波风口红利。

于是就有了生成式BI（Generative BI）的概念，也有仿照ChatGPT叫DataGPT，ChatBI之类的。对应的基本思想就是AI for Data，即用AI的能力来实现BI产品或业务的智能化。

在继续下文，讨论生成式BI的具体能力现状之前，先对本文BI术语的定义做个补充说明。

狭义的BI产品，通常指的是类似PowerBI，Tableau，帆软，QuickBI这类可视化报表数据分析产品。

不过在本文中，在AI for DATA的话题时，更多的是用BI这个术语概念，泛化的指代整个大数据数据工程链路的概念，在多数企业中，对应的是大体是类似数据仓库，数据工程，商业智能这样的团队的工作，涉及的产品等（作为对比，AI的概念对应类似算法，推荐，数据科学等团队的工作和产品）。

产品能力定义和成熟度阶段划分

以当前业界的情况来看，AI4DATA可以做些什么，生成式BI应该具备什么样的能力，适用于什么样的场景，呈现出什么样的产品形态，并没有明确的定义或共识，大体还处在一个集思广益，积极探索能力边界的阶段。

以下仅根据笔者工作实践过程中，所接触到的客户需求，业界的产品为线索，结合个人的认知和理解，谈一下从满足用户BI工作链路需求的角度来看，生成式BI可能需要具备的各种能力。同时，按照各种能力对客户商业智能洞察这个终极目标需求的满足程度，智能化程度，做一下成熟度的阶段划分。

需要指出的是，以下各阶段之间的能力整体上是一个递进的关系，但并不完全绝对线性的。因为具体产品形态和场景的定位不同，对各阶段能力的组合方式可能也不同。此外，能力阶段的递进也不等同于实现难度的递进，只是从BI业务角度来看，对最终需求的满足程度的近似的一个划分。

阶段一：Text to Sql （代码生成和Copilot）

• 能通过自然语言描述，生成特定数据库引擎的SQL代码，完成指定的目标业务逻辑

• 能够辅助代码编写，提高生产效率，如：对SQL代码进行自动补全，语法纠正，函数参数，表字段提示等

可能的典型的问题如：用hive语法创建一张典型的订单表；给定一张流量表，写一段SQL计算每周访客UV的数值及同环比。

阶段二：Text to Query （问答式统计查询）

• 能够根据用户的问题，结合实际业务数据和库表结构，生成具体的查询逻辑，执行并返回结果数据

• 能够将查询返回的结果数据，以默认的表格或固定的图表呈现出来

• 能够识别一些通用的业务术语，指标含义

可能的典型问题如：按周统计新客的回购率，按渠道统计商品动销率。

阶段三：Text to Report （问答式报表构建）

• 能够根据查询结果，自动选择合适的可视化呈现方式

• 能够通过自然语言描述，构建和修改各类图表组件的配置，产出符合用户需求的视觉呈现效果

• 能够根据用户的语言描述，对结果进行二次聚合，下钻分析等

• 能够结合上下文，和过往问答历史，进行渐进式探索

可能的典型问题，比如：统计最近一个月新用户的7日留存率。用蓝绿色系绘制图表，用红色标识出留存率最高的单元格，进一步按新用户不同的渠道来源下钻分析各自的留存率等等。

阶段四：Text to Insight （问答式洞察分析）

• 能够回答非简单孤立统计性问题，能够回答探寻式问题

• 能结合行业领域知识和最佳实践，生成一个或多个关联查询

• 能够根据几组关联查询的结果，生成组合报表，多角度分析呈现

• 能够对特定业务指标进行归因分析，找到潜在问题点，形成总结分析报告等

可能的典型问题，比如：本周产品的运营情况表现如何？天猫旗舰店昨天GMV下降的原因是什么？

目标客户定位和用户心理预期

上述产品能力如何实现，能否实现，在当前AI和大语言模型能力范围内，要满足上述能力需求，有什么困难，障碍和挑战？用户的心理预期和产品能力现状能否匹配呢？

要谈这个问题，那就得先从目标用户定位的角度，做一下划分，大体上，目标用户群体可以分为两类

第一类，是有一定SQL代码开发或理解能力，偏数据开发或数据分析师角色的同学，他们对相关产品的需求，大致可以定义为开发过程中的Copilot助手或加快完成自身开发任务的提效工具，整体定位上，偏向于AI辅助人。

第二类，是没有代码编写能力(或者不想编写代码），偏运营或业务，管理角色的同学，他们往往希望相关产品能够代替开发同学，完成数据加工，分析，探索并给出结论，整体定位偏向于AI替代人。

人群不同，定位不同，用户的预期和要求标准自然也不同。两类人群固然都需要对应的产品能够尽可能给出正确的结果。但对于前者，用户更多关心的是数据加工过程的正确性，过程本身需要足够白盒化，你能告诉我这段SQL逻辑该怎么写，帮我完成一些明确的任务，加快报表开发的速度，提供一些问题思路等等。怎么用，用不用，决定怎么做的还是人。用户是花钱买工具。

这类用户对相应产品的能力成熟度需求，多半集中在阶段一的特性，以及阶段二和阶段三的少部分提效相关的特性上。同时，因为是作为辅助工具来使用，所以往往对最终的准确度要求也有一定的宽容度。

而对于后者，用户多半更关心最终数据分析结果的正确性，至于过程怎么做，完全可以是黑盒的，用什么语法，函数，数据从哪里来，效率高不高，如果可以，用户多半并不想关心，甚至可能也不懂（当然，这是基于这类产品能建立起足够的信任度的基础上来说的）。用户是花钱买结果。

由于当前大语言模型在其他文本生成领域的惊艳表现，这类用户往往会高估大语言模型在BI领域的效果能力，因此对于相关产品的表现预期通常也是比较高的，也就导致对实际产品能力的较大的心理落差。

按照上述成熟度阶段定义，他们往往预期产品落地就能很轻易的具备阶段四的能力（毕竟，是希望用来替代人的工作的），但在实际实践中，很有可能磕磕绊绊的能在局部场景完成阶段二能力Demo就已经很不错了

挑战在哪里，困难的根源是什么

那么，这种预期的落差，问题出在哪里呢？这其中的差距，将来能否抹平，如何抹平呢？

要回答这个问题，我们首先来看看当前大多数生成式BI的解决方案背后，所依托的大语言模型的能力特性，擅长什么，不擅长什么。

笔者个人一向的观点是：当前的大语言模型，不管采用了什么Transformer模型，还是Attention的机制，究其根源，并没有摆脱其信息压缩器和概率检索的本质，并不具备真正的逻辑推理能力。

所以，虽然大语言模型优秀的信息压缩，检索，关联重组（基于概率合理性）能力，使得其在语言理解和文本生成方面表现出很强的实用性，并一定程度上呈现（涌现）出了具备逻辑思考能力的假象。但归根结底，大语言模型只是给出了符合概率最大化的文字组合，对于这个文字组合的真正含义，并没有哪怕一点点的的认知和理解。

这也是为什么，大语言模型的幻觉（hallucination）问题（一本正经，胡说八道）至今没法根治，因为严格来说，这并不是大语言模型的Bug，而是它的工作特性（概率推导）。对于幻觉问题，人所能做的，只是通过一些辅助信息对模型的输出进行约束和限制。

但巧的是，人类的语言表达，本身合不合逻辑，通不通顺，自不自恰，在某种意义上来说，很大程度上，就是一个概率组合问题（大家的共同认知，约定习惯等等）。而且纯粹的文本表达，是一个非常主观的事情，没有绝对客观的对错。更不用说，部分的文本创作场景，追求的还是文字排列组合的创新，所以概率组合有时候还能出乎意料的推陈出新，因为它没有推导的过程，也不存在思维定式。类似的，这也是为什么在图像生成这种“艺术”领域，Diffusion这种概率分布模型的效果尤其的好。

因此，尽管存在幻觉问题，但是在大语言模型训练过程中输入了海量的文本信息以后（据说，目前OpenAI模型的训练很有可能已经离可用于输入的通用有效信息的上限差得不远了），计算推理产出的内容，往往从主观感受上具备很强的合理性和逻辑性。

回到生成式BI的问题上，为什么大模型在文本和图像生成领域的惊艳表现，到了这里的应用效果，就不尽如人意了呢？个人认为这是因为目标问题域和环境不一样了，简单罗列几点：

• 如前所述，大语言模型本身，更多的是语言概率逻辑的关联能力，而不具备推导能力，所以并不适合需要精确逻辑和确定性规则推理的问题（举个简单的例子，随便一个计算器都能计算的加减乘除四则运算，你让大语言模型试试看，你会发觉稍微长一点的数值的加法问题都做不出来）

• 大语言模型训练过程中所压缩的大体是通用的文本Token概念和他们之间的关联关系，而数据分析的场景针对的大多是数字，甚至文本信息，没有文本信息和数据之间的关联关系，仅通过通用知识，很难通过概率拼凑出正确的答案

• 不比语言文本表达，没有绝对对错。数据加工分析的逻辑，是一个有绝对对错，非0即1的场景，任何细微的幻觉问题，都会导致错误的结果

• BI分析，作为一个处理特定数据信息的应用场景，不只是一个通用的与环境无关的普适的技术问题，更多的是一个具体的和上下文语境密切相关业务问题，需要领域相关知识和足够的业务信息进行辅助

这么说可能比较抽象，我们可以结合前面几个阶段的成熟度阶段的能力列表，对照一下，如果人要完成对应的事情，会需要具备什么样的前置条件，当前大语言模型有没有可能具备

比如在阶段一，Text to SQL的能力：

基本上，要做到较高的正确率，首先要求系统精确的掌握特定计算引擎的SQL语法。对于通用大语言模型来说，实际上它只能通过训练过程输入各类SQL代码来获取相关的信息。但他不像人，可以有选择的定向学习特定的绝对正确的信息（比如特定数据库指定版本的语法手册），所以它所获取的信息中，必然存在大量的偏差和噪音。这个问题当然可以通过一些办法来缓解，这个我们后面谈方案的时候说，但本质上，这导致了其学习的内容本身就是通用的，模糊的，非定向，非绝对精确的，那你就不用指望它产出的结果能做到100%精确了。

其次，在掌握了SQL语法的基础上，还要求系统掌握业务逻辑和具体SQL表达逻辑之间的映射关系，才能给出最终的SQL语句。

比如：给定一张流量表，写一段SQL计算每周访客UV的数值及同环比这个问题。由于大语言模型本质上不具备推导能力，所以只能通过见过类似的描述信息和对应的代码（不一定是直接的，也可以是多个概念间接关联的）之间的概率关系，把这段文字和group by， Week，UID， count distinct，子查询，计算差值之类的代码建立关系，并产出代码。

这个过程有太多的概率关联，而SQL逻辑的表达一方面极度灵活，另一方面对正确性又是极度的严格，所以相关问题的具体描述一旦不是那么常见（常见指的是文本概率上的角度来说的，比如网上总有人问的类似的问题），大语言模型按概率计算输出结果基本就歇菜了。（实际上，哪怕类似上述计算UV环比这样并不算太难，且非常普遍的问题，你不妨试试看，目前的大语言模型在经过反复提示之后，也几乎都无法写出完整正确的逻辑）

再比如阶段二的能力：Text to Query

相比阶段一的能力，这要求相关产品产出的结果不再是纯粹的文本层面对自然语言翻译转换。而是要求相关产品能获取和结合用户的实际库表结构信息，来给出精确的在实际系统中可执行的逻辑。

这里的难点其实还不在于获取库表结构信息，当前常见的做法，大体都是通过构建固定的提问模版，在喂给大语言模型的Prompt文本中，除了用户问题以外，同时添加库表结构信息的方式，来改写提问的文本。比如：假设你是一个BI工程师，基于以下表结构信息，撰写一段Spark SQL，回答如下问题：xxxx（用户的问题）之类。

当然，如何选择正确的库表的表结构信息喂给大语言模型，这个步骤，其实就已经有不小的挑战和难度（这本身就是一个如何把输入文本和信息检索建立起正确关联的问题，不少产品其实都没有自己解决这个问题，而是由用户选择具体的表，或者干脆一股脑把所有表的元数据信息全部发给大语言模型）

但更大的问题还是在于模型本身，即使获取到了正确的库表结构信息，如何能够把这些信息和所问问题的业务逻辑以及模型中压缩的通用知识信息对应上

比如：字段列表中 user，customer，buyer，name，ID哪个指代用户问题中的人？这种映射关系从源头上就不属于客观通用的具有唯一正确性的知识。而是具体场景，具体问题，具体数据表格下的个性化的信息。所以，通用知识和特例化信息之间的映射也就不是唯一绝对的。也就是说如果没有附加信息输入，这个模糊性对于大语言模型来说，是很难消除的。更不用说，在客观实际生活中，用户的库表结构的命名可能还是混乱或者非标的，这种情况下，哪怕是具备推理能力的人，都有可能无从下手，更不用说AI了。

至于阶段三尤其是阶段四的能力，可能面临的问题就更加复杂了：

设想一下，你是一个外星球的语言学专家，猛然间给你一个地球上某公司的数据库，里面有几百张表，并且用这个奇怪的地球文字给你发出了一串文本。虽然你不理解这些文字在地球的现实生活中代表了什么意思，但你有一个优势特长，就是你看过了这个星球上所有的文本，你知道这些文字在概率层面上是怎么组合的。然后，你需要根据你看过的内容，回复一段信息，尽管哪怕你自己也不知道自己回复的这段信息到底是啥意思。。。

大语言模型面临的处境与此类似，只会更难，因为前面说了，它甚至连推理能力都没有。

事实上，在没有掌握特定领域知识经验，或者了解公司特定业务逻辑，运营流程的情况下，哪怕是一个经验丰富的BI工程师，空降到一家公司，仅看库表结构和元数据定义，想要完成他的工作，都有可能是一个很困难的事情。

业界产品分类和实践探索

难归难，问题还是要解，前面说的困难仅仅是针对大语言模型本身的能力特性来说的。

尽管这波生成式BI应用的起源是由于大语言模型的出现引发的，但是在构建生成式BI产品的过程中，谁说只能使用大语言模型呢？实际上，有些环节可能也并不适合通过大语言模型来实现，大语言模型只是可能的核心组件之一，但不代表全部。此外，有些问题，也未必只能通过技术手段来解决，也可以由人来解决，而不是都交给AI，至少目前如此。

接下来，我们来看看，在AI4DATA，生成式BI的思路下，业界常见的产品，大概包含哪几类，当前的实现方式，都面临哪些问题，可能的解决思路，发展方向等等：

辅助编程类产品

这类产品大体，或者以代码编辑器插件的形式存在（比如：Github Copilot，Codeium，CodeWhisper，国内的通义灵码之类，多多少少都能支持一些SQL语法问答），或者是一些集成开发平台内置的产品能力（比如：Deepnote AI Copilot，Dataworks Copilot），或者是一些独立的NL2SQL或数据库客户端工具（比如：开源的DB-GPT，Chat2DB），又或者是一些DB数据库对自己查询控制台的能力增强（比如TiDB Cloud的Chat2Query）。

从能力上成熟度角度来说，这些产品大致对于阶段一到阶段二之间的能力特性。如果进一步细分，这类产品的具体功能还可以分为两部分：QA问答和代码补全

QA问答部分，面向一些开放性的问题，相对来说更加接近常见的ChatGPT聊天类应用的交互方式。这类能力如果使用到了大语言模型，那么通常大部分就是对大语言模型的一个简单封装调用，部分和数据库或开发平台定向集成的产品，还能通过传递用户选择的库表名，字段名等给大语言模型提供额外的辅助信息。

所以这类产品的具体表现，大差不差，最大的挑战，还是来源于其所使用的大模型本身，Text to Sql的准确性。

根据 BIRD（A Big Bench for Large-Scale DataBase) ：https://arxiv.org/pdf/2305.03111.pdf 这篇论文的测试结论。 对于大型数据库，当下，即使是最强模型如ChatGPT，其执行准确率也只有40.08%，远低于人类的92.96%

SQL语言自身代码正确性和外部数据信息强相关的特性，加上各种数据库计算引擎都有自己的定制语法，方言众多，导致它的难度相比于其他非SQL的编程类语言要高得多，总体的体验大体就只能算是勉强能玩。

而代码补全，则是在代码编辑框中随着用户的编辑，自动预测后续的内容，快捷补全代码或字段，函数参数等等。

这部分看起来和前者只是内容输出位置的不同，但其实本质上却有很大的区别，那就是对问答响应速度的要求和调用频次的要求。

QA问答可以容忍几秒的问答延迟，同时调用的频率也不会太高。而代码补全通常要求最多百毫秒级别附近的延迟响应，同时每敲一个字符就可能发起一次补全请求。所以很显然，当前的LLM模型的响应速度和费用开销并不能适配这种场景需求。（敲一个字符发起一次请求，花费你几毛钱显然无法接受）

所以这类产品要达到商业化实用的程度，总体会有几种思路：

• 提升准确度：针对特定引擎，特定SQL方言，特定业务领域，能否Finetune或训练出更高准确率的定制化模型（难度较高）

• 改善易用性：针对SQL代码的场景做一些针对性的UI交互适配，常见比如：QA问答框和代码编辑框之间的双向文本复制，代码编辑框中注释文本和代码之间的双向生成，对执行结果文本的错误的自动问答诊断，内置函数的使用说明等等（大体雷同，较难做出亮点）

• 降低成本，减少使用代价：如前所述Copilot的具体输出形式很多，如何在效果，性能和成本之间取得一个较好的平衡，哪些功能通过LLM实现，哪些功能通过其它方式来实现，或者完全不用LLM来实现？比如通常通过语法树解析，规则，上下文搜索，传统机器学习算法等各种方案来实现，在非开放性问题的限定场景下，可能表现比LLM还更好。事实上不少Copilot产品核心链路完全不使用LLM，或者只是在部分开放性问答场景中，局部使用少量使用LLM来做语义理解和QA问答。（LLM不是AI的唯一解，路径选择，成本性价比都是核心要素）

文件，表格数据分析类产品

这类产品的侧重点不在于代码生成，而是则侧重于对数据的分析和问答的支持，毕竟代码只是完成BI相关工作的工具而已，能直接得到结果，还要什么过程，不过因为基于文件来工作，所以定位替代对象往往是Execel之类。

比如 ：julius.ai，datasquirrel.ai，Jeda.ai等等（需要注意的是，这里面并不是所有产品都是用了大语言模型，有些整体核心逻辑还是基于领域经验和规则来的）

以文件或表格来承载输入信息，针对性问答，也绝非BI领域的大语言模型应用所特有的形式。实际上各种文本类文档问答产品，比如阅读PPT，阅读Paper，阅读会议记录，做出总结，纪要，支持问答等等，早就已经成为大语言模型的重要应用形式。毕竟这类应用形态，从根本上来说，就是LLM的强项，天然适配。

这类独立的产品实现，如果使用了大语言模型来实现部分功能，那么多多少少会使用一些类似检索增强生成RAG (Retrieval Augmented Generation)或Agent代理之类的架构方案。

什么是检索增强生成呢，通俗的来说，就是给LLM大语言模型外挂一个知识库，在提交问题给LLM之前，先检索知识库获取一些相关的资料信息，然后把这些信息和问题一起提交给大语言模型，让大语言模型基于这些信息回答问题。

这么做的目的，一方面是给大模型补充一些领域知识信息，另一方面也可以解决部分大模型的幻觉问题。这种方案，在类似Google Bard，Bing Chat之类搜索引擎的Chat AI应用中也很普遍，只不过在那里，这个外挂的知识库是以整个搜索引擎的能力为后盾的。

RAG的应用形式如此普及和相关的基础设施的普及也不无关系。如向量数据库（当然，向量数据库只是提供了一种知识检索的方案，RAG不一定非要用向量数据库），流程框架如LangChain（同样，只是方案之一），以及相关的方法论知识都已经很普及，所以这种产品形态模式，应用在BI数据分析领域上也不奇怪。

实际上如果不这么用，反而奇怪了，因为把大语言模型和用户数据关联在一起的最通用，最简单的方式，也就是通过文件上传数据了。否则，要把整个数仓开发流程和大语言模型打通，或者进一步把数据通过Finetune或者从头训练模型的方式，融合进大语言模型中，那难度完全不是一个数量级的。

那么，这类基于文件文档的BI数据分析应用产品的困难点，和能够商业化实用的挑战在哪里呢，个人感觉大体有如下几点：

• 通用大语言模型是基于自然语言训练的，相比文本类文档，从数据类文档中能直接获取的自然语言相关信息非常有限（比如可能只有字段名，或者再推理一下字段类型之类），是否能进一步从数据中获取一些统计信息进行辅助很大程度决定了产品的最终效果。

• 数据类文档的数据量可能比较大，而语言模型本身也并不能做数据加工工作，如何将数据处理的能力与语言模型进行串联，虽然有类似langchain的框架，但实际工程要考虑的不光是流程串联问题。

• 不同领域，不同类型的数据可能都有各自的分析方法论，如何沉淀和套用这些方法论，如何将其与语言模型的语言理解能力结合起来，能否结合起来，也还是一个在探索的问题。

严格来说，这些难点不仅仅是文件表格数据分析类产品所独有的问题，而是所有前面提到的能力成熟度阶段二以上的生成式BI产品都会遇到的问题。但对于文件表格分析类产品来说，它能获取的信息的手段尤为有限（其它平台类产品可能还有别的途径获取除了数据以外的业务信息），所以相关问题挑战会更加突出一些。

其次，作为一个独立的数据分析产品，这类产品的产品形态本身的创新也是非常重要的，甚至有可能数据分析只是其基本能力，对数据分析结果的输出展现形式，才是他们的差异化核心竞争力（比如做出更好的PPT，提供更好的分析模版，报告等等）

BI报表产品报表构建能力增强类

作为狭义BI概念的典型代表，可视化报表类产品显然不可能不去拥抱生成式BI的概念。绝大多数的成熟BI报表产品，多多少少都引入了AI相关的增强能力特性，但有些和LLM集成的很生硬，有些则做了较好的交互融合。相关产品比如：Tableau AI，PowerBI Copilot等等

做得好的产品，除了针对数据集进行问答式查询和自动生成图表基本是标配（虽然实际效果好坏，还有待观察提高）以外，也有不少着眼于使用自然语言简化报表的创建，和精细化定制过程。

后者也可以说是一种Text to Command，或者说免操作的配置能力，从目标上来说，当然是为了将用户从繁琐复杂的配置和较高的软件学习成本中解放出来。但目前整体感觉还是借AI的热点打造商业卖点的成分居多，其实现，大概率也未必非得通过大语言模型来承载。不过，相对于开放式问答场景，图表配置这个相对封闭的应用场景，显然还是有很大的概率是可以通过不断地积累和改进，持续优化效果和体验的。

商业智能分析型产品

相比于针对上传的数据文件和局部报表做个体的分析和问答的产品。商业智能分析型产品的定位，面向的往往就是就是更大规模，更加标准化体系下的数据分析，业务洞察和问答场景了，因此通常也都需要和企业的大数据存储，计算，开发，管理等环境进行更深度的集成，来获取更完整的信息和能力。

这种产品的能力需求，通常对应上文中阶段三或阶段四的能力，也最接近企业商业智能分析团队或者运营，管理等团队对于生成式BI应用形态的美好设想。

只不过，理想非常好，但现实中，这类产品大多还处在探索实验阶段，除了前面几类产品会遇到的问题一个不拉以外，企业自身私域业务信息，概念，术语，领域知识等等，对企业商业智能分析结果正确性的影响，可能是比上述问题还要严重的多。

所以，当前大多数对于这类产品的探索，除去大语言模型的建设以外，都把工作重点放在了指标，术语体系的建设或者业务知识的抽象和管理等方面的能力建设上。

从技术方案的角度来说，这类产品的应用场景下，RAG的架构模式基本是逃不掉的，具体怎么构建有效的RAG能力，提高相关信息的召回率和准确率或许就是最核心的困难挑战了。相比之下，SQL代码语法层面翻译的准确性等问题反而可能没有那么突出了。

从当前业界实践来看，大多数此类探索和尝试产品，距离理想中所希望的准确性还有很大的差距。问题的根源，就在于在开放性问题环境下，通用自然语言领域，各种名词，术语，概念的多义性，模糊性，非唯一性，与企业业务的领域性，个性化，灵活性，以及数据加工分析洞察所要求的精确性，唯一性，这几者之间的矛盾鸿沟很难跨越。

上述问题，如果指望仅仅依靠技术手段来解决，是不太现实的。指标，术语体系的建设，更多的是依靠人的经验和企业BI工程知识的沉淀。但这块体系的建设，目前来看，其实也缺乏快速总结归纳的有效手段，而且相关知识往往和特定问题，特定数据之间有很强的绑定关系，缺乏普适通用性，也造成短期内，场景和问题覆盖面通常非常有限，且难以快速拓宽。

因此，当前大多数此类产品，基本都还停留在Demo阶段，经过反复的工程校准，Bad Case修正之后，能够回答少量与预设问题相似，或者模板化的问题。

那么，商业化可用的生成式BI产品，是不是就完全没有可能性了呢。我个人觉得，还是有可能的，只不过，需要认清AI和大语言模型的能力边界，尊重大语言模型的客观局限性，从产品形态上，扬长避短。需要人解决的问题，提供的信息，就应该由人来处理，AI辅助BI，AI+BI，而不是替代AI-BI，人与模型，算法，各自发挥各自的特长。同时，从产品形态设计的角度，尽量避免落入无边界的开放性问题场景，缩小问题域，降低问题本身的解决难度。

业界是不是有类似思路的产品实现和探索呢？的确有的，比如，Amazon QuickSight中的AI助手，Amazon Q的产品形态和思路，个人觉得，就是一个很值得参考的对象。下面稍微做一些分析

Amazon Quick Sight Q的产品形态思路

Amazon Q中，问答是围绕着称之为Topics话题的对象来展开的，所谓话题，就是一个主题域，用户可以将一个或多个数据集加入到这个主题域中，后续用户问问题，首先需要指定一个主题域，这相当于划定了一个命名空间，对应企业的某个业务领域。这么做，相当于约束了用户的问题的边界，从而减少了不同场景，不同业务和语义背景下，各种概念的多义性或模糊性。

这其实是一种很符合客观实际的做法，此前提到的标签指标建设之类的思路，多数寄希望于企业先整理出一套全局标准统一的术语，指标定义之类来去除二义性，和模糊性。

但实际上，理想和现实之间有着巨大的鸿沟，一方面，建设一套完整，标准，规范的指标体系规范，并确实落地到实际数仓实践中，这件事对于99%的企业来说，都只是一个美好但无法落地的愿望（性价比，可维护性，历史数据问题等等）。为了一个最终业务价值还未知的QA问答能力，如果需要前置这么重的工作，实际上就是立了一个很高的门槛。

另一方面，哪怕企业有能力，有决心这么做了。由于企业自身的业务是复杂的，指标术语等体系的定义也几乎不可能做到简单唯一，举个例子，比如新客户如何定义，GMV什么渠道，含义，口径；流量指的是什么，不同场景，环节，角度都可能有不同的解释，在不同的语境中可能都是正确的，在不同的业务流程下也是需要的。那么，在系统中就必然衍生出大量近似的定义来满足不同场景的需求。

所以，实操中指望全局术语唯一和标准化，不能说幼稚吧，只能说太天真了，把现实想象得太过简单了。

所以，尊重现实，分领域治之，按需定义，零门槛起步的思路，显然就客观和务实很多。

继续回头看Amazon Q，在定义完Topic，添加好数据集以后，对于这些数据集，用户可以进一步添加和完善Topic的各种元数据信息，比如数据集字段的业务信息，以便使其“对NLP自然语言友好”，也就是给AI更多的辅助信息。比如对于字段来说，这可能包括，映射术语，定义同名词，可能的聚合算子，维度还是指标，字段格式单位，是否用于检索等等。

实际上这和一般数据标准，资产定义之类的工作所要填写的信息非常类似。数据标准，资产定义这些模块，之前都是为人服务的，BI工程师，都需要这样的信息来辅助理解数据，AI需要这些信息来正确的回答问题也就很合情合理了。指望AI通过观察数据，以及各种统计分析的方法就能够自动获取这些信息，至少目前看来是不太现实的。

再之后，用户就可以开始问问题了。对于AI问答场景来说，答案的可信性和可理解性也是让用户对生成式BI产出的结果建立起信任的很重要的一环。

Amazon Q，会把用户问题里AI认为关键的词进行标识，并和数据集里的字段进行映射，相当于对它的计算逻辑做出一个白盒化的解释。

相应的，如果有些逻辑映射方式不正确，用户可以修改相关的映射关系，统计方式，增改术语定义等等，进一步对AI的行为进行校准。对于确定答案逻辑正确的问题，也能进行标定，作为标准答案，或者后续类似问题的逻辑参考。而作为话题的维护者，也能看到所有相关问题的统计反馈情况，进一步主动对前面各个环节的信息进行完善补充和配置。

整个加工逻辑的白盒化能力和校准反馈的机制加持下，我们有理由相信，Amazon Q对相关的话题的问答，确实有可能做到用得越多，回答越准确的效果。

以上只是做一个简单的介绍，用来探讨一下此类产品当前可行的实现思路。Amazon Q其他的能力，包括后续对图表呈现的AI辅助配置等等，还有不少，这里就不再详述，有兴趣的同学可以自行去官网了解。

小结

总体来说，个人认为，当前生成式BI领域的探索和实践，无论产品形态如何变化，具体的切入点是什么，清晰的认知和界定BI工程，大语言模型以及传统AI算法或规则各自的优势强项，合理的界定各自的能力边界，才是最终能达成商业化实用目标的前置条件。

简单的来说，数据资产描述，术语模糊性去除，业务领域知识的注入，语义空间的隔离，交给人和BI链路来解决。语言的理解，相似问题的映射，结构化信息的解析，基本语法逻辑的翻译，交给大语言模型或其它AI算法来完成。

相关产品的思路不应该是取代BI工程师（至少中短期内以当前大语言模型的能力和基本原理，笔者认为做不到），而是放大BI数据工程师的工作产出。将固定的，标准化的工作，通过AI，进行更好的灵活泛化，举一反三，达成收益放大的效果。

​