Contents
Get a scoped quote

LLM evaluation services for AI features and agents

For teams shipping LLM features and agents: know whether a model, prompt or retrieval change scores measurably worse on your cases before it ships.

Get a scoped quote

First reply within 1 business day

See a sample report

Narrated video. LLM evaluation measures every model, prompt or retrieval change on your own cases before it ships: a golden set, graders checked against your experts, and a CI gate. A model provider's postmortem says its evaluations didn't capture what users reported. On our own demo agent, 20 unchanged runs set the gate's threshold, a planted 4.9-point drop failed the build, and 19 more unchanged runs raised no false alarm.

Fee
Fixed scope and fee agreed in writing before work starts.
Where it lives
Golden set, graders and CI gate in your repository, as produced
Typical build
3 to 5 weeks

What are LLM evaluation services?

LLM evaluation measures an LLM app's or agent's outputs against a definition of correct, on test cases or sampled production traces, using code checks, model judges or human labels. We build it with you: your cases, graders checked against your experts, and a baseline gate.

Read more

Two other things share the name. Rater and data vendors supply people who review, rate and rewrite model responses, producing data that helps improve models. Cloud and MLOps platforms include evaluation features that score traces with built-in or custom evaluators.

An evaluation service decides what those evaluators should measure for your product: which cases count, what correct means, and whether each grader agrees with your experts. It tests your own system on your own cases; it does not rank models in general.

How does AI agent evaluation work?

AI agent evaluation runs the agent on tasks, usually in a sandbox, and grades the end state it leaves as well as what it says. Agents vary between runs, so tasks are often repeated; pass^k counts a task only if all k runs succeed.

Read more

The end state is what the agent changed, such as an order record in the database, rather than what it said it did. Where the path matters, such as which tools were called and with what arguments, we add transcript checks. We also read transcripts to confirm that the graders reject real failures and accept valid solutions.

An eval platform runs the evaluators. The service decides the tasks, the end states that count as success and the criteria the graders apply.

More on agent evaluation

What noisy evaluations miss: a model provider's own lesson

Anthropic's September 2025 postmortem describes three infrastructure bugs that intermittently degraded 's response quality, and is candid about its evaluations.

Source: Anthropic, "A postmortem of three recent issues", 17 Sep 2025

A score is only useful if you know how far it moves when nothing has changed. Intermittent serving faults like these are a job for production monitoring.

Read more

An eval gate gives you a score that moves when quality moves, with its false-alarm rate measured. The Baseline and CI gate deliverable is where we measure that.

The postmortem is also plain about cause: "We never reduce model quality due to demand, time of day, or server load. The problems our users reported were due to infrastructure bugs alone."

"The evaluations we ran simply didn't capture the degradation users were reporting, in part because often recovers well from isolated mistakes." "More fundamentally, we relied too heavily on noisy evaluations."

Above the quote, a drawing of checks that all passed, then a report from users: "Reported by users".

What you get from an LLM evaluation build

Six parts, built with your experts on your cases. Your team runs, re-baselines and changes it without us.

  • These are results on a test set, not a measured rate. The gate sees only what the golden set covers; the smallest drop it caught in testing is stated, and smaller drops can pass.
  • The report is evidence, not a certification. Your results and test set are yours; what you tell your customers about your own testing is your decision. The report is prepared for you only; no third party may rely on it, and we issue no letters, and we do not name ourselves to your customers without written consent.
  • Open the sample evaluation report

  • A golden set: real-traffic cases, known failures and cases written with your experts

  • A rubric that writes down what correct means, agreed with your experts

  • Graders: code checks first, LLM judges checked against your experts' labels

    Each judge's agreement with your experts is reported per label, with n, on cases held out from judge tuning, beside the failures it caught.

  • Agent tasks with checkable end states, run k times in CI

  • Baseline and CI gate: threshold set from run-to-run variation, false alarms measured

    The gate fails the build when golden-set scores drop below the recorded baseline by more than a threshold set from the baseline's own run-to-run variation. Its false alarms on N unchanged runs and the smallest drop it detected at the stated n are reported.

  • Scheduled run against your model endpoint: catches sustained score drops, not intermittent faults

    The same suite, re-run on a schedule against the model endpoint your app calls, scores the golden set when you have shipped nothing.

Sample evaluation report, results page

Source: Our demo stack, run on our own demo agent and on τ-bench v1.0.1 tasks. The figures describe this demo only.

Test sets

Test set A: our demo support agent; cases and pass or fail labels written by Veriprajna's AI build agent, labels fixed before any judge prompt.

Test set B: an agent run in the τ-bench v1.0.1 retail environment (sierra-research/tau2-bench), judge-free tasks only, 28 held out from judge tuning. The two are reported apart.

Graders
Held-out splitAgreedFailures caught
B: judge vs the benchmark's end-state check23 of 28 tasks3 of 8
A: judge vs our labels24 of 24 cases7 of 7

Counted per task or case. Before judge tuning: B 20 of 28 and 2 of 8; A 19 of 24 and 6 of 7.

Agents

All 4 runs succeeded on 20 of 28 tasks (test set B); all 3 runs on 48 of 48 (test set A). Trajectories are shown separately and are not independent.

Gate

False alarms on unchanged runs, the smallest drop caught, and planted regressions caught and missed: run by run below.

Scheduled run

The run that first flagged a sustained drop we planted: step 5 below.

The gate on our own demo agent, run by run

Every gate we build reports these numbers on your cases. Here they are on our demo agent: real runs, in order.

Run chart of the demo gate. Twenty unchanged runs score 100% and set the threshold at 97.9%. A change we planted scores 95.1% and fails the build. Nineteen more unchanged runs stay at 100%. Of the planted regression runs, 8 are caught and 3 missed. The scheduled run stays green twice, then a planted drop is flagged on its second run below the threshold.

  1. All 20 scored 100%, so the margin is its preset minimum, one case in 48: threshold 97.9%.

    More

    The margin is the larger of three times the run-to-run spread and one case's worth of episodes (3 of 144), fixed before any results.

  2. The smallest drop it caught: a change we planted scored 95.1%, 4.9 percentage points down at n = 144, and the build failed.

  3. None of 19 further unchanged runs fell below the threshold: no false alarms.

    More

    One more unchanged run was left out of these figures because an episode errored; the sample report lists it.

  4. Planted regression runs: 8 caught, 3 missed. The 3 missed left the score unchanged, so no threshold could flag them.

  5. A drop we planted behind the model endpoint, with nothing committed, was flagged on its second consecutive run below the threshold.

See every run in the sample report

From a short review to a gate in your CI

Start with a short review, or go straight to the build. Durations depend on scope.

Eval review (optional first step)A written memo you keep: your failure modes, your definition of correct, and the metric and labelling plan, usable with or without us2 to 3 days
Details

We read a sample of your traces, or expert-written cases if you have none, against your goals, and draft the definition of correct with your expert.

Eval baseline buildDefaultThe six parts above, built on your cases and calibrated on a held-out split, with a handover session and a guide to the suite3 to 5 weeks
Details

No sandbox for your agent's tools yet? Building one as code in your repository is part of the build, quoted in the written scope.

Model-selection benchmark on your own casesCandidate models scored on your golden set, per rubric item, so a model choice or migration rests on your cases1 to 2 weeks
Details

Or run inside the build. Columns: quality per rubric item, latency, and cost per run. Why public leaderboards do not settle this: benchmarks versus your own cases.

We take no commission from any model, tool or guardrail vendor named in a report.

Regression upkeep and production trace scoringRe-baselining on model, prompt or retrieval changes, new suites, golden-set upkeep, and the same graders scoring sampled production tracesMonthly, scoped in writing
  • You provide: a sample or export of traces, handled under our data controls.
  • You provide: two domain experts' labelling time: the same cases for the rubric check, about 50 cases for judge calibration, agreed in the written scope.
  • You provide: repository and CI access, plus a sandbox, a test copy of your agent's tools, or recordings your engineers make of their responses.

When an evaluation build is worth it, and when it is not

A fit

  • A model, prompt or retrieval change is coming, and nobody can say whether quality holds
  • An agent is moving from demo to production, and "it worked when we tried it" is the only test
  • Your eval tool's scores do not predict what your users see
  • You want the suite in your own repository, run by your team, with agreement, stability and detection numbers you can show a board or customer

Not a fit

  • Independent assurance or a third-party test of an AI system
  • Security testing, red teaming or prompt-injection testing
  • An audit of whether today's answers are grounded in your sources
  • Choosing between AI vendors or products in procurement

Your repository, your merges: how we work and protect your data

What we commit to, and the controls on your traces and systems while we work.

You get

  • Handover on the last day of the build, and a written report within 5 business days of it ending
  • One re-baseline within 30 days of handover
  • Liability capped at the fees paid for the engagement, as set out in the MSA and SOW.
  • The eval review is an optional way to try us; the build can always be quoted directly.
  • Only third-party services agreed in your written scope see your code, traces or data.
  • We read none of your code or traces before a written scope, a mutual NDA and the DPA are signed.
  • Your engineer scans for keys and personal data before we read anything.
  • We push only after your main branch is protected and production secrets are out of our reach, or to a fork; you merge every change.
  • Our CI access carries no production secrets or deploy rights.
  • Judge-run cost is agreed in writing; the scheduled run calls only model endpoints.
  • No test content is ever written to a live system.
  • What we received is deleted from our systems 30 days after our last included work ends.
  • Never named or published without your written consent.
Read each control in full
  1. 1. Every third-party service that sees your code, configuration, prompts, traces, labels or test results, including any model or AI development tool, is agreed with you in the written scope, with its data settings; no other receives them.
  2. 2. A written scope, a mutual NDA and the DPA are signed before we read your code or traces; traces arrive as a pseudonymised export.
  3. 3. Your engineer scans the repository, git history included, and the export for keys and personal data. Anything we still find is reported, never used, and that file waits until cleaned.
  4. 4. Before we can push, your engineer protects the main branch and moves production secrets out of our reach, or gives us a fork. Work arrives as pull requests you merge.
  5. 5. Our CI access carries no production secrets or deploy rights. Model runs use our account within a budget in the written scope, or a non-production key you issue and revoke.
  6. 6. Cost per judge run is agreed in the written scope. The scheduled run calls only model endpoints: the one your app calls and, where a judge grades, the judge's.
  7. 7. Agent trials use only a sandbox, a test copy or recorded tool responses, never writing test content to a live system. Your engineers run any trials on your test copies.
  8. 8. Code, traces, labels, prompts and test material we received are deleted from our systems 30 days after our last included work ends. Agreed services follow the scope's data settings.
  9. 9. We never name you, reference the engagement or publish findings without your written consent.
Where your data goes during an engagement Traces arrive as a pseudonymised export after a written scope, a mutual NDA and the DPA are signed, then go into your repository or a store you choose, as pull requests you merge. Agent trials run only against a sandbox, a test copy or recorded tool responses; no test content is written to a live system. The scheduled run calls only model endpoints: the one your app calls and, where a judge grades, the judge's. Only third-party services agreed in the written scope, generation or grading services and model APIs included, receive anything. Copies are deleted 30 days after our last included work ends. Traces Pseudonymisedexport Scope, NDA and DPA signed Your repository Or a store you choose Pull requests you merge Agenttrials Sandbox or test copy Or recorded tool responses Live systems Scheduledrun Calls only Model endpoints Your app's and judge's Third-party services Generation or grading services, model APIs Only those agreed in the written scope Copies deleted 30 days after ourlast included work ends

Where your data goes during an engagement. Traces arrive as a pseudonymised export, then go into your repository or a store you choose. Agent trials run only against a sandbox, a test copy or recorded tool responses, with no test writes to live systems. The scheduled run calls only model endpoints: your app's and the judge's. Only third-party services agreed in the written scope receive anything.

An eval platform, your own framework, or a build with us

A platform or framework runs evaluators. The lasting work is deciding what correct means, which cases count, and whether graders agree with your experts.

QuestionA platform or framework on its ownAn evaluation build with us

Your team, in the evaluators it writes or configures.

A rubric written with your experts, tested by having two of them label the same cases.

Your team, if it collects expert labels and runs the comparison.

Yes: agreement with your experts' labels, per label and with n, on cases held out from judge tuning.

Your team, in the tool's settings.

From the baseline's own run-to-run variation, with its false alarms and the smallest drop it caught reported.

The datasets your team assembles.

Real-traffic cases, known failures and cases written with your experts, kept apart by source.

Whatever your team has built and kept.

The suite, golden set, rubric and labels in your repository, run with no call to our systems and no licence fee.

It stays in place.

No. We build in your existing test runner and CI; platform compatibility is confirmed in the written scope.

How we build each part, and the check it must pass

Each part is checked before you rely on it: the rubric against two of your experts, the graders against their labels, and the gate against its own noise.

The evaluation pipeline Cases from real traffic, known failures and expert-written cases form the golden set, kept apart by source, one row of dots per source. A rubric writes down a definition of correct. Code checks and LLM judges, calibrated on a held-out split, grade each case and each agent run. Agent tasks run k times in a sandbox. Scores are compared with the pinned baseline and its threshold in the CI gate. The scheduled run uses the same graders and threshold against the model endpoint. Numbered pins match the list beside the diagram. Golden set Kept apart by source Real traffic Known failures Expert-written cases 1 Rubric A written definitionof correct 2 Graders Code checks and LLMjudges, calibrated on aheld-out split 3 Agent tasks Run k timesin a sandbox 4 Baseline and CI gate Pinned baseline Threshold 5 Scheduled run Same gradersand threshold 6 Model endpoint

The evaluation pipeline: cases from real traffic, known failures and expert-written cases form the golden set; a rubric defines correct; code checks and calibrated judges grade each case; agent tasks run k times in a sandbox; scores are compared with the recorded baseline in CI; the same suite re-runs on a schedule against the model endpoint.

Tap a build step to zoom the map to it.

Build steps

  1. Golden set kept apart by source, so only a random sample of real traffic can carry an interval or a measured rate

    Known-failure and expert-written cases are reported separately, as results on a test set. Real-traffic cases are pseudonymised before commit by default, or kept in a store you choose with only references in the repository.

  2. Rubric with your experts a written definition of correct for each case type, tested by having two of your experts label the same cases

    Where two experts disagree, the case or the rubric is rewritten before any grader is tuned against it. Who labels is agreed in the written scope.

  3. Graders code checks where code can decide, LLM judges where it cannot, calibrated on a held-out split; for RAG, retrieval and answer scored apart

    The held-out split is fixed before any judge-prompt work, and the first pass is kept as the before. Agreement is computed per case, the independent unit, per label and with n. A judge from the same model family as the system under test is disclosed as a self-enhancement risk.

  4. Agent tasks each trial starts from a clean environment, so leftover state cannot cause or hide a failure

    Results are per task: all k runs succeeded, or not.

  5. Baseline and CI gate offline, each change is gated in CI against the pinned baseline, and the gate's numbers are recomputed when the golden set or graders change

    The stability run of N unchanged runs measures run-to-run variation and sets the threshold, and its false alarms are counted. Regressions of several sizes, planted on a copy, show which are caught and which are missed.

  6. Scheduled run configured in your CI scheduler, with the same graders and threshold as the gate, flagging a drop that persists across runs

Grader types, outcome grading, pass^k and transcript reading: Anthropic, Demystifying evals for AI agents, 9 Jan 2026. pass^k was proposed in Yao et al., τ-bench, 2024. Named companies and projects are cited as sources or test environments only; Veriprajna is not affiliated with them.

Standards your results map to

The suite produces measurement evidence relevant to these requirements.

Baseline and CI gate

One part of the method, mapped to the requirements below.

  • NIST AI RMF 1.0 (AI 100-1)MEASURE 2.3, MEASURE 2.5, MEASURE 4.2
  • ISO/IEC 42001:2023A.6.2.4 AI system verification and validation
  • EU AI Act, Regulation (EU) 2024/1689Article 15(1) and 15(3), for providers of high-risk AI systems
  • EU: under Article 113 as amended by Regulation (EU) 2026/1744, Article 15 applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Systems placed on the market or put into service before then are covered only if their design changes significantly afterwards; systems intended for use by public authorities must comply by 2 August 2030 in any case (Article 111(2)).
Read more

MEASURE 2.3: "AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented."

MEASURE 2.5: "The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented."

MEASURE 4.2: "Measurement results regarding AI system trustworthiness in deployment context(s) and across the AI lifecycle are informed by input from domain experts and relevant AI actors to validate whether the system is performing consistently as intended. Results are documented."

NIST AI 600-1 (July 2024), the Generative AI Profile, is a companion resource to the AI RMF for generative AI.

EU AI Act Article 15(1): "High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle." Article 15(3): "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use."

Questions about LLM evaluation, judges and golden sets

8 questions

Which LLM evaluation metrics and criteria should we use?

Start from the failures that matter to you, not from a metric list. Use code checks for anything code can decide (format, values, tool arguments, end state), a rubric scored by a calibrated judge for what it cannot, and expert labels to calibrate that judge. For RAG, score retrieval and the answer separately. A worked RAG example shows one case.

Can we trust an LLM as a judge, and how do you check one?

As far as its measured agreement with your experts, and no further. Research has examined position, verbosity and self-enhancement biases in LLM judges, as well as limited reasoning ability. We check each judge against your experts' labels on cases held out from judge tuning and report agreement per label, with n.

We could build our own LLM evaluation framework, or we already use an eval tool. What does an engagement add?

Your framework or platform runs evaluators; the lasting work is deciding what correct means, which cases count, and whether the graders agree with your experts. We build in your existing test runner and CI; platform compatibility is confirmed in the written scope. What we deliver runs with no call to our systems and no licence fee, and the test set, rubric and labels are assigned to you.

What is a golden dataset in LLM evaluation, and how many cases does it need?

A fixed, versioned set of cases with agreed labels that every change is scored against. Anthropic's engineering guidance calls 20 to 50 simple tasks drawn from real failures a great start for an agent. Detecting smaller drops takes more cases: the count follows from the smallest drop you need to see and how much scores vary between cases, a statistical minimum rather than a universal number.

How does LLM evaluation work in production?

Online LLM evaluation means the same graders score a sample of production traces, and failures go back into the golden set; offline, the golden set gates each change in CI. The scheduled run re-checks the model endpoint when you ship nothing, and upkeep keeps the baseline current. Tracing, dashboards and alerting belong to production monitoring, a separate service.

How is a quote scoped?

After you email or WhatsApp us, through a free 30-minute discovery call: what you ship, which changes are coming, whether you have traces, and who can label. You get a written scope and a fixed fee within 2 business days of the call. The fee is agreed in writing before any work.

When can you start?

The earliest start date is in the written scope. The fixed fee does not change if the schedule slips on our side, and you can halt or end the engagement at any time.

Can we share the results with our customers?

Your results and test set are yours; what you tell your customers about your own testing is your decision. The report is prepared for you only; no third party may rely on it, and we issue no letters, and we do not name ourselves to your customers without written consent. Only the real-traffic estimate may be described as a measured rate; other results are failures found on a test set.

Evaluating LLM apps and agents: the evidence behind the method

RAG evaluation: one case, graded in two parts

Imagine a support assistant that answers from a policy library. One case from its golden set, graded the way we would grade it:

  • Case: "Can I return an opened item after 30 days?"
  • Retrieval check: Did the returns-policy passage come back in the top results? (code check against labelled passages)
  • Answer check: Is every claim in the answer supported by the retrieved passages, and does it match the label "no, except faulty items"? (calibrated judge, then code check on the label)

Scored as one number, a wrong answer could come from either half. Scored apart, a retrieval miss points to the index or the query, and an unsupported answer points to the prompt or the model.

The RAGAS authors describe the same split: the ability of the retriever "to identify relevant and focused context passages" and of the model "to exploit such passages in a faithful way", with metrics that need no ground-truth labels. A 2025 survey of 63 articles on RAG evaluation likewise treats the retriever and the generator as separate areas.

In RAG evaluation, metric choice follows the failure. If the risk is a wrong value, use a code check on the value. If it is an unsupported claim, use a faithfulness judge calibrated on your labels. If it is the wrong passage, use a retrieval check against labelled passages. Reference-free metrics help where labels are scarce; a judge still needs your experts' labels before its score blocks a release.

Public benchmarks and leaderboards versus your own cases

Public benchmarks score a model on someone else's tasks, graded someone else's way. They help shortlist models, but they cannot show how a model does on your prompts, your documents and your definition of correct. Their scores can also be inflated when benchmark data leaked into training.

A 2024 survey describes benchmark data contamination as language models "inadvertently" incorporating "evaluation benchmark information from their training data, leading to inaccurate or unreliable performance during the evaluation phase" (Xu, Guan, Greene and Kechadi, arXiv 2406.04244).

For a model choice, LLM evaluation and benchmarking become one job: each candidate model is scored per rubric item on your golden set, with latency and cost per run beside it, by the same graders that will gate your releases.

What the research says about LLM judges

Zheng and colleagues, who introduced MT-Bench and Chatbot Arena, examined "position, verbosity, and self-enhancement biases, as well as limited reasoning ability" in LLM judges, and proposed mitigations for some of them (arXiv 2306.05685, NeurIPS 2023 Datasets and Benchmarks Track). Anthropic's engineering guidance lists model-based graders as "Non-deterministic" and says they require "calibration with human graders for accuracy"; "LLM-as-judge graders should be closely calibrated with human experts".

Two practical consequences. First, a judge is only as good as the rubric: Anthropic notes that "Ambiguity in task specifications becomes noise in metrics", which is why the rubric is tested on two experts before any judge is tuned. Second, agreement measured on the cases the judge prompt was tuned on says little about the cases it has not seen.

Agent evaluation: outcomes, repeated trials and transcripts

For agents, Anthropic separates the transcript from the outcome: "The outcome is the final state in the environment at the end of the trial." Its example is a flight-booking agent that says the flight is booked, where the outcome is whether a reservation exists in the environment's SQL database. It also warns against grading the exact path: "it's often better to grade what the agent produced, not the path it took."

Agents vary between runs, so one pass proves little. pass^k "measures the probability that all k trials succeed". It was proposed with τ-bench, whose authors reported, on the original 2024 task set, that even "state-of-the-art function calling agents" succeeded on fewer than half of the tasks and were "quite inconsistent" ("pass^8 <25% in retail").

Trials must also be isolated. Anthropic advises that each trial start "from a clean environment", because shared state between runs "can cause correlated failures due to infrastructure flakiness" and "can also artificially inflate performance". Finally, the transcripts are read: "You won't know if your graders are working well unless you read the transcripts and grades from many trials."

Know whether your next model, prompt or retrieval change holds quality

Whether you are changing models, taking an agent to production or getting more from an eval tool you already run, start with a short conversation about your product.

Email us
  1. Email or WhatsApp us
  2. Reply within 1 business day
  3. Free 30-minute discovery call
  4. Written scope and fixed fee within 2 business days of the call
WhatsApp
Chat instantly
Book a Call
Schedule via Calendly
Email
[email protected]