Grab: Classificação de dados com LLM — 20.000+ entidades no primeiro mês e 360 dias/pessoa economizados por ano

• 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 é o principal superapp do Sudeste Asiático: ride-hailing, entrega de comida e serviços financeiros em um aplicativo. O modelo de superapp significa dados de superapp: a empresa gerencia um ecossistema em escala de petabytes — inúmeras tabelas de banco de dados e esquemas de mensagens Kafka continuamente criados e modificados por dezenas de equipes de produto.

Para conformidade regulatória e política interna, cada entidade de dados deve ser classificada por sensibilidade: contém dados pessoais? A qual nível de confidencialidade pertence? Não é formalidade burocrática, mas o fundamento de todo o sistema de proteção: na Grab, as tags de sensibilidade determinam os níveis de acesso à tabela e impulsionam políticas de controle de acesso baseadas em atributos (ABAC) e mascaramento dinâmico de dados em consultas. Uma tabela não classificada ou mal classificada é ou uma brecha na proteção de dados pessoais ou restrições excessivas bloqueando o trabalho das equipes.

O problema foi abordado pelas equipes Caspian (engenharia de dados) e Data Governance. Em outubro de 2023 descreveram no blog de engenharia como migraram a classificação de dados de um processo manual para LLMs — um dos primeiros casos públicos de aplicação de modelos generativos à governança de dados. Um detalhe revelador: o serviço de orquestração que incorpora o LLM nas plataformas de dados se chama Gemini — sem relação com o modelo de mesmo nome do Google, pois o post é anterior ao seu anúncio. Em novembro de 2024 a equipe publicou uma sequência — Metasense V2 — sobre a atualização do sistema para cobrir todo o data lake, tornando este um raro exemplo documentado de evolução de um sistema LLM entre duas gerações.

Problema

A classificação manual de dados não escala. Os proprietários de dados tinham que revisar cada tabela e cada coluna e atribuir tags de sensibilidade manualmente — lento, custoso e propenso a erros: um engenheiro classificando sua centésima tabela da semana inevitavelmente perde o foco. Em um ecossistema em escala de petabytes onde novas entidades aparecem diariamente, a lista de pendências de tabelas não classificadas e esquemas Kafka cresce mais rápido do que pode ser limpa — e o risco de conformidade cresce com ela.

As alternativas da equipe eram imperfeitas. Heurísticas rígidas (expressões regulares sobre nomes de colunas) não entendem semântica: uma coluna user_note pode conter desde um comentário técnico até um endereço e um número de telefone. O serviço de classificação de terceiros que a equipe avaliou em paralelo com LLMs exigia regras predefinidas e enfrentava dificuldades com a semântica de colunas no contexto do negócio da Grab. Treinar um modelo ML interno significaria primeiro montar um grande conjunto de dados rotulados — ou seja, resolver o mesmo problema de rotulação, com infraestrutura de ML por cima.

Modelos generativos ofereceram um terceiro caminho: um LLM tem conhecimento 'geral' suficiente para dizer, a partir de nomes de colunas e descrições, se está vendo um número de telefone, um endereço ou um identificador de dispositivo, e os requisitos de classificação podem ser expressos em texto de prompt simples — sem código, sem treinamento de modelo. Mas esse caminho veio com restrições de engenharia: o contexto do GPT-3.5 é apenas 4.000 tokens (aproximadamente 3.000 palavras), e a cota do Azure OpenAI é 240K tokens por minuto compartilhados entre todos os deployments da empresa.

Solução

A equipe integrou o GPT-3.5 ao Gemini — um serviço de orquestração que recebe solicitações de classificação das plataformas de dados. A arquitetura é construída para cotas e escala: as solicitações são agregadas em filas de mensagens, um limitador de taxa em nível de workflow mantém o fluxo dentro do limite do Azure OpenAI (240K tokens por minuto), e os metadados de uma entidade — nomes de colunas e descrições — são empacotados em um prompt dentro do contexto de 4.000 tokens; tabelas muito largas são processadas em partes. Em paralelo com o LLM, um classificador de terceiros funcionou durante o período de avaliação — uma comparação direta de motores no mesmo fluxo de dados.

A qualidade foi alcançada através de engenharia de prompt, sem treinamento de modelo personalizado: requisitos claros por tag, exemplos de poucos disparos, saída restrita a um esquema rígido via definições de DTO, e — um detalhe importante — uma tag padrão <None> para casos incertos para que o modelo não force classificações duvidosas. A equipe descreveu a precisão resultante como 'surpreendentemente precisa'. Os resultados fluem de volta para as plataformas de dados via Kafka, e os proprietários de dados recebem notificações semanais de verificação para confirmar ou corrigir as tags propostas. O humano permaneceu no loop, mas o papel mudou de rotulador para validador.

Todo o stack de proteção funciona nas tags: determinação do nível de sensibilidade da tabela, políticas de controle de acesso baseadas em atributos, mascaramento dinâmico de dados em consultas e descoberta de dados. A equipe também construiu pipelines de análise para avaliar a qualidade de cada versão de prompt — prompts são versionados e testados como código.

A segunda geração do sistema — Metasense V2 (novembro de 2024) — corrigiu fraquezas encontradas no tráfego ao vivo: o modelo era confundido por grandes amostras mistas onde dados pessoais se escondiam entre não-pessoais (e-mails comerciais com nomes legais, JSON aninhado, comunicações de passageiros). As correções são notáveis por sua simplicidade: um modelo foi dividido em dois — tags de PII separadas do resto; a contagem de tags na parte de PII foi reduzida de 21 para 8; o prompt foi reduzido de 1.254 para 737 palavras; tabelas com mais de 150 colunas são divididas em partes. Para experimentação rápida de prompts, a equipe adotou LangChain e LangSmith, e configurou alertas automatizados em limites de má classificação em caso de degradação de qualidade.

Resultado

No primeiro mês após o lançamento, o sistema verificou mais de 20.000 entidades de dados — uma média de 300–400 por dia, um ritmo fisicamente inalcançável para um processo manual. Em uma pesquisa de setembro de 2023, 80% dos proprietários de dados disseram que o novo processo os ajudou a marcar suas entidades, e para tabelas reconhecidas os usuários mudaram menos de uma tag em média — significando que a grande maioria das propostas do modelo foram aceitas sem alterações. Com dois minutos de classificação manual por entidade, a automação economiza aproximadamente 360 dias/pessoa por ano. Na V2 o sistema cobriu todo o data lake da Grab com o que a equipe chama de taxas de má classificação 'excepcionalmente baixas' — embora a empresa não publique percentuais exatos, e todas as figuras do caso sejam auto-relatadas sem auditoria externa.

Em nossa opinião, este caso é um modelo de seleção sóbria de tarefas para LLMs. Classificação de metadados é um cenário onde um modelo generativo é quase ideal: a entrada é compacta (nomes de colunas e descrições), a saída é estruturada (tags de uma taxonomia fixa), o custo de um único erro é limitado (um validador humano e notificações semanais), e a alternativa não é 'outro modelo' mas milhares de horas de trabalho manual. A economia é calculada de forma conservadora e legível: 2 minutos × 20.000+ entidades por mês é aritmética que qualquer CFO aceitará — diferentemente de 'percentuais de produtividade' abstratos.

Nostra segunda observação: o histórico V1→V2 mostra honestamente que um sistema LLM não é 'configurar e esquecer'. A primeira versão, 'surpreendentemente precisa' em 2023, acumulou uma lista de fraquezas no tráfego ao vivo — e foram curadas não com um modelo mais poderoso, mas com decomposição de tarefas, redução à metade do prompt e observabilidade (LangSmith, alertas de limite). Essa é talvez a lição mais transferível do caso: em sistemas LLM em produção, a engenharia em torno do modelo — orquestração, cotas, esquemas de saída, versionamento de prompt, monitoramento — importa mais do que a escolha do próprio modelo.

Lições aprendidas

1. A governança de dados é um caso de uso de LLM subestimado: a classificação de sensibilidade a partir de metadados não precisava de modelos personalizados — GPT-3.5 mais engenharia de prompt era o suficiente.
2. Conte o impacto em dias/pessoa: 2 minutos por entidade × 20.000+ entidades por mês = ~360 dias/pessoa por ano — aritmética que qualquer executivo entende.
3. Mantenha um humano no loop como validador: os proprietários de dados confirmam tags, e a métrica 'menos de uma correção por tabela' mostra maturidade do sistema.
4. Projete para cotas de API desde o primeiro dia: os limites do Azure OpenAI (240K tokens/min) e o contexto de 4K tokens são restrições arquitetônicas rígidas, não letra miúda — daí as filas do Gemini e o limitador de taxa.
5. Dê ao modelo o direito de dizer 'Não sei': uma tag padrão <None> para casos incertos protege contra classificações forçadas melhor do que exigir uma resposta.
6. Versione prompts como código: pipelines de análise pontuando cada versão de prompt, mais LangSmith na V2, são a base da evolução controlada do sistema LLM.
7. Um sistema LLM precisa de uma segunda iteração: a V2 curou as fraquezas reais da V1 com decomposição de tarefas (PII/não-PII), redução do prompt de 1.254 para 737 palavras e alertas de má classificação — não com um modelo maior.

Perguntas frequentes