Diagnostic des problèmes de sortie des LLM : quand utiliser des prompts, la récupération ou le fine-tuning
Une approche axée sur les symptômes pour déterminer si une fonctionnalité d’IA faible a besoin d’un meilleur prompt, d’une couche de récupération ou d’un affinage, et pourquoi entraîner un modèle sur des faits a des effets contraires.
La première version de toute fonctionnalité d’IA produit des résultats qui ne sont pas tout à fait corrects. Vous disposez de trois solutions pour y remédier : modifier les instructions, fournir au modèle les documents qui lui manquent, ou le réentraîner avec vos propres exemples. Leur coût varie énormément, allant de quelques minutes de travail à des semaines de collecte de données, et chacune résout un type différent d’échec. Ce guide vous propose une approche basée sur les symptômes pour choisir la bonne solution, afin d’éviter de passer des semaines à corriger un problème qui n’en avait jamais besoin.
Traitez le modèle comme un nouvel employé compétent
Un modèle mental utile consiste à considérer le modèle comme un employé très compétent mais en première journée. Il connaît une quantité remarquable de choses sur le monde en général, mais rien du tout sur votre entreprise : ni vos produits, ni vos politiques, ni la manière dont votre équipe préfère que soient rédigées les réponses. Il fera des erreurs, tout comme n’importe quel nouvel arrivé talentueux.
Vous pouvez aider ce nouvel employé de trois manières précises. Vous pouvez lui fournir des informations plus détaillées, lui remettre les documents de référence ou l’envoyer suivre une formation. Ces méthodes correspondent respectivement à l’encadrement des demandes, au récupération d’informations et au ajustement fin, et elles sont classées du moins coûteux au plus coûteux. L’art réside dans le fait de choisir l’intervention adaptée au problème, c’est pourquoi il est logique de les examiner dans cet ordre.
Encadrement des demandes : réécrivez d’abord les instructions
Commencez toujours par là. Un encadrement des demandes n’est rien d’autre que les instructions que vous envoyez avec la requête : la tâche elle-même, un ou deux exemples de bonnes réponses, le destinataire de ces réponses et le format attendu. Le modifier ne coûte rien et ne prend que quelques minutes. Une grande partie des plaintes selon lesquelles « l’IA est mauvaise » proviennent en réalité du fait que les instructions données étaient vagues.
Supposons que les réponses générées par votre fonctionnalité soient longues et rigides. Aucun reconditionnement n’est nécessaire. Vous ajoutez une instruction telle que « répondez en trois phrases, sur un ton chaleureux et simple », vous collez un bon exemple de réponse, et le problème est généralement résolu en une seule itération. Les instructions permanentes que vous définissez pour chaque demande sont appelées le prompt système ; les exemples de réponses que vous incluez pour illustrer un schéma sont appelés exemples few-shot.
Cependant, le promptage a une limite : les instructions ne peuvent pas fournir des connaissances que le modèle n’a jamais vues. Si le nouvel employé n’a jamais été présenté aux chiffres de ce trimestre, lui demander d’« être plus précis » ne produira pas ces chiffres. Lorsque le véritable manque est informationnel, vous avez besoin du deuxième levier.
Vérification rapide avant de passer à autre chose
Récupération : transmettez les fichiers
La génération augmentée par récupération de données, souvent abrégée en RAG, permet au modèle d’accéder à vos documents au moment où il répond : la liste des prix en vigueur, la politique de retour, l’historique des commandes d’un client donné. Elle permet de combler tout manque de connaissances, de gérer celles qui changent fréquemment ou qui sont réservées à votre organisation. Lorsqu’un document est mis à jour, les réponses s’adaptent automatiquement sans nécessiter de reformation du modèle. C’est le choix idéal lorsque les connaissances vous appartiennent, évoluent souvent ou doivent être citées. La distinction entre ce que le modèle a mémorisé dans ses poids et ce qu’il consulte au moment de répondre est abordée plus en détail dans la manière dont la mémoire, le contexte, les embeddings et les poids du modèle en IA diffèrent.
Dans le cas des nouveaux employés, vous ne leur donnez plus de cours ; vous leur remettez plutôt le manuel et ils peuvent le consulter avant de répondre. Ils peuvent désormais répondre à des questions concernant des changements survenus longtemps après l’entraînement du modèle, et ils peuvent indiquer précisément d’où provient chaque réponse.
Le coût est plus élevé qu’un simple ajustement de prompt. Vous créez en effet un petit pipeline qui stocke des documents et les recherche par sens, ce qui nécessite généralement plusieurs jours de travail plutôt que quelques minutes. Cela reste tout de même bien moins cher qu’un affinage du modèle, et le système reste à jour au fur et à mesure que vos documents évoluent. De plus, cela ajoute des éléments dynamiques que vous devez maintenant entretenir : la manière dont les documents sont divisés, la façon de mesurer la qualité des recherches et ce qui se passe lorsqu’aucun résultat pertinent n’est trouvé.
La récupération d’informations possède ses propres limites claires. Un document comble les lacunes dans les connaissances du modèle, mais il ne modifie pas son comportement. Fournir un manuel à quelqu’un n’altère ni son style d’écriture ni son jugement ; pour cela, on le forme.
Ajustement fin : l’envoyer en formation
L’ajustement fin réentraîne le modèle à l’aide de nombreux exemples jusqu’à ce qu’un style ou une compétence devienne automatique. C’est le moyen d’obtenir un comportement cohérent lorsque les instructions données échouent à produire le résultat souhaité, ou lorsqu’une série d’instructions s’est transformée en une page de règles tout en restant peu fiable. Imaginez devoir que chaque réponse suive une voix de marque très spécifique au cours d’un million de conversations, sans qu’aucune ne s’écarte. Un entraînement sur des milliers d’exemples peut rendre ce comportement la norme, sans nécessiter de directives supplémentaires.
Le point que les gens comprennent le plus souvent à tort est le suivant : l’ajustement fin modifie le comportement du modèle, pas ce qu’il sait. Ce processus est lent et coûteux, il nécessite une grande quantité de données d’exemple, et tout fait concret que l’on y intégre devient obsolète dès que ces faits changent. Par conséquent, on ne doit pas l’utiliser pour stocker des faits ; c’est là que le système de récupération entre en jeu. C’est l’option d’entraînement parmi les trois : puissante lorsque le problème est réellement lié au comportement, mais inutile pour tout ce qui aurait pu être résolu par des informations plus claires. Pour une analyse détaillée des aspects économiques de cette décision, consultez le coût d’un modèle ajusté fin contre une appel API.
Choix en fonction des symptômes
Commencez par une seule question : qu’y a-t-il exactement de mal dans le résultat ?
Les symptômes guident le choix de la solution. Deux autres points sont facilement négligés.
Les leviers s’additionnent plutôt qu’ils ne se concurrencent
Presque chaque fonctionnalité commence par une instruction. Beaucoup y ajoutent ensuite la récupération de données lorsque des informations en temps réel ou privées sont nécessaires, et un nombre plus restreint intègre un affinage pour obtenir un comportement que l’instruction seule ne peut pas garantir. Vous décidez généralement quel niveau ajouter ensuite, et non de choisir une méthode définitive. Un modèle affiné reçoit toujours une instruction, et un système RAG dépend toujours d’instructions indiquant au modèle comment utiliser les données qu’il a récupérées.
Aller seulement aussi loin que le symptôme l’exige
Puisque les options vont du moins cher au plus coûteux dans cet ordre, arrêtez-vous à la première qui résout le problème. Le même raisonnement s’applique avant même de construire quoi que ce soit : si la tâche dépend de faits qui changent, prévoyez la récupération de données ; si elle nécessite un comportement précis à très grande échelle, l’affinage peut finalement se justifier ; pour tout le reste, on part d’une instruction.
L’erreur coûteuse : l’affinage pour enseigner des faits
L’erreur qui mérite d’être soulignée explicitement est le recours au réglage fin pour faire en sorte que le modèle sache quelque chose. Cela semble être un choix sérieux, nécessitant beaucoup de travail d’ingénierie, et c’est précisément pour cette raison que les équipes l’adoptent en premier. Mais un fait qui change constamment ne doit pas faire partie des habitudes du modèle ; il doit figurer dans un document que le modèle peut consulter. Si l’on inverse cette logique, on risque de passer des semaines à enseigner au modèle un fait qui est déjà faux au moment du lancement, sans moyen simple de montrer d’où provient une réponse.
Un piège similaire concerne le réglage fin utilisé pour corriger ce qui n’est en réalité qu’une instruction vague. Si vous n’avez pas encore essayé des instructions de formatage explicites ainsi que quelques bons exemples sur un ensemble de test fixe, vous ne savez pas encore si vous avez réellement un problème de comportement.
Points clés
- Diagnostiquez avant d’investir : déterminez si l’échec est dû aux instructions, aux connaissances ou au comportement.