O motor que tinha seis polos — O mito das dez linhas de código

Investigação em seis partes sobre os motivos pelos quais o chatbot documental que lhe venderam continua a inventar — e sobre a direção diferente que, no início de 2026, alguém começou a seguir.

Investigação em seis partes sobre os motivos pelos quais o chatbot documental que lhe venderam continua a inventar — e sobre a direção diferente que, no início de 2026, alguém começou a seguir.

Intro — O motor que tinha oito polos (mas tinha seis)

Milão, março de 2026. Um gerente abre o chatbot corporativo interno, daqueles montados "em duas semanas" pelo departamento de TI com grande entusiasmo e pouca desconfiança. Pergunta simples: "Quantos polos tem o motor CMP40M?". O chatbot responde com toda a confiança que os grandes modelos de linguagem sabem exibir: "O motor CMP40M tem oito polos."

Errado. Tem seis. A resposta certa não estava no catálogo de 422 páginas que alguém, meses antes, havia depositado com a máxima confiança em um banco de dados vetorial, convencido de que, a partir dali, o sistema "saberia tudo". Esse dado, no catálogo, simplesmente não existia. Estava em um PDF anexado a um e-mail dos técnicos SEW, arquivado em uma pasta que ninguém se deu ao trabalho de indexar.

Essa cena, com variações de setor e de dialeto, se repete em centenas de escritórios italianos. A promessa era simples e sedutora: deem ao seu assistente de IA todos os documentos empresariais, e ele poderá responder a qualquer pergunta sobre eles. A realidade é muito mais prosaica: o chatbot lê, mas não compreende, procura, mas não encontra, e quando não encontra — em vez de dizer — inventa. Inventa com fluidez, com gramática perfeita, com números plausíveis. O que é muito pior do que não responder.

Entre o final de 2024 e o início de 2026, passamos meses fazendo a autópsia desses fracassos. Não para alimentar polêmicas, mas para entender uma coisa: por que uma ideia tão linear — "dê os documentos e depois pergunte coisas" — se torna tão difícil quando sai do palco da demonstração e entra na sala dos servidores reais.

Esta investigação em seis capítulos conta o que encontramos: bugs silenciosos que apagavam catálogos inteiros, rerankers em nuvem com pontuações incorretas, alucinações nascidas não do modelo, mas de dados contaminados anos antes, faturas de saída que tornavam cada consulta mais cara do que seu valor, e frameworks "populares" que prometem tudo em dez linhas de código, desde que não se lhes peça muito. E no último capítulo, a direção diferente que alguém, em silêncio, começou a percorrer no início de 2026 — uma arquitetura em que a estratégia de pesquisa deixa de ser código e se torna um documento que qualquer pessoa, na empresa, pode ler e modificar.

Cada capítulo se sustenta sozinho. Se quiser começar pela história das 342 tabelas desaparecidas, ou pela do reranker mentiroso, está livre para fazê-lo. Mas o relato em seu conjunto tem uma moral que emerge apenas no final: o RAG empresarial — esse acrônimo técnico que significa Retrieval-Augmented Generation, ou seja, "gerar respostas com base em documentos que você recupera primeiro" — ainda não é um produto acabado. É uma fronteira. E como todas as fronteiras, até agora foi contado principalmente pelos vendedores. É hora de ouvir também quem viveu dentro dela.

Capítulo 1 — O mito das dez linhas de código

O slide é idêntico em todas as conferências sobre IA a partir de 2023: "Seu assistente documental corporativo em 10 linhas de código." Abaixo do título, um bloco de Python em cores pastel que mostra uma biblioteca de código aberto — tipicamente uma daquelas famosas americanas, cujo nome evoca cadeias de árvores ou lamas tibetanos — que carrega PDFs, os fragmenta, os cola em um banco de dados vetorial e os consulta com um modelo de linguagem. Em cinco minutos, você tem um chatbot. Em cinco minutos, os aplausos. Em cinco minutos, uma empresa italiana de médio porte se convence de que o problema está resolvido e que seu departamento de TI pode conseguir em duas semanas.

O problema — o que o slide não diz — é que a demonstração é construída com três PDFs bem formatados, uma pergunta feita sob medida para corresponder ao conteúdo, um palco sem latências reais e um apresentador que testou tudo vinte e sete vezes antes de subir. Na realidade, os documentos corporativos são um desastre geológico: digitalizações de digitalizações, tabelas que se sobrepõem ao texto, notas de rodapé que se infiltram nos parágrafos, códigos alfanuméricos como "RH1M" que o fragmentador corta ao meio, pensando que são palavras, imagens que contêm setenta por cento da informação útil, mas que ninguém extrai realmente, e layouts tão criativos que exigem um arqueólogo mais do que um parser.

O RAG — esta é a ideia por trás — é uma ótima ideia. Pegue a pergunta do usuário, procure em seu arquivo os documentos mais relevantes, passe-os para o modelo de linguagem e obtenha uma resposta baseada nesses documentos. Em teoria, resolve elegantemente o problema da alucinação: o modelo não precisa mais "saber" a resposta, ele só precisa "lê-la" nos trechos que você forneceu. Na prática, cada elo da cadeia — o chunking, o embedding, o retrieval, o reranking, a geração final — tem suas próprias maneiras de falhar, e a falha raramente se manifesta como um erro visível. Manifesta-se como uma resposta ligeiramente incorreta. Depois, como uma resposta completamente incorreta. Depois, como um gerente que se pergunta por que está pagando por um sistema que sabe menos que o estagiário.

Os frameworks de código aberto que popularizaram o RAG são feitos para demonstrar, não para produzir. São concatenações elegantíssimas de abstrações em que cada camada esconde uma premissa não dita: que seus PDFs tenham um OCR decente, que suas fotos já tenham sido descritas, que suas tabelas sigam uma convenção, que o modelo de embedding realmente fale a sua língua (spoiler: muitos falam bem apenas inglês), que seu arquivo já tenha sido limpo de duplicatas. Quando uma dessas premissas falha — e pelo menos uma sempre falha, quase sempre três — o sistema não para de funcionar. Pior: para de funcionar bem, mas continua a dar respostas. Respostas fluidas, seguras e, frequentemente, desconectadas da verdade.

Há uma frase que circula entre aqueles que constroem esses sistemas profissionalmente, e que você nunca lerá em tutoriais: "O RAG é fácil de fazer, e difícil de fazer bem." Entre a primeira demonstração e o serviço em produção há um abismo que não se preenche adicionando GPUs ou mudando o modelo. Preenche-se compreendendo algo desconfortável: quando você constrói um RAG empresarial, você não está escrevendo código. Você está projetando um pequeno, obstinado motor de busca sob medida para seus documentos, com todas as escolhas editoriais que isso implica — o que é ruído, o que é sinal, o que deve ser indexado duas vezes, o que deve ser descartado. Só que nos tutoriais de dez linhas, essas escolhas são tomadas por você, uma vez, por alguém que nunca viu seus documentos. E são quase sempre as erradas para o seu caso.