Quel consiglio su quale lingua è migliore per i codici AI? Cade a pezzi nel lavoro reale
Dan Luu ha riproposto la popolare affermazione secondo cui i linguaggi dinamici sono più economici per gli agenti di codifica. In due progetti di grandi dimensioni l'effetto è svanito e il secondo benchmark più citato si è rivelato non valido.
C’è un consiglio in giro secondo cui se vuoi che un agente di codifica AI sia economico ed efficace, dovresti scegliere un linguaggio compatto e tipizzato dinamicamente. Il riepilogo AI di Google lo ripete. Dan Luu, un ingegnere con una lunga esperienza nello smontare le affermazioni popolari, ha eseguito i propri test. Su qualsiasi cosa assomigli a un lavoro reale, l’effetto scompare.
L’affermazione originale proveniva da un benchmark che misurava il numero di token, i piccoli pezzi di testo che un modello legge e scrive e per i quali viene fatturato, e di diversi linguaggi necessari per risolvere i problemi di Rosetta Code. Ha rilevato un divario di 2,6 volte tra C, il peggiore, e Clojure, il migliore, e una vittoria ancora maggiore per il linguaggio array J con circa 70 token per soluzione. L’obiezione di Luu è schietta: un problema che puoi risolvere con 70 gettoni non è un problema. La maggior parte del lavoro è stampare la risposta.
Quindi ha costruito due test più difficili. Nella prima, agli agenti venivano fornite le specifiche di compressione zstd e veniva detto loro di implementare un decoder funzionante, senza accesso a Internet e senza poter vedere i test. Nella seconda, è stato loro consegnato il benchmark del convertitore di documenti Pandoc e hanno ottenuto un punteggio rispetto a test che non avevano mai visto. In entrambi i casi non è emerso alcun chiaro vincitore tra i linguaggi statici e quelli dinamici. A fronte di uno sforzo di ragionamento più elevato, diversi linguaggi statici sono risultati vincitori. I linguaggi oscuri e densi che sembravano così impressionanti nei problemi dei giocattoli si sono comportati male, il che si adatta a una semplice spiegazione: i laboratori di intelligenza artificiale dedicano i loro sforzi di formazione alle lingue che le persone usano effettivamente.
Cosa c’è dietro
La parte più utile dell’articolo è l’autopsia degli altri parametri di riferimento citati. Un test eseguiva un eseguibile su un percorso che non esisteva, quindi ogni esecuzione di Rust falliva. Una successiva esecuzione di Go ha “risolto” questo problema creando un collegamento simbolico al proprio binario, il che significava che ogni test successivo in ogni lingua eseguiva silenziosamente il programma Go. L’autore del benchmark ha concluso che Rust ha difficoltà perché è un linguaggio difficile. Con un punteggio adeguato, Rust ottiene un voto perfetto. Altri due test hanno avuto un errore di copia-incolla che li ha fatti superare indipendentemente da ciò che ha fatto il codice.
Luu è attento anche al proprio lavoro. Nota di aver corretto oltre un centinaio di bug di installazione e si aspetta che ne rimangano altri, e si rifiuta di fare affermazioni sulle singole lingue di due attività. L’unico modello che seguirà è debole ma coerente: i linguaggi più popolari tendono a produrre risultati più corretti ed economici.
Cosa significa per te: Non cambiare lingua perché una tabella dice che lì un agente sarebbe più economico. Attieniti a qualcosa di tradizionale e ben supportato. Più in generale, questa è una buona lezione su come i benchmark dell’intelligenza artificiale falliscono: un risultato sorprendente su piccoli problemi di solito smette di essere sorprendente nel momento in cui il problema diventa abbastanza grande da avere importanza. Quando ne vedi uno, chiedi quanto sono stati difficili i compiti.
Fonti
Il creatore di Redis ha realizzato un modello video cinese su un Mac. Gli europei non hanno la licenza per usarlo
Salvatore Sanfilippo ha pubblicato h3.c, un motore C e Metal che esegue MiniMax H3 in modo nativo su Apple Silicon. La licenza stessa del modello esclude UE, Regno Unito, Stati Uniti e Corea del Sud dall'implementazione locale.
