大模型在企业 BI 数据分析中的应用领域与落地实践

其次，在底层关系数据库上很难进行一些复杂的计算。例如，同比和环比的始点值、期末值，以及全年累计等指标的计算都无法通过 SQL 的能力进行计算。在这种情况下，大型语言模型也无法满足这些需求，因此需要在模型层面具备此类能力。通常会倾向于建立多位数值的模型，并利用其计算能力来处理这些复杂的派生指标。只有在具备这个前提下，我们才能使数据处理变得更加顺畅。

最后，我们最渴望的是让大语言模型本身去帮助我们准确理解用户意图，并进行一层中间处理最终与模型综合起来。固定的模型需要特定的语言，只需要让大语言模型理解我们的即可。

如需实现对用户的支持，必须有某些自然语言方式的交互和底层数据交互的先决条件，以下几个条件满足才能确保最终权威可靠的结果，并获得最终用户的认可：

1. 需要对底层数据进行建模，确保模型的输出结果是准确无误的。
2. 通过模型本身提供的复杂指标计算能力解决大模型难以处理的需求。
3. 利用大模型自身精确理解一些常识问题以及我们学习模型查询语言的过程，输出高质量的查询语句，获取数据，并利用 BI 工具自身的图形展示功能呈现数据。

1.4 大模型在行业应用层的能力

在大量的项目实时交付过程中，我们发现不同行业都有自己的指标体系，而用户常看的目前只有少数行业专家能够完全理解。实际上，现在这些知识被认为是行业通用知识，大语言模型也对它有一定的了解，GPT-4 通过对行业指标体系的理解，输出的结果已接近于行业专家的水平。

将这种能力与客户需求相结合，我们可以做些什么呢？最理想的目标，我们可以通过利用大模型对行业通用知识和指标体系的理解，结合与客户项目的数据，输出针对当前项目的指标信息。结合具体的数据再利用基于指标体系的实时方案或实时工具，可以输出一个直接被当前项目使用的指标模型。

指标模型做出后，下一步主要工作就是往指标库里灌输数据，在这个层面利用大模型的助力，就能让这项工作高效完成。据我们的研究，如果这种实施方式落地，将会缩短项目建设周期从现在的三个月到半年的时间，缩短至一两个月甚至更短。虽然输出的结果可能不会完全满足客户的要求，但至少可以作为项目实施的一个起点。这在很大程度上缩短了项目实施周期并有效地降低了成本。

02、大模型 + BI 落地与实现路径

2.1 三大实现目标

前面提到的是技术结合的若干要点，下面我们来探讨一下如何在具体项目中将大模型和 BI 结合，实现路径中都有哪些。在我们理解中，实践应用大致有三种不同的目标，分别是短期、中期和长期的。

2.2 短期目标

就短期目标而言，我们希望通过智能问答的方式与传统的数据分析应用相结合，以及自然语言对话的方式，使普通业务用户能够更简单、更高效地与底层数据交互查询，获取所需结果。中期目标是将其变成面向技术人员的数据处理工具，通过对话交互的方式加快数据梳理流程。至于长期目标，则是通过实现 BI 系统的完整构建。

实际上，在当前阶段短期目标是最容易实现的，因为我们在之前已经有了很好的数据技术基础。对于许多企业而言，最差的情况仍然是已经拥有自己的 OLAP 或大数据平台，并且有一部分已经构建了指标体系。此外，刚才提到的技术本身也已经非常成熟，比如已经出现多年，并且早期已经有大量的项目实施。

结合大语言模型后，它本身输出结果的质量也会更上一层楼。它可以有效地支持项目开发周期，快速看到成效，特别是适用于这种项目的快速优化和迭代。实际上这种能力相对基础，本身不仅可以集成嵌入以前的工具，还有许多其他的应用。例如，它甚至可以作为一个完全独立的应用，比如市面上许多厂商推出的面向普通业务用户的个人数字助理。只要与企业内部的标准数据模型和指标，用户就可以随时随地以各种方式交互数据。

2.3 中期目标

而中期目标的实现主要是通过自然语言进行自助式的数据探索。这种能力可以集成到任何 BI 中，并将其应用于第三方系统。例如，我们期望将该直接引入传统的数据处理过程中，利用类似现有界面或传统编辑方式进行多轮对话，基于之前的查询结果进行一些子查询，同时对查询结果本身进行一些学习建模，从而创造更丰富的数据处理能力并降低数据处理难度。

2.4 长期目标

而最后的长期目标当前处于行业探索阶段，需要等待技术进步和突破。

03、大模型 + BI 实践案例

3.1 保险行业案例

第一个案例客户是一家国内规模较大的保险公司。当时该公司为高层领导制作了大量的手动移动端报表，大约有 150 张左右，但对方表示报表数量太多，在手机上很难找到对应报表。

因此客户当时的需求是：

1. 能否通过语音的方式，直接进入现有的报表中并且可以通过语音指令方式去切换报表里面参数，这也是他们最核心的需求。
2. 即便已经做了一两百张，但仍有很多需求没有得到满足。在以往的模式下，需要将数据发送给 IT 同事开发相应的报告。但是，针对需要的数据，能否随时随地自动生成报告呢？

针对这两个需求，我们可以对上海分公司的新业务单价值总和、订单价值排名前五的子公司表格进行对比，以及比较上海分公司和北京分公司近五年的新业务单价值情况。就像刚才简单的三轮查询一样，其中可能已经有现成的报表了。如果我们按照当时的匹配原则，优先匹配已有的报表，如果这些查询不能命中现有的报表，我们就去尝试创建新的报表。

项目推进过程中我们发现，所涉及的保险行业具有许多专有术语，如前述'新单'一词，这些术语的底层定义可能并不具有特定的维度，那么如何应对这个问题呢？我们需要在旧的模型训练界面上进行人工微调，将这些术语全部定义好，甚至在出现同义词时，也需要处理这些同义词。随着大语言模型的引入，我们现在可以针对保险业这个领域训练出大模型，然后进行微调，从而在较短时间内交付此类项目，并对项目进行优化，从而使效果更佳。

3.2 证券行业案例

第二个案例客户是国内比较大的证券公司。在大模型受到广泛关注后，年初时有非常多的金融机构都开始尝试要引入相关技术。我们发现，这类金融机构最大的特点是数据质量相对较高，其所需的模型和指标早已建成并具备完整性，只要把我们的产品与现有模型结合对接，让这种能力直接集成到企业内部的 App 中，最终这个项目也是在短时间内迅速上线。客户员工日常的工作主要通过语音对话方式查询获取数据，摆脱了传统的报表或敏捷 BI 的查询方式。通过拓展方式生成图表，最大的改变是让交互方式变得更加简单、查询更加高效。

04、实施挑战与未来展望

尽管大模型与 BI 的结合展现出巨大的潜力，但在实际落地过程中仍面临诸多挑战。

4.1 数据安全与隐私

企业数据往往涉及核心商业机密，直接调用公有云大模型存在数据泄露风险。解决方案包括采用私有化部署的大模型，或在数据传输前进行脱敏处理，确保敏感信息不离开企业内网环境。

4.2 幻觉问题与准确性

大模型可能会产生'幻觉'，即生成看似合理但事实错误的内容。在数据分析场景中，这可能导致错误的决策建议。需要通过 RAG（检索增强生成）技术，强制模型基于企业知识库和真实数据回答，并引入验证机制，对关键指标进行二次校验。

4.3 性能与延迟

实时查询要求低延迟，而大模型推理可能带来额外耗时。优化策略包括缓存常用查询结果、使用轻量级模型处理简单任务、复杂任务才调用大模型，以及优化网络架构。

4.4 未来展望

随着多模态技术的发展，未来的 BI 系统将不仅限于文本和图表，还能支持图像、视频等多源数据的自然语言分析。此外，Agent（智能体）技术的成熟将使大模型不仅能回答问题，还能自主执行数据清洗、报表生成甚至业务流程自动化操作，真正实现从'人找数据'到'数据找人'的转变。

综上所述，大模型正在重塑 BI 行业的格局，为企业提供更智能、更高效的数据洞察能力。企业在拥抱这一技术变革时，应注重基础数据治理，选择合适的落地路径，并持续关注技术演进带来的新机遇。