A maioria das empresas que me procuram por causa de um projeto de IA travado começa a conversa com os mesmos problemas:
- Já testaram alguns modelos diferentes.
- Reescreveram os prompts uma dúzia de vezes.
- O sistema funciona às vezes, falha outras, e ninguém do time sabe dizer por quê.
Aí elas querem que eu chegue e, de algum jeito, "melhore os prompts". Eu sei fazer isso, mas prompt ruim quase nunca é o problema de verdade.
Quando um sistema de IA funciona de forma inconsistente em produção, o prompt é a coisa mais visível. É a parte que o time controla diretamente. É a parte que muda quando algo dá errado. Então é pra lá que vai a atenção. O time ajusta o prompt, o comportamento muda um pouco, o problema vai pra outro lugar, e o ciclo recomeça. Seis meses depois, estão na versão 47 do prompt e o sistema continua não funcionando.
O prompt raramente é o problema. Na maioria das vezes, o problema mora na arquitetura em volta dele. O prompt só calha de ser o lugar onde o sintoma aparece, ou o jeito mais rápido e fácil de achar um culpado.
É disso que trata a consultoria de arquitetura de IA.
O que "arquitetura" quer dizer num sistema de IA
Numa aplicação web tradicional, arquitetura é a relação entre o banco de dados, o servidor de aplicação, o front-end, as filas, o cache e o monitoramento. São as decisões sobre o que conversa com o quê, como os dados circulam, o que falha quando, e o que você faz a respeito.
Um sistema de IA tem tudo isso e mais um modelo no meio que na maior parte do tempo mente, às vezes se recusa a responder, às vezes devolve saída mal formatada, às vezes custa dez vezes o esperado numa única requisição, e gera resultados diferentes a cada execução.
A arquitetura é o sistema que você constrói em volta desse modelo pra que a pouca confiabilidade dele deixe de importar. Especificamente:
O que o modelo vê. Que contexto, que dados, que instruções, que conhecimento recuperado. O modelo só é tão bom quanto o que você coloca na frente dele. É aqui que a maioria dos projetos de IA travados falha.
O que você faz com o que volta. Validação da saída, imposição de schema, novas tentativas quando a resposta vem mal formatada e plano B quando o modelo está em dúvida. O modelo vai produzir saída errada às vezes. É a arquitetura que decide se essa saída errada chega a um usuário.
Onde o modelo entra no fluxo. Síncrono ou assíncrono. Na frente do usuário ou em segundo plano. Em tempo real ou em cache. Um modelo no caminho crítico de um checkout é um sistema completamente diferente do mesmo modelo resumindo e-mails de madrugada, mesmo com o prompt idêntico.
Como você sabe que está funcionando. Log, conjuntos de avaliação, testes de regressão e alerta quando a qualidade das respostas cai. Sem isso, você não tem sinal. Sem sinal, toda mudança é chute.
O que acontece quando falha. Porque vai falhar. Rate limit, API fora do ar, modelo descontinuado, caso extremo que alucina. A arquitetura é o que decide se a falha fica invisível pro usuário ou vira incidente de segunda-feira de manhã.
O prompt fica em cima de tudo isso. Um bom prompt em cima de uma arquitetura quebrada é um sistema um pouco menos quebrado. Um prompt sem graça em cima de uma arquitetura bem pensada é um sistema que roda em produção e ninguém comenta, que é exatamente o que uma boa infraestrutura deveria fazer.
Alguns padrões que eu vejo em projetos de IA travados
"O modelo dá respostas diferentes pra mesma pergunta." Às vezes é o prompt. Mais vezes, a camada de busca está trazendo contextos diferentes a cada vez, o histórico da conversa está sendo cortado de jeitos diferentes, ou a temperatura está num valor que acrescenta aleatoriedade sem motivo nenhum. A correção está antes do prompt.
"O modelo inventa coisas com toda a confiança." O instinto de quem mexe em prompt é acrescentar "não alucine" ou "use só informações sobre as quais você tem certeza" no prompt de sistema. Não funciona. A alucinação acontece quando o modelo não tem contexto suficiente pra responder certo, e aí preenche o buraco. A correção é dar o contexto certo (busca) ou detectar quando ele saiu da própria competência e fazer ele se recusar a responder (limites de segurança).
"Funciona nos testes e falha em produção." Quase sempre é problema de contexto. As entradas de teste eram limpas e representativas. As de produção têm emoji, idiomas misturados, sarcasmo, JSON mal formado e reclamação de cliente espalhada em seis mensagens. O prompt foi ajustado pros casos fáceis, mas a arquitetura precisa dar conta dos reais.
"Os custos estão explodindo e a gente não sabe por quê." Normalmente é uma de três coisas: o histórico da conversa inteiro vai junto a cada turno, a camada de busca devolve contexto irrelevante demais, ou alguém acrescentou um "seja detalhista" que dobrou o tamanho médio das respostas. Nenhuma delas é problema de prompt.
"O modelo é lento." O modelo raramente é lento. O sistema em volta dele faz chamadas em sequência quando poderia fazer em paralelo, espera a resposta completa quando poderia fazer streaming, ou calcula embeddings a cada requisição quando poderia usar cache. O gargalo é a arquitetura, e não a inferência.
Em todos esses casos, o instinto do time é reescrever o prompt. Às vezes o prompt novo ajuda. O alívio dura pouco. Até o problema voltar.
Como é uma consultoria de arquitetura na prática
Quando me contratam pra isso, a primeira ou a segunda semana normalmente não é de construir nada. É de ler.
Leio o sistema que existe, de ponta a ponta. Vejo o que o modelo recebe numa requisição real, e não o que o time acha que ele recebe. Vejo como a saída é interpretada, validada e usada adiante. Vejo onde os erros são capturados e onde são engolidos. Vejo os logs, quando existem, e pergunto por que não existem, quando não existem. Vejo o custo separado por tipo de requisição. Vejo o conjunto de avaliação, se existir um. Quase sempre não existe.
É a parte que parece lenta pro cliente que me contratou pra consertar alguma coisa. Ele queria uma mudança no código. O que recebe é alguém que conhece o sistema dele melhor que ele, fazendo perguntas que ninguém tinha pensado em fazer. Uma semana depois, normalmente eu tenho uma lista do que precisa mudar, em ordem do que mais ajuda com menos transtorno.
As recomendações quase nunca são sobre o prompt. São sobre fluxo, validação, busca, avaliação, cache e observabilidade. Às vezes o prompt precisa mesmo de trabalho, mas aparece na quarta ou quinta posição da lista, não na primeira.
A segunda fase é implementar as mudanças. Às vezes eu faço. Às vezes o time do cliente faz, com a minha revisão. Às vezes é uma mistura. Mas documentar e deixar claro quem faz o quê, e como, é extremamente importante.
A terceira fase é o handoff: documentação, runbooks, o conjunto de avaliação e/ou um plano de manutenção. Sem isso, o sistema vai se degradar conforme o time mexe sem entender o que tocou, e daqui a seis meses eles me ligam de novo pelos mesmos motivos da primeira vez.
Quando você precisa de consultoria de arquitetura de IA, e quando não precisa
Você não precisa se o sistema funciona, os custos são previsíveis, o time consegue explicar o que está acontecendo quando algo dá errado, e existe um jeito de saber se uma mudança melhora ou piora as coisas. Isso é um sistema saudável. Continue fazendo o que está fazendo.
Você precisa quando o sistema quase funciona e ninguém do time sabe dizer por quê. Quando o prompt já foi reescrito uma dúzia de vezes. Quando o time tem medo de mexer em qualquer coisa porque não sabe o que vai quebrar. Quando a demo foi ótima e a produção está dois meses atrasada em relação à data em que vocês esperavam lançar.
O que ninguém te conta sobre arquitetura de IA
A maior parte do trabalho não é trabalho de IA.
É o mesmo trabalho que você faria em qualquer sistema de produção, pra qualquer aplicação ou site. Log. Validação. Cache. Tratamento de erro. Nova tentativa com espera crescente. Imposição de schema. Monitoramento. Observabilidade. A disciplina de construir software que aguenta o contato com usuários.
A parte de IA (o modelo, os prompts, a busca) é talvez 20% do sistema em linhas de código. Os outros 80% são a infraestrutura que torna esses 20% confiáveis. Se o seu time é ótimo nos 80% e está aprendendo os 20%, provavelmente você não precisa de mim. Se o seu time vem tratando os 20% como se fossem o sistema inteiro, é isso que um projeto de arquitetura de IA resolve.
Escrevi sobre isso por outro ângulo no post sobre agentes de IA com permissão demais, e por mais outro no post sobre agências WordPress. Nos dois dá pra ver o mesmo padrão: o time focou na parte de IA e construiu pouco o sistema em volta. A correção é sempre de arquitetura.
O que fazer antes de contratar alguém
Antes de chamar um consultor, escreva o que você sabe e o que não sabe.
- O que o sistema faz, de ponta a ponta?
- Que entradas chegam?
- O que o modelo vê numa requisição típica?
- O que sai?
- O que vocês fazem com a saída?
- Onde as falhas acontecem?
- O que vocês já tentaram?
- O que não funcionou, e por quê?
A maioria dos times não consegue responder essas perguntas por escrito. Às vezes, só tentar responder já basta pra o problema aparecer, sem contratar ninguém. Se você escreveu tudo e as lacunas ficaram óbvias, feche as lacunas você mesmo. Se escreveu tudo e o sistema continua sem fazer sentido, aí é hora de ligar pra alguém.
Se o seu sistema de IA chegou ao ponto em que o prompt foi reescrito mais vezes do que alguém quer admitir e o time começa a se perguntar se tudo foi um erro, isso é uma auditoria de arquitetura de IA. Diagnóstico pago, escopo por escrito, handoff de verdade. O resultado é um sistema que deixa de ser interessante, que é o objetivo. Comece por aqui.
O que o seu diagrama de arquitetura atual deixa de fora?