Le RAG n'est pas qu'une recherche vectorielle
Brancher un embedding et une base vectorielle est la partie facile. La question qui détermine si le RAG est utile est différente : qu'est-ce qu'on indexe, et à quel moment ça devient obsolète ? Un RAG alimenté par du contenu qui change (posts approuvés, décisions passées) doit se réindexer en continu, pas une seule fois au démarrage.
Few-shot dynamique plutôt que prompt figé
Sur LuxenCrest, le brief éditorial et le barème de contrôle qualité s'appuient directement sur les posts déjà approuvés — récupérés par similarité au moment de la génération, pas copiés une fois pour toutes dans un prompt statique. Le système s'améliore avec l'historique sans qu'on ait à retoucher le prompt à chaque nouvelle campagne.
La qualité de la récupération compte plus que la taille du modèle
Un modèle plus gros ne compense pas une récupération qui remonte des passages hors sujet. La distance de similarité utilisée pour filtrer, la taille des chunks et le nombre de résultats remontés pèsent davantage sur la qualité finale que le choix du LLM lui-même.
Ce que ça coûte de le maintenir
Un RAG en production, c'est aussi une base vectorielle à faire évoluer, des embeddings à régénérer si le modèle change, et un budget de tokens à surveiller sur chaque appel de récupération — des coûts d'exploitation qu'un prototype n'a jamais à assumer.