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

Contexto e escala do negócio

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 e gargalos operacionais

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.

Arquitetura e implementação de IA

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.

“Dentro de um mês desde seu lançamento, verificamos mais de 20.000 entidades de dados, com uma média de cerca de 300-400 entidades por dia. — Equipes Caspian e Data Governance, Grab

Impacto mensurável e economia

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 para a indústria

Fontes primárias verificadas

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