影片筆記：2000 行 JSON 也不怕！🔥 Fast-Jev 把 AI「記憶爆倉」變成精準斷捨離

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

• 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

影片介紹開源專案 Fast-Jev-Compaction，透過「得分刪除法」（GMV）與 Jev 模型評分，針對工具呼叫（Tool Use）與結果進行精準壓縮，解決 AI 上下文視窗爆滿問題，同時保留最新對話與關鍵資訊，並探討其資安風險與部署限制。

核心重點

1. 解決上下文危機：傳統摘要法如同「打果汁」會遺失細節並引發 AI 幻覺；Fast-Jev-Compaction 採用「得分刪除法」，主張逐字保留有效資訊，僅刪除過期或低價值內容。
2. 核心機制：

• 成對綁定：將工具呼叫（Tool Use）與結果（Tool Result）綁定，確保操作與回傳不脫鉤。
• 保護機制：預設保留最新 6 筆對話（Preserve Recent Messages）。
• 評分模型：使用 Jev 模型進行評分，受限于 32K Token 上限，設定 25,000 Token 的安全水位。

1. 壓縮策略：

• Token 估算：放棄精確分詞器，改用字元粗略估算以節省效能（英文約 6 字=1 Token），但可能嚴重低估繁體中文的 Token 消耗。
• 多階段處理：當資料超限時，逐步壓縮參數（從 1000 字元縮減至 60 字元），直至符合限制。
• 停損機制：若壓縮比例小於 0.25，則放棄壓縮，回退至 Cloud Code 內建機制。

1. 適用情境：

• 適用：自動化任務、工具密集任務、大量 JSON 報表與錯誤日誌。
• 不適用：人類純聊天場景（純文字訊息不會被壓縮）。

1. 資安與部署：

• 資料會完整傳送至 TypeSafe 伺服器，缺乏內建敏感資訊過濾，企業需自建過濾層。
• 依賴處於測試階段的 Function Hooks，需手動開啟 Feature Flag，增加部署摩擦力。

詳細大綱

一、 問題背景：上下文視窗危機

• 情境描述：工程師在凌晨除錯時，面對龐大 JSON 錯誤報告與程式碼片段，AI 助手因上下文爆滿而崩潰，回傳不相關邏輯或拼錯檔名。
• 傳統摘要法的缺陷：
• 如同將剩菜打成綜合果汁，體積變小但原貌消失。
• 遺失關鍵細節（如 API 參數），導致後續除錯失準。
• 引發 AI 幻覺，憑空捏造被摘要吃掉的細節。

二、 Fast-Jev-Compaction 核心機制解析

• 基本策略：
• 主打「逐字保留」與「得分刪除法」。
• 不打果汁，而是將過期食材丟棄，保留新鮮蘋果。
• 運作基石：
• 將每一筆工具呼叫（Tool Use）與結果（Tool Result）成對綁定，確保操作與回傳不脫鉤。
• 訊息保護與評估：
• Preserve Recent Messages：預設值為 6，最新 6 筆對話絕對安全，不被刪除。
• 評估瓶頸：Jev 模型上下文上限為 32K Token，若傳送評估資料時爆滿，壓縮工具將失效。
• Max State Tokens：預設上限 25,000，預留緩衝空間。
• Token 估算與中文風險：
• 放棄精確分詞器（Tokenizer），改用字元粗略估算（英文約 6 字=1 Token，數字半個，標點一個）。
• 實務地雷：繁體中文字可能消耗 2-3 個 Token，系統若按英文邏輯估算會嚴重低估，導致 API 報錯。
• 建議技術主管在導入時注意資源估算比例。

三、 多階段處理與停損機制

• 多階段處理 (Stage Based Fitting)：
• 當估算值超過 25,000 Token 時啟動。
• 第一階段：將舊工具輸入參數壓縮至 1000 字元（保留開頭結尾，捨棄中間龐大資料）。
• 第二階段：若仍超限，縮減至 200 字元。
• 極限階段：若仍超限，砍至 60 字元。
• 最終處理：很久以前的舊訊息被折疊成類似註解的短語（如「省略 N 個字元」），直到能安全塞入限制。
• 停損機制 (Reduction Ratio)：
• 預設壓縮比例參數。
• 若預估能刪除的內容比例小於 0.25（25%），系統判斷壓縮不划算。
• 立即停損，退回完整對話或回退至 Cloud Code 內建裁減機制。

四、 彈性設計與技術綁架風險

• 廠商綁架 (Vendor Lock-in)：
• 企業擔心被單一廠商綁架，若已購買 OpenAI 或 Anthropic 額度，此套件是否適用？
• 解決方案：
• 原生內建主流模型，但刻意留下寬廣後門。
• Jev Asker 介面：開發者可自行實作此介面，定義底層傳輸邏輯，接駁任意模型。
• 模組化設計：作為 NPM 模組發布，匯出 Compact Messages、Collect Tool Calls 等核心函式。
• 技術主管可將刪除演算法抽離，整合至公司內部私有 AI 系統，降低綁架風險。

五、 評分邏輯與補救機制

• Jev 評分機制：
• 針對未勾選的工具呼叫問兩個問題：

1. 該呼叫記錄本身是否重要（知道曾被執行過）？
2. 執行結果是否需原封不動保留，還是可刪除並讓 AI 重新執行？

• 保留門檻 (Keep Threshold)：預設 0.5。
• 若保留結果機率 > 0.5：整組保留。
• 若保留結果機率低，但保留動作機率 > 0.5：截斷結果至前 300 字元，並加註解說明曾發生之事。
• 若兩者機率均 < 0.5：整組直接刪除（超度）。
• 誤刪補救：
• Toast 提示：顯示保留了幾筆訊息。
• 代理能力：若 AI 發現缺少參數，可重新執行工具（重新讀檔），成本可接受。
• 單元測試：實作不聯網的 Fake Jev，確保在 API 失敗或回傳破損 JSON 時，系統能優雅降級（切換回 Cloud Code 內建機制）。

六、 資安與部署實務

• 資安警告：
• 運作時需填寫 API Key，並將完整對話記錄（含工具輸入參數）傳送至 TypeSafe 伺服器。
• 無內建過濾：缺乏自動過濾敏感資訊機制，程式碼中的 AWS 金鑰或商業邏輯可能以純文字外洩。
• 作者警告：README 強調勿將金鑰提交至原始碼，暗示資料傳輸透明且具風險。
• 企業建議：技術團隊需自建中介層，在送給 Jev 評分前於本地端過濾敏感資訊。
• 部署摩擦力：
• 依賴 Cloud Code 的 Function Hooks，目前處於早期測試階段。
• 非安裝即用，需在環境變數或設定檔中強制宣告全域變數以開啟功能。
• 需手動開啟 Feature Flag，增加 DevOps 團隊推廣成本與新進員工設定負擔。

七、 視覺化展示與產業趨勢

• 視覺化演示：
• 作者開發 macOS 原生 Swift UI App 錄製展示影片。
• 非真實 API 呼叫：對話與決策由腳本預先寫實，僅為視覺化演出。
• 效果：歷史記錄中判定為廢話的文字變紅並動態折疊消失。
• 實務價值：直觀展示核心價值，有助於工程師向老闆提案，證明節省 API 費用。
• 產業趨勢與限制：
• 現有方法比較：遮蔽法、滑動視窗（遺失早期約束）、傳統摘要法。
• GMV (得分刪除) 的硬傷：
• 純文字訊息（人類與 AI 對話）永遠不會被移除或縮減。
• 僅在傳給 GMV 評估的狀態中被縮減，最終保留的記錄中，人類純文字 100% 完整保留。
• 適用情境：
• 最佳舞台：多代理人瘋狂反覆執行工具、產生大量 JSON 報表與錯誤日誌的自動化任務。
• 不適用：人類純聊天，節省效果微乎其微。
• 結論：需將刀用在刀口上，針對自動化與工具密集任務應用，最大化 Token 節省報酬率。

工具 / 模型 / 名詞整理

• Cloud Code：開發環境/擴充套件平台。
• Fast-Jev-Compaction：本次探討的開源專案名稱，Cloud Code 擴充套件兼 NPM 模組。
• Jev：用於評估訊息是否該刪除的 AI 模型。
• TypeSafe：提供 Jev 模型 API 服務的廠商（提及 TypeSafe 的 API）。
• OpenAI：提及的模型供應商。
• Anthropic：提及的模型供應商。
• NPM：Node.js 套件管理系統，Fast-Jev-Compaction 以此模組發布。
• macOS：作業系統，作者開發 Swift UI App 的平台。
• Swift UI：用於開發展示 App 的框架。
• AWS：提及的雲端服務供應商（涉及金鑰管理）。
• Function Hooks：Cloud Code 的功能鉤子，Fast-Jev-Compaction 依賴此功能。
• Feature Flag：功能旗標，用於手動開啟特定功能。
• Jev Asker：Fast-Jev-Compaction 中定義的介面，允許開發者自定義底層傳輸邏輯。
• Compact Messages：Fast-Jev-Compaction 匯出的核心函式之一。
• Collect Tool Calls：Fast-Jev-Compaction 匯出的核心函式之一。
• Fake Jev：單元測試中實作的不聯網假 Jev，用於確保系統優雅降級。
• GMV：逐字稿後段提及「GMV 帶來的這種得分刪除」，疑為「Jev」或「Fast-Jev-Compaction」的縮寫或口誤。

操作流程整理

1. 初始化與設定：

• 安裝 Fast-Jev-Compaction 作為 Cloud Code 擴充套件或 NPM 模組。
• 手動開啟 Feature Flag 並設定環境變數以啟用 Function Hooks。
• 填寫 API Key 以連接 TypeSafe 伺服器。

1. 訊息處理流程：

• 綁定：系統將工具呼叫（Tool Use）與結果（Tool Result）成對綁定。
• 保護：預設保留最新 6 筆對話（Preserve Recent Messages）。
• 估算：使用字元粗略估算 Token 數量（非精確分詞器），檢查是否超過 25,000 Token 上限。
• 評分：若超限，將資料傳送至 Jev 模型進行評分。
• Jev 評估工具呼叫記錄的重要性及結果是否需保留。
• 根據保留門檻（預設 0.5）決定保留、截斷或刪除。
• 壓縮：若評分後仍需壓縮，啟動多階段處理（Stage Based Fitting）：
• 第一階段：壓縮參數至 1000 字元。
• 第二階段：縮減至 200 字元。
• 極限階段：砍至 60 字元。
• 最終：舊訊息折疊為註解短語。
• 停損檢查：若壓縮比例小於 0.25，放棄壓縮，回退至 Cloud Code 內建機制。

1. 執行與監控：

• AI 執行工具呼叫。
• 若發生誤刪，AI 可透過重新執行工具（如重新讀檔）進行補救。
• 系統顯示 Toast 提示保留的訊息數量。
• 若 API 失敗，系統切換至 Fake Jev 進行單元測試或優雅降級。

值得注意的限制或風險

1. Token 估算不準確：系統使用字元粗略估算 Token，對於繁體中文可能嚴重低估消耗，導致 API 報錯。
2. 資安風險：資料完整傳送至 TypeSafe 伺服器，缺乏內建敏感資訊過濾，企業需自建過濾層以防金鑰或商業邏輯外洩。
3. 適用情境有限：純文字訊息不會被壓縮，僅適用於工具密集與自動化任務，不適用於人類純聊天場景。
4. 部署複雜度：依賴測試階段的 Function Hooks，需手動開啟 Feature Flag，增加部署與維護成本。
5. 模型依賴與綁架：雖有 Jev Asker 介面可自定義傳輸邏輯，但仍依賴 TypeSafe 的 Jev 模型服務，需確認長期可用性與成本。
6. 壓縮極限：極限階段僅保留 60 字元，可能遺失過多上下文資訊，需依賴 AI 重新執行工具的代理能力。

逐字稿辨識疑點

• off 檔案：逐字稿中提到「針對剛剛那個 off 檔案生成修復程式碼」，疑為口誤或聽寫錯誤，實際語境可能指代某個特定檔案類型或名稱，但無法確定具體所指。
• Jev 模型：逐字稿多次提及「Jev」作為評估模型，疑為特定模型名稱或專案內部命名，需查證是否為通用模型名稱或拼寫錯誤（如 Gem、Jewel 等，但不得自行更動）。
• GMV：逐字稿後段提及「GMV 帶來的這種得分刪除」，疑為「Jev」或「Fast-Jev-Compaction」的縮寫或口誤，因前文主要討論 Jev，此處 GMV 可能為聽寫錯誤，但需保留原樣。
• 25,000 與 32K：關於 Token 上限的數值，逐字稿明確區分 Jev 上限 32K 與 Max State Tokens 上限 25,000，此為專案設定，非錯誤，但需注意其對應關係。
• 0.25 壓縮比例：關於 Reduction Ratio 的閾值，逐字稿明確指出小於 0.25 時停損，此為邏輯設定，非錯誤。
• 300 字元截斷：關於保留動作但刪除結果時的截斷長度，逐字稿明確指出前 300 個字元，此為邏輯設定，非錯誤。
• 6 個英文字母算一個詞：關於 Token 估算的啟發式演算法描述，逐字稿指出這是為了效能妥協的做法，雖與實際 Tokenizer 可能不符，但屬專案設計邏輯，非錯誤。

可延伸追問

1. Jev 模型的具體評分標準與訓練數據來源為何？
2. TypeSafe 伺服器的資料保留政策與隱私條款為何？
3. 如何針對繁體中文環境優化 Token 估算算法？
4. 企業自建敏感資訊過濾層的最佳實踐與技術方案為何？
5. Fast-Jev-Compaction 與 Cloud Code 內建機制的具體差異與效能比較？
6. Jev Asker 介面的實作範例與文件是否公開？