Documento - Ground Truth de IA além do OCR: ordem de leitura, tabelas, campos e relações entre páginas

Os sistemas de Document AI fazem mais do que OCR: eles precisam recuperar a estrutura e as relações que tornam uma página utilizável. Para equipes que criam conjuntos de dados de treinamento de IA, um modelo pode transcrever cada palavra corretamente e ainda assim falhar no fluxo de trabalho para o qual foi criado.

Uma fatura pode conter o valor correto, mas associá-lo ao item de linha errado. Um relatório em duas colunas pode conter todas as frases, mas unir as colunas na ordem errada. Uma tabela pode preservar o valor de cada célula, mas colocar um valor sob o cabeçalho errado. Esses são erros de compreensão de documentos que a taxa de erro de caracteres ou a taxa de erro de palavras, isoladamente, não consegue capturar.

É por isso que a verdade de referência do Document AI precisa ir além do texto verificado. Se o aplicativo depende da ordem de leitura, da topologia da tabela, dos relacionamentos entre campos ou da continuidade entre páginas, o conjunto de dados de referência precisa de rótulos para esses relacionamentos, para que cada um possa ser avaliado separadamente.

A distinção não é que o OCR moderno esteja limitado a texto simples. Sistemas atuais, como o Google Cloud Document AI, podem retornar texto de OCR, coordenadas e sinais de layout. A distinção mais útil é entre a precisão do reconhecimento de texto e a precisão estrutural: uma métrica de transcrição pode dizer se as palavras foram reconhecidas, mas não se as relações do documento necessárias para a tarefa foram reconstruídas corretamente.

O ground truth do Document AI é o conjunto de dados de referência verificados usado para treinar ou avaliar sistemas que convertem documentos em informações estruturadas. Dependendo da tarefa, ele pode incluir texto de OCR e regiões de layout, ordem de leitura, estrutura de tabelas, campos nomeados, relações chave-valor, classes de documentos, limites de página e links entre páginas.

O ground truth deve corresponder à saída que está sendo avaliada. Caso se espere que um modelo recupere uma hierarquia de tabela, associe um campo ao seu valor ou una uma tabela que atravessa uma quebra de página, a transcrição verificada é necessária, mas não suficiente. O conjunto de avaliação precisa registrar a relação em si.

É também por isso que a expressão “acurácia do OCR” exige cuidado. A taxa de erro de caractere (CER) e a taxa de erro de palavra (WER) medem o texto reconhecido em relação a uma transcrição de referência. Elas são úteis para a qualidade do OCR, mas não informam se um valor corretamente reconhecido foi atribuído ao campo certo ou se blocos corretamente reconhecidos foram colocados na sequência correta.

A ordem de leitura parece trivial em uma página de coluna única. Ela se torna um problema separado de anotação assim que uma página contém duas colunas, uma barra lateral, uma citação destacada, uma nota de rodapé, uma legenda flutuante ou um formulário com vários grupos alinhados.

Os dados de referência, portanto, precisam de uma unidade explícita de ordenação. Um projeto pode ordenar blocos, regiões, linhas ou outra unidade de layout, mas a regra precisa ser fixada antes do início da anotação de produção. Caso contrário, dois revisores cuidadosos podem discordar, embora ambos acreditem estar seguindo a “ordem de leitura natural”.

Pesquisas recentes tratam a ordem de leitura como uma tarefa mensurável, e não como um subproduto informal da detecção de layout. LaTeX2Layout, publicado na AAAI 2026, recupera tanto as regiões de layout quanto a ordem de leitura a partir de rastros do compilador e avalia a concordância da sequência com o tau de Kendall separadamente da ancoragem de elementos. O ROOR, da mesma forma, anota a ordem de leitura como relações de ordenação explícitas, em vez de presumir que as caixas de região impliquem uma sequência.

A mesma direção aparece em benchmarks mais recentes de documentos visualmente ricos. MosaicDoc, também publicado na AAAI 2026, combina anotações de OCR, de ordem de leitura, de localização e de perguntas e respostas sobre documentos em layouts complexos de jornais e revistas. A lição útil não é uma pontuação específica de benchmark:  localizar as regiões corretas e ordenar essas regiões são capacidades diferentes, portanto um conjunto de avaliação não deve tratá-las como intercambiáveis.

Se a sequência importa para a tarefa downstream, a sequência precisa de seus próprios rótulos de referência.

A extração de tabelas tem pelo menos dois modos de falha distintos. Um modelo pode ler incorretamente o texto dentro de uma célula ou pode ler o texto corretamente e, ainda assim, atribuir a célula à linha, à coluna ou à hierarquia visual do cabeçalho de forma errada. Um único número de acurácia combinada torna essas falhas difíceis de diagnosticar.

A Similaridade baseada em Distância de Edição de Árvore (TEDS), introduzida com o PubTabNet, compara uma representação prevista da tabela com a referência como uma árvore. As variantes apenas estruturais, comumente reportadas como TEDS-Struct ou TEDS-S, ignoram o texto da célula para que erros de transcrição não dominem a pontuação estrutural. Os benchmarks atuais de extração de tabelas de 2026 ainda reportam TEDS e TEDS-S separadamente, exatamente por esse motivo.

Essa separação é útil operacionalmente. Se o desempenho cair após uma mudança no modelo, uma equipe precisa saber se a regressão veio do OCR, de uma célula mesclada não detectada, de um limite de coluna deslocado ou de uma relação incorreta entre cabeçalho e corpo. Esses problemas exigem correções diferentes.

O domínio do conjunto de dados também importa. O PubTabNet foi construído a partir de tabelas de artigos científicos, enquanto o FinTabNet foi criado a partir de documentos financeiros. Um modelo que lida bem com uma população pode ter dificuldade quando a gramática de layout muda, especialmente em relação a cabeçalhos aninhados, subtotais, células mescladas e formatação financeira densa.

Suponha que um formulário contenha três ocorrências do rótulo “Date”: data da fatura, data de vencimento e data de entrega. Um modelo pode localizar cada rótulo e cada valor de data, transcrever corretamente todos os seis trechos e ainda assim falhar se os associar incorretamente.

É por isso que a extração de campos frequentemente precisa de rótulos de relacionamento, e não apenas de caixas. O conjunto de dados FUNSD original deixa essa distinção explícita: ele rotula entidades semânticas, como perguntas e respostas, e registra separadamente os vínculos entre essas entidades. A anotação diz não apenas “este texto existe aqui”, mas também “estas duas partes andam juntas”.

A parte difícil é definir a unidade que pode ser vinculada. Um endereço multilinha pode ser um único valor, várias linhas ou um conjunto de campos aninhados. Um esquema vago permite que cada anotador faça uma escolha diferente, o que transforma a discordância em ruído na verdade de referência.

Esse risco não é teórico. Pesquisadores que revisitaram o FUNSD documentaram rótulos inconsistentes e revisaram o conjunto de dados para detecção de chave-valor. Trabalhos posteriores de reanotação continuaram a destacar inconsistências de granularidade e de vinculação. A lição prática é simples: defina os limites das entidades e as regras de vinculação com exemplos difíceis antes que uma grande equipe de anotação comece.

A pré-rotulagem assistida por modelo pode reduzir o trabalho repetitivo. Um modelo pode propor caixas, campos, tabelas ou vínculos, e um revisor pode corrigi-los. Mas a proposta deve continuar sendo uma proposta: os revisores precisam ser treinados para procurar erros estruturais aparentemente plausíveis, em vez de assumir que a saída confiante de um modelo já é a verdade de referência.

A ausência de um vínculo não é o mesmo defeito que a ausência de um campo. O rótulo e o valor podem estar ambos presentes e perfeitamente transcritos, enquanto a relação entre eles está errada.

Uma página nem sempre é a unidade de avaliação adequada. Uma tabela pode começar na página 4 e continuar na página 5. Um lote digitalizado pode conter três faturas consecutivas porque chegaram como um único PDF. Uma referência no corpo do texto pode apontar para um apêndice várias páginas adiante. Um título de seção pode estabelecer uma hierarquia que continua ao longo das quebras de página.

Essas relações precisam de rótulos em nível de documento se a aplicação depender delas. Exemplos úteis incluem:

• Continuação de tabela  -  se dois fragmentos pertencem à mesma tabela lógica e como a continuação deve ser unida.

• Limites de documento  -  onde um documento lógico termina e o próximo começa dentro de uma digitalização ou pacote combinado.

• Referências cruzadas  -  para qual figura, tabela, seção ou nota uma referência realmente aponta.

• Estrutura hierárquica  -  como títulos, subtítulos e seções do corpo se aninham ao longo de todo o documento.

Isso é mais difícil de anotar de forma consistente do que desenhar caixas em páginas isoladas. Os revisores precisam de contexto suficiente para entender o documento inteiro, e o trabalho é menos fácil de dividir entre pessoas sem perder a continuidade.

Os benchmarks públicos refletem cada vez mais essa realidade. O DUDE foi projetado em torno de documentos visualmente ricos com várias páginas e vários domínios, enquanto o VRDU enfatiza esquemas ricos, modelos complexos, campos repetidos e aninhados, e diversidade de layout em documentos empresariais. Para um conjunto de dados de produção, o ponto não é imitar um benchmark. É decidir de quais relações entre páginas a aplicação real depende e rotular essas relações deliberadamente.

Métricas separadas não são mera organização acadêmica. Elas tornam as falhas diagnosticáveis.

Imagine que um sistema de extração de campos piora após uma atualização do modelo. Se o único resultado for “92% de acurácia”, o número não diz à equipe onde procurar. A regressão pode vir do reconhecimento de texto, da ordem de leitura, da estrutura de tabelas, da vinculação de campos, dos limites do documento ou de vários deles ao mesmo tempo.

Um conjunto de avaliação útil mantém esses sinais distintos o suficiente para que possam ser investigados. Isso não significa que todo projeto precise de uma dúzia de métricas de dashboard. Significa que a métrica relatada deve corresponder à afirmação feita. Se o alvo for transcrição, apresente uma métrica de transcrição. Se o alvo for estrutura de tabela, apresente uma métrica de estrutura. Se o alvo for extração de chave-valor, defina como a detecção de entidades e a vinculação são pontuadas.

Se dois erros exigem correções diferentes, eles normalmente devem continuar distinguíveis na avaliação. Uma pontuação resumida ainda pode ser útil, mas não deve substituir as medidas dos componentes necessárias para diagnosticar o que mudou.

Uma métrica de qualidade sem seu método de medição não é evidência. “95% de acurácia” só se torna útil quando o leitor sabe o que contou como correto, quais rótulos de referência foram usados e como os casos ambíguos foram resolvidos.

As mesmas palavras podem criar um problema de compreensão de documento muito diferente quando o layout muda. Isso faz da variação controlada de design uma forma útil de testar se um modelo aprendeu a estrutura do documento ou apenas padrões familiares.

Um experimento prático é manter o conteúdo constante e alterar uma variável de layout por vez:

• texto em coluna única versus duas colunas;
• um valor de campo colocado ao lado do seu rótulo versus alinhado a uma distância;
• um cabeçalho de tabela simples versus cabeçalhos mesclados ou aninhados;
• uma legenda diretamente sob uma imagem versus um destaque flutuante;
• uma tabela mantida em uma página versus a mesma tabela continuada em uma segunda página.

Execute as variantes pelo mesmo pipeline de OCR/IA para documentos e pontue a transcrição e a estrutura separadamente. Se as palavras permanecerem corretas enquanto a ordem de leitura, a topologia da tabela ou os vínculos de campo se deteriorarem, o teste isolou um problema de generalização de layout, e não um problema de OCR.

Para uma publicação voltada ao design, este é um ângulo de ganho de informação mais crível do que outra lista genérica de benefícios da IA para documentos. Isso transforma o design da página em uma variável controlada que pode ser medida. Não publique resultados numéricos a menos que o experimento seja realmente executado e sua metodologia seja documentada.

Um projeto não precisa de todas as camadas por padrão. Ele precisa das camadas que correspondem a decisões reais a jusante. Um sistema de classificação de documentos pode não precisar de rótulos de tabela no nível da célula. Um sistema de automação de faturas provavelmente precisa deles. O objetivo não é a densidade máxima de anotação; é ter dados de referência suficientes para avaliar as tarefas que realmente importam.

Os erros caros costumam acontecer antes de o primeiro lote de produção ser rotulado. Um pipeline viável é assim:
1. Defina o esquema primeiro. Decida o que conta como campo, tabela, unidade de ordem de leitura e limite do documento. Inclua exemplos difíceis em vez de apenas páginas ideais.

2. Execute um lote piloto. Use uma amostra pequena, mas variada, para encontrar divergências nas diretrizes antes que elas se espalhem por milhares de páginas.

3. Meça a divergência onde a ambiguidade importa. Nem todo rótulo precisa de uma estatística formal de concordância entre anotadores, mas divergências recorrentes devem acionar uma mudança nas diretrizes ou uma regra de adjudicação, em vez de uma média silenciosa.
4. Use a pré-rotulagem assistida por modelo de forma seletiva. Automação é útil para propostas repetitivas, enquanto a atenção humana deve se concentrar em relacionamentos e casos limite que saem caros quando errados.
5. Pontue conteúdo e estrutura separadamente. Mantenha transcrição, topologia de tabela, vinculação de entidades e relacionamentos entre páginas distintos o suficiente para diagnosticar regressões.
6. Versione o esquema e preserve a proveniência. Uma equipe deve conseguir dizer qual versão das diretrizes produziu um rótulo, como ele foi revisado e por que uma exceção foi aceita.

O esquema útil mais enxuto é melhor do que um esquema elaborado que ninguém consegue aplicar de forma consistente. Defina apenas os rótulos que respondem a perguntas reais de modelo ou de produto e, em seguida, torne esses rótulos reproduzíveis.

Se você está licenciando, contratando ou aprovando um conjunto de dados de documentos, faça perguntas que exponham a estrutura por trás do número de acurácia em destaque:
• Qual é a unidade de anotação da ordem de leitura: palavras, linhas, blocos ou regiões?
• A estrutura da tabela e o texto das células são avaliados separadamente?
• As relações chave-valor são rotuladas explicitamente ou inferidas por proximidade?
• Como campos repetidos, aninhados e multilinha são tratados?
• Há rótulos de continuação e de limite de documento disponíveis entre as páginas?
• Quais casos ambíguos estão documentados nas diretrizes de anotação?
• Houve um piloto e um processo de adjudicação para divergências entre revisores?
• A versão do conjunto de dados pode ser rastreada até uma versão de esquema e um lote de produção?
• Quais métricas são relatadas e o que exatamente conta como uma previsão correta?

Essas perguntas frequentemente revelam mais sobre a adequação do conjunto de dados do que um único número agregado de acurácia.

Se você ainda está na etapa anterior de obtenção de dados, o guia da DesignWizard para encontrar conjuntos de dados profissionais para projetos de aprendizado de máquina abrange a descoberta e a obtenção de conjuntos de dados de forma mais ampla. Este artigo começa em uma etapa posterior, quando a pergunta passa a ser o que os próprios rótulos de referência precisam conter.

Para equipes que contratam conjuntos de dados de documentos, a página da Wavebreak Media sobre conjuntos de dados de documentos para treinamento de IA abrange conjuntos de dados de documentos licenciados e personalizados para OCR, compreensão de layout, extração de campos, tabelas e metadados estruturados. Para projetos comerciais, suas orientações sobre licenciamento de conjuntos de dados de IA também abrangem direitos de uso, proveniência, liberações e documentação de suporte. Um projeto de IA para documentos ainda deve definir seu próprio esquema estrutural e critérios de aceitação, em vez de presumir que a palavra “anotado” abrange as relações de que precisa.

O que é o ground truth documentado de IA?

O ground truth de Document AI é um dado de referência verificado usado para treinar ou avaliar sistemas que interpretam documentos. Dependendo da tarefa, pode incluir transcrição, ordem de leitura, estrutura de tabelas, relações entre campos, limites de documentos e vínculos entre páginas.

Qual é a diferença entre a acurácia de OCR e a acurácia de Document AI?

Métricas de OCR como CER e WER medem se o texto foi reconhecido corretamente. A avaliação de Document AI também pode precisar medir se as regiões foram ordenadas corretamente, se as tabelas foram reconstruídas corretamente, se os campos foram vinculados aos valores certos e se as relações entre páginas foram preservadas.

Quais anotações um conjunto de dados de Document AI precisa?

Apenas as anotações exigidas pela tarefa downstream. Um extrator de formulários pode precisar de vínculos chave-valor e regras de campos repetidos; um sistema de tabelas pode precisar de anotações de linha, coluna, span e cabeçalho; um fluxo de trabalho multipágina pode precisar de limites de documentos e rótulos de continuação.

Como você avalia a ordem de leitura em um documento?

Primeiro, defina a unidade que está sendo ordenada, como blocos ou regiões, e depois compare a sequência prevista com uma sequência de referência. Benchmarks de pesquisa usam medidas de ranking, como o tau de Kendall, mas a métrica apropriada depende da anotação e da tarefa.

Como a acurácia da estrutura de tabelas é medida separadamente do OCR?

Métricas como TEDS-Struct ou TEDS-S comparam a estrutura da tabela excluindo o texto das células. Isso permite que erros estruturais, como associação incorreta à linha/coluna ou spans ausentes, sejam avaliados separadamente de erros de transcrição.

Um conjunto de dados de OCR existente pode ser reutilizado para a avaliação de Document AI?

Às vezes, mas geralmente apenas para as camadas que ele já rotula. Se a aplicação depende da ordem de leitura, da estrutura de tabelas, de vínculos entre campos ou de relações entre páginas, esses rótulos talvez precisem ser adicionados antes que o conjunto de dados possa ser usado para avaliar a tarefa completa.

Como você avalia sistemas de Document AI para documentos de várias páginas?

Use referências em nível de documento para as relações que cruzam os limites das páginas: continuação de tabelas, limites de documentos, seções hierárquicas e referências cruzadas. A acurácia por página sozinha não consegue mostrar se essas relações foram preservadas.

O que um comprador deve verificar antes de contratar serviços de anotação de documentos?

Pergunte quais relações são rotuladas explicitamente, como os casos difíceis são definidos, como os revisores resolvem divergências, qual processo de QA é usado e o que cada métrica relatada realmente mede.

O erro mais fácil de medir em IA para documentos é um caractere incorreto. Muitas das falhas custosas acontecem depois que os caracteres já estão corretos.

Uma célula de tabela fica sob o cabeçalho errado. Um valor é vinculado ao rótulo errado. Duas colunas são lidas na ordem errada. Uma continuação de tabela é tratada como uma nova tabela porque o conjunto de avaliação nunca registrou que as páginas pertenciam umas às outras.

Uma boa verdade de referência torna essas relações visíveis. A precisão do texto indica o que foi reconhecido; a verdade de referência estrutural indica se a saída foi organizada da forma que a tarefa exige.

Essa é a linha divisória útil para a avaliação: se uma decisão a jusante depende de uma relação, a especificação do conjunto de dados deve indicar como essa relação é representada, revisada e pontuada.