Créer une entreprise AI-native

xguru · 2024-07-01T11:22:02+09:00

Au début des années 2020, l’attention s’est fortement portée sur l’IA générative Les discussions ont surtout porté sur la manière dont les outils d’IA générative allaient nous façonner, et sur leur impact sur l’écriture, le code, l’animation et notre façon de consommer l’information En revanche, la forme de nos outils a été relativement peu évoquée À la fin des années 1960, les systèmes d’information ont été confrontés à un problème croissant : le coût de la recherche d’informations pertinentes augmentait à mesure que les volumes de données explosaient Dans les années 1980 et 1990, les bases de données relationnelles sont devenues la solution dominante Elles offraient une indexation intuitive et garantissaient l’efficacité des requêtes Elles permettaient de représenter les données sous forme d’un ensemble de tables dotées de relations structurées Grâce à des langages de requête comme SQL, elles ont rendu la recherche de données plus rapide À mesure que l’architecture des bases de données a évolué, certaines entreprises comme IBM, Oracle, Sun Microsystems et MongoDB se sont imposées sur chacun de ces marchés émergents Si Oracle a dominé l’univers des bases de données relationnelles, la manière dont les gens stockent et accèdent à l’information a continué d’évoluer À chaque nouveau type de travail, ils ont imaginé une nouvelle architecture pour le gérer L’évolution récente des bases de données est née du besoin de traiter des données non structurées Pendant plus de 50 ans, les schémas se sont principalement organisés autour de relations de données structurées Mais de plus en plus d’utilisateurs ont eu besoin d’outils capables de bien mieux gérer l’ambiguïté des données C’est dans ce contexte que les bases de données vectorielles sont apparues Les grands modèles de langage (LLM) fondés sur les transformeurs, comme GPT, peuvent capter les dépendances de long terme dans le texte Mais préserver une compréhension fiable des longs contextes peut être coûteux en calcul Les bases de données vectorielles peuvent étendre la fenêtre de contexte de ces modèles Les bases de données vectorielles peuvent être puissantes pour les cas d’usage de l’IA, mais elles restent une infrastructure stupide, pilotée par des entrées et des sorties Elles n’ont pas la capacité de comprendre ni d’interpréter les données Elles servent simplement de dépôts qui stockent et récupèrent les données selon les instructions reçues, sans intelligence intrinsèque ni conscience du contexte Avec le lancement de GPT-3 en 2020, l’IA a pu devenir de plus en plus le cœur des produits d’entreprise plutôt qu’un simple ajout L’architecture des transformeurs, l’augmentation des volumes de données et l’amélioration des performances ont posé les bases du développement de produits fondés sur l’IA À mesure que les entreprises AI-native se multiplient et changent d’échelle, le besoin d’outils capables de prendre en charge des cas d’usage fondés sur l’IA augmente également La première vague d’entreprises centrées sur l’IA s’est surtout concentrée sur l’inférence à partir de modèles existants Mais avec des modèles plus performants, en particulier les modèles open source facilement accessibles, les entreprises peuvent développer plus en profondeur leurs capacités en tant qu’activités fondées sur l’IA Cette montée en puissance ouvre un vaste champ de possibilités quant à ce que pourrait être une stack technologique AI-native Les outils qui nous façonnent (The Tools that Shape Us) En 1967, John M. Culkin, ami de Marshall McLuhan, disait : « Nous façonnons nos outils, puis nos outils nous façonnent » Il en va de même pour la création de technologies L’infrastructure que nous utilisons pour construire des logiciels n’a cessé d’évoluer pour répondre à nos besoins de développement, puis nos constructions ont à leur tour été façonnées par l’infrastructure mise en place Au début des années 2020, l’attention s’est fortement portée sur l’IA générative En particulier sur les résultats produits : texte ou code généré, images rendues, deepfakes créés, musique synthétisée Les discussions ont surtout porté sur la manière dont ces outils allaient nous façonner, et sur leur impact sur l’écriture, le code, l’animation et notre façon de consommer l’information Les gens débattaient des performances comparées des grands modèles de langage ouverts et propriétaires, du risque d’hallucination, du débat plateforme contre fonctionnalité, ou encore de l’opposition entre entreprises établies et startups En revanche, la forme de nos outils a été relativement peu évoquée Fondamentalement, la manière dont nous construisons la technologie a toujours été façonnée par l’infrastructure mise en place pour la construire L’essor du SaaS a été accéléré par Internet, le développement mobile a été rendu possible par la généralisation des smartphones, et le cloud computing a favorisé le passage à l’échelle de générations entières d’applications L’omniprésence de l’IA dans les applications dépend de la puissance de calcul, des capacités des modèles et de la manière dont ces modèles sont orchestrés dans les cas d’usage métier Cet article se concentre sur cet élément d’orchestration L’un des éléments clés de l’orchestration de tous les cas d’usage de l’IA est la base de données de l’entreprise L’endroit où les données sont stockées, manipulées et appelées constitue une pièce essentielle du puzzle Mais, comme nous allons le montrer, l’histoire des bases de données a largement été celle d’une infrastructure stupide Pour maximiser l’utilité de l’IA, il faudra concevoir des bases de données capables de faire partie de l’équation générative Une base pour les données (A Base For Data) En mai 1959, CODASYL (Conference on Data Systems Languages) s’est réuni pour la première fois avec l’ambition de créer « un langage générique pour construire des applications métier » À la fin des années 1960, les systèmes d’information ont été confrontés au problème d’un coût croissant de la recherche d’informations pertinentes, en raison du volume massif de données L’usage des ordinateurs mainframe a généralement entraîné une hausse du coût par MIPS (millions d’instructions par seconde), à mesure que leur utilisation augmentait, en raison notamment des coûts de maintenance applicative, de patching et de mises à niveau nécessaires pour maintenir les performances En raison de la complexité de l’administration des bases de données, de hiérarchies rigides et de mappings complexes des structures de navigation, les entreprises avaient souvent besoin d’une expertise technique pour accéder aux informations choisies, et certains développeurs devaient même écrire des programmes entiers pour y accéder En 1970, E.F. Codd a publié « A Relational Model for Large Shared Data Banks », proposant un modèle dans lequel des tables pouvaient être reliées par des caractéristiques communes, à savoir des clés primaires identifiant des enregistrements uniques et des clés étrangères établissant des relations entre tables Cela a permis de récupérer des données à partir de tables hétérogènes avec une seule requête La base de données relationnelle de Codd, fondée sur les relations entre les éléments de données, a permis davantage de flexibilité dans la manipulation et l’utilisation des données En 1973, un groupe de programmeurs du laboratoire de recherche IBM de San Jose a lancé le projet System R, démontrant qu’un système de base de données relationnelle pouvait intégrer toutes les fonctionnalités nécessaires à un usage en production tout en conservant de hautes performances L’équipe a développé un optimiseur à base de coûts pour l’efficacité de la base de données, et les avancées issues de System R ont ensuite conduit au lancement de SQL/DS, premier produit de base de données relationnelle d’IBM Dans les années 1980 et 1990, les bases de données relationnelles sont devenues la solution dominante Elles offraient une indexation intuitive et garantissaient l’efficacité des requêtes Elles permettaient de représenter les données comme un ensemble de tables liées par des relations structurées Elles ont permis une récupération plus rapide des données via des langages de requête comme SQL Les bases de données relationnelles ont été conçues en partant de l’hypothèse qu’elles s’exécutaient sur une seule machine Mais l’adoption massive d’Internet dans les années 1990 et 2000 a provoqué un afflux colossal de données, générant des charges de travail trop lourdes pour un seul ordinateur Les bases de données SQL traditionnelles étaient conçues pour fonctionner sur un seul serveur, obligeant les utilisateurs à augmenter le matériel physique en fonction des besoins de stockage, ce qui s’est révélé très coûteux pour les entreprises opérant de plus grosses charges de travail Dans les années 2010, les données et le nombre d’utilisateurs liés à l’OLTP (online transaction processing) ont augmenté de manière exponentielle, entraînant une forte montée en puissance des bases de données distribuées, des data warehouses et de l’OLAP (online analytical processing) Les bases de données relationnelles et SQL n’étaient plus adaptées à l’échelle et à la complexité des applications requises, et les bases de données NoSQL ont émergé comme moyen d’améliorer les performances, au prix des garanties ACID Les bases de données relationnelles pouvaient stocker et manipuler des données structurées, mais il était difficile de maintenir les relations entre les données compte tenu de l’overhead des jointures et du coût des opérations CRUD Elles étaient adaptées au traitement de données relationnelles répondant à des exigences logiques ou discrètes, mais restaient généralement alignées sur des systèmes legacy spécialement conçus pour des structures relationnelles NoSQL est apparu comme un moyen de traiter du big data non structuré, en fournissant aux développeurs une persistance des données via une approche non relationnelle Au lieu d’utiliser SQL comme langage de requête principal, NoSQL fournit un accès via des API, garantissant une plus grande scalabilité, du calcul distribué, une réduction des coûts et une flexibilité de schéma Les bases de données NoSQL reposent sur une architecture efficace pouvant monter en charge horizontalement, de sorte qu’il suffit d’ajouter davantage de serveurs ou d’instances cloud pour augmenter la capacité de stockage ou de calcul Pour les entreprises ayant des charges de travail orientées vers un traitement ou une analyse plus rapide de données non structurées, les bases de données NoSQL ont été privilégiées Les OG database wars À mesure que l’architecture des bases de données évoluait, certaines entreprises ont consolidé leur position sur chaque marché émergent Peu après le lancement de System R par IBM, Larry Ellison, alors âgé de 33 ans, a lu le même article de Codd sur les bases de données relationnelles Ellison et ses deux cofondateurs ont tenté de créer une entreprise compatible avec System R, mais IBM a rendu cela très difficile En conséquence, le trio a bâti son activité autour d’un nouveau produit phare de base de données, Oracle Databases Depuis, la base de données d’Oracle est devenue le produit leader, avec environ 28,7 % de part de marché en mai 2024 Dans les années qui ont précédé l’IPO d’Oracle en 1986, une autre entreprise est entrée dans le secteur des bases de données Sun Microsystems a commencé en 1982 par vendre divers composants informatiques, avant de devenir connue pour ses contributions comme le langage de programmation Java, Network File System, entre autres Point important : en 2008, Sun Microsystems a acquis MySQL, un système open source de gestion de base de données Deux ans plus tard à peine, Oracle a racheté Sun Microsystems, MySQL compris Près de 15 ans plus tard, en mai 2024, les bases de données leaders sont Oracle (28,7 % de part de marché) et MySQL (environ 17,3 %) Si Oracle a dominé le monde des bases de données relationnelles, la manière dont les gens stockent et accèdent à l’information a continué d’évoluer À chaque nouveau type de tâche, de nouvelles architectures ont été conçues pour les gérer Des document stores comme MongoDB (2007) et Databricks (2013), aux bases de données de séries temporelles comme InfluxDB (2013) et Prometheus (2012), jusqu’aux bases de données graphe comme Neo4j (2007) et Cosmos (2017), la liste des bases de données spécialisées ne cesse de s’allonger À mesure que la popularité des bases de données relationnelles déclinait progressivement, diverses solutions sont apparues pour répondre à ces nouveaux besoins de niche La dernière évolution des bases de données est née de la nécessité de traiter des données non structurées Pendant plus de 50 ans, les schémas ont été principalement organisés autour de relations de données structurées Mais de plus en plus de personnes ont eu besoin d’outils capables de bien mieux gérer l’ambiguïté des données C’est dans ce contexte qu’ont émergé les bases de données vectorielles L’essor des bases de données vectorielles Avec la diffusion massive des grands modèles de langage (LLM) et de l’IA générative, les bases de données vectorielles se sont imposées comme des outils capables de traiter des données multimodales non structurées Alors que les bases de données relationnelles traditionnelles (Postgres, MySQL) conviennent le mieux aux schémas structurés, les bases de données vectorielles sont adaptées au stockage et à l’interrogation d’embeddings vectoriels (des représentations numériques des données qui intègrent un sens relatif aux poids d’un modèle de langage) Au lieu des lignes et colonnes généralement utilisées dans les bases relationnelles, les bases de données vectorielles représentent les données comme des points dans un espace multidimensionnel et établissent des correspondances sur la base de la similarité plutôt que de valeurs exactes Selon le modèle d’embedding, les données peuvent être représentées dans différents espaces vectoriels et avec diverses dimensions Les embeddings vectoriels capturent la signification des points de données, ce qui permet de retrouver des objets similaires en recherchant les objets les plus proches dans une base de données vectorielle Par exemple, Word2Vec mappe les mots en vecteurs, ce qui aide à capturer le sens, la similarité sémantique et les relations contextuelles avec d’autres textes Cet algorithme utilise un réseau de neurones peu profond pour déduire le sens d’un mot donné à partir d’un corpus textuel plus large et identifie les synonymes via une régression logistique Il existe aussi des méthodes comme la décomposition en valeurs singulières (SVD) et l’analyse en composantes principales (PCA), qui aident à extraire des embeddings sans dépendre de réseaux de neurones profonds Les métriques de distance aident à déterminer la « distance » relative entre des points dans un espace vectoriel ; parmi les méthodes courantes figurent la distance euclidienne, la distance de Manhattan, la distance cosinus et la similarité de Jaccard Les K plus proches voisins (KNN) et les voisins les plus proches approximatifs (ANN) contribuent à simplifier la recherche de similarité sur des images, des vidéos ou d’autres entrées multimodales, tout en améliorant le temps d’exécution Des bases de données spécialisées dans les vecteurs, comme Weaviate, Chroma, Qdrant et Pinecone, aident les développeurs à gérer plus facilement la recherche dans de grands volumes de données, en particulier des entrées non structurées Contrairement aux bases de données relationnelles ou NoSQL traditionnelles, les bases de données vectorielles sont spécialement conçues pour traiter les embeddings vectoriels Là où les bases de données traditionnelles stockent les données sous forme de scalaires, les bases de données vectorielles ne stockent que des vecteurs et exploitent des techniques d’indexation comme la quantification et le clustering pour optimiser les opérations de recherche Les LLM basés sur des transformers, comme GPT, peuvent capturer les dépendances de long terme dans le texte Toutefois, préserver la compréhension des textes longs peut être coûteux sur le plan computationnel Les LLM les plus récents peuvent capter les dépendances globales entre paires de tokens sur l’ensemble de l’entrée, mais la complexité en temps et en espace pose des problèmes de ressources de calcul, ce qui limite la longueur du texte d’entrée pendant l’entraînement ainsi que la fenêtre de contexte effective en inférence Dans les cas multidimensionnels, le codage de position relative est difficile à mettre en œuvre, et la plupart des approches qui encodent les positions relatives nécessitent des mécanismes d’embedding positionnel puissants qui contribuent à une baisse des performances lors de l’inférence Même lorsque la longueur du texte augmente, les bases de données vectorielles peuvent jouer un rôle important en servant de mémoire à long terme au modèle L’utilisation de bases de données vectorielles peut simplifier des tâches comme la complétion de texte ou le résumé, où le contexte de la phrase entière peut être nécessaire pour générer des résultats précis Les bases de données vectorielles peuvent prendre en charge la génération augmentée par récupération (RAG), où elles servent à enrichir le prompt transmis au LLM en y ajoutant un contexte supplémentaire avec la requête d’origine Les LLM reposent souvent sur des modèles d’apprentissage auto-supervisé, ce qui les met fréquemment en difficulté sur des tâches spécifiques à un domaine nécessitant des connaissances particulières ou un seuil de précision plus élevé Le RAG peut aider à vérifier, retracer ou expliquer comment une réponse a été obtenue, tout en atténuant les hallucinations dues à un manque de contexte autour de la requête posée Les développeurs peuvent combiner graphes de connaissances et recherche vectorielle afin d’étendre les capacités des LLM au-delà des données sur lesquelles ils ont été entraînés Des outils comme GraphRAG de Microsoft Research facilitent l’augmentation de prompt lors de recherches sur des jeux de données privés Le RAG de base a souvent du mal à appréhender globalement des concepts sémantiques résumés dans de vastes collections de données ; c’est pourquoi des outils comme LlamaIndex et GraphRAG construisent des graphes de connaissances à partir de jeux de données privés Selon les exigences ou les cas d’usage, il peut être préférable pour les développeurs d’utiliser des graphes de connaissances plutôt que le RAG Les bases de données vectorielles conviennent à la recherche de similarité et sont les mieux adaptées à la recherche de documents ou d’images ainsi qu’à la génération de recommandations, tandis que les graphes de connaissances sont mieux adaptés au raisonnement (en particulier pour la collecte de données, l’extraction d’entités avec leurs relations interconnectées et la traversée de ces relations) Pour les applications nécessitant un traitement des données en temps réel ou quasi réel, les bases de données vectorielles peuvent être privilégiées en raison d’une latence plus faible lors des requêtes En collectant et en stockant des embeddings, les bases de données vectorielles facilitent une récupération plus rapide dans le cadre de la recherche de similarité, en faisant correspondre le prompt saisi à des embeddings similaires Le classement par similarité contribue à prendre en charge de nombreuses tâches de machine learning, allant des systèmes de recommandation à la recherche sémantique, à la reconnaissance d’images et à d’autres applications de traitement du langage naturel Les bases de données vectorielles jouent un rôle clé dans l’amélioration des performances des LLM en permettant le stockage et la récupération efficaces d’embeddings vectoriels Cela permet une compréhension automatique du langage naturel à grande échelle Cependant, les embeddings vectoriels représentent une innovation N+1 Il s’agit d’un format de données antérieur, comme les données relationnelles ou de séries temporelles Les fournisseurs historiques de bases de données ont commencé à lancer des fonctionnalités vectorielles, comme Atlas Vector Search de MongoDB, la base de données vectorielle de SingleStore et les index de recherche vectorielle de Neo4J Même si les bases de données vectorielles peuvent être puissantes pour les cas d’usage IA, elles restent une infrastructure simpliste, pilotée par les entrées et les sorties Elles n’ont pas la capacité de comprendre ou d’interpréter les données Elles ne font que stocker et récupérer les données selon les instructions reçues, sans intelligence intrinsèque ni conscience du contexte Pour les applications modernes fondées sur l’IA, cela seul ne suffira pas Les entreprises construisent de plus en plus avec les modèles d’IA au cœur de leur activité Par conséquent, à mesure que les applications afficheront des capacités toujours plus intelligentes, l’infrastructure devra elle aussi offrir les mêmes capacités intelligentes Les entreprises AI-native de première génération Depuis que le monde universitaire a commencé à étudier l’intelligence artificielle pour la première fois au Dartmouth College en 1956, ce sont les cas d’usage pratiques qui ont fait progresser le domaine Par exemple, à la fin des années 1960, Joseph Weizenbaum a créé un programme informatique appelé ELIZA, dont l’approche simple de simulation de conversation par appariement de motifs a été utilisée pour des échanges rappelant une forme rudimentaire de thérapie (le premier chatbot) Pendant la majeure partie de l’histoire de l’usage de l’IA dans les cas d’usage métier, les améliorations de l’IA ont été progressives Avant que le terme IA ne devienne à la mode, on utilisait plus souvent le terme apprentissage automatique pour désigner la même technologie Autrement dit, des « algorithmes statistiques capables d’apprendre à partir de données et de généraliser à des données inédites, afin d’exécuter des tâches sans instructions explicites » Du point de vue de la perception du grand public, l’IA a atteint un point d’inflexion le 30 novembre 2022, lorsque OpenAI a lancé ChatGPT, mais d’un point de vue technique, le tournant s’était produit bien plus tôt En novembre 2017, le Conseil de stabilité financière (FSB), un organisme international de régulation, a rédigé une vue d’ensemble de l’impact de l’apprentissage automatique sur les services financiers Les entreprises de services financiers pouvaient de plus en plus utiliser l’apprentissage automatique pour effectuer des tâches comme « l’évaluation de la qualité du crédit » et ainsi « contribuer à un système financier plus efficace » Autrement dit, cela pouvait améliorer l’efficacité, mais ne constituait pas une nécessité existentielle Entre-temps, l’apprentissage automatique s’améliorait de plus en plus et, en mai 2018, OpenAI a publié une étude sur l’historique du calcul nécessaire à l’entraînement de grands modèles, montrant qu’il avait doublé tous les 3,4 mois depuis 2012, soit une hausse de 300 000 fois de la puissance de calcul Le mois suivant, en juin 2018, OpenAI a publié la première présentation du modèle GPT Un débat commençait à se former entre deux camps D’un côté, beaucoup pensaient que la croissance continue de modèles toujours plus grands finirait par se heurter à la loi des rendements décroissants L’autre camp, auquel appartenait OpenAI, estimait que les performances continueraient de s’améliorer avec l’augmentation de l’échelle En janvier 2020, Jared Kaplan, chercheur chez OpenAI et professeur à l’université Johns Hopkins, a publié avec d’autres chercheurs « Scaling Laws for Neural Language Models », où il est écrit : « Les performances des modèles de langage s’améliorent de manière fluide et prévisible à mesure que l’on augmente correctement la taille du modèle, les données et la puissance de calcul. Nous nous attendons à ce que des modèles de langage plus grands soient plus performants que les modèles actuels et présentent une meilleure efficacité d’échantillonnage. » En mai 2020, OpenAI a publié l’article sur GPT-3 intitulé « Language Models are Few-Shot Learners », qui montrait une montée en performance régulière avec l’augmentation de la puissance de calcul OpenAI a également constaté qu’augmenter l’échelle améliorait aussi la capacité de généralisation, affirmant que « le passage à l’échelle des grands modèles de langage améliore fortement les performances few-shot indépendantes de la tâche, au point de rivaliser parfois avec les précédentes approches de fine-tuning à l’état de l’art » Le chercheur indépendant Gwern Branwen a formulé l’hypothèse du scaling dans un billet de blog, en écrivant : « GPT-3, publié par OpenAI en mai 2020, est le plus grand réseau de neurones jamais entraîné à ce jour, et de plus d’un ordre de grandeur... Contrairement aux attentes de nombreuses personnes (moi y compris), cette augmentation massive d’échelle a continué à produire les bénéfices du passage à l’échelle prédits par OpenAI, sans buter sur les rendements décroissants ou négatifs auxquels beaucoup s’attendaient. » Cette surprise ressentie par Branwen signalait un changement de paysage L’IA pouvait être utilisée de plus en plus comme cœur du produit d’une entreprise, et non plus comme simple appendice L’architecture Transformer, l’augmentation du volume de données et l’amélioration du niveau de performance ont ensemble posé les bases du développement de produits alimentés par l’IA Peu après la sortie de GPT-3, en mai 2020, des entreprises comme Writer et Jasper ont créé des produits de copywriting plaçant les modèles d’IA au centre de leur activité Des entreprises comme Harvey et EvenUp ont construit leur legal tech autour de l’IA Des entreprises comme DeepScribe et Freed ont bâti la transcription médicale autour de l’IA Mais, de la même manière que de nouveaux cas d’usage avaient autrefois entraîné l’évolution des bases de données, la naissance de produits alimentés par l’IA signifiait aussi que l’infrastructure derrière la stack technique de chaque entreprise devait évoluer et s’adapter Base de données AI-native À mesure que les entreprises alimentées par l’IA se multiplient et changent d’échelle, le besoin d’outils capables de prendre en charge des cas d’usage fondés sur l’IA augmente lui aussi La première vague d’entreprises dont le cœur reposait sur l’IA s’est principalement concentrée sur l’inférence à partir de modèles existants Avec des outils de workflow spécialisés pour les applications, le copywriting, la transcription médicale, etc. Le cœur du produit est la sortie, comme le texte ou l’image générés par le modèle Après le DevDay d’OpenAI en novembre 2023, le mème « OpenAI ruined my startup » a commencé à se répandre Certains GPT spécialisés ou agents IA semblaient assumer le rôle de ces premières startups IA, car ils se concentraient sur l’inférence à partir de modèles existants OpenAI est ainsi devenu, presque par accident, à la fois fournisseur de modèles et d’applications L’innovation centrée sur les capacités des modèles avançait si vite qu’elle a commencé à apparaître comme une menace pour les startups Mais à l’inverse, des modèles plus performants, en particulier les modèles open source facilement accessibles, ont permis aux entreprises d’approfondir davantage leurs capacités en tant qu’activité fondée sur l’IA Construire une stack technique alimentée par l’IA ne consiste pas seulement à ajouter des composants autour du modèle À quoi ressemblerait, par exemple, une base de données conçue spécifiquement pour l’IA ? Si l’inférence est la sortie importante, alors une base de données AI-native ne doit pas seulement stocker et récupérer des données, mais aussi être capable de prendre des instructions contextuelles sur ce qu’il faut faire avec les données qu’elle stocke Un exemple peut être la personnalisation de descriptions de produits pour l’e-commerce Une base de données vectorielle peut stocker non seulement les embeddings vectoriels des SKU et des descriptions de produits, mais aussi des embeddings correspondant à des personas utilisateurs En utilisant toutes ces données contextuelles dans la base, l’infrastructure peut exploiter une boucle de rétroaction générative dans laquelle une requête sur une description de produit déclenche aussi une requête sur le persona utilisateur pertinent, puis rédige cette description en s’appuyant sur ce persona De la même manière, le langage peut être utilisé comme boucle de rétroaction générative Par exemple, un utilisateur peut vouloir générer des descriptions de produits dans différentes langues Il devient possible de générer des descriptions de produits non seulement personnalisées pour l’utilisateur, mais aussi traduites dans la langue choisie par celui-ci Ce type d’instructions peut être intégré directement dans la base de données, car des cas d’usage comme l’IA générative deviennent de plus en plus une fonction centrale des applications Faire évoluer l’infrastructure en fonction des cas d’usage n’a rien de nouveau À l’origine, les développeurs construisaient des applications dans le navigateur avec JavaScript pour rendre les sites web interactifs et dynamiques Mais lorsque les développeurs ont compris qu’ils pouvaient aussi l’utiliser côté backend, node.js est né Puis, à mesure que les développeurs ont commencé à créer davantage d’applications mobiles, JSON (JavaScript Object Notation) est apparu pour permettre des applications plus dynamiques, réactives et pilotées par les données MongoDB s’est parfaitement inscrit dans cette vague en tant qu’entreprise apparue pour répondre à l’évolution des besoins d’infrastructure Avec l’IA, l’histoire se répète À mesure que les besoins changent, l’infrastructure doit évoluer pour y répondre La plus grande question sera de savoir quel type d’entreprise les gens veulent construire, et quel type d’infrastructure convient le mieux à ce type d’entreprise Comme l’a dit Bob dans une interview avec Matthew Lynley : « Je crois fermement que toutes les applications du futur intégreront de l’IA. Dans certaines, l’IA sera saupoudrée ; dans d’autres, elle sera au cœur de l’application. Si vous retirez l’IA, elles n’existent plus. Si vous voulez construire une web app et y saupoudrer de l’IA, utilisez MongoDB. Surtout si vous l’utilisez déjà... Si vous voulez construire des applications AI-native, où l’IA est le cœur même de l’application, alors il est temps d’envisager Weaviate. » À l’avenir, les entreprises devront décider si elles construisent leur produit avec l’IA comme appendice — ou, comme le dit Bob, comme simple « sprinkle » — ou si elle doit en devenir le cœur Stack technique AI-native Pour les entreprises qui veulent faire de l’IA un composant central de leur produit, l’infrastructure existante a de fortes chances de ne pas convenir Avec des outils legacy, le stockage, l’organisation et l’exécution des données sont construits dans un silo, tandis que l’automatisation est construite dans un autre L’inconvénient de cette approche est la perte de contexte sur des éléments comme les boucles de rétroaction génératives, qui peuvent mieux informer le produit et l’améliorer Pour les entreprises issues d’une stack « AI-adjacent », l’inférence d’un modèle donné est souvent limitée par la fenêtre de contexte Certains pensent qu’une augmentation de la capacité d’une fenêtre de contexte donnée pourrait remplacer les bases de données vectorielles Cependant, le scénario inverse — où les bases de données vectorielles évoluent jusqu’à remplacer la fenêtre de contexte — a plus de chances d’être vrai Les vector embeddings sont essentiels pour les modèles génératifs, et l’infrastructure destinée aux résultats générés doit traiter les vector embeddings comme des citoyens de première classe Au lieu d’augmenter simplement la taille de la fenêtre de contexte, il est possible d’intégrer une base de données vectorielle dans le modèle afin d’offrir à la fois la compréhension contextuelle de la fenêtre de contexte et la fiabilité ainsi que l’évolutivité d’une base de données En particulier, plus un modèle est généraliste, moins il a de chances d’être conçu pour une tâche spécifique Les bases de données vectorielles pilotées par l’IA permettront des fonctionnalités plus ciblées Les modèles généralistes comme GPT-4 ont été conçus pour généraliser délibérément les connaissances Si un produit repose sur un simple fine-tuning, le modèle de base ne constituera pas la partie singulièrement précieuse de cette activité Construire un produit fondé sur l’IA impliquera, au-delà de l’exploitation du modèle, de bâtir le produit autour d’une stack plus étroitement intégrée Cette stack apportera l’échelle d’une base de données et les capacités d’un modèle pour produire des produits plus performants

(research.contrary.com)

23 points par xguru 2024-07-01 | 1 commentaires | Partager sur WhatsApp

Au début des années 2020, l’attention s’est fortement portée sur l’IA générative
- Les discussions ont surtout porté sur la manière dont les outils d’IA générative allaient nous façonner, et sur leur impact sur l’écriture, le code, l’animation et notre façon de consommer l’information
- En revanche, la forme de nos outils a été relativement peu évoquée
À la fin des années 1960, les systèmes d’information ont été confrontés à un problème croissant : le coût de la recherche d’informations pertinentes augmentait à mesure que les volumes de données explosaient
Dans les années 1980 et 1990, les bases de données relationnelles sont devenues la solution dominante
- Elles offraient une indexation intuitive et garantissaient l’efficacité des requêtes
- Elles permettaient de représenter les données sous forme d’un ensemble de tables dotées de relations structurées
- Grâce à des langages de requête comme SQL, elles ont rendu la recherche de données plus rapide
À mesure que l’architecture des bases de données a évolué, certaines entreprises comme IBM, Oracle, Sun Microsystems et MongoDB se sont imposées sur chacun de ces marchés émergents
Si Oracle a dominé l’univers des bases de données relationnelles, la manière dont les gens stockent et accèdent à l’information a continué d’évoluer
- À chaque nouveau type de travail, ils ont imaginé une nouvelle architecture pour le gérer
L’évolution récente des bases de données est née du besoin de traiter des données non structurées
- Pendant plus de 50 ans, les schémas se sont principalement organisés autour de relations de données structurées
- Mais de plus en plus d’utilisateurs ont eu besoin d’outils capables de bien mieux gérer l’ambiguïté des données
- C’est dans ce contexte que les bases de données vectorielles sont apparues
Les grands modèles de langage (LLM) fondés sur les transformeurs, comme GPT, peuvent capter les dépendances de long terme dans le texte
- Mais préserver une compréhension fiable des longs contextes peut être coûteux en calcul
- Les bases de données vectorielles peuvent étendre la fenêtre de contexte de ces modèles
Les bases de données vectorielles peuvent être puissantes pour les cas d’usage de l’IA, mais elles restent une infrastructure stupide, pilotée par des entrées et des sorties
- Elles n’ont pas la capacité de comprendre ni d’interpréter les données
- Elles servent simplement de dépôts qui stockent et récupèrent les données selon les instructions reçues, sans intelligence intrinsèque ni conscience du contexte
Avec le lancement de GPT-3 en 2020, l’IA a pu devenir de plus en plus le cœur des produits d’entreprise plutôt qu’un simple ajout
- L’architecture des transformeurs, l’augmentation des volumes de données et l’amélioration des performances ont posé les bases du développement de produits fondés sur l’IA
À mesure que les entreprises AI-native se multiplient et changent d’échelle, le besoin d’outils capables de prendre en charge des cas d’usage fondés sur l’IA augmente également
- La première vague d’entreprises centrées sur l’IA s’est surtout concentrée sur l’inférence à partir de modèles existants
Mais avec des modèles plus performants, en particulier les modèles open source facilement accessibles, les entreprises peuvent développer plus en profondeur leurs capacités en tant qu’activités fondées sur l’IA
- Cette montée en puissance ouvre un vaste champ de possibilités quant à ce que pourrait être une stack technologique AI-native

Les outils qui nous façonnent (The Tools that Shape Us)

En 1967, John M. Culkin, ami de Marshall McLuhan, disait : « Nous façonnons nos outils, puis nos outils nous façonnent »
- Il en va de même pour la création de technologies
- L’infrastructure que nous utilisons pour construire des logiciels n’a cessé d’évoluer pour répondre à nos besoins de développement, puis nos constructions ont à leur tour été façonnées par l’infrastructure mise en place
Au début des années 2020, l’attention s’est fortement portée sur l’IA générative
- En particulier sur les résultats produits : texte ou code généré, images rendues, deepfakes créés, musique synthétisée
- Les discussions ont surtout porté sur la manière dont ces outils allaient nous façonner, et sur leur impact sur l’écriture, le code, l’animation et notre façon de consommer l’information
- Les gens débattaient des performances comparées des grands modèles de langage ouverts et propriétaires, du risque d’hallucination, du débat plateforme contre fonctionnalité, ou encore de l’opposition entre entreprises établies et startups
En revanche, la forme de nos outils a été relativement peu évoquée
- Fondamentalement, la manière dont nous construisons la technologie a toujours été façonnée par l’infrastructure mise en place pour la construire
- L’essor du SaaS a été accéléré par Internet, le développement mobile a été rendu possible par la généralisation des smartphones, et le cloud computing a favorisé le passage à l’échelle de générations entières d’applications
L’omniprésence de l’IA dans les applications dépend de la puissance de calcul, des capacités des modèles et de la manière dont ces modèles sont orchestrés dans les cas d’usage métier
- Cet article se concentre sur cet élément d’orchestration
- L’un des éléments clés de l’orchestration de tous les cas d’usage de l’IA est la base de données de l’entreprise
- L’endroit où les données sont stockées, manipulées et appelées constitue une pièce essentielle du puzzle
- Mais, comme nous allons le montrer, l’histoire des bases de données a largement été celle d’une infrastructure stupide
- Pour maximiser l’utilité de l’IA, il faudra concevoir des bases de données capables de faire partie de l’équation générative

Une base pour les données (A Base For Data)

En mai 1959, CODASYL (Conference on Data Systems Languages) s’est réuni pour la première fois avec l’ambition de créer « un langage générique pour construire des applications métier »
- À la fin des années 1960, les systèmes d’information ont été confrontés au problème d’un coût croissant de la recherche d’informations pertinentes, en raison du volume massif de données
L’usage des ordinateurs mainframe a généralement entraîné une hausse du coût par MIPS (millions d’instructions par seconde), à mesure que leur utilisation augmentait, en raison notamment des coûts de maintenance applicative, de patching et de mises à niveau nécessaires pour maintenir les performances
- En raison de la complexité de l’administration des bases de données, de hiérarchies rigides et de mappings complexes des structures de navigation, les entreprises avaient souvent besoin d’une expertise technique pour accéder aux informations choisies, et certains développeurs devaient même écrire des programmes entiers pour y accéder
En 1970, E.F. Codd a publié « A Relational Model for Large Shared Data Banks », proposant un modèle dans lequel des tables pouvaient être reliées par des caractéristiques communes, à savoir des clés primaires identifiant des enregistrements uniques et des clés étrangères établissant des relations entre tables
- Cela a permis de récupérer des données à partir de tables hétérogènes avec une seule requête
- La base de données relationnelle de Codd, fondée sur les relations entre les éléments de données, a permis davantage de flexibilité dans la manipulation et l’utilisation des données
En 1973, un groupe de programmeurs du laboratoire de recherche IBM de San Jose a lancé le projet System R, démontrant qu’un système de base de données relationnelle pouvait intégrer toutes les fonctionnalités nécessaires à un usage en production tout en conservant de hautes performances
- L’équipe a développé un optimiseur à base de coûts pour l’efficacité de la base de données, et les avancées issues de System R ont ensuite conduit au lancement de SQL/DS, premier produit de base de données relationnelle d’IBM
Dans les années 1980 et 1990, les bases de données relationnelles sont devenues la solution dominante
- Elles offraient une indexation intuitive et garantissaient l’efficacité des requêtes
- Elles permettaient de représenter les données comme un ensemble de tables liées par des relations structurées
- Elles ont permis une récupération plus rapide des données via des langages de requête comme SQL
Les bases de données relationnelles ont été conçues en partant de l’hypothèse qu’elles s’exécutaient sur une seule machine
- Mais l’adoption massive d’Internet dans les années 1990 et 2000 a provoqué un afflux colossal de données, générant des charges de travail trop lourdes pour un seul ordinateur
- Les bases de données SQL traditionnelles étaient conçues pour fonctionner sur un seul serveur, obligeant les utilisateurs à augmenter le matériel physique en fonction des besoins de stockage, ce qui s’est révélé très coûteux pour les entreprises opérant de plus grosses charges de travail
Dans les années 2010, les données et le nombre d’utilisateurs liés à l’OLTP (online transaction processing) ont augmenté de manière exponentielle, entraînant une forte montée en puissance des bases de données distribuées, des data warehouses et de l’OLAP (online analytical processing)
Les bases de données relationnelles et SQL n’étaient plus adaptées à l’échelle et à la complexité des applications requises, et les bases de données NoSQL ont émergé comme moyen d’améliorer les performances, au prix des garanties ACID
- Les bases de données relationnelles pouvaient stocker et manipuler des données structurées, mais il était difficile de maintenir les relations entre les données compte tenu de l’overhead des jointures et du coût des opérations CRUD
- Elles étaient adaptées au traitement de données relationnelles répondant à des exigences logiques ou discrètes, mais restaient généralement alignées sur des systèmes legacy spécialement conçus pour des structures relationnelles
- NoSQL est apparu comme un moyen de traiter du big data non structuré, en fournissant aux développeurs une persistance des données via une approche non relationnelle
- Au lieu d’utiliser SQL comme langage de requête principal, NoSQL fournit un accès via des API, garantissant une plus grande scalabilité, du calcul distribué, une réduction des coûts et une flexibilité de schéma
- Les bases de données NoSQL reposent sur une architecture efficace pouvant monter en charge horizontalement, de sorte qu’il suffit d’ajouter davantage de serveurs ou d’instances cloud pour augmenter la capacité de stockage ou de calcul
- Pour les entreprises ayant des charges de travail orientées vers un traitement ou une analyse plus rapide de données non structurées, les bases de données NoSQL ont été privilégiées

Les OG database wars

À mesure que l’architecture des bases de données évoluait, certaines entreprises ont consolidé leur position sur chaque marché émergent
- Peu après le lancement de System R par IBM, Larry Ellison, alors âgé de 33 ans, a lu le même article de Codd sur les bases de données relationnelles
- Ellison et ses deux cofondateurs ont tenté de créer une entreprise compatible avec System R, mais IBM a rendu cela très difficile
- En conséquence, le trio a bâti son activité autour d’un nouveau produit phare de base de données, Oracle Databases
- Depuis, la base de données d’Oracle est devenue le produit leader, avec environ 28,7 % de part de marché en mai 2024
Dans les années qui ont précédé l’IPO d’Oracle en 1986, une autre entreprise est entrée dans le secteur des bases de données
- Sun Microsystems a commencé en 1982 par vendre divers composants informatiques, avant de devenir connue pour ses contributions comme le langage de programmation Java, Network File System, entre autres
- Point important : en 2008, Sun Microsystems a acquis MySQL, un système open source de gestion de base de données
- Deux ans plus tard à peine, Oracle a racheté Sun Microsystems, MySQL compris
- Près de 15 ans plus tard, en mai 2024, les bases de données leaders sont Oracle (28,7 % de part de marché) et MySQL (environ 17,3 %)
Si Oracle a dominé le monde des bases de données relationnelles, la manière dont les gens stockent et accèdent à l’information a continué d’évoluer
- À chaque nouveau type de tâche, de nouvelles architectures ont été conçues pour les gérer
- Des document stores comme MongoDB (2007) et Databricks (2013), aux bases de données de séries temporelles comme InfluxDB (2013) et Prometheus (2012), jusqu’aux bases de données graphe comme Neo4j (2007) et Cosmos (2017), la liste des bases de données spécialisées ne cesse de s’allonger
- À mesure que la popularité des bases de données relationnelles déclinait progressivement, diverses solutions sont apparues pour répondre à ces nouveaux besoins de niche
La dernière évolution des bases de données est née de la nécessité de traiter des données non structurées
- Pendant plus de 50 ans, les schémas ont été principalement organisés autour de relations de données structurées
- Mais de plus en plus de personnes ont eu besoin d’outils capables de bien mieux gérer l’ambiguïté des données
- C’est dans ce contexte qu’ont émergé les bases de données vectorielles

L’essor des bases de données vectorielles

Avec la diffusion massive des grands modèles de langage (LLM) et de l’IA générative, les bases de données vectorielles se sont imposées comme des outils capables de traiter des données multimodales non structurées
- Alors que les bases de données relationnelles traditionnelles (Postgres, MySQL) conviennent le mieux aux schémas structurés, les bases de données vectorielles sont adaptées au stockage et à l’interrogation d’embeddings vectoriels (des représentations numériques des données qui intègrent un sens relatif aux poids d’un modèle de langage)
- Au lieu des lignes et colonnes généralement utilisées dans les bases relationnelles, les bases de données vectorielles représentent les données comme des points dans un espace multidimensionnel et établissent des correspondances sur la base de la similarité plutôt que de valeurs exactes
Selon le modèle d’embedding, les données peuvent être représentées dans différents espaces vectoriels et avec diverses dimensions
- Les embeddings vectoriels capturent la signification des points de données, ce qui permet de retrouver des objets similaires en recherchant les objets les plus proches dans une base de données vectorielle
Par exemple, Word2Vec mappe les mots en vecteurs, ce qui aide à capturer le sens, la similarité sémantique et les relations contextuelles avec d’autres textes
- Cet algorithme utilise un réseau de neurones peu profond pour déduire le sens d’un mot donné à partir d’un corpus textuel plus large et identifie les synonymes via une régression logistique
- Il existe aussi des méthodes comme la décomposition en valeurs singulières (SVD) et l’analyse en composantes principales (PCA), qui aident à extraire des embeddings sans dépendre de réseaux de neurones profonds
Les métriques de distance aident à déterminer la « distance » relative entre des points dans un espace vectoriel ; parmi les méthodes courantes figurent la distance euclidienne, la distance de Manhattan, la distance cosinus et la similarité de Jaccard
- Les K plus proches voisins (KNN) et les voisins les plus proches approximatifs (ANN) contribuent à simplifier la recherche de similarité sur des images, des vidéos ou d’autres entrées multimodales, tout en améliorant le temps d’exécution
Des bases de données spécialisées dans les vecteurs, comme Weaviate, Chroma, Qdrant et Pinecone, aident les développeurs à gérer plus facilement la recherche dans de grands volumes de données, en particulier des entrées non structurées
- Contrairement aux bases de données relationnelles ou NoSQL traditionnelles, les bases de données vectorielles sont spécialement conçues pour traiter les embeddings vectoriels
- Là où les bases de données traditionnelles stockent les données sous forme de scalaires, les bases de données vectorielles ne stockent que des vecteurs et exploitent des techniques d’indexation comme la quantification et le clustering pour optimiser les opérations de recherche
Les LLM basés sur des transformers, comme GPT, peuvent capturer les dépendances de long terme dans le texte
- Toutefois, préserver la compréhension des textes longs peut être coûteux sur le plan computationnel
- Les LLM les plus récents peuvent capter les dépendances globales entre paires de tokens sur l’ensemble de l’entrée, mais la complexité en temps et en espace pose des problèmes de ressources de calcul, ce qui limite la longueur du texte d’entrée pendant l’entraînement ainsi que la fenêtre de contexte effective en inférence
Dans les cas multidimensionnels, le codage de position relative est difficile à mettre en œuvre, et la plupart des approches qui encodent les positions relatives nécessitent des mécanismes d’embedding positionnel puissants qui contribuent à une baisse des performances lors de l’inférence
- Même lorsque la longueur du texte augmente, les bases de données vectorielles peuvent jouer un rôle important en servant de mémoire à long terme au modèle
- L’utilisation de bases de données vectorielles peut simplifier des tâches comme la complétion de texte ou le résumé, où le contexte de la phrase entière peut être nécessaire pour générer des résultats précis
Les bases de données vectorielles peuvent prendre en charge la génération augmentée par récupération (RAG), où elles servent à enrichir le prompt transmis au LLM en y ajoutant un contexte supplémentaire avec la requête d’origine
- Les LLM reposent souvent sur des modèles d’apprentissage auto-supervisé, ce qui les met fréquemment en difficulté sur des tâches spécifiques à un domaine nécessitant des connaissances particulières ou un seuil de précision plus élevé
- Le RAG peut aider à vérifier, retracer ou expliquer comment une réponse a été obtenue, tout en atténuant les hallucinations dues à un manque de contexte autour de la requête posée
Les développeurs peuvent combiner graphes de connaissances et recherche vectorielle afin d’étendre les capacités des LLM au-delà des données sur lesquelles ils ont été entraînés
- Des outils comme GraphRAG de Microsoft Research facilitent l’augmentation de prompt lors de recherches sur des jeux de données privés
- Le RAG de base a souvent du mal à appréhender globalement des concepts sémantiques résumés dans de vastes collections de données ; c’est pourquoi des outils comme LlamaIndex et GraphRAG construisent des graphes de connaissances à partir de jeux de données privés
Selon les exigences ou les cas d’usage, il peut être préférable pour les développeurs d’utiliser des graphes de connaissances plutôt que le RAG
- Les bases de données vectorielles conviennent à la recherche de similarité et sont les mieux adaptées à la recherche de documents ou d’images ainsi qu’à la génération de recommandations, tandis que les graphes de connaissances sont mieux adaptés au raisonnement (en particulier pour la collecte de données, l’extraction d’entités avec leurs relations interconnectées et la traversée de ces relations)
Pour les applications nécessitant un traitement des données en temps réel ou quasi réel, les bases de données vectorielles peuvent être privilégiées en raison d’une latence plus faible lors des requêtes
En collectant et en stockant des embeddings, les bases de données vectorielles facilitent une récupération plus rapide dans le cadre de la recherche de similarité, en faisant correspondre le prompt saisi à des embeddings similaires
Le classement par similarité contribue à prendre en charge de nombreuses tâches de machine learning, allant des systèmes de recommandation à la recherche sémantique, à la reconnaissance d’images et à d’autres applications de traitement du langage naturel
Les bases de données vectorielles jouent un rôle clé dans l’amélioration des performances des LLM en permettant le stockage et la récupération efficaces d’embeddings vectoriels
- Cela permet une compréhension automatique du langage naturel à grande échelle
Cependant, les embeddings vectoriels représentent une innovation N+1
- Il s’agit d’un format de données antérieur, comme les données relationnelles ou de séries temporelles
Les fournisseurs historiques de bases de données ont commencé à lancer des fonctionnalités vectorielles, comme Atlas Vector Search de MongoDB, la base de données vectorielle de SingleStore et les index de recherche vectorielle de Neo4J
Même si les bases de données vectorielles peuvent être puissantes pour les cas d’usage IA, elles restent une infrastructure simpliste, pilotée par les entrées et les sorties
- Elles n’ont pas la capacité de comprendre ou d’interpréter les données
- Elles ne font que stocker et récupérer les données selon les instructions reçues, sans intelligence intrinsèque ni conscience du contexte
Pour les applications modernes fondées sur l’IA, cela seul ne suffira pas
- Les entreprises construisent de plus en plus avec les modèles d’IA au cœur de leur activité
- Par conséquent, à mesure que les applications afficheront des capacités toujours plus intelligentes, l’infrastructure devra elle aussi offrir les mêmes capacités intelligentes

Les entreprises AI-native de première génération

Depuis que le monde universitaire a commencé à étudier l’intelligence artificielle pour la première fois au Dartmouth College en 1956, ce sont les cas d’usage pratiques qui ont fait progresser le domaine
- Par exemple, à la fin des années 1960, Joseph Weizenbaum a créé un programme informatique appelé ELIZA, dont l’approche simple de simulation de conversation par appariement de motifs a été utilisée pour des échanges rappelant une forme rudimentaire de thérapie (le premier chatbot)
Pendant la majeure partie de l’histoire de l’usage de l’IA dans les cas d’usage métier, les améliorations de l’IA ont été progressives
Avant que le terme IA ne devienne à la mode, on utilisait plus souvent le terme apprentissage automatique pour désigner la même technologie
- Autrement dit, des « algorithmes statistiques capables d’apprendre à partir de données et de généraliser à des données inédites, afin d’exécuter des tâches sans instructions explicites »
Du point de vue de la perception du grand public, l’IA a atteint un point d’inflexion le 30 novembre 2022, lorsque OpenAI a lancé ChatGPT, mais d’un point de vue technique, le tournant s’était produit bien plus tôt
En novembre 2017, le Conseil de stabilité financière (FSB), un organisme international de régulation, a rédigé une vue d’ensemble de l’impact de l’apprentissage automatique sur les services financiers
- Les entreprises de services financiers pouvaient de plus en plus utiliser l’apprentissage automatique pour effectuer des tâches comme « l’évaluation de la qualité du crédit » et ainsi « contribuer à un système financier plus efficace »
- Autrement dit, cela pouvait améliorer l’efficacité, mais ne constituait pas une nécessité existentielle
Entre-temps, l’apprentissage automatique s’améliorait de plus en plus et, en mai 2018, OpenAI a publié une étude sur l’historique du calcul nécessaire à l’entraînement de grands modèles, montrant qu’il avait doublé tous les 3,4 mois depuis 2012, soit une hausse de 300 000 fois de la puissance de calcul
Le mois suivant, en juin 2018, OpenAI a publié la première présentation du modèle GPT
Un débat commençait à se former entre deux camps
- D’un côté, beaucoup pensaient que la croissance continue de modèles toujours plus grands finirait par se heurter à la loi des rendements décroissants
- L’autre camp, auquel appartenait OpenAI, estimait que les performances continueraient de s’améliorer avec l’augmentation de l’échelle
En janvier 2020, Jared Kaplan, chercheur chez OpenAI et professeur à l’université Johns Hopkins, a publié avec d’autres chercheurs « Scaling Laws for Neural Language Models », où il est écrit :
- « Les performances des modèles de langage s’améliorent de manière fluide et prévisible à mesure que l’on augmente correctement la taille du modèle, les données et la puissance de calcul. Nous nous attendons à ce que des modèles de langage plus grands soient plus performants que les modèles actuels et présentent une meilleure efficacité d’échantillonnage. »
En mai 2020, OpenAI a publié l’article sur GPT-3 intitulé « Language Models are Few-Shot Learners », qui montrait une montée en performance régulière avec l’augmentation de la puissance de calcul
OpenAI a également constaté qu’augmenter l’échelle améliorait aussi la capacité de généralisation, affirmant que « le passage à l’échelle des grands modèles de langage améliore fortement les performances few-shot indépendantes de la tâche, au point de rivaliser parfois avec les précédentes approches de fine-tuning à l’état de l’art »
Le chercheur indépendant Gwern Branwen a formulé l’hypothèse du scaling dans un billet de blog, en écrivant :
- « GPT-3, publié par OpenAI en mai 2020, est le plus grand réseau de neurones jamais entraîné à ce jour, et de plus d’un ordre de grandeur... Contrairement aux attentes de nombreuses personnes (moi y compris), cette augmentation massive d’échelle a continué à produire les bénéfices du passage à l’échelle prédits par OpenAI, sans buter sur les rendements décroissants ou négatifs auxquels beaucoup s’attendaient. »
Cette surprise ressentie par Branwen signalait un changement de paysage
L’IA pouvait être utilisée de plus en plus comme cœur du produit d’une entreprise, et non plus comme simple appendice
L’architecture Transformer, l’augmentation du volume de données et l’amélioration du niveau de performance ont ensemble posé les bases du développement de produits alimentés par l’IA
Peu après la sortie de GPT-3, en mai 2020, des entreprises comme Writer et Jasper ont créé des produits de copywriting plaçant les modèles d’IA au centre de leur activité
Des entreprises comme Harvey et EvenUp ont construit leur legal tech autour de l’IA
Des entreprises comme DeepScribe et Freed ont bâti la transcription médicale autour de l’IA
Mais, de la même manière que de nouveaux cas d’usage avaient autrefois entraîné l’évolution des bases de données, la naissance de produits alimentés par l’IA signifiait aussi que l’infrastructure derrière la stack technique de chaque entreprise devait évoluer et s’adapter

Base de données AI-native

À mesure que les entreprises alimentées par l’IA se multiplient et changent d’échelle, le besoin d’outils capables de prendre en charge des cas d’usage fondés sur l’IA augmente lui aussi
La première vague d’entreprises dont le cœur reposait sur l’IA s’est principalement concentrée sur l’inférence à partir de modèles existants
- Avec des outils de workflow spécialisés pour les applications, le copywriting, la transcription médicale, etc.
- Le cœur du produit est la sortie, comme le texte ou l’image générés par le modèle
Après le DevDay d’OpenAI en novembre 2023, le mème « OpenAI ruined my startup » a commencé à se répandre
- Certains GPT spécialisés ou agents IA semblaient assumer le rôle de ces premières startups IA, car ils se concentraient sur l’inférence à partir de modèles existants
- OpenAI est ainsi devenu, presque par accident, à la fois fournisseur de modèles et d’applications
L’innovation centrée sur les capacités des modèles avançait si vite qu’elle a commencé à apparaître comme une menace pour les startups
Mais à l’inverse, des modèles plus performants, en particulier les modèles open source facilement accessibles, ont permis aux entreprises d’approfondir davantage leurs capacités en tant qu’activité fondée sur l’IA
Construire une stack technique alimentée par l’IA ne consiste pas seulement à ajouter des composants autour du modèle
- À quoi ressemblerait, par exemple, une base de données conçue spécifiquement pour l’IA ?
- Si l’inférence est la sortie importante, alors une base de données AI-native ne doit pas seulement stocker et récupérer des données, mais aussi être capable de prendre des instructions contextuelles sur ce qu’il faut faire avec les données qu’elle stocke
Un exemple peut être la personnalisation de descriptions de produits pour l’e-commerce
- Une base de données vectorielle peut stocker non seulement les embeddings vectoriels des SKU et des descriptions de produits, mais aussi des embeddings correspondant à des personas utilisateurs
- En utilisant toutes ces données contextuelles dans la base, l’infrastructure peut exploiter une boucle de rétroaction générative dans laquelle une requête sur une description de produit déclenche aussi une requête sur le persona utilisateur pertinent, puis rédige cette description en s’appuyant sur ce persona
De la même manière, le langage peut être utilisé comme boucle de rétroaction générative
- Par exemple, un utilisateur peut vouloir générer des descriptions de produits dans différentes langues
- Il devient possible de générer des descriptions de produits non seulement personnalisées pour l’utilisateur, mais aussi traduites dans la langue choisie par celui-ci
- Ce type d’instructions peut être intégré directement dans la base de données, car des cas d’usage comme l’IA générative deviennent de plus en plus une fonction centrale des applications
Faire évoluer l’infrastructure en fonction des cas d’usage n’a rien de nouveau
- À l’origine, les développeurs construisaient des applications dans le navigateur avec JavaScript pour rendre les sites web interactifs et dynamiques
- Mais lorsque les développeurs ont compris qu’ils pouvaient aussi l’utiliser côté backend, node.js est né
- Puis, à mesure que les développeurs ont commencé à créer davantage d’applications mobiles, JSON (JavaScript Object Notation) est apparu pour permettre des applications plus dynamiques, réactives et pilotées par les données
- MongoDB s’est parfaitement inscrit dans cette vague en tant qu’entreprise apparue pour répondre à l’évolution des besoins d’infrastructure
Avec l’IA, l’histoire se répète
- À mesure que les besoins changent, l’infrastructure doit évoluer pour y répondre
- La plus grande question sera de savoir quel type d’entreprise les gens veulent construire, et quel type d’infrastructure convient le mieux à ce type d’entreprise
- Comme l’a dit Bob dans une interview avec Matthew Lynley :
  - « Je crois fermement que toutes les applications du futur intégreront de l’IA. Dans certaines, l’IA sera saupoudrée ; dans d’autres, elle sera au cœur de l’application. Si vous retirez l’IA, elles n’existent plus. Si vous voulez construire une web app et y saupoudrer de l’IA, utilisez MongoDB. Surtout si vous l’utilisez déjà... Si vous voulez construire des applications AI-native, où l’IA est le cœur même de l’application, alors il est temps d’envisager Weaviate. »
À l’avenir, les entreprises devront décider si elles construisent leur produit avec l’IA comme appendice — ou, comme le dit Bob, comme simple « sprinkle » — ou si elle doit en devenir le cœur

Stack technique AI-native

Pour les entreprises qui veulent faire de l’IA un composant central de leur produit, l’infrastructure existante a de fortes chances de ne pas convenir
- Avec des outils legacy, le stockage, l’organisation et l’exécution des données sont construits dans un silo, tandis que l’automatisation est construite dans un autre
- L’inconvénient de cette approche est la perte de contexte sur des éléments comme les boucles de rétroaction génératives, qui peuvent mieux informer le produit et l’améliorer
Pour les entreprises issues d’une stack « AI-adjacent », l’inférence d’un modèle donné est souvent limitée par la fenêtre de contexte
- Certains pensent qu’une augmentation de la capacité d’une fenêtre de contexte donnée pourrait remplacer les bases de données vectorielles
- Cependant, le scénario inverse — où les bases de données vectorielles évoluent jusqu’à remplacer la fenêtre de contexte — a plus de chances d’être vrai
- Les vector embeddings sont essentiels pour les modèles génératifs, et l’infrastructure destinée aux résultats générés doit traiter les vector embeddings comme des citoyens de première classe
Au lieu d’augmenter simplement la taille de la fenêtre de contexte, il est possible d’intégrer une base de données vectorielle dans le modèle afin d’offrir à la fois la compréhension contextuelle de la fenêtre de contexte et la fiabilité ainsi que l’évolutivité d’une base de données
- En particulier, plus un modèle est généraliste, moins il a de chances d’être conçu pour une tâche spécifique
- Les bases de données vectorielles pilotées par l’IA permettront des fonctionnalités plus ciblées
Les modèles généralistes comme GPT-4 ont été conçus pour généraliser délibérément les connaissances
- Si un produit repose sur un simple fine-tuning, le modèle de base ne constituera pas la partie singulièrement précieuse de cette activité
- Construire un produit fondé sur l’IA impliquera, au-delà de l’exploitation du modèle, de bâtir le produit autour d’une stack plus étroitement intégrée
- Cette stack apportera l’échelle d’une base de données et les capacités d’un modèle pour produire des produits plus performants

1 commentaires

savvykang 2024-07-01

J’aimerais voir davantage de cas d’usage autour de la génération d’embeddings vectoriels et de l’utilisation des bases de données vectorielles, afin qu’un workflow standard émerge. Il faudra peut-être attendre encore un an ?