Grab: clasificación de datos con LLM — más de 20 000 entidades en el primer mes y 360 días-persona ahorrados al año

• 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

Contexto

Grab es la superapp líder de Asia Sudoriental: transporte compartido, entrega de comida y servicios financieros en una sola aplicación. El modelo de superapp implica datos de superapp: la empresa gestiona un panorama a escala de petabytes — innumerables tablas de bases de datos y esquemas de mensajes Kafka creados y modificados continuamente por docenas de equipos de producto.

Por cumplimiento normativo y política interna, cada entidad de datos debe clasificarse por sensibilidad: ¿contiene datos personales? ¿A qué nivel de confidencialidad pertenece? Esto no es mera formalidad burocrática sino el fundamento de todo el sistema de protección: en Grab, las etiquetas de sensibilidad determinan los niveles de acceso a tablas e impulsan políticas de control de acceso basado en atributos (ABAC) y enmascaramiento dinámico de datos en consultas. Una tabla sin clasificar o mal clasificada es un agujero en la protección de datos personales o restricciones excesivas que bloquean el trabajo de los equipos.

El problema fue abordado por los equipos Caspian (ingeniería de datos) y Data Governance. En octubre de 2023 describieron en el blog de ingeniería cómo pasaron la clasificación de datos de un proceso manual a LLMs — uno de los primeros casos públicos de aplicación de modelos generativos a la gobernanza de datos. Un detalle revelador: el servicio de orquestación que integra el LLM en las plataformas de datos se llama Gemini — sin relación con el modelo de Google del mismo nombre, ya que el artículo precede su anuncio. En noviembre de 2024 el equipo publicó una secuela — Metasense V2 — sobre la mejora del sistema para cubrir todo el data lake, haciendo de este un raro ejemplo documentado de evolución de un sistema LLM a través de dos generaciones.

Problema

La clasificación manual de datos no escala. Los propietarios de datos tenían que revisar cada tabla y cada columna y asignar etiquetas de sensibilidad manualmente — lento, costoso y propenso a errores: un ingeniero etiquetando su centésima tabla de la semana inevitablemente pierde el enfoque. En un panorama a escala de petabytes donde nuevas entidades aparecen diariamente, el acumulado de tablas y esquemas Kafka sin clasificar crece más rápido de lo que puede despejarse — y el riesgo de cumplimiento crece con él.

Las alternativas del equipo eran imperfectas. Las heurísticas rígidas (expresiones regulares sobre nombres de columnas) no entienden semántica: una columna user_note puede contener cualquier cosa desde un comentario técnico hasta una dirección y un número de teléfono. El servicio de clasificación de terceros que el equipo evaluó en paralelo con LLMs requería reglas predefinidas y tenía dificultades con la semántica de columnas en el contexto del negocio de Grab. Entrenar un modelo ML interno habría significado primero ensamblar un conjunto de datos grande etiquetado — es decir, resolver el mismo problema de etiquetado, con infraestructura ML encima.

Los modelos generativos ofrecían un tercer camino: un LLM tiene suficiente 'conocimiento general' para distinguir a partir de nombres de columnas y descripciones si está mirando un número de teléfono, una dirección o un identificador de dispositivo, y los requisitos de clasificación pueden expresarse en texto de prompt plano — sin código, sin entrenamiento de modelo. Pero ese camino vino con restricciones de ingeniería: el contexto de GPT-3.5 es apenas 4 000 tokens (aproximadamente 3 000 palabras), y la cuota de Azure OpenAI es 240K tokens por minuto compartida entre todos los despliegues de la empresa.

Solución

El equipo integró GPT-3.5 en Gemini — un servicio de orquestación que toma solicitudes de clasificación de plataformas de datos. La arquitectura está construida para cuotas y escala: las solicitudes se agregan en colas de mensajes, un limitador de velocidad a nivel de flujo de trabajo mantiene el flujo dentro del límite de Azure OpenAI (240K tokens por minuto), y los metadatos de una entidad — nombres de columnas y descripciones — se empaquetan en un prompt dentro del contexto de 4 000 tokens; las tablas demasiado anchas se procesan en partes. En paralelo con el LLM, un clasificador de terceros se ejecutó durante el período de evaluación — una comparación directa del motor sobre el mismo flujo de datos.

La calidad se logró mediante ingeniería de prompts, sin entrenamiento de modelo personalizado: requisitos claros por etiqueta, ejemplos de pocos disparos, salida limitada a un esquema estricto mediante definiciones DTO, y — un detalle importante — una etiqueta predeterminada <None> para casos inciertos para que el modelo no fuerce clasificaciones dudosas. El equipo describió la precisión resultante como 'sorprendentemente precisa'. Los resultados fluyen de vuelta a las plataformas de datos vía Kafka, y los propietarios de datos reciben notificaciones semanales de verificación para confirmar o corregir las etiquetas propuestas. El humano siguió en el bucle, pero el rol cambió de etiquetador a validador.

Todo el stack de protección se ejecuta en las etiquetas: determinación del nivel de sensibilidad de la tabla, políticas de control de acceso basado en atributos, enmascaramiento dinámico de datos en consultas y descubrimiento de datos. El equipo también construyó pipelines de análisis para calificar la calidad de cada versión de prompt — los prompts se versionan y prueban como código.

La segunda generación del sistema — Metasense V2 (noviembre de 2024) — corrigió debilidades encontradas en tráfico en vivo: el modelo se confundía con muestras mixtas grandes donde datos personales se ocultaban entre no-personales (correos de negocios con nombres legales, JSON anidado, comunicaciones de pasajeros). Las correcciones son notables por su simplicidad: un modelo se dividió en dos — etiquetas PII separadas del resto; el conteo de etiquetas en la parte PII se redujo de 21 a 8; el prompt se redujo de 1 254 a 737 palabras; las tablas más anchas que 150 columnas se dividen en bloques. Para experimentación rápida de prompts el equipo adoptó LangChain y LangSmith, y configuró alertas automatizadas sobre umbrales de clasificación errónea en caso de degradación de calidad.

Resultado

En el primer mes después del despliegue el sistema escaneó más de 20 000 entidades de datos — promediando 300–400 por día, un ritmo físicamente inalcanzable para un proceso manual. En una encuesta de septiembre de 2023, 80% de los propietarios de datos dijeron que el nuevo proceso los ayudó a etiquetar sus entidades, y para tablas reconocidas los usuarios cambiaron menos de una etiqueta en promedio — significando que la inmensa mayoría de las propuestas del modelo fueron aceptadas sin cambios. A dos minutos de clasificación manual por entidad, la automatización ahorra aproximadamente 360 días-persona al año. Para V2 el sistema cubrió todo el data lake de Grab con lo que el equipo llama tasas de clasificación errónea 'excepcionalmente bajas' — aunque la empresa no publica porcentajes exactos, y todas las cifras del caso son auto-reportadas sin auditoría externa.

En nuestra opinión, este caso es un modelo de selección sobria de tareas para LLMs. La clasificación de metadatos es un escenario donde un modelo generativo es casi ideal: la entrada es compacta (nombres de columnas y descripciones), la salida es estructurada (etiquetas de una taxonomía fija), el costo de un único error es acotado (un validador humano y notificaciones semanales), y la alternativa no es 'otro modelo' sino miles de horas de trabajo manual. La economía se calcula conservadoramente y legiblemente: 2 minutos × 20 000+ entidades al mes es aritmética que cualquier CFO aceptará — a diferencia de 'porcentajes de productividad' abstractos.

Nuestra segunda observación: el historial V1→V2 honestamente muestra que un sistema LLM no es 'configurar y olvidar'. La primera versión, 'sorprendentemente precisa' en 2023, acumuló una lista de debilidades en tráfico en vivo — y fueron curadas no con un modelo más poderoso sino con descomposición de tareas, reduciendo el prompt a la mitad, y observabilidad (LangSmith, alertas de umbral). Esa es quizás la lección más transferible del caso: en sistemas LLM en producción, la ingeniería alrededor del modelo — orquestación, cuotas, esquemas de salida, versionado de prompts, monitoreo — importa más que la elección del modelo en sí.

Lecciones aprendidas

1. La gobernanza de datos es un caso de uso LLM subestimado: la clasificación de sensibilidad a partir de metadatos no requería modelos personalizados — GPT-3.5 más ingeniería de prompts fue suficiente.
2. Cuente el impacto en días-persona: 2 minutos por entidad × 20 000+ entidades al mes = ~360 días-persona al año — aritmética que cualquier ejecutivo entiende.
3. Mantenga un humano en el bucle como validador: los propietarios de datos confirman etiquetas, y la métrica 'menos de una corrección por tabla' muestra madurez del sistema.
4. Diseñe para cuotas de API desde el principio: los límites de Azure OpenAI (240K tokens/min) y el contexto de 4K tokens son restricciones arquitectónicas duras, no letra pequeña — de ahí las colas y limitador de velocidad de Gemini.
5. Dé al modelo el derecho a decir 'No sé': una etiqueta predeterminada <None> para casos inciertos protege contra clasificaciones forzadas mejor que exigir una respuesta.
6. Versione prompts como código: pipelines de análisis puntuando cada versión de prompt, más LangSmith en V2, son la base de la evolución controlada del sistema LLM.
7. Un sistema LLM necesita una segunda iteración: V2 curó las debilidades reales de V1 con descomposición de tareas (PII/no-PII), reduciendo el prompt de 1 254 a 737 palabras, y alertas de clasificación errónea — no con un modelo más grande.

Preguntas frecuentes