n
n8n rag rag pipeline 企業知識庫 metadata 文件切片

N8N RAG 文件切片與 Metadata 怎麼設計，檢索準確度差最多在這裡

這篇聚焦 n8n rag 最常出錯的文件切片與 metadata 設計，從 chunk 長度、overlap、欄位規劃到重建索引流程逐步拆解，幫你把企業知識庫做得更準、更好維護，也能回接主流程快速落地。

N8NMarket 2026年5月3日

N8N RAG 的準確度，很多時候不是輸在模型，而是輸在切片和 metadata。chunk 切錯、欄位亂放，檢索就會把不該回來的內容撈進來，答案自然越回越歪。

我看過一個最典型的案例：同一家公司把「退款規則」「代理商政策」「內部例外流程」全丟進同一個索引，沒有部門欄位，結果客服問退費，系統抓到的是渠道合作條款。模型不是不會答，是你餵錯資料。

如果你還沒看過整體架構，先回主文補全流程：https://n8nstart.cc/blog/n8n-rag-enterprise-knowledge

為什麼切片與 metadata 會決定成敗

RAG 的檢索邏輯很簡單：先找相近內容，再把它交給模型整理。
問題是「相近」不等於「正確」。

例如下面這兩段文字：

  • 企業版客戶退款需主管核准
  • 代理商合作終止後不適用退款條款

它們都跟「退款」很像。
如果你的 metadata 沒有標出客戶類型、產品線或文件類別，向量搜尋很容易把兩段一起撈回來。

所以切片和 metadata 的任務其實不同：

  • 切片負責保留語意單位
  • metadata 負責幫你縮小業務範圍

兩個都做好，檢索才會穩。

文件切片怎麼切，才不會一開始就失真

原則一：以語意段落為單位，不要只看字數

很多人第一次做 n8n rag，會直接用固定長度切，例如每 500 tokens 一段。
這樣很快，但不一定準。

如果一份 SOP 剛好把「條件」切在上一段，「例外」切在下一段，模型拿到其中一片時就會少一截意思。

比較好的做法是：

  • 先按標題、章節、條列切大段
  • 再按 token 長度做二次切分
  • 保留前後 overlap，避免語意斷裂

原則二：不同文件類型，用不同 chunk 尺寸

這裡不要追求單一規格打天下。
實務上可以先這樣分：

  • FAQ：300 到 500 tokens
  • SOP：400 到 700 tokens
  • 技術文件：600 到 900 tokens
  • 合約條款：700 到 1000 tokens

原因很直接。
FAQ 本來就短，切太大只是把多餘背景塞進來。
技術文件和條款上下文較強，切太小反而破壞完整性。

原則三：overlap 要有，但不要過量

常見做法是 50 到 120 tokens overlap。
太少，語意容易斷。
太多，會讓相似內容重複命中，增加檢索噪音和儲存成本。

如果你發現同一份文件常有 3 到 4 個相鄰 chunk 一起被抓回來，通常代表 overlap 太大，或切片粒度太細。

metadata 欄位怎麼設計，才真的能幫檢索

很多人知道 metadata 很重要，但欄位設計只放 title 和 source，這其實不夠。

對企業知識庫來說，至少先規劃這幾類：

1. 文件識別欄位

  • doc_id
  • chunk_id
  • title
  • source
  • url

這組欄位的用途是追蹤與引用。
回答錯了，你要知道是哪一份文件、哪一段 chunk 被撈回來。

2. 業務範圍欄位

  • department
  • product
  • region
  • customer_type
  • language

這組欄位的用途是檢索過濾。
沒有它，客服和代理商、台灣和海外、中文和英文內容很容易混在一起。

3. 版本與時效欄位

  • updated_at
  • version
  • status
  • valid_from
  • valid_to

這組欄位的用途是控管新舊資料。
很多 RAG 不是找不到答案，而是找到過期答案。

4. 文件類型欄位

  • doc_type
  • topic
  • sensitivity

這組欄位對後續權限管理很有用。
例如內部 HR 文件與公開產品文件，不該被同一種查詢策略處理。

在 n8n 裡怎麼落地這套設計

如果你從工作流角度思考，這件事沒有想像中複雜。
你可以在建庫線裡分 4 段做。

第 1 段：先抽文字，再清洗

常用節點會是：

  • Google Drive 或 HTTP Request
  • Extract from File
  • Code

這段主要處理：

  • 移除頁碼、頁首頁尾
  • 合併被硬切斷的句子
  • 統一換行與空白

如果文件品質很亂，先不要急著 embedding。
文字還沒洗乾淨時，後面做再多優化都只是補破網。

第 2 段：產生 chunk 與 chunk_id

你可以在 Code 節點中先根據標題或段落切分，再補上：

  • chunk_id
  • chunk_index
  • token_estimate

chunk_id 很重要。
更新文件、刪除舊索引、追查錯誤時，你會一直用到它。

第 3 段：補 metadata

這一段通常用 Set 最直觀。
把來源系統裡已有的欄位，轉成向量資料庫可查的 metadata。

例如：

  • Drive 資料夾名稱對應 department
  • 檔名規則解析出 product
  • 文件日期寫進 updated_at

你會發現，很多資料其實本來就有，只是以前沒系統化整理。

第 4 段：寫入向量庫前先做驗證

正式寫入前，至少檢查三件事：

  1. content 不是空值
  2. doc_id、chunk_id 存在
  3. updated_at 格式一致

這一步很土，但很有用。
少了它，後面出現空 chunk、重複 chunk、無法刪舊索引的機率會高很多。

什麼情況該重建索引，而不是只增量更新

很多團隊一開始只想做增量更新，因為看起來比較省。
但不是每種變更都適合增量。

下面幾種情況，直接重建通常比較乾淨：

1. 切片規則改了

只要 chunk size 或 overlap 改動，舊 chunk 就跟新 chunk 不再可比。
這時硬混在一起，檢索品質通常會變差。

2. metadata 欄位補強了

如果你新增 product、region 這些關鍵 filter 欄位，舊資料沒有值，查詢時就會一半能篩、一半不能篩。這種情況直接重跑比較省事。

3. 文件大量改版

如果制度、價格表、政策一次更新一大批，增量更新很容易漏刪舊內容。
與其之後花時間除錯，不如直接整批重建。

怎麼檢查你的切片與 metadata 有沒有設錯

這裡提供一個很務實的檢查法，20 分鐘內就能知道方向對不對。

測試 10 個高頻問題

挑客服、業務或內訓最常問的 10 題，逐題檢查：

  • 撈回來的 chunk 是否屬於對的部門
  • 是否有過期文件混進來
  • top 3 結果裡是否至少有 1 個精準命中
  • 回答能不能附上正確來源

看錯誤長相，不只看正確率

比起只記「答對幾題」，更重要的是分辨錯誤類型：

  • 完全沒命中
  • 命中錯部門
  • 命中舊版本
  • 命中相近但不適用內容

不同錯誤，對應的修法不同。
沒命中通常是切片或 query rewrite。
命中錯部門，多半是 metadata filter。
命中舊版本，通常是同步與版本欄位設計有問題。

結論：先把 chunk 與 metadata 做乾淨，再談模型升級

如果你的 n8n rag 已經接上 LLM，答案還是常漂，先別急著換模型。
多數情況下，問題出在切片不穩、metadata 不夠、索引重建策略太鬆。

把這三件事補齊，檢索準度通常會先上一個台階。
之後再去調 prompt、換 embedding、加 rerank，效果才會疊得上去。

想看完整企業知識庫流程，回主文這裡：

https://n8nstart.cc/blog/n8n-rag-enterprise-knowledge

如果你想先用可修改模板起步，再按部門和文件類型微調，也可以直接逛 N8Nmarket 模板庫：

https://n8nstart.cc/templates

延伸閱讀：

FAQ

n8n rag 的 chunk size 要先設多少

沒有單一標準值，但企業知識庫可先從 400 到 800 tokens 起跑，再依 FAQ、SOP、技術文件分不同策略。重點不是數字漂亮，而是 chunk 能保留完整語意。

metadata 至少要放哪些欄位

最低建議包含 doc_id、title、source、updated_at，再加上對業務有幫助的 department、product、customer_type。只放標題和來源，通常不夠支撐穩定檢索。

什麼時候要整批重建索引

當你改了切片規則、補了重要 metadata 欄位，或文件大規模改版時，整批重建通常比增量更新更乾淨，也更容易維護。