# Erstellen Sie einen KI-Trainingsdatensatz aus Ihren vorhandenen Dokumenten

Sammeln Sie freigegebene Supporttickets oder Dokumente und erstellen Sie daraus einen überprüfbaren JSONL-Datensatz mit Quellenangaben, Duplikatprüfungen und getrennten Evaluierungs-Splits.

Canonical page: https://beeuni.ai/blog/de/build-ai-training-dataset-jsonl

Mit Ihren bisherigen Support-Anfragen könnten Sie ein Modell zur Klassifizierung neuer Anfragen trainieren. Doch Fragen und Antworten sind über viele Tickets verteilt. Beeuni kann die ausgewählten Gespräche sammeln, daraus beschriftete Beispiele erstellen und nach fehlenden Feldern und Duplikaten suchen. Sie prüfen unklare Labels und erhalten einen JSONL-Datensatz: eine JSON-Datenstruktur pro Zeile, mit Verweisen auf die ursprünglichen Tickets.

## Legen Sie das gewünschte Verhalten fest, bevor Sie das Dateiformat wählen

Angenommen, Sie möchten ein Modell entwickeln, das eingehende Anfragen klassifiziert. Jedes Beispiel benötigt eine Anfrage und eine freigegebene Kategorie. Wenn Antworten auf einem Handbuch beruhen sollen, braucht ein Beispiel eine Frage, den dazugehörigen Text und eine geprüfte Antwort. Aus jedem Absatz eine Frage zu machen, stellt nicht sicher, dass die Antworten korrekt oder nützlich sind.

Verbinden Sie den Dienst, in dem die Inhalte liegen, oder geben Sie dem Agenten Zugriff auf das Dokumentations-Repository. Beginnen Sie mit einer benannten Sammlung oder einem bestimmten Zeitraum. Geben Sie bei öffentlich zugänglicher Dokumentation die Website und die einzubeziehenden Bereiche an. Lassen Sie den Agenten vor der Prüfung der ersten Beispiele die gesammelten Quellen und alle Seiten auflisten, die er nicht lesen konnte.

## Bearbeiten Sie zuerst eine kleine Aufgabe zur Beschriftung

Stellen Sie sich ein fiktives Supportteam vor, das einen Klassifikator für Anfragen vorbereitet. Es benötigt vier Labels: Abrechnung, Kontozugriff, Produkthilfe und Prüfung erforderlich. Über einen autorisierten Support-Connector liest der Agent geschlossene Tickets aus einem vereinbarten Zeitraum. Erfassen Sie nur die Felder, die für die Beschriftung und die Quellenzuordnung nötig sind, und lassen Sie Kontaktdaten sowie nicht zugehörige Anhänge weg. Die Warteschlange, an die ein Ticket weitergeleitet wurde, gibt nicht unbedingt sein richtiges Label an: Ein Mitarbeiter der Abrechnungsabteilung kann eine weitergeleitete Frage zum Login beantwortet haben.

Speichern Sie im Computer eine Kopie der Quelle zusammen mit den Ticketverweisen, der Auswahlregel und dem Erfassungszeitpunkt. Führen Sie die Umwandlung anhand dieser Kopie aus, damit ein Ticket, das mitten in der Prüfung bearbeitet wurde, die Beispiele nicht unbemerkt verändert. Der Agent kann die Extraktions- und Validierungsskripte schreiben und ausführen und anschließend Datensatz, Skripte und Prüfbericht gemeinsam bereitstellen.

Beginnen Sie mit Anfragen, die kurze Nachrichten, längere Unterhaltungen und mehrere Anliegen umfassen. Legen Sie fest, welche Informationen bei der Vorhersage als Eingabe vorliegen werden. Wenn das Modell nur die erste Nachricht des Kunden erhält, nehmen Sie die spätere Lösung nicht in die Trainingseingabe auf. Andernfalls lernt es aus Informationen, über die Ihre Anwendung bei einer neuen Anfrage nicht verfügen wird.

| Fiktive Anfrage | Vorgeschlagenes Label | Entscheidung zur Beschriftung |
| --- | --- | --- |
| Mir wurde diesen Monat der Betrag zweimal berechnet. | Abrechnung | Reklamation zu einer Abbuchung |
| Die E-Mail zum Zurücksetzen kommt nicht an. | Kontozugriff | Die Anfrage betrifft die Anmeldung |
| Ich kann mich nicht anmelden, um vor meiner nächsten Verlängerung zu kündigen. | Prüfung erforderlich | Legen Sie fest, welche Absicht Vorrang hat |
| Das funktioniert immer noch nicht. | Prüfung erforderlich | Zu wenig Kontext für eine Klassifizierung |

Legen Sie die Regel für die dritte Zeile fest, bevor Sie den Agenten bitten, den Rest zu beschriften. Sie könnten Anfragen nach dem unmittelbaren Hindernis weiterleiten oder alle Anfragen mit konkurrierenden Anliegen zur Prüfung schicken. Beide Vorgehensweisen können sinnvoll sein. Werden sie von verschiedenen Annotatoren vermischt, entstehen uneinheitliche Beispiele, aus denen das Modell lernen soll.

## Nutzen Sie Meinungsverschiedenheiten, um den Beschriftungsleitfaden zu verbessern

Lassen Sie zwei Prüfer dieselbe kleine Stichprobe unabhängig voneinander beschriften. Bewahren Sie ihre ursprünglichen Labels und die endgültige Entscheidung auf. Halten Sie bei Abweichungen den Grund fest: fehlender Kontext, überschneidende Kategorien oder ein Beschriftungsfehler. Ein Agent kann diese Fälle in einer Prüfdatei zusammenstellen, doch die für den Arbeitsablauf verantwortliche Person sollte die Weiterleitungsregel festlegen.

Wenn eine Entscheidung den Beschriftungsleitfaden ändert, überprüfen Sie frühere Beispiele, auf die diese Regel zutrifft. Beim fiktiven Klassifikator wird die Kündigungsanfrage unter Kontozugriff eingeordnet, wenn das „unmittelbare Hindernis“ maßgeblich ist. Weitere Nachrichten, in denen Anmeldeprobleme und Zahlungen zusammenkommen, müssen nun genauso behandelt werden. Wird nur die strittige Zeile korrigiert, bleibt der ältere Widerspruch bestehen.

Halten Sie Quellnachrichten getrennt von synthetischen Varianten. Eine Anfrage zehnmal umzuformulieren, kann helfen, unterschiedliche Formulierungen abzudecken, fügt aber nicht zehn unabhängige Situationen hinzu. Wenn Sie Varianten erzeugen, dokumentieren Sie das zugehörige Ausgangsbeispiel und prüfen Sie, ob die Bedeutung erhalten bleibt. Schon eine kleine Änderung von „wurde abgebucht“ zu „wird abgebucht“ kann das beabsichtigte Label verändern.

## Führen Sie ein Prüfprotokoll, bevor Sie Trainingsdatensätze erstellen

Verwenden Sie ein Zwischenschema, in dem jede Quelle neben dem zugehörigen Beispiel erhalten bleibt. Ein fiktiver Prüfdatensatz für einen Frage-Antwort-Datensatz könnte so aussehen. Frage und Antwort in Ihrem Datensatz müssen aus Ihren eigenen geprüften Materialien stammen.

```
{"id":"sample-001","source":"sample-handbook.txt","section":"Opening hours","question":"When does the desk open?","answer":"The desk opens at 9 a.m.","review_status":"pending","split":"unassigned"}
```

Dies ist ein Arbeitsschema und kein Payload für eine Trainings-API. Wandeln Sie die freigegebenen Datensätze nach der Prüfung in das von Ihrem Trainingstool verlangte Format um. Bewahren Sie Quellenverweise und Prüfentscheidungen in einer Begleitdatei auf, falls das Tool nur Nachrichten oder Eingabe-Ausgabe-Paare akzeptiert.

## Geben Sie dem Agenten ausführbare Prüfungen vor

- **Struktur:** Jede JSONL-Zeile parsen und die erwarteten Felder sowie Werttypen verlangen.
- **Quellen:** Überprüfen, ob jedes Beispiel auf eine vorhandene Quelle und einen vorhandenen Abschnitt verweist.
- **Duplikate:** Normalisierten Text vergleichen und nahezu identische Einträge gesondert prüfen. Ähnliche Formulierungen können trotzdem unterschiedliche Sachverhalte beschreiben.
- **Datenschutz:** Nach personenbezogenen Informationen und Zugangsdaten suchen und markierte Datensätze vor dem Export prüfen.
- **Abdeckung:** Beispiele je Kategorie zählen und Kategorien mit wenig oder ganz ohne geprüftes Material auflisten.

Ein Skript kann prüfen, ob ein Quellenverweis existiert. Es kann nicht nachweisen, dass eine Antwort aus der Quelle hervorgeht. Prüfen Sie die Antworten, auch bei Beispielen mit fehlendem Kontext oder widersprüchlichen Textstellen. Halten Sie erzeugte Vorschläge getrennt von freigegebenen Datensätzen.

## Denselben Fall nicht zugleich zum Trainieren und Testen verwenden

Legen Sie fest, was die Evaluierung messen soll. Wenn Sie die Leistung bei bisher ungesehenen Dokumenten prüfen möchten, müssen alle Beispiele aus einem Dokument im selben Split bleiben. Beschreiben mehrere Dateien denselben Fall, gruppieren Sie stattdessen nach Fall. Bei einer zufälligen Aufteilung von Zeilen kann eine nahezu identische Kopie einer Evaluierungsantwort im Training landen.

Fordern Sie train.jsonl, validation.jsonl, ein Quellenmanifest und einen Validierungsbericht an. Der Bericht sollte die Anzahl der Datensätze, abgelehnte Datensätze, Duplikatgruppen und die Aufteilungsregel enthalten. Wenn der Datensatz diese Prüfungen besteht, können Sie Beeuni bitten, [auf Ihrem verbundenen Trainingscomputer ein Fine-Tuning-Experiment auszuführen](/blog/de/run-model-fine-tuning-with-beeuni).

Für den Klassifikator umfasst eine brauchbare Übergabe neben den JSONL-Dateien auch die Labeldefinitionen, die Eingabefelder und die Regel für mehrdeutige Anfragen. Fügen Sie das Vorbereitungsskript samt Einstellungen hinzu, damit andere Entwickler die Umwandlung nachvollziehen können. Dokumentieren Sie, aus welcher Quellstichprobe der Export stammt: Ein Dateiname wie final.jsonl sagt Prüfern nicht, was sich seit dem letzten Export geändert hat.

Wenn die Quelle als Tabelle vorliegt, behandelt der [Leitfaden zur CSV-Bereinigung](/blog/de/clean-messy-csv-without-losing-rows) Kennungen und fehlende Werte. Um die Vorbereitung von Datensätzen über eine eigene Benutzeroberfläche anzubieten, beginnen Sie mit dem [SDK-Leitfaden](/docs/de/sdk).