HHostingByteSoftware
Ctrl K
ComunidadGuías…

docs/datasets.de.md

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

Archivo original ↗Preguntar a KiBot
---
source_sha: "9c37b08af0c5"
title: "Datasets"
description: "Datasets enthalten die Fragen, an denen ein Agent getestet wird: versionierte Fälle, von Hand geschrieben, aus CSV oder JSONL importiert oder aus einer bewerteten Antwort übernommen."
---

# Datasets { #datasets }

Ein **Dataset** enthält die Fragen, an denen ein Agent getestet wird. Ohne eines
besteht jede Prüfung, ob eine Änderung den Agent besser gemacht hat, darin,
dass jemand ein paar Prompts von Hand ausprobiert und sich zu erinnern versucht,
wie die letzte Antwort aussah.

Jede Frage ist ein **Fall**: die Nachricht, die der Agent beantwortet, und wie
eine gute Antwort aussieht. Fälle kommen aus vier Quellen - in der Konsole
geschrieben, aus einer Datei importiert, aus einem echten Gespräch übernommen,
in dem jemand die Antwort negativ bewertet hat, oder vom Fallgenerator entworfen
und von einem Menschen angenommen. Die letzte Quelle
ist meist die wertvollste, weil es eine Frage ist, die ein Mensch wirklich
gestellt hat, und eine Antwort, die ihn wirklich enttäuscht hat.

**Fälle**, **Ergebnisse** und **Einstellungen** teilen einen Arbeitsbereich mit Vollbildsteuerung. Fälle enthält geschriebene und generierte Fälle; Ergebnisse verbindet Testläufe mit der Antwortprüfung; Einstellungen enthält Bewertung, Generierung und Verbesserung. Hinzufügen, Importieren, Generieren und Aktivität stehen an der Falltabelle. Ein Fall öffnet sich im Seitenpanel, Bearbeiten öffnet sein Formular. Frage und erwartete Antworten stehen zuerst; Werkzeuge, Prüfungen und Labels haben aufklappbare Abschnitte.

Bewertungsmodell und Anweisungen stehen zusammen mit Generierung und Verbesserung unter **Einstellungen**. Gespeicherte Modelle haben einen kompakten durchsuchbaren Selektor; **Modell hinzufügen** öffnet das Formular für Provider, Modell und Schlüssel. Anweisungen verwenden den Markdown-Editor. Helfer sind im Code definiert und benötigen keinen zusätzlich erstellten oder veröffentlichten Agenten. Wartende Aufgaben behalten ihre Startkonfiguration.

## Vom neuen Dataset zu Ergebnissen { #dataset-workflow }

Fälle dient der Datenvorbereitung, Ergebnisse zeigt Testläufe und Antworten, Einstellungen enthält Bewertung und Helferkonfiguration.

1. **Fälle hinzufügen.** Eine Frage eingeben, eine CSV- oder JSONL-Datei importieren oder Vorschläge zur Prüfung generieren. Du kannst auch eine Antwort aus der Aktivität übernehmen.
2. **Bewertung einrichten.** Regeln, Referenzvergleich oder Kriterien des Bewerters wählen. Einstellungen weist auf Fälle ohne Bewertungsregeln hin.
3. **Agent testen.** Ergebnisse → Testläufe öffnen, einen Agent wählen und die geschätzten Kosten vor dem Start prüfen. Nach dem Einrichten der Bewertung führt eine Schaltfläche unten in der Bewertung unter Einstellungen hierher.
4. **Ergebnisse prüfen.** Antworten und erfüllte oder nicht erfüllte Kriterien prüfen. Abgeschlossene Evals bieten einen direkten Weg zur Überprüfung.

Die Falltabelle zeigt Quellen, Erwartungen und Tags als farbige Etiketten. Eine
Zeile öffnet den Fall; ihr Aktionsmenü enthält Bearbeiten und Löschen. Generierung
und Import bleiben neben Fall hinzufügen sichtbar; Aktivität steht im Menü für weitere Aktionen.

## Was ein Fall enthält { #what-a-case-holds }

| Feld | Was es ist |
|---|---|
| Eingabe | Die Nachricht, die der Agent beantwortet |
| Gespräch vor der Eingabe | Optionale frühere Züge, älteste zuerst. Mit ihnen ist der Fall ein Gesprächsanfang, und der Agent beantwortet dessen letzten Zug |
| Referenzantwort | Was eine gute Antwort sagt |
| Gegenbeispiel | Eine Antwort, die bekanntermaßen falsch ist |
| Erwartete Tool-Aufrufe | Die Tools, die der Agent aufrufen soll, jeweils mit den Argumenten, die passen müssen. Argumente, die ein Fall nicht nennt, werden ignoriert. Ein Fall legt auch fest, wie die Aufrufe abgeglichen werden: `any` in beliebiger Reihenfolge, `in_order` in der angegebenen Reihenfolge mit anderen Aufrufen dazwischen, oder `exact` - genau diese, in dieser Reihenfolge, und keine anderen |
| Prüfungen | Regeln für die Antwort, jede ein Objekt, dessen `type` die Regel benennt, mit deren Parametern daneben. [Bewertung](#checks) listet die Typen auf, und ein Fall mit einem Typ, den es nicht kennt, wird abgelehnt |
| Tags | Labels zum Gruppieren von Ergebnissen, etwa `billing` oder `refusal` |
| Notiz | Warum es den Fall gibt - was schiefging oder was er absichert |
| Quelle | `manual`, `import`, `conversation` oder `synthetic` - von der Plattform gesetzt, nicht eingegeben |

Ein Fall muss sagen, woran seine Antwort gemessen wird: eine Referenzantwort,
ein Gegenbeispiel, ein erwarteter Tool-Aufruf oder eine Prüfung - mindestens
eines davon. Ein Fall nur mit einer Eingabe könnte nie scheitern, deshalb wird er
abgelehnt: Das Formular speichert ihn nicht, die API antwortet mit 422 und nennt
`reference_answer`, und ein Import nennt die Zeile.

Ein guter Fall ist klein: eine Frage und das eine, was eine richtige Antwort
richtig machen muss. Meist genügt eine Referenzantwort oder ein Gegenbeispiel.
Fügen Sie erwartete Tool-Aufrufe hinzu, wenn der Agent handeln statt nur
antworten soll, Prüfungen, wenn sich eine Regel genau angeben lässt, und das
Gespräch vor der Eingabe nur, wenn die Frage davon abhängt. Die Notiz ist für
die nächste Person, die den Fall liest: was schiefging oder was er absichert.
Beim Anlegen Ihres ersten Datasets bietet die Konsole eine geführte Tour an, die
mit dem ersten Fall endet, Feld für Feld.

Ein Fall aus einem Gespräch behält außerdem einen Verweis auf den Run, das
Gespräch und die Nachricht, aus denen er stammt. Frage und Antwort werden in den
Fall kopiert, sodass der Fall vollständig bleibt, nachdem die Aufbewahrung den
Run selbst entfernt hat.

Anhänge sind in dieser Version kein Teil eines Falls. Ein Fall ist Text.

## Jede Änderung ist eine neue Version { #versions }

Einen Fall hinzufügen, bearbeiten oder entfernen, eine Datei importieren und
generierte Fälle annehmen erzeugt jeweils eine neue **Version** des Datasets,
nummeriert ab 1. Eine
Version ändert sich nach ihrem Anlegen nie. Ein bearbeiteter Fall wird als neue
Revision gespeichert, und die Version vor der Bearbeitung enthält weiterhin die
alte.

Das zählt, wenn Sie Ergebnisse vergleichen. Zwei Eval-Runs über dieselbe
Version haben dieselben Fragen gesehen, also kommt ein Unterschied in ihren
Ergebnissen vom Agent und nicht vom Test. Die Dataset-Seite zeigt standardmäßig
die neueste Version; eine ältere wählen Sie in der Versionsliste. Eine ältere
Version ist schreibgeschützt.

Ein Dataset mit **Details bearbeiten** auf seiner Seite umzubenennen oder seine
Beschreibung zu ändern erzeugt keine Version, weil keines von beiden einen Fall
ändert.

Die Versionsliste zeigt die hundert neuesten Versionen; eine ältere öffnen Sie,
indem Sie ihre Nummer eingeben. Eine Version speichert nur,
was sie geändert hat: Ein hinzugefügter oder bearbeiteter Fall ist eine neue
Fallrevision, ein entfernter speichert nichts, daher kostet eine lange
Historie, was sich geändert hat, nicht jeden Fall in jeder Version. Die Datasets
einer Organisation speichern zusammen höchstens
`DATASET_MAX_VERSION_ROWS_PER_ORG` Fallrevisionen (standardmäßig 5 Millionen,
siehe [Konfiguration](configuration.md#datasets)). Ein Hinzufügen oder
Bearbeiten darüber wird abgelehnt und nennt, wie viele gespeichert sind; einen
Fall zu entfernen ist immer erlaubt, und das Löschen eines Datasets gibt seine
Revisionen frei.

### Ungespeicherte Änderungen { #unsaved-changes }

Weil jedes Speichern eine neue Version ist, wird beim Bearbeiten nichts von
selbst gespeichert. Ein Fall, den du schreibst, eine Änderung unter
**Bewertung**, die Details des Datasets und die Auswahl in **Fälle generieren**
bleiben auf dem Bildschirm, bis du sie speicherst. Wenn du vorher gehen willst -
über einen Link, Zurück, das Schließen des Editors, einen anderen Tab oder eine
andere Version des Datasets, eine andere Organisation oder das Abmelden -, fragt
die Konsole, was geschehen soll: **Speichern**, **Verwerfen** oder **Bleiben**.
Speichern wird nur dort angeboten, wo sich die Änderung von dort aus so, wie sie
ist, speichern lässt. Das Schließen oder Neuladen des Browser-Tabs zeigt
stattdessen die Warnung des Browsers selbst.

Ein ungespeicherter Fall oder eine ungespeicherte Änderung der Bewertung wird
außerdem in deinem Browser aufbewahrt, nie auf dem Server. Kommst du zum Dataset
zurück, bietet die Konsole an, die Änderung wiederherzustellen. Hat das Dataset
inzwischen eine neuere Version, sagt sie das und bietet nur das Verwerfen an,
mit einer Möglichkeit zu sehen, was die Änderung war, damit du sie erneut machen
kannst. Die Kopie verschwindet nach dem Speichern oder Verwerfen, beim Wechsel
der Organisation und beim Abmelden. Eine sehr große Änderung wird nicht
aufbewahrt.

## Fälle hinzufügen { #adding-cases }

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

Öffnen Sie **Datasets**, legen Sie ein Dataset an - es öffnet sich, sobald es
existiert - und wählen Sie **Fall hinzufügen**. Schreiben Sie die Eingabe und
mindestens eine der vier Erwartungen oben. Das Gespräch wird Zug für Zug
geschrieben, jeder erwartete Tool-Aufruf als Tool-Name mit seinen Argumenten als
Zeilen aus Name und Wert und jede Prüfung als Typ, aus der Liste gewählt, neben
dem, was sie prüft. **Als JSON bearbeiten** zeigt den ganzen Fall in der Form,
die ein Import enthält.

Fälle öffnen sich in einem Seitenpanel mit dem Nachrichtenlayout des Chats. Zuerst erscheinen die Frage und die gekennzeichnete Referenzantwort; frühere Gesprächszüge lassen sich darüber aufklappen. Agenten- und Referenztexte verwenden den Markdown-Renderer des Chats, entfernte Bilder erscheinen als Links. Tool-Namen lassen sich zu ihren Argumenten aufklappen; Gegenbeispiele, Prüfungen, Notizen und Tags bleiben getrennt. **Bearbeiten** im festen Kopf öffnet das Formular, das die beim Speichern erstellte Version und die Scorer des Datasets nennt. Ein Link auf `?tab=cases&case={case_id}` öffnet einen Fall direkt.

Das Speichern eines neuen Falls, dessen Frage ein Fall bereits stellt - ohne
Rücksicht auf Groß- und Kleinschreibung oder Leerraum -, hält an und sagt das,
mit **Öffnen**, um stattdessen jenen Fall zu lesen, und **Trotzdem
hinzufügen**, um beide zu behalten. Geprüft wird mit
`POST /datasets/{id}/cases/twins`, mit der Frage im Body, damit sie nicht in
Zugriffsprotokollen landet.

### Aus einer Datei { #import-and-export }

**Importieren** liest eine `.csv`- oder `.jsonl`-Datei und fügt alle Fälle darin
als eine neue Version hinzu. Der Import gilt ganz oder gar nicht: Ist eine Zeile
ungültig, wird keine hinzugefügt, und die Ablehnung nennt jede ungültige Zeile,
damit Sie die Datei korrigieren und es erneut versuchen können. Eine Datei ist
höchstens 10 MB groß, und ein Dataset enthält höchstens 10.000 Fälle. In der
Konsole listet **Importieren** zuerst die Spalten auf und bietet **Vorlage
herunterladen** an, eine CSV-Datei mit jeder Spalte und einem Fall, der sich
unverändert importieren lässt; **Datei wählen** öffnet die Dateiauswahl.

Beide Formate verwenden dieselben neun Feldnamen:

| Spalte | In CSV | In JSONL |
|---|---|---|
| `input` | Text. Pflicht | String. Pflicht |
| `history` | Eine JSON-Liste in der Zelle oder leer | Eine Liste von `{"role", "content"}`-Objekten |
| `reference_answer`, `counter_example`, `note` | Text oder leer | String oder `null` |
| `expected_tool_calls` | Eine JSON-Liste in der Zelle oder leer | Eine Liste von `{"tool", "args"}`-Objekten |
| `order_mode` | `any`, `in_order` oder `exact`; leer bedeutet `any` | String |
| `checks` | Eine JSON-Liste in der Zelle oder leer | Eine Liste von Prüfungsobjekten |
| `tags` | Durch Kommas getrennt | Eine Liste von Strings |

Eine CSV-Datei braucht eine Kopfzeile. Andere Spalten als diese neun werden
abgelehnt, damit ein Tippfehler in einem Spaltennamen deren Daten nicht still
verliert. Weggelassene Spalten erhalten ihren leeren Wert. Innerhalb einer Prüfung und in den Argumenten eines Tool-Aufrufs werden die Schlüssel alphabetisch exportiert, nach dem `type` einer Prüfung.

```csv
input,reference_answer,tags
How long is the return window?,30 days from delivery,returns
Can I return a used kettle?,"No, only unused items",returns
```

**Exportieren** lädt die angezeigte Version als CSV oder JSONL herunter. Ein
Export lässt sich unverändert wieder importieren. Damit das auch in einer
Tabellenkalkulation gilt, wird eine CSV-Zelle, die mit `=`, `+`, `-`, `@` oder
`'` beginnt, mit einem vorangestellten `'` geschrieben, damit die Tabelle sie
nicht als Formel ausführt, und ein Import entfernt dieses eine `'` wieder. Der
Export wird im [Audit-Log](governance.md#audit) festgehalten.

### Aus einem Gespräch oder einem Run { #add-to-dataset }

Es gibt zwei Wege, und beide erzeugen denselben Fall:

- **Im Chat** bewerten Sie die Antwort, und die Bewertung entscheidet, als was
  sie behalten wird. Nach einem Daumen nach oben bietet die Bestätigung **Zum
  Dataset hinzufügen** an: Dataset wählen, und die Antwort wird als
  Referenzantwort behalten; die Bestätigung bleibt zehn Sekunden stehen, lange
  genug, um danach zu greifen. Nach einem Daumen nach unten bietet der Dialog,
  der fragt, was schiefging, auch **Diese Antwort zu einem Dataset hinzufügen**
  an: Haken setzen, Dataset wählen und absenden, und die Antwort wird als
  Gegenbeispiel behalten - eine Antwort, die der Agent nicht geben sollte, wie
  der Dialog sagt. Zuerst wird die Bewertung gespeichert, danach der Fall
  angelegt, sodass Ihr Kommentar zur Notiz des Falls wird. Es sind zwei
  getrennte Schreibvorgänge - wird das Hinzufügen abgelehnt, bleibt die
  Bewertung, und die Meldung sagt, welcher Teil fehlschlug. Wird die Bewertung
  später entfernt, bleibt der Fall: Er ist eine Kopie, versioniert mit seinem
  Dataset. Die Konsole merkt sich das zuletzt verwendete Dataset, sodass das
  nächste Hinzufügen ein Klick ist.
- **In Aktivität** hat jede Antwort eines Agents ein Bedienelement **Zum Dataset
  hinzufügen**, einmal, an ihrem letzten Schritt: Eine in Schritten geschriebene
  Antwort - ein Tool-Aufruf, dann der Text - ist ein Fall. Hier werden Antworten
  kuratiert, daher lässt sich eine gute Antwort ebenso leicht als Referenz
  behalten wie eine schlechte als Gegenbeispiel. Gibt es noch kein Dataset zum
  Hinzufügen, legt es eines an, sichtbar für die Organisation; aus **Aus der
  Aktivität hinzufügen** eines Datasets geöffnet, fügt es diesem Dataset hinzu
  und bietet den Weg zurück an.

In beiden Fällen entsteht der Fall aus diesem Zug:

- die Frage wird zur Eingabe, und die Züge davor kommen nur mit, wenn Sie
  **Mit dem Gespräch** wählen. Beide Dialoge im Chat fragen danach - der nach
  dem Daumen nach unten, sobald Sie ihn ankreuzen -, ebenso Aktivität und
  **Score against a Fall**; jeder beginnt mit **Nur diese Frage**, damit ein
  Chat, der mit einem anderen Thema begann, draußen bleibt. Im Chat wird eine
  Frage, die die vorige erkennbar fortsetzt, weil sie mit „und“ oder „was ist
  mit“ anfängt, als Fortsetzung gekennzeichnet, und nach einer Frage ohne
  etwas davor wird nicht gefragt. Über die API gilt dasselbe: `with_history`
  auf `POST /datasets/{id}/cases/from-message` ist false, solange es nicht
  gesendet wird;
- die ganze Antwort des Agents auf die Frage - jeder Schritt, den er vor der
  nächsten Frage schrieb - ist die Antwort, und ihr Text wird zum Gegenbeispiel.
  Hat niemand sie negativ bewertet, wird sie stattdessen als Referenzantwort
  angeboten, und Sie wählen eines von beiden; als Referenz behalten, werden die
  Tools, die sie aufrief, zu den erwarteten Tool-Aufrufen des Falls, nach Namen
  (die erfolgreichen, die etwas ändern, kein gescheiterter Aufruf und keiner,
  den ihr Agent als nur lesend deklariert), und eine Antwort ohne Text wird als
  diese allein behalten;
- der neueste Kommentar zu einem Daumen nach unten wird zur Notiz.

Beide Wege sehen nur Mitglieder, die ein Dataset bearbeiten dürfen. Die
Nachricht muss zu Ihrer Organisation gehören, und Sie müssen sie lesen dürfen:
Entweder Sie haben `runs:view`, womit Sie wie in Aktivität jeden Run der
Organisation lesen, oder Sie können das Gespräch öffnen. Eine Nachricht aus
einer anderen Organisation wird abgelehnt, als gäbe es sie nicht, und eine
Antwort, die bereits ein Fall der neuesten Version des Datasets ist, wird
abgelehnt, statt ein zweites Mal hinzugefügt zu werden. **Zu … hinzugefügt**
nennt das Dataset und öffnet es.

### Vom Fallgenerator { #generating-cases }

**Fälle generieren** öffnet den Dialog direkt unter Fälle. Nach dem Start erscheint die Vorschlagsansicht; beim Abbrechen bleibt die Fallliste geöffnet. Referenzantworten und tatsächliche Antworten unterstützen Markdown und aufklappbare Vorschauen für lange Inhalte. Auf breiten Bildschirmen stehen sie in den Antwortdetails nebeneinander.

Hundert gute Fälle von Hand zu schreiben ist der Grund, warum die meisten Teams
keine haben. Die Aktion **Fälle generieren** auf der Seite eines Datasets, sichtbar für
Mitglieder, die das Dataset bearbeiten dürfen, bittet den Fallgenerator, sie zu entwerfen, und Sie entscheiden, welche das Dataset behält.
Wählen Sie den Agent, den die Fälle testen - den, aus dessen Anweisungen, Tools
und Chats sie geschrieben werden; gegen ihn läuft nichts -, die Quellen und wie
viele Fälle Sie
möchten - höchstens 50 und mindestens einen je Quelle, gleichmäßig auf die
Quellen verteilt:

| Quelle | Was der Generator entwirft | Was er gezeigt bekommt |
|---|---|---|
| Vom Agent | Typische Anfragen und Grenzfälle, mit den Aufrufen von Tools, die etwas ändern, die eine gute Antwort macht - ein Tool, das nur liest, wird nie erwartet, wie bei einem Fall, der aus einer Antwort hinzugefügt wird | Die Anweisungen des Agents, die seiner Skills, die Sie sehen dürfen, und seine Tools, unter den Namen, die der Agent ihnen gibt |
| Aus dem Wissen | Fragen, die seine Wissensbasis beantwortet. Jeder Fall verweist auf das Dokument, aus dem sein Abschnitt stammt, behält den Abschnitt als Referenzantwort und trägt eine `judge`-Prüfung, dass die Antwort zum Abschnitt passt | Abschnitte aus höchstens 12 indexierten Dokumenten der Wissensbasen, die der Agent nutzt und die Sie lesen dürfen |
| Aus Chats | Umformulierungen und schwierigere Varianten dessen, was Menschen den Agent gefragt haben, negativ bewertete Antworten zuerst. Jeder Fall verweist auf die Frage, die er abwandelt | Höchstens 60 Fragen, die dem Agent in dieser Organisation gestellt wurden, mit dem Kommentar zu einer negativ bewerteten Antwort. Nur Betriebsverkehr: Eval-Runs und isoliert gelaufene Runs haben auf einen Test geantwortet, nicht auf einen Menschen, und bleiben außen vor |
| Red Team | Anfragen außerhalb des Zwecks, Prompt-Injections, Versuche, personenbezogene Daten herauszulocken, und Versuche, die Richtlinien des Agents zu umgehen. Jeder Fall hat die Tags `red-team` und `red-team:<Kategorie>` und eine `judge`-Prüfung, dass der Agent ablehnt | Die Anweisungen des Agents, die seiner Skills, die Sie sehen dürfen, und seine Tools |

**Zuerst die geschätzten Kosten.** Der Dialog zeigt, wie viele Fälle jede Quelle
liefern soll, woraus jede schöpft und eine Schätzung der Kosten auf dem eigenen
Modell des Generators, bevor etwas ausgegeben wird - ein bezahltes Modell unter
einem Cent sagt das, statt $0.00 zu zeigen. Es ist eine Schätzung: Das Budget des Generators wird beim Lauf
geprüft, wie das jedes Agents. Wer den Agent, die Quellen oder die Anzahl
ändert, verwirft die Schätzung.

**Nichts gelangt in das Dataset, bevor Sie es annehmen.** Die Entwürfe warten
unter **Vorgeschlagene Fälle** im Generierungsansicht unter Fälle. Nehmen Sie einen
unverändert an, bearbeiten Sie ihn vorher oder verwerfen Sie ihn, einzeln oder
eine Seite auf einmal. Ein Annehmen ist eine neue Version, egal wie viel es
enthielt, und ihre Fälle haben die Quelle `synthetic`. Ein verworfener Entwurf
wird gelöscht und hinterlässt nichts im Dataset. Ein angenommener verschwindet
ebenfalls aus den Entwürfen: Die Version ist sein Nachweis. Ein Entwurf aus Chats
formuliert um, was jemand gefragt hat, deshalb liest und entscheidet ihn nur, wer
Runs ansehen darf; alle anderen, die das Dataset bearbeiten, sehen, wie viele
warten.

**Der Generator ist ein Agent.** Er ist ein Systemagent, der in jeder
Organisation angelegt wird, daher werden seine Runs gegen sein eigenes Budget
und das der Organisation gezählt, und jede Generierung ist ein Run, den Sie in
der [Aktivität](console.md) öffnen können. Er hat keine Tools: Alles, was er
liest, wird mit Ihren eigenen Zugriffsrechten für ihn gesammelt und im Prompt
übergeben, sodass ein Dokument oder ein Gespräch, das ihm Anweisungen geben
will, höchstens den Text eines Entwurfs ändern kann, den Sie prüfen. Ein
Entwurf, der die Regel seiner Quelle nicht einhält - ein Wissensfall ohne einen
Abschnitt, den der Generator bekam, ein Gesprächsfall ohne eine Frage, die er
bekam, ein Red-Team-Fall ohne Kategorie, ein Fall, der nichts erwartet, ein
Fall, dessen Referenzantwort sein Gegenbeispiel wiederholt und damit selbst
durchfallen würde -, wird verworfen, bevor Sie ihn sehen. Ebenso ein Fall in
einer Form, die sich nicht lesen lässt: Der Rest der Antwort wird trotzdem zu
Entwürfen, und nur eine Antwort ohne einen lesbaren Fall schlägt fehl. Eine
abgeschlossene Generierung sagt, wie viele Fälle sie ausgelassen hat, die nicht
lesbaren getrennt von denen, die eine Regel verletzten.

**Jede Quelle hat ihre eigene Schranke**, und eine Quelle, die Sie nicht nutzen
dürfen, wird mit Namen abgelehnt statt stillschweigend ausgelassen:

- jede Generierung braucht `datasets:edit` auf dem Dataset, `agents:view` auf
  dem getesteten Agent und `agents:run` auf dem Fallgenerator, weil sie Geld der
  Organisation ausgibt;
- Wissen liest nur die Wissensbasen, die Sie lesen dürfen; der Dialog sagt, wie
  viele der Wissensbasen des Agents ausgelassen wurden;
- Gespräche brauchen `runs:view`, die Berechtigung, mit der die Aktivität jeden
  Run liest;


Nur Mitglieder, die das Dataset bearbeiten dürfen, sehen seine Entwürfe. Ein
Entwurf aus einem Gespräch ist Text, den die übrigen Leser des Datasets nicht zu
sehen bekommen haben; angenommen ist er ein Fall wie jeder andere.

**Eine Generierung ist ein Hintergrundjob.** Sie wird mit der Anfrage, die sie
startet, in die Warteschlange gestellt und übersteht einen Neustart der API oder
des Workers. Der Worker entwirft als die Person, die gefragt hat, mit ihrem
Zugriff, wie er zu diesem Zeitpunkt ist; eine Generierung, deren Worker
abgestürzt ist, wird als fehlgeschlagen markiert, sodass nichts ewig auf sie
wartet.

Eine mit einem API-Schlüssel gestartete Generierung behält dessen Identität. Vor dem Lesen der Quellen prüft der Worker die aktuellen Berechtigungen des Schlüssels und die Mitgliedschaft des Ausstellers erneut. Ein eingeschränkter Schlüssel erhält keinen Konsolenzugriff; ein widerrufener, abgelaufener oder gelöschter Schlüssel stoppt die Generierung mit einer eindeutigen Fehlermeldung.

### Das Testset eines Agents { #agent-test-set }

`POST /agents/{id}/test-set` erstellt ein privates Dataset für den Agenten oder ergänzt neue bewertete Antworten im vorhandenen bearbeitbaren Satz. Eine positive Bewertung wird zur Referenzantwort, eine negative zum Gegenbeispiel mit dem Kommentar als Notiz. Nur zugängliche Gespräche werden gelesen. Bestehende Fälle und Bewertungseinstellungen bleiben erhalten.

Ein neuer Satz nutzt das Agentenmodell für Bewertung, Generierung und Verbesserung. Das Ergebnis nennt ausdrücklich, wenn Bewerter und Agent dasselbe Modell nutzen. Ein unabhängiges Modell wird unter Bewertung gewählt; weder Preis noch Organisationsvorgabe wählen es. Es entsteht kein zusätzlicher Benutzeragent.

Der Generator fordert Fragen bis zu fünf bewertbaren Fällen oder die angegebene Menge `more` an. Diese Startfälle werden automatisch als neue Dataset-Version angenommen. Weniger als drei bewertbare Fälle werden als unzureichend gemeldet. `/test-set/estimate` schätzt Generierungskosten; beide Aktionen benötigen `datasets:edit` und Agentenzugriff.

## Zugangsdaten werden geschwärzt { #credentials }

Der Text von Fällen wird aus Gesprächen und hochgeladenen Dateien kopiert und
später exportiert und an Modelle übergeben. Bevor ein Fall gespeichert wird,
ersetzt die Plattform jeden erkannten API-Schlüssel und jedes erkannte Token
durch einen Platzhalter wie `[redacted:github_token]`. Das gilt für jedes Feld,
das ein Modell liest oder ein Export enthält, auch für die Argumente eines
erwarteten Tool-Aufrufs, und für jeden Weg, auf dem ein Fall hinzukommt. Der
Audit-Eintrag der Änderung hält fest, wie viele Werte geschwärzt wurden, nie die
Werte selbst.

Eine Generierung schwärzt außerdem die Fragen und Abschnitte, die sie dem
Generator übergibt, bevor sie an das Modell gehen, und nimmt aus den Fragen und
Kommentaren von Menschen die personenbezogenen Daten, die die Detektoren finden
- E-Mail-Adressen, Telefon-, Karten- und Kontonummern -: Einen Fall liest jeder,
der sein Dataset lesen darf.

## Bewertung { #scoring }

Ein Dataset legt auf seinem Tab **Einstellungen** fest, wie seine Fälle bewertet
werden, in zwei gemeinsam gespeicherten Karten: **Wann ein Fall besteht**
enthält Prüfungen und erwartete Tool-Aufrufe; **Bewerter** bestimmt Modell und
Kriterien. Alle bewerteten Antworten erscheinen unter Ergebnisse. Vier Scorer können auf
einen Fall angewendet werden, und jeder wird ein- oder ausgeschaltet und als
**Muss bestehen** markiert oder nicht:

| Scorer | Was er vergleicht | Kosten |
|---|---|---|
| Prüfungen | Die Antwort mit den Regeln des Falls und mit Standardregeln, die das Dataset jedem Fall mitgibt | Keine |
| Erwartete Tool-Aufrufe | Die Tools, die der Agent aufgerufen hat, mit den erwarteten Aufrufen des Falls | Keine |
| Bewerter (**Ihre Kriterien** auf der Karte Bewerter) | Die Antwort anhand einer Rubrik benannter Kriterien, bewertet vom Bewerter des Datasets | Ein Run des Bewerters |
| Referenzantwort | Die Antwort mit der Referenzantwort des Falls, bewertet vom Bewerter des Datasets | Derselbe Run des Bewerters |

Jeder Scorer liefert bestanden oder nicht bestanden, einen Score von 0 bis 1
und eine Begründung. Ein Fall **besteht**, wenn jeder mit „Muss bestehen“
markierte Scorer besteht, und **besteht nicht**, wenn einer von ihnen nicht
besteht. Kam einer von ihnen zu keinem Urteil - der Bewerter war ausgeschaltet,
sein Budget war aufgebraucht, sein Run schlug fehl oder seine Antwort ließ sich
nicht lesen -, ist der Fall **nicht bewertet**: weder bestanden noch nicht
bestanden, weil niemand die Antwort geprüft hat. Der Score sagt, warum, und
lässt sich [erneut bewerten](#judge), sobald die Ursache behoben ist.

Jeder Scorer sagt, wie viele Fälle enthalten, was er liest, und der Tab warnt,
wenn die angezeigte Konfiguration einige Fälle anhand von nichts bewerten
würde. Einem Dataset, dessen Fälle Referenzantworten haben, mit denen nichts
die Antworten vergleicht, wird der Vergleich mit der Referenzantwort angeboten.
Eine Karte mit einer noch nicht gespeicherten Änderung sagt das, eine Leiste
unten am Bildschirm speichert oder verwirft alle Änderungen auf einmal, und die
Seite fragt nach, bevor man sie verlässt.

Die Konfiguration wird nicht mit den Fällen versioniert, weil die Art, wie ein
Team bewertet, nicht das ist, was es fragt. Jeder Score bewahrt eine Kopie der
Konfiguration auf, mit der er berechnet wurde, sodass ein älterer Score auch
nach einer Änderung der Konfiguration noch sagt, wie er zustande kam.

Eine Konfiguration, die nichts bewerten könnte, wird abgelehnt: alle Scorer
ausgeschaltet oder der Bewerter eingeschaltet ohne ein Kriterium. Ebenso die
Bewertung eines Falls, an dem keiner der konfigurierten Scorer etwas zu prüfen
hat - nichts wird gespeichert, und der Bewerter wird nicht aufgerufen.

Über die API ändert `PUT /datasets/{id}/scoring` nur die Einstellungen, die der
Body nennt, auf jeder Ebene: Eine ausgelassene behält ihren Wert, und eine
angegebene Liste - die Kriterien, die Standardprüfungen - ersetzt die
gespeicherte ganz. Die Bestehensgrenze wird nach dem Zusammenführen an der Skala
geprüft, sodass `{"judge": {"pass_at": 8}}` allein auf der gespeicherten Skala
gelesen wird, und eine darüber wird mit Verweis auf `judge.pass_at` abgelehnt.

### Prüfungen { #checks }

| `type` | Parameter | Besteht, wenn |
|---|---|---|
| `contains`, `not_contains` | `value`, optional `path`, `case_sensitive` | Die Antwort den Wert enthält oder nicht enthält |
| `equals` | `value`, optional `path`, `case_sensitive` | Die Antwort ohne umgebende Leerzeichen der Wert ist |
| `regex` | `value` (höchstens 500 Zeichen), optional `path`, `case_sensitive` | Das Muster irgendwo in der Antwort passt |
| `json_schema` | `schema`, optional `path` | Die Antwort JSON ist, das dem JSON Schema entspricht |
| `max_cost_usd` | `value` | Der Run nicht mehr als das gekostet hat |
| `max_latency_ms` | `value` | Der Run nicht länger als das gedauert hat |
| `length` | `unit` (`characters` oder `words`), `min` und/oder `max`, optional `path` | Die Antwort mindestens `min` und höchstens `max` lang ist |
| `judge` | `criterion` | Der Bewerter das Kriterium mit der Bestehensgrenze oder höher bewertet |

`path` liest in eine Antwort hinein, die JSON ist: `items.0.name` ist der Name
des ersten Elements. Ohne ihn liest eine Regel die ganze Antwort. Textregeln
unterscheiden nicht zwischen Groß- und Kleinschreibung, außer `case_sensitive`
ist true.

Ein Muster wird geprüft, wenn der Fall geschrieben wird, und eine Regel liest
höchstens die ersten 100.000 Zeichen einer Antwort. Ein Muster, das auf einer
Antwort länger als eine Zehntelsekunde braucht, wird abgebrochen und als Fehler
festgehalten, damit ein einzelnes Muster das Scoring nicht aufhalten kann. Aus
demselben Grund darf ein JSON Schema weder `pattern` noch `patternProperties`
verwenden - eine `regex`-Prüfung mit `path` leistet dasselbe unter derselben
Frist -, und sein `$ref` muss innerhalb des Schemas zeigen.

Eine `length`-Prüfung zählt als Wort jede Folge von Zeichen, die keine
Leerzeichen sind, und braucht mindestens eine Grenze.

Eine `judge`-Prüfung ist ein Kriterium nur für einen Fall, bewertet im selben
Run des Bewerters wie die Rubrik des Datasets. Verwenden Sie sie für das, was eine Regel
nicht ausdrücken kann, etwa „lehnt ab und verrät die Adresse des Kunden nicht“.

### Erwartete Tool-Aufrufe { #trajectory }

Die Aufrufe des Agents werden mit den erwarteten Aufrufen des Falls nach
Tool-Name und nach jedem Argument abgeglichen, das der Fall nennt. Der
Reihenfolgemodus des Falls entscheidet, was besteht: Mit `any` hat jeder
erwartete Aufruf stattgefunden; mit `in_order` fanden sie in der aufgeführten
Reihenfolge statt; mit `exact` sind sie die einzigen Aufrufe und in dieser
Reihenfolge. Die Begründung nennt, was fehlte, was nicht erwartet war oder dass
die Reihenfolge abwich. Ein Schreibvorgang, den ein isolierter Run blockiert
hat, zählt weiterhin als Aufruf, den der Agent gemacht hat.

Ein Aufruf wird über den Tool-Namen abgeglichen, den der Run aufgezeichnet hat,
also den Namen nach einer etwaigen Überschreibung im Spec. Ein Fall, der vor der
Umbenennung eines Tools geschrieben wurde, erwartet den alten Namen.

### Der Bewerter { #judge }
Der Bewerter ist ein im Code definierter Evaluierungshelfer. Modell, Anweisungen, Kriterien, Skala und Bestehensgrenze gehören zum Tab **Einstellungen** dieses Datasets. Modellauswahl und Markdown-Editor entsprechen Agent Builder. Bearbeiten benötigt `datasets:edit`, das Hinzufügen eines Modells `connections:manage`. Ein separater Agent muss weder erstellt noch veröffentlicht werden.

Jeder Score behält Modell, veröffentlichte Helferidentität, Kriterienhash, Aufgabenversion und Anweisungshash. Dataset-Modell und Anweisungen dürfen geändert werden; Bewertungen unterschiedlicher Konfigurationen sind nicht unmittelbar vergleichbar.

Der Bewerter erhält die Notiz des Falls als Grund, warum es den Fall gibt, seine
früheren Züge und die Frage, die Referenzantwort, wenn sie bewertet wird, das
Gegenbeispiel, jeden Tool-Aufruf des Agenten - mit seinen Argumenten und ob ein
isolierter Run ihn blockiert hat - und die Antwort.

Ein Fall mit Gegenbeispiel wird immer auch nach dem erforderlichen Kriterium
**counter-example** bewertet: Die Antwort darf die bekannte schlechte Antwort
nicht wiederholen, und der Bewerter soll zitieren, was die Antwort von ihr
unterscheidet. Es wird bewertet, sobald **Ihre Kriterien** oder die
Referenzantwort eingeschaltet ist, und hat daher keinen eigenen Schalter; die
Karte Bewerter zeigt, wie viele Fälle ein Gegenbeispiel haben.

Ein Bestehen des Kriteriums counter-example ist
ein Fehler, wenn es nur zitiert, was beide
sagen, oder nichts aus einer Antwort zitiert, die das Gegenbeispiel kopiert;
jedes andere ohne Zitat bleibt stehen, als nicht belegt markiert. Eine Antwort,
die das Gegenbeispiel behält und ergänzt, was ihm fehlte, besteht mit einem
Zitat der Ergänzung. Eine Antwort, die das Gegenbeispiel ist oder ein Teil
davon, fällt bei dem Kriterium durch, was auch immer der Bewerter sagte.

Bewerter starten mit Temperatur 0, damit dieselbe Antwort zweimal gleich
bewertet wird; ein Modell, das keine Temperatur annimmt, etwa ein
Reasoning-Modell, bewertet ohne sie.

Jedes Kriterium wird von 1 bis zum oberen Ende der Skala bewertet und besteht
ab der Bestehensgrenze. Für jedes Kriterium zitiert der Bewerter die Stelle der
Antwort, auf der seine Bewertung beruht, und nennt die Regel, aus der sie
folgt. Eine Bewertung, deren Begründung überwiegend aus den Worten des
Kriteriums besteht, ohne ein Zitat, das die Antwort enthält, ist ein Fehler:
Nichts zeigt, dass der Bewerter die Antwort gelesen hat. Eine Höchstnote ohne
Zitat aus der Antwort bleibt bestehen und wird als nicht belegt markiert.

Ein Bewerter bewertet eine Ja-oder-Nein-Frage am beständigsten, deshalb schlägt
der Kriterien-Editor vor, jedes Kriterium als solche zu formulieren, und die
Skala des Bewerters bietet **Ja/Nein-Benotung verwenden** an, eine Skala von 2,
die bei 2 besteht. Ein Kriterium, das eine Regel prüfen kann - eine Länge,
gültiges JSON, ein in Anführungszeichen genannter Anfang, eine Aufzählung -, sagt
das, und **Regel hinzufügen** fügt diese Prüfung zu denen hinzu, die jeder Fall
bekommt: Sie kosten nichts und bewerten jedes Mal gleich. Der Vorschlag liest die
Worte des Kriteriums selbst und ruft kein Modell auf.

Kann der Bewerter nicht bewerten, werden seine Kriterien als übersprungen oder
als Fehler festgehalten, mit einer Begründung, die die Ursache nennt:
der vom Dataset gewählte Bewerter existiert
nicht mehr, er hat keine veröffentlichte Version, er ist archiviert, sein
Modell ist entfernt oder hat keinen Schlüssel, die Person darf ihn nicht
ausführen, sein Budget ist aufgebraucht, sein Run schlug fehl oder seine
Antwort ließ sich nicht lesen - deren erste 2.000 Zeichen bleiben dann neben der
Begründung. Die regelbasierten Scorer bewerten trotzdem.

Ist die Ursache behoben, bewertet **Erneut bewerten** an einem nicht bewerteten
Ergebnis - oder an allen in der Gruppe eines Eval-Runs auf dem Tab Prüfung -
dieselbe Antwort neu, mit der Konfiguration, mit der sie zuerst bewertet wurde
(`POST /datasets/{id}/scores/rescore`, bis zu zehn Scores pro Anfrage). Der
Agent läuft nicht erneut, und der Score behält seinen Eval-Run und jede
Entscheidung, die eine Person darüber getroffen hat; einer, bei dem jeder
Scorer zu einem Urteil kam, bleibt, wie er ist.

Eine Ursache, die noch besteht - Bewerter nicht
veröffentlicht -, wird so abgelehnt, wie sie ist, ebenso der Bewerter eines
Eval-Runs, der seit seinem Fehlschlag neu veröffentlicht wurde, oder ein
Ergebnis eines solchen Runs, das an einen früheren Bewerter-Prompt gebunden ist,
dessen Bewertung sich nicht mit dem Rest des Runs vergleichen ließe; dann wird
nichts bewertet.

Eine für sich bewertete Antwort, aus dem Chat oder aus **Aktivität**, hat keinen Run,
mit dem sie sich vergleichen müsste: Sie wird von der jetzt veröffentlichten
Version bewertet, und ihr Pin nennt diese Version. Ein Ergebnis wird gebunden,
ob sein Bewerter bewertet hat oder gescheitert ist, also bleibt ein
gescheitertes an die Version und den Prompt gebunden, mit denen es scheiterte.

Eine Bewertung darf die Antwort zitieren, bis zu 12 Stellen; ein Zitat, das die
Antwort nicht wörtlich enthält - abgesehen von Leerraum, der Art der
Anführungszeichen und Apostrophe sowie den umschließenden Anführungszeichen und
dem Satzzeichen am Ende des Zitats -, wird neben der Bewertung als nicht
verifiziert aufbewahrt und in einer eigenen Zeile unter der Begründung angezeigt,
und die Bewertung bleibt bestehen.

Was eine Bewertung stützt, macht sie nie ungültig: Ein leeres oder zu langes
Zitat wird verworfen, Zitate über zwölf und eine Regel über 300 Zeichen werden
gekürzt, und nur eine fehlende Kriteriums-ID oder Note macht ein Urteil
unlesbar. Ein mehrfach bewertetes Kriterium ist ein Fehler, nicht die zuletzt
gekommene Note. Der Run des Bewerters in **Aktivität** nennt die Felder, die sich
nicht lesen ließen, nie die Antwort selbst, die einen Fall eines Datasets
wiederholen kann, das sein Leser nicht sehen darf.

Jeder Score behält Modell, veröffentlichte Helferidentität, Kriterienhash, Aufgabenversion und Anweisungshash. Dataset-Modell und Anweisungen dürfen geändert werden; Bewertungen unterschiedlicher Konfigurationen sind nicht unmittelbar vergleichbar.

### Prüfung { #review }
Prüfung zeigt alle bewerteten Antworten in einer Tabelle mit Frage, Agent, Ergebnis, Modell, Datum und Quelle. Eine gewählte Antwort öffnet Evidenz, Bewertung und Entscheidung im Seitenpanel. Speichern hält das Panel offen und die Zeile an ihrer Position; Entscheidungen lassen sich zurücknehmen oder rückgängig machen. Ändert der Server die Datenschutzmaske, werden Panel und ungespeicherte Notiz verworfen.

Ein Score wartet in der **Warteschlange zur Prüfung**, wenn jemand ihn dorthin
schickt oder ein Eval-Run es tut. Hat er erneut ausgeführt, was gekippt ist,
schickt ein Eval-Run die Regressionen, die er bestätigt hat, und die Antworten,
an denen der Bewerter mit einem Fehler scheiterte - nicht die, die er
übersprungen hat und die auf eine erneute Bewertung warten - ein Score pro Fall
und Agent.
Seine Seite schickt weitere Scores, die Sie auswählen, alle auf einmal über
`POST /datasets/{id}/scores/review` mit bis zu 500 Score-IDs - alle oder keine.

Die Antworten jedes Agents auf einen Fall warten für sich: Ein dorthin
geschickter Score, von einem Eval-Run oder von Hand, nimmt den Platz eines noch
wartenden Scores desselben Falls und Agents ein, wenn er höher rangiert oder
gleich rangiert und neuer ist, und der Score eines anderen Agents für den Fall
wartet daneben.

Ein bewerteter Score - eine Regression oder ein von Hand geschicktes Fail -
rangiert über einem, den nichts bewertet hat, etwa einem Fehler des Bewerters,
sodass ein scheiternder Bewerter die Regression eines Falls nie verdrängt. Der
ersetzte verlässt die Warteschlange unentschieden und bleibt ein Score; sonst
behält der wartende seinen Platz, und der geschickte wird nicht eingereiht. Ein
entschiedener Score wird nie angetastet.

Ein Score, der von Hand aus **Aktivität** angefordert wurde, folgt der Einstellung
**Prüfung durch eine Person** des Datasets: nichts, bis jemand einen schickt,
jedes Ergebnis, das nicht bestanden hat, oder jedes Ergebnis. Ein bereits
entschiedener Score bleibt entschieden. Ein solcher Score, und einer, dessen
Entscheidung zurückgenommen wird, durchläuft dieselbe Ersetzung, sodass ein Fall
nie zweimal für einen Agent wartet.

Die Ansicht **Ergebnisse → Antworten prüfen** zeigt sofort alle Ergebnisse, auch bereits geprüfte. Filter betreffen Ausgang, Agent und Fall-Tag; der Prüfstatus teilt die Liste nicht. Jede Zeile verlinkt bei entsprechender Berechtigung zum Eval-Run. Aktionen über der Tabelle können unbewertete Antworten erneut bewerten oder wartende aus der Warteschlange nehmen (`POST /datasets/{id}/scores/review/withdraw`).

Jede Karte zeigt, was der Fall gefragt und erwartet hat - die Frage, mit einem
Link zum Fall, die Referenzantwort, die erwarteten Tool-Aufrufe und die
Prüfungen -, die bewertete Antwort, Agent und Version, die geantwortet haben -
mit einer Warnung, wenn der Bewerter auf dem Modell bewertet hat, das
geantwortet hat, da ein Bewerter Antworten wie seine eigenen bevorzugen kann -,
was jeder Scorer gefunden hat und warum, die nicht bestandenen zuerst, und die
Prüfentscheidung, die sich in der Meldung, die sie bestätigt, rückgängig machen
lässt.

Die Notiz zu einer Entscheidung ist oft die Regel, die der Bewerter übersehen
hat, daher bietet die Karte an, sie zu einem Kriterium des Bewerters zu machen:
nur für diesen Fall, als Prüfung `judge` in einer neuen Version des Datasets,
oder für jeden Fall, in der Rubrik, was den Bewerter einschaltet.

Die Dashboard-Karte **Wartet auf Prüfung** zeigt die Warteschlange über alle
Datasets, die Sie sehen können: wie viele Ergebnisse nicht bestanden haben,
nicht bewertet wurden oder bestanden haben, und in welchen Datasets, jedes
öffnet sich auf seinem Tab Prüfung. Die Karte ist standardmäßig auf dem
Dashboard. **Alle ansehen** öffnet den Tab Prüfung des Datasets, in dem am
meisten wartet.

Die Prüfentscheidung einer Person wird neben den Ergebnissen der Scorer
gespeichert und entscheidet über das Ergebnis. Sie ändert nie, was der Bewerter
gesagt hat: Die Bewertungen und Begründungen des Bewerters bleiben am Score,
nachdem er überstimmt wurde. Eine Prüfentscheidung kann zurückgezogen werden,
und der Score wartet dann wieder auf eine Prüfung.

### Einen Run bewerten { #scoring-a-run }

Öffnen Sie in **Aktivität** einen Run, öffnen Sie sein Menü **⋯** und wählen Sie
**Gegen einen Fall bewerten**. Der Dialog öffnet sich auf einem Dataset mit
einem Fall, der die Frage des Runs selbst stellt, und wählt diesen Fall aus;
haben mehrere Datasets einen, sagt er das und führt sie zuerst auf. Hat das
gewählte Dataset keinen, bietet der Dialog an, die Antwort des Runs als Fall
hinzuzufügen, bis Sie einen Fall wählen, und führt die Fälle, die der Frage des
Runs am nächsten sind, zuerst auf - die, die die meisten ihrer Wörter teilen,
auf der angezeigten Seite.

Die Antwort und die Tool-Aufrufe des Runs werden mit jedem Scorer bewertet, den das Dataset konfiguriert. Ein Run
ohne Transkript hat keine Antwort, die sich bewerten ließe.

Der Dialog nennt den Bewerter, der bewerten wird, und das Modell, auf dem er
bewertet, mit Links, um den Bewerter des Datasets in seinem Tab Bewertung und
das Modell des Bewerters auf seiner Seite zu ändern - beides gilt für jede
danach bewertete Antwort, daher wird keines davon im Dialog geändert.

| Um | Brauchen Sie |
|---|---|
| Zu ändern, wie ein Dataset bewertet wird | `datasets:edit` darauf |
| Einen Bewerter dafür anzulegen | `datasets:edit` darauf und `agents:edit` |
| Einen Run dagegen zu bewerten | `datasets:run` darauf und `runs:view` |
| Seine Scores zu lesen | `datasets:view` darauf |
| Scores zur Prüfung zu schicken, eine Prüfentscheidung festzuhalten oder zurückzuziehen | `datasets:edit` darauf |

Eine Begründung, die der Bewerter geschrieben hat, durchläuft vor dem Speichern
dieselbe Schwärzung von Zugangsdaten wie ein Fall.

Damit ein Agent jeden Fall einer Version in einem Durchgang beantwortet, jede
Antwort bewertet und das Ergebnis mit einer früheren Version verglichen wird,
starte einen [Eval-Run](evals.md).

## Zugriff { #access }

Ein Dataset ist eine geteilte Ressource mit Besitzer, Sichtbarkeit und Grants,
wie ein [Skill](skills.md) oder eine [Context-Datei](context.md). Ein neues
Dataset sieht die ganze Organisation, außer der Ersteller legt es von Anfang
an als privat an; später ändert man das auf seiner Seite. Der Katalog hat drei
Berechtigungen für Datasets:

| Berechtigung | Erlaubt einem Mitglied | Grant-Stufe, die sie gibt |
|---|---|---|
| `datasets:view` | Fälle und Versionen eines Datasets lesen und exportieren | `read` |
| `datasets:edit` | Datasets anlegen, Fälle ändern, importieren, löschen, freigeben | `edit` |
| `datasets:run` | Evals über ein Dataset ausführen, mit `runs:view` | `use` (nicht mehr angeboten, siehe unten) |

| | Owner | Admin | Builder | Operator | Member | Viewer |
|---|---|---|---|---|---|---|
| `datasets:view` | all | all | all | all | shared | shared |
| `datasets:edit` | all | all | shared | - | own | - |
| `datasets:run` | all | all | all | all | shared | - |

Ein Eval zu starten erfordert vor allem `runs:view`: Ein Run kostet Geld, und
wer ihn nicht lesen darf, darf ihn nicht starten. Jede eingebaute Rolle, die
Runs liest, hat `datasets:run` bereits in der ganzen Organisation, und ein
Member, dessen `datasets:run` nur geteilte Datasets erreicht, liest keine Runs.
Ein `use`-Grant auf ein Dataset ließe niemanden ein Eval starten, das er ohne
ihn nicht starten könnte, deshalb bietet die Freigabe für ein Dataset nur Lesen
und Bearbeiten an; `use` kommt mit benutzerdefinierten Rollen zurück.

Ein früher erteilter `use`-Grant bleibt bestehen und bewirkt nichts; seine Zeile
sagt das, und er lässt sich entfernen. Wer ein Dataset ausführen darf, aber
keine Runs lesen, sieht auf seiner Seite Run evals deaktiviert, mit dem Hinweis,
dass Runs lesen nötig ist; wer es gar nicht ausführen darf, bekommt es nicht
angeboten. Siehe [Eval-Runs](evals.md#access).

Ein Mitglied ohne Zugriff auf ein Dataset erhält auf jeder Route „nicht
gefunden“, gleich was seine Rolle anderswo erlaubt - ob ein privates Dataset
existiert, ist selbst etwas, das es nicht erfahren darf. Ein Grant erweitert den
Zugriff auf ein Dataset und ändert nie eine Rolle. Wie Scopes und Grants
zusammenwirken, steht unter [Berechtigungen](permissions.md).

Den Text eines aus einer Unterhaltung kopierten Falls sehen nur Leser mit `runs:view` oder Zugriff auf die Quellunterhaltung. Andere sehen Metadaten und einen Platzhalter, sowohl in aktuellen und historischen Versionen als auch in CSV/JSONL-Exporten. Eine fehlende Quelle gibt den Text nicht frei. Verborgener Text kann nicht bearbeitet und durch Metadatenänderungen nicht offengelegt werden. Evals führen weiterhin die vollständige gespeicherte Revision aus.

Antworten, Prüfungsnotizen und Bewertungsbelege benötigen `runs:view` und Zugriff auf den antwortenden Agenten. Fehlt eines davon, bleiben Ergebnis und Status sichtbar, aber Antworttext, Begründungen, Regeln und Zitate werden entfernt. Vor dem Kopieren einer fremden privaten Unterhaltung nennt der Dialog deren Eigentümer und warnt, dass Dataset-Leser mit Leserecht für Runs den Text sehen werden.

## Personenbezogene Daten { #personal-data }

Ein Fall aus einem Gespräch ist eine Kopie dessen, was eine Person geschrieben
und der Agent geantwortet hat. Wird das Gespräch gelöscht, bleibt der Fall, und
jede Verbindung zurück zum Gespräch wird entfernt: der Run, das Gespräch und die
Nachricht, aus denen er stammt. Der Text bleibt und kann weiterhin
personenbezogene Daten enthalten, die jemand eingegeben hat. Das Löschen des
Falls entfernt ihn.

Wird die Person gelöscht, die die Frage eines Falls gestellt hat, geht auch der Text. Die
Frage, die früheren Züge, beide Antworten und die Notiz werden in jeder Version
ersetzt, die den Fall enthält, und ebenso die Antworten und Aufrufe, die
Eval-Runs für ihn aufgezeichnet haben. Der Fall behält seine Id, seine
erwarteten Aufrufe, seine Prüfungen und seine Tags und wird als **Nach Löschung
anonymisiert** markiert, damit sein Kurator ihn umschreiben oder entfernen kann.
Bis dahin lässt ein Eval-Run ihn aus, denn eine Antwort auf den Platzhalter misst
nichts.

Ein Fall hält fest, wessen Worte er enthält: wer seine Frage gestellt hat, wer
jeden seiner früheren Züge geschrieben hat und wessen Kommentar zu seiner Notiz
wurde. Das wird nie angezeigt oder exportiert und überdauert das Gespräch,
sodass eine Löschung den Fall auch dann noch findet, wenn das Gespräch, aus dem
er stammt, gelöscht wurde. Ein Fall, dessen Frage jemand anderes gestellt hat,
behält Frage und Antwort: Die Züge der gelöschten Person in seinem früheren
Verlauf werden ersetzt, mit den Antworten des Agents darauf, und ihr als Notiz
aufbewahrter Kommentar wird geleert.

Bei einem Fall, der geschrieben wurde, bevor die Urheberschaft festgehalten
wurde, wird sie aus den Verbindungen ergänzt, die er noch hatte; einer, dessen
Gespräch schon gelöscht war, hat keine, und nur das Löschen des Falls entfernt
seinen Text. Siehe
[Datenschutz](data-protection.md#what-deletion-reaches).

Ein Score wird auf dieselbe Weise aufbewahrt. Er enthält eine Kopie der
bewerteten Antwort, bis zu 8.000 Zeichen mit geschwärzten Zugangsdaten, damit
ein Prüfer sie neben dem Fall liest. Diese Kopie ist im Export der Person
enthalten, deren Run es war, und wird entfernt, wenn diese Person gelöscht wird.
Wird der Run entfernt, den er bewertet hat, bleibt der Score ohne die Verbindung
zu ihm, und wird die Person gelöscht, die ihn angefordert oder entschieden hat,
wird ihr Name aus ihm entfernt. Die Begründung eines Bewerters kann die Antwort
zitieren, die er bewertet hat.

Ein generierter Fall, der noch auf eine Entscheidung wartet, wird nicht so
aufbewahrt. Wird das Gespräch gelöscht, aus dem er entworfen wurde, oder die
Person gelöscht, die die Frage gestellt hat, wird der Entwurf mit gelöscht:
Niemand hat entschieden, ihn zu behalten. Der Datenexport einer Person enthält
die Entwürfe aus ihren Fragen und Gesprächen. Eine Generierung aus Gesprächen
schickt die gestellten Fragen, geschwärzt, an den Modellanbieter des
Fallgenerators, und eine Generierung aus dem Wissen schickt Abschnitte der
Dokumente - siehe
[was das Deployment verlässt](data-protection.md#what-leaves-the-deployment).