Mistral OCR 4.1: o que uma equipa deve voltar a validar quando mudam o texto, a estrutura e as coordenadas de um fluxo documental

A alteração anunciada afeta o contrato de saída, não apenas o reconhecimento de caracteres

A Mistral AI identifica esta versão como `mistral-ocr-4-1`. A documentação do fornecedor situa o seu lançamento em 16 de julho de 2026 e regista a sua disponibilidade geral em 31 de agosto do mesmo ano. O registo de alterações também indica que os aliases `mistral-ocr-latest` e `mistral-ocr-4` passaram a resolver para o OCR 4.1. Para uma equipa que utiliza um desses aliases, a atualização pode ocorrer sem que o nome usado no pedido necessariamente mude.

Isto torna a atualização uma questão de compatibilidade operacional. Um sistema que utiliza OCR como primeira etapa para indexar processos, extrair campos, classificar documentos ou preparar uma revisão humana não recebe apenas uma cadeia de texto. Pode depender de páginas, fragmentos em Markdown, blocos, etiquetas estruturais, tabelas, dimensões do documento e posições espaciais. Se qualquer uma destas representações mudar, um processo posterior pode falhar ou degradar-se, ainda que o texto visível pareça melhor.

A página do modelo declara caixas delimitadoras por parágrafo, etiquetas estruturais e pontuações de confiança por bloco. O registo de alterações, por sua vez, menciona a introdução de granularidade de confiança ao nível do bloco. Estas capacidades podem fornecer mais sinais para priorizar revisões, mas exigem que se defina como são armazenadas, comparadas e consumidas. Não se deve assumir que um sinal de confiança equivale a uma garantia de correção semântica de uma cláusula, de um montante ou de uma identidade.

O que o endpoint expõe e porque deve ser comparado antes da migração

A referência do endpoint de OCR descreve um pedido para `POST /v1/ocr` e opções que condicionam a forma de processar e devolver o documento. Entre elas estão a modalidade do documento, a seleção de páginas, a inclusão de blocos, o formato de tabelas, os formatos de anotação e as granularidades das pontuações de confiança. Nem todas estas opções têm necessariamente de estar ativas numa integração existente; precisamente por isso, a configuração efetiva deve fazer parte do teste.

O guia do processador OCR descreve resultados organizados por página e conteúdo que pode incluir Markdown, tabelas, cabeçalhos, rodapés, dimensões, imagens e blocos. Também indica que `include_blocks` requer OCR 4 ou posterior, enquanto a informação de tabela, cabeçalho e rodapé requer OCR 2512 ou posterior. Uma equipa deve confirmar a versão efetivamente invocada e as opções aceites na sua conta antes de concluir que um campo estará disponível.

A comparação não deve limitar-se a verificar se o JSON continua válido. É necessário confrontar o esquema de cada objeto utilizado pela aplicação, a presença ou ausência de valores, a ordem de leitura dos blocos, a associação à página e as coordenadas ou caixas delimitadoras quando forem usadas para destacar evidência. Também convém verificar que os extratores de tabelas não estejam a pressupor colunas, cabeçalhos ou quebras de linha que o OCR possa representar de outra forma.

Cinco verificações de compatibilidade que convém transformar em testes

A primeira verificação é o esquema. Guarde respostas de referência da versão anterior e do OCR 4.1 para os mesmos documentos, com opções idênticas. Compare nomes de campos, tipos, campos opcionais e valores nulos. Se o sistema transformar a resposta antes de a armazenar, teste tanto a resposta original como o JSON transformado; muitos problemas surgem em adaptadores, validadores de esquema ou serializadores, e não no OCR isoladamente.

A segunda é a segmentação. Um modelo pode dividir um parágrafo, unir dois blocos próximos ou identificar de forma diferente cabeçalhos e rodapés. Essas variações podem alterar regras que atribuem texto a uma secção contratual ou que excluem elementos repetidos. Meça quantos blocos mudam e, sobretudo, se a alteração modifica a saída dos processos consumidores.

A terceira verificação é a reconstrução de tabelas. Selecione documentos com tabelas complexas, células combinadas, formulários, colunas estreitas, escrita digitalizada e baixa qualidade de imagem. Avalie campos de negócio concretos, e não apenas a semelhança global com uma transcrição. Por exemplo, numa fatura podem ser o total, a moeda, os impostos, os identificadores de linha e a sua correspondência com a linha correta.

A quarta é a rastreabilidade espacial. Quando uma aplicação mostra ao revisor a origem de uma extração, deve verificar que o texto, a página e a região assinalada continuam a coincidir. O facto de existirem caixas delimitadoras por parágrafo não permite concluir, sem um teste próprio, que todas as citações geradas anteriormente conservarão a mesma geometria ou segmentação.

A quinta é o comportamento operacional. Registe o tempo de resposta, os erros, as repetições, o volume processado e a proporção de casos que exigem correção humana. A documentação do endpoint contempla modalidades e parâmetros de processamento; a carga, o tipo de ficheiro e a configuração podem afetar o resultado observado. Os limites e o comportamento efetivo devem ser validados no ambiente e na conta que serão utilizados.

Teste de migração: corpus congelado, execução dupla e condições de reversão

O teste mínimo deve usar um corpus congelado e representativo, com uma referência humana para os elementos críticos. Inclua documentos nativos e digitalizados, os idiomas presentes em produção, diferentes resoluções, páginas rodadas, formulários, tabelas, cabeçalhos repetidos e os casos que historicamente geraram incidentes. Separe um conjunto de desenvolvimento de um conjunto final que não seja utilizado para ajustar regras durante a migração.

Execute ambos os percursos com o mesmo documento de entrada e preserve o identificador do modelo, os parâmetros, a hora, o resultado original e o resultado transformado. A inferência regional da Mistral recomenda registar o hostname, o modelo, a hora e o identificador do pedido para fins de auditoria. Essa disciplina permite investigar uma diferença sem a atribuir imediatamente ao modelo.

Defina limiares antes de observar os resultados. Alguns podem ser a exatidão dos campos críticos, a proporção de citações corretas por página, a integridade das tabelas, a taxa de erro técnico, percentis de latência e a taxa de revisão ou correção humana. Estabeleça também que diferença justifica interromper a implementação. Um canary com tráfego limitado e execução dupla sem afetar a decisão de negócio tendem a reduzir o risco face à substituição do modelo para todo o tráfego de uma só vez.

A decisão não tem de ser binária. Se o OCR 4.1 melhorar alguns tipos documentais e piorar outros, a equipa pode manter percursos diferenciados enquanto corrige os seus consumidores ou revê o critério de seleção. Trata-se de uma decisão de arquitetura e operação baseada em medições internas, não de uma conclusão que possa ser extraída das capacidades declaradas pelo fornecedor.

Retenção, ficheiros e região: aspetos que não devem ficar fora da avaliação

A documentação de retenção zero de dados inclui o endpoint de OCR entre os compatíveis com essa modalidade. Contudo, a mesma documentação exclui dessa cobertura a API de ficheiros e os ficheiros de processamento em lote. Assim, não basta conhecer o modelo selecionado: a equipa deve rever por que via cada documento é entregue e que serviços auxiliares intervêm no fluxo.

A documentação de inferência regional descreve endpoints regionais, incluindo um endpoint europeu. A escolha da região, quando estiver disponível para a integração, pode ser relevante para requisitos internos de auditoria, residência ou rastreabilidade. No entanto, a existência de um endpoint regional não substitui a análise jurídica, contratual e de segurança aplicável a cada organização.

Convém documentar separadamente a retenção, a via de carregamento, a região, as permissões de acesso, os prazos internos de conservação e a eliminação de artefactos derivados. São controlos do fluxo completo, e não propriedades que possam ser deduzidas da qualidade do reconhecimento. Se a aplicação processar informação sensível, essa análise deve preceder a implementação e ser atualizada quando os componentes utilizados mudarem.

Conclusão: fixar a evidência antes de alterar a rota de produção

O Mistral OCR 4.1 disponibiliza uma versão identificável, disponibilidade geral documentada e sinais estruturais que podem ser úteis em aplicações documentais. O facto mais relevante para uma integração existente é que determinados aliases passaram a apontar para esta versão. Por isso, equipas que dependam de aliases devem tratar a alteração como uma potencial modificação de contrato, e não como uma atualização transparente.

Uma validação prudente compara saídas e consequências: não apenas os caracteres reconhecidos, mas também campos de negócio, estrutura de tabelas, referências por página, geometria, desempenho e carga de revisão. A evidência necessária para aprovar a migração deve resultar de um protocolo reproduzível sobre documentos próprios, com limiares explícitos e uma reversão disponível. As afirmações do fornecedor ajudam a delimitar o que testar; não substituem essa verificação.

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.