Les progrès récents de l'IA sont très excitants. Les gens l'utilisent de toutes sortes de manières novatrices, de des expériences de support client à de code, en passant par de nouvelles musiques et même de la technologie d'imagerie médicale. l'amélioration l'écriture et à l'exécution la création l'accélération Mais dans le processus, une tendance inquiétante a émergé : la communauté de l'IA semble réinventer le mouvement des données (alias ETL). Qu'ils les appellent connecteurs, extracteurs, intégrations, chargeurs de documents ou autre chose, les gens écrivent le même code pour extraire des données des mêmes API, formats de document et bases de données, puis les chargent dans des bases de données vectorielles ou des index pour leurs LLM. Le problème est que la construction et la maintenance de pipelines d'extraction et de chargement robustes à partir de rien représentent un engagement énorme. Et il y a tellement d'art antérieur dans ce domaine que pour presque tous les ingénieurs ou entreprises du domaine de l'IA, c'est une énorme perte de temps de le reconstruire. Dans un espace où les dernières nouvelles émergent environ toutes les heures, l'objectif principal doit être de rendre votre produit de base incroyable pour vos utilisateurs, et non de faire des quêtes parallèles. Et pour presque tout le monde, le produit principal n'est pas le déplacement des données ; c'est la sauce magique alimentée par l'IA que vous préparez. Beaucoup a été écrit ( , ) sur les défis liés à la construction de pipelines d'extraction, de transformation et de chargement (ETL) robustes, mais contextualisons-les au sein de l'IA. 1 2 Pourquoi l'IA a-t-elle besoin de mouvement de données ? Les LLM formés sur les données publiques sont formidables, mais vous savez ce qui est encore mieux ? Des IA qui peuvent répondre à des questions spécifiques à nous, à nos entreprises et à nos utilisateurs. Nous aimerions tous que ChatGPT puisse apprendre l'ensemble de notre wiki d'entreprise, lire tous nos e-mails, messages Slack, notes de réunion et transcriptions, se connecter à l'environnement d'analyse de notre entreprise et utiliser toutes ces sources pour répondre à nos questions. Ou lors de l'intégration de l'IA dans notre propre produit (par exemple avec Notion AI , nous voudrions que le modèle d'IA de notre application connaisse toutes les informations dont nous disposons sur un utilisateur lorsque nous l'aidons. ) Le déplacement des données est une condition préalable à tout cela. Que vous affiniez un modèle ou la génération augmentée par récupération (RAG), vous devez extraire des données où qu'elles se trouvent, les transformer en un format assimilable par votre modèle, puis les charger dans un magasin de données auquel votre application d'IA peut accéder. pour servir votre cas d'utilisation. que vous utilisiez Le diagramme ci-dessus illustre à quoi cela ressemble lorsque vous utilisez RAG, mais vous pouvez imaginer que même si vous n'utilisez pas RAG, il est peu probable que les étapes de base changent : vous devez extraire, transformer et charger alias ETL les données afin de construire des modèles d'IA qui connaissent des informations non publiques spécifiques à vous et à votre cas d'utilisation. Pourquoi le déplacement des données est-il difficile ? Construire un MVP fonctionnel de base pour l'extraction de données à partir d'une API ou d'une base de données est généralement - mais pas toujours - faisable avec un préavis rapide (<1 semaine). La partie vraiment difficile est de le rendre prêt pour la production et de le garder ainsi. Examinons quelques-uns des défis standard qui viennent à l'esprit lors de la construction de pipelines d'extraction. Extraits incrémentiels et gestion des états Si vous avez un volume de données significatif, vous devrez implémenter une extraction incrémentielle de sorte que votre pipeline n'extrait que les données qu'il n'a pas vues auparavant. Pour ce faire, vous aurez besoin d'une couche de persistance pour garder une trace des données extraites par chaque connexion. Gestion des erreurs transitoires, interruptions, reprise en cas d'échec (s), espacement d'air Sources de données en amont tout le temps, parfois sans raison claire. Vos pipelines doivent être résilients à cela et réessayer avec les bonnes politiques d'interruption. Si les pannes ne sont pas si transitoires (mais toujours pas de votre faute), votre pipeline doit être suffisamment résistant pour se rappeler où il s'est arrêté et reprendre à partir du même endroit une fois que l'amont est réparé. Et parfois, le problème venant de l'amont est suffisamment grave (comme une API supprimant certains champs cruciaux des enregistrements) pour que vous souhaitiez suspendre complètement l'ensemble du pipeline jusqu'à ce que vous examiniez ce qui se passe et que vous décidiez manuellement quoi faire. Identification et correction proactive des erreurs de configuration Si vous construisez des pipelines d'extraction de données pour extraire les données de vos clients, vous devrez mettre en place des vérifications défensives pour vous assurer que toute la configuration que vos clients vous ont donnée pour extraire des données en leur nom est correcte et si ce n'est pas le cas, rapidement donnez-leur des messages d'erreur exploitables. La plupart des API ne facilitent pas cela car elles ne publient pas de tableaux d'erreurs complets et même lorsqu'elles le font, elles vous donnent rarement des points de terminaison que vous pouvez utiliser pour vérifier les autorisations attribuées, par exemple aux jetons d'API, vous devez donc trouver des moyens d'équilibrer vérifie avec un retour rapide pour l'utilisateur. Authentification et gestion des secrets Les API varient en simplicité, de la simple authentification de jeton au porteur à, euh, des implémentations «créatives» de jetons de session ou OAuth à jeton à usage unique. Vous devrez implémenter la logique pour effectuer l'authentification ainsi que gérer les secrets qui peuvent être actualisés une fois par heure, en coordonnant potentiellement les actualisations secrètes sur plusieurs travailleurs simultanés. Optimisation des vitesses d'extraction et de chargement, de la simultanéité et des limites de débit Et en parlant de travailleurs simultanés, vous souhaiterez probablement implémenter la simultanéité pour atteindre un débit élevé pour vos extractions. Bien que cela n'ait pas d'importance sur les petits ensembles de données, c'est absolument crucial sur les plus grands. Même si les API publient des limites de débit officielles, vous devrez déterminer de manière empirique les meilleurs paramètres de parallélisme pour maximiser la limite de débit qui vous est fournie par l'API sans être mis sur liste noire IP ou limité à jamais. S'adapter aux changements d'API en amont Les API changent et adoptent constamment de nouveaux comportements ou caprices non documentés. De nombreux fournisseurs publient de nouvelles versions d'API tous les trimestres. Vous devrez garder un œil sur l'impact de toutes ces mises à jour sur votre travail et consacrer du temps d'ingénierie pour tout maintenir à jour. De nouveaux terminaux apparaissent tout le temps, et certains changent de comportement (et vous n'êtes pas toujours prévenu). Planification, surveillance, journalisation et observabilité Au-delà du code qui extrait les données d'API spécifiques, vous devrez probablement créer des fonctionnalités horizontales exploitées par tous vos extracteurs de données. Vous aurez besoin d'une planification ainsi que d'une journalisation et d'une surveillance lorsque la planification ne fonctionne pas, ou lorsque d'autres choses tournent mal et que vous devez enquêter. Vous souhaitez également probablement une certaine observabilité, telle que le nombre d'enregistrements extraits hier, aujourd'hui, la semaine dernière, etc. et de quels points de terminaison d'API ou tables de base de données proviennent-ils. Blocage ou hachage de données Selon l'endroit d'où vous extrayez les données, vous aurez peut-être besoin de certaines fonctionnalités de confidentialité pour bloquer ou hacher les colonnes avant de les envoyer en aval. Pour être clair, ce qui précède ne s'applique pas si vous souhaitez simplement déplacer quelques fichiers en une seule fois. Mais cela s'applique lorsque vous créez des produits qui nécessitent un déplacement de données. Tôt ou tard, vous devrez faire face à la plupart de ces préoccupations. Et bien qu'aucun d'entre eux ne soit une science de fusée insurmontable, pris ensemble, ils peuvent rapidement ajouter jusqu'à un ou plusieurs emplois à temps plein, d'autant plus que vous extrayez de sources de données. Et c'est exactement la difficulté de maintenir l'extraction de données et les pipelines : la majorité de son coût provient de l'investissement incrémentiel continu nécessaire pour maintenir ces pipelines fonctionnels et robustes. Pour la plupart des ingénieurs en IA, ce n'est tout simplement pas le travail qui ajoute le plus de valeur à leurs utilisateurs. Leur temps est mieux dépensé ailleurs. Alors, qu'est-ce qu'un ingénieur en intelligence artificielle doit faire pour déplacer des données ici ? Si jamais vous avez besoin d'extraction de données et de pipelines de chargement, essayez les solutions déjà disponibles au lieu de créer automatiquement les vôtres. Il y a de fortes chances qu'ils puissent résoudre beaucoup sinon tous vos problèmes. Sinon, construisez le vôtre en dernier recours. Et même si les plates-formes existantes ne prennent pas en charge tout ce dont vous avez besoin, vous devriez toujours pouvoir y accéder avec un framework portable et extensible. De cette façon, au lieu de tout construire à partir de zéro, vous pouvez obtenir 90 % du chemin avec des fonctionnalités prêtes à l'emploi dans la plate-forme et ne construire et maintenir que les 10 % restants. L'exemple le plus courant est celui des intégrations à longue traîne : si la plate-forme n'est pas livrée avec une intégration à une API dont vous avez besoin, une bonne plate-forme facilitera l'écriture de code ou même une solution sans code pour créer cette intégration et bénéficiez toujours de toutes les fonctionnalités utiles offertes par la plateforme. Même si vous souhaitez avoir la possibilité d'importer simplement un connecteur en tant que package python et de le déclencher comme bon vous semble à partir de votre code, vous pouvez utiliser l'un des nombreux outils EL open source tels que les connecteurs Airbyte ou Singer. Pour être clair, le mouvement des données n'est pas complètement résolu. Il existe des situations où les solutions existantes sont vraiment insuffisantes et vous devez créer de nouvelles solutions. Mais ce n'est pas la majorité de la population d'ingénieurs en IA. La plupart des gens n'ont pas besoin de reconstruire sans cesse les mêmes intégrations avec Jira, Confluence, Slack, Notion, Gmail, Salesforce, etc. Utilisons simplement les solutions qui ont déjà été testées au combat et mises à la disposition de tous afin que nous puissions continuer à ajouter la valeur dont nos utilisateurs se soucient réellement. Apparaît également . ici

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Cet audio est produit dans la langue originale de l'histoire !

L'IA ne devrait pas perdre de temps à réinventer l'ETL

Trop long; Pour lire

John Lafleur

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Vested Interest

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...