Custom LLM-as-a-judge evaluations use an LLM to judge the performance of another LLM. Define evaluation logic with natural language prompts, capture subjective or objective criteria (like tone, helpfulness, or factuality), and run the evaluations at scale on:

• Span scope—score the input and output of one LLM call, agent step, or tool invocation in isolation.
• Trace scope—feed every span of a trace to the LLM judge in a single prompt, so the evaluation can reason across steps. See Trace-Level Evaluations for the full walkthrough, use cases, and prompt examples.

Create a custom LLM-as-a-judge evaluation

You can create and manage custom evaluations from the Evaluations page in LLM Observability. You can start from scratch or use and build on existing template LLM-as-a-judge evaluations we provide.

Learn more about the compatibility requirements.

Configure the prompt

1. In Datadog, navigate to the LLM Observability Evaluations page. Select Create Evaluation, then select Create your own.

2. Provide a clear, descriptive evaluation name (for example, factuality-check or tone-eval). You can use this name when querying evaluation results. The name must be unique within your application.
3. Use the Account drop-down menu to select the LLM provider and corresponding account to use for your LLM judge. To connect a new account, see connect an LLM provider.
   • If you select an Amazon Bedrock account, choose a region the account is configured for.
   • If you select a Vertex account, choose a project and location.
4. Use the Model drop-down menu to select a model to use for your LLM judge.
5. Under Evaluation Scope, select the application you want to evaluate.
6. Under Evaluation Prompt section, use the Prompt Template drop-down menu:
   • Create from scratch: Use your own custom prompt (defined in the next step).
   • Failure to Answer, Prompt Injection, Sentiment, etc.: Populate a pre-existing prompt template. You can use these templates as-is, or modify them to match your specific evaluation logic.
7. In the System Prompt field, enter your custom prompt or modify a prompt template. For custom prompts, provide clear instructions describing what the evaluator should assess.
   • Focus on a single evaluation goal
   • Include 2–3 few-shot examples showing input/output pairs, expected results, and reasoning.

You will be looking at interactions between a user and a budgeting AI agent. Your job is to classify the user's intent when it comes to using the budgeting AI agent.

You will be given a Span Input, which represents the user's message to the agent, which you will then classify. Here are some examples.

Span Input: What are the core things I should know about budgeting?
Classification: general_financial_advice

Span Input: Did I go over budget with my grocery bills last month?
Classification: budgeting_question

Span Input: What is the category for which I have the highest budget?
Classification: budgeting_question

Span Input: Based on my past months, what is my ideal budget for subscriptions?
Classification: budgeting_advice

Span Input: Raise my restaurant budget by $50
Classification: budgeting_request

Span Input: Help me plan a trip to the Maldives
Classification: unrelated

Span Input: {{span_input}}

8. In the User field, provide your user prompt. Explicitly specify what parts of the span or trace to evaluate. You can reference any span attribute, such as Span Input ({{span_input}}), Output ({{span_output}}), or any other span field. For trace-scoped evaluations, use {{spans...}} paths to read across spans—see Prompt Templating for the full reference. An autocomplete dropdown appears when you type {{ to help you select available fields.

   You may also use the panel on the right (Filtered Spans in span scope, Spans in Selected Trace in trace scope) to add span data as a variable:

   1. Choose an account and an application so that spans/traces show up on the right.
   2. Select one of the spans on the right to view its JSON.
   3. Use the three-dots menu and select Add variable to message to insert the JSON into your prompt.

Define the evaluation output

For OpenAI, Azure OpenAI, Vertex AI, Anthropic, or Amazon Bedrock models, configure Structured Output.

For Anthropic or Amazon Bedrock models, you can alternatively configure Keyword Search Output.

For AI Gateway, both Structured Output and Keyword Search Output are supported. Datadog recommends using Structured Output when your model supports it, and falling back to Keyword Search Output otherwise.

{
    "name": "categorical_eval",
    "schema": {
        "type": "object",
        "required": [
            "categorical_eval",
            "reasoning"
        ],
        "properties": {
            "categorical_eval": {
                "type": "string",
                "anyOf": [
                    {
                        "const": "budgeting_question",
                        "description": "The user is asking a question about their budget. The answer can be directly determined by looking at their budget and spending."
                    },
                    {
                        "const": "budgeting_request",
                        "description": "The user is asking to change something about their budget. This should involve an action that changes their budget."
                    },
                    {
                        "const": "budgeting_advice",
                        "description": "The user is asking for advice on their budget. This should not require a change to their budget, but it should require an analysis of their budget and spending."
                    },
                    {
                        "const": "general_financial_advice",
                        "description": "The user is asking for general financial advice which is not directly related to their specific budget. However, this can include advice about budgeting in general."
                    },
                    {
                        "const": "unrelated",
                        "description": "This is a catch-all category for things not related to budgeting or financial advice."
                    }
                ]
            },
            "reasoning": {
                "type": "string",
                "description": "Describe how you decided the category"
            }
        },
        "additionalProperties": false
    },
    "strict": true
}

{
    "name": "json_eval",
    "schema": {
        "type": "object",
        "required": [
            "result",
            "reasoning"
        ],
        "properties": {
            "result": {
                "type": "object",
                "description": "The structured evaluation result",
                "properties": {
                    "is_compliant": {
                        "type": "boolean",
                        "description": "Whether the response meets compliance requirements"
                    },
                    "confidence_score": {
                        "type": "number",
                        "description": "Confidence level of the evaluation from 0 to 1"
                    },
                    "issue_count": {
                        "type": "integer",
                        "description": "Number of issues identified in the response"
                    }
                },
                "required": ["is_compliant", "confidence_score", "issue_count"],
                "additionalProperties": false
            },
            "reasoning": {
                "type": "string",
                "description": "Describe the reasoning behind your evaluation"
            }
        },
        "additionalProperties": false
    },
    "strict": true
}

Define the evaluation scope: Filtering and sampling

Under Evaluation Scope, define where and how your evaluation runs. This helps control coverage (which spans or traces are included) and cost (how many are sampled).

• Application: Select the application you want to evaluate.
• Evaluate On: Choose one of the following:
  • Trace: Evaluate the full trace, including all its spans, as a single unit. Use this when the answer depends on context across multiple spans (agent goal completion, tool-use chains, RAG faithfulness). See Trace-Level Evaluations for examples and details on how trace completion is determined.
  • Span: Evaluate matching spans individually. Use the Query field to scope to specific spans (for example, only root spans, only llm spans, or spans with a specific tag).
• Query: (Optional) Enter a query using Datadog query syntax to filter which spans or traces are evaluated. For example:
  • @name:agent.workflow to filter by span name
  • env:prod to filter by tag
  • @parent_id:undefined to evaluate only root spans (when Evaluate On is set to Span)
  • @name:agent.workflow AND env:prod to filter by span name and tag
• Sampling Rate: (Optional) Apply sampling (for example, 10%) to control evaluation cost.

Test and preview

The pane on the right shows Filtered Spans (or traces) corresponding to the configured evaluation scope.

Select a span to show JSON data available for use in an evaluation. Then, click Test Evaluation to pre-fill inputs to your evaluation with data from the span, and click Run to test.

Viewing and using results

After you Save and Publish your evaluation, Datadog automatically runs your evaluation on targeted spans. Alternatively, you can Save as Draft and edit or enable your evaluation later.

Results are available across LLM Observability in near-real-time for published evaluations. You can find your custom LLM-as-a-judge results for a specific span in the Evaluations tab, alongside other evaluations.

Each evaluation result includes:

• The evaluated value (for example True, 9, or Neutral)
• The reasoning (when enabled)
• The pass/fail indicator (based on your assessment criteria)

Use the syntax @evaluation.<evaluation_name>.value to query or visualize results.

For example:

@evaluation.helpfulness-check.value

You can:

• Filter traces by evaluation results (example, @evaluation.helpfulness-check.value)
• Filter by pass/fail assessment status (example, @evaluation.helpfulness-check.assessment:fail)
• Use evaluation results as facets
• View aggregate results in the LLM Observability Overview page’s Evaluation section
• Create monitors to alert on performance changes or regression

Using in experiments

To reuse a custom LLM-as-a-judge evaluation in a local LLM Experiment, reference it by name using RemoteEvaluator from the SDK:

from ddtrace.llmobs import LLMObs, RemoteEvaluator

evaluator = RemoteEvaluator(eval_name="quality-assessment")

experiment = LLMObs.experiment(
    name="my-experiment",
    task=my_task,
    dataset=dataset,
    evaluators=[evaluator],
)
experiment.run()

You can mix RemoteEvaluator with other local evaluators in the same experiment. For custom input mapping, error handling, and more options, see RemoteEvaluator in the Evaluation Developer Guide.

Best practices for reliable custom evaluations

• Start small: Target a single, well-defined failure mode before scaling.
• Enable reasoning when you need explainable decisions and to improve the accuracy on complex reasoning tasks.
• Iterate: Run, inspect outputs, and refine your prompt.
• Validate: Periodically check evaluator accuracy using sampled traces.
• Document your rubric: Clearly define what “Pass” and “Fail” mean to avoid drift over time.
• Re-align your evaluator: Reassess prompt and few-shot examples when the underlying LLM updates.

Estimated token usage

You can monitor the token usage of your LLM evaluations using the LLM Evaluations Token Usage dashboard.

If you need more details, the following metrics allow you to track the LLM resources consumed to power evaluations:

• ml_obs.estimated_usage.llm.input.tokens
• ml_obs.estimated_usage.llm.output.tokens
• ml_obs.estimated_usage.llm.total.tokens

Each of these metrics has ml_app, model_server, model_provider, model_name, and evaluation_name tags, allowing you to pinpoint specific applications, models, and evaluations contributing to your usage.

Configure LLM-as-a-judge evaluations from the API

You can use basic CRUD operations to manipluate managed evaluation configs, one you have the DD_API_KEY API key specified in your environment.

• GET existing evaluation configurations
• PUT existing evaluation configurations
• DELETE existing evaluation configurations

Further Reading

Documentation, liens et articles supplémentaires utiles:

Driving AI ROI: How Datadog connects cost, performance, and infrastructure so you can scale responsiblyBLOG Gain visibility into Strands Agents workflows with Datadog LLM ObservabilityBLOG Building an LLM evaluation framework: best practicesBLOG Learn about LLM Observability terms and conceptsDOCUMENTATION Learn how to set up LLM ObservabilityDOCUMENTATION Learn about managed evaluationsDOCUMENTATION Using LLM-as-a-judge for an automated and versatile evaluationHUGGING FACE