L'essor des opérations rapides : s'attaquer aux coûts cachés de l'IA liés aux mauvaises entrées et au gonflement du contexte

Cet article fait partie du numéro spécial de VentureBeat, « Le coût réel de l'IA : performances, efficacité et retour sur investissement à grande échelle ». Pour en savoir plus, consultez ce numéro spécial.

Les fournisseurs de modèles continuent de déployer des modèles de langage de grande taille (LLM) de plus en plus sophistiqués avec des fenêtres de contexte plus longues et des capacités de raisonnement améliorées.

Cela permet aux modèles de traiter et de « penser » davantage, mais cela augmente également la capacité de calcul : plus un modèle absorbe et produit, plus il dépense d’énergie et plus les coûts sont élevés.

Ajoutez à cela tous les ajustements nécessaires à l'incitation (il faut parfois plusieurs essais pour arriver au résultat escompté, et parfois la question en question n'a tout simplement pas besoin d'un modèle capable de penser comme un doctorat) et les dépenses de calcul peuvent devenir incontrôlables.

Cela donne naissance aux opérations rapides, une toute nouvelle discipline à l’aube de l’ère de l’IA .

« L'ingénierie des prompts s'apparente à l'écriture, à la création proprement dite, tandis que les opérations des prompts s'apparentent à l'édition, où l'on fait évoluer le contenu », a expliqué Crawford Del Prete, président d'IDC , à VentureBeat. « Le contenu est vivant, il évolue, et il faut s'assurer de l'affiner au fil du temps. »

L'utilisation et le coût du calcul sont deux concepts « liés mais distincts » dans le contexte des LLM, explique David Emerson, scientifique appliqué au Vector Institute . En général, le prix payé par les utilisateurs varie en fonction du nombre de jetons d'entrée (ce que l'utilisateur demande) et du nombre de jetons de sortie (ce que le modèle fournit). Cependant, ces prix ne sont pas modifiés pour les actions en coulisses telles que les méta-invites, les instructions de pilotage ou la génération augmentée de récupération (RAG).

Bien que des contextes plus longs permettent aux modèles de traiter beaucoup plus de texte simultanément, cela se traduit directement par un nombre significativement plus élevé de FLOPS (mesure de la puissance de calcul), a-t-il expliqué. Certains aspects des modèles de transformateurs évoluent même de manière quadratique avec la longueur des entrées s'ils ne sont pas bien gérés. Des réponses inutilement longues peuvent également ralentir le traitement et nécessiter des calculs et des coûts supplémentaires pour développer et maintenir des algorithmes permettant de post-traiter les réponses afin d'obtenir la réponse attendue par les utilisateurs.

En règle générale, les environnements contextuels plus longs incitent les fournisseurs à fournir délibérément des réponses verbeuses, a déclaré Emerson. Par exemple, de nombreux modèles de raisonnement plus lourds ( o3 ou o1 d'OpenAI , par exemple) fournissent souvent de longues réponses même à des questions simples, ce qui entraîne des coûts de calcul importants.

Voici un exemple :

Entrée : Répondez au problème mathématique suivant. Si j’ai deux pommes et que j’en achète quatre autres au magasin après en avoir mangé une, combien de pommes ai-je ?

Résultat : Si j'en mange 1, il ne m'en reste plus qu'une. J'aurais 5 pommes si j'en achète 4 de plus.

Le modèle a non seulement généré plus de jetons que nécessaire, mais a également enterré sa réponse. Un ingénieur peut alors être amené à concevoir un moyen programmatique d'extraire la réponse finale ou à poser des questions complémentaires telles que « Quelle est votre réponse finale ? », ce qui engendre des coûts d'API encore plus élevés.

Alternativement, l'invite pourrait être repensée pour guider le modèle vers une réponse immédiate. Par exemple :

Entrée : Répondez au problème mathématique suivant. Si j'ai deux pommes et que j'en achète quatre autres au magasin après en avoir mangé une, combien de pommes ai-je ? Commencez votre réponse par « La réponse est… »

Ou:

Entrée : Répondez au problème mathématique suivant. Si j'ai deux pommes et que j'en achète quatre autres au magasin après en avoir mangé une, combien de pommes ai-je ? Mettez votre réponse finale en gras. .

« La façon dont la question est posée peut réduire l'effort ou le coût pour obtenir la réponse souhaitée », a déclaré Emerson. Il a également souligné que des techniques comme l'invite à réponse rapide (fournir quelques exemples de ce que l'utilisateur recherche) peuvent contribuer à accélérer les résultats.

L’un des dangers est de ne pas savoir quand utiliser des techniques sophistiquées comme l’incitation à la chaîne de pensée (CoT) (générer des réponses par étapes) ou l’auto-affinage, qui encouragent directement les modèles à produire de nombreux jetons ou à passer par plusieurs itérations lors de la génération de réponses, a souligné Emerson.

Toutes les requêtes ne nécessitent pas un modèle à analyser et réanalyser avant de fournir une réponse, a-t-il souligné ; elles pourraient parfaitement répondre correctement lorsqu'on leur demande de répondre directement. De plus, des configurations d'API d'invite incorrectes (comme OpenAI o3, qui nécessite un effort de raisonnement important) entraîneront des coûts plus élevés alors qu'une requête moins exigeante et moins coûteuse suffirait.

« Avec des contextes plus longs, les utilisateurs peuvent également être tentés d'adopter une approche du type « tout sauf l'évier de cuisine », qui consiste à insérer un maximum de texte dans le contexte d'un modèle dans l'espoir que cela l'aidera à exécuter une tâche avec plus de précision », a déclaré Emerson. « Si davantage de contexte peut aider les modèles à exécuter des tâches, ce n'est pas toujours l'approche la plus efficace. »

Ce n'est un secret pour personne que l'infrastructure optimisée pour l'IA peut être difficile à trouver de nos jours ; Del Prete d'IDC a souligné que les entreprises doivent être en mesure de minimiser la durée d'inactivité du GPU et de remplir davantage de requêtes dans les cycles d'inactivité entre les demandes GPU.

« Comment tirer le meilleur parti de ces ressources extrêmement précieuses ? », a-t-il remarqué. « Je dois optimiser l'utilisation de mon système, car je ne peux tout simplement pas me permettre d'augmenter la capacité de traitement. »

Les opérations rapides peuvent contribuer grandement à relever ce défi, car elles gèrent en fin de compte le cycle de vie de l'invite. Si l'ingénierie des invites porte sur la qualité de l'invite, les opérations rapides sont le lieu où l'on répète l'invite, a expliqué Del Prete.

« C'est davantage une question d'orchestration », a-t-il déclaré. « Je vois cela comme une sélection de questions et une gestion rigoureuse de la façon dont on interagit avec l'IA pour s'assurer d'en tirer le meilleur parti. »

Les modèles ont tendance à se fatiguer, tournant en boucle et la qualité des résultats se dégradant, a-t-il expliqué. Les opérateurs de prompts aident à gérer, mesurer, surveiller et ajuster les prompts. « Je pense que, dans trois ou quatre ans, ce sera une discipline à part entière. Ce sera une compétence. »

Bien qu'il s'agisse d'un domaine encore émergent, les premiers fournisseurs incluent QueryPal, Promptable, Rebuff et TrueLens. À mesure que les opérations de prompting évoluent, ces plateformes continueront d'évoluer, de s'améliorer et de fournir un retour d'information en temps réel afin d'offrir aux utilisateurs davantage de possibilités d'ajustement des prompts au fil du temps, a souligné Dep Prete.

À terme, prédit-il, les agents seront capables de peaufiner, de rédiger et de structurer leurs messages de manière autonome. « Le niveau d'automatisation augmentera, le niveau d'interaction humaine diminuera, et les agents pourront gérer les messages de manière plus autonome. »

Tant que les opérations rapides ne seront pas pleinement réalisées, il n'existera pas de réponse parfaite. Selon Emerson, certaines des plus grosses erreurs que l'on commet :

• Manque de précision quant au problème à résoudre. Cela inclut la manière dont l'utilisateur souhaite que le modèle fournisse sa réponse, les éléments à prendre en compte lors de la réponse, les contraintes à prendre en compte et d'autres facteurs. « Dans de nombreux contextes, les modèles ont besoin d'un contexte suffisant pour fournir une réponse conforme aux attentes des utilisateurs », a déclaré Emerson.
• Ne pas prendre en compte les possibilités de simplification d'un problème pour restreindre la portée de la réponse. La réponse doit-elle se situer dans une fourchette donnée (de 0 à 100) ? La réponse doit-elle être formulée sous forme de problème à choix multiples plutôt que de question ouverte ? L'utilisateur peut-il fournir de bons exemples pour contextualiser la requête ? Le problème peut-il être divisé en étapes pour des requêtes distinctes et plus simples ?
• Ne pas exploiter la structure. Les LLM sont très doués pour la reconnaissance des formes et beaucoup peuvent comprendre le code. Bien que l'utilisation de puces, de listes détaillées ou d'indicateurs en gras (****) puisse paraître un peu encombrée à l'œil nu, Emerson a noté que ces légendes peuvent être utiles pour un LLM. Demander des sorties structurées (comme JSON ou Markdown) peut également être utile lorsque les utilisateurs souhaitent traiter les réponses automatiquement.

Selon Emerson, de nombreux autres facteurs sont à prendre en compte pour maintenir un pipeline de production, conformément aux meilleures pratiques d'ingénierie. Parmi ceux-ci, on peut citer :

• S’assurer que le débit du pipeline reste constant ;
• Suivi des performances des invites au fil du temps (potentiellement par rapport à un ensemble de validation) ;
• Mise en place de tests et de détection d'alerte précoce pour identifier les problèmes de pipeline.

Les utilisateurs peuvent également tirer parti d'outils conçus pour faciliter le processus d'invite. Par exemple, l'outil open source DSPy peut configurer et optimiser automatiquement les invites pour les tâches en aval, à partir de quelques exemples étiquetés. Bien que cet exemple soit assez sophistiqué, de nombreuses autres offres (dont certaines intégrées à des outils comme ChatGPT, Google et d'autres) peuvent faciliter la conception d'invites.

Et finalement, Emerson a déclaré : « Je pense que l’une des choses les plus simples que les utilisateurs peuvent faire est d’essayer de se tenir au courant des approches d’incitation efficaces, des développements de modèles et des nouvelles façons de configurer et d’interagir avec les modèles. »