Partager via

Plateforme de données pour les charges de travail IA sur Azure

  • Article

Une plateforme de données est un ensemble intégré de technologies conçues pour gérer les exigences de charge de travail en ingérés les données sources, puis en filtrant, en les agrégeant et en les préparant pour la consommation.

Les données ont des caractéristiques distinctes basées sur son utilisation prévue. Nous vous recommandons vivement de comprendre les principes de conception de pipeline de données appropriés avant d’explorer les fonctionnalités technologiques décrites par cet article. Pour plus d’informations, consultez Conception des données d’entraînement et conception de données grounding.

La plateforme répond également aux besoins de stockage lorsque les données reposent à certains points du pipeline. Si la charge de travail est complexe et gère des données à grande échelle, vous pouvez distribuer des tâches de pipeline entre différents composants. Pour des cas d’usage plus simples, déterminez si vous pouvez utiliser les données sources dans un magasin qui offre ces fonctionnalités combinées.

Posez-vous les questions suivantes pour éviter de concevoir une architecture trop complexe pour votre plateforme de données. Il est toujours préférable de garder les choses simples quand vous pouvez.

  • Votre application peut-elle disposer de la puissance prédictive attendue en ingérée des données à partir d’une seule source ?
  • Votre choix initial de magasin de données prend-il en charge les fonctionnalités d’entreposage de données ?
  • Les données sources sont-elles déjà optimisées pour les recherches ia ?

Si vous répondez oui à ces questions, vous pouvez simplifier votre architecture en permettant à l’application d’accéder directement à la source de données. Cette approche élimine le besoin de composants d’architecture Big Data tels que l’ingestion des données, l’intégration du magasin analytique et le traitement des données externes. Si la base de données source peut gérer les recherches requises, l’intégration de la fonctionnalité d’index de recherche directement dans la base de données source peut être une approche pratique. Assurez-vous que la source peut être mise à l’échelle rentable pour répondre à de nouvelles demandes.

Par exemple, Azure Cosmos DB prend en charge la recherche vectorielle. Vous n’avez donc peut-être pas besoin d’un autre index. Un autre cas d’usage consiste à utiliser des réplicas en lecture comme points de terminaison pour les opérations de recherche. Pour les bases de données SQL qui ont des réplicas en lecture, les recherches directes vers ces réplicas peuvent optimiser les performances. Tirez parti des fonctionnalités intégrées de la base de données pour simplifier autant que possible l’architecture.

Une architecture de plateforme de données pour les charges de travail à grande échelle est plus complexe.

L’ingestion de données à partir de plusieurs sources de données et l’orchestration de recherches sur différentes plateformes peuvent devenir complexes et inefficaces. En outre, vous avez toujours besoin d’extraire, de transformer et de charger (ETL) ; extraire, charger et transformer (ELT) ; ou extraire et charger (EL) des processus pour remodeler les données dans le magasin de données. Le scénario devient plus complexe, car les données nécessitent davantage de traitement. Vous devez ajouter de nombreux composants à l’architecture pour gérer le pipeline de bout en bout de l’ingestion vers le service des requêtes. De nombreuses technologies Big Data sont hautement spécialisées et conçues pour gérer efficacement ces tâches de traitement.

L’une de ces technologies est l’index de recherche. L’avantage principal de l’ajout d’un index distinct est sa capacité à gérer efficacement les requêtes et à traiter de grands volumes de données qui ont un débit élevé. Cette fonction décharge les fonctionnalités IA de la source de données d’origine afin que l’index puisse se concentrer sur sa fonction principale, en servant des requêtes.

Choisissez une plateforme basée sur ses fonctionnalités et son objectif spécifiques, et tenez compte de vos exigences fonctionnelles et techniques. Si votre architecture évolue pour gérer des cas d’usage complexes, concentrez-vous sur les sections suivantes sur les magasins de données agrégés, les pipelines de traitement et les index de recherche.

Recommandations

Voici le résumé des recommandations fournies dans cet article.

Recommandation Description
Créez des magasins de données sécurisés, performants et rentables. Une partie clé de votre plateforme de données est un magasin de données qui agrège les données de plusieurs sources et permet l’intégration à différentes tâches d’intégration. Cela permet à votre charge de travail d’effectuer à grande échelle. Veillez à passer en revue les différentes exigences fonctionnelles et non fonctionnelles de votre magasin de données pour garantir un déploiement économique.

▪ Considérations relatives au stockage des données agrégées
Suivez les bonnes pratiques pour l’ingestion et le traitement des données. Les données de haute qualité permettent d’améliorer la fiabilité de votre charge de travail et de l’expérience utilisateur final. Tenez compte des exigences de votre charge de travail ainsi que des meilleures pratiques clés pour créer des processus d’ingestion et de transition de données efficaces qui aident à maintenir une barre de haute qualité.

▪ Considérations relatives au traitement des données
Concevoir des index de recherche fiables et pertinents. Visez un magasin de données en lecture seule et performant qui gère efficacement les requêtes impromptu et approximatives, fournissant des résultats pertinents à votre base d’utilisateurs, même si les requêtes ne sont pas précises.

▪ Considérations relatives à un index de recherche
Vérifiez que les magasins de données fonctionnels s’exécutent à grande échelle. Selon les exigences fonctionnelles de votre charge de travail, vous devrez peut-être créer des magasins de données fonctionnels, par exemple pour l’inférence hors connexion. Il est important de créer des magasins de données avec leur fonction désignée à l’esprit et d’appliquer les meilleures pratiques pour la fonction.

▪ Considérations relatives à un magasin de fonctionnalités
▪ Considérations relatives à un magasin de données d’inférence hors connexion

Considérations relatives au stockage des données agrégées

Dans les charges de travail IA, les données passent par différentes phases de stockage et de traitement à l’aide de pipelines qui orchestrent le flux de travail entre ces phases. Une étape clé est un magasin de données qui contient des données ingérées et agrégées à partir de plusieurs sources. Vous avez besoin de ce magasin pour effectuer le traitement jusqu’à ce que les données atteignent un état approprié pour l’apprentissage ou l’indexation. Le principal objectif est de s’assurer que les données reflètent avec précision sa source.

Remarque

Une autre approche consiste à accéder directement aux sources de données. Toutefois, cette approche peut entraîner des problèmes de performances, car elle peut surcharger les systèmes sources avec des fonctionnalités IA. Il peut également y avoir des problèmes d’accès aux données. Pour éviter ces problèmes, nous vous recommandons de copier des données dans ce magasin.

La plateforme de données de ce magasin doit respecter les normes de sécurité appliquées aux sources de données, être rentable et prendre en charge l’intégration aux tâches de traitement ETL, ELT et EL. Les options varient du stockage de base aux technologies Big Data en fonction du volume de données. Choisissez un stockage économique qui vous permet d’obtenir suffisamment de fiabilité et de performances.

La section suivante fournit des conseils sur les fonctionnalités à prendre en compte lorsque vous sélectionnez une technologie de magasin de données. Pour plus d’informations, consultez pipelines de traitement des données.

Besoins fonctionnels

  • La plateforme peut-elle gérer différents formats de données ?

    Le magasin de données doit pouvoir stocker différents formats de données et les transformer en d’autres formats si nécessaire.

    Supposons que vos données de pipeline d’ingestion proviennent d’une base de données relationnelle et d’un fichier Parquet, de sorte qu’elles prennent en charge les données structurées et semi-structurées. Vous souhaitez convertir des données relationnelles au format Parquet conformément à ses définitions de schéma. La plateforme de données doit avoir des fonctionnalités intégrées pour effectuer cette transformation sans écrire de code personnalisé.

  • Pensez-vous stocker plusieurs versions des données ?

    Les valeurs et schémas de données peuvent changer au fil du temps, et la gestion de plusieurs versions des données devient importante.

    Les systèmes sources stockent généralement uniquement les données actuelles, et non les données historiques. S’il est important de conserver les données historiques, vous devrez peut-être dupliquer des jeux de données volumineux à partir de systèmes sources. Dans ce cas, le contrôle de version peut lever l’ambiguïté des données actuelles des données historiques.

    Dans certains cas, vous devrez peut-être conserver des copies de données pour différents cas d’usage. Pour prendre en charge ce scénario, vous devrez peut-être fourcher des données. Chaque fourche peut muter indépendamment pour améliorer sa qualité et sa facilité d’utilisation. Votre plateforme de données doit être en mesure de gérer le contrôle de version approprié de ces fourche.

    Votre plateforme de données doit être en mesure de stocker des versions de données au fil du temps pour fournir un contexte historique. Ce texte contetxt est bénéfique pour le traitement et l’apprentissage des modèles IA, car il offre plusieurs observations plutôt qu’un seul point dans le temps.

  • La plateforme dispose-t-elle de fonctionnalités intégrées de gestion du cycle de vie des données ?

    La gestion du cycle de vie des données (DLM) est un processus de gestion des données de sa création à sa suppression, avec des étapes telles que la collecte de données, le stockage, l’utilisation, l’archivage et la suppression.

    Sans DLM, les données peuvent croître incontrôlablement, ce qui entraîne souvent plusieurs copies au fur et à mesure qu’elles passent par des niveaux de qualité. La plateforme de données doit disposer de fonctionnalités DLM pour empêcher la croissance des données non liées.

    Tenez compte de ce scénario. L’étape de prétraitement doit se répéter pour affiner les données jusqu’à ce qu’elles atteignent une qualité acceptable à des fins d’entraînement. Votre plateforme de données doit pouvoir supprimer des copies intermédiaires des données.

    Dans certains cas, vous devrez peut-être conserver les données pour les audits réglementaires. La plateforme de données doit disposer de fonctionnalités de stockage à froid pour les données rarement sollicitées afin de pouvoir les archiver à moindre coût.

  • La plateforme prend-elle en charge les fonctionnalités de gouvernance des données ?

    L’auditabilité est un aspect important pour les charges de travail IA. Le magasin de données doit gérer les pistes d’audit qui peuvent suivre l’accès aux données, garantir la confidentialité et comprendre les origines des données.

    Utilisez une fonctionnalité de dictionnaire de données pour gérer les métadonnées, les types de données, les objectifs et la traçabilité. Cette fonctionnalité est particulièrement importante lorsque les données sont ingérées à partir de plusieurs sources.

  • Prévoyez-vous d’effectuer une formation avec des données de production ?

    Il existe deux approches pour les déploiements, le déploiement de modèles et le déploiement de code. Dans le déploiement de modèles, les données de production sont utilisées dans le développement, ce qui nécessite des mesures de sécurité strictes. Dans le déploiement de code, le modèle ne voit pas les données de production tant qu’il n’est pas en production. Bien que le déploiement de code simplifie les problèmes de sécurité dans l’environnement de développement, il peut augmenter les coûts de calcul. Quelle que soit l’approche choisie, votre plateforme de données doit prendre en charge des environnements distincts pour le développement et la production.

  • Vous hiérarchisez les fonctionnalités pratiques par rapport aux fonctionnalités fonctionnelles clés ?

    Lorsque vous choisissez une plateforme de données pour l’IA ou le Machine Learning, ne vous appuyez pas uniquement sur ses fonctionnalités de notebook. Bien que les notebooks soient utiles pour l’analyse exploratoire des données, ils ne doivent pas être le facteur déterminant. Les ressources de calcul pour les notebooks sont généralement en dehors de l’étendue du magasin de données d’agrégation. Elles sont généralement intégrées à d’autres ressources, telles qu’Azure Machine Learning.

Exigences non fonctionnelles

  • Quelle quantité de données prévoyez-vous de stocker ?

    Les charges de travail IA génèrent beaucoup de données. Le volume peut augmenter considérablement en raison de plusieurs versions et de métadonnées supplémentaires.

    L’extensibilité pour le stockage et le débit est importante. La plateforme de données doit consommer efficacement des données à partir du pipeline d’ingestion pendant qu’elle gère le volume de données, gère les écritures simultanées et garantit des performances d’écriture individuelles sans dégradation. Ces critères s’appliquent également au pipeline de traitement qui lit, traite et réécrit même dans le magasin.

    Lorsque vous prenez une décision, tenez compte de l’ensemble du processus, car l’ingestion et le traitement se produisent souvent simultanément. La conception doit être en mesure de gérer les déplacements et le traitement fréquents des données. La plateforme de données doit offrir des niveaux élevés de parallélisme pour traiter efficacement les données.

    La technologie de plateforme doit émettre des données de télémétrie qui donnent un aperçu significatif du débit et des performances des opérations de lecture et d’écriture.

  • Ce magasin de données est-il un composant critique qui contribue à la cible de fiabilité de la charge de travail ?

    Choisissez un magasin de données qui améliore la fiabilité et l’extensibilité à l’aide de plusieurs instances. Les magasins Big Data ont souvent un contrôleur intégré qui orchestre le traitement des données entre les instances. Si une copie échoue, une autre peut être utilisée.

    N’oubliez pas que les données ne servent pas leur objectif s’il n’est pas correct ou accessible. La plateforme de données doit garantir la durabilité et s’assurer que les données restent intactes. Assurez-vous que les API qui interrogent les données sont accessibles. En outre, tenez compte des magasins de données qui ont des fonctionnalités de sauvegarde.

    En général, vous n’avez pas besoin de sauvegarder ces données. Toutefois, si le coût de l’agrégation des données à chaque fois à partir de zéro est considérablement élevé, vous pouvez envisager de réhydrater les données à partir d’une sauvegarde.

  • Avez-vous des contraintes de coût ?

    Si la fiabilité et les performances des données sont suffisantes, tenez compte de l’impact sur les coûts.

    Le système doit être optimisé pour l’écriture une seule fois, en lisant plusieurs pour éviter les dépenses excessives sur le stockage des données. Les données d’entraînement ou de base sont importantes, mais pas critiques comme une base de données de production, ce qui nécessite une réactivité instantanée. L’accent est mis sur l’équilibrage des coûts avec une efficacité suffisante pour maximiser le retour sur investissement.

Les exigences précédentes peuvent naturellement vous amener à envisager d’utiliser un lac de données, car il offre des niveaux de qualité, une observabilité et une prise en charge de différents formats de fichiers. Si votre charge de travail utilise déjà un lac de données, tirez parti de cette ressource pour répondre à vos besoins ia. Vous pouvez également choisir d’autres options de stockage, telles que Stockage Blob Azure, qui fournissent un certain niveau de DLM, de fonctionnalités de supervision et de taux de transaction élevés.

Considérations relatives au traitement des données

Vous devez traiter les données dans le magasin de données d’agrégation pour augmenter son utilitaire en aval. Les pipelines ETL effectuent cette tâche, ce qui est le plus important aux points suivants :

  • Couche d’ingestion

    Le pipeline est chargé de collecter des données à partir de différentes sources et de les déplacer vers le magasin de données agrégé. Pendant ce processus, le pipeline effectue généralement un prétraitement de base et peut même structurer les données dans un format interrogeable.

    Pour réduire le besoin de code personnalisé, nous vous recommandons de décharger une grande partie de cette responsabilité sur une plateforme de données. Lorsque vous sélectionnez une technologie, tenez compte des caractéristiques ETL requises pour prendre en charge la formation et l’augmentation du modèle.

  • Couche de traitement

    Les données du magasin de données agrégées subissent un traitement approfondi avant de pouvoir être utilisées pour l’indexation ou les cas d’utilisation de l’entraînement de modèle. Le pipeline de traitement nécessite des niveaux de fiabilité et de mise à l’échelle similaires au pipeline d’ingestion. La principale différence est le type de traitement effectué sur les données.

    Le processus implique une rescoping et une restructuration significatives des données. Ce processus inclut des tâches telles que la reconnaissance d’entité, l’intégration de données supplémentaires dans le jeu de données et l’exécution de recherches. Ce processus peut également inclure la suppression de données inutiles et l’application d’une logique de données via une plateforme d’orchestration de données.

La phase de traitement des données peut produire différentes sorties, qui atterrissent dans différentes destinations pour différentes intentions. Son objectif principal est de préparer et de transférer des données à partir du magasin de données agrégé pour la consommation par la destination finale. Le consommateur peut extraire des données si nécessaire, ou la couche de traitement peut envoyer (push) des données lorsqu’elles sont prêtes.

Remarque

Dans le contexte de l’apprentissage automatique et de l’IA générative, il est important de faire la distinction entre les processus ETL, ELT et EL. L’ETL traditionnel est essentiel pour l’entreposage de données et les mappages relationnels d’objets, où, en raison des restrictions de schéma, les données doivent être transformées avant de les charger dans le système cible. ELT implique d’extraire des données, de les charger dans un lac de données, puis de les transformer à l’aide d’outils tels que Python ou PySpark. Dans l’IA générative, en particulier pour la génération augmentée par récupération (RAG), le processus implique souvent l’extraction et le chargement de documents dans le stockage en premier, suivis de transformations telles que l’extraction de blocs ou d’images.

La section suivante fournit des conseils à prendre en compte lorsque vous sélectionnez une technologie de traitement des données qui dispose de fonctionnalités ETL.

Besoins fonctionnels

  • Quelle est la prise en charge de la connexion aux sources de données ?

    Les données qui doivent être traitées peuvent être stockées dans des bases de données relationnelles, des sources big data ou différentes solutions de stockage.

    La plupart des technologies de traitement des données prennent en charge les intégrations prédéfinies qui vous permettent de vous connecter à différentes sources de données sans écrire de code. Les connecteurs ont des fonctionnalités telles que la possibilité de copier des données d’une source vers un récepteur, d’effectuer des recherches et d’appliquer une certaine forme de gouvernance des données. Il existe des outils qui offrent des fonctionnalités de glisser-déplacer pour éviter le codage inutile.

    Choisissez une plateforme de données qui facilite l’intégration aux sources de données attendues.

  • La plateforme peut-elle traiter différents formats de données ?

    Les données peuvent se présenter dans différents formats, tels que des données structurées telles que des bases de données et JSON, des données non structurées telles que des images et des documents, ou des données de streaming telles que des données provenant d’appareils Internet des objets. Les pipelines doivent être en mesure de gérer les types de fichiers attendus.

  • La plateforme offre-t-elle des fonctionnalités pour la préparation et la rescoping des données ?

    Vous devez traiter les données que vous envisagez d’utiliser pour l’entraînement ou l’augmentation jusqu’à ce qu’elles conviennent à l’entraînement, au réglage précis ou à l’indexation. Vos stratégies de conception de données doivent décrire explicitement les exigences.

    Les articles suivants décrivent des considérations spécifiques :

    Dans le cadre du nettoyage de base, la plateforme supprime les doublons, remplit les valeurs manquantes et élimine le bruit superflu pendant l’ingestion. Pour certains cas d’usage, tels que l’implémentation d’un modèle RAG, nous vous recommandons d’utiliser des blocs minuscules.

    Bien que ces étapes de prétraitement soient nécessaires, la plateforme doit également prendre en charge une manipulation de données enrichie spécifique à vos besoins. Ce processus implique le chargement, la rescoping et la transformation des données. Pour certains modèles, la plateforme doit pouvoir interroger des sources externes pour l’analyse des documents, telles que l’intelligence de document ou d’autres outils IA. Ce travail est nécessaire pour préparer les données et pour l’enrichissement des données.

    Si votre magasin de données prend en charge ce niveau de traitement, vous pouvez localiser cette étape dans le magasin sans le déplacer ailleurs. Sinon, vous avez besoin d’une technologie externe telle qu’Azure Databricks ou Azure Data Factory. Ces technologies conviennent au déplacement des données et à l’exécution de manipulations, telles que le filtrage, le remplissage de valeurs manquantes et la normalisation de la casse de chaîne. Pour les tâches plus complexes, une plateforme d’hébergement de travaux est généralement nécessaire. Vous pouvez utiliser des pools Spark pour l’orchestration big data.

    Dans certains cas d’usage, vous souhaiterez peut-être externaliser cette responsabilité au consommateur des données. Par exemple, les modèles IA qui utilisent le Machine Learning offrent des fonctionnalités de traitement des travaux pour lire, manipuler et écrire des données à l’aide du code Python personnalisé.

    Un autre exemple est l’implémentation de RAG. Une étape de traitement courante consiste à segmenter, où un document est divisé en plusieurs blocs, et chaque bloc devient une ligne dans l’index. Il stocke également les incorporations, qu’un service OpenAI génère souvent, pour ces blocs. Dans les recherches PAR IA, ce processus est orchestré dans le flux de travail d’indexation, que ce soit à l’aide d’OpenAI ou d’Azure AI Search.

  • Existe-t-il un orchestrateur intégré pour la gestion des flux de travail ?

    Les tâches de traitement sont modulaires et exécutées en tant que travaux. La plateforme doit disposer de fonctionnalités d’orchestration qui décomposent le flux de travail en étapes ou en travaux. Chaque travail doit être défini, exécuté et surveillé indépendamment.

    Dans les flux de travail complexes, certaines étapes dépendent de l’achèvement réussi des flux de travail précédents. L’orchestrateur doit gérer les dépendances de travail et s’assurer que les tâches sont terminées dans l’ordre approprié.

    La conception des données est un processus itératif. L’outil d’orchestrateur doit donc être suffisamment flexible pour modifier facilement les flux de travail. Vous devez être en mesure d’injecter de nouvelles étapes ou d’ajuster les étapes existantes sans réécrire de grandes parties du code.

    Data Factory est un choix populaire, car il fournit un ensemble de fonctionnalités riche pour la gestion des flux de travail de données. Azure Databricks peut également gérer des flux de travail complexes et planifier et surveiller des travaux. Vous devez également prendre en compte les implications sur les coûts. Par exemple, les fonctionnalités d’Azure Databricks peuvent être étendues, mais elles sont également coûteuses. Une autre option open source, telle qu’Apache NiFi, peut être plus rentable.

    En fin de compte, l’outil que vous choisissez dépend de ce que votre organisation permet et des compétences que l’équipe de charge de travail est à l’aise avec.

Exigences non fonctionnelles

Lorsque vous choisissez un pipeline de traitement, il est essentiel d’équilibrer le débit et l’observabilité. Le pipeline doit traiter et atterrir de manière fiable les données nécessaires pour les modèles ou les index dans un délai suffisant. Il doit être suffisamment léger pour prendre en charge vos besoins actuels et être évolutif pour une croissance future. Teams doit décider de la quantité dont ils ont besoin pour vérifier à l’avenir la plateforme afin d’éviter la dette technique ultérieurement. Les principales considérations incluent la fréquence et le volume d’ingestion des données, la fiabilité du processus et la nécessité d’observer l’observabilité pour surveiller et résoudre rapidement les problèmes.

  • Quelle quantité de données prévoyez-vous d’ingérer ?

    Pour les phases d’ingestion et de traitement, tenez compte de la scalabilité et de la vitesse de la plateforme pour la gestion des tâches. Par exemple, vous prévoyez de charger 10 téraoctets de données quotidiennement dans un index ou pour l’entraînement du modèle. Votre plateforme d’ingestion de données doit être en mesure de traiter ce volume et avec le débit attendu. Dans ce cas, l’utilisation d’Azure Logic Apps peut ne pas être réalisable, car elle peut échouer sous une telle charge. Au lieu de cela, Data Factory est mieux adapté à cette échelle de traitement des données.

    Une façon de gérer un volume élevé est parallélisme, car elle permet une gestion et un traitement des données plus efficaces. Les plateformes telles qu’Azure Databricks peuvent orchestrer des tâches en créant plusieurs instances pour le même travail et en distribuant la charge efficacement.

    Considérez également la latence tolérable et la complexité des travaux. Par exemple, le nettoyage des données implique la validation et le remplacement potentiellement des champs non valides ou le masquage des informations sensibles. Ces tâches, bien que de base, nécessitent des ressources importantes, car chaque ligne est traitée individuellement, ce qui ajoute au temps global.

  • Quelles fonctionnalités de supervision avez-vous besoin ?

    Les pipelines de traitement des données doivent avoir des fonctionnalités de surveillance et fournir des insights sur les performances et l’état des travaux du pipeline.

    Vous devez être en mesure de suivre la progression des travaux. Supposons que le pipeline exécute un travail de nettoyage des données qui ne se termine pas ou se termine partiellement. Il peut y avoir un impact en aval sur la qualité des données avec lesquelles le modèle est entraîné, ce qui peut affecter la puissance prédictive.

    Comme pour d’autres composants de la charge de travail, vous devez activer les journaux, les métriques et les alertes sur le pipeline de données pour comprendre son comportement. Collectez et analysez les métriques de performances pour comprendre les aspects d’efficacité et de fiabilité.

    Identifiez les lacunes dans les données de télémétrie intégrées et déterminez quelle surveillance supplémentaire vous devez implémenter. Cette surveillance peut impliquer l’ajout de métriques ou de journalisation personnalisées pour capturer des détails spécifiques sur les étapes du travail.

  • Quelle fiabilité attendez-vous de la plateforme de traitement des données ?

    La fiabilité d’un pipeline de traitement des données varie en fonction du choix de la plateforme. Même si Logic Apps dispose de fonctionnalités d’orchestration, il peut ne pas être aussi fiable que Data Factory. Data Factory, hébergé sur un cluster Azure Kubernetes Service (AKS), peut avoir des caractéristiques de fiabilité différentes.

    Les configurations à instance unique sont considérées comme des points d’échec. Choisissez une plateforme qui prend en charge les fonctionnalités de fiabilité, telles que plusieurs instances, pour répondre à vos besoins.

    La plateforme doit également prendre en charge les fonctionnalités de résilience. Par exemple, l’orchestrateur doit réessayer automatiquement une tâche ayant échoué, ce qui réduit le besoin de redémarrages manuels.

    Le traitement par lots peut être moins fiable que l’inférence, en fonction des exigences de fraîcheur et de latence des données. Si la formation se produit chaque semaine et que le traitement prend un jour, les échecs occasionnels sont acceptables, car il y a suffisamment de temps pour réessayer.

  • Existe-t-il des contraintes de coût ?

    Lorsque vous envisagez l’efficacité d’un pipeline de traitement des données, il est important de choisir une solution qui répond à vos besoins sans frais inutiles. Si vos exigences ne justifient pas les fonctionnalités avancées d’Azure Databricks, une option plus économique comme Data Factory peut être suffisante. En outre, les outils open source comme Apache Airflow ou Apache NiFi peuvent fournir des fonctionnalités robustes à moindre coût. La clé est d’éviter les dépenses excessives sur les fonctionnalités dont vous n’avez pas besoin et de sélectionner une plateforme qui équilibre les fonctionnalités et l’efficacité des coûts.

  • Quelles sont les exigences de sécurité sur les flux de travail et sur les données que vous traitez ?

    Soyez clair sur les exigences de sécurité, de confidentialité et de résidence des données. Par exemple, tenez compte des exigences réglementaires géographiques. Respectez les exigences de résidence des données en veillant à ce que les données soient stockées et traitées dans des régions spécifiques. Vous devrez peut-être exécuter des pipelines distincts pour différentes régions, comme l’une pour l’Europe et l’autre pour l’Amérique, afin de respecter les réglementations locales en matière de conformité.

    La plateforme de pipeline de données doit prendre en charge la gestion des identités et des accès pour s’assurer que seules les identités autorisées ont accès à des travaux ou étapes spécifiques dans les flux de travail. Par exemple, si votre processus ETL se compose de plusieurs flux de travail et qu’un d’eux gère des données hautement confidentielles, la plateforme doit vous permettre de restreindre l’accès à ce flux de travail tout en gardant les autres accessibles. Cette fonctionnalité vous aide à répondre aux exigences de sécurité sans avoir besoin de plateformes distinctes pour différents niveaux de confidentialité des données. Dans l’idéal, la plateforme doit fournir une prise en charge intégrée pour une telle isolation qui permet une gestion efficace et sécurisée des données.

Les pipelines de traitement des données peuvent générer les données vers un index de recherche ou un pipeline d’entraînement de modèle. Selon le cas d’usage, consultez les sections sur les index de recherche ou les magasins de fonctionnalités.

Considérations relatives à un index de recherche

L’index de recherche est conçu pour stocker les données contextuelles ou de base à envoyer au point de terminaison d’inférence du modèle, ainsi que l’invite. Les deux appels, la requête d’index et l’appel de point de terminaison d’inférence se produisent dans le contexte de la maintenance des mêmes requêtes HTTP clientes. Contrairement aux processus ETL qui gèrent des travaux hors connexion et par lots, cet index prend en charge l’inférence en temps réel, ce qui nécessite des performances et une fiabilité élevées. Il est spécialisé pour les requêtes IA et offre des fonctionnalités telles que l’indexation et le filtrage de mots clés, qui ne sont pas typiques des magasins Big Data. L’objectif est d’avoir un magasin de données haute performance, en écriture seule et en lecture seule qui prend en charge les requêtes imromptu et approximatives. Ce magasin de données peut fournir des résultats pertinents sans requêtes précises.

Besoins fonctionnels

  • Quels types de recherche l’index de recherche prend-il en charge ?

    Les requêtes reçues par le système sont essentiellement des recherches, et l’index doit prendre en charge des fonctionnalités de recherche enrichies. Pour RAG, la recherche vectorielle n’est pas modifiable, car les données sont stockées sous forme de vecteurs calculés ou d’incorporations, qui sont utilisées pour la recherche.

    La recherche vectorielle est puissante et la combine avec le filtrage et la recherche en texte intégral améliore l’efficacité de l’index de recherche. Votre conception de données doit tenir compte de la combinaison de ces types de recherches, tels que vector, recherche en texte intégral, filtrage et types de données spéciaux tels que la géolocalisation.

    Votre conception de données doit indiquer explicitement ces exigences. Pour plus d’informations, consultez Interrogation efficace dans la conception des données.

  • L’index prend-il en charge les données modales ?

    Choisissez les technologies d’index qui prennent en charge les données modales. Par exemple, les recherches IA peuvent analyser un e-mail, convertir une image dans celle-ci en vecteurs et stocker la description dans l’index. Utilisez cette fonction pour effectuer des recherches dans différentes modalités de contenu, notamment des images, des vidéos et des fichiers audio.

  • L’index prend-il en charge les fonctionnalités de mise à jour automatique lorsque les données des sources de données changent ?

    Choisissez un index doté de fonctionnalités de mise à jour automatique. Si l’un n’est pas disponible, vous devez détecter et envoyer manuellement des modifications à l’index. Avec ces fonctionnalités, l’indexeur peut détecter automatiquement les modifications apportées aux sources de données et extraire les mises à jour. En déchargeant cette responsabilité sur la plateforme, vous pouvez réduire la surcharge opérationnelle et simplifier le processus de maintenance.

Exigences non fonctionnelles

  • L’index peut-il s’exécuter avec de grands volumes de données ?

    L’index doit être en mesure de gérer de grandes quantités de données, d’être évolutifs et de fonctionner correctement pour les charges de travail de recherche lourdes. L’index stocke les données brutes et toutes les métadonnées, enrichissements et entités qui y sont associés. Dans le contexte du modèle RAG, un document unique divisé en plusieurs blocs peut entraîner une augmentation significative du volume de données.

  • L’index a-t-il des fonctionnalités de fiabilité intégrées ?

    Considérez l’alignement entre la fiabilité du point de terminaison d’inférence, ou le modèle, et le magasin de données, car ils dépendent les uns des autres.

    Le processus de recherche implique deux étapes : interroger le magasin de données, puis interroger le point de terminaison d’inférence. Les deux étapes doivent avoir des caractéristiques de fiabilité similaires. Équilibrez vos objectifs de fiabilité entre les deux composants pour garantir l’efficacité de la recherche.

    Pour garantir la résilience, la charge de travail doit prendre en charge le nombre attendu d’utilisateurs simultanés et disposer d’une bande passante suffisante pour gérer les pics de trafic. Dans l’idéal, la plateforme doit survivre aux pannes zonales.

    La plateforme de données doit être conçue pour empêcher l’utilisation d’un index endommagé pour l’inférence. Dans ce cas, vous devez être en mesure de reconstruire facilement l’index. L’index doit également prendre en charge l’échange fiable entre les index à l’aide de fonctionnalités telles que l’alias pour réduire les temps d’arrêt pendant les échanges d’index. Sans cette fonctionnalité, vous devrez peut-être vous appuyer sur une sauvegarde de l’index. La gestion d’une sauvegarde est plus complexe.

    Du point de vue de la charge de travail, comprenez les modes d’échec potentiels ou les indicateurs de stress, tels que la limitation. Par exemple, bien que le système puisse normalement prendre en charge 50 utilisateurs simultanés, il peut uniquement prendre en charge 30 utilisateurs pendant un processus de réindexation qui s’exécute en tant que travail en arrière-plan. Dans ce cas, le minutage du travail en arrière-plan devient important. Lorsque vous évaluez le débit d’un index, incluez à la fois des requêtes frontales et des travaux principaux.

  • Quels sont les principaux facteurs de coût de cette technologie ?

    Lorsque vous modélisez les coûts, estimez les dépenses associées au volume de données, au nombre de requêtes et au débit attendu de l’index. N’oubliez pas que les index sont principalement des plateformes en tant que service (PaaS), où la tarification est abstraite. Niveaux de recherche et leurs capacités pour éviter le surpayement pour la capacité ou les fonctionnalités inutilisées.

    Par exemple, la recherche IA facture en tant qu’unités, ce qui peut inclure la capacité, le débit et le stockage. Des fonctionnalités supplémentaires peuvent entraîner des frais supplémentaires. Par exemple, une utilisation intensive des fonctionnalités d’extraction d’images peut entraîner une facture élevée. Les dépendances, telles que la fonctionnalité d’ensemble de compétences, qui se trouvent en dehors de l’étendue de l’index, mais qui font partie du traitement des données peuvent entraîner des coûts supplémentaires.

    Le paiement d’un niveau sans utiliser la capacité totale peut entraîner un surpayement. De même, le nombre de tables de votre index et la possibilité de gérer le trafic simultané affectent les coûts.

    Pour comprendre les coûts associés à la recherche IA, consultez Planifier et gérer les coûts d’un service Search IA.

  • Les fonctionnalités de sécurité de l’index répondent-elles à votre conception des données de sécurité ?

    Votre conception de données doit clairement spécifier les exigences de sécurité et de confidentialité. Dans les environnements de développement et de test où des données de production réelles sont utilisées, l’index doit prendre en charge les fonctionnalités conformes à tous les contrôles d’accès et mesures de traçabilité. Passez en revue les fonctionnalités de sécurité telles que le masquage des données et la suppression d’informations personnelles dans l’index.

    Choisissez un index qui a la possibilité d’identifier de manière unique les clients via l’ID Microsoft Entra. L’index de recherche doit également prendre en charge les contrôles d’accès au niveau du document pour permettre l’interrogation de la pertinence par les identités. Si l’index n’offre pas ces fonctionnalités, ajustez votre conception pour obtenir des fonctionnalités similaires avec des filtres de requête. Pour plus d’informations, consultez Filtres de sécurité pour réduire les résultats dans la recherche IA.

    Dans l’idéal, l’index de recherche doit s’aligner sur les exigences de sécurité réseau. Par exemple, si vous devez filtrer le trafic de sortie vers des sites non-Microsoft et maintenir l’observabilité, l’index doit offrir des contrôles de sortie. Il doit également prendre en charge la segmentation du réseau. Si le calcul principal se trouve dans un réseau virtuel, une connectivité privée pour les composants clés, y compris l’index, est essentielle pour éviter l’exposition à l’Internet public. L’index doit facilement s’intégrer à des réseaux privés et prendre en charge les identités managées pour l’authentification via l’ID Microsoft Entra.

Considérations relatives à un magasin de fonctionnalités

Pour les modèles discriminatifs, votre conception de données peut inclure un magasin de données intermédiaire qui met en cache les données pour un affinement supplémentaire. Ce magasin, appelé magasin de fonctionnalités, permet aux scientifiques des données de stocker les fonctionnalités en tant qu’étape finale, en dehors du magasin de données agrégé.

Le magasin de fonctionnalités permet de cataloguer des données pour plusieurs utilisations en ajoutant des métadonnées telles que l’heure de génération et l’origine. Ce spot d’atterrissage intermédiaire est idéal pour les données d’entraînement d’or.

Le magasin de fonctionnalités géré dans Machine Learning est une option de stockage de données qui s’intègre à MLflow et à d’autres outils. Il extrait et entraîne des données à partir du magasin de données d’agrégation, en ajoutant une couche réutilisable pour améliorer la traçabilité des données et l’identification formelle dans Machine Learning.

Lorsque vous utilisez un magasin de fonctionnalités, traitez-le comme un magasin de données avec des considérations de sécurité et d’accès.

Considérations relatives à un magasin de données d’inférence hors connexion

Dans certains scénarios, l’utilisation d’un magasin distinct est appropriée pour accélérer les recherches futures, car l’inférence est effectuée sur les données pré-collectées et précalculées, à l’avance. Dans ce processus, la demande de l’utilisateur n’atteint jamais le modèle IA. Il existe plusieurs avantages :

  • Amélioration de l’efficacité et de l’expérience utilisateur en réduisant la latence. Les résultats sont servis plus rapidement pour les requêtes fréquentes, telles que la génération de FAQ en conséquence.
  • Les appels d’inférence peuvent être mis à l’échelle plus facilement en tant que processus par lots sans contraintes de traitement en temps réel.
  • Permet la prévalidation pour garantir la précision avant la production.
  • Étant donné que la requête n’est pas dirigée vers le point de terminaison d’interférence, elle réduit la charge, contribuant à la fiabilité de la charge de travail.
  • Cela peut être plus rentable, car il réduit le besoin de matériel hautes performances requis pour le traitement en temps réel.

Toutefois, cette approche n’est efficace que si vous pouvez prédire les requêtes possibles et une partie importante des prédictions sont censées être demandées par les utilisateurs. Pour les scénarios avec moins de requêtes répétées, un magasin d’inférence hors connexion peut être moins efficace.

Le magasin de données de ce scénario doit être optimisé pour les opérations de lecture, doit pouvoir gérer de grands volumes de données et fournir une récupération efficace. Il doit également être en mesure d’intégrer dans le magasin de données agrégé. N’importe quel magasin avec ces fonctionnalités peut être considéré, tel qu’Azure Cosmos DB, ou même un stockage de tables.

Ressources

Ces articles fournissent plus de détails sur les produits Azure que nous vous recommandons en tant qu’options technologiques pour les considérations décrites dans cet article.

Étapes suivantes

Zone de conception : MLOps et GenAIOps