O problema com catálogos de produtos em escala
Quem trabalha com e-commerce ou gestão de catálogos sabe bem o desafio: os dados raramente chegam limpos e estruturados. Nomes de produtos, descrições e caminhos de categoria vêm de fontes variadas, mudam constantemente e precisam de tags consistentes para que busca, recomendação e navegação funcionem bem. Aplicar essas tags manualmente em milhares de unidades de estoque (SKUs) é lento, caro e propenso a inconsistências.
Uma alternativa comum é usar um modelo de linguagem de propósito geral com engenharia de prompts. Mas para um fluxo de tagging de alto volume, o objetivo é bem mais restrito: retornar os atributos corretos no esquema correto, de forma consistente. Quando a taxonomia é estável e o resultado pode ser avaliado programaticamente, customizar um modelo menor e especializado costuma ser uma escolha mais adequada — e mais econômica — do que pagar pelas capacidades amplas de um modelo de fronteira em cada requisição.
Foi exatamente esse raciocínio que a AWS explorou em um guia técnico recente, mostrando como especializar o modelo Qwen3-8B para tagging de produtos usando o Amazon SageMaker com customização serverless de modelos. O fluxo combina Ajuste Fino Supervisionado (SFT) com Aprendizado por Reforço com Recompensas Verificáveis (RLVR) via Otimização de Política Relativa de Grupo (GRPO).
Serverless vs. SageMaker Training Jobs tradicionais
Antes de entrar no passo a passo, vale entender uma distinção importante. Existem exemplos anteriores do Qwen3-8B no repositório de exemplos do SageMaker que utilizam o Amazon SageMaker Training Jobs (SMTJ), com instâncias de GPU selecionadas pelo cliente e imagens de treinamento customizadas.
O guia em questão usa uma abordagem diferente: o Amazon SageMaker Python SDK v3 com os trainers serverless (SFTTrainer e RLVRTrainer). Quando nenhuma configuração de computação é fornecida, o próprio SageMaker seleciona e libera a capacidade de treinamento — sem que o time precise gerenciar instâncias ou containers de treinamento. Para os notebooks oficiais, a AWS disponibiliza os exemplos de customização serverless do Amazon SageMaker Python SDK v3.
Pré-requisitos e referências úteis
Para reproduzir o fluxo, é necessário ter em mãos:
- Permissões no Amazon SageMaker AI para gerenciar jobs de customização serverless, datasets e avaliadores no AI Registry, grupos de pacotes de modelo, endpoints e inferência assíncrona
- Acesso de leitura e escrita no Amazon Simple Storage Service (Amazon S3) para catálogo-fonte, dados de treinamento transformados, artefatos de modelo e entradas/saídas de inferência assíncrona
- Acesso ao Amazon Elastic Container Registry (Amazon ECR), necessário apenas se você construir e hospedar a imagem de inferência vLLM — o treinamento serverless não exige imagem customizada
- Disponibilidade da customização serverless na região AWS escolhida para Qwen3-8B com SFT e RLVR
- Cota de endpoint suficiente para
ml.g6.2xlarge - Python 3.11+, AWS CLI v2, pandas, Amazon SageMaker Python SDK v3 e Docker (apenas para a imagem vLLM)
- Credenciais via AWS IAM Identity Center ou outro fluxo de credenciais de curta duração — evite credenciais root e chaves de acesso de longa duração
Referências úteis: modelos open-weight suportados e tipos de customização, Amazon SageMaker Processing e Amazon SageMaker Asynchronous Inference.
Visão geral do fluxo
O fluxo é dividido em três etapas bem separadas: preparação dos dados, customização serverless do modelo e inferência. O treinamento é serverless; a serving usa um endpoint provisionado. Em resumo:
- Os dados são transformados uma vez em ativos versionados
- O SFT ensina ao modelo o esquema de tagging
- O RLVR otimiza o comportamento com base em uma recompensa determinística
- O modelo final é hospedado para inferência assíncrona
Passo 1: Preparação dos dados para SFT
O ponto de partida é o Amazon Sales Dataset no Kaggle, com mais de 1.000 registros de produtos. Os campos utilizados são nome do produto, caminho de categoria e descrição. Em produção, o recomendado é usar o catálogo próprio da empresa com labels validadas.
A transformação é executada como um Amazon SageMaker Processing job, garantindo que a preparação dos dados seja reproduzível e auditável. O script de processamento lê o arquivo-fonte do S3, normaliza textos e caminhos de categoria, remove linhas inutilizáveis, mapeia as informações para um esquema de tagging de nove categorias, divide os dados em treino e validação, e grava arquivos JSONL de volta no S3.
Esses arquivos são registrados como datasets versionados no Amazon SageMaker AI Registry. Cada linha do JSONL de SFT contém um array messages:
{"messages": [
{"role": "system", "content": "Use the nine-category schema."},
{"role": "user", "content": "Name: USB-C Cable | Category: Cables"},
{"role": "assistant", "content": "1, Product Name: USB-C Cable\n...\n9, Occasion:"}
]}Os turnos de sistema e usuário formam o prompt; o turno final do assistente é o alvo supervisionado. O trainer consome o ARN do dataset versionado em vez de um canal de entrada convencional:
from sagemaker.ai_registry.dataset import DataSet, CustomizationTechnique
train_dataset = DataSet.create(
name="amazon-sft-train",
source="s3://amzn-s3-demo-bucket/sft/train.jsonl",
customization_technique=CustomizationTechnique.SFT,
wait=True,
)
TRAINING_DATASET_ARN = train_dataset.arnPasso 2: Ensinando o esquema ao Qwen3-8B com SFT serverless
O SFTTrainer do SDK v3 submete o job de customização. Ele resolve a receita suportada para o Qwen3-8B, aplica Adaptação de Baixo Posto (LoRA), consome os ARNs dos datasets registrados e publica o resultado em um grupo de pacotes de modelo. Como nenhum argumento de computação é fornecido, o SageMaker usa capacidade de treinamento serverless gerenciada pela AWS:
from sagemaker.train.common import TrainingType
from sagemaker.train.sft_trainer import SFTTrainer
trainer = SFTTrainer(
model="huggingface-reasoning-qwen3-8b",
training_type=TrainingType.LORA,
model_package_group=model_package_group,
training_dataset=TRAINING_DATASET_ARN,
validation_dataset=VALIDATION_DATASET_ARN,
sequence_length="4K",
s3_output_path=S3_OUTPUT_PATH,
role=ROLE_ARN,
# No compute argument: use serverless model customization.
)
trainer.hyperparameters.max_epochs = 3
trainer.hyperparameters.global_batch_size = 8
trainer.hyperparameters.lora_rank = 16
trainer.hyperparameters.merge_weights = True
training_job = trainer.train(wait=True)
SFT_MODEL_PACKAGE_ARN = training_job.output_model_package_arnO SFT é a etapa que gera o maior salto na aderência ao esquema, pois demonstra diretamente o comportamento de entrada/saída desejado. A próxima etapa usa RLVR para refinar os trade-offs de qualidade — não para reaprender o formato do zero.
Passo 3: Convertendo exemplos supervisionados em dados para RLVR
Após o SFT, o modelo já segue o esquema, mas ainda pode deixar de capturar atributos esperados ou incluir atributos desnecessários. O RLVR é adequado aqui porque a saída de tagging é estruturada e pode ser comparada a uma referência sem precisar de outro LLM como juiz.
Para cada linha de SFT, os turnos de sistema e usuário vão para prompt, e o conteúdo final do assistente vai para reward_model.ground_truth:
messages = json.loads(line)["messages"]
rlvr_row = {
"id": f"amazon-tagging-{split}-{index:05d}",
"prompt": messages[:-1],
"data_source": "amazon_tagging",
"reward_model": {
"style": "rule",
"ground_truth": messages[-1]["content"],
},
"extra_info": {
"answer": messages[-1]["content"],
"split": split,
},
}Passo 4: Otimizando com RLVR e GRPO serverless
O RLVR parte do pacote de modelo gerado pelo SFT e usa uma função de recompensa determinística para avaliar conjuntos de tags candidatas. O GRPO gera um grupo de completions para cada prompt — neste caso, oito candidatos com rollout_n=8. O avaliador pontua cada completion de forma independente, o GRPO calcula as vantagens relativas do grupo, e a regularização KL limita o desvio em relação ao modelo de referência SFT:
from sagemaker.train.rlvr_trainer import RLVRTrainer
training_dataset = DataSet.get(
name="amazon-rlvr-train",
sagemaker_session=sagemaker_session,
)
validation_dataset = DataSet.get(
name="amazon-rlvr-eval",
sagemaker_session=sagemaker_session,
)
trainer = RLVRTrainer(
model=SFT_MODEL_PACKAGE_ARN,
training_type=TrainingType.LORA,
model_package_group=rlvr_model_package_group,
custom_reward_function=REWARD_EVALUATOR_ARN,
training_dataset=training_dataset,
validation_dataset=validation_dataset,
s3_output_path=S3_OUTPUT_PATH,
role=ROLE_ARN,
# No compute argument: use serverless model customization.
)
trainer.hyperparameters.rollout_n = 8
trainer.hyperparameters.global_batch_size = 128
trainer.hyperparameters.max_epochs = 4
trainer.hyperparameters.learning_rate = 1e-5
trainer.hyperparameters.max_prompt_length = 2048
training_job = trainer.train(wait=False)Design da função de recompensa
A recompensa é determinística: verifica o formato de saída das nove categorias e usa correspondência fuzzy com limiar de 0,5 para comparar as tags previstas com a referência. Isso torna o sinal de treinamento verificável sem precisar de um modelo juiz separado:
Overall = 0,30 × recall + 0,30 × precision + 0,30 × accuracy + 0,05 × match_quality + 0,05 × formatting
O cronograma progressivo de recompensa muda a ênfase ao longo do treinamento: nas iterações iniciais, o recall é favorecido para que o modelo aprenda a não perder atributos esperados; nas iterações posteriores, a precisão aumenta para que ele aprenda a evitar tags desnecessárias. Isso torna o trade-off de negócio explícito na recompensa, em vez de deixá-lo implícito no prompt.
Passo 5: Deploy para inferência assíncrona
Treinamento e inferência usam infraestruturas diferentes neste fluxo. O SFT e o RLVR usam a customização serverless do SageMaker. A serving usa um endpoint de Inferência Assíncrona do Amazon SageMaker em ml.g6.2xlarge — adequado para enriquecimento de catálogo em lote, onde as requisições podem ser enfileiradas e os resultados gravados no S3:
sm_client.create_endpoint_config(
EndpointConfigName=endpoint_config_name,
ProductionVariants=[{
"VariantName": "AllTraffic",
"ModelName": model_name,
"InitialInstanceCount": 1,
"InstanceType": "ml.g6.2xlarge",
}],
AsyncInferenceConfig={
"OutputConfig": {
"S3OutputPath": "s3://amzn-s3-demo-bucket/async-output"
}
},
)Para produção, a AWS recomenda adicionar uma política de autoescalonamento se o endpoint assíncrono precisar escalar com a profundidade da fila ou reduzir quando ocioso.
Passo 6: Invocação e avaliação da qualidade de tagging
As requisições são enviadas ao endpoint assíncrono em formato compatível com OpenAI. Para payloads maiores, o corpo da requisição é carregado no S3 e o URI é passado como InputLocation; o resultado é lido a partir do OutputLocation retornado. O guia usa temperature=0.1 e max_tokens=1024 para geração estável:
response = sagemaker_runtime.invoke_endpoint_async(
EndpointName=ENDPOINT_NAME,
ContentType="application/json",
InputLocation=input_location,
)
output_location = response["OutputLocation"]Resultados: o que cada etapa contribui
Os resultados mostram que o SFT é o principal motor de qualidade, enquanto o GRPO faz um ajuste mais fino que favorece cobertura. A tabela abaixo resume os efeitos separados:
- Baseline: Overall 0,354 | Recall 0,327 | Precision 0,397 | Accuracy 0,327
- SFT: Overall 0,6827 | Recall 0,6689 | Precision 0,652 | Accuracy 0,6689
- GRPO: Overall 0,6941 | Recall 0,703 | Precision 0,638 | Accuracy 0,686
O SFT eleva o Overall de 0,354 para 0,6827 — esse é o efeito de ensinar diretamente ao modelo a tarefa e o esquema. O GRPO então faz um trade-off mais estreito: o Overall sobe de 0,6827 para 0,6941 e o recall de 0,6689 para 0,703, enquanto a precisão cai levemente de 0,652 para 0,638.
Para um time de catálogo, isso significa que o GRPO é útil quando perder atributos válidos é mais custoso do que produzir algumas tags extras. Se tags desnecessárias forem mais prejudiciais downstream, os pesos de recompensa podem ser ajustados para favorecer a precisão.
Vale destacar: essas métricas medem qualidade de tagging, não conversão de negócio diretamente. Use-as como sinais de seleção de modelo e valide o impacto em produção com medidas específicas do catálogo, como completude de atributos, taxa de correção manual, cobertura de busca/filtro e qualidade de recomendação downstream.
Limpeza de recursos
Após validar o fluxo, a AWS orienta excluir apenas os recursos criados para ele: endpoint, configuração de endpoint, modelo, Lambda de recompensa e avaliador, versões de dataset, grupos de pacotes de modelo, prefixos no S3 e a imagem de inferência no ECR. É importante confirmar os nomes dos recursos antes de excluir ativos compartilhados.
Conclusão
Tagging de produtos é um forte candidato à customização de modelos quando o esquema é estável, a carga de trabalho é repetitiva e a correção pode ser avaliada programaticamente. Neste exemplo, o Qwen3-8B aprende o formato de nove categorias via SFT serverless, e o RLVR com GRPO usa uma recompensa verificável para ajustar o equilíbrio entre cobertura e precisão.
O resultado não é que todas as métricas melhoram igualmente — é que o design da recompensa torna o trade-off desejado explícito e mensurável. Um modelo de fronteira ainda é útil quando a tarefa muda com frequência, a taxonomia ainda está evoluindo ou o fluxo precisa de raciocínio mais amplo além de um esquema fixo de tagging. Para uma tarefa madura de alto volume, porém, a customização serverless do SageMaker oferece um caminho gerenciado para especializar um modelo open-weight sem precisar selecionar instâncias de treinamento ou manter containers de treinamento.
Para reproduzir e estender o fluxo, a AWS disponibiliza os exemplos de customização serverless do Amazon SageMaker Python SDK v3 no GitHub, incluindo notebooks de SFT, RLVR, AI Registry e end-to-end. Para os conceitos do serviço e modelos suportados, consulte a documentação de customização de modelos do Amazon SageMaker AI.
Fonte
Build an AI-powered product tagging system with Amazon SageMaker serverless model customization (https://aws.amazon.com/blogs/machine-learning/build-an-ai-powered-product-tagging-system-with-amazon-sagemaker-serverless-model-customization/)
Leave a Reply