品質與安全#

推薦系統上線後需要持續監控與優化。本章涵蓋測試方法、評估指標、攻防與倫理議題。

測試方法#

四種測試方法#

業務規則掃描#

推薦系統雖然是機率系統，但仍有確定性的業務規則，違反就是 Bug。

離線模擬測試#

1. 收集歷史用戶請求參數
2. 用新系統生成推薦結果
3. 對比真實回饋計算指標

評估指標：

• TopK 準確率 / 召回率
• AUC / GAUC
• 覆蓋率
• 失效率

線上對比測試#

使用 A/B 測試框架：

┌────────────────┐
│   全部流量      │
├───────┬────────┤
│ 實驗組 │ 對照組  │
│  50%  │  50%   │
└───────┴────────┘

線上測試是驗證效果的黃金準則，但需要足夠的樣本量與測試時間。詳細流量分配與分層架構見 第 9 章。

用戶訪談#

• 評估指標設計是否合理
• 發現資料無法反映的問題
• 深入了解用戶真實感受（挫折、驚喜、不安）

評估指標#

兩大問題#

推薦系統指標回答兩個核心問題：

效果指標#

預測準確度#

RMSE = √[Σ(r̂ - r)² / n]
MAE = Σ|r̂ - r| / n

排序指標#

AUC = Σ I(r̂_pos > r̂_neg) / (|pos| × |neg|)

分類指標#

商業指標#

健康指標#

覆蓋率#

UV 覆蓋率 = 有效推薦覆蓋的用戶數 / 總用戶數
PV 覆蓋率 = 有效推薦的請求數   / 總請求數

失效率#

失效率 = 推薦結果為空的請求數 / 總請求數

新穎性#

推薦結果中用戶未見過的比例（依不同粒度評估，如「新類別」「新作者」「新物品」）。

更新率#

更新率 = 本次與上次不同物品數 / 上次推薦數

個人化程度#

個人化程度 = 1 - 平均(用戶間推薦列表相似度)

值越高代表「不同人看到不同東西」，越低代表「大家看到差不多的東西」。

基尼係數（馬太效應）#

Gini = (1/n) × Σ p_i × (2i - n - 1)

p_i：按推薦次數排序第 i 個物品的推薦比例。

接近 0 表示均勻、接近 1 表示集中。Gini 過高代表流量集中在少數頭部物品，長尾沒被照顧到。

多樣性（Entropy）#

Diversity = Σ(-p_i × log(p_i)) / (n × log(n))

p_i：類別 i 被推薦的比例。

健康指標一旦惡化，效果指標通常還能撐一陣子，但用戶感受會先變差（資訊繭房感、推薦無聊感）。要早期觀察健康指標。

推薦系統攻防#

攻擊類型#

協同過濾特別容易受攻擊，因為它依賴「群體智慧」，可以透過操縱「選民」來影響結果。

托攻擊（Shilling Attack）#

攻擊者批量註冊假用戶，製造虛假行為：

目標物品（要扶持 / 打壓的）
    ↑
助攻物品（構造相似用戶）
    ↑
陪跑物品（掩飾造假）

攻擊方式#

信號層攻擊#

托攻擊操縱的是「用戶」，但攻擊也可以直接污染回饋信號本身——這就是資料投毒在推薦系統的具體形態：

這些攻擊對應到前面的防護框架（用戶品質評分、行為異常偵測、機器人偵測），差別在於監控的是信號的統計分佈而非帳號本身。把「點擊 / 停留 / 評分」的分佈當成被監控對象，偏離基線就告警。

防護策略#

平台級#

資料級#

1. 標註假用戶 / 假回饋資料
2. 訓練分類器識別
3. 排除或降權可疑資料
4. 用聚類發現異常群體

演算法級#

服務層與 Web 安全#

前面談的是「演算法層」的攻防，但推薦系統終究是一個對外的 Web 服務，serving API 與前端反饋流同樣是攻擊面。

輸入驗證與注入#

推薦 API 的參數（user_id、查詢字串、批量大小）都是不可信輸入：

反饋流的 XSS 與 CSRF#

點擊、評分等反饋常經由 HTML/JS 介面，且物品的標題、描述會被渲染：

• 儲存型 XSS：惡意物品元資料（標題、標籤）注入腳本，渲染推薦卡片時執行 ➡️ 對所有動態內容做 HTML 跳脫、設定 CSP。
• CSRF：誘導已登入用戶送出偽造反饋（刷讚、灌負評）➡️ 反饋表單加 anti-CSRF token、cookie 設 SameSite。

限流與可用性#

serving API 多半無狀態、對外公開，是 DoS 的天然目標（尤其模型推理很貴）：

• 依用戶 / IP 限流、設連線逾時。
• 熱門推薦結果快取，攤平尖峰。
• CDN 卸載 + 水平擴展。

資訊洩露#

推薦回應可能洩漏模型與用戶資訊：冗長錯誤訊息暴露 schema、推理時間差形成 timing 旁路、被大量抓取以反推排序邏輯。防禦：回傳通用錯誤訊息、限制回應中的中繼資料、對爬取行為限流偵測。

演算法再穩健，serving 層一個注入或未限流的端點就能讓整個系統失守。安全要端到端：資料層防投毒、演算法層防操縱、服務層防 Web 攻擊。

典型案例#

某電商網站被攻擊：攻擊者大量購買暢銷書與自己要推的書，導致在暢銷書頁面的「相關推薦」中出現目標書籍。

公平性與倫理#

推薦系統不只是技術問題，還是社會問題。隨著影響力擴大，下面這些議題從「nice to have」變成「must have」。

常見議題#

緩解方向#

歐盟 DSA、中國《個人化推薦演算法管理規定》、台灣《個人資料保護法》都對推薦透明化提出要求。設計階段就要把這些納入考量，不要等到上線才補。

商業價值與成本#

商業價值的三個來源#

對平台而言，推薦系統的商業價值來自：

1. 提升留存：用戶找到想看的內容，更願意回來
2. 提升活躍：人均時長與互動次數增加
3. 提升變現效率：廣告 CTR、電商 CVR、訂閱轉換率

成本考量#

做推薦系統之前要評估：新增的留存 / 變現價值 是否大於 總投入？小規模平台用人工編輯往往更划算。

資訊流的演進#

Feed 的歷史#

配套設施#

發展趨勢#

1. 人機協同：純演算法驅動容易在敏感事件上翻車，需要編輯把關與規則兜底
2. 目標多元化：從單一 CTR ➡️ 多目標（時長、互動、長期留存、創作者生態）
3. 生成式推薦：LLM 直接生成推薦理由、甚至生成個人化內容（推薦 + AIGC）
4. 合規與倫理：透明化、用戶可控、未成年人保護成為硬性要求

總結#