Ajuste Fino por Reforço com LLM-as-a-Judge nos modelos Amazon Nova

O problema de alinhamento dos modelos de linguagem

Grandes Modelos de Linguagem (LLMs) já estão no centro de agentes conversacionais, ferramentas criativas e sistemas de apoio a decisões. Mas o output bruto desses modelos frequentemente carrega imprecisões, desalinhamentos de política ou respostas pouco úteis — problemas que comprometem a confiança e limitam o uso real em produção.

Para resolver isso, o Ajuste Fino por Reforço (RFT) se consolidou como o método preferido de alinhamento eficiente. Em vez de depender de rotulagem manual cara e demorada, o RFT usa sinais de recompensa automatizados para guiar o comportamento do modelo.

No centro do RFT moderno estão as funções de recompensa, construídas de duas formas principais:

• Aprendizado por Reforço com Recompensas Verificáveis (RLVR): usa código para avaliar as respostas geradas pelo modelo com critérios verificáveis.
• Aprendizado por Reforço com Feedback de IA (RLAIF): usa um segundo modelo de linguagem como “juiz” para avaliar as respostas candidatas — a técnica conhecida como LLM-as-a-judge.

A AWS publicou um post técnico detalhando como o RLAIF funciona na prática com os modelos Amazon Nova, incluindo um caso de uso real no setor jurídico.

Por que usar LLM-as-a-judge em vez de recompensas genéricas?

Recompensas genéricas baseadas em regras simples — como correspondência de substrings — funcionam para casos bem definidos, mas falham quando os critérios de qualidade são subjetivos ou multidimensionais.

Um juiz baseado em LLM raciocina sobre múltiplas dimensões ao mesmo tempo: correção, tom, segurança, relevância. Ele captura nuances e especificidades de domínio sem precisar de retreinamento específico por tarefa. Além disso, oferece explicabilidade embutida por meio de justificativas — algo que funções de recompensa estáticas simplesmente não conseguem fornecer.

Seis passos para implementar o LLM-as-a-judge

1. Escolha a arquitetura do juiz

Existem dois modos principais de avaliação:

• Julgamento baseado em rubrica (pontuação absoluta): atribui uma nota numérica a uma única resposta com base em critérios predefinidos. Recomendado quando não há dados de preferência disponíveis e o RLVR não é adequado. Funciona melhor para dados fora da distribuição e evita viés de dados.
• Julgamento baseado em preferência (comparação relativa): compara duas respostas candidatas lado a lado e seleciona a superior. Recomendado quando há dados comparativos disponíveis e o modelo deve explorar livremente sem restrições de dados de referência.

2. Defina os critérios de avaliação

Critérios claros são a base de um treinamento RLAIF eficaz. Para juízes baseados em rubrica, a AWS recomenda usar pontuação booleana (aprovado/reprovado) em vez de escalas de 1 a 10 — isso reduz a variabilidade do juiz e torna a avaliação mais confiável.

3. Selecione e configure o modelo juiz

A escolha do modelo depende da complexidade do domínio e do equilíbrio entre custo e confiabilidade:

• Modelos grandes/pesados (Amazon Nova Pro, Claude Opus, Claude Sonnet): indicados para raciocínio complexo, avaliação com nuances e pontuação multidimensional. Alto custo, altíssima confiabilidade.
• Modelos médios/leves (Amazon Nova 2 Lite, Claude Haiku): adequados para domínios gerais como matemática ou programação. Custo baixo a médio, confiabilidade moderada a alta.

O juiz é configurado via Amazon Bedrock e chamado por uma função AWS Lambda de recompensa.

4. Refine o prompt do modelo juiz

O prompt do juiz é o alicerce da qualidade do alinhamento. Ele deve produzir saídas estruturadas e facilmente parseáveis, com regras de pontuação claras, tratamento de casos extremos e comportamentos desejados explicitamente definidos.

5. Alinhe os critérios do juiz com as métricas de produção

A função de recompensa deve espelhar as métricas que serão usadas para avaliar o modelo final em produção. O fluxo recomendado é: definir critérios de sucesso em produção, mapear cada critério para dimensões de pontuação do juiz, validar a correlação entre as notas do juiz e as métricas de avaliação, e testar em amostras representativas e casos extremos.

6. Construa uma função Lambda de recompensa robusta

Sistemas RFT em produção processam milhares de avaliações de recompensa por etapa de treinamento. A AWS recomenda combinar o juiz LLM com componentes de recompensa determinísticos rápidos para capturar falhas óbvias antes de acionar avaliações mais custosas:

• Validação de formato: verifica estrutura JSON, campos obrigatórios e conformidade com o schema — sempre, pois é barato e instantâneo.
• Penalidades de tamanho: desencoraja respostas excessivamente longas ou curtas, quando o comprimento importa.
• Consistência de idioma: verifica se as respostas correspondem ao idioma de entrada — crítico para aplicações multilíngues.
• Filtros de segurança: verificações baseadas em regras para conteúdo proibido — sempre, para evitar que conteúdo inseguro chegue à produção.

Do ponto de vista de infraestrutura, a AWS recomenda: implementar backoff exponencial para lidar com limites de taxa da API do Amazon Bedrock, usar ThreadPoolExecutor ou padrões assíncronos para paralelizar chamadas ao juiz, configurar o timeout da Lambda para 15 minutos e usar concorrência provisionada de aproximadamente 100 para configurações típicas. Erros devem retornar recompensas neutras (0.5) em vez de interromper toda a etapa de treinamento.

Fluxo de treinamento RFT com LLM-as-a-judge

O processo completo de ponta a ponta passa por três fases principais: configuração e validação, treinamento e implantação. O diagrama abaixo ilustra esse fluxo, mostrando como cada etapa se apoia na anterior para criar um pipeline resiliente que equilibra qualidade de alinhamento com eficiência computacional.

• Fase 1 — Configuração e Validação: avaliação do modelo juiz, avaliação de baseline e design do dataset e das funções de recompensa.
• Fase 2 — Treinamento: treinamento iterativo com monitoramento contínuo de distribuições de recompensa, scores de vantagem, taxa de concordância do juiz e detecção de reward hacking.
• Fase 3 — Implantação: verificação de diversidade de rollouts, calibração do juiz, alinhamento recompensa-avaliação e ausência de reward hacking antes do deploy.

Caso de uso real: revisão automatizada de contratos jurídicos

O post da AWS descreve uma aplicação prática com um parceiro do setor jurídico. O desafio era automatizar a revisão, avaliação e identificação de riscos em documentos de contratos, comparando-os com diretrizes internas, regulamentações, contratos anteriores e legislação aplicável.

O problema foi formulado da seguinte forma: dado um documento-alvo (o contrato a ser avaliado) e um documento de referência (as diretrizes e contexto), o LLM deve gerar um JSON com comentários, tipos de comentário e ações recomendadas baseadas na avaliação.

O dataset original era relativamente pequeno, contendo contratos completos com anotações e comentários de especialistas jurídicos. Foi utilizado um modelo GPT OSS 120b como juiz, com um system prompt personalizado durante o RFT.

Estrutura do prompt do juiz para revisão de contratos

O prompt do juiz foi construído em camadas bem definidas:

a) Objetivo de alto nível:

# Contract Review Evaluation - Unweighted Scoring
You are an expert contract reviewer evaluating AI-generated comments. Your PRIMARY objective is to assess how well each predicted comment identifies issues in the TargetDocument contract clauses and whether those issues are justified by the Reference guidelines.

b) Abordagem de avaliação: define o que o modelo recebe (TargetDocument, Reference, Prediction) e instrui o juiz a avaliar cada comentário de forma independente, verificando se o campo text_excerpt cita texto do contrato-alvo — não das diretrizes de referência.

c) Dimensões de pontuação: três dimensões avaliadas em sequência obrigatória — TargetDocument_Grounding, Reference_Consistency e Actionability — cada uma com escala de 1 a 5 e critérios explícitos para cada nota.

d) Formato de saída: JSON estruturado com pontuação por comentário, justificativas e score agregado.

e) Handler Lambda com multithreading:

def lambda_handler(event, context):
    scores: List[RewardOutput] = []
    samples = event
    max_workers = len(samples)
    print(f"Evaluating {len(samples)} items with {max_workers} threads...")
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        futures = [executor.submit(judge_answer, sample) for sample in samples]
        scores = [future.result() for future in futures]
    print(f"Completed {len(scores)} evaluations")
    return [asdict(score) for score in scores]

Configuração de permissões e IAM

A função de execução do Amazon SageMaker AI precisa de permissão para invocar a Lambda de recompensa:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:InvokeFunction"
      ],
      "Resource": "arn:aws:lambda:region:account-id:function:function-name"
    }
  ]
}

A AWS reforça que o nome da função Lambda deve conter “SageMaker” (por exemplo, arn:aws:lambda:us-east-1:123456789012:function:MyRewardFunctionSageMaker) e que o treinamento RFT pode falhar se as permissões estiverem ausentes. O princípio do menor privilégio deve ser aplicado, limitando as permissões a ARNs de recursos específicos. Para mais detalhes, consulte a documentação de Segurança no AWS Lambda e a Segurança no Amazon SageMaker AI.

Personalização do treinamento com o Nova Forge SDK

A AWS disponibilizou o Nova Forge SDK para gerenciar todo o ciclo de personalização de modelos — da preparação dos dados ao deploy e monitoramento. O SDK elimina a necessidade de buscar receitas ou URIs de container para técnicas específicas. No caso de uso jurídico, os parâmetros de treinamento foram ajustados via overrides:

# Launch training with recipe overrides
result = customizer.train(
    job_name="my-rft-run",
    rft_lambda_arn="",
    overrides={
        # Training config
        "max_length": 64000,
        "global_batch_size": 64,
        "reasoning_effort": None,
        # Data
        "shuffle": False,
        # Rollout
        "type": "off_policy_async",
        "age_tolerance": 2,
        "proc_num": 6,
        "number_generation": 8,
        "max_new_tokens": 16000,
        "set_random_seed": True,
        "temperature": 1,
        "top_k": 0,
        "lambda_concurrency_limit": 100,
        # Trainer
        "max_steps": 516,
        "save_steps": 32,
        "save_top_k": 17,
        "refit_freq": 4,
        "clip_ratio_high": 0.28,
        "ent_coeff": 0.0,
        "loss_scale": 1,
    },
)

Resultados: RFT supera modelos maiores

Os resultados foram avaliados em um cenário “best of k” com comentário único, onde cada modelo gerou múltiplos comentários por amostra e o de maior qualidade foi pontuado. Essa abordagem estabelece um limite superior de desempenho e permite comparação justa entre modelos.

O Amazon Nova 2 Lite com RFT alcançou score agregado de 4.33 — o maior entre todos os modelos avaliados — além de validação perfeita do schema JSON. Isso representa uma melhoria significativa sobre o Nova 2 Lite base (3.05), o Nova 2 Lite com Ajuste Fino Supervisionado — SFT (3.16), o Claude Haiku 4.5 (3.54) e o Claude Sonnet 4.5 (3.89).

Outros destaques dos resultados:

• Eliminação de artefatos indesejados: durante iterações de SFT, foram observados comportamentos problemáticos como geração repetitiva de comentários e predições anômalas de caracteres Unicode. Esses problemas não apareceram nos checkpoints de RFT, pois o mecanismo de recompensa desencoraja naturalmente tais artefatos.
• Boa generalização para novos critérios de avaliação: quando os modelos RFT foram avaliados com um prompt de juiz modificado (alinhado, mas não idêntico ao usado no treinamento), o desempenho se manteve forte — evidência de que o RFT aprende padrões de qualidade generalizáveis, não apenas decora critérios específicos.
• Custo computacional maior: o RFT exigiu de 4 a 8 rollouts por amostra de treinamento, aumentando os custos em relação ao SFT. Para aplicações de missão crítica — como revisão jurídica, conformidade financeira ou documentação de saúde — os ganhos de desempenho justificam esse custo adicional.

Conclusão

O RFT com LLM-as-a-judge representa uma abordagem poderosa para alinhar LLMs a aplicações específicas de domínio. Como demonstrado no caso de revisão de contratos jurídicos, a metodologia entrega melhorias significativas sobre modelos base e sobre o ajuste fino supervisionado tradicional.

Para equipes que constroem sistemas de IA de missão crítica, a recomendação da AWS é começar pequeno: validar o design do juiz em benchmarks curados, verificar a resiliência da infraestrutura e escalar gradualmente monitorando sinais de reward hacking.

Para aprofundamento, a AWS disponibiliza o Guia do Desenvolvedor Amazon Nova 2, o Nova Forge SDK no GitHub e a documentação de Ajuste Fino por Reforço (RFT) com modelos Amazon Nova.

Fonte

Reinforcement fine-tuning with LLM-as-a-judge (https://aws.amazon.com/blogs/machine-learning/reinforcement-fine-tuning-with-llm-as-a-judge/)