先把新鮮度定義成可驗證的契約
向量索引是從文件、產品資料、知識庫或交易系統衍生出的查詢結構，不應被視為唯一資料來源。設計更新策略時，我們會區分四個時間點：來源資料何時變更、事件何時進入管線、向量何時寫入，以及新內容何時能被查詢。只看排程是否成功，無法回答使用者實際讀到的資料是否已經過期。
新鮮度需求也不應套用到所有內容。客服公告、庫存狀態、存取權限與事故處理文件，通常比歷史報告或封存手冊更需要快速同步。可以先依內容類型定義可接受的延遲，以及新增、修改、刪除和權限變更各自的處理規則。若權限資訊可能落後，檢索結果就不應只依賴索引內的中繼資料，還要在回傳內容前向權威系統重新驗證。
即時更新：低延遲背後是分散式系統問題
即時模式通常由 CDC、outbox、webhook 或應用事件觸發，再經過訊息佇列、內容解析、切塊、嵌入模型與向量資料庫的 upsert。來源系統的交易不應同步等待整條索引管線完成；較穩健的做法是先可靠地記錄事件，再由背景工作處理。如此一來，嵌入服務或向量資料庫暫時失效時，不會阻塞 ERP、CRM 或內容管理系統的主要操作。
真正困難的部分是重送、亂序與刪除。同一份文件需要穩定識別碼、單調遞增的來源版本，以及可重複執行的寫入操作。消費者應忽略較舊事件，並把刪除記錄成可追蹤的 tombstone，而不是假設文件從來源快照消失後，舊向量自然會被清除。切塊方式改變時，也要先移除前一版本產生的 chunk，否則搜尋結果可能同時包含新舊內容。這種模式適合變動頻繁且陳舊資料會直接影響工作流程的場景，但代價是更多常駐元件、尖峰流量控制與細緻的監控。
批次更新：簡單可控，但不能只是定時重跑
批次模式可定期讀取完整快照，或依時間戳、序號與變更表擷取增量資料。它適合更新集中、來源不支援事件通知，或業務能接受固定新鮮度窗口的內容。批次工作應在開始時固定查詢邊界，記錄 watermark，並在成功後才推進檢查點。否則長時間執行的工作可能漏掉執行期間產生的變更，或在重試時重複處理不一致的範圍。
完整重建不應直接覆寫目前供查詢的索引。較安全的方式是在新 namespace 或新 generation 中建置、驗證文件數量與抽樣查詢，再透過 alias 或應用設定一次切換。嵌入模型、向量維度或切塊規則改版時尤其應採用這種方式，因為不同模型產生的向量不應混在同一索引空間。批次設計仍須處理失敗續跑、孤兒向量、刪除清單與工作時間重疊；排程較少不代表一致性問題會自動消失。
混合模式：快速路徑加上週期性對帳
多數企業系統最後會採用混合模式：高優先級變更走事件管線，完整或增量批次則定期對帳。新增公告、撤銷文件和權限異動可以快速生效；批次工作負責找回事故期間遺漏的事件、修正解析失敗，並清理來源已不存在的向量。這種架構把即時管線視為速度層，把批次工作視為正確性與修復層。
混合模式最大的風險是兩條路徑彼此覆寫。例如批次讀到較早的快照，卻在較新的即時事件之後完成寫入。每筆索引資料都應攜帶來源版本、內容雜湊、嵌入模型版本與索引時間；寫入端則必須拒絕版本倒退。若向量資料庫不支援條件式更新，版本判斷應在索引服務或外部狀態表完成。模型遷移期間可以建立新的索引 generation，待查詢驗證通過後切換，避免即時與批次工作把不同模型的向量混合。
- 新鮮度：先問資料最久可以延遲多久，以及哪些變更必須優先處理，而不是先選技術。
- 變更型態：觀察更新量是否穩定、集中或具有尖峰；事件佇列必須能吸收來源突發流量。
- 來源能力：確認是否有 CDC、可靠 webhook、修改時間或可查詢的變更紀錄；來源限制往往決定可行方案。
- 一致性風險：刪除、權限、法規內容及工作指令通常需要比一般知識文章更嚴格的保護。
- 成本邊界：把解析、嵌入、向量寫入、重建與重試成本一起估算，並避免未變更內容反覆產生向量。
- 可復原性：保留 dead-letter queue、watermark、版本記錄與可重播事件，才能在失敗後精確補資料。
無論選擇哪一種模式，都應監控端到端索引延遲、佇列積壓、失敗與重試、來源和索引的文件差異，以及查詢抽樣結果。最實用的策略通常不是追求所有資料零延遲，而是讓重要資料快速更新、一般資料有效率地處理，並確保任何遺漏都能被發現與修復。