Vers une nouvelle architecture applicative

Les LLM peuvent être utilisés de trois façons par une entreprise. On peut, comme Bloomberg, choisir un modèle open source (ici, Bloom) pour entraîner son propre modèle de fondation. On peut, comme Microsoft Bing ou Morgan Stanley, préférer un fine-tuning (“ajustement”) de GPT-4, de loin le LLM le plus avancé aujourd’hui, avec Palm 2 de Google. Ou encore, on peut choisir l’apprentissage en contexte (in-context learning).

Dans cette approche, la plus courante chez les développeurs en lien avec A16Z, les LLM sont utilisés tels quels, sans ajustement, et leur comportement est contrôlé par des prompts (invites) et des données « contextuelles » privées. La limite semble évidente : l’efficacité des modèles décroît avec la taille du prompt et la fenêtre d’attention (“contexte”) est limitée à 32 000 tokens pour GPT-4 (24 000 mots environ). L’astuce consiste à demander au LLM de construire son propre prompt et choisir, dans un fonds documentaire donné (hébergé dans une base de données vectorielle, de type Pinecone), les documents à soumettre dans le contexte. C’est ainsi, par exemple, qu’a été monté en France ClimbGPT (cf. Qant du 12 mai).

Presque tous les développeurs commencent par utiliser l’API OpenAI, généralement avec le modèle GPT-4 ou GPT-4-32k. Cependant, lorsque les projets passent en production et commencent à se développer, d’autres options sont envisagées : passer à GPT-3.5-turbo, qui est moins cher et plus rapide que GPT-4, ou expérimenter avec d’autres fournisseurs de modèles, open source ou propriétaires. Les applications LLM nécessitent également un hébergement, et les solutions les plus courantes à ce jour sont les options standard comme Vercel ou les grands fournisseurs de cloud.

Descendre de l’IA à la data science…

Le processus de travail comprend trois étapes : le prétraitement des données et l’embedding, la construction de l’invite puis l’exécution de l’invite. D’après A16Z, cela s’avère généralement plus simple que l’entraînement ou l’ajustement du LLM lui-même. En fin de compte, on transforme ainsi un problème d’IA en un problème de data science.

Les données contextuelles pour les applications LLM comprennent les documents texte, les PDF et même des formats structurés comme CSV ou SQL. Les outils de chargement et de transformation des données varient largement, la plupart des développeurs utilisant des outils de gestion d’ETL traditionnels comme Databricks ou Airflow. Il existe des solutions de réplication de données conçues spécifiquement pour les applications LLM, mais elles sont intégrées à des frameworks comme LangChain (lire Qant du 30 mars) ou LlamaIndex.

Pour les embeddings, la plupart des développeurs utilisent l’API OpenAI, en particulier le modèle text-embedding-ada-002, pour donne des résultats satisfaisants pour un coût de plus en plus abordable. Certaines grandes entreprises se tournent vers Cohere, et la bibliothèque Sentence Transformers de Hugging Face reste une référence pour ceux qui préfèrent l’open-source.

La base de données vectorielle, qui stocke, compare et récupère efficacement des milliards d’embeddings, est une étape cruciale du pipeline de prétraitement. Pinecone est le choix le plus courant mais l’éventail de bases de données vectorielles est inclut des solutions open-source comme Weaviate, Vespa et Qdrant, des bibliothèques de gestion vectorielle locales comme Chroma et Faiss, et des extensions OLTP comme pgvector. Pour A16Z, la question principale à long terme est de savoir si les bases de données vectorielles suivront le chemin de leurs homologues OLTP et OLAP, se consolidant autour d’un ou deux grands systèmes.

… et remonter vers le prompt engineering

L’application va surtout se démarquer par la manière dont elle guide le LLMs en incorporant les données contextuelles. Les développeurs commencent généralement par expérimenter des consignes simples, consistant en des instructions directes (utilisation zéro-shot) ou quelques exemples de résultats (utilisation few-shot). Ces consignes peuvent produire de bons résultats mais sont souvent insuffisantes pour une mise en production.

Des stratégies plus avancées visent à ancrer les réponses du modèle à une source de vérité et à fournir un contexte externe non présent lors de l’entraînement du modèle. Des frameworks comme LangChain et LlamaIndex se distinguent ici en gérant les détails de la chaîne de consignes, l’interface avec des APIs externes, la récupération de données contextuelles à partir de bases de données vectorielles et le maintien de la mémoire entre plusieurs appels LLM.

Source:

• Andreessen Horowitz