AI Engineer World's Fair 2025
From Self-driving to Autonomous Voice Agents — Brooke Hopkins, Coval
Read the talk
Building Reliable Voice Agents Through Simulation
Voice agents need more than a convincing demo: they need simulations, reusable metrics, and continuous evaluation that preserve autonomy while exposing failures.
From a talk by Brooke Hopkins
Before you start: Familiarity with LLM agents, tool calls, and basic software testing will help; no self-driving background is required.
Production trust without sacrificing autonomy
Why aren't voice agents everywhere? They promise to automate difficult workflows, yet trusting them with customer interactions remains a barrier. Brooke Hopkins, founder of Coval, approaches that problem through her experience leading Waymo's evaluation job infrastructure team. The mismatch starts with scope: teams overestimate agents when they attempt to automate every call or workflow at once, while underestimating the useful experiences they could already build around a smaller problem.
An agent can handle 10 conversations convincingly and still struggle across 10,000 or 100,000; Hopkins uses these counts to illustrate scale, not to report benchmark results. That gap leaves enterprises reluctant to move beyond proofs of concept, internal tools, or tightly controlled workflows.
Two familiar approaches appear to offer a tradeoff:
- Constrain the conversation. Force the agent down predetermined paths to make its behavior predictable. Taken far enough, this becomes an expensive interactive voice response tree with an LLM inside it.
- Allow autonomy. Let the agent adapt to unfamiliar situations, accepting that its interactions and actions become harder to predict.
Reliability and autonomy need not be mutually exclusive. Waymo provides Hopkins's motivating comparison: a system can respond to unfamiliar interactions while delivering a dependable experience. The engineering question is how to build confidence in that flexibility.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From road observations to aggregate simulation
Hopkins traces the self-driving evaluation process from manual observation toward large-scale simulation. Initially, teams drove cars through streets, noted failures, and brought those observations back to engineers. That produced useful evidence but was difficult to scale. Explicit scenario tests came next: construct a particular situation and specify what the vehicle should do. Those tests were more repeatable, but complicated scenarios and exact expectations were expensive to maintain and could quickly become obsolete.
The next step broadened the question from what must happen in one scripted instance to how often a type of event happens across many simulations. Aggregate evaluation characterizes behavior across varied runs instead of making every test depend on an exact sequence. This is the emphasis Hopkins brings from self-driving to voice; focused tests still have a role within that larger evaluation strategy.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Conversations need a responsive environment
Driving and conversation share a crucial property: each action affects what happens next. A car must respond to its environment, which continues changing as it moves. A conversational agent must respond to a person whose next answer depends on what the agent just said. Asking for a name produces a different continuation from asking for an email address. A useful simulation therefore needs an environment that responds to the agent's actual behavior.
A test that prescribes every conversational turn becomes fragile when the agent changes its wording or asks questions in a different order. Simulated users can instead generate varied responses as the conversation unfolds. Here, LLM nondeterminism becomes useful: it supplies variation across repeated interactions, helping explore possible continuations without writing each one by hand. The objective is broad coverage, not a claim that a finite simulation suite exhausts everything a caller might do.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure behavior without prescribing every answer
Repeated simulations let a team estimate how often its agent succeeds. That shifts evaluation beyond the familiar pattern of running fixed inputs through a prompt and comparing outputs against a golden dataset. In a conversation, enumerating every acceptable response to every possible input becomes cumbersome. Reference-free evaluation assesses behavior without requiring a reference answer for each turn.
| Evaluation approach | What it checks |
|---|---|
| Input-output evaluation | Correctness for specified inputs |
| Scripted scenario assertions | Expected events in a particular scenario |
| Reference-free conversational metrics | Behaviors across varied conversations |
Reusable criteria might ask whether the agent resolved the inquiry, repeated itself, or said something prohibited. These criteria still define what good behavior means; they simply avoid prescribing every intermediate response. Metrics that apply across many scenarios provide the basis for a continuous evaluation loop.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A local fix must survive broader regression tests
Without a repeatable process, maintaining a deployed voice agent can turn into an ongoing professional service: every enterprise needs another adjustment. Hopkins estimates that enterprise-specific tweaks can consume 80% of a team's time after initial setup when processes are inadequate; she supplies no study conditions for that estimate. The alternative is to make each fix pass through increasingly broad checks.
Consider a car that fails to stop at a stop sign. An engineer reproduces the problem, changes the system, and confirms that the car now stops. The focused test passes—but perhaps the change made the car stop every ten seconds. A larger regression suite reveals that the apparent fix damaged ordinary driving. Passing the reproducer establishes that the local symptom changed, not that the whole system improved.
The evaluation layers then extend through delivery and operation:
- Focused feature evaluations reproduce the bug and check the fix.
- Larger regression sets check for damage elsewhere.
- Pre-submit and post-submit CI/CD checks keep verification connected to code changes and deployment.
- Large-scale release evaluations assess readiness using automated tests, manual review, or both.
- Live monitoring and detection find production failures and feed them back into development.
Each layer answers a broader question than the one before it. Monitoring closes the loop by supplying new cases for future fixes and regression tests.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build metrics by reading conversations
The goal is not to automate every evaluation. Automated checks provide speed and scale; human reviewers handle judgments that need a human perspective. For an appointment-booking agent, begin with a happy path such as booking an appointment for tomorrow, then simulate that request repeatedly.
Read the resulting conversations before deciding what to measure. Identify how they fail, turn those failure modes into automated metrics, and iterate through simulation and evaluation. Once the agent is ready to deploy, run the evaluations again on production conversations. Flag cases for human review and return the findings to the simulation suite. The test collection grows from observed behavior rather than remaining a fixed checklist written before anyone used the product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Match simulation realism to the question
Does a simulated caller need to sound exactly like a real customer? That depends on the component being tested. As in an experiment, the task is to control variables and expose the behavior of interest. A driving simulation that looks like real video is not automatically the most useful test environment. For some decisions, the system only needs inputs identifying a dog, a cat, or a person crossing the street. Controlling those relevant inputs matters more than rendering every detail.
| Simulation level | Suitable questions |
|---|---|
| Text | Workflows, tool calls, instruction following |
| Simple voice | Interruptions, latency, instructed pauses |
| Realistic audio conditions | Accents, background noise, audio quality |
For workflow iteration, text is often the fastest and cheapest option. Basic voices can exercise timing and turn-taking behavior without recreating every caller's accent or acoustic environment. More realistic audio becomes necessary when those properties are the suspected cause of a production issue. Keep end-to-end voice tests, but avoid paying for full realism in every component test.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Denoise a failure by rerunning its scenario
One failed run tells you that a failure is possible. It does not tell you how frequently it occurs. Hopkins calls the next step denoising: take the failed scenario and simulate it repeatedly to estimate its failure frequency. Her example uses 100 reruns of the same scenario.
| Hypothetical failures in 100 reruns | Interpretation |
|---|---|
| 50 | Roughly coin-flip behavior |
| 99 | Near-consistent observed failure |
| 1 | A rarer observed failure |
These are illustrative outcomes, not experimental results. A 99-in-100 result does not prove that failure is certain, and a 1-in-100 result is acceptable only if the application's requirements permit it.
The bookkeeping can stay simple. This TypeScript function summarizes already-scored reruns of one scenario:
typescript
type RunResult = {
scenarioId: string;
failed: boolean;
};
function summarizeScenario(runs: readonly RunResult[]) {
const first = runs[0];
if (!first) throw new Error("At least one rerun is required");
if (runs.some(run => run.scenarioId !== first.scenarioId)) {
throw new Error("Summarize one scenario at a time");
}
const failures = runs.filter(run => run.failed).length;
return {
scenarioId: first.scenarioId,
runs: runs.length,
failures,
observedFailureRate: failures / runs.length,
};
}
The output is an observed fraction, not a guaranteed underlying probability. Hopkins invokes cloud infrastructure's six-nines reliability as a way to ask what level of reliability each part of a voice product needs—not as a result established by these reruns or a universal target for voice agents.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose metrics from the product's purpose
Evaluation design is product design. Choosing metrics means deciding what the agent must do well. General voice systems, including those available through OpenAI APIs, already cover broad conversational capabilities. A vertical agent needs more specific priorities: which tasks justify its existence, and which capabilities matter less?
- Refund support: A caller who wants a refund may tolerate some delay to obtain the outcome.
- Outbound sales: Latency can be critical because the recipient is ready to hang up.
- Appointment booking: Instruction following and complete information collection are essential; a booking without the required details is useless.
- Interviewing or therapy: Conversational workflows may deserve more emphasis than rigid task completion.
Interruptions deserve evaluation alongside latency. The relative importance of each behavior comes from the interaction the product is supposed to support.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Calibrate automated judges with human feedback
LLM-as-a-judge makes customer-specific evaluation criteria practical, but flexibility brings noise. Asking only “Was this conversation successful?” leaves success underspecified. Hopkins illustrates the problem by suggesting that judging the same conversation ten times may produce inconsistent answers. Before trusting an automated metric, make its judgments align with what human reviewers actually mean by success.
Hopkins presents Coval's Metric Studio as a way to iterate on automated metrics using human feedback. Review conversations, supply judgments, and refine the metric until its evaluations align with those judgments. She illustrates scaling from 10 or 100 human-labeled conversations to automated evaluation of 10,000 conversations; those counts are not a guarantee that a small labeled sample is sufficient.
The calibration effort should reflect the reliability the product needs. A team may begin with a small number of labeled conversations, while another application warrants much more work to establish agreement. The essential step is to set the desired reliability deliberately and use human feedback to improve the metric before relying on it at scale.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Benchmark components, then test the full system
Build the evaluation strategy in stages:
- Review public benchmarks. Use them for rough directional guidance about promising approaches.
- Benchmark on your own data. A medical application should test transcription methods on the medical terminology callers will actually use.
- Run task evaluations. Exercise individual modules or workflows, using text where appropriate. As with a car, testing one component does not require enabling every component.
- Run end-to-end evaluations. Exercise the complete system at scale under conditions resembling production.
This progression keeps early tests focused while still requiring the integrated system to demonstrate that its parts work together.
Hopkins describes Coval's work on continuous model benchmarking, then emphasizes custom comparisons. A voice that suits one kind of conversation may not suit another; an LLM that performs well on one task may be a poor fit for a different workflow. Benchmark the components of the voice stack against their intended use, then establish task-level baseline performance. That baseline makes the next development question concrete: where does the application work, where does it fail, and which component or workflow needs attention?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give production failures an owner and a test set
An evaluation process must specify what happens after a customer reports a production bug. Decide who owns the investigation, how the failure becomes a test case, and which regression sets should include it. Organize those sets around meaningful boundaries: important customers, customer types, workflows, or individual features. This gives a discovered failure a route back into routine verification.
Dashboards and recurring review processes make that structure useful over time. A successful customer pilot answers a question about the agent during that pilot. Continuous monitoring and evaluation answer the ongoing question of whether it still works as the product and its operating conditions change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Voice as an expected enterprise interface
Hopkins's closing platform thesis compares voice with the web and mobile. Each shift changes where companies can meet users and which interactions users expect to complete there. Natural voice interfaces could bring services into additional moments of daily life, though that does not make voice the right interface for every task.
She predicts that every enterprise will launch a voice experience within three years of the talk. Her analogy is an airline's mobile app: a good voice experience could become a baseline expectation rather than a novelty. That remains a forecast, but it explains the emphasis on sustained reliability. As users expect more from voice, a persuasive pilot will be insufficient. Hopkins presents integrated evaluation—and Coval's work on it—as the infrastructure needed to keep those experiences dependable as they grow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
- Waymo's SimulationCityArticle
Waymo explains how scenario variation, realistic behavior distributions and full-trip simulation complement focused tests.
- Confidence intervals for failure proportionsDocumentation
Statistical guidance for expressing uncertainty around observed failure rates, including small samples and rare failures.
Updates since the talk
Current guides for simulating conversations, monitoring production agents, incorporating human review and integrating evaluations into development.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hey everyone.
- 0:16
I'm Brooke. I'm the founder of Coval, and we are building evals for voice agents. So today, I'm gonna be talking a little bit about what can we learn from self-driving in building evals for voice agents.
- 0:27
My background is from Waymo, so I led our Eval Job Infrastructure team at Waymo that was responsible for our developer tools for launching and running simulations. And now we're taking a lot of the learnings from self-driving and robotics and applying them to voice agents.
- 0:41
Um, but first, why are voice agents not everywhere? They have this massive promise of being able to automate all of these really critical hard workflows autonomously. And I think probably a lot of you are building in voice agents and know how amazing voice agents can be.
- 0:56
Um, I think the biggest problem to v- launching voice agents is trust. So we simultaneously are paradox-paradoxically overestimating voice agents and trying to say, "I'm going to automate all of my call volume or all of my workflows with voice all at once."
- 1:13
And we're underestimating them. I think what they're capable of today and really scoping a smaller problem versus what they could possibly do in the next six months. I think there's just so much more that you could have for a magical voice experience.
- 1:28
Um, so conversational agents are so capable, but you also know that scaling to production is really hard. So it's easy to nail it for 10 conversations, but to do it for 10,000 or 100,000 becomes really difficult.
- 1:41
So a lot of times voice agents get stuck in POC hell, where enterprises are scared to actually deploy them to customer-facing issues or non-internal workflows.
- 1:52
So I think there's two approaches to deal with that today. There's conservative but deterministic, so you force the agent down a specific path and try and get it to do something exactly as you want it to do.
- 2:03
This is basically an expensive IVR tree. Um, you're using LLMs, but you're essentially forcing it into certain pathways. Or you can make them much more autonomous and flexible to new scenarios that they've never seen before, but this makes it really hard to scale it to production because they're so unpredictable, and so taking actions on behalf or interfacing
- 2:23
with users can be really, um, unpredictable. I think this is a false choice. I think you can have reliability and autonomy. So how many of you have taken a Waymo?
- 2:35
Yeah. If you haven't and you're from out of town, you sh- definitely should. It is so magical. So how did it become so magical? It's so reliable and y- also so smooth, but it's able to navigate all of these inter, um, interactions that it's never seen before, go down streets it's never seen before, and Waymo is launching
- 2:54
to all of these new cities, um, very quickly.
- 2:59
So I'm biased, but I think large scale simulation has been the huge unlock for self-driving and robotics because without it, you-- So we started in more manual evals. So, um, starting with like running the car throughout all the streets, noting where it doesn't go well, and then bringing that back to the engineers.
- 3:17
This obviously is very hard to scale, so then we created these specific tests where we're saying, "For this specific scenario, we expect these things to happen." Um, but this is very brittle.
- 3:27
Your scenarios tend to no longer be useful after a very short period of time, and they're very expensive to maintain because you have to build up these very complicated scenarios and then say exactly what should happen in those.
- 3:38
So then they move to-- The vi-- the industry as a whole has moved to large scale evaluation. So how often is a certain type of event happening across many, many simulations?
- 3:50
And so instead of trying to say, "For this specific instance, I want this to happen," you run large scale simulation to really reliably show how the agent is performing.
- 4:00
So I'm gonna talk through like some of the things that I've learned from self-driving and how they apply to voice. Um, and hopefully that will-- that's useful because it's definitely been useful for us as we interact with hundreds of voice, uh, systems.
- 4:12
So what is the similarity between the two? Self-driving and conversational evals are very similar because both of them are systems where you're interacting with the real world, and for each step that you take, you have to respond to the environment and go back and forth.
- 4:28
And so simulations are really important for this because for every step that I take in a Waymo or a self-driving car or a smaller robotics vehic-- um, device, or in a conversation, when I say, "H-hello, what's your name?"
- 4:43
You'll respond differently than when I say, "Hello, what's your email?" So being able to simulate all of these possible scenarios is really important because otherwise you have to create these static tests or do it manually, and both of which are either expensive or brittle.
- 4:57
Um, you also-- And so this makes for a very dur-- that doesn't make for very durable tests. If you have to specifically outline every single step along the way, those break immediately and are very expensive to maintain.
- 5:09
And then lastly, coverage. You really wanna simulate all of the possible scenarios across a very large area. And so the non-determinism of LLMs is actually really useful for this because you can show what are all the possible things that someone might respond back to this, and then we simulate that over and over and look for what the
- 5:27
probability of my agent succeeding is. Another thing that I touched on a bit is input-output evals versus probabilistic evals. So with LLMs to date, we have seen you run a set of inputs for your prompt. [clears throat]
- 5:45
Excuse me. You run a set of inputs for your prompt, and then you look at all the outputs and evaluate whether or not the output for that input was correct based on some criteria.
- 5:54
So you might have a golden data set that you're iterating against. With conversational evals, it becomes even more important to have reference-free evaluation, where you don't necessarily need to say, "These are all of the expected things I s- want, am expecting for this exact input."
- 6:10
But rather you're defining as a whole, how often is my agent resolving the user inquiry? How often is my agent repeating itself over and over? How often is my agent saying things it shouldn't?
- 6:21
Um, rather than saying for this specific scenario, these six things should happen. Um, and so this is what's going to really allow you to scale your evals, and also what we did at Waymo.
- 6:31
So coming up with metrics that are, uh, apply to lots of scenarios. Another thing is that constant eval loops are what made autonomous vehicles scalable, and that's what's going to make, um, voice agents scalable.
- 6:44
I think we're seeing today that voice agents are so expensive to maintain in production. Once you deploy to an enterprise, it becomes often a professional service if you don't set up your processes right.
- 6:55
And so you're constantly making all of these tweaks for specific enterprises, which can take up eighty percent of your time even after you've set up the initial agent. So something that the autonomous vehicle industry has been doing is, how do you run-- Like, let's say you find a bug, and as an engineer, I might iterate on that,
- 7:13
and I run a couple of evals to reproduce that, and then I fix the issue, and then I run more. So it wasn't stopping at a stop sign. I iterate on that, and now it is stopping at a stop sign.
- 7:23
But then I li- run a larger regression set because maybe I just made the car stop every ten seconds, and so I broke the everything. Um, so then you run a larger regression set and make sure you didn't break everything.
- 7:34
And then we have a set of, um, pre-submit and post-submit CI/CD workflows so that before you ship code and then after you, um, you push the code to production, we make sure everything is continuously working.
- 7:45
And then there's large-scale release evals, so making sure that everything is up to par before we launch a new release. And this might be both manual evals and automated evals and some combination thereof.
- 7:57
And then live monitoring and detection, um, which then you can, uh, feed back into this whole system.
- 8:05
So we're emulating a lot of this with voice. I think we think that's the right, uh, approach as well. But you're-- Notably that there's still manual evals involved. The goal is not to automate all evals, but rather to leverage auto evals for speed and scale, and then use the manual time that you have to really focus on
- 8:26
how, um, those like very h- you know, human touch judgment calls. Um, so the process that we've seen is you might start with simulated conversations, and you run some happy paths of like, "I know I should be able to book an appointment."
- 8:39
Um, so book an appointment for tomorrow. I run a bunch of simulations of that. I run evals. I come up with metrics of-- I look through all those conversations.
- 8:47
Looking at your data is super important. Um, I look at all those conversations and I say, "These are the ways they're failing." So I set up some automated metrics and iterate through this loop several times.
- 8:57
Now I think it's ready for production, so I ship it to production and then run those evals again. And so this cycle, this virtuous cycle of iterating on through simulation and then detecting or like flagging things for human review and then feeding all of that back into your simulations is super important for scalable voice agents.
- 9:18
Um, so what level of realism is actually needed?
- 9:23
Uh, something-- A question we get a lot is, "How are your voi- are your voice agents exactly how my customers sound?" And that's a good question because the level of realism is dependent on what you're trying to test.
- 9:35
So like any scientific method, right? You're trying to control variables and then test for the things that you care about. So there's-- Something we saw in self-driving is that there's kind of this hierarchy of like you might not need to simulate everything in order to get a representative feedback on how your system is doing.
- 9:53
Um, so the way we think-- So for example, all the time there are all these, you know, super hyper-realistic simulations coming out that look like a r- you know, that look like a real video.
- 10:04
And people would say, "That simulation system is amazing." And really, that's not necessarily true because what you want from a simulation system is how much can you control what parts of the system you're simulating, and then how-- like what inputs are needed.
- 10:18
So you might just need to know this is a dog and I-- this is a cat and this is a person walking across the street. Um, and then what should I do next as a result of those inputs?
- 10:28
And so this is the same for voice. We think about it as, uh, for example, workflows, tool calls, instruction following. You actually don't need to even simulate that with vo-voice often.
- 10:37
You might wanna do end-to-end tests with voice, but when you're iterating, doing that all with text is probably the fastest and cheapest way to do that. Um, then for interruptions or latency or instructed pauses, um, simple voices that are just the bas-basic voices are sufficient because you're doing that voice-to-voice testing.
- 10:57
But, you know, accents or background noises might not im-impact that as much. And then where you need hyper-realistic voices of different accents, different background noises, different audio quality, et cetera, is when you're testing those things in production and trying to recreate those issues.
- 11:13
And so thinking about what c- what are the base level of components that you really need to, to develop this is super important for, um, for building a good eval strategy.
- 11:26
Uh, and then an awesome tactic that we've learned is denoising. So, um, you run a bunch of evals, and then you might find one that failed. And something that's really important about agents is that it doesn't-- it's not the end of the world maybe if it fails one time.
- 11:41
You really wanna know what is the probability of this failing overall. So then you can find that scenario and then resimulate that, and maybe you resimulate that 100 times.
- 11:51
So is this scenario failing 50 out of 100 times? Is it a coin flip? Is it failing 99 out of 100 p- times, which it means it's definitely always failing?
- 12:00
Um, or does it fail once out of 100 times? And that might be totally okay for your application. Um, and so having a sense in the same way of cloud infrastructure, where are you shooting for six nines of reliability?
- 12:11
For voice AI, that's really important as well as like what reliability are you looking for for different parts of your product?
- 12:18
So now I wanna talk a bit about how to build an eval strategy, because we believe that evals are as an important part of your process. Uh, it's the key part of your product development, and it's not just an engineering best practice.
- 12:30
This is actually like a core part of thinking through what does your product do.
- 12:35
So voice AI-- Like thinking through what metrics you should use is thinking through what does your product do and what do you wanna be good at. You can build a general voice model that's kind of good at everything, and that already exists, right?
- 12:47
Like, you can use the OpenAI APIs. You can use, like, all of these different end-to-end, um, voice systems that already exist that-- and are generally useful. But really, you're probably building a vertical agent that you're trying to make useful at something in particular.
- 13:02
And so thinking about what you want it to do well and what you don't care if it does is a really important part of the process. Um, and it's not just about latency.
- 13:09
It's about interruptions. Like, your voice application actually might not be so latency sensitive because someone really wants a refund. But if you're doing outbound sales, latency is super important because that person's about to hang up the phone.
- 13:22
Um, interruptions, uh, workflows. Workflows, like how much you adhere to instruction following for some applications is really important. Like, if you're booking an appointment and don't get all the details, it's useless.
- 13:34
But if you're, you know, an interviewer or a therapist, you might be more tuned for conversational evals-- uh, conversational workflows.
- 13:44
And then, um, so really thinking through like what you're trying to measure. These are the five things w- that we see the most, but, um, LLM-as-a-judge is a really powerful way of being really flexible, and you can build out evals that are very specific for different customers.
- 13:59
But something we get a lot is how you trust LLM as a judge. It's this magical thing that can be so flexible to so many cases, and also it is very, um, you know, can be very noisy.
- 14:10
But I think the common patterns that we see with LLM as a judge is that you say, "Was this conversation successful?" That's a pretty-- That's going to be a really noisy metric.
- 14:19
Um, you might run that 10 times for the same conversation and it'll come back, um, with lots of different responses. So in Coval, we have this Metric Studio that we think is really, like, um, pretty different from anything out there because it allows you to iterate on this human-- incorporate human feedback into really correlate-- calibrating your metrics
- 14:39
with human feedback. So you can iterate over and over until your automated metrics are aligning with human feedback, and now you have the confidence to go deploy those in production and run them over ten thousand conversations instead of the hundred that you labeled or the ten that you labeled, um, to, to get that confidence.
- 14:57
So really, I think set-- putting in the time to saying, "This is the level of reliability that we're looking for," and being thoughtful of that, maybe just labeling ten conversations is important to you.
- 15:08
Wha-- Um, or maybe you really wanna dial this in. Um, but using this workflow can be really powerful.
- 15:16
Uh, our other advice of how to approach evals for voice AI is starting with this system of reviewing public benchmarks, which can be a rough dial of this is how, um, this is roughly the direction I wanna go in.
- 15:29
Then benchmarking with your own specific data. So using-- If you're like a medical company, using medical terms that you're going to be using in production to test out different transcription methods, um, et cetera.
- 15:41
Then running task-based evals, which are maybe text or very specific, um, smaller modules of your system. Again, what I talked about in self-driving is you don't necessarily need to enable every module on the car in order to test the one thing that you're trying to test.
- 15:54
And then end-to-end evals, where you're running everything at scale and pr-- um, and how it would run in production.
- 16:01
So we've done a lot of benchmarking. You should check out our benchmarking, um, on our t-t-- uh, on our website. But we try to do continuous benchmarking of what are the latest models out there.
- 16:12
But doing your own custom benchmarking is also really important. So through Coval, you can actually-- And you can also do this yourself. I just happen to have a tool that does this.
- 16:21
Um, but you can like run on your specific data because you might prefer different voices for the types of conversations that you're having, or you might h- prefer different LLMs based on your specific tasks.
- 16:33
Um, and so benchmarking each part of your voice stack is really helpful for choosing out those models, especially because voice has so many models. And then, um, building out your task evals, so starting to get a sense of baseline performance.
- 16:47
Where are the problem areas in your voice AI application? Where are things working? Where could they be better?
- 16:53
Um, and then creating an eval process. So this means like what kinds of continuous monitoring are we doing? What do we do when we find a bug in production from a customer?
- 17:02
Who takes it and where do-- what test sets does it go into, so we can make sure that it doesn't happen again? How do we set up our hierarchy of test sets?
- 17:09
Do we have test sets for specific customers that we care a lot about? Do we have types of customers that we have? Um, do we have specific workflows or features of our voice agent?
- 17:18
Um, and then creating dashboards and processes so that you can check in on those things continuously. I think this is an underestimated piece of the process is like what is our continuous eval process versus just saying, "Does the voice agent work when I deploy it to this production-- this, uh, uh, customer on their-- during their pilot period?"
- 17:38
Um, so yeah, always happy to talk more about tips on like what we've seen across all of the many voice systems that we've seen. But one of the reasons why we're so excited about the future of voice, and I think Quinn, um, uh, stole a little bit of this.
- 17:54
But [laughs] Quinn, I really think that voice is the next platform. Um, so we had web, we had mobile, and I think both of these were huge platform shifts in what types of things do you expect that companies will allow you to do on those platforms?
- 18:08
What types of work-- Where in the workflow, where in your daily live-life are you meeting the user? And I think voice is unlocking all of these new, really natural voice experiences.
- 18:18
It doesn't mean everything you should be doing via voice, but there is really exciting potential there.
- 18:25
And in the next three years, we think every enterprise is going to launch a voice experience. It's going to be like a mobile app where if the airline does not have a good voice experience, it's going to be like not having a good mobile app, and it will just be a, a baseline expectation.
- 18:40
And I think users' expectations of what really amazing, magical voice AI experiences will be is just going to increase over, um, over the next few years.
- 18:51
So we really wanna enable this future, and so we think the next gen of scalable voice AI will be built with integrated evals using Coval.
- 19:01
And we're hiring, so we're always looking for people to join us. I think this is like s- really one of the most technically interesting fields that I have ever worked in because you get to work with every model across the stack, and there are so many different types of models, different types of problems, scalability, new frontiers of
- 19:19
building infrastructure, and no one knows any of the answers. So it's a really exciting space. Thanks so much, everyone. [upbeat music]