Amazon Nova 2 Lite: o que revisar ao migrar do Nova 1 quando o contexto chega a um milhão de tokens

O Nova 2 Lite muda o contrato de integração, não apenas o nome do modelo

O Amazon Nova 2 Lite é um modelo proprietário disponível por meio de serviços gerenciados da AWS. Seu identificador base declarado é `amazon.nova-2-lite-v1:0`. A ficha oficial informa lançamento em 2 de dezembro de 2025, estabelece uma janela de contexto de até um milhão de tokens e define uma saída máxima declarada de 64.000 tokens. Ela também indica que o fim de vida não ocorrerá antes de 2 de dezembro de 2026 e prevê um período mínimo de legado. Esses dados definem limites publicados do serviço, e não um resultado garantido para uma carga de trabalho específica.

O qualificativo “Lite” não permite concluir que a integração será simples, que a latência será baixa, que o custo por tarefa será menor ou que o comportamento será equivalente ao do Nova 1 Lite, Pro ou Premier. Tampouco prova que um prompt, um esquema de saída ou uma automação existente manterá sua qualidade após a troca de modelo. Uma migração responsável precisa tratar o modelo, a API escolhida, o perfil de inferência e a configuração de raciocínio como partes de um contrato que deve ser testado novamente.

O contexto amplo pode alterar o desenho de uma aplicação. Ele pode reduzir a necessidade de dividir determinados documentos ou históricos, mas não elimina a necessidade de selecionar informações relevantes, restringir permissões, controlar dados sensíveis nem medir resultados. Um contexto muito grande também não implica que todo o conteúdo terá o mesmo peso na resposta, nem que o modelo produzirá respostas factualmente corretas. Trata-se de propriedades distintas: capacidade de entrada, comportamento de recuperação dentro do contexto, precisão e utilidade operacional.

Portanto, a diferença relevante não é apenas quantitativa. Ao adotar o Nova 2 Lite, uma equipe precisa decidir qual modalidade de invocação utilizará, quais entradas permitirá, se habilitará o raciocínio estendido, como receberá e executará solicitações de ferramentas e qual rota de inferência é compatível com suas obrigações de residência de dados. Cada decisão requer evidências obtidas no próprio ambiente.

Inventário do contrato: identificador, modalidades e limites que convém definir antes dos testes

O primeiro artefato da migração deveria ser um inventário versionado. Ele deve incluir o identificador do modelo, a região ou o perfil de inferência selecionado, a API de invocação, os tipos de conteúdo aceitos pela aplicação e os limites que a equipe aplicará antes de chamar o serviço. A ficha do Nova 2 Lite declara entrada de texto, imagem e vídeo. O tratamento de documentos, os tamanhos específicos dos arquivos, as combinações de blocos de conteúdo e a disponibilidade efetiva devem ser conferidos na documentação vigente da API e com solicitações de teste.

A janela de um milhão de tokens exige uma leitura precisa. Ela é uma capacidade máxima de contexto declarada, não um convite para enviar sempre o máximo. Uma aplicação pode encontrar limites práticos pela composição da solicitação, pela saída pedida, por seus próprios limites de memória, pelos tempos de rede ou por seus objetivos de latência. Também deve registrar quantos tokens entram e saem em cada operação, pois sem essa telemetria não conseguirá identificar regressões ao mudar o tamanho dos documentos ou o comportamento do modelo.

A saída máxima declarada de 64.000 tokens também amplia a superfície de risco. Uma saída longa pode exceder limites de gateways, buffers, filas, interfaces de usuário ou validadores posteriores. Se o produto precisa de JSON ou de outro formato estruturado, não basta verificar que o modelo gera uma resposta longa: é preciso confirmar que o resultado pode ser recebido integralmente, validado, rejeitado com segurança e corrigido ou reenviado de acordo com uma política explícita.

Convém separar os limites do provedor dos limites internos. Por exemplo, uma organização pode impor um máximo de contexto menor para proteger latência e custo, um máximo de saída para determinada interface e um limiar de tamanho diferente para conteúdo multimodal. Essas restrições devem constar na configuração e nos testes, e não apenas no conhecimento informal da equipe.

Converse e Invoke: a abstração escolhida condiciona a portabilidade

A documentação do Amazon Nova apresenta o Converse como uma interface consistente para interagir com modelos e descreve o Invoke como um caminho com formato nativo que não é portátil. A consequência prática é clara: a escolha não deve ser feita apenas pela conveniência inicial. O Converse pode reduzir diferenças de integração quando uma aplicação precisa trabalhar com uma interface comum, enquanto o Invoke pode exigir que o cliente conheça e mantenha um formato específico do modelo.

Isso não torna uma interface universalmente superior à outra. A equipe deve confirmar que a API escolhida aceita as modalidades, configurações e campos de resposta de que precisa. Quando um formato nativo é usado, o teste deve cobrir a serialização exata da solicitação, a análise de cada bloco de resposta, os motivos de parada e os erros. Quando uma interface consistente é usada, também é necessário verificar que sua abstração não oculta opções necessárias nem altera a semântica esperada pelo produto.

O limite de tempo merece uma revisão arquitetural. A AWS alerta que solicitações de inferência do Nova podem exigir timeouts de até 60 minutos e que o cliente precisa ajustá-los. Isso afeta SDKs, balanceadores, proxies, workers, limites de execução de funções e a experiência do usuário. Apenas elevar um timeout pode aumentar os recursos retidos e não resolve cancelamento, tentativas novamente nem deduplicação.

Uma operação longa deve ter uma política explícita: qual componente pode cancelá-la, como o cancelamento é propagado, o que é registrado se o cliente se desconecta, quando é possível tentar novamente e como evitar executar duas vezes uma ação externa. Essas decisões são especialmente importantes se a conversa puder acionar ferramentas ou se a resposta posterior alimentar um sistema automatizado.

Raciocínio estendido: configurar, medir e não confundir com uma explicação completa

O Nova 2 oferece raciocínio estendido por meio de `reasoningConfig`. A documentação descreve os níveis de orçamento `low`, `medium` e `high`. Ativar essa função não equivale a acrescentar uma explicação legível e completa de como uma resposta foi obtida. A resposta pode incluir blocos `reasoningContent`, mas a AWS informa que o conteúdo de raciocínio é retornado com redações. Por isso, esses blocos não devem ser tratados como um registro exaustivo de decisões nem como evidência suficiente para auditoria de negócio.

O raciocínio estendido deve ser avaliado como uma variante de configuração independente. Um conjunto de testes adequado compara, para cada tarefa, o modo sem raciocínio e cada orçamento que o produto considere aceitável. Deve coletar taxa de sucesso segundo uma rubrica definida, validade da saída estruturada, duração total, uso de tokens disponível na telemetria, frequência de novas tentativas e resultados de segurança. A escolha do orçamento deve responder a um objetivo medido, e não à suposição de que um nível maior melhora todos os casos.

Há também uma questão de rastreabilidade. Registrar a configuração solicitada, o identificador do modelo, a API e o perfil de inferência permite reproduzir uma classe de incidente. Contudo, esses registros não substituem a observação das entradas, saídas, decisões da aplicação e resultados das ferramentas autorizadas. Quando os dados contiverem informações pessoais ou confidenciais, o registro deve aplicar as mesmas políticas de minimização, acesso e retenção usadas no restante do sistema.

Não há base na documentação fornecida para afirmar que o raciocínio estendido garanta respostas mais corretas, mais seguras ou mais rápidas. A decisão razoável é limitar seu uso às tarefas nas quais a avaliação própria mostrar uma melhoria suficiente em relação aos seus efeitos sobre duração e operação.

Function calling: o modelo propõe; a aplicação autoriza e executa

A documentação do Nova 2 descreve o function calling como um fluxo no qual o cliente define ferramentas por meio de JSON Schema. Quando o modelo solicita uma ferramenta, a resposta inclui um bloco `toolUse` e um motivo de parada `tool_use`. A responsabilidade por executar a ferramenta recai explicitamente sobre o cliente, que deve devolver o resultado ao modelo se quiser continuar a interação. Essa divisão é essencial: uma solicitação gerada pelo modelo não é uma autorização para executar uma ação externa.

A camada de aplicação deve validar o nome da ferramenta e seus argumentos contra um contrato estrito, verificar a identidade e as permissões do usuário, aplicar limites de frequência e escopo, executar com credenciais de menor privilégio e converter erros em um resultado controlado. Ela também deve decidir como tratar argumentos ambíguos, recursos inexistentes, respostas com dados sensíveis, erros transitórios e operações não idempotentes. Um JSON Schema melhora a definição da interface, mas não substitui controles de autorização nem validação semântica.

A proposta de migração menciona ferramentas integradas, como grounding na web ou interpretador de código. As fontes verificadas fornecidas para este texto documentam o fluxo de function calling, mas não permitem estabelecer aqui quais ferramentas integradas estão disponíveis para o Nova 2 Lite, sob quais condições, em quais rotas de invocação ou regiões, nem como elas tratam dados e permissões. Essa é uma incerteza que deve ser resolvida com documentação específica e vigente antes de desenhar um fluxo que dependa delas.

O teste de ferramentas deve incluir sucesso e falha. Não basta demonstrar que o modelo seleciona uma função em uma consulta simples. É necessário testar argumentos válidos e inválidos, permissões negadas, timeouts, indisponibilidade do serviço externo, resultados parciais, repetição de chamadas e rejeição de uma ação potencialmente danosa. A aplicação deve manter o controle sobre o efeito externo mesmo se o modelo insistir em uma chamada.

Migrar do Nova 1: substituir um ID não demonstra equivalência

Não há, nas fontes fornecidas, uma matriz oficial que permita afirmar uma equivalência funcional direta entre o Nova 2 Lite e o Nova 1 Lite, Pro ou Premier. Portanto, não é rigoroso prometer que a substituição do identificador preservará qualidade, formatos, seleção de ferramentas, latência ou comportamento multimodal. A migração deve ser definida como uma substituição sujeita a avaliação, e não como uma atualização transparente.

O ponto de partida é congelar uma linha de base do sistema atual. Para cada fluxo, a equipe deveria preservar entradas representativas permitidas, configuração de geração, prompts de sistema e de usuário, ferramentas disponíveis, respostas esperadas ou rubricas de revisão, duração e taxa de falhas. Em seguida, pode executar o mesmo conjunto no Nova 2 Lite, diferenciando o resultado por API, orçamento de raciocínio e perfil de inferência. Sem essa separação, uma regressão pode ser atribuída incorretamente ao modelo quando, na verdade, decorre da rota de invocação ou de uma mudança de prompt.

Casos longos são obrigatórios se o motivo da mudança for o contexto amplo. Eles devem incluir informações relevantes distribuídas, conteúdo irrelevante, contradições deliberadas e os limites internos da aplicação. Os casos multimodais devem avaliar cada modalidade utilizada pelo produto e confirmar que os mecanismos de envio, conversão e observabilidade funcionam. As saídas estruturadas precisam de validação automática e revisão dos casos que falharem; a aparência de um JSON correto não prova que seus valores sejam adequados.

A decisão de implantação pode ser gradual. Uma equipe pode manter o modelo anterior para os fluxos que não atingirem os limiares, limitar o Nova 2 Lite a tarefas observáveis e reversíveis ou desativar raciocínio e ferramentas até concluir os testes. Essa prudência não é uma avaliação negativa do modelo; é uma forma de não confundir capacidades declaradas com resultados demonstrados em um sistema concreto.

Regiões, perfis de inferência e residência: transformar uma política em evidência

A disponibilidade regional e a residência de dados não devem ser deduzidas pelo nome da região da qual uma solicitação é enviada. O Amazon Bedrock distingue inferência na região, inferência entre regiões por meio de perfis geográficos e inferência entre regiões por meio de perfis globais. A documentação da AWS informa que um perfil geográfico processa solicitações dentro da geografia definida, enquanto um perfil global pode processá-las em qualquer região comercial compatível.

Isso exige tratar o perfil de inferência como um parâmetro de conformidade, e não como um detalhe de desempenho. Antes de habilitar o Nova 2 Lite, a organização precisa consultar a matriz vigente de disponibilidade por modelo e região, identificar qual rota sua configuração seleciona e confrontá-la com sua política contratual, regulatória e de classificação de dados. A disponibilidade muda com o tempo; uma conclusão obtida durante um teste não deve substituir um controle de mudanças.

A AWS documenta que o CloudTrail registra `additionalEventData.inferenceRegion`. Esse campo pode fornecer evidência operacional do local de processamento utilizado por uma solicitação. Ainda assim, a equipe de conformidade deve determinar qual período de retenção, qual cobertura de registros e quais controles adicionais são necessários. Um registro útil para diagnóstico não certifica, por si só, que toda a arquitetura atende a uma obrigação setorial.

O teste deve ser realizado com a identidade, a conta, a região e o perfil de inferência que serão usados em produção. Ele deve verificar que os eventos esperados são gerados, que o campo é preservado e que uma alteração não autorizada de perfil pode ser detectada. Se a política proíbe uma rota global, essa proibição deve se materializar em controles de configuração e permissões, e não depender de uma convenção de nomes.

Critérios de aceitação e limites do que é possível concluir

Uma bateria mínima de aceitação deveria cobrir contexto curto e longo, entradas multimodais efetivamente usadas pelo produto, respostas estruturadas válidas e inválidas, solicitações de ferramenta corretas e malformadas, negativas de permissão, falhas de ferramentas, cancelamento, novas tentativas e repetição de uma mesma solicitação. Ela deve medir percentis de latência em toda a cadeia, inclusive nos componentes intermediários, porque o timeout do cliente, sozinho, não descreve a experiência real.

Os limiares devem ser definidos antes da observação dos resultados para evitar aprovar uma migração por impressão subjetiva. Eles podem incluir uma taxa mínima de atendimento a uma rubrica, um máximo de saídas não conformes, uma proporção máxima de operações que exigem intervenção humana e um limite de duração por tipo de tarefa. A avaliação humana continua necessária quando o resultado depende de significado, utilidade ou risco contextual que não pode ser reduzido a uma comparação mecânica.

Depois de superar esses testes, é razoável afirmar que o Nova 2 Lite cumpriu os critérios definidos para os fluxos avaliados, sob uma configuração específica e durante um período observado. Não é razoável extrapolar isso para todos os prompts, todos os documentos, todos os idiomas, todas as regiões ou todos os volumes de tráfego. Tampouco demonstra precisão factual geral, conformidade setorial, confiabilidade de ações automatizadas ou custo real por tarefa em escala.

A operação posterior exige observabilidade e uma rota de reversão. Versionar prompts e esquemas, registrar o modelo e a configuração, medir erros e estabelecer sinais de recuo permite distinguir uma variação pontual de uma regressão sustentada. O objetivo da migração não é demonstrar que um modelo é melhor em abstrato, mas decidir de forma rastreável para quais tarefas, dados e controles seu uso é aceitável.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.