# Klassifikation und Extraktion > Die häufigsten Produktionsaufgaben sauber spezifizieren: Labels über ihre Grenzen definieren, menschliche Übereinstimmung als Obergrenze messen, eine Restklasse mit Kennzahl führen, Beispiel-Schieflagen entschärfen — und bei Extraktion Treue vor Vollständigkeit stellen. Track: [Prompt Engineering](https://physar.tech/learn/prompt-engineering) Kanonische Fassung: https://physar.tech/learn/prompt-engineering/classification-extraction Stand: 2026-09-04 Interaktiver Teil: 9 Checks (nur im Browser) ## Klassifikation und Extraktion ### Die unspektakulären Arbeitspferde Der größte Teil des Produktionsvolumens in LLM-Systemen sind zwei unauffällige Aufgaben: **Klassifikation** — ordne diese Eingabe einer von n Kategorien zu — und **Extraktion** — hol diese Felder aus diesem Dokument. Kein Reasoning, kein Dialog, hohe Stückzahl, enge Marge. Genau diese Nüchternheit macht sie interessant. Beide Aufgaben sind **messbar**: Es gibt eine richtige Antwort, man kann sie zählen, und Verbesserungen sind belegbar. Und beide haben eine kleine Zahl wiederkehrender Fehlerquellen, die fast nie am Modell liegen — sondern an der Taxonomie, an den Beispielen oder an einer fehlenden Fallunterscheidung. > **Merksatz:** Klassifikation und Extraktion sind die Aufgaben, bei denen ein Prompt-Autor am schnellsten lernt, ob er sein Handwerk beherrscht — weil das Ergebnis eine Zahl ist und nicht ein Eindruck. Wer hier scheitert, scheitert nachweisbar — und kann es beheben. ### Ein Label ist eine Definition, kein Name Der häufigste Fehler ist auch der billigste zu beheben: Die Kategorien tragen nur **Namen** und keine Definitionen. `Zugang`, `Bug`, `Abrechnung` — jeder im Team weiß ungefähr, was gemeint ist, und jeder etwas anderes. Das Modell füllt die Lücke mit der allgemeinsprachlichen Bedeutung des Wortes, und die ist nicht eure. Eine tragfähige Label-Definition hat drei Teile: was **hineinfällt**, was ausdrücklich **nicht** hineinfällt, und die **Abgrenzung** zur benachbarten Kategorie. Der dritte Teil ist der, der fehlt und über die Trefferquote entscheidet — denn die Fehler sitzen fast immer auf einer Grenze und nicht in der Mitte. | | | | --- | --- | | Nur ein Name | Eine Definition | | `Zugang` | Nutzer kann sich nicht anmelden, obwohl Konto und Berechtigung bestehen. Nicht: Anmeldung schlägt wegen eines Softwarefehlers fehl — das ist `Bug`. | | `Abrechnung` | Fragen zu Rechnungsbetrag, Zahlungsweg, Mahnung. Nicht: Löschung von Rechnungsdaten — das ist `DSGVO-Anfrage`. | | `Sonstiges` | Trifft keine der übrigen Kategorien zu. Ausdrücklich erlaubt und nicht als Notlösung gedacht. | > **Merksatz:** Definiere jede Kategorie über ihre **Grenze** zur Nachbarkategorie. Eine Definition, die nur die Mitte beschreibt, hilft genau bei den Fällen nicht, an denen die Klassifikation scheitert. ### Wenn Menschen nicht übereinstimmen, hilft kein Prompt Hier die Prüfung, die vor jeder Prompt-Arbeit steht und fast immer übersprungen wird: Lass **zwei Menschen** aus deinem Team dieselben 50 Fälle unabhängig klassifizieren und vergleiche. Wenn sie sich in 30 % der Fälle uneinig sind, ist keine Prompt-Verbesserung der nächste Schritt — die Taxonomie ist nicht trennscharf. **Annotator-Übereinstimmung:** Das Maß, in dem unabhängige menschliche Bearbeiter dieselben Fälle gleich einordnen — über den Anteil hinaus, der bei zufälliger Zuordnung ohnehin übereinstimmen würde. Cohens Kappa ist das klassische Maß dafür. Der Wert dieser Messung liegt in ihrer Konsequenz. Die menschliche Übereinstimmung ist die **Obergrenze** für alles, was du erwarten darfst: Wo Menschen sich nicht einig sind, gibt es keine eindeutige richtige Antwort, gegen die ein Modell gemessen werden könnte. Ein Eval-Set, das aus solchen Fällen besteht, hat Sollwerte, die selbst Meinung sind. Und die Messung ist billig: 50 Fälle, zwei Bearbeiter, eine Stunde Arbeit. Was sie liefert, ist mehr als eine Zahl — die Fälle, in denen die beiden sich uneinig waren, sind genau die Grenzen, die in den Definitionen fehlen. Der Streit im Nachgespräch, warum der eine `Zugang` und der andere `Bug` gewählt hat, ist die Definitionsarbeit selbst. > **Merksatz:** Miss zuerst, ob deine Taxonomie unter Menschen funktioniert. Eine Trefferquote von 78 % ist ein Erfolg, wenn zwei Kollegen sich nur in 80 % der Fälle einig sind — und eine Fehldiagnose, wenn sie es in 99 % sind. ### Der Ausgang für Unklares Eine geschlossene Kategorienliste über einer offenen Welt zwingt bei jedem Fall, der nicht hineinpasst, eine falsche Wahl. Es entsteht kein Fehler — es entsteht ein reguläres, falsches Ergebnis. Deshalb gehört zu jeder Taxonomie eine **Restklasse**, und sie braucht eine Definition wie jede andere Kategorie. Wichtig ist die Doppelrolle dieser Klasse. Erstens ist sie der Ausgang, der die erzwungene Falschzuordnung verhindert. Zweitens ist ihre **Häufigkeit** eine Kennzahl: Ein Anstieg zeigt, dass sich das Fragebild geändert hat oder eine Kategorie fehlt. Ohne Restklasse verteilt sich diese Information unsichtbar auf die vorhandenen Kategorien. - **Definiert** — was gehört hinein, und ausdrücklich: es ist keine Notlösung, sondern die richtige Antwort für den Fall. - **Gemessen** — die Quote als laufendes Signal, mit einer Schwelle, ab der jemand hinsieht. - **Nachgearbeitet** — eine Stichprobe aus der Restklasse zeigt, welche Kategorie fehlt. - **Nicht bestraft** — wenn die Trefferquote Restklassen-Zuordnungen als Fehler zählt, lernt niemand sie zu nutzen. > **Merksatz:** Eine Zuordnungsquote von 100 % ist keine Leistung, sondern ein Konstruktionsfehler: Eine Kennzahl, die nicht fallen kann, misst nichts. ### Die Beispiele definieren den Label-Raum Bei Klassifikation zeigt sich der Befund von Min und Kollegen besonders deutlich: Was Few-shot-Beispiele übertragen, ist vor allem der **Label-Raum**, die **Eingabeverteilung** und das **Format** — nicht so stark die einzelne Zuordnung. Praktisch heißt das: Jede Kategorie sollte in den Beispielen vorkommen, sonst ist sie nur im Instruktionstext belegt und im Beispielblock unsichtbar. Das gilt auch für die Restklasse, und dort wird es am häufigsten verletzt. Wer `Sonstiges` definiert, aber kein Beispiel dafür gibt, hat eine Kategorie geschaffen, die das Modell für unwahrscheinlicher hält als die anderen fünf — und die es entsprechend selten wählt. Ein Beispiel für den unklaren Fall ist deshalb kein Luxus, sondern die Voraussetzung dafür, dass der Ausgang benutzt wird. Und es heißt, dass die Auswahl der Beispiele der **Fehlerauswertung** folgt und nicht dem Gefühl. Die vier klarsten Fälle lehren nichts, was das Modell nicht schon kann. Die zwei Grenzen, an denen 80 % der Fehler sitzen, lehren genau das, was fehlt. > **Merksatz:** Beispiele zeigen dem Modell den Raum, in dem es antworten soll. Eine Kategorie ohne Beispiel ist eine Kategorie, die es für unwahrscheinlicher hält, als sie ist. ### Verteilung und Reihenfolge sind eine Vorannahme Zhao und Kollegen haben drei Schieflagen benannt, die aus dem Beispielblock selbst entstehen — und alle drei treffen Klassifikation direkt. Der **Majority-Label-Bias**: Ein Label, das in den Beispielen häufiger vorkommt, wird häufiger vorhergesagt. Der **Recency-Bias**: Labels am Ende des Blocks werden bevorzugt. Der **Common-Token-Bias**: Antworten, die im Vortraining häufig waren, werden bevorzugt. Die dritte Schieflage ist die, an die niemand denkt, und sie hat eine konkrete Konsequenz für die **Benennung** deiner Kategorien: Ein seltener, ungewöhnlicher Kategoriename ist strukturell benachteiligt gegenüber einem alltäglichen Wort. Wenn eine Kategorie systematisch untergeht, lohnt ein Blick auf ihren Namen, bevor man an den Beispielen dreht. > **Merksatz:** Balanciere die Label-Verteilung im Beispielblock und fixiere die Reihenfolge. Beides sind Festlegungen — überlässt du sie dem Zufall der Datei, baust du eine Vorannahme ein, die niemand dokumentiert hat. ### Eine Kategorie oder mehrere Eine Entscheidung, die früh fallen muss und oft nachträglich schmerzt: Trägt ein Fall **genau eine** Kategorie oder **mehrere**? Die Praxis liefert regelmäßig Nachrichten, die zwei Anliegen enthalten — eine Rechnungsfrage plus einen Bug. Wer Einfachzuordnung erzwingt, bekommt eine Entscheidung, die die Hälfte des Anliegens verwirft. | | | | --- | --- | | Entwurf | Preis | | Genau eine Kategorie | Einfach zu messen und zu verarbeiten; verliert bei mehrfachen Anliegen die Hälfte. | | Mehrere Kategorien erlaubt | Bildet die Realität ab; Trefferquote wird mehrdeutig, und der Konsument muss n Fälle behandeln. | | Eine Hauptkategorie plus Nebenkategorien | Guter Kompromiss; erfordert eine Regel, was die Hauptkategorie bestimmt. | | Vorher zerlegen, dann je Teil klassifizieren | Sauberste Variante; ein zusätzlicher Schritt mit eigener Fehlerquelle. | Praktisch entscheidet die Frage, was der **Konsument** mit dem Ergebnis tut. Wird das Ticket in genau eine Warteschlange geroutet, ist Einfachzuordnung die passende Form — dann muss aber eine Regel festlegen, welches Anliegen bei zwei gewinnt. Werden Kennzahlen daraus gebildet, ist Mehrfachzuordnung meist richtiger, weil sonst die Hälfte der Anliegen aus der Statistik verschwindet. > **Merksatz:** Die Frage nach Einfach- oder Mehrfachzuordnung ist eine Frage an die Realität deiner Eingaben, nicht an die Bequemlichkeit deines Konsumenten. Sie nachträglich zu ändern, ist eine rückwärtsinkompatible Änderung des Ausgabevertrags. ### Extraktion: Treue vor Vollständigkeit Bei Extraktion kippt die Zielsetzung. Nicht **jedes Feld gefüllt** ist das Ziel, sondern **kein Feld falsch**. Ein leeres Feld ist ein bekanntes Loch, das nachgearbeitet werden kann; ein plausibel gefülltes falsches Feld ist ein Fehler, der durch die ganze Verarbeitung wandert und niemandem auffällt. Dass diese Sorge begründet ist, zeigt die Arbeit von Maynez und Kollegen zu abstraktiver Zusammenfassung: In der menschlichen Bewertung enthielten **alle** untersuchten Modellzusammenfassungen erhebliche Mengen an Inhalt, der der Eingabe nicht treu war. Der zweite Befund ist für die Messung entscheidend: **Entailment-Maße** korrelieren besser mit Treue als die üblichen Standardmetriken — wer mit Überlappungsmaßen prüft, sieht das Problem nicht. ### Vollständigkeit gegen Treue Eine Extraktion holt acht Felder aus Rechnungen. Die Auswertung zeigt: 96 % der Felder sind gefüllt, und 4 % der gefüllten Werte sind falsch — meist Beträge und Datumsangaben, die im Dokument nicht stehen, aber plausibel aussehen. Die Buchhaltung hat drei Monate lang mit diesen Zahlen gearbeitet. **Anforderungen** - Welche Zielgröße stellst du um, und wie? - Benenne, was die Umstellung im Betrieb auslöst. **Schritte** - Die Zielgröße wechseln: nicht Füllquote maximieren, sondern Falschquote minimieren. `null` wird zum erlaubten und erwarteten Wert, wenn die Angabe im Dokument fehlt. - Im Prompt und im Schema den leeren Fall benennen — sonst hat das Modell keinen Ausgang und füllt weiter. - Belegpflicht ergänzen: je extrahiertem Wert die wortwörtliche Textstelle, aus der er stammt. Dann ist die Treue maschinell prüfbar statt geschätzt. - Prüfen, dass die Stelle im Dokument vorkommt, und Werte ohne auffindbare Stelle verwerfen. Das fängt genau die 4 %. - Erwarten und einplanen, dass die Füllquote sinkt: Aus 96 % gefüllt werden vielleicht 88 % gefüllt und 8 % ausdrücklich leer — und die 8 % brauchen einen Nacharbeitsweg. **Merksatz:** Bei Extraktion ist Treue die Zielgröße und Vollständigkeit die abhängige Variable — ein leeres Feld ist ein bekanntes Loch, ein falsch gefülltes ein unsichtbarer Fehler. **+** Falsche Werte verschwinden fast vollständig, und die verbleibenden Lücken sind benannt und bearbeitbar. **−** Die Füllquote sinkt sichtbar, es entsteht Nacharbeit, und die drei Monate alten Zahlen in der Buchhaltung müssen nachträglich geprüft werden. ### Wörtlich oder normalisiert Eine Entscheidung, die bei Extraktion immer ansteht: Soll der Wert **wortwörtlich** aus dem Dokument kommen oder in ein **normalisiertes** Format übersetzt werden? Ein Datum steht als `3. Feber 2024` im Text und soll als `2024-02-03` in der Datenbank landen. Beides ist legitim, und die Verwechslung kostet die Prüfbarkeit. Die tragfähige Lösung ist, **beides** zu verlangen: den wörtlichen Ausschnitt als Beleg und den normalisierten Wert als Nutzlast. Der Ausschnitt ist gegen das Dokument prüfbar, der normalisierte Wert ist verarbeitbar — und wenn die Normalisierung falsch ist, sieht man es am Vergleich. Nur den normalisierten Wert zu verlangen heißt, die Umwandlung ungeprüft zu übernehmen. > **Merksatz:** Verlange den Beleg **und** den verarbeitbaren Wert. Wer nur normalisiert extrahiert, hat einen Rechenschritt im Modell versteckt, der nirgends geprüft wird. ### Die Kennzahl, die lügt Zum Schluss die Messfalle, die bei Klassifikation zuverlässig zuschlägt: die **Gesamttrefferquote** bei ungleich verteilten Kategorien. Wenn 70 % aller Nachrichten `Abrechnung` sind, erreicht ein System, das immer `Abrechnung` antwortet, 70 % — und ist wertlos. | | | | --- | --- | | Kennzahl | Was sie zeigt | | Gesamttrefferquote | Wird von der häufigsten Kategorie dominiert; verdeckt jeden Ausfall in seltenen Kategorien. | | Trefferquote je Kategorie | Zeigt, welche Kategorie tatsächlich funktioniert — die eigentliche Arbeitszahl. | | Verwechslungsmatrix | Zeigt, **wohin** die Fehler gehen; benennt die Grenzen, an denen es scheitert. | | Restklassen-Quote | Zeigt, wie viel die Taxonomie nicht abdeckt. | Die Verwechslungsmatrix verdient eine eigene Empfehlung, weil sie als einzige der vier Größen sagt, **was zu tun ist**. Eine Trefferquote je Kategorie meldet, dass `DSGVO-Anfrage` schlecht läuft. Die Matrix meldet, dass 80 % dieser Fälle als `Abrechnung` eingeordnet werden — und damit steht die Aufgabe fest: die Grenze zwischen diesen beiden Kategorien definieren und mit Beispielen belegen. Ohne Matrix ist jede Maßnahme geraten. **Kurzcheck:** Eine Klassifikation über sechs Kategorien erreicht 89 % Gesamttrefferquote. Die Fachabteilung meldet, dass DSGVO-Anfragen regelmäßig falsch landen — die machen 2 % des Volumens aus. Was ist zu tun? - [x] Trefferquote je Kategorie und Verwechslungsmatrix erheben - [ ] Die Gesamttrefferquote als Ziel auf 95 % anheben - [ ] Mehr Beispiele für DSGVO-Anfragen in den Prompt aufnehmen - [ ] DSGVO-Anfragen über eine Schlüsselwortregel vor der Klassifikation abzweigen > Genau. Bei 2 % Anteil kann DSGVO vollständig ausfallen, und die Gesamtquote bewegt sich um höchstens 2 Punkte. Die Matrix zeigt zusätzlich, in welche Kategorie die Fälle abwandern — und damit die Grenze, die zu definieren ist. ### Ein Fallsatz, der beides prüft Weil beide Aufgaben messbar sind, ist der Fallsatz hier billiger und wirksamer als in jedem anderen Modul. Für Klassifikation genügen pro Kategorie eine Handvoll Fälle plus die **Grenzfälle** zwischen den verwechselten Kategorien. Für Extraktion braucht jeder Fall zusätzlich die Angabe, welche Felder im Dokument **fehlen** — sonst ist nicht prüfbar, ob `null` richtig war. Der zweite Punkt wird fast immer vergessen und ist der wichtigere: Ein Extraktions-Testfall ohne Sollwert für die leeren Felder prüft nur, ob gefüllte Werte stimmen — nicht, ob korrekt leer gelassen wurde. Damit bleibt genau die Fehlerart ungeprüft, die dieses Modul behandelt. > **Merksatz:** Ein Extraktions-Fallsatz braucht Sollwerte für die **Abwesenheit**. Sonst belohnt er Füllen und bestraft Zurückhaltung — und du trainierst dein System auf die Kennzahl, die dich nicht interessiert. ### Zusammenfassung — gleich im Check Du kennst jetzt die Hebel: **Labels als Definition** mit Abgrenzung zur Nachbarkategorie, die **Annotator-Übereinstimmung** als Obergrenze deiner Erwartung, die **Restklasse** mit Definition und Kennzahl, **Beispiele** als Träger des Label-Raums, **Verteilung und Reihenfolge** als eingebaute Vorannahme, die Entscheidung über **Einfach- oder Mehrfachzuordnung**, bei Extraktion **Treue vor Vollständigkeit** samt Beleg und normalisiertem Wert — und die **Trefferquote je Kategorie** statt der Gesamtquote. > **Gleich im Check:** In den nächsten Aufgaben entscheidest du Taxonomien, Beispielwahl und Extraktionsverträge. Die wiederkehrende Falle: eine Zahl, die gut aussieht, weil sie die seltene Kategorie nicht enthält. Frage bei jeder Kennzahl, welche Kategorie sie dominiert. ## Quellen - Min et al., Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?, EMNLP 2022 — https://arxiv.org/abs/2202.12837 - Zhao et al., Calibrate Before Use: Improving Few-Shot Performance of Language Models, ICML 2021 — https://arxiv.org/abs/2102.09690 - Maynez et al., On Faithfulness and Factuality in Abstractive Summarization, ACL 2020 — https://arxiv.org/abs/2005.00661 - Cohen, A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20(1), 1960 — https://doi.org/10.1177/001316446002000104 - Anthropic — Prompting best practices: Use examples effectively — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices - Willard und Louf, Efficient Guided Generation for Large Language Models, 2023 — https://arxiv.org/abs/2307.09702 - JSON Schema Specification (Draft 2020-12), Validation: enum — https://json-schema.org/specification - Anthropic — Prompt engineering overview (Erfolgskriterien vor dem Tuning) — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview - Semantic Versioning 2.0.0 — https://semver.org/ - Ji et al., Survey of Hallucination in Natural Language Generation, ACM Computing Surveys 2023 — https://arxiv.org/abs/2202.03629