上下文限制、無狀態、脈絡腐化：讓你用 AI 用得不夠暢快

首先：AI 一次能看的東西是有限的。
以 Claude 為例，依模型不同，一次可以處理約數十萬甚至上百萬個 tokens，我們先假設「十萬～十三萬」個中文字吧，一次對話不能超過這個 tokens ，超過就必須刪減、壓縮，或乾脆塞不進去。

拿論文來舉例：

一博士生小文。他的博士論文有二十萬個字，Bang ! 塞不下一次對話，馬上觸碰到了超過上下文限制（context window limit，參考：Context: The Secret Life of LLMs）。

隔一天，碩士生小玉。借用小文的 Claude 帳號來跟 AI 討論他的論文，八萬個字。

小玉請 AI 先掃過他的論文再展開他的討論，但是因為「AI 不會記得」它讀過小玉的論文，下次再打開，要重新複製貼上。畢竟 LLM 本身是無狀態的（Stateless）（參考：Are LLMs Stateless?）

就是說，LLM 不會因為「上次看過」就把那八萬字記在腦袋裡。下一次要用到那些資訊，還是得重新把相關內容提供給它。

於是，小玉每次跟 AI 討論論文，都重新複製貼上、複製貼上、複製貼上，Bang ! 直接用完額度，討論不下去了，跟小文一起被當掉。

最後一個，路人阿伯小劉。看小玉這樣占人家便宜，覺得很杯壁，他都用自己訂閱的帳號。

小劉問題很多，每次對話很發散，像是什麼論文、參考資料、隔壁王老五的內褲、或是教授的小祕密都塞在同一個對話裡。

剛開始聊的時候 AI 答得好好的，但是等到對話越來越長，AI 的回答也越來越莫名其妙。

像是「這段文字只有九個字」，AI 卻總結說整段文章只有九個字。或是「論文成功的祕密」AI 回答說藏在教授的內褲裡。（只是舉個例子）

這個現象可以歸類為 Context Rot（脈絡腐化）（參考：Context Rot: The Emerging Challenge），資料明明就給得很正確，也沒有超出上下文限制，但是 AI 正確找到、區分、理解的能力隨著對話拉長逐漸下降。

所以我們現在碰到了三個問題。

小文的問題是塞不下；小玉的問題是AI 不會一直記得；小劉的問題是塞的下但 AI 用不好。

三個問題其實是一件事：

上下文管理

這就是 LLM Wiki 要解決的問題（之一）。

一定要讓它管，替身（知識庫）就是為我們幹這個的

解決上下文限制的問題，這也是 LLM Wiki 出生的初衷。

透過把文字內容整理成結構化的架構，以知識庫的形式儲存你的檔案，讓每次與 AI 對話「只拿這次討論需要的檔案」。

我們可以把論文依照章節分類，每次開啟對話不需要整包掃，想聊某個想法就去特定章節看。
或是公司/團隊的技術文件、 SOP，按模組、按功能分頁存放，AI 討論某個 bug 或某個功能只需要調那個模組的文件（不是程式碼）。

一次解決上下文限制、因無狀態延伸出的成本，與脈絡腐化三個問題。

按需檢索

知識庫的核心哲學之一：按需檢索。意思就是字面意思。

AI 只需要知道檔案在哪裡就好。

這大幅改善了上下文問題，幅度大到有些人會直接把知識庫當作「工作臺」，將所有日常工作搬到跟知識庫相同的檔案夾裡面，例如待辦事項、行事曆、記帳、寫日記。

先小小提醒大家，這類跟知識庫無關的資料不適合建在知識庫裡面，具體一點，是不適合放在 raw/wiki/CLAUDE.md 檔三層之內，知識庫就是知識庫，資訊的目的若是混合了，就像是廚房擺了一張書桌，你能分辨用途，但 AI 能嗎？

我的經驗是 AI 不能分辨（靈活度不若人類），我之前把日記也放進知識庫裡面，結果好幾次對話 AI 都拿日記裡的東西來回答我。

偏題了，總之希望大家如果想把自己的工作搬進來，請額外建一層。

「把房間隔好」

四種機制做到按需檢索

1. 拆分 => 一份筆記只講一件事（原子化）、命名要具體，這跟 Ingest（入庫）有關。

2. 結構 => 透過清楚定義好資料結構，「用看的」就能知道資料放在哪，不需要找，這對你跟對 AI都方便。

3. 索引 => 弄一份「目錄」出來，像字典那樣，如果要查 Butthole，先去看看 B開頭的從哪一頁開始。

4. 連結 => 相關的東西要互相牽線。像是 Butthole 跟痔瘡有關，兩件事要牽起來，掃到其中一個，自動想起另外一個。

收尾

好像開了很多不恰當的玩笑，這邊做個比較正經的總結。

在使用 AI 時會遇到上下文管理的問題，可以利用知識庫把「儲存」與「使用」拆開處理。

下一篇要講「怎麼寫知識庫的設定檔（Claude.md）」。