Selbst gehostete Evals für KI-Agenten einrichten

Was selbst gehostete Evals für KI-Agenten sind

Selbst gehostete Evals für KI-Agenten bestehen aus vier Dingen, die Sie in Ihrem eigenen Repository verwalten: einer Datei mit gespeicherten Fällen, einem Skript, das den Agenten darauf ausführt, einer Reihe von Prüfungen zur Bewertung jeder Antwort und einer abfragbaren Ergebnistabelle. Nichts davon benötigt einen Anbieter. Der gesamte Ablauf umfasst einige hundert Zeilen Python und eine SQLite-Datei.

Der Agent funktionierte in der Demo, weil Sie die fünf Eingaben selbst ausgewählt hatten. In der zweiten Woche schlug er fehl, weil sich eine Prompt-Zeile, ein Modell oder eine Tool-Beschreibung geändert hatte und keine Messung diese Änderung erfasste. Ein Eval-Ablauf macht aus „es fühlt sich jetzt schlechter an“ die Aussage „Die Erfolgsrate ist bei Commit 4f1c9ab von 58 von 60 auf 51 von 60 gesunken“.

Der Ablauf umfasst vier Schritte. Dieser Leitfaden enthält für jeden Schritt einen eigenen Abschnitt: reale Traces sammeln, die interessanten Traces in Fälle überführen, jeden Fall bei jeder Änderung bewerten und die Erfolgsrate neben dem Commit speichern, durch den sie entstanden ist. Derselbe Ablauf funktioniert unabhängig davon, worauf Sie den Agenten ausführen. Die selbst gehosteten Agent-Frameworks, deren Betrieb sich lohnt unterscheiden sich hauptsächlich darin, wie viele Informationen aus dem Trace sie Ihnen standardmäßig bereitstellen.

Warum der Agent in der zweiten Woche ausfällt

Ein Agent besteht aus einem Prompt, einem Modell, einer Reihe von Tool-Definitionen und dem Kontext, der zur Laufzeit abgerufen wird. Alle vier Bestandteile können sich ändern, ohne dass Sie den Anwendungscode anpassen. Eine normale Codeprüfung erkennt daher keinen offensichtlichen Änderungsbedarf.

Die häufigste Ursache ist eine Prompt-Änderung. Sie fügen einen Satz hinzu, damit keine unhöfliche Antwort mehr ausgegeben wird. Dieser Satz verändert das Verhalten bei Eingaben, die niemand erneut getestet hat. Die Traces zeigen das eindeutig: Der Trace der letzten Woche für dieselbe Frage enthält einen create_refund-Tool-Aufruf, der Trace dieser Woche enthält keinen, und stattdessen wird eine höfliche Entschuldigung ausgegeben. Es ist kein Fehler aufgetreten. Daher wurde auch kein Alert ausgelöst.

Die zweite Ursache ist das Modell. Protokollieren Sie bei jedem Lauf den exakten Modell-String, den Sie gesendet haben, claude-haiku-4-5-20251001, statt sich auf eine Kurzbezeichnung zu verlassen, die Sie nur im Kopf führen. Eine sinkende Erfolgsrate an dem Tag, an dem Sie das Modell gewechselt haben, lässt sich nur diagnostizieren, wenn das Modell in der jeweiligen Zeile erfasst ist.

Die dritte Ursache sind die Tools. Eine Umformulierung der Tool-Beschreibung verändert den Zeitpunkt, zu dem das Modell den Aufruf des Tools entscheidet. Wenn Ihre Tools über MCP-Server auf einem VPS bereitgestellt werden, liegt das Schema in einem anderen Prozess. Es kann sich daher unbemerkt ändern, ohne dass in Ihrem Repository überhaupt ein Diff entsteht. Die vierte Ursache ist der Abruf von Kontext: Dieselbe Frage trifft auf einen Index, der über Nacht neu erstellt wurde, und die Antwort basiert auf dem neuen Dokument.

Erstellen Sie den Golden Set aus bereits erfassten Traces

Erfinden Sie keine Eval-Fälle. Übernehmen Sie sie aus dem Traffic. Wenn Sie bereits Self-Hosted-Langfuse-Tracing für Ihren Agenten verwenden, wird jede Anfrage mit ihrer Eingabe, ihren Tool-Aufrufen und ihrer Ausgabe gespeichert. Genau daraus lässt sich ein Fall erstellen.

Exportieren Sie über die öffentliche API ein Zeitfenster mit Root-Beobachtungen. Die API verwendet die Basic-Authentifizierung. Ihr Public Key ist der Benutzername und Ihr Secret Key das Passwort.

export LF_HOST="https://langfuse.example.com"
curl -sS -u "$LF_PUBLIC_KEY:$LF_SECRET_KEY" \
  "$LF_HOST/api/public/v2/observations?limit=50&isRootObservation=true&fromStartTime=2026-07-01T00:00:00Z" \
  | jq '.data[0]'

Lesen Sie einen Datensatz, bevor Sie Parsing-Code schreiben. Die Zeilen werden unter data zurückgegeben. Die Feldnamen für Frage und Antwort hängen jedoch davon ab, wie Ihr Agent seine Spans instrumentiert. Ordnen Sie daher die tatsächlich vorhandenen Felder zu und nicht die erwarteten. Schreiben Sie die Fälle anschließend manuell als jeweils ein JSON-Objekt pro Zeile in evals/cases.jsonl:

{"id": "refund-double-charge", "tags": ["smoke"], "input": "I was charged twice for order 41822.", "must_call": ["lookup_order", "create_refund"], "must_not_include": ["I cannot help"], "rubric": "The reply confirms exactly one refund for order 41822 and states the amount."}

Mit fünf Regeln bleibt der Datensatz für Ausführungen geeignet:

• 40 bis 80 Fälle reichen für den Anfang. Bei weniger als 20 Fällen verändert ein einzelner fehlerhafter Fall die Erfolgsrate um 5 Punkte. Eine Zahl, die ohne erkennbaren Grund stark schwankt, wird ignoriert.
• Jeder in der Produktion behobene Fehler wird am Tag seiner Behebung zu einem Fall. Diese Gewohnheit sorgt dafür, dass der Datensatz in die richtige Richtung wächst.
• Pro Fall wird genau ein Verhalten geprüft. Ein Fall, der gleichzeitig den Erstattungsbetrag und den Ton prüft, liefert bei einem Fehlschlag keine eindeutige Information.
• id wird nie geändert, weil die ID den Vergleich des heutigen Laufs mit dem Lauf des letzten Monats ermöglicht.
• Redigieren Sie die Daten, bevor Sie sie committen. Diese Datei wird in Git eingecheckt. Entfernen Sie daher Kundennamen und alle Bestellnummern, die nicht Ihnen gehören.

Bewerten Sie zuerst mit deterministischen Prüfungen, weil diese kostenlos sind

Alles mit einer eindeutigen richtigen Antwort wird per einfacher Assertion geprüft. Es ist kein Modellaufruf erforderlich, es entstehen keine Kosten und es gibt keine Mehrdeutigkeit. Deterministische Prüfungen erkennen strukturelle Regressionen. Diese Regressionen führen zu Fehlern in den Systemen rund um Ihren Agenten: Das JSON lässt sich nicht parsen, das Tool wurde nie aufgerufen, die verbotene Formulierung ist wieder enthalten oder die Antwort nennt keine Quelle.

Nur eine Funktion muss Ihren Agenten kennen. Alles andere im Test-Harness bleibt generisch.

import json, os, urllib.request

def run_agent(case):
    req = urllib.request.Request(
        os.environ["AGENT_URL"],
        data=json.dumps({"input": case["input"]}).encode(),
        headers={"content-type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)


def deterministic(case, result):
    text = result.get("output", "")
    called = [c["name"] for c in result.get("tool_calls", [])]
    failures = []
    for tool in case.get("must_call", []):
        if tool not in called:
            failures.append(f"tool not called: {tool}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text.lower():
            failures.append(f"forbidden phrase: {phrase}")
    if len(called) > case.get("max_tool_calls", 12):
        failures.append(f"too many tool calls: {len(called)}")
    return failures

Behalten Sie das Tool-Budget in dieser Liste. Ein Agent, der einen Fall heute mit 3 Aufrufen und morgen mit 11 Aufrufen löst, hat sich verschlechtert, selbst wenn die endgültige Antwort korrekt ist, weil jeder Aufruf Kosten verursacht.

LLM als Bewerter und die vier Arten, wie er Fehler macht

Was die Assertions übersteht, braucht einen Bewerter, der lesen kann. Ein LLM-Bewerter ist ein zweiter Modellaufruf: Er erhält die Frage, die Antwort des Agenten und ein Kriterium und gibt anschließend ein Urteil zurück. Das ist die einzige praktikable Möglichkeit zu bewerten, ob die Antwort die Frage des Benutzers beantwortet.

Vier Regeln machen einen Bewerter brauchbar:

• Binäres Urteil, niemals eine Bewertung von 1 bis 10. Eine Skala liefert für fast alles 7 oder 8. Die Zahl verändert sich dadurch kaum, und Sie lernen nichts daraus.
• Pro Aufruf ein Kriterium. Fragen Sie entweder nach dem Erstattungsbetrag oder nach dem Ton, nicht nach beidem gleichzeitig.
• Geben Sie dem Bewerter die erwartete Antwort, sofern für den Fall eine solche existiert. Die Bewertung anhand einer Referenz ist deutlich einfacher als eine abstrakte Bewertung.
• Erzwingen Sie das Ausgabeformat und parsen Sie es strikt.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment


def judge_prompt(case, output):
    return (
        "You grade one answer against one criterion.\n"
        "Reply with JSON only, in this exact shape:\n"
        '{"verdict": "pass", "confidence": "high", "reason": "one short sentence"}\n'
        f"Criterion: {case['rubric']}\n"
        f"Question: {case['input']}\n"
        f"Answer: {output}\n"
        "Length is not a criterion. Judge only the criterion above."
    )


def judge(case, output, model):
    msg = client.messages.create(
        model=model,
        max_tokens=200,
        messages=[{"role": "user", "content": judge_prompt(case, output)}],
    )
    return json.loads(msg.content[0].text)

Nun zu den Fehlerquellen. Für jede gibt es einen Test, den Sie noch heute Nachmittag ausführen können. Diese Tests sind wichtig, weil ein ungeprüfter Bewerter Zahlen erzeugt, die präzise aussehen, aber keine Bedeutung haben.

Längenverzerrung. Längere Antworten werden häufiger akzeptiert. Testen Sie dies: Nehmen Sie zehn Antworten, die der Bewerter abgelehnt hat, und ergänzen Sie jede um zwei Absätze mit selbstsicherem Fülltext, der keine neue Tatsache enthält. Bewerten Sie sie anschließend erneut. Wechselt ein Urteil zu „bestanden“, liegt eine Längenverzerrung vor. Dann müssen Sie die Bewertungsrichtlinie korrigieren.

Selbstpräferenz. Ein Bewerter bewertet Ausgaben aus seiner eigenen Modellfamilie häufig großzügiger als Ausgaben eines anderen Modells. Testen Sie dies: Bewerten Sie dieselben 30 Antworten mit Bewertern aus zwei verschiedenen Modellfamilien und vergleichen Sie die Urteile für jeden Fall. Bei Abweichungen prüfen Sie den Fall selbst.

Positionsverzerrung. Wenn Sie den Bewerter zum Vergleich zweier Antworten A und B verwenden, vertauschen Sie die Reihenfolge und führen Sie den Test erneut aus. Wechselt das Urteil durch die Vertauschung, ist der paarweise Vergleich für diese Bewertungsrichtlinie noch nicht zuverlässig.

Abweichung der Bewertungsrichtlinie. Vage Kriterien führen zu Bewertern, die fast alles akzeptieren. „Ist die Antwort hilfreich?“ akzeptiert nahezu jede Antwort. „Nennt die Antwort den Erstattungsbetrag in Dollar?“ akzeptiert nur Antworten, die genau das enthalten. Überarbeiten Sie jedes Kriterium, bis es die zu prüfende Tatsache eindeutig benennt.

Ein Schutzmechanismus deckt alle vier Probleme ab. Bewahren Sie 30 Fälle auf, die Sie manuell beschriftet haben, und vergleichen Sie den Bewerter jedes Mal mit Ihren Beschriftungen, wenn Sie das Bewertermodell oder den Prompt des Bewerters ändern. Weicht er in mehr als einem von zehn Fällen von Ihnen ab, korrigieren Sie die Bewertungsrichtlinie, bevor Sie einer von ihm erzeugten Bestehensquote vertrauen. Der Bewerter ist Code. Deshalb wird er wie Code versioniert und geprüft.

Günstige Modelle bewerten lassen und bei Bedarf auf ein Frontier-Modell eskalieren

Jeden Fall bei jedem Commit mit dem teuersten Modell zu bewerten, lässt die Evaluierungskosten schneller wachsen als den Agenten, den sie testet. Ordnen Sie die Bewertungsmodelle nach Preis und beenden Sie die Bewertung, sobald das Ergebnis eindeutig ist.

[
  {
    "label": "Haiku 4.5, Batch API",
    "usd_per_1000_judge_calls": "0.90"
  },
  {
    "label": "Haiku 4.5",
    "usd_per_1000_judge_calls": "1.80"
  },
  {
    "label": "Sonnet 5",
    "usd_per_1000_judge_calls": "3.60"
  },
  {
    "label": "Opus 5",
    "usd_per_1000_judge_calls": "9.00"
  }
]

Diese Werte basieren auf etwa 1,200 Eingabetokens und 120 Ausgabetokens pro Bewertungsaufruf. Das ist eine realistische Größe für eine Frage, eine Antwort und ein Kriterium. Die Bewertung von 1,000 Fällen kostet 1.80 US-Dollar mit Claude Haiku 4.5 und 9.00 mit Claude Opus 5. Der Unterschied wirkt zunächst gering, bis Sie ihn hochrechnen. Ein Satz mit 60 Fällen, der bei jedem Commit bewertet wird, verursacht bei 40 Commits pro Woche 2,400 Bewertungsaufrufe pro Woche, bevor jemand den nächtlichen Job ausgeführt hat.

Zwei Rabatte lassen sich für Evaluierungsaufgaben direkt nutzen, und sie sind kombinierbar. Evaluierungsläufe sind nicht interaktiv. Die Batch API halbiert daher die Preise für Eingaben und Ausgaben und liefert die Ergebnisse asynchron. Das ist die erste Zeile des Diagramms. Rubrik und Anweisungen sind bei jedem Aufruf bytegenau identisch. Daher eignet sich Prompt-Caching: Ein Cache-Lesevorgang kostet ein Zehntel des regulären Eingabepreises. Das Schreiben in den Cache für fünf Minuten kostet das 1.25-Fache des regulären Eingabepreises. Der Cache amortisiert sich daher bereits nach einem einzigen Treffer. Dies sind die Listenpreise von Anthropic im August 2026. Sonnet 5 wird bis zum 31. August 2026 zu einem Einführungspreis angeboten. Danach steigt der dritte Balken.

Die Reihenfolge:

• Deterministische Prüfungen für jeden Fall. Es fallen keine API-Kosten an.
• Ein Bewertungsmodell mit geringer Größe für die Fälle, die diese Prüfungen bestanden haben.
• Ein Frontier-Bewertungsmodell nur dann, wenn das kleinere Modell den Fall als nicht bestanden bewertet oder mit geringer Konfidenz als bestanden einstuft.
• Einmal pro Woche eine manuelle Prüfung einer kleinen Stichprobe.

CHEAP = "claude-haiku-4-5-20251001"
STRICT = "claude-opus-5"


def grade(case, result):
    hard = deterministic(case, result)
    if hard:
        return False, "deterministic", "; ".join(hard)
    first = judge(case, result["output"], CHEAP)
    if first["verdict"] == "pass" and first["confidence"] == "high":
        return True, CHEAP, first["reason"]
    second = judge(case, result["output"], STRICT)
    return second["verdict"] == "pass", STRICT, second["reason"]

Damit tauschen Sie einen Teil der Bewertungsgenauigkeit gegen geringere Kosten. Messen Sie diesen Kompromiss, statt ihn vorauszusetzen. Bewerten Sie einmal pro Monat den gesamten Satz zusätzlich mit dem strengen Bewertungsmodell und vergleichen Sie die beiden Spalten. Wenn die Ergebnisse bei mehr als einer Handvoll Fälle voneinander abweichen, ist Ihre Rubrik für das kleinere Modell zu unpräzise. Überarbeiten Sie dann die Rubrik. Die Kostenkontrolle für den Agenten selbst ist eine separate Aufgabe. Sie wird unter Kostenkontrolle für einen AI-Agenten auf einem VPS behandelt.

Pass-Rate im Zeitverlauf in einem System verfolgen, das Ihnen gehört

Eine Pass-Rate, die Sie keinem Commit zuordnen können, ist nur ein Gefühl. Speichern Sie pro Fall und Lauf eine Zeile. Commit und Modell müssen in dieser Zeile enthalten sein.

CREATE TABLE IF NOT EXISTS results (
  run_id      TEXT NOT NULL,
  ran_at      TEXT NOT NULL,
  git_sha     TEXT NOT NULL,
  agent_model TEXT NOT NULL,
  case_id     TEXT NOT NULL,
  passed      INTEGER NOT NULL,
  graded_by   TEXT NOT NULL,
  reason      TEXT
);

SELECT run_id, git_sha, agent_model,
       count(*) AS cases,
       round(100.0 * sum(passed) / count(*), 1) AS pass_pct
FROM results
GROUP BY run_id
ORDER BY ran_at DESC
LIMIT 10;

Laden Sie das Schema mit sqlite3 evals/results.db < evals/schema.sql und lesen Sie anschließend den Trend mit sqlite3 -box evals/results.db < evals/passrate.sql aus. Ein Jahr mit täglichen Läufen über 60 Fälle ergibt etwa 22,000 Zeilen. Der Speicher wird dadurch nie zu einem eigenen Projekt. SQLite in der Produktion auf einem VPS betreiben behandelt die Einstellungen, die relevant werden, wenn diese Datei zwischen mehreren Rechnern geteilt wird.

Der Runner gibt dieselben Informationen für eine Person aus:

run 2026-08-05T09:14:22Z  sha 4f1c9ab  model claude-sonnet-5  58/60 pass (96.7%)
FAIL refund-double-charge  deterministic: tool not called: create_refund
FAIL pto-policy-question   judge(opus): reply gives no dollar amount

Führen Sie die Testsuite für Änderungen aus, die einen Agenten beschädigen können. Dazu gehören Änderungen an Prompts, Modellen und Tools, nicht jeder Commit irgendwo im Repository. Ein pre-push-Hook deckt die schnelle Teilmenge ab:

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
python3 evals/run.py --set smoke || exit 1
EOF
chmod +x .git/hooks/pre-push

Vollständige Läufe dauern länger und gehören in einen Zeitplan. Ein nächtlicher systemd-Service und -Timer auf dem VPS führt die gesamte Menge gegen den bereitgestellten Prompt aus. Dadurch werden auch Änderungen erkannt, die außerhalb Ihres Repositorys eintreffen, beispielsweise wenn sich das Verhalten eines gehosteten Tools ändert.

Menschliche Prüfung durch Stichproben statt vollständiger Prüfung

Der Judge wird anhand menschlicher Bewertungen kalibriert. Daher muss jemand diese Bewertungen erstellen. Prüfen Sie jede Woche eine Stichprobe: jeden Fall, bei dem der Judge versagt hat, sowie zehn zufällig ausgewählte Fälle mit bestandener Prüfung. Die zufällig ausgewählten Fälle sind besonders wichtig. Ein Judge, der unbemerkt fehlerhafte Antworten durchwinkt, wirkt auf jedem Dashboard, das auf seinen eigenen Bewertungen basiert, fehlerfrei.

Fünfzehn Fälle mit jeweils drei Minuten Aufwand entsprechen 45 Minuten pro Woche. Dafür erhalten Sie Korrekturen an der Bewertungsrichtlinie, wenn Sie und der Judge unterschiedlicher Meinung sind, sowie neue Fälle für Fehlertypen, die bisher niemand berücksichtigt hatte. Schreiben Sie die menschliche Bewertung in dieselbe Tabelle. Setzen Sie graded_by auf human. Dadurch wird die Übereinstimmung zwischen Judge und Mensch zu einer Abfrage statt zu einer Erinnerung.

Was im Eval-Harness selbst fehlschlägt

anthropic.RateLimitError beim ersten vollständigen Lauf. Sechzig Fälle, die gleichzeitig gestartet werden, überschreiten das Request- oder Token-Limit Ihres Tarifs. Begrenzen Sie die Parallelität auf vier Worker und verlagern Sie den nächtlichen Lauf auf die Batch API.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) vom Judge. Das Modell hat eine Prosaausgabe zurückgegeben oder sein JSON in einen Codeblock eingeschlossen. Wiederholen Sie den Lauf einmal und erfassen Sie den Fall anschließend als Fehler. Lassen Sie einen Parse-Fehler niemals als bestanden zählen. Andernfalls steigt eine Suite, die Fehler in bestandene Fälle umwandelt, auf 100 %, während der Agent schlechter wird.

Flaky-Fälle. Dieselbe Eingabe ist in einem Lauf erfolgreich und schlägt im nächsten fehl, weil der Agent seine Ausgabe sampelt. Führen Sie den Flaky-Fall dreimal aus und erfassen Sie den Anteil, statt den Fall zu löschen. Ein Fall, der in zwei von drei Läufen erfolgreich ist, weist auf ein echtes Robustheitsproblem hin. Ein Kunde wird es finden.

Veralteter Golden Set. Jemand bearbeitet eine erwartete Antwort, damit die Suite grün wird. Prüfen Sie Diffs an evals/cases.jsonl ebenso sorgfältig wie Diffs am Agenten. Diese Datei ist Ihre schriftlich festgehaltene Definition von korrekt.

Eine Suite, die niemals fehlschlägt. Eine Erfolgsrate, die einen Monat lang bei 100 % bleibt, bedeutet, dass das Set das Produkt nicht mehr abbildet. Ziehen Sie zehn aktuelle Traces heran, suchen Sie die Fälle, die der Agent schlecht verarbeitet hat, und fügen Sie sie hinzu. Lassen Sie anschließend absichtlich etwas fehlschlagen und bestätigen Sie, dass der Lauf rot wird. Das ist der Prüfschritt Mutation Testing gilt für eine Testsuite und die einzige Möglichkeit festzustellen, ob Ihr Set noch aussagekräftige Fehler erkennt.

FAQ

Wie viele Fälle benötigt ein Eval-Set für einen KI-Agenten?

Beginnen Sie mit 40 bis 80 Fällen und erweitern Sie das Set anhand realer Fehler. Bei weniger als etwa 20 Fällen verändert bereits ein einzelnes instabiles Ergebnis die Erfolgsquote um 5 Prozentpunkte. Dadurch verliert diese Zahl an Aussagekraft. Bei einigen hundert Fällen verursacht jeder Durchlauf erhebliche Kosten und benötigt viel Zeit, während zusätzliche Fälle nur noch wenig mehr abdecken. Entscheidend ist nicht die Anzahl der Fälle. Entscheidend ist der Anteil der bekannten Fehlertypen aus der Produktion, die mindestens einmal im Set vorkommen.

Kann ich einem LLM-Judge zur Bewertung meines Agenten vertrauen?

Erst, nachdem Sie ihn anhand Ihrer eigenen Bewertungen gemessen haben. Bewerten Sie 30 Fälle manuell und vergleichen Sie den Judge mit diesen Bewertungen, sobald Sie das Judge-Modell oder den Judge-Prompt ändern. Judges zeigen eine Längenverzerrung: Ausführlichere Antworten bestehen häufiger. Außerdem zeigen sie eine Selbstpräferenz: Ausgaben aus der eigenen Modellfamilie werden wohlwollender bewertet. Beides lässt sich testen. Ergänzen Sie eine fehlgeschlagene Antwort um Fülltext und bewerten Sie sie erneut. Oder lassen Sie dieselben Antworten von einem Judge aus einer anderen Modellfamilie bewerten. Wenn der Judge bei mehr als einem von zehn Fällen von Ihren Bewertungen abweicht, ist die Bewertungsrichtlinie zu ungenau für den praktischen Einsatz.

Welches Modell sollte die Evals bewerten?

Bewerten Sie zunächst kostengünstig und eskalieren Sie bei Bedarf. Deterministische Assertions verursachen keine Kosten und werden daher bei jedem Fall zuerst ausgeführt. Ein kleines Modell bearbeitet eindeutige Erfolgsfälle. Nur Fehlversuche und Bewertungen mit geringer Konfidenz werden an ein Frontier-Modell weitergeleitet. Zu den Listenpreisen im August 2026 kostet die Bewertung von 1,000 Fällen mit Claude Haiku 4.5 etwa 1.80 US-Dollar und mit Claude Opus 5 etwa 9.00 US-Dollar. Da Eval-Durchläufe asynchron sind, halbiert die Batch API beide Beträge.

Ersetzen Evals das Monitoring in der Produktion?

Nein, denn sie beantworten unterschiedliche Fragen. Eine Eval-Suite zeigt, ob eine geplante Änderung eine feste Gruppe von Fällen verbessert oder verschlechtert. Tracing und Monitoring zeigen, welche Anfragen reale Benutzer aktuell stellen, einschließlich Eingaben, die von keinem Fall abgedeckt werden. Beide Verfahren ergänzen sich: Traces liefern neue Fälle, und die Eval-Suite zeigt, ob Ihre Korrektur tatsächlich funktioniert hat.