Os Prompts do Seu Time Não São o Problema
A maioria das empresas que me procuram sobre um projeto de IA travado começam a conversa com os mesmos problemas:
- Eles já tentaram alguns modelos diferentes.
- Reescreveram os prompts uma dúzia de vezes.
- O sistema funciona às vezes, falha outras vezes, e ninguém do time consegue dizer por quê.
Então, eles querem que eu venha e de alguma forma "melhore os prompts". É algo que consigo fazer, mas um prompt ruim quase nunca é o problema real.
Quando um sistema de IA funciona inconsistentemente em produção, o prompt é a coisa mais visível. É a parte que o time tem controle direto. É a parte que muda quando as coisas dão errado. Então é para lá que a atenção vai. O time ajusta o prompt, o comportamento muda um pouco, o problema se move para outro lugar, e o ciclo começa de novo. Seis meses depois, eles estão na versão 47 do prompt, e o sistema ainda não funciona.
O prompt raramente é o problema. Na maioria das vezes, o problema reside na arquitetura ao redor do prompt. O prompt apenas coincidentalmente acontece de ser onde o sintoma aparece, ou é o jeito mais fácil e rápido de encontrar algo para culpar.
É isso que consultoria de arquitetura de IA realmente é.
O que "arquitetura" significa em um sistema de IA
Em uma aplicação web tradicional, arquitetura é a relação entre seu banco de dados, seu servidor de aplicação, seu front-end, suas filas, seu cache e seu monitoramento. As decisões sobre o que fala com o quê, como os dados fluem, o que falha quando, e o que você faz sobre isso.
Um sistema de IA tem tudo isso mais um modelo no meio que a maioria das vezes mente, às vezes se recusa a responder, às vezes retorna saída malformada, às vezes custa dez vezes o que você esperava em uma única requisição, e produz resultados não-determinísticos entre execuções.
A arquitetura é o sistema que você constrói ao redor daquele modelo, para que a confiabilidade baixa deixe de importar. Especificamente:
O que o modelo vê. Que contexto, que dados, que instruções, que conhecimento recuperado. O modelo só pode ser tão bom quanto o que você coloca na frente dele. A maioria dos projetos de IA travados falham aqui.
O que você faz com o que volta. Validação de saída, imposição de schema, retentativas em respostas malformadas, e fallbacks quando o modelo é incerto. O modelo produzirá saída errada às vezes. A arquitetura decide se aquela saída errada alguma vez alcança um usuário.
Onde o modelo se encaixa no fluxo. Síncrono vs. assíncrono. Voltado para o usuário vs. background. Tempo real vs. em cache. Um modelo no caminho crítico de um fluxo de checkout é um sistema completamente diferente do mesmo modelo resumindo emails durante a noite, mesmo que o prompt seja idêntico.
Como você sabe que está funcionando. Logging, conjuntos de avaliação, testes de regressão, e alertas quando a qualidade da resposta cai. Sem isso, você não tem sinal. Sem um sinal, toda mudança é um palpite.
O que acontece quando falha. Porque vai falhar. Rate limits, interrupções de API, descontinuação de modelos, casos extremos que alucinam. A arquitetura é o que decide se uma falha é invisível para o usuário ou um incidente de segunda-feira de manhã.
O prompt fica no topo de tudo isso. Um bom prompt em cima de uma arquitetura quebrada é um sistema um pouco menos quebrado. Um prompt monótono em cima de uma arquitetura bem pensada é um sistema que roda em produção, e ninguém fala sobre, que é o que uma boa infraestrutura deveria fazer.
Alguns padrões que vejo em projetos de IA travados
"O modelo dá respostas diferentes para a mesma pergunta." Às vezes isso é o prompt. Mais frequentemente, é que a camada de recuperação está puxando contextos diferentes cada vez, o histórico de conversa está sendo truncado diferentemente, ou a temperatura está configurada para algo que introduz aleatoriedade sem nenhuma boa razão. O conserto está upstream do prompt.
"O modelo confidentemente inventa coisas." O instinto de engenharia de prompt é adicionar "não alucine" ou "use apenas informações sobre as quais você tem certeza" ao system prompt. Isso não funciona. Alucinação acontece quando o modelo não tem contexto suficiente para responder corretamente, então preenche a lacuna. O conserto é dar a ele o contexto certo (recuperação) ou detectar quando está fora de sua competência e se recusar a responder (guardrails).
"Funciona nos testes e falha em produção." Quase sempre um problema de contexto. Os inputs de teste eram limpos e representativos. Os inputs de produção incluem emoji, idiomas mistos, sarcasmo, JSON malformado, e reclamações de clientes que abrangem seis mensagens. O prompt foi ajustado contra os casos fáceis, mas a arquitetura precisa lidar com os reais.
"Os custos estão explodindo, e não sabemos por quê." Geralmente uma de três coisas: o histórico de conversa está sendo enviado completo a cada turno, a camada de recuperação está retornando muito contexto irrelevante, ou alguém adicionou uma instrução "seja minucioso" que dobrou o comprimento médio da resposta. Nenhuma dessas são problemas de prompt.
"O modelo é lento." O modelo raramente é lento. O sistema ao redor dele está fazendo chamadas sequenciais quando poderia paralelizar, esperando respostas completas quando poderia fazer streaming, ou rodando embeddings em cada requisição quando poderia fazer cache. A arquitetura é o gargalo, não a inferência.
Em cada um desses casos, o instinto do time é reescrever o prompt. Às vezes o novo prompt ajuda. O alívio é temporário. Até que o problema reapareça.
O que consultoria de arquitetura realmente parece
Quando sou contratado para isso, a primeira ou segunda semana geralmente não é construir nada. É ler.
Leio o sistema existente de ponta a ponta. Vejo o que o modelo recebe em uma requisição real, não o que o time acha que recebe. Vejo como a saída é analisada, validada e usada downstream. 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 breakdown de custo por tipo de requisição. Vejo o conjunto de avaliação, se existe um. Quase sempre acho que não existe.
Essa é a parte que parece lenta para clientes que me contrataram para consertar algo. Eles queriam uma mudança de código. O que estão recebendo é alguém que conhece seu sistema melhor do que eles, fazendo perguntas que não pensaram em fazer. Uma semana depois, geralmente tenho uma lista de coisas que precisam mudar, ordenadas pelo que ajudará mais com o mínimo de disrupção.
As recomendações quase nunca são sobre o prompt. São sobre fluxo, validação, recuperação, avaliação, cache e observabilidade. Às vezes o prompt realmente precisa de trabalho, mas aparece na posição quatro ou cinco da lista, não na primeira.
A segunda fase é implementar as mudanças. Às vezes faço isso. Às vezes o time do cliente faz com minha revisão. Às vezes é uma mistura. Mas documentar e deixar claro quem está fazendo o quê e como está sendo feito é 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 degradará conforme o time faz mudanças sem entender o que tocou, e eles estarão me ligando de novo em seis meses pelos mesmos motivos que ligaram a primeira vez.
Quando você precisa de consultoria de arquitetura de IA e quando não precisa
Você não precisa se seu sistema funciona, seus custos são previsíveis, seu time consegue explicar o que está acontecendo quando algo dá errado, e você tem um jeito de saber se uma mudança faz as coisas ficarem melhor ou pior. Esse é um sistema saudável. Continue fazendo o que está fazendo.
Você precisa quando o sistema quase-funciona, e ninguém no time consegue dizer por quê. Quando o prompt foi reescrito uma dúzia de vezes. Quando o time tem medo de tocar em qualquer coisa porque não sabe o que vai quebrar. Quando a demo foi ótima, e a produção está dois meses após a data em que você esperava fazer o ship.
A coisa que ninguém te conta sobre arquitetura de IA
A maioria do trabalho não é trabalho de IA.
É o mesmo trabalho que você faria em qualquer sistema de produção para uma única aplicação ou website. Logging. Validação. Cache. Tratamento de erros. Retentativas com backoff. Imposição de schema. Monitoramento. Observabilidade. A disciplina de construir software que sobrevive ao contato com usuários.
A parte de IA (o modelo, os prompts, a recuperação) é talvez 20% do sistema por contagem de linhas. Os outros 80% são a infraestrutura que torna os 20% confiáveis. Se seu time é ótimo nos 80% e aprendendo os 20%, provavelmente você não precisa de mim. Se seu time vem tratando os 20% como o sistema inteiro, é isso que um engajamento de arquitetura de IA realmente conserta.
Escrevi sobre isso de um ângulo diferente em o post sobre agentes de IA com permissões demais, e de ainda outro em o post de agências WordPress. Em cada post, o mesmo padrão pode ser visto: o time focou na parte de IA e subconstruiu o sistema ao redor. O conserto é sempre arquitetural.
O que você deveria fazer antes de contratar alguém
Antes de trazer um consultor, escreva o que você sabe e o que não sabe.
- O que o sistema realmente faz, de ponta a ponta?
- Que inputs entram?
- O que o modelo vê em uma requisição típica?
- O que sai?
- O que você faz com a saída?
- Onde acontecem as falhas?
- O que vocês tentaram?
- O que não funcionou e por quê?
A maioria dos times não consegue responder essas perguntas por escrito. O ato de tentar respondê-las às vezes é suficiente para superficiar o problema sem contratar alguém. Se você escrever tudo e as lacunas forem óbvias, conserte as lacunas você mesmo. Se você escrever tudo e o sistema ainda não fizer sentido, é quando você liga para alguém.
Se seu sistema de IA está no ponto em que o prompt foi reescrito mais vezes do que qualquer um quer admitir e o time está começando a se perguntar se a coisa toda foi um erro, esse é o trabalho de arquitetura que faço. Descoberta paga, escopo escrito, handoff real. A saída é um sistema que deixa de ser interessante, que é o objetivo.
O que seu diagrama de arquitetura atual deixa de fora?