Bonjour à tous, bienvenue à un autre cours de CS230 Deep Learning. Aujourd'hui, nous allons parler de l'amélioration des applications de grands modèles de langage. J'appelle ce cours « Au-delà des LLM ». Il contient beaucoup de nouveaux contenus et l'idée derrière ce cours est que nous avons commencé par apprendre les neurones, puis les couches, puis les réseaux de neurones profonds, puis un peu sur la façon de structurer les projets en C3, et maintenant nous passons au niveau supérieur pour voir à quoi ressemblerait la construction de systèmes d'IA agentiques au travail, dans une startup ou dans une entreprise. C'est probablement l'un des cours les plus pratiques. Le but n'est pas de construire un produit de bout en bout dans l'heure qui suit, mais plutôt de vous présenter toutes les techniques que les ingénieurs en IA ont découvertes ou explorent afin qu'après le cours, vous ayez une vue d'ensemble des différentes techniques de prompt, des différents flux de travail agentiques, des systèmes multi-agents et des évaluations. Ensuite, quand vous voudrez approfondir, vous aurez les bases pour plonger plus loin et apprendre plus vite. Essayons de rendre cela aussi interactif que possible, comme d'habitude. Si l'on regarde l'ordre du jour, nous allons commencer par l'idée centrale derrière les défis et les opportunités pour augmenter les LLM. Nous partons d'un modèle de base ; comment maximiser les performances de ce modèle ? Ensuite, nous nous pencherons sur la première ligne d'optimisation qui sont les méthodes de prompting et nous en verrons une variété. Ensuite, nous irons un peu plus loin dans le fine-tuning. Je ne suis pas un fan du fine-tuning et j'en parle beaucoup, mais j'expliquerai pourquoi j'essaie de l'éviter autant que possible. Ensuite, nous ferons une section quatre sur la génération augmentée par récupération ou RAG, dont vous avez probablement entendu parler dans l'actualité. Nous allons décortiquer ce qu'est un RAG, comment il fonctionne et les différentes méthodes au sein des RAG. Ensuite, nous parlerons des flux de travail d'IA agentiques. Andrew Ng est l'un des premiers à avoir nommé cette tendance « flux de travail d'IA agentiques », nous examinerons donc la définition qu'Andrew donne aux flux agentiques, puis nous commencerons à voir des exemples. La section six est très pratique. Il s'agit d'une étude de cas où nous réfléchirons à un flux de travail agentique et je vous demanderai de mesurer si l'agent fonctionne réellement et nous réfléchirons à la manière dont nous pouvons mesurer si un flux agentique fonctionne comme vous le souhaitez. Il existe de nombreuses méthodes appelées « evals » (évaluations) qui résolvent ce problème. Ensuite, nous examinerons brièvement les flux de travail multi-agents, puis nous pourrons avoir une discussion ouverte où je partagerai quelques réflexions sur la suite de l'IA et j'ai hâte de vous entendre tous également sur ce point. Commençons par le problème de l'augmentation des LLM. Question ouverte pour vous : vous connaissez tous les modèles pré-entraînés comme GPT-3.5 Turbo ou GPT-4o. Quelle est la limite de l'utilisation d'un simple modèle de base ? Quels sont les problèmes typiques qui pourraient survenir lors de l'utilisation d'un modèle pré-entraîné standard ?

Il manque de connaissances spécifiques à certains domaines.

Manque de connaissances spécialisées. Vous avez tout à fait raison. Nous avions un groupe d'étudiants il y a quelques années — ce n'était pas lié aux LLM — mais ils construisaient un appareil ou un véhicule agricole autonome doté d'une caméra en dessous prenant des photos des cultures pour déterminer si la culture est malade ou non et si elle doit être utilisée ou non. Cet ensemble de données n'est pas un jeu de données que l'on trouve partout et le modèle de base ou un modèle de vision par ordinateur pré-entraîné manquerait bien sûr de ces connaissances. Quoi d'autre ?

Il est entraîné sur des images de haute qualité, mais la réalité des images est qu'elles sont très sombres ou comportent du bruit.

D'accord, vous voulez peut-être dire que le modèle a pu être entraîné sur des données de haute qualité, mais que les données réelles ne sont pas d'aussi bonne qualité. En fait, oui, la distribution du monde réel peut différer, comme nous l'avons vu avec les GAN, de l'ensemble d'entraînement. Cela pourrait poser un problème avec les modèles pré-entraînés, bien que les LLM pré-entraînés s'améliorent pour gérer toutes sortes de types de données. Oui.

Manque d'informations actuelles.

Manque de quoi ?

D'informations actuelles.

Manque d'informations actuelles. Le LLM n'est pas à jour. Vous avez raison. Imaginez que vous deviez réentraîner votre LLM à partir de zéro tous les deux mois. Une anecdote que j'ai trouvée amusante date d'il y a environ cinq ans : pendant sa première présidence, le président Trump a tweeté un jour « covfefe ». Vous vous souvenez de ce tweet ? C'était probablement une faute de frappe ou il l'avait dans sa poche, mais ce mot n'existait pas. Les LLM que Twitter utilisait à l'époque ne pouvaient pas reconnaître ce mot et le système de recommandation est devenu incontrôlable parce que soudain tout le monde se moquait de ce tweet en utilisant le mot « covfefe » et le LLM ne comprenait pas ce que cela signifiait, où l'afficher et à qui. C'est un exemple de ce qui se passe aujourd'hui, surtout sur les réseaux sociaux, où il y a tellement de nouvelles tendances qu'il est très difficile de réentraîner un LLM pour qu'il corresponde à la nouvelle tendance et comprenne les nouveaux mots. Vous entendez souvent des mots de la génération Z comme « rizz » ou « mid » ou autre. Vous voulez probablement trouver un moyen de permettre au LLM de comprendre ces tendances sans réentraîner le LLM de zéro. Quoi d'autre ?

Il est entraîné pour avoir des connaissances générales, mais si vous voulez l'utiliser pour une tâche spécialisée, il pourrait ne pas être aussi performant.

Oui, il peut être entraîné sur une vaste étendue de connaissances, mais il peut échouer ou ne pas être assez performant sur une tâche étroite très bien définie. Pensez aux applications d'entreprise où vous avez besoin d'une haute précision, d'une haute fidélité et d'une faible latence ; peut-être que le modèle n'est pas excellent pour cette chose spécifique. Il peut s'en sortir, mais pas assez bien et vous pourriez vouloir l'augmenter d'une certaine manière.

Il peut avoir beaucoup de connaissances générales, mais elles ne sont peut-être pas nécessaires pour votre application et vous utilisez donc un modèle massif et lourd alors que vous n'utilisez réellement que 2 % de ses capacités.

Peut-être qu'il a beaucoup de connaissances générales qui ne sont pas nécessaires pour votre application et vous utilisez donc un modèle massif et lourd alors que vous n'utilisez réellement que 2 % des capacités du modèle. Vous avez parfaitement raison. Vous n'avez peut-être pas besoin de tout cela, donc vous pourriez trouver des moyens d'élaguer, de quantifier le modèle ou de le modifier. Tous ces points sont excellents. Je vais en ajouter quelques-uns également. Les LLM sont très difficiles à contrôler. Votre dernier point en est d'ailleurs un exemple. Vous voulez contrôler le LLM pour qu'il utilise une partie de ses connaissances, mais il finit par s'embrouiller. En 2016, Microsoft a créé un bot Twitter tristement infamous qui apprenait des utilisateurs et il est rapidement devenu un abruti raciste. Microsoft a fini par retirer le bot 16 heures après son lancement. La communauté a été très rapide à déterminer qu'il s'agissait d'un bot raciste, ce qui prouve qu'il est difficile de contrôler un LLM. Plus récemment encore, il y a eu un tweet de Sam Altman en novembre dernier lors de ce débat entre Elon Musk et Sam Altman pour savoir quel LLM était une machine de propagande de gauche ou de droite. Ils se détestaient mutuellement pour leurs LLM respectifs, mais cela montre au final que même ces deux équipes, Grok et OpenAI, qui sont probablement les équipes les mieux financées avec énormément de talent, ne font pas un excellent travail pour contrôler leurs LLM. De temps en temps, si vous traînez sur X, vous pouvez voir des captures d'écran d'utilisateurs interagissant avec des LLM où le LLM dit quelque chose de très controversé, raciste ou quelque chose qui ne serait pas considéré comme génial selon les normes sociales, et cela vous montre que le modèle est vraiment difficile à contrôler. Le deuxième aspect est une chose que vous avez mentionnée plus tôt. Les LLM peuvent être moins performants dans votre tâche, ce qui peut inclure des lacunes de connaissances spécifiques comme le diagnostic médical. Si vous faites du diagnostic médical, vous préféreriez avoir un LLM spécialisé pour cela et qui y excelle. En fait, une chose que nous n'avons pas mentionnée en tant que groupe, ce sont les sources. On a du mal à croire quelque chose à moins d'avoir la source réelle de la recherche qui le soutient. Les incohérences de style et de format sont un autre problème. Imaginez que vous construisiez un flux de travail agentique d'IA juridique. Le domaine juridique a une façon très spécifique d'écrire et de lire où chaque mot compte. Si vous négociez un contrat important, chaque mot de ce contrat peut signifier autre chose devant un tribunal et il est donc très important d'utiliser un LLM qui y soit très bon. La précision compte. Ensuite, il y a la compréhension spécifique à une tâche, comme effectuer une classification dans un domaine de niche. Disons qu'un produit biotechnologique essaie d'utiliser un LLM pour classer les avis des utilisateurs en positif, neutre ou négatif. Peut-être que pour cette entreprise, ce qui serait considéré comme un avis négatif est en fait considéré comme un avis neutre parce que le NPS de cette industrie a tendance à être bien inférieur à celui d'autres industries. C'est une compréhension spécifique à la tâche et le LLM doit être aligné sur ce que l'entreprise estime être la catégorisation qu'elle souhaite. Nous verrons un exemple de la façon de résoudre ce problème dans un instant. Ensuite, il y a la gestion limitée du contexte. De nombreuses applications d'IA, en particulier dans l'entreprise, nécessitent des données qui ont beaucoup de contexte. Pour prendre un exemple simple, la gestion des connaissances est un espace important. Lorsque vous allez sur votre disque dur et que vous avez tous vos documents, idéalement vous pourriez avoir un LLM fonctionnant au-dessus de ce disque ; vous pourriez poser n'importe quelle question et il lirait des milliers de documents et répondrait. En pratique, comme les LLM n'ont pas un contexte suffisamment large, vous ne pouvez pas utiliser un LLM pré-entraîné autonome pour résoudre ce problème. Vous devrez l'augmenter. Est-ce que cela a du sens ? L'autre aspect concernant les fenêtres de contexte est qu'elles sont en fait limitées. Si vous regardez les fenêtres de contexte des modèles des cinq dernières années, même les meilleurs modèles aujourd'hui vont se situer dans une plage de fenêtre de contexte ou de nombre de jetons qu'ils peuvent prendre en entrée d'environ quelques centaines de milliers de jetons au maximum. Juste pour vous donner une idée, 200 000 jetons représentent environ deux livres. Vous pouvez imaginer que lorsque vous traitez de la compréhension vidéo ou de fichiers de données plus lourds, cela pose évidemment un problème. Vous devrez peut-être les segmenter, les intégrer (embedding) ou trouver d'autres moyens d'amener le LLM à gérer des contextes plus larges. Le mécanisme d'attention est également puissant mais problématique car il ne parvient pas très bien à porter son attention dans des contextes très larges. Il existe un problème intéressant appelé « l'aiguille dans une botte de foin » (needle in a haystack). C'est un benchmark d'IA où, afin de tester si votre LLM est capable de prêter attention à un fait très précis au sein d'un grand corpus, les chercheurs insèrent au hasard une phrase dans un livre qui énonce un certain fait. Ensuite, on demande au LLM ce qui s'est passé concernant ce fait pour voir s'il s'en souvient. C'est en fait un problème complexe non pas parce que la question est complexe, mais parce que vous demandez au modèle de trouver un fait dans un très grand corpus. Et c'est compliqué. Encore une fois, c'est un facteur limitant pour les LLM.

Nous parlerons du RAG dans un instant, mais je veux donner un aperçu du débat sur la question de savoir si le RAG est la bonne approche à long terme pour les systèmes d'IA. En tant qu'idée de haut niveau, un RAG est un mécanisme qui intègre des documents qu'un LLM peut récupérer puis ajouter comme contexte à son prompt initial pour répondre à une question. La gestion des connaissances en est un exemple. Le débat est qu'en théorie, si nous avons une puissance de calcul infinie, alors le RAG est inutile car on peut simplement lire un corpus massif immédiatement et répondre à la question. Mais même dans ce cas, la latence pourrait être un problème. Imaginez le temps qu'il faudrait à une IA pour lire tout votre disque dur à chaque fois que vous posez une question. L'origine des sources compte également. Il y a toujours ce débat dans la communauté pour savoir si une certaine méthode est réellement pérenne car en pratique, comme la puissance de calcul double chaque année, certaines des méthodes que nous apprenons actuellement pourraient ne plus être pertinentes dans trois ans. Nous n'en savons rien. L'analogie qu'il fait sur la raison pour laquelle les approches RAG pourraient rester pertinentes même dans longtemps est la recherche. Lorsque vous effectuez une recherche sur un moteur de recherche, vous trouvez toujours des sources d'information et, en fait, en arrière-plan, il existe des algorithmes de parcours détaillés qui classent et trouvent les liens spécifiques, par opposition à si vous deviez lire l'intégralité du web à chaque fois que vous faites une requête de recherche. Lorsque nous pensons à améliorer les LLM, la façon la plus simple de le voir est en deux dimensions. Une dimension consiste à améliorer le modèle de fondation lui-même. Par exemple, nous passons de GPT-3.5 Turbo à GPT-4o. Le modèle pré-entraîné s'améliore et vous devriez donc voir vos performances s'améliorer sur vos tâches. L'autre dimension est que nous pouvons concevoir des moyens d'exploiter le LLM pour le rendre meilleur. Vous pouvez faire du prompting simple, enchaîner certains prompts, ou mettre un RAG ou un flux de travail agentique autour. C'est une autre dimension pour améliorer les performances. Ce cours porte sur cet axe vertical. Ça vous va pour l'introduction ? Passons à l'ingénierie des prompts (prompt engineering). Je vais commencer par une étude intéressante juste pour justifier pourquoi le prompt engineering est important. Il existe une étude de HBS, UPenn et Wharton qui a pris un sous-ensemble de consultants du BCG, et les a divisés en trois groupes. Un groupe n'avait pas accès à l'IA, un groupe avait accès à GPT-4, et un groupe avait accès au LLM plus une formation sur la façon de mieux prompter. Ils ont observé les performances de ces consultants à travers une grande variété de tâches. Ils ont remarqué quelques points intéressants. L'un d'eux est ce qu'ils ont appelé la « frontière dentelée » (jagged frontier), ce qui signifie que certaines tâches effectuées par les consultants tombent au-delà de cette frontière, signifiant que l'IA n'est pas assez bonne et n'améliore pas la performance humaine. Dans certains cas, elle l'aggrave même. Certaines tâches sont en deçà de la frontière, ce qui signifie que l'IA améliore considérablement les performances, la vitesse et la qualité du consultant. Le résumé est qu'il existe une frontière à l'intérieur de laquelle l'IA aide absolument et une autre où ils signalent ce comportement de « s'endormir au volant » où les gens comptaient sur l'IA pour une tâche qui était au-delà de la frontière et cela a fini par être pire parce que l'humain ne vérifiait pas les résultats assez attentivement. Ils ont noté que le groupe qui avait été formé était le meilleur, plus performant que le groupe qui n'avait pas été formé au prompt engineering, ce qui motive également l'intérêt de ce cours.

Un autre aperçu concernait les centaures et les cyborgs. Ils ont remarqué que les consultants avaient tendance à travailler avec l'IA de l'une des deux manières suivantes. Les centaures sont des créatures mythiques mi-humaines, mi-chevalines. Il s'agissait d'individus qui divisaient et déléguaient. Ils pouvaient confier une tâche assez importante à l'IA, rédiger un prompt très long, la laisser travailler, puis revenir une fois terminé. D'autres agissaient comme des cyborgs. Les cyborgs sont des robots humains totalement fusionnés. Ces individus ne déléguaient pas entièrement une tâche ; ils travaillaient super rapidement avec le modèle dans un va-et-vient constant. Je trouve que beaucoup d'étudiants travaillent plus comme des cyborgs que comme des centaures, alors qu'en entreprise, lorsqu'on essaie d'automatiser un flux de travail, on pense plus comme un centaur. De plus, beaucoup d'entreprises vous diront qu'elles recrutent des « prompt engineers » comme carrière. Je n'y crois pas. Je pense que c'est juste une compétence que tout le monde devrait avoir. Vous n'allez pas faire carrière dans le prompt engineering, mais vous allez probablement l'utiliser comme une compétence très puissante dans votre carrière. Parlons des principes de base de la conception de prompts. Je vous donne ici un prompt très simple : « résume ce document ». Le modèle n'a pas beaucoup de contexte sur ce que devrait être le résumé, sa longueur ou de quoi il devrait parler. Vous pouvez améliorer ce prompt en disant : « résume cet article scientifique de 10 pages sur l'énergie renouvelable en cinq points clés, en mettant l'accent sur les conclusions principales et les implications pour les décideurs politiques. » C'est déjà mieux. Vous précisez l'audience et vous l'adaptez. Vous dites que vous voulez cinq points clés et que vous voulez vous concentrer uniquement sur les conclusions principales. Comment pourriez-vous encore améliorer ce prompt ? Quelles sont les autres techniques dont vous avez entendu parler ou que vous avez essayées vous-mêmes et qui pourraient améliorer ce prompt en un seul passage ?

Fournir des exemples.

D'accord, donner des exemples. Donc vous voulez dire : « voici un exemple d'un excellent résumé ». Vous avez raison, c'est une bonne idée.

Est-ce qu'on peut demander à quelqu'un d'agir comme s'il était un expert ?

Technique très populaire, agis comme un expert en énergies renouvelables donnant une conférence à Davos. C'est génial.

J'allais dire la même chose, agis comme si tu étais vraiment doué pour ça.

Tu es le meilleur au monde dans ce domaine, explique. En fait, ces choses fonctionnent. C'est drôle, mais cela fonctionne de dire « agis comme XYZ ». C'est un modèle de prompt très populaire. Quoi d'autre pourriez-vous faire ?

Personnellement, j'aime bien dire « critique ton propre projet ».

Critique ton propre projet, donc vous utilisez la réflexion. Vous pourriez en fait obtenir un premier résultat, puis lui demander de le critiquer et de le retravailler. C'est une excellente technique qui fonctionne généralement mieux dans ces cas-là, mais nous en verrons quelques exemples. Quoi d'autre ?

Décomposer la tâche en étapes.

Décomposer la tâche en étapes. Savez-vous comment cela s'appelle ?

Non.

Chaîne de pensée (Chain of Thought). C'est en fait une méthode populaire dont la recherche a montré qu'elle améliorait les choses. Vous pourriez donner des instructions claires et aussi encourager le modèle à réfléchir étape par étape. Aborde la tâche étape par étape et ne saute aucune étape. Ensuite, vous lui donnez des étapes telles que étape 1 : identifier les trois conclusions les plus importantes, étape 2 : expliquer comment chaque conclusion impacte la politique des énergies renouvelables, étape 3 : rédiger le résumé en five points, chaque point traitant d'une conclusion. La chaîne de pensée est très populaire en ce moment, surtout dans les startups d'IA qui essaient de contrôler leurs LLM. Pour en revenir à vos exemples sur « agis comme XYZ », ce que j'aime faire, c'est regarder les prompts des autres. En fait, en ligne, vous avez beaucoup de dépôts de prompts gratuits sur GitHub. J'ai mis le lien vers le dépôt « awesome prompt template » sur GitHub où vous avez tant d'exemples de superbes prompts que des ingénieurs ont construits. Beaucoup d'entre eux commencent par « agis en tant que », comme agis en tant que terminal Linux, agis en tant que traducteur anglais, ou agis en tant qu'interviewer pour un poste. L'avantage d'un modèle de prompt est que vous pouvez le mettre dans votre code et le mettre à l'échelle pour de nombreuses demandes d'utilisateurs. Laissez-moi vous donner un exemple de Workera. Workera évalue les compétences et essaie de les personnaliser pour l'utilisateur. Dans un système RH, vous pourriez avoir Jane qui est chef de produit de niveau trois aux États-Unis et sa langue préférée est l'anglais. Ces métadonnées peuvent être insérées dans un modèle de prompt qui personnalisera pour Jane et de même pour Joe dont la langue préférée est l'espagnol. C'est ce qu'on appelle un modèle de prompt (prompt template).

Est-ce que ces modèles de fondation utilisent des modèles de prompt ou est-ce quelque chose que vous devez intégrer vous-même ?

La question est : est-ce que les modèles de fondation utilisent un modèle de prompt ou devez-vous l'intégrer vous-même ? Les modèles de fondation utilisent probablement un prompt système (system prompt) que vous ne voyez pas. Lorsque vous écrivez sur ChatGPT, il est possible qu'OpenAI ait en arrière-plan un prompt tel que « agis comme un assistant très utile pour cet utilisateur » et y insère vos souvenirs provenant d'une base de données. Ensuite, votre prompt arrive en dessous et la génération commence. Ils utilisent donc probablement quelque chose comme ça, mais cela ne veut pas dire que vous ne pouvez pas en ajouter un vous-même. Si vous pensez à un modèle de prompt pour l'exemple de Workera que je montrais, peut-être qu'il commence quand vous appelez OpenAI par « agis comme un assistant utile » et en dessous il est dit « agis comme un excellent mentor en IA qui aide les gens dans leur carrière ». Le modèle de prompt d'OpenAI contient également des instructions telles que « suis les instructions du créateur ». Des questions sur les modèles de prompts ? Encore une fois, je vous encourage à aller lire des exemples de prompts, certains sont très bien pensés. Parlons du prompt zero-shot par rapport au few-shot. Voici un exemple : « classe le ton de cette phrase comme positif, négatif ou neutre », puis vous collez l'avis : « le produit est correct mais j'en attendais plus ». Si je devais faire un sondage dans la salle, je parie que certains d'entre vous diraient que c'est négatif et certains diraient que c'est neutre parce que vous avez une première partie relativement positive et une deuxième partie relativement négative. Cela peut être une question subjective et peut-être que dans un secteur cela serait considéré comme incroyable et dans un autre comme vraiment mauvais. La façon dont vous pouvez aligner le modèle sur votre tâche est de convertir ce prompt zero-shot en un prompt few-shot où le modèle reçoit un ensemble d'exemples. L'exemple ici est que vous collez le même prompt, puis vous ajoutez : « voici des exemples de classifications de tons ». « Cela a complètement dépassé mes attentes » est positif. « C'est correct mais j'aimerais qu'il y ait plus de fonctionnalités » est négatif. « Le service était adéquat, ni bon ni mauvais » est neutre. Maintenant, classe le ton de cette phrase. Le modèle répond alors négatif, probablement à cause du deuxième exemple. Parce que le modèle a vu cela, il est maintenant aligné sur vos attentes. Les prompts few-shot sont très populaires. Pour les startups d'IA un peu plus sophistiquées, vous pourriez les voir maintenir un prompt à jour chaque fois qu'un utilisateur dit quelque chose, elles pourraient demander à un humain de le labelliser puis l'ajouter comme exemple few-shot. On peut voir cela comme la construction d'un jeu de données, mais au lieu de construire un jeu de données séparé pour un fine-tuning supervisé, vous le mettez directement dans le prompt. C'est probablement plus rapide de faire ainsi si vous voulez expérimenter rapidement car vous ne touchez pas aux paramètres du modèle. S'il s'agit d'exemples textuels, vous pouvez concaténer de nombreux exemples dans un seul prompt. À un certain moment, ce sera trop long et vous n'aurez pas la fenêtre de contexte nécessaire, mais c'est une approche assez solide et rapide pour aligner un LLM. Passons à l'enchaînement (chaining). L'enchaînement est la technique la plus populaire parmi tout ce que nous avons vu jusqu'à présent en prompt engineering. Ce n'est pas la chaîne de pensée. Il s'agit d'enchaîner des prompts complexes pour améliorer les performances. Vous prenez un prompt en une seule étape tel que « lis cet avis client et rédige une réponse professionnelle qui reconnaît leur préoccupation, explique le problème, propose une résolution », puis vous collez l'avis. Le résultat est un e-mail qui vous est donné immédiatement. Cela peut fonctionner, mais cela peut être difficile à contrôler car il y a plusieurs étapes listées et tout est intégré dans le même prompt. Si vous vouliez déboguer étape par étape et savoir quelle étape est la plus faible, vous ne pourriez pas. L'un des avantages de l'enchaînement est que vous séparez les prompts afin de pouvoir les déboguer séparément, ce qui facilitera également l'amélioration de votre flux de travail. Disons qu'un premier prompt est « extraire les problèmes clés ». Deuxième prompt : « en utilisant ces problèmes, rédige un plan pour une réponse professionnelle ». Prompt numéro trois : « en utilisant le plan, rédige la réponse professionnelle ». En théorie, la deuxième approche peut sembler plus complexe, mais nous pouvons tester ces trois prompts séparément et déterminer si nous obtiendrons le plus de gains en travaillant sur le premier, le deuxième ou le troisième prompt. Nous avons maintenant trois prompts indépendants et peut-être que si le plan était meilleur, la satisfaction de l'utilisateur serait en fait plus élevée. L'enchaînement améliore les performances mais surtout vous aide à contrôler votre flux de travail et à le déboguer plus harmonieusement.

Y a-t-il des problèmes de latence si la chaîne est longue ?

Si vous pensez aux versions 3.5, 4 et 4o, c'est vraiment de cela qu'il s'agit. Le modèle pré-entraîné s'améliore, et vous devriez donc voir vos performances s'améliorer sur vos tâches.

L'autre dimension est que nous pouvons réellement concevoir et exploiter le LLM d'une manière qui le rend meilleur. Vous pouvez donc simplement prompter GPT-4o, vous pouvez enchaîner certains prompts et améliorer le prompt, et cela améliorera les performances.

Vous pouvez même mettre un RAG autour, vous pouvez mettre un flux de travail agentique autour, vous pouvez même mettre un système multi-agents autour, et c'est une autre dimension pour améliorer les performances.

C'est donc ainsi que je veux que vous y pensiez. Quel LLM j'utilise, et ensuite comment puis-je maximiser les performances de ce LLM ?

Ce cours porte sur l'axe vertical. Ce sont les méthodes que nous verrons ensemble.

Ça vous va pour l'introduction ? Alors passons au prompt engineering.

Je vais commencer par une étude intéressante juste pour motiver pourquoi le prompt engineering est important.

Il y a une étude de HBS, UPenn et de la Harvard Business School qui a pris un sous-ensemble de consultants du BCG et les a divisés en trois groupes.

Un groupe n'avait pas accès à l'IA, un groupe avait accès à GPT-4, puis un groupe avait accès au LLM mais aussi à une formation sur la façon de mieux prompter.

Et ensuite, ils ont observé la performance de ces consultants sur une grande variété de tâches. Il y a quelques points qu'ils ont remarqués et que j'ai trouvés intéressants.

L'un d'eux est ce qu'ils ont appelé la frontière dentelée, ce qui signifie que certaines tâches effectuées par les consultants tombent au-delà de cette frontière, ce qui signifie que l'IA n'est pas assez bonne. Elle n'améliore pas la performance humaine. En fait, elle l'aggrave même.

Et certaines tâches sont à l'intérieur de la frontière, ce qui signifie que l'IA améliore réellement de manière significative la performance, la rapidité et la qualité du consultant.

Beaucoup de tâches tombaient à l'intérieur et beaucoup à l'extérieur, et ils ont partagé leurs observations. Mais le résumé est qu'il existe une frontière à l'intérieur de laquelle l'IA aide absolument et une autre où ils signalent ce comportement de s'endormir au volant, où les gens comptaient sur l'IA pour une tâche qui était au-delà de la frontière et en fait, cela a fini par être pire parce que l'humain ne vérifiait pas les résultats assez attentivement.

Ils ont noté que le groupe qui avait été formé était le meilleur, meilleur que le groupe qui n'avait pas été formé au prompt engineering, ce qui motive également l'importance de ce cours afin que vous fassiez partie de ce groupe par la suite.

Une autre observation concernait les centaures et les cyborgs. Ils ont remarqué que les consultants avaient tendance à travailler avec l'IA de l'une des deux manières suivantes, et vous pourriez vous-même faire partie de l'un de ces groupes.

Les centaures sont des créatures mythiques mi-humaines et mi-chevalines. Il s'agissait d'individus qui divisaient et déléguaient.

Ils pouvaient confier une tâche assez importante à l'IA. Imaginez que vous travailliez sur un PowerPoint ; vous pourriez en fait rédiger un très long prompt sur la façon dont vous voulez qu'elle fasse votre PowerPoint, puis la laisser travailler pendant un certain temps et revenir une fois que c'est fini.

Tandis que d'autres agiraient comme des cyborgs. Les cyborgs sont des robots humains totalement fusionnés, augmentés de pièces robotiques. Ces individus ne déléguaient pas entièrement une tâche ; ils travaillaient en fait très rapidement avec le modèle dans un va-et-vient constant.

Je trouve que beaucoup d'étudiants travaillent en fait plus comme des cyborgs que comme des centaures, alors qu'en entreprise, lorsqu'on essaie d'automatiser un flux de travail, on pense plus comme un centaur.

C'est juste une bonne chose à garder à l'esprit. De plus, beaucoup d'entreprises vous diront qu'elles recrutent des prompt engineers. Je n'y crois pas. Je pense que c'est juste une compétence que tout le monde devrait avoir. Vous n'allez pas faire carrière dans le prompt engineering, mais vous allez probablement l'utiliser comme une compétence très puissante dans votre carrière.

Parlons donc des principes de base de la conception de prompts. Je vous donne ici un prompt très simple : « résume ce document » et le document est téléchargé à côté.

Et le modèle n'a pas beaucoup de contexte sur ce que devrait être le résumé, sa longueur ou de quoi il devrait parler.

Vous pouvez en fait améliorer ce prompt en faisant quelque chose comme : « résume cet article scientifique de 10 pages sur l'énergie renouvelable en cinq points, en te concentrant sur les conclusions clés et les implications pour les décideurs politiques. »

C'est déjà mieux. Vous précisez l'audience et il va l'adapter à l'audience. Vous dites que vous voulez cinq points et que vous voulez vous concentrer uniquement sur les conclusions clés. C'est un meilleur prompt.

Comment pourriez-vous même améliorer ce prompt ? Quelles sont les autres techniques dont vous avez entendu parler ou que vous avez essayées vous-mêmes et qui pourraient améliorer ce prompt en un seul passage ?

Oui.

Fournis des exemples de ce à quoi ressemble un excellent résumé.

D'accord, donne des exemples. Vous voulez dire voici un exemple d'un excellent résumé. Vous avez raison, c'est une bonne idée.

Demande au modèle d'agir comme un personnage spécifique.

Technique très populaire. Agis comme un expert en énergies renouvelables donnant une conférence à Davos. C'est génial.

Quelqu'un d'autre...

Dis au modèle qu'il est le meilleur au monde pour cette tâche.

Tu es le meilleur au monde dans ce domaine, explique. Ces choses fonctionnent. C'est drôle, mais cela fonctionne de dire « agis comme XYZ ». C'est un modèle de prompt très populaire, et nous verrons quelques exemples. Quoi d'autre pourriez-vous faire ?

Oui.

Demande au modèle de critiquer son propre résultat.

Critique ton propre projet, donc tu utilises la réflexion. Tu pourrais en fait obtenir un résultat puis lui demander de le critiquer et de le retravailler. C'est une excellente technique qui fonctionne probablement mieux dans ces cas-là, mais nous verrons quelques exemples. Quoi d'autre ?

Décomposer la tâche en étapes.

Décomposer la tâche en étapes. Savez-vous comment cela s'appelle ?

Non.

Chaîne de pensée. C'est en fait une méthode populaire dont la recherche a montré qu'elle améliorait les choses. Vous pourriez en fait donner des instructions claires et encourager le modèle à réfléchir étape par étape.

Aborde la tâche étape par étape et ne saute aucune étape. Ensuite, vous lui donnez des étapes telles que étape 1 : identifie les trois conclusions les plus importantes, étape 2 : explique comment chaque conclusion impacte la politique des énergies renouvelables, étape 3 : rédige le résumé en cinq points, chaque point traitant d'une conclusion.

La chaîne de pensée est très populaire en ce moment, surtout dans les startups d'IA qui essaient de contrôler leurs LLM.

Pour en revenir à vos exemples sur « agis comme XYZ », ce que j'aime faire, c'est regarder les prompts des autres.

En fait, en ligne, vous avez beaucoup de dépôts de prompts gratuits sur GitHub. J'ai mis le lien vers le dépôt « awesome prompt template » sur GitHub où vous avez tant d'exemples de superbes prompts que des ingénieurs ont construits.

Ils les ont publiés en ligne, et beaucoup d'entre eux commencent par « agis en tant que », comme agis en tant que terminal Linux, agis en tant que traducteur anglais, ou agis comme un interviewer pour un poste.

L'avantage d'un modèle de prompt est que vous pouvez le mettre dans votre code et le mettre à l'échelle pour de nombreuses demandes d'utilisateurs. Laissez-moi vous donner un exemple de Workera.

Workera évalue les compétences et essaie de personnaliser les choses pour l'utilisateur. Dans un système RH, vous pourriez avoir Jane qui est chef de produit de niveau trois aux États-Unis et sa langue préférée est l'anglais.

Ces métadonnées peuvent être insérées dans un modèle de prompt qui personnalisera pour Jane, et de même pour Joe dont la langue préférée est l'espagnol. C'est ce qu'on appelle un modèle de prompt.

Oui.

Est-ce que les modèles de fondation utilisent des modèles de prompt en interne ?

La question est : est-ce que les modèles de fondation utilisent un modèle de prompt ou devez-vous l'intégrer vous-même ? Les modèles de fondation utilisent probablement un prompt système que vous ne voyez pas.

Par exemple, quand vous écrivez sur ChatGPT, il est possible qu'OpenAI ait en coulisses un prompt du type « agis comme un assistant très utile pour cet utilisateur » et insère vos souvenirs provenant d'une base de données.

Ensuite, votre prompt arrive en dessous et la génération commence. Ils utilisent donc probablement quelque chose comme ça, mais cela ne veut pas dire que vous ne pouvez pas en ajouter un vous-même.

En fait, si vous pensez à un modèle de prompt pour l'exemple de Workera, peut-être qu'il commence par agis comme un assistant utile et qu'en dessous il est dit « agis comme un excellent mentor en IA qui aide les gens dans leur carrière ». Le modèle de prompt d'OpenAI contient également des instructions telles que « suis les instructions du créateur ».

Des questions sur les modèles de prompts ? Encore une fois, je vous encourage à aller lire des exemples de prompts ; certains sont très bien pensés.

Parlons du prompt zero-shot par rapport au few-shot. Voici un exemple, en revenant à la catégorisation des avis sur les produits.

Disons que nous travaillons sur une tâche où le prompt est « classe le ton de cette phrase comme positif, négatif ou neutre » et ensuite vous collez l'avis : « le produit est correct, mais j'en attendais plus ».

Si je devais faire un sondage dans la salle, je parie que certains d'entre vous diraient que c'est négatif et d'autres que c'est neutre. Vous avez une première partie qui est relativement positive et ensuite la deuxième partie « j'en attendais plus » qui est relativement négative.

Cela peut être une question subjective. Dans un secteur, cela serait considéré comme incroyable et dans un autre, ce serait considéré comme vraiment mauvais. Donc, la façon dont vous pouvez aligner le modèle sur votre tâche est de convertir ce prompt zero-shot en un prompt few-shot où le modèle reçoit un ensemble d'exemples.

L'exemple ici est que vous collez à nouveau le même prompt qu'auparavant et vous ajoutez ensuite : « voici des exemples de classifications de tons. Cela a complètement dépassé mes attentes : positif. C'est correct, mais j'aimerais qu'il y ait plus de fonctionnalités : négatif. Le service était adéquat, ni bon ni mauvais : neutre. »

Maintenant, classe le ton de cette phrase. Le modèle répond alors négatif, probablement à cause du deuxième exemple que nous avons indiqué au modèle comme étant négatif.

Parce que le modèle a vu cela, il est maintenant aligné avec vos attentes. Les prompts few-shot sont très populaires. En fait, pour les startups d'IA qui sont un peu plus sophistiquées, vous pourriez les voir tenir un prompt à jour.

Chaque fois qu'un utilisateur dit quelque chose, elles pourraient demander à un humain de le labelliser et de l'ajouter comme few-shot dans leur prompt. Vous pouvez considérer cela comme la construction d'un jeu de données, mais au lieu de construire un jeu de données séparé pour le fine-tuning supervisé, vous le mettez directement dans le prompt.

Il s'avère que c'est probablement plus rapide de procéder ainsi si vous voulez expérimenter rapidement car vous ne touchez pas aux paramètres du modèle. S'il s'agit d'exemples de texte, vous pouvez concaténer de nombreux exemples dans un seul prompt.

À un moment donné, ce sera trop long et vous n'aurez pas la fenêtre de contexte nécessaire, mais c'est une approche assez solide qui permet d'aligner rapidement un LLM.

D'accord. Oui.

Existe-t-il des recherches sur la manière dont la longueur du prompt affecte les performances du modèle ?

La question était de savoir s'il existe des recherches sur la longueur que peut avoir un prompt avant que le modèle ne s'y perde. Il y en a. Le problème est que ces recherches sont obsolètes tous les quelques mois parce que les modèles s'améliorent.

Je ne sais pas où en est l'état de l'art. Sur le produit Workera, nous avons une conversation vocale où l'on vous demande d'expliquer ce qu'est un prompt et il y a un algorithme de notation derrière.

Nous savons qu'après huit tours, le modèle se perd. Après huit tours, parce que vous recollez toujours la réponse précédente, il commence à divaguer. Les techniques que nous utilisons consistent donc à créer des « chapitres » de la conversation.

Peut-être qu'un chapitre correspond aux huit premiers prompts, puis vous recommencez à partir d'un autre prompt où vous résumez la première partie de la conversation et insérez ce résumé. Ce sont des astuces d'ingénierie que les ingénieurs ont trouvées.

Parce que huit tours rendent un prompt assez long.

Passons maintenant à l'enchaînement (chaining). L'enchaînement est la technique la plus populaire parmi tout ce que nous avons vu jusqu'à présent en prompt engineering. Ce n'est pas la chaîne de pensée. La chaîne de pensée consiste à réfléchir étape par étape.

Il s'agit d'enchaîner des prompts complexes pour améliorer les performances. Vous prenez un prompt en une seule étape tel que « lis cet avis client et rédige une réponse professionnelle qui reconnaît sa préoccupation, explique le problème et propose une résolution ».

Ensuite, vous collez l'avis du client : « J'ai commandé l'ordinateur portable, il est arrivé avec trois jours de retard, l'emballage était endommagé, très décevant, j'en avais un besoin urgent pour le travail. » Le résultat est un e-mail qui vous est immédiatement donné par le LLM après avoir lu le prompt.

Cela pourrait fonctionner, mais cela pourrait être difficile à contrôler car il y a plusieurs étapes énumérées et tout est intégré dans le même prompt. Si vous vouliez déboguer étape par étape et savoir quelle étape est la plus faible, vous ne le pourriez pas.

L'un des avantages de l'enchaînement est que vous séparez les prompts afin de pouvoir les déboguer séparément, ce qui permet d'améliorer plus facilement votre flux de travail.

Disons qu'un premier prompt est « extraire les problèmes clés ». Deuxième prompt : « en utilisant ces problèmes, rédige un plan pour une réponse professionnelle qui reconnaît les préoccupations, explique les raisons possibles et propose une résolution ».

Prompt numéro trois : « en utilisant le plan, rédige la réponse professionnelle ». Vous obtenez ensuite votre résultat final.

En théorie, vous ne pouvez pas me dire au premier abord que la deuxième approche est meilleure. Mais ce que vous pouvez remarquer, c'est que nous pouvons tester ces trois prompts séparément et déterminer si nous obtiendrons le plus de gains en optimisant le premier, le deuxième ou le troisième prompt.

Nous avons maintenant trois prompts qui sont indépendants. Peut-être que si le plan était meilleur, la satisfaction de l'utilisateur par rapport à la réponse serait en fait plus élevée.

L'enchaînement améliore les performances mais surtout vous aide à contrôler votre flux de travail et à le déboguer plus harmonieusement.

Oui.

Si nous combinons les trois prompts en un seul et demandons une réflexion étape par étape, obtenons-nous la même qualité ?

Laissez-moi essayer de reformuler. Vous dites : si nous évaluons le résultat et mesurons la satisfaction de l'utilisateur, pourquoi ne pas simplement modifier ce premier prompt unique et voir comment il améliore la satisfaction ?

Oui, au lieu d'un processus en trois étapes.

Pourquoi avons-nous besoin des trois étapes ? Réfléchissez-y : le résultat intermédiaire est ce que vous voulez voir. Si je débogue la première approche, je capturerais les avis des utilisateurs, mais je ne serais pas capable de remonter facilement à la source du problème.

Dans la deuxième approche, non seulement je peux utiliser des mesures de bout en bout pour améliorer mon processus, mais je peux aussi utiliser les étapes intermédiaires. Par exemple, si je regarde le prompt deux et que je vois que le plan n'est pas génial, alors je sais que je peux obtenir beaucoup de gains en corrigeant le plan.

Ou si le plan est vraiment bon, mais que le dernier prompt ne fait pas un bon travail pour le traduire en e-mail, alors je sais que c'est sur le troisième prompt que j'obtiendrais le plus de gains.

C'est donc ce que cela me permet de faire : avoir des étapes intermédiaires à examiner.

Y a-t-il des problèmes de latence avec les chaînes longues ?

Nous allons en parler. Y a-t-il des problèmes de latence ? Oui. Dans certaines applications, vous ne voulez pas utiliser une longue chaîne car cela ajoute de la latence. Bon point.

En pratique, voici à quoi ressemble l'enchaînement de prompts complexes. Vous avez votre premier prompt, il produit un résultat, et ce résultat est collé dans le deuxième prompt, puis ce résultat est collé dans le troisième prompt. C'est à cela que cela ressemble en pratique.

Nous parlerons plus tard du test de vos prompts. Il existe maintenant des méthodes pour le faire et nous verrons avec notre étude de cas comment nous pouvons tester nos prompts.

Voici un exemple de la façon dont vous pourriez procéder. Vous pourriez avoir un flux de travail de résumé de base qui est un prompt unique. Vous pourriez avoir un flux de travail de résumé affiné avec une chaîne.

Ensuite, vous avez votre cas de test et le résultat généré, et vous pouvez demander à des humains d'évaluer ces résultats. Bien sûr, cette approche manuelle prend du temps, mais c'est une bonne façon de commencer. Le travail pratique vous donne une meilleure intuition sur les ajustements qui mènent à de meilleures performances.

Cependant, si vous vouliez passer à l'échelle sur de nombreux produits, vous pourriez vouloir trouver un moyen de le faire automatiquement sans demander à des humains de noter les résumés.

Une approche consiste à utiliser des plateformes comme Promptfoo qui vous permettent d'automatiser une partie de ces tests.

En résumé, cela peut vous permettre de lancer le même prompt avec cinq LLM différents immédiatement et de tout mettre dans un tableau qui facilite la notation par un humain.

Alternativement, cela pourrait vous permettre de définir des juges LLM. Par exemple, je peux avoir un juge LLM qui effectue une comparaison par paires entre deux résumés pour me dire lequel est le meilleur.

Une autre façon de faire appel à un juge LLM est la notation d'une réponse unique, où vous évaluez un résumé de un à cinq.

Vous pouvez aller encore plus loin et utiliser une grille d'évaluation (rubric). Vous dites : « un cinq, c'est quand un résumé fait moins de 100 caractères, mentionne au moins trois points clés distincts et commence par une vue d'ensemble ». Zéro, c'est quand le LLM ne parvient pas à résumer ou est très verbeux.

Vous pouvez maintenant combiner différentes techniques, comme l'utilisation du few-shot pour la grille d'évaluation en donnant des exemples de copies notées cinq sur cinq. Est-ce que cela a du sens ?

C'était la section sur le prompt engineering. Maintenant, disons que vous avez épuisé toutes vos chances avec le prompt engineering et que vous envisagez de toucher réellement au modèle ou de faire du fine-tuning.

Je vous ai dit que je n'étais pas fan du fine-tuning. Il y a plusieurs raisons à cela. Premièrement : cela nécessite une quantité importante de données étiquetées. Les modèles affinés peuvent également faire du surapprentissage (overfitting) sur des données spécifiques, perdant ainsi leur utilité générale.

Vous pourriez affiner un modèle et vous apercevoir qu'il ne répond plus bien aux questions génériques. C'est aussi long et coûteux.

Chez Workera, nous nous éloignons du fine-tuning car le temps de terminer, le modèle suivant est déjà sorti et surpasse votre version affinée du modèle précédent.

L'avantage du prompt engineering est que vous pouvez mettre le prochain meilleur modèle pré-entraîné directement dans votre code et cela mettra tout à jour. Le fine-tuning ne fonctionne pas comme ça.

Il y a des avantages là où cela reste logique si la tâche nécessite des résultats de haute précision répétés, comme des explications juridiques ou scientifiques, et si le LLM polyvalent a du mal avec le langage spécifique au domaine.

Regardons un exemple rapide de Ross Lazarevitz de septembre 2023 où Ross a essayé de faire un « fine-tuning Slack ».

Il a examiné de nombreux messages Slack au sein de son entreprise et a pensé qu'il allait affiner un modèle qui parle ou fonctionne comme eux parce que ces données représentent la façon dont les gens travaillent dans l'entreprise.

Il a affiné le modèle et lui a donné un prompt pour « écrire un article de blog de 500 mots sur le prompt engineering » et le modèle a répondu « Je m'en occuperai demain matin ».

Lorsqu'il a insisté auprès du modèle, en disant « c'est le matin maintenant », le modèle a dit « J'écris en ce moment même, il est 6h30 ici ». Puis il a dit « En fait, je ne sais pas ce que vous aimeriez que je dise sur le prompt engineering. Je ne peux que décrire le processus. »

C'est un exemple amusant de fine-tuning qui tourne mal. Il voulait que le modèle parle comme eux au travail et il a fini par agir comme des humains au lieu de suivre les instructions.

C'est un exemple de la raison pour laquelle je m'éloignerais du fine-tuning.

Parlons des RAG. Il est important d'en connaître les bases. C'est une question d'entretien très courante. J'espère qu'après cela, vous serez capable d'expliquer ce qu'est un RAG.

Nous avons vu certains des défis des LLM autonomes, notamment la fenêtre de contexte restreinte, les lacunes de connaissances et les hallucinations. Dans des domaines comme le diagnostic médical, vous ne pouvez pas vous permettre une hallucination.

Il y a aussi un manque de sources. De nombreux domaines comme l'éducation ou le droit adorent les sources. Le LLM pré-entraîné ne fait pas un bon travail de sourçage et invente même de faux articles de recherche.

Comment résoudre cela avec un RAG ? Le RAG s'intègre à des sources de connaissances externes comme des bases de données ou des documents. Il garantit que les réponses sont plus précises, à jour et fondées.

Votre disque dur est toujours à jour, donc quand vous demandez « quelle est notre performance au T4 », il y a avec un peu de chance la dernière présentation du conseil d'administration sur le disque et il peut la lire.

Les RAG permettent une personnalisation ciblée sans réentraîner le modèle. En fait, vous ne touchez pas au modèle avec les RAG. C'est une technique qui est placée au-dessus du modèle.

Pour voir un exemple, voici une application de questions-réponses dans le domaine médical où un utilisateur demande « quels sont les effets secondaires du médicament X ? »

On ne peut pas halluciner et on doit être à jour, donc un RAG est un excellent exemple de ce qu'on voudrait utiliser ici.

La façon dont cela fonctionne est que vous avez votre base de connaissances de documents. Vous utilisez une intégration (embedding) pour représenter ces documents dans des représentations de dimension inférieure.

Si la représentation est trop petite, vous perdrez des informations. Si elle est trop grande, vous ajouterez de la latence. Vous stockez ces représentations dans une base de données vectorielle.

Une base de données vectorielle stocke ces vecteurs efficacement, permettant une récupération rapide avec une mesure de distance.

Vous intégrez également le prompt de l'utilisateur et lancez un processus de récupération pour trouver les documents pertinents en fonction de la distance entre ces intégrations.

Une fois que vous avez trouvé les documents pertinents, vous les ajoutez à la requête de l'utilisateur avec un modèle de prompt tel que « réponds à la requête de l'utilisateur en te basant sur cette liste de documents. Si la réponse n'est pas dans les documents, dis que tu ne sais pas ».

Le résultat est désormais ancré dans le document. Vous pouvez également ajouter « indique-moi la page exacte, le chapitre et la ligne du document qui était pertinent ».

Des questions sur les RAG ? C'est un RAG standard tout simple.

Est-ce que les intégrations de documents conservent des informations sur l'emplacement des éléments sur la page ou dans le paragraphe ?

Excellente question. Vous avez raison de dire qu'un RAG standard pourrait ne pas faire du bon travail avec des documents très volumineux.

Si vous avez une boîte de médicaments avec une notice gigantesque, un RAG standard pourrait ne pas suffire.

Ce que les gens ont trouvé, c'est une série de techniques comme le découpage (chunking). Vous pourriez stocker l'intégration du document complet ainsi qu'un vecteur au niveau du chapitre.

Lors de la récupération, vous récupérez le document et le chapitre, ce qui vous permet d'être plus précis dans le sourçage.

Une autre technique est HyDE, intégrations de documents hypothétiques. Les chercheurs ont montré qu'un problème est que la requête de l'utilisateur ne ressemble souvent pas à vos documents.

Comment garantir que le vecteur d'une question courte d'utilisateur sera proche de l'intégration d'un long document ?

Ce qu'ils font, c'est qu'ils utilisent la requête de l'utilisateur pour générer un faux document halluciné. Ils intègrent ce document puis le comparent au vecteur dans la base de données.

Par exemple, si l'utilisateur demande des effets secondaires, un prompt génère un faux rapport de cinq pages répondant à la requête. Vous intégrez cela, et ce sera probablement plus proche du document réel que vous recherchez.

Le but de ce cours n'est pas de passer en revue chaque méthode, mais je voulais vous montrer l'ampleur des recherches effectuées sur les RAG depuis 2020.

L'article de synthèse est lié dans les diapositives. J'espère que vous avez maintenant l'impression de savoir comment faire de meilleurs prompts, chaînes, fine-tuning et récupération.

La prochaine série de sujets porte sur la manière dont nous pourrions étendre les capacités de tâches uniques à des flux de travail autonomes en plusieurs étapes.

C'est là que nous entrons dans l'IA agentique. Nous parlerons des flux de travail d'IA agentiques, puis des évaluations, des systèmes multi-agents et des réflexions sur la suite de l'IA. Andrew Ng a inventé le terme « flux de travail d'IA agentiques » car de nombreuses entreprises utilisent le terme « agent » pour désigner des choses très différentes. Andrew dit appelons cela des flux de travail agentiques car en pratique, il s'agit d'un ensemble de prompts avec des outils, des ressources supplémentaires et des appels d'API qui sont mis dans un flux de travail. Tout repose sur le processus en plusieurs étapes pour accomplir une tâche. Cela nous permet également de ne pas le confondre avec la définition d'« agent » dans l'apprentissage par renforcement. Voici un exemple : un utilisateur demande « puis-je obtenir un remboursement ? ». Dans un RAG classique, la réponse dit « les remboursements sont disponibles sous 30 jours ». Au lieu de cela, un flux agentique récupère la politique, recontacte l'utilisateur pour un numéro de commande, interroge une API et confirme le remboursement. C'est beaucoup plus réfléchi.

Je ne suis pas fan de mettre un visage derrière ces choses ; je trouve que c'est un gadget. Dans quelques années, très peu de produits auront un visage humain derrière eux ; c'est plus effrayant qu'engageant.

Je veux parler du changement de paradigme. Le génie logiciel passe d'une mentalité déterministe à une mentalité floue (fuzzy). Le logiciel traditionnel traite des données structurées dans une base de données. Désormais, les entreprises manipulent du texte libre et des images, ce qui nécessite une interprétation dynamique.

Le logiciel flou crée de nombreux problèmes. Si vous laissez un utilisateur demander n'importe quoi sur votre site web, les chances que cela plante sont énormes. L'ingénierie floue est vraiment difficile.

Il faut un état d'esprit spécialisé pour faire de l'ingénierie floue tout en sachant quand on doit être déterministe. Avec les logiciels d'IA agentiques, vous voulez penser comme un gestionnaire.

Si vous déléguiez votre produit à un groupe d'humains, quels seraient leurs rôles ? Auriez-vous un graphiste puis un responsable marketing ? C'est ainsi que l'on conçoit un logiciel d'IA agentique.

L'équivalent traditionnel pourrait être d'avoir une boîte d'ingénieur de données et une boîte d'UI/UX. Les tests et le débogage sont également très différents.

Le coût de l'expérimentation diminue, donc les gens devraient être plus à l'aise à l'idée de jeter du code. Cela présente des avantages pour la rapidité mais des inconvénients pour la qualité du logiciel.

Je vais vous donner un exemple de Workera. Parfois, l'interface pose des questions à choix multiples, qui sont des types d'éléments déterministes avec une seule bonne réponse.

D'un autre côté, vous avez des questions vocales ou de codage qui sont floues. L'algorithme de notation peut faire des erreurs. Nous avons une fonction d'appel avec humain dans la boucle à la fin pour que les utilisateurs puissent contester l'agent. Ensuite, vous faites intervenir un humain qui peut dire à l'agent s'il a été trop sévère. Si vous créez une entreprise, réfléchissez à ce qui peut être fait avec déterminisme et où vous voulez utiliser des interactions floues avec des garde-fous.

Voici un autre exemple de McKinsey où une institution financière met des semaines à créer un mémo de risque de crédit parce qu'un gestionnaire rassemble des données provenant de 15 sources et qu'un analyste écrit pendant 20 heures.

Ils ont découvert que les agents GenAI pouvaient réduire le temps de 20 à 60 %. Le gestionnaire fournit les documents, l'agent subdivise les tâches, rassemble les données et rédige un mémo pour révision.

Vous ne changez pas les parties prenantes, juste le processus. Les grandes entreprises redessinent actuellement les flux de travail, mais changer les gens prend des années. Il faudra 10 ou 20 ans pour que cela soit fait à grande échelle au sein des organisations parce que le changement est très difficile.

Parlons des composants essentiels d'un agent. Un agent d'IA de réservation de voyage possède des prompts et un système de gestion de contexte pour la mémoire. La mémoire comprend la mémoire de travail et la mémoire archivistique.

La mémoire de travail doit être rapide car l'agent l'utilise à chaque fois qu'il vous parle. La mémoire archivistique sert aux choses dont il n'a pas besoin tous les jours. Ensuite, vous avez des outils comme la recherche de vols ou les API météo. Les LLM sont très doués pour lire la documentation des API.

Anthropic parle également de ressources, qui sont des données situées quelque part que vous laissez votre agent lire. Vous donnerez probablement au modèle un outil de recherche pour accéder à cette ressource.

Cette architecture peut avoir différents degrés d'autonomie. Moins autonome signifie des étapes codées en dur. Semi-autonome signifie que vous codez les outils mais pas les étapes. Le plus autonome est celui où l'agent décide des étapes et peut même créer des outils à l'aide d'un éditeur de code.

Vous avez peut-être entendu parler de MCP ou Model Context Protocol. Dans le cas de l'API, vous apprenez à votre LLM à interroger une API en lui donnant la documentation, ce qui ne passe pas bien à l'échelle. Le MCP place un système au milieu qui simplifie la communication de votre LLM avec un point de terminaison en utilisant une communication d'agent à agent. Vous n'avez pas besoin de tout coder en dur.

Ce changement n'est-il pas comme réécrire n'importe quelle hypothèse exacte en logiciel ? Si je change l'API, le MCP doit maintenant changer.

Vous avez raison, si une API est mise à jour, le MCP doit être mis à jour. Mais cela permet à l'agent de faire des allers-retours pour comprendre les besoins. Ce n'est pas totalement autonome, mais c'est plus efficace.

Le MCP devient-il un problème de sécurité ? Pourquoi exactement voulez-vous exposer votre base de données ?

L'exposition des données répond à des exigences différentes, mais je pense que beaucoup de MCP ont une authentification et nécessitent une clé. Je ne suis pas un expert en sécurité de ces systèmes, mais nous pourrons nous pencher sur la question.

La mémoire n'est pas non plus un problème résolu ; c'est assez difficile à mettre en place.

Vous n'avez pas besoin d'un MCP pour communiquer, n'est-ce pas ? Un MCP facilite simplement l'accès à l'API.

Exactement. Le MCP est une question d'efficacité. Un agent peut communiquer très efficacement avec plusieurs serveurs MCP. Vous contrôlez toujours les données qui sont exposées, même si le serveur MCP doit être robuste car il reçoit des entrées d'un autre LLM.

Voici un exemple de flux de travail d'un agent de voyage. Étape 1 : l'utilisateur donne une tâche. Étape 2 : l'agent planifie les étapes comme la recherche de vols et la validation du budget. Étape 3 : exécution du plan. Étape 4 : mise à jour de la mémoire. La prochaine fois, je ne proposerai que des vols directs car je viens d'apprendre que l'utilisateur les préfère.

Comment sauriez-vous si cela fonctionne et comment l'amélioreriez-vous ?

Laisser les utilisateurs évaluer leur expérience.

C'est un test de bout en bout. Si un utilisateur donne une mauvaise note, comment amélioreriez-vous le flux de travail ?

Regarder les différentes options et voir précisément ce que l'utilisateur n'a pas aimé.

Évaluer votre flux de travail en séparant ce qui est déterministe et là où vous utilisez un prompt.

Vous pouvez construire des évaluations objectives. Si le LLM propose un vol plus cher alors qu'un moins cher est disponible, vous pouvez le détecter. Pour les choses subjectives, comme choisir entre le confort et le prix, vous pouvez construire un ensemble de données de préférences utilisateur et voir si l'agent les comprend.

Qu'en est-il du ton ? Si le LLM n'est pas amical, comment le corriger ?

Avoir quelques cas de test en utilisant un autre LLM comme juge pour évaluer la réponse.

Je suis d'accord. Vous pourriez utiliser un juge LLM avec une grille d'évaluation pour la politesse. Vous pourriez également faire fonctionner trois LLM différents côte à côte pour voir quel modèle est le plus poli en moyenne. Vous pouvez corriger le LLM et changer le prompt pour voir l'influence de mots comme « serviable ».

Faisons une étude de cas. Un chef de produit vous demande de construire un agent d'IA pour le support client. Par quoi commencez-vous ?

Faire des recherches sur les modèles existants et en choisir un en fonction des performances dans le support client.

Faire d'abord une décomposition de la tâche en tâches plus petites.

Je m'assiérais avec le support client pour voir comment ils effectuent la tâche et j'essaierais d'optimiser ce processus.

Je recommande la décomposition des tâches. Un agent humain extrairait les infos, consulterait la base de données, vérifierait la politique et rédigerait une réponse. Comment concevez-vous votre flux de travail agentique autour de cela ?

Définir quelles tâches sont déterministes et lesquelles utilisent un prompt, puis évaluer chacune d'elles.

Exactement. L'extraction d'informations peut être un LLM classique. La consultation de la base de données nécessitera un outil ou un MCP. La rédaction de l'e-mail nécessitera un LLM. Enfin, il faut un outil pour envoyer l'e-mail. Pour savoir si cela fonctionne, il faut des traces LLM. C'est une partie fondamentale de la pile d'une startup d'IA. Vous pouvez regarder la satisfaction utilisateur de bout en bout ou adopter une approche par composants pour voir si un outil spécifique échoue. Vous pouvez également distinguer les erreurs objectives, comme l'extraction d'un mauvais ID de commande, et les erreurs subjectives comme les décalages de ton. Les évaluations quantitatives suivent les taux de réussite et la latence, tandis que les évaluations qualitatives utilisent l'analyse d'erreurs pour examiner les hallucinations.

Dernière section : flux de travail multi-agents. Pourquoi avons-nous besoin de plusieurs agents ? L'avantage principal est le parallélisme et la réutilisation. Un agent construit pour le design peut être utilisé par les équipes marketing et produit. Disons que vous construisez une automatisation de maison intelligente. Quels agents voudriez-vous construire ? Prenez une minute pour y réfléchir.

J'aurais un agent qui suit les mouvements, un agent qui ajuste la température et l'éclairage, un agent qui suit l'utilisation des appareils, et un orchestrateur pour tous.

Je pense que l'orchestrateur transmet les instructions aux autres agents pour l'utilisateur.

D'accord, donc si je veux que le four soit préchauffé, je parle à l'orchestrateur. C'est un système multi-agents hiérarchique. Quoi d'autre ?

Attendez, et pour la sécurité de l'IdO ? Selon la personne, on a accès à des actions minimales, comme juste ouvrir le frigo. On pourrait avoir des agents pour chaque tâche domestique et le contexte détermine ce qu'on peut faire.

Un agent de sécurité qui donne des permissions selon que l'on soit un parent ou un enfant. J'aime bien ça. Quoi d'autre ?

On peut lier les économies d'énergie avec les réglages d'ambiance en suivant les capteurs de température extérieure et le moment de se brancher sur le réseau. J'ai aussi pensé à un agent pour suivre les produits au supermarché pour comprendre ce qu'il y a dans le frigo.

Super. Un agent pour les API externes comme la météo peut influencer la température intérieure. Un autre agent peut regarder dans le frigo avec une caméra et commander des courses à l'avance. Ce sont tous de bons exemples. Les modèles d'interaction peuvent être plats ou hiérarchiques. Un système hiérarchique est souvent préférable pour l'UI/UX afin que l'utilisateur n'ait qu'à parler à l'orchestrateur. On traite les agents comme des outils en utilisant le protocole MCP.

Nous avons appris de nombreuses techniques. Je tiens à souligner quelques tendances. Ilya Sutskever a soulevé la question de savoir si nous stagnons. Bien que les lois d'échelle suggèrent des améliorations avec plus de calcul, nous avons également besoin de recherche architecturale. Les Transformers ne sont pas la seule voie ; une nouvelle architecture pourrait réduire les besoins de calcul d'un facteur 10. La multimodalité est un autre domaine. Être bon en images et en texte rend l'ensemble du modèle meilleur. Maintenant, nous ajoutons l'audio ou la vidéo. Nous nous dirigeons vers le sommet de la robotique. La combinaison de différentes méthodes d'apprentissage — supervisé, non supervisé et par renforcement — est également la tendance. Les recherches de Stanford explorent des approches centrées sur l'humain modelées sur le cerveau et des approches non centrées sur l'humain. La vitesse est élevée, donc la demi-vie d'une compétence est courte. Ressortez avec une bonne vue d'ensemble et approfondissez chaque fois que vous en aurez besoin après le cours. Merci de votre participation.