亚马逊云科技助力光伏企业生成式 BI 落地的实践探索

背景和目标

自今年 5 月份起，我们为一家国内光伏行业的领军企业，利用生成式人工智能技术，开发了一套创新的生成式商业智能（BI）工具。这一工具极大地提升了数据使用的效率。

在此前，企业内各个业务部门的业务分析师和运营人员经常面临大量的即席查询和分析需求。这些需求通常是零散的、突发的，且没有固定的模式，需要进行探索。由于这些特点，传统的 BI 工具，尽管能够构建看板和查询工具，却难以满足业务部门的多样化需求。因此，业务人员不得不将这些需求提交给数据中心的数据分析师处理。然而，这种方式不仅影响了需求响应的时效性，而且在探索性诉求的沟通过程中，双方需要反复交流以理解业务术语和场景，这对业务分析师和数据分析师都是一种极大的挑战。

关键问题

大模型能够及时且耐心地通过对话方式回应用户在数据探索方面的需求，因此，基于生成式 AI 技术的智能机器人成为了我们的首选方案。然而，仅仅将数据库表的 schema 作为提示词提供给大模型，实际效果并不理想：

当涉及超过五张表的复杂查询时，大模型生成的 SQL 语句的准确性会急剧下降；
大模型在理解专业术语方面存在困难，尤其是对于那些名称相近但含义不同的术语。例如，“澳洲站”和“澳洲地区”分别代表业务区域和设备安装地点；
对于同一个指标，不同的业务人员可能会使用多种类似但并不完全相同的术语来称呼。例如，设备的 SN 码，有的业务人员会直接称呼为序列号；
查询条件和数据库存储的值往往不是直接相同。例如询问，上海地区的销量，生成的 SQL 往往会出现
```
where city = "上海地区"
```
而 city 字段存放的值是类似 shanghai, beijing 一类的英文；
企业的海外业务为了满足当地国家的合规性诉求，数据往往都存放在不同的区域。例如我们的客户面向的用户分布在欧洲、澳洲、美国、日本、东南亚等。要对这些跨区域的数据进行汇总性质的分析，这样的运营诉求也很常见。例如，要分析某个固件版本当前总装机容量，这就要从多个区域的数据源分析并汇总。

这些挑战表明，大模型在生成式 BI 的实际落地中仍需要进一步的优化和调整，以提高其准确性和用户友好性。

解决方案架构

为了解决上述问题，我们优先建议企业对数据先进行数据治理，保证数据场景之间能高内聚。并且在数据应用层按业务场景划分主题，每个主题不超过五张表，保证大模型生成的 SQL 不会出现准确率急速下降的问题。

在数据清洗和建模的过程中，我们建议客户使用具有物化视图的特性的数仓来实现，例如 Amazon Redshift 、 Apache StarRocks。

整体业务流程和技术方案如下：

用户发起请求后，调用大模型进行意图识别，选择场景或者主题
根据主题对问题进行提示词包装后，对问题进行 embedding
从向量数据库查找问题的上下文
根据返回的上下文对用户问题进一步进行提示词工程
调用大模型，返回问题的具体 SQL
向不同的数据源发送 SQL，查询数据
对返回的数据切片，使用 pandas dataframe 进行聚合
返回最终数据给用户

实现过程

建模方法

物化视图（Materialized View）是一种特殊的视图，它不是在查询时动态生成结果，而是根据定义预先计算并存储结果集的视图。当底层数据表发生变更（插入、更新或删除操作）时，数仓引擎会根据需要更新物化视图中的数据，以保持数据的一致性，这个过程往往是自动完成的（也可以手动），同时这个过程是采用增量刷新机制，只对变更的部分进行重新计算，而不是每次都刷新整个视图，这提高了效率。物化视图具有读写分离，加速查询，优化索引，自动后台动态刷新等特性，在数据建模过程中，十分方便有效。

物化视图的工作方式

如何建模

在进行数据建模时，我们推荐采用维度建模理论。在每个场景中，首先应选择一个主题。数据应用层中主题的选择应基于最终用户查询数据的模式。在大多数情况下，应选择事件事实表的业务含义作为该场景的主题。我们需要围绕这一主题，来确定需要的维度。

在选择了依赖的维度之后，需要考虑是将维度信息冗余在事实表中，还是建立维度表并通过外键进行关联。通过外键关联的好处是数据逻辑更加清晰，但这可能导致 SQL 的 join 操作变得更加复杂。根据维度建模的方法论以及我们的实践经验，我们建议在一级维度中将信息冗余于事实表，而二级维度则建立维度表并通过外键进行关联。

如图二所示，我们对本应通过设备 ID 进行关联的设备维度信息进行了筛选，仅将业务中经常使用的几个核心维度信息直接冗余到测点事件表中。此外，通过冗余二级维度信息（例如固件维度表中的固件 ID），我们确保了即使对于二级维度，也能通过一次关联快速完成查询。

建模方式参考

跨源数据的聚合

我们统计了历史上业务对数据的诉求，发现跨数据源的数据查询基本都可加的，大部分场景都不存在跨数据源查询后的数据需要去重的场景。所以，我们通过在服务端通过 pandas dataframe 对分片的数据进行二次聚合实现整体计算结果的汇总，合并过程类似图三。对于少量无法直接对分片数据进行聚合的场景，我们依旧采用定制看板的形式提供支持。

使用 Pandas Dataframe 合并数据

优化提示词

为了让大模型更深入地理解业务术语，需要根据大模型的最佳实践提示词来描述数据表。在我们的实践过程中，我们使用了大语言模型，并参考了提示词的最佳实践进行提示词工程，取得了非常好的效果。

在开发阶段，数据表及其字段的描述会频繁变动以确保更高的效率。我们根据实践经验，构建了一种格式的 Excel 表格供客户更新表信息，以方便客户进行频繁的更新。一旦 Excel 表格更新完毕，使用脚本将提示词导入向量数据库后，就可以立即体验到优化的效果。

在实践过程中，我们发现明确地告诉大模型字段类型、字段属于维度还是度量、关联键信息、维度枚举值的业务含义以及枚举值是否可穷举，这些信息能够显著提高大模型生成 SQL 语句的准确度。

通过优化提示词，大语言模型能够深刻理解数据库中的维度枚举值的含义，并使用数据库中的真实值来代替问题中的条件，而不是简单地进行替换。

以一份电商数据为例，我们可以看到这种优化带来的效果。

我们按照模板，以如下方式描述订单信息：

我们明确告知了 SKU 的取值范围，并指导大模型尝试理解枚举值的具体含义。以问题”男装在上海地区的销售金额”为例，大模型不仅用’shanghai’替换了问题中的”上海地区”，而且使用了 SQL 中的 IN 语法来定位”男装”这一条件，避免了简单地使用 g.sku=”男装”进行替换。此外，根据我们的提示词，大模型还理解到销售金额这一指标应该只统计真正完成的订单，而不是包括未付款、运输中或已取消等状态的订单。

下图是一个查询示例。在系统中输入示例问题“男装在上海地区的销售金额是多少？”系统返回生成的 SQL 及其在数据库中查询到的结果。

大模型返回的完整 SQL 如下：

SELECT SUM(od.amount) AS total_sales 
FROM business.order_detail od 
JOIN business.user u ON od.user_mail = u.user_mail 
JOIN business.goods g ON od.goods_id = g.goods_id 
WHERE u.city = 'shanghai' 
AND g.sku IN ('boy shirt', 'boy shoes', 'boy pants', 'boy coat') 
AND od.status = 'finished' LIMIT 50

当用户的提出问题后，我们将使用如下过程，先对客户问题进行场景分类，然后再把问题路由到对应场景的提示词。

当用户提出问题后，我们会先尝试让大模型，根据我们提供的提示词，选择问题所属的场景。
大模型选择好场景后，我们会把这个场景包含的，经过提示词优化后的元数据信息以及用户问题，提交给大模型，让大模型回答问题。
我们会引导大模型对自己的回答进行评判、自我纠错，把一个相对最优的结果返回给用户。

整个过程在我们的方案中已经配置化，可以轻松在其他业务场景使用。

效果展示

上图是方案运行的效果。用户在下方的聊天框中输入问题，系统会返回问题涉及的数据，并分别以表格和图表的形式展示，也会显示相应的 SQL。左侧面板记录了用户的历史提问，便于用户随时回顾。右侧面板则配置了一系列常见问题，方便用户快速获取所需信息。

总结

本文记录了使用生成式 AI 构建生成式 BI 平台的实践探索过程。在这一过程中，我们发现良好的数据架构、优秀的提示词工程以及先进的大模型对于实现最终结果至关重要，缺一不可。

使用具备物化视图功能的数仓产品，如 Amazon Redshift 或 StarRocks，可以简化数据建模过程的实现难度。遵循大模型提示词工程的最佳实践，清晰明确地向大模型传达业务含义，并让大模型尝试理解样例数据，有助于生成高质量的 SQL 语句。此外，选择一个先进的大模型能够显著优化整个工作流程，减少工作量。该方案已经逐步在客户的多个海外业务区域上线。

亚马逊AWS官方博客