Claude Sonnet 5 e Cohere Embed 4 nel RAG multimodale: come separare un errore di recupero da un errore di risposta

Non è un confronto diretto fra due modelli

Claude Sonnet 5 e Cohere Embed 4 non risolvono lo stesso compito in un'architettura di generazione aumentata dal recupero, o RAG. Il primo può occupare il livello di generazione: riceve un'istruzione e l'evidenza recuperata, quindi produce una risposta. Il secondo può occupare il livello di rappresentazione e recupero: trasforma gli input in vettori per localizzare contenuti correlati prima che il generatore risponda. Presentarli come se uno fosse un'alternativa all'altro nasconde la causa dei risultati e porta a modifiche dell'architettura attribuite in modo errato.

La domanda operativa non è quale dei due sia “migliore”, bensì quale combinazione di recuperatore e generatore fornisca evidenza localizzata e risposte fondate per un corpus, un insieme di query e vincoli concreti. Una risposta fluida non dimostra che l'indice abbia trovato la fonte corretta. Allo stesso modo, il fatto che il passaggio appropriato compaia fra i risultati non dimostra che il modello generativo lo abbia interpretato, citato e delimitato correttamente.

La documentazione di Anthropic identifica il modello API come `claude-sonnet-5`. La documentazione di Cohere descrive invece `embed-v4.0` e richiede di dichiarare un tipo di input, inclusi valori per documenti di ricerca, query di ricerca e immagini. Questi elementi permettono di fissare le variabili dell'esperimento, ma non consentono da soli di dedurre un vantaggio su uno specifico corpus aziendale.

La valutazione deve trattare il sistema come una catena di decisioni osservabili: conversione del documento, segmentazione, indicizzazione, recupero, composizione del contesto, generazione, validazione e presentazione. Se si misura soltanto la risposta finale, il team non può sapere se un errore dipenda da una pagina assente, da un frammento troppo piccolo, da una query vettorizzata male, da un contesto troncato o da un'affermazione generata senza supporto.

Cosa può apportare ciascun livello e cosa non dimostrano le schede tecniche

Cohere presenta Embed Multimodal v4 come una famiglia di embedding multimodali unificati. La sua documentazione indica recupero fra testo e immagini e fra testo e modalità miste, oltre a un contesto dichiarato fino a 128k e dimensioni Matryoshka di 256, 512, 1024 e 1536. In un RAG di PDF con testo, tabelle e immagini, queste proprietà giustificano la sperimentazione di rappresentazioni coerenti per diversi tipi di evidenza. Non dimostrano che una certa dimensione, né che un embedding multimodale in quanto tale, migliori ogni raccolta documentale.

La dimensione scelta è una variabile sperimentale, non un dettaglio implementativo. Influisce sull'archiviazione, sulla latenza di ricerca e potenzialmente sul comportamento di vicinato dell'indice. Lo stesso vale per il modo in cui viene rappresentata una pagina: come testo estratto, come immagine della pagina, come regione di tabella, come combinazione di tali oggetti o come più unità collegate tramite metadati. Un test riproducibile deve conservare questa scelta in tutti i rami che non valutano esplicitamente l'indicizzazione.

Claude Sonnet 5 va valutato come consumatore di evidenza, non come sostituto silenzioso del recupero. Una risposta corretta quando l'evidenza non è comparsa nel contesto può derivare dalla conoscenza pregressa del modello, da una coincidenza fortunata o da un difetto nei log della pipeline. In un'applicazione che richiede risposte basate esclusivamente sul corpus, tale caso non dimostra il recupero: va etichettato come risposta non attribuibile all'insieme documentale oppure escluso dalla metrica delle risposte fondate.

Anche i modelli generativi possono fallire pur ricevendo i passaggi corretti. Possono omettere una condizione presente in una tabella, fondere due fonti incompatibili, interpretare una cifra fuori dal proprio ambito oppure includere una citazione che rimanda a una fonte correlata ma non sostiene l'affermazione. Le citazioni sono quindi oggetti da valutare, non ornamenti dell'interfaccia.

Costruire un corpus che consenta di diagnosticare, non soltanto di assegnare punteggi

Il corpus di valutazione deve essere congelato prima di confrontare le configurazioni. Includete PDF nativi e scansionati, pagine prevalentemente testuali, tabelle con intestazioni e note a piè di pagina, immagini con informazioni rilevanti e documenti che combinano questi elementi. L'obiettivo non è riprodurre ogni variante della documentazione aziendale, ma dichiarare con precisione quali varianti sono incluse ed evitare che un miglioramento apparente dipenda da documenti aggiunti o corretti durante il test.

Ogni query richiede una risposta di riferimento e, soprattutto, una definizione di evidenza sufficiente. Tale evidenza può essere una pagina, una regione di tabella, più passaggi distribuiti o una combinazione di testo e immagine. Registrate identificatori stabili di documento, versione, pagina, regione e frammento. Quando l'evidenza è distribuita, il giudizio sul recupero deve richiedere l'insieme necessario, non soltanto uno dei suoi componenti.

È utile stratificare le query secondo il loro schema probatorio. Quelle con evidenza unica mostrano se il recuperatore trova un fatto localizzato. Quelle multifonte rivelano se consegna tutte le parti necessarie senza perderne la relazione. Quelle contraddittorie verificano se il sistema preserva provenienza e contraddizione invece di selezionare arbitrariamente una fonte. Le query senza evidenza verificano che l'assistente si astenga anziché completare la risposta con conoscenza esterna o inferenze non giustificate.

Riservate una partizione finale che non sia usata per regolare dimensione dei frammenti, sovrapposizione, dimensioni vettoriali, numero di risultati, istruzioni o regole di validazione. Se una decisione viene presa dopo avere osservato la partizione di test, quella partizione non è più una misura indipendente. Dimensione del campione, distribuzione per strato e protocollo di annotazione devono essere pubblicati insieme ai risultati.

Fissare le condizioni prima di eseguire la matrice fattoriale

Il confronto richiede una pipeline di base esplicita. Mantenete invariati parser o OCR, politica di risoluzione delle pagine, segmentazione, sovrapposizione, metadati, database vettoriale, filtri, metodo di ricerca, numero di risultati recuperati, reranking — se presente —, composizione del contesto, prompt, politica delle citazioni, massimo di output e tentativi ripetuti. Se uno di questi elementi cambia fra rami, l'effetto non può essere attribuito in modo netto a Cohere Embed 4 o a Claude Sonnet 5.

Documentate inoltre canale di accesso, data e ora della consultazione, regione quando pertinente, versione di SDK o API, identificatore effettivo del modello e parametri inviati. Per Cohere Embed 4, registrate almeno `embed-v4.0`, dimensione, modalità di ciascun oggetto e `input_type`. La documentazione dell'endpoint distingue gli usi `search_document`, `search_query` e `image`; usare tipi diversi senza annotarlo altererebbe il test. Per Claude Sonnet 5, conservate la richiesta effettiva, la risposta non post-elaborata e il contesto che l'ha accompagnata.

Definite un baseline utile e riproducibile. Può essere un embedding già adottato dal team e un generatore esistente, ma deve restare immutabile nel corso dell'esperimento. Non presentate il baseline come riferimento universale: è soltanto il punto di confronto per quel sistema. Se introducete il reranking, esso deve restare identico nei quattro rami o essere valutato come fattore aggiuntivo, poiché potrebbe mascherare o amplificare differenze di recupero.

L'unità di analisi deve essere la query, ma i risultati vanno raggruppati anche per tipo di documento e schema di evidenza. Una media generale può nascondere che una modifica aiuti a localizzare pagine visive e peggiori le domande testuali brevi, oppure che migliori il recall aumentando però il contesto irrilevante consegnato al generatore.

La matrice fattoriale: quattro configurazioni, una sola domanda di attribuzione

Eseguite quattro rami sulle stesse query. Il primo usa recuperatore e generatore di riferimento. Il secondo sostituisce soltanto il livello di embedding con Cohere Embed 4, mantenendo il generatore di base. Il terzo conserva il recupero di base e usa soltanto Claude Sonnet 5 per generare. Il quarto combina Cohere Embed 4 e Claude Sonnet 5. Se il sistema usa già uno dei due come riferimento, ridefinite i rami affinché ciascun fattore mantenga una condizione di controllo chiaramente identificabile.

Questa matrice consente di stimare cambiamenti condizionali, non di stabilire una gerarchia assoluta fra fornitori. La differenza fra primo e secondo ramo si interpreta come cambiamento associato al recupero con il generatore di base. Quella fra primo e terzo ramo riflette il cambiamento di generazione con evidenza recuperata dal baseline. Il quarto ramo mostra il comportamento della combinazione, inclusa una possibile interazione: il generatore può sfruttare meglio un'evidenza differente, oppure il cambiamento nel recupero può non tradursi in risposte migliori.

Eseguite più ripetizioni se la generazione non è deterministica e conservate semi o parametri di campionamento quando disponibili. Per compiti di accuratezza e astensione, una configurazione generativa conservativa riduce la varianza e facilita l'audit. Il confronto dei costi deve includere indicizzazione ammortizzata, embedding delle query, recupero, generazione, validazione e ritentativi; riportare soltanto il costo della generazione sposterebbe la spesa da un livello a un altro senza rappresentare l'operatività reale.

Misurare evidenza e risposta come risultati distinti

Per il recupero, misurate il recall dell'evidenza: la quota di query per le quali l'evidenza sufficiente compare fra i risultati consegnati al generatore. Integratelo con la precisione del recupero, ossia la quota di risultati rilevanti, perché aumentare indiscriminatamente il numero di frammenti può elevare il recall e peggiorare il contesto. Nelle domande con evidenza distribuita, misurate il recupero completo dell'insieme annotato e non la sola presenza di una fonte parziale.

Per la risposta, valutate fedeltà fattuale rispetto ai documenti, copertura dei punti richiesti dalla query, correttezza dell'astensione in assenza di evidenza e validità del formato quando l'applicazione richiede una struttura, come JSON. La copertura non equivale alla fedeltà: una risposta può menzionare tutti i temi e contenere una cifra errata. Nemmeno la fedeltà equivale all'utilità: una risposta strettamente supportata può omettere una condizione necessaria.

Aggiungete una metrica di citazione supportata a livello di singola affermazione verificabile. Un revisore, idealmente cieco rispetto alla configurazione, deve decidere se la citazione o il riferimento di provenienza sostenga esattamente l'affermazione associata. Si può usare un grader automatico con una rubrica sottoposta ad audit, ma va confrontato con una revisione umana su un campione e devono esserne conservati i disaccordi. RAGBench propone un approccio di valutazione spiegabile pertinente per scomporre i risultati anziché ridurli a un punteggio finale.

Riportate la latenza p50 e p95 per risposta, non soltanto le medie. Separate il tempo di indicizzazione dal tempo di query, anche se il primo viene incluso come costo ammortizzato in una metrica economica. Per le decisioni di prodotto, la misura più utile è spesso costo e latenza per risposta corretta e fondata, purché sia pubblicata la definizione di “corretta” e il denominatore includa le astensioni appropriate.

Diagnosticare gli schemi di errore

Quando l'evidenza annotata non compare fra i risultati, l'incidente appartiene inizialmente al recupero o a una fase precedente di conversione e indicizzazione. Verificate se testo o immagine fossero disponibili dopo il parser, se l'unità indicizzata conservasse il contesto della tabella, se i metadati avessero filtrato il documento e se la query usasse la modalità e il tipo di input dichiarati. Cambiare generatore non corregge l'assenza di evidenza nel contesto.

Quando l'evidenza sufficiente compare ma la risposta è errata, l'incidente riguarda l'uso dell'evidenza, salvo che la composizione del contesto abbia troncato il passaggio rilevante prima dell'invio. Confrontate il testo consegnato con l'affermazione finale: ciò rivela omissioni, fusioni di fonti, inferenze eccessive e contraddizioni ignorate. Qui può essere ragionevole esaminare istruzione, struttura del contesto, limite di output o modello generativo.

La citazione decorativa è uno schema distinto: la risposta incorpora un riferimento reale, ma questo non sostiene la proposizione concreta. È particolarmente frequente quando il documento contiene termini correlati o quando una tabella viene citata a livello di pagina mentre la cifra proviene da un'altra riga. Etichettarla come semplice risposta errata impedisce di capire se il problema risieda nella generazione delle citazioni, nella granularità della provenienza o nella validazione successiva.

L'astensione ingiustificata richiede una diagnosi opposta. Se esisteva evidenza sufficiente recuperata e il sistema ha risposto di non poter rispondere, possono essere fallite l'istruzione di uso del contesto, l'ordine dei risultati o la leggibilità del contenuto estratto. Se non esisteva evidenza, l'astensione è corretta anche se meno soddisfacente per l'utente. Un sistema affidabile deve distinguere i due casi e spiegare i propri limiti senza inventare una risposta.

Prendere decisioni senza estrapolare oltre l'esperimento

Modificate il livello di recupero quando il deficit principale è l'assenza di evidenza rilevante, soprattutto nei sottoinsiemi nei quali testo, immagini o pagine miste devono essere trovati reciprocamente. Prima di concludere che l'embedding sia la causa, escludete errori di OCR, segmentazione e metadati. Una tabella separata dalle proprie intestazioni, per esempio, può fallire con qualunque embedding perché l'unità indicizzata ha perso la semantica necessaria.

Modificate o regolate il livello generativo quando l'evidenza arriva in modo sufficiente e stabile, ma la risposta la usa male. Anche in questo caso, non presumete che il nome del modello spieghi tutto il cambiamento: sperimentate istruzioni sulle citazioni, formati del contesto e regole di astensione sulla partizione di sviluppo, poi confermate sulla partizione finale. Claude Sonnet 5 va confrontato mediante richieste equivalenti e log completi, non tramite esempi selezionati.

Considerate il reranking se il recall iniziale è ragionevole ma i primi risultati contengono troppo rumore o relegano evidenza decisiva. Considerate la revisione umana per risposte ad alto impatto, contraddizioni documentali, tabelle complesse o casi nei quali la validazione automatica non raggiunga un accordo sufficiente con i revisori. Nessuna di queste misure elimina la necessità di misurare ogni livello: aggiunge un'altra variabile che deve anch'essa essere sottoposta ad audit.

Pubblicate la scheda dell'esperimento insieme ai risultati: definizione e versione del corpus, schema di annotazione, distribuzione delle query, configurazioni effettive, artefatti di recupero, criteri del grader, accordo fra valutatori, intervalli o incertezza statistica, latenza, costo ed errori rappresentativi. Non pubblicate soltanto un tasso aggregato né esempi dimostrativi. Il quadro di valutazione della qualità del recupero e i lavori sul RAG multimodale rafforzano la necessità di osservare separatamente accesso all'evidenza e risposta.

I risultati non sono automaticamente generalizzabili a tutti i repository aziendali. La prevalenza di PDF scansionati, le lingue, la qualità dell'OCR, la densità delle tabelle, i permessi, l'aggiornamento documentale e la tolleranza al costo possono cambiare la decisione. La conclusione difendibile è locale: in condizioni documentate, una configurazione ha recuperato meglio una certa evidenza oppure ha prodotto risposte più fedeli. Questa precisione è più utile dell'attribuire capacità generali a modelli che svolgono funzioni diverse.

Continua a esplorare

Correzioni e trasparenza

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