大家想像一個情境
現在是凌晨一點
然後你為了解一個系統 bug
已經坐在電腦前
除錯了十幾分鐘
哇 凌晨一點
這聽起來就是我們工程師的
日常噩夢
真的超級痛苦
然後你剛剛把一份
就是大概 2000 行左右的
JSON 錯誤報告
還有三個核心程式碼
檔案的片段
全部貼給你的 AI 助手
嗯 這資訊量真的很龐大
對 然後你好不容易
真的是好不容易
引導他找到了問題點
你就下指令說
太好了 就針對剛剛那個
off 檔案生成修復程式碼
結果你猜怎麼著
該不會是忘記了吧
沒錯 他回傳了一段
完全不相關的邏輯
甚至連檔名都拼錯
也就是說 他的上下文記憶
就在最關鍵的這一刻
徹底爆滿崩潰了
這種時候真的會讓人
想直接砸螢幕
其實這就是開發界常說的
所謂的上下文視窗危機
對 Context Window 危機
沒錯 當歷史資訊量太大
傳統的 AI 系統
為了解決這個問題
通常會在背後
偷偷做一件事
就是把前面的對話
進行摘要
但講到傳統的摘要法
那根本就像是
我們清理冰箱的時候
把所有剩菜
隔夜飯全部倒進果汁機裡
然後打成一鍋
完全看不出原貌的綜合果汁
這個比喻非常精準
體積確實是變小了
沒錯 對
可是如果我現在需要
找裡面的一根蔥
抱歉 完全找不到
在程式碼的環境裡
少掉的那根蔥
可能就是一個至關重要的 API 參數
確實 這會讓整個後續的除錯
完全失準
而且比綜合果汁更糟的是
這杯果汁還會讓 AI 產生幻覺
讓它去憑空捏造那些
被摘要吃掉的細節
哇 那真的是越忙越忙
所以我們在本次深入探討中
要來解析一個全新的開源專案
這是一個 Cloud Code 的擴充套件
兼 NPM 模組
叫做 Fast-Jev-Compaction
這個套件的策略非常極端
它主打的是逐字保留
以及得分刪除法
也就是說 它不打果汁了
它是把你確定已經過期的食材
整包連同包裝袋
直接丟進垃圾桶
而留下來的每一顆蘋果
都是百分之百原封不動
非常新鮮的
沒錯 這就是它的核心理念
所以今天的任務
我們就是要來拆解這套機制的底層邏輯
比如它能省下多少 Token
如果是很短的對話
會不會反而增加成本
還有對我們台灣的中小企業來說
這到底能不能真正落地
這些實務問題都非常關鍵
那我們先從它的保鮮機制談起好了
我注意到來源資料裡提到
它會把每一筆工具呼叫
就是 Tool Use 跟它的結果 Tool Result
成對地綁定在一起
對 這是它運作的最基礎基石
因為在 Cloud Code 這種
會瘋狂呼叫終端機
或者是讀取檔案的環境中
工具的操作跟回傳結果
是絕對不能脫鉤的
了解 那它怎麼決定誰該留下來
系統有一個叫做
Preserve Recent Messages 的設定
預設值是 6
意思是最新發生的前 6 筆對話訊息
會被加上精選的保護罩
精選
所以這 6 筆是絕對安全的
絕對不碰
它保證你當下正在處理的邏輯
不會被刪掉
但挑戰來了
如果要請 Jev 這個模型
來幫我們評估那些
沒被勾選的舊資料該不該刪
我們得把整個長篇大論的歷史記錄
傳送給它對吧
沒錯 這就是一個潛在的瓶頸
Jev 本身的上下文上限
是 32K 個 Token
如果在傳送評估的路上就先爆了
那這個壓縮工具
不就毫無意義了嗎
所以開發者為了解決這個問題
設定了一個 Max State Tokens 的上限
預設是 25,000
25,000 留了一點緩衝空間
對 而且為了在不拖慢系統速度的前提下
估算這 25,000 個 Token
它放棄了傳統那種
精確但很笨重的分詞器
不用 Tokenizer
那它怎麼算
它直接用字元來進行粗略的估算
等一下 用字元算
這在英文環境或許說得通
大約 6 個英文字母算一個詞
數字算半個 Token
標點符號算一個
這是一種為了效能妥協的做法
沒錯 這是一種啟發式演算法
可是這在我們台灣的實務應用上
根本是個隱形地雷吧
你想想看 如果使用者的 Prompt
或者那個巨大的 JSON 報表裡
塞滿了繁體中文呢
哇 這裡真的講到重點了
在大多數大型語言模型裡
一個繁體中文字可能就會消耗 2 到 3 個 Token
如果系統還傻傻地以為
6 個中文字才等於 1 個 Token
這絕對會嚴重低估真實的 Token 數量
這個實務觀察真的非常敏銳
這個開源專案目前的設計思維
確實帶有強烈的英語系
跟程式碼本位色彩
對 最後送給 Jev 的時候
肯定會直接撞破 32K 的上限
導致 API 報錯
這也是為什麼它把安全水位設在 25,000
留了足足 7K 的緩衝
但對於大量處理中文文本的團隊來說
技術主管在導入時
絕對需要注意這個資源估算的比例
了解 要特別小心
不過撇除中文字元的問題
當它發現資源數真的超過了 25,000 的限制
我看到資料說它的處理手法
叫做多階段處理
對 Stage Based Fitting
它的做法相當精妙
讓我推演一下
假設我有一個 5000 行的系統日誌
它總不可能直接放棄壓縮吧
它一定是從那些最肥大的參數開刀
完全正確
第一階段 它會把所有沒被勾選的
舊工具輸入參數
硬生生壓縮到 1000 個字元
所以它把中間挖空了嗎
沒錯 它只保留開頭跟結尾
把中間龐大的資料直接捨棄
所以它保留了工具曾經被執行過的形狀
但捨棄了內容
那如果挖空到 1000 字元
算一算還是超過 25,000 呢
那它就會變得更殘酷一點
進入第二階段
把限制縮減到 200 個字元
200 字元真的很少了
如果再不行 就砍到極限的 60 個字
到最後如果還是塞不進去
那些很久以前的舊訊息
會被徹底折疊成一句簡單的短語
像是一句註解那樣嗎
對 例如省略 N 個字元
就這樣一步一步削肉剔骨
直到整包資料的估算值
能安全塞進 25,000 的限制裡
再送給 Jev 去做最後的決策
哇 這種在極限狀態下的多階段處理邏輯
對我們工程師來說
真的是一個很棒的價值提升
怎麼說
就是在系統設計時
為了追求極致的效能跟穩定
其實你不一定需要追求百分之百
精確的 Token 計算
用簡單的資源估算
搭配多層次的安全防線
實務上不僅運作更快
容錯率也更高
工程思維的精髓
就是用最小的算力成本
換取最大的系統穩定度
但講到成本
這就衍生出另一個很現實的問題了
什麼問題
如果今天我這個除錯任務其實很簡單
我只跟 AI 來回對話了三四次
上下文根本還很空
為了清理那一點點的歷史記錄
我還要特地把資料打包
傳送一個 API 請求給 Jev 去做評分
這反而多花了一筆 API 費用
甚至增加了網路延遲對吧
沒錯 這樣感覺很不划算
其實這個外掛並沒有那麼死板
在系統內部
它設定了一個參數叫做 Reduction Ratio
也就是壓縮比例
哦 所以它會先算帳
對 當 Jev 評估完畢
準備動刀刪除之前
系統會先預估一下
如果預計能砍掉的內容比例小於 0.25
也就是說 Jev 認為能刪掉的廢話不到四分之一
系統就會判斷說
這套壓縮根本不划算
馬上停損
就是這樣
它會直接退回原本的完整對話
或者 Fallback 回去使用
Cloud Code 內建的裁減機制
它不會為了展現自己會壓縮
而硬去執行無效的操作
懂得及時停損是很聰明的設計
但如果我們把目光放遠一點
考慮到企業長期的技術選型
我們最怕的其實是被單一廠商綁架
Vendor Lock-in
這確實是企業導入新技術時最大的顧慮
對啊 今天這個套件是為 Jev 模型設計的
如果我不想把資料打給 TypeSafe 的 API
或者我們公司已經買了大量的
OpenAI 或 Anthropic 的額度
這套機制還有用武之地嗎
來源文件雖然沒有明說
它原生內建了所有主流模型
但它刻意留下了一道非常寬廣的後門
開發者可以自行實作一個
名為 Jev Asker 的介面
Jev Asker
意思是只要我符合這個介面的標準
我背後要接誰都可以
沒錯 只要你能寫出一個 Ask 的方法
你就可以自行撰寫底層的傳輸邏輯
而且這個專案是作為 NPM 模組發布的
所以它可以直接裝在專案裡
對 它還大方地匯出了像是
Compact Messages
Collect Tool Calls 這些核心函式
這些就像是樂高積木一樣
這對於技術主管來說
真的是一盒定心丸
這種模組化暴露出核心介面的設計
意味著我們甚至可以把這套刪除法的演算法
抽離出來 改寫整合到公司內部的私有 AI 系統中
這樣技術綁架的風險就趨近於零了
既然機制這麼彈性
那我們就得來檢驗它的心臟了
它到底是怎麼給出那個所謂的刪除得分的
它的評分機制是這樣
Jev 會針對每一個沒被勾選的工具呼叫
問兩個非常刁鑽的問題
哪兩個問題
第一 這個呼叫的記錄本身該留下來嗎
知道它曾經被執行過
對接下來的任務還重要嗎
嗯 這是評估動作本身
那第二個呢
第二 這個執行的結果該原封不動保留嗎
還是其實可以刪掉
大不了讓 AI 發現缺資料時重新跑一次
哦 所以它把動作跟結果分開來評估
那幾個分數是多少
系統依賴一個預設為 0.5 的 keep threshold
也就是保留門檻
大於 0.5 就保留嗎
對 如果 Jev 給出保留結果的機率大於 0.5
那就整組完好無缺地留下
那如果結果不重要 但動作很重要呢
如果保留結果的機率不高
但保留動作記錄的機率大於 0.5
它就會把那份龐大的結果
截斷到前 300 個字元
並加上一行註解
告訴 AI 這裡曾經發生過什麼
了解 那如果兩個機率都低於 0.5 呢
那就是整組直接超度
完全刪除
超度 這形容很貼切
邏輯聽起來很縝密啦
但我們都知道 機率不代表絕對
萬一 Jev 今天就是判斷失誤
把一個超級關鍵的記錄給刪了
導致模型徹底忘記了
剛剛讀過的檔名
這時候補救機制是什麼
開發者在畫面上其實不會瞎子摸象
你會看到一個 Toast 提示
明確告訴你保留了幾筆訊息
但如果真的誤刪了關鍵資訊怎麼辦
文件也坦承這項技術有它的局限
如果真的刪錯了
其實補救方式非常直覺
因為你是在具有代理能力的環境裡
AI 如果發現自己缺少某個參數
它可以隨時再次執行該工具
大不了就是讓 AI 再花個幾秒鐘
重新讀一次檔案
這成本還算可以接受
除此之外 為了確保系統不會因為 API 連線失敗
而整組崩潰
作者在寫單元測試的時候
特別實作了一個不聯網的 Fake Jev
不聯網的假 Jev
這有什麼好處
這確保了在真實情境中
萬一 Jev 回傳了破損的 JSON
或是網路直接斷線
系統能百分之百順暢地執行優雅降級
優雅降級
也就是無縫切換回
Cloud Code 原本內建的裁減機制對吧
完全正確
有降級機制確實讓人安心
但說到聯網打 API
我們就必須面對企業導入時最大的心魔了
那就是資安
沒錯 這真的是重中之重
任何會把資料往外送的外掛
在公司內部都會面臨嚴格的審查
對 這部分資料裡有提到什麼防護機制嗎
這是今天最核心
最需要劃重點的資安警告
這個套件在運作時 你需要填寫 API Key
而且它會將你那份完整的對話記錄
包含所有的工具輸入參數
毫無保留地傳送到 TypeSafe 的伺服器
等一下 毫無保留
也就是說 如果我的程式碼裡夾帶了 AWS 的機密金鑰
或者我們公司核心產品還沒公開的商業邏輯
這些都會變成純文字
直接送到別人的伺服器上
毫不設防
完全會
來源文件完全沒有提到
任何內建的自動過濾或清理敏感資訊的機制
哇 這太危險了吧
作者反而在 README 裡非常用力地警告大家
絕對不要把金鑰提交到原始碼中
這等於是在暗示
資料的對外傳輸是完全透明且具有風險的
這件事對台灣的中小企業
資安公司或是企業內部團隊來說
太關鍵了
非常關鍵
我們常常看到工程師為了解決眼前的
Context 爆滿痛點
上網隨手就裝了一個開源工具
這裡的實務提醒是
如果你的專案牽涉到任何商業機密
絕對不能在沒有自建防線的情況下直接套用
沒錯 這也呼應了前面提到的
Jev Asker 介面
如果企業真的要導入
技術團隊必須自己寫一個中介層
在把資料送出去給 Jev 評分之前
先在本地端把敏感資訊過濾掉
企業的底線是不能妥協的
但其實即使資安這關過了
技術團隊還要面對另一個深淵
那就是部署的摩擦力
部署的坑真的很多
技術再好 如果無法順暢地部署到
每一位工程師的電腦上
或者沒辦法放進 CI/CD 的流程裡
那也是白搭
我看到文件特別提到
這個機制依賴 Cloud Code 的 Function Hooks 功能
對 麻煩就在於
這個功能目前還處於早期測試階段
所以它不是 NPM 安裝完
就能無腦啟動的
遠比那複雜
你必須在環境變數
或者是本機的設定檔裡
強制宣告一個全域變數來開啟這個功能
哦 要手動去開 Feature Flag
對 這代表團隊裡的每一個使用環境
包括每位新進員工的筆電
或是雲端的 CI/CD 伺服器
都必須先經歷這個手動開啟的步驟
否則外掛根本不會動
哇 這對 DevOps 團隊來說
絕對是個大坑啊
推廣新工具時
只要多一個手動設定步驟
採用率就會掉一半
確實會增加初期的推廣成本
不過談到推廣跟說服
我注意到作者做了一件讓我非常驚艷的事情
他為了展示這套抽象的得分刪除法技術
特地寫了一個 macOS 原生的 Swift UI App
只為了錄製一段展示影片
這在開源推廣上真的非常聰明
對啊 為什麼他不直接錄個
無聊的終端機畫面就好
還要特地寫個 App
這個 App 其實從頭到尾
都沒有呼叫任何真實的 API
它裡面顯示的對話跟決策
全都是用腳本預先寫實的
它純粹就是為了視覺化演出而生的
視覺化演出
它具體演出的是什麼效果
當你在畫面上看到一長串
密密麻麻的歷史記錄
系統判定哪些舊的呼叫是不需要的廢話時
那些文字會直接在畫面上變成紅色
然後動態地折疊消失
哇 變成紅色然後消失
這種視覺衝擊力太強了吧
對一個沒時間看長篇技術文件的技術主管
或非技術老闆來說
這幾秒鐘的動態裁剪
能讓他們瞬間看懂這個技術的核心價值
這裡有一個超棒的實務應用價值
如果我們是工程師
準備向老闆提案導入
這種可以幫公司省 API 費用的新架構
嗯 你要怎麼說服他
與其貼出一堆冷冰冰的 Lockdown
或是 Token 節省數據
不如學學這種視覺化展示核心邏輯的手法
老闆一看紅字消失 馬上就知道
哦 垃圾被清掉了
有用的東西還在
而且我們省錢了
沒錯 能把深奧的底層邏輯
轉化為直覺的視覺
有時候比寫出這段程式碼還要困難
這絕對是提升競爭力的好方法
聊到這裡我們最後來宏觀地檢視一下產業趨勢
面對上下文爆滿
目前業界有遮蔽法
有直接砍掉舊對話的滑動視窗
還有傳統的摘要法
GMV 帶來的這種得分刪除
未來真的會成為主流嗎
它還有什麼無法跨越的曲線
滑動視窗雖然簡單粗暴
但大家都意識到它會無可避免地
遺失早期設定的系統約束條件
GMV 確實在精確度上開創了一個新流派
但它目前有一個非常硬傷的缺陷
什麼缺陷
在最終輸出實際保留下來的歷史記錄裡
純文字訊息
也就是人類跟 AI 講的話
永遠不會被移除或縮減
等等 也就是說如果使用者自己打字
貼了幾萬字的會議記錄
甚至是一堆無意義的廢話
這個外掛其實拿它一點辦法都沒有
一點辦法都沒有
純文字只會在傳給 GMV 評估的那個狀態中
被縮減
但最終真實保留在上下文裡的記錄
人類打的純文字會被百分之百完整保留
所以它只管工具呼叫的記錄
對 GMV 的權限僅限於決定
要不要刪除工具呼叫
跟工具回傳結果
這個誤區非常重要
這意味著企業在評估導入時
絕對不能抱持著說
哦 我裝了這個就能無腦壓縮所有人類對話
這是一個錯誤期待
沒錯 它是一把極端特化的手術刀
它最佳的發揮舞台是那種
多代理人瘋狂反覆執行工具
在背後產生大量 JSON 報表與錯誤日誌的自動化任務
只有在這種情境下
大量的無效系統痕跡才可以被精準抹除
但如果是人類純聊天
它的節省效果其實微乎其微
對 這點在導入前一定要評估清楚
所以真的是要把刀用在刀口上
針對自動化與工具密集的任務去應用
才能最大化節省 Token 的投資報酬率
今天的解析真的非常精彩
從果汁機的殘酷比喻
到多階段處理的精妙
還有繁體中文的潛在風險
甚至資安防護跟視覺化展示
這讓我們不禁反思
在未來 AI 越變越強的時代
我們真的需要讓 AI 記住所有的摸索與錯誤過程嗎
還是其實只要讓它記住關鍵的結論與原始資料就足夠了
今天最後的實務提醒是
看到新的開源工具
大家不要只看表面上宣稱省了多少 Token
一定要往底層看它的資料流向
有沒有資安過濾機制
能不能真正安全地落地到你們公司的規範中
沒錯 安全永遠是第一考量
喜歡我們的深入分析討論嗎
記得轉發給有需要的親朋好友
並且幫我們按讚訂閱開啟小鈴鐺
更多相關資訊連結
請參考影片下方的資訊欄
最後感謝您的收聽
祝您順心 我們下集再會
拜拜