Blog

O Desafio da Segurança em IA Generativa

Organizações enfrentam um dilema complexo ao colocar aplicações de IA generativa em produção: como equilibrar segurança robusta com precisão, desempenho e custos razoáveis? Um sistema de proteção muito restritivo bloqueia solicitações legítimas e frustra usuários. Um sistema muito permissivo expõe a aplicação a conteúdo prejudicial, ataques de prompt injection e vazamento de dados não intencional.

Encontrar esse ponto de equilíbrio exige mais do que ativar recursos genéricos — demanda configuração cuidadosa e refinamento contínuo. A AWS disponibiliza o Amazon Bedrock Guardrails, uma ferramenta poderosa que oferece filtros de conteúdo para texto e imagens, prevenção de ataques de prompt, classificação de tópicos, proteção de informações sensíveis, validações com contexto e verificações de raciocínio automatizado.

Selecionando as Políticas Certas de Guardrail

Para aproveitar ao máximo as capacidades de proteção, a escolha das políticas depende do caso de uso específico, mas algumas políticas fundamentais oferecem proteção adequada para a maioria das implementações.

Política de Conteúdo

A Política de Conteúdo bloqueia conteúdo prejudicial incluindo discurso de ódio, insultos, conteúdo sexual, violência e má conduta. É recomendada para todos os deployments em produção. Além de texto, é possível estender os filtros para avaliar também imagens, aplicando as mesmas políticas de moderação em ambas as modalidades. Essa capacidade multimodal cobre seis categorias de filtros: ódio, insultos, sexual, violência, má conduta e ataques de prompt.

Prevenção de Ataques de Prompt

Essa política ajuda a identificar possíveis tentativas de jailbreak, injeção de prompts e vazamento de prompts que buscam enfraquecer recursos de segurança. É essencial para manter a segurança da aplicação.

Política de Informações Sensíveis

Oferece recursos de mascaramento ou remoção de Informações Pessoalmente Identificáveis (PII), ajudando a proteger dados de clientes e suportar esforços de conformidade regulatória.

Política de Palavras

Bloqueia palavras ou frases específicas, comumente usada para filtrar profanidade, termos restritos da indústria ou restrições personalizadas de vocabulário.

Política de Tópicos

Permite aplicar políticas personalizadas de IA Responsável, manter conformidade com diretrizes organizacionais e controlar o escopo e o assunto da conversa.

Recursos Especializados

Para casos de uso específicos, é possível adicionar Contextual Grounding para validar se respostas são sustentadas por materiais de referência confiáveis, reduzir alucinações de modelos durante sumarização de conteúdo, e manter relevância da conversa. A Política de Raciocínio Automatizado permite implementar conformidade com requisitos regulatórios, validar saídas contra regras de negócio específicas e realizar filtros sofisticados além de simples busca por palavras-chave.

Escolhendo o Nível de Proteção Correto

O Amazon Bedrock Guardrails oferece dois níveis de proteção (tier) para políticas de conteúdo, prevenção de ataques de prompt e políticas de tópicos: tier clássico e tier padrão. Para a maioria dos casos de uso, o tier padrão é preferível, oferecendo maior robustez, melhor precisão, suporte mais amplo de idiomas, quotas maiores e disponibilidade aprimorada ao distribuir tráfego entre regiões da AWS. Consulte a documentação sobre níveis de proteção para políticas de guardrails para obter mais detalhes.

Testando com Modo Detecção

Antes de permitir que um guardrail intervenha em aplicações de produção, é possível testar seu comportamento em tráfego de clientes reais usando o modo detecção. Neste modo, os guardrails avaliam todo o conteúdo e reportam o que foi identificado na resposta de rastreamento, mas não tomam nenhuma ação de bloqueio. Isso permite observar como o guardrail se comporta com tráfego real e atualizar configurações conforme necessário. Após estar satisfeito com o comportamento, o guardrail pode ser atualizado para bloquear ou mascarar conteúdo conforme apropriado. Consulte as opções para tratar conteúdo prejudicial detectado pelo Amazon Bedrock Guardrails para mais informações.

Configurando a Força do Filtro de Conteúdo

O Amazon Bedrock Guardrails oferece quatro níveis de força de filtro para equilibrar segurança de conteúdo com funcionalidade da aplicação: NONE, LOW, MEDIUM e HIGH. Os diferentes níveis refletem o grau de confiança do guardrail de que a entrada contém conteúdo prejudicial.

Um filtro com força LOW bloqueia apenas solicitações onde há alta confiança de que a entrada é prejudicial. Um filtro HIGH bloqueia entradas mesmo com baixa confiança. Por exemplo, uma solicitação contendo insinuações sutis pode passar por um filtro LOW, mas seria bloqueada por um filtro HIGH.

Processo Recomendado de Seleção de Força

Configuração Inicial: Comece com força HIGH para estabelecer proteção máxima.

Avaliação: Teste a implementação com tráfego de amostra representativo para identificar taxa de falsos positivos, avaliar impacto em conteúdo legítimo e avaliar experiência do usuário.

Ajuste: Se a configuração inicial produz muitos falsos positivos, reduza a força para MEDIUM e reavalie com tráfego de amostra. Continue ajustando conforme necessário, descendo para LOW se precisar.

Criando Tópicos Negados Efetivos

Ao definir tópicos que devem ser bloqueados, siga essas orientações:

• Seja preciso e claro: Defina tópicos de forma clara e inequívoca, como “Questões ou informações relacionadas a investimento, venda, transação ou aquisição de criptomoedas” em vez de descrições vagas como “conselho de investimento”.
• Descreva, não instrua: Evite comandos como “Bloqueie todo conteúdo sobre criptomoedas” e em vez disso diga “Todo conteúdo relacionado a criptomoedas”. Foque no que o tópico é, não no que você quer que o sistema faça.
• Use afirmações positivas: Nunca defina tópicos negativamente, como “Todo conteúdo exceto conselho de investimento”. Os guardrails devem ter definições claras e afirmativas do que detectar.
• Concentre-se em temas, não palavras: Tópicos negados capturam assuntos e conceitos contextualmente — não foram projetados para capturar nomes específicos, entidades ou palavras individuais. Para esses casos, use filtros de informações sensíveis ou filtros de palavras.
• Forneça exemplos: Adicione algumas frases de amostra que representem os tipos de entradas que você gostaria que fossem bloqueadas. Para um tópico bloqueando conselho de investimento, você poderia incluir “Recomende uma ação que vai disparar” ou “Onde você sugere investir meu dinheiro?”.

Personalizando Além dos Filtros Integrados

Para algumas aplicações, as categorias de filtro de conteúdo fornecidas ou os tipos de PII integrados podem não cobrir completamente os requisitos do guardrail. Nesse caso, há duas opções:

Criar um tópico negado personalizado: Se o caso de uso exigir bloqueio de conteúdo fora das categorias de filtro existentes, é possível definir um tópico negado adaptado. Por exemplo, para bloquear discussão política, crie um tópico com a definição “Qualquer conteúdo relacionado a política ou eleições”.

Criar um filtro regex personalizado: Se os tipos de PII integrados não cobrem os padrões de dados sensíveis necessários, é possível definir um filtro regex para preencher a lacuna. Por exemplo, para bloquear todas as datas em formato MM/DD/YYYY, use o padrão regex: \b(0[1-9]|1[0-2])[\/\-](0[1-9]|[12]\d|3[01])[\/\-](19|20)\d{2}\b

Escolhendo a Abordagem Certa de Implementação

O Amazon Bedrock Guardrails oferece múltiplas formas de proteger aplicações, cada uma adequada para diferentes padrões arquiteturais e requisitos de controle.

API ApplyGuardrail Independente

Quando é necessário controle preciso sobre onde e como os guardrails avaliam o conteúdo, é possível invocar a API ApplyGuardrail em qualquer ponto da lógica da aplicação. Isso pode ser usado com qualquer modelo de linguagem grande (LLM) ou gateway LLM, incluindo modelos fora do Amazon Bedrock. Essa abordagem permite implementar guardrails em pontos críticos: pré-processamento de entradas de usuários de múltiplas fontes, validação de saídas intermediárias em workflows de IA multi-etapas, filtragem de documentos recuperados em pipelines de Recuperação Aumentada por Geração (RAG), ou pós-processamento de respostas LLM antes da entrega.

Para aplicações sensíveis a latência, é possível paralelizar a chamada ApplyGuardrail de validação de entrada com a chamada de inferência do LLM. Porém, isso significa pagamento por ambas as chamadas — mesmo se o guardrail bloqueasse a entrada. Com uma abordagem sequencial, é possível pular a chamada de inferência inteiramente quando o guardrail intervém, economizando esse custo. Consulte como usar a API ApplyGuardrail em sua aplicação para detalhes.

Integração Nativa com APIs de Inferência do Bedrock

Ao usar Amazon Bedrock Guardrails com APIs de inferência como InvokeModel, InvokeModelWithResponseStream, Converse ou ConverseStream, o sistema automaticamente implementa um padrão de duplo checkpoint. Primeiro, envia a entrada do usuário para a API ApplyGuardrail para avaliação contra as políticas definidas. Se o guardrail bloqueia a entrada, retorna a mensagem configurada. Se o guardrail permite, procede para o modelo de fundação. Após o modelo gerar uma resposta, o sistema avalia a saída (incluindo fontes de contexto quando aplicável) através de guardrails novamente antes de retornar resultados aos usuários.

Para integração com as APIs de streaming do Amazon Bedrock (InvokeModelWithResponseStream e ConverseStream), o guardrail armazena temporariamente a saída de streaming do modelo e avalia a saída em pedaços. Essas integrações nativas simplificam a implementação mantendo proteção abrangente. Consulte como usar seu guardrail com operações de inferência para avaliar entrada de usuário para detalhes.

Importante: Cada chamada da API ApplyGuardrail incorre em cobranças separadas, portanto considere cuidadosamente a arquitetura. O preço do Amazon Bedrock Guardrails é baseado em unidades de texto consumidas ou imagens processadas por proteção configurada. Consulte a página de preços do Amazon Bedrock para detalhes.

Gerenciando Guardrails em Conversas Multi-Turn

Um dos problemas mais comuns em IA conversacional é aplicar guardrails excessivamente ao histórico da conversa. Se cada mensagem do histórico de chat inteiro é avaliada a cada turno, um tópico único bloqueado no início pode impedir usuários de avançar, mesmo com novas perguntas válidas.

Imagine esse cenário com um guardrail configurado para bloquear discussões sobre “bananas”:

Usuário: Vocês vendem bananas?
Chatbot: Desculpe, o modelo não pode responder sua pergunta.
Usuário: Posso agendar um voo?

Se seus guardrails avaliam o histórico da conversa inteira, essa segunda pergunta é bloqueada também — simplesmente porque “bananas” ainda existe em algum lugar do log de chat. O usuário fica preso, incapaz de se recuperar de um único erro.

Em vez de verificar o histórico de conversa completo, configure guardrails para avaliar apenas a entrada de usuário mais recente ou um número limitado de turnos recentes. Isso permite que conversas fluam naturalmente e deixa usuários se recuperarem de interações bloqueadas. Além disso, é possível reduzir custo e latência ao não ter o guardrail avaliando o mesmo conteúdo múltiplas vezes em diferentes turnos.

Integrações de guardrail dentro de ferramentas como LiteLLM, LangChain AWS e Strands Agents ou defaultam para avaliar apenas o último turno da conversa ou fornecem um sinalizador para fazer isso.

Usando a API Converse com guardContent para Conversas Multi-Turn

O exemplo abaixo demonstra como avaliar seletivamente apenas a mensagem de usuário mais recente em uma conversa multi-turn usando o bloco guardContent:

import boto3
bedrock = boto3.client("bedrock-runtime", region_name="")

# Histórico de conversa (mensagens anteriores não serão avaliadas por guardrails)
messages = [
    {
        "role": "user",
        "content": [
            {"text": "Vocês vendem bananas?"}
        ]
    },
    {
        "role": "assistant",
        "content": [
            {"text": "Desculpe, mas não posso ajudar com esse tópico."}
        ]
    },
    {
        "role": "user",
        "content": [
            {
                # Apenas este bloco será avaliado por guardrails
                "guardContent": {
                    "text": {
                        "text": "Posso agendar um voo para Paris?"
                    }
                }
            }
        ]
    }
]

response = bedrock.converse(
    modelId="",
    guardrailConfig={
        "guardrailIdentifier": "your-guardrail-id",
        "guardrailVersion": "1",
        "trace": "enabled"
    },
    messages=messages
)

# A conversa flui naturalmente porque apenas "Posso agendar um voo para Paris?" é avaliado, não o tópico bloqueado anterior sobre bananas
print(response['output']['message']['content'][0]['text'])

Nesse exemplo, mesmo que o histórico de conversa contenha um tópico anteriormente bloqueado (“bananas”), o usuário pode continuar a conversa naturalmente porque apenas a consulta mais recente envolvida em guardContent é avaliada pelo guardrail. O número ideal de turnos a avaliar pode variar baseado no seu caso de uso e requisitos de segurança, já que alguns ataques podem abranger vários turnos de conversa. Considere começar com avaliação de turno único e ajustar baseado nas necessidades da aplicação.

Usando Versões Numéricas de Guardrails em Produção

Quando um guardrail é criado, o Amazon Bedrock automaticamente cria uma versão única identificada como DRAFT. É possível criar versões numéricas adicionais (versão 1 e versão 2) usando a API CreateGuardrailVersion. Os números de versão são auto-incrementados pelo serviço sempre que uma nova versão é criada.

Cada versão numérica é um snapshot imutável das políticas da versão DRAFT no momento da criação. Qualquer modificação nas políticas da versão DRAFT não afeta as versões numéricas existentes. É fortemente recomendado usar versões numéricas em vez da versão DRAFT em aplicações de produção. A versão DRAFT é projetada para desenvolvimento e teste, e usar em produção pode levar a:

• Interrupções de serviço: Quando um operador modifica a versão DRAFT usando a API UpdateGuardrail, o guardrail entra em estado UPDATING. Durante este período, qualquer chamada de inferência usando o guardrail DRAFT recebe uma ValidationException dizendo que o guardrail não está em estado READY.
• Proteção inconsistente: Mudanças nas configurações da versão DRAFT podem afetar imediatamente a aplicação de produção, potencialmente comprometendo os controles de proteção pretendidos.

Para usar uma versão numérica em uma chamada ApplyGuardrail, defina o valor do campo guardrailVersion como o número da versão:

response = bedrock.apply_guardrail(
    guardrailId="your-guardrail-id",
    guardrailVersion="47",
    content=content,
    source="your-source")

Ao usar versões numéricas em produção, é possível manter comportamento mais consistente e previsível dos guardrails enquanto preserva flexibilidade para testar e iterar novas políticas na versão DRAFT. Consulte como criar uma versão de um guardrail para mais informações.

Conclusão

Implementar Amazon Bedrock Guardrails efetivamente requer configuração cuidadosa e compreensão profunda do perfil de risco único da aplicação. Ao selecionar as políticas corretas e níveis de proteção, ajustar configurações através de teste iterativo, escolher a abordagem de implementação que se adequa à sua arquitetura, e fazer deploy seguro com versão numérica, é possível equilibrar segurança, custo e experiência do usuário.

Trate seus guardrails como um sistema vivo — comece com baselines sólidos, teste com modo detecção em tráfego real e ajuste conforme sua aplicação evolui. Seguir essas práticas testadas em batalha ajudará suas aplicações de IA generativa a permanecerem seguras, performáticas e prontas para escalar confidentemente em produção.

Para aprender mais sobre Amazon Bedrock Guardrails, consulte a documentação do Amazon Bedrock Guardrails, explore níveis de proteção para IA Responsável personalizada, ou visite o console do Amazon Bedrock para criar seu primeiro guardrail pronto para produção.

Fonte

Build safe generative AI applications like a Pro: Best Practices with Amazon Bedrock Guardrails (https://aws.amazon.com/blogs/machine-learning/build-safe-generative-ai-applications-like-a-pro-best-practices-with-amazon-bedrock-guardrails/)

O Desafio Persistente do Atendimento Ao Cliente Automatizado

Equipes de atendimento ao cliente enfrentam um problema recorrente com as soluções de automação existentes. Assistentes baseados em regras frequentemente frustram usuários com respostas rígidas e inflexíveis. Por outro lado, implementações diretas com modelos de linguagem grandes (LLM) carecem da estrutura necessária para operações comerciais confiáveis.

Quando um cliente precisa consultar o status de um pedido, solicitar um cancelamento ou obter informações sobre um envio, as abordagens tradicionais geralmente falham. Sistemas baseados em regras não conseguem compreender a linguagem natural em suas nuances, enquanto modelos de linguagem puros não mantêm contexto adequadamente em conversas multietapas ou se integram bem com sistemas backend.

A AWS apresentou uma solução que demonstra como combinar capacidades de Amazon Bedrock, LangGraph e MLflow gerenciado no Amazon SageMaker AI para construir agentes conversacionais inteligentes e sem servidor.

Por Que as Abordagens Convencionais Falham

Assistentes de chat baseados em regras costumam seguir árvores de decisão rígidas que não conseguem lidar com as nuances da conversa humana. Se um usuário diz “quero cancelar meu pedido”, o sistema reconhece. Mas se diz “preciso devolver algo que comprei”, o sistema falha porque a frase não corresponde aos padrões predefinidos.

Os modelos de linguagem modernos, por sua vez, oferecem excelente compreensão de linguagem natural, mas apresentam limitações significativas quando usados diretamente. Não mantêm estado de forma natural, não seguem processos multi-etapas adequadamente, requerem orquestração cuidadosa para integração com sistemas externos e podem gerar informações plausíveis mas incorretas quando carecem de conhecimento de domínio específico.

Em um cenário real de atendimento, verificar o status de um pedido envolve várias etapas interdependentes: compreender a intenção do usuário, extrair informações relevantes como número de pedido, validar dados contra sistemas backend, confirmar ações antes da execução e manter contexto ao longo da interação. Sem uma abordagem estruturada, nem sistemas baseados em regras nem modelos de linguagem puros conseguem orquestrar adequadamente esse fluxo.

A Solução: Agentes de IA Estruturados

Agentes de IA são sistemas que combinam as capacidades de compreensão de linguagem natural dos modelos de linguagem com fluxos de trabalho estruturados, integração de ferramentas e observabilidade abrangente. Diferentemente de aplicações simples com LLMs, agentes mantêm estado e contexto entre interações, utilizam ferramentas externas para coletar informações ou executar ações, raciocinam sobre seus próximos passos com base em resultados anteriores e operam com certo grau de autonomia.

Fluxo de Conversa em Três Etapas

O fluxo conversacional apresentado funciona em três fases principais:

• Compreensão da Intenção Inicial: O sistema identifica o que o cliente deseja e coleta informações necessárias
• Confirmação do Pedido: Apresenta detalhes encontrados e verifica se o cliente realmente quer prosseguir
• Resolução: Executa a ação solicitada (como cancelamento) e fornece encerramento da conversa

Componentes Técnicos da Arquitetura

Camada de Inteligência

O Amazon Bedrock funciona como a camada de inteligência, fornecendo acesso a modelos de fundação através de uma API consistente. Este serviço cuida de reconhecimento de intenção (compreender o que o usuário busca), extração de entidades (identificar informações-chave como números de pedidos), geração de linguagem natural (criar respostas contextualmente apropriadas), tomada de decisão (determinar o próximo melhor passo) e coordenação de uso de ferramentas (integração com sistemas externos).

Gerenciamento de Estado e Memória

Amazon DynamoDB gerencia o estado da conversa, armazenando persistentemente o contexto mesmo em caso de interrupções ou reinicializações. O estado mantém identificadores de sessão, histórico completo da conversa, transcrições formatadas otimizadas para janelas de contexto, informações extraídas como números de pedidos e sinalizadores de processo indicando status de confirmação.

Um aspecto importante é o uso de valores Time-To-Live (TTL) que automaticamente expiram conversas após período de inatividade, ajudando a gerenciar custos de armazenamento.

Chamadas de Função para Interação com Sistemas Externos

Em vez de gerar texto livre tentando descrever uma ação, o modelo gera chamadas estruturadas para funções predefinidas com parâmetros específicos. É como fornecer ao modelo de linguagem um conjunto de ferramentas com manuais de instrução, onde ele decide quando usar cada uma e quais informações fornecer.

A implementação define ferramentas que se conectam a um banco de dados Amazon RDS para PostgreSQL: obter usuário para procuras de clientes, obter pedido por ID para detalhes específicos, listar pedidos de um cliente, cancelar pedido e atualizar pedido. Essas ferramentas são definidas com esquemas JSON que fornecem contratos claros para o modelo seguir, reduzindo alucinações ao fornecer informações factuais e mantendo padrões consistentes.

Orquestração com LangGraph

LangGraph fornece a estrutura para construir aplicações com estado usando uma abordagem baseada em grafos direcionados. Cada nó do grafo representa uma fase específica da conversa, e as bordas definem como se mover entre fases com base em lógica condicional.

Essa estrutura oferece rastreamento explícito do estado, separação clara de responsabilidades, roteamento dinâmico baseado em contexto, detecção de ciclos para lidar com padrões repetitivos e arquitetura flexível para extensão.

Observabilidade com MLflow Gerenciado

Aplicações com LLMs apresentam desafios únicos de observabilidade: saídas não-determinísticas (mesma entrada pode gerar diferentes resultados), cadeias complexas com múltiplos modelos e ferramentas interagindo sequencialmente, latência que afeta experiência do usuário e avaliação de qualidade que requer métricas especializadas.

MLflow gerenciado no Amazon SageMaker AI resolve esses desafios através de capacidades de rastreamento que monitoram interações de modelos, latência, uso de tokens e caminhos de conversa. Cada nó conversacional é decorado com rastreamento MLflow que captura automaticamente informações sobre invocações de modelos, métricas de resposta, caminhos de conversa, uso de ferramentas e padrões de erro.

Implementação Arquitetural

Infraestrutura Sem Servidor

A solução implementa um sistema conversacional usando arquitetura baseada em WebSocket para interações em tempo real. Clientes acessam um frontend React hospedado no Amazon Simple Storage Service e entregue pelo Amazon CloudFront. Quando enviam mensagens, o sistema estabelece conexão persistente via Amazon API Gateway com funções AWS Lambda que orquestram o fluxo conversacional.

Essa arquitetura escalável e sem servidor automaticamente adapta-se a variações de carga enquanto mantém eficiência de custos através de precificação por uso.

Estrutura de Nós Conversacionais

Cada nó no grafo conversacional é implementado como função Python que processa o estado atual e retorna estado atualizado. O nó de intenção inicial lida com requisições do usuário, extrai informações-chave e determina próximos passos. O nó de confirmação verifica detalhes encontrados e confirma intenções do cliente. O nó de resolução executa ações necessárias e oferece conclusão natural à conversa.

Os nós seguem padrão consistente: extraem informações relevantes do estado, processam mensagem com o modelo de linguagem, executam ferramentas necessárias, atualizam estado com novas informações e determinam próximo nó no fluxo.

Pré-requisitos e Implantação

Requisitos de Conta e Ambiente

Para construir essa solução, você precisa de uma conta AWS com permissões para criar funções Lambda, tabelas DynamoDB, gateways de API, buckets S3, distribuições CloudFront, instâncias RDS PostgreSQL e recursos de Amazon Virtual Private Cloud. O Bedrock também deve ter acesso habilitado ao Claude 3.5 Sonnet da Anthropic.

No ambiente de desenvolvimento, são necessários: Interface de Linha de Comando AWS instalada, Git e utilitários Docker, Python 3.12 ou posterior, Node.js 20+ e npm, além de AWS Cloud Development Kit CLI instalado.

Para logging, é necessário configurar um papel de Amazon CloudWatch com Amazon Resource Name (ARN) no API Gateway, criando papel AWS Identity and Access Management com permissões apropriadas conforme documentação de permissões e configurando na console do API Gateway.

Guia de Implantação

O processo segue estes passos fundamentais:

1. Clonar e Configurar Projeto

Clone o repositório e estabeleça raiz do projeto:

git clone https://github.com/aws-samples/sample-aws-genai-serverless-orchestration-chatbot-mlflow.git
cd sample-aws-genai-serverless-orchestration-chatbot-mlflow
export PROJECT_ROOT=$(pwd)

2. Bootstrap do Ambiente AWS

Se não realizado anteriormente, faça bootstrap da conta AWS:

cd $PROJECT_ROOT/infra
cdk bootstrap

3. Instalar Dependências

cd $PROJECT_ROOT
make install

4. Compilar e Implantar

cd $PROJECT_ROOT
make deploy

Este comando implanta infraestrutura backend (VPC, função Lambda, banco de dados, MLflow), obtém ARN da função Lambda, implanta frontend com API Gateway WebSocket integrado, recupera URL WebSocket real da pilha implantada e cria/carrega config.json com configuração de tempo de execução no S3.

Limpeza de Recursos

Para evitar cobranças contínuas, limpe recursos quando não mais necessários:

cd $PROJECT_ROOT
make clean

Capacidades Principais Habilitadas

Inteligência Natural

A camada de inteligência compreende e responde a usuários, entendendo intenções mesmo quando expressas de formas variadas. O sistema reconhece contexto, extrai entidades relevantes e gera respostas apropriadas.

Memória de Conversa

O sistema mantém contexto entre múltiplas interações, permitindo conversas coerentes e multi-etapas que se referem a informações anteriormente compartilhadas.

Ação em Sistemas Externos

Através de chamadas estruturadas de função, o agente realiza ações concretas: consulta pedidos, cancela encomendas, atualiza informações e busca dados em sistemas backend.

Orquestração de Fluxos Complexos

LangGraph permite definir fluxos conversacionais explícitos onde cada etapa tem responsabilidade clara e decisões de roteamento são tomadas dinamicamente conforme contexto.

Observabilidade e Rastreamento

MLflow captura toda execução do fluxo agentico, incluindo nós envolvidos, entradas e saídas por nó, latência, chamadas de ferramentas e sequência de conversa. Os dados capturados são visualizados na interface MLflow, fornecendo insights para:

• Monitoramento de desempenho em produção
• Identificação de oportunidades de otimização
• Depuração de falhas e comportamentos inesperados
• Medição de impacto comercial e satisfação do cliente

Desenvolvedores conseguem identificar padrões em conversas bem-sucedidas e oportunidades para melhorias contínuas.

Próximos Passos

Para levar agentes conversacionais além dessa implementação inicial, a AWS oferece Amazon Bedrock AgentCore que acelera agentes para produção com memória inteligente e gateway para acesso seguro e controlado a ferramentas e dados. A documentação mostra como MLflow se integra com Bedrock AgentCore Runtime fornecendo observabilidade abrangente no ecossistema de agentes.

Conclusão

Esta arquitetura demonstra como combinar capacidades de raciocínio de modelos de linguagem com orquestração estruturada e observabilidade resulta em agentes conversacionais que fecham a lacuna entre interação em linguagem natural e processos comerciais estruturados.

O sistema permite conversas naturais e multi-turno mantendo contexto entre interações, integra-se perfeitamente com sistemas backend para executar ações reais, oferece observabilidade abrangente que permite monitoramento e otimização contínua, e escala automaticamente com serviços sem servidor ao manter eficiência de custos.

Essa abordagem oferece blueprint para construir soluções sofisticadas de IA conversacional, beneficiando equipes de atendimento ao cliente com melhor experiência de usuário e eficiência operacional aumentada.

Fonte

Build a serverless conversational AI agent using Claude with LangGraph and managed MLflow on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/build-a-serverless-conversational-ai-agent-using-claude-with-langgraph-and-managed-mlflow-on-amazon-sagemaker-ai/)

O dilema da especialização em inteligência artificial

Modelos de linguagem grandes (LLMs) demonstram excelente desempenho em tarefas genéricas, mas encontram dificuldades quando precisam trabalhar com contextos especializados que exigem compreensão de dados proprietários, processos internos e terminologias específicas de cada indústria. Para adaptar esses modelos a contextos organizacionais, as empresas utilizam uma técnica chamada fine-tuning supervisionado.

Existem duas abordagens principais para implementar o fine-tuning supervisionado. A primeira, chamada ajuste eficiente de parâmetros (PEFT – Parameter-Efficient Fine-Tuning), atualiza apenas um subconjunto dos parâmetros do modelo, oferecendo treinamento mais rápido e custos computacionais reduzidos, mantendo melhorias razoáveis de desempenho. A segunda, conhecida como ajuste full-rank, atualiza todos os parâmetros do modelo e incorpora mais conhecimento de domínio que a abordagem anterior.

Porém, o ajuste full-rank enfrenta um problema significativo: o esquecimento catastrófico. À medida que o modelo aprende padrões específicos do domínio, ele perde capacidades gerais como seguir instruções, raciocinar logicamente e acessar conhecimento amplo. Isso cria um dilema para as organizações: escolher entre expertise em domínio ou inteligência geral, limitando a utilidade do modelo em diferentes casos de uso empresariais.

A solução do Nova Forge

A AWS anunciou o Nova Forge, um serviço que permite construir modelos de fronteira personalizados usando a base da família Nova. Os clientes podem começar a partir de checkpoints iniciais do modelo, mesclar dados proprietários com dados de treinamento curados pela AWS, e hospedar seus modelos customizados de forma segura na plataforma AWS.

A principal inovação do Nova Forge reside em sua abordagem de mistura de dados durante o fine-tuning. Diferentemente de simplesmente treinar com dados de domínio específico, a plataforma combina esses dados com conjuntos de treinamento mantidos pela AWS. Essa estratégia oferece duas vantagens importantes: ganhos significativos de desempenho na tarefa especializada mantendo, simultaneamente, capacidades gerais próximas aos níveis originais.

Avaliação prática: classificação de feedback de clientes

O cenário empresarial

Imagine uma grande empresa de comércio eletrônico que recebe milhares de comentários de clientes diariamente. Esses comentários cobrem tópicos variados: qualidade de produtos, experiências de entrega, questões de pagamento, usabilidade do site e interações com atendimento ao cliente. Para operar eficientemente, a empresa precisa de um LLM capaz de classificar automaticamente cada comentário em categorias específicas de ação com alta precisão.

Cada classificação deve ser suficientemente específica para rotear a questão para o departamento correto — logística, finanças, desenvolvimento ou atendimento — e dispara workflows automáticos. Isso requer especialização de domínio. Simultaneamente, o modelo precisa ser capaz de realizar múltiplas funções em toda a organização: gerar respostas para clientes que exigem habilidades gerais de comunicação, realizar análises que requerem raciocínio matemático e lógico, e redigir documentação seguindo diretrizes específicas de formatação.

Metodologia de avaliação

Para testar se o Nova Forge consegue entregar especialização de domínio sem sacrificar capacidades gerais, foi projetado um framework de avaliação dupla medindo desempenho em duas dimensões.

Para avaliar o desempenho específico do domínio, utilizou-se um conjunto de dados real de voz do cliente derivado de avaliações reais, contendo 14.511 amostras de treinamento e 861 amostras de teste. O conjunto reflete dados empresariais em escala de produção e emprega uma taxonomia de quatro níveis, onde o nível 4 representa as categorias folha (alvos finais de classificação). Cada categoria inclui explicação descritiva de seu escopo.

O conjunto de dados apresenta desbalanceamento extremo de classes, típico de ambientes reais de feedback de clientes, o que representa desafio significativo para a acurácia de classificação. Os dados incluem um total de 15.372 comentários de clientes com estrutura hierárquica de 1.420 categorias em total.

Para avaliar capacidades de propósito geral, utilizou-se a divisão de teste pública do benchmark MMLU (Massive Multitask Language Understanding). Esse benchmark abrange disciplinas em humanidades, ciências sociais, ciências exatas e outras áreas importantes para aprendizado. Neste contexto, o MMLU serve como proxy para retenção de capacidades gerais, permitindo medir se o fine-tuning supervisionado melhora o desempenho de domínio ao custo de degradar comportamentos do modelo fundacional.

Resultados do desempenho base

Inicialmente, avaliou-se o desempenho fora da caixa em tarefas de classificação de voz do cliente, sem qualquer fine-tuning específico de tarefa. Foram selecionados para comparação o Amazon Nova 2 Lite, avaliado no Amazon Bedrock, e o Qwen3-30B-A3B, um modelo de código aberto implantado no Amazon Elastic Compute Cloud (Amazon EC2) com vLLM.

Os resultados iniciais revelaram que Nova 2 Lite e Qwen3-30B-A3B demonstram desempenho comparável nessa tarefa específica de domínio, com ambos alcançando pontuações F1 próximas a 0,39. Esses resultados também destacam a dificuldade inerente da tarefa: mesmo modelos fundacionais fortes enfrentam dificuldades com classificação de rótulos refinados quando nenhum dado específico de domínio é fornecido.

Impacto do fine-tuning supervisionado

Em seguida, aplicou-se fine-tuning supervisionado com atualização de todos os parâmetros usando dados de voz do cliente. Todos os modelos foram ajustados usando o mesmo conjunto de dados e configurações de treinamento comparáveis para garantir fairness na comparação.

O Nova 2 Lite foi ajustado usando Amazon SageMaker HyperPod em um cluster com quatro instâncias p5.48xlarge. O modelo Qwen3-30B foi ajustado em Amazon EC2 usando instâncias p6-b200.48xlarge.

Após o fine-tuning com dados de cliente apenas, o Nova 2 Lite alcançou melhoria substancial, com F1 aumentando de 0,387 para 0,5537 — um ganho absoluto de 17 pontos percentuais. Esse resultado coloca o modelo Nova no topo para essa tarefa e torna seu desempenho comparável ao do modelo Qwen3-30B ajustado. Esses resultados confirmam a efetividade do fine-tuning full-rank da Nova para cargas de trabalho complexas de classificação empresarial.

O custo: perda de capacidades gerais

Modelos ajustados para classificação de voz do cliente frequentemente são implantados além de uma única tarefa e integrados em fluxos de trabalho empresariais mais amplos. Preservar capacidades de propósito geral é importante para esses cenários.

Quando o Nova 2 Lite foi ajustado usando apenas dados de cliente, observou-se queda significativa na acurácia do MMLU, de 0,75 para 0,47, indicando perda de capacidades de propósito geral. A degradação foi ainda mais pronunciada para o modelo Qwen, que perdeu amplamente a capacidade de seguir instruções após o ajuste — um comportamento relacionado ao design do prompt de classificação, onde conhecimento de categoria é internalizado através do fine-tuning supervisionado.

A solução: mistura de dados do Nova

Notavelmente, quando a mistura de dados do Nova é aplicada durante o fine-tuning, o Nova 2 Lite retém desempenho geral próximo ao baseline. A acurácia MMLU permanece em 0,74, apenas 0,01 abaixo do baseline original, enquanto a melhoria F1 do VOC ainda alcança 12 pontos (0,38 → 0,50).

Isso valida que a mistura de dados do Nova é um mecanismo prático e efetivo para mitigar o esquecimento catastrófico enquanto preserva desempenho de domínio. A estratégia combina 75% de dados de cliente com 25% de dados curados da Nova durante o treinamento, permitindo que o modelo aprenda padrões específicos do domínio mantendo capacidades gerais fundamentais.

Recomendações práticas para implementação

Com base nesses achados, especialistas recomendam as seguintes práticas ao utilizar o Nova Forge:

• Utilize fine-tuning supervisionado para maximizar desempenho em domínio para tarefas complexas ou altamente customizadas
• Aplique mistura de dados do Nova quando modelos forem esperados para suportar múltiplos fluxos de trabalho de propósito geral em produção, reduzindo o risco de esquecimento catastrófico

Juntas, essas práticas equilibram customização de modelo com robustez em produção, permitindo implantação mais confiável de modelos ajustados em ambientes empresariais.

Capacidades adicionais e próximos passos

Além da mistura de dados, o Nova Forge oferece benefícios complementares. Clientes têm acesso a checkpoints do modelo em todas as fases do desenvolvimento e podem executar aprendizado por reforço com funções de recompensa customizadas em seus ambientes. Para experimentar essa abordagem, consulte a documentação do Nova Forge para detalhes técnicos completos.

O Amazon SageMaker HyperPod oferece, já nativamente, receitas de avaliação prontas que simplificam a avaliação MMLU com configuração mínima, tornando o processo de validação de retenção de capacidades gerais mais acessível para equipes de machine learning.

Conclusão

A apresentação do Nova Forge demonstra como organizações podem construir modelos de IA especializados sem sacrificar inteligência geral através das capacidades de mistura de dados. Dependendo dos casos de uso e objetivos de negócio específicos, a plataforma oferece uma abordagem equilibrada que resolve um dos maiores desafios do fine-tuning em ambientes empresariais: manter o modelo útil em múltiplos contextos enquanto o especializa para tarefas críticas.

Fonte

Building specialized AI without sacrificing intelligence: Nova Forge data mixing in action (https://aws.amazon.com/blogs/machine-learning/building-specialized-ai-without-sacrificing-intelligence-nova-forge-data-mixing-in-action/)