As tabelas que não existiam

Capítulo 2 — As tabelas que não existiam

Um técnico de uma empresa mecânica do Nordeste nos contou isso tomando um espresso, com aquela calma dos venezianos que prenuncia um desastre: "Nosso chatbot sabia tudo sobre o motor. Exceto os dados do motor." Depois ele explicou. Seu assistente de IA interno sabia descrever as linhas de produtos, os contextos de uso, a história da marca, as vantagens competitivas. Uma maravilha, no plano narrativo. Mas quando um cliente perguntava o torque nominal do modelo CMP50L — ou seja, o dado técnico pelo qual as pessoas abrem o catálogo, o número pelo qual se compra um motor — o chatbot respondia de forma vaga, às vezes plausível, às vezes não. Cinco meses de desenvolvimento, o diretor operacional cada vez mais perplexo, e ninguém que soubesse dizer o porquê.

O diagnóstico chegou por acaso, quase por tédio, inspecionando manualmente o banco de dados após a enésima reunião sem conclusão. O catálogo PDF continha 342 tabelas técnicas. No banco de dados, haviam chegado zero. Não algumas poucas: zero. Nenhuma. O código que extraía as tabelas dos PDFs salvava os dados em campos chamados columns e data, enquanto o código que as indexava em seguida esperava campos chamados headers e rows. Um "sinônimo" não respeitado. Uma convenção interna que havia saltado em um refactoring esquecido. O resultado, por cinco meses silenciosos: toda a inteligência numérica do catálogo — pares, potências, diâmetros, pesos, códigos de pedido, tensões de alimentação — saiu da torneira sem nunca ser despejada no copo. Trezentas e quarenta e duas tabelas, perdidas uma por uma em silêncio litúrgico.

Este é o tipo de bug que não grita. Não levanta exceções, não causa crashes, não aparece em nenhum log. Simplesmente, uma parte do mundo cessa de existir para o seu sistema, e ninguém percebe até que um usuário — geralmente um usuário irritado — faça perguntas persistentes o suficiente para mostrar o abismo. E é emblemático de um problema muito maior que os nomes dos campos: os frameworks RAG genéricos são otimizados para o texto corrente — artigos, páginas web, parágrafos de narrativa — e tratam as tabelas como cidadãos de segunda classe, quando as tratam. Mas os documentos empresariais italianos são frequentemente tabelas. Catálogos técnicos, listas de preços, especificações de produto, fichas de segurança, boletins de encomenda: a parte valiosa, para quem consulta estes documentos, é a tabular. Aquela que quebra primeiro e de que ninguém se apercebe.

A lição não é "preste atenção aos nomes dos campos". É mais incômoda: em um RAG sério, cada tipo de conteúdo — tabelas, imagens, códigos alfanuméricos, títulos de parágrafo, notas de rodapé — precisa de um tratamento dedicado, projetado, testado. E o teste de funcionamento não é "o chatbot responde a perguntas banais" — a essas perguntas respondem até os sistemas quebrados, porque há dados flutuantes suficientes para construir algo plausível. O teste verdadeiro é "o chatbot responde a perguntas que o forçam a tocar em cada pedaço do pipeline". Perguntas específicas, numéricas, verificáveis. Perguntas para as quais existe uma resposta certa e uma só, e se o sistema errar você saberá imediatamente.

Se você não fizer este teste, não saberá se o seu RAG funciona. Você saberá apenas que ele não reclama. E "não reclama" é um critério de qualidade muito baixo para um sistema que as pessoas usarão para tomar decisões.