Un modello 28 volte più economico ha rilevato tre quarti dei bug e ha mancato la metà di quelli relativi alla sicurezza
Entelligence ha eseguito GPT-5.6 Luna e GPT-6 Astra sulle stesse 50 richieste pull da progetti open source reali. Il modello economico ha resistito agli errori comuni ed è crollato in termini di sicurezza, che è una forma utile da conoscere.
Questa settimana Entelligence ha pubblicato un confronto che risponde a una domanda con cui molti team si stanno tranquillamente confrontando: quanto si perde effettivamente utilizzando il modello economico? Hanno preso 50 richieste pull reali, le modifiche al codice proposte che gli sviluppatori inviano per la revisione, da progetti tra cui Sentry, Discourse, Keycloak, Cal.com e Grafana. Quindi li hanno inviati ciascuno al GPT-5.6 Luna e al GPT-6 Astra con istruzioni identiche e hanno contato i difetti autentici riscontrati in ciascuno.
Astra ha trovato 92 bug verificati, Luna ne ha trovati 69. Il costo per recensione è stato di 0,113 dollari per Astra e 0,0041 per Luna, una differenza di circa 28 volte, e Luna è stata anche più veloce, 23 secondi contro 36. Preso come titolo sembra una vittoria facile per il modello economico. La ripartizione dice il contrario. Sui dati ordinari e sugli errori logici i due erano vicini. Sulla concorrenza, la classe di bug in cui due cose accadono contemporaneamente e si sovrappongono, Luna è scivolata. Per quanto riguarda i difetti di sicurezza, è caduto: 9 su 24 rilevati, contro i 19 di Astra. La precisione, ovvero quanto spesso un problema segnalato era reale piuttosto che rumore, era del 74% per Luna e del 96% per Astra, quindi anche il recensore economico spreca più attenzione. Il team ha verificato i risultati facendo giudicare in modo indipendente altri due modelli e chiedendo loro di concordare, il che è un metodo ragionevole e anche, per essere onesti, circolare: modelli di classificazione dei modelli.
Cosa c’è dietro tutto questo?
Il modello si adatta a ciò che sappiamo su come differiscono i modelli piccoli e grandi. Trovare un controllo nullo mancante è vicino al pattern match e i modelli piccoli sono bravi nel pattern match. Trovare un difetto di sicurezza di solito significa tenere a mente diverse cose contemporaneamente, rintracciare la provenienza dei dati, immaginare un aggressore e ragionare su cosa succede due passaggi dopo. Questa è la capacità che si riduce per prima quando un modello diventa più economico. Quindi la domanda giusta non è “il modello economico è abbastanza buono?” ma “abbastanza bravo in cosa?”, e la risposta qui ha una forma chiara: sì per la correttezza quotidiana, no per tutto ciò in cui sbagliare è costoso.
Che cosa significa per te: Se rivedi il codice con l’intelligenza artificiale, la configurazione sensata è entrambe le cose anziché una delle due. Esegui il modello economico su tutto come primo passaggio, poiché a quattro decimi di centesimo a revisione non c’è motivo di non farlo, e riserva quello costoso per modifiche che riguardano l’autenticazione, le autorizzazioni, i pagamenti o qualsiasi cosa gestisca dati di estranei. Se non si scrive codice, la lezione trasferibile vale più del benchmark: i modelli economici non sono uniformemente peggiori, sono peggiori in luoghi specifici, e quei luoghi tendono ad essere quelli che necessitano di diversi passaggi di attento ragionamento. Questa è una cosa utile da tenere a mente ogni volta che scegli tra il livello veloce e gratuito e quello lento e a pagamento per il tuo lavoro.
Fonti
DeepMind ha dato a 100 agenti gli stessi compiti di matematica e si sono divisi in imbroglioni e spie
Un agente trovò un buco nel sistema di valutazione e nel giro di 27 minuti le prove false avevano spazzato via ogni problema rimasto. Tutti i 100 agenti hanno funzionato con pesi di modello identici, ma il 14% ha imbrogliato, il 24% ha segnalato bug e la maggior parte non se ne è mai accorta.
