notizia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

• Crecy proviene dal Tempio Aofei
  Qubit |. Account pubblico QbitAI

Il team Apple ha rilasciato un nuovo risultato open source: una serie di parametri di riferimento sulla capacità di richiamare strumenti di modelli di grandi dimensioni.

Questo benchmark utilizza in modo innovativoMetodo di valutazione basato su scenari, che può riflettere meglio il livello del modello nell'ambiente reale.

Introduce inoltre scenari importanti a cui non viene prestata attenzione negli standard tradizionali, come l’interazione del dialogo e la dipendenza dallo Stato.

Questa serie di benchmark di test si chiama ToolSandbox e anche Pang Ruoming, capo del team del modello base di Apple, ha partecipato al lavoro di ricerca.

ToolSandbox compensa la mancanza di valutazione basata su scenari negli standard di test esistenti e riduce il divario tra le condizioni di test e le applicazioni reali.

E in termini di interazione, l’autore lascia che GPT-4o agisca come utente e parli con il modello in prova, simulando così scenari del mondo reale.

Ad esempio, dì a GPT-4o che non sei più un assistente, ma vuoi interpretare l'utente A che sta parlando con l'utente B, e poi fai una serie di richieste specifiche.

Inoltre, l'autore ha utilizzato anche ToolSandbox per testare alcuni modelli tradizionali e i risultati complessiviI modelli closed source ottengono punteggi più alti rispetto ai modelli open source, il più potente dei quali è GPT-4o.

Lo sviluppatore di applicazioni iOS Nick Dobos ha affermato che l’insieme di standard di Apple è conciso e chiaro.

Allo stesso tempo, ha sottolineato che ChatGPT è già un po' sovraccarico di fronte a tre strumenti. Se Siri vuole gestire decine o centinaia di applicazioni sui telefoni cellulari, deve anche migliorare le sue capacità di chiamata degli strumenti.

L'implicazione è che la ricerca di ToolSandbox potrebbe servire a chiarire la direzione della futura ricerca e sviluppo di Siri.

Testare il modello in uno scenario

Come accennato in precedenza, ToolSandbox adotta un metodo di test interattivo e basato su scenari.

Nello specifico, ToolSandbox include un totale di quasi 2.000 scenari in sette tipi, tra cui invocazione di strumenti singoli/multipli, cicli di dialogo singoli/multipli, dipendenza dallo stato, standardizzazione e informazioni insufficienti.

I primi sono relativamente facili da capire. Ecco alcune spiegazioni per i seguenti tre tipi di scene:

• Dipendenza dallo stato: l'esecuzione di uno strumento dipende da alcuni stati globali e questo stato deve prima essere modificato da altri strumenti;
• Standardizzazione: converte le espressioni del linguaggio naturale nella forma standard richiesta dallo strumento, che potrebbe richiedere l'aiuto di altri strumenti;
• Informazioni insufficienti: gli strumenti chiave necessari per completare l'attività mancano intenzionalmente. Controllare se il modello può identificare situazioni in cui non può essere completato.

In questi scenari, ToolSandbox si concentrerà su tre indicatori del modello:

• Prestazione complessiva, ovvero la somiglianza media con le risposte preimpostate in vari scenari
• Robustezza, utilizzare vari metodi per modificare e interferire con lo strumento e osservare le prestazioni del modello in questo ambiente
• Efficienza, ovvero il numero medio di cicli di completamento delle attività

In termini di strumenti, l'autore ha selezionato come strumenti 34 funzioni Python combinabili, paragonabili alla complessità degli scenari reali.

Include sia strumenti Python nativi che alcuni strumenti RapidAPI integrati, con funzioni che coprono molte aree comuni come ricerca, dialogo, navigazione, meteo ed elaborazione di immagini.

In termini di processo, il primo passo è preparare lo scenario di test. I ricercatori definiranno e memorizzeranno lo stato mondiale iniziale e allo stesso tempo utilizzeranno il modello GPT-4o calibrato per generare il messaggio utente iniziale.

Entrando quindi nella fase di esecuzione interattiva, il sistema inizializza innanzitutto il Message Bus come canale di comunicazione tra i ruoli e configura il modello che interpreta l'utente e il modello sotto test.

Quando inizia il ciclo di conversazione, il modello che simula l'utente invia un messaggio iniziale e il modello sotto test riceve il messaggio e decide l'azione successiva, rispondendo direttamente all'utente o chiamando uno strumento per interagire con l'ambiente.

Se il modello sceglie di chiamare lo strumento, fornisce i parametri necessari in formato JSON e l'ambiente di esecuzione interpreta ed esegue questa chiamata, eventualmente aggiornando lo stato mondiale e gestendo potenziali condizioni di chiamata parallela.

Dopo che i risultati dell'esecuzione sono stati restituiti al modello sotto test, il modello sotto test determina nuovamente l'azione successiva. Questo processo continua finché il simulatore utente non ritiene che l'attività sia completata (o non possa essere completata), momento in cui chiamerà end_conversation. strumento per terminare la conversazione.

Durante l'intero processo di interazione, il sistema registra tutti i messaggi e i cambiamenti di stato per formare una "traccia di dialogo" completa, che poi entra nella fase di valutazione.

La valutazione utilizza “pietre miliari” e “campi minati” predefiniti per misurare le prestazioni del modello di agente.

pietra miliareVengono definiti gli eventi chiave per completare l'attività, formando un grafico aciclico diretto per riflettere le dipendenze temporali.

Il sistema cerca la migliore corrispondenza tra eventi e tappe fondamentali nella traiettoria mantenendo l'ordine topologico delle tappe fondamentali.

campo minatoDefinisce gli eventi proibiti e viene utilizzato principalmente per rilevare se il modello ha allucinazioni a causa di informazioni insufficienti.

Ad esempio, la figura seguente mostra un esempio di valutazione di un campo minato nello scenario di "informazioni insufficienti".

In questa attività, poiché il timestamp corrente non è disponibile, il modello non dovrebbe chiamare lo strumento timestamp_diff, ma il modello indovina erroneamente il timestamp corrente e chiama lo strumento, ottenendo un punteggio pari a 0 per questo round.

Alla fine, il sistema calcola un punteggio composito che è il prodotto del punteggio medio della partita fondamentale e della penalità del campo minato.

Inoltre, il sistema conterà anche il numero medio di round necessari per completare l'attività come indicatore supplementare per valutare l'efficienza del modello.

Gli scenari di interazione complessi rappresentano ancora una sfida

Su tutto,I modelli closed source hanno prestazioni migliori rispetto ai modelli open source in termini di chiamate agli strumenti。

Quello con il punteggio medio più alto è GPT-4o, con un punteggio di 73,0. È l'unico che supera 70 e ha ottenuto il punteggio più alto in quattro dei sette scenari stabiliti dall'autore.

Inoltre, GPT-4o è anche estremamente robusto. L'autore ha utilizzato 8 metodi per modificare lo strumento e GPT-4o ha ottenuto il punteggio di robustezza più alto tra questi.

È seguito da vicino da Claude 3-Opus, con un punteggio medio di 69,2, che supera GPT-4o nelle scene con informazioni insufficienti, e poi alcune altre versioni di GPT e Claude.

Il Gemini di Google è relativamente in ritardo. Il punteggio di 1.5 Pro è 60,4, che è appena sufficiente e non buono come GPT-3.5. Tuttavia, si comporta bene nel singolo elemento di informazioni insufficienti.

Il punteggio medio più alto del modello open source è solo 31,4. Tra questi, il famoso punteggio Mistral-7B è 29,8, ma ha ottenuto il punteggio migliore di 76,8 nella singola voce di informazione insufficiente.

Anche alcuni modelli open source come Gorilla e Command-R non sono in grado di gestire affatto le risposte degli strumenti o riescono a malapena a completare un singolo ciclo di chiamate agli strumenti.

Ulteriori analisi lo hanno dimostratoI modelli open source sono incapaci di identificare quando è il momento di ricorrere agli strumenti, preferendo trattare il problema come un puro compito di generazione di testo.

Dalla dimensione dell'attività, il modello grande funziona bene nelle chiamate di strumenti singoli/multipli e nelle richieste utente a ciclo singolo, maIl vantaggio si indebolisce nei dialoghi a più turni e nei compiti dipendenti dallo stato。

In famiglie come GPT, Claude e Gemini,I modelli più grandi presentano vantaggi più evidenti nell'invocazione multi-strumento e nelle attività di dialogo multi-turno.;MaSui compiti dipendenti dallo Stato, modelli di piccole e medie dimensioni（如GPT-3.5、Claude-3-Sonetto）Al contrario, è migliore del modello grande(GPT-4、Claude-3-Opus)eseguire meglio。

Inoltre, la normalizzazione rappresenta una sfida importante per tutti i modelli, in particolare per gli scenari che richiedono strumenti per la normalizzazione, e anche la normalizzazione dei parametri legati al tempo è molto difficile.

La ricerca sulla robustezza mostra che la sensibilità del modello ai cambiamenti nella descrizione dello strumento, nelle informazioni sui parametri, ecc. varia notevolmente e non vengono trovate regole ovvie.

In termini di efficienza, i modelli più potenti sono generalmente più efficienti, ma ci sono delle eccezioni. Ad esempio, l’efficienza dei modelli della serie Claude è generalmente migliore di quella GPT.

In breve, i modelli di grandi dimensioni devono ancora affrontare molte sfide quando utilizzano strumenti per gestire scenari di interazione complessi nel mondo reale.

Informazioni sull'autore

I membri del team ToolSandbox provengono dal machine learning, dalla data science, dal modello di base di grandi dimensioni di Apple e da altri team.

Il primo autore è un ingegnere cinese di machine learningJiarui Lu, si è laureato all'Università di Tsinghua. Durante i suoi studi, ha lavorato anche come assistente di ricerca nel laboratorio del professor Zhu Jun.

Successivamente, Lu ha conseguito un master in machine learning presso la Carnegie Mellon University ed è entrato in Apple nel 2020 dopo la laurea.

Compreso Lu, firmato10 dei 12 autori sono cinesie tutti provengono da scuole prestigiose.

Ciò include anche il capo del team di base del modello grandePang Ruom(Ruoming Pang).

Inoltre, un direttore tecnico che lavora in Apple da 8 anniBernhard Aumayer (1890-1965) è un medico.ha partecipato anche a questo progetto.

Indirizzo cartaceo:
https://arxiv.org/abs/2408.04682