https://yennj12.js.org/yennj12_blog_V4/tags/datapipeline/Recent content in DataPipeline on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-15-vector-drift-blue-green-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-15-vector-drift-blue-green-zh/核心定義：向量索引的「健康度」不等於資料存在，而是指 HNSW 圖的連結品質——增量插入累積後圖結構失衡，recall 靜默下滑；Blue-Green 重建搭配 Lambda 雙索引架構，是兼顧零停機與高精度的唯一根治手段。 一、為什麼面試官問這個 RAG 系統上線後，工程師最容易忽略的問題不是「向量有沒有進去」，而是「向量索引精度是否隨時間穩定」。向量資料庫不像關聯式資料庫——寫入成功不等於查詢品質維持。面試官問這個，實際在測試三個層次的判斷力： 你是否理解 ANN 索引的內部結構：HNSW 不是 B-Tree，插入操作不做全域重平衡，因此 recall 會隨增量操作靜默衰退。候選人若只知道「向量存進去就能查」，代表從未在生產規模下操作過 RAG。 你是否能設計「寫入友好 + 讀取高精度」的分層架構：Lambda 架構在向量場景的應用屬於進階知識。弱答案只說「定期重建索引」卻無法說明如何做到零停機；強答案會畫出 Base + Delta 雙索引，並描述夜間管線的每一個驗證步驟。 你是否有刪除場景的務實方案：向量資料庫普遍不支援就地刪除後的圖修復，黑名單過濾是業界慣例。候選人若不知道，代表缺乏真實生產維運經驗。 弱答案特徵：「我們每週排程重建索引，重建期間暫停寫入。」沒有說明 recall 衰退速率、重建後如何驗證、流量如何切換、舊索引如何回滾。 強答案特徵：點出 HNSW 圖失衡的具體機制（節點鄰居數不均、長尾節點導致搜尋路徑加長），提出 Base + Delta 雙索引架構及查詢合併策略，描述 recall@10 golden-set 驗證閾值（≥ 90%），以及 10% → 50% → 100% 漸進流量切換與 24 小時回滾窗口的完整流程。 面試情境：「你的 RAG 系統上線六個月後，客服團隊反映搜尋到的文章越來越舊、越來越不相關，但後台顯示知識庫文件每天都有新增。你的 vector search 服務的 QPS 和錯誤率都正常。你怎麼診斷，又怎麼解決？」 這個情境的陷阱在於——所有「系統健康」指標都正常，問題是隱性的精度衰退。正確的診斷路徑是： 先查 delta_index_size：若六個月來持續增量、從未重建，Delta 可能已累積數十萬筆——HNSW 圖嚴重漂移。 對 golden test set 執行 recall@10 採樣，確認數字（如：發現 recall 已從 94% 跌至 71%）。 執行緊急全量重建，驗證通過後 Blue-Green swap，並建立夜間排程防止再次發生。 補建監控：delta_index_size 超過 40K 時告警，每小時採樣 recall。 二、核心原理與技術深度 HNSW 圖為什麼會漂移（Drift） HNSW（Hierarchical Navigable Small World）是目前最主流的 ANN 索引結構。它在建構時為每個節點在各層維持固定的鄰居數（參數 M，通常 16–64），搜尋時從最頂層貪心向下導航，每層選取距離 query 最近的鄰居繼續往下，直到 Layer 0 收集候選集。理論上在 M=16, efConstruction=200 的設定下，靜態資料集的 recall@10 可達 95%–97%。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/大多數工程師的直覺：「索引過期了？重新跑一次 Re-indexing 就好。」 資深 FDE 的直覺：「Re-indexing 要數小時，這期間服務怎麼辦？Re-indexing 之後 HNSW 圖會不會因此失衡？」 大多數工程師的直覺：「那就頻繁做增量更新，隨時保持最新。」 資深 FDE 的直覺：「增量更新累積到一定程度，Graph Drift 會讓 RECALL@10 從 95% 跌到 70%，這才是真正的定時炸彈。」 面試情境 面試官：「你們的企業客戶每天會在 GCS 上新增、修改、刪除數千份 PDF 文件。你們的 AI Agent 需要即時查詢這些知識庫，但現在常常給出已被刪除或過期的內容，讓客戶非常不滿。我知道 Vertex AI Vector Search 支援增量更新，但我聽說大規模頻繁更新會造成 HNSW 圖退化，進而影響搜尋精準度。請告訴我，你會如何設計一套既能即時響應文件變更、又能長期維持向量索引健康度的自動化管線？在系統規模達到百萬向量時，你的設計會有哪些具體調整？」 一、核心問題：為什麼向量索引的「即時性」與「精準度」天生對立？ 1.1 RAG 系統的資料新鮮度危機 在企業 RAG（Retrieval-Augmented Generation）場景中，知識庫並非靜態的。法規文件每週更新、產品手冊每月改版、內部 SOP 隨業務調整。當 AI Agent 仰賴向量檢索來回答問題時，索引延遲（Index Lag）直接等同於「AI 在說謊」。 典型的痛點數字： 文件刪除後，向量索引平均滯後 4–8 小時才能同步 在此期間，Agent 回答基於已廢棄文件的機率高達 23% 企業客戶每月因 AI 給出過期資訊而提交的客訴工單：平均 340 件 1.2 三重矛盾的根本原因 矛盾一：即時性 vs. 批次效率 ┌────────────────────────────────────────────┐ │ 即時更新：每次文件變更立即寫入向量索引 │ │ 優點：延遲 < 30 秒 │ │ 缺點：HNSW 圖節點連結逐漸失衡（Graph Drift）│ │ 每 10K 次增量更新後，RECALL@10 下降約 8%│ └────────────────────────────────────────────┘ 矛盾二：完整重建 vs.