Konfiguration für die Erstellung von Aufträgen zur Erzeugung unstrukturierter synthetischer Daten

Sie haben verschiedene Optionen, um die Generierung unstrukturierter synthetischer Daten anzupassen. Unabhängig davon, ob Sie die Aufträge über die Benutzeroberfläche oder über die API zur Generierung synthetischer Daten watsonx.ai erstellen, haben Sie Zugriff auf dieselben Einstellungen.

Konfiguration des Data Builders

Jeder Datenersteller hat spezifische Anforderungen an Saatgutdaten und Referenzdokumente. Sie können zum Beispiel mehrere Dateien als Referenzdokumente für den Knowledge Data Builder verwenden. Der Text to SQL Data Builder verwendet jedoch keine Referenzdokumente.

Die Registerkarte Data builder configuration führt Sie durch die Anforderungen der Benutzeroberfläche.

Um Ihre API-Anfrage zu konfigurieren, lesen Sie die folgenden Ressourcen:

Allgemeine Konfiguration und erweiterte Einstellungen für den Generator

Über die erweiterten Einstellungen des Generatormodells können Sie verschiedene Optionen für die Erzeugung unstrukturierter synthetischer Daten konfigurieren. Sie können beispielsweise festlegen, wie Tokens ausgewählt werden und welches LLM als Generatormodell verwendet werden soll.

Tabelle 1. Allgemeine Einstellungen und Generatoreinstellungen
Feld Name in der Benutzeroberfläche Typ Standard Zulässige Werte Beschreibung
num_outputs_to_generate Anzahl der zu generierenden Zeilen Ganzzahl 10 Bereich: 1value1000 Dieser Parameter bestimmt die Menge der zu erzeugenden synthetischen Daten. Wenn Sie mit verschiedenen Modellen experimentieren möchten, können Sie diesen Parameter auf 10 setzen, um die Menge der erzeugten synthetischen Daten während des Tests zu reduzieren.
overwrite_output_file Ausgabedatei überschreiben boolesch false true
false
Dieser Parameter legt fest, ob eine vorhandene Ausgabedatei bei der Ausführung des Auftrags überschrieben wird. Wenn diese Option auf false (Standard) gesetzt ist, gibt der Auftrag einen Fehler zurück, falls bereits eine Ausgabedatei mit demselben Namen vorhanden ist. Wenn diese Option aktiviert ist true, wird die vorhandene Datei überschrieben.
model_id Modell-ID Zeichenfolge ibm/granite-3-8b-instruct Siehe Unterstützte Modelle Das Modell, das für die Erzeugung von Token verwendet wird.
temperature Temperatur Glättekelle 0.5 Bereich: 0.05value2 Mit diesem Parameter wird die Wahrscheinlichkeitsverteilung für das nächste Token eingestellt, wodurch das Gleichgewicht zwischen Kreativität und Determinismus bei der Texterstellung gesteuert wird. Niedrigere Werte (≤ 0.3 ) verengen die Verteilung, was die Zufälligkeit verringert und zu einem gezielteren, wiederholbaren Ergebnis führt. Höhere Werte (≥ 0.7 ) verbreitern die Verteilung und ermöglichen vielfältigere und kreativere Antworten, wenn auch manchmal auf Kosten der Genauigkeit.
max_new_tokens Maximale Anzahl an Token pro „ QnA “-Paar Ganzzahl 1024 Jeder Wert über min_new_tokens Dieser Parameter legt eine harte Obergrenze für die Anzahl der in einer Antwort erzeugten Token fest, was übermäßig lange Ausgaben verhindert. Eine Verringerung des Wertes kann hilfreich sein, wenn die Antworten länger ausfallen als erwartet.
min_new_tokens Mindestanzahl an Token pro „ QnA “-Paar Ganzzahl 100 Jeder Wert über 50 Dieser Parameter legt die Mindestanzahl der Token fest, die das Modell generieren muss, um zu verhindern, dass es zu früh aufhört.
top_p top_p Glättekelle 0.9 Bereich: 0 < value1 Dieser Parameter bestimmt den Pool von Token-Kandidaten für das nächste generierte Token. Das Modell berechnet die Wahrscheinlichkeiten für alle möglichen nächsten Token, sortiert sie nach Wahrscheinlichkeit und wählt dann die kleinste Menge von Token aus, deren kumulative Wahrscheinlichkeit mindestens p beträgt. Höhere Werte ( 0.9 ) bedeuten, dass weniger wahrscheinliche Token enthalten sind, was zu einem vielfältigeren und kreativeren Ergebnis führt.
top_k top_k Ganzzahl 50 Bereich: 1value100 Dieser Parameter legt fest, wie viele Token als Kandidaten für das nächste generierte Token in Betracht gezogen werden. Bei jedem Schritt wird der Pool der Token-Kandidaten auf die k wahrscheinlichsten Optionen begrenzt. Wenn zum Beispiel k = 50 ist, berechnet das Modell die Wahrscheinlichkeiten für alle möglichen nächsten Token und sortiert sie nach Wahrscheinlichkeit. Von dieser Rangliste der Token werden nur die 50 wahrscheinlichsten Token berücksichtigt. Der Rest wird ignoriert. Kleinere Werte führen zu besser vorhersehbaren Ergebnissen. Höhere Werte sorgen für mehr Vielfalt. Ein mittlerer Wert (50) trägt dazu bei, Vielfalt und Relevanz in Einklang zu bringen.

Unterstützte Modelle

Sie können wählen, welches Modell Sie für die Erzeugung der synthetischen Daten verwenden möchten. Für Projekte und Bereitstellungsumgebungen ist das folgende Multi-Tenant-Modell für die Verwendung mit dem Dienst „ Synthetic Data Generator “ zur Generierung unstrukturierter synthetischer Daten zertifiziert:

  • ibm/granite-3-8b

In Bereitstellungsbereichen können Sie Modelle auch bei Bedarf über den Resource Hub bereitstellen. Synthetic Data Generator kann jedes Modell verwenden, das für Aufgaben im Bereich Text-Chat und Textgenerierung geeignet ist. Modelle, die als empfohlene Modelle gekennzeichnet sind, wurden einer Leistungsbewertung mit Synthetic Data Generator unterzogen. Ihre Leistung liegt innerhalb der internen Leistungsgrenzwerte, und sie erzielen in der Regel bessere Ergebnisse hinsichtlich des Token-Verbrauchs, was den Token-Verbrauch und die Kosten senken kann. Die Leistung von Modellen, die nicht empfohlen werden, kann im Laufe der Zeit schwanken und wird nicht garantiert.

Weitere Informationen zur Bereitstellung von Modellen nach Bedarf finden Sie unter Bereitstellung Foundation-Modelle nach Bedarf.

Um in einer Curl-Anfrage auf das Modell zu verweisen, verwenden Sie die deployment_id des Modells, sobald Sie das Modell in Ihrem Bereitstellungsbereich bereitgestellt haben. Zum Beispiel: "model_id": "892abdf9-21e1-4314-80b0-a235c805895d".

Erweiterte Einstellungen des Validators

Die erweiterten Einstellungen legen fest, wie Synthetic Data Generator die von ihm generierten Token auswertet. Diese Einstellungen steuern die Konfiguration der Validierungsmodelle. Sie können Einstellungen wie das für die Validierung zu verwendende LLM sowie die Kriterien für die Annahme oder Ablehnung von Tokens anpassen.

Tabelle 2. Validierungseinstellungen
Feld Name in der Benutzeroberfläche Typ Standard Zulässige Werte Kommentare
type Wird in der Benutzeroberfläche nicht verwendet Zeichenfolge Keine llm_judge
rouge_scorer
Sie können bis zu ein llm_judge und ein rouge_scorer Validierungsmodell konfigurieren, die im Rahmen desselben Auftrags für den Knowledge Data Builder verwendet werden sollen. Alle anderen Daten-Builder können nur ein rouge_scorer Validierungsmodell verwenden.
filter Wird in der Benutzeroberfläche nicht verwendet boolesch Ja true
false
Dieses Flag wird nur in Skripten verwendet. Hiermit wird festgelegt, ob ungültige Messwerte entfernt werden.
threshold Schwellenwert (Parameter des De-Duplikators) Glättekelle 0.9 Jeder Wert zwischen 0 und 1 Legt den Ähnlichkeitswert fest, anhand dessen der ROUGE-Scorer entscheidet, wann zwei Ergebnisse als Duplikate gelten. Das Modell verwendet das Rouge-L-Bewertungsverfahren, um die Ähnlichkeit zu bestimmen. Ein Datensatz wird verworfen, wenn sein ROUGE-L-Wert über diesem Wert liegt. Wird der Wert auf 0 gesetzt, werden alle „ QnA “-Paare als ungültig behandelt, wodurch keine Ausgabe erfolgt. Bei der Einstellung 1 werden keine Duplikate entfernt. Bei
Verwendung des threshold Feldes wird immer ein rouge_scorer Validierungsmodell hinzugefügt.
lm_config Validierungsmodell Strukturierte Immobilie Gleiches Modell wie der Generator model_id Jedes unterstützte Foundation-Modell top_kmodel_idKonfigurieren Sie das LLM, das für das llm_judge Validierungsmodell verwendet werden soll.
Sie können, temperature, max_new_tokens min_new_tokens, top_p, und festlegen.
Hinweis: Wenn Sie für die Validierung und die Generierung unterschiedliche Modelle verwenden, kann sich die Ablehnungsrate für Token erhöhen.

Arten von Validator-Modellen

Die Modelle, die Sie zur Validierung auswählen, lassen sich einer der folgenden Kategorien zuordnen:

LLM als Richter
Bei LLM-as-Judge-Modellen wird ein LLM eingesetzt, um die generierten synthetischen Daten zu bewerten. Diese Art von Modellen nutzt KI-basierte Schlussfolgerungen und Inferenzverfahren, um die Ähnlichkeit synthetischer Daten auf semantischer Ebene zu ermitteln. Diese Modelle können mehr als nur exakte Wörter und Wortgruppen abgleichen. Sie können die Bedeutung ähnlicher Wörter prüfen, um festzustellen, ob es Überschneidungen gibt.
Da dieses Modell auf KI-basierten Schlussfolgerungen und Inferenzverfahren beruht, ist es weniger deterministisch und kann bei jeder Ausführung zu unterschiedlichen Ergebnissen führen.
Dieses Validierungsmodell steht nur für den Wissensdaten-Generator zur Verfügung.
ROUGE-Torschütze
Ein ROUGE-Scorer-Modell eignet sich zur Bewertung der Überlappung in den generierten synthetischen Daten. Es verwendet die Rouge-L-Bewertungsmethode, bei der die längste gemeinsame Teilfolge zur Bestimmung der Ähnlichkeit herangezogen wird. Bei dieser Methode werden lange Wortfolgen verglichen, die in den zu vergleichenden Ausgaben vorkommen, und anschließend wird eine Punktzahl ermittelt, die davon abhängt, wie viele Wörter in beiden Ausgaben vorkamen.
Da dieses Modell eine bestimmte Bewertungsmethode verwendet, ist es deterministisch und liefert konsistente Ergebnisse. Allerdings achtet es auf exakte Übereinstimmungen zwischen Textzeichenfolgen, sodass es weniger effektiv ist, wenn Textzeichenfolgen eine ähnliche Bedeutung haben, aber unterschiedliche Wörter verwenden.

Muster anfordern

Mit dem folgenden Befehl wird eine Anforderung zum Erstellen eines Auftrags zur Erzeugung unstrukturierter synthetischer Daten übermittelt. Die Kopfzeile von curl ist für alle Datenersteller gleich:

curl -X POST \
  'https://api.<region>.dai.cloud.ibm.com/v2/synthetic_data/generation/unstructured' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer eyJraWQiOi...' \
  --data @payload.json

Sie können eine separate JSON-Datei verwenden, z. B. payload.json, um den Request Body mit den Konfigurationsdetails für den Auftrag zu übergeben. Die JSON-Datei kann sich je nach Data Builder und der Einstellung, die Sie konfigurieren möchten, ändern. In der Regel hat sie die folgende Struktur:

{
    "project_id": "<ID of the project to create the job in>",
    "name": "<Name of the job that you want to create>",
    "description": "<Description for the job>",
    "configuration": {
        "pipeline": "<data builder>",
        "num_outputs_to_generate": <A value between 1 to 1000>,
        "overwrite_output_file": false,
        "generator": {
            "model_id": "<LLM. For example ibm/granite-3-8b. For models deployed on demand, this is the deployment_id>",
            "temperature": 0.5,
            "max_new_tokens": 1024,
            "min_new_tokens": 100,
            "decoding_method": "sample",
            "top_p": 0.9,
            "top_k": 50
        },
        "validators": [            
            {
                "type": "rouge_scorer",
                "filter": true,
                "threshold": 0.9
            },
            {
                "type": "lm_judge",
                "lm_config": {
                    "model_id": "<LLM. For example ibm/granite-3-8b."
                }
            }
        ],
        "seed_data_reference": {
            "type": "container",
            "location": {
                "path": "<Input YAML file name in project assets. For example qna_know_seed.yaml>"
            }
        },
        "knowledge_base_references": [
            {
                "type": "container",
                "location": {
                    "path": "<File name for reference documents. For example origins_*.pdf>"
                }
            },
            {
                "type": "container",
                "location": {
                    "path": "<File name for additional reference documents. For example education-at-ibm.md>"
                }
            }
        ],
        "results_reference": {
            "type": "container",
            "location": {
                "path": "<Unique file name for the generated data output in project assets. For example sdg-output-knowledge-1.jsonl>"
            }
        }
    },
    "job": {
        "schedule": "0 0 1 * *",
        "schedule_info": {
            "repeat": true,
            "startOn": 1547578689512,
            "endOn": 1547578689512
        }
    }
}