Author: Make.com Service User

O problema: busca semântica não é suficiente sozinha

Imagine um agente de suporte ao cliente que recebe a consulta “problemas de cobrança” e devolve uma mistura de tickets técnicos, conversas de vendas com reclamações de recibo e disputas de faturamento — tudo junto. Esse é o limite da busca por similaridade semântica quando agentes acumulam semanas de histórico de interações: o sistema encontra tudo que é semanticamente próximo, mas não consegue filtrar pelo que realmente importa, como tipo de problema, status ou período de tempo.

O Amazon Bedrock AgentCore Memory é um serviço gerenciado de memória que dá aos agentes de IA a capacidade de lembrar e recuperar informações entre conversas. Ele organiza os registros de memória em namespaces que definem escopos isolados — como clients/client-123 — garantindo que os dados de cada entidade fiquem separados. Para entender mais sobre organização de namespaces, a AWS publicou o post Organizando a memória de agentes em escala: padrões de design de namespace no AgentCore Memory.

À medida que as memórias crescem, sinais relevantes se perdem em resultados semanticamente similares, mas contextualmente irrelevantes. O isolamento por namespace sozinho não resolve isso. A filtragem por metadados fecha essa lacuna: é possível aplicar filtros baseados em atributos de negócio — como prioridade, departamento ou intervalo de tempo — antes que a busca semântica seja executada.

Em avaliações realizadas com um conjunto de 151 perguntas baseado em um benchmark de memória de longo prazo (no estilo LoCoMo, com múltiplas sessões de conversa), a precisão geral nas respostas subiu de 40% para 64% com a filtragem por metadados habilitada. Para perguntas que dependem de fronteiras contextuais — como buscas por período de tempo, filtragem por prioridade ou escopo por departamento — o ganho foi ainda maior: de 16% para 69%.

Como namespaces e metadados se complementam

O AgentCore Memory usa namespaces para organizar e isolar memórias ao longo das fronteiras das entidades primárias. O namespace define quem é o dono dos dados — por exemplo, patients/patient-456. Já os metadados lidam com o sub-agrupamento dentro dessas fronteiras: a categoria, o status de resolução, a data, a prioridade e as tags.

Em ambientes multi-tenant, o padrão fica claro: os namespaces já fornecem separação completa de dados entre tenants. Dentro do namespace de cada tenant, os agentes ainda precisam filtrar por tipo de ticket antes de buscar padrões de resolução. Os namespaces respondem ao quem; os metadados respondem ao o quê, quando e quão urgente.

Como os metadados funcionam no AgentCore Memory

Os metadados operam tanto na memória de curto prazo quanto na de longo prazo, seguindo um ciclo de vida em três fases: configuração, ingestão e recuperação.

Na memória de curto prazo, é possível anexar pares de chave-valor baseados em strings aos eventos, marcando interações com informações contextuais que não fazem parte da conversa em si, mas são críticas para recuperação posterior. Essas tags são carregadas para a memória de longo prazo durante a extração e consolidação, onde se tornam dimensões filtráveis.

Fase 1: Configuração

Ao criar um recurso de memória, é necessário declarar quais chaves de metadados serão indexadas para filtragem e recuperação rápida. As chaves indexadas são armazenadas em um formato otimizado para filtragem de consultas, enquanto as chaves não indexadas ficam armazenadas junto aos registros de memória apenas para fins informativos. O exemplo a seguir cria um recurso de memória de suporte ao cliente com configuração de metadados:

response = agentcore_client.create_memory(
    name="CustomerSupportMemory",
    eventExpiryDuration=30,
    indexedKeys=[
        {"key": "priority", "type": "STRING"},
        {"key": "agent_type", "type": "STRING"},
        {"key": "channel", "type": "STRING"},
        {"key": "ticket_id", "type": "STRING"}
    ],
    memoryStrategies=[{
        "semanticMemoryStrategy": {
            "name": "SupportSemanticStrategy",
            "description": "Captures support interaction details",
            "namespaces": ["support/{actorId}"],
            "memoryRecordSchema": {
                "metadataSchema": [
                    {
                        "key": "priority",
                        "type": "STRING",
                        "extractionType": "STRICTLY_CONSISTENT",
                        "extractionConfig": {
                            "llmExtractionConfig": {
                                "definition": "Issue priority level based on customer impact.",
                                "llmExtractionInstruction": "LATEST_VALUE",
                                "validation": {
                                    "stringValidation": {
                                        "allowedValues": ["critical", "high", "medium", "low"]
                                    }
                                }
                            }
                        }
                    },
                    {
                        "key": "agent_type",
                        "type": "STRING",
                        "extractionType": "STRICTLY_CONSISTENT",
                        "extractionConfig": {
                            "llmExtractionConfig": {
                                "definition": "Support agent classification.",
                                "llmExtractionInstruction": "Prefer the most specialized agent type. Hierarchy: specialist > tier3 > tier2 > tier1 > bot."
                            }
                        }
                    },
                    {
                        "key": "sentiment",
                        "type": "STRING",
                        "extractionType": "STRICTLY_CONSISTENT",
                        "extractionConfig": {
                            "llmExtractionConfig": {
                                "definition": "Customer sentiment during the interaction.",
                                "llmExtractionInstruction": "Classify the overall customer sentiment based on tone and language used.",
                                "validation": {
                                    "stringValidation": {
                                        "allowedValues": ["positive", "neutral", "negative", "frustrated"]
                                    }
                                }
                            }
                        }
                    }
                ]
            }
        }
    }]
)

Cada entrada do schema tem um campo definition, que descreve o que o campo representa, e um llmExtractionInstruction, que fornece orientação adicional de extração e comportamento de resolução de conflitos ao Modelo de Linguagem de Grande Escala (LLM). A operação embutida LATEST_VALUE fornece resolução baseada em recência, enquanto instruções personalizadas em linguagem natural tratam lógicas específicas do domínio. O campo opcional validation restringe os valores extraídos — como allowedValues para STRING, maxItems para STRINGLIST, ou mínimo-máximo para NUMBER.

Um ponto importante: ticket_id é declarado como chave indexada no nível da memória, mas não está incluído no memoryRecordSchema da estratégia. Isso significa que essa chave não será populada nos registros de memória extraídos. Somente chaves definidas no schema da estratégia aparecem nos registros após a extração. Para mais detalhes sobre as restrições de configuração, consulte a documentação do AgentCore Memory.

Além das chaves configuradas, a filtragem temporal está disponível por meio dos campos x-amz-agentcore-memory-createdAt e x-amz-agentcore-memory-updatedAt, gerados automaticamente pelo sistema, que suportam os operadores BEFORE e AFTER sem exigir que você declare chaves de data/hora indexadas.

Extração determinística com STRICTLY_CONSISTENT

Algumas chaves de metadados são classificadores organizacionais — como department, compliance_level ou interaction_type — cujos valores a aplicação já conhece no momento da criação do evento. Para esses casos, a extração via LLM introduz variabilidade indesejada: a mesma conversa pode gerar "eng" em um registro e "Engineering" em outro.

O AgentCore Memory resolve isso com o tipo de extração STRICTLY_CONSISTENT. Quando uma chave é configurada dessa forma, o valor fornecido no evento é propagado sem alteração através da extração e consolidação — o LLM não é consultado para essa chave. Além disso, eventos com os mesmos valores determinísticos são sempre extraídos juntos e isolados de eventos com valores diferentes, eliminando ambiguidade. A consolidação respeita a mesma separação: um registro com department: "billing" não será mesclado com um de department: "engineering", por mais similar que seja o conteúdo.

Esse mecanismo é ideal para isolamento de conformidade (registros HIPAA não se misturam com registros padrão), roteamento organizacional e qualquer cenário em que o valor seja conhecido no momento do evento e precise ser preservado exatamente nos registros resultantes. O AgentCore Memory suporta até três chaves STRICTLY_CONSISTENT por estratégia, e cada uma consome um dos dez slots de chaves indexadas do recurso de memória — chaves indexadas não podem ser removidas depois de adicionadas.

Fase 2: Ingestão

Os metadados entram no sistema por dois caminhos. O caminho orientado a eventos anexa metadados aos eventos, e o AgentCore Memory os propaga automaticamente pela extração e consolidação para os registros de memória de longo prazo:

# Initial contact event
agentcore_client.create_event(
    memoryId="mem-support-abc123",
    actorId="customer-123",
    sessionId="session-001",
    eventTimestamp="2024-01-23T10:00:00Z",
    payload=[{
        "conversational": {
            "role": "USER",
            "content": {"text": "I have a question about my bill"}
        }
    }],
    metadata={
        "priority": {"stringValue": "medium"},
        "channel": {"stringValue": "email"},
        "ticket_id": {"stringValue": "TKT-5001"}
    }
)

Quando múltiplos eventos em uma sessão carregam valores diferentes para a mesma chave, o LLM resolve os conflitos usando o llmExtractionInstruction definido no schema. Por exemplo, se um evento posterior escalar a prioridade de "medium" para "high", a instrução LATEST_VALUE mantém o valor mais recente.

Vale destacar que os metadados do evento não são estritamente necessários para que as chaves do schema produzam valores. Quando uma chave do schema não tem metadados correspondentes nos eventos de origem, o LLM deriva o valor diretamente do conteúdo da conversa, usando a definition e o llmExtractionInstruction da chave. As regras de validação ainda se aplicam: a saída do LLM é restringida aos allowedValues declarados, independentemente de o valor ter vindo de metadados do evento ou de inferência de conteúdo.

O caminho direto de escrita — via BatchCreateMemoryRecords e BatchUpdateMemoryRecords — ignora a extração por completo. Quando memoryStrategyId é fornecido em cada registro, o serviço filtra os metadados de entrada de acordo com o schema daquela estratégia, descartando silenciosamente chaves não definidas. Quando omitido, os metadados do payload são armazenados como estão — mas apenas chaves indexadas são filtráveis.

Fase 3: Recuperação

Com os metadados indexados e populados nos registros de memória, é possível combinar busca semântica com filtros de metadados para refinar os resultados. O AgentCore Memory usa uma arquitetura de pré-filtragem: os filtros de metadados são aplicados antes da busca por similaridade vetorial. Isso reduz o conjunto de candidatos primeiro, para que a busca K-Vizinhos Mais Próximos (KNN) opere em um subconjunto menor e mais relevante:

results = agentcore_client.retrieve_memory_records(
    memoryId="mem-support-abc123",
    namespace="support/customer-123",
    searchCriteria={
        "searchQuery": "billing issues",
        "topK": 10,
        "metadataFilters": [{
            "left": {"metadataKey": "priority"},
            "operator": "EQUALS_TO",
            "right": {"metadataValue": {"stringValue": "high"}}
        }, {
            "left": {"metadataKey": "x-amz-agentcore-memory-createdAt"},
            "operator": "AFTER",
            "right": {"metadataValue": {"dateTimeValue": "2026-01-01T00:00:00Z"}}
        }]
    }
)

O AgentCore Memory disponibiliza múltiplos operadores para cobrir padrões comuns de consulta. Para recuperação sem busca semântica, o ListMemoryRecords oferece filtragem por metadados para enumerar registros que atendam a critérios específicos — por exemplo, listar registros de alta prioridade criados após uma determinada data.

Nos experimentos da AWS, consultas com restrições de tempo mostraram os maiores ganhos com a filtragem por metadados. A filtragem estruturada com os operadores BEFORE e AFTER converte a busca temporal em uma operação determinística de índice, evitando ambiguidades da busca semântica.

Casos de uso empresariais

Aplicações SaaS multi-tenant

Em uma empresa SaaS com assistentes de IA para múltiplos clientes corporativos, os namespaces já fornecem isolamento primário de tenants. Os metadados adicionam filtragem refinada dentro dessas fronteiras — por segmento de cliente, departamento ou nível de assinatura. Por exemplo, um tenant de nível enterprise pode obter recuperação completa do histórico, enquanto um tenant de nível inicial tem a recuperação restrita a memórias recentes por meio de filtros AFTER no timestamp do sistema.

Saúde e domínios com conformidade regulatória

Em um agente de saúde que gerencia interações de pacientes em múltiplos departamentos, uma busca ampla por “histórico de medicação” retorna resultados de cardiologia, endocrinologia e clínica geral ao mesmo tempo. Indexando chaves como department, record_type e symptoms, o agente consegue restringir a recuperação a dimensões clínicas específicas. O operador CONTAINS em uma chave do tipo STRINGLIST verifica se a lista inclui o valor especificado, permitindo escopo por indicadores clínicos. Para conformidade, a filtragem por metadados ajuda a atender requisitos como HIPAA (isolamento por departamento), GDPR (identificação de registros fora da janela de retenção) e SOC 2 (trilha verificável de escopo correto na recuperação).

Suporte ao cliente com roteamento por prioridade

Em organizações de suporte que lidam com milhares de tickets, os metadados suportam padrões de recuperação como “encontre memórias de cobrança de alta prioridade dos últimos 30 dias”, combinando filtros de metadados personalizados com filtros de timestamp do sistema. À medida que tickets escalam de baixo para crítico, as regras de mesclagem mantêm os metadados nos registros consolidados alinhados com o estado de escalação mais recente.

Serviços financeiros e precisão temporal

Dados financeiros são inerentemente sensíveis ao tempo. Uma consulta sobre “discussões de portfólio do terceiro trimestre” deve retornar registros específicos daquele trimestre. Um agente de gestão de patrimônio pode combinar filtragem DATETIME com metadados personalizados para delimitar a recuperação com precisão, evitando ruído de outras classes de ativos e períodos de tempo.

Sistemas multi-agente e coordenação de memória

Em fluxos de trabalho com múltiplos agentes, saber qual agente criou uma memória é essencial para confiança, depuração e roteamento. Indexando chaves como source_agent, agent_role e workflow_step, um agente supervisor pode filtrar memórias armazenadas por um agente específico. Num pipeline com bot de triagem, agente de nível 1 e especialista, os metadados controlam quais memórias cada agente recupera — o especialista filtra por workflow_step: "triage" para entender a classificação inicial, evitando trabalho duplicado.

Evolução do schema de metadados

O AgentCore Memory suporta evolução de schema por um modelo apenas-aditivo. É possível adicionar novas chaves de metadados indexadas a um recurso de memória existente:

agentcore_client.update_memory(
    memoryId="mem-support-abc123",
    addIndexedKeys=[
        {"metadataKey": "customer_segment", "metadataValueType": "STRING"}
    ]
)

Novas chaves ficam disponíveis imediatamente para eventos e registros de memória futuros. Registros existentes não recebem o novo campo retroativamente, mas à medida que memórias antigas passam por consolidação com as mais novas, elas naturalmente adquirem os novos metadados. Não é possível remover uma chave indexada previamente adicionada.

Boas práticas

• Comece pelas dimensões que seus agentes realmente precisam filtrar. Evite indexar todos os campos possíveis de antemão. Cada campo indexado consome um dos slots disponíveis e adiciona custo em ambas as direções: mais trabalho por escrita durante a ingestão e compactação de consulta nas leituras. Comece com três a cinco chaves que impactam diretamente a qualidade da recuperação.
• Escreva definições claras e específicas. Em vez de “A prioridade do ticket”, escreva “Nível de prioridade do problema com base no impacto ao cliente. Use ‘critical’ para interrupções de serviço em produção, ‘high’ para degradação de desempenho, ‘medium’ para solicitações de funcionalidades, ‘low’ para problemas de documentação ou cosméticos.”
• Escolha regras de mesclagem que correspondam à semântica do domínio. LATEST_VALUE é um padrão seguro para a maioria dos campos, mas nem sempre correto. Para agent_type em um fluxo de escalonamento, o tipo de agente mais sênior deve ser retido, não o mais recente.
• Restrinja a saída do LLM com regras de validação. Defina allowedValues para evitar que o LLM produza “High”, “high”, “HIGH” ou “critical” para o mesmo conceito, o que quebraria a correspondência de filtros downstream.
• Use extração determinística para valores conhecidos no momento do evento. Se uma chave representa um atributo organizacional fixo — como departamento, nível de tenant ou escopo de conformidade — configure-a como STRICTLY_CONSISTENT e forneça o valor em cada evento. Reserve llmExtractionConfig para dimensões que precisam ser inferidas do conteúdo da conversa, como sentimento ou tópico.
• Evite estes antipadrões: não indexe campos de texto livre com alta cardinalidade (como descrições ou nomes completos); não use metadados para valores que mudam a cada interação; não replique isolamento de namespace apenas por metadados — um campo tenant_id sem isolamento de namespace é um modelo de segurança frágil.

Conclusão

A filtragem por metadados no AgentCore Memory resolve um desafio fundamental de recuperação. Os namespaces já isolam memórias por entidades primárias — usuários, tenants ou projetos. Com a filtragem estruturada por metadados aplicada sobre o escopo de namespace, é possível restringir a recuperação do agente a fronteiras contextuais precisas antes que a correspondência por similaridade seja executada, entregando precisão mensurável e uma base prática para conformidade, gerenciamento de contexto baseado em prioridade e filtragem organizacional refinada.

Para começar, identifique três a cinco dimensões de filtragem que mais impactam a qualidade da recuperação para o seu caso de uso. Comece com uma Prova de Conceito (PoC) usando um recurso de memória de teste para validar as estratégias relevantes, e depois expanda o schema conforme necessidades concretas surgirem. Os recursos a seguir oferecem orientação prática:

• Documentação do Amazon Bedrock AgentCore
• Exemplos de código do AgentCore Memory
• Post sobre Amazon Bedrock AgentCore Memory: construindo agentes conscientes do contexto

Fonte

Structured memory filtering with metadata in AgentCore Memory (https://aws.amazon.com/blogs/machine-learning/structured-memory-filtering-with-metadata-in-agentcore-memory/)

O problema com o RAG tradicional

Os Modelos de Linguagem de Grande Escala (LLMs) revolucionaram a forma como processamos e geramos informação, mas ainda enfrentam uma limitação importante: integrar conhecimento proveniente de múltiplas fontes ao mesmo tempo. Os métodos convencionais de Geração Aumentada por Recuperação (RAG) tratam cada documento de forma isolada, o que funciona bem para perguntas simples, mas falha quando a resposta exige conectar informações espalhadas por diferentes textos — o chamado raciocínio multi-hop.

Para endereçar essa limitação, a AWS publicou um guia técnico explorando o HippoRAG, um framework RAG que busca inspiração em como o cérebro humano organiza e recupera memórias de longo prazo.

A inspiração neurobiológica por trás do HippoRAG

O nome não é por acaso. O HippoRAG se baseia na teoria do indexamento hipocampal da memória humana. No cérebro, o neocórtex processa as entradas perceptuais enquanto o hipocampo cria um índice de associações entre memórias. Esse sistema dual permite que os seres humanos integrem informações de experiências distintas de forma eficiente.

Traduzindo isso para sistemas de IA, o HippoRAG resolve o problema do RAG tradicional por meio de três mecanismos principais:

• Construção de um Grafo de Conhecimento (GC) que representa as relações entre entidades;
• Uso do algoritmo de PageRank Personalizado (PPR) para percorrer o grafo e ranquear relevância;
• Recuperação multi-hop em uma única etapa, sem necessidade de múltiplas iterações.

Arquitetura da solução na AWS

A implementação descrita pela AWS combina quatro serviços principais:

• Amazon Bedrock: fornece as capacidades de LLM para extração de triplas do grafo de conhecimento, resposta a perguntas e identificação de entidades nomeadas;
• Amazon Neptune: armazena a estrutura do grafo de conhecimento e habilita operações básicas de grafo;
• Amazon Neptune Analytics: executa algoritmos avançados de grafo, especialmente o PageRank Personalizado para ranqueamento de relevância;
• Amazon Titan Embeddings: gera representações vetoriais do texto para correspondência por similaridade.

Pré-requisitos para implementação

Para seguir a implementação descrita no guia, são necessários:

• Uma conta AWS com acesso ao Amazon Bedrock e ao Neptune;
• Cluster do Amazon Neptune configurado e acessível;
• Grafo do Amazon Neptune Analytics criado a partir do Neptune Database;
• AWS CLI e Python 3.8+ instalados;
• Permissões de Gerenciamento de Identidade e Acesso (IAM) adequadas para: Amazon Bedrock, Amazon Neptune, Amazon Neptune Analytics e Amazon Simple Storage Service (Amazon S3).

Pipeline de processamento de dados

O primeiro passo da implementação é converter dados brutos em uma estrutura de grafo de conhecimento compatível com o Neptune. O guia utiliza o dataset HotpotQA como exemplo, percorrendo as seguintes etapas:

• Leitura do arquivo JSON de origem;
• Extração de triplas do grafo de conhecimento via Amazon Bedrock;
• Geração de arquivos CSV para carga em massa no Neptune;
• Upload dos arquivos para o Amazon S3;
• Importação para o cluster Neptune.

Configuração do importador de dados

A classe HotpotQANeptuneImporter orquestra todas as etapas da pipeline. Ela é inicializada com parâmetros de configuração do ambiente AWS, incluindo endpoints do Neptune, bucket S3, região e configurações de workers paralelos:

class HotpotQANeptuneImporter:
    """Class to handle importing HotpotQA data into Neptune."""
    def __init__(
        self,
        hotpotqa_file_path: str,
        output_dir: str,
        s3_bucket: str,
        s3_prefix: str,
        neptune_endpoint: str,
        neptune_port: int,
        iam_role_arn: str,
        aws_region: str,
        llm_endpoint: Optional[str] = None,
        embedding_endpoint: Optional[str] = None,
        max_workers: int = 4,
        max_examples: int = 10,
        max_docs_per_example: int = 2,
        use_ssl: bool = False
    ):
        """Initialize the importer with configuration."""
        self.hotpotqa_file_path = hotpotqa_file_path
        self.output_dir = output_dir
        self.s3_bucket = s3_bucket
        self.s3_prefix = s3_prefix
        self.neptune_endpoint = neptune_endpoint
        self.neptune_port = neptune_port
        self.iam_role_arn = iam_role_arn
        self.aws_region = aws_region
        # Initialize AWS clients
        self.s3_client = boto3.client('s3', region_name=aws_region)
        self.session = boto3.Session()
        # Initialize data structures
        self.phrase_dict = {}  # Maps phrase text to node ID
        self.phrase_embeddings = {}  # Maps phrase text to embedding vector

Extração de triplas do grafo de conhecimento

Para cada passagem de texto, o sistema usa o LLM do Bedrock para gerar triplas no formato sujeito-relação-objeto, que se tornam as arestas do grafo de conhecimento:

def extract_triples_with_llm(self, text: str) -> List[Tuple[str, str, str]]:
    """
    Use an LLM to extract knowledge graph triples from text.
    In this simplified version, just generate simple triples from the text.
    """
    # Simple triple generation from text
    words = text.split()
    if len(words) < 5:
        return []
    # Generate simple triples from the words in the text
    triples = []
    for i in range(min(3, len(words) - 2)):  # Get at most 3 triples
        subject = words[i]
        relation = "related_to"
        obj = words[i+2]
        triples.append((subject, relation, obj))
    return triples

Conversão para CSV e carga no Neptune

Os dados são serializados em quatro arquivos CSV — phrase_nodes.csv, passage_nodes.csv, relation_edges.csv e context_edges.csv — que capturam toda a estrutura do grafo. Após o processamento, os arquivos são enviados ao S3 e importados para o Neptune via API de carga em massa, com autenticação AWS4Auth:

def import_to_neptune(self) -> Dict:
    """Import data into Neptune using the bulk loader API."""
    logger.info(f"Importing data to Neptune endpoint {self.neptune_endpoint}")
    loader_endpoint = f"{self.protocol}://{self.neptune_endpoint}:{self.neptune_port}/loader"
    payload = {
        "source": f"s3://{self.s3_bucket}/{self.s3_prefix}/",
        "format": "csv",
        "formatParams": {
            "delimiter": ",",
            "header": "true"
        },
        "iamRoleArn": self.iam_role_arn,
        "region": self.aws_region,
        "failOnError": "FALSE"
    }
    try:
        # Create AWS4Auth for the request
        credentials = self.session.get_credentials()
        if credentials:
            auth = AWS4Auth(
                credentials.access_key,
                credentials.secret_key,
                self.aws_region,
                'neptune-db',
                session_token=credentials.token
            )
            response = requests.post(
                loader_endpoint,
                data=json.dumps(payload),
                headers={"Content-Type": "application/json"},
                timeout=30,
                auth=auth
            )
            response.raise_for_status()
            result = response.json()
            logger.info(f"Neptune load job submitted: {result}")
            return result
    except Exception as e:
        logger.error(f"Failed to submit Neptune load job: {e}")
        raise

Implementação do HippoRAG

Configuração inicial

A configuração base do HippoRAG define o modelo LLM (Claude 3.5 Haiku via Bedrock), o modelo de embeddings (Amazon Titan Embeddings v2), a região AWS e os parâmetros de recuperação:

from src.hipporag.utils.config_utils import BaseConfig
config = BaseConfig()
config.force_index_from_scratch = True
config.openie_mode = "online"
config.llm_name = "us.anthropic.claude-3-5-haiku-20241022-v1:0"
config.embedding_model_name = "amazon.titan-embed-text-v2:0"
config.aws_region = "us-east-1"
config.save_dir = "outputs"
config.retrieval_top_k = 3

Integração com o Neptune Analytics e PageRank Personalizado

O diferencial central da implementação é o uso do Neptune Analytics para executar o PageRank personalizado. Um cliente dedicado gerencia as operações de análise avançada de grafo, recebendo nós-semente e propagando scores de relevância pelo grafo:

class NeptuneAnalyticsClient:
    """Client for Neptune Analytics operations including personalized PageRank."""
    def __init__(self, graph_id, region='us-east-1'):
        """Initialize Neptune Analytics client."""
        self.graph_id = graph_id
        self.region = region
        self.client = boto3.client('neptune-analytics', region_name=region)
        logger.info(f"Initialized Neptune Analytics client for graph {graph_id}")

    def run_personalized_pagerank(self, seed_nodes, damping_factor=0.85, max_iterations=20, tolerance=0.0001):
        if not seed_nodes:
            logger.warning("No seed nodes provided for personalized PageRank")
            return []
        # Format seed nodes for the query
        seed_list = ",".join([f"'{node}'" for node in seed_nodes])
        # Neptune Analytics personalized PageRank query using openCypher
        query = f"""
        CALL neptune.algo.pagerank({{
            sourceNodes: [{seed_list}],
            dampingFactor: {damping_factor},
            maxIterations: {max_iterations},
            tolerance: {tolerance},
            personalized: true
        }})
        YIELD nodeId, score
        RETURN nodeId, score
        ORDER BY score DESC
        LIMIT 100
        """
        try:
            result = self.execute_analytics_query(query)
            if result and 'results' in result:
                pagerank_results = [(item['nodeId'], item['score']) for item in result['results']]
                logger.info(f"Personalized PageRank returned {len(pagerank_results)} results")
                return pagerank_results
            return []
        except Exception as e:
            logger.error(f"Failed to run personalized PageRank: {e}")
            return []

Construção e indexação do grafo de conhecimento

O processo de indexação envolve seis etapas principais: extração de entidades nomeadas com o Claude via Bedrock, criação de triplas por extração de informação aberta, geração de embeddings com o Amazon Titan, armazenamento da estrutura no Neptune Database, adição de arestas de sinonímia entre entidades similares e preparação do grafo para processamento no Neptune Analytics.

Demonstração e resultados

O guia apresenta uma demonstração completa com perguntas reais. A inicialização do NeptuneHippoRAG recebe o endpoint do Neptune, a porta e o ID do grafo do Analytics. Em seguida, os documentos são indexados a partir do Neptune e as consultas são processadas com PageRank personalizado:

# Initialize NeptuneHippoRAG with Analytics support
hippo = NeptuneHippoRAG(
    global_config=config,
    neptune_endpoint="your-neptune-endpoint.us-east-1.neptune.amazonaws.com",
    neptune_port=8182,
    analytics_graph_id="g-your-analytics-graph-id"
)

# Index data from Neptune
hippo.index_from_neptune(limit=1000)

# Example queries
questions = [
    "Who painted the Mona Lisa?",
    "Which city is the capital of France?",
    "What is the height of the Eiffel Tower?",
    "What is the connection between Leonardo da Vinci and France?",
]

# Process each query with personalized PageRank
for question in questions:
    # Get retrieval results with personalized PageRank
    results = hippo.retrieve_with_personalized_pagerank([question])
    # Generate answer using the QA method
    qa_results, _, _ = hippo.qa(results)
    # Display the answer with PageRank scores
    print(f"Question: {question}")
    print(f"Answer: {qa_results[0].answer}")
    print(f"Top documents (PageRank ranked):")
    for i, (doc, score) in enumerate(zip(results[0].docs, results[0].doc_scores)):
        print(f"  Doc {i+1} (Score: {score:.4f}): {doc[:100]}...")

Os resultados demonstram a capacidade do sistema de conectar informações entre documentos distintos. Para a pergunta sobre a conexão entre Leonardo da Vinci e a França, por exemplo, o HippoRAG recupera e ranqueia corretamente passagens sobre a morte do artista em território francês, seu convite pela corte do Rei Francisco I e seus últimos anos em Amboise — informações que estão em documentos separados.

Recuperação multi-hop do tipo path-finding

Uma das capacidades mais relevantes do HippoRAG é resolver perguntas do tipo path-finding — aquelas que, ao contrário das perguntas com caminho direto entre entidades, exigem explorar múltiplos caminhos possíveis no grafo. Para uma pergunta como "Qual professor de Stanford trabalha com neurociência do Alzheimer?", o algoritmo de PageRank Personalizado parte de nós-semente relacionados a "Stanford", "neurociência" e "Alzheimer" e propaga scores de relevância pelo grafo até identificar as entidades e passagens mais fortemente conectadas aos conceitos da consulta. Esse tipo de capacidade é especialmente valioso para revisão de literatura científica, análise de casos jurídicos ou diagnóstico médico.

Benefícios e considerações de performance

A abordagem HippoRAG implementada com esse conjunto de serviços AWS oferece vantagens concretas:

• Alta performance em raciocínio multi-hop: o HippoRAG se destaca como uma variante de alto desempenho do GraphRAG para tarefas complexas;
• Eficiência em etapa única: o PageRank Personalizado permite recuperação multi-hop direta, diferente de métodos iterativos;
• Analytics avançado de grafo: o Neptune Analytics entrega o algoritmo de PageRank com escalabilidade e alta performance;
• Integração nativa AWS: uso completo de serviços gerenciados como Bedrock, Neptune e Neptune Analytics para confiabilidade e facilidade operacional;
• Aprendizado contínuo: o sistema pode ser atualizado com novas informações sem necessidade de retreinamento do modelo;
• Pronto para empresas: seguro, escalável e compatível com infraestruturas AWS existentes.

Limpeza de recursos

Ao concluir os testes, é importante remover os recursos criados para evitar cobranças desnecessárias. A AWS recomenda seguir as instruções de exclusão na documentação do Amazon Neptune, Amazon Neptune Analytics, Amazon Bedrock e Amazon S3, além de remover as roles e políticas de IAM criadas durante a implementação.

Referências

• HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models (artigo de pesquisa original)
• Documentação do Amazon Bedrock
• Documentação do Amazon Neptune
• Documentação do Amazon Neptune Analytics
• Documentação do Amazon Titan Embeddings

Fonte

HippoRAG: Neurobiologically inspired RAG using Amazon Bedrock, Amazon Neptune, and personalized PageRank (https://aws.amazon.com/blogs/machine-learning/hipporag-neurobiologically-inspired-rag-using-amazon-bedrock-amazon-neptune-and-personalized-pagerank/)

IA de ponta dentro do perímetro regulatório

Agências governamentais americanas, comunidades de defesa e inteligência, e seus contratantes enfrentam um dilema claro: precisam de modelos de IA cada vez mais avançados, mas não podem comprometer os controles de segurança, conformidade e residência de dados que suas missões exigem. A AWS respondeu a esse desafio com um anúncio relevante: os modelos de peso aberto da NVIDIA (família Nemotron) e da OpenAI (GPT OSS) estão agora disponíveis no Amazon Bedrock dentro do AWS GovCloud (US).

Isso significa que tarefas como análise de inteligência, planejamento de missões, revisão de contratos de aquisição, análise de logs de segurança e automação de conformidade podem ser executadas com modelos de última geração — sem que os dados sensíveis precisem sair do ambiente controlado.

Os modelos disponíveis

NVIDIA Nemotron

A família NVIDIA Nemotron combina modelos de linguagem pequenos (SLM) e grandes (LLM), construídos para eficiência computacional e precisão em sistemas de IA agêntica especializada. Dois modelos se destacam:

• NVIDIA Nemotron 3 Super (120B): modelo híbrido aberto com arquitetura de Mistura de Especialistas (MoE — Mixture of Experts), com 120 bilhões de parâmetros totais, mas que ativa apenas 12 bilhões por token. Esse design entrega até 5 vezes mais throughput que a geração anterior e suporta uma janela de contexto de 1 milhão de tokens — ideal para tarefas longas e com múltiplos passos.
• NVIDIA Nemotron 3 Nano (30B): modelo com 30 bilhões de parâmetros que ativa aproximadamente 3 bilhões por token, entregando 4 vezes mais throughput que a geração anterior e reduzindo a geração de tokens de raciocínio em até 60%. Também suporta janela de contexto de 1 milhão de tokens.

Para a lista completa de modelos NVIDIA disponíveis no GovCloud, consulte a documentação de modelos NVIDIA no Amazon Bedrock.

OpenAI GPT OSS

Os modelos GPT OSS da OpenAI são modelos de peso aberto texto-para-texto, projetados para raciocínio, tarefas agênticas e desenvolvimento, com esforço de raciocínio ajustável e suporte a integração com ferramentas externas. Dois variantes estão disponíveis:

• gpt-oss-120b: modelo com 120 bilhões de parâmetros, voltado para uso em produção, propósito geral e casos de raciocínio complexo.
• gpt-oss-20b: modelo com 20 bilhões de parâmetros, projetado para menor latência e casos de uso locais ou especializados.

Ambos oferecem janela de contexto de 128 mil tokens e até 16 mil tokens de saída, aceitando entrada de texto e gerando saída de texto. Por serem de peso aberto, as organizações podem avaliar independentemente a arquitetura do modelo, revisar o cartão do modelo publicado e executar seus próprios benchmarks. Para equipes governamentais, essa transparência apoia avaliações de risco organizacional e se alinha aos princípios de zero trust que muitas agências americanas estão adotando.

Consulte a lista completa de modelos OpenAI disponíveis no Amazon Bedrock.

Inferência sem servidor dentro do limite de conformidade

Os modelos NVIDIA Nemotron e GPT OSS no Amazon Bedrock são servidos pelo mecanismo de inferência de próxima geração, chamado Mantle. É importante entender a distinção entre o mecanismo e o endpoint: o mecanismo é a infraestrutura de servimento subjacente, projetado com isolamento de conta de implantação de modelo e acesso zero para operadores; já o endpoint bedrock-mantle é a API HTTPS compatível com OpenAI que as aplicações usam para enviar requisições.

O design de acesso zero para operadores significa que nenhum operador — seja da AWS, do cliente ou do provedor do modelo — pode acessar dados do cliente, como prompts ou completions de inferência. Combinado com o isolamento do AWS GovCloud (US), isso oferece uma base sólida de proteção de dados. Para detalhes técnicos, consulte o post Explorando o design de acesso zero para operadores do Mantle. Para mais informações sobre como o Amazon Bedrock trata seus dados, veja a documentação de proteção de dados no Amazon Bedrock.

Não há infraestrutura para provisionar, GPUs para gerenciar ou expertise em implantação de modelos necessária — o serviço é totalmente gerenciado.

Endpoints disponíveis

O Amazon Bedrock oferece dois endpoints para invocar esses modelos:

• bedrock-mantle: endpoint compatível com a API da OpenAI, que pode ser chamado com os SDKs Python e TypeScript da OpenAI. Suporta as APIs Chat Completions e Responses.
• bedrock-runtime: utiliza as APIs Converse e InvokeModel via AWS SDK, com acesso a funcionalidades nativas do Amazon Bedrock, como Guardrails.

Disponibilidade regional e residência de dados

O Amazon Bedrock oferece múltiplas opções para onde as requisições de inferência são processadas:

• Inferência In-Region: disponível em us-gov-west-1 (AWS GovCloud US-West), mantendo cada requisição dentro de uma única região.
• Inferência Geo Cross-Region: disponível via um ID de inferência cross-region dedicado ao AWS GovCloud (US), roteando requisições entre us-gov-west-1 e us-gov-east-1. O tráfego permanece dentro do limite do AWS GovCloud (US), com maior resiliência.

A inferência Global Cross-Region, que roteia requisições por regiões comerciais da AWS ao redor do mundo, não está disponível no AWS GovCloud (US). Toda inferência para esses modelos permanece dentro do limite do AWS GovCloud (US).

Níveis de serviço disponíveis

O Amazon Bedrock oferece múltiplos níveis de serviço para atender diferentes requisitos de carga de trabalho. Para todos os modelos mencionados, os níveis Standard, Priority e Flex são suportados:

• Standard: acesso pago por token, sem compromisso prévio de capacidade.
• Priority: maior throughput para tráfego sensível a latência.
• Flex: acesso com menor custo para cargas de trabalho flexíveis e não urgentes, como avaliações de modelos ou sumarizações em lote.

O nível Reserved (throughput dedicado com compromisso de prazo) não está disponível atualmente para esses modelos. Para orientações sobre escalabilidade, consulte as boas práticas de escalabilidade e throughput.

Como começar no AWS GovCloud (US)

Console do Amazon Bedrock

Para testar os modelos diretamente no console:

• Acesse o console do Amazon Bedrock na sua conta AWS GovCloud (US).
• Selecione Playground no menu lateral, em seguida Select model.
• Escolha o provedor (NVIDIA ou OpenAI) e o modelo desejado (por exemplo, NVIDIA Nemotron 3 Super ou gpt-oss-120b).
• Clique em Apply para carregar o modelo e insira um prompt para testar.

Usando o endpoint bedrock-mantle (recomendado)

Para usar esses modelos via endpoint bedrock-mantle, é necessária uma conta AWS no GovCloud (US) com permissões para invocar modelos do Amazon Bedrock e uma chave de API do Amazon Bedrock ou credenciais AWS padrão. Exemplo de política IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockMantleInference",
      "Effect": "Allow",
      "Action": [
        "bedrock-mantle:CreateInference",
        "bedrock-mantle:Get*",
        "bedrock-mantle:List*"
      ],
      "Resource": "arn:aws-us-gov:bedrock-mantle:us-gov-west-1:111122223333:project/*"
    },
    {
      "Sid": "BedrockMantleCallWithBearerToken",
      "Effect": "Allow",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*"
    }
  ]
}

Substitua 111122223333 pelo ID da sua conta AWS. Para controlar quais identidades podem gerar ou usar chaves de API do Amazon Bedrock, consulte Controle de permissões para geração e uso de chaves de API do Amazon Bedrock. Para restringir sua organização a modelos aprovados, utilize uma política de controle de serviço (SCP).

O exemplo a seguir usa o SDK Python da OpenAI para chamar o endpoint bedrock-mantle. Para cargas de trabalho em produção, use chaves de API de curto prazo, que expiram automaticamente (máximo de 12 horas):

import boto3
from openai import OpenAI

# Retrieve the Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-gov-west-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]

client = OpenAI(
    # Use the AWS GovCloud (US) Region in the base URL, e.g. us-gov-west-1
    base_url="https://bedrock-mantle.us-gov-west-1.api.aws/v1",
    api_key=api_key,
)

response = client.chat.completions.create(
    model="openai.gpt-oss-120b",
    messages=[
        {"role": "user", "content": "Explain the benefits of open-weight models for regulated workloads."}
    ],
    reasoning_effort="medium",  # low | medium | high
    max_completion_tokens=512,
)

print(response.choices[0].message.content)

Nota: os exemplos recuperam a chave de API do Bedrock a partir do AWS Secrets Manager. Para desenvolvimento local, é possível ler a chave de uma variável de ambiente, mas esse padrão deve ser evitado em produção.

Para chamar o NVIDIA Nemotron 3 Super 120B em vez do GPT OSS, basta alterar o parâmetro model para nvidia.nemotron-super-3-120b e remover o parâmetro reasoning_effort (o controle de esforço de raciocínio é específico para os modelos GPT OSS). Nenhuma outra alteração de código é necessária.

Controlando o esforço de raciocínio

Os modelos GPT OSS são modelos de raciocínio que expõem um esforço de raciocínio ajustável. Defina o parâmetro reasoning_effort na chamada Chat Completions como low, medium ou high para equilibrar latência de resposta e profundidade de raciocínio. Use low para tráfego de alto volume e sensível a latência, e high para raciocínio complexo com múltiplos passos ou planejamento agêntico. Para modelos de raciocínio, prefira max_completion_tokens para limitar o tamanho da resposta.

Usando a Responses API

Além do Chat Completions, os modelos GPT OSS suportam a Responses API, a interface da OpenAI para interações no estilo de raciocínio. Ela recebe um único input em vez de um array de mensagens. O NVIDIA Nemotron 3 Super 120B não suporta a Responses API — use Chat Completions, Converse ou Invoke para esse modelo.

import boto3
from openai import OpenAI

# Retrieve the Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-gov-west-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]

client = OpenAI(
    base_url="https://bedrock-mantle.us-gov-west-1.api.aws/v1",
    api_key=api_key,
)

response = client.responses.create(
    model="openai.gpt-oss-120b",
    input="Explain the benefits of open-weight models for regulated workloads.",
)

print(response)

Respostas em streaming

Para casos de uso de chat e agentes onde se deseja exibir tokens ao usuário conforme são gerados, defina stream=True:

stream = client.chat.completions.create(
    model="openai.gpt-oss-120b",
    messages=[
        {"role": "user", "content": "Write a short summary of mixture-of-experts architectures."}
    ],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

print()

Tool calling (chamada de ferramentas)

Os modelos NVIDIA Nemotron e GPT OSS de peso aberto são projetados para fluxos de trabalho agênticos, tornando-os adequados para cenários de tool calling. Nesse fluxo, você define funções (ferramentas) que o modelo pode invocar, o modelo decide quando chamá-las com base na solicitação do usuário, e sua aplicação executa a função e retorna o resultado para o modelo incorporar em sua resposta final.

import json
import boto3
from openai import OpenAI

# Retrieve the Bedrock API key from AWS Secrets Manager
secrets_client = boto3.client("secretsmanager", region_name="us-gov-west-1")
api_key = secrets_client.get_secret_value(SecretId="bedrock-api-key")["SecretString"]

client = OpenAI(
    base_url="https://bedrock-mantle.us-gov-west-1.api.aws/v1",
    api_key=api_key,
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a given location",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "City and country (e.g., Seattle, US)"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "Temperature unit"
                    }
                },
                "required": ["location"]
            }
        }
    }
]

# Step 1: Send the user request with tool definitions
messages = [
    {"role": "user", "content": "What's the weather like in Seattle?"}
]

response = client.chat.completions.create(
    model="openai.gpt-oss-120b",
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

assistant_message = response.choices[0].message

# Step 2: Check if the model wants to call a tool
if assistant_message.tool_calls:
    messages.append(assistant_message)

    for tool_call in assistant_message.tool_calls:
        function_name = tool_call.function.name
        arguments = json.loads(tool_call.function.arguments)

        # Step 3: Validate function name and run it
        if function_name == "get_weather":
            location = arguments.get("location", "Unknown")
            unit = arguments.get("unit", "fahrenheit")
            result = {
                "location": location,
                "temperature": 18 if unit == "celsius" else 64,
                "unit": unit,
                "condition": "Partly cloudy",
                "humidity": 72,
            }
        else:
            result = {"error": f"Unknown function: {function_name}"}

        # Step 4: Return the function result to the model
        messages.append({
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(result),
        })

    # Step 5: Get the final response incorporating tool results
    final_response = client.chat.completions.create(
        model="openai.gpt-oss-120b",
        messages=messages,
        tools=tools,
    )
    print(final_response.choices[0].message.content)
else:
    print(assistant_message.content)

No endpoint bedrock-mantle, os modelos GPT OSS suportam tool calling client-side e server-side, enquanto o NVIDIA Nemotron 3 Super 120B suporta apenas client-side. Ambas as famílias também suportam tool calling no endpoint bedrock-runtime via API Converse (usando toolConfig). Consulte o cartão do modelo de cada um para a matriz completa de funcionalidades.

Usando o endpoint bedrock-runtime (boto3)

Para o endpoint bedrock-runtime, são necessárias credenciais AWS configuradas (usuário ou role do Serviço de Gerenciamento de Identidade e Acesso — IAM) com permissão para invocar o modelo. Exemplo de política:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws-us-gov:bedrock:us-gov-west-1::foundation-model/openai.gpt-oss-120b-1:0"
    }
  ]
}

O exemplo a seguir envia uma requisição de turno único usando o SDK AWS para Python (boto3) com a API Converse. Os IDs de modelo GPT OSS no endpoint bedrock-runtime incluem um sufixo de versão (por exemplo, openai.gpt-oss-120b-1:0). Use o ID exato do cartão de cada modelo:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-gov-west-1")

response = client.converse(
    modelId="openai.gpt-oss-120b-1:0",
    messages=[{
        "role": "user",
        "content": [{"text": "What is a mixture-of-experts architecture?"}]
    }],
    inferenceConfig={"maxTokens": 2048, "temperature": 1.0, "topP": 0.95},
)

content_blocks = response["output"]["message"]["content"]
response_text = next(
    (block["text"] for block in content_blocks if "text" in block), None
)

if response_text:
    print(response_text)
else:
    print("No text response.")

Para chamar o NVIDIA Nemotron 3 Super 120B via bedrock-runtime, use o ID de modelo nvidia.nemotron-super-3-120b (esse modelo não carrega sufixo de versão). Também é possível acessar esses modelos pelo terminal usando a Interface de Linha de Comando da AWS (AWS CLI):

aws bedrock-runtime converse \
  --model-id openai.gpt-oss-120b-1:0 \
  --messages '[{"role":"user","content":[{"text":"Type_Your_Prompt_Here"}]}]' \
  --inference-config '{"maxTokens":512}' \
  --region us-gov-west-1

Escalabilidade e tratamento de erros

A capacidade sob demanda no nível Standard é compartilhada e alocada por região da AWS. Durante períodos de alta demanda, uma requisição pode ser brevemente enfileirada ou limitada. No endpoint bedrock-mantle, não há cota de requisições por minuto — o throughput é governado por limites baseados em tokens.

O Amazon Bedrock expõe dois códigos de erro HTTP que indicam quando uma requisição não pode ser atendida:

• 429: a requisição foi negada por exceder as cotas da conta. Solicite um aumento de cota pelo console de Service Quotas e aplique throttling no lado do cliente.
• 503: o serviço está enfrentando alta demanda ou restrições temporárias de capacidade. Faça retry com backoff exponencial e jitter.

Para respostas 503 transitórias, configure retries automáticos no SDK:

import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)

Ao retomar após throttling sustentado, mantenha um estado estável por cerca de 15 minutos entre aumentos, em vez de ir diretamente ao volume alvo. Para mais detalhes, consulte as boas práticas de escalabilidade e throughput no Guia do Usuário do Amazon Bedrock.

Limpeza e custos

Esses modelos utilizam inferência sob demanda, que gera cobranças apenas quando um modelo é invocado — não há endpoint ou infraestrutura para desligar. Para evitar cobranças não intencionais após testes:

• Se você gerou chaves de API de curto prazo do Bedrock, elas expiram automaticamente (máximo de 12 horas). Para revogar antes disso, exclua-as no console do Amazon Bedrock.
• Se optou pelo nível Priority para testes, retorne ao preço Standard removendo o parâmetro service_tier das suas invocações.
• Se armazenou uma chave de API do Bedrock no AWS Secrets Manager para testes, exclua o segredo para evitar cobranças de armazenamento.

Para detalhes de preços por modelo e nível, consulte a página de preços do Amazon Bedrock.

Disponibilidade

Os modelos OpenAI GPT OSS e NVIDIA Nemotron já estão disponíveis no Amazon Bedrock no AWS GovCloud (US). A inferência In-Region está disponível no AWS GovCloud (US-West) (us-gov-west-1), e a inferência Geo Cross-Region roteia requisições entre AWS GovCloud (US-West) e AWS GovCloud (US-East) (us-gov-east-1), mantendo o tráfego dentro do limite do AWS GovCloud (US). Os preços são por token e variam por modelo e nível de serviço. Para as tarifas atuais, consulte a página de preços do Amazon Bedrock.

Recursos adicionais

• AWS GovCloud (US)
• Guia do Usuário do Amazon Bedrock
• Modelos OpenAI no Amazon Bedrock
• Cartão do modelo NVIDIA Nemotron 3 Super 120B
• Explorando o design de acesso zero para operadores do Mantle
• Níveis de serviço do Amazon Bedrock
• Chaves de API do Amazon Bedrock

Fonte

Run NVIDIA Nemotron and OpenAI GPT OSS models on Amazon Bedrock in AWS GovCloud (US) (https://aws.amazon.com/blogs/machine-learning/run-nvidia-nemotron-and-openai-gpt-oss-models-on-amazon-bedrock-in-aws-govcloud-us/)

Mais capacidade para agentes de IA em escala

A AWS anunciou um aumento nos limites padrão de cota de execução do Amazon Bedrock AgentCore, ampliando a capacidade disponível para quem desenvolve e opera cargas de trabalho baseadas em agentes de IA. A mudança chega sem necessidade de solicitações adicionais — os novos limites já estão ativos por padrão para todos os clientes.

O que é o AgentCore?

O AgentCore é a plataforma da AWS voltada para desenvolvedores que precisam construir, conectar e otimizar agentes de IA. Ele serve como base para quem quer criar soluções inteligentes e autônomas usando os modelos disponíveis no Amazon Bedrock.

Quais são os novos limites?

Com a atualização, as cotas padrão passam a ser:

• 5.000 sessões ativas simultâneas nas regiões US East (N. Virginia) e US West (Oregon)
• 2.500 sessões ativas simultâneas em todas as demais regiões suportadas
• 200 interações de agentes por segundo em todas as regiões da AWS onde o AgentCore está disponível
• 25 novas sessões criadas por segundo em todas as regiões suportadas

Na prática, isso significa que equipes e empresas conseguem rodar mais agentes de IA ao mesmo tempo, suportando cargas de trabalho de alto volume sem precisar solicitar aumentos de cota logo de início.

Por que isso importa para quem desenvolve com IA?

Um dos gargalos mais comuns em ambientes de produção com agentes de IA é justamente o limite de sessões e interações simultâneas. Com cotas mais generosas disponíveis por padrão, o ciclo de desenvolvimento e a transição para produção ficam mais fluidos — especialmente para aplicações que precisam atender múltiplos usuários ou processos em paralelo.

Essa expansão de limites é um sinal claro de que a AWS está preparando a infraestrutura do AgentCore para suportar adoção em maior escala, alinhada ao crescimento do uso de agentes autônomos em cenários empresariais.

Saiba mais

Para quem quer explorar o AgentCore em mais detalhes, a AWS disponibiliza a página do produto AgentCore e o Guia do Desenvolvedor do AgentCore. Para consultar todos os limites de cota vigentes, acesse a documentação de cotas do AgentCore.

Fonte

Amazon Bedrock AgentCore increases default runtime quota limits (https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-increases-default-runtime-quota-limits/)