스크립트
00:00:00Bonjour à tous. Merci d'être venus aujourd'hui. Bienvenue à une conférence sur rien. Désolé, une conférence sur
00:00:21la recherche d'informations. Je m'appelle Yuval. Je travaille chez AI21, qui est essentiellement un laboratoire de recherche en IA. Et aujourd'hui,
00:00:29je veux vous parler de quelque chose dont la plupart des gens ne veulent pas parler, c'est-à-dire le découpage en blocs.
00:00:37Et j'espère vous convaincre d'ici la fin que le découpage n'est pas mort et qu'il y a des choses à faire avec.
00:00:45Et vraiment, si vous êtes sur X, LinkedIn, ou ailleurs, vous avez probablement vu que le RAG est mort, n'est-ce pas ?
00:00:53Je crois que les gens ont aussi tué le MCP récemment. Et le RAG est mort à nouveau. Longue vie à la recherche organique,
00:01:00à la recherche organique. Et vient un moment où l'on doit se demander : combien de fois le RAG peut-il mourir ?
00:01:07N'est-ce pas ? Et même quand quelqu'un dit, eh bien, le RAG n'est pas mort, comme Jerry, le PDG de Llama Index,
00:01:14ils doivent quand même tuer quelque chose. Et apparemment, ce quelque chose, c'est le découpage en blocs. Genre, n'investissez pas dedans.
00:01:23Ne le faites pas. Et c'est la raison pour laquelle les gens disent que le découpage est mort, parce que tout le monde utilise
00:01:30la recherche agentique maintenant, n'est-ce pas ? Vous avez grep, vous avez ls, vous avez find. Tout cela est formidable,
00:01:36mais ce n'est toujours pas suffisant si vous avez beaucoup de données et une grande variété de requêtes.
00:01:46Juste une seconde. D'accord. Et je pense que la raison principale pour laquelle beaucoup de gens n'aiment pas parler
00:01:51du découpage, c'est parce que ce n'est pas la partie amusante, n'est-ce pas ? Dans tout système RAG ou de fichiers,
00:02:00nous avons deux étapes. La première étape est la plus ennuyeuse, si l'on peut dire. Celle qu'on fait au début,
00:02:07on a beaucoup de données. Il faut les prétraiter. Il faut choisir la taille des blocs. Et ensuite,
00:02:13il faut stocker le tout dans une base de données vectorielle. L'autre partie est la partie recherche, essentiellement celle
00:02:20qui s'effectue par requête. C'est quelque chose de beaucoup plus facile à faire, n'est-ce pas ? C'est beaucoup plus facile à
00:02:25optimiser. On peut utiliser toutes nos requêtes et puis jouer avec le max K, le top K, désolé, on peut jouer
00:02:32avec la recherche hybride peut-être, ce genre de choses. C'est beaucoup plus amusant d'ajuster la recherche, n'est-ce pas ?
00:02:40Je soutiendrai donc que si nous devons tuer quelque chose, si quelque chose doit mourir, c'est probablement
00:02:47l'optimisation de la recherche. Et oui, la recherche agentique a probablement tué cela. Mais pourtant, la recherche agentique, même si l'on
00:02:55peut accepter le fait qu'elle a tué l'optimisation de la recherche, n'est toujours pas assez bonne quand on a beaucoup de
00:03:02données. Cela coûte beaucoup d'argent. Je ne pense pas avoir besoin de le mentionner encore. La maximisation des jetons
00:03:09est un sujet dont tout le monde parle. Et le problème sous-jacent, c'est que si les données elles-mêmes
00:03:17n'est pas bien ordonnée dans vos dossiers ou répertoires, vous obtenez toujours quelque chose
00:03:25d'inefficace. Prenons un exemple d'actualité. La Coupe du monde de la FIFA a lieu en ce moment.
00:03:33que nous ayons un ensemble de données contenant toute l'histoire de la Coupe du Monde. Donc chaque répertoire est, disons,
00:03:40celui de 98, celui de 2002, et ainsi de suite. Mais si votre requête demande quelle équipe a gagné le plus de Coupes du Monde,
00:03:50vous ne pouvez pas simplement aller dans un dossier pour y accéder. Vous devez aller dans chaque dossier, voir qui a gagné,
00:03:57puis agréger tout cela, ce qui est très inefficace. La réponse immédiate est le Brésil, je l'espère, du moins
00:04:03au moment où cette conversation a lieu. La recherche n'est donc pas vraiment morte. Nous ne tuons
00:04:13rien dans cette présentation. Elle a simplement été reléguée au rang de plomberie. Et je pense que tous ceux qui ont travaillé
00:04:21sur un système RAG connaissent ce sentiment. Le premier jour, ou la première semaine, ou peut-être même le premier mois si vous êtes très minutieux,
00:04:29vous choisissez une taille de bloc. Disons 512. Et vous y ajoutez probablement un chevauchement,
00:04:36n'est-ce pas, 10 %, 20 %, etc., vous indexez le tout, et vous oubliez complètement. Et c'est possible, n'est-ce pas,
00:04:43nous parlons beaucoup des stratégies de découpage fixe, où si votre bloc est trop grand,
00:04:49eh bien, vous obtenez une vue d'ensemble, ce qui est bien, mais vous perdez beaucoup de nuances. Et tous les
00:04:54blocs n'auront pas des représentations vectorielles pertinentes. Alors que si vous choisissez des blocs trop petits,
00:05:00vous perdez la vue d'ensemble. Et vraiment, ce ne sera pas aussi efficace. Ce que cela nous indique, c'est
00:05:07que le découpage en blocs est essentiellement une compression avec perte. Quoi que nous fassions, nous perdons quelque chose.
00:05:15Et je prétendrai qu'il n'y a pas de taille de bloc idéale. Et beaucoup d'entre vous qui ont travaillé sur des données diront,
00:05:23non, mais nous avons ce corpus, nous avons cet ensemble de données, et nous avons vraiment utilisé et optimisé notre système pour
00:05:29qu'il fonctionne très, très bien sur ces données. Et nous le pensions aussi. Nous avions beaucoup d'expérience avec cela,
00:05:35avec de nombreux types d'agents, de systèmes et de flux de travail différents, et vous pouvez vraiment,
00:05:40et, n'est-ce pas, pensez aux benchmarks, à quel point il est facile de surajuster son modèle à un benchmark.
00:05:48Mais pas avec le RAG. Cela ne se produit pas là. Et vous ne pouvez pas vraiment l'optimiser par ensemble de données. Et je vais
00:05:54vous montrer comment vous assurer qu'il dépend des requêtes. Et comment puis-je en être si sûr ? Comment puis-je affirmer une telle
00:06:00chose ? Parce que nous avons mené des expériences, nous les avons testées, et maintenant je vais vous les présenter. Donc ce que nous
00:06:06avons fait, au lieu de chercher la meilleure taille de bloc par données, découvrons-la. Prenons
00:06:14un ensemble de données et dupliquons-le plusieurs fois. Dans ce cas, six fois. Dans chaque duplication,
00:06:23dans chaque instance, la taille des blocs est différente. Nous avons donc une base de données avec des blocs de 2 000,
00:06:28une base de données avec des blocs de 1 000, et ainsi de suite. Et nous l'avons fait avec plusieurs ensembles de données,
00:06:36comme QMSUM, qui est un ensemble de données de transcriptions de réunions. Narrative QA, qui concerne la lecture de questions-réponses sur
00:06:41des romans. Et l'ensemble de données Seinfeld, qui est un jeu-questionnaire sur rien. Enfin, pas vraiment. Ce sont des questions de culture générale
00:06:49sur les transcriptions de Seinfeld. C'est un peu un jeu de données provocateur que nous avons créé en interne. Nous l'avons également
00:06:56publié si quelqu'un veut le lien à la fin. Et nous avons testé sur tous ces ensembles pour voir ce qui se passe.
00:07:03Et tout d'abord, nous voulions simplement voir, pour chaque ensemble de données, quelle taille de bloc est la meilleure. Et ce que
00:07:10nous voyons ici est un exemple tiré de l'ensemble de données Seinfeld, où essentiellement deux requêtes de nature
00:07:16différente obtiennent des résultats différents selon la taille des blocs. La première question, par exemple : quel est
00:07:24le nom de la chemise préférée de Jerry ? Vous voyez que c'est une question très ciblée, très précise.
00:07:28La réponse y est probablement très circonscrite. Et c'est pour cela qu'une plus petite taille de bloc
00:07:33fonctionnera le mieux. Et vous pouvez voir le rang un par rapport à un rang inférieur à 50. Entre une taille de bloc fixe
00:07:43de 100 tokens. Alors qu'une question comme : qui Jerry décrit-il comme son némésis et l'incarnation du mal,
00:07:50et je ne suis même pas si grand fan de Seinfeld que ça, et je sais que c'est Newman. Mais si vous regardez le
00:07:56texte, ce n'est pas quelque chose que l'on trouve aussi facilement. Et vous voyez que cela change vraiment, n'est-ce pas ? Si vous utilisez
00:08:02une petite taille de bloc, vous n'obtiendrez pas la réponse. Et ce que nous avons fait pour vraiment -- après avoir exécuté
00:08:10toutes ces analyses, nous nous sommes dit : et si nous avions un oracle, ou un génie si l'on veut,
00:08:19capable de nous dire, pour chaque requête, quelle est la meilleure taille de bloc à utiliser pour la recherche ? C'est essentiellement l'expérience
00:08:25de l'oracle. C'est ce que nous voulions savoir pour voir le potentiel. Ce n'est pas -- nous avons déjà la
00:08:33capacité de construire un système ici. Nous voulons simplement voir quel est notre potentiel. Et ce que vous pouvez
00:08:38voir ici, sur ce graphique, toutes les lignes bleues -- tout d'abord, l'axe des ordonnées représente le rappel. Plus il est élevé, mieux c'est. L'axe
00:08:46des abscisses représente le nombre de blocs récupérés. C'est donc le rappel à k en fonction de k. Vous pouvez voir toutes les lignes bleues,
00:08:52probablement indiscernables, mais chacune d'elles correspond aux performances pour une taille de bloc fixe. Alors que la ligne orange est la
00:09:01ligne de l'oracle. C'est -- pour chaque requête, nous avons pris la meilleure parmi toutes ces options. Et vous pouvez voir que cela se produit
00:09:09sur plusieurs ensembles de données. Dans un grand nombre d'entre eux, vous pouvez effectivement voir que les lignes bleues se croisent
00:09:16entre elles, ce qui signifie qu'en effet, pour beaucoup d'ensembles de données, aucune taille de bloc ne domine réellement. Et ce qui est
00:09:24plus intéressant, c'est qu'il y a un énorme potentiel. L'écart que vous pouvez voir entre la ligne orange
00:09:30et toutes les lignes bleues est important. Et quand je dis important, c'est de l'ordre de 20 à 40 pour cent rien qu'en
00:09:38optimisant la stratégie de découpage. Et une stratégie très simple, dois-je ajouter. Et cet écart, c'est ce que
00:09:47le choix de 512 ou 1 000 ou autre, n'est-ce pas ? Ce chiffre est purement arbitraire. C'est ce que cela vous coûte. Et je
00:09:56pense que le problème ici est -- c'est un peu délicat parce que c'est un problème d'information : nous ne disposons pas de
00:10:07l'information dont nous avons besoin à chaque étape. Et qu'est-ce que je veux dire par là ? Si je regarde la partie indexation,
00:10:12où j'ai le contrôle sur la taille des blocs, je ne sais pas quelles seront les requêtes.
00:10:18Je peux deviner. Je peux peut-être estimer. Je peux essayer. Mais je ne sais pas quelles seront les requêtes, donc je ne peux pas
00:10:25ajuster la taille de mes blocs en conséquence. Et lors de la recherche, là où j'ai mes requêtes,
00:10:31je ne peux pas contrôler la taille des blocs, n'est-ce pas ? Elle est déjà fixée. Et je ne vais évidemment pas refaire tout
00:10:37le processus pour chaque requête depuis le début. Nous avons donc examiné des travaux antérieurs, notamment
00:10:47la recherche contextuelle entropique, où ils enrichissent chaque bloc, ainsi que d'autres approches qui tentent essentiellement d'améliorer l'espace
00:10:54latent de chaque bloc. Mais ce n'est pas la direction que nous avons prise. Toutes ces méthodes s'en tiennent au modèle
00:11:01qui consiste à travailler avec une taille de bloc fixe, alors que nous avons adopté une approche différente. Nous nous sommes dit : pourquoi se limiter
00:11:08à une seule taille quand on peut en utiliser plusieurs ? C'est ce que nous appelons l'indexation multi-échelle. Essentiellement, nous faisons
00:11:16ce que nous avons vu avant. Nous prenons la base de données, nous la dupliquons et la découpons avec plusieurs
00:11:26tailles de blocs ou de fenêtres. Ça, c'est ce qui se passe lors de l'indexation. Et ensuite, au moment de la recherche,
00:11:34nous les interrogeons toutes. Si nous avons n doublons de la base de données avec différentes tailles de fenêtres, nous devons maintenant exécuter
00:11:43six appels de recherche différents par requête. Enfin, six en tant que n. Et comment les combiner ? Nous ne pouvons évidemment pas
00:11:52utiliser l'oracle, n'est-ce pas ? L'oracle n'est là que pour illustrer le potentiel. Dans la vraie vie,
00:11:57nous ne connaissons pas la réponse. Mais ce que nous pouvons faire, c'est trouver une sorte d'algorithme de fusion. Maintenant, vous diriez,
00:12:06quand on regarde les choses ainsi, quel peut être le problème ? Le fait que nous ayons n classements,
00:12:13mais que ces classements concernent des blocs. Et des blocs de tailles différentes ne sont pas vraiment comparables,
00:12:19n'est-ce pas ? Nous avons donc plutôt choisi de faire quelque chose qui est assez populaire de nos jours. Et beaucoup de
00:12:25systèmes RAG fonctionnent ainsi : au lieu de récupérer simplement le segment, quand nous avons un
00:12:30segment, nous récupérons le document entier. Quand la fenêtre de contexte s'élargit, nous voulons donner de plus en
00:12:35plus de contexte. Et ici, nous avons n classements pour les mêmes documents, car ce ne sont
00:12:44plus des segments. Et ça, nous pouvons le comparer. Dans ce cas, vous pouvez voir la recherche comme
00:12:50un simple vote. D'accord ? Ce n'est donc pas purement du classement. Nous n'avons pas un classement suivi d'un
00:12:56reclassement. Nous avons n rangs différents pour les documents pertinents, et nous voulons les agréger
00:13:03tous en un seul. C'est pourquoi nous utilisons la méthode RRF (Reciprocal Rank Fusion), qui est une
00:13:11formule assez simple. Nous avons essayé plusieurs approches, celle-ci a le mieux fonctionné. Et comme vous le voyez, ce n'est pas un
00:13:17modèle. Ce n'est pas quelque chose que vous devez faire spécifiquement. C'est juste un
00:13:23script simple qui ne prend vraiment aucun temps. Et voici à quoi ressemble le système complet. Nous avons
00:13:32l'indexation n fois, puis nous interrogeons chaque requête dans chaque base de données, et nous utilisons RRF pour les combiner
00:13:40toutes. Et les résultats, vous devinez qu'ils sont bons. Sinon, je ne serais pas là
00:13:48avec autant d'assurance. D'accord ? Mais vous voyez, nous avons fait des tests sur plusieurs jeux de données, QMSum,
00:13:56Narrative QA, Seinfeld, ainsi que Finance Bench. Nous les avons tous pris, et cela surpasse nettement la
00:14:05taille fixe. Voyons cela sur un graphique. C'est un peu dur à voir ici, donc je vais expliquer doucement. Chaque ligne
00:14:12représente la taille du segment. Vous voyez 50, 100, etc. La ligne du bas est notre méthode. Celle-ci, celle
00:14:21qui extrait à partir de tout et combine ensuite. Et chaque colonne est le rappel à un certain seuil : rappel à un,
00:14:31deux, trois, jusqu'à 10. Ce qu'on observe ici, c'est deux choses, d'accord ? D'abord, sur
00:14:39n'importe quel niveau de rappel, notre méthode gagne toujours, ce qui peut sembler facile, mais le fait de
00:14:46devoir tout combiner n'est pas du tout trivial. Vous pouvez aussi voir que la qualité
00:14:53augmente réellement. La carte thermique devient nettement plus verte. Et encore une fois, c'était juste
00:14:58quelque chose que je voulais vous montrer en grand. Ici, vous voyez les quatre jeux de données où nous obtenons
00:15:06de meilleurs résultats. Vraiment de l'ordre de 20, 30, voire 40 % sur plein de points. Il y a aussi des résultats
00:15:14que je ne vous ai pas montrés ici, qui sont sur MTab. Vous pouvez voir sur notre blog, je mettrai le lien plus tard, nous y obtenons
00:15:22aussi de grosses améliorations, entre 10 et 40 % selon le jeu de données.
00:15:30Maintenant, je ne suis pas naïf. Je ne vais pas prétendre ici que ça ne coûte rien. Évidemment, il y a un coût,
00:15:36pas de repas gratuit. Tout a un prix. Et oui, cela coûte de la mémoire supplémentaire.
00:15:43Cela coûte entre 2 et 5, un O(1), une constante de mémoire additionnelle pour conserver
00:15:51toutes ces copies de la base de données. Cependant, si vous y pensez, en matière de latence, cela n'a pas vraiment
00:15:59d'impact car la recherche peut se faire en parallèle. Et la partie RRF ne prend pas vraiment beaucoup de temps.
00:16:10C'était un projet de recherche très sympa qu'on a mené, et on a obtenu des résultats vraiment super.
00:16:16Il reste des choses à faire, des axes d'amélioration et des travaux futurs. Plus précisément,
00:16:23nous voulons comprendre combien de tailles de segments il nous faut et lesquelles. Le fait d'avoir travaillé avec 50, 100,
00:16:32200, etc., était assez arbitraire, pour être honnête. Nous devons donc trouver comment calculer cela et
00:16:40savoir exactement combien de copies sont nécessaires. Il faut aussi aller au-delà de RRF. Le fait qu'on
00:16:46utilise RRF, c'est parce que c'est ce qui marchait le mieux parmi nos essais, mais ça ne veut pas dire qu'il n'y a
00:16:52pas de meilleure méthode. Et si je devais vous laisser sur une idée, je dirais que les agents n'ont pas tué
00:16:59la recherche documentaire. Rien n'est mort, voyons. C'est juste de l'infrastructure. Et le problème, c'est que c'est
00:17:07une infrastructure de 2022. Avec des méthodes vraiment simples, vous pouvez prendre votre système RAG ou tout ce qui a
00:17:17un rapport avec le stockage de données puis leur recherche, et l'améliorer de 20 à 40 %, encore une fois, sans rien de trop
00:17:26sophistiqué. Si vous voulez en lire plus, vous pouvez consulter le blog. Il y a aussi un exemple de
00:17:34code ainsi que le jeu de données Seinfeld. Et voilà. Je suis Yuval. Merci beaucoup d'être venus.
00:17:47À la prochaine.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기