影片筆記：【科技專題】Jev很火! 不聊天 不寫字 只做選擇 / 擊中LLM痛點? 應用場景測試〈Allen〉

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 全文快速校讀發現待確認修正

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

• 待修正：⚠️ 全文快速校讀：已套用暫定修正，請確認（segment=154 已先套用暫定修正：反而另一位 我想是他的同事 → 反而另一位 我想是他的同事 以前OpenAI的CTO 那位女士 我不記得她叫甚麼名字；segment=154 待確認：上下文提到「他的同事」且為「前OpenAI CTO」的女性，實際上OpenAI歷任CTO中女性為Ilya Sutskever（男）或早期高管如Miriam Golden等，但近期獨立創業且被廣泛討論的OpenAI前高管女性為Miriam Golden（非CTO）或可能指代錯誤。然而，更明顯的語病是「那位女士 我不記得她叫甚麼名字」與後文「那位女士做的反而真的是技術突破」重複指代，且語氣略顯彆扭。考慮到演講口語，保留原意但微調標點以區分語氣。不過，若嚴格校讀，「前OpenAI CTO」的女性實際上並不存在（Ilya是男性，Sam是男性），這可能是講者口誤或指代錯誤（可能指Miriam Golden或其他高管）。鑑於無法確認講者具體指誰，且「CTO」稱謂對女性前高管可能不準確，標記為待確認。但根據逐字稿規則，僅修正明顯語病。此處語法無大礙，僅是事實存疑。暫不修正文字，僅標記。等等，規則要求修正「不合理、突兀、看不懂」。這裡「前OpenAI CTO 那位女士」在事實層面是錯誤的（OpenAI沒有女性CTO），這導致聽眾困惑。但作為逐字稿編輯，若講者口誤，應保留原貌或標記。這裡選擇保留，因為這是事實錯誤而非語言錯誤。但若考慮到「同事」一詞，可能指代錯誤。暫不列入修正，除非有明顯錯字。重新審視，無明顯錯字，僅事實存疑。根據規則，若可信度不足標為待確認。此處無語言層面的「突兀」，僅是內容爭議。故不修正。；暫定：反而另一位 我想是他的同事 以前OpenAI的CTO 那位女士 我不記得她叫甚麼名字）
• 待修正：逐字稿可先使用，但有待校正清單（segment=154 rapid_semantic_review: 全文速讀上下文判斷；尚未回聽或交叉比對；segment=227 rapid_semantic_review: 上下文討論AI幻覺和網民留言，此句可能為講者自創的荒謬論述。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

影片介紹並評論了 TypeSafe AI 推出的新型 AI 模型「Jev」，該模型定位為「決策引擎」而非大型語言模型，旨在透過僅提供選擇而非生成文字來降低 AI Agent 的 Token 消耗與成本，作者認為其商業提案成功但技術非重大突破，建議僅用於簡單分類任務，複雜任務仍應依賴具備 Chain of Thought 能力的傳統 LLM。

核心重點

1. Jev 模型定位：Jev 並非大型語言模型（LLM），而是被定義為「Decision Engine」或「Classifier Model」。其核心功能是輸入文字後，僅回傳一組選擇（如 Yes/No、多選題、機率分數，最多 255 個選項），不生成長篇文字。
2. 解決痛點：針對 AI Agent 在執行簡單決策時過度消耗 Token 的問題，Jev 旨在降低高頻率、低複雜度任務（如郵件分類、緊急程度評分）的成本並提高速度。
3. 技術評價：作者認為 Jev 的技術層面涉及 Embedding Model 與 Re-ranker Algorithm，皆為現有技術，不算重大技術突破。創辦人 Diogo Almeida 曾參與 OpenAI 的 InstructGPT 研究。
4. 應用建議：

• 適合場景：每日大量郵件、查詢或 Ticket System 的分類，Jev 成本較低、反應較快，可作為 LLM 前的 Cheap Filter。
• 不適合場景：涉及複雜判斷或需要細節分析的任务，傳統 LLM（如 Claude、GPT）具備 Chain of Thought 能力，能透過逐步思考提高準確性，建議使用傳統 LLM。

1. 商業與資金：TypeSafe AI 成立 2 年，剛完成約 4000 萬美元的 Seed Round 融資。作者認為 4000 萬美元不足以開發 Frontier LLM，因此選擇在 Classifier 層次做突破以獲取 Traction 並籌集更多資金。
2. Jevons Paradox 致敬：Jev 之名致敬經濟學中的「Jevons Paradox」（技術進步提高資源效率，但總消耗量反而上升），暗示 AI 技術進步可能不會減少 Token 消耗，反而可能增加使用量。

詳細大綱

1. Jev 模型介紹與背景

• 發佈公司：TypeSafe AI，成立 2 年，剛完成 Seed Round 融資約 4000 萬美元。
• 創辦人：Diogo Almeida，前 OpenAI 員工，InstructGPT 論文作者之一。
• 技術定位：非大型語言模型，本質為 Decision Engine 或 Classifier Model。

2. Jev 的運作原理與應用場景

• 運作方式：輸入文字，提供一組選擇（Yes/No, MCQ, 機率分數等，最多 255 個選擇），模型輸出選擇或機率。
• 輸出限制：不生成長篇文字，僅回傳決策結果。
• 應用範例：
• 電郵分類（客戶 vs 垃圾郵件）。
• 醫療緊急程度評分（如血壓數據評估，提及 A&E 急症室場景）。
• 資源提供：作者已將 Code 範例與測試結果放上 GitHub。

3. 作者對 Jev 的技術與商業評價

• 商業觀點：Pitch 非常成功，精準擊中 AI Agent 呼叫 LLM 時 Token 消耗過大的痛點。
• 技術觀點：不算重大技術突破。技術層面涉及 Embedding Model 與 Re-ranker Algorithm，這些皆為現有技術。
• 資金與策略：4000 萬美元不足以開發 Frontier LLM，因此選擇在 Classifier 層次做突破以獲取 Traction 並籌集更多資金。
• 對比：提及前 OpenAI CTO（女性）提出的影像原生輸入語言模型，認為那才是技術突破。

4. Jev 與傳統 LLM 的比較與建議

• 簡單任務：對於每日大量郵件、查詢或 Ticket System 的分類，Jev 成本較低、反應較快，建議使用。
• 複雜任務：若任務涉及複雜判斷或需要細節分析，傳統 LLM（Claude, GPT）具備 Chain of Thought 能力，能透過逐步思考提高準確性，建議使用。
• 與 Flash/Mini Model 比較：Flash/Mini 版本雖快且便宜，但作者認為在準確性與速度的 Trade-off 中，寧願慢一點以確保準確性，不建議為省錢而用 Jev 取代所有決策，以免決策出錯。
• 結論：Jev 可作為 LLM 前的 Cheap Filter，但不應完全取代所有 Decision Making。

5. Jevons Paradox 的致敬

• 解釋 Jevons Paradox：技術進步提高資源效率，但總消耗量反而上升（如引擎省油導致用油總量增加、4G/5G 導致數據消耗增加）。
• 隱喻：暗示 AI 技術進步可能不會減少 Token 消耗，反而可能增加使用量。

工具 / 模型 / 名詞整理

• Jev：TypeSafe AI 發佈的新型 AI 模型，定位為 Decision Engine / Classifier Model。
• TypeSafe AI：Jev 模型的發佈公司。
• LLM (Large Language Model)：大型語言模型，Jev 的對比對象。
• OpenAI：Jev 創辦人 Diogo Almeida 的前雇主。
• InstructGPT：Diogo Almeida 參與研究的論文/模型。
• ChatGPT：提及的大型語言模型。
• Gemini：提及的大型語言模型。
• GPT-3：提及的大型語言模型。
• Qwen 27B：提及的模型。
• DeepSeek：提及的模型。
• Claude：提及的大型語言模型，具備 Chain of Thought 能力。
• Chain of Thought：技術術語，指模型透過逐步思考提高準確性的能力。
• Embedding Model：Jev 技術層面涉及的現有技術。
• Re-ranker Algorithm：Jev 技術層面涉及的現有技術。
• Frontier Model：模型類別，指代頂尖的大型語言模型。
• GitHub：程式碼範例與測試結果的存放平台。
• A&E (Accident & Emergency)：急症室，用於醫療緊急程度評分的範例場景。
• Jevons Paradox：經濟學現象，指技術進步提高資源效率但總消耗量上升，Jev 模型名稱的致敬來源。
• Seed Round：種子輪融資。

操作流程整理

1. 輸入：使用者或系統輸入文字內容。
2. 定義選擇：設定一組預定義的選擇選項（Yes/No, MCQ, 機率分數等，最多 255 個）。
3. 模型處理：Jev 模型對輸入文字進行分類或決策判斷。
4. 輸出結果：模型僅回傳選定的選項或機率分數，不生成額外文字。
5. 後續應用：根據回傳的決策結果執行後續動作（如分類郵件、評估緊急程度）。

值得注意的限制或風險

1. 準確性與速度的 Trade-off：作者認為犧牲準確性以換取速度的做法不值得，寧願慢一點以確保準確性。
2. 不適用於複雜任務：Jev 不具備 Chain of Thought 能力，若任務涉及複雜判斷或需要細節分析，使用 Jev 可能導致決策出錯。
3. 非技術突破：Jev 的核心技術（Embedding, Re-ranker）為現有技術，並非重大技術創新。
4. Token 消耗可能增加：受 Jevons Paradox 啟發，AI 技術進步可能導致總體 Token 消耗量上升，而非減少。

逐字稿辨識疑點

• Jev：逐字稿中多次提及此模型名稱，拼寫一致，但非常見知名模型名稱，需查證是否為特定新模型或聽寫錯誤。
• Diogo Almeida：逐字稿提及此人名為 TypeSafe AI 創辦人及前 OpenAI 員工，需查證其真實身份與背景。
• 前 OpenAI CTO（那位女士）：逐字稿中作者表示「我不記得她叫甚麼名字」，指稱其為前 OpenAI CTO 且為女性，並成立新 AI 公司，需查證具體人名。
• 梅建國：逐字稿中提及此名字，並稱其為網民搞笑內容，作者表示「我真的不知道」，需查證此為特定網路梗或人名誤植。
• 美斯是王敏德：逐字稿中作者說「美斯是王敏德」，此處邏輯或事實關係不明，疑為口誤或特定玩笑，需查證。
• 砵蘭街：逐字稿中提及「砵蘭街」，為香港地名，需確認是否為正確地名拼寫。
• Segment 154: rapid_semantic_review：全文速讀上下文判斷；尚未回聽或交叉比對。
• Segment 227: rapid_semantic_review：上下文討論 AI 幻覺和網民留言，此句可能為講者自創的荒謬論述。

可延伸追問

1. TypeSafe AI 的 Jev 模型在實際應用中，與傳統 LLM 的 Token 成本節省比例具體為何？
2. Jev 模型支援的 255 個選擇選項，在實際商業場景中是否足夠覆蓋複雜的分類需求？
3. 前 OpenAI CTO 提出的「影像原生輸入語言模型」具體技術細節與進展為何？
4. Jevons Paradox 在 AI 領域的具體數據表現，是否真有證據顯示 Token 消耗隨效率提升而增加？