Skalierung der Dokumentenklassifizierung auf über 100.000 Labels

Bei Databricks erstellen Tausende von Kunden Produktions-Workloads, die Freitext normalisierten Taxonomien mit mehr als 100.000 Labels zuordnen. Einige häufige Anwendungsfälle sind:

• Biomedizinische Entitätenverknüpfung. Klinische Notizen und Forschungsarbeiten erwähnen Krankheiten, Medikamente und Verfahren, die einem Konzept im Unified Medical Language System zugeordnet werden müssen, einem Vokabular mit Tausenden von biomedizinischen Konzept-IDs.
• Anbieternormalisierung. Zur Analyse von Ausgabenmustern normalisieren Finanzunternehmen unformatierte Transaktions-Strings wie "SBUX #4471 SEATTLE WA" mit einer Liste von über 100.000 Händlern.
• Unternehmensnormalisierung. Unternehmen bereinigen Kundendatensätze in verschiedenen internen Systemen von Duplikaten, indem sie Unternehmensbeschreibungen mit einer Liste von über 100.000 Unternehmen abgleichen.

Jeder dieser Anwendungsfälle definiert eine große Menge an Labels, auch als Taxonomie bezeichnet, und jede Eingabe muss einem oder mehreren dieser Labels zugeordnet werden. Kunden bewerten ihre Produktionslösung in der Regel anhand dieser Kriterien:

1. Qualität: Klassifizierungen erstellen, die präzise genug sind, um nachgelagerte Entscheidungen zu unterstützen.
2. Kosten: Die Klassifizierungskosten pro Dokument niedrig halten, insbesondere im großen Maßstab.
3. Durchsatz: Große Workflows, oft in der Größenordnung von Hunderttausenden von Dokumenten, in einem angemessenen Zeitrahmen verarbeiten.

Das Erfüllen aller drei Anforderungen macht die Klassifizierung großer Taxonomien in der Produktion schwierig. Bei Databricks hat die Erforschung und Entwicklung von Lösungen dafür hohe Priorität.

Warum bestehende Ansätze an ihre Grenzen stoßen

In der Vergangenheit näherten sich Unternehmen der Klassifizierung großer Taxonomien an, indem sie sich auf benutzerdefinierte Regex-Regeln, Keyword-Matching und überwachte Machine-Learning-Klassifikatoren verließen. Diese Ansätze stoßen jedoch in mehrfacher Hinsicht an ihre Grenzen:

Fehleranfälliges Pattern Matching. Regex- und Keyword-Regeln hängen von exakten Übereinstimmungen ab, sodass sie bei unvorhersehbaren Formatierungen in realen Daten fehlschlagen. Unternehmen wie YipitData mussten ihre Regex-Muster kontinuierlich aktualisieren, um Sonderfälle und Taxonomieänderungen zu berücksichtigen, was bei einer Skalierung auf Tausende von Labels nur schwer zu warten ist.

Spärliche und ungleichmäßig verteilte Ground Truth. Reale Label-Verteilungen sind Long-Tail-Verteilungen: Eine Handvoll Labels deckt die meisten Dokumente ab, während Tausende nur selten vorkommen. Den meisten Kunden fehlen Ground-Truth-Dokumente für jedes Label in ihrer Taxonomie, was das Trainieren überwachter Klassifikatoren erschwert. Ein Klassifikator kann nicht lernen, Labels zu klassifizieren, die nicht in den Trainingsdaten enthalten sind, und ein Klassenungleichgewicht führt dazu, dass Klassifikatoren häufig vertretene Labels zu oft und seltene Labels zu selten vorhersagen.

Taxonomie-Drift. Labels und ihre Beschreibungen werden ständig hinzugefügt, entfernt und umgeschrieben, um neuen geschäftlichen Anwendungsfällen Rechnung zu tragen und die Klassifizierungsqualität zu verbessern. Bei jeder neuen Taxonomieversion müssen Regex-Muster aktualisiert und Klassifikatoren neu trainiert und bereitgestellt werden.

In letzter Zeit sehen wir immer mehr Kunden, die große Sprachmodelle (LLMs) für die Klassifizierung verwenden. Mit LLMs müssen Kunden keine Modelle mehr trainieren oder fehleranfällige Regex-Muster pflegen. Bei Hunderttausenden von Labels fällt es LLMs jedoch schwer, die Taxonomie in ihr Kontextfenster einzupassen und logische Schlüsse darüber zu ziehen. Bei Tausenden von Kandidaten in einem einzigen Prompt beginnen die Modelle zudem zu halluzinieren und geben Labels zurück, die in der Taxonomie überhaupt nicht existieren. Die Übergabe der gesamten Taxonomie für Hunderttausende von Dokumenten an ein Frontier-Modell ist im großen Maßstab ebenfalls kostspielig, selbst wenn Prompt-Caching genutzt wird.

Wie wir die Klassifizierung mit vielen Labels angehen

Wir bewerten drei verschiedene Methoden, um das beste Gleichgewicht zwischen Kosten und Qualität für große Taxonomien zu finden:

Methode 1: Vektorsuche

Die erste Methode, die wir testen, ist die Verwendung der Vektorsuche, um das beste Label für die jeweilige Eingabe abzurufen. Wir erstellen Embeddings für jedes Label (gegebenenfalls mit Beschreibung) und das Eingabedokument mithilfe des Modells Qwen3-Embedding-8B, einem der bestplatzierten Open-Weight-Embedding-Modelle (Stand Juli 2026). Anschließend bewerten wir die Relevanz jedes Labels für das Dokument mit einem Hybrid-Score, der sowohl die semantische als auch die lexikalische Ähnlichkeit gewichtet.

Der semantische Score wird durch Berechnung der Kosinus-Ähnlichkeit zwischen den Dokumenten- und Label-Embeddings ermittelt. Eine höhere Kosinus-Ähnlichkeit bedeutet, dass das Label in seiner Bedeutung eng mit dem Dokument übereinstimmt, selbst wenn der Text nicht exakt übereinstimmt. Der lexikalische Score wird mit dem BM25-Algorithmus berechnet, der jeden gemeinsamen Begriff mit seiner inversen Dokumenthäufigkeit im gesamten Label-Set gewichtet. So erhält ein generisches Verb wie "use", das in Tausenden von Labels vorkommt, eine niedrige Gewichtung, während ein seltenes Token wie "ETL" eine hohe Gewichtung erhält.

Jede Suchmethode gibt eine eigene Rangliste von Labels zurück. Wir führen die beiden Listen mit Reciprocal Rank Fusion zusammen, wodurch jedes Label anhand seiner Position in der jeweiligen Liste bewertet wird. Wir nehmen die Top-k-Ergebnisse und variieren k über die Werte 1, 5, 10, 20, 50, 100 und 200, um den Wert mit der besten durchschnittlichen Genauigkeit zu ermitteln, und verwenden das am höchsten bewertete Label als Vorhersage.

Bei Hunderttausenden von Labels ist es kostengünstiger, die Taxonomie einmalig zu embedden und einen In-Memory-Index zu erstellen, als einen gehosteten Vektorsuchindex anzulegen. Das Erstellen von Embeddings für 100.000 Labels benötigt ca. 1,6 GB Speicherplatz (unter der Annahme von Qwen3-8B 4096-dim float32 Embeddings) und dauert etwa 1–3 Minuten unter Verwendung der Databricks AI Query-Funktion. Zu Beginn eines Workloads erstellen wir dann eine Vektorsuchinstanz im Arbeitsspeicher, lesen die persistierten Embeddings ein und verwenden den Index für alle Dokumente während der gesamten Dauer des Workloads. Beispielcode für unsere Vektorsuchimplementierung finden Sie in diesem Tutorial-Notebook.

Methode 2: Vektorsuche + AI Classify

Die zweite Methode, die wir testen, ist ein zweistufiger Workflow, der den Vektorsuchansatz und die Databricks-Funktion AI Classify kombiniert. AI Classify ist eine Databricks AI-Funktion, die ein Dokument und ein Mapping von Labels zu Beschreibungen entgegennimmt und das am besten passende Label oder eine Reihe von Labels zurückgibt. Die Funktion AI Classify verwendet eine Kombination von Techniken, um große Dokumente und Taxonomien zu verwalten und gleichzeitig die Klassifizierungsqualität aufrechtzuerhalten.

Die Funktion AI Classify kann wie folgt mit SQL ausgeführt werden:

Wir erstellen einen zweistufigen Workflow, indem wir den in Methode 1 beschriebenen Vektorsuchabruf verwenden, um die k ähnlichsten Labels pro Dokument in die engere Auswahl zu nehmen, und übergeben dann nur diese Auswahlliste an AI Classify. Wir optimieren k auf den kleinsten Wert, bei dem sich die Genauigkeit nicht weiter verbessert, und verwenden das Ergebnis von AI Classify als Vorhersage.

Methode 3: Direkter Aufruf eines Frontier-Modells

Die letzte Methode, die wir testen, ruft ein Frontier-LLM direkt mit dem Eingabedokument und der Liste der Labels (einschließlich Beschreibungen, sofern vorhanden) auf und fordert das Modell auf, das korrekte Label zurückzugeben. Die getesteten Modelle sind GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash und Claude Sonnet 5 – die neuesten Modelle, die im Rahmen der typischen Produktions-Klassifizierungsbudgets unserer Kunden liegen. Flaggschiff-Modelle wie Claude Opus 4.8, Claude Fable 5 und GPT-5.6 Sol kosten das Drei- bis Zehnfache pro Token und liegen in der Regel außerhalb des Budgets von Kunden, die Klassifizierungs-Workflows mit Tausenden von Dokumenten pro Tag ausführen.

Wenn die Taxonomie die Kontextlänge eines Modells überschreitet, kürzen wir die Label-Liste, damit sie in das Kontextfenster passt. Wir übergeben die Taxonomie bei jedem Dokument konsistent über alle Aufrufe hinweg, um von Prompt-Caching zu profitieren.

Wie wir evaluieren

Wir evaluieren jede Methode anhand von drei Datensätzen, die die oben genannten, am häufigsten vorkommenden Kundenanwendungsfälle abdecken. Sofern nicht anders angegeben, werden Embeddings für die Labels zusammen mit ihren Beschreibungen erstellt:

• Transaktionen (100.000 Labels, 200 Evaluierungsdokumente): synthetisch generierte Transaktions-Strings basierend auf den 100.000 wichtigsten Unternehmensnamen von Crunchbase.
• Unternehmen (100.000 Labels, 200 Evaluierungsdokumente): Unternehmensbeschreibungen, die demselben Crunchbase-Unternehmensnamenskatalog wie die Transaktionen zugeordnet sind. Labels bestehen nur aus Namen.
• MedMentions (35.000 Labels, 200 Eval-Dokumente): biomedizinisches Mention Linking zu Konzept-IDs des Unified Medical Language System aus dem MedMentions-Korpus.

Jeder Datensatz wird anhand der Accuracy bewertet: dem Anteil der Dokumente, deren vorhergesagtes Label mit dem Ground-Truth-Label übereinstimmt. Wir aktivieren die Prompt-Caching-Option des Modellanbieters für alle direkten Aufrufe von Frontier-Modellen.

Ergebnisse

Wir stellen für jeden Ansatz die Accuracy im Verhältnis zu den Kosten pro Dokument dar, gemittelt über die drei Datensätze. Die Kosten umfassen das Dokumenten-Embedding und die LLM-Token unter Berücksichtigung der Prompt-Caching-Rabatte des Anbieters. Wir schließen das Taxonomie-Embedding aus – ein einmaliger Aufwand, der nicht mit der Workload-Größe skaliert (siehe die Speicherschätzungen für unsere Vektorsuche-Konfiguration unter „Wie wir die Klassifizierung großer Labels angehen“).

Über alle Datensätze hinweg schneidet der AI Classify-Workflow besser ab als jedes direkte Frontier-Modell, mit einer durchschnittlichen Accuracy von 0,81 gegenüber 0,76 bei der nächstbesten Option, Gemini 3.5 Flash – und das zu einem Hundertstel der Kosten pro Dokument. Die Qualität des AI Classify-Workflows ist im Durchschnitt am besten, wenn wir die Top-20-Labels aus der Vektorsuche in die engere Auswahl nehmen, um sie an die AI Classify-Funktion zu übergeben.

Die reine Vektorsuche ist fast hundertmal günstiger als der AI Classify-Workflow, da nur das Dokument eingebettet werden muss und die CPU-Kosten für das Ranking vernachlässigbar sind. Doch selbst nach dem Tuning von k liegt sie mehr als zwanzig Prozentpunkte unter dem AI Classify-Workflow.

Bei den größten Taxonomien kann der direkte Frontier-Aufruf nicht das gesamte Label-Set im Kontextfenster des Modells unterbringen. Bei MedMentions konnte nur GPT-5.6 Luna die gesamte Taxonomie in seinem 1M-Token-Kontext halten; nach der Tokenisierung konnte kein anderes Modell das Label-Set innerhalb seines Limits unterbringen. An diesem Punkt können Teams Batch-, mehrstufige und agentische Strategien zur Kontextverwaltung evaluieren – Funktionen, die unser Team entwickelt hat und in der AI Classify-Funktion kontinuierlich verfeinert.

Fazit

Über drei Benchmarks hinweg, die 35.000 bis 100.000 Labels abdecken, bot der AI Classify-Workflow in Kombination mit der Vektorsuche und der Databricks AI Classify-Funktion das beste Verhältnis zwischen Kosten und Qualität. Er übertrifft das stärkste direkte Frontier-Modell, Gemini 3.5 Flash, um fünf Prozentpunkte bei etwa einem Hundertstel der Kosten pro Dokument. Wenn sich die Taxonomie ändert, können veraltete Labels entfernt und neue Labels zu Beginn des Workflows eingebettet und geladen werden, ohne dass ein erneutes Training oder Deployment erforderlich ist.

Für Teams, die vor einer Klassifizierung in dieser Größenordnung stehen, ist die Erstellung eines Workflows mit AI Classify und Vektorsuche ein hervorragender Ausgangspunkt. Dieses Schritt-für-Schritt-Tutorial führt Sie durch den gesamten Workflow auf Databricks, von der Einbettung des Label-Sets bis zur Auswahl von K.

AI Classify-Workflow ausprobieren

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag