大模型在研发数据中台的应用实践

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

数据指标如下：

• 接入情况：覆盖了公司内部50多个APP、小程序、浏览器，以及外部收购的APP。
• 服务规模：每日处理近千亿条研发数据，数据峰值达到30万QPS，核心业务端到端入库时间达到秒级别。

• 业务可视化报表：针对通用化业务，提供例如问题概览、APP启动速度、用户分析等页面的可视化报表。
• 业务宽表与数据集：针对个性化业务，通过公司内部BI分析平台(TDA)，业务方可以自助完成需求分析。例如，互动搜索到达率和Feed页面展开流畅度等指标的监控。
• 端到端服务：结合业务流程，提供数据报表、平台工具进行端到端的支持，帮助业务方排查和解决问题。例如，线上问题的智能分析和云控拨测等服务。
  流程如下：

△线上问题排查解决流程

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

1. 基础依赖：通过采用统一的日志规范和日志SDK，提供多种自定义埋点功能以满足不同场景需求。依托大数据基础服务，将采集到的数据分发至各个应用方。
2. 平台能力：在数据计算方面，提供了离线数仓和实时数仓的构建能力。基础设施和分析工具方面，提供了各种算法模型以及多维度的问题分析。并实现了线上、线下开发测试全流程的场景覆盖。
3. 业务支持：基于平台层的基础设施，支持上层业务报表的计算。通过宽表建模以及大语言模型，实现了自然语言问数/Text2Viz的需求自助。同时深入结合业务场景，实现线上问题的一键式诊断和修复。
4. 产品支撑：覆盖重点应用程序和新孵化的矩阵应用程序，支持横向通用场景的业务需求。

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

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

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

△线上问题解决流程

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

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

数据分析归因：

• 数据分析：对外提供的数仓/数据集结构需简单、字段粒度需要足够的全面以及细致，业务方可通过自然语言或者简单的界面拖拽即可完成对应业务的数据分析配置。
• 自动归因：当系统监控到某些关键指标出现异常波动时，能够迅速分析出哪些维度对该次波动的影响最大。
• 问题分发：当出现线上问题时，通过问题现场的特征分析将问题指向负责该模块的组件以及RD/QA。

• 上线单召回：出现线上问题后，通过之前的数据归因环节可以获得问题的现场相关的特征分布。同时，中台和各个上线平台进行打通获得相应的上线单特征信息（时间、上线平台、topic），结合两者数据，通过一定的策略对产生本次线上问题的上线单进行召回。

• 止损预案推荐：通过数据归因、上线单推荐环节，可以归因到业务组件模块，通过中台和各个业务方向制定线上问题定位止损方案的文档以及知识检索技术，给出面对该线上问题时需采用的止损步骤。
• 问题智能修复：发生线上问题时，从数据流中可以获得问题的现场特征，从上线单召回模块中可以或者导致问题的上线单及代码，基于大模型的泛化能力对该线上问题进行修复。

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

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

• 控制器：控制器负责对查询请求进行意图识别，并将识别结果传递给任务规划模块。根据不同的意图，制定相应的任务规划路径，并对任务执行结果进行解析和调整，最终将结果返回给用户。
• Agent集合：在子Agent集合中，每个模块的功能高度内聚，并且每一组相对独立的大模型调用操作被视为一个Agent。通过控制器的任务规划模块，将子Agent串联起来，形成一个多Agent的工作流。每个Agent在工作期间都会维护自身的任务状态和结果，这些状态和结果可以作为下一步Agent行为的依据。

• 灵活性不足：复杂多变的业务场景都需要数据研发的参与，时间依赖开发侧排期。定制化结果灵活性不足，需频繁迭代，ADS层占用了数据研发团队大量的时间和精力。
• 交付效率低：随着业务发展越来越快，数据需求大量增加，所需的人力成本增加、交付效率降低。
• 数仓结构复杂：随着需求的不断迭代，表的数量容易迅速膨胀并变得杂乱，导致开发过程复杂。需求可能需要关联查询N张表，子查询层级超过M层，数据分析和归因分析的准确率低。

数仓建模思路

△宽表建模思路流程图

技术方案

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

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

宽表建模具有以下优点：

1. 结构简化与维护便捷：相比传统的500多张层级表，宽表建模将结构简化为20多张宽表，维护更加方便且数据冗余更少。
2. 需求自助化率高：宽表的设计使得用户操作更加简便，业务需求的自助化率超过80%。
3. 高效的数据存储：宽表/数据集存储采用冷热分离（CK+HDFS），业务宽表和数据集的查询速度能够达到秒级响应。
4. 智能分析：宽表层及其数据集支持上层应用的数据智能分析（如生成式BI和自动归因），可以通过自然语言生成业务自助看板。

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

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

1. 任务组依赖：通过调度平台的任务名称进行依赖检查，支持内部的Pingo和TDS调度平台。
2. AFS文件依赖：在某一版本合并至宽表后，生成该版本任务成功的AFS标识文件，供下游进行依赖检查。
3. 字段产出探测服务：对于其他数据应用平台，当平台无法通过任务组或AFS文件依赖识别字段是否产出时，提供字段探测服务。在某一版本合并至宽表后，更新探测服务中该版本相关字段的产出标识，数据应用平台通过API接口调用判定查询时间范围内字段是否就绪，从而保障数据的可用性。

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

• 降低门槛、提高效率：业务方可以直接通过自然语言交互，即时获取所需数据。
• 更细致的数据分析：传统的人工或者工具分析在处理业务指标（上千个观测指标）时有其局限性，而AI能够实现更为精细和准确的分析。
• 分析准确性持续提升：随着时间的推移和数据的积累，系统将持续学习，从而不断提高其性能和分析准确性。

△数据分析变革迭代

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

△生成式BI功能设计

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

• 自然语言问数：业务部门通过自然语言完成业务需求，通过Text2Func技术获取查询结果。
• 自动图表生成：根据提问结果，选择合适的图形界面进行展示。
• 智能总结：对查询结果进行智能总结。
• 归因分析：在数据产生波动时，分析并提供数据波动的原因，识别出贡献度最高的指标和维度。
• 特征分发：通过归因分析，识别出波动的主要指标和维度，并根据知识库的维度指标映射进行问题分发。

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

• 用户友好性：虽然自然语言问数系统的背后技术可能非常复杂，但其Func接口封装的简洁易用，用户无需了解SQL语言或数据库结构也能轻松进行查询。
• 准确性：这是最基本也是最重要的能力。系统需要能够准确理解自然语言查询，并转换成正确的Function查询语句，以确保用户意图得到准确执行。
• 响应速度：在工业应用中，快速响应是至关重要的。系统需要能够在秒级别内处理查询，快速返回结果。
• 可扩展性：随着数据量的增加和查询需求的变化，系统应能够方便地扩展，包括处理更复杂的查询、支持更多的数据库和表、以及优化性能等。
• 适应性与自我优化能力：系统应能够基于用户反馈和使用情况自我优化，不断调整模型以提高准确性和效率。适应性还包括能够适应新的数据库结构和业务逻辑的变化。
• 安全性：在处理敏感数据时，系统必须确保高安全性，包括数据加密、访问控制等，防止数据泄露或未经授权的访问。

技术方案

△基于Text2Func框架图

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

• 数据构建阶段：精标案例的录入、场景模型的训练。
• 数据查询阶段：数据查询的优化，对查询结果在工程上适配。

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

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

• 大盘初步归因分析：关注识别导致关键指标波动的总体大盘状况。例如，分析线上问题突增的背后原因，涉及到的因素可能包括应用APP版本、操作系统、基础组件等较为通用的因素。
• 业务下钻二次归因分析：在识别了影响波动的大盘指标后，进一步按照与业务更相关的指标进行深入分析。例如，问题的具体页面、网站、进程、AB测试等与具体业务相关的指标。

• 能够基于指标波动，分析不同维度对波动的贡献度，并能够精确到具体的维度指标，例如将问题归因到应用程序的一个特定APP版本突增。
• 能够根据业务需求，区分不同指标维度对波动贡献度的重要性。比如初步大盘分析，侧重分析APP版本、操作系统。二次归因侧重于页面、进程等。

技术方案

△归因总结Agent流程图

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

2.2.3 止损方案推荐

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

• 私有数据的需求：大型语言模型（LLM）通常缺乏获取实时或领域特定知识的能力，同时，频繁地进行微调（fine-tuning）会带来较高的成本。因此，需要将私有数据视为一个外部数据库，使得LLM在回答涉及私有数据的问题时，能够直接从外部数据库中检索相关信息，并结合这些检索到的内容进行回答。
• 知识的动态更新：知识库可能会不断地进行内容的补充和更新。在进行问题检索时，有必要确保检索到的是最新的知识，以保证回答的时效性和准确性。
• 增强可解释性：传统的LLM在提供答案时往往类似于一个“黑箱”过程，可能会产生不准确或无根据的回答，并且通常不会提供信息来源。而RAG通过建立检索内容与回答之间的关系，增强了模型的可解释性，使得业务能够明确知道LLM的回答是基于哪些信息得出的。

• 优点
• 通用性强、灵活性强、可拓展性强。
• 实现相对简单、技术成熟度高、开发门槛低。
• 缺点：
• 查询-块相似度的局限性：仅根据查询和块之间的相似度来检索，可能无法充分考虑查询的复杂性和多样性。这种方法可能忽略了查询背后的语义意图，以及不同信息块之间的相关性。
• 检索效率低：当数据库非常大时，对所有块进行相似度比较的过程仍可能非常耗时，这对于需要实时或近实时响应的应用来说，是一个显著的瓶颈。
• 信息片段化严重：将文档分割成较小的块可能导致信息的冗余和片段化，一个小的片段没有足够的上下文来支持生成模型产生准确的回答。
• 固定块大小的限制：固定大小的块可能不适合所有类型的查询。对于某些查询，较小的块可能缺乏足够的信息，而较大的块可能包含太多不相关的信息，这两种情况都可能降低检索的准确性和相关性。

△常规RAG检索方案

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

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

△止损方案架构图

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

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

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

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

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

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

• 模型输入的精确度

• 场景识别的准确性

• 知识增强的应用

• 模型的调优与参数调整

2.2.5 数据飞轮的构建

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

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

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

• 案例库中线上问题经验总结风格相似。
• 同一个线上问题可能在不同的产品线出现，可以借鉴经验，而不用重复解决。
• 线上已收录的案例可作为新的线上问题智能诊断的案例参考(few shot)，提升大模型回答的准确度。

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

• 大模型回答准确率和响应速度优化：业务逐步切换至专业垂类模型，灌入更多的精标语料提升准确性。
• 智能体架构的优化：目前业界的智能体架构在规划任务时，回答问题过程中经常出现死循环或者一步错步步错的问题，因此中台通过工程化的方式让智能体限制在一定的特定场景，再去规划任务，后续希望将非全自主的方式->全自主的方式。
• 赋能更多的业务场景：智能日报周报等，通过大模型将这些业务报表的智能总结以及波动归因以日报/周报的形式直接给到业务，提升数据分析的效率。