Self-Hosted-Evaluierungen für KI-Agenten aufbauen

Was Self-Hosted-Evaluierungen für KI-Agenten sind

Self-Hosted-Evaluierungen für KI-Agenten bestehen aus vier Bestandteilen, 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 Ergebnistabelle, die Sie abfragen können. Kein Bestandteil davon benötigt einen Anbieter. Der gesamte Ablauf umfasst nur wenige 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 dies erfasste. Eine Evaluierungsschleife macht aus „Es wirkt jetzt schlechter“ die Aussage „Die Erfolgsquote ist bei Commit 4f1c9ab von 58 von 60 auf 51 von 60 gesunken“.

Die Schleife umfasst vier Schritte. Dieser Leitfaden behandelt jeden Schritt in einem eigenen Abschnitt: Erfassen Sie reale Traces, übernehmen Sie die interessanten Traces als Fälle, bewerten Sie jeden Fall bei jeder Änderung und speichern Sie die Erfolgsquote neben dem Commit, durch den sie entstanden ist. Dieselbe Schleife funktioniert unabhängig davon, wofür Sie den Agenten einsetzen. Die empfehlenswerten Self-Hosted-Agent-Frameworks unterscheiden sich hauptsächlich darin, wie viele Informationen aus dem Trace sie Ihnen automatisch bereitstellen.

Warum der Agent in der zweiten Woche ausfällt

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

Die häufigste Ursache ist eine Änderung am Prompt. 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 Alarm ausgelöst.

Die zweite Ursache ist das Modell. Protokollieren Sie bei jedem Lauf die exakte Modellzeichenfolge, die Sie gesendet haben, claude-haiku-4-5-20251001 statt einer Kurzbezeichnung, die Sie sich nur merken. Denn eine sinkende Erfolgsquote an dem Tag, an dem Sie das Modell gewechselt haben, lässt sich nur diagnostizieren, wenn das Modell in der jeweiligen Zeile steht.

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

Erstellen Sie den Golden Set aus bereits erfassten Traces

Erfinden Sie keine Evaluierungsfälle. Übernehmen Sie sie aus dem Datenverkehr. Wenn Sie bereits Self-Hosted-Langfuse-Tracing für Ihren Agenten betreiben, wird jede Anfrage mit ihrer Eingabe, den Tool-Aufrufen und ihrer Ausgabe gespeichert. Das ist genau das Rohmaterial, das ein Fall benötigt.

Exportieren Sie über die öffentliche API ein Zeitfenster mit Root-Beobachtungen. Die API verwendet die Basic-Authentifizierung. Der öffentliche Schlüssel ist der Benutzername und der geheime Schlüssel 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, statt die erwarteten Feldnamen zu verwenden. 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."}

Diese fünf Regeln sorgen dafür, dass sich der Satz ausführen lässt:

• 40 bis 80 Fälle reichen für den Anfang. Bei weniger als 20 Fällen verändert ein einziger fehlerhafter Fall die Erfolgsrate um 5 Punkte. Eine Zahl, die ohne erkennbaren Grund schwankt, wird dann ignoriert.
• Jeder in der Produktion behobene Fehler wird am Tag seiner Behebung zu einem Fall. Diese Gewohnheit sorgt dafür, dass der Satz 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 ändert sich nie, weil die ID den Vergleich zwischen dem heutigen Lauf und dem Lauf des letzten Monats ermöglicht.
• Entfernen Sie vertrauliche Daten, bevor Sie die Datei committen. Die Datei wird in Git übernommen. Entfernen Sie daher Kundennamen und alle Bestellnummern, die nicht Ihnen gehören.

Prüfen Sie zunächst deterministisch, weil diese Prüfungen kostenlos sind

Alles mit einer eindeutig richtigen Antwort erhält eine einfache Assertion. Es wird kein Modellaufruf benötigt, es entstehen keine Kosten und es gibt keine Mehrdeutigkeit. Deterministische Prüfungen erkennen strukturelle Regressionen. Diese Regressionen beeinträchtigen die Systeme rund um Ihren Agenten: Das JSON lässt sich nicht parsen, das Tool wurde nie aufgerufen, die verbotene Formulierung ist wieder vorhanden oder die Antwort enthält keine Quelle.

Nur eine Funktion muss Ihren Agenten kennen. Alles andere im Harness ist 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 eine Regression, auch wenn die endgültige Antwort korrekt ist, weil jeder Aufruf Kosten verursacht.

LLM als Bewertungsinstanz und die vier Fehlerarten

Was die Assertions übersteht, braucht einen Grader, der Inhalte liest. Ein LLM-Judge 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 eine Antwort tatsächlich auf die Frage des Benutzers eingeht.

Vier Regeln machen einen Judge brauchbar:

• Binäres Urteil, niemals eine Bewertung von 1 bis 10. Eine Skala liefert für fast alles die Werte 7 und 8. Die Zahl verändert sich dadurch nie, und Sie lernen nichts daraus.
• Pro Aufruf genau ein Kriterium. Fragen Sie entweder nach dem Erstattungsbetrag oder nach dem Ton, nicht nach beidem gleichzeitig.
• Geben Sie dem Judge die erwartete Antwort, wenn für den Fall eine vorhanden ist. 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 Fehlerarten. Jede davon können Sie noch heute Nachmittag testen. Das ist wichtig, weil ein ungeprüfter Judge präzise wirkende Zahlen erzeugt, die keine Aussagekraft haben.

Längenverzerrung. Längere Antworten werden häufiger akzeptiert. Testen Sie das: Nehmen Sie zehn Antworten, die der Judge abgelehnt hat, und ergänzen Sie jede um zwei Absätze mit überzeugend formulierten Füllsätzen, die keine neue Tatsache enthalten. Bewerten Sie sie anschließend erneut. Wenn ein Urteil dadurch auf akzeptiert wechselt, liegt eine Längenverzerrung vor. Dann müssen Sie die Bewertungsrichtlinie überarbeiten.

Selbstpräferenz. Ein Judge bewertet Ausgaben aus seiner eigenen Modellfamilie häufig wohlwollender als Ausgaben aus einer anderen Modellfamilie. Testen Sie das: Bewerten Sie dieselben 30 Antworten mit Judges 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 Judge zum Vergleich zweier Antworten A und B verwenden, vertauschen Sie die Reihenfolge und führen Sie den Test erneut aus. Wenn sich das Urteil durch den Tausch ändert, ist der paarweise Vergleich für diese Bewertungsrichtlinie noch nicht zuverlässig.

Abweichung der Bewertungsrichtlinie. Vage Kriterien erzeugen zustimmungsbereite Judges. Bei „Ist die Antwort hilfreich?“ wird fast alles akzeptiert. Bei „Nennt die Antwort den Erstattungsbetrag in Dollar?“ wird nur das akzeptiert, was Sie tatsächlich prüfen wollten. Überarbeiten Sie jedes Kriterium, bis es die zu prüfende Tatsache eindeutig benennt.

Eine Schutzmaßnahme deckt alle vier Fehlerarten ab. Halten Sie 30 Fälle vor, die Sie manuell bewertet haben, und vergleichen Sie den Judge bei jeder Änderung des Judge-Modells oder des Judge-Prompts mit Ihren Bewertungen. Wenn er in mehr als einem von zehn Fällen von Ihnen abweicht, überarbeiten Sie die Bewertungsrichtlinie, bevor Sie einer von ihm erzeugten Akzeptanzrate vertrauen. Der Judge ist Code. Deshalb wird er wie Code versioniert und geprüft.

Günstiges Modell bewerten, 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 prüft. Ordnen Sie die Bewerter 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 setzen pro Bewertungsaufruf etwa 1,200 Eingabetokens und 120 Ausgabetokens voraus. 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. Bei vielen Aufrufen summiert er sich jedoch. Ein Datensatz mit 60 Fällen, der bei jedem Commit bewertet wird, verursacht bei 40 Commits pro Woche 2,400 Bewertungsaufrufe pro Woche. Der nächtliche Lauf ist dabei noch nicht berücksichtigt.

Für Evaluierungen lassen sich zwei Rabatte direkt nutzen. Sie können kombiniert werden. Evaluierungsläufe sind nicht interaktiv. Die Batch API halbiert daher die Preise für Eingaben und Ausgaben, wenn Sie die asynchrone Bereitstellung akzeptieren. Das ist die erste Zeile des Diagramms. Das Rubric und die Anweisungen sind bei jedem Aufruf bytegenau identisch. Daher eignet sich Prompt Caching: Ein Cache-Lesevorgang kostet ein Zehntel des normalen Eingabepreises. Das Schreiben in den Cache für fünf Minuten kostet das 1.25-Fache des normalen Eingabepreises. Der Cache amortisiert sich daher nach einem einzigen Treffer. Dies sind die Listenpreise von Anthropic mit Stand August 2026. Für Sonnet 5 gilt bis zum 31 August 2026 ein Einführungspreis. Danach steigt der dritte Balken.

Die Reihenfolge:

• Deterministische Prüfungen für jeden Fall. Es fallen keine API-Kosten an.
• Ein Bewerter mit kleinem Modell für die Fälle, die diese Prüfungen bestanden haben.
• Ein Frontier-Bewerter nur dann, wenn der Bewerter mit kleinem Modell einen Fehler feststellt oder mit geringer Zuverlässigkeit eine erfolgreiche Bewertung abgibt.
• 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 im Monat zusätzlich den gesamten Datensatz mit dem strengen Bewerter und vergleichen Sie die beiden Spalten. Wenn die Ergebnisse bei mehr als einer Handvoll Fällen voneinander abweichen, ist Ihr Rubric für das kleine Modell zu ungenau. Dann müssen Sie das Rubric anpassen. Die Ausgaben des Agenten selbst zu begrenzen, ist eine separate Aufgabe. Sie wird unter Kostenkontrolle für einen AI-Agenten auf einem VPS behandelt.

Pass-Rate im Zeitverlauf in einem eigenen System erfassen

Eine Pass-Rate, die Sie keinem Commit zuordnen können, ist nur ein Gefühl. Speichern Sie pro Fall und Durchlauf eine Zeile. Der Commit und das Modell stehen in derselben Zeile.

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 Durchläufen über 60 Fälle umfasst etwa 22,000 Zeilen. Der Speicher wird dadurch nie zu einem eigenen Projekt. SQLite in einer Produktionsumgebung auf einem VPS ausführen behandelt die Einstellungen, die relevant werden, wenn diese Datei zwischen mehreren Rechnern gemeinsam genutzt 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 Tests für Änderungen aus, die einen Agent beeinträchtigen 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 Durchläufe dauern länger und gehören in einen Zeitplan. Ein nächtlicher systemd-Dienst und -Timer auf dem VPS führt die gesamte Testsuite mit dem bereitgestellten Prompt aus. Dadurch werden auch Änderungen erkannt, die außerhalb Ihres Repositorys eintreffen, beispielsweise bei einem gehosteten Tool, dessen Verhalten sich geändert hat.

Menschliche Prüfung, stichprobenartig statt vollständig

Der Judge wird anhand menschlicher Bewertungen kalibriert. Diese Bewertungen muss also jemand erstellen. Prüfen Sie jede Woche eine Stichprobe: jeden Fall, bei dem der Judge versagt hat, sowie zehn zufällig ausgewählte bestandene Fälle. Die zufällig ausgewählten bestandenen Fälle sind dabei besonders wichtig. Ein Judge, der unbemerkt fehlerhafte Antworten akzeptiert, wirkt auf jedem Dashboard perfekt, das auf seinen eigenen Bewertungen basiert.

Fünfzehn Fälle mit jeweils drei Minuten Aufwand entsprechen 45 Minuten pro Woche. Dafür erhalten Sie Korrekturen am Bewertungsmaßstab, wenn Ihre Einschätzung und die des Judges voneinander abweichen, sowie neue Fälle für Fehlertypen, die bisher niemand berücksichtigt hatte. Schreiben Sie die menschliche Bewertung in dieselbe Tabelle, wobei graded_by auf human gesetzt wird. Dadurch wird die Übereinstimmung zwischen Judge und Mensch zu einer Abfrage statt zu einer Erinnerung.

Was im Evaluierungsharness selbst fehlschlägt

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

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) vom Judge. Das Modell hat eine Erklärung ausgegeben oder sein JSON in einen Codeblock eingeschlossen. Wiederholen Sie den Versuch einmal und erfassen Sie den Fall anschließend als Fehler. Lassen Sie einen Analysefehler niemals als bestanden zählen. Eine Suite, die Fehler in bestandene Fälle umwandelt, nähert sich 100 %, während der Agent schlechter wird.

Flaky-Fälle. Dieselbe Eingabe besteht in einem Durchlauf und schlägt im nächsten fehl, weil der Agent seine Ausgabe per Sampling erzeugt. Führen Sie den Flaky-Fall dreimal aus und erfassen Sie den Anteil, anstatt den Fall zu löschen. Ein Fall, der zwei von drei Durchläufen besteht, weist auf ein echtes Robustheitsproblem hin, das auch ein Kunde finden wird.

Veraltender Golden Set. Jemand ändert eine erwartete Antwort, damit die Suite wieder grün wird. Prüfen Sie Diffs an evals/cases.jsonl ebenso sorgfältig wie Diffs am Agenten, weil diese Datei Ihre schriftliche Definition von korrekt enthält.

Eine Suite, die niemals fehlschlägt. Eine Erfolgsrate von 100 %, die einen Monat lang unverändert bleibt, bedeutet, dass das Set das Produkt nicht mehr abbildet. Wählen Sie zehn aktuelle Traces aus, suchen Sie die Fälle, die der Agent schlecht verarbeitet hat, und fügen Sie sie hinzu.

FAQ

Wie viele Fälle braucht 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 schwankendes Ergebnis die Erfolgsquote um 5 Prozentpunkte. Dadurch verliert die Kennzahl an Aussagekraft. Bei einigen hundert Fällen verursacht jeder Durchlauf erhebliche Kosten und benötigt viel Zeit, während ein zusätzlicher Fall nur noch wenig Abdeckung bringt. Entscheidend ist nicht die Anzahl der Fälle. Entscheidend ist der Anteil der bekannten Fehlerarten aus der Produktion, die mindestens einmal im Set vorkommen.

Kann ich darauf vertrauen, dass ein LLM-Judge meinen Agenten bewertet?

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 einen Längen-Bias: Ausführlichere Antworten bestehen häufiger. Außerdem gibt es eine Präferenz für das eigene Modell, sodass Ausgaben aus derselben Modellfamilie milder bewertet werden. Beides lässt sich testen: Ergänzen Sie eine fehlgeschlagene Antwort um Fülltext und lassen Sie sie erneut bewerten, oder bewerten Sie dieselben Antworten mit einem Judge aus einer anderen Modellfamilie. 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 stufen Sie bei Bedarf auf. Deterministische Assertions kosten nichts und werden daher bei jedem Fall zuerst ausgeführt. Ein kleines Modell bearbeitet eindeutige erfolgreiche Ergebnisse. Nur fehlgeschlagene Fälle und Ergebnisse mit geringer Konfidenz werden an ein Frontier-Modell weitergeleitet. Zu den Listenpreisen im August 2026 kostet die Bewertung von 1,000 Fällen etwa 1.80 US-Dollar mit Claude Haiku 4.5 und etwa 9.00 mit Claude Opus 5. Da Eval-Durchläufe asynchron ausgeführt werden, 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 bevorstehende Änderung einen festen Satz von Fällen verbessert oder verschlechtert. Tracing und Monitoring zeigen, worauf reale Benutzer aktuell stoßen, einschließlich Eingaben, die durch keinen Fall abgedeckt sind. Beide ergänzen sich: Traces liefern neue Fälle, und die Eval-Suite zeigt, ob Ihre Korrektur tatsächlich funktioniert hat.