1,368 AI Failures and What They Teach About Evals — Vishal Srivastava, New York Life & Tanmay Sah

AI Engineer · 20 min · 169 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:01[music]
00:12A big part of my research is looking into AI failures, investigating it, and then learning from it.
00:18And joining me is Tanmay Shah.
00:21Yeah, hi everyone.
00:22I'm Tanmay Shah.
00:23I'm a senior quantitative modeler and an AI researcher.
00:27This is my second time here, so it's great to be back.
00:30So, I will hand it over to Vishal to get us a started.
00:34So, we looked at AI incident database.
00:37It's a publicly available AI incident database, and we looked at the AI failures and asked one simple question, what these failures teach us about how this is how the AI system should be evaluated,
00:54and if we can apply those learnings to system level evaluation.
01:02So, the first thing that we see is that AI failures have been increasing exponentially.
01:08And if you look at the last four years of AI failures, particularly in the foundational model era, you see that the jump is almost vertical.
01:20And many of us feel that the number of AI use cases that we have in enterprises, they they are much larger than our capacity to review them each one by one.
01:35So, what we argue is that we need a structured way to investigate these AI failures.
01:43And to do that, we look at the AI failures essentially into three dimensions.
01:50The first dimension is the development stage, when the model and or the AI system is developed.
01:58So, it could be issues with respect to data quality or tool architecture or system design.
02:06Any of these things during the development phase can can break and once it happens, then those errors can be propagated to the next dimension, which is the deployment phase.
02:19Now, even if the model or the system has some faulty design issues, but if you have sufficient controls in deployment, those errors can be contained.
02:33And that is why it is very important to kind of understand what kind of controls do we have in deployment and whether we can contain those failures from reaching
02:45from deployment production platform to the final stage, which is the context in which the AI system is being used from a business standpoint.
02:56It could lead to reputational risk.
02:59It could lead to legal or financial risk and all those business context really matters for the AI system in which it is being used.
03:08And what we say what we propose is that the model alone or the technical strength of the model is just one part of the system.
03:17We have to look at the system holistically.
03:23So, after defining those three core dimensions, the technical strength where the system should be strong or in opposite way where the system can break, the second dimension is how do
03:37we ensure that the deployment controls are in place?
03:39And third, the business context the AI system is being used.
03:44We divide each of these core dimensions into several sub dimensions.
03:52So, in the from the technical strength point, right?
03:55There could be six major sub dimensions which could be affecting the technical strength of the AI system.
04:02It could be first related with the data quality that we use for to build the AI system.
04:08How the system has been designed for the appropriate task that it is supposed to accomplish.
04:14How is the predictive validity or outcome analysis of the out of of the AI system?
04:20Does that system perform as we intend?
04:23Um there could be fairness related um checks.
04:27Um failure modes essentially looks at where when, how, and for whom the uh system can break.
04:36Uh so, basically mapping out all the failure modes of the system.
04:40And finally, can we explain for uh explain the decisions for the regulators or other bodies uh so that we know how the system is arriving at its decision.
04:50So, these six sub dimensions are essentially part of the technical strength of the AI system.
05:00The next four are essentially looking at how we are using the model.
05:04Um what kind of authorities we have given to the AI, right?
05:08Is the AI for informing us or it it is out there to act on our behalf.
05:14What kind of decision authority are we associating with respect to AI?
05:18Uh second one, human mediation.
05:20Um how effective is human in the loop process is, right?
05:25That's really important.
05:26The third one, exposure control.
05:28Who's actually using the uh system?
05:30Is it internal employees so that they see the error and they can contain it or it is exposed to the out there in the wild external customers so that any small issue can really propagate fast.
05:43And finally, what kind of monitoring uh controls that we have so that we see some uh issues in production and we detect it and we can contain it.
05:54Finally, in the financial or the business impact phase, we see these three core sub-dimensions.
06:01What kind of financial impact it would make if there is an error?
06:05There could be legal consequences and how many users would get affected?
06:09That's the the last one, the scale sub-dimension.
06:15So, we we we look at this this as one framework which has 13 dimensions and three core questions as we explained.
06:27Once we define these 13 sub-dimensions and look back at AI incident retrospectively, we find that using these 13 sub-dimensions, almost 98% of AI failures can be covered.
06:40Meaning that AI failures are are associated with some of these dimensions, in some cases multiple of these dimensions, and in some cases few of these dimensions.
06:51But, these dimensions are involved.
06:53So, failure AI failures have structures.
06:57We need to map it and we need to act accordingly according to these sub-dimensions.
07:04Now, as I mentioned that some of these failure sub-dimensions can be present in these failures simultaneously.
07:12Meaning that when something goes wrong with respect to a particular failure, there may be multiple things going wrong.
07:20What we find is that on average, there are six failure sub-dimensions that can be present in each of these AI incident failures that we we we have investigated.
07:35Now, the question comes to our mind is that are all of these sub-dimensions are equal or some are more important than others.
07:43And the answer is that some of the sub-dimensions can be more critical than others.
07:50And what I'm showing you here in the in the plot on the Y-axis is the association to harm when these sub-dimensions are present.
07:58And on X-axis, we have the frequency of these sub-dimensions being present.
08:03What we see on the left upper side of the plot, sub-dimensions like human mediations or effectiveness of human in the loop, harm detection, meaning that whether we have monitoring
08:15control in place.
08:17On on X-axis, we see things like scale and system design.
08:21Although they are present in many cases, but they are not associated so much with harm as some of the some of some of the earlier sub-dimensions that I have mentioned.
08:32So, when we are really looking at the AI systems, some of these sub-dimensions can be really critical.
08:39So, we need to prioritize these sub-dimensions by the potential of making harm, and then allocate appropriate resources to the to the investigation of these sub-dimensions rather than looking at all the failure sub-dimensions
08:54equally.
08:59And when we club the when we group these sub-dimensions together, we see that controls that we have in deployment are more critically associated with harm, followed by the business impact, and followed by the technical failure.
09:12So, this plot is essentially telling us that once once we have deployment controls taken care of for the high-risk system, that gives us some level of assurance that we can take care of the failures in
09:31in advance in contrast to just looking at the technical failure alone.
09:36So, all these sub-dimensions are important, but deployment controls are far more important.
09:43And what in the next phase what we did was we we designed a materiality scale, meaning that if we can understand which AI use cases are more risky compared to some others,
09:59we can we can prioritize these AI use cases based on materiality because materiality directly rank orders with respect to the harm associated with this AI use cases.
10:12Meaning that we can spend suppose we know which AI cases are more more material then we can allocate more resources to much higher material AI use cases than compared to some other AI use cases which may not be as material.
10:29With that, I would hand over to Tanmay who would explain how we can use those learnings to build system-level evals.
10:37Thanks, Vishal.
10:40Uh so, so far as we have seen what these failure teach us, so now let us use those lessons to build system-level evaluations.
10:50So, first first of all, what we did is that we have decomposed risk into four components, which are how often the model fails, whether that failure reaches a real decision,
11:03whether it goes whether it goes uncaught, and how severe the consequences are.
11:09So, in this scenario, the deployment setup matters, how much authority does the system have, does someone review its output, can monitoring catch error before it causes harm?
11:24So, this same model can create different risk depending on how we deploy it.
11:30So, what we are saying is that if risk depends on the whole deployment system, our evaluation needs to cover that setup, too.
11:40So, that brings us to the next question.
11:43What should we test in an agentic system?
11:47So, see, in traditional machine learning, we already know how to challenge models.
11:52We test their assumptions, input data, and behavior under stress.
11:56Now, when we extend that discipline to the whole deployment system, then, like, does retrieval bring back the right information?
12:06Or what happens when a tool fails?
12:08Does human review catch mistake?
12:11Or does the agent stay within its permission or boundary?
12:14And can the system finally recover?
12:17So, here the logic stays the same.
12:19The boundary of what we test gets bigger.
12:23So, now the question is, how should we test an agentic system?
12:28So, on the right, we have the familiar traditional ML.
12:32We test a model on held-out data, calculate metrics like accuracy and AUC ROC, use those evidence to inform deployment.
12:41But, we still need to check the data and assumptions behind those metrics.
12:46But, on the left-hand side, we have an agentic system which adds new complexity.
12:52So, the deployment system, like, it has many possible inputs, tool responses, and action sequences, or trajectory, or rollout, whatever you dis- say.
13:04So, we test selected scenarios.
13:06Sometimes, another AI uh agent or AI judge generates those tests or judges the result.
13:14So, but that judge can make mistakes, and the test can miss important failures.
13:22So, this is where we need to check whether the evaluator is reliable, what the evidence covers, and whether it applies to the system we are actually deploying it.
13:32That's why the evaluator is the part of the system we govern.
13:37So, now I will hand it over to Vishal to explain how we can check whether an evaluation is reliable and what to do when it is not.
13:48Thank you, Tanmay.
13:49So, we have seen the system level evaluation for evaluator as well as you know, the whole AI system.
13:57The question is that how should we really And when I was looking at some of the previous research, particularly in the area of cognitive neuroscience, what I found was the um this
14:12the scientist Peter Wason, he's the one who coined this term confirmation bias.
14:19And essentially what he did was he did a bunch of experiments, but essentially uh in this case here, the series that you see 2 4 6, right?
14:28He was asking people to predict the next number, and more often than not, they were predicting 8 10, like even numbers.
14:34But those answers was those answers were incorrect because essentially the correct number was any increasing number.
14:42Essentially proving that all humans, like most humans, um in this case it 79% of people tested wrong.
14:50Um may have some sort of confirmation bias.
14:52And AI systems, as we know, uh are trained on human-generated data.
14:58So, what what he proposed was that any evaluation or any any evaluation that needs to be done has to falsify, not to confirm.
15:10And that that's the way to go about it.
15:11And we take that learning from his research and propose that eval system needs to be failure-driven.
15:19So, if the eval systems are failure-driven, what would that mean?
15:23That would mean that you would start right from looking at your system claim and testing it and trying to break it and then identify where the system claims are breaking, right?
15:35And then what you do for fix?
15:38Either you uh don't let the AI system run in you know, in the in the in the territory where uh there are failures or you come up with uh supporting systems, right?
15:50Which you are confident of.
15:52And you keep doing it iteratively uh until you get um you to the to the level of confidence, right?
15:59This is essentially the first principles based approach that we propose for any evaluation system.
16:06So, essentially you take take your AI systems, perform this build-break-fix loop, understand where the AI systems could be trusted in terms of its uh uh final outcomes, and also
16:20a map out uh the uncertain region and high-risk region where you can not be very sure of the system's performance, and you map out the entire failure region map and route it based on the reliability and materiality,
16:36meaning that particularly if you're using AI for any high-risk rated system, make sure that your AI is only being used for um the the the region that you're confident of.
16:52And with this, I will hand over to Tanmay who who who who would apply this approach to a real uh AI failure case.
17:03Okay, I sure.
17:04So, uh so, uh let's make this framework concrete and see how a narrow evaluation can miss failures uh that matters in the real world.
17:13So, I will quickly go through the story behind it.
17:15So, a customer needed to travel after a death in the family.
17:19He asked an Airlines chatbot about a discounted fare.
17:22The chatbot said he could buy a regular ticket and claim the discount afterwards within 90 days.
17:28So, he relied on that advice, but the airline later refused because its policy uh did not allow that request.
17:36Then finally, the tribunal held the airline responsible.
17:40So, through this example, we we are seeing the failure chain.
17:45So, it's crystal clear.
17:47So, incorrect advice reaches the customer, the customer acts on it, and the organization faces the consequences.
17:55So, if we apply our build, break, fix, and break again approach, uh that could have exposed the failure way before the deployment.
18:03So, we Ideally, we would start with a clear requirement like advice must match the approved policy.
18:10Then we would challenge the chatbot with questions about refunds after travel.
18:16If those tests exposed incorrect advice, then we could add a policy check or human escalation.
18:23Then we would test again to see whether those controls caught the errors before it reached the customer.
18:30So, that's our framework in practice.
18:32We have to define the claim, actively challenge it, and use the evidence guide changes and make a deployment decision.
18:41So, finally, I will hand it over to Vishal to bring the pieces together and conclude.
18:49Um this is our final slide.
18:51So, essentially, what we are saying is that your evals should be risk-based um rather than frequency-based.
18:58You should look at your uh entire system and then break it into the core components like technical uh failure, deployment controls, and business context.
19:08And then assess your AI use cases materiality with some uh scale, uh and that could be your company specific scale and risk should that risk could change.
19:20And then once you have that, apply the system level stress testing on the AI use case.
19:27And then once you are confident about the region, then only make the deployment decision.
19:33Otherwise, it may be too expensive.
19:36Our final takeaway message is evaluate the full AI system based on risk, not just one component.
19:45Thank you so much for your time and attention.
19:47You can feel free to reach out to us outside.
19:51We'd be happy to take any questions later.
19:55[applause]