Valutare un modello su leaderboard generiche ti dice quanto sia bravo a gestire quiz e test standardizzati. Non ti dice quasi nulla su come ragionerà di fronte ai problemi complessi e vincolati che i tuoi sistemi di produzione affrontano realmente. Prima di distribuire qualsiasi modello linguistico di grandi dimensioni agli utenti, hai bisogno di un framework di test che metta alla prova i pattern cognitivi specifici richiesti dalla tua applicazione. I benchmark di ragionamento sono il luogo in cui i modelli si distinguono dai semplici chatbot.

Questa guida ti accompagnerà nella creazione di un benchmark di ragionamento mirato partendo da zero. Metterai a confronto tre architetture distinte: DeepSeek R1 671B MoE, Llama 3.3 70B e Qwen 3 32B. Invece di assemblare cluster di GPU, eseguirai tutti e tre tramite Oxlo.ai. Per la valutazione, utilizzerai Kimi K2.6 come giudice per assegnare un punteggio agli output in base alla chiarezza del ragionamento, alla correttezza e alla qualità del codice.

Perché il ragionamento è la prima cosa a cedere

I fallimenti in produzione raramente si manifestano come errori grammaticali o rifiuti. Si presentano come sottili errori logici. Un modello potrebbe generare una prosa sicura di sé pur fraintendendo un vincolo, saltando un passaggio o cambiando silenziosamente una variabile a metà processo. I benchmark pubblici spesso privilegiano l'ampiezza rispetto alla profondità, quindi un modello può ottenere punteggi elevati senza mai risolvere un problema combinatorio complesso.

Un benchmark mirato affronta il problema direttamente. Assegna a ogni modello lo stesso compito di ottimizzazione vincolata, richiede una catena di pensiero (chain of thought) tracciabile e misura se la soluzione generata soddisfi effettivamente le regole. Se un modello non è in grado di ragionare in modo coerente sulla matematica discreta, non saprà gestire in modo affidabile nemmeno l'allocazione dell'inventario, il motore di pianificazione o il router delle risorse.

I Modelli e la Piattaforma

DeepSeek R1 671B MoE utilizza un design mixture-of-experts. Solo una frazione dei suoi 671 miliardi di parametri si attiva per ogni singolo token, il che modifica la curva rapporto costo-prestazioni e, a volte, la struttura del suo ragionamento. Llama 3.3 70B è un modello denso, mentre Qwen 3 32B opera su una scala più ridotta con forti capacità multilingue e di coding. Confrontare questi tre modelli ti permetterà di capire se la qualità del ragionamento segue il numero totale di parametri, il numero di parametri attivi o la metodologia di addestramento.

Oxlo.ai ospita questi modelli dietro un'API unificata. Non dovrai gestire l'infrastruttura di inferenza né lottare con diversi accordi con i fornitori. La piattaforma utilizza inoltre un modello di prezzo per richiesta anziché per token. Un prompt di sistema di duemila parole costa esattamente quanto una breve riga di testo. Questo dettaglio è più importante di quanto sembri: significa che puoi scrivere istruzioni esaustive, includere requisiti di formattazione dettagliati ed inserire esempi few-shot senza vedere i costi dei token di input gonfiarsi. Paghi per la chiamata, non per la verbosità.

Avrai bisogno di Python 3.10 o versioni successive, della libreria Python di OpenAI e di una chiave API di Oxlo.ai.

Passaggio 1: Connettersi all'Endpoint

Poiché Oxlo.ai espone un'API compatibile con OpenAI, l'integrazione è semplice. Punta l'SDK di OpenAI all'URL base di Oxlo, inserisci la tua chiave API e verifica la connessione con una richiesta leggera a DeepSeek R1. Non saltare il controllo di integrità (sanity check). Conferma la latenza, verifica che l'identificativo del modello venga riconosciuto e assicurati che il tuo ambiente possa gestire lo streaming o il buffering del formato di risposta che intendi memorizzare. Una volta che l'handshake funziona, avrai un unico client in grado di indirizzarsi a tutti e tre i modelli cambiando una singola stringa.

Passaggio 2: Progettare il Task

Scegli un problema che richieda una logica passo dopo passo e che abbia una risposta oggettivamente misurabile. Il bin-packing funziona eccezionalmente bene. È un problema NP-hard, il che significa che le euristiche greedy falliscono in modi prevedibili e costringe il modello a monitorare più vincoli simultaneamente. Oggetti di dimensioni variabili devono essere inseriti in contenitori di capacità fissa senza superarne i limiti.

Struttura il prompt in modo che il modello debba fare due cose: descrivere il proprio processo di ragionamento e poi fornire codice Python funzionante che risolva l'istanza. Usa un system prompt che richieda esplicitamente al modello di mostrare la sua catena di pensiero (chain-of-thought) prima di scrivere qualsiasi codice. Questo è particolarmente importante per DeepSeek R1, che è ottimizzato per tracce di ragionamento estese. Vuoi capire se il modello sta effettivamente elaborando i controlli di capacità o se sta solo effettuando un pattern-matching basato sui dati di addestramento. Un buon task deve essere sufficientemente avversariale da far fallire le risposte basate su template.

Passaggio 3: Eseguire il Benchmark

Invia lo stesso prompt a DeepSeek R1, Llama 3.3 70B e Qwen 3 32B. Cattura le risposte testuali complete, non solo i blocchi di codice finali. Memorizzale con timestamp e identificativi del modello. Poiché Oxlo.ai fattura per richiesta, non è necessario troncare il prompt o rimuovere le istruzioni di chiarimento per risparmiare denaro. Puoi permetterti di essere preciso. Questa stabilità ti consente di iterare sul design del prompt senza l'ansia del costo, il che porta a esperimenti più puliti e risultati più riproducibili.

Esegui ogni modello più volte se il tuo budget lo consente. I modelli di ragionamento possono variare tra generazioni stocastiche, e vorrai sapere se un punteggio elevato rappresenta una competenza costante o un campione fortunato.

Step 4: Valuta con un LLM Judge

La valutazione manuale non è scalabile, ma le rubriche numeriche da sole trascurano le sfumature. La via di mezzo è un LLM judge. In questo caso, utilizzerai Kimi K2.6. Forniscigli il problema originale, la rubrica e ogni risposta candidata. Chiedigli di valutare tre dimensioni specifiche:

  • Chiarezza del ragionamento: La spiegazione segue effettivamente la logica o è superficiale?
  • Correttezza: La soluzione proposta soddisfa tutti i vincoli stabiliti?
  • Qualità del codice: Il codice Python è pulito, eseguibile e privo di bug evidenti?

Istruisci il judge a restituire i punteggi in formato JSON. L'output strutturato rende banale confrontare i risultati (diff), tracciare tendenze e alimentare l'automazione a valle. Mantieni il prompt del judge rigoroso. Se fornisci un'istruzione vaga come "valuta la risposta", otterrai risultati vaghi. Invece, definisci cosa conta come una soluzione corretta di bin-packing. Le capacità non devono essere superate. Ogni elemento deve essere assegnato. Il codice deve essere sintatticamente valido. Più i tuoi criteri sono concreti, più i tuoi voti diventeranno affidabili.

Controlla sempre a campione il judge. Se Kimi K2.6 sovrastima costantemente un modello a causa di una perfezione superficiale, il tuo benchmark è compromesso. Un piccolo livello di audit umano previene una valutazione di tipo garbage-in-garbage-out.

Step 5: Crea il report

Aggrega i punteggi JSON e accoppiali con estratti degli output grezzi del modello. Inserisci tutto in un unico file all'interno del tuo repository. Quando aggiorni una versione del modello o modifichi il prompt, il diff nella tua pull request mostrerà esattamente come è cambiato il comportamento. Un benchmark ben mantenuto diventa documentazione vivente. Giustifica perché la tua pipeline di produzione utilizza un modello rispetto a un altro e intercetta regressioni silenziose prima che raggiungano gli utenti.

Struttura il report in modo che un collega possa leggerlo senza eseguire il codice. Includi la dichiarazione del problema, il template del prompt, i punteggi e citazioni rappresentative della traccia di ragionamento di ogni modello. La trasparenza è fondamentale. Se DeepSeek R1 ottiene un punteggio alto ma allucina un vincolo, vorrai che ciò sia visibile nell'estratto di testo, non sepolto in una media.

Automazione della pipeline

Un benchmark che vive solo sul tuo laptop viene dimenticato entro una settimana. Spostalo in un job CI notturno. Ogni notte, l'harness si avvia, interroga le versioni attuali dei modelli su Oxlo.ai, esegue il task di bin-packing, valuta gli output e effettua il commit dei risultati. Se un aggiornamento del modello causa un calo di dieci punti nella correttezza, lo saprai prima dei tuoi utenti.

Una volta che l'harness principale è stabile, estendilo. Testa le varianti a lungo contesto riempiendo il prompt con documenti irrilevanti, posizionando poi la domanda di bin-packing alla fine. Le ampie finestre di contesto sono inutili se il ragionamento crolla sotto il rumore. Scopri quali modelli mantengono la disciplina logica quando il segnale è sepolto in diecimila token di distrazione.