HHostingByteSoftware
Ctrl K
ComunidadGuías…

docs/evals.de.md

Rama main · réplica de lectura del repositorio original.

Archivo original ↗Preguntar a KiBot
---
source_sha: "b01337524a1f"
title: "Eval-Runs"
description: "Ein Eval-Run beantwortet jeden Fall eines Datasets mit einer Agent-Version oder ihrem Entwurf, bewertet jede Antwort und vergleicht das Ergebnis mit einer Baseline."
---

# Eval-Runs { #eval-runs }

Ein **Eval-Run** lässt einen Agent jeden Fall einer Version eines
[Datasets](datasets.md) beantworten, bewertet jede Antwort so, wie das
[Scoring](datasets.md#scoring) des Datasets es vorgibt, und hält fest, was
passiert ist. Er beantwortet die Frage, die jemand beim Bearbeiten eines Agents
wirklich hat: Hat diese Änderung den Agent besser gemacht, schlechter oder
keines von beidem - und was hat es gekostet?

Ein Run besteht aus vier Entscheidungen: der **Agent** und was davon läuft
(eine veröffentlichte Version oder der Entwurf in seinem aktuellen Stand), die
**Dataset-Version**, die **Umgebung**, deren Testverbindungen die Fälle nutzen,
und optional **mehrere Modelle** nebeneinander. Im selben Run kann außerdem
eine **Baseline** laufen - eine frühere Version -, damit beide Seiten am selben
Tag auf denselben Provider treffen.

## In der Konsole { #in-the-console }

Der Tab **Evals** eines Agents zeigt ein kompaktes Diagramm über der Run-Historie, sobald Messergebnisse vorliegen. Das Diagramm bleibt sichtbar. Jede Zeile zeigt verglichene Versionen, Status, Urteil, Modell, Bestehensquote und bestandene Fälle im Verhältnis zur Gesamtzahl. Das Diagramm zeigt die
Bestehensquote Run für Run, der älteste links, eine Linie pro Dataset, jede mit
eigener Strichart. Ein Punkt ist rot, wo der Run Fälle verschlechtert hat, grün,
wo er sie behoben hat, bernsteinfarben, wo beides, und hohl für einen Entwurf; der
Hover sagt, was lief, wogegen und wann, und ein Klick öffnet den Run.

Die Achse zeigt Uhrzeiten, wenn die Historie innerhalb eines Tages liegt, auch eines vergangenen. Über mehrere Tage zeigt sie Daten für ältere Runs und Uhrzeiten für heutige, ohne gleiche Beschriftungen zu wiederholen. Der Tooltip enthält das vollständige Startdatum mit Uhrzeit. Ab mehr als 10 Runs zeigt ein
Schalter über dem Diagramm die letzten 10, die letzten 30 oder alle Runs; er
öffnet mit den letzten 10, und die Wahl bleibt in der Adresse der Seite, sodass
Zurück und ein Link sie behalten.

Die Tabelle zeigt die Runs mit den neuesten zuerst, jeder mit dem, was gegen was
getestet wurde, seinem Urteil (Verschlechtert 2, Insgesamt schlechter ·
4 verschlechtert, Erstes Ergebnis, Läuft) und der Bestehensquote jedes Modells, mit der Quote der ersten
Antworten beim Darüberfahren.

**Evals starten** (Run evals) öffnet den Startdialog mit der naheliegenden
Antwort: der Entwurf gegen die Live-Version, wenn sich der Entwurf von ihr
unterscheidet, die Live-Version allein, wenn nicht, und der Entwurf allein bei
einem Agent, den niemand veröffentlicht hat. Das Dataset, auf dem der Agent
zuletzt gemessen wurde - oder das einzige, das es gibt -, ist bereits
ausgewählt; Umgebung, Aufzeichnungen und Wiederholungen liegen unter
**Erweitert** (Advanced). Die Kosten werden berechnet, sobald die Felder
feststehen, und sagen, was die Antworten bewertet und was die Budgets des
Agents und der Organisation danach behalten; der Run startet erst über den
Button, der den Betrag nennt. **Entwurf weicht von vN ab**
(Draft differs from vN) auf der Seite des Agents - vN ist die zuletzt
veröffentlichte Version, und wenn die Wächter der Produktion sie auf einer
älteren halten, sagt ein zweites Badge, auf welcher, etwa „Produktion auf v1
(wartet auf Evals)“ - trägt einen Button **Entwurf testen** (Test draft), der
denselben Dialog öffnet. Der Veröffentlichungsdialog sagt, was der letzte Run
des Entwurfs ergeben hat - eine
[Prüfung der Vorschläge des Assistenten](authoring.md#check-with-evals) zählt,
sobald sie angenommen sind -, oder dass er seit seiner letzten Änderung nicht
getestet wurde, oder dass sein Test veraltet ist, ohne die Veröffentlichung
aufzuhalten.

Die Seite eines Runs öffnet mit seinem Urteil in wenigen Sätzen - die Fälle,
die der Kandidat jedes Mal verschlechtert oder behebt, wenn er sie gestellt
bekommt, einer davon zitiert mit der Zahl der Versuche, die es wiederholt
haben, ob er insgesamt besser oder schlechter ist, wenn die bestätigten
Änderungen das entscheiden können, und die Bestehensquote vorher und nachher -
und mit dem, was als Nächstes zu tun ist: sehen, was sich zwischen den beiden
Versionen geändert hat (History öffnet auf diesem Vergleich, gegen den
getesteten Spec statt den jetzigen Entwurf), die verschlechterten Fälle zeigen,
zurück zum Tab Bauen gehen oder den Entwurf veröffentlichen.

Publish ist nur dann die Hauptaktion, wenn keine Regression bestätigt wurde und
kein Fall des Kandidaten unbeantwortet oder unbewertet blieb, und der Run eines
seitdem geänderten Entwurfs bietet stattdessen **Erneut testen** (Test again)
an. Solange der Run
antwortet, sagt die Seite, wie viele erste Antworten vorliegen, und der
Vergleich wartet auf beide Seiten. Antworten, die der Bewerter nicht bewerten
konnte, sagen, warum, und zählen weder als bestanden noch als nicht bestanden,
und **Erneut bewerten** (Grade again) im Kopfbereich bewertet sie erneut, ohne den Agent zu
fragen, für jeden, der das Dataset laufen lassen darf.

Unter dem Urteil stehen die Seiten nebeneinander, wie die beiden abschneiden,
und die Fälle - jede Zeile mit einem Punkt für bestanden oder nicht bestanden
pro Seite, gefiltert nach Ergebnis oder Tag, jeder Fall mit dem, was er
erwartet, und den Antworten, Aufrufen und Bewerterbegründungen jeder Seite. Ein
gewählter Tag beschränkt die Seiten, die Änderungen und die Fälle auf ihn; das
Urteil gilt weiter für alle Fälle.

Sobald seine Wiederholungen vorliegen, schickt ein Run in die
[Prüfwarteschlange](datasets.md#review) des Datasets, wofür er einstehen
kann - jede bestätigte Regression und jede Antwort, an deren Bewertung sein
Bewerter gescheitert ist, eine pro Fall und Agent - und sagt, wie viele
(`routed_to_review`).
Eine [Prüfung des Vorschlags des Assistenten](authoring.md#check-with-evals)
schickt von sich aus nichts, da nichts angenommen wurde. Ein übersprungener
Bewerter schickt nichts: Seine Antworten warten auf der Seite des Runs auf
**Erneut bewerten** (Grade again). Wird das Senden abgelehnt, endet der Run
trotzdem, und seine Seite sagt, warum (`routing_error`).

**Nicht bestandene Fälle zur Prüfung senden** (Send failed cases to review)
schickt die übrigen nicht bestandenen Antworten einer Seite, für jeden, der das Dataset bearbeiten darf, und ein Fall, dessen
Bewertung eine Person überstimmt hat, wird als korrigiert markiert.

In beiden Fällen nimmt eine Antwort den Platz einer älteren, noch wartenden
Antwort desselben Falls und Agents ein, die die Warteschlange unentschieden
verlässt - ein Run nennt deren Zahl als `routed_replacing` - und eine Antwort,
die älter ist als die wartende, wird nicht gesendet. Die Antwort eines anderen
Agents auf den Fall wartet daneben.

Unter **Ergebnisse → Testläufe** zeigt ein Dataset alle gemessenen Agents in einem gemeinsamen Diagramm und einer Run-Tabelle. **Evals starten** öffnet den Dialog auf diesem Dataset und fragt nach dem Agent. Wenn alle Antworten mit demselben Konfigurationsfehler scheitern, steht **Start fehlgeschlagen** statt einer Bestehensquote; solche Runs fehlen im Qualitätsverlauf.

Die Karte **Eval-Runs** (Eval runs) im Dashboard listet die neuesten Runs der
Organisation mit ihrem Agent und ihrem Urteil. Die Fälle eines Evals und die
Bewertung durch den Bewerter bleiben aus jeder anderen Dashboard-Zahl heraus.
[Aktivität](console.md#activity) führt sie mit allen anderen Runs auf,
beschriftet mit **Eval** und **Bewerter**, und ihr Filter **Herkunft** grenzt die
Liste auf sie ein.

Die Liste in **Aktivität** zeigt, was jedem Run gestellt wurde - seine erste
Nutzernachricht oder die Frage des Eval-Falls und beim Run des Bewerters das,
was er bewertet hat -, damit sich ein Run wiederfinden und zu einem Fall machen
lässt. Ein Eval-Fall öffnet dort seinen Eval-Run auf diesem Fall, und
**Sehen, was das Modell sah** (See what the model saw) eines Falls öffnet, was
sein Modell bekommen hat.

**Alle ansehen** auf der Karte öffnet **Eval-Runs** unter `/evals`: jeden
Eval-Run, den Sie sehen dürfen, über alle Agents, der neueste zuerst,
seitenweise. Gibt es noch keinen, sagt die Seite, was ein Eval ist und wo man
einen startet.

## Einen Run starten { #starting-a-run }

Der Start besteht aus zwei Aufrufen, damit nichts ausgegeben wird, bevor jemand
gesehen hat, was es kosten wird.

```text
POST /api/v1/agents/{agent_id}/eval-runs/estimate   the estimate, nothing written
POST /api/v1/agents/{agent_id}/eval-runs            the same body; starts the run
```

Der Body nennt das Dataset (`dataset_id`, `dataset_version`), den Kandidaten
(`candidate: "version"` mit optionaler `version` oder `candidate: "draft"`),
die `environment_id`, die zu vergleichenden `model_profile_ids` und
`paired_baseline`. Die Schätzung ist der durchschnittliche Preis eines Runs des
Agents auf jedem Modell, gemessen an seinen letzten abgeschlossenen Runs, mal
die Zahl der Fälle, plus ein Aufruf des Bewerters pro Fall, wenn ein Bewerter
das Dataset bewertet .

Die Schätzung berücksichtigt modellgestützte Bewertung, wenn das Dataset sie verlangt, zum unter Bewertung gewählten Modellpreis. Kein Organisationsschalter deaktiviert diesen Bewerter.

Ein Agent ohne Historie auf einem Modell wird als typischer Fall geschätzt -
`EVAL_FALLBACK_INPUT_TOKENS` hinein, `EVAL_FALLBACK_OUTPUT_TOKENS` heraus - zum
eigenen Preis des Modells, oder mit `EVAL_FALLBACK_CASE_COST_USD` bei einem
Modell ohne bekannten Preis, und die Schätzung sagt, dass es eine grobe Annahme
ist (`basis: "fallback"`). Ein Bewerter ohne Historie wird genauso bepreist, auf
dem Modell, das sein veröffentlichter Spec nennt; die Schätzung warnt, wenn das
das getestete Modell ist, und die Seite eines Runs, wenn es das war. Die Kosten
der Baseline gehören zur Summe, außer eine aktuelle passende Baseline wird
wiederverwendet - dann kosten ihre ersten Antworten nichts, und die Schätzung
nennt den Run, aus dem sie stammen.

### Das verbleibende Budget { #the-budget-it-leaves }

Ein Eval nutzt die bestehenden Monatsbudgets des Agents und der Organisation.
Die Schätzung zeigt die verbleibenden Beträge nach dem vollständigen erwarteten
Aufwand als `agent_after_usd` und `org_after_usd`. Der Start wird mit `402`
abgelehnt, wenn erster Durchlauf plus `rerun_ceiling_usd` eines der Budgets
übersteigt. Die Obergrenze enthält alle bestätigenden Versuche bei geänderten
Ergebnissen, den Richter und Wiederholungen der Baseline, auch bei einer
wiederverwendeten Baseline. Tatsächliche Kosten können abweichen. Jede
Modellanfrage unterliegt weiterhin den Monatsbudgets; ein erschöpftes Budget
beendet den Run als `budget_exceeded`.

Auch die geschätzte Ausgabengrenze einer Suite enthält Wiederholungen und bei
Paaren beide Seiten. Die erste Veröffentlichungsschätzung enthält die bestehende
Version als Baseline der nächsten Veröffentlichung, selbst bei nur einer Version.
Diese Grenze entscheidet nur über den Start; sie stoppt keinen laufenden Test.
Jeder positive Kosten- oder Latenzanstieg von einer Baseline von null überschreitet
jede Prozentgrenze.

### Was abgelehnt wird { #what-is-refused }

Ein Run, der niemandem etwas sagen könnte, wird abgelehnt, bevor er geschätzt
wird:

- eine Dataset-Version ohne Fälle;
- Bewertung ohne erforderlichen Scorer, der einen Fall entscheiden kann: ergänze eine Prüfung, einen erwarteten Werkzeugaufruf oder Bewertungskriterien;
- ein Agent, der nie veröffentlicht wurde, für den eine Version verlangt wird -
  starte stattdessen seinen Entwurf;
- eine Baseline für eine erste Version, vor der es nichts gibt.

Eine Version, in der nur einige Fälle nichts haben, das sie bewertet, läuft
trotzdem, und die Schätzung zählt sie vorher (`ungraded_cases`): der
Startdialog, ein Check von Vorschlägen und der Dialog einer Suite sagen „1 Fall
has nothing to grade it. The result will be inconclusive.“

Eine unbekannte Umgebung liefert 404. Gleichzeitiges Erstellen oder Umbenennen von Suiten mit demselben Namen liefert 409 statt eines Serverfehlers. Ein lesbares Dataset ohne Bearbeitungs- oder Ausführungsrecht liefert 403 mit der fehlenden Berechtigung; ein nicht zugängliches Dataset bleibt bei 404 ohne Berechtigungsdetails. Ein ungültiger Entwurfstest erklärt, dass der Entwurf nicht ausgewertet werden kann, und behält die Feldprobleme bei.

### Vorschläge prüfen { #checking-suggestions }

**Er lernt nur aus Trainingsfällen.** Neben bewerteten Chats liest der Assistent fehlgeschlagene Trainingsantworten, bestätigte Regressionen, Bewerterbegründungen und Prüfungsnotizen aus zugänglichen [Datasets](datasets.md). Er erhält Trainingsquoten nach Tag und Bewerterkriterium sowie die Anzahl behobener und neuer Fehler. Kontrollfragen, Antworten und Bewertungen gelangen nie in seinen Prompt. Runs des Bewerters und des Assistenten bleiben ausgeschlossen.

Jeder Fall wird fest dem Training oder der Kontrolle zugeordnet, auch über Dataset-Versionen hinweg. Die Dataset-Einstellungen bestimmen den Kontrollanteil nur für künftige Fälle (standardmäßig 50%). Vorschlagsprüfungen messen ausschließlich Kontrollfälle; eine Verbesserungssitzung teilt die Fragen für jeden ihrer Versuche im selben Anteil neu auf und misst jeden Versuch auf seinem eigenen Kontrollteil. Beide benötigen mindestens fünf bewertbare Kontrollfragen.

Kopien von Trainingsfragen oder Quellbelegen werden anhand normalisierter Eingaben und der Quell-Run-ID ausgeschlossen, auch bei manueller Eingabe oder Generierung. Unter dem Minimum stoppt eine Sitzung mit `no_data` oder lehnt den Schritt ab, der zu wenige testen würde, und nennt die fehlende Anzahl. Der Run kennzeichnet beide Teile und ausgeschlossene Kopien. Normale Suites und Beförderungsschranken zählen weiterhin alle Fälle.

Eine Verbesserungssitzung fixiert Dataset-Version und Chat-Belegidentitäten. Ein späterer Versuch lernt aus den Trainingsergebnissen seiner eigenen Aufteilung, sodass eine Frage, die ein Versuch zurückgelegt hat, beim Schreiben des nächsten helfen kann; neue Chats und Fälle ändern nicht, was die Sitzung misst. Auf verschiedenen Fragen gemessene Versuche werden danach verglichen, was jeder gegenüber seiner eigenen Ausgangsfassung geändert hat, nicht nach ihren Bestehensquoten.

Eine menschliche Entscheidung und **Entscheidung zurücknehmen** verwerfen abhängige Run-Vergleiche und berechnen gespeicherte Suite-Ergebnisse in derselben Transaktion neu. Run, Suite, Umgebungsschranke und Beförderungsdialog zeigen das korrigierte Urteil und die prüfende Person. Das Audit hält alte und neue Zustände sowie Zählwerte fest; ein geändertes Suite-Urteil erzeugt eine neue Benachrichtigung. Namen werden aus der aktuellen Organisationsmitgliedschaft aufgelöst und nicht in aufbewahrte Ergebnisse kopiert.

Ein durch Prüfung erzielter Erfolg erlaubt eine ausdrückliche Beförderung. Er befördert oder verschiebt niemals automatisch eine folgende Umgebung, auch nicht beim periodischen Abgleich. Die Umgebungszeile zeigt das tatsächliche fehlgeschlagene oder korrigierte Wächterergebnis und verlinkt die Prüfung. Ein früheres Ergebnis mit anderen Fragen, Bewertungen, Schwellen oder einer anderen bereitgestellten Vergleichsversion bleibt als **Veraltet** mit Run-Link sichtbar, statt **Nicht geprüft** zu werden.

## Als was jeder Fall läuft { #what-each-case-runs-as }

Jeder Fall ist ein gewöhnlicher Run des Agents mit der Oberfläche `eval`. Er
wird vor jeder Modellanfrage gegen die Budgets geprüft, und seine Kosten
werden erfasst. Er bleibt aus den Nutzungszahlen des Dashboards heraus, die nur
die Produktion zählen und die Kosten des Eval-Verkehrs daneben melden
(`cost.eval_usd`), und die Run-Historie lässt ihn weg, wenn danach gefragt wird
(`?exclude_surface=eval`). Das Lesen des einzelnen Runs nennt den Eval-Run und
den Fall, den er beantwortet hat (`eval_case`), für eine lesende Person, die
das Dataset sehen darf. Er läuft als die Person, die den Eval gestartet hat,
mit ihrer aktuellen Rolle, und liest oder schreibt nicht ihr persönliches
Gedächtnis.

Jeder Fall läuft **isoliert**, wie [Umgebungen](environments.md) beschreibt:
Ein Tool mit einer Testverbindung in der Umgebung des Runs läuft gegen diese,
ein Tool, von dem bekannt ist, dass es nur liest, läuft auf der normalen
Verbindung, und alles, was ohne Testverbindung schreibt, wird nicht ausgeführt
- der Aufruf und seine Argumente werden als beabsichtigter Aufruf behalten, den
das Trajektorie-Scoring trotzdem bewertet.

Jeder isolierte Versuch erhält einen temporären Workspace für seinen eigenen
Run, auch wenn der Agent Dateien sonst pro Unterhaltung, Benutzer oder Agent
teilt. Er benötigt keine Chat-Unterhaltung und verwendet keine dieser
persistenten Dateien. Der Workspace wird am Ende des Runs freigegeben.

Ein Fall aus einer Conversation kann **aus der Aufzeichnung** des Runs
beantwortet werden, aus dem er stammt (`from_recordings`): Ein Aufruf, der zur
Aufzeichnung passt, bekommt das aufgezeichnete Ergebnis, einer, der nicht
passt, wird zurückgehalten und als abweichend markiert. Ein Fall ohne
verwendbare Aufzeichnung läuft isoliert ohne sie.

### Ein Entwurf zählt nie als Version { #a-draft-is-never-counted-as-a-version }

Ein Entwurf läuft über denselben Weg, mit zwei Unterschieden. Er wird zuerst
gegen den eigenen Zugriff der startenden Person geprüft - alles, was eine
Veröffentlichung prüfen würde -, weil ein Entwurf beim Speichern nie validiert
wurde. Und seine Runs werden keiner Version zugeordnet: Sie erscheinen nicht in
der Nutzung einer Version, und die Zahlen einer Version enthalten nie Antworten
ihres Entwurfs.

Der Entwurf wird beim Start des Runs kopiert, sodass jeder Fall auf denselben
Inhalt antwortet, auch wenn jemand weiter bearbeitet.

## Ausführen und abbrechen { #running-and-cancelling }

Ein Run wird im Hintergrund ausgeführt, als eigener Job im Worker, und
übersteht daher einen Neustart der API. Fälle laufen zu wenigen gleichzeitig:
höchstens `EVAL_RUN_CONCURRENCY` pro Run und höchstens `EVAL_ORG_CONCURRENCY`
über alle Eval-Runs einer Organisation, sodass ein Dataset mit 500 Fällen nicht
jede Anfrage belegen kann, die ein Provider der Organisation erlaubt.

Abbrechen (`POST /api/v1/eval-runs/{id}/cancel`, durch die Person, die ihn
gestartet hat, oder jeden, der den Agent bearbeiten darf) stoppt, was noch nicht
begonnen hat: Bereits laufende Fälle laufen zu Ende und werden behalten, und
kein weiterer Fall startet. Wer den Job eines Runs unter **Admin** →
**Background jobs** abbricht, bevor ein Worker ihn übernommen hat, bricht den
Run ebenso ab, binnen Sekunden.

Ein Run, den sein Worker nicht beenden kann - etwa weil ihm mitten im Run die
Datenbank wegbricht -, endet sofort als `failed`, wie ein Agent-Run: Seine
laufenden Fälle schlagen fehl, die übrigen werden übersprungen, und seine Seite
sagt, dass er an einem Fehler angehalten hat und neu gestartet werden sollte. Er
wird nicht fortgesetzt. Ebenso sofort als `failed` endet ein Run, dessen Job die
Zeit ausgegangen ist oder dessen Worker währenddessen heruntergefahren wurde.

Ein Worker kann auch kommentarlos sterben. Der Worker eines laufenden Runs meldet
alle `EVAL_HEARTBEAT_SECONDS`, dass er lebt; ein Run, dessen Worker schweigt und
dessen Fälle sich `EVAL_ABANDONED_AFTER_MINUTES` lang nicht bewegt haben, wird
von einem Sweep, den der Worker jede Minute ausführt, als fehlgeschlagen beendet,
der auch seine Plätze freigibt. Ein Worker, dessen Heartbeats so lange
fehlschlagen - auf einem Host, der zu ausgelastet ist, um seine Datenbank zu
erreichen -, wird ebenso beendet, obwohl er noch arbeitet, und sein Run muss neu
gestartet werden.

Ein Run in der Warteschlange hat noch keinen Worker, der melden könnte, dass er
lebt. Er darf auf einen freien Worker oder hinter einer pausierten Job-Art warten,
solange sein Job in der Warteschlange steht; der Sweep beendet ihn erst als
fehlgeschlagen, wenn kein Job mehr übrig ist, der ihn ausführen würde. Ein Fall,
den ein toter Worker in einem bereits beendeten Run laufend zurückgelassen hat,
schlägt nach denselben `EVAL_ABANDONED_AFTER_MINUTES` fehl. Ein laufender Fall
zählt auf `EVAL_ORG_CONCURRENCY`, bis er endet, auch nachdem sein Run
abgebrochen wurde.

Solange ein Run wartet oder läuft, lassen sich die Umgebung, die er nennt, und
das Modellprofil, auf dem eine seiner Seiten läuft, nicht entfernen: Seine
übrigen Fälle würden sonst gegen die Verbindungen der Produktion antworten oder
auf einem anderen Modell als die Fälle davor.

## Ergebnisse { #results }

Jeder Versuch behält die Antwort, die gemachten Aufrufe - jeder markiert als
ausgeführt, blockiert, wiedergegeben oder abweichend -, das Urteil und die
Begründung jedes Bewerters, seine Kosten, seine Tokens und seine Latenz.
Antwort und Aufrufe werden in das Ergebnis kopiert, weil ein Run eines Falls
keine Conversation hat, in der er ein Transkript behalten könnte.

Jeder Arm des Runs wird auf zwei Achsen zusammengefasst, und pro Tag:

| Achse | Misst |
|---|---|
| Qualität | Bestehensquote unter den entschiedenen Fällen, jeder so gewertet, wie die meisten seiner Versuche ausgingen; daneben die Quote der ersten Antworten; wie viele unentschieden blieben, und warum |
| Effizienz | Kosten pro bestandenem Fall, Tokens pro Fall und Latenz bei p50 und p95 |

Jeder Versuch geht auf eine von vier Arten aus (`state` am Versuch):

- **bestanden** oder **nicht bestanden** nach seiner Bewertung;
- ebenfalls **nicht bestanden**, wenn der Run des Agenten gescheitert ist - ein
  Werkzeug hat eine Ausnahme geworfen, sein Schrittlimit, eine Schleife, eine
  Guardrail, eine vom Provider abgelehnte Anfrage -, was eine Suite sofort
  durchfallen lässt, auch wenn die Wiederholungen des Falls bestehen;
- **unvollständig**, wenn der Provider nach seinen Wiederholungen gescheitert
  ist (ein Fehler 5xx, 408 oder 429 oder gar keine Antwort), ein Bewerter eine
  Ausnahme geworfen hat, der Run abgebrochen wurde oder das Budget ausging, oder
  seine Versuche unentschieden ausgingen;
- Bewertung ohne erforderlichen Scorer, der einen Fall entscheiden kann: ergänze eine Prüfung, einen erwarteten Werkzeugaufruf oder Bewertungskriterien;

Keiner der letzten beiden ist je bestanden; die Zusammenfassung zählt sie
getrennt (`incomplete`, `ungraded`).

Der Kopf eines Runs sagt „Bestehensquote 67 % · 1 von 3 Fällen unentschieden“ und nennt das
Ergebnis unentschieden, bis jeder Fall ein Urteil hat. Ein Provider, der die
Zugangsdaten ablehnt, wird als solcher genannt, und eine Seite, deren Antworten
alle mit demselben Fehler gescheitert sind, sagt das statt eines Urteils. Ein
Fall, an dem der Agent abgestürzt ist, wo die Baseline bestand, ist eine
Regression wie jede andere, gezeigt mit ihrem Fehler.

Eine Antwort, bei der der Bewerter gescheitert ist oder die er übersprungen hat, ist **nicht bewertet**: Der Run listet diese
Bewertungen als `ungraded_score_ids`, und sie erneut zu bewerten
(`POST /api/v1/datasets/{id}/scores/rescore`) liest die im Versuch behaltene
Antwort, statt den Agent zu fragen. Das Urteil einer Person bei der
[Prüfung](datasets.md#review) ersetzt für diesen Fall das Ergebnis der Scorer,
und die Zahlen des Runs folgen ihm.

Ein Bewerter, der sucht - [Knowledge search](concepts.md#system-agent-spec) auf
seinem Toolbox-Tab -, prüft die Fakten einer Antwort an den Wissensbasen des Agents,
der sie gab, und jede seiner Bewertungen führt unter ihrer Begründung auf, was
er dort fand: das Dokument und den Anfang der Stelle. Bis seine Runs ihm einen
Verlauf geben, bepreist die Schätzung jede Bewertung mit den Schritten des
Bewerters. Ein Bewerter beginnt mit Temperatur 0, damit dieselbe Antwort
zweimal gleich bewertet wird, und seine Seite warnt, wenn sie erhöht wird.

Ein abgeschlossener Run behält Urteil, Zählungen und Bestehensquoten seines
ersten Kandidaten als `outcome`, sodass eine Liste sie liest, ohne jeden Run
erneut zu vergleichen. Er wird erneut verglichen, wenn eine Person seitdem über
eine der Bewertungen entschieden hat, auf denen er beruht, oder eine davon
erneut bewertet wurde.

```text
GET /api/v1/agents/{agent_id}/eval-runs      an agent's runs, newest first; ?draft=current
GET /api/v1/datasets/{dataset_id}/eval-runs  a dataset's runs over the agents the reader may see
GET /api/v1/eval-runs/{id}                   one run, with each arm's summary and its outcome
GET /api/v1/eval-runs/{id}/cases             cases, what each expects, and every attempt;
                                             ?outcome=, ?tag=, ?arm_id=, ?case_id=
GET /api/v1/eval-runs/{id}/comparison        a candidate arm against its baseline
GET /api/v1/eval-runs/{id}/arms/{arm}/spec   the spec one side ran; needs agents:edit
```

`?draft=current` behält die Runs, die den Entwurf in seinem jetzigen Stand
getestet haben - denselben Spec, gleich in welcher Reihenfolge seine Schlüssel
gespeichert wurden, darunter eine Prüfung von Vorschlägen, die inzwischen
angenommen sind -, und genau das liest der Veröffentlichungsdialog.
`?draft=earlier` behält die Runs, die seit der Veröffentlichung der neuesten
Version einen anderen Entwurf getestet haben - eine Prüfung erst, wenn einer ihrer
Vorschläge angenommen wurde: den Test, von dem sich der Entwurf entfernt hat. Eine
Prüfung, die am Entwurf selbst gemessen wurde, zählt in keinem von beiden.

Ein Bewerterkriterium kann für alle Fälle oder nur für Fälle mit mindestens einem ausgewählten Tag gelten. Wählen Sie unter **Bewertung** (Grading) die Tags und prüfen Sie die Anzahl; ein Fall mit mehreren passenden Tags zählt einmal. Nicht passende Kriterien werden vollständig ausgelassen und können den Fall weder scheitern noch unentschieden lassen. Prüfungsnotizen können Kriterien für einen ausgewählten Fall-Tag werden. Eine Bereichsänderung ändert den Bewertungsfingerabdruck; Wächter übernehmen sie erst nach einem autorisierten Verschieben der Anheftung.

## Mit einer Baseline vergleichen { #comparing-with-a-baseline }

Ein Vergleich ordnet beide Seiten Fall für Fall über die stabile ID des Falls
zu und meldet jeden Fall als **Regression** (bestanden, jetzt nicht mehr),
**behoben** (nicht bestanden, jetzt bestanden), unverändert oder unvollständig.
Fälle, die nur eine Seite beantwortet hat, zählen als nicht verglichen. Ebenso
ein Fall, dessen Eingabe, Verlauf, Referenzantwort, Gegenbeispiel, erwartete
Aufrufe oder Checks sich zwischen den beiden Seiten geändert haben (`changed`):
Einen Check zu verschärfen ist eine Änderung des Falls, nicht des Agents, und
die Seite des Runs sagt, wie viele sich seit der Baseline geändert haben. Eine
Änderung seiner Tags oder seiner Notiz zählt nicht.

Die Baseline wird **beim Start des Runs** gewählt, als eigene Seite am Run
gespeichert und nie neu gewählt: Wer den Run nach der nächsten Veröffentlichung
öffnet, sieht denselben Vergleich.

**Die Standard-Baseline ist günstig**: der letzte abgeschlossene Run desselben
Datasets auf der Version vor dem Kandidaten - bei einem Entwurf die
veröffentlichte Version. Es zählt nur ein Run dieser Version, wie sie
veröffentlicht ist: auf ihrem eigenen Modell, ohne vorgeschlagenen Skill- oder
Kontextinhalt, mit jedem Fall beantwortet, mit demselben Scoring bewertet und in
derselben Umgebung mit denselben `from_recordings` und `live_reads` gelaufen.
Gibt es keinen, hat der Run keine Baseline; die Schätzung sagt das
(`missing_baseline_version`), und der Startdialog bietet an, diese Version
stattdessen daneben laufen zu lassen. Beide Seiten sind mit Datum, Modell und
Dataset-Version beschriftet, weil sie sich in den letzten beiden davon
unterscheiden können.

Ein Run kann stattdessen einen **früheren Run** desselben Agents auf demselben
Dataset als Baseline nennen (`baseline_run_id`), einen abgeschlossenen - so
sieht eine [Eval-Suite](#suites), die täglich dieselbe Version prüft, die
Drift.

### Eine Baseline im selben Run { #a-baseline-in-the-same-run }

Wenn eine Entscheidung vom Ergebnis abhängt - ein Promotion-Gate, eine mit
Evals geprüfte vorgeschlagene Änderung, ein Modellvergleich -, läuft die
Baseline **im selben Run** (`paired_baseline`, und immer bei
`purpose: "gate"`). Provider verändern sich von Tag zu Tag, und eine Regression,
gemessen an den Antworten der letzten Woche, kann am Provider liegen, nicht am
Agent.

Ein abgeschlossener Baseline-Arm ersetzt einen neuen Lauf nur, wenn Version,
Dataset-Version, Modell, Scoring und Bewerter übereinstimmen, er in derselben
Umgebung mit denselben `from_recordings` und `live_reads` lief und er
innerhalb von `EVAL_BASELINE_CACHE_HOURS` fertig wurde. Der Run nennt den Run, den er
wiederverwendet hat. Nur seine ersten Antworten werden wiederverwendet: Ein Fall,
der kippt, wird ihm in diesem Run erneut gestellt.

### Ein Kippen wird bestätigt, bevor es zählt { #a-flip-is-confirmed-before-it-counts }

Ein gekippter Fall wird `EVAL_RERUNS` Mal (standardmäßig 2) wiederholt, sobald
die ersten Antworten vorliegen. Eine Regression ist **bestätigt**, wenn jede
Wiederholung des Kandidaten wieder nicht besteht und - bei einer Baseline im
selben Run - jede Wiederholung der Baseline wieder besteht; sonst wird sie als
**unbestätigt** gemeldet. Eine Behebung wird genauso bestätigt.

Jede Baseline wird neben dem Kandidaten wiederholt - eine, die hier geantwortet
hat, oder eine, deren erste Antworten aus einem früheren Run stammen -, sodass
beide Seiten ein Kippen am selben Tag bestätigen und eine glückliche Antwort der
Baseline nichts bestätigt. Die einzige Ausnahme ist eine Baseline, die der
Kandidat selbst zu einem früheren Zeitpunkt ist - derselbe Spec auf demselben
Modell, auf dieselbe Weise ausgeführt, wie sie eine Suite, die täglich eine
Version prüft, zum Vergleich heranzieht: Ihre Wiederholungen wären nur wieder
die des Kandidaten, daher wird sie nicht wiederholt, und die Wiederholungen des
Kandidaten allein bestätigen die Drift.

Ein Run, der mit einer Baseline verglichen wird, braucht mindestens eine
Wiederholung; ein Run ohne Baseline darf sie überspringen. Ein Run, der mit
einem früheren Run verglichen wird, den er nie erneut gefragt hat - einer, der
geschrieben wurde, bevor Baselines an Runs gespeichert wurden, oder einer, der
von Hand mit einem anderen Run verglichen wurde -, sagt das, und keiner seiner
gekippten Fälle ist bestätigt.

Wiederholungen heben die Latte, statt sie zu senken: Ein Kippen gilt nur als
bestätigt, wenn es bei jeder Wiederholung hält, daher bestätigen mehr
Wiederholungen weniger Kippen. Ein kleines oder günstiges Modell, das einen Fall
von Versuch zu Versuch anders beantwortet, lässt seine Kippen unbestätigt, und
das Urteil lautet `no_difference`, auch wenn sich die Bestehensquote bewegt
hat - das heißt, das Modell ist bei diesen Fällen unbeständig, nicht dass sich
nichts geändert hat. Helfen mehr Fälle im Dataset, ein beständigeres Modell oder
eine niedrigere `temperature` in seinen [Model
Settings](models.md#model-settings) und das Durchsehen der unbestätigten Fälle
in der Tabelle.

Die Seite des Runs sagt es, wenn nichts hielt, aber drei oder mehr Fälle sich
einmal änderten oder die beiden Bestehensquoten 20 Punkte oder mehr
auseinanderliegen.

Die Bewertung kann sich so sehr bewegen wie das Modell. Ein Bewerter, dessen
Kriterium auf seiner Schwelle liegt - eine Skala von 1 bis 5, die ab 4 besteht,
etwa - bewertet fast dieselbe Antwort beide Male verschieden, sodass dieselbe
Version auf denselben Fällen unterschiedlich abschneidet. Eine
[Verbessern-Sitzung](authoring.md#the-improve-wizard) liest das aus ihren eigenen
Prüfungen, ohne neuen Modellaufruf, und ihr Ergebnis sagt es, wenn Antworten
innerhalb eines Versuchs beim erneuten Stellen verschieden bewertet wurden oder
sich die heutige Version zwischen Versuchen auf ihren gemeinsamen zurückgelegten
Fragen bewegt hat - weniger als fünf gemeinsame sind zu wenige, um das zu
beurteilen.

Verwende klare Ja/Nein-Kriterien, deterministische Format- und Längenprüfungen sowie ausreichend repräsentative Fälle. Wähle ein geeignetes unabhängiges Bewertungsmodell ausdrücklich im Tab **Bewertung** des Datasets; der Modellpreis belegt keine Bewertungsqualität.

### Wie beständig die Antworten sind { #how-steady-the-answers-are }

Ein **Stabilitäts-Run** misst das Rauschen, bevor etwas verglichen wird. Er
stellt jeden Fall des Datasets und dann jeden noch einmal - `reruns`-mal,
standardmäßig einmal - und vergleicht nichts. Der Run zählt die Fälle, die
einmal als bestanden und einmal als nicht bestanden bewertet wurden: Schon zwei
davon oder ein Fünftel der gestellten Fälle bedeuten, dass ein Vergleich auf
diesem Dataset höchstwahrscheinlich nichts zeigen würde, weil sich die Antworten
oder ihre Bewertung von selbst bewegen. Nur ein Fall mit einer bewerteten ersten
Antwort und einer bewerteten Wiederholung zählt.

Bevor eine [Verbessern-Sitzung](authoring.md#the-improve-wizard) beginnt, ist der
Test, wie der Agent heute antwortet, ein Stabilitäts-Run des Entwurfs, der jede
Frage zweimal stellt: standardmäßig bei einem Dataset mit weniger als 40 Fragen
und auf Wunsch bei einem größeren, da er die Kosten verdoppelt. Findet er die
Antworten unbeständig, sagt der Startbildschirm, dass die Sitzung
höchstwahrscheinlich nichts zeigen wird, mit einem Link zu den
Bewertungskriterien und zum Bewertungsmodell. Der letzte solche Run des Entwurfs
wird nach dem Neuladen der Seite wieder angezeigt.

Über die API ist es `stability: true` bei einem Run des Entwurfs oder einer
Version, ohne `paired_baseline` oder `baseline_run_id`; seine Leseantwort hat
`purpose` `stability` und `stability` mit `asked`, `unstable` und `noisy`.

### Was das Urteil sagt { #what-the-verdict-says }

Das Urteil beruht nur auf den bestätigten Kippfällen. Eine bestätigte
Regression macht den Kandidaten `worse` - ein Fall, den er jedes Mal
verschlechtert, ist Grund genug, nicht zu veröffentlichen -, nur bestätigte Behebungen
machen ihn `better`, beides macht ihn `mixed`, und gar kein bestätigter
Kippfall ist `no_difference`. Jeder Kippfall nennt die Frage des Falls.

Unabhängig davon ergibt ein exakter McNemar-Test über die bestätigten
Kippfälle `overall`: `worse` oder `better`, wenn er die beiden Seiten bei
`EVAL_SIGNIFICANCE` unterscheidet, und null, wenn es zu wenige Kippfälle gibt,
wie bei den meisten kleinen Datasets.

Die Bestehensquote zählt jeden Fall nach der Mehrheit seiner entschiedenen
Versuche - nur nach seiner ersten Antwort, wenn er nicht wiederholt wurde, und
das Urteil einer Person über diese Antwort geht beidem vor -, sodass sie mit
den bestätigten Kippfällen übereinstimmt. Die eigene Quote der ersten
Antworten wird daneben als `first_pass_rate` behalten.

### Ein anderer Bewerter macht den Vergleich ungültig { #a-different-judge-invalidates-the-comparison }

Jede Bewertung hält den [Bewerter fest, der sie vergeben hat](datasets.md#judge):
sein Modell, seine Version, einen Fingerabdruck der Rubrik und die Version des
eigenen Prompts des Bewerters. Wurden die beiden Seiten mit unterschiedlichen
Scoring-Einstellungen bewertet oder von einem anderen Bewerter, Modell, einer
anderen Rubrik oder einem anderen Prompt, ist der Vergleich `invalid` und gibt
kein Urteil - ein Kippen sagt dann etwas über die Bewertung, nicht über den
Agent. Eine Baseline, die unter einem früheren Prompt des Bewerters bewertet
wurde, sagt das und wird nicht als zwischengespeicherte Baseline
wiederverwendet.

Ein Run, dessen Bewerter sich änderte, während seine Fälle bewertet wurden, ist
ebenfalls `invalid`: Ein Fall, dessen Versuche Bewertungen zweier Bewerter tragen,
entscheidet sich nach dem, der mehr davon bewertet hat.

### Zwei Achsen, Qualität zuerst { #two-axes-quality-first }

Das Urteil betrifft die Qualität. Effizienz wird daneben gemeldet und nie
hineingerechnet: Kosten pro bestandenem Fall, Tokens und Latenz sind jeweils
`better`, `worse` oder `unchanged`, wobei eine Änderung innerhalb von
`EVAL_EFFICIENCY_TOLERANCE` als unverändert gilt.

## Modelle vergleichen { #comparing-models }

Mehrere `model_profile_ids` lassen den Kandidaten im selben Run einmal pro
Modell laufen, jedes als eigener Arm. Jeder Arm meldet seine Bestehensquote,
Kosten und Latenz nebeneinander. Mit einer Baseline im selben Run läuft die
Baseline auf dem zuerst genannten Modell, und jeder Arm wird mit ihr
verglichen.

## Suites { #suites }

Eine **Suite** ist ein Eval-Run, an dessen Start niemand denken muss. Sie nennt
den Agent, das Dataset, die Umgebung, deren Version sie prüft, und eine
Schwelle, die jedes Ergebnis erfüllen muss, und läuft dann selbstständig. Die
Karte **Suites** steht im Evals-Tab eines Agents unter den Runs: das Dataset
jeder Suite, wann sie läuft, ihre Schwelle und wie sie zuletzt abschnitt.
Geöffnet listet eine Suite jedes Ergebnis, warum es nicht bestand, die
verschlechterten Fälle und einen Link zum Eval-Run dahinter; die Seite dieses Runs
nennt die Suite, die ihn gestartet hat.

### Wann eine Suite läuft { #when-a-suite-runs }

Jede Kombination aus:

- **Nach Zeitplan** - ein Cron-Ausdruck, gelesen auf der Uhr einer Zeitzone,
  sodass `0 6 * * *` in `Europe/Berlin` vor und nach der Zeitumstellung sechs
  Uhr in Berlin ist. Sie prüft die Version, die ihre Umgebung ausliefert - die
  täglich geprüfte Produktionsversion bemerkt, wenn sich das Modell beim
  Provider oder eine Wissensbasis darunter ändert. Ein Lauf, der verpasst
  wurde, während der Worker stand, läuft einmal.
- **Bei Veröffentlichung** - jede neue Version, mit der Version davor im selben
  Eval-Run daneben.
- **Bei Promotion** - eine Version, die auf die Umgebung der Suite promotet
  wird (die Standardumgebung, wenn sie keine nennt), gemessen an der Version,
  die sie ersetzt.
- **Wenn sich eine Abhängigkeit ändert** - ein Skill oder eine Context-Datei,
  die die geprüfte Version bindet, wird bearbeitet, oder ein Dokument in einer
  Wissensbasis, die sie durchsucht, wird hinzugefügt, neu eingelesen oder
  gelöscht. Spezialisten, die die Version definiert, zählen als die Version.
  Eine Reihe von Änderungen ist ein Lauf, fällig
  `EVAL_SUITE_DEPENDENCY_DEBOUNCE_SECONDS` nach der ersten. Ein Modellprofil
  lässt sich nicht an Ort und Stelle ändern - einen Agent auf ein anderes zu
  richten ist eine Veröffentlichung -, und ein Provider, der das Modell dahinter
  austauscht, ist das, was der Zeitplan bemerkt.
- **Jetzt ausführen** - von Hand, als die Person, die es drückt.

Eine Suite, die darauf wartet, eine Version zu prüfen, nimmt den nächsten
Trigger für dieselbe Version auf, sodass eine Veröffentlichung und die
Promotion dieser Version danach ein Lauf sind. Eine Suite führt einen Eval-Run
zur Zeit aus; eine Änderung, die währenddessen kommt, wartet auf den nächsten.
Eine pausierte Suite läuft nicht, weder durch einen Trigger noch von Hand.

Eine Suite, die **eine Umgebung bewacht**, läuft auch vor einer Promotion
darauf - auf der Version, die promotet werden soll, neben der, die die Umgebung
ausliefert -, und die Promotion wartet, bis sie besteht; siehe
[Eine Promotion mit Evals bewachen](environments.md#guarding-a-promotion-with-evals).
Ihre Ergebnisse heißen *Vor der Promotion* (`gate`). Eine Suite, die eine
Umgebung bewacht, ist auf die Dataset-Version und das Scoring festgelegt, die sie
hatte, als sie Wächter wurde; das Dataset zu bearbeiten ändert also nicht, was
sie prüft, bis die Festlegung verschoben wird. Sie lässt sich erst löschen, wenn
sie dort abgenommen ist.

### Was ein Ergebnis erfüllen muss { #what-a-result-must-meet }

Ohne Mindestbestehensquote oder früheres vergleichbares Ergebnis erhält eine vollständige erste Messung den Status **Vergleichsbasis gesetzt**, auch wenn alle Fälle durchgefallen sind. Sie dient späteren Vergleichen und gilt nicht als bestanden: Sie öffnet keine Promotionsschranke und verschiebt keine folgende Umgebung. Setze eine Mindestquote für eine absolute Qualitätsanforderung. Beim Upgrade werden frühere Bestehensergebnisse ohne beide Kriterien neu eingestuft; bereits verschobene Umgebungen bleiben zur Prüfung durch den Betreiber bestehen.

Ein Ergebnis **besteht nicht**, wenn mehr Fälle reproduzierbar gegenüber der
Baseline brechen, als die Suite erlaubt - standardmäßig keiner, also lässt eine
bestätigte Regression es durchfallen -, oder wenn die Bestehensquote, jeder
Fall nach der Mehrheit seiner Versuche, unter das Minimum der Suite fällt. Die
Richtung aus dem McNemar-Test steht neben dem Ergebnis und entscheidet es nie.
Zwei optionale Grenzen prüfen die Effizienz: den Anstieg der Kosten pro
bestandenem Fall und der p95-Latenz gegenüber der Baseline; leer prüfen sie
nichts.

Ein Ergebnis, dessen Vergleich
[ungültig](#a-different-judge-invalidates-the-comparison) ist oder in dem auch
nur ein Fall unvollständig oder nicht bewertet blieb, ist **ohne Ergebnis** - nie
bestanden -, es sei denn, etwas ist klar durchgefallen: eine bestätigte
Regression oder ein Minimum, das die Bestehensquote verfehlt, selbst wenn jeder
unentschiedene Fall bestünde. Es nennt die Fälle, die unentschieden blieben.

Eine Guardrail-Blockade wird als Ablehnung mit der gespeicherten Begründung bewertet; vom Ausgabe-Guardrail zurückgehaltener Inhalt wird nicht bewertet. Das Warten auf eine Freigabe oder Antwort, ein Abbruch und ein unvollendeter Lauf lassen den Fall unvollständig. Ein fehlgeschlagener Lauf, eine gestoppte Schleife oder eine Schrittgrenze zählt als Ausfall. Die Ausfälle erster Antworten werden unabhängig von der Mehrheit der Versuche gezählt: Jeder solche Ausfall lässt die Suite scheitern, auch wenn Wiederholungen bestehen oder unentschieden enden.

Ein Wächter hält die Veröffentlichung des Bewerters zusammen mit Dataset und Bewertung fest. Eine neue Veröffentlichung ändert weder seine Läufe noch deren erneute Bewertung. Das Verschieben braucht `promotions:override` und protokolliert alte und neue Bewerterversion in `agent.environment_guards_changed`. Ein fehlender angehefteter Bewerter lässt die Bewertung unvollständig; eine neue Veröffentlichung wird nie automatisch gewählt. Nach dem Upgrade öffnen alte Läufe ohne gespeicherte Bewerteranheftung kein Tor.

Bei einer Suite ohne Wächter ändert eine neue Veröffentlichung die Bewertung: Der nächste Vergleich bleibt einmal ohne Ergebnis und der Eigentümer wird benachrichtigt. Eine
Bestehensquote unter dem Minimum lässt ein Ergebnis unabhängig vom Vergleich
durchfallen: Das Minimum braucht keine Baseline. Ein Ergebnis, dessen Eval-Run
abgebrochen wurde, ist ebenfalls ohne Ergebnis und sagt das; eines, dessen Run
fehlgeschlagen ist, ist ein Fehler.

Eine Suite läuft nicht, wenn ihre Schätzung das verbleibende Budget oder ihre eigene Grenze überschreitet, keine veröffentlichte Version existiert oder kein erforderlicher Scorer einen Fall entscheiden kann.

Geplante Läufe und Läufe nach
einer Abhängigkeit werden mit dem letzten bestandenen Lauf der Suite auf
derselben Version verglichen - dem letzten als gut bekannten Stand, sodass ein
verschlechterter Fall verschlechtert bleibt, bis ihn jemand behebt - und messen so die
Drift; eine Veröffentlichung oder Promotion lässt ihre Baseline im selben Run
laufen. Nach einem Ergebnis, das sich mit diesem Lauf nicht vergleichen ließ -
weil sich die Bewertung seitdem geändert hat -, lässt der nächste die Version
davor neben sich laufen, so bewertet, wie es jetzt geschieht, damit er wieder
bestehen und der Lauf werden kann, mit dem die folgenden verglichen werden.

Wenn beide zusammen das `max_run_usd` der Suite überschreiten würden, der
Kandidat allein aber nicht, läuft der Kandidat ohne die Version davor neben
sich: verglichen mit dem letzten vergleichbaren Lauf dieser Version, wenn noch
einer da ist, sonst an seinen eigenen Zahlen gemessen. Lässt sich nichts
vergleichen, sagt das Ergebnis „Not compared: running the earlier version too
would exceed the suite's cost cap.“, und ein bestandenes Ergebnis, das das sagt,
benachrichtigt den Eigentümer der Suite.

Eine [Prüfung der Vorschläge des Authoring-Assistenten](authoring.md#check-with-evals)
auf einer Suite wird am selben Schwellenwert gemessen, ist aber kein Ergebnis der
Suite: Sie steht in keinem ihrer Verläufe und benachrichtigt niemanden.

### Als wer sie läuft, und wer benachrichtigt wird { #who-it-runs-as-and-who-is-told }

Eine Suite läuft als die Person, die sie zuletzt gespeichert hat - ihr
**Eigentümer** -, mit deren Berechtigungen zum Start des Runs. Niemand sieht
einem geplanten Lauf beim Start zu, also stimmt, wer eine Suite speichert,
ihren Kosten zu, und das Formular nennt vorher den Preis eines Laufs und eines
Monats des Zeitplans. Wer die Suite sonst ändert, übernimmt sie. Eine Suite,
deren Eigentümer die Organisation verlässt oder sie nicht mehr ausführen kann,
pausiert mit dem Grund - ebenso eine, deren Umgebung entfernt wird, ob schon
pausiert oder nicht, statt still eine andere Version zu prüfen. Sie lässt sich
erst fortsetzen, wenn jemand wieder eine Umgebung für sie wählt.

Der Eigentümer wird benachrichtigt, wenn ein Ergebnis nicht besteht, ohne
Ergebnis bleibt oder nicht läuft - einmal pro Serie solcher Ergebnisse auf einer
Version, mit den verschlechterten oder unbewerteten Fällen -, im Benachrichtigungscenter und per E-Mail, wenn er sie
eingeschaltet hat. Slack ist noch kein Benachrichtigungskanal.

## Einstellungen { #settings }

| Einstellung | Standard | Was sie entscheidet |
|---|---|---|
| `EVAL_RUN_CONCURRENCY` | `3` | Fälle, die ein Run gleichzeitig ausführt |
| `EVAL_ORG_CONCURRENCY` | `6` | Fälle, die eine Organisation gleichzeitig ausführt, über ihre Runs hinweg |
| `EVAL_RERUNS` | `2` | Wiederholungen eines gekippten Falls; ein Run kann 0 bis 5 verlangen |
| `EVAL_BASELINE_CACHE_HOURS` | `24` | Wie alt eine passende Baseline sein darf, um wiederverwendet zu werden |
| `EVAL_SIGNIFICANCE` | `0.05` | Das Niveau, unter dem bestätigte Kippfälle ein Urteil sind |
| `EVAL_EFFICIENCY_TOLERANCE` | `0.05` | Eine relative Änderung von Kosten, Tokens oder Latenz, die als keine zählt |
| `EVAL_FALLBACK_INPUT_TOKENS` | `2000` | Die Input-Tokens, mit denen ein Fall auf einem Modell ohne Historie bepreist wird |
| `EVAL_FALLBACK_OUTPUT_TOKENS` | `400` | Die Output-Tokens, mit denen ein Fall auf einem Modell ohne Historie bepreist wird |
| `EVAL_FALLBACK_CASE_COST_USD` | `0.05` | Die Schätzung pro Fall auf einem Modell ohne Historie und ohne bekannten Preis |
| `EVAL_ESTIMATE_SAMPLE` | `50` | Wie viele letzte Runs die Schätzung mittelt |
| `EVAL_ABANDONED_AFTER_MINUTES` | `10` | Wie lange ein laufender Run bei schweigendem Worker stillstehen darf, bevor der Sweep ihn beendet |
| `EVAL_HEARTBEAT_SECONDS` | `60` | Wie oft ein arbeitender Run meldet, dass er lebt |
| `EVAL_SUITE_DEPENDENCY_DEBOUNCE_SECONDS` | `600` | Wie lange eine Suite nach einer Änderung an einem Skill, einer Context-Datei oder einer Wissensbasis wartet, damit eine Reihe von Änderungen ein Lauf ist |

## Zugriff { #access }

Einen Run zu starten - oder zu fragen, was er kosten würde - erfordert zuerst
`runs:view`: Ein Run kostet Geld, und wer ihn nicht lesen oder abbrechen könnte,
darf ihn nicht starten, welche Grants er auch hat. Wo die Konsole ihm sonst ein
Start-Bedienelement anbieten würde, zeigt sie es deaktiviert und sagt warum.
Jeder Weg, einen zu starten, fragt dasselbe: Run evals, eine Suite, Test Entwurf
und Mit Evals prüfen des Assistenten.

Ein Start erfordert dann `datasets:run` auf dem Dataset und `agents:run`
auf dem Agent, jeweils mit den Grants der Ressource aufgelöst. Den Entwurf
laufen zu lassen erfordert außerdem `agents:edit` auf dem Agent, weil der Entwurf
die laufende Arbeit der Bearbeiter ist. Der Bewerter braucht, wenn er das Dataset
bewertet, was das [Scoring](datasets.md#scoring) sagt.

Einen Run zu lesen erfordert `runs:view` und dass die lesende Person sowohl den
Agent als auch das Dataset sehen kann - ein Run über ein Dataset, das sie nicht
öffnen kann, wird nicht aufgelistet, und eine Anfrage danach per ID antwortet
`404`, wie bei einem Run einer anderen Organisation. Die Runs eines Datasets
erfordern außerdem `datasets:view` darauf und listen nur die Agents, die die
lesende Person sehen darf.

Eine Suite anzulegen, zu ändern, zu pausieren oder auszuführen erfordert
`agents:edit` und `agents:run` auf dem Agent, `datasets:run` auf dem Dataset und
`runs:view`,
und eine Person, die als sie selbst angemeldet ist: Eine Suite gibt als die
Person aus, die sie speichert, also kann das weder ein API-Schlüssel noch ein
Administrator, der für jemanden handelt. Die Suites eines Agents zu lesen
erfordert `runs:view` und den Agent; die Fragen der Fälle, die ein Ergebnis
nennt, sieht nur, wer das Dataset öffnen darf.

## Was ein Run behält { #what-a-run-keeps }

Ein Ergebnis enthält die Antwort des Agents und die Argumente jedes Aufrufs,
den er gemacht hat, und kann daher personenbezogene Daten aus dem beantworteten
Fall und aus der Aufzeichnung enthalten, aus der geantwortet wurde. Es wird mit
seinem Run gelöscht, und ein Run mit seinem Agent oder seinem Dataset; das
Löschen der Conversation, aus der ein Fall stammt, löscht keine bereits daraus
erzeugten Ergebnisse. [Datenschutz](data-protection.md) führt es mit den
anderen Speichern auf.

Erkannte Geheimnisse in gespeicherten Antworten, Werkzeugaufrufen und Fehlern werden durch dieselben Platzhalter wie in der Prüfung und Dataset-Fällen ersetzt. Die erste Bewertung prüft die Originalantwort im Arbeitsspeicher vor dem Speichern; eine erneute Bewertung verwendet die gespeicherten, bereinigten Daten. Das Upgrade bereinigt auch vorhandene Ergebnisse; ein Downgrade stellt entfernte Geheimnisse nicht wieder her.