GenAI : comment choisir une solution « prête à l’emploi »

Choisir les bonnes options parmi les nombreux LLM

C’est un fait : les modèles ne font pas tous la même chose. Et leurs capacités évoluent. Certains voient leurs connaissances mises à jour et/ou en acquièrent des spécifiques, deviennent multimodaux, se connectent à d’autres services, etc.

L’offre de Google illustre la variété des options aujourd’hui disponibles dans l’univers de la GenAI. Sans compter les modèles tiers accessibles sur son offre Vertex AI, le groupe américain propose :

– Gemini (analyse de texte et d’images ; production de texte)
– PaLM (traitement du langage, y compris représentation vectorielle)
– Codey (génération, explication et saisie semi-automatique de code)
– Imagen (production, modification, sous-titrage et vectorisation d’images)
– Gecko (représentations vectorielles)
– MedLM (adapté à des tâches médicales)

L’API OpenAI ouvre des possibilités similaires : génération de texte avec Babbage et Davinci, traitement du code avec Codex, analyse et création d’images respectivement avec GPT-4 et DALL-E, reconnaissance vocale avec Whisper…

Le catalogue de modèles tiers a son importance dans une offre GenAI. Illustration chez AWS. La branche cloud d’Amazon ne commercialise qu’une famille de modèles maison (Titan). Mais elle donne accès, par l’intermédiaire du service Bedrock, à des solutions telles que Claude (Anthropic), Command (Cohere) et Stable Diffusion (Stability AI).

Certains fournisseurs font le choix de partenariats plus spécifiques. Il en est ainsi d’OVHcloud pour son service AI Deploy. L’entreprise y donne accès à des modèles « prêts à l’emploi » de Lettria (analyse de sentiment et d’émotions, reconnaissance d’entités) et de Voxist (reconnaissance vocale).

Choisir un LLM adapté aux profils des utilisateurs

Bedrock, AI Deploy, l’API OpenAI… Même si chacune de ces solutions inclut un « terrain de jeu » sous forme d’interface graphique pour tester des modèles, les développeurs en sont le public cible.

Les professions de la data science font l’objet d’offres plus spécifiques, à l’image de SageMaker chez AWS et Azure ML chez Microsoft. Plus « transversales », elles permettent de gérer le cycle de vie des modèles (MLOps).

La GenAI a aussi commencé à infuser au sein des progiciels. SAP a ouvert la voie à Joule, un assistant numérique qu’il entend intégrer de manière transversale à son offre. Salesforce avance sous les bannières Einstein GPT, Slack GPT et Tableau GPT. Snowflake a choisi la marque Cortex pour proposer une gamme de services managés (optimisation de requêtes, recherche universelle…) fondés sur des LLM. Google et Microsoft ont également accroché le wagon, entre autres pour leurs suites bureautiques respectives.

On n’oubliera pas les chatbots « génériques » à la ChatGPT, accessibles sur abonnement. Des systèmes d’extensions commencent à apparaître pour les ouvrir à des informations et à des services tiers.

Attention à la sensibilité des données traitées

Sur certaines offres, il existe un risque d’exploitation des données par le fournisseur. ChatGPT Plus en est emblématique. Bien qu’il s’agisse d’une formule payante (22 € TTC/mois), OpenAI s’est réservé le droit, par défaut, d’effectuer des collectes. Google est dans le même cas avec la version web de Gemini, même s’il est possible de refuser les collectes a posteriori (opt-out).

La sensibilité des données traitées peut aussi entraîner des exigences de localisation géographique des workloads. Avec de nombreuses API publiques, c’est la loterie sur ce point. Et chez les CSP, on est encore loin d’une couverture mondiale. Illustration pour Amazon Bedrock : l’ajustement de modèles, la création d’agents et la constitution de bases de connaissances ne peut pour le moment se faire que sur la plaque États-Unis.

Même limite géographique chez Oracle pour les clusters d’inférence dédiés à l’exécution des modèles. La disponibilité dépend parfois des modèles : sur Azure OpenAI, la version Instruct de GPT-3.5 Turbo n’est accessible que dans deux régions cloud (USA est, Suède centre).

Sur ce volet, OVHcloud a un avantage en qualité de fournisseur français : son service AI Deploy est disponible dans les datacenters de Gravelines.

Comment gérer l’infrastructure ?

AI Deploy d’OVHCloud est emblématique des offres qui permettent de déployer des modèles « prêts à l’emploi », mais qui impliquent une gestion d’infrastructure.

C’est à l’utilisateur de gérer le compute : il attribue une à dix instances dont il peut régler la configuration (cœurs CPU et GPU, RAM, bande passante) et éventuellement les stratégies de scaling.

Plus globalement, dès lors qu’on passe sur des offres intégrées aux écosystèmes IaaS, il faut s’attendre à devoir – ou tout au moins pouvoir – gérer de l’infra. En particulier lorsqu’on souhaite personnaliser des modèles. Les exécuter nécessite de provisionner des capacités dédiées sur Azure OpenAI comme sur Bedrock. On les achète généralement sous forme d’engagement mensuel renouvelable et on les alloue aux ressources sur lesquelles on effectue des déploiements. Chez Oracle, le modèle économique n’est pas le même, mais le principe l’est : il faut lancer des clusters d’inférence spécifiques.

En fonction des techniques de personnalisation, on peut être amené à paramétrer des bases de données. Notamment en créant des magasins de vecteurs pour le RAG (génération augmentée par récupération, que Google Cloud nomme ancrage).

Alimenter le LLM avec mes données (ou pas)

Exploiter des modèles est une chose. Les personnaliser en est une autre. Dans ce domaine, les techniques varient… comme la terminologie employée pour les décrire.

La méthode du « réglage fin », aussi appelée « ajustement », consiste à surentraîner un modèle à partir de données annotées. Google la recommande notamment pour la classification, l’analyse de sentiment et la synthèse de contenu simple. Microsoft la conseille pour qui souhaite que le modèle génère du contenu avec un style, un ton ou un format spécifique. Ou encore si les informations nécessaires sont trop longues ou complexes pour entrer dans la fenêtre d’invite.

Autre option : l’apprentissage automatique par renforcement avec feedback humain (RLHF, reinforcement learning with human feedback). On est ici sur un apprentissage continu, approprié aux systèmes de questions-réponses comme à la création de contenu.

Le procédé de distillation repose sur une autre approche : un modèle « enseignant » forme un modèle « élève » moins volumineux. On obtient ainsi une version moins lourde d’un modèle sans dégrader fondamentalement ses capacités.

L’ancrage, ou génération augmentée par récupération (RAG, retrieval-augmented generation), n’implique par d’entraînement. Il consiste à connecter les modèles à des sources de données pour enrichir (contextualiser) les invites.

Ces sources peuvent être des fichiers ajoutés « à la volée ». Pour plus d’efficacité, on constituera des bases de connaissances indexées, sur lesquelles on pourra appliquer de la recherche sémantique. On vectorisera éventuellement le contenu.

Des modèles dits d’incorporation (embedding) remplissent cette dernière fonction. Ils transforment les données en vecteurs. Les outils de recherche peuvent alors évaluer leur proximité. Méthode commune : mesurer le cosinus de l’angle entre deux vecteurs. Cela permet de rapprocher des documents qui, projetés dans l’espace multidimensionnel, seraient éloignés par la distance euclidienne en raison de leur taille.

Si vous souhaitez ajouter des connaissances au modèle hors de son domaine de compétences, commencez par le RAG, résume Microsoft. L’ajustement peut réduire les coûts en raccourcissant les invites, mais il implique un coût initial de surentraînement et des frais d’hébergement du modèle qui en résulte.

Attention aux contraintes liées à l’ajustement et à la compatibilité des modèles. Sur le premier point, illustration chez Oracle : un dataset maximum, réparti à 90/10 entre données d’entraînement et de validation. Sur le second, illustration chez Amazon : on ne peut ajuster que les modèles de Cohere, une partie des modèles Titan et quelques modèles LLaMa. Ceux d’Anthropic sont pour le moment les seuls à prendre en charge le RAG.

Comment connecter ma solution GenAI à mon SI cloud ?

Les fournisseurs cloud ont monté des passerelles entre leurs offres de GenAI « sur étagère » et le reste de leur catalogue. Chez Google Cloud, on mentionne, entre autres, le déclenchement d’appels à partir d’événements (Cloud Functions, Cloud Run), le monitoring (Cloud Logging, BigQuery), la planification de tâches (Cloud Scheduler) et l’exploitation des règles de gouvernance et de résidence des données.

Des passerelles, il y en a aussi sur le volet sécurité. Chez Microsoft, Entra ID (ex-Azure Active Directory) fournit des identités managées et plusieurs rôles spécifiques à Azure OpenAI. Chez OVHcloud, sur l’offre AI Deploy, on peut restreindre les accès grâce à des tags. Chaque application a par ailleurs son dashboard Grafana natif.

Chez AWS, Bedrock se nourrit par défaut de l’OpenSearch maison pour les magasins de vecteurs. Il supporte d’autres options du catalogue, dont Aurora pour PostgreSQL et Redis. Ses KMS peuvent être mis à contribution pour héberger des clés de chiffrement gérées par le client. Elles protégeront aussi bien les tâches de personnalisation de modèles que les sessions des agents (modèles autonomes).

Des connexions entre services d’IA existent aussi. On mentionnera, chez Microsoft, la possibilité d’utiliser Azure AI Vision en parallèle de GPT-4 Turbo pour le traitement d’images afin :

– D’identifier et localiser les objets importants
– De reconnaître des caractères
– De traiter des vidéos (échantillonnées en un ensemble d’images)

Bien comprendre le modèle économique et les quotas

Les quotas sont un fait généralisé dans les offres de GenAI « sur étagère ». Le terme se rapporte pour l’essentiel à la quantité d’infrastructure consommable sur une période donnée. On peut parfois relever les plafonds sur demande, comme chez OVHcloud, où AI Deploy impose une limite de 12 CPU par application (ou, côté GPU, 4 V100S ou 2 A100).

Microsoft attribue ses quotas – en tokens/minute – par région et par modèle. On peut les répartir entre déploiements, en réglant le nombre de tokens par paliers de 1000. Une option « dynamique », en préversion, permet de tirer parti, de manière opportune, des capacités supplémentaires. Idéal pour le traitement en lot, la vectorisation ou l’analyse hors ligne de journaux.

Chez Amazon aussi, chaque modèle a ses quotas (en tokens/minute ainsi qu’en requêtes/minutes)… non ajustables. Un autre type de limite se présente avec les capacités réservées : les modèles qu’on y exploite doivent reposer sur le même modèle de fondation.

Il y a aussi des limites inhérentes aux modèles et aux services associés : quantité et taille des images dans l’invite, nombre de tours de conversation, taille de chunking pour les bases de connaissances, longueur maximale de texte à vectoriser… La liste est longue. Elle s’assortit de limites globales allant du nombre de modèles ajustés à la taille des jeux de données.

Côté tarification, le modèle à la consommation prévaut. Les prix diffèrent tant entre modèles qu’entre types de données traitées et générées. Le cas d’Anthropic l’illustre. D’une part, il en coûte dix fois plus cher d’utiliser Claude que sa version « légère » Claude Instant. De l’autre, les jetons en sortie coûtent trois fois plus cher que ceux en entrée.

Autre exemple, sur l’API OpenAI : pour l’analyse d’images, on ne paye pas la même chose selon la résolution. Pour Whisper (reconnaissance vocale), l’unité de facturation est la seconde. Pour l’API Assistants, la session (interpréteur de code) et le Go/jour (récupération).

L’ajustement de modèles a sa propre tarification. L’ancrage implique des coûts de transfert et de stockage. L’usage des « terrains de jeu » n’est pas ailleurs pas systématiquement gratuit, malgré leur fonction expérimentale. L’usage de service cognitifs connexes (cf. cas d’Azure AI Vision avec GPT-4 Turbo) a également un coût.

Des outils intégrés permettent d’estimer le nombre de jetons pour une invite. Ils ne couvrent toutefois pas nécessairement tous les modèles.

Sur les offres par abonnement, outre l’absence fréquente de SLA, on aura noté que les plafonds de ressources exploitables peuvent évoluer en fonction de la demande.

Choisir une solution de GenAI ou de Machine Learning ?

Envie d’une tarification plus prévisible ? Il est peut-être possible de faire sans GenAI. Ou en tout cas sans modèles classés dans cette catégorie, au profit de ce qu’on appelle communément « services cognitifs ». C’est-à-dire des solutions ML plus traditionnelles, spécialisées sur une tâche, à la capacité de personnalisation limitée et exigeant peu d’expertise.

Chez Amazon, elles s’appellent Polly (synthèse vocale), Rekognition (reconnaissance faciale), Translate (traduction)… Chez Microsoft, AI Search (recherche), Content Safety (détection de contenu indésirable), Speech (reconnaissance vocale)…

Microsoft reconnaît, dans sa documentation, que le résultat de la synthèse vocale Azure OpenAI est « le même » qu’avec Speech. Ce dernier a même des avantages. Dont la prise en charge du traitement par lots, d’un échantillonnage de qualité supérieure, d’un sous-ensemble de SSML (langage de balisage de synthèse vocale) et d’un accès CLI + SDK en plus de l’API REST.
Certains rôles Entra ID englobent d’ailleurs tous les « services cognitifs ».

Illustration © faithie – Adobe Stock