DeepSeek R1 in produzione: come testare il template del prompt senza compromettere l’applicazione

Le raccomandazioni sono un punto di partenza, non una garanzia

Un template di prompt può migliorare la risposta del modello e, allo stesso tempo, rendere più difficile l’integrazione. Per esempio, un’istruzione che induce a fornire spiegazioni più articolate può essere utile in un’attività di analisi, ma violare il contratto di un’API che si aspetta una risposta breve in JSON. Perciò, quando si distribuisce DeepSeek R1, la domanda pratica non è soltanto quale configurazione raccomandi il fornitore, ma se quella configurazione migliori le attività reali senza introdurre regressioni che incidono sul prodotto.

Il repository ufficiale di DeepSeek R1 fornisce raccomandazioni d’uso relative alla posizione delle istruzioni, al messaggio di sistema e all’inizio della risposta dell’assistente. Consiglia inoltre di effettuare più prove durante la valutazione. Queste indicazioni costituiscono una base per progettare esperimenti, ma non dimostrano da sole che una determinata pratica sia migliore in qualsiasi applicazione. Spetta al team che definisce le attività, i criteri di accettazione e le conseguenze di ogni errore verificarne la validità.

Questo articolo propone un’ablazione controllata: modificare un fattore alla volta, mantenere costanti gli altri e registrare non soltanto se la risposta sembra corretta, ma anche se rispetta il contratto di output. L’obiettivo è valutare DeepSeek R1 nel contesto di una specifica applicazione. Non si tratta di un confronto con altri modelli né di uno studio volto a stabilire se R1 ragioni meglio di DeepSeek V3.2. Inoltre, non si presume che il testo generato tra i tag di ragionamento descriva fedelmente un processo interno.

Per prima cosa, fissa la versione e la configurazione da testare

Prima di confrontare i prompt, registra quale modello e quale percorso di inferenza vengono usati in ciascuna esecuzione. La scheda ufficiale del modello su Hugging Face, il file di configurazione della generazione e il template di chat del repository sono riferimenti utili per documentare questi elementi. In particolare, il file del template aiuta a determinare come vengono serializzati i messaggi. Due condizioni che nell’interfaccia sembrano diverse possono essere convertite in sequenze di token differenti; oppure, due prove possono smettere di essere confrontabili se nel frattempo cambia il template.

Annota l’identificativo o la revisione esatta dei pesi, il runtime e la sua versione, il template di chat, i parametri di generazione e ogni meccanismo aggiuntivo dell’applicazione: strumenti, validatori, nuovi tentativi o trasformazioni successive. Non modificare contemporaneamente template, temperatura e runtime. Se cambiano più variabili insieme, sarà difficile attribuire con chiarezza un miglioramento o un peggioramento al fattore che si intendeva valutare.

Se usi un servizio compatibile invece dei pesi in un runtime gestito in proprio, documenta quali parametri accetta e quali restano fuori dal controllo del team. Il fatto che un’interfaccia sia compatibile non garantisce, di per sé, che la serializzazione o tutti i dettagli dell’inferenza siano identici. Se non è possibile verificare un dato, riportalo come incertezza nel resoconto, invece di presentarlo come una condizione nota.

Trasforma le raccomandazioni in fattori confrontabili

Progetta le condizioni in modo che ogni confronto risponda a una domanda precisa. Per studiare la posizione delle istruzioni, mantienine equivalente il contenuto e confronta, per esempio, una condizione in cui sono inserite nel messaggio di sistema con un’altra in cui compaiono nel messaggio dell’utente. Se vuoi confrontare anche posizioni diverse all’interno del messaggio dell’utente, crea una condizione separata e conserva invariato il testo dell’istruzione. In questo modo eviti di attribuire alla posizione un effetto che potrebbe invece dipendere da una formulazione diversa.

Il prefisso «<think>» va valutato come fattore indipendente. Confronta una condizione in cui l’inizio della risposta dell’assistente non è forzato con un’altra in cui viene aggiunto il prefisso indicato dalla documentazione, verificando come viene serializzato nel prompt effettivamente inviato. Non combinare questa modifica con quella del messaggio di sistema nello stesso confronto: se una condizione cambia entrambe le cose, un’eventuale differenza non permette di capire quale l’abbia provocata.

La raccomandazione di usare un prefisso non dimostra che questo migliori tutte le attività o sia necessario in ogni runtime. Né consente di concludere che il testo di ragionamento visibile misuri direttamente il funzionamento interno del modello. Valuta ciò che l’applicazione riceve e può verificare: risposta finale, struttura, latenza, errori e coerenza.

Includi attività che rappresentino contratti diversi

Un insieme di test composto soltanto da problemi matematici non rappresenta necessariamente un’applicazione che estrae anche dati, risponde a domande brevi ed elabora documenti. Costruisci un insieme piccolo ma vario, basato sulle attività effettive del prodotto. La varietà non è un dettaglio accessorio: aiuta a individuare i casi in cui una configurazione favorisce un tipo di attività e ne penalizza un altro.

Per una risposta fattuale breve, definisci in anticipo quali informazioni devono comparire e quali contenuti aggiuntivi costituirebbero una violazione. Nell’estrazione strutturata, specifica lo schema, i campi obbligatori e come trattare i dati mancanti. Per un’attività matematica verificabile, conserva la risposta corretta e il metodo di controllo. Per un’attività basata su documenti, fornisci la stessa evidenza a tutte le condizioni e valuta se la risposta è supportata da essa, se distingue ciò che non è documentato e se evita di aggiungere informazioni estranee.

Includi anche casi in cui il comportamento corretto consiste nell’astenersi o nel segnalare che le prove disponibili non bastano. Senza questi casi, la valutazione potrebbe premiare risposte sicure ma infondate. Conserva esempi di errori noti e casi limite, ma separa i dati usati per mettere a punto un template da quelli impiegati nella valutazione finale. Se durante l’esperimento rivedi le istruzioni, registra la modifica e ripeti le condizioni confrontabili.

Misura separatamente la qualità e la compatibilità

Il punteggio principale dovrebbe indicare se la risposta risolve correttamente l’attività secondo criteri scritti prima di esaminare i risultati. Non ridurre tutto a un’impressione generale. Registra anche il rispetto delle istruzioni, la validità del formato, i campi mancanti o inattesi, le astensioni appropriate e quelle improprie. Nelle applicazioni che usano parser, verifica come metrica operativa se la risposta può essere elaborata senza correzioni manuali.

Misura la latenza con un metodo costante e specifica quale intervallo stai misurando: generazione, chiamata completa o tempo percepito dall’utente. Registra anche gli errori di esecuzione e i nuovi tentativi. Le risposte ripetitive o vuote meritano una categoria propria, con regole chiare per identificarle: non nasconderle dentro un punteggio medio di qualità. Una risposta può contenere una parte corretta e risultare comunque inutilizzabile se ripete il testo, omette la chiusura di una struttura o viola il formato richiesto.

Effettua più esecuzioni per ciascuna condizione quando il sistema introduce variabilità. Conserva i risultati individuali oltre a qualsiasi media o riepilogo. Anche per input deterministici e condizioni di generazione che lo consentono, ripetere il test può essere utile per verificare la stabilità dell’ambiente; in presenza di casualità, indica il numero di esecuzioni e la dispersione osservata. Non presentare una differenza minima come un effetto solido senza mostrare quanti casi la sostengono.

Interpreta i risultati contrastanti senza nascondere le regressioni

Supponiamo che una condizione migliori il punteggio dei problemi matematici, ma aumenti gli errori di formato nell’estrazione. Non è corretto descriverla semplicemente come «migliore». La decisione dipende da quale attività sia critica, da quanto costi l’errore e dalla disponibilità di meccanismi affidabili per rilevarlo e recuperare. Un miglioramento medio può nascondere una regressione grave in una funzione specifica.

Confronta prima ogni attività separatamente, poi presenta un riepilogo complessivo spiegando il metodo di aggregazione. Se applichi dei pesi, dichiara chi li ha scelti e quale importanza rappresentano. Quando l’insieme è piccolo, affianca percentuali e conteggi assoluti: passare da zero a un errore non equivale a passare da dieci a undici, anche se un tasso aggregato può apparire simile. Non modificare i pesi dopo aver visto quale condizione ne trae vantaggio.

La documentazione di DeepSeek raccomanda di effettuare più prove durante la valutazione. In pratica, ciò significa conservare la variabilità tra le esecuzioni e non selezionare soltanto una risposta favorevole. Significa anche non generalizzare oltre l’insieme testato: i risultati ottenuti su un gruppo di attività proprie costituiscono evidenze per quella specifica applicazione e per quelle condizioni, non una garanzia universale su R1.

Non confondere il testo di ragionamento con una spiegazione affidabile

Il tag «<think>» fa parte dell’interfaccia testuale di alcuni formati di conversazione di R1, ma la presenza di testo sotto quel tag non dimostra che si stia osservando una trascrizione completa o letterale di un processo interno. La valutazione dovrebbe concentrarsi su risultati osservabili e verificabili. Per una risposta matematica, controlla il risultato; per un’estrazione, confronta i campi con il documento; per un’astensione, verifica se le evidenze disponibili erano insufficienti.

Il lavoro pubblicato con il titolo DeepSeek-R1 Thoughtology analizza caratteristiche del comportamento di ragionamento di R1 e affronta aspetti come la lunghezza, la controllabilità e la ruminazione. Questo contesto aiuta a motivare il monitoraggio delle risposte ripetitive e della lunghezza, ma non sostituisce le misurazioni dell’applicazione né dimostra in anticipo cosa accadrà modificando un template. Una spiegazione lunga non è, di per sé, la prova di una risposta migliore; una spiegazione breve non dimostra che l’attività sia stata risolta senza ragionamento.

Se il prodotto non deve mostrare o archiviare questo contenuto, verifica separatamente cosa espone il runtime, cosa conserva l’applicazione e cosa riceve l’utente. Non presumere che nascondere una stringa nell’interfaccia equivalga a rimuoverla dai log o dalle tracce. Queste proprietà dipendono dall’integrazione e richiedono verifiche specifiche.

Documenta la decisione con un rapporto di regressione

Un rapporto utile permette di ripetere l’esperimento e di capire perché è stata scelta una condizione. Includi le revisioni esatte del modello e del template, la configurazione di generazione, i prompt completi, l’insieme di attività e i criteri di valutazione. Riassumi i risultati per tipo di attività, non soltanto con una cifra aggregata. Conserva esempi rappresentativi di risposte corrette ed errori, gestendo i dati sensibili secondo le politiche del team.

Descrivi cosa è cambiato tra le condizioni e cosa è rimasto invariato. Annota anche le limitazioni: per esempio, se il servizio non espone la revisione dei pesi o se non è possibile controllare determinati parametri. Se i risultati non sono conclusivi, anche questa è una conclusione valida: puoi ampliare l’insieme, ripetere il test o mantenere la configurazione attuale mentre svolgi ulteriori verifiche. Evita di trasformare la mancanza di prove di regressione nella prova che non vi siano regressioni.

La raccomandazione operativa finale deve essere specifica: quale template viene approvato, per quali attività, con quale versione e con quali soglie. Se una variante funziona bene soltanto per un flusso, limita il suo impiego a quel flusso invece di presentarla come template universale per DeepSeek R1.

Criterio pratico: mantenere ciò che supera la prova dell’applicazione

La pratica di prompting più utile per un’applicazione basata su DeepSeek R1 è quella che migliora le attività senza indebolire i contratti di output né i meccanismi di sicurezza e recupero. Per scoprirlo, definisci una configurazione di riferimento, isola le modifiche, includi attività diverse, ripeti i test quando necessario e presenta risultati suddivisi per categoria. Un prefisso, la posizione di un’istruzione o l’assenza di un messaggio di sistema non dovrebbero essere accettati per abitudine né scartati per intuizione: i loro effetti vanno verificati in condizioni documentate.

Quando i risultati sono coerenti e rispettano le soglie stabilite, distribuisci la configurazione monitorando le metriche che hanno motivato la decisione. Se cambiano l’ambiente, i pesi, il template o le attività, ripeti le valutazioni pertinenti. In questo modo, le raccomandazioni ufficiali restano utili come ipotesi iniziali, mentre sono le evidenze raccolte nell’applicazione a determinare la configurazione finale.

Continua a esplorare

Correzioni e trasparenza

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