Article
Mettre en place un RAG : le POC n'est pas le produit
· Maxence Foulon, Ingénieur produit expert
Vous avez un notebook qui répond bien sur dix PDF. Un client va poser une question hors corpus la semaine prochaine. Voici ce qui casse — et dans quel ordre le réparer.
Votre POC RAG répond. Ce n'est pas une mise en production.
Un POC prouve qu'un modèle, avec vos fichiers du jour, peut formuler une réponse plausible. Une production prouve autre chose : que la même question, demain, avec un corpus qui a bougé, sous une identité réelle, produit une réponse que vous assumez — ou un refus que vous assumez aussi.
Ce qui manque presque toujours : un déploiement que quelqu'un d'autre que vous peut relancer, des logs de retrieval, une politique de mise à jour des documents, et un propriétaire du repo. Sans ça, vous n'avez pas un assistant. Vous avez une séance de prompt qui a bien tourné.
Si votre critère de succès est encore « ça a l'air juste », vous n'êtes pas prêt à l'ouvrir. Le critère devient : « on peut expliquer pourquoi cette réponse est sortie, et on sait quoi faire quand elle est fausse. »
Un corpus, ce n'est pas « tous vos documents »
Ingérer le drive entier est la façon la plus rapide de fabriquer un menteur confiant. Chaque fichier doit avoir une licence, une date, un propriétaire, et une raison d'être interrogé. Un PDF obsolète, un contrat d'un autre client, une FAQ marketing qui contredit le support : le retriever les trouvera, et le modèle les dira avec le même aplomb que le reste.
Tranchez avant d'indexer. Qu'est-ce qui a le droit d'être cité ? Qui republie quand le tarif change ? Que se passe-t-il si un document est retiré — la réponse d'hier doit disparaître, ou elle reste dans un cache ? Un corpus versionné coûte plus cher qu'un zip. Il coûte moins cher qu'une hallucination servie à un client.
La découpe n'est pas un détail d'ingénierie à déléguer « plus tard ». Un chunk trop large mélange deux règles. Un chunk trop étroit perd la condition. Vous le voyez le jour où le système recommande un produit incompatible parce que la contrainte était deux paragraphes plus bas.
Une réponse sans source n'est pas une fonctionnalité
Si l'utilisateur ne peut pas ouvrir le passage dont la réponse s'autorise, vous vendez une hallucination habillée. La citation doit résoudre : un identifiant de document, une ancre, un extrait que vous avez réellement indexé. « D'après vos documents » n'est pas une source.
Le corollaire est le droit de se taire. Hors périmètre, conflit entre deux sources, donnée manquante : le système s'abstient et passe la main. Un assistant qui invente pour rester utile détruit la confiance plus vite qu'un assistant qui dit « je ne sais pas ». Ce n'est pas une phrase dans le system prompt. C'est une règle de produit, testée, avec un chemin d'escalade vers un humain.
Les équipes qui sautent cette étape retouchent le prompt pendant des semaines. Les équipes qui l'écrivent découvrent que la moitié des mauvaises réponses étaient des mauvaises récupérations, pas un modèle « pas assez intelligent ».
Mesurez avant de retoucher le prompt
Un jeu de questions d'or — vingt à cinquante, écrites avec quelqu'un du métier, avec la réponse attendue ou le refus attendu — vous dit si un changement améliore ou casse. Sans ça, chaque « petite » modification du prompt est un déploiement aveugle.
Séparez les échecs. Le retriever a-t-il ramené le bon passage ? Le générateur a-t-il trahi un passage correct ? A-t-il répondu alors qu'il aurait dû s'abstenir ? Ces trois erreurs se corrigeant autrement, les mélanger produit des semaines de prompt-engineering pour un problème d'index.
Relancez le jeu à chaque changement de corpus, de découpe, ou de modèle. Si vous ne pouvez pas le relancer, vous n'avez pas d'évaluation. Vous avez une impression.
Ce qu'il faut trancher avant d'écrire une ligne
La surface : chat interne, widget public, WhatsApp, e-mail. Elle impose l'auth, le ton, et ce qu'une mauvaise réponse coûte. Un assistant derrière login n'est pas le même produit qu'un widget sur une boutique.
L'isolation : un client ne voit jamais le corpus d'un autre. Évident à dire, facile à rater dès qu'on « mutualise l'index pour aller plus vite ».
La propriété du code : qui a le dépôt le jour 1, qui paie l'inférence, qui peut couper le service, qui republie un document. Si la réponse est « l'agence, on verra », vous achetez une dépendance, pas un produit.
Quand ces quatre points sont écrits — corpus, sources et refus, évaluation, surface et propriété du code — le travail tient en semaines. Tant qu'ils restent dans le flou, aucun modèle plus grand ne vous sauvera.