Un pipeline RAG naïf,embedder des chunks de documents, faire une recherche par similarité, injecter les meilleurs résultats dans un prompt,suffit à construire une démo convaincante. Ça ne suffit pas à tenir en production, où le bruit de retrieval, un mauvais chunking et l'absence de boucle de feedback dégradent silencieusement la qualité des réponses. Voici l'architecture qui tient vraiment la route.

Indexation : le chunking est une décision d'architecture, pas un détail

La stratégie de chunking détermine tout ce qui suit. Le chunking à taille fixe est le défaut courant, mais il coupe des phrases et des idées en deux. Le chunking sémantique (découper sur les frontières de sens) et le chunking hiérarchique (petits chunks pour un retrieval précis, liés à un chunk parent plus large pour le contexte) surpassent tous les deux le découpage à taille fixe sur des documents réels.

Retrieval hybride : la recherche vectorielle seule ne suffit pas

La similarité vectorielle pure excelle sur les correspondances conceptuelles et faiblit sur les correspondances exactes,codes produit, codes d'erreur, noms propres. Combiner la recherche vectorielle dense avec une recherche par mots-clés sparse (BM25) et fusionner les deux ensembles de résultats avec du reciprocal rank fusion.

def hybrid_search(query: str, k: int = 10):
    dense_results = vector_store.similarity_search(query, k=20)
    sparse_results = bm25_index.search(query, k=20)

    return reciprocal_rank_fusion([dense_results, sparse_results], k=k)

def reciprocal_rank_fusion(result_lists, k, rrf_k=60):
    scores = {}
    for results in result_lists:
        for rank, doc in enumerate(results):
            scores[doc.id] = scores.get(doc.id, 0) + 1 / (rrf_k + rank + 1)

    return sorted(scores.items(), key=lambda x: x[1], reverse=True)[:k]

Re-ranking : une seconde passe, plus coûteuse

Récupérer largement et à moindre coût d'abord (20 à 50 candidats), puis re-ranker avec un modèle cross-encoder qui score la requête et chaque document ensemble. Les cross-encoders sont bien plus précis que la similarité d'embeddings, mais trop lents pour tourner sur tout le corpus,ils ont donc leur place à l'étape de re-ranking, pas au retrieval initial.

RAG agentique : le retrieval comme outil, pas comme étape fixe

Plutôt que de toujours faire un retrieval avant de générer, laisser le modèle décider si le retrieval est même nécessaire, et autoriser un retrieval en plusieurs étapes pour les questions complexes,chercher, évaluer les résultats, chercher à nouveau avec une requête affinée si la première passe n'était pas satisfaisante.

Évaluation et observabilité : la partie que tout le monde saute

• ✓Mesurer la qualité du retrieval séparément de la qualité de génération,recall@k et précision, pas seulement "est-ce que la réponse sonnait juste".
• ✓Logger les chunks récupérés à côté de chaque réponse générée,impossible de déboguer une mauvaise réponse sans voir ce que le modèle a vraiment vu.
• ✓Utiliser un jeu d'évaluation labellisé ou un LLM-as-judge pour attraper les régressions avant qu'elles n'atteignent la production.
• ✓Monitorer les échecs silencieux de retrieval : ensembles de résultats vides, chunks non pertinents scorés comme pertinents, index obsolètes.

Une architecture RAG de production est un pipeline avec des boucles de feedback, pas une simple fonction embed-search-generate. Traiter la qualité du retrieval comme une métrique de premier ordre, mesurée, et le reste du système devient bien plus facile à raisonner et à améliorer.