Pare de Enviar Todas as Páginas para um Modelo de Visão: Lições de Pesquisadores do Citigroup, EY e NVIDIA

Quando equipes de engenharia constroem pipelines de documentos para Geração Aumentada por Recuperação (RAG), a conversa quase imediatamente se transforma em uma disputa de modelos. Você deve chamar o Gemini 3.1 Pro? Rotear páginas para o Mistral OCR v3? Usar um modelo compacto como o Granite-Docling?

Um artigo de Abbas Raza Ali (Citigroup), Muhammad Ajmal Siddiqui (Ernst & Young) e Moona Zahid (NVIDIA), intitulado Smart Content Ingestion for Generative AI Workloads, traz uma dose fria de realidade de produção para essa discussão. Publicado como preprint em 5 de outubro de 2026, ele está em revisão para o MLSys 2027.

Ao relatar medições em um corpus interno de 180 documentos que abrangem 10.507 páginas, os autores destacam dois números que devem orientar o design da sua arquitetura de ingestão:

1. Cerca de 77% do tempo de relógio (wall-clock time) de extração foi gasto em pré-processamento compartilhado na configuração mais rápida. O aprimoramento de imagem e a análise de layout (layout parsing) consumiram cerca de 2.062 segundos, em comparação com 611 segundos de inferência do Mistral OCR. Na configuração mais lenta, a inferência do Granite-Docling levou aproximadamente 1.350 segundos, deixando o pré-processamento em cerca de 60% do tempo total de extração.
2. Cerca de 92% das páginas seguiram a rota de extração nativa. Das 10.507 páginas, 853 ultrapassaram o limiar de área de imagem do sistema para OCR em nível de página. As 9.654 páginas restantes seguiram o caminho nativo com custo de modelo quase nulo, embora figuras extraídas ainda pudessem disparar legendagem por visão computacional (vision captioning).

Se você direciona todos os documentos integralmente para uma API de visão, essa arquitetura sugere uma alternativa: extraia primeiro o conteúdo diretamente acessível e reserve o OCR em nível de página para páginas com predominância de imagens. A ingestão de documentos não é apenas um exercício de engenharia de prompt. O artigo a trata como um pipeline de sistemas em quatro etapas, no qual erros de parsing no início do fluxo (upstream) podem deixar a recuperação no final do fluxo (downstream) sem as informações necessárias.

A camada de percepção de sistemas agênticos

No aprendizado de máquina tradicional, a preparação de dados era restrita e vinculada a esquemas (schemas). Tarefas, representações de dados, rótulos e arquiteturas de modelos eram fortemente acoplados.

A IA generativa mudou essa relação. Modelos de fundação oferecem suporte a múltiplas tarefas downstream por meio de instruções em linguagem natural e contexto. À medida que o lado dos modelos se tornou mais genérico, o lado dos dados trouxe seu próprio desafio: o conhecimento corporativo reside em PDFs, apresentações de slides, planilhas, documentos digitalizados, formulários, tabelas e diagramas.

Esses arquivos concentram informações textuais, visuais, geométricas e estruturais em um único artefato. Se um parser de ingestão achata um documento de duas colunas em linhas intercaladas ou perde as relações dentro de uma tabela financeira, os componentes downstream recebem uma representação corrompida. Um recuperador vetorial (vector retriever) não consegue recuperar de forma confiável informações ausentes de seu índice. Um re-ranker não consegue restaurar alinhamentos de colunas que a extração descartou.

Os autores posicionam a extração mensurada de conteúdo como a camada de percepção de sistemas agênticos corporativos. O argumento deles é que o raciocínio downstream depende de representar a fonte corretamente nessa fronteira.

O artigo apresenta uma arquitetura de produção dividida em quatro fases sequenciais:

• Fase 1: Extração de Conteúdo Multimodal, combinando roteamento seletivo de OCR com extração nativa heurística.
• Fase 2: Curadoria e Avaliação de Extração, usando amostragem multi-rótulo orientada à escassez (scarcity-first) para auditar parsers contra o ground truth.
• Fase 3: Chunking Pai-Filho Sensível à Estrutura (Structure-Aware Parent-Child Chunking), desacoplando unidades de recuperação de contextos de leitura.
• Fase 4: Avaliação de Recuperação Somente Leitura, gerando perguntas sintéticas fundamentadas (grounded) para testar a capacidade de recuperação.

Três princípios de engenharia regem o design: estrutura antes da semântica, nunca modifique o que você mede e defina um orçamento para seus rótulos.

Roteamento seletivo: Deixe o PyMuPDF carregar o tráfego pesado

A principal percepção de eficiência na Fase 1 é simples: extrair conteúdo diretamente acessível sem OCR e usar uma heurística de área de imagem para rotear páginas com predominância de imagens para modelos de visão.

Para cada página de PDF de entrada $p$, o sistema calcula uma taxa de cobertura de área de imagem:

$$r(p) = \frac{A_{\text{img}}(p)}{A(p)}$$

Se a área total de imagens incorporadas $A_{\text{img}}(p)$ exceder 80% ($\tau_{\text{cov}} = 0,8$) da área total da página $A(p)$, a página é roteada para OCR. Caso contrário, permanece no caminho de extração nativa alimentado pelo PyMuPDF.

No conjunto de dados Orion dos autores, composto por 180 documentos, 853 de 10.507 páginas (8,1%) seguiram a rota de OCR. As 91,9% restantes seguiram a extração nativa. Essa é uma divisão de roteamento observada no Orion, não uma estimativa para documentos corporativos em geral.

Separadamente, o mecanismo de curadoria aplica um teste de dois sinais ao rotular páginas digitalizadas (scanned):

$$s(p) = 1_{|T(p)| < \kappa ;\wedge; r(p) > \tau_{\text{cov}}}$$

Com $\kappa = 40$, uma página deve ter menos de 40 caracteres extraíveis, bem como alta cobertura de imagem, para receber o rótulo de digitalizada. Isso impede que uma página com uma fotografia grande e uma camada substancial de texto seja rotulada incorretamente como digitalizada durante a curadoria. Isso não altera a regra baseada apenas na área utilizada pelo roteador de extração.

Para páginas com predominância de imagem, o artigo descreve uma sequência opcional de aprimoramento: remoção de bordas, estimativa de ruído via variância Laplaciana para escolher entre filtros Gaussiano, bilateral ou de médias não locais (non-local-means), Equalização Adaptativa de Histograma com Limitação de Contraste (CLAHE), máscara de nitidez (unsharp masking) e upscaling cúbico. As páginas rasterizadas vão então para um back-end de OCR. A infraestrutura de inferência inclui tratamento de repetição (retry) e recuo (back-off) para respostas 429/5xx e atualização de token OAuth2 em caso de 401.

Reconstrução determinística de layout sem deep learning

Para páginas com texto nativo, a etapa de reconstrução estrutural evita modelos aprendidos. Em vez disso, baseia-se em heurísticas determinísticas:

• Calibração de tamanho de fonte: O extrator calcula o tamanho de fonte modal $f^$ em todo o documento, tratando-o como texto de corpo padrão. Tamanhos de fonte distintos que satisfazem $f \ge 1,12 f^$ tornam-se candidatos a títulos (headings). Esses tamanhos são ordenados de forma decrescente em níveis hierárquicos, até uma profundidade configurada, para emitir títulos em Markdown.
• Supressão de cabeçalho e rodapé: O sistema inspeciona blocos de texto dentro das margens da página, normaliza dígitos para que "Page 4" e "Page 9" compartilhem uma chave, e descarta o conteúdo de margem correspondente que se repete em mais de 50% das páginas.
• Detecção de tabelas em dois níveis: Tabelas com linhas demarcadoras (ruled tables) são capturadas usando lines_strict no PyMuPDF. Quando a estratégia de tabela é definida como auto, um detector de alinhamento de palavras também busca tabelas sem bordas, agrupando palavras em linhas e colunas por meio de uma tolerância de alinhamento no eixo x. Uma proteção (guard) rejeita textos em prosa lado a lado que se assemelham a uma tabela.
• Reconciliação com granularidade de linha: Em vez de descartar um bloco de texto inteiro que se sobrepõe a uma tabela detectada, este pipeline testa cada linha individualmente. Uma linha só é suprimida se mais de 50% de sua área estiver dentro do retângulo da tabela, preservando frases próximas que apenas compartilham um bloco de texto com um fragmento de tabela.
• Desduplicação de raster: Imagens rasterizadas incorporadas maiores que $32 \times 32$ pixels são desduplicadas usando hashes MD5 e representadas por marcadores de posição (placeholders) de figuras, como ## Figure-{page}.{n}. Os marcadores restantes acionam a geração de legendas por visão computacional (vision captioning), com Gemma-3 e Llama-4-Scout entre os modelos apresentados na arquitetura.

A saída da Fase 1 é um Markdown com tags preservando marcadores explícitos de ### Page: N, tabelas e figuras. A reconstrução estrutural nativa e a legendagem por visão são partes distintas desse processo.

A armadilha da escassez: Auditando a extração quando 90% dos dados são texto

Antes de enviar o Markdown extraído para um modelo de embedding, você precisa saber se o seu extrator realmente funcionou. Isso nos leva à Fase 2: curadoria de dados e avaliação da extração.

Avaliar a extração de documentos em repositórios corporativos esbarra em um problema persistente de amostragem. Se a maioria das páginas for de texto simples, uma amostra aleatória pode deixar páginas digitalizadas, diagramas e infográficos com poucos exemplos para estimar a qualidade da extração. Modalidades raras precisam de representação deliberada no conjunto de avaliação.

Os autores formalizam isso como um problema de cobertura (covering problem) com múltiplos rótulos por página. A taxonomia inclui as categorias Scanned (Digitalizado), Text (Texto), Table (Tabela), Diagram (Diagrama), Graph/Infographic (Gráfico/Infográfico) e Photo/Signature (Foto/Assinatura).

Dadas as cotas-alvo $t_m = \lceil \phi_m N \rceil$ para cada modalidade ao longo de um orçamento total de $N$ páginas, o Algoritmo 1 aplica uma heurística gulosa orientada à escassez (scarcity-first):

1. Ordenar as modalidades em ordem crescente de sua cota-alvo. Essa ordem segue as cotas configuradas, não necessariamente sua frequência observada no corpus.
2. Para a modalidade ativa, classificar as páginas candidatas por uma pontuação de utilidade (helpfulness score): o número de outras cotas ainda não atendidas que uma página também satisfaz.
3. Selecionar páginas enquanto essa modalidade tiver uma cota não atendida e restarem candidatos, atualizando os déficits em todos os rótulos correspondentes.
4. Completar com páginas não selecionadas ou podar seleções de baixa utilidade para atingir o orçamento de páginas, reportando em seguida a cobertura pretendida versus a atingida.

O método é uma heurística, não uma garantia de que todas as cotas possam ser atendidas. As páginas selecionadas podem ser exportadas como PDFs isolados de página única ou documentos de origem completos quando o contexto for importante. Uma planilha de seis abas registra a configuração, as seleções, as estatísticas e a distribuição alcançada. A digitalização do ground truth e a validação humana são então realizadas na amostra.

Pontuando a fidelidade de textos e tabelas

O framework de avaliação normaliza o texto por meio de Unicode NFKC, case-folding, unificação de pontuação e ligaduras, remoção de Markdown e HTML e colapso de espaços em branco. Ele calcula a Taxa de Erro de Caracteres (Character Error Rate - CER) e a Taxa de Erro de Palavras (Word Error Rate - WER) via distância de Levenshtein, além de precisão, revocação (recall), F1, F1 de bag-of-words, BLEU-4 suavizado e uma razão de comprimento $(|\hat{c}| / |c|)$.

Essa razão sinaliza possível superprodução ou perda de conteúdo. Ela não determina, por si só, se o texto extra é duplicação ou alucinação.

Para tabelas, o avaliador adiciona comparação estrutural usando a Similaridade Baseada em Distância de Edição de Árvore (TEDS - Tree Edit Distance-based Similarity). Tabelas com barras verticais (pipes) e HTML são analisadas em grades retangulares e modeladas como árvores (table -> row -> cell). A similaridade reportada assume a forma:

$$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

Isso mede a organização da tabela e, no modo sensível ao conteúdo descrito, as diferenças entre as strings das células.

Por fim, os back-ends são classificados usando uma pontuação composta ($Q_m \in [0, 100]$):

$$Q_m = 100 \cdot \frac{\sum_j w_j \mu_{j,m}}{\sum_j w_j} \cdot \text{cov}_m$$

As métricas são orientadas à acurácia e combinadas usando pesos configuráveis. A variável $\text{cov}_m$ representa a fração de arquivos esperados para os quais o modelo produziu saída. Arquivos ausentes reduzem a pontuação proporcionalmente, penalizando explicitamente um mecanismo que pula documentos difíceis.

O resultado é uma pontuação de avaliação configurável, não uma porcentagem isolada de conteúdo extraído corretamente.

Chunking pai-filho: Cartões pequenos dentro de pastas grandes

A Fase 3 aborda o chunking. O artigo descreve dois modos de falha concorrentes:

• Chunks grandes podem diluir a contribuição de uma passagem relevante em um embedding. Sob a aproximação de mean-pooling do artigo, uma frase relevante contribui menos à medida que o número de frases aumenta.
• Chunks pequenos podem fragmentar uma resposta em pedaços que, individualmente, são correspondências ruins para recuperação.

A arquitetura lida com esse trade-off desacoplando a unidade de recuperação da unidade de contexto.

As unidades recuperadas são os filhos (children): fichas de índice focadas com meta de 320 tokens e um teto de 512 tokens para texto em prosa normal. As unidades de contexto são os pais (parents): pastas estruturais com um máximo configurado de 3.500 tokens. Esses não são limites incondicionais: frases individuais excessivamente longas e tabelas ou figuras atômicas são preservadas inteiras, e uma tabela ou figura muito grande também pode exceder o limite do pai.

Os filhos passam por embedding com GTE, são normalizados por L2 e indexados no FAISS usando um índice de produto interno exato (IndexFlatIP). Os pais são armazenados em um mapa chave-valor de parent_id para o texto do pai.

No momento da consulta, a busca vetorial recupera as fichas filhas. A expansão de um filho para seu pai armazenado requer uma única busca $O(1)$. Essa complexidade descreve a busca de contexto, não a busca vetorial ou a consulta completa.

Document Markdown
       │
       ▼
[Pasta da Seção Pai: máximo configurado de 3.500 tokens]
       │                                      (Armazenamento Chave-Valor)
       │
       ├──► Cartão Filho 1: meta ~320 tokens (Índice FAISS)
       │      Prefixo opcional: "Doc > Section > Subsection (p.4)"
       │
       ├──► Cartão Filho 2: meta ~320 tokens (Índice FAISS)
       │      Prefixo opcional: "Doc > Section > Subsection (p.4)"
       │
       └──► Cartão Filho 3: tabela atômica inteira (Índice FAISS)

As quatro regras de empacotamento

O empacotamento de frases dentro de pack_sentences() segue quatro regras:

• Regra 1 (Orçamento de tokens): Ter como meta cerca de 320 tokens usando o tokenizador do GPT-2, com um teto de 512 tokens para o empacotamento de prosa comum.
• Regra 2 (Preservação de frases): Nunca cortar no meio de uma frase. Dividir na pontuação preservando aspas e colchetes finais. Se uma frase exceder o teto, emita-a como um chunk isolado em vez de truncá-la.
• Regra 3 (Sem migalhas / No crumbs): Se um grupo empacotado ficar abaixo do limiar mínimo de tokens, mescle-o com as frases sem sobreposição do chunk anterior quando o tamanho combinado respeitar o teto.
• Regra 4 (Tabelas e figuras atômicas): Quando o empacotador encontra uma tabela ou figura, ele descarrega (flushes) o texto pendente e emite a unidade estrutural inteira como um único filho, inclusive quando essa unidade excede o orçamento normal de tokens.

Quando um chunk é encerrado porque a frase seguinte excederia o teto, o sistema transporta até 48 tokens de frases inteiras finais para o chunk seguinte.

Para adicionar contexto posicional sem uma reescrita por LLM, breadcrumbs opcionais prefixam o texto de embedding de cada filho com seu endereço estrutural: Document > Title > Section > Subsection (p.N). O texto bruto e sem prefixo é preservado separadamente para exibição.

Auditando a recuperação: 25.050 perguntas com um avaliador somente leitura

A Fase 4 fecha o ciclo com o RetrievalEvaluator. Seguindo o princípio de nunca modifique o que você mede, o framework abre o índice usando faiss.IO_FLAG_READ_ONLY. Ele reutiliza exatamente a mesma impressão digital (fingerprint) de embedding GTE e a gramática de tags de página usadas durante a indexação.

O avaliador gera perguntas sintéticas fundamentadas (grounded) usando o Mistral-Medium para páginas que contenham pelo menos um número mínimo configurado de tokens. Seu prompt solicita perguntas factuais específicas e perguntas amplas que sintetizem o conteúdo ao longo da página, exige JSON puro e proíbe conhecimento externo. Essas instruções restringem a geração; elas não provam de forma independente que cada pergunta gerada seja válida.

Cada pergunta passa por embedding com GTE e é pesquisada dentro de seu documento de origem usando o IDSelectorBatch do FAISS, com um fallback de filtro exaustivo quando o suporte a seletores não estiver disponível. Os filhos recuperados são desduplicados por parent_id, mantendo o filho de maior pontuação por pai. A busca busca candidatos a mais (over-fetching) para dar suporte ao retorno de pais distintos.

Um acerto (hit) é registrado se o filho candidato ultrapassar um limiar de similaridade de cosseno $s(q, c) \ge \theta$ e sua página de origem estiver a no máximo uma página ($\delta = 1$) da origem da pergunta:

$$\text{hit}(q, c) = 1_{s(q, c) \ge \theta ;\wedge; |\pi(c) - \pi(q)| \le \delta}$$

No corpus Orion, o examinador gerou e avaliou 25.050 perguntas em 180 documentos:

• hit@1: 68,58%
• hit@3: 82,30%
• hit@5: 87,66%
• hit@10: 92,77%
• Mean Reciprocal Rank (MRR): 0,7745
• Rank Mediano (Median Rank): 1,0 (Rank Médio: 1,81)
• Perguntas não encontradas em nenhum dos ranks avaliados: 1.810 (7,2%)
• Latência média por consulta: 0,81 segundos, relatada como dominada por chamadas remotas de embedding

Mais de dois terços das perguntas atenderam ao critério de acerto do avaliador logo no primeiro pai retornado. Ao considerar dez pais distintos, essa fatia atingiu 92,77%.

Esses são resultados de proxy de recuperação. O critério verifica similaridade e proximidade de página, não uma seção-alvo exata rotulada de forma independente ou a correção de uma resposta gerada. Como a busca é restrita ao documento de origem, os números também não medem a localização do documento correto em todo o corpus.

O benchmark de extração: Back-ends maiores vs. modelos compactos

Os autores relatam pontuações de extração para quatro back-ends de produção. As medições vêm dos próprios avaliadores do sistema em corpora internos; não se trata de um leaderboard público independente.

Modelo	Pontuação Composta ($Q_m$)	Taxa de Erro de Caracteres (CER)	Taxa de Erro de Palavras (WER)	Similaridade de Tabela (TEDS)	Tempo de Inferência no Orion	Tempo Total de Relógio no Orion
Gemini 3.1 Pro	97,37	0,13%	0,13%	0,9952	Não relatado separadamente	Não relatado separadamente
Mistral OCR v3	95,98	1,39%	1,55%	0,9737	~611 s	2.672,67 s
Granite-Docling (258M)	92,92	2,60%	2,90%	0,9599	~1.350 s	3.411,86 s
SmolDocling (256M)	90,70	4,43%	4,82%	0,9274	Não relatado separadamente	Não relatado separadamente

Nota: Os totais de tempo de relógio para extração incluem aproximadamente 2.062 segundos de pré-processamento compartilhado, descrito como aprimoramento de imagem e análise de layout. O artigo posiciona os outros dois back-ends entre os extremos de tempo relatados, sem fornecer seus tempos individuais.

O Gemini 3.1 Pro liderou o ranking de acurácia reportado, registrando um CER de 0,13% e uma pontuação TEDS de 0,9952.

O Mistral OCR v3 ficou em segundo lugar com uma pontuação composta de 95,98. Seu CER de 1,39% foi cerca de uma ordem de magnitude maior que o do Gemini, embora tenha apresentado o tempo de extração mais rápido relatado. Seu componente de inferência do modelo levou cerca de 611 segundos, em comparação com cerca de 1.350 segundos do Granite-Docling.

Os modelos compactos, Granite-Docling e SmolDocling, ficaram atrás do Gemini por aproximadamente 4,5 e 6,7 pontos compostos. Seus CERs reportados foram de 2,60% e 4,43%, respectivamente; suas pontuações TEDS foram de 0,9599 e 0,9274. Esses são resultados agregados de benchmark, não medições separadas para texto de corpo simples ou níveis específicos de dificuldade de tabelas.

O artigo também cita trabalhos anteriores de detecção de tabelas por CNN e extração de células por Encoder-Dual-Decoder que relatam 85% de acurácia de palavras em tabelas de imagem. Isso fornece contexto histórico, mas os resultados apresentados não estabelecem uma comparação em conjunto de dados pareado a partir da qual se possa calcular uma melhoria controlada em relação a esse sistema anterior.

Por que isso importa: Os verdadeiros trade-offs para pipelines de documentos em produção

Se você é um líder de engenharia ou gerente de produto construindo ingestão de documentos para busca corporativa ou fluxos de trabalho agênticos, este artigo oferece várias lições operacionais:

1. A chamada de OCR mais barata é aquela que você nunca faz

O roteamento seletivo manteve 91,9% das páginas do Orion fora do caminho de OCR em nível de página. Esse é um resultado concreto que vale a pena testar em seus próprios documentos.

Isso não representa uma redução medida de 91,9% no custo total. A extração nativa ainda tem custos de processamento, e a legendagem de figuras ainda pode invocar modelos de visão. O artigo não fornece preços por página ou uma comparação de faturamento antes e depois. A lição fundamentada é mais restrita: texto diretamente acessível não precisa receber automaticamente OCR em nível de página.

2. O pré-processamento compartilhado merece um lugar no seu orçamento de latência

A Figura 4 torna visível o tempo de extração: cerca de 2.062 segundos foram destinados ao aprimoramento compartilhado de imagens e análise de layout, em comparação com 611 segundos de inferência do Mistral OCR.

Isso coloca o pré-processamento em cerca de 77% do tempo de relógio de extração na configuração mais rápida e cerca de 60% na mais lenta. Os autores o identificam como o próximo alvo de otimização.

As medições não estabelecem utilização de CPU, execução serial ou o ganho de velocidade (speedup) que uma alteração específica em multiprocessamento ou filtros de imagem proporcionaria. Elas mostram, no entanto, por que escolher o back-end de OCR mais rápido deixa uma parte substancial do tempo de extração intocada.

3. A taxa de erro de caracteres é apenas parte da qualidade de extração

Uma pontuação de texto não fornece um relato completo da fidelidade de tabelas. O artigo avalia ambos, combinando métricas em nível de caractere e de palavra com estrutura de tabela e métricas relacionadas a células.

Ao comparar extratores, preserve essa distinção. O TEDS fornece evidências estruturais ao lado de CER e WER; a pontuação composta combina esses sinais, mas não deve ocultá-los.

4. Separe suas fichas de recuperação de suas janelas de contexto

A arquitetura pai-filho do artigo oferece uma maneira concreta de corresponder passagens pequenas ao mesmo tempo em que retorna um contexto mais amplo. Tags estruturais mantêm tabelas e figuras intactas, e breadcrumbs opcionais adicionam a posição no documento ao texto que está sendo incorporado (embedded).

A execução no Orion demonstra que esse design pode ser avaliado em escala. Ela não inclui uma comparação de recuperação controlada provando que o chunking pai-filho supera alternativas de tamanho fixo, semânticas ou outras no mesmo corpus.

Onde o sistema atinge seus limites

Os autores descrevem o sistema como pronto para produção, mas as evidências impõem vários limites sobre como interpretar seus resultados:

• Dependência de perguntas sintéticas: As medições de recuperação usam perguntas geradas pelo Mistral-Medium. O artigo observa explicitamente que essa métrica proxy depende da qualidade do gerador. Ele não relata validação contra um conjunto de consultas de usuários reais.
• Acertos baseados em páginas e com escopo no documento: A busca ocorre dentro do documento de origem da pergunta, e o sucesso depende da similaridade e proximidade de página. Esses resultados não comprovam a seleção de documentos em todo o corpus nem a correção das respostas.
• Avaliação interna e comparações limitadas: As pontuações relatadas são automedições em corpora internos. O artigo não relata uma ablação de chunking ou uma comparação controlada de recuperação contra as estratégias alternativas discutidas.
• Heurísticas de roteamento configuráveis: O limiar de 80% de área de imagem produz a divisão de roteamento reportada no Orion. O artigo não estabelece a acurácia de roteamento em outras populações de documentos, e a regra mais rigorosa de rotulagem de páginas digitalizadas pertence à curadoria, e não ao roteamento de extração.
• O monitoramento permanece em parte uma proposta: CER e WER baseados em referência exigem ground truth. O artigo discute sinais sem referência e estratégias de calibração, mas rotula a justificativa de monitoramento como uma hipótese ou direção futura, em vez de código de calibração em produção. Esses sinais não conseguem reportar uma taxa de erro real por si sós.

Conclusão

A ingestão de documentos merece mais atenção do que um script utilitário montado uma única vez e esquecido. No enquadramento dos autores, ela é a camada de percepção de um sistema de IA generativa.

Ao combinar roteamento seletivo, reconstrução determinística de layout, chunking pai-filho sensível à estrutura e avaliadores somente leitura, o artigo apresenta uma maneira concreta de tornar as decisões de ingestão explícitas e mensuráveis. Sua maior contribuição é a conexão entre esses componentes e as evidências que eles produzem sobre si mesmos.

Antes de passar mais uma semana ajustando prompts ou testando modelos de re-ranking, examine atentamente sua camada de ingestão. Se o seu parser perder as informações da página, a recuperação downstream começará com um problema que talvez não tenha como consertar.