超越基礎 RAG：AI 工作流結合向量資料庫的四種實務架構
大型語言模型的上下文視窗愈來愈長，並沒有讓檢索增強生成（RAG）失去價值。真正改變的是問題本身：團隊不再只問「要不要使用向量資料庫」，而是必須決定 哪些資料該在什麼時候進入模型上下文、如何保持新鮮，以及檢索失敗時該怎麼處理。
固定字數切片、取回 Top-K 結果，再一次塞進 Prompt 的基礎做法，仍適合資料量小、問題單純的情境；但面對跨文件推理、持續更新的資料與長時間運作的 Agent，它就容易暴露限制。以下整理四種值得理解的實務架構，也說明哪些說法有實驗依據、哪些只是需要自行驗證的工程選擇。
長上下文無法取代檢索
把整份知識庫直接放進長上下文，看似能避開切片與檢索，實際上仍有三個問題：
- 資訊位置會影響召回：研究論文 Lost in the Middle 發現，相關資訊位於長上下文中段時，部分模型的表現會比資訊位於開頭或結尾差。
- 成本與延遲會隨輸入增加：每次請求都重送大量內容，會提高輸入成本與首字延遲；即使有快取，也不代表所有資料都值得放進每一次請求。
- 資料仍需要生命週期管理：長上下文只解決單次請求能放多少內容，沒有自動處理資料更新、刪除、權限與跨工作階段記憶。
因此，長上下文與檢索不是二選一。較合理的做法是先用檢索縮小候選範圍，再讓模型在足夠但受控的上下文中推理。
Contextual Retrieval 解決切片失去脈絡
傳統切片常把主詞、時間或文件名稱留在相鄰段落，導致單一 Chunk 難以被正確搜尋。Anthropic 的 Contextual Retrieval 會先為每個 Chunk 補上一小段與整份文件相關的說明，再分別建立向量索引與 BM25 索引。
Anthropic 公布的數字需要連同測試條件一起看。在其涵蓋程式碼、論文與文本等資料集的實驗中，以 Top-20 是否找回相關片段作為指標：
- 只加入 Contextual Embeddings，檢索失敗率由 5.7% 降至 3.7%，相對降低 35%。
- 再結合 Contextual BM25，失敗率降至 2.9%，相對降低 49%。
- 加入 Reranker 後可進一步改善，但也會增加執行時延遲與成本。
這些結果證明「在切片前補入文件脈絡」值得測試，但不能直接推論每個知識庫都會得到相同幅度。Chunk 大小、語言、Embedding 模型、Top-K 與評估資料集都會影響結果。
架構一：讓 Agent 決定何時及如何檢索
基礎 RAG 的路徑固定；Agentic RAG 則把檢索器包裝成工具，讓模型或工作流依問題選擇是否查詢、如何改寫查詢，以及結果不足時是否重試。
LangGraph 的官方 Agentic RAG 教學 示範了幾個典型節點：
- 判斷目前問題是否需要使用 Retriever。
- 取回候選文件。
- 評估文件與問題是否相關。
- 相關性不足時改寫問題並重新檢索。
- 有足夠證據後生成答案。
實務上還可以加入混合檢索：
- Dense Retrieval：用向量相似度處理概念、語意與近義表達。
- Sparse Retrieval：用 BM25 或倒排索引處理產品名稱、錯誤碼與精確關鍵字。
- Reranking：讓較精細的模型重新排序候選片段，再把較少但更相關的內容交給生成模型。
「先取回 50 筆，再選 5 筆」只能當成示例，不是通用設定。候選數量應由離線評估決定；取回太少可能漏掉答案，取回太多則會增加延遲，也可能把不相關內容帶回上下文。
Agentic RAG 適合查詢路徑會變動、需要多個資料來源或必須自我修正的情境。代價是流程更難預測，所以需要限制最大重試次數、工具預算與逾時，並保留每一步的檢索與判斷紀錄。
架構二：向量檢索與 GraphRAG 分工
向量搜尋擅長找出語意接近的段落，卻不擅長保證完整的關係鏈。例如「某項變更會透過哪些服務影響其他團隊」涉及明確的依賴方向、實體與多跳關係，不能只靠相似度排序。
這類問題可以把兩種檢索方式分開處理：
- 向量索引：尋找與問題最相關的非結構化內容。
- 知識圖譜：查詢實體、關係、路徑、聚合與影響範圍。
- 查詢路由：依問題類型選擇向量、圖查詢，或先以向量縮小範圍再展開圖關係。
Microsoft GraphRAG 的重點不只是「把向量資料庫旁邊再放一套圖資料庫」，而是從非結構化文本抽取實體與關係，建立社群結構與摘要，以支援跨整個資料集的全域問題。
LazyGraphRAG 不是完全免索引
LazyGraphRAG 的確把大量 LLM 工作延後到查詢階段，但它並非等到有人提問才建立所有關係。索引階段仍會用自然語言處理抽取名詞、統計概念共現關係，並建立階層式社群；查詢時才使用 LLM 拆解問題、判斷相關片段並抽取主張。
是否導入 GraphRAG，應先看問題是否真的需要多跳關係、全域主題或圖聚合。如果只是 FAQ、客服文件或單一產品手冊，混合向量與關鍵字檢索通常更容易維護。
架構三：把 Agent 記憶視為資料生命週期
向量資料庫可以找回語意相近的內容，但不會自動理解哪一條記憶已過期、哪一條只在目前任務有效，也不會替應用決定何時應刪除個人資料。完整的 Agent 記憶層需要同時處理範圍、時間、更新與治理。
常見產品也沒有採用完全相同的「三層記憶」模型：
- Mem0 以 Conversation、Session、User 與 Organizational Memory 區分生命週期與共享範圍。
- Letta 區分會持續放在上下文中的 Memory Blocks、可搜尋的 Files、Archival Memory，以及外部 RAG。
- Zep 使用具時間資訊的 Context Graph；新資料推翻舊事實時，會標記舊關係失效並保留歷史，而不是只把相似文字再寫入向量庫。
因此，比「選哪套記憶框架」更重要的是先定義下列規則：
- 作用範圍：這筆資料只屬於目前回合、工作階段、單一使用者，還是整個組織？
- 有效時間：它何時開始成立，何時過期，新資料是否會覆蓋舊資料？
- 召回策略：哪些記憶必須永遠在上下文中，哪些只在相關時才搜尋？
- 刪除與權限：使用者能否查看、修正或刪除記憶？不同 Agent 是否能共享？
Redis、關聯式資料庫、向量資料庫或圖資料庫都可能出現在這一層，但它們是實作選項，不是固定配方。
架構四：AST 切片與 CDC 增量索引
程式碼庫與持續變動的業務資料，除了要能搜尋，還要避免檢索到已刪除或過期的內容。這需要同時改善切片邊界與同步管線。
用語法結構切分程式碼
按固定字元數切割程式碼，可能把函式簽名、類別或條件分支拆開。較穩定的做法是利用抽象語法樹或具體語法樹，以函式、類別與模組作為主要邊界，再針對過大的節點做第二層切分。
Tree-sitter 能為多種程式語言建立語法樹，並在原始碼變更後增量更新。建立向量時，可以把檔案路徑、符號名稱、函式簽名、語言與版本識別碼一起寫入 Metadata，讓後續搜尋可以過濾與追蹤來源。
語法樹只能幫助系統理解程式碼結構，不能保證每個 Chunk 都具備完整語意。跨函式呼叫、型別定義與設定檔關係，仍可能需要額外的符號圖或相依性分析。
用 CDC 維持索引新鮮度
對持續更新的資料庫，可以透過 PostgreSQL Logical Decoding、Debezium PostgreSQL Connector 等方式捕捉已提交的 Insert、Update 與 Delete，送進訊息佇列或背景 Worker，再執行重新切片、Embedding、Upsert 或 Delete。
這是一種事件驅動同步，而不是「一定在數秒內完成」的保證。實際延遲取決於事件積壓、Embedding 服務、批次大小、重試與向量資料庫寫入速度。Qdrant 的同步指南 也把事件驅動、批次同步與應用程式雙寫列為不同策略，各自有延遲、複雜度與一致性取捨。
要避免索引悄悄失真，管線至少需要：
- 穩定且可重複使用的文件 ID，讓 Upsert 與 Delete 具備冪等性。
- 版本或時間戳記，防止較舊事件覆蓋較新內容。
- 失敗重試與待處理佇列，避免 Embedding 服務暫時失效就遺失更新。
- 定期對帳，檢查來源資料與向量索引是否一致。
向量資料庫與索引怎麼選
產品名稱不是第一個決策點。先看既有資料在哪裡、查詢量、更新頻率、是否需要圖關係，以及團隊願意維護多少基礎設施。
| 選擇方向 | 代表方案 | 適合情境 | 主要取捨 |
|---|---|---|---|
| 沿用 PostgreSQL | pgvector | 資料已在 PostgreSQL，希望向量與業務資料一起交易及備份 | 維運單純，但大型獨立搜尋服務仍需評估索引建置、記憶體與水平擴充 |
| 專用向量搜尋服務 | Qdrant、Pinecone、Milvus、Weaviate | 向量搜尋是獨立服務，需要混合搜尋、Payload 過濾或獨立擴充 | 功能完整，但增加資料同步與另一套服務的維運成本 |
| 圖關係優先 | Neo4j | 問題需要多跳關係、圖路徑、聚合或 GraphRAG | 能結合向量索引與圖查詢，但資料建模與圖更新成本較高 |
pgvector 支援精確搜尋、HNSW 與 IVFFlat，適合先在既有 PostgreSQL 中驗證需求。Weaviate 雖支援物件 Cross-reference，但其官方最佳實務明確指出它不適合圖狀查詢或 Join，因此不應直接和圖資料庫歸為同一類。
HNSW、DiskANN 與量化
HNSW 與 DiskANN 都是加速向量相似度搜尋的索引方法；差別在於前者通常以記憶體中的多層圖結構換取速度，後者則針對索引大到放不進記憶體、需要使用 SSD 的情境設計。量化不是另一種索引，而是壓縮向量數值、降低儲存與運算成本的技術。
- HNSW 是目前常見的近似最近鄰索引，通常能取得不錯的速度與召回率，但圖結構會占用較多記憶體。它是通用選項，不是所有資料集的絕對最佳答案。
- DiskANN 把主要索引放在磁碟，適合資料超過可用記憶體的情境；代價是更依賴磁碟 I/O、快取與產品支援。Milvus 的 DiskANN 文件也將它定位為超過 RAM 容量時的磁碟型索引。
- Scalar Quantization 將每個向量維度由 32 位元浮點數壓縮為 8 位元，在向量表示本身可達四倍壓縮，也就是減少 75%。Qdrant 的實驗顯示其誤差通常低於 1%，但官方同時強調結果取決於資料與參數。
- Binary Quantization 可把每個維度縮成 1 位元，向量表示最多縮小 32 倍，但較適合高維度且分布接近中心化的向量，通常還要搭配 Oversampling 與 Rescoring 才能維持召回率。
這些倍率描述的是向量表示，不等於整個服務的總記憶體一定等比例下降。Payload、HNSW 圖、快取、原始向量與程序本身仍會占用空間。
上線前應先驗證什麼
RAG 架構不能只用「回答看起來合理」驗收。至少應建立一組包含正確來源的測試問題，持續量測：
- Recall@K：正確證據是否出現在前 K 個檢索結果中。
- 答案忠實度：回答中的主張是否能由取回內容支持。
- 延遲與成本：檢索、Reranking、模型生成各花多少時間與費用。
- 資料新鮮度：來源更新或刪除後，要多久才不會再取回舊內容。
- 失敗行為：證據不足時，系統是否會明確說明，而不是自行補完。
先以基礎向量加關鍵字檢索建立可量測的 Baseline，再逐步加入 Contextual Retrieval、Reranker、Agent 或 GraphRAG，才能知道複雜度是否真的換來改善。
結語
向量資料庫並沒有因長上下文而過時，但它也不是 AI 工作流的萬用答案。Agentic RAG 解決查詢路徑變動，GraphRAG 處理關係與全域問題，記憶層管理跨時間的資料，而 AST 與 CDC 則讓程式碼及持續更新的知識保持可用。
真正重要的不是把所有技術都裝進同一套系統，而是先定義問題、建立評估資料，再選擇足以通過驗證的最小架構。