As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Tópicos e estratégias avançadas

Tópicos nesta página

Multi-objective otimização

O Advanced Prompt Optimization aceita uma métrica por execução — uma única pontuação escalar por amostra. No entanto, ele suporta implicitamente a otimização multiobjetivo (multidimensão): você pode agrupar vários objetivos em um escalar (uma métrica composta) e o serviço otimiza o prompt em relação a esse pacote. Esta seção aborda os padrões que recomendamos, quando cada um é apropriado, e os modos de falha a serem observados.

Isso se aplica a todas as verticais — em qualquer lugar em que você se preocupe com mais de uma coisa ao mesmo tempo: precisão + tom, correção da chamada de ferramenta + segurança, fidelidade + concisão, facilidade de latência + integridade e muito mais.

Por que uma métrica é, na verdade, multiobjetivo

Dois fatos sobre o sistema fazem com que isso funcione:

Portanto, “uma métrica por execução” é um contrato sobre a forma do sinal, não um limite sobre o que você pode otimizar.

Padrões para agrupar vários objetivos em uma única métrica

Escolha um com base em como seus objetivos se relacionam entre si.

Padrão 1 — Soma ponderada (mais comum)

final = w₁·s₁ + w₂·s₂ + ... + wₖ·sₖ, com pesos somando 1.

Quando usar: os objetivos são praticamente independentes e você pode classificá-los. Trade-offs são aceitáveis — melhorar um em detrimento do outro é bom, desde que a soma aumente.

Escolhendo pesos:

Exemplo (uso agêntico/de ferramentas):

final = 0.5 * tool_correctness + 0.3 * answer_correctness + 0.2 * format_compliance

Padrão 2 — Hard-fail portões (essenciais para a segurança)

Defina um ou mais objetivos de portão. Se algum portão falhar, a pontuação é 0 (ou algum andar), independentemente do resto. Caso contrário, a pontuação é a soma ponderada dos objetivos restantes.

if not safety_check_passed:
    return 0.0
if wrong_tool_called_for_destructive_action:
    return 0.0
return 0.6 * accuracy + 0.4 * tone

Quando usar: pelo menos um objetivo não é negociável (vazamento de PII, conta errada modificada, recusa de conteúdo proibido). Use isso sempre que um aviso “bom em média” for inaceitável se ele falhar na barra de segurança, mesmo que ocasionalmente.

Por que isso é melhor do que apenas ponderar: com apenas pesos, o otimizador pode trocar segurança por qualidade e ainda assim subir a pontuação. Um portão impossibilita a troca por meio da construção.

Padrão 3 — Restrição + recompensa () Pareto-style

Escolha o objetivo mais importante como recompensa. Expresse o resto como restrições que, quando violadas, subtraem da recompensa (em vez de zerá-la).

reward = task_accuracy
penalty = 0.0
if response_too_long:
    penalty += 0.1
if missed_required_disclosure:
    penalty += 0.2
return max(0.0, reward - penalty)

Quando usar: você quer que um objetivo principal lidere, mas objetivos secundários flexíveis ainda devem moldar o prompt. Menos frágeis que portões rígidos, menos ambíguos que somas ponderadas.

Padrão 4 — Lambda externo, LLM-as-a-Judge interno (recomendado para misturas difusas e estruturais)

Uma métrica Lambda calcula subpontuações determinísticas (regex, análise JSON, validação de esquema) e chama uma LLM-as-a-Judge subavaliação para as partes difusas (tom, fidelidade, utilidade) dentro da função Lambda. Em seguida, ele os agrega em um escalar.

def compute_score(prompt, prediction, gold, ...):
    structural = grade_format_and_tools(prediction)        # 0..1 from regex
    semantic   = call_llm_judge(prediction, gold, criteria) # 0..1 from LLMJ
    if structural < 1.0 and is_safety_critical(prompt):
        return 0.0
    return 0.6 * semantic + 0.4 * structural

Quando usar: Seus objetivos combinam “fácil de testar em código” (formatos, nomes de ferramentas, tamanho, presença de citações) com “precisa de um modelo para julgar” (tom, fidelidade, utilidade). Isso geralmente é mais simples do que pedir a um LLM-as-a-Judge prompt que produza uma única pontuação composta, porque as partes determinísticas não se desviam de uma corrida para outra.

Padrão 5 — Multi-dimension LLM-as-a-Judge (sem Lambda)

Use o LLM-as-a-Judge fluxo incorporado, opcionalmente com um customLLMJConfig.customLLMJPrompt que defina suas próprias dimensões e ponderação. O juiz emite pontuações por dimensão e umOverall; o sistema analisa Overall (ou calcula a média das dimensões, se Overall estiver faltando) em um escalar [0, 1].

Quando usar: todos os seus objetivos são semânticos/difusos e você não tem subverificações determinísticas. Mais rápido de criar. Observe a variação do juiz — execute novamente o mesmo conjunto de dados duas vezes e observe a estabilidade da pontuação antes de confiar nele como o sinal de otimização.

Escolhendo um padrão

Você pode combinar padrões. Uma métrica de produção típica é “soma ponderada+uma barreira rígida de segurança”.

Modos de falha a serem observados

Pre-launch lista de verificação

Otimizando solicitações em várias voltas e em etapas

O Advanced Prompt Optimization otimiza um único modelo de solicitação em relação às avaliações por amostra. Ele não tem reconhecimento nativo de turnos — ele não pode iterar em uma caixa de diálogo ou otimizar o comportamento em um turno específico de forma nativa. Uma solicitação em etapas é um modelo de solicitação em que uma conversa ou fluxo de trabalho em vários turnos reutiliza a mesma solicitação em turnos, e a solicitação em si contém instruções para cada estágio, etapa ou fase do fluxo de trabalho. Para otimizar essas solicitações, nivele o estado da caixa de diálogo nas variáveis de entrada do modelo, incorpore as instruções do sistema que você deseja refinar e examine promptTemplate as curvas que realmente lhe interessam com respostas de referência por amostra.

Esse padrão é verticalmente agnóstico. Ele se aplica a qualquer lugar em que um modelo seja invocado repetidamente com um contexto crescente: fluxos de atendimento ao cliente, ciclos de uso de ferramentas autênticas, raciocínio em várias etapas, tutoria, turnos de assistentes de código, controle de qualidade baseado em documentos, fluxos de trabalho de triagem e muito mais.

O que o Advanced Prompt Optimization realmente otimiza

Qualquer coisa que você queira otimizar deve estar dentro de promptTemplate si mesma. Coisas que variam de acordo com a amostra (o histórico da conversa, a consulta atual do usuário, o contexto recuperado) são{{variables}}. As instruções do sistema que você deseja refinar fazem parte do modelo — nunca são uma variável de entrada ou o serviço não tem nada para reescrever.

Se você quiser que o serviço melhore o comportamento na curva N, expresse a curva N como o prompt renderizado mais as variáveis de entrada para uma amostra, sendo a saída desejada do modelo Turn-n. referenceResponse

Padrão A — Stage-at-a-time (iniciador recomendado)

Otimize uma fase da caixa de diálogo por vez. Cada amostra de avaliação representa um único ponto de decisão dentro dessa fase.

Um “estágio” aqui é o que você pode descrever com um conjunto coerente de critérios de sucesso. Exemplos por vertical:

Quando usar o Padrão A

Forma do modelo

As instruções do sistema específicas do estágio são incorporadas ao modelo (é isso que o serviço reescreve). Somente o histórico da conversa e o turno atual são variáveis. A estrutura abaixo é ilustrativa, não prescrita. Use qualquer delimitador ou layout que seu modelo manipule melhor. Os únicos requisitos são: (a) as instruções do sistema que você deseja otimizar estão dentro do modelo e (b) as variáveis por amostra são referenciadas como. {{variablename}}

You are an assistant in the {STAGE_NAME} phase of a multi-turn task.
- ...the policy / goals / format / tool-use rules for this phase...
- ...constraints the model must satisfy at this point in the conversation...

Conversation so far:
{{conversation_so_far}}

User's current message:
{{user_query}}

Forma da amostra

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n... (turns 1..N-1)"},
        {"user_query": "...the user input that triggers this stage..."}
    ],
    "referenceResponse": "...the assistant output that satisfies the stage's success criteria..."
}

Prós e contras

Vantagens: sinal de feedback apertado, solicitações menores, execuções de otimização mais rápidas, mais facilidade de criar uma métrica focada.

Contras: Não detecta desvios entre estágios; você executará o serviço uma vez por estágio e poderá precisar de um teste final de integração.

Padrão B — Conversa totalmente nivelada (avançada)

Otimize um grande prompt monolítico que possui toda a política de vários estágios. Cada amostra é o diálogo completo até uma volta da sonda.

Quando usar o Padrão B

Forma do modelo

O prompt totalmente monolítico e multifásico do sistema fica literalmente dentro do modelo. O serviço reescreve esse corpo durante a otimização. O histórico e o turno atual permanecem variáveis. Escolha qualquer layout que seu modelo manipule bem; os requisitos são apenas que as instruções a serem otimizadas façam parte do modelo e que os dados por amostra sejam referenciados. {{name}}

You are an assistant for {TASK}. The conversation may proceed through phases:
1. {PHASE_1} — ...
2. {PHASE_2} — ...
3. {PHASE_3} — ...
(...the entire multi-phase policy, tool-use rules, tone, formatting, refusal rules...)

Conversation so far (turns 1..N-1, with role tags):
{{conversation_so_far}}

User's current message:
{{user_query}}

Forma da amostra (sonda em qualquer curva N)

{
    "inputVariables": [
        {"conversation_so_far": "user: ...\nassistant: ...\n[tool_call: X(...)]\n... (turns 1..N-1)"},
        {"user_query": "...the user input at turn N..."}
    ],
    "referenceResponse": "...desired assistant output at turn N..."
}

Por que o Padrão B pode funcionar melhor do que o Padrão A

Advertências para o Padrão B

Tool-call verificação em um turno específico

O serviço vê a saída de texto do assistente. Para avaliar “o modelo chamou a ferramenta X com os argumentos corretos na curva N”, escolha uma delas:

Para obter critérios compostos em várias voltas ou várias subverificações (correção, tom e integridade da ferramenta), consulte a seção. Multi-objective otimização

Caminho recomendado

Quando não usar a Otimização Avançada de Prompts para várias voltas

Lista de verificação inicial