Prompts de IA: Quão Bons e Quão Ruins Eles São — Abrindo uma Nova Linha de Pesquisa

Existe uma frase silenciosa que se repete em toda reunião, toda demonstração, toda revisão de arquitetura: "o modelo pode cometer erros." A indústria diz isso como um aviso, como uma previsão do tempo, e ficou tão confortável com ela que a frase agora funciona como infraestrutura estrutural para todo o resto — uma licença que permite a engenheiros entregar, integrar e confiar em sistemas que, no mesmo fôlego, também se recusam a confiar plenamente.

Este post é o início público de uma linha de pesquisa que quero conduzir nos próximos meses. Não é um tutorial, não é um benchmark e não é uma opinião quente. É uma declaração de tese. A pergunta com a qual quero conviver é simples de enunciar e difícil de responder:

O que seria necessário para o campo parar de supor que a IA cometerá erros — e começar a projetar para a precisão?

Antes de explicar para onde quero ir, quero fazer um levantamento honesto de onde o campo está. Os prompts hoje são extraordinários. Os prompts hoje também são pouco confiáveis de maneiras que a indústria ainda não mede bem. Ambas as coisas são verdadeiras, e a lacuna entre elas é o território que quero explorar.

O bom: o que os prompts realmente entregam hoje

É fácil esquecer o quanto se está pedindo a um único prompt. Um bloco de linguagem natural é, simultaneamente, um contrato de API, uma especificação de tarefa, uma janela de contexto, uma definição de persona, um limite de segurança e um protocolo de coordenação para ferramentas. Que isso funcione é um dos resultados mais surpreendentes da história recente do software.

Aqui está o que eu acho que os prompts genuinamente entregam hoje, e onde me recuso a ser cínico em relação a eles:

Estreitamento de contexto. Um prompt é o mecanismo mais barato já inventado para pegar um sistema treinado em toda a internet e direcioná-lo para este cliente, este ticket, esta fatura. A geração aumentada por recuperação (RAG), quando bem feita, reduz as taxas de alucinação em 75–90% em comparação com a geração de livro fechado. Isso não é um ajuste — é uma primitiva arquitetural. O campo descobriu que é possível corrigir uma enorme classe de modos de falha não treinando o modelo novamente, mas melhorando o que se coloca na frente dele.

Conclusão de tarefas por composição. A mudança de "fazer prompt para o modelo" para "programar o modelo" já está em andamento. Frameworks como o DSPy explicitamente reformulam os prompts como módulos tipados com assinaturas de entrada/saída, otimizáveis de ponta a ponta e componíveis em pipelines. O grupo de Stanford tem pressionado fortemente nesse sentido: parem de mexer em strings, comecem a declarar contratos. Acho que é para onde o campo está realmente indo, e os primeiros resultados — pipelines neuro-simbólicos combinando LLMs com solucionadores formais — relatam ganhos de precisão de até 43% em relação à cadeia de pensamento (chain-of-thought) simples.

Saída estruturada, sob demanda. A decodificação restrita (XGrammar, llguidance, Outlines) significa que, quando eu peço JSON, agora posso garantir JSON — não "geralmente JSON, exceto às terças-feiras." O XGrammar roda em menos de 40 microssegundos por token e, em março de 2026, é o backend padrão de geração estruturada para vLLM, SGLang e TensorRT-LLM; o XGrammar-2 saiu em maio de 2026 com foco em estruturas dinâmicas para fluxos agênticos. O llguidance é a base que a OpenAI creditou publicamente para seu recurso de Saídas Estruturadas. Esta é uma vitória de precisão que vale celebrar: no nível sintático, o problema está essencialmente resolvido.

Uso de ferramentas e fluxos agênticos. Function calling, servidores MCP, frameworks de agentes — o modelo agora pode acessar sistemas determinísticos para as coisas sobre as quais não deveria estar adivinhando. O ancoramento em ferramentas (tool grounding) reduz as alucinações em 65–80%. Isso é enorme. Toda vez que um cálculo, uma busca de data, uma consulta a banco de dados ou uma leitura de arquivo é delegado a uma ferramenta de verdade, a arquitetura está removendo uma categoria de erro em vez de tolerá-la.

Aprendizado em contexto como primitiva. Alguns exemplos bem escolhidos podem remodelar o comportamento de maneiras que antes exigiam fine-tuning. Para trabalho exploratório, para tarefas pontuais, para requisitos em evolução, isso é um tipo de programação genuinamente novo.

Se você veio da era do código imperativo, a experiência de escrever um prompt que generaliza é estranha. Você descreve o quê, não o como, e o sistema preenche o resto. Esse é um poder real, e não quero falar sobre os modos de falha sem antes reconhecer isso.

O ruim: onde os prompts quebram silenciosamente

E ainda assim. A mesma propriedade que faz com que os prompts pareçam mágicos — linguagem natural como interface — é a mesma propriedade que os torna frágeis. Aqui está onde vejo os prompts quebrando hoje, ordenados aproximadamente de "bem conhecido" a "raramente discutido":

Fragilidade ao fraseamento. Esta é a grande questão, e é muito pior do que a área reconhece publicamente. As linhas de trabalho Brittlebench e Multi-Prompt Evaluation mostram que perturbações que preservam a semântica — reescrever, reordenar, reformatar — podem mudar o desempenho em até 12%, e uma única perturbação inverte o ranking relativo dos modelos em 63% dos casos de benchmark. Leia de novo: a resposta para "qual modelo é melhor para esta tarefa?" depende, na maioria das vezes, de como a pergunta por acaso foi fraseada. A cultura de benchmark mascara isso ao relatar um único número por modelo por tarefa, mas a distribuição subjacente é ampla e bimodal.

Alucinação, mesmo em 2026. Os números das manchetes parecem bons — as taxas de alucinação de modelos de fronteira são 3–8× menores que as bases de 2024. Algumas comparações publicadas colocam o Claude em dígitos únicos baixos e outros modelos de fronteira na faixa de 8–12% em tarefas de sumarização factual; em benchmarks de conhecimento mais difíceis, como o AA-Omniscience, a dispersão é bem maior. Isso é progresso real. Mas os mesmos dados mostram que mitigações apenas via prompt chegam a um teto em torno de –15%. Os grandes ganhos (RAG, ancoramento em ferramentas) são arquiteturais, não vitórias da engenharia de prompts. A indústria tem super-recompensado coletivamente "truques de prompt" em relação ao que os dados mostram sobre de onde vem a confiabilidade de fato.

Não-determinismo como recurso, não como bug. Mesmo com temperatura zero, o mesmo prompt contra o mesmo modelo no mesmo dia pode produzir saídas diferentes entre execuções, porque batching, hardware e otimizações em tempo de inferência introduzem pequenas diferenças numéricas que se acumulam ao longo da amostragem. Avaliar a confiabilidade requer executar a mesma tarefa em centenas de tentativas e medir a variância — mas a maioria dos sistemas em produção trata uma boa resposta como evidência de que o prompt "funciona."

Erros acumulativos em sistemas multietapas. Um passo 95% confiável é aceitável. Vinte deles em sequência dá 36%. Fluxos agênticos multiplicam erros por passo, e o campo ainda não tem frameworks de avaliação amplamente aceitos que meçam a trajetória, não apenas a saída final. O problema da medição está à frente das ferramentas — e as ferramentas são o que as pessoas realmente usam para decidir se entregam ou não.

Colisões de instruções. À medida que os prompts crescem — system prompts, developer prompts, descrições de ferramentas, contexto recuperado, mensagens do usuário — as instruções começam a se contradizer. O modelo resolve essas colisões de maneiras que ninguém consegue prever totalmente. Pior, a resolução depende de ordem, recência e fraseamento de maneiras que mudam a cada versão do modelo. O campo não tem um bom vocabulário para isso. Não existe um git diff para o comportamento de prompts.

Falha de verificação sob composição. Um estudo recente sobre integração de LLMs com métodos formais constatou que, embora a correção de função única alcance mais de 99% de precisão sintática, tarefas composicionais degradam para 95,67% de correção sintática e uma catastrófica taxa de verificação completa de 3,69%, com o melhor modelo chegando a apenas 7% em Pass@8. Funções únicas são tratáveis. Compô-las com garantias não é.

O padrão cultural do "melhor esforço". Este é o mais profundo. A indústria concordou coletivamente, sem nunca debater, que "melhor esforço" é o contrato certo entre humanos e modelos de linguagem. O modelo tentou, geralmente acertou, e o humano é responsável por capturar os casos em que ele não acertou. Esse é um padrão de transição razoável. É um péssimo estado terminal.

A suposição que ninguém questiona mais

Aqui está a mesa que quero virar.

Quando um banco de dados retorna a linha errada, engenheiros não dão de ombros e dizem "bem, bancos de dados às vezes cometem erros." Eles abrem um bug. Abrem um incidente. Esperam um postmortem. O sistema é mantido em um contrato de precisão, e as violações desse contrato são tratadas como defeitos.

Quando um modelo de linguagem retorna a linha errada, a resposta é "o modelo pode alucinar, por favor verifique." Foi construída uma profissão inteira — "engenheiro de IA", "engenheiro de prompt", "engenheiro de avaliação" — em torno da suposição de que o sistema é fundamentalmente não-determinístico e, portanto, fundamentalmente falível. A verificação é descarregada no humano ou em uma checagem a jusante. O sistema é mantido em um contrato de melhor esforço.

Não estou argumentando que essa suposição esteja errada hoje. Ela é empiricamente correta — os sistemas que existem de fato cometem erros, frequentemente, de maneiras que ninguém consegue prever totalmente. Estou argumentando que ela parou de ser interrogada. O campo internalizou isso como uma propriedade permanente da "IA" em vez de uma propriedade contingente dos "LLMs que por acaso estão disponíveis em 2026."

Algumas coisas mudaram recentemente que me fazem pensar que essa suposição agora está sustentando peso de uma forma que não deveria:

1. A decodificação restrita funciona. No nível sintático, há prova de que o campo pode sair de "geralmente correto" para "provavelmente correto." Não há razão teórica para que a mesma mudança não possa acontecer em níveis semânticos superiores — só requer o andaime certo.
2. O ancoramento em ferramentas funciona. Empurrar as respostas para fora do modelo e para sistemas determinísticos dá uma fatoração limpa: o modelo propõe, a ferramenta decide. A maioria das "alucinações" em sistemas agênticos bem projetados agora são falhas de planejamento, não factuais.
3. A prompting programática funciona. O DSPy e seus descendentes mostram que, quando prompts são tratados como artefatos compiláveis com assinaturas tipadas, eles podem realmente ser otimizados e verificados — em vez de afinados por intuição.
4. A economia está se alinhando. Todo cliente com quem converso tem a mesma reclamação: "Posso construir um demo em uma hora, mas não consigo entregar em produção porque não consigo garantir nada." Agora há uma pressão econômica real para fechar a lacuna de precisão.

As condições para uma mudança de fase estão presentes. O vocabulário para a mudança de fase não está.

O que "precisão" poderia significar para modelos de linguagem

Quero ter cuidado aqui. "Precisão" está fazendo muito trabalho neste post, e eu lhe devo uma definição.

Quando digo que quero sair do melhor esforço para a precisão, não me refiro a determinismo no sentido estrito. Não quero dizer que todo prompt deve produzir exatamente uma sequência de tokens. Algumas tarefas são inerentemente abertas; criatividade, sumarização, ideação — essas se beneficiam da variância e seriam empobrecidas se ela fosse removida.

O que quero dizer é algo mais parecido com: o comportamento de um prompt deve ser especificável, mensurável e delimitado. Concretamente, gostaria de poder dizer coisas como:

• "Para entradas que correspondem a este esquema, este prompt produz uma saída que satisfaz este contrato com probabilidade ≥ 0,999."
• "Em 100 reformulações que preservam a semântica deste prompt, a variância de saída nestas métricas é ≤ ε."
• "Este prompt, esta versão do modelo, esta temperatura, este conjunto de ferramentas — se qualquer um deles mudar, o comportamento é reverificado."

Isso não é ficção científica. Isso é o que a engenharia já faz para componentes de software. Software tem sistemas de tipos, testes baseados em propriedades, testes de contrato, versionamento, CI. Prompts não têm nada disso de maneira séria e padronizada.

Hoje, o análogo mais próximo é: escreva o prompt, execute-o em alguns exemplos, observe as saídas, entregue. Isso não é engenharia. Isso é trabalho artesanal e, embora haja habilidade real nisso, não escala para os sistemas que estão sendo construídos hoje.

Como a precisão poderia se parecer, concretamente, no médio prazo:

Contratos de prompt como artefatos de primeira classe. Um prompt tem entradas tipadas, saídas tipadas, pré-condições, pós-condições e asserções. A ferramenta os impõe em tempo de compilação e em tempo de execução. O DSPy é o movimento mais sério nesse sentido. O Mellea e projetos similares estão buscando a mesma coisa.

Diffs comportamentais. Uma mudança em um prompt deve produzir um diff não apenas no nível da string, mas no nível do comportamento — "esta reformulação muda as saídas em 3% das entradas históricas, e aqui estão os deltas." Essa é a primitiva ausente que permitiria que prompts fossem tratados como software.

Verificação em nível de span. O trabalho REFIND SemEval 2025 aponta para a forma correta: cada afirmação que um modelo faz é comparada com evidências recuperadas, e afirmações sem suporte são sinalizadas. Isso deveria se tornar a UX padrão para qualquer sistema que produza saídas factuais.

Supervisão de processo, não apenas supervisão de resultado. Para fluxos agênticos, a unidade certa de avaliação é a trajetória — a ferramenta certa foi selecionada, o plano foi coerente, o raciocínio se sustentou — não apenas a resposta final. O problema da medição aqui está aberto; é um dos problemas abertos mais importantes na IA aplicada hoje.

Modelos delimitados por domínio. Um modelo geral com uma taxa de alucinação de 10% em consultas factuais não pode ser a base de um sistema clínico, de um sistema jurídico ou de um sistema financeiro. A arquitetura correta provavelmente é um modelo restritamente escopado e rigorosamente avaliado, cujo domínio seja pequeno o suficiente para caracterizar seus modos de falha — composto em um sistema maior por meio de interfaces explícitas.

Nada disso é uma única descoberta. Tudo isso é o acúmulo lento de prática de engenharia que os bancos de dados ganharam na década de 1970, as redes ganharam na década de 1980 e a web ganhou nos anos 2000. O campo está na fase dos anos 1970 da engenharia de modelos de linguagem. Ainda não há um equivalente ao ACID.

As perguntas de pesquisa que quero conduzir

Este post é o início de uma linha de pesquisa. Aqui estão as perguntas específicas que quero investigar no próximo trecho de tempo, aproximadamente na ordem em que planejo encará-las:

1. Quão frágeis, na prática, são os prompts que realmente são entregues?

A maioria das pesquisas publicadas sobre fragilidade usa benchmarks acadêmicos. Quero pegar os tipos de prompts que aparecem em sistemas reais de produção — agentes, pipelines RAG, fluxos de classificação — e medir como eles mudam sob perturbações realistas. A hipótese que quero testar: a maioria dos prompts de produção é muito mais frágil do que seus autores acreditam, e a fragilidade está concentrada em lugares previsíveis.

2. Qual é a unidade certa de versionamento para o comportamento do prompt?

Hoje o campo versiona strings de prompt. Essa é a unidade errada. A unidade certa está mais próxima de "o comportamento deste prompt em uma distribuição de entrada representativa." Pode-se construir uma ferramenta que permita a um desenvolvedor fazer commit de um prompt e automaticamente obter uma impressão digital comportamental — e um diff contra a impressão digital anterior? Como essa ferramenta seria na prática?

3. Onde está a fronteira entre "especificar em linguagem" e "especificar em código"?

A aposta do DSPy é que o movimento certo é escrever código que gera prompts, não prompts diretamente. A aposta da decodificação restrita é escrever gramáticas que restringem a saída. A aposta do uso de ferramentas é escrever funções que o modelo chama. Cada uma delas é um lugar onde a linguagem natural dá lugar à especificação formal. Quero entender, para uma determinada classe de tarefa, onde está a fronteira correta — e desenvolver heurísticas.

4. Pode "o modelo pode cometer um erro" sair de uma propriedade do sistema para uma propriedade quantificada e contratual?

Esta é a grande pergunta. Um prompt pode vir com um SLA? Não "melhor esforço", mas "para entradas nesta classe, taxa de erro ≤ X, medida continuamente." Como seria a infraestrutura necessária para entregar e impor isso — para um único prompt, e depois para composições de prompts?

5. Quanto a precisão custa, e vale a pena pagar?

Cada movimento em direção à precisão — decodificação restrita, ancoramento por recuperação, verificação de span, delegação a ferramentas, testes comportamentais — custa latência, custo, complexidade e, às vezes, capacidade. Para quais tarefas a troca vale a pena, e como as equipes decidem? Suspeito que haja uma taxonomia útil aqui para a qual a área ainda não tem vocabulário.

O que você verá de mim sobre isso

Estou planejando compartilhar trabalho nessa área de algumas formas nos próximos meses:

• Relatórios de campo — experimentos concretos medindo a fragilidade de prompts, com metodologia aberta e resultados honestos, incluindo as partes que não funcionam.
• Descrições de padrões — quando uma abordagem específica (um contrato, uma etapa de verificação, uma estratégia de decodificação) realmente move um sistema de "melhor esforço" para "especificável", quero documentá-la com precisão suficiente para que outros possam aplicá-la.
• Posicionamentos — como este, em que estabeleço uma opinião sobre para onde a área deveria estar indo e convido à discordância.
• Esboços de ferramentas — espero que parte deste trabalho produza pequenas ferramentas abertas. Quando produzir, elas estarão abertas desde o primeiro dia.

Intencionalmente, não estou prometendo um paper, um produto ou um framework. Estou prometendo atenção sustentada a um problema que acho que a indústria parou de olhar com clareza.

A razão pela qual isso importa

De vez em quando, uma indústria desenvolve um pedaço de sabedoria recebida que, na verdade, é uma suposição que sustenta peso confundida com uma lei da natureza. "Sites precisam ser servidos a partir de um único local físico." "Bancos de dados não podem ser ao mesmo tempo consistentes e disponíveis sob partições." "Software é entregue com bugs e é assim mesmo."

Algumas dessas suposições se revelam verdadeiras. Algumas se revelam temporárias, e as pessoas que percebem cedo — e constroem a alternativa — definem a próxima década.

Acho que "a IA comete erros" está na segunda categoria. Não porque a geração atual de modelos não vá cometer erros — eles cometerão, frequentemente, e quero ser honesto sobre isso — mas porque a suposição de que erros são intrínsecos, em vez de serem uma propriedade de como esses sistemas estão sendo construídos atualmente, está começando a parecer uma falha de imaginação.

A boa notícia é que o caminho à frente não exige nenhuma descoberta dramática única. Exige a mesma disciplina de engenharia chata e acumulada pela qual todos os outros ramos da computação passaram. Contratos. Testes. Diffs. Versionamento. SLAs. Componibilidade. Verificação.

A má notícia é que nada disso é glamouroso, e muito pouco aparece em posts de lançamento.

Eu gostaria de passar o próximo tempo construindo, medindo e escrevendo sobre as partes não glamourosas. Se isso te interessa — ou, especialmente, se você discorda de qualquer um dos pontos acima — eu adoraria saber de você. Linhas de pesquisa ficam melhores em público.

Este é o tiro de abertura. Mais por vir.