Les démos RAG sont faciles. Le RAG en production, c'est surtout de la récupération, un tout petit peu de génération, et beaucoup de plomberie dont personne ne parle. La magie, s'il y en a, vit dans la récupération — pas dans le modèle.
Le chunking est la partie qui détermine si le RAG fonctionne ou pas. Découper les documents par nombre de tokens est un point de départ — et un mauvais. Nous découpons sur des frontières sémantiques : titres de section, sauts de paragraphe, tableaux, blocs de code. Et nous mesurons la qualité de récupération hors ligne avant tout appel LLM. Si le bon chunk n'est pas dans le top-K, aucun modèle ne peut récupérer.
La récupération hybride n'est pas négociable. BM25 attrape les cas de correspondance exacte que la recherche vectorielle rate (références produit, identifiants de code, codes d'erreur). La recherche vectorielle attrape l'intention sémantique. La combinaison — typiquement une reciprocal rank fusion — est ce que nous shippons. La récupération vectorielle pure laisse 20 à 30 % des cas sur la table.
La suite d'évaluation est l'artefact qui compte. Nous commençons chaque projet RAG avec 200 à 500 questions sourcées d'utilisateurs réels (tickets support, appels commerciaux, tout ce qui est généré par un humain). Chaque question a une réponse correcte connue ou une citation correcte connue. Chaque changement de chunking, d'embedding, de récupération ou de prompt est mesuré contre cet ensemble. Pas d'éval = pas de progrès, juste de l'opinion.
Ce que nous ne faisons pas : prétendre que les embeddings se choisissent seuls, shipper des boucles « agentic » sans budget de latence, écrire des plans multi-étapes sans chemin de fallback. Un RAG qui gagne sa place en production est ennuyeux, mesuré, et remplaçable fournisseur par fournisseur.