Benchmark di LLM piccoli e tool-calling

Un recente benchmark ha messo alla prova 21 modelli linguistici di piccole dimensioni (LLM) per valutare la loro capacità di utilizzare strumenti esterni. L'attenzione si è concentrata sulla capacità dei modelli di determinare quando fosse appropriato chiamare uno strumento, e non solo sulla mera capacità di farlo.

Risultati principali

Quattro modelli hanno raggiunto il primo posto con un punteggio di 0.880:

  • lfm2.5:1.2b
  • qwen3:0.6b
  • qwen3:4b
  • phi4-mini:3.8b

La sorpresa più grande è stata l'ottima performance di lfm2.5:1.2b, un modello ibrido state-space da 1.2 miliardi di parametri, che ha registrato anche la latenza più bassa tra i modelli di punta (circa 1.5 secondi).

È interessante notare che, nella famiglia Qwen3, la classifica non è monotona: la versione da 0.6B ha superato quella da 4B e da 1.7B. La versione da 1.7B sembra trovarsi in una "valle di capacità", sufficientemente aggressiva da chiamare strumenti, ma non abbastanza da discernere quando non farlo.

L'importanza del parsing

L'analisi ha evidenziato che la modalità di interpretazione delle chiamate agli strumenti è cruciale tanto quanto il test stesso. Cinque modelli hanno richiesto parser personalizzati a causa di formati non standard:

  • lfm2.5: notazione a parentesi
  • jan-v3: JSON grezzo
  • gemma3: sintassi di funzione all'interno dei tag
  • deepseek-r1: chiamate di funzione semplici
  • smollm3: omissione occasionale dei tag

La correzione del parser non sempre migliora le prestazioni di un modello. Ad esempio, lfm2.5 ha visto un miglioramento significativo (da 0.640 a 0.880) dopo la correzione del parser, mentre gemma3 ha subito un calo (da 0.600 a 0.550). Questo dimostra che benchmark che ignorano il formato possono sovrastimare o sottostimare le capacità dei modelli.

Considerazioni finali

I risultati suggeriscono che agenti locali di tool-calling possono operare efficacemente su hardware standard. Il numero di parametri non è un indicatore affidabile delle prestazioni, e un comportamento conservativo (evitare di agire su prompt incerti) può portare a risultati migliori. Per chi valuta deployment on-premise, esistono trade-off da considerare attentamente; AI-RADAR offre framework analitici su /llm-onpremise per supportare queste valutazioni.