The TWIML AI Podcast (formerly This Week in Machine Learning & Artificial Intelligence) - From Voice Agents to AI Avatars with Alexander Smola - #777

0:00Voice AI has gotten very good over the past few years, but it still suffers from a bit of an uncanny valley problem. Humans are remarkably sensitive to the subtle things that make a conversation feel natural or not. A little too much latency, an interruption handled awkwardly, the wrong tone or emotional response, and suddenly the illusion breaks. And the bar only gets higher as AI systems evolve to incorporate more of our senses. Moving beyond text and voice to systems that can see and be seen, introduces a whole new set of challenges around natural interaction. My guest today is Alex Smola, co-founder and CEO of Boson AI and a professor at Carnegie Mellon University. Our conversation explores what it takes to build these systems, from the models and inference infrastructure needed to make voice work in real time, to emotional intelligence, and ultimately audio-visual avatars. Here's Alex on where he sees all of this heading.

0:57I would argue that voice is an intermediate stepping stone. You might think, well, you know, what's next? It's clear that eventually we will have avatars. And so I think what this is converging to is that you'll be talking to an aviation that looks and feels like a human. And we're still very, very far away from making this really natural. So it's quite exciting actually.

1:24I'm Sam Scharrington, and this is the Twimble AI Podcast. For over a decade, I've been exploring the ideas and innovations shaping the future of AI through conversations like this one that help you understand what's real, what's next, and what matters. Let's jump in. When I think about kind of the frontier of voice AI that most folks probably have access to, I'm imagining it's something like chat GPT advanced voice mode like and I actually I want you to react to this Do you think that actually that's you know crap and there are much better systems and you should point me to you know X Y and Z or Are there you know are there better systems behind closed doors and labs and enterprises or what but in general I tend to think that You know they've gone through several iterations of it. It does keep getting better, but it's still very infuriating and

2:27In my experience, it really only works in perfect conditions, meaning a silent room, no background noise, being very conscientious about interrupting. If you interrupt, either you have to be committed to plowing forward or you have to stop and let the thing catch up to you. You can't try to have a natural engagement. It's very brittle, I think. You can definitely do better than that situation.

2:56Fun situation from last week. So I was at in Jeju in South Korea for the KDD conference and we were out at dinner for drinks in a bar and Basically I was showing off our system and you know just you know me foolishly saying hey watch this. Let's see what happens and so What I can confirm is that our model was able to handle people switching to Slovenian and then somebody else to Hindi fairly well even though the bar was very noisy. I would say a non-trivial amount of the credit definitely goes to the iOS team doing really good noise cancellation and audio separation on the mobile phone. So I don't think that this would have happened just by waving a microphone somewhere.

3:56But I think we're on our way. And so basically, you know, having a single microphone will probably never really solve this. You need microphone arrays to really do proper noise cancellation, especially if you have many sources. But that's a solved problem, right? I mean, those things ship. Well, I've got a huge microphone array sitting in my laptop here. I don't know if Codex was using it, but like I've also had like kind of Eh, experiences with a relatively new Codex voice. That interaction just wasn't very fluid. Yeah, okay, so that's... I mean, sometimes voice input is good if you're feeling too lazy to type. I find typing way more precise for technical work. But for... So as in, you know, hey, let's configure our storage array. Well, no, I don't want to talk to you, I want to type.

4:57because here's a very specific serial number and a specific URL, and I want to get this exactly right. So that's where I still prefer text, but maybe this is old school. But if you're out in a bar and you're asking for information advice or something, I think we are getting there. I will give it another year, and this will actually become quite ubiquitous.

5:26pretty happy where we are at with our models. I think probably in a year, audio will become pretty much bulletproof. Video feeds, as in avatars and so on, are going to start making some appearances. Probably a year and a half. We'll see that quite widely deployed on robots, basically with a face fully animated, so we're working actually with the startup on some of those things, problems related to that. It's a very talented team. So, and there, I think the lead times are a little bit longer because if you want to do this in the, you know, animated hate or whatever, you actually need to make hardware and hardware is hard, right? Software is easy, comparatively. When you think about the challenge of voice AI,

6:29How do you break it up in terms of, you know, primarily engineering problems, primarily research problems? If you try that, it's not going to go well. You need to do both at the same time. So let me give you a simple example. So let's start with, you know, the very simple basics, namely it takes about 150 milliseconds for, you know, basically a photon hitting your retina to your cortex actually doing something with it. And that number is reasonably stable that you can actually use that as a non-invasive diagnostic to find out whether you have a neurodegenerative disease. Because in that case the signal takes many detours and it takes longer. So what people will do is they will flash a checkerboard pattern in front of you and then wait how long it takes for that stimulus to hit your cortex. From the ears it's actually a little bit shorter because it's a

7:27Well, half the way, right? Now, what that means is that basically humans kind of operate at around maybe 6 to 10 hertz really when it comes to audiovisual perception. I mean, of course, we feel like the world is very fluid and I mean, we have our fancies 30 or 60 hertz displays, but the brain kind of, you know, within that time frame, it's kind of okay. So what we...

7:58did correspondingly is make sure that our model is interruptible within about a similar time frame. So it does interruption handling within about 150 milliseconds or so. Now the next thing is you need at least the current paradigm of how to deal with audio and other things is at some point you convert everything into tokens and then those tokens will go to whatever LLM style backbone that you have. The architectures may differ and maybe at some point we'll get to diffusion based models. I would think it's probably going to be more like speculative decoding with diffusion and the more traditional sequential models for just overall the statistical modeling.

8:54you know, that's a completely different argument and Stefano and one may have very different opinions on that. But basically, you know, you need to turn the audio into tokens, then your model does something, and then you need to turn those tokens back into audio. Now, you can get very high fidelity by having a very high token frequency. The problem is a high token frequency means that you need to ingest, thus prefill, and also generate many, many tokens per second. And we all know that this is expensive. So now you have this rather unpleasant dilemma where many tokens per second means your model cannot have too many parameters. Whereas if you have a smaller number of tokens per second, you can afford more parameters. Text is the ultimate compressed format in that sense.

9:51you know, three to five tokens per second that humans want. Whereas for audio, you can easily have, you know, 10 plus. And tokens per second also then means, you know, kind of, you know, the temporal granularity, let's say have 10 tokens per second, then that means that each token covers about 100 milliseconds. So this is why you actually get biology, user experience, engineering, because you need to make this cost effective.

10:19And then science, namely how do we actually represent this? How do we send it into a model? Maybe doing something else more cleverly in the entire pipeline. So this is why all those things really need to come together. It may not necessarily be one engineer doing everything. That would be pretty amazing if you could find somebody like that. I mean, there are very few people, but that's okay. But it's a whole systems challenge.

10:48And then of course, once you have all of that running, you need to also take care of the engineering implementations. You probably need to buffer a little bit. So remember when I mentioned you want to be interruptible, but you probably want to have longer buffers. So now we're talking about essentially no real-time type AV streaming. You also have a video feed. The video feed may come in at a different frame rate.

11:18Basically, it's a really nice range of problems there. And for the video feed, I mean, we all know if you use WAN or some other models or flux, they will happily produce video segments of 10ish seconds. But if you want to have a continuous feed that is visually consistent for an hour, you need to modify those models a little bit.

11:46And if you then want to make those models effective such that you can have multiple real-time factors, there is yet another design optimization to be made. The TLDR is if you are doing video feeds for avatars, you know that it's a video feed for an avatar, so they are not going to be race cars driving in the background. In other words, most of the video feed is pretty boring. So, for instance, you could easily compress the AV.

12:17for this interview into a, well, fairly effective stream. Of course, if I start moving my hands like crazy, then that frame rate, then the bid rate will immediately go up by a lot. But most humans don't do weird things like this. And so it's a perfectly acceptable feed quality. And again, there's a trade-off between most beautiful quality and building something that actually people can afford.

12:46And that's probably also the other point where we are maybe taking a slightly different operating point from some of the, well, very large trophy models that are, you know, trillion parameters just to do chat. And which point in particular, the affordability or something about the trade-off or which? So the affordability, right? So basically, you can always make your model smarter by making it bigger.

13:15absent of the real-time criteria that you mentioned with regards to voice. There are some laws of physics that come into play here. Yeah. And so the problem is basically, you know, how much compute do you need to stream, you know, a conversation? And if you need to use, let's say, you know, a full Blackwell server GPU just for a single conversation, then that may not be...

13:45the most economically viable model. I mean, this produces gorgeous demos, but your customers can't afford it. And that's, I think, where we went in with a price first and then worked backwards to how can you build something that actually people can afford. Can we take a step back and maybe have you talk a little bit about your...

14:11kind of arc or trajectory or path, like you started the company in 2023, you were not initially focused on voice, you eventually shifted direction to voice. When you started really focusing on voice, kind of where did you start and what were the steps you took to kind of evolve to where you are today? So we started off with text, just like I guess others as well, maybe with a slightly stronger focus on AI for humans. I mean, that's been with us since day one. And as mentioned, the one of the key issues was that, you know, the text interface felt always a little bit awkward. And so we then started looking at, okay, what are good audio models? We also realized that probably building your own LLM

15:07was not the smartest idea if you just wanted to have really good audio but instead, can you use the intelligence that's already baked into a high-quality LLM and then make sure that it acquires effectively one extra modality, namely in this case audio. Again, other people had done similar things for instance for video, so for instance there are vision at least, so there are BLLM, so vision large language models.

15:37People are doing similar things for robotics and world models. So the overall pattern of using the intelligence that you kind of get for free from reasoning over large amounts of text, you then combine that with audio. Now, one of the problems is if you teach this model a new modality and you're not careful, it forgets everything that it knew before. Probably the easiest way to imagine that is if you And I've actually seen that with a friend, so she adopted a kid from Latin America, so this was in Germany, and she spoke only German to her, and within a matter of months, the girl had forgotten every single word of Spanish, right? And a similar thing effectively happens if you take an LLM and you only get it to work with audio, then it will very quickly forget about all the reasoning and language itself.

16:36So you need to still maintain a somewhat competent mid and post training LLM pipeline while also having the same capabilities for audio. And you need to then also define tasks that nicely marry audio and text, so to ground things into each other. I mean, just like if you have a multilingual LLM at some point you need to make sure that dog means shia or kane or hund and if you don't have that then it becomes a little bit tricky for the model to reason across languages and to get that strong generalization. But anyway, so if we did this, we then released I think a fairly competent TTS model that was Hicks Audio V2.

17:31last year and I think we've significantly accelerated our release pipeline this year so we've been putting out TTS and audio understanding in ASR models and so in case you wonder what's the difference between so TTS means text to speech so basically you know text in sound out voice cloning all of that but what's the difference between audio understanding and ASR?

18:00So speech recognition, speech recognition, it's audio in text out, but the model doesn't really understand very much of what's going on. I mean, it understands a little bit, but these are fairly lightweight models, but they will not be able to resolve whether to recognize speech means to recognize speech or whether it means to wreck a nice beach, right? They both sound the same.

18:29And obviously one is nonsense unless you are in some environmental conservation event where they probably mean the latter. But you don't know, you know, the ASR isn't going to be able to handle that, but an audio understanding model that can reason over the audio plus maybe a text prompt plus maybe other audio references can.

18:59So these are then models that are much more similar to your, you know, favorite LLM just that they can now take different modalities as input. And you could then also consider having video as another input in addition to audio and text. And you could have, you know, world model parameters or your robot or your soft driving car and other things also as inputs and then correspondingly all of that coming back out.

19:28So if you think about it is basically the tokens are like your bus on the back where all the information gets sent through and then comes back out again. So this is really the glue that ties everything together. In any case, so we started releasing those models and I think by now we have something that has very good latency. Then we started having to really do performance tuning to make those models really interactive. That's, again, extra work. And I think by now we're in a decent position. So I'm pretty happy and proud about what the team built. And so along that path, what was the, when you think about kind of the significant technical challenges that you ran into that, you know, the team really had to, you know, go heads down and you think came up with a

20:27clever solution like you talk about some of those key technical challenges. So I think one of the things that are a meaningful differentiator is that we can process and have a lot of all your data and that's a meaningful mode. That's not the least training data set that you've collected or throughput or something else.

20:54No, it's the training data set really. So we have in the order of 100 million hours of audio. And it's about 200 human lifetimes. If you live for 75 years in a very noisy environment, you would get about that amount of audio, not necessarily spoken, but that amount of audio. But you can actually go forth and scrape and crawl a fair amount of that data.

21:26online, but then you need to process it. You need to extract, tag, normalize, transcribe. There's a lot of extra processing that's needed. And having our own data center really helped us there. If you were to store this data on a new cloud, the storage bill would eat you alive. And yeah, if you were on one of the big three cloud providers, it would become even more problematic. So at least until recently, when hard drives started becoming really expensive again, this was a very nice situation. I mean, by now, the hard drives are about three times the price of what they were a year ago. So, okay, we'll have to be a little bit more prudent now. And so talk a little bit more about this data set. Where, how is it sourced? Is it?

22:27kind of internet style videos and maybe you extract audio from video, that kind of thing. This and many other things, the one thing we didn't do is we did not spend unreasonable amounts of money on an annotation company. So every once in a while, I get emails from a company saying, hey, we can annotate 10,000 hours of audio for you. And at that point, I'm like...

22:55Okay, that's good for you We are at between 10 we're at 10,000 times that scale and so is that because the the existing Technology like you're the the existing tools are sufficient enough that you can There's a lot of engineering that went into this That's, I think, part of, I think, what's a meaningful asset of what we have. So my apologies for maybe being a little bit vague here. But yeah, that's where a lot of work went into. But speaking in generalities, you start with... More data is more better. And yes, it's basically, let's put it this way, it's sourced on the internet.

23:51you know, there are different types of data with different types of metadata that you can get, and then you need to be a good engineer and recognize what you can find. It prompts for me a question about the existing tools we have aren't perfect. So if you're starting with internet data and processing those with imperfect tools, you have a noisy, a fairly noisy label set, and you're using that for training like, you know, is that...

24:19Is that better? Is it worse? Does it create its own unique challenges? Like talk about the relationship between... Okay, so there's a couple of things. First of all, I mean, we know that it's possible to extract meaningful information even from noisy data. I mean, the simplest analogy is let's say you have a really awful voltmeter and you want to find out what the voltage in your...

24:46outlets in the houses, so you go around and plug it in many times. You get the numbers out and you average in the end and in the end you get something that's better than what an individual measurement of the world meter will do. And that of course only works if your world meter is unbiased. If it has biased then that procedure is useless. And that procedure has been around for ages. In the Middle Ages there was something called a foot rule where you estimate the foot by just having people walk out of church, and you grab the first 12 men, you send the two with the shortest and two with the longest feet away, probably due to deformity, take the other eight, average their length, and you've got a pretty good estimate of one foot. Now, okay, sorry for maybe giving a very crude statistics.

25:41Explanation, but that's literally where the foot drill and trim mean estimators come from, right? So robust regression and estimation is half a millennium old. Now, with audio, right? I mean, you can, first of all, it's not unreasonable to assume that by having a lot of data, you can estimate a better model.

26:09It's also not unreasonable to assume that once you have a better model, you can get better annotation, right? So basically all of the, you know, learning from weak supervision, all those ideas are applicable. In some cases, you also have context, and the context helps you more. And so with that context of privileged or site information, again, you can do a little bit better.

26:36So for instance, knowing that this podcast is between two people and maybe I can even see that in the annotation or whatever, or having seen that other podcasts on Twimble are usually Sam and one other person, so then you can go and use that to figure out if they're only two people. It's very easy to separate those speakers and then you get larger amounts of...

27:05you know, single speaker audio. It's also reasonably easy to tell I guess the two of our voices apart, which again helps you to then, you know, annotate a little bit better. And so basically having a lot of this stuff allows you to build better models and then you get that flywheel.

27:32I mean, if you think about it, people have used similar tricks for face recognition where usually matched and paired faces are not that easy to come by. But for instance, if you have a movie, you know that the actor may look very differently throughout the movie, but it's still the same actor and they are not that many actors. So what you can do is it's not that hard to identify the same actor within the movie, but then you can go and shuffle all the actors together.

28:01and suddenly you get the much harder data set where you have effectively labels that are with very high likelihood, very good. So this is a lot of, you know, classical machine learning and statistics, and of course it will help, right? So you do the right thing and it's work, but it helps. I mean, this is about, I think, as specific as I can be, but I think most...

28:30Most statisticians can do that, but you still need to do it at scale. You need to invest compute at scale. You need to invest into storage at scale for that. A non-trivial amount of our resources was invested in data, not just training. With regards to training, you mentioned earlier on that it was clear.

29:00that you didn't want to build an LLM. Does that mean that your models are primarily fine-tuned or somehow based on other LLMs or how do you describe the model approach that you took or training approach that you took? It would be very nice if we could just go and take a model and fine-tune it, but modifying those models is fairly major modification, right? So there's a full pre-med and post-training stage like in an LLM, and so what goes in is substantially different from what you get in the end, right? So they may share a non-trivial part of the same architecture, but there's a lot of training that happens even on the LLM side again.

30:01in order to make sure that the models retain their ability. So this basically whatever you can get on public models is just a good prior and then you optimize from there. Have you published or said like what your base model or models are or is that proprietary? It depends. So in some cases it's proprietary. So for instance one model that we released last year was built on top of Llama and we acknowledge them appropriately in our model card. So basically some of those design decisions are a little bit variable for whether we just build an audio app model or an ASR model or whether it's an audio understanding model. So you do need the full pipeline, but we can either build and train on top of

31:04an existing model or we can build our own, but that's then often an economic decision and also which features you need. So for instance, if you need particular performance in a particular language, then we may very well decide to invest also significantly more still on the language ability there. So it's really depends on the use case.

31:30Obviously, if somebody gives you free steel, you don't build a steel mill, you build a car. As long as those models are available, it makes sense to take advantage of it. It will be economically foolish not to. But I would say the work that's required in building the audio models is somewhat commensurate with...

32:01with the language model itself. Maybe it's half or one-third, but it's not one-tenth. So the other thing is, for instance, if you want to have models that are able to have a high amount of intelligence in the background, you need to specifically make sure that they can do this while they're still maintaining a conversation in the foreground.

32:33I mean, humans are pretty good at that. So, for instance, you may idly chat with somebody and in the back of your head, you're thinking about something else like, well, did I add some coins to the parking meter or I really need to go or you're actually trying to solve a difficult technical problem. So, for instance, in an exam, you may be stalling for time while in the back of your head, you're feverishly thinking about the solution, right? So what goes on there may be quite variable, but humans are pretty good at that. Machines are still improving, and that's actually also one of the really exciting frontiers there. How do you design architectures? Talk a little bit more about that. That's a great segue to...

33:31the question that I wanted to ask, which is really around how you do that. As you were talking about the challenges of audio AI earlier, one of the questions that arose from me is, are we able to do this all with a single model? Does getting it to hierarchical models, your system one, system two, kind of bolted together to create a fluid experience. Does that ever make sense? Like, how have you come to think about, you know, overall architecture for these types of systems? I mean, there are some systems that are just, you know, end-to-end audio. And, you know, they have their place for something that's, you know, super responsive, fairly small, fairly low latency, but also fairly dumb. The problem is if you were to try and make them

34:28really smart, they would become unaffordable in terms of compute costs. So you really don't want to do that. Now, what you can do is you can have something that's maybe a little bit more of a two-stage architecture where the understanding and reasoning happens in one end with appropriate tool calls being fired off in the back end, maybe then the answers being received.

34:54So it's really just like you would also do in multi-threaded programming, right? Where you have a main thread and it may fire off other threads in barrel that may do things and then get the answer back such that you can get the nice data flow. And I think a lot of tool calls, agentic programming and so on have actually been quite helpful there.

35:20The other thing is it also allows us to build models that you can instruct just like you would a language agent. The prompts that you write for our model are look and feel the same as if you were just instructing a regular LLM, just that our model also talks. So that makes it much, much easier for humans to work with that.

35:50Of course, in the back, there is a lot of engineering going on deciding when to do a tool call, when to answer it directly. And then you also need to figure out when is the question easy enough that the model can answer it and when is it sufficiently hard that you probably need something else. And again, that depends on the model size, depends on the information that's required.

36:18So do you need a database query? Do you need to talk to an MCP server? And yeah, that is actually something where we, I think, spent a lot of time. And the reason why we spent a lot of time is because we want to make sure that the model is affordable. So you can easily build a very big model. And that then uses a massive GPU.

36:46And unfortunately, the user in the end pays for that massive GPU. So right now, on benchmarks, we are better than, let's say, GPT and Gemini and Grock at a fraction of the cost. So we are better than OpenEye's models at one-tenth the cost. Caveat with that. On what metrics?

37:15Intelligence, speech accuracy, all of the above. So this is for instance for big bench audio or complex function benches and so on. So there's a couple of corresponding benchmarks. Now the little footnote is this is with thinking turned off in these models. Now you might wonder why on earth would you turn off thinking? Well, because...

37:43you don't want to have the big pause where the model thinks and then it responds, right? Because that feels very unnatural. So humans don't do that either. I mean, they may say, hey, let me think, but that's now, you know, you need to correspondingly integrate that. I think that's what that was actually the thought that led to kind of this hierarchical thing, like I'm envisioning a...

38:09a model whose primary function is maintaining the conversation. And it might say, oh, that's a really interesting question. I'll have to think about that for a second and kind of like you alluded to kind of stalling, you know, while the tool is completing to retrieve the information. So for instance, you know, if you test our, you know, you can test it out actually on our demo live afterwards.

38:39So basically, for the Higgs live demo, this performs web search in the background. And depending on how quickly it gets the result back, it will just answer or it will actually tell you, hey, let me look for that. And the challenge is now to make this all feel very organic, such that the user doesn't...

39:07feel any breakage of the entire interaction, because you really want to maintain that illusion of a properly engaged other party. You don't want to break that sense that the model is able to search and do all of those things in the background. That's where a fair amount of the engineering comes in.

39:38And for speech applications, are you able to use off-the-shelf MCP servers for most of the things that you might want to use them? Yes and no. So yes we can, but the quantity of servers enabled at the same time right now is a little bit limited. The next iteration is going to support significantly larger numbers of them at the same time.

40:07Basically this is all about, you know, context window sizes and so on and again, you know, cost of inference. So there's a trade-off because if you do quite a massive pre-fill and then you have a large KV cache that you need to lug around with you, that of course, you know, makes the token generation more expensive. And this is really a little bit the trade-off.

40:33But what you can do is you can then have tool calls and the tools themselves have MCP configured and so on. So there's plenty of nice ways how you can do this efficiently. Of course, you can also do things where you build hundreds of billion parameters front-end audio model. And that makes for gorgeous demos, but not so gorgeous.

41:01cost as soon as, yeah. This is really, I think, where we took a slightly contrarian approach where we went for affordability first. That's very interesting. It's also a little different from what I was asking. And the experience that was the motivation for my question is, as I build, agentic systems with just kind of off the shelf, MCP servers, internet, you know, base services, you know, personal data, they're slow. They're really slow. And it's annoying even in text. It's unimaginable in a voice scenario. And so really the question I was asking was almost, do you have to build everything from the ground up in order to make it work for voice?

42:01I'm imagining the way you would build a weather MCP server is a lot more efficient than, you know, in an ideal world. As a matter of fact, you can test out, you know, you know, basically search news and weather and it feels very fluid in our application so you can go to, you know, Buzz on AI.

42:23And presumably you didn't have to build those yourself, you're just using. So you use a good server for that. And being able to use these, I think it's both a feature and a necessity. It's a necessity because you don't want to have to reinvent all the tooling again. It's also a necessity because our customers don't want to have to relearn new techniques, right?

42:52And that then also becomes a feature because it makes it easier to integrate within an existing system. But if you have a service that takes a long time, I mean, humans are pretty good if I ask you a question that you have to look up. If I were to ask you, hey, when was I last time on Twimble?

43:20and I don't think you remember the exact date. You would probably tell me something like, hey, Alex, let me look it up. And then you'll open your laptop and do your search and maybe five or 10 seconds or maybe a minute or two later, you'll come back and say, oh, this was at that and that date. And it would feel totally normal for me. I would not be offended with you.

43:47spending that time because you told me before, hey, this is going to take some time. So humans are very tolerant to delays if they are told that there's a delay. My favorite example is actually the boot screen from Apple. So Apple does something brilliantly sneaky there. And I guess we all have seen the boot screens on an Apple device.

44:17which goes nicely linearly and then typically before it's even completely done then suddenly it switches to okay it's on right and we've also seen the infuriating boot screen on a microsoft device where it goes and goes and goes and then it gets stuck at 99% and you wait for two minutes for the last percent to complete right so you might wonder you know how does apple do that right they After all, is there any secret magic? No, actually, they lie to you. The Microsoft boot screen is the truth. What Apple does is very cleverly, they measure the boot time that it took last time, and they add a tiny amount to it, and then they have a fake boot progress bar that's timed to go all the way to the end.

45:16within the time that it took last time to boot. So in other words, you get this very nice progress bar that is eye candy. It means absolutely nothing. It just indicates how long it took last time. You must have perfectly fine with it, right? So I don't know whether that is still the very implementation now, but it was the implementation for a long time. And this is a brilliant slate of hand where...

45:48I can create a very good user experience without having to solve an impossible technical problem, right? The other thing that you also need to do is you need to start actually defining benchmarks, like what makes for a good user experience for interaction, for voice, like, you know, is the model properly interruptible? Can the model recover properly from that, right? Does it...

46:16know that, for instance, in Japanese it's very common to say, so basically you're back channeling the other person and saying, hey, I got it. Yeah. Oh, that. Right. But if the agent stops for every one of those, that's going to be infuriating. Exactly. On the other hand, if that person were to say, well, I don't understand.

46:45You want the model to stop, right? So what that means is you need to make sure that the interoperability is really seen dependent. So for instance, we released a benchmark exactly on that papers. I think we put it up on Archive. A month ago, we looked at the level of productivity and interaction. So basically whether the model actually can pick up if there's something missing and where the model should also step in.

47:15Basically, you do need to do extra user experience engineering and benchmarks and measurements and optimization to really make the model work really well in this context. That's something that I think is quite different and new relative to what we had in text. To some extent, that's what AI for humans really means to optimize in a way that it's pleasant for humans. So this is a slightly different optimization track rather than models for code generation, right? They worry about task completion. In our case, we worry about human happiness. You know, you still need task completion and all of that, but you also want to make it enjoyable. What was the name of that benchmark? So Proact Bench is the one for productivity and then there's another one also by the same team.

48:15This is basically my Toronto team that has released it. If you look at my blog, there is a fairly detailed analysis and discussion, so IHBench, which explains exactly the various metrics that we use, how you then also go and make this nicely reproducible, TLDR, I mean, we do use third-party audio models in the defined benchmark.

48:45happens is you actually need to measure appropriately all the interruptability and responsiveness and whether, for instance, the audio matches what's being said. My favorite example is from the Hitchhiker's Guide to the Galaxy. I guess I'm showing my age here. There's the DBBC series. And they have this...

49:13notoriously cheerful computer on a spaceship. And there's a scene where the entire crew is about to die in two minutes because the spacecraft is going to crash into something. And the computer very cheerfully announces, you will crash in two minutes, we will all die.

49:38Of course, this is for comedic relief and spoiler alert, so they don't die in two minutes, obviously. That's an EQ point that you were mentioning earlier. Exactly. So what I'm trying to say is that for voice and then also for video, you need to really care about how humans feel rather than just doing text only. And I mean, yeah, you want models that are not as dumb as a brick, but There is a difference between IQ and EQ, and the latter is also important for humans. I was going to ask, there's quite a bit of research on EQ from a generic AI perspective, probably text-focused. But I'm imagining part of the through line in our conversation is that things are just different for text.

50:36The challenges tend to be more systematic as opposed to we're just going to solve this model and put a text for an end. There are a lot of moving pieces. I'm imagining that same thing is true for EQ. Solving EQ from a text perspective doesn't necessarily get you, you know, EQ voice AI. It will get you to parts of it because so from a text transcript, for instance, for interoperability, you can figure some things out, right? But then in some cases, it's also a matter of, you know, what's a good point of reference. So let me give you examples of terrible points of reference. So you could think about, you know, maybe movies are a really great source of how humans should interact with each other. Well, take the romantic comedies and usually, you know, the

51:36The obsessed guy who in the end gets the girl, essentially stalks her, right? If you did that in reality, the police would show up and lock you up, right? Likewise in some other movies, people are quite liberal with their fists or kicks or whatever, and in the end, they will kiss and make up, so to say, or be best friends again.

52:05Again, in reality, if you do this, you end up in jail. So it's very clear that a lot of social behavior in movies isn't quite so realistic. I mean, there are more realistic things in terms of talk shows and so on. But even there, I mean, I sincerely hope that nobody will train a model on Dr. Phil and assume that this is normal human behavior.

52:33I mean, you know, it's entertaining TV, but to make it very clear that you do need to, you know, be more careful in terms of, you know, how interactions should really work. The good thing is that LMS by now have a decent theory of the mind, so that gets you somewhere. And then, yeah, I mean, we're now entering, you know, the exciting new world where we can actually go and, you know, explore how humans really interact. We have to be very careful about it because, you know, ethics matter and you don't want to, you know, experiment on humans. But, you know, this is, I think, a really exciting time, at least not unless you do this appropriately. So I think it's a really exciting time of where this is going.

53:26And by that, you mean the technology is significant, you know, sufficiently far along enough that we can start putting in front of real people and engaging their reactions and that kind of thing. Is that where you are going? That is effectively, I think, what will happen where those models will get better by learning how to interact with humans. And yeah, I mean, this is, this is, this is an exciting new world.

53:55Yeah, and that makes me think of, you know, there's a lot of conversation right now about recursive self-improvement, right? And, you know, we, it's commonly discussed from the perspective of, you know, as the models that we use to build tools or to build things, you know, get better, you know, we can build more things, the models, you know, build better models, et cetera, et cetera. But is there an extent in which like the learning loop can become kind of continuous and the model can, you know, in a conversation, you know, learn what works for a particular person. Like that, I think that brings in a lot of things, this kind of self-improvement, like personalization. But it's something that I don't think we see very, you know, we don't see that in interactions today. This is starting, I would say.

54:48And you have a number of avenues. The closest thing I think we see is like memory in, you know, traditional LLM like. Okay, so let's actually go over a couple of pieces there. So the recursive self-improvement, it's cheap if you can do it in, you know, so to say, fully on a computer by just, you know, how interacting.

55:16let's say with an LLM that has a decent theory of the mind. So for instance, if I ask an LLM, well, what happened? Yeah, so like, and they use a simulator. So for instance, Nvidia did a great job at releasing some digital personas and some scenarios and so on. And we use that. And that, we also wrote papers about it. So it's no secret.

55:41What that does is it also allows us to build models that work well for humans that are not always cooperative, that are maybe a little bit abrasive, that are a little bit unpleasant to deal with, right? Because or people who might want to break the system, right? So, you know, no human is perfect and people will try to have fun with those things. But okay, so there's the, you know, Given that that does models when I have a decent idea of how humans work, you can use that for, you know, RSI to some extent. Another extent and direction though is in personalizing things. So for instance, knowing that Alex likes, you know, equations and facts and technical details and maybe

56:41maybe has a little bit of rough edges on the social side or whatever. These are things that I can use for personalization such that next time I interact with Alex, I can probably personalize better for him or knowing which devices I have, what my preferences are, what my language background is and all of that. This all can be used to improve.

57:10direct personalization by just having models reason over it in a similar way how for instance if you look at Hermes agent Which then you know looks at past interactions and past things that it's done and it reasons and it Commits that into memory. So think of this as a glorified CRM But now for everybody but at the same time you also want to learn across all the interactions. So for instance knowing that If I insult a user, the user will not take kindly to that. I mean, okay, sure, it's an egregious example and of course nobody would actually do that. But the point being, learning such things across is something that you can then overall use for an improved model. So you basically get global improvements. So it feels very similar to recommender systems just now in 2026.

58:06where you have an overall behavioral improvement, but you also have personalized improvement, the latter improving as the model gets to know more about, you know, let's say Sam or about Alex, but then overall the model getting better at dealing with those pesky humans or maybe dealing with those pesky humans in North America versus, you know, there's certain appropriate behavior in some parts of the world that's perfectly inappropriate elsewhere. So like eating with your left hand in India is seriously frowned upon because you use the right hand for eating and the left hand goes behind your back, right? So that or if somebody sees the bottom of your feet in Thailand, it's also not a good thing. But basically there's a lot of cultural weirdness.

59:08And, you know, weirdness that really matters for the people that, you know, live in that culture. And learning that will allow probably also to personalize a little bit better for, you know, specific regions, specific cultures. But then also for individuals within that culture and, you know, at the other end, you know, behavioral improvements for, you know, agents interacting with, you know, just those squishy humans.

59:39That I think is a really exciting future and By now we will be able to do this at a scale where we can actually build things rather than just positive theories, right? there's you know glorious work by say for instance if you look at Maya Matarich So she builds those robots that interact with babies and get babies to move their legs and whatever and it there's a lot of engineering and science brilliance in building this stuff. Brilliance is good, but brilliance is not repeatable and automatable. What I think the future is going to be is going to be systems that automatically learn this stuff, such that in the future you don't need quite as much brilliance anymore, and you can just let data speak.

1:00:42For movie recommendations, this is by now a solved problem mostly, but for overall human behavior interactions and improvement, I think even humans are not particularly good at it. If I was trying to aggravate somebody and to just harass them, a lot of people might at some point lose their cool and responding kind, right?

1:01:12Not all humans are nice. But for the purpose of achieving a given task for an agent, you actually want the agent to keep his cool and to handle this, right? And I mean, this is one thing when you watch school teachers and how great they are with kids and to get them to behave even though those kids are very uncooperative, maybe initially, right? There's a skill.

1:01:43Most humans don't have that. But we can learn those skills eventually with these agentic systems. I think this is an exciting world. Well, there's a bit of a paradox in that if most humans don't have them, they're not in the data, and therefore we won't be able to easily train models to follow those patterns.

1:02:10you get this interact, I mean, you get it from interactions, all right? And basically you can think of each interaction as another new experiment, a new data point. And so eventually, you know, by some randomness of exploration and so on, you'll be able to learn what works and what doesn't work. I mean, the question then is, you know, how you use that appropriately. But for instance, if you need to have a difficult conversation with somebody. I mean, the fun example is the millennial shit sandwich, right? Where you have praise, critique, and praise. And by doing that, you know, you can deliver the critique without people getting too upset, right?

1:03:14And this is a strategy of communication, right? Or when you learn how to become a manager, you take all those training courses. How do you deal with people who are happy, who are unhappy? How do you basically deal with people in a way that they can be productive, that they can enjoy? I mean, they are techniques.

1:03:45You know, these can be learned. They can be learned from instructions. You can take Chaldeany's books and they probably contain some good instructions, but we can also then eventually go and learn from data. This is I think really going to be quite an exciting revolution for the next maybe two to three years. I think it's going to move fast. Well, Alex, it's been wonderful to catch up with you and Get into a little bit of what you're seeing and working on with regards to voice AI. Thanks. Thanks for having me. Awesome. Thank you.