Prerequisites
- Complete the cloud evaluation prerequisites and client setup.
- An evaluation ID and run ID from a submitted cloud evaluation.
Poll for a completed run
After an evaluation run completes, retrieve the scored results and review them in the portal or programmatically. Evaluation runs are asynchronous. Poll the run status until it completes, then retrieve the results:- Python
- C#
- JavaScript/TypeScript
- cURL
Interpret results
For a single data example, all evaluators output the following schema:- Label: a binary “pass” or “fail” label, similar to a unit test’s output. Use this result to facilitate comparisons across evaluators.
- Score: a score from the natural scale of each evaluator. Some evaluators use a fine-grained rubric, scoring on a 5-point scale (quality evaluators) or a 7-point scale (content safety evaluators). Others, like textual similarity evaluators, use F1 scores, which are floats between 0 and 1. Any nonbinary “score” is binarized to “pass” or “fail” in the “label” field based on the “threshold”.
- Threshold: any nonbinary scores are binarized to “pass” or “fail” based on a default threshold, which the user can override in the SDK experience.
- Reason: To improve intelligibility, all LLM-judge evaluators also output a reasoning field to explain why a certain score is given.
- Details: (optional) For some evaluators, such as tool_call_accuracy, there might be a “details” field or flags that contain additional information to help users debug their applications.
Review an item result
Review aggregate results
For aggregate results over multiple data examples (a dataset), the average rate of the examples with a “pass” forms the passing rate for that dataset.Review model-target latency and estimated cost
When you retrieve or list completed model-target runs, they can include run-wide target latency underlatency.target and estimated inference cost under
estimated_cost.target.
Both properties are optional. The service omits latency when no evaluation row
has a usable target latency measurement. It omits estimated cost when the run
isn’t a model-target evaluation or when no target model can be priced.
Estimated cost is currently available for Global Standard model deployments
when the run has usable target token attribution and pricing data.
The following example shows the relevant part of a completed evaluation run:
Estimated cost fields have the following meanings:
Each entry in
model_costs contains the backing model_name, its
estimated_cost, non-cached input prompt_tokens, cached_tokens, and output
completion_tokens. For a direct deployment, model_name is the backing model
resolved from deployment metadata. For a model-router target, the breakdown
identifies the models attributed by the runtime.
When completeness is partial, the top-level cost and model_costs include
only the models that the service could price. Check unpriced_models before
using the estimate to compare runs.
Extract latency and estimated cost
After the evaluation run finishes and is available inrun, convert the SDK
response to a dictionary and check the optional target latency:
- Python
- C#
- JavaScript/TypeScript
- cURL
model_costs. If
completeness is partial, the output identifies the omitted models in
unpriced_models; don’t treat the estimate as the full cost of the run.
Target cost is an estimate based on reported token usage and published list
prices. It excludes evaluator model usage and evaluation runtime costs, and it
doesn’t account for negotiated pricing, commitments, or discounts. Use Azure
billing data for actual charges.
Cancel a run
Cancel a run that you no longer need:- Python
- C#
- JavaScript/TypeScript
- cURL
Troubleshoot cloud evaluation
Job running for a long time
Your evaluation job might stay in the Running state for a long time. This condition usually happens when the Azure OpenAI model deployment doesn’t have enough capacity, so the service retries requests. Resolution:- Cancel the current evaluation job by using
openai_client.evals.runs.cancel(run_id, eval_id=eval_id). - Increase the model capacity in the Azure portal.
- Run the evaluation again.
Authentication errors
If you get a401 Unauthorized or 403 Forbidden error, check that:
- You configured your
DefaultAzureCredentialcorrectly. If you’re using Azure CLI, runaz login. - Your account has the Foundry User role on the Foundry project. For all evaluation role requirements, see Set up permissions for evaluation workflows.
- The project endpoint URL is correct and includes both the account and project names.
Data format errors
If the evaluation fails with a schema or data mapping error:- Verify your JSONL file has one valid JSON object per line.
- Confirm that field names in
data_mappingmatch the field names in your JSONL file exactly (case-sensitive). - Check that
item_schemaproperties match the fields in your dataset.
HTTP 400 error when you use file_id with agent response evaluations
Agent response evaluations (azure_ai_responses) support only inline data through file_content. If you provide response IDs by using file_id, the request returns a 400 Bad Request error.
Resolution: Switch to file_content and provide the response IDs inline.
Rate limit errors
Tenant, subscription, and project levels rate-limit evaluation run creations. If you receive a429 Too Many Requests response:
- Check the
retry-afterheader in the response for the recommended wait time. - Review the response body for rate limit details.
- Use exponential backoff when retrying failed requests.
429 error during execution:
- Reduce the size of your evaluation dataset or split it into smaller batches.
- Increase the tokens-per-minute (TPM) quota for your model deployment in the Azure portal.
Agent evaluator tool errors
If an agent evaluator returns an error for unsupported tools:- Check the supported tools for agent evaluators.
- As a workaround, wrap unsupported tools as user-defined function tools so the evaluator can assess them.