"Software engineering is not about writing code" — Benoit Schillings, Google DeepMind VP of Research

频道: AI Engineer
视频: https://www.youtube.com/watch?v=1P1hJ36rxM0
原文语言: en
统计: 共 11 轮 · Host 1 · Benoit 10

[0:01] Host

[music] Please welcome to the stage the vice president of research [music] at Google DeepMind, Benois Schillings. [music]

[音乐] 有请 Google DeepMind 研究副总裁 Benoit Schillings 上台。[音乐]

[0:30] Benoit

[music]

[音乐]

[0:49] Benoit

All right, good morning. Uh this is really quite exciting to be here and have a chance to to speak with all of you. Uh my name is Benois Shellings. I'm actually a bit of a noob when it comes to to machine learning. Till a year and a half ago, I was working for Google X which some of you may know. We've done things like Whimo, which seems to be at every street corner now. Uh we also do things like Glass. So, you know, we we had a mix of hit and success. But in many ways this was for me an interesting formative experience on how to run a research team in a place like deep mind. I do have an incredible team. Uh my team goal in deep mind is basically to develop whatever technology will be needed to make Gemini incredible between one months and one year from now. So one month because if you start to work on what is needed in one week that's a very different type of job and one year because I don't think anybody can really predict anything that far. So that's already pretty ambitious in my opinion to think about things that would happen one year in the future. We do many things under that role. Uh a lot of it is related to code which will be the main subject of my talk today. uh but we also do a lot of research on what is the evolution of reasoning for models for instance or we do topology research what are new type of network that might bring better performance uh we do fundamental work in the science of reinforcement learning which is so fundamental to what we're doing today with ML let's do a bit of an origin story Um, we started the project at X named Pitchfork uh in 2018 which was aimed at looking at how ML could really improve the way code is being written. And this was very interesting because in 2018 when we presented that at Google honestly nobody would give us the time of day. uh there was that point like why would you ever need ML to to write code. Um at the same time I think that we totally underestimated how fast this could go.

好的，早上好。能来到这里和大家交流，我真的非常兴奋。我叫 Benoit Schillings。说实话，在机器学习这个领域我算是个新人——直到一年半以前，我还在 Google X 工作，可能有些人听说过。我们做过 Waymo 这样的项目，现在似乎每个街角都能看到它了；我们也做过 Glass。所以你看，我们的项目有成有败。但从很多方面讲，这段经历对我来说是一次很有意义的历练，让我学会了如何在 DeepMind 这样的地方带研究团队。我的团队非常出色。我们在 DeepMind 的目标很简单：开发让 Gemini 在未来一个月到一年之内变得无比强大所需要的任何技术。为什么下限是一个月？因为如果你做的是一周内就要用上的东西，那是完全不同性质的工作；为什么上限是一年？因为我认为没有人能真正预测那么远的未来。在我看来，能思考一年后会发生什么，本身就已经相当有野心了。在这个使命下我们做很多事情。其中很大一部分和代码有关，这也是我今天演讲的主题。但我们同时也在研究模型 reasoning 能力的演进方向，做网络拓扑研究——探索什么样的新型网络结构能带来更好的性能——还有 reinforcement learning 的基础科学研究，这对我们今天做的机器学习来说至关重要。先讲讲起源故事吧。2018 年，我们在 X 启动了一个叫 Pitchfork 的项目，目标是研究机器学习如何真正改进代码的编写方式。有意思的是，2018 年我们在 Google 内部展示这个项目时，说实话根本没人搭理我们。当时大家的反应是：你为什么会需要用机器学习来写代码？但与此同时，我们也完全低估了这件事的发展速度。

[3:14] Benoit

When we did that project originally the idea was to look at how we could speed up the evolution of a piece of code. How could we make many of those small changes which slows down code speed development? you know the small edit which requires a review that takes three days and how we could compress that cycle. Some people were talking about vibe coding writing code in English and at the time honestly I totally dismissed that. I was that's why we have programming language. English is not a programming language. Well I I guess I was pretty wrong on that front. But the resistance we felt at the time reminded me of how my own career was pretty resistive to to change. Um I've been writing code for 45 years. Uh I started by writing video game for Apple 2 and Commodore 64. So uh my formation was to write assembly language. And when you spend a long time writing assembly language, you look at compilers with a lot of suspicion, right? are those things really working correctly? And then when you switch to C++ and use compiler, you lose you look at garbage collected languages as this h that's not real programming. You need to manage your memory. Well, today I use Python and V coding. So even old dogs can learn new tricks. So uh but I I I do understand what happened there. I think that we have a number of eras in what happened with software and and the first one was you know the one where I started writing code where the fundamental limit was really the machine and there was a lot of work to go and extract the last ounce of power out of those machine and that was the days of assembly language where you really needed to be incredibly accurate in the way you were writing code computing became much cheaper and we switched to the modern cloud era where getting the best performance is not the most critical aspect. You can actually brute force many problems but really what became the limiting factor was the ability for us to design in a modular way. You know this was the era where software was write it only once and this was this whole idea of how are you going to build libraries? How are you going to write functions? How are you going to break down that problem into something that is long-term manageable?

我们最初做那个项目时，想法是研究如何加快一段代码的演进速度。那些拖慢开发节奏的小改动——比如一个小小的修改却要等三天才能通过 review——我们怎么把这个循环压缩掉？当时有人在谈 vibe coding，用英语写代码，说实话我当时完全不屑一顾。我的想法是：我们有编程语言就是为了这个，英语可不是编程语言。好吧，看来我在这一点上错得离谱。但当时我们感受到的那种阻力，让我想起我自己的职业生涯也曾经很抗拒变化。我写代码已经 45 年了。我最早是给 Apple II 和 Commodore 64 写游戏的，所以我的科班出身是写汇编语言。当你写了很久汇编之后，你看编译器的眼神是充满怀疑的——这些玩意儿真的能编译对吗？然后当你转向 C++、开始用编译器之后，你又会看不起带垃圾回收的语言：哼，那不是真正的编程，程序员应该自己管理内存。而今天呢？我用 Python，还用 vibe coding。所以老狗也能学会新把戏。不过我确实理解这背后发生了什么。我认为软件的发展经历了几个时代。第一个时代，也就是我开始写代码的那个时代，根本的限制在于机器本身。你要花大量的功夫去榨干机器的每一分算力，那是汇编语言的年代，写代码必须极其精确。后来计算变得便宜多了，我们进入了现代云计算时代，追求极致性能不再是最关键的事——很多问题你可以直接靠算力硬解。真正成为瓶颈的，是我们进行模块化设计的能力。那是一个软件『只写一次』的时代，核心问题变成了：你怎么构建库？怎么写函数？怎么把问题拆解成长期可维护的结构？

[5:47] Benoit

The limitation there and that determine a lot of how our software process are working where actually the human brain. Uh a traditional human typical human is able to get the context between seven and nine tokens. I mean we have very rich tokens but you compare that to modern ML where the context is basically going to be infinite pretty soon. uh that fundamental limitation of human determined a lot of how software was being written. This is over and we're switching now to that AI frontier where really writing the code is not the challenge anymore. Uh I'll speak some more about it. But the bottlenecks are really how do you ensure that that code is what you really wanted because writing the code is easy but getting what is needed for a specific problem can be much harder to to specify. So humans at least in the near future will be that role of architecture or thinking of what are really the implication of that piece of code. I'm getting the ML to to design. Inductive thinking is another category where I think humans still have a very clear edge which is to look at a system in a much wider context and to be able to detect patterns and from those pattern take some decision. So where are we today? Um, superhuman syntax generation. When is the last time I got Gemini to write a function for me? And I looked at the function and I was like, I can do that better. It's over. Uh, I think that the minutia of code writing, I mean, you can fight, you can argue, you can find counter example, but that time is is gone. Where we still have a lot of work to do is multi-step code base. Uh software engineering is not about writing code. Software engineering is the first time you join a company and you realize that there are 35 million lines of PHP in the codebase and that you need to make some changes. That that's the day you understand what software engineering is and that's a place where our models today or frontier models are progressing. But this ability to manage that extreme complexity and break it down into man manageable pieces is a place where the frontier is still moving.

而那个时代的限制因素——它在很大程度上决定了我们今天的软件流程——其实是人类的大脑。一个普通人的工作记忆大约只能装下七到九个 token。当然，人类的 token 信息量很丰富，但对比一下现代机器学习：模型的 context 很快就基本上是无限的了。人类这个根本性的局限，塑造了过去软件的写法。这个时代结束了，我们正在切换到 AI 前沿时代——在这个时代，写代码本身已经不再是挑战。这一点我后面还会展开讲。真正的瓶颈在于：你如何确保写出来的代码就是你真正想要的？因为写代码容易，但把一个具体问题真正需要什么讲清楚、规格化出来，可能难得多。所以至少在近期，人类的角色会是架构师，去思考让机器学习来设计的这段代码究竟有哪些深层影响。归纳式思维（inductive thinking）是另一个我认为人类仍然明显占优的领域：在更宏观的上下文里审视一个系统，从中发现模式，并基于这些模式做出决策。那我们今天走到哪一步了？首先，语法生成已经是超人水平。我上一次让 Gemini 帮我写一个函数，然后看着那个函数心想『这我能写得更好』，是什么时候的事了？这已经结束了。写代码的那些细枝末节——你可以争辩，可以找反例，但那个时代已经过去了。我们还有大量工作要做的地方，是多步骤的大型代码库。软件工程不是写代码。软件工程是你入职一家公司的第一天，发现代码库里躺着 3500 万行 PHP，而你需要在上面做改动——那一天你才真正明白什么叫软件工程。这正是当今的 frontier 模型正在进步的地方。管理这种极端复杂度、并把它拆解成可控单元的能力，是前沿仍在推进的方向。

[8:11] Benoit

Um it goes all the way to architecture. You look at I don't know the Google architecture. Thanks God we have Jeff Dean which was you know the the key architect there. But that's the level of thinking which has many implication which can go from how do you do hardware optimization? How do you manage security? How do you build a system so that 10 years later you're not full of regrets? And I think this is really the the range of progress we are working on today. So code is over but there's plenty to do. There's plenty of progress to be made. Now code is a very unique problem and in some way that's the reason we we did pitchfork on this. Um, first of all, code is a lot of data. There are other domains where you can find a lot of data to train your model, but code was so incredible. You could go and go on GitHub and start to to scrape GitHub. So, this was one of those problem where the amount of training data was a very unique situation. It is also a domain where doing verification is reasonable. You can run a piece of code, you can compile it, you can have unit test. So the ability to figure out is the model generating something correct was something that was pretty reasonable to do. That brought us where we are today. But today what happened is that we run out of training data. I think that 80% of the new code added to GitHub today is machine generated. So the notion of human bringing some knowledge that can be used for mining and to train model is reaching an end. But the good news is that we can do selfplay and selfplay is something we always liked a lot at deep mind. I suppose all know Alpha Zero. Alpha Zero became a superhuman go and chess player without any human knowledge just by playing against itself. We are now at that stage where Frontier model for code are able to do the same where they can create their own challenge.

这一路可以延伸到架构层面。你看看 Google 的系统架构——谢天谢地我们有 Jeff Dean，他是那里的核心架构师。那种层面的思考牵涉极广：怎么做硬件优化？怎么管理安全？怎么把系统设计好，让你十年之后不会追悔莫及？我认为这才是我们今天正在攻克的进步空间的全貌。所以说，写代码这件事结束了，但要做的事还多得很，还有大量的进步空间。代码其实是一个非常独特的问题，某种程度上这也是我们当年做 Pitchfork 选它的原因。首先，代码意味着海量数据。别的领域也能找到大量数据来训练模型，但代码的条件实在太好了——你可以直接去 GitHub 抓取数据。所以就训练数据的体量而言，这是一个非常独特的场景。其次，这也是一个验证成本合理的领域：代码可以运行、可以编译、可以跑单元测试。所以『模型生成的东西对不对』这个问题，是相对容易搞清楚的。这两点把我们带到了今天。但现在的情况是：训练数据用完了。我估计如今 GitHub 上新增的代码有 80% 是机器生成的。所以『人类贡献知识、供我们挖掘并训练模型』这个模式正在走向终点。但好消息是，我们可以做 self-play——self-play 是 DeepMind 一直以来的最爱。想必大家都知道 AlphaZero：AlphaZero 不依赖任何人类知识，纯靠自我对弈就成为了超人水平的围棋和国际象棋选手。我们现在正处在这样一个阶段：代码领域的 frontier 模型也能做同样的事——它们可以自己给自己出题。

[10:20] Benoit

They can judge the validity of the answer. they can even to some extent judge the architecture. So that ability to do those hundreds of millions of hours of selfplay writing code is the thing that will bring us to the to the next layer. You know, it's interesting. Um do the experiment. Take a a brilliant software engineer, lock him in a room, lock him or her in a room for two years and feed pizza and give the mission you need to become a better software engineer. What do you do as a person? you you give yourself some challenges, challenges that you can verify and you keep working and coding on those challenges. We can do the same here. So this is an issue of how much compute, how much selfplay time we can have. But that will bring the horizon of how far we go in superhuman coding. So the economics of code are changing dramatically. You know, as I say, we developed a whole software engineering culture and infrastructure and set of companies based on the assumption that writing code was the hard part. That this was the expensive part. We're now in a world where writing code is free or nearly free. That's why I've got the tilda there. That means that the amount of code that we're going to see produced is going to explode. And there are some hard implications to that. First is the question of design and adequacy. How in front of that mountain of code which will be written or written dynamically, how do we keep systems which works and are reliable at the microscopic level? Great role for human. It is also the issue that you know we're writing code and we're not reading it very much anymore. I mean I know we still have code review but I would predict that in one year we'll let Gemini or other model generate the code and nobody will actually look at it. You know it's similar to compilers who still check the assembly output of their compiler and maybe someone there but that's probably the end of it. So the same thing is going to happen to code and that brings some question of what are the new process that we need to put in place to keep that manageable and that's where I've got a [clears throat] a bit of a list active guard rails. I mean you've all seen the news of mythos looking at a piece of code and detecting a unreasonable number of vulnerability in that code.

它们能判断答案是否成立，甚至在一定程度上能评判架构的好坏。所以，这种让模型通过数亿小时的 self-play 来写代码的能力，正是把我们带向下一个层次的关键。你想想，这挺有意思的——做个思想实验：找一位非常出色的软件工程师，把他或她关进一个房间里两年，只管送披萨，任务就一个：你得让自己成为更好的软件工程师。作为一个人你会怎么做？你会给自己出一些题目——那种可以自我验证的挑战——然后不断地在这些挑战上写代码、打磨。我们对模型也可以这么干。所以这归根结底是一个问题：我们能投入多少算力、能跑多长时间的 self-play。而这将决定我们在超越人类水平的编程上能走多远。所以，代码的经济学正在发生剧变。就像我说的，我们过去建立起的整个软件工程文化、基础设施乃至一整批公司，都建立在一个假设之上：写代码是最难的部分，是最贵的部分。而现在我们所处的世界里，写代码已经免费或近乎免费了——所以我在幻灯片上打了个波浪号。这意味着接下来产出的代码量将会爆炸式增长。这带来一些相当棘手的影响。第一个是设计与适配性的问题：面对那座即将被写出来、甚至是动态生成的代码大山，我们怎么在微观层面上保证系统依然可用、依然可靠？这是人类可以发挥重要作用的地方。另一个问题是，我们在写代码，但已经不怎么读代码了。我知道现在还有 code review，但我敢预测，一年之内我们就会让 Gemini 或其他模型直接生成代码，而没有人会真正去看它。这就像编译器一样——现在还有谁会去检查编译器输出的汇编代码？也许还有那么一两个人，但基本上也就到头了。同样的事情将会发生在代码上。这就引出一个问题：我们需要建立哪些新的流程，才能让这一切保持可控？这里我列了个清单，第一项是主动式的护栏（active guardrails）。你们应该都看到过那些新闻——模型审视一段代码，就能在里面发现数量多得离谱的漏洞。

[12:57] Benoit

there is a rush to go and patch those vulnerability but I think that's going to be a neverending process you know we're going to get a certain layer of vulnerability discovered by models we're going to fix those models will get smarter they will go a bit deeper and find even more subtle vulnerability so I think that the first aspect is that we need to think at least as much about code security and the implication of a piece of code than on the code writing itself and the grail and you know something my team is working actively on is instead of detecting the vulnerability and then suggesting some fix how about teaching model to write correct things from the start and that is very very hard to do because it is very context dependent the other aspect is that you know that's what I call inductive architecture uh I think that models today are still not very good at transferring knowledge of taking knowledge from one domain and applying it to another one or taking two concepts and finding the intersection of those context to be those context to be able to do deductive thinking. If we really want to write those very complex software system using ML that is a skill that we need to teach and you know one aspect of that is to really teach models how to do correct planning in front of a problem. How do you look at a very complex problem and decide what is the right decomposition of that problem that will bring the best clarity or correctness to the to the problem. We also need to change the way we do evaluation. I mean u threebench is infamous in in my book because threebench verifies if a piece of code runs and produce the right output. That's only a small part of as I mentioned earlier of code engineering. So for instance, I think that we need some problems much more in those benchmarks that we use which are open-ended problem. I I'll give an example. Uh I love the question of text compression. How many bits per character do you need and how far can you go? So that's a very simple eval to to write. You just take a piece of 10 megabyte of code and you tell the model write the best compressor you can that is lossless and the loss function in that case will be you know the size of the compressed file plus the size of the source code that's never ending I mean those problems are I think what's going to force those model to do novel things like creating totally new algorithmic for instance and I I think we're now getting to that stage Writing code or doing software engineering is not thinking as a chain of tokens.

现在大家都在抢着去修补那些漏洞，但我认为这会是一个永无止境的过程：模型先发现一层漏洞，我们修掉；模型变得更聪明，就会挖得更深，找到更隐蔽的漏洞。所以我认为第一点是：我们对代码安全、对一段代码带来的影响的思考，至少要和对写代码本身的思考一样多。而真正的圣杯——也是我的团队正在积极攻关的方向——不是先检测出漏洞再提出修复建议，而是从一开始就教会模型写出正确的代码。这非常非常难，因为它高度依赖上下文。另一个方面，是我所说的归纳式架构能力。我认为今天的模型在知识迁移上还不够好——把一个领域的知识拿过来应用到另一个领域，或者拿两个概念找出它们的交集，从而进行演绎式的思考。如果我们真的想用 ML 来构建那些非常复杂的软件系统，这是一项必须教会模型的技能。其中一个环节，就是真正教会模型面对一个问题时如何做正确的规划：面对一个极其复杂的问题，怎么判断哪种问题分解方式能带来最好的清晰度和正确性。我们还需要改变做评测的方式。SWE-bench 在我这儿是有点臭名昭著的，因为它只验证一段代码能不能跑通、输出对不对——就像我前面说的，这只是软件工程里很小的一部分。所以我认为，我们用的这些 benchmark 里需要加入更多开放式的问题。举个例子，我特别喜欢文本压缩这个问题：每个字符需要多少比特？你能压到什么程度?这个评测写起来非常简单：拿 10 MB 的代码给模型，让它写一个最好的无损压缩器，损失函数就是压缩后文件的大小加上压缩器源代码的大小。这个问题是没有尽头的。我认为正是这类问题，会逼着模型去做真正新颖的事情，比如创造出全新的算法。而且我觉得我们现在正走到这个阶段。写代码，或者说做软件工程，并不是以 token 链的方式在思考。

[15:51] Benoit

Thinking and reasoning today is chain of code which has been you know very successful and improve models a lot. But humans of course are much more complex in the way they think about problems. I always think that code writing is a very visual activity and that can be I don't know the block diagram of what you're doing or the flow of data through your code. uh but saying that code will be just a set of token that you emit that are going to be the code I think goes only up to a certain point that's a very interesting aspect to what we do at Google Gemini we made that choice from the onset that this would be a multimodal model that you know text was only one of the modality that Gemini would be able to apply and we're starting to see you know how can a model start to think in term of spatial or dynamic representation to to solve problem and I think that's going to become a must have another interesting question is is this time to create a new language for models Python you name it have been invented for humans and those language are not very good to write safe or reliable code I mean they're great to write code but they're certainly not the the best thing I think We're getting to the point where since the pain of writing the code does not exist anymore. How about we make writing the code much harder by having you know very strongly typed languages or you know some inspiration from lean on how to write code that by design it's not going to be perfect. I mean program proof is something which has some limits but at least putting the burden of correctness on the model. So I don't know if we have some language designers here, but I I I think there's something really to be done there and it doesn't need to be human readable. I I don't think that that will matter anymore. So beyond code, um code is a universal language to solve problems. I think that what we're starting to see is this ability to experiment very quickly in code is impacting other domain very quickly because doing experiment becomes basically free. So I think that looking at that intersection of code writing and atoms or science is another big front that we are opening that is the place where true novelty is going to appear.

今天的思考和 reasoning 是「代码链」——这条路非常成功，让模型进步了很多。但人类思考问题的方式当然要复杂得多。我一直认为写代码是一种非常视觉化的活动——可能是你脑子里那张系统框图，也可能是数据在代码中流动的路径。而如果说代码就只是模型吐出来的一串 token，我觉得这条路只能走到某个程度。这也是我们在 Google Gemini 所做的事情里一个很有意思的方面：我们从一开始就决定 Gemini 是一个多模态模型，文本只是它能运用的模态之一。我们已经开始看到，模型如何用空间的、动态的表征来思考和解决问题——我认为这将成为一种必备能力。另一个有意思的问题是：是不是到了为模型创造一门新编程语言的时候了？Python 也好，别的语言也好，都是为人类发明的，而这些语言并不擅长写出安全、可靠的代码——写代码它们很好用，但论安全可靠肯定不是最优解。我觉得我们正走到这样一个节点：既然写代码的痛苦已经不存在了，那我们何不反过来把写代码变得更难？比如用类型系统极强的语言，或者从 Lean 那里汲取灵感，让代码在设计层面就……当然，程序证明（program proof）是有局限的，但至少可以把「保证正确性」的负担压到模型身上。我不知道在座有没有语言设计师，但我认为这里真的大有可为——而且这门语言不需要人类可读，我觉得那已经不重要了。再往代码之外看，代码是解决问题的通用语言。我们开始看到的是：这种在代码里快速做实验的能力，正在飞快地影响其他领域，因为做实验基本上变成免费的了。所以我认为，代码写作与原子世界、与科学的交叉点，是我们正在打开的另一条大战线——真正的新颖性将在那里出现。

[18:24] Benoit

two which are especially exciting for me is chemistry. Um you know as humans we do not understand chemistry or we understand a very very small sliver of chemistry. Once you have more than 20 atoms in your molecule it's like wow we don't know what that thing is going to do. I think we're going to see incredible things emerging out of that. I mean once you are able to put 10,000 atom together that starts to look like life. So what are all the other things you can do with 10,000 atoms? Biology. You probably heard plenty about it, but you know, biology is the case of nature did an incredible engineering job and terrible job at documentation. Um, but we can crack through that now. Models are able to find those relationship that might be elusive for us. So I think that that is something that will open incredible door. And then there is what I call the gold we cannot see. Humans are incredibly biased in what we feel is the correct solution. I mean, we're the result of an evolutionary training that help us survive in the jungle, right? Not doing quantum computing. So, I think that even though we can be brilliant and innovative, there are whole bunch of progress and breakthrough that can be done which we just cannot see or perceive. If I had more time, I would give some examples. I think that's one of the thing where ML is such a different viewpoint on many of those problems that we're going to get the oh my god this was in front of us the whole time and we could not see it. So exciting times ahead. Thank you very much. [applause]

其中有两个领域让我特别兴奋。一个是化学。作为人类，我们其实并不理解化学，或者说只理解化学里非常非常小的一角。一旦分子里的原子超过 20 个，我们就只能感叹：哇，完全不知道这东西会有什么行为。我认为这里会涌现出令人难以置信的东西——要知道，当你能把一万个原子组装在一起时，那就开始有点像生命了。那么，用一万个原子还能做出哪些别的东西？另一个是生物学。这个你们肯定听得很多了，但生物学的情况是：大自然做了一场不可思议的工程，却把文档写得一塌糊涂。不过我们现在有能力把它啃下来了——模型能够发现那些对我们来说难以捉摸的关联。所以我认为这会打开一扇不可思议的大门。然后还有一个，我称之为「我们看不见的金子」。人类对什么才是正确解法的感觉带着强烈的偏见——毕竟我们是一场进化训练的产物，那场训练是帮我们在丛林里活下来的，对吧？可不是用来搞量子计算的。所以我认为，即便我们可以很聪明、很有创造力，仍然有一大堆进步和突破是我们根本看不见、感知不到的。要是时间多一点，我可以举几个例子。我觉得这正是 ML 的价值所在——它看待许多问题的视角和我们截然不同，将来我们会有很多「天哪，答案一直就摆在眼前，我们却看不见」的时刻。激动人心的时代就在前方。非常感谢大家。[掌声]

[20:23] Benoit

[music]

[音乐]