Amazon Nova 2 Lite: qué revisar al migrar desde Nova 1 cuando el contexto llega a un millón de tokens

Nova 2 Lite cambia el contrato de integración, no solo el nombre del modelo

Amazon Nova 2 Lite es un modelo propietario disponible mediante servicios gestionados de AWS. Su identificador base declarado es `amazon.nova-2-lite-v1:0`. La ficha oficial sitúa su lanzamiento el 2 de diciembre de 2025, establece una ventana de contexto de hasta un millón de tokens y fija una salida máxima declarada de 64.000 tokens. También indica que su fin de vida no será anterior al 2 de diciembre de 2026 y contempla un periodo mínimo de legado. Estos datos definen límites publicados del servicio, no un resultado garantizado para una carga de trabajo concreta.

El calificativo «Lite» no permite deducir que la integración sea sencilla, que la latencia sea baja, que el coste por tarea sea menor o que el comportamiento sea equivalente al de Nova 1 Lite, Pro o Premier. Tampoco prueba que un prompt, un esquema de salida o una automatización existente conserve su calidad al cambiar de modelo. Una migración responsable debe tratar el modelo, la API elegida, el perfil de inferencia y la configuración de razonamiento como partes de un contrato que se prueba de nuevo.

El contexto amplio puede modificar el diseño de una aplicación. Puede reducir la necesidad de fragmentar determinados documentos o historiales, pero no elimina la necesidad de seleccionar información relevante, limitar permisos, controlar datos sensibles ni medir resultados. Un contexto de gran tamaño tampoco implica que todo el contenido tenga el mismo peso en la respuesta ni que el modelo produzca respuestas factualmente correctas. Son propiedades distintas: capacidad de admisión, comportamiento de recuperación dentro del contexto, exactitud y utilidad operacional.

La diferencia relevante, por tanto, no es solo cuantitativa. Al adoptar Nova 2 Lite, un equipo debe decidir qué modalidad de invocación empleará, qué entradas permitirá, si habilitará razonamiento ampliado, cómo recibirá y ejecutará solicitudes de herramienta y qué ruta de inferencia es compatible con sus obligaciones de residencia de datos. Cada decisión requiere evidencia obtenida en el entorno propio.

Inventario del contrato: identificador, modalidades y límites que conviene fijar antes de probar

El primer artefacto de migración debería ser un inventario versionado. Debe incluir el identificador del modelo, la región o el perfil de inferencia seleccionado, la API de invocación, los tipos de contenido que admite la aplicación y los límites que el equipo aplicará antes de llamar al servicio. La ficha de Nova 2 Lite declara entrada de texto, imagen y vídeo. El tratamiento de documentos, los tamaños concretos de archivos, las combinaciones de bloques de contenido y la disponibilidad efectiva deben comprobarse contra la documentación vigente de la API y con solicitudes de prueba.

La ventana de un millón de tokens merece una lectura precisa. Es una capacidad máxima de contexto declarada y no una invitación a enviar siempre el máximo. Una aplicación puede encontrar límites prácticos por la composición de la solicitud, la salida solicitada, sus propios límites de memoria, los tiempos de red o sus objetivos de latencia. También debe registrar cuántos tokens entran y salen por operación, porque sin esa telemetría no podrá identificar regresiones al cambiar el tamaño de los documentos o el comportamiento del modelo.

La salida máxima declarada de 64.000 tokens también cambia la superficie de riesgo. Una salida extensa puede exceder límites de gateways, buffers, colas, interfaces de usuario o validadores posteriores. Si el producto necesita JSON u otro formato estructurado, no basta con comprobar que el modelo genera una respuesta larga: hay que verificar que el resultado se puede recibir completo, validar, rechazar de forma segura y reparar o reintentar según una política explícita.

Conviene separar los límites del proveedor de los límites internos. Por ejemplo, una organización puede imponer un máximo de contexto menor para proteger latencia y coste, un máximo de salida para una interfaz concreta y un umbral de tamaño distinto para contenido multimodal. Esas restricciones deben estar en configuración y pruebas, no solo en conocimiento informal del equipo.

Converse e Invoke: la abstracción elegida condiciona la portabilidad

La documentación de Amazon Nova presenta Converse como una interfaz consistente para interactuar con modelos y describe Invoke como una vía con formato nativo que no es portable. La consecuencia práctica es clara: la elección no debe hacerse únicamente por comodidad inicial. Converse puede reducir diferencias de integración cuando una aplicación necesita trabajar con una interfaz común, mientras que Invoke puede requerir que el cliente conozca y mantenga un formato específico del modelo.

Esto no convierte una interfaz en universalmente superior. Un equipo debe comprobar que la API elegida admite las modalidades, configuraciones y campos de respuesta que necesita. Cuando se usa un formato nativo, la prueba debe cubrir la serialización exacta de la petición, el análisis de cada bloque de respuesta, los motivos de parada y los errores. Cuando se usa una interfaz consistente, también se debe verificar que su abstracción no oculte opciones necesarias ni cambie la semántica que espera el producto.

El límite de tiempo merece una revisión de arquitectura. AWS advierte que las solicitudes de inferencia de Nova pueden requerir tiempos de espera de hasta 60 minutos y que el cliente debe ajustarlos. Esto afecta a SDK, balanceadores, proxies, workers, límites de ejecución de funciones y experiencia de usuario. Elevar un timeout sin más puede aumentar recursos retenidos y no resuelve cancelación, reintentos ni deduplicación.

Una operación larga debe tener una política explícita: qué componente puede cancelarla, cómo se propaga la cancelación, qué se registra si el cliente se desconecta, cuándo puede reintentarse y cómo se evita ejecutar dos veces una acción externa. Estas decisiones son especialmente importantes si la conversación puede desencadenar herramientas o si la respuesta posterior alimenta un sistema automatizado.

Razonamiento ampliado: configurar, medir y no confundir con una explicación completa

Nova 2 ofrece razonamiento ampliado mediante `reasoningConfig`. La documentación describe niveles de presupuesto `low`, `medium` y `high`. Activar esta función no equivale a añadir una explicación legible y completa de cómo se obtuvo una respuesta. La respuesta puede incluir bloques `reasoningContent`, pero AWS indica que el contenido de razonamiento se devuelve redactado. Por ello, esos bloques no deben considerarse un registro exhaustivo de decisiones ni una evidencia suficiente para auditoría de negocio.

El razonamiento ampliado debe evaluarse como una variante de configuración independiente. Un conjunto de pruebas adecuado compara, para cada tarea, el modo sin razonamiento y cada presupuesto que el producto considere admisible. Debe recoger tasa de éxito según una rúbrica definida, validez de la salida estructurada, duración total, uso de tokens disponible en la telemetría, frecuencia de reintentos y resultados de seguridad. La elección de presupuesto debe responder a un objetivo medido, no a la suposición de que un nivel mayor mejora todos los casos.

También hay una cuestión de trazabilidad. Registrar la configuración solicitada, el identificador del modelo, la API y el perfil de inferencia permite reproducir una clase de incidencia. Sin embargo, esos registros no sustituyen a la observación de entradas, salidas, decisiones de la aplicación y resultados de herramientas autorizadas. Cuando los datos contengan información personal o confidencial, el registro debe aplicar las mismas políticas de minimización, acceso y retención que el resto del sistema.

No hay base en la documentación aportada para afirmar que el razonamiento ampliado garantice respuestas más correctas, más seguras o más rápidas. La decisión razonable es acotar su uso a tareas donde la evaluación propia muestre una mejora suficiente frente a sus efectos en duración y operación.

Function calling: el modelo propone; la aplicación autoriza y ejecuta

La documentación de Nova 2 describe function calling como un flujo en el que el cliente define herramientas mediante JSON Schema. Cuando el modelo solicita una herramienta, la respuesta incluye un bloque `toolUse` y un motivo de parada `tool_use`. La responsabilidad de ejecutar la herramienta recae explícitamente en el cliente, que debe devolver el resultado al modelo si quiere continuar la interacción. Este reparto es esencial: una solicitud generada por el modelo no es una autorización para realizar una acción externa.

La capa de aplicación debe validar el nombre de la herramienta y sus argumentos frente a un contrato estricto, comprobar identidad y permisos del usuario, aplicar límites de frecuencia y alcance, ejecutar con credenciales de mínimo privilegio y convertir errores a un resultado controlado. También debe decidir qué hacer con argumentos ambiguos, recursos inexistentes, respuestas con datos sensibles, errores transitorios y operaciones que no sean idempotentes. Un JSON Schema mejora la definición de la interfaz, pero no sustituye a controles de autorización ni a validación semántica.

La propuesta de migración menciona herramientas integradas, como grounding web o intérprete de código. Las fuentes verificadas aportadas para esta pieza documentan el flujo de function calling, pero no permiten establecer aquí qué herramientas integradas están disponibles para Nova 2 Lite, bajo qué condiciones, en qué rutas de invocación o regiones, ni cómo tratan datos y permisos. Es una incertidumbre que debe resolverse con documentación específica vigente antes de diseñar un flujo que dependa de ellas.

La prueba de herramientas debe incluir éxito y fallo. Es insuficiente demostrar que el modelo selecciona una función con una consulta simple. Hay que probar argumentos válidos e inválidos, permisos denegados, tiempos de espera, caída del servicio externo, resultados parciales, repetición de llamadas y rechazo de una acción potencialmente dañina. La aplicación debe conservar control sobre el efecto externo incluso si el modelo insiste en una llamada.

Migrar desde Nova 1: sustituir un ID no demuestra equivalencia

No hay en las fuentes aportadas una matriz oficial que permita afirmar una equivalencia funcional directa entre Nova 2 Lite y Nova 1 Lite, Pro o Premier. En consecuencia, no es riguroso prometer que el reemplazo del identificador conservará calidad, formatos, selección de herramientas, latencia o comportamiento multimodal. La migración debe definirse como una sustitución sometida a evaluación, no como una actualización transparente.

El punto de partida es congelar una línea base del sistema actual. Para cada flujo, el equipo debería conservar entradas representativas permitidas, configuración de generación, prompts de sistema y usuario, herramientas disponibles, respuestas esperadas o rúbricas de revisión, duración y tasa de fallos. Después puede ejecutar el mismo conjunto sobre Nova 2 Lite, distinguiendo el resultado por API, presupuesto de razonamiento y perfil de inferencia. Sin esta separación, una regresión puede atribuirse erróneamente al modelo cuando procede de la ruta de invocación o de una modificación de prompt.

Los casos largos son obligatorios si el motivo del cambio es el contexto amplio. Deben incluir información relevante distribuida, contenido irrelevante, contradicciones deliberadas y límites internos de la aplicación. Los casos multimodales deben evaluar cada modalidad utilizada por el producto y comprobar que los mecanismos de carga, conversión y observabilidad funcionan. Las salidas estructuradas necesitan validación automática y revisión de los casos que fallen; la apariencia de un JSON correcto no demuestra que sus valores sean adecuados.

La decisión de despliegue puede ser gradual. Un equipo puede mantener el modelo anterior para flujos que no hayan alcanzado los umbrales, limitar Nova 2 Lite a tareas observables y reversibles, o desactivar razonamiento y herramientas hasta completar pruebas. Esta prudencia no es una valoración negativa del modelo; es una forma de no confundir capacidades declaradas con resultados demostrados en un sistema concreto.

Regiones, perfiles de inferencia y residencia: convertir una política en evidencia

La disponibilidad regional y la residencia de datos no se deben deducir del nombre de la región desde la que se envía una solicitud. Amazon Bedrock distingue inferencia en región, inferencia entre regiones mediante perfiles geográficos e inferencia entre regiones mediante perfiles globales. La documentación de AWS señala que un perfil geográfico procesa solicitudes dentro de la geografía definida, mientras que un perfil global puede procesarlas en cualquier región comercial admitida.

Esto obliga a tratar el perfil de inferencia como un parámetro de cumplimiento, no como un detalle de rendimiento. Antes de habilitar Nova 2 Lite, la organización debe consultar la matriz vigente de disponibilidad por modelo y región, identificar qué ruta selecciona su configuración y contrastarla con su política contractual, regulatoria y de clasificación de datos. La disponibilidad cambia con el tiempo; una conclusión tomada durante una prueba no debe sustituir a un control de cambios.

AWS documenta que CloudTrail registra `additionalEventData.inferenceRegion`. Este campo puede aportar evidencia operativa del lugar de procesamiento usado por una solicitud. No obstante, el equipo de cumplimiento debe determinar qué periodo de retención, qué cobertura de registros y qué controles adicionales necesita. Un registro útil para diagnóstico no certifica por sí solo que toda la arquitectura cumple una obligación sectorial.

La prueba debe hacerse con la identidad, cuenta, región y perfil de inferencia que se usarán en producción. Debe comprobar que los eventos esperados se generan, que el campo se conserva y que un cambio no autorizado de perfil resulta detectable. Si la política prohíbe una ruta global, esa prohibición debe materializarse en controles de configuración y permisos, no depender de una convención de nombres.

Criterios de aceptación y límites de lo que puede concluirse

Una batería mínima de aceptación debería cubrir contexto corto y largo, entradas multimodales que el producto realmente use, respuestas estructuradas válidas e inválidas, solicitudes de herramienta correctas y malformadas, denegaciones de permisos, fallos de herramientas, cancelación, reintentos y repetición de una misma petición. Debe medir percentiles de latencia en la cadena completa, incluidos los componentes intermedios, porque el timeout del cliente no describe por sí solo la experiencia real.

Los umbrales deben definirse antes de observar los resultados para evitar aprobar una migración por impresión subjetiva. Pueden incluir una tasa mínima de cumplimiento de una rúbrica, un máximo de salidas no conformes, una proporción máxima de operaciones que necesiten intervención humana y un límite de duración por tipo de tarea. La evaluación humana sigue siendo necesaria cuando el resultado depende de significado, utilidad o riesgo contextual que no puede reducirse a una comparación mecánica.

Tras superar estas pruebas, es razonable afirmar que Nova 2 Lite ha cumplido los criterios definidos para los flujos evaluados, bajo una configuración concreta y durante un periodo observado. No es razonable extrapolarlo a todos los prompts, todos los documentos, todos los idiomas, todas las regiones ni todos los volúmenes de tráfico. Tampoco demuestra exactitud factual general, cumplimiento sectorial, fiabilidad de acciones automatizadas o coste real por tarea a escala.

La operación posterior necesita observabilidad y una ruta de reversión. Versionar prompts y esquemas, registrar el modelo y la configuración, medir errores y establecer señales de retroceso permite distinguir una variación puntual de una regresión sostenida. El propósito de la migración no es demostrar que un modelo es mejor en abstracto, sino decidir de manera trazable para qué tareas, datos y controles su uso es aceptable.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.