TingIS：面向企业级噪声客户工单的实时风险事件发现系统 TingIS: Real-time Risk Event Discovery from Noisy Customer Incidents at Enterprise Scale
蚂蚁集团端到端风险情报系统，融合LLM与高效索引从嘈杂工单流中实时发现风险事件。
前置知识
Locality-Sensitive Hashing (LSH)
局部敏感哈希是一类把相似向量高概率映射到同一桶的哈希族，常用 MinHash 做 Jaccard 相似、随机投影做余弦相似。它允许亚线性时间内近似最近邻搜索，常被用作大规模聚类的粗筛阶段。
TingIS 的 M3 模块用 LSH 对同一业务域内的事件流做高速粗聚类，把候选集先压缩到可控规模再交给 LLM 审核，是控制 LLM 调用成本的关键前置环节。
B3-F1 聚类评价指标
B-Cubed 是为聚类设计的指标,逐样本计算 precision=|C(i)∩L(i)|/|C(i)| 与 recall=|C(i)∩L(i)|/|L(i)|,再求平均后取 F1,避免类标任意性带来的匹配问题。Mismerge 与 Fragmentation 率由 B3-P/R 直接推导。
论文所有聚类对比都用 B3-F1，能同时反映「不该合并的合并了」和「该合并的没合并」两种工业错误，是评估风险事件去重质量的核心指标。
Cross-encoder Reranker
交叉编码器把 query 与 doc 拼接后过 Transformer 做全自注意力联合打分，比双塔向量检索更准但代价高无法预计算，常作为 top-K 后的精排器。文中用 BGE-Reranker-V2-M3。
M2 级联路由的最后一环靠 reranker 做「质量门卫」，拒绝低置信候选，决定 88.1% 的覆盖率，是路由准确性的关键。
时间衰减加权
对历史事件与当前候选用形如 $s^*=s \cdot e^{-k\Delta t}$ 的乘积打分，让时间越久的事件对当前合并决策的贡献越小，抑制「历史惯性」造成的错误归并。
这是 M3 跨批次关联的核心公式，>70% 的稳态匹配因为 s*>0.95 被绕过 LLM 直接采纳，是 TingIS 控制 Kimi-K2 token 消耗的关键工程设计。
信噪比 (SNR) 与告警疲劳
信噪比衡量有效事件数与无效事件数之比。SNR 低意味着系统产生大量假阳性，SRE 团队会被「告警风暴」淹没而对真正告警脱敏，反而掩盖严重故障。
TingIS 95% 发现率背后的真正痛点不是召回，而是同时压低误报；M5 多维降噪就是围绕 SNR 做工程优化。
研究动机
大型云原生平台即便有指标、日志、追踪三层可观测性,仍存在监控盲区,客户反馈与热线工单作为唯一暴露盲区的信号,成为风险发现的核心来源。但这条信号极难处理:蚂蚁集团 Alipay 这样的平台日均处理 300,000 条工单、峰值 2,000 条/分钟,且要求只凭 3 条碎片化描述就能发现系统性故障。文中举例 2025 年 1 月 Alipay 因配置错误对所有交易误打 8 折,按 $20 万亿年交易额估算 5 分钟内损失约 4000 万美元。工单本身又口语化、噪声大、跨业务线,例如「不能支付,一直在转圈」、「支付失败,网没问题」、「(噪声)我的额度是多少」混在同一流里,系统若 SNR 不达标,几分钟内就会产生数千条误报,把 SRE 团队淹没导致告警疲劳。现有方法要么只做关键词匹配(覆盖率低),要么做无监督聚类(误合并率高),要么把 LLM 直接喂原始流(token 成本爆炸),都无法满足企业级实时性、准确性、成本三重要求。
本文的目标是论文目标是在不牺牲高优先级召回的前提下,把 SNR 提升一个数量级。具体可衡量的目标包括:对一个月线上运行而言高优先级事件发现率达到 95% 以上、P90 告警延迟控制在 5 分钟内(实际达到 3.5 分钟)、误报量级压缩到 1% 以下(原始 512 条降到 29 条)、每条 actionable 告警的端到端 token 成本控制在可承受量级(实测约 275K tokens/alert、合计 8.0M tokens/day),并使系统能峰值扛住 2,000 条/分钟、稳态 300,000 条/天的吞吐。
与已有工作不同的是，TingIS 的独特切入角度是「混合智能 + 持久事件身份」。它不把 LLM 当作万能聚类器,而是按三层正交洞察设计:语义收敛与身份持久(同一根因的工单稳定映射到唯一持久的 Event-ID)、高效混合智能(规则前置剪枝、LSH 粗聚类、阈值门控,只在最有价值环节调用 LLM)、多约束 SNR 平衡(融合知识库、统计基线、行为门控的级联降噪)。已有方法如 DBSCAN 的误合并率高达 64.3%、单纯向量匹配无事件身份、单纯 LLM 聚类成本不可控;TingIS 在 M3 模块用「域内 LSH→LLM 审计→跨批时序关联→LLM 终审」四步流水线,同时用 M2 级联路由把不同业务域隔离开(业务域误合并率从无隔离的 64.3% 降到 21.5%,B3-F1 从 0.673 升到 0.826),真正补上「工业级实时 + 高 SNR + 可控成本」这一空白。
核心方法
TingIS 是面向客户工单流的事件级风险发现系统,整体采用「数据观测层 → 语义智能引擎 → 长期知识记忆」三层架构,把流水线拆成五个可插拔模块 M1–M5。直觉上可以把它想象成一条流水线工厂:工单进来先在 M1 被 Qwen3-8B 蒸馏成「主体+问题」标准格式,等价于给每条投诉做规范化翻译;M2 用级联路由(关键词→向量→reranker)把工单按业务域隔离投递,避免「支付失败」被错分到保险业务组;M3 是核心,先按业务域做 LSH 粗聚类,再用 Kimi-K2 做语义审计/拆分,再用时间衰减 $s^*=s \cdot e^{-k\Delta t}$ 跨批检索历史 Event-ID,最终由 LLM 判决合并还是新建;M4 维护「状态/审计/快照」三层数据,既支撑实时告警也支撑基线计算;M5 用误报知识库匹配、动态基线 $(\mu+2\sigma)$、告警静默+斜率穿透三种机制压 SNR。整套设计的灵魂是「LLM 越精准但越贵,要让 LLM 只在最有价值的那 1% 决策上发言」。
与已有方法的本质区别在于三点:(1)「业务域作为不可协商的防火墙」——很多纯语义聚类(DBSCAN/向量匹配)在跨域共用词汇时会灾难性误合并,例如把营销奖励兑换失败和 NFC 支付功能奖励失败归到一起,TingIS 用 biz_code 硬约束加 LLM 审计,消融实验表明去掉业务域划分后 B3-F1 下降 15.6%、误合并率飙升 157%;(2)「持久事件身份」——把每条工单链到有状态的 Event-ID 而非瞬时 cluster,使得历史降噪、跨批关联、抑制重复告警都成为可能;(3)「架构决定成本」——固定大小批处理(batch=200)稳定 LLM 调用率,s*>0.95 阈值绕过 >70% 历史匹配,LSH 粗聚类把 LLM 候选集从全流压缩到约 30,000 簇/天,日 token 总量控制在 8.0M 的工业可承受范围。这三点合在一起,才让「95% 召回 + 3.5 分钟 P90 + 94.3% 噪声下降」同时成立。
方法步骤详情
流水线按 M1→M2→M3→M4→M5 顺序,每步伴随 LLM 阈值门控。步骤一 M1 语义蒸馏:Qwen3-8B 在严格 prompt 约束下生成「主体+问题」摘要(如「信用卡在线支付+折扣异常」),丢弃情绪、PII、客套话,后接 BGE-M3 向量化。步骤二 M2 级联路由:关键词库命中即返回 biz_code;未命中则并行向量检索多库,BGE-Reranker-V2-M3 在 Top-10 内精排,拒绝者入 fallback 域。步骤三 M3.1 批内聚合:按 biz_code 分区,每区内 LSH 粗聚类,再用 Kimi-K2 做代表性检查,不纯则拆并起名。步骤四 M3.2 跨批关联:cluster title 嵌入后检索 Risk Event KB,用 $s^*=s \cdot e^{-k\Delta t}$ 综合语义与时间,超阈值由 LLM 终审,否则直接新建 Event-ID。步骤五 M4 写入三层数据:可变状态、不可变审计、周期快照。步骤六 M5 多维降噪:误报 KB 抑制、$(\mu+2\sigma)$ 动态基线过滤、「告警静默 2 小时 + 斜率穿透」避免告警疲劳。
技术新颖性
技术新颖性主要体现在三处工程创新。第一,把 LSH 的高效性与 LLM 的语义深度用「粗筛→审计→精排」三段式耦合,而非端到端 LLM 聚类,使 LLM 调用量从全流下降到约 30,000 簇/天;第二,时间衰减权重 $s^*=s \cdot e^{-k\Delta t}$ 与 LLM 自然语言判决结合,既防止「历史惯性」又给 SRE 提供可读的合并依据;第三,级联架构本身的设计哲学——「架构压倒技术」(cascade Acc@1 0.669 vs fusion 0.460)、「reranker 作为风险控制器」(数据库退化时 reranker 价值凸显,从 80% DB 时的 0.669 涨到 60% DB 时仍能控住 coverage)、「业务域防火墙」(去掉后 B3-F1 暴跌 15.6%)——这些并非新算法但组合起来是工业 NLP 系统设计中少有的完整实践。论文还贡献了「规则过滤召回验证」、「固定批大小」、「阈值门控绕过 LLM」三条可迁移的工业经验。
实验结果
实验分系统级与模块级。系统级:一个月生产运行中 TingIS 达 95% 高优先级发现率、P90 告警延迟 3.5 分钟;离线 50K Alert Replay Set 上触发 29 条告警、Event-to-Alert Ratio 1.23(理想 1.0),去降噪膨胀到 512 条/2.18,噪声下降 94.3% 而召回无下降。M3 聚类:TingIS B3-F1 0.826、误合并 21.5%、碎片化 5.8%;DBSCAN 0.673/64.3%/5.0%、关键词分组 0.745/24.4%/16.1%,误合并较 DBSCAN 降 42.8 个百分点、碎片化仅多 0.8。M3 消融:去 M1 摘要 B3-F1 降 7.0%/误合并 +66.5%;去业务分区降 15.6%/误合并 +157%。M2 路由:级联 Acc@1 0.669 优于融合 0.460;无 reranker Acc@1 升到 0.705 但 coverage 100%,DB 退化到 60% 时 reranker 让 Acc@1 维持 0.534 验证长尾价值。效率:端到端 12.4 秒/批,LLM 8.53 秒占 69.7%;日 token 8.0M,每告警约 275K tokens。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 客户工单风险事件发现 (端到端系统行为) | Event-to-Alert Ratio (越接近 1.0 越好) + 总告警数 | TingIS Full: 29 alerts, ratio 1.23 | Keyword-based 215/1.85; Single-stage Matching 125/1.52; TingIS w/o Denoising 512/2.18 | 噪声告警相对无降噪版本下降 94.3% (512→29),比关键词基线告警数减少 86.5%,ratio 从最差 2.18 拉到最接近理想值 1.23 |
| 事件聚类质量 (M3 模块) | B3-F1 (越高越好) | 0.826 (误合并 21.5%, 碎片化 5.8%) | DBSCAN 0.673 (误合并 64.3%); 关键词分组 0.745; 向量匹配 0.744 | 相对最优基线(关键词分组)B3-F1 提升 +10.9% (0.745→0.826),相对 DBSCAN 提升 +22.7%; 误合并率从 DBSCAN 灾难性 64.3% 降至工业可接受 21.5% |
| 业务路由准确性 (M2 模块) | Acc@1 (越高越好) + Coverage | TingIS Cascade: Acc@1 0.669, Coverage 0.881, Latency 53.7s | Fusion 0.460/0.680/220.2s; Semantic-only 0.542/0.772/92.3s; Keyword-only 0.430/0.516/4.2s; w/o Reranker 0.705/1.000/99.2s | 级联架构相对融合架构 Acc@1 提升 +45.4% (0.460→0.669) 且延迟下降 75.6%; 在 DB 退化到 60% 时仍保持 Acc@1 0.534 vs w/o reranker 0.502,验证 reranker 长尾价值 |
| 在线生产指标 | 高优先级事件召回率 + P90 告警延迟 | Recall 95%, P90 latency 3.5 min | 未给出具体基线,但 95% 为 SRE 团队标注的高优先级事件 | 在日均 300K 工单、峰值 2,000/min 吞吐下,3.5 分钟 P90 远优于传统周期批处理 5–15 分钟的「黄金窗口」 |
| 聚类消融 (M1 + M3) | B3-F1 + 误合并率 | Full: B3-F1 0.826, 误合并 21.5% | w/o M1 摘要: 0.768/35.8%; w/o 业务分区: 0.697/55.2%; w/o 批内 LLM: 0.796/32.1%; w/o 终审 LLM: 0.815/23.9% | 业务分区为最大基石(-15.6% B3-F1),M1 主体+问题格式次之(-7.0%); LLM 调用累计贡献约 +5% B3-F1 与 -60% 误合并 |
| 降噪对召回保持 | 发现率不变情况下告警数压缩 | 95% 召回 + 29 alerts | TingIS w/o Denoising: 95% 召回 + 512 alerts | 告警量下降 94.3% 而召回保持,Event-to-Alert Ratio 从 2.18 降到 1.23 |
局限与改进
局限有以下几点:(1)误合并率 21.5% 工业上「可操作」但绝对值仍不低,DBSCAN 是 64.3% 但凡合并都错,TingIS 仍需人工偶发拆分,作为研究指标有下降空间。(2)12.4 秒端到端延迟中 69.7% 来自 LLM,论文未给出 10,000 条/分钟以上的极限压测,QPS 飙升时 P90 可能突破 5 分钟阈值。(3)离线 Benchmark Events 仅 12 个、Identity Set 约 1,400 条,样本规模偏小,聚类指标方差可能较大。(4)M5 动态基线 $(\mu+2\sigma)$ 假设业务量近似高斯,对营销活动爆发等重尾分布可能出现误抑制。(5)对比基线多为无 LLM 或弱 LLM 方法,未与 GPT-4/Claude 等强基座直接对比,难以判断「LLM 强还是架构强」。(6)代码虽开源但业务域知识库、误报 KB、动态基线都是 Alipay 私有,外部复现只能跑到通用架构层,真正工业级 SNR 难以复现。
独立分析的弱点
独立审视的弱点:(1)误合并率 21.5% 根源在于 M3.1 批内 LSH 在口语化多子域场景下仍会误归并,可引入对比学习 hard negative mining 或在 LLM 审计 prompt 中显式要求「业务子域判定」字段,目标压到 10% 以下。(2)12 个 Benchmark Events 太小,建议 Bootstrap 重采样并报告置信区间,同时扩到 50+ 真实事件。(3)动态基线 $(\mu+2\sigma)$ 在营销爆发日偏弱,可用 Prophet/LSTM 替代高斯假设并对节假日加先验。(4)M1 prompt 严格剥离 PII 可能误删真实业务上下文,需引入漏斗式 PII 检测器而非 prompt 规则。(5)级联路由 fallback 域需人工分单,论文未给 SLA 与覆盖率曲线,生产中可能成瓶颈。(6)8.0M tokens/day 看似可控,但 Qwen3-8B 与 Kimi-K2 均为外部 API,未设计多模型 fallback 的 SLA 与供应商锁定风险预案。
未来方向
作者暗示与可延伸方向:(1)Conclusion 提到「injecting more powerful LLMs」plug-and-play,可试 GPT-4o/Claude 4/Gemini 替代 Qwen3-8B 与 Kimi-K2,验证基座升级边际收益。(2)Appendix F 提到「Knowledge Requires Continuous Curation」,可引入主动学习让 SRE 反馈闭环驱动误报 KB 与关键词库自动更新。(3)M4 状态层只存 volume 与 timestamp,可扩展到「故障拓扑图」,把 Event-ID 与受影响微服务、上下游交易链路关联,直接生成 on-call 处置建议。(4)时间衰减 $s^*=s \cdot e^{-k\Delta t}$ 的 $k$ 是手工超参,可用强化学习按业务域自适应。(5)可迁移方向:把架构套到社交媒体客服、电商评论、医疗患者反馈等「高噪声+低基线」场景,验证 Event-ID 持久身份模型通用性。(6)探索多模态融合——工单文本与语音情绪、用户操作录屏截图同时输入,提升「隐性故障」(如 UI 卡顿)发现率。
复现评估
复现评估中等难度。代码已开源在 https://github.com/Geralt-Targaryen/CIIS,核心 M1 prompt、M3 LSH+LLM 流水线、M2 级联路由都有伪代码,可直接复用。但:(1)Alipay 业务数据非公开,只能用类似客服日志替代,生产指标(95% 召回、3.5 分钟 P90)无法外部重现。(2)Qwen3-8B+Kimi-K2+BGE-M3+BGE-Reranker-V2-M3 四模型需自备资源,按 8.0M tokens/day 估算峰值至少 2–4 张 A100;也可改云端 API 但成本显著上升。(3)误报 KB、关键词 KB、动态基线 $(\mu+2\sigma)$ 都是私有,外部必须从零搭建并标注,工作量以人月计。(4)B3-F1 评估需 SRE 专家标注 ground truth,标注成本不低。建议路径:用 Qwen 系列做 M1、BGE 做嵌入,LLM 审计先用 GPT-3.5/GPT-4o 替代 Kimi-K2,跑通架构后注入私有数据,约 2–4 周完成离线验证版,生产级 SNR 优化需 2–3 个月领域适配。
论文图表