PRAGMATICUS
← Knowledge

Le RAG, sans la promesse magique.

Sépare la recherche de la génération.

Objectif

Comprendre où se joue vraiment la qualité.

Un assistant RAG est d'abord un projet de documents et de recherche.

Quand une réponse est mauvaise, le modèle n'est pas toujours le premier suspect. Le bon passage peut être absent, mal découpé, inaccessible ou simplement introuvable.

Avant de changer de modèle, il faut donc suivre le chemin de l'information : identifier la source attendue, vérifier qu'elle est exploitable, puis contrôler qu'elle remonte au moment de la question. Cette fiche sert à diagnostiquer cette chaîne dans le bon ordre.

Principe

Le modèle écrit à partir d’un contexte documentaire retrouvé.

Un raccourci fréquent consiste à dire que l'assistant a été « entraîné sur les documents de l'entreprise ». Dans un système RAG, le mécanisme est différent : au moment de la question, un moteur cherche quelques extraits pertinents et les transmet au modèle comme contexte.

La réponse finale dépend donc de deux opérations distinctes. La recherche doit retrouver le bon passage. Ensuite seulement, le modèle doit l'interpréter sans dépasser ce que la source permet d'affirmer.

Une réponse fluide ne prouve rien si le bon passage n'a jamais été retrouvé.
  1. Documents

    Sources, droits et versions.

  2. Découpage

    Des passages rendus cherchables.

  3. Recherche

    Les extraits les plus pertinents.

  4. Contexte

    La question enrichie avec les sources.

  5. Réponse

    Une génération citée et vérifiable.

Approche

Construire la chaîne, maillon par maillon.

Le piège consiste à commencer par le modèle parce que c'est la partie la plus visible. Une démarche robuste commence par la qualité attendue et remonte progressivement jusqu'à la génération.

  1. Fixe les critères avant la technique.

    Définis ce qu'est une réponse correcte, comment le système se comporte quand il ne sait pas, le délai acceptable et la part des demandes réellement résolues.

  2. Traite les documents comme le vrai chantier.

    Inventorier, nettoyer, découper et maintenir les sources est une fonction produit. Ce n'est pas une tâche préparatoire que l'on termine une fois pour toutes.

  3. Teste la recherche séparément.

    Avant d'évaluer la qualité de la prose, vérifie que le passage attendu est bien remonté. Sinon, le modèle travaille avec un contexte incomplet.

  4. Décide tôt entre managé et maison.

    Compare droits d’accès, qualité de recherche, contraintes de données, coûts d’exploitation, capacité de l’équipe et réversibilité. Teste les options avec les mêmes cas avant de choisir managé, développement propre ou une combinaison.

  5. Branche une boucle de retour.

    Les documents et les questions évoluent. Sans mesure continue, l'assistant peut se dégrader sans que personne ne s'en aperçoive.

Points d’attention

Reconnaître un produit, pas seulement une bonne démonstration.

Les signaux utiles ne sont pas les effets visuels de l'interface. Ils montrent que la fiabilité et la maintenance ont été pensées au-delà du premier test.

Bon signal

  • Chaque réponse importante renvoie vers une source vérifiable.
  • Le système refuse clairement quand aucun passage ne suffit.
  • Un propriétaire suit les erreurs et maintient la base.

À surveiller

  • La fluidité de la réponse remplace toute mesure d'exactitude.
  • Le budget modèle est central, mais les documents sont oubliés.
  • Le lancement clôt le projet et aucun suivi n'est prévu.

À retenir

La qualité se vérifie sur les sources retrouvées et leur utilisation dans la réponse.

La bonne question n'est donc pas seulement « quel modèle ? », mais « quel document, quel passage, quel droit, quelle preuve ? ».

En pratique

Teste une question documentée et une question sans réponse suffisante.

Une question connue aide à suivre la chaîne ; elle ne suffit pas à évaluer le produit ni à tester l’abstention. Ajoute des cas sans réponse suffisante, des sources contradictoires et des droits différents.

Un diagnostic par cas, pas une impression globale.

Pour une question documentée, vérifie le passage et l’appui de chaque affirmation. Pour une question sans réponse suffisante dans les sources accessibles, vérifie que le système reconnaît la limite sans inventer.

Question test

Une vraie question, formulée comme sur le terrain.

Passage attendu

Le document et l'extrait qui doivent remonter.

Réponse vérifiable

Une conclusion reliée explicitement à sa source.

Refus propre

Un cas sans réponse suffisante vérifie la reconnaissance de la limite. L’absence de preuve ne doit pas devenir une réponse inventée.

Fidélité

La présence d’une citation n’est pas suffisante : vérifie que le passage étaye réellement la conclusion et que les conditions ou limites n’ont pas disparu.

Le template à reprendre

CAS : [question / droits / sources accessibles]
ATTENDU : [réponse étayée ou abstention]
RECHERCHE : [passage attendu / passage retrouvé]
GÉNÉRATION : [exactitude / fidélité / citations]
ÉCART : [cause à vérifier / correction / nouveau test]

Sources et méthode