I benchmark dei Large Language Models raccontano una storia chiara: i modelli chiusi come Claude di Anthropic dominano sistematicamente quelli aperti. Ogni volta che un punteggio sorprende, la spiegazione più diffusa chiama in causa architetture proprietarie, pipeline di training raffinate e tecniche di machine learning che i vendor custodiscono gelosamente. Ma questa narrativa ha una falla: il confronto non è mai tra due modelli nudi.

L’analisi pubblicata su Reddit dall’utente u/p-e-w mette il dito su un nodo trascurato. Quando confrontiamo l’inference di un LLM aperto con la risposta dell’API di Claude, non stiamo valutando solo un singolo modello. Riceviamo l’output di un prodotto completo, che Anthropic può arricchire con una serie di accorgimenti invisibili all’esterno. I trace di ragionamento sono censurati, lo storico della conversazione non è accessibile per intero. L’azienda ha la possibilità di operare in modo opaco, inserendo componenti che spostano sensibilmente le performance.

Cosa può nascondere un’API chiusa

La lista delle tecniche che un provider può applicare dietro le quinte è lunga e tecnicamente plausibile. Iniezione di conoscenza via Retrieval-Augmented Generation, ad esempio per attingere a documentazione software aggiornata senza che il modello di base la contenga. Pre-elaborazione del prompt, con riscritture automatiche che eliminano ambiguità prima di arrivare alla rete neurale principale. System prompt modificati in modo dinamico a seconda del contesto, in grado di forzare comportamenti più accurati. Chiamate interne a strumenti – in stile function calling – che l’utente non vede, ma che risolvono sottoproblemi con modelli specializzati. C’è persino la possibilità di orchestrare una “MoE a nascondino” (l’autore la chiama “clown-car MoE”), dove il servizio smista richieste a modelli esperti diversi da quello principale, confezionando il tutto sotto il marchio unico “Claude”.

Nessuna di queste ipotesi è verificabile dall’esterno, e tutte hanno il potenziale per migliorare radicalmente l’accuratezza apparente. Il risultato è un paragone tra mele e pere: da un lato il singolo modello open, dall’altro un sistema composito che sfrutta componenti ausiliari.

Trasparenza e sovranità dell’inference

Il dibattito tocca un nervo scoperto per chi valuta deployment on-premise. Quando si esegue un LLM open in locale, si ha il controllo completo della pipeline: si conosce il modello esatto, la quantization adottata, il prompt così come arriva al motore di inference. Le metriche misurate in un ambiente self-hosted fotografano la performance reale del modello, senza trucchi. Al contrario, adottare un’API chiusa significa accettare una scatola nera, dove i punteggi dei benchmark potrebbero rappresentare un pacchetto ottimizzato di cui non si conoscono i confini.

Per chi lavora in contesti regolamentati o che pongono la sovranità dei dati al centro, questa opacità porta con sé anche un rischio di “lock-in percettivo”: si può essere indotti a credere che il fornitore abbia un vantaggio di ricerca incolmabile, mentre parte della differenza potrebbe dipendere semplicemente da un’orchestrazione più sofisticata e non dal modello fondamentale.

Cosa cambia nel calcolo del Total Cost of Ownership

La trasparenza dei sistemi aperti non è solo una questione di principio. Valutare il TCO di uno stack on-premise richiede un confronto onesto. Se il competitor cloud fa leva su componenti nascosti per alzare i benchmark, l’analisi comparativa rischia di trascurare soluzioni open che, replicate su una base modelli equivalente e con analoghe integrazioni, reggerebbero il confronto. In altre parole, il costo di sviluppare internamente un’infrastruttura di retrieval o di routing tra modelli specializzati potrebbe essere giustificato se il gap “nudo” tra LLM fosse già ridotto.

La tesi emersa dalla discussione non prova che Claude nasconda effettivamente questi meccanismi. Suggerisce però una cautela metodologica: senza accesso alla catena di elaborazione completa, ogni vantaggio misurato va preso con beneficio di inventario.

Una prospettiva per l’ecosistema open

La possibilità che i modelli chiusi non godano di un distacco architetturale incolmabile è una buona notizia per l’ecosistema on-premise. Accelera la convergenza verso stack interamente locali, dove la differenza la fanno l’integrazione con strumenti interni, la qualità dei dati aziendali e la possibilità di eseguire fine-tuning mirato. Piuttosto che rincorrere un’API irraggiungibile, le organizzazioni possono concentrarsi su ciò che rende l’inference auto-ospitata un asset strategico: controllo, auditabilità e assenza di dipendenze esterne.

Approfondire i trade-off tra API opache e LLM self-hosted è uno dei compiti centrali per chi progetta infrastrutture AI a lungo termine. AI-RADAR esplora questi temi offrendo framework analitici su /llm-onpremise per valutare scenari di deployment che mettono la trasparenza al primo posto.