Treinamento iterativo

Visão geral do

O treinamento iterativo é o processo de ajustar repetidamente um modelo por meio de vários ciclos de treinamento em diferentes métodos de treinamento — treinar, avaliar, analisar erros, ajustar data/objectives/hyperparameters — com cada rodada começando no ponto de verificação anterior. Essa abordagem permite direcionar sistematicamente os modos de falha do modelo, incorporar exemplos selecionados que abordam pontos fracos específicos e se adaptar às mudanças nos requisitos ao longo do tempo.

Benefícios em relação ao treinamento com uma única passagem:

• Melhoria direcionada: aborde padrões de falha específicos descobertos por meio da avaliação

• Refinamento adaptativo: responda às mudanças de distribuição ou à evolução dos requisitos do produto

• Mitigação de riscos: valide as melhorias de forma incremental em vez de se comprometer com um único treinamento longo

• Eficiência de dados: concentre os esforços de coleta de dados nas áreas em que o modelo tem um desempenho inferior

• Treinamento curricular: várias rodadas de treinamento com dados de qualidade cada vez maior

Como funciona

Localização e acesso ao posto de controle

Após a conclusão de cada trabalho de treinamento, um arquivo manifesto é gerado no local de saída especificado pelo output_path parâmetro em sua configuração de treinamento.

Para acessar seu ponto de verificação

• Navegue até o especificado output_path no S3

• Baixe e extraia o output.tar.gz arquivo

• Abra o manifest.json arquivo dentro

• Localize o checkpoint_s3_bucket parâmetro, que contém o URI S3 do seu modelo treinado

Exemplo de estrutura manifest.json

{  
  "checkpoint_s3_bucket": "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<job-name>/stepID",  
  ...  
}

Entendendo os depósitos de garantia

Como os pesos do Amazon Nova são proprietários, os pontos de verificação de modelos treinados são armazenados em buckets S3 de garantia em contas AWS gerenciadas, em vez de serem copiados para sua conta. Esses baldes de garantia:

• Contenha seus pesos de modelo personalizados com segurança

• Pode ser referenciado por outros AWS serviços (inferência, avaliação e trabalhos de treinamento subsequentes)

• São acessíveis somente à sua AWS conta por meio de permissões do IAM

• Incorra em cobranças de armazenamento padrão do S3 em sua conta (consulte Considerações de custo)

Você pode usar o caminho do depósito de garantia model_name_or_path em sua próxima execução de treinamento para continuar o treinamento iterativo.

Usando pontos de verificação para treinamento iterativo

Configure seu próximo trabalho de treinamento para usar o ponto de verificação anterior como modelo básico:

run:  
  name: "my-iterative-training-job"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<previous-job-name>"  
  data_s3_path: s3://<bucket>/<data-file>.jsonl  
  replicas: 4

Quando usar o treinamento iterativo

Casos de uso ideais

Use o treinamento iterativo quando você tiver:

• Ciclos de feedback — Capacidade de coletar casos de falha do mundo real e abordá-los sistematicamente

• Ambientes dinâmicos — documentação em evolução ou tópicos APIs de suporte que exigem atualizações periódicas do modelo

• Avaliação robusta — Benchmarks e estruturas de avaliação fortes (veja os exemplos abaixo) para medir as melhorias com confiança

• Capacidade de operações de ML — recursos para gerenciar vários ciclos de treinamento e controle de versão

Exemplos de estruturas de avaliação robustas

• Suítes de benchmark automatizadas com limites pass/fail

• Protocolos de avaliação humana com métricas de confiabilidade entre avaliadores

• Cenários de testes da equipe vermelha que abrangem casos extremos e contribuições adversárias

• Infraestrutura de testes A/B para medir o impacto na produção

Padrões comuns

SFT → RFT Pipeline: Um padrão iterativo usado com frequência envolve:

• SFT primeiro — Ensine o modelo a resolver problemas por meio de exemplos de demonstração

• RFT second — Otimize o desempenho em todo o espaço de problemas usando sinais de recompensa

Essa sequência é essencial quando os modelos têm um desempenho inicial ruim — o RFT em modelos de precisão próxima de zero não melhorará o desempenho sem primeiro estabelecer recursos básicos de resolução de problemas por meio do SFT.

Quando não usar o treinamento iterativo

Evite o treinamento iterativo para:

• Tarefas estáveis e bem definidas — dados estacionários com requisitos consistentes que já atingem um desempenho próximo ao teto

• Problemas simples de classificação — tarefas restritas em que o treinamento de uma única passagem é suficiente

• Restrições de recursos — Falta de recursos operacionais de ML dedicados para gerenciar vários ciclos de treinamento

• Ganhos marginais — Quando a sobrecarga não justifica melhorias mínimas de desempenho

Exemplo de fluxo de trabalho: SFT → RFT

Este exemplo demonstra um padrão comum de treinamento iterativo para modelos de raciocínio.

Etapa 1: treinamento inicial em SFT

Configure e inicie seu trabalho de treinamento SFT com seu conjunto de dados:

run:  
  name: "initial-sft-training"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "nova-lite-2/prod"  
  data_s3_path: s3://<bucket>/sft-training-data.jsonl  
  validation_data_s3_path: s3://<bucket>/sft-validation-data.jsonl

Justificativa: O SFT fornece demonstrações adicionais que moldam as saídas do modelo no formato e na voz desejados, estabelecendo recursos fundamentais.

Após o término do treinamento

• Observe o output_path configurado em seu trabalho de treinamento

• Faça o output.tar.gz download desse local

• Extraia e localize manifest.json

• Copie o checkpoint_s3_bucket valor

Etapa 2: treinamento de RFT no posto de controle do SFT

Crie um novo trabalho de treinamento de RFT usando o ponto de verificação do SFT:

run:  
  name: "rft-on-sft-checkpoint"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<initial-sft-training>"  
  data_s3_path: s3://<bucket>/rft-training-data.jsonl  
  reward_lambda_arn: <your-reward-function-arn>

Justificativa: o treinamento de RFT se baseia na base do SFT, permitindo que o modelo desenvolva padrões de raciocínio mais complexos, otimizados por sua função de recompensa.

Etapa 3: avaliar e iterar

Execute a avaliação no ponto de verificação da RFT para avaliar o desempenho:

run:  
  name: "evaluate-rft-checkpoint"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<rft-on-sft-checkpoint>"  
  data_s3_path: s3://<bucket>/evaluation-data.jsonl

Se as métricas-alvo não forem satisfeitas, continue iterando com dados ou hiperparâmetros ajustados.

Importante

A técnica de treinamento (LoRa versus Full Rank) deve permanecer consistente em todas as iterações:

• Se você usa SFT com LoRa, você deve usar RFT com LoRa

• Se você usa SFT com Full Rank, você deve usar RFT com Full Rank

• Você não pode alternar entre LoRa e Full Rank no meio do pipeline

Importante

Se uma chave KMS for usada para criptografia no bucket S3 de saída de propriedade da Amazon, essa mesma chave KMS deverá ser usada para todas as iterações futuras.

Monitorando o progresso em todas as iterações

Você pode acompanhar as métricas via MLFlow.

Crie um MLflow aplicativo

Usando a interface do usuário do Studio: se você criar um trabalho de treinamento por meio da interface do usuário do Studio, um MLflow aplicativo padrão será criado automaticamente e selecionado por padrão em Opções avançadas.

Usando a CLI: se você usa a CLI, precisa criar um MLflow aplicativo e passá-lo como entrada para a solicitação da API do trabalho de treinamento.

mlflow_app_name="<enter your MLflow app name>"  
role_arn="<enter your role ARN>"   
bucket_name="<enter your bucket name>"   
region="<enter your region>"  
  
mlflow_app_arn=$(aws sagemaker create-mlflow-app \  
  --name $mlflow_app_name \  
  --artifact-store-uri "s3://$bucket_name" \  
  --role-arn $role_arn \  
  --region $region)

Acesse o MLflow aplicativo

Usando a CLI: crie uma URL pré-assinada para acessar a interface do usuário do MLflow aplicativo:

aws sagemaker create-presigned-mlflow-app-url \  
  --arn $mlflow_app_arn \  
  --region $region \  
  --output text

Usando a interface do usuário do Studio: a interface do usuário do Studio exibe as principais métricas armazenadas MLflow e fornece um link para a interface do usuário do MLflow aplicativo.

Principais métricas a serem monitoradas

Monitore essas métricas em todas as iterações para avaliar a melhoria e acompanhar o progresso do trabalho:

Para SFT

• Curvas de perda de treinamento

• Número de amostras consumidas e tempo para processar amostras

• Precisão de desempenho em conjuntos de teste retidos

• Conformidade de formato (por exemplo, taxa de saída JSON válida)

• Perplexidade nos dados de avaliação específicos do domínio

Para RFT

• Pontuações médias de recompensa em relação ao treinamento

• Distribuição de recompensas (porcentagem de respostas de alta recompensa)

• Tendências de recompensa de validação (observe se há sobreajuste)

• Taxas de sucesso específicas de tarefas (por exemplo, taxa de aprovação de execução de código, precisão de problemas matemáticos)

Geral

• Compare os deltas de desempenho entre as iterações

• Pontuações de avaliação humana em amostras representativas

• Métricas de produção (se implantadas de forma iterativa)

Determinando quando parar

Pare de iterar quando:

• Estágios de desempenho — o treinamento adicional não melhora mais significativamente as métricas-alvo

• A troca de técnica ajuda — Se uma técnica se estabilizar, tente alternar (por exemplo, SFT → RFT → SFT) para ultrapassar os limites de desempenho

• Métricas-alvo alcançadas — Seus critérios de sucesso foram atendidos

• Regressão detectada — Novas iterações degradam o desempenho (consulte os procedimentos de reversão abaixo)

Para obter procedimentos de avaliação detalhados, consulte a seção Avaliação.

Práticas recomendadas

Comece pequeno e expanda gradualmente

Comece com conjuntos de dados mínimos e períodos de treinamento únicos para validar sua abordagem antes de aumentar a escala. Isso aumenta a confiança e ajuda a identificar problemas precocemente.

Estabeleça métricas claras de sucesso

Defina indicadores quantitativos e qualitativos antes de começar:

Exemplo de métricas de sucesso por caso de uso

• Resposta à pergunta — Precisão exata da partida, pontuação na F1, classificações de preferência humana

• Geração de código — taxa de aprovação no teste unitário, sucesso da compilação, tempo de execução

• Tarefas de raciocínio — precisão das etapas, exatidão da resposta final, pontuações de recompensa

• Geração de conteúdo — pontuações de coerência, precisão factual, aderência ao estilo

Implemente a avaliação automatizada

Configure canais de avaliação automatizados para monitorar o desempenho após cada rodada, permitindo uma rápida iteração e comparação objetiva.

Mantenha um controle de versão rigoroso

Documento para cada iteração:

• Versões e modificações do conjunto de dados

• Localizações dos pontos de verificação do modelo

• Alterações de hiperparâmetros

• Métricas e deltas de desempenho

• Observações qualitativas

Isso cria conhecimento institucional e permite a depuração.

Concentre-se na qualidade dos dados em vez da quantidade

Analise casos de falha de rodadas anteriores e adicione exemplos direcionados e de alta qualidade em vez de simplesmente aumentar o tamanho do conjunto de dados.

Planeje o orçamento de iteração

Planeje de 3 a 5 iterações como um intervalo típico:

• 1-2 iterações — geralmente suficientes para melhorias simples ou polimento final

• 3-5 iterações — Adequado para tarefas complexas que exigem vários ciclos de refinamento

• Mais de 5 iterações — Pode indicar retornos decrescentes ou necessidade de abordagens diferentes

Ajuste com base no orçamento computacional e nas taxas de melhoria de desempenho.

Implemente recursos de reversão

Se uma iteração introduzir regressões:

• Identifique a regressão — Compare as métricas de avaliação em todos os pontos de verificação

• Retornar ao ponto de verificação anterior — Use o caminho S3 do ponto de verificação anterior como seu model_name_or_path

• Ajuste a abordagem de treinamento — modifique dados, hiperparâmetros ou técnicas antes de tentar novamente

• Documente a falha — registre o que causou a regressão para evitar a repetição

Exemplo de reversão

run:  
  name: "rollback-to-iteration-2"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  # Use iteration 2 checkpoint instead of failed iteration 3  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<iteration-2-job-name>"

Considerações sobre custos

Armazenamento no ponto de verificação

• Localização — Os pontos de verificação armazenados em depósitos de garantia incorrem em cobranças de armazenamento S3 padrão cobradas em sua conta AWS

• Retenção — os pontos de verificação são retidos indefinidamente, a menos que sejam explicitamente excluídos

• Gerenciamento — implemente políticas de ciclo de vida para arquivar ou excluir pontos de verificação antigos que você não precisa mais

Dicas de otimização de custos

• Exclua os pontos de verificação intermediários após validar as iterações mais recentes

• Arquive pontos de verificação no S3 Glacier para retenção de longo prazo a um custo menor

• Defina políticas de retenção com base em suas necessidades de conformidade e experimentação

Limitações

Consistência da família de modelos

Ao treinar iterativamente, você deve usar o mesmo tipo de modelo em todas as iterações.

Treinamento inicial

run:  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "nova-lite-2/prod"

As iterações subsequentes devem usar o mesmo model_type

run:  
  model_type: amazon.nova-2-lite-v1:0:256k  # Must match original  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<job-name>"

Consistência da técnica de treinamento

A técnica de treinamento deve permanecer consistente em todas as iterações:

• Modelos treinados pelo LoRa só podem ser treinados iterativamente com o LoRa

• Full-Rank-trained os modelos só podem ser treinados iterativamente com o Full-Rank

Como os adaptadores LoRa funcionam no treinamento iterativo

• Cada iteração de treinamento LoRa produz novos pesos de adaptador

• Os novos adaptadores substituem (não se empilham) com os adaptadores anteriores

• O modelo básico permanece congelado; somente os adaptadores são atualizados

Matriz de compatibilidade técnica

Treinamento inicial	Pode iterar com
SFT (classificação completa)	SFT (classificação completa), RFT (classificação completa)
SFT (LoRa)	SFT (LoRa), RFT (LoRa)
RFT (classificação completa)	RFT (classificação completa)
RFT (LoRa)	RFT (LoRa)

Verificando a compatibilidade antes de iniciar um trabalho

• Verifique sua receita de treinamento anterior para identificar o tipo de modelo e a técnica de treinamento (LoRa vs. Full-Rank)

• Certifique-se de que sua nova receita corresponda ao tipo de modelo e à técnica

• Revise o manifest.json para confirmar se o caminho do ponto de verificação está correto

Solução de problemas

Erro: “Técnicas de treinamento de modelos incompatíveis detectadas”

Causa: A técnica de treinamento (LoRa vs. Full-Rank) não corresponde à técnica do checkpoint.

Resolução: certifique-se de que sua receita use a mesma técnica de treinamento do modelo original:

• Se o ponto de verificação foi treinado com LoRa, use LoRa em sua nova receita

• Se o checkpoint foi treinado com Full-Rank, use Full-Rank em sua nova receita

Erro: “O modelo base para o trabalho extraído do model_name_or_path não corresponde ao model_type”

Causa: O tipo de modelo especificado em model_type não corresponde ao modelo real no ponto de verificação.

Resolução: verifique se:

• O model_type em sua receita corresponde ao tipo de modelo original

• O caminho do ponto de verificação S3 está model_name_or_path correto

• Você está usando o caminho do arquivo manifest.json correto

Exemplo de configuração correta

run:  
  model_type: amazon.nova-2-lite-v1:0:256k  # Must match checkpoint's model  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<job-name>"

Erro: “Configuração do modelo não encontrada”

Causa: O caminho de entrada do S3 é inválido ou model_name_or_path está inacessível.

Resolução:

• Verifique se o caminho do S3 foi copiado corretamente do arquivo manifest.json

• Certifique-se de que sua função do IAM tenha permissões para acessar o depósito de garantia

• Confirme se o trabalho de treinamento anterior foi concluído com sucesso

• Verifique se há erros de digitação no caminho

Regressão de desempenho após iteração

Sintomas: As métricas de avaliação diminuem após uma nova iteração de treinamento.

Resolução:

• Reversão — Use o ponto de verificação anterior como seu modelo base

• Analisar — Revise os registros de treinamento e a qualidade dos dados da iteração que falhou

• Ajustar — Modifique hiperparâmetros (reduza a taxa de aprendizado), melhore a qualidade dos dados ou reduza os períodos de treinamento

• Tentar novamente — Inicie uma nova iteração com ajustes