O custo oculto de usar ai_parse_document em produção: desafios de confiabilidade, custo e auditabilidade

A função ai_parse_document do Databricks é um atalho tentador: extrai tabelas, textos e metadados de PDFs com uma linha de SQL. Mas, como mostram os testes em produção, ela não é um parser, é um wrapper para chamadas a LLMs com todas as suas limitações. Cada execução gera custo variável (não só pelo token count, mas pela latência e número de retries), e a saída muda mesmo com temperatura zero por causa de variações no chunking interno e no contexto de sistema da LLM. Isso quebra o contrato implícito de determinismo que pipelines de dados exigem.

O problema se agrava quando combinado com outros gargalos já documentados na cobertura CEVIU: avaliações de IA (que agora consomem mais compute que treinamento em alguns cenários) e a dívida de intenção, pois equipes raramente documentam por que escolheram essa função em vez de um parser baseado em regras ou OCR estruturado. O resultado é um pipeline frágil, caro e impossível de auditar com precisão.

Em abril, a CEVIU alertou que avaliações de IA viraram um gargalo de compute. Agora, em junho, vemos o mesmo padrão se repetindo na camada de ingestão: ai_parse_document está transformando a extração de documentos em um novo ponto de fuga de custos. Antes era teórico, agora há relatos de times pagando até 3x mais por reprocessamento acidental de PDFs idênticos, só por falta de checkpointing ou deduplicação de hash no input. Também confirmamos que a promessa de 'zero config' foi substituída por necessidade de versionamento de prompts e controle de schema de saída, algo ausente na primeira versão da função.

Isso importa porque dados não estruturados são a principal fonte de novos ativos analíticos nas empresas, mas se a ingestão depende de LLMs não auditáveis, você está construindo seu data lake sobre areia movediça. A confiabilidade cai, o time de engenharia gasta 40% do tempo corrigindo inconsistências de saída, e a governança fica inviável: não dá para rastrear qual versão do modelo gerou qual campo no JSON, nem provar que duas execuções idênticas produziram o mesmo resultado. Para quem lida com compliance (como finanças ou saúde), isso não é otimização, é risco operacional.