Fine-tuning vs RAG (et le prompting)

Trois leviers, du moins cher au plus cher

1. Le prompt engineering : commencer TOUJOURS ici

Instructions claires, exemples dans le prompt (few-shot), format de sortie imposé, rôle système. Gratuit, itérable en minutes, versionnable en git. Le function calling / tool use en fait partie : tu déclares des fonctions (schéma JSON), le modèle décide de les appeler, ton code exécute — le pont LLM ↔ ton backend.

2. Le RAG : brancher tes données

Retrieval-Augmented Generation : à chaque question, retrouver les passages pertinents de TES documents (recherche vectorielle, leçon 7.1) et les injecter dans le prompt.

question → embedding → top-k passages (pgvector/Qdrant) → prompt enrichi → LLM → réponse sourcée

Le RAG règle les deux plaies du LLM brut : la connaissance figée (tes docs changent tous les jours) et les hallucinations (le modèle cite ses sources). Les vrais chantiers sont l'ingénierie de la recherche : découpage des documents (chunking), qualité de l'index, re-ranking, évaluation du retrieval.

3. Le fine-tuning : modifier les poids

Ré-entraîner (partiellement) le modèle sur tes exemples. Grâce à LoRA (on n'entraîne que de petites matrices adaptatrices, ~1 % des poids), c'est devenu abordable. Mais retiens la règle : le fine-tuning apprend un comportement, pas des connaissances. Pour un ton, un format, un domaine de sortie stricte → oui. Pour « connaître nos produits » → non, c'est le job du RAG (et les connaissances fine-tunées deviennent obsolètes à la première mise à jour).

L'arbre de décision honnête

1. Le prompt (+ few-shot + tools) suffit-il ? → 80 % des cas s'arrêtent ici ;
2. Le modèle doit connaître tes données à jour ? → RAG ;
3. Le modèle doit adopter un comportement/format que le prompt n'obtient pas de façon fiable, à grand volume ? → fine-tuning (LoRA) ;
4. Les trois se combinent : un modèle fine-tuné sur le ton, alimenté par RAG, piloté par un bon prompt.