---
title: "AI evaluation: test the behavior you will actually ship"
description: "Published Arne Kellmann website information and agent integration guidance."
canonical: https://arnekellmann.de/ai-evaluation
last-updated: 2026-09-26
---

# AI evaluation: test the behavior you will actually ship

Build an evaluation set from real tasks, test failure behavior and compare quality, latency and cost. A practical guide with first-party replay and prompt-injection studies.

## Define a useful answer before comparing models

A valid JSON response can still contain the wrong decision. Separate format checks from the judgment that matters to the user. Record the input, available context and expected behavior, including cases where the system should decline to answer.

Start with representative tasks and known failures. Keep a held-out set for the release decision so repeated prompt tuning does not simply optimize against the examples you already know.

## Test the boundaries as well as the happy path

An evaluation set needs explicit failure cases. Agree on unacceptable outcomes before the run, and preserve the evidence behind each result.

| Case | What to check |
| --- | --- |
| Missing or conflicting evidence | Does the system state uncertainty rather than invent an answer? |
| Prompt injection in a retrieved source | Can source text change instructions or trigger an unauthorized action? |
| Provider timeout or rate limit | Does the retry or fallback stay within the agreed time and cost budget? |
| Invalid or unsupported output | Does deterministic validation stop the action before it has a side effect? |

## Compare the complete request path

Use the same inputs, context and scoring rules across candidates. Record model and prompt versions, quality, round-trip latency, token usage, retries and fallback outcomes. When correctness needs human judgment, reviewers should use a written rubric rather than an unrecorded impression.

Keep slow or failed requests in the report. A system that gives a strong answer after the user’s deadline has not completed the same task as one that answers in time.

## A replay is evidence with a boundary

My published model comparison used 506 decisions per model and one day of Kraken BTC/USD trades. It illustrates why latency can change the practical value of a decision; it is not live-trading evidence or a general model ranking. The method, measured results and limitations are available in the article below.

Rerun the relevant cases when the prompt, model, retrieval source or tool permissions change. Decide whether to release from those results, then monitor production separately: a replay cannot establish every behavior of a live system.

- [The slow model was right more often: replay method and limits](/blog/the-slow-model-was-right-more-often)
- [Jev: decisions rather than generated text](/blog/jev-decisions-not-text)
- [Prompt-injection tests in my own AI factory](/blog/i-attacked-my-own-ai-factory)