L'IA redéfinit la pile de données : l'ancienne architecture dépassée

L'ancienne pile de données face aux défis de l'IA

Les architectures de données traditionnelles, centrées sur des entrepôts comme Redshift ou BigQuery, sont mises à mal par les nouvelles exigences de l'IA. Ces systèmes, conçus pour gérer des données structurées avec des requêtes SQL simples, peinent à répondre aux besoins complexes des pipelines de LLM. Ces derniers nécessitent la gestion de données non structurées, des calculs en temps réel et une traçabilité complète, des tâches que l'ancienne pile ne peut pas gérer efficacement.

La pile traditionnelle, souvent alimentée par des Airflow DAGs, était initialement conçue pour un flux de travail simple : des données structurées entrent, des requêtes SQL sortent, et les tableaux de bord BI se mettent à jour. Cependant, l'IA modifie fondamentalement ce contrat, nécessitant des ajustements majeurs. Par exemple, un pipeline de LLM peut exiger du texte brut et non structuré dans S3 aux côtés de données relationnelles propres, des embeddings calculés à partir de tables de 50 millions de lignes en temps réel, et des vecteurs de caractéristiques générés en millisecondes pour un point de service de modèle.

Aucun de ces éléments ne s'intègre proprement dans l'ancien paradigme. L'entrepôt suppose une structure, tandis que le lac de données a une structure mais pas de transactions. Aucun des deux n'a été conçu pour servir une base de données vectorielle avec une latence de 10 ms. L'architecture Lakehouse, intégrant des solutions comme Delta Lake, Apache Iceberg ou Apache Hudi, offre une flexibilité accrue tout en maintenant l'intégrité transactionnelle, répondant ainsi mieux aux besoins actuels.

L'importance du niveau Platine dans l'architecture Medallion

L'architecture Medallion, souvent simplifiée à trois niveaux (Bronze, Argent, Or), néglige souvent un quatrième niveau crucial : le niveau Platine ou AI-native. Ce niveau est essentiel pour préparer les données à l'IA, en organisant et en traçant les embeddings et les ensembles de données de fine-tuning. Ignorer cette étape dès le début complique considérablement l'intégration ultérieure dans des structures comme Iceberg.

Les embeddings doivent être calculés et stockés rapidement, et les ensembles de données de fine-tuning doivent être organisés, versionnés et suivis. Les vecteurs de caractéristiques pour les modèles ML en temps réel doivent être pré-matérialisés pour éviter des calculs au moment de la requête. Une chose que je voudrais souligner ici : beaucoup d'équipes traitent ce quatrième niveau comme optionnel, quelque chose à ajouter plus tard. En pratique, si vous ne le concevez pas dès le départ, l'ajouter à une structure de table Iceberg existante est réellement douloureux. Vous vous retrouverez avec des tables d'embeddings qui ne sont pas liées à leurs lignes sources dans le graphique de traçabilité, ce qui rend l'audit presque impossible.

Fin du débat Lambda : une nouvelle approche unifiée

Le débat entre les architectures Lambda et Kappa a longtemps divisé les ingénieurs de données. Aujourd'hui, une approche unifiée utilisant Iceberg comme point central semble émerger. Cette méthode permet de gérer simultanément les traitements en temps réel et par lot, garantissant des écritures sûres au niveau ACID et offrant une vue cohérente aux consommateurs en aval.

Les SLOs de latence doivent être explicitement mentionnés. Le chemin en temps réel doit répondre à des exigences de latence mesurées en secondes, tandis que le chemin par lot est mesuré en heures. Ces deux pipelines nécessitent une surveillance différente, des alertes différentes, et souvent des équipes différentes qui les possèdent. J'ai vu des organisations fusionner ces deux SLOs en une seule rotation d'appel, et cela se termine mal.

Gouvernance des données : une nécessité fondamentale

La gouvernance des données est souvent reléguée au second plan, perçue comme une obligation réglementaire. Pourtant, elle est cruciale pour éviter des erreurs coûteuses, comme l'ingestion accidentelle de PII. La traçabilité au niveau des colonnes, les contrats de données et l'automatisation de la classification des PII sont des éléments essentiels pour une gestion efficace et sécurisée des données.

OpenLineage est la norme ouverte pour la traçabilité, et des outils comme Airflow et dbt peuvent émettre des événements de traçabilité qui alimentent des outils comme Marquez ou DataHub. Les contrats de données sont le véritable déblocage. L'idée est suffisamment simple : avant qu'une équipe de producteurs ne change le schéma ou le SLA d'une table, elle doit négocier ce changement avec tous les consommateurs en aval. En pratique, cela signifie définir un contrat YAML (les schémas Avro fonctionnent bien ici) qui spécifie les noms de colonnes, les types, les garanties de nullabilité et le SLA de fraîcheur attendu. Rompez le contrat, rompez la construction. Des outils comme Soda Core ou des suites Great Expectations personnalisées peuvent faire respecter cela au moment de l'ingestion.

La classification des PII était autrefois manuelle. Maintenant, cela ne doit plus l'être. Un pipeline de tagging LLM, oui, utilisant un LLM pour gouverner des données qui pourraient être alimentées dans un LLM, peut scanner de nouvelles tables, identifier des colonnes qui ressemblent à des noms, des e-mails, des numéros de téléphone ou des identifiants de santé, et appliquer automatiquement les balises de gouvernance pertinentes. Ces balises se propagent ensuite en aval pour déclencher des politiques de masquage au niveau des colonnes dans Unity Catalog ou quel que soit le métastore que vous utilisez.

La couche IA : défis et solutions

Intégrer un LLM à une plateforme de données va bien au-delà de la simple installation. Des modèles comme Text-to-SQL et les pipelines RAG nécessitent une gouvernance stricte pour éviter les fuites de données sensibles. Des outils comme Vanna.AI et DSPY de Stanford améliorent la génération de SQL en production. Text-to-SQL est trompeusement délicat. Les démonstrations sont toujours impressionnantes, vous tapez "quel était notre revenu par pays le trimestre dernier" et sort un beau SQL. Mais en production, la qualité de génération de SQL se dégrade fortement lorsque votre schéma est large, lorsque les noms de colonnes sont ambigus (le statut est-il le statut de commande ou le statut de paiement ?), ou lorsque la requête nécessite de joindre plus de trois ou quatre tables. Des outils comme Vanna.AI abordent cela avec une boucle de rétroaction, stockant des paires requête-SQL validées comme exemples à peu d'exemples. DSPY de Stanford adopte une approche plus systématique d'optimisation de la chaîne de prompt en utilisant un petit ensemble de données étiquetées. Aucun des deux n'est parfait, mais les deux sont considérablement plus fiables qu'un simple prompt "voici mon schéma, générez SQL".

Les pipelines RAG ont également besoin de gouvernance. Lorsque votre système RAG récupère des morceaux d'une base de connaissances interne, il contourne effectivement toute la sécurité au niveau des lignes que vous avez intégrée dans votre lakehouse. Un utilisateur qui ne devrait pas pouvoir voir des PII clients peut, en théorie, poser une question qui amène le système RAG à récupérer et à afficher cette information. Résoudre cela correctement nécessite de filtrer vos résultats de recherche vectorielle par les mêmes politiques d'accès que vous appliquez à vos données structurées, ce qui signifie que votre pipeline d'embeddings doit stocker des métadonnées avec chaque vecteur indiquant quels rôles sont autorisés à le voir.

Le feature store est encore sous-utilisé. La plupart des équipes avec lesquelles je parle ont au moins entendu parler des feature stores mais n'en ont pas construit un correctement. La proposition de valeur est la suivante : vous calculez une caractéristique, par exemple, la fréquence d'achat d'un utilisateur sur 30 jours, une fois, la stockez et la servez à la fois aux points de service de modèle en ligne (avec une latence en millisecondes via Redis) et aux pipelines d'entraînement hors ligne (depuis le lakehouse). Sans un feature store, ce calcul est dupliqué, souvent subtilement différemment, entre votre pipeline d'entraînement et votre pipeline de service. Cette incohérence est l'une des sources les plus courantes de dégradation des performances des modèles en production.

Observabilité : la partie qui décide si votre plateforme survit

L'observabilité des données est devenue sa propre catégorie. Des outils comme Monte Carlo, Acceldata et Metaplane effectuent essentiellement des vérifications de santé sur vos pipelines et vous alertent lorsque quelque chose se casse silencieusement. Et "casser silencieusement" est le tueur. Un pipeline qui échoue est ennuyeux. Un pipeline qui fonctionne correctement mais produit des chiffres subtilement erronés pendant trois semaines est catastrophique.

La configuration d'observabilité minimale viable pour une plateforme de production :

• Vérifications de volume : si une table reçoit 10 % du nombre de lignes quotidien normal, déclenchez une alerte.

• Vérifications de fraîcheur : si une table Gold n'a pas été mise à jour dans les 6 heures suivant son SLA, déclenchez une alerte.

• Vérifications de distribution : si la moyenne d'une colonne numérique change de plus de deux écarts-types par rapport à sa moyenne mobile sur 30 jours, signalez-le.

• Détection de dérive de schéma : si une source...