ByteBrain团队FSE25 | 基于LLM的自动化Oncall升级

推荐语

探索字节跳动ByteBrain团队如何利用大语言模型（LLM）优化Oncall升级流程。

核心内容：
1. FSE 2025会议背景及ByteBrain团队论文入选情况
2. Oncall在云计算服务中的重要性及其传统处理模式
3. TickIt系统：基于LLM的自动化Oncall升级方案及其面临的挑战

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

前言

软件工程领域顶级学术会议之一FSE 2025（The ACM International Conference on the Foundations of Software Engineering）预计将在2025年6月于挪威特隆赫姆举行，字节跳动ByteBrain团队的论文《TickIt: Leveraging Large Language Models for Automated Ticket Escalation》成功入选（https://arxiv.org/abs/2504.08475）。

背景

在云计算技术蓬勃发展的当下，对于火山引擎来说，工单/Oncall 成为了客户与技术支持&SRE团队沟通的关键桥梁。随着云服务规模的不断扩大，每日会产生数以千计的Oncall。这些Oncall通常以自然语言的形式，涵盖了使用咨询、功能需求，系统故障等各类复杂问题。

在传统的手动升级模式下，Oncall值班人依赖个人经验判断工单是否严重，进而决定是否应该进一步升级。这一过程很依赖值班人员的经验判断，也难以形成统一标准。在过往的案例研究与故障复盘中，我们发现由于人为疏漏，部分严重问题没有及时升级处理，从而导致了稳定性下降的风险，这也可能对火山引擎的客户满意度造成负面影响。

如何在面对紧急问题时，及时识别并升级这些Oncall，成为了提升客户满意度和保障服务质量的关键所在。针对这一问题，我们提出了TickIt，旨在识别紧急的、报告严重问题的Oncall，并及时地将其升级给产研/稳定性/故障应急等团队。

挑战

Oncall问题具有显著的多样性，不同类型的问题需由不同专业背景的人员进行处理。例如，系统故障需要产研&SRE迅速定位并修复，以减少服务中断时间；客户投诉以及负面情绪则需要客户经理及时安抚客户并解决问题，进而提升客户满意度。进一步来说，Oncall问题还可进一步细分，例如判断其影响面大小、是否对业务有损等。

现有的基于特征工程的分析方法，对Oncall内容的语义理解能力也较为有限，在实际应用中难以准确识别关键问题，致使重要Oncall无法及时升级处理。此外，Oncall的严重程度也可能在对话过程中被（动态地）逐步澄清，而一些现有方法仅进行一次性分类，忽略了对话中不断更新的信息，无法在线及时识别到需要升级的情况。

此外，挖掘Oncall之间的关系同样重要。当一个问题影响多个客户时，会产生多个相似的Oncall。如果能及时捕获分析这些Oncall之间的关系，有助于更全面地评估问题的严重性与影响范围，而对于产研来说，可以合并这些Oncall共同处理，从而更加聚焦地解决问题。

得益于大语言模型（LLM）在自然语言理解方面的强大能力，我们将其用于辅助理解Oncall中的文本信息，但是简单使用LLM并不能真正有效的解决上述挑战。在本文中，我们提出了基于 LLM 的 Oncall 分析方法 —— TickIt，该方法可以动态追踪Oncall中的信息，还能借助LLM深入理解 Oncall 对话的语义内容，及时识别严重问题并升级。同时，TickIt 还能挖掘不同 Oncall 问题现象之间的语义关联，识别潜在的共性问题，实现更高效的问题处理。

TickIt 的方法设计

TickIt 使用了字节的豆包（doubao）模型，旨在借助大语言模型（LLM）强大的自然语言处理能力，实现高效、准确的Oncall升级任务。该框架主要包含基于多分类的Oncall升级（Multi-class escalation）、重复Oncall分析(Escalation deduplication)和基于类别引导的微调（Category-guided fine-tuning）这三个核心功能模块。

基于多分类的Oncall升级

在Oncall升级功能中，TickIt 将Oncall升级问题视作多分类任务。依据产研&SRE&客户关系的不同职责和关注重点，预先定义了系统故障、客户投诉、资产损失等多种主题类别。而对于普通Oncall，统一归为 “其他” 类别（无需升级处理）。为使大语言模型更好地完成Oncall多分类任务，TickIt 也在System Prompt中采用了一些技术来提升其分类表现，例如赋予其任务角色、思维链（COT）等。例如，在判断一个Oncall是否属于系统故障时，模型会分析对话内容中提到的故障现象、影响范围等因素，并逐步解释做出该分类决策的原因。这种方式增强了分类结果的逻辑性和可解释性，让人们更易理解和信任模型的判断。此外，TickIt 通过Few-shot learning，辅助模型理解不同的Oncall类别。这些示例特别对易混淆的场景进行了举例示范，从而帮助模型更准确地区分各类Oncall的特征。

TickIt采用在升级任务中所采用的System Prompt格式如下图所示

重复Oncall分析

重复Oncall分析是 TickIt 的另一个功能。当一个Oncall被判定需要升级时，TickIt 会对所有处于“Pending”状态的Oncall进行检查，以确定是否有类似问题已被升级。为此，TickIt 将Oncall在其生命周期中的状态抽象为有限状态机。当客户提交Oncall工单并被接受后，该Oncall对象进入 “Active” 状态。每当Oncall中有新的对话内容时，最新的对话记录会触发 TickIt 启动新一轮分析，此时将其设置为进入 “Analyzing” 状态。TickIt 会运用上述的基于多分类的升级方法，判断当前Oncall是否需要升级。如果被分类为 “其他”，则其状态返回 “Active”，等待下一轮对话交互；若被分类为预设好的严重问题类型中，则进入 “Pending” 状态，此时TickIt会检查是否有相似的Oncall已经被升级。

在判断Oncall是否重复时，TickIt 首先利用大语言模型提取Oncall中的问题描述，并借助doubao-embedding model将这些问题描述转化为向量表示。通过consine similarity来计算向量之间的相似度，并通过一个阈值参数 ? 来判断当前Oncall与已升级的Oncall是否相似（?通过参数选择实验确认，在本方法中?=0.88）。对于TicketIt判定当前需要升级的Oncall，如果历史已有升级且相似的Oncall，则会将当前Oncall与对应的历史Oncall进行关联，并不再重复告警（仅在关联工单中体现）。同时，TickIt 会将当前Oncall与已重复会利用大语言模型重写问题描述，从语义上更全面地归纳该类问题的共性特征，避免因个别Oncall工单描述的局限性而导致对问题的理解偏差。

基于类别引导的微调

类别引导的微调是 TickIt 不断优化准确率的关键机制。当一个Oncall按照上述的流程被升级后，TickIt 会发送包含Oncall问题摘要的提醒通知卡片。通知卡片中有三个交互按钮，其中两个分别用于点赞或点踩；第三个按钮则是一个Oncall跳转链接，点击后可直接跳转到相关的聊天群中。TickIt则会记录下这些通知卡片的交互行为作为自动升级的反馈数据。

在处理这些反馈数据时，TickIt 采用监督微调（SFT）方法，一条典型的SFT数据同时包含“对话内容”（Oncall原始信息），“LLM 思考过程与类别判断”（LLM的输出）。并按照TickIt 用于Oncall升级任务的System Prompt来进行组织成数据集。

我们对四种反馈动作设置了不同的优先级，以避免同一Oncall下存在冲突的反馈。其中直接反馈（点赞、点踩）都会被纳入SFT的数据集中。根据我们的观察，相较于正面反馈（点赞）人们通常会在Oncall升级错误时更倾向提供一些负面反馈（点踩）。因此，点赞的数量要远小于点踩，也正是出于此原因，我们将点赞的优先级设置为最高（至少有一个人认为该告警是有帮助的）。而对于点踩的反馈来说，通常是认为误告警，因此则将其目标类别设置为“其它”（如无指定类别说明）。在该情况下，由于仅仅知道目标类别，而缺乏COT所需要的推理步骤，TickIt则利用大语言模型完成目标分类下思维链步骤的补充。考虑到思维步骤的多样性，TickIt 会对每个Oncall进行三次可能思维链步骤的采样，以丰富数据集。

通过这种方式，TickIt 能够处理用户反馈，并基于类别引导进行数据增强，最终构建出一个高质量的标注数据集。当积累了足够数量的标注数据后，TickIt 会运用 SFT 方法对模型进行离线优化，然后更新在线模型，从而不断提升模型在升级分类任务上的性能表现。

TickIt 的实验验证

TickIt 在火山引擎的线上进行了全面部署，并取得了显著成效。在此期间，TickIt 共处理了数以万计的Oncall。在收到的反馈中，约 81% 的反馈表明 TickIt 的升级决策是准确的，这也证明了 TickIt 在实际应用中的有效性和可靠性。

在进一步的Oncall升级性能评估方面，我们还对比了基于小语言模型（SLM）和大语言模型（LLM）的多种方法。小语言模型受限于参数规模，其语言理解能力相较 LLM 有较大差距，且部分非端到端的方法设计在信息传递过程中易出现信息丢失的情况。而基于 LLM 的方法则展现出了良好的准确率。我们通过消融实验验证了不同框架设计对模型性能的影。使用CoT的 LLM 方法，准确率和召回率均能达到 82% 左右。在此基础上，结合反思（Reflection）提示，模型能够对自身的推理和输出进行自我纠正，精度略微提升至 82.8%。但由于 CoT 提示已经使模型在得出结论前进行了充分的推理，在反思阶段模型难以获取新的关键信息来进一步提高输出的准确性和洞察力，因此反思技术对实验结果的提升效果并不显著。引入上下文学习（ICL）提示后，模型的召回率大幅提升至 89.2%，尽管精度略有下降，但这一结果充分体现了 LLM 方法强大的泛化能力。

在不同方法设计下的Oncall升级比较

进一步对 LLM 进行监督微调（SFT）后，模型性能得到了显著提升。以 CoT 提示为例，微调后的召回率从 82.1% 大幅提高到 91.2%，同时保持了 81.8% 的较高精度，F1 分数达到了 86.2%，在所有对比方法中表现最佳。这一结果有力地证明了 SFT 在利用 LLM 能力提升Oncall升级任务性能方面的有效性。然而，当 SFT 与其他基于提示的方法（如 Reflection 和 ICL）结合时，性能出现了轻微下降。这可能是因为 SFT 过程中使用了 ICL 中的一些样本或与训练数据分布相似的数据，使得模型在离线微调时已经学习了相应内容，从而在结合使用时产生了一定的冲突。

在重复Oncall分析的实验中，通过调整相似度阈值来探寻最合适的参数，该参数在 0.86 - 0.95 之间时，F1 分数会随着参数的升高先上升后下降。当其设置过高时，严格的相似度约束可能会导致相似问题被错误分类到不同类别，使得评估结果中升级Oncall的数量相较于真实情况出现偏差，且该偏差与阈值并非单调关系。此外，基于问题现象的去重方法本身存在一定局限性，对于表现相同但根因不同的Oncall，可能会出现错误去重的情况。而在针对Oncall问题重写的设计中，我们也进行了消融实验。实验结果表明，开启重写功能的 TickIt 相较于未开启该功能的实验设置来说，F1 分数提升了 1.7%。进一步对数据集进行分析，仅保留包含多个关联Oncall的升级进行实验，结果显示TickIt中的重写设计使得其F1 分数从 0.706 提升至 0.749，提升幅度达到 6.1%。

重复Oncall识别下的参数选择实验

Ticket在重复Oncall识别下的问题重写消融实验

总结与局限性分析

TickIt 借助大语言模型实现了高效的自动化Oncall升级，为火山引擎带来了显著的效率提升。它从“帮助人们及时介入严重Oncall”的角度，帮助火山引擎缩短了严重问题的响应时间，使得整体的MTTR降低了约26%，并节约了人力投入成本。同时，TickIt 也得到了使用者的广泛认可。

然而，TickIt 在实际应用中也暴露出一些局限性。对话中（个性化的）表达方式可能会对大语言模型的判断产生影响。例如，部分使用者可能会夸大问题的影响，导致不必要的升级；而有人也可能对严重问题描述过于平淡，使得 TickIt 未能及时识别出需要升级的情况。此外，如果Oncall所关联的云服务产品不够具体，相似的问题描述可能会因涉及不同的云服务产品而具有不同的严重程度，这容易导致大语言模型的误判，进而出现错误的升级。我们在后续的工作中会进一步优化TickIt的实际效果，助力火山引擎的稳定性工作。