Ce que j’avais prévu
Pour l’ancien assistant de mon portfolio, je pensais pouvoir faire tourner un modèle 4B sur mon VPS.
Le RAG devait retrouver des passages dans les documents du site, puis les transmettre au modèle pour produire une réponse.
Les essais tournaient uniquement sur CPU, sans GPU. Je n’avais pas beaucoup de contexte à fournir au modèle et je pensais que cette configuration pourrait suffire.
Les essais ne m’ont pas convaincu
Avec le 4B, les réponses étaient mauvaises pour ce que j’attendais du RAG.
Pour comprendre d’où venait le problème, j’ai séparé les deux étapes : j’ai examiné les passages retrouvés indépendamment de la réponse générée, puis comparé les résultats sur les mêmes questions.
Les essais restaient mauvais. Le passage au modèle 8B ne m’a pas permis d’identifier une amélioration nette, alors que le temps de génération augmentait fortement. Même avec peu de contexte, le gain n’était pas suffisamment visible pour justifier cette attente dans ma configuration CPU only.
Le choix : garder la recherche sur le VPS
J’ai finalement séparé les deux parties. La recherche documentaire est restée sur le VPS, tandis que la génération passait par une API externe, avec une clé d’accès.
Le serveur continuait à retrouver les passages utiles. Il les transmettait au modèle distant au lieu de faire tourner lui-même le modèle de génération.
C’était un changement par rapport à mon idée de départ : je voulais héberger le modèle sur mon serveur, et j’ai fini par déléguer cette partie. La fiche du projet RAG présente le chemin complet d’une requête.
Ce que j’en retiens
Je ne tire pas de ces essais la conclusion qu’un 4B est forcément mauvais pour le RAG, ni qu’un 8B est toujours trop lent. Je sais que les résultats ne me convenaient pas dans ce projet.
Pour ce prototype, le choix concret a été de conserver la recherche sur le VPS et d’utiliser une API pour la génération.