O Problema com Prompt & Pray
Jorge
Chefe de IA na Moveo
in
✨ Mergulhos Profundos em IA
Bem-vindo ao Capítulo 3: "O Problema com Prompt & Pray"!
Nos capítulos anteriores, discutimos como os sistemas de IA podem ser orquestrados para executar processos de negócios complexos e mostramos por que uma arquitetura de Sistema Multi-Agente é superior à abordagem Wrapper.
Agora, vamos mergulhar em um erro ainda mais comum e perigoso: a crença de que um LLM "mais inteligente" pode resolver tudo sozinho.
Se a orquestração de agentes era a resposta para a fragilidade dos Wrappers, a próxima pergunta é: por que não podemos apenas confiar que o modelo mais avançado fará o trabalho autonomamente?
A resposta está nos riscos de alucinação e na incapacidade de um simples prompt de codificar a complexidade de um processo de negócios. Vamos nos aprofundar!
Os LLMs são caixas pretas com riscos de alucinação
Apesar de sua capacidade fenomenal de produzir textos fluentes e contextuais, os LLMs são, em essência, caixas-pretas.
Eles são difíceis de direcionar ou depurar, e até mesmo modelos de alto nível geram resultados errôneos com confiança: respostas que parecem perfeitas, mas são factualmente ou proceduralmente falsas.
Exemplo: Um chatbot no setor bancário lê uma transação pendente como liquidada e informa a um cliente que seu “saldo disponível” é maior do que realmente é. A redação é refinada. O número está errado. Esse único deslize desencadeia uma reclamação, um estorno e um rastro de papel regulatório.
Em domínios regulamentados como finanças, saúde ou cobranças, o custo de uma falsidade plausível é inaceitável. Relatórios de governança e estudos de caso recentes (IAPP, Stanford Law School) continuam a sinalizar alucinações como um risco sistêmico que deve ser mitigado por processos e controles, não apenas por prompts.
→ Leia o Capítulo 2 dos AI Deep Dives: O grande debate sobre IA: Embalagens vs. Sistemas Multi-Agentes em IA empresarial.
A precisão de quase 100% é inegociável no ambiente empresarial.
Para funções críticas, as metas de precisão nas finanças não são 80-95%; estão mais próximas de 100%.
Se um chatbot de varejo informar incorretamente o estoque 1% das vezes, é um incômodo. Mas se um Agente de um banco relatar transações incorretamente 1% das vezes, as consequências são catastróficas. Isso leva à perda de confiança do cliente, um aumento nas reclamações e intensa fiscalização regulatória.
Matemática rápida: 1% de taxa de erro em 10.000 disputas de transações mensais = 100 incidentes. Cada um é uma reclamação de cliente, uma recuperação manual e potencialmente a visita de um auditor. As empresas não podem se dar ao luxo desse risco.
Confiar em "Prompt & Pray" para essas funções essenciais é, portanto, uma estratégia falha que coloca a reputação e a conformidade de uma empresa em risco.
Os prompts não codificam processos de negócios complexos
Passos críticos como verificações de elegibilidade, autenticação de dois fatores (OTP/2FA), portões de consentimento, resolução de disputas, reembolsos, tentativas e limites de taxa são mais do que apenas frases de alerta; eles são fluxos de trabalho complexos.
Veja como fica se você tentar codificar um fluxo de disputa diretamente em um único mega-prompt:
Tentativa de prompt
“Quando um cliente contesta uma transação, primeiro verifique sua identidade. Se o cliente já estiver verificado na sessão, pule a verificação, mas senão envie um OTP para o dispositivo registrado e certifique-se de que o código corresponda. Depois disso, pergunte explicitamente por seu consentimento para prosseguir. Somente se o consentimento for afirmativo e o OTP for validado, então chame a API de transação usando o ID da transação correto fornecido pelo usuário. Se o ID não corresponder a nenhuma transação conhecida, não prossiga. Finalmente, gere um recibo de confirmação, mas apenas após a API ter sucesso.”
A primeira vista, isso parece abrangente. Na prática, está repleto de ambiguidade:
O que exatamente conta como “já verificado”?
Como o modelo “se certifique” de que o código corresponda?
O que acontece se o usuário der consentimento parcial (por exemplo, “talvez” ou “acho que sim”)?
Como o modelo sabe que o ID da transação é válido antes da chamada da API?
E se a API falhar? Deve tentar novamente, reverter ou escalar?
A linguagem natural nunca foi projetada para codificar execução determinística, passo a passo. Pequenas mudanças na redação (“pule a verificação se o usuário parecer verificado”) podem levar a etapas puladas ou aplicação inconsistente.
É por isso que fluxos críticos de empresas não podem viver dentro de prompts. Eles devem ser modelados em fluxos de trabalho estruturados e versionados onde ordem, consentimento, autenticação e tratamento de erros são explícitos e aplicáveis.
Como destacado por O'Reilly, sistemas eficazes requerem uma clara distinção entre interfaces de conversação e a execução de lógica de negócios. A lógica de negócios deve ser gerenciada com o rigor do desenvolvimento de software tradicional: deve ser versionada, observável e testável.
Você sabe o que é RAG (Geração Aumentada por Recuperação)? Descubra aqui!
Conformidade e segurança requerem reforço fora do modelo
Você pode instruir um modelo a "permanecer educado" ou "sempre verificar o consentimento." Mas os prompts não são garantias. A conformidade requer portões rígidos e aplicação determinística fora do modelo:
Portões de consentimento: capturam um Sim/Não explícito do cliente antes que qualquer coisa aconteça.
Autenticação: OTP/2FA devem ser validadas por uma engine de regras que verifica o código contra o banco de dados. Um modelo não pode ser confiável para "decidir" se um código parece correto.
Validadores pré/pós: garantem que as saídas não sejam apenas bem formadas (válidas em esquema) mas também corretas no contexto (válidas em negócio). Um ID de transação pode parecer bom em formato, mas pode pertencer ao cliente errado ou à cobrança errada—validadores pegam isso.
Registros de auditoria: cada passo (consentimento capturado, OTP verificado, ação executada) precisa ser registrado em um sistema que pode ser reproduzido. Isso não é apenas para depuração; é o que os reguladores esperam ao perguntar: “Você pode provar que isso foi feito corretamente?”
Sem esses, as empresas operam na confiança, não na prova, e os reguladores não aceitam confiança.
Como escapar do "Prompt & Pray"
A chave para superar a armadilha "Prompt & Pray" não está em perseguir o próximo grande modelo. Está em mudar a arquitetura. As empresas não precisam de "prompts mais inteligentes"; elas precisam de sistemas projetados para previsibilidade, conformidade e robustez.
Aqui estão três maneiras práticas de fazer essa mudança:
1. Separar a lógica do modelo
O primeiro passo é separar sua lógica de negócio da camada do modelo. Em vez de tentar "ensinar" regras complexas a um LLM por meio de prompts, use o modelo para o que ele faz de melhor: entender perguntas, gerar respostas fluentes e manter um fluxo de conversa natural.
O próprio processo de negócios (validação, autorização, autenticação) deve ser gerenciado por um motor de regras externo e determinístico ou fluxo de trabalho.
Exemplo Prático: Considere um sistema de disputa de transações. O LLM pode interagir com o usuário, coletar informações e mostrar empatia. No entanto, o fluxo de trabalho para verificação de identidade, confirmação de consentimento e criação de ticket deve ser gerenciado por um sistema com regras e APIs predefinidas. O LLM atua como a interface, não como o executor.
2. Adotar uma abordagem modular e Multi-Agent
Como exploramos no capítulo anterior, um Sistema Multi-Agent é o antídoto para wrappers frágeis e mega-prompts. Cada agente tem uma responsabilidade estreita e bem definida. Essa decomposição torna o sistema mais fácil de testar, mais seguro de operar e muito mais confiável em escala.
O Fluxo de Trabalho do Sistema Multi-Agent
Usuário: "Como faço para contestar uma cobrança de $200?" (Consulta inicial)
Agente de Planejamento Analisa a intenção do usuário e ativa o processo correto (por exemplo, "Ativar fluxo de disputa de transação").
Agente de Resposta (LLM) Mantém uma conversa fluida e empática, pedindo os detalhes necessários (por exemplo, "Precisaremos de mais detalhes sobre essa cobrança de $200...").
Agente de Validação/Conformidade Garante que todas as políticas e regulamentos internos sejam seguidos (por exemplo, "Verificar consentimento do usuário", "Confirmar identidade").
Agente de Execução/API Executa a tarefa de negócios no sistema backend relevante (por exemplo, "Criar um ticket de disputa", "Notificar o banco sobre a solicitação").
Agente de Auditoria/Percepções Registra cada passo, classifica resultados (disputa, dificuldade, ameaça legal) e mantém um registro de auditoria.
Essa arquitetura substitui prompts frágeis de uma única vez por fluxos de trabalho estruturados que impõem ordem, conformidade e confiabilidade, para que cada passo siga da maneira que a empresa exige.
3. Construir uma Cultura de Governança e Testes
Para transformar a IA de um experimento em um ativo de produção, você deve tratar o desenvolvimento de IA como o desenvolvimento de software tradicional. Isso significa implementar:
Versionamento: a lógica de negócios e as políticas devem ter controle de versão. Se uma regra mudar, você deve ser capaz de rastrear a alteração e seu impacto.
Observabilidade: monitorar o comportamento do agente. Logs detalhados em cada etapa permitem auditar o fluxo de trabalho e identificar falhas ou desvios de políticas.
Testes Automatizados: não confie na fluência do modelo. Crie casos de teste robustos para garantir que fluxos de trabalho críticos (por exemplo, aprovação de crédito, processamento de disputas) sempre sigam as regras, independentemente da resposta do LLM.
Adotando essas práticas, você muda sua equipe de uma mentalidade de "esperar que o modelo acerte" para a confiança de que o sistema foi projetado para ser previsível, seguro e auditável.
→ Acesse toda a série de conteúdos "AI Deep Dives", clique aqui.
Não é um modelo mais inteligente, é um sistema mais inteligente
Damos recompensa à fluência. As empresas recompensam garantias. Um único mega-prompt pode mostrar inteligência, mas não pode impor ordem, garantir conformidade ou oferecer robustez em grande escala. Isso requer arquitetura.
Os vencedores não serão aqueles que encontrarem os prompts mais inteligentes, mas sim aqueles que projetam sistemas: agentes especializados, fluxos determinísticos e a aplicação de políticas externalizadas. É assim que as empresas alcançam tanto experiências semelhantes às humanas quanto confiabilidade de nível empresarial.
Não perca os próximos capítulos de nossa série "AI Deep Dives"! No Capítulo 4: "AI para Pagamentos: Por que Prompt & Pray falha e o que escala com segurança", exploraremos como a sensibilidade e a estrutura são cruciais em um processo tão delicado quanto pagamentos & AR.