Blog

Entendendo a Personalização de Modelos com Fine-Tuning

Conforme as organizações expandem suas implementações de IA, surge uma necessidade crítica: contar com modelos que reflitam conhecimento proprietário e fluxos de trabalho específicos. Seja mantendo uma voz de marca consistente na comunicação com clientes, processando workflows complexos específicos de indústrias ou classificando intenções em sistemas de reserva com alto volume de transações, o desafio é o mesmo.

Técnicas tradicionais como engenharia de prompts e Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation) fornecem contexto adicional ao modelo, melhorando o desempenho em tarefas, mas não incorporam compreensão nativa ao modelo. A diferença é fundamental: essas abordagens “leem” as instruções a cada execução, em vez de internalizarem o conhecimento.

O Amazon Bedrock oferece três abordagens de personalização para modelos Nova:

• Supervisioned Fine-Tuning (SFT): treina o modelo em exemplos de entrada-saída rotulados
• Reinforcement Fine-Tuning (RFT): utiliza funções de recompensa para guiar o aprendizado em direção a comportamentos alvo
• Model Distillation: transfere conhecimento de um modelo professor maior para um modelo aluno menor e mais rápido

Diferentemente das técnicas de contexto, essas abordagens embutem novo conhecimento diretamente nos pesos do modelo. O resultado prático é triplo: inferência mais rápida, custos menores de tokens e maior precisão nas tarefas relevantes ao negócio.

Quando Aplicar Fine-Tuning e Quando Não Aplicar

Cenários Ideais para Fine-Tuning

Fine-tuning é recomendado quando você possui tarefas de alto volume bem definidas e consegue reunir exemplos rotulados de qualidade ou uma função de recompensa estruturada. Casos de uso típicos incluem renderizar corretamente o logo da empresa no modelo, incorporar tom de marca e políticas corporativas, ou substituir um classificador tradicional de machine learning por um pequeno LLM.

A indústria de atendimento ao cliente demonstra resultados práticos: ao personalizar modelos Nova Micro para suporte especializado, é possível melhorar a precisão em 5,4% em problemas específicos do domínio e 7,3% em questões gerais, reduzindo latência simultaneamente. Pequenos LLMs ajustados como o Nova Micro estão gradualmente substituindo classificadores tradicionais em tarefas de detecção de intenção, combinando a flexibilidade e conhecimento de mundo dos LLMs com a velocidade e eficiência de modelos leves.

Quando Evitar Fine-Tuning

Fine-tuning exige investimento inicial: montagem de dados rotulados, execução de job de treinamento, tempo e custos computacionais. Porém, esse investimento inicial costuma compensar em aplicações de alto volume ao reduzir custos de inferência por requisição e latência.

Capacidades dos Modelos Amazon Nova no Bedrock

O Amazon Bedrock automatiza completamente o provisionamento de infraestrutura, gerenciamento de compute e orquestração de treinamento. Você faz upload dos dados para o Amazon Simple Storage Service (Amazon S3) e inicia o treinamento com uma única chamada de API, sem gerenciar clusters, GPUs ou pipelines de treinamento distribuído.

Os modelos Amazon Nova suportam fine-tuning em diferentes variações. Vários deles possibilitam tanto SFT quanto RFT, conforme documentação específica. Para informações sobre disponibilidade e suporte, consulte a documentação atualizada e o Guia do Usuário Nova.

O Nova 2 Lite, por exemplo, é um modelo multimodal processando texto, imagens e vídeo em uma janela de contexto de 1 milhão de tokens. Oferece desempenho em processamento de documentos, compreensão de vídeo, geração de código e workflows de agentes.

O Nova Micro, o menor da família, destaca-se pela combinação de latência muito baixa com custo reduzido, sendo ideal para processamento em pipeline dentro de sistemas maiores — como correção de endereços ou extração de campos de dados de texto.

Caso de Uso Prático: Classificação de Intenções

Substituindo Modelos Tradicionais de Machine Learning

A detecção de intenção categoriza a intenção do usuário a partir da entrada fornecida. Em um sistema de assistência de viagens aéreas, por exemplo, o usuário pode estar solicitando informações sobre um voo previamente reservado ou perguntando sobre políticas da companhia. Esses sistemas precisam operar rápida e economicamente em alto volume.

Historicamente, a solução era treinar um modelo de machine learning tradicional. Hoje, desenvolvedores migram cada vez mais para pequenos LLMs. LLMs oferecem flexibilidade maior, compreendem gírias de texting, contexto e variações de linguagem natural — proporcionando melhor experiência ao usuário.

Para demonstração, o modelo Nova Micro foi personalizado sobre o dataset aberto Airline Travel Information System (ATIS), um benchmark padrão industrial para sistemas baseados em intenção. Sem personalização, Nova Micro alcança 41,4% de precisão. Com fine-tuning simples, essa precisão sobe para 97%.

Implementação Técnica do Fine-Tuning

Preparação de Dados

O Amazon Bedrock exige formato JSONL (JavaScript Object Notation Lines) para streaming eficiente de grandes datasets durante o treinamento, permitindo processamento incremental sem limitações de memória. Cada linha representa um exemplo independente e pode ser validada separadamente.

Para o exemplo do classificador de intenção, utilizou-se script para formatar o dataset ATIS em JSONL. O Nova Micro aceita um conjunto de validação separado — foram reservados 10% dos dados para validação e um conjunto de teste não utilizado no treinamento para testes limpos. Modelos Nova 2 fazem essa divisão automaticamente.

Ao trabalhar com modelos multimodais, confirme uso apenas de formatos de imagem suportados: PNG, JPEG e GIF. Valide o dataset com sua equipe, removendo respostas ambíguas ou contraditórias antes do treinamento.

Para informações detalhadas sobre preparação de dados para fine-tuning Nova, consulte a documentação correspondente.

Considerações de Privacidade de Dados

Ao trabalhar com dados sensíveis, anonimize ou mascare Informações Pessoalmente Identificáveis (nomes, emails, telefones, dados de pagamento) antes do upload para S3. Considere requisitos de residência de dados para conformidade regulatória.

O Amazon Bedrock não utiliza seus dados de treinamento para melhorar modelos base. Para segurança aprimorada, configure endpoints VPC para conectividade privada entre S3 e Amazon Bedrock, eliminando exposição à internet pública.

Hiperparâmetros Críticos

Embora o Amazon Bedrock defina padrões sensatos, três hiperparâmetros merecem atenção:

epochCount especifica quantas passagens completas o modelo faz através do dataset. O modelo Nova suporta 1 a 5 épocas com padrão de 2. Datasets maiores convergem com menos épocas, enquanto datasets menores beneficiam-se de mais iterações. Para o exemplo ATIS com ~5000 amostras, foi utilizado epochCount de 3.

learningRateMultiplier controla quão agressivamente o modelo aprende com erros — essencialmente, o tamanho do passo nas correções. Taxa alta demais resulta em saltos que perdem detalhes. Taxa baixa demais produz aprendizado lento. Para ATIS, utilizou-se 1e-5 (0,00001), proporcionando aprendizado estável e gradual.

learningRateWarmupSteps aumenta gradualmente a taxa de aprendizado durante iterações iniciais, estabilizando o treinamento. O padrão de 10 foi mantido no exemplo.

Para documentação completa sobre hiperparâmetros de modelos Nova, consulte a referência específica.

Iniciando um Job de Fine-Tuning

Pré-requisito: criar bucket S3 com dados de treinamento. Configure o bucket S3 na mesma região do job Bedrock com:

• Criptografia server-side (SSE-S3 ou SSE-KMS)
• Acesso público bloqueado
• Versionamento S3 para proteção contra sobrescrita acidental e rastreamento de mudanças
• Mesmas criptografia e controles de acesso no bucket de saída

Faça upload do arquivo JSONL e organize-o com prefixo /training-data.

Acesse o Console de Gerenciamento AWS, selecione Amazon Bedrock, navegue para “Modelos Personalizados” e escolha “Criar job de fine-tuning supervisionado”. Especifique o modelo Nova Micro como modelo fonte, o caminho S3 do arquivo JSONL de treinamento (exemplo: s3://seu-bucket/training-data/dados-treinamento-v2.jsonl) e o caminho S3 para saída dos resultados.

Configure os hiperparâmetros: epochCount: 3, learningRateMultiplier: 1e-5, learningRateWarmupSteps: 10.

Selecione função IAM com permissões S3 de menor privilégio ou crie uma. A função deve ter permissões limitadas a ações específicas (s3:GetObject e s3:PutObject) em caminhos específicos do bucket. Para orientação detalhada sobre boas práticas de permissões S3, consulte a documentação IAM da AWS.

Monitoramento e Avaliação

Monitore o status do job no dashboard de modelos personalizados. Aguarde conclusão da fase de validação de dados, seguida pela fase de treinamento (durando minutos a horas conforme tamanho e modalidade do dataset). Após conclusão bem-sucedida, um modelo personalizado é criado e pronto para inferência.

Analise as curvas de perda para verificar convergência apropriada. Uma curva de perda decrescente lisa indica sucesso — o modelo está aprendendo efetivamente. Padrões oscilantes (flutuações selvagens) sugerem taxa de aprendizado excessiva; reduza learningRateMultiplier em 50%. Curvas planas ou quase inalteradas indicam necessidade de mais épocas ou dados melhores; aumente epochCount em 1-2 épocas.

Custo e Tempo de Treinamento

Treinar o modelo Nova Micro personalizado para o exemplo ATIS com 4.978 amostras combinadas e 3 épocas (~1,75M tokens totais) completou em aproximadamente 1,5 horas com custo de apenas $2,18, mais taxa de armazenamento mensalrecorrente de $1,75 para o modelo.

Inferência On-Demand usando modelos Amazon Nova personalizado é cobrada à mesma taxa dos modelos não personalizados. Consulte a página de preços do Bedrock para referência atualizada.

O fine-tuning gerenciado do Amazon Bedrock torna a personalização acessível economicamente para a maioria das organizações, abrindo possibilidades para customizar modelos visando melhor desempenho e velocidade sem manutenção de prompts longos ou bases de conhecimento proprietárias.

Implantação e Segurança

Para inferência sob demanda não previsível ou baixo volume, use On-Demand. Para workloads de produção consistentes e alto volume exigindo desempenho garantido e custos menores por token, considere capacidade provisionada.

Implemente restrições de invocação usando políticas de recursos IAM para controlar quais usuários e aplicações podem invocar seu modelo personalizado. Configure autenticação/autorização para chamadas de API através de papéis e políticas IAM.

Configure endpoints VPC para Amazon Bedrock mantendo tráfego dentro de sua rede AWS. Restrinja acesso de rede a pipelines de treinamento e inferência usando grupos de segurança e Network ACLs.

Habilite endpoints VPC e configure CloudTrail para logging de chamadas de API, CloudWatch para métricas de invocação e performance, e logs de acesso S3 para rastreamento de padrões de acesso.

Avaliação do Modelo Personalizado

Após treinamento, é essencial avaliar desempenho em mundo real. Uma abordagem comum é “LLM como juiz”, onde um modelo maior com acesso a base RAG completa avalia respostas do modelo treinado versus respostas esperadas. O Amazon Bedrock oferece o serviço Amazon Bedrock Evaluations ou você pode usar seu próprio framework. Para orientação, consulte o artigo sobre LLM-as-a-judge no Amazon Bedrock Model Evaluation.

Use um conjunto de teste de perguntas e respostas preparado com mesma metodologia dos dados de treinamento, mas mantido separado para validação limpa. Para o exemplo ATIS, o modelo fine-tuned atingiu 97% de precisão no conjunto de testes — melhoria de 55,6% em relação ao modelo base Nova Micro.

Alternativas Avançadas

Para necessidades de customização mais extensas, o Amazon SageMaker AI oferece customização mais ampla e controle detalhado sobre hiperparâmetros.

Para casos demandando customização ainda mais profunda, o Amazon Nova Forge oferece alternativa estratégica a construir modelos fundacionais do zero. Enquanto fine-tuning ensina comportamentos específicos via exemplos rotulados, Nova Forge utiliza pré-treinamento continuado para construir conhecimento de domínio abrangente imergindo o modelo em milhões a bilhões de tokens de dados proprietários não rotulados.

Essa abordagem é ideal para organizações com datasets proprietários massivos, domínios altamente especializados demandando expertise profunda, ou aquelas construindo modelos fundacionais estratégicos de longo prazo servindo como ativos organizacionais. Para exemplos de customização Nova Forge, consulte o Amazon Nova Customization Hub no GitHub.

Próximos Passos

Para iniciar seu próprio projeto de fine-tuning com Amazon Bedrock, explore a documentação de fine-tuning do Amazon Bedrock e revise notebooks de exemplo no repositório AWS Samples no GitHub. Consulte a página de On-Demand inference e verifique a página de preços do Bedrock para taxas atualizadas.

Fonte

Customize Amazon Nova models with Amazon Bedrock fine-tuning (https://aws.amazon.com/blogs/machine-learning/customize-amazon-nova-models-with-amazon-bedrock-fine-tuning/)

Nova funcionalidade de agendamento sincronizado no SageMaker HyperPod

A AWS anunciou que o SageMaker HyperPod agora oferece suporte a gang scheduling em sua governança de tarefas. Esse recurso representa um avanço importante para profissionais que trabalham com treinamento distribuído de modelos de inteligência artificial e aprendizado de máquina em larga escala.

Por que o gang scheduling importa

Em ambientes de computação distribuída, quando cientistas de dados executam trabalhos de treinamento de IA/ML no SageMaker HyperPod usando o orquestrador EKS (Elastic Kubernetes Service), múltiplos pods precisam trabalhar em conjunto em diferentes nós, estabelecendo comunicação pod-a-pod para coordenar o treinamento.

O problema surge quando alguns pods iniciam enquanto outros permanecem indisponíveis. Nessa situação, os jobs em execução continuam ocupando recursos sem fazer progresso real, bloqueando outras cargas de trabalho na fila e elevando custos desnecessariamente. Além disso, podem criar deadlocks quando jobs ficam aguardando recursos que nunca chegam a estar disponíveis simultaneamente.

Como o gang scheduling resolve esses desafios

O novo recurso monitora continuamente todos os pods que compõem uma carga de trabalho e recua a execução se nem todos os pods ficarem prontos dentro de um prazo configurável. Essas cargas de trabalho recuadas são automaticamente reinseridas na fila de espera, evitando travamentos do sistema.

Administradores de infraestrutura ganham controle granular sobre o comportamento do agendamento através do Console HyperPod, podendo ajustar parâmetros como:

• O tempo de espera para que todos os pods fiquem prontos
• Estratégias para lidar com falhas de nós
• Configurações para admitir cargas de trabalho uma de cada vez, reduzindo deadlocks em clusters congestionados
• Políticas de agendamento de novas tentativas

Disponibilidade regional

O recurso está disponível para clusters SageMaker HyperPod que utilizam o orquestrador EKS nas seguintes regiões da AWS: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Jakarta), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain) e South America (São Paulo).

Próximos passos

Para aprender mais sobre essa funcionalidade, consulte a página do SageMaker HyperPod e a documentação de governança de tarefas HyperPod.

Fonte

SageMaker HyperPod now supports gang scheduling for distributed training workloads (https://aws.amazon.com/about-aws/whats-new/2026/04/sagemaker-hyperpod-gang-scheduling/)

Introdução: Por que a Supervisão Humana é Essencial em Saúde

No setor de saúde e ciências da vida, agentes de IA desempenham papéis cada vez mais relevantes: processam dados clínicos, submetem registros regulatórios, automatizam codificação médica e aceleram o desenvolvimento e comercialização de medicamentos. No entanto, a natureza sensível dos dados médicos e requisitos regulatórios como conformidade com Boas Práticas (GxP) exigem supervisão humana em pontos críticos de decisão. É neste contexto que as construções de aprovação humana no fluxo de trabalho (conhecidas como human-in-the-loop ou HITL) se tornam fundamentais.

A AWS apresentou quatro abordagens práticas para implementar esses mecanismos de aprovação usando seus serviços de nuvem, permitindo que organizações de saúde mantenham tanto a segurança regulatória quanto os ganhos de eficiência que a automação inteligente proporciona.

Desafios Únicos da Implementação de Agentes em Saúde

As organizações de saúde e ciências da vida enfrentam desafios específicos ao implantar agentes de IA:

• Conformidade regulatória – As regulamentações GxP exigem supervisão humana para operações sensíveis. Por exemplo, exclusão de registros de pacientes ou modificações em protocolos de ensaios clínicos não podem prosseguir sem autorização documentada.
• Segurança do paciente – Decisões médicas que afetam o cuidado do paciente devem ter validação clínica antes da execução.
• Requisitos de auditoria – Os sistemas de saúde precisam de rastreabilidade completa: quem aprovou cada ação e quando.
• Sensibilidade dos dados – Informações Protegidas de Saúde (PHI) exigem autorização explícita antes de acesso ou modificação.

As construções HITL fornecem esses pontos de controle necessários mantendo os ganhos de eficiência da automação baseada em agentes, permitindo que as organizações atendam a todos esses requisitos simultaneamente.

Quatro Estratégias Complementares de Implementação

A AWS apresenta quatro padrões complementares, cada um adequado para diferentes cenários e perfis de risco. A implementação utiliza o framework Strands Agents, o Amazon Bedrock AgentCore Runtime e o Protocolo de Contexto do Modelo (Model Context Protocol – MCP), com exemplos de código que podem ser adaptados para casos de uso específicos.

Método 1: Interrupção no Loop do Agente (Sistema de Hooks)

O framework Strands Agents fornece um sistema de hooks que intercepta chamadas de ferramentas antes de sua execução no nível do loop do agente. Essa abordagem aplica uma política HITL uniforme a ferramentas sensíveis sem necessidade de modificar as ferramentas em si.

Um HookProvider registra um callback no evento BeforeToolCallEvent. Quando uma ferramenta sensível é invocada, o hook dispara uma interrupção, pausando o loop do agente até que o operador humano responda. O usuário pode responder com “y” (aprovar uma vez), “n” (negar) ou “t” (confiar – aprovar essa ferramenta pelo restante da sessão).

class ApprovalHook(HookProvider):
    SENSITIVE_TOOLS = ["get_patient_condition", "get_patient_vitals"]
    
    def register_hooks(self, registry: HookRegistry, **kwargs: Any) -> None:
        registry.add_callback(BeforeToolCallEvent, self.approve)
    
    def approve(self, event: BeforeToolCallEvent) -> None:
        tool_name = event.tool_use["name"]
        if tool_name not in self.SENSITIVE_TOOLS:
            return
        
        # Pular se o usuário já escolheu "confiar sempre" para esta ferramenta
        approval_key = f"{tool_name}-approval"
        if event.agent.state.get(approval_key) == "t":
            return
        
        approval = event.interrupt(
            approval_key,
            reason={"reason": f"Authorize {tool_name} with args: {event.tool_use.get('input', {})}"},
        )
        
        if approval.lower() not in ["y", "yes", "t"]:
            event.cancel_tool = f"User denied permission to run {tool_name}"
            return
        
        if approval.lower() == "t":
            event.agent.state.set(approval_key, "t")

O hook é anexado ao agente no momento da construção — as ferramentas permanecem completamente desconhecidas da lógica de aprovação, mantendo a separação de responsabilidades:

agent = Agent(
    hooks=[ApprovalHook()],
    tools=[get_patient_name, get_patient_condition, get_patient_vitals],
)

Método 2: Interrupção no Contexto da Ferramenta

Em vez de um hook centralizado, a lógica de aprovação é incorporada diretamente em cada ferramenta usando tool_context.interrupt(). Essa abordagem oferece controle granular por ferramenta: cada uma implementa suas próprias regras de acesso baseadas no contexto da sessão.

Neste exemplo, a sessão do agente carrega um user_role. Uma função check_access compartilhada implementa controle de acesso baseado em papéis. Usuários não-médicos recebem negação imediata, enquanto médicos recebem um prompt de aprovação:

def check_access(tool_context, patient_id: str, action: str):
    user_role = tool_context.agent.state.get("user_role") or "Non-Physician"
    if user_role != "Physician":
        return f"Access denied: {action} requires Physician role (current: {user_role})"
    
    approval_key = f"{action}-{patient_id}-approval"
    if tool_context.agent.state.get(approval_key) == "t":
        return None  # previously trusted
    
    approval = tool_context.interrupt(
        approval_key,
        reason={"reason": f"[{user_role}] Authorize {action} for patient {patient_id}"},
    )
    
    if approval.lower() not in ["y", "yes", "t"]:
        return f"Physician denied access to {action} for patient {patient_id}"
    
    if approval.lower() == "t":
        tool_context.agent.state.set(approval_key, "t")
    return None  # approved

Como no Método 1, a opção de confiança armazena a aprovação para o restante da sessão, evitando prompts repetitivos para a mesma operação.

Método 3: Aprovação Assíncrona com AWS Step Functions

Em muitos cenários empresariais, o fluxo de aprovação requer autorização de um terceiro que não está invocando o agente. Isso necessita de um fluxo de trabalho assíncrono que funcione independentemente da sessão do agente.

Uma abordagem efetiva utiliza AWS Step Functions para orquestrar esses processos de aprovação externa. Neste padrão, a ferramenta do agente dispara uma execução do Step Functions que envia uma solicitação de aprovação a um aprovador externo através de notificação por email via Amazon SNS (Serviço de Notificação Simples).

A ferramenta consulta periodicamente o resultado da aprovação e atualiza o estado da sessão do agente. O usuário também pode verificar o status de aprovação depois usando uma ferramenta separada check_discharge_status:

@tool(context=True)
def discharge_patient(tool_context, patient_id: str, reason: str) -> str:
    # Skip workflow if already approved in this session
    if tool_context.agent.state.get("external-approver-state") == "approved":
        return f"Patient {patient_id} discharged (pre-approved). Reason: {reason}"
    
    response = sfn_client.start_execution(
        stateMachineArn=state_machine_arn,
        input=json.dumps({"patient_id": patient_id, "action": "discharge", "reason": reason}),
    )
    
    return f"Waiting for approval. Execution ARN: {response['executionArn']}"

Essa abordagem assíncrona permite operações não-bloqueantes onde os usuários não são forçados a aguardar aprovações que podem levar horas ou dias. A execução do agente prossegue independentemente. O Step Functions mantém trilhas de auditoria detalhadas com histórico completo de execução, gerenciamento de estado persistente entre timeouts de sessão e integração com canais de comunicação empresariais como email, Slack ou Microsoft Teams.

Método 4: Elicitação via Protocolo de Contexto do Modelo (MCP)

O protocolo MCP (Model Context Protocol) introduziu recentemente o conceito de elicitação, que permite que servidores MCP solicitem informações ou aprovação adicionais do usuário durante a execução da ferramenta.

Quando uma ferramenta sensível é chamada, o servidor MCP pausa a execução e envia um prompt de aprovação de volta através do cliente MCP para o usuário final. O usuário vê o prompt, toma uma decisão e o servidor retoma — procedendo com a operação ou negando acesso. Essa comunicação bidirecional é habilitada pelo transporte HTTP contínuo do MCP, que mantém uma conexão com estado entre cliente e servidor.

No servidor MCP, a lógica de aprovação é uma única chamada ctx.elicit() dentro de cada ferramenta sensível:

@server.tool
async def get_patient_condition(patient_id: str, ctx: Context) -> str:
    """Get patient condition. Sensitive — requires approval via MCP elicitation."""
    result = await ctx.elicit(
        f"⚠️ Approve access to SENSITIVE condition data for patient {patient_id}?"
    )
    
    if result.action != "accept":
        return f"Access to condition data for patient {patient_id} DENIED."
    
    return f"Patient {patient_id} condition: Hypertension Stage 2, Type 2 Diabetes"

No lado do agente, um callback de elicitação é registrado com o cliente MCP. Quando o servidor chama ctx.elicit(), esse callback dispara, transmitindo o prompt de aprovação ao usuário e retornando sua decisão de volta ao servidor. Para agentes locais, este é um prompt terminal. Para agentes implantados no AgentCore Runtime, uma conexão WebSocket retransmite a elicitação para o usuário remoto em tempo real.

Essa abordagem mantém a lógica de aprovação inteiramente dentro das definições de ferramentas do servidor MCP. O agente em si desconhece quais ferramentas exigem aprovação, permitindo adicionar ou modificar requisitos de aprovação de forma independente.

Visão Geral da Arquitetura

A arquitetura da solução utiliza o framework Strands Agents para gerenciamento do ciclo de vida do agente e tratamento de interrupções, implantado no Amazon Bedrock AgentCore Runtime para escalabilidade sem servidor e isolamento de sessão. AWS Step Functions orquestra fluxos de trabalho de aprovação assíncrona com Amazon SNS, enquanto servidores MCP expõem ferramentas ao agente através do MCP — também implantados no AgentCore Runtime.

Todos os códigos para esses padrões de arquitetura estão disponíveis publicamente no repositório GitHub. Cada um dos métodos demonstrados representa uma abordagem autocontida.

Detalhes de Implementação Prática

O agente é implantado no Amazon Bedrock AgentCore Runtime com acesso a ferramentas de saúde em diferentes níveis de sensibilidade. Operações de baixo risco, como buscar o nome de um paciente, executam sem aprovação. Ações de alto risco, como recuperação de sinais vitais ou condições médicas, exigem autorização humana. Operações como alta hospitalar requerem aprovação de supervisor externo através de notificação por email.

A seleção entre os quatro padrões depende do seu caso de uso específico: o Método 1 oferece controle centralizado e uniforme; o Método 2 oferece flexibilidade por ferramenta com controle granular; o Método 3 acomoda aprovações externas assíncronas em ambientes empresariais; e o Método 4 proporciona aprovação interativa em tempo real com protocolo padrão.

Conclusão: Segurança e Eficiência em Harmonia

Os padrões de aprovação humana apresentados permitem que organizações de saúde e ciências da vida construam implantações seguras e compatíveis de agentes de IA. Ao implementar o padrão HITL apropriado para seu caso de uso, é possível implantar fluxos de trabalho prontos para produção que escalem desde projetos piloto até implantações em toda a empresa.

O primeiro passo é identificar quais operações no seu fluxo de trabalho exigem supervisão humana. Em seguida, selecione o padrão HITL que melhor se adequa aos seus requisitos de aprovação — centralizado (Método 1), específico por ferramenta (Método 2), assíncrono (Método 3) ou em tempo real (Método 4).

Para informações adicionais sobre Amazon Bedrock AgentCore, visite a documentação do Amazon Bedrock AgentCore.

Fonte

Human-in-the-loop constructs for agentic workflows in healthcare and life sciences (https://aws.amazon.com/blogs/machine-learning/human-in-the-loop-constructs-for-agentic-workflows-in-healthcare-and-life-sciences/)

O desafio de entender os gastos com IA

Conforme as organizações ampliam suas operações de IA no Amazon Bedrock, compreender o que está impulsionando os gastos se torna essencial. Equipes precisam realizar cobranças internas, investigar picos de custo e orientar decisões de otimização — tudo isso exigindo uma atribuição de custos no nível da carga de trabalho. O desafio cresce quando múltiplos projetos, ambientes e times utilizam os mesmos recursos.

Para endereçar essa necessidade, a AWS desenvolveu o Amazon Bedrock Projects, um recurso que permite atribuir custos de inferência a cargas de trabalho específicas e analisar esses gastos usando ferramentas de billing já consolidadas na plataforma, como AWS Cost Explorer e AWS Data Exports.

Como funcionam os Bedrock Projects e a alocação de custos

Na prática, um projeto no Amazon Bedrock é uma demarcação lógica que representa uma carga de trabalho — pode ser uma aplicação, um ambiente ou até um experimento. Para atribuir custos a esse projeto, você anexa etiquetas de recurso (resource tags) e passa o ID do projeto nas chamadas de API. Posteriormente, essas etiquetas podem ser ativadas como etiquetas de alocação de custos no AWS Billing, permitindo filtrar, agrupar e analisar gastos no Cost Explorer e nos Data Exports.

O fluxo é simples: usuários e aplicações enviam requisições de API com o ID do projeto, que passa por Foundation Models (como OpenAI, Meta e DeepSeek). As etiquetas associadas ao projeto fluem para o AWS Billing & Cost Management, onde você ativa a alocação de custos de forma única. A partir daí, todas as ferramentas de análise ficam cientes dessa dimensão de custo.

Pontos importantes sobre compatibilidade

O Amazon Bedrock Projects oferece suporte aos endpoints Mantle compatíveis com a API OpenAI, incluindo a Responses API e a Chat Completions API. Requisições que não incluem um ID de projeto são automaticamente associadas ao projeto padrão da sua conta AWS.

Preparação: pré-requisitos e permissões

Antes de começar, você precisa de:

• Acesso ao Amazon Bedrock com suporte ao OpenAI SDK. Confira o Guia de Início Rápido do Amazon Bedrock para começar.
• Permissões do IAM (Identity and Access Management) para Amazon Bedrock Projects, inferência e tagging. Para fins de exemplo, você pode anexar a política gerenciada da AWS AmazonBedrockMantleFullAccess. Em produção, consulte Implementando privilégio mínimo para Amazon Bedrock.
• Acesso ao console de Billing e Gerenciamento de Custos da AWS.

Definindo sua estratégia de etiquetagem

As etiquetas que você vincula aos projetos tornam-se as dimensões que você pode filtrar e agrupar nos seus relatórios de custo. Recomenda-se planejar essas dimensões antes de criar o primeiro projeto. Uma abordagem comum é etiquetar por aplicação, ambiente, time e centro de custo:

Chave de Etiqueta	Propósito	Exemplos de Valores
Application	Qual carga de trabalho ou serviço	CustomerChatbot, Experiments, DataAnalytics
Environment	Estágio do ciclo de vida	Production, Development, Staging, Research
Team	Responsabilidade ou propriedade	CustomerExperience, PlatformEngineering, DataScience
CostCenter	Mapeamento financeiro	CC-1001, CC-2002, CC-3003

Para mais orientações sobre construir uma estratégia de alocação de custos, consulte Melhores Práticas para Etiquetar Recursos AWS. Com sua estratégia de etiquetagem definida, você está pronto para criar projetos e começar a atribuir custos.

Criando seu primeiro projeto

Com a estratégia de etiquetagem e as permissões em lugar, você pode criar seu primeiro projeto. Cada projeto tem seu próprio conjunto de etiquetas de alocação de custos que fluem para seus dados de billing. O exemplo a seguir demonstra como criar um projeto usando a Projects API.

Instalando dependências

Comece instalando as bibliotecas necessárias:

$ pip3 install openai requests

Criando um projeto com sua taxonomia de etiquetas

O OpenAI SDK utiliza a variável de ambiente OPENAI_API_KEY. Defina-a com sua chave de API do Bedrock:

import os
import requests

# Configuration
BASE_URL = "https://bedrock-mantle..api.aws/v1"
API_KEY = os.environ.get("OPENAI_API_KEY")

# Your Amazon Bedrock API key

def create_project(name: str, tags: dict) -> dict:
    """Create a Bedrock project with cost allocation tags."""
    response = requests.post(
        f"{BASE_URL}/organization/projects",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json"
        },
        json={"name": name, "tags": tags}
    )
    if response.status_code != 200:
        raise Exception(
            f"Failed to create project: {response.status_code} - {response.text}"
        )
    return response.json()

# Create a production project with full tag taxonomy
project = create_project(
    name="CustomerChatbot-Prod",
    tags={
        "Application": "CustomerChatbot",
        "Environment": "Production",
        "Team": "CustomerExperience",
        "CostCenter": "CC-1001",
        "Owner": "alice"
    }
)
print(f"Created project: {project['id']}")

A API retorna os detalhes do projeto, incluindo o ID e o ARN:

{
    "id": "proj_123",
    "arn": "arn:aws:bedrock-mantle:::project/"
}

Guarde o ID do projeto — você o usará para associar requisições de inferência na próxima etapa. O ARN é utilizado para anexação de políticas do IAM se você precisar restringir o acesso a esse projeto específico.

Repita esse processo para cada carga de trabalho. A tabela a seguir mostra uma estrutura de projeto de exemplo para uma organização com três aplicações:

Nome do Projeto	Application	Environment	Team	Cost Center
CustomerChatbot-Prod	CustomerChatbot	Production	CustomerExperience	CC-1001
CustomerChatbot-Dev	CustomerChatbot	Development	CustomerExperience	CC-1001
Experiments-Research	Experiments	Production	PlatformEngineering	CC-2002
DataAnalytics-Prod	DataAnalytics	Production	DataScience	CC-3003

Você pode criar até 1.000 projetos por conta AWS para atender às necessidades da sua organização.

Associando requisições de inferência ao seu projeto

Com seus projetos criados, você associa requisições de inferência passando o ID do projeto em suas chamadas de API. O exemplo a seguir utiliza a Responses API:

from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-mantle..api.aws/v1",
    project="",
    # ID returned when you created the project
)

response = client.responses.create(
    model="openai.gpt-oss-120b",
    input="Summarize the key findings from our Q4 earnings report."
)

print(response.output_text)

Para manter uma atribuição de custos limpa e consistente, sempre especifique um ID de projeto em suas chamadas de API em vez de depender do projeto padrão.

Ativando as etiquetas de alocação de custos

Antes que suas etiquetas de projeto apareçam nos relatórios de custo, você deve ativá-las como etiquetas de alocação de custos no AWS Billing. Esse é um processo de configuração único que conecta suas etiquetas de projeto ao pipeline de billing. Para mais informações, consulte a documentação de ativação de etiquetas de alocação de custos no AWS Billing.

Pode levar até 24 horas para as etiquetas se propagarem para o AWS Cost Explorer e AWS Data Exports. Recomenda-se ativar suas etiquetas imediatamente após criar seu primeiro projeto para evitar lacunas nos dados de custo.

Visualizando custos dos projetos

Com os projetos criados, as requisições de inferência etiquetadas e as etiquetas de alocação de custos ativadas, você consegue ver exatamente para onde seus gastos com Amazon Bedrock estão indo. Cada dimensão que você definiu em sua taxonomia agora está disponível como filtro ou agrupamento em seus relatórios de billing da AWS.

Usando o AWS Cost Explorer

O AWS Cost Explorer oferece a forma mais rápida de visualizar seus custos por projeto. Siga estes passos para revisar seus custos por projeto:

• Abra o console de Billing e Gerenciamento de Custos da AWS e escolha Cost Explorer.
• No painel Filtros, expanda Serviço e selecione Amazon Bedrock.
• Em Agrupar por, selecione Etiqueta e escolha sua chave de etiqueta (por exemplo, Application).

Para mais formas de refinar sua visualização, consulte Analisando seus custos e uso com AWS Cost Explorer.

Análise mais granular com Data Exports

Para análise mais granular e detalhes de linha de item com suas etiquetas de projeto, consulte Criando Data Exports na documentação do AWS Billing.

Conclusão

Com o Amazon Bedrock Projects, as organizações conseguem atribuir custos a cargas de trabalho individuais e acompanhar gastos utilizando as ferramentas de billing que já dominam. Conforme suas operações de IA escalam, utilize a estratégia de etiquetagem e os padrões de visibilidade de custos apresentados neste artigo para manter a responsabilidade entre equipes e aplicações.

Para mais informações, consulte a documentação do Amazon Bedrock Projects e o AWS Cost Management User Guide.

Fonte

Manage AI costs with Amazon Bedrock Projects (https://aws.amazon.com/blogs/machine-learning/manage-ai-costs-with-amazon-bedrock-projects/)

Redefinindo o Acesso aos Dados Empresariais

Um dos maiores desafios em organizações orientadas por dados é o gargalo entre a pergunta e a resposta. Quando um gestor precisa entender como está o crescimento de receita por segmento de cliente, essa pergunta muitas vezes fica aguardando em fila atrás de demandas consideradas mais urgentes. Uma solução de conversão de texto em SQL pode transformar esse cenário: usuários de negócio conseguem responder suas próprias perguntas rotineiras, liberando a capacidade técnica para iniciativas mais complexas e estratégicas.

Perguntas que exigiriam horas de trabalho especializado — como “Qual é a tendência de receita este ano em comparação com o ano anterior, desagregada por nossos principais segmentos de clientes?” — podem se tornar acessíveis a qualquer pessoa, sem criar sobrecarga adicional nos times técnicos.

Embora ferramentas tradicionais de Business Intelligence (BI) tenham evoluído significativamente, ainda existem lacunas quando usuários precisam explorar dados além das análises pré-configuradas. Uma solução customizada de text-to-SQL preenche essa lacuna, operando diretamente contra o esquema do seu data warehouse e incorporando contexto de negócio recuperado dinamicamente.

Os Desafios que Justificam uma Abordagem Customizada

A Barreira da Expertise em SQL

A maioria dos usuários de negócio não possui conhecimento técnico de SQL. Perguntas aparentemente simples frequentemente exigem múltiplas junções entre tabelas, cálculos temporais complexos e agregações hierárquicas. Esse cenário cria um gargalo: usuários aguardam relatórios customizados enquanto analistas gastariam tempo valioso respondendo requisições repetitivas, em vez de se dedicarem a análises estratégicas.

Os Limites das Ferramentas Modernas de BI

Ferramentas contemporâneas de BI avançaram bastante em consultas em linguagem natural e análise de autoatendimento. Contudo, essas capacidades funcionam melhor quando confinadas a camadas semânticas pré-curadas, conjuntos de dados governados ou dashboards pré-modelados. Quando um usuário precisa explorar além desses limites — realizando junções pontuais, aplicando cálculos organizacionais específicos ou consultando tabelas não incluídas na camada semântica — ainda enfrenta restrições que demandam intervenção técnica.

A Lacuna de Contexto e Semântica

Traduzir terminologia de negócio em consultas de banco de dados corretas é desafiador. Termos como “atingimento”, “pipeline” e “previsão” carregam lógica de cálculo única, fontes de dados específicas e regras de negócio que variam conforme a organização. Compreender quais tabelas devem ser combinadas, como métricas são definidas e quais filtros aplicar exige conhecimento institucional profundo que muitos usuários não possuem. Uma solução efetiva precisa codificar esse contexto de negócio — princípios estratégicos, regras de segmentação de clientes, processos operacionais — permitindo que usuários tomem decisões orientadas por dados sem dominar schemas complexos.

Como Funciona: A Experiência do Usuário

Considere um usuário de negócio que formula uma pergunta através de uma interface conversacional: “Como a receita está evoluindo este ano em relação ao ano passado por segmento de cliente?” Em questão de segundos, o sistema realiza as seguintes operações:

Compreensão da Pergunta

O sistema classifica se a questão é uma consulta simples ou se requer decomposição em múltiplas etapas. No exemplo acima, reconhece que “tendência de receita”, “comparação ano a ano” e “principais segmentos de cliente” são componentes distintos que demandam passos de recuperação de dados separados.

Recuperação de Contexto de Negócio

O sistema consulta um grafo de conhecimento que codifica definições de métricas, terminologia de negócio, relacionamentos entre tabelas e regras de dados específicas da organização. Sabe o que “receita” significa no contexto da empresa, quais tabelas a contêm e como “segmento de cliente” é definido.

Geração e Validação de SQL

Gera uma consulta SQL estruturada, valida sua correção e segurança usando verificações determinísticas e a executa contra o data warehouse. Se a validação identificar um problema, a consulta é automaticamente revisada e executada novamente, sem necessidade de intervenção humana.

Síntese da Resposta

Os resultados brutos da consulta são transformados em narrativa em linguagem natural, fornecendo ao usuário tanto o insight quanto a transparência necessária para confiar no resultado.

Arquitetura da Solução

Para entregar essa experiência, a solução integra três capacidades principais:

• Modelos de fundação (FM) em Amazon Bedrock para compreensão de linguagem natural e geração de SQL
• Recuperação Aumentada por Grafos de Conhecimento (GraphRAG) para recuperação de contexto de negócio
• Data warehouses de alto desempenho para execução rápida de consultas

O Amazon Bedrock desempenha um papel central, fornecendo tanto a camada de inferência de modelo de linguagem de grande escala (LLM) quanto o runtime de orquestração de agentes. A plataforma oferece acesso a um amplo portfólio de modelos de fundação, permitindo que equipes selecionem e troquem modelos conforme evoluem os requisitos de desempenho, custo e latência, sem necessidade de redesenho arquitetural.

O Amazon Bedrock AgentCore Runtime funciona como camada central de orquestração, hospedando um agente supervisor que coordena todo o fluxo de trabalho. Roteia perguntas de usuários, invoca ferramentas de busca GraphRAG para recuperação de contexto, aplica segurança em nível de linha, dispara geração e validação de SQL e executa consultas contra um banco de dados como o Amazon Redshift. O runtime oferece suporte a múltiplos pontos de entrada, incluindo protocolos MCP e HTTP, possibilitando integração tanto com superfícies de análise integradas como o AWS QuickSight quanto com interfaces web customizadas.

O Amazon Bedrock AgentCore também fornece observabilidade integrada, alimentando traces de execução de agentes e métricas de desempenho no Amazon CloudWatch para monitoramento, depuração e otimização contínua. Esse runtime gerenciado elimina o trabalho indiferenciado de construir infraestrutura customizada de agentes, permitindo que equipes se concentrem em lógica de negócio, ajuste de prompts e enriquecimento de conhecimento de domínio.

Os Cinco Estágios do Fluxo de Trabalho

Estágio 1: Análise e Decomposição da Pergunta

Quando uma pergunta chega, o processador de questões a classifica inicialmente. Perguntas diretas e factuais como “Qual foi a receita total no Q4?” são roteadas diretamente ao pipeline de recuperação de dados. Perguntas complexas ou com múltiplas partes são decompostas em subperguntas independentes que podem ser processadas em paralelo por equipes de agentes separadas. Esse passo de decomposição permite que o sistema trabalhe com perguntas analíticas sofisticadas que abrangem múltiplos domínios de dados, períodos de tempo ou dimensões de negócio.

Estágio 2: Recuperação de Contexto via Grafo de Conhecimento e GraphRAG

Este é o estágio que resolve a barreira de contexto — e representa o diferencial mais crítico frente a abordagens naive de text-to-SQL. Um grafo de conhecimento construído sobre Amazon Neptune e Amazon OpenSearch Service funciona como fundação semântica. Armazena a ontologia de tabelas da organização e captura relacionamentos entre entidades de negócio, métricas, terminologia e hierarquias organizacionais.

Criaticamente, esse grafo é enriquecido com conhecimento de domínio — proprietários de tabelas e especialistas em assunto fornecem descrições específicas do negócio, definições de métricas, mapeamentos de terminologia e tags de classificação carregadas a partir de arquivos de configuração estruturados.

Quando o sistema processa uma pergunta, realiza uma busca GraphRAG leve em três fases:

• Busca vetorial (usando Amazon OpenSearch Service): Localiza valores de coluna, nomes de coluna e descrições de tabelas semanticamente relevantes que correspondem aos conceitos na pergunta do usuário.
• Traversal do grafo (usando Amazon Neptune): Segue relacionamentos no grafo de conhecimento, desde valores correspondidos até suas colunas-pai e tabelas-pai, construindo uma visão completa de quais ativos de dados são relevantes e como se conectam.
• Scoring de relevância e filtragem: Classifica e estrutura o contexto recuperado para que o gerador de SQL receba precisamente as informações necessárias — as tabelas certas, as colunas certas, os caminhos de junção corretos e a lógica de negócio apropriada.

O grafo de conhecimento e seus dados associados são atualizados regularmente para refletir mudanças de schema, novas tabelas e evoluções nas definições de negócio. Quanto mais rica essa camada contextual, mais precisa torna-se a geração de SQL subsequente.

Estágio 3: Geração de SQL Estruturada e Validação

O sistema utiliza os recursos de chamadas de função do Amazon Bedrock para produzir consultas SQL como dados estruturados. Isso impõe formatos de saída rigorosos, elimina a necessidade de pós-processamento frágil ou expressões regulares complexas e melhora significativamente a confiabilidade.

As consultas geradas passam por validadores SQL determinísticos operando no nível de Árvore de Sintaxe Abstrata (AST). Esses validadores identificam proativamente operações potencialmente arriscadas — consultas sintaticamente corretas mas semanticamente perigosas (por exemplo, varreduras sem limite, filtros faltantes, lógica de agregação incorreta).

Quando um validador identifica um problema, retorna feedback detalhado explicando a questão e sugerindo uma revisão. Para aumentar ainda mais a robustez, todo o ciclo é encapsulado em um agente de geração SQL leve que itera automaticamente até produzir uma consulta válida e executável ou atingir um limite configurável de tentativas. Essa abordagem visa entregar confiabilidade significativamente superior à engenharia de prompts isolada.

Estágio 4: Computação Paralela em Tempo de Teste

Para perguntas ambíguas ou complexas, o sistema pode gerar múltiplas respostas potenciais ou caminhos de raciocínio simultaneamente, submetendo a mesma pergunta a agentes em paralelo. Resultados são sintetizados através de votação majoritária, selecionando o resultado mais confiável. Isso é particularmente valioso para perguntas passíveis de múltiplas interpretações e melhora significativamente tanto a acurácia quanto a robustez.

Estágio 5: Síntese da Resposta

Resultados brutos de consulta — incluindo números, dataframes e logs de execução — são sintetizados em narrativas em linguagem natural que usuários recebem como respostas acionáveis. Transparência total é mantida: usuários podem inspecionar o SQL gerado e dados subjacentes a qualquer momento, construindo confiança nos outputs do sistema.

Estratégias para Resultados em Ambiente de Produção

Permitir que Usuários Finais Moldem os Prompts

Mesmo entre usuários experientes, interpretações padrão divergem para termos ambíguos e expectativas variam para perguntas vagas. Recomenda-se construir uma interface de customização — como uma aplicação web — permitindo que proprietários de tabelas e usuários avançados designados personalizem prompts dentro de limites governados. Customizações devem passar por guardrails de validação que reforçam políticas de conteúdo, restringem tentativas de prompt injection e garantem que modificações permaneçam dentro de templates e parâmetros aprovados.

Essa capacidade de customização prova-se essencial para alcançar a compreensão nuançada que domínios de negócio diferentes demandam. Sua solução deve acomodar essas variações em vez de impor uma abordagem única e padronizada.

Validação de SQL como Camada Crítica de Segurança

Engenharia de prompts isolada não consegue eliminar erros que produzem SQL sintaticamente válido mas semanticamente incorreto. Esses erros são particularmente perigosos pois retornam resultados que parecem plausíveis, podendo silenciosamente deteriorar confiança do usuário ou alimentar decisões incorretas. Como SQL é uma linguagem bem-definida, validadores determinísticos conseguem capturar uma ampla classe desses erros antes que a consulta chegue ao banco de dados.

Priorize-a como um mecanismo de segurança inegociável.

Otimização Agressiva para Latência

Usuários acostumados com IA conversacional esperam respostas quase instantâneas. Embora recuperar dados ao vivo e executar cálculos necessariamente demande mais tempo que responder de uma base de conhecimento estática, a latência ainda deve ser gerenciada ativamente como preocupação crítica de experiência do usuário.

Análise de desempenho revela que o fluxo de trabalho envolve múltiplos passos, e o tempo cumulativo através deles representa a maior oportunidade em relação ao tempo de execução SQL isoladamente. Para otimizar, foque em:

• Execução de agentes em paralelo — Processe perguntas com múltiplas partes concorrentemente em vez de sequencialmente. Isso pode reduzir drasticamente o tempo total para consultas complexas.
• Armazenamento analítico de alto desempenho — Use bancos de dados orientados por colunas que se destacam em cargas de trabalho pesadas em agregação, típicas em BI.
• Otimização de tokens — Minimize tokens de entrada e saída por interação de agente através de otimização de prompt e padronização de formato de resposta. Reduza dependência de frameworks agentic baseados em chamadas de ferramentas, onde cada chamada força o agente a reingerir contexto crescente.

Com essas otimizações, em implantações observadas, consultas SQL simples são tipicamente geradas em aproximadamente 3 a 5 segundos. Tempos de resposta reais variarão conforme fatores como desempenho de data warehouse, complexidade de consulta, seleção de modelo e tamanho do grafo de conhecimento. Recomenda-se fazer benchmark contra seu próprio ambiente para estabelecer alvos realistas de latência para análise de negócio interativa.

Construir Segurança e Governança desde o Início

Implemente integração de Segurança em Nível de Linha (RLS) para que usuários visualizem apenas dados aos quais estão autorizados a acessar. O sistema mantém tabelas de direitos compostas que aplicam políticas de controle de acesso originadas de sistemas organizacionais existentes. Quando um usuário submete uma consulta, filtros RLS apropriados são automaticamente injetados no SQL gerado antes da execução.

Projetar essa camada para respeitar padrões rígidos de governança de dados sem adicionar fricção à experiência do usuário é essencial.

Resultados e Impacto

Após seguir a arquitetura e estratégias apresentadas, uma solução text-to-SQL consegue entregar melhorias significativas em acessibilidade de dados e produtividade analítica:

• Velocidade — Respostas para perguntas de negócio complexas em minutos, comparado a horas ou dias com abordagens tradicionais. Perguntas exigindo múltiplas junções, cálculos temporais e agregações hierárquicas — que previamente demandavam desenvolvimento SQL customizado — tornam-se acessíveis via linguagem natural.
• Democratização analítica — Usuários não técnicos em operações de vendas, planejamento financeiro e liderança executiva conseguem realizar análise de dados sofisticada sem expertise SQL. Isso tipicamente reduz a carga de trabalho analítico em times de engenharia de dados, permitindo que se dediquem a iniciativas estratégicas em vez de requisições de consulta repetitivas.
• Suporte a consultas complexas — Análise multidimensional de receita com segmentação automática, tendências ano a ano e mês a mês com explicações de variância, inteligência de cliente em níveis granulares com padrões de uso, análise de variância de previsão com comparações de meta e benchmarking cross-funcional através de períodos e unidades de negócio.

O Futuro das Consultas Conversacionais a Dados

Soluções text-to-SQL movidas por Amazon Bedrock representam um avanço significativo em tornar análise de dados acessível a usuários de negócio. A arquitetura multi-agente usando Amazon Bedrock Agents oferece suporte a decomposição complexa de consultas e processamento paralelo, enquanto grafos de conhecimento fornecem contexto de negócio e compreensão semântica. Juntos, esses componentes entregam análise precisa, rápida e acessível que empoderam usuários a tomar decisões orientadas por dados sem barreiras técnicas.

Ao construir sua própria solução, considere expandir cobertura do grafo de conhecimento para domínios adicionais de negócio, otimizar latência de resposta através de estratégias avançadas de cache e integração com mais fontes de dados empresariais. Os Amazon Bedrock Guardrails oferecem capacidades aprimoradas de validação de output e segurança que valem exploração, enquanto o Amazon Bedrock Flows fornece padrões de orquestração sofisticados para fluxos de trabalho agentic.

A flexibilidade de modelos de fundação, capacidades de orquestração de agentes e integração de base de conhecimento disponíveis através do Amazon Bedrock continuam evoluindo, tornando análise de dados progressivamente mais intuitiva e poderosa para usuários de negócio através de organizações.

Próximos Passos

Para construir sua própria solução text-to-SQL, explore o Amazon Bedrock User Guide, participe de um Amazon Bedrock Workshop e revise o guia sobre Building generative AI agents with Amazon Bedrock. Para os desenvolvimentos mais recentes, visite What’s New with AWS.

Fonte

Text-to-SQL solution powered by Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/text-to-sql-solution-powered-by-amazon-bedrock/)

Novidade no SageMaker: Fluxos de Trabalho Serverless para Identity Center

A AWS anunciou a adição de uma funcionalidade importante ao Amazon SageMaker Unified Studio: suporte a fluxos de trabalho serverless em domínios do Identity Center (Centro de Identidades). Essa expansão democratiza o acesso a uma capacidade que, até então, estava disponível apenas para domínios baseados em IAM (Gerenciamento de Identidade e Acesso).

O que são Fluxos de Trabalho Serverless?

Os fluxos de trabalho serverless permitem que usuários orquestrem tarefas de processamento de dados utilizando Apache Airflow através do Managed Workflows for Apache Airflow, sem a necessidade de provisionar ou gerenciar manualmente a infraestrutura do Airflow. Esse modelo simplifica significativamente o trabalho dos engenheiros de dados e cientistas de dados que precisam coordenar pipelines complexos.

Vantagens para Clientes do Identity Center

O grande diferencial dessa solução é a eficiência operacional. Os fluxos de trabalho provisionam automaticamente os recursos de computação quando uma execução é iniciada e os liberam quando ela é concluída. Essa abordagem garante que você pague apenas pelo tempo de execução real do seu fluxo de trabalho, eliminando custos com infraestrutura ociosa.

Além disso, cada fluxo de trabalho executa com sua própria função de execução e um worker isolado, oferecendo segurança em nível de fluxo de trabalho e prevenindo interferências entre diferentes processos. Essa arquitetura protege seus dados e garante a integridade das operações.

Experiência Visual e Integrações Integradas

Os clientes do Identity Center agora também têm acesso à experiência visual de fluxo de trabalho com suporte para aproximadamente 200 operadores. O Amazon SageMaker Unified Studio vem com integrações nativas para diversos serviços AWS, incluindo Amazon S3, Amazon Redshift, Amazon EMR, AWS Glue e Amazon SageMaker AI. Isso significa que você pode construir pipelines sofisticados conectando esses serviços sem escribar código complexo de integração.

Disponibilidade e Próximos Passos

Os fluxos de trabalho serverless em domínios do Identity Center estão disponíveis em todas as regiões AWS onde o SageMaker Unified Studio é suportado. Para aprofundar seu conhecimento técnico e explorar as capacidades completas dessa funcionalidade, você pode consultar a documentação detalhada sobre fluxos de trabalho serverless.

Por que isso importa para equipes brasileiras?

Essa novidade reduz a barreira de entrada para empresas brasileiras que desejam modernizar seus pipelines de dados na nuvem. Com menos complexidade operacional e uma interface visual intuitiva, organizações podem focar em entregar valor através dos dados, em vez de gastar recursos em administração de infraestrutura. Para startups e empresas que crescem rapidamente, o modelo de precificação pay-as-you-go dos fluxos serverless oferece flexibilidade financeira e escalabilidade sem surpresas orçamentárias.

Fonte

Amazon SageMaker adds serverless workflows to Identity Center domains (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-serverless-workflows/)

Consultas em linguagem natural chegam ao Cost Explorer

A AWS anunciou a integração de capacidades de inteligência artificial generativa do Amazon Q diretamente ao AWS Cost Explorer, transformando a forma como equipes analisam seus custos e gastos na nuvem. Agora é possível utilizar perguntas em linguagem natural para fazer buscas sobre dados de custos e uso, reduzindo significativamente o tempo necessário para obter insights valiosos.

Essa integração vai além de simplesmente responder perguntas. Quando o Amazon Q fornece insights, o Cost Explorer atualiza automaticamente suas visualizações, gráficos, filtros e agrupamentos conforme necessário. Isso elimina a necessidade de configurações manuais e cria uma experiência fluida, onde a análise acontece sem interrupções ou mudanças de ferramenta.

Como funciona na prática

Prompts sugeridos para começar

Para facilitar o primeiro contato com o novo recurso, o Cost Explorer apresenta prompts sugeridos que contemplam perguntas frequentes sobre custos. Um exemplo é “Mostre meus principais serviços por gasto neste mês”, que oferece uma forma rápida de iniciar a análise. O Amazon Q responde com informações detalhadas enquanto o Cost Explorer atualiza a visualização correspondente, os filtros e os agrupamentos em tempo real.

Perguntas customizadas e conversas contínuas

Além dos prompts sugeridos, usuários podem fazer perguntas personalizadas usando o botão ‘Fazer uma Pergunta’. Isso permite explorar padrões de gastos de forma conversacional, sem restrições. Enquanto investiga custos baseados em dados de uso, o Cost Explorer atualiza automaticamente gráficos e tabelas. Quando o Amazon Q precisa compilar insights de conjuntos de dados adicionais — como informações de preços ou detecção de anomalias — as visualizações aparecem em um novo painel de artefatos do Amazon Q.

A conversa permanece contextualizada ao longo de toda a sessão. Isso significa que é possível passar de uma verificação rápida de custos para uma investigação profunda mantendo o histórico completo da conversa, sem necessidade de alternar entre ferramentas ou perder o contexto da análise.

Disponibilidade e próximos passos

A análise de custos em linguagem natural para o AWS Cost Explorer está disponível hoje em todas as regiões comerciais da AWS, sem cobrança adicional. Para aproveitar o novo recurso, acesse AWS Cost Explorer ou consulte o guia do usuário para instruções detalhadas de uso.

Fonte

AWS Cost Explorer launches Natural Language Query capabilities powered by Amazon Q (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-cost-explorer-natural-language-query/)

Streaming de Respostas do Lambda agora disponível globalmente

A AWS expandiu o suporte ao streaming de respostas do Lambda para todas as suas regiões comerciais, alcançando paridade completa desse recurso em toda sua infraestrutura global. Clientes nas regiões recém-suportadas agora podem utilizar a API InvokeWithResponseStream para transmitir progressivamente as respostas de funções Lambda de volta aos clientes conforme os dados ficam disponíveis.

Como funciona o streaming de respostas

O streaming de respostas permite que funções Lambda enviem respostas parciais aos clientes de forma incremental, em vez de acumular toda a resposta em memória antes de transmiti-la. Essa abordagem traz benefícios significativos para aplicações sensíveis à latência, particularmente na redução do tempo até o primeiro byte (TTFB) — um fator crítico na experiência do usuário.

Casos de uso ideais

Esse recurso é especialmente adequado para aplicações baseadas em grandes modelos de linguagem (LLM), bem como para aplicativos web e mobile. Em cenários assim, os usuários se beneficiam de ver as respostas aparecerem progressivamente na tela, melhorando a percepção de responsividade da aplicação.

Capacidades técnicas

O streaming de respostas da AWS Lambda suporta:

• Payloads de até 200 MB por padrão
• Acesso através da API InvokeWithResponseStream via SDK da AWS suportados
• Integração com Amazon API Gateway através de REST APIs com streaming habilitado
• Runtimes gerenciados do Node.js e runtimes customizados

Considerações de custo

É importante saber que o streaming de respostas gera custos adicionais relacionados à transferência de rede da resposta. A cobrança ocorre com base na quantidade de bytes gerados e transmitidos pela função Lambda, considerando apenas os primeiros 6 MB. Isso permite um controle mais previsível dos custos em aplicações que transmitem grandes volumes de dados.

Próximos passos

Desenvolvedores interessados em implementar streaming de respostas nas funções Lambda podem consultar a documentação técnica do AWS Lambda para obter detalhes de implementação e boas práticas.

Fonte

AWS Lambda expands response streaming support to all commercial AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-lambda-response-streaming/)