Arbre de décision pratique

Se poser les bonnes questions dans l'ordre

Face à un besoin d'adaptation d'un modèle, un arbre de décision simple évite de se précipiter vers la solution la plus complexe et coûteuse sans avoir testé les alternatives plus simples.

flowchart TD
    A[Le modele repond mal] --> B{Le probleme est-il\nla formulation/ton ?}
    B -- Oui --> C[Ajuster le prompt\nsysteme et les exemples]
    B -- Non --> D{Le modele manque-t-il\nd'une information precise ?}
    D -- Oui --> E[Mettre en place\nun systeme RAG]
    D -- Non --> F{Le comportement souhaite\nest-il tres specifique et\nrecurrent sur des milliers\nde cas ?}
    F -- Oui --> G[Envisager un\nfine-tuning]
    F -- Non --> H[Retester le prompt\navec plus de precision]

Le fine-tuning : quand il devient réellement pertinent

Le fine-tuning devient pertinent quand : le comportement souhaité est très spécifique et difficile à décrire entièrement dans un prompt, le volume d'usage est suffisamment important pour justifier l'investissement, et le prompt engineering combiné au RAG a déjà été testé sans succès suffisant.

Le coût caché du fine-tuning : la maintenance

Un modèle fine-tuné doit être réentraîné à chaque évolution significative des besoins ou des données, contrairement à un système RAG dont la base de connaissances se met à jour indépendamment du modèle. Cette maintenance récurrente est souvent sous-estimée au moment de la décision initiale.

Cas concret

Une entreprise de service client envisage un fine-tuning pour que son agent réponde toujours dans un format très structuré et spécifique à son métier. Avant de se lancer, l'équipe teste d'abord un prompt système détaillé avec plusieurs exemples (few-shot prompting) du format exact attendu. Cette approche, bien moins coûteuse, produit des résultats suffisamment fiables pour l'usage prévu, évitant un investissement en fine-tuning qui aurait nécessité un jeu de données d'entraînement et une maintenance continue.

Erreurs fréquentes

• Envisager un fine-tuning avant d'avoir sérieusement testé un prompt engineering poussé avec des exemples (few-shot), qui résout souvent des besoins de formatage ou de ton spécifique sans investissement lourd.
• Sous-estimer le coût de maintenance récurrent d'un modèle fine-tuné, qui doit être réentraîné à chaque évolution significative des besoins.
• Ne jamais reconsidérer une décision architecturale prise tôt (fine-tuning décidé initialement) même quand le besoin réel aurait pu évoluer vers une solution RAG plus simple et flexible entre-temps.

À retenir

• Un arbre de décision simple oriente vers l'approche la moins coûteuse et complexe qui résout réellement le problème identifié.
• Le fine-tuning devient pertinent seulement quand le prompt engineering et le RAG ont été sérieusement testés sans succès suffisant.
• Le coût de maintenance récurrent d'un modèle fine-tuné (réentraînement à chaque évolution) est souvent sous-estimé au moment de la décision initiale.

Mini-exercice

Une équipe envisage directement un fine-tuning pour un chatbot qui doit adopter un ton spécifique et citer des données produit à jour. Quelles deux étapes tester avant d'investir dans un fine-tuning ?

Réponse : d'abord ajuster le prompt système avec des exemples précis du ton attendu (prompt engineering), puis connecter le modèle à un système RAG pour les données produit à jour, avant d'envisager un fine-tuning si ces deux approches combinées ne suffisent réellement pas.