# 影片筆記：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 的安全水位。
3.  **壓縮策略**：
    *   **Token 估算**：放棄精確分詞器，改用字元粗略估算以節省效能（英文約 6 字=1 Token），但可能嚴重低估繁體中文的 Token 消耗。
    *   **多階段處理**：當資料超限時，逐步壓縮參數（從 1000 字元縮減至 60 字元），直至符合限制。
    *   **停損機制**：若壓縮比例小於 0.25，則放棄壓縮，回退至 Cloud Code 內建機制。
4.  **適用情境**：
    *   **適用**：自動化任務、工具密集任務、大量 JSON 報表與錯誤日誌。
    *   **不適用**：人類純聊天場景（純文字訊息不會被壓縮）。
5.  **資安與部署**：
    *   資料會完整傳送至 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 伺服器。
2.  **訊息處理流程**：
    *   **綁定**：系統將工具呼叫（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 內建機制。
3.  **執行與監控**：
    *   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 介面的實作範例與文件是否公開？