[AI 分享] RAG知識庫更新機制

 [AI 分享] RAG知識庫更新機制

摘要 : 生產級RAG文件更新不應做Chunk局部替換，而應以文件為單位先刪後增，並結合雜湊、輪詢或事件驅動確保更新可靠。

內容:

在面試或實務場景中，若被問到RAG知識庫上線後文件更新怎麼處理，不能簡單回答「只更新變動的Chunk即可」。這種說法通常代表對生產級RAG的理解還不夠深入。因為文件進入知識庫之前，會先被切分成多個Chunk，再做Embedding後寫入向量庫；只要原文改動一小段，整體Chunk的邊界與數量都有可能改變，原本的第3個Chunk，更新後可能變成第3和第4個Chunk的一部分，因此很難穩定地只更新某一個Chunk。

在真實的生產環境中，更穩定可靠的做法是「先刪後增」。只要系統偵測到某篇文件被修改，就先刪除該文件在向量庫中對應的所有舊Chunk，再用新版本文件重新切分、重新Embedding，最後重新寫入向量庫。這樣雖然看起來較粗暴，但能有效避免舊內容殘留、新舊資訊混雜，導致檢索結果錯亂的問題。很多工程設計追求的不是最精細，而是最可控。

要實現這套更新機制，系統必須先能自動知道哪篇文件發生了變化。常見做法是為每篇文件計算內容雜湊值，首次入庫時記錄文件ID、內容Hash，以及對應的Chunk ID。之後系統再次掃描文件時，重新計算Hash，若Hash未變就直接跳過；若Hash改變，就表示內容有更新，觸發重新處理流程。實務上還可以先用最後修改時間做粗篩，只有修改時間變動的文件才進一步計算Hash，以降低大規模文件掃描成本。

此外，文件ID與Chunk ID之間的關聯設計一開始就要規劃好，否則之後很難準確刪除某篇文件對應的全部Chunk。常見做法有兩種：一種是直接在Chunk ID中包含文件ID，例如 product-manual-chunk-001；另一種則是在Chunk的metadata中保存 source-doc-id，方便向量庫依文件ID做批次刪除。這是知識庫可維護性的關鍵基礎設計。

文件更新的觸發方式通常分為兩類。第一類是定時輪詢，例如每小時或每天固定掃描一次資料來源，檢查哪些文件新增、修改或刪除。這種方式簡單易做，適合內部知識庫或對即時性要求不高的場景，但缺點是同步會有延遲。第二類是事件驅動，也就是當文件發生變更時，由資料來源透過 webhook、Kafka、RabbitMQ 等方式主動通知知識庫更新服務。這種模式的優勢是即時性高，適合政策更新、新聞發布、客服知識庫等需要快速同步的應用。

除了新增與修改，文件刪除也是非常重要的一環。若原始文件已下線，但向量庫內的舊Chunk沒有同步刪除，就會形成所謂的「殭屍Chunk」，導致系統仍可能檢索出過期甚至錯誤資訊。在金融、醫療、合規、法務等高風險場景，這類問題可能帶來嚴重後果。因此，RAG知識庫更新本質上就是穩定處理三件事：新增、修改、刪除，其中最需要注意的就是修改與刪除時的資料清理完整性。

至於是否需要定期全量重建知識庫，答案是可以，但不應作為日常方案。全量重建適合知識庫規模小，或遇到重大變更，例如更換Embedding模型、調整Chunk策略等，因為此時新舊向量本身已不相容，只能全面重建。若平時文件更新頻繁，仍以增量更新為主會更符合成本與效率。

如果知識庫應用在高風險、高價值場景，例如金融問答、醫療問答、企業合規系統，還可以進一步採用灰度更新策略。做法是同時保留舊版與新版知識庫，分別標記版本，例如 old 與 new。新版本完成入庫後，先用測試問題驗證品質，確認無誤後再切換線上檢索條件；若新版本異常，也能快速回退。這種方式類似軟體部署中的藍綠發布，能大幅提升更新的安全性與可控性。

總結來說，生產級RAG知識庫更新的核心，不是怎麼精細地更新某一個Chunk，而是如何可靠地感知文件變化、完整刪除舊資料，並穩定地將新資料重新寫入向量庫。這正是生產級RAG與Demo級RAG之間最本質的差別。