为了适应当下数字化经营的市场环境，指标平台通过指标高效开发、以及提供灵活高性能指标服务，逐渐成为企业数据基础设施的重要组成部分。而随着大模型技术的日益迭代，在大模型加持下的指标平台与指标分析正迎来新一轮升级变革，为企业提供新的增量价值。

数势科技是行业领先的指标平台提供商，近期也发布了大模型与指标平台能力结合的产品智能分析助手SwiftAgent。上周，数势联合爱分析举办了“基于大模型，构建新一代指标分析”主题网络研讨会，AI负责人李飞博士带来数势大模型产品建设方法和成功实践案例，为企业业务运营和技术建设提升带来新思路。

以下内容根据李飞博士现场分享内容整理，如想了解更多请点击“阅读原文”。

围绕大模型的建设，按照成本和难度排序，分别为基础大模型的构建，大模型的微调，AI Agent和RAG的工程化落地，以及开发Prompt激活基础大模型的能力。对于企业而言，需要考虑的是如何权衡大模型落地策略。大部分企业难以独立构建基础大模型，微调阶段的成本同样比较高昂。

因此，在大模型落地过程中，企业应自金字塔结构顶部逐层深入，低成本且构建难度较低的Prompt Engineering、RAG、AI Agent，是结合具体场景以快速实现大模型应用效果的首选。

在企业的指标建设和经营过程中，搭建指标体系一直是一个面临挑战的痛点。目前，企业在指标体系建设中往往面临缺乏有效方法的问题。事实上，指标体系扮演着企业经营分析的基础支撑角色，是企业成功运营的基石。

然而，在实际应用中，我们依然发现存在一些不足之处。特别是在面对管理决策团队时，如何在已建好的各项指标基础上进行精细化取数分析成为一个挑战。传统的BI工具，如报表大屏，虽然能够满足一般性需求，但当管理决策团队提出个性化需求时，例如需要提取特定数字或寻找某地区销售额下降原因时，往往需要借助业务分析团队进行繁琐的工作。

业务分析团队在指标平台或传统的BI平台上进行分析工作，包括可视化处理和分析建模等任务。如果数据不完整，他们还需与数据开发团队沟通，由后者进行指标或数据仓库字段的加工。

获得数据后，业务分析团队需要依赖个人经验来解读并得出结论。因为目标不仅仅是获取数据，更是通过这些数据揭示背后的结论，为管理决策层提供实质性的管理指导和决策支持。

当然，随着高层管理团队和业务团队对数据的日益增长的需求，数据团队不得不应对日益增多的需求。许多重复性的指标需要不断开发，这无疑会导致企业计算资源的浪费，同时也会使存储空间超负荷。在字段加工报表较多时，可能存在数据口径相同但分析员和管理人员不清楚应该参考哪个字段或以哪一个为准的情况，这会成为他们面临的一个日常困扰。

因此，我们采用了基于指标+大模型的多模态交互方式。这种方式使得分析人员和管理者更容易理解大模型的设计意图和扩展功能，从而实现了更为高效的企业数据分析和决策制定。这一创新让数据真正做到了大众化、普及化，标志着企业智能决策迈向了一个新的里程碑。

近期我们从真实客户中汇总了五个多样化的数据分析问题，这些问题不仅仅是简单的取数问题，而且需要融合多方面的能力，包括归因、洞察以及高级计算分析等。通过大模型的帮助，我们能够更有效地解决这些难题。

对于第一个问题，涉及到一些取数和累加聚合的操作，可以通过NLP2SQL进行解决。在第二个问题中，涉及到了销售数量与自然表述方式的对齐，这就需要大模型超级对齐的能力，通过大模型将出售商品的数量与人的自然表达方式进行精准对齐，最终对齐至具体字段或指标含义中。

对于第三至第五个问题，特别是第四、第五个问题，涉及到的并非单一任务。在第四个问题中，需要找到某个品牌中销量最佳的产品，涉及到排序、每月销售数据的计算等多任务规划问题。而第五个问题则引入了归因分析，以解释为何昨日销售额下降。这需要通过深层次的数据分析，了解下降的原因，包括焦点在哪些维度、哪个因子等。

传统方法中，我们通常需要先获取数据，核实数据的下降情况，进行归因分析，最后以报告形式向管理层呈现结论。这涉及到多方面的技能，包括解释数据、归因分析、报告撰写等。

通过采用基于大模型的数势SwfitAgent产品，企业可实现对这些复杂问题的更高效解决。大模型不仅能够处理多样化的问题，还能够为企业提供更精准的决策支持，推动数据分析进入更为智能、高效的阶段。

在这个过程中，我们总结了一些关键困难点，其中包括语义对齐的实现、多任务复杂性的确定以及数据计算性能的需求。

处理语义对齐的挑战：首要的困难是如何处理语义对齐，以确保不同表达方式之间的精准匹配。这是一个需要深度理解语义和意图的任务，涉及到超级对齐技术，以确保数据的一致性和精准性。

多任务复杂性及任务依赖：其次，如前所提到的第四个问题，当任务繁多时，我们面临确定每项任务以及任务之间前后依赖关系的挑战。以找到最畅销产品为例，随后需要查看该产品在其他地区的销售情况，这涉及到任务之间的依赖关系。我们必须精确地确定任务的执行顺序，以有效地完成整个任务链。

大模型产品对数据性能的需求：最后，针对大模型这类交互性产品，我们必须确保无论是在查询数据还是在进行运算时，性能都必须得到保证。了解到对话式产品的用户相较于传统GUI产品用户的耐心较低，我们迫切需要在用户更快地获取答案的同时保证数据的准确性和完整性，以满足用户的需求。

在这个前沿技术领域，我们致力于克服这些挑战，使大模型产品能够更好地服务于用户，实现智能、高效的数据分析和决策制定。

基于大模型的指标分析解决方案

对于上述提到的三点正是我们基于大模型的新一代指标产品所要解决的。

首先，关于语义如何对齐的问题，我们实施了一种指标字典，它的优势在于它能以业务语言及研发语言为基础对每个指标进行定义。例如，业务语言用来定义指标的业务含义是什么，而研发语言表明指标的口径描述是什么，包括该指标提出的部门，需求相关人员，以及开发人员等方面的信息。

为什么我们要处理语义呢？我们知道，大模型对文本的理解能力比较强，在传统的NLP2SQL流程中，经过调整后的准确率可能仍未达到90%，这是由于我们会对每个数仓字段做出中文语义表述，而如NLP2SQL这类工具通常是基于英文编写的，无法完全适应数仓本身基于英文的特点。因此，在使用中文进行提问时，我们需要进行大量的微调工作，使我们的中文语言与英文的SQL语言实现对接。当然，你也可以对每个字段或表标记中文语义，这样才能达到预期效果。

在指标平台方面，实际上我们在将数仓数据录入至指标平台时会完成这一步骤，其中涉及指标平台的中文语义和技术语义的录入。通过这一环节，大模型能基于此层面的业务和技术语言及其他相关口径，更加准确地理解用户的问题所对应的确切指标，因此，数仓表中的结构化数据会更适合我们的大模型来提取数据或进行查询。

接下来在我们的平台中，为每一张表进行导入时，都会包含一个配置化功能，可理解为类似于标注平台，帮助我们的大模型更好地理解。这其中也包括指标之间的血缘关系理解，例如指标中应包括刚刚提到的指标建议，每个指标应有哪些维度，因为我们的用户在查询时可能会遇到这样的问题，即查询的指标本身并不匹配该维度，此时通过这种配置化功能，我们会告知用户已查询的指标未找到相关维度，以此给出提醒。由此可见，通过血缘关系和定义的结合，大模型能更好地进行理解。

那么在下一部分我们主要做了什么呢？包括刚刚提到的跨任务协调以及任务间的依赖性，还有当用户提出查询时，如何将查询进行拆解。这部分工作是基于ReAct框架、知识库和技能池，组成了核心的Agent。实际应用到行业或领域时，我们会考虑技能池怎么构建，例如报表生成、结论总结、归因洞察等能力。具体规划上，我们尝试采用了COT（思维链）和TOT（思维树）等方式进行规划。然而，TOT相较于COT，对于复杂度和实效性的分解所耗费的时间更长，引发了用户等待的焦虑。

除此之外我们还会微调大模型进一步加强用户Query解析成API参数的能力，因为实际上不同的平台其接口的Json格式并不完全相同。那么，如何使我们的大模型更好地将用户输入映射到相应的调用API参数上？这就需要进行相关的微调。财外，我们还采用了类似Function Call的方式，当现有技能（尤其是分析能力）无法满足需求时，我们会调用Function，以形成完整的能力覆盖。

接下来聊聊第三部分。刚刚提到，用户是有等待时间要求的，在会话任务管理时，我们基于指标平台有一个非常强大的计算引擎——HME（HyperMetricsEngine）。

HME的原理是主要依靠底层数据进行加工，通过数据虚拟化和预计算的方式，在用户查询时它会知道你在该场景下哪个字段是最为常用的，然后会将这些字段自动预处理并作为缓存。如此一来，用户在下次查询时，这个指标无需再次开始加工，而是通过缓存的方式加快查询结果的呈现速度。

图中右侧部分是对一些传统数据获取方法和HME引擎查询效率的探究，以及如何通过这些方式提高性能的展示和解释。我们知道，企业的指标数量可能非常可观，因此保证查询性能显得尤为重要，尤其在我们刚刚提及的会话式任务管理方面。

接下来，我们通过一个金融行业的实践落地案例，深入解读数势大模型产品智能分析助手SwiftAgent为企业带来的实际成效。

该企业在实际运营中面临几方面的问题：

第一，需求激增，研发效能不足。业务层面的语言与研发团队使用的语言无法实现精准对齐。这导致许多人在描述同一事件时，业务层面的指标，如其口径，与研发团队认知的口径并不相同。在此种情况下，需求的沟通成本极高。当指标和报表开发过程中需要不断进行迭代和返工，这无疑会延长上线周期。

第二，缺乏指标管理工具。如果缺乏一个统一的指标底层管理工具，则有可能令指标的来源、开发的报表及口径来源等方面变得模糊不清，使用这些指标时，有时候可能会遇到无法确定其是否准确的问题。比如，A员工开发了一个指标或数据，B员工可能也开发了类似的数据，那么在同一个平台上该如何使用这两个数据呢？

第三，报表固化千人一面。举个例子，A员工在进行开发时无法将开发的数据进行有效的共享，这直接导致了下游用户在进行自助式分析的门槛较高，他们需要由企业招募相关分析人员才能应用类似自助分析的BI功能。一旦资产被加工完毕，实际上便无法再进行任何修改，而且类似于个人报表的设计也无法进行。

在实践过程中，我们将项目将其分为一期和二期，第一期的主要任务是建立企业的基础数据，并通过统一的指标平台进行管理。在此过程中，我们要完成诸多任务，例如，如何统一业务和研发团队的语言以确保每个指标的口径得到明确拉齐；以及建立数据委员会，实现数据间的拉齐，同时也保证了指标的定期更新和质量管理。

在底层数据建设完善后我们也注意到了上层的问题，即通过某些BI报表和看板，仅有少数人可以使用，或许在企业内部只有特定部门的一两位员工使用。正是意识到了这个痛点，我们基于大模型构建了Agent工具，集成了语义理解等相关技术，并开发出人和数据之间以最短的路径进行连接的产品，也就是SwiftAgent。

借助大模型技术，可以将一句话就拆分成不同的部分，换句话说，分析也是将业务流程分解成流中的各个节点，实现自动化执行，并将结果反馈给用户。最主要的是，用户只需检查结果是否符合预期的数据需求即可。

此外，该平台还有一个显著的优点，在使用数据分析产品时，传统的图形化产品需要通过埋点来了解企业内部员工的分析习惯和常用的场景，但如果无法得知他们的分析内容和洞察场景，那么在固定化指标字段进行预计算管理方面就会遇到困难。利用SwiftAgent，我们可以把高级分析人员的思路通过知识库和思维链的方式进行串联化，让初级分析人员也能获知该场景的思路。

分享的最后一部分与大家深入讨论一下，大模型与企业级场景如何结合和应用。

批量构建企业级Agent

应用分析肯定不是大模型落地的唯一场景，就像SwiftAgent重点也在于分析Agent的构建。一家企业往往有着各个角色，例如运营专家、策略制定专家，或者财务专家及人力资源专家。这些角色在就可以形成一个一个的Agent，不同角色其实存在技能重叠的现象。例如，运营专家与财务专家可能都需要数据查询的技能。当这些技能逐渐被公有化并抽象出来后，就可以在企业里构建一个技能池，基于不同的技能组合构件不同的Agent。这将是基于大模型的Agent在企业落地应用级能力的一个重要基础。

基于会话式任务执行的思考

同时，正如刚才所提到的，基于会话式任务的相关思考，就是我们在实际操作过程中需要把如何产生结果的这一思考过程，也就是所查询的具体指标、维度等信息公开给客户。因为我们需要以业务视角来帮助他们，实际上业务人员并不一定精通数据开发和分析，如果只告诉他们这个大模型的效果和准确性，他们可能无法理解。

因此，我们只需要用业务语言向他们解释业务的中间结果，如告诉你现在用指标查询查了何种数据、哪些维度，以及接下来将使用什么计算工具。通过这种更良好的交互方法，就能让客户对Agent实现的过程产生信任。

在实际工作中会发现，传统的问答模式其实是我们提问，机器回答，为何不让机器提问，我们回答呢？之所以如此，就是涉及到刚刚提到的我们为何要做出这种问题的联想和推荐。用户在使用产品时，只知道取什么数据，但是取完后基于这个数据下一步要去做什么呢，或者是数据中间有什么样的结果，以及有什么样的这种可洞察的结论，那其实如果不输入会话框，是不是这个产品就不能进行告知了？

答案是否定的。在基于大模型加持的能力的基础上，产品也应该告诉用户是否需要去做这件事情，以便指导用户去完成任务和目标，这样才能真正实现人与机器的协同，也就是让用户从主动变为被动，用户也才能真正喜爱和使用这个产品。

至于第三点，每个行业、每个领域，都有其自身的专家经验，即使在同一行业中的不同领域还是存在一些差异的。那么，如何在每个行业通过将专家经验融入到知识库中，然后将基于知识库与我们的产品相结合。这样，随着企业用户使用产品越来越多，其知识也会越来越多的灌入到产品里，从而形成知识库让刚入职的新员工也能更快地了解分析思路，帮助他们更快上手。

而第四点，我们要理解为何需要构建Agent，其实以GUI为基础的设计方针下，产品的实用性正趋于复杂化，原因正是因为我们力求满足广大用户的需求，因此研发一系列能力并嵌入产品中。然而，产品作为扁平化工具，其仅能展示一级功能，倘若这些一级功能过于繁复，那么便会将部分功能划分为二级、三级乃至四级功能，形成了迷宫式的操作环境。

当用户接触产品时，初期可能并不清楚该产品具备哪些功能或在何种情境下如何加以运用。那么，能否通过直接理解用户需求的表述来解决问题呢？作为产品开发人员，我们能够了解用户在何种环境下使用此功能，从而将后端功能与用户需求紧密联系起来，激发产品尚未被充分利用的潜在功能。例如，微软的Excel中只有20%的功能被频繁使用，而Excel之所以推出Copilot功能，其实也是为了激活更多的隐藏功能。

大模型的未来展望

关于数据使用与需求，尽管数据的动态变动性是不可忽视的事实，但其内在的意义依旧保持不变。早前，我们经常讨论大模型是否为我们创造了新的场景。有些人认为没有。但是不可否认的是，交互式的任务执行，实际上是大模型带来的一种新的场景，或者说让这种场景走向实际落地。

回归到大模型的本质，我们认为它是一个具备丰富知识的压缩体，就像人的大脑一样，学习了大量的知识后，才能做出思考和行动，解决现实环境中更为复杂的问题。

— END —