逐字稿文字預覽
ChatGPT主創人員之一表示他讓他感到心碎。Diogo Ameta曾是OpenAI研究員,參與構建了聊天機器人並共同發明了RLHF,即基於人類反饋的強化學習。這很可能是造就當前AI時代最關鍵的技術。但他卻感到失望用他的話來說,我們空有驚人潛力,卻無法將其轉化為實際用途。 他的观点是,整个行业一直在针对人类语言进行优化,模型在这方面已出色了四年之久,但这并不能带来自动化。 毕竟计算机的语言与人类不同,他在发布文中,反问,模型在对话方面已超越人类多年。 那自动化究竟在哪?他曾以为对话模型能通向API调用,但尽管外界喧嚣不断,显然还缺了关键的一环。 于是两年前他离开了OpenAI 创办了TypeSafe AI 并出任联合创始人兼CEO 他们融资4000万美元 潜心研发两年 并于9月15日周二发布了JEFF 这是他们首个系统一模型一类 全新的前沿模型 能直接为软件提供快速的结构化决策 最奇特的一点是他基于Transformer架构 但他并非大语言模型 他不输出文本而是返回概率 即他们所说的校准决策 Almeta将其称为机器原生人工智能 因为如果人工智能要改变工作流程 人类不能是智能的唯一受众 TypeSafe将其称为前沿智能函数 输入非结构化状态输出类型化的概率决策 输出结果可以是Jason 也可以只是一个简单的字符串 比如我的卡被重复扣费了 随后你可以使用名为Choice Score的原语来提问 以及NEO他们会返回类型化的选择评分 或是带有概率的不耳直答案全部并行评估 以工单分类为例 假设你需要决定有哪个部门处理客户咨询 你会得到账务0.08 技术0.85 销售0.07 智信度0.82 这对人类而言毫无意义 但对代码来说却非常完美 因为可以直接据此进行逻辑分支 这就是名字的由来 类型安全是指程序捕获异常数据的方式 即防止程序遇到预期之外的情况 比如试图用整数 去除以字符串而使用Jeff 你可以预先定义输出格式 它绝不会输出结构以外的内容 省去了解析与验证的麻烦 而大语言模型输出的只是一个字符串 可能是对话回复 可能是代码 可能是幻觉 也可能是拒绝回答 又或是带有风险的结构化数据 稍不留神就会失控 你当然能用代码封装大语言模型 但这正是Jeff的优势所在 Type Safe 声称它不会产生幻觉 在处理系统一任务时 其表现足以媲美大语言模型 且速度快了两个数量级 效率也更高在其底层架构下 采用了一种全新的并行采样器架构 以及一种名为强化学习的训练方法 即基于校准决策 简称RLCD The Register将RLCD归类为一种架构 但它本质上是一种训练方法 也是他们对RLHF的回应 像GPD 5.6 Terra这类模型 每次只能生成一个Token 每个Token都依赖前一个Jeff 就能一次性生成所有结果 通过单次硬件感知查询实现 它基于结构化程序状态 而非序列消息构建 他们认为放弃字符串 赋予了模型超能力 而且速度快得惊人 这就是TypeSafe 前沿大模型处理耗时 3到329秒端到端 人类用者还行 但在代码自动化场景下 就是瓶颈Jeff只需 70到500毫秒 速度快了40到200倍 在TechCrunch报道的对比演示中 截图显示Jeff响应仅需0.114秒 而Tara则用了8.566秒 更惊人的是价格 大模型每百万输入Token收费 20美分到10美元 输出费用是输入的5倍 而Jeff每百万Token仅需0.042美元 也就是每10亿Token仅需42美元 没错他们按10亿单位计费 输出成本极低 几乎可以忽略不计 Tara模型输入为每百万两美元 输出则为每百万十二美元 数据显示Jeff模型 比Fable 5.1便宜了238倍 再来说说自信度 这恐怕是最被低估的一点大模型 往往过度自信 且对自身确信度的评估前后不一 如果一个模型能在95%的情况下完成任务 但却无法告诉你 它何时会出错 你就无法实现自动化 Jeff的自信度 经过了较准 自信度越高 准确率也就越高 相似的输入会得到相似的答案 Iron DL的首席技术官 Armond Risser表示 这让开源模型得以发挥其效用 他告诉TechCrunch 这实际上是将 幻觉问题交由用户自行把控 自信度5x10如抛硬币直接忽略 9x50则果断执行 面对高调的声称TypeSafe 心知肚明 正如文中那句 非凡的结论需要非凡的证据 下方还附上了有图有真相的证据配文 还带了个图指甲油的表情 他们自称欢迎质疑 因为他们自己就是怀疑论者 值得称赞的是 他们在速度优化上确实下足了功夫 你可以亲自验证 这些模型多运行在西海岸的笔记本上 也就是该服务的所在地定价方面很透明 但他们坦言无法证明其未获补贴 并预计价格未来会进一步下降 且不存在类型错误 虽然一个反例就能将其推翻 但这在数学上是不可能的 他们说在Terra演示中 他们坦言查询过程经过了高度简化 使用了可读的问题件外加一段 有利于Jeff的密集状态描述 从而美化了其表现 他们选用了默认推理的Terra 认为其智力水平最接近Jeff 唯一的意见分歧在于流失可能性的判断 他们称之为真正的魔能两可有趣的是 正是类似的演示说服了他们全力投入 更有利的证据是他们的工作流评估 旨在衡量AI在代码环境下的表现 没有标准答案标签 也不对评估框架进行微调 迎演导致过你和每个模型 都运行相同的工作流 并根据GT6 Extra的平均表现评分 以及Fable 5.1他们说 Jeff 稳居 帕雷托 前沿 在近两个数量级的范围内 且由大语言模型处理所有逻辑 比起遵循工作流思维链的表现 明显差得多 这些调用远比演示案例复杂 更接近实际生产环境 他们将结果发布在评估网站上 他们认为可靠的工作流 是有许多小型的独立 由概率驱动的问题 组成最终导向一个分支 这就是 他们主页上那些数据的来源 也就是100 93.6倍的提速 以及444.6倍的成本缩减 Virtue将其四舍侮入为100 94和400 即45倍 这大概是实际应用中的上限 他们声称这些工作流 并非刻意挑选 且不在训练数据分布之内 但毕竟是他们自家团队构建的 所以难免存在偏差Astra 和Fable的参考案例 可能更偏向OpenAI和Anthlopic 所以他们认为自己可能还低估了性能 以及DeepSeek这些大模型 都是通过TypeSafe的开源系统运行的 即针对Python的大模型封装库 他们称这是获取大模型决策最准确的方式 但处理幻觉时速度较慢成本也更高 他们视类型安全为基本门槛 对智能体来说 工具调用产生幻觉是不可接受的 但对于有延迟要求的系统 这是致命的缺陷 或是深埋在依赖链的底层 即便是最强的模型也难免出错 它们的大模型指标来自OpenRouter 复杂查询会被自动路由到更强的模型 Jeff的零错误率不是测出来的 而是由模式匹配保证的 The Register的反驳很重肯 Jeff并不生成自然语言 以此演示其具备的实时智能 据他们说 工程师曾担心每秒十次查询 以及每小时七美元的成本 团队认为这比预期更低 他读取的是文本 而非图像格式的游戏状态 暂时还不是 他们也承认非AI机器人玩起来会更强 但他们想要的是 能适应多种游戏状态表达的AI 且能听从指令 用他们的话说着酷毙了 演示和黑客松活动即将开启 还有危机竞速 仅靠点击链接在成百上千个页面间穿梭 每一步都有上千种选择 充分展现了其极高的处理效率 面对海量选项不产生幻觉的优势会不断叠加 Jeff支持的基数上限为200 一旦超过这个数值 他会独立评估各个链接再进行选择 因此偶尔会出现减速 毕竟大模型没有推理过程整体提速空间有限 但Astra设为最低档以保证流畅度的情况除外 而且Jeff往往能以更少的步骤完成任务 这是我最喜欢的一点 第二和第三项挑战的起始页面都随机抽到了小黄鸭 直到团队指出来作者才发现这一点 开发者们蜂拥而至导致需求激增 以至于TypeSafe的API一度无法为用户提供服务 据TechCrunch报道 开发者将其视为一种更经济 更稳健的智能集成方案 Adversal公司的工程师Branet Sharma表示 他们此前一直在使用指令安全分类器 基于OpenAI的GPD-4O Mini模型 但换成Jeff后 处理速度提升了5到18倍 且准确度更高 Brio AI的CTO Nikhil Matokar 在处理商务邮件时 对比了Gemini的准确率 略胜一筹 但成本却高出10到20倍 让他感到震惊的是 况且Jeff是唯一能提供 真实概率反馈的模型 他认为这使其成为 自动化工作流的理想之选 AI Gateway的数据表现简直惊人 发布24小时内 Jeff吸引的付费团队数量 是此前任何模型的两倍多 这是Gateway历史上普及最快的模型 12小时内就超越了所有竞品 第18小时就覆盖了 1%的付费团队 第24小时是接近13% 是GPT 5.6系列的两倍 更是Fable 5.1的6倍多 而其他近期发布的模型 均未超过7% 首日数据就足以证明 专用模型投入生产环境的速度有多快 但真正的考验在于持久性谈到具体用途 Perser提到智能体可以自主选择下一个工具 或在子智能体的工作流中决定是继续重视还是询问用户 亦或在行动前先评估风险并决定是否终止 并将无法确定的情况转交人工处理 TypeSafe将其称为智能异服语句或模糊规则 因为手写逻辑往往过于脆弱 他们还建议使用Map 将PB级数据精炼为特征以支持实时应用 毕竟100毫秒的延迟完全在用户体验的可控范围内 从推理过程到越狱尝试全程进行验证 Amata希望人们能用它来监控智能体 由于智能体互间成本高昂 Runiker建议采用实时模型路由 The Register补充到聊天机器人人由LLM架构主导 编程助手代码智能体以及数学证明或演示等可验证任务 而这正如Type Safe戏称的那样 效果时好时坏 至于内部究竟如何 Amita手口如瓶 外界普遍怀疑其底层使用的是 开源权重的大模型 尽管Jeff称其FAQ文档内容并不短 Jeff模型完全采用合成数据进行训练 Amita告诉TechCrunch 资产数据是他人生中最成功的豪赌之一 比发布产品更成功 也优于RLHF TypeSafe自诩为一家核心的数据研究实验室 公司半数员工几乎主导了 统计学可控合成数据这一细分领域 这已成他毕生乐趣 即便你请求他们也不会用你的数据训练请见谅 想了解细节 得先被他们录用 这就是他们所奉行的苦涩教训 优化任务远比堆砌数据和算力重要 或是RLHF这类针对文本优化的算法 人类评估员偏好虽然适合聊天 却不适用于自动化任务 且RLHF仅适用于程序可校验的任务 导致其现实判断波动极大 智能表现不够稳健 系统1这一名称 源自卡尼曼的思考快与曼 尽管在传统认知中 系统1往往意味着一出错 但他们认为这些模型 其实比其他方案更可靠 他们还完全放弃了公开基准测试 仅提供一次性评估 并推动用户自行构建评估体系 因为系统1任务更易于评估 甚至还有篇题为反基准优化的文章 Jeff 这个名字源自威廉 Tauffell 这位19世纪的经济学家提出了一个悖论 当蒸汽机效率提升 煤炭需求反而不降反升他们压住的是 智能成本每降低一个数量级 就会解锁多出数个数量级的应用场景 阿尔梅达预见智能软件将无处不再呈现出涌现性 且更像早期互联网那样分布化而非如今的超级应用 但The Register 指出 这建立在一个假设之上 即Token的需求会像能源一样广泛 这尚未有定论PO研究中心 发现许多能用上AI的人根本找不到用处 CNBC调查显示另一些人则出于道德顾虑排斥AI 目前Jeff依然是特例 但Renneker预计竞争终会出现 他感叹我们本应早点看透这一点 毕竟大语言模型太便宜了 再加上补贴人们往往懒得去创新 但TypeSafe正在开发更多新模态版本 并开始从后补名单中邀请开发者 询问他们想实现什么样的科幻构想 当TypeCrunch问起TypeSafe 是否属于前沿实验室时 Almeta直言前沿实验室的主打产品 无非是恐惧和炒作 它追求的是真正智能 而非一场无限财富的豪赌 也不是某种宗教 更不是在数据中心里创造神 总之 这是Jeff 欢迎在评论区留言分享 你会如何使用它 感谢观看 我们下期见
本次執行流程與問題處理
下達指令
預期流程
- 自動字幕優先，Whisper 作為備援
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
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（來源選擇報告）
耗時：1052.6 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：44.7 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.9 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.9 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：1.0 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：1.0 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：151.6 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.7 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.7 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
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 環境與音訊後重試精進模式。