影片筆記：EP404 - Jev 橫空出世！前OpenAI研究員打造專注結構化決策的工具，速度 200x，徹底解決 LLM 格式不穩定的致命缺陷！

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

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

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

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

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

介紹由前 OpenAI 研究員開發的 Jerby（亦稱 Jav/Jeff/JAB），這是一款專注於結構化決策的 System 1 Model。透過 Constraint Decoding（約束解碼） 技術，Jerby 能確保輸出格式 100% 符合預定義 Schema，解決 LLM 常見的格式不穩定問題，同時具備比傳統 Transformer 快 20-200 倍的速度與極低成本，建議與大型語言模型結合形成「雙腦架構」以提升自動化效率。

核心重點

1. LLM 格式不穩定的痛點：主流 LLM 基於機率預測，常輸出錯誤格式（如多加 Markdown 反引號、將數字轉為字串），導致開發者需花費大量時間撰寫驗證與容錯邏輯。
2. Jerby 的核心技術：Constraint Decoding：

• 在推理層面直接遮擋不符合 Schema 的選項。
• 若欄位定義為布林值，則僅允許 True 或 False，其他字詞根本不在選項內。
• 實現 Schema Safe，輸出永遠符合型別結構，無需額外驗證。

1. 三大功能：

• Choice：從選項中選擇最符合者（最多 255 個選項）。
• Score：對輸入打分數並附上信心指數（Confidence）。
• No-o：輸出 0 到 1 之間校準後的機率值。

1. 性能與成本優勢：

• 速度：比傳統 Transformer 模型快 20 到 200 倍。
• 成本：輸入每百萬 Token 0.04 美金，輸出免費。

1. 雙腦架構（Dual-Brain Architecture）：

• LLM：負責深度推理、規劃與策略（慢、貴）。
• Jerby：負責高速執行、格式保證與微決策（快、便宜）。
• 經濟效益：將昂貴推理集中在規劃階段，執行階段使用低成本引擎，使自動化流程具備規模化可行性。

1. 應用場景：

• 瀏覽器自動化：將決策延遲降至毫秒級，解決 LLM 控制瀏覽器時因延遲過高導致動作失效的問題。
• 資料抽取與格式化：從非結構化資料抽取資訊並格式化成固定格式（如寫入 CRM）。
• Vibe Coding 輔助：在 IDE 中設定背景監聽器，自動修復編譯錯誤或測試失敗。

1. 安全與風險管理：

• 速度越快，出錯代價越高，需預設將 AI 生成的程式碼視為「不信任」。
• 使用 Docker 容器隔離執行環境，給予最小必要權限（非 root）。
• 瀏覽器自動化使用獨立、一次性的工作階段。

詳細大綱

一、 痛點：LLM 自動化流程的格式崩潰

• 常見困境：開發者設計自動化流程，但 LLM 偶爾輸出錯誤格式（如數字變字串、多加 Markdown 反引號、換行或空格）。
• 後果：開發者必須花費大量時間撰寫驗證邏輯、從事機制（容錯機制）與備援處理，導致系統比手動操作更複雜。
• 根源：主流 LLM（如 ChatGPT、Astra、Fable）基於「預測下一個 Token」的機率性架構，無法保證 100% 的格式正確性。

二、 Jerby 的核心技術與定位

• 開發者：Type Safe AI。
• 定位：System 1 Model（系統 1 模型），非聊天或寫作工具，僅專注於結構化決策。
• 核心技術：Constraint Decoding（約束解碼）
• 在生成每個 Token 時，直接從詞彙表中遮擋違反 Schema 規則的選項。
• 若欄位為布林值，則僅允許選 True 或 False，其他字詞根本不在選項內。
• Schema Safe：輸出永遠符合定義的型別結構，開發者無需額外驗證。

三、 Jerby 的三大功能

1. Choice：輸入與選項清單，回傳最符合的選項（最多 255 個選項），類似精準的選擇題機器。
2. Score：對輸入打分數並附上 Confidence（信心分數），告知確定的把握程度。
3. No-o：輸出 0 到 1 之間的機率值，代表事件發生可能性，且機率經過校準（例如：說 0.8 代表 10 封中有 8 封為退款需求）。

四、 性能與成本優勢

• 速度：比傳統 Transformer 模型快 20 到 200 倍。
• 成本：輸入每百萬 Token 0.04 美金，輸出免費（被稱為「佛心價」）。
• 適用範圍：僅限於結構化決策任務（如分類、判斷），不適用於寫文章或深度推理。

五、 應用場景：瀏覽器自動化

• 問題：使用 LLM 控制瀏覽器時，延遲過高（秒級），導致網頁更新或彈窗出現後動作失效。
• 解決方案：使用 Jerby 將決策延遲降至毫秒級，讓 Agent 能即時對照 DOM 結構並輸出動作，使瀏覽器自動化從「示範」變為「生產環境可用」。

六、 架構建議：雙腦架構（Dual-Brain Architecture）

• 概念：LLM 負責策略（深度推理），Jerby 負責執行（快速決策）。
• 流程範例：

1. LLM（如 Fable/Astra）分析需求，產出詳細執行計劃（慢、貴、但需深度思考）。
2. Jerby 接手，根據計劃判斷下一步、輸出固定格式指令、處理錯誤訊息（快、便宜、格式保證）。

• 經濟效益：將昂貴的推理集中在規劃階段，執行階段使用低成本引擎，使自動化流程具備規模化可行性。

七、 實際整合切入點

1. 資料抽取與格式化：從非結構化資料（如信件）抽取資訊並格式化成固定格式（如寫入 CRM），消除格式錯誤。
2. Vibe Coding 輔助：在 IDE 中設定背景監聽器，自動將編譯錯誤或測試失敗丟給 Jerby 修復，無需手動介入。

八、 安全與風險管理

• 風險：速度越快，出錯代價越高。毫秒級執行可能導致無法即時阻止錯誤。
• 安全原則：

1. 預設將 AI 生成的程式碼視為「不信任」，不給予最高權限。
2. 使用 Docker 容器隔離執行環境，給予最小必要權限（非 root）。
3. 瀏覽器自動化使用獨立、一次性的工作階段，避免影響生產環境。

• 角色轉變：開發者從寫程式轉為設計系統架構與安全審計。

九、 總結與觀點

• 產業趨勢反思：過去追求更大、更聰明、更貴的模型（AGI），但實際開發需求多為快速、準確、格式正確的決策工具。
• Jerby 的意義：代表 AI 執行層的「工業化」，透過高度專門化的引擎分工合作，解決格式不穩定問題。

工具 / 模型 / 名詞整理

• Jerby / Jav / Jeff / JAB：本集介紹的主角工具，由 Type Safe AI 開發（逐字稿中名稱混用）。
• Type Safe AI：Jerby 的開發公司。
• System 1 Model：Jerby 的技術分類，專注於結構化決策。
• Constraint Decoding（約束解碼）：Jerby 的核心技術，透過限制輸出格式確保 Schema 安全。
• Schema Safe：Type Safe AI 對 Jerby 特性的定義，指輸出永遠符合型別結構。
• Choice：Jerby 的功能之一，從選項中選擇。
• Score：Jerby 的功能之一，打分數並附信心指數。
• No-o：Jerby 的功能之一，輸出校準後的機率值。
• LLM / 大型語言模型：泛指 ChatGPT 等模型。
• Transformer 模型：傳統模型架構。
• Docker：用於隔離執行環境的容器技術。
• VOAI：節目贊助商，提供 AI 聲音與虛擬人生成服務。
• AI 懶人報：節目名稱。
• ChatGPT：提及的主流大型語言模型。
• Astra：提及的最近很紅的大型語言模型（需查證）。
• Fable：提及的最近很紅的大型語言模型（需查證）。
• Jason：逐字稿中多次出現，應指 JSON，但依規則標為疑點。
• Apple Podcast：節目收聽平台。
• FB / IG / Flats：節目社群媒體平台（Flats 疑點）。
• 湯懶懶：節目主持人。

操作流程整理

1. 規劃階段（LLM 負責）：

• 使用大型語言模型（如 Fable/Astra）分析需求。
• LLM 進行深度推理，產出詳細的執行計劃。

1. 執行階段（Jerby 負責）：

• Jerby 接手 LLM 產出的計劃。
• 根據計劃判斷下一步動作。
• 利用 Constraint Decoding 技術，確保輸出格式固定且符合 Schema。
• 處理錯誤訊息或進行微決策（如分類、評分）。

1. 整合與監控：

• 在 IDE 中設定背景監聽器，自動將編譯錯誤或測試失敗丟給 Jerby 修復。
• 在瀏覽器自動化中，即時對照 DOM 結構並輸出動作。
• 使用 Docker 容器隔離執行環境，確保安全。

值得注意的限制或風險

1. 格式不保證的根源：主流 LLM 基於機率預測，無法保證 100% 格式正確性，需額外驗證邏輯。
2. 速度與風險的平衡：Jerby 速度極快（毫秒級），若出錯代價高，可能無法即時阻止錯誤。
3. 安全邊界設定：

• 預設將 AI 生成的程式碼視為「不信任」，不給予最高權限。
• 需使用 Docker 容器隔離，給予最小必要權限（非 root）。
• 瀏覽器自動化需使用獨立、一次性的工作階段，避免影響生產環境。

1. 適用範圍限制：Jerby 僅限於結構化決策任務（如分類、判斷），不適用於寫文章或深度推理。

逐字稿辨識疑點

• VOAI 絕好身瘡技術支援：聽起來像是「技術支援」的聽寫錯誤，但「絕好身瘡」語意不通，需查證 VOAI 的正確宣傳用語。
• Astra 跟 Fable：逐字稿提及「最近很紅的 Astra 跟 Fable」，需查證是否為特定 LLM 模型名稱或口誤。
• Jason：逐字稿多次出現「修壞掉的 Jason」、「輸出成 Jason」，應為 JSON 的聽寫錯誤，但依規則標為疑點。
• 從事機制：應為「容錯機制」或「防禦機制」的聽寫錯誤，但依規則標為疑點。
• 備緣處理：應為「備援處理」的聽寫錯誤，但依規則標為疑點。
• Tru / 加引號的 Tru：應為 True 的聽寫錯誤，但依規則標為疑點。
• Jerby / Jav / Jeff / JAB：同一個工具在逐字稿中被稱為 Jerby、Jav、Jeff、JAB，需確認正確產品名稱。
• 型別結構 / 行別定義 / 行別不符：應為「型別（Type）」的聽寫錯誤，但依規則標為疑點。
• 經費違反：應為「經符合」或「違反」的聽寫錯誤，但依規則標為疑點。
• 布林子：應為「布林值（Boolean）」的聽寫錯誤，但依規則標為疑點。
• 2 跟 false：應為「True 跟 False」的聽寫錯誤，但依規則標為疑點。
• vibe coding：應為「Vibe Coding」的聽寫錯誤，但依規則標為疑點。
• 多 A-系統：應為「多 Agent 系統」的聽寫錯誤，但依規則標為疑點。
• 為決策：應為「微決策」或「決策」的聽寫錯誤，但依規則標為疑點。
• 1 分多鐘 / 1 塊多美金：應為「1 秒多鐘 / 1 塊多美金」或類似單位的聽寫錯誤，但依規則標為疑點。
• 介位：應為「Jerby」或「它」的聽寫錯誤，但依規則標為疑點。
• Flats：應為「Threads」或其他社群平台的聽寫錯誤，但依規則標為疑點。

可延伸追問

1. Jerby 的「約束解碼」技術在處理複雜嵌套結構（如嵌套 JSON 或 XML）時，是否仍能保证 100% 的格式正確性？
2. 在「雙腦架構」中，LLM 與 Jerby 之間的介面定義與錯誤傳遞機制是如何設計的？
3. Jerby 的「信心指數（Confidence）」是如何計算的？其校準方法是否依賴於特定的訓練數據集？
4. 對於需要高度創造性或模糊判斷的任務，Jerby 的「System 1」定位是否會導致誤用？
5. Type Safe AI 未來的產品路線圖中，是否會擴展 Jerby 的功能範圍，使其能處理更複雜的自然語言生成任務？