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 (multidimensional): 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, precisã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 isso funcionar:

Portanto, “uma métrica por execução” é um contrato sobre o formato do sinal, não um limite para 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 totalizando 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 (agente/uso de ferramentas):

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

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

Defina um ou mais objetivos de bloqueio. 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 falhar na barra de segurança, mesmo que ocasionalmente.

Por que isso é melhor do que apenas pesar: apenas com pesos, o otimizador pode trocar segurança por qualidade e ainda aumentar a pontuação. Um portão impossibilita a troca por 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 portas rígidas, menos ambíguas que somas ponderadas.

Padrão 4 — Lambda externa, LLM-as-a-Judge interna (recomendada 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 “necessidades de um modelo para julgar” (tom, fidelidade, utilidade). Isso geralmente é mais limpo do que pedir que uma LLM-as-a-Judge única pontuação composta produza uma única pontuação composta, porque as partes determinísticas não mudam de corrida para corrida.

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 peso. O juiz emite pontuações por dimensão e umOverall; o sistema analisa Overall (ou calcula a média das dimensões, se estiverem Overall 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. O mais rápido para escrever. Observe a variância do juiz — execute novamente o mesmo conjunto de dados duas vezes e verifique a estabilidade da pontuação antes de confiar nela como sinal de otimização.

Escolhendo um padrão

Você pode combinar padrões. Uma métrica de produção típica é “soma ponderada + um limite absoluto de segurança”.

Modos de falha a serem observados

Pre-launch lista de verificação

Otimizando solicitações em vários turnos e em etapas

O Advanced Prompt Optimization otimiza um único modelo de prompt em relação às avaliações por amostra. Ele não tem reconhecimento de turnos nativo — 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, ajuste o estado da caixa de diálogo às variáveis de entrada do modelo, incorpore as instruções do sistema que você deseja refinar e teste promptTemplate as curvas que realmente lhe interessam com respostas de referência por amostra.

Esse padrão é agnóstico vertical. Ele se aplica em qualquer lugar em que um modelo é invocado repetidamente com um contexto crescente: fluxos de atendimento ao cliente, ciclos de uso de ferramentas agentes, 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 a Advanced Prompt Optimization realmente otimiza

Tudo o que você quiser otimizado deve estar dentro de promptTemplate si mesmo. 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 as variáveis de solicitação mais entrada renderizadas 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 do diálogo por vez. Cada amostra de avaliação representa um único ponto de decisão dentro dessa fase.

Um “estágio” aqui é tudo 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

Prós: sinal de feedback rígido, solicitações menores, execuções de otimização mais rápidas e mais facilidade de criar uma métrica focada.

Contras: Não percebe a diferença entre os estágios; você executará o serviço uma vez por estágio e talvez precise de um teste final de integração.

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

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

Quando usar o Padrão B

Forma do modelo

O prompt monolítico completo do sistema multifásico 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:

Para critérios compostos em vários turnos ou várias subverificações (exatidã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 Prompt para várias voltas

Lista de verificação inicial