Amazon Nova 2 Lite: cosa verificare nella migrazione da Nova 1 quando il contesto arriva a un milione di token

Nova 2 Lite cambia il contratto di integrazione, non solo il nome del modello

Amazon Nova 2 Lite è un modello proprietario disponibile tramite servizi AWS gestiti. Il suo identificatore base dichiarato è `amazon.nova-2-lite-v1:0`. La scheda ufficiale colloca il lancio al 2 dicembre 2025, indica una finestra di contesto fino a un milione di token e stabilisce un output massimo dichiarato di 64.000 token. Indica inoltre che la fine del ciclo di vita non sarà precedente al 2 dicembre 2026 e prevede un periodo minimo di legacy. Questi dati definiscono limiti pubblicati del servizio, non un risultato garantito per uno specifico carico di lavoro.

La qualifica «Lite» non consente di dedurre che l'integrazione sia semplice, che la latenza sia bassa, che il costo per attività sia inferiore o che il comportamento sia equivalente a Nova 1 Lite, Pro o Premier. Non dimostra neppure che un prompt, uno schema di output o un'automazione esistente mantengano la loro qualità cambiando modello. Una migrazione responsabile deve trattare il modello, l'API scelta, il profilo di inferenza e la configurazione del ragionamento come parti di un contratto da testare nuovamente.

Il contesto esteso può modificare la progettazione di un'applicazione. Può ridurre la necessità di frammentare determinati documenti o cronologie, ma non elimina il bisogno di selezionare informazioni pertinenti, limitare i permessi, controllare i dati sensibili o misurare i risultati. Un contesto molto ampio non implica neppure che tutto il contenuto abbia lo stesso peso nella risposta o che il modello produca risposte fattualmente corrette. Sono proprietà distinte: capacità di ammissione, comportamento di recupero all'interno del contesto, accuratezza e utilità operativa.

La differenza rilevante, quindi, non è solo quantitativa. Adottando Nova 2 Lite, un team deve decidere quale modalità di invocazione usare, quali input consentire, se abilitare il ragionamento esteso, come ricevere ed eseguire le richieste di strumenti e quale percorso di inferenza sia compatibile con i propri obblighi di residenza dei dati. Ogni decisione richiede evidenze raccolte nel proprio ambiente.

Inventario del contratto: identificatore, modalità e limiti da fissare prima dei test

Il primo artefatto della migrazione dovrebbe essere un inventario versionato. Deve includere l'identificatore del modello, la regione o il profilo di inferenza selezionato, l'API di invocazione, i tipi di contenuto ammessi dall'applicazione e i limiti che il team applicherà prima di chiamare il servizio. La scheda di Nova 2 Lite dichiara input di testo, immagini e video. Il trattamento dei documenti, le dimensioni specifiche dei file, le combinazioni di blocchi di contenuto e la disponibilità effettiva devono essere verificati rispetto alla documentazione aggiornata dell'API e con richieste di prova.

La finestra di un milione di token richiede una lettura precisa. È una capacità massima di contesto dichiarata, non un invito a inviare sempre il massimo. Un'applicazione può incontrare limiti pratici dovuti alla composizione della richiesta, all'output richiesto, ai propri limiti di memoria, ai tempi di rete o agli obiettivi di latenza. Deve inoltre registrare quanti token entrano ed escono per operazione, perché senza questa telemetria non potrà identificare regressioni quando cambiano la dimensione dei documenti o il comportamento del modello.

Anche l'output massimo dichiarato di 64.000 token modifica la superficie di rischio. Un output esteso può superare i limiti di gateway, buffer, code, interfacce utente o validatori successivi. Se il prodotto richiede JSON o un altro formato strutturato, non basta controllare che il modello generi una risposta lunga: occorre verificare che il risultato possa essere ricevuto integralmente, convalidato, rifiutato in modo sicuro e corretto o ritentato secondo una politica esplicita.

È opportuno separare i limiti del fornitore dai limiti interni. Per esempio, un'organizzazione può imporre un massimo di contesto più basso per proteggere latenza e costo, un massimo di output per una determinata interfaccia e una soglia dimensionale distinta per i contenuti multimodali. Questi vincoli devono essere presenti nella configurazione e nei test, non soltanto nella conoscenza informale del team.

Converse e Invoke: l'astrazione scelta condiziona la portabilità

La documentazione di Amazon Nova presenta Converse come interfaccia coerente per interagire con i modelli e descrive Invoke come un percorso con formato nativo non portabile. La conseguenza pratica è chiara: la scelta non deve dipendere soltanto dalla comodità iniziale. Converse può ridurre le differenze di integrazione quando un'applicazione deve operare con un'interfaccia comune, mentre Invoke può richiedere che il client conosca e mantenga un formato specifico del modello.

Questo non rende un'interfaccia universalmente superiore all'altra. Un team deve verificare che l'API scelta supporti le modalità, le configurazioni e i campi di risposta necessari. Quando si usa un formato nativo, il test deve coprire la serializzazione esatta della richiesta, l'analisi di ogni blocco di risposta, i motivi di arresto e gli errori. Quando si usa un'interfaccia coerente, occorre anche verificare che la sua astrazione non nasconda opzioni necessarie né modifichi la semantica attesa dal prodotto.

Il timeout richiede una revisione architetturale. AWS avverte che le richieste di inferenza Nova possono richiedere timeout fino a 60 minuti e che il client deve adeguarli. Questo influenza SDK, bilanciatori di carico, proxy, worker, limiti di esecuzione delle funzioni ed esperienza utente. Aumentare semplicemente un timeout può incrementare le risorse trattenute e non risolve annullamento, ritentativi o deduplicazione.

Un'operazione lunga deve avere una politica esplicita: quale componente può annullarla, come l'annullamento viene propagato, cosa viene registrato se il client si disconnette, quando può essere ritentata e come si evita di eseguire due volte un'azione esterna. Queste decisioni sono particolarmente importanti se la conversazione può attivare strumenti o se la risposta successiva alimenta un sistema automatizzato.

Ragionamento esteso: configurare, misurare e non confondere con una spiegazione completa

Nova 2 offre ragionamento esteso tramite `reasoningConfig`. La documentazione descrive livelli di budget `low`, `medium` e `high`. L'attivazione di questa funzione non equivale all'aggiunta di una spiegazione leggibile e completa di come sia stata ottenuta una risposta. La risposta può includere blocchi `reasoningContent`, ma AWS indica che il contenuto del ragionamento viene restituito in forma redatta. Per questo, tali blocchi non devono essere considerati un registro esaustivo delle decisioni né un'evidenza sufficiente per un audit di business.

Il ragionamento esteso deve essere valutato come una variante di configurazione indipendente. Un set di test adeguato confronta, per ciascuna attività, la modalità senza ragionamento e ogni budget che il prodotto ritiene ammissibile. Deve raccogliere il tasso di successo secondo una rubrica definita, la validità dell'output strutturato, la durata complessiva, l'uso dei token disponibile nella telemetria, la frequenza dei ritentativi e gli esiti di sicurezza. La scelta del budget deve rispondere a un obiettivo misurato, non all'ipotesi che un livello più alto migliori tutti i casi.

Vi è anche una questione di tracciabilità. Registrare la configurazione richiesta, l'identificatore del modello, l'API e il profilo di inferenza permette di riprodurre una categoria di incidente. Tuttavia, questi registri non sostituiscono l'osservazione di input, output, decisioni dell'applicazione e risultati degli strumenti autorizzati. Quando i dati contengono informazioni personali o riservate, la registrazione deve applicare le stesse politiche di minimizzazione, accesso e conservazione del resto del sistema.

Non vi sono basi nella documentazione fornita per affermare che il ragionamento esteso garantisca risposte più corrette, più sicure o più rapide. La decisione ragionevole è limitarne l'uso alle attività per cui la valutazione interna mostri un miglioramento sufficiente rispetto ai suoi effetti sulla durata e sull'operatività.

Function calling: il modello propone; l'applicazione autorizza ed esegue

La documentazione di Nova 2 descrive il function calling come un flusso in cui il client definisce strumenti mediante JSON Schema. Quando il modello richiede uno strumento, la risposta include un blocco `toolUse` e un motivo di arresto `tool_use`. La responsabilità dell'esecuzione dello strumento ricade esplicitamente sul client, che deve restituire il risultato al modello se vuole proseguire l'interazione. Questa ripartizione è essenziale: una richiesta generata dal modello non è un'autorizzazione a compiere un'azione esterna.

Il livello applicativo deve convalidare nome e argomenti dello strumento rispetto a un contratto rigoroso, verificare identità e permessi dell'utente, applicare limiti di frequenza e di ambito, eseguire con credenziali a privilegio minimo e trasformare gli errori in un risultato controllato. Deve inoltre decidere come trattare argomenti ambigui, risorse inesistenti, risposte contenenti dati sensibili, errori transitori e operazioni non idempotenti. Un JSON Schema migliora la definizione dell'interfaccia, ma non sostituisce i controlli di autorizzazione né la convalida semantica.

La proposta di migrazione menziona strumenti integrati, quali grounding web o interprete di codice. Le fonti verificate fornite per questo articolo documentano il flusso di function calling, ma non consentono di stabilire qui quali strumenti integrati siano disponibili per Nova 2 Lite, a quali condizioni, in quali percorsi di invocazione o regioni, né come trattino dati e permessi. È un'incertezza da risolvere mediante documentazione specifica aggiornata prima di progettare un flusso che dipenda da tali strumenti.

Il test degli strumenti deve includere successo e fallimento. Non è sufficiente dimostrare che il modello seleziona una funzione con una semplice query. Bisogna testare argomenti validi e non validi, permessi negati, timeout, indisponibilità del servizio esterno, risultati parziali, ripetizione delle chiamate e rifiuto di un'azione potenzialmente dannosa. L'applicazione deve mantenere il controllo sull'effetto esterno anche se il modello insiste su una chiamata.

Migrare da Nova 1: sostituire un ID non dimostra equivalenza

Nelle fonti fornite non esiste una matrice ufficiale che consenta di affermare un'equivalenza funzionale diretta tra Nova 2 Lite e Nova 1 Lite, Pro o Premier. Di conseguenza, non è rigoroso promettere che la sostituzione dell'identificatore conserverà qualità, formati, selezione degli strumenti, latenza o comportamento multimodale. La migrazione deve essere definita come una sostituzione sottoposta a valutazione, non come un aggiornamento trasparente.

Il punto di partenza è congelare una baseline del sistema attuale. Per ogni flusso, il team dovrebbe conservare input rappresentativi consentiti, configurazione di generazione, prompt di sistema e utente, strumenti disponibili, risposte attese o rubriche di revisione, durata e tasso di errore. Può poi eseguire lo stesso set su Nova 2 Lite, distinguendo il risultato per API, budget di ragionamento e profilo di inferenza. Senza questa separazione, una regressione può essere attribuita erroneamente al modello quando dipende dal percorso di invocazione o da una modifica del prompt.

I casi lunghi sono obbligatori se il motivo del cambiamento è il contesto esteso. Devono includere informazioni rilevanti distribuite, contenuti irrilevanti, contraddizioni intenzionali e limiti interni dell'applicazione. I casi multimodali devono valutare ogni modalità usata dal prodotto e verificare che i meccanismi di caricamento, conversione e osservabilità funzionino. Gli output strutturati richiedono convalida automatica e revisione dei casi che falliscono; l'apparenza di un JSON corretto non dimostra che i suoi valori siano adeguati.

La decisione di rilascio può essere graduale. Un team può mantenere il modello precedente per i flussi che non hanno raggiunto le soglie, limitare Nova 2 Lite ad attività osservabili e reversibili o disabilitare ragionamento e strumenti fino al completamento dei test. Questa prudenza non è una valutazione negativa del modello; è un modo per non confondere capacità dichiarate con risultati dimostrati in un sistema concreto.

Regioni, profili di inferenza e residenza: trasformare una politica in evidenza

La disponibilità regionale e la residenza dei dati non devono essere dedotte dal nome della regione da cui viene inviata una richiesta. Amazon Bedrock distingue l'inferenza nella regione, l'inferenza tra regioni tramite profili geografici e l'inferenza tra regioni tramite profili globali. La documentazione AWS segnala che un profilo geografico elabora le richieste all'interno della geografia definita, mentre un profilo globale può elaborarle in qualunque regione commerciale supportata.

Questo impone di trattare il profilo di inferenza come un parametro di conformità, non come un dettaglio prestazionale. Prima di abilitare Nova 2 Lite, l'organizzazione deve consultare la matrice aggiornata di disponibilità per modello e regione, identificare quale percorso selezioni la propria configurazione e confrontarlo con la politica contrattuale, normativa e di classificazione dei dati. La disponibilità cambia nel tempo; una conclusione raggiunta durante un test non deve sostituire un controllo delle modifiche.

AWS documenta che CloudTrail registra `additionalEventData.inferenceRegion`. Questo campo può fornire evidenza operativa del luogo di elaborazione utilizzato da una richiesta. Tuttavia, il team di compliance deve stabilire quali periodo di conservazione, copertura dei registri e controlli aggiuntivi siano necessari. Un registro utile alla diagnostica non certifica da solo che l'intera architettura rispetti un obbligo settoriale.

Il test deve essere effettuato con l'identità, l'account, la regione e il profilo di inferenza che verranno usati in produzione. Deve verificare che gli eventi previsti vengano generati, che il campo sia conservato e che una modifica non autorizzata del profilo sia rilevabile. Se la politica vieta un percorso globale, il divieto deve concretizzarsi in controlli di configurazione e permessi, non dipendere da una convenzione di denominazione.

Criteri di accettazione e limiti di ciò che si può concludere

Una batteria minima di accettazione dovrebbe coprire contesto breve e lungo, input multimodali effettivamente usati dal prodotto, output strutturati validi e non validi, richieste di strumenti corrette e malformate, dinieghi di permesso, errori degli strumenti, annullamento, ritentativi e ripetizione della stessa richiesta. Deve misurare i percentili di latenza lungo l'intera catena, inclusi i componenti intermedi, perché il timeout del client non descrive da solo l'esperienza reale.

Le soglie devono essere definite prima di osservare i risultati per evitare di approvare una migrazione sulla base di un'impressione soggettiva. Possono includere un tasso minimo di rispetto di una rubrica, un massimo di output non conformi, una proporzione massima di operazioni che richiedono intervento umano e un limite di durata per tipo di attività. La valutazione umana resta necessaria quando il risultato dipende da significato, utilità o rischio contestuale che non può essere ridotto a un confronto meccanico.

Dopo il superamento di questi test, è ragionevole affermare che Nova 2 Lite ha soddisfatto i criteri definiti per i flussi valutati, con una configurazione specifica e durante un periodo osservato. Non è ragionevole estrapolare questo risultato a tutti i prompt, tutti i documenti, tutte le lingue, tutte le regioni o tutti i volumi di traffico. Non dimostra neppure accuratezza fattuale generale, conformità settoriale, affidabilità di azioni automatizzate o costo reale per attività su scala.

L'operatività successiva richiede osservabilità e un percorso di rollback. Versionare prompt e schemi, registrare modello e configurazione, misurare gli errori e stabilire segnali di arretramento consente di distinguere una variazione episodica da una regressione persistente. Lo scopo della migrazione non è dimostrare che un modello sia migliore in astratto, ma decidere in modo tracciabile per quali attività, dati e controlli il suo uso sia accettabile.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.