Blog

O problema da janela de contexto em documentos grandes

Quem já tentou analisar documentos extensos com modelos de linguagem grandes (LLM, do inglês Large Language Model) conhece bem o problema: em algum momento, o documento simplesmente não cabe na janela de contexto do modelo. E quando isso acontece, ou a requisição falha, ou o modelo trabalha com informações incompletas — o que compromete diretamente a qualidade das respostas.

Considere uma tarefa comum de análise financeira: comparar métricas de dois anos consecutivos de relatórios anuais de uma empresa. Cada relatório pode ter entre 300 e 500 páginas. Somando relatórios de analistas, documentos da SEC e materiais complementares, o total facilmente chega a milhões de caracteres. Mesmo os maiores contextos disponíveis hoje têm um teto — e o famoso problema do “lost in the middle” (informação perdida no meio do contexto) ainda afeta modelos mesmo quando o documento tecnicamente cabe.

A AWS publicou uma abordagem para contornar essa limitação estrutural usando Amazon Bedrock AgentCore em conjunto com o Strands Agents SDK. A técnica é chamada de Modelos de Linguagem Recursivos (RLM, do inglês Recursive Language Models).

O que são Modelos de Linguagem Recursivos (RLM)

Os RLMs foram introduzidos por Zhang et al. no artigo arXiv:2512.24601 e propõem uma mudança de perspectiva: em vez de tentar colocar o documento inteiro dentro da janela de contexto, o modelo passa a tratar o documento como um ambiente externo com o qual ele interage programaticamente.

Na prática, o modelo recebe apenas a pergunta do usuário e uma descrição do ambiente disponível. A partir daí, ele escreve código para buscar, fatiar e analisar o documento de forma iterativa. Quando precisa de compreensão semântica de uma seção específica, ele delega essa análise a uma chamada de sub-LLM, mantendo os resultados em memória de trabalho como variáveis Python — sem consumir espaço na janela de contexto principal.

Isso cria uma estrutura recursiva: o LLM raiz orquestra a análise via código, chamando sub-LLMs conforme necessário para tarefas semânticas, enquanto o documento completo jamais entra diretamente na janela de contexto do modelo orquestrador.

Arquitetura da solução com Amazon Bedrock AgentCore

A implementação descrita pela AWS combina três componentes que trabalham juntos:

• Agente LLM raiz, construído com o Strands Agents SDK, que recebe a pergunta do usuário e decide qual código executar.
• Sessão do Amazon Bedrock AgentCore Code Interpreter, rodando em modo de rede pública (PUBLIC), com o documento completo carregado como variável Python.
• Função llm_query() injetada no sandbox, que chama o Amazon Bedrock diretamente de dentro do Code Interpreter — mantendo os resultados dos sub-LLMs em variáveis Python, sem que eles retornem para o contexto do LLM raiz.

O modo de rede pública do Bedrock AgentCore Code Interpreter é essencial aqui: ele permite que o sandbox faça chamadas de saída para a API do Amazon Bedrock. O estado persistente da sessão garante que variáveis, resultados intermediários e dados extraídos se acumulem ao longo de múltiplas execuções de código — funcionando como uma memória de trabalho que persiste durante toda a análise.

Como implementar: passo a passo

Pré-requisitos

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

• Uma conta AWS com acesso aos modelos fundacionais do Amazon Bedrock.
• Python 3.10 ou superior.
• A Interface de Linha de Comando da AWS (AWS CLI) configurada com as credenciais adequadas.
• Familiaridade com Python e uso básico do AWS SDK (Boto3).
• Um Amazon Bedrock AgentCore Code Interpreter configurado em modo de rede PUBLIC.
• Permissões do Gerenciamento de Identidade e Acesso (IAM) para: bedrock:InvokeModel, bedrock-agentcore:StartCodeInterpreterSession, bedrock-agentcore:InvokeCodeInterpreter e bedrock-agentcore:StopCodeInterpreterSession.

Passo 1: Iniciar uma sessão do Code Interpreter e carregar o documento

O primeiro passo é criar uma sessão do Amazon Bedrock AgentCore Code Interpreter e escrever o documento no sandbox:

import boto3
import json

# Start a Bedrock AgentCore Code Interpreter session
client = boto3.client('bedrock-agentcore', region_name='us-east-1')
response = client.start_code_interpreter_session(
    codeInterpreterIdentifier=code_interpreter_id,
    name="rlm-session",
    sessionTimeoutSeconds=3600
)
session_id = response["sessionId"]

# Write the document to the sandbox
client.invoke_code_interpreter(
    codeInterpreterIdentifier=code_interpreter_id,
    sessionId=session_id,
    name="writeFiles",
    arguments={"content": [{"path": "_context.txt", "text": document}]}
)

Passo 2: Inicializar o documento e definir a função llm_query() dentro do sandbox

Dentro do sandbox, o documento é carregado e a função llm_query() é definida para que as chamadas de sub-LLM possam ser feitas diretamente de dentro do Code Interpreter:

# Runs inside the Bedrock AgentCore Code Interpreter sandbox
with open('_context.txt', 'r') as f:
    context = f.read()

def llm_query(prompt: str) -> str:
    """Query a sub-LLM from within the sandbox."""
    response = bedrock_client.invoke_model(
        modelId=sub_model_id,
        body=json.dumps({
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 4096,
            "messages": [{"role": "user", "content": prompt}]
        })
    )
    result = json.loads(response['body'].read())
    return result['content'][0]['text']

Passo 3: Criar o agente Strands e executar a consulta

Com o ambiente preparado, basta criar um agente Strands com uma ferramenta execute_python que executa código na sessão e enviar a pergunta:

from strands import Agent

agent = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=rlm_system_prompt,
    tools=[execute_python],
)

answer = agent("What are the key revenue trends across these reports?")

O agente escreve e executa código Python de forma iterativa para explorar o documento, extrair seções relevantes e chamar llm_query() quando precisar de análise semântica de trechos específicos.

Resultados: RLM vs. abordagens tradicionais

A AWS avaliou a abordagem em dois subconjuntos do benchmark LongBench v2, comparando três estratégias:

• Base: o documento completo é enviado diretamente ao modelo em uma única chamada de API com janela de contexto de 200 mil tokens.
• Long Context: uso da janela estendida de 1 milhão de tokens do Claude, que suporta entradas maiores mas ainda tem limite superior e pode sofrer com o problema do “lost in the middle”.
• RLM: a abordagem descrita neste post.

QA Financeiro Multi-Documento (15 questões)

Os resultados para o subconjunto de QA Financeiro foram os seguintes:

• A abordagem Base atingiu taxa de sucesso de 46,7% e precisão de 33,3% (Claude Haiku 4.5).
• A abordagem Long Context atingiu 93,3% de sucesso e 60–66,7% de precisão, dependendo do modelo.
• O RLM atingiu 100% de taxa de sucesso em todas as configurações avaliadas, com precisão variando de 66,7% (Haiku 4.5 e Sonnet 4.5) a 80,0% (Claude Opus 4.6 + Haiku 4.5 como sub-LLM).
• Para referência, a precisão de especialistas humanos no mesmo benchmark é de 40%.

Compreensão de Repositórios de Código (50 questões)

O segundo subconjunto testou a capacidade de navegar por grandes bases de código — um cenário especialmente adequado para exploração programática. Os resultados foram igualmente expressivos:

• Base: 30% de sucesso e 20% de precisão.
• Long Context: 60% de sucesso e 42–46% de precisão.
• RLM: 100% de sucesso e precisão entre 64% e 76% dependendo do modelo raiz.

Três conclusões dos resultados

1. O RLM elimina falhas por limite de contexto. Ao desacoplar o tamanho do documento da janela de contexto, o RLM processa 100% das questões — enquanto Base e Long Context falham em parte delas.

2. O RLM melhora a precisão na maioria dos modelos. O maior ganho foi observado no Claude Haiku 4.5 (de 33,3% para 66,7%). Modelos mais fortes como Sonnet 4.6 e Opus 4.6 também melhoraram, mas com ganhos menores. O Claude Sonnet 4.5 não apresentou melhora sobre o Long Context baseline, sugerindo que os ganhos dependem da capacidade do modelo raiz de decompor a tarefa em sub-consultas eficazes.

3. A escolha do sub-LLM tem impacto limitado. Nos experimentos, usar o Claude Haiku 4.5 como sub-LLM em vez do mesmo modelo principal não produziu diferença significativa de precisão. O desempenho é determinado principalmente pela capacidade do modelo raiz de gerar sub-consultas eficientes.

Como o modelo trabalha na prática

Para ilustrar o funcionamento real, a AWS descreve uma sequência representativa de um dos casos de avaliação. O modelo precisa comparar métricas financeiras em dois relatórios anuais que somam aproximadamente 1,5 milhão de caracteres.

Primeiro, o modelo busca marcadores estruturais para entender o layout do documento:

matches = re.findall(r'Table of Contents|ANNUAL REPORT', context)

Em seguida, fatia seções específicas para localizar tabelas de receita:

revenue_section = context[450000:500000]
print(revenue_section)

Para análise semântica, delega ao sub-LLM:

analysis = llm_query(f"Compare these revenue figures: {chunk}")

Por fim, agrega os resultados de múltiplas seções e chega à resposta final.

Considerações práticas

A AWS destaca três pontos importantes para quem for adotar o RLM em produção:

Latência. O RLM troca latência por capacidade. Nas avaliações, execuções individuais variaram de cerca de 10 segundos para perguntas simples a alguns minutos para questões complexas com contextos grandes. Para processamento em lote ou análise offline, esse tradeoff é bem justificado. Para aplicações em tempo real, vale avaliar se a tarefa realmente exige processar documentos além da janela de contexto do modelo.

Custo. Cada execução do RLM envolve múltiplas invocações de modelo — tanto o raciocínio iterativo do LLM raiz quanto as chamadas de sub-LLM dentro do sandbox. Para workloads sensíveis a custo, usar um modelo menor (como o Haiku 4.5) como sub-modelo e um modelo maior como raiz é uma estratégia eficaz para reduzir custos sem comprometer a precisão.

Engenharia de prompt. O prompt de sistema influencia diretamente a eficiência do modelo no uso das ferramentas. Sem orientações claras, modelos tendem a fazer chamadas desnecessárias ao sub-LLM para validar o próprio raciocínio ou imprimir resumos intermediários verbosos. Instruções precisas sobre quando usar execução de código versus raciocínio direto reduzem chamadas desperdiçadas e melhoram a latência.

Limpeza de recursos

Para evitar cobranças contínuas, a sessão do Amazon Bedrock AgentCore Code Interpreter deve ser encerrada ao final da análise:

client.stop_code_interpreter_session(
    codeInterpreterIdentifier=code_interpreter_id,
    sessionId=session_id
)

Se um recurso de Code Interpreter dedicado foi criado apenas para esse teste, ele pode ser excluído pelo console do Amazon Bedrock AgentCore ou pela AWS CLI.

Conclusão

Os Modelos de Linguagem Recursivos oferecem um caminho prático para processar documentos que excedem as janelas de contexto dos modelos atuais. Combinando o Amazon Bedrock AgentCore com o Strands Agents SDK, é possível implementar RLM para raciocinar sobre dados de entrada arbitrariamente longos através de execução iterativa de código e chamadas de sub-LLM.

Os resultados dos benchmarks são expressivos: Claude Opus 4.6 com RLM alcança 80% de precisão no LongBench v2 Financial QA — contra 66,7% do Long Context com janela de 1 milhão de tokens e 40% de especialistas humanos. Claude Sonnet 4.5 com RLM atinge 76% no LongBench v2 Code Repository QA — contra 20% do prompting base com janela de 200 mil tokens e 46% do Long Context.

Tarefas que exigem raciocínio sobre contextos longos — análise financeira, compreensão de repositórios de código, pesquisa em ciências da saúde e ciências da vida, revisão jurídica ou auditoria de conformidade — podem se beneficiar diretamente desse padrão arquitetural.

Recursos adicionais

• Amazon Bedrock AgentCore — documentação do serviço e capacidades para construir agentes prontos para produção.
• AgentCore Code Interpreter — documentação da ferramenta de interpretação de código usada nesta implementação.
• Strands Agents SDK — SDK de código aberto usado para construir a camada de orquestração do RLM.

Referências

• Zhang, A. L., Kraska, T., & Khattab, O. (2025). Recursive Language Models. arXiv:2512.24601
• Bai, Y., Tu, S., Zhang, J., Peng, H., Wang, X., Lv, X., Cao, S., Xu, J., Hou, L., Dong, Y., Tang, J., & Li, J. (2024). LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-context Multitasks. arXiv:2412.15204

Fonte

Break the context window barrier with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/break-the-context-window-barrier-with-amazon-bedrock-agentcore/)

O que foi anunciado

A AWS anunciou que o Amazon SageMaker Inference agora oferece suporte a APIs compatíveis com OpenAI nos endpoints de inferência. Na prática, isso significa que ferramentas e frameworks amplamente utilizados no ecossistema de Inteligência Artificial (IA) — como o OpenAI SDK, LangChain e Strands Agents — podem se conectar diretamente aos endpoints do SageMaker sem nenhuma adaptação especial.

O que muda na prática

A grande vantagem dessa novidade é a simplicidade da migração. Para quem já utiliza essas ferramentas apontando para outros serviços, a transição para o SageMaker exige apenas a troca da URL do endpoint. Não é necessário escrever código de integração personalizado, criar wrappers de SDK ou reescrever qualquer parte da aplicação existente.

Segundo a AWS, toda a lógica já construída continua funcionando normalmente: chamadas ao SDK, streaming e integrações com frameworks seguem operando exatamente como estavam — só que agora apontando para a infraestrutura gerenciada do SageMaker.

Benefícios imediatos

Com essa compatibilidade, quem adota o SageMaker Inference passa a ter acesso a uma série de vantagens de infraestrutura que não estavam disponíveis em outras plataformas de API:

• Escolha de instâncias de GPU: é possível selecionar o tipo de instância mais adequado para cada carga de trabalho.
• Dados dentro da sua própria Nuvem Privada Virtual (VPC): os dados não precisam sair do ambiente controlado da organização.
• Flexibilidade de modelos: qualquer modelo de código aberto ou ajustado (fine-tuned) pode ser utilizado.
• Auto-scaling configurável: as políticas de escalonamento automático podem ser ajustadas conforme a demanda de cada aplicação.

A autenticação é feita com as credenciais AWS já existentes, com renovação automática de token — sem nenhuma configuração adicional para gerenciar em produção.

Disponibilidade regional

O recurso já está disponível nas seguintes regiões: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Leste dos EUA (Ohio), Ásia-Pacífico (Mumbai), Ásia-Pacífico (Jacarta), Europa (Irlanda), Europa (Frankfurt), América do Sul (São Paulo), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Seul), Europa (Londres), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney) e Canadá (Central).

Para equipes brasileiras, vale destacar a presença da região América do Sul (São Paulo) na lista, o que facilita o uso com menor latência e em conformidade com requisitos de residência de dados locais.

Como saber mais

Para aprofundar o entendimento sobre essa novidade, a AWS disponibilizou um post de lançamento no blog oficial e a documentação do SageMaker Inference com detalhes técnicos sobre como configurar e utilizar as APIs compatíveis com OpenAI.

Fonte

Amazon SageMaker AI now supports OpenAI-compatible APIs for inference endpoints (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-sagemaker-ai-openai-apis/)

O que foi anunciado

A AWS anunciou uma nova capacidade do Amazon SageMaker Unified Studio: a criação automática de conexões para retentativas de jobs do AWS Glue entre sub-redes distintas. O objetivo é aumentar a resiliência de pipelines de dados, reduzindo o tempo de inatividade não planejado em cargas de trabalho críticas para o negócio.

O problema que essa novidade resolve

Pipelines de dados que rodam jobs do Glue dependem de conectividade de rede estável. Quando a sub-rede primária de um job fica indisponível — seja por esgotamento de endereços IP ou por degradação de uma Zona de Disponibilidade (ZA) — o job falha. Até então, a solução dependia de engenheiros configurando manualmente conectores de backup ou intervindo durante o incidente, o que aumenta o tempo de resposta e o risco de violação de SLAs.

Como funciona a automação

Com essa atualização, o SageMaker Unified Studio passa a provisionar automaticamente os conectores Glue necessários para todas as sub-redes definidas na configuração de VPC (Virtual Private Cloud — Nuvem Privada Virtual) do domínio. O fluxo funciona da seguinte forma:

• O administrador configura o domínio com múltiplas sub-redes privadas distribuídas entre diferentes Zonas de Disponibilidade.
• O sistema provisiona automaticamente os conectores necessários para todos os novos projetos criados naquele domínio.
• Se um job Glue falhar porque a sub-rede primária está indisponível, ele é automaticamente reexecutado em um conector de uma sub-rede alternativa.
• Nenhuma ação adicional é necessária após a configuração inicial da VPC no domínio.

Impacto prático para equipes de dados

A principal vantagem dessa automação é eliminar a necessidade de intervenção manual durante falhas de sub-rede. Equipes que operam pipelines críticos — com compromissos de SLA (Service Level Agreement — Acordo de Nível de Serviço) rigorosos — ganham uma camada extra de resiliência sem precisar arquitetar soluções de contorno manualmente. A configuração acontece uma única vez, no momento em que o domínio VPC é definido, e o restante é gerenciado pela plataforma.

Disponibilidade

O recurso já está disponível em todas as regiões AWS onde o Amazon SageMaker Unified Studio é suportado. Para aprofundar o entendimento técnico e conferir os detalhes de configuração, a AWS disponibiliza a documentação oficial do Amazon SageMaker Unified Studio.

Fonte

SageMaker Unified Studio automates Glue connector provisioning for cross-subnet job retries (https://aws.amazon.com/about-aws/whats-new/2026/05/sagemaker-unified-studio-glue/)

O problema que avaliadores de texto não conseguem resolver

Se você está construindo sistemas de compras visuais, extração de documentos ou análise de gráficos, você precisa de uma forma confiável de verificar se a resposta do modelo está realmente fundamentada na imagem de origem. Um avaliador que analisa apenas texto não consegue dizer se uma legenda descreve fielmente uma imagem, se o total extraído de uma nota fiscal bate com o documento, ou se um resumo de tela inventou um botão que nunca existiu na página.

O contexto do mercado reforça a urgência: a Gartner prevê que até 2030, 80% dos softwares empresariais serão multimodais — contra menos de 10% em 2024. Sem avaliação multimodal automatizada, as equipes ficam presas entre revisão humana cara e proxies de texto que não são confiáveis.

Os quatro novos avaliadores do Strands Evals

A AWS anunciou quatro novos avaliadores baseados em Modelos de Linguagem Multimodais de Grande Porte (MLLM) como juízes para tarefas de imagem para texto no Kit de Desenvolvimento de Software (SDK) do Strands Evals. Cada avaliador pontua saídas de imagem para texto comparando diretamente com a imagem de origem, enviando a imagem ao modelo juiz junto com a consulta, a resposta e, opcionalmente, uma resposta de referência. O juiz retorna uma pontuação ancorada na imagem e uma string de raciocínio útil para depuração.

Os quatro avaliadores cobrem os casos de uso mais comuns: legendagem de imagens, resposta visual a perguntas, interpretação de gráficos, extração de campos em documentos, Reconhecimento Ótico de Caracteres (OCR) e sumarização de capturas de tela. Veja o que cada um avalia:

• Qualidade Geral (Overall Quality): Pontuação em escala Likert de 1 a 5. Avalia a qualidade geral da resposta — relevância, precisão, profundidade e abrangência.
• Correção (Correctness): Binário. Verifica se a resposta é factualmente correta e completa considerando a imagem e a consulta. Detecta erros factuais, atributos errados, contagens, posições e omissões.
• Fidelidade (Faithfulness): Binário. Verifica se a resposta está ancorada na imagem sem alucinações — objetos inventados, inferências sem suporte ou vazamento de conhecimento externo.
• Seguimento de Instruções (Instruction Following): Binário. Verifica se a resposta respeita as restrições da consulta — formato, contagem, escopo e tópico.

Todos os avaliadores suportam dois modos de operação. O modo baseado em referência compara a resposta com uma resposta-ouro e é útil quando há conjuntos de teste rotulados disponíveis. O modo sem referência avalia apenas a partir da imagem, sendo a única opção quando o sistema opera com imagens ao vivo sem gabarito disponível.

Passo a passo: avaliando uma tarefa de leitura de gráfico

Para tornar a API concreta, o exemplo utilizado no anúncio original percorre um único Case. A entrada é um gráfico de barras com a receita média por assinatura paga de streaming por região (EUA/Canadá, Europa/Oriente Médio/África, Ásia-Pacífico, América Latina). O sistema sob teste é um agente de visão simples que responde uma pergunta específica sobre o gráfico.

Passo 1: Definir o Case e os avaliadores

O Case encapsula a imagem e a instrução em um MultimodalInput. Fornecer expected_output ativa a avaliação baseada em referência nos avaliadores que suportam esse modo.

from strands import Agent
from strands_evals import Case, Experiment
from strands_evals.evaluators import (
    MultimodalOverallQualityEvaluator,
    MultimodalCorrectnessEvaluator,
    MultimodalFaithfulnessEvaluator,
    MultimodalInstructionFollowingEvaluator,
)
from strands_evals.types import ImageData, MultimodalInput

cases = [
    Case[MultimodalInput, str](
        name="revenue-chart-1",
        input=MultimodalInput(
            media=ImageData(source="revenue_chart.jpeg"),
            instruction="Which region has the highest average revenue? "
                        "State the region name and the dollar amount shown in the chart.",
        ),
        expected_output="U.S. and Canada has the highest at $13.32.",
        metadata={"dataset": "ChartQA"},
    ),
]

evaluators = [
    MultimodalOverallQualityEvaluator(),        # Likert 1-5
    MultimodalCorrectnessEvaluator(),           # Binary
    MultimodalFaithfulnessEvaluator(),          # Binary
    MultimodalInstructionFollowingEvaluator(),  # Binary
]

Passo 2: Configurar a tarefa e executar o experimento

A função de tarefa recebe cada Case, executa o modelo de visão com a imagem e a instrução, e retorna a string de resposta para ser avaliada.

agent = Agent(callback_handler=None)
task_output = None

def run_task(case):
    global task_output
    image = case.input.media
    messages = [
        {"image": {"format": image.format or "png", "source": {"bytes": image.to_bytes()}}},
        {"text": case.input.instruction},
    ]
    task_output = str(agent(messages))
    return task_output

reports = await Experiment(cases=cases, evaluators=evaluators).run_evaluations_async(
    task=run_task,
    max_workers=1,
)

Passo 3: Inspecionar o relatório

Cada relatório contém pontuações por caso, resultados de aprovação/reprovação e raciocínios:

print(f"Task Output:\n{task_output}\n")
print("=" * 50)
for name, report in zip(
    ["Quality", "Correctness", "Faithfulness", "Instruction"],
    reports,
):
    reason = report.reasons[0] if report.reasons else ""
    status = "PASS" if report.test_passes[0] else "FAIL"
    print(f"{name}: {report.scores[0]:.2f} [{status}]")
    print(f"  Reason: {reason}\n")

A execução sobre o gráfico do exemplo produz o seguinte resultado:

Task Output:
According to the chart, the U.S. and Canada region has the highest average revenue per paying streaming membership at $13.32.

==================================================
Quality: 1.00 [PASS]
Reason: The response correctly identifies U.S. and Canada as the highest revenue region at $13.32, directly addressing both parts of the instruction. The answer is factually accurate based on the chart data and provides appropriate context.
Correctness: 1.00 [PASS]
Reason: The factual claims are accurate. U.S. and Canada is correctly identified as the region with the highest bar in the chart, and $13.32 is the exact dollar amount visible on that bar. No factual errors found.
Faithfulness: 1.00 [PASS]
Reason: The response is fully grounded in the image. Each claim can be directly verified against the chart. U.S. and Canada shows $13.32 and is visibly the highest bar. No hallucinations detected.
Instruction: 1.00 [PASS]
Reason: Response perfectly follows instruction by stating both required elements: region name (U.S. and Canada) and dollar amount ($13.32). Matches expected output factually with no constraint violations.

Dois pontos importantes a observar: cada avaliador retorna uma string de raciocínio além da pontuação — essencial para depuração quando uma execução falha em Integração Contínua (CI). Além disso, o mesmo Case foi pontuado por quatro juízes independentes em um único Experiment, mantendo o fluxo idêntico ao de avaliações com texto apenas.

Rubricas personalizadas

Para critérios específicos de domínio, a classe base aceita uma string de rubrica arbitrária:

from strands_evals.evaluators import MultimodalOutputEvaluator

medical_eval = MultimodalOutputEvaluator(rubric="""Rate diagnostic accuracy:
- 1.0: All findings correctly identified with proper terminology.
- 0.5: Key findings identified but imprecise terminology.
- 0.0: Critical findings missed or misidentified.""")

O que os experimentos revelaram

O juiz precisa ver a imagem?

Uma dúvida natural é se um juiz apenas de texto, recebendo uma descrição detalhada da imagem gerada automaticamente, consegue substituir um juiz multimodal. Os experimentos compararam o MLLM-as-a-Judge (imagem mais texto) contra o Modelo de Linguagem de Grande Porte (LLM) como juiz com descrições longas e curtas da imagem. O resultado foi claro: o juiz multimodal se alinhou mais de perto com as pontuações humanas do que qualquer variante apenas de texto. Além disso, quando se conta a chamada extra ao LLM para gerar a descrição, a rota apenas de texto não é significativamente mais barata ou rápida. Tendo um juiz multimodal disponível, o recomendado é usá-lo diretamente.

Qual modelo usar como juiz no Amazon Bedrock?

A AWS avaliou vários MLLMs disponíveis no Amazon Bedrock como juízes, usando alinhamento com pontuações humanas, custo por consulta e latência como critérios. O Anthropic Claude Sonnet 4.6 no Amazon Bedrock ofereceu o melhor equilíbrio entre precisão e custo e é utilizado como modelo juiz padrão nos avaliadores multimodais. Duas observações gerais também se confirmaram: modelos maiores com capacidade de raciocínio são mais confiáveis como juízes; e modelos de preço premium não apresentaram ganho mensurável de precisão sobre os de nível intermediário para essa tarefa.

Quais escolhas de design de prompt realmente importam?

Os experimentos testaram diferentes abordagens de design de prompt. As conclusões que se generalizaram foram:

• Peça ao juiz para raciocinar antes de pontuar. Esta foi a escolha de maior impacto. Saída apenas com pontuação é mais barata e consistente, mas o alinhamento com pontuações humanas cai de forma perceptível.
• Inclua alguns exemplos de calibração diversificados. O alinhamento melhorou de forma monotônica ao passar de zero exemplos para um punhado deles.
• Use uma rubrica multidimensional detalhada (precisão visual, aderência a instruções, completude, coerência) em vez de um único prompt holístico. Separar dimensões evita que uma pontuação vaga absorva modos de falha distintos.

Referência vs. sem referência: quando usar cada modo

Injetar uma resposta de referência no prompt do juiz ajuda avaliadores ancorados em conteúdo. Qualidade Geral, Correção e Fidelidade se alinharam mais de perto com o julgamento humano quando uma referência estava disponível. Seguimento de Instruções teve comportamento oposto: adicionar conteúdo de referência distraiu o juiz da verificação de restrições estruturais (formato, escopo, ordem, contagem) que são determinadas pela consulta e resposta isoladamente. A diretriz geral é: use referências para métricas ancoradas em conteúdo e dispense-as para métricas estruturais como seguimento de instruções.

Boas práticas recomendadas

• Use o MultimodalOverallQualityEvaluator para verificações rápidas de sanidade e adicione os avaliadores binários direcionados (Correção, Fidelidade, Seguimento de Instruções) à medida que diagnostica modos de falha específicos.
• Comece com o Claude Sonnet 4.6 como juiz e migre para MLLMs menores com capacidade de raciocínio no Amazon Bedrock apenas se custo ou latência forem fatores dominantes.
• Evite modelos pequenos para julgamento.
• Mantenha o formato de saída com raciocínio mais pontuação. Saída apenas com pontuação é tentadora pelo custo, mas o alinhamento com pontuações humanas cai de forma perceptível.
• Use referências para correção, fidelidade e qualidade geral quando disponíveis. Dispense-as para seguimento de instruções.

Próximos passos

Os quatro novos avaliadores MLLM-as-a-Judge no Strands Evals movem a avaliação de imagem para texto de revisão humana cara ou proxies de texto não confiáveis para pontuação automatizada ancorada na imagem. Cada avaliador tem como alvo um modo de falha distinto, suporta avaliação baseada em referência e sem referência, e retorna raciocínio diagnóstico junto com cada pontuação.

Esta é a primeira etapa em direção a uma avaliação multimodal mais ampla no Strands Evals. Os trabalhos futuros incluem avaliação em nível de etapa para uso de ferramentas multimodais e trajetórias de agentes, além de combinações adicionais de modalidades como texto para imagem, vídeo para texto e áudio para texto.

Para começar, instale o Strands Evals com o comando:

pip install strands-agents-evals

Em seguida, explore os recursos disponíveis: leia a documentação do Strands Evals para uma visão geral do fluxo Case → Experiment → Report; consulte a referência do avaliador multimodal para a API completa; experimente o exemplo de avaliador multimodal no repositório de documentação do Strands Agents; e compartilhe feedback e solicitações de funcionalidades no GitHub Issues.

Fonte

Multimodal evaluators: MLLM-as-a-judge for image-to-text tasks in Strands Evals (https://aws.amazon.com/blogs/machine-learning/multimodal-evaluators-mllm-as-a-judge-for-image-to-text-tasks-in-strands-evals/)

Voz em tempo real: o desafio que o modelo request-response não resolve

Agentes de voz, legendagem ao vivo, análise de contact centers e ferramentas de acessibilidade têm algo em comum: todas dependem de transcrição de fala em tempo real. Isso significa que a aplicação precisa transmitir o áudio enquanto já recebe o texto de volta — simultaneamente, por uma única conexão persistente.

O modelo tradicional de requisição e resposta (request-response) não serve para esse cenário. Nele, a transcrição só começa depois que o arquivo de áudio inteiro foi recebido, adicionando uma latência que quebra completamente a experiência em tempo real.

A partir de novembro de 2025, a AWS passou a oferecer o streaming bidirecional para inferência em tempo real no Amazon SageMaker AI, permitindo que dados fluam continuamente nas duas direções entre clientes e contêineres de modelo. Combinado com a Realtime API do vLLM — que usa WebSockets para streaming bidirecional entre cliente e servidor — essa dupla forma uma solução completa para aplicações de voz.

O post original da AWS demonstra como implantar o Voxtral-Mini-4B-Realtime-2602, o modelo compacto de fala em tempo real da Mistral AI, em um endpoint do SageMaker AI usando um contêiner vLLM com streaming bidirecional. O exemplo completo está disponível no repositório GitHub.

O que cada componente entrega

Construir uma aplicação de voz em produção exige que vários componentes de infraestrutura funcionem juntos dentro de orçamentos de latência muito apertados. O SageMaker AI e o vLLM resolvem partes distintas dessa pilha:

Modelo de fala com serving eficiente em GPU

No núcleo de qualquer aplicação de voz está um modelo de Reconhecimento Automático de Fala (ASR) que processa o áudio de forma incremental, produzindo tokens de transcrição à medida que o áudio chega — sem esperar pela gravação completa. O vLLM serve esses modelos por meio de sua Realtime API, um endpoint nativo WebSocket em /v1/realtime que aplica execução de grafo CUDA por partes (piecewise CUDA graph execution) para reduzir a sobrecarga de lançamento de kernels de GPU, resultando em menor latência por token durante a transcrição em streaming. Por ser open source, o vLLM garante controle total sobre configuração do modelo, quantização e configurações de compilação, sem dependência de fornecedor (vendor lock-in) na camada de serving.

Infraestrutura de streaming bidirecional

O SageMaker AI resolve o problema do protocolo com streaming bidirecional nativo via HTTP/2 na porta 8443, fazendo a ponte automaticamente entre o protocolo de event stream HTTP/2 no lado do cliente e o WebSocket no lado do contêiner. Não é necessário construir ou gerenciar essa camada de tradução de protocolo — o SageMaker AI cuida disso de forma transparente.

Processamento e codificação de áudio

O áudio bruto de microfones ou sistemas de telefonia chega em vários formatos e taxas de amostragem. Antes de chegar ao modelo, ele precisa ser reamostrado (tipicamente para 16 kHz mono PCM16), dividido em segmentos de tamanho adequado e codificado em base64 para transmissão. O pipeline do lado do cliente cuida dessa conversão, enquanto a Realtime API do vLLM define o protocolo: chunks PCM16 em base64 entram via WebSocket, e os tokens de transcrição voltam em streaming.

Gerenciamento de conexão e resiliência

O SageMaker AI mantém conexões WebSocket com frames de keepalive ping/pong, verifica a saúde do contêiner e fornece monitoramento em nível de endpoint pelo Amazon CloudWatch — tudo isso sem instrumentação customizada.

Visão geral da solução

A solução conecta três camadas:

• Cliente → SageMaker AI: A aplicação se conecta ao endpoint de runtime do SageMaker AI na porta 8443 via HTTP/2. Cada mensagem JSON do protocolo vLLM Realtime (como input_audio_buffer.append ou transcription.delta) é enviada dentro de um RequestPayloadPart com DataType definido como "UTF8".
• SageMaker AI → Contêiner Docker: O SageMaker AI faz a ponte automaticamente entre o event stream HTTP/2 e o WebSocket, estabelecendo uma conexão WebSocket com o contêiner em ws://localhost:8080/invocations-bidirectional-stream e encaminhando os frames de dados nos dois sentidos.
• Contêiner Docker: Dentro do contêiner, uma bridge leve em FastAPI (app.py) escuta na porta 8080 e, ao receber uma conexão WebSocket do SageMaker AI, abre uma segunda conexão WebSocket para a Realtime API do vLLM em ws://localhost:8081/v1/realtime, encaminhando mensagens bidirecionalmente.

O protocolo da Realtime API

A Realtime API fornece transcrição de áudio em streaming via WebSocket. O áudio deve ser codificado como base64 PCM16 a 16 kHz mono. O fluxo de mensagens funciona assim:

• Cliente conecta em ws://host/v1/realtime
• Servidor envia evento session.created
• Cliente envia opcionalmente session.update com modelo e parâmetros
• Cliente envia input_audio_buffer.commit quando pronto para enviar áudio
• Cliente envia eventos input_audio_buffer.append com chunks PCM16 em base64
• Servidor envia eventos transcription.delta com texto incremental
• Servidor envia transcription.done com a transcrição final e estatísticas de uso
• Repete a partir do passo 5 para o próximo enunciado

O modelo começa a transcrever assim que tem contexto de áudio suficiente, enviando tokens de transcription.delta de volta ao cliente enquanto ele continua enviando chunks de áudio — sem necessidade de esperar o envio completo.

Construindo o contêiner vLLM customizado

A solução parte do SageMaker AI vLLM Deep Learning Container e adiciona três elementos: o label Docker de streaming bidirecional, uma bridge WebSocket que traduz entre as rotas esperadas pelo SageMaker AI e os caminhos nativos da API do vLLM, e um entrypoint que executa ambos os processos.

FROM public.ecr.aws/deep-learning-containers/vllm:0.17.1-gpu-py312-cu129-ubuntu22.04-sagemaker-v1.0-soci

# Tell SageMaker AI this container supports bidirectional streaming
LABEL com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true

WORKDIR /opt/ml/code

# Install bridge dependencies
COPY requirements.txt .
RUN pip install --upgrade --no-cache-dir -r requirements.txt

# WebSocket bridge: routes /invocations-bidirectional-stream → /v1/realtime
COPY app.py .
COPY sagemaker-entrypoint.sh entrypoint.sh
RUN chmod +x entrypoint.sh

ENTRYPOINT ["./entrypoint.sh"]

HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 \
    CMD curl -f http://localhost:8080/ping || exit 1

O label com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true sinaliza ao SageMaker AI que o contêiner suporta streaming bidirecional. Sem esse label, o SageMaker AI não estabelecerá conexões WebSocket com o contêiner.

A bridge (app.py) é uma aplicação FastAPI que escuta na porta 8080 e encaminha conexões WebSocket para o endpoint /v1/realtime do vLLM na porta interna 8081. Ela também faz proxy dos health checks de /ping para o /health do vLLM.

VLLM_WS_URL = "ws://localhost:8081/v1/realtime"

@app.websocket("/invocations-bidirectional-stream")
async def websocket_bridge(sm_ws: WebSocket):
    await sm_ws.accept()
    async with websockets.connect(VLLM_WS_URL) as vllm_ws:
        async def sm_to_vllm():
            """Forward SageMaker AI → vLLM."""
            while True:
                message = await sm_ws.receive()
                if "text" in message and message["text"]:
                    await vllm_ws.send(message["text"])
                elif "bytes" in message and message["bytes"]:
                    # Fallback for non-UTF8 clients
                    await vllm_ws.send(message["bytes"].decode("utf-8"))

        async def vllm_to_sm():
            """Forward vLLM → SageMaker AI."""
            async for msg in vllm_ws:
                if isinstance(msg, str):
                    await sm_ws.send_text(msg)
                elif isinstance(msg, bytes):
                    await sm_ws.send_bytes(msg)

        await asyncio.gather(sm_to_vllm(), vllm_to_sm())

Implantando no endpoint do SageMaker AI

As variáveis de ambiente SM_VLLM_* configuram os parâmetros do servidor vLLM:

vllm_env = {
    "SM_VLLM_MAX_MODEL_LEN": "45000",
    "SM_VLLM_COMPILATION_CONFIG": '{"cudagraph_mode": "PIECEWISE"}'
}

O Voxtral-Mini-4B suporta até 262.144 tokens de contexto. O valor MAX_MODEL_LEN=45000 é suficiente para gravar ao vivo aproximadamente uma hora de áudio (3600 segundos / 0,08 segundos por token). O COMPILATION_CONFIG com cudagraph_mode: PIECEWISE oferece otimização de grafo CUDA para melhor throughput de inferência.

O trecho abaixo cria o endpoint no SageMaker AI:

# Create model
voxtral_model = Model.create(
    model_name=model_name,
    primary_container=ContainerDefinition(
        image=inference_image,
        model_data_source=ModelDataSource(
            s3_data_source=S3ModelDataSource(
                s3_uri=f"{model_artifact}/",
                s3_data_type="S3Prefix",
                compression_type="None",
            )
        ),
        environment=vllm_env
    ),
    execution_role_arn=role,
)

# Create config
endpoint_config = EndpointConfig.create(
    endpoint_config_name=endpoint_config_name,
    production_variants=[
        ProductionVariant(
            variant_name="AllTraffic",
            model_name=model_name,
            initial_variant_weight=1.0,
            instance_type=instance_type,
            initial_instance_count=1,
            model_data_download_timeout_in_seconds=health_check_timeout,
        )
    ]
)

# Create endpoint
endpoint = Endpoint.create(
    endpoint_name=endpoint_name,
    endpoint_config_name=endpoint_config_name
)
endpoint.wait_for_status("InService")

Testando com streaming bidirecional

Com o endpoint em execução, a invocação é feita pelo SDK Python aws-sdk-sagemaker-runtime-http2, que se comunica via event streams HTTP/2 na porta 8443 do endpoint de runtime do SageMaker AI.

O repositório inclui um cliente completo sagemaker_bidi_client.py que encapsula o SDK de streaming bidirecional em uma classe SageMakerRealtimeClient. Quando transcribe_audio() é executado, ele primeiro envia um evento session.update para selecionar o modelo e depois transmite o arquivo de áudio em chunks de 4 KB PCM16. O loop de recebimento roda como uma asyncio.Task em segundo plano, enquanto a corrotina principal envia os chunks de áudio — garantindo que ambas as direções do stream HTTP/2 estejam ativas simultaneamente.

O detalhe-chave que torna esse overlap observável é o await asyncio.sleep(chunk_duration) após cada envio. Ele cadencia a transmissão para corresponder à reprodução em tempo real (~128 ms por chunk de 4 KB a 16 kHz) e cede o controle ao event loop, dando à tarefa de recebimento a chance de processar eventos transcription.delta enquanto mais áudio ainda está sendo enviado.

Para executar o cliente:

python sagemaker_bidi_client.py ./audio.wav \
    --region us-east-1

Demo ao vivo com microfone e Gradio

O cliente baseado em arquivo é útil para testes, mas o streaming bidirecional entrega sua menor latência com áudio ao vivo. O repositório inclui um cliente de microfone baseado em Gradio (sagemaker_bidi_microphone_client.py) que captura o áudio do microfone e o transmite ao SageMaker AI em tempo real:

python sagemaker_bidi_microphone_client.py \
    --endpoint-name  \
    --region us-east-1

O cliente de microfone usa a mesma configuração DataType="UTF8" e o mesmo protocolo da Realtime API do vLLM que o cliente baseado em arquivo. Ele captura o áudio do navegador via Gradio, reamosta para 16 kHz PCM16, codifica cada chunk em base64 e o envia pelo stream bidirecional do SageMaker AI. O texto de transcrição é atualizado na interface à medida que o usuário fala, sem esperar o fim do enunciado.

Considerações importantes

• A Realtime API do vLLM espera áudio como PCM16 codificado em base64 a 16 kHz mono. Se o áudio de origem usar um formato ou taxa de amostragem diferente, converta antes de transmitir.
• O Voxtral-Mini-4B-Realtime-2602 é um modelo de 4 bilhões de parâmetros e cabe em uma única GPU. Uma instância ml.g6.4xlarge (1x NVIDIA L4) é suficiente para hospedá-lo.
• O SageMaker AI mantém a conexão WebSocket com frames ping/pong a cada 60 segundos, e a conexão é encerrada se 5 pings consecutivos ficarem sem resposta. Para sessões longas, o cliente deve tratar a reconexão em vez de assumir que o stream permanecerá aberto indefinidamente.
• O tamanho do chunk e o cadenciamento também valem ser ajustados. O exemplo usa chunks de 4 KB, equivalente a aproximadamente 128 ms de áudio a 16 kHz PCM16. Chunks menores reduzem a latência, mas aumentam a sobrecarga por mensagem; chunks maiores melhoram o throughput ao custo de maior latência.

Limpeza dos recursos

Para evitar cobranças contínuas, é importante excluir os recursos criados após os testes. O endpoint do SageMaker AI cobra pela instância subjacente enquanto estiver ativo, portanto removê-lo é o passo mais crítico. O notebook que acompanha a solução inclui uma célula de limpeza que exclui o endpoint, a configuração do endpoint e o modelo. Se a imagem de contêiner customizada no Amazon Elastic Container Registry (ECR) ou os artefatos de modelo no Amazon Simple Storage Service (S3) não forem mais necessários, esses recursos devem ser excluídos separadamente para evitar cobranças de armazenamento.

Conclusão e próximos passos

A combinação do SageMaker AI com o vLLM demonstra como é possível ir de um modelo de fala no Hugging Face a um serviço de transcrição em tempo real totalmente gerenciado, sem construir infraestrutura de streaming customizada nem gerenciar servidores de GPU. A infraestrutura de streaming bidirecional do SageMaker AI atua como uma ponte transparente entre event streams HTTP/2 (lado do cliente) e WebSocket (lado do contêiner).

Esse padrão vai além da transcrição de fala. Casos de uso que exigem comunicação contínua e bidirecional — agentes de voz, tradução em tempo real, geração de áudio interativa ou diálogo em streaming com múltiplos turnos — podem usar a mesma arquitetura.

Para ir além, a AWS sugere as seguintes direções:

• Estender a demo Gradio em uma aplicação completa: Use o cliente de microfone ao vivo como ponto de partida e adicione funcionalidades como exportação de transcrição ou sumarização encadeando a saída de transcrição em um LLM de texto.
• Ajustar o endpoint para seus requisitos de latência e custo: Experimente tipos de instância, tamanhos de chunk e configurações de compilação do vLLM para encontrar o equilíbrio certo para sua carga de trabalho.
• Implantar um modelo diferente: Substitua o Voxtral-Mini-4B-Realtime-2602 por outro modelo suportado pela Realtime API do vLLM atualizando o artefato do modelo e o identificador nos clientes.
• Aprofundar o conhecimento sobre streaming bidirecional: Consulte a documentação oficial para entender o contrato completo do event stream HTTP/2 e aplicá-lo a outros casos de uso.

O notebook completo, o cliente baseado em arquivo e a demo ao vivo com microfone estão disponíveis no GitHub.

Pré-requisitos

Para reproduzir a solução, são necessários:

• Uma conta AWS com permissões do SageMaker AI (incluindo sagemaker:InvokeEndpoint* para streaming bidirecional)
• Ambiente Docker (SageMaker AI Studio com Docker habilitado ou uma máquina local)
• Python 3.12+
• Acesso ao modelo Voxtral-Mini-4B-Realtime-2602 no Hugging Face
• O pacote Python aws-sdk-sagemaker-runtime-http2 para invocar a API de streaming bidirecional

Fonte

Build real-time voice applications with Amazon SageMaker AI and vLLM (https://aws.amazon.com/blogs/machine-learning/build-real-time-voice-applications-with-amazon-sagemaker-ai-and-vllm/)