Como pedir trabalho a uma IA: contexto, critérios e verificação

Uma pergunta clara ajuda um modelo de linguagem, mas não garante uma resposta correta. O prompt define o trabalho esperado; fontes, ferramentas, testes e revisão determinam quanto podemos confiar no resultado.

Essa diferença importa porque conversar com uma pessoa e instruir um modelo não são a mesma atividade. Uma pessoa pode relatar uma experiência, assumir responsabilidade e explicar uma decisão que tomou. Um modelo gera uma resposta a partir do contexto e dos padrões aprendidos. Quando perguntamos “como você chegou a essa conclusão?”, a explicação também é uma saída gerada, não um registro auditável do processo interno.

Eu trataria prompting como especificação e avaliação, não como a arte de encontrar palavras mágicas.

Comece pela tarefa, não pela persona

“Você é o melhor especialista do mundo” acrescenta autoridade ao tom, mas não fornece os dados necessários para resolver um problema.

Um pedido operacional começa pelo verbo e pelo objeto:

Compare as duas configurações de deploy fornecidas abaixo.
Identifique diferenças que alterem disponibilidade, custo ou rollback.

Depois entram contexto, limites e formato. A documentação de prompting do Google recomenda instruções claras, contexto relevante, exemplos e definição do formato de saída. Ela também trata prompting como processo iterativo, não como receita estática.

As partes de um prompt verificável

Para tarefas profissionais, eu procuro deixar seis campos distinguíveis:

tarefa: o que precisa ser feito
contexto: dados e documentos disponíveis
restricoes: o que não pode ser assumido ou alterado
saida: formato e nível de detalhe esperados
criterios: como reconhecer uma resposta aceitável
incerteza: o que fazer quando faltar evidência

Nem todo prompt precisa usar YAML. A estrutura serve para conferir se uma informação importante ficou implícita.

Compare dois pedidos.

Explique qual configuração é melhor.

Compare os arquivos A e B apenas com base no conteúdo fornecido.

Avalie:
- tempo de rollback;
- dependências externas;
- impacto de uma falha parcial;
- esforço operacional.

Para cada conclusão, cite o trecho que a sustenta.
Se os arquivos não permitirem decidir, identifique a informação ausente.
Entregue uma tabela e uma recomendação de até três parágrafos.

O segundo prompt não torna o modelo mais inteligente. Ele reduz ambiguidades e cria condições para revisar a resposta.

Contexto não é sinônimo de volume

Adicionar documentos pode melhorar a base factual, mas contexto excessivo também dificulta localizar o que importa. Eu incluiria o material necessário e indicaria sua função:

<politica_atual>
...
</politica_atual>

<mudanca_proposta>
...
</mudanca_proposta>

Use a política atual como fonte de restrições.
Use a mudança proposta apenas como objeto da revisão.

Delimitadores ajudam a separar dados de instruções. Quando o conteúdo vem de usuários ou fontes externas, o agente também precisa ser instruído a tratar comandos encontrados dentro desse conteúdo como dados, não como novas ordens.

Exemplos definem melhor do que adjetivos

“Seja conciso” permite muitas interpretações. Um exemplo mostra tamanho, estrutura e densidade esperados.

Entrada: serviço sem health check
Saída: alto risco — o orquestrador não consegue distinguir inicialização de falha.

Entrada: segredo incluído na imagem
Saída: alto risco — a credencial permanece no artefato e precisa ser rotacionada.

Esses exemplos orientam o formato, mas também podem estreitar demais a resposta. Eu usaria casos variados e manteria um conjunto separado para avaliar se o prompt funciona fora dos exemplos fornecidos.

Perguntas de acompanhamento ainda ajudam

Uma primeira resposta pode revelar que a tarefa estava mal definida. Perguntas de acompanhamento servem para acrescentar evidência ou ajustar critérios:

“Qual trecho do documento sustenta essa afirmação?”
“Quais informações faltam para decidir?”
“Reavalie considerando que o serviço não pode ficar indisponível.”
“Transforme as recomendações em testes executáveis.”
“Compare a saída com estes três critérios de aceitação.”

Perguntar apenas “você tem certeza?” costuma produzir outra formulação, não uma verificação independente. Para verificar, é melhor fornecer uma fonte, executar um teste, consultar uma ferramenta ou pedir uma comparação que possa ser inspecionada.

Os cinco porquês podem fabricar uma causa

A técnica dos cinco porquês ajuda equipes a explorar relações causais, mas um modelo pode preencher cada resposta com uma narrativa plausível sem acesso ao incidente real.

Considere este começo:

Por que o deploy falhou?

Sem logs, configuração e linha do tempo, qualquer sequência causal é hipótese. Um prompt mais responsável seria:

Com base apenas nos logs abaixo, liste até três hipóteses para a falha.
Para cada hipótese, informe:
- evidência favorável;
- evidência contrária;
- próximo teste;
- resultado que descartaria a hipótese.

O modelo passa a organizar uma investigação sem fingir que encontrou a causa.

Fluência não é evidência

O perfil de risco para IA generativa do NIST usa o termo confabulation para conteúdo falso ou incorreto apresentado com confiança. Um prompt detalhado pode reduzir erros em uma tarefa, mas não elimina esse comportamento.

Eu aumentaria a exigência de verificação quando a resposta envolve:

informação recente;
números ou cálculos;
saúde, direito ou finanças;
segurança e privacidade;
ações difíceis de reverter;
afirmações sobre pessoas;
comandos que alteram produção ou dados.

Nesses casos, a resposta deve apontar fontes, executar ferramentas adequadas ou ser revisada por alguém responsável pelo domínio.

Avalie o sistema, não o melhor exemplo

Um prompt não está validado porque funcionou uma vez. Para uma tarefa recorrente, eu manteria casos de teste com entradas normais, ambíguas, incompletas e adversariais.

caso:
entrada:
resultado_esperado:
criterios_de_avaliacao:
falhas_inaceitaveis:

Depois de mudar prompt, modelo ou ferramentas, o conjunto precisa ser executado novamente. A comparação mostra se a alteração melhorou o comportamento desejado ou apenas resolveu o exemplo que estava visível.

O próximo prompt precisa deixar rastros

Uma boa instrução reduz interpretações, define o formato e diz o que fazer quando a evidência não basta. Uma boa aplicação acrescenta fontes, testes, permissões e revisão proporcional ao risco.

Na próxima tarefa, eu começaria retirando a persona decorativa e escrevendo tarefa, contexto, restrições, critérios e tratamento da incerteza. Se a resposta não puder ser conferida, o problema não se resolve com uma pergunta mais elegante: falta um mecanismo de verificação.