导读

研发数据中台负责MEG所有研发数据的管理、接入、传输、应用等各个环节。中台的主要构建3个能力：构建端研发数据实时感知能力、线上问题/数据的便捷分析能力、线上问题的快速止损召回能力。随着业务的不断变化和发展，越来越多的业务同学对中台的问题分析定位效率有更高的要求。随着ChatGPT和文心一言大模型相继发布，公司内外都在探索使用大模型提升线上问题分析的效率，也使我们看到了提升线上问题数据分析效率的可能性。本文主要介绍中台利用大模型在数据分析、线上问题快速定位等方向所做的一些努力(Agent建设)，核心点是利用大模型强大的推理判断以及泛化能力对效率低的工作方式以及流程进行重构，最终提升业务的工作效率。

01 简述1.1 平台介绍

研发数据中台（性能中台）是一个专为APP性能追踪设计的一站式解决方案平台。通过先进的数据采集与监控技术，为APP提供实时、全链路的应用性能监控服务，助力APP提升线上问题排查与解决的效率。

数据指标如下：

中台通过以下三种方式为上层业务提供支持：

△线上问题排查解决流程

1.2 服务全景图

中台服务主要包括以下几个层面：基础依赖、平台能力建设、业务支持以及产品支撑。

基础依赖：通过采用统一的日志规范和日志SDK，提供多种自定义埋点功能以满足不同场景需求。依托大数据基础服务，将采集到的数据分发至各个应用方。

平台能力：在数据计算方面，提供了离线数仓和实时数仓的构建能力。基础设施和分析工具方面，提供了各种算法模型以及多维度的问题分析。并实现了线上、线下开发测试全流程的场景覆盖。

业务支持：基于平台层的基础设施，支持上层业务报表的计算。通过宽表建模以及大语言模型，实现了自然语言问数/Text2Viz的需求自助。同时深入结合业务场景，实现线上问题的一键式诊断和修复。

产品支撑：覆盖重点应用程序和新孵化的矩阵应用程序，支持横向通用场景的业务需求。

大模型的应用实践主要针对需求自助、问题智能分析两个模块。 !

△研发数据中台服务全景图

1.3 业务背景

随着业务的不断变化和发展，越来越多的业务同学对研发数据中台的易用性有更高的要求。在过去的几年里，中台在用户和研发数据交互的易用性以及线上问题的快速分析能力做了大量的优化和尝试，提升了业务自助化快速分析的能力以及线上问题的解决效率。但依然面临：定位问题时数据分析存在一定的门槛、核心指标例如MTTI(问题定位时间-问题感知时间)依然过长(小时级)等问题。自ChatGPT和文心一言大模型相继发布，公司内外都在探索使用大模型提升自身平台业务分析的效率，相关的经验也让我们看到线上问题定位分析变革的可能性。我们基于研发数据中台的积累以及与大模型能力的结合，探索新的线上问题智能分析系统。

在快速发展的移动应用领域，APP需要保持持续不断的技术迭代来保证APP的竞争力。然而，对于规模庞大、用户众多的APP应用，每一次的变更上线都存在引入线上问题的风险。但APP的各个组件模块相互调用，一旦某处出现异常，往往会像连锁反应一样影响整个系统的稳定性，这些问题可能表现为崩溃、卡顿、功能失效等，严重影响用户的使用体验。当感知到线上问题出现时，线上问题的止损、定位解决的时间长短决定了问题的影响面大小。目前线上问题的定位流程如下：

△线上问题解决流程

从流程可以看出，目前对于现场问题的定位，绝大多数环节都需要人为参与分析和定位。问题的定位和解决时间高度依赖于接收到告警的同学的分析能力以及他对系统各个组件的熟悉程度，这导致了整体定位时间过长（通常在小时级别）。这种情况可能导致原本的P4问题恶化为P1问题。如果我们能够利用大模型强大的泛化能力、自动化决策能力，对上述流程进行重构，将当前的人为逐步跟进的线上问题解决方式优化为自动一键式解决方案（智能分析），那么问题的整体定位时间将大大缩短，从小时级优化到分钟级别。以线上告警为例，通过智能分析，问题的自动归因、问题上线单的关联、问题的止损方案以及解决步骤均可实现一键式解决。

02 技术方案

为了协助业务实现问题端到端闭环的目标，线上问题的智能分析需满足以下功能：

数据分析归因：

上线单推荐：

解决方案推荐：

2.1 智能分析架构

通过对整体功能模块的拆解和抽象，线上问题智能分析的整体技术架构如下所示：

△线上智能分析整体架构问题图

从上图可以看出，当用户请求(例如告警)到达智能分析时，将经历以下两个环节：

用户请求经过上述两个环节返回给用户，因此线上问题智能分析的回答准确率取决于控制器的任务规划能力以及各个任务Agent的执行任务的准确率。接下来，分别对智能分析的各个核心组件进行介绍。

2.2 数据智能分析

数据分析归因组件核心的能力是生成式BI以及数据自动归因的能力，而这些能力的关键指标是回答的准确率。提升准确率的关键在于以下两方面：

数仓建设：合理的数仓建设至关重要，它可以显著提高生成式BI和数据归因能力的准确性。SQL语句的层级数量、多表关联的复杂度以及字段的清晰度都会严重影响生成的SQL质量以及归因的结果。

数据工程：在数据仓库合理建模之后，通过一系列数据工程技术，激发大模型的回答潜力，同时对大模型自身进行调优，显著提升大模型在数据分析中的表现。

2.2.1 数仓建设

在业界，通常采用分层模型来构建数据仓库。当业务部门需要查看某个指标的数据变化时，会向数据中台提出需求。数据研发团队会按照ODS->DWD->DWS->ADS逐层进行建模，并通过定制化开发ADS层来满足业务需求。最终，这些数据会配置成多个图表，保存到报表中供业务查看。尽管这种建设思路可以满足业务的数据需求，但也面临以下三个主要问题：

因此，研发数据中台需要探索一种新的数据开发交付模式，从传统的研发定制化开发转变为业务需求自助化开发方式，但这对数据仓库建模和数据可视化平台的使用体验提出了更高的要求。

数仓建模思路

上述数据仓库的复杂性主要源于其过长的链路、结构层级复杂以及ADS层报表开发逻辑的高度复杂性，导致业务部门无法直接通过拖拽BI或者自然语言问数的方式生成所需的业务报表。基于上述问题，我们决定将数据仓库的建模方式从传统的分层建模转变为宽表建模。对外提供的宽表或者数据集需满足以下条件：

1、全面：覆盖场景足够丰富，可以充分满足业务需求。

2、及时：解决上游时效差异化带来的木桶效应，字段分批产出。

3、易用：需求场景通过少数宽表即可获取，避免多表关联。

4、准确：逻辑统一收敛，口径简单清晰，业务使用无歧义。

5、智能：高准确度的支持自然语言问数或者报表归因总结能力。

宽表建模核心在于将上层的业务逻辑尽可能地下沉到宽表中，使宽表的数据粒度足够简单易用，并且合理的设计存储使得查询具有较高的相应速度。具体的流程如下：

△宽表建模思路流程图

技术方案

研发数据业务场景复杂，数据来源多，包括研发流量日志、产品流量日志、业务数据日志及server集群日志等，为了平衡数据时效性及易用性，共构建了500+张DWD、DWS及ADS分层报表，这个报表层级存在表血缘关系复杂、中间表冗余、数据口径不一致、SQL复杂度高等问题。为了解决上述问题，我们提出宽表建模方案：根据产品功能和业务场景划分主题，明确主题最细粒度及所有的业务过程，基于ODS表直接构建宽表层，宽表覆盖业务所需全部字段，支持即席分析、报表查询、自动归因、ChatBI等所有数据应用场景。基于上面的建模思路，研发数据中台的整体宽表设计如下：

△研发数据中台宽表建设流程图

宽表建模具有以下优点：

结构简化与维护便捷：相比传统的500多张层级表，宽表建模将结构简化为20多张宽表，维护更加方便且数据冗余更少。

需求自助化率高：宽表的设计使得用户操作更加简便，业务需求的自助化率超过80%。

高效的数据存储：宽表/数据集存储采用冷热分离（CK+HDFS），业务宽表和数据集的查询速度能够达到秒级响应。

智能分析：宽表层及其数据集支持上层应用的数据智能分析（如生成式BI和自动归因），可以通过自然语言生成业务自助看板。

然而，宽表建模也存在一定的缺陷。由于宽表依赖多个上游数据源且数据量巨大，当多个上游数据源的就绪时间不同步时，宽表的产出时效会受到限制。此外，为了尽可能覆盖全部业务需求，宽表封装了大量的处理逻辑和关联计算，导致代码更加复杂，维护成本和回溯成本较高。为了解决上述问题，我们探索并实现了宽表建模的多版本方案。根据数据的时效差异，将宽表拆分为多个计算任务，每个任务负责产出宽表的部分字段，并通过配置进行数据合并，最终生成完整的宽表。由于同一版本在不同日期的产出时效受上游数据源的影响不可控，为提升宽表整体的时效，需要在各版本数据产出后尽快将其合并至宽表。合并后，还需为下游提供依赖检查机制，以便感知该版本字段的产出状态。

△业务宽表分版本产出流程图

为确保各版本数据在产出后能够迅速合并至宽表，并避免同一分区内同时运行两个合并任务导致数据混乱的问题，我们引入了分布式锁服务。这一机制保证了每个宽表在任意时刻仅有一个合并任务或回溯任务在执行，通过抢占锁来决定是否进行合并。同时，由于多版本宽表中的字段基于时效差异进行分版本产出，因此需要提供依赖检查机制，以便下游及时使用已就绪的字段，满足高时效的数据应用场景。针对不同的场景，方案中提供了三种不同的依赖检查方式：

任务组依赖：通过调度平台的任务名称进行依赖检查，支持内部的Pingo和TDS调度平台。

AFS文件依赖：在某一版本合并至宽表后，生成该版本任务成功的AFS标识文件，供下游进行依赖检查。

字段产出探测服务：对于其他数据应用平台，当平台无法通过任务组或AFS文件依赖识别字段是否产出时，提供字段探测服务。在某一版本合并至宽表后，更新探测服务中该版本相关字段的产出标识，数据应用平台通过API接口调用判定查询时间范围内字段是否就绪，从而保障数据的可用性。

当宽表建模完成后，数据中台的需求交付方式由被动承接需求转变为用户自助完成需求，生成式BI以及业务自动归因的准确度也得到了显著提升。

数据分析

完成数据仓库的宽表建模后，业务方能够利用BI工具，通过编写简单的SQL语句或通过图形界面的拖拽操作来满足自身需求。然而，此过程仍存在一定门槛，例如业务部门必须熟悉各数据表的结构、表Schema、数据血缘关系及必要的SQL知识。为了提高线上业务问题的数据分析效率，中台落地了自然语言问数。该系统的优势主要在于：

数据分析的更迭过程如下：

△数据分析变革迭代

整体的构建思路依然是帮助业务更加有效率的分析解决线上问题。当业务方遇到线上问题时，首先是提供业务部门以自然语言提问的能力(Text2Func)；其次，根据提问结果生成合理的图形化界面；接着，对返回的结果进行智能总结；最后得出业务问题的归因分析结果。整体功能设计如下：

△生成式BI功能设计

因此，生成式BI系统需要具备以下核心能力：

而一个可以投入工业生产环境使用的生成式BI系统需要具备以下几个关键能力：

技术方案

整体架构设计如图所示：

△基于Text2Func框架图

在生成式BI中，业界的通用的技术方案均是将表的schema的信息以及用户查询信息通过prompt工程传输给大模型让其生成SQL或者方法，但是在较为复杂的场景下，上述方案在落地的过程中遇到了许多问题，比如查询的准确性、时效性、大模型的token长度限制等。为了解决上述问题，我们将生成式BI分成了两个阶段：

具体的核心修改点如下：

2.2.3 数据归因

在完成了宽表建模和生成式BI等基础设施建设之后，下一步的重点是发展数据的自动化总结与归因能力。这一过程主要通过与业务场景紧密结合，构建基于底层数据的通用归因能力，从而提高业务查询分析问题的效率。其核心目标在于，将业务团队之前需手动执行的问题排查流程自动化，同时确保分析的准确性。目前，中台业务团队主要聚焦于三个场景下的数据总结与归因：

根据上述业务场景的分析，归因分析需展现以下能力：

因此，数据归因分析模块必须具备以下两方面的能力：

技术方案

在数据归因总结模块的设计中，采取了一种结合大型模型与专业化小型模型的策略。对于某些专业垂类领域，业界已有的成熟模型和算法在精确度上比直接应用大型模型进行分析准确率有明显优势。因此在归因分析总结过程中，大型模型利用自身出色的归纳和总结能力及决策判断力来负责归因算法的选择以及和对输出结果总结，而具体的归因分析则是在算法模型层实现。整个架构的设计如下：

△归因总结Agent流程图

大型模型的任务规划会依据算法模型层的各个归因模型所具备的基础功能及其适用的业务场景，用户查询时会选择合适的模型算法进行计算。而智能总结模块则根据归因模型提供的结果进行综合汇总，通过输出控制层，将查询结果反馈给用户。算法模型层各个算法模型的基本功能和适配的业务场景如下：

在选定算法模型之后，为了满足业务需求，算法中会引入权重因子对各个维度在归因分析中的影响力进行调整。这一过程涉及计算各维度的加权平均值，进而根据这一加权平均值确定哪些维度的表现超出了预设的水平，作为分析和决策的基础。归因特征分析完成后，通过建立从归因特征到组件/人员的的映射关系，直接将线上问题分发到实际业务方进行问题修复。

2.2.3 止损方案推荐

通过线上问题数据归因以及特征分发后，目前中台已能够根据线上问题的特征直接将问题定位到具体的业务组件。针对线上各类问题，每个业务组件都会有相应的应急止损方案文档。因此，在线上问题发生时，中台需要依据组件所处的具体问题现场，推荐相应的止损步骤。例如，当归因分析指出问题的增加是由内核组件的host站点异常引起时，中台将提出针对host站点异常情况下，内核组件应采取的止损步骤，具体推荐步骤会标注为红色文字以示区分。

根据特定知识库解答私有数据问题时，业界普遍采用且落地效果明显的技术选型是RAG（Retrieval Augmented Generation）。选择此技术的主要理由是：

在常规的RAG流程中，先将文本进行分块处理，随后利用Transformer Encoder模型将这些文本块转化为向量，并存储于向量数据库中。在接收到查询请求时，系统通过相似度判断找出相关的文本块，然后构建一个大型语言模型（LLM）的提示词（prompt），最终返回用户的查询结果。

综合以上分析，业务常规RAG方法的准确度约为45%左右。因此，业界针对缺点有许多优化方案，业界常采用的优化策略（如langchain/llamaIndex）--- 高级（Advanced）RAG。

△常规RAG检索方案

根据止损方案推荐的业务场景，针对常规RAG不足的地方进行了以下优化：

止损方案推荐的整体架构如下：

△止损方案架构图

2.2.4 线上问题智能诊断

出现了线上问题后，通过归因分析将问题指向业务方，业务方通过止损应急预案推荐完成应急止损后，任务便转向协助业务团队进行问题的彻底修复。线上问题的修复包括三个部分：

① 通过分析线上问题数据流，能够获取到线上问题发生时的现场信息，如设备信息、错误堆栈、调用链等详细信息。

② 通过步骤①可以获得问题现场特征，而通过各个上线平台打通可以获得上线单信息，结合两者，完成上线单的推荐。

③ 通过步骤①可以获得问题现场、通过步骤②可以获得上线单以及问题代码，结合两者信息，通过LLM建立一键式线上问题智能诊断，整体的设计如下：

△线上问题智能诊断流程图

智能诊断的准确率主要依赖以下四个方面：

确保输入代码的准确性(上线单推荐)以及输入崩溃的准确性，主要是对输入的线上问题堆栈的解析。APP厂商在发布应用程序包时，通常会对包进行混淆操作，这是为了提高APP应用的安全性和减少反编译的风险。混淆是将源代码中的符号、名称和结构等转换为难以理解的形式，使得反编译后的代码难以还原为原始的源代码，但是APP上报的异常信息也被混淆了。反混淆操作是将混淆后的异常信息还原为可读的形式，使开发人员能够更准确地分析问题的原因，并迅速采取正确的修复措施。在APP产出应用程序包时，同时也会产生一份用于反混淆异常信息的映射文件（密码本），通过映射文件 + 解析算法对混淆的异常进行解析，即可得到已读的异常堆栈。通过在数据工程上的优化（算法优化 + 多级缓存等方式），完成了ms级堆栈的解析。

正确识别不同线上问题（例如崩溃、卡顿）的场景对后续处理流程至关重要。为此，中台采用了业界通用的的分类模型（如TextCNN/DPCNN）来完成场景的精确识别。

核心在于利用高级RAG技术，结合线上已解决的类似问题的总结，辅助大语言模型解决新问题。prompt通过从zero-shot到few-shot的转变，激发大型语言模型的潜能。

根据业务场景选择模型调用的参数。temperature：较高的温度值会产生更随机的输出，而较低的温度值则会使模型更倾向于选择最可能的单词。top_p：模型从累计概率大于或等于“p”的最小集合中随机选择一个。常用temperature、top_p的调节关系的参考如下：

2.2.5 数据飞轮的构建

数据飞轮在大模型应用的发展中发挥着至关重要的作用，收集用户数据 -> 基于用户数据反馈迭代产品 -> 由此吸引更多用户使用，收集更广泛数据，最终形成一个正向的反馈循环，与移动互联网时代产品迭代思路类似。但在用户数据收集环节（数据类型&数据重要性）产生了差异，整体的对比如下：

在构建我们应用的数据飞轮时，用户输入query是产品交互的首步环节，因此其获取难度不大，更大难点在于如何在Agent产品下引导用户“自愿无感”的给予结果反馈，这也应该是AI产品设计时需要考虑的重要环节，最好内嵌至用户流程中，无需用户给出额外的动作反馈。因此，线上问题智能分析将自身的工具结合到业务流程中，让用户“自愿无感”的给予结果反馈，数据飞轮的流程如下：

△线上问题智能分析数据飞轮流程图

借助大模型能力构建了一个基于端问题的案例库，当解决完一个线上问题后，线上问题案例编写95%的工作均由大模型来完成，业务的工作可能是对案例进行审核或者对不对的结果进行修正，通过审核后的线上案例会进入案例库。当统一案例库建设完成之后：

03 总结

前文介绍了中台利用大模型在数据分析、线上问题快速定位等方向所做的一些努力，核心点是利用大模型强大的推理判断以及泛化能力对效率低的工作方式以及流程进行重构，最终提升我们的工作效率。后面我们依然会继续对中台进行优化，例如：

最后，随着通用大语言模型的发展和智能体Agent技术的兴起，我们正迎来 AI 应用开发重构的一个新时代。无论是什么业务，都能在这个新时代中找到属于自己的空间。未来充满着无限的潜力和广阔的天地，等待着我们去探索和创造。

————END————