Measure AI Quality: LLM Judges and Enterprise Governance

Summary

Jonathan Frankle, chief AI scientist at Databricks, argues that raw model intelligence is not the primary bottleneck to AI adoption — the real gap is rigorous measurement of whether AI systems are actually doing what organizations want.
Building calibrated LLM judges that emulate human judgment provides reliable, scalable quality signals and is the foundation for confidently deploying AI in production environments ranging from government to finance.
The World Bank demonstrates how governance frameworks, outcome-focused scorecards, and agentic AI for mission-critical operations put systematic measurement principles into practice at scale.

Measure AI Quality: LLM Judges and Enterprise Governance

Raw intelligence is not the bottleneck to AI adoption. Measurement is. this video establishes why rigorous quality evaluation matters more than ever, contrasting software engineering practices with how AI systems are currently deployed. Learn how to move beyond vibes and establish systematic measurement frameworks that enable organizations to confidently scale AI in production.
Discover the practical workflow for building calibrated LLM judges that emulate human judgment, creating reliable quality signals at scale. Explore governance and compliance in action through World Bank case studies, and understand how Databricks enables mission-critical AI through evaluation, observability, and systematic risk management. Whether you're building for government, finance, or enterprise, learn why measurement is the foundation of AI engineering.
🤝

Chapters

FAQs

Why does Databricks' chief AI scientist argue that measurement is more important than raw AI intelligence?

Jonathan Frankle contends that the limiting factor in AI adoption is not model capability but the ability to verify that AI is reliably doing what you want. Without rigorous measurement, teams cannot distinguish genuine improvements from regressions, cannot scale responsibly, and tend to rely on intuition rather than evidence when making deployment decisions.

How do you build a calibrated LLM judge for evaluating AI quality?

A calibrated LLM judge is built by first collecting human labels on a representative set of outputs, then designing a judge prompt that attempts to replicate that human judgment, and iterating until the judge's scores closely match the human labels. The calibration process ensures the judge produces reliable quality signals rather than arbitrary scores.

How does the World Bank use AI governance and measurement in its operations?

The World Bank, represented by Arvin in this video, uses outcome-focused scorecards to measure mission impact rather than just outputs, and applies agentic AI to mission-critical operations. Their approach illustrates how governance frameworks and systematic measurement can be applied in a multilateral institution context.

What is the role of the Databricks AI gateway in enterprise AI governance?

The Databricks AI gateway is discussed in this video as a tool for managing and governing access to AI models across an organization. It provides the control layer that organizations need to ensure consistent, compliant, and auditable use of AI in production.

Full transcript

[00:10] Hey everybody. Um I'm Jonathan Frankle, chief AI scientist at Data Bricks. Um it's great to be with you today. I'm here to talk about measurement of AI. Um so as chief AI scientist, I run our research team. So I spend a lot of time in the lab doing AI research, training new models, building new techniques,
[00:26] experimenting with new products that then eventually find their way into, you know, the data bricks platform that you know and love, agent bricks, those sorts of things. So I'm here today to tell you about measurement because to me it is the single most important topic in AI. Day-to-day I do a lot of reinforcement learning. I train a lot of models, but
[00:43] the only thing that really matters is measuring whether AI is actually doing what you want. And that's a non-trivial thing to do. Um, so that's what I'm going to tell you about for a little bit and then, you know, I have my friend Arvin from World Bank here to tell you about, you know, what some of this looks like in practice.
[00:59] So, you always have to have a controversial claim. Um, I want to, you know, see if I can get myself into a little bit of trouble. I don't think that, you know, raw intelligence is the bottleneck to AI adoption right now. I think a lot of folks look at this and go, well, we just need smarter models.
[01:14] We just need super intelligence. We just need AGI, and then all of our problems with AI will be solved. Um, and if only it were so easy. Um, you know, and I'll give you a few examples of that in a moment. Um, but you know, motivation for this is really let's start with a metaphor. Um, so you know, you're
[01:29] building a new software product. I think a lot of us who are here have been there and done that hopefully if you're bothering to come to a talk that I'm giving. And so you write a thousand line script in Python as one does. You know, you just go write it, see what happens. And then you play with it a little bit. You know, you tinker, try it out on a couple inputs, see what happens. Feels
[01:46] good. Ship to prod. um just give it to everybody, deploy it to 10,000 people and you're set, right? This is how we all build software, right? Yeah, this is exactly right. Right. Like you'd be an idiot to do this. Like that would be completely insane. Um
[02:02] yet, you know, instead we have all these guard rails to make sure you don't do something too stupid. You write a design doc, you break it into modules, you have abstraction boundaries, all the things that for anyone who's written software, we've been trained from birth to think this way. um you write unit tests and you know integration tests you look for
[02:18] typical corner cases like you you test the system really rigorously. You have some confidence objectively that it's going to work and you're you're very confident it will work before you ship it. If there's something that goes wrong after you've shipped it, you've made a mistake. You've done something bad. This is the software process. Um but you
[02:35] know, let's take this metaphor that I had before and instead you're building a new AI product. You write a thousandword prompt, check the vibes, seems good, you ship it, call it a day. Um, this is basically the state-of-the-art in AI development right now. Um, how many people have done this? Just out of
[02:51] curiosity, because I know I've done this. Um, and so the contrast between, you know, this slide, you know, or actually this slide, you know, we're really careful about everything and what AI quote unquote software engineering or
[03:07] deployment looks like is kind of insane to me. Somehow the excuse of I'm working with AI means we get out of all the good habits and practices that we've learned over, you know, we as a field have learned over six decades about how to build software. Again, this is
[03:23] completely insane to me and I think it's worth a conversation. Now, I kind of, you know, we're a few days ahead of schedule, but I kind of look at 2026 as a year where I hope we talk about it as AI engineering, not like AI agent building, AI app development, call
[03:38] it whatever you will. Um, moving from demos to actually deploying stuff, everything, you know, like your thousandline prompt, that's a cute demo. Um, well done. Pat on the back. You've got some good vibes. Nice demo. Your boss thinks you're brilliant. um your customers think you're a genius, nicely done, but now it's time to actually
[03:54] build something production ready. Um and so the watch word for me is reliability. Like this stuff has to actually work in production. And you know, so I ask myself these really basic questions. Again, if you ask this about software, this would sound idiotic. How do you build a software system that will still exist in a year? If you're not building
[04:10] a software system that will still exist in a year, what are you doing? But with AI, I think a lot of the agents we're building right now are kind of throwaway. They're not going to exist in a year. Um, how do you build an AI system that multiple people can work on simultaneously? That is an unsolved problem in AI right now, which again is
[04:25] kind of insane to me. In software, we can build systems with tens of thousands of people working on them all at the same time. In AI, if you have two people working on the same prompt, they're going to step on each other's toes and break it. Like, you make a change here and it breaks something up there that you didn't even know was related.
[04:43] So, you know, what is a million line equivalent AI system? We don't know. We're at the very beginning of this journey. Um, so you know, AI isn't software in the traditional sense. Um, like we only know one way to do this. It's modularity, abstraction,
[04:58] specification. These are the core concepts of software building that if anybody has ever taken a class on software engineering or ever, you know, been trained as a software engineer, you just do this thing by default. You think about abstraction boundaries and modularity. You think about how you specify what something is supposed to do
[05:15] and then you implement it. That's how we scale this. AI isn't software in the traditional sense, but this is the only way we figured out for humans to be able to build complex systems with multiple people involved, whether it's building a ship, building a piece of software, building a building. And we need to figure out how to do that in AI. And
[05:31] that's really what this talk is about. I think the beginnings of that. So the belief at data bricks is it all starts with emails and measurement. Like the word measurement is just the thing that you're going to hear me say on repeat. If I just literally played that over and over again for the next half hour, you would get the gist of this
[05:46] talk. Um, so again, my claim, raw intelligence isn't the bottleneck to AI adoption. It's something I would call more programming AI. That is to say, how do we actually get AI to do what we want it to do and verify that it's actually doing it in a rigorous enough way that we're not
[06:03] relying on, you know, some person's vibes. And I I I actually saw a use case with a customer where this was about a year ago. They wanted to upgrade from cloud 3.5 to cloud 3.7. And I asked them, "Well, how are you going to know whether you can upgrade?" And they said, "Well, our vibes guy is actually on vacation right now, but when he gets
[06:18] back, we'll have him check." And you can laugh all you want. For any of you who are using AI, that is probably your solution, too. Like, you can point the finger all you want. We're all doing that. It may be my vibes at Data Bricks.
[06:33] It may be your vibes at your organization. We're all doing that. We all know that this is bad. And it's funny until something really stupid, bad, or you know, catastrophically harmful happens in production because your vibes weren't sufficient to catch every possible scenario and your vibes
[06:49] were inconsistent day-to-day. So, you know, quick outline of what I'm going to chat about. Number one, the challenge. Measuring quality is really important. I don't think anybody here is going to debate with me that we should measure the quality of AI systems. It's also really hard. There are a lot of challenges with it. Number two, I'm
[07:06] going to give you a little bit of the framework we use to think about this at a high level on my team at data bricks. Kind of how we're trying to make this a little more systematic. Um, I'm going to talk about kind of a recipe for building gold standard evals, at least for relatively basic agentic applications. Things get harder as you get more complicated. And I won't claim to have
[07:22] any of the answers any more than people in the 1960s knew what good software engineering was going to look like 30 years later in the 90s. If only people in the 60s had said, "We know that what we're doing sucks, but also there will be this thing called object-oriented programming and this thing called Java, and we'll just have that and then we'll be fine."
[07:39] I don't have those answers yet. Um, I wish I did, but we may be waiting many years and trying a lot of stuff first, but I at least want to give you the beginnings of some stuff I think isn't good and some stuff I think might lead us in a better direction. And then, you know, takeaways. There's always takeaways. There's going to be a QR code because we're doing a bunch of cool stuff on this at Data Bricks. It's not
[07:55] even really in our products yet, but there are ways to take part in this that you can get into. Um, and you know, we'll proceed from there. Hopefully, I'll have enough time to actually get to all this. So, we'll start with the challenge. Um, so I probably don't need a slide on this. Why should you measure quality for an AI system? I probably
[08:10] don't need to tell you this, but I think it's worth saying anyway. First of all, yeah, you want it to get better. If you don't know whether something is getting better, you're not making any progress. Looking at your prompt and saying, "This prompt looks more comprehensive to me." is a really shitty way to measure whether something is better.
[08:27] Looking at the vibes on your output and saying, "Eh, this kind of feels a little nicer, like I think it's it caught this thing that it didn't catch before." I'm sorry, but that's a really shitty way to measure quality. Um, that is not sufficient. You would never do that in software. And your rule of thumb should be, if I wouldn't do that in software, I
[08:42] shouldn't be doing that in AI. Um, it helps you figure out where to focus your development efforts. I've seen this time and again where just a little bit of measurement even the mere attempt to measure systematically has revealed that your rag system is not actually retrieving the right documents. You should revisit that like basic failure
[08:58] localization. Um you can validate that changes actually improve performance and not just in your head or in your hopes and dreams but in reality. Um you can also scale with confidence. The amazing thing about digital systems is that unlike a human, one human can only
[09:13] affect a localized environment. You know, I to give you my, you know, my favorite example here, although it's not a pleasant one. You know, one human who decides that they are very tired or drinks a little bit before getting behind the wheel can cause catastrophic damage locally. If there were a bug in an autonomous vehicle piece of software,
[09:29] you could cause massive damage widely. Digital systems have the ability to scale beyond human systems and to scale all at once. And you can get a lot wrong if you make one little mistake. Um, you can evaluate large volumes of outputs automatically. No one human has enough vibes to look at all the behaviors that
[09:46] you want to check in an AI system, no matter how 10x you think you are. Um, and it also grows trust and adoption. Like, how do you know if it's consistent? You upgraded from Gemini 2.5 to Gemini 3. Gemini 3 is a decidedly better model than Gemini 2.5, but did
[10:02] your system get better? Just because you upgraded to a better model does not mean your system got any better? It may have actually gotten worse because your prompt was really well tuned for a different model. um and you know preventing quality related churn that you may not even know about. So there's a there's a lot here. Um
[10:19] so what makes a genai solution good? Um well for starters there are lots of different use cases like you know we can go through I'm just going to stick a few up here. Um these are things that I have just seen around data bricks that we have spent time building evaluation for
[10:34] as of now. Um every use case has different quality requirements. There is no oneizefits-all. I think there's this dream we have that you buy the ultimate AI evaluation product and it has all the judges or all the metrics that you want for your application. Um, dream on. This is like buying a software testing suite
[10:50] that magically tests for all the right properties without you having to write a single test case. If only it were so easy. You have to provide some information about what you want and every use case is different. There even no two use cases for customer support are the same. No two use cases for any kind of automation with software are the
[11:06] same. The details matter. Um defining quality is difficult because it's subjective and context dependent. Subjective is really important here in software at least you can define the full space of possible behaviors for a system and try to evaluate each of them and understand all the corner cases from
[11:22] a from first principles. You can reason through it this out this input can have this set of values and that can affect the output in these ways. You can look at the code and understand that in AI it's natural language. God knows what's going to happen. your system could do something really weird and inexplicable.
[11:38] And we've all seen that happen. We've all seen when the system just starts doom looping or changes, you know, into a language that's completely different from what you asked the question in unexpectedly. That happens. We're dealing with a technology that we can't open up the hood and look inside and it has the full space of words available to it. It can say or do anything. It is
[11:55] very subjective and very context dependent. It's also its superpower. The fact that it's subjective allows us to do NLT tasks that we could not fathom doing manually with Python or with regular expressions, let alone with last generation AI systems. But that superpower also means you basically have
[12:10] an infinite number of corner cases. That's really difficult to work with. Okay, so geni measurement gap. Um this is kind of again I'm going to give you a few of our simple frameworks that I use when I sit down and talk to our customers. You're basically getting you know the spiel I would get if we were chatting one-on-one. Um, what we need is
[12:26] reliable quality signals and it has to be scalable. You have to be able to do this on potentially thousands of inputs and outputs or live monitoring or live guardrails. Um, and you have to do it consistently. Instead, what we have is like you're doing manual spot checks. Like I'm sure everybody here has done a manual spot check on their agent. I have. Um, you you have subject matter
[12:44] experts. You hopefully have someone who knows how the system is supposed to behave. Otherwise, you're never going to know if it's good. If you're in an insurance application and you're trying to do automated underwriting, I hope you have some people who understand how underwriting is supposed to work. Otherwise, what are you doing? Um, and
[12:59] then you have vibes. You have vibes. Um, vibes aren't bad. They're just bad in isolation if that's all you're counting on. And a lot of this talk is really about how you mechanize vibes. How do you make your vibes into something repeatable that you can check in a consistent way across uses? Um, the
[13:16] solution at least for a lot of simple applications is calibrated LLM judges. A lot of us are probably familiar with LM judges. You just asked an LLM to evaluate the behavior of a system instead of a human. The word that really matters here is not LLM judges, but calibrated. What does it mean for an LM judge to
[13:31] judge things in the way that you would judge them? Judge things in the way that you and your experts, your peers, your collaborators would judge it. holistically capturing your best qualitative belief about how a system should behave. That's what this is about. Kind of how you do this
[13:47] rigorously and scientifically. And why? Well, there are many ways for an LM to say the right thing. We're not doing classification. We're doing genai. An LM outputs a bunch of words. And you know, fuzzy behavior requires fuzzy verification. And LM judges can emulate
[14:04] human judgment if calibrated properly. Emphasis on if calibrated properly. That is the single most important part here. Okay. So, framework. How do we kind of make sense of this? There's there are a few ways we typically break this down when we're working with anyone on trying to measure an agent. You know, from very
[14:20] simple ones to very complex ones. First of all, you got to figure out what your must haves are. This is where everything starts. What is the application uniquely trying to do that is different from a general purpose chatbot? What is the value out of this application? If it's doing underwriting, you want it to be able to answer questions about underwriting. If it is doing customer
[14:36] support, you want to be able to answer questions specific to your product and your policies. What does it have to do? What are the table stakes things that it has to get right? Then there are a bunch of mustnot haves. You know, the things that it should not do. You know, some of this is often going
[14:52] off topic. How many people have seen the example where like the Amazon review chatbot? You can kind of get it. There's probably some kind of, you know, OpenAI or something endpoint running underneath it. You can talk to it about anything on an Amazon page. You can ask it math questions and it'll answer math questions. Um, constraining scope is
[15:08] actually pretty important. You do not want it to make up new policies. You do not want it to produce hate speech. If you're using the data bricks chatbot, you do not want it to talk about snowflake. Those are just, you know, those are things we do not want it to do. Must not haves. You often discover
[15:24] these by mistake as you're tinkering with the system. Vibes are a great way to get inspired about this, but you should write them down. This is the expected usage. Um, and then God help you when you go and get it in front of real users because again, Amazon probably did not
[15:39] anticipate that people would use the Amazon reviews chatbot as free chat GPT and ask it all sorts of other questions that were unrelated. But that's what happens. Um, you know, people who have started using Google search with the AI summaries at the top, it has
[15:54] fundamentally changed the behavior of how people use Google. They start asking it questions like a chatbot instead of using nice keywords and things in quotes and things like that. It has completely changed the distribution of behaviors that Google is seeing and has probably broken a lot of their search algorithm and they've probably had to fix a lot of stuff in the past year or so as they've
[16:10] rolled out this more AIcentric experience. That was probably not something they predicted. Um, and now they've got to redo not just the AI part but the entire search algorithm to handle this whole new set of behaviors that happens. Okay. So there's another way we also look at this that I think is really
[16:26] helpful. Kind of three phases of AI system development. There's proof of concept. You've got vibes and that's okay because you're just messing around. You're trying to see what's possible. Can AI do this? Can it get anything right? Can it get it right if I give it this rag database? Can it get it right if I give it this context? Can I get it
[16:41] right if I give it all the documents that are relevant? Just can I get this damn thing to work? Then you've got the pilot stage like getting from step one to step n minus one. Like is the quality high enough for people to actually use this in production? And then you've got it in
[16:57] prod. You've got, you know, you're iterating now. You're in steady state. Okay, human behavior changed. Okay, it's no longer baseball season, it's football season. Okay, like actually some of the data is out of date or there are new things I want my application to do or I found a few behaviors that it's not handling super well. How do I kind of
[17:12] iteratively improve those over time? Okay, so you can kind of map these things together. Um, you know, you've got your three stages, you've got your three different, you know, kinds of usage, and we've built this kind of 3x3 framework here, which basically tells you what you're looking for. Um, the
[17:29] thing I'm really going to focus on is the pilot stage. This is what we internally, and now I guess externally describe as the Bermuda triangle of Gen AI applications and agents. A lot of AI applications go into this phase and are never seen or heard from again. Um, and I think a lot of folks have had this
[17:44] experience where you can get the Vibes to be okay, but the struggle of going from Vives and kind of tinkering around a little bit to something that reliably works in enough cases and reliably works with consistent measurement is actually really hard. You have to make a huge leap from your Vives to something
[18:00] systematic where you can go on vacation and whoever is covering for you can still measure in the same way you were measuring. So the solution um and you know solution is a very strong statement here. What I would say are the first steps on a very long journey. How we get from 1961 in
[18:17] software engineering to 1962. I'm not promising I will get you to 2025 because we have a long journey ahead of us in developing methodology for this. Um so building and calibrating an LLM judge. This is for relatively simple applications. This is for single turn or
[18:33] kind of relatively simple agents with LM judge based evaluation where you're using generic LM judges across every input and output across your application. Things can get more sophisticated. If you want to look at agentic use cases with thousands of tool interactions or you want to look at multi-turn where you're interacting with a user over and over again, you need to
[18:50] bring more sophisticated methodology and tools to bear. And that's a conversation we can have. But this is the most universal and kind of you know if you're not doing this we shouldn't be doing the more sophisticated complicated stuff yet because frankly you should do this kind of basic stuff first. So first you need to have some kind of proof of concept up
[19:06] and running. This can be something you engineered with your vibes that's fine a prompt. It doesn't have to be God's gift to prompts. It doesn't have to cover every use case but something that is in the right direction that can kind of address your problem. You have to have gotten through that like PC tinkering phase to have something worth playing
[19:22] with. Again, doesn't have to be perfect, doesn't even need to be deployable, but has to be good enough that it's showing signs of life. Um, and I would think of this, you know, your evaluation is your product specification. This is your PRD. This is your design doc. This is your integration test, your unit test. This
[19:37] is, you know, your slideware, whatever you want to call it. This is your specification. You should be able to hand off this eval to somebody else and say, if you can build an agent that passes this evaluation, it's deployable. That's the goal you want to get to. Um, so there's a lot of stuff you got to
[19:52] think about here. I'm going to skip through it because I want to be respectful of your time. Then you need to collect inputs from a target audience or annotators acting as such. What are typical behaviors? What are people actually going to do with this? This can be you just tinkering with the vibes. This can be, and this is a trend I see
[20:08] at a lot of our customers. The person building the AI application is not a subject matter expert. You are really good at AI or data science. You are not a trained underwriter. You are not a trained doctor. that would be amazing if you were a trained doctor who is also really good at AI. Um, if you find me
[20:24] one of those, please let me know. I would love to hire them. Um, usually it's in two people. So, you as the person developing the system need to find the subject matter experts who you're going to whose expertise you're going to try to codify in an evaluation. Find those folks. Find your users. They're usually internal.
[20:40] Um, so you probably need hundreds of inputs. I'll settle for five inputs initially. I'll settle for tens of inputs initially, but ideally in steady state, you've gotten up to 100 to 200 different inputs. And you'll keep adding those over time. You'll find places where this doesn't behave well, and you'll just add that to your eval set
[20:56] over time. Um, in practice, like if you can get me to 50 high quality samples, I am your best friend. If you can get me to 10 high quality samples, that's still pretty good. Um, emphasis on high quality. I would rather quality than quantity. And again, these are just inputs. You don't need to have the
[21:12] perfect output. You just need to have some inputs for now. um it gets you off the ground. Like I'll take it. Number three is you need to define some specific guidelines and annotate according to those guidelines. That's going to be basically what the entire rest of the talk is about. How you actually do this and what this looks
[21:27] like in practice, but you've got to start figuring out what is good look like. This is the hardest part. There's a lot to it. Um and the really important part, I cannot emphasize this bullet enough. You want to reduce the amount of noise. I've seen these amazing scenarios in practice
[21:43] where two people have built an AI agent together. They've worked on this beautiful prompt. They both think the prompt is great. They deploy the system to production. They both think the system is great. I sit them down and have them look at some sample outputs and annotate are these good or are these bad for various reasons. Just free text like tell me is
[22:00] this good or is this bad? And they fundamentally disagree with each other because there's nothing in this entire process that forces you and your buddy who you're working on the system with to actually get on the same page. Prompts are written in natural language. It is very easy for two humans to interpret the same natural language in different ways according to their biases and
[22:16] according to what they, you know, what they wish it meant. And you know what? If you and your buddy disagree, you, your buddy, and Claude definitely disagree. And Gemini disagrees with all three of you and so on and so forth. So, it's really important to get people aligned. And again, I'll talk about how
[22:32] to systematically do this alignment between humans. But until you have a way to get humans to agree on what the behavior should be, why in the world would you expect that anybody else should agree? Like Claude is certainly not going to behave the way you hope because you have two contradictory beliefs about what the system should do.
[22:47] And again, this isn't criticism for anyone who's living in this world. I'm living in this world. Our data bricks products are living in this world and we're constantly fighting our way out of it. Um, but what you really have to do here is create a rubric and guidelines. You know, to give you an example, I've seen medical chatbot applications. I
[23:04] love medical chatbot applications because they bring in a lot of constraints. You have some medical data and you know you want a chatbot that will allow someone to talk to you know talk about their data test results let's say. Now number one or you know a fitness application let's say both of which are scenarios that we've worked on
[23:20] with customers on this thing number one you want is you want medical accuracy. This should be medically correct right you shouldn't be telling people things that are just physiologically wrong. Cool. It should be grounded in their real data. That's another constraint you should have. That's something you can
[23:36] rate and you can get annotators to agree on. Number three, and this often shows up a lot, is it should not give medical advice. You give medical advice, you're going to have a long conversation with the FDA about your new app. And that's not something you want to do. So, these are three categories you need to rate your application on and develop a rubric
[23:52] for what is and isn't medical advice and get your annotators to at least agree with each other. There doesn't have to be something so objective that a third human being can come in and agree with you, but you at least need to have the humans who are rating the data agree with each other. That way you will get consistent results when you annotate.
[24:09] Um, and ideally you have three or more people doing this because you want people to have to converge. This has two really nice effects. Number one is you get some consistent data about like rating on real, you know, you get some real outputs from your system. You need to have consistency in what those ratings are about what is good or is bad
[24:26] so that you can eventually get an LLM judge to rate that as well. But also I found this to be even outside of building AI evaluation a great way to force people who are working on an application together to actually get on the same page. In software we have lots of processes for doing this like design reviews and code reviews especially code
[24:42] reviews because you look at the code and it is objective. There is no disagreement about what the code means and does. There are semantics. Everybody should interpret the code the same way. With AI, there is nothing in the entire AI life cycle that forces you to do this beyond literally sitting people down and having them annotate data and then talk
[24:58] to each other and say, "Wow, we annotated this thing about medical correctness completely differently. We need to get on the same page about what we mean by that." It's been a great alignment exercise for the humans who are trying to build this. I've actually found this to be really valuable just from a business perspective for a lot of our customers. Um, there are real
[25:14] statistical measures you can use to look at whether humans, as they rate many examples, agree with each other or not. And there are values that we consider good or bad for this. And this is, you know, this is not new. This is not revolutionary. This is not invented at data bricks. My name is not
[25:29] Crypendorf. Um, it's Jonathan. But, you know, this nice guy named Krypendorf created some really good correlation metrics that we tend to use for looking at multiple raers and how much they agree over a wide variety of different examples. And then number four, the fun part. Once
[25:45] you have some human ratings according to let's say these three axes we came up with. We have three human annotators rate some data along these axes. You know scale of one to five. We have them talk to each other a bunch and debate like hey is this really a three or is this a five and then update our rubric
[26:02] to kind of help codify that so the humans can agree with each other. Iterate a little bit and get to some consistent ratings across 50 to 100 examples. The next thing we want to do is ask an LLM to do literally the same thing. We're going to just prompt engineer an LLM to try to be a judge against this rubric.
[26:17] What we care about with that LLM is, is it rating the same way as the humans? If I add that LM as a fourth raider, will my correlation metrics still look good? Did I basically manage to distill all of my human expertise from my human raers into an LLM using a prompt? There are lots of techniques to do this. These
[26:33] days at Data Bricks, we love prompt optimization techniques, techniques like jeepa. Um, if you're not familiar with that, I would love to talk to you afterward. I think this is the best thing since sliced bread for LLMs because you have a system that will automatically optimize a prompt for a metric like agreement with some human raiders so that you don't have to sit
[26:49] there manually tinkering with the prompt and hoping that if you get the keywords exactly right or offer the LM a bribe or threaten the LM or whatever you have to do you get it to behave in the way that you want. Once you have this you have basically taken your human raiders all of that human expertise and you are modeling it with an LLM. You can now use
[27:06] that LM judge that you have created to go and rate future examples. And you know that that LM is relatively well correlated with what your humans can do. You have scaled your human expertise into an LM so that now you have a consistent way to rate new examples and
[27:21] new behaviors and new outputs. If say Gemini 3 comes out and you want to see how it does versus Gemini 2.5, you have a way to do that without getting your three annotators together in a room ruining their day having to annotate data again and so on and so forth. And the nice thing is as you annotate more examples, as new corner cases or
[27:38] scenarios or problems come up, you can annotate them, integrate them into this evaluate the judge using a prompt optimization technique, and you've already scaled and updated your eval. So, I'm going to skip ahead a little bit because I'm already running low on time. Um, but the important part, this is iterative.
[27:54] I wish this was one and done. You are building a robust data artifact that you can keep using again and again and again, a robust measurement, but it is not one and done. not in the least. Um, this is something that you will constantly improve. Think of the example with Google where by merely putting AI
[28:10] into the system, you have changed user behavior and you have to adapt to that. We've worked with Fox Sports on kind of a chatbot about various sports applications and I'm guessing that, you know, when we're back in baseball season in a few months, we're going to have to update that again. There's going to be some work to do to improve the agent
[28:26] because, you know, right now we're in core football season. Um, we have products for each of these stages of the pipeline. This is kind of, you know, when I say we take the research building these kinds of methodologies and getting them out into our products, we have products for each of these. We have Mosaic AI model
[28:43] serving to actually get your PC up and running and our model gateway. You can use any of the popular LLMs, Gemini, Claude, OpenAI, Llama, Quen, what have you. You can use all of those on data bricks. It's really simple. We have MLflow to help you collect these these
[28:58] outputs. We have our review app and other MLflow based tools. And then we have agent evalu
[29:13] teams until they actually serve my needs for my team. And hopefully if they're good enough for me, they're good enough for you. That's the idea. And you know, this is kind of the last part while I'll advertise a little bit. Ask about our human eval preview. Um, we're taking this on the road and we're literally running workshops with my researchers, with customers right now to
[29:29] keep improving this workflow and then getting that into our product. And that is an open offer. There's gonna be a QR code in a moment where you can just go to a a Google form and sign up. Um, takeaway key takeaways very briefly. Quality measurement is necessary. I would say quality measurement is the most necessary thing. This is the
[29:46] programming, the software engineering of AI. It's not prompt engineering. I kind of think prompt should go away eventually. The thing we should do is build measurements and then have various systems that will automatically build us a prompt to make our measurement good. That is what I think the future of AI engineering is going to look like. Um,
[30:02] we have these three dimensions. It helps you take the space of all possible behaviors and break it down into something that's a little easier to brainstorm about. Um, and avoid the Bermuda triangle. I'm sure we've all had AI applications that have gone into the PC stage and have never been seen or heard from again. I certainly have and
[30:17] we're getting better internally at data bricks about avoiding this and you're seeing that in our products. But the bottom line, do this systematically. Vibes are not good enough anymore than they would be for software. Um, so you know, I'm going to go ahead and just stick this up here. Um, you know, we do
[30:32] have a workshop where we're doing this. This is kind of advertising for a data bricks product work in progress, but if you're interested in this, you have an interesting AI application, we would love to work with you. Um, we're trying to run this with, you know, a few dozen folks in 2026 because every time we run this, we add some features, we try some
[30:48] new stuff. you're part of helping us refine this methodology and then it all flows into our products that you get to use even if you're not doing this. Um, but we we have lots of techniques for doing this. It's actually been pretty popular these days. Um, ping this, you get to hang out with me. If that's a perk, great. Um, so, you know, maybe one
[31:06] other thing I'll say, a little bit of tough love um, from me. Um, this is a lot of work. It's a lot more work if you deploy something that's bad. Good luck cleaning that one up. We can all look at the famous examples of the AI chatbot that promised fle free flights or flight refunds or things like that that were
[31:22] just wrong. Um much worse things can happen if you don't measure. Um we've already learned this lesson extensively with software testing, but it kind of seems like when people say the word AI, all of our knowledge about software just disappears and we go back to 1960. Um we're here to help. Like
[31:38] my team, we're a bunch of AI scientists and our job is to figure this stuff out and work with you to do that. that takes us back to really cool fundamental research problems. Um, I want to highlight just one last quote. This is a quote that I love very much. Um, and
[31:54] then I'll give you the origin of it in a moment. To put it quite bluntly, um, as long as there were no machines, programming was no problem at all. When we had a few weak computers, programming became a mild problem. And now we have gigantic computers and programming has become an equally gigantic problem. Um,
[32:10] one last piece here. Um the increased power of the hardware made solutions feasible that the programmer had not dared to dream about a few years before. And now a few years later he had to dream about them and even worse he had to transform such dreams into reality. Is it any wonder we found ourselves in a software crisis? Um this is a quote from
[32:25] Dystra in 1972. Dyster's algorithm shortest paths like early software engineering from his touring award lecture in 72. It's worth reading. I've been reading a lot from the 1960s lately just because I think the 1960s were a very similar era where the complaint was
[32:42] the computers are faster than our methodology to actually make effective use of them. And I think if you swap out the word computer for AI and the word speed for intelligence, I think we're in a place where we don't actually know how to squeeze the most value out of the AI systems as they exist today. You could give me something even smarter, but if I
[32:58] can't measure whether it's doing the right thing or tell it what to do in a proper, clear, simple way, it doesn't matter. You could have given someone in 1962 an H100 with many orders of magnitude more compute than existed on the planet and they still would not have been able to get any more value than
[33:14] they did with the computers of the day. And I think this is kind of the moment we're in. I think that really good measurement is the path out of it. So, with that, I'm going to wrap up and introduce my friend Arvin from the World Bank. Um, so I probably don't need to tell this crowd what the World Bank is, but I will say the World Bank's mission
[33:31] is to end poverty worldwide. Um, you know, nice, easy, simple mission. Um, you know, I'm glad they took on something really straightforward and really easy like, you know, I'm glad somebody's doing No, it this is like I don't think I need to tell you how important this is. doing that with
[33:46] limited resources by making loans to the right organizations at the right times is really hard. Um, and one of the things that you're going to hear about from Arvin in just a moment is how they're measuring that. Um, what he's going to show you looks deceptively simple. There's a great set of
[34:02] dashboards you can go to online and see how the World Bank is doing at ending poverty statistically. It looks really simple and it is built on data bricks. It's using a huge number. I think the number is hundreds of different data sources being brought together onto data bricks managed with
[34:18] Unity catalog and computed into these really nice deceivingly simple looking dashboards. That simplicity is being made possible by the fact that you can bring all this together in one platform. I'm not going to spoil it though. I'm going to let Arvin tell you the rest. But thank you all so much.
[34:39] Thank you John. Good afternoon everybody. I'm Arvin Shinasan, head of data and analytics at the World Bank Group, representing a fantastic team of data professionals across the globe. We have teams in Washington DC, Chennai, and Sophia. So, shout out to my fantastic team. Um um
[34:54] what we have today is a brief 10-minute presentation about our data journey. John talked a little bit about know measuring uh impact and I have few slides that cover that topic.
[35:10] So starting with the mission of the World Bank Group as John touched upon that at the end of his presentation. Our uh mission is to end extreme poverty and boost shared prosperity on a livable planet. Uh I am part of the IT organization within the World Bank Group and our mission within the IT
[35:26] organization is to leverage information and technology as a force multiplier to accelerate, deepen and sustain development impact. So this is the organizational context in which we operate in.
[35:42] So what are some of the drivers and challenges that we are up against. Um by 2050 about 80% of the world's population will be living in what we are considering as developing countries. So about 1.2 billion people will be
[35:57] confronting a labor market with a projected offer of just 400 million jobs. So everything we do is in support of this mission which is to make sure that people have an opportunity to earn a living and support their families and shape their futures. A very noble
[36:13] mission and data supports these directly and indirectly by innovating developing fantastic data products that support uh datadriven decision- making and also supports corporate risk and compliance management. Some of the challenges that
[36:31] we have are very typical to every other organization. The three Vss volume, variety, velocity. So we deal with all of this. We are a huge organization. We are made up of five different institutions. We deal with internally produced data and externally partnered
[36:47] data and procure data. We as other organizations do as well have data silos and fragmentation and duplication and we need to manage that. uh we need to figure a better way to get the business to lead data governance. Without good quality data governance, we
[37:05] are going to struggle with by producing high quality data products and it cannot do it all. So how do we democratize data and promote self-service uh so that the business colleagues can also contribute to accelerating data and insight
[37:21] delivery. So just to give you a sneak peek of our ecosystem. So across the data value chain. So we deal with many different uh data sources. We get as I said data from
[37:36] across 180 countries. We keep data as far as 60 years ago and more than 60,000 indicators and data sets that we manage. Lots of users that use our data products both internally and externally.
[37:52] So our data journey started sometime early in the 2000s when we implemented our ERP system and we acquired SAP business warehouse abbreviated as BW as the first data warehouse platform and then along the way we expanded to other
[38:07] data warehouses and then in early 2010s we uh acquired a virtualization platform um which was called Cisco or composite at the time then Cisco and Tipco have recently acquired it and then when the organ organization adopted our cloud uh
[38:23] journey, we also jumped on board and we had our first data lake which stored a lot of our data in there and then in late 2020 we started piloting and embracing the lakeos architecture and data bricks is integral part of that
[38:38] architecture. Currently we are experimenting prototyping on how do we unlock the power of Agentic and Genai in support of our mission.
[38:54] So keeping uh with the theme of measuring impact I'll talk about three key case studies. WBG scorecard um you can actually check this out scorecard.worldbang.org uh is the website. This is our scorecard of how we are delivering our impact. So
[39:11] we moved from measuring outputs to outcomes. There are three kinds of indicators that you would see there when you go to the website. One is called the vision indicators. What problem are we trying to solve? Where do we expect the organization or the the world to be in? Second set of indicators are called
[39:27] client context indicators. How are countries performing in their own context because data without context isn't that useful. And third are results indicators. So what is the impact of the work that the world bank has done? So in a very short time frame we had to put
[39:43] together a nextgen data platform to support a federated data architecture. All five institutions within the world bank group had to feed their results and the context indicators to make sure that we can produce uh this uh scorecard. And
[39:59] we also had to establish data contracts and implement it for the first time in the organization because we wanted rapid agility and loose coupling and interoperability across the organization. And this project won the president's award for the impact that we produce and
[40:16] the high quality work that we did. The second case study is what's called data 360. Again, another solution you can check it out uh data.worldbank.org. So data 360's uh vision is how do we enhance the efficiency, the quality and
[40:34] the coherence of development data ecosystem. When you go to data.worldbank.org, you will see a lot of open data sets and the World Bank group is a biggest contributor to the open data environment and a lot of countries and partners use World Bank's data to make decisions. So the key
[40:51] themes behind this is transparency, reproducibility and international standards. Given that we have to operate in this context, we had to build a solution that supports these three pillars and implement a product that can underpin
[41:09] this entire theme of improving the quality, coherence and efficiency. So this platform powers through close to 13,000 data sets and indicators that are available for all of you to use and it's constantly churned, produced, validated and enhanced uh throughout its life
[41:26] cycle. The last one um the case study that I have is around the metadata. Just like in every other organization, metadata is the last thing on anybody's mind. But without metadata, the users of the data always struggle. So they don't understand what they're working with.
[41:43] And as a data team, when we go to the business and say, "Hey, we'd like metadata." That's the least priority, right? They have 100 other things to do. And they say, "Okay, your ticket number 2017." And like, "Okay, hold on a second. When would we get to that?" So
[41:58] when the Genai era came along, we said, "Okay, is there a different way to process this?" So with the unity catalog in place, so we took a different approach and saying how can we dip into the organizational policies, procedures, guidances, directives, manuals and use
[42:14] that knowledge of uh the organization and use that to scan all the data elements, the business terms, the reporting elements in the Unity catalog and can we auto augment these data sets by including
[42:30] metadata and that went from so we had for the longest while plateaued at about 2,000 to 3,000 data elements over multiple years and with the introduction of this we zoomed to 60,000 within few months because we could now
[42:46] programmatically and automatically unleash the power of AI against our data. The last slide uh or last but one slide that I have is what are we doing with agentic AI at World Bank Group. This is hot of the oven. So we just rolled out
[43:01] this prototype a couple of weeks ago. So let's look at the use case a little bit. When someone says I'd like to get a list of trust funded projects in Nigeria for a fiscal year and give me allowable expenditures. If you look at this
[43:17] problem, it's a problem of bringing in unstructured information and structured information and answering a question. And we all know how well this goes. So it's a problem of compound AI. Good luck. John talked about you know dealing
[43:33] with hallucination and is the data reliable and good luck with with that problem if you can't have a meaningful integration of unstructured and structured data. So our approach to this was to use uh langraph and lang chain
[43:48] and develop something um within the world bank group. So within a domain any domain in this case trust funds you have different subject areas and given that the genie rooms within data bricks have a limitation I don't remember I think 20 or 25 tables is the maximum within a
[44:05] subject area so we stood up multiple genie rooms for each of these uh subject areas within a domain and that would be responsible for translating your query into NLQs and going and retrieving data from authoritative and approved data sources and then We developed a rag
[44:23] engine that would go into these policies, procedures, manuals. In this case, what are the allowable expenditures? And then you have domain supervisors that's figuring out which subject areas and which genie rooms and which rag engines to route this to get an answer. This is incredibly exciting
[44:40] times for the business because imagine doing this manually today. So we do have fancy AI BI products that brings you all the analytics. give me list of trust funded projects great for a fiscal year great in Nigeria great but I can't join
[44:56] this allowable expenditures because that's sitting in a different manual in a different document and it may vary based on trust funds so the next step um for us is how do we go forward adopting agent bricks we are
[45:11] excited for the announcement today um using agent bricks and uh AI genies we want to take this to the next frontier Wrapping all of this up with the impact and the next steps. We talked a little bit about the measuring the impact at the mission level. The scorecard does
[45:26] that and we're incredibly proud of you know being uh part of that project um within the IT environment. So we have been able to turbocharge the adoption of data products by using uh the um nextG data platforms. We have improved the
[45:42] data uh onboarding time. We've decreased the pipeline development time. And last but not the least, we now have a very thriving marketplace with more than 65,000 indicators accessible and use and available for use. The next steps is to build on the uh traction that we have
[45:58] within the agentic uh and the compound AI space and unleashing this power to solve cross domain analytics problem. With that, I'm going to turn it back to John. Thank you.
[46:17] Please thank Arvin for for telling us all this. I can talk about chat bots all I want. Um you know ending extreme poverty globally. Hell of a mission. Um hell of a monumental task. With that I just want to thank everybody for coming to this session. I hope you took away the importance of measurement and evaluation for AI. It's not just a nice
[46:34] to have. It is the whole ball game. Um we're working really hard to make that possible for you at data bricks. everything from the science of how to do it um all the way up to the tools and products that will allow you to do it really easily, really well at scale. Um so, thank you all so much.

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.