Optimiser la précision des LLM

Comment maximiser l’exactitude des résultats et la cohérence du comportement des LLM

Optimiser les LLM est difficile.

Nous avons travaillé avec de nombreux développeurs, dans des start-up comme dans de grandes entreprises. Les difficultés d’optimisation se résument toujours aux mêmes questions :

• Savoir par où commencer pour optimiser la précision
• Quelle méthode utiliser et quand pour optimiser les résultats
• Quel niveau de précision est suffisant pour la production

Cet article propose un cadre de réflexion pour optimiser la précision et le comportement des LLM. Nous explorerons des méthodes comme l’ingénierie de prompts, la génération augmentée par récupération (RAG) et l’affinage. Nous expliquerons également comment et quand utiliser chaque technique, ainsi que quelques pièges à éviter.

Au fil de votre lecture, reliez ces principes à ce que signifie la précision dans votre cas d’utilisation. Cela peut sembler évident, mais produire un texte médiocre qu’une personne doit corriger n’a pas les mêmes conséquences que rembourser 1 000 $ à un client au lieu de 100 $. Avant toute discussion sur la précision des LLM, ayez une idée approximative de ce que vous coûte un échec du LLM et de ce qu’une réussite vous fait économiser ou gagner. Nous y reviendrons à la fin, lorsque nous aborderons le niveau de précision « suffisant » pour la production.

Comprendre l’optimisation des LLM

De nombreux guides pratiques présentent l’optimisation comme un processus linéaire simple : commencer par l’ingénierie de prompts, passer à la génération augmentée par récupération, puis à l’affinage. Pourtant, les choses se passent souvent autrement. Ces leviers répondent à des problèmes différents, et pour optimiser dans la bonne direction, vous devez actionner le bon levier.

Il est plus utile de représenter l’optimisation des LLM sous forme de matrice :

Une tâche typique confiée à un LLM commence dans le coin inférieur gauche, par l’ingénierie de prompts. Nous testons, tirons des enseignements et évaluons les résultats pour établir une référence. Après avoir examiné ces premiers exemples et déterminé pourquoi ils sont incorrects, nous pouvons actionner l’un de nos leviers :

• Optimisation du contexte : Vous devez optimiser le contexte lorsque 1) le modèle manque de connaissances contextuelles parce qu’elles ne figuraient pas dans son jeu d’entraînement, 2) ses connaissances sont obsolètes ou 3) il a besoin d’informations internes à l’entreprise. Cet axe maximise la précision des réponses.
• Optimisation du LLM : Vous devez optimiser le LLM lorsque 1) le modèle produit des résultats irréguliers au format incorrect, 2) le ton ou le style ne convient pas ou 3) le raisonnement n’est pas suivi de manière constante. Cet axe maximise la cohérence du comportement.

En pratique, cela devient une série d’étapes d’optimisation : nous évaluons les résultats, formulons une hypothèse sur la façon de les améliorer, la mettons en œuvre, puis évaluons à nouveau les résultats pour déterminer l’étape suivante. Voici un exemple de processus d’optimisation assez courant :

Dans cet exemple, nous procédons comme suit :

• Commencez par un prompt, puis évaluez ses performances
• Ajoutez des exemples few-shot statiques, ce qui devrait améliorer la cohérence des résultats
• Ajoutez une étape de récupération pour intégrer dynamiquement les exemples few-shot en fonction de la question. Cela améliore les performances en fournissant un contexte pertinent pour chaque entrée
• Préparez un jeu de données d’au moins 50 exemples et affinez un modèle pour améliorer la cohérence
• Ajustez la récupération et ajoutez une étape de vérification des faits pour repérer les hallucinations et améliorer la précision
• Réentraînez le modèle affiné sur les nouveaux exemples d’entraînement, qui incluent nos entrées RAG améliorées

Ce processus d’optimisation est assez typique pour un problème métier difficile. Il nous aide à déterminer si nous avons besoin d’un contexte plus pertinent ou d’un comportement plus cohérent du modèle. Une fois cette décision prise, nous savons quel levier actionner pour commencer l’optimisation.

Maintenant que nous disposons d’un cadre de réflexion, examinons les méthodes permettant d’agir sur chacun de ces aspects. Nous commencerons dans le coin inférieur gauche, par l’ingénierie de prompts.

Ingénierie de prompts

L’ingénierie de prompts est généralement le meilleur point de départ**. C’est souvent la seule méthode nécessaire pour des cas d’utilisation comme le résumé, la traduction et la génération de code, où une approche zero-shot peut atteindre des niveaux de précision et de cohérence suffisants pour la production.

En effet, elle vous oblige à définir ce que signifie la précision pour votre cas d’utilisation. Vous commencez au niveau le plus élémentaire, en fournissant une entrée : vous devez donc pouvoir juger si la sortie correspond à vos attentes. Si ce n’est pas le cas, comprendre pourquoi vous indiquera quels moyens utiliser pour poursuivre l’optimisation.

Pour y parvenir, commencez toujours par un prompt simple en gardant à l’esprit le résultat attendu. Optimisez ensuite le prompt en ajoutant du contexte, des instructions ou des exemples jusqu’à obtenir ce que vous souhaitez.

Optimisation

Pour optimiser vos prompts, je m’appuierai principalement sur les stratégies du guide d’ingénierie de prompts de la documentation de l’API OpenAI. Chaque stratégie vous aide à ajuster le contexte, le LLM ou les deux :

Ces stratégies peuvent être un peu abstraites. Nous allons donc les mettre à l’épreuve avec un exemple concret : utiliser gpt-4-turbo pour corriger des phrases en islandais.

SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.

# Examples
USER: "Stofnendurnir séu margir og eru fulltrúar hennar frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."
ASSISTANT: "Hann segir að stofnendur leynireglunnar séu margir og að fulltrúar hennar séu frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

USER: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstormar (fræðiheiti: Polychatete)."
ASSISTANT: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstaormar (fræðiheiti: Polychatete)."

USER: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjótsti."
ASSISTANT: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjósti."

USER: [input user query here]

Nous avons vu que l’ingénierie de prompts est un excellent point de départ et que des méthodes d’ajustement adaptées permettent d’améliorer considérablement les performances.

Toutefois, la principale limite de l’ingénierie de prompts est qu’elle passe souvent difficilement à l’échelle. Soit il faut fournir du contexte de façon dynamique pour permettre au modèle de traiter une gamme de problèmes plus large que ce que permet le simple ajout de contenu au contexte, soit il faut obtenir un comportement plus constant que ce que permettent les exemples few-shot.

Jusqu’où peut-on vraiment aller avec l’ingénierie de prompts ? Cela dépend du cas d’utilisation, et ce sont les évaluations qui vous permettront de décider.

Évaluation

C’est pourquoi un bon prompt accompagné d’un jeu d’évaluation composé de questions et de réponses de référence est le meilleur résultat à obtenir à cette étape. Avec un ensemble d’au moins 20 questions et réponses, une analyse détaillée des échecs et une hypothèse sur leurs causes, nous disposons d’une base solide pour passer à des méthodes d’optimisation plus avancées.

Avant de passer à des méthodes d’optimisation plus sophistiquées, réfléchissez aussi à la façon d’automatiser cette évaluation pour accélérer vos itérations. Voici quelques pratiques courantes dont nous avons constaté l’efficacité :

• Utilisez des approches comme ROUGE ou BERTScore pour obtenir une estimation approximative. Leurs résultats ne sont pas très étroitement corrélés aux jugements humains, mais ils permettent de mesurer rapidement et efficacement à quel point une itération a modifié les sorties du modèle.
• Utilisez GPT-4 comme évaluateur, selon la méthode décrite dans l’article G-Eval : fournissez au LLM une grille de notation pour qu’il évalue la sortie aussi objectivement que possible.

Pour approfondir ces approches, consultez ce cookbook, qui vous guide dans leur mise en pratique.

Comprendre les outils

Vous avez travaillé sur l’ingénierie de prompts et constitué un jeu d’évaluation, mais votre modèle ne fait toujours pas ce que vous attendez de lui. L’étape suivante, essentielle, consiste à déterminer où il échoue et quel outil convient le mieux pour l’améliorer.

Voici un cadre simple pour y parvenir :

Vous pouvez considérer chaque question d’évaluation ayant abouti à un échec comme un problème de mémoire contextuelle ou acquise . Pour illustrer cette distinction, imaginez que vous passez un examen. Vous disposez de deux moyens de trouver la bonne réponse :

• Vous avez suivi des cours pendant les 6 derniers mois et vu de nombreux exemples répétés du fonctionnement d’un concept particulier. Il s’agit de mémoire acquise . Avec les LLM, vous répondez à ce besoin en montrant au modèle des exemples de prompts et des réponses attendues, pour qu’il apprenne à partir de ces exemples.
• Vous avez le manuel avec vous et pouvez y chercher les informations nécessaires pour répondre à la question. Il s’agit de mémoire contextuelle . Avec les LLM, nous répondons à ce besoin en insérant des informations pertinentes dans la fenêtre de contexte, soit de façon statique par l’ingénierie de prompts, soit à grande échelle avec le RAG.

Ces deux méthodes d’optimisation sont cumulatives et non exclusives : elles se combinent, et certains cas d’utilisation nécessitent de les associer pour obtenir des performances optimales.

Supposons que nous soyons confrontés à un problème de mémoire à court terme. Nous allons utiliser le RAG pour le résoudre.

Génération augmentée par récupération (RAG)

Le RAG consiste à Récupérer du contenu pour Augmenter le prompt de votre LLM avant de Générer une réponse. Il permet de donner au modèle accès à un contexte propre à un domaine pour accomplir une tâche.

Le RAG est un outil extrêmement précieux pour améliorer la précision et la constance d’un LLM. Chez OpenAI, bon nombre des déploiements les plus importants de nos clients reposent uniquement sur l’ingénierie de prompts et le RAG.

Dans cet exemple, nous avons créé des représentations vectorielles d’une base de connaissances statistiques. Lorsqu’un utilisateur pose une question, nous en créons également une représentation vectorielle et récupérons le contenu le plus pertinent dans notre base de connaissances. Ce contenu est présenté au modèle, qui répond à la question.

Les applications RAG introduisent un nouvel axe d’optimisation : la récupération. Pour que notre RAG fonctionne, nous devons fournir le bon contexte au modèle, puis vérifier s’il répond correctement. Je vais présenter ces éléments sous forme de grille pour proposer une façon simple d’aborder l’évaluation du RAG :

Votre application RAG peut rencontrer des problèmes à deux niveaux :

L’essentiel à retenir est que le principe reste celui du modèle mental présenté au début : vous évaluez pour comprendre ce qui n’a pas fonctionné, puis vous appliquez une optimisation pour y remédier. Avec le RAG, la seule différence est que vous devez désormais aussi prendre en compte la récupération.

Bien qu’utile, le RAG ne résout que les problèmes d’apprentissage en contexte. Dans de nombreux cas d’utilisation, l’enjeu est de faire apprendre une tâche au LLM pour qu’il l’exécute de manière constante et fiable. Pour résoudre ce problème, nous nous tournons vers l’affinage.

Affinage

Pour résoudre un problème de mémoire acquise, de nombreux développeurs poursuivent l’entraînement du LLM sur un jeu de données plus restreint et propre à un domaine, afin de l’optimiser pour une tâche précise. Ce processus est appelé affinage.

L’affinage répond généralement à l’un des deux objectifs suivants :

• Améliorer la précision du modèle sur une tâche précise : entraîner le modèle sur des données propres à cette tâche pour résoudre un problème de mémoire acquise, en lui montrant de nombreux exemples d’exécution correcte.
• Améliorer l’efficacité du modèle : obtenir la même précision avec moins de tokens ou avec un modèle plus petit.

L’affinage commence par la préparation d’un jeu d’exemples d’entraînement. C’est l’étape la plus importante, car ces exemples doivent représenter exactement ce que le modèle rencontrera en conditions réelles.

Une fois ce jeu de données nettoyé, vous pouvez obtenir un modèle affiné en lançant un entraînement . Selon la plateforme ou le framework utilisé, vous pourrez éventuellement ajuster des hyperparamètres, comme pour tout autre modèle d’apprentissage automatique. Nous recommandons toujours de conserver un jeu de données à l’écart de l’entraînement pour l’utiliser lors de l’ évaluation qui suit, afin de détecter le surapprentissage. Pour savoir comment constituer un bon jeu d’entraînement, consultez les conseils de notre documentation sur l’affinage. Une fois l’entraînement terminé, le nouveau modèle affiné est disponible pour l’inférence.

Pour optimiser l’affinage, nous allons nous concentrer sur les bonnes pratiques observées avec les offres de personnalisation de modèles d’OpenAI. Ces principes devraient toutefois aussi s’appliquer aux autres fournisseurs et aux solutions open source. Voici les principales pratiques à suivre :

• Commencez par l’ingénierie de prompts : constituez à cette étape un jeu d’évaluation solide qui vous servira de référence. Cela permet de limiter l’investissement tant que vous n’avez pas confiance dans votre prompt de base.
• Commencez à petite échelle et privilégiez la qualité : lors de l’affinage d’un modèle de fondation, la qualité des données d’entraînement compte davantage que leur quantité. Commencez avec au moins 50 exemples, évaluez les résultats, puis augmentez la taille du jeu d’entraînement si vous n’avez pas encore atteint la précision requise et si les réponses incorrectes sont dues à des problèmes de constance ou de comportement, et non de contexte.
• Vérifiez que vos exemples sont représentatifs : l’un des écueils les plus fréquents est l’utilisation de données d’entraînement non représentatives, dont les exemples diffèrent subtilement, par leur format ou leur forme, de ce que le LLM rencontre en production. Par exemple, si vous développez une application RAG, affinez le modèle avec des exemples RAG pour qu’il n’ait pas à apprendre à utiliser le contexte en zero-shot.

Combiner toutes ces approches

Ces techniques se combinent : si vos premières évaluations révèlent des problèmes à la fois de contexte et de comportement, votre solution de production associera probablement affinage et RAG. C’est tout à fait normal : leur combinaison permet de compenser les faiblesses de chaque approche. Voici quelques-uns de ses principaux avantages :

• L’affinage permet de réduire au minimum le nombre de tokens utilisés pour l’ingénierie de prompts : les instructions et les exemples few-shot sont remplacés par de nombreux exemples d’entraînement qui ancrent un comportement constant dans le modèle.
• Enseigner des comportements complexes grâce à un affinage approfondi
• Utiliser le RAG pour ajouter du contexte, du contenu plus récent ou tout autre contexte spécialisé nécessaire à vos cas d’utilisation

# One training example
SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.
USER: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum í heiminum."
ASSISTANT: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum heims."

Vous devriez maintenant mieux comprendre le RAG et l’affinage, ainsi que les situations où chacun est adapté. Il reste un dernier point à retenir : leur introduction implique un compromis sur la vitesse d’itération :

• Avec le RAG, vous devez optimiser à la fois la récupération et le comportement du LLM
• Avec l’affinage, chaque optimisation supplémentaire nécessite de relancer le processus d’affinage et de gérer les jeux d’entraînement et de validation.

Ces deux processus peuvent être longs et complexes, et entraîner des régressions à mesure que votre application LLM se complexifie. Si vous ne deviez retenir qu’une chose de cet article, ce serait de tirer le maximum de précision des méthodes de base avant de recourir au RAG ou à l’affinage, plus complexes. Laissez votre objectif de précision guider vos choix, au lieu de vous précipiter vers le RAG + FT parce qu’ils sont perçus comme les méthodes les plus sophistiquées.

Quel niveau de précision est « suffisant » pour la production ?

Améliorer la précision des LLM peut être un effort sans fin : il est peu probable qu’ils atteignent une précision de 99,999 % avec des méthodes standard. Cette section explique comment déterminer le niveau de précision suffisant : comment déployer un LLM en production avec confiance et gérer les risques de la solution proposée.

Je trouve utile d’aborder cette question sous deux angles : métier et technique . Je vais présenter les grandes approches pour traiter ces deux aspects, puis prendre l’exemple d’un centre d’assistance client pour illustrer la gestion des risques dans chaque cas.

Aspect métier

Pour une entreprise, il peut être difficile de faire confiance aux LLM après la relative prévisibilité des systèmes à règles, des systèmes d’apprentissage automatique classiques, voire des humains ! Un système dont les échecs peuvent prendre des formes très diverses et imprévisibles pose un véritable défi.

J’ai vu une approche porter ses fruits dans un cas d’usage de service client. Voici comment nous avons procédé :

Nous commençons par identifier les principaux cas de réussite et d’échec, puis nous attribuons à chacun un coût estimé. Cela nous donne une idée claire des économies ou des coûts probables de la solution, à partir des résultats du pilote.

• Par exemple, une demande résolue par une IA alors qu’elle était auparavant traitée par un humain peut représenter une économie de 20 $.
• Un transfert inutile vers un humain pourrait coûter 40 $
• Dans le pire des cas, un client est tellement frustré par l’IA qu’il nous quitte, ce qui nous coûte 1 000 $. Nous supposons que cela se produit dans 5 % des cas.

Nous avons également mesuré des indicateurs empiriques sur le processus pour évaluer l’impact global de la solution. Toujours dans le cas du service client, il pourrait s’agir des indicateurs suivants :

• Le score CSAT des interactions exclusivement humaines comparé à celui des interactions avec l’IA
• Le taux de décisions correctes dans les dossiers examinés rétrospectivement, pour les humains et pour l’IA
• Le délai de résolution pour les humains et pour l’IA

Dans l’exemple du service client, cette démarche nous a aidés à prendre deux décisions clés après quelques essais pilotes destinés à recueillir des données fiables :

1. Même si notre solution fondée sur un LLM transférait les demandes à des humains plus souvent que nous le souhaitions, elle réduisait considérablement les coûts opérationnels par rapport à la solution existante. Un taux d’exactitude de seulement 85 % pouvait donc être acceptable, à condition que les 15 % restants correspondent principalement à des transferts effectués tôt dans le traitement des demandes.
2. Lorsque le coût d’une erreur était très élevé, par exemple pour un dossier de fraude mal résolu, nous avons décidé de laisser l’humain aux commandes et de confier à l’IA un rôle d’assistant. Dans ce cas, le taux de décisions correctes nous a aidés à conclure qu’une autonomie complète présentait trop de risques à nos yeux.

Aspects techniques

Sur le plan technique, les choses sont plus claires : maintenant que les équipes métier ont défini la valeur attendue et le coût des erreurs possibles, votre rôle consiste à créer une solution qui gère les échecs sans perturber l’expérience utilisateur.

Reprenons l’exemple du service client pour illustrer ce point, en supposant que notre modèle détermine correctement l’intention dans 85 % des cas. Voici quelques moyens dont dispose l’équipe technique pour limiter les conséquences des 15 % d’erreurs :

• Nous pouvons ajuster le prompt pour que le modèle demande davantage d’informations au client lorsqu’il n’est pas sûr de lui. Le taux d’exactitude à la première tentative peut alors baisser, mais nous pouvons obtenir de meilleurs résultats en disposant de 2 tentatives pour déterminer l’intention.
• Nous pouvons permettre à l’assistant de deuxième niveau de revenir à l’étape de détermination de l’intention. Le parcours utilisateur peut ainsi, là encore, se corriger de lui-même, au prix d’un délai supplémentaire pour l’utilisateur.
• Nous pouvons ajuster le prompt pour que le modèle passe le relais à un humain lorsque l’intention n’est pas claire. Cela réduit une partie des économies opérationnelles à court terme, mais peut limiter le risque de perdre des clients à long terme.

Ces décisions se répercutent ensuite sur l’expérience utilisateur : les échanges prennent plus de temps pour gagner en exactitude, ou nécessitent davantage d’interventions humaines. Ces dernières entrent dans le modèle de coûts présenté dans la section consacrée aux aspects métier.

Vous disposez désormais d’une méthode pour analyser les décisions métier et techniques nécessaires à la définition d’un objectif d’exactitude ancré dans la réalité de l’entreprise.

Pour aller plus loin

Ce cadre de réflexion général vous aide à envisager comment maximiser l’exactitude des LLM, quels outils utiliser pour y parvenir et comment déterminer le niveau suffisant pour la production. Vous disposez du cadre et des outils nécessaires pour mener régulièrement vos projets jusqu’à la production. Pour vous inspirer des résultats obtenus avec ces méthodes, consultez nos témoignages clients : les cas d’utilisation de Morgan Stanley et de Klarna illustrent ce que ces techniques permettent d’accomplir.

Bonne continuation ! Nous avons hâte de découvrir ce que vous allez créer grâce à ces méthodes !