Bruno:
Figurez-vous que j'ai eu du mal à trouver l'inspiration pour cette intro. Je me suis donc tourné vers mon LLM habituel, qui m'a trouvé, je pense, la meilleure analogie pour expliquer ce qu'est un LLM. L'analogie qui est d'ailleurs, je ne trouve pas assez répandue sur Internet. Votre LLM, c'est comme le personnage principal de Memento. Il se réveille régulièrement, sans savoir où il est, pourquoi il est là, et ni ce qu'il doit faire. Pas de mémoire, juste des tatouages sur le corps qui lui rappellent ce qu'il doit faire, qui croire, qui poursuivre, et sans ces tatouages il invente complètement. Confabule et il hallucine sa propre vie. Et c'est exactement ce qui se passe dans la tête d'un LLM. Pas de mémoire, juste des prédictions du mot suivant et quand on n'a rien à se mettre sous la dent, forcément, il va complètement inventer. Le rag, ça a été un de ses premiers tatouages. Le contexte engineering, c'est apprendre à mettre ses tatouages au bon endroit, au bon moment, avec la bonne taille de police. Mais alors, jusqu'où peut-on tatouer une machine ? Le rag, Est-il mort ou seulement renommé ? Et surtout, ces problèmes de mémoire vont-ils inverser la pyramide de coût des cloud providers ? Pour répondre à ces questions de mémoire courte, je ne reçois pas Christopher Nolan, mais il s'y connaît en bon contexte. Guillaume, bonjour.
Guillaume:
Bonjour. Ravi d'être là avec toi et avec les auditeurs aujourd'hui.
Bruno:
Avec plaisir. Alors Guillaume, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Guillaume:
Alors, je m'appelle Guillaume Laforte, je travaille chez Google depuis à peu près dix ans, et depuis surtout 3 ans, j'ai toujours été dans la branche Google Cloud et depuis à peu près 3 ans, je me focalise sur tout ce qui est intelligence artificielle, les LLM, Generative AI, etc. Les gens me connaissent peut-être pour ma participation au podcast Les Cascodeurs, donc les Cascodeurs te font coucou. Et puis, j'ai aussi créé un langage de programmation qui était assez connu, qui s'appelle Groovy dans la fondation Apache. Et du coup voilà il y a un an ou deux j'ai commencé à creuser un peu plus le sujet du RAG et puis plus récemment tout ce qui est contexte engineering et tout ça qui sont un peu plus à la mode on va dire, et du coup ça m'a vraiment intéressé de trouver les meilleures manières de donner la bonne information au bon moment un LLM pour pas que... Qu'il oublie trop.
Bruno:
T'avais déjà... J'ai cherché après cette analogie avec Memento.
Guillaume:
C'est très bien, ça.
Bruno:
En fait, j'ai trouvé que 220 000 références sur Google de cette analogie-là, ce qui est quand même assez peu à l'échelle d'Internet. T'avais déjà entendu cette analogie-là ?
Guillaume:
En fait, non. Et je me suis dit, c'est une très bonne analogie.
Bruno:
Et j'adore. Donc, on a déjà eu l'occasion d'évoquer le rag à quelques moments dans différents épisodes sur ce podcast. J'avais quand même le sentiment que c'était... il y a des gens qui nous expliquent qu'avec les contextes qui sont de plus en plus vastes, on a de moins en moins besoin d'utiliser le RAG, donc du coup la question c'est là on est mi-2026 à peu de choses près le RAG ça en est où ?
Guillaume:
Donc c'est vrai qu'il y a tous ceux qui disent le RAG est mort, et puis c'est vrai que le terme ou l'acronyme RAG était plus à la mode on va dire il y a deux ans alors que là on en parle de moins en moins et tous les grands modèles aujourd'hui que ce soit chez Google, chez OpenAI entrepiqués, etc. Elles sont passées les fenêtres de contexte énorme de 1 million de tokens. Donc on se dit, on peut mettre tout Harry Potter, tout Lord of the Ring dans un contexte. Est-ce que ça fait sens ou pas ? Alors déjà, ça a un coût. C'est quand même un temps aussi de processing. Mais bon, du coup, est-ce qu'on a encore vraiment besoin de RAC ? En fait, oui. Parce que si on regarde les données des utilisateurs, de nos clients, de toutes les bases de données qu'on peut avoir en interne, malgré tout, c'est même encore plus gros que ce que, de toute façon, tu peux mettre dans une contexte Windows. Donc, il va falloir sélectionner, trouver, chunker, etc., pour mettre le bon contexte au bon moment dans la fenêtre de contexte du LLM. Donc, oui, ça reste toujours d'actualité. Et on peut tirer parti des grandes fenêtres de contexte pour faire des choses un peu hybrides, c'est-à-dire remonter des documents entiers et ne donner que les 2-3 documents qui sont pertinents. Mais effectivement, on ne peut pas mettre toutes les données des entreprises comme ça dans une grande fenêtre.
Bruno:
Et puis en fait aussi ce qu'on voit beaucoup c'est que, On peut voir sur LinkedIn et autres tout un tas d'exemples, des meilleurs prompts. On voit qu'il y a quand même aussi une notion de structuration de l'information, de hiérarchisation de l'information. Le RAG apporte aussi ça, cette capacité à structurer la donnée et à ne mettre dans ton contexte que l'information qui est réellement pertinente pour la tâche en cours.
Guillaume:
Exactement. Donc après, ce n'est pas non plus la panacée parce que ce n'est pas un système qui est parfait. Souvent, je prends l'exemple, on va dire, on recherche je ne sais pas, on est une compagnie d'assurance et on va rechercher s'il y a telle condition qui s'applique je ne sais pas, j'ai eu un accrochage, avec ma voiture et est-ce que je suis couvert donc oui, peut-être qu'on va voir, on va remonter parce qu'il y a cette technique de on découpe les documents en petits morceaux on les vectorise, etc. On va remonter les extraits qui sont pertinents mais en fait, peut-être qu'en note de bas de page très très loin de l'extrait qui a l'air pertinent il y a écrit, ah par contre ça ne s'applique pas pour tel type de contrat et l'utilisateur a peut-être ce contrat là donc il y a aussi un petit peu c'est comme si on mettait des je sais pas, qu'est-ce que je pourrais prendre comme analogie des lunettes avec des fentes où tu vois juste, quelques passages et tu vois pas la note en bas de page parce que elle était cachée par tes lunettes un peu bizarroïdes donc voilà, c'est pas non plus parfait, mais il y a des techniques pour essayer d'améliorer les choses pour que le rack soit plus pertinent éviter les hallucinations et de remonter la bonne information dans le contexte.
Bruno:
Oui, parce qu'en fait, ce découpage de l'information est un pré-processeur qu'il faut pouvoir mettre en place. Mais donc, ce découpage de l'information, ce chunking, il est primordial dans la qualité du rag derrière.
Guillaume:
Tout à fait. Donc, le chunking, c'est le fait de découper un document en petits morceaux. Après, ces petits morceaux-là, on va calculer un grand vecteur de grande dimension, en utilisant des modèles particuliers, des embedding models, qui calculent ces vecteurs-là à partir de textes, voire d'images, de vidéos et autres. Et ce vecteur-là, on va les stocker dans une base de données vectorielle qui est faite exprès pour stocker ce genre de structure-là. Et en fait, on s'est aperçu, enfin les chercheurs se sont aperçus que quand un utilisateur pose une question, le vecteur de la question, et quand on calcule la distance entre les vecteurs, le vecteur de la question est assez proche d'un vecteur, d'un chunk qui contiendrait la réponse. Et du coup, quand on fait une recherche vectorielle, on essaie de trouver les vecteurs les plus proches d'un vecteur de query, de requête, et on remonte tout cela dans le contexte donc le vecteur et puis le bout de chunk de texte qui est associé et on donne ça en fait dans le contexte du LLM mais effectivement est-ce qu'il faut, donc il y avait un débat à une époque sur est-ce qu'il faut que ça fasse 100 tokens 1000 tokens, c'est quoi la meilleure taille et en fait oui on peut regarder par rapport à une taille, on peut faire des fenêtres glissantes, on peut faire plein de choses mais il y a aussi d'autres approches, ça peut être par exemple de regarder plutôt la structuration d'un document, typiquement quand on veut essayer de faire des unités un peu plus sémantiques, peut-être qu'un paragraphe. Logiquement, quand on écrit des documents les êtres humains, ils vont regrouper les choses par paragraphe, par section etc. Si on arrive à regrouper un chunk peut-être que c'est juste un paragraphe, peut-être qu'il y aura des paragraphes plus courts, plus longs, parce que c'est naturel d'écrire, plus ou moins longuement sur tel ou tel sujet mais peut-être que faire des découpages différents pas forcément en fonction d'un nombre de tokens ça peut être plus pertinent. Et donc il y a plein d'autres techniques, et moi je m'étais amusé à creuser un petit peu le sujet et d'essayer de trouver des techniques intéressantes. Pour faire des découpages sémantiques, pour faire un peu des notions de zoom, c'est-à-dire on va regarder un chunk, mais on stocke aussi le contexte dans lequel il est. Parce que peut-être qu'une phrase, je prenais dans une présentation que j'avais faite, que j'avais donnée à Devox France par exemple, je disais, je prenais la page Wikipédia sur Berlin. Et l'utilisateur peut poser la question, combien est l'habitant à Berlin ? Peut-être que le chunk intéressant va contenir... Il y a 3 millions d'habitants à Berlin. Donc OK, chouette, on a trouvé le bon chunk. Mais peut-être qu'en fait, il va y avoir plusieurs chunks et l'information peut être découpée dans plusieurs phrases. Imaginons que c'est un chunk, une phrase. Et peut-être que la ville de Berlin est la capitale de l'Allemagne. Et la deuxième phrase, cette ville... À 3 millions d'habitants. Mais du coup, si on regarde juste cette vie à 3 millions d'habitants, c'est le chunk qui nous intéresserait. Mais on n'a pas le contexte global, c'est-à-dire les références entre les pronoms et les entités qu'ils représentent. Donc, il y a d'autres manières de faire, c'est-à-dire de calculer des vecteurs très précis, mais par contre, de stocker, de remonter dans le contexte du LLM le texte environnant, par exemple. Donc, j'ai essayé de tester différentes techniques et voir comment elles s'appliquaient, si ça me remontait. Alors, je n'ai pas fait une évaluation comme les chercheurs y font. Avec des datasets, etc. Mais en tout cas, pour les cas que j'ai utilisés et avec lesquels j'ai expérimenté, j'ai vu que juste de se focaliser sur des 500 tokens par chunk, ce n'était pas forcément le plus pertinent. Et que suivant les types d'applications qu'on fait, par exemple du Q&A, etc., peut-être qu'une autre manière de découper les informations pourrait être plus pertinente et remonter des meilleurs extraits.
Bruno:
Donc avec un côté un peu plus sémantique.
Guillaume:
Tout à fait, oui.
Bruno:
Tu as évoqué le cas des tokens.
Guillaume:
Oui.
Bruno:
J'ai essayé de creuser un peu le sujet de la tokenisation, de comment est-ce qu'on traduit une question en token, parce que je trouvais ça assez intéressant. Et j'ai découvert, alors peut-être que j'ai mal compris le sujet, mais qu'en fait, justement, ces modèles d'embedding qui traduisent une question ou un chunk en vecteur, en fait, c'est la même chose que pour traduire un bout de mot en token. En fait, c'est le même principe, on traduit en fait un morceau de mot en vecteur aussi.
Guillaume:
Oui, tout à fait.
Bruno:
Et c'est les mêmes modèles qui sont utilisés ?
Guillaume:
Alors, les tokenizers, en général, utilisent aussi... Tous ces modèles-là, les LLM, etc., c'est basé sur l'architecture des réseaux de neurones de type Transformers, ce qui était un papier de recherche que Google a sorti en 2017. Et donc, par exemple, tout ce qui est les modèles de type BERT, etc., sont souvent utilisés pour faire des tokenizers. Et si on regarde aussi l'architecture des LLM, En fait, c'est toujours des couches de réseaux de neurones et finalement, les dernières couches aussi représentent le même type de vecteurs. Qui sont utilisées dans ces embedding modèles, qui ont une structure un petit peu différente. Mais ce n'est pas forcément, en tout cas, les mêmes vecteurs, les mêmes informations, etc., sémantiques, puisque c'est un peu deux process différents. Mais en tout cas, oui, c'est les mêmes genres d'approches pour représenter des notions sémantiques avec des vecteurs de nombreux flottants.
Bruno:
Hyper intéressant. dans cette notion de contextualisation j'ai découvert récemment, parce que en plus de ce podcast j'ai aussi une émission sur TikTok hebdomadaire qui s'appelle la stack des autres où on découpe la stack d'une grosse entreprise et il s'avère que hier on a fait la stack de Notion et en faisant tout le travail de recherche sur la stack de Notion j'ai découvert que Notion ils ont un avantage concurrentiel sur l'approche de l'IA parce qu'en fait dans les choix de structure qu'ils ont choisi chez Notion, Tout est un bloc. Quand tu crées ta page sur Notion, ton paragraphe, ton image, tes tables, tout est un bloc. C'est enregistré tel quel. Les blocs sont rattachés à d'autres blocs. Un bloc peut contenir une infinité de blocs qui peuvent contenir une infinité de blocs avec une profondeur infinie. Ils ont un chunking qui est naturel, qui était déjà là depuis leur création, et qui leur permet d'avoir une capacité de recherche hyper pertinente. Et comme ils ont en plus cette notion de lien entre les chunks, ils ont aussi, comme tu disais, cette contextualisation. Je ne sais pas du coup si ça c'est... Je ne sais pas si tu avais l'information et si c'est une approche qui commence à se généraliser dans le monde du RAG.
Guillaume:
Donc il y a différentes approches, tu vois, pour le RAG, il y a par exemple tous ceux qui avaient déjà des bases de données orientées graves, par exemple, avaient déjà cette notion de contextualisation, de lien entre éléments, entités, etc. Donc c'est marrant de voir qu'il y a une certaine convergence aussi de technologies ou d'approches de stockage et qui du coup, rétrospectivement, et quand on regarde Notion effectivement, bah oui, il y a déjà toute cette structuration, hiérarchique et c'est super pertinent parce que là on va effectivement pouvoir se dire, tiens ça, ça appartient à un plus grand contexte on peut retourner ce plus grand contexte parce qu'il y aura peut-être plus d'informations pour répondre à une question donnée, ouais, ouais C'est effectivement très pertinent dans le cadre du RAG d'avoir cette structuration intrinsèque finalement à son outil, à sa base de données.
Bruno:
J'ai déjà essayé de faire quelques systèmes de RAG. Il y a effectivement cette importance de la manière dont tu vas découper tes éléments. Mais j'avais l'impression que sur les modèles d'embedding, j'ai l'impression qu'à chaque fois que je fais un RAG, on me dit, prends l'embedding d'OpenAI. C'est le meilleur. Est-ce que c'est vrai ? Est-ce que le modèle d'embedding est important ? Ou est-ce qu'il n'y a pas de temps de différence ?
Guillaume:
Non, le modèle d'embedding est important. Donc, pour plusieurs raisons. Alors déjà en général plus le modèle d'embedding est gros plus il comprend de notions sémantiques distinctes, mais après il y a aussi des petits modèles d'embedding qui sont très spécialisés et qui peuvent marcher même sur un laptop avec un CPU, on n'est pas obligé forcément d'avoir un modèle qui est dans le cloud pas forcément même besoin d'un GPU non plus, sur ses serveurs etc. Donc il y a une question de taille où la finesse sémantique peut avoir son importance déjà. Deuxièmement, tous ces modèles-là aussi sont entraînés sur certains datasets et typiquement, il y a beaucoup de modèles. Moi, quand j'expérimentais à l'époque, j'utilisais souvent un petit modèle local. J'oublie toujours son nom, il est un peu barbare, mais qui avait été entraîné essentiellement sur de l'anglais, Donc, par exemple, sur les exemples Wikipédia, les villes européennes, etc., ça marchait bien, puisque je regardais le Wikipédia en anglais. Mais si je voulais comparer avec d'autres informations qui étaient dans d'autres langues, les vecteurs étaient très descriptifs, on va dire, en anglais, mais assez peu descriptifs dans d'autres langues. Donc, si on a du contenu multilingue, il vaut mieux avoir un modèle qui a été entraîné sur des datasets très riches en termes de langues différentes. Et du coup aussi, il va y avoir une sorte de rapprochement sémantique aussi entre les langues. C'est-à-dire que si je dis une voiture rouge en français ou a red car en anglais, si on a un vrai modèle d'embedding multilingue, les vecteurs vont être très proches. Alors que si justement il a été entraîné essentiellement sur l'anglais, peut-être que les vecteurs vont être complètement disparates et éloignés. Donc la langue, on a aussi... Du coup des modèles qui sont multimodaux. Donc là, il y a DeepMind de Google qui a sorti la version 2 de son modèle Gemini Embedding, qui est multimodal. Donc on peut très bien lui donner une image, une photo, une vidéo, un extrait de son, et de calculer dans le même espace vectoriel d'embedding. Et du coup, imagine-toi, tu veux rechercher les vidéos de If This Then Dev, quelque chose qui va être dans la vidéo mais pas forcément, enfin je sais que tu as les transcriptions donc en général tu vas retrouver les mêmes choses mais peut-être que tu vas chercher quelque chose de visuel qui est apparu, je sais pas mon t-shirt il est peut-être spécial, bon non là il y a juste écrit Google, on s'en fout mais. Peut-être que si tu recherchais, si j'avais une Ferrari sur mon t-shirt tu recherches Ferrari, voiture rouge peut-être que ça te remontrait cet épisode-là parce que la personne que tu interviewais avait une Ferrari sur son t-shirt, donc si par exemple, tu as un site d'e-commerce et quelqu'un, tu peux imaginer donc un client qui essaie de trouver tiens, je veux trouver la même robe, la même voiture en Lego que j'ai photographiée, tu vas pouvoir faire une recherche comme ça, sémantique, sur la vidéo, sur le texte, sur les images, de la même manière, tu vois, et remonter du coup, les choses très riches. Donc, suivant les use cases, si on peut utiliser en tout cas des modèles plus riches, plus... Qui ont été entraînés sur des datasets plus variés tu auras des meilleurs résultats aussi du coup tu remonteras des extraits que tu pourras mettre dans ton contexte qui seront plus pertinents.
Bruno:
Et du coup, est-ce qu'il y a des modèles en particulier que tu recommandes en fonction de certains contextes ? Ça bouge tellement vite que c'est difficile de recommander un truc.
Guillaume:
Oui, ça bouge vite. Après, c'est vrai que j'ai tendance à utiliser celui que je disais, la Gemini Embedding 2, parce qu'il est très riche, etc. Mais il y a aussi, j'ai vu, donc on a aussi un modèle OpenWeight, en poids libre, qui est basé sur le modèle Gemma, qui est open source, qui est un cousin, on va dire, de Gemini. Et donc, il y a Gemma Embedding et je connais des gens qui l'ont entraîné sur du contenu en polonais. Donc, ils l'ont fine-tuné pour leur utilisation particulière pour la langue polonaise. Et du coup, si toi, tu recherches des documents, je ne sais pas, des textes de loi, des lois polonaises, peut-être que tu auras envie d'utiliser vraiment un modèle plus petit que tu peux faire tourner sur tes serveurs et vraiment spécialisé dans cette langue-là, voire spécialisé dans un domaine donné. Parce que souvent, les problèmes des embedding models aussi, et des tokenizers, etc., c'est qu'ils peuvent créer aussi plus de tokens quand c'est des notions, des choses qu'ils ne connaissent pas. Et quand on a des mots scientifiques, des acronymes qui sont spécifiques à son entreprise, etc., peut-être qu'on n'aura pas d'aussi bons résultats parce que le modèle n'aura pas été entraîné sur ce type de données-là, sur le vocabulaire particulier. Donc voilà, il y a ça aussi, fine-tunez, pourquoi pas, des modèles open-weight sur ses propres données, qui peut être intéressant.
Bruno:
Et Minoa, ça paraît comme aussi un peu... Tu disais tout à l'heure qu'on a remarqué que le vecteur de la question est souvent proche des vecteurs de la réponse. Mais est-ce que c'est une vérité absolue ou est-ce que ça nécessite de quand même réussir à poser une question qui soit suffisamment intelligible et suffisamment complète ? Et qu'en fait, plus ta question est entre guillemets vague, moins il y a de chances que tu trouves ta réponse.
Guillaume:
Alors c'est vrai, oui, oui, tout à fait. Ce qu'il faut voir, c'est que quand on fait cette recherche, ce calcul de distance entre vecteurs, parfois, les vecteurs qu'on va trouver dans notre base de données, qui vont être vraiment les plus proches du vecteur de la requête d'entrée, ne sont pas forcément ceux qui contiennent la réponse. Donc comme je disais tout à l'heure l'exemple de quelle est la population de Berlin, une phrase qui dit « la population de Berlin n'a pas changé depuis 2020 » ou un truc comme ça. En fait, tu as déjà quand même dedans toutes les notions clés de la réponse et de la question, c'est-à-dire population Berlin, etc. Mais par contre, tu n'as pas le chiffre. Et peut-être que ce vecteur-là, il va bien matcher par rapport à cette requête, mais un vecteur d'un chunk qui contiendrait la réponse, mais le texte est, il y a, je ne sais pas, on va dire 3 millions de personnes habitent la capitale de l'Allemagne, c'est un peu plus éloigné, tu vois, on n'a pas habitant, il n'y a pas de population, on n'a pas dit Berlin, mais celui-là contient la réponse. Et donc il y a d'autres idées qu'on peut mettre en place donc on peut très bien remonter, 10 vecteurs ou 100 vecteurs mais vérifier que ces vecteurs répondent à la question et pour ça il y a aussi d'autres modèles des modèles de re-ranking qu'on peut utiliser pour comparer et vraiment ils sont spécialisés pour dire pour donner un score, est-ce que ce bout de texte là répond à la question leur job c'est juste de retourner un score c'est pas de donner des tokens, de donner quoi que ce soit c'est juste de dire, là ouais je suis assez confiant que ça donne la réponse c'est à dire ils ne connaissent pas intrinsèquement dans leur savoir la réponse, ils ne savent pas qu'il y a 3 millions d'habitants à Berlin mais ils voient que la structure etc. Correspond bien et a l'air de donner la réponse et du coup on peut remonter dans ces 100 vecteurs là, on peut les réordonner et ne sélectionner par exemple que les 10 meilleurs avec un autre score, mais qui va être une sorte de score de pertinence si tu veux.
Bruno:
Ça rajoute une dimension.
Guillaume:
Et ça rajoute en quelque sorte une dimension, ça les réordonne et ça permet de les filtrer et de ne donner vraiment, encore une fois, que les bons vecteurs. Et moi, une autre technique que j'avais utilisée, c'est en fait, quand tu disais, est-ce que finalement la question et la réponse, le texte contenant la réponse, sont si proches que ça ? Ouais, quand même, pas mal, mais est-ce que si on comparait plutôt des réponses avec des réponses ou des questions avec des questions, on n'aurait pas quelque chose de plus proche ? Et en fait, la technique que j'avais utilisée, c'est, Quand je fais mon chunking, etc., je regardais plutôt des paragraphes ou un certain nombre de phrases. Et au moment du chunking, je demande à un LLM de me dire quelles sont les questions pour lesquelles je trouverai la réponse dans ce paragraphe-là. Donc, on génère des questions de manière un peu dynamique. Et donc, s'il y a un paragraphe sur la population de Berlin, il y aura peut-être la question, quelle est la population de Berlin qui est générée ? Donc, quand on fait des applications de type Q&A, etc., sur des bases de connaissances et tout, peut-être que si je compare les questions des utilisateurs avec des questions générées à partir de mes documents, j'aurai un meilleur matching. Et c'est vrai que moi, j'avais noté, donc c'est toujours entre 0 et 1, etc., les résultats, et je voyais qu'il y avait au moins 10% d'amélioration dans les scores et la pertinence qui m'étaient remontées. Donc voilà, il y a différentes techniques pour essayer de trouver, de filtrer, de réordonner et de trouver des meilleurs vecteurs plus pertinents à comparer.
Bruno:
C'est hyper intéressant ton approche d'ajouter les questions mais est-ce que ça veut dire que tu stockes quand même, le vecteur de ton chunk ou est-ce qu'au final tu fais que des vecteurs de questions qui sont liés en métadonnées à un chunk.
Guillaume:
Donc il y a différentes techniques pour ça ou approches mais effectivement l'idée, moi je calcule le vecteur sur la question mais ce que je retourne c'est en fait le paragraphe qui contient la réponse donc ça oui t'es obligé de faire ça mais c'est vrai qu'il y a aussi dans les bases de données vectorielles souvent t'as les métadonnées, donc même si tu fais pas cette approche de créer des questions, génériques, tu peux aussi associer à par exemple la section d'un document dans laquelle se trouve ce texte là et peut-être que la section, je sais pas si c'était dans la page de Wikipédia, ça va être informations géographiques populations, donc t'as déjà en fait, les informations aussi, même ne serait-ce qu'au niveau des métadonnées, tu vois, tu peux faire du filtrage aussi grâce à ça.
Bruno:
De la même manière qu'aujourd'hui on a des context windows qui sont de plus en plus vastes sur nos LLM mais on sait que si tu mets trop d'informations en fait le LLM il se perd et du coup il fait n'importe quoi j'ai cru comprendre aussi que dans ton rag, plus tu mets de documents dans ton base vectorielle plus en fait au final tu te retrouves avec un bro à A, je sais plus j'avais vu qu'à partir de 10 millions de documents ce qui reste quand même phénoménal mais qu'à partir de 10 millions de documents tu commences à avoir une chute qui est relativement, forte de la pertinence parce qu'en fait tout se retrouve à proximité et ce que je trouve étonnant parce que la notion c'est pas juste de dire qu'il y a trop de bruit c'est aussi qu'en fait au bout d'un moment tout se rapproche, et je comprends pas comment est-ce que les vecteurs passent à se rapprocher bah oui pourquoi est-ce que quand t'as 9 millions de vecteurs tu passes à 12 millions d'un coup ils se sont tous rapprochés entre eux ?
Guillaume:
Ça c'est une bonne question et c'est vraiment un sujet de recherche actuel, il y a un papier qui est sorti il n'y a pas très longtemps sur Archive, le site de préprint de papier de recherche, qui explorait ce sujet-là. Alors, je ne l'ai pas lu, malheureusement. Mais effectivement, je pense que ça revient aussi encore, quand on parlait tout à l'heure, un petit peu de la finesse des... Des vecteurs embedding et de leur connaissance intrinsèque, etc. Et souvent, quand on utilise un modèle d'embedding qui est plus gros, il a plus de finesse et il a aussi plus de dimensions. Donc, par exemple, celui de Gemini, c'est 3000 dimensions, mais on peut aussi le faire, donc il y a ce qu'on appelle Matryoshka Embedding, c'est-à-dire qu'en fait, on a 3072, mais on peut faire 1500, 768 on peut avoir c'est à dire tronquer en quelque sorte et faire des recherches rapides sur moins mais regarder quand même sur la finesse de toutes les dimensions du vecteur après pour faire des comparaisons et souvent les plus gros vecteurs, embedding modèles ont plus de finesse et on va avoir moins cette notion un peu d'agrégation mais je pense que l'agrégation et ces vecteurs qui se rapprochent ça va être, disons quand il y a beaucoup plus de notions sémantiques variées mais pas forcément, ou trop spécifiques, et qui ne sont pas forcément dans les connaissances enfin les datasets sur lesquels on était entraîné les Amédic Models, je pense que c'est ceux-là qui vont se retrouver un peu agglutinés, plutôt que ceux qui sont sur un domaine varié connu, etc. Donc à mon avis tu vois, faire plus de filtrage, faire plus d'utiliser des modèles plus forts etc. Peut pallier quand même dans une certaine mesure à ça mais voilà ça reste un vrai sujet de recherche et j'ai pas la réponse à la question.
Bruno:
Pour le moment de la même manière que on tend à juste mettre de plus en plus de neurones dans les réseaux de neurones tu dis qu'en fait sur les RAC c'est le même système en fait en prenant des espaces de vecteurs plus importants pareil on en met plus on arrive à aller au-delà des limites actuelles quoi.
Guillaume:
En tout cas c'est mon.
Bruno:
Intuition et.
Guillaume:
Pour le moment.
Bruno:
Et est-ce que du coup, cet agrandissement des fenêtres de contexte, est-ce que tu penses que petit à petit, ça va faire disparaître le concept même de RAG ? Ou ça sera toujours quelque chose qui sera utile ?
Guillaume:
Donc le RAG reste toujours utile parce que même malgré ce qu'on disait tout à l'heure, la taille des fenêtres, on ne pourra jamais mettre toutes les données, évidemment, de l'entreprise. Plus le fait qu'on a du mal, dans les grandes fenêtres de contexte, toutes les tâches de recherche dans les grandes fenêtres de contexte, les datasets d'entraînement, etc., ne travaillent jamais vraiment sur des datasets énormes. Et donc souvent, ces datasets vont se focaliser sur 100 000 tokens ou des choses comme ça, mais pas un million de tokens, par exemple. Et du coup, on a des bons résultats pour des plus petits datasets que des grands datasets. Par ailleurs, on a remarqué que souvent, les LLM se focalisaient plus sur ce qu'il y a au début ou la fin de la fenêtre de contexte, mais oubliaient un petit peu ce qui avait, ou ne semblait pas être pertinent, ce qu'il y a au milieu de la fenêtre. Et puis, de manière générale, plus d'hallucinations, de confabulations sur des grandes fenêtres. Donc ça, c'est ce qu'on a pu mesurer. D'où toutes ces idées de contexte engineering, c'est-à-dire, le RAG en fait partie du contexte engineering, mais d'arriver à donner la bonne information au bon moment, quitte à faire... Donc là, il y a toute la mode des agents IA, etc., où on va faire des sous-agents, où on ne donne qu'une tâche donnée avec juste le contexte qui va bien et pas tout le contexte en cours de la conversation ou du projet ou je ne sais quoi, justement pour essayer de spécialiser un agent pour qu'il ne se focalise que... Sur ce dont il a besoin. Après, encore une fois, les grandes fenêtres de contexte restent quand même utiles. L'exemple que je disais tout à l'heure, imagine une grande police d'assurance, tu trouves la question, est-ce que je suis couvert pour telle chose ? Oui, et ta note en bas de page dit, non, en fait, toi, tu n'es pas couvert parce que tu as le contrat. Ce qui peut être intéressant, c'est qu'au lieu de remonter éventuellement juste des chunks, on a retrouvé finalement... Tu as trouvé 10 chunks super intéressants, et au lieu de mettre ça dans le contexte, peut-être que tu vas retourner les dix documents qui contiennent ces chunks-là. Et tu ne donneras que ces documents-là et qui tiennent dans la fenêtre de contexte. Et les LLM auront quand même tout le contexte, les notes en bas de page, les références, etc. Croisées dans les documents. Et peut-être que cette approche un petit peu hybride. Fonctionnera mieux finalement parce qu'ils verront tout le document et les contre-indications, les notes de bas de page, etc. ils seront. Donc je pense que l'avenir est un petit peu plus mixte, c'est-à-dire bien séparé en sous-agent, en contexte dédié, peut-être utiliser justement les grandes fenêtres de contexte pour mettre des documents. Parce que l'autre aspect aussi que je trouve pertinent, c'est qu'un peu historiquement, le RAG se focalisait essentiellement sur le texte, parce qu'avant, il n'y avait pas de modèle multimodal qui accepte les images, les vidéos, les audios, etc. Et en fait, justement, ce qui arrive, c'est que quand on a des PDF à ingérer, peut-être que, donc imagine des papiers d'introduction en bourse ou de recherche économique ou je ne sais quoi, tu vas avoir des graphes qui vont te montrer l'évolution de la population, l'évolution du cours d'une action. Mais ça va être dans un diagramme, ça va pas être forcément tu vas pas voir le tableau de toutes les valeurs sur la période. Voilà quelle est la valeur de l'action à tel jour, mais par contre le LLM, si lui, tu peux le faire embedder toutes les images, tous les diagrammes qu'il y a dans le PDF, ben le LL il va pas voir que la réponse en fait, elle est pas du tout dans le texte mais elle est dans l'image, donc là encore, les gros LLM avec des grosses fenêtres de contexte qui sont capables, et qui sont multimodaux qui sont capables de comprendre des images, des vidéos, etc., ils vont peut-être trouver l'information juste au bon endroit, dans la vidéo, dans le diagramme, dans la courbe, et où c'est finalement pas du texte. Donc, RAG reste pertinent, les grandes fenêtres de contexte restent pertinents, mais toute cette approche de contexte engineering, de bien séparer les choses, faire des sous-agents, des appels, vraiment juste avec les bonnes informations, ça, ça explose, quoi.
Bruno:
T'as évoqué effectivement ce terme de contexte engineering est-ce que c'est en train de devenir un vrai métier en tant que tel on commence à parler de contexte engineer ou est-ce que c'est juste une pratique une best practice dans la manière dont tout un chacun utilise ces outils là.
Guillaume:
Autant tu vois en 2023 on disait je vais devenir prompt engineer et après tu vois on arrive 2025-2026 on a beaucoup parlé de contexte engineering, donc est-ce qu'on devient un contexte engineer Et l'autre sujet dont on entend parler pas mal ces derniers temps, c'est Harness Engineering. C'est-à-dire qu'en fait, surtout pour les multi-agents, systèmes d'agents, etc., où en fait, la manière dont tu vas intégrer tous ces agents ensemble avec leur contexte, etc., tu vas essayer en fait de... C'est ça qu'on appelle le « harness engineering » pour essayer de tout mettre ensemble. Mais dans le « harness engineering », tu es obligé de faire du contexte engineering pour bien mettre la bonne information au bon moment dans le bon agent, de même que tu as toujours besoin de faire des promptes. Mais est-ce que ça devient un métier en soi ? Non, pas forcément, mais ça va être une des multiples facettes de ton travail avec l'IA, d'essayer de tout mettre ensemble, de trouver les meilleurs prompts, de trouver le meilleur contexte et d'organiser tout ça avec les outils, tes agents IA, etc.
Bruno:
Donc en fait, c'est aussi un peu tout ça, c'est une évolution du prompt engineering, qui en fait maintenant, le prompt engineering, au final, c'est plus juste de réussir à écrire le bon prompt, c'est le bien structuré, dans le bon endroit, de bien le découper entre les différents agents.
Guillaume:
Tout à fait.
Bruno:
Et j'avais aussi, en préparant du coup aussi cette intro, j'ai eu une espèce de... Parce que quand on parle de contexte, On pense bien évidemment à la guerre autour du prix du token qui est en train d'exploser. Mais ce qui est intéressant, c'est que le RAG, dans ce qu'il apporte dans le gain du LLM, au final, c'est de la donnée qui est statique. Et jusque là, jusqu'en 2000, c'est peut-être encore le cas aujourd'hui, je pense, quand tu regardes la grille tarifaire chez ton cloud provider, de la mémoire, ton S3, il ne te coûte pas très cher. La RAM, ça va coûter quand même un peu plus cher. surtout en ce moment, mais le CPU c'est ce qui coûte le plus cher et au final de ce que tu dis c'est que ton LLM est bien meilleur si tu gères bien ta mémoire et l'information que tu donnes est-ce que ça veut dire que toute la notion de l'inférence c'est du CPU qui coûte pas très cher, qui est pas très compliqué est-ce que ça va inverser la pyramide de coût, chez les groupes de valeur, il va falloir que cette gestion de la mémoire de la data qui va devenir le vrai coeur, des entreprises et va faire que notre S3 va prendre beaucoup plus cher par rapport au CPU d'aujourd'hui je sais pas.
Guillaume:
C'est une bonne question parce que là on voit qu'il y a effectivement cette, scarcité, je trouve plus le mot en français cette pénurie de mémoire et de GPU, etc donc ça je pense ça va quand même, perdurer malgré tout après je pense le stockage est quand même pas si cher que ça et a plutôt tendance à diminuer qu'à augmenter. Donc si je devais avoir une boule de cristal je ne sais pas trop comment ça va évoluer mais malgré tout pour revenir un petit peu sur le prix du token si on regarde quand même l'évolution des LLM même si peut-être qu'on a l'impression, qu'ils ont atteint un certain plateau peut-être donc qu'ils s'améliorent mais il faut voir aussi que, On arrive à faire, donc les grands providers font toujours des très très gros modèles, mais pas forcément aussi gros qu'ils l'étaient au début, et on s'aperçoit qu'on a des modèles quand même beaucoup plus puissants et capables, et qui sont pourtant plus petits que nos anciens modèles, et on voit une meilleure utilisation des ressources, des GPU d'entraînement et autres, Et par exemple, on faisait des comparatifs entre notre petit modèle open source Gemma avec le gros modèle Gemini. Donc là, on a sorti Gemma 4 en open-wait il n'y a pas très longtemps. Et il est aussi fort que notre plus gros modèle d'il y a un an ou quelque chose comme ça. Donc on arrive à avoir des modèles qu'on peut faire tourner sur des GPUs sur notre serveur. Pour lesquels il fallait de très très gros GPU qui coûtaient des dizaines et des dizaines, voire 100 000 dollars. Donc le coût du token, ou en tout cas de la bonne réponse, a vraiment beaucoup diminué ces dernières années, parce qu'on a des modèles plus pertinents, plus puissants, avec moins de paramètres, et du coup moins de bruit aussi dans les données d'entraînement, etc.
Bruno:
Ça montre bien que le calcul lui même, l'inférence de la réponse qui va consommer du CPU est de moins en moins, primordial parce qu'au final si je prends un RAG et que j'ai été très vigilant sur le modèle d'un bidding que j'ai fait du chunking propre bien pensé et compagnie au final que j'utilise, Cloudopus 4.7 ou ChatGPT on pourrait peut-être même dire ChatGPT3, au final la qualité des réponses sera à peu près la même.
Guillaume:
Le choix du LLM est moins prédominant, en particulier pour tout ce qui est RAC parce qu'on dit base ta réponse sur ce qu'il y a dans le contexte donc oui tout à fait on peut utiliser des modèles plus petits pour donner des bonnes réponses, et même parfois j'avais lu un article il n'y a pas très longtemps où il disait que même au contraire, donc je ne sais plus si c'était entre deux versions on va dire, je ne sais plus quel modèle le modèle un peu plus intelligent c'est un peu comme faire du mansplaining c'est à dire je sais mieux que ce que tu m'as mis dans mon contexte et je vais te donner ma réponse plutôt que de baser ma réponse sur ce que tu m'as donné et c'était rigolo parce que il a fallu refaire du prompt engineering pour trouver et s'assurer que le modèle se baserait que finalement sur, le contexte qu'on lui donne plutôt que sur son savoir intrinsèque de ses données d'entraînement etc. C'est assez rigolo, je trouve.
Bruno:
Je trouve ça assez bon. Ça veut dire qu'on commence à avoir des modèles qui font du human-splaining, qui nous expliquent en disant « Non, je sais mieux que toi ».
Guillaume:
Je sais mieux que toi.
Bruno:
Assez surprenant. Et donc, est-ce que tu penses qu'il va y avoir un... Je ne te demande pas de faire une prédiction au bout de cristal, parce que ce serait bien trop compliqué. Mais est-ce que tu penses qu'il va y avoir un changement de paradigme que vont apporter toutes ces IA sur le fait qu'elles montrent que l'intelligence, la capacité de calcul n'est pas plus importante que la base d'informations qui est à disposition.
Guillaume:
C'est vrai que... Même si tu regardes au niveau des investissements, des choix des fois stratégiques de certains acteurs, on s'est aperçu... Donc il y a très longtemps, tu sais, sur le big data, on disait plus t'as de data, plus t'auras de bonnes réponses. Et de même, plus tu as de garbage in, garbage out, parce que plus tu donnes d'informations et tu vas noyer le poisson finalement dans trop d'informations, alors qu'en fait, d'avoir de meilleures données d'entraînement, etc., plus pertinentes, ça reste, en tout cas pour les gros providers, ça reste très très important de faire un gros travail en amont sur la préparation. Données, etc., pour avoir des... en fait, finalement, avoir moins besoin de poids, et donc de mémoire, de GPU, etc., pour représenter le même savoir, parce qu'il y aura moins de bruit, de diffusion de choses sans intérêt. Donc ça, je pense que, tu vois, il y aura toujours ce nerf de la guerre, de la qualité de la donnée, même si avant, en big data, on se dit, oh, c'est pas grave, on me donne un gros data lake, c'est bon, on arrivera à trouver les informations, en fait, on s'aperçoit que la qualité de la donnée est primordial en.
Bruno:
Fait et c'est autant sur la pertinence de l'information que la manière dont elle est bien rangée bien cataloguée bien taguée aussi qui est importante dans le nombre de liens.
Guillaume:
Tout à fait.
Bruno:
Canon. Merci beaucoup, Guillaume, pour cette discussion. J'aurais deux dernières questions pour toi avant, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais recommander à l'ensemble des auditeuristes ?
Guillaume:
Alors, comme on a parlé pas mal de rag, alors c'est un shameless plug, comme on dit, mais sur mon blog, j'ai laforge.dev, j'ai publié différents articles qui expliquent certaines des techniques dont j'ai parlé, par exemple de générer des questions avec des LLM, etc. Pour le chunking donc il y a ça, il y a aussi mes supports de présentation donc c'est un peu présomptueux de dire allez regardez mon blog mais si vous voulez creuser en tout cas ce sujet là, j'ai pas mal écrit sur le sujet donc je vous invite à regarder mon blog très bien.
Bruno:
On mettra bien évidemment le lien en description, et enfin pour terminer la question la plus importante de ce podcast Guillaume tu es plutôt espace ou tabulation ?
Guillaume:
Je suis plutôt espace quand même sachant que tu vois moi j'aime bien 4 espaces, pour faire mes j'allais dire pour faire mes tabulations pour faire mes indentations, mais par exemple chez Google c'est 2 espaces donc je jongle un petit peu entre le code à 2 espaces et mon propre code à moi ou open source qui est plutôt à 4 espaces mais c'est des espaces très.
Bruno:
Bien je vois c'est noté merci beaucoup Guillaume.
Guillaume:
Merci et.
Bruno:
Merci à tous d'avoir suivi cet épisode voilà vous voyez le rag quand même encore de beaux jours devant lui et surtout le contexte engineering pensez à bien. Ingénérer effectivement la manière dont vous faites appel à vos agents, leur donner les bonnes informations, puisque exploiter le contexte Windows de 1 million de tokens c'est pas forcément un flex, c'est peut-être même au final l'inverse de mon côté comme toujours je vous remercie de partager ce podcast autour de vous, je vous invite à aller voir les différentes choses autour du podcast, pour aller voir notamment le MCP qui reste comme un produit sympa, qui peut être intéressant à tester qui est aussi un bon moyen de soutenir le podcast il y a aussi la page Tipeee bien évidemment, bref il y a tout un tas de trucs si vous voulez soutenir ce podcast, en tout cas moi je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.
