Agent Evaluation

Agents are designed to execute precise workflows to generate domain-specific answers, which makes the challenge of measuring agent performance significantly more complex than traditional evaluation techniques. Evaluating an agent requires a multidimensional assessment of its decision-making, taking into account both the agent’s answer and the path the agent took to create that answer.

Dataiku offers an “Evaluate Agent” recipe for transactional agents: single-turn agents that process one request at a time. The recipe evaluates both the agent’s answer and its trajectory (tool calls and encountered guardrails) to generate various outputs, the most pivotal of which is an agent evaluation stored in an evaluation store. From this evaluation store, you can then complete your GenAIOps actions with alerting or automated actions.

Note

The “Evaluate Agent” recipe is available to customers with the Advanced LLM Mesh add-on.

Overview

Much like the Evaluate LLM recipe, the Evaluate Agent recipe does not take a model as a direct input, but a single dataset — the output of your pipeline containing all the required columns: input, output, tool calls, ground truth, etc…

When run, the recipe computes a set of metrics based on the content of the input dataset and create a single agent evaluation.

Note

Our agent evaluation tutorial provides a step-by-step explanation of how to create your first agent evaluation Flow. Do not hesitate to do it as a first experience.

Recipe configuration

You can create an “Evaluate Agent” recipe from any dataset.

Input dataset

The input dataset must contain a record of all the interactions with the agent. Ground truth might also be needed by some metrics. If the input dataset was created by a Prompt recipe, you can set the Input Dataset Format to “Prompt Recipe”, and only have to fill the Ground truth and Reference tool calls fields. If the input dataset is an agent interaction logging dataset, you can set the Input Dataset Format to “Agent Interaction Logs”, and only have to fill the Ground truth and Reference tool calls fields. Otherwise, you can set the Input Dataset Format to “Custom”, and reference all the columns from the Input Dataset:

  • Input column: The column containing the input sent to the agent. Usually, a question or request from the user.

  • Output column: The textual answer sent back by the agent.

  • Actual tool calls column: The list of tools used by the agent. Must be an array of tool names as strings.

  • Ground truth column: The reference textual answer that was expected. Will be compared against the Output column.

  • Reference tool calls column: The reference list of used tools that was expected. Must be an array of tool names as strings. Will be compared against the Actual tool calls column.

Outputs

The outputs of the recipe are settable from the Input/Output tab. Like the Standalone Evaluation Recipe and the Evaluate LLM recipe, the Evaluate Agent recipe can output:

  • An Output Dataset: Will contain a copy of the Input Dataset, with one additional column for each of the metrics computed. The metric values are hence “row-by-row”: Each value is specific to that row.

  • A Metrics Dataset: Will contain one row for each run of the recipe, and one column for each of the metric computed. Each metric value is hence an aggregation of the values of this metric over all the rows. The aggregation is usually an average, but this can depend from one metric to another.

  • A GenAI Evaluation Store: Will contain a collection of agent evaluations (one for each run), each agent evaluation containing all of the above information: values from the input dataset, row-by-row metrics, aggregated metrics.

Some of the agent evaluation settings can be set from the recipe, to help you name and label each run.

Metrics

The metrics section contains a list of built-in metrics that you can select to evaluate the behavior of your agent. These metrics should cover basic needs:

  • Fine-grained deterministic checks on the tools used by the agent (In order and Out of order tool calls metrics).

  • LLM-as-a-judge metrics, based on the RAGAS framework.

  • Or deterministic BERTScore metric, which uses embeddings to compare outputs.

Custom Traits

In addition to writing custom metrics with code, you can also define custom LLM-as-a-judge metrics without code in the form of traits.

You define a trait by providing a list of pass/fail assertions, which will be applied to individual rows in your input dataset. For each row, the LLM defined in “Completion LLM” will run each assertion over its values. If all assertions for that row are correct, the value of the trait for that row will be “True”.

Each trait is a list of assertions, which are sent along with each row of your input dataset, to the LLM defined in “Completion LLM”. Each assertion is made on the values of the row. For each row, if all the assertions are correct, the LLM is expected to set the value of the trait to “True”. The aggregated value of the trait over all the rows is the fraction of rows having returned True.

As for custom metrics, trait samples are available, which can allow you to set and reuse traits.

Trajectory explorer

The trajectory explorer displays an overview of what the agent did in chronological order, for each row in the input dataset.

The left panel contain a list of all the actions the agent took, as nodes. They can be of four types:

  • Initial input: The request sent to the agent.

  • Tool call: Any tool call the orchestrator requested, that was subsequently executed by Agent Management. Each tool call stores its input parameters and outputs (or eventual error).

  • Guardrail trigger: If guardrails are defined at the agent or orchestrator LLM level, they might not interrupt the agent. Nevertheless, any hit guardrail is presented here, as it can have altered (e.g by redacting) the input or output. Each guardrail stores its input (what was checked), and output (why the guardrail triggered).

  • Final output: The answer sent back by the agent.

You can click on each action to display its properties on the right panel. This includes, in addition to the input/output mentioned above, metadata such as timing information, or descriptions.