題幹與適用場景
平台接收文字、圖片、音訊和影片，使用者希望發佈後很快可見；平台又必須在高風險內容造成大範圍傳播前處理它。請設計上傳預篩、非同步深度分析、人工審核、申訴、發佈後複查和策略迭代。題目不要求你訓練模型，但要說明模型輸出如何進入可稽核的業務決策。
公開系統設計面經把這類題拆成多層流水線、信心度分段、人審佇列和申訴流程。為了讓容量可複算，先採用一組面試假設：每小時 1,000,000 次上傳，平均約 278 次/秒，峰值按 10 倍約 2,778 次/秒；同步預篩給發佈鏈路增加不超過 100 毫秒，人工團隊每天最多處理 100,000 個案件。真實數值應由面試官給定後替換。
面試官考察點
面試官會看你能否把「審核」拆成不同延遲和風險等級的決策，而不是只畫一個分類器。強回答會區分立即阻斷、先發佈後複查和送人工的路徑，按政策類別設定不同閾值，記錄模型版本與證據，並說明錯誤判定如何糾正。
系統設計評分還包括峰值容量、佇列積壓、重複任務、模型不可用、對抗性輸入、審核員安全、申訴時限和租戶或地區隔離。只談準確率卻沒有安全預設、回放證據和營運指標，無法支撐線上治理。
回答前需要釐清的問題
哪些內容必須阻斷
確認是所有內容都要發佈前審核，還是只有明顯高風險類別必須同步阻斷。若只允許約 100 毫秒的同步預算，影片深度分析應轉為非同步；若法規要求某類別零延遲下架，就要為該類別保留更重的同步檢查。
錯誤成本如何排序
詢問誤殺合法表達與漏放高危內容哪一個代價更高，以及是否按國家、年齡或內容類別變化。答案決定每類閾值、是否寧可送人工、以及自動動作能否直接刪除。
審核和證據需要保留多久
確認申訴期限、監管取證、媒體儲存和個人資訊刪除要求。若必須複盤當時的判斷，系統要保存當時的策略版本、模型版本、輸入摘要、分數、證據引用和審核員動作，而不是只存最終標籤。
模型和人工的容量邊界
詢問模型不可用時是否允許降級發佈、人工每日容量和最長等待時間。容量不足時應降低低風險非同步流量或延遲非關鍵任務，不能讓佇列無限增長並悄悄放過高風險內容。
30 秒回答框架
「我會把路徑分成同步預篩和非同步深審。上傳時先做雜湊命中、格式與大小檢查、輕量分類和基礎策略校驗；明確高風險直接阻斷，中間信心度進入按風險和預計曝光排序的人審佇列，低風險先發佈但保留發佈後複查。每個決定記錄模型、策略、證據和版本，申訴交給不同審核員。容量上按峰值 2,778 次/秒擴展預篩，非同步佇列用租戶和風險類別隔離，監控漏放、誤殺、積壓年齡、曝光時間和審核員負載；模型或佇列故障時採用安全預設和明確的人工兜底。」
分步驟深入解答
第一步：拆分同步與非同步決策
入口接收內容後寫入不可變的 contentId 和媒體引用。同步層只做快速雜湊匹配、格式與大小檢查、輕量文字或圖片模型和地區策略。明確高危結果阻斷；可疑但不確定的結果進入 PENDING_REVIEW；低風險結果允許發佈並附帶後續複查標記。影片抽幀、音訊轉寫和多模型融合放到非同步流水線，避免把深度分析時間塞進發佈請求。
第二步：按類別而不是全域分數動作
不要用一個全域閾值處理所有政策類別。對高危類別可以設定較低的自動阻斷門檻，並把臨界樣本送人審；對語境依賴強的類別，擴大人工區間，減少誤殺。閾值設定必須帶策略版本和生效地區，決策事件保存原始分數及閾值，後續才能解釋為什麼採取某個動作。
第三步：設計可擴展的審核佇列
把審核任務寫入持久佇列，按風險等級、預計曝光量、使用者檢舉和截止時間計算優先級。每個任務帶租戶或地區、內容版本、策略版本和租約；審核員領取後短暫鎖定，逾時自動回佇列。佇列按類別和地區分片，避免一個熱門類別耗盡所有人工容量；當積壓年齡超過閾值時，降低低風險非同步任務的准入並告警。
第四步：讓申訴和回饋可回放
申訴建立新案件，不覆蓋原始決定。複核員看到當時的證據、策略和模型版本，並擁有與初審不同的權限；推翻決定會恢復內容或保留限制，同時產生稽核事件。抽樣人工結果、申訴翻轉和新出現的規避樣本進入評估集，但不能未經審核直接回灌訓練，以免把錯誤標籤放大。
第五步：觀測風險、體驗和成本
即時指標包括預篩延遲、每類阻斷率、非同步佇列長度與年齡、模型錯誤率、審核吞吐和服務錯誤。成熟標籤到達後，再按類別和地區計算精確率、召回率、誤殺、漏放、申訴翻轉率。還要看高風險內容的曝光次數乘以線上時長、審核員平均暴露量和單位內容成本；只看模型準確率無法發現治理失效。
第六步：覆蓋故障和對抗性輸入
模型逾時或不可用時，保留雜湊命中和規則阻斷；對未知風險的內容進入受限發佈或人工路徑，不能把「無結果」當成安全。對重編碼圖片、變形文字、重複上傳和故意製造佇列的攻擊設定速率限制、內容去重和資源配額。所有自動動作都要能按 contentId 重放，便於事故調查和規則回滾。
高品質示範回答
我先確認發佈鏈路的同步預算和高風險類別。假設平均 278 次/秒、峰值 2,778 次/秒，我會把同步路徑限制在雜湊、格式、輕量模型和地區規則，目標是不超過 100 毫秒。明確高危內容立即拒絕；中間區間進入持久人審佇列；低風險內容先發佈，但標記為可被非同步複查。影片和音訊的深層分析透過佇列和 worker 執行，不能阻塞所有使用者的發佈。
閾值按政策類別配置，而不是把一個分數用於所有風險。每次決定保存 contentId、內容版本、模型與策略版本、分數、證據摘要和動作。人審任務按預計曝光量、風險、檢舉和截止時間排序，使用租約防止重複領取；積壓時先保護高風險佇列。審核員確認或推翻決定都會產生不可變事件，申訴由不同審核員處理並引用原始證據。
我會監控預篩延遲、佇列年齡、每類誤殺和漏放、曝光時間、申訴翻轉、人工容量和單位成本。模型故障時仍執行雜湊和規則阻斷，對未知結果採用受限發佈或人工兜底。模型、政策和地區變更都先離線回放，再小範圍灰度；這樣系統的目標是可解釋、可回滾和持續降低風險，而不是只追求一個離線準確率。
常見錯誤
- 所有內容都同步跑重模型 → 影片和音訊延遲拖垮發佈鏈路 → 同步只做快速預篩，深度分析非同步化。
- 所有類別共用一個閾值 → 高危漏放或語境類誤殺無法同時避免 → 按政策類別和地區配置閾值，並保留人工區間。
- 模型回傳空結果就自動放行 → 模型逾時會變成無稽核的漏放 → 保留規則和雜湊阻斷，對未知結果走受限發佈或人工兜底。
- 只存最終標籤 → 申訴時無法重建當時依據 → 保存內容版本、模型/策略版本、分數、證據和動作事件。
- 佇列按先到先得 → 熱門或低價值流量可能餓死高風險案件 → 按風險、預計曝光和截止時間排序，並隔離佇列容量。
追問及應對
追問一：人工審核只覆蓋總量的 1% 是否足夠？
比例本身不是目標。AWS 文件以其圖片和影片流程為例，說明機器篩選後人工可能只需查看約 1%–5%；你的系統仍應按類別召回、漏放後果、積壓年齡和曝光時間驗證，而不能把該範圍當成普遍保證。若高風險類別漏放，寧可擴大人工區間或降低發佈准入。
追問二：審核佇列積壓到一天怎麼辦？
先按風險和預計曝光重新排序，暫停低價值批量任務，擴大高風險審核容量並提升告警。對已經發佈的內容執行發佈後複查和限流；不能透過靜默丟棄任務來降低積壓數字。若仍無法滿足高風險截止時間，應收緊發佈策略並向業務暴露容量不足。
追問三：使用者申訴成功後如何防止模型再次誤殺？
保存申訴前後的策略和模型版本，將翻轉案例按類別加入獨立評估集，並檢查是否存在地區、語言或群體偏差。修訂閾值或規則後先回放歷史樣本，再灰度發佈；申訴結果不能直接當作未經審核的訓練標籤。
追問四：模型供應商切換時如何保證可追溯？
為每個模型配接器定義統一輸出和版本標識，保存原始供應商結果摘要與映射規則。新模型先在固定回放集和人工盲評中比較每類誤殺、漏放、延遲和成本，再按地區或流量灰度；出現異常時按策略版本回滾到舊配接器。