Grab : classification de données par LLM — 20 000+ entités au premier mois et 360 jours-homme économisés par an

• LLM-powered data classification for data entities at scale — Grab Engineering Blog (Caspian & Data Governance), 2023-10
• Metasense V2: Enhancing, improving and productionisation of LLM powered data governance — Grab Engineering Blog (Buhrer, Parbat, Zeng), 2024-11-14
• Grab: LLM-Powered Data Classification System for Enterprise-Scale Metadata Generation (сторонний разбор) — ZenML LLMOps Database

Contexte

Grab est la superapp dominante d'Asie du Sud-Est : transport à la demande, livraison de nourriture et services financiers dans une seule application. Le modèle de superapp génère des données de superapp : l'entreprise gère un paysage à l'échelle du pétaoctet — d'innombrables tables de base de données et schémas de messages Kafka créés et modifiés en permanence par des dizaines d'équipes produit.

Pour la conformité réglementaire et la politique interne, chaque entité de données doit être classifiée par sensibilité : contient-elle des données personnelles et à quel niveau de confidentialité appartient-elle. Il ne s'agit pas d'une formalité bureaucratique mais du fondement de tout le système de protection : chez Grab, les étiquettes de sensibilité déterminent les niveaux d'accès aux tables et pilotent les politiques d'ABAC (attribute-based access control) et le masquage dynamique des données dans les requêtes. Une table non classifiée ou mal classifiée est soit une faille dans la protection des données personnelles, soit des restrictions excessives bloquant le travail des équipes.

Le problème a été abordé par les équipes Caspian (ingénierie des données) et Data Governance. En octobre 2023, ils ont décrit sur le blog d'ingénierie comment ils ont fait évoluer la classification des données d'un processus manuel à des LLM — l'un des premiers cas publics d'application de modèles génératifs à la gouvernance des données. Un détail révélateur : le service d'orchestration qui intègre le LLM dans les plateformes de données s'appelle Gemini — aucun lien avec le modèle de Google du même nom, car l'article précède son annonce. En novembre 2024, l'équipe a publié une suite — Metasense V2 — sur la mise à niveau du système pour couvrir l'ensemble du lac de données, ce qui en ferait un exemple documenté rare d'une évolution système LLM sur deux générations.

Problème

La classification manuelle des données n'est pas évolutive. Les propriétaires de données devaient passer en revue chaque table et chaque colonne et attribuer manuellement des étiquettes de sensibilité — lent, coûteux et sujet aux erreurs : un ingénieur étiquetant sa centième table de la semaine perd inévitablement sa concentration. Dans un paysage à l'échelle du pétaoctet où de nouvelles entités apparaissent quotidiennement, l'arriéré de tables et schémas Kafka non classifiés s'accumule plus vite qu'il ne peut être traité — et le risque de conformité croît avec lui.

Les alternatives de l'équipe n'étaient pas parfaites. Les heuristiques rigides (expressions régulières sur les noms de colonnes) ne comprennent pas la sémantique : une colonne user_note peut contenir n'importe quoi, d'un commentaire technique à une adresse et un numéro de téléphone. Le service de classification tiers que l'équipe a évalué parallèlement aux LLM nécessitait des règles prédéfinies et avait du mal avec la sémantique des colonnes dans le contexte du secteur d'activité de Grab. Entraîner un modèle ML interne signifierait d'abord assembler un grand ensemble de données étiqueté — c'est-à-dire résoudre le même problème d'étiquetage, avec une infrastructure ML en plus.

Les modèles génératifs offrent une troisième voie : un LLM a assez de « connaissances générales » pour déterminer d'après les noms de colonnes et les descriptions s'il regarde un numéro de téléphone, une adresse ou un identifiant d'appareil, et les exigences de classification peuvent être exprimées en texte de prompt simple — pas de code, pas d'entraînement de modèle. Mais cette voie s'accompagnait de contraintes d'ingénierie : le contexte de GPT-3.5 n'est que de 4 000 tokens (environ 3 000 mots), et le quota Azure OpenAI est de 240 000 tokens par minute partagés entre tous les déploiements de l'entreprise.

Solution

L'équipe a intégré GPT-3.5 à Gemini — un service d'orchestration qui reçoit les demandes de classification des plateformes de données. L'architecture est conçue pour les quotas et l'échelle : les demandes sont agrégées dans des files d'attente de messages, un limiteur de débit au niveau du workflow maintient le flux dans la limite Azure OpenAI (240 000 tokens par minute), et les métadonnées d'une entité — noms de colonnes et descriptions — sont compactées dans un prompt dans le contexte de 4 000 tokens ; les tables trop larges sont traitées par parties. En parallèle avec le LLM, un classifieur tiers a fonctionné pendant la période d'évaluation — une comparaison directe des moteurs sur le même flux de données.

La qualité a été obtenue par l'ingénierie des prompts, sans entraînement de modèle personnalisé : exigences claires par étiquette, exemples few-shot, sortie contrainte à un schéma strict via des définitions DTO, et — un détail important — une étiquette par défaut <None> pour les cas incertains afin que le modèle ne force pas de classifications douteuses. L'équipe a décrit la précision obtenue comme « étonnamment précise ». Les résultats reviennent aux plateformes de données via Kafka, et les propriétaires de données reçoivent des notifications de vérification hebdomadaires pour confirmer ou corriger les étiquettes proposées. L'humain est resté dans la boucle, mais le rôle a changé d'étiqueteur à validateur.

Toute la pile de protection fonctionne sur les étiquettes : détermination du niveau de sensibilité des tables, politiques de contrôle d'accès basé sur les attributs, masquage dynamique des données dans les requêtes et découverte des données. L'équipe a également construit des pipelines d'analytique pour évaluer la qualité de chaque version de prompt — les prompts sont versionnés et testés comme du code.

La deuxième génération du système — Metasense V2 (novembre 2024) — a corrigé les faiblesses trouvées sur le trafic en direct : le modèle était confus par de grands échantillons mixtes où les données personnelles se cachaient parmi les non-personnelles (emails professionnels avec des noms légaux, JSON imbriqué, communications de passagers). Les correctifs sont remarquables par leur simplicité : un modèle a été scindé en deux — étiquettes PII séparées du reste ; le nombre d'étiquettes dans la partie PII a été réduit de 21 à 8 ; le prompt a été réduit de 1 254 à 737 mots ; les tables de plus de 150 colonnes sont divisées en chunks. Pour l'expérimentation rapide de prompts, l'équipe a adopté LangChain et LangSmith, et a mis en place des alertes automatiques sur les seuils de mauvaise classification en cas de dégradation de la qualité.

Résultat

Au cours du premier mois suivant le déploiement, le système a scanné plus de 20 000 entités de données — en moyenne 300 à 400 par jour, une cadence physiquement inaccessible pour un processus manuel. Dans une enquête de septembre 2023, 80 % des propriétaires de données ont dit que le nouveau processus les a aidés à étiqueter leurs entités, et pour les tables reconnues, les utilisateurs ont modifié moins d'une étiquette en moyenne — ce qui signifie que la grande majorité des propositions du modèle ont été acceptées sans changement. À deux minutes de classification manuelle par entité, l'automatisation économise environ 360 jours-homme par an. Par V2, le système couvrait tout le lac de données de Grab avec ce que l'équipe appelle des taux de mauvaise classification « exceptionnellement faibles » — bien que l'entreprise ne publie pas de pourcentages exacts, et tous les chiffres du cas sont auto-déclarés sans audit externe.

À notre avis, ce cas est un modèle de sélection sobre de tâches pour les LLM. La classification des métadonnées est un scénario où un modèle génératif est presque idéal : l'entrée est compacte (noms de colonnes et descriptions), la sortie est structurée (étiquettes d'une taxonomie fixe), le coût d'une seule erreur est limité (un validateur humain et des notifications hebdomadaires), et l'alternative n'est pas « un autre modèle » mais des milliers d'heures de travail manuel. L'économie est calculée de manière prudente et lisible : 2 minutes × 20 000+ entités par mois est une arithmétique que tout directeur financier acceptera — contrairement aux « pourcentages de productivité » abstraits.

Notre deuxième observation : l'historique V1→V2 montre honnêtement qu'un système LLM n'est pas « définir et oublier ». La première version, « étonnamment précise » en 2023, a accumulé une liste de faiblesses sur le trafic en direct — et elles ont été guéries non pas avec un modèle plus puissant mais avec la décomposition des tâches, la réduction de moitié du prompt et l'observabilité (LangSmith, alertes de seuil). C'est peut-être la leçon la plus transférable du cas : dans les systèmes LLM en production, l'ingénierie autour du modèle — orchestration, quotas, schémas de sortie, versionnage des prompts, surveillance — importe plus que le choix du modèle lui-même.

Leçons

1. La gouvernance des données est un cas d'usage LLM sous-estimé : la classification de sensibilité à partir de métadonnées n'a pas nécessité de modèles personnalisés — GPT-3.5 plus l'ingénierie des prompts a suffi.
2. Comptez l'impact en jours-homme : 2 minutes par entité × 20 000+ entités par mois = ~360 jours-homme par an — une arithmétique que tout cadre comprend.
3. Gardez un humain dans la boucle comme validateur : les propriétaires de données confirment les étiquettes, et la métrique « moins d'une correction par table » montre la maturité du système.
4. Concevez pour les quotas API dès le départ : les limites Azure OpenAI (240 000 tokens/min) et le contexte de 4 000 tokens sont des contraintes architecturales strictes, pas des conditions générales — d'où les files d'attente et le limiteur de débit de Gemini.
5. Donnez au modèle le droit de dire « je ne sais pas » : une étiquette par défaut <None> pour les cas incertains protège mieux contre les classifications forcées que d'exiger une réponse.
6. Versionnez les prompts comme du code : les pipelines d'analytique évaluant chaque version de prompt, plus LangSmith dans V2, sont la base de l'évolution contrôlée du système LLM.
7. Un système LLM a besoin d'une deuxième itération : V2 a guéri les vraies faiblesses de V1 avec la décomposition des tâches (PII/non-PII), la réduction du prompt de 1 254 à 737 mots et les alertes de mauvaise classification — pas avec un modèle plus grand.

Questions fréquentes