Dans cet épisode enrichissant du podcast What’s AI, j’ai eu, moi, Louis-François Bouchard, une excellente conversation avec Jerry Liu, le PDG de LlamaIndex. Nous explorons les complexités et les défis de la technologie de l’IA en nous concentrant sur la génération augmentée par la recherche, ou Retrieval Augmented Generation (RAG), l’importance d’une excellente documentation et le potentiel des modèles multimodaux émergents comme Gemini.
Jerry nous fait profiter de son expertise sur la gestion de divers formats de données, particulièrement le défi constant du traitement des PDF. Il explique comment les modèles multimodaux pourraient offrir des solutions révolutionnaires à ces problèmes de longue date. Nous abordons aussi le rôle essentiel d’une documentation claire et complète dans l’industrie de la tech. En s’appuyant sur son expérience chez LlamaIndex, Jerry souligne l’importance de créer une documentation qui ne se contente pas d’informer, mais qui propose aussi un parcours de développement aux développeurs, des concepts de base jusqu’aux applications avancées de l’IA.
Notre conversation plonge au cœur du monde du RAG, où Jerry explique sa simplicité, son efficacité et son côté pratique, particulièrement pour les applications d’entreprise. Il compare le RAG au fine-tuning des modèles afin de nous aider à déterminer « quand utiliser lequel ». Cette discussion est particulièrement éclairante pour les personnes qui implémentent et optimisent des applications basées sur les LLM.
Nous explorons aussi les aspects techniques des stratégies de chunking et de la qualité des données dans les systèmes RAG. Les réflexions de Jerry sur les modèles d’embedding, le fine-tuning pour des domaines précis et l’optimisation des processus de recherche sont inestimables pour toute personne qui souhaite implémenter ou améliorer des systèmes RAG dans ses projets.
Ma conversation avec Jerry rend des concepts complexes de l’IA accessibles à un vaste public, que vous soyez profondément ancré dans le domaine de l’IA ou que vous commenciez tout juste à en explorer les possibilités.
N’oubliez pas de laisser un like ou une évaluation de 5 étoiles pour soutenir le podcast ! Si vous trouvez cet épisode aussi éclairant que moi, partagez-le avec vos amis et collègues qui souhaitent rester au courant des plus récents développements en IA. La transcription française complète se trouve ci-dessous. L’épisode original reste offert sur Spotify et Apple Podcasts.
Transcription complète :
Jerry Liu : [00:00:00] Je pense que Gemini est, est très prometteur. C’est un modèle multimodal. Si vous regardez certaines vidéos de démo, il entrelace le texte, l’image, la vidéo, le raisonnement et l’audio. L’un des aspects prometteurs est la multimodalité. L’autre aspect semble être la latence, qui est plutôt faible. Je pense que ce qui m’enthousiasme n’est pas nécessairement.
De savoir s’il surpasse complètement GPT 4. Pour l’instant, d’après ce que j’ai vu, il semble offrir, comme, une amélioration progressive, mais pas nécessairement, comme, un changement radical. Quand on y pense, le RAG est essentiellement du prompt engineering, parce que vous cherchez essentiellement une façon d’insérer du contexte dans le prompt.
C’est simplement une façon programmatique de faire du prompt engineering. Si nous pensons que le RAG fera mieux que cela, nous pouvons le voir comme une façon de faire du prompt engineering. C’est une façon de prompter qui vous permet de récupérer du contexte.
Louis-François Bouchard : Ici Louis-François pour le podcast What’s AI. Dans cet épisode, je reçois Jerry Liu, cofondateur et PDG de LlamaIndex. LlamaIndex se trouve au cœur de l’industrie [00:01:00] du RAG, qui signifie Retrieval Augmented Generation, ou génération augmentée par la recherche. Il s’agit essentiellement de combiner de grands modèles de langage à vos propres données. Dans cette entrevue, nous parlons beaucoup du RAG et des LLM.
Jerry partage beaucoup de conseils très concrets sur la façon d’améliorer votre système RAG ou LLM actuel. Je suis certain que cet épisode vous apportera beaucoup. S’il vous plaît, si vous l’aimez, n’oubliez pas de le partager avec vos amis et de laisser une évaluation de cinq étoiles ou un like, selon la plateforme sur laquelle vous écoutez cet épisode.
Entrons tout de suite dans le vif du sujet.
Jerry Liu : Bonjour à tous, je m’appelle Jerry. Je suis le cofondateur et PDG de Llama Index. Pour ceux d’entre vous qui ne le savent pas, LlamaIndex est un framework et une plateforme de données qui vous aident à construire des applications LLM sur vos données. Je suis vraiment heureux d’être ici. Merci pour l’invitation.
Louis-François Bouchard : Bien sûr. Merci.
Merci d’être ici. Avant de parler de LlamaIndex et de tous les sujets intéressants, pourriez-vous nous en dire un peu plus ? Quand et comment êtes-vous entré dans le domaine ?
Jerry Liu : Oui, alors, j’ai essentiellement travaillé dans le domaine de l’IA pendant la majeure partie de ma carrière. J’ai obtenu mon diplôme en [00:02:00] 2017 et, à l’époque, je jouais avec les premières itérations des modèles génératifs.
Il s’agissait des GAN, donc des réseaux antagonistes génératifs. Pour les auditeurs qui les connaissent, ils étaient plutôt rudimentaires à l’époque. Et je me souviens d’avoir été vraiment impressionné par le fait que, vous savez, on pouvait essentiellement générer des chambres, ou, ou simplement des rendus de chambres en 64 par 64 avec ces modèles très simples.
J’ai donc mené quelques recherches de base en deep learning pour essayer d’entraîner certains de nos propres GAN, puis j’ai étendu le tout à un contexte 3D. Et c’est en quelque sorte ce qui m’a amené dans l’ensemble du domaine de l’IA. N’est-ce pas ? C’est un domaine très vaste. Il y a le volet des applications, comme le ML engineering, les aspects de data science, la recherche pure en ML et, bien sûr, les outils de MLOps qui soutiennent les praticiens.
J’ai donc en quelque sorte mis les pieds dans presque tous ces trois espaces au fil de mes expériences professionnelles, mais je n’ai pas vraiment commencé à jouer avec les LLM avant la même période l’an dernier, en octobre 2022, lorsque je commençais tout juste à expérimenter avec l’API de GPT 3 pour explorer ses capacités [00:03:00].
Je comprenais le fonctionnement des modèles génératifs du point de vue théorique, disons conceptuel, mais je n’avais pas vraiment exploré tout leur potentiel applicatif. À l’époque, j’essayais simplement de bricoler quelques applications avec GPT 3. C’est à ce moment que j’ai découvert le besoin d’avoir essentiellement des outils et des abstractions pour construire des applications LLM avec mes propres données.
J’essayais de comprendre comment injecter mes propres données dans, dans, disons, GPT 3. C’est essentiellement ce qui a inspiré tout ce projet.
Louis-François Bouchard : Pour revenir un peu en arrière, pourquoi avez-vous choisi d’entrer directement dans l’industrie après votre diplôme, par exemple, plutôt que de faire une maîtrise, un doctorat ou de la recherche en IA, donc de créer des produits plutôt que de faire de la recherche ?
Jerry Liu : C’est une bonne question. Je ne pense pas que quelqu’un me l’ait déjà posée. Et, et pour être honnête, j’ai bel et bien envisagé de retourner aux études supérieures pour faire, disons, une maîtrise ou un doctorat. Mon cas est un peu particulier parce que, honnêtement, la plupart des gens, disons, si la recherche les passionnait vraiment, beaucoup de personnes à l’époque commençaient à poser leur candidature à ces programmes de résidence [00:04:00], puis à entreprendre un doctorat dans différentes universités. À l’inverse, si vous saviez en quelque sorte que vous ne vouliez pas vraiment faire de recherche, vous restiez surtout ML engineer ou vous travailliez dans un domaine appliqué.
J’aimais les deux. J’ai donc posé ma candidature au programme de résidence. J’ai été résident en IA chez Uber de 2018 à 2019. C’est d’ailleurs ainsi que j’ai rencontré mon cofondateur actuel, Simon. J’ai fait de la recherche pendant environ un an, puis cette expérience s’est prolongée pendant deux ans sous la direction de Raquel, qui dirige maintenant Waabi, mais qui dirigeait alors la recherche chez Uber R&D à Toronto sur les voitures autonomes.
J’ai donc passé une bonne période à travailler sur la recherche en deep learning, tout en décidant si je voulais poursuivre dans cette voie aux études supérieures. Mais, en même temps, ce qui me ramenait dans l’autre direction, je pense, c’est que j’aime fondamentalement bricoler des choses et réfléchir à la façon de construire des produits.
Et ça, je veux dire, vous pouvez en voir des traces dans ce que nous faisons aujourd’hui, mais, vous savez, cela m’a aussi motivé à rejoindre une startup de ML et de MLOps après mes travaux de recherche.
Louis-François Bouchard : Je suppose que vous aimez aussi la façon plus appliquée d’apprendre. [00:05:00] Oui, vous apprenez essentiellement en appliquant, je suppose, tout comme moi. Vous avez mentionné les GAN et je suis certain que vous en comprenez bien les bases.
Ma question comporte, disons, deux volets. D’abord, pour travailler avec de grands modèles de langage et les systèmes d’IA récents, que pensez-vous de la nécessité ou de l’utilité de comprendre le fonctionnement des transformers ? Et le deuxième volet, est-il également important de comprendre les bases ? Vous avez mentionné les GAN, mais aussi les, les autres réseaux neuronaux plus simples et les mathématiques derrière les modèles.
Pensez-vous que c’est nécessaire ? Est-ce utile ? Est-ce inutile ?
Jerry Liu : Je pense que c’est un peu comme comprendre l’architecture informatique. Je ne crois pas que quiconque comprenne vraiment le fonctionnement interne d’un ordinateur, à moins d’avoir fait un doctorat en génie électrique, n’est-ce pas, et de travailler directement, disons, sur les transistors.
Je pense que les gens comprendront ces choses à différents niveaux d’abstraction et que le ML offre essentiellement une profondeur infinie. En fait, même si vous regardez le [00:06:00] sous-ensemble de chercheurs qui détiennent un doctorat en machine learning, je ne pense pas que chacun d’entre eux comprenne parfaitement, ou qu’ils comprennent tous parfaitement les mathématiques théoriques, n’est-ce pas ?
À moins que vous travailliez directement en ML théorique. Alors, je, je pense qu’il est tout simplement impossible que tout le monde comprenne tout. De façon réaliste, toutefois, je dirais que si vous êtes, par exemple, un ingénieur en IA qui travaille sur des applications, vous devez en quelque sorte acquérir l’expérience utilisateur qui consiste à jouer avec des outils comme
ChatGPT. Comprendre les frameworks d’application dans leur ensemble, par exemple la génération augmentée par la recherche, les agents, donc quels, quels, quels types de cas d’usage applicatifs émergent de ces modèles, même si vous ne comprenez pas, disons, parfaitement les modèles eux-mêmes. Et je pense que vous devez aussi apprendre certaines bonnes pratiques.
Nous pouvons aussi en parler, mais je pense que la plupart des ingénieurs en IA, aujourd’hui, devraient probablement au moins comprendre l’évaluation et savoir comment vraiment benchmarker les résultats par rapport à un dataset pour des systèmes stochastiques. Du moins, pour l’instant. Et qui sait ce qui se produira lorsqu’ils s’amélioreront. Bien sûr, si vous voulez vraiment approfondir l’[00:07:00] IA afin d’essayer de fine-tuner des modèles ou de construire vos propres modèles pour apprendre cette couche supplémentaire, alors, oui, je pense qu’il est utile d’apprendre certaines bases sur, vous savez, le fonctionnement de ces modèles, les mathématiques et statistiques de base, la rétropropagation et toutes ces choses.
Louis-François Bouchard : Je voulais, je voulais approfondir ce sujet un peu plus tard dans le podcast, mais puisque nous en parlons, quelle serait, maintenant ou dans un avenir proche, la stack technologique utile à apprendre pour entrer dans le domaine ? Prenons, par exemple, une personne qui travaille dans un autre domaine ou qui étudie actuellement au collège, peu importe, et qui ne possède aucune expérience en programmation ni aucune formation en, en intelligence artificielle.
Ni dans un domaine connexe, mais elle est, elle est extrêmement intriguée par les LLM et souhaite construire, disons, une app ou travailler dans ce domaine. Que lui recommanderiez-vous d’apprendre et comment lui conseilleriez-vous de l’apprendre ?
Jerry Liu : Oui, alors je pars un peu du principe que, que cette personne sait au moins un peu programmer.
Parce que, si vous ne savez pas programmer [00:08:00], le parcours est différent. Mais si vous savez au moins un peu programmer, que ce soit en Python, en TypeScript ou même en Java, n’est-ce pas, vous pouvez au moins apprendre certaines bases. Et quelles sont ces bases ? D’abord, choisissez un grand modèle de langage. Le plus simple pour commencer est probablement OpenAI, parce que vous pouvez simplement, vous savez, obtenir une clé API et commencer à l’utiliser, lui fournir un input et récupérer un output. Fixez-vous un budget afin de ne pas dépasser, disons, la limite mensuelle, n’est-ce pas ? Comme je l’ai dit, pour éviter d’utiliser accidentellement GPT 4 et d’accumuler une facture énorme. L’étape suivante consiste à choisir une source de données ou, en fait, à choisir un cas d’usage. Pour la source de données, déterminez ce que vous voulez vraiment faire.
Voulez-vous répondre à des questions sur vos documents, vos notes de cours ou votre base de données ? Voulez-vous plutôt envoyer des messages, n’est-ce pas ? Ou construire un chatbot personnalisé doté d’une mémoire conversationnelle ? À partir de là, apprenez certains concepts de base du RAG, donc de la Retrieval Augmented Generation, ou génération augmentée par la recherche, ainsi que les agents [00:09:00], ainsi que le fonctionnement général de ces modèles.
Et pour ces, ces sujets, je recommanderais essentiellement, vous savez, un framework comme, comme LlamaIndex. Nous avons beaucoup de ressources éducatives à ce sujet, tant pour les utilisateurs débutants qu’avancés. Quant aux bases de données vectorielles ou aux systèmes de stockage en général, je pense qu’ils entrent en jeu lorsque vos exigences en matière de données deviennent plus importantes, n’est-ce pas ?
Et, bien sûr, c’est en quelque sorte au cœur de ce que nous faisons. Mais, concrètement, si vous voulez essayer de comprendre, disons, un vaste corpus de données, vous devriez choisir un outil de stockage comme une base de données vectorielle. Il existe aujourd’hui beaucoup de bases de données vectorielles. Vous avez donc beaucoup de choix.
Vous pouvez probablement en choisir une pour commencer. Ou, honnêtement, avec LlamaIndex, vous pouvez simplement utiliser notre solution in-memory très simple. Elle n’est pas scalable, mais elle fonctionne directement out of the box. Vous pouvez donc aussi l’essayer si vous le souhaitez.
Louis-François Bouchard : Je veux absolument parler du RAG, comme vous l’avez mentionné, mais il serait peut-être d’abord plus utile d’approfondir un peu LlamaIndex, simplement parce que je pense que c’est [00:10:00] un, un outil extraordinaire.
J’aimerais le démystifier un peu pour les personnes qui ne le connaissent pas bien ou qui ne savent simplement pas si, si, si elles devraient utiliser LlamaIndex, LangChain, leur propre solution ou autre chose. Alors, d’abord, selon vous, quand devrait-on utiliser LlamaIndex et qui devrait l’utiliser ?
Est-ce, disons, un outil destiné aux programmeurs ou, comme, à qui, à qui s’adresse-t-il et quand devrions-nous, devrions-nous l’utiliser ?
Jerry Liu : Oui, absolument. LlamaIndex est donc un outil pour les développeurs. Il s’adresse actuellement aux programmeurs, du moins, et nous verrons peut-être ce que nous ferons à l’avenir. Mais, à un niveau très élémentaire, il s’agit essentiellement d’un package Python ainsi que d’un package TypeScript.
Vous installez donc le package avec pip install ou npm install. Notre objectif principal en ce moment est de fournir les outils qui permettent aux développeurs de construire plus facilement des applications LLM sur leurs données. Donc, si vous avez une source de [00:11:00] données et que vous voulez construire une sorte de chatbot augmenté par les connaissances afin de pouvoir poser des questions à vos données et obtenir des réponses.
Vous pouvez utiliser LlamaIndex. LlamaIndex est actuellement très vaste. Ainsi, vous pouvez essentiellement construire avec LlamaIndex n’importe quelle application LLM que vous souhaitez, n’est-ce pas ? Si je parle d’applications LLM sur vos données, c’est parce qu’elles constituent en quelque sorte l’un des axes principaux de l’entreprise depuis, depuis quelques mois.
Cela comprend donc des choses comme le RAG, par exemple construire une sorte de chatbot sur vos données. Cela comprend aussi l’extraction de données structurées. Cela comprend l’interaction avec votre base de données SQL. Si vous voulez exécuter des analyses structurées, ce sont des cas d’usage assez populaires en entreprise.
Si vous voulez faire de la synthèse, vous pouvez aussi construire toutes sortes de choses intéressantes, comme, comme des simulations d’agents, par exemple, ou des expériences semblables à Auto-GPT dans lesquelles vous pouvez, vous savez, avoir une conversation avec, avec, avec ce chatbot et, et conserver en quelque sorte l’historique de la conversation [00:12:00]. Nous n’avons pas investi autant d’efforts dans ce domaine.
Pour ce qui est du support de premier ordre, donc des abstractions de plus haut niveau, mais vous pouvez certainement le construire. Et une, une question que les gens se posent peut-être est de savoir quand utiliser LlamaIndex, appeler directement l’API d’OpenAI ou écrire leurs propres outils. Cela dépend vraiment du temps dont vous disposez.
Et je pense que le temps, le temps est une ressource précieuse aujourd’hui. Je pense qu’il faut simplement plus de boilerplate pour mettre en place beaucoup de ces abstractions et les rendre robustes, comparativement à l’utilisation de certains de nos outils. Nous avons aussi beaucoup de matériel éducatif directement dans nos modules pour montrer quand utiliser certains modules selon les cas d’usage, tant pour les applications simples que pour les applications avancées.
Louis-François Bouchard : Pourriez-vous nous expliquer rapidement les, les différences ou vos avantages comparativement, par exemple, à LangChain ou, oui. À l’entraînement à partir de zéro. Pas l’entraînement, mais la construction à partir de zéro, comme vous, comme vous l’avez dit. Et enfin, le récent produit Assistants d’OpenAI. Quand, quand devrait-on utiliser LlamaIndex [00:13:00], ou quelle est la, la particularité ou l’avantage d’utiliser LlamaIndex plutôt que toutes ces solutions ?
Jerry Liu : Oui, je pense avoir parlé brièvement de la construction de votre propre solution à partir de zéro. Et, et pour ce qui est des différences entre LlamaIndex et LangChain, c’est une question très populaire. Je pense, vous savez, que nous sommes tous deux des frameworks. Au bout du compte, vous pouvez essentiellement construire ce que vous voulez avec l’un ou l’autre.
Je dirais que LangChain a investi de façon un peu plus large dans une variété de choses. Je pense que nous nous sommes concentrés très précisément sur les abstractions d’outils qui permettent de construire différents éléments autour de vos données. Et l’un des frameworks les plus populaires est probablement le RAG. Nous voyons beaucoup de ces abstractions comme de simples extensions du RAG qui offrent essentiellement des fonctions encore plus avancées de recherche et d’analyse sur vos données.
Cela comprend donc, vous savez, les chatbots. Lorsque nous pensons aux agents, nous les envisageons généralement dans un cas d’usage d’analyse de données. Nous essayons donc de rendre nos abstractions très personnalisables pour l’utilisateur avancé, mais aussi très out of the box et faciles à utiliser pour l’utilisateur débutant. Voilà donc notre objectif principal. [00:14:00]
Et, et notre façon de voir les différences. Quant à l’API Assistants d’OpenAI, oui, elle est, elle est bonne. Je veux dire, je pense qu’ils ont lancé beaucoup de fonctionnalités pendant le DevDay, et je suis certain que vous m’en parlerez davantage dans un instant. Mais l’API Assistants en particulier, pour l’expliquer aux auditeurs, est essentiellement une expérience d’agent hébergée capable d’effectuer la recherche à l’interne, d’utiliser Code Interpreter et d’appeler des fonctions pour tous les outils que vous lui fournissez.
En fait, je pense que c’est assez complémentaire, parce qu’au bout du compte, nous voulons vraiment nous concentrer sur d’excellentes expériences de recherche dans vos données. Nous avons d’ailleurs un wrapper de l’API Assistants qui agit comme un agent. Et nous montrons que vous devriez simplement utiliser les pipelines RAG de LlamaIndex comme outils dans cette API Assistants.
Ainsi, l’API Assistants peut effectuer des appels de fonctions sur ce que vous avez construit avec LlamaIndex. Utilisez donc LlamaIndex pour cela. Par exemple, indexez vos données, n’est-ce pas ? Vos divers corpus de données. Leur propre API de recherche demeure actuellement assez rudimentaire. Je ne la recommanderais [00:15:00] pas pour autre chose qu’un cas d’usage de démonstration.
Alors, vous savez, utilisez les capacités que nous offrons sur vos données, branchez-les dans l’API Assistants, l’agent, puis voyez ce qui se passe.
Louis-François Bouchard : Je suppose qu’un autre avantage est que vous pouvez, oui, utiliser les API d’OpenAI pour, pour faire ce que vous voulez, mais qu’elles plantent parfois, et même souvent. Vous pouvez donc certainement, facilement, pas facilement, mais vous pouvez, disons, si, si votre requête à l’API d’OpenAI plante, interroger un autre modèle de langage, qu’il soit le vôtre, dans le cloud ou, ou, ou autre.
Je suppose donc que l’utilisation de quelque chose d’externe à OpenAI, comme LlamaIndex, offre aussi un avantage important.
Jerry Liu : Oui, exactement. De façon générale, il y a la question plus vaste de savoir à quoi sert LlamaIndex si OpenAI, vous savez, lance toutes ces fonctionnalités. Pour y répondre, essentiellement, comme vous l’avez dit, vous savez, le domaine est très concurrentiel [00:16:00].
Gemini vient d’être lancé au moment de cet enregistrement, n’est-ce pas ? Bien sûr, il y a aussi beaucoup de concurrence dans le monde open source. Ce que nous avons constaté chez beaucoup d’utilisateurs, c’est qu’ils veulent du choix et de bons compromis. Ils veulent donc éviter, vous savez, le vendor lock-in afin de pouvoir choisir, par exemple, de brancher un modèle open source avec OpenAI pour différents cas d’usage.
Et les frameworks vous permettent essentiellement de le faire très facilement et de gagner du temps lorsque vous essayez ces différentes abstractions. Vous avez mentionné
Louis-François Bouchard : Gemini, et je voulais justement aussi en parler avec vous, parce que vous, vous venez, vous avez récemment publié quelque chose sur Gemini en partageant vos observations et, et vos réflexions. J’aimerais beaucoup savoir ce que vous pensez de, de Gemini.
Pensez-vous qu’il s’agit d’une avancée importante ou qu’il, qu’il ne concurrencera même pas GPT 4 ? J’ai vu qu’ils n’avaient même pas encore lancé le, le modèle plus grand, Turbo, ou je ne me souviens plus du nom, mais ils n’ont pas encore lancé de modèle plus grand. Alors oui, [00:17:00] que pensez-vous de Gemini ?
Jerry Liu : Oui. Pour vous donner rapidement un peu de contexte, j’en sais à peu près autant que vous. Mon tweet venait littéralement de ma lecture du billet de blogue.
Mais, en principe, d’après ce billet, je pense que Gemini est, est très prometteur. C’est un modèle multimodal, selon ce qu’ils ont publié. Si vous regardez certaines vidéos de démo, il entrelace le texte, l’image, la vidéo, le raisonnement et l’audio. L’un des aspects prometteurs est la multimodalité. L’autre semble être sa latence, qui est plutôt faible.
Je pense que ce qui m’enthousiasme. Ce n’est pas nécessairement de savoir s’il, s’il surpasse complètement GPT 4. Pour l’instant, d’après ce que j’ai vu, il semble offrir une amélioration progressive, mais pas nécessairement un changement radical dans les aspects, disons, du raisonnement purement textuel. Ce qui m’enthousiasme, c’est.
De rendre les éléments multimodaux pratiques et faciles à utiliser. Aujourd’hui, lorsque vous construisez des apps multimodales, vous assemblez un ensemble de composants très disparates qui ne sont pas optimisés de bout en bout. Vous assemblez, disons, un LLM, comme un GPT [00:18:00]. Vous ajoutez un service de text-to-speech, n’est-ce pas ? Puis un service de speech-to-text.
Puis vous, vous l’utilisez pour essayer, disons, de faire circuler les conversations dans les deux sens. Un problème important dans beaucoup de ces applications, pas seulement l’audio, mais aussi l’image et la vidéo, est la latence et la vitesse, ainsi que la nécessité de disposer d’un bon pipeline de bout en bout. Je pense donc que, si Gemini peut réellement devenir un modèle universel capable de traiter et d’analyser beaucoup de données très rapidement, il offre un potentiel très prometteur pour des cas plus avancés.
Des cas d’usage RAG, n’est-ce pas ? Et je pense que cela nous enthousiasme beaucoup. Mais aussi, vous savez, des cas d’usage agentiques en général. Les cas d’usage RAG comprennent des capacités comme l’analyse de graphiques et de tableaux dans un document, le traitement de sites Web et l’extraction de données structurées d’une façon plus efficace qu’avec le simple traitement de texte.
Nous sommes aussi enthousiasmés, par exemple, par la possibilité d’effectuer une sorte de captioning augmenté de capteurs. À partir d’une vidéo, vous pouvez simplement générer beaucoup de texte [00:19:00], n’est-ce pas, et avoir une conversation. Vous pouvez aussi, en quelque sorte, simplement indexer votre propre corpus de connaissances interne.
Ainsi, ce que vous indexez ne se limite pas aux données textuelles, mais comprend aussi les images, les vidéos, l’audio et d’autres éléments. Je pense que cela prendra probablement plus d’importance à l’avenir. Nous l’avons vu, je pense, avec les modèles open source, et, et vous avez déjà réalisé des progrès considérables dans ce domaine, mais il reste encore certaines lacunes à combler pour rendre tout cela pleinement applicable en, en, en production.
Louis-François Bouchard : Et en ce moment, comment gérez-vous la multimodalité, donc les images, les tableaux, les PDF, tout cela ? Comment, comment gérez-vous ces éléments chez LlamaIndex ?
Jerry Liu : Pour les modèles antérieurs à la multimodalité, nous explorons encore le volet multimodal. C’est donc un travail en cours. Et, et Gemini contribuera aussi à accélérer une partie de ce travail.
Le, le principal problème, soit dit en passant, lorsque nous jouons avec les modèles actuels au moment de cet enregistrement, c’est que beaucoup d’entre eux sont soit un peu lents à utiliser, soit soumis à de fortes limites de débit, comme, comme GPT [00:20:00] 4. De façon générale, le traitement d’un document complexe nous intéresse beaucoup, et nous avons d’ailleurs publié beaucoup de contenu à ce sujet.
Comment traitez-vous, par exemple, un tableau intégré dans un PDF ? Si vous avez un rapport SEC 10-K, un article de recherche arXiv ou tout type de mémoire juridique, vous avez beaucoup de graphiques et de tableaux, n’est-ce pas ? Et vous voulez les indexer d’une façon ou d’une autre. Nous avons donc beaucoup d’abstractions dans LlamaIndex qui vous permettent essentiellement de résumer et de modéliser hiérarchiquement ce, ce document complet, pas seulement comme une liste plate de chunks de texte, mais plutôt comme un graphe de document.
Vous avez donc un graphe complet d’objets nœuds reliés à d’autres objets nœuds. Et lorsque vous effectuez une recherche, vous ne vous limitez pas à un top K plat des chunks de texte du document. Vous effectuez plutôt la recherche dans ce graphe de document. Cela vous permet essentiellement d’interroger et de comprendre différentes représentations d’objets dans ces données [00:21:00].
Les modèles multimodaux pourront donc peut-être nous aider à résoudre ce problème.
Louis-François Bouchard : Oui, je l’espère. Oui. Nous rencontrons aussi beaucoup de difficultés avec les différents PDF. Je suppose que ce problème existe, existe depuis aussi longtemps que les PDF, mais, oui, c’est vraiment intéressant. Je, je, j’espère vraiment que Gemini aidera, aidera à le résoudre, ou simplement d’autres modèles multimodaux.
Auriez-vous des conseils à donner aux entreprises ou aux particuliers pour s’assurer d’avoir une bonne documentation et, disons, de bonnes compétences en communication ?
Jerry Liu : J’ai l’impression que, historiquement, notre documentation n’était pas très bonne. Une grande partie de son amélioration vient, honnêtement, de notre vice-président des relations avec les développeurs [00:22:00], Worry. Il est arrivé et a essentiellement remanié la documentation. En fait, vous savez, encore une fois, au moment de cet enregistrement, nous effectuons une autre refonte afin d’essayer, vous savez, d’ajouter davantage de ressources.
Nous avons ajouté plus de contenu et, et essayé de réorganiser certaines sections pour les rendre un peu plus claires. Je pense que, de façon générale, il faut réfléchir au public. Et pour nous, encore une fois, dans le contexte où la documentation n’a jamais été excellente, n’est-ce pas, je pense que nous avons vraiment essayé de nous adresser à la vaste majorité des développeurs.
Ils découvrent encore les concepts. Ils, ils veulent donc voir la documentation comme une ressource éducative qui les accompagne tout au long de leur parcours de développeur. Moi, par exemple, je ne suis pas l’utilisateur cible des premiers, disons, 70 % de la documentation, parce que je connais déjà les modules et les abstractions. J’irais directement à la référence de l’API ainsi qu’à certains guides de modules, simplement pour copier-coller du code de référence.
Mais, pour la vaste majorité des utilisateurs, nous voulions structurer la documentation [00:23:00] de manière à ce qu’elle représente un parcours qui commence lorsque, vous savez, vous débutez avec le RAG. Vous passez par le quickstart, puis vous essayez réellement de construire une application RAG full stack. Quels éléments tentez-vous de mettre en place ?
Oh, voici les agents. Comment devriez-vous les envisager ? Et comment s’intègrent-ils à cette expérience ? Vous essayez maintenant d’optimiser tout le système. Quelles stratégies, quels conseils et quelles astuces pouvez-vous employer ? Je pense donc que cela nous a beaucoup aidés, parce que la documentation est devenue beaucoup plus accessible et qu’il était possible de la lire simplement du début à la fin.
Louis-François Bouchard : Je suppose donc que c’est simplement comme dans mon cas. Pour créer des vidéos, il faut une histoire, un bon fil narratif. Même lorsque vous ne faites qu’expliquer quelque chose, le contenu suit une histoire, de l’introduction jusqu’au développement, et ainsi de suite. C’est donc un peu le même principe pour améliorer la documentation.
Jerry Liu : N’est-ce pas ? Exactement. Je pense que c’est un principe clé.
Louis-François Bouchard : Intéressant. C’est, je pense que je n’avais jamais entendu parler de cette façon de documenter son code. C’est, c’est vraiment génial. Et j’espère que davantage de personnes l’adopteront à l’avenir [00:24:00].
Jerry Liu : Oui. Et pour le public, soit dit en passant, je, vous savez, nous, nous l’améliorons constamment. En fait, je ne pense pas que la documentation soit parfaite.
Il manque certainement des éléments et d’autres pourraient être améliorés. Alors, si vous avez des commentaires, n’hésitez pas à nous en faire part.
Louis-François Bouchard : Parfait. Maintenant, oui, j’aimerais approfondir la génération augmentée par la recherche, puisqu’elle représente une grande partie de, de ce que vous faites. D’abord, vous avez déjà expliqué ce, ce que c’était, mais pourriez-vous nous expliquer pourquoi elle suscite autant d’engouement et est aussi populaire ?
Pourquoi tout le monde veut-il utiliser la génération augmentée par la recherche plutôt que d’autres solutions ? Prenons, par exemple, le fine-tuning, où vous réentraînez sur vos données personnelles, où vous réentraînez un modèle puissant sur vos données personnelles. Pourquoi le RAG est-il si populaire maintenant ?
Jerry Liu : Je pense que c’est une bonne question. Je vais peut-être d’abord expliquer ce qu’est la génération augmentée par la recherche.
Puis je parlerai, je parlerai un peu [00:25:00] des raisons pour lesquelles il s’agit probablement du principal cas d’usage en entreprise aujourd’hui, et il y a sans doute une raison à cela. Alors, qu’est-ce que la génération augmentée par la recherche, ou RAG ? Le RAG signifie essentiellement que vous figez le modèle. Le modèle ne change pas. Vous ne l’entraînez plus.
Il est déjà préentraîné. Vous utilisez simplement l’API d’OpenAI out of the box, Llama 2 ou n’importe quel autre modèle. Puis vous prenez un corpus de données, n’est-ce pas ? Le RAG est simplement la façon de combiner les deux. Voici comment il fonctionne : vous chargez des données provenant de votre corpus. Il peut s’agir de PDF, de bases de données ou de fichiers CSV.
D’accord. En fait, pas de fichiers CSV. Oubliez cela. Mais plutôt des données semi-structurées ou non structurées. Vous voulez ensuite les indexer, généralement dans une base de données vectorielle. Vous prenez certains de ces documents. Vous les divisez en chunks, créez leurs embeddings et les placez dans une base de données vectorielle. Maintenant que les données se trouvent dans votre système de stockage, vous pouvez essentiellement construire ce pipeline RAG où, lorsqu’un utilisateur soumet une requête, vous récupérez d’abord le contexte pertinent dans la base de données vectorielle.
Et les bases de données vectorielles [00:26:00] exposent un endpoint qui permet essentiellement de récupérer les documents les plus similaires à une requête utilisateur. Vous prenez ensuite ce texte et l’insérez dans le prompt. Alors, vous savez, imaginez simplement une immense chaîne de texte avec un espace au milieu. Vous prenez tout ce texte et vous le déversez, vous déversez les documents sous forme de texte brut dans le prompt d’input.
Et c’est ce que vous utilisez pour, essentiellement, générer une réponse. Le template du prompt ressemble donc à ceci : vous savez, voici du contexte, insérez le contexte. Voici la question. Insérez la question. Vous obtenez ensuite la réponse. C’est exact. Et, honnêtement, vous pouvez reproduire cette expérience en ouvrant simplement ChatGPT dans votre navigateur, en prenant une page Web ou un article au hasard, en copiant-collant le texte dans ChatGPT et en lui demandant de le résumer, n’est-ce pas ?
Toutes les personnes qui utilisent ChatGPT font cela constamment. Il s’agit essentiellement d’un RAG automatisé, n’est-ce pas ? Dans une sorte de cadre systématique. Alors, pourquoi est-ce si populaire ? Oui. Premièrement, parce qu’il s’agit d’un cas d’usage central [00:27:00] pour la recherche et la récupération d’information. Je pense que, alors, premièrement, c’est un cas d’usage très utile.
Je pense que nous avons parlé à beaucoup d’entreprises. Beaucoup d’entre elles voient une grande valeur dans la capacité d’extraire des informations de leurs données non structurées d’une façon performante, rapide et peu coûteuse. Deuxièmement, c’est très facile à mettre en place dans LlamaIndex. Vous pouvez obtenir une solution fonctionnelle. Les bases tiennent en cinq lignes de code, n’est-ce pas ?
En fait, les agents ont suscité beaucoup d’engouement en avril et en mai. Mais, lorsque les gens ont commencé à jouer avec eux, ils ont constaté qu’ils n’arrivaient pas tout à fait à résoudre beaucoup de cas d’usage, n’est-ce pas ? Et, et je suis certain que les agents enthousiasmeront davantage les gens. Nous voyons des personnes passer du RAG à des approches de type agent [00:28:00], mais d’une façon un peu plus limitée.
Et, à mesure que ces modèles s’amélioreront, nous verrons des changements importants dans les capacités des agents. Mais, pour l’instant, le RAG atteint un bon équilibre : il résout le cas d’usage, il est facile à mettre en place et il fonctionne assez bien.
Louis-François Bouchard : Oui. Et il réduit aussi les hallucinations comparativement au fine-tuning.
Voici une courte interruption pour vous rappeler de laisser un like ou une évaluation de 5 étoiles, selon la plateforme sur laquelle vous regardez cet épisode. Cela aide énormément la chaîne et constitue une excellente façon de me montrer si vous aimez cet épisode ou non. Merci de votre écoute, et je vous laisse profiter du reste de l’épisode.
Pourriez-vous nous expliquer un peu plus quand vous utiliseriez le fine-tuning d’un modèle plutôt que, plutôt que le RAG, ou vice versa ?
Jerry Liu : D’accord. Alors, alors, pour ce qui est maintenant du, du débat entre le RAG et le fine-tuning, je pense que, pour la vaste majorité des développeurs, si vous avez un corpus de connaissances que vous voulez comprendre et, et que vous voulez essentiellement interroger dans un contexte de recherche ou de récupération d’information [00:29:00], vous devriez utiliser le RAG.
Je pense que le fine-tuning possède, en théorie et sur le plan conceptuel, la capacité de faire tout ce que fait le RAG. Parce que, si vous y réfléchissez, vous savez, ChatGPT lui-même est entraîné sur un corpus de données. Vous lui posez des questions, il peut, vous savez, régurgiter des éléments et, et, et, et, vous savez, répondre à vos questions.
N’est-ce pas ? Concrètement, il n’existe actuellement aucun endpoint magique qui vous permet de fine-tuner quelque chose et de lui faire apprendre vos données comme par magie. La plupart des tutoriels sur le fine-tuning que vous trouverez sur le Web, et nous avons nous-mêmes des abstractions de fine-tuning, sont soit très progressifs, soit conçus pour des cas d’usage limités.
Vous ne pouvez donc pas simplement lancer, disons, ce processus aléatoire qui effectuera le fine-tuning en arrière-plan et mémorisera automatiquement chaque nouvelle information que vous lui donnez. Voilà le premier point. Cette UX n’existe tout simplement pas encore. Le fine-tuning prend donc plus de temps, il est difficile à mettre en place et il offre aussi des cas d’usage plus progressifs.
Cela dit, je pense que le fine-tuning fera généralement des choses que le RAG ne peut pas faire [00:30:00], parce qu’il peut effectuer une sorte d’entraînement global sur l’ensemble du dataset. Cela comprend une meilleure adhésion à tous les prompts système que vous configurez. Donc, si vous voulez vraiment refaire, disons, le RLHF du modèle, puis refaire son RLHF avec, en quelque sorte, vos propres instructions personnalisées, ce serait une façon de procéder.
Il pourrait ainsi agir plus systématiquement selon vos directives. Vous pouvez, par exemple, lui faire produire des outputs dans certains styles et ce genre de choses. Mais nous offrons, en fait, un support de base du fine-tuning dans LlamaIndex. Nous avons, par exemple, des tutoriels sur le fine-tuning de Llama 2 ou d’autres modèles pour des cas d’usage comme l’extraction de données structurées et le text-to-SQL.
Nous avons aussi utilisé le fine-tuning pour fine-tuner les embeddings afin d’améliorer les performances de recherche. C’est un autre aspect que les gens oublient souvent. Vous pouvez, vous devriez probablement fine-tuner le modèle d’embedding lorsque vous commencez vraiment à optimiser ces systèmes. Les deux approches sont donc tout à fait complémentaires.
Il est possible que le fine-tuning remplace certaines parties du RAG [00:31:00] à l’avenir. Nous ne le constatons simplement pas encore.
Louis-François Bouchard : Oui, vous pouvez optimiser à la fois l’indexation de vos données et. La, la, la partie requête. Pourriez-vous nous expliquer un peu plus comment, quelles sont les bases de, des deux et, d’abord, dans quelle mesure on peut les améliorer, mais aussi comment on peut les améliorer ?
Jerry Liu : Alors oui, le RAG fonctionne, encore une fois, en indexant des données, vous savez. Et qu’est-ce que l’indexation ? Cela signifie que vous prenez chaque document que vous placez dans une base de données vectorielle, puis que vous l’ajoutez, que vous créez son embedding, n’est-ce pas ? Vous le fournissez à un modèle d’embedding et récupérez un embedding. Cet embedding représente essentiellement le, le type d’index appliqué à ces données.
Et c’est cet élément que vous utilisez pour effectuer la recherche. Pour cet embedding, vous pouvez fine-tuner le modèle afin qu’il produise de meilleurs embeddings. Avec un modèle préentraîné, par exemple un modèle préentraîné de Hugging Face, les modèles sont généralement préentraînés sur de grandes quantités de données [00:32:00], mais pas nécessairement sur des données propres à votre domaine.
Donc, selon les types de questions que vous voulez poser, si elles sont très propres à votre domaine, cet embedding peut ne pas être optimisé pour récupérer le contexte pertinent de la question. Vous pouvez donc essayer de fine-tuner ce modèle d’embedding. Il existe plusieurs façons de le faire.
La première s’applique si vous avez les poids du modèle, n’est-ce pas ? S’il s’agit d’un modèle de Hugging Face, vous pouvez simplement le télécharger et le fine-tuner vous-même. Si vous savez écrire du PyTorch, certains services peuvent aussi, n’est-ce pas, le faire pour vous. Et nous avons ici plusieurs abstractions qui essaient de faciliter l’utilisation de ces différents services.
Cela comprend. En fait, attendez, désolé. Laissez-moi, laissez-moi retirer cela. Je, je n’arrive pas à penser spontanément à un service qui, qui effectue uniquement le fine-tuning d’embeddings. Je suis certain qu’ils existent. Je ne peux simplement pas garantir que les entreprises que je nommerais seraient les bonnes. Mais l’, l’autre chose que vous pouvez faire, et, et c’est aussi un concept assez intéressant, consiste essentiellement à prendre un embedding existant, n’est-ce pas ?
Il peut s’agir d’une transformation linéaire ou d’un réseau neuronal, mais vous, vous pouvez essentiellement fine-tuner un modèle adaptateur supplémentaire par-dessus le modèle de base. N’est-ce pas ? Et les compromis deviennent quelque peu complexes selon que vous effectuez ce fine-tuning du côté du document ou de la requête. Mais, vous savez, nous, nous offrons dans LlamaIndex certaines capacités de base qui vous permettent de le faire.
Et nous encourageons aussi les utilisateurs à essayer de le faire eux-mêmes. C’est un principe assez intéressant, parce que vous pouvez prendre un modèle figé et simplement fine-tuner une couche de transformation par-dessus afin de l’adapter un peu mieux à votre domaine de données. Du côté du fine-tuning des LLM, certains cas d’usage fondamentaux que nous avons observés et trouvés assez intéressants consistent à [00:34:00] prendre un modèle plus faible.
Par exemple, un modèle moins cher ou plus faible, comme Llama 2, que vous essayez de fine-tuner pour qu’il produise de meilleurs outputs structurés. Dans beaucoup de cas d’usage RAG, nous avons constaté que de nombreux utilisateurs souhaitent produire des résultats au format JSON. Et les meilleurs modèles pour générer du JSON en ce moment sont, disons, GPT 4.
Donc, si vous pouvez fine-tuner les plus petits modèles afin qu’ils exécutent mieux ce type de tâche, vous pouvez essentiellement utiliser un modèle plus petit et moins cher. Et alors, nous, c’est un cas d’usage qui nous intéresse beaucoup. Certains, certains autres comprennent la capacité de distiller, de façon générale, le suivi des prompts et des instructions d’un modèle plus puissant, comme GPT 4, vers un modèle plus petit.
Louis-François Bouchard : Et pour ce qui est des autres aspects du, du système RAG, par exemple le chunking, vous devez diviser vos données, ou devez-vous le faire ? Quelle, quelle, quelle est l’importance de la taille des chunks et de la stratégie de chunking [00:35:00] que vous, que vous voulez adopter ? Comment, comment faites-vous ce choix, comment choisissez-vous la stratégie, la stratégie à utiliser ?
Et quelle devrait être la taille de chaque chunk ?
Jerry Liu : C’est une bonne question. Dans l’ensemble, je pense que les gens ne réfléchissent pas assez au pipeline de données du RAG, parce qu’ils utilisent une stratégie de chunking très standard qui s’avère sous-optimale. C’est d’ailleurs la raison pour laquelle leur pipeline RAG échoue. Parmi les quelques variables ou paramètres de base auxquels vous devez réfléchir lorsque vous construisez une stratégie de chunking, il y a d’abord la qualité de votre parseur de fichiers.
Dans quelle mesure extrayez-vous correctement le texte du, du PDF, n’est-ce pas ? Prenons simplement un PDF comme exemple. Il existe différents types de parseurs de PDF. Certains sont meilleurs que d’autres. Certains extraient mieux ou moins bien les éléments plus complexes, comme, vous savez, une mise en page à deux colonnes, des en-têtes, des tableaux et ce genre de choses.
L’étape suivante est le chunking. Alors, comment divisez-vous concrètement le texte ? Soit dit en passant, tout d’abord, pourquoi devez-vous diviser les éléments en chunks ? La raison [00:36:00] est simplement de réduire un document volumineux. Vous obtenez un contexte plus petit et facile à assimiler, n’est-ce pas ? Premièrement, il ne déborde pas de la fenêtre de contexte pendant la recherche.
Deuxièmement, cela réduit le nombre de tokens utilisés et, par conséquent, le coût ainsi que le temps nécessaire pour générer une réponse. Et alors. Mais oui, la façon dont vous divisez les documents en chunks influence beaucoup les performances de recherche. En général, avec une forme de chunking plat, vous, vous observez une courbe en U pour ce qui est du taux d’erreur.
Si les chunks sont trop petits, vous ne retournez pas assez de contexte pour, vous savez, répondre correctement à la question. S’ils sont trop grands, vous commencez à rencontrer des problèmes d’attention et de lost in the middle, ainsi qu’une hausse évidente du coût et du temps de réponse.
Il arrive que le contexte pertinent soit simplement perdu au milieu d’un très gros chunk. Le LLM ne comprend alors pas tout à fait ce qui se passe. Et je pense [00:37:00] que nous nous dirigerons probablement vers des chunks de plus en plus grands à mesure que ces modèles s’amélioreront. Mais, pour l’instant, vous devez ajuster ce paramètre.
Oui. Et l’autre aspect, disons, que nous couvrons généralement dans la section sur la recherche avancée concerne l’idée même de diviser arbitrairement le texte par phrases, paragraphes ou autre. C’est assez arbitraire. Il arrive donc que vous coupiez accidentellement le contexte en plein milieu.
Vous pouvez avoir une section pertinente et, parce que vous l’avez divisée au préalable, elle se retrouve maintenant coupée en deux. À moins de récupérer ces deux chunks, vous n’aurez donc pas tout le contexte nécessaire pour répondre à une question. Comme cette division est quelque peu arbitraire, je pense qu’il est certainement possible de mieux diviser et traiter ces éléments plutôt que de le faire, vous savez, à chaque phrase, à chaque paragraphe ou selon une taille de chunk fixe.
C’est une piste que nous explorons activement.
Louis-François Bouchard : Et quelle est l’importance de la qualité des données à l’intérieur de ces chunks ? Avez-vous des techniques pour repérer, disons, les chunks non pertinents [00:38:00], ou est-ce que vous les organisez ? Parce que, par exemple, je, je suppose que beaucoup d’entreprises construiront des systèmes RAG à partir de leur documentation interne et de tout ce qu’elles possèdent.
Beaucoup de ces éléments sont obsolètes ou correspondent à d’anciennes versions. Ou encore, si votre chunking est un peu étrange, le chunk peut contenir la dernière phrase, qui est complètement inutile. Alors, comment organisez-vous ou améliorez-vous les chunks ? Avez-vous des conseils sur le post-traitement ou faites-vous quelque chose pour améliorer leur qualité ?
Jerry Liu : Oui, je pense que c’est, c’est une bonne question. Le sujet devient assez complexe et, honnêtement, quelques idées me viennent spontanément, mais, en toute transparence, nous travaillons nous-mêmes à mieux le comprendre. Vous pouvez agir à la fois du côté de l’ingestion et de la recherche pour essayer d’améliorer la qualité finale du contexte récupéré, afin que votre LLM ait accès aux informations [00:39:00] les plus précises et pertinentes. Du côté de l’ingestion, n’est-ce pas ?
Vous devez consacrer du temps à choisir un bon parseur de PDF. Par exemple, je pense qu’Unstructured est assez efficace pour séparer les tableaux et les graphiques. Vous pouvez ainsi les traiter plus tard. Certains parseurs de PDF sont aussi très mauvais.
Vous savez, vous pouvez constater que le texte lui-même est simplement très mal formaté. L’autre aspect serait de consacrer, vous savez, un effort de base à la création d’un benchmark d’évaluation et de vérifier quelles tailles de chunks produisent réellement les meilleures performances de génération, n’est-ce pas ? La taille des chunks est, par exemple, un paramètre que vous pouvez ajuster.
Pour ce qui est des stratégies générales de division, il en existe différentes. Vous pouvez diviser par phrases ou par paragraphes. Dans la mesure du possible, j’essaie de préserver les sections afin que les sections contiguës ne soient pas coupées en deux. Par exemple, si vous divisez un fichier Markdown, il est plus logique de conserver une section [00:40:00] contiguë plutôt que d’avoir simplement un chevauchement entre 2 sections.
Nous avons d’ailleurs un séparateur de texte Markdown qui essaie de préserver cela au mieux. L’autre aspect, c’est que vous pouvez apporter davantage d’améliorations aux données par-dessus les chunks eux-mêmes. Et il y en a quelques-unes dont je vais parler. La première concerne les métadonnées.
C’est vraiment important, parce que, si vous ne disposez que du chunk de texte brut, il n’est pas contextualisé. L’embedding de ce chunk de texte ou le LLM ne saura pas vraiment où il se situe par rapport aux autres éléments récupérés. Même l’ajout d’éléments comme le nom du fichier ou un court résumé.
Ou une abstraction de plus haut niveau, par exemple un résumé abstractif du sujet, peut faciliter la recherche, le filtrage par métadonnées et diverses autres tâches. Il y a aussi d’autres éléments, mais ce sont simplement, vous savez, quelques aspects que les utilisateurs devraient considérer du, du côté de l’ingestion. Du côté de la recherche, je dirais généralement, vous savez, qu’on peut tirer beaucoup de pratiques [00:41:00] traditionnelles de recherche.
Comment récupérez-vous le contexte le plus pertinent pour une requête donnée ? Une partie de la réponse repose, encore une fois, sur la qualité des données dont nous venons de parler. L’autre partie est l’algorithme. Dans la plupart des pipelines de recherche en production que nous avons observés, vous savez, même indépendamment de LlamaIndex, on trouve un parcours en deux étapes où vous effectuez d’abord une sorte de recherche top K au moyen des embeddings.
À la deuxième étape, vous pouvez effectuer un reranking, n’est-ce pas ? Donc, une fusion entre différents résultats de recherche. Et même avant cela, avant de lancer une requête, vous pouvez effectuer une forme de réécriture ou de décomposition afin de diviser une question complexe en questions plus petites.
Une architecture avancée de référence générale, n’est-ce pas ? Je ne suis pas certain qu’il s’agisse de la forme la plus générale qui existe, mais je suis assez confiant qu’elle fera probablement mieux que l’approche de base. Commencez par une requête, puis décomposez-la, si possible, en sous-requêtes portant sur différents outils. Et, vous savez, LlamaIndex offre plusieurs abstractions qui vous aident à le faire. [00:42:00]
Décomposez-la en sous-requêtes. Ensuite, pour chaque requête sous-jacente plus petite, exécutez-la sur un retriever. Vous pouvez avoir, par exemple, plusieurs retrievers : l’un effectue une recherche hybride, l’autre une recherche par mots-clés. Et cette approche, appelée Ensemble Retrieval, vous donne un ensemble de chunks candidats.
Il s’agit de votre parcours de première étape. Vous avez donc soudainement un ensemble de chunks provenant, vous savez, de différents retrievers, dont certains peuvent être des doublons. Vous effectuez ensuite le reranking et le filtrage, qui constituent la deuxième étape. C’est là que vous essayez de retenir les chunks les plus pertinents.
Cette étape utilise généralement un modèle plus puissant qu’un simple, simple modèle d’embedding. Oui. Cohere, par exemple, possède un reranker. Vous pouvez utiliser le LLM lui-même pour reranker les éléments. Vous pouvez aussi employer un modèle cross-encoder. Plusieurs de ces modèles sont accessibles au public. Vous récupérez enfin le contexte pertinent.
Vous pouvez alors le fournir au modèle de langage. Il s’agit donc simplement d’un exemple d’architecture, n’est-ce pas ? Mais ce sont des pratiques générales auxquelles les gens devraient réfléchir.
Louis-François Bouchard : Oui, c’est très intéressant. [00:43:00] Vous avez mentionné le DevDay d’OpenAI et maintenant l’évaluation. Je sais que, pendant le DevDay, ils ont mentionné qu’ils utilisaient Ragas pour construire un pipeline d’évaluation.
Est-ce celui que vous recommanderiez aussi, ou comment, comment évalueriez-vous un nouveau système RAG ?
Jerry Liu : Oui, Ragas est excellent. En fait, je devrais l’explorer davantage. Mais je, je connais en quelque sorte les créateurs du projet. C’est, vous savez, c’est, c’est un excellent framework. Nous avons aussi certains de nos propres modules d’évaluation.
Mais ils sont très rudimentaires. Nous cherchons donc à la fois à les améliorer et à mieux les intégrer à ces fournisseurs tiers. Je peux peut-être expliquer conceptuellement en quoi consiste l’évaluation, parce que nous venons aussi de créer un cours de DeepLearning.AI avec TruEra sur la construction et l’évaluation d’applications RAG avancées. Vous devriez tous y jeter un coup d’œil si vous ne l’avez pas encore fait. Pour évaluer le RAG sur le plan conceptuel, il existe quelques domaines clés.
Premièrement, vous savez, vous avez une question qui est posée [00:44:00], puis vous obtenez cette réponse prédite. Vous avez aussi le contexte récupéré, n’est-ce pas ? Et si vous disposez d’une réponse ground truth ou d’un contexte récupéré ground truth, vous pouvez mesurer les métriques de génération et de recherche selon la proximité entre cette réponse prédite et une réponse de référence, ainsi que selon la qualité du contexte prédit par rapport au contexte récupéré ground truth.
Mais, vous savez, il s’agit d’une métrique de base, une métrique d’exactitude. D’autres éléments vont plus loin. Vous pouvez, par exemple, mesurer la réponse prédite par rapport au contexte. C’est ce qu’on appelle la faithfulness. Si la réponse obtenue n’est pas réellement générée à partir du contexte récupéré, cela signifie que le LLM hallucine probablement.
Vous pouvez aussi mesurer si la réponse respecte les directives, comme les outputs structurés et ce genre de choses, mais aussi si elle répond à la question, n’est-ce pas ? Il s’agit alors de la pertinence. Répond-elle réellement à la question ? Vous pouvez donc définir à la fois des métriques de recherche [00:45:00] et de génération.
Vous pouvez aussi définir des métriques dans un contexte sans labels ou avec labels. Soit dit en passant, pour les métriques de recherche, vous pouvez simplement calculer des métriques de classement standards, comme NDCG, MRR et ce genre de choses. Pour comparer la qualité des réponses générées, beaucoup d’utilisateurs emploient généralement un LLM.
D’accord. Vous, vous utilisez donc, par exemple, GPT 4 à la manière d’un juge humain, et vous pouvez essentiellement déterminer si la qualité de cette réponse correspond à celle d’une autre réponse.
Louis-François Bouchard : Génial. Pensez-vous que le RAG représente l’avenir des, des modèles de langage basés sur la mémoire, ou qu’un modèle comme GPT 7 deviendra assez performant pour simplement répondre d’emblée à toutes vos questions ?
Mais je, je comprends qu’il existe des données privées, alors il faudra nécessairement, nécessairement faire quelque chose pour ce type de, de cas d’usage [00:46:00]. Mais deviendra-t-il très facile de, de fine-tuner rapidement un modèle ? Que pensez-vous de l’avenir des LLM ? En fait, ce que j’essaie de demander, c’est : pensez-vous que les LLM deviendront assez puissants et faciles à utiliser pour être tout ce dont vous aurez besoin ?
Ou resteront-ils une petite partie d’un produit plus vaste dont l’ensemble fonctionnera beaucoup mieux ?
Jerry Liu : Oui. Je veux dire, je pense qu’il y a quelques points ici, et, et certains sont vraiment intéressants à examiner. Pour certains, je n’ai pas vraiment les bonnes réponses. Nous pouvons surtout spéculer, et j’espère évidemment que certaines hypothèses se révéleront plus vraies que d’autres, parce que, vous savez, nous construisons un framework.
Qui se situe en quelque sorte du côté de l’orchestration. La première question consiste à savoir si la forme actuelle du RAG durera. Honnêtement, probablement pas. En fait, vous pouvez déjà la voir évoluer. Je veux dire, d’accord, quelle est, soit dit en passant, la forme actuelle du RAG ? Par cette hypothèse, je veux dire précisément [00:47:00] prendre beaucoup de texte, le diviser en chunks avec une sorte de séparateur de texte naïf, puis effectuer une recherche top K, n’est-ce pas ?
Au cours des derniers mois, nous avons notamment investi pour dépasser cette approche, parce que les gens constatent déjà que ces éléments de base ne fonctionnent pas aussi bien qu’ils, qu’ils le souhaiteraient. Je pense donc que, même sur le plan conceptuel, pour ce qui est de l’architecture RAG de référence, les bonnes pratiques évolueront probablement. Reste à savoir si une grande partie de cette recherche sera absorbée par le modèle.
Je pense que la recherche elle-même sera probablement intégrée au modèle d’une façon ou d’une autre. Vous commencerez sans doute à voir, premièrement, des fenêtres de contexte plus longues, voire infinies, où l’architecture des transformers exploitera en quelque sorte une recherche top K ou une base de données vectorielle en coulisses.
Cela a commencé l’an dernier avec des travaux comme RETRO de DeepMind et l’article Memorizing Transformers. Il y aura probablement des développements intéressants du côté des modèles. Toutefois, selon mon intuition issue de la recherche en ML [00:48:00], je ne pense pas que cela éliminera simplement le besoin, du côté des développeurs, d’effectuer toute forme d’indexation et de stockage des données, parce que la capacité d’indexer des quantités arbitraires de données demeure généralement un problème assez difficile.
Et, et je pense que la quantité de compute et le coût nécessaires pour vraiment résoudre ce problème demeureront probablement assez élevés. Je pense qu’un scénario où l’IA s’améliore, ou s’améliore très rapidement, est possible. Je pense que tout le monde convient que l’IA offrira de plus longues fenêtres de contexte et comprendra les éléments à un coût beaucoup plus faible et beaucoup plus rapidement.
Et il y a aussi le fine-tuning, vous savez, la possibilité de fine-tuner un modèle sur des quantités arbitraires de nouvelles données. La question est de savoir à quel point nous sommes limités par le compute, n’est-ce pas, et, et par les coûts. Je pense que c’est, c’est une fonctionnalité très prometteuse. Je, je pense personnellement me situer quelque part au [00:49:00] milieu, entre les personnes qui pensent que GPT 4 représente le sommet et celles qui croient que l’AGI arrivera dans les trois prochains mois.
Et une partie de cela vient aussi du fait que, concrètement, la plupart des gens ont encore du mal à accéder au compute, pour être honnête. Lorsque je regarde les futurs développements de ces modèles, les deux extrêmes me semblent encore un peu lointains.
Louis-François Bouchard : Oui, je, je suis d’accord. Pour parler plus précisément d’une compétence actuellement requise pour développer de tels modèles, approches et systèmes basés sur les LLM, la, la compétence importante dont j’entends moins parler est le prompt engineering, qui était extrêmement populaire il y a quelques mois.
Et je pense qu’il est peut-être beaucoup moins populaire maintenant. Mais pensez-vous que le prompt engineering est là pour rester ou que les LLM [00:50:00] comprendront de mieux en mieux l’anglais ou d’autres langues au point de devenir faciles à utiliser ? Est-ce, est-ce encore une compétence prometteuse à acquérir pour les futures apps LLM, les développeurs LLM ou même les utilisateurs ?
Jerry Liu : Oui, je pense que cela dépend de ce que vous entendez par prompt engineering. Si vous le définissez comme le fait de bricoler littéralement une f-string, d’, d’ajouter des crochets au hasard et d’essayer, vous savez, d’ajouter un caractère spécial, un stop token ou autre chose afin de générer certains éléments.
Oui, je pense, je pense que cela disparaîtra probablement. N’est-ce pas ? Mais je crois que le besoin de prompting en général ne disparaîtra pas. Je le définis ici dans un sens très général. Il restera stable ou, ou augmentera même au fil du temps. Qu’est-ce que je veux dire ? Si vous y réfléchissez, le RAG est essentiellement du prompt engineering, parce que vous cherchez une façon d’insérer du contexte dans le prompt [00:51:00].
C’est simplement une façon programmatique de faire du prompt engineering. Si nous pensons que le RAG fera mieux que cela, nous pouvons le voir comme une façon de faire du prompt engineering. C’est une façon de prompter qui vous permet de récupérer du contexte. Toute abstraction de plus haut niveau que vous construisez par-dessus les LLM exige que l’utilisateur décrive une tâche.
Peu importe donc tout ce que l’agent propulsé par un LLM résoudra pour vous en coulisses à un haut niveau, vous devez encore lui indiquer la tâche à accomplir, et il doit être capable de la résoudre pour vous. Je pense donc que cette idée de prompting continuera probablement de, de représenter un besoin, même si vous abstrairez de nombreuses exigences de bas niveau, comme bricoler précisément un mot particulier.
Et même avec des outils comme l’API Assistants, l’interface d’input demeure en anglais, n’est-ce pas ? Vous devez donc encore interagir avec elle en anglais. Le besoin d’utiliser l’anglais comme input continuera donc d’exister. [00:52:00]
Louis-François Bouchard : Mais pensez-vous, comme pour la question sur les transformers et les bases à connaître, que les utilisateurs doivent comprendre le prompting et apprendre à mieux prompter, ou qu’ils ne devraient même pas s’y intéresser ni apprendre quoi que ce soit à ce sujet ?
Jerry Liu : Oui, en fait, d’accord. Je ne pense pas que la catégorie du prompt engineering subsistera nécessairement comme titre professionnel différenciateur, si cela a du sens. Mais je crois que la capacité d’utiliser l’IA continuera de vous distinguer, parce que, peu importe le niveau de ces abstractions, vous devez découvrir comment en tirer le meilleur parti.
Pour vous aider, pour, pour vous aider essentiellement. N’est-ce pas ? Les personnes qui apprennent à utiliser ChatGPT efficacement obtiennent, vous savez, un gain d’efficacité de 30 % comparativement à celles qui ne savent pas l’utiliser. Je pense donc que cet aspect demeurera [00:53:00] et, et pourrait même devenir plus important à mesure que ces modèles s’amélioreront.
Louis-François Bouchard : Oui. J’ai récemment parlé à une gestionnaire de produit chez Google, et elle a dit que la compétence, la compétence qu’elle recherche maintenant est la communication, mais surtout la communication avec le langage, avec les modèles de langage, parce que vous pouvez faire presque n’importe quoi si, si vous savez bien les utiliser. Tout comme autrefois, si vous saviez bien utiliser Google, vous pouviez trouver sur Stack Overflow comment coder n’importe quoi.
Maintenant, c’est simplement comme Stack Overflow sous stéroïdes. Oui, exactement. Et j’ai une dernière question pour vous, une question que je, je pose souvent, mais qui s’adresse maintenant plus personnellement à vous. À quoi utilisez-vous l’IA ? Utilisez-vous ChatGPT, GitHub Copilot ou une autre IA générative ? À quoi, à quoi l’utilisez-vous ?
Jerry Liu : Oui, j’utilise beaucoup ChatGPT, en fait.
J’utilise Copilot. Je veux essayer d’autres outils [00:54:00] comme Cursor, donc essentiellement des assistants de codage. Oui. Sur notre, sur notre propre Discord, nous utilisons Kapa AI pour gérer la documentation. Nous employons Mendable pour la recherche et Dosu Bot sur GitHub. Alors, vous savez, oui, ces outils présentent quelques défauts et quelques aspérités, mais ils sont, ils sont, ils sont bons.
Ils nous ont objectivement fait gagner du temps, n’est-ce pas ? Pour ce qui est d’aller manuellement répondre à des issues ou à des questions et ce genre de choses. Je veux essayer davantage d’outils. En fait, j’utilise LlamaIndex lui-même, n’est-ce pas, pour traiter un contrat de location.
Et, et pour essayer de répondre à des questions à son sujet. C’était amusant. Mais oui, j’ai hâte de faire un peu plus de dogfooding.
Louis-François Bouchard : Pour, pour coder. Quand utilisez-vous, ou pourquoi utilisez-vous Copilot plutôt que ChatGPT ? Ou quand utiliseriez, utiliseriez-vous chacun ?
Jerry Liu : Oh, d’accord. Oui. Je veux dire, Copilot est simplement Copilot.
Il est simplement là, n’est-ce pas ? Je pense, je pense que, s’il est simplement là [00:55:00], je vais l’utiliser. En fait, il est là sans même que j’aie à activer une barre. Je pense que c’est important : il apparaît et vous n’avez qu’à appuyer, appuyer pour l’utiliser. Je pense qu’il s’agit d’une UX assez importante. J’ai commencé à l’utiliser parce que, parfois, je ne trouve pas de réponses sur, sur Google.
Et parfois, la question que je pose est assez complexe et j’ai besoin qu’il synthétise en quelque sorte des éléments provenant de sources de connaissances disparates. Et il fait vraiment un assez bon travail. Parfois, oui, mais je,
Louis-François Bouchard : Ce que je voulais dire, c’est que, de mon côté, je préfère utiliser ChatGPT pour coder plutôt que Copilot. Je me demande donc pourquoi, pourquoi vous, je suppose que vous utilisez Copilot en raison de son UX, comme vous l’avez dit. Je pense aussi que l’IA deviendra de plus en plus populaire auprès du grand public en étant intégrée de manière facile à utiliser dans toutes les applications actuelles. Mais avez-vous essayé de coder ou d’utiliser ChatGPT comme assistant de codage ?
Et [00:56:00], si oui, pourquoi préférez-vous Copilot ? Est-ce uniquement en raison de l’UX, ou les résultats sont-ils aussi meilleurs ?
Jerry Liu : Oh, non, je veux dire, j’utilise bel et bien ChatGPT pour, pour m’aider à déboguer. Je l’utilise aussi pour chercher des éléments que j’ai oubliés. Par exemple, une définition de méthode Pydantic pour effectuer une certaine opération.
Je le fais vraiment. Je pense que j’utilise Copilot simplement parce qu’il est, il est, je veux dire, juste là, dans VS Code, et aussi parce que je connais mieux Python. Alors, alors, lorsque j’essayais d’apprendre ou de coder un peu en TypeScript, ou même de faire certaines choses avec Streamlit, par exemple, n’est-ce pas, j’utilisais davantage ChatGPT pour apprendre quelque chose de nouveau. Mais, pour les sujets que je connais mieux, il est, il est plus facile de l’intégrer à mon workflow actuel.
Louis-François Bouchard : Oui, c’est une réponse parfaite. Je, je suis, je suis tout à fait d’accord pour utiliser ChatGPT lorsque vous apprenez, tandis que Copilot peut, peut être meilleur pour la productivité et simplement pour coder plus rapidement. C’est tout à fait logique. Génial. [00:57:00] Y a-t-il quelque chose que vous aimeriez partager, ou encore, où les gens peuvent-ils en apprendre davantage auprès de vous ou de LlamaIndex ?
Si vous, si vous souhaitez partager quoi que ce soit au sujet de l’entreprise ou de vous-même, allez-y.
Jerry Liu : Bien sûr. Oui, je veux dire, je pense, je pense que, oui, nous avons couvert la plupart des bases. Les deux seules choses que je dirai sont, premièrement, que nous investissons beaucoup plus, non seulement dans les techniques RAG avancées et ce genre de choses du côté de la technologie fondamentale, mais aussi beaucoup plus dans le développement full stack d’applications d’IA.
Alors, si vous avez des suggestions ou des commentaires. Nous avons lancé des produits comme Create Llama, qui ressemble à Create React App, mais pour les ingénieurs en IA. Nous avons lancé Chat LlamaIndex et SEC Insights, essentiellement des démonstrations d’applications full stack qui montrent comment créer des UX d’IA. L’autre chose que je dirai, c’est que, si vous travaillez en entreprise, comme nous travaillons avec les entreprises, nous souhaitons toujours voir comment vous adoptez les LLM et dans quels cas d’usage.
Alors nous, nous organisons essentiellement des office hours. Envoyez-moi donc un message privé. Nous aimerions discuter avec vous et en apprendre davantage sur vos cas d’usage et vos difficultés. [00:58:00] C’est vraiment génial.
Louis-François Bouchard : Je suis, je suis vraiment enthousiaste à l’idée de voir toutes les prochaines mises à jour. J’utilise aussi LlamaIndex, et nous l’utiliserons davantage pour un projet à venir chez Towards AI.
J’en suis donc très enthousiaste. Mais oui, merci. Merci beaucoup pour votre temps et vos conseils. C’était vraiment génial d’approfondir le RAG et de pouvoir discuter avec un expert du sujet. Je vous suis très reconnaissant d’avoir pris le temps et, oui, merci encore pour cette excellente discussion.
Jerry Liu : Merci de m’avoir invité.
FAQ
Qu’est-ce que LlamaIndex aide les développeurs à construire ?
LlamaIndex connecte les modèles de langage à des collections de données privées ou volumineuses au moyen de l’ingestion, de l’indexation, de la recherche et de workflows structurés.
Pourquoi décrire le RAG comme du prompt engineering programmatique ?
La recherche sélectionne automatiquement le contexte utile et l’insère dans l’input du modèle avant la génération.
Quand une base de données vectorielle est-elle utile ?
Elle aide à parcourir un vaste corpus par similarité sémantique lorsque les passages pertinents ne peuvent pas tenir dans un seul prompt.
Pourquoi des chunks de taille fixe peuvent-ils nuire à la recherche ?
Une réponse complète peut traverser les limites arbitraires des chunks et exiger plusieurs morceaux que le retriever ne sélectionnera pas nécessairement ensemble.
Comment les équipes devraient-elles améliorer un système RAG ?
Elles devraient évaluer la recherche séparément, examiner le contexte manquant et adapter le chunking, les métadonnées, le routage ou la synthèse aux échecs observés.
Quand une équipe devrait-elle utiliser le RAG plutôt que le fine-tuning ?
Utilisez le RAG lorsque l’objectif consiste à effectuer des recherches ou à répondre à des questions dans un corpus de connaissances qui évolue. Le fine-tuning convient mieux au comportement, au style, aux instructions ou aux outputs structurés.
Pourquoi les PDF sont-ils difficiles à traiter pour les systèmes RAG ?
Les tableaux, les graphiques, les colonnes, les en-têtes et l’ordre de lecture peuvent disparaître pendant l’extraction du texte. Traiter le résultat comme des chunks plats détruit souvent la structure nécessaire pour obtenir une réponse exacte.
Qu’est-ce qui rend une documentation technique utile aux nouveaux développeurs ?
Elle devrait les guider d’un démarrage rapide vers des applications complètes, puis vers l’optimisation, tout en laissant la référence de l’API accessible aux utilisateurs expérimentés.
Pourquoi fine-tuner un modèle d’embedding pour un système RAG ?
Un embedding général peut ne pas placer les questions propres au domaine près des bons passages. L’adapter au domaine peut améliorer le contexte récupéré.