Claude Vision: extração de dados estruturados que supera OCR

Manda pro Claude uma foto de nota fiscal manuscrita, um screenshot de ERP legado ou um PDF de múltiplas colunas com layout irregular, e ele devolve um JSON corretamente estruturado sem schema predefinido. O AWS Textract precisa de treinamento de templates ou marcação explícita de tabelas para chegar à mesma precisão nas mesmas entradas. Essa diferença de comportamento é onde o valor profissional do Claude Vision realmente está, e a maioria dos artigos sobre o recurso ignora completamente isso.

Aqui o foco é extração de dados estruturados de documentos visualmente complexos: por que o Claude performa melhor que OCR tradicional em cenários específicos, onde ele quebra, e qual o teto de custo antes da conta deixar de fechar.

Claude lê hierarquia espacial, não só texto

Ferramentas de OCR padrão leem pixels e tentam reconstruir texto a partir de caracteres reconhecidos. Tratam o documento como uma grade plana. O Claude faz algo diferente: como é um modelo de linguagem com percepção visual integrada à sua arquitetura (conforme documentado na documentação oficial de visão da Anthropic), ele entende relações espaciais e infere hierarquia implícita.

Na prática, um número posicionado abaixo de um cabeçalho em negrito num screenshot é atribuído à categoria daquele cabeçalho, mesmo sem delimitadores explícitos, porque o Claude entende convenções de documento como um leitor humano. Uma linha de subtotal numa nota fiscal mal formatada não precisa de coluna de rótulo para o modelo identificá-la como subtotal. Um formulário com células mescladas e espaçamento irregular de campos não precisa de template de layout.

O resultado é uma extração qualitativamente diferente de qualquer pipeline de OCR. Dado um screenshot de nota fiscal com múltiplas colunas, o Claude pode retornar algo assim:

{
  "fornecedor": "Distribuidora Sul Ltda",
  "numero_nf": "NF-00412",
  "itens": [
    { "descricao": "Porcelanato 60x60 Bege", "qtd": 120, "preco_unit": 48.90, "total": 5868.00 },
    { "descricao": "Argamassa AC-III", "qtd": 40, "preco_unit": 22.50, "total": 900.00 }
  ],
  "subtotal": 6768.00,
  "impostos": 812.16,
  "total_geral": 7580.16
}

Sem schema fornecido. Sem template treinado. Esse output vem de uma única chamada de API com um prompt pedindo extração estruturada em JSON, onde o Claude inferiu nomes de campos, aninheu os itens corretamente e separou a linha de imposto do subtotal porque a estrutura visual do documento implicava isso.

A documentação de visão da Anthropic confirma que todos os modelos Claude atuais suportam esse tipo de análise com múltiplas imagens em múltiplos formatos. Uma única sessão consegue processar várias páginas de um documento simultaneamente, o que importa para notas fiscais multipágina e manifestos de carga.

Onde supera o AWS Textract e o Azure Form Recognizer em baixo volume

AWS Textract e Azure Form Recognizer são serviços excelentes. Em alto volume, com formatos de documento consistentes e templates treinados, são mais rápidos, mais baratos e mais determinísticos que o Claude. Essa comparação não é a relevante.

Em baixo a médio volume, com formatos heterogêneos, construir e manter templates de extração para cada fornecedor, cada sistema legado e cada variante regional de documento é genuinamente caro em horas de engenharia.

Pensa num varejista de porte médio recebendo notas de 80 fornecedores diferentes. Cada fornecedor tem seu próprio layout de NF. O Textract resolve isso com AnalyzeDocument mais adaptadores treinados, mas cada adaptador exige dados de treinamento rotulados e retreinamento periódico quando o fornecedor atualiza o template. O Claude lida com os 80 formatos com um único prompt e zero dados de treinamento, porque lê o documento como uma pessoa leria.

Um tradeoff que vale dizer diretamente: o output do Claude é não-determinístico. Duas execuções no mesmo documento podem produzir chaves JSON levemente diferentes ou escolhas de formatação distintas. Para aplicações que exigem output byte-idêntico ou validação de schema rígida downstream, isso é um problema que precisa de mitigação: um schema de output fixo no prompt, JSON mode quando disponível, ou uma camada de validação pós-extração. Acima de aproximadamente 500 documentos por dia, o custo por token também se torna relevante o suficiente para justificar uma comparação com um pipeline Textract treinado.

Minha leitura da precificação atual é que o Claude Vision fica confortavelmente abaixo do teto de custo para operações processando algumas centenas de documentos diariamente, especialmente quando esses documentos são heterogêneos o suficiente para tornar o treinamento de templates impraticável.

Os modos de falha que a cobertura genérica ignora

A maioria dos artigos sobre Claude Vision para em listas de capacidades. Os modos de falha são mais úteis.

Primeiro, qualidade de imagem importa mais do que parece. A documentação da Anthropic é explícita: o Claude pode alucinar ou errar em imagens de baixa qualidade, rotacionadas ou muito pequenas, abaixo de 200 pixels. Em workflows de processamento de documentos, isso significa que etapas de pré-processamento (correção de inclinação, aumento de resolução, remoção de artefatos JPEG) não são opcionais. Uma nota fiscal fotografada em ângulo no chão de um depósito vai produzir extração não confiável. Escaneada corretamente a 300 DPI, o mesmo documento não vai.

Segundo, confiança é invisível. O Textract retorna scores de confiança por campo. O Claude não. Se um campo está parcialmente ilegível, o Claude frequentemente preenche um valor plausível sem sinalizar incerteza. Para documentos financeiros, isso é um risco real. Uma abordagem de mitigação é pedir que o Claude retorne uma chave "confianca" por campo no JSON, onde sinaliza extrações de baixa certeza, embora isso adicione complexidade ao prompt e consumo de tokens.

Terceiro, o Claude não consegue detectar de forma confiável documentos gerados por IA ou alterados sinteticamente. A Anthropic declara isso diretamente na documentação. Para workflows de detecção de fraude ou autenticação de documento, essa é uma limitação dura que nenhuma engenharia de prompt vai resolver.

Quarto, documentos densos em tabelas com estruturas profundamente aninhadas podem produzir erros de extração em hierarquias complexas. Um conhecimento de embarque com sub-itens dentro de contêineres dentro de embarques vai ocasionalmente colapsar níveis de aninhamento ou duplicar um campo pai. Quebrar o prompt em etapas contorna isso: extrai a estrutura de nível superior primeiro, depois aprofunda em cada seção como uma chamada separada.

O que a cobertura genérica não diz: schema no prompt reduz não-determinismo de forma mensurável

Esse ponto merece destaque próprio porque aparece em quase nenhuma documentação tutorial.

Quando você manda o Claude extrair dados sem especificar o schema de output, ele infere os nomes de campo. Isso é útil para exploração, mas problemático em produção: dois documentos do mesmo fornecedor podem retornar "numero_nf" e "nf_numero" dependendo de variações mínimas no layout. O não-determinismo aqui não é do modelo fazendo algo errado, é comportamento esperado de um sistema que está inferindo.

A correção é simples e subestimada: inclua o schema exato no prompt. Especifique nomes de campo, tipos de dado e estrutura de aninhamento. O modelo segue o schema fornecido com consistência muito maior do que quando infere livremente. Para operações de catálogo onde o output vai para um sistema com validação de schema, essa única mudança de prompt é a diferença entre um workflow confiável e um que quebra periodicamente.

Uma abordagem para documentos onde o schema não é conhecido de antemão: primeira chamada pedindo ao Claude para propor um schema com base na estrutura do documento, segunda chamada de extração usando esse schema proposto. Produz output mais consistente do que uma requisição de extração em aberto, com o custo de uma chamada de API adicional.

Na prática: catálogo de pisos e revestimentos

No meu trabalho gerenciando um catálogo com milhares de SKUs ativos em categorias de piso e revestimento, o problema de documentação de fornecedor é constante. Fabricantes atualizam fichas técnicas, distribuidores regionais mandam versões localizadas em formatos não padronizados, e coleções sazonais chegam como PDFs de marketing com especificações de produto embutidas em layouts pesados de design que nenhum parser convencional lida bem.

A documentação de fornecedor aqui no Brasil tem uma característica que complica qualquer abordagem baseada em templates: não tem padrão. Uma ficha técnica de porcelanato de um fabricante gaúcho é estruturalmente diferente da de um fabricante mineiro, que é diferente da de um importador de produto asiático. Cada um tem seus campos de dimensão, absorção de água, PEI, carga de ruptura, em posições e formatos completamente distintos. Treinar um parser para cada um não é inviável, mas é caro em tempo de engenharia e mais caro ainda em manutenção quando o fornecedor atualiza o layout.

O workflow que uso e que produz resultados consistentes: imagem do documento, schema JSON alvo especificado no prompt (com nomes de campo exatamente como o sistema de catálogo espera), e uma etapa de validação leve para pegar campos obrigatórios ausentes antes de escrever no sistema. Para documentos com imagem do produto anexada na mesma ficha, o Claude processa os dois na mesma chamada: extrai os atributos estruturados e gera uma descrição de produto ao mesmo tempo.

Um estudo publicado na ScienceDirect em julho de 2025 (DOI: 10.1016/j.csa.2025.100083) valida o caso de uso de IA multimodal em operações de e-commerce, documentando redução mensurável no tempo de preparação de catálogo quando modelos de visão lidam com extração de atributos de materiais de fornecedor. Minha leitura da evidência é que os ganhos são maiores em operações com alta variedade de formato de documento, exatamente o perfil de quem trabalha com múltiplos fornecedores no varejo brasileiro.

Se você trabalha com system prompts bem estruturados, vale aplicar a mesma lógica aqui: o Claude responde muito melhor a instruções de extração quando o contexto do documento e o schema esperado estão claros desde o início da chamada.

FAQ

Claude Vision pode substituir o AWS Textract completamente?

Para workflows de documento heterogêneos, em baixo a médio volume (por volta de menos de 500 documentos por dia), é uma alternativa prática e frequentemente mais barata. Para processamento de alto volume com formatos consistentes onde output determinístico e scoring de confiança importam, o Textract com adaptadores treinados continua sendo a escolha mais sólida. A decisão depende de variedade de documento e throughput.

Quais formatos de imagem o Claude Vision aceita?

Conforme a documentação de visão da Anthropic, o Claude suporta JPEG, PNG, GIF e WebP. Imagens podem ser passadas como dados base64 ou via URL. Múltiplas imagens são suportadas numa única requisição, o que é útil para documentos multipágina.

Como reduzir não-determinismo no JSON extraído?

Forneça o schema alvo exato no prompt com nomes de campo, tipos de dado e estrutura de aninhamento especificados explicitamente. Se o sistema downstream exige validação rígida, adicione uma etapa de validação de schema JSON após a extração e refaça o prompt em caso de falhas de validação. Adiciona latência, mas melhora consistência de output de forma substancial.

O Claude Vision funciona em documentos manuscritos?

Sim, com ressalvas. Letra de forma limpa em fundo de alto contraste extrai com confiança. Cursiva, baixo contraste ou escrita muito degradada produz alucinações. Pré-processamento (melhoria de contraste, redução de ruído) melhora os resultados antes de enviar para a API.

O teto real para o Claude Vision em workflows de documento é custo e latência em escala, não capacidade do modelo. Abaixo desse teto, ele lida com formatos de documento que de outra forma exigiriam um parser customizado para cada fornecedor, cada sistema legado e cada variação regional que a operação encontrar.