題幹與適用場景
搜尋團隊完成了新的排序演算法，但上線方式未定。工程師想用功能開關，成長團隊想做 A/B 實驗，營運擔心事故。請說明如何選擇機制、定義成功指標、控制曝光，並在結果不佳時回滾。假設演算法已部署到生產，問題集中在「誰看到、如何比較、何時擴大」，不討論程式實作。
面試官考察點
- 能否區分目的：功能開關控制曝光，漸進發布控制風險，A/B 實驗回答因果問題。
- 能否先定義使用者、商業與系統護欄指標，再討論流量比例。
- 能否說明穩定分桶、實驗污染、回滾權限與預設值。
- 能否把旗標生命週期、負責人和清理計畫放進產品方案，而非只談上線按鈕。
回答前需要釐清的問題
- 我們是在驗證價值，還是只想安全發布？ 未知價值需要實驗；價值已確定但風險高則漸進發布。
- 實驗單位是什麼？ 搜尋演算法通常按使用者或帳號穩定分桶；按請求隨機會讓同一使用者看到不同體驗。
- 主要成功指標和不可接受的護欄是什麼？ 點擊率提升不能掩蓋延遲、客訴、轉換或錯誤率惡化。
- 是否跨端、跨地區或依賴其他服務？ 若曝光不能一致，實驗結論會被污染，應縮小範圍或先解決分配問題。
30 秒回答框架
「我先確認目標是學習、控風險，或兩者兼有。若要比較排序價值，我會用使用者級穩定分桶的 A/B 實驗；若價值已確認但擔心事故，就先小範圍漸進發布，並保留一鍵關閉的功能開關。上線前定義一個北極星指標和延遲、錯誤率等護欄指標，記錄變體 ID、曝光與結果。達到預設門檻才擴大，失敗則暫停並回滾，實驗結束後刪除旗標和清理程式碼。」
分步驟深入解答
1. 先把三種機制放回問題類型
功能開關是執行時的控制面：程式可進入生產，但不必向所有使用者曝光。漸進發布是曝光策略：從內部帳號、少量客戶到全量。A/B 實驗是比較變體的測量設計：在可比群體中觀察指標差異。三者可以疊加，不能互相取代。
2. 選擇實驗單位與穩定分桶
Google Cloud 文件範例使用 userID 做 sticky bucketing，並用描述性變體 ID 記錄結果。搜尋排序應按使用者或帳號雜湊到 baseline/experimental，讓同一使用者在實驗期間不來回換組。若按請求隨機，快取、學習行為與回訪體驗會互相污染。
3. 設計指標和停止規則
北極星指標應直接代表使用者任務，例如有效搜尋後的滿意點擊或完成率。護欄指標涵蓋 P95 延遲、零結果率、錯誤率、客訴與商業損失。提前寫出擴大、暫停和回滾門檻，避免短期點擊上升就忽略長期留存或系統健康。
4. 用漸進發布降低不可逆風險
Microsoft 的做法把部署與曝光分開，從團隊帳號、選定客戶到更廣使用者逐級開放。先讓內部使用者驗證基本正確性，再按地區或客戶段擴大。每一級都檢查指標與日誌；旗標的關閉路徑必須獨立於新演算法，避免「回滾按鈕本身依賴故障程式碼」。
5. 處理實驗污染與變體稽核
記錄使用者、變體、時間、版本、曝光事件與結果事件。Google Cloud 建議使用描述性變體名稱，不要只記錄布林值。若同一使用者跨端分配不一致、實驗組互相影響，先標註污染並暫停結論。指標分析必須能從結果追溯到當時的旗標規則。
6. 結束實驗並治理旗標
Optimizely 區分實驗和目標投放：實驗回答「哪種方案更好」，答案確定後再用旗標發布勝者。Atlassian 與 Microsoft 都強調清理已全量發布的舊旗標，否則會累積分支、溝通和維護成本。每個旗標應有負責人、到期日、預設值和刪除任務。
高品質示範回答
我會先問團隊要學習還是控風險。排序演算法的價值未知，所以第一階段採用使用者級穩定分桶的 A/B 實驗；實驗外層再套小流量漸進發布開關，任何護欄超過門檻都能立即關閉。成功指標是有效搜尋後的滿意點擊，護欄包括 P95 延遲、零結果率、錯誤率和客訴。
我會記錄變體 ID、曝光和結果，不按請求隨機分組，也不只看點擊率。先在內部帳號和一小組客戶執行，確認日誌、快取和跨端分配一致，再按預設門檻擴大。結果確定後，把勝者切換為預設並刪除實驗分支、負責人和旗標設定；若護欄惡化，先暫停實驗、恢復 baseline，再調查原因。這樣同時回答學習、風險與長期治理。
常見錯誤
- 錯誤表現 → 把功能開關說成 A/B 實驗。 失敗原因：開關只控制曝光，不一定產生可比測量。修正方法：明確說明實驗需要分組、指標、曝光紀錄與分析計畫。
- 錯誤表現 → 每次請求隨機分流。 失敗原因：同一使用者體驗抖動，快取和行為被污染。修正方法：選擇穩定實驗單位並使用 sticky bucketing。
- 錯誤表現 → 只設定一個成長指標。 失敗原因：點擊上升可能同時伴隨延遲、錯誤或客訴惡化。修正方法：同時定義北極星指標和系統、體驗護欄。
- 錯誤表現 → 全量後保留旗標不清理。 失敗原因：分支和規則持續增加，未來無法判斷哪條路徑有效。修正方法：建立時登記負責人、到期日和刪除任務。
追問及應對
如果實驗組點擊率高但延遲也高，你會選哪一個？
先檢查護欄是否超過預設門檻。若超標，暫停擴大並恢復 baseline，再按使用者價值分層判斷是否最佳化演算法或只在延遲敏感場景保留實驗。不能用單一點擊提升掩蓋系統退化。
如果同一使用者在網頁和行動端被分到不同變體怎麼辦？
先定義實驗單位。若問題要求跨端一致，就用帳號級鍵並統一分配服務；無法統一時，將結論限定在單端，避免把跨端互動誤當成實驗效果。
什麼時候不值得做 A/B 實驗？
當風險主要來自正確性或合規、樣本量不足以偵測目標差異，或上線價值已由外部約束決定時，直接使用小範圍漸進發布和護欄監控更合適。實驗成本應低於決策不確定性。
旗標服務不可用時預設什麼？
為每個變體定義安全預設值，通常是已驗證的 baseline，並在本地設定保留最後可用值。記錄評估失敗，避免旗標服務故障放大成核心業務故障。