Cloudflare 的機器人管理被世界各地的組織用來主動偵測測和緩解自動化機器人流量。為此，Cloudflare 利用機器學習模型來協助預測特定 HTTP 請求是否來自機器人，並進一步區分良性機器人和惡意機器人。Cloudflare 每秒處理超過 5500 萬個 HTTP 請求，因此我們的機器學習模型需要在 Cloudflare 的規模上執行。
我們不斷改進為機器人管理提供支援的模型，以確保它們納入最新的威脅情報。這一反覆運算過程是確保我們的客戶領先于惡意行為者一步的重要組成部分，並且需要嚴格的實驗、部署和持續觀察過程。
我們最近分享了 Cloudflare 的 MLOps 方法介紹，該方法提供了 Cloudflare 模型訓練和部署流程的整體概觀。在這篇文章中，我們將更深入地探討監控，以及我們如何持續評估支援機器人管理的模型。
為什麼監控很重要
在發佈機器人偵測模型之前，我們會進行廣泛的模型測試/驗證過程，以確保我們的偵測按預期執行。透過瀏覽器、HTTP 通訊協定和其他維度，在大量 Web 流量片段中驗證模型效能，以便更詳細地瞭解我們期望模型在部署後的執行情況。如果一切順利，該模型就會逐漸投入生產，我們的機器人偵測也會得到提升。
將模型部署到生產後，在細微層級上瞭解效能可能具有挑戰性。當然，我們可以查看基於結果的指標，例如機器人分數分佈或驗證解決率。這些內容提供了豐富的資訊，但隨著機器人評分或驗證解決率發生任何變化，我們仍然會問：「Web 流量的哪些部分受此變化影響最大？這是預期的嗎？」。
訓練網際網路模型就是針對移動目標訓練模型。只要輸入不改變，任何人都可以使用靜態資料訓練模型並取得很好的結果。構建一個適用於具有新威脅、瀏覽器和機器人的未來的模型是一項更加困難的任務。機器學習監控是這一過程的重要組成部分，因為它為我們提供了信心，讓我們相信我們的模型能夠透過嚴格、可重複的流程不斷進行推廣。
在機器學習監控之前的日子裡，團隊將分析 Web 流量模式和模型評分結果，以追蹤被評分為機器人或人類的 Web 請求的比例。這個高級指標有助於評估模型的總體效能，但沒有提供模型如何處理特定類型流量的詳細資訊。為了進行更深入的分析，我們需要進行額外的工作來調查各個流量分段的效能，例如來自 Chrome 瀏覽器或使用 iOS 的用戶端的流量。
透過機器學習監控，我們不僅可以在高層次上瞭解模型的行為方式，而且可以更精細地瞭解模型的行為方式，而無需進行大量的手動調查。監控透過回答關鍵問題來關閉意見反應迴圈：「我們的機器人偵測模型在_生產中_的表現如何？」監控為我們提供了與部署前模型驗證/測試相同的置信度，但套用至生產中的所有模型除外。
事實證明，監控功能非常有用，其中包括：
調查機器人評分異常：如果客戶報告機器學習評分出現假陽性/陰性，而我們懷疑偵測子集存在更廣泛的問題，那麼監控可以幫助我們找到答案。工程師可以從我們的全球監控儀表板中獲得見解，也可以關注特定資料集的效能。
監控任何模型預測或請求欄位：監控服務非常靈活，可以在我們的 Web 請求資料庫中儲存的任何請求工件上新增可觀察層。如果模型預測或相關結果與我們的請求記錄一起儲存，那麼就可以對其進行監控。我們可以跨工程團隊合作，以監控任何結果。
部署新模型：我們逐步部署新模型版本，最終逐步在 Cloudflare 的全球 Web 流量上執行。在此過程中，我們會進行一系列檢查，然後才能將新模型部署到下一個發佈步驟。監控使我們能夠在每個部署階段將最新模型與以前的版本和詳細的流量分段進行比較，這讓我們在繼續部署時充滿信心。
機器學習監控如何運作？
該過程從真實資料集開始，這是一組已知由人類或機器人產生的流量資料，且已進行相應且準確的標記。如果我們的模型將特定請求識別為機器人流量，當我們的真實標籤表明該請求源自人類時，我們就知道該模型對該請求進行了錯誤分類，反之亦然。這種標記資料（我們將流量標記為來自機器人或人類）是我們的模型首先接受訓練以學習進行偵測的資料。
在訓練時收集的資料集使我們能夠及時評估該快照的訓練模型的效能。由於我們希望在生產中持續評估模型效能，因此我們同樣需要獲取即時標記資料以與我們的機器人分數進行比較。當我們確定 Web 請求來自某個參與者時，我們可以為此目的產生一個帶標籤的資料集。例如，我們的啟發式引擎是高可信度標記資料的來源之一。其他可靠的標記資料來源包括客戶意見反應和攻擊模式研究。
我們可以直接將模型對 Web 請求的機器人評分與最近標記的資料集進行比較，以判斷模型效能。為了確保我們在評估模型隨時間變化的分數時進行同類比較，一致性至關重要：資料本身會有所不同，但我們希望方法、條件和篩選器在採樣時間段之間保持相同。我們已經自動化了這個過程，從而即時產生標記資料集，讓我們能夠及時瞭解模型的效能。
獲取詳細的效能指標
假設我們偵測到標記為機器人流量的給定資料集的準確性突然下降，這意味著我們的偵測錯誤地將機器人流量計為人類流量。我們很想確定造成評分失誤的確切流量子集。它來自最新的 Chrome 瀏覽器還是某個 ASN？
為了回答這個問題，效能監控使用了專項化，這是針對我們的資料集套用的篩選器，重點關注感興趣的維度（例如瀏覽器類型、ASN）。透過對資料集的專項化，我們既可以提出_應該_如何對流量評分的期望，也可以深入瞭解導致失誤的確切維度。
將監控整合到我們的機器人機器學習平台中
監控系統在名為 Endeavor 的統一平台上執行，我們構建該平台是為了處理與機器人相關的機器學習的各個方面，包括模型訓練和驗證、模型可解釋性以及向執行機器人偵測的伺服器提供最新資訊。我們可以將監控分解為幾個任務：轉譯監控查詢以擷取資料集、計算效能指標和儲存指標。Endeavor 使用 Airflow（一種工作流程執行引擎），使其成為在 kubernetes 叢集和 GPU 上執行監控任務的好地方，並可以存取 Postgres 和 ClickHouse 資料庫。
轉譯監控查詢
監控查詢只是對 ClickHouse Web 請求資料庫的 SQL 查詢，詢問「機器學習評分現在看起來如何？」。當我們新增資料集和專項化條件時，查詢會變得更加精確，以便我們可以提出更精確的問題「對於這組已知（非）自動化流量，在相關維度上的機器學習評分看起來如何？」。
在我們的系統中，用於訓練和驗證的資料集是使用 SQL 查詢確定的，這些查詢專門用於擷取請求流量的片段，例如由我們的啟發式引擎標記為機器人的流量。對於模型監控，我們調整這些查詢來測量準確性等效能指標，並不斷更新時間範圍以測量最新的模型效能。對於訓練和驗證中使用的每個資料集，我們可以產生一個監控查詢，以產生對模型效能的即時見解。
計算效能指標
準備好轉譯的監控查詢後，我們可以繼續從 Web 請求資料庫中獲取機器人分數分佈。MetricsComputer 將機器人分數分佈作為輸入，並針對可設定的時間間隔產生相關的效能指標，例如準確性。
我們可以根據任何感興趣的指標評估模型效能。MetricInterface 是一個 Python 介面，充當效能指標的藍圖。任何新新增的指標只需要實作介面的 compute_metric 方法，該方法定義 MetricsComputer 應如何執行計算。
儲存指標
每次監控執行後，我們都會按資料集、模型版本和專項化值將效能指標儲存在 ml_performance ClickHouse 表格中。預計算指標支援較長的資料保留期，因此我們可以根據模型版本或感興趣的維度隨時間的推移來審查模型效能。重要的是，可以根據需要回填新增的效能指標，因為 ml_performance 表格還儲存用於計算每個指標的分數分佈。
在 GPU 上執行任務
指標計算在跨 GPU 執行的 endeavour-worker 執行個體之間進行負載平衡。從系統角度來看，airflow-scheduler 將監控任務新增到 Redis 佇列中，並且在每個 GPU 上執行的 Airflow Celery worker 會從佇列中拉取任務進行處理。與只執行臨時模型訓練工作負載相比，我們從 GPU 持續提供的生產服務中獲益匪淺。因此，監控服務充當健康檢查的角色，確保各種 Endeavor 元件在 GPU 上正常運作。這有助於確保 GPU 始終處於更新狀態，並隨時準備執行模型訓練/驗證任務。
機器學習監控的實際應用
為了更好地說明 Cloudflare 如何使用機器學習監控，讓我們來看看最近的一些範例。
提高機器學習機器人偵測的準確性
當第一次部署監控系統時，我們很快發現了一個異常：我們的模型在使用 HTTP/3 的 Web 流量上表現不佳。當時，HTTP/3 的使用在 Web 上幾乎看不到，而且生產中的主要模型沒有接受過 HTTP/3 流量的訓練，導致機器人分數不準確。幸運的是，另一個機器人偵測層（即我們的啟發式引擎）仍然可以準確地查找使用 HTTP/3 的機器人，因此我們的客戶仍然受到保護。
儘管如此，這一發現還是指出了下一次模型反覆運算的一個關鍵改進領域。我們確實有所改進：下一個模型反覆運算始終能夠區分機器人和人類發起的 HTTP/3 Web 請求，與之前的模型版本相比，準確度提高了 3.5 倍以上。隨著我們啟用更多資料集和專項化，我們可以發現特定的瀏覽器、作業系統和其他維度，從而在模型訓練期間提高效能。
早期偵測，快速干預
在全球範圍內部署機器學習，在遍佈全球 100 多個國家/地區的資料中心中執行，是一項具有挑戰性的工作。事情並不總是按計畫進行。
幾年前，我們對機器學習驅動的機器人偵測進行了更新，這導致機器人偵測誤判增加——我們錯誤地將一些合法流量標記為機器人流量。我們的監控系統很快顯示出住宅 ASN 的效能下降，而我們預計其中大部分都是非自動化流量。
在上圖中，顯示的是部署到 1-3 三個共置「層」的情況。由於軟體部署從第 3 級共置中心開始，然後逐步升級到第 1 級共置中心，因此其影響也遵循相同的模式。
與此同時，我們正在將一個軟體版本部署到我們的全球網路，但我們不知道這是否是效能下降的原因。我們進行分階段部署，每次在一批資料中心更新軟體，最終覆蓋到全球流量。我們的監控儀表板顯示，效能的下降與這一部署模式完全一致，而且該版本已開始到達我們最大的資料中心。
監控儀表板清楚地顯示了軟體更新後的模式。我們在更新到達大部分資料中心之前還原了這一變更，並恢復了正常的機器學習機器人偵測效能。透過監控，我們可以捕捉效能異常，挖掘根本原因，並快速採取行動。
適用於所有人的模型部署監控
我們看到了能夠監控和控制我們的模型和部署的巨大價值，並意識到其他人也一定會遇到同樣的挑戰。在接下來的幾個月裡，我們將為 AI Gateway 構建更進階的功能——我們的代理可以協助人們更好地觀察和控制他們的 AI 應用程式和模型。藉助 AI Gateway，我們可以在一個統一的控制平面中執行與機器人偵測模型相同的所有部署、監控和最佳化策略。我們很高興能夠在內部使用這些新功能，但對於向公眾發佈這些功能感到更為興奮，這樣所有人都能夠部署、測試、監控和改進他們使用 AI 或機器學習模型的方式。
下一步
如今，機器學習監控可以協助我們調查效能問題，並在我們推出新模型時監控效能，而這一切才剛剛開始！
今年，我們加快了機器人偵測機器學習模型的反覆運算速度，以比以往更快的速度提供更好的偵測結果。監控是實現快速安全部署的關鍵。我們很高興能新增基於模型效能的警示功能，這樣，如果模型效能超出我們的預期範圍，就會自動向我們傳送通知。
除了推出 Workers AI 之外，我們最近還在 100 多個城市部署了 GPU，在全球範圍內提升了我們的運算資源。這個新的基礎架構將解鎖我們的模型反覆運算過程，使我們能夠探索具有更強大機器人偵測能力的新尖端模型。在我們的 GPU 上執行模型將使推理更接近使用者，從而獲得更好的模型效能和延遲，我們很高興能夠將新的 GPU 運算與我們的機器人偵測模型結合使用。