Der Auftrag an ein Modell: so geschrieben, dass man das Ergebnis prüfen kann

Angenommen, jemand sagt in der Besprechung: „Ich hab die Rechnung dem Modell gegeben, es sagt 725 Euro.“ Die Frage, die dann gestellt werden müsste, lautet nicht, ob die Zahl stimmt. Sie lautet: Woran würde man merken, dass sie nicht stimmt? Wenn die Antwort darauf „man rechnet es nach“ ist, hat das Modell keine Arbeit gespart. Ob man es merkt, entscheidet sich nicht am Modell, sondern am Auftrag.

Danach weißt du:

• welche fünf Bausteine einen Auftrag prüfbar machen, und aus welchen unserer eigenen Aufträge sie stammen
• was sie an einem kleinen Modell bewirken, gezählt in 300 Läufen über drei Aufgaben
• in welchem Fall der ausgebaute Auftrag weniger richtige Antworten brachte als der knappe, und warum er trotzdem der bessere war

Prüfbar heißt: in Sekunden nachsehen, ohne die Arbeit zu wiederholen

Ein Ergebnis ist prüfbar, wenn ein Programm oder ein Mensch es gegen das Material halten kann, ohne die Aufgabe selbst noch einmal zu lösen. Eine Rechnungsnummer mit der Zeile, aus der sie stammt, ist prüfbar: Man sucht die Zeile im Dokument und sieht, ob sie dort steht und ob sie die richtige ist. Eine Rechnungsnummer allein ist es nicht. Man müsste die Rechnung öffnen und selbst suchen.

Das ist kein Feinschliff. Wer einen Ablauf ohne Aufsicht laufen lässt, braucht genau diese Eigenschaft, denn sonst gibt es nur zwei Möglichkeiten: alles nachrechnen, oder allem glauben.

Woher die Bausteine kommen

Wir haben keine Prompt-Sammlung durchgesehen, sondern unsere eigenen Aufträge. Im Newsletter steht in jeder Ausgabe ein Abschnitt „Der eine Satz“. In Ausgabe 01 zum Rechnungseingang lautet er: Miss die Trefferquote je Feld, nicht je Rechnung. Im Fließtext davor steht der Fehler, der dazu geführt hat: Ein Beispiel in der Anweisung, „RE-2026-0042“, hat dem Modell beigebracht, aus der Rechnungsnummer 5470 ein „RE-5470“ zu machen. In Ausgabe 02 zum CSV-Bericht lautet er: Bevor du summierst, zeig mir alle vorkommenden Kategorien mit Anzahl. Dazu kommen die Aufgabenübergabe AUFTRAG.md aus dem Paket zum CSV-Bericht und die Extraktionsanweisung aus dem Paket zum Rechnungseingang.

Fünf Dinge kehren darin wieder:

• Format festlegen. Feste Zeilenanfänge oder JSON mit festen Schlüsseln, und kein Text davor oder danach. Was ein Programm nicht lesen kann, kann es nicht prüfen.
• Kategorien vor Summen. Erst jeden Wert, nach dem gruppiert wird, wörtlich und mit Anzahl. Dann die Bestandteile mit Zeilennummer. Die Summe rechnet ein Programm.
• Fundstelle verlangen. Zu jedem Wert die Zeile, aus der er stammt, wörtlich abgeschrieben.
• Unsicherheit mit fester Formulierung. Eine vorgegebene Antwort für den Fall, dass etwas fehlt, etwa UNKLAR, und der ausdrückliche Satz, dass sie richtig ist.
• Abgrenzen, auch im Beispiel. Zu jedem Feld sagen, was es nicht ist, und zwar genau die Nachbarn, die im Dokument danebenstehen. Beispiele nur mit Platzhaltern.

Und eines gehört ausdrücklich nicht hinein, auch das steht in AUFTRAG.md: wie das Programm aussehen soll. Ein Auftrag beschreibt das Ergebnis und die Prüfung, nicht den Weg.

Derselbe Auftrag, zweimal geschrieben

Für die Rechnung sieht der knappe Auftrag so aus, wie man ihn ohne Nachdenken stellt:

Lies aus der folgenden Rechnung die Rechnungsnummer, das Rechnungsdatum und den Bruttobetrag aus.

Der ausgebaute hat dieselbe Aufgabe und vier der fünf Bausteine. Gekürzt auf das Wesentliche:

- bruttobetrag: der Gesamtbetrag der Rechnung einschließlich Umsatzsteuer, so geschrieben wie im Text,
  zum Beispiel 1.234,56. Nicht der Betrag nach Skonto, nicht der Zahlbetrag nach Abzug einer Anzahlung,
  nicht der Nettobetrag.

Fundstelle: Schreib zu jedem Feld die Zeile aus dem Rechnungstext ab, in der der Wert steht,
wörtlich und vollständig.
Fehlt ein Feld im Text, ist der Wert NICHT GEFUNDEN und die Fundstelle leer. Rate nicht.

Antworte nur mit diesem JSON, ohne Text davor oder danach:
{"rechnungsnummer": {"wert": "<Wert>", "fundstelle": "<Zeile wörtlich>"}, ...}

Das Beispiel im Format enthält mit Absicht keinen echt wirkenden Wert, sondern Platzhalter. Das ist die Lehre aus „RE-5470“.

Die Messung

Drei Aufgaben, alle mit erfundenen Daten, die ein Skript im Paket erzeugt:

• Rechnung: sechs Rechnungstexte, fünf davon mit einer Falle (Kundennummer neben der Rechnungsnummer, Lieferdatum vor dem Rechnungsdatum, Skontobetrag, Nummer ohne Präfix, abgezogene Anzahlung). Gesucht: Nummer, Datum, Bruttobetrag.
• Export: drei Umsatzexporte, zwei mit Summenzeile, einer mit Gutschrift. Gesucht: der Gesamtumsatz.
• Termin: sechs Kundenmails, drei mit Kalenderdatum, drei ohne („so bald wie möglich“, „Anfang November“, „nach den Herbstferien“). Gesucht: der gewünschte Termin.

Jede Aufgabe einmal knapp und einmal ausgebaut, jeder Fall zehnmal, das sind 300 Anfragen an llama3.2 mit 3 Milliarden Parametern, lokal über Ollama, am 4. Oktober 2026. Temperatur 0,8 und die Laufnummer als Seed, damit zehn Läufe nicht zehnmal dasselbe ergeben und trotzdem wiederholbar sind.

Gezählt wird viermal. Richtig: Stimmt die Antwort? Beim knappen Auftrag haben wir wohlwollend gelesen; es reicht, wenn der richtige Wert in der letzten Zeile mit der passenden Bezeichnung steht, egal in welchem Satz. Prüfung: Ein Programm hält die Antwort gegen das Dokument, ohne die Lösung zu kennen. Das geht nur beim ausgebauten Auftrag. Für die Rechnung ist das der Kern:

if wert.strip().upper() == "NICHT GEFUNDEN":
    hinweise.append(f"{feld}: NICHT GEFUNDEN, an Mensch")
elif not fund:
    hinweise.append(f"{feld}: Fundstelle leer")
elif fund not in dok_eng:
    hinweise.append(f"{feld}: Fundstelle steht nicht wörtlich im Text")
elif not wert_in_fundstelle(feld, wert, fund):
    hinweise.append(f"{feld}: Wert steht nicht in der Fundstelle")
elif not any(z in fund and wert_in_fundstelle(feld, wert, z) for z in dok_zeilen):
    hinweise.append(f"{feld}: Fundstelle ist keine vollständige Zeile mit dem Wert")

Prüfbar richtig heißt: richtig, und die Prüfung hat bestanden oder den Fall als UNKLAR an einen Menschen gegeben. Durchgerutscht heißt: falsch, und nichts hat es gemeldet. Beim knappen Auftrag ist jede falsche Antwort durchgerutscht, weil es nichts gibt, wogegen ein Programm sie halten könnte. Das ist eine strenge Lesart; ein Mensch, der jede Antwort liest, fände einen Teil davon. Aber dann liest eben ein Mensch jede Antwort.

Was herauskam

Das ist die Übersicht, wie messe.py sie am 4. Oktober 2026 ausgegeben hat:

Aufgabe   Auftrag     Läufe  richtig  prüfbar richtig  falsch, gemeldet  falsch, durchgerutscht  richtig, gemeldet
rechnung  knapp          60       22                –                 –                      38                  –
                     je Feld: rechnungsnummer 45/60, rechnungsdatum 52/60, bruttobetrag 25/60
rechnung  ausgebaut      60       47               43                 7                       6                  4
                     je Feld: rechnungsnummer 52/60, rechnungsdatum 60/60, bruttobetrag 55/60
export    knapp          30       12                –                 –                      18                  –
export    ausgebaut      30        7                0                23                       0                  7
termin    knapp          60       60                –                 –                       0                  –
termin    ausgebaut      60       38               27                22                       0                 11

Zusammengezählt: Richtig waren 94 von 150 knappen und 92 von 150 ausgebauten Antworten. Fast gleich. Unbemerkt falsch waren 56 knappe und 6 ausgebaute. Das ist der eigentliche Befund, und er liegt nicht dort, wo man ihn erwartet. Die Bausteine haben das Modell im Ganzen nicht besser gemacht. Sie haben seine Fehler sichtbar gemacht. Je Aufgabe sieht das sehr verschieden aus.

Rechnung: deutlich besser, und die Fundstelle hat eine Grenze

Hier haben die Bausteine gewirkt, von 22 auf 47 richtige Rechnungen. Je Feld gezählt, wie Ausgabe 01 es verlangt, liegt der Unterschied fast ganz beim Bruttobetrag: 25 von 60 gegen 55 von 60. Unsere Fallen waren dabei gar nicht das Problem. Den Skontobetrag und den Zahlbetrag nach Anzahlung hat das Modell beim knappen Auftrag kein einziges Mal genommen. Es hat in 16 von 60 Läufen den Nettobetrag als Bruttobetrag genannt. Der Halbsatz „nicht der Nettobetrag“ im ausgebauten Auftrag hat das behoben.

Der knappe Auftrag wurde außerdem oft missverstanden. In 30 von 60 Läufen begann die Antwort als Fehlersuche, etwa mit „Die falschen Informationen in der Rechnung sind:“, obwohl niemand nach Fehlern gefragt hatte.

Sechs falsche Rechnungen sind trotz Prüfung durchgerutscht, und fünf davon haben dieselbe Ursache. Bei der Rechnung mit Lieferschein hat das Modell die USt-ID als Rechnungsnummer ausgegeben, mit wörtlich richtiger Fundstelle:

{"rechnungsnummer": {"wert": "DE305512640", "fundstelle": "USt-IdNr.: DE305512640"}, ...}

Die Prüfung sagt: Die Zeile steht im Dokument, der Wert steht in der Zeile. Beides stimmt. Die Fundstelle beweist, dass ein Wert im Dokument steht, nicht, dass es das richtige Feld ist. Ein Mensch sieht „USt-IdNr.“ in einer Sekunde, ein Programm, das nur Zeichen vergleicht, sieht es nicht. Wir vermuten, dass unser eigener Auftrag beteiligt war: Er schließt die Lieferscheinnummer aus, und in dieser Rechnung tragen Lieferschein und Rechnung dieselbe Nummer 88123. Gemessen haben wir das nicht.

Export: der Baustein, den das kleine Modell nicht geschafft hat

Hier ist der ausgebaute Auftrag schlechter: 7 richtige gegen 12. Er verlangt drei Schritte, Kategorienliste, Zeilen ohne Buchung, Buchungen mit Betrag, und llama3.2 hat das nicht hinbekommen. In 18 von 30 Läufen kamen keine lesbaren Buchungszeilen zurück, sondern Tabellen mit Platzhaltern oder Zusammenfassungen je Kunde. In den übrigen 12 fehlte eine lesbare Kategorienliste, also genau der Schritt, um den es ging. Kein einziger Lauf hat alle Prüfungen bestanden. Weil die Prüfung jede dieser Antworten gemeldet hat, ist nichts durchgerutscht, aber das ist ein schwacher Trost, wenn alles beim Menschen landet.

Der knappe Auftrag hat 12 von 30 richtig, und die Fehler sind lehrreich: Den Fehler aus dem CSV-Beitrag, die Summenzeile mitzuzählen, hat das Modell nicht gemacht; kein Ergebnis lag beim Doppelten. Es hat sich verrechnet, um einen Euro, um die weggelassene Gutschrift, einmal um die Hälfte zu viel. Jede dieser Zahlen steht am Ende eines ordentlichen Rechenwegs und sieht plausibel aus.

Termin: weniger richtig, und trotzdem kein einziger unbemerkter Fehler

Das ist der Fall, der sich umgedreht hat. Der knappe Auftrag war 60 von 60 richtig. Wo kein Datum in der Mail stand, hat das Modell in ganzen Sätzen geantwortet: „Der Kunde möchte, dass das Fenster … Anfang November installiert wird.“ Das ist richtig, aber es ist ein Satz, den jemand lesen muss.

Der ausgebaute Auftrag gibt eine Zeile TERMIN vor, und das kleine Modell hat sie gefüllt, auch wenn es nichts zu füllen gab. Bei „Anfang November“ kam in keinem von zehn Läufen UNKLAR, sondern Daten wie 01.11.2024 oder 04.11.2024; insgesamt waren es 22 erfundene Daten in 30 Läufen ohne Datum. Der Satz „UNKLAR ist eine richtige Antwort“ hat das nicht verhindert. Was es aufgefangen hat, war die Fundstelle:

TERMIN: 01.11.2024
FUNDSTELLE: „Wir würden den Einbau gern Anfang November machen lassen, die genaue Woche stimmen wir noch mit dem Mieter ab.“

Das Programm sucht das Datum in der Fundstelle und findet es nicht. Alle 22 erfundenen Daten hat die Prüfung gemeldet, 19 aus genau diesem Grund, 3, weil die Fundstelle so nicht in der Mail stand. Weniger richtige Antworten, aber jede falsche fällt auf.

Was daraus für die eigene Arbeit folgt

• Schreibt den Auftrag auf die Prüfung hin, nicht auf die Antwort. Die Frage beim Schreiben ist: Was muss in der Antwort stehen, damit ich sie in fünf Sekunden gegen das Material halten kann?
• Fundstelle und festes Format zuerst. Diese zwei haben in unserer Messung die meisten Fehler sichtbar gemacht, quer über alle drei Aufgaben.
• Abgrenzung nach den Fehlern, die wirklich passieren. Unsere ausgedachten Fallen hat das Modell umgangen; den Nettobetrag hat es genommen. Lasst den knappen Auftrag einmal über zehn echte Fälle laufen und schreibt dann hinein, was es nicht ist.
• Bei kleinen Modellen eine Aufgabe je Auftrag. Drei Schritte in einem Auftrag waren für ein Modell mit 3 Milliarden Parametern zu viel.
• Lest die einzelnen Fehler, nicht nur die Zählung. Sechs durchgerutschte Fälle waren fünfmal derselbe.

Was das nicht kann

• Es sagt nichts über große Modelle. Ein Modell mit dreißig- oder hundertfacher Größe hält das dreistufige Format vermutlich ein und erfindet seltener ein Datum. Gemessen haben wir das nicht; das Skript nimmt jedes Ollama-Modell über MODELL.
• Die Prüfung ist mechanisch. Sie erkennt Werte, die nicht im Dokument stehen, und Werte, die nicht zur Fundstelle passen. Sie erkennt nicht das falsche Feld mit der richtigen Zeile. Dafür braucht es eine Stichprobe von Hand.
• 15 erfundene Fälle sind wenige. Die Fälle sind nach echten Unregelmäßigkeiten gebaut, aber es sind unsere. Mit euren eigenen Dokumenten kann das Verhältnis anders ausfallen, auch umgekehrt.

Zum Nachbauen

Das Paket zu diesem Beitrag enthält die Bausteine, alle sechs Aufträge, das Messskript, die Testdaten und alle 300 Antworten. Entpacken, dann:

• BAUSTEINE.md: die fünf Bausteine mit Herkunft, Zweck, Grenze und je einem Satz zum Übernehmen
• auftraege/: rechnung, export und termin, je knapp und ausgebaut; der erste text-Block ist der Auftrag
• messe.py: schickt beide Fassungen an ein Modell über Ollama und zählt richtig, prüfbar richtig, gemeldet und durchgerutscht; mit --nur-auswerten ohne Modell über die vorhandenen Antworten
• erzeuge_testdaten.py und testdaten/: sechs Rechnungen, drei Exporte, sechs Mails, alle erfunden, mit den Lösungen
• rohausgaben/: jede der 300 Antworten mit Auftrag, Lauf, Seed, Dauer und Bewertung, dazu die Übersicht aus diesem Beitrag

Stand dieses Artikels

Gebaut und gemessen am 4. Oktober 2026 mit llama3.2 (3,2 Milliarden Parameter) über Ollama 0.32.15 auf einem Mac, Python 3.12.2, Temperatur 0,8, Seed gleich Laufnummer, höchstens 1.024 Token je Antwort, zehn Läufe je Fall und Auftrag. Alle Zahlen in diesem Beitrag stammen aus diesem Lauf und der Auswertung mit der Fassung von messe.py, die im Paket liegt. Die Testdaten sind erfunden; Firmen, Personen und Beträge gibt es nicht. Nicht geprüft: andere oder größere Modelle, andere Temperaturen, echte Rechnungen, Exporte und Mails, die Vermutung zur Lieferscheinnummer bei der USt-ID-Verwechslung, und ob der dreistufige Export-Auftrag in zwei getrennten Aufträgen besser läuft. Die Bewertung des knappen Auftrags ist absichtlich wohlwollend; eine strengere hätte ihn schlechter aussehen lassen.

Häufige Fragen