前言
昨天盤點資料時,我們特別提到「資料量級」這個面向——這不只是為了了解資料,更是為了預備今天要處理的實際技術限制:AI 一次能處理的內容長度是有上限的。當某週事件特別多、資料量暴增時,如果沒有應對策略,範本很可能會出狀況。

一、什麼是 Token,為什麼它是一道實際存在的天花板
AI 模型並不是直接「讀懂」文字,而是先把輸入的文字拆解成一個一個的Token(詞元)——可以粗略理解為,一個 Token 大約對應一小段文字(中文常常一到兩個字算一個 Token,英文則大約一個單字或字根算一個 Token)。每個 AI 模型,對「一次對話能處理的 Token 總量」都有上限,這個上限包含了你輸入的所有內容(System Prompt、範例、原始資料)以及 AI 產出的回應。
這代表:你的 System Prompt 越長、範例越多、丟進去的原始資料越大,能留給 AI「回應」的空間就越少。如果總量超過上限,輕則內容被截斷、範例被忽略,重則整個請求直接失敗。
二、哪些東西在「偷偷佔用」你的 Token 額度
回顧前面幾天累積下來的範本內容,你會發現額度其實被瓜分到很多地方:

• System Prompt 本身:角色設定、Context、格式規則、防呆規則,這些累積下來可能已經不算短
• Few-shot 範例(Day 10):如果你放了 2-3 份完整範例,這部分的篇幅有時候甚至比規則本身還長
• 原始資料(User Prompt):這是最容易「爆量」的部分,尤其遇到事件特別多的那一週
  這也是為什麼 Day 10 特別提醒「範例不是越多越好」——因為範例、規則、資料,三者共同競爭同一份有限的額度,任何一項寫得太肥,都會擠壓到其他部分的空間。
  三、資料量爆表時的三種應對策略
  策略一:分段處理,再彙整
  如果單週資料量真的超出負荷,可以把資料拆成幾個批次,分別請 AI 整理成中間結果(例如先按事件類型分批摘要),最後再用一次額外的請求,把幾份中間結果彙整成最終報告。這種做法的代價是流程變複雜、需要多次呼叫,但好處是不會因為單次輸入過長而出問題。
  策略二:資料先做「摘要式」壓縮,再交給 AI
  如果資料裡有大量重複性高、細節不影響整體判斷的內容(例如同一類型的低風險事件重複出現很多筆),可以在丟給 AI 之前,先用程式或人工的方式做初步彙總(例如「本週共發生 15 起同類型低風險事件,均已自動化處理完畢」),而不是把 15 筆逐條細節都塞進去。這部分會在明天 Day 15 資料預處理裡更深入討論。
  策略三:精簡固定骨架的篇幅
  如果發現額度緊繃的根本原因不是資料,而是 System Prompt 本身(規則寫得太囉唆、範例放太多份),可以回頭檢視 Day 6-12 建立的規則,看看有沒有能濃縮、卻不失去精確度的空間——這也呼應 Day 4 談的變數化思維:骨架應該精煉,而不是越寫越肥大。
  四、怎麼判斷自己「快要爆表」?
  一個實用的習慣是:定期估算你的 System Prompt 加上一份典型週資料的大概篇幅,心裡對這個數字有個底,而不是等到真正出狀況才驚覺「怎麼這次沒處理完整」。你不需要精確計算 Token 數,但至少要對「這份東西大概多長」有基本敏感度——例如留意 AI 的回應是否常常在某個章節突然變得簡略、或明顯像是被截斷的樣子,這往往是額度緊繃的徵兆。
  五、今天的行動練習
  回顧昨天資料盤點時記錄的「一般情況資料量」,再對照你目前 System Prompt 草稿的篇幅(規則 + 範例),粗略評估一下:如果遇到資料量是平常兩到三倍的那一週,你的範本有沒有可能爆表?如果有疑慮,先想好你會採用今天提到的哪一種應對策略。

小結
今天談的是一個很實際、卻常被忽略的技術限制:AI 處理內容的空間不是無限的,而規則、範例、資料三者,都在競爭同一份有限額度。了解這個限制,才能在設計範本時預留彈性,而不是等到資料量爆表的那一週,才手忙腳亂地臨時想辦法。
下一篇,我們會更深入談資料預處理的具體技巧——在把資料交給 AI 之前,還能幫它做哪些「瘦身」,既節省篇幅,又能提高 AI 判斷的準確度。