Evaluation-Driven Development Workflows: Best Practices and Real-World Scenarios

Summary

EDD methodology: Evaluation-Driven Development embeds continuous assessment into the AI development lifecycle to ensure reliable and efficient systems.
Quality datasets: High-quality evaluation datasets are created using document analysis, synthetic data generation, and SME validation to reduce manual effort.
Automated improvement: Tools like MLflow and Mosaic AI Agent Framework quantify improvements by tracking metrics such as context relevance, groundedness, and response accuracy.

Evaluation-Driven Development Workflows: Best Practices and Real-World Scenarios

Talk by Arthur Dooner, Senior Specialist Solutions Architect, Databricks ; Wenwen Xie, Specialist Solutions Architect, Databricks
In enterprise AI, Evaluation-Driven Development (EDD) ensures reliable, efficient systems by embedding continuous assessment and improvement into the AI development lifecycle. High-quality evaluation datasets are created using techniques like document analysis, synthetic data generation via Mosaic AI’s synthetic data generation API, SME validation, and relevance filtering, reducing manual effort and accelerating workflows. EDD focuses on metrics such as context relevance, groundedness, and response accuracy to identify and address issues like retrieval errors or model limitations. Custom LLM judges, tailored to domain-specific needs like PII detection or tone assessment, enhance evaluations. By leveraging tools like Mosaic AI Agent Framework and Agent Evaluation, MLflow, EDD automates data tracking, streamlines workflows, and quantifies improvements, transforming AI development for delivering scalable, high-performing systems that drive measurable organizational value.
Databricks Named a Leader in the 2025 Gartner® Magic Quadrant™ for Data Science and Machine Learning Platforms: https://www.databricks.com/blog/databricks-named-leader-2025-gartner-magic-quadrant-data-science-and-machine-learning
Build and deploy quality AI agent systems: https://www.databricks.com/product/artificial-intelligence
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

Chapters

FAQs

What is Evaluation-Driven Development?

Evaluation-Driven Development (EDD) is a methodology that embeds continuous evaluation and assessment into the AI development lifecycle. This video explains best practices for ensuring reliable and efficient enterprise AI systems.

How do you create quality evaluation datasets?

Quality evaluation datasets use document analysis, synthetic data generation via Mosaic AI APIs, and SME validation. This video demonstrates techniques for reducing manual effort and accelerating workflows.

What are the best practices for evaluating large language models?

This video demonstrates best practices for evaluation-driven development, including establishing clear success criteria tailored to your business goals, using metrics like context relevance and groundedness to identify issues, and building repeatable evaluation processes. The key is treating quality measures as first-class, comparing new model versions against previous versions to verify progress, and using custom LLM judges tailored to domain-specific needs like PII detection or tone assessment.

What is the difference between AI agent evaluation and observability?

This video clarifies that evaluation and observability serve different purposes in AI agent development. Observability through MLflow tracing captures every step an agent takes, including inputs, outputs, costs, and token usage. Evaluation, by contrast, assesses whether agents are performing correctly against defined success criteria using metrics like accuracy and relevance, helping iterate and improve before deployment.

Where can I find production-ready tools for AI agent development?

This video showcases production-ready agentic tools on the Databricks Data and AI platform, including Mosaic AI Agent Framework, Agent Evaluation, and MLflow 3. These tools automate data tracking, streamline workflows, and support evaluation-driven development practices. The platform also provides vector search for retrieval-augmented generation and integration with open-source frameworks like LangChain and LLaMA Index.

Full transcript

`0:00` Introduction to AI agents

Welcome to our session on evaluationdriven development workflow. I really appreciate you guys staying with us in the late afternoon. I know a lot of you guys are hiding out but this is us. So welcome. All right. So today we are going to explore best practices and then real world scenarios for building iterating and evaluating AI agent on data bricks. Uh before we dive in a brief introduction about us Z. I'm a specialist solutions architect at data bricks within manufacturing vertical.
This is my partner Duner. Hey folks, I'm a specialist architect on the same team as as well. We work building Gen AI systems and workflows and agents together. And the idea is to try to take a centralized way of understanding how we iterate on our AI systems through evaluation as the methodology. That's what our talk's all about. So before we dive really deep into that, we're going to dive first into what are AI agents.
All right, so let's start with the basics. What is an AI agent? An AI agent use large language model to decide how to call APIs or query data. It reasons based on user requests which true function or data set to invoke. We often hear systems called compound AI system where you have multiple agents make multiple tool calls or rag retrieval augmented generation or genie style chatbot using pax code that allows user to ask natural language query about their data and many more.

`1:17` The agentic ops life cycle

So in essence AI agent is large language models, language capability or reasoning capability plus decision making plus taking actions. So now let's take a look at what it takes to run agentbased system in production. What we recommend or the best practices is agentic ops life cycle. What is agentic ops? Just like traditional software type ops life cycle agent AI agent needs agentic ops life cycle. It's a life cycle that supports evaluation, iteration and improvement of AI agents.
So it all starts from data collection. This is where you might have user inputs, application logs, uh knowledge documents or juro tickets, chat history and you would like to generate insights or reports for deep analysis and these data can flow in from Microsoft Azure blob storage or AWS S3 buckets uh you know whatever external resources you might have. And the next is data prep. Data prep is when you use tools like spark, SQL, pandas to clean and transform the data for it ready to consume or build or tuning the AI agents.
This is where the data engineer plays a important role for building and tuning AI agents. This often involves you know prompt engineering rag system configuration setup for example using vector search for contact retrieval and then decide which tool or functions to call and you can use your favorite like open source source software like lchain lama index openai and this is where you might also be fine-tuning your model or customize your model using tensorflow or pietorch and tracing is critically important in this step because it tracks every step the agent takes and captures the input and output cost and token usage all these metrics so you can review and make sure that agent gets to high quality and that yeah that's a really big point on all this like training and these AI systems that you're building because you know it's not like we're training an a model we're training a set of behaviors through prompting through agents, through all these tools that alluding to, right?
And then we're evaluating how those tools are being used in different context. Are the tools working well? Are the model prompts working well? Is the mandate of the model clear? Is the model performing safely? We're going to get really deep into all those parts, but you want to uh review the deployment piece as well. Yeah. So, basically, after you build the agent, we enter into evaluation phase. And this is where you have the domain experts whether that's human or AI judges come into play.
And once your model pass your threshold and hits the uh verification checks, it's ready for deployment. And this is where the ML engineer uh serve the model via model serving whether that's data bricks model serving or docker or kubernetes. But this doesn't stop the story doesn't stop here. Once your model is live in production, you should continuously model uh monitor the model performance catching any bugs, any issues and regressions or edge cases.
So to start the life cycle again. So in essence the agentic ops is not about just getting one prompt working. It's about iterating and then evaluating and using traces and then helping you uh build this entire life cycle that you can iterate on to get your model to high quality. Exactly. All right. What does it mean to be evaluation driven? And evaluation is a mindset. And evaluation driven it. What we mean is that you treat your quality measure or metrics as first class.

`5:51` Evaluation-driven development

Which means every change whether that's be prompt tweaks or model upgrades or new tools you added into your system, you verify them in a repeatable and a standardized way. And every evaluation run, before you run uh evaluation, you should have a clear defined success criteria. And this success or this correctness should be catered to your business use case align to your business goals. And what is correct in one system may not necessarily be correct in the other system.
And then you need to compare your new versions from the previous version to know whether you're moving forward or backward. Without evaluation, we cannot prove that our iteration is making any progress. And one of the big things about this these foundations, as you look at the tooling that about to present, I want to make it really really clear that those are templates and scaffolds to accelerate how you train and build these AI systems. when you how you design your system to solve each goal.
The technology that's on the newest versions of MLflow, MLflow 3 that got announced this week at data and AI summit, right? We want to recognize that these are ways to help you get started evaluating the these AI systems. They aren't necessarily the end all beall. There's going to be nuance to the ways that you build your AI system or like quality metrics or heruristics or judges that we'll all dive into in a second, but just think about that you're using the MLflow technology as a template to extend judging your own AI system.
Does that make sense? Hope it does. , yeah. So the types of evaluation we're talking about here is and this circles back to my point earlier about you should be able to build your system that caterers to your business use case align with your business goals and accuracy and the correctness may mean different things in different AI agent system in different systems like for example in traditional machine learning you have classification and you have advanc and this is where you might also be able to apply it in your agent uh JI system where you need to do some classification or some sort of like uh task as a related to this aspect and in rag system you might highlight on the retrieval performance or retrieval quality uh prompt expansion latency costs so on and so forth for agent system you want to highlight that whether that's agent is uh deterministic or the tool quality and performance individually as well as the tool results together.
You're taking a big step on the on the agent side where everything becomes less deterministic, right? You can kind of view this whole slide as a spectrum of very tangible exact answers, right? Two very dynamic, unstructured, you have to extract features out of that data or ask questions about what the LLM judge did. So it ends up being this really like the nuance increases as you approach the further right sides of this visual.
All right. And then the top customer challenge we have heard over and over is how do I get my GI system to be high quality deliver accurate results and quality is hard. Quality is the number one blocker for productionizing your giant applications because LM agents are non-deterministic and unpredictable meaning that you can have small prompt tweaks but wildly different outputs or you can have uh different parameters like temperature or some different parameters that add viability to it and user input can also come in countless ways. user can ask the same questions with many different formats.
It's also unpredict predictable and then change over time. Quality is also defined vly and in multi in many many different dimensions such as accuracy, correctness or fluency or professional professionalism right there many moving parts in the system for example large language model retrievers and the tools. Why are J why why are JI eval so hard? And as we mentioned inputs, user inputs are free form text and constantly changing user can ask the same questions in many ways and user can also have like different synonyms and paraphrases or slan in their language and the same the outputs are also plain language.
So it has the same problem. It's also free form text. So judging accuracy is very difficult bring to bring it all together for evaluationdriven development workflow we really want to focus on these different components and for each of the components we're going to dive deep into it later but for evaluationdriven development we uh throughout this whole life cycle we want to focus on run repeatable able and then standardized tests and have a clear definition uh success criteria and be able to compare between versions and that's what we mean evaluationdriven development that's what evaluation drives development exactly and as about to show right now imagine you built that first agent system right you running your first questions against that AI system you've built what's the first thing you're going to look You're going to look at all of the things that AI system generated or the retrieval pieces it called or the tools it called and you're going to see that through tracing.

`11:05` MLflow tracing for observability

Yeah. So let's dive into ML tracing. What is ML tracing? ML tracing provides end to end observability. It provides all of these features that help you get the JI system you build to high quality. It has streamlined debugging. you know every step of your GI applications you can quickly diagnose and resolve issues. Offline evaluation you can use our proprietary technology uh for LM judge to do agent evaluation and you can measure improved agent quality over time. production monitoring.
It allows you to monitor the agent behavior or actions it takes in production to optimize agent performance or capture any uh regressions or edge cases or errors happening. So you have confidence that your agent is working properly in production. Audit logs. So tracing also generates audit logs for agent actions and decisions. This also uh allow you to use this logs later for review or edit and understand the quality of your application.
And now you see a UI interface of ML tracing. Um this is just showing you on the left side you can see like the trace breakdown of the step that the agent takes whether that's tool calling or the input and output. And on the right side you can see all of this in information that being captured and visualized with inputs and outputs and the latency. ML tracing is also standard and interoperable. You can trace 20 plus libraries by one line and it's also built on open telemetry traces.
It's a opensource software um used by the broad community. So it's it's kind of funny, right? Like you might think when we show you that trace it's like oh my god I've got to like set up all of these different pieces that integrate all of these different frameworks or all these different AI systems I've already built. No, it's literally that one line of code where it will start to autolog and you can even like bundle models or like logical entities wrapping all of your models and it's auto auto that trace that we just showed on that last slide.
You're literally seeing all of the steps that it's automatically understanding because it has those deep integrations to those frameworks. So, it's something you can basically turn on. I wouldn't say for free in a sense of effort, but nearly free, right? It's just like, okay, enable MLflow, make sure MLFlow is working. I have a tracking server hooked up, which is automatic and data bricks, and you're off to the races.
Awesome. And now, let's talk about building. And as we talked about uh a lot about like building and tuning agent earlier you can use any of your favorite open source frameworks and iterate on the PC you know whether that's line chain lama index open a tropic uh anything you can use and choose which are integrated with our ML flow you can use and choose to build your AI agenc And this is this screenshot is showing you how easy it is to debugging with tracing.

`14:47` Building and collecting feedback

You can see the exception details are being captured in the events and you can use that to debug and with the inputs and the culture it shows that you can debug very easily. All right. And let's talk about human feedback and why human feedback is so important. I'm going to uh I'm going to talk about like uh with some customers I match they always say oh we know that human feedback is super important but our theme or stakeholders they just don't have the time to do it or to review the output of the agent systems right and MLflow tracing provides uh review app to collect human feedback from your stakeholder from yourmemes seamlessly and easily and you will see example later in the demo.
Exactly. So for this screenshot you are seeing that this is capturing like the user input and the system output in the same place with the human and AI judge feedbacks. And then here imagine this would be your production trace where you have a user input and the MLflow tracing that shows each step the agent takes and assistant output. And you can have you can see like the assessment to identify the root causes from ML judges and the human annotations and you can send the traits for theme review and data set curation later.
And you if you had used um all of our MLflow tech uh even a week ago, right? What what you would have experienced is I have all of this trace in one place. How do I look at an aggregate of that trace and like similar traces or similar questions that someone asked or how can I go look at the human feedback? All of that was very segmented in a lot of different zones because the like foundational structure of MLflow was a little different. it was every experiment was the logical grouping.
Every time you run something was the logical grouping rather than every model, every like key entity you're designing. So there's been this shift in MLflow around those model ids as that like central entity that we can add all those additional like human traces, human feedback, AI judge feedback that we'll go into in a second in one place and you can aggregate and see those together. Yeah. And this gave is showing you what the review app looks like.
You can see it's very easy for your stakeholders to interact with this app and to uh provide feedback on expected facts or guidelines or metrics to the user input and assistant output and the stakeholders can can just go into this app, open it up, have a conversation and review the answer and provide the feedback to it. It's all uh about collecting the human feedback and then send it later formeme labeling if you want to build that into your own front end too right you might be like I don't want my users to see something that like is in data bricks for testing I want it to be like embedded in how they're consuming the model anyway you can actually tie into that endpoint that's auto deployed with every MLflow deployed model all right and now let's talk about automatic evaluation so this is what we used to call mosaic AI agent evaluation.

`18:15` Automatic and custom evaluation

It's advanced and researchbacked techniques that allow the developers to quickly evaluate the cost, the quality or latency of your AI application to do further analysis and improve the agent performance. So as you can see it's just as easy as putting up a one line of code to do the ML flow JI evaluate and then pass the data set you want the uh LM judge to evaluate on and define the scores that caters or customize to your business goals.
And in this screenshot you can see like you can just use this decorator syntax to define this customized evaluation. You can also provide guidelines uh for the LM judges. For example, the agent must be or the response must be in English or the response must be clear and cohesive and concise and things like that. And a lot of the teams that we've worked with, we would build these evaluations. We'd build them very manually and it was extremely painful to design custom evaluations in MLflow again up until last week uh where it's a lot more intuitive. built into again those like model app objects that you just define custom scorers for each.
So this is another really big change to help you evaluate these AI systems in a lot more custom ways without the infrastructure getting in your way. Exactly. Yeah. So uh in this screenshot uh I I want to show you something that's really special like we provide this feature for ML tracing because it's not just capture internal giant applications you can use it with external applications whether that's application beyond data bricks apps or some external servers you can use MLflow to capture the traces which has the user input and output and all these different metadata and then create evaluation run on it.
So as you can see here, you create evaluation run and specify or select the AI judge you would like to run whether that's be correctness or relevance or hallucination like these different metrics or providing your own customized AI judge or create your customized metrics. You can use this to run the evaluation on these traces for getting the applications to evaluate understand the quality of your J applications. And now this would be the screenshot you probably would like to capture for later reference because with MLflow 3.
0 you'll be able to view and compare evaluation results across agent versions. And like something to just note on all this like as we see like each one of these is a dimension of a builtin grading feature in MLflow right like the correctness the which is against a ground truth the context relevance was the context that was provided enough to answer the question and you see towards the end you start to have more custom judges that you would layer it past these these are again AI judges that are grading the answers of each of these responses and you can combine them with heruristics which are like oh tell me like what about this answer like how long was it how many characters did it have was the variance and custom judges and on that last screen that just showed all of this you would used to have to do with code but with the launch of agent bricks and mlflow 3 the again the release this week you're seeing an ability to be able to do this in the UI and what's so novel about agent bricks that like kind of gets buried in the whole keynote is that it's creating a lot custom evaluations for you to make the AI system better and better on its own.
So that's how it's like different from a lot of those low code systems like AI like Microsoft Copilot Studio and such. Yeah. Uh and the ML flow tracing has a new feature come out that allows you to do prompt management so you can version and reuse prompt across agents. You can also uh automatically optimize your prompts by leveraging DSPI. Um so as you can see on the screenshot, you can just you can just run this SDK like optimize prompt.
It will allow you to optimize the prompt under the hood. And this screenshot is showing you that you can also view and then compare agent versions and different versions of prompts and then see how your agent system like evolve over time. All right. uh in terms of uh what like once your uh AI application is in production you also need to know like how is it doing is it uh producing any you know inaccurate results or is it having any edge cases or regression happening.
So this uh this feature allows you to do that. So you you can uh run the traces on your uh production application and you can use the same uh custom scores that you defined with the offline development use it to use for online monitoring. And here you can see that you can review the evaluation results again and identify the bottlenecks or the issues and the root cause to fix it later. All right. Um monitoring is a very important part.

`23:59` Production monitoring and data curation

It's it's we we would like to continuously monitoring our uh JI applications and ML flow tracing is providing this monitoring capabilities. You can just configure a monitor on your serving endpoint and then you can use the same like judges that you built reuse reuse the same scores between offline and the production environment and there you can run the monitoring on your data set with the same set of evaluation that unified across offline and online.
You can also see there's a dashboard generated with the monitoring capabilities. And here you can see the operation metrics and the request latency and also the assessment scores that you defined earlier. And you can click on each of the diagram or each bar to a deep dive and then take a further look at the issues or uh things that happen in there. All right. And you can also capture like the monitoring results uh into the unity catalog table you know like secure governance production traces with data bricks unity catalog and for later analyze analyze with SQL dashboard just like you any other business data and finally data set collection.
You can create a data set and export these traces to this data set in Unity catalog for your theme or stakeholders to review and edit. And then again once you run through this life cycle you collect this data you can put it as your ground truth again your contacts your information that you want to get insights from it for deep analysis. Uh that's what we call you complete the agent ops life cycle. So thanks so much for all right appreciate the uh overview of all this platform tooling and the view that we have of data bricks and where we see this technology going.

`25:56` Applied evaluation strategies

I want to make it very clear that the data bricks platform builds a set of tooling for all of us to be successful. you as you are building these AI systems, we are no longer grounded in these root mean squared error like a regression problem classical ML might have. We are now in the wild west of having to think about well what does good look like for my application? How would I grade it? How would I know this is good?
What data bricks is trying to do with this whole ML flow stack is to support the largest number of people to have a template to grade and assess their AI systems out of the box from a correctness perspective if you provide a ground truth from a groundedness like hey is it using the right context those are pretty common generic grades you know is it safe is it saying mean things about after the session right those sorts of things we need to be very thoughtful about That's a great template.
That's a great place to start. But how do we extend it? And a lot of us approach it backwards. We think what are the metrics that I need or like what are the questions I want to ask? When really we need to be starting from what is the problem I'm trying to solve? What are the types of scenarios that I might face? And what's like the base data set of a good question and a good answer that we might be looking for. So, what I'm trying to convey here, I'll convey it in a whiteboard real quick.
So, I love working on cars. Um, I'm not good at it, but I love it. And I've worked on a lot of different cars and like gone through all these like manuals that would tell me, hey, you know, to actually repair this part, you have to repair another part, right? You have to first take this other piece off. So, that network graph, even in these like ancient books on old cars, is is present and important. But if you're just using like a regular rag, that context might be lost.
So, as I think about like any problem, let alone this very specific silly one that I'm bringing up, there's a question or a task and an answer or an outcome that you need the AI system to solve, right? You need to think about it in that lens. And I challenge yall as you build your first AI systems, right? Think about it in those ways. What are the questions my users are going to ask? You might already know this. You might have to go ask them.
You might have an idea of it that will evolve. The questions and the answers are going to change and rapidly change rapidly evolve as we see more and more users like try this out. Oh, wow. I never thought I'd get asked this question or we're not going to support that question yet, so we need to put a guardrail to say we're not we're not interested in solving that. Right? So, when I ask it like I think about repairing silly old cars, uh I'm like, "Tell me about how to replace the front suspension strut of a 2003 Pontiac Aztec, the ugliest car ever made."
Uh we think about like what is that the first version of the system that I build might just like pull the raw pages from those docs. It'd be like the section that talks about suspension struts. It's like, "Okay, take those three bolts off." Right? But you would miss the whole context of actually first you need to take off the windshield wiper assembly. Ask me how I know. Um and that context is lost if there isn't like a network relationship of those data.
You the tool the tools that I design the data ecosystems are not big enough in this data domain when I get started to just like focus on these small slices to solve this problem. I need to build that knowledge graph of all of the relationships of the parts that I might need to take off or change or upgrade or you know all these different edge cases that exist in an automotive repair scenario right the complete answer is like hey you actually have to take this off first you have to disconnect the battery all these related pieces before you approach the problem that's signifying what tools you need to solve that task right and there are attributes of that answer that you can brain, right?
So, sure there are simple versions of this where it just pulls like that first dot on struts and how they relate to other things, but there is a second version of this. Oh, how all these components are related that it's a more compound tool, but you're grading is it traversing that network relationship of data? Is it going to actually bring up that it needs the windshield washer uh assembly removed? It's easy to think about this if you think about it in tangible examples that are related to your business.
It's hard to think about it in the abstract. So the best way to do this is to just start listing out all the questions, all the tasks you needed to solve and then you start to think about what is a good answer look like and then you deconstruct what are the components of a good answer, right? You have this idea what is the groundedness? What are the attributes that make this a high quality answer? And then that becomes your template. you use the ML flow template and you extend it broader than just that set, right?
So, as you're building these AI systems, we might think, I build a first version of an AI app. This one's an SEC knowledge bot. We build this first version of it and what's going to happen is I've built a few tools. This is what I think that I need to solve. And then I run it through all the questions that I needed to ask. And that's where that genai. evaluate comes through. You have that list of like 20 or 30 questions that you're thinking about.
Those 20 or 30 become the starting set that help you improve the system step over step and having that correctness ground truth. That's why that's the most important one because it tells you is this the accurate number. Is this the accurate result is might be collapsing and losing some of the dimensionality and how the other pieces are working but it's the most important piece. So if you can start with the ground truth, please do.
So you can see it's going to be calling all these tools. We can get all this feedback and it's not just me sitting in a vacuum getting these results and it knowing that I asked this question. It's actually like oh you know it's traversing all these different data. It's an agent. This these are the actual results about 2023 and 2024 that I asked about and then it includes all the context and sites and I can say oh this was a good source that was a bad source.
You can see it right here like this is a good one. Okay, maybe it doesn't want to visualize live demo problems. You can edit the response. You can say it needed to change. And then you can say like this was a great answer because it was helpful, it was professional, it was relevant. You can give free text feedback. Same on the other side. No, it wasn't helpful in these ways. And then you build that data set at a very small scale of 20 or 30, right?
You're building that data set of just a few examples. like you have an idea of what are the tools, the components, the pieces of the system that I need to iterate on and how do you dig into that beyond the scale of one? Well, that's where some of these grading pieces come in where we actually capture all of these in what's called an inference table in data bricks. And that inference table is the base data set, right?
That's capturing every single question, answer, and then grade that I give later to this system. There's going to be an assessment log and there's going to be a request log. And as you get more of those from either you testing it or your end users, you end up with this view of like, wow, I've got a lot of questions that people ask me. And then I can use that to improve my system over time or grade it later, right? Even on future versions of it as it's a more complete and comprehensive system.
So, we're thinking about this in a very iterative way, but we're building the data set to grade it from the get-go, from the very beginning ourselves with our subject matter expert feedback, and then we're also grading it against LLM judges to help us understand like the dimensional components of how well it's working, right? So, we think about as I build this system, as I've got people testing it, I'm going to eventually end up in this spot where I've got all of this is a customer service app.
So, it's going to look a little bit different on the questions, but you can see like how is the how is the answer? Is the correctness good? Is the groundedness good? Is the safety good? Groundedness again being like context related to the answer. Is that relevant? And is it using that context? The safety obviously is it saying something harmful? the context efficiency. You can see there are a lot of them like I didn't hook up the context efficiency piece of this system and I'm sure you won't the first time either on your first AI system, but having a ground truth it will highlight all of the ones that fail because that's really the ones that you care about on each of these pieces.
You can see like you can dig in like why is this one actually failing? It's going to say these are the attributes of it failing. There'll be a trace that you can click into and that's what we were show showing earlier on the slides that you can filter to certain types of questions that people might have asked. pay to who has to vote Pontiacs, who asked to vote olds, who you can find those edge cases of different types of questions and answers that people are getting.
And we end up with this view of when I have these maybe specialized business users who we we might be more skeptical of this whole AI system thing, we want to make sure we can support their edge cases or at best deflect those questions, say, "Hey, we're not here to solve that yet." That's that's part of our backlog. By you asking that question, we've now gut it in our list of questions so we can see if there's any new types of questions we might want to support in the future.
So evaluation is a journey and it's a mindset. Your evaluation is the place that we like to start when we're building these because we have an idea of what good looks like. We can define those different dimensions, but then we're not just statically using that evaluation. evolving with us. As there are new features of our application that we add, we're going to add those features as components in. Right? This is a journey in evaluation.
And as much as you improve the app that you are building, you are also improving the actual AI systems evaluation itself. The MLflow starter points are again templates for you to extend. So let me talk about how I've worked with a few teams to build some custom AI evaluations against AI systems that they have made. And uh if you got questions uh you can hop on that line on the at one of the mics and I'll be more than happy to answer them when I'm done talking about these few scenarios.
So if we think about this um very common scenario is these customer support use cases. Liippard is customer that I've worked with quite a bit. They're working with progressively more data domains all at once. So they start with like a very small subset data domain. They ask it a few types of questions. It works really well in that. It builds user trust. We can evaluate that it's going to work well because we're assessing across the dimensions that the business users would care about.

`36:58` Real-world customer case studies

So that one's a pretty typical standard very aligned to the template that ML flow might use. Right? Then as we think about our customer needs, right? It's not just building and deploying and governing. We need to monitor these more uh as we run huge sets of data. The lipert one is more of a like customer service probably a couple requests an hour scenario. What happens when you get a case study where you might have technician notes from an an automaker or a tractor company that ends up with a ton of unstructured text.
It's a huge mess. Everyone's writing it slightly differently, but you're trying to extract value out of it. trying to get some insights about what these technicians said about the cars or tractors that you're working on. So, what do you do? You say, "All right, we need to understand if someone mention tires in that uh technician. You need to understand, did someone mention brakes? Did someone mention, you know, any of these different components of the vehicle?"
And we can actually mine that out and we can say, "Okay, that looks good." And then we can compare it to how we manually graded a set of a hundred of them. Right? Let's go through and manually grade a hundred of them. See, okay, did they mention tires? Do they mention brakes? They mentioned these other things. And then that can be just a classification score. That's just an F1 score that collapses to one number, right?
So you can just compare this version of my AI system was 50% accurate because compared to the labeled set that I started with at 100, it was it was 50% accurate. And then the next version with a better prompt, oh it's 70%. Oh, with more tools for more context, it's at 80%. See the journey that lives here. And at this this scenario in this big batch process, we're collapsing it the accuracy down to these very distinct numbers.
We're building up our confidence to rely on this in production at a much bigger scale. And then we can audit this process as we as we move forward. further. I have I've worked with a lot of teams that have built AI systems on their own without data bricks and then they actually like we don't we don't know how to take it like assess quality. They don't the these other platforms like AI foundry bedrock might not have those deep evaluation integrations that ML flow does.
So people bring their AI systems to data bricks. We don't really change them and we we'd like to but we don't. We will take those in and we'll actually work with them to design an evaluation and then we'll compare how does a maybe a new version of that in data bricks work that's running multi- aents running agent bricks and see is it at least as good as the one that Microsoft the one on Azure is working is it okay compared to a ground truth how is this across all of these edge cases with synthetic data generation for like representative questions of what our business asks is that going to work and we obviously have those elements judges And I know I'm over time, so give me like 10 more seconds.
Those SQL prompts end up even going as far as we can label specific features of SQL questions. Did it reference the right table? Did it reference the right columns in those tables? Did it do a join? Was it supposed to do a join? We can collapse those attributes into some very clear tasks. And these are very uh deconstructable problems that are a lot more approachable. But you have to think what are the components and features that we need to extract from our AI systems so we know that they are working well.
So I'll leave this one for as big takeaways for that I hope you got away from today. Uh feel free to screenshot that. It's a mindset. It's a way that you're viewing all of these AI systems. It's how you iterate and evolve and how you view the problem space that you need to work on. And data bricks helps you with all of these templates. all of this autoconnecting technology. Think like a data scientist. You need to choose the metric.
You don't have that metric anymore, right? It's not pre-built for you. So, think about how you would design a metric that means something to your business use case. I really appreciate y'all sticking with us late on a Thursday afternoon. Thank you both or thank you all for your time.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.