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.
• Session scope—feed every trace in a user session (and every span in those traces) to the LLM judge in a single prompt, so the evaluation can reason across an entire multi-turn interaction. See Session-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 Agent Observability. You can provide an evaluation description to generate an evaluation, use and build on existing template LLM-as-a-judge evaluations we provide, or start from scratch. You can enable tracing to see traces from your evaluations.

Learn more about the compatibility requirements.

Configure the prompt

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

2. To enable tracing for evaluations, click the Tracing Disabled button, then select the Trace Evaluations toggle to enable tracing. When this evaluation runs, its traces appear under datadog-evaluations, giving you greater visibility into your evaluations. Note: Enabling tracing increases the number of billed spans sent to Datadog.

3. 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.
4. Configure the model:
   1. Select the Account dropdown 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. You can then select a model name or provide the inference profile ARN.
      • If you select a Vertex account, choose a project and location.
   2. Use the Model dropdown menu to select a model.
5. In Runs On, select the application you want to evaluate, what you want to evaluate on (span, trace, or session), and the sampling rate. You can add more filtering criteria by selecting the button to the right of the sampling rate.
6. In the Template section, use the dropdown 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 Prompt field, specify what parts of the span, trace, or session to evaluate by adding variables. You can add 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; for session-scoped evaluations, use {{traces...}} paths to read across traces. See Prompt Templating for the full reference. To edit the user prompt directly, select it and edit the text.

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

   1. Choose an account and an application so that spans, traces, or sessions show up on the right.
   2. Select one of the spans on the right to view its JSON.
   3. Select + to add the JSON to your user 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
}

{
    assessment: "pass", // "pass" | "fail" [REQUIRED],
    value: "evaluation_label" // string [OPTIONAL],
    reasoning: "explanation behind the assessment" // string [OPTIONAL]

}

function __evalPostProcessing(input) {
    /*
     * Expected input shape (from LLM evaluator [this depends on the JSON Structured Output]):
     * {
     *   criteria: {
     *     quality_score: { score: number (0–1), category: "excellent"|"good"|"poor", reasoning: string },
     *     toxicity:      { score: number (0–1), category: "safe"|"unsafe",           reasoning: string },
     *     completeness:  { score: number (0–1), category: "complete"|"incomplete",   reasoning: string },
     *     relevance:     { score: number (0–1), category: "relevant"|"irrelevant",   reasoning: string },
     *   },
     *   overall_reasoning: string  // (optional) top-level summary from LLM evaluator
     * }
     */

    const SCORE_THRESHOLD = 0.7;

    // Category → pass/fail mappings per criterion
    const CATEGORY_PASS_MAP = {
        quality_score: ["excellent", "good"],
        toxicity:      ["safe"],
        completeness:  ["complete"],
        relevance:     ["relevant"],
    };

    const criteriaResults = {};
    const failures = [];
    const passes = [];

    for (const [criterionName, passCategories] of Object.entries(CATEGORY_PASS_MAP)) {
        const criterion = input?.criteria?.[criterionName];

        if (!criterion) {
            failures.push(`[${criterionName}] Missing from evaluator output.`);
            criteriaResults[criterionName] = false;
            continue;
        }

        const { score, category, reasoning } = criterion;

        const scorePass    = typeof score === "number" && score >= SCORE_THRESHOLD;
        const categoryPass = typeof category === "string" && passCategories.includes(category.toLowerCase());

        // Both score AND category must pass
        const criterionPass = scorePass && categoryPass;
        criteriaResults[criterionName] = criterionPass;

        if (criterionPass) {
            passes.push(`[${criterionName}] PASS — score: ${score.toFixed(2)}, category: "${category}". ${reasoning ?? ""}`);
        } else {
            const reasons = [];
            if (!scorePass)    reasons.push(`score ${score?.toFixed(2) ?? "N/A"} below threshold (≥${SCORE_THRESHOLD})`);
            if (!categoryPass) reasons.push(`category "${category}" not in acceptable set [${passCategories.join(", ")}]`);
            failures.push(`[${criterionName}] FAIL — ${reasons.join("; ")}. ${reasoning ?? ""}`);
        }
    }

    // Determine overall assessment
    const passed = Object.values(criteriaResults).every(Boolean);
    const failCount = failures.length;

    const assessment = passed ? "pass" : "fail";

    const label = passed
        ? "high_quality_response"
        : failCount === 1
            ? "minor_quality_issue"
            : failCount === 2
                ? "moderate_quality_issue"
                : "low_quality_response";

    const reasoningParts = [
        passed
            ? "All criteria passed."
            : `${failCount} criterion/criteria failed.`,
        ...failures,
        ...passes,
        input?.overall_reasoning ? `Evaluator summary: ${input.overall_reasoning}` : ""
    ].filter(Boolean);

    return {
        assessment: assessment,
        value: label,
        reasoning: reasoningParts.join(" | ")
    };
}

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).
  • Session: Evaluate an entire user session, including every trace and its spans, as a single unit. Use this when the answer depends on context across multiple traces in the same session (user satisfaction, multi-turn coherence, or user behavior over time). Requires spans tagged with a session_id. See Session-Level Evaluations for examples and details on how session completion is determined.
• 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 Agent 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 Agent 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 manipulate managed evaluation configs, after 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

추가 유용한 문서, 링크 및 기사:

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 Agent Observability terms and conceptsDOCUMENTATION Learn how to set up Agent ObservabilityDOCUMENTATION Learn about managed evaluationsDOCUMENTATION Using LLM-as-a-judge for an automated and versatile evaluationHUGGING FACE