乐于分享
好东西不私藏

OpenAI后训练负责人杜布瓦:AI正从“竞赛跑道”走向“实用生产力”,持续学习仍是最大难题

OpenAI后训练负责人杜布瓦:AI正从“竞赛跑道”走向“实用生产力”,持续学习仍是最大难题
来源:瓜哥AI新知

本文内容整理自OpenAI Post-training Frontiers Co-lead Yann DuboisThe MAD Podcast with Matt Turck频道的专访,公开发表于2026年05月21日。
原始内容参考:https://www.youtube.com/watch?v=DhD1zZ8w8Mw

内容提要: OpenAI后训练负责人Yann Dubois在The MAD Podcast的专访

  • 可靠性触发了阶跃式进化: 尽管人工智能能力的增长是渐进的,但当模型可靠性跨越临界阈值(OpenAI于去年12月实现)时,它便赢得了处理复杂任务的信任。在用户体验端,这完成了从“竞赛玩具”到“生产力工具”的阶跃式蜕变。
  • “后训练”与推理的核心价值: “后训练(Post-training)”是让“通晓万物”的模型真正为人类所用的关键。通过强化学习(尤其是针对实际效用的优化),模型学会了自我纠错、路径探索和验证逻辑,使其在处理真实世界的复杂任务时,展现出远超预训练阶段本身的能力水平。
  • 推理期计算(Test-time compute)的权衡艺术: 赋予模型更多的“思考时间”(生成更多Token)能显著提升表现,但存在边际递减效应。未来的破局之道在于:在保持同等精度的前提下,将“推理缩放曲线”整体向左推移,从而大幅降低延迟、提升效率。
  • 预训练仍未触碰天花板: 模型规模的扩张依然红利不减,更强大的基础模型在推理时具备更高效的并行信息处理能力。所谓的“数据墙”并未出现,大模型正在通过极高的数据利用率和合成数据技术,轻松跨越数据受限的障碍。
  • “持续学习”仍是未解之谜: 尽管模型在发布之初惊艳四座,但如何让它们在特定环境中实现个性化进化(随使用时间增长而越来越懂用户),依然是全行业尚未攻克的终极难题。当前的AI效用曲线起点极高,却在时间推移下趋于平缓,远未达到人类专家持续学习的境界。
  • 应用层“最后一公里”潜藏巨大红利: 通用大厂正专注夯实底层通用能力的“地基”,而特定垂直领域的深耕(如权限管理、系统集成、行业工作流打通)依然敞开着巨大的机会窗口。初创企业应当死磕这“最后一公里”,将大模型的效用在垂直场景中压榨到极致。

OpenAI Post-training Frontiers Co-lead Yann Dubois 简介

扬·杜布瓦(Yann Dubois)是 OpenAI 后训练(Post-training)团队的联席负责人,专注于将大模型打磨成能完美契合生产环境与专业场景的智能系统。他深度参与了 OpenAI 的 o1、o3、GPT-5 前沿推理模型的训练与部署。此前,他曾在斯坦福大学深造,并核心参与了对现代AI研究社区产生深远影响的 Stanford Alpaca 项目。

内容简介

AI 仿佛在一夜之间跨越了一道极其关键的门槛。OpenAI 后训练前沿团队联席负责人扬·杜布瓦(Yann Dubois)做客本期节目,与 Matt Turck 共同揭秘这背后的底层逻辑。扬的团队主导了公司推理模型(包括近期重磅发布的 GPT-5.5)的后训练工作。

在这场深度对话中,我们剖析了 AI 是如何从“原始模型能力”向“实用可靠的系统”发生范式转移的:GPT-5.5 究竟带来了哪些质变?为什么强化学习正在跳出数学和编程竞赛的温室,杀入充满不确定性的真实世界工作流?像 GPT-5.5 这样的推理模型到底是如何运转的?GPT-5.5 Thinking 与 GPT-5.5 Pro 之间有何本质差异?

我们还探讨了为什么“后训练”已经成为当前 AI 领域最核心的前沿阵地,以及为什么评估体系(Evals)、“模型即裁判(Model-as-judge)”、幻觉治理、Agent智能体工作流、GDPval 乃至持续学习,已然成为下一代前沿模型的主战场。最后,扬也坦诚分享了在 ChatGPT 发布三年后的今天,为什么“持续学习”依然是 AI 最大的未解之谜,以及在前沿大模型狂飙突进的当下,初创公司为何在“最后一公里”仍有巨大的施展空间。

访谈全文

扬·杜布瓦: 你必须达到这种可靠性水平,才能让这些 AI 工具真正发挥巨大作用。我认为我们大概在去年 12 月跨越了这个门槛,至少在 OpenAI 是这样。现在我们可以放心地把手头的很多工作交给这些模型去处理。过去几个月的发展非常顺利。我们从跑分竞赛的象牙塔,走向了为用户创造真实价值的广阔天地。 这正是我们当下的切身感受。我认为大多数时候,真正的瓶颈(bottleneck)在于“最后一公里”。在各个垂直领域,这“最后一公里”总蕴含着巨大的发展空间。我强烈建议大家继续在这个方向深耕。

主持人马特·特克: 大家好,我是 Matt Turck,欢迎收听《Mad Podcast》。今天的嘉宾是 Yann Dubois,他在 OpenAI 共同领导后训练前沿(post-training frontiers)团队。

近期发布的 GPT-5.5 是人工智能领域的又一个重要里程碑,Yann 的团队与 OpenAI 之前的顶级推理模型(包括 o3 和 GPT-5 thinking)一起参与了该模型的构建。在加入 OpenAI 之前,Yann 在斯坦福大学工作,他是标志性项目斯坦福 Alpaca(Stanford Alpaca)的合著者,该项目开启了现代后训练研究社区的大量工作。

在这次对话中,我们将深入探讨 GPT-5.5 的真正创新之处,为什么强化学习(reinforcement learning)正在从数学和编程竞赛转向错综复杂的现实世界工作,为什么人工智能的进步有时看起来像是一个突发的阶跃函数(step function),以及为什么在 ChatGPT 发布三年后,持续学习(continual learning)仍然是人工智能领域悬而未决的重大难题之一。请享受我与 Yann Dubois 的这场精彩对话。

为什么近期 AI 的进步感觉像是阶跃函数 (Step Function)

主持人马特·特克: 嘿,Yann,欢迎来到节目。在前沿 AI(Frontier AI)领域,随着 GPT-5.5 和 Claude Mythos Preview 的发布,我们又度过了疯狂的几周。感觉我们在发展进程中又解锁了一个阶跃函数,特别是在网络安全和代理编程(agentic coding)方面。从你的角度来看,理解这一点的最佳方式是什么?事物是在加速发展吗?究竟发生了什么?

扬·杜布瓦: 嗨,Matt,谢谢邀请。是的,过去几个月的情况确实非常好。在 OpenAI 内部我们的感受非常强烈,我想现在任何从事编程工作的人也都深有体会。我认为这主要归功于三个原因。

第一个原因是,尽管在我看来进步一直是连续的,但你必须达到一定的可靠性水平,才能让这些 AI 工具真正发挥巨大作用。我认为我们大概在去年 12 月跨越了这个门槛,至少在 OpenAI 是这样。现在,我们可以放心地把很大一部分工作交给这些模型去处理。因此,尽管能力的增长是平滑连续的,但其带来的影响却犹如阶跃函数般发生了质变。

第二个原因是,一旦你拥有了真正强大的模型,你就能开始加速自己的工作,尤其是在编程方面。因为我们在内部都需要写代码,这些模型可以帮助我们训练其他模型,并构建我们作为研究人员日常所需的专用工具。所有这些叠加的加速效应,使得过去几个月的发展飞轮越转越快。

第三个原因是,在去年一整年里,我们高度聚焦于推理模型,并在强化学习上投入了巨大精力。最初,对于像 o1、o1-preview 甚至 o3 这样的模型,我们主要针对“可验证奖励(verifiable rewards)”进行优化——即那些我们掌握标准答案(ground truth)且容易测试正确性的任务,比如数学题或编程竞赛。但我们现在意识到,完全可以将这些为可验证奖励场景打造的工具,更广泛地应用于错综复杂的现实世界用例中。正是这一转变,造就了我们眼下感受到的强劲势头。

模型可靠性与发布 5.5 版本的心路历程

扬·杜布瓦: 也就是真实的编程工作,而不仅仅是打比赛。我们从跑分竞赛的象牙塔,走向了为用户创造真实价值的广阔天地。 这正是我们当下的切身感受。

主持人马特·特克: 太令人着迷了。我们将深入剖析这些内容,特别是强化学习(RL)方面。关于你提到的第一点:可靠性。这是一个工程问题还是模型问题?在你的语境下,究竟是什么让一个模型变得“可靠”?

扬·杜布瓦: 这两者兼而有之。但总的来说,考虑到这些是代理(agentic)模型,你可以这样想:每隔两分钟,它们就有一定的概率出错。模型运行的时间越长,最终答案出错的累积概率就越高。这是代理模型固有的一种特性。

而我们一直在极力推进的,就是确保降低模型这“每两分钟出错的概率”。这纯粹是从模型的角度来看,当然,应用侧也进行了大量的可靠性优化,OpenAI 的应用团队在这方面做得非常出色。

但我这里特指的,是我们模型本身的可靠性,我们要从根本上压低它们犯错的概率。

主持人马特·特克: 太好了。5.5 版本(内部代号曾为 Spud)正如刚才所说,是一个大事件,意义非凡。我很好奇从内部视角来看,你们最引以为傲的是什么?你们觉得最具挑战性的是什么?能不能给我们讲讲,你们在发布这款模型时的真实感受?

扬·杜布瓦: 说实话,我们对 5.5 版本都感到无比兴奋。它是那种全公司所有人都深度参与构建过程的模型,我们现在确实感受到了它的分量。因为 5.5,我们受到了极大的关注,仿佛“天时地利人和”全都凑齐了——这种情况可不常见。从这个角度来看,它是一个出色的模型,我们也切身感受到了那股势不可挡的势头。

有趣的是,通常当一个模型在早期表现得极其出色时,大家都会兴奋不已。但紧接着往往会袭来一阵自我怀疑,因为我们担心:虽然内部呼声很高,但这模型会不会在其他任务上表现得很糟糕?随后,又会出现一阵大家开始“反向降温”的浪潮。

这种情绪的周期性波动很常见,我们内部的感受往往取决于模型实际发布的时机。5.5 版本在这方面也不例外,甚至它所经历的情绪波动幅度可能更大。大家一开始热血沸腾,随后热情骤降,但当我们最终将其推向市场时,外部的反响极其热烈。

主持人马特·特克: 这个过程通常需要多久?包括这种兴奋感的起起落落。我想这取决于发布的具体内容和每次发布的重要性,但大概是几周,还是几个月?

OpenAI 如何架构垂直与水平团队

扬·杜布瓦: 这真的取决于具体情况。我不能透露 5.5 的具体开发细节,但这取决于流水线(pipeline)中是哪个环节在训练模型。我们确实划分了不同的子团队,包括预训练(pre-training)、中段训练(mid-training)阶段,以及后训练(post-training)。通常来说,越靠近产品端——比如后训练作为最后一环——迭代周期就越快。而你所处的位置越靠上游,迭代周期就越长。所以,这个周期基本上可以从几个月跨度到几天不等。

主持人马特·特克: 5.5 版本在编程(coding)、计算机操作(computer use)、知识型工作和早期科学研究方面表现尤为出色。这在内部是如何运作的?是有不同的团队分别专注于这些不同的领域吗?你们是如何达成这一成果的?

扬·杜布瓦: 我们确实有不同的团队致力于特定的用例,并推动这些用例的发展。我的团队专门负责将所有这些垂直领域的改进整合到最终模型中。你可以将我们视为一个起到平滑作用的团队;尽管拥有各种改进方案,但必须确保模型在不同垂直领域之间不会显得过于突兀或不连贯。

我的团队还负责所有横向改进(Horizontal Improvements)。例如指令遵循(Instruction Following)、函数调用(Function Calling),或者权衡模型在处理不同问题时应该“思考”多少。这些都是非常横向的能力,会影响所有的用例。我们同时拥有垂直团队和横向团队,两者对于改进模型都至关重要。

好处在于,这些领域可以独立且互不干扰地(Orthogonally)进行改进。你可能有多个团队负责某些垂直领域,而对于某一个特定的模型版本,可能只有一半团队的改进被整合了进去。到了下一个版本,可能就是另外一半团队的成果。从高层视角来看,流程大致就是这样。

关于这个模型最令我们自豪的地方,我想强调两点。第一是效率:我们实现了显著的提升,大多数任务现在的执行速度大约是之前的两倍。第二点是我之前提到的公司内部的协同一致(Alignment)。确保每个人都朝着同一个目标努力——在特定时间表内构建一个卓越模型的“北极星(North Star)”愿景——这让我感到无比自豪。

提升模型效率与测试时计算(Test-time compute)

主持人马特·特克: 提到效率,你们是如何进行优化的?我们是在说每个 Token 的效率吗?还是涉及模型服务的延迟?在这其中,哪些部分属于 AI 研究,哪些属于工程?

扬·杜布瓦: 这就是为什么我说是整个公司在共同努力;效率的提升源于方方面面。它既需要推理优化(Inference Optimizations),也需要模型在思考时间上变得更高效。

通常你应该关注这样一张图表:横轴代表思考的 Token 数量,纵轴代表性能表现。这就是我们关注的测试时计算缩放曲线(Test-time Scaling Curves)。研究团队的核心目标就是将这条曲线向左移,力求用更少的思考时间达到相同甚至更高的准确率。

推理(Inference)团队同样关注横轴,但他们将焦点从 Token 数量转移到了实际的延迟(Latency)上。用户最终真正关心的是以延迟为横轴、性能为纵轴的曲线,这里是所有努力的交汇点。这也是 5.5 版本真正实现的突破。这就是为什么我说,我为公司在这方面的表现感到无比自豪。

主持人马特·特克: 好的。我们来聊聊你个人。你在后训练前沿(Post-training Frontiers)团队,你之前描述这是一个横向团队。那么这个团队总体上负责什么呢?

扬·杜布瓦: 我们主要做三件事。广义上,我们属于后训练(Post-training)部门,而我的团队负责其中的前沿(Frontiers)部分。

首先,我的团队决定最终的训练运行(Final Run)中包含哪些内容。如前所述,我们有不同的垂直领域,必须有人来拍板什么能进、什么不能进。我们还负责提供科学实验环境,让人们能在代表最终运行结果的基础上进行迭代。

其次,我的团队负责将所有成果整合在一起,并实际执行这次大规模训练(Big Run)。如你所想,我们在海量的 GPU 上进行训练。这不仅需要繁重的底层基础设施(Infrastructure)建设,还需要极高水平的机器学习工作来整合一切,确保所有组件协同良好。

第三,我的团队专注于模型的横向改进。基本上,这些是垂直团队通常不会太关注的方面。正如我之前提到的,比如“思考时间”——决定模型针对某些回答应该思考多久。其他领域还包括指令遵循、函数调用、记忆功能,以及跨越整个技术栈的模型通用改进。这就是后训练前沿(Post-training Frontiers)团队的工作,而我正是这个团队的负责人。

Yann Dubois 从瑞士到 OpenAI 的旅程

主持人马特·特克: 你是如何一路走来加入 OpenAI 的?

扬·杜布瓦: 这是一个很长的故事,但我尽量长话短说。我来自瑞士,本科在那里读的是生物医学工程。后来,我获得了一个去加拿大交换的机会,在那里我了解到了 word2vec。

不知道你是否听说过这个算法,它本质上是将离散的单词映射到一个向量空间(Vector Space)中。你可以将其想象成一个平面,语义相近的单词会被放置得更靠近。它将这些离散的单词带入了一个具有丰富语义的连续空间。我当时完全被这个算法震撼了,也就是在那时,我决定投身于自然语言处理(NLP)和语言理解领域。

那是在 2017 年,就在 Transformer 架构出现之前。我当时的想法大错特错,我竟然以为英语 NLP 已经基本被解决,或者接近被解决了。正因如此,我决定去研究那些资源不足的语言,通过改进 NLP 来帮助那些缺乏数据的语言。

于是,我去了新加坡的 Grab 工作,构建了他们的自然语言处理流水线。我处理过高棉语、印尼语(Bahasa)、泰语、越南语以及其他多种语言。

跳过中间的过程,我在不同国家做了一些学术研究,最终去了斯坦福大学攻读博士学位。之后,我在初创公司短暂工作了一段时间,然后加入了 Hugging Face。

主持人马特·特克: 我记得在你的博客或主页上看到过一条声明,建议量化交易公司不要联系你,因为你对对冲基金的工作不感兴趣。

扬·杜布瓦: 是的,因为我一直认为,时刻思考自己正在对世界产生的积极影响,或者至少是我试图产生的积极影响,对我来说至关重要。这就是我写下那条声明的原因。

主持人马特·特克: 正如我们在录音前聊到的,大家可能已经在 GPT-5 的发布视频中见过你了,你当时演示了一个非常有趣的应用程序,现场即时构建了一个应用来教你的伴侣说法语。强烈建议大家去看看那个视频。

扬·杜布瓦: 确实,那次非常有趣。当时的 GPT-5 还没那么稳定,所以我有点担心它会失效。但最终并没有翻车。

主持人马特·特克: 所以那真的是现场直播?虽然可能排练过很多次,但确实是实时的。

2026 年的推理:现实世界的实用性与可验证的奖励

扬·杜布瓦: 实际上,就在我们直播前最后一次排练时,它失效了。所以我当时真的有点紧张,但好在现场直播时一切都很顺利。

主持人马特·特克: 毫无压力嘛!不过那一幕呈现得非常完美。太酷了。

好了,让我们来拆解一下开场时提到的一些内容。我们一直在讨论推理(Reasoning),我很好奇在 2026 年,“推理”的含义与我们过去讨论 o1 或 o3 时有什么不同?

特别值得一提的是,5.5 版本的一个核心卖点,同时也是我作为用户的切身体验,是它在处理杂乱数据时表现得极为出色,这似乎意味着它需要通过更强的逻辑来理清歧义。这期间究竟发生了什么变化?

扬·杜布瓦: 我想说的是,o1 和 o1 preview 在研究界确实是一个重大突破,它们让模型具备了思考能力。它们思考的时间越长,得出正确答案的可能性就越高。这确实是一个创举。但最初,如果你查阅以前的博客文章,你主要会看到数学评估(math evals),以及类似

编程竞赛之类的测试,也就是那些非常容易判断对错的任务。这也暗示了我们当时训练这些模型的方式。回顾去年全年,尤其是去年年底到今年年初,我认为最大的变化在于:我们能够将这些基于验证性奖励(verified rewards)——也就是能明确判断对错的算法——应用到纷繁复杂的现实世界中,并真正针对用户的实际效用进行优化,从而大幅提升生产力。我认为这才是真正的变革所在。

主持人马特·特克: 明白,所以这主要归功于后训练(post-training)的强化学习部分。

扬·杜布瓦: 我想说还有另一个重要因素。首先,当你开发出一种新方法时,它往往是不够稳定、可靠性低,且难以产品化(productionize)的。但现在这方面已经有了极大的改善。

事实上,我们现在拥有了一个可以针对不同目标进行优化的工具。最初开发这个工具时,我们对现实世界做了很多简化的假设;而现在,我们正在逐步摒弃这些假设。

至少在后训练(post-training)阶段,我们能够针对实际的用户效用进行优化,确保这些模型能发挥真正的作用,也确保我们所关注的任务具有切实的意义。

这就是为什么当前的评估标准(evaluations)看起来更贴近现实。如果你看看 GPQA,或者 SWE-bench Pro 和 SWE-bench,这些测试基准比我们早期研发 o1 时关注的 Codeforces 或其他编程竞赛要真实得多。

GPT-5.5 Thinking 与 Pro:测试时计算(test-time compute)的扩展

主持人马特·特克: 还是关于推理的话题,5.5 Thinking 和 5.5 Pro 归根结底的区别是什么?仅仅是投入了更多的测试时计算(test-time compute)、更多的 Token,以及在解决问题上花费了更多时间吗?

扬·杜布瓦: 基本上,这取决于我们在模型或发布的整个系统中投入了多少测试时计算(test-time compute)。我们反复验证了一个定律:模型思考的时间越长,输出的答案就越优质。但问题在于,我们所讨论的性能增长曲线绝不是线性的,它们存在一定的平台效应(plateauing effect),在某种意义上呈对数增长趋势,具体取决于不同的评估标准。

你可能投入了两倍的算力,但实际上只获得了微小的性能提升。我个人不太常用 Pro 版本,因为我非常没有耐心,真的不喜欢等那么久。虽然我知道它输出正确答案的概率绝对会提升,但这种提升幅度还不足以吸引我去使用它。

推理模型如何变得更加高效

但确实有一些用户非常喜欢 Pro 版本,尤其是在学术研究领域。我知道很多数学家都在使用它,因为他们可以让模型在后台运行一两个小时,由于不需要与模型进行快速的交互迭代,Pro 版本对这种场景来说简直是完美的。

主持人马特·特克: 我想将这一点与你之前提到的“每个 Token 的效率”结合起来理解。你的意思是,模型不仅能思考得更久,而且思考得更高效,从而更好地完成任务吗?时间维度和效率维度具体是如何相互作用的?

扬·杜布瓦: 如果你回想我刚才提到的图表,横轴是延迟(latency),纵轴是性能(performance)。当我们谈论提高效率时,本质上是将这条曲线不断向左推移。这意味着我们变得更加高效,也就是用更少的时间实现了同等的性能。

而“Pro”版本的作用在于延伸了这条曲线。它意味着随着模型思考的时间大幅增加,它得出正确答案的概率也会随之拔高。此外,每一次迭代的“Pro”模型同样会将曲线向左推移,这意味着随着时间的推移,它也会变得越来越高效。

关键在于,总会有那么一些任务,你唯一的诉求就是将正确率最大化,而完全不在乎延迟。比如,如果我在睡觉前跑一个任务,模型有足足八个小时的时间,那它就应该尽可能地去深度思考。这正是“Pro”版本赋予你的能力。

主持人马特·特克: 用通俗的话来说,这在实际应用中意味着什么?或者说它是如何运作的?如果模型发现自己走错了方向,它会提前打断自己吗?这也是衡量维度之一吗?

扬·杜布瓦: 这里面包含两件事。你是在问关于效率的问题吗?具体是指什么?

主持人马特·特克: 主要是关于效率,我很好奇推理能力究竟是如何变得更加强大的。

扬·杜布瓦: 这是一个好问题。让我从人类的视角打个比方:如果把某个领域的专家和刚入门的本科生做个对比,完成同一项任务,学生可能需要花上一两天的时间。因为他们从未遇到过这种特定问题,不得不反复推演各种可能性并进行大量探索。相比之下,该领域的专家通常能一针见血地找到正确的方向,他们不会把时间浪费在试错十条不同的路径上,因为他们凭经验就知道哪条路最可能通向正确答案。

这就是我们所说的效率提升。本质上,它是我们在针对现实问题对模型进行优化。因此,模型被训练出一种能力:能够以更高的准确率,精准预判哪些推理路径最有可能得出正确结果。

除了这种核心效率之外,确实也包括你刚才提到的情况:模型能感知到自己是否误入歧途。这种能力是可以通过强化学习(reinforcement learning)来训练的——让模型学会识别某条路径是否徒劳无功,从而及时回溯(backtrack)并尝试其他方案。如果你对模型的训练不够充分,它可能需要耗费漫长的时间才会恍然大悟自己走错了路。

预训练扩展(Pre-training scaling)与突破数据壁垒(data wall)

主持人马特·特克: 看来这很大程度上都要归功于强化学习和后训练(post-training)。那么,让我们来聊聊现代 AI 系统的不同组件是如何协同工作的。

我们可以探讨一下预训练(pre-training)、中期训练(mid-training)和后训练(post-training),鉴于后训练如此关键,我们可以在这上面多花点时间。先从宏观层面的预训练说起,我知道你可能不方便透露具体的操作细节,或者 GPT-5.5 开发过程中的具体内幕。但去年的一个主流论调是:预训练已经撞到了“天花板”,很难再取得什么实质性的进展。

但到了 2026 年,情况似乎完全出乎意料。你能为我们梳理一下目前预训练领域究竟发生了什么,以及为什么它现在的进展速度远远打破了人们去年的悲观预测吗?

扬·杜布瓦: 关于预训练(Pre-training),除了团队一直在做大量出色的工作,且我们的模型变得越来越好之外,我无法透露太多内部细节。但当谈到效率时,有一点我特别想强调:如果模型规模更大,其“思考时间”(即为了思考而生成的 token 数量)通常会减少。你可以这样理解:

打个比方,模型在生成某个 token 时,其实已经通过自身的权重进行过“思考”了。因此,只要增加所训练模型的规模,就能减少它在思考时需要生成的 token 数量。通常情况下,只要单纯地增大模型规模——即预训练更大的模型——就能获得更高的效率。

大模型的好处在于,它们在推理阶段(Inference)能更好地实现并行化。你可能以为,由于大模型生成的 token 变少了,会导致系统整体效率下降,但这并非事实。模型越大,你在 GPU 上优化推理的空间就越大。因此,你反而能让整个系统变得更高效。大模型实际上能带来极高的效率。

就预训练而言,我认为现在的局势非常有趣。大约两年前,我还以为预训练已经碰壁了。然而,看看 Anthropic 的模型等案例,从成本上就可以明显看出它们的规模要大得多。——通常你可以通过每个 token 的成本来判断模型是否变大了——这表明,仅仅通过增加模型规模,它们就能获得极其出色的性能。我认为这个领域至少有一部分人对此感到惊讶。此前有很多关于撞上“数据墙(Data Wall)”的讨论,但现在看来,我们并没有真正撞上这堵墙。模型越大,训练时需要吸收的数据就越多,而各家公司似乎都找到了各自的方法,来克服互联网数据有限的困境。

多模态数据、合成数据与具身智能

主持人马特·特克: 数据领域的下一个前沿,或者说当前的前沿,是多模态数据(Multimodal Data)吗?还是合成数据(Synthetic Data)?

扬·杜布瓦: 我认为在数据受限的环境下,合成数据可能会非常有效。多模态是一个很有趣的方向。我绝对不能透露我们内部的具体做法,但我早年曾从事多模态表征学习(Multimodal Representation Learning),我一直认为,拥有大量多模态数据会极大地提升模型的推理能力。

至今我依然这么认为。但举个例子,如果你看看 Anthropic 的模型,它们在多模态任务上的表现往往没那么出众,却依然非常聪明。因此,多模态似乎并没有我过去想象的那么不可或缺。

我始终坚信,一旦我们迈向具身智能体(Embodied Agents)和具身人工智能(Embodied AI),我们将能极大地加深对这个世界的理解。通过学习世界是如何自我交互的,我们将提升通用智能,并为用户带来更大的实用价值。

不过,至少从 Anthropic 的模型来看,它们似乎并不需要那么多的多模态数据,就能训练出非常强大的模型。

主持人马特·特克: 你提到的“具身智能”,潜在的意思是指机器人技术(Robotics)吗?也就是说,如果我们用视频来展示重力是如何运作的,以及机器人是如何在物理空间中活动的,这大概会更有用。是这个思路吗?

扬·杜布瓦: 是的。我觉得很多人都有这种直觉,我自己也长期抱有这种看法:仅仅通过文本是很难真正理解这个世界的。 如果不亲眼去观察,你很难理解物理学到底是什么。比如,如果不亲眼看着物体掉落,你根本无法真正理解重力。

看看我们现在的模型,它们似乎在没见过物体掉落的情况下也懂得了重力,但这依然让人觉得不够直观。感觉上,如果亲眼所见,它们本可以理解得更深刻;目前它们似乎仍缺失了一些常识层面的认知。因此,我确实觉得,让模型在真实世界中进行交互,能有效提升它们的常识水平。 但我认为我们距离实现这一点还有很长的路要走。我说的“我们”,泛指整个学术界和 AI 社区。

主持人马特·特克: 是的。既然聊到这个话题,我们稍微岔开一下,这就引出了“世界模型(World Models)”的概念。暂且摘下你作为 OpenAI 员工的帽子,你个人看好世界模型吗?

扬·杜布瓦: 所谓世界模型,如果是指试图去复制或模拟事物,本质上就是在模拟环境(Simulated Environment)中工作。问题在于,模拟永远充满了挑战,并且永远无法做到百分之百还原真实。因此,我相信始终需要在真实世界中进行一定程度的训练,以确保模型能够识别出模拟世界与真实世界之间的偏差。

我认为,作为整个领域,我们有一种倾向:总是在那些不完全真实的模拟或系统上过度优化,甚至越过了其实用性的临界点。我们花费大量的时间和精力去优化一个不够真实的东西;虽然在初期效果很好,但到了某个阶段,一旦你对其进行过度优化,它就再也代表不了真实世界了。

人们往往只是因为习惯了这么做就一直持续下去。我认为研究人员需要意识到何时应该适可而止。我不太经常接触……

揭秘中训练与后训练

……我不太经常接触这类合成环境,或许仅仅是因为我不从事具身 AI 方面的研究。所以我也不确定我们是否已经到了(过度优化)那个阶段。

主持人马特·特克: 好的,太棒了。那么,回到预训练(Pre-training)、中训练(Mid-training)和后训练(Post-training)的话题上来。我们来聊聊中训练。这个概念大家可能听得相对少一些,这个词出现的频率也不高。它到底是什么?为什么它很重要?

扬·杜布瓦: 顾名思义,中训练(Mid-training)就是指介于预训练和管线(Pipeline)中后训练之间的一个阶段。其核心理念在于:如果你拥有能更好地代表最终模型预期表现的高质量数据,你就应该在这些数据上进行过拟合(Overtrain/加强训练)。

我们先退一步讲,什么是预训练?预训练本质上就是试图从网络(Web)上学习一切知识。也就是在宏观层面上从互联网学习海量信息。但问题在于,互联网上的大部分内容并不真正有用。比如,你拿维基百科或者 GitHub(主要包含代码数据)来比较,里面的信息量显然比一些乌七八糟的论坛要大得多。

是的,某些杂乱的论坛可能没那么多有价值的信息;再比如广告,互联网上充斥着大量广告,你肯定不想在这些数据上训练太多。但在预训练阶段,我们是在所有数据上进行全量训练的。而到了中训练阶段,我们基本上会为这些我们认为对训练最终模型更有用的高质量数据赋予更高的权重(Overweight)。虽然我无法透露各家公司内部的具体情况,但这绝对是目前整个学术界都在探索的方向,而且所有开源模型也都已经引入了中训练这一阶段。

主持人马特·特克: 很好。我们先从宏观层面来定义一下“训练后阶段”(Post-training)。除了强化学习(Reinforcement Learning)之外,训练后阶段还包含哪些内容?

扬·杜布瓦: 这在很大程度上取决于你如何定义这个术语以及如何界定其边界。在我看来,从广义上讲,训练后阶段——包括所有的强化学习以及针对推理模型的训练——本质上就是将一个“通晓世界万物”的模型,转化为对人类真正有用的工具的过程。

我喜欢用一个比喻来解释:预训练(Pre-training)就像走进一座图书馆,里面包罗万象,理论上你能找到任何想要的信息。但相比之下,直接与一位读过所有这些书的专家交谈显然更有效——你可以向他提问,他能直接给出解答,并且真正理解你的核心诉求。

宏观来看,这正是训练后阶段的目标:打造一个对用户真正有用、更易于交互的系统。

这个过程包含多个阶段。我仅讨论 OpenAI 体系之外的行业通用做法。通常,首先会进行有监督微调(Supervised Fine-Tuning, SFT)。

主持人马特·特克: 也就是微调(Fine-tuning)。

扬·杜布瓦: 有监督微调是大多数早期模型主要采用的方法。其核心思想是,只要人类提供了期望的最终答案(即“黄金标准答案”),你就可以有效地克隆人类行为。这种方法被称为行为克隆(Behavior Cloning)。

然而,这种方法的局限在于,模型的表现永远无法超越所提供的真实标签(Ground Truth)。由于人类自身存在诸多局限,模型的表现永远无法突破那些为你提供数据的人类标注者(Human Labelers)的能力天花板。

强化学习阶段则超越了行为克隆,转向了奖励优化(Optimizing Rewards)。在这个过程中,即使不知道完美的“标准答案”是什么,你也可以建立一套评估标准,来判断答案是否正确或合乎预期。通过让模型尝试最大化这一奖励函数(Reward Function),模型就有可能突破人类导师的能力边界。

在强化学习内部,具体方法因训练模型而异。在开源社区中,主要有几种不同的路径。一种是基于可验证奖励(Verifiable Rewards)的强化学习,在这种情况下,很容易判断答案是否正确,通常会产生二元奖励(Binary Reward)。这与 o1 和 o1-preview 等模型的工作机制有关。

另一种是没有可验证奖励的强化学习。在这种场景下,你可能会通过成对比较(Pairwise Comparisons)来判断一个答案是否优于另一个,即使你无法明确地将某一个回答标记为绝对完美的答案。

当然,这中间存在一个连续的过渡带,包含了各种变体,但我认为在思考一般意义上的训练后阶段时,这三点是宏观层面的主要考量维度。

在开源领域,人们通常先从监督微调(SFT)起步,以克隆从互联网或人类收集来的行为模式。当模型达到相当不错的水平后,再引入强化学习来突破现有的能力瓶颈。

这种循序渐进的方法是必要的,因为直接从强化学习入手效率极低。强化学习的难点在于,模型本质上必须“误打误撞”地摸索出正确答案。

由于强化学习的机制是对模型进行多次采样,奖励正确的输出并惩罚错误的输出,你必须足够幸运才能碰巧命中正确的解决方案。因此,先通过行为克隆尽可能逼近最佳性能,然后再应用强化学习,效果会好得多。

强化学习是否创造了 AI 的新能力?

主持人马特·特克: 强化学习究竟是创造了新的能力,还是仅仅让模型在已有能力上表现得更好?

扬·杜布瓦: 这个问题真的很难回答。因为当模型在涵盖整个互联网的数据上进行预训练时,按理说它已经具备了所有的潜在能力。所以从科学的角度严谨回答这个问题极其困难,因为可以说所有知识都已经储存在那里了。

我想说的是,如果你对比两年前开源领域训练的模型——例如我参与过的 Alpaca 模型,当时我们用了 50,000 条示例进行监督微调(SFT)——你会发现一个明显的范式转变。现在,当你观察 Kimi 或 DeepSeek 等模型的强化学习阶段,它们使用的数据量似乎已经接近 1,000,000 条。显然,业界已经大幅扩张了强化学习阶段的规模(Scaling)。

由此可见,它们似乎确实学到了新的能力,比如推理(Reasoning)能力:即模型能够检查自己的答案并尝试改进。它真的可以进行更长时间的深度思考,以得出更准确的回答。所以我想说的是,按理说所有知识都已经存在于预训练中,但在过去一年半的时间里,即使在开源领域,通过强化学习,我们确实激发出比以往更强大的模型能力。

扩展强化学习(Scaling RL)的挑战与前沿

主持人马特·特克: 我多次听说强化学习非常棘手(finicky)且难以扩展(scale)。这也是为什么我们整个行业在最初的大语言模型(LLM)发展曲线上没有将强化学习纳入其中的部分原因——正是因为它太难奏效了。扩展强化学习的难点究竟在哪里?是数据集的问题,是难以确定奖励在哪里的问题,还是其他原因?

扬·杜布瓦: 我想说,直到两年前,大多数在学术界或研究界不从事强化学习的人,可能都认为强化学习根本行不通,或者操作起来太“娇气”、太难调参了。我曾经也是这么想的。

事实上,当 ChatGPT 发布时,他们发了一篇博客声明使用了强化学习。我当时的第一反应是:“不用强化学习我也能做到同样的效果,这完全是把简单问题复杂化了。”这正是我们启动 Alpaca 项目的初衷——尝试仅通过监督微调(SFT)进行行为克隆来复现那种效果。杨立昆(Yann LeCun)曾用过一个著名的比喻,说强化学习只是“蛋糕上的樱桃(锦上添花)”。我认为这确实代表了当时大多数人的直觉。

但现在看来,在跨越了一定的规模阈值——即模型已经知晓世界万物并具备所谓的良好先验知识(Priors)之后——强化学习终于开始发挥巨大威力。这不仅适用于大语言模型(LLMs),机器人领域似乎也进入了同一发展阶段。研究人员意识到,虽然过去强化学习非常棘手,但现在由于我们在基于已经掌握世界规律的模型上进行训练,它的学习效果其实相当惊人。

回到你关于强化学习目前仍有哪些难点的问题,一方面是基础设施(Infrastructure)。与常规系统一样,从宏观层面看,强化学习需要你采样大量答案并判断对错。这种采样成本极其高昂,且必须在大规模下进行。目前开源领域面临的另一个难题是……

当我们训练更具自主性的智能体系统(Agentic Systems)时,你只有在漫长的序列执行(Rollout)结束时,才知道最终结果是否正确。因此,对于每一个词元(Token),你很难获得有关具体操作正确与否的有效反馈。

此外,进行归因(Attribution)也非常困难。你很难辨别出整个长篇回答中究竟是哪一个具体环节导致了最终的正确结果。这构成了机器学习领域的一个重大挑战。

在理想的机器学习场景中,我应该能够精准定位哪个动作是成功的并对其进行强化。然而,智能体系统与强化学习面临的核心痛点在于,在得出最终结果之前,你根本不知道究竟是哪些中间步骤发挥了作用。这是强化学习面临的另一个重大难题。

主持人马特·特克: 强化学习(Reinforcement Learning)目前的前沿进展是什么?现在感觉就像走进了一个让人眼花缭乱的缩写丛林,比如 GRPO 以及其他各种技术。你们目前在使用什么?哪些技术让你感到兴奋?你认为哪些方向最有前景?

扬·杜布瓦: 我可以谈谈我们目前正在使用的技术。例如在开源领域,GRPO 的表现似乎就非常亮眼。过去人们经常使用 PPO 和 DPO 等不同方法,但现在大家似乎都殊途同归,向这一种方法靠拢了。

构建 AI 模型是一门手艺还是一门严谨的科学?

这种方法与其他方法最大的区别在于,它依然采用了我之前提到的那种简单直接的方式:尽可能多地采样答案,然后判断哪个是正确的。从某种程度上说,GRPO 是一种极其极简的方法。我们在机器学习领域一次又一次地见证了一个真理:最简单且能随着算力规模法则(Scaling Law)不断扩展的方法,往往就是最终效果最好的方法。 至少在开源领域,这正是目前正在发生的事实。

主持人马特·特克: 听你描述这些挑战时,我脑海中闪过一个问题。人们常说,AI 系统不是“被制造(built)”出来的,而是“生长(grown)”出来的。你会这样形容吗?在你的日常工作中,多少成分是严谨的科学,多少成分是手艺活——也就是不断试错,然后留下最有效的方法?

扬·杜布瓦: 这是一个非常好的问题。我认为通常的演进过程是:一开始往往是手艺活。大家就是不断尝试各种方法,然后逐渐建立起一套心智模型(Mental Model),知道哪些行得通、哪些行不通。随着时间推移,我们开始从“手工艺阶段”向“科学阶段”迈进。科学,或者说更科学的方法,才是最终让系统真正稳健运转的关键。然而这很难,极少有人能一开始就拿着一套绝对科学的方法说:

“这就是最优解”,然后照做就成功了。实际上,人们往往带有某种类似“炼金术(Alchemy)”般的直觉,凭借对事物的敏锐嗅觉,硬是把它做成了。

之后,这个人或是其他研究人员才会开始用非常科学的手段,来系统性地改进我们已经做出的成果。可以说,这一幕在机器学习领域一次又一次地重演:先有手艺,后有科学。两者都至关重要,只是代表了研发流水线上不同的阶段。

从工程角度来看,这种能力绝对是不可或缺的。所以,我想说大多数研究人员已经转变为了……我不敢说他们都是顶尖的工程师,但他们至少非常擅长在复杂的系统中游刃有余,并清楚地知道自己需要去试错什么。我们所使用的系统和基础设施(Infrastructure)正变得越来越复杂。因此,随着时间的推移,我们需要完成的工作性质已经发生了巨大的变化。

主持人马特·特克: 太有启发了。那么,让我们继续留在强化学习的话题上,并回到你开头提到的一些观点。如果我想让我的模型在计算机操作(Computer Use)、代码生成(Code Generation)或任何其他特定领域表现得更好,我是不是应该花大量时间,专门针对这个领域做强化学习,构建数据集,然后设计奖励函数(Reward Function)?是这样运作的吗?就是单拎出一个问题,然后专门为它做强化学习?

扬·杜布瓦: 需要澄清的是,我之所以更多地谈论强化学习,主要是因为这是我最熟悉的领域,也是我长期以来一直在推动的工作。我们之前提到过中期训练(Mid-training)。其实流水线上的所有环节都极其重要,你可以在不同阶段对模型进行优化。正如我刚才所说,你越靠近模型训练的最终阶段,训练的规模通常就越小。

由于训练规模较小,这就允许我们进行快速迭代,让开发者以“天”而不是“月”为单位来更新模型。通常的做法是,大家会先在这个阶段跑通快速迭代的闭环,然后再向更深层挖掘,在整个技术栈上做更伤筋动骨的重大调整。

这绝不是说只有强化学习最重要——我完全没有这个意思。但这解释了为什么大家总是从这些较小的改动着手,随着探索的深入,这些改动最终会渗透到系统的底层。这就是研发的实际运作逻辑,开源世界里更是如此。

我想你会发现,市面上涌现的后训练(Post-training)模型,远远多于全新的预训练基座模型(Pre-trained Base Models)。你也会看到算法层面的改进呈井喷式增长,这就是为什么大家都在热烈讨论 GRPO、DPO、PPO 以及形形色色的各种“XPO”。根本原因就在于,人们能够在这个流水线的最终阶段实现极速的迭代。

主持人马特·特克: 那么,这些模型表现出那种参差不齐的能力边界(Jagged Nature),是不是正是源于这种“头痛医头、脚痛医脚”式的挑问题优化方式?也就是说,因为它针对这些特定问题做了优化,所以表现极为出色,而在其他问题上就相形见绌?还是说,这本身就是 AI 模型更底层的根本特性?

扬·杜布瓦: 肯定有这方面的原因。毋庸置疑,你在某类特定问题上投入的优化越多,模型在这个场景下的表现就越拔尖。

但至少凭我的直觉来看,关键不在于你到底优化了哪一个具体问题,而在于你优化的是哪一个“问题类别(Class of Problems)”。举个例子,如果你的模型在数学竞赛中大杀四方,那么它在编程竞赛中的表现多半也不会差。所以,这并不是“领域”壁垒的问题,而更关乎底层所需的技能、思维方式,以及执行这些任务所需的横向通用能力(Horizontal Capabilities)。

AI 模型如何实现跨领域泛化

这正是我认为大家经常观察到的现象:当一个模型在某项任务上表现很糟时,它其实是在任何领域、任何语言下的这项任务中都很糟。因此,在思考这个问题时,你必须把视野从“特定领域”拉高到“跨领域的泛化(Generalization)”,而不是仅仅死盯着单一领域的垂直能力。

主持人马特·特克: 既然聊到了泛化,我们看到了一条非常清晰的演进主线:模型从最初在数学和编程上的成功,到现在已经开始向各个不同的领域开疆拓土。这就是推动国民生产总值(GDP)增长的核心价值主张——也就是整个经济体的各个领域,都在用模型的表现来进行重新评估。

现在的问题是:这种百花齐放的局面,究竟是模型整体能力进化的自然结果,还是我们刻意为之的产物——比如我们专门挑出经济体中的某个特定切面,为它量身定制数据集,然后进行中期训练和后训练?

这种从极度垂直的特定领域,走向惠及整个现实世界的泛化过程,到底是如何发生的?

扬·杜布瓦: 这绝对是我们正在积极推动的事情。我认为大家——不管是我们还是其他公司——都越来越清醒地认识到:我们正在大步迈向一个全新的世界,在这个世界里,我们真正渴望打造出极具实用价值的产品,去大幅提升人类生产力,去切实改善人们的日常生活。

因此,我认为行业内正在采取极其主动的策略,来决定我们应该优先攻克哪些领域。既然我们已经掌握了能够放之四海而皆准的算法,那么现在的瓶颈就不在算法本身了,而在于如何收集到正确的高质量数据,以及如何找到那些真正对某个领域痛点充满热情的人,让他们投入到这个问题的解决中去。

然而,既懂技术又懂业务的复合型顶尖人才依然凤毛麟角,所以你必须严格排好优先级。这完全是一种非常主动的战略布局。

总而言之,我想说:模型最终的表现,很大程度上取决于到底有多少人真正在乎它的输出结果,并愿意夜以继日地去死磕、去审视这个模型。 如果大家开始把火力集中在某些特定的垂直领域,这些领域的模型能力绝对会一日千里。但话说回来,我们手头确实还没有那么多能挑起这个重担的人才。

主持人马特·特克: 顺着你刚才提到的一点展开来说,现在的模型是否真的具备了更强的泛化能力(Generalization)?特别是在强化学习(Reinforcement Learning)的视角下,如果我们将一个模型在A领域或B领域训练得极其出色,那么即使我们在C领域的奖励机制上投入甚少,它是不是也有可能在C领域表现得更好?

扬·杜布瓦: 我认为泛化(Generalization)可以分为不同的维度。首先是算法层面的泛化,这主要是指我能否将在A领域开发的算法或“黑盒”直接应用到B领域。

至少从开源社区的情况来看,大家似乎已经做到了这一点。他们采用 GRPO(组相对策略优化,Group Relative Policy Optimization),将其应用到各种不同的场景中,结果直接奏效。这种泛化能力似乎相当不错,这也是为什么我们能看到如此多的技术进展;否则,行业很难大步向前。

其次是基于特定数据集训练出的模型的泛化。这就是我之前提到的情况。至少在我的认知模型里,只要底层能力范畴保持一致,泛化就会自然发生。

你会看到跨领域的泛化。比如在不同的编程语言之间,如果你专门针对C语言进行优化,只需极少量的训练,就能得到一个优秀的C语言模型。这在一定程度上是因为预训练模型已经“阅尽”了C语言代码,它已经掌握了这门语言的基础。这种泛化是确切存在的。

但我认为,当我们缺乏这种“横向能力(Horizontal Capabilities)”时,泛化就会变得极其困难。我举个具体的例子:如果我的模型在应对竞赛题时极其精准聪明——我经常用数学或编程竞赛举例,因为它们的规则非常明确且受限——从人类的视角来看,擅长这些的人通常会被认为“很聪明”。

人们往往会觉得,既然他们这么聪明,那他们肯定也能胜任其他事情。但这未必成立,这种跨领域的泛化是无法保证的。

在许多需要人类专家的领域中,情况大不相同。真实世界是极其复杂混乱的,而编程和数学竞赛的规则却极其清晰明确。模型需要具备一种能力,去理解那些定义模糊的任务,懂得如何应对这个混乱的世界,并且知道:解答一个问题到底需要调用哪些资源?你看数学竞赛,提示词(Prompt)里通常已经给出了所有前置条件,可能就5到15行字,却包含了破题所需的一切信息。

然而在现实世界中,假设我是一名顾问或金融从业者,我必须去网上检索。在进行任何逻辑推理之前,我得先大海捞针般地提取各种信息来构建上下文背景——这仅仅是拿到了进行推理的“入场券”而已。

这种横向能力一旦具备,通常就能实现很好的泛化。遗憾的是,在很多情况下,我们的模型并不具备这种横向能力。

强化学习如何治愈AI幻觉

所以,这就是为什么模型在任何领域都会产生幻觉(Hallucination)。对于语言模型(LLMs)的幻觉来说,如果一个模型不懂得承认“我不知道”,这种缺陷通常会贯穿所有领域。你绝不会看到这样一个模型:它在某个领域对自身知识边界的校准(Calibrated)极其精准,但在另一个领域却一塌糊涂。

主持人马特·特克: 顺便插一句,幻觉是否本质上也是一个强化学习问题?如果我们对模型说“我不知道”的行为给予奖励(Reward),是否就能解决幻觉问题?

扬·杜布瓦: John Schulman 在一两年前做过一次极其精彩的演讲,他在其中提出:如果你过度依赖行为克隆(Behavior Cloning)——本质上就是我们前面讨论的SFT(监督微调,Supervised Fine-Tuning)过程——你可能会在无意中对幻觉进行奖励和优化。

核心症结在于:如果你的模型原本对某个特定主题一无所知,但你却强行喂给它一个“无所不知”的基准答案(Ground-Truth),你实际上是在训练模型凭空捏造。说得更具体点:如果模型压根没读过某篇论文,但人类提供的标准答案里却煞有介事地引用了这篇论文,你就是在诱导模型去引用一个不存在的文献,因为它根本分不清真伪。

因此,Schulman的演讲表明,SFT实际上是在逼迫模型产生幻觉。相比之下,在强化学习中,由于模型在训练时是从自身的输出中进行采样(Sample),它极小概率会随机采样到一条它既不知道、同时又恰好符合客观事实的内容。

负面泛化与指令冲突

这几乎是不可能的。因此,你永远不会去奖励那种“不懂装懂”的行为。模型只会采样出它不知道且错误的内容,然后强化学习机制会直接扼杀(Kill)这种行为。所以,业界目前的直觉是:幻觉往往来源于SFT,或者来源于后训练(Post-Training)流水线中的某些环节。但如果你拥有一套足够优秀的强化学习流水线,幻觉就不应该频繁出现。

主持人马特·特克: 再回到泛化的问题上,有没有这样的例子:模型在某个领域变得越来越强,反而导致它在其他领域的表现变差了?这有点像你刚才说的,有些人极具数学天赋,有些人则极具语言天赋,但他们往往不是同一拨人。

扬·杜布瓦: 通常不会。真正的情况是,资源分配决定了优化方向。如果你倾注全力去优化某一个领域,你在其他领域能投入的优化力度自然就会减少。

所以,并非“优化A就一定会让B变差”。纯粹是因为算力瓶颈、数据稀缺,甚至是参与训练的人类专家自身的精力极限,导致你无法兼顾对B的优化。

但确实会发生一种现象,那就是负向泛化(Negative Generalization),或者叫负迁移(Negative Transfer)——这在模型的横向能力上体现得尤为明显。我给你举个非常具体的例子。

那就是“显式指令遵循”与“隐式指令遵循”的冲突。如果我有一个模型——我们经常听到关于 OpenAI 模型的这种评价——如果你事无巨细地告诉它你想要什么,它会表现得无比出色。但随之而来的代价是,一旦你的描述不够具体,它的表现就会大打折扣。打个比方,如果我在输入指令时敲错了一个字,比如让它修改某个文件但我把文件名拼错了,一个在“显式指令遵循”上做到极致的模型,会死心塌地去修改那个拼错的、错误的文件。

强化学习能否扩展到法律、医疗和更广泛的经济领域?

但如果换作人类,很大概率会意识到你只是打字口误(Typo)。因此,在某些场景下,这种绝对的“显式指令遵循”恰恰与“隐式指令遵循”背道而驰。这就是横向能力之间相互打架、自我消耗的典型案例。

主持人马特·特克: 作为这段关于强化学习讨论的收尾,你认为,当我们从精通编程和数学,逐步进军更广泛的经济领域时,其他经济领域的应用是一个可以攻克的问题(Tractable Problem)吗?你认为我们最终能在这些领域达到同样出色的性能水平吗?

扬·杜布瓦: 是的,我坚信可以。我不觉得这些特定领域存在什么不可逾越的护城河,能阻碍我们去优化它们,或是阻碍我们取得与编程、数学领域比肩的成果。

不过,这里有两个关键的限制因素需要注意。首先,目前开发这些大模型的人本身就是顶尖的编程高手,他们对写代码有着发自内心的热爱,因为那是他们每天都在用的工具。天下没有比“用户自己亲自训练模型”更完美的场景了,因为他们对痛点有着切肤之痛的理解。相比之下,如果我对法律一窍不通,我就很难去判断,到底该如何微调模型才能让它在法律领域的表现更上一层楼。

第二个原因,我刚才简单提过,就是关于“可验证的奖励(Verifiable Rewards)”。在某些领域,判断模型的输出对错非常容易。以你提到的网络安全为例,现在模型在网安领域的能力突飞猛进。这是因为在网络安全中,验证结果极度简单——你可以瞬间测试出它发现的安全漏洞到底是真是假。

归根结底,虽然在某些领域应用强化学习确实是捷径,但模型本身的基础能力并不存在任何内在的限制,

评估瓶颈与“模型即裁判”

来阻碍它们在法律、医疗等其他领域达到同样卓越的水平。简而言之:瓶颈仅仅在于我们对这些领域知之甚少。毫无疑问,某些领域天生就更容易使用强化学习来进行优化。

主持人马特·特克: 太好了。我们花点时间谈谈评估(evals)。这是一个极其重要的话题。首先,为什么评估一个模型从一开始就这么难?

扬·杜布瓦: 随着模型变得越来越强大,评估(evals)也变得越来越困难。这是因为我们要求模型完成的任务越来越通用,也越来越具开放性。

比如现在,我可能直接就说:“帮我建一个具备X功能的网站。”而在过去,我只会问:“这段代码实现中是否存在某个具体的bug?”找出bug要容易得多,因为我可以让人工提取并对所有已知问题进行优先级排序,然后自动应用修复。相比之下,对于“建网站”这类需求,由于实现方式多种多样,很难确定什么才是“最优”答案。模型这种开放式特质,让评估变得困难得多。

另一个问题是,在特定领域,模型的表现正在超越大多数人类。因此,能在这些特定领域有效评估模型的人类越来越少。这无疑是一个瓶颈。

老实说,这其中还有文化的因素。大多数人都想提升模型,并且认为实现这一目标的最佳途径就是训练。但实际上,发现问题并确保我们能量化这些改进也同样重要,甚至更为重要。然而,人们在这方面一直存在文化偏见。直到大约两年前,在学术界尤其如此,那里的评估、基准测试(benchmarks),甚至数据集(datasets)很大程度上都是固定不变的。

后来人们的观念发生了转变,终于意识到数据至关重要,现在许多人都在深耕数据。但我感觉,评估工作还没跟上步伐。每个人都知道评估很重要,但并未充分意识到在这方面发力能带来多大的影响力。当我在OpenAI开启第一个项目时,我特意选择了数据和评估,因为我知道没人在关注这一块,这也意味着它将极具影响力。风向正在转变,但速度还不够快。

主持人马特·特克: 那么,“模型作为裁判”(LLM-as-a-judge)以及AI评估AI,这方面的进展速度同样快吗?这是一个独立的研究领域,还是说本质上是相同的理念或技术?

扬·杜布瓦: 从根本上讲,这其实是同一种方法。毫无二致;我们在评估中所做的绝大部分工作,特别是现在有了强化学习(Reinforcement Learning)后,几乎可以原封不动地应用到训练过程中。

这也是评估如此复杂的另一个原因:每当你构建一个评估标准时,你实际上也是在构建一种创建训练数据集(training datasets)的方法。随后你就会针对这个训练数据集进行优化。即便不是针对那个特定的评估,也会是同类型的数据。由于模型具备能力泛化(generalization of capabilities)的特点,它会从这些数据中学习,从而在那个评估中表现得异常出色,于是这个评估标准很快就会失效过时。这是评估面临的一个重大问题。

回到你的问题,“模型作为裁判”(Model-as-a-Judge)的方法非常重要。我认为这可能是最关键的领域之一,因为随着我们开发出更强大的模型,我们正在构建一个自我强化的循环——一个能力飞轮(capability flywheel),让更好的模型成为其他模型的卓越导师

这对于训练至关重要,但你也可以将相同的原则应用于评估。我的团队里有很多人在从事这项工作,我相信关注“模型作为裁判”(Model-as-a-Judge)这一框架极为关键。

持续的AI进步与持续学习(Continual Learning)

主持人马特·特克: 好的,太棒了。在这次对话接近尾声时,我想把视角拉远一点,听听你对未来发展方向的看法。显然,预测AI未来几年的发展极其困难,但我们暂且说是未来的12、18甚至24个月。你觉得事物会继续稳步发展,还是我们正走向某种让人感觉像是“非连续性跃迁”(discontinuity)的阶段?

扬·杜布瓦: 就进步而言,正如我之前所说,我认为它始终是连续的。不过,确实会产生“非连续性跃迁”的体感。大概3或4个月前,在编程领域就发生过这样的情况。

我认为现在这种现象将发生在每一个其他领域。大多数人目前对我们的模型在编程和软件工程方面所展现出的能力和实用性感到震撼,但对其他领域还没有同感。所以,我认为这种冲击必然会渗透到许多其他垂直领域。

就我们目前关注的这些垂直领域的能力跃升而言,我认为它会更加连续,绝不会出现巨大的非连续性。大多数非连续性都是局部的,但当你拉远视角来看,它总显得相当平滑。虽然并非总是如此,但绝大多数情况都是这样。我确实无法预测下一次重大的非连续性跃迁会在何时到来。

主持人马特·特克: 你对AI领域中“加速循环”(accelerating loops)这个宏观概念有何看法?无论是通过持续学习(continual learning)让模型更具时效性且学得更快,还是更广泛的“AI构建AI”(AI building AI)概念——即以日益自动化的方式进行。这其中哪些是事实,哪些是幻想?你又对什么感到兴奋?

扬·杜布瓦: 我对持续学习(continual learning)感到非常兴奋。我认为我们还没有完全攻克它。我的意思是,虽然我们有像上下文记忆(context memories)这样的功能,这固然有帮助,但绝对不是终极形态。

我有个朋友经常提到一张我们应该关注的图表:X轴代表时间,Y轴代表为用户提供的效用(utility)。目前,大多数模型在“第零天”(Day Zero)——如果你直接把它们空投到一家公司——可以说是比大多数新员工更有用的。所以,它们在起点(T-zero)的效用更高;但随着时间推移,它们的效用基本保持不变,因为它们并没有真正学习公司特有的知识,也不会在任务中变得更高效。

相比之下,人类学得非常快。真正重要的是这些表现趋势曲线下的积分,即曲线下的面积。因此,我认为在许多情况下,人类依然更有用。所以,我们在持续学习方面要做的,就是让这条效用曲线随时间单调递增;简而言之,让模型在特定环境中工作的时间越长,就变得越来越有用。

我对此感到极度兴奋,说实话,我很惊讶我们至今还没实现这一点。3年前ChatGPT问世时,我和朋友们正在创业,当时我们就在考虑涉足持续学习、个性化以及记忆(memory)这些通用领域。我们当时觉得:“OpenAI肯定会在接下来的6个月内搞定这个;他们有海量数据、庞大用户群,完全有能力让这些模型实现超快学习。”然而,3年过去了,我认为我们依然没有达到那个高度。

主持人马特·特克: 那么,用通俗的话快速概括一下,其根本难点在哪里呢?

扬·杜布瓦: 好问题。实不相瞒,我其实也不太清楚。我不太明白为什么我们要花这么长时间才能搞清楚它。我认为,只要我们在这一领域投入足够多的资源,终究是能解决的。

当然,特别是当我们谈论公司内部的记忆时,会涉及到权限方面的大问题。同时,关于隐私保护,以及在模型和用户之间什么可以共享、什么不可以共享,也存在诸多争议。

基础模型会吞噬智能体框架(agent harness)吗?

遗憾的是,撇开公司层面不谈,即使只是针对单一用户,我们也还没完全实现这一点。所以就我能谈论的宏观层面而言,我真不知道原因何在。

主持人马特·特克: 你提到的这一点对于AI开发者、投资者和初创企业来说都非常关键,即模型在企业应用中正变得越来越智能这一议题。

特别值得注意的是,模型本身的能力与人们围绕模型所构建的外围系统之间,始终存在着一种博弈。一两年前,大家都在做 RAG(检索增强生成);而如今,焦点已完全转移到了智能体(Agent)的控制框架(Harness)上。

许多人都在好奇,模型最终是否会直接取代这些外围框架,还是说这些框架仅仅是过渡性的产物。从你的角度来看,未来会如何发展?

扬·杜布瓦: 我认为在现阶段,外围框架确实能显著提升模型的能力。鉴于我们正目睹模型能力极其快速的迭代,除非是为了实现当前某个非常具体的目标,否则我个人不会在外围框架上投入过多精力。

例如,专注于特定垂直领域的公司可能希望将可靠性从 80% 提升到 85%,而框架系统肯定能帮助他们实现这一目标。这非常有价值,但他们必须清楚,未来极有可能需要重新调整或重构这些框架。我认为这完全没问题;然而,如果你试图打造一个旨在长期通用的控制框架,我认为这是行不通的。

针对特定领域的框架是短期的必然需求,且其能发挥的上限终究是有限的。如果说有什么建议的话,那就是大家如果有明确要解决的具体问题,就应该投入更多精力去构建框架。因为如果缺乏优秀的控制框架,我们就是在白白浪费模型的巨大潜力。

可以说,如果我们冻结当前的模型版本,并全身心投入于构建强大的框架——或许结合这些框架进行更多训练——人们真的会在每一个垂直领域体验到通用人工智能(AGI)。但现实是,我们并未停止底层开发,而是会持续训练更先进的模型,因此我们目前无法预知最终的框架会是什么形态。框架的持续演进是历史的必然。

为什么初创公司应该关注AI的“最后一公里”

主持人马特·特克: 关于应用层面,也有类似的问题。刚才我们提到了你在不同垂直领域取得的进展,这不仅包括 GDBI Val 的整体进展,还包括针对电信行业、处理复杂客户服务工作流的 Tau to Bench Telecom。

此外,在金融智能体(Agent)方面也取得了突破,自动化了内部投资银行 88.5% 的建模任务,以及在 Office QA Pro 上完成了 51.1% 的任务。所以,你们正一步步接管越来越多的工作。

那么,你认为人们还有必要去构建应用程序吗?还是说,随着我们越来越接近 AGI,所有的这些应用最终都将直接成为模型原生能力的一部分?

扬·杜布瓦: 对于外部公司或初创企业来说,在特定垂直领域深耕仍有巨大的发展空间。我认为这方面的潜力是无限的。原因在于,许多人倾向于将所谓的“智能”(Intelligence)和模型的原始能力视为

真正的瓶颈——但我并不完全认同。真正的瓶颈往往在于“最后一公里”(The last mile)。这涉及到确保模型拥有正确的系统权限,并能够顺利接入必要的API和连接器。我们将继续专注于提升模型的通用基础能力。

我相信其他公司应该更专注于垂直领域,利用现有的技术创造出最大的价值。在不同垂直领域的“最后一公里”上,永远会有广阔的市场空间,我非常鼓励大家继续在这方面努力。

也许有一天,当通用大模型的横向演进(Horizontal progress)停滞时——尽管我认为这在短期内根本不会发生——我们才会开始关注这些垂直应用。但就目前而言,这并非我们的工作重心。

主持人马特·特克: 好的,至少对初创生态系统而言,这是一个非常乐观的收尾。非常感谢你,Yann。这次交流非常精彩,我受益匪浅。感谢你抽出时间与我们交流。太棒了,谢谢你。

参考资料: https://www.youtube.com/watch?v=DhD1zZ8w8Mw,公开发表于2026年05月21日

声明:此公号(ID:Fintech_Education)发布内容和图片的目的在于传播更多信息,版权归原作者所有,不为商业用途,如有侵犯,敬请作者与我们联系。
基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-05-26 11:35:47 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/669710.html
  2. 运行时间 : 0.121019s [ 吞吐率:8.26req/s ] 内存消耗:4,813.96kb 文件加载:145
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=351239b1d08999e1a473fd8f02ce7c61
  1. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/composer/autoload_static.php ( 6.05 KB )
  7. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/ralouphie/getallheaders/src/getallheaders.php ( 1.60 KB )
  10. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  11. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  12. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  13. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  14. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  15. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  16. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  17. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  18. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  19. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions_include.php ( 0.16 KB )
  21. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/guzzlehttp/guzzle/src/functions.php ( 5.54 KB )
  22. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  23. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  24. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  25. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/provider.php ( 0.19 KB )
  26. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  27. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  28. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  29. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/common.php ( 0.03 KB )
  30. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  32. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/alipay.php ( 3.59 KB )
  33. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  34. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/app.php ( 0.95 KB )
  35. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cache.php ( 0.78 KB )
  36. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/console.php ( 0.23 KB )
  37. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/cookie.php ( 0.56 KB )
  38. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/database.php ( 2.48 KB )
  39. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/filesystem.php ( 0.61 KB )
  40. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/lang.php ( 0.91 KB )
  41. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/log.php ( 1.35 KB )
  42. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/middleware.php ( 0.19 KB )
  43. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/route.php ( 1.89 KB )
  44. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/session.php ( 0.57 KB )
  45. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/trace.php ( 0.34 KB )
  46. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/config/view.php ( 0.82 KB )
  47. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/event.php ( 0.25 KB )
  48. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  49. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/service.php ( 0.13 KB )
  50. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/AppService.php ( 0.26 KB )
  51. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  52. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  53. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  54. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  55. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  56. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/services.php ( 0.14 KB )
  57. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  58. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  59. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  60. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  61. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  62. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  63. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  64. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  65. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  66. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  67. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  68. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  69. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  70. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  71. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  72. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  73. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  74. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  75. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  76. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  77. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  78. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  79. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  80. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  81. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  82. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  83. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  84. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  85. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  86. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  87. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/Request.php ( 0.09 KB )
  88. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  89. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/middleware.php ( 0.25 KB )
  90. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  91. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  92. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  93. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  94. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  95. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  96. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  97. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  98. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  99. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  100. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  101. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  102. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  103. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/route/app.php ( 3.94 KB )
  104. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  105. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  106. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Index.php ( 9.87 KB )
  108. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/BaseController.php ( 2.05 KB )
  109. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  110. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  111. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  112. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  113. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  114. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  115. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  116. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  117. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  118. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  119. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  120. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  121. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  122. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  123. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  124. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  125. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  126. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  127. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  128. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  129. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  130. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  131. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  132. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  133. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  134. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  135. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/app/controller/Es.php ( 3.30 KB )
  136. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  137. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  138. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  139. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  140. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  141. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  142. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  143. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  144. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/runtime/temp/c935550e3e8a3a4c27dd94e439343fdf.php ( 31.50 KB )
  145. /yingpanguazai/ssd/ssd1/www/wwww.yeyulingfeng.com/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000700s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000852s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000326s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000291s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000487s ]
  6. SELECT * FROM `set` [ RunTime:0.000202s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000565s ]
  8. SELECT * FROM `article` WHERE `id` = 669710 LIMIT 1 [ RunTime:0.000976s ]
  9. UPDATE `article` SET `lasttime` = 1779766547 WHERE `id` = 669710 [ RunTime:0.024018s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000437s ]
  11. SELECT * FROM `article` WHERE `id` < 669710 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000666s ]
  12. SELECT * FROM `article` WHERE `id` > 669710 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000397s ]
  13. SELECT * FROM `article` WHERE `id` < 669710 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.000922s ]
  14. SELECT * FROM `article` WHERE `id` < 669710 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.002852s ]
  15. SELECT * FROM `article` WHERE `id` < 669710 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.000886s ]
0.122686s