- L'architecture de référence pour la stack des applications LLM, résumée par a16z
Emerging LLM App Stack
Données contextuelles
- Pipelines de données : Databricks, Airflow, Unstructured,..
- Modèle d'embedding : OpenAI, Cohere, Hugging Face
- Base de données vectorielle : Pinecone, Weaviate, Chroma, pgvector
Exemples few-shot dans le prompt
- Playground : OpenAI, nat.dev, Humanloop
- Orchestration : Pytion/DIY, LangChain, LlamaIndex, ChatGPT
- APIs/Plugins : Serp, Wolfram, Zapier,...
Requête et sortie
- Hébergement d'application : Vercel, Steamship, Streamlit, Modal
- Cache LLM : Redis, SQLite, GPTCache
- Logging/LLMOps : Weights & Biases, MLflow, PromptLayer, Helicone
- Validation : Guardrails, Rebuff, Guidance, LMQL
APIs LLM et hébergement
- API propriétaire : OpenAI, Anthropic
- API ouverte : Hugging Face, Replicate
- Fournisseur cloud : AWS, GCP, Azure, Coreweave
- Cloud spécialisé : Databricks, Anyscale, Mosaic, Modal, Runpod,...
Pattern de conception : apprentissage in-context
- Apprentissage in-context : utiliser le LLM tel quel, sans fine-tuning, en s'appuyant sur un prompting intelligent et des conditions basées sur certaines données « contextuelles »
- Exemple : pour créer un chatbot qui répond sur des documents juridiques, une approche naïve consisterait à envoyer tous les documents à ChatGPT puis à poser la question, mais cela n'est possible qu'avec de petits jeux de données. Même le plus grand modèle de ChatGPT ne peut traiter qu'environ 50 pages
Dans l'apprentissage in-context, on n'envoie que les documents pertinents, puis on obtient la réponse à partir de ceux-ci - Cela se compose donc d'un workflow en 3 étapes :
- Étape 1. Prétraitement des données / embedding
- Étape 2. Construction du prompt / récupération des documents pertinents depuis la base vectorielle
- Étape 3. Exécution du prompt / inférence
- Cela peut sembler demander beaucoup de travail, mais c'est bien plus simple que d'entraîner et de fine-tuner le LLM lui-même
Étape 1. [Prétraitement des données / embedding]
→ Les données contextuelles passent par un pipeline de données, puis par un modèle d'embedding, avant d'être stockées dans une base de données vectorielle
Données contextuelles
- Documents texte, PDF, CSV et tables SQL
- Dans la plupart des cas, le chargement et la transformation des données utilisent tels quels les outils ETL existants (Databricks, Airflow)
- Dans certains cas, on utilise les chargeurs de documents intégrés à des frameworks d'orchestration comme LangChain et LlamaIndex
- Cette partie de la stack semble encore relativement peu développée, et il existe des opportunités pour des solutions de réplication de données conçues spécifiquement pour les applications LLM
Embeddings
- La plupart des développeurs utilisent l'API OpenAI (modèle
text-embedding-ada-002)- Elle est facile à utiliser, donne des résultats raisonnablement bons et devient de moins en moins chère
- Certaines grandes entreprises explorent Cohere, qui 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 référence.
- Il est aussi possible de générer différents types d'embeddings selon le cas d'usage
- C'est un cas de niche, mais un domaine de recherche prometteur
Base de données vectorielle
- La partie la plus importante du pipeline de prétraitement est la base de données vectorielle
- Elle sert à stocker, comparer et rechercher efficacement jusqu'à des dizaines de milliards d'embeddings (vecteurs)
- Le choix le plus courant sur le marché est Pinecone
- Entièrement hébergé dans le cloud, donc facile à démarrer
- Dispose de nombreuses fonctionnalités nécessaires à la production en entreprise à grande échelle (bonnes performances, SSO, SLA de disponibilité, etc.)
- Mais il existe énormément de bases de données vectorielles disponibles, notamment :
- des solutions open source comme Weaviate, Vespa et Qdrant
- offrant d'excellentes performances sur un nœud unique et pouvant être ajustées à des applications spécifiques
- très populaires auprès des équipes IA expérimentées qui préfèrent construire une plateforme sur mesure
- des bibliothèques locales de gestion vectorielle comme Chroma et Faiss
- excellente expérience développeur
- faciles à exploiter pour les petites applications et les expérimentations de développement
- elles ne sont pas destinées à remplacer une base de données complète à grande échelle
- des extensions OLTP comme pgvector
- une bonne solution pour le support vectoriel pour les développeurs qui veulent faire entrer tous leurs besoins de base de données dans Postgres, ou pour les entreprises qui achètent l'essentiel de leur infrastructure de données auprès d'un seul fournisseur cloud
- à long terme, on ne sait pas encore clairement s'il est pertinent de coupler étroitement les workloads vectoriels et scalaires
- des solutions open source comme Weaviate, Vespa et Qdrant
- À plus long terme, la plupart des entreprises open source de bases de données vectorielles développent des offres cloud
- D'après nos recherches, il est très difficile d'obtenir d'excellentes performances dans le cloud sur des cas d'usage variés
- Ce paysage pourrait donc ne pas changer à court terme, mais il a de fortes chances d'évoluer sur le long terme
- La question clé est de savoir si les bases de données vectorielles se consolideront autour d'un ou deux systèmes dominants, comme cela s'est produit pour les usages OLTP et OLAP
- Une autre question est de savoir comment les embeddings et les bases de données vectorielles vont évoluer à mesure que la fenêtre de contexte disponible dans la plupart des modèles s'agrandit
- On pourrait être tenté de dire que les embeddings deviendront inutiles puisqu'on pourra mettre toutes les données contextuelles dans le prompt,
- mais les retours d'experts indiquent au contraire que les pipelines d'embedding pourraient devenir encore plus importants
- Les grandes fenêtres de contexte sont un outil puissant, mais elles ont un coût de calcul significatif. L'enjeu prioritaire est donc de les utiliser efficacement
- Nous allons désormais voir se démocratiser différents types de modèles d'embedding, entraînés directement avec une pertinence liée au modèle, ainsi que des bases de données vectorielles capables de les activer et de les exploiter efficacement
Étape 2. [Construction du prompt / retrieval]
- Les stratégies d'intégration du prompting LLM avec des données adaptées au contexte deviennent de plus en plus complexes et prennent de plus en plus d'importance comme source de différenciation produit
- La plupart des développeurs commencent un nouveau projet avec des prompts simples composés soit d'instructions directes (zero-shot prompting), soit de quelques exemples (few-shot prompting)
- Ces prompts peuvent parfois donner de bons résultats, mais ils n'atteignent pas le niveau de précision requis pour un déploiement en production
- L'étape suivante du prompting consiste à ancrer les réponses du modèle dans une source de vérité et à lui fournir un contexte externe sur lequel il n'a pas été entraîné
- Le Prompt Engineering Guide recense 12 stratégies avancées de prompting
- C'est ici que des frameworks d'orchestration comme LangChain/LlamaIndex brillent vraiment
- Ils abstraient de nombreux détails du chaînage de prompts
- intégration d'API externes, récupération de données contextuelles depuis une base vectorielle, conservation de la mémoire entre plusieurs appels LLM, etc.
- Ils fournissent aussi des templates pour de nombreux programmes courants
- Leur sortie correspond à un prompt, ou à plusieurs prompts, à envoyer au modèle de langage
- LangChain est aujourd'hui le plus utilisé parmi les startups et les développeurs hobbyistes
- LangChain est encore un projet récent (version actuelle 0.0.220)
- mais on commence déjà à voir des applications construites avec lui en production
- Certains développeurs, en particulier les early adopters du LLM, préfèrent revenir à du Python pur en production pour supprimer les dépendances
- Mais nous pensons que cette approche DIY diminuera progressivement, comme dans la stack des applications web (où la plupart utilisent les frameworks existants)
- Les lecteurs attentifs auront remarqué la présence de ChatGPT dans la case orchestration
- En général, ChatGPT n'est pas un outil développeur mais une application, même s'il est accessible via API
- D'une certaine manière, il remplit des fonctions similaires à ces frameworks d'orchestration (abstraction des prompts, maintien de l'état, récupération de données contextuelles via des plugins, etc.)
- Il n'est pas un concurrent direct des outils évoqués ici, mais peut être considéré comme une solution alternative. Cela peut constituer une alternative simple, rapide à mettre en place et utilisable immédiatement
Étape 3. [Exécution du prompt / inférence]
- À l'heure actuelle, OpenAI est le leader des modèles de langage
- Presque tous les développeurs commencent le développement d'applications LLM avec les modèles GPT-4 et GPT-4-32k
- Ils sont faciles à utiliser, exploitables sur des domaines variés, et ne nécessitent ni fine-tuning ni self-hosting
- Une fois en production et à plus grande échelle, différentes options deviennent possibles
- passer à
gpt-3.5-turbo:- plus de 50 fois moins cher et bien plus rapide que GPT-4
- un choix adapté lorsqu'on n'a pas besoin du niveau de précision de GPT-4, qu'on veut un temps de réponse rapide, ou qu'il faut servir efficacement des utilisateurs gratuits
- expérimenter avec les modèles d'autres fournisseurs (notamment Claude d'Anthropic)
- Claude offre une inférence rapide, une précision au niveau de GPT-3.5, davantage d'options de personnalisation, et une fenêtre de contexte allant jusqu'à 100k (même si la précision baisse quand la longueur augmente)
- router certaines requêtes vers des modèles open source
- cela peut être efficace pour des cas d'usage B2C à grande échelle comme la recherche ou le chat, où les requêtes ont des niveaux de complexité variés ou lorsqu'il faut servir des utilisateurs gratuits à faible coût
- passer à
- Les modèles open source sont encore en train de rattraper les produits propriétaires, mais l'écart commence à se réduire
- Les modèles LLaMA de Meta ont établi une nouvelle référence en matière de précision open source et ont suscité de nombreuses variantes
- LLaMA n'était autorisé qu'à des fins de recherche, mais de nombreux fournisseurs se sont mobilisés pour entraîner des modèles de base alternatifs (Together, Mosaic, Falcon, Mistral)
- Meta discute du lancement du véritable modèle open source LLaMa 2
- Quand les LLM open source atteindront un niveau de précision comparable à GPT-3.5, on peut s'attendre pour le texte à un moment comparable à celui de Stable Diffusion
- expérimentation à grande échelle, partage, mise en production de modèles fine-tunés, etc.
- Des sociétés d'hébergement comme Replicate ajoutent déjà des outils pour permettre aux développeurs d'utiliser plus facilement ces modèles
- De plus en plus de développeurs pensent que des modèles plus petits mais fine-tunés peuvent atteindre la précision des modèles de pointe
- La plupart des développeurs avec qui nous avons échangé n'étaient pas encore entrés en profondeur dans les outils d'exploitation pour les LLM
- Le caching est courant, généralement avec Redis (car il améliore le temps de réponse et le coût)
- Des outils comme Weights & Biases, MLFlow, PromptLayer et Helicone sont aussi largement utilisés
- ils permettent de journaliser, tracer et évaluer les sorties LLM pour accélérer la création de prompts, l'ajustement des pipelines et le choix des modèles
- On voit également apparaître de nombreux outils de validation des sorties LLM (Guardrails) ou de détection de prompt injection (Rebuff)
- La plupart de ces outils d'exploitation recommandent d'effectuer les appels LLM via leur propre client Python, il sera donc intéressant d'observer comment ils cohabiteront à l'avenir
- Enfin, la partie statique des LLM (tout ce qui n'est pas le modèle) doit elle aussi être hébergée quelque part
- Les solutions les plus courantes sont Vercel ou les grands fournisseurs cloud
- Mais deux nouvelles catégories émergent
- Steamship propose un hébergement end-to-end pour les applications LLM, avec des fonctions telles que l'orchestration (LangChain), le contexte de données multi-tenant, les tâches asynchrones, le stockage vectoriel, la gestion des clés, etc.
- Anyscale et Modal permettent aux développeurs d'héberger simultanément les modèles et le code Python
Et les agents ?
- L'élément le plus important manquant dans cette architecture de référence est le framework d'agents IA
- AutoGPT a été ce printemps le dépôt GitHub à la croissance la plus rapide de l'histoire, présenté comme une « expérience open source visant à rendre GPT-4 entièrement autonome »
- Aujourd'hui, presque tous les projets IA incluent une forme ou une autre d'agent
- La plupart des développeurs avec qui nous avons parlé sont très enthousiastes quant au potentiel des agents
- Le pattern d'apprentissage in-context décrit dans cet article est particulièrement adapté aux tâches de génération de contenu et permet de mieux traiter les problèmes d'hallucination et de fraîcheur des données
- Les agents, en revanche, apportent des capacités fondamentalement nouvelles aux applications IA
- résoudre des problèmes complexes, agir sur le monde extérieur, ou apprendre de l'expérience après le déploiement
- grâce à une combinaison de raisonnement/planification avancés, d'utilisation d'outils, de mémoire/récursivité/self-reflection, etc.
- Les agents pourraient devenir l'élément central de l'architecture des applications LLM (et, si l'on croit à leur auto-amélioration par récursivité, ils pourraient même occuper toute la stack)
- Des frameworks comme LangChain ont déjà intégré le concept d'agent
- Le seul problème, c'est que les agents ne fonctionnent pas encore vraiment correctement
- La plupart des frameworks d'agents en sont encore au stade PoC : ils permettent des démos impressionnantes, mais ne sont ni stables ni reproductibles
- Nous suivons de près leur évolution
Perspectives
- Les modèles d'IA préentraînés constituent le changement d'architecture le plus important du logiciel depuis Internet
- Ils permettent désormais à chaque développeur de construire en quelques jours des applications IA capables de dépasser des projets de machine learning supervisé qui demanderaient des mois de travail à de grandes équipes
- Les outils et patterns présentés ici ne sont probablement pas un état final, mais plutôt un point de départ pour l'intégration des LLM
6 commentaires
C’est un article qui dégage une vraie profondeur et des insights pertinents.
Je pense qu’il sera d’une grande aide pour concevoir une architecture d’application LLM sur cette base.
Comme il n’y a pas encore de gagnant clairement établi par domaine dans l’écosystème, de nombreuses solutions coexistent.
Le problème du choix devient donc de plus en plus important, et on entre dans une phase où la vraie compétence consiste à trouver la bonne combinaison adaptée à ses besoins.
C’est un article extrêmement riche. Je suis en train de le lire attentivement.
Si on entraîne le LLM sur GN, est-ce que ça facilitera aussi la vie de guru ? ^^;
Merci.
Ah, vous avez donc créé GN+ :-o
Ça deviendra sans doute plus pratique, mais je pense que je continuerai à lire ce genre d’articles en me disant que c’est une façon d’étudier. Haha
Si GN⁺ traite toutes les autres actualités, cela pourrait aussi avoir pour effet de faire augmenter le nombre d’articles de ce type !
Merci pour cet excellent article et ce résumé.