Wenn das Modell JSON liefern soll
- Matt
Die unangenehmste Stelle beim Arbeiten mit Sprachmodellen ist die Rückgabe. Man bittet um JSON, bekommt JSON, und beim vierzigsten Aufruf steht davor „Gerne! Hier ist das JSON:” und das Ganze in einem Markdown-Block.
Der übliche Umgang damit sind reguläre Ausdrücke, die die geschweiften Klammern herausschneiden. Das funktioniert, bis ein Textfeld selbst eine Klammer enthält.
Der bessere Weg
var antwort = await client.GetResponseAsync<Rechnungsdaten>(
"Extrahiere Betrag, Datum und Rechnungsnummer aus diesem Text: ...");
Rechnungsdaten daten = antwort.Result;
public sealed class Rechnungsdaten
{
public required decimal Betrag { get; init; }
public required DateOnly Datum { get; init; }
public string? Rechnungsnummer { get; init; }
}
Die generische Überladung erzeugt aus dem Typ ein JSON-Schema, schickt es mit und deserialisiert die Antwort. Beim Anbieter, der das unterstützt, ist das keine Bitte, sondern eine Einschränkung: Das Modell kann gar kein anderes Format erzeugen.
Zusammen mit required bekommt man dabei gleich die Prüfung mit, ob alle Pflichtfelder da sind.
Bei lokalen Modellen
Hier wird es unbequemer. Ollama kann ein Schema entgegennehmen, aber die Umsetzung hängt am Modell. Kleinere Modelle halten sich an die Struktur und füllen sie mit Unsinn, was schlimmer ist als ein Formatfehler: Ein Formatfehler fällt auf, ein plausibler falscher Wert nicht.
Zwei Dinge helfen. Erstens die Temperatur weit herunter, wie schon beim Modelfile beschrieben. Zweitens das Schema klein halten. Drei Felder gehen zuverlässig, fünfzehn nicht. Wenn viel zu extrahieren ist, lieber mehrere Durchgänge.
Was bleibt
Auch mit erzwungenem Schema ist der Inhalt nicht geprüft. Das Datum ist ein gültiges Datum, aber nicht zwingend das aus dem Dokument. Eine Plausibilitätsprüfung danach ersetzt das Schema nicht, sondern ergänzt es.
Bei Beträgen prüfe ich inzwischen immer gegen den Ausgangstext, ob die Zahl dort überhaupt vorkommt. Das hat mehr Fehler gefunden als jede Anpassung am Prompt.