題幹與適用場景
這是檢索系統設計題，不是背誦某個向量資料庫名稱。目標是對 embedding 做語意搜尋，同時滿足租戶隔離、元資料與權限過濾、延遲、可搜尋新鮮度與相關性評估。假設 embedding 由上游模型生成，文件會更新和刪除，系統既要支援批量回填，也要支援持續寫入。
面試官考察點
- 能否拆分寫入、向量生成、索引建置、查詢服務與評估鏈路。
- 能否說明精確搜尋為何昂貴，並根據約束選擇近似最近鄰（ANN）方案。
- 能否在不犧牲召回與租戶隔離的前提下執行過濾。
- 能否定義更新、刪除、模型升級與重建期間的可見性語義。
- 能否給出召回、延遲、成本與新鮮度指標，而不是把相似度當成正確性。
回答前需要釐清的問題
- 向量維度、距離函數、每租戶文件量與查詢 QPS 是多少？
- 租戶與 ACL 是必須滿足的硬過濾，還是允許檢索後再刪除結果？
- 一分鐘新鮮度適用每次寫入，還是只適用熱門集合？
- 是否需要關鍵字與向量混合搜尋、重排，還是只做近鄰搜尋？
- embedding 模型是否會更換？遷移期間舊向量是否必須繼續可查？
30 秒回答框架
「我會把系統拆成持久化寫入日誌、embedding worker、有版本的向量索引和無狀態查詢層。每筆記錄帶租戶、ACL、文件版本、模型版本和刪除狀態。查詢先做授權，再路由到租戶分片，執行帶過濾的 ANN，並可對小候選集重排。新寫入進入可變 delta 索引，後台建置不可變 segment；查詢合併兩者並按版本隱藏舊資料。評估用精確搜尋或標註集校驗 recall@20，同時監控 p95、過濾錯誤、新鮮度延遲和每次查詢成本。」
分步深入解答
第一步：定義資料與可見性契約
保存 document_id、tenant_id、ACL 屬性、embedding 模型版本、內容版本、向量與更新時間。刪除應寫成帶版本的墓碑記錄，不能假設所有副本立即刪除。查詢必須先完成授權；租戶和 ACL 是硬約束，相關性排序只能在已授權候選中進行。
第二步：選擇 ANN 索引與分片
對 N 個 D 維向量做暴力搜尋，大致需要 O(N × D) 次距離計算。一億向量無法滿足 150 毫秒目標，因此選擇 HNSW 或倒排聚類等 ANN 索引。HNSW 通常以較高召回換取記憶體；聚類或量化能降低記憶體和成本，卻增加調參與召回風險。先按租戶命名空間或分片，再把熱門租戶獨立拆分並複製讀容量。不要聲稱某個庫有通用複雜度或召回數字，必須按維度和實作基準測試。
第三步：把過濾納入檢索正確性
後過濾可能先找到 20 個相似但屬於其他租戶的向量，過濾後只剩很少結果；預過濾能縮小候選空間，卻可能讓低選擇性過濾變慢。可行方案是讓可過濾元資料與向量路徑一起建索引，按選擇性動態擴大候選池，或為高選擇性條件使用專用 segment。Pinecone 文件把元資料謂詞作為查詢契約的一部分；回答必須說明授權結果不足 20 條時的行為。
第四步：分離新寫入與壓縮 segment
先把寫入追加到可靠日誌和小型可變 delta 索引。查詢同時讀取基礎 segment 與 delta，按文件版本合併並隱藏墓碑 ID。後台壓縮生成新 segment，校驗數量和抽樣召回後原子替換 manifest。一分鐘 SLA 要從寫入確認到查詢可見來量測，而不是從 embedding 任務啟動來量測。生成或建索引延遲時暴露 lag，並保留舊版本，不能把「寫入成功」當成「已可搜尋」。
第五步：處理模型與元資料遷移
更換 embedding 模型後，新舊向量通常不可直接比較，需要雙索引或投影方案。給記錄寫入模型版本，回填新索引，對新舊索引做 shadow query，比較召回和延遲後再切換。回滾與保留窗口結束前保留舊索引。ACL 元資料升級也要分版本發布；向量相似絕不能繞過新增權限欄位。
第六步：設計查詢路徑與過載策略
查詢層先驗證租戶，規範化查詢，選擇模型版本，只向相關分片發請求。設定 deadline、候選上限和取消機制。分片超時時，只有 API 明確支援部分結果才能回傳並標記完整性；權限敏感查詢應失敗關閉。可以快取 embedding 和穩定的公開查詢，但快取鍵不能跨授權範圍共享。突發流量時用 admission control 保護索引記憶體和重排容量。
第七步：衡量相關性、新鮮度與成本
建立包含相關文件和禁止文件的標註查詢集。對抽樣分片與精確搜尋基線比較，報告 recall@20、precision 或 nDCG、過濾正確率和權限洩露測試。持續記錄 p50/p95/p99 延遲、候選數、索引建置時間、寫入到可見的 lag、墓碑積壓、每向量記憶體和每千次查詢成本。離線指標發現排序回歸；線上點擊會受位置偏差影響，不能單獨作為正確性證明。
設計取捨與邊界
HNSW 與聚類或量化索引
記憶體足夠且讀多寫少時，HNSW 是合理起點。資料規模更大或記憶體成本敏感時可用 IVF 或乘積量化，但必須增加訓練、調參與召回驗證。選擇依據應是更新率、維度、租戶傾斜和硬體預算，而不是產品名稱。
專用向量庫與現有資料庫
集合規模中等、ACL 資料需要交易連接時，既有資料庫的向量索引更簡單。向量檢索成為主要容量、需要專用 ANN 索引或獨立擴縮容時，再考慮專用服務。若向量庫不能提供交易保證，應把文件與權限事實保留在外部來源系統。
每租戶索引與共享分片
每租戶獨立索引便於隔離和控制噪聲，但運維開銷會隨租戶增長。共享分片硬體利用率高，卻要求嚴格元資料過濾和公平調度。普通租戶使用命名空間或分區鍵，超大或強監管租戶再使用獨立容量。
高品質示範回答
「我會先建立持久化寫入日誌，並為每份文件、ACL 和 embedding 模型做版本管理。查詢層先完成租戶授權，只向相關分片發請求，執行帶過濾的 ANN，再合併新鮮 delta 與不可變 segment。讀多寫少時可從 HNSW 起步，但要用 recall@20 和 p95 延遲與聚類或量化索引做基準。重建透過原子 manifest 發布，模型升級使用 shadow query，刪除使用帶版本的墓碑。服務還要報告過濾正確率、寫入到可見 lag、權限洩露測試、每向量記憶體和查詢成本；相關性必須是可測量契約。」
常見錯誤
- 只討論 ANN 庫選型，忽略寫入、刪除和重建。
- 檢索後才執行 ACL 過濾，結果數量不足時卻沒有明確契約。
- 不說明向量維度、索引參數、硬體和負載，就聲稱固定召回率或延遲。
- 原地替換 embedding 模型，導致新舊向量不可比較。
- 只看點擊率，不維護精確搜尋或標註相關性基線。
追問及應對
ACL 過濾後只有三條結果怎麼辦？
按契約回傳三條並標記完整性，或回傳「結果不足」。絕不能用未授權或未過濾結果填滿剩餘位置。擴大候選池也必須在授權檢索路徑內完成。
如何重建索引而不遺失寫入？
從持久化日誌回放到新 segment，記錄高水位，補齊高水位之後的寫入，校驗數量和抽樣召回後原子發布 manifest。切換完成前保持 delta 路徑，失敗時恢復舊 manifest。
什麼時候能刪除舊模型向量？
只有 shadow 評估通過、新模型已服務、回滾與保留窗口結束，並且所有查詢路徑都拒絕舊模型版本後才能刪除。僅按時間刪除會遺漏延遲任務或回放消費者。