AI Engineer World's Fair 2025
Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work
Read the talk
Engineering Evaluation Pipelines That Improve the System—and the Judge
Scalable evaluation combines traces, human labels, model judgments and code checks, then uses that signal to improve applications, diagnose agent paths and refine the evaluators themselves.
From a talk by Dat Ngo and Aman Khan
Before you start: Familiarity with LLM calls, retrieval-augmented generation and basic Python will help; traces, evaluation scopes and agent trajectories are explained as they arise.
When every trace needs many evaluations
What happens when a production application needs many evaluations for every trace? Dat Ngo introduces the problem from his work as an AI architect at Arize AI, observing teams such as Reddit and Duolingo. Dat reports that Duolingo runs about 20 evaluations per trace. In that example, running evaluations, understanding their results and optimizing their cost are substantial operational concerns; he does not specify the workload, sampling policy or evaluator mix.
That scale changes the engineering question. An evaluation pipeline must produce useful signals repeatedly and economically, while giving the people building the application enough visibility to act on them. Dat approaches this as an engineer working on observability and evaluations, rather than as a developer advocate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Observe the application at the level your team owns
Observability answers what the application is actually doing. Engineers may inspect traces and spans; an AI product manager may inspect conversations. Those are different views of the same application, and evaluations can operate at the conversation level as well as on individual calls.
Analytics also reflects organizational ownership. Dat describes a hub-and-spoke structure: a central LLM platform team owns infrastructure, including the model gateway or router, while business teams build applications around it.
| Team | Typical responsibility | Main signals |
|---|---|---|
| Central platform | Infrastructure and model gateway | Cost and latency |
| Business application | Application behavior and user experience | Task-specific evaluation results |
The dashboard brings these concerns together, but the people using it need different views and different definitions of success.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose the cheapest method that captures the signal
Nobody can manually inspect every production trace. Evaluations turn that volume of activity into signals about what is going well and what is failing. An LLM judge is one way to produce those signals, but it is not the whole toolbox.
Consider retrieval-augmented generation: a user asks a question, the application retrieves context, and a model generates an answer. Each relationship offers something to evaluate. Retrieval relevance, for example, compares the retrieved context with the original query: would this material help answer that question? This isolates a retrieval problem before treating the final answer as one undifferentiated success or failure.
Judging an answer is also a different task from generating it. Writing a summary of War and Peace requires producing the summary; assessing an existing summary asks whether that candidate is good or bad. That distinction helps explain why an LLM can be useful as a judge without making its judgments automatically trustworthy.
Autoregressive generation is not required for every evaluation. Dat describes encoder-only BERT-type evaluators as about 10 times cheaper and 10–100 times faster than the larger-model alternative. He supplies no task, comparison model, hardware or quality threshold for those estimates, so they motivate testing a smaller evaluator rather than predicting its performance on a particular workload.
Human feedback supplies another kind of signal. Users can report whether an interaction was helpful, and developers or domain experts can label examples themselves. A golden dataset collects judgments the team trusts. Automated judges supply scale; human-graded examples provide a quality reference.
To connect the two, run the LLM judge on that golden dataset and compare its labels with the trusted labels. The question becomes concrete: can this evaluator approximate the judgments the team expects? Disagreements give you evidence for quantifying and tuning the judge, rather than accepting its first prompt as a reliable measuring instrument.
Some questions need neither a model nor a human. In the code-evaluation demonstration, Dat checks properties such as keyword containment, regex matching and whether an output parses as JSON. These are deterministic requirements, so ordinary code can capture the signal directly. A Python implementation of those checks looks like this:
python
import json
import re
def evaluate_output(text: str) -> dict[str, bool]:
try:
json.loads(text)
parses_as_json = True
except json.JSONDecodeError:
parses_as_json = False
return {
"contains_hotel": "hotel" in text.casefold(),
"has_booking_id": bool(re.search(r"\bBK-\d{4}\b", text)),
"parses_as_json": parses_as_json,
}
output = '{"hotel": "Harbor Inn", "booking_id": "BK-1042"}'
scores = evaluate_output(output)
These checks establish syntax and string properties, not whether the hotel exists or the booking is correct. Choose code, human labels or a model according to the question the evaluator must answer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Improve the application and the evaluator separately
The application-improvement loop is familiar:
- Collect traces and other observations.
- Run evaluations to locate successes and failures.
- Inspect failures to identify causes—for example, a hallucinated answer caused by a faulty retrieval strategy or agent behavior.
- Annotate examples to check the evaluation results.
- Change the prompt, model or agent orchestration, then repeat.
The evaluation is the instrument that tells you where to intervene.
The instrument needs its own improvement loop. A judge may flag a correct answer as a hallucination, or approve an answer that is wrong. Periodically annotate evaluated examples, collect those mistaken judgments, and revise the evaluation prompt. Instructions that initially seemed adequate may turn out to be vague, obscure or insufficiently specific as the application changes.
These loops reinforce each other: better evaluations make application changes easier to assess, and new application behavior exposes weaknesses in the evaluations. Dat emphasizes iteration speed, contrasting four cycles in a month with two. His description of exponential improvement is an argument for faster learning, not a measured growth rate.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate the component, workflow, route and session
Evaluation structure should follow application structure. Dat uses Booking.com’s Trip Planner as a travel-agent example, describing it as revenue-driving and discussing flights, hotels and itineraries. A routed application consists of multiple components, so its evaluation can be as complex as its orchestration.
Start with an individual component, such as one LLM call inside a trace. Then zoom out to the inputs and outputs of a whole workflow. In Dat’s travel example, that workflow combines LLM calls, API calls to find actual flights or hotel vacancies, and heuristics. The accompanying slide illustrates component composition with a separate Chat-to-Purchase Router: product comparison, product search, customer support and package tracking branches combine LLM calls, internal API calls and application code.
Check control flow before spending money evaluating its consequences. If the router sent a request down the wrong branch, downstream quality scores may add little diagnostic value. Conditional evaluation can first judge the routing decision and skip downstream checks when that decision fails. This makes the evaluator’s execution order reflect dependencies in the application.
Zoom out again and a session becomes a series of traces representing a back-and-forth conversation. A session-level evaluator can ask whether the customer became frustrated at any point, even when no single call captures the whole experience. There is no universal evaluation recipe: Dat recommends customizing evaluators heavily and first understanding how the application works.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find failure modes across agent paths
Arize’s Copilot provides a concrete example of an agent built to observe, troubleshoot and create evaluations for other AI systems. Dat says it had been available for a year at the time of the talk. He frames it as an early step toward a future, five to ten years out, in which AI systems perform more of the work of evaluating other AI systems.
The demonstration moves into agent traces, which grow longer as agent calls become more involved. Dat opens a failed trace and explains how Copilot chooses specialized agents based on the user’s request and their current location in the platform. Each agent has its own set of tools. A trace lets an engineer inspect what happened in one execution, but the operational question is broader: which failure modes recur across the agent’s executions?
For an agent with ten available tools, useful questions include how often it calls each tool and how evaluation results vary by path. The aggregate agent graph is described as framework-agnostic, covering LangGraph, CrewAI and hand-written orchestration. Its purpose is to connect path frequency and path-specific evaluation results across many traces.
Dat’s dependency example makes the value concrete:
| Observed path | Evaluation pattern | Explanation |
|---|---|---|
1 → 2 → 3 | Looks good | Successful path in the example |
4 → 2 → 3 | Scores drop | Component 4 needs component 3 first |
The second path eventually reaches component 3, but too late to satisfy component 4’s dependency. Looking across executions exposes an ordering problem that a single overall good-or-bad score would obscure. The target is the distribution of behavior, not just one instantiation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compare what the agent did with the path it needed
A trajectory evaluation starts with a particular request and the components the agent should visit. For a Trip Planner hotel request, that might begin with a start agent followed by a tool agent. A golden trajectory dataset can record the expected path, or the three or four components an example must reach.
There are two straightforward ways to use that reference: give an LLM the actual and expected trajectories and ask it to grade the difference, or compare trajectory strings directly. The demonstrated strict comparison shows different actual and reference step sequences and returns False.
Exact sequence equality and required-step coverage answer different questions. For a simplified hotel request, this Python example makes the difference explicit:
python
request = "Find me hotels."
reference = ["start_agent", "tool_agent"]
actual = ["tool_agent", "start_agent"]
scores = {
"strict_match": actual == reference,
"required_steps_present": set(reference).issubset(actual),
}
# {"strict_match": False, "required_steps_present": True}
Both steps are present, but their order is wrong relative to the reference. Choose the comparison that expresses the application’s requirement; a presence check cannot enforce ordering.
An exact ground-truth path is not always necessary. Dat suggests judging whether the visited nodes and their descriptions match the expected process. He also describes an exploratory approach: provide the actual trajectory alongside possible paths, represented as nested key-value pairs, and ask a model to assess it. These alternatives move from literal sequence matching toward judging whether the path fulfills the intended process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put checks in the execution path deliberately
The first audience question turns from after-the-fact evaluation toward checks that can affect the current interaction. Dat prefers in orchestration versus out of orchestration to the less precise distinction between online and offline evaluation. An inline check can decide whether execution may continue; that makes it a guardrail, and puts its latency in the user’s path.
Think of two interacting systems. System one is the application: prompts, orchestration and other behavior. System two is the guardrail that checks it. The guardrail mitigates risk but adds work. Dat describes embedding-based guardrails as roughly 100 times lower-latency, without specifying the comparison system or benchmark conditions. A faster check can reduce the latency cost, but the second system still adds complexity.
When the guardrail repeatedly catches a problem, the first repair should often be in system one. Adjust the prompt or orchestration that produces the failure rather than immediately changing the protective check. Guardrails are fallible and resemble unit tests for known cases; observability and evaluations help discover behavior that was not anticipated before real users arrived.
The placement decision therefore depends on the application. An inline evaluator can prevent a bad continuation, while an evaluator outside orchestration can generate improvement signals without blocking the current response. Neither placement is universally correct; the question is which checks must influence execution now and which can inform the next iteration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Carry trace context across service boundaries
A second question asks how to evaluate a complex, long-running asynchronous system when spans, timeouts and service boundaries limit the view. Dat points to OpenTelemetry context propagation. As LLM applications spread across services, Docker containers and Kubernetes pods, observing one process is no longer enough.
His example follows application A → model router → application A → application B → application A. Propagating trace context lets those service-level observations remain connected, so the engineer can inspect the complete operation instead of disconnected fragments. That requires instrumentation to carry the context, or explicit injection and extraction where automatic propagation is unavailable.
Dat says Arize committed to an OpenTelemetry-first approach two and a half years earlier. The answer addresses cross-service visibility: propagation preserves the relationship between work performed in different places. It does not itself define timeout policy or determine when an asynchronous workflow is complete.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Treat evaluator confidence as another signal
Asked how to obtain a confidence score for an evaluation, Dat starts with autoregressive judges. If the evaluator returns a single-token label and the provider exposes that token’s log probability, the value offers a pseudo-confidence signal. He names OpenAI as one provider with this capability; the OpenAI logprobs example documents the historical approach and is now archived, so availability must be checked for the chosen model and endpoint.
A token’s log probability measures how likely that token is under the model’s context. It is not a calibrated probability that the evaluation is correct. Encoder-only classifiers can instead expose classification probabilities. Dat recommends using these signals together with the rest of the evaluation toolbox to understand where the system is doing well or badly.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Shorten the loop from feedback to a revised prompt
The final question asks how to reduce developer intervention between customer feedback and prompt improvement. Dat points to DSPy and its MIPRO optimizer. He illustrates the idea with roughly 30 input-output pairs and describes the goal as less fragile prompts across models from providers such as OpenAI and Google, including Gemini. The example count is illustrative, not a fixed requirement or a guarantee of transfer across models; current MIPROv2 uses configurable datasets and a task metric.
Dat then describes Arize’s meta-prompting approach, with prompt optimization available or being released at the time. The mechanism is to give an LLM the evidence needed to propose a repair:
- Supply the original prompt.
- Include a dataset of input-output pairs.
- Attach evaluation results showing successes and failures.
- Ask for a revised prompt that addresses the observed failures.
The output is a proposed prompt revision. This automates part of the improvement loop by turning examples and evaluation signals into a concrete change, rather than leaving a developer to translate every failure into new instructions manually.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
How trace context crosses service boundaries through injection and extraction, including custom propagation.
The original announcement describes conversational destination, accommodation and itinerary planning and the initial US beta.
Further reading
The original MIPRO paper explains how to optimize instructions and few-shot demonstrations across a multi-stage language-model program.
An archived OpenAI example demonstrating token log probabilities and classification thresholds in Chat Completions.
Updates since the talk
API reference and examples for optimizing DSPy programs with task metrics, training examples and Bayesian search.
June 2025 announcements covering Alyx, agent graphs, session and trajectory evaluation, and prompt optimization.
Read the complete timestamped transcript
- 0:00
[upbeat music] All right.
- 0:15
Well, let's get started. Uh, we don't have much time, but, um, I hope your conference is going well. Uh, welcome to AI Engineering World Fair. Uh, my name is Dat Ngo.
- 0:24
Uh, today's talk is about LLM Eval Pipelines. Um, so I never know what I wanna talk about till I get into the room, so I don't prep too hard.
- 0:31
But by show of hands, who here, uh, who here has built, uh, an agent? Just raise your hand. Okay. Uh, who here, um, has run an eval?
- 0:42
Right. Who here has productionized an AI product? Nice. Okay. Some technical builders. Um, let's get technical then. So, uh, my name is, uh, Dat. Um, I'm an AI architect at Arize AI.
- 0:56
Um, this is Mochi and Lati- uh, Latte. They're, uh, dogs of my friends. I figured let's, let's keep it spicy and interesting. Um, but I've been building observability and evals since, since day zero.
- 1:07
So, uh, since the first... Uh, I don't know if you guys know what Arize AI is, but we are the largest, uh, AI evals player, uh, in the space, so observability, evals, kinda beyond.
- 1:18
Uh, we work really heavily, uh, with, with real use cases, so folks like Reddit, folks like Duolingo. Um, so we work across the best AI teams, and we have a really unique business.
- 1:29
Being on the observability side, we get to see what everyone is building,
- 1:34
how they're tackling those problems, what are their biggest pains, uh, and what are the kind of the tips and tricks that they use to, to really productionize these things.
- 1:41
And just to give you a s- a hint, um, you know, Duolingo has massive eval scale. They tend to run about twenty evals por- per, like, um, trace. Um, so they end up spending, you know, quite a fair amount, uh, doing evals, understanding their evals, optimizing them.
- 1:57
Uh, and the last thing about me, I have a huge passion for the AI community. Um, when I was in SF the last five years, uh, really loved to go to pretty much every single event that I could.
- 2:05
Uh, I'm not a developer advocate. I'm an engineering-- uh, an engineer by, by trade, but I just love the community. So, um, yeah, this is a little bit about Arize, but I think I don't wanna keep it too salesy.
- 2:15
I just wanna keep it pretty technical. So really three concepts that I think everybody should be familiar with and where evals really sit in the space is, is really as simple as this.
- 2:24
Um, this is what I teach all my customers. Really, the first thing is observability. I think you guys have kind of seen this before. Observability really just answers the question of, what is the thing that I built actually doing, right?
- 2:35
To some people, it may be traces, uh, traces and, and spans. Um, I'll show you a little bit. Um, it, you know... Platform agnostic, just, just think about the concepts.
- 2:45
Um, but traces might be one, one area for people. So traces represent, hey, what's happening? Can I look at things? Uh, to an AI engineer, makes a lot of sense.
- 2:54
Um, let's say you're an AIPM, maybe not super technical, or maybe, uh, you wanna think about things differently. Maybe you wanna look at, hey, what are the conversations that are happening?
- 3:03
Turns out you can run evals at these levels. Uh, we'll get into that in depth kind of later. Um, you know, signal comes and observability comes in different kind of flavors and forms.
- 3:12
Maybe it's, it's analytics. Uh, what we're starting to really realize is that LLM teams are getting split into two special niches. There's platform teams, right? And they, they own things like the, the infrastructure.
- 3:25
So who here has heard of a, a model gateway router? Uh, it's like an interface pattern. Behind it are all the models, right? Well, it turns out the central LLM platform team tends to own that.
- 3:34
They care about cost, latency, things like that. And then you have the other LLM teams. These t- these LLM teams sin- team, uh, sit on the, like, the outer side of the business, so like a hub and spoke.
- 3:45
They work for the business side. So these are like, uh, the people building the applications to help the business. So, um, if anyone here comes from, like, the, the ML or, or data science space, it's actually not far from that.
- 3:56
Um, and so different teams care about different metrics. Uh, so maybe if you're an AIPM sitting on the business side, you care about evals. If you care about, you know, the platform, maybe you care about costs, latency, things like that.
- 4:08
But TLDR, uh, observability... Oops. Uh, observability, um, represents what's happening. And now evals are really important in this space because the reality of the fact is, if you've ever seen a trace or something like that, um, you're not gonna inspect every single trace manually, right?
- 4:26
It is not scalable for you, an AI engineer, or you, the AIPM, to look through these things. So what is eval's use for? It's actually just a really clever word for signal.
- 4:36
You're just trying to understand what's going well and what's not going well. So I'm not here to sell you on, like, evals. I think everybody knows how important they are.
- 4:43
But if you think evals, evals are LLM-as-a-Judge only, uh, there's actually a lot of other tools that you're missing. So LLM-as-a-Judge, raise your hand if you used LLM-as-a-Judge. Okay, about half the room.
- 4:55
Um, it's super great. Uh, you use an LLM to give you feedback or process on, on any process, including an LLM process. So if you're doing RAG, this is a really good way to, to think about RAG in terms of evals.
- 5:07
Um, RAG would be like, hey, user has a question. Um, we retrieve some context to be able to, you know, possibly answer that question, and then we generate an answer.
- 5:17
Turns out every arrow on this is actually an eval you can run. So, hey, I retrieved some context, and I wanna compare that to the query being asked. Well, that's RAG relevance.
- 5:26
It's like, is the thing that I returned even helpful in answering the question? And so LLM-as-a-Judge is great. It's super helpful. Um, you know, I think most people understand why it works, but there's a whole, there's a whole research area on why they're really good indicators.
- 5:41
Um, the original task is not the eval task, right? So if I asked you, a human, "Hey, generate me a summary on, uh, something long and complex, like the book War and Peace," uh, that's a very different task than say, "Hey, I wrote this summary for you.
- 5:56
Is it a good one or is it a bad one?" But LLM-as-a-Judge is, is a small part. Um, it doesn't always have to be a large language model or autoregressive model.
- 6:05
Um, things like encoder-only BERT-type architectures are super helpful. They're about ten times cheaper, um, about one or two orders of magnitudes faster, uh, to run that eval. But, you know, you don't just have LLMs at your disposal.
- 6:20
You, a human, also are a really good way to discern signal. So it turns out evals can also come in the form of, is your user having a good or bad experience?
- 6:27
So for those people who've productionized, uh, some sort of LLM application, do you guys have user feedback? Raise your hand if you've implemented user feedback. And okay, about thirty percent.
- 6:37
Uh, it's actually incredible signal. Um, so that comes from a human. Obviously, you yourself can also generate labels on stuff. So has anyone here heard of a, a golden dataset?
- 6:46
Raise your hand. Okay, most of the room.
- 6:50
Um, and the way I encourage folks to think about this is a pro tip, actually. If the first column represents scale... So LLM-as-a-Judge is valuable because I don't have to grade it myself, right?
- 7:00
But let's say I don't necessarily trust it off the bat. Use the third column to help you out. So a golden dataset represents quality. So you yourself graded it.
- 7:09
You know that it's, it's what you expected, you know. Um, well, it turns out you can run your LLM-as-a-Judge on a golden dataset. Um, what you're trying to do is say, "Hey, can the LLM approximate the thing that I trust?"
- 7:21
Right? And what that allows you to do is to actually quantify and tune your LLM-as-a-Judge. So we'll go over that in a second. But strong pro tip, uh, most really strong LLM teams in the world kind of do this today.
- 7:33
Uh, and it turns out you don't always have to use an, an LLM, uh, or a human. You can use what are called, like, heuristics or code-based logic. So I'm gonna take you into the platform a little bit to talk through it.
- 7:42
But, um, in our platform, you have a way to, to run evals, great. Uh, what code evals actually are, um, are just, um... it's much cheaper, so I'll just run a little test here.
- 7:53
But, you know, let's say you wanna say, "Hey, does this output contain any keywords?" I don't need to use an LLM or a human for that. I can just use code.
- 8:01
It's infinitely cheaper, um, faster to run. Um, does this match this regex pattern XYZ? Is this a parsable JSON? So the reality of it is you have this kind of, uh, large toolbox in your kind of, uh, eval set.
- 8:15
So when you say evals, don't just think of LLM-as-a-Judge. There's a whole other set of smarter things that you can use that are actually more cost-effective. And so really, you know, this is a really good way to, to emphasize really the value of, like, the AI engineer evals and observability.
- 8:31
Most people understand this, this left-hand circle, this purple one. Um, it actually represents what we all wanna do, and it's like, hey, build a better AI system, right? So what you do is you collect data, observability, traces, things like that.
- 8:43
Then you run some evals to say, "Hey, did this process go well, or did this process not go well?" So you're discerning signal from that, you know, mass of data.
- 8:52
You'll actually collect where areas of things went right or wrong, right? And you'll say, "Hey, turns out we hallucinated on this. It's because our RAG strategy is off," or the agent is, is off, for example.
- 9:03
Um, you'll also annotate datasets as well just to double-check that those evals are correct. And then, of course, you always come back in, into your platform, and you, you know, you update the, the prompt template, right?
- 9:14
You change the model 'cause it's, it's wasn't good enough, or you update the agent orchestration. So everybody understands that left-hand circle. Now, a lot of people actually forget about the right-hand circle.
- 9:24
And so it turns out the first time you run evals, what you'll qu- quickly realize is that, um, they're not perfect, right? You actually have to tune those evals over time.
- 9:35
So the way you collect signal actually adjusts as your application also, you know, gets better. And so what I mean by that is that process of running evals, what you might notice if you annotate some of them, is that the eval said something hallucinated or wasn't correct, and it actually was, or vice versa.
- 9:52
Um, so what you actually need to do is collect a set of those failures, right? Say, "Hey, this is where the eval was wrong." And you'll know that by annotating some data every now and again.
- 10:02
Um, and then you'll want to improve the eval prompt template, right? 'Cause the way you collect signal at first, um, you'll quickly realize it's either too obscure, too vague, uh, not specific enough.
- 10:12
So these are the kind of two virtuous cycles that you really wanna get through very quickly. And the way I describe it to AI engineering teams is if you wanna build an, like, a quality AI product, uh, think about velocity.
- 10:26
So the faster you iterate through stuff, if you... I can get through four iterations in a month rather than two, you're gonna exponentially have a better AI product as you build.
- 10:34
And so when we talk about architectures and things like that, um, when the industry first started, this was state-of-the-art, um, routers, right? Um, am I right? Um, so routers are made up of, like, components.
- 10:46
Um, this is a really dumb example of Booking.com's Trip Planner. Um, so Booking, you know, they're one of our largest customers. Trip Planner is basically a, a travel agent in LLM form.
- 10:56
It drives revenue for that company. It helps you book, you know, it'll book your flights, your hotels. It'll give you an itinerary. And so, um, you know, when we think about evals, evals can be as complex as the applicat- application itself.
- 11:10
So in kind of older architectures, um, where there's things like routing, um, you can, you can eval individual components. I think most people get this when you're looking inside of a, a trace, for example.
- 11:22
Um, maybe I wanna eval a specific, uh, component or trace, so this one LLM call, right? But remember... Oops, I'll come up here. But remember that you can, um, okay.
- 11:33
Remember that you can zoom out too, so it doesn't have to just be this one specific component. Let's say this one component is part of an agent or a workflow.
- 11:40
Uh, maybe I just wanna evaluate the input/output of that larger workflow. So that larger workflow is made up of LLM calls, API calls, right? I have to find actual flights, actual hotels that have vacancy, um, maybe some heuristics.
- 11:54
And then you can zoom out a little bit more. Uh, maybe you want to eval things like the way control flow happens. It's a really important component. If you have components in your AI agents that have control flow in them, uh, it actually makes way more sense to eval your control flow first.
- 12:09
And you have conditional evals, meaning if you didn't get the control flow right, why eval anything down the line? 'Cause it's probably wrong, right? So save yourse- save yourself some, some money and some, um, some costs.
- 12:21
So you can think about conditional evals as well. And then of course, we have things like, um, people wanna run evals at, at the highest level. So imagine you have a back and forth, so we call this a session in, in our platform.
- 12:33
But, uh, the whole idea is, you know, uh, a session is made up of a series of traces. So you can imagine there's a back and forth between your...
- 12:40
you and your agent. I just wanna understand, hey, at any point, was the customer frustrated? Was the customer XYZ? So when you start to think about evals, there's no one-stop shop.
- 12:50
Uh, if anybody t- like, says, "This is how you should do evals," and they never asked you about how your application works, you probably shouldn't trust them. Also, I have a hot take, and my hot take is that don't use out-of-the-box evals.
- 13:01
If you get out-of-the-box... If you use out-of-the-box evals, you'll get out-of-the-box results. Um, so really customize them very heavily. It's something that we've learned really from some of the best teams in the world.
- 13:12
Um, okay, let me come here. Um, then you have complexity. Um, this is our own architecture for, uh, our AI copilot. Uh, we built an AI whose one purpose is to troubleshoot, observe, build evals for your AI system.
- 13:25
It obviously takes advantage of our platform, but you know, the reason why we go this route is take us forward five, 10 years from now. Do you guys really think that you, a human, are gonna be the ones who are evaluating all these AI systems, like, manually? [laughs]
- 13:39
Um, what do you think would actually take your place? Um, it's probably gonna be an AI that evaluates future AI. So this is our first iteration on this stuff.
- 13:46
Um, we're super excited about it. Um, you know, it's been out for a year. It's getting better and better. But maybe I'll show you a little bit of the workflows that we have in, in our platform really quickly.
- 13:56
Um, who here is, is working with agents? Okay, who here is interested in, like, agent evaluation? Okay, let's cover that then. Let's see. I'll show you... We'll show you how the industry is doing agent evals.
- 14:08
So with agent evals, things get, like, way more complex, right? The calls are longer. So when you look at your traces, they're much longer. Um, I'll actually show you, uh, our agent, um, traces.
- 14:20
So this is one that kinda failed. But our agent traces kinda works like this. So Copilot works like this. It basically, based off what you say and where you're at in the platform, there's e- there's agents that kind of can do things.
- 14:32
So, um, and it has tools. Each agent has access to a set of tools that it's particularly good at. Um, so the whole idea is that, yes, we can see what each individual, um, trace is doing, right?
- 14:44
We can say, "Hey, what's happening in this particular area?" We can look at the traces. But the reality of, of what people are actually asking in the space is not, "Is my AI agent good or bad?"
- 14:56
What they're actually asking is, "What are the failure modes in which my agent fails?" Right? And so what I mean by that is you can look at one individual, uh, trace and the graph view of it, but the reality is you wanna understand and discern the signal with your entirety of your AI agent.
- 15:13
So what is the d- like, what does the pathing look like across all of that particular AI agent's, um, calls? So for instance, if it had access to, to 10 tools, maybe you wanna answer questions like, how often did it call a specific tool, right?
- 15:29
Um, what were the evals in a specific path? So in our agent graph, for example, um, it's framework agnostic. So whether you use LangGraph, whether you use CrewAI, whether you use your hand-rolled code, um, this is an agnostic way to look at, um, you know, how, how an agent's pathing performs across the aggregate traces.
- 15:50
Um, and so this helps you understand, okay, if my agent that hits component one, then two, then three, uh, my evals look great. But for some reason, when we hit component four, then two, then three, our evals are dropping.
- 16:03
And the reason is why? Well, oh, it turns out component four had a dependency, right, on component three, and it needs that dependency in order to perform. And so when you think about the complexity of agent evals, um, you need kind of the ability to see across not one instantiation, but all of them.
- 16:20
You need to understand the distribution of what's happening. And so when we think about evals across agents, um, that's one way you can think about it. And then maybe a, an easier way to kinda think about it too is, um, you know, trajectory.
- 16:33
Uh, we're thinking about trajectory evals. So imagine for a second, um, you have this specific input, right? And the input is like, you know, "Hey, find me these hotels at, at Trip Planner."
- 16:44
And you know you should hit this component, then that component, this other component. So in this case, it's like start agent, tool agent. You might have a golden dataset, like very similar to how we have golden datasets for LLM-as-a-Judge, but this is for trajectories.
- 16:57
So I expect us to be able to hit at least three or four of these components, for example. So the reference trajectory is kind of mentioned, like I need to hit these components.
- 17:05
Then you get to do, do two, two things, one of two things. Either one, you can pass in like, here's what we did, here's what we expected into an LLM, and then an LLM can actually grade the trajectory.
- 17:16
Um, you can also just say, "Hey, did we explicitly hit these exact like trajectory strings?" Great. Um, but you don't always need a ground truth for that. You, you can start to get creative here.
- 17:25
You can say, "Hey, you know, here's this process that I expected to hit. Do, do the, does these nodes and the description of their nodes match the correct, correct trajectory," for instance.
- 17:35
Um, and then maybe you could do things like we're kind of playing around with this, but maybe here's the trajectory that I hit. Uh, here's the possible paths that are just possible.
- 17:45
Did I do well in these specific areas, right? And you can pass in the, the pathing as a series of like nested key value pairs, for example. LLMs are pretty good at that.
- 17:53
But we start to think about, um, you know, agent evals. You know, the eval space is already complex enough, and what we're seeing is even more complexity. Um, but hopefully that makes sense.
- 18:04
Um, I'll pause here. Um, hopefully that makes sense, but usually I like to make time for questions at the end to keep this pretty interactive. Um, hope that's okay, team.
- 18:12
But any questions? Does this make sense? Cool. No questions. Oh, yeah. Go ahead.
- 18:20
Most of the evals you're talking about are kind of like after the fact, right? Is there a way that you can-
- 18:28
Clearly a hallucination [door closing]
- 18:31
Yeah, incredible question. So a lot of people-- So there's evals that can be, um, you know, some people call them offline or online. Um, I like to say is, like, is it in the path-- Is it in orchestration or out of orchestration?
- 18:43
So for some people, there's a cost to in, in orchestration evals, and the cost is things like latency, right? Some people might call those a guardrail too. Like, "Hey, can I continue or not continue?"
- 18:54
Um, and so there's pros and cons to everything. I think when it comes to guardrails, this is something I, I kinda coach my customers. The way to think about guardrails, um, in general is you have system one.
- 19:06
System one is your orchestration system. It's what you built. It's your prompts. It's everything else. System two is your guardrail system, right? Guardrails are really nice because they, they mitigate risk, right?
- 19:17
But there is a cost, and the cost is maybe it's latency in your user's experience. You can get around that by doing smart things like maybe embeddings guardrails. They're, you know, two orders of magnitude shorter.
- 19:29
Um, but a lot of people don't think about the other two cons here. The other con is complexity. Two systems is complex, especially when one system checks in with the first.
- 19:38
The third thing is that a lot of people mistake guardrails as, like, the thing that needs to be adjusted. A lot of people will go to their guardrails first, like, "Oh, I need to adjust my guardrails."
- 19:48
The reality is you need to adjust system one. That's the root cause, right? Your guardrails are really there to protect you. And then maybe the last thing I'll say too is guardrails are not infa-fallible.
- 19:59
They're-- They kinda act like unit tests. They're for known knowns, right? Whereas observability plus evals... 'Cause the reality is you don't know the distribution of what you're gonna see until you get there, right?
- 20:10
Um, ask anybody who's built in the L-LLM space. Uh, their users are just crazy. [laughs] And so, um, that, that's the difference, and I, and I really caution people 'cause people are like, "Oh, I need to fix my guardrail."
- 20:21
No, no. Go fix the prompt [laughs] first and then worry about your guardrails. But yeah, inline, we call those inline, uh, evals. Some people call them guardrails. But really, do you do the evals in the orchestration or outside of it?
- 20:33
Um, and so you can-- there's pros and cons, so there's no right or wrong answer there, but good question.
- 20:39
Yeah. So, uh, when we have a complex system that is typically taking a long time to run and you have timeouts in this, and I know, uh, uh, you'll have something called a span that limits what, uh, uh, kind of, uh, view we're taking to, uh, a complex agent.
- 20:57
So if we have like a complex system that's really gonna take time, and then there's an asynchronous way, is there support to manage something like that and eval it across the whole system that we have modeled?
- 21:08
Oh, yeah. Amazing question. So, um, who here has ever heard of OTel? OpenTelemetry. Okay, even less than... Okay. Um, one of the most important things to our enterprise customers is, is being on OpenTelemetry.
- 21:21
Um, so you know how I said LLM teams are being split into two? Well, it turns out LLM services are also being split across services. And so the idea is, like, people wanna understand, um, so maybe an asynchronous process in one service or one Docker contain or, you know, one, one Docker or one Kubernetes pod.
- 21:38
Um, OTel propagation is a great way to get around that, meaning you can have a process like application A sends data to my model router, right? And then that comes back to application A.
- 21:50
Then application A hits application B for some reason, and then it comes back to A. When you're actually creating those traces, you wanna be able to see all that work, right?
- 21:58
You don't wanna just instrument one particular thing. You wanna see it across, work across. And so OTel is an incredible pattern for that. It's a solved problem. So that's why we at Arize two and a half years ago when this crazy time started for all of us, we made a bet to be OTel first, and it's, it's
- 22:14
really paid off. Um, yeah.
- 22:16
Awesome.
- 22:17
Yeah.
- 22:17
That's all.
- 22:18
So, uh, I just wanted to ask, like in your experience, is, uh, is there a good way to get the kind of confidence score on the like model eval?
- 22:26
Because I imagine if I, if you have that, you can, you know, identify the value, values like
- 22:32
Okay. So confidence scores on evals, right? Um, yeah, I think it depends where you're getting your eval, if it's from an autoregressive model. Um, companies like OpenAI have actually exposed the log prob.
- 22:42
So the log probability is pseudo like confidence of like... And since you're returning only one co-token and that token is like the, the eval label, log prob is a really good way for those autoregressive models.
- 22:54
If you're using things like, um, small language models, encoder-only models, they come with a probability, uh, of the classification. Um, but really, yeah, it's tough, but you have a bunch of tools in your toolbox, and you generally use them together to discern where things go well or not well.
- 23:09
But log prob, if you're using, uh, a model provider that exposes the log prob is, is a really good way to start for autoregressive models.
- 23:18
Okay. Last question, and then we time up. Yeah.
- 23:20
Hey. Uh, are, do you have anything in your plans like going forward, uh, like how to shorten the loop between customer feedback and automatically improving the prompts as opposed to having like, you know, the development team have to look at it?
- 23:32
Oh, good question. Yeah. We wanna automate in that area definitely. So who here has heard of DSPy?
- 23:38
All right. Okay. If you, if you didn't raise your hand on any of this, I hope you learned a bunch. Um, DSPy obviously has something like MePro. Uh, MePro is an optimizer.
- 23:46
You get like thirty inputs, thirty outputs, and then, um, it basically creates less fragile prompts that span across different models. Like, so it does-- it works for OpenAI, and then it works for Gemini, et cetera.
- 23:56
Um, in terms of like auto optimization, yeah, I think we have the ability to... or we're releasing the ability to run, uh, prompt optim-optimization. So some people call it-- We call it meta-prompting.
- 24:08
But basically, we feed it a dataset. We said, "Here's the input-output pairs. Here's the evals on those things, uh, and there's where things failed and didn't fail. Look at the original prompts.
- 24:18
Look at this dataset. Can you give me a new prompt that fixes this dataset?" Yeah. So we, we have-- we call that meta-prompting, but it's basically use an LLM to just automate so you don't have to.
- 24:29
Yeah. But good question. But really appreciate the time. Uh, we're over at the booth. Uh, feel free to come grab me if you want to talk architecture or, or anything.
- 24:36
But really nice to see you all. [audience applauding] [upbeat music]