00:30:12 · Aditya Agarwal
[00:30:12] S2: I think most of us who have a more distributed systems back end or kind of a world where we have kind of built apps for a living, we're used to living with a world where failures happen, you tolerate them, it's not that big a deal, you kind of recover them. Most of the systems are pretty fault tolerant slash the worst case is not that big a deal. So what is a mindset shift you need to make to build systems for the real world deploying two ton robots that are flying through San Francisco? Do you have to untrain people who you hire to kind of think differently? How do you kind of put that mindset in? I think it's a very different mindset that most of us are used to when we build kind of computer systems.
00:30:53 · Dmitri Dolgov, Ruchi Sanghvi
[00:30:53] S0: Generally you don't have to untrain people. You have to hire people who are very good and are adaptive and fast learners. But you get I guess some of the principles that we apply to our research and engineering are not earth shattering. We just take them very seriously and we apply them to that, very high degree of rigor in everything we do. And it starts with having that culture of being safety first and eval data driven primarily. Right? And just like safety, eval is kind of not something you do after the fact. Right? It's not something that you do as an afterthought. It is something that kind of permeates all of all of the work you do across the team and all of your engineering practices. And... But, you know, it's not unlike, you know, good engineering practices of, you know, being test driven development. Right? You start with the test before you write a code. You think about, you know, what has to be true and how do you evaluate your system before you deploy. We just take it, to that next level of fidelity. [00:32:06] S1: The part that I'm still wrapping my head around is when a robot learns in simulation, how do you know whether it's getting better or getting better exploiting a loophole? Like, what is the reward function? Like, what evidence do you require outside of the training group to prove that to believe that the improvement is actually real? [00:32:27] S0: Yeah. So I think this gets back to this fundamental question of metrics and evaluation.
00:32:27 · Dmitri Dolgov, Ruchi Sanghvi
[00:32:27] S0: Yeah. So I think this gets back to this fundamental question of metrics and evaluation. [00:32:33] S1: I have to ask right after this, how strong is your eval team? We've heard upon eval so much.
00:32:38 · Dmitri Dolgov
[00:32:38] S0: Yeah, we have a very strong eval team, the team that builds the infrastructure, the simulator, all of the metrics, the data science team that supports that. But it's also, like, the eval first mindset, that is spread across the entire company, across definitely all of the engineering functions. And you do... It's not one or two simple metrics that would describe that, what does it mean for an autonomous system to be ready and good enough? And it's not a couple of things that you measure at the system level at the very end of your development. It starts kind of... You know, do, you know, eval and hard data driven evaluation every part of your system. Right? Now it starts with that model level. And, you whatever model you're training, and you don't train it monolithically, and you you kinda train your encoders, you train your decoder, and they have, you know, many mesh. We can talk a little bit about end to end and, you know, structured representation because that is an important aspect of supporting, you know, rigorous training and evaluation. And then, you know, that goes to kind of dense proxy metrics of the system level performance that are maybe not the final things you care about, but they're very dense, you know, predictive signals about the performance that you will see in the field. And then you do rigorous system level evaluation, you know, everything from safety, you know, to quality. And we run billions of miles of simulation. And every release before we put it out on the road goes through this multi week rigorous evaluation and validation cycle that includes testing both in the physical world and in simulation. And then we have a team of well, highly experienced subject matter experts to refuel of the data, and all of that gets fully vetted before we put the software on railroads.
00:34:26 · Aditya Agarwal, Dmitri Dolgov, Ruchi Sanghvi
[00:34:26] S2: To your point earlier, it feels as though that having that pipeline and having that infrastructure to be able to both iterate and then deploy with confidence feels like a real source of competitive advantage. And I suspect that anybody who's deploying any kind of physical, whether robots, drones and so on, at scale will have to have that. But I don't know if how many like there are that many companies that have that today, right? [00:34:52] S0: Yeah. No, I think that's one one of the hardest things to build. And really, again, there's some applications where that might not be required. But there is a big divide. And if you are on the other side of it, where it's safety critical, it does require closed loop training, closed loop evaluation, then you're in a very different world where, you know, those fundamentals matter tremendously. [00:35:16] S1: If you had three exceptional engineers who are starting today, they had Waymo sized ambitions but a startup budget, where would you tell them to start? [00:35:26] S0: What space? Physical AI, anything? [00:35:29] S1: Physical AI. Let's keep to physical AI.
00:35:33 · Dmitri Dolgov
[00:35:33] S0: Oh, man. There's so much I'm super excited about all the things that we could be building in physical AI. If, I think, yeah, if you have Waymo's ambition, but a qualitatively different budget, if I think that puts you on that side of the spectrum where you need to, today, look at applications where you can simplify the problem. Maybe you can control the environment, or maybe you can build a system that helps humans as opposed to being fully autonomous. Again, this, I think, my mind, this is the big divide in our domain. Right? Are you building, you know, a driver assist system or are building a fully autonomous system with superhuman safety that you're gonna deploy and scale? Qualitatively different problems. So I think there's a similar analogous divide in other applications of AI in the physical world. So if you are looking for a relatively quick product you can deploy, or application, a problem you can solve, an application you can deliver, then I look for something where it can be simplified. Again, maybe something in, let's say, warehouse, in you can control the environment, you can maybe put some guardrails in the system. There, I think you can make a lot of progress by taking the ingredients that already exist kind of off the shelf, again, doing some, you know, open loop imitation things and deploy it, and then iterate from a deployed product. Other... If you're on the other side of it, then I think you have to be realistic that you need to invest in the fundamentals, which is less about the product and iterating and, you know, deploying and iterating, but more about focus on the fundamentals, like world models, realistic simulators for whatever agent you're building, and the whole infrastructure and evaluation machinery.