A estratégia como documento — O sétimo capítulo

Capítulo 6 — A estratégia como documento, não como código

Chegamos ao insight que, mais do que qualquer outro, no relato de quem construiu RAG a partir de 2023, recorre como "a coisa que eu gostaria de ter entendido desde o primeiro dia".

Os frameworks tradicionais tratam a estratégia de pesquisa como código Python. Quer, para os catálogos técnicos, pesquisar primeiro por código de produto, depois por palavras-chave, depois por vetores semânticos, e somente em última instância gerar a resposta? Escreva uma função. Quer, para os álbuns fotográficos, pular completamente a pesquisa semântica tradicional e confiar em um reranker especializado para imagens? Escreva outra função. Quer, para os vídeos corporativos, dividir o áudio da trilha visual, transcrevê-los separadamente, tratá-los como fontes distintas e depois recomporlos na resposta final? Mais uma função ainda. Cada tipo de conteúdo, cada domínio, cada cliente acaba gerando um ramo de código que diverge dos outros, até o ponto em que modificar uma estratégia requer um lançamento de software, uma code review, um ciclo de testes, um deploy. O tempo entre "tenho uma ideia sobre como melhorar a pesquisa nos manuais técnicos" e "a ideia está em produção" é medido em semanas. Para cada ideia.

O insight alternativo é trivial de dizer e profundo em suas consequências: a estratégia de pesquisa não é código. É um documento. Um JSON — um formato de texto estruturado que qualquer editor, com meia hora de treinamento, pode ler — que diz: "primeiro tente isto, depois aquilo, se o primeiro falhar passe para o terceiro, reclassifique assim, responda com este modelo." Este documento vive em um banco de dados, não em um repositório. É modificado por uma interface, não por um pull request. É versionado, copiado, especializado por domínio. Uma estratégia para catálogos técnicos, uma para álbuns fotográficos, uma para manuais de instalação, uma para vídeos, uma para áudio, uma para contratos legais, uma para balanços. Todas coexistindo no mesmo sistema. Todas modificáveis em tempo real.

Quem trabalhou com essa abordagem — vamos chamá-la, sem muita imaginação, de Meta-RAG — relata uma mudança de velocidade que vai além da engenharia. Uma solicitação do cliente do tipo "adicione uma pesquisa específica para os códigos de produto que contenham siglas como CMP40M ou RH1M" não é mais um ticket de desenvolvimento de duas semanas. É um novo passo adicionado a um procedimento JSON, testado em um ambiente de staging, promovido para produção em uma tarde. A pergunta "o que muda se usarmos um reranker diferente para as fotos, mantendo o atual para o texto?" é respondida modificando uma linha de configuração. O experimento não custa nada, o rollback não custa nada (basta restaurar a versão anterior do documento), e o conhecimento acumulado — o que funciona bem para um certo tipo de conteúdo — se torna um patrimônio versionado e transferível, não o saber tácito de quem escreveu aquele ramo de código específico e hoje está de férias.

Há também um efeito social interessante que emerge nas organizações que adotam essa abordagem. Com as estratégias como documento, a fronteira entre "desenvolvedor" e "usuário especialista" se desloca. Um bibliotecário digital, um arquivista corporativo, um especialista de domínio — o chefe do escritório técnico, a responsável pela documentação, o gerente de produto que conhece como ninguém as verdadeiras perguntas dos clientes — pode ler uma estratégia, entender o que ela faz, sugerir modificações, às vezes escrevê-las diretamente. Não precisa passar pelo funil do ticket de desenvolvimento, não precisa explicar a um desenvolvedor coisas que o desenvolvedor não sabe (porque não é do seu ofício saber). O RAG deixa de ser um produto que você consome e se torna uma ferramenta que você modela com base no seu conhecimento organizacional. Isso, na experiência de quem o experimentou, muda o moral do projeto antes mesmo dos números das métricas.

Não é magia, e tem seus custos. É necessário um motor que execute essas estratégias como documento de forma eficiente e segura. É necessário uma linguagem de descrição suficientemente rica para cobrir os casos reais e suficientemente pobre para não se tornar outro Turing-completo disfarçado. São necessários ferramentas de versionamento, teste e rollback. Mas tudo isso é problema de quem constrói o motor — uma vez só, e para todos os usuários. O cliente final vê apenas uma coisa: a possibilidade de evoluir sua estratégia de pesquisa à velocidade do pensamento, em vez da velocidade do ciclo de lançamento de software. E isso, para quem está dentro, é uma revolução silenciosa que ainda não encontrou seu nome nas revistas do setor.

Encerramento — O sétimo capítulo, dentro de alguns meses

No início de 2026, somando as lições dos capítulos anteriores — as tabelas que se perdiam, os rerankers mentirosos, as alucinações herdadas, as contas de cloud que cresciam mais rápido que o valor, os frameworks prometedores mas rígidos — alguém, na Itália, começou a construir um servidor RAG diferente. Escrito em Python, pensado para rodar em hardware acessível, capaz de conversar com modelos de cloud quando convém e com modelos locais quando a privacidade o impõe ou o custo não compensa. Um servidor em que as estratégias de pesquisa são documentos modificáveis, o reranker é um processo local em GPU, as tabelas não se perdem porque são tratadas como cidadãos de primeira classe, as fotos não herdam objetos de arquivos empoeirados de outras épocas, e o custo por query — seja em dinheiro ou em dados exfiltrados para terceiros — é conhecível e controlável até o centavo.

Não vamos mencionar o projeto. Este não é o momento para isso, e não queremos transformar uma investigação em publicidade. Mas se os capítulos anteriores o fizeram reconhecer uma situação que você está vivendo — um chatbot corporativo que responde com confiança a perguntas erradas, um projeto RAG que não decola há meses, uma conta de nuvem que cresce mais rápido do que a utilidade que produz, uma dúvida crescente sobre o fato de que seus documentos confidenciais estão viajando para lugares que você não conhece — então vale a pena saber que existe outro caminho, que foi percorrido por alguém na Itália e que em 2026 começou a dar as primeiras respostas que se esperava em 2023.

A boa notícia é que a IA corporativa, finalmente, está saindo da fase de demonstração. A menos boa é que está saindo carregando consigo todas as cicatrizes do percurso: frameworks inchados, dependências de provedores, arquiteturas monolíticas, dados sujos, bugs silenciosos e uma certa tendência do setor de vender soluções antes mesmo de entender o problema. Contamos isso em seis capítulos. O sétimo — a história do que acontece quando finalmente alguém faz as coisas bem, com paciência, em italiano e em código aberto — escreveremos em breve, com menos cautela sobre os nomes e mais números na mesa.

Enquanto isso, se você chegou até aqui, já fez mais autópsia do que 90% dos tomadores de decisão que, neste momento, estão assinando um contrato para um chatbot empresarial sem fazer nenhuma das perguntas que você fez ao ler estes capítulos. É um ponto de partida melhor do que o deles. E nos próximos meses, a diferença entre aqueles que fizeram essas perguntas e aqueles que não fizeram, se tornará muito visível nas faturas — e nas respostas que sua IA dará aos seus clientes.

Esta investigação foi redigida em abril de 2026, com base na experiência de dezoito meses de projeto, construção e otimização de sistemas RAG empresariais entre o final de 2024 e o início de 2026.