本文探讨了大模型与商业智能（BI）平台的结合方式，涵盖数据处理、分析及应用三个层面的能力应用。介绍了短期、中期及长期的实现路径，并通过保险与证券行业的实际案例展示了自然语言交互、指标生成及报表自动化的落地效果。同时分析了实施中的挑战与未来趋势，旨在为企业利用大模型优化数据分析流程提供参考。
大模型的应用场景日益广泛，以商业智能（BI）为代表的数据分析，已成为大模型在企业内部最先落地的应用场景之一。为了应对海量数据和高复杂度决策的挑战，越来越多的企业开始寻求将大模型与 BI 相结合的应用方案，实现对数据的深度挖掘和分析，从而更好地理解客户需求、市场趋势和业务运营情况。
本文将重点介绍大模型和 BI 相互结合时的落地方式，以及针对企业侧的具体实践案例进行解读。
首先，我们需要了解传统 BI 工具和大模型之间有哪些可以结合的地方。传统 BI 工具通常分为数据接入层、分析工具层和基于该工具平台的各种行业应用层面，大模型可以在这些环节发挥作用。
在数据处理层面，大模型可以帮助传统的 ETL 过程简化难度，提高实时交互效率。在数据分析层面，大模型可以替代拖拽交互方式，让业务用户用更简单、更高效的方式以自然语言形式与底层数据交互，来构建需要的报表和看板。在行业应用层面，大模型可以真正发挥对行业知识的理解能力，与具体数据结合，形成针对客户、特定项目、指标体系的输出，再加上数据准备，可能直接输出标准化的项目成果。
数据处理主要会通过三个方面使用大模型的能力：
目前阶段，我们仍然难以直接将底层数据库交给大规模模型处理。首先，我们主要是通过接口调用大模型来使用，而大部分大模型没有进行私有化部署，也无法传输整个数据库，只能处理元数据定义和部分模式，输出也基于该提示词的处理，因此生成的 SQL 质量取决于信息传递和提示词生成的质量。
据目前看，这部分看似技术难度相对较低，实现也相对容易。但是在处理该项时，最大的问题是很难控制分支对象的质量。因此通过大模型能力构建模型的许多环节，可能会借助这种界面入口生成 SQL 片段或者使用 MDX 表达式。
比如，我们通常在模型构建过程中通过人工调用许多来生成，这对于大多数用户而言具有一定的学习和掌握难度。如果我们能够通过学习和微调使掌握此能力，则可以帮助我们完成此项工作。
接下来再聊聊数据分析层面大模型能力的使用。在这个环节中，直接与最终业务用户或需要使用数据的用户交互的形式，是通过自然语言对话形式进行数据的查询、分析和利用。从技术上来看，这个环节成熟度相对较高，因为商业用户自主分析工具已经发展了很多年，尤其是这种交互方式不断落到底层，接口越发完备。
我们只要让大型语言模型本身去帮忙理解这种语义，并与传统能力相结合，就可以让使用过程相对简单易懂。我们知道，此前数据分析大部分能力都是通过传统的 NL2SQL 方式来实现的，那么这其中大语言模型矩阵的哪些环节发生了作用呢？我总结出了以下两点。
我们期望让大型模型可以更精确地理解用户的输入，特别是针对那些常识性的问题。以传统的 NL2SQL 举例，它难以解决像'作为一家公司，我想查询公司内部有多少本科以上学历的员工'的这种问题。
虽然该模型可以准确地识别'本科'这个词，但对于'本科以上'这四个字的理解就有困难了，因为它代表的是一个字符串类型的字段，而无法简单地通过大于等于号等操作符进行筛选。
然而，一旦引入了大模型，就能够很好地解决这个问题。它可以准确地告诉我们'本科以上'代表的是本硕博学历，只要将该信息带入生成的查询语句的过滤条件中，就能够得到我们所需的结果。
以上只是一个小例子，我们期望大语言模型能够帮助我们处理与特定行业领域知识相关的常识性问题，这样将其与传统的 NL2SQL 相结合，将有助于提升其语言理解能力，同时也能提高数据结构返回的准确性。在大语言模型出现之前，我们也可以解决类似的问题。然而，过去的项目实施通常需要依靠项目化的方法，通过不断的配置和人工微调的方式来解决查询模板无法处理问句或需求的问题，导致项目实时交付的周期长、功能投入大，长期需要运维人员持续维护。而现在，大语言模型具有自适应学习能力，可以缩短实时交付周期，以最终降低成本。
如果能够将底层的数据库，特别是 OLAP 或大数据平台直接开放给大语言模型进行学习或微调，那么是否就能够准确地处理用户的智能问句，并获得用户所需的答案呢？实际上，这可能不太现实。在传统项目实施过程中，即使是最熟悉数据库结构的人，也会发现对底层数据库的处理过程存在困难。
首先，语言对于同一个指标本身的理解其实不是技术问题，而是一种业务决策。为此需要业务协助去确认数据处理口径和结果的正确性，这个过程很难完全通过技术手段解决，因此我们必须在原始之上构建智能模型。只有在最终业务用户确认数据指标和对应维度的情况下，才能将这个模型交给大语言模型，以便查询所需的结果。如果没有进行这些工作，那么直接开放将会得到缺乏解释性和不准确的结果，用户会很难理解。
其次，在底层关系数据库上很难进行一些复杂的计算。例如，同比和环比的始点值、期末值，以及全年累计等指标的计算都无法通过 SQL 的能力进行计算。在这种情况下，大型语言模型也无法满足这些需求，因此需要在模型层面具备此类能力。通常会倾向于建立多位数值的模型，并利用其计算能力来处理这些复杂的派生指标。只有在具备这个前提下，我们才能使数据处理变得更加顺畅。
最后，我们最渴望的是让大语言模型本身去帮助我们准确理解用户意图，并进行一层中间处理最终与模型综合起来。固定的模型需要特定的语言，只需要让大语言模型理解我们的即可。
如需实现对用户的支持，必须有某些自然语言方式的交互和底层数据交互的先决条件，以下几个条件满足才能确保最终权威可靠的结果，并获得最终用户的认可：
在大量的项目实时交付过程中，我们发现不同行业都有自己的指标体系，而用户常看的目前只有少数行业专家能够完全理解。实际上，现在这些知识被认为是行业通用知识，大语言模型也对它有一定的了解，GPT-4 通过对行业指标体系的理解，输出的结果已接近于行业专家的水平。
将这种能力与客户需求相结合，我们可以做些什么呢？最理想的目标，我们可以通过利用大模型对行业通用知识和指标体系的理解，结合与客户项目的数据，输出针对当前项目的指标信息。结合具体的数据再利用基于指标体系的实时方案或实时工具，可以输出一个直接被当前项目使用的指标模型。
指标模型做出后，下一步主要工作就是往指标库里灌输数据，在这个层面利用大模型的助力，就能让这项工作高效完成。据我们的研究，如果这种实施方式落地，将会缩短项目建设周期从现在的三个月到半年的时间，缩短至一两个月甚至更短。虽然输出的结果可能不会完全满足客户的要求，但至少可以作为项目实施的一个起点。这在很大程度上缩短了项目实施周期并有效地降低了成本。
前面提到的是技术结合的若干要点，下面我们来探讨一下如何在具体项目中将大模型和 BI 结合，实现路径中都有哪些。在我们理解中，实践应用大致有三种不同的目标，分别是短期、中期和长期的。
就短期目标而言，我们希望通过智能问答的方式与传统的数据分析应用相结合，以及自然语言对话的方式，使普通业务用户能够更简单、更高效地与底层数据交互查询，获取所需结果。中期目标是将其变成面向技术人员的数据处理工具，通过对话交互的方式加快数据梳理流程。至于长期目标，则是通过实现 BI 系统的完整构建。
实际上，在当前阶段短期目标是最容易实现的，因为我们在之前已经有了很好的数据技术基础。对于许多企业而言，最差的情况仍然是已经拥有自己的 OLAP 或大数据平台，并且有一部分已经构建了指标体系。此外，刚才提到的技术本身也已经非常成熟，比如已经出现多年，并且早期已经有大量的项目实施。
结合大语言模型后，它本身输出结果的质量也会更上一层楼。它可以有效地支持项目开发周期，快速看到成效，特别是适用于这种项目的快速优化和迭代。实际上这种能力相对基础，本身不仅可以集成嵌入以前的工具，还有许多其他的应用。例如，它甚至可以作为一个完全独立的应用，比如市面上许多厂商推出的面向普通业务用户的个人数字助理。只要与企业内部的标准数据模型和指标，用户就可以随时随地以各种方式交互数据。
而中期目标的实现主要是通过自然语言进行自助式的数据探索。这种能力可以集成到任何 BI 中，并将其应用于第三方系统。例如，我们期望将该直接引入传统的数据处理过程中，利用类似现有界面或传统编辑方式进行多轮对话，基于之前的查询结果进行一些子查询，同时对查询结果本身进行一些学习建模，从而创造更丰富的数据处理能力并降低数据处理难度。
而最后的长期目标当前处于行业探索阶段，需要等待技术进步和突破。
第一个案例客户是一家国内规模较大的保险公司。当时该公司为高层领导制作了大量的手动移动端报表，大约有 150 张左右，但对方表示报表数量太多，在手机上很难找到对应报表。
因此客户当时的需求是：
针对这两个需求，我们可以对上海分公司的新业务单价值总和、订单价值排名前五的子公司表格进行对比，以及比较上海分公司和北京分公司近五年的新业务单价值情况。就像刚才简单的三轮查询一样，其中可能已经有现成的报表了。如果我们按照当时的匹配原则，优先匹配已有的报表，如果这些查询不能命中现有的报表，我们就去尝试创建新的报表。
项目推进过程中我们发现，所涉及的保险行业具有许多专有术语，如前述'新单'一词，这些术语的底层定义可能并不具有特定的维度，那么如何应对这个问题呢？我们需要在旧的模型训练界面上进行人工微调，将这些术语全部定义好，甚至在出现同义词时，也需要处理这些同义词。随着大语言模型的引入，我们现在可以针对保险业这个领域训练出大模型，然后进行微调，从而在较短时间内交付此类项目，并对项目进行优化，从而使效果更佳。
第二个案例客户是国内比较大的证券公司。在大模型受到广泛关注后，年初时有非常多的金融机构都开始尝试要引入相关技术。我们发现，这类金融机构最大的特点是数据质量相对较高，其所需的模型和指标早已建成并具备完整性，只要把我们的产品与现有模型结合对接，让这种能力直接集成到企业内部的 App 中，最终这个项目也是在短时间内迅速上线。客户员工日常的工作主要通过语音对话方式查询获取数据，摆脱了传统的报表或敏捷 BI 的查询方式。通过拓展方式生成图表，最大的改变是让交互方式变得更加简单、查询更加高效。
尽管大模型与 BI 的结合展现出巨大的潜力，但在实际落地过程中仍面临诸多挑战。
企业数据往往涉及核心商业机密，直接调用公有云大模型存在数据泄露风险。解决方案包括采用私有化部署的大模型，或在数据传输前进行脱敏处理，确保敏感信息不离开企业内网环境。
大模型可能会产生'幻觉'，即生成看似合理但事实错误的内容。在数据分析场景中，这可能导致错误的决策建议。需要通过 RAG（检索增强生成）技术，强制模型基于企业知识库和真实数据回答，并引入验证机制，对关键指标进行二次校验。
实时查询要求低延迟，而大模型推理可能带来额外耗时。优化策略包括缓存常用查询结果、使用轻量级模型处理简单任务、复杂任务才调用大模型，以及优化网络架构。
随着多模态技术的发展，未来的 BI 系统将不仅限于文本和图表，还能支持图像、视频等多源数据的自然语言分析。此外，Agent（智能体）技术的成熟将使大模型不仅能回答问题，还能自主执行数据清洗、报表生成甚至业务流程自动化操作，真正实现从'人找数据'到'数据找人'的转变。
综上所述，大模型正在重塑 BI 行业的格局，为企业提供更智能、更高效的数据洞察能力。企业在拥抱这一技术变革时，应注重基础数据治理，选择合适的落地路径，并持续关注技术演进带来的新机遇。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
