从“会聊天”到“可调用”:TypeSafe CEO谈代码模型的机器原生路线

代码模型应减少拟人化表达,以结构化输出和可验证训练提升机器调用效率。

冷月清谈:

TypeSafe AI 联合创始人兼 CEO Diogo Almeida 认为,随着 API 的主要调用者从人类转向程序与 Agent,代码模型不应继续把算力浪费在自然语言润色、客套应答和复杂排版上。其机器原生模型 Jev 不生成自由文本,而是面向高并发、强类型场景提供结构化、低延迟且更确定的输出。Almeida 主张以“每美元智能”和帕累托前沿衡量模型价值,关注单位成本下可稳定交付的有效逻辑与类型安全代码。他还指出,RLHF 可能引入过度解释、格式噪音及自信但错误的结果,代码训练应更多采用程序运行信号、可验证反馈和 RLCD 范式。未来的软件工程或将形成由结构化模型、确定性 API、编译器与 Agent 协同运转的自动化闭环。

怜星夜思:

1、代码模型完全不输出自然语言,真的会比通用大模型更实用吗?哪些场景最适合这种路线?
2、“每美元智能”应该怎么衡量,才能避免变成另一个好听但难落地的指标?
3、如果代码模型放弃人类偏好对齐,会不会带来新的安全、可解释性或责任边界问题?

原文标题:TypeSafe CEO 为何主张代码模型必须放弃拟人化?

原文作者:机器之心

原文内容

本文来自PRO会员通讯内容,文末关注「机器之心PRO会员」,查看更多专题解读。

随着生成式 AI 与代码大模型的深度渗透,代码 Agent 和程序系统逐渐取代人类成为 API 的主要消耗主体。传统大模型将庞大的算力和上下文预算消耗在自然语言润色、客套应答与复杂排版上,这种拟人化表达在造成算力浪费的同时,也让开发者在面对高并发与强类型的工业级代码需求时遭遇了延迟与不确定性瓶颈。作为前 OpenAI 核心研究员、InstructGPT 与 ChatGPT 共同作者兼机器原生模型 Jev 的主导开发者,TypeSafe AI 联合创始人兼 CEO Diogo Almeida 提出,代码大模型的评估标准需要严格转向每美元智能与帕累托前沿,彻底放弃自然语言表达与人类偏好对齐,转而通过 RLCD 范式与确定性 API 构建直接被系统代码消费的底层基础设施,从而抹平开发者的试错成本并推动软件工程迈向全自动化闭环。


目录

01. 为什么「RLHF」路线会误导代码开发者?
什么是「每美元智能」与「帕累托前沿」?
...

02. 强代码强化学习如何走向「RLCD」范式?
「RLCD」把哪些程序运行信号当成了训练奖励?...
03. 结构化代码底座与 Agent 协作将如何重塑软件工程?
限定结构化生成后,如何降低 KV Cache 延迟?...


为什么「RLHF」路线会误导代码开发者?

1、TypeSafe AI 联合创始人兼 CEO Diogo Almeida 近日接受专访,围绕机器原生模型 Jev 的发布,剖析了传统文本模型在代码场景下的优化误区,提出代码模型必须摆脱拟人化对齐,转而围绕每美元智能与程序在环范式构建高可靠的底层计算基础设施。

① Diogo Almeida 曾为 OpenAI 语言团队核心研究员,参与了 InstructGPT 与 ChatGPT 的研发,现担任 TypeSafe AI 联合创始人兼 CEO。

② Jev 是 TypeSafe AI 推出的 System 1 机器原生模型,该模型放弃了文本生成与人类偏好对齐,不输出自由文本,专为高并发与强类型的代码决策场景设计。Jev 上线之后,凭借相对可观的延迟与成本表现,迅速吸引大量开发者与平台接入生产环境。

2、Almeida 认为 API 消费主体的结构性转变正倒逼模型评估标准的重塑,当主要调用者从人类转变为程序代码与 Agent 时,过去为迎合人类阅读偏好所做的文本优化会造成严重算力浪费。

① 过去几年 AI 行业陷入了将模型拟人化的思维惯性中,主流厂商将庞大算力与上下文预算消耗在自然语言润色、客套应答与复杂排版上;但在代码场景中接收输出的是下游编译器与解析器,程序要求的是极低响应延迟与极高结构确定性。

② 在帕累托前沿的工程推算中,算力在自然语言表达与逻辑验证之间存在明确的竞争关系,彻底放弃多余的自然语言表达能够将每一单位算力与生成 Token 都投入到类型推演中,实现系统吞吐量的数量级提升。

3、围绕重塑后的工程架构,Almeida 提出每美元智能才是衡量工业级代码基础设施效率的核心指标。该指标要求模型的优化目标摆脱单纯追求基准测试得分的误区,转而将所有工程算力集中收拢到提高单位资金投产比与有效推理能力上。

① 每美元智能指在特定的 API Token 成本与计算预算限制下,模型所能稳定交付的确定性逻辑与类型安全代码总量。

4、在模型训练与对齐路径上,Almeida 指出基于人类反馈的强化学习(RLHF)范式存在着模式崩溃(Mode Collapse)与校准(Calibration)失效的问题,可能会使模型生成过度迎合人类偏好、多样性下降、自信但错误的输出。

① RLHF 旨在对齐人类沟通语气与安全拒答,但该技术会给模型注入过度解释倾向,导致生成的代码中混入非确定性的解释文本与格式噪音,在代码解析中构成异常来源。

② 这种为迎合人类偏好而产生的自然语言谄媚与幻觉会破坏了下游机器调用场景所必需的语法确定性,导致模型在处理自动化编译与结构化接口解析时容易发生非预期的崩溃。


代码强化学习如何走向「RLCD」范式?

1、随着大模型向复杂推理(如数学、代码)领域深入,RLVR(基于可验证结果的强化学习)逐渐兴起,Almeida 则认为 RLVR 虽能解决 Navier-Stokes 等特定问题,但会加剧「锯齿状智能」(jagged intelligence)的现象...

 关注👇🏻「机器之心PRO会员」,前往「收件箱」查看完整解读 

更多往期专题解读内容,关注「机器之心PRO会员」服务号,点击菜单栏「收件箱」查看。

我会设计分层指标:任务成功率衡量质量,P95 延迟衡量稳定性,单位成功任务成本衡量经济性,再按业务价值加权。否则生成十万个没用的小函数,也能把“每美元产量”刷得很好看。

3 个赞

从系统工程角度看,关键不在于有没有自然语言,而在于输出是否满足可验证契约。高频、窄任务、强约束场景最适合专用模型;低频、开放式任务则更需要通用模型。两者可能长期共存,而不是谁淘汰谁。

1 个赞

这个指标最怕财务看了兴奋、开发看了沉默。模型调用费省了五成,结果工程师多花两小时擦屁股,那不是“每美元智能”,是把账单从 GPU 挪到了工资表。

3 个赞