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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.