RAG Studies

Introduction

RAG (Retrieval-Augmented Generation) systems have become the reference architecture for document AI applications in professional environments. By combining a semantic search engine with a generative language model, RAG enables answering complex questions by drawing on an external knowledge base, without requiring costly fine-tuning and ensuring that answers are grounded in verifiable documentary sources. This approach solves two fundamental problems of LLMs: hallucinations and the lack of domain-specific business knowledge. RAG anchors generation in facts — those contained in the organization's documents — and keeps knowledge up to date without retraining the model, simply by updating the document base.

Technical Challenges

The quality of a RAG system depends on a chain of interconnected architectural decisions. Each link in the pipeline — from document chunking to final response generation — directly influences the relevance and reliability of results. Overly coarse chunking drowns relevant information in a sea of context, diluting the LLM's ability to extract the exact answer. Overly fine chunking fragments reasoning and deprives the model of the big picture needed for a coherent response. An embedding model ill-suited to the language or domain of the corpus produces vector similarities that do not reflect true semantic proximity. A poorly calibrated retrieval strategy returns off-topic documents or misses essential passages. Generation, finally, depends on the quality of the provided context: a high-performing LLM with poor context produces mediocre answers, while a modest LLM with excellent context can deliver remarkable responses.

This research project offers a systematic and methodical exploration of all RAG pipeline parameters, with the aim of producing concrete, quantified, and reproducible recommendations for designing industrial RAG systems. We do not merely compile theoretical knowledge: each configuration is tested, measured, and compared on real business corpora, with objective metrics. Experiments cover varied corpora — technical documents, legal texts, product manuals, business correspondence, activity reports — to ensure generalizability of results. Project deliverables include an architectural guide, performance matrices per configuration, and a reusable test bench for evaluating any new component.

Chunking Strategy

Chunking strategy — the segmentation of documents into exploitable segments — is the first and perhaps most decisive parameter of a RAG pipeline. Poor chunking irremediably compromises retrieval quality, regardless of embedding model quality or LLM power. We study three major strategy families. Fixed chunking is the simplest method: documents are split at regular intervals, typically between 256 and 1024 tokens, with or without overlap between adjacent chunks to avoid cutting information in half. Its simplicity is its main advantage: it is fast, deterministic, and easy to implement. Its limitations appear on strongly structured documents: a misplaced cut can separate a title from its content, a table from its caption, or a question from its answer. Overlap partially mitigates this problem but increases vector database size and may introduce redundancy.

Semantic chunking improves upon fixed chunking by using the document's natural segmentation. Instead of cutting at an arbitrary size, it detects semantic boundaries: paragraph ends, section changes, thematic transitions. Boundary detection can rely on several approaches: analysis of similarity between consecutive sentences (a sharp drop in similarity indicates a topic change), document structure (headings, subheadings, numbering, lists), or a specifically trained segmentation model. The result is a set of chunks that respect the thematic unity of documents, significantly improving retrieval relevance: each chunk contains a coherent topic, facilitating matching with the query and understanding by the LLM.

Hierarchical chunking is the most sophisticated approach. It builds a multi-level representation of documents: a table of contents at the highest level, sections and subsections at the intermediate level, and detailed content at the finest level. Retrieval first occurs at the coarse level to identify relevant sections, then at the fine level to extract precise passages. This strategy is particularly suited to long, structured documents: technical manuals, research reports, legal documents. The hierarchy enables answering both general questions (what is the structure of this document?) and precise ones (what is the tolerance threshold mentioned on page 47?). Results from our campaigns show that hierarchical chunking outperforms flat approaches by 15 to 25% on retrieval precision metrics for documents over 50 pages.

Embedding models constitute the heart of semantic search in a RAG system. Their role is to transform text — document chunks and queries — into numerical vectors in a high-dimensional space, where geometric proximity reflects semantic proximity. The choice of embedding model has a direct impact on retrieval quality: a good model produces representations where relevant documents are naturally close to the query, while a poor model mixes concepts and produces off-topic results. We systematically evaluate the most widely used embedding models in the ecosystem: OpenAI's text-embedding (ada-002, text-embedding-3-small, text-embedding-3-large), BGE models (BAAI), E5 (Microsoft), Sentence Transformers (all-MiniLM-L6-v2, multilingual-e5-large), Cohere models, and embedding models from Mistral and Jina AI.

Embedding model evaluation criteria cover several dimensions. Retrieval performance measures the model's ability to rank relevant documents at the top of results: we use standard metrics recall@k, precision@k, and MRR (Mean Reciprocal Rank) on annotated query sets for each business corpus. Multilingual robustness evaluates vector representation quality across different languages: an excellent English model can degrade by 30 to 50% on French legal text or German technical content. Domain resistance measures the model's ability to capture specialized semantics: an engineering document corpus uses vocabulary and concepts that differ significantly from the general language on which models are mostly trained. Vector dimension impacts performance, storage, and search speed: 384-dimensional vectors are faster to search but may be less expressive than 1536 or 3072-dimensional vectors.

Results from our evaluation campaigns reveal significant gaps between models. On French technical corpora, multilingual models (multilingual-e5-large, BGE-m3) achieve recall@5 15 to 25% higher than English monolingual models. OpenAI's text-embedding-3-large dominates on raw quality but its inference cost — proportional to token count — can be prohibitive for databases of millions of documents. Open source models like BGE and E5 offer the best quality-to-cost ratio: free to use, executable locally via Ollama or Sentence Transformers, and with performance close to proprietary models on most corpora. Model choice depends on the trade-off between quality, cost, latency, and data sovereignty: a local model guarantees that no document data leaves the infrastructure, a decisive criterion for sensitive or regulated data.

Retrieval strategy — how to select and rank relevant chunks to answer a query — is the second critical parameter of the RAG pipeline. We explore several combinable approaches. Pure vector search (top-k) is the basic method: the query is vectorized, a cosine similarity or L2 distance search is performed in the vector database, and the k closest chunks are returned. The value of k is a sensitive parameter: too low (1 to 3) may miss essential complementary passages, while too high (20 to 50) drowns the LLM in voluminous context and dilutes relevant information. Our experiments show that k between 5 and 15 offers the best balance for most use cases, with fine optimization based on chunk length and query complexity.

Fusion retrieval combines multiple search strategies to improve coverage and robustness. The principle is to execute several queries in parallel — with different phrasings, different embedding models, or different search modes — then merge the results into a single ranked list. Fusion can be done by weighted score interpolation, by rank (RRF — Reciprocal Rank Fusion) which gives more weight to documents ranked first in each list, or by majority voting. RRF is particularly effective: it is simple, deterministic, and requires no weight calibration. Our tests show that fusing two or three retrieval strategies improves recall by 10 to 20% compared to a single strategy, with a significant reduction in result variance.

Re-ranking is a complementary step to initial retrieval. After retrieving a broad set of candidate chunks (k = 20 to 50), a re-ranking model — more performant but slower than the embedding model — re-evaluates each chunk's relevance to the query. Re-ranking models like Cohere Rerank, BGE-Reranker, or Cross-Encoder are specialized for this task: instead of comparing vectors, they take the (query, chunk) pair as input and produce a more accurate relevance score. This two-step approach combines vector search speed (step 1) with re-ranking precision (step 2). The gain is substantial: recall@5 improved by 15 to 30% depending on the corpus, with acceptable latency overhead (a few hundred milliseconds per query for GPU re-ranking).

Hybrid search — combining vector search and BM25 lexical search — is a powerful technique to overcome the respective limitations of both approaches. Vector search excels at capturing semantic similarity: it finds documents about the same topic even with different words. BM25 search excels at exact lexical matching: it finds documents containing the precise terms of the query, which is essential for identifiers, references, codes, proper names, and rare technical terms. Combining both modes covers the full range of cases: a query about early termination clause 12 will find both documents using other phrasings (early cancellation, termination) via vector search, and documents exactly mentioning clause 12 via BM25.

Hybrid search implementation depends on the vector database used. Qdrant natively supports combining vector search and filters, but BM25 must be implemented via a separate inverted index or a custom scoring function. In our test bench, we use a dual-index architecture: a Qdrant vector index for semantic search, and a BM25 index based on Tantivy or Elasticsearch for lexical search. Results from both indexes are fused via RRF with configurable weights. Calibration of the weight between the two modes is a corpus-dependent parameter: a high vector weight (0.7 to 0.8) is preferable for narrative or descriptive documents, while a higher lexical weight (0.5 to 0.7) is optimal for documents rich in technical terms, codes, and references. Our tests show that hybrid search improves recall@10 by 12 to 18% compared to pure vector search, with particularly marked gains on queries containing specific named entities.

Systematic evaluation of RAG pipeline quality is a challenge in itself, which is the subject of a dedicated sub-project. Unlike a classification task where accuracy is directly measurable, RAG system quality is multidimensional and partially subjective. We have developed a comprehensive evaluation framework covering five axes: fidelity measures whether the LLM's response is faithfully grounded in the retrieved documents — a response can be correct in itself but not based on the provided sources, which is a RAG failure; relevance assesses whether the retrieved chunks are actually relevant to the query; completeness verifies that the response covers all aspects of the question; absence of hallucination guarantees that the response does not introduce information not present in the sources; and writing quality evaluates the clarity, conciseness, and structure of the response.

The framework uses a combination of automatic metrics and LLM-as-a-judge evaluation. Automatic metrics include cosine similarity between the response and sources (for fidelity), named entity recall (for completeness), and correct citation rate (for traceability). LLM-as-a-judge uses a judge model — typically GPT-4o or Claude — that receives the query, retrieved chunks, generated response, and evaluates each axis according to a standardized grid with textual justification. This approach correlates well with human evaluation (Spearman correlation coefficient > 0.85 in our tests) while being automatable and reproducible. Each evaluation campaign produces a detailed report with scores per axis, success and failure examples, and improvement recommendations.

Use Cases

Concrete use cases cover two main domains that will structure our recommendations. Processing technical documents — user manuals, specifications, API documentation, test reports, operating procedures — is a natural application domain for RAG. These documents are generally well structured, with headings, sections, numbering, and indexes, making them particularly suited to hierarchical chunking. Technical queries are often specific and factual: what is the recommended torque for this screw? Which Python version is required for this module? Retrieval precision is critical because erroneous information — an incorrect specification, a misinterpreted parameter — can have material or financial consequences. Our recommendations for this domain favor hierarchical chunking with reduced overlap (50 tokens), a BGE-type multilingual embedding model, a top-k of 8 to 12, and hybrid search with a lexical weight of 0.4 for technical terms.

Processing legal documents — contracts, clauses, terms and conditions, amendments, court decisions — presents specific requirements. Legal vocabulary is precise and standardized: a term has an exact legal meaning that tolerates no semantic approximation. Legal documents are rich in cross-references, definitions, and references to other articles or contracts, requiring navigation capability between chunks — a point where hierarchical chunking with a relationship graph between chunks proves particularly useful. Legal queries are often conditional: what happens if the client terminates before the anniversary date? Analyzing the condition involves finding potentially multiple clauses spread across different contract articles. Retrieval precision is equally critical here, but error tolerance is even lower: misinterpreting a contractual clause can have serious legal and financial consequences. For this domain, we recommend semantic chunking with longer chunks (800 to 1200 tokens) to preserve legal reasoning coherence, a fine-tuned legal embedding model (SaulLM or LegalBERT) if available, a top-k of 10 to 15 to cover related clauses, and mandatory re-ranking with a cross-encoder model.

Project results take the form of an architectural recommendation guide classifying configurations by corpus type, business constraint (precision, latency, cost, sovereignty), and document volume. Each recommendation is supported by quantified results from our test campaigns, with expected performance metrics, hardware prerequisites, and associated trade-offs. The guide is designed to be usable by a technical team without prior RAG expertise: it provides ready-to-use configurations, decision trees for component selection, and test procedures to validate each pipeline step. The test bench itself is delivered as an open source project, enabling any organization to reproduce our evaluations on its own corpora and validate architectural choices before going into production.

Perspectives

Project evolution prospects are numerous. Evaluation of agentic architectures that extend classic RAG with planning and tool-use capabilities is a promising avenue: a RAG agent capable of iteratively deciding which documents to consult, in what order, and how to combine information, can handle complex questions beyond the capabilities of single-pass RAG. Integration of graph-augmented generation (GraphRAG), which uses a knowledge graph alongside the vector database for retrieval, opens perspectives for highly interconnected corpora. Extension to other modalities — RAG on documents containing images, tables, charts — is an active research area. Finally, study of conversational RAG, where the system maintains dialogue history and adapts retrieval based on the accumulated context of exchanges, foreshadows the next generation of document AI systems.

Conclusion

RAG is not a static technology but an active research field whose architectures evolve rapidly. This project helps structure this evolution by rigorously documenting what works, in what context, and at what cost. Architectural decisions of a RAG system — chunking, embedding, retrieval, generation — are interdependent and must be optimized holistically: an improvement in one link can be negated by a regression in another. Our systematic approach, combining rigorous quantitative evaluation with concrete use cases, provides technical teams with the keys to design performant, reliable RAG systems adapted to their business constraints. Mastering these architectures is a decisive competitive advantage for any organization wishing to fully exploit the value of its professional knowledge bases.