Discuter avec 1000+ fichiers PDF en local : Évolution du RAG au-delà des démos

Pourquoi le RAG standard échoue au-delà de 1.000 documents

• Index-hors-RAM : LanceDB, ChromaDB et FAISS commencent tous en mémoire résidente. Quand l'index dépasse la RAM disponible (typiquement 5-8 GB de vecteurs sur un laptop 16 GB), ils basculent sur lectures par disque et latence query p95 saute de ~300 ms à 1-3 secondes.
• Cosinus-seul échoue sur termes rares : embeddings denses sous-pondèrent noms propres rares, noms de médicaments, numéros de statut et identifiants de code. Une requête pour « Section 230(c)(1) » récupère chunks de « Section 9 » car l'embedding ne distingue pas la spécificité numérique. BM25 le capte ; recherche cosinus seule le manque.
• Top-K de 4 est trop étroit à grande échelle : à 1.000 chunks, top-4 a une précision correcte. À 50.000 chunks, le vraiment meilleur chunk est souvent au rang 12-30 – en dehors de la fenêtre top-4. Récupération semble fonctionner (réponses plausibles) mais est silencieusement ancrée sur mauvais passages.
• Pas de filtrage par métadonnées gaspille l'index : demander « qu'a dit Smith sur X » sur corpus 10.000 documents cherche chaque chunk dans l'index, quand le système devrait d'abord pré-filtrer « documents par Smith ». RAG naïf n'a pas concept de pré-filtrage par métadonnées.
• Taille de chunk par défaut 512/0 fragmente longs contextes : paragraphes PDF et sections juridiques rentrent rarement en 512 tokens. Chevauchement 0 par défaut perd signification aux frontières. Ajustement 1.000/200 corrige pour moyens corpus ; chunking hiérarchique demandé au-delà 5.000 documents.
• Drift d'embedding sur mise à jour : quand vous ajoutez 1.000 nouveaux PDF trois mois après index original, versions de modèles sentence-transformer peuvent avoir changé. Mélanger embeddings de deux versions dans un index dégrade silencieusement – chaque architecture force ré-indexation complète sur changement d'embedder.

Arborescence décisionnelle : Choisissez d'abord par taille du corpus

• Moins de 1.000 documents (moins ~5.000 chunks) : AnythingLLM Desktop avec chunk-size 1.000 / overlap 200 et nomic-embed-text-v1.5 comme embedder. Pas de code personnalisé. Voir guide étape-par-étape 30 minutes pour setup.
• 1.000-5.000 documents (5k-25k chunks) : LlamaIndex mode local avec indices hiérarchiques (DocumentSummaryIndex + VectorStoreIndex), Ollama comme fournisseur LLM, nomic-embed-text-v1.5 comme embedder, LanceDB ou ChromaDB comme vector store. ~150 lignes Python, fonctionne comme processus durable.
• 5.000-10.000 documents (25k-50k chunks) : Stack personnalisé Ollama, ChromaDB, recherche hybride BM25 via Whoosh ou Tantivy, reranker BGE-reranker-v2-m3 sur top-50 candidats. ~300-400 lignes Python. Reranker non-négociable à cette échelle.
• 10.000+ documents (50k+ chunks) : Ollama + Qdrant mode single-node avec filtrage métadonnées par payload, recherche hybride native Qdrant sparse vectors, BGE-reranker-v2-m3 et index résumé hiérarchique par IDs documents. Setup grade production single-user.
• Multi-utilisateur (toute échelle) : Open WebUI face à l'une des architectures ci-dessus, OU petit wrapper FastAPI autour Qdrant+Ollama. Multi-utilisateur change histoire opérationnelle (auth, isolation, rate limiting) mais pas architecture récupération.

Tableau comparatif des architectures

Option 1 : AnythingLLM ajusté (100-1.000 documents)

• LLM : Llama 3.3 8B Q4_K_M via Ollama (5 GB RAM lors inférence). Systèmes 24 GB+, Qwen 2.5 14B Q4 améliore notablement synthèse.
• Embedder : passez défaut AnythingLLM Native à nomic-embed-text-v1.5 via Ollama. Embedder défaut est raison principale pour rapports « AnythingLLM ne scale pas ».
• Chunking : 1.000 tokens avec 200-token overlap, réglez par workspace sous Vector Database settings. Défaut 512/0 faux pour n'importe quel corpus plus gros que quelques douzaines documents.
• Top-K : relevez défaut 4 à 6-8. À 1.000 documents, vraiment meilleur chunk souvent rang 5-7, et LLM ignore mieux chunks faibles que peut inventer manquants.
• Partition workspace : créez un workspace par catégorie document (papiers, contrats, notes). Chaque workspace separate LanceDB indexé ; requêtes cross-workspace non-supportées, mais précision per-workspace bien plus haute qu'unique grand pool.

Option 2 : LlamaIndex local (1.000-5.000 documents)

• Stack : Ollama + LlamaIndex + LanceDB (ou ChromaDB) + nomic-embed-text-v1.5 via adaptateur OllamaEmbedding. Persisté disque ; fonctionne comme processus Python durable interagi via CLI ou petit wrapper FastAPI.
• DocumentSummaryIndex au-dessus VectorStoreIndex : LlamaIndex construit résumé par-document index time, puis récupération d'abord sélectionne documents pertinents (recherche résumé) puis cherche chunks dans ceux-là uniquement. Motif récupération hiérarchique le moins cher.
• Routage requête : RouterQueryEngine envoie requêtes fact-recall à index chunk et requêtes synthèse à index résumé. ~30 lignes code ; double qualité réponse sur corpus long-document.
• Récupération sentence-window : index optionnel second récupérant cible phrase plus N phrases autour. Utile corpus juridique et académique où réponse une phrase mais signification dépend paragraphe.
• Persistance : index.storage_context.persist(persist_dir=...) sauvegarde tout. Temps reload index 5.000-documents 10-30 secondes sur SSD NVMe.

# Minimal LlamaIndex RAG local avec indices hiérarchiques (~30 lignes)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Index résumé pour routage + index chunk pour récupération
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# Temps requête, routez par type question
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "Quelle taille d'échantillon Smith et al. ont-ils utilisée?"
)
print(response)

Option 3 : Ollama + ChromaDB personnalisé (5.000-10.000 documents)

• Stack : Ollama + ChromaDB (mode serveur) + Whoosh ou Tantivy pour BM25 + BGE-reranker-v2-m3 (~570 MB, fonctionne CPU à 50-100 candidats/sec). Hébergé comme processus Python unique ou divisé workers ingest + requête.
• Recherche hybride temps récupération : exécutez BM25 et récupération dense vecteur parallèle, prenez top-25 chacun, dédupliquéz, rerangez merged top-50 avec cross-encoder. Final top-K 6-8 au LLM.
• Champs métadonnées ChromaDB : remplissez source_filename, page_number, document_type, author, year chaque chunk temps index. Filtrage temps requête (where={"document_type": "contract"}) coupe espace recherche 5-10x zéro perte qualité.
• Indexation batch : ChromaDB embed batches 32-128 chunks. Sur RTX 4070, BGE-reranker goulot (50-100 candidats/sec CPU ; 400+/sec GPU).
• Persistance : ChromaDB écrit répertoire SQLite + Parquet. Index 50.000-chunk disque ~3-5 GB. Sauvegarde est copie répertoire.

Option 4 : Ollama + Qdrant (10.000+ documents)

• Stack : Ollama + Qdrant (Docker, single-node) + sparse vectors natifs (équivalent BM25 intégré Qdrant 1.10+) + BGE-reranker-v2-m3 + petite couche orchestration Python.
• Hybrid natif : Qdrant supporte denses + sparse vectors une collection, fusion pondérée temps requête. Pas processus BM25 séparé maintenir.
• Tuning HNSW : 50.000+ vecteurs, relevez ef_construct 200 et m 32 index build, utilisez ef=128 requête time. Défauts fonctionnent mais échangent ~10% précision rapidité build.
• Payload schemas filtrage : Qdrant traite payloads first-class. Indexez author, document_type, year, tags keyword payloads activer pré-filtrage sub-milliseconde.
• Récupération hiérarchique : deux collections – summaries (un vecteur document) et chunks (usuel). Routez requêtes collection résumé d'abord, chunk-cherchez dans matched document IDs.
• Persistance : Qdrant écrit volume monté unique. Collection 100.000-chunk ~6-12 GB disque selon payload size et settings HNSW.

# Collection Qdrant dense + sparse vectors et filtrage métadonnées
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Requête : recherche hybride + filtre payload, pas processus BM25 séparé
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # avant rerank
)

Recherche hybride : BM25 + Vecteur beau l'un seul

• Pourquoi dense seul échoue : embeddings sous-pondèrent tokens rares. Requêtes comme « RFC 9110 section 7.4 » ou « MNDA-2024-0143 » embedded proche chunks IETF / contrat génériques. BM25 capture identifiant exact ; recherche cosinus seule le manque.
• Pourquoi BM25 seul échoue : correspondance lexicale manque paraphrase. Requête « Comment annulons-nous? » contre chunk titre « Procédures résiliation » match espace dense, score 0 BM25.
• Fusion Rang Réciproque (RRF) combiner standard : chaque chunk apparaît l'une ou l'autre liste résultat, score-le comme 1/(60+rank_dense) + 1/(60+rank_bm25). Tri descendant. 60 constante lissage ; valeurs 30-100 fonctionnent pratique.
• Recette pratique : top-25 chaque méthode, combinez via RRF, prenez top-50, envoyez reranker, puis top-6-8 au LLM. C'est pipeline production standard n'importe quelle échelle au-delà 1.000 documents.
• Coût stockage : indices BM25 petits (~50-150 MB par 10.000 documents) comparé indices denses (~500 MB-2 GB même échelle). Ajouter BM25 store dense existant bon marché.

Reranking : Le passage raffinement Top-N

• BGE-reranker-v2-m3 (~570 MB, multilingue, Apache 2.0) choix défaut mai 2026. Fonctionne 50-100 candidats/sec CPU moderne ; 400+ /sec GPU. Coût latence top-50 reranking ~200-500 ms CPU, ~80-150 ms GPU.
• Pourquoi cross-encoders gagnent récupération : embeddings denses encodent requête document indépendant, donc modèle jamais les voit ensemble. Cross-encoder lit `[CLS] requête [SEP] candidat [SEP]` ensemble score pair directement. Recall@5 typiquement saute 15-25 points.
• Où injecter reranker : après recherche hybride, avant LLM. Prenez top-50 hybride, rerangez top-6-8, envoyez ceux-là au LLM comme contexte.
• Alternative – Cohere Rerank API : qualité plus haute, demande appel cloud. Stacks entièrement-locaux, BGE-reranker-v2-m3 défaut pratique. mxbai-rerank-base-v2 runner-up fort.
• Passer reranker fein sous 1.000 documents : gain qualité ne justifie pas coût latence. Au-delà 5.000 documents, le passer laisse ~15-25% réponses ancrées mauvais chunks.

Filtrage métadonnées : Rétrécissez avant espace recherche

• Champs payload universels remplir index-time : source_filename, page_number, document_type (papier / contrat / note / wiki), author, year, language, plus tags domain-spécifiques (p.ex. case_number, project_id, client_id).
• Pré-filtre temps requête : « Qu'a dit Q3 2024 minutes board sur tarifs? » → filtre document_type=board_minutes AND year=2024 AND quarter=3 d'abord, puis vecteur cherche dans ~12 documents au lieu tous 10.000.
• Support vector store : payloads Qdrant, properties Weaviate, métadonnées ChromaDB, colonnes schéma LanceDB supportent tous filtrage. Performance varie – filtrage payload Qdrant champs indexés sub-milliseconde ; filtrage métadonnées ChromaDB >100k chunks peut ajouter 50-150 ms.
• Auto-extraction métadonnées : corpus juridique, petit LLM pass index-time peut extraire numéros cas, dates, noms partis chaque document. Coûts ~30 secondes document sur Llama 3.3 8B ; fonctionne une fois par ingest.
• Combiné recherche hybride : filtre payload rétrécit univers → BM25 + récupération dense ensemble filtré → rerank. Filtre payload speedup 5-10x meilleur marché n'importe quel gros système RAG.

Motifs récupération hiérarchique

• Résumés par-document : index-time, promptez LLM écrire 100-200 token résumé chaque document. Embedez résumés collection summaries séparée. Coût ~30-90 secondes document Llama 3.3 8B.
• Récupération deux-stages : (1) embed requête, cherchez summaries, prenez top-5 documents ; (2) dans ceux 5, récupérez top-8 chunks via recherche hybride ; (3) rerangez si demandé ; (4) envoyez LLM.
• Quand ça aide plus : synthèse et requêtes multi-documents (« comparez comment ces papiers gèrent X »). Fact recall (« quel valeur Smith a rapporté? ») correct chunk index seul – détour résumé ajoute latence gain qualité zéro.
• Tradeoff coût : double stockage index (résumés petits mais index lui-même infrastructure dupliquée). Double latence requêtes non-routées. Gain réduction bruit 10.000+ documents.
• LlamaIndex construit ceci dedans : DocumentSummaryIndex plus RouterQueryEngine implémentation 30-lignes. Python personnalisé ChromaDB ou Qdrant ~80-120 lignes.

Benchmarks mesurés à 100, 1.000 et 10.000 documents

Dimensionnement stockage et configuration matérielle

• Texte brut 1.000 PDF (~12 pages chacun) : ~50-150 MB texte extrait. Hautement variable selon densité.
• Vecteurs 1.000 documents : ~300-400 MB disque incluant overhead index HNSW. ~120-180 MB skip index HNSW utilisez brute-force (acceptable sous 5.000 documents).
• Vecteurs 10.000 documents : ~3-5 GB disque. Build HNSW 10-30 minutes CPU moderne.
• Vecteurs 50.000 documents : ~15-25 GB disque. Build time index goulot – planifiez 2-4 heures CPU travail one-time.
• RAM lors requête : récupération dense demande ~30-50% index mémoire travail bas-latence requêtes. Index 5 GB requête confortable 8-16 GB RAM avec HNSW ; brute-force demande index entier resident.
• RAM lors indexation : spikes 2-3x embedding modèle taille (~600 MB nomic-embed-text) plus per-batch texte. 8 GB libre RAM suffisant pass indexation.
• GPU vs CPU : embedding throughput 4-8x plus rapide GPU discrète ou Apple Silicon. 10.000+ documents one-shot indexation, GPU sauve 1-3 heures. Embedding temps requête (une requête à fois), CPU fien.
• Type disque compte : SSD NVMe plancher pratique 5.000+ documents. SATA SSD ajoute 30-100% latence requête froide ; disque rotatif inu-utilisable au-delà ~2.000 documents.

Indexation incrémentale et déduplication

• Hash-basée dupe exacte ingest : SHA-256 octets fichier brut. Passer fichiers hash déjà index. Bon marché, attrape fichiers identiques, manque quasi-dupes (passes OCR différentes même scan, conversions format).
• Dupe content-hash : SHA-256 texte plain extrait après normalisation whitespace. Attrape même document formats fichier différents. Ajoute ~5 ms fichier ingest.
• MinHash quasi-dupes : corpus juridique académique où versions multiples même document s'accumulent, calculez MinHash signature (~128 bytes document) passez fichiers threshold similarité Jaccard existant entrée.
• IDs document à jamais : jamais ré-utilisez ID document après suppression. Vector stores souvent ré maintiennent briefly ; ré-utilisation IDs causes confusion silencieuse. Utilisez UUIDs ou IDs hash-basés.
• Re-embedding changement embedder : chaque architecture force ré-indexation complète changez embedding modèle. Planifiez choix embedder vos commit avant indexation 10.000 documents.
• Efface : ChromaDB et Qdrant supportent suppression point par ID. LanceDB demande pass compaction reclaim disk space – planifiez hebdomadaire si vous supprimez plus ~5% corpus par mois.

Surveillance qualité RAG grande échelle

• Construisez petit ensemble or : 30-50 requêtes vous connaissez réponse correcte, dessinées usage réel. Incluez fact recall (5-10), synthèse (5-10), cross-document (5-10), cas limites (5-10), requêtes known-miss (5-10) où réponse pas corpus.
• Suivez trois métriques par requête : précision récupération (chunk correct apparaissait top-K?), fidélité génération (réponse match chunk?), taux refus (système dit correctement « pas corpus » requêtes known-miss?).
• Ré-exécutez chaque changement significatif : nouveaux ingest batches, swaps embedder, chunk-size changes, tweaks prompt. Diffez résultats vs. run précédent ; flagez requête dont récupération précision ou réponse changea.
• Trulens ou RAGAS frameworks eval automatisés. Tous deux fonctionne local intègrent LlamaIndex. Scoring manuel 30-50 requêtes aussi fien souvent plus précis.
• Budgets latence : suivez p50 et p95 latence requête temps. Saut 50% p95 typiquement signifie index dépassa RAM – signal précoce upgrade prochain niveau archit.

Questions fréquemment posées

Lectures complémentaires

• AnythingLLM vs PrivateGPT vs Open WebUI : Meilleur RAG local en 2026 – contexte base pour choisir plateforme RAG desktop avant évolution.
• Meilleurs modèles embedding pour RAG local en 2026 – choix embedder décision seule plus importante avant indexation 10.000 documents.
• RAG local pour données business privées – escalade naturelle quand RAG scale-personnel rencontre exigences compliance enterprise.
• Construisez RAG local sur vos PDF en 30 minutes (Ollama + AnythingLLM) – setup level-entrée avant vous hittez falaise évolution.
• RAG Expliqué : Ancrez réponses IA dans données réelles (2026) – autorité concept sur RAG est et pourquoi chaque composant récupération compte.
• Guide matériel LLM local 2026 – référence dimensionnement matériel corpus 10.000+ documents.
• Centre Power Local LLM – bibliothèque guide complète cluster.