Gli agenti di frontiera hanno completato il 30 percento di un flusso di lavoro di ricerca. Questo è il numero.

Stanford ha un nuovo benchmark chiamato Terminal-Bench-Science 0.1, e il risultato principale è molto meno entusiasmante di quanto lo sia di solito il marketing attorno agli agenti. Il benchmark ha messo 70 flussi di lavoro di ricerca scritti da esperti davanti ad agenti di frontiera. Il migliore ne ha completato il 30 percento.

Il 30 percento è il numero da tenere a mente. Non si legge né come un fallimento né come un trionfo. È una misurazione onesta di dove si trova la tecnologia, pubblicata da persone che hanno scritto i compiti a mano.

Cosa testa davvero il benchmark

I compiti sono flussi di lavoro scientifici, scritti da esperti di dominio, e gli agenti vengono eseguiti in un terminale. Questa scelta conta. Un terminale è un ambiente di lavoro in cui un compito è reale: devi effettivamente installare la dipendenza, scrivere il file, eseguire l'analisi e controllare l'output. Non c'è credito parziale per aver descritto l'approccio giusto. Il comando o funziona o non funziona.

I flussi di lavoro sono tratti dalla pratica di ricerca, che è un obiettivo molto più disordinato di un compito di programmazione con una suite di test ordinata. Un benchmark di programmazione di solito ha una risposta corretta definita, quindi può essere valutato automaticamente. Il lavoro di ricerca spesso non ce l'ha, ed è per questo che costruire un benchmark come questo ha richiesto che fossero esperti a scrivere i compiti invece di prelevarli da un repository.

Perché il 30 percento è l'inquadramento giusto

I benchmark tendono a essere letti come promosso o bocciato. Un modello che ottiene 90 in un benchmark di programmazione viene considerato quasi risolto. Un modello che completa il 30 percento dei flussi di lavoro di ricerca può, nello stesso spirito, essere letto come fallimentare la maggior parte delle volte.

Questa lettura manca lo scopo del numero. Un completamento del 30 percento su compiti scritti a mano da esperti significa che gli agenti possono gestire il terzo di routine del lavoro di ricerca: configurare ambienti, eseguire pipeline consolidate, pulire dati, produrre output standard. L'altro 70 percento è dove il compito richiede un giudizio che il flusso di lavoro non ha esplicitato, o dove un passaggio si rompe in un modo che richiede a un umano di decidere cosa fare dopo.

Questa è una suddivisione utile. Dice a un laboratorio dove indirizzare un agente oggi, e dice a chi costruisce strumenti dove si trova il divario.

Il terminale è la parte interessante

Eseguire gli agenti in un terminale è una scelta deliberata per testarli dove avviene il lavoro. Il software di ricerca è in gran parte software da riga di comando. Un modello che sa solo usare una finestra di chat non aiuta un laboratorio. Un modello che sa stare a una shell, leggere la documentazione, installare una toolchain e riprendersi quando una build fallisce è una categoria diversa di utilità.

È anche il luogo in cui le modalità di fallimento sono più visibili. Un terminale non nasconde un errore. Quando un comando restituisce un messaggio ambiguo o uno script si completa a metà, l'agente deve decidere se riprovare, cambiare approccio o fermarsi. Quel punto decisionale è dove si perde la maggior parte del 70 percento, ed è esattamente il tipo di cosa che un benchmark di programmazione con una suite di test pulita non farà mai emergere.

In cosa questo differisce dai benchmark di programmazione

Il confronto ovvio è con i benchmark di programmazione, che sono diventati il modo standard per pubblicizzare i progressi degli agenti. Un benchmark di programmazione di solito arriva con un repository e una suite di test, quindi la risposta corretta è definita e il punteggio è automatico. Questo lo rende economico da eseguire e facile da confrontare, ed è per questo che quei numeri dominano la conversazione.

I flussi di lavoro di ricerca resistono a questo trattamento. Spesso non c'è un singolo output corretto, e la qualità di un risultato dipende dal giudizio su cosa misurare e come. Ecco perché i compiti qui sono stati scritti da esperti invece che raschiati da un repository, e perché il benchmark riporta il completamento invece di un tasso di superamento dei test.

Lo scambio è copertura in cambio di realismo. Un benchmark di programmazione può essere eseguito migliaia di volte al giorno e produrre un numero preciso. Un benchmark di flussi di lavoro è più lento e più rumoroso, ma testa l'ambiente in cui avviene davvero una gran parte del lavoro tecnico. Entrambi sono utili, e solo uno dei due era ampiamente disponibile prima.

Perché il numero è misurato in questo modo

Il completamento è una metrica grossolana, e gli autori l'hanno scelta di proposito. Un flusso di lavoro o finisce o non finisce, e questo è un fatto che un osservatore esterno può verificare senza giudicare la qualità del risultato. L'eleganza non viene valutata. La correttezza non viene discussa. L'agente o ha prodotto l'output richiesto dal flusso di lavoro o si è fermato prima.

Questa grossolanità è il punto. I benchmark che cercano di valutare la qualità su compiti di ricerca aperti tendono a ridursi al gusto dell'autore del benchmark. Valutando il completamento, questo sacrifica la sfumatura in favore della riproducibilità. Due laboratori che eseguono lo stesso flusso di lavoro ottengono la stessa risposta, ed è questo che rende un numero degno di essere citato.

Il costo è che non riesce a distinguere un agente che ha quasi finito da uno che ha fallito immediatamente. Entrambi contano come fallimenti. Questo è un limite, e una versione futura potrebbe affrontarlo, ma un numero grossolano su cui tutti concordano batte un numero fine di cui nessuno si fida.

Cosa dice il risultato sul lavoro scientifico

Il benchmark è una risposta silenziosa a un'affermazione rumorosa, cioè che gli agenti presto faranno ricerca. Ciò che mostra è che gli agenti possono eseguire ricerca, nel senso che possono eseguire una procedura che un umano ha già messo a punto, in una quota crescente di passaggi di routine. Non possono ancora fare la parte in cui la procedura è sconosciuta e qualcuno deve inventarla.

Questo divario non è un piccolo dettaglio ingegneristico. Il lavoro di routine occupa una gran parte del tempo di uno scienziato, e automatizzarlo fa risparmiare denaro e ore reali. Inoltre non è la parte che produce scoperte. La distinzione conta per chiunque faccia previsioni su cosa l'IA farà alla scienza nei prossimi anni.

Come leggere benchmark come questo

Due avvertenze valgono per qualsiasi nuovo benchmark. La prima è il numero di versione. Questo è 0.1, il che significa che l'insieme di compiti cambierà man mano che gli autori imparano quali compiti sono ben posti e quali ambigui. I punteggi di versioni diverse non sono direttamente confrontabili.

La seconda è che un benchmark misura i flussi di lavoro che i suoi autori hanno scelto. Settanta compiti tratti da domini scientifici sono un campione, non un censimento. La cifra del 30 percento è un buon segnale della forma generale della capacità degli agenti nel lavoro di ricerca. Non è un numero preciso che sopravvivrà alla prossima revisione.

Cosa tenere d'occhio

Il progresso da osservare non è la percentuale principale che sale. È quali compiti iniziano a essere superati. Se gli agenti iniziano a completare flussi di lavoro che richiedono un recupero multi-step, quello è un vero avanzamento. Se il guadagno deriva solo da compiti più facili di configurazione e pulizia dei dati, il tetto è più basso di quanto suggerisca il titolo.

Un benchmark che riporta onestamente un numero basso è più utile di uno che riporta un numero alto che le persone non riescono a riprodurre. Questo sta facendo la prima cosa, e il campo ha bisogno di più di così.