Amazon Nova 2 Lite vs Claude Fable 5.1 para extração de dados de documentos: como estruturar uma comparação reproduzível

Que decisão esta comparação resolve e o que ela não permite concluir

A decisão relevante não é qual modelo é «melhor» em abstrato, mas qual se adapta a um fluxo específico de extração documental. O caso de uso considerado consiste em converter faturas, contratos breves, formulários e documentos PDF com tabelas em dados que cumpram um esquema definido. Nesses fluxos, uma resposta aparentemente correta não é suficiente: ela precisa preservar os valores relevantes, respeitar os tipos exigidos, distinguir uma ausência de um valor real e deixar rastreabilidade suficiente para corrigir erros.

As informações fornecidas descrevem o Amazon Nova 2 Lite e o Claude Fable 5.1 a partir de seus fornecedores, mas não incluem resultados de uma avaliação comum executada em ambos. Portanto, não é possível afirmar, com base nessas fontes, que um alcance maior precisão, menor latência ou menor custo efetivo do que o outro em uma determinada carteira documental. Tampouco seria rigoroso extrapolar comparações da Amazon com outros modelos para o confronto proposto aqui.

A conclusão operacional, antes de realizar um teste, é condicional. O Nova 2 Lite pode ser avaliado como modelo multimodal da família Nova 2 por meio do Amazon Bedrock. O Claude Fable 5.1 pode ser avaliado na rota e nas condições de disponibilidade documentadas pela Anthropic. A seleção só será defensável depois de fixar uma rota de acesso, um corpus congelado, uma definição de correção, uma política de novas tentativas e uma forma homogênea de atribuir os custos auxiliares.

Uma comparação útil deve separar três planos. O primeiro é a capacidade declarada por cada fornecedor: modalidades aceitas, APIs, tratamento de documentos e controles disponíveis. O segundo é o resultado medido em um conjunto documental específico. O terceiro é o risco operacional: dados incompletos, OCR defeituoso, documentos não equivalentes, mudanças de versão, cotas, políticas de retenção e revisão humana. Confundir esses planos costuma gerar uma decisão aparentemente quantitativa, mas difícil de auditar.

Modelos, rotas de acesso e assimetrias que devem ser definidas

A Amazon documenta o Nova 2 Lite no Amazon Bedrock, incluindo identificadores de modelo, opções de inferência e possibilidades de uso regional ou global. A documentação do Nova também descreve capacidades relacionadas à compreensão de documentos, PDF, tabelas e layouts. Essas capacidades devem ser verificadas na modalidade exata contratada, pois um teste de texto não equivale a um teste que entregue imagens ou documentos ao modelo.

A Anthropic identifica o Claude Fable 5.1 em sua documentação e página de produto, nas quais também comunica disponibilidade, preços e capacidades relacionadas a PDF e tabelas. Antes de comparar, a equipe deve registrar o identificador exato utilizado, a data, a região ou localização de processamento quando aplicável, a versão da API, os limites configurados, o orçamento de saída e qualquer configuração de raciocínio ou cache. Sem esse registro, um resultado posterior pode não ser reproduzível.

Há uma assimetria metodológica potencial na saída estruturada. A documentação da Anthropic sobre structured outputs descreve um mecanismo baseado em JSON Schema e alerta que a compatibilidade depende da plataforma e do modelo. Segundo as informações fornecidas, o Fable 5.1 não aparece entre os modelos do Bedrock compatíveis com structured outputs. Isso não demonstra que o Fable 5.1 não possa produzir JSON válido em outras rotas; porém, obriga a documentar qual mecanismo foi usado de cada lado e a não apresentar duas integrações diferentes como se fossem idênticas.

Há duas opções aceitáveis, com implicações distintas. A primeira consiste em usar a interface nativa de cada fornecedor e medir o sistema efetivamente implantável, declarando as diferenças de plataforma. A segunda consiste em impor um denominador comum: um prompt que exija JSON, validação externa contra o mesmo esquema e um número idêntico de novas tentativas. A segunda reduz vantagens específicas de integração; a primeira reflete melhor a experiência operacional. As duas não devem ser combinadas sem identificá-las como experimentos separados.

Desenho reproduzível para extração estruturada

O corpus deve ser congelado antes da observação dos resultados e representar o trabalho que se pretende automatizar. Uma divisão prática inclui texto digital limpo, tabelas simples, tabelas de várias páginas, digitalizações, formulários, documentos com campos ambíguos e documentos incompletos. Devem ser preservados o arquivo original, um identificador não sensível, o tipo documental, o idioma, o canal de entrada e as ocorrências conhecidas. Caso sejam usados dados reais, o conjunto de avaliação deve respeitar as políticas internas e contratuais aplicáveis.

Cada documento necessita de uma verdade de referência independente do modelo. Para os campos críticos, dois revisores deveriam anotar o valor esperado, a ausência legítima, a ambiguidade e a evidência visual ou textual que a sustenta. Quando houver discordância, uma terceira revisão ou uma regra de adjudicação deve resolver o caso. A porcentagem de documentos duplamente revisados e as discordâncias não resolvidas devem ser publicadas como parte da incerteza, e não ocultadas em uma única métrica de precisão.

O esquema deve representar tanto o dado quanto seu estado. Por exemplo, uma data pode ser válida, ausente, ilegível, ambígua ou estar fora de escopo. Sempre forçar uma string pode transformar uma omissão em uma invenção. Convém exigir campos de evidência, nível de confiança expresso segundo regras próprias e uma lista de ocorrências; contudo, uma confiança declarada pelo modelo não prova que ela seja bem calibrada. Isso é medido comparando esse sinal com os erros observados.

O prompt deve ser idêntico no objetivo semântico: extrair apenas o que é visível ou explicitamente inferível segundo uma regra documentada, retornar ausência quando não houver evidência e não completar valores plausíveis. Se a interface de um fornecedor acrescentar instruções de sistema ou elementos obrigatórios de formatação, eles devem ser preservados, arquivados e contabilizados como parte da configuração. Também deve ser registrado se houve conversão prévia de PDF, OCR, redução de imagens ou divisão de páginas.

Execuções repetidas são necessárias mesmo quando a configuração parecer determinística. No mínimo, cada combinação de modelo, tipo de documento e configuração deve ser executada três vezes. Os resultados devem informar dispersão e, quando o tamanho da amostra permitir, intervalos de incerteza. Uma diferença isolada de poucos campos não deve se converter em uma recomendação de compra caso esteja dentro da variação observada ou decorra de poucos documentos.

Métricas que importam: formato, significado, tempo e custo

A taxa de JSON válido mede quantas respostas podem ser analisadas sem um reparo que altere seu conteúdo. Ela é necessária, mas não suficiente. Um JSON perfeitamente válido pode conter um fornecedor incorreto, um valor inventado ou uma data deslocada. Por isso, deve ser combinada com precisão por campo e precisão por documento. Esta última pode ser definida de forma estrita: um documento só conta como correto se todos os campos críticos coincidirem com a referência e não surgirem valores não sustentados.

Omissões e alucinações devem ser contadas separadamente. Uma omissão é um campo que deveria ser extraído e está ausente ou foi marcado incorretamente como ausente. Uma alucinação é um valor apresentado como extraído sem respaldo no documento ou contrário à referência. Em contratação, faturamento ou conformidade, alucinações podem ter custo operacional maior do que uma omissão, pois uma revisão pode detectar uma lacuna com mais facilidade do que um dado plausível, mas errado. A ponderação deve refletir o risco do processo, não uma preferência genérica.

A sinalização de incerteza deve ser avaliada como classificação. Se o modelo sinaliza dúvida em casos realmente ambíguos ou ilegíveis, ele agrega valor ao encaminhamento para revisão humana. Se declara alta segurança em erros graves, esse sinal não permite automatizar decisões. O relatório deve incluir cobertura: qual fração do corpus pode passar sem revisão sob um limiar de risco; e precisão condicionada: quantos desses documentos aceitos estão efetivamente corretos.

A latência deve ser medida de ponta a ponta, desde o momento em que o sistema inicia a solicitação até obter uma saída validada ou esgotar as novas tentativas. É necessário separar percentis, e não apenas médias, e medir por tamanho e complexidade documental. Também devem ser separados os tempos de carregamento, conversão de arquivos, OCR, se existir, inferência, validação e nova tentativa. Caso contrário, um gargalo externo pode ser atribuído indevidamente ao modelo.

O custo útil não é o preço anunciado por token. Para cada documento, devem ser somados entrada, saída, leituras ou gravações de cache aplicáveis, processamento de arquivos, novas tentativas e serviços auxiliares. Depois, o custo total é dividido pelo número de documentos que superam a definição de correção. Se for exigida revisão humana, há duas medidas distintas: custo por resultado automático correto e custo por resultado final aceito, incluindo o trabalho de revisão. Ambas são válidas, mas respondem a decisões diferentes.

Resultados: o que pode ser afirmado hoje e como interpretar um teste futuro

Não foram fornecidas medições do corpus proposto para o Amazon Nova 2 Lite nem para o Claude Fable 5.1. Por isso, as seções de resultados devem permanecer sem um veredito de desempenho até que o protocolo seja executado e publicado. A documentação da AWS pode justificar a inclusão do Nova 2 Lite na avaliação por suas capacidades declaradas de compreensão documental e modalidades relacionadas. A documentação da Anthropic pode justificar a inclusão do Fable 5.1 pelas capacidades e condições que comunica para PDF e tabelas. Nenhuma dessas descrições substitui uma taxa observada de campos corretos.

Um resultado favorável ao Nova 2 Lite em documentos de texto limpo não demonstraria superioridade em digitalizações, tabelas complexas ou contratos ambíguos. Da mesma forma, um resultado favorável ao Claude Fable 5.1 em uma configuração com um recurso de saída estruturada não demonstraria que a vantagem decorre do modelo, e não da integração. A divisão por categoria documental não é um detalhe editorial: ela é a base para que uma equipe aplique a conclusão à sua própria carteira.

A AWS publica um exemplo de arquitetura que combina o Nova 2 Lite com outro modelo Claude para digitalização de documentos escaneados. Esse material é útil como ilustração de uma arquitetura de várias etapas e da necessidade de distribuir custos e tarefas. Ele não deve ser usado como evidência comparativa entre o Nova 2 Lite e o Claude Fable 5.1: o exemplo citado usa outro modelo Claude e um caso documental diferente.

Um teste futuro também deveria relatar falhas recorrentes, e não apenas dados agregados. Entre as categorias úteis estão: célula de tabela atribuída à coluna incorreta, confusão entre subtotal e valor total, data normalizada de forma incorreta, parte contratante errada, erro por rotação ou baixa resolução, perda de uma página, valor não visível e descumprimento do esquema. Um conjunto de exemplos anonimizados e revisáveis ajuda a identificar se uma média alta esconde um tipo de falha inaceitável.

Privacidade, retenção e condições que podem invalidar uma decisão baseada apenas em métricas

A escolha da rota de acesso afeta tanto a avaliação quanto a implantação. O Amazon Bedrock documenta políticas de retenção de dados e controles de segurança e privacidade. A Anthropic documenta separadamente as condições de retenção de sua API, incluindo opções como retenção zero quando disponíveis nas condições aplicáveis. Essas políticas devem ser verificadas para a conta, o produto, a região e o acordo contratual específicos; uma afirmação geral sobre um fornecedor não substitui essa verificação.

Antes de carregar documentos reais, a equipe deve classificar os dados, determinar se contêm informações pessoais, financeiras, contratuais ou reguladas e confirmar quem pode acessar prompts, respostas, arquivos e registros. Também deve verificar se o esquema JSON, os metadados de rastreabilidade e os exemplos de erro contêm informações sensíveis. A minimização de dados pode ser mais importante do que uma pequena diferença de latência ou preço.

A residência de dados, a criptografia, a gestão de identidades, as chaves gerenciadas pelo cliente e os controles de rede podem determinar qual serviço é admissível. A AWS descreve controles empresariais para o Bedrock, incluindo mecanismos de segurança e isolamento. A avaliação deve registrar quais controles foram ativados, pois uma configuração de laboratório com permissões amplas pode não representar a arquitetura que seria aprovada em produção.

Não se deve presumir que os dados não sejam usados para treinamento, que sejam eliminados imediatamente ou que sejam processados em uma localização determinada sem confirmar isso na documentação e no contrato vigentes. As políticas mudam e podem depender da modalidade de acesso. Se uma exigência de conformidade não estiver confirmada, a decisão deve ser «pendente de validação», e não uma recomendação técnica provisória apresentada como suficiente.

Decisão por cenário e limites desta comparação

Para um cenário de menor custo aceitável, a decisão deve se basear no custo por documento correto dentro de um limiar mínimo de precisão, e não no preço unitário anunciado. Para máxima precisão, devem prevalecer a precisão por documento crítico, a taxa de alucinações e a calibração da incerteza. Para menor latência, é necessário observar percentis de ponta a ponta sob a carga prevista. Para alta criticidade, a opção adequada pode ser uma combinação de extração, validação determinística e revisão humana, mesmo que um modelo obtenha uma boa média agregada.

Quando ambos os modelos não cumprem um limiar definido para campos críticos, a conclusão correta é que nenhum deles deve aprovar automaticamente esses documentos nessa configuração. As alternativas são melhorar a qualidade da entrada, separar OCR da extração, dividir documentos por páginas ou seções, restringir o esquema, adicionar regras de validação, usar roteamento por risco ou manter a revisão humana. Trocar de modelo sem diagnosticar a causa pode deslocar o erro sem resolvê-lo.

O calendário de atualização deve depender de mudanças materiais: novo identificador de modelo, mudança de preços, modificação de limites ou modalidades, atualização de políticas de dados, mudança de região, alteração do corpus de produção ou surgimento de um novo tipo documental. Cada nova medição deve preservar a versão anterior para evitar comparar resultados incompatíveis. A recomendação deve expirar explicitamente se mudarem componentes que não foram testados novamente.

Em síntese, as fontes permitem estabelecer que existem capacidades e controles documentados que justificam avaliar ambas as opções, mas não permitem quantificar uma vantagem entre elas na extração confiável de documentos. A decisão rastreável exige um teste próprio e repetível. Até que ele seja publicado, qualquer preferência deve ser tratada como hipótese de integração, custo ou conformidade, e não como resultado de qualidade demonstrado.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.