导读：ChatBI目前是AI在企业应用中比较火的一个方向，然而这个术语是国内厂商发明的，国外并没有这个概念（和中台一样），不过在LLM结合BI的产品设计上，国内外都有相似的实践。
本文尝试探讨AI（主要指LLM）在企业数据分析场景的相关话题，文中既会给大家展示我当年屡试不爽的土鳖但管用的图形观察数据分析法（囧），也会分享我对ChatBI类产品在企业应用价值的思考和观点。PS：周四晚上九点我会直播，展开讲解本文的案例和文中观点，直播方式见文末。- 体验：ChatBI介绍与典型产品分析（Tableau、PowerDrill、帆软、火山引擎等）
- 观点：ChatBI在企业级数据分析场景是否具备实际价值？
做IT的都知道，企业经营领域的数据分析，不是单纯的数据分析工作，首先要解决多数据源异构系统的数据治理、管理、整合问题。ERP有订单数据，CRM有客户数据，SRM有供应商数据，而商城系统又有重复冗余的客户数据；企业需要从整体经营的角度和层面，理清楚公司对业务指标的定义，形成一致的数据指标口径，并且梳理数据来源，确定数据的准确性、唯一性，这些工作都是IT团队必须要解决的脏活累活。随着企业应用架构的发展和沉淀，上述问题解决起来绝非一朝一夕之事，更不可能由AI轻易解决。所以，我们要首先明确一点：任何BI产品或者AI产品，都不可能一招制敌的解决企业经营过程中数据治理和数据应用挖掘问题。本文目的不是探讨企业数据治理和数据架构，只是想在文章开头先澄清一个基本认识：如果企业自身信息化都没做到位，数据治理混乱，那么想通过AI挖掘数据那就是无稽之谈。那么，AI在企业数据分析挖掘中哪些场景存在实际价值呢？大家看下边这张图，是我简单绘制了企业经营中挖掘应用数据的几个工作方向。首先，要有良好的数据架构，通过数据仓库、主数据等手段完成数据的治理和管理，提供扎实的数据底层底座，这部分工作和AI一点关系都没有，是又枯燥又无聊又重要的IT基础工作。有了数据底座，接下来就是上层应用分析，我分为两个场景：1、碳基人通过BI等软件，人工分析挖掘数据，这里包括了高管、业务主管、业务一线、数据分析师、产品经理等角色，通过BI、多维洞察、即席查询、Dashboard、日报表、Excel等方式，完成数据分析和应用。2、硅基人（AI）直接完成数据的挖掘和分析，给出结论或产生能应用的业务策略，例如数据解读，或者智能推荐策略等。要注意，LLM只是AI中的一种技术，很多AI策略算法用的都不是LLM，例如骑手调度是一个规划求解问题，商品推荐使用的是深度学习。国内厂商提出所谓的ChatBI的概念，主要覆盖上图中灰色板块的内容，即：1、对话式BI：在传统GUI（Graphic User Interface）BI中融入了对话式人机交互（CUI，Conversational UI），从而期望用户能够以自然语言的方式更方便的获取、洞察数据。2、LLM数据洞察：通过大语言模型解读数据，给出深刻的业务洞察。如果要讨论ChatBI的业务价值，需要将这两个应用方向分开讨论。
ChatBI分析洞察业务数据，本质上调用的还是大模型的能力，接下来，我们做一个小实验，来观察大模型的数据分析能力到底如何。在企业经营数据分析中，跟踪业绩变化趋势，及时发现其中的异常和波动并分析原因，是一个典型的数据分析场景。我让ChatGP模拟生成了300条订单数据，并对生成的数据做了略微的手工调整，得到了一份待AI分析的数据集，这里边我植入了以下业务特点：
我以前一直很喜欢瞎捣鼓数据分析，也很享受这个过程，不过我都是野路子分析法，直接把数据做成图表，肉眼观察其中的现象和问题。这个方法虽然比较土，但也挺有效。我记得读MBA时教统计学的老师就讲过，数据分析工作，学一堆理论知识没有用，关键要有分析意识动手习惯，大多数情况下单纯做几张图表就已经能解决工作中的很多问题了。第一步，先观察数据的特点，做一张散点图，看看数据中的异常值，如果需要，还可以算一下方差看看数据的离散程度。下图展示了数据的散点图，可以看到有六个异常值，交易额远远大于正常订单，实际上这六个点都是我手工改过原始数据的上海的交易数据。第二步，制作折线图，观察整体销售额和分地区销售额变化趋势，如下图。绿色的粗线，是副坐标下的整体销售额，其他细线，是主坐标下的分地区销售额。可以看出，整体销售额在增长，各地区销售额在增长，只有上海的销售额在下降。绘制月销售额变化趋势图，发现全国城市只有上海在下降第三步，分析上海的销售额为什么会下降，一般会对数据进行各种维度的下钻和交叉分析，使用数据透视表，经过几轮测算，发现上海的数码品类交易额占比大，且持续下降，导致了整体销售额的下降，如下图。至此，我们演示了传统的土鳖图形分析法对数据的洞察，虽然老土，但是好使。现在，有了LLM，我们来看看AI能不能直接帮我们分析其中的现象和原因。我把这份数据分别扔给了ChatGP、Claude、豆包、DeepSeek、PowerDrill（一款国外的ChatBI产品），我们来看看分析效果（提示词都很简单，就是让AI分析数据背后的业务现象和原因）。下图是ChatGPT结论，把我偷偷设计进去的几个异常点都挖掘出来了，包括金额过大，上海地区下降，原因是数码品类下降。接下来是Claude，结果不是特别理想，发现了订单异常，但是没有描述全国唯一出现销售额下降的上海地区业务波动；而且观察分析的角度更多是从品类占比和区域占比展开，而非从月度业绩趋势变化。接下来是豆包，对数据波动有分析，但没有明显提出我期望的对上海的观察和分析。接下来是DeepSeek，他也是从整体业绩变化和品类、区域占比变化的角度分析，而没有提出上海异常于其他区域的业绩下降。以上只是尝试了直接使用大模型分析，实际上我很想尝试专业的AI+BI工具的效果，但是不论是Tableau、Qlik还是帆软，DEMO都不支持导入数据进行数据洞察，只能作罢。不过有一款国外的创业产品PowerDrill，也是国外少有的把自己定义为ChatBI的产品，他们提供试用版，并支持上传数据分析，于是我测试了一把，但效果非常不好。不知道他们具体用的是谁的LLM，给出的结论是一堆车轱辘话，夹杂了一些炫酷图表，但没有任何有价值的洞察，如下图。一款国外ChatBI产品PowerDrill的分析整体来看，大模型对数据的分析洞察能力还是很不错的，虽然不同模型给出的思路和侧重点不同，但我相信在合理提示词和领域知识的加持下，业务问题识别和归因分析，都可以达到初级数据分析师的水平。根据我和专业数据分析师的交流，大家的观点也是AI可以达到初级分析师水平，但在实际业务环境中，可能对分析的深度要求更高，初级的分析和洞察在业务决策上价值有限。 企业级场景下的AI数据分析：ChatBI的技术原理 上边的实验只是对简单数据集的测试，在企业级软件环境中，让AI分析数据更复杂一些，因为AI需要理解分析的诉求、数据的来源、指标的定义、口径的计算等等要素。其中，检索数据，不是简单的扫描数据库拿到结果，而是要根据语境、语义做预处理，例如，针对销售额指标，到底要不要包括退货数据？口径如何定义？什么分析场景下选用什么口径？让AI处理这些问题，需要更加谨慎。行业中针对检索数据这个环节，有两种技术路径，分别是NL2SQL和NL2DSL。NL2SQL（Nature Language to SQL）：将自然语言理解后直接转换成查询数据库的SQL语句，基于对数据库元数据的理解、表结构的理解，生成正确的查询语句，逻辑如下图：NL2DSL（Nature Language to Domain Specified Language）：将自然语言首先转换为某个领域下的专业查询语言，再进一步查询数据，相当于加了一层语义处理，这也是当前AI+BI主流的处理方案。两种方案的优缺点对比如下（来自Google AI）：NL2DSL是一个很宽泛的概念，具体不同厂家实现时都有自己的处理模型。以Tableau为例，其采用了一种叫做VizQL（Visual Query Language）的技术，根据其介绍，Tableau的前端编辑器中用户做字段的拖拽、调整，维度的上卷下钻，Tableau都会将动作转义成所谓VizQL语言，从而进一步进行数据查询。而Tableau的Agent，理解自然语言的检索诉求后，也会首先将其转换成VizQL，再进一步处理。下图是处理过程。不同厂商的DSL处理模型与理念不尽相同，可以参考下表对比（依然来自Google AI）。
国内外BI厂商针对AI+BI的应用场景和核心逻辑框架是类似的，但是国外产品并没有所谓ChatBI和问数的概念。
国内的BI厂商大多数都将所谓ChatBI发布成为独立产品宣传，而国外BI则只是将AI融入后对产品主体进行升级，而不会单独包装成ChatBI或者Agent产品单独售卖（Salesforce Tableu、微软PowerBI、Qlik均是如此）。
我最早接触Tableau，是在十几年前，上班摸鱼时，下载了Windows客户端版本。当时的Tableau更像是一款个人数据处理工具，大量丰富的图形化组件让我震撼无比，带薪学习了Tableau所有的功能。后来，Tableau被Salesforce收购，我也好久没有用过。最近重新捡起来，发现他已经更像是一个企业级BI软件。Tableau在Salesforce的产品线中占据非常重要且核心的地位，在收购Tableau之前Salesforce就已经有非常强大的BI产品和报表产品，目前Sales Cloud等主产品中依然在使用，但是Salesforce将Tableau放在一个核心且醒目的位置，下图是Salesforce整体产品线架构。Tableau使用企业邮箱可以免费注册体验，遗憾的是，我进去捣鼓了半天也没把Tableau内置的Agent调出来，如下图，他本应该在右侧呈现后可以访问，但Tableu继承了Salesforce同样的复杂性，巨复杂的配置后台，搞了半天也没有调好，于是我放弃了，只能给大家把演示视频的DEMO截图进行介绍。Tableau内嵌的Agent（看起来应该就是Agentforce）如果你仔细研究Salesforce的产品架构，会发现其中蕴藏着迷人的架构之美，一个个产品就像精巧的零件一般组装在一起，构建了整体的产品蓝图。围绕Tableau的BI应用解决方案，Salesforce的Data Cloud提供了数据底层处理能力，Einstein Trust Layer提供了数据的安全机制，而Agentfoce则是主推的融入Salesforce主产品Portal的Agentic Agent能力。下图展示了Salesforce数据架构的理念：Salesforce在数据层和应用消费层之间加入了语义层，也就是前边提到的NL2DSL中的DSL，当然Salesforce的语义层不单纯是为了NL2DSL服务，而是数据架构中很重要的组成，具体可以参看下图：Tableu推荐通过Salesforce主推的Agentforce实现数据和业务场景的融合（关于Agentforce的介绍可以看我之前写的文章聊聊Salesforce Agentforce产品）；根据Salesforce介绍，Tableau Next产品构建了一个叫做Concierge的AI能力，实现Tableau的数据分析体系和Agentforce的融合，给用户提供可视化、可编辑、可执行的对话式数据分析上下文。在Salesforce的主产品门户中，用户通过Agentforce，询问业绩情况：Agentforce返回了业绩结果，当然背后经历了NL2DSL的查询机制，以及Concierge对数据的封装和呈现。用户在Agentforce中点击View in Tableau，打开并跳转到Tableau编辑界面，可以对图形进一步的调整处理。在Tableau中继续唤起Agent，并要求Tableau将分析结果通过Slack发送给同事。在Tableau访问Agentforce将结论发送到Slack在Slack中可以看到Tableau Agent发来的图表。在Slack继续唤起Agentforce，根据数据分析，直接创建Campaign活动。以上是Salesforce官网给出的一个Sample，展示了人机交互从数据获取到问题识别，结合GUI进一步分析数据，实现团队协作并产生落地行动方案的完整过程。下边这个截屏展示了通过对话式交互指导Tableau完成指标计算口径的定义，大家注意右边的对话框中内签了GUI界面。不过我一直怀疑这种交互是否真的好用。。。Tableau在Agent中通过自然语言定义指标口径在ChatBI的问数过程中，比较经典的挑战，是如何处理用户模糊的模能两可的问题。例如，用户可能问“最近哪个区域业绩比较好？”，这里就存在好几个模糊点，“最近”是多久？“业绩”是指销售额还是增长率？怎么算“比较好”？让碳基人提问题，总是会这么随性。在自然语言交互中，这类问题很难避免，也是必须解决的问题。大家可以仔细看下图，第一个问题是询问了一个趋势波动的归因分析；第二个问题是一个模糊提问，用户问“最好的商机有哪些？”，Agent没有直接回答，而是给用户一些引导和提示（这些引导应该来自于语义层的信息），以便明确规则。对于这类自然语言交互中模糊的提问，我试了试帆软的产品，都已经很好地解决了（或者给一个预置条件，或者进一步询问）。值得信赖，是Salesforce产品价值观中的重要关键词，尤其是针对AI和数据服务。Tableau有一个非常强大的工作台，把运行背后从数据源确认、语义层分析、到数据展示的所有的环节都呈现出来，遗憾的是我在DEMO中没有找到这个功能，只能给大家看下视频截图了。Salesforce完整丰富的产品生态，从数据底层处理（Data Cloud）到应用接口管理（Mule Soft），从低代码应用搭建（Force）到办公协同（Slack），可以说涵盖了企业软件架构的关键板块，正是在这些能力的加持下，Tableau可以更好的融入企业应用生态，这是其他任何BI厂商无法比拟的优势。除了Tableau，其他的BI厂商，在生态的整合与场景融合的多样性上就要弱很多。Qlik的Agent截图，Qlik支持试用，但需要企业邮箱，我搞了好久都没弄好，放弃了。帆软的ChatBI产品，可以很方便的试用体验，交互设计的很丝滑，很值得研究学习从架构图中可以看出，如果将Agent从数据产品中单独提出来作为一类，会显得比较单薄，不论是对话式交互，还是数据洞察，都应该作为BI整体功能架构的一部分。不论起名叫ChatBI，还是DataAgent，国内外厂商对AI（主要指生成式AI）+BI的应用主要围绕两个场景，即：除此以外，不同厂商也有不同的AI产品封装，例如业务预测、自动化策略等。与个人数据分析不同，企业级数据分析，首先要解决数据架构和数据治理问题，如果基础工作没做好，AI+BI就无从谈起，这是基本前提条件。接下来我分享我理解企业不同岗位角色数据分析的诉求和痛点：1、领导看数：我以前做BI时一直有个困惑，为什么领导看数据只喜欢看实时指标，而不喜欢看历史趋势波动，后来我自己创业管业务才理解，领导对自己的业务数据情况都了熟于心，根本不需要通过趋势图来掌握业务；领导要看的就是当前关键指标的情况，同环比的对比，从而及时掌握业务情况，做出调整和改变。领导（大领导）很少自己取琢磨研究数据背后的现象，总裁办或者分析师团队帮领导完成数据分析和洞察，所以手机版dashboard可以解决绝大多数领导看数的诉求。2、业务人员看数：大多数业务人员根本不看数据，也不在意数据，现实情况是，即便你把数据做好贴在对方脸上，对方也懒得看。业务人员不喜欢看数据，原因并不是数据不方便分析，而是真没有这个习惯。对于管理软件，我认为数据产品建设最重要的目标是把分析业务解读数据的最佳实践沉淀固化后贴在业务人员桌上，让她不动脑子不用自己分析就知道咋回事，千万别让业务人员自己分析数据，而应该告诉他结果和该做什么。所以针对业务人员，封装了最佳实践的dashboard与固化报表是首选，而落地的难点在于培养对方看数据跟踪业务的习惯和意识。3、分析师看数：分析师要做深度的数据洞察，复杂的BI工具和Excel以及各种统计分析软件是标配。中高级分析师不可能用ChatBI的方式问数，也不可能主要依赖AI给的结论。综上所述，我认为ChatBI类产品在某些场景下做辅助分析可以有效提高效率，但并不能完全代替传统分析方法；另外重视并应用数据是企业文化和员工素质决定的，工具只能打配合但不是决定性因素。对于劳动密集型工作者，例如地推、客服，业务人员可能更需要设计好的分析数据贴在自己面前（都不一定看）。对于智力密集型工作者，例如基金经理、业务主管，业务人员可能更需要灵活的数据分析工具支持自己做数据洞察。以上只是我个人不成熟的见解，欢迎大家在评论区留言讨论，说说你的观点。
