E-Veille IA Générative France #16
Semaine du 13 au 20 octobre (plus ou moins)
Retrouvez un résumé de l'actualité Generative AI en français sélectionnée par Adrien Maret.
✍️ L’édito
Après presque 3 mois d’absence, j’ai enfin réussi à sacraliser du temps pour continuer à sortir cette newsletter. Je vais continuer à essayer de tenir le rythme d’une sortie par semaine, quitte à faire des éditions avec seulement quelques nouveautés.
La principale raison c’est que comme tout le monde je n’ai qu’un temps limité à ma disposition et celui-ci doit d’abord être divisé entre mon travail et ma vie perso (le fameux équilibre perso/pro).
Dans mon temps de travail, la majeur partie est allouée à Didask avec de la GenAI en production pour de la génération de contenu et un assistant pédagogique.
Le reste doit se partager entre l’organisation du Meetup Montpellier GenAI et mon activité de conseil technologique et produit en GenAI, ce qui ne me laisse pas toujours le temps de pousser ma veille autant que je le voudrais 🥲
Projet d’Assistant E-commerce
Justement dans le cadre de mon activité de conseil, j’ai travaillé avec une entreprise Montpelliéraine pour la réalisation d’un Assistant générique branché sur les sites e-commerce dans le but d’améliorer la performance des ventes.
Je ne peux pas trop en dire plus pour le moment à part que la première version est bluffante et que pour l’instant il n’y a rien de semblable sur le marché 😄
Bref, pour continuer à avancer, nous cherchons à recruter une personne à plein temps pour bosser sur le projet. Le poste en quelque points:
⚙️ Stack Nest + Vue.js + Postgres
🏢 Montpellier (TT négociable)
Profil fullstack, autonome (on est sur de la R&D) et une expérience en LLM Engineering est un plus (on formera si besoin)
Salaire jusqu’à 70K selon profil
Envoyez moi un message sur amaret93@gmail.com si vous êtes intéressé 😉
🤖 Agents LLM
OpenAI propose un framework d'expérimentation multi-agents.
Concrètement, ça permet de déclarer des agents spécialisés et surtout de pouvoir donner la main à un autre agent mieux qualifier à gérer une demande.
Par exemple, on peut avoir deux agents spécialisés, Sales et Refund et un agent de "triage" qui va recevoir les demande et les rediriger vers les agents spécialisés.
Tant qu'on reste sur des cas d'usages assez simple de ce genre (ça ressemble fortement à du routing d'API) alors les résultats sont plutôt bon. On utilise quelque chose de similaire chez Didask pour que les demandes soient traités par des agents spécialisés (nous on appelle ça des "behaviors")
Par contre je trouve que les cas d'usages ou il y a plusieurs boucles de communications entre plusieurs agents (comme agency-swarm) partent rapidement dans le n'importe quoi car les hallucinations deviennent ingérables.
Agent S est un framework d'Agent conçu spécialement pour interagir avec un ordinateur comme un humain.
Il est capable de comprendre et manipuler des interfaces pour réaliser des tâches.
Il s'appuie sur un outil permettant de manipuler les interfaces au clique mais aussi de la recherche en ligne et une mémoire des actions réalisées précédemment.
🔍 Retrieval-Augmented-Generation
💡 NotebookLM - Google Drive RAG
NotebookLM est une manière très simple de faire un RAG à partir de documents présents sur Google Drive (mais pas que)
Il suffit de créer un Notebook, de sélectionner des sources et de poser des questions comme dans ChatGPT.
Les sources possibles pour le moment:
- Google Slides
- Google Doc
- Site web
- Vidéo Youtube
- Texte brut
C'est très facile à mettre en place et ça fonctionne plutôt bien.
La feature avec effet Whaou mais valeur à prouver c'est la possibilité de créer un "podcast" d'une conversation fictive à propos des documents que vous avez envoyé pour résumer les thèmes clés.
Un comparatif des capacités des bases de données vectorielles.
Mon conseil sur ce sujet c'est de ne pas se prendre trop la tête et d'utiliser les capacités de recherche vectorielle de la DB que vous utilisez déjà:
- Postgres: pgvector
- Mongo Atlas: Atlas Vector Search
- Elasticsearch: knn vector search
Si vous avez besoin de recherche avancée avec filtrage, scoring, BM25 (keyword search) et scalabilité alors Elasticsearch reste la meilleure option.
Si vous avez besoin de quelque chose de léger qui tourne dans le même process que votre application, il y a Qdrant (Python) ou LanceDB (Javascript) selon votre techno.
💡 FRAMES: Factuality, Retrieval, And reasoning MEasurement Set
Frames est un benchmark (plutôt un dataset) de Google pour mesurer les capacités des RAGs.
Il contient +800 questions/réponses/articles qui nécessite de récupérer des informations depuis 2 à 15 articles de Wikipédia pour y répondre.
Concrètement cela veut dire que pour tester les performances de son RAG, il suffit de mettre les articles de Wikipédia anglophone en base de connaissances et de poser les questions du dataset une à une.
Pour arriver à répondre à ces questions, il faut que le RAG soit capable d'extraire des informations de plusieurs documents, de traiter des données numérique, des tableaux et de gérer des contraintes ou des données temporelles.
💡 Conversational search - OpenSearch Documentation
Le fork OpenSearch (Elasticsearch) d'Amazon Web Service inclut un RAG sur étagère.
On peut y déverser directement sa base de connaissance au format texte et ensuite l'interroger en mode RAG.
C'est pensé pour être utilisé dans une interface conversationnel et ils ont pensé à la persistance des conversations dans une entité "memory"
On peut choisir les modèles de LLM et aussi d'embeddings (ça reste limité aux modèles de OpenAI, Anthropic, Cohere et Bedrock)
C'est pratique pour monter rapidement un projet/prototype mais ensuite ça reste quand même une solution assez fermée si on veut pousser un peu plus loin dans le RAG.
💡 Understanding Retrieval Augmented Generation
La page de Dust qui explique le concept et les limites du RAG.
C'est la meilleure explication que j'ai trouvé et de loin !
💡 HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models
HippoRAG propose une méthode de RAG avancée capable de répondre à des questions à partir d'informations dispersées dans plusieurs documents.
La méthode commence par une phase d'indexation afin d'extraire les "named entities" et des tuple de relations d'un graphe de connaissances. Par exemple, "Teddy Riner", "Judo", "Paris" sont des entités nommées (NE) et ["Teddy Riner", "est un champion de", "judo"] est une partie du graphe.
Lors de la phase de recherche, ils commencent par extraire les NE de la requête puis ils s'en servent pour parcourir le graphe à l'aide d'un algorithme de type "Page Rank". Entre autre, plus un noeud est loin du noeud de départ (une NE extraite depuis la query) et plus son score est faible.
Les résultats dépassent ceux des benchmark actuels jusqu'à 20 %.
Je trouve que la méthode de construction d'un graphe par LLM afin de s'en servir pour récupérer les informations pertinentes est quelque chose à creuser. Plus une base de connaissances augmente en taille et plus il est difficile d'extraire les connaissances pertinente simplement avec des recherches.
Tous les prompts sont donnés à la fin du papier 👌
🧠 Large-Language-Models
Une étude qui démontre que les performances de génération ("raisonnement") des LLMs peuvent être impactées lorsque l'on demande une sortie dans un format spécifique comme du JSON.
Les LLMs suivant ont été testés:
- Gemini 1.5 flash: presque pas de différence
- Claude 3 haiku: baisse significative en JSON, pas en XML ou YAML
- GPT 3.5 Turbo: baisse significative en JSON, XML et meilleures perfs en Yaml
- LlaMa 3 8B: baisse de performance dans les 3 formats
Comme à chaque fois que l'on cherche à contraindre la génération, par des formats ou des règles d'éthique, la qualité de cette dernière est moindre.
Pour les formats, je pense qu'une chaine de prompt pourrait améliorer les performances avec un premier prompt qui sortirait une génération en texte brute et un deuxième prompt qui prendrait le texte tel quel pour le formater en JSON par exemple.
💡 MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering
Un nouveau benchmark qui vise à évaluer les capacités des LLMs à résoudre des tâche de ML engineering.
Concrètement, on leur pose des problèmes de MLE comme entrainer des modèles, préparer des dataset ou exécuter des expérimentations.
Certaines tâches ont été résolues par les modèles avec plus de 200 étapes et plusieurs heures de calcul.
Sans surprise, c'est le modèle o1 de OpenAI qui obtient la meilleure place avec 16.9% des problèmes résolus. On trouve ensuite GPT4-o avec 8.7%, Claude 3.5 Sonnet avec 7.6% et LlaMa 3.1 avec 3%
💡 microsoft/BitNet: Official inference framework for 1-bit LLMs
Microsoft propose un framework pour l'inférence de modèles à 1bit.
Cela signifie que la précision du modèle est à 1 seul bit au lieu des 32 bits habituels pour un float. Réduire le nombre de bits de précision est le processus de "quantization" et cela permet de réduire les exigences en terme de hardware pour un modèle.
D'ailleurs, la précision n'est pas de 1 bit mais plutôt une moyenne de 1.58 bit car la représentation interne des poids du modèle se fait avec des ternaires (1, 0 ou -1) et il faut donc 1 ou 2 bits pour les représenter.
Ainsi, un modèle "quantizé" à 16, 8, 4 voir 1 bit aura un meilleur débit de token et pourra fonctionner sur du matériel moins puissant au prix d'une diminution des capacités de "raisonnement" du modèle.
Alors oui ça peut être utile pour faire tourner des modèles sur du matériel de consommateur (ordinateur, téléphone) mais il y quand même un inconvénient majeur il faudrait ré-entrainer le modèle de 0 par rapport aux techniques habituelles de quantization qui peuvent simplement s'appliquer un modèle déjà entrainé.
Il est possible d'essayer des modèles 1 bit sur Huggingface et se faire une idée des capacités:
- bitnet_b1_58-3B (le modèle de Microsoft)
- Llama3-8B-1.58 (un LlaMa 3 "quantizé" à 1.58 bit
💡 Prompt Caching in the API | OpenAI
OpenAI fait du caching automatique de prompts.
C'est une bonne nouvelle car ça permet de réduire la latence (jusqu'à 80%) et les coûts des tokens d'input (les tokens en cache sont 50% moins cher)
Ça fonctionne de manière transparente sur les derniers modèles d'OpenAI.
Pour optimiser le caching, il est conseillé de mettre les instructions statiques au début du prompt. Si vous avez une instruction statique après du contenu dynamique, elle ne sera pas caché.
Ça apporte une sacré contrainte au niveau de la construction des prompts si on veut maximiser le caching mais dans des cas d'usage ou la latence est importante ça peut vraiment changer les choses.
💡 Un Ministral, des Ministraux
Mistral sort deux nouveaux SLM avec une version 3B et une version 8B (un peu gros pour un SLM quand même)
Le but affiché est de concurrencer les autres Small Language Model Open Source comme Phi de Microsoft ou Gemma de Google.
Les modèles ont de meilleures performances que les mêmes modèles de la même catégorie, ce qui pourrait en faire les meilleures SLM du marché pour l'instant.
Attention car les modèles sont release avec la MNPL et donc pas d'application commercial sans passer par la case licence.
💡 nvidia/Llama-3.1-Nemotron-70B-Instruct
Un modèle basé sur LlaMa 3.1 qui a été ré-entrainé par Nvidia.
Les performances sont impressionnantes, il se classe tout simplement juste derrière les modèles d'OpenAI et d'Anthropic sur Arena Hard
Alors après ces résultats sont quand même à prendre avec des pincettes car Arena Hard est basé sur une évaluation automatique d'une sélection de question de Chatbot Arena.
Il faudra attendre le résultat sur d'autres benchmark (raisonnement, code, math, etc) et notamment sur Livebench qui reste pour l'instant une référence.
C'est quand même une bonne nouvelle car cela prouve que les modèles Open Source sont capables d'approcher les performances des modèles closed source.
💡 LLMs don’t do formal reasoning - and that is a HUGE problem
Le résultat d'une étude menée par 6 chercheurs de chez Apple sur les capacités de "raisonnement" des LLMs.
On entend beaucoup dire que les LLMs sont capable de raisonner sur des problèmes alors que c'est faux dans la mesure ou la seule chose qu'est capable de faire un LLM c'est de prévoir une suite de mots en fonction d'une autre suite de mot.
La complexité des modèles est telle que cette simple capacité des LLM leur permet de résoudre des tâches plus ou moins complexe.
Mais il ne faut pas leur attribuer des capacités de raisonnement comme on l'entendrait pour un humain.
Les LLMs restent quand même excellent dans de nombreuses tâches comme l'extraction d'entités ou l'extrapolation depuis des exemples.
💡 LTM-2-mini - 100M Token Context Windows
Un modèle supportant une fenêtre de contexte de 100M de tokens.
L'avancée c'est surtout une réduction drastique de la mémoire nécessaire, LlaMa 3.1 405B aurait besoin de 638 H100 pour une inférence à 100M de tokens alors que le modèle LTM-2-mini en aurait besoin que d'une.
Pour l'instant, il faut prendre cette avancée avec des pincettes car leur modèle est beaucoup plus petit que LlaMa 3.1 405B.
Le seul benchmark utilisé est celui de "Needle in a haystack" qui consiste à retrouver une phrase dans un très long texte mais rien sur la capacité de raisonnement ou les connaissances générales.
Bref, à part les 100M tokens, on a pas plus d'info sur le modèle LTM-2-mini
💡 Finding Trends With Approximate Embedding Clustering
Un article qui explique comment découvrir des tendances lorsque l'on manipule des embeddings.
Par exemple, si l'on a les embeddings des questions posées par les utilisateurs à un Assistant, on peut utiliser la technique de k-mean clustering pour trouver quels sont les sujets les plus abordés dans les questions.
L'article explique comment utiliser Clickhouse pour calculer les centroids de chaque cluster (et donc la meilleure "représentation" du concept) mais il est possible d'utiliser d'autres méthodes, l'algorithme k-mean est assez répandu et de nombreuses implémentations existent
Mistral sort un nouveau modèle en collaboration avec Nvidia.
C'est un petit modèle (16b paramètres) qui avec 68% au MMLU benchmark, joue dans la cour de LlaMa 3 8b (62%) mais assez loin de GPT-4o mini (82%)
L'autre nouvelle importante c'est surtout la nouvelle version de leur tokenizer qui utilise 30% de tokens en moins pour représenter du code !
🎨 Image
💡 Diffusion Models Are Real-Time Game Engines
Des chercheurs de chez Google ont exploré l'utilisation de modèles de génération d'images comme moteur de jeu.
En gros ils génèrent 20 images par seconde qui représentent le gameplay du jeu Doom et ils guident la génération avec les input clavier.
Cela permet d'avancer, de tourner, de tirer etc
Impressionnant mais par contre je doute que ça remplace un jour les vrais engine au vu des problèmes d'hallucinations et des coûts faramineux associés à la génération de 20 images par seconde.
Aussi, les jeux modernes sont bien plus complexes que Doom et donc bien plus dur à simuler uniquement en générant des images. (Simuler un moteur physique par exemple)
📰 Autres
💡 Copilot Code Generation Instructions
On peut maintenant donner des instructions custom à Github Copilot pour guider la génération.
C'est très pratique pour que le code généré suive systématiquement nos standards de code.
On peut spécifier des instructions une par une ou un fichier qui en contient plusieurs.
Generative AI France est une newsletter technique francophone. Retrouvez nous sur https://gen-ai.fr