Ce que j’ai appris en construisant avec des LLM pendant un an

• Le développement avec des grands modèles de langage (LLM) est à un moment passionnant
  • Au cours de l’année écoulée, les LLM sont devenus « suffisamment bons » pour de vraies applications, et ils s’améliorent tout en devenant moins chers chaque année
  • Avec les démos sur les réseaux sociaux, on estime qu’environ 200 milliards de dollars seront investis dans l’IA d’ici 2025
  • Les API des fournisseurs ont rendu les LLM plus accessibles, permettant non seulement aux ingénieurs et scientifiques en ML, mais à tout le monde, d’intégrer de l’intelligence dans des produits
• La barrière à l’entrée pour construire avec l’IA a baissé, mais il reste difficile de créer des produits et des systèmes efficaces au-delà des simples démos
• Nous avons construit au cours de l’année passée, et avons découvert de nombreuses difficultés en chemin
  • Nous voulons partager ce que nous avons appris pour vous aider à éviter nos erreurs et à itérer plus vite
• Cet article est composé de trois parties :
  1. Tactical (tactique) : quelques pratiques pour le prompting, le RAG, l’ingénierie de workflow, l’évaluation et la supervision
     • Écrit pour les praticiens qui construisent avec des LLM ou ceux qui travaillent sur un projet du week-end
  2. Operational (opérationnel) : les préoccupations organisationnelles et quotidiennes du lancement produit, et comment bâtir des équipes efficaces
     • Destiné aux responsables produit/tech qui veulent déployer de façon durable et fiable
  3. Strategic (stratégique) : des points de vue long terme et big picture comme « pas de GPU avant le PMF » ou « concentrez-vous sur le système, pas sur le modèle », ainsi que sur la manière d’itérer
     • Rédigé avec les fondateurs et les dirigeants en tête
• Ce guide vise à être un manuel pratique pour construire des produits à succès avec des LLM
  • Il est tiré de notre propre expérience et présente des exemples de toute l’industrie

[Tactique : l’essentiel de l’usage des LLM]

• Dans cette section, nous partageons des bonnes pratiques sur les composants clés de la stack LLM émergente
  • Cela inclut des conseils de prompting pour améliorer la qualité et la fiabilité, des stratégies pour évaluer les sorties, et des idées de retrieval augmented generation pour améliorer le grounding
  • Nous explorerons aussi comment concevoir des workflows human-in-the-loop

Tactique 1. Le prompting

• Lors du développement d’une nouvelle application, nous recommandons de commencer par le prompting
  • Il est facile de sous-estimer ou de surestimer l’importance du prompting
  • Il tend à être sous-estimé, car une bonne utilisation des bonnes techniques de prompting permet d’aller très loin
  • Il tend à être surestimé, car même les applications fondées sur des prompts nécessitent une ingénierie importante autour du prompt pour réellement bien fonctionner

Se concentrer sur l’exploitation maximale des techniques de base du prompting

• Certaines techniques de prompting aident de manière constante à améliorer les performances sur différents modèles et tâches
  • On peut citer les prompts N-shot + l’apprentissage en contexte, la Chain-of-Thought, ou encore la fourniture de ressources pertinentes
• Prompts N-shot et apprentissage en contexte
  • L’idée de l’apprentissage en contexte via des prompts N-shot consiste à montrer la tâche au LLM et à lui fournir quelques exemples pour aligner la sortie sur les attentes
  • Si N est trop faible, le modèle risque de trop s’ancrer sur ces exemples spécifiques et de moins bien généraliser
  • Empiriquement, visez N ≥ 5, et n’ayez pas peur d’aller jusqu’à plusieurs dizaines
  • Les exemples doivent être représentatifs de la distribution d’entrées attendue
  • Il n’est pas nécessaire de fournir des paires entrée/sortie complètes ; dans de nombreux cas, des exemples de la sortie souhaitée suffisent
  • Si vous utilisez un LLM prenant en charge l’usage d’outils, les exemples N-shot doivent eux aussi utiliser les outils que vous voulez voir l’agent employer
• Prompting en Chain-of-Thought (CoT)
  • Dans le prompting CoT, on encourage le LLM à expliquer son raisonnement avant de renvoyer la réponse finale
  • On peut voir cela comme le fait de donner au LLM un bloc-notes, pour qu’il n’ait pas à tout faire de mémoire
  • L’approche d’origine consistait simplement à ajouter une formule comme « réfléchissons étape par étape » dans les instructions, mais nous avons constaté qu’il était utile de rendre le CoT plus spécifique
  • Ajouter de la spécificité en 1 ou 2 phrases réduit souvent nettement le taux d’hallucination
  • Récemment, certains ont remis en question la puissance réelle de cette technique
  • Il existe aussi un débat important sur ce qui se passe exactement pendant le raisonnement lorsque le CoT est utilisé
  • Malgré cela, cela reste une technique qui vaut la peine d’être testée quand c’est possible
• Fournir des ressources pertinentes
  • Fournir des ressources pertinentes est un mécanisme puissant pour étendre la base de connaissances du modèle, réduire les hallucinations et renforcer la confiance de l’utilisateur
  • Cela se fait souvent via le retrieval augmented generation (RAG)
  • Fournir au modèle des extraits de texte qu’il peut directement exploiter dans sa réponse est une technique essentielle
  • Lorsqu’on fournit des ressources pertinentes, il ne suffit pas de simplement les inclure
    • Il ne faut pas oublier d’indiquer au modèle qu’il doit prioriser l’usage de ces ressources, les citer directement et parfois signaler quand elles ne suffisent pas
  • Ces éléments aident à « ancrer » les réponses de l’agent dans le corpus de ressources

Structurer les entrées et les sorties

• Les entrées et sorties structurées aident le modèle à mieux comprendre les entrées et à renvoyer des sorties pouvant s’intégrer de manière fiable aux systèmes en aval
  • Ajouter un format de sérialisation à l’entrée peut aider avec les relations entre les tokens du contexte, avec des métadonnées supplémentaires sur certains tokens (comme leur type), ou à relier la requête à des exemples similaires dans les données d’entraînement du modèle
  • Par exemple, beaucoup de questions sur l’écriture de SQL sur Internet commencent par la définition du schéma SQL
    • Un prompting efficace pour le Text-to-SQL devrait donc inclure une définition structurée du schéma
• Les sorties structurées servent un objectif similaire, mais simplifient l’intégration aux composants en aval du système
  • Instructor et Outlines fonctionnent bien pour les sorties structurées
    • (utilisez Instructor si vous importez le SDK d’une API LLM, et Outlines si vous utilisez Huggingface avec un modèle auto-hébergé)
  • Les entrées structurées expriment plus clairement la tâche et ressemblent davantage au format des données d’entraînement, ce qui augmente les chances d’obtenir une meilleure sortie
• Lorsque vous utilisez des entrées structurées, gardez à l’esprit que chaque famille de LLM a ses préférences
  • Claude préfère <xml>, tandis que GPT préfère Markdown et JSON
  • Avec XML, vous pouvez aussi préremplir la réponse de Claude en fournissant une balise <response>

Créer des prompts petits et spécialisés

• Un anti-pattern/code smell courant en logiciel est le « God Object », c’est-à-dire une classe ou une fonction unique qui fait tout
  • Cela s’applique de la même manière aux prompts
• Les prompts commencent généralement de façon simple
  • On peut commencer avec quelques phrases d’instructions et quelques exemples
  • Mais à mesure qu’on cherche à améliorer les performances et à gérer davantage de edge cases, la complexité augmente
    • On ajoute plus d’instructions, du raisonnement multi-étapes, des dizaines d’exemples, etc.
  • Au final, le prompt initialement simple devient un Frankenstein de 2 000 tokens
    • Et, en plus, ses performances se dégradent parfois sur des entrées plus générales et intuitives
    • GoDaddy a classé ce problème comme la leçon n°1 tirée de sa construction avec les LLM
• De la même manière qu’on essaie de garder le système et le code simples, il faut faire pareil avec les prompts
  • Au lieu d’utiliser un unique prompt universel pour un résumeur de transcription de réunion, on peut le découper en étapes comme :
    • extraire les décisions clés, les actions à mener et leurs responsables dans un format structuré
    • vérifier la cohérence des détails extraits par rapport à la transcription originale
    • générer un résumé concis à partir des détails structurés
• Le résultat consiste à scinder un prompt unique en plusieurs prompts simples, ciblés et faciles à comprendre
  • Une fois ce découpage fait, on peut itérer et évaluer chaque prompt individuellement

Créer des tokens de contexte

• Il faut remettre en question et tester nos hypothèses sur la quantité de contexte qu’il faut réellement envoyer à l’agent
  • Au lieu de sculpter le contexte comme Michel-Ange en ajoutant morceau après morceau, il faut retirer la matière inutile pour faire apparaître la sculpture
  • Le RAG est une méthode largement utilisée pour rassembler tous les blocs de marbre potentiellement pertinents, mais que fait-on pour en extraire ce dont on a besoin ?
• J’ai constaté qu’il est utile, pour repenser le contexte, de prendre le prompt final envoyé au modèle, de le poser sur une page blanche avec toute la construction de contexte, le meta-prompting et les résultats du RAG, puis de le relire
  • Cette méthode permet de repérer les redondances, les formulations contradictoires et les problèmes de format
• Une autre optimisation essentielle concerne la structure du contexte
  • Une représentation en bag-of-docs n’aide pas les humains ; il ne faut donc pas supposer qu’elle convient aux agents
  • Il faut réfléchir soigneusement à la manière de structurer le contexte afin de mettre en évidence les relations entre ses différentes parties et de rendre l’extraction aussi simple que possible

Tactique 2. Recherche d’information / RAG

• Au-delà du prompting, une autre manière efficace d’orienter un LLM consiste à lui fournir des connaissances dans le prompt
  • Cela permet d’ancrer le LLM dans le contexte fourni, utilisé pour l’apprentissage en contexte
  • C’est ce qu’on appelle la génération augmentée par récupération (Retrieval-Augmented Generation, RAG)
  • Les praticiens ont constaté que le RAG est efficace pour fournir des connaissances et améliorer les sorties, avec bien moins d’effort et de coût que le fine-tuning
  • Le RAG n’est bon que dans la mesure où les documents récupérés sont pertinents, denses en information et détaillés

La qualité des sorties du RAG dépend de la qualité des documents récupérés, et plusieurs facteurs peuvent être pris en compte

• Le premier critère, et le plus évident, est la « pertinence »
  • Elle est généralement quantifiée par des métriques de ranking comme le Mean Reciprocal Rank (MRR) ou le Normalized Discounted Cumulative Gain (NDCG)
  • Le MRR évalue la capacité du système à bien placer le premier résultat pertinent dans une liste classée, tandis que le NDCG prend en compte la pertinence et la position de tous les résultats
  • Ces métriques mesurent la performance d’un système à classer plus haut les documents pertinents et plus bas les documents non pertinents
  • Par exemple, si l’on récupère des résumés utilisateurs pour produire un résumé d’avis de film, il est préférable de classer plus haut les avis sur le film concerné et d’exclure ceux sur d’autres films
  • Comme dans les systèmes de recommandation traditionnels, le classement des éléments récupérés a un impact important sur la manière dont le LLM exécute la tâche en aval
  • Pour mesurer cet impact, exécutez la tâche fondée sur le RAG en mélangeant les éléments récupérés, puis observez comment la sortie RAG se comporte
• Le deuxième facteur est la « densité informationnelle »
  • Si deux documents sont également pertinents, il faut préférer celui qui est plus concis et contient moins de détails hors sujet
  • Pour reprendre l’exemple du cinéma, le script du film et l’ensemble des avis utilisateurs peuvent être considérés comme pertinents au sens large
  • Malgré cela, les avis très bien notés et les critiques éditoriales ont davantage de chances d’avoir une densité informationnelle plus élevée
• Enfin, il faut prendre en compte le « niveau de détail » fourni par le document
  • Imaginons que l’on construise un système RAG pour générer des requêtes SQL à partir du langage naturel
    • Fournir comme contexte uniquement le schéma des tables avec les noms de colonnes peut suffire
    • Mais qu’en serait-il si l’on ajoutait les descriptions de colonnes et quelques valeurs représentatives ?
  • Ces détails supplémentaires peuvent aider le LLM à mieux comprendre le sens des tables et à générer un SQL plus précis

N’oubliez pas la recherche par mots-clés, à utiliser comme baseline et dans la recherche hybride

• Comme les démos de RAG fondé sur des embeddings se sont largement diffusées, il est facile d’oublier ou de négliger des décennies de recherche et de solutions en recherche d’information
  • Pourtant, même si les embeddings sont sans aucun doute un outil puissant, ils ne sont pas une solution universelle
• Avantages de la recherche fondée sur les mots-clés
  • D’abord, les embeddings excellent à capter une similarité sémantique de haut niveau, mais peuvent être en difficulté sur des requêtes plus spécifiques et fondées sur des mots-clés, par exemple quand un utilisateur recherche un nom (ex. : Ilya), un acronyme (ex. : RAG) ou un identifiant (ex. : claude-3-sonnet)
    • La recherche par mots-clés comme BM25 est explicitement conçue pour cela
    • Les utilisateurs se sont appuyés sur la recherche par mots-clés pendant si longtemps qu’ils la considèrent comme acquise ; ils peuvent donc être frustrés si le document qu’ils veulent retrouver n’est pas renvoyé
  • Ensuite, il est plus intuitif de comprendre pourquoi un document a été retrouvé avec une recherche par mots-clés
    • Parce qu’on peut voir quels mots-clés correspondent à la requête
    • À l’inverse, la recherche fondée sur des embeddings est moins interprétable
  • Enfin, grâce à des systèmes comme Lucene ou OpenSearch, optimisés et éprouvés en production depuis des décennies, la recherche par mots-clés est généralement plus efficace sur le plan computationnel
• Dans la plupart des cas, une approche hybride est la plus efficace
  • Utiliser le matching par mots-clés pour les correspondances évidentes, et les embeddings pour les synonymes, hyperonymes, fautes d’orthographe et le multimodal (par ex. : image et texte)
  • Shortwave a partagé sa manière de construire son pipeline RAG, avec réécriture de requête, recherche par mots-clés + embeddings, ranking, etc.

Pour les nouvelles connaissances, privilégier le RAG au fine-tuning

• Le RAG comme le fine-tuning peuvent tous deux servir à intégrer de nouvelles informations dans un LLM et à améliorer les performances sur des tâches spécifiques
  • Alors, lequel faut-il essayer en premier ?
• Avantages du RAG
  • Des travaux récents suggèrent que le RAG peut être supérieur
  • Une étude a comparé le RAG et le fine-tuning non supervisé (aussi appelé pré-entraînement continu) sur MMLU et un sous-ensemble de questions d’actualité
    • Le RAG a montré de manière constante de meilleures performances que le fine-tuning, à la fois sur les connaissances vues pendant l’entraînement et sur des connaissances entièrement nouvelles
  • Un autre article a comparé le RAG et le fine-tuning supervisé sur un jeu de données agricole
    • Là encore, le gain de performance du RAG était supérieur à celui du fine-tuning, en particulier avec GPT-4 (voir le tableau 20 de l’article)
  • Au-delà des gains de performance, le RAG présente plusieurs avantages pratiques
    • D’abord, il est plus simple et moins coûteux de maintenir un index de recherche à jour que de faire du pré-entraînement continu ou du fine-tuning
    • Ensuite, si l’index de recherche contient un document problématique avec du contenu nocif ou biaisé, il est facile de supprimer ou de corriger ce document
  • Par ailleurs, le « R » de RAG offre un contrôle plus fin sur la manière de récupérer les documents
    • Par exemple, si l’on héberge un système RAG pour plusieurs organisations, on peut partitionner l’index de recherche afin que chaque organisation ne puisse récupérer que les documents de son propre index
    • Cela permet d’éviter d’exposer par erreur les informations d’une organisation à une autre

Les modèles à long contexte ne rendront pas le RAG inutile

• Avec Gemini 1.5, qui offre une fenêtre de contexte pouvant aller jusqu’à 10 millions de tokens, certains ont commencé à remettre en question l’avenir du RAG
  • Une fenêtre de contexte de 10 millions de tokens rend inutile la plupart des frameworks RAG existants
    • Il suffit de placer les données dans le contexte et d’échanger avec le modèle comme d’habitude
  • Imaginez l’impact que cela pourrait avoir sur les startups, les agents et les projets langchain dont l’essentiel des efforts d’ingénierie est consacré au RAG
    • Résumé en une phrase : un contexte de 10 millions tue le RAG
• Le besoin persistant du RAG
  • S’il est vrai que les contextes longs seront un game changer pour des cas d’usage comme l’analyse de plusieurs documents ou le chat avec des PDF, les rumeurs sur la fin du RAG sont largement exagérées
    • Premièrement, même avec une fenêtre de contexte de 10 millions de tokens, il faut toujours un moyen de choisir quelles informations fournir au modèle
    • Deuxièmement, au-delà des évaluations de type « aiguille dans une botte de foin », je n’ai pas encore vu de données convaincantes montrant que les modèles peuvent raisonner efficacement sur un contexte aussi vaste
    • Ainsi, sans une bonne recherche (et un bon ranking), on risque soit de submerger le modèle avec des informations distrayantes, soit même de remplir entièrement la fenêtre de contexte avec des informations totalement non pertinentes
• Enfin, il y a la question du coût
  • Le coût d’inférence des Transformers augmente de façon quadratique avec la longueur du contexte (ou linéaire à la fois en espace et en temps)
  • Ce n’est pas parce qu’il existe un modèle capable de lire tout le contenu du Google Drive d’une organisation qu’il est judicieux de le faire avant de répondre à chaque question
  • Prenons une analogie avec l’usage de la RAM
    • Il existe des instances de calcul disposant de dizaines de téraoctets de RAM, mais on continue malgré tout à lire et écrire sur disque
• Donc, ne jetez pas encore le RAG à la poubelle
  • Ce pattern restera utile même à mesure que la taille des fenêtres de contexte augmentera

Tactique 3. Réglage et optimisation des workflows

• Donner un prompt à un LLM n’est qu’un point de départ
  • Pour tirer le meilleur parti des LLM, il faut aller au-delà d’un prompt unique et adopter des workflows
  • Par exemple, comment décomposer une tâche complexe en plusieurs tâches plus simples ?
  • À quel moment le fine-tuning ou le caching peuvent-ils aider à améliorer les performances et à réduire la latence ou les coûts ?
• Cette section partage des stratégies éprouvées et des cas concrets pour aider à optimiser et construire des workflows LLM

Les « Flow » étape par étape, en multi-tour, peuvent apporter de gros gains de performance

• On sait déjà qu’on peut obtenir de meilleurs résultats en décomposant un gros prompt en plusieurs petits prompts
  • AlphaCodium en est un exemple
    • En passant d’un prompt unique à un workflow en plusieurs étapes, il a fait passer la précision de GPT-4 (pass@5) sur CodeContests de 19 % à 44 %
  • Le workflow comprend
    • réflexion sur le problème
    • raisonnement sur les tests publics
    • génération de solutions possibles
    • classement des solutions possibles
    • génération de tests synthétiques
    • itération sur les solutions à partir des tests publics et synthétiques
• De petites tâches avec un objectif clair produisent les meilleurs prompts d’agent ou de flow
  • Tous les prompts d’agent n’ont pas besoin de demander une sortie structurée, mais les sorties structurées aident beaucoup pour l’interface avec les systèmes qui orchestrent l’interaction de l’agent avec son environnement
• Pistes à essayer
  • une étape de planification explicite, spécifiée aussi strictement que possible
    • envisager de faire choisir parmi des plans prédéfinis
  • réécrire le prompt utilisateur d’origine en prompt d’agent
    • attention : ce processus entraîne une perte d’information
  • le comportement d’agent sous forme de chaîne linéaire, de DAG et de machine à états
    • des dépendances et relations logiques différentes peuvent être plus ou moins adaptées selon l’échelle
    • peut-on obtenir une optimisation des performances selon différentes architectures de tâches ?
  • validation du plan
    • le plan peut inclure des instructions sur la manière d’évaluer les réponses d’autres agents afin que le livrable final fonctionne correctement
  • prompt engineering avec un état amont fixe
    • s’assurer que les prompts d’agent sont évalués face aux différentes variations possibles en amont

Pour l’instant, privilégier les workflows déterministes

• Les agents IA peuvent réagir dynamiquement aux demandes des utilisateurs et à l’environnement, mais leur nature non déterministe complique leur déploiement
  • Chaque étape exécutée par un agent peut échouer, et la probabilité de récupération après erreur est faible
  • Ainsi, la probabilité qu’un agent mène à bien une tâche en plusieurs étapes diminue de façon exponentielle à mesure que le nombre d’étapes augmente
  • En conséquence, les équipes qui construisent des agents peinent à déployer des agents réellement fiables
• Une approche prometteuse consiste à disposer d’un système d’agents qui génère un plan déterministe puis l’exécute de manière structurée et reproductible
  • Dans une première étape, l’agent génère un plan à partir d’un objectif de haut niveau ou d’un prompt
  • Ensuite, le plan est exécuté de manière déterministe
  • Cela permet de rendre chaque étape plus prévisible et plus fiable
  • Avantages
    • Les plans générés peuvent servir d’exemples few-shot pour prompter les agents ou les fine-tuner
    • L’exécution déterministe rend le système plus fiable, facilite les tests et le débogage. De plus, les échecs peuvent être retracés jusqu’à une étape précise du plan
    • Les plans générés peuvent être représentés sous forme de graphe orienté acyclique (DAG), ce qui les rend plus faciles à comprendre et à adapter à de nouvelles situations qu’un prompt statique
• Les personnes qui réussissent le mieux à construire des agents sont peut-être celles qui ont une forte expérience dans la gestion de développeurs juniors
  • Parce que le processus de génération de plans ressemble à la manière de guider et d’encadrer des juniors
  • De la même façon qu’on donne à un junior des objectifs clairs et un plan précis plutôt que des orientations vagues et ouvertes, il faut faire de même avec les agents
• En fin de compte, la clé d’agents fiables et opérationnels réside probablement dans
  • l’adoption d’une approche plus structurée et déterministe,
  • et la collecte de données pour améliorer les prompts et fine-tuner les modèles
• Sans cela, vous construirez des agents qui peuvent parfois très bien fonctionner, mais qui décevront les utilisateurs en moyenne et entraîneront une faible rétention

Obtenir des sorties variées autrement qu’avec le paramètre de température

• Supposons que vous ayez une tâche qui nécessite de la diversité dans les sorties d’un LLM
  • Vous êtes peut-être en train d’écrire un pipeline LLM qui suggère des produits à acheter dans un catalogue en tenant compte de la liste des produits déjà achetés par l’utilisateur
  • Vous pouvez constater que, lorsque vous exécutez plusieurs fois le prompt, les recommandations obtenues sont trop similaires
  • Vous pourriez donc augmenter le paramètre Temperature de la requête LLM
• Augmenter le paramètre de température rend les réponses du LLM plus variées
  • Lors de l’échantillonnage, la distribution de probabilité du token suivant devient plus plate, ce qui fait que des tokens normalement moins susceptibles d’être choisis le sont plus souvent
• Mais augmenter la température peut entraîner certains modes d’échec liés à la diversité des sorties
  • Par exemple, certains produits du catalogue pourraient être pertinents sans jamais être produits par le LLM
  • Si le LLM est fortement enclin à suivre ce qu’il a appris pendant l’entraînement, le même petit nombre de produits peut être surreprésenté dans les sorties
  • Si la température est trop élevée, on peut générer des sorties qui font référence à des produits inexistants (ou à du contenu dénué de sens)
• Augmenter la température ne garantit pas non plus que le LLM échantillonne les sorties selon la distribution de probabilité que vous attendez (par exemple, un aléatoire uniforme)
• Malgré cela, il existe d’autres astuces pour augmenter la diversité des sorties
  • La plus simple consiste à ajuster des éléments dans le prompt
    • Par exemple, si le template de prompt inclut une liste d’éléments comme l’historique d’achats, le fait d’en mélanger l’ordre à chaque insertion dans le prompt peut produire une différence notable
  • Conserver aussi une courte liste des sorties récentes aide à éviter les doublons
    • Dans l’exemple des produits recommandés, on peut demander au LLM d’éviter de proposer des éléments figurant dans cette liste récente, ou diversifier davantage les réponses en rejetant les sorties trop proches des suggestions récentes puis en rééchantillonnant
  • Une autre stratégie efficace consiste à varier les formulations utilisées dans le prompt
    • Par exemple, intégrer des formulations comme « sélectionner des éléments que l’utilisateur aimerait utiliser régulièrement » ou « sélectionner des produits que l’utilisateur serait susceptible de recommander à des amis » peut déplacer le point focal et influencer la diversité des produits recommandés

Le caching est sous-estimé

• La mise en cache réduit les coûts en supprimant la nécessité de recalculer les réponses pour une même entrée et élimine la latence de génération
  • De plus, si une réponse a déjà été soumise à des garde-fous, on peut servir cette réponse validée afin de réduire le risque de fournir un contenu nuisible ou inapproprié
• Une approche simple de la mise en cache consiste à utiliser un identifiant unique pour l’élément en cours de traitement, par exemple lors du résumé d’un nouvel article ou d’un test produit
  • Lorsqu’une requête arrive, on peut vérifier si un résumé existe déjà dans le cache
    • Si oui, on peut le renvoyer immédiatement ; sinon, on le génère, on lui applique les garde-fous et on le sert, puis on le stocke dans le cache pour les futures requêtes
• Pour des requêtes plus ouvertes, on peut emprunter aux techniques de recherche qui exploitent aussi le cache pour des entrées ouvertes
  • Des fonctionnalités comme l’autocomplétion et la correction orthographique aident à normaliser la saisie utilisateur afin d’augmenter le taux de succès du cache

Quand le finetune (fine-tuning) devient nécessaire

• Certaines tâches peuvent rester hors de portée même du prompt le plus intelligemment conçu
  • Par exemple, même après un important travail de prompt engineering, le système peut encore être loin de produire des sorties fiables et de haute qualité
  • Dans ce cas, il peut être nécessaire de fine-tuner le modèle pour une tâche spécifique
• Exemples de fine-tuning réussi
  • Honeycomb et son Natural Language Query Assistant
    • Au départ, un « manuel de programmation » était fourni dans le prompt avec des exemples n-shot pour l’apprentissage en contexte
    • Cela fonctionnait correctement, mais le fine-tuning du modèle permet d’obtenir de meilleures sorties sur la syntaxe et les règles propres au domaine
  • Lucy de Rechat
    • Le LLM doit générer une réponse dans un format très spécifique, combinant données structurées et non structurées, pour que le frontend puisse l’afficher correctement
    • Le fine-tuning est indispensable pour que cela fonctionne de manière cohérente
• Le fine-tuning peut être efficace, mais il implique un coût important
  • Il faut annoter les données de fine-tuning, fine-tuner et évaluer le modèle, puis finalement l’héberger soi-même
  • Il faut donc se demander si ce coût initial plus élevé en vaut la peine
• Si le prompting permet déjà d’atteindre 90 %, il peut ne pas être rentable d’investir dans le fine-tuning
  • En revanche, si vous décidez de fine-tuner, vous pouvez générer et fine-tuner sur des données synthétiques ou amorcer le processus à partir de données open source afin de réduire le coût de collecte de données annotées par des humains

Tactique 4. Évaluation et monitoring

• L’évaluation des LLM peut être un champ de mines
  • Les entrées et sorties d’un LLM sont du texte arbitraire, et les tâches qu’on lui assigne sont elles aussi variées
  • Malgré cela, une évaluation rigoureuse et soigneuse est essentielle
    • Ce n’est pas un hasard si les responsables techniques d’OpenAI participent aux évaluations et donnent leur avis sur des évaluations individuelles
• L’évaluation des applications LLM nécessite une diversité de définitions et de réductions
  • Cela peut être simplement des tests unitaires, quelque chose de plus proche de l’observabilité, ou tout simplement de la data science
  • Nous avons constaté que toutes ces perspectives sont utiles
• Dans cette section, nous présentons les enseignements tirés de la construction d’un pipeline d’évaluation et de monitoring

Générer quelques tests unitaires basés sur des assertions à partir d’échantillons réels d’entrées et de sorties

• Créez des tests unitaires (c’est-à-dire des assertions) à partir d’échantillons d’entrées et de sorties issus de la production, et définissez les attentes sur la sortie selon au moins trois critères
  • Trois critères peuvent sembler arbitraires, mais c’est un seuil pratique pour démarrer
    • S’il y en a moins, la tâche est peut-être insuffisamment définie, ou trop ouverte, comme un chatbot généraliste
  • Ces tests unitaires ou assertions doivent être déclenchés par des changements dans le pipeline, comme une modification du prompt, l’ajout d’un nouveau contexte via le RAG ou d’autres ajustements
• Envisagez de commencer par des assertions qui spécifient les formulations ou idées à inclure ou à exclure dans chaque réponse
  • Pensez également à des vérifications sur le fait que le nombre de mots, d’éléments ou de phrases se situe bien dans une plage donnée
  • Pour d’autres types de génération, les assertions auront une autre forme
    • Par exemple, dans l’évaluation par exécution, une méthode robuste pour évaluer la génération de code, on exécute le code généré et on vérifie si l’état d’exécution répond suffisamment à la demande de l’utilisateur
• Par exemple, si l’utilisateur demande une nouvelle fonction appelée foo, on doit pouvoir appeler foo après avoir exécuté le code généré par l’agent
• Une difficulté de l’évaluation par exécution est que le code de l’agent laisse souvent l’environnement d’exécution dans un état légèrement différent du code cible
  • Il peut être efficace d’« assouplir » les assertions jusqu’aux hypothèses les plus faibles qui puissent être satisfaites par toute réponse valide
• Utiliser le produit comme prévu pour les clients (« dogfooding ») peut fournir des informations sur les modes de défaillance à partir de données réelles
  • Cette approche aide non seulement à identifier les faiblesses potentielles, mais fournit aussi une source utile d’échantillons de production pouvant être convertis en évaluations

LLM-as-Judge peut fonctionner (dans une certaine mesure), mais ce n’est pas une solution miracle

• Le LLM-as-Judge consiste à utiliser un LLM puissant pour évaluer les sorties d’un autre LLM, ce qui suscite du scepticisme chez certaines personnes
• Malgré cela, lorsqu’il est bien mis en œuvre, le LLM-as-Judge peut atteindre une corrélation significative avec le jugement humain et, au minimum, aider à construire une intuition préalable sur la manière dont un nouveau prompt ou une nouvelle technique pourrait se comporter
  • En particulier dans les comparaisons par paires (par exemple témoin vs traitement), le LLM-as-Judge a généralement la bonne intuition directionnelle, même si l’ampleur du gain ou de la perte peut rester bruitée
• Suggestions pour tirer le meilleur parti du LLM-as-Judge
  • Utiliser des comparaisons par paires
    • Au lieu de demander au LLM d’évaluer une sortie unique sur une échelle de Likert, présentez-lui deux options et demandez-lui de choisir la meilleure
    • Cela tend à produire des résultats plus stables
  • Contrôler le biais de position
    • L’ordre des options présentées peut biaiser la décision du LLM
    • Pour atténuer cela, effectuez chaque comparaison par paires deux fois en inversant l’ordre à chaque fois
    • Après permutation, il faut attribuer correctement la victoire à la bonne option
  • Autoriser les égalités
    • Dans certains cas, les deux options peuvent être tout aussi bonnes
    • Il faut donc permettre au LLM de déclarer une égalité afin qu’il n’ait pas à choisir un vainqueur de manière arbitraire
  • Utiliser le Chain-of-Thought
    • Demander au LLM d’expliquer sa décision avant d’indiquer sa préférence finale peut améliorer la fiabilité de l’évaluation
    • En bonus, cela permet d’utiliser un LLM plus petit mais plus rapide tout en obtenant des résultats similaires
    • Comme cette partie du pipeline fonctionne souvent en mode batch, la latence supplémentaire due au CoT n’est pas problématique
  • Contrôler la longueur des réponses
    • Les LLM ont tendance à favoriser les réponses plus longues
    • Pour atténuer cela, assurez-vous que les deux réponses comparées ont une longueur similaire
• Une application particulièrement puissante du LLM-as-Judge consiste à vérifier qu’une nouvelle stratégie de prompt n’introduit pas de régression
  • Si vous avez conservé un ensemble de résultats de production, vous pouvez parfois relancer ces exemples de production avec la nouvelle stratégie de prompt et utiliser le LLM-as-Judge pour évaluer rapidement où la nouvelle stratégie risque de rencontrer des difficultés
• Exemple d’approche simple mais efficace du LLM-as-Judge
  • Il suffit d’enregistrer la réponse du LLM, la critique du juge (c’est-à-dire le CoT) et le résultat final
  • Puis de les passer en revue avec les parties prenantes afin d’identifier les axes d’amélioration
  • Après trois itérations, le taux d’accord entre humains et LLM est passé de 68 % à 94 %
• Cependant, le LLM-as-Judge n’est pas une solution miracle
  • Même les modèles les plus puissants échouent à évaluer de manière fiable certains aspects linguistiques subtils
• Nous avons également constaté que les classifieurs traditionnels et les reward models peuvent atteindre une précision supérieure au LLM-as-Judge, avec un coût et une latence moindres
  • Pour la génération de code, le LLM-as-Judge peut être moins performant que des stratégies d’évaluation plus directes, comme l’évaluation par exécution

Le « test du stagiaire » pour évaluer les résultats générés

• Lors de l’évaluation des résultats générés, il est utile d’utiliser le « test de l’interne » suivant
  • Si l’on prenait l’entrée exacte donnée au modèle de langage, contexte compris, pour la confier comme exercice à un étudiant moyen de premier cycle dans la spécialité concernée, réussirait-il ?
  • Combien de temps cela lui prendrait-il ?
• Si la réponse est non
  • Si c’est parce que le LLM ne dispose pas des connaissances nécessaires, envisager d’enrichir le contexte
  • Si cela ne se résout pas même après amélioration du contexte, la tâche est peut-être trop difficile pour les LLM actuels
• Si la réponse est oui, mais que cela prend du temps
  • On peut essayer de réduire la complexité de la tâche
    • Peut-on la décomposer ?
    • Quels aspects de la tâche peuvent être davantage mis sous forme de template ?
• Si la réponse est oui et que cela peut être fait rapidement
  • En examinant les données
    • Sur quoi le modèle se trompe-t-il ?
    • Peut-on repérer des motifs d’échec ?
  • Essayer de demander au modèle d’expliquer son raisonnement avant ou après sa réponse

Trop insister sur une évaluation spécifique peut dégrader les performances globales

« Lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. » - loi de Goodhart

• Un exemple est l’évaluation Needle-in-a-Haystack (NIAH)
  • À l’origine, cette évaluation aide à quantifier le rappel du modèle à mesure que la taille du contexte augmente, et à voir comment la position de l’aiguille affecte ce rappel
  • Mais elle a été tellement mise en avant qu’elle a été présentée comme Figure 1 dans le rapport de Gemini 1.5
  • Cette évaluation consiste à insérer une phrase spécifique (« The special magic {city} number is: {number} ») dans un long document répétant des essais de Paul Graham, puis à demander au modèle de rappeler le nombre magique
• Certains modèles atteignent un rappel presque parfait, mais on peut douter que NIAH reflète réellement les capacités de raisonnement et de rappel nécessaires dans des applications réelles
• Considérons des scénarios plus pratiques
  • Si on donne la transcription d’une réunion d’une heure, le LLM peut-il résumer les décisions clés et les prochaines étapes, tout en attribuant correctement chaque élément au bon responsable ?
  • Cette tâche est plus réaliste, car elle va au-delà de la simple mémorisation et prend aussi en compte la capacité à comprendre une discussion complexe, à identifier les informations pertinentes et à produire une synthèse
• Exemple d’évaluation NIAH plus pratique
  • Utiliser la transcription d’un appel vidéo médecin-patient et poser au LLM des questions sur les médicaments du patient
  • Inclure aussi un NIAH plus difficile, par exemple en insérant des phrases sur des ingrédients aléatoires nécessaires pour une garniture de pizza, comme des dattes trempées dans un espresso, du citron ou du fromage de chèvre
  • Le rappel était d’environ 80 % pour la tâche sur les médicaments, et de 30 % pour la tâche sur la pizza
• Trop insister sur l’évaluation NIAH peut dégrader les performances sur les tâches d’extraction et de synthèse
  • Comme ces LLM sont affinés pour prêter attention à chaque phrase, ils peuvent commencer à traiter des détails non pertinents et des distractions comme s’ils étaient importants
  • Ils peuvent alors apparaître dans la sortie finale (même quand ils ne devraient pas !)
• Cela peut aussi s’appliquer à d’autres évaluations et cas d’usage
  • Par exemple, pour le résumé
    • Mettre l’accent sur la cohérence factuelle peut produire des résumés moins spécifiques, et donc potentiellement moins pertinents
    • À l’inverse, insister sur le style d’écriture et l’éloquence peut générer un langage plus tape-à-l’œil, de type marketing, susceptible d’entraîner des incohérences factuelles

Simplifier l’annotation en tâche binaire ou en comparaison pairwise

• Donner un retour ouvert sur la sortie d’un modèle ou l’évaluer sur une échelle de Likert est cognitivement exigeant
  • En conséquence, les données collectées sont plus bruitées à cause de la variabilité entre évaluateurs humains, et donc moins utiles
• Une approche plus efficace consiste à simplifier la tâche et à réduire la charge cognitive des annotateurs
  • Deux formats qui fonctionnent bien sont la classification binaire et la comparaison pairwise
• En classification binaire, on demande aux annotateurs de porter un jugement simple oui/non sur la sortie du modèle
  • On peut par exemple demander si le résumé généré est factuellement cohérent avec le document source, si la réponse proposée est pertinente, ou si elle contient un contenu nuisible
  • Par rapport à une échelle de Likert, les décisions binaires sont plus précises, plus cohérentes entre évaluateurs et offrent un meilleur débit
  • C’est ainsi que DoorDash a mis en place une file de labellisation pour étiqueter les éléments de menu via une série de questions oui/non
• En comparaison pairwise, les annotateurs reçoivent une paire de réponses de modèle et doivent indiquer laquelle est meilleure
  • Comme il est plus facile pour un humain de dire « A est meilleur que B » que de noter séparément A ou B, cela conduit à des annotations plus rapides et plus fiables que sur une échelle de Likert
• Lors d’un meetup Llama2, Thomas Scialom, l’un des auteurs du papier Llama2, a confirmé que la comparaison pairwise est plus rapide et moins coûteuse que la collecte de données de supervised fine-tuning sous forme de réponses rédigées
  • Le coût de la première est de 3,5 $ par unité, contre 25 $ par unité pour la seconde

Les évaluations reference-free et les guardrails peuvent être utilisés de manière interchangeable

• Les guardrails aident à détecter les contenus inappropriés ou nuisibles, tandis que les évaluations servent à mesurer la qualité et l’exactitude des sorties du modèle
  • Dans le cas des évaluations reference-free, on peut les voir comme les deux faces d’une même pièce
    • Une évaluation reference-free permet d’évaluer la qualité d’une sortie à partir du prompt d’entrée et de la réponse du modèle uniquement, sans dépendre d’une référence « golden » telle qu’une réponse rédigée par un humain
• Exemple d’évaluation reference-free : l’évaluation de résumé
  • Il suffit de considérer le document d’entrée pour évaluer la cohérence factuelle et la pertinence du résumé
  • Si le résumé obtient un faible score sur ces métriques, on peut choisir de ne pas l’afficher à l’utilisateur, ce qui revient à utiliser l’évaluation comme un guardrail
• Évaluation « de traduction » reference-free :
  • Il est possible d’évaluer la qualité d’une traduction sans référence traduite par un humain, et donc de l’utiliser à nouveau comme guardrail

Les LLM renvoient parfois une sortie alors qu’ils ne devraient pas

• Un défi majeur quand on travaille avec des LLM est qu’ils génèrent souvent une sortie même lorsqu’ils ne devraient pas
  • Cela peut produire des réponses inoffensives mais dénuées de sens, ou des défauts plus graves comme des contenus nuisibles ou dangereux
  • Par exemple, si on leur demande d’extraire certains attributs ou métadonnées d’un document, les LLM peuvent renvoyer une valeur avec assurance même lorsque cette valeur n’existe pas réellement
  • Ou bien le modèle peut répondre dans une langue autre que l’anglais parce qu’on lui a fourni dans le contexte des documents non anglophones
• On peut inciter le LLM, via le prompt, à renvoyer « non applicable » ou « inconnu », mais ce n’est pas parfait
  • Même quand on a accès aux log probabilities, elles restent un mauvais indicateur de la qualité de la sortie
    • Les log probabilities indiquent la probabilité d’apparition des tokens dans la sortie, mais ne reflètent pas l’exactitude du texte généré
  • Pire encore, pour les modèles instruction-tuned entraînés à répondre aux requêtes et à produire des réponses cohérentes, les log probabilities peuvent être mal calibrées
    • Ainsi, une log probability élevée peut indiquer que la sortie est fluide et cohérente, sans pour autant être exacte ni pertinente
• Un prompt engineering soigné peut aider dans une certaine mesure, mais il doit être complété par des guardrails robustes capables de détecter les sorties indésirables et de les filtrer ou régénérer
  • Par exemple, OpenAI fournit une API de content moderation capable d’identifier des réponses non sûres comme les discours haineux, l’automutilation ou des sorties à caractère sexuel
  • De même, il existe de nombreux packages pour détecter les informations personnelles identifiables (PII)
• L’un des avantages des guardrails est qu’ils sont largement indépendants du cas d’usage et peuvent donc s’appliquer de façon étendue à toutes les sorties dans une langue donnée
  • En outre, grâce à une recherche de haute précision, si aucun document pertinent n’est trouvé, le système peut répondre de manière déterministe « Je ne sais pas »
• Les LLM peuvent aussi ne pas produire de sortie alors qu’une sortie est attendue
  • Cela peut arriver pour des raisons très diverses, depuis des problèmes simples comme une latence importante chez le fournisseur d’API jusqu’à des causes plus complexes comme un blocage de la sortie par un filtre de content moderation
• Il est donc important de journaliser de manière cohérente les entrées et les sorties — ou potentiellement l’absence de sortie — afin de faciliter le débogage et le monitoring

Les hallucinations restent un problème tenace

• Les problèmes de safety des contenus ou de PII reçoivent tellement d’attention qu’ils surviennent rarement, tandis que les incohérences factuelles persistent de manière tenace et sont plus difficiles à détecter
  • Elles sont plus fréquentes, avec un taux de base de 5 à 10 %, et d’après ce qui a été appris auprès des fournisseurs de LLM, il peut être difficile de descendre sous les 2 %, même pour des tâches simples comme le résumé
• Pour y remédier, on peut combiner le prompt engineering (en amont de la génération) et des garde-fous contre les incohérences factuelles (en aval de la génération)
  • Côté prompt engineering, des techniques comme le CoT peuvent aider à réduire les hallucinations en amenant le LLM à expliquer son raisonnement avant de produire la sortie finale
  • On peut ensuite appliquer des garde-fous contre les incohérences factuelles pour évaluer la fidélité d’un résumé et filtrer ou régénérer les hallucinations
• Dans certains cas, les hallucinations peuvent être détectées de manière déterministe
  • Lorsqu’on utilise les ressources d’une recherche RAG, si la sortie est structurée et identifie clairement quelles sont les ressources, il devrait être possible de vérifier manuellement qu’elle provient bien du contexte d’entrée

[Exploitation : enjeux quotidiens (Day-to-Day) et organisationnels ]

Exploitation 1. Données

• De même que la qualité des ingrédients détermine le goût d’un plat, la qualité des données d’entrée limite les performances d’un système de machine learning
• Les données de sortie sont aussi le seul moyen de savoir si le produit fonctionne
• Tous les auteurs passent chaque semaine plusieurs heures à examiner de près les entrées et les sorties afin de mieux comprendre la distribution des données (modes, cas limites, limites du modèle)

Vérifier le biais entre développement et production

• Dans les pipelines de machine learning traditionnels, une cause fréquente d’erreur est le biais entraînement-service
  • Il survient lorsque les données utilisées pour l’entraînement diffèrent de celles que le modèle rencontre en production
• Comme il est possible d’utiliser des LLM sans entraînement ni fine-tuning, il n’y a pas de jeu d’entraînement, mais un problème analogue apparaît : le biais entre données de développement et de production
  • En pratique, les données utilisées pour tester le système pendant le développement doivent refléter celles auxquelles il sera confronté en production
    • Sinon, la précision en production peut se dégrader
• Le biais développement-production pour les LLM peut être classé en deux types : le biais structurel et le biais lié au contenu
  • Le biais structurel inclut des problèmes comme des divergences de format, par exemple la différence entre un dictionnaire JSON avec des valeurs sous forme de listes et une liste JSON, une casse incohérente, ou des erreurs comme des fautes de frappe ou des fragments de phrase
    • Ces erreurs peuvent conduire à des performances imprévisibles du modèle, car différents LLM ont été entraînés sur certains formats de données et les prompts peuvent être très sensibles à des changements minimes
  • Le biais lié au contenu, ou biais « sémantique », désigne les différences de sens ou de contexte dans les données
• Comme en ML traditionnel, il est utile de mesurer périodiquement le biais entre les paires entrée-sortie des LLM
  • Des métriques simples, comme la longueur des entrées et des sorties ou certaines exigences de format (par ex. JSON ou XML), offrent un moyen simple de suivre les changements
• Pour une détection plus « avancée » du biais, on peut envisager de regrouper les embeddings des paires entrée-sortie afin de détecter un biais sémantique, par exemple des changements dans les sujets abordés par les utilisateurs, ce qui peut indiquer qu’ils explorent des zones auxquelles le modèle n’a pas encore été exposé
• Lorsqu’on teste des changements comme le prompt engineering, il faut vérifier que le jeu de données holdout est à jour et reflète les types d’interactions utilisateur les plus récents
  • Par exemple, si les fautes de frappe sont fréquentes dans les entrées de production, elles doivent aussi figurer dans les données holdout
• Au-delà d’une simple mesure numérique du biais, il est utile de mener une évaluation qualitative des sorties
  • Examiner régulièrement les sorties du modèle — une pratique familièrement appelée « vibe check » — permet de vérifier que les résultats correspondent aux attentes et restent pertinents pour les besoins des utilisateurs
• Il est également utile d’intégrer la non-déterminisme dans la vérification du biais
  • En exécutant plusieurs fois le pipeline pour chaque entrée du jeu de test et en analysant toutes les sorties, on augmente les chances de repérer des anomalies qui ne se produisent qu’occasionnellement

Vérifier chaque jour des échantillons d’entrées et de sorties LLM

• Les LLM sont dynamiques et en évolution constante
  • Malgré leurs impressionnantes capacités en zero-shot et des sorties souvent agréables, leurs modes d’échec restent très imprévisibles
• Pour les tâches sur mesure, il est essentiel de revoir régulièrement des échantillons de données afin de développer une compréhension intuitive des performances du LLM
  • Les paires entrée-sortie issues de la production sont le « réel, sur le terrain » (genchi genbutsu) des applications LLM, et rien ne peut les remplacer
• Des recherches récentes soulignent que plus les développeurs interagissent avec les données, plus leur perception d’une « bonne » ou d’une « mauvaise » sortie évolue (c’est-à-dire le biais de référence)
  • Les développeurs peuvent définir à l’avance certains critères pour évaluer les sorties du LLM, mais ces critères prédéfinis sont souvent incomplets
• Par exemple, au cours du développement, on peut mettre à jour les prompts pour augmenter la probabilité de bonnes réponses et diminuer celle de mauvaises réponses
  • Ce processus itératif d’évaluation, de réévaluation et de mise à jour des critères est nécessaire, car il est difficile de prédire le comportement d’un LLM ou les préférences humaines sans observer directement les sorties
• Pour gérer cela efficacement, il faut journaliser les entrées et sorties du LLM
  • Examiner chaque jour des échantillons de ces logs permet d’identifier rapidement de nouveaux schémas ou modes d’échec et de s’y adapter
  • Lorsqu’un nouveau problème est découvert, on peut immédiatement écrire une assertion ou une eval à son sujet
• De même, toute mise à jour de la définition des modes d’échec doit être reflétée dans les critères d’évaluation
  • Ces « vibe checks » sont des signaux de sorties incorrectes, et le code ainsi que les assertions permettent de les opérationnaliser
• Enfin, cette posture doit être socialisée
  • Par exemple, en ajoutant à la rotation d’astreinte la revue ou l’annotation des entrées et sorties

Exploitation 2. Travailler avec les modèles

• Utiliser des API de LLM signifie s’appuyer sur l’intelligence d’un petit nombre de fournisseurs
  • C’est un avantage, mais cette dépendance implique des arbitrages en matière de performances, de latence, de débit et de coût
• En outre, comme des modèles plus récents et meilleurs sont sortis presque tous les mois au cours de l’année écoulée, il faut être prêt à mettre le produit à jour lorsqu’on abandonne un ancien modèle pour migrer vers un nouveau
  • Cette section partage les enseignements tirés de l’usage d’une technologie qu’on ne contrôle pas totalement, c’est-à-dire une technologie dont on ne peut pas auto-héberger ni gérer soi-même les modèles
• Dans la plupart des cas d’usage réels, la sortie d’un LLM sera consommée par des applications en aval via une forme de format lisible par machine
  • Par exemple, ReChat, un CRM immobilier, a besoin de réponses structurées pour afficher des widgets côté frontend
  • De même, Boba, un outil de génération d’idées de stratégie produit, a besoin d’une sortie structurée avec des champs de titre, résumé, score de faisabilité et horizon temporel
  • Enfin, LinkedIn a expliqué comment contraindre un LLM à générer du YAML, utilisé pour décider quelle technique employer et fournir les paramètres permettant d’appeler cette technique
• Ce schéma applicatif est une version extrême de la loi de Postel
  • Il faut être libéral dans ce qu’on accepte (du langage naturel arbitraire) et conservateur dans ce qu’on envoie (des objets typés lisibles par machine)
  • C’est pourquoi on peut s’attendre à ce qu’il soit très durable
• Aujourd’hui, Instructor et Outlines sont les standards de fait pour obtenir des sorties structurées à partir des LLM
  • Si vous utilisez une API de LLM (par ex. Anthropic, OpenAI), utilisez Instructor ; si vous utilisez un modèle auto-hébergé (par ex. Huggingface), utilisez Outlines

La migration des prompts d’un modèle à l’autre est pénible

• Il arrive qu’un prompt soigneusement conçu fonctionne remarquablement bien avec un modèle, mais pas correctement avec un autre
  • Cela peut se produire non seulement lors d’un changement entre différents fournisseurs de modèles, mais aussi lors d’une mise à niveau entre différentes versions d’un même modèle
• Par exemple, Voiceflow a constaté qu’une migration de gpt-3.5-turbo-0301 vers gpt-3.5-turbo-1106 entraînait une baisse de performance de 10 % sur une tâche de classification d’intention
  • (Heureusement, ils disposaient d’évaluations !)
• De façon similaire, GoDaddy a observé, en passant à la version 1106, une tendance positive : l’écart de performance entre gpt-3.5-turbo et gpt-4 se réduisait
  • (Ou, si vous voyez le verre à moitié plein, vous pourriez être déçu que la nouvelle mise à niveau réduise l’avance de gpt-4)
• Par conséquent, si vous devez migrer des prompts d’un modèle à un autre, attendez-vous à ce que cela prenne plus de temps qu’un simple remplacement du point de terminaison API
  • Ne partez pas du principe qu’en branchant le même prompt, vous obtiendrez des résultats similaires ou meilleurs
• De plus, des évaluations fiables et automatisées aident à mesurer les performances de la tâche avant et après la migration, tout en réduisant l’effort nécessaire à la validation manuelle

Gestion et verrouillage des versions de modèles

• Dans tout pipeline de machine learning, « si vous changez quoi que ce soit, tout change »
  • Cela est particulièrement vrai lorsqu’on dépend de composants comme les grands modèles de langage (LLM), que nous n’entraînons pas nous-mêmes et qui peuvent être modifiés sans que nous le sachions
• Heureusement, de nombreux fournisseurs de modèles proposent une option permettant de « verrouiller » une version spécifique du modèle (par exemple gpt-4-turbo-1106)
  • Cela permet d’utiliser une version précise des poids du modèle afin qu’elle ne change pas
• Verrouiller la version du modèle en production permet d’éviter des changements imprévus dans son comportement
  • Cela peut aider à éviter les plaintes des clients liées à des problèmes comme des sorties trop verbeuses ou d’autres modes de défaillance inattendus pouvant apparaître lorsqu’un modèle est remplacé
• Envisagez également de maintenir un « shadow pipeline » qui reflète la configuration de production, mais utilise la version la plus récente du modèle
  • Cela permet de mener des expérimentations et des tests en toute sécurité avec les nouvelles releases
• Une fois la stabilité et la qualité des sorties validées sur ces nouveaux modèles, vous pouvez mettre à jour en toute confiance la version du modèle en environnement de production

Choisir le plus petit modèle capable d’accomplir la tâche

• Lorsqu’on travaille sur une nouvelle application, il est tentant d’utiliser le plus grand et le plus puissant des modèles disponibles
  • Mais une fois qu’il est confirmé que la tâche est techniquement réalisable, il vaut la peine d’expérimenter pour voir si un plus petit modèle peut produire des résultats comparables
• Les avantages des petits modèles sont une latence et un coût plus faibles
  • Ils sont peut-être moins puissants, mais des techniques comme le Chain-of-Thought, le prompting n-shot et l’apprentissage en contexte peuvent aider un petit modèle à dépasser ce que l’on attendrait normalement de ses capacités
• Au-delà des API de LLM, le fine-tuning pour une tâche spécifique peut aussi contribuer à améliorer les performances
• En résumé, un workflow soigneusement conçu autour de petits modèles peut être plus rapide et moins coûteux, tout en égalant, voire en dépassant, la qualité de sortie d’un unique grand modèle
  • Par exemple, ce tweet partage une anecdote expliquant comment Haiku + un prompt 10-shot surpasse Opus en zéro-shot et GPT-4
• À long terme, on peut s’attendre à voir davantage d’exemples de flow engineering avec de petits modèles offrant le meilleur équilibre entre qualité de sortie, latence et coût
• On peut prendre comme autre exemple l’humble tâche de classification
  • Des modèles légers comme DistilBERT (67 millions de paramètres) constituent une baseline étonnamment solide
  • DistilBART, avec 400 millions de paramètres, est une autre excellente option
    • Une fois fine-tuné sur des données open source, il peut identifier les hallucinations avec un ROC-AUC de 0,84, surpassant la plupart des LLM pour moins de 5 % de leur latence et de leur coût
• L’idée clé est qu’il ne faut pas négliger les petits modèles
  • Il est facile d’appliquer un modèle gigantesque à tous les problèmes, mais avec un peu de créativité et d’expérimentation, on peut souvent trouver des solutions plus efficaces

Ops 3. Produit

• Les nouvelles technologies ouvrent de nouvelles possibilités, mais les principes qui permettent de créer de grands produits restent intemporels
  • Ainsi, même si l’on résout un problème nouveau pour la première fois, il n’est pas nécessaire de réinventer la roue en matière de conception produit
• Il y a beaucoup à gagner à fonder le développement d’applications LLM sur des bases solides de product design
  • Cela permet d’apporter une réelle valeur aux personnes que nous servons

Impliquer le design dès le départ

• Avoir des designers pousse à comprendre et à réfléchir en profondeur à la manière de construire le produit et de le présenter aux utilisateurs
  • On a parfois tendance à réduire les designers à des personnes qui rendent les choses jolies
  • Pourtant, ils repensent non seulement l’interface utilisateur, mais aussi la manière d’améliorer l’expérience utilisateur, y compris en rompant avec les règles et paradigmes existants
• Les designers sont particulièrement doués pour reformuler les besoins des utilisateurs sous différentes formes
  • Certaines de ces formes sont plus faciles à résoudre que d’autres, ce qui peut offrir plus ou moins d’opportunités à une solution d’IA
• Comme pour beaucoup d’autres produits, concevoir un produit IA doit partir du travail à accomplir, et non de la technologie qui l’anime
• Il faut se concentrer sur des questions comme :
  • « Quelle tâche l’utilisateur demande-t-il à ce produit d’accomplir ? Est-ce le genre de tâche qu’un chatbot ferait bien ? Qu’en est-il de l’autocomplétion ? Ou peut-être autre chose ? »
• Il faut aussi réfléchir aux patterns de conception existants et à leur lien avec le travail à accomplir
  • Ce sont des atouts précieux que les designers apportent aux capacités de l’équipe

Concevoir une UX pour le human-in-the-loop

• Une façon d’obtenir des annotations de qualité consiste à intégrer du Human-in-the-Loop (HITL) dans l’expérience utilisateur (UX)
  • Permettre aux utilisateurs de fournir facilement des retours et des corrections améliore les sorties immédiates et permet de collecter des données utiles pour améliorer le modèle
• Imaginons une plateforme e-commerce où les utilisateurs téléversent et catégorisent des produits
  • Il existe plusieurs façons de concevoir l’UX
    1. L’utilisateur sélectionne manuellement la bonne catégorie de produit, et le LLM vérifie périodiquement les nouveaux produits puis corrige les erreurs de classification dans le backend
    2. L’utilisateur ne choisit aucune catégorie, et le LLM classe périodiquement les produits dans le backend, avec de potentielles erreurs
    3. Le LLM suggère une catégorie de produit en temps réel, et l’utilisateur peut la valider et la mettre à jour si nécessaire
• Les trois approches intègrent un LLM, mais offrent des UX très différentes
  • La première approche fait peser la charge initiale sur l’utilisateur, et le LLM joue un rôle de vérification a posteriori
  • La deuxième approche ne demande aucun effort à l’utilisateur, mais n’offre ni transparence ni contrôle
  • La troisième approche maintient un bon équilibre
    • En suggérant une catégorie à l’avance, le LLM réduit la charge cognitive de l’utilisateur, qui n’a pas besoin d’apprendre notre taxonomie pour classer le produit
    • En même temps, en permettant à l’utilisateur de revoir et modifier la suggestion, elle laisse fermement à l’utilisateur la décision finale sur la manière dont le produit est classé
  • En bonus, la troisième approche crée une boucle de feedback naturelle pour améliorer le modèle
    • Les bonnes suggestions sont acceptées (label positif) et les mauvaises sont mises à jour (label négatif puis positif)
• Ce schéma de suggestion, validation utilisateur et collecte de données est courant dans de nombreuses applications
  • Assistant de code : l’utilisateur peut accepter une suggestion (positif fort), l’accepter et l’ajuster (positif) ou l’ignorer (négatif)
  • Midjourney : l’utilisateur peut agrandir l’image et la télécharger (positif fort), modifier l’image (positif) ou générer un nouvel ensemble d’images (négatif)
  • Chatbot : l’utilisateur peut donner un pouce levé à une réponse (positif) ou un pouce baissé (négatif), ou choisir de régénérer la réponse si elle est vraiment mauvaise (négatif fort)
• Le feedback peut être explicite ou implicite
  • Le feedback explicite est l’information fournie par l’utilisateur en réponse à une sollicitation du produit
  • Le feedback implicite est l’information apprise à partir des interactions utilisateur, sans que l’utilisateur ait besoin de fournir intentionnellement un retour
• Les assistants de code et Midjourney sont des exemples de feedback implicite, tandis que les pouces levés et baissés sont du feedback explicite
  • Si l’UX est bien conçue, comme avec les assistants de code et Midjourney, il est possible de collecter beaucoup de feedback implicite pour améliorer le produit et le modèle

Prioriser sans pitié la hiérarchie des exigences

• Lorsqu’on réfléchit au déploiement d’une démo en production, il faut prendre en compte des exigences concernant les points suivants
  • Fiabilité : 99,9 % de disponibilité, respect des sorties structurées
  • Innocuité : ne pas générer de contenu offensant, NSFW ou autrement nuisible
  • Cohérence factuelle : rester fidèle au contexte fourni et ne pas déformer les faits
  • Utilité : être pertinent par rapport aux besoins et aux demandes de l’utilisateur
  • Scalabilité : SLA de latence, débit pris en charge
  • Coût : parce que le budget n’est pas illimité
  • Autres : sécurité, vie privée, équité, GDPR, DMA, etc.
• Si l’on essaie de traiter toutes ces exigences en même temps, on ne pourra rien lancer
  • Il faut donc les prioriser. Sans pitié.
• Cela signifie clarifier ce qui est non négociable, c’est-à-dire les éléments sur lesquels aucun compromis n’est possible parce que le produit risquerait sinon de ne pas fonctionner ou de ne pas être viable, comme la fiabilité ou l’innocuité
  • Il est important d’identifier le MVP (Minimum Lovable Product)
• Il faut accepter que la première version ne sera pas parfaite, puis lancer et itérer

Ajuster le niveau de tolérance au risque selon le cas d’usage

• Pour déterminer le niveau de revue à appliquer à un modèle de langage et à son application, il faut prendre en compte le cas d’usage et le public visé
  • Pour un chatbot orienté client qui fournit des conseils médicaux ou financiers, il faut une exigence très élevée en matière de sécurité et d’exactitude
    • Les erreurs ou sorties incorrectes peuvent causer un préjudice réel et faire perdre la confiance
  • En revanche, pour des applications moins critiques comme un système de recommandation, ou pour des applications internes comme la classification ou le résumé de contenu, des exigences excessivement strictes n’apportent pas beaucoup de valeur et ne font que ralentir les progrès
• Cela correspond au récent rapport d’a16z selon lequel beaucoup d’entreprises avancent plus vite sur les applications LLM internes que sur les applications externes
  • En expérimentant l’IA pour la productivité interne, les organisations peuvent commencer à capter de la valeur tout en apprenant à gérer les risques dans un environnement plus contrôlé
  • Elles peuvent ensuite étendre ces usages à des cas orientés client une fois la confiance acquise

Opérations 4. Équipe et rôles

• Aucun poste n’est facile à définir, mais rédiger une fiche de poste pour le travail dans ce nouveau domaine est encore plus difficile que pour d’autres
  • Je vais laisser de côté les diagrammes de Venn de postes qui se recoupent ou les suggestions de fiches de poste
  • En revanche, je vais reconnaître l’existence d’un nouveau rôle, celui d’ingénieur IA, et en parler
• Il est important de discuter aussi de la manière dont le reste de l’équipe et les responsabilités doivent être répartis

Se concentrer sur le processus, pas sur les outils

• Face à un nouveau paradigme comme les LLM, les ingénieurs logiciels ont tendance à privilégier les outils
  • Il en résulte qu’ils passent à côté des problèmes et des processus que ces outils étaient censés résoudre
  • Ce faisant, beaucoup d’ingénieurs introduisent une complexité accidentelle, ce qui nuit à la productivité de l’équipe à long terme
• Par exemple, cet article explique comment certains outils peuvent générer automatiquement des prompts pour les grands modèles de langage
  • Il soutient, à juste titre selon moi, que les ingénieurs qui utilisent ces outils sans d’abord comprendre la méthodologie ou le processus de résolution du problème finissent par accumuler une dette technique inutile
• Au-delà de la complexité accidentelle, les outils sont souvent insuffisamment spécifiés
  • Par exemple, l’industrie des outils d’évaluation de LLM est en plein essor, en proposant des « boîtes à outils d’évaluation de LLM » avec des évaluateurs génériques pour la nocivité, la concision, le ton, etc.
  • Je vois beaucoup d’équipes adopter ces outils sans réfléchir de manière critique aux modes de défaillance spécifiques à leur domaine
• À l’inverse, EvalGen met l’accent sur l’apprentissage du processus de création d’évaluations spécifiques à un domaine, en impliquant profondément les utilisateurs à chaque étape, comme la définition des critères, l’annotation des données et la vérification des évaluations
  • Le logiciel guide l’utilisateur à travers un workflow du type suivant
• Bonnes pratiques de création d’évaluations LLM guidées par EvalGen
  1. Définir des tests spécifiques au domaine, amorcés automatiquement à partir des prompts
     • Définis comme des assertions en code ou via LLM-as-a-Judge
  2. Importance d’aligner les tests sur le jugement humain afin que l’utilisateur puisse vérifier que les tests capturent bien les critères spécifiés
  3. Itérer sur les tests à mesure que le système change, par exemple les prompts
• EvalGen fournit aux développeurs un modèle mental du processus de construction d’évaluations, sans les enfermer dans un outil particulier
  • Je constate qu’une fois ce contexte fourni aux ingénieurs IA, ils décident souvent de choisir des outils plus simples ou de construire les leurs
• En dehors de l’écriture de prompts et de l’évaluation, il y a trop de composants liés aux LLM pour tous les lister ici
  • Mais il est important que les ingénieurs IA cherchent à comprendre le processus avant d’adopter des outils

Toujours expérimenter

• Les produits de ML sont étroitement liés à l’expérimentation
  • Cela signifie non seulement des tests A/B et des essais contrôlés randomisés, mais aussi des tentatives fréquentes consistant à modifier les plus petits composants possibles du système et à effectuer des évaluations hors ligne
  • Si tout le monde est si enthousiaste à propos de l’évaluation, ce n’est pas vraiment pour la fiabilité et la confiance, mais parce qu’elle rend l’expérimentation possible !
    • Plus l’évaluation est bonne, plus on peut itérer rapidement sur les expériences, et donc converger plus vite vers la meilleure version du système
• Comme les expériences sont devenues très peu coûteuses, il est courant d’essayer diverses approches pour résoudre un même problème
  • Les coûts élevés de collecte de données et d’entraînement des modèles ont été minimisés
    • Le prompt engineering coûte à peine plus que du temps humain
  • Il faut organiser l’équipe pour que chacun puisse apprendre les bases du prompt engineering
    • Cela encourage tout le monde à expérimenter et mène à une diversité d’idées dans toute l’organisation
• N’utilisez pas les expériences uniquement pour l’exploration, utilisez-les aussi pour l’exploitation !
  • Vous avez une version fonctionnelle pour une nouvelle tâche ?
    • Demandez à quelqu’un d’autre dans l’équipe d’envisager une approche différente
  • Essayez une autre méthode qui pourrait être plus rapide
  • Étudiez des techniques de prompt comme Chain-of-Thought ou Few-Shot afin d’améliorer la qualité
  • Veillez à ce que les outils ne freinent pas l’expérimentation
    • Si c’est le cas, achetez ce que vous pouvez reconstruire ou améliorer
• Pendant la planification du produit/projet, réservez explicitement du temps pour construire l’évaluation et mener plusieurs expériences
  • Réfléchissez à une spécification produit pour le produit d’ingénierie, et ajoutez-y des critères clairs pour l’évaluation
• Lors de l’élaboration de la roadmap, n’underestimez pas le temps nécessaire à l’expérimentation
  • Anticipez plusieurs cycles de développement et d’évaluation avant d’obtenir la validation pour la production

Donner à chacun les moyens d’utiliser les nouvelles technologies de l’IA

• À mesure que l’adoption de l’IA générative augmente, on veut que toute l’équipe, et pas seulement les spécialistes, ait le sentiment de comprendre et de pouvoir utiliser cette nouvelle technologie
  • Il n’existe pas de meilleure façon de développer une intuition sur le fonctionnement des LLM (par ex. latence, modes d’échec, UX)
  • Les LLM sont relativement accessibles
    • Il n’est pas nécessaire de savoir coder pour améliorer les performances d’un pipeline, et chacun peut contribuer via le prompt engineering et l’évaluation
• Une grande partie de cela relève de la formation
  • On peut commencer par les bases du prompt engineering, où des techniques comme le n-shot prompting et le CoT aident à orienter le modèle vers le type de sortie souhaité
• Les personnes qui ont ces connaissances peuvent aussi former les autres sur des aspects plus techniques, comme le fait que les LLM sont intrinsèquement autorégressifs
  • Autrement dit, les tokens d’entrée sont traités en parallèle, mais les tokens de sortie sont générés de manière séquentielle
  • Par conséquent, la latence dépend davantage de la longueur de la sortie que de celle de l’entrée
    • C’est un point clé à prendre en compte lors de la conception de l’UX et de la définition des attentes en matière de performances
• Il est aussi possible d’offrir des occasions pratiques d’expérimentation et d’exploration
  • Pourquoi pas un hackathon ?
    • Il peut sembler coûteux de laisser toute l’équipe passer quelques jours à bricoler des projets spéculatifs, mais les résultats peuvent vous surprendre
  • Une équipe a presque achevé en un an une roadmap sur trois ans grâce à un hackathon
    • Une autre équipe a abouti, via un hackathon, à une UX qui changeait de paradigme et qui n’était devenue possible que grâce aux LLM ; c’est désormais une priorité pour cette année et au-delà

Ne tombez pas dans le piège du « l’AI engineering, c’est tout ce qu’il faut »

• Quand un nouveau poste émerge, il existe au départ une tendance à surestimer les compétences associées à ce rôle
  • Cela conduit souvent à des corrections douloureuses à mesure que le périmètre réel de ces métiers devient plus clair
  • Les nouveaux venus dans ce domaine comme les responsables du recrutement peuvent faire des déclarations exagérées ou nourrir des attentes excessives
• Voici quelques exemples marquants des dix dernières années
  • Data scientist : « quelqu’un qui maîtrise mieux les statistiques que n’importe quel software engineer et mieux le software engineering que n’importe quel statisticien »
  • Machine learning engineer (MLE) : une perspective centrée sur le software engineering appliquée au machine learning
• Au départ, beaucoup supposaient que des data scientists suffisaient pour les projets fondés sur les données
  • Mais il est apparu clairement que les data scientists doivent collaborer avec des software engineers et des data engineers pour développer et déployer efficacement des produits data
• Ce malentendu réapparaît avec le nouveau rôle d’AI engineer, certaines équipes croyant que les AI engineers suffisent à eux seuls
  • En réalité, construire des produits de machine learning ou d’IA exige un large éventail de rôles spécialisés
• Nous avons conseillé plus de 12 entreprises sur des produits d’IA, et avons observé de manière constante qu’elles tombaient dans le piège de croire que « l’AI engineering est tout ce qu’il faut »
  • Résultat, leurs produits peinent souvent à dépasser le stade de la démo parce que des aspects essentiels à la construction du produit sont négligés
• Par exemple, l’évaluation et la mesure sont essentielles pour faire passer un produit au-delà d’un simple Vibe check
  • Les compétences nécessaires à une évaluation efficace correspondent en partie à des points forts qu’on retrouve traditionnellement chez les machine learning engineers
    • Une équipe composée uniquement d’AI engineers a de fortes chances de manquer de ces compétences
• Le co-auteur Hamel Husain explique l’importance de ces compétences dans des travaux récents sur la détection des biais dans les données et la conception d’évaluations spécifiques à un domaine
• Les types de rôles nécessaires et le moment où ils le deviennent dans le parcours de construction d’un produit d’IA
  1. Concentrez-vous d’abord sur la construction du produit
  • Cela peut inclure des AI engineers, mais ce n’est pas obligatoire
  • Les AI engineers sont utiles pour prototyper le produit (UX, plomberie, etc.) et itérer rapidement
  2. Ensuite, instrumentez le système et collectez des données afin de poser les bonnes bases
  • Selon le type et le volume de données, vous pourriez avoir besoin d’ingénieurs plateforme et/ou data
  • Il faut aussi disposer de systèmes permettant d’interroger et d’analyser ces données pour déboguer les problèmes
  3. Ensuite, optimisez le système d’IA
  • Cela n’implique pas nécessairement l’entraînement d’un modèle
  • Les fondamentaux incluent des étapes comme la conception de métriques, la construction de systèmes d’évaluation, l’exécution d’expériences, l’optimisation de la recherche RAG et le débogage de systèmes probabilistes
  • Les MLE sont très compétents dans ce domaine (même si les AI engineers peuvent bien sûr aussi l’apprendre)
  • Si les étapes précédentes n’ont pas été accomplies, recruter un MLE n’est généralement pas pertinent
• Au-delà de cela, il faut toujours des experts métier
  • Dans une petite entreprise, ce rôle devrait idéalement être assuré par l’équipe fondatrice ; dans une grande entreprise, il peut revenir au product manager
• Il est important de reconnaître la progression des rôles et leur bon timing
  • Recruter les mauvaises personnes au mauvais moment (par ex. embaucher un MLE trop tôt) ou construire dans le mauvais ordre fait perdre du temps et de l’argent, et provoque du turnover
• De plus, faire régulièrement appel à un MLE aux étapes 1 et 2 (sans pour autant l’embaucher à temps plein) peut aider l’entreprise à poser les bonnes bases

[Stratégie : comment ne pas se laisser distancer lorsqu’on construit avec des LLM]

• Pour réussir le développement d’un produit, il faut une planification réfléchie et une hiérarchisation des priorités, plutôt que de fabriquer des prototypes au hasard ou de suivre le dernier modèle ou la dernière tendance
• Lors du développement d’un produit d’IA, il faut examiner des arbitrages majeurs, comme le fait de développer soi-même ou d’acheter
• Voici un « playbook » pour le développement initial d’applications LLM

Stratégie 1 : pas de GPU avant le PMF

• Pour devenir un excellent produit, il faut être plus qu’un simple emballage minimal autour de l’API de quelqu’un d’autre
• Mais l’erreur inverse peut coûter encore plus cher
  • L’an dernier, d’énormes capitaux-risque ont été dépensés pour entraîner et personnaliser des modèles sans vision produit claire ni marché cible défini
  • Une entreprise a même levé jusqu’à 6 milliards de dollars en série A
• Cette section explique pourquoi commencer immédiatement à entraîner son propre modèle est une erreur, et examine le rôle que peut jouer l’auto-hébergement

Réentraîner (presque) depuis zéro dès le départ n’a aucun sens

• Pour la plupart des organisations, préentraîner un LLM à partir de zéro est irréaliste et hors de propos par rapport au développement produit
  • Développer et maintenir une infrastructure de machine learning demande beaucoup de ressources
    • Cela inclut la collecte de données, l’entraînement et l’évaluation du modèle, ainsi que le déploiement
  • Si l’on en est encore à valider l’adéquation produit-marché, cet effort détourne des ressources du développement du produit principal
  • Même avec des ressources de calcul, des données et des compétences techniques, un LLM préentraîné peut devenir obsolète en quelques mois
• Le cas de BloombergGPT
  • BloombergGPT, un LLM spécialisé pour les tâches financières, a été préentraîné sur 363B tokens
  • Un effort considérable de 9 employés à temps plein y a été consacré, dont 4 en AI engineering et 5 en produit ML et recherche
  • Malgré cela, en moins d’un an, il a été dépassé sur ces tâches par gpt-3.5-turbo et gpt-4
• Ces exemples suggèrent que, pour la plupart des applications réelles, préentraîner un LLM à partir de zéro n’est pas la meilleure utilisation des ressources
  • À la place, il vaut mieux pour les équipes fine-tuner le modèle open source le plus puissant disponible en fonction de leurs besoins spécifiques
• Il existe bien sûr des exceptions
  • Le modèle de code de Replit est un excellent exemple de préentraînement spécialisé dans la génération et la compréhension de code
  • Grâce au préentraînement, il a surpassé des modèles plus grands comme CodeLlama7b
  • Mais à mesure que des modèles plus puissants ont été lancés, il a fallu investir en continu pour conserver son utilité

Pas de fine-tuning tant que sa nécessité n’est pas confirmée

• Dans la plupart des organisations, le fine-tuning est motivé par le FOMO (Fear Of Missing Out, la peur de rater quelque chose) plutôt que par une réflexion stratégique
  • Les organisations investissent trop tôt dans le fine-tuning pour éviter les critiques de n’être qu’un « simple wrapper »
  • En réalité, le fine-tuning doit être considéré comme de l’artillerie lourde à déployer seulement après avoir accumulé de nombreux cas montrant que les autres approches ne suffisent pas
• Il y a un an, beaucoup d’équipes affichaient de grandes attentes vis-à-vis du fine-tuning, mais rares sont celles qui ont trouvé une adéquation produit-marché, et la plupart ont regretté leur décision
  • Si vous comptez faire du fine-tuning, il faut être prêt à le refaire à mesure que le modèle de base s’améliore
    • Voir ci-dessous « Le modèle n’est pas le produit » et « Construire du LLMOps »
• Dans quels cas le fine-tuning peut réellement être le bon choix
  • Lorsqu’il faut des données qui ne sont pas disponibles dans la plupart des jeux de données ouverts à l’échelle du web utilisés pour entraîner les modèles existants
  • Lorsqu’un MVP a déjà été construit et montre que les modèles existants ne suffisent pas
  • Mais prudence : si le concepteur du modèle ne peut pas facilement obtenir de bonnes données d’entraînement, où allez-vous les trouver ?
• Une application fondée sur des LLM n’est pas un projet de foire scientifique
  • L’investissement doit être proportionnel à sa contribution aux objectifs stratégiques et à la différenciation concurrentielle

Commencer avec une API d’inférence, sans avoir peur de l’auto-hébergement

• Utiliser une API LLM permet à une startup d’adopter et d’intégrer facilement des capacités de modélisation du langage sans devoir entraîner son propre modèle dès le départ
  • Des fournisseurs comme Anthropic et OpenAI proposent des API génériques qui permettent d’ajouter de l’intelligence à un produit avec seulement quelques lignes de code
  • Utiliser ces services permet de réduire l’effort et de se concentrer sur la création de valeur pour les clients, afin de valider des idées et d’itérer plus vite vers l’adéquation produit-marché
• Mais comme pour les bases de données, un service managé ne convient pas à tous les cas d’usage à mesure que l’échelle et les exigences augmentent
  • En pratique, l’auto-hébergement peut être le seul moyen d’utiliser un modèle sans envoyer des données confidentielles ou personnelles hors du réseau, comme l’exigent les secteurs réglementés tels que la santé et la finance, ou certaines obligations contractuelles et exigences de confidentialité
• L’auto-hébergement permet aussi de contourner les contraintes imposées par les fournisseurs d’inférence, comme les limites de débit, l’arrêt de certains modèles ou les restrictions d’usage
  • Il donne un contrôle total sur le modèle, ce qui facilite la construction de systèmes différenciés et de haute qualité
• Enfin, l’auto-hébergement, en particulier avec fine-tuning, peut réduire les coûts à grande échelle
  • Par exemple, Buzzfeed a partagé un cas où le fine-tuning d’un LLM open source a permis de réduire les coûts de 80 %

Stratégie 2 : itérer vers quelque chose de meilleur

• Pour conserver un avantage concurrentiel sur le long terme, il faut réfléchir à ce qui peut différencier le produit au-delà du modèle
• La vitesse d’exécution est importante, mais elle ne doit pas être le seul avantage

Le modèle n’est pas le produit, c’est le système qui l’entoure qui est le produit

• Pour les équipes qui ne construisent pas elles-mêmes de modèle, le rythme rapide de l’innovation est une bénédiction
  • Parce qu’elles peuvent migrer vers les derniers modèles pour créer de meilleurs produits, en recherchant des améliorations sur la taille de contexte, les capacités de raisonnement ou encore le rapport qualité-prix
  • Ces progrès sont passionnants au point d’en devenir prévisibles
  • Pris ensemble, cela signifie que le modèle est probablement le composant le moins durable du système
• Il faut plutôt concentrer ses efforts sur les éléments capables de fournir une valeur durable
  • Evals : pour mesurer de façon fiable la performance sur les tâches, quel que soit le modèle
  • Guardrails : pour empêcher les sorties non désirées, indépendamment du modèle
  • Caching : pour réduire la latence et les coûts en évitant complètement le modèle
  • Data flywheel : pour alimenter l’amélioration itérative de tout ce qui précède
  • Ces composants créent un fossé défensif de qualité produit plus épais que les capacités brutes du modèle
• Cela ne veut cependant pas dire que construire dans la couche applicative est sans risque
  • Si OpenAI ou un autre fournisseur de modèles veut proposer un logiciel d’entreprise viable, ne coupez pas là où ils vont eux-mêmes couper au ciseau
• Par exemple, certaines équipes ont investi dans des outils sur mesure pour valider les sorties structurées de modèles propriétaires
  • Un investissement minimal ici est important, mais investir en profondeur n’est pas un bon usage du temps
  • OpenAI doit garantir qu’une demande de function calling produit un appel de fonction valide, parce que tous les clients le veulent
  • Appliquez ici un « report stratégique » : construisez uniquement ce qui est absolument nécessaire, puis attendez l’extension des capacités du fournisseur

Commencer petit pour gagner la confiance

• Construire un produit qui veut être tout pour tout le monde est la recette de la banalité
• Pour créer un produit convaincant, une entreprise doit se spécialiser dans la construction d’une expérience suffisamment sticky pour faire revenir les utilisateurs
• Prenons un système RAG générique qui vise à répondre à toutes les questions posées par les utilisateurs
  • Le manque de spécialisation signifie que le système ne peut ni prioriser les informations récentes, ni parser des formats spécifiques à un domaine, ni comprendre les nuances d’une tâche donnée
  • Résultat : les utilisateurs se retrouvent avec une expérience superficielle et peu fiable, qui ne répond pas à leurs besoins et les pousse à partir
• Pour y remédier, il faut se concentrer sur un domaine et des cas d’usage spécifiques
  • Il faut réduire le périmètre en ajoutant de la profondeur plutôt que de la largeur
  • Cela permet de créer des outils spécialisés qui résonnent auprès des utilisateurs
• La spécialisation permet aussi de communiquer honnêtement sur les capacités et les limites du système
  • Expliquer de manière transparente ce que le système peut et ne peut pas faire montre une forme de lucidité, aide les utilisateurs à comprendre où il peut apporter le plus de valeur, et construit ainsi la confiance et l’assurance dans les résultats

Construire du LLMOps, mais pour les bonnes raisons : itération rapide

• Le DevOps ne consiste pas fondamentalement à rendre les workflows reproductibles, ni à shift left, ni à donner du pouvoir à des équipes « two-pizza ». Encore moins à écrire des fichiers YAML
• Le DevOps consiste à raccourcir la boucle de feedback entre le travail et ses résultats, afin que les améliorations s’accumulent au lieu des erreurs
  • Ses racines remontent, via le mouvement lean startup, au lean manufacturing et au système de production Toyota, avec un accent sur le single-minute die exchange et le kaizen
• Le MLOps a appliqué la forme du DevOps au ML
  • Il existe des suites d’outils tout-en-un pour des expériences reproductibles et pour donner aux concepteurs de modèles la capacité de déployer. Avec beaucoup de fichiers YAML aussi
• Mais en tant qu’industrie, le MLOps n’a pas adopté la fonction du DevOps. Il n’a pas réduit l’écart de feedback entre les modèles et l’inférence ainsi que les interactions en production
• Heureusement, le domaine du LLMOps s’est éloigné des problèmes triviaux comme la gestion des prompts pour se tourner vers l’amélioration continue, qui mène aux problèmes difficiles freinant l’itération : le monitoring en production et l’évaluation
• Il existe déjà des arènes conversationnelles pour des évaluations neutres et crowdsourcées des modèles de chat et de code. C’est la boucle externe d’une amélioration collective et itérative
  • Des outils comme LangSmith, Log10, LangFuse, W&B Weave et HoneyHive promettent non seulement de collecter et d’organiser les données sur les résultats des systèmes en production, mais aussi de s’intégrer profondément au développement pour aider à améliorer ces systèmes. Adoptez ces outils ou construisez-les vous-même

Ne construisez pas des capacités LLM que vous pouvez acheter

• La plupart des entreprises qui réussissent ne sont pas des entreprises LLM. En même temps, la plupart des entreprises ont des opportunités d’amélioration avec les LLM
• Ces deux constats induisent souvent les dirigeants en erreur, les poussant à refondre à la hâte leurs systèmes avec des LLM, à augmenter les coûts, à faire baisser la qualité, puis à lancer des fonctionnalités « IA » artificielles et vaniteuses. Vous obtenez alors l’icône scintillante que tout le monde redoute aujourd’hui
• Il existe une meilleure approche : se concentrer sur des applications LLM qui s’alignent réellement sur les objectifs produit et renforcent les opérations cœur de métier
• Considérons quelques fausses bonnes idées qui font perdre du temps aux équipes
  • Construire une fonctionnalité text-to-SQL sur mesure pour l’entreprise
  • Construire un chatbot capable de dialoguer avec des documents
  • Intégrer la base de connaissances de l’entreprise à un chatbot de support client
• Même si les points ci-dessus sont le hello world des applications LLM, il n’est pas logique qu’une entreprise produit les construise elle-même
  • Ce sont des problèmes génériques communs à de nombreuses entreprises, avec un grand écart entre des démos prometteuses et des composants fiables, et ils relèvent du terrain habituel des éditeurs de logiciels
  • Investir de précieuses ressources de R&D dans des problèmes génériques que la promotion actuelle de Y Combinator tente de résoudre à grande échelle est un gaspillage
• Si cela ressemble à un conseil business banal, c’est parce qu’au milieu de l’excitation de la vague de hype actuelle, il est facile de prendre quelque chose estampillé « LLM » pour une différenciation de pointe et de passer à côté d’applications déjà banalisées

Mettez l’IA dans la boucle, et l’humain au centre

• Les applications actuelles basées sur des LLM sont fragiles. Elles nécessitent énormément de garde-fous et d’ingénierie défensive, tout en restant difficiles à prédire. En même temps, lorsqu’elles sont strictement bien cadrées, elles peuvent être extrêmement utiles. Cela signifie que les LLM sont d’excellents outils pour accélérer les workflows des utilisateurs
• On peut être tenté d’imaginer des applications basées sur des LLM qui remplacent entièrement un workflow ou se substituent à une fonction métier, mais aujourd’hui le paradigme le plus efficace est celui du centaure humain-machine (Centaur chess)
  • Associer un humain compétent à des capacités LLM ajustées pour son usage rapide peut fortement améliorer à la fois la productivité et la satisfaction dans l’exécution du travail
  • GitHub CoPilot, l’une des applications emblématiques des LLM, a démontré la puissance de ce type de workflow
    • « Dans l’ensemble, les développeurs ont déclaré que coder avec GitHub Copilot et GitHub Copilot Chat était plus facile, avec moins d’erreurs, plus lisible, plus réutilisable, plus concis, plus facile à maintenir et plus résilient. » - Mario Rodriguez, GitHub
• Les personnes qui travaillent depuis longtemps dans le ML peuvent vite en arriver à l’idée de « human-in-the-loop », mais n’allez pas si vite
  • Le machine learning HITL est un paradigme fondé sur des experts humains qui veillent à ce que les modèles de ML se comportent comme prévu
  • Ce qui est proposé ici est lié, mais plus nuancé. Les systèmes basés sur des LLM ne devraient pas être aujourd’hui le moteur principal de la plupart des workflows ; ils devraient simplement être une ressource
• Mettre l’humain au centre et se demander comment les LLM peuvent soutenir le workflow a des implications très différentes pour les décisions produit et design
  • Au final, vous créerez un produit différent de celui des concurrents qui cherchent à sous-traiter trop vite toute responsabilité aux LLM : un meilleur produit, plus utile et moins risqué

Stratégie 3. Commencer par le prompting, les evals et la collecte de données

• La section précédente a concentré beaucoup de techniques et de conseils. C’est beaucoup à assimiler. Considérons l’ensemble minimal de recommandations utiles
  • Si une équipe veut construire un produit LLM, par où doit-elle commencer ?
• Depuis un an, on a vu suffisamment d’applications LLM réussir pour être convaincu qu’elles suivent une trajectoire cohérente. Cette section présente ce playbook fondamental de « prise en main »
• L’idée centrale est de commencer simplement et d’ajouter de la complexité selon les besoins
  • Rule of Thumb : chaque niveau de sophistication demande généralement au moins un ordre de grandeur d’effort de plus que l’étape précédente. Gardez cela en tête...

Le prompt engineering est la priorité n°1

• Commencez par le prompt engineering
  • Utilisez toutes les techniques discutées plus haut dans la section tactique
  • Le chain-of-thought, les exemples n-shot et les entrées/sorties structurées sont presque toujours de bonnes idées
  • Prototypez avec le modèle le plus performant avant d’essayer d’extraire le maximum d’un modèle plus faible
• N’envisagez le fine-tuning que si le prompt engineering ne permet pas d’atteindre le niveau de performance souhaité
  • Cela arrivera plus souvent si vous avez des exigences non fonctionnelles (par exemple confidentialité des données, contrôle total, coût) qui excluent l’usage de modèles propriétaires et imposent l’auto-hébergement
  • Veillez à ce que ces mêmes exigences de confidentialité n’interdisent pas ensuite l’utilisation des données utilisateur pour le fine-tuning

Construire des évaluations et lancer le data flywheel

• Même les équipes qui débutent ont besoin d’evals. Sinon, il est impossible de savoir si le prompt engineering suffit ou si un modèle fine-tuné est prêt à remplacer le modèle de base
• Des évaluations efficaces sont spécifiques à la tâche et reflètent le cas d’usage visé
  • Le premier niveau d’évaluation que nous recommandons est le test unitaire
  • Ces assertions simples aident à détecter des modes de défaillance connus ou hypothétiques et à prendre les premières décisions de conception
  • Référez-vous aussi à d’autres évaluations spécifiques à certaines tâches pour la classification, le résumé, etc.
• Les tests unitaires et les évaluations basées sur le modèle sont utiles, mais ne remplacent pas la nécessité d’une évaluation humaine
  • Faites en sorte que des personnes utilisent le modèle/produit et fournissent un retour
  • Cela remplit un double objectif : mesurer les performances réelles et le taux de défauts, tout en collectant des données annotées de haute qualité utilisables plus tard pour le fine-tuning du modèle
  • Cela crée une boucle de feedback positive, ou data flywheel, qui produit des effets composés avec le temps
    • Évaluation humaine pour mesurer la performance du modèle ou trouver des défauts
    • Utilisation des données annotées pour fine-tuner le modèle ou mettre à jour les prompts
    • Répéter
• Par exemple, lors de l’audit des défauts de résumés générés par des LLM, vous pouvez attribuer à chaque phrase des labels de feedback granulaires identifiant une incohérence factuelle, une absence de pertinence ou un mauvais style
  • Vous pouvez ensuite utiliser ces annotations d’incohérence factuelle pour entraîner un classificateur d’hallucinations, ou les annotations de pertinence pour entraîner un modèle de récompense de pertinence
• LinkedIn a partagé des cas de réussite utilisant des évaluateurs basés sur des modèles pour estimer les hallucinations, les violations de l’IA responsable, la cohérence, etc.
• En créant des actifs dont la valeur augmente avec le temps, vous transformez la construction d’evals d’un simple coût opérationnel en investissement stratégique, tout en construisant au passage un data flywheel

Stratégie 4. La tendance de fond de la cognition à bas coût (The high-level trend of low-cost cognition)

• En 1971, les chercheurs du Xerox PARC ont prédit le monde actuel des ordinateurs personnels connectés en réseau
  • Ils ont contribué à faire naître cet avenir en jouant un rôle central dans l’invention des technologies qui l’ont rendu possible (Ethernet, rendu graphique, souris, fenêtres, etc.)
• Ils ont aussi mené un exercice simple
  • Ils ont examiné des applications très utiles (par ex. les écrans vidéo), mais pas encore viables économiquement (la RAM suffisante pour piloter un écran vidéo coûtait alors des milliers de dollars)
  • Ils ont ensuite observé l’évolution historique des prix de cette technologie (dans un esprit proche de la loi de Moore) et prédit à quel moment elle deviendrait économiquement viable
• On peut faire le même exercice avec la technologie des LLM, même si c’est moins net que le nombre de transistors par dollar
  • Choisir un benchmark populaire utilisé depuis longtemps (par ex. le dataset Massively-Multitask Language Understanding) et une approche d’entrée cohérente (5-shot prompting)
  • Puis comparer, au fil du temps, le coût d’exécution de modèles de langage atteignant différents niveaux de performance sur ce benchmark
• À coût constant, les capacités augmentent rapidement. À niveau de capacité constant, les coûts diminuent rapidement
  • Depuis le lancement du modèle davinci d’OpenAI via API il y a 4 ans, le coût pour exécuter à l’échelle d’un million de tokens (environ 100 copies de ce document) un modèle offrant des performances comparables sur cette tâche est passé de 20 $ à moins de 10 centimes. La demi-vie n’est que de 6 mois
  • De même, en mai 2024, le coût pour exécuter LLaMA 3 8B de Meta, via un fournisseur d’API ou en propre, n’est plus que de 20 centimes par million de tokens, avec des performances comparables à text-davinci-003 d’OpenAI, le modèle à l’origine de ChatGPT
  • Ce modèle coûtait encore environ 20 $ par million de tokens à sa sortie, fin novembre 2023. Un écart d’un ordre de grandeur en seulement 18 mois, soit la même période que le simple doublement prédit par la loi de Moore
• Considérons maintenant des applications LLM très utiles (comme l’animation de personnages de jeu vidéo génératifs à la Park et al), mais pas encore viables économiquement (leur coût est estimé à 625 $ de l’heure)
  • Depuis la publication de cet article en août 2023, le coût a déjà baissé d’environ un ordre de grandeur, à 62,50 $ de l’heure
  • Neuf mois plus tard, on peut s’attendre à ce qu’il tombe à 6,25 $ de l’heure
• Pendant ce temps, lorsque Pac-Man est sorti en 1980, 1 $ d’aujourd’hui permettait d’acheter des crédits pour jouer quelques minutes ou quelques dizaines de minutes. Appelons cela 6 parties par heure, soit 6 $ de l’heure
  • Ce calcul de coin de table suggère que des expériences de jeu enrichies par les LLM et réellement attrayantes pourraient devenir économiquement viables vers 2025
• Ces tendances sont nouvelles et n’ont que quelques années. Mais il y a peu de raisons de penser que ce processus va ralentir dans les prochaines années
  • Même si l’on exploite les fruits les plus faciles à cueillir en matière d’algorithmes et de datasets, comme le scaling au-delà du « ratio Chinchilla » d’environ 20 tokens par paramètre, des innovations et investissements plus profonds, dans les data centers comme dans la pile silicium, combleront l’écart
• Et c’est probablement le fait stratégique le plus important
  • Les démos de laboratoire ou articles de recherche totalement irréalisables aujourd’hui deviendront des fonctionnalités premium dans quelques années, puis des commodités peu après
  • Il faut construire ses systèmes et ses organisations en gardant cela à l’esprit

[Les démos qui passent de 0 à 1 suffisent désormais. Il faut maintenant construire des produits qui passent de 1 à N]

• Construire une démo LLM est vraiment amusant. Avec quelques lignes de code, une base de données vectorielle et un prompt soigneusement rédigé, on crée de la « magie »
• Au cours de l’année écoulée, cette magie a été comparée à Internet, au smartphone, voire à l’imprimerie
• Malheureusement, comme le sait quiconque a déjà travaillé au lancement d’un vrai logiciel, il y a un immense fossé entre une démo qui fonctionne dans un environnement contrôlé et un produit qui fonctionne de manière fiable à grande échelle
• Il existe de nombreux problèmes qu’il est facile d’imaginer et de démontrer, mais extrêmement difficiles à transformer en produit
  • Prenons l’exemple de la conduite autonome : il est facile de montrer une voiture parcourant un pâté de maisons en autonomie, mais il faut 10 ans pour en faire un produit — Andrej Karpathy
• Prenons justement l’exemple des voitures autonomes
  • La première voiture pilotée par réseau de neurones est apparue en 1988
  • 25 ans plus tard, Andrej Karpathy a effectué sa première course de démonstration chez Waymo
  • Dix ans après, l’entreprise a obtenu l’autorisation d’exploiter des véhicules sans conducteur
  • Entre le prototype et le produit commercial, il a fallu 35 ans d’ingénierie rigoureuse, de tests, d’itérations et de navigation réglementaire
• À travers l’industrie et le monde académique, nous avons observé les hauts et les bas de l’année écoulée : l’an 1 des applications LLM (Year 1 of N for LLM applications)
  • Nous espérons que les leçons apprises, depuis les tactiques comme l’évaluation, le prompt engineering et les guardrails, jusqu’aux perspectives stratégiques comme les capacités opérationnelles, la constitution des équipes et le choix de ce qu’il faut développer en interne, seront utiles pour l’an 2 et au-delà
  • Nous avons hâte de faire progresser ensemble cette nouvelle technologie passionnante

[inthelife]

Le contenu est si bon que j’en ai fait une mind map pour le garder et le revoir souvent ^^;

https://drive.google.com/file/d/…

[hheungsu]

C’est un texte vraiment excellent !! Du début à la fin, il y a énormément de passages utiles à méditer. Merci d’avoir traduit et partagé un article aussi précieux !!

[nutella]

À ce stade, c’est vraiment très utile.

[komanabi]

Megastudy, c'est fini, l'oméga-3 arrive !!!

[ssifood]

Maintenant, c'en est fini de Skynet, MegaStudy arrive.

[my0075425]

C'en est fini de l'humanité, Skynet arrive !!

[zihado]

La carrière de l’auteur du billet original était elle aussi intéressante.
https://fr.news.hada.io/topic?id=1626

[eungook]

Waouh... c’est incroyablement stimulant... merci pour le partage.

[humblebee]

C’est un excellent article dans lequel les idées et l’expérience paraissent très vivantes ! Je pense qu’il sera d’une grande aide pour mon équipe et moi. Je l’ai lu avec beaucoup de plaisir. Merci ☺️