Qu'est-ce que le RAG (Retrieval-Augmented Generation) ?

Le RAG est une technique qui récupère des documents au moment de la requête et les ajoute au prompt, pour qu’un LLM réponde à partir de données, pas de mémoire. Introduit par Lewis et al. en 2020, c’est l’examen à livre ouvert face à l’examen à livre fermé d’un modèle nu : au lieu de s’appuyer sur ce qu’il a mémorisé pendant l’entraînement, le modèle consulte la matière que vous lui fournissez et répond à partir d’elle — ancré, actuel, capable d’exploiter vos données privées et, parce que les sources sont connues, citable. Pour un développeur backend, la vérité rassurante sous le hype est que le RAG n’est pas un framework qu’il faut adopter : c’est une boucle for que vous savez déjà écrire.

Points clés

Les deux phases

INGESTION (offline, une fois par document)
  charger → découper en chunks (~quelques centaines de tokens, avec chevauchement)
       → encoder chaque chunk en un vecteur
       → stocker vecteur + texte + métadonnées d'ACL dans un index

REQUÊTE (online, à chaque question)
  encoder la question → recherche par similarité des top-k chunks (souvent 5–10)
       → filtrer selon ce que CET utilisateur a le droit de lire
       → augmenter le prompt avec les chunks
       → le LLM génère une réponse ancrée dans ces chunks (+ citations)

Toute la phase online, côté serveur, dans une seule fonction :

// JavaScript — Cloud Code (cloud/main.js): RAG is a for-loop, not a framework
Parse.Cloud.define('askDocs', async (req) => {
  // 1 · embed the question (LLM API key stays server-side)
  const qVec = await embed(req.params.question);

  // 2 · retrieve — similarity search, ACL-FILTERED to this user's docs
  const chunks = await vectorSearch('DocChunk', qVec, {
    limit: 6,
    aclUser: req.user, // never retrieve what the asker can't read
  });

  // 3 · augment + generate
  const context = chunks.map((c) => c.get('text')).join('\n---\n');
  return await complete(`Answer using ONLY this context:\n${context}\n\nQ: ${req.params.question}`);
  // Answer cites the retrieved chunks — grounded, and permission-safe.
});

// Flutter / Dart — Back4app Flutter SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
final answer = await ParseCloudFunction('askDocs')
    .execute(parameters: {'question': 'What is our refund window?'});
print(answer.result); // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// iOS / Swift — Back4app Swift SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
let answer: String = try await Cloud.run(
    name: "askDocs",
    parameters: ["question": "What is our refund window?"])
print(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

// Android / Kotlin — Back4app Android SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
val params = mapOf("question" to "What is our refund window?")
val answer = ParseCloud.callFunction<String>("askDocs", params)
println(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.

Pourquoi le RAG : les trois manques

Un LLM nu a trois faiblesses structurelles, et le RAG les traite toutes sans réentraînement. L’hallucination — les modèles répondent avec assurance qu’ils sachent ou non ; ancrer chaque affirmation dans du texte récupéré donne au modèle quelque chose de vrai à dire. La date de coupure de l’entraînement — la connaissance d’un modèle se fige au moment de l’entraînement ; la récupération va chercher les données du jour. Les données privées — le modèle n’a jamais vu vos documents ; la récupération est la façon dont il les lit au moment de la requête. Le bonus que les modèles à livre fermé ne peuvent pas offrir : parce que les chunks récupérés sont connus, la réponse peut citer ses sources comme des notes de bas de page — le plus gros avantage de confiance du RAG.

Le RAG vs. le fine-tuning

Ce ne sont pas des rivaux : le fine-tuning apprend au modèle comment répondre, le RAG fournit sur quoi répondre, et un assistant métier spécialisé utilise fréquemment les deux — une voix affinée par fine-tuning qui répond depuis une base de connaissances récupérée.

Le RAG est-il mort ? La question du contexte long, tranchée

Le traitement honnête que les pages génériques évitent. Les fenêtres de contexte atteignent désormais plusieurs millions de tokens, ce qui alimente l’argument récurrent du « mettez tout dans le prompt ». Trois faits maintiennent la récupération en vie. Coût et latence : payer le traitement d’un contexte géant à chaque requête est radicalement plus cher et plus lent que d’aller chercher la tranche pertinente — des ordres de grandeur, à l’échelle. Context rot : les études menées jusqu’en 2025 ont constaté une précision des modèles qui se dégrade bien avant que la fenêtre soit pleine — les faits pertinents enfouis dans un contexte énorme passent à la trappe, donc une fenêtre plus grande n’est pas une meilleure réponse de façon fiable. Fraîcheur et contrôle d’accès : un méga-prompt statique est périmé à l’instant où les données changent, et aveugle à qui a le droit de lire quoi. Le consensus de 2026 n’est pas « RAG ou contexte long » mais les deux — récupérer un sous-ensemble généreux, pertinent et filtré par permissions, puis raisonner dessus avec un modèle à contexte long. Le contexte long pur ne convient qu’aux corpus petits, stables et non sensibles.

C’est dans la récupération que le RAG échoue

Le cadrage qui réorganise votre façon de déboguer un système RAG : du déchet récupéré, c’est du déchet généré avec assurance. La plupart des échecs imputés au modèle sont des échecs de récupération déguisés en génération — les mauvais chunks ont été ramenés, donc une réponse parfaitement fidèle s’ancre dans la mauvaise matière. Deux variables font donc réellement bouger la qualité. Le chunking : des morceaux trop gros diluent la pertinence et brûlent le budget de prompt ; trop petits, ils perdent le contexte qui leur donnait du sens — un découpage sensible à la structure (par titre, paragraphe, bloc de code) bat généralement les tailles fixes (les stratégies comptent). La récupération hybride : combinez la recherche par mots-clés (termes exacts, noms, identifiants) et la recherche vectorielle (le sens), puis re-classez les candidats fusionnés avec un modèle de pertinence plus fort avant de construire le prompt — le rappel des deux côtés, la précision du re-ranker. Et mesurez les deux moitiés séparément, dans le vocabulaire de RAGAS : les métriques de récupération (a-t-on ramené les bons chunks ?) face à la fidélité (chaque affirmation est-elle étayée par ce qu’on a ramené ?) — parce qu’elles échouent indépendamment et se corrigent différemment.

La faille de sécurité que personne ne mentionne

La similarité vectorielle classe par sens et ne sait rien des permissions — ce qui fait d’un RAG naïf une machine à fuites de données. Encodez les documents d’une entreprise dans un index unique sans métadonnées d’accès, et la question de n’importe quel utilisateur peut récupérer n’importe quel document, parce que le rapport financier et la question du stagiaire ne sont que des points voisins dans l’espace vectoriel. Filtrer après la récupération n’est pas non plus la solution : écarter les chunks interdits après la sélection top-k divulgue leur existence et casse le contrat du top-k (vous en avez demandé six et vous en recevez deux). Le bon schéma : stocker les métadonnées d’ACL avec chaque chunk et restreindre la récupération à l’ensemble autorisé de l’utilisateur qui pose la question avant le classement par similarité — une récupération filtrée par permissions, pas un affichage filtré par permissions. Le paramètre aclUser des onglets de code est exactement cela, et c’est la différence entre une démo et un système que vous pouvez mettre en production.

Cas d’usage courants

• Chat de support et de connaissance — répondre depuis la documentation réelle de l’entreprise, avec citations, à jour à la dernière ingestion.
• Recherche sur des corpus privés — juridique, médical, wikis internes : la récupération par le sens que le champ de recherche par mots-clés ne vous a jamais donnée.
• Assistants cadrés par client — les données propres à chaque utilisateur, filtrées par ACL pour que la récupération ne franchisse jamais une frontière de tenant.
• Analytique ancrée — des réponses tirées d’enregistrements vivants plutôt que de la supposition périmée d’un modèle.
• Documentation et onboarding — un modèle qui cite le manuel au lieu de l’improviser.

Avez-vous vraiment besoin du RAG ? Matrice de décision

Limites et trade-offs

• Le RAG réduit l’hallucination ; il ne la supprime pas. La fidélité doit se mesurer, pas se présumer — le modèle peut encore mal lire un bon contexte.
• La qualité vit dans la récupération. L’essentiel de l’effort d’ingénierie — chunking, recherche hybride, re-ranking — se situe en amont du modèle, là où sont les gains.
• Les embeddings ont une version. Changez de modèle d’embedding et chaque vecteur stocké doit être régénéré ; ré-encoder un grand corpus est une vraie migration.
• Cela ajoute des pièces mobiles. Pipelines d’ingestion, un index à maintenir, des tokens et une latence supplémentaires par requête — un coût réel qu’un corpus petit et stable peut ne pas justifier.
• Les permissions ne sont pas gratuites. La récupération filtrée par ACL est le travail de sécurité porteur, et c’est la partie que les démos sautent et que les incidents redécouvrent.

Le RAG sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. L’affirmation « le RAG est une boucle for » est ici littérale : les documents sont des objets ordinaires, avec le stockage de fichiers pour les originaux ; les vecteurs des chunks vivent à côté d’eux dans des champs de type tableau, indexés pour la recherche par similarité ; les ACL qui gouvernent déjà chaque requête deviennent gratuitement le filtre de permissions de la récupération — la même règle qui empêche un utilisateur de lire les enregistrements d’un autre empêche le retriever de les ramener ; et l’orchestration — encoder, récupérer, augmenter, générer — est une fonction Cloud Code qui appelle l’API du modèle avec la clé gardée côté serveur, exactement comme le montrent les onglets de code. Pas de framework, pas de service vectoriel séparé à sécuriser, pas de clé de LLM sur l’appareil — le RAG cesse d’être un projet d’IA pour devenir de l’ingénierie backend que vous savez déjà faire.