GitHub Issues 導覽優化：三層快取架構讓即時命中率從 4% 升至 70%
GitHub Engineering · 2026-05-14
GitHub 工程團隊發文記錄 GitHub Issues 導覽效能的現代化歷程：以三層快取架構取代原本每次導覽都完整付出伺服器渲染與網路成本的流程，P10 延遲從 600ms 降至 70ms，即時導覽（0ms）比例從 4% 提升至約 70%，快取命中率從 33% 升至 96%。
原本的問題
GitHub Issues 的使用模式高度重複——使用者在 triage 工作流程中反覆瀏覽同一組 issue、跟隨連結後返回、切換標籤篩選。每次導覽都付出完整的伺服器渲染成本，即便資料在幾秒前才看過。P10 延遲約 600ms，P50 約 1,200ms，對鍵盤重度使用者（如 triage 工程師）體感明顯。
三層快取架構
第一層：IndexedDB 持久化快取使用 stale-while-revalidate（SWR）語意：瞬間從本地資料渲染，背景非同步重新驗證。在 session 間保留。
第二層：In-memory hot cache位於 active store 與 IndexedDB 之間，提供同步存取，避免跨越非同步邊界的延遲。
第三層：Service Worker攔截硬性導覽（hard navigation）與冷啟動，在命中快取時通知伺服器跳過部分渲染工作。
預熱策略
快取的關鍵不只是儲存，而是提前填充：系統在使用者訪問 issue 列表或儀表板等「高意圖」頁面時，以低優先級 worker 主動預取並快取可能被點擊的 issue。預熱邏輯帶有速率限制和 circuit breaker，避免不必要的網路請求。
效能結果
| 指標 | 優化前 | 優化後 |
|---|---|---|
| P10 延遲 | ~600ms | 70ms |
| P50 延遲 | ~1,200ms | 700ms |
| 即時導覽比例 | 4% | ~70% |
| 快取命中率 | 33% | ~96% |
團隊接受約 4.7% 的伺服器/快取資料差異（controlled staleness），認為對 triage 工作流程而言這是可接受的取捨。
Meta SilverTorch：以索引作為模型的推薦系統新檢索典範
Meta Engineering · 2026-05-26
Meta 工程部落格發表 SilverTorch，一個顛覆傳統「先建索引、再向量搜尋」推薦流程的新框架。SilverTorch 將索引本身設計為模型（Index as Model）：索引結構不再是獨立於推薦模型之外的查詢加速器，而是整合進模型訓練週期，使檢索與排序在同一最佳化目標下共同演化，解決兩個子系統在訓練時目標不一致的長期痛點。
背景：傳統兩段式架構的問題
大規模推薦系統通常分為檢索（retrieval）與排序（ranking）兩個階段：檢索用 ANN（近似最近鄰）搜尋找出候選集，排序模型再對候選集做精細評分。兩個子系統各有獨立的訓練目標——ANN 索引最大化向量相似度，排序模型最大化點擊或轉換率，導致最終業務指標（如用戶參與度）在兩個系統的邊界處損耗。
SilverTorch 的核心設計
SilverTorch 以可微分的近似索引（differentiable approximate index）替換傳統 ANN 索引。索引結構的參數（如分區中心點、routing logic）被納入端對端梯度流，使索引在反向傳播時根據最終業務指標自我調整，而非僅優化向量距離。具體而言，Meta 團隊採用基於可學習量化（learnable quantization）的索引層，讓量化碼本（codebook）作為可訓練參數更新。
影響範圍
SilverTorch 在 Meta 多個推薦系統（Reels、Groups Feed、Marketplace）上通過 A/B 測試，在內部業務指標上達到正向提升。由於架構涉及分佈式訓練中索引參數的梯度同步，計算成本高於傳統離線建索引——Meta 目前的做法是以較低頻率更新索引參數（每個訓練 epoch 更新一次），降低同步開銷。