用 n8n 建出可上線的向量資料庫

如果你先用本機向量庫做 RAG，常會在真實流量下碰到延遲、篩選或維運瓶頸。這篇會帶你把資料庫選型、索引、寫入與查詢接成一條可交付的 n8n 流程。

這篇教你為 RAG 選擇向量資料庫，並用 n8n 串起可上線的索引、寫入與檢索流程。

開始之前

• 一個 n8n 文件 介紹的帳號，或自架 n8n 服務
• 一個向量資料庫帳號或本機實例，例如 Pinecone 文件 與 Pinecone GitHub，或 Qdrant 文件 與 Qdrant GitHub
• 一組 LLM 或 embedding 供應商 API key，例如 OpenAI 或相容模型服務
• Node 20+，如果你要跑本機腳本或自訂工具
• PostgreSQL 15+，如果你要用 pgvector
• 一批範例文件、切塊規則與要搜尋的 metadata 欄位

Step 1: 定義檢索工作負載

先把需求寫清楚，才能避免選到只適合 demo 的資料庫。你要先判斷系統是偏低延遲語意搜尋、混合關鍵字加向量檢索、強 metadata 篩選，還是超大規模儲存。

請整理三個產出：向量數量預估、篩選複雜度、以及新 embedding 的更新頻率。這份內容會直接決定你該偏向 pgvector、Qdrant、Weaviate、Milvus 或 Pinecone。

你應該看到一份簡短需求筆記，裡面明確寫出規模、延遲目標與篩選需求。只要你能說出為什麼要託管服務或自架系統，這一步就完成了。

Step 2: 選定向量資料庫

第二個產出是一個主選方案與一個備援方案。把工具和你的技術棧對齊：Pinecone 適合零維運託管搜尋，pgvector 適合已經有 PostgreSQL 的系統，Qdrant 適合快速 payload 篩選，Weaviate 適合混合搜尋，Milvus 適合超大規模部署，Chroma 適合本機開發，Redis 適合記憶體速度，Elasticsearch 適合企業混合搜尋，SingleStore 適合 SQL 與向量統一，Faiss 適合研究與離線批次作業。

原則很簡單，選能滿足規模上限與篩選需求的最小工具。若團隊已經有 Postgres，pgvector 能減少元件數；若你需要獨立向量引擎與強篩選，Qdrant 是很實用的預設值。

你應該看到一個被選中的資料庫，以及一段淘汰其他選項的理由。理由若提到維運成本、記憶體用量或混合搜尋，就表示方向正確。

Step 3: 建立索引與 schema

第三個產出是可存 embeddings 與 metadata 的資料結構。先建立 collection 或 table，再定義向量維度、索引型別與可篩選欄位，之後才開始灌正式資料。

-- PostgreSQL 15+ 搭配 pgvector 與 HNSW 的範例
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  metadata JSONB NOT NULL,
  embedding vector(1536) NOT NULL
);

CREATE INDEX documents_embedding_hnsw
ON documents
USING hnsw (embedding vector_cosine_ops);

CREATE INDEX documents_metadata_gin
ON documents
USING gin (metadata);

你應該看到 table 或 collection 成功建立，並且有一個符合查詢模式的索引。也要確認 embedding 維度和模型輸出一致，不然後面的寫入會直接失敗。

Step 4: 組出 n8n 匯入流程

第四個產出是從原始文件到向量寫入的自動化路徑。把 trigger、文件載入、切塊、embedding 節點，以及你選的向量資料庫節點接起來，讓每份新文件都走同一條流程。

切塊大小要固定，metadata 也要保留來源、標題、時間戳與存取權限標籤。n8n 可以同時負責 ingest、chunking、embedding 與 retrieval，這樣就不必再維護一堆分散腳本。

你應該看到第一輪測試後，向量庫中出現新紀錄。若資料庫裡能看到帶有 metadata 與 embeddings 的 chunk，表示匯入流程已經可用。

Step 5: 驗證檢索並調整延遲

第五個產出是一條可預期的查詢路徑。把幾個真實問題送進工作流，對照回傳 chunk 與原始文件，檢查 filters、排序與新鮮度是否符合預期。

調整時一次只改一個變數，例如索引設定、chunk 大小、top-k 或篩選策略。HNSW 可以提升搜尋速度，但記憶體也可能增加；pgvector 的 SQL 篩選很方便，但超大工作負載可能更適合專用向量引擎。

你應該看到相關答案、可接受的回應時間，以及被 metadata 篩掉的錯誤文件。若結果過舊、太慢或太雜，就回頭檢查索引與匯入順序。

常見錯誤

• 為了不需要的規模選了太重的資料庫。修法：先以目前工作負載為準，再選能滿足延遲與篩選需求的最小系統。
• 一開始沒設計 metadata。修法：從第一天就存 source、tenant、permission、document type，避免之後重寫。
• embedding 維度設錯。修法：先確認模型輸出大小，再建立 schema，並讓匯入與查詢工作都保持一致。

接下來可以看什麼

當這條流程跑通後，可以再加上 reranking、hybrid search、access control 與評估任務，持續量化檢索品質。之後你也能在 n8n 裡替換向量後端，跟著規模或維運需求一起演進。