Migre e otimize seus prompts em múltiplos modelos com o Amazon Bedrock Advanced Prompt Optimization

O problema que todo time de IA generativa conhece bem

Você finalmente tem uma aplicação de IA generativa funcionando em produção. Os prompts estão ajustados, as respostas são consistentes e os usuários estão satisfeitos. Então aparece um modelo novo no Amazon Bedrock — mais rápido, mais barato, mais capaz — e você precisa decidir se vai migrar.

Na teoria, a decisão deveria ser simples. Na prática, equipes gastam dias ou semanas reescrevendo prompts, rodando testes e comparando resultados manualmente. Multiplique esse esforço por cada template de prompt em produção e por cada modelo candidato a avaliar, e você tem um problema que cresce proporcionalmente à ambição do projeto.

É exatamente esse gargalo que a AWS endereça com o lançamento do Advanced Prompt Optimization no Amazon Bedrock: uma ferramenta que otimiza prompts para até 5 modelos simultaneamente, comparando desempenho original e otimizado em um único job.

Por que esse problema trava o ciclo de desenvolvimento

A migração e a otimização de prompts afetam quatro pontos críticos no ciclo de vida de aplicações de IA generativa:

• Dependência excessiva de modelo: times evitam migrar porque o custo de reajuste é alto demais, mesmo quando um modelo mais novo reduziria latência e custo de inferência.
• Desempenho abaixo do potencial: prompts escritos para um modelo raramente aproveitam as capacidades plenas de outro.
• Cegueira para regressões: sem avaliação sistemática contra resultados esperados, é impossível distinguir “diferente” de “pior”. Times colocam saídas degradadas em produção sem perceber.
• Ciclos de iteração lentos: cada mudança de prompt exige testes manuais de A/B, mantendo engenheiros em loops de avaliação em vez de construindo funcionalidades.

Como o Advanced Prompt Optimization funciona

O Amazon Bedrock Advanced Prompt Optimization opera de trás para frente a partir da sua métrica de avaliação. Em vez de reescrever prompts de forma heurística, o sistema funciona em um loop de feedback no estilo de aprendizado por reforço — sem alterar os pesos do modelo:

• Você fornece um template de prompt, exemplos de entradas (texto ou multimodal), respostas esperadas opcionais e uma métrica de avaliação.
• O otimizador envia o template e as entradas para os modelos de inferência escolhidos.
• Ele avalia as respostas contra a métrica e reescreve o prompt.
• O loop se repete (avaliar, reescrever, avaliar) até otimizar iterativamente o prompt.

A saída inclui os prompts original e otimizado. Para cada um, você recebe pontuações de avaliação, tempo até o primeiro token (TTFT — Time to First Token) por amostra e estimativas de custo de inferência com preços sob demanda. A arquitetura é agnóstica de modelo: um único job pode ter como alvo até 5 modelos ao mesmo tempo, entregando uma comparação direta de qualidade, latência e custo.

O que é TTFT?

TTFT (Time to First Token — Tempo até o Primeiro Token) mede a velocidade com que o modelo começa a responder: o tempo entre o envio da requisição e o recebimento do primeiro token. É um indicador útil de latência percebida, como um chatbot que começa a digitar. Como o TTFT reflete condições reais de infraestrutura em tempo real, leia valores de execução única como um sinal direcional — e combine com contagens de tokens de saída para ter o panorama completo de latência.

Dois casos de uso, três modos de avaliação

O Advanced Prompt Optimization pode ser usado de duas formas:

• Migração de modelo: selecione seu modelo atual como baseline e até 4 candidatos. Você recebe prompts otimizados para cada um e uma comparação lado a lado.
• Melhoria no mesmo modelo: selecione apenas seu modelo atual. Você obtém um prompt melhor sem mudar nada mais.

Para cada template de prompt, você escolhe um dos três métodos de avaliação:

• Função AWS Lambda: ideal para métricas concretas (acurácia, F1, ROUGE, correspondência de JSON etc.). Você fornece uma função Lambda com lógica de pontuação compute_score.
• LLM-as-a-Judge (LLM como Juiz): indicado para tarefas abertas (sumarização, raciocínio, geração). Você fornece um prompt de rubrica e escolhe o modelo juiz.
• Critérios de direcionamento (Steering Criteria): para voz de marca, formato e restrições de segurança. Você define até 5 critérios em linguagem natural.

Se você omitir todos os campos de avaliação, o sistema usa um padrão embutido que combina acurácia, completude da resposta e pontuação de estilo de escrita. A AWS recomenda definir sua própria métrica para melhores resultados. Se você tiver mais de um objetivo, pode criar uma métrica composta com pesos para cada critério — mas a saída da métrica deve ser um único número.

Suporte multimodal

O Advanced Prompt Optimization suporta entradas multimodais: arquivos PNG, JPG, JPEG, GIF, WebP e PDF referenciados via URIs do Amazon S3 (Simple Storage Service). Isso permite otimizar prompts para análise de documentos, classificação de imagens, resposta visual a perguntas e outras tarefas que combinam texto com entrada visual.

Preparando o dataset de entrada (formato JSONL)

O arquivo de entrada usa formato JSONL (JSON Lines), com um objeto JSON por linha — cada linha é um template de prompt a otimizar. Para detalhes completos, consulte a documentação técnica. O schema principal é:

{
  "version": "bedrock-2026-05-14",
  "templateId": "unique-id-for-this-template",
  "promptTemplate": "Your prompt with {{variableName}} placeholders",
  "evaluationSamples": [
    {
      "inputVariables": [
        {"variableName": "value"}
      ],
      "referenceResponse": "Expected output (optional but recommended)"
    }
  ]
}

Em seguida, adicione um dos campos de método de avaliação. Para mais detalhes, consulte a documentação técnica de avaliação. Abaixo, o snippet para a opção de métrica via AWS Lambda:

{
  "evaluationMetricLambdaArn": "arn:aws:lambda:us-west-2:111122223333:function:my-metric",
  "customEvaluationMetricLabel": "my_score_name"
}

Para a opção LLM-as-a-Judge:

{
  "customLLMJConfig": {
    "customLLMJPrompt": "Your rubric. Use {{prompt}}, {{response}}, {{referenceResponse}} as placeholders.",
    "customLLMJModelId": "us.anthropic.claude-opus-4-6-v1"
  },
  "customEvaluationMetricLabel": "my_judge_metric"
}

No customLLMJPrompt, referencie 3 placeholders com chaves duplas: {{prompt}} (o prompt completamente renderizado), {{response}} (a saída do modelo) e {{referenceResponse}} (a resposta esperada). O Advanced Prompt Optimization substitui esses valores para cada candidato e amostra antes de enviar a rubrica ao modelo juiz. Para detalhes, veja como usar um LLM como juiz.

Para a opção de critérios de direcionamento:

{
  "steeringCriteria": [
    "be concise",
    "use professional tone",
    "avoid speculation"
  ]
}

Criando e acompanhando um job via API (boto3)

É possível conduzir todo o fluxo com boto3. O código abaixo cria um job com dois modelos candidatos:

import boto3

bedrock = boto3.client("bedrock", region_name="us-west-2")

response = bedrock.create_advanced_prompt_optimization_job(
    jobName="my-migration-job",
    modelConfigurations=[
        {"modelId": "us.amazon.nova-2-lite-v1:0"},          # candidate 1
        {"modelId": "us.anthropic.claude-haiku-4-5-20251001-v1:0"},  # candidate 2
    ],
    inputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/inputs/prompts.jsonl"
    },
    outputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/outputs/migration-job/"
    },
)

job_arn = response["jobArn"]
print(f"Job submitted: {job_arn}")

Um job roda de forma assíncrona. Para verificar o status a cada 60 segundos:

import time

while True:
    info = bedrock.get_advanced_prompt_optimization_job(jobIdentifier=job_arn)
    status = info["jobStatus"]
    print(f"Status: {status}")
    if status in ("Completed", "Failed", "Stopped"):
        break
    time.sleep(60)

Quando o job é concluído, ele escreve automaticamente um arquivo de resultados JSONL no local de saída do S3 definido na criação. Para baixá-lo:

# Results land at: s3://output-uri/job-id/advanced_prompt_optimization_results.jsonl
s3 = boto3.client("s3")
job_id = job_arn.rsplit("/", 1)[-1]
result_key = f"outputs/migration-job/{job_id}/advanced_prompt_optimization_results.jsonl"
s3.download_file("amzn-s3-demo-bucket", result_key, "results.jsonl")

Resultados reais: o que esperar de ganhos

A AWS divulgou resultados de 4 jobs reais rodados na região US East (N. Virginia), cada um com 5 amostras de avaliação. Os números são ilustrativos do tipo de ganho que o otimizador entrega — não constituem um benchmark formal. É possível reproduzi-los com os datasets do repositório de tutoriais no GitHub.

• XSum (sumarização) — Steering, Claude Haiku 4.5: Quality Score de 0,550 para 0,743 (+35%). Os critérios de direcionamento produziram respostas mais curtas, reduzindo tokens de saída de 51 para 28. O prompt otimizado cresceu de 720 para 1.601 tokens de entrada.
• NESTFUL (chamada de função) — Lambda, Nova 2 Lite: acurácia de 0,267 para 0,647 (+143%). O prompt cresceu de ~1,3K para ~3,8K tokens de entrada ao adicionar regras explícitas de decomposição e exemplos.
• MM-VQA (resposta visual a documentos) — Lambda, Claude Haiku 4.5: ROUGE-L de 0,339 para 0,777 (+129%), com crescimento de apenas ~7% nos tokens de entrada (30.998 para 33.057). O otimizador afiou o prompt em vez de alongá-lo.
• IFBench (seguimento de instruções) — LLM-as-a-Judge, Kimi K2.5: aderência a restrições de 0,413 para 0,890 (+115%). O caso mais intensivo em tokens, com crescimento expressivo para detalhar as restrições que o modelo deve satisfazer.

Entendendo os trade-offs de custo e latência

Prompts otimizados não mudam apenas a qualidade — eles mudam o que você paga e o tempo de esposta. O Bedrock cobra por token de entrada e de saída, sendo os tokens de saída geralmente mais caros. O padrão observado nos 4 runs é consistente: otimização entregou grandes ganhos de qualidade, e todo prompt otimizado usou mais tokens no total.

O aumento variou de ~7% a mais (MM-VQA) até várias vezes mais (IFBench). Quando a saída encolhe — como em XSum e MM-VQA — isso suaviza o aumento total de custo. O otimizador entrega as contagens exatas de tokens e pontuações, permitindo calcular o custo real para o seu volume de tráfego e escolher o trade-off adequado para cada workload.

Vale destacar: você pode moldar a saída diretamente adicionando um objetivo nos critérios de avaliação que recompense respostas mais curtas. O otimizador então favorecerá prompts que as produzam.

Limites e boas práticas

Antes de rodar um job, é útil conhecer os limites por job:

• Templates por job: 10
• Amostras de avaliação por template: 100
• Modelos por job: 5
• Variáveis de texto por template: 20
• Arquivos multimodais por amostra: 100
• Critérios de direcionamento por template: 5

Algumas práticas importantes:

• Escolha um único método de avaliação por template — combinar steeringCriteria com customLLMJConfig ou evaluationMetricLambdaArn não é suportado.
• Use chaves duplas ({{variavel}}) nos templates, não chaves simples.
• Dê a cada variável em inputVariables seu próprio objeto.
• Misture exemplos fáceis e difíceis no dataset. Um conjunto só com exemplos fáceis não desafia o otimizador; um conjunto só com difíceis não deixa nada para ele aprender.
• Para LLM-as-a-Judge, há atualmente 3 modelos juiz disponíveis: anthropic.claude-opus-4-6-v1, anthropic.claude-sonnet-4-5-20250929-v1:0 e anthropic.claude-sonnet-4-6. Consulte as regiões, modelos e cotas suportados para disponibilidade por região.

Recursos para aprofundamento

• Como o Advanced Prompt Optimization funciona
• Referência de API: CreateAdvancedPromptOptimizationJob
• GitHub: notebooks de tutorial para os três modos de avaliação
• Documentação: como preparar seu dataset de entrada

Fonte

Migrate your prompts to new models and optimize them on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/migrate-your-prompts-to-new-models-and-optimize-them-on-amazon-bedrock/)