Amazon Nova 2 Lite vs Claude Fable 5.1 per estrarre dati dai documenti: come impostare un confronto riproducibile

Quale decisione risolve questo confronto e cosa non consente di concludere

La decisione rilevante non riguarda quale modello sia «migliore» in astratto, ma quale si adatti a uno specifico flusso di estrazione documentale. Il caso d'uso considerato consiste nel trasformare fatture, contratti brevi, moduli e documenti PDF con tabelle in dati conformi a uno schema definito. In questi flussi, una risposta apparentemente corretta non è sufficiente: deve preservare i valori rilevanti, rispettare i tipi richiesti, distinguere un'assenza da un valore reale e lasciare una tracciabilità sufficiente per correggere gli errori.

Le informazioni fornite descrivono Amazon Nova 2 Lite e Claude Fable 5.1 attraverso i rispettivi fornitori, ma non includono risultati di una valutazione comune eseguita su entrambi. Non è quindi possibile affermare, sulla base di queste fonti, che uno raggiunga maggiore accuratezza, minore latenza o minore costo effettivo rispetto all'altro in un determinato portafoglio documentale. Non sarebbe nemmeno rigoroso estrapolare confronti pubblicati da Amazon con altri modelli allo scontro qui considerato.

La conclusione operativa, prima di eseguire un test, è condizionale. Nova 2 Lite può essere valutato come modello multimodale della famiglia Nova 2 tramite Amazon Bedrock. Claude Fable 5.1 può essere valutato nel percorso e alle condizioni di disponibilità documentati da Anthropic. La scelta sarà difendibile soltanto dopo aver fissato un percorso di accesso, un corpus congelato, una definizione di correttezza, una politica di ritentativi e una modalità uniforme di imputazione dei costi ausiliari.

Un confronto utile deve separare tre livelli. Il primo è la capacità dichiarata da ciascun fornitore: modalità supportate, API, gestione dei documenti e controlli disponibili. Il secondo è il risultato misurato su uno specifico insieme documentale. Il terzo è il rischio operativo: dati incompleti, OCR difettoso, documenti non equivalenti, cambiamenti di versione, quote, politiche di conservazione e revisione umana. Confondere questi livelli produce spesso una decisione apparentemente quantitativa ma difficile da sottoporre ad audit.

Modelli, percorsi di accesso e asimmetrie da fissare

Amazon documenta Nova 2 Lite in Amazon Bedrock, inclusi identificativi del modello, opzioni di inferenza e possibilità di utilizzo regionale o globale. La documentazione di Nova descrive inoltre capacità legate alla comprensione di documenti, PDF, tabelle e layout. Queste capacità devono essere verificate nella modalità esatta acquistata, perché una prova testuale non equivale a una prova che fornisca immagini o documenti al modello.

Anthropic identifica Claude Fable 5.1 nella propria documentazione e nella pagina di prodotto, dove comunica anche disponibilità, prezzi e capacità relative a PDF e tabelle. Prima del confronto, il team deve registrare l'identificativo esatto utilizzato, la data, la regione o il luogo di elaborazione quando applicabile, la versione dell'API, i limiti configurati, il budget di output e qualsiasi configurazione di ragionamento o cache. Senza questa registrazione, un risultato successivo potrebbe non essere ripetibile.

Esiste una potenziale asimmetria metodologica nell'output strutturato. La documentazione di Anthropic sugli structured outputs descrive un meccanismo basato su JSON Schema e avverte che la compatibilità dipende dalla piattaforma e dal modello. Secondo le informazioni fornite, Fable 5.1 non figura tra i modelli di Bedrock compatibili con gli structured outputs. Questo non dimostra che Fable 5.1 non possa produrre JSON valido su altri percorsi; impone però di documentare quale meccanismo sia stato usato per ciascun lato e di non presentare due integrazioni diverse come se fossero identiche.

Esistono due opzioni accettabili, con implicazioni differenti. La prima consiste nell'usare l'interfaccia nativa di ciascun fornitore e misurare il sistema effettivamente distribuibile, dichiarando le differenze di piattaforma. La seconda consiste nell'imporre un denominatore comune: un prompt che richieda JSON, una validazione esterna rispetto allo stesso schema e un numero identico di ritentativi. La seconda riduce i vantaggi delle integrazioni specifiche; la prima riflette meglio l'esperienza operativa. Non devono essere mescolate senza etichettarle come esperimenti separati.

Progettazione riproducibile per l'estrazione strutturata

Il corpus deve essere congelato prima di osservare i risultati e deve rappresentare il lavoro che si intende automatizzare. Una suddivisione pratica comprende testo digitale pulito, tabelle semplici, tabelle su più pagine, scansioni, moduli, documenti con campi ambigui e documenti incompleti. Occorre conservare il file originale, un identificativo non sensibile, il tipo documentale, la lingua, il canale di input e le anomalie note. Se si usano dati reali, l'insieme di valutazione deve rispettare le politiche interne e contrattuali applicabili.

Ogni documento necessita di una verità di riferimento indipendente dal modello. Per i campi critici, due revisori dovrebbero annotare il valore atteso, l'assenza legittima, l'ambiguità e l'evidenza visiva o testuale che lo supporta. In caso di disaccordo, una terza revisione o una regola di aggiudicazione deve risolvere il caso. La percentuale di documenti sottoposti a doppia revisione e i disaccordi irrisolti devono essere pubblicati come parte dell'incertezza, non nascosti all'interno di un'unica misura di accuratezza.

Lo schema deve rappresentare sia il dato sia il suo stato. Per esempio, una data può essere valida, assente, illeggibile, ambigua o fuori ambito. Forzare sempre una stringa può trasformare un'omissione in un'invenzione. È opportuno richiedere campi di evidenza, un livello di confidenza espresso secondo regole proprie e un elenco di anomalie; tuttavia, una confidenza dichiarata dal modello non dimostra che sia ben calibrata. La si misura confrontando quel segnale con gli errori osservati.

Il prompt deve essere identico nell'obiettivo semantico: estrarre soltanto ciò che è visibile o esplicitamente inferibile secondo una regola documentata, restituire l'assenza quando manca evidenza e non completare valori plausibili. Se l'interfaccia di un fornitore aggiunge istruzioni di sistema o elementi di formattazione obbligatori, questi devono essere mantenuti, archiviati e conteggiati come parte della configurazione. Va inoltre registrato se si è effettuata una conversione preventiva del PDF, OCR, riduzione delle immagini o suddivisione delle pagine.

Le esecuzioni ripetute sono necessarie anche quando la configurazione sembra deterministica. Come minimo, ogni combinazione di modello, tipo di documento e configurazione deve essere eseguita tre volte. I risultati devono riportare la dispersione e, quando la dimensione campionaria lo consente, intervalli di incertezza. Una differenza isolata di pochi campi non dovrebbe trasformarsi in una raccomandazione di acquisto se rientra nella variazione osservata o deriva da un numero ridotto di documenti.

Metriche importanti: formato, significato, tempo e costo

Il tasso di JSON valido misura quante risposte possano essere analizzate senza una riparazione che ne alteri il contenuto. È necessario, ma non sufficiente. Un JSON perfettamente valido può contenere un fornitore errato, un importo inventato o una data spostata. Per questo deve essere combinato con accuratezza per campo e accuratezza per documento. Quest'ultima può essere definita in modo rigoroso: un documento è considerato corretto soltanto se tutti i campi critici coincidono con il riferimento e non compaiono valori non supportati.

Omissioni e allucinazioni devono essere conteggiate separatamente. Un'omissione è un campo che doveva essere estratto e manca oppure è erroneamente segnato come assente. Un'allucinazione è un valore presentato come estratto senza supporto nel documento o in contrasto con il riferimento. Nella contrattualistica, fatturazione o conformità, le allucinazioni possono avere un costo operativo superiore a quello di un'omissione, perché una revisione può individuare un vuoto più facilmente di un dato plausibile ma errato. La ponderazione deve riflettere il rischio del processo, non una preferenza generica.

La segnalazione dell'incertezza deve essere valutata come classificazione. Se il modello segnala dubbio in casi realmente ambigui o illeggibili, offre valore per l'instradamento alla revisione umana. Se dichiara alta sicurezza in errori gravi, quel segnale non consente di automatizzare decisioni. Il rapporto deve includere la copertura: quale frazione del corpus può passare senza revisione sotto una soglia di rischio; e la precisione condizionata: quanti di quei documenti accettati sono effettivamente corretti.

La latenza deve essere misurata end-to-end, dal momento in cui il sistema avvia la richiesta fino all'ottenimento di un output validato o all'esaurimento dei ritentativi. Occorre separare i percentili, non solo le medie, e misurare per dimensione e complessità del documento. Devono inoltre essere separati i tempi di caricamento, conversione dei file, OCR se presente, inferenza, validazione e ritentativo. Altrimenti, un collo di bottiglia esterno può essere erroneamente attribuito al modello.

Il costo utile non è il prezzo annunciato per token. Per ogni documento si sommano input, output, letture o scritture della cache applicabili, elaborazione dei file, ritentativi e servizi ausiliari. Il costo totale viene poi diviso per il numero di documenti che superano la definizione di correttezza. Se è richiesta una revisione umana, esistono due misure distinte: costo per risultato automatico corretto e costo per risultato finale accettato, incluso il lavoro di revisione. Entrambe sono valide, ma rispondono a decisioni diverse.

Risultati: cosa si può affermare oggi e come interpretare una futura prova

Non sono state fornite misurazioni del corpus proposto né per Amazon Nova 2 Lite né per Claude Fable 5.1. Di conseguenza, le sezioni dei risultati devono restare prive di un verdetto sulle prestazioni fino all'esecuzione e alla pubblicazione del protocollo. La documentazione AWS può giustificare l'inclusione di Nova 2 Lite nella valutazione per le sue capacità dichiarate di comprensione documentale e per le modalità correlate. La documentazione Anthropic può giustificare l'inclusione di Fable 5.1 per le capacità e le condizioni comunicate per PDF e tabelle. Nessuna di queste descrizioni sostituisce un tasso osservato di campi corretti.

Un risultato favorevole a Nova 2 Lite su documenti di testo pulito non dimostrerebbe superiorità su scansioni, tabelle complesse o contratti ambigui. Allo stesso modo, un risultato favorevole a Claude Fable 5.1 in una configurazione con una funzione di output strutturato non dimostrerebbe che il vantaggio provenga dal modello anziché dall'integrazione. La ripartizione per categoria documentale non è un dettaglio editoriale: è la base affinché un team possa applicare la conclusione al proprio portafoglio.

AWS pubblica un esempio di architettura che combina Nova 2 Lite con un altro modello Claude per la digitalizzazione di documenti scansionati. Tale materiale è utile come illustrazione di un'architettura in più fasi e della necessità di distribuire costi e compiti. Non deve essere usato come evidenza comparativa tra Nova 2 Lite e Claude Fable 5.1: l'esempio citato utilizza un altro modello Claude e un caso documentale differente.

Una prova futura dovrebbe riportare anche gli errori ricorrenti, non soltanto gli aggregati. Tra le categorie utili rientrano: cella di tabella assegnata alla colonna errata, confusione tra subtotale e importo totale, data normalizzata in modo errato, parte contrattuale sbagliata, errore dovuto a rotazione o bassa risoluzione, perdita di una pagina, valore non visibile e mancato rispetto dello schema. Un insieme di esempi anonimizzati e verificabili aiuta a rilevare se una media elevata nasconde una tipologia di errore inaccettabile.

Privacy, conservazione e condizioni che possono invalidare una decisione basata soltanto sulle metriche

La scelta del percorso di accesso incide sia sulla valutazione sia sulla distribuzione. Amazon Bedrock documenta politiche di conservazione dei dati e controlli di sicurezza e privacy. Anthropic documenta separatamente le condizioni di conservazione della propria API, incluse opzioni come la conservazione zero quando disponibili alle condizioni applicabili. Queste politiche devono essere verificate per lo specifico account, prodotto, regione e accordo contrattuale; un'affermazione generale su un fornitore non sostituisce questa verifica.

Prima di caricare documenti reali, il team deve classificare i dati, stabilire se contengono informazioni personali, finanziarie, contrattuali o regolamentate e confermare chi possa accedere a prompt, risposte, file e registri. Deve inoltre verificare se lo schema JSON, i metadati di tracciabilità e gli esempi di errore contengano informazioni sensibili. La minimizzazione dei dati può essere più importante di una piccola differenza di latenza o prezzo.

La residenza dei dati, la crittografia, la gestione delle identità, le chiavi gestite dal cliente e i controlli di rete possono condizionare quale servizio sia ammissibile. AWS descrive controlli aziendali per Bedrock, inclusi meccanismi di sicurezza e isolamento. La valutazione deve registrare quali controlli siano stati attivati, perché una configurazione di laboratorio con autorizzazioni ampie può non rappresentare un'architettura approvabile in produzione.

Non si deve presumere che i dati non siano usati per l'addestramento, che vengano eliminati immediatamente o che siano elaborati in una determinata ubicazione senza verificarlo rispetto alla documentazione e al contratto vigenti. Le politiche cambiano e possono dipendere dalla modalità di accesso. Se un requisito di conformità non è confermato, la decisione deve essere «in attesa di validazione», non una raccomandazione tecnica provvisoria presentata come sufficiente.

Decisione per scenario e limiti di questo confronto

Per uno scenario con il minor costo accettabile, la decisione deve basarsi sul costo per documento corretto entro una soglia minima di accuratezza, non sul prezzo unitario annunciato. Per la massima accuratezza, devono prevalere l'accuratezza per documento critico, il tasso di allucinazioni e la calibrazione dell'incertezza. Per la minore latenza, occorre guardare ai percentili end-to-end sotto il carico previsto. Per alta criticità, l'opzione adeguata può essere una combinazione di estrazione, validazione deterministica e revisione umana, anche se un modello ottiene una buona media aggregata.

Quando entrambi i modelli non soddisfano una soglia definita per i campi critici, la conclusione corretta è che nessuno dei due debba approvare automaticamente quei documenti in quella configurazione. Le alternative consistono nel migliorare la qualità dell'input, separare OCR ed estrazione, dividere i documenti per pagine o sezioni, restringere lo schema, aggiungere regole di validazione, usare un instradamento basato sul rischio o mantenere la revisione umana. Cambiare modello senza diagnosticare la causa può spostare l'errore senza risolverlo.

Il calendario di aggiornamento deve dipendere da cambiamenti rilevanti: nuovo identificativo del modello, variazione dei prezzi, modifica dei limiti o delle modalità, aggiornamento delle politiche sui dati, cambio di regione, alterazione del corpus di produzione o comparsa di un nuovo tipo documentale. Ogni nuova misurazione deve conservare la versione precedente per evitare confronti tra risultati incompatibili. La raccomandazione deve scadere esplicitamente se cambiano componenti che non sono stati nuovamente testati.

In sintesi, le fonti consentono di stabilire che esistono capacità e controlli documentati che giustificano la valutazione di entrambe le opzioni, ma non consentono di quantificare un vantaggio tra esse nell'estrazione affidabile di dati dai documenti. Una decisione tracciabile richiede un test proprietario e ripetibile. Fino alla sua pubblicazione, qualsiasi preferenza deve essere trattata come un'ipotesi di integrazione, costo o conformità, non come un risultato di qualità dimostrato.

Continua a esplorare

Correzioni e trasparenza

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