WEBVTT
Kind: captions
Language: zh-TW

00:00:00.000 --> 00:00:01.600
大家想像一個情境

00:00:01.600 --> 00:00:03.640
現在是凌晨一點

00:00:03.640 --> 00:00:06.280
然後你為了解一個系統 bug

00:00:06.280 --> 00:00:08.000
已經坐在電腦前

00:00:08.000 --> 00:00:09.880
除錯了十幾分鐘

00:00:09.880 --> 00:00:11.320
哇 凌晨一點

00:00:11.320 --> 00:00:13.520
這聽起來就是我們工程師的

00:00:13.520 --> 00:00:14.840
日常噩夢

00:00:14.840 --> 00:00:16.720
真的超級痛苦

00:00:16.720 --> 00:00:18.960
然後你剛剛把一份

00:00:18.960 --> 00:00:21.280
就是大概 2000 行左右的

00:00:21.280 --> 00:00:22.560
JSON 錯誤報告

00:00:22.560 --> 00:00:24.920
還有三個核心程式碼

00:00:24.920 --> 00:00:26.120
檔案的片段

00:00:26.120 --> 00:00:28.440
全部貼給你的 AI 助手

00:00:28.440 --> 00:00:31.160
嗯 這資訊量真的很龐大

00:00:31.160 --> 00:00:32.880
對 然後你好不容易

00:00:32.880 --> 00:00:34.360
真的是好不容易

00:00:34.360 --> 00:00:36.320
引導他找到了問題點

00:00:36.320 --> 00:00:37.680
你就下指令說

00:00:37.680 --> 00:00:40.160
太好了 就針對剛剛那個

00:00:40.160 --> 00:00:42.440
off 檔案生成修復程式碼

00:00:42.440 --> 00:00:43.880
結果你猜怎麼著

00:00:43.880 --> 00:00:45.440
該不會是忘記了吧

00:00:45.440 --> 00:00:47.200
沒錯 他回傳了一段

00:00:47.200 --> 00:00:49.360
完全不相關的邏輯

00:00:49.360 --> 00:00:51.520
甚至連檔名都拼錯

00:00:51.520 --> 00:00:54.680
也就是說 他的上下文記憶

00:00:54.680 --> 00:00:56.600
就在最關鍵的這一刻

00:00:56.600 --> 00:00:58.280
徹底爆滿崩潰了

00:00:58.280 --> 00:00:59.720
這種時候真的會讓人

00:00:59.720 --> 00:01:00.800
想直接砸螢幕

00:01:00.800 --> 00:01:04.120
其實這就是開發界常說的

00:01:04.120 --> 00:01:06.880
所謂的上下文視窗危機

00:01:06.880 --> 00:01:08.960
對 Context Window 危機

00:01:08.960 --> 00:01:11.680
沒錯 當歷史資訊量太大

00:01:11.680 --> 00:01:13.320
傳統的 AI 系統

00:01:13.320 --> 00:01:14.600
為了解決這個問題

00:01:14.600 --> 00:01:16.000
通常會在背後

00:01:16.000 --> 00:01:17.120
偷偷做一件事

00:01:17.120 --> 00:01:19.160
就是把前面的對話

00:01:19.160 --> 00:01:20.240
進行摘要

00:01:20.240 --> 00:01:22.360
但講到傳統的摘要法

00:01:22.360 --> 00:01:23.880
那根本就像是

00:01:23.880 --> 00:01:26.360
我們清理冰箱的時候

00:01:26.360 --> 00:01:27.880
把所有剩菜

00:01:27.880 --> 00:01:30.600
隔夜飯全部倒進果汁機裡

00:01:30.600 --> 00:01:31.760
然後打成一鍋

00:01:31.760 --> 00:01:34.520
完全看不出原貌的綜合果汁

00:01:34.520 --> 00:01:36.040
這個比喻非常精準

00:01:36.040 --> 00:01:38.080
體積確實是變小了

00:01:38.080 --> 00:01:38.920
沒錯 對

00:01:38.920 --> 00:01:40.320
可是如果我現在需要

00:01:40.320 --> 00:01:41.760
找裡面的一根蔥

00:01:41.760 --> 00:01:43.560
抱歉 完全找不到

00:01:43.560 --> 00:01:45.440
在程式碼的環境裡

00:01:45.440 --> 00:01:47.000
少掉的那根蔥

00:01:47.000 --> 00:01:49.880
可能就是一個至關重要的 API 參數

00:01:49.880 --> 00:01:52.760
確實 這會讓整個後續的除錯

00:01:52.760 --> 00:01:53.440
完全失準

00:01:53.440 --> 00:01:56.080
而且比綜合果汁更糟的是

00:01:56.080 --> 00:01:58.640
這杯果汁還會讓 AI 產生幻覺

00:01:58.640 --> 00:02:00.640
讓它去憑空捏造那些

00:02:00.640 --> 00:02:02.320
被摘要吃掉的細節

00:02:02.320 --> 00:02:04.440
哇 那真的是越忙越忙

00:02:04.440 --> 00:02:06.960
所以我們在本次深入探討中

00:02:06.960 --> 00:02:10.080
要來解析一個全新的開源專案

00:02:10.080 --> 00:02:13.000
這是一個 Cloud Code 的擴充套件

00:02:13.000 --> 00:02:14.280
兼 NPM 模組

00:02:14.280 --> 00:02:18.280
叫做 Fast-Jev-Compaction

00:02:18.280 --> 00:02:20.400
這個套件的策略非常極端

00:02:20.400 --> 00:02:22.640
它主打的是逐字保留

00:02:22.640 --> 00:02:24.680
以及得分刪除法

00:02:24.680 --> 00:02:27.080
也就是說 它不打果汁了

00:02:27.080 --> 00:02:30.000
它是把你確定已經過期的食材

00:02:30.000 --> 00:02:31.880
整包連同包裝袋

00:02:31.880 --> 00:02:33.400
直接丟進垃圾桶

00:02:33.400 --> 00:02:35.640
而留下來的每一顆蘋果

00:02:35.640 --> 00:02:37.360
都是百分之百原封不動

00:02:37.360 --> 00:02:38.520
非常新鮮的

00:02:38.520 --> 00:02:40.720
沒錯 這就是它的核心理念

00:02:40.720 --> 00:02:42.280
所以今天的任務

00:02:42.280 --> 00:02:45.280
我們就是要來拆解這套機制的底層邏輯

00:02:45.280 --> 00:02:48.360
比如它能省下多少 Token

00:02:48.360 --> 00:02:49.560
如果是很短的對話

00:02:49.560 --> 00:02:51.120
會不會反而增加成本

00:02:51.120 --> 00:02:53.680
還有對我們台灣的中小企業來說

00:02:53.680 --> 00:02:55.960
這到底能不能真正落地

00:02:55.960 --> 00:02:58.960
這些實務問題都非常關鍵

00:02:58.960 --> 00:03:02.320
那我們先從它的保鮮機制談起好了

00:03:02.320 --> 00:03:04.280
我注意到來源資料裡提到

00:03:04.280 --> 00:03:06.880
它會把每一筆工具呼叫

00:03:06.880 --> 00:03:09.720
就是 Tool Use 跟它的結果 Tool Result

00:03:09.720 --> 00:03:11.320
成對地綁定在一起

00:03:11.320 --> 00:03:14.400
對 這是它運作的最基礎基石

00:03:14.400 --> 00:03:16.120
因為在 Cloud Code 這種

00:03:16.120 --> 00:03:17.880
會瘋狂呼叫終端機

00:03:17.880 --> 00:03:20.040
或者是讀取檔案的環境中

00:03:20.040 --> 00:03:22.160
工具的操作跟回傳結果

00:03:22.160 --> 00:03:23.680
是絕對不能脫鉤的

00:03:23.680 --> 00:03:26.800
了解 那它怎麼決定誰該留下來

00:03:26.800 --> 00:03:28.120
系統有一個叫做

00:03:28.120 --> 00:03:30.440
Preserve Recent Messages 的設定

00:03:30.440 --> 00:03:31.720
預設值是 6

00:03:31.720 --> 00:03:35.240
意思是最新發生的前 6 筆對話訊息

00:03:35.240 --> 00:03:37.440
會被加上精選的保護罩

00:03:37.440 --> 00:03:38.200
精選

00:03:38.200 --> 00:03:40.360
所以這 6 筆是絕對安全的

00:03:40.360 --> 00:03:41.400
絕對不碰

00:03:41.400 --> 00:03:44.160
它保證你當下正在處理的邏輯

00:03:44.160 --> 00:03:45.280
不會被刪掉

00:03:45.280 --> 00:03:46.320
但挑戰來了

00:03:46.320 --> 00:03:48.480
如果要請 Jev 這個模型

00:03:48.480 --> 00:03:49.840
來幫我們評估那些

00:03:49.840 --> 00:03:53.320
沒被勾選的舊資料該不該刪

00:03:53.320 --> 00:03:55.800
我們得把整個長篇大論的歷史記錄

00:03:55.800 --> 00:03:56.840
傳送給它對吧

00:03:56.840 --> 00:03:59.560
沒錯 這就是一個潛在的瓶頸

00:03:59.560 --> 00:04:01.400
Jev 本身的上下文上限

00:04:01.400 --> 00:04:03.480
是 32K 個 Token

00:04:03.480 --> 00:04:06.000
如果在傳送評估的路上就先爆了

00:04:06.000 --> 00:04:07.480
那這個壓縮工具

00:04:07.480 --> 00:04:08.720
不就毫無意義了嗎

00:04:08.720 --> 00:04:11.200
所以開發者為了解決這個問題

00:04:11.200 --> 00:04:14.360
設定了一個 Max State Tokens 的上限

00:04:14.360 --> 00:04:16.120
預設是 25,000

00:04:16.120 --> 00:04:18.040
25,000 留了一點緩衝空間

00:04:18.040 --> 00:04:21.920
對 而且為了在不拖慢系統速度的前提下

00:04:21.920 --> 00:04:23.840
估算這 25,000 個 Token

00:04:23.840 --> 00:04:25.880
它放棄了傳統那種

00:04:25.880 --> 00:04:28.240
精確但很笨重的分詞器

00:04:28.240 --> 00:04:29.600
不用 Tokenizer

00:04:29.600 --> 00:04:30.680
那它怎麼算

00:04:30.680 --> 00:04:33.840
它直接用字元來進行粗略的估算

00:04:33.840 --> 00:04:35.600
等一下 用字元算

00:04:35.600 --> 00:04:37.760
這在英文環境或許說得通

00:04:37.760 --> 00:04:39.880
大約 6 個英文字母算一個詞

00:04:39.880 --> 00:04:41.360
數字算半個 Token

00:04:41.360 --> 00:04:42.720
標點符號算一個

00:04:42.720 --> 00:04:45.320
這是一種為了效能妥協的做法

00:04:45.320 --> 00:04:48.200
沒錯 這是一種啟發式演算法

00:04:48.200 --> 00:04:50.520
可是這在我們台灣的實務應用上

00:04:50.520 --> 00:04:52.280
根本是個隱形地雷吧

00:04:52.280 --> 00:04:54.680
你想想看 如果使用者的 Prompt

00:04:54.680 --> 00:04:56.880
或者那個巨大的 JSON 報表裡

00:04:56.880 --> 00:04:58.360
塞滿了繁體中文呢

00:04:58.360 --> 00:05:00.480
哇 這裡真的講到重點了

00:05:00.480 --> 00:05:02.720
在大多數大型語言模型裡

00:05:02.720 --> 00:05:06.320
一個繁體中文字可能就會消耗 2 到 3 個 Token

00:05:06.320 --> 00:05:08.440
如果系統還傻傻地以為

00:05:08.440 --> 00:05:10.520
6 個中文字才等於 1 個 Token

00:05:10.520 --> 00:05:13.840
這絕對會嚴重低估真實的 Token 數量

00:05:13.840 --> 00:05:16.440
這個實務觀察真的非常敏銳

00:05:16.440 --> 00:05:19.400
這個開源專案目前的設計思維

00:05:19.400 --> 00:05:21.960
確實帶有強烈的英語系

00:05:21.960 --> 00:05:23.600
跟程式碼本位色彩

00:05:23.600 --> 00:05:25.880
對 最後送給 Jev 的時候

00:05:25.880 --> 00:05:29.040
肯定會直接撞破 32K 的上限

00:05:29.040 --> 00:05:30.440
導致 API 報錯

00:05:30.440 --> 00:05:34.080
這也是為什麼它把安全水位設在 25,000

00:05:34.080 --> 00:05:36.400
留了足足 7K 的緩衝

00:05:36.400 --> 00:05:40.280
但對於大量處理中文文本的團隊來說

00:05:40.280 --> 00:05:42.120
技術主管在導入時

00:05:42.120 --> 00:05:44.920
絕對需要注意這個資源估算的比例

00:05:44.920 --> 00:05:47.000
了解 要特別小心

00:05:47.000 --> 00:05:49.320
不過撇除中文字元的問題

00:05:49.320 --> 00:05:53.360
當它發現資源數真的超過了 25,000 的限制

00:05:53.360 --> 00:05:55.440
我看到資料說它的處理手法

00:05:55.440 --> 00:05:57.080
叫做多階段處理

00:05:57.080 --> 00:05:58.760
對 Stage Based Fitting

00:05:58.760 --> 00:06:00.600
它的做法相當精妙

00:06:00.600 --> 00:06:01.960
讓我推演一下

00:06:01.960 --> 00:06:04.880
假設我有一個 5000 行的系統日誌

00:06:04.880 --> 00:06:07.240
它總不可能直接放棄壓縮吧

00:06:07.240 --> 00:06:10.240
它一定是從那些最肥大的參數開刀

00:06:10.240 --> 00:06:11.200
完全正確

00:06:11.200 --> 00:06:14.320
第一階段 它會把所有沒被勾選的

00:06:14.320 --> 00:06:15.840
舊工具輸入參數

00:06:15.840 --> 00:06:18.240
硬生生壓縮到 1000 個字元

00:06:18.240 --> 00:06:19.200
1000 個字元

00:06:19.200 --> 00:06:21.080
所以它把中間挖空了嗎

00:06:21.080 --> 00:06:23.440
沒錯 它只保留開頭跟結尾

00:06:23.440 --> 00:06:26.120
把中間龐大的資料直接捨棄

00:06:26.120 --> 00:06:29.840
所以它保留了工具曾經被執行過的形狀

00:06:29.840 --> 00:06:31.000
但捨棄了內容

00:06:31.000 --> 00:06:33.160
那如果挖空到 1000 字元

00:06:33.160 --> 00:06:35.400
算一算還是超過 25,000 呢

00:06:35.400 --> 00:06:36.920
那它就會變得更殘酷一點

00:06:36.920 --> 00:06:38.320
進入第二階段

00:06:38.320 --> 00:06:40.280
把限制縮減到 200 個字元

00:06:40.280 --> 00:06:42.760
200 字元真的很少了

00:06:42.760 --> 00:06:45.560
如果再不行 就砍到極限的 60 個字

00:06:45.560 --> 00:06:48.160
到最後如果還是塞不進去

00:06:48.160 --> 00:06:50.160
那些很久以前的舊訊息

00:06:50.160 --> 00:06:53.080
會被徹底折疊成一句簡單的短語

00:06:53.080 --> 00:06:54.760
像是一句註解那樣嗎

00:06:54.760 --> 00:06:57.160
對 例如省略 N 個字元

00:06:57.160 --> 00:06:59.480
就這樣一步一步削肉剔骨

00:06:59.480 --> 00:07:01.440
直到整包資料的估算值

00:07:01.440 --> 00:07:03.960
能安全塞進 25,000 的限制裡

00:07:03.960 --> 00:07:06.400
再送給 Jev 去做最後的決策

00:07:06.400 --> 00:07:10.200
哇 這種在極限狀態下的多階段處理邏輯

00:07:10.200 --> 00:07:11.640
對我們工程師來說

00:07:11.640 --> 00:07:13.840
真的是一個很棒的價值提升

00:07:13.840 --> 00:07:14.400
怎麼說

00:07:14.400 --> 00:07:16.200
就是在系統設計時

00:07:16.200 --> 00:07:18.720
為了追求極致的效能跟穩定

00:07:18.720 --> 00:07:21.080
其實你不一定需要追求百分之百

00:07:21.080 --> 00:07:22.320
精確的 Token 計算

00:07:22.320 --> 00:07:24.280
用簡單的資源估算

00:07:24.280 --> 00:07:26.120
搭配多層次的安全防線

00:07:26.120 --> 00:07:28.120
實務上不僅運作更快

00:07:28.120 --> 00:07:29.560
容錯率也更高

00:07:29.560 --> 00:07:31.400
工程思維的精髓

00:07:31.400 --> 00:07:34.080
就是用最小的算力成本

00:07:34.080 --> 00:07:36.520
換取最大的系統穩定度

00:07:36.520 --> 00:07:37.920
但講到成本

00:07:37.920 --> 00:07:41.080
這就衍生出另一個很現實的問題了

00:07:41.080 --> 00:07:41.840
什麼問題

00:07:41.840 --> 00:07:45.360
如果今天我這個除錯任務其實很簡單

00:07:45.360 --> 00:07:48.240
我只跟 AI 來回對話了三四次

00:07:48.240 --> 00:07:50.000
上下文根本還很空

00:07:50.000 --> 00:07:52.640
為了清理那一點點的歷史記錄

00:07:52.640 --> 00:07:54.960
我還要特地把資料打包

00:07:54.960 --> 00:07:58.760
傳送一個 API 請求給 Jev 去做評分

00:07:58.760 --> 00:08:01.520
這反而多花了一筆 API 費用

00:08:01.520 --> 00:08:02.920
甚至增加了網路延遲對吧

00:08:02.920 --> 00:08:05.080
沒錯 這樣感覺很不划算

00:08:05.080 --> 00:08:07.000
其實這個外掛並沒有那麼死板

00:08:07.000 --> 00:08:08.240
在系統內部

00:08:08.240 --> 00:08:11.040
它設定了一個參數叫做 Reduction Ratio

00:08:11.040 --> 00:08:12.760
也就是壓縮比例

00:08:12.760 --> 00:08:14.880
哦 所以它會先算帳

00:08:14.880 --> 00:08:17.320
對 當 Jev 評估完畢

00:08:17.320 --> 00:08:18.920
準備動刀刪除之前

00:08:18.920 --> 00:08:20.600
系統會先預估一下

00:08:20.600 --> 00:08:24.360
如果預計能砍掉的內容比例小於 0.25

00:08:24.360 --> 00:08:28.920
也就是說 Jev 認為能刪掉的廢話不到四分之一

00:08:28.920 --> 00:08:30.240
系統就會判斷說

00:08:30.240 --> 00:08:32.040
這套壓縮根本不划算

00:08:32.040 --> 00:08:32.800
馬上停損

00:08:32.800 --> 00:08:33.560
就是這樣

00:08:33.560 --> 00:08:36.320
它會直接退回原本的完整對話

00:08:36.320 --> 00:08:38.440
或者 Fallback 回去使用

00:08:38.440 --> 00:08:40.600
Cloud Code 內建的裁減機制

00:08:40.600 --> 00:08:43.120
它不會為了展現自己會壓縮

00:08:43.120 --> 00:08:45.440
而硬去執行無效的操作

00:08:45.440 --> 00:08:48.240
懂得及時停損是很聰明的設計

00:08:48.240 --> 00:08:50.520
但如果我們把目光放遠一點

00:08:50.520 --> 00:08:53.240
考慮到企業長期的技術選型

00:08:53.240 --> 00:08:56.440
我們最怕的其實是被單一廠商綁架

00:08:56.440 --> 00:08:57.560
Vendor Lock-in

00:08:57.560 --> 00:09:00.920
這確實是企業導入新技術時最大的顧慮

00:09:00.920 --> 00:09:04.400
對啊 今天這個套件是為 Jev 模型設計的

00:09:04.400 --> 00:09:07.720
如果我不想把資料打給 TypeSafe 的 API

00:09:07.720 --> 00:09:10.200
或者我們公司已經買了大量的

00:09:10.200 --> 00:09:12.200
OpenAI 或 Anthropic 的額度

00:09:12.200 --> 00:09:14.320
這套機制還有用武之地嗎

00:09:14.320 --> 00:09:15.920
來源文件雖然沒有明說

00:09:15.920 --> 00:09:18.160
它原生內建了所有主流模型

00:09:18.160 --> 00:09:21.240
但它刻意留下了一道非常寬廣的後門

00:09:21.240 --> 00:09:23.560
開發者可以自行實作一個

00:09:23.560 --> 00:09:25.520
名為 Jev Asker 的介面

00:09:25.520 --> 00:09:26.800
Jev Asker

00:09:26.800 --> 00:09:29.760
意思是只要我符合這個介面的標準

00:09:29.760 --> 00:09:31.760
我背後要接誰都可以

00:09:31.760 --> 00:09:34.920
沒錯 只要你能寫出一個 Ask 的方法

00:09:34.920 --> 00:09:37.680
你就可以自行撰寫底層的傳輸邏輯

00:09:37.680 --> 00:09:40.960
而且這個專案是作為 NPM 模組發布的

00:09:40.960 --> 00:09:42.920
所以它可以直接裝在專案裡

00:09:42.920 --> 00:09:45.480
對 它還大方地匯出了像是

00:09:45.480 --> 00:09:46.840
Compact Messages

00:09:46.840 --> 00:09:49.720
Collect Tool Calls 這些核心函式

00:09:49.720 --> 00:09:51.480
這些就像是樂高積木一樣

00:09:51.480 --> 00:09:53.400
這對於技術主管來說

00:09:53.400 --> 00:09:55.000
真的是一盒定心丸

00:09:55.000 --> 00:09:58.640
這種模組化暴露出核心介面的設計

00:09:58.640 --> 00:10:02.880
意味著我們甚至可以把這套刪除法的演算法

00:10:02.880 --> 00:10:07.400
抽離出來 改寫整合到公司內部的私有 AI 系統中

00:10:07.400 --> 00:10:10.200
這樣技術綁架的風險就趨近於零了

00:10:10.200 --> 00:10:11.760
既然機制這麼彈性

00:10:11.760 --> 00:10:14.200
那我們就得來檢驗它的心臟了

00:10:14.200 --> 00:10:17.800
它到底是怎麼給出那個所謂的刪除得分的

00:10:17.800 --> 00:10:19.480
它的評分機制是這樣

00:10:19.480 --> 00:10:23.240
Jev 會針對每一個沒被勾選的工具呼叫

00:10:23.240 --> 00:10:25.640
問兩個非常刁鑽的問題

00:10:25.640 --> 00:10:26.840
哪兩個問題

00:10:26.840 --> 00:10:30.600
第一 這個呼叫的記錄本身該留下來嗎

00:10:30.600 --> 00:10:32.160
知道它曾經被執行過

00:10:32.160 --> 00:10:34.280
對接下來的任務還重要嗎

00:10:34.280 --> 00:10:36.800
嗯 這是評估動作本身

00:10:36.800 --> 00:10:37.840
那第二個呢

00:10:37.840 --> 00:10:41.880
第二 這個執行的結果該原封不動保留嗎

00:10:41.880 --> 00:10:43.480
還是其實可以刪掉

00:10:43.480 --> 00:10:46.720
大不了讓 AI 發現缺資料時重新跑一次

00:10:46.720 --> 00:10:50.720
哦 所以它把動作跟結果分開來評估

00:10:50.720 --> 00:10:52.560
那幾個分數是多少

00:10:52.560 --> 00:10:56.360
系統依賴一個預設為 0.5 的 keep threshold

00:10:56.360 --> 00:10:57.880
也就是保留門檻

00:10:57.880 --> 00:10:59.680
大於 0.5 就保留嗎

00:10:59.680 --> 00:11:03.800
對 如果 Jev 給出保留結果的機率大於 0.5

00:11:03.800 --> 00:11:05.880
那就整組完好無缺地留下

00:11:05.880 --> 00:11:08.960
那如果結果不重要 但動作很重要呢

00:11:08.960 --> 00:11:10.800
如果保留結果的機率不高

00:11:10.800 --> 00:11:13.560
但保留動作記錄的機率大於 0.5

00:11:13.560 --> 00:11:15.560
它就會把那份龐大的結果

00:11:15.560 --> 00:11:17.240
截斷到前 300 個字元

00:11:17.240 --> 00:11:18.840
並加上一行註解

00:11:18.840 --> 00:11:21.040
告訴 AI 這裡曾經發生過什麼

00:11:21.040 --> 00:11:24.560
了解 那如果兩個機率都低於 0.5 呢

00:11:24.560 --> 00:11:26.520
那就是整組直接超度

00:11:26.520 --> 00:11:27.520
完全刪除

00:11:27.520 --> 00:11:30.280
超度 這形容很貼切

00:11:30.280 --> 00:11:32.520
邏輯聽起來很縝密啦

00:11:32.520 --> 00:11:35.600
但我們都知道 機率不代表絕對

00:11:35.600 --> 00:11:38.600
萬一 Jev 今天就是判斷失誤

00:11:38.600 --> 00:11:41.280
把一個超級關鍵的記錄給刪了

00:11:41.280 --> 00:11:43.440
導致模型徹底忘記了

00:11:43.440 --> 00:11:44.240
剛剛讀過的檔名

00:11:44.240 --> 00:11:46.160
這時候補救機制是什麼

00:11:46.160 --> 00:11:48.920
開發者在畫面上其實不會瞎子摸象

00:11:48.920 --> 00:11:50.840
你會看到一個 Toast 提示

00:11:50.840 --> 00:11:53.400
明確告訴你保留了幾筆訊息

00:11:53.400 --> 00:11:56.160
但如果真的誤刪了關鍵資訊怎麼辦

00:11:56.160 --> 00:11:58.920
文件也坦承這項技術有它的局限

00:11:58.920 --> 00:12:00.440
如果真的刪錯了

00:12:00.440 --> 00:12:02.400
其實補救方式非常直覺

00:12:02.400 --> 00:12:04.960
因為你是在具有代理能力的環境裡

00:12:04.960 --> 00:12:07.760
AI 如果發現自己缺少某個參數

00:12:07.760 --> 00:12:10.000
它可以隨時再次執行該工具

00:12:10.000 --> 00:12:12.640
大不了就是讓 AI 再花個幾秒鐘

00:12:12.640 --> 00:12:14.320
重新讀一次檔案

00:12:14.320 --> 00:12:15.960
這成本還算可以接受

00:12:15.960 --> 00:12:20.440
除此之外 為了確保系統不會因為 API 連線失敗

00:12:20.440 --> 00:12:21.320
而整組崩潰

00:12:21.320 --> 00:12:23.480
作者在寫單元測試的時候

00:12:23.480 --> 00:12:26.080
特別實作了一個不聯網的 Fake Jev

00:12:26.080 --> 00:12:28.120
不聯網的假 Jev

00:12:28.120 --> 00:12:29.800
這有什麼好處

00:12:29.800 --> 00:12:31.840
這確保了在真實情境中

00:12:31.840 --> 00:12:34.440
萬一 Jev 回傳了破損的 JSON

00:12:34.440 --> 00:12:36.320
或是網路直接斷線

00:12:36.320 --> 00:12:40.160
系統能百分之百順暢地執行優雅降級

00:12:40.160 --> 00:12:41.640
優雅降級

00:12:41.640 --> 00:12:43.480
也就是無縫切換回

00:12:43.480 --> 00:12:45.840
Cloud Code 原本內建的裁減機制對吧

00:12:45.840 --> 00:12:46.800
完全正確

00:12:46.800 --> 00:12:49.320
有降級機制確實讓人安心

00:12:49.320 --> 00:12:51.920
但說到聯網打 API

00:12:51.920 --> 00:12:55.440
我們就必須面對企業導入時最大的心魔了

00:12:55.440 --> 00:12:57.040
那就是資安

00:12:57.040 --> 00:12:59.400
沒錯 這真的是重中之重

00:12:59.400 --> 00:13:02.200
任何會把資料往外送的外掛

00:13:02.200 --> 00:13:04.920
在公司內部都會面臨嚴格的審查

00:13:04.920 --> 00:13:08.680
對 這部分資料裡有提到什麼防護機制嗎

00:13:08.680 --> 00:13:10.080
這是今天最核心

00:13:10.080 --> 00:13:12.360
最需要劃重點的資安警告

00:13:12.360 --> 00:13:16.320
這個套件在運作時 你需要填寫 API Key

00:13:16.320 --> 00:13:19.320
而且它會將你那份完整的對話記錄

00:13:19.320 --> 00:13:21.600
包含所有的工具輸入參數

00:13:21.600 --> 00:13:24.680
毫無保留地傳送到 TypeSafe 的伺服器

00:13:24.680 --> 00:13:26.520
等一下 毫無保留

00:13:26.520 --> 00:13:31.840
也就是說 如果我的程式碼裡夾帶了 AWS 的機密金鑰

00:13:31.840 --> 00:13:35.440
或者我們公司核心產品還沒公開的商業邏輯

00:13:35.440 --> 00:13:38.000
這些都會變成純文字

00:13:38.000 --> 00:13:40.120
直接送到別人的伺服器上

00:13:40.120 --> 00:13:40.920
毫不設防

00:13:40.920 --> 00:13:41.720
完全會

00:13:41.720 --> 00:13:43.960
來源文件完全沒有提到

00:13:43.960 --> 00:13:47.440
任何內建的自動過濾或清理敏感資訊的機制

00:13:47.440 --> 00:13:49.200
哇 這太危險了吧

00:13:49.200 --> 00:13:52.280
作者反而在 README 裡非常用力地警告大家

00:13:52.280 --> 00:13:55.080
絕對不要把金鑰提交到原始碼中

00:13:55.080 --> 00:13:56.400
這等於是在暗示

00:13:56.400 --> 00:14:00.240
資料的對外傳輸是完全透明且具有風險的

00:14:00.240 --> 00:14:02.560
這件事對台灣的中小企業

00:14:02.560 --> 00:14:05.400
資安公司或是企業內部團隊來說

00:14:05.400 --> 00:14:06.320
太關鍵了

00:14:06.320 --> 00:14:07.120
非常關鍵

00:14:07.120 --> 00:14:10.320
我們常常看到工程師為了解決眼前的

00:14:10.320 --> 00:14:11.800
Context 爆滿痛點

00:14:11.800 --> 00:14:14.400
上網隨手就裝了一個開源工具

00:14:14.400 --> 00:14:16.240
這裡的實務提醒是

00:14:16.240 --> 00:14:19.240
如果你的專案牽涉到任何商業機密

00:14:19.240 --> 00:14:23.240
絕對不能在沒有自建防線的情況下直接套用

00:14:23.240 --> 00:14:25.640
沒錯 這也呼應了前面提到的

00:14:25.640 --> 00:14:26.760
Jev Asker 介面

00:14:26.760 --> 00:14:28.960
如果企業真的要導入

00:14:28.960 --> 00:14:31.560
技術團隊必須自己寫一個中介層

00:14:31.560 --> 00:14:34.240
在把資料送出去給 Jev 評分之前

00:14:34.240 --> 00:14:37.040
先在本地端把敏感資訊過濾掉

00:14:37.040 --> 00:14:39.480
企業的底線是不能妥協的

00:14:39.480 --> 00:14:41.720
但其實即使資安這關過了

00:14:41.720 --> 00:14:44.320
技術團隊還要面對另一個深淵

00:14:44.320 --> 00:14:46.480
那就是部署的摩擦力

00:14:46.480 --> 00:14:47.920
部署的坑真的很多

00:14:47.920 --> 00:14:51.120
技術再好 如果無法順暢地部署到

00:14:51.120 --> 00:14:52.880
每一位工程師的電腦上

00:14:52.880 --> 00:14:55.880
或者沒辦法放進 CI/CD 的流程裡

00:14:55.880 --> 00:14:56.880
那也是白搭

00:14:56.880 --> 00:14:59.040
我看到文件特別提到

00:14:59.040 --> 00:15:02.400
這個機制依賴 Cloud Code 的 Function Hooks 功能

00:15:02.400 --> 00:15:03.840
對 麻煩就在於

00:15:03.840 --> 00:15:06.280
這個功能目前還處於早期測試階段

00:15:06.280 --> 00:15:08.080
所以它不是 NPM 安裝完

00:15:08.080 --> 00:15:09.920
就能無腦啟動的

00:15:09.920 --> 00:15:11.240
遠比那複雜

00:15:11.240 --> 00:15:12.560
你必須在環境變數

00:15:12.560 --> 00:15:14.520
或者是本機的設定檔裡

00:15:14.520 --> 00:15:17.800
強制宣告一個全域變數來開啟這個功能

00:15:17.800 --> 00:15:20.240
哦 要手動去開 Feature Flag

00:15:20.240 --> 00:15:22.760
對 這代表團隊裡的每一個使用環境

00:15:22.760 --> 00:15:24.960
包括每位新進員工的筆電

00:15:24.960 --> 00:15:27.200
或是雲端的 CI/CD 伺服器

00:15:27.200 --> 00:15:30.240
都必須先經歷這個手動開啟的步驟

00:15:30.240 --> 00:15:31.840
否則外掛根本不會動

00:15:31.840 --> 00:15:34.400
哇 這對 DevOps 團隊來說

00:15:34.400 --> 00:15:35.720
絕對是個大坑啊

00:15:35.720 --> 00:15:37.600
推廣新工具時

00:15:37.600 --> 00:15:39.840
只要多一個手動設定步驟

00:15:39.840 --> 00:15:41.480
採用率就會掉一半

00:15:41.480 --> 00:15:43.520
確實會增加初期的推廣成本

00:15:43.520 --> 00:15:45.960
不過談到推廣跟說服

00:15:45.960 --> 00:15:49.360
我注意到作者做了一件讓我非常驚艷的事情

00:15:49.360 --> 00:15:53.600
他為了展示這套抽象的得分刪除法技術

00:15:53.600 --> 00:15:57.360
特地寫了一個 macOS 原生的 Swift UI App

00:15:57.360 --> 00:15:59.600
只為了錄製一段展示影片

00:15:59.600 --> 00:16:01.840
這在開源推廣上真的非常聰明

00:16:01.840 --> 00:16:03.760
對啊 為什麼他不直接錄個

00:16:03.760 --> 00:16:05.680
無聊的終端機畫面就好

00:16:05.680 --> 00:16:07.200
還要特地寫個 App

00:16:07.200 --> 00:16:08.840
這個 App 其實從頭到尾

00:16:08.840 --> 00:16:10.440
都沒有呼叫任何真實的 API

00:16:10.440 --> 00:16:12.400
它裡面顯示的對話跟決策

00:16:12.400 --> 00:16:14.600
全都是用腳本預先寫實的

00:16:14.600 --> 00:16:17.360
它純粹就是為了視覺化演出而生的

00:16:17.360 --> 00:16:18.640
視覺化演出

00:16:18.640 --> 00:16:20.640
它具體演出的是什麼效果

00:16:20.640 --> 00:16:22.360
當你在畫面上看到一長串

00:16:22.360 --> 00:16:23.560
密密麻麻的歷史記錄

00:16:23.560 --> 00:16:26.880
系統判定哪些舊的呼叫是不需要的廢話時

00:16:26.880 --> 00:16:29.640
那些文字會直接在畫面上變成紅色

00:16:29.640 --> 00:16:31.800
然後動態地折疊消失

00:16:31.800 --> 00:16:34.400
哇 變成紅色然後消失

00:16:34.400 --> 00:16:36.760
這種視覺衝擊力太強了吧

00:16:36.760 --> 00:16:39.600
對一個沒時間看長篇技術文件的技術主管

00:16:39.600 --> 00:16:40.960
或非技術老闆來說

00:16:40.960 --> 00:16:42.600
這幾秒鐘的動態裁剪

00:16:42.600 --> 00:16:45.680
能讓他們瞬間看懂這個技術的核心價值

00:16:45.680 --> 00:16:48.400
這裡有一個超棒的實務應用價值

00:16:48.400 --> 00:16:50.360
如果我們是工程師

00:16:50.360 --> 00:16:52.040
準備向老闆提案導入

00:16:52.040 --> 00:16:55.280
這種可以幫公司省 API 費用的新架構

00:16:55.280 --> 00:16:56.680
嗯 你要怎麼說服他

00:16:56.680 --> 00:16:59.360
與其貼出一堆冷冰冰的 Lockdown

00:16:59.360 --> 00:17:01.200
或是 Token 節省數據

00:17:01.200 --> 00:17:05.400
不如學學這種視覺化展示核心邏輯的手法

00:17:05.400 --> 00:17:08.440
老闆一看紅字消失 馬上就知道

00:17:08.440 --> 00:17:09.920
哦 垃圾被清掉了

00:17:09.920 --> 00:17:11.560
有用的東西還在

00:17:11.560 --> 00:17:13.000
而且我們省錢了

00:17:13.000 --> 00:17:15.800
沒錯 能把深奧的底層邏輯

00:17:15.800 --> 00:17:17.600
轉化為直覺的視覺

00:17:17.600 --> 00:17:20.720
有時候比寫出這段程式碼還要困難

00:17:20.720 --> 00:17:23.560
這絕對是提升競爭力的好方法

00:17:23.560 --> 00:17:28.640
聊到這裡我們最後來宏觀地檢視一下產業趨勢

00:17:28.640 --> 00:17:30.080
面對上下文爆滿

00:17:30.080 --> 00:17:32.120
目前業界有遮蔽法

00:17:32.120 --> 00:17:35.400
有直接砍掉舊對話的滑動視窗

00:17:35.400 --> 00:17:37.320
還有傳統的摘要法

00:17:37.320 --> 00:17:40.200
GMV 帶來的這種得分刪除

00:17:40.200 --> 00:17:42.160
未來真的會成為主流嗎

00:17:42.160 --> 00:17:44.760
它還有什麼無法跨越的曲線

00:17:44.760 --> 00:17:47.040
滑動視窗雖然簡單粗暴

00:17:47.040 --> 00:17:50.200
但大家都意識到它會無可避免地

00:17:50.200 --> 00:17:52.880
遺失早期設定的系統約束條件

00:17:52.880 --> 00:17:56.760
GMV 確實在精確度上開創了一個新流派

00:17:56.760 --> 00:18:00.240
但它目前有一個非常硬傷的缺陷

00:18:00.240 --> 00:18:01.400
什麼缺陷

00:18:01.400 --> 00:18:04.960
在最終輸出實際保留下來的歷史記錄裡

00:18:04.960 --> 00:18:06.440
純文字訊息

00:18:06.440 --> 00:18:08.640
也就是人類跟 AI 講的話

00:18:08.640 --> 00:18:10.800
永遠不會被移除或縮減

00:18:10.800 --> 00:18:14.160
等等 也就是說如果使用者自己打字

00:18:14.160 --> 00:18:16.000
貼了幾萬字的會議記錄

00:18:16.000 --> 00:18:18.120
甚至是一堆無意義的廢話

00:18:18.120 --> 00:18:21.160
這個外掛其實拿它一點辦法都沒有

00:18:21.160 --> 00:18:22.120
一點辦法都沒有

00:18:22.120 --> 00:18:26.520
純文字只會在傳給 GMV 評估的那個狀態中

00:18:26.520 --> 00:18:27.120
被縮減

00:18:27.120 --> 00:18:30.240
但最終真實保留在上下文裡的記錄

00:18:30.240 --> 00:18:33.720
人類打的純文字會被百分之百完整保留

00:18:33.720 --> 00:18:36.680
所以它只管工具呼叫的記錄

00:18:36.680 --> 00:18:39.440
對 GMV 的權限僅限於決定

00:18:39.440 --> 00:18:41.240
要不要刪除工具呼叫

00:18:41.240 --> 00:18:42.480
跟工具回傳結果

00:18:42.480 --> 00:18:44.400
這個誤區非常重要

00:18:44.400 --> 00:18:47.280
這意味著企業在評估導入時

00:18:47.280 --> 00:18:49.280
絕對不能抱持著說

00:18:49.280 --> 00:18:52.440
哦 我裝了這個就能無腦壓縮所有人類對話

00:18:52.440 --> 00:18:53.960
這是一個錯誤期待

00:18:53.960 --> 00:18:56.720
沒錯 它是一把極端特化的手術刀

00:18:56.720 --> 00:18:59.120
它最佳的發揮舞台是那種

00:18:59.120 --> 00:19:01.440
多代理人瘋狂反覆執行工具

00:19:01.440 --> 00:19:05.960
在背後產生大量 JSON 報表與錯誤日誌的自動化任務

00:19:05.960 --> 00:19:07.600
只有在這種情境下

00:19:07.600 --> 00:19:11.160
大量的無效系統痕跡才可以被精準抹除

00:19:11.160 --> 00:19:13.320
但如果是人類純聊天

00:19:13.320 --> 00:19:15.960
它的節省效果其實微乎其微

00:19:15.960 --> 00:19:18.840
對 這點在導入前一定要評估清楚

00:19:18.840 --> 00:19:22.000
所以真的是要把刀用在刀口上

00:19:22.000 --> 00:19:25.840
針對自動化與工具密集的任務去應用

00:19:25.840 --> 00:19:29.280
才能最大化節省 Token 的投資報酬率

00:19:29.280 --> 00:19:32.640
今天的解析真的非常精彩

00:19:32.640 --> 00:19:34.480
從果汁機的殘酷比喻

00:19:34.480 --> 00:19:36.840
到多階段處理的精妙

00:19:36.840 --> 00:19:39.280
還有繁體中文的潛在風險

00:19:39.280 --> 00:19:42.360
甚至資安防護跟視覺化展示

00:19:42.360 --> 00:19:44.400
這讓我們不禁反思

00:19:44.400 --> 00:19:46.720
在未來 AI 越變越強的時代

00:19:46.720 --> 00:19:51.160
我們真的需要讓 AI 記住所有的摸索與錯誤過程嗎

00:19:51.160 --> 00:19:56.760
還是其實只要讓它記住關鍵的結論與原始資料就足夠了

00:19:56.760 --> 00:19:58.680
今天最後的實務提醒是

00:19:58.680 --> 00:20:00.640
看到新的開源工具

00:20:00.640 --> 00:20:04.200
大家不要只看表面上宣稱省了多少 Token

00:20:04.200 --> 00:20:07.080
一定要往底層看它的資料流向

00:20:07.080 --> 00:20:08.960
有沒有資安過濾機制

00:20:08.960 --> 00:20:12.680
能不能真正安全地落地到你們公司的規範中

00:20:12.680 --> 00:20:15.760
沒錯 安全永遠是第一考量

00:20:15.760 --> 00:20:18.240
喜歡我們的深入分析討論嗎

00:20:18.240 --> 00:20:21.000
記得轉發給有需要的親朋好友

00:20:21.000 --> 00:20:24.240
並且幫我們按讚訂閱開啟小鈴鐺

00:20:24.240 --> 00:20:26.320
更多相關資訊連結

00:20:26.320 --> 00:20:28.440
請參考影片下方的資訊欄

00:20:28.440 --> 00:20:29.920
最後感謝您的收聽

00:20:29.920 --> 00:20:32.040
祝您順心 我們下集再會

00:20:32.040 --> 00:20:33.080
拜拜