Prompt
Prompt é a entrada que condiciona o comportamento de um modelo, podendo reunir instruções, pergunta, exemplos, contexto, documentos, schemas e resultados de ferramentas. Em sistemas conversacionais, ele pode ser composto por mensagens com papéis diferentes e não apenas por uma frase do usuário. A qualidade melhora quando objetivo, restrições, dados e formato são explícitos. Porém, prompt não é um mecanismo de segurança: instruções podem ser ambíguas, conflitantes ou atacadas por prompt injection. Autorizações, validações e limites de ação precisam existir fora do modelo.
Prompt é uma entrada estruturada ou textual que orienta o modelo sobre a tarefa, os dados disponíveis, as restrições e a forma esperada de resposta. Em APIs modernas, pode ser uma sequência de mensagens de sistema, desenvolvedor, usuário, ferramentas e assistente, além de imagens ou arquivos. O prompt não é necessariamente escrito por uma pessoa: o aplicativo monta partes fixas, contexto recuperado, estado e pedido. A clareza reduz ambiguidade, mas não produz garantia formal. Em casa inteligente, um prompt pode pedir a interpretação de uma frase e a geração de argumentos para uma função. O backend deve validar tudo. Senhas, chaves e autorização não pertencem ao prompt. O modelo é um componente probabilístico sujeito a instruções conflitantes e conteúdo malicioso.
- Um prompt eficaz separa instrução, contexto e dados. Delimitadores, títulos e schemas ajudam. Em vez de “entenda o comando”, a aplicação pode dizer: “extraia uma intenção permitida; use apenas entidades fornecidas; retorne JSON conforme schema; não execute; quando houver ambiguidade, retorne `needs_clarification=true`”. O catálogo de entidades é dado. Exemplos few-shot mostram formatos, mas também consomem tokens e podem induzir padrão excessivo. A ordem importa. Regras críticas ficam no nível de instrução de maior prioridade da plataforma. Dados recuperados são marcados como não confiáveis. O prompt deve ser curto o suficiente para manutenção e longo o necessário para precisão. Redundância não garante obediência.
- O prompt precisa considerar o contrato de saída. Texto livre é difícil de validar. Structured outputs, JSON Schema ou function calling reduzem. Mesmo assim, o backend verifica tipo, faixa, enum, ID, permissão e precondição. Se o modelo retorna brilho 150%, o validador rejeita ou limita conforme política. Se inventa dispositivo, o resolvedor falha. A aplicação não executa string como código ou SQL. Para automação, a saída pode ser plano com etapas e nível de risco. A confirmação é externa. O prompt instrui a não assumir estado; ferramentas consultam. A linguagem do usuário é preservada na resposta, mas IDs são internos. A execução registra chamada e resultado.
- Prompts são versionados como código. Mudanças afetam comportamento e precisam de testes de regressão. Guarde versão, modelo, parâmetros e conjunto de avaliação. Não altere em produção sem medir. Testes incluem comandos comuns, negação, ambiguidade, erros de ASR, português, nomes parecidos, multiusuário e ataques. Métricas: acerto de intenção, validade do schema, clarificação, ação indevida, custo e latência. A/B testing deve respeitar risco. Um prompt que aumenta taxa de execução pode reduzir segurança. Rollback existe. Logs de prompt podem conter dados pessoais; use redaction e amostragem. Não registrar tokens de acesso. O usuário não precisa ver instruções internas, mas deve conhecer limites e uso de dados.
- Prompt injection ocorre quando conteúdo não confiável tenta alterar instruções. Pode vir do usuário, site, e-mail, PDF, imagem com texto, nome de dispositivo ou resultado de ferramenta. Um documento recuperado dizendo “ignore as regras” deve ser tratado como dado. Delimitar ajuda, mas não é suficiente. A segurança usa allowlist de ferramentas, autorização, confirmação, sandbox, filtros de dados e redução de privilégios. O modelo não recebe credenciais. A ferramenta não aceita destinos arbitrários. Para RAG, fontes externas não podem instruir chamadas. O sistema pode classificar e detectar, mas ataques evoluem. A premissa é que o prompt não é fronteira de segurança. Uma saída manipulada deve encontrar barreiras no backend.
- Prompts podem incorporar raciocínio por etapas, decomposição, crítica e autoavaliação, mas pedir cadeia de pensamento explícita não é requisito e pode expor conteúdo ou aumentar custo. É melhor solicitar resultado verificável, plano resumido e evidências. Para cálculos, use calculadora. Para estado, API. Para busca, RAG. Para códigos, ferramentas. O prompt roteia. Técnicas como self-consistency aumentam chamadas e não garantem. Em casa, uma resposta rápida e correta vale mais que texto longo. O sistema pode pedir ao modelo para listar suposições e incertezas. A confiança declarada pelo modelo não é probabilidade calibrada. Decisões críticas usam sinais externos.
- O prompt deve respeitar a janela de contexto e a hierarquia. Instruções duplicadas podem entrar em conflito. Histórico de usuário pode conter pedidos antigos que não valem. Resumos gerados podem distorcer. A aplicação monta contexto determinístico: política atual, identidade, entidades candidatas, estados com timestamp e fontes. O pedido do usuário fica separado. Após ferramenta, o resultado é anexado com estrutura. O modelo gera resposta. O prompt não deve incluir todo o banco. A recuperação é seletiva. Modelos diferentes interpretam prompts de modo diferente; migração exige ajuste. A portabilidade não é garantida. O design deve manter regras de negócio fora para reduzir dependência.