这项由蚂蚁集团与上海交通大学联合完成的研究，以预印本形式发布于2026年4月，论文编号为arXiv:2604.21889，感兴趣的读者可通过该编号查询完整论文。
每隔一段时间，你可能会遇到这样的经历：打开支付宝准备付款，转圈转了好几秒，然后弹出一个"支付失败"。你有点烦躁，把这个情况反馈给了客服。但你不知道的是，此刻全国可能有成千上万个人正在经历同样的事情，而在某个机房里，一场悄悄蔓延的系统故障正在酝酿更大的麻烦。
问题的关键在于：这些散落在各处的用户抱怨，能不能被及时汇聚成一个"故障警报"，让工程师在事态扩大之前介入？这恰恰是这篇论文所解决的核心难题，而研究团队给出的答案，是一套名为TingIS（听智服务）的实时风险事件发现系统。
研究团队特别举了一个发生在现实中的案例作为开场白。2025年1月，支付宝曾因配置错误，将一项国家补贴的20%折扣错误地应用到了所有交易上。支付宝每年的交易规模约为20万亿美元，哪怕这个错误只持续了5分钟，估算损失就高达4000万美元。这个例子说明，对于大型金融科技平台而言，发现故障的速度，以分钟计算，直接关系到真实的财务损失。
---
一、用户的抱怨，为什么比机器监控更重要
现代大型系统通常装备了大量内部监控工具，就像给一座大楼装满了烟雾报警器、温度传感器和摄像头。这些工具监测指标、分析日志、追踪请求链路，是系统健康的第一道防线。然而，这套防线并非无懈可击。有些故障藏在监控系统的"盲区"里，比如某个业务逻辑错误，从技术指标上看一切正常，但用户就是无法完成支付，或者优惠券无法使用。
这时候，用户的投诉和反馈就成为了最后一道防线，也是最直接反映用户体验的信号。用户不会按照技术文档写投诉，他们只会说"我付不了钱，一直转圈"或者"怎么显示失败啊，网络明明很好"。这些来自普通人的、口语化的抱怨，其实蕴含着系统故障的真实信号。
但困难就在这里。一个日均处理几十万条用户反馈的平台，这些反馈就像一条滚滚河流，里面混杂着真正有价值的故障信号，也混杂着大量的无效噪音——有人问信用额度，有人反映业务纠纷，有人纯粹在发泄情绪。研究团队面对的挑战，用他们自己的话说，是在每分钟2000条消息的洪流中，从仅仅3条相似的用户描述里，准确识别出一个正在发生的系统故障。这不是一件容易的事。
---
二、系统的核心目标：把"抱怨"变成"警报"
在正式介绍技术之前，有必要先搞清楚两个核心概念，因为整个系统的设计都是围绕这两者之间的转换来展开的。
第一个概念叫"客户事件"，指的是每一条用户反馈的原始记录，比如一条投诉日志。它的特点是嘈杂、口语化、主观性强。第二个概念叫"风险事件"，指的是一个被结构化表示的系统漏洞或故障，它有唯一的身份标识，由业务归属（即属于哪个业务线）和问题主题共同定义，而且是会随时间演变的——它有当前的投诉量，有紧急程度，有处理状态。
TingIS的目标，就是将滚滚而来的客户事件，正确地归并到对应的风险事件上，或者识别出这是一条噪音该丢弃，或者判断这是一个全新的风险信号该创建新的风险事件来追踪它。
这个任务之所以难，在于一个"语义鸿沟"的问题。用户说"我的小宠物不睡觉了"和"睡眠按钮没反应"以及"游戏卡在加载界面"，这三句话字面上看起来毫无关联，但它们实际上都在描述同一个系统更新导致的虚拟宠物功能故障。如果系统不理解这些句子背后的含义，就会把它们当成三件小事分散处理，无法触发高优先级的故障警报。
---
三、TingIS的整体架构：一条流水线上的五个"关卡"
整个TingIS系统被设计成三个层次、五个模块的流水线。三个层次分别是数据观测层（接收原始投诉流）、语义智能引擎（处理和理解文本）、以及长期知识记忆（存储历史事件和各类知识库）。五个模块则像流水线上的五个工位，每条投诉依次经过它们的处理。
研究团队在设计这个系统时，始终遵循三个核心原则。其一是"语义收敛与身份持久"，意思是同一个根因引发的不同投诉，最终必须被汇聚到同一个风险事件的名下，而这个事件的身份必须稳定持久，不会随时间而消失。其二是"混合智能的协同"，这是整个系统最精妙的设计哲学——大型语言模型（LLM，可以理解为当下最强大的AI文字理解工具）虽然理解能力强，但调用一次成本不低；而简单的规则筛选和向量检索虽然浅薄，但速度极快。好的系统设计应该让简单的工具先做大量初步过滤，只把真正需要深度思考的问题交给LLM来判断，而不是对每条投诉都大动干戈。其三是"多约束的信噪比平衡"，也就是说，光靠一种方法去噪是不够的，要从知识库匹配、统计基线、行为约束等多个维度综合抑制误报。
---
四、第一关：语义蒸馏——把"用户语言"翻译成"机器能懂的摘要"
用户的原始投诉往往充满了感情色彩、冗余信息和个人隐私，比如"天啊我都付了好几次了还是失败，我银行卡余额明明够的，你们系统是不是有问题啊！！！"。直接把这句话拿去分析，既低效又容易误导后续处理。
第一个模块的任务，就是把这种原始投诉"蒸馏"成一句干净的技术摘要。系统调用了一个叫Qwen3-8B的轻量级语言模型，要求它按照严格的格式生成摘要：必须遵循"主语+问题"的结构，比如"信用卡网络支付+折扣错误"，并且必须忽略情绪表达、闲聊内容和个人隐私信息。这种设计用较低的计算成本，创造了一个高质量的语义表示。
生成摘要之后，系统还会用另一个工具（BGE-M3嵌入模型）把这段文字转换成一串数字向量，可以理解为给每句话生成一个"语义坐标"，语义相近的句子会有相近的坐标。这个向量坐标将作为后续所有操作的基础。
---
五、第二关：级联路由——先判断"这是谁家的事"
处理完文字，系统接下来要解决一个关键问题：这条投诉应该归属到哪个业务线？一家大型金融科技平台有数十个甚至更多的业务线，保险、信贷、基金、支付、商户服务……每个业务线背后都有对应的应急响应团队。如果把一条"基金赎回失败"的投诉发到了"保险理赔"团队，不仅浪费时间，还会耽误故障处理。
路由模块采用了一个两段式的瀑布策略，就像海关的两道安检。第一道是关键词匹配，系统维护了一个关键词知识库，如果投诉摘要里出现了特定的实体关键词，就直接命中对应的业务代码，立即返回结果，既快又准，适合处理那些描述清晰的高频投诉。
对于那些没有命中关键词的投诉，系统进入第二道：语义检索。这时候，系统会同时在多个向量知识库里检索相似的历史案例，获取候选结果后，再调用一个叫BGE-Reranker-V2-M3的精排模型对候选结果重新打分排序。精排模型的优点是准确，但比较耗时，所以系统只让它处理检索出的前10个候选，这个设计将计算量控制在了合理范围内。通过精排筛选的投诉被分配到对应业务线，而置信度太低的投诉则进入一个兜底队列，由人工运营团队手动分拨。
实验数据证明了"瀑布式"设计的优越性。将关键词和向量检索并行融合的方案，准确率只有0.460；而瀑布式级联方案的准确率达到了0.669，同时处理时间也从220秒缩短到了54秒。此外，精排模型扮演的角色不仅仅是提高准确率，它还充当了一个"质量门卫"，主动拒绝那些置信度不足的预测，将覆盖率维持在88%左右，而不是强行给每条投诉都打一个标签。进一步的实验发现，当知识库只有60%完整时，精排模型的价值体现得更加明显——它在不确定的情况下，有勇气说"我不确定"，而不是强行猜一个。
---
六、第三关：事件关联引擎——判断"这条投诉和已有故障是不是同一件事"
这是整个系统最核心、最复杂的部分，也是TingIS区别于普通投诉管理系统的关键所在。它的任务是回答一个本质性的问题：这些来自不同时间、用不同方式描述的投诉，到底是不是在说同一个故障？
这个引擎分为两个阶段。第一个阶段处理"批内聚合"，也就是在同一批同时到达的投诉里找出相似的群体。系统先按照业务归属把投诉分组，然后在每个业务组内使用一种叫"局部敏感哈希"（LSH）的技术做快速的粗略聚类——这种方法的原理类似于把相似的书放到相邻的书架上，速度很快但精度有限。粗略聚类完成后，系统调用一个更强大的语言模型（Kimi-K2）对每个聚类做"代表性检查"：这堆投诉真的在说同一件事吗？如果不纯，就让模型把它拆分成更小的、真正同质的子类，并为每个子类生成一个简洁的标题。
第二个阶段处理"跨批历史关联"，也就是判断新聚类出来的投诉群体，与之前已经存在的历史风险事件是不是同一个问题。系统把新聚类的标题转换成向量坐标，然后去历史风险事件知识库里检索相似的历史事件。在打分时，系统还引入了一个"时间衰减机制"：时间越久远的历史事件，相似度得分会按照公式 s*=s·e^(-k·Δt) 自动打折，其中Δt代表距离上次活跃的天数。这是为了防止一个已经修复多时的老故障，把新出现的、完全不相关的投诉错误地吸引过来。如果最高得分超过了预设阈值，系统才会进一步调用LLM做最终裁决：合并到旧事件，还是创建新事件？并且要求模型给出自然语言的理由，方便人工审核。
实验对比数据非常有说服力。传统的DBSCAN聚类算法（一种常用的自动聚类方法）在这项任务上的"误合并率"高达64.3%，意味着差不多三分之二的情况下，它会把两个不同的故障混在一起，给工程师指错方向。TingIS将这个误合并率降低到了21.5%，同时B?-F1综合分数达到0.826，显著优于所有对比方法。研究团队特别强调，误合并是一种"灾难性"错误，因为它会导致工程师在错误的方向上排查根因，浪费大量时间；而轻微的"碎片化"（同一个故障被分成两个事件追踪）虽然也不理想，但只是造成重复工作，后果要轻得多。
消融实验进一步拆解了各个组件的贡献。移除"业务分组"这个看似简单的操作，B?-F1得分直接下降15.6%，误合并率从21.5%飙升到55.2%。这印证了一个核心洞察：在企业级应用场景里，不同业务线的用户可能使用完全相同的口语词汇描述完全不同的问题（比如"失败了"这个词在保险领域和支付领域背后是完全不同的技术问题），纯粹依赖语义相似度的聚类方法必然会在这里碰壁，注入确定性的业务元数据是防止"语义塌方"的必要防火墙。
---
七、第四关：状态管理——给每个风险事件建立"档案"
当一个风险事件被识别出来后，系统需要跟踪它的生命周期，就像医院给每个病人建立的病历档案。研究团队设计了一个三层的数据模型。
第一层是状态层，存储风险事件最核心的实时数据：当前的投诉量是多少，最近一次被更新的时间，最近一次有新投诉关联进来的时间。这些数据用于驱动实时告警和时间衰减计算。
第二层是审计层，记录每一条投诉从原始文本到最终被归并到哪个风险事件的完整证据链：原始文本→摘要→聚类→事件ID。同时还记录每次触发告警时的上下文，是因为绝对量超过阈值，还是因为动态基线偏差触发的？这层数据确保系统100%可追溯，出了问题可以复盘每一个决策节点。
第三层是快照层，定期记录风险事件的投诉量时序数据，为动态基线的计算提供历史样本。这个设计的精明之处在于：如果要计算统计基线，每次都重新扫描历史日志代价极高，而定期保存快照，则可以以极低的存储成本获得稳定的统计数据。
---
八、第五关：多维降噪——在拉响警报前再过一道筛
即使一个风险事件的投诉量确实很高，也不代表它一定是真正的系统故障。比如某个社会化营销活动上线，大量用户涌入查询"怎么查我的奖励进度"，这条投诉会形成一个高频聚类，但它不是故障，只是正常的业务波动。如果系统对此拉响警报，工程师会疲于奔命应对大量虚假警报，最终对告警系统麻痹，这就是所谓的"告警疲劳"。
TingIS的降噪模块分三个层次工作。第一层是源头抑制：在聚类阶段，系统会把新出现的聚类标题与一个"历史误报知识库"做相似度匹配，如果高度相似，直接压制，不再生成风险事件。第二层是统计过滤：投诉量不只需要超过一个静态的绝对量阈值，还必须显著偏离动态基线（也就是比过去同期水平高出两个标准差以上），两个条件同时满足才能通过。这个双重触发机制能有效过滤掉那些随着业务周期性波动而产生的高峰。第三层是行为约束：一旦某个风险事件被标记为"处理中"，系统会自动关闭一个两小时的静默窗口，在此期间不再重复推送告警，避免轰炸响应人员。但与此同时，系统会持续监控投诉量的增长斜率，如果发现非线性的爆发式增长，系统会直接穿透静默窗口，强行推送紧急升级告警。
这五个模块协同工作的效果非常显著。在实验的告警回放测试中，没有降噪模块的版本触发了512次告警，而完整版的TingIS只触发了29次告警，噪音降低了94.3%，同时对高优先级故障的发现率没有任何下降。每个故障事件平均对应的告警次数也从2.18降低到了1.23，最接近理想状态的1.0。
---
九、系统性能：在真实的炮火中经受检验
这套系统不只是在实验室里跑通了，而是真正部署在了一个头部金融科技平台的生产环境中，每天处理超过30万条用户投诉，峰值处理速度超过每分钟2000条。经过一个月的实际运行验证，系统对高优先级故障事件的发现率达到了95%，P90告警延迟为3.5分钟，也就是说90%的故障在3.5分钟内就能收到告警。
从计算效率的角度看，整个端到端处理的平均延迟约为12.4秒一个批次。延迟的构成很有意思：三次LLM调用（摘要生成、批内聚类审核、最终裁决）累计耗时8.53秒，占总延迟的69.7%，是主要瓶颈。向量检索、关键词匹配、数据库操作等非LLM操作合计只需要2.1秒，效率极高。
在token消耗方面，系统每天总计消耗约800万个token，折算下来每产生一个有效的高置信度告警，需要消耗约27.5万个token。这个数字看起来很大，但要注意它包含了处理所有非告警投诉的全部成本——真正触发告警的只是极小一部分，但为了找到它们，系统必须处理全量的投诉流。研究团队还披露了多项降低成本的设计决策，其中规则预过滤将原始的25万条日投诉量压缩到了约5万条，减少了80%的下游LLM负担；固定批次大小（200条一批）避免了流量峰谷时的资源浪费和API限流风险；而当某个聚类与历史事件的相似度分数超过0.95时，系统直接跳过最终的LLM裁决步骤，在稳定运行期间有超过70%的历史匹配请求得以绕过这一步，进一步节省了约3/8的总token消耗。
---
十、经验与教训：从真实部署中摸爬滚打得来的智慧
论文的最后几个章节展示了研究团队在真实部署中积累的工程经验，这部分内容对于任何需要构建类似系统的人来说都极具参考价值。
关于数据预处理，团队发现用户投诉的分布极度倾斜——73%的投诉集中在8个高频业务领域，超过一半的投诉是低信息量内容。设计了6条可配置的过滤规则（长度阈值、前缀加长度模式、关键词逻辑组合等），但重要的是，每条规则都必须用历史故障日志反复验证，确保对高优先级故障的召回率零损失，而不是靠拍脑袋设定阈值。
关于批处理策略，按时间窗口切割批次的方案在流量极不稳定的场景下会引发双重故障：流量高峰时批次过大导致内存溢出，流量低谷时资源严重浪费。最终选择了固定批次大小（200条）的方案，以确定的计算负载换来稳定的系统行为。
关于关键词设计，关键词库里的每个关键词都必须具备跨业务域的区分能力。举例来说，"账户查询"和"交易失败"这两类词虽然在用户口中可能混用，但在系统里必须被精心设计以区分不同业务域。同时，路由知识库需要持续维护，通过运营团队核实的误判案例触发定向的增量更新，不能"建好就放那儿不管了"。
关于语言模型的价值定位，纯向量嵌入聚类有一个根本性的结构缺陷：它过度关注"问题"词汇（比如"失败"），而忽略了"主语"词汇（比如是"营销活动的奖励"失败，还是"NFC支付功能"失败）。研究团队举了一个具体的反例：营销活动奖励兑换失败与NFC支付功能奖励使用失败，向量相似度很高，但根因完全不同，一个在营销逻辑，一个在支付管道。LLM生成的"主语+问题"结构化摘要，是弥合口语化描述和技术根因之间鸿沟的关键。
---
说到底，TingIS解决的问题可以用一句话概括：让机器学会把用户的抱怨，翻译成工程师能立刻行动的故障警报。它的精妙之处不在于某一项单独的技术有多先进，而在于整个流水线的协同设计——每个模块各司其职，大模型只在最需要它的地方出现，轻量级工具承担了绝大部分的信息过滤工作，最终在每天30万条嘈杂投诉中，以3.5分钟的响应速度捕获了95%的高优先级故障。
这项研究对于任何运营大规模在线服务的团队都有相当直接的参考价值，无论是互联网平台、金融科技公司，还是各类云原生服务的运营者。它也揭示了一个普遍的工程规律：在实际生产环境中，系统的价值不只来自算法的精妙，更来自对数据分布特性、资源约束和人机协作边界的深入理解和精心设计。
对这项研究感兴趣的读者，可以通过arXiv编号2604.21889找到完整的论文原文，其中的附录部分包含了详细的模块流程图、案例研究和工程经验，对于希望复现或借鉴这套方案的工程师来说尤其有用。
---
Q&A
Q1：TingIS系统如何在海量投诉中识别真正的系统故障？
A：TingIS通过五个串联模块来完成这个任务。首先用语言模型把用户的口语化投诉"翻译"成标准化的"主语+问题"摘要，然后按照业务归属分流，再用局部敏感哈希做快速粗聚类，由更强大的语言模型做精细化的语义审核，最后结合历史事件知识库和时间衰减机制判断是否是新故障。全程只在真正需要深度理解时才调用大语言模型，大幅控制了计算成本。
Q2：TingIS的误合并率为什么比传统聚类算法低这么多？
A：传统聚类算法（如DBSCAN）只看文本的语义相似度，很容易把"营销活动奖励失败"和"NFC支付奖励失败"混为一谈，因为两者用词高度相似但根因完全不同。TingIS的关键改进有两点：一是引入业务分组这道"防火墙"，确保不同业务域的投诉不会跨域合并；二是通过语言模型生成结构化摘要，强制区分"主语"和"问题"，避免被相似的问题词汇误导。实验中DBSCAN的误合并率高达64.3%，TingIS降低到了21.5%。
Q3：TingIS的动态基线告警机制和普通的阈值告警有什么区别？
A：普通的阈值告警是静态的，比如投诉量超过100条就告警。问题在于，某些业务节点（如营销活动日）本来就会有高峰投诉，静态阈值会产生大量误报。TingIS的动态基线机制要求投诉量不只超过绝对阈值，还必须比同期历史水平高出两个标准差以上，两个条件同时满足才触发告警。这就像判断一个城市是否"异常堵车"，不只看当前车辆数量，还要和同一时段的历史平均水平比较，这样才能过滤掉节假日本来就会有的正常拥堵。