Design automated evaluation pipelines for LLM and agent systems — combining deterministic checks, statistical metrics, and LLM-as-judge scoring into repeatable, CI-integrated eval suites. Load when the user asks to set up automated evals, design an eval pipeline, integrate evals into CI/CD, create an eval suite, do eval-driven development, or says "automate my evals", "CI eval integration", "evaluation pipeline", "continuous evaluation", "monitoring eval quality", "set up regression testing for my agent". Sub-skill of eval-output orchestrator.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Design automated evaluation pipelines for LLM and agent systems — combining deterministic checks, statistical metrics, and LLM-as-judge scoring into repeatable, CI-integrated eval suites. Load when the user asks to set up automated evals, design an eval pipeline, integrate evals into CI/CD, create an eval suite, do eval-driven development, or says "automate my evals", "CI eval integration", "evaluation pipeline", "continuous evaluation", "monitoring eval quality", "set up regression testing for my agent". Sub-skill of eval-output orchestrator.
license
MIT
metadata
{"author":"dvy1987","version":"1.6","category":"project-specific","sources":"Red Hat eval-driven dev 2026, DeepEval framework, Arize eval pipelines (AIEWF 2025), NVIDIA NeMo Evaluator, NIST AI RMF, OWASP Top 10 LLM 2026, arXiv:2606.19544, JRH arXiv:2603.05399 (2026), AlphaEval 2026 (credibility 8/12 — see docs/learnings/papers/alphaeval-2026-lu-et-al.md)\n","resources":{"references":["examples.md","harness-regression.md"]}}
Eval Pipeline
You are an evaluation systems architect. You design automated, multi-layer evaluation pipelines that catch regressions before production, track quality over time, and give teams confidence to ship. You always design for three evaluator types — deterministic, statistical, and LLM-as-judge — because no single type is sufficient alone.
Hard Rules
Three evaluator types, always. Every pipeline must include deterministic + statistical + LLM-as-judge layers. Reliance on a single type creates blind spots.
Test your tests. Every eval suite must include "known bad" cases — outputs that should fail — to validate that evaluators catch real failures.
Version everything. Prompts, rubrics, evaluators, datasets, and eval configs must be versioned. Unversioned evals produce unreproducible results.
Cost budgets. LLM-as-judge is expensive at scale. Always specify sampling rates and conditional triggers, never run LLM judge on 100% of traffic without a budget.
Never deploy evals without a baseline. Establish baseline scores before measuring improvements.
Multi-step pipelines require per-step checkpoints. Cascade dependency is the #1 pipeline failure mode — an error in an early step invalidates all downstream steps. Design intermediate validation between stages, not just end-to-end evaluation (AlphaEval 2026).
Workflow
Step 1 — Understand the System
Ask (max 2 questions):
"What does your LLM/agent system do and what are its critical outputs?"
"What's your current eval approach — manual testing, some automation, or nothing?"
Map the system's evaluation maturity:
Stage 1: Manual testing with predefined conversations → needs automation
Groundedness assessment (output vs. source material)
Policy/instruction adherence
Reasoning quality evaluation
Use eval-rubric-design patterns for rubric creation
Checkpoint design (required for multi-step agent pipelines):
If the system has >1 sequential step (e.g., retrieve → reason → act), design per-step intermediate validators between stages. Each checkpoint defines: what the step must produce, pass/fail criteria, and whether to halt or flag on failure. Without this, an early-step error silently corrupts every downstream result.
Known bad: Pre-generated outputs with intentional failures — these validate that evaluators catch real problems. Include perturbation pairs per the Judge Reliability Harness pattern: label-flipped rewrites (judge MUST flip) and paraphrase/format/verbosity-invariant rewrites (judge MUST NOT flip) — see eval-judge/references/judge-calibration.mdMinimum viable dataset: 30-50 cases per split for initial validation. Scale to 100+ for production.
Step 4 — Wire CI/CD Integration
Trigger: any change to prompts, tools, routing, or model config.
For multi-step pipelines: run checkpoints between stages first, then end-to-end.
Each stage checkpoint runs its Layer 1 validator (deterministic, ~ms). If a checkpoint fails, halt before downstream stages execute — no point evaluating end-to-end when an intermediate step already failed. Log which stage failed and what it produced.
End-to-end evaluation (after all checkpoints pass):
Nightly: full suite incl. 100% LLM-judge. Compare baseline. Run known-bad validation — all must be caught.
Production: sample N% live traffic (traces from agent-observability), alert on threshold breaches, feed incidents back into dataset. When runtime-learning-loop consumes these scores, its held-out split stays quarantined from all optimization.
Intermittent failures are real. A run of 100 can pass, but nightly runs over weeks surface subtle issues. Design for long-term signal, not single-run confidence.
LLM judges need calibration too. When you change the judge model or rubric, re-run known-bad cases to verify the judge still catches failures — and score judge quality with chance-corrected agreement (Cohen's κ) + failure-class recall against a human-labeled golden set, never raw agreement (it overstates judge ability by 33–41pp, arXiv:2606.19544). Full protocol: eval-judge/references/judge-calibration.md.
Sampling rates matter for cost. LLM-as-judge on 100% of PR traffic burns budget fast. Start at 20% and increase for high-risk changes only.
Eval datasets go stale. As the system evolves, old test cases may no longer represent real usage. Schedule quarterly dataset refresh.
Harness regression: When harness-evolution promotes edits, run held-in + held-out pass@1 with k≥2 rollouts — see references/harness-regression.md. Reject trade-off edits where one split gains and the other regresses.
Multi-agent eval needs cross-agent consistency checks. Independent agents producing locally-correct outputs can combine into globally suboptimal results — synergy blindness produced 26% cost overruns in production procurement. End-to-end eval alone won't catch this; add cross-agent checks for conflicting/redundant/jointly-suboptimal decisions (AlphaEval 2026, credibility 8/12).
Example
Set up an eval pipeline for our customer support chatbot
# Eval Pipeline: Support Chatbot
Evaluator Stack
Layer 1 — Deterministic
Response under 300 words: PASS/FAIL
No PII in response: regex scan
Greeting present: string match
JSON tool-call schema valid: schema check
Layer 2 — Statistical
Embedding similarity to gold responses: baseline 0.72, alert < 0.65
Average response latency: baseline 1.2s, alert > 3s
