La sémantique est un souhait, l'indexation est un fait

C’est une question à la fois très actuelle et parfaitement centrée sur les vrais problèmes. L’essor de PageIndex et du No-Vector RAG (RAG sans vecteurs) constitue en réalité une réflexion critique et une correction des limites du Vector RAG dominant (génération augmentée par la recherche fondée sur une base de données vectorielle).

En termes simples, PageIndex est une technologie fondée sur un index inversé (Inverted Index), conçue pour trouver précisément, par correspondance de mots-clés, les « pages (Page) » pertinentes ou le contexte complet, plutôt que de dépendre d’une recherche sémantique floue de fragments au moyen de vecteurs.

Je vais maintenant vous expliquer en détail le concept de PageIndex et les raisons pour lesquelles nous commençons à nous tourner vers le « RAG sans vecteurs », ou à le combiner avec lui.

---

1. Qu’est-ce que PageIndex ?

Dans le Vector RAG traditionnel, nous découpons les documents en petits blocs (Chunks), nous les transformons en vecteurs, puis nous recherchons les vecteurs similaires.
Avec le mode PageIndex, la logique revient aux origines des moteurs de recherche :

1. Phase d’indexation : le système ne découpe plus les documents et ne les vectorise plus ; il construit un index inversé global (semblable à l’index situé à la fin d’un livre). Celui-ci indique sur quelles pages (Pages) ou dans quels documents apparaît chaque mot-clé (Keyword).
2. Phase de recherche : lorsque l’utilisateur pose une question, le système extrait les mots-clés de la question et localise directement, grâce à l’index inversé, les pages complètes qui contiennent ces mots-clés.
3. Phase de génération : le système fournit à l’LLM (grand modèle de langage) le contenu de ces pages complètes (plutôt que des Chunks fragmentés) comme contexte, afin que l’LLM les lise, les comprenne et en extraie lui-même la réponse.

Différence essentielle : le Vector RAG fournit à l’LLM des « paragraphes découpés en morceaux » ; PageIndex lui fournit des « pages complètes contenant les indices ».

---

2. Pourquoi adopter le « RAG sans vecteurs » (No-Vector RAG) ?

Bien que le Vector RAG soit populaire, sa mise en œuvre concrète a révélé trois problèmes fondamentaux ; le RAG sans vecteurs vise précisément à les résoudre :

A. La fragmentation sémantique provoquée par le « découpage » (The Chunking Problem)

• Problème du Vector RAG : pour stocker un long document dans une base vectorielle, il faut le découper en blocs de 500 à 1 000 caractères. Cela entraîne une perte de contexte. Par exemple, la « clause de manquement au contrat » peut se trouver à la page 5, tandis que le « montant de l’indemnisation » se trouve à la page 10. La recherche vectorielle peut ne récupérer que le bloc de la page 5, empêchant l’LLM de répondre à une question nécessitant une logique complète.
• Avantage du No-Vector : PageIndex recherche des Pages ou des Documents. L’LLM dispose ainsi d’une fenêtre de contexte plus longue (avec la prise en charge par les modèles de 128k/200k/1M tokens, cela devient possible) et peut comprendre les relations logiques entre les paragraphes.

B. Correspondance floue contre correspondance exacte (Fuzziness vs. Precision)

• Problème du Vector RAG : la recherche vectorielle repose sur une recherche floue fondée sur la « similarité sémantique ».
  • Exemple : si vous recherchez « code d’erreur 1024 », le vecteur peut retrouver du contenu relatif au « code d’erreur 1025 », car les deux sont proches dans l’espace mathématique ; pour un programmeur, c’est pourtant totalement faux.
  • Échec sur les termes spécifiques : lors de la recherche d’un numéro de SKU particulier, d’un nom ou de mots très rares, les vecteurs échouent souvent.
• Avantage du No-Vector : l’index inversé repose sur une correspondance exacte. Si vous recherchez « 1024 », il ne fournit que les pages contenant « 1024 ». C’est essentiel dans les domaines exigeant de la rigueur, comme le droit, la finance ou le code.

C. Opacité et coût de maintenance (Black Box & Complexity)

• Problème du Vector RAG : le vecteur est une boîte noire. Vous ne savez pas pourquoi le système considère A et B comme similaires. De plus, la maintenance d’une base de données vectorielle (Vector DB) performante est coûteuse, et la mise à jour de l’index (ajout, suppression, modification et recherche) est plus complexe que dans une base de données traditionnelle.
• Avantage du No-Vector : la recherche fondée sur les mots-clés est entièrement explicable (« parce que cette page contient ces trois termes de recherche »). En outre, les technologies d’index inversé (comme Lucene, ElasticSearch) sont déjà très matures, peu coûteuses et efficaces.

---

3. PageIndex contre Vector RAG : comparaison essentielle

Pour comprendre plus intuitivement, nous pouvons comparer ces deux architectures :

---

4. Pourquoi cela ne devient-il populaire que maintenant ? (Contexte technologique)

Vous vous demandez peut-être : « L’index inversé n’est-il pas une technologie vieille de plusieurs décennies ? Pourquoi n’en parle-t-on que maintenant ? »

C’est parce que la fenêtre de contexte (Context Window) des LLM s’est agrandie.

• Avant (début 2023) : les LLM ne pouvaient lire que 4k tokens. Si vous insériez une page entière (pouvant contenir 2k tokens), deux pages suffisaient à remplir la fenêtre. Il fallait donc découper le texte (Vector RAG).
• Aujourd’hui : Claude 3 prend en charge 200k tokens, et Gemini 1.5 Pro prend en charge plus de 1M de tokens.
• Résultat : nous n’avons plus besoin de nous donner beaucoup de mal pour « découper » le savoir en morceaux. Il suffit d’utiliser PageIndex pour localiser rapidement, même, par exemple, 10 pages pertinentes, puis de fournir toutes ces 10 pages à l’LLM en lui disant : « Lis dans cette zone et trouve-moi la réponse. »

Ce mode « Retrieve Pages -> LLM Reads All » donne souvent de meilleurs résultats que « Embed Chunks -> Retrieve Chunks -> LLM Guesses ».

---

Conclusion

Mettre en place un RAG sans vecteurs (PageIndex) ne signifie pas abandonner complètement les vecteurs, mais résoudre les problèmes de recherche vectorielle qui est « pas assez précise » et qui « perd le contexte ».

• Vector RAG ressemble à un bibliothécaire très intuitif : il sait plus ou moins quels livres sont liés à votre question, mais il ne vous en arrache que quelques pages.
• PageIndex ressemble à un système d’indexation rigoureux : il ouvre toutes les pages qui mentionnent les mots-clés et vous laisse, à vous (l’LLM), lire le contenu du chapitre dans son ensemble.

La tendance future est l’approche hybride (Hybrid RAG) : utiliser d’abord PageIndex pour garantir la couverture des mots-clés (précision), puis les vecteurs pour compléter les éléments sémantiques manquants (généralisation).

Souhaitez-vous ensuite que je vous montre un exemple simple de code Python comparant, dans une implémentation réelle, la « recherche fondée sur les vecteurs » et la « recherche fondée sur un index de mots-clés » ?

C’est une question très pertinente. Si vous avez l’impression que le Vector RAG est « si mauvais », c’est parce que nous l’avons abordé précédemment en opposant la précision (le point fort de PageIndex) à son caractère flou (le point faible du Vector RAG).

En réalité, le Vector RAG est aujourd’hui la technologie la plus répandue. Il n’est pas « mauvais » ; il a simplement sacrifié la « précision » au profit de la « généralité ».

Pour répondre à votre question, nous devons examiner la logique interne du Vector RAG et voir comment il « compresse » et « démembre » exactement les longs textes.

---

I. Comment fonctionnait l’ancien Vector RAG ? (Processus standard)

La logique centrale du Vector RAG consiste à transformer le texte en coordonnées mathématiques. Son fonctionnement se divise généralement en quatre étapes :

1. Découpage (Chunking) :

• On commence par découper un long document (par exemple un PDF de 100 pages) en une multitude de petits paragraphes.

• Par exemple, un bloc tous les 500 caractères.

• Conséquence : la logique cohérente de l’article est interrompue de force.

2. Vectorisation (Embedding) :

• On utilise un modèle (comme le text-embedding-3 d’OpenAI) pour transformer ces 500 caractères en une série de nombres (généralement 1 536 nombres à virgule flottante).

• Cette série de nombres représente la « position sémantique » de ce passage.

3. Stockage (Indexing) :

• On stocke cette série de nombres dans une base de données vectorielle (Vector DB).

4. Recherche (Retrieval) :

• Lorsque vous posez une question, celle-ci est également transformée en une série de nombres.

• La base de données calcule quels nombres de passages sont les plus proches de ceux de votre question (similarité cosinus), puis récupère ces passages.

---

II. Comment les longs textes sont-ils « compressés » ? (Principe essentiel)

C’est la partie la plus technique de votre question. Au cours de ce processus, le texte est compressé deux fois, ce qui constitue la source de la perte d’information.

1. Compression au niveau physique : le découpage (The Chunking)

Imaginez que vous regardez un film (un long texte) et qu’un monteur découpe la pellicule en une multitude de courtes vidéos de 30 secondes (Chunks).

• Problème : si une réplique traverse le point de montage, avec la première moitié dans le segment 1 et la seconde dans le segment 2, lorsque vous ne récupérez que le segment 1, vous ne savez absolument pas ce qui est dit. C’est la perte de contexte.

2. Compression au niveau sémantique : Embedding (The Embedding)

C’est l’étape la plus abstraite. La « vectorisation » est en réalité une compression sémantique extrêmement destructive.

• Principe : le modèle d’Embedding lit ces 500 caractères, puis tente d’utiliser 1 536 dimensions (nombres) pour résumer ce dont ils parlent.

• Analogie : imaginez que vous deviez présenter votre ami à quelqu’un (le long texte).

• Présentation complète (texte original) : « Il s’appelle Xiao Ming, il aime manger épicé, il a peur des chiens parce qu’il a été mordu par un chien quand il était enfant, et il vient de vivre une rupture… »

• Vectorisation (après compression) : [Taille : 180, Poids : 70 kg, Sexe : homme, Indice émotionnel : 0,2]

• Pourquoi est-ce « mauvais » ?

• Cette compression perd les détails. Si votre question est « Que s’est-il passé dans l’enfance de Xiao Ming ? », il est impossible de déduire le détail « il a été mordu par un chien » à partir de cette simple série de nombres (taille et poids).

• En pratique, l’Embedding compresse un texte riche en un « thème général » flou. Il retient que « ce passage concerne des informations personnelles », mais peut oublier le « numéro de téléphone » précis.

---

III. Pourquoi le Vector RAG donne-t-il une impression de « médiocrité » ?

Ce n’est pas que la technologie soit intrinsèquement mauvaise ; elle présente des défauts naturels lorsqu’elle traite des tâches à forte densité de connaissances, notamment les trois suivants :

1. Le « flou » entraîne des « hallucinations »

La recherche vectorielle repose sur la « similarité ».

• Exemple : vous recherchez une boisson sans sucre.

• Résultat vectoriel : il peut vous recommander une « boisson sucrée ».

• Raison : dans l’espace mathématique, « avec sucre » et « sans sucre » sont très proches, car les deux expressions parlent de sucre et de boissons. Les vecteurs ont du mal à distinguer le petit mot « sans ». L’index inversé (correspondance de mots-clés), lui, ne commet pas cette erreur, car il doit faire correspondre le mot « sans ».

2. Le « découpage » détruit la logique

De nombreux documents complexes (comme les contrats juridiques ou les manuels techniques) exigent une compréhension qui traverse plusieurs paragraphes.

• Situation : la définition se trouve à la page 1, tandis que les instructions concrètes figurent à la page 10.

• Vector RAG : il peut retrouver les étapes d’exécution de la page 10, mais comme il a découpé la page 1, l’LLM ne sait absolument pas ce que signifie le terme spécifique qui y est mentionné et commence alors à inventer.

3. La « boîte noire » empêche l’optimisation

• Lorsqu’un utilisateur pose une question et que la base vectorielle récupère les mauvais fragments, il est difficile pour le développeur de déboguer le système.

• Vous ne savez pas pourquoi cette suite de 1 536 nombres et cette autre suite de nombres ont été jugées « similaires ». Le système devient donc difficile à optimiser.

---

Conclusion : pourquoi utilisons-nous encore le Vector RAG ?

Bien qu’il présente de nombreux défauts, le Vector RAG possède un avantage incomparable à celui de PageIndex : il comprend le sens implicite du « langage humain ».

• Utilisateur : « Ma voiture ne démarre pas. »

• Document : « Une batterie déchargée peut empêcher le moteur de démarrer. »

Dans ce cas :

• PageIndex (mots-clés) peut échouer, car l’utilisateur n’a parlé ni de « batterie » ni de « démarrage impossible ».

• Vector RAG (vecteurs) réussira, car il sait que « ne pas réussir à démarrer » et « échec du démarrage » sont sémantiquement équivalents.

Conclusion : si l’ancien Vector RAG vous donne l’impression d’être « mauvais », c’est parce qu’il constitue une « synthèse floue ». PageIndex, en revanche, est une « localisation précise ». La tendance actuelle est de ne plus compresser les textes. À mesure que les LLM peuvent lire un million de caractères en une seule fois, nous sommes de plus en plus enclins à fournir directement à l’LLM le « texte original non compressé », afin que le modèle le plus intelligent le lise lui-même, plutôt que de dépendre de cet « intermédiaire qui ne sait calculer que la taille (le modèle vectoriel) ».

Votre intuition est très pertinente. En réalité, le « découpage sémantique (Semantic Chunking) » et la réduction de la granularité (« Small-to-Big ») sont précisément les deux grandes orientations actuelles de l’optimisation du RAG.

Personne ne « s’en abstient » ; ces approches entraînent simplement chacune de nouveaux effets secondaires.

C’est comme découper un gâteau :

• Découpage de taille fixe (traditionnel) : on coupe tous les 5 centimètres, sans se poser de questions. C’est simple et brutal, et les motifs risquent d’être abîmés.

• Découpage sémantique : on suit les motifs. Le résultat est meilleur, mais le découpage est lent et il est très difficile de définir où se termine un « motif ».

• Découpage plus fin : on réduit le gâteau en miettes. Chaque bouchée est mangeable, mais on ne sait plus si la miette appartenait aux fraises du dessus ou à la base du dessous.

Voici pourquoi ces deux solutions n’ont pas entièrement résolu le problème :

---

I. Pourquoi le « découpage sémantique » ne s’est-il pas généralisé ?

Le découpage sémantique consiste à utiliser un modèle NLP pour déterminer si « cette partie du texte est terminée », puis à la découper, plutôt que de couper mécaniquement selon le nombre de caractères.

Bien que cela semble parfait, la mise en œuvre technique comporte trois pièges majeurs :

1. Lenteur et coût (Latency & Cost)

• Le découpage traditionnel par nombre de caractères se règle en une ligne de code Python text[0:500] et prend 0,0001 seconde.

• Le découpage sémantique exige qu’un modèle « lise » le texte, calcule la similarité entre les phrases adjacentes ou demande à l’LLM de déterminer si « le sujet change ici ». Le traitement d’un gros fichier peut prendre plusieurs minutes, voire davantage. C’est inacceptable pour les systèmes qui exigent une réponse en temps réel.

2. Les limites de la « sémantique » sont extrêmement floues

• Exemple : un paragraphe commence par parler du « prix du produit », puis enchaîne sur la « politique de remboursement ».

• Faut-il couper à la fin de la partie sur le « prix » ? Mais si vous coupez à cet endroit, le RAG sera démuni lorsque l’utilisateur demandera : « À quel prix ce produit est-il remboursé ? », car le « prix » se trouve dans un bloc et le « remboursement » dans l’autre ; le lien entre les deux est interrompu.

3. Le « découpage sémantique » ne résout toujours pas les dépendances globales

• Même si vous découpez parfaitement par paragraphes, chaque paragraphe peut toujours dépendre d’une définition située plusieurs pages auparavant.

• Par exemple, le paragraphe de la page 10 dit : « Exécuter conformément à l’accord susmentionné… »

• Le découpage sémantique garantit que ce paragraphe est complet, mais il n’inclut toujours pas l’« accord susmentionné » de la page 1.

---

II. Pourquoi ne pas découper les paragraphes plus finement ?

Vous pourriez vous dire : « Si un découpage trop large contient du bruit, je n’ai qu’à découper au niveau de la phrase (Sentence Level) ; il me suffira d’utiliser la phrase retrouvée, ne serait-ce pas plus précis ? »

Cela touche au paradoxe le plus classique du domaine du RAG : granularité de la recherche contre granularité de la compréhension.

Un découpage trop fin (par exemple phrase par phrase) entraîne les problèmes critiques suivants :

1. La catastrophe des pronoms (The Pronoun Problem)

• Texte original : « Elon Musk a fondé SpaceX. Cette entreprise a considérablement réduit le coût des lancements de fusées. »

• Après découpage (granularité fine) :

• Bloc A : « Elon Musk a fondé SpaceX. »

• Bloc B : « Cette entreprise a considérablement réduit le coût des lancements de fusées. »

• Recherche : l’utilisateur demande « Qu’est-ce qui a réduit le coût des lancements ? »

• Résultat : le vecteur retrouve le bloc B.

• Présenté à l’LLM : l’LLM voit « Cette entreprise a réduit les coûts ». Il se demande : « De quelle entreprise s’agit-il ? »

• Issue : comme le découpage est trop fin, la relation de référence est perdue. Ce fragment devient inutilisable.

2. Densité sémantique trop faible (Low Semantic Density)

• La recherche vectorielle a besoin qu’un passage contienne suffisamment d’« information » pour être localisé avec précision.

• Si le texte est découpé en phrases courtes comme « Oui, je suis d’accord. » ou « Conformément aux dispositions, comme suit : »

• les vecteurs produits par ces phrases sont extrêmement génériques et ne possèdent aucune caractéristique distinctive. Lors d’une recherche, ces phrases courtes apparaissent massivement comme du bruit et occupent les premières positions à la place des informations réellement utiles.

3. Les fragments ne permettent pas de reconstituer l’ensemble

• Supposons que la fenêtre de l’LLM puisse contenir 5 blocs.

• Découpage en gros blocs : vous pouvez voir 5 paragraphes complets et comprendre globalement le déroulement de l’affaire.

• Découpage extrêmement fin : vous ne voyez que 5 phrases isolées. C’est comme vous donner 5 pièces de puzzle et vous demander de deviner l’image entière : la difficulté est très élevée.

---

III. La solution avancée actuelle : Parent-Child Indexing (indexation parent-enfant)

Pour résoudre les deux problèmes que vous soulevez, la solution la plus mature s’appelle « Small-to-Big » (recherche de petits blocs, fourniture de gros blocs à l’LLM).

Il s’agit d’un compromis qui combine les avantages du « découpage fin » et de la « préservation de l’intégrité » :

1. Phase de découpage :

• Child Chunk (petit bloc) : on découpe le document en phrases ou petits paragraphes très fins (par exemple 100 caractères). Ils servent à la vectorisation et à la recherche. Comme le petit bloc est sémantiquement pur, la précision de la recherche est élevée.

• Parent Chunk (grand bloc) : on enregistre à quel paragraphe parent plus large appartient ce petit bloc (par exemple 1 000 caractères), voire s’il appartient au document entier.

2. Phase de recherche :

• Le système trouve le « petit bloc » grâce au vecteur (par exemple la phrase « Cette entreprise a réduit les coûts »).

3. Phase de génération (étape essentielle) :

• Le système ne fournit pas ce petit bloc à l’LLM.

• Grâce à l’ID, le système retrouve son « parent » (Parent Chunk) et fournit à l’LLM le paragraphe complet de 1 000 caractères qui contient le contexte.

Résumé :

• On n’utilise pas le découpage sémantique -> parce qu’il est trop lent ; il vaut mieux utiliser un découpage avec chevauchement (Sliding Window) pour compenser les problèmes de frontières.

• On n’utilise pas une granularité fine pour la génération -> parce que, sans contexte, on ne comprend pas.

La tendance actuelle est donc la suivante : utiliser une granularité extrêmement fine pour « viser » (indexer), et une granularité extrêmement large pour « lire » (générer). PageIndex est en réalité la forme ultime de cette logique : viser avec des mots-clés et lire le document entier.

C’est une excellente question de suivi. La réponse simple est : il résout presque parfaitement les problèmes de « découpage » et de « contexte », mais introduit aussi un nouveau défaut critique.

Le RAG sans vecteurs (PageIndex) n’est pas une solution universelle ; il ressemble davantage à une forme d’esthétique brutale qui consiste à « prendre le contre-pied ».

On peut le considérer comme un échange consistant à « remplacer la complexité par de la puissance de calcul ».

---

I. Quels problèmes résout-il complètement ? (Gains)

Le RAG sans vecteurs abandonne le « découpage préalable » et exploite directement la capacité des LLM à gérer de très longs contextes, ce qui permet d’éradiquer les problèmes évoqués précédemment :

1. Il élimine complètement la « fragmentation des morceaux » (Solved: Fragmentation)

• Problème du Vector RAG : le découpage s’interrompt au milieu et la logique entre les paragraphes est perdue.
• Solution du RAG sans vecteurs : puisque l’on ne sait pas où découper, autant ne pas découper du tout.
  • Il fournit directement à l’LLM la page entière, voire le chapitre entier, qui contient les mots-clés.
  • Résultat : les problèmes de « référence pronominale ambiguë » et de « définitions entre paragraphes » disparaissent instantanément. Comme l’LLM voit le texte original de manière cohérente, il peut comprendre lui-même à qui « cette entreprise » fait référence et quel est l’accord mentionné « plus haut ».

2. Il résout le problème de « précision » (Solved: Precision)

• Problème du Vector RAG : rechercher « 1024 » peut renvoyer « 1025 », et une recherche portant sur un nom rare peut ne rien trouver.
• Solution du RAG sans vecteurs : retour à l’index inversé (logique de Ctrl+F).
  • Résultat : seules les pages contenant obligatoirement le terme « 1024 » sont retrouvées. Pour les numéros de contrat, les SKU, les codes d’erreur, les noms et autres indicateurs stricts, la précision passe de 70 % à 100 %.

3. Il résout les problèmes de « boîte noire et de maintenance » (Solved: Black Box)

• Problème du Vector RAG : la base vectorielle est une boîte noire ; il est difficile de comprendre pourquoi un fragment inutile a été retrouvé.
• Solution du RAG sans vecteurs : la logique est transparente.
  • Résultat : pourquoi cette page a-t-elle été récupérée ? Parce qu’elle contient ces trois mots-clés. Si la récupération est incorrecte, le problème vient de la stratégie d’extraction des mots-clés, ce qui est très facile à modifier.

---

II. Quels nouveaux problèmes introduit-il ? (Pertes)

Toute chose a un coût. Le RAG sans vecteurs sacrifie en réalité la « compréhension sémantique » au profit du « contexte précis ». Cela entraîne deux nouveaux problèmes :

1. Il perd le « sens implicite » (Lost: Semantic Fuzziness)

C’est le principal défaut rédhibitoire du RAG sans vecteurs.

• Situation : l’utilisateur recherche « Comment économiser de l’argent ? », tandis que le document parle de « réduire les coûts en optimisant les processus ».
• Vector RAG : il peut retrouver le passage, car il sait que « économiser de l’argent » ≈ « réduire les coûts ».
• RAG sans vecteurs : il ne le trouve pas. Le document ne contient pas les mots « économiser de l’argent ».
  • Mesure corrective : avant la recherche, il faut utiliser un LLM pour effectuer une « Query Expansion (expansion de requête) » et reformuler la question de l’utilisateur en plusieurs mots-clés (« économiser de l’argent » -> réduire les coûts, diminuer les dépenses, faire des économies), ce qui accroît toutefois la complexité et la latence.

2. Le coût en calcul et en argent de la « recherche d’une aiguille dans une botte de foin » (Cost & Latency)

• Vector RAG : il ne fournit à l’LLM que 5 fragments (environ 1 000 tokens). C’est peu coûteux et rapide.
• RAG sans vecteurs : il peut fournir à l’LLM 10 pages complètes (environ 10 000 à 20 000 tokens).
  • Argent : votre facture API peut être multipliée par 10 ou 20.
  • Lenteur : faire lire 20 000 caractères à un LLM et lui en faire lire 1 000 entraîne une latence de génération du premier token (TTFT) totalement différente.
  • Risque de se perdre (Lost in the Middle) : même si l’LLM affirme prendre en charge 200k de contexte, les expériences montrent que lorsque le contexte est trop long, l’LLM a tendance à négliger les informations du milieu et à ne retenir que le début et la fin.

---

III. Le verdict final : où est son véritable avantage ?

Pour vous faire comprendre l’essentiel, prenons l’analogie d’un « examen à livre ouvert » :

IV. Quelle est la meilleure pratique actuelle ?

Personne ne « remplace » l’autre ; l’architecture la plus performante aujourd’hui est le Hybrid RAG (RAG hybride), qui combine leurs points forts :

1. Récupération à deux voies :
   • Une voie utilise Vector pour trouver le contenu « sémantiquement pertinent » (résolvant le problème « économiser de l’argent » contre « coûts »).
   • L’autre utilise Keyword pour trouver le contenu en « correspondance exacte » (résolvant le problème des « numéros de contrat »).
2. Réordonnancement (Rerank) :
   • On mélange les contenus retrouvés par ces deux voies, puis on les évalue avec un modèle précis afin de sélectionner les N meilleurs.
3. Génération avec une grande fenêtre :
   • Quelle que soit la méthode de récupération, il faut autant que possible élargir la « fenêtre de contexte » (par exemple, lorsqu’un passage est retrouvé, fournir également à l’LLM les 2 000 caractères qui le précèdent et le suivent), en utilisant les modèles actuels de texte long et peu coûteux (comme Gemini 1.5 Flash ou Claude Haiku) pour la lecture.

Conclusion :
Le RAG sans vecteurs résout les deux problèmes techniques les plus douloureux — la « fragmentation du contexte » et la « précision » — mais il dépend énormément de la capacité des LLM à traiter de longs textes et de l’épaisseur de votre portefeuille.

Souhaitez-vous maintenant découvrir comment construire concrètement l’architecture du « Hybrid RAG (RAG hybride) » ? Ou voir comment optimiser le coût du RAG sur de longs textes ?