Prompt engineering em produção: como testar alterações?
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Defina as saídas corretas, reúna casos representativos e compare uma alteração ao prompt com uma referência fixa. Melhore a instrução, os exemplos ou o contexto fornecido de acordo com a falha observada. Reserve um conjunto de teste para verificar se a alteração funciona para além dos exemplos usados para a conceber.
Um prompt em produção precisa de tratar entradas incompletas, ambíguas e inválidas, além dos pedidos habituais.
Transforme falhas em casos de teste
Suponha que um modelo extrai campos de faturas. Inclua faturas habituais, valores em falta, disposições desconhecidas, datas contraditórias e documentos que não sejam faturas. Defina como o sistema deve tratar cada caso antes de editar o prompt.
| Falha | Alteração a comparar | Verificação |
|---|---|---|
| Campo obrigatório em falta | Clarificar o campo e acrescentar um exemplo relevante | O campo está presente quando a fonte o sustenta |
| Valor inventado | Especificar o comportamento para valores ausentes e fornecer provas | O campo sem suporte permanece vazio |
| Não é possível analisar a resposta | Usar um esquema de saída suportado | O analisador aceita a resposta completa |
| Valor correto da fonte errada | Preservar a identidade da fonte no contexto | O valor pertence ao documento pedido |
Uma saída limitada por um esquema pode resolver falhas de sintaxe. A documentação de vLLM sobre structured outputs descreve as restrições de saída suportadas. Um objeto JSON válido pode continuar a conter uma data errada ou uma afirmação sem suporte, por isso valide os valores separadamente.
Mantenha a comparação interpretável
Mantenha constantes a versão do modelo, as definições de descodificação, os dados de origem, as definições das ferramentas e os limites de saída enquanto testa a alteração ao prompt. Registe a qualidade, as categorias de falha, os tokens e a latência. Repita os casos não determinísticos vezes suficientes para verificar se a melhoria se mantém.
Os exemplos few-shot devem cobrir a variação real, incluindo entradas incompletas ou ambíguas. Acrescente-os para resolver um problema medido, em vez de assumir que mais exemplos ajudam sempre. A posição no contexto também pode importar: Lost in the Middle encontrou uma utilização desigual das provas consoante a posição nos modelos e nas tarefas testados.
Use etapas explícitas quando facilitarem o isolamento de uma falha, mas inclua as chamadas e interfaces adicionais na comparação. Aplique as permissões e outras regras obrigatórias da aplicação no código; uma mensagem de sistema, por si só, não as pode garantir.
A secção sobre prompts em produção do Guia de engenharia de LLM explica as principais técnicas e as suas limitações.