逐字稿文字預覽
最近有一個叫Jev的AI Model非常爆紅 大家如果有上網 應該都見到很多人討論這個AI Model 這個叫Jev的AI Model 其實是由一間叫TypeSafe AI的公司發佈的 這間公司已經成立了2年 只不過最近才發佈了這個Jev模型 同時亦宣佈完成了一輪融資 應該是Seed Round 籌集了大約4000萬美元 這個叫Jev的AI Model 首先它不是大型語言模型 例如ChatGPT、Gemini這些才是大型語言模型 它們的性質像一個Chatbot 會跟你聊天 它們執行你的任務之餘 亦可能會說很多廢話 因為LLM的本質就是不停重複 去Generate the Next Token 但是這個Jev的AI Model 完全不是這樣的東西 它技術方面的東西我稍後再說 我先說一下它的創辦人 TypeSafe AI這間公司的創辦人 就是Diogo Almeida 他之前在OpenAI工作 他亦有參與InstructGPT這篇論文 是作者之一 並有參與這項研究 InstructGPT當然是非常重要 因為例如在GPT-3之前 大型語言模型的能力或訓練目標 都是很單純地預測下一個字、下一個Token 但自從OpenAI研究了InstructGPT之後 它能夠將大型語言模型的Output 與人類的意圖保持一致 例如人類交給大型語言模型的任務 可能你叫模型寫一封辭職信或一份計劃書 模型就會根據你的任務和文字 或計劃書的目的 去寫出那段文字 自從有了InstructGPT之後 大型語言模型才真正可以做到這樣的功能 並且做得很準確 而且InstructGPT亦確立了 強化學習的技術模式 這個叫Jev的AI Model本質上是一個Decision Engine 或者更準確地說 它算是一個Classifier Model 舉一個例子 你有一封電郵和電郵的文字 你想知道這封電郵究竟是客戶電郵 還是垃圾郵件 使用方法就是將電郵的文字 交給這個Jev的AI Model 然後給它幾個選擇 A是客戶電郵 還是B是垃圾郵件 如果它告訴你這是客戶電郵 你可能想知道這封電郵是投訴 還是一般查詢 如果是投訴 客戶現在是否很生氣 模型不是寫文章 亦不會長篇大論 它回傳的Output只是你給的選擇 它會作出選擇 或給每個選擇一個機率 又或者你問它是或不是 它會給出是與不是的機率或分數 為甚麼大家熱烈討論這個模型 這麼興奮 原因是現在尤其是使用AI Agent時 AI Agent很多時會呼叫大型語言模型 最大的問題是 這些AI Agent不停呼叫大型語言模型時 哪怕你只是做很少的事 模型在背後其實真的會做Inference 用很多Token長篇大論 雖然大部分人都不會看 但事實上它就是消耗了這麼多Token 其實Jev這個AI Model的運作並不複雜 它和大型語言模型最重要的分別在於 你除了要給它問題或任務的文字之外 還必須要給一系列的選擇 選擇可能很簡單 是一個是非題 Jev就在Yes or No之間做選擇 或者分配一個概率 或者是一個MCQ A至E五個答案中 哪一個正確 或者機會率最大 你最多可以給255個選擇 記住選擇是必須的 舉一個例子 現在一間診所裡有一位45歲女病人 她的BP是184/112 沒有特別症狀 亦沒有特別不適 測試結果正常 究竟這個女人需不需要去急症室 或者她的情況有多危急 有多緊急 以1至5評分 5最緊急 1不緊急 Jev的應用場景就是這樣 為方便一些做Tech的朋友試用Jev的AI Model 我亦寫了一些Code作為Example 給大家參考試用 亦已放上GitHub 而最重要的是 我亦測試了一些任務 當然我們做醫學人工智能 剛才我提到那位女士血壓這麼高的情況下 究竟有多危急 需不需要去A&E 就是這些例子 當然這些例子本身是有答案的 然後我們測試Jev在這些情境上表現好不好 LLM的表現又好不好 又或者你將Qwen 27B的Model 放到你的Mac上運行 那就不需要Token 當然會較慢 但它不需要花錢 亦是用你自己的電腦 究竟效果又如何 我們亦將結果放上去了 I'm the king of the keys No crown on my dome ChatGPT spitting scripts Making AI my home Gemini twin flows Split brains in the zone DeepSeek visions Seeing truths never shown Claude in my corner Whisper moves like a sage Lines so clean Got em popping off the page I don't CD That's alphabet soup I'm the vibe of the code Making systems salute I'm the king of coding No crown no throne Turn words into magic I'm a vibe on my own Chatbots and cosmos Most the digital roam The king of coding in the cloud I'm home 接著我說一下我對Jev這個AI Model的看法 根據TypeSafe AI所說 Jev這個AI Model的功能或定位 又或者說它針對的痛點 就是現今我們使用大型語言模型時 尤其是使用Agent的時候 Agent每一個步驟都會呼叫大型語言模型 無論你用哪一個API 哪間公司的模型 其實你每次呼叫的時候 哪怕只是一個很簡單的決定 或者一個很簡單的任務 背後經常都會消耗很多Token 它的論點是 這些Token是否真的必須這樣消耗 因為老實說 你的AI Agent在背後做的事 它在背後回傳的那些文字 大部分時間只是AI Agent自己看 你不會看 對大部分人來說 一些很Minor的決定 你最重要是告訴我是或不是 做或不做 或者用甚麼工具就可以 為甚麼需要浪費這麼多Token 這就是TypeSafe AI對Jev功能的看法 又或者可以說是他們的Pitch 毫無疑問 這個Pitch非常成功 因為大家都感受到那種痛點 因為大家用AI Agent去寫Program 寫Code 你真的覺得好像在燒錢一樣 但我的看法是 這是一個很好的Pitch 但算不上是一個重大的技術突破 因為如果從技術角度去看 我覺得Jev像一個Classifier Model 當然它有理解語言的部分 我相信這是Embedding Model做的事 亦涉及一些Re-ranker的Algorithm 但我剛才說的這幾樣東西絕對不是新技術 因為你也可以想像 你說的是4000萬美元的Funding 如果你要做大型語言模型 尤其要與現在市面上的Frontier Model競爭 根本不夠錢 4000萬美元不可能做LLM 你唯一可能做到突破的 就是在剛才說的Classifier Model 再加Embedding Model的層次上去做 所以我覺得這個Pitch很好 亦是很好的Marketing 至少現在這麼多人在討論 取得Traction之後再籌集更多資金 再想下一步怎樣做 這可能是他們現在的策略 所以我不覺得這是一個重大的技術突破 反而另一位 我想是他的同事 以前OpenAI的CTO 那位女士 我不記得她叫甚麼名字 以前OpenAI的CTO 那位女士 我不記得她叫甚麼名字 她出來亦成立了一間AI公司 那個反而算是一個技術突破 因為她說的是用影像 原生地作為語言模型的Input 這其實是很難做到的 我不是說她一定會成功 但純粹從技術來說 前OpenAI CTO 那位女士做的反而真的是技術突破 而Jev不是 所以要視乎你做的事、任務或決定有多複雜 舉個例子 純粹做電郵分類 可能你的公司每日有幾百封Email 或者你做網店 每日有幾百個查詢 你要對那些Email、查詢或客戶訊息 純粹做分類 例如你的Ticket System 要看那個Ticket有多Urgent 如果很急 可能你會分為極急 立即處理 客戶很生氣就先處理 一般查詢就稍後 如果純粹是電郵或客戶訊息 用Jev這類模型 我覺得是對的 因為一來成本會較便宜 二來反應時間會較快 而且這類System很多時未必即時自動回覆 可能都會經過人手客服再覆核 在這類情況下用Jev是合理的 或者用Jev分類後再交給LLM處理亦可以 但如果你做的事或任務有一定複雜程度 你可能仍需要用回傳統語言模型 就算你的任務純粹是做決定 不涉及生成文章或回覆客戶Email 不需要生成文字 純粹做決定 我想你仍是用回傳統語言模型 例如Claude、GPT這類Frontier Model 它們的判斷做得好 原因是它們可能會一步一步地思考 它們有Chain of Thought 你可以選擇Thinking是High還是Low 用多少思考力去做 複雜的任務或判斷 你可能真的需要看當中的細節 或者重點 才可以作出結論 而這個過程是做Chain of Thought 真的要消耗Token 你不可以說是浪費 不可以說不是必須 很多時有些Tasks要看很多細節 你不看細節 不讓它一步一步思考 就有很大機會出錯 例如一個男人有性病 他是否一定出去鬼混 未必 表面看似是這樣 但不一定 他的女朋友濫交又行不行 或者那個男人走過砵蘭街 被水淋到後染上性病又行不行 很無辜 我說到這裡 一定有些有識之士會在留言更正我 如果你走過砵蘭街被水淋到 在醫學上是絕對不會染上性病的 因為DeepSeek、Gemini都是這樣說 其實我想說 我做這些節目 或這些題目這麼悶 有時搞搞笑 搞搞氣氛都可以 我覺得有時大家缺乏了一些幽默感 就像上次我的影片 我說梅建國 真的有網友很認真地留言說 梅建國其實是網民搞笑的 Allen竟然當真 然後說這就證明了 AI幻覺的最佳例證 老實說 美斯是否真的叫梅建國 我真的不知道 我不肯定 但我可以很肯定地告訴大家 美斯是王敏德 另一個問題是 OpenAI、Gemini 或DeepSeek這類模型 現在亦有推出所謂Mini或Flash版本 它們針對的應用場景 是一些不需要太多思考又要快的 任務或工作 當然Jev可以反駁 這些Flash Model、Mini Model都會消耗Token 但就我個人的使用經驗而言 未必代表大多數人 但這類Flash Model 無論你的prompt怎樣寫 我覺得都夠快亦夠便宜 當然你不可以將它與Jev這類 Classifier Model性質的東西比較 但你說Flash Model是否真的很貴 我又覺得不是 如果要我衡量任務的準確性 即做出來的準確性 或判斷的準確性 相對速度的Trade Off 我寧願做慢一點 而不犧牲準確性 如果你為了省錢 而用Jev這類Model令你的決策出錯 我覺得不太值得 就算要等AI Agent 你先喝杯咖啡吧 我覺得其實不是那麼Time Critical的事 我覺得交回LLM去做會比較放心 這就是我的結論 但正如我剛才所說 他們的Pitch做得好 因為這的確是一個痛點 如果用Jev做一個Cheap Filter 在大型語言模型之前先過濾 或者有些任務很簡單就可以作決定 我覺得用Jev是合理的 但如果完全用Jev取代所有Decision Making 這點我就不同意了 這個叫Jev的AI Model 其實是向Jevons Paradox致敬 Jevons Paradox是一個經濟學現象 它說的是當技術進步到一定程度 令某種資源的使用效率提高時 該資源的總消耗量 我們很多時以為 提高效率 整體上會用少了那些資源 但很多時發現並不是 其中一個例子是引擎的改進 技術進步令引擎更省油 省油之後 我們以為對燃油的整體需求會減少 其實不但沒有減少 反而上升 另一個例子是電訊 即數據傳輸技術 例如4G、5G 技術進步令數據傳輸速度更快 或成本降低 我們會否以為人們會用少了數據 答案當然不是 現在的人不只看文字 不只看圖片 就算看影片都可能要求高 高質素的4K、8K串流影片 或者會做更多以前沒有的事 例如線上會議或線上遊戲等等 數據的總消耗量 並沒有因為技術提升而下跌 其實Jevons Paradox就是說這樣的事 好 時間到了 多謝大家
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：15.4 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：26.7 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.7 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.7 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.8 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.8 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：81.5 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.6 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.7 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
目前待解決問題與初步改善方向
- ⚠️ 全文快速校讀：已套用暫定修正，請確認
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=227 待確認：邏輯荒謬或特定梗：「美斯」（Messi）與「王敏德」無直接關聯，可能是講者故意製造的荒謬例子以說明AI幻覺或網民搞笑，需確認是否為特定梗。；暫定：美斯是王敏德
- 逐字稿可先使用，但有待校正清單
segment=154 rapid_semantic_review: 全文速讀上下文判斷；尚未回聽或交叉比對；segment=227 rapid_semantic_review: 上下文討論AI幻覺和網民留言，此句可能為講者自創的荒謬論述。
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。