nouvelles

comment un doctorat en ia produit-il des recherches percutantes ? les disciples des lauréats du prix sloan partagent leurs expériences

2024-10-07

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

compilation de coeurs de machines

auteur : omar khattab

editeur : sauce aux oeufs, zenan

rédiger un article ? ce n'est qu'un petit pas.

durant leurs études supérieures, de nombreuses personnes ne savent souvent pas comment structurer leur propre recherche. comment devrions-nous mener des recherches pour faire une différence dans le domaine déjà très chargé de l’intelligence artificielle ?

trop de gens pensent que les projets à long terme, les versions de code appropriées et les tests de référence bien pensés ne sont pas assez motivants - parfois, cela peut être quelque chose que vous faites rapidement et de manière coupable, puis recommencez à faire de "vraies" recherches.

récemment, omar khattab, doctorant au sein du groupe pnl de l'université de stanford, a publié un article de blog discutant des réflexions des meilleurs spécialistes de l'ia sur la réalisation de recherches percutantes.

voyons ce qu'il a dit :

l’impact de la recherche prend de nombreuses formes, et je me concentrerai uniquement sur la mesure de l’impact de la recherche sur l’ia à travers des travaux open source (par exemple, modèles, systèmes, cadres ou benchmarks). étant donné qu'une partie de mon objectif est d'affiner mes idées, d'enregistrer des suggestions spécifiques et de recueillir des commentaires, je vais rendre la déclaration plus succincte. si vous avez d'autres idées, veuillez en discuter dans la zone de commentaires.

tout d’abord, voici les principes directeurs :

  • concentrez-vous sur les projets, pas sur les papiers.

  • vous pouvez « creuser un trou » en choisissant un problème approprié qui a plus de place pour le développement.

  • pensez avec deux longueurs d'avance et répétez rapidement.

  • rendez votre travail public et faites la promotion de vos idées.

  • trouvez des moyens de vous motiver : voici des conseils pour développer votre recherche open source.

  • continuez à investir dans votre projet avec de nouveaux papiers.

  • le cinquième point, « conseils pour développer la recherche open source », mérite à lui seul un article plus long. j'en parlerai peut-être dans mon prochain article.

focus sur les projets

plutôt qu'un papier

il s’agit d’une réflexion cruciale sur laquelle repose tout le reste.

les étudiants débutants accorderont une grande importance à la publication de leurs premiers articles. cela a du sens : c'est ainsi que vous apprenez à mener des recherches, à explorer les orientations initiales et à démontrer les premiers progrès. mais c’est une étape que vous devrez éventuellement franchir : à long terme, vos réalisations et votre croissance dépendront moins du simple nombre d’articles que de votre impact et du contexte de recherche global que vous véhiculez.

malheureusement, trop de doctorants considèrent les comportements les plus potentiellement percutants comme « démotivants ». cela m'a dérouté jusqu'à ce que je réalise que ce qu'ils voulaient dire, c'est que ces actions pourraient ralentir votre capacité à publier votre prochain article. mais votre capacité à publier votre prochain article aussi rapidement est moins importante.

je vous suggère de ne pas considérer votre travail comme une série d'articles isolés, mais plutôt de vous demander : quelles sont les visions plus larges que vous allez mener, et quels sont les sous-domaines ou paradigmes qui s'y trouvent ? quelle différence voulez-vous faire avec votre travail ? vous publierez donc des articles individuels pour explorer et établir des références, tandis que la vision plus large devrait être quelque chose sur lequel vous répéterez intentionnellement. il doit être beaucoup plus volumineux que ce que contient le papier, et c'est certainement un problème qui n'a pas encore été entièrement résolu.

une façon d'y parvenir consiste à structurer certains documents de recherche autour d'artefacts cohérents (tels que des modèles, des systèmes, des cadres ou des benchmarks) que vous maintenez dans le domaine open source. cette stratégie est plus coûteuse que « faire quelques expériences et publier un référentiel rapide et éphémère », mais elle vous oblige à trouver un problème ayant un impact réel et permet de garantir que la nouvelle recherche que vous effectuez est réellement cohérente et utile : vous ne faites pas d'efforts. en introduisant une petite fonctionnalité ou une astuce inutile pour les artefacts que vous avez développés et maintenus.

choisissez des questions appropriées avec une plus grande marge d'amélioration

peut « creuser un trou »

tous les articles que vous rédigez ne valent pas la peine d’être investis indéfiniment. de nombreux articles sont des articles exploratoires ponctuels. pour trouver des orientations pouvant se transformer en projets plus vastes, utilisez les critères suivants.

premièrement, le problème doit être d’actualité. vous pouvez le définir de plusieurs façons, mais dansiaune stratégie efficace dans ce domaine consiste à trouver un domaine problématique qui sera « chaud » dans 2-3 ans mais qui n’est pas encore devenu courant.

deuxièmement, le problème doit avoir un grand potentiel de creusement de trous, c'est-à-dire un impact potentiel sur de nombreux problèmes en aval. fondamentalement, les résultats de ces questions pourraient bénéficier ou intéresser suffisamment de personnes. les chercheurs et les gens se soucient de ce qui les aide à atteindre leurs objectifs, votre question pourrait donc être par exemple aider les autres à construire des choses ou à atteindre leurs objectifs de recherche ou de production. vous pouvez appliquer ce filtre pour étudier les fondements théoriques, l’infrastructure système, de nouveaux benchmarks, de nouveaux modèles et bien d’autres choses.

troisièmement, il faut laisser au problème une plus grande marge. si vous dites aux gens que leur système peut être 1,5 fois plus rapide ou 5 % plus efficace, ce n'est probablement pas intéressant. il me semble que vous devez trouver des problèmes pour lesquels, au moins après des années de travail acharné, vous avez un espoir non nul de rendre quelque chose plus rapide, disons 20 fois plus rapide ou 30 % plus efficace. bien sûr, vous n’avez pas besoin d’aller jusqu’au bout pour réussir, et vous ne devriez pas attendre d’y être complètement pour publier votre premier article ou publier votre premier travail.

je ne veux pas être trop abstrait, utilisons colbert pour illustrer. fin 2019, les recherches sur l'application du bert pour la récupération étaient très populaires, mais ces méthodes sont très coûteuses. on se demande naturellement : pouvons-nous améliorer considérablement l’efficacité de cette approche ? qu’est-ce qui en fait une bonne question ?

premièrement, c'est très préfacé. nous pouvons prédire à juste titre que d’ici 2021 (un an et demi plus tard), de nombreux chercheurs rechercheront des architectures de récupération efficaces basées sur bert. deuxièmement, il y a une grande marge de développement. les nouveaux paradigmes de ml ont tendance à ressembler à ceci, car la plupart de ces efforts ignorent initialement l'efficacité. en fait, l’approche originale pouvait prendre 30 secondes pour répondre à une requête, mais elle permet désormais d’effectuer des extractions de meilleure qualité en 30 millisecondes, ce qui est 1 000 fois plus rapide. troisièmement, il a une grande diffusion. la récupération évolutive est un bon problème de « fondation » : tout le monde a besoin de construire quelque chose sur les récupérateurs, mais peu veulent les construire.

pensez avec deux longueurs d'avance

et itérer rapidement

maintenant que vous avez un bon problème, ne vous précipitez pas pour choisir le fruit à portée de main comme approche ! à un moment donné, au moins beaucoup de gens finiront par envisager l’approche « évidente ».

au lieu de cela, pensez à au moins deux longueurs d’avance. identifiez le chemin que la plupart des gens sont susceptibles d’emprunter lorsque cette question d’actualité deviendra enfin courante. ensuite, identifiez les limites du chemin lui-même et travaillez à comprendre et à résoudre ces limites.

a quoi cela ressemble-t-il en pratique ? revenons sur le cas colbert. le moyen évident de créer un récupérateur efficace à l'aide de bert est d'encoder les documents en vecteurs. il est intéressant de noter qu’à la fin de 2019, seuls des travaux limités en matière de ri avaient permis d’atteindre cet objectif. par exemple, l’ouvrage le plus cité dans cette catégorie (dpr) n’a publié sa première prépublication qu’en avril 2020.

compte tenu de cela, vous pourriez penser que la bonne chose à faire en 2019 est de créer un excellent modèle ir à vecteur unique via bert. en revanche, penser à deux longueurs d’avance soulève la question suivante : tôt ou tard, tout le monde construit une approche à vecteur unique, alors où cette approche à vecteur unique se bloque-t-elle fondamentalement ? en fait, ce problème a conduit ultérieurement à des paradigmes d’interaction et à des modèles largement utilisés.

comme autre exemple, nous pouvons utiliser dspy. en février 2022, alors que les indices devenaient de plus en plus puissants, il est devenu clair que les gens souhaitaient les utiliser pour une assurance qualité basée sur la récupération, plutôt que pour un réglage précis comme auparavant. pour ce faire, il faut naturellement établir une méthode. en allant plus loin, nous nous demandons : où une telle approche se bloque-t-elle ? en fin de compte, l'approche « récupérer puis générer » (ou rag) est probablement l'approche la plus simple impliquant lm.

pour les mêmes raisons que les gens s'y intéressent, ils seront évidemment de plus en plus intéressés par : (i) l'expression de combinaisons plus complexes de modules (ii) la détermination de ce qui doit être fait grâce à des invites automatiques ou à un réglage fin du lm sous-jacent. superviser ou optimiser le pipeline complexe qui en résulte. c'est dspy.

la seconde moitié de cette règle est « itérer rapidement ». c'était peut-être le premier conseil de recherche que mon conseiller matei zaharia (lauréat du prix sloan et fondateur d'apache spark) m'a donné au cours de la première semaine de mon doctorat : en identifiant un sujet sur lequel vous pouvez itérer rapidement et obtenir des commentaires (comme le retard ou la vérification score) du problème, ce qui peut grandement améliorer vos chances de résoudre le puzzle. ceci est particulièrement important si vous envisagez deux longueurs d’avance, ce qui est déjà assez difficile et incertain.

rendre votre travail public

laissez vos idées s'imprégner

à ce stade, vous avez découvert un bon problème et avez continué à répéter jusqu'à ce que vous découvriez quelque chose d'intéressant et écriviez un article perspicace. ne passez pas au prochain article. au lieu de cela, concentrez-vous sur la diffusion des résultats de votre travail dans le monde et cherchez à avoir de véritables interactions avec les gens, pas seulement à propos de votre publication papier, mais à propos de la situation générale que vous recherchez activement. ou mieux encore, faites connaître aux gens un outil open source utile que vous créez et maintenez et qui capture vos idées clés.

une première étape courante consiste à publier une prépublication de votre article sur arxiv, puis à publier un « article » annonçant la publication de votre article. ce faisant, assurez-vous de commencer votre message par une affirmation spécifique, substantielle et compréhensible. le but n’est pas de dire aux gens que vous avez publié un article qui n’a aucune valeur intrinsèque. le but est de transmettre vos principaux arguments de manière directe et engageante. (oui, je sais que c'est dur, mais c'est nécessaire).

peut-être plus important encore, le processus ne se termine pas avec le premier « lancement », ce n’est que le début. étant donné que vous êtes désormais investi dans des projets, et pas seulement dans des articles, vos idées et votre communication scientifique se poursuivront tout au long de l'année, bien au-delà des publications papier isolées.

lorsque j’aide des étudiants diplômés à tweeter sur leur travail, il n’est pas rare que leurs messages initiaux ne reçoivent pas l’attention qu’ils espéraient. les étudiants y voient souvent une confirmation de leur peur de publier leurs recherches et y voient un signe supplémentaire qu'ils devraient passer à leur prochain article. évidemment, cette idée est incorrecte.

il existe une richesse d’expériences personnelles, d’expériences de seconde main et d’observations qui montrent qu’il est tout à fait logique de persévérer dans ce domaine (ce que, d’ailleurs, peu de gens font). autrement dit, à de rares exceptions près, la traction d'une bonne idée nécessite que vous disiez aux gens les éléments clés à plusieurs reprises dans différents contextes et que vous affiniez continuellement votre idée et la façon dont vous la présentez jusqu'à ce que la communauté soit capable de grandir au fil du temps, ou jusqu'à ce que la communauté soit en mesure de se développer au fil du temps. le domaine atteint le bon stade de développement où ces idées sont plus facilement comprises.

recueillir l'enthousiasme

conseils pour publier des recherches open source

susciter l'enthousiasme des gens pour vos recherches est une bonne chose, mais transmettre vos idées à des applications pertinentes en aval par le biais de la publication, de la contribution et du développement d'outils open source peut souvent avoir un impact plus important.

ce n'est pas facile à faire : il ne suffit pas de simplement télécharger les fichiers de code avec le readme sur github. un bon référentiel sera le « domicile » de votre projet, plus important que n'importe quel article que vous publiez.

une bonne recherche open source requiert deux qualités presque indépendantes. premièrement, il doit s’agir d’une recherche de qualité, nouvelle, opportune, bien ciblée et précise. deuxièmement, il doit avoir une utilité claire en aval et une faible friction.

c'est la partie la plus importante : les gens éviteront à plusieurs reprises (et d'autres utiliseront à plusieurs reprises) votre travail oss pour toutes les « mauvaises » raisons. par exemple, votre recherche peut être objectivement « de pointe », mais selon toute vraisemblance, les gens donneront la priorité aux alternatives avec moins de frictions. d'un autre côté, les étudiants diplômés ne comprennent souvent pas pourquoi les gens utilisent votre outil, par exemple, parce qu'ils ne profitent pas pleinement de vos parties les plus créatives. ce n’est pas quelque chose qui mérite d’être résisté, mais quelque chose qui mérite d’être compris et d’être amélioré.

sur cette base, je voudrais énumérer quelques étapes auxquelles il faut prêter attention lorsqu'il s'agit de résultats de recherche sur l'open source.

jalon 0 : rendre le contenu publié disponible

cela ne sert à rien de publier du code que personne ne peut exécuter. dans votre domaine de recherche, ces personnes souhaitent reproduire vos résultats. peut-être iront-elles au-delà de votre travail et citeront les résultats de votre recherche. ces personnes sont plus patientes que les autres types d’utilisateurs. néanmoins, vous constaterez d'énormes différences dans l'impact académique en fonction de la facilité avec laquelle le code est à corriger.

étape 1 : rendre le contenu publié utile

en plus des personnes appartenant à votre niche, vous devez vous assurer que votre version est utile à un public qui souhaite réellement utiliser le projet pour créer d'autres choses. dans la recherche sur l’intelligence artificielle, cette étape arrive rarement naturellement. vous devez consacrer beaucoup de temps à réfléchir aux problèmes que les gens tentent de résoudre (recherche, production, etc.) et aux domaines dans lesquels vos efforts en matière d’ia peuvent vous aider. si vous parvenez à le faire correctement, cela présentera de nombreux avantages, de la conception du projet à l'api exposée en passant par la documentation/les exemples présentés.

étape 2 : rendre les versions compréhensibles

c'est difficile pour les chercheurs en ia, mais il faut comprendre qu'une version utile, où tout est techniquement disponible et quelque peu explicable, ne signifie pas que la majorité de vos utilisateurs potentiels trouveront cela. la version est facile à comprendre et suffisante pour les conserver engagé dans l’apprentissage ou l’essai.

andrej karpathy, spécialiste bien connu de l'ia, a écrit un article sur cette question : « vous construisez quelque chose, puis vous devez construire des rampes pour y accéder. » ben clavie a également beaucoup écrit à ce sujet, et il a largement contribué à rendre le travail que nous avons effectué sur colbert plus accessible.

étape 3 : découvrez pourquoi l'alternative évidente a échoué et soyez patient

nous avons commencé par parler de penser avec deux longueurs d’avance. c'est à mon avis crucial, mais cela signifie également que la plupart des gens ne comprendront pas pourquoi ils ont besoin d'une solution à un problème qu'ils ne peuvent pas encore clairement observer. je pense qu'une partie de votre travail, au fil du temps, consiste à monter un dossier. rassemblez des preuves et expliquez d'une manière facile à comprendre pourquoi les alternatives évidentes (pensez une étape à la fois) échoueront.

jalon 4 : comprendre le type d'utilisateurs et en tirer parti pour la croissance

lorsque j'ai lancé colbert et dspy, mon public initial était constitué de chercheurs et d'ingénieurs professionnels en ml. au fil du temps, j’ai appris à abandonner cela et à comprendre que l’on peut toucher un public plus large, mais qu’il veut des choses différentes. avant de faire quoi que ce soit, ne bloquez pas indirectement ni même directement différentes catégories d’utilisateurs potentiels. cette situation est beaucoup plus courante qu’on ne le pense.

deuxièmement, lors de la recherche d’utilisateurs, nous devons trouver un équilibre entre les deux types d’utilisateurs. d'une part, les constructeurs experts avec des cas d'utilisation avancés peuvent vous demander d'investir beaucoup d'argent, mais ont tendance à faire avancer certains cas d'utilisation dans le sens de la recherche, ce qui peut s'avérer payant. les constructeurs publics, en revanche, ne sont généralement pas des experts en ml, mais ils construisent et partagent souvent leurs apprentissages en public, représentent une plus grande part de la croissance à grande échelle et vous feront réfléchir davantage à votre hypothèse initiale. vous avez besoin des deux.

étape 5 : transformer l'intérêt en une communauté en pleine croissance

le véritable succès du travail oss réside dans la présence d'une communauté et sa croissance continue indépendamment de vos efforts. de manière générale, une bonne communauté doit être organique, mais vous devez travailler activement pour l'aider à se former, par exemple en accueillant des contributions et des discussions, et en recherchant des opportunités de transformer votre intérêt en contributions ou en une sorte de forum (comme discord ou github).

jalon 6 : convertir l'intérêt en projets en aval actifs, collaboratifs et modulaires

il y a de fortes chances que votre projet oss à ses débuts ne résolve pas tous les problèmes de votre vision initiale. un projet bien conçu comportera souvent plusieurs parties modulaires qui vous permettront d'initier des collaborations de recherche (ou d'autres efforts) et permettront aux nouveaux membres de l'équipe non seulement de faire avancer le projet, mais également de s'approprier des parties importantes du projet, ce qui le rendra plus rapide ou aura une plus grande influence. leurs idées tout en améliorant considérablement le projet. par exemple, dspy dispose actuellement d'équipes distinctes qui dirigent les efforts de r&d en matière d'optimisation juste à temps, d'abstraction de programmation et d'apprentissage par renforcement. les composants de colbert tels que les interfaces de programmation d'applications externes, l'infrastructure de récupération sous-jacente et la modélisation de base sont principalement pilotés par différentes personnes dans différents projets.

venez, résumez. l'adoption de la recherche open source nécessite une bonne recherche et de bons résultats open source. cet équilibre est difficile à trouver, mais une fois atteint, il peut être très gratifiant. personnellement, il m’a fallu beaucoup de temps pour comprendre et intérioriser cela. c'est grâce aux commentaires répétés de mes directeurs de doctorat, chris potts et matei zaharia, ainsi qu'à la précieuse contribution de heather miller et jeremy howard.

le critère d'évaluation de la recherche est « l'incrément » par rapport aux connaissances antérieures, mais avant de pouvoir exploiter de manière significative « l'incrément », le logiciel lui-même doit être efficace. pour qu'un logiciel soit efficace, sa documentation doit également l'être : les utilisateurs ne verront pas toutes les manières en aval dont ils sont censés utiliser le logiciel à moins que vous ne la leur montriez. autrement dit, jusqu'à ce que ces tâches puissent être développées par une communauté indépendante.

cela dit, la compétence la plus importante dans cette section est de « publier », de publier réellement, de publier souvent et d'en tirer des leçons.

publier un nouvel article

continuez à investir dans vos propres projets

lorsque vous lisez la cinquième règle, il est naturel de vous demander : où les étudiants diplômés passent-ils autant de temps sur les logiciels open source ? quand peut-on faire de véritables recherches ?

la réponse pratique est que la plupart du temps consacré à l’open source pourrait être utilisé pour mener des recherches nouvelles et passionnantes. les deux ne sont pas aussi distincts qu’il y paraît. pourquoi tu dis ça ?

premièrement, être à l’avant-garde de ce type de travail sur les logiciels open source vous permet d’identifier intuitivement de nouveaux problèmes très tôt. vous comprendrez le problème plus instinctivement que vous ne le feriez autrement. de plus, la communauté que vous créez fournit souvent des commentaires directs sur vos propres prototypes de méthodes et vous donne accès à des collaborateurs talentueux qui comprennent l'importance du problème. vous aurez également accès à des « canaux de distribution » utiles pour garantir que chaque nouvel article que vous publiez dans ce domaine atteint votre public et renforce votre plateforme existante.

par exemple, « colbert » n’est pas qu’un journal début 2020. il compte désormais probablement une dizaine d'articles de suivi, investissant dans une formation améliorée, une empreinte mémoire réduite, une infrastructure de récupération plus rapide, une meilleure adaptabilité du domaine et une meilleure correspondance avec les tâches nlp en aval. de même, dspy n'est pas un article, mais une collection d'articles sur l'abstraction de la programmation, l'optimisation des indices et les programmes en aval. beaucoup de ces articles sont rédigés par d’excellents auteurs et leurs travaux ont eu un impact énorme, en partie en créant un large public via les canaux de logiciels open source.

ainsi, un bon outil open source peut créer des œuvres modulaires qui peuvent être explorées, possédées et développées par de nouveaux chercheurs et contributeurs.

texte original de référence : https://github.com/okhat/blog/blob/main/2024.09.impact.md