How to evaluate agent trajectories with AgentEvals

0:00 hi this is Katherine from Lang Ching today we'll chat about evaluating agent trajectories with agent evals we often evaluate the final response from Agents but sometimes an agent can arrive at the correct final response with inefficient or incorrect paths for example here's a situation where I asked for a meeting on Friday and if we scroll into the final response our scheduler agent correctly responds that it has set up meeting on Friday this seems correct for the email output

0:29 but if take a closer look at the trajectory here it only calls the get calendar tool it never actually called the scheduled calendar tool that it's supposed to it simply hallucinated the result this is an example where simply evaluating on the final step is not enough and it's necessary to evaluate based on the trajectory that our agent has taken which can be really helpful for complex agents with multiple steps and Tool calls and this is the

0:56 motivation behind agent evals agent evals is is a pre-built open- Source package designed for agent trajectory evaluation it contains a collection of evaluators and utilities allowing you to perform checks including whether an agent is calling the right tools or if the overall trajectory is efficient I also want to call it here that it is designed to be framework agnostic and works with the open AI format so there are two main ways you can conduct an evaluation for agent

1:27 trajectory first is a trajectory match you can evaluate by directly comparing trajectories which is a list of messages of tool calls this approach is good for testing for a welldefined set of expected tool calls or steps for example you could do a match to check whether certain tools are called in the order they're called in second you can use LM as a judge to evaluate the trajectory based on a criteria for example you might want to

1:55 understand whether your agent is making efficient progress and taking logical reasoning steps and unlike trajectory match which focuses on tool calls themselves Elm as a judge also takes the message content into account and this can be helpful for General assessment of agent reasoning capabilities let's take a deeper look together on how you can set up these evaluators using agent evals first let's take a look at trajectory match together so agent eval offers the create trajectory match

2:26 evaluator method it also offers acing support as as well the method has two main parameters that you can customize first is the trajectory match mode so this is how you're conducting your overall trajectory match and second how you're choosing to match the argument of the tools so on the trajectory match mode side there are four main modes first is the strict mode so this ensures the agent uses the exact set of tools and

2:57 are called in exact order as the reference reference in this example it means that we will want the output to match the exact tool call in the reference output but actually in this case in the output we see that it called tool tools instead of one which would actually leads to a false for evaluator so this strict mode is useful for cases where you want to enforce both the exact set of tool calls and the orders for example in a customer support

3:26 scenario you might want to enforce policy lookup tool is always called before invoking any action cool the second unorder mode also ensures the exact set of tools are called but they can now be in any order so in this code example if we look at the reference output here we called get fun activities and get weather so this means that as long as we call both of these tools which we do but in reverse order it would return true so this is

3:58 helpful in cases where actions from tools are independent from one another example could be looking up information from two separate products where the order doesn't really matter great and the final two modes subset and supet are partial matches of the trajectory so for the superet mode you want the actual agent output to be a super set of the reference this is helpful to check a few key tools are called in the execution but you're okay

4:29 with the agent calling additional tools so in this case the reference output contains get weather tool so as long as our actual output contains this tool call it is okay it has one additional tool call as well it will still return true and the subset mode is the opposite of superet you actually want the agent output to be a subset of their reference so this is helpful when you want to ensure agent efficiency so you want to

4:58 make sure they did not call any relevant tools that would be unnecessary great and Beyond the four General modes of matching trajectories of tool calls there's also flexibility in how you want to match the arguments are passed to invok the tools by default tool arguments are being compared and matched exactly but you can bypass that by calling match mode to be ignore which can be done in this example or you can set up additional override options so such as accounting

5:30 for case in sensitivity so that is done with the tool ARS match overrides method great so now this brings us to the second part of agent evil package so other than directly matching the trajectory we can also ask llm to be the evaluator of our trajectory so in this case we can either compare the output trajectory directly to a reference or ask the LM to judge an output trajectory by itself so below here shows an example

6:00 of initiating an LM evaluator we created an evaluator here called create trajectory LM as a judge we pass in a prompt as well as model and below this initialization we use the same output and reference output as the earlier examples that we see so what does a prompt look like for LM judges let's actually take a look at an example together so this is a pre-built prompt from the agent eval package called trajectory Act accuracy prompt we can

6:31 see that first it's asking LM to be an expert data labeler and to Great the accuracy of agent's trajectory so the rubric here being several things it has to make logical sense between steps it has to show clear progression and it has to be efficient at the end of The Prompt we attach the output trajectory from our agent now in addition to prompt and model the create trajectory LM as a judge can also optionally take on a few

7:01 additional parameters on defining the format or value for the AL output you can add system messages or few shot examples so these are listed here great now that we've covered Concepts in agent evils let's go see how we can actually use it to improve an agent in the development cycle in this notebook we have initialized a react agent this is the same scheduler agent we saw in the beginning of this demo let's now make use of the agent evals

7:32 package to evaluate the trajectories of our agent in the first evaluation we'll use the trajectory match evaluator we likely want strict mode because we want the exact three tool calls we likely also don't care about the arguments because there could be variabilities in the arguments for scheduled meeting time and email content so to use our evaluator we need to have both a reference trajectory and an agent output of the trajectory so let's first initialize our reference trajectory so here we want to

8:04 make sure that we call three tools versus get Cal and then schedule calendar as well as sending email so now we want to obtain a real output from invoking the agent we just created let's pass in the input from our initial example and fetch the trajectory great so our application just ran and it looks like our application again only called get Cal but not the schedule calendar tool from there we can pass a reference output and real output to our evaluator

8:35 and as expected this return false let's try another example with LM judge similarly we can initialize an evaluator with the pre-built accuracy prompt and pass the application output and reference outputs as parameters after running this also gave us a score of false and in the comments this also highlighted missing the tool call for Schedule C now that we saw how to use agent evals for a single data point let's look at how we can do that as part of a lsmith

9:05 evaluation run the benefits of running experiments in lsmith is that first it allows you to save the example as a data set so you can continuously test against those data points as you make changes to your application you can also compare the results across experiments second it allows you to automatically run multiple repetitions for a given input that allows you to get more confidence and reliability in the test to run an experiment through the lsmith SDK there are four steps first we want

9:35 to create a data set with a list of inputs and reference outputs here we'll just be using the one example we saw earlier next we want to define the application logic to run the test and then we want to Define our evaluators which have defined for a single data point earlier using the agent evals package from there we can run the experiment to view the results so we have initialized the data set here we only included one example in this data

10:01 set but realistically in development Cycles we typically want to test against a number of use cases and example set and then we defined a Target function this is basically invoking the graph with input and returning the trajectory and now let's define our evaluator so here we are making use of the agent eval package we create a trajectory match evaluator we can just do the simple strict mode match as as well as ignoring the arguments in the tool calls itself

10:33 cool so now that we have our evaluator Target function and data set defined let's pass it in to this evalue function and run our experiment and notice here that I'm running three repetitions for this example because LM can be a lot of times non-deterministic so running over a number of repetitions will allow for reliability in the results so it looks like our experiment results has finished running two out of three times actually is fail to call an our ideal trajectory

11:02 so now let's click on this lsmith link this will take us to the data set and experiment view that allow us to take a look at the results the first two columns are just the inputs and reference outputs that we created the third column is the real outputs from invoking our agent and the fourth column is the average of the evaluator results from the three runs from here I can take a quick flip through the outputs to

11:25 examine the trajectory of the three runs cool so look look like only one of the three runs did it actually correctly called both the get cow and schedule cow tools so now that I have a better understanding of an example scenario that my agent does not perform well on we can then focus on refining The Prompt or architecture to improve it from there we can continuously rerun our application against this data set to ensure performance improvement over time