目的
由於各LLM單次能處理的訊息長度，在Caveduck平臺上從未公開。且角色扮演框架也會自動插入一些內容，難以獲得精確答案。
本次測試旨在驗證各LLM在角色扮演框架下，可確保「單次完整輸入」的下限，並篩檢異常截斷現象。
方法
- 設計：編造大量無實際語意的對聯，並為之編號，總計400條。目的是避免模型根據統計學預測取巧，確保截斷點可明確反映其處理極限。而後輸入該表為角色背景，要求模型僅據「最後能看到的序號及內容」回覆，不得摻雜其他敘述。（該表依GPT計法共9107 tokens，依Caveduck計法共13618 tokens）
- 限制：
- Caveduck本身可能於Prompt前後自動插入框架內容，佔未知Token數，無法推估上限，只能反推下限。
- 不要問我怎麽做到「關掉Caveduck角色扮演功能」的，我不會說。
- 測試對象
- Huey
- DeepSeek V3
- Donald 2
- GPT-4o
- Claude 3.7 Sonnet
- Claude 3.5 Sonnet v2
- Claude Sonnet 4
- Gemini 2.5 Pro
結果
- Huey：最後看到的數字是361，內容為「水盆藏蛋燕孵雲，磁鐵吸瓜蛇扭頭」。
- DeepSeek V3：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
- Donald 2：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
- GPT-4o：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
- Claude 3.7 Sonnet：最後看到的數字是124，內容為「瓦片滑落蛇驚走，院牆生苔草亂爬」。
- Claude 3.5 Sonnet v2：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
- Claude Sonnet 4：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
- Gemini 2.5 Pro：最後看到的數字是400，內容為「咖啡灑盆燕流連，魚骨畫沙狗蹭臉」。
| 模型名稱 | 最後可見序號 | 內容 | GPT Tokens | Caveduck Tokens |
|---|---|---|---|---|
| Huey | 361 | 正確 | 8217 | 12247 |
| DeepSeek V3 | 400 | 正確 | 9107 | 13618 |
| Donald 2 | 400 | 正確 | 9107 | 13618 |
| GPT-4o | 400 | 正確 | 9107 | 13618 |
| Claude 3.7 Sonnet | 124 | 正確 | 2846 | 4075 |
| Claude 3.5 Sonnet v2 | 400 | 正確 | 9107 | 13618 |
| Claude Sonnet 4 | 400 | 正確 | 9107 | 13618 |
| Gemini 2.5 Pro | 400 | 正確 | 9107 | 13618 |
- 異常：
- Claude 3.7 Sonnet明顯偏低（僅124行），遠低於同家族其他版本，推測其API參數有特殊限制，並非模型本體能力問題。
- Huey亦低於主流（361行）。
結論
Caveduck多數模型，除了Claude 3.7 Sonnet與Huey，皆可一次性完整傳送400條對聯這樣的大內容，且回傳內容皆無遺漏或錯誤。這代表在單次回應中，均能保證至少9107 tokens（或依Caveduck算法為13618 tokens）有效傳遞。
即便如此，創作者也要注意，單次能完整接收並回應，頂多證明API層面的「可輸入長度」足夠。並不等於模型本身在面對複雜情境時，仍能持續維持精確回答。
實際上LLM的注意力機制，對於極長內容，始終存在「資訊稀釋」。即便內容未被截斷，模型仍可能因為關鍵訊息被稀釋，而導致回應品質下降，甚至出現語無倫次、偏離主題的情形。
因此，在真實應用場景下，仍建議創作者謹慎控管Prompt的結構與篇幅，切勿為追求一次輸入極大資料量，而忽略模型注意力分配的限制。唯有適度精簡關鍵資訊，才能有效提升使用體驗。
達人
