Come valutare Command R 08-2024 in presenza di evidenze incomplete nei sistemi RAG

A quale domanda risponde questa valutazione

Un sistema di generazione aumentata dal recupero, o RAG, riceve documenti recuperati e li usa come contesto per rispondere. La prova qui proposta pone una domanda circoscritta: quando a Command R 08-2024 viene fornito un insieme di estratti documentali, il modello distingue ciò che gli estratti supportano, ciò che contraddicono e ciò a cui non consentono di rispondere? Non si tratta di misurare tutte le capacità linguistiche del modello né di riprodurre un punteggio pubblicato dal fornitore.

L’unità di analisi sarà una risposta prodotta a partire da un contesto documentale specificato. Verranno valutate separatamente l’accuratezza della risposta, il supporto delle sue affermazioni, la qualità delle citazioni, la gestione delle contraddizioni e la decisione di astenersi. Separare queste dimensioni evita che una risposta scorrevole o un dato aggregato nascondano errori diversi: per esempio, una conclusione casualmente corretta, una citazione che menziona l’argomento ma non dimostra l’affermazione, oppure un’astensione di fronte a informazioni esplicite.

L’ambito esclude inoltre conclusioni generali su tutte le versioni di Command R, su Command R+ o sulle prestazioni in produzione di un sistema completo. Una prova svolta con un corpus, istruzioni e parametri determinati descrive quegli elementi specifici. Da sola non consente di affermare che il modello si comporterà allo stesso modo con altri documenti, utenti, configurazioni di recupero o condizioni di servizio.

Identificare il modello prima di metterlo alla prova

Il nome commerciale non basta a identificare in modo riproducibile il sistema che ha generato una risposta. Il registro deve includere l’identificatore esatto, il canale di accesso, la data di ogni esecuzione e la configurazione disponibile. Deve inoltre conservare la richiesta inviata e, quando il canale lo consente, i parametri di generazione e gli eventuali metadati restituiti. Se un fornitore modifica il modello dietro un nome senza consentire di fissare una revisione, questa limitazione deve essere dichiarata come parte del metodo.

La documentazione di Cohere relativa all’aggiornamento di agosto identifica Command R 08-2024 e presenta miglioramenti nel recupero aumentato multilingue e nell’uso di strumenti. Questa descrizione serve a documentare ciò che il fornitore dichiara sull’aggiornamento, ma non costituisce una verifica indipendente delle metriche previste da questo protocollo. La descrizione di una scheda del modello o una valutazione del fornitore non deve quindi sostituire l’esperimento controllato qui proposto.

La documentazione disponibile di Oracle identifica cohere.command-r-08-2024 nel proprio servizio e indica il modello come deprecato. Questo dato permette di segnalare una limitazione relativa a quel canale, ma non dimostra che l’identificatore non sia disponibile altrove. Il repository di Cohere Labs, a sua volta, identifica una versione di ricerca con pesi aperti. Prima di eseguire la prova, occorrerebbe verificare direttamente quale artefatto o servizio verrà utilizzato, quale versione specifica fornisce e quali condizioni d’uso si applicano. Le fonti fornite non bastano a confermare la disponibilità attuale né tutti i parametri operativi.

Costruire un corpus con tre condizioni

Il set deve includere tre classi di casi, distinte fin dalla progettazione. Nei casi con evidenze sufficienti, la risposta può essere ricavata da uno o più passaggi identificabili. Nei casi contraddittori, due o più documenti sostengono versioni incompatibili di un dato rilevante. Nei casi privi di evidenze sufficienti, il materiale fornito non permette di rispondere in modo giustificato, anche se la domanda sembra plausibile. Questa terza categoria non va confusa con un documento difficile da trovare: l’assenza deve essere verificata nel corpus definito per la prova.

È opportuno utilizzare documenti controllati, registrandone provenienza e data, e formulare le domande prima di osservare le risposte del modello. Per ogni domanda, un revisore dovrebbe determinare in anticipo quali passaggi la supportano, se esiste un conflitto e quali informazioni mancano. Questa revisione definisce l’etichetta di riferimento e riduce il rischio di decidere a posteriori che una risposta inattesa fosse corretta solo perché suona ragionevole.

Il corpus dovrebbe rappresentare gli usi che si intendono studiare senza introdurre differenze accidentali tra le categorie. Se i casi contraddittori sono molto più lunghi o hanno formati diversi rispetto ai casi con evidenze sufficienti, il risultato potrebbe riflettere tali differenze oltre alla capacità di riconoscere i conflitti. Una tabella di composizione dovrebbe riportare il numero di domande per condizione, la quantità e la lunghezza dei documenti, le lingue, le date e ogni criterio di selezione. Queste scelte non vanno presentate come un campione universale della documentazione interna.

Fissare recupero, istruzioni ed esecuzione

Per valutare il comportamento del modello di fronte alle evidenze, occorre descrivere tutti i componenti che incidono sul contesto. Se la domanda viene fornita insieme a estratti già selezionati, si valuta la risposta del modello condizionata da quegli estratti, non la qualità di un motore di ricerca. Se si usa un componente di recupero, occorre conservare anche la query, i documenti candidati, il loro ordine, il numero di estratti e il criterio di selezione. Senza questa distinzione, un errore del sistema di recupero potrebbe essere attribuito al modello generativo, o viceversa.

Le istruzioni devono essere identiche per tutti i casi, a meno che un confronto controllato non modifichi deliberatamente una variabile. Dovrebbero indicare come presentare le evidenze e cosa fare quando mancano o sono in conflitto. La richiesta di astenersi merita particolare attenzione: un’istruzione ambigua può misurare l’interpretazione del prompt tanto quanto la capacità di riconoscere un’insufficienza. Per questo è necessario pubblicarne il testo letterale ed evitare di adattarlo caso per caso dopo aver visto le risposte.

Il piano deve specificare quante esecuzioni verranno effettuate per ogni domanda. Se il canale non consente di controllare o conoscere determinati parametri, occorre annotarlo. Ripetere un’esecuzione può aiutare a osservare la variabilità, ma non rende automaticamente il set un campione rappresentativo. Vanno conservate anche le esecuzioni fallite e le risposte che non rispettano il formato richiesto, invece di eliminarle senza dichiararlo.

Misurare separatamente ogni dimensione

L’accuratezza fattuale deve valutare se la risposta è coerente con ciò che si può stabilire sulla base del corpus e del riferimento revisionato. Il supporto delle affermazioni pone una domanda diversa: ogni affermazione sostanziale della risposta è sostenuta dai documenti forniti? Una risposta può indovinare il dato principale e aggiungere dettagli non supportati dal corpus; una sola etichetta di «corretta» nasconderebbe il problema.

La valutazione delle citazioni deve verificare se il passaggio indicato sostiene l’affermazione specifica a cui è associato. Una semplice corrispondenza tematica non basta: il fatto che una citazione menzioni un reso non dimostra necessariamente il termine citato. Se l’output non include riferimenti espliciti ai passaggi, questa dimensione deve essere indicata come non valutabile o adattata al formato concordato, non valutata come se le citazioni fossero presenti.

La gestione delle contraddizioni deve misurare se la risposta rileva il conflitto, identifica le versioni pertinenti ed evita di presentare una di esse come indiscutibile senza basi nei documenti. L’astensione appropriata deve distinguere tra l’astensione dovuta all’assenza di supporto e il rifiuto non necessario quando il corpus contiene una risposta. È possibile riportare tassi o conteggi per ciascuna categoria, purché siano accompagnati dai denominatori, dalle regole di annotazione e da esempi. Non è consigliabile ridurre tutte le dimensioni a un punteggio aggregato senza motivare il modo in cui vengono ponderate.

Annotazione, controlli e contaminazione

L’annotazione deve seguire regole formulate prima di esaminare gli output. Quando è praticabile, due revisori possono valutare le risposte in modo indipendente e senza sapere quale configurazione le abbia prodotte. I disaccordi non devono scomparire in una media opaca: occorre registrare le dimensioni su cui divergono, come viene risolto ciascun caso e quali esempi restano ambigui. È inoltre utile conservare sia le risposte originali sia la versione normalizzata utilizzata nell’analisi, spiegando ogni trasformazione.

La contaminazione del set di valutazione è un limite distinto dalla qualità del recupero. Domande o documenti eventualmente presenti in precedenza nei dati di addestramento potrebbero influenzare una risposta, ma le fonti qui disponibili non consentono di stabilire se ciò sia avvenuto per un set specifico. Occorre descrivere ciò che si sa sulla provenienza dei documenti e sulla data di creazione delle domande, e dichiarare quale eventuale esposizione precedente non è possibile verificare. Non è corretto affermare che un set sia privo di contaminazione senza prove sufficienti a sostenerlo.

I controlli includono anche la verifica che le etichette di riferimento non rivelino inavvertitamente la risposta nella domanda stessa, che gli estratti siano forniti in modo coerente e che i problemi di accesso non vengano scambiati per risposte del modello. Se il prompt, il recupero o il corpus vengono modificati nel corso dello studio, la nuova condizione deve essere trattata come una variante distinta e documentata. La comparabilità dipende dalla possibilità di ricostruire che cosa è cambiato.

Comparabilità e limiti di interpretazione

Una prova di questo tipo descrive il comportamento osservato con una configurazione, un corpus e istruzioni specifiche. Non è sufficiente per concludere che Command R 08-2024 sia adatto a qualsiasi sistema RAG, né per classificare modelli valutati con documenti, prompt, accessi o rubriche differenti. Un confronto diretto con Command R+ richiederebbe una valutazione parallela, con versioni identificate e condizioni equivalenti; il protocollo qui descritto non fornisce risultati comparativi.

Le dichiarazioni del fornitore relative a un aggiornamento possono aiutare a identificare gli aspetti che si intendono migliorare, ma non devono essere trasformate nei risultati di questo esperimento. Analogamente, la disponibilità di un modello su un canale non descrive necessariamente quella su altri canali. Se un accesso riproduce pesi aperti e un altro usa un servizio gestito, il rapporto deve considerarli configurazioni diverse, a meno che non si possa verificare che corrispondano allo stesso artefatto e a condizioni comparabili.

Anche la possibilità di generalizzare dipende dalla progettazione del corpus. Un set piccolo o concentrato in un ambito documentale può essere utile per individuare errori e perfezionare una configurazione, ma non giustifica la promessa che il comportamento sarà identico in altri domini, lingue o tipologie di documenti. Il rapporto deve comunicare incertezza e copertura, non solo il risultato più appariscente. Se non è possibile identificare e fissare il modello esatto, la scelta metodologicamente corretta è non pubblicare punteggi attribuiti a quella versione.

Pubblicare la prova affinché altri possano ripeterla

Un rapporto riproducibile deve includere il protocollo, l’identificatore e il canale di accesso, la data di esecuzione, le istruzioni testuali, la configurazione registrata, il formato del contesto, le domande, le regole di annotazione e i risultati disaggregati. Deve inoltre spiegare come sono stati trattati gli output non validi, gli errori del servizio e i disaccordi tra revisori. Se un elemento non può essere condiviso, occorre specificare quale e perché: l’assenza di un artefatto non deve essere mascherata facendo apparire il metodo completamente riproducibile.

Prima di pubblicare documenti o query è necessario verificare se diritti, riservatezza o altre condizioni ne impediscano la divulgazione. Se non è possibile condividerli, tra le alternative figurano la descrizione della struttura del set, la pubblicazione di esempi sintetici chiaramente identificati come tali o la possibilità di svolgere una valutazione controllata. Queste opzioni non sostituiscono automaticamente la pubblicazione dei dati: riducono la possibilità di una ripetizione indipendente, e tale limite deve essere dichiarato esplicitamente.

Per un gruppo di lavoro, la conclusione pratica è usare la prova come strumento diagnostico, non come autorizzazione automatica alla messa in produzione. Se il sistema risponde con citazioni, è importante verificare se queste sostengono le affermazioni. Se il rischio principale riguarda documenti obsoleti o contraddittori, occorre provare questi casi con i propri materiali e regole di risoluzione adeguate. Se è necessaria un’astensione sicura, il comportamento accettabile per il dominio specifico va definito prima di osservare le risposte.

Conclusione: un protocollo non è un risultato

La domanda utile non è se un modello «citi bene» in astratto, ma che cosa faccia di fronte a evidenze definite e in condizioni che altri possano esaminare. Distinguere tra evidenze sufficienti, contraddizione e assenza permette di progettare controlli diversi per ciascuna situazione. Separare accuratezza, supporto, qualità delle citazioni e astensione impedisce che un singolo punteggio o una risposta convincente nascondano errori rilevanti.

Le fonti verificate fornite consentono di identificare Command R 08-2024 nella documentazione di Cohere e in un repository di Cohere Labs, e di segnalare che la documentazione Oracle consultata indica il modello come deprecato in quel servizio. Non dimostrano che la prova proposta sia stata eseguita, non confermano la disponibilità attuale su tutti i canali e non forniscono risultati indipendenti sulle citazioni, sulle contraddizioni o sull’astensione. Per questo l’articolo presenta il progetto e le condizioni di validità senza attribuire punteggi al modello.

Un gruppo che intenda applicare il protocollo alla propria documentazione interna dovrà creare un set revisionato, stabilire che cosa significhi che una risposta è supportata e decidere quali livelli di incertezza siano accettabili. Solo dopo aver verificato la versione ed eseguito la prova secondo le condizioni registrate sarà opportuno riportare risultati. Anche in quel caso, le conclusioni resteranno limitate alla configurazione e al corpus esaminati.

Continua a esplorare

Correzioni e trasparenza

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