notizia

compilazione del cuore della macchina

autore: omar khattab

redattore: salsa all'uovo, zenan

scrivere un articolo? questo è solo un piccolo passo.

durante la scuola di specializzazione, molte persone sono spesso confuse su come strutturare la propria ricerca. come dovremmo condurre la ricerca per fare la differenza nel campo già affollato dell’intelligenza artificiale?

troppe persone credono che progetti a lungo termine, rilasci adeguati di codice e benchmark ben ponderati non siano abbastanza motivanti: a volte può essere qualcosa che fai rapidamente e con senso di colpa, per poi tornare a fare ricerca "reale".

recentemente, omar khattab, uno studente di dottorato nel gruppo pnl dell’università di stanford, ha pubblicato un post sul blog in cui discute i pensieri dei migliori studiosi di intelligenza artificiale sulla conduzione di ricerche di grande impatto.

vediamo cosa ha detto:

l’impatto della ricerca si presenta in molte forme e mi concentrerò solo sulla misurazione dell’impatto della ricerca sull’intelligenza artificiale attraverso il lavoro open source (ad esempio modelli, sistemi, framework o benchmark). poiché parte del mio obiettivo è perfezionare le mie idee, registrare suggerimenti specifici e raccogliere feedback, renderò la dichiarazione più concisa. se avete altre idee, discutetene nell'area commenti.

innanzitutto, ecco i principi guida:

• concentrati sui progetti, non sui documenti.

• puoi "scavare una buca" scegliendo un problema appropriato che abbia più spazio per lo sviluppo.

• pensa due passi avanti e ripeti rapidamente.

• rendi pubblico il tuo lavoro e promuovi le tue idee.

• trova modi per motivarti: ecco alcuni suggerimenti per far crescere la tua ricerca open source.

• continua a investire nel tuo progetto con nuovi documenti.

• il quinto punto, “suggerimenti per lo sviluppo della ricerca open source”, merita un articolo più lungo a parte. potrei scriverne nel mio prossimo post.

concentrarsi sui progetti

piuttosto che un foglio

questo è un pensiero cruciale su cui si basa tutto il resto.

gli studenti principianti daranno grande enfasi alla pubblicazione dei loro primi articoli. questo ha senso: è così che impari a condurre ricerche, esplorare le direzioni iniziali e dimostrare i primi progressi. ma questa è una fase che prima o poi dovrai abbandonare: nel lungo periodo, i tuoi risultati e la tua crescita dipenderanno meno dal semplice numero di articoli e più dal tuo impatto e dal contesto di ricerca complessivo che trasmetti.

sfortunatamente, troppi dottorandi considerano i comportamenti potenzialmente più impattanti come “immotivanti”. questo mi ha confuso finché non ho capito che ciò che intendevano era che queste azioni avrebbero potuto rallentare la tua capacità di pubblicare il tuo prossimo articolo. ma la tua capacità di pubblicare il tuo prossimo articolo così rapidamente è meno importante.

ti suggerisco di non pensare al tuo lavoro come una serie di articoli isolati, ma di chiederti invece: quali sono le visioni più ampie che porterai avanti e quali sono i sottocampi o i paradigmi al loro interno? che differenza vuoi fare con il tuo lavoro? quindi pubblicherai documenti individuali per esplorare e stabilire parametri di riferimento, mentre la visione più ampia dovrebbe essere qualcosa su cui ripetere intenzionalmente. deve essere molto più grande di quanto trasportato dalla carta ed è certamente un problema che non è stato ancora completamente risolto.

un modo per farlo è strutturare alcuni documenti di ricerca attorno ad artefatti coerenti (come modelli, sistemi, framework o benchmark) che mantieni nel dominio open source. questa strategia è più costosa di "eseguire alcuni esperimenti e rilasciare un archivio rapido e fugace", ma ti costringe a trovare un problema con un impatto reale e aiuta a garantire che la nuova ricerca che fai sia effettivamente coerente e utile: non ti impegni nell'introdurre una piccola funzionalità o un trucco inutile per gli artefatti che hai sviluppato e mantenuto.

scegli domande appropriate con maggiori margini di miglioramento

può "scavare una buca"

non vale la pena investire in ogni articolo che scrivi indefinitamente. molti documenti sono documenti esplorativi una tantum. per trovare indicazioni che possano trasformarsi in progetti più ampi, utilizzare i seguenti criteri.

innanzitutto, il problema deve essere d’avanguardia. puoi definirlo in molti modi, ma inaiuna strategia efficace sul campo è quella di trovare uno spazio problematico che sarà “caldo” tra 2-3 anni ma che non è ancora diventato mainstream.

in secondo luogo, il problema deve avere un grande potenziale per scavare buchi, cioè un potenziale impatto su molti problemi a valle. fondamentalmente, i risultati di queste domande potrebbero essere utili o interessare un numero sufficiente di persone. i ricercatori e le persone si preoccupano di ciò che li aiuta a raggiungere i loro obiettivi, quindi la tua domanda potrebbe essere qualcosa come aiutare gli altri a costruire cose o raggiungere obiettivi di ricerca o produzione. puoi applicare questo filtro per studiare fondamenti teorici, infrastruttura di sistema, nuovi benchmark, nuovi modelli e molte altre cose.

in terzo luogo, il problema deve essere lasciato con un margine più ampio. se dici alle persone che il loro sistema può essere 1,5 volte più veloce o il 5% più efficiente, probabilmente non è interessante. mi sembra che sia necessario trovare problemi in cui, almeno dopo anni di duro lavoro, si ha una speranza diversa da zero di realizzare qualcosa più veloce, diciamo 20 volte più veloce o il 30% più efficiente. naturalmente, non devi arrivare fino in fondo per avere successo, e non dovresti aspettare fino a quando non ci arrivi completamente per pubblicare il tuo primo articolo o pubblicare il tuo primo lavoro.

non voglio essere troppo astratto, usiamo colbert per illustrare. alla fine del 2019, la ricerca sull’applicazione del bert per il recupero era molto popolare, ma questi metodi sono molto costosi. ci si chiede naturalmente: possiamo migliorare significativamente l’efficienza di questo approccio? cosa rende questa una buona domanda?

innanzitutto, è molto preceduto. possiamo prevedere correttamente che entro il 2021 (1,5 anni dopo), molti ricercatori cercheranno architetture di recupero efficienti basate su bert. in secondo luogo, ha molto spazio di sviluppo. i nuovi paradigmi ml tendono ad essere così perché la maggior parte di questi sforzi inizialmente ignora l’efficienza. in effetti, l’approccio originale potrebbe impiegare 30 secondi per rispondere a una query, ma ora può completare recuperi di qualità superiore in 30 millisecondi, ovvero 1.000 volte più veloci. terzo, ha un grande fanout. il recupero scalabile è un buon problema di "fondazione": tutti hanno bisogno di costruire qualcosa sui retriever, ma pochi vogliono costruirli.

pensa due passi avanti

e ripetere rapidamente

ora che hai un buon problema, non affrettarti a scegliere il frutto più facile che hai di fronte come approccio! ad un certo punto, almeno molte persone prenderanno in considerazione l’approccio “ovvio”.

invece, pensa almeno due passi avanti. identificare il percorso che la maggior parte delle persone probabilmente intraprenderà quando questa questione attuale diventerà finalmente mainstream. quindi, identifica i limiti del percorso stesso e lavora per comprendere e affrontare tali limiti.

come si presenta in pratica? rivisitiamo il caso colbert. il modo più ovvio per costruire un retriever efficiente utilizzando bert è codificare i documenti in vettori. è interessante notare che alla fine del 2019 solo un lavoro limitato sulle ir aveva raggiunto questo obiettivo. ad esempio, l’opera più citata in questa categoria (dpr) ha pubblicato la sua prima prestampa solo nell’aprile 2020.

detto questo, potresti pensare che la cosa giusta da fare nel 2019 sia costruire un ottimo modello ir a vettore singolo tramite bert. al contrario, pensare solo due passi avanti fa sorgere la domanda: prima o poi tutti costruiscono un approccio a vettore singolo, quindi dove si blocca fondamentalmente questo approccio a vettore singolo? in effetti, questo problema ha portato a paradigmi di interazione successivi e a modelli ampiamente utilizzati.

come altro esempio, possiamo usare dspy. nel febbraio 2022, quando i suggerimenti sono diventati sempre più potenti, è diventato chiaro che le persone volevano utilizzare i suggerimenti per il controllo della qualità basato sul recupero, piuttosto che per la messa a punto come prima. per fare questo, dobbiamo naturalmente stabilire un metodo. facendo due passi oltre, ci chiediamo: dove si blocca un simile approccio? in definitiva, l'approccio "recupera quindi genera" (o rag) è probabilmente l'approccio più semplice che coinvolge lm.

per gli stessi motivi per cui le persone sono interessate, saranno ovviamente sempre più interessate a: (i) esprimere combinazioni più complesse di moduli; (ii) capire cosa dovrebbe essere fatto attraverso suggerimenti automatici o messa a punto del sottostante lm how to supervisionare o ottimizzare la pipeline complessa risultante. questo è dspy.

la seconda metà di questa regola è "itera rapidamente". questo è stato forse il primo consiglio di ricerca che il mio relatore matei zaharia (vincitore del premio sloan e fondatore di apache spark) mi ha dato durante la prima settimana del mio dottorato: identificando un argomento su cui è possibile iterare rapidamente e ottenere feedback (come ritardo o verifica punteggio) versione del problema, che può aumentare notevolmente le tue possibilità di risolvere il puzzle. ciò è particolarmente importante se stai pensando due passi avanti, il che è abbastanza difficile e incerto.

rendi pubblico il tuo lavoro

lascia che le tue idee affondino

a questo punto, hai scoperto un buon problema e hai continuato a ripetere finché non hai scoperto qualcosa di interessante e hai scritto un articolo approfondito. non passare al documento successivo. concentrati invece sulla diffusione dei risultati del tuo lavoro nel mondo e cerca di avere interazioni reali con le persone, non solo riguardo al tuo unico rilascio cartaceo, ma riguardo al quadro generale su cui stai attivamente ricercando. o meglio ancora, fai conoscere alle persone un utile strumento open source che stai creando e mantenendo e che cattura le tue idee chiave.

un primo passo comune è pubblicare una prestampa del tuo articolo su arxiv e quindi pubblicare un "post" che annunci la pubblicazione del tuo articolo. quando lo fai, assicurati di iniziare il tuo post con un'affermazione specifica, sostanziale e comprensibile. l'obiettivo non è dire alla gente che hai pubblicato un articolo, che non ha valore intrinseco. l'obiettivo è trasmettere le tue argomentazioni chiave in modo diretto e coinvolgente. (sì, lo so, è difficile, ma è necessario).

forse ancora più importante, il processo non termina con il primo "lancio", è solo l'inizio. dato che ora sei investito in progetti, non solo in articoli, le tue idee e la tua comunicazione scientifica continueranno durante tutto l'anno, ben oltre le isolate pubblicazioni cartacee.

quando aiuto gli studenti laureati a twittare sul loro lavoro, non è raro che i loro post iniziali non ricevano l'attenzione che speravano. gli studenti spesso vedono questo come una conferma della loro paura di pubblicare la loro ricerca e lo prendono come un altro segno che dovrebbero passare al loro articolo successivo. ovviamente questa idea non è corretta.

c’è una ricchezza di esperienze personali, esperienze di seconda mano e osservazioni che dimostrano che ha molto senso perseverare in questa questione (cosa che, tra l’altro, non molte persone fanno). cioè, con rare eccezioni, la buona trazione di un'idea richiede che tu dica alle persone le cose chiave più volte in contesti diversi e raffini continuamente la tua idea e la tua consegna finché la comunità non sarà in grado di assimilare queste idee, o fino a quando il campo raggiunge il giusto stadio di sviluppo in cui queste idee sono più facilmente comprensibili.

raccogli entusiasmo

suggerimenti per la pubblicazione di ricerche open source

rendere le persone interessate alla tua ricerca è una buona cosa, ma fornire le tue idee ad applicazioni downstream pertinenti attraverso la pubblicazione, il contributo e lo sviluppo di strumenti open source può spesso avere un impatto maggiore.

non è facile farlo: caricare semplicemente i file di codice insieme al readme su github non è sufficiente. un buon repository sarà la "casa" del tuo progetto, più importante di qualsiasi articolo che pubblichi.

una buona ricerca open source richiede due qualità quasi indipendenti. in primo luogo, deve trattarsi di una buona ricerca, nuova, tempestiva, ben mirata e accurata. in secondo luogo, deve avere una chiara utilità a valle e un basso attrito.

questa è la parte più importante: le persone eviteranno ripetutamente (e altri utilizzeranno ripetutamente) il tuo lavoro oss per tutte le ragioni "sbagliate". ad esempio, la tua ricerca potrebbe essere oggettivamente "allo stato dell'arte", ma con ogni probabilità le persone daranno priorità alle alternative con meno attriti. d'altra parte, gli studenti laureati spesso non capiscono il motivo per cui le persone utilizzano il tuo strumento, ad esempio perché non sfruttano appieno le tue parti più creative. questo non è qualcosa a cui vale la pena resistere, ma qualcosa che vale la pena comprendere e migliorare.

sulla base di ciò, vorrei elencare alcune pietre miliari a cui prestare attenzione quando si tratta di risultati di ricerca open source.

obiettivo 0: rendere disponibili i contenuti pubblicati

non ha senso rilasciare codice che nessuno può eseguire. nel tuo campo di ricerca, queste persone vogliono replicare i tuoi risultati forse andranno oltre il tuo lavoro e citeranno i risultati della tua ricerca. queste persone sono più pazienti rispetto ad altri tipi di utenti. tuttavia, troverai enormi differenze nell'impatto accademico a seconda della facilità con cui il codice è patchato.

obiettivo 1: rendere utili i contenuti pubblicati

oltre alle persone nella tua nicchia, dovresti assicurarti che la tua pubblicazione sia utile a un pubblico che desidera effettivamente utilizzare il progetto per costruire altre cose. nella ricerca sull’intelligenza artificiale, questa pietra miliare raramente arriva in modo naturale. dovresti dedicare molto tempo a pensare ai problemi che le persone stanno cercando di risolvere (ricerca, produzione, ecc.) e a dove i tuoi sforzi di intelligenza artificiale possono aiutare. se riesci a farlo correttamente, avrai molti vantaggi, dalla progettazione del progetto all'api esposta e alla documentazione/esempi presentati.

pietra miliare 2: rendere comprensibili i comunicati

questo è difficile per i ricercatori sull'intelligenza artificiale, ma dovremmo renderci conto che una versione utile, dove tutto è tecnicamente disponibile ed è in qualche modo spiegabile, non significa che la maggior parte dei tuoi potenziali utenti la troverà la versione è facile da capire e sufficiente per mantenerli impegnato nell'apprendimento o nel provarlo.

il noto studioso di intelligenza artificiale andrej karpathy ha scritto un articolo su questo tema: "costruisci qualcosa e poi devi costruire rampe per arrivarci". anche ben clavie ha scritto molto su questo argomento, e ha avuto un ruolo importante nel prendere il lavoro che abbiamo fatto su colbert e renderlo più accessibile.

pietra miliare 3: capire perché l'ovvia alternativa ha fallito e sii paziente

abbiamo iniziato parlando di pensare due passi avanti. questo è fondamentale secondo me, ma significa anche che la maggior parte delle persone non capirà perché hanno bisogno di una soluzione a un problema che non possono ancora osservare chiaramente. penso che parte del tuo lavoro nel tempo sia costruire un caso. raccogli prove e spiega in modo facile da comprendere perché le alternative ovvie (pensa un passo alla volta) falliranno.

pietra miliare 4: comprendere il tipo di utenti e sfruttarlo per la crescita

quando ho avviato colbert e dspy, il mio pubblico iniziale erano ricercatori e ingegneri ml professionisti. col tempo, ho imparato a lasciar andare tutto ciò e a capire che puoi raggiungere un pubblico più vasto, ma loro vogliono cose diverse. prima di fare qualsiasi cosa, non bloccare indirettamente e nemmeno direttamente diverse categorie di potenziali utenti. questa situazione è molto più comune di quanto si pensi.

in secondo luogo, quando cerchiamo gli utenti, dobbiamo trovare un equilibrio tra le due tipologie di utenti. da un lato, i costruttori esperti con casi d’uso avanzati potrebbero richiedere di investire molti soldi, ma tendono a portare avanti determinati casi d’uso in un senso di ricerca, il che può ripagare. i costruttori pubblici, d'altra parte, in genere non sono esperti di ml, ma spesso sviluppano e condividono le loro conoscenze in pubblico, rappresentano una quota maggiore della crescita su larga scala e ti faranno riflettere di più sulla tua ipotesi iniziale. hai bisogno di entrambi.

obiettivo 5: trasformare l'interesse in una comunità in crescita

il vero successo del lavoro dell'oss risiede nella presenza di una comunità e nella sua continua crescita indipendentemente dai vostri sforzi. in generale, una buona comunità dovrebbe essere organica, ma è necessario lavorare attivamente per aiutarla a formarsi, ad esempio accogliendo contributi e discussioni e cercando opportunità per trasformare l'interesse in contributi o in qualche tipo di forum (come discord o github).

pietra miliare 6: convertire l'interesse in progetti downstream attivi, collaborativi e modulari

è probabile che il tuo progetto oss nelle sue fasi iniziali non risolva tutti i problemi della tua visione originale. un progetto ben progettato avrà spesso più parti modulari che consentono di avviare collaborazioni di ricerca (o altre attività) e consentire ai nuovi membri del team non solo di far avanzare il progetto, ma anche di possedere parti significative del progetto, rendendolo più veloce o con una maggiore influenza le loro idee migliorando notevolmente il progetto. ad esempio, dspy dispone attualmente di team separati che guidano le attività di ricerca e sviluppo nell'ottimizzazione just-in-time, nell'astrazione della programmazione e nell'apprendimento per rinforzo. i componenti di colbert come le interfacce di programmazione delle applicazioni esterne, l'infrastruttura di recupero sottostante e la modellazione principale sono guidati principalmente da persone diverse in progetti diversi.

vieni, riassumi. l'adozione della ricerca open source richiede una buona ricerca e buoni risultati open source. questo equilibrio è difficile da raggiungere, ma una volta trovato il giusto equilibrio può essere molto gratificante. personalmente, mi ci è voluto molto tempo per coglierlo e interiorizzarlo. ciò è avvenuto grazie ai ripetuti feedback dei miei supervisori di dottorato, chris potts e matei zaharia, nonché al prezioso contributo di heather miller e jeremy howard.

il criterio per valutare la ricerca è l'“incremento” rispetto alle conoscenze pregresse, ma prima che si possa sfruttare significativamente l'“incremento” è necessario che il software stesso sia efficace. perché il software sia efficace, anche la sua documentazione deve essere efficace: le persone non vedranno tutti i modi successivi in ​​cui dovrebbero utilizzare il software a meno che tu non glielo mostri. questo fino a quando questi compiti non potranno essere sviluppati da una comunità indipendente.

detto questo, l'abilità più importante in questa sezione è "pubblicare", pubblicare davvero, pubblicare spesso e imparare da ciò.

pubblica un nuovo articolo

continua a investire nei tuoi progetti

quando si legge la quinta regola, viene naturale chiedersi: dove gli studenti laureati trascorrono così tanto tempo sul software open source? quando si potrà fare vera ricerca?

la risposta pratica è che la maggior parte del tempo dedicato all’open source potrebbe essere utilizzato per condurre ricerche nuove ed entusiasmanti. i due non sono così separati come sembrano. perchè dici questo?

innanzitutto, essere in prima linea in questo tipo di lavoro con il software open source consente di identificare in modo intuitivo i nuovi problemi molto presto. capirai il problema più istintivamente di quanto faresti altrimenti. inoltre, la comunità che crei spesso fornisce feedback diretto sui prototipi dei tuoi metodi e ti dà accesso a collaboratori di talento che comprendono l'importanza del problema. avrai inoltre accesso a utili "canali di distribuzione" per garantire che ogni nuovo articolo che pubblichi in quest'area raggiunga il tuo pubblico e rafforzi la tua piattaforma esistente.

ad esempio, "colbert" non è solo un articolo dell'inizio del 2020. ora ha probabilmente una decina di documenti correlati di follow-up, investimenti in formazione migliorata, minore occupazione di memoria, infrastruttura di recupero più veloce, migliore adattabilità del dominio e migliore corrispondenza con le attività nlp a valle. allo stesso modo, dspy non è un articolo, ma una raccolta di articoli sull'astrazione della programmazione, sull'ottimizzazione dei suggerimenti e sui programmi downstream. molti di questi articoli sono scritti da vari autori eccellenti e il loro lavoro ha avuto un enorme impatto, in parte creando un vasto pubblico attraverso i canali del software open source.

pertanto, un buon strumento open source può creare opere modulari che possono essere esplorate, possedute e sviluppate da nuovi ricercatori e contributori.

testo originale di riferimento: https://github.com/okhat/blog/blob/main/2024.09.impact.md