Pipeline de Retrieval : Optimiser l'Architecture RAG

Un pipeline de retrieval transforme une question en langage naturel en une recherche documentaire ciblée : le système découpe un corpus de documents en passages, les indexe, puis extrait les plus pertinents pour alimenter un modèle de langage. C’est ce mécanisme qui distingue un système RAG (génération augmentée par retrieval, c’est-à-dire un modèle qui consulte des sources externes avant de répondre) d’un modèle qui se contente de ses connaissances internes figées. Chaque maillon de la chaîne, du découpage initial jusqu’à l’évaluation finale, influence directement la qualité des réponses produites.

1. Découper et enrichir vos documents avant toute recherche

Les documents d’un corpus varient considérablement en longueur, certains dépassant les 100 pages ^[1]. Les indexer tels quels est impraticable : les modèles d’embedding (les algorithmes qui convertissent du texte en vecteurs numériques pour en calculer la similarité) ont une limite de contexte, et un texte trop long noie l’information pertinente dans du bruit. Il faut découper le corpus en unités exploitables, puis enrichir chaque unité avec des métadonnées qui permettront de la retrouver et de la filtrer plus tard.

Les stratégies de découpage

Il n’existe pas de taille universelle. Le découpage doit s’adapter au format du document et à l’usage visé :

Par phrase : idéal pour des requêtes de type FAQ, où chaque réponse tient dans quelques phrases. Le framework Docling expose les phrases, paragraphes, en-têtes de section, tableaux et légendes comme des éléments de premier niveau, et permet de configurer le chevauchement et la taille maximale de chaque chunk ^[2].
Par paragraphe ou par section (aligné sur les titres) : mieux adapté aux manuels de procédures ou aux politiques d’entreprise, où le contexte plus large est nécessaire ^[2].
Sémantique : regroupe les phrases par cohérence thématique plutôt que par position dans le document. Ce préservatif de l’intégrité contextuelle améliore la fidélité des réponses générées ^[3].
Syntaxique (AST) : pour les fichiers source, un découpage basé sur l’arbre syntaxique abstrait (la structure grammaticale du code) surpasse nettement le découpage textique brut, avec des gains allant jusqu’à 20,4 % sur le rappel du retrieval lorsque le chemin relatif du fichier est ajouté au chunk ^[4].

L’écueil principal est le même partout : des chunks trop grands dépassent les limites de l’embedding model, des chunks trop petits fragmentent le contexte et rendent la recherche plus difficile. Il faut aussi préserver les références anaphoriques (les « il », « ils » qui renvoient à un sujet mentionné plus haut), sous peine de produire des chunks grammaticalement corrects mais sémantiquement aveugles ^[5]. Le benchmark HiCBench a été conçu précisément pour évaluer l’impact des différentes méthodes de chunking sur les composants d’un système RAG, du découpeur au retrieveur au modèle de réponse ^[6].

Points de départ concrets

Les configurations testées dans la littérature donnent des repères utiles :

Paramètre	Valeurs testées	Contexte
Taille de chunk	256 et 512 tokens	Tournoi d’évaluation avec RAGAS ^[7]
Taille de chunk	300 tokens, chevauchement 0,2	Configuration par défaut avec OpenSearch ^[8]

Ce ne sont que des points de départ. Le découpage adaptatif, qui ajuste la taille et le chevauchement selon le type de document, est un axe d’amélioration important : des chunks de 256 tokens conviennent à des FAQ, tandis que des segments alignés sur les titres de section, plus larges, conviennent mieux aux politiques ou aux manuels ^[2]^[9].

L’enrichissement par les métadonnées

Chaque chunk doit porter un jeu de métadonnées : sa source, sa date, sa version, sa section d’origine, sa page ^[2]. Ces métadonnées ne servent pas uniquement à la traçabilité : elles alimentent le pré-filtrage lors de la recherche (voir section 3). Sans elles, le retrieveur ne distingue pas un extrait d’un rapport annuel 2023 d’un extrait d’un rapport 2024, même s’ils portent sur le même sujet.

Dans la tâche partagée décrite dans ^[1], le pipeline de traitement analyse chaque page pour déterminer si elle contient du contenu factuel exploisable avant de la découper en segments destinés à la génération de questions. L’étape d’évaluation précède le découpage.

Ce que vous devez décider

Quel format ? Texte continu, code source, documents structurés (tableaux, formulaires). Chaque format appelle une stratégie différente.
Quelle granularité ? Testez 256 et 512 tokens en premier ^[7], mesurez l’impact avec HiCBench ^[6].
Quelles métadonnées ? Source, date, section, type de document. Les enrichir en amont coûte peu ; leur valeur est considérable au moment de la recherche.

Préparer sa donnée pour un RAG

2. Construire un index hybride qui ne repose pas sur les vecteurs seuls

La recherche purement sémantique (comparer des vecteurs d’embedding par similarité cosinus, c’est-à-dire mesurer l’alignement entre deux représentations numériques de texte) ignore les correspondances lexicales exactes. Un terme technique précis, un nom propre, un acronyme : tout cela peut être raté si l’embedding ne capture pas la similarité lexicale. Inversement, la recherche par mots-clés, comme celle que propose BM25 (un algorithme classique qui évalue la pertinence d’un document en comptant les occurrences des termes de la requête, pondérées par leur rareté), ignore le sens : elle ne comprend pas que « rémunération » et « salaire » désignent la même chose.

La solution est de combiner les deux signaux. Un modèle intégrant la structuration de requête par LLM, la recherche par mots-clés et la recherche vectorielle sémantique surpasse chaque approche prise isolément ^[10].

Architecture de l’index hybride

Concrètement, deux structures de données fonctionnent en parallèle :

Un index inversé BM25 : chaque mot du corpus pointe vers les chunks qui le contiennent, avec un score de pertinence.
Une base vectorielle : les embeddings de chaque chunk y sont stockés et indexés pour permettre une recherche par similarité approchée. Des méthodes comme HNSW (un graphe de navigation qui accélère la recherche des voisins les plus proches dans un espace à haute dimension) ou le partitionnement adaptatif permettent de monter à des millions de vecteurs ^[11].

L’outil OpenSearch combine nativement un index inversé pour BM25 et une recherche KNN (K plus proches voisins) approchée pour le retrieval dense ^[8].

Fusionner les deux signaux

La méthode la plus courante est le score hybride : un score final qui pondère le score BM25 et le score de similarité vectorielle avec un coefficient α à régler. Mais il existe aussi des approches plus fines : la structuration de la requête par un LLM, qui décompose la question de l’utilisateur en composantes lexicales et sémantiques avant de les diriger respectivement vers BM25 et l’index vectoriel ^[10].

Quand les filtres s’ajoutent à la recherche

Dans certains scénarios, la recherche vectorielle doit coexister avec des prédicats de filtrage (des conditions booléennes sur les métadonnées, comme « date > 2023 » ou « domaine = finance »). C’est le problème de la recherche hybride avec prédicats : on cherche les K plus proches voisins d’un vecteur de requête parmi les seuls documents qui satisfont une condition donnée. La sélectivité du prédicat (la fraction de documents qui passent le filtre) influence directement la difficulté du problème ^[12].

Optimisation par apprentissage par renforcement

Les paramètres de l’index vectoriel, notamment les seuils de similarité et le choix du modèle d’embedding, peuvent être optimisés dynamiquement par apprentissage par renforcement (RL, une méthode où un agent apprend à prendre des décisions en recevant des récompenses). L’objectif est d’identifier quels documents historiques ont produit les meilleures réponses, puis d’ajuster les stratégies de retrieval en conséquence. Les actions incluent le réglage des seuils de similarité pour s’aligner sur les préférences observées et la modification des stratégies de retrieval pour s’adapter aux contextes spécifiques de chaque flux de travail ^[13].

3. Réécrire la requête et filtrer le corpus avant même de chercher

Le retrieval ne commence pas à la recherche : il commence à la requête. Une question mal formulée, ambiguë ou trop vague produira des résultats médiocres, quel que soit la qualité de l’index. Les stratégies de pré-retrieval agissent en amont pour maximiser les chances de succès.

Pré-filtrage et réécriture

Dans le système Metadata-Driven RAG pour la recherche documentaire financière, l’architecture 4 introduit une intelligence de pré-retrieval en deux étapes ^[14] :

Pré-filtrage par métadonnées : avant même de calculer une similarité vectorielle, le système utilise les métadonnées documentaires (domaine, type, date) pour réduire l’espace de recherche. Si la question porte sur un rapport trimestriel de 2024, seuls les documents correspondants sont considérés.
Réécriture de la requête : un LLM reformule la question de l’utilisateur pour lever les ambiguïtés et la structurer en composantes exploitables par le retrieveur.

La réécriture se fait via un prompt explicite : « Écrivez un passage pour répondre à la question. Question : {requête_utilisateur}. Passage : » ^[15]. Ce passage réécrit sert ensuite de requête de recherche.

L’approche multi-requêtes

Plutôt que de réécrire la requête une seule fois, certaines méthodes génèrent plusieurs reformulations en parallèle. La méthode de multi-récriture par beam search (une technique de décodage qui explore plusieurs chemins simultanément) produit plusieurs variantes à coût marginal nul supplémentaire, puis les résultats sont fusionnés. C’est particulièrement utile pour la recherche conversationnelle, où la requête actuelle dépend du contexte des échanges précédents ^[16].

La réécriture comme vérification

La réécriture ne sert pas uniquement à reformuler : elle peut déclencher une étape de vérification. Lorsque le système détecte que les preuves récupérées sont insuffisantes, il reformule la requête pour cibler spécifiquement l’information manquante. Dans une expérience sur la récupération de métadonnées de films, un système concurrent (Search-R1) commettait une erreur en inférant le nombre de scénaristes d’un film à partir d’informations sur les compositeurs et musiciens. La méthode avec réécriture de vérification a corrigé le tir en reformulant la requête pour cibler spécifiquement les crédits d’écriture, récupérant l’information manquante et produisant la bonne réponse ^[17].

Impact mesurable

L’ablation de la réécriture de requête (c’est-à-dire mesurer ce qui se passe quand on la retire) montre une dégradation significative des performances. Sur le benchmark PopQA, l’évaluateur de retrieval basé sur T5 (un modèle de langage entraîné à évaluer la pertinence) atteint 84,3 % de précision, contre 58 % pour ChatGPT et 62,4 % pour ChatGPT avec chaîne de pensée ^[18]. Le gain vient précisément de la réécriture et de la sélection de connaissances externes.

Le routage : filtrer avant de chercher

Le routage est une troisième composante du pré-retrieval. Avant de chercher, le système classifie la requête par similarité avec des exemples de référence valides et invalides. Si la requête ne correspond à aucun cas pertinent, elle est rejetée plutôt que de produire une réponse hors sujet ^[15].

4. Rechercher, puis reranker : le duo qui fait la différence

Le premier passage de retrieval, qu’il soit par mots-clés, sémantique ou hybride, est un filet large. Il vise le rappel (ne rien manquer de pertinent) plutôt que la précision (ne rien ramasser d’irrelevant). Le reranking est le crible fin qui réordonne les candidats pour ne garder que les plus pertinents en tête de liste.

La séquence retrieval puis reranking

Dans l’architecture 3 du système Metadata-Driven RAG pour la recherche documentaire financière, la recherche hybride récupère d’abord un ensemble élargi de 25 chunks candidats, puis un cross-encoder (un modèle qui évalue la pertinence d’un chunk en le lisant conjointement avec la requête, plutôt que de les encoder séparément) réordonne ces candidats pour ne conserver que les 7 plus pertinents dans le contexte final ^[14].

Un cross-encoder fonctionne différemment d’un modèle bi-encodeur classique. Là où un bi-encodeur calcule indépendamment un vecteur pour la requête et un vecteur pour chaque document puis mesure leur similarité, le cross-encoder prend en entrée la paire (requête, document) et produit directement un score de pertinence. Plus lent, mais beaucoup plus précis.

Approches en une ou deux étapes

Pour les tâches de compréhension de lecture (où le système doit répondre à une question à partir d’un passage donné), les méthodes de retrieval se distinguent ^[19] :

Approche	Fonctionnement	Exemples cités dans ^[19]
Une étape	Concaténer la requête à chaque passage candidat et scorer directement	SAE
Deux étapes	Sélectionner d’abord un passage de départ, puis affiner en le combinant avec d’autres candidats	S2G, FE2H
Deux étapes, multi-passages	Sélectionner plusieurs passages initiaux, les combiner pour trouver la bonne réponse	R3

Reranking dans les graphes de connaissances

Pour les systèmes qui récupèrent des triplets (entité-relation-entité) depuis un graphe de connaissances plutôt que des passages textuels, un reranker de graphe sélectionne les triplets les plus pertinents dans un rayon de L sauts (niveaux de connexion) autour des entités liées à la requête. Dans le framework BYOKG-RAG, ce reranker est utilisé en complément d’une traversée agentic du graphe, avec des valeurs de k allant de 10 à 50 selon la base de connaissances ^[20].

Reranking sur les benchmarks de référence

Les méthodes de reranking sont évaluées sur des benchmarks standardisés comme TREC DL19 et l’ensemble des jeux de données BEIR (un benchmark couvrant divers domaines et types de requêtes), ainsi que sur FutureQueryEval ^[21]. Ces évaluations permettent de comparer objectivement les différentes stratégies de réordonnancement.

Ce que le reranking coûte et ce qu’il apporte

Le reranking ajoute une étape de calcul. Mais les bénéfices en précision l’emportent sur ce coût : l’architecture hybride avec reranking améliore significativement la précision des résultats par rapport à la recherche seule ^[10]. L’essentiel est de dimensionner le nombre de candidats intermédiaires : trop peu, et le reranker n’a pas de quoi travailler ; trop, et le coût explose sans gain proportionnel.

Attention toutefois au contexte : pour de grands k (par exemple top-10), le retrieval dense direct avec un chunking adapté au code et l’ajout du chemin de fichier peut surpasser le reranking par LLM, ce qui souligne l’importance de calibrer le pipeline selon le cas d’usage ^[4].

5. Évaluer chaque maillon, pas seulement la réponse finale

Un pipeline RAG ne s’améliore que si on sait où il casse. Une réponse incorrecte peut provenir d’un mauvais découpage, d’un index inadapté, d’un reranking insuffisant ou d’un prompt de génération défaillant. Chaque maillon a ses propres indicateurs.

Métriques de retrieval

Pour la qualité des résultats trouvés :

Précision@k : parmi les k premiers résultats renvoyés, combien sont réellement pertinents ? Elle mesure la qualité de ce qui a été trouvé ^[22].
Rappel@k : parmi tous les passages pertinents du corpus, combien le retrieveur en a-t-il trouvé dans ses k premiers résultats ? Elle mesure la complétude, c’est-à-dire ce qui aurait dû être trouvé ^[22]^[23].
F1-score : la moyenne harmonique entre précision et rappel, utile comme indicateur unique ^[22].

Pour la qualité du classement :

MRR (Mean Reciprocal Rank) : l’inverse du rang du premier résultat pertinent. Un MRR de 1 signifie que le premier résultat est toujours correct ; un MRR de 0,5 signifie qu’il faut regarder en moyenne au 2e rang ^[22].
MAP (Mean Average Precision) : moyenne de la précision calculée à chaque rang où un document pertinent apparaît ^[22].
nDCG@k : mesure qui pénalise les résultats pertinents classés trop bas, en tenant compte de leur position. C’est la métrique principale utilisée dans les benchmarks comme BEIR ^[24].
Hit@k : indique si au moins un document pertinent apparaît dans les k premiers résultats. Hit@1 équivaut à la précision du premier résultat ^[23].

La tension entre précision et rappel dépend de votre usage : pour un système juridique qui ne doit rien mancher, privilégiez le rappel ; pour un assistant qui doit donner une réponse directe, privilégiez la précision ^[22]. L’évaluation du retrieval se fait en pratique par rapport à un jeu de données de référence (golden dataset) où les passages pertinents sont annotés pour chaque requête ^[25].

Métriques de génération

Une fois les passages récupérés, le LLM générateur doit produire une réponse fidèle au contexte :

Fidélité (Faithfulness) : la réponse est-elle ancrée dans les passages récupérés, sans hallucination ? Le framework RAGAS évalue cette dimension en décomposant la réponse en affirmations individuelles puis en vérifiant chacune contre le contexte ^[7]^[22].
Pertinence de la réponse : la réponse traite-t-elle directement la question posée ? RAGAS l’évalue comme une dimension distincte de la fidélité ^[7].
ROUGE : mesure le chevauchement de n-grams entre la réponse générée et une réponse de référence. Utile mais limité, car elle ne capture pas la similarité sémantique. Pour le retrieval multimodal, des métriques comme ROUGE ou BLEU sont inadaptées, tout comme les métriques sans référence comme UMBRELA ou AutoNuggetizer ^[25].

Frameworks d’évaluation intégrés

Plutôt que de construire vos métriques à la main, plusieurs frameworks automatisent l’évaluation complète :

Framework	Ce qu’il évalue	Principe
RAGAS ^[7]	Fidélité, pertinence de la réponse, précision du contexte	LLM-as-a-judge
RAGCHECKER ^[8]	Corrélation entre score de prédiction et qualité réelle	Score de prédiction
RAGGED ^[26]	Conception informée de systèmes RAG, évaluation de la qualité du contexte récupéré	Analyse expérimentale

Le framework RAGAS a été utilisé dans une évaluation de type tournoi suisse (Swiss-system tournament) pour comparer 8 configurations de systèmes RAG combinant différents modèles d’embedding (bge-small, bge-large), tailles de chunks (256, 512 tokens) et modèles de génération (Qwen2.5-7B, Qwen2.5-0.5B), évalués sur trois dimensions : fidélité, pertinence de la réponse et précision du contexte ^[7].

Diagnostic par ablation

La méthode la plus efficace pour identifier le maillon faible est l’ablation systématique : retirer un composant à la fois et mesurer l’impact. Sur le benchmark PopQA, retirer la réécriture de requête, la sélection de connaissances externes ou le raffinement des documents produit chacun une dégradation mesurable des performances ^[18]. Chaque ablation pointe vers un composant spécifique à améliorer.

En recherche d’information, le rappel prime souvent sur la précision lorsqu’on évalue l’expansion de requête : il est généralement plus important de ne pas manquer de documents pertinents que de garantir que tous les documents récupérés soient pertinents ^[23]. Mais dans un pipeline complet, les deux comptent, car le reranker en aval peut rattraper un rappel imparfait, mais pas un rappel nul.

6. Aller plus loin : quand le pipeline linéaire ne suffit plus

Un pipeline retrieval-then-rerank séquentiel atteint ses limites face à des corpus complexes, des requêtes multi-facettes ou des documents multimodaux. Trois axes d’amélioration éprouvés permettent de franchir ce cap.

GraphRAG : capturer les relations entre entités

Plutôt que de chercher des passages isolés, GraphRAG construit un graphe de connaissances à partir du corpus et effectue le retrieval sur ce graphe. Un modèle GraphRAG efficace doit évaluer avec précision la difficulté d’une requête, décomposer intelligemment les questions complexes, et optimiser dynamiquement ses stratégies de recherche. Pour y parvenir, la récompense CAF (Compute-Aware F1) pénalise les opérations de retrieval superflues : elle combine le F1-score de la réponse avec un coefficient de décroissance exponentielle basé sur le nombre total d’opérations de retrieval, ce qui incite le modèle à utiliser le minimum de récupérations nécessaires ^[27]. Sans ce mécanisme, le LLM adopte des récupérations inutilement nombreuses, le problème du « surpensage » qui gaspille des ressources de calcul considérables.

Stratégies adaptatives selon le contenu

Les paramètres optimaux de retrieval changent selon le type de document et la nature de la requête. Des mécanismes de réglage automatique peuvent ajuster les tailles de chunks, les ratios de chevauchement et les paramètres de retrieval en fonction des caractéristiques du document et des patterns de requêtes ^[9]. En pratique, cela signifie que le même pipeline peut utiliser des chunks de 256 tokens pour des FAQ techniques et des segments plus larges pour des manuels de procédures, en adaptant dynamiquement la stratégie.

L’analyse des patterns de performance inter-modèles permet d’identifier les caractéristiques architecturales bénéfiques aux systèmes RAG, et l’impact de la complexité documentaire sur le choix de la stratégie de retrieval reste un axe de recherche ouvert ^[9].

Approches multimodales

Lorsque le corpus contient des images, des vidéos ou des schémas, le retrieval doit gérer plusieurs modalités. L’évaluation du retrieval multimodal repose sur le rappel@k, mesuré à partir d’un jeu de données de référence de paires image-texte. Dans un contexte d’entreprise, ces paires peuvent être générées synthétiquement en utilisant un modèle de vision de haute qualité pour produire des descriptions (captions) d’un échantillon de la base d’images ^[25].

L’approche MiRAGE combine des descriptions textuelles et des images brutes pour le retrieval multimodal. Cependant, utiliser les images seules (sans descriptions textuelles) augmente le score de fondation visuelle à 0,62 mais réduit la fidélité à 0,71, ce qui suggère que les modèles de vision peinent encore à combler le fossé sémantique entre images et texte ^[3].

La base d’évaluation pour progresser

Le benchmark MTEB (Massive Text Embedding Benchmark) et le cadre BEIR fournissent des évaluations standardisées des modèles d’embedding sur des tâches de retrieval, similarité sémantique et regroupement. Ils constituent la référence pour comparer vos choix de modèle d’embedding avant de les intégrer dans le pipeline ^[24]. Un embedding performant sur MTEB ne garantit pas un pipeline performant, mais un embedding médiocre garantit un pipeline défaillant.

Les pistes ouvertes par la recherche incluent la relation entre la structure des prompts et l’efficacité du retrieval, le développement de stratégies adaptatives qui modifient leur approche selon les caractéristiques de la requête, et la mise au point de mécanismes de réglage automatique des paramètres pour différents types de documents ^[9].

Sources

[1] An End-to-End Ukrainian RAG for Local Deployment. Optimized Hybrid Search and Lightweight Generation · Mykola Trokhymovych et al. · 2026 · preprint · arXiv:2604.22095
[2] Generative AI on Kubernetes Operationalizing Large Language Models · livre · Amazon
[3] MiRAGE: A Multiagent Framework for Generating Multimodal Multihop Question-Answer Dataset for RAG Evaluation · Chandan Kumar Sahu et al. · 2026 · preprint · arXiv:2601.15487
[4] BLAgent: Agentic RAG for File-Level Bug Localization · Md Afif Al Mamun et al. · 2026 · preprint · arXiv:2605.17965
[5] A Comprehensive Survey on Long Context Language Modeling · Jiaheng Liu et al. · 2025 · preprint · arXiv:2503.17407
[6] HiChunk: Evaluating and Enhancing Retrieval-Augmented Generation with Hierarchical Chunking · Wensheng Lu et al. · 2025 · preprint · arXiv:2509.11552
[7] DICE: Discrete Interpretable Comparative Evaluation with Probabilistic Scoring for Retrieval-Augmented Generation · Shiyan Liu et al. · 2025 · preprint · arXiv:2512.22629
[8] RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation · Dongyu Ru et al. · 2024 · preprint · arXiv:2408.08067
[9] RAG Playground: A Framework for Systematic Evaluation of Retrieval Strategies and Prompt Engineering in RAG Systems · Ioannis Papadimitriou et al. · 2024 · preprint · arXiv:2412.12322
[10] Hybrid Semantic Search: Unveiling User Intent Beyond Keywords · Aman Ahluwalia et al. · 2024 · preprint · arXiv:2408.09236
[11] Agentic AI for Engineers · livre · Amazon
[12] ACORN: Performant and Predicate-Agnostic Search Over Vector Embeddings and Structured Data · Liana Patel et al. · 2024 · preprint · arXiv:2403.04871
[13] Reinforcement Learning Integrated Agentic RAG for Software Test Cases Authoring · Mohanakrishnan Hariharan · 2025 · preprint · arXiv:2512.06060
[14] Metadata-Driven Retrieval-Augmented Generation for Financial Question Answering · Michail Dadopoulos et al. · 2025 · preprint · arXiv:2510.24402
[15] Is Agentic RAG worth it? An experimental comparison of RAG approaches · Pietro Ferrazzi et al. · 2026 · preprint · arXiv:2601.07711
[16] A Surprisingly Simple yet Effective Multi-Query Rewriting Method for Conversational Passage Retrieval · Ivica Kostric et al. · 2024 · preprint · arXiv:2406.18960
[17] TreePS-RAG: Tree-based Process Supervision for Reinforcement Learning in Agentic RAG · Tianhua Zhang et al. · 2026 · preprint · arXiv:2601.06922
[18] Corrective Retrieval Augmented Generation · Shi-Qi Yan et al. · 2024 · preprint · arXiv:2401.15884
[19] Gumbel Reranking: Differentiable End-to-End Reranker Optimization · Siyuan Huang et al. · 2025 · preprint · arXiv:2502.11116
[20] BYOKG-RAG: Multi-Strategy Graph Retrieval for Knowledge Graph Question Answering · Costas Mavromatis et al. · 2025 · preprint · arXiv:2507.04127
[21] How Good are LLM-based Rerankers? An Empirical Analysis of State-of-the-Art Reranking Models · Abdelrahman Abdallah et al. · 2025 · preprint · arXiv:2508.16757
[22] RAG with Python Cookbook Practical Recipes from Data Preprocessing to LLM Agents · livre · Amazon
[23] Generative Query Expansion with Multilingual LLMs for Cross-Lingual Information Retrieval · Olivia Macmillan-Scott et al. · 2025 · preprint · arXiv:2511.19325
[24] MTEB: Massive Text Embedding Benchmark · Niklas Muennighoff et al. · 2022 · preprint · arXiv:2210.07316
[25] Hands-On RAG for Production · Ofer Mendelevitch and Forrest Sheng Bao · livre · Amazon
[26] On the Influence of Context Size and Model Choice in Retrieval-Augmented Generation Systems · Juraj Vladika et al. · 2025 · preprint · arXiv:2502.14759
[27] GraphRAG-R1: Graph Retrieval-Augmented Generation with Process-Constrained Reinforcement Learning · Chuanyue Yu et al. · 2025 · preprint · arXiv:2507.23581