Dans le premier article de cette série, nous avons abordé la complexité et les ressources colossales inhérentes au développement de grands modèles de langage (LLM) de fondation, rendant leur création hors de portée de la plupart des entreprises. Nous allons à présent identifier les options présentées aux entreprises pour exploiter ces LLM dans leurs propres datacenters privés.
Un datacenter IA modeste équipé de 128 processeurs graphiques peut coûter des millions de dollars en déploiement. Pour maîtriser les coûts, il est donc impératif d’investir dans l’efficacité. Pour Juniper, les investissements dans l’IA doivent principalement s’articuler autour des applications, des coûts et de la fameuse question : développer ou acheter ? Dans cet article, nous allons nous intéresser plus précisément à la manière dont l’application doit influencer le modèle de consommation de l’IA dans le cadre d’un investissement d’entreprise.
La complexité des applications
Avant d’investir dans l’IA, vous devez clairement identifier les objectifs et les attentes de votre application d’IA. Quel sera votre cas d’usage ? Un outil générique pour améliorer l’expérience client, par exemple un assistant de support optimisé par l’IA, un analyseur de document ou un assistant de documentation technique ? Une application d’IA plus personnalisée et différenciée, spécifique à votre secteur d’activité ou à votre organisation ? Plus la solution sera personnalisée, plus son développement sera compliqué. Pour votre application ou LLM, il sera donc primordial de choisir un modèle de consommation adapté.
McKinsey Consulting identifie trois approches pour le déploiement d’une application d’IA : les Makers, les Takers et les Shapers.
Les « Makers » : les gros poissons dans la mare
Les « Makers », autrement dit les créateurs, désignent les rares entreprises au monde qui disposent des moyens financiers et de l’expertise nécessaires pour développer leurs propres LLM de fondation entraînés à partir des données d’Internet. Il s’agit d’entreprises telles que Google (Gemma, Gemini), Meta (Llama), OpenAI (GPT), Anthropic (Claude), Mistral (Large, Nemo) et Amazon (Titan). La plupart des entreprises ne sont pas capables de développer un LLM : ce sont donc des Takers ou des Shapers.
Les « Takers » : ceux qui tirent directement parti des applications d’IA existantes
Les entreprises qui cherchent à déployer des services moins complexes, comme un chatbot client générique, ou à connecter un système de traitement automatique du langage naturel (NLP) à une base de données existante n’ont pas besoin de personnaliser un LLM disponible dans le commerce. Elles peuvent se contenter d’une application d’IA existante qui repose sur un LLM préentraîné, sous licence ou open source, et déployer ce modèle à des fins d’inférence.
Aujourd’hui, ces applications répondent à des attentes basiques dans la plupart des entreprises. Malgré un faible potentiel de différentiation, leur simplicité permet de rationaliser le développement et d’éviter les dépenses inutiles lorsqu’elles sont bien exécutées. Le référentiel de bibliothèques d’IA Hugging Face permet aux entreprises d’accéder à plus de 400 000 LLM préentraînés, 150 000 applications d’IA et 100 000 datasets. Il existe donc pour les entreprises d’infinies possibilités de déployer l’IA rapidement et efficacement.
Les « Shapers » : ceux qui s’approprient les LLM
Les LLM ou applications prêtes à l’emploi peuvent vite atteindre leurs limites pour les entreprises qui cherchent à se différencier de leurs concurrents ou à personnaliser leurs workflows. Un Shaper prend un LLM préentraîné et le façonne (« shape ») en l’ajustant à l’aide de ses propres datasets propriétaires afin de produire un LLM capable de donner à n’importe quelle question des réponses extrêmement spécifiques et précises. Ce modèle profite à toutes sortes d’applications, notamment :
- L’automatisation des workflows, où le LLM est entraîné à exécuter une fonction spécifique afin de simplifier certaines tâches ou de les rendre moins fastidieuses
- L’assistance pilotée par l’IA, pour comparer des politiques internes, des réglementations ou des amendements juridiques dans le but d’identifier les différences notables
- Les copilotes entraînés sur des systèmes d’exploitation, des CLI et des documentations spécifiques afin de simplifier le développement de code ou la recherche de documents
Les avantages de l’inférence basée sur la RAG
Comme nous l’avons vu dans le premier article de cette série, les systèmes d’inférence fournissent aux utilisateurs finaux et aux appareils des applications d’IA entraînées. Selon la taille du modèle, l’inférence peut être déployée soit sur un seul serveur ou processeur graphique, soit dans le cadre d’un déploiement à plusieurs nœuds où l’application est répartie entre plusieurs serveurs pour augmenter le degré d’échelle et de performances.
La Retrieval-Augmented Generation, ou RAG, est une innovation relativement récente qui offre aux entreprises une technique intéressante pour personnaliser le développement et/ou le déploiement de modèles d’IA. La RAG enrichit les LLM préentraînés en fournissant des données supplémentaires à partir d’une source de données externe. La RAG vectorise les requêtes des utilisateurs et recherche les vecteurs les plus similaires dans une source de données externe. Une fois le résultat obtenu, les fragments de texte ou de données (les « chunks ») les plus pertinents sont transmis au LLM, accompagnés de l’invite d’origine, à des fins d’inférence. Ces données locales pertinentes complètent la compréhension du LLM pour produire des réponses plus avancées. Sans avoir à réentraîner un LLM, la RAG est capable de donner des réponses spécifiques et précises à une requête d’un client ou d’un appareil.
Située au croisement des modèles Taker et Shaper, la RAG donne aux entreprises les moyens d’utiliser des LLM prêts à l’emploi sans avoir à déployer de lourds efforts d’adaptation. En revanche, comme elle impose d’accéder, en plus de la requête d’origine, à une source de données supplémentaire (généralement une base de données vectorielle), cette approche nécessite des connexions réseau extrêmement performantes entre le front-end, la source de données externe et le LLM, avec une latence globale aussi réduite que possible.
Après avoir défini leur modèle de consommation des LLM, les entreprises doivent ensuite choisir leur approche de déploiement pour leurs modèles d’entraînement et d’inférence. Dans notre prochain article, nous nous pencherons sur le grand dilemme : « acheter ou développer ? », et essaierons d’y répondre en analysant les coûts.
