Imagine uma prancha de projeto de um DOT estadual para um entroncamento rodoviário. Uma linha de cota se estende de um poste de guardrail até a borda do pavimento, rotulada como "24'-0"". Por perto, um balão de chamada aponta para um bueiro com uma anotação sobre o diâmetro da tubulação. Nada disso tem uma ordem natural de leitura. O número 24 não significa nada sem a seta à qual está associado, e a seta não significa nada sem os dois pontos que conecta. Agora passe essa página por um OCR. Você obtém um saco de palavras desconexas: "24'-0"", "CULVERT", um diâmetro de tubo, alguns números de estaqueamento, todos corretos como strings extraídas e todos inúteis — porque aquilo que lhes dava significado (qual linha toca qual objeto, onde ela fica na página) desapareceu.

Esse é o problema que um novo artigo chamado PlanSightRAG tenta resolver, e é um excelente exemplo de um modo de falha fácil de ignorar se você pensa no OCR como um problema resolvido. Ele não está resolvido para desenhos técnicos. Está resolvido para documentos compostos predominantemente por frases.

Por que projetos de engenharia civil quebram a cartilha padrão de IA para documentos

A maioria dos sistemas de geração aumentada por recuperação (RAG) para documentos segue a mesma receita: aplicar OCR na página para extrair texto, dividir o texto em blocos (chunks), gerar embeddings desses blocos e deixar que um modelo de linguagem recupere e raciocine sobre eles. Isso funciona razoavelmente bem para contratos, faturas e relatórios, porque a informação reside nas palavras e as palavras são lidas em ordem sequencial.

Plantas padronizadas de engenharia civil não funcionam assim. Uma única prancha de um conjunto de projetos de um Departamento de Transportes (DOT) estadual pode combinar:

Uma vista em planta (olhando de cima para baixo) e uma vista de perfil (uma elevação lateral) na mesma página, em escalas diferentes
Linhas de cota e linhas de chamada que codificam relações puramente por meio da geometria
Símbolos e padrões de hachura que significam coisas específicas por convenção, e não por qualquer rótulo textual
Referências cruzadas a outras pranchas, tabelas e a um caderno de especificações separado que define os limites numéricos reais

Elimine o layout com o OCR e você terá jogado fora a maior parte do que torna o desenho legível. Os autores colocam isso com clareza em seu resumo: a automação baseada em OCR "elimina a geometria e o layout essenciais para interpretar essas plantas". Engenheiros ainda realizam a verificação de conformidade desse material visualmente, folha por folha, cruzando informações com documentos de especificação que podem chegar a centenas de páginas. É um processo lento e é exatamente o tipo de tarefa repetitiva e suscetível a erros em que a automação deveria ser eficiente — exceto pelo fato de que o kit de ferramentas padrão de IA para documentos não serve para ela.

A solução: parar de vez de converter o desenho em texto

A principal sacada do PlanSightRAG é dispensar totalmente a extração de texto via OCR para indexação e recuperação. Em vez de converter uma folha de projeto em texto para depois pesquisar no texto, ele trata cada página como uma imagem e pesquisa imagens a partir de imagens.

A base de sustentação da recuperação é um modelo chamado ColNomic-3B. Para entender o que isso significa, ajuda conhecer a família à qual ele pertence. A recuperação de documentos tradicional pega uma página inteira e a comprime em um único vetor (uma lista de números) que supostamente resume tudo o que há nela. Isso é rápido, mas com perdas: uma página com doze chamadas distintas colapsa no mesmo tamanho de vetor que uma página com apenas um parágrafo. O ColNomic, em vez disso, utiliza uma abordagem multivetor derivada de um método chamado ColPali: ele fatia a imagem em uma grade de patches e produz um vetor separado para cada patch, de modo que uma consulta possa corresponder à região específica da página onde o conteúdo relevante realmente está, e não apenas a uma média da folha inteira. Quando você consulta o sistema (por exemplo, "qual é o afastamento mínimo para este tipo de guardrail?"), ele compara sua busca com cada patch em todas as páginas e encontra as correspondências mais fortes. É por isso que a geometria se preserva. Em nenhum momento você pede a um modelo para descrever o desenho em palavras primeiro.

No topo dessa camada de recuperação opera o que o artigo chama de um pipeline agêntico Planner-Retriever-Auditor-Synthesizer. São quatro funções, cada uma desempenhada por uma etapa do pipeline em vez de um único prompt monolítico:

Planner detalha o que a pergunta está realmente solicitando (quais tipos de pranchas são relevantes, o que precisa ser verificado)
Retriever busca as páginas de projeto candidatas e as páginas de especificação de referência usando a recuperação multivetor do ColNomic
Auditor verifica se a evidência recuperada realmente sustenta uma resposta, em vez de simplesmente repassar o que quer que tenha retornado
Synthesizer gera a resposta final ou o veredito de conformidade, fundamentado nas páginas recuperadas

Outro elemento digno de nota é o que eles chamam de mapas de calor MaxSim (MaxSim heatmaps). Como o modelo de recuperação calcula pontuações de similaridade no nível do patch, é possível visualizar quais patches de uma página determinaram a correspondência. Isso gera um mapa de calor sobreposto ao desenho original, mostrando exatamente onde o sistema identifica a cota, o símbolo ou a nota relevante. Isso tem muito mais importância do que pode parecer à primeira vista. Uma verificação de conformidade que simplesmente retorna "PASS" ou "FAIL" não é algo que um engenheiro possa assinar. Uma verificação de conformidade que retorna "FAIL, e aqui está o ponto exato do desenho que disparou isso" é algo que você pode de fato auditar e confiar — ou flagrar quando estiver errado.

O que os números realmente dizem

A equipe criou um benchmark a partir de material real: 1.898 páginas de plantas padrão de cinco DOTs estaduais, transformadas em 4.056 pares de perguntas e respostas. Em recuperação zero-shot (o que significa que o modelo não foi ajustado previamente nesse conjunto específico de projetos), o PlanSightRAG atingiu 91,47% de Recall@5. Essa métrica significa: para uma dada pergunta, a página fonte correta está entre as 5 primeiras páginas que o sistema recupera? Acertar isso mais de 91% das vezes em desenhos tão densos e não estruturados é um resultado sólido.

O dado mais convincente, a meu ver, é o que aconteceu em um corpus de teste separado (held-out) do DOT de Michigan, que não fazia parte dos cinco estados originais: 91,40% de Recall@5, praticamente idêntico ao resultado dentro da distribuição. Estados diferentes formatam suas plantas padrão de maneiras diferentes. Um sistema que só funciona nos desenhos com os quais foi ajustado não tem muita utilidade para um DOT que não constava no conjunto de treinamento. Generalizar com essa precisão para o formato de plantas de um novo estado é o resultado que realmente sugere que a abordagem está captando a estrutura geral de interpretação de projetos, e não apenas decorando um punhado de layouts.

Onde o artigo se torna mais honesto — e mais interessante

Os resultados da verificação de conformidade são onde quero ir mais devagar, porque o número em destaque exige um asterisco que o próprio artigo fornece.

Em desenhos de conformidade sintéticos e gerados parametricamente (desenhos elaborados com valores conhecidos e controlados programaticamente para que a resposta correta seja inequívoca), um pipeline baseado no Qwen2.5-VL-72B, um modelo de visão e linguagem de 72 bilhões de parâmetros, atinge 100% de acurácia no veredito. Mas apenas sob uma condição específica: quando o sistema recebe de antemão o valor-limite da regra contra o qual deve fazer a verificação, já resolvido em um número. Em outras palavras, se você disser ao modelo "o valor máximo permitido aqui é de 6 polegadas", ele compara corretamente a cota do desenho com 6 polegadas todas as vezes.

Esse é um teto controlado, e o artigo é franco ao admitir que se trata de um teto, e não de uma demonstração de verificação de conformidade ponta a ponta. Ele mostra que o modelo consegue comparar corretamente um número em um desenho com outro número, o que é bom confirmar, mas não é a parte difícil do problema. A comparação genuinamente útil é esta: uma linha de base de OCR sem VLM, sem nenhum modelo de visão envolvido, já atinge 76,4% nessa mesma configuração. Portanto, uma parte substancial desse benchmark específico é solucionável sem compreender absolutamente nada da geometria do desenho, apenas extraindo números e comparando-os. A diferença entre 76,4% e 100% é real, mas é uma margem mais estreita do que "OCR versus um sistema sofisticado de visão" sugeriria à primeira vista — algo que vale a pena lembrar quando um artigo abre com uma taxa de 100%.

O resultado que considero, na verdade, a contribuição mais importante do artigo é o menor e menos chamativo apresentado ao final: a ancoragem autônoma de regras (autonomous rule-grounding). Em vez de receber o limiar de conformidade pronto, o sistema extrai o limite numérico diretamente de um corpus de especificações, sem intervenção humana fornecendo a regra previamente. Essa é a versão da tarefa que se aproxima do que a verificação de conformidade realmente exige na prática: você não recebe o valor da regra pronto; você precisa encontrá-lo em um livro de especificações e, em seguida, aplicá-lo corretamente ao desenho. Esse é um problema muito mais árduo do que comparar dois números previamente resolvidos, e é nele que este sistema precisa ser consistentemente confiável para justificar sua implementação em produção. O artigo demonstra que funciona, sem apresentar um número de acurácia em destaque para isso — o que, por si só, é um sinal de quanto esse componente ainda precisa evoluir antes de estar pronto para benchmarks.

Por que isso importa para quem constrói ou adquire IA para documentos

Se você desenvolve pipelines de documentos que lidam com desenhos de engenharia, plantas arquitetônicas, diagramas elétricos ou qualquer outro material em que o significado esteja na relação espacial entre marcas e não nas palavras em si, este artigo é um argumento concreto a favor de uma regra que vale a pena internalizar: não aplique OCR primeiro para fazer perguntas depois. Converter para texto descarta informações que não podem ser facilmente reconstruídas, e nenhuma engenharia engenhosa de prompts sobre a saída do OCR conseguirá recuperá-las.

Para equipes de produto que avaliam fornecedores de OCR ou de IA para documentos, os números de recuperação apresentados aqui (mais de 91% de Recall@5, mantendo-se consistentes no formato de projetos de um estado não visto) representam uma referência genuinamente útil de comparação se você lida com documentos de layout complexo: mapas, desenhos técnicos, formulários com tabelas intrincadas, ou qualquer coisa em que "ler de cima para baixo" não seja a forma como um ser humano abordaria a página.

E para qualquer pessoa tentada a citar o número de 100% no veredito de conformidade em uma apresentação de slides, leia as letras miúdas antes. Esse número descreve um sistema conferindo um valor para o qual a regra já lhe havia sido informada. O teste real — a ancoragem autônoma de regras a partir de um corpus de especificações sem nenhum gabarito entregue de antemão — é o ponto a ser acompanhado, e é também aquele que ainda não conta com uma métrica de acurácia consolidada. Isso não desmerece o artigo. Ser honesto sobre qual parte do pipeline está comprovada e qual é uma demonstração inicial promissora é muito mais valioso para quem atua no setor do que uma porcentagem triunfante isolada.

O que ainda está faltando

Alguns pontos merecem atenção. Os números de recuperação do benchmark vêm de Recall@5 em pares de perguntas e respostas elaborados a partir de plantas de cinco estados, o que é um começo sólido, mas está longe de cobrir toda a diversidade de convenções de formatação de DOTs nos cinquenta estados — sem falar em padrões municipais e de condados que sequer seguem os modelos de DOT. O pipeline de conformidade depende de um modelo de 72 bilhões de parâmetros, o que está longe de ser algo leve para operar em produção, e o artigo não reporta métricas de custo ou latência que indiquem se isso é viável no volume demandado por um órgão real de revisão de DOT. Além disso, os desenhos de conformidade sintéticos, embora sejam um método razoável para obter um ground truth confiável, são mais simples do que os conjuntos de projetos reais — desorganizados, anotados à mão e com décadas de idade — sobre os quais grande parte da análise de infraestrutura ainda opera.

Nada disso enfraquece a ideia central. Tratar uma folha de projeto como uma imagem a ser pesquisada, em vez de uma página a ser transcrita, é o instinto correto para essa categoria de documento, e os resultados de recuperação sustentam essa tese. A parte da história referente à verificação de conformidade está em um estágio mais inicial do que a narrativa inicial sugere, mas o artigo é notavelmente transparente quanto aos limites atuais da tecnologia — o que é mais do que se pode afirmar sobre a maioria dos benchmarks nesse campo.

Lendo plantas rodoviárias sem perder o desenho: uma análise do PlanSightRAG