Blog

Migrar dashboards de BI sem perder o que foi construído ao longo dos anos

Quem trabalha com ferramentas de Inteligência de Negócios (BI) legadas sabe o valor que está embutido em cada dashboard: campos calculados refinados pelos analistas, layouts que os executivos consultam toda semana, regras de segurança ajustadas à estrutura organizacional. Migrar tudo isso parece assustador — e, até pouco tempo atrás, era mesmo: estimativas de meses de trabalho, risco de perda de lógica analítica e alto custo de engenharia.

A AWS anunciou que o AWS Transform agora automatiza a migração de ferramentas de BI legadas para o Amazon QuickSight, com potencial de reduzir esse processo de meses para dias. A novidade expande o escopo do AWS Transform, que já era usado para modernizar aplicações mainframe, ambientes VMware, cargas de trabalho Windows e SQL Server.

Por que sair das ferramentas de BI legadas?

Além das licenças, manter uma plataforma de BI tradicional gera custos operacionais que consomem tempo e energia da equipe de dados. A AWS aponta três pressões principais que as organizações enfrentam ao persistir em soluções legadas:

• Infraestrutura que desvia o foco: atividades como patching, escalonamento e monitoramento de servidores tomam tempo que poderia ser dedicado à geração de insights. O Amazon QuickSight é serverless e totalmente gerenciado, eliminando o planejamento de capacidade e as janelas de manutenção.
• Ausência de IA nativa: ferramentas tradicionais de BI exigem engenharia customizada para suportar respostas baseadas em Inteligência Artificial (IA). O QuickSight inclui capacidades nativas de IA que permitem às equipes fazer perguntas em linguagem natural e automatizar fluxos de trabalho diretamente dos dashboards.
• Lentidão nas respostas: provisionamento de capacidade, gerenciamento de extrações e troubleshooting de performance criam gargalos. O mecanismo de memória em memória SPICE do QuickSight entrega performance de consultas em frações de segundo, e dashboards podem ser publicados diretamente em aplicações próprias por meio das APIs de análise embarcada.

Para quem quiser explorar o que o Amazon QuickSight oferece antes de iniciar uma migração, a AWS disponibiliza um guia de introdução ao Amazon QuickSight.

Como o AWS Transform viabiliza a migração de BI

O AWS Transform é descrito pela AWS como uma bancada colaborativa de transformação de TI empresarial, impulsionada por agentes especializados, sistemas de IA agêntica e aprendizado contínuo. Para a migração de BI, a AWS firmou parceria com a Wavicle Data Solutions, parceira avançada de consultoria AWS, que integrou seus agentes EZConvertBI diretamente na plataforma.

A Wavicle disponibiliza quatro agentes especializados para compra no AWS Marketplace: um agente Analisador e um agente Conversor para cada ferramenta de origem — Power BI e Tableau. Juntos, esses agentes entregam uma experiência de migração guiada, baseada em chat, inteiramente dentro do ambiente AWS do cliente.

Um ponto importante: nenhum dado sai do ambiente do cliente. Não há ferramentas externas para contratar nem transferências de dados para aprovar com equipes de segurança ou procurement. Isso remove boa parte da fricção que costuma atrasar projetos de migração.

O processo em dois passos: Analisar e Converter

Independentemente da ferramenta de origem — Power BI ou Tableau —, o processo de migração segue a mesma lógica em duas etapas:

Passo 1: Análise (Analyze)

O agente Analisador se conecta ao ambiente de BI existente e extrai apenas metadados — sem tocar nos dados em si. Ele cataloga dashboards, conjuntos de dados, cálculos e dependências entre workspaces, e gera um relatório de prontidão para migração. Esse relatório inclui um mapa de compatibilidade que mostra o que será convertido de forma limpa e o que pode exigir atenção manual. Isso permite que os gestores do projeto de migração definam um plano de execução baseado em prioridade e utilidade dos dashboards, antes mesmo de comprometer recursos adicionais.

Passo 2: Conversão (Convert)

Com o escopo definido, o agente Conversor reconstrói os ativos selecionados diretamente no Amazon QuickSight. Isso inclui:

• Conjuntos de dados com fontes de dados e tipos mapeados
• Campos calculados, tanto no nível do conjunto de dados quanto no nível da análise
• Visualizações e gráficos com tipos e formatação preservados
• Filtros e controles de parâmetros

O objetivo é preservar a lógica analítica que as equipes levaram anos desenvolvendo na ferramenta de origem. O progresso pode ser acompanhado diretamente na interface de chat do AWS Transform, e ao final da conversão os ativos já estão disponíveis no QuickSight para validação e entrada em produção.

Arquitetura: os serviços AWS envolvidos

A solução é construída sobre serviços nativos da AWS:

• AWS Transform: fornece a camada de orquestração com interface conversacional, permitindo criar e gerenciar jobs de migração por chat, acompanhar progresso entre workspaces e coordenar equipes. Como o AWS Transform executa tarefas em paralelo, é possível converter centenas de dashboards simultaneamente sem abrir mão de qualidade ou controle.
• Amazon Bedrock AgentCore: atua como ambiente de execução seguro para os agentes, gerenciando credenciais por meio de identidades de carga de trabalho e controle de acesso baseado em Gerenciamento de Identidade e Acesso (IAM — Identity and Access Management).
• Amazon QuickSight: é o serviço de BI de destino, com escalabilidade serverless, performance do mecanismo SPICE e integração nativa com os serviços de dados da AWS.
• Amazon Simple Storage Service (Amazon S3): armazena relatórios de validação e artefatos de migração para fins de auditoria e revisão.

Passo a passo completo da jornada de migração

Pré-requisitos na ferramenta de origem

Antes de executar a primeira migração, é necessário preparar a ferramenta de BI de origem para que o agente consiga ler os metadados dos dashboards:

• Power BI: configure o acesso ao workspace e a autenticação via service principal para que o agente possa ler os metadados do tenant do Power BI. As instruções estão nos pré-requisitos para Power BI.
• Tableau: habilite a Metadata API no Tableau Server e gere um Token de Acesso Pessoal (PAT — Personal Access Token) para acesso autenticado à API. As instruções estão nos pré-requisitos para Tableau.

Configuração do AWS Transform e assinatura no AWS Marketplace

O AWS Transform fornece a camada de orquestração para toda a migração. Ele implanta os agentes de IA especializados que automatizam avaliações, mapeamento de dependências e planejamento da transformação. Toda a equipe trabalha no mesmo workspace compartilhado, colaborando em tempo real e gerenciando a migração do início ao fim. É possível acompanhar um demo interativo do processo de configuração.

Análise dos dashboards de BI

O relatório de análise captura a complexidade dos dashboards em várias dimensões: número de fontes de dados, cálculos analíticos, nuances de consumo como regras condicionais e dependências entre dashboards. Demos interativos estão disponíveis tanto para o agente Analisador de Power BI quanto para o agente Analisador de Tableau.

Conversão dos dashboards de BI

O agente Conversor reconstrói os dashboards selecionados no Amazon QuickSight, preservando conjuntos de dados, campos calculados, visualizações, filtros e parâmetros. Demos interativos estão disponíveis para o agente Conversor de Power BI e para o agente Conversor de Tableau.

Após a migração: de convertido a pronto para produção

O agente de migração entrega os ativos convertidos — datasets e análises do QuickSight com campos calculados, visuais, controles e parâmetros. O que vem depois — governança, validação e publicação — fica sob responsabilidade da equipe do cliente. Essa divisão deliberada de responsabilidades garante qualidade e clareza de accountability.

Vale destacar que o relatório de avaliação sinaliza componentes que podem precisar de refinamento manual após a migração, como parâmetros, SQL customizado, cálculos específicos da ferramenta de origem e visuais de terceiros. Não há surpresas nessa etapa.

Para administradores do QuickSight

O administrador do QuickSight precisa atribuir a propriedade de cada dashboard migrado aos autores de BI adequados. Um ponto de atenção importante: as estruturas de autenticação e diretórios da ferramenta de origem raramente mapeiam diretamente para o Amazon QuickSight. Por exemplo, ambientes Tableau frequentemente dependem de grupos do Active Directory, enquanto o Power BI usa service principals no nível do workspace. O agente de migração transfere os ativos analíticos, mas não os controles de acesso. Permissões de usuário, segurança em nível de linha (RLS — Row-Level Security) e configurações de compartilhamento precisam ser configuradas manualmente no QuickSight para atender aos requisitos da organização. Para empresas com hierarquias de diretório complexas, esse passo deve ser tratado como uma frente de trabalho separada.

Para autores de BI

Os autores de BI recebem os dashboards atribuídos e são responsáveis pelo Teste de Aceitação do Usuário (UAT — User Acceptance Testing). Isso inclui verificar visualizações, campos calculados, filtros e interatividade em comparação com a fonte original, testar drill-downs e ações dos dashboards, e confirmar a consistência do layout. Como o agente de migração não transfere permissões nem segurança em nível de linha, também é recomendável verificar se os usuários certos têm acesso aos dados certos no QuickSight.

Publicação e entrada em produção

Após a validação, os autores de BI publicam seus dashboards, configurando permissões de compartilhamento, assinaturas de e-mail e embedding quando necessário. Para migrações de grande escala, as APIs de implantação de ativos do Amazon QuickSight permitem automatizar a atribuição de permissões e a distribuição de dashboards. A partir desse ponto, os dashboards originais na ferramenta legada podem ser arquivados.

Com os dashboards ativos no Amazon QuickSight, as equipes passam a ter acesso a capacidades que não eram possíveis na ferramenta legada: consultas em linguagem natural, análise automatizada sobre fontes de dados corporativos e ações orientadas a dados diretamente dos dashboards.

Como começar

Para explorar a solução, a AWS recomenda os seguintes passos:

• Explorar os agentes disponíveis no AWS Marketplace: agentes Power BI para QuickSight e agentes Tableau para QuickSight.
• Acessar o guia do usuário e demos interativos no site da Wavicle Data Solutions.
• Entrar em contato com o time de conta AWS para discutir os requisitos de migração e explorar programas disponíveis para migrações gratuitas ou com desconto para o Amazon QuickSight.

Seja para migrar 10 ou 10.000 dashboards, o AWS Transform oferece um caminho governado e repetível para o Amazon QuickSight — combinando as capacidades de IA do Amazon Bedrock com a expertise de migração de BI da Wavicle.

Fonte

AWS Transform now automates BI migration to Amazon Quick in days (https://aws.amazon.com/blogs/machine-learning/aws-transform-now-automates-bi-migration-to-amazon-quick-in-days/)

AgentCore chega à região de São Paulo

A AWS anunciou a disponibilidade do Amazon Bedrock AgentCore na região South America (São Paulo). Trata-se de uma plataforma voltada para construir, conectar e otimizar agentes de inteligência artificial, e sua chegada ao Brasil representa um passo importante para equipes de engenharia que desenvolvem soluções baseadas em agentes na América do Sul.

O que é o Amazon Bedrock AgentCore?

O AgentCore é a plataforma da AWS para quem quer colocar agentes de IA em produção com agilidade. Ele foi projetado para que engenheiros consigam:

• Desenvolver e entregar agentes rapidamente, com suporte a qualquer framework e qualquer modelo;
• Conectar esses agentes a sistemas e ferramentas corporativas;
• Otimizá-los de forma contínua ao longo do tempo.

Um ponto de destaque é a abordagem de segurança da plataforma: as políticas de segurança são aplicadas na camada de infraestrutura, o que significa que os próprios agentes não conseguem contorná-las. Isso reduz riscos operacionais e facilita a governança em ambientes empresariais.

O que está disponível na região de São Paulo

Desde o lançamento na região, todas as principais capacidades do AgentCore já estão acessíveis. São elas:

• Agent Runtime — ambiente de execução dos agentes;
• Identity — gerenciamento de identidade para agentes;
• Gateway — integração com sistemas externos;
• Policy — aplicação de políticas de acesso e comportamento;
• Observability — monitoramento e rastreabilidade das execuções;
• Code Interpreter — interpretação e execução de código pelos agentes;
• Browser Tools — ferramentas de navegação web para os agentes.

Por que isso importa para o mercado brasileiro?

Com a chegada do AgentCore à região de São Paulo, clientes na América do Sul passam a poder implantar e operar agentes mais próximos dos seus usuários finais. Os benefícios diretos são a redução de latência nas interações e a capacidade de atender requisitos de residência de dados — um ponto cada vez mais relevante para empresas sujeitas a regulações como a LGPD.

Saiba mais

Para quem quer se aprofundar no AgentCore, a AWS disponibiliza recursos completos de documentação e referência:

• Página do produto AgentCore — visão geral da plataforma;
• Guia do desenvolvedor do AgentCore — documentação técnica detalhada;
• Preços do AgentCore — informações sobre custos;
• Regiões AWS com suporte — disponibilidade por região.

Fonte

Amazon Bedrock AgentCore is now available in the South America (São Paulo) Region (https://aws.amazon.com/about-aws/whats-new/2026/05/agentcore-sao-paulo-region/)

O problema que essa arquitetura resolve

Grandes empresas acumulam petabytes de dados em data lakes e lakehouses, mas transformar esse volume em decisões rápidas ainda é um gargalo. O motivo é simples: acessar esses dados exige especialistas em SQL, modelagem de dados e ferramentas de Business Intelligence (BI). Quem está no negócio — analistas, gestores, times de operação — fica dependente da fila técnica para obter respostas.

A AWS publicou uma arquitetura de referência que endereça exatamente esse problema. A proposta combina Amazon SageMaker, Amazon Athena e Amazon Quick para criar um assistente de IA agêntica capaz de responder perguntas sobre dados complexos usando linguagem natural — sem que o usuário precise escrever uma linha de SQL.

Visão geral da arquitetura

A solução foi construída usando o dataset de benchmark TPC-H como base de dados. A escolha é estratégica: o TPC-H representa um modelo de negócio realista com pedidos, clientes e itens de linha, tornando os exemplos reproduzíveis e significativos.

Os principais componentes da arquitetura são:

• Amazon Simple Storage Service (S3) como camada de armazenamento principal
• Amazon SageMaker e AWS Glue para a estrutura do lakehouse e catálogo de metadados
• Amazon Athena para consultas SQL serverless em múltiplos formatos de armazenamento
• Amazon Quick para dashboards, agentes de IA conversacional e bases de conhecimento

O fluxo funciona da seguinte forma: os dados TPC-H são ingeridos e armazenados no S3 em três formatos distintos. O Athena executa consultas sobre esses dados usando o catálogo do AWS Glue como camada de metadados unificada. O Amazon Quick se conecta ao Athena para carregar os dados no SPICE (Motor de Cálculo Super-rápido, Paralelo e em Memória), onde alimenta dashboards interativos e agentes de chat com IA. Em paralelo, um Web Crawler indexa documentação não estruturada do TPC-H em uma Knowledge Base (Base de Conhecimento), que também é disponibilizada ao agente conversacional.

Três formatos de armazenamento no mesmo lakehouse

Um dos pontos mais instrutivos da arquitetura é a demonstração de três abordagens diferentes de armazenamento, todas consultáveis pelo mesmo Athena:

Tabela externa CSV

Utiliza o dataset de clientes do TPC-H diretamente de um bucket público do S3. Com tabelas externas, o Athena consulta os dados no local original sem movê-los — uma abordagem rápida e econômica para explorar dados brutos. O comando de criação no editor de queries do Athena é:

CREATE EXTERNAL TABLE IF NOT EXISTS blog_qs_athena_tpc_h_db_sql.customer_csv (
  C_CUSTKEY INT,
  C_NAME STRING,
  C_ADDRESS STRING,
  C_NATIONKEY INT,
  C_PHONE STRING,
  C_ACCTBAL DOUBLE,
  C_MKTSEGMENT STRING,
  C_COMMENT STRING
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '|'
STORED AS TEXTFILE
LOCATION 's3://redshift-downloads/TPC-H/2.18/100GB/customer/'
TBLPROPERTIES ('classification' = 'csv');

Tabela Apache Iceberg (Parquet)

O Apache Iceberg é um formato de tabela aberto que traz transações ACID, time travel e evolução de partições para o data lake — ideal para cargas de trabalho em produção. A arquitetura cria uma tabela Iceberg a partir dos dados de pedidos usando o comando CREATE TABLE AS SELECT (CTAS), particionada por data de pedido:

CREATE TABLE blog_qs_athena_tpc_h_db_sql.orders_iceberg
WITH (
  table_type = 'ICEBERG',
  format = 'PARQUET',
  is_external = false,
  partitioning = ARRAY['o_orderdate'],
  location = 's3://amzn-s3-demo-bucket/tpch_iceberg/orders/')
AS SELECT *
FROM blog_qs_athena_tpc_h_db_sql.orders_csv
WHERE O_ORDERDATE BETWEEN '1998-06-01' AND '1998-12-31';

Amazon S3 Tables

As Amazon S3 Tables são tabelas totalmente gerenciadas com suporte nativo ao Apache Iceberg. Elas eliminam a necessidade de gerenciar operações de manutenção como compactação e remoção de arquivos não referenciados. A criação também usa CTAS, desta vez apontando para o catálogo s3tablescatalog:

CREATE TABLE lineitem_csv_s3_table
WITH (
  format = 'PARQUET')
AS SELECT *
FROM AwsDataCatalog.blog_qs_athena_tpc_h_db_sql.lineitem_csv
WHERE CAST(L_SHIPDATE AS DATE) BETWEEN DATE('1998-06-01') AND DATE('1998-12-31');

Preparação dos dados no Amazon Quick

Com as três tabelas registradas e consultáveis no Athena, o próximo passo é conectá-las ao Amazon Quick. A conexão é feita por meio de uma única fonte de dados Athena — as três tabelas ficam acessíveis porque todas estão catalogadas no AWS Glue Data Catalog e acessíveis pelo mesmo workgroup do Athena.

Cada tabela vira um dataset separado no Quick, importado para o SPICE para garantir performance sub-segundo em dashboards e fluxos agênticos. Um ponto de atenção importante: as S3 Tables ficam em um catálogo AWS Glue não padrão (s3tablescatalog), o que significa que elas não aparecem no navegador visual de tabelas do Quick. Para criar o dataset dessa tabela, é necessário usar SQL customizado:

SELECT * FROM "s3tablescatalog/blog-qs-athena-tpc-h-db-sql-s3-table-mar-3"."blog_qs_athena_tpc_h_namespace"."lineitem_csv_s3_table"

Join entre os três datasets

O esquema TPC-H é um esquema estrela por design. Para unir as três tabelas, a abordagem recomendada é fazer o join diretamente no Athena via SQL customizado e ingerir o resultado unificado no SPICE como um único dataset desnormalizado. Isso delega o processamento ao Athena e elimina restrições de tamanho de tabelas secundárias no Quick:

SELECT
  c.c_custkey, c.c_name, c.c_mktsegment, c.c_nationkey,
  o.o_orderkey, o.o_orderdate, o.o_orderstatus, o.o_totalprice, o.o_orderpriority,
  l.l_linenumber, l.l_partkey, l.l_suppkey, l.l_quantity,
  l.l_extendedprice, l.l_discount, l.l_shipmode, l.l_returnflag
FROM "s3tablescatalog/blog-qs-athena-tpc-h-db-sql-s3-table-mar-3"."blog_qs_athena_tpc_h_namespace"."lineitem_csv_s3_table" l
INNER JOIN "blog_qs_athena_tpc_h_db_sql"."orders_iceberg" o
  ON l.l_orderkey = o.o_orderkey
INNER JOIN "blog_qs_athena_tpc_h_db_sql"."customer_csv" c
  ON o.o_custkey = c.c_custkey;

Camada de BI e IA conversacional

Topic e Dashboard com Amazon Q

Com o dataset unificado no SPICE, a arquitetura configura um Topic no Amazon Quick — a camada semântica que traduz nomes de colunas em conceitos de negócio. Quando um usuário pergunta “Qual foi a receita total no último trimestre por segmento de cliente?”, o Topic mapeia “receita” para l_extendedprice, “último trimestre” para um filtro em o_orderdate e “segmento de cliente” para c_mktsegment. Sem esse mapeamento, as consultas em linguagem natural retornam resultados genéricos ou incorretos.

O dashboard é construído usando o Amazon Q dentro do Quick, que permite criar visualizações a partir de prompts em linguagem natural como “Mostre um KPI de receita total” ou “Crie um gráfico de barras de receita por status de pedido”. Após a publicação, o dashboard embute uma barra de perguntas em linguagem natural para que os usuários façam perguntas adicionais sem sair da tela.

Knowledge Base e agente de chat

Em paralelo ao fluxo estruturado, a arquitetura configura uma Knowledge Base alimentada pela especificação oficial do TPC-H (documento PDF público). Um Web Crawler indexa esse conteúdo não estruturado, tornando-o pesquisável pelo agente de chat.

O agente é configurado dentro de um Space (Espaço) do Amazon Quick — a camada organizacional que agrupa Topic, Knowledge Base e Dashboard em um único contexto governado. A instrução de persona do agente define claramente seu escopo: responder perguntas sobre receita de pedidos, performance de fornecedores, precificação de itens e disponibilidade de inventário, sempre fundamentando as respostas nos dados do lakehouse TPC-H.

Na prática, quando um analista de negócio pergunta “Qual segmento de clientes gerou mais receita no mês passado, e o que significa ‘segmento de mercado’ no esquema TPC-H?”, o agente:

• Consulta o Topic TPC-H Analytics para obter a receita por c_mktsegment filtrada ao último mês
• Simultaneamente recupera a definição de c_mktsegment da Knowledge Base
• Retorna uma resposta unificada: o ranking de receita com citação ao dataset SPICE, seguido da definição do campo com citação ao documento de especificação

Sem SQL. Sem navegação em dashboards. Sem ticket para o time de dados.

Permissões e governança

A arquitetura mantém governança corporativa em toda a cadeia. Se o AWS Lake Formation estiver habilitado, ele atua como a camada central de autorização, sobrescrevendo as permissões IAM padrão do S3. Nesse caso, as permissões precisam ser concedidas diretamente ao autor do Amazon Quick ou à role IAM no console do Lake Formation. Se o Lake Formation não estiver habilitado, as permissões são gerenciadas no nível da service role do Quick via controle de acesso IAM padrão.

Para S3 Tables especificamente, a service role do Quick requer uma política inline adicional glue:GetCatalog para acessar o catálogo não padrão s3tablescatalog. A referência completa está disponível na documentação Visualizando dados de S3 Tables com Amazon Quick.

Limpeza dos recursos

Após os testes, a AWS recomenda remover todos os artefatos criados para evitar custos desnecessários. O processo de limpeza envolve, na ordem:

• Dropar tabelas e banco de dados via console do Athena
• Remover o S3 Table bucket, namespace e tabela via AWS CLI, SDKs ou API REST do S3
• Excluir o bucket S3 via console
• No Amazon Quick: excluir o Chat Agent, o Space, o Dashboard, o Topic, a Knowledge Base, os Datasets e a fonte de dados, nessa ordem

Conclusão

A arquitetura demonstrada pela AWS mostra como é possível transformar um lakehouse complexo — com dados em múltiplos formatos e fontes — em uma interface conversacional acessível para usuários de negócio. A combinação de Amazon Athena para consulta serverless, AWS Glue para catálogo unificado, SPICE para performance em memória e os agentes de IA do Amazon Quick cria uma camada de self-service que mantém governança e escalabilidade corporativa.

Para equipes que buscam democratizar o acesso a dados sem abrir mão de segurança e controle, essa arquitetura de referência oferece um caminho concreto e reproduzível. A documentação de referência inclui tutoriais adicionais para casos de uso em B2B, receita, vendas, marketing e RH, além de guias aprofundados sobre permissões com Lake Formation.

Links úteis para aprofundamento:

• Tutorial de introdução ao Amazon Quick
• Usando AWS Lake Formation com Quick
• Analise seus dados com segurança usando AWS Lake Formation e Amazon QuickSight
• Modernize cargas de trabalho de Business Intelligence com Amazon Quick
• Boas práticas para SPICE e modo de consulta direta no Amazon QuickSight
• Acessando Amazon S3 Tables pelo Amazon Quick com permissões do AWS Lake Formation
• Segurança AWS no Quick

Fonte

Unleashing Agentic AI Analytics on Amazon SageMaker with Amazon Athena and Amazon Quick (https://aws.amazon.com/blogs/machine-learning/unleashing-agentic-ai-analytics-on-amazon-sagemaker-with-amazon-athena-and-amazon-quick/)

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/)