Quand le prompting suffit

Avant d’avoir recours à l’ajustement fin, considérez la formulation d’instructions comme l’hypothèse nulle. Les modèles modernes de pointe possèdent suffisamment de capacités latentes pour que la plupart des tâches relèvent de la récupération et de l’instruction, et non de la mise à jour des poids.

L’erreur coûteuse que commettent les équipes consiste à lancer un entraînement alors qu’une instruction bien structurée, quelques exemples et un accès aux outils auraient comblé l’écart sans coût marginal d’entraînement. L’ajustement fin n’est justifié que lorsque la formulation d’instructions atteint de manière démontrable un plafond.

• La formulation d’instructions modifie chaque requête ; l’ajustement fin modifie le modèle
• La formulation d’instructions est réversible en quelques secondes ; un point de contrôle ajusté est un artefact définitivement engagé
• Commencez à moindre coût et ne passez à l’étape suivante que sur la base de preuves

Comparez les approches selon trois axes de coût indépendants, et pas seulement selon leur prix :

• Coût d’itération - à quelle vitesse pouvez-vous modifier le comportement ? Formulation d’instructions : minutes. Ajustement fin : de quelques heures à quelques jours par cycle.
• Coût d’inférence - la formulation d’instructions paie au jeton pour les instructions longues et les exemples à chaque appel ; un modèle ajusté peut intégrer ce comportement dans ses poids et raccourcir l’instruction.
• Coût de maintenance - une instruction réside dans la gestion de versions et peut être auditée ; un point de contrôle doit être réajusté chaque fois que le modèle de base devient obsolète.

La formulation d’instructions l’emporte sur l’itération et la maintenance ; l’ajustement fin peut l’emporter sur le coût d’inférence à haut volume.

L’argument du coût d’inférence en faveur du réglage fin ne tient qu’au-delà d’un seuil de volume. Modélisez explicitement le point de bascule : une longue instruction avec quelques exemples qui ajoute 2 000 jetons d’entrée par appel entraîne un coût récurrent ; un modèle réglé finement amortit le coût d’entraînement sur le volume.

Si votre trafic est inférieur au seuil de rentabilité, l’instruction avec quelques exemples est strictement moins chère et plus flexible.

Le principal argument en faveur de la formulation d’instructions est la possibilité de changer de cap en situation d’incertitude. Les exigences évoluent : nouveau cas limite, changement de politique, nouveau champ de sortie. Avec des instructions, vous corrigez le texte ; avec un modèle réglé finement, vous recueillez de nouvelles données et vous réentraînez le modèle.

Lorsque la définition de la tâche évolue encore — produit à ses débuts, spécification ambiguë, changements fréquents des parties prenantes — la formulation d’instructions est presque toujours le bon choix. Ne figez les paramètres qu’une fois la cible stabilisée.

De nombreux problèmes qui donnent l’impression de nécessiter un réglage fin se résolvent grâce à des techniques appliquées aux instructions :

• Respect du format — sortie structurée / contraintes de schéma JSON, pas d’entraînement
• Ton du domaine — bloc d’exemples de style accompagné d’une description explicite de la voix
• Profondeur du raisonnement — décomposition, chaîne de raisonnement ou étape de planification
• Lacunes de connaissances — la récupération (RAG) injecte les faits ; le réglage fin intègre des faits obsolètes

Ne recourez au réglage fin que pour ce que les instructions ne peuvent structurellement pas faire : compression des instructions pour réduire la latence, formats très particuliers ou comportement auquel le modèle résiste même avec des consignes précises.

Une confusion fréquente consiste, pour les équipes, à effectuer un réglage fin afin d’injecter des connaissances alors qu’elles devraient les récupérer. Le réglage fin enseigne mal les faits : il perd des informations, coûte cher à mettre à jour et favorise l’interpolation hallucinée entre les exemples d’entraînement.

Règle pratique : si la lacune concerne ce que le modèle sait, utilisez la récupération. Si elle concerne la manière dont le modèle se comporte, envisagez le réglage fin. Les connaissances changent quotidiennement ; le comportement change rarement.

Avant de conclure que la formulation d’instructions est insuffisante, parcourez toute l’échelle. La plupart des équipes abandonnent au deuxième niveau :

• Niveau 1 : instruction claire + rôle + contrat de sortie explicite
• Niveau 2 : exemples couvrant les cas limites
• Niveau 3 : décomposition en plusieurs appels en chaîne
• Niveau 4 : utilisation d’outils / récupération pour décharger les connaissances et les calculs
• Niveau 5 : étapes d’autocritique ou de vérification

Ce n’est qu’après avoir épuisé les niveaux 1 à 5 avec un ensemble d’évaluation mis de côté que le réglage fin devient défendable.

Les instructions longues coûtent plus que de l’argent — elles coûtent du temps. Les jetons d’entrée dominent souvent le temps avant le premier jeton dans de nombreuses architectures de service. Une instruction de 4 000 jetons comprenant des exemples entraîne un surcoût de latence mesurable à chaque appel.

C’est le seul cas où la formulation d’instructions perd véritablement à grande échelle : lorsque vous avez besoin à la fois du comportement fourni par une longue instruction et de réponses en moins de 100 ms, distiller ce comportement dans un petit modèle réglé finement est la bonne décision. Vérifiez toutefois que le budget de latence est réel et non supposé.

Décidez en fonction du TCO sur toute la durée de vie de l’artefact, et non de la première facture. Un point de contrôle réglé finement entraîne des coûts récurrents cachés :

• Nouveau réglage lorsque le fournisseur retire le modèle de base (souvent tous les 6 à 12 mois)
• Une chaîne de traitement des données et un processus d’annotation que vous devez maintenir
• Une infrastructure d’évaluation pour détecter les régressions après chaque nouveau réglage
• Gestion des versions, retour arrière et complexité du service A/B

Le TCO de la formulation d’instructions se résume principalement à un fichier texte et à un ensemble d’évaluation. Pour les équipes qui ne maîtrisent pas encore les opérations de ML, cette seule asymétrie maintient la formulation d’instructions en tête bien plus longtemps que prévu.

La formulation d’instructions suffit lorsque vous pouvez répondre YES à la plupart de ces questions :

• La spécification de la tâche évolue-t-elle encore de mois en mois ?
• Le volume est-il inférieur à votre seuil de rentabilité calculé ?
• La lacune concerne-t-elle les connaissances (récupérables) plutôt que le comportement ?
• Une évaluation mise de côté montre-t-elle que la formulation d’instructions atteint une qualité acceptable après avoir parcouru l’échelle ?
• Votre budget de latence supporte-t-il la longueur des instructions ?
• Votre équipe ne dispose-t-elle pas d’une chaîne de traitement maintenue pour le réglage et l’évaluation ?

Trois réponses YES ou plus signifient que vous devez rester sur la formulation d’instructions et ne réévaluer la situation que lorsque les réponses changent.

Encodez la décision sous forme de données, et non au gré des impressions. Une petite fonction de score oblige l’équipe à énoncer explicitement ses hypothèses (volume, latence, stabilité de la spécification) et rend la recommandation vérifiable a posteriori.

La formulation d’instructions est le choix par défaut ; le réglage fin est l’étape suivante. Restez sur la formulation d’instructions tant que la spécification évolue, que le volume est inférieur au seuil de rentabilité et que la lacune concerne les connaissances plutôt que le comportement.

• Comparez les coûts d’itération, d’inférence et de maintenance, pas seulement les montants
• Calculez le seuil de rentabilité en volume avant de supposer que le réglage fin permet d’économiser de l’argent
• Parcourez toute l’échelle d’optimisation des instructions avant de conclure qu’elles sont insuffisantes
• Récupérez les connaissances ; réservez le réglage fin aux comportements récalcitrants ou à la compression des instructions dictée par la latence
• Évaluez le TCO sur toute la durée de vie, y compris le retrait du modèle de base