AI Evaluation and Quality Engineering

An AI system can fail at several layers even when the final text looks plausible. Define what the user task requires and classify failures before selecting a metric. Business outcomes need separate measurement from model response quality.

• Retrieval versus response versus task quality
• Deterministic and probabilistic tests
• Failure categories and acceptance criteria

Planned lab. Review ten seeded failures and map each to the component and evidence needed.

Expected output. Quality model and failure taxonomy.

Examples should reflect the task population and important exceptions. Preserve source provenance and labels, and keep a holdout set separate from examples used for tuning. A small curated set is useful for a lab but does not establish broad reliability.

• Representative cases and expected evidence
• Labelling guidance and reviewer disagreement
• Dataset versioning and holdout separation

Planned lab. Build a small versioned dataset with normal, unsupported, restricted, ambiguous, and failure cases.

Expected output. Dataset, label guide, and coverage inventory.

Use code to check behaviours that have explicit expected outcomes. Separate candidate-source checks from the question of whether a generated claim is supported. Explain the denominator and dataset composition for every reported rate.

• Schema and exact boundary checks
• Expected source retrieval and negative cases
• Tool arguments and action-state checks

Planned lab. Implement checks for required and forbidden source IDs, valid schemas, tool arguments, and approved state changes.

Expected output. Repeatable deterministic evaluation suite.

A review rubric needs clear anchors and examples. A model-assisted judge can help organise review, but it can also be biased or inconsistent. Compare its judgements with human labels before treating the scores as reliable evidence.

• Support, relevance, and task-completion rubrics
• Judge calibration and disagreement review
• Bias, leakage, and scorer limitations

Planned lab. Score sampled answers manually, run a model-assisted judge where authorised, and investigate disagreements.

Expected output. Calibrated rubric and disagreement analysis.

Compare changes against a fixed baseline and record prompt, model, data, and configuration versions. Repeated trials may reveal unstable behaviour. A higher average score can hide an important failing subgroup or a higher cost per useful task.

• Baseline and candidate comparison
• Repeated runs and confidence limits
• Quality cost and latency trade-offs

Planned lab. Compare two candidate configurations and document the cases that improve, regress, or remain uncertain.

Expected output. Experiment report and decision thresholds.

Evaluation should run when relevant application assets change and should learn from operational feedback. Avoid letting new production examples contaminate a holdout set without version control. Define who investigates a failed release gate.

• CI integration and reports
• Feedback triage and new regression cases
• Sensitive-data handling in evidence

Planned lab. Add a release check and convert one observed failure into a versioned regression case.

Expected output. Pipeline specification and feedback process.

Review a candidate AI application as a quality owner. Present evidence, unresolved risks, and a clear release decision. A failed critical boundary should remain visible even if the aggregate quality score appears acceptable.

• Independent holdout run
• Error analysis and manual sampling
• Release recommendation and evidence index

Planned lab. Evaluate a supplied support agent candidate, reject or accept it with conditions, and defend the decision.

Expected output. Evaluation pack and release memo.