01
企业数据民主化
今年越来越多的企业尝试构建 Chat BI、Data Agent 工具释放来数据价值，但多数企业内部的数据团队状况不容乐观，根据调研，企业内部拥有大量业务团队，包括 BA、DA 分析师，承载为不同业务团队的供数功能。企业内部的客服、运营、供应链等组成部分，都有不同的看数需求。但目前很多数据开发工作都由体量较小的数据团队承接，这是很多企业目前面临的困境。
数势科技希望把集中式、分散式的数据分析现状，拓展成民主化流程，让更多的内部企业公民完成自主数据分析，如何通过指标语义+大模型能力来更好地帮助用户去取数用数，是我们的愿景。
目前多数企业内真正具备数据素养，能够进行数据分析的人可能只占全体的 15%，如何把 15% 扩展到95%，其中 80% 的提升需要通过指标语义层 Semantic layer 与大模型的结合能够解决，这也是本次分享的重点。
02
指标平台与AI Agent能力融合突破难题
实现 AI 理解每个用户的自然语言请求，并转化为相应数据及结论，其中重要的中间层叫指标语义层。我们发现，目前很多企业拥有各种数据源、数据仓库、数据湖，直接对到数据应用终端，比如 BI 工具、内部大屏看板，但没有尝试构建统一语义层。当大模型在数据库里，指标本身没有在语义层面统一时，大模型很难理解语义口径，这样无法解决幻觉、准确性不高的问题。要让 AI 更好地释放数据价值，首先要在中间语义层构建统一，只有这样大模型才能够理解用户所表述的自然语言具体所指的指标与维度。通过 AI 释放数据价值的前提条件，需达成企业内部的业务语言、指标语义统一，这也我们强调指标语义层构建的前提。
上图是客户的实际情况，没有构建指标语义层之前，数据链路是经典的数仓分层，从 ODS 到 ADS 层。其中存在一个问题，数仓分层完成后的最终数据消费，不管是 BI 工具还是大屏，都是直接从 ADS 抽表，推表后进行可视化渲染，但当数据集本身在数据团队无法管控的情况下，会出现指标口径不统一问题。指标口径本身不统一时，指标是混淆的，大模型很难准确理解所需的具体口径。
在这样的架构痛点之下，数势科技提出了新的范式，把数据集以数仓的分层推给应用端之前，先在语义层做统一，也就是说公司内部所有的标准原子指标是清晰统一的，在此基础上大模型才能够理解用户提出的指标维度含义。所以建议数仓还保留原来的分层结构，但仓外构建逻辑语义层，将所有指标要素从原子层到指标维度再到分析颗粒度，让大模型理解了用户提问意图。比如，“近 7 天的销售额哪个城市增长的最快？”这时大模型要把问句中的销售额映射到原子指标，城市指维度，也就是把用户的自然语言翻译为企业的指标与维度，这样才能够更好地支持业务团队自然语言的产品请求，目前很多零售、制造行业，包括金融机构，都在尝试迁移此架构。
当构建好指标语义层后，如何与大模型进行交互？我们并不希望大模型直接生成SQL，因为模型本身有幻觉，生成 SQL 时会有准确率问题，并且数学推算能力并不强。我们希望大模型第一步完成意图识别，比如问题的性质，到底是取数任务？还是趋势分析任务？还是归因任务？先进行意图判断，再把用户的请求拆解成对应指标维度，包括时间颗粒度，最终由指标引擎做执行，转化 SQL 逻辑，进行取数分析，本质上会有类似于大小模型协同的机制。
我们并不期待大模型本身直接做 SQL 生成，但当你把问题交给大模型后，大模型能够解析其指标、维度、时间颗粒度的过滤条件。至于具体指标维度的标准映射关系，在后台有指标管理模块进行维护，通过大小模型协同的机制，能够更加准确且高效地给业务团队提供准确数据，同时也可以对数据安全性做更好的校验。这是我们建议的 Data Agent 的实施架构。我们常看到 NL2SQL 的技术路线，与数势科技这种先构建语义层再让大模型做任务解析与意图识别的产品架构，使用差距是较明显的。比如某零售行业提问，“最近七天北京地区的某门店销售额情况如何？”单指标查询对于 NL2SQL 与 NL to 语义层没有任何难度。一旦把问句难度提升后，很难直接让大模型以快思考模式进行解析。实际业务团队在提问时，往往既要做明细数据查询，又要排序，还要归因分析与报告解读，这是相对复杂的任务。我们希望通过 Agent 架构，让大模型先把任务解析为对应的原子能力，拆解出子任务，比如第一步查数，第二步排序，第三步分析，这是 Agent 的拆解流程。再通过 function code 形式拿到对应数据，或做高阶计算，这样才能够帮助业务团队准确回答复杂问题。
03
落地实践分享
案例一：某消费零售建立经营决策体系
这是一家零售消费企业，并在全国有上千家门店，门店内设有督导经理角色，负责日常对管理的加盟商做大量报表分析，原来所有指标只能依靠总部的专业数据分析师进行提数，会存在需求等待情况，针对督导人员取数慢，我们提供了大模型分析助手产品。
该企业架构并非替代了原有 BI ， BI 更多解决如何让领导层面以固化的形式看数，还是有一定价值，但针对于门店的经理、督导，需求比较零散或临时，把需求全提给数据开发人员非常浪费时间。
1、在指标语义层把所有财务指标、门店运营指标做标准化管理。企业内部的几百个指标里，每个指标的标准定义与维度都已标准化。只需让大模型理解中间一层，再提供给业务人员分析助手，能够自由问数、取数，这是整体架构。2、为了让大模型更好理解用户的需求表达，在为企业部署产品之前，把门店域的完整指标体系做梳理。这对于大模型而言是指标知识库概念，直接问大模型公司营业单数是多少，它不能理解，因为每个企业对于指标的定义都不一样。所以这套指标体系相当于给大模型外挂了企业自己的知识库，知识库是连接数据语言跟业务语言的关键点，作为门店经理或督导，需要让大模型理解其请求，能够对应到企业内部指标体系。
门店经理的需求之前都会给到研发，但当我们把所有的这指标交给大模型后，首先可以通过自然语言问询，快速了解经理所负责门店的经营情况，同时通过自然语言的交互把关心维度进行快速分析，包括可视化能力，以及当核心门店指标出现下降时，提供大小模型结合能力，帮助门店经理找到具体情况与原因，包括归因算法技能，让大模型调用 API ，提出下一步建议，盘活企业整体数据资产。原来这些指标都只能让专业的数据分析师在数仓里面写 ETL ，这就限制了真正能够用数的人员不超过 30 人，而这些人通常不包括门店经理或业务人员。经过此次合作，数势科技为该企业的门店经理提供了自由取数用数的能力，当他一个人负责全国上千家门店时，能够移动端产品，利用自然语言问询，快速获取门店所需的数据或指标，极大提升了数据使用效率和价值。金融机构本身较特殊，对整个数据指标体系的要求、安全性、复杂度都更高。其实施的整体架构，基本上是私有化部署模式，对接架构数仓。在此之上构建了指标的语义层，这一层包含对于整个银行所有业务线，比如信贷、代发财富管理、对公对私等所有指标的含义，包括指标之间的关系，都在中间层做了维护，包括内部渠道、产品、客户经理等多实体标签。
有了中间语义层后，产品对接国产化大模型，在前端赋能使用场景。对于银行，特别重要的场景是分支行领导的问数场景，银行内部会定期让领导做日常复盘，原来领导都是提需求给助理或秘书，由秘书找业务团队、数据开发人员，一层层传递需求，时间成本较大，效率也低。
因此，客户希望直接让分支行领导对公司内部的核心财务指标、业绩指标，包括风控指标直接做问询，通过场景化落地，帮助领导在移动端实现了基于语音形式，快速获取行内核心信贷资产的波动，比如分期金额、资产余额、逾期率等等，能够通过语音交互形式快速做数据呈现，包括指标的可视化及归因分析。同时在整个机制上加入反问，让大模型做反思，帮助领导构建更好地掌握业务现状。在此基础上还有一个很重要的模块——归因洞察。对于企业经营而言，有了数据指标是远远不够的，更重要的时指标变动背后的原因，因此产品也可自动化结合行内分析报告模板产出归因、总结报告，比如看某几个分支行、某几个客户经理的指标是否有问题，同时拿到数据后，可以选择生成报告，查看问题原因，这样领导能够更加快速洞察到指标的异常情况，为后续的策略调整提供数字化支撑。
04
总结与展望
在与客户实施交流过程中，我们发现让用户问问题，本身就是很难的事情。人类自然语音交流时，不可避免会出现黑话或名词短语，导致理解有误。
所以当使用者问的问题不清晰或者模糊时，我们会让大模型做反思，通过反问机制逐渐澄清需求，这是我们产品上的核心优化机制。具体来说，我们通过大模型思考、确认所问的指标是否清楚，问句中的时间段是否模糊等，整个过程用户可干预，大模型会做澄清，明确提问的口径，这样能够提升用户最终使用工具时的产品体验。我们并不期待所有人的问题都很专业和标准，真正的大模型数据产品需要支持用户像人类交流一样，可以问得模糊、可以追问反问。
另外，不同的人对于同一个词或同一句话的理解不一样，企业内部也有不同的获取数据角色。比如我们发现，企业内不同团队的需求通过日志分析发现非常像，但实际上同一名词对于不同角色完全不一样，如果全都同样处理和分析，数据分析准确性根本无法保证。因此，我们便通过构建企业知识库让大模型明白提问者是谁，问题内名词的具体含义是什么，让分析更准确。
最后，我们还发现，对于实际的业务团队而言，数据很重要，但在某些特定维度下如何思考、如何生成数据洞察更重要，真正做到基于用户的“增强分析”。因此，数势科技在后台建立了角色知识库模板，首先让它了解用户的角色与岗位，以及这个岗位提出的名词，分析场景的推荐是什么，这样就能做到基于用户角色的定向指标推荐，提升用户产品体验，比如当用户运营团队询问门店情况时，会推荐首单用户数与复购人数，财务团队问具体表现时，推荐收入、利润。
一些高阶工具的痛点就是用户不知道该如何提问，让用户更好的提问，也是大模型时代重要的特色，如何把企业内部的分析思路给大模型，让大模型帮助提出合适的问题，这一点在基于 LUI 交互的产品体验中尤为重要。因此，我们把企业内部的行业分析指标方法论同步给大模型，此时该工具不是单纯的ChatBot，而是真正做到“增强分析”。
最后，数势科技在服务众多商业客户后也形成了对于智能分析 Agent 未来发展的思考与展望。
第一，我们希望大模型未来不仅能够 Listen，还能够 Speak。现在大部分 AI 产品只能满足基于需求的回答输出，这种体验对于知道如何提问的用户效果很好，但无法让所有人都成为专业分析师，这时候我们认为帮助用户自动生成领域内的数据分析问题非常重要。数据分析助手不应该是鹦鹉，它是助手角色，能够主动提问，从听懂人说话升级到帮人说话。第二，具备专家级的规划能力。我们期待大模型能够由本科生的规划能力升级为博士生，甚至达成研究生在某一个垂直领域的规划能力。第三，能够像人一样在数据分析后进行决策。现在大部分的工具只能挖掘出数据里的结论，下一步应该跟企业侧的业务系统进行打通。当发现业绩不好时，能否让大模型调取 API，自动做场活动来提升业绩？这样不仅能给到用户数据结论，更大的价值是给到业务决策，能够满足用户从数据分析到驱动决策的能力。以上是本次分享的全部内容，如需获取专家完整版视频实录和课件可扫码领取。
粤ICP备14082021号
免费POC，
零成本试错
