A16Z : une architecture émergente pour les applications de grands modèles

Note de l'éditeur : L'explosion de l'intelligence artificielle générative a le potentiel de perturber de nombreuses industries, dont l'industrie du logiciel. L'essor du modèle de grande langue (LLM) a entraîné l'explosion d'applications connexes. Les géants de la technologie et les start-up ont lancé diverses applications LLM. Alors, quels types d'outils et de modèles de conception ces applications utilisent-elles ? Cet article résume. L'article est issu d'une compilation.

Source de l'image : générée par l'IA illimitée

Les grands modèles de langage (LLM) sont de nouvelles primitives puissantes pour le développement de logiciels. Mais parce que LLM est si nouveau et se comporte si différemment des ressources informatiques normales, il n'est pas toujours évident de savoir comment utiliser LLM.

Dans cet article, nous partagerons une architecture de référence pour la pile d'applications LLM émergente. L'architecture présentera les systèmes, les outils et les modèles de conception les plus courants que nous avons vus utilisés par les startups d'IA et les entreprises de pointe. Cette pile technologique est encore relativement primitive et peut subir des changements majeurs à mesure que la technologie sous-jacente progresse, mais nous espérons qu'elle pourra fournir une référence utile aux développeurs travaillant aujourd'hui sur le développement LLM.

Ce travail est basé sur des conversations avec des fondateurs et des ingénieurs de startups en IA. En particulier, nous nous appuyons sur les contributions de personnes telles que Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei Zaharia et Jared Zoneraich. Merci pour votre aide!

Pile technologique LLM

La version actuelle de la pile d'applications LLM ressemble à ceci :

Les cases grises sont les composants clés, et celles avec des flèches représentent différents flux de données : la ligne pointillée noire correspond aux données contextuelles fournies par le développeur de l'application pour limiter la sortie, la ligne continue noire correspond à l'invite et quelques exemples d'exemples sont transmis à LLM. , et la ligne continue bleue est Requête de l'utilisateur, la ligne continue rouge est la sortie renvoyée à l'utilisateur

Vous trouverez ci-dessous une liste de liens vers chaque élément pour une référence rapide :

, des outils/systèmes communs pour chaque composant clé de la pile d'applications

Il existe de nombreuses façons de développer avec LLM, y compris la formation de modèles à partir de rien, le réglage fin de modèles open source ou l'exploitation d'API gérées. La pile technologique que nous présentons ici est basée sur l'apprentissage en contexte, un modèle de conception que nous observons que la plupart des développeurs commencent à exploiter (et actuellement possible uniquement avec les modèles de base).

La section suivante explique brièvement ce modèle de conception.

Modèle de conception : apprentissage contextuel

L'idée centrale de l'apprentissage contextuel est de tirer parti des LLM prêts à l'emploi (c'est-à-dire sans aucun réglage fin), puis de contrôler leur comportement grâce à des conseils intelligents et à un conditionnement sur des données "contextuelles" privées.

Par exemple, supposons que vous développiez un chatbot pour répondre à des questions sur une série de documents juridiques. De manière simple, vous pouvez coller tous les documents dans l'invite ChatGPT ou GPT-4, puis poser des questions connexes. Cela peut fonctionner pour de très petits ensembles de données, mais cela ne s'adapte pas. Les plus grands modèles GPT-4 ne peuvent gérer qu'environ 50 pages de texte d'entrée, et les performances (mesurées par le temps d'inférence et la précision) se dégradent considérablement à l'approche de cette limite de fenêtre contextuelle.

L'apprentissage contextuel résout ce problème avec une astuce : au lieu d'envoyer tous les documents à chaque fois qu'une invite LLM est saisie, il n'envoie que les quelques-uns les plus pertinents. Qui aidera à décider quels sont les documents les plus pertinents ? Vous l'avez deviné... LLM.

À un niveau très élevé, ce flux de travail peut être décomposé en trois phases :

• Prétraitement/intégration des données : cette phase stocke les données privées (documents juridiques dans ce cas) pour une récupération ultérieure. En général, les documents sont divisés en morceaux, transmis au modèle d'intégration et stockés dans une base de données spéciale appelée base de données vectorielle. * Construction/récupération d'invites : lorsqu'un utilisateur soumet une requête (dans ce cas, une question juridique), l'application construit une série d'invites, qui sont ensuite soumises au modèle de langage. Les astuces compilées sont souvent combinées avec des modèles d'astuces codés en dur par le développeur ; des exemples de sortie valide sont appelés exemples à quelques prises de vue ; toutes les informations nécessaires sont récupérées via une API externe ; et un ensemble de documents connexes est récupéré à partir d'une base de données vectorielle.
• Exécution/inférence d'indices : une fois les indices compilés, ils sont soumis à des LLM pré-formés pour l'inférence, y compris des API de modèles propriétaires ainsi que des modèles open source ou auto-formés. Au cours de cette phase, certains développeurs ajoutent également des systèmes opérationnels tels que la journalisation, la mise en cache et la validation.

Celles-ci peuvent sembler beaucoup de travail, mais elles sont généralement plus faciles à mettre en œuvre que les alternatives : former le LLM ou affiner le LLM lui-même est en fait plus difficile. Vous n'avez pas besoin d'une équipe dédiée d'ingénieurs en apprentissage automatique pour faire de l'apprentissage contextuel. Vous n'avez pas non plus besoin d'héberger votre propre infrastructure ou d'acheter des instances dédiées coûteuses auprès d'OpenAI. Ce modèle réduit efficacement les problèmes d'IA à des problèmes d'ingénierie de données que la plupart des startups ainsi que les grandes entreprises savent déjà résoudre. Il a également tendance à surpasser le réglage fin pour des ensembles de données relativement petits, car des informations spécifiques doivent avoir eu lieu au moins environ 10 fois dans l'ensemble de formation avant que le LLM puisse être affiné pour mémoriser des informations spécifiques, et l'apprentissage contextuel peut également incorporer de nouvelles informations. en temps quasi réel.

L'une des plus grandes questions de l'apprentissage contextuel est la suivante : que se passe-t-il si nous modifions simplement le modèle sous-jacent pour augmenter la fenêtre contextuelle ? C'est en effet possible, et c'est un domaine de recherche actif. Mais cela s'accompagne de certains compromis - principalement le coût et le temps d'inférence s'échelonnent de manière quadratique avec la longueur de l'indice. Aujourd'hui, même la mise à l'échelle linéaire (le meilleur résultat théorique) est trop coûteuse pour de nombreuses applications. Aux tarifs actuels de l'API, une seule requête GPT-4 sur 10 000 pages coûterait des centaines de dollars. Par conséquent, nous ne prévoyons pas de modifications à grande échelle de la pile basées sur des fenêtres de contexte étendues, mais nous développerons cela plus tard.

Dans le reste de cet article, nous allons parcourir cette pile technologique en utilisant le flux de travail ci-dessus comme guide.

## Traitement/intégration des données

Partie traitement/intégration des données : transmettre les données au modèle intégré via le pipeline de données pour la vectorisation, puis les stocker dans la base de données vectorielle

Les données contextuelles pour les applications LLM incluent les documents texte, les PDF et même les formats structurés comme les tableaux CSV ou SQL. Les solutions de chargement et de transformation des données (ETL) employées par les développeurs que nous avons interrogés variaient considérablement. La plupart utilisent des outils ETL traditionnels, tels que Databricks ou Airflow. Certains tirent également parti des chargeurs de documents intégrés au cadre d'orchestration, tels que LangChain (alimenté par Unstructed) et LlamaIndex (alimenté par Llama Hub). Cependant, nous pensons que cette partie de la pile technologique est relativement sous-développée et qu'il existe une opportunité de développer une solution de réplication de données spécifiquement pour les applications LLM.

En ce qui concerne l'intégration, la plupart des développeurs utilisent l'API OpenAI, en particulier le modèle text-embedding-ada-002. Ce modèle est facile à utiliser (surtout si vous utilisez déjà d'autres API OpenAI), donne des résultats raisonnablement bons et devient moins cher. Certaines grandes entreprises explorent également Cohere, dont le travail sur les produits est davantage axé sur l'intégration et offre de meilleures performances dans certains scénarios. Pour les développeurs qui préfèrent l'open source, la bibliothèque Sentence Transformers de Hugging Face est la norme. Il est également possible de créer différents types d'incrustations selon les cas d'utilisation ; c'est une pratique relativement niche aujourd'hui, mais un domaine de recherche prometteur.

D'un point de vue système, la partie la plus importante du pipeline de prétraitement est la base de données vectorielles. Une base de données vectorielle est chargée de stocker, de comparer et de récupérer efficacement jusqu'à des milliards d'incorporations (alias vecteurs). L'option la plus courante que nous voyons sur le marché est Pinecone. C'est la valeur par défaut, il est facile de démarrer car il est entièrement hébergé dans le cloud et possède de nombreuses fonctionnalités dont les grandes entreprises ont besoin en production (par exemple, de bonnes performances à grande échelle, une authentification unique et un SLA de disponibilité).

Cependant, il existe également un grand nombre de bases de données vectorielles disponibles. Les plus notables incluent :

• Systèmes Open Source tels que Weaviate, Vespa et Qdrant : ces systèmes ont généralement d'excellentes performances à nœud unique et peuvent être personnalisés pour des applications spécifiques, ce qui les rend populaires auprès des équipes d'IA expérimentées qui aiment développer des plates-formes personnalisées.
• Faiss et al Bibliothèques natives de gestion des vecteurs : ces bibliothèques disposent d'une vaste expérience de développement et sont faciles à démarrer pour les petites applications et les expériences de développement. Mais celles-ci ne remplaceront pas nécessairement des bases de données complètes à grande échelle. * Extensions OLTP telles que pgvector : idéales pour les développeurs qui voient des trous dans chaque forme de base de données et tentent de se connecter à Postgres, ou pour les entreprises qui achètent la majeure partie de leur infrastructure de données auprès d'un seul fournisseur de cloud. Solution de prise en charge vectorielle Nice. Il n'est pas clair que le couplage étroit des charges de travail vectorielles par rapport aux charges de travail scalaires ait un sens à long terme.

À l'avenir, la plupart des sociétés de bases de données vectorielles open source développent des produits cloud. Nos recherches montrent que l'obtention de performances robustes dans le cloud est un problème très difficile dans le vaste espace de conception des cas d'utilisation possibles. Ainsi, l'ensemble d'options peut ne pas changer radicalement à court terme, mais il peut le faire à long terme. La question clé est de savoir si les bases de données vectorielles seront regroupées autour d'un ou deux systèmes populaires similaires aux bases de données OLTP et OLAP.

Il y a aussi la question ouverte de savoir comment l'intégration et les bases de données vectorielles évolueront à mesure que la fenêtre de contexte disponible pour la plupart des modèles s'élargit. Vous pourriez facilement affirmer que l'intégration devient moins importante car les données contextuelles peuvent être placées directement dans l'invite. Cependant, les commentaires des experts sur le sujet suggèrent que le contraire est le cas - que les pipelines intégrés peuvent devenir plus importants avec le temps. Les grandes fenêtres contextuelles sont en effet des outils puissants, mais nécessitent également des coûts de calcul importants. Par conséquent, il est impératif d'utiliser efficacement cette fenêtre. Nous pourrions commencer à voir différents types de modèles d'intégration devenir populaires, former directement sur la pertinence du modèle et émerger des bases de données vectorielles conçues pour permettre et exploiter cela.

Construire rapidement et obtenir

Construire rapidement et obtenir

Les stratégies qui incitent au LLM et intègrent des données contextuelles sont de plus en plus sophistiquées et également utilisées comme source de différenciation des produits, et leur rôle prend de plus en plus d'importance. La plupart des développeurs démarrent de nouveaux projets en expérimentant des conseils simples qui incluent soit des instructions directes (conseils zéro-shot) ou une sortie pouvant contenir des exemples (conseils peu-shot). Ces conseils produisent généralement de bons résultats, mais pas le niveau de précision requis pour les déploiements en production.

Le niveau suivant d'astuces consiste à baser les réponses du modèle sur une source de vérité et à fournir un contexte externe sur lequel le modèle n'a pas été formé. Le Cue Engineering Guide répertorie pas moins d'une douzaine (!) de stratégies de repérage plus avancées, y compris des chaînes de pensée, des connaissances auto-cohérentes et génératives, des arbres de pensée, des stimuli directionnels, etc. Ces stratégies peuvent être combinées pour prendre en charge différents cas d'utilisation LLM tels que les questions-réponses sur les documents, les chatbots, etc.

C'est là qu'interviennent les frameworks d'orchestration comme LangChain et LlamaIndex. Ces cadres éliminent de nombreux détails du chaînage d'indices ; l'interaction avec des API externes (y compris la détermination du moment où un appel d'API est requis ); la récupération de données de contexte à partir d'une base de données vectorielle ; et le maintien de la mémoire entre les appels sur plusieurs LLM. Ils fournissent également des modèles pour de nombreuses applications courantes mentionnées ci-dessus. Sa sortie est un indice ou une série d'indices soumis au modèle de langage. Ces frameworks sont largement utilisés par les amateurs ainsi que par les startups cherchant à développer des applications, LangChain étant le leader.

LangChain est encore un projet relativement nouveau (actuellement en version 0.0.201), mais nous commençons déjà à voir des applications développées avec lui entrer en production. Certains développeurs, en particulier les premiers utilisateurs de LLM, préfèrent passer à Python brut en production pour supprimer les dépendances supplémentaires. Mais nous nous attendons à ce que cette approche de bricolage diminue dans la plupart des cas d'utilisation, comme c'est le cas avec les piles d'applications Web traditionnelles.

Les lecteurs aux yeux d'aigle remarqueront une entrée étrange dans la zone de mise en page : ChatGPT. Dans des circonstances normales, ChatGPT est une application, pas un outil de développement. Mais il est également accessible en tant qu'API. Et, si vous regardez attentivement, il exécute certaines des mêmes fonctions que d'autres frameworks d'orchestration, telles que : supprimer le besoin d'indications personnalisées ; maintenir l'état ; récupérer des données contextuelles via des plugins, des API ou d'autres sources. Bien que ChatGPT ne soit pas un concurrent direct des autres outils répertoriés ici, il peut être considéré comme une solution alternative et pourrait finir par être une alternative viable et facile à la construction rapide.

Exécution/raisonnement des indices

Exécution/raisonnement des indices

Aujourd'hui, OpenAI est un leader dans le domaine des modèles de langage. Presque tous les développeurs que nous avons interrogés ont lancé une nouvelle application LLM à l'aide de l'API OpenAI, généralement ils utilisent le modèle gpt-4 ou gpt-4-32k. Cela fournit le meilleur scénario d'utilisation pour les performances de l'application et est facile à utiliser car il peut utiliser un large éventail de domaines d'entrée et ne nécessite souvent pas d'ajustement ou d'auto-hébergement.

Une fois qu'un projet est en production et commence à évoluer, un plus large éventail d'options peut entrer en jeu. Certaines questions courantes que nous entendons incluent :

• Passer au gpt-3.5-turbo : c'est environ 50 fois moins cher que le GPT-4 et nettement plus rapide. De nombreuses applications n'ont pas besoin d'une précision de niveau GPT-4, mais en ont besoin pour une inférence à faible latence et une prise en charge économique pour les utilisateurs gratuits.
• Expérimenté avec d'autres fournisseurs propriétaires (en particulier le modèle Claude d'Anthropic) : Claude offre une inférence rapide, une précision de niveau GPT-3.5, davantage d'options de personnalisation pour les gros clients et des fenêtres contextuelles jusqu'à 100 000 (bien que nous ayons constaté que la précision diminue avec l'augmentation de la longueur d'entrée) .
• Classer les requêtes partielles pour les modèles open source : ceci est particulièrement efficace pour les cas d'utilisation B2C à volume élevé comme la recherche ou le chat, où la complexité des requêtes varie considérablement et où les utilisateurs gratuits doivent être servis à moindre coût :

1. Cela a généralement plus de sens en combinaison avec le réglage fin du modèle de base open source. Nous n'aborderons pas cette pile d'outils dans cet article, mais des plates-formes telles que Databricks, Anyscale, Mosaic, Modal et RunPod sont de plus en plus utilisées par les équipes d'ingénierie.

2. Les modèles open source peuvent utiliser plusieurs options d'inférence, y compris l'interface API simple de Hugging Face and Replicate ; les ressources informatiques brutes des principaux fournisseurs de cloud ; et les produits cloud (cloud opiniâtre) avec des préférences plus claires comme celles répertoriées ci-dessus.

Actuellement, le modèle open source est à la traîne par rapport aux produits propriétaires, mais l'écart commence à se combler. Le modèle LLaMa de Meta a établi de nouvelles normes de précision open source et a engendré une gamme de variantes. Étant donné que LLaMa n'est autorisé qu'à des fins de recherche, de nombreux nouveaux fournisseurs ont commencé à former des modèles de base alternatifs (par exemple, Together, Mosaic, Falcon, Mistral). Meta discute toujours de l'opportunité de lancer une véritable version open source de LLaMa 2.

Lorsque (pas si) le LLM open source atteint des niveaux de précision comparables à GPT-3.5, nous nous attendons à ce que le texte ait également son propre moment de diffusion stable, avec des modèles d'expérimentation, de partage et d'ajustement à grande échelle entrant en production. Des sociétés d'hébergement comme Replicate ont commencé à ajouter des outils pour rendre ces modèles plus accessibles aux développeurs de logiciels. Les développeurs pensent de plus en plus que des modèles plus petits et affinés peuvent atteindre une précision de pointe pour une gamme restreinte de cas d'utilisation.

La plupart des développeurs que nous avons interrogés n'avaient pas une compréhension approfondie des outils opérationnels de LLM. La mise en cache est relativement courante (souvent basée sur Redis), car elle améliore le temps de réponse des applications et réduit les coûts. Des outils tels que Weights & Biases avec MLflow (porté de l'apprentissage automatique traditionnel) ou Layer avec Helicone (conçu pour LLM) sont également assez largement utilisés. Ces outils peuvent enregistrer, suivre et évaluer la sortie du LLM, souvent dans le but d'améliorer la construction de la pointe, de régler les pipelines ou de sélectionner des modèles. De nombreux nouveaux outils sont également en cours de développement pour valider la sortie LLM (par exemple, Guardrails) ou détecter les attaques par injection d'indices (par exemple, Rebuff). La plupart de ces outils opérationnels encouragent l'utilisation de leurs propres clients Python pour effectuer des appels LLM, il sera donc intéressant de voir comment ces solutions coexistent dans le temps.

Enfin, la partie statique de l'application LLM (c'est-à-dire tout ce qui n'est pas le modèle) doit également être hébergée quelque part. De loin, les solutions les plus courantes que nous avons vues sont des options standard comme Vercel ou les principaux fournisseurs de cloud. Cependant, deux nouvelles catégories font leur apparition. Des startups comme Steamship fournissent un hébergement de bout en bout pour les applications LLM, y compris l'orchestration (LangChain), le contexte de données multi-locataires, les tâches asynchrones, le stockage vectoriel et la gestion des clés. Des entreprises comme Anyscale et Modal permettent aux développeurs d'héberger des modèles et du code Python en un seul endroit.

Qu'en est-il des proxys ?

L'un des composants les plus importants manquant dans cette architecture de référence est le framework d'agent d'intelligence artificielle. AutoGPT a été décrit comme "une tentative open-source expérimentale d'automatisation complète de GPT-4", et ce printemps, il est devenu le référentiel Github à la croissance la plus rapide de l'histoire, et presque tous les projets ou startups d'IA intègrent aujourd'hui une forme de L'agent entre .

La plupart des développeurs à qui nous avons parlé étaient très enthousiasmés par le potentiel des proxys. Le modèle d'apprentissage contextuel que nous décrivons dans cet article peut résoudre efficacement les problèmes d'hallucinations et de fraîcheur des données, soutenant ainsi mieux les tâches de génération de contenu. Les agents, quant à eux, offrent un tout nouvel ensemble de capacités pour les applications d'IA : résoudre des problèmes complexes, agir sur le monde extérieur et tirer des enseignements de l'expérience post-déploiement. Cela se fait grâce à une combinaison de raisonnement/planification avancés, d'utilisation d'outils et de mémoire/récursivité/pensée autoréflexive.

En tant que tels, les agents ont le potentiel de devenir un élément central de l'architecture d'application LLM (ou même de prendre en charge l'ensemble de la pile technologique, si vous croyez en l'auto-amélioration récursive). Les frameworks existants comme LangChain intègrent déjà une partie du concept de proxy. Il y a juste un problème : les procurations ne fonctionnent pas encore vraiment. Aujourd'hui, la plupart des frameworks d'agents en sont encore au stade de la preuve de concept, offrant des démonstrations incroyables mais n'exécutant pas les tâches de manière fiable et répétable. Nous suivons de près l'évolution du proxy dans un avenir proche.

Tourné vers l'avenir

Les modèles d'IA pré-entraînés représentent le changement le plus important dans l'architecture logicielle depuis Internet. Ils permettent aux développeurs individuels de créer des applications d'IA incroyables en quelques jours, dépassant même les projets d'apprentissage automatique supervisés qui prenaient des mois à développer par de grandes équipes.

Les outils et les modèles que nous énumérons ici peuvent être un point de départ pour l'intégration du LLM, et non un état final. Nous mettons également à jour lorsqu'il y a des changements de rupture (par exemple, le passage à la formation de modèles) et publions de nouvelles architectures de référence là où cela a du sens.