AIM Enterprise: benchmark enterprise agentico

Le imprese usano gli LLM ogni giorno per le loro attività ordinarie. Per trovare gli LLM più convenienti, abbiamo progettato AIM Enterprise, un benchmark enterprise agentico, in cui abbiamo utilizzato 69 attività aziendali reali tra strategia, marketing, HR, vendite e operations.

Risultati del benchmark

• Claude Opus 5 (66.4) e GPT 5.6 Sol (62.4) hanno chiuso con più di 7 punti di vantaggio sul terzo posto e hanno mantenuto i primi due posti in tutti i 4.000 ricalcoli dei punteggi su riselezioni casuali dei task.
• Opus 5 ha vinto 43 dei 69 task e Sol ne ha vinti 13. Nessun altro model ha vinto più di quattro.
• Opus 5 ha anche ottenuto la media più alta nei 17 task più difficili, 66.2 contro 62.3 per Sol.
• I sei model successivi hanno ottenuto punteggi tra 51.4 e 55.2. È una differenza inferiore a quella che 69 task riescono a distinguere, quindi il loro ordine cambia con la selezione dei task.

Costo e punteggio

• GPT 5.6 Luna ha ottenuto 55.2 a $0,040 per task. Sono 7 punti in meno rispetto al miglior model nel grafico a un diciassettesimo del suo costo.
• Tra gli 11 model a pagamento, il costo per task e il punteggio correlano a 0.71.
• Considerando tutti i 16 setup, la correlazione tra tempo per task e punteggio è 0.55. I quattro più rapidi erano quattro dei cinque punteggi più bassi e Inkling Small ha completato un task in 49 secondi, classificandosi penultimo.
• Kimi K3 a $0,652 e Qwen 3.8 Max a $0,628 costano all'incirca quanto GPT 5.6 Sol a $0,670 e ottengono punteggi inferiori di 8 e 11 punti.

Disaccordo tra i giudici

Due judge model hanno valutato ogni file e spesso non erano d'accordo. In circa un terzo dei punteggi individuali, i due si sono discostati di più di un quarto della scala e nessuno ha rivisto quelle righe.

Erano d'accordo sugli estremi ma non sul centro. Entrambi hanno collocato Opus 5 e GPT 5.6 Sol sopra tutti gli altri, ma 11 dei 16 setup finiscono in una posizione diversa a seconda del model di punteggio che si segue.

I due inoltre non erano d'accordo su quale leader venisse per primo, collocando ciascuno in cima il model della propria azienda. L'ordine pubblicato combina entrambe le classifiche.

Il benchmark AIM Marketing

Lo stesso metodo viene applicato al lavoro di marketing: individuare offerte che un concorrente pubblica e che AIMultiple non ha, creare un elenco di account più adatti e produrre una presentazione di vendita personalizzata. Ogni task riceve un punteggio da 0 a 100 e il punteggio complessivo è la media dei tre. Un audit della reputazione del sito web viene eseguito in parallelo e viene riportato su assi propri, perché non ha un punteggio massimo fisso.

Risultati completi: il benchmark di marketing agentico.

Il benchmark AIM IT

Dodici models hanno eseguito due volte un task di progettazione di benchmark, inventando un benchmark, costruendolo e facendo girare quattro model attraverso di esso. Nessuno dei 24 tentativi ha superato tutti i criteri e sei dei controlli della griglia non sono stati superati da nessuno di essi. Claude Opus 5 ha primeggiato nel text-to-SQL con 78.2 e Kimi K3 nel tool calling con 74.3.

Risultati completi: gli LLM possono progettare un benchmark.

Il benchmark AIM VC

A tredici model presenti nel grafico è stato chiesto di indicare i clienti di un'azienda con prove datate, in tre aziende target. Claude Opus 5 ha ottenuto 89.1 su 100 e Claude Fable 5 85.0, e questi due sono stati gli unici a rimanere sopra 76 in tutti e tre i target valutati. La maggior parte degli altri ha ottenuto il punteggio più basso proprio sul target i cui clienti compaiono nella pubblicità dei podcast anziché sulle pagine indicizzate.

Risultati completi: il benchmark sull'elenco clienti.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Metodologia

I 69 task sono stati scritti dal fondatore di AIMultiple sulla base di decisioni aziendali reali e mappati sugli identificatori APQC Process Classification Framework.¹

Coprono strategia (16 task), marketing (15), HR (7), vendite (6), operations (5), IT e finanza (4 ciascuno) e sette aree minori. Ogni task indica il file che richiede: un results.csv con un elenco fisso di colonne, in genere 10 righe e 8 colonne, con una regola esplicita per ogni campo intero.

Come sono stati eseguiti i model

Tredici model hanno girato in 16 setup, dove un setup è un model sotto un programma agente. Undici hanno girato su opencode 1.15.13 tramite OpenRouter. Gli altri hanno girato sui programmi agenti forniti dai rispettivi vendor, Claude Code e Codex, fatturati sugli abbonamenti.

Ogni setup ha ricevuto lo stesso prompt congelato, accesso web in tempo reale tramite una scraping API e un limite di due ore. I prompt non sono mai stati calibrati per singolo model e le rubriche di valutazione non hanno mai raggiunto la macchina che eseguiva i task.

Nessuno ha scelto un livello di ragionamento. Ogni setup ha girato con il default del proprio programma agente, e i default non corrispondono a un unico livello:

Claude Code 2.1.220 viene fornito con livello alto per entrambi i model che ha eseguito e Codex ha registrato alto in ogni esecuzione. opencode non sceglie nulla e lascia il livello al provider, quindi quegli otto restano al default di ciascun model.

Un default di ragionamento più alto non corrispondeva a un punteggio più alto. I due model che di default superano il livello alto, Kimi K3 a livello massimo e Qwen 3.8 Max a livello molto alto, sono arrivati 4 e 8 su 13. I tre model che hanno girato sia con una CLI del vendor sia con opencode restano entro 0.83 punti da se stessi.

Ogni dato di costo qui è ricalcolato dai tokens effettivamente movimentati da un'esecuzione, in base ai prezzi di listino OpenRouter letti il 19 agosto 2026, con input in cache fatturato alla tariffa cache.

La fatturazione propria dei programmi agente non sarebbe confrontabile. opencode fattura con il proprio listino prezzi in bundle, e le esecuzioni di Claude Code e Codex vengono fatturate sugli abbonamenti, che non registrano alcun costo per singola esecuzione. I due setup di Claude Code non hanno conservato alcun registro d'uso e non possono essere prezzati affatto.

Ciò ha prodotto 1.104 file, uno per setup per task. Sei setup opencode hanno mancato 25 esecuzioni al primo passaggio perché la ricerca dei file dell'agente percorreva percorsi che il suo stesso sandbox poi si rifiutava di aprire, bloccando l'esecuzione. Rilanciando quei 25 in una directory isolata sono stati recuperati tutti, quindi la consegna viene riportata sia come tasso al primo passaggio sia come tasso finale. Ogni task è stato eseguito una volta e valutato una volta. Un model che non produceva alcun file veniva eseguito di nuovo, ma nessun file è mai stato valutato due volte, quindi nessun risultato deriva dalla scelta del migliore tra due tentativi.

Un settantesimo task, un playbook per la gestione delle richieste, è escluso da tutti i dati qui. Il suo file di input mancava al momento dell'esecuzione e solo un setup ha mai prodotto un file per esso. Contando ogni riavvio, 83 delle 759 esecuzioni con registri d'uso hanno richiesto più di un tentativo.

Come funzionano i controlli e i giudici

I controlli deterministici vengono eseguiti per primi e nessun giudice vede un file che non li supera: set di colonne e conteggio delle righe, parsing RFC 4180,²

formattazione degli interi, nessuna cella vuota, nessuna riga duplicata e ordinamento dove il task lo richiede.

Un file che non supera i controlli ottiene zero anziché essere scartato. DeepSeek V4 Flash ha fallito in 6 dei suoi 69 file, Inkling Small in 2, MiniMax M3 e GPT 5.6 Terra in uno ciascuno. Eliminando ogni task in cui un setup qualsiasi ha fallito, i due leader restano al loro posto.

I 1.094 file che hanno superato i controlli sono andati a due giudici: GPT 5.6 Sol tramite la CLI di Codex e Claude Opus 5 tramite la CLI di Claude Code, entrambi con livello alto di ragionamento e accesso web in tempo reale.

Ogni colonna del file va al proprio subagente, che vede le risposte di quella colonna di ogni model e nient'altro, sotto ID di riga anonimi mescolati separatamente per ciascun giudice. Il giudice classifica quelle risposte tra loro e non può considerare uguali due risposte. Le due classifiche vengono poi combinate sommando la posizione di ogni risposta presso ciascun giudice. Ciò ha prodotto 90.530 punteggi.

Misurando con i nomi dei model visibili, Sol ha classificato le risposte di GPT 8.4 percentili sopra il punto in cui le ha classificate Opus, e Opus ha classificato le risposte di Anthropic 4.9 percentili sopra il punto in cui le ha classificate Sol. L'anonimizzazione non elimina l'effetto. Le esecuzioni dietro questa leaderboard sono state anonimizzate e ogni giudice ha comunque messo al primo posto il setup della propria azienda.

Come funziona il punteggio

Il punteggio di un model è la somma delle medie delle sue colonne, riscalata in modo che il totale più alto possibile sia 100. Quel tetto dipende da quanti model hanno superato i controlli, ed è per questo che questi punteggi sono confrontabili solo all'interno di questo benchmark e non altrove.

Per verificare quanto la classifica dipenda dalla selezione dei task, abbiamo ricalcolato i punteggi della leaderboard 4.000 volte, ogni volta su una riselezione casuale dei 69 task. Questo misura solo la sensibilità ai task. Non misura quanto una nuova esecuzione dello stesso task sposterebbe un punteggio, perché nessun task è stato valutato due volte.

Il quartile più difficile è costituito dai 17 task con il punteggio medio più basso in tutti i 16 setup. Questa regola è stata fissata prima che venisse calcolata la posizione di qualsiasi model su quei task.

Dodici dei 13 model compaiono anche nei benchmark precedenti. I loro punteggi non sono trasferibili, perché ogni benchmark definisce la propria scala.

Ogni punteggio qui è una posizione relativa rispetto ai model contro cui è stato eseguito, quindi eliminare un setup comporterebbe il ricalcolo di tutti gli altri anziché rimuovere una barra. Qwen 3.8 Max partecipa solo a questo benchmark e resta nel grafico per questo motivo.

FAQ

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{kalelioglu2026,
  author = {Kalelioğlu, Berk},
  title  = {{AIM Enterprise: benchmark enterprise agentico}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-enterprise}},
  note   = {AIMultiple. Consultato il 24 Agosto 2026}
}

Collegamenti di riferimento

1.

Process Frameworks | APQC

2.

RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files | RFC Editor

Berk Kalelioğlu

Ricercatore di IA

Segui

Berk è un ricercatore di IA presso il team benchmark di AIMultiple, concentrandosi su IA agentica, apprendimento automatico e modelli linguistici grandi e piccoli (LLM e SLM).

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento