De nos jours, la majorité de nos clients sont enthousiasmés par les grands modèles de langage (LLM) et réfléchissent à la manière dont l'IA générative pourrait transformer leur entreprise. Cependant, introduire de telles solutions et modèles dans les opérations habituelles n’est pas une tâche facile. Dans cet article, nous expliquons comment opérationnaliser des applications d'IA générative à l'aide des principes MLOps menant aux opérations de modèle de base (FMOps). De plus, nous approfondissons le cas d'utilisation de l'IA générative le plus courant des applications texte-texte et des opérations LLM (LLMOps), un sous-ensemble de FMOps. La figure suivante illustre les sujets que nous discutons.
Plus précisément, nous présentons brièvement les principes du MLOps et nous concentrons sur les principaux différenciateurs par rapport aux FMOps et aux LLMOps concernant les processus, les personnes, la sélection et l'évaluation des modèles, la confidentialité des données et le déploiement du modèle. Cela s'applique aux clients qui les utilisent directement, créent des modèles de base à partir de zéro ou les affinent. Notre approche s’applique aussi bien aux modèles open source qu’aux modèles propriétaires.
Résumé de l’opérationnalisation du ML
Tel que défini dans le post Feuille de route de la fondation MLOps pour les entreprises avec Amazon SageMaker, ML et opérations (MLOps) est la combinaison de personnes, de processus et de technologies pour produire efficacement des solutions d'apprentissage automatique (ML). Pour y parvenir, une combinaison d’équipes et de personnages doivent collaborer, comme l’illustre la figure suivante.
Ces équipes sont les suivantes :
- Équipe d'analyse avancée (lac de données et maillage de données) – Les ingénieurs de données sont chargés de préparer et d'ingérer des données provenant de plusieurs sources, de créer des pipelines ETL (extraire, transformer et charger) pour organiser et cataloguer les données, et de préparer les données historiques nécessaires pour les cas d'utilisation de ML. Ces propriétaires de données s’efforcent de fournir un accès à leurs données à plusieurs unités commerciales ou équipes.
- Équipe de science des données – Les data scientists doivent se concentrer sur la création du meilleur modèle basé sur des indicateurs de performance clés (KPI) prédéfinis fonctionnant dans des notebooks. Une fois la phase de recherche terminée, les data scientists doivent collaborer avec les ingénieurs ML pour créer des automatisations pour la création (pipelines ML) et le déploiement de modèles en production à l'aide de pipelines CI/CD.
- Équipe commerciale – Un propriétaire de produit est chargé de définir l’analyse de rentabilisation, les exigences et les KPI à utiliser pour évaluer les performances du modèle. Les consommateurs de ML sont d'autres parties prenantes de l'entreprise qui utilisent les résultats d'inférence (prédictions) pour prendre des décisions.
- Équipe plateforme – Les architectes sont responsables de l’architecture cloud globale de l’entreprise et de la façon dont tous les différents services sont connectés entre eux. Les experts en sécurité examinent l'architecture en fonction des politiques et des besoins de sécurité de l'entreprise. Les ingénieurs MLOps sont chargés de fournir un environnement sécurisé aux data scientists et aux ingénieurs ML afin de produire les cas d'utilisation ML. Plus précisément, ils sont responsables de la normalisation des pipelines CI/CD, des rôles d'utilisateur et de service, de la création de conteneurs, de la consommation de modèles, des tests et de la méthodologie de déploiement en fonction des exigences commerciales et de sécurité.
- Équipe Risques et Conformité – Pour les environnements plus restrictifs, les auditeurs sont chargés d'évaluer les données, le code et les artefacts de modèle et de s'assurer que l'entreprise est conforme aux réglementations, telles que la confidentialité des données.
Notez que plusieurs personas peuvent être couverts par la même personne en fonction de l'évolutivité et de la maturité MLOps de l'entreprise.
Ces personas ont besoin d'environnements dédiés pour exécuter les différents processus, comme illustré dans la figure suivante.
Les environnements sont les suivants :
- Administration de la plateforme – L'environnement d'administration de la plateforme est l'endroit auquel l'équipe de la plateforme a accès pour créer des comptes AWS et relier les bons utilisateurs et données.
- Données – La couche de données, souvent appelée lac de données ou maillage de données, est l'environnement que les ingénieurs ou propriétaires de données et les parties prenantes de l'entreprise utilisent pour préparer, interagir et visualiser avec les données.
- Expérimentation – Les data scientists utilisent un bac à sable ou un environnement d'expérimentation pour tester de nouvelles bibliothèques et techniques de ML afin de prouver que leur preuve de concept peut résoudre les problèmes commerciaux
- Construction de modèles, tests de modèles, déploiement de modèles – L'environnement de création, de test et de déploiement de modèles constitue la couche de MLOps, où les scientifiques des données et les ingénieurs ML collaborent pour automatiser et déplacer la recherche vers la production.
- Gouvernance du ML – La dernière pièce du puzzle est l'environnement de gouvernance ML, où tous les artefacts de modèle et de code sont stockés, examinés et audités par les personnages correspondants.
Le diagramme suivant illustre l'architecture de référence, qui a déjà été abordée dans Feuille de route de la fondation MLOps pour les entreprises avec Amazon SageMaker.
Chaque unité commerciale dispose de son propre ensemble de comptes de développement (formation et création automatisées de modèles), de préproduction (tests automatiques) et de production (déploiement et service de modèles) pour produire des cas d'utilisation de ML, qui récupèrent des données à partir d'un lac de données ou de données centralisé ou décentralisé. maille, respectivement. Tous les modèles produits et l'automatisation du code sont stockés dans un compte d'outillage centralisé en utilisant la capacité d'un registre de modèles. Le code d'infrastructure de tous ces comptes est versionné dans un compte de service partagé (compte de gouvernance analytique avancée) que l'équipe de la plateforme peut extraire, modéliser, maintenir et réutiliser pour l'intégration à la plateforme MLOps de chaque nouvelle équipe.
Définitions de l'IA générative et différences par rapport aux MLOps
Dans le ML classique, la combinaison précédente de personnes, de processus et de technologies peut vous aider à produire vos cas d'utilisation de ML. Cependant, dans l’IA générative, la nature des cas d’utilisation nécessite soit une extension de ces capacités, soit de nouvelles capacités. L'une de ces nouvelles notions est le modèle de fondation (FM). Ils sont appelés ainsi car ils peuvent être utilisés pour créer un large éventail d’autres modèles d’IA, comme l’illustre la figure suivante.
FM a été formé sur la base de téraoctets de données et dispose de centaines de milliards de paramètres pour pouvoir prédire la prochaine meilleure réponse sur la base de trois catégories principales de cas d'utilisation de l'IA générative :
- Texte à texte – Les FM (LLM) ont été formés sur la base de données non étiquetées (telles que du texte libre) et sont capables de prédire le prochain meilleur mot ou séquence de mots (paragraphes ou longs essais). Les principaux cas d'utilisation concernent les chatbots de type humain, la synthèse ou d'autres créations de contenu telles que le code de programmation.
- Texte à image – Données étiquetées, telles que des paires de , a été utilisé pour former des FM, capables de prédire la meilleure combinaison de pixels. Des exemples de cas d'utilisation sont la génération de designs de vêtements ou des images personnalisées imaginaires.
- Texte vers audio ou vidéo – Les données étiquetées et non étiquetées peuvent être utilisées pour l’entraînement FM. L’un des principaux exemples d’utilisation de l’IA générative est la composition musicale.
Pour produire ces cas d'utilisation de l'IA générative, nous devons emprunter et étendre le domaine MLOps pour inclure les éléments suivants :
- Opérations FM (FMOps) – Cela peut produire des solutions d’IA générative, y compris tout type de cas d’utilisation
- Opérations LLM (LLMOps) – Il s'agit d'un sous-ensemble de FMOps axé sur la production de solutions basées sur LLM, telles que le texte à texte
La figure suivante illustre le chevauchement de ces cas d’utilisation.
Par rapport au ML et au MLOps classiques, les FMOps et les LLMOps se différencient en fonction de quatre catégories principales que nous couvrons dans les sections suivantes : les personnes et les processus, la sélection et l'adaptation du FM, l'évaluation et la surveillance du FM, la confidentialité des données et le déploiement du modèle, ainsi que les besoins technologiques. Nous aborderons la surveillance dans un article séparé.
Parcours d’opérationnalisation par type d’utilisateur d’IA générative
Pour simplifier la description des processus, nous devons catégoriser les principaux types d’utilisateurs de l’IA générative, comme le montre la figure suivante.
Les types d'utilisateurs sont les suivants :
- Fournisseurs – Les utilisateurs qui créent des FM à partir de zéro et les fournissent sous forme de produit à d'autres utilisateurs (régleurs et consommateurs). Ils disposent d'une expertise approfondie de bout en bout en matière de ML et de traitement du langage naturel (NLP), de compétences en science des données, ainsi que d'énormes équipes d'étiquetage et d'édition de données.
- Affineurs – Les utilisateurs qui recyclent (affinent) les FM des fournisseurs pour répondre aux exigences personnalisées. Ils orchestrent le déploiement du modèle en tant que service destiné aux consommateurs. Ces utilisateurs ont besoin d’une solide expertise de bout en bout en matière de ML et de science des données, ainsi que de connaissances en matière de déploiement et d’inférence de modèles. De solides connaissances du domaine pour le réglage, y compris l'ingénierie rapide, sont également requises.
- Les consommateurs – Les utilisateurs qui interagissent avec les services d’IA générative des fournisseurs ou des peaufineurs par l’intermédiaire d’une invite textuelle ou d’une interface visuelle pour effectuer les actions souhaitées. Aucune expertise en ML n'est requise mais, principalement, des développeurs d'applications ou des utilisateurs finaux comprenant les capacités du service. Seule une ingénierie rapide est nécessaire pour obtenir de meilleurs résultats.
Selon la définition et l'expertise ML requise, MLOps est principalement requis pour les fournisseurs et les ajusteurs, tandis que les consommateurs peuvent utiliser les principes de production d'applications, tels que DevOps et AppDev pour créer les applications d'IA génératives. En outre, nous avons observé une évolution parmi les types d'utilisateurs, où les fournisseurs pourraient devenir des peaufineurs pour prendre en charge des cas d'utilisation basés sur un secteur vertical spécifique (comme le secteur financier) ou les consommateurs pourraient devenir des peaufineurs pour obtenir des résultats plus précis. Mais observons les principaux processus par type d'utilisateur.
Le parcours des consommateurs
La figure suivante illustre le parcours du consommateur.
Comme mentionné précédemment, les consommateurs doivent sélectionner, tester et utiliser un FM, en interagissant avec lui en fournissant des entrées spécifiques, également appelées instructions. Les invites, dans le contexte de la programmation informatique et de l'IA, font référence à l'entrée donnée à un modèle ou à un système pour générer une réponse. Cela peut prendre la forme d'un texte, d'une commande ou d'une question, que le système utilise pour traiter et générer une sortie. Les résultats générés par le FM peuvent ensuite être utilisés par les utilisateurs finaux, qui devraient également être en mesure d'évaluer ces résultats pour améliorer les réponses futures du modèle.
Au-delà de ces processus fondamentaux, nous avons remarqué que les consommateurs expriment le désir de peaufiner un modèle en exploitant les fonctionnalités offertes par les peaufineurs. Prenons, par exemple, un site Web qui génère des images. Ici, les utilisateurs finaux peuvent créer des comptes privés, télécharger des photos personnelles, puis générer du contenu lié à ces images (par exemple, générer une image représentant l'utilisateur final sur une moto brandissant une épée ou situé dans un endroit exotique). Dans ce scénario, l'application d'IA générative, conçue par le consommateur, doit interagir avec le backend de réglage fin via des API pour fournir cette fonctionnalité aux utilisateurs finaux.
Cependant, avant d'aborder cela, concentrons-nous d'abord sur le parcours de sélection du modèle, de test, d'utilisation, d'interaction d'entrée et de sortie et d'évaluation, comme le montre la figure suivante.
Étape 1. Comprendre les principales fonctionnalités FM
De nombreuses dimensions doivent être prises en compte lors de la sélection des modèles de fondation, en fonction du cas d'utilisation, des données disponibles, des réglementations, etc. Une bonne liste de contrôle, bien que non exhaustive, pourrait être la suivante :
- FM propriétaire ou open source – Les modèles propriétaires ont souvent un coût financier, mais ils offrent généralement de meilleures performances (en termes de qualité du texte ou de l'image généré), étant souvent développés et maintenus par des équipes dédiées de fournisseurs de modèles qui garantissent des performances et une fiabilité optimales. D’un autre côté, nous assistons également à l’adoption de modèles open source qui, en plus d’être gratuits, offrent des avantages supplémentaires en termes d’accessibilité et de flexibilité (par exemple, chaque modèle open source est personnalisable). Un exemple de modèle propriétaire est le modèle Claude d'Anthropic, et un exemple de modèle open source très performant est le Falcon-40B, en juillet 2023.
- Licence commerciale – Les considérations en matière de licence sont cruciales lors du choix d’un FM. Il est important de noter que certains modèles sont open source mais ne peuvent pas être utilisés à des fins commerciales, en raison de restrictions ou de conditions de licence. Les différences peuvent être subtiles : le nouveau xgen-7b-8k-base Le modèle, par exemple, est open source et utilisable commercialement (licence Apache-2.0), tandis que la version affinée des instructions du modèle xgen-7b-8k-inst n'est publié qu'à des fins de recherche. Lors de la sélection d'un FM pour une application commerciale, il est essentiel de vérifier le contrat de licence, de comprendre ses limites et de s'assurer qu'il correspond à l'utilisation prévue du projet.
- Paramètres – Le nombre de paramètres, constitués des poids et des biais du réseau neuronal, est un autre facteur clé. Plus de paramètres signifie généralement un modèle plus complexe et potentiellement plus puissant, car il peut capturer des modèles et des corrélations plus complexes dans les données. Cependant, le compromis est que cela nécessite plus de ressources de calcul et, par conséquent, coûte plus cher à exploiter. De plus, nous constatons une tendance vers des modèles plus petits, en particulier dans l’espace open source (modèles allant de 7 à 40 milliards) qui fonctionnent bien, surtout lorsqu’ils sont affinés.
- Vitesse – La vitesse d'un modèle est influencée par sa taille. Les modèles plus grands ont tendance à traiter les données plus lentement (latence plus élevée) en raison de la complexité informatique accrue. Par conséquent, il est crucial d’équilibrer le besoin d’un modèle doté d’une puissance prédictive élevée (souvent des modèles plus grands) avec les exigences pratiques de vitesse, en particulier dans les applications, comme les chatbots, qui exigent des réponses en temps réel ou quasi-réel.
- Taille de la fenêtre de contexte (nombre de jetons) – La fenêtre contextuelle, définie par le nombre maximum de jetons pouvant être entrés ou sortis par invite, est cruciale pour déterminer la quantité de contexte que le modèle peut prendre en compte à la fois (un jeton se traduit approximativement par 0.75 mot pour l'anglais). Les modèles dotés de fenêtres contextuelles plus grandes peuvent comprendre et générer des séquences de texte plus longues, ce qui peut être utile pour les tâches impliquant des conversations ou des documents plus longs.
- Ensemble de données d'entraînement – Il est également important de comprendre sur quel type de données le FM a été formé. Certains modèles peuvent être formés sur divers ensembles de données textuelles telles que des données Internet, des scripts de codage, des instructions ou des commentaires humains. D'autres peuvent également être formés sur des ensembles de données multimodaux, comme des combinaisons de données texte et image. Cela peut influencer l'adéquation du modèle à différentes tâches. En outre, une organisation peut avoir des problèmes de droits d'auteur en fonction des sources exactes sur lesquelles un modèle a été formé. Il est donc obligatoire d'inspecter de près l'ensemble de données de formation.
- Qualité – La qualité d’un FM peut varier en fonction de son type (propriétaire ou open source), de sa taille et de la matière sur laquelle il a été formé. La qualité dépend du contexte, ce qui signifie que ce qui est considéré comme de haute qualité pour une application peut ne pas l'être pour une autre. Par exemple, un modèle formé sur des données Internet peut être considéré comme de haute qualité pour générer du texte conversationnel, mais moins pour des tâches techniques ou spécialisées.
- Ajustable – La possibilité d'affiner un FM en ajustant les poids ou les couches de son modèle peut être un facteur crucial. Un réglage fin permet au modèle de mieux s'adapter au contexte spécifique de l'application, améliorant ainsi les performances sur la tâche spécifique à accomplir. Cependant, le réglage précis nécessite des ressources informatiques et une expertise technique supplémentaires, et tous les modèles ne prennent pas en charge cette fonctionnalité. Les modèles open source sont (en général) toujours affinables car les artefacts du modèle sont disponibles en téléchargement et les utilisateurs peuvent les étendre et les utiliser à volonté. Les modèles propriétaires peuvent parfois offrir la possibilité d’un réglage fin.
- Compétences clients existantes – La sélection d'un FM peut également être influencée par les compétences et la familiarité du client ou de l'équipe de développement. Si une organisation n’a pas d’experts en IA/ML dans son équipe, un service API pourrait lui être mieux adapté. De plus, si une équipe possède une vaste expérience avec un FM spécifique, il peut être plus efficace de continuer à l'utiliser plutôt que d'investir du temps et des ressources pour apprendre et s'adapter à un nouveau.
Ce qui suit est un exemple de deux listes restreintes, une pour les modèles propriétaires et une pour les modèles open source. Vous pouvez compiler des tableaux similaires en fonction de vos besoins spécifiques pour obtenir un aperçu rapide des options disponibles. Notez que les performances et les paramètres de ces modèles changent rapidement et peuvent être obsolètes au moment de la lecture, tandis que d'autres fonctionnalités peuvent être importantes pour des clients spécifiques, comme la langue prise en charge.
Voici un exemple de FM propriétaires notables disponibles dans AWS (juillet 2023).
Voici un exemple de FM open source notable disponible sur AWS (juillet 2023).
Après avoir dressé un aperçu de 10 à 20 modèles candidats potentiels, il devient nécessaire d’affiner davantage cette liste restreinte. Dans cette section, nous proposons un mécanisme rapide qui produira deux ou trois modèles finaux viables comme candidats pour le prochain tour.
Le diagramme suivant illustre le processus de présélection initial.
En règle générale, les ingénieurs d'invites, experts dans la création d'invites de haute qualité permettant aux modèles d'IA de comprendre et de traiter les entrées des utilisateurs, expérimentent diverses méthodes pour effectuer la même tâche (telle qu'une synthèse) sur un modèle. Nous suggérons que ces invites ne soient pas créées à la volée, mais soient systématiquement extraites d'un catalogue d'invites. Ce catalogue d'invites est un emplacement central pour stocker les invites afin d'éviter les réplications, activer le contrôle de version et partager les invites au sein de l'équipe afin de garantir la cohérence entre les différents testeurs d'invites dans les différentes étapes de développement, que nous présentons dans la section suivante. Ce catalogue d'invites est analogue à un référentiel Git d'un magasin de fonctionnalités. Le développeur d'IA générative, qui pourrait potentiellement être la même personne que l'ingénieur d'invite, doit ensuite évaluer le résultat pour déterminer s'il conviendrait à l'application d'IA générative qu'il cherche à développer.
Étape 2. Testez et évaluez le meilleur FM
Une fois la liste restreinte réduite à environ trois FM, nous recommandons une étape d'évaluation pour tester davantage les capacités des FM et leur adéquation au cas d'utilisation. En fonction de la disponibilité et de la nature des données d'évaluation, nous proposons différentes méthodes, comme l'illustre la figure suivante.
La méthode à utiliser en premier dépend si vous avez étiqueté ou non les données de test.
Si vous disposez de données étiquetées, vous pouvez les utiliser pour effectuer une évaluation de modèle, comme nous le faisons avec les modèles ML traditionnels (saisissez quelques échantillons et comparez le résultat avec les étiquettes). Selon que les données de test comportent des étiquettes discrètes (telles qu'une analyse des sentiments positifs, négatifs ou neutres) ou s'il s'agit d'un texte non structuré (telles qu'un résumé), nous proposons différentes méthodes d'évaluation :
- Mesures de précision – Dans le cas de résultats discrets (tels que l'analyse des sentiments), nous pouvons utiliser des mesures de précision standard telles que la précision, le rappel et le score F1
- Métriques de similarité – Si le résultat n'est pas structuré (comme un résumé), nous suggérons des métriques de similarité comme ROUGE et la similarité cosinus.
Certains cas d'utilisation ne se prêtent pas à une véritable réponse (par exemple, « Créer une courte histoire pour enfants pour ma fille de 5 ans »). Dans de tels cas, il devient plus difficile d’évaluer les modèles car vous ne disposez pas de données de test étiquetées. Nous proposons deux approches, selon l'importance de l'examen humain du modèle par rapport à l'évaluation automatisée :
- Humain dans la boucle (HIL) – Dans ce cas, une équipe de testeurs rapides examinera les réponses d’un modèle. En fonction du degré de critique de l'application, les testeurs d'invite peuvent examiner 100 % des résultats du modèle ou simplement un échantillon.
- Évaluation basée sur le LLM – Dans ce scénario, les testeurs d'invite sont remplacés par un LLM, idéalement plus puissant (bien que peut-être plus lent et plus coûteux) que ceux testés. Le LLM examinera toutes les réponses générées par le modèle et les notera. Cette méthode peut entraîner une qualité inférieure, mais il s'agit d'une option d'évaluation moins coûteuse et plus rapide qui pourrait fournir une bonne évaluation initiale des performances des modèles.
Par exemple, nous pouvons utiliser l'exemple d'invite suivant pour un LLM, qui comprend la requête d'entrée, la réponse LLM et les instructions : « Nous aimerions demander votre avis sur les performances d'un assistant IA en réponse à la question de l'utilisateur affichée ci-dessus. . Veuillez évaluer l'utilité, la pertinence, l'exactitude et le niveau de détail de la réponse de l'assistant. L’assistant recevra une note globale sur une échelle de 1 à 10, une note plus élevée indiquant une meilleure performance globale.
Cette invite sera envoyée à un autre LLM (l'EvalLLM) pour évaluation. Ce qui suit est un exemple où la réponse du modèle Falcon-40B a été évaluée par un EvalLLM (dans ce cas Claude). Nous utilisons la question « Et si le canal de Suez n’avait jamais été construit ? » La réponse est la suivante :
Question : Et si le canal de Suez n’avait jamais été construit ?
falcon-40b-instruire
Si le canal de Suez n’avait jamais été construit, les navires devraient parcourir l’Afrique pour naviguer entre la Méditerranée et la mer Rouge. Cela ajouterait beaucoup de temps et de distance au voyage, le rendant moins efficace et plus coûteux. De plus, sans le canal de Suez, de nombreux pays du Moyen-Orient et d’Afrique du Nord auraient été bien moins connectés au reste du monde, ce qui entraverait leur développement économique et culturel.
Critique (Note : 9/10)
La réponse de l'assistant est très pertinente, précise et détaillée. Il apporte une excellente réponse à l’hypothétique question de l’utilisateur sur l’inexistence du canal de Suez. L'assistant souligne à juste titre les implications sur les voyages maritimes et l'impact économique et culturel sur le Moyen-Orient et l'Afrique du Nord. Cependant, il aurait pu développer davantage les implications géopolitiques ou l’impact sur les modèles commerciaux mondiaux pour une réponse plus globale.
La figure suivante illustre l’exemple de processus d’évaluation de bout en bout.
Sur la base de cet exemple, pour effectuer une évaluation, nous devons fournir les exemples d'invites, que nous stockons dans le catalogue d'invites, ainsi qu'un ensemble de données d'évaluation étiquetées ou non en fonction de nos applications spécifiques. Par exemple, avec un ensemble de données d'évaluation étiquetées, nous pouvons fournir des invites (saisie et requête) telles que « Donnez-moi le nom complet du Premier ministre britannique en 2023 » et des résultats et réponses, tels que « Rishi Sunak ». Avec un ensemble de données non étiqueté, nous fournissons uniquement la question ou l'instruction, telle que « Générer le code source d'un site Web de vente au détail ». Nous appelons la combinaison d'un catalogue d'invites et d'un ensemble de données d'évaluation le catalogue d'invites d'évaluation. La raison pour laquelle nous différencions le catalogue d'invites du catalogue d'invites d'évaluation est que ce dernier est dédié à un cas d'utilisation spécifique au lieu des invites et instructions génériques (telles que la réponse aux questions) que contient le catalogue d'invites.
Avec ce catalogue d'invites d'évaluation, l'étape suivante consiste à transmettre les invites d'évaluation aux principaux FM. Le résultat est un ensemble de données de résultats d'évaluation qui contient les invites, les sorties de chaque FM et la sortie étiquetée ainsi qu'un score (s'il existe). Dans le cas d'un catalogue d'invites d'évaluation non étiqueté, il existe une étape supplémentaire pour qu'un HIL ou un LLM examine les résultats et fournisse une note et des commentaires (comme nous l'avons décrit précédemment). Le résultat final sera des résultats agrégés combinant les scores de tous les résultats (calculer la précision moyenne ou l'évaluation humaine) et permettre aux utilisateurs de comparer la qualité des modèles.
Après avoir collecté les résultats de l’évaluation, nous proposons de choisir un modèle basé sur plusieurs dimensions. Ceux-ci dépendent généralement de facteurs tels que la précision, la vitesse et le coût. La figure suivante montre un exemple.
Chaque modèle possèdera des atouts et certains compromis dans ces dimensions. Selon le cas d'utilisation, nous devons attribuer différentes priorités à ces dimensions. Dans l’exemple précédent, nous avons choisi de donner la priorité au coût comme facteur le plus important, suivi de la précision, puis de la rapidité. Même s'il est plus lent et moins efficace que FM1, il reste suffisamment efficace et nettement moins cher à héberger. Par conséquent, nous pourrions sélectionner FM2 comme premier choix.
Étape 3. Développer le backend et le frontend de l'application d'IA générative
À ce stade, les développeurs d'IA générative ont sélectionné le FM adapté à l'application spécifique, avec l'aide d'ingénieurs et de testeurs rapides. La prochaine étape consiste à commencer à développer l’application d’IA générative. Nous avons séparé le développement de l'application d'IA générative en deux couches, un backend et un front-end, comme le montre la figure suivante.
Sur le backend, les développeurs d'IA générative intègrent le FM sélectionné dans les solutions et travaillent avec les ingénieurs d'invite pour créer l'automatisation permettant de transformer l'entrée de l'utilisateur final en invites FM appropriées. Les testeurs d'invites créent les entrées nécessaires dans le catalogue d'invites pour les tests automatiques ou manuels (HIL ou LLM). Ensuite, les développeurs d’IA générative créent le mécanisme de chaînage d’invites et d’application pour fournir le résultat final. Le chaînage d'invites, dans ce contexte, est une technique permettant de créer des applications LLM plus dynamiques et contextuelles. Il fonctionne en décomposant une tâche complexe en une série de sous-tâches plus petites et plus faciles à gérer. Par exemple, si nous posons à un LLM la question « Où est né le premier ministre du Royaume-Uni et à quelle distance se trouve cet endroit de Londres », la tâche peut être divisée en invites individuelles, où une invite peut être construite en fonction de la réponse. d'une évaluation rapide précédente, telle que « Qui est le Premier ministre du Royaume-Uni », « Quel est son lieu de naissance » et « À quelle distance se trouve cet endroit de Londres ? Pour garantir une certaine qualité d'entrée et de sortie, les développeurs d'IA générative doivent également créer le mécanisme permettant de surveiller et de filtrer les entrées de l'utilisateur final et les sorties des applications. Si, par exemple, l'application LLM est censée éviter les demandes et réponses toxiques, elle pourrait appliquer un détecteur de toxicité pour les entrées et les sorties et les filtrer. Enfin, ils doivent fournir un mécanisme de notation, qui permettra d'augmenter le catalogue d'invites d'évaluation avec de bons et de mauvais exemples. Une représentation plus détaillée de ces mécanismes sera présentée dans les prochains articles.
Pour fournir la fonctionnalité à l'utilisateur final de l'IA générative, le développement d'un site Web frontend qui interagit avec le backend est nécessaire. Par conséquent, les personnalités DevOps et AppDevs (développeurs d'applications sur le cloud) doivent suivre les meilleures pratiques de développement pour mettre en œuvre les fonctionnalités d'entrée/sortie et d'évaluation.
En plus de cette fonctionnalité de base, le frontend et le backend doivent intégrer la fonctionnalité de création de comptes d'utilisateurs personnels, de téléchargement de données, de lancement de réglages fins en tant que boîte noire et d'utilisation du modèle personnalisé au lieu du FM de base. La production d’une application d’IA générative est similaire à celle d’une application normale. La figure suivante représente un exemple d'architecture.
Dans cette architecture, les développeurs d'IA générative, les ingénieurs d'invite et DevOps ou AppDevs créent et testent l'application manuellement en la déployant via CI/CD dans un environnement de développement (Generative AI App Dev dans la figure précédente) à l'aide de référentiels de code dédiés et en fusionnant avec la branche de développement. À ce stade, les développeurs d'IA générative utiliseront le FM correspondant en appelant l'API comme cela a été fourni par les fournisseurs de réglages fins FM. Ensuite, pour tester l'application de manière approfondie, ils doivent promouvoir le code vers la branche de test, ce qui déclenchera le déploiement via CI/CD vers l'environnement de préproduction (generative AI App Pre-prod). Dans cet environnement, les testeurs d'invites doivent essayer un grand nombre de combinaisons d'invites et examiner les résultats. La combinaison d'invites, de résultats et de révision doit être déplacée vers le catalogue d'invites d'évaluation pour automatiser le processus de test à l'avenir. Après ce test approfondi, la dernière étape consiste à promouvoir l'application d'IA générative en production via CI/CD en fusionnant avec la branche principale (generative AI App Prod). Notez que toutes les données, y compris le catalogue d'invites, les données et résultats d'évaluation, les données et métadonnées de l'utilisateur final et les métadonnées de modèle affinées, doivent être stockées dans le lac de données ou la couche de maillage de données. Les pipelines et référentiels CI/CD doivent être stockés dans un compte d'outils distinct (similaire à celui décrit pour MLOps).
Le parcours des prestataires
Les fournisseurs de FM doivent former les FM, comme les modèles d'apprentissage en profondeur. Pour eux, le cycle de vie et l’infrastructure MLOps de bout en bout sont nécessaires. Des ajouts sont nécessaires dans la préparation des données historiques, l'évaluation du modèle et la surveillance. La figure suivante illustre leur parcours.
Dans le ML classique, les données historiques sont le plus souvent créées en alimentant la vérité terrain via des pipelines ETL. Par exemple, dans un cas d'utilisation de prédiction de désabonnement, une automatisation met à jour une table de base de données en fonction du nouveau statut d'un client pour qu'il se désabonne/ne se désabonne pas automatiquement. Dans le cas des FM, ils ont besoin de milliards de points de données étiquetés ou non. Dans les cas d'utilisation de texte en image, une équipe d'étiqueteurs de données doit étiqueter paires manuellement. Il s’agit d’un exercice coûteux qui nécessite un grand nombre de ressources humaines. Amazon SageMaker Vérité au sol Plus peut mettre à votre disposition une équipe d’étiqueteuses pour réaliser cette activité à votre place. Pour certains cas d'utilisation, ce processus peut également être partiellement automatisé, par exemple en utilisant des modèles de type CLIP. Dans le cas d'un LLM, tel que le texte à texte, les données ne sont pas étiquetées. Cependant, ils doivent être préparés et suivre le format des données historiques non étiquetées existantes. Par conséquent, des éditeurs de données sont nécessaires pour effectuer la préparation des données nécessaire et garantir la cohérence.
Une fois les données historiques préparées, l’étape suivante est la formation et la production du modèle. Notez que les mêmes techniques d’évaluation que celles que nous avons décrites pour les consommateurs peuvent être utilisées.
Le voyage des peaufineurs
Les peaufineurs visent à adapter un FM existant à leur contexte spécifique. Par exemple, un modèle FM peut résumer un texte à usage général mais pas un rapport financier avec précision ou ne peut pas générer de code source pour un langage de programmation non courant. Dans ces cas, les ajusteurs doivent étiqueter les données, affiner un modèle en exécutant une tâche de formation, déployer le modèle, le tester en fonction des processus consommateur et surveiller le modèle. Le diagramme suivant illustre ce processus.
Pour l’instant, il existe deux mécanismes de réglage fin :
- Réglage fin – En utilisant un FM et des données étiquetées, une tâche de formation recalcule les poids et les biais des couches du modèle d'apprentissage profond. Ce processus peut nécessiter beaucoup de calculs et nécessite une quantité représentative de données, mais peut générer des résultats précis.
- Ajustement précis des paramètres (PEFT) – Au lieu de recalculer tous les poids et biais, les chercheurs ont montré qu’en ajoutant de petites couches supplémentaires aux modèles d’apprentissage profond, ils pouvaient obtenir des résultats satisfaisants (par exemple, LoRA). PEFT nécessite une puissance de calcul inférieure à un réglage fin en profondeur et à un travail de formation avec moins de données d'entrée. L’inconvénient est une précision potentiellement inférieure.
Le diagramme suivant illustre ces mécanismes.
Maintenant que nous avons défini les deux principales méthodes de réglage fin, l’étape suivante consiste à déterminer comment déployer et utiliser le FM open source et propriétaire.
Avec les FM open source, les ajusteurs peuvent télécharger l'artefact du modèle et le code source à partir du Web, par exemple, en utilisant le Hub de modèle de visage étreignant. Cela vous donne la possibilité d'affiner en profondeur le modèle, de le stocker dans un registre de modèles local et de le déployer sur un Amazon Sage Maker point final. Ce processus nécessite une connexion Internet. Pour prendre en charge des environnements plus sécurisés (comme pour les clients du secteur financier), vous pouvez télécharger le modèle sur site, exécuter tous les contrôles de sécurité nécessaires et les télécharger dans un compartiment local sur un compte AWS. Ensuite, les peaufineurs utilisent la FM du bucket local sans connexion Internet. Cela garantit la confidentialité des données et les données ne transitent pas sur Internet. Le diagramme suivant illustre cette méthode.
Avec les FM propriétaires, le processus de déploiement est différent car les ajusteurs n'ont pas accès à l'artefact du modèle ou au code source. Les modèles sont stockés dans les comptes AWS et les registres de modèles du fournisseur FM propriétaire. Pour déployer un tel modèle sur un point de terminaison SageMaker, les ajusteurs peuvent demander uniquement le package de modèle qui sera déployé directement sur un point de terminaison. Ce processus nécessite que les données client soient utilisées dans les comptes des fournisseurs FM propriétaires, ce qui soulève des questions concernant l'utilisation de données sensibles client dans un compte distant pour effectuer un réglage fin, et l'hébergement des modèles dans un registre de modèles partagé entre plusieurs clients. . Cela conduit à un problème de multilocation qui devient plus difficile si les fournisseurs FM propriétaires doivent servir ces modèles. Si les peaufineurs utilisent Socle amazonien, ces défis sont résolus : les données ne circulent pas sur Internet et les fournisseurs FM n'ont pas accès aux données des peaufineurs. Les mêmes défis s'appliquent aux modèles open source si les peaufineurs souhaitent proposer des modèles provenant de plusieurs clients, comme dans l'exemple que nous avons donné plus tôt avec le site Web sur lequel des milliers de clients téléchargeront des images personnalisées. Cependant, ces scénarios peuvent être considérés comme contrôlables car seul le réglage fin est impliqué. Le diagramme suivant illustre cette méthode.
D'un point de vue technologique, l'architecture qu'un réglage fin doit prendre en charge est similaire à celle du MLOps (voir la figure suivante). Le réglage fin doit être effectué en développement en créant des pipelines ML, par exemple en utilisant Pipelines Amazon SageMaker; effectuer un prétraitement, un réglage fin (tâche de formation) et un post-traitement ; et envoyer les modèles affinés à un registre de modèles local dans le cas d'un FM open source (sinon, le nouveau modèle sera stocké dans l'environnement propriétaire FM fourni). Ensuite, en pré-production, nous devons tester le modèle comme nous le décrivons pour le scénario des consommateurs. Enfin, le modèle sera servi et suivi en prod. Notez que le FM actuel (affiné) nécessite des points de terminaison d'instance GPU. Si nous devons déployer chaque modèle affiné sur un point de terminaison distinct, cela pourrait augmenter le coût dans le cas de centaines de modèles. Par conséquent, nous devons utiliser des points de terminaison multimodèles et résoudre le défi de la multi-location.
Les affineurs adaptent un modèle FM en fonction d'un contexte spécifique pour l'utiliser à leurs fins commerciales. Cela signifie que la plupart du temps, les peaufineurs sont également des consommateurs qui doivent prendre en charge toutes les couches, comme nous l'avons décrit dans les sections précédentes, y compris le développement d'applications d'IA générative, les lacs de données et le maillage de données, ainsi que les MLOps.
La figure suivante illustre le cycle de vie complet des réglages précis de FM dont les affineurs ont besoin pour fournir à l'utilisateur final de l'IA générative.
La figure suivante illustre les étapes clés.
Les étapes clés sont les suivantes :
- L'utilisateur final crée un compte personnel et télécharge des données privées.
- Les données sont stockées dans le lac de données et sont prétraitées pour suivre le format attendu par le FM.
- Cela déclenche un pipeline ML de réglage fin qui ajoute le modèle au registre de modèles,
- À partir de là, soit le modèle est déployé en production avec un minimum de tests, soit le modèle effectue des tests approfondis avec HIL et des portes d'approbation manuelles.
- Le modèle affiné est mis à la disposition des utilisateurs finaux.
Étant donné que cette infrastructure est complexe pour les clients non professionnels, AWS a lancé Amazon Bedrock pour se décharger des efforts de création de telles architectures et rapprocher les FM affinés de la production.
Personnalités et processus FMOps et LLMOps différenciateurs
Sur la base des parcours d'utilisateurs précédents (consommateur, producteur et affineur), de nouveaux personnages dotés de compétences spécifiques sont requis, comme l'illustre la figure suivante.
Les nouveaux personnages sont les suivants :
- Étiqueteurs et éditeurs de données – Ces utilisateurs étiquettent les données, telles que paires, ou préparer des données non étiquetées, telles que du texte libre, et étendre l'équipe d'analyse avancée et les environnements de lac de données.
- Affineurs – Ces utilisateurs ont des connaissances approfondies sur les FM et savent les régler, élargissant ainsi l’équipe de science des données qui se concentrera sur le ML classique.
- Développeurs d'IA générative – Ils ont des connaissances approfondies sur la sélection des FM, le chaînage des invites et des applications et le filtrage des entrées et des sorties. Ils appartiennent à une nouvelle équipe : l’équipe des applications d’IA générative.
- Ingénieurs rapides – Ces utilisateurs conçoivent les invites d’entrée et de sortie pour adapter la solution au contexte et testent et créent la version initiale du catalogue d’invites. Leur équipe est l’équipe des applications d’IA générative.
- Testeurs rapides – Ils testent à grande échelle la solution d’IA générative (backend et frontend) et alimentent leurs résultats pour augmenter le catalogue d’invites et l’ensemble de données d’évaluation. Leur équipe est l’équipe des applications d’IA générative.
- AppDev et DevOps – Ils développent le front-end (comme un site Web) de l’application d’IA générative. Leur équipe est l’équipe des applications d’IA générative.
- Utilisateurs finaux de l'IA générative – Ces utilisateurs consomment des applications d’IA générative sous forme de boîtes noires, partagent des données et évaluent la qualité du résultat.
La version étendue de la cartographie des processus MLOps pour intégrer l'IA générative peut être illustrée par la figure suivante.
Une nouvelle couche d'application est l'environnement dans lequel les développeurs d'IA générative, les ingénieurs et testeurs d'invites, ainsi que les AppDevs, ont créé le backend et le front-end des applications d'IA générative. Les utilisateurs finaux de l'IA générative interagissent avec le frontal des applications d'IA générative via Internet (comme une interface utilisateur Web). D’un autre côté, les étiqueteurs et éditeurs de données doivent prétraiter les données sans accéder au backend du lac de données ou du maillage de données. Par conséquent, une interface Web (site Web) avec un éditeur est nécessaire pour interagir en toute sécurité avec les données. SageMaker Ground Truth fournit cette fonctionnalité prête à l'emploi.
Conclusion
MLOps peut nous aider à produire efficacement des modèles ML. Cependant, pour opérationnaliser les applications d’IA générative, vous avez besoin de compétences, de processus et de technologies supplémentaires, conduisant aux FMOps et LLMOps. Dans cet article, nous avons défini les principaux concepts de FMOps et LLMOps et décrit les principaux différenciateurs par rapport aux capacités MLOps en termes de personnes, de processus, de technologie, de sélection de modèles FM et d'évaluation. De plus, nous avons illustré le processus de réflexion d'un développeur d'IA générative et le cycle de vie de développement d'une application d'IA générative.
À l'avenir, nous nous concentrerons sur la fourniture de solutions dans le domaine abordé et fournirons plus de détails sur la manière d'intégrer la surveillance FM (telle que la toxicité, les biais et les hallucinations) et les modèles architecturaux de sources de données tierces ou privées, tels que Génération augmentée de récupération (RAG), dans FMOps/LLMOps.
Pour en savoir plus, consultez Feuille de route de la fondation MLOps pour les entreprises avec Amazon SageMaker et testez la solution de bout en bout dans Mise en œuvre des pratiques MLOps avec les modèles pré-formés Amazon SageMaker JumpStart.
Si vous avez des commentaires ou des questions, veuillez les laisser dans la section commentaires.
À propos des auteurs
Dr Sokratis Kartakis est un architecte principal de solutions spécialisé en apprentissage automatique et en opérations pour Amazon Web Services. Sokratis vise à permettre aux entreprises clientes d'industrialiser leurs solutions d'apprentissage automatique (ML) en exploitant les services AWS et en façonnant leur modèle opérationnel, c'est-à-dire la fondation MLOps et la feuille de route de transformation tirant parti des meilleures pratiques de développement. Il a passé plus de 15 ans à inventer, concevoir, diriger et mettre en œuvre des solutions innovantes de bout en bout de ML et d'Internet des objets (IoT) au niveau de la production dans les domaines de l'énergie, de la vente au détail, de la santé, de la finance/banque, des sports automobiles, etc. Sokratis aime passer son temps libre avec sa famille et ses amis, ou faire de la moto.
Heiko Hotz est un architecte de solutions senior pour l'IA et l'apprentissage automatique, avec un accent particulier sur le traitement du langage naturel, les grands modèles de langage et l'IA générative. Avant d'occuper ce poste, il était responsable de la science des données pour le service client européen d'Amazon. Heiko aide nos clients à réussir leur parcours IA/ML sur AWS et a travaillé avec des organisations de nombreux secteurs, notamment l'assurance, les services financiers, les médias et le divertissement, la santé, les services publics et l'industrie manufacturière. Pendant son temps libre, Heiko voyage autant que possible.
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
- PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
- PlatonESG. Automobile / VE, Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
- PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
- GraphiquePrime. Élevez votre jeu de trading avec ChartPrime. Accéder ici.
- Décalages de bloc. Modernisation de la propriété des compensations environnementales. Accéder ici.
- La source: https://aws.amazon.com/blogs/machine-learning/fmops-llmops-operationalize-generative-ai-and-differences-with-mlops/
- :possède
- :est
- :ne pas
- :où
- $UP
- 1
- 10
- 100
- 2023
- 23
- 7
- 75
- a
- capacité
- Capable
- A Propos
- au dessus de
- RÉSUMÉ
- accès
- accessible
- accès
- Compte
- hybrides
- précision
- Avec cette connaissance vient le pouvoir de prendre
- avec précision
- atteindre
- actes
- activité
- adapter
- adaptation
- ajouter
- ajoutant
- ajout
- Supplémentaire
- En outre
- ajouts
- Ajoute
- administration
- Adoption
- Avancée
- Afrique
- Après
- contrat
- AI
- AI et apprentissage automatique
- Assistant IA
- Modèles AI
- Services d'IA
- cas d'utilisation de l'IA
- AI / ML
- objectif
- Aligne
- Tous
- permettre
- permet
- le long de
- déjà
- aussi
- Bien que
- toujours
- Amazon
- Amazon Sage Maker
- Amazon SageMaker JumpStart
- Amazon Web Services
- parmi
- montant
- an
- selon une analyse de l’Université de Princeton
- analytique
- ainsi que
- et infrastructure
- Une autre
- répondre
- réponses
- tous
- api
- Apis
- appli
- Application
- Le développement d'applications
- applications
- Appliquer
- une approche
- approches
- approprié
- approbation
- d'environ
- architectes
- architectural
- architecture
- SONT
- autour
- AS
- Évaluation
- Assistante gérante
- At
- vérifié
- vérificateurs
- augmentée
- automatiser
- Automatisation
- Automatique
- automatiquement
- Automation
- disponibilité
- disponibles
- moyen
- éviter
- AWS
- backend
- Mal
- Balance
- basé
- Essentiel
- BE
- car
- devenez
- devient
- était
- before
- va
- référence
- avantages.
- LES MEILLEURS
- Améliorée
- jusqu'à XNUMX fois
- biais
- biais
- Milliards
- milliards
- Noir
- né
- emprunter
- tous les deux
- les robots
- Box
- boîtes
- Branche
- Rupture
- brièvement
- Apporter
- Cassé
- construire
- Développement
- construit
- la performance des entreprises
- mais
- by
- calculer
- Appelez-nous
- appelé
- appel
- CAN
- candidat
- candidats
- capacités
- aptitude
- capturer
- maisons
- cas
- catalogue
- catégories
- central
- centralisée
- certaines
- challenge
- globaux
- difficile
- Change
- Chatbots
- moins chère
- Contrôles
- le choix
- choose
- classiques
- étroitement
- plus
- Vêtements
- le cloud
- code
- Codage
- collaborons
- combinaison
- комбинации
- combiner
- comment
- commentaires
- commercial
- commercialement
- Commun
- comparer
- par rapport
- complet
- achèvement
- complexe
- complexité
- conformité
- composition
- complet
- puissance de calcul
- ordinateur
- concentrer
- concept
- concepts
- Préoccupations
- conditions
- Conduire
- menée
- connecté
- connexion
- par conséquent
- Considérer
- considérations
- considéré
- consommer
- consommateur
- Les consommateurs
- consommation
- Contenant
- contient
- contenu
- création de contenu
- contexte
- continuer
- des bactéries
- de la conversation
- conversations
- droit d'auteur
- Correspondant
- Prix
- cher
- Costs
- pourriez
- d'exportation
- couverture
- couvert
- engendrent
- créée
- crée des
- La création
- création
- critique
- crucial
- à la diversité
- Courant
- Customiser
- des clients
- données client
- Service à la clientèle
- Clients
- données
- Lac de données
- points de données
- Préparation des données
- confidentialité des données
- science des données
- Base de données
- ensembles de données
- Décentralisé
- Décider
- décisions
- dévoué
- profond
- plongée profonde
- l'apprentissage en profondeur
- défini
- définir
- définition
- définitions
- livrer
- delve
- Demande
- Selon
- dépend
- représentant
- déployer
- déployé
- déployer
- déploiement
- décrire
- décrit
- la description
- Conception
- un
- conception
- désir
- voulu
- détaillé
- détails
- Déterminer
- détermination
- dev
- développer
- développé
- Développeur
- mobiles
- développement
- Développement
- équipe de développement
- différences
- différent
- différencier
- dimensions
- directement
- discuter
- discuté
- dans
- distance
- plongeon
- plusieurs
- do
- INSTITUTIONNELS
- Ne fait pas
- domaine
- domaines
- Ne pas
- down
- download
- motivation
- deux
- Dynamic
- e
- chacun
- Plus tôt
- Est
- Easy
- Économique
- éditeur
- Efficace
- efficace
- efficacement
- effort
- non plus
- caoutchouteuse élaborée
- élu
- permettre
- permettant
- fin
- end-to-end
- Endpoint
- énergie
- ingénieur
- ENGINEERING
- Les ingénieurs
- Anglais
- de renforcer
- assurer
- Assure
- Entreprise
- entreprises
- Divertissement
- Environment
- environnements
- également
- notamment
- essential
- etc
- EU
- évaluer
- évalué
- évaluation
- Pourtant, la
- Chaque
- exemple
- exemples
- excellent
- excité
- Exercises
- existant
- existe
- Exotique
- attend
- cher
- d'experience
- expérience
- nous a permis de concevoir
- de santé
- exploitant
- étendre
- extension
- extension
- les
- Une vaste expérience
- précieux
- extrait
- f1
- Visage
- facteur
- facteurs
- Familiarité
- famille
- loin
- plus rapide
- Fonctionnalité
- Réactions
- alimentation
- Figure
- une fonction filtre
- filtration
- finale
- finalement
- la traduction de documents financiers
- rapport financier
- Secteur financier
- services financiers
- Prénom
- s'adapter
- Flexibilité
- flexible
- Focus
- concentré
- se concentre
- mettant l'accent
- suivre
- suivi
- Abonnement
- suit
- Pour
- Pour les consommateurs
- formulaire
- le format
- Fondation
- quatre
- Gratuit
- amis
- De
- avant
- L'extrémité avant
- L'extrémité avant
- plein
- fondamental
- plus
- En outre
- avenir
- Portes
- jauge
- Général
- à usage général
- généralement
- générer
- généré
- génère
- générateur
- génération
- génératif
- IA générative
- géopolitique
- obtenez
- Git
- donné
- donne
- Global
- commerce international
- Bien
- gouvernance
- GPU
- Sol
- ait eu
- main
- Exploiter
- Vous avez
- ayant
- he
- front
- Santé
- la médecine
- vous aider
- aide
- ici
- Haute
- de haute qualité
- augmentation
- très
- sa
- historique
- appuyez en continu
- hôte
- organisé
- Comment
- How To
- Cependant
- HTML
- HTTPS
- humain
- Des centaines
- i
- idéalement
- if
- illustre
- image
- satellite
- imaginaire
- Impact
- Mettre en oeuvre
- la mise en œuvre
- implications
- importance
- important
- l'amélioration de
- in
- comprendre
- inclut
- Y compris
- intégrer
- Améliore
- increased
- indique
- Indicateurs
- individuel
- secteurs
- influencer
- influencé
- Infrastructure
- initiale
- technologie innovante
- contribution
- entrées
- instance
- plutôt ;
- Des instructions
- Assurance
- intégrer
- prévu
- interagir
- interagissant
- l'interaction
- interagit
- Interfaces
- Internet
- connexion Internet
- Internet des objets
- développement
- introduire
- sueñortiendo
- impliqué
- impliquant
- IOT
- IT
- SES
- Emploi
- chemin
- Voyages
- Juillet
- juste
- ACTIVITES
- facteur clé
- Genre
- Savoir
- spécialisées
- connu
- Libellé
- Etiquettes
- lac
- langue
- gros
- plus importantes
- Nom de famille
- Latence
- couche
- poules pondeuses
- conduisant
- Conduit
- APPRENTISSAGE
- apprentissage
- Laisser
- prêter
- moins
- Niveau
- en tirant parti
- bibliothèques
- Licence
- Licence
- vos produits
- comme
- aime
- limites
- LINK
- LLM
- charge
- locales
- situé
- emplacement
- London
- Location
- plus long
- baisser
- click
- machine learning
- LES PLANTES
- Entrée
- maintenir
- Majorité
- Fabrication
- maniable
- obligatoire
- Manuel
- manuellement
- fabrication
- de nombreuses
- Localisation
- massif
- maturité
- maximales
- Mai..
- me
- sens
- veux dire
- mécanisme
- mécanismes
- Médias
- Méditerranéen
- mentionné
- fusion
- engrener
- Métadonnées
- méthode
- Méthodologie
- méthodes
- Métrique
- Milieu
- Moyen-Orient
- pourrait
- minimum
- ML
- MLOps
- modèle
- numériques jumeaux (digital twin models)
- Surveiller
- surveillé
- Stack monitoring
- PLUS
- plus efficace
- (en fait, presque toutes)
- la plupart
- Motorsports
- Bougez
- déménagé
- mouvement
- beaucoup
- plusieurs
- Musique
- must
- my
- prénom
- Nature
- Traitement du langage naturel
- Nature
- NAVIGUER
- nécessaire
- Besoin
- nécessaire
- Besoins
- négatif
- réseau et
- Réseau neuronal
- Neutri
- n'allons jamais
- Nouveauté
- nouvellement
- next
- nlp
- aucune
- Ordinaire
- Nord
- notable
- nombre
- observer
- of
- code
- présenté
- souvent
- on
- Onboarding
- ONE
- et, finalement,
- uniquement
- ouvert
- open source
- d'exploitation
- Opérations
- optimaux
- Option
- Options
- or
- organisation
- organisations
- Autre
- Autres
- autrement
- nos
- ande
- Résultat
- sortie
- plus de
- global
- vue d'ensemble
- propre
- propriétaire
- propriétaires
- paquet
- paires
- paramètres
- motifs
- Personnes
- /
- Effectuer
- performant
- effectuer
- être
- personne
- personnel
- Personnalisé
- objectifs
- phase
- Photos
- pièce
- pipeline
- Place
- plateforme
- Platon
- Intelligence des données Platon
- PlatonDonnées
- veuillez cliquer
- Point
- des notes bonus
- politiques
- positif
- posséder
- possible
- Post
- Poteaux
- défaillances
- l'éventualité
- power
- solide
- Méthode
- pratiques
- La précision
- prévoir
- prédiction
- Prédictions
- préparation
- Préparer
- préparé
- en train de préparer
- présenté
- précédent
- précédemment
- Prime
- premier ministre
- principes
- Avant
- Prioriser
- la confidentialité
- Privé
- Problème
- processus
- les process
- traitement
- Produit
- producteur
- Produit
- Vidéo
- Programmation
- Projet
- promouvoir
- preuve
- preuve de concept
- proposer
- propriétaire
- Prouver
- fournir
- à condition de
- de voiture.
- fournisseurs
- fournit
- aportando
- but
- des fins
- pousse
- puzzle
- qualité
- question
- fréquemment posées
- Rapide
- soulève
- gamme
- allant
- rapidement
- Tarif
- plutôt
- clients
- en cours
- en temps réel
- raison
- recevoir
- recommander
- Rouge
- Prix Réduit
- affiner
- en ce qui concerne
- les registres
- enregistrement
- règlements
- en relation
- libéré
- pertinence
- pertinent
- fiabilité
- reste
- éloigné
- remplacé
- rapport
- dépôt
- représentation
- représentant
- nécessaire
- demandes
- conditions
- Exigences
- a besoin
- un article
- chercheurs
- Resources
- respectivement
- réponse
- réponses
- responsables
- REST
- restrictions
- Restrictif
- résultat
- Résultats
- détail
- réutiliser
- Avis
- examiné
- équitation
- bon
- feuille de route
- Rôle
- rôle
- grossièrement
- Round
- Courir
- pour le running
- sagemaker
- même
- tas de sable
- Escaliers intérieurs
- mise à l'échelle
- scénario
- scénarios
- Sciences
- scientifiques
- But
- gratter
- scripts
- MER
- Section
- les sections
- secteur
- sécurisé
- en toute sécurité
- sécurité
- les politiques de sécurité
- sur le lien
- recherche
- choisi
- la sélection
- sélection
- envoi
- supérieur
- envoyé
- sentiment
- séparé
- Séquence
- Série
- besoin
- service
- Services
- service
- set
- plusieurs
- mise en forme
- Partager
- commun
- navires
- Shorts
- devrait
- montré
- Spectacles
- côté
- significative
- de façon significative
- similaires
- simplifier
- Taille
- compétences
- petit
- faibles
- PME
- So
- sur mesure
- Solutions
- RÉSOUDRE
- quelques
- Identifier
- code source
- Sources
- Space
- spécial
- spécialiste
- spécialisé
- groupe de neurones
- spécifiquement
- vitesse
- passer
- dépensé
- Étape
- étapes
- parties prenantes
- Standard
- standardisation
- Commencer
- Statut
- étapes
- Étapes
- Boutique
- stockée
- stockage
- Histoire
- forces
- STRONG
- Par la suite
- réussi
- tel
- suggérer
- pertinence
- convient
- résumé
- RÉSUMÉ
- Support
- Appareils
- supposé
- sûr
- SWIFT
- combustion propre
- table
- Prenez
- Tâche
- tâches
- équipe
- équipes
- Technique
- techniques
- Les technologies
- Technologie
- conditions
- tester
- examiné
- testeurs
- Essais
- que
- qui
- La
- El futuro
- La Source
- au Royaume-Uni
- le monde
- leur
- Les
- se
- puis
- Là.
- donc
- Ces
- l'ont
- des choses
- En pensant
- des tiers.
- this
- ceux
- bien que?
- pensée
- milliers
- trois
- fiable
- à
- ensemble
- jeton
- Tokens
- top
- Les sujets
- vers
- commerce
- traditionnel
- Train
- qualifié
- Formation
- Transformer
- De La Carrosserie
- Voyage
- voyage
- Trend
- déclencher
- oui
- Vérité
- Essai
- deux
- type
- types
- typiquement
- ui
- Uk
- comprendre
- compréhension
- unité
- unités
- Actualités
- Téléchargement
- us
- utilisable
- Utilisation
- utilisé
- cas d'utilisation
- d'utiliser
- Utilisateur
- utilisateurs
- Usages
- en utilisant
- les services publics
- utilisé
- divers
- vérifier
- version
- Versus
- vertical
- via
- viable
- visualiser
- vs
- souhaitez
- était
- we
- web
- services Web
- Site Web
- WELL
- Quoi
- Qu’est ce qu'
- quand
- Les
- que
- qui
- tout en
- WHO
- large
- Large gamme
- sera
- fenêtre
- fenêtres
- comprenant
- dans les
- sans
- Word
- des mots
- activités principales
- travailler ensemble
- travaillé
- de travail
- vos contrats
- world
- pourra
- années
- Rendement
- Vous n'avez
- Votre
- zéphyrnet