1. 題目
分析團隊希望公開每日活躍使用者、按地區分組的平均訂單金額和趨勢圖,同時不讓單一使用者的加入、退出或一筆記錄顯著改變發布結果。團隊成員把「移除姓名、雜湊使用者 ID」當作隱私方案,也有人要求直接把 epsilon 設成很小的數字。
請設計差分隱私發布流程,說明隱私單位、相鄰資料集、查詢敏感度、雜訊機制、epsilon/delta、重複查詢的組合、每位使用者的貢獻上限和準確率評估。最後說明哪些風險需要存取控制、最小化收集或治理流程配合。
2. 約束與釐清
- 先明確保護的是使用者、帳號、裝置還是事件;同一使用者的多筆事件通常應屬於一個隱私單位。
- 相鄰資料集的定義必須固定,例如兩個資料集只差一位使用者的全部記錄,或只差一筆事件;不同定義會得到不同敏感度和保證。
- 題目討論集中式差分隱私:可信的內部機制存取原始資料,再發布加雜訊結果。匿名化、雜湊和加密不自動提供差分隱私保證。
- 不應給出脫離查詢、資料分布和威脅模型的「正確 epsilon」;隱私強度、效用和使用者預期需要共同決定。
3. 核心定義:保護相鄰資料集間的輸出分布
隨機演算法 M 滿足 (epsilon, delta)-差分隱私,是指對任意相鄰資料集 D、D' 和輸出事件 S:
Pr[M(D) in S] <= exp(epsilon) * Pr[M(D') in S] + delta
這表示攻擊者即使擁有其他輔助資訊,也難以僅從一次發布判斷某個隱私單位是否存在;它不保證輸出中完全沒有敏感資訊,也不等同於「匿名後無法識別」。epsilon 越小,通常隱私約束越強但雜訊越大;delta 是允許極小失敗機率的參數,不能被隨意當成誤差率或缺失率。
相鄰關係決定「一個單位的變化」是什麼。若一位使用者最多貢獻 5 筆訂單,計數查詢的使用者級敏感度可限制為 1,金額總和則還需要限制單筆金額或使用者總金額,否則單一使用者可以改變任意大的結果。
4. 機制與參考偽程式碼
對敏感度為 Delta 的計數或有界總和,Laplace 機制可以發布 f(D) + Laplace(Delta / epsilon)。對需要 (epsilon, delta) 保證的高維或平均值查詢,常用 Gaussian 機制,但校準依賴敏感度、delta 和會計方法。
release_count(users, epsilon, delta, budget):
clipped = cap_each_user_contribution(users, max_contribution=1)
true_count = count_distinct_privacy_units(clipped)
require budget.remaining >= epsilon
noise = sample_laplace(scale=1 / epsilon)
budget.spend(epsilon, delta)
return max(0, round(true_count + noise))
release_mean(records, epsilon, delta, budget):
clipped = cap_each_user_contribution(records, max_rows=K)
clipped_values = clamp_values(clipped, lower=L, upper=U)
sum_release = dp_sum(clipped_values, epsilon_sum, delta_sum)
count_release = dp_count(clipped, epsilon_count, delta_count)
return sum_release / max(count_release, minimum_safe_count)平均值不能只給分子加雜訊:分母也必須保護,且數值範圍和每位使用者貢獻都要裁剪。裁剪會引入偏差,雜訊會引入變異,應在模擬或保留的評估集上測量區間覆蓋、相對誤差和小群體失真。
5. 組合、預算與系統設計
同一隱私單位參與多次發布時,隱私損失會組合。最簡單的基本組合把多次純 epsilon 保證相加;實際系統可使用更緊的高階組合或 Rényi DP 等會計方式,但必須統一會計器、隱私單位和 delta 語義。把同一查詢換成十個不同篩選條件,仍會消耗預算,不能因為每次只發布聚合值就忽略組合。
預算服務應為每個隱私單位或資料集維護已花費的 epsilon、delta、查詢類型、版本和過期策略;預算耗盡後拒絕、降級到更粗粒度或回傳既有結果。並行發布互不重疊的使用者分區可以使用並行組合界限,但同一使用者的多個分組貢獻仍需按使用者級會計。
治理上還要限制查詢權限、記錄稽核、規定保留期、區分探索和正式發布,並對小群體設定最小門檻。差分隱私保護的是統計發布的可區分性,不能修復原始資料中的越權存取、惡意內部人員、輸出業務邏輯洩露或結果本身不應公開的問題。
6. 追問與陷阱
- 為什麼雜湊 ID 不夠? 雜湊通常仍是穩定連結識別,結合外部資料可重新識別;它沒有給出相鄰資料集輸出分布的機率保證。
- epsilon 能越小越好嗎? 不能脫離效用。過小的 epsilon 可能讓小群體結果無法使用,必須透過威脅模型、使用者預期和誤差目標共同選擇。
- 為什麼要限制使用者貢獻? 沒有貢獻上限時,一個高活躍使用者可以主導敏感度,導致雜訊校準失真或保護承諾無法解釋。
- 發布多個分組會怎樣? 每次查詢都消耗預算;高維切片還會造成稀疏雜訊和多重比較問題,應限制維度、預先登記查詢並使用統一會計。
7. 驗證與品質檢查
- 性質測試: 在相鄰資料集上重複執行機制,檢查輸出分布比率是否滿足設定的 epsilon/delta 上界,而不是只比較一次結果。
- 效用測試: 用代表性評估集測量絕對誤差、相對誤差、區間覆蓋和不同群體的誤差差異,分別評估計數、總和與平均值。
- 預算測試: 模擬重複查詢、並行請求、重試和快取命中,確認每次邏輯發布只記帳一次且不能繞過剩餘預算。
- 治理測試: 驗證隱私單位映射、貢獻裁剪、權限、稽核、最小群體門檻和版本回滾,確保實作與公開隱私聲明一致。
8. 面試評分點
能定義隱私單位與相鄰關係
候選人應先說明保護對象、使用者級或事件級相鄰定義,以及它們如何改變敏感度和預算。
能解釋機制與效用取捨
應區分 Laplace 與 Gaussian 機制,說明敏感度、裁剪、epsilon、delta、偏差和變異,而不是只說「加隨機雜訊」。
能處理組合與預算治理
應說明重複查詢會累積隱私損失,並提出統一會計、貢獻上限、拒絕或降級策略。
能識別差分隱私的邊界
應指出差分隱私不能替代存取控制、資料最小化、稽核和輸出治理,並給出性質、效用和預算驗證方法。