这集讲什么
TypeSafe AI CEO Diogo Almeida 认为,AI 真正的经济价值不在于继续制造更像人的“万能聊天同事”,而在于构建供代码直接调用、可组合、可校准、低成本且高度可靠的“System 1 模型”;Jev 正是他们对这一新模型类别的首次产品化尝试。
1-3要点
- AI 的主要消费者最终将是代码,而不是人类。
- 聊天模型与可编程模型不是同一种产品。
- 真正的目标不是最低价格,而是 intelligence per dollar。
0:00 / --:--
Latent Space · 9 月 21 日
TypeSafe AI CEO Diogo Almeida 认为 AI 的真正经济价值在于构建供代码直接调用、可组合、低成本且高度可靠的「System 1 模型」,而不是继续制造更像人的万能聊天同事。
TypeSafe AI CEO Diogo Almeida 认为,AI 真正的经济价值不在于继续制造更像人的“万能聊天同事”,而在于构建供代码直接调用、可组合、可校准、低成本且高度可靠的“System 1 模型”;Jev 正是他们对这一新模型类别的首次产品化尝试。
这集还没有学习卡。生成后会保存在这一集,下次直接打开。
Latent Space
Jev: System One models for Prod, not God — with Diogo Almeida, CEO, TypeSafe AI
YouTube
音频
official_en_transcriptJev 是 TypeSafe AI 推出的首个所谓 large programmable model(大型可编程模型)。Diogo 将这一类别描述为“machine-native System 1 models”:它的首要消费者不是正在聊天的人,而是软件、程序、API 和自动化工作流。
这里的“System 1”借用了认知科学中“快速、直觉式处理”的隐喻,但不能简单等同于人类心理学里的 System 1。Diogo 强调的是一种工程定位:
Jev 这个名字来自 Jevons Paradox(杰文斯悖论):当某种资源的使用效率提高、单位成本下降时,总需求不一定下降,反而可能大幅增长。TypeSafe 的产品假设是:如果模型调用足够便宜、快速且可靠,开发者不会只是“少花钱做同样的事”,而会把智能嵌入此前根本不值得自动化的大量软件路径中。
整期节目还包含 Diogo 对 RLHF、RLVR、公开基准、安全拒答、模型身份、预训练、SaaS、计算机使用和编码智能体架构的强烈批评。理解这些观点时,需要区分:
本集主线不是再造一个更会聊天的通用模型,而是重新定义 AI 的调用单位:从承担整段对话或完整任务,缩小为供程序反复调用的局部判断。TypeSafe 将 Jev 定位为 large programmable model,面向分类、提取、路由和决策等高频环节,核心指标不是人格感或长篇推理,而是结构化输出、低延迟、校准能力、稳定版本及“每美元智能”。其商业假设来自杰文斯悖论:调用足够便宜、可靠后,需求不会只来自现有任务降本,还会扩展到过去不值得自动化的软件路径,最终让 AI 像数据库一样被吸收进产品内部。
相对行业主流,最有价值的新信息是“程序在环”的产品观:聊天模型服务人的偏好,可编程模型则必须让代码理解其结果、置信度与失败状态。由此,RLHF 带来的肯定语气、公开榜单上的高分、面向用户的模糊拒答,都未必能转化为生产可靠性。校准尤其关键,因为系统需要据此决定自动执行、升级到更强模型还是请求人工确认。这一路线也为编码智能体提供了不同架构:不再把全部历史塞入单一上下文,而以显式任务树、状态管理、记忆检索和多模型路由组织工作;便宜模型负责控制面的局部判断,强模型处理真正困难的生成。
不过,Jev 目前更像一套有吸引力的工程命题,而非已被充分验证的新范式。RLCD 的定义、训练目标与消融结果尚未公开;全合成数据的质量控制、流量统计口径、“更多可靠性的 9”对应何种指标,也都需要核实。拒绝公开基准能避免为榜单过拟合,却同时削弱横向复核;把拒答视为 API 类型错误指出了接口缺陷,却不能消除模型层与应用层的滥用责任。对 AI 工程和创业团队,直接启示不是立即押注某个模型,而是先拆分任务、定义失败语义,以真实业务集测准确率、校准、延迟和单位成功任务成本;锁定版本并设置回退、人工确认与可回滚边界。若这一方向成立,护城河也不会只是 API,而在任务定义、数据体系、失败分布和长期版本可信度。
💬 他们说了什么:
Jev 发布后迅速占据 AI 开发者社区的讨论中心。Diogo 一方面形容自己已经累成“一具破烂的尸体”,另一方面又认为这是他多年来第一次感到行业认知与现实重新对齐:开发者开始理解,AI 不必被限定为聊天机器人,也可以成为真正的经济自动化组件。
TypeSafe 把工程师社区放在投资人和所谓 VIP 之前。节目提到其 Discord 已达到约 10 万人,发布视频也获得数千万次浏览。Diogo 强调,真正令他兴奋的不是注册数,而是开发者开始通过程序持续调用模型。
💡 为什么重要:
AI 产品常用注册用户、聊天轮数和社交传播衡量增长,但面向程序的基础设施应看另一组指标:持续调用量、重复工作流、单位调用创造的价值、延迟、故障率与集成深度。一次人工试用产生的几十次调用,可能远不如一个进入生产环境的循环任务。
这一判断也改变了增长瓶颈:普通消费产品担心没人使用,而可编程 AI 在找到产品市场匹配后,真正的压力会迅速转向速率限制、推理容量、跨区域部署和服务稳定性。
⚡ 争议点:
发布热度不等于长期生产价值。社区规模、视频播放量和 token 消耗都可能被营销、免费额度或高频低价值任务放大。若缺少客户留存、付费收入、真实任务成功率和故障数据,仍难确认这是否构成持久的“AI 经济革命”。
💬
Diogo 将 Jev 定义为 TypeSafe 的第一个 large programmable model,也称 machine-native System 1 model。与预训练语言模型对互联网文本的续写、RLHF 模型对人类指令的响应不同,Jev 从内部到外部都以软件集成为中心:模型输出应直接进入代码,成为程序执行链的一部分。
Jev 优化的不是单一的“最强模型”指标,而是 intelligence per dollar(单位美元智能)。成本、速度、可靠性和校准并非互相独立:真正目标是在特定预算和延迟约束下,为软件提供足够准确、可控的判断能力。
💡
聊天界面允许人类容忍、解释和纠正模型;程序接口则要求输出满足明确约束。一段“差不多正确”的自然语言可能对人有帮助,却会令下游程序崩溃。Jev 因而代表一种从“人机交互优化”转向“机器间接口优化”的产品哲学。
如果这一类别成立,模型选型也会从“哪家模型总体最聪明”转向“哪类模型适合哪种计算路径”:复杂规划交给慢速推理模型,大量局部判断则交给便宜、快速、可校准的模型。
⚡
“System 1 model”目前更多是 TypeSafe 的类别定义,而非行业已有统一标准。外界还需要知道它与小型分类器、微调模型、蒸馏模型、结构化输出模型及传统判别系统的实质区别。没有公开架构和系统评测时,类别创新与品牌包装之间的边界仍不清晰。
💬
Diogo 认为,RLHF 的一个关键副作用是 mode dropping 或 mode collapse:模型为了稳定地产生人类偏好的答案,会牺牲对完整概率分布的覆盖,集中到少数安全、常见且高奖励的表达模式。
他借 Yann LeCun 对自回归模型的批评说明这一点。直觉上,只要每一步都有出错概率,长序列出错率就应快速累积;但现实中的对齐模型会变得极度保守,避开容易被奖励模型惩罚的少数模式,因此可以生成长而表面连贯的文本。代价是其概率不再诚实反映不确定性,导致过度自信、谄媚和校准恶化。
对于 JEPA、世界模型和缩放定律,Diogo 的态度并非否定,而是强调实用性:研究是否优雅不是第一问题,能否在现有资源下解决真实任务才是。
💡
校准对自动化系统尤其关键。聊天时,模型给出 70% 或 95% 置信度的差异可能不明显;但在程序中,概率会直接决定是否执行操作、是否请求复核、是否升级给更昂贵的模型。错误校准会破坏整套风险控制逻辑。
模式坍缩也解释了为什么某些模型“说话越来越像”,以及为什么竞技场偏好可能奖励粗体、列表、长解释和追问,却不一定提高软件工作流中的决策质量。
⚡
Diogo 将多种现象——长文本稳定性、模式坍缩、过度自信、RLHF 风格化——放进同一解释框架,但节目没有给出实验设计或定量证据。不同后训练方法、奖励建模方式与解码策略的影响也可能不同,不能把所有校准问题一概归因于 RLHF。
💬
Diogo 并不反对安全本身,但反对把面向终端聊天产品的安全对齐直接下沉到通用 API。他把随机拒答称为“类型错误”:如果一个模型作为后台依赖,因输入触发安全策略而返回一段道歉文字,下游程序可能无法理解,更无法可靠恢复。
他区分了两种对齐:
在 ChatGPT 或 Claude 这样的第一方产品中,服务商有权设定产品边界;但在底层 API 中,Diogo 认为安全政策会让模型服从“另一个主体”,削弱开发者可预测性。他更愿意把智能比作数据库,而不是拥有独立身份和价值判断的同事。
💡
这是 AI 基础设施中真实存在的抽象层问题。应用层可以理解用户、组织政策与业务背景,底层模型却只看到被分解后的局部输入。若安全控制被分散到不可观察的模型内部,开发者就难以测试、审计和设定失败行为。
更好的工程设计可能不是简单取消安全,而是把政策显式化:返回机器可读错误、风险分数、可配置阈值和审计记录,让应用层决定阻止、升级或请求人工确认。
⚡
主持人提出最直接的反例:如果 API 被用于战争或伤害他人,模型提供商是否真的可以宣称“不关我的事”?Diogo 承认希望技术被用于善,但拒绝在模型技术层施加偏置。这一立场低估了基础设施提供者可能承担的法律、伦理和商业责任,也没有充分回答滥用防控应部署在哪一层。
💬
Diogo 极度反对以公开基准作为模型价值的核心证明。他认为,一旦测试集和评分方法公开,实验室就会有意或无意地收集类似数据、调整模型和选择性发布结果。即使没有直接训练测试答案,也可能出现“benchmarking with extra steps”。
他并非反对所有评测,而是更认可:
TypeSafe 的工作是持续增加“可靠性的 9”,客户的工作则是在自己的真实流程中衡量 Jev。
💡
通用模型排行榜很难替代任务级评估。企业真正关心的是:在自己的输入分布、错误成本、延迟预算和人工复核机制下,系统是否创造净价值。一个基准高两分的模型,可能因为更慢、更贵或更难校准而不适合生产。
Diogo 所说的“模型气味”虽然主观,却指向一个真实现象:经验丰富的开发者会从边界情况、错误形态和可控性中感受到模型差异,而这些往往不被单一平均分捕获。
⚡
彻底淡化公开基准也会削弱外部问责。只依赖“感觉和信任”容易让供应商选择最有利的案例,客户也难以横向比较。更合理的方案可能是公开、私有、任务级和生产指标并用,而不是从“基准会被操纵”推导出“公开基准没有价值”。
💬
Diogo 改写了 Rich Sutton 的 “The Bitter Lesson”。传统表述强调利用算力扩展的通用方法最终往往超过手工注入知识;Diogo 则进一步主张:
在他看来,语言模型发展中真正改变方向的任务创新并不多:RLHF 把目标转为指令遵循,RLVR 将可验证任务和推理引入训练,而 RLCD 则试图建立“程序在环”的新任务。
TypeSafe 因而自称更像一家 data lab,而非传统 model lab。其数据据称全部为合成数据,目标不是拟合今天用户最常问的问题,而是系统地发现“认知核心”的锯齿边界,再用数据修补一般能力。
💡
如果任务定义错误,再多算力只会更快优化错误目标。聊天偏好训练得越彻底,模型可能越擅长让人满意,却不一定越适合后台程序调用。TypeSafe 的核心赌注并非某个具体架构,而是“软件作为主要消费者”这一目标函数本身。
不训练用户数据还有两个潜在好处:降低隐私风险,并避免被当前流量的幂律分布绑架。若未来应用与今天完全不同,过拟合当前热门用例可能反而阻碍泛化。
⚡
“所有数据均为合成”不能自动保证高质量、无偏或无污染。合成数据会继承生成模型的盲点,也可能造成错误自我强化。TypeSafe 没有在节目中披露数据生成、筛选、验证和去重流程,因此“面向未来而非拟合现在”仍主要是方法论宣言。
💬
主持人要求 Diogo 解释 RLCD,以免它只是为了制造差异而创造的新术语。Diogo 没有在这段对话中公开 RLCD 的完整技术配方,也没有把重点放在某个强化学习算法上,而是从“RLHF 究竟是什么”反问。
他的解释是:RLHF 在历史上既可指从人类偏好学习的具体方法,也可泛指后来由 PPO、DPO 等不同算法实现的“指令遵循”任务。真正重要的不是 PPO,而是行业认可了“让模型遵循用户指令”这个 North Star。
同理,RLCD 所代表的是:
💡
算法名称容易让人把创新理解为损失函数或优化器变化,但大规模 AI 产品突破往往来自任务形态变化。ChatGPT 的意义不只是某个训练算法,而是把通用语言模型变成了可交互的指令系统。TypeSafe 希望 RLCD 对程序化 AI 起到类似作用。
这一视角也提醒开发者:不要只问“模型参数多大、用了什么 RL”,还要问训练反馈究竟奖励了什么行为,以及它是否与生产工作流一致。
⚡
截至节目内容,RLCD 没有公开论文、标准定义或足够实验细节,外界无法判断它是否是独立训练范式、数据方法、产品接口,还是多种技术的总称。TypeSafe 若希望该术语进入公共技术讨论,需要给出可复现定义与对照实验。
💬
Diogo 提出整期最核心的矛盾:AI 可以在数学、代码和复杂推理中表现出惊人能力,却仍无法稳定接管大量重复、枯燥、认知要求并不高的经济活动。问题不一定是发动机不够强,而是缺少接入软件世界的“插头”。
他认为传统聊天模型造成了严重的“过度承诺、交付不足”。展示中模型像一个博学的人,但在后台自动运行时,却会因不稳定输出、成本、延迟、拒答和错误校准而失效。Jev 的目标就是把大模型已有能力转换成软件可用的微型判断。
发布后,TypeSafe 声称每日调用量已超过 1 万亿 token,而且夜间仍持续运行,说明流量不只是人类试用,而包含机器发起的自动任务。Diogo 认为一个真正创造价值的循环,可能比全球用户各试几次更重要。
💡
经济自动化依赖的往往不是一次完成宏大任务,而是把工作拆成数百万个足够简单的小决策。例如:
只要这些判断足够便宜可靠,就能像数据库查询一样进入软件路径,并通过组合产生更复杂能力。
⚡
token 吞吐量不能直接换算为自动化价值。高流量可能来自低效提示、重复调用或免费试验。Diogo 关于“技术历史路径已改变”和“AI 寒冬已避免”的判断也明显超出节目所提供证据,需要收入、生产部署和长期留存来验证。
💬
这部分把讨论从愿景拉回工程指标。Jev 并不承诺数学意义上的绝对确定性;更现实的目标是让模型在输入扰动、重复调用和版本变化下表现得足够稳定,并让开发者知道何时可以信任输出。
Diogo 所说的“增加可靠性的 9”,借用了高可用系统的表达:90%、99%、99.9% 看似只差小数点,却决定一个能力能否成为关键依赖。聊天产品偶尔失败只是糟糕体验,嵌入交易、运营或数据管道后,同样的失败率会随着调用规模被放大。
校准在这里连接了概率模型与传统软件。若模型能提供有意义的置信度,程序可以设置阈值、回退路径和升级策略,而不是把每个输出都当作同等可信。
💡
生产 AI 的关键并非消灭概率性,而是把概率性变成可管理的系统属性。典型架构应包括:
这比要求单个模型“永不犯错”更符合成熟软件工程。
⚡
可靠性、鲁棒性和确定性是不同概念,不能互换。输出稳定也可能意味着模型稳定地产生错误答案;校准良好也不等于任务准确率高。TypeSafe 需要分别披露任务成功率、重复一致性、概率校准和分布外表现。
💬
当模型成为代码依赖,版本更新就不能只意味着“新模型更聪明”。生产系统需要稳定版本、长期支持、明确迁移窗口和可回归的行为。否则供应商的一次静默升级,就可能改变分类边界、概率分布或下游控制流。
Diogo 反复强调,成本和速度只是为“智能”支付的代价,而不是产品目的。便宜但无法完成任务的模型没有价值;极强但太慢、太贵的模型也无法进入高频路径。因此更合理的指标是:
地理位置同样会成为瓶颈。节目结尾提到,欧洲用户当时只能感受到约三倍速度提升,而非理想中的百倍量级,原因之一是尚未完成当地服务器部署,网络光速开始占据端到端延迟的重要部分。
💡
传统模型发布往往追求榜单提升,基础设施客户却需要可预测的生命周期管理。LTS 思维意味着模型供应商要像数据库、运行时或云服务一样承担兼容性责任。
当推理速度足够快后,性能优化会从 GPU 转向全链路:网络往返、序列化、连接复用、批处理、区域部署和客户端逻辑都可能成为主要瓶颈。
⚡
“智能/美元”具有吸引力,但智能无法脱离任务定义而成为统一标量。不同错误的成本不对称,一次高风险误判可能抵消数百万次低成本成功调用。实际采购仍需建立具体任务的效用函数,而不能依赖供应商给出的综合口号。
💬
Jev 的使用方式建立在结构化任务、显式分解和小决策之上。开发者不应把整个模糊目标一次交给模型,而应先用普通代码定义流程,再把难以手写规则、却容易根据上下文判断的局部步骤交给 Jev。
这与“AI 将消灭 SaaS”的说法相反。Diogo 更接近一种“逆 SaaS-pocalypse”判断:AI 不一定取代所有软件,而会逐渐消失在软件内部。用户未必看到一个聊天框,但排序、路由、状态识别、数据清洗和界面适配已经由模型参与完成。
计算机使用是典型案例。大量业务信息存在于没有 API 的旧系统、网页、桌面软件和内部工具中,可称为“暗数据”或不可直接编程的数据。若快速模型能够判断屏幕状态、选择动作或读取半结构化界面,它就能成为连接传统软件的适配层。
💡
这一路径将 AI 从独立产品转化为软件能力。用户不再为“AI”本身付费,而为更自动、更顺畅的原有产品付费。未来最成功的 AI 功能可能在界面中几乎不可见。
对开发者而言,最佳实践是“代码管流程,模型补语义”:状态、权限、事务和审计仍由确定性代码控制,模型只处理传统规则难以覆盖的模糊判断。
⚡
把任务切成小决策并不自动解决误差累积。局部准确率很高的模型,在长流程中仍可能因多步相乘而显著失败。计算机使用还涉及界面变化、注入攻击、隐私和不可逆操作,必须配套沙箱、权限最小化与回滚机制。
💬
最后约 40 分钟把 Jev 放回整个 AI 研究版图。Diogo 认为,“必须持续扩展 RLVR,然后担忧这种扩展很危险”的叙事预设了只有一条技术路线。RLVR 不只是可验证奖励,还包含让模型自由探索中间过程、以解决困难问题的整体任务形态。对 Jev 的目标而言,他甚至认为 RLVR 的最优用量可能是零。
谈到训练投资时,他表示即使得到 10 亿美元,也不会从头预训练。他更愿意采用中期训练、后训练、模型组合和“Frankensteining”解决问题,因为预训练极其昂贵,而现有模型已经提供大量可重用能力。
他回顾了自己从 OpenAI 到 TypeSafe 的路线:曾推动 InstructGPT 部署,看到它迅速获得使用,却也发现指令模型主要被用于营销文案等场景。由此他开始反推 AI 经济革命的调用者究竟是谁,答案是“绝大多数将是代码”。在 OpenAI 内部探索后,他最终与 Eric、Sasha 等人创立 TypeSafe,并在约两周内获得融资。
他对多数 Neo-lab 的批评是:重视研究履历和预训练规模,却没有清晰任务方向。节目结尾,他给出两个希望他人探索的方向:
KV cache 让智能体倾向于不断向同一上下文追加内容,造成模型锁定、状态混杂、压缩困难和子智能体低效。Diogo设想把状态、任务树、记忆和读写权限显式管理,让不同模型处理不同难度的子任务,并让多个智能体共享必要状态、并行协作。
💡
这段提出了一条不同于“单模型、单上下文、不断变长”的智能体路线:把智能体重新视为分布式软件系统。模型只是计算节点,真正的架构重点是:
这可能比单纯增加上下文窗口更符合软件工程规律,也与 Jev 的“小决策原语”定位相互呼应。
⚡
Diogo 对 RLVR、预训练和 Neo-lab 的评价带有明显个人立场。他没有证明从头预训练在所有情况下都不划算,也没有证明 KV cache 是多智能体失败的主要原因。节目中关于 AI 前沿节奏与美国选举政治动机的谈话,是参与者转述的私人讨论和推测,不应当作经过验证的事实。
Diogo Almeida
TypeSafe AI CEO,自称“技术型 CEO”。曾在 OpenAI 工作并参与早期指令遵循模型的推进。他把 TypeSafe 的使命定义为构建供软件直接调用的智能基础设施。
swyx
Latent Space / AI Engineer 生态的主持人与评论者。本期负责追问 Jev 定义、RLCD、安全边界、评测和编码智能体架构。
TypeSafe AI
Jev 的开发公司。Diogo 将其描述为以数据和任务设计为核心的实验室,长期愿景是建立类似“智能领域 AWS”的多层基础设施。
Jev
TypeSafe 首个大型可编程模型,强调 System 1、小决策、可靠性、校准、速度与单位成本智能。
OpenAI
Diogo 的前雇主,也是节目讨论 RLHF、InstructGPT、ChatGPT、函数调用和组织研究方向时的主要参照对象。
Anthropic / Claude
被用于对比聊天产品、安全策略、编码智能体和模型工具调用。
Yann LeCun
Meta 首席 AI 科学家。节目讨论了他对自回归 LLM 的批评、世界模型与 JEPA 路线。
Rich Sutton
强化学习研究者,《The Bitter Lesson》作者。Diogo 借其框架强调通用方法、数据与正确任务方向。
Paul Christiano
与早期从人类偏好学习的研究相关,被 Diogo 用来追溯 RLHF 的历史含义。
Eric、Sasha
TypeSafe 早期团队成员。Diogo 回忆自己决定创业后邀请 Eric,并在与 Sasha 讨论研究方向时得到她主动加入。
Dario Amodei、Alec Radford、Ryan Lowe
在节目回顾 OpenAI 早期 RLHF、摘要和指令遵循研究谱系时被提及。
Jasper AI、Copy.ai
被用作早期指令模型主要商业落地之一:营销文案与网页内容生成。
PrimeAgent / RLM
主持人在结尾提到的相关探索方向,用于回应层级任务、递归模型与智能体状态管理问题。
“The goal is for code to be the consumer.”
目标是让代码成为模型的消费者。
— 02:50 🎧
“Jev is meant to be optimized for intelligence per dollar.”
Jev 要优化的是单位美元能够购买到的智能。
— 05:03 🎧
“Refusal is just obviously a type error.”
拒答显然是一种类型错误。
— 11:41 🎧
“I think intelligence will be more like a database than a coworker.”
我认为智能更像数据库,而不是同事。
— 15:54 🎧
“Doing the right task, having the North Star, is the hardest, most important thing.”
做正确的任务、找到正确的北极星,是最困难也最重要的事。
— 20:43 🎧
“We are a data lab.”
我们是一家数据实验室。
— 21:31 🎧
“If every single human being in the world just wrote a couple of queries, that would be a rounding error compared to one power user’s for loop.”
全世界每个人各试几次,可能还不如一个重度用户真正创造价值的循环调用。
— 36:45 🎧
“If you gave me a billion dollars, I wouldn’t pre-train.”
即使给我十亿美元,我也不会选择从头预训练。
— 01:49:33 🎧
“Frankensteining is not the most elegant, beautiful thing, but it solves problems, baby.”
把模型‘科学怪人式’拼接起来也许不够优雅,但它能解决问题。
— 01:49:33 🎧
“The solution is begging in a system message. That’s nuts.”
现在的解决办法是在系统提示里求模型照做,这太荒谬了。
— 02:17:22 🎧
聊天模型的默认调用单位是一次对话或一个完整任务。Jev 希望把调用单位缩小为一个局部判断。调用粒度越小:
这与微服务和 Unix 工具哲学相似:每个组件只做一件事,再通过组合产生复杂系统。风险在于,AI 决策不是严格确定的函数,组合后会出现概率误差传播,因此还必须增加置信度门控和端到端评测。
如果接受这一比喻,模型提供商就应提供数据库式能力:
但数据库比喻也有边界:数据库通常执行明确查询,而模型会根据训练分布进行近似推断。模型即使接口稳定,语义也可能漂移。
Diogo 对 API 拒答的批评指出了真实问题,但更稳健的结论不是“底层不需要安全”,而是把安全拆成不同层次:
生产系统最忌讳的是“不可预测的隐性政策”。即使必须拒绝,也应以稳定错误码、原因类别和可测试规则呈现。
人类偏好往往奖励清晰、肯定、有帮助的回答,却未必奖励“诚实表达不确定性”。因此,偏好优化可能让模型在主观体验上更好,在概率决策上更差。
实际评测不应只看答案正确率,还应测:
企业不会仅因模型出现就放弃权限、计费、审计、工作流和行业知识。更可能发生的是:
这意味着 AI 创业不必全部做独立助手,也可以成为现有软件的智能化基础层。
当前编码智能体经常把终端输出、文件内容、计划、错误日志和历史对话全部塞进线性上下文。KV cache 让这种追加方式经济高效,却也限制了架构设计。
更软件工程化的方案可能包括:
Jev 若能提供低成本局部判断,可能更适合担任智能体控制平面的“胶水模型”,而不是替代负责复杂代码生成的主模型。
API 形式容易复制,模型也可能被更大实验室模仿。更难复制的部分可能是:
这也解释了 Diogo 为什么强调招聘“model capabilities”人员,而不愿让“数据工作”在组织中被视为低地位劳动。
RLCD 的技术定义尚不透明。
节目把它描述为新的 North Star,却没有公开完整名称、目标函数、训练过程、数据格式或消融实验。
Jev 的独立性能证据不足。
TypeSafe 主动拒绝以公开基准作为核心营销手段,但也因此缺少便于外界复核的横向数据。
“每日一万亿 token”需要明确统计口径。
应核实其是否包括输入、输出、缓存命中、免费测试、内部流量及失败重试。
“更多可靠性的 9”尚未对应公开 SLA。
需要区分平台在线率、模型任务成功率、结构化输出有效率和重复一致性。
全合成数据的质量控制没有公开。
需了解生成来源、人工审核比例、去重、污染检测以及如何避免合成偏差循环。
“公开基准有害”是过强结论。
公开测试确实容易被优化,但仍能支持透明比较、学术复核和最低能力检查。
把拒答称为类型错误忽略了滥用责任。
工程接口问题与安全责任是两个问题。可预测的安全返回值能修复前者,却不会自动解决后者。
“预训练不值得做”只适用于特定公司位置。
能直接利用成熟基础模型的应用实验室,与需要掌握底层权重、数据主权或新模态能力的实验室,资本选择并不相同。
对 RLHF、RLVR 和 Neo-lab 的概括较为宽泛。
不同团队的方法和目标差异很大,不能把所有后训练、推理训练或新实验室视为同质路线。
发布播放量和社区规模需外部核验。
社交平台显示口径、自动播放、重复曝光和时间窗口都会影响数字。
InstructGPT 的“50% 市场份额”缺少市场定义。
需要确认是 OpenAI API 内部模型使用占比、某类 LLM 请求占比,还是更广义市场份额。
有关 2028 年美国选举与 AI 前沿节奏的说法属于现场转述和推测。
节目没有提供公开文件或可核实证据,不能据此推断任何公司或研究机构的正式动机。
“ChatGPT 是 Claude 的复制”是高度简化的历史叙述。
两家公司均存在长期内部研究和产品迭代,仅凭发布时间或内部工具相似性无法得出完整因果结论。
KV cache 未必是智能体架构问题的唯一根源。
工具可靠性、环境反馈、任务规划、模型能力、记忆检索和权限设计都可能造成子智能体失效。
先拆任务,再选模型。
把端到端流程拆成分类、提取、判断、路由、生成和验证等步骤,不要把整个业务目标一次性交给模型。
为每一步定义失败语义。
明确输出无效、低置信度、超时、拒答和服务不可用时,程序分别如何处理。
建立置信度分层。
高置信度自动执行,中置信度调用更强模型,低置信度进入人工复核。
同时衡量质量、成本和延迟。
使用“每个成功任务成本”,而不是单纯比较每百万 token 价格。
锁定模型版本。
新版本上线前运行真实业务回归集,避免供应商升级静默改变控制流。
保留确定性代码边界。
权限、资金、事务提交、审计和不可逆操作应由代码控制,模型只提供建议或受限动作。
不要把 token 消耗当作价值。
跟踪节省的人力时间、减少的错误、提高的转化率和缩短的处理周期。
在正式进入关键生产路径前,至少完成以下验证:
official_en_transcript