Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work

Talk transcript

1. 0:00

   [upbeat music] All right.

2. 0:15

   Well, let's get started. Uh, we don't have much time, but, um, I hope your conference is going well. Uh, welcome to AI Engineering World Fair. Uh, my name is Dat Ngo.

3. 0:24

   Uh, today's talk is about LLM Eval Pipelines. Um, so I never know what I wanna talk about till I get into the room, so I don't prep too hard.

4. 0:31

   But by show of hands, who here, uh, who here has built, uh, an agent? Just raise your hand. Okay. Uh, who here, um, has run an eval?

5. 0:42

   Right. Who here has productionized an AI product? Nice. Okay. Some technical builders. Um, let's get technical then. So, uh, my name is, uh, Dat. Um, I'm an AI architect at Arize AI.

6. 0:56

   Um, this is Mochi and Lati- uh, Latte. They're, uh, dogs of my friends. I figured let's, let's keep it spicy and interesting. Um, but I've been building observability and evals since, since day zero.

7. 1:07

   So, uh, since the first... Uh, I don't know if you guys know what Arize AI is, but we are the largest, uh, AI evals player, uh, in the space, so observability, evals, kinda beyond.

8. 1:18

   Uh, we work really heavily, uh, with, with real use cases, so folks like Reddit, folks like Duolingo. Um, so we work across the best AI teams, and we have a really unique business.

9. 1:29

   Being on the observability side, we get to see what everyone is building,

10. 1:34

    how they're tackling those problems, what are their biggest pains, uh, and what are the kind of the tips and tricks that they use to, to really productionize these things.

11. 1:41

    And just to give you a s- a hint, um, you know, Duolingo has massive eval scale. They tend to run about twenty evals por- per, like, um, trace. Um, so they end up spending, you know, quite a fair amount, uh, doing evals, understanding their evals, optimizing them.

12. 1:57

    Uh, and the last thing about me, I have a huge passion for the AI community. Um, when I was in SF the last five years, uh, really loved to go to pretty much every single event that I could.

13. 2:05

    Uh, I'm not a developer advocate. I'm an engineering-- uh, an engineer by, by trade, but I just love the community. So, um, yeah, this is a little bit about Arize, but I think I don't wanna keep it too salesy.

14. 2:15

    I just wanna keep it pretty technical. So really three concepts that I think everybody should be familiar with and where evals really sit in the space is, is really as simple as this.

15. 2:24

    Um, this is what I teach all my customers. Really, the first thing is observability. I think you guys have kind of seen this before. Observability really just answers the question of, what is the thing that I built actually doing, right?

16. 2:35

    To some people, it may be traces, uh, traces and, and spans. Um, I'll show you a little bit. Um, it, you know... Platform agnostic, just, just think about the concepts.

17. 2:45

    Um, but traces might be one, one area for people. So traces represent, hey, what's happening? Can I look at things? Uh, to an AI engineer, makes a lot of sense.

18. 2:54

    Um, let's say you're an AIPM, maybe not super technical, or maybe, uh, you wanna think about things differently. Maybe you wanna look at, hey, what are the conversations that are happening?

19. 3:03

    Turns out you can run evals at these levels. Uh, we'll get into that in depth kind of later. Um, you know, signal comes and observability comes in different kind of flavors and forms.

20. 3:12

    Maybe it's, it's analytics. Uh, what we're starting to really realize is that LLM teams are getting split into two special niches. There's platform teams, right? And they, they own things like the, the infrastructure.

21. 3:25

    So who here has heard of a, a model gateway router? Uh, it's like an interface pattern. Behind it are all the models, right? Well, it turns out the central LLM platform team tends to own that.

22. 3:34

    They care about cost, latency, things like that. And then you have the other LLM teams. These t- these LLM teams sin- team, uh, sit on the, like, the outer side of the business, so like a hub and spoke.

23. 3:45

    They work for the business side. So these are like, uh, the people building the applications to help the business. So, um, if anyone here comes from, like, the, the ML or, or data science space, it's actually not far from that.

24. 3:56

    Um, and so different teams care about different metrics. Uh, so maybe if you're an AIPM sitting on the business side, you care about evals. If you care about, you know, the platform, maybe you care about costs, latency, things like that.

25. 4:08

    But TLDR, uh, observability... Oops. Uh, observability, um, represents what's happening. And now evals are really important in this space because the reality of the fact is, if you've ever seen a trace or something like that, um, you're not gonna inspect every single trace manually, right?

26. 4:26

    It is not scalable for you, an AI engineer, or you, the AIPM, to look through these things. So what is eval's use for? It's actually just a really clever word for signal.

27. 4:36

    You're just trying to understand what's going well and what's not going well. So I'm not here to sell you on, like, evals. I think everybody knows how important they are.

28. 4:43

    But if you think evals, evals are LLM-as-a-Judge only, uh, there's actually a lot of other tools that you're missing. So LLM-as-a-Judge, raise your hand if you used LLM-as-a-Judge. Okay, about half the room.

29. 4:55

    Um, it's super great. Uh, you use an LLM to give you feedback or process on, on any process, including an LLM process. So if you're doing RAG, this is a really good way to, to think about RAG in terms of evals.

30. 5:07

    Um, RAG would be like, hey, user has a question. Um, we retrieve some context to be able to, you know, possibly answer that question, and then we generate an answer.

31. 5:17

    Turns out every arrow on this is actually an eval you can run. So, hey, I retrieved some context, and I wanna compare that to the query being asked. Well, that's RAG relevance.

32. 5:26

    It's like, is the thing that I returned even helpful in answering the question? And so LLM-as-a-Judge is great. It's super helpful. Um, you know, I think most people understand why it works, but there's a whole, there's a whole research area on why they're really good indicators.

33. 5:41

    Um, the original task is not the eval task, right? So if I asked you, a human, "Hey, generate me a summary on, uh, something long and complex, like the book War and Peace," uh, that's a very different task than say, "Hey, I wrote this summary for you.

34. 5:56

    Is it a good one or is it a bad one?" But LLM-as-a-Judge is, is a small part. Um, it doesn't always have to be a large language model or autoregressive model.

35. 6:05

    Um, things like encoder-only BERT-type architectures are super helpful. They're about ten times cheaper, um, about one or two orders of magnitudes faster, uh, to run that eval. But, you know, you don't just have LLMs at your disposal.

36. 6:20

    You, a human, also are a really good way to discern signal. So it turns out evals can also come in the form of, is your user having a good or bad experience?

37. 6:27

    So for those people who've productionized, uh, some sort of LLM application, do you guys have user feedback? Raise your hand if you've implemented user feedback. And okay, about thirty percent.

38. 6:37

    Uh, it's actually incredible signal. Um, so that comes from a human. Obviously, you yourself can also generate labels on stuff. So has anyone here heard of a, a golden dataset?

39. 6:46

    Raise your hand. Okay, most of the room.

40. 6:50

    Um, and the way I encourage folks to think about this is a pro tip, actually. If the first column represents scale... So LLM-as-a-Judge is valuable because I don't have to grade it myself, right?

41. 7:00

    But let's say I don't necessarily trust it off the bat. Use the third column to help you out. So a golden dataset represents quality. So you yourself graded it.

42. 7:09

    You know that it's, it's what you expected, you know. Um, well, it turns out you can run your LLM-as-a-Judge on a golden dataset. Um, what you're trying to do is say, "Hey, can the LLM approximate the thing that I trust?"

43. 7:21

    Right? And what that allows you to do is to actually quantify and tune your LLM-as-a-Judge. So we'll go over that in a second. But strong pro tip, uh, most really strong LLM teams in the world kind of do this today.

44. 7:33

    Uh, and it turns out you don't always have to use an, an LLM, uh, or a human. You can use what are called, like, heuristics or code-based logic. So I'm gonna take you into the platform a little bit to talk through it.

45. 7:42

    But, um, in our platform, you have a way to, to run evals, great. Uh, what code evals actually are, um, are just, um... it's much cheaper, so I'll just run a little test here.

46. 7:53

    But, you know, let's say you wanna say, "Hey, does this output contain any keywords?" I don't need to use an LLM or a human for that. I can just use code.

47. 8:01

    It's infinitely cheaper, um, faster to run. Um, does this match this regex pattern XYZ? Is this a parsable JSON? So the reality of it is you have this kind of, uh, large toolbox in your kind of, uh, eval set.

48. 8:15

    So when you say evals, don't just think of LLM-as-a-Judge. There's a whole other set of smarter things that you can use that are actually more cost-effective. And so really, you know, this is a really good way to, to emphasize really the value of, like, the AI engineer evals and observability.

49. 8:31

    Most people understand this, this left-hand circle, this purple one. Um, it actually represents what we all wanna do, and it's like, hey, build a better AI system, right? So what you do is you collect data, observability, traces, things like that.

50. 8:43

    Then you run some evals to say, "Hey, did this process go well, or did this process not go well?" So you're discerning signal from that, you know, mass of data.

51. 8:52

    You'll actually collect where areas of things went right or wrong, right? And you'll say, "Hey, turns out we hallucinated on this. It's because our RAG strategy is off," or the agent is, is off, for example.

52. 9:03

    Um, you'll also annotate datasets as well just to double-check that those evals are correct. And then, of course, you always come back in, into your platform, and you, you know, you update the, the prompt template, right?

53. 9:14

    You change the model 'cause it's, it's wasn't good enough, or you update the agent orchestration. So everybody understands that left-hand circle. Now, a lot of people actually forget about the right-hand circle.

54. 9:24

    And so it turns out the first time you run evals, what you'll qu- quickly realize is that, um, they're not perfect, right? You actually have to tune those evals over time.

55. 9:35

    So the way you collect signal actually adjusts as your application also, you know, gets better. And so what I mean by that is that process of running evals, what you might notice if you annotate some of them, is that the eval said something hallucinated or wasn't correct, and it actually was, or vice versa.

56. 9:52

    Um, so what you actually need to do is collect a set of those failures, right? Say, "Hey, this is where the eval was wrong." And you'll know that by annotating some data every now and again.

57. 10:02

    Um, and then you'll want to improve the eval prompt template, right? 'Cause the way you collect signal at first, um, you'll quickly realize it's either too obscure, too vague, uh, not specific enough.

58. 10:12

    So these are the kind of two virtuous cycles that you really wanna get through very quickly. And the way I describe it to AI engineering teams is if you wanna build an, like, a quality AI product, uh, think about velocity.

59. 10:26

    So the faster you iterate through stuff, if you... I can get through four iterations in a month rather than two, you're gonna exponentially have a better AI product as you build.

60. 10:34

    And so when we talk about architectures and things like that, um, when the industry first started, this was state-of-the-art, um, routers, right? Um, am I right? Um, so routers are made up of, like, components.

61. 10:46

    Um, this is a really dumb example of Booking.com's Trip Planner. Um, so Booking, you know, they're one of our largest customers. Trip Planner is basically a, a travel agent in LLM form.

62. 10:56

    It drives revenue for that company. It helps you book, you know, it'll book your flights, your hotels. It'll give you an itinerary. And so, um, you know, when we think about evals, evals can be as complex as the applicat- application itself.

63. 11:10

    So in kind of older architectures, um, where there's things like routing, um, you can, you can eval individual components. I think most people get this when you're looking inside of a, a trace, for example.

64. 11:22

    Um, maybe I wanna eval a specific, uh, component or trace, so this one LLM call, right? But remember... Oops, I'll come up here. But remember that you can, um, okay.

65. 11:33

    Remember that you can zoom out too, so it doesn't have to just be this one specific component. Let's say this one component is part of an agent or a workflow.

66. 11:40

    Uh, maybe I just wanna evaluate the input/output of that larger workflow. So that larger workflow is made up of LLM calls, API calls, right? I have to find actual flights, actual hotels that have vacancy, um, maybe some heuristics.

67. 11:54

    And then you can zoom out a little bit more. Uh, maybe you want to eval things like the way control flow happens. It's a really important component. If you have components in your AI agents that have control flow in them, uh, it actually makes way more sense to eval your control flow first.

68. 12:09

    And you have conditional evals, meaning if you didn't get the control flow right, why eval anything down the line? 'Cause it's probably wrong, right? So save yourse- save yourself some, some money and some, um, some costs.

69. 12:21

    So you can think about conditional evals as well. And then of course, we have things like, um, people wanna run evals at, at the highest level. So imagine you have a back and forth, so we call this a session in, in our platform.

70. 12:33

    But, uh, the whole idea is, you know, uh, a session is made up of a series of traces. So you can imagine there's a back and forth between your...

71. 12:40

    you and your agent. I just wanna understand, hey, at any point, was the customer frustrated? Was the customer XYZ? So when you start to think about evals, there's no one-stop shop.

72. 12:50

    Uh, if anybody t- like, says, "This is how you should do evals," and they never asked you about how your application works, you probably shouldn't trust them. Also, I have a hot take, and my hot take is that don't use out-of-the-box evals.

73. 13:01

    If you get out-of-the-box... If you use out-of-the-box evals, you'll get out-of-the-box results. Um, so really customize them very heavily. It's something that we've learned really from some of the best teams in the world.

74. 13:12

    Um, okay, let me come here. Um, then you have complexity. Um, this is our own architecture for, uh, our AI copilot. Uh, we built an AI whose one purpose is to troubleshoot, observe, build evals for your AI system.

75. 13:25

    It obviously takes advantage of our platform, but you know, the reason why we go this route is take us forward five, 10 years from now. Do you guys really think that you, a human, are gonna be the ones who are evaluating all these AI systems, like, manually? [laughs]

76. 13:39

    Um, what do you think would actually take your place? Um, it's probably gonna be an AI that evaluates future AI. So this is our first iteration on this stuff.

77. 13:46

    Um, we're super excited about it. Um, you know, it's been out for a year. It's getting better and better. But maybe I'll show you a little bit of the workflows that we have in, in our platform really quickly.

78. 13:56

    Um, who here is, is working with agents? Okay, who here is interested in, like, agent evaluation? Okay, let's cover that then. Let's see. I'll show you... We'll show you how the industry is doing agent evals.

79. 14:08

    So with agent evals, things get, like, way more complex, right? The calls are longer. So when you look at your traces, they're much longer. Um, I'll actually show you, uh, our agent, um, traces.

80. 14:20

    So this is one that kinda failed. But our agent traces kinda works like this. So Copilot works like this. It basically, based off what you say and where you're at in the platform, there's e- there's agents that kind of can do things.

81. 14:32

    So, um, and it has tools. Each agent has access to a set of tools that it's particularly good at. Um, so the whole idea is that, yes, we can see what each individual, um, trace is doing, right?

82. 14:44

    We can say, "Hey, what's happening in this particular area?" We can look at the traces. But the reality of, of what people are actually asking in the space is not, "Is my AI agent good or bad?"

83. 14:56

    What they're actually asking is, "What are the failure modes in which my agent fails?" Right? And so what I mean by that is you can look at one individual, uh, trace and the graph view of it, but the reality is you wanna understand and discern the signal with your entirety of your AI agent.

84. 15:13

    So what is the d- like, what does the pathing look like across all of that particular AI agent's, um, calls? So for instance, if it had access to, to 10 tools, maybe you wanna answer questions like, how often did it call a specific tool, right?

85. 15:29

    Um, what were the evals in a specific path? So in our agent graph, for example, um, it's framework agnostic. So whether you use LangGraph, whether you use CrewAI, whether you use your hand-rolled code, um, this is an agnostic way to look at, um, you know, how, how an agent's pathing performs across the aggregate traces.

86. 15:50

    Um, and so this helps you understand, okay, if my agent that hits component one, then two, then three, uh, my evals look great. But for some reason, when we hit component four, then two, then three, our evals are dropping.

87. 16:03

    And the reason is why? Well, oh, it turns out component four had a dependency, right, on component three, and it needs that dependency in order to perform. And so when you think about the complexity of agent evals, um, you need kind of the ability to see across not one instantiation, but all of them.

88. 16:20

    You need to understand the distribution of what's happening. And so when we think about evals across agents, um, that's one way you can think about it. And then maybe a, an easier way to kinda think about it too is, um, you know, trajectory.

89. 16:33

    Uh, we're thinking about trajectory evals. So imagine for a second, um, you have this specific input, right? And the input is like, you know, "Hey, find me these hotels at, at Trip Planner."

90. 16:44

    And you know you should hit this component, then that component, this other component. So in this case, it's like start agent, tool agent. You might have a golden dataset, like very similar to how we have golden datasets for LLM-as-a-Judge, but this is for trajectories.

91. 16:57

    So I expect us to be able to hit at least three or four of these components, for example. So the reference trajectory is kind of mentioned, like I need to hit these components.

92. 17:05

    Then you get to do, do two, two things, one of two things. Either one, you can pass in like, here's what we did, here's what we expected into an LLM, and then an LLM can actually grade the trajectory.

93. 17:16

    Um, you can also just say, "Hey, did we explicitly hit these exact like trajectory strings?" Great. Um, but you don't always need a ground truth for that. You, you can start to get creative here.

94. 17:25

    You can say, "Hey, you know, here's this process that I expected to hit. Do, do the, does these nodes and the description of their nodes match the correct, correct trajectory," for instance.

95. 17:35

    Um, and then maybe you could do things like we're kind of playing around with this, but maybe here's the trajectory that I hit. Uh, here's the possible paths that are just possible.

96. 17:45

    Did I do well in these specific areas, right? And you can pass in the, the pathing as a series of like nested key value pairs, for example. LLMs are pretty good at that.

97. 17:53

    But we start to think about, um, you know, agent evals. You know, the eval space is already complex enough, and what we're seeing is even more complexity. Um, but hopefully that makes sense.

98. 18:04

    Um, I'll pause here. Um, hopefully that makes sense, but usually I like to make time for questions at the end to keep this pretty interactive. Um, hope that's okay, team.

99. 18:12

    But any questions? Does this make sense? Cool. No questions. Oh, yeah. Go ahead.

100. 18:20

     Most of the evals you're talking about are kind of like after the fact, right? Is there a way that you can-

101. 18:28

     Clearly a hallucination [door closing]

102. 18:31

     Yeah, incredible question. So a lot of people-- So there's evals that can be, um, you know, some people call them offline or online. Um, I like to say is, like, is it in the path-- Is it in orchestration or out of orchestration?

103. 18:43

     So for some people, there's a cost to in, in orchestration evals, and the cost is things like latency, right? Some people might call those a guardrail too. Like, "Hey, can I continue or not continue?"

104. 18:54

     Um, and so there's pros and cons to everything. I think when it comes to guardrails, this is something I, I kinda coach my customers. The way to think about guardrails, um, in general is you have system one.

105. 19:06

     System one is your orchestration system. It's what you built. It's your prompts. It's everything else. System two is your guardrail system, right? Guardrails are really nice because they, they mitigate risk, right?

106. 19:17

     But there is a cost, and the cost is maybe it's latency in your user's experience. You can get around that by doing smart things like maybe embeddings guardrails. They're, you know, two orders of magnitude shorter.

107. 19:29

     Um, but a lot of people don't think about the other two cons here. The other con is complexity. Two systems is complex, especially when one system checks in with the first.

108. 19:38

     The third thing is that a lot of people mistake guardrails as, like, the thing that needs to be adjusted. A lot of people will go to their guardrails first, like, "Oh, I need to adjust my guardrails."

109. 19:48

     The reality is you need to adjust system one. That's the root cause, right? Your guardrails are really there to protect you. And then maybe the last thing I'll say too is guardrails are not infa-fallible.

110. 19:59

     They're-- They kinda act like unit tests. They're for known knowns, right? Whereas observability plus evals... 'Cause the reality is you don't know the distribution of what you're gonna see until you get there, right?

111. 20:10

     Um, ask anybody who's built in the L-LLM space. Uh, their users are just crazy. [laughs] And so, um, that, that's the difference, and I, and I really caution people 'cause people are like, "Oh, I need to fix my guardrail."

112. 20:21

     No, no. Go fix the prompt [laughs] first and then worry about your guardrails. But yeah, inline, we call those inline, uh, evals. Some people call them guardrails. But really, do you do the evals in the orchestration or outside of it?

113. 20:33

     Um, and so you can-- there's pros and cons, so there's no right or wrong answer there, but good question.

114. 20:39

     Yeah. So, uh, when we have a complex system that is typically taking a long time to run and you have timeouts in this, and I know, uh, uh, you'll have something called a span that limits what, uh, uh, kind of, uh, view we're taking to, uh, a complex agent.

115. 20:57

     So if we have like a complex system that's really gonna take time, and then there's an asynchronous way, is there support to manage something like that and eval it across the whole system that we have modeled?

116. 21:08

     Oh, yeah. Amazing question. So, um, who here has ever heard of OTel? OpenTelemetry. Okay, even less than... Okay. Um, one of the most important things to our enterprise customers is, is being on OpenTelemetry.

117. 21:21

     Um, so you know how I said LLM teams are being split into two? Well, it turns out LLM services are also being split across services. And so the idea is, like, people wanna understand, um, so maybe an asynchronous process in one service or one Docker contain or, you know, one, one Docker or one Kubernetes pod.

118. 21:38

     Um, OTel propagation is a great way to get around that, meaning you can have a process like application A sends data to my model router, right? And then that comes back to application A.

119. 21:50

     Then application A hits application B for some reason, and then it comes back to A. When you're actually creating those traces, you wanna be able to see all that work, right?

120. 21:58

     You don't wanna just instrument one particular thing. You wanna see it across, work across. And so OTel is an incredible pattern for that. It's a solved problem. So that's why we at Arize two and a half years ago when this crazy time started for all of us, we made a bet to be OTel first, and it's, it's

121. 22:14

     really paid off. Um, yeah.

122. 22:16

     Awesome.

123. 22:17

     Yeah.

124. 22:17

     That's all.

125. 22:18

     So, uh, I just wanted to ask, like in your experience, is, uh, is there a good way to get the kind of confidence score on the like model eval?

126. 22:26

     Because I imagine if I, if you have that, you can, you know, identify the value, values like

127. 22:32

     Okay. So confidence scores on evals, right? Um, yeah, I think it depends where you're getting your eval, if it's from an autoregressive model. Um, companies like OpenAI have actually exposed the log prob.

128. 22:42

     So the log probability is pseudo like confidence of like... And since you're returning only one co-token and that token is like the, the eval label, log prob is a really good way for those autoregressive models.

129. 22:54

     If you're using things like, um, small language models, encoder-only models, they come with a probability, uh, of the classification. Um, but really, yeah, it's tough, but you have a bunch of tools in your toolbox, and you generally use them together to discern where things go well or not well.

130. 23:09

     But log prob, if you're using, uh, a model provider that exposes the log prob is, is a really good way to start for autoregressive models.

131. 23:18

     Okay. Last question, and then we time up. Yeah.

132. 23:20

     Hey. Uh, are, do you have anything in your plans like going forward, uh, like how to shorten the loop between customer feedback and automatically improving the prompts as opposed to having like, you know, the development team have to look at it?

133. 23:32

     Oh, good question. Yeah. We wanna automate in that area definitely. So who here has heard of DSPy?

134. 23:38

     All right. Okay. If you, if you didn't raise your hand on any of this, I hope you learned a bunch. Um, DSPy obviously has something like MePro. Uh, MePro is an optimizer.

135. 23:46

     You get like thirty inputs, thirty outputs, and then, um, it basically creates less fragile prompts that span across different models. Like, so it does-- it works for OpenAI, and then it works for Gemini, et cetera.

136. 23:56

     Um, in terms of like auto optimization, yeah, I think we have the ability to... or we're releasing the ability to run, uh, prompt optim-optimization. So some people call it-- We call it meta-prompting.

137. 24:08

     But basically, we feed it a dataset. We said, "Here's the input-output pairs. Here's the evals on those things, uh, and there's where things failed and didn't fail. Look at the original prompts.

138. 24:18

     Look at this dataset. Can you give me a new prompt that fixes this dataset?" Yeah. So we, we have-- we call that meta-prompting, but it's basically use an LLM to just automate so you don't have to.

139. 24:29

     Yeah. But good question. But really appreciate the time. Uh, we're over at the booth. Uh, feel free to come grab me if you want to talk architecture or, or anything.

140. 24:36

     But really nice to see you all. [audience applauding] [upbeat music]