昨天我們先停下來處理 Workflow 的錯誤問題，學會從每個 Node 的 Input、Output 慢慢找出問題。

但目前做的 AI 客服分類系統，幾乎都是：

收到一筆資料 → AI 分類 → 執行下一步

這讓我想到，如果今天不是一筆，而是一次有很多筆資料呢？

例如 Google Sheets 裡已經累積了很多使用者留言：

系統完全無法登入
請問要怎麼修改密碼？
希望增加深色模式
APP 一直閃退
可以新增搜尋功能嗎？

難道要自己一筆一筆丟給 AI？

所以今天想來了解 n8n 怎麼處理：

多筆資料與批次處理。

n8n 裡的資料不一定只有一筆

前面為了方便理解，我們大部分都使用單筆 JSON。

例如：

{
  "text": "系統目前無法登入"
}

但實際使用時，前一個 Node 可能一次取得很多筆資料。

例如：

[
  {
    "text": "系統完全無法登入"
  },
  {
    "text": "請問如何修改密碼？"
  },
  {
    "text": "希望增加深色模式"
  }
]

也就是：

一個 Node → 輸出多個 Items

這裡的 Item 可以先簡單理解成「一筆資料」。

所以如果有 10 筆使用者留言，就可能會有 10 個 Items。

Step 1：先準備多筆測試資料

今天不用一開始就測很多筆。

先準備 3 筆就好：

1. 系統完全無法登入，請立即處理！
2. 請問密碼要在哪裡修改？
3. 希望可以增加深色模式。

預期 AI 分類分別是：

這樣等一下比較容易確認每筆資料有沒有被正確處理。

圖 1　準備多筆測試資料

Step 2：觀察 n8n 的 Items

把多筆資料送進下一個 Node 後，可以注意 n8n 的 Input / Output。

以前可能只有：

1 item

今天則可能看到多個 Items。

點選不同 Item，就可以查看每一筆 JSON 的內容。

例如：

{
  "text": "請問密碼要在哪裡修改？"
}

另一筆則是：

{
  "text": "希望可以增加深色模式。"
}

圖 2　在 n8n 中查看多筆 Items

做到這裡，我覺得 Item 可以先記成：

n8n Workflow 中正在流動的一筆資料。

Step 3：把多筆資料交給後面的 Node

n8n 很方便的一點是，許多 Node 本來就是以 Items 的方式處理資料。

概念上可以想成：

Item 1 ─┐
Item 2 ─┼→ Node → 處理結果
Item 3 ─┘

所以不一定每次都要自己寫迴圈。

例如三筆客服訊息經過 AI 分類後，希望得到：

系統完全無法登入
→ urgent

請問如何修改密碼？
→ question

希望增加深色模式
→ suggestion

接著再交給 Switch Node。

圖 3　多筆資料經過 AI 分類後的輸出

那為什麼還需要「批次處理」？

如果只有 3 筆資料，一次處理可能沒有什麼問題。

但假設今天突然有：

100 筆、500 筆，甚至更多資料

而且每一筆都需要呼叫 AI 或外部 API，就需要開始考慮：

執行時間

API 使用限制

AI 使用成本

外部服務可以承受多少請求

發生錯誤後要怎麼處理

這時候「全部一起處理」不一定是最好的方式。

所以可以把大量資料拆成比較小的批次。

例如：

100 筆資料
    ↓
每次處理 10 筆
    ↓
第 1 批
    ↓
第 2 批
    ↓
第 3 批
   ...
    ↓
處理完成

這就是我今天想理解的 Batch Processing（批次處理）。

Step 4：認識 Loop Over Items

在需要控制資料分批或逐批處理的情況下，可以使用 n8n 的 Loop Over Items。

概念就是：

把收到的資料按照設定的數量分批處理。

例如有 10 筆資料。

如果設定：

Batch Size = 2

就可以理解成：

第 1 批 → 2 筆
第 2 批 → 2 筆
第 3 批 → 2 筆
第 4 批 → 2 筆
第 5 批 → 2 筆

圖 4　使用 Loop Over Items 設定批次處理

今天不用一開始就真的準備 100 筆。

用 3～5 筆資料測試，就已經可以看出資料如何一批一批往下執行。

Step 5：把 AI 放進批次流程

接著可以把前面的 AI 分類接進來。

概念變成：

多筆客服資料
      ↓
Loop Over Items
      ↓
     AI
      ↓
分類 + 摘要
      ↓
   Switch
 ↙    ↓    ↘
urgent question suggestion

例如一次取得很多筆客服訊息後，就讓 Workflow 依序處理。

每一筆都經過：

AI 理解 → 分類 → Switch 分流

這樣就不用自己一筆一筆複製訊息給 AI。

Step 6：把結果存進 Google Sheets

今天也可以把最後結果重新接到 Google Sheets。

假設原本有：

3 筆使用者訊息

處理完成後，希望 Google Sheets 自動出現：

圖 5　多筆客服訊息處理完成後寫入 Google Sheets

實際執行後，三筆資料皆成功經過批次處理，其中一筆 urgent 進入 Email 通知流程，另外兩筆 question 與 suggestion 則成功進入 Google Sheets 儲存流程。

如果每一筆都有成功新增，就代表多筆資料的流程已經跑起來了。

批次處理不代表越小越好

一開始我可能會覺得：

「那每次只處理 1 筆不是最安全嗎？」

但這也不一定。

如果資料非常多，每次只處理一筆可能讓整個 Workflow 花更長時間。

反過來，如果一次處理太多，也可能讓外部服務壓力增加。

所以 Batch Size 沒有一個固定答案，而是要看：

資料量、API 限制、執行速度以及實際使用情況。

今天先理解這個概念就好，不需要急著找到「最完美」的 Batch Size。

今天跟昨天其實有關係

昨天學的是「錯誤處理」，今天學「大量資料」。

兩個其實很有關係。

假設一次處理 100 筆資料，其中第 53 筆出錯。

這時候就會出現：

前面 52 筆怎麼辦？

第 53 筆為什麼失敗？

後面的資料還要不要繼續？

要不要記錄失敗的資料？

所以 Workflow 資料量越大，Day 18 學到的除錯和錯誤處理也會越重要。

今日小結

今天最大的收穫，是開始把 n8n 的資料從：

「一筆 JSON」

改成：

「很多個 Items 在 Workflow 裡流動」

也認識了批次處理的概念。

以前的 AI 客服系統比較像：

1 筆訊息
↓
AI
↓
分類

今天開始變成：

很多筆訊息
↓
分批處理
↓
AI
↓
每筆分類
↓
儲存結果

這讓 Workflow 更接近實際使用的情況，因為真正的系統通常不會永遠只有一筆資料。

不過目前這些資料主要還是我們自己準備，或從 Webhook 傳進來。

下一步我想讓 Workflow 可以主動去跟其他服務「拿資料」。

這時候就會遇到一個前面一直提到、但還沒有真正深入使用的東西：

API