DeepSeek R1 vs. DeepSeek V3.2: come scegliere tra ragionamento esplicito ed efficienza in un flusso sottoposto a revisione

La decisione non riguarda quale modello sembri migliore, ma quale rischio riduca il flusso

Il confronto tra DeepSeek R1 e DeepSeek V3.2 deve partire da una decisione operativa concreta. Per esempio: analizzare un dossier tecnico, identificare requisiti applicabili nei documenti forniti dall’utente, formulare una raccomandazione strutturata e predisporre un’azione successiva. Tale azione può consistere nella creazione di una bozza, nell’apertura di un caso o nella proposta di un percorso di approvazione, ma non deve essere eseguita senza le validazioni umane e di sistema richieste dal processo.

In questo tipo di flusso, una risposta lunga o un ragionamento visibile non costituiscono di per sé un vantaggio. Ciò che conta è se riducono un errore materiale: una raccomandazione incompatibile con le evidenze, una citazione documentale errata, uno strumento invocato con parametri sbagliati, la mancata astensione in presenza di dati insufficienti oppure un output che il sistema destinatario non può elaborare.

La domanda di acquisto o di distribuzione può essere formulata in modo falsificabile: R1 riduce in misura sufficiente gli errori materiali e il carico di revisione umana nei casi ambigui e in più passaggi, compensando tempo di risposta, token e complessità? Se V3.2 raggiunge la stessa soglia di correttezza, evidenza, astensione e struttura con meno risorse, un ragionamento più lungo non giustifica da solo l’instradamento dell’attività verso R1.

Questo articolo non presuppone che uno dei due modelli sia un sostituto universale dell’altro. Propone un test destinato a responsabili di prodotto, piattaforma e ingegneria che devono scegliere un percorso per ciascun caso e mantenere un’approvazione umana per le decisioni con conseguenze operative.

Identificare con precisione ciò che viene confrontato prima di misurare i risultati

“DeepSeek V3.2” non è un identificatore sperimentale sufficiente. La documentazione di rilascio presenta DeepSeek-V3.2 come successore di V3.2-Exp, mentre il registro delle modifiche indica l’aggiornamento degli alias deepseek-chat e deepseek-reasoner a DeepSeek-V3.2 il 1° dicembre 2025. Di conseguenza, un rapporto riproducibile deve registrare l’identificatore richiesto, l’alias effettivamente usato, data e ora dell’esecuzione, il canale di accesso e la versione o revisione dell’artefatto locale nel caso venga eseguito un checkpoint.

La scheda pubblicata di DeepSeek-V3.2 permette di fissare un artefatto per una valutazione locale, ma un test locale e un test tramite API non sono automaticamente intercambiabili. Possono differire per hardware, runtime, quantizzazione, server di inferenza, limiti di contesto, code, controlli di sicurezza, politica di ritentativi e tariffazione. Possono anche cambiare il template conversazionale o l’elaborazione degli strumenti. Il confronto deve dichiarare tali differenze, anziché attribuirle al modello.

Anche DeepSeek R1 richiede la documentazione della procedura utilizzata. Il repository ufficiale descrive un contesto di 128K e, per la sua valutazione pubblicata, indica una generazione massima di 32.768 token, temperatura pari a 0,6 e top_p pari a 0,95 nel campionamento. Questi valori non garantiscono di essere ottimali per ogni attività, ma costituiscono un riferimento importante. Se il test se ne discosta, deve motivarlo e valutare se la modifica favorisca o penalizzi R1.

Non è opportuno imporre una configurazione identica quando le interfacce documentate presentano vincoli diversi. L’uguaglianza rilevante è quella dell’opportunità di risolvere l’attività: stesso corpus, stessi strumenti disponibili, stesse regole di successo, stesso limite temporale operativo e una politica di ritentativi definita prima di osservare i risultati. Le configurazioni specifiche di ciascun modello devono essere registrate come parte dell’esperimento.

Formulare un’ipotesi che possa essere smentita

L’ipotesi non dovrebbe essere che R1 “ragiona meglio” né che V3.2 “è più efficiente”. Entrambe le espressioni sono troppo imprecise per una decisione di piattaforma. Un’ipotesi utile potrebbe essere la seguente: nei dossier con evidenze contraddittorie, dipendenze tra documenti e necessità di consultare strumenti simulati, R1 ottiene un tasso più elevato di decisioni corrette e di astensioni corrette, riducendo il numero di revisioni umane in modo operativamente rilevante.

Deve essere definita anche l’ipotesi contraria: nelle richieste dirette, con evidenze sufficienti e un singolo passaggio decisionale, V3.2 raggiunge la soglia di qualità concordata con minore latenza, meno token in output o un costo inferiore per risultato accettato. In questo caso, V3.2 sarebbe il percorso preferibile per tale strato, anche se R1 ottenesse un punteggio medio leggermente più alto.

È opportuno stabilire in anticipo quale risultato invalida ciascuna proposta. Per esempio, R1 non giustifica un percorso specializzato se il suo miglioramento negli errori materiali non supera il margine stabilito, se il miglioramento scompare ripetendo i casi o se deriva da un formato di prompt, un recupero documentale o un’infrastruttura differenti. V3.2 non dovrebbe essere il percorso predefinito se mantiene un tasso inaccettabile di raccomandazioni prive di supporto o se non si astiene in modo adeguato.

Le soglie devono appartenere al processo. Un flusso che prepara risposte interne a basso impatto può tollerare una revisione a campione. Un flusso che incide su impegni contrattuali, operazioni o persone può richiedere evidenze obbligatorie, blocchi basati su regole e approvazione umana in ogni caso. La valutazione misura le prestazioni in condizioni date; non trasforma il modello in un’autorità autonoma.

Progettare l’esperimento per misurare un’attività, non la capacità di impressionare

Costruite un corpus congelato prima di eseguire il primo modello. Ogni caso deve contenere i documenti e i metadati che entrambi i sistemi riceveranno, una chiave di valutazione elaborata indipendentemente e un’etichetta di strato. Il corpus può includere attività dirette, dossier estesi, ambiguità deliberate, contraddizioni, informazioni incomplete e casi in cui la risposta corretta consiste nell’astenersi o nell’escalare a una persona.

La chiave di valutazione deve separare i fatti verificabili dai criteri degli esperti. I fatti possono includere una decisione corretta, campi obbligatori, riferimenti a evidenze consentite, parametri attesi degli strumenti e condizioni di astensione. I criteri degli esperti possono valutare chiarezza, priorità o qualità della spiegazione. Questi ultimi devono essere esaminati alla cieca rispetto al modello, con istruzioni e risoluzione dei disaccordi documentate.

Fornite a entrambi i modelli esattamente lo stesso contenuto operativo e lo stesso schema di output. Se gli strumenti sono abilitati, simulate risposte deterministiche affinché una differenza non derivi da sistemi esterni variabili. La guida alle chiamate di strumenti documenta il supporto agli strumenti in modalità thinking a partire da V3.2 e una modalità rigorosa orientata alla conformità con JSON Schema. Se si utilizza tale opzione, applicatela in modo coerente dove compatibile e misurate separatamente la validità sintattica del JSON e la validità semantica dei valori.

Registrate temperatura, top_p, limite di output, seme quando disponibile, numero massimo di chiamate, limite temporale e politica di ritentativi. Per R1, la documentazione pubblicata raccomanda una configurazione specifica per la sua valutazione e consiglia più esecuzioni in determinati scenari. Per stimare la stabilità non basta quindi una sola risposta per caso: ripetete ciascun caso un numero prestabilito di volte e comunicate la distribuzione dei risultati, non soltanto il tentativo migliore.

Non mescolate modifiche al prompt con modifiche al modello. Se il formato fallisce, mantenete un ciclo diagnostico distinto dal confronto principale. Se il prompt o il parser vengono modificati dopo aver osservato un errore, rieseguite entrambi i modelli con la nuova configurazione. In caso contrario, l’esperimento non distingue più l’effetto del modello da quello dell’iterazione del team.

Misurare separatamente correttezza, evidenza, astensione e costo

L’accuratezza finale è necessaria, ma non sufficiente. Una raccomandazione può coincidere casualmente con la chiave e tuttavia citare evidenze errate o predisporre un’azione con parametri non sicuri. Misurate la correttezza della decisione, la copertura degli elementi obbligatori e la fedeltà delle evidenze: ogni affermazione rilevante deve poter essere collegata a un passaggio consentito del corpus del caso.

L’astensione richiede una metrica specifica. Distinguete l’astensione corretta — il modello riconosce di non poter decidere con i dati disponibili — dall’astensione eccessiva — inoltra casi risolvibili — e dalla falsa sicurezza — decide quando avrebbe dovuto effettuare un’escalation. Quest’ultima è spesso più rilevante di una moderata perdita di produttività nei processi a impatto elevato. La rubrica deve indicare quali dati mancanti, conflitti o limiti di autorità richiedono escalation.

Per gli strumenti, misurate almeno quattro aspetti: selezione dello strumento appropriato, parametri validi, interpretazione corretta della risposta e decisione successiva coerente con tale risposta. Una chiamata con JSON valido non è necessariamente utile; allo stesso modo, una risposta con un formato imperfetto può contenere una decisione corretta che il sistema non può accettare. Mantenete separate le metriche di struttura e di contenuto.

La misurazione operativa deve includere latenza end-to-end per percentili, token in output, numero di chiamate agli strumenti, ritentativi e costo per caso accettato. Il denominatore è importante: dividere il costo per tutte le risposte può nascondere il costo di quelle realmente utilizzabili dopo la validazione. Riportate inoltre il volume di revisione umana richiesto e il tempo di correzione per tipo di errore.

Diagnosticare la causa di una differenza prima di attribuirla al ragionamento

Presentate i risultati per strato, oltre alla media complessiva. Una media può nascondere il fatto che R1 apporti valore soltanto in una minoranza di dossier ambigui o che V3.2 risolva in modo sufficiente la maggior parte delle richieste semplici. Incrociate i risultati con lunghezza del contesto, numero di documenti, necessità di strumenti, contraddizione tra fonti e condizione di astensione.

Quando emerge una differenza, classificate il primo punto di fallimento. Può trovarsi nel recupero delle evidenze, nella comprensione di un’istruzione, nella pianificazione di una chiamata, nella generazione degli argomenti, nel parser, nell’esaurimento del tempo, nel ritentativo o nell’infrastruttura. Esaminate le tracce senza rivelare al valutatore quale modello le abbia prodotte, quando ciò sia praticabile. La guida della modalità thinking tratta il contenuto di ragionamento come un elemento con gestione specifica e stabilisce requisiti per determinati flussi con strumenti; l’arnese di test deve rispettare tale contratto anziché mescolare improvvisatamente i contenuti di ragionamento con lo storico.

Non usate il ragionamento esposto come prova di verità. Può aiutare la diagnosi se il canale e la politica sui dati consentono di registrarlo, ma la validazione deve basarsi sull’output finale, sulle evidenze fornite e sugli eventi degli strumenti. Inoltre, la conservazione delle tracce può avere implicazioni di privacy, sicurezza e governance che devono essere valutate separatamente.

Se la differenza scompare uniformando quantizzazione, server, lunghezza massima o ritentativi, il risultato non dimostra una superiorità generale del modello. Allo stesso modo, se un modello ottiene un vantaggio perché riceve un prompt specializzato, la conclusione valida è che la combinazione modello-configurazione funziona meglio con quell’arnese di test, non che il modello isolato sia superiore in qualsiasi ambiente.

Trasformare i risultati in una regola di instradamento e mantenere i controlli umani

L’output dell’esperimento deve essere una regola operativa, non una dichiarazione generica di vincitore. Una possibile politica consiste nell’inviare a V3.2 i casi diretti che superano la soglia di correttezza, evidenza e struttura entro un budget definito; nell’inviare a R1 i dossier con ambiguità, dipendenze multiple o pianificazione degli strumenti quando abbia dimostrato una riduzione materiale degli errori; e nell’escalare a una persona i conflitti di evidenze, l’assenza di dati critici e i casi al di fuori dell’autorità delegata.

Prima della distribuzione, testate la regola in modalità ombra. Il sistema può produrre una raccomandazione e un’azione predisposta senza che questa abbia effetto, mentre un revisore confronta i risultati con il processo esistente. Stabilite avvisi per l’aumento delle astensioni omesse, il calo delle evidenze valide, il peggioramento della latenza e i cambiamenti di comportamento successivi a un aggiornamento di alias o infrastruttura.

L’approvazione finale non deve essere delegata soltanto perché il modello ha superato un test. La valutazione non dimostra conoscenze aggiornate al di fuori del corpus, sicurezza degli strumenti reali, conformità normativa, resistenza agli input avversari né generalizzazione a un altro dominio. Non elimina neppure la necessità di privilegi minimi, validazione deterministica dei parametri, registri verificabili e meccanismi di rollback.

DeepSeek V3.2 offre disponibilità documentata in App, Web e API e la documentazione dell’API descrive capacità di thinking e strumenti. Questi fatti facilitano la definizione di un test, ma non dimostrano che un canale soddisfi di per sé requisiti di residenza dei dati, conservazione, capacità, prezzo o disponibilità. Tali condizioni devono essere confermate per lo specifico account, la regione e la data di contrattazione prima di una decisione di acquisto.

Continua a esplorare

Correzioni e trasparenza

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