大模型在研发数据中台的应用实践_AI阅读总结 — 包阅AI

。

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

研发数据中台（性能中台）是一个专为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问题。如果我们能够利用大模型强大的泛化能力、自动化决策能力，对上述流程进行重构，将当前的人为逐步跟进的线上问题解决方式优化为自动一键式解决方案（智能分析），那么问题的整体定位时间将大大缩短，从小时级优化到分钟级别。以线上告警为例，通过智能分析，问题的自动归因、问题上线单的关联、问题的止损方案以及解决步骤均可实现一键式解决。

线上告警现状

智能分析告警

告警通知： 监控名称：崩溃突增 产品线：手机百度app 系统：android 数据看板：平台链接 报警详情：17:45:00-17:59:00 连续3个周期内pv>1000 监控时间：2024-04-22 18:00:00

告警通知： 监控名称：崩溃突增 产品线：手机百度app 系统：android 数据看板：平台链接 报警详情：17:45:00-17:59:00 连续3个周期内pv>1000 监控时间：2024-04-22 18:00:00  【推荐排查思路】 归因分析及分发： 指标异常归因：90%的崩溃在app 版本[13.45.0.17] 基础组件归因：80%的崩溃在聚类 java.lang.NullPointerException，组件：基础架构，RD:XX，QA:XX 业务归因：在问题聚类java.ang.NuPointerException中，90%聚类发生在进程[searchbox.applet](小程序页面)，负责人RD:XX，QA: XX 可疑上线单以及icafe： 1) top1上线单 上线平台:contentcms 可疑度:95.0%，上线关联卡片链接 2) top2 上线单上线平台: jarvis 可疑度: 90.0%，上线关联卡片链接 止损及解决方案： 1）应急止损预案：按照知识库中小程序站点异常的应急方案，需对XXX站点进行屏蔽，屏蔽步骤为：XXX。 2）问题智能诊断：该崩溃是由于APP程序中的某个严重问题引起的，如内存访问错误、无法处理的异常、非法操作等。代码修复结果：XXXX。

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

数据分析归因：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

数仓建模思路

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

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

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

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

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

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

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

△宽表建模思路流程图

技术方案

研发数据业务场景复杂，数据来源多，包括研发流量日志、产品流量日志、业务数据日志及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以及业务自动归因的准确度也得到了显著提升。

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

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

△数据分析变革迭代

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

△生成式BI功能设计

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

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

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

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

技术方案

△基于Text2Func框架图

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

• 数据查询阶段：数据查询的优化，对查询结果在工程上适配。

阶段	流程	目的	具体步骤
数据构建	场景模型训练	通过对业务精标、以及SQL2Text数据的采集训练场景识别以及选表能力模型。
	数据知识检索增强	大模型领域知识增强
数据查询	查询优化	对查询语句进行优化，更复合查询逻辑	将查询语句拆解或者转化为固定Func方法的调用，Func调用可避免生成SQL语法错误，将SQL转化为func调用。
	召回选表	减少查询表的数量，提升选表的准确度
	Schema Linking	避免prompt长度超过大模型上下文长度限制	通过宽表建模，将业务场景从选择多表多字段级联查询->单表字段选择(包括几百个字段)，更为精确的列信息使得生成的SQL准确度越高
	prompt工程	激发大模型回答的潜力	提示词=角色+技能+查询任务拆解+表+schema_link+带cot的上下文(few shot)+输出规则
数据产出	自我反思和纠错	异常场景下，二次回答提升的准确率	面对不同的出错场景，例如生成的结果和表字段的关系不匹配、语法错误等，通过再次交互让大模型进行自我反思，重新生成结果。
	工程化的方式	通过一些工程建设提升回答的准确率

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

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

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

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

技术方案

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

△归因总结Agent流程图

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

算法及模型	角度	基础功能	业务适合场景
超均算法	微观	直接量化和识别哪些具体项对整体变化有显著贡献(和以往的平均值做对比)	适合需要确定是维度以及具体是哪个指标导致，和以往的平均值做对比
方差算法	宏观	用来衡量数据集整体的分布特性	适合需要得到哪个维度波动导致数据波动，但是不需要确定是具体是哪个指标导致
基尼系数算法	宏观	衡量分布不平等程度的指标，其值范围从0(平等)到1(不平等)	适合需要得到哪个维度波动导致数据波动，但是不需要确定是具体是哪个指标导致
波动贡献算法	微观	方法的目的是分析和识别哪些组成部分对总体波动性(判断波动的整体原因)	适合需要确定是维度以及具体是哪个指标导致，判断波动的整体原因
JS散度算法	宏观	判断实际业务与预期业务的概率分布相似度	适合判断预期业务的分布贡献和实际业务分布贡献的对比
综合贡献度算法	微观	采用因素分解的方法，将结果的变化分解为分子和分母两部分的贡献	适合多表归因总结，需要综合考虑的场景

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

2.2.3止损方案推荐

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

业务方向	子方向	负责人	线上应急预案排查思路
崩溃	内核	XXX/XXX	1.关注问题host站点的变化 a. 若问题聚类到host站点，请按以下步骤进行止损： i: host->站点->先对该站点进行手动屏蔽，观察趋势 ii: 将搜索query->反馈给搜索的同学，优先查看数据中的query和title信息等是否可以有对应的归因分析 iii: 尝试复现的某几类host，真机xmonkey自动化以url为参数做复现，需要提供完整的url信息给到业务做问题复现 b.若不聚类到站点，则观察其他方向 2. 关注问题的页面特征的变化 a. 若问题聚类到Feed方向 i: 将页面->反馈给Feed方向 ii: 用真机模拟页面进行调用 b.若问题聚类到小程序方向 i: 重点排查进程中是否有明显的小程序的分布信息 ii: 如果以上的线索中没有明显的线索，查看logcat信息是否有明显的tag聚类和研发沟通一下给一些经验的数据，字符串等作为tag识别，找一些关键词等是不是每个崩溃都有 iii:尝试复现的某几类host，真机xmonkey自动化以url为参数做复现，需要提供完整的url信息给到业务做问题复现

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

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

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

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

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

△常规RAG检索方案

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

阶段	增强方式	描述
1、如何对输入的源头进行优化？	数据增强	在检索前对数据进行预先完善，去除不相关信息，歧义信息等，保证文档输入的准确性。
	查询语句优化	通过优化输入查询来增强检索结果，例如multi-query或者查询拆解进行查询。
2、如何检索出有效的信息？	元数据建立	按照业务对元数据进行业务拆分，例如增加一级业务索引（崩溃、搜索、Feed）等。
	块优化	通过调整检索文本块的大小来获得更好的检索成果，句子窗口检索可以用更好的效果。
	混合索引	同时使用多种类型的检索方法，多路召回。向量 + 关键词的搜索(bge embeding + bm25 search)。
	重新排序	业务效果较好的RRF（倒数排序融合）对上述搜索结果进行重排，选择top k。
3、如何根据这些信息利用大模型输出更好的回答？	提示词工程	通过设计有效的提示来激发大模型输出的质量。
	微调大模型	使用经过语料训练的文心-speed模型代替文心4.0，包括post-pretrain、SFT、参数调优、效果评估等部分。
4、对大模型输出的结果进行后处理？	文本溯源	要求大模型一定按照知识库内容回答，并给出回答信息源（块），避免大模型幻读。

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

△止损方案架构图

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

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

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

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

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

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

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

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

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

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

业务场景	temperature	top_p	描述
代码生成	0.2	0.1	生成符合既定模式和约定的代码，输出更具确定性和针对性，生成语法正确的代码。
创造写作	0.7	0.8	生成创意和多样化的文本，输出更具探索性。
聊天机器人	0.5	0.5	生成聊天对话，在连贯性和多样性之间取得平衡，使得输出更自然、更吸引人。
代码注释生成	0.3	0.2	生成的代码注释简洁且相关，输出更为确定性且遵循约定。
数据分析	0.2	0.1	生成的数据分析SQL需要正确且高效，输出需要更为确定。

2.2.5数据飞轮的构建

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

	交互模式	用户数据类型	用户数据作用
移动互联网	GUI	数据相对结构化，eg 用户的点击、停留时长等	数据收集用于理解用户需求辅助产品决策支持，产品迭代满足仍依托于产品经理
LLM Agent	LUI为主	数据类型更多元&长尾：更依赖用户的直接输入和对于模型输出的结果反馈 eg 基于用户输入query分析理解用户意图 eg 基于用户结果反馈理解用户满意度	用户输入&结果反馈数据，清洗&二次标注后直接作为新的训练数据作用于产品效果提升

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

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

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

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

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

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

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

活动时间：

9月2号-9月8号

活动文案：

每一次留言都是一次思想的碰撞
每一个观点都可能引发一场精彩的讨论

快来参与互动吧！！！

参与方式：

1：关注我们的微信公众号。
2：在本篇文章下方留下精彩留言
3：邀请亲朋好友为你的留言点赞

活动规则：

1：活动期间，你的留言将有机会获得众多点赞，成为人气王！
2：我们为点赞人气王留言准备了神秘礼物盲盒。