平安人寿ChatBI：大模型智能化报表的深度实践

导读 本文将分享平安人寿自研的大模型智能化报表——ChatBI 产品的实践与思考。

主要会从以下几个方面展开：

1. 项目背景和目标

2. 解决方案

3. 产品效果

4. 落地挑战

5. 总结和展望

6. 问答环节

分享嘉宾｜刘行行 中国平安人寿保险股份有限公司 财企及产品数据服务组分组经理

编辑整理｜杨生

内容校对｜李瑶

出品社区｜DataFun

---

01

项目背景和目标

1. 项目背景：大模型赋能智能 BI

我们先来看一份报告，2023 年，国家发布了《数字中国发展报告》，报告显示我国的数字经济规模已经达到了 50 多亿，位居世界第二。这一成就的取得，离不开像 ChatBI 这样的创新性产品的贡献。

我们做 ChatBI 这款产品的原因主要有三个：

• 第一，传统的 BI 产品在数据指标、预测能力方面遇到了技术瓶颈，用户体验也不够友好；

• 第二，随着 GPT 的发展，GPT 技术在文本和图像生成上取得了突破性进展，为 ChatBI 在企业中的落地提供了坚实的基础；

• 第三，许多企业对数字化和 BI 的发展也越来越重视。

因此，平安人寿也在积极推进 ChatBI 产品的应用，我们主要在解放手、解放脑、开药方这三个方面做一些积极的改变。

我们认为 ChatBI 能够在大模型领域落地，主要有四个方面的原因：

• 一是语言能力，大模型已经能够理解自然语言的语法结构和词的含义；

• 二是学习能力，我们可以通过 RAG 技术让大模型快速学习特定领域的知识；

• 三是工具调用，我们可以通过 Agent 编排，可以快速调用现有工具，并生成代码；

• 四是逻辑推理，我们可以通过大模型结合人工对数据进行洞察分析，检查出异常点和问题。

比如我们在实践应用中的一个案例场景，当用户询问业绩情况时，大模型能够根据后台计算提供数据结果。用户进一步询问原因时，大模型则可以基于逻辑推理得出具体原因。

2. 项目目标：智能 BI 3.0

随着平安人寿进入 BI 3.0 时代，我们进行了用户调研，发现用户对 BI 3.0 有三大需求：智能化、自动化和实时化。

• 智能化意味着需要大模型为用户提供智能的分析建议；

• 自动化则是自动生成可视化报表；

• 实时化要求秒级返回底层数据库的所有数据。

我们的目标是让管理者，基层员工，甚至 ToC 的客户，都能享受到全面的数字化服务。

为什么平安人寿能够快速落地 ChatBI 产品呢，我们主要是基于以下几点基础：

• 第一，我们拥有完善的数据中台，包含丰富的数据域；

• 第二，我们进行了长期的数据治理，拥有上万个规范的数据指标供用户使用；

• 第三，我们拥有丰富的可视化组件可以复用；

• 第四，我们的服务平台也已经实现了数据服务的 API 化；

• 最后，我们内部已经具备私有部署大模型和模型调优的能力。

基于这些优势，我们才能快速地成功搭建并落地了 ChatBI 产品。

3. 项目愿景：人人都是数据分析师

我们的愿景是为用户带来如下三个方面的体验：

• 第一，通过零学习成本，降低报表的使用门槛，让数据的使用变得极其简单；

• 第二，提供智能的分析建议，使数据分析变得智慧化；

• 第三，通过嵌入方式将 ChatBI 产品整合到多个内部平台中，实现快速查询数据，提升用户体验，让每个人都能成为数据分析师。

02

解决方案

1. 总体架构方案

我们的整体解决方案大致分为四层。

• 最底层是数据中台，包含各种数据域和指标。

• 往上一层是平台层，集成了 API 服务、知识管理、大模型以及 Cube 和 GS 平台，以及北斗可视化平台。这些平台主要覆盖从用户提问到代码生成，再到可视化等功能点。

• 在 Agent 这一层，我们分为四类：问数、分析、数据解读以及公共能力 Agent。

• 最后是应用层，我们实现了三个核心功能：What（解放手）、Why（解放脑）和How（开药方）。

  What 指的是用户可以通过对话方式查询数据，实现零代码和实时数据获取，并通过图表进行可视化生成，数据获取速度从以前的天级提升到现在的秒级。

  Why 主要指通过大模型实现根因分析、数据洞察、维度分析等，替代人工进行数据分析，将数据分析流程从原来的"提需求→分析需求→获取数据→进行数据分析→制作分析报告"变成现在的一步到位，通过自然语言提问即可直接生成分析报告。

  How 则是开药方，通过大模型的洞察能力和分析能力，提供数据建议和措施，让洞察分析从依赖人工经验变成自动化智能生成。

2. 业务架构

我们的产品是直接面向用户的，因此我们首先梳理了用户的需求，并将其大致分为三类：产品功能、问法和指标。

• 在产品功能方面，业务用户不仅需要查询数据，还需要了解指标口径、元数据等信息，并希望有指标推荐、代码生成、可视化以及通过多轮对话提升体验等。

• 在问法方面，除了简单问题，还支持复杂问题的查询，如同比、环比、累计和排序等。

• 在指标方面，我们提供全域数据指标，并能支持日频、月频和年频指标的查询能力，最关键的是指标权限管理，确保每个用户根据账号确定其指标使用范围，保障数据安全。

我们的业务流程从用户提问开始，首先通过 BI 大模型的语义理解，多轮对话和意图识别准确摘取用户提问中的关键信息，如指标、时间和维度。然后，通过 API 和 Doris 快速从数据库中找到所需数据。接下来是对查询后的数据进行可视化组装，我们支持提供各种可视化模板进行图表组装。最后是在客户端呈现数据报告。

3. 技术架构

在技术架构方面，底层包括公共服务、BI 大模型、数据中台和知识库，这些都是我们的基础服务。

在基础服务之上有五大部分：

• 第一是前端用户，我们可以通过插件的形式插入到不同的平台，支持用户访问、提问、鉴权和网关控制。

• 第二是多轮对话，多轮对话部分通过上下文理解能力捕获业务客户的意图，为下一步的任务编排做准备。

• 第三是 Agent 编排，其中任务执行是整个系统的大脑，通过任务编排调用不同的工具和知识库。

• 第四是 AI+BI 工具箱，这是我们开发过程中面临的最大挑战，需要针对不同场景开发不同的小模型，比如预测预警、时间序列预测和指标分析等，通过定制化的模型来适应不同的场景。

• 最后是可视化系统，我们通过可视化平台和一些可视化布局的插件快速生成可视化图表。

我们整个问数的流程，包括意图识别、知识提取、文本生成、数据生成等步骤，整个过程中会多次与大模型进行交互。

另外知识库是我们的开发过程中最重要的工作之一，我们采用了两种技术：RAG 技术和外挂知识库。

• RAG 技术用于提高准确率，大模型在进行语义解析后会调用知识库进行检索，然后用这些知识进行文本和数据的语义分析和生成，从而大幅提高准确率。

• 知识库分为常见知识库和进阶知识库，常见知识库包含常见名词、知识和 SQL 语法等，而进阶知识库则是垂直领域内的知识，如 BI 知识库的同环比、累计等术语，保险知识库的各种保险行业名词，以及 SQL 知识库的 SQL 编写规范。

知识库的维护需要投入大量的精力，但是知识库的丰富度与语义解析和结果生成的准确性息息相关，是非常必要的工作。

03

产品效果

案例 1：对话式问数

我们已经上线了随机报表功能，主要功能是问数，支持用户随机提问，系统快速解答，同时支持同比、环比和排序等复杂查询。

用户可以随机提问，例如查询某个机构的业绩。系统通过大模型、意图识别和知识库对意图进行识别，解析出时间、指标、计算方法和维度，然后通过知识库进行二次校准，进入任务编排阶段。接下来是 UM 鉴权，根据用户账号确定用户是否有权限使用该指标。之后是 SQL 生成，调用数据库进行秒级查询。最后是对结果进行可视化包装和美化。

案例 2：言出必答

我们还实现了一些其他功能点，比如“言出必答”，用户可以查询指标的元数据和口径，系统能快速展示数据库底层的数据治理知识。

案例 3：SQL 生成与问题推荐

此外，随机报表功能提供了兜底话术，当用户提问不完整时，系统可以补齐默认信息，如补齐时间。还能帮助有代码能力的人员直接使用我们系统生成的代码。

04

落地挑战

我们在开发过程中也遇到了很多挑战。

• 第一是大模型的幻觉问题，即同一个问题可能会出现不同的回答，我们的解决方案是通过知识库和数据中台进行兜底策略。

• 第二是根因分析，这是我们认为最难的问题，当分析指标变动的深层原因时，需要在后台有大量的指标图谱和知识库支撑，需要花费大量的精力建设小模型，这也是我们未来重点的方向。

• 第三，用户权限管理也是一个重要但容易被忽略的点，我们需要长期的数据治理和盘点，以确保每个用户只能使用其授权的指标，避免出现数据安全问题。

05

总结与展望

整体而言，我们认为这个项目的价值在于以下六个方面：

• 首先，我们的产品不仅限于管理层使用，而是可以覆盖到所有员工和客户。

• 其次，我们可以实现 7×24 小时的在线应用。

• 第三，我们可以无缝衔接到不同的客户端。

• 第四，我们提供的是标准一致的全域数据。

• 第五，我们能提供智能化的分析，降低分析门槛。

• 最后，我们能提供数据洞察的结论或建议，使数据洞察成为一个完整的分析过程。

感谢各位同仁的聆听。我们平安人寿的大模型智能化报表——ChatBI 产品的介绍和讨论到此结束。期待与各位进一步交流和合作，共同推动数字化转型的进程。

06

问答环节

Q1：平安人寿的 Chat BI 生成是使用专用的大模型，还是通过微调通用大模型来实现的？另外，在 Python 和 SQL 两个选择之间，您的规划和侧重点是什么？

A1：我们目前使用的大模型是私有部署的 Qwen 72b 模型，并进行了微调和多项工程优化。由于金融企业的特殊规范，我们更倾向于私有化部署。对于 SQL 生成和 Python 功能，我们根据不同场景进行规划。例如，我们上线的随机报表功能主要生成 SQL 语句，大模型主要负责语义理解，之后通过 API 方式和 NLP 技术生成代码，我们底层的数据服务中台可以快速生成数据查询。之前尝试过让大模型生成 SQL，但发现实现路径和精准度提升较慢，难度较高，因此我们采用了现有的指标平台。Python 功能我们规划用于数据分析。

Q2：关于数据权限的管理，您是如何控制行列权限的？

A2：我们的数据权限管理已经从早期的行级别权限服务，进化到可以进行列级别的权限管理，我们认为列级别的权限管理更为细致和安全。为此，我们在数据指标上投入了两三年的时间进行数据治理和数据库中台的搭建。目前，我们底层有一个权限服务，每次用户调用时，都会进行鉴权检查，确保用户和指标的权限范围和关系已经预设好。

Q3：关于用户提问的问题，不同的用户可能对同一个问题有不同的描述，大模型可能会给出不同的判断。您提到的兜底方案，能否详细说明一下？

A3：关于大模型的幻觉问题，我们确实遇到过，这个问题需要花费大量时间去分析 bad case，我们认为没有什么捷径可走，需要不断收集 bad case，并在意图识别中加入各种知识。同时，我们的模型也需要不断细化，针对不同场景和用户提问进行服务细分。我们已经分析了十几轮，上千个 bad case，并不断进行分析。我们在产品端设置了点赞功能，对于点赞的问题，我们会进行重点关注，产品运营人员会对每个案例进行分析。我们认为，通过知识库和数据中台的维护和优化，可以解决这个问题，而不是通过调整一两个参数就能解决的。

Q4：关于根因分析，如果我们要做好它，需要给大模型输入哪些东西？

A4：要做好根因分析，我们需要输入指标之间的勾稽关系和相关性，这些知识需要形成知识图谱输入给大模型。我们通过业内调研了解到，方向都是要梳理好自己的指标图谱，因为一个指标可能受多个指标的影响，包括显性和隐性的影响。这需要在底层做好数据模型去支持计算他们的相关性，包括时间滞后性等问题。大方向就是要有指标图谱，我们已经开始着手这个工作了。

Q5：关于知识图谱，除了指标图谱之外，是否还涉及到其他的图谱？

A5：我们的知识图谱主要涉及指标图谱，包括指标之间的血缘关系等，我们的数据中台已经包含了这些关系。至于是否涉及到企业或其他实体或关系，我们的图谱主要是指标方面的，因为我们的产品是对内的。技术方案方面，我们把图谱直接放在数据库里面，作为一个服务，通过接口进行调用。我们有能力穷举它们之间的关系，并通过算法计算出指标和指标之间的隐性关系，因此我们也具备相关的图算法能力。

以上就是本次分享的内容，谢谢大家。