导读 本文将分享大模型时代下的指标平台建设实践。
主要分为以下几个部分：1. LLM 拉开数据普惠序幕
2. 数据普惠实现路径
3. 指标平台相关创新点
4. 案例分享
5. 未来展望
分享嘉宾｜刘豹 北京数势云创科技有限公司 标品研发负责人
编辑整理｜汪维
内容校对｜李瑶
出品社区｜DataFun
LLM 拉开数据普惠序幕
数据普惠，即让没有数据领域专业背景知识的人也能够更好地利用数据，比如一线的业务员、公司管理层等。大模型为数据普惠创造了更有利的条件。1. LLM Agent 在 ToB 行业场景落地场景
自从 OpenAI 发布 ChatGPT 之后，行业内出现了很多 Agent 应用来解决企业的各种问题，常见的有内容创作、企业级知识库、风险控制和智能客服等。其中，智能分析与决策是实现数据普惠的一个重要场景方向。2. 智能分析 LLM Agent 与数据普惠
企业中，一般管理者或者一线业务人员需要使用数据的时候，会先把需求提给数据分析师，然后数据分析师把需求提给数据产品经理，数据产品经理再将需求传达给数据工程师，数据工程师用 SQL 或者自动化的工具来实现，整个流程比较长。未来，基于大模型智能分析 Agent 可以通过对话的方式快速提供用户想要的数据，降低用户使用数据的门槛，让数据在企业的经营决策以及日常业务流中的参与度大大提高，从而实现数据的普惠。数据普惠实现路径
智能分析大模型 Agent 常见的实现方案有两种：NL2SQL 和 NL2API。
NL2SQL 指的是将自然语言直接翻译成 SQL 查询，NL2API 则是将自然语言转化成已有的数据分析类系统工具的 API，通过间接的方式获取数据。这两种方式中都会存在大模型的幻觉问题，为了防止大模型“一本正经的胡说八道”，中间需要有一个语义层，叫做 semantic layer。在语义层，企业能够对底层的数据进行语义标注，让大模型可以更好地去理解取数、用数的需求，找到正确的数据并完成精准的分析。
语义层在数据栈中是一个独立且可互操作的部分，位于数据源和数据使用者之间。统一语义使得所有数据端点，无论是 AI，还是 AI Agent，或者嵌入式分析都可以使用相同的语义和底层数据，从而得到一致且可信赖的洞察。语义层要建在哪里呢？通常有两种方案：仓内语义和仓外语义。1. 仓内语义
仓内语义就是将语义层建在数仓里，建在 ODS 层、DWD 层或者 ADS 层。
这个方案通常对应的是 NL2SQL，常见的一个实现方式是把企业数据中台中已有的表及其字段的语义（通常在数据治理平台），以及表的下游关系的语义（通常在数据质量平台）放入向量数据库，当用户进行查询的时候利用语义数据库对查询进行增强，将 prompt 发送给大模型，由大模型生成一段 SQL 直接到 OLAP 引擎里面去执行，然后反馈结果。
这种方案存在很多问题。首先，准确率比较低，只有 60%
~ 70%，即使使用 GPT 也很难达到直接可用的准确效果。另外，成本也比较高，性能也不可控，还可能存在数据安全风险，而且能力比较单一。首先这是因为涉及到了“语义究竟应该建在数仓哪一层的问题”。如果每一层都建语义，那么每一层的语义差别会非常细微，大模型去查询时可能会判断错层级，比如本来想要查 DWS 层的数据，结果查了 ODS 层的数据，准确率就会受到影响。同时，ODS 层数据量可能是 DWD 层的几百倍，可能在 DWD 层本来一秒钟就能返回结果的情况，在 ODS 层级则需要更长的时间，因此性能也不可控。大模型能解析的是标准 SQL 的语义，如果企业里面有很多自定义的算子、UDF 等，大模型无法翻译，所以在生成 SQL 的时候可能会存在缺失。与此同时，如将语义在数仓上完成定义，工作通常是由数据开发工程师来完成的，跟业务离得比较远，那么当业务用户作为终端使用者查询时，大模型依据由系统开发工程师定义的语义去做的推断，这可能造成语义与业务实际需求偏差较大。最后，关于数据安全风险，“什么样的人能用什么样的数据”在企业中需要对业务范围进行管控，然而实际上大模型无法精准理解并实现这部分管控需求。在生成 SQL 的时候，where 条件里面不知道怎么去加这样的控制，可能会导致一线业务人员看到了不该看的数据。2. 仓外语义
仓外语义，即将语义层右移，做一个仓外模型，让数据产品经理或者数据分析师去做建模，这个通常对应的是指标平台。
如上图所示，我们在 DWD 这一层进行定义规范化、定义统一的原子指标和维度，通过积木式的组装成派生指标和衍生指标，其实也就是对应了 DWS 层和 ADS 层，都基于虚拟层的逻辑定义，会更便捷，而且离业务更近，这样就形成了 NL2Sematic2API 的方案。
之前 NL2SQL 的问题在 NL2semantic2API 方案中都得到了解决：- 准确率比较高，比如数势科技的产品 SwiftAgent 准确率可以达到了 95% 以上，完全可以商业化为企业级的应用。
- 训练成本比较低，因为指标、维度的数量有限，不用每一层都拿来进行预训练。
- 性能提升且稳定，通过 API 的查询是平台本身的能力，跟直接 SQL 查询相比，相当于是做了一层加速，性能更优，数势科技 SwiftAgent 产品 P95 能够实现秒级输出。
- 数据安全可靠，什么角色有什么样的权限能看到哪些指标，在指标平台可以做到清晰严格的管控。
- 能力覆盖全，内部算子可以直接通过 API 的方式翻译出来。
数势科技的 SwiftAgent 产品便是采用了上述 NL2semantic2API 方案，具有以下 5 点优势：- 通过指标和标签构建企业统一的业务语义层，提升以自然语言取数问数的准确率；
- 多源异构数据连接，可以支持企业结构化和非结构化数据的输入；
- 整个系统可以持续反思学习，通过不断的用数历史积累，实现产品的自优化。
指标平台相关的创新点
数势科技 SwiftMetrics 指标平台的核心目标为实现统一语义层的构建，以及计算加速。
上图中展示了数势科技指标平台的整体架构，是一个典型的分层的松耦合的微服务架构。底层是数据接入层，可以接入各种常见的数据源，用的是 StarRocks/Doris 引擎；向上是数据预处理层，用来做数据的加速；再上一层是服务层，做元数据管理；最上面的网关层为接入用户角色校验提供了更安全精细的权限控制。整体来说，此指标平台有三个特点：指标管理高效便捷、指标查询快速灵活、数据安全精细可靠。
核心是基于数据虚拟化 DataFabric 数据编织的理念，构建了清晰的分层架构。最下面是数据模型层，上面是原子指标，再上面是派生指标、衍生指标、维度等，然后是所有模型或者指标的语义定义，它跟具体的物理存储没有关系，全部是元信息的存储。这也就意味着如果要做改动，不需要把数据再重新算一遍，即改即生效，非常灵活便捷。上面介绍了数据虚拟化的思路，通常来说数据虚拟化与性能是没有办法兼顾的。例如原来是查一个预聚合的数据，改动后，原来的预聚合失效了，就需要查底层的原始数据，数据量会比较大。因此为了保证好的性能，数势科技指标平台采取了以下几个措施进行优化：
引擎层选择新一代全场景的 MPP Live 引擎 StarRocks/Doris 引擎，让指标查询更快速与灵活。在选型之前，我们做了大量的对比调研：①跟 ClickHouse 对比，实际上 ClickHouse 也是一个非常快速的引擎，但是它在多表关联的场景性能表现较差，另外 ClickHouse 引擎运维比较麻烦，为分布式的思路，元数据最终一致性不能很好地保证，会出现数据不准确的问题；②跟 Impala 比，两者有代际的差异，Impala 不支持向量化执行，也没有自己的存储，需要靠外部的存储来做存储加速；③Kylin 严格意义上来说不能算是一个非常标准的OLAP 引擎，因为所有的查询都需要先预定义 cube，并且还要等 cube 计算完以后才能查出数据来，有比较大的限制。（2）旁路加速引擎 HME（Hyper Metrics Engine)
除了引擎的选型以外，数势科技还自研了加速引擎 HME，它是一个旁路的加速引擎，在定义了模型以后，可以根据指标、维度以及指标计算要素的定义做层层上卷的预计算操作，在查询的时候先看哪一层是可用并能够命中的，然后层层往下推，以此提升查询性能，最坏的情况也无非就是需要查最底层的数据，整体数据查询效率较高。
此外，数势科技指标平台的 HME 也做了一些其他设计优化的策略，如自动预打宽、自动重分区、自动预聚合、自动去重、自动缓存等，通过这些策略来实现指标定义的灵活性和性能的兼顾。
以上是一个 HME 加速的例子，是一个维度再加上一个指标 sum 计算，从底表查需要将近 30s。通过 HME 加速：首先通过预打宽省了一层关联（join in），然后主动的位置下推实现了分区裁剪，查询的时候数据量也会变少，最后命中了预聚合的一个缓存，最终查询只需要 0.3s，整个查询速度提升了大概 100 倍。
权限控制是指标平台常见的能力，基于 RBAC 的权限控制模型可以实现精确的行列级的数据权限控制。上图展示了数势科技 SwiftAgent 产品权限控制的功能。案例分享
第一个案例是 SwiftAgent 对话式数据分析产品在某头部茶饮连锁企业的实践。主要应用场景包括：管理层每天可通过对话的方式查看经营情况；巡店的人员每天可查看其负责店铺的情况；一些店长可能不会用BI，也不会复杂的操作，通过对话式的交互就可以通过微信查到自己权限范围内的数据。简单来讲，就是通过使用 SwifAgent 产品实现简化决策，放大成效的效果。
除泛零售行业外，金融机构也是数势科技重要的服务行业。在某头部城商行，数势科技提供 SwiftAgent 产品，将银行业平均取数工单每天减少约 50%，大幅降低人工成本。以前，某个领导想看某个数据的时候，只能通过单一的工单渠道发起提数需求，有了系统以后，工单减少了很多，提供数据的周期也短了很多。另外，原来数仓里面的表非常多，有了这个系统以后原表的使用率下降了，整体的利用率也有了比较大的提升。在该城商银行内部对系统的满意度非常高。未来展望
除了智能分析助手 SwiftAgent 外，数势科技还有其他一些成熟的产品，包括智能指标平台、智能标签平台和智能营销平台，产品支持先进行洞察确定目标实体，然后进行策略触达，最后进行数据回收与优化，形成飞轮效应。目前这些产品在企业使用广泛，但如果想要把整套系统都用起来，需要各种角色配合，也需要对整个系统有非常深入的理解。未来我们希望利用大模型能力帮助企业完成所有产品的重构与升级，实现下面这样的效果：如帮助一线运营人员日常工作，请先帮助找出最近三十天持仓金额大于一百万、交易次数超过十次的所有男性客户们，并对他们送上节日的祝福。目前，实现这一需求，需要好几个业务系统进行联动才能实现。未来，企业运营人员可以直接对数势科技的 SwiftAgent 说出目标，产品将清晰地理解需求，自动串联调用相关业务系统，找到准确的数据完成分析，并生成定时任务，快速实现期望的运营效果。
分享嘉宾
INTRODUCTION
刘豹
北京数势云创科技有限公司
标品研发负责人
14 年北邮硕士毕业，先后在百度、腾讯等公司从事大数据引擎、大数据平台研发架构工作，现于数势负责标品研发，具有丰富的大数据平台、OLAP 引擎优化经验。