Mise à l'échelle de la classification de documents à plus de 100 000 étiquettes

Sur Databricks, des milliers de clients créent des charges de travail de production qui associent du texte libre à des taxonomies normalisées de plus de 100 000 étiquettes. Voici quelques cas d'usage courants :

• Liaison d'entités biomédicales. Les notes cliniques et les articles de recherche mentionnent des maladies, des médicaments et des procédures qui doivent être associés à un concept dans l' Unified Medical Language System, un vocabulaire contenant des milliers d'identifiants de concepts biomédicaux.
• Normalisation des fournisseurs. Pour analyser les habitudes de dépenses, les institutions financières normalisent les chaînes de transactions brutes telles que "SBUX #4471 SEATTLE WA" par rapport à un ensemble de plus de 100 000 marchands.
• Normalisation des entreprises. Les entreprises dédupliquent les dossiers clients de différents systèmes internes en faisant correspondre les descriptions d'entreprises à un ensemble de plus de 100 000 entreprises.

Chacun de ces cas d'usage définit un large ensemble d'étiquettes, également appelé taxonomie, et chaque entrée doit être associée à une ou plusieurs de ses étiquettes. Les clients évaluent généralement leur solution de production selon ces critères :

1. Qualité : Produire des classifications suffisamment précises pour orienter les décisions en aval.
2. Coût : Maintenir un coût de classification par document bas, en particulier à grande échelle.
3. Débit : Traiter des flux de travail volumineux, souvent de l'ordre de centaines de milliers de documents, dans un délai raisonnable.

Répondre à ces trois exigences rend difficile la classification de taxonomies volumineuses en production, et nous accordons la priorité à la recherche et au développement de solutions pour y parvenir chez Databricks.

Pourquoi les approches existantes montrent leurs limites

Historiquement, les organisations abordaient la classification de taxonomies volumineuses en s'appuyant sur des règles regex personnalisées, de la correspondance de mots-clés et des classificateurs d'apprentissage automatique supervisé. Cependant, ces approches montrent leurs limites sur plusieurs aspects :

Correspondance de motifs fragile. Les règles regex et de mots-clés dépendent de correspondances exactes, elles échouent donc face aux formats imprévisibles des données réelles. Des entreprises comme YipitData devaient continuellement mettre à jour leurs modèles regex pour gérer les cas particuliers et les modifications de taxonomie, ce qui est difficile à maintenir à l'échelle de milliers d'étiquettes.

Vérité terrain éparse et asymétrique. Les distributions réelles des étiquettes ont une longue traîne : une poignée d'étiquettes couvre la plupart des documents, tandis que des milliers d'autres apparaissent rarement. La plupart des clients manquent de documents de vérité terrain pour chaque étiquette de leur taxonomie, ce qui rend les classificateurs supervisés difficiles à entraîner. Un classificateur ne peut pas apprendre à classer des étiquettes qui ne sont pas incluses dans les données d'entraînement, et le déséquilibre des classes conduit les classificateurs à sur-prédire les étiquettes fréquemment représentées et à sous-prédire les étiquettes rares.

Dérive de la taxonomie. Des étiquettes et leurs descriptions sont constamment ajoutées, retirées et réécrites pour répondre à de nouveaux cas d'usage métier et améliorer la qualité de la classification. À chaque nouvelle version de la taxonomie, les modèles regex doivent être mis à jour et les classificateurs réentraînés et déployés.

Récemment, nous avons constaté que de plus en plus de clients utilisent des grands modèles de langage (LLM) pour la classification. Avec les LLM, les clients n'ont plus besoin d'entraîner des modèles ou de maintenir des modèles regex fragiles. Cependant, à l'échelle de centaines de milliers d'étiquettes, les LLM ont du mal à intégrer et à raisonner sur la taxonomie dans leur fenêtre de contexte. Avec des milliers de candidats dans un seul prompt, les modèles commencent également à halluciner, renvoyant des étiquettes qui n'existent pas du tout dans la taxonomie. Transmettre l'intégralité de la taxonomie pour des centaines de milliers de documents à un modèle de pointe est également coûteux à grande échelle, même en tirant parti de la mise en cache des prompts.

Notre approche de la classification à grand nombre d'étiquettes

Nous évaluons trois méthodes différentes pour trouver le meilleur équilibre entre coût et qualité pour les taxonomies volumineuses :

Méthode 1 : Recherche vectorielle

La première méthode que nous testons consiste à utiliser la recherche vectorielle pour récupérer la meilleure étiquette pour une entrée donnée. Nous générons des embeddings pour chaque étiquette, avec sa description lorsqu'elle est présente, et pour le document d'entrée à l'aide du modèle Qwen3-Embedding-8B, un modèle d'embedding open-weight de premier plan en juillet 2026. Nous évaluons ensuite la pertinence de chaque étiquette par rapport au document à l'aide d'un score hybride qui pondère la similarité sémantique et lexicale.

Le score sémantique est déterminé en calculant la similarité cosinus entre les embeddings du document et de l'étiquette ; une similarité cosinus plus élevée signifie que l'étiquette correspond étroitement au sens du document, même si le texte ne correspond pas exactement. Le score lexical est calculé avec l' algorithme BM25, qui pondère chaque terme partagé par sa fréquence inverse de document dans l'ensemble d'étiquettes, de sorte qu'un verbe générique comme "use" qui apparaît dans des milliers d'étiquettes reçoit un poids faible tandis qu'un token rare comme "ETL" reçoit un poids élevé.

Chaque méthode de recherche renvoie sa propre liste classée d'étiquettes. Nous fusionnons les deux listes avec la méthode Reciprocal Rank Fusion, qui évalue chaque étiquette selon sa position dans chaque liste. Nous prenons les k meilleures, en faisant varier k sur 1, 5, 10, 20, 50, 100 et 200 pour trouver la valeur offrant la meilleure précision moyenne, et nous utilisons l'étiquette la mieux classée comme prédiction.

À l'échelle de centaines de milliers d'étiquettes, générer les embeddings de la taxonomie une seule fois et créer un index en mémoire est plus rentable que de créer un index de recherche vectorielle hébergé. Générer les embeddings de 100 000 étiquettes utilise environ 1,6 GB de stockage en supposant des embeddings Qwen3-8B 4096-dim float32 et prend environ 1 à 3 minutes à générer à l'aide de la fonction Databricks AI Query. Ensuite, au début d'une charge de travail, nous créons une instance de recherche vectorielle en mémoire, ingérons les embeddings persistés et utilisons l'index pour tous les documents pendant toute la durée de la charge de travail. Vous trouverez un exemple de code pour notre implémentation de recherche vectorielle dans ce notebook de tutoriel.

Méthode 2 : Recherche vectorielle + AI Classify

La deuxième méthode que nous testons est un flux de travail en deux étapes combinant l'approche de recherche vectorielle et la fonction Databricks AI Classify. AI Classify est une fonction Databricks AI qui prend un document et une correspondance d'étiquettes avec leurs descriptions, et renvoie l'étiquette ou l'ensemble d'étiquettes qui correspond le mieux. La fonction AI Classify utilise une combinaison de techniques pour gérer des documents et des taxonomies volumineux tout en maintenant la qualité de la classification.

La fonction AI Classify peut être exécutée avec SQL comme suit :

Nous créons un flux de travail en deux étapes en utilisant la même recherche vectorielle décrite dans la méthode 1 pour présélectionner les k étiquettes les plus similaires par document, puis nous transmettons uniquement cette liste restreinte à AI Classify. Nous ajustons k à la plus petite valeur à partir de laquelle la précision cesse de s'améliorer et nous prenons le résultat d'AI Classify comme prédiction.

Méthode 3 : Appel direct d'un modèle de pointe

La dernière méthode que nous testons appelle directement un LLM de pointe avec le document d'entrée et la liste des étiquettes, y compris les descriptions lorsqu'elles sont présentes, puis demande au modèle de renvoyer l'étiquette correcte. Les modèles testés sont GPT-5.6 Luna, GPT-5.4 mini, Gemini 3.5 Flash et Claude Sonnet 5, qui sont les modèles les plus récents à la portée des budgets de classification de production habituels de nos clients. Les modèles phares comme Claude Opus 4.8, Claude Fable 5 et GPT-5.6 Sol coûtent trois à dix fois plus cher par token et dépassent généralement le budget des clients qui exécutent des flux de travail de classification contenant des milliers de documents par jour.

Lorsque la taxonomie dépasse la longueur de contexte d'un modèle, nous tronquons la liste des étiquettes pour l'adapter à la fenêtre de contexte. Nous transmettons la taxonomie de manière cohérente d'un appel à l'autre pour chaque document afin de tirer parti de la mise en cache des prompts.

Comment nous évaluons

Nous évaluons chaque méthode sur trois ensembles de données qui couvrent les cas d'usage clients les plus courants mentionnés ci-dessus. Les embeddings des étiquettes sont générés avec leurs descriptions, sauf indication contraire :

• Transactions (100 000 étiquettes, 200 documents d'évaluation) : chaînes de transactions générées de manière synthétique sur la base des 100 000 principaux noms d'entreprises de Crunchbase.
• Entreprises (100 000 étiquettes, 200 documents d'évaluation) : descriptions d'entreprises associées au même catalogue de noms d'entreprises Crunchbase que pour Transactions. Les étiquettes sont uniquement des noms.
• MedMentions (35 000 labels, 200 documents d'évaluation) : liaison de mentions biomédicales aux identifiants de concepts du Unified Medical Language System à partir du corpus MedMentions.

Chaque jeu de données est évalué selon son exactitude (accuracy) : la fraction de documents dont le label prédit correspond au label de référence (ground truth). Nous activons l'option de mise en cache des invites (prompt caching) du fournisseur de modèle pour tous les appels directs aux modèles de pointe (frontier models).

Résultats

Pour chaque approche, nous représentons graphiquement l'exactitude en fonction du coût par document, calculé en moyenne sur les trois jeux de données. Le coût comprend l'intégration de documents (embedding) et les jetons (tokens) LLM, avec les remises de mise en cache des invites du fournisseur appliquées. Nous excluons l'intégration de la taxonomie, un coût unique qui ne varie pas avec la taille de la charge de travail (voir les estimations de stockage pour notre configuration de recherche vectorielle sous « Comment nous abordons la classification de labels à grande échelle »).

Sur l'ensemble des jeux de données, le workflow AI Classify obtient un score supérieur à celui de tous les modèles de pointe directs, avec une exactitude moyenne de 0,81 contre 0,76 pour la deuxième meilleure option, Gemini 3.5 Flash, pour un centième du coût par document. En moyenne, la qualité du workflow AI Classify est optimale lorsque nous sélectionnons les vingt meilleurs labels issus de la recherche vectorielle pour les transmettre à la fonction AI Classify.

La recherche vectorielle seule est près de cent fois moins chère que le workflow AI Classify, car seul le document a besoin d'être converti en embedding et le coût CPU du classement est négligeable. Cependant, même après avoir ajusté k, son score reste inférieur de plus de vingt points à celui du workflow AI Classify.

Pour les taxonomies les plus volumineuses, l'appel direct au modèle de pointe ne peut pas intégrer l'ensemble des labels dans la fenêtre de contexte du modèle. Sur MedMentions, seul GPT-5.6 Luna a pu contenir l'intégralité de la taxonomie dans son contexte de 1M de tokens ; après tokenisation, aucun autre modèle n'a pu faire tenir l'ensemble de labels dans sa limite. À ce stade, les équipes peuvent choisir d'évaluer des stratégies de traitement par lots (batch), multi-étapes et agentielles pour gérer le contexte — des fonctionnalités que notre équipe a développées et continue de perfectionner dans la fonction AI Classify.

Conclusion

Sur trois benchmarks allant de 35 000 à 100 000 labels, le workflow AI Classify combinant la recherche vectorielle et la fonction AI Classify de Databricks a offert le meilleur équilibre entre coût et qualité. Il dépasse de cinq points le modèle de pointe direct le plus performant, Gemini 3.5 Flash, pour environ un centième du coût par document. Lorsque la taxonomie change, les labels obsolètes peuvent être supprimés et les nouveaux labels convertis en embeddings et intégrés au début du workflow, sans aucun réentraînement ni redéploiement.

Pour les équipes confrontées à une classification à cette échelle, la création d'un workflow avec AI Classify et la recherche vectorielle est un excellent point de départ. Ce tutoriel étape par étape présente l'intégralité du workflow sur Databricks, de la génération d'embeddings pour l'ensemble de labels à la sélection de K.

Essayer le workflow AI Classify

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original