Magasin de fonctions : l’interface pour tous vos pipelines de données d’IA

L’IA d’entreprise évolue au-delà des modèles individuels vers des écosystèmes de données unifiés.

À mesure que les entreprises étendent leurs initiatives d’IA, une opportunité intéressante se présente : la création d’une passerelle de données unifiée qui connecte chaque étape de votre pipeline d’IA, des données brutes au traitement informatique, en passant par les catalogues de fonctions et la diffusion des modèles. Il ne s’agit pas seulement de gérer la complexité, mais aussi de créer une base qui contribue à accélérer l’innovation.

L’un des défis récurrents auxquels les entreprises sont confrontées est que les spécialistes des données finissent par reconstruire les mêmes fonctions à maintes reprises. Une équipe calcule la valeur vie client pour un modèle de prédiction de perte de clientèle, et trois mois plus tard, une autre équipe a besoin du même calcul pour un moteur de recommandation, mais elle ne sait pas qu’il existe déjà. Ils le reconstruisent donc à partir de zéro, introduisant des incohérences et gaspillant des semaines de temps de développement.

Il s’agit du problème de réutilisation des fonctions, et cela coûte aux entreprises du temps et de la qualité.

Qu’est-ce qu’un magasin de fonctions ?

Un magasin de fonctions est une plateforme centralisée qui gère, stocke et dessert les fonctions de machine learning, c’est-à-dire les variables d’entrée que les modèles utilisent pour faire des prédictions. Considérez-le comme un catalogue de données spécialement conçu pour l’IA. Au lieu de parcourir la documentation ou de demander à leurs collègues « est-ce que quelqu’un a déjà calculé la vélocité d’achat mensuelle ? », les spécialistes des données peuvent découvrir, réutiliser et partager des fonctions dans l’ensemble de leurs projets de machine learning (ML).

Cependant, un magasin de fonctions ne se limite pas à cataloguer les fonctions. Il résout trois problèmes essentiels :

1. Réutilisation des fonctions : Il permet aux développeurs de découvrir et de réutiliser les fonctions existantes au lieu de les reconstruire de zéro.
2. Cohérence entre l’entraînement et le service : Il contribue à garantir la cohérence, de sorte que les modèles utilisent des calculs de fonctions identiques lors de l’entraînement et de la production (ce qui élimine le problème redouté « cela fonctionnait dans mon notebook »).
3. Simplicité opérationnelle : Il permet de gérer les pipelines de fonctions, le contrôle de version et la surveillance via une interface unique.

Red Hat OpenShift AI intègre une fonctionnalité de magasin de fonctions basée sur le projet Open Source Feast en tant que composant natif de la plateforme. Aucune installation séparée n’est nécessaire. Cette fonctionnalité est disponible et peut être activée lorsque vos équipes sont prêtes à adopter des pratiques de développement axées sur les fonctions.

L’opportunité d’une passerelle de données unifiée

Feast peut servir de couche d’accès unique et cohérente pour tous vos pipelines de données d’IA. Basé sur une fondation Open Source éprouvée avec plus de 6 500 étoiles GitHub et plus de seize millions de téléchargements, Feast connecte les sources de données, les moteurs de calcul (Ray/Spark) et les orchestrateurs (KFP/Airflow) dans un catalogue unifié, afin que les entreprises puissent créer des données indépendantes des fournisseurs.

Interface de pipeline : simplification des workflows de données d’IA complexes

Le magasin de fonctions de Red Hat OpenShift AI prend en charge cette approche unifiée :

• Base indépendante du fournisseur : S’intègre à Spark, Ray, Milvus, Elastic, Postgres et à de nombreuses autres bases de données courantes. Vous choisissez votre infrastructure.
• Visibilité complète du pipeline : Des données brutes à l’inférence de modèles en passant par l’ingénierie des fonctions
• Liberté de déploiement hybride : S’exécute de manière cohérente dans les environnements sur site, de cloud et de périphérie
• Innovation Open Source : Basée sur la base éprouvée de Feast avec plus de seize millions de téléchargements, utilisée et enrichie par de nombreuses entreprises, notamment Shopify, NVIDIA, Walmart, etc..

Cette approche permet également de résoudre de véritables défis d’entreprise. Les agences fédérales peuvent traiter des données sensibles sur site tout en tirant parti du cloud computing. Les établissements financiers peuvent répondre aux exigences de conformité tout en conservant une flexibilité opérationnelle. Les entreprises de fabrication peuvent traiter les données à la périphérie tout en se connectant à des analyses centralisées.

L’architecture à trois couches : données, calcul et catalogue

L’approche de Red Hat en matière de gestion des données d’IA repose sur un principe simple, mais puissant : les meilleures plateformes d’entreprise connectent l’infrastructure existante au lieu de la remplacer. Nous allons vous montrer comment cela fonctionne dans la pratique à travers l’histoire d’une entreprise de services financiers qui adopte les magasins de fonctions.

Couche 1 : sources de données — accéder à vos données là où elles se trouvent

Prenons l’exemple d’une grande banque qui met en œuvre la détection de fraude. Ses données clients sont stockées dans une base de données Oracle sur site (exigences de conformité réglementaire), les flux de transactions transitent par Kafka sur AWS (traitement moderne en temps réel) et les modèles historiques se trouvent dans un entrepôt de données Snowflake (investissement de l’équipe d’analyse il y a trois ans).

Les solutions traditionnelles de magasin de fonctions forcent un choix : tout migrer vers la plateforme ou ne pas utiliser du tout le magasin de fonctions. Cela crée une situation très difficile : la base de données Oracle ne peut pas être déplacée en raison de la conformité, l’équipe n’abandonnera pas son investissement Snowflake et les pipelines Kafka en temps réel sont essentiels aux opérations.

Le magasin de fonctions de Red Hat résout ce problème grâce à la connectivité universelle des données :

• Connexion universelle : Les fonctions peuvent extraire des données des bases de données sur site, du stockage cloud, des capteurs de périphérie et des plateformes de streaming, le tout dans la même définition de fonction.
• Préservation des investissements : L’équipe de détection de fraude continue d’utiliser son infrastructure existante sans coûts de migration ni perturbation opérationnelle.
• Maintien de la conformité : Les données clients sensibles restent dans la base de données sur site conforme, tandis que le magasin de fonctions orchestre l’accès contrôlé.

L’équipe de détection de fraude de la banque définit ses fonctions une seule fois : « customer_transaction_velocity_30d », « account_risk_score », « merchant_category_pattern » et le magasin de fonctions gère la complexité de l’extraction des données d’Oracle, de la jointure avec les flux Kafka et de l’enrichissement avec l’historique Snowflake. Les spécialistes des données n’écrivent plus d’instruction JOIN pour relier ces sources.

Couche 2 : traitement informatique — de la flexibilité pour chaque charge de travail

Voyons maintenant comment ces fonctions sont calculées. L’équipe de détection de fraude doit traiter des milliards de transactions quotidiennement, mais les différentes fonctions ont des besoins de calcul différents :

• Les agrégations simples (nombre de transactions) s’exécutent efficacement en SQL.
• La détection de modèles complexes (anomalies comportementales) nécessite Spark pour le traitement distribué.
• L’évaluation des risques en temps réel (latence inférieure à la seconde) nécessite un calcul de streaming léger.

La plupart des plateformes de fonctions vous enferment dans leur moteur de calcul préféré. Si vous avez investi dans l’expertise et l’infrastructure Spark, on vous dit de les abandonner et d’apprendre leur système propriétaire. Si vous avez besoin de Ray pour les transformations ML lourdes, vous n’avez pas de chance.

Le magasin de fonctions de Red Hat offre une flexibilité de calcul :

• Moteurs indépendants du fournisseur : Prise en charge native de Ray et Spark, ainsi que la possibilité d’apporter votre propre framework de calcul (Spark, Ray, etc.)
• Normes ouvertes : Fonctions définies à l’aide de Python et de SQL standard, et non de DSL propriétaires qui créent un verrouillage

L’équipe de détection de fraude exécute ses agrégations simples dans Postgres (déjà déployées), exécute des modèles comportementaux complexes dans son cluster Spark existant (préservant des années d’investissement dans l’infrastructure) et déploie des moteurs d’évaluation en temps réel dans les succursales pour une détection de fraude instantanée. Mêmes définitions de fonction, différentes stratégies de calcul basées sur les exigences métier.

Couche 3 : catalogue unifié — votre interface unique pour toutes les fonctions

C’est là que les défis commencent. L’équipe de détection de fraude a défini plus de cinquante fonctions tirant parti de trois sources de données et s’exécutant sur deux plateformes de calcul. Sans catalogue unifié, voici ce qui se passe :

• Les spécialistes des données perdent des heures à chercher dans les référentiels Git, les notebooks Jupyter et les connaissances de l’équipe pour essayer de déterminer si quelqu’un a déjà créé un calculateur de vélocité de transaction mensuelle.
• Lorsqu’ils trouvent une fonction, ils découvrent qu’elle est incompatible : noms de colonnes différents, horodatages différents, fenêtres d’agrégation différentes.
• Les ingénieurs de production ont du mal à comprendre les dépendances des fonctions : quelles fonctions dépendent de quelles sources de données et de quels travaux de calcul ?
• Les responsables de la conformité ne peuvent pas répondre à la question « qui a accès aux fonctions clients sensibles ? »

Le catalogue unifié (Feast) résout tous ces problèmes :

• Interface unique : Les spécialistes des données découvrent les cinquante fonctions via une seule interface de recherche : pas de recherche dans les référentiels ni de questions dans Slack.
• Visibilité complète du pipeline : Chaque fonction indique exactement d’où proviennent les données, quel calcul elle nécessite et quels modèles la consomment.
• Gouvernance prête pour l’entreprise : Le contrôle d’accès basé sur les rôles (RBAC) intégré signifie que seules les équipes autorisées ont accès aux fonctions sensibles, des pistes d’audit complètes suivent chaque accès et les flux de travail d’approbation appliquent les normes de déploiement de production.

Voici à quoi cela ressemble pour deux utilisateurs différents :

Workflow d’administration (équipe de plateforme) :

1. Activer le magasin de fonctions : Dans le tableau de bord OpenShift AI, accédez aux paramètres du magasin de fonctions et activez le composant (intégré, pas d’installation séparée).
2. Configurer les autorisations : Définissez les équipes de science des données qui peuvent créer des fonctions, celles qui peuvent uniquement consommer des fonctions et les sources de données accessibles à chaque équipe.
3. Surveiller les opérations : Le tableau de bord affiche l’intégrité du pipeline de fonctions, l’utilisation des ressources et la fraîcheur des données.

Workflow du spécialiste des données :

1. Découvrir les fonctions : Recherchez « transaction » dans le catalogue de fonctions : trouvez douze fonctions existantes, dont « customer_transaction_velocity_30d » créée par l’équipe de fraude au dernier trimestre.
2. Comprendre le contexte : Cliquez sur la fonction pour afficher les sources de données (transactions Kafka + clients Oracle), les exigences de calcul (tâche Spark, s’exécute quotidiennement) et un exemple de code d’utilisation.
3. Réutiliser dans un nouveau modèle : Copiez la définition de fonction dans leur projet de moteur de recommandation et obtenez la même logique de calcul et la même cohérence entre la détection de fraude et les recommandations.
4. Itérer rapidement : Lancez des notebooks Jupyter préintégrés directement à partir du catalogue de fonctions avec l’authentification déjà configurée.

Résultat : ce qui prenait auparavant trois jours de recherche, cinq conversations Slack et le débogage de calculs incohérents prend désormais dix minutes. Et lorsque l’équipe de lutte contre la fraude améliore son calcul de vélocité des transactions, tous les modèles en aval bénéficient automatiquement de l’amélioration.

C’est la valeur combinée d’un catalogue unifié : chaque fonction créée rend le développement de l’IA de l’ensemble de l’entreprise plus rapide, plus fiable et plus cohérent.

L’impact commercial : d’un outil tactique à une plateforme stratégique

Cette architecture à trois couches transforme les magasins de fonctions d’un composant tactique en une passerelle de données stratégique qui orchestre toute la consommation de données d’IA. Au lieu de gérer des pipelines distincts pour différentes initiatives d’IA, vous établissez un point d’entrée unique et régi qui dessert les modèles ML traditionnels, les applications d’IA générative et les flux de travail hybrides avancés.

L’impact commercial est transformateur :

• Innovation plus rapide : Les spécialistes des données découvrent et réutilisent les fonctions dans tous les projets au lieu de reconstruire à partir de zéro, ce qui réduit le délai de commercialisation.
• Gouvernance plus forte : Point de contrôle unique pour les stratégies d’accès aux données, les pistes d’audit et les exigences de conformité dans toutes les initiatives d’IA
• Meilleure économie : L’infrastructure partagée et les actifs réutilisables réduisent les coûts par projet tout en améliorant la qualité.
• Flexibilité stratégique : Architecture indépendante de la plateforme qui s’adapte à l’évolution de votre pile technologique, préservant ainsi votre capacité à innover.

À mesure que l’IA devient essentielle aux opérations commerciales, les premiers utilisateurs d’une infrastructure de données indépendante des fournisseurs acquièrent un avantage concurrentiel durable en termes de rapidité d’innovation et d’excellence opérationnelle.

Conclusion : bâtir une base de données d’IA pour réussir

La capacité de magasin de fonctions de Red Hat OpenShift AI représente plus qu’une solution de gestion de fonctions : c’est votre plateforme pour bâtir un écosystème de données d’IA indépendant des fournisseurs qui contribue à accélérer l’innovation, à optimiser les opérations et à préserver la flexibilité stratégique.

Votre stratégie de données permet votre avenir en matière d’IA : bâtissez sur une base qui croît avec les capacités de votre entreprise tout en préservant la flexibilité nécessaire pour innover.

Lancez-vous

Prêt à explorer l’approche du magasin de fonctions pour votre entreprise ?

• Démarrez un essai : essai du produit Red Hat AI
• Essayez les exemples de Feast : démos et tutoriels de la communauté
• Découvrez l’IA avec Red Hat : services de consulting en IA
• Contactez l’équipe : jzarecki@redhat.com
• Explorez le code : Feast GitHub Repository
• En savoir plus : Documentation OpenShift AI