逐字稿文字預覽
9月15日迪奥哥阿尔梅达在X上发了一条帖子 第一句话就很抓人 他说参与创造XGP之后 我一直在问自己 为什么这些已经超过人类水平的聊天模型 没有带来AGI呢 这个问题从他嘴里说出来确实有点特别 阿尔梅达是Intract GPT的作者之一 也参与过GPT4的RLHF和指令遵循的相关工作 简单来说 今天我们已经习以为常的这件事 就是你对AI说一句话 它能够理解你想干什么 然后按照你的要求回答 它就是这个早期参与 把这条路线做出来的人之一 不过参与创造ChatGPT 是它自己的表述 并不是OpenAI给它的 ChatGPT联合发明人头衔 但是ChatGPT出现以后 它反而开始怀疑一件事了 就是模型已经越来越会说话了 那为什么我们期待中的大规模自动化 却没有以同样的速度发生呢 于是过去两年 阿尔梅达一直在隐身做另一件东西 直到这几天 他和自己的公司TypeSafe AI 才把它公开出来 这个模型叫Jeff 你知道吗 TypeSafe给出的数字非常夸张 说它20到200倍更快 40到400倍更便宜 不过我看到这里的时候 真正让我觉得有意思的 还不是这些数字 而是Jav做了一件非常反常识的事情 就是他不会说话 真的不会 Jav他不跟你聊天 不写文章 也不生成自由文本 你把一段对话 一个agent当前的状态 或者一堆数据交给他 然后问他 这个请求安全吗 下一步应该调用哪个工具呢 这几个方案选哪一个呢 这之后 Jav不会先写一段分析 也不需要慢慢吐出一串Jason 他会直接给你决定 以及他对这个决定有多大把握 欢迎回到All Insight 在继续今天的视频之前 我想先感谢一直支持这个频道的朋友 我知道还有不少观看我视频的朋友 还没有订阅我的频道 那如果你觉得我的内容对你有所帮助 欢迎点赞分享和订阅 也可以加入频道会员 每个月一杯咖啡的钱 不仅是对我的支持 也会帮助我继续制作 更多关于AI和未来技术方向的深度内容 好的 接下来我们进入今天的主题 这件事听起来好像只是少生成了一些文字 但放到今天的agent里面 你会发现问题其实没有那么简单 现在一个agent的每走一步 可能都要做很多判断 比如下一步该调用哪个工具 这个结果能不能相信 要不要继续 需不需要升级到更强的模型 很多时候我们真正需要的 其实只是一个是或者不是 ABC选哪个 但今天最常见的做法 是把整个上下文交给一个大语言模型 让它先生成文字或者结构化输出 然后程序再从这些输出里 拿出最后那个决定 所以阿尔梅达这次实际上是在问 如果软件真正需要的只是一个决定 那为什么一定要让AI先说一段话呢 Jav发布以后 X上很快出现了两种不同的声音 第一种反应非常直接 就是等等这不就是分类器吗 独立AI研究者Alexis Gallagher就说 他觉得Jav很酷 但更有意思的是大家对Jav的反应 因为这似乎说明很多人已经忘了 锦编码器分类器已经存在很多年了 而且一直很好用 像Modern Bird这样的模型 本来就可以快速和廉价的完成结构化判断 Jav也许更好 而且不需要针对每一个任务重新训练 但这个类别本身并不新 另一边XBOM的AI研究员Lan Butler马上反驳说 问题恰恰就在不需要重新训练 如果今天突然给你一个非常奇怪 而且类别又特别多的决策任务 你手里甚至还没有数据集 那传统分类器怎么办 而Jav的卖点就是直接用自然语言告诉他 现在要判断什么 更有意思的是 已经有人不吵了 他们直接把Jab塞进agent里面开始跑 有人拿它做模型路由 让Jab决定什么时候该用便宜模型 什么时候升级到更强的模型 还有人拿它做Computer Use的下一步决策 还有一个叫Observed开发者 测试了一整晚跑了500多次API 总共才花了大约3美分 一次同时多问20个问题 延迟也只增加了47毫秒 他还抓住了一次针对他自己agent的假审批注入 然后他发现Jeff有一次打错了 而Jeff给那个错误答案给出的信心是1.00 这就有意思了 一边是这不就是我们用了很多年的分类器吗 而另一边却已经有人开始把他塞进agent的决策循环 官方说他的概率经过较准 但在真实测试里却已经出现了 答错了但信心百分之百的情况 所以这期视频我真正想弄清楚的 不是Jav到底有没有快200倍 而是说一个参与创造ChattGPT的人 在模型越来越会说话之后 为什么会花两年的时间 重新做一个不会说话的AI呢 以及他是不是碰到了今天A成的系统里 一个更有意思的问题 就是我们真的需要让大模型来做每一个决定吗 那么一个不生成自由文本的AI 到底是怎么工作的呢 TypeSafe对Jav的描述其实很简洁 翻译过来的意思就是 输入可以很复杂 但输出不再是一串自由生成的文字 而是提前定义好类型的概率决策 比如一个客服agent的正在处理退款请求 你可以把完整的对话记录 用户账户状态 以及最近的付款记录一起交给Jav 然后同时问他 用户现在是不是在要求退款呢 有没有欺诈风险呢 需不需要转人工呢 如果要继续处理 下一步应该执行哪个动作呢 当然普通大模型也能回答这些问题 但它通常还是要生成 哪怕最后输出的是JESN 本质上也是一个Token接一个Token的 把字符串写出来 但JESN走的是另一条路 他把这些问题直接变成了几个 类型确定的决策 而且可以一次并行回答 TypeSafe目前把这种输出 分成三种基本形式 第一种叫Nual 它处理是不是这一类的判断 比如这个请求有没有越狱风险 那么它返回的就不是一句 我认为没有 而是说这个判断对应的概率 第二种叫Choice 也就是从提前给定的选项里做选择 比如一个Agent手里有八个工具 现在应该调用哪一个呢 Jive直接在这八个选项里做判断 并给出相应的概率 第三种叫Score 用来处理打分和排序 比如一个任务的优先级有多高 或者一个结果有多值得信任 所以 它和普通聊天模型在接口上的 区别其实非常直观 聊天模型的输出空间 几乎是无限的 你可以让它写一句话 一篇文章一段代码 也可以让它生成结构化数据 JF在开始计算之前 输出空间就已经被软件定义好了 它可以判断 但它不能临场发明一个新的答案 这里还有一个很容易被忽略的区别 就是这些判断不一定要一个接一个的做 Type-Safe官方展示的Workflow 本身就会把一个复杂的软件状态 拆成很多独立的问题 然后一次并行询问 比如他们公开的客服工作流 第一步就会同时读取用户意图 情绪 紧急程度 以及欺诈风险等多个信号 再用后面的代码决定 退款 冻结银行卡 转人工 还是继续处理 这时候我们再回头 看TypeSafe给这种模型起的名字 就比较容易理解了 他们叫它System-1 Module 这个名字来自丹尼尔·卡尼曼 对System-1和System-2的区别 他认为System-1负责 快速和直觉式的判断 System 2才负责缓慢和复杂的推理 那Type-C想做的不是让Jeff取代所有大语言模型 而是把软件系统里大量这种快速判断单独抽出来 阿尔梅达后来把这个速度说得更直接 他说他们把今天几条不同的训练路线 看成是在解决不同的问题 像RLVR就更适合可以验证答案的Resonings和Proves 而他们希望RLCD去解决的是自动控制 也就是让模型的决定真正能够被软件直接使用 这也是为什么Type-Safe一直把Jeff的典型用途写成 分类 路由 打分 提取和分支判断 他们甚至用了一个狠形象的说法是聪明的一语句 听到这里Jeff好像已经也没有那么神秘了 他不是一个被砍掉聊天界面的GPT 也不是为了写出更好的答案 而是他想把做决定本身 从语言生成里单独拆出来 变成软件可以直接钓鱼的一种智能原语 但是这也就回到了开场那个质疑 就是这不就是分类器吗 以太坊基军会AI的负责人 David Krapis的说法就更直接了 他认为把Jav和通用ML放在一起比较 很容易产生误导 因为Jav根本不生成自由文本 从功能上看 它更接近一个非常聪明的工具 或者一个分类器 而不是GPT Cloud这种通用模型的直接竞争者 有人继续往下拆 Robert试文透客把Jab的几个卖点 一条一条列了出来 像是类型受限的输出 我们已经可以用受限解码做 概率可以从LogProps里面拿 概率校准也早就有Temperature Scaling 什么时候放行 什么时候升级 本来就可以在应用代表里面写Thrust Hold 所以他最后的评价其实很有意思 他认为这些统计学上的零件 没有哪一个是突然从天上掉下来的 真正可能不同的是Type Safe把校准放进了训练目标 然后让API从一开始返回的就是Decision 而不是一段等待程序再次解析的文字 换句话说 这不是发明了一堆从来没有存在过的零件 而是少兵了几层东西 这时候Jav就不是分类器吗 这个问题就开始变得没那么简单了 因为Type-Safe真正想挑战的 并不是传统分类器做不到的分类 而是它的使用方式 假设你今天做一个金融agent 你只需要判断的是 这笔交易有没有欺诈风险 那你当然可以收集数据标注样本 训练一个专门的分类器 如果业务一直不变 这就可能比调用Jav更便宜更快 甚至更可靠 但现实里的agent很少永远只问同一个问题 今天你要判断的是欺诈 明天可能增加是否需要人工复合 后天可能又增加 应该交给哪个风险团队 换一个产品 问题标签和业务规则可能全部都变了 如果每增加一种判断都要重新积累数据 训练和部署一个模型 那传统分类器的成本就开始从推理阶段 转移到了开发和维护阶段 而Jeff想做的是把大语言模型 最有价值的一部分能力保留下来 就是你可以直接用自然语言告诉模型 现在要判断什么 我们目前还没有看到 Jeff和一个认真微调过的Mardenberg 专门的小型分类器 或者一个使用受限解码的小语言模型 在同样任务同样数据同样准确率要求下 做一次真正公平的正面对比 TypeSafe真正需要证明的是 当任务不断变化 而你又不想每次重新训练一个模型的时候 Jab能不能同时保住分类器的速度和成本 又同时保住大模型那种 拿自然语言就能直接定义新任务的灵活性 而这还只是第一层 因为TypeSafe对Jab最大胆的主张 其实不是快也不是便宜 甚至不是自然语言可编程 而是他认为 Jav不只会给你一个决定 他还知道自己这个决定到底有多可靠 这就进入了整个Jav的故事里 最关键也是目前最神秘的一块RLCD 前面讲到Jav会给每一个决策附上概率 但这里真正重要的 不是他能不能输出一个0.73或者0.91 而是说这些数字到底有没有统计意义 这就是RLLCD想解决的问题 它的全称是校准决策强化学习 所谓校准 我们可以先用一个很简单的例子来理解 就是如果一个模型做了很多次判断 我们把它所有认为有70%把握的判断放在一起 那么一个校准的好的模型 长期来看应该有大约70%是正确的 他说90%就应该接近90% 说50%就真的意味着这件事差不多只有一半的把握 这和准确率其实是两回事 一个模型完全可能总体准确率很高 但他根本不知道自己什么时候会错 而另一个模型也许平均准确率没有高出多少 但他在容易出错的时候 真的会把自己的概率降下来 对于聊天机器人来说 这个区别可能没有那么明显 但对于agent来说 这就直接决定了一件事 就是这个概率能不能拿来控制系统 比如一个agent正在决定 要不要自动批准退款 债务判断可以批准 概率99.8% 如果经过大量测试之后 你真的知道这种99.8%值得性 那么Harness就可以设置一个预值 超过这个概率自动执行 但如果只有70% 就升级给更强更贵的模型 如果再低一点 就交给人工或者Verify 这个时候CoundDefense 就不再是给人看的一个装饰数字 它变成了A站的内部的一种控制信号 就是什么时候继续 什么时候升级 什么时候验证 什么时候停下来 前面那个满分信心却答错的例子 追问的也正是这件事 就是这些概率究竟有多可信呢 而RLCD真正生成改变的是另一件事 就是从训练阶段开始 就让模型学习一个决定应该有多确定 让概率本身也成为训练目标的一部分 但是我目前还没有看到TypeSafe公开完整的论文 具体的训练流程和损失函数 也没有足够完整的第三方校准基准 所以RLCD是否真的比现有校准方法更好 这一部分还要等更多的证据 这里也刚好可以解释TypeSafe另一个 很容易让人误解的说法 就是Jav不能产生幻觉 如果你只允许Jav在批准和拒绝之间选择 他确实不可能突然回答也许 也不会捏造第三个不存在的函数 更不会生成一段格式错误程序 根本解析不了的Jason 它的输出空间在计算之前 就已经被系统类型限制好了 但是它完全可能选择批准 而正确答案其实是拒绝 所以更准确的说 Jav解决的是一种非常具体的幻觉 它不会生成类型之外的答案 但仍然可能在合法答案里面选错 不过呢 真正决定Jav能不能进入高风险自动化流程的 还是后一个问题 就是它选错的时候 自己到底知不知道 这也是为什么我觉得 RLCD反而比Jav那个200倍更快的数字 更值得关注 如果一个模型只是快而且便宜 我们其实已经有很多办法可以做到了 但如果它能在保持这种速度和成本的同时 给软件提供一个真正可信的不确定性信号 那它在A层里面的位置就完全不一样了 当然接下来还有一个跟现实的问题 就是这些概率决策究竟能省下多少时间和成本呢 现在我们终于可以回到 JF发布时最新眼球的那组数字 20到200倍更快 40到400倍更便宜 TypeSafe自己公布的Workflow Benchmark里面 最高端的数字达到了193.6倍更快 444.6倍更便宜 这个数字第一眼看起来很离谱 但离着JF前面的设计之后 你会发现它其实并不神秘 因为Jav和普通LM做计算的方式 从一开始就不一样 假设一个agent现在需要做20个判断 比如用户是不是在退款 有没有欺诈风险 需不需要人工介入 需要调用哪个工具 结果要不要再验证一次 阿尔梅达回应过一个很直接的问题 就是为什么不干脆用受限解码呢 他的回答是 这层约束仍然叠在LM上 字符串生成的开销还在 他还提出了一更尖锐的判断 就是模型本来就拿不准的时候 再去限制他能选哪些输出 反而会让模型变笨 债务直接省掉了字符串生成这一步 他不需要把决定翻译成一段语言 再让软件把语言重新翻译成决定 他的输出空间已经提前确定 而且多个问题可以在同一次询问里并行计算 TypeSafe公布的端到端延迟 大约是70到500毫秒 输入价格是每百万Token4.2美分 输
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
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（來源選擇報告）
耗時：1354.3 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：48.2 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.4 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.4 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.4 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：0.5 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.5 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：150.8 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.9 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：1.0 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。