這項由螞蟻集團與上海交通大學聯合完成的研究，以預印本形式發布於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的動態基線機制要求投訴量不只超過絕對閾值，還必須比同期歷史水平高出兩個標準差以上，兩個條件同時滿足才觸發告警。這就像判斷一個城市是否"異常塞車"，不只看當前車輛數量，還要和同一時段的歷史平均水平比較，這樣才能過濾掉節假日本來就會有的正常擁堵。
