Monthly Shaarli
June, 2024
Inflection 2.5 est un modèle aux performances comparables à GPT-4.
Les détails d'une méthode qui allie un RAG à des comportements d'Agent.
Leur benchmark est une optimisation de flux financiers et logistique à réaliser en interrogeant de la donnée dans une base relationnelle.
Concrètement, un plan des données nécessaires et de leurs relations est établie en amont puis les différentes requêtes sont exécutées.
Si des données sont manquantes, un nouveau plan peut être établie.
Ils affichent des résultats jusqu'à 2 fois meilleurs (60%) qu'un RAG simple sur le benchmark qu'ils ont créé.
Donner la représentation interne de la base de connaissance au modèle pour lui permettre de créer ses propres requêtes est une piste intéressante que j'avais déjà envisagé (mais repoussé faute de structuration correcte dans notre base de connaissances à l'époque)
Koyeb est un cloud serverless assez moderne avec un scalling automatique en fonction de pleins de paramètres (RPS, active connections, latence, etc)
Ils proposent maintenant des GPU avec une facturation à la seconde !
C'est super pour l'inférence avec des modèles Open Source. Que ce soit des petits modèles sur un GPU à 0.5$/h ou un LlaMa 3 sur un H100 à 3.30$/h.
La dernière version de Claude serait le premier modèle à battre un modèle d'OpenAI.
Sur un benchmark de raisonnement par exemple, Claude 3.5 Sonnet fait 59% vs 53% pour GPT-4o.
Le million de token est à 3$ vs 5$ pour GPT-4o et ma fenêtre de contexte est de 200K tokens vs 128 pour GPT-4o.
Le modèle possède également des capacités d'analyse image.
Bref, un sérieux concurrent pour OpenAI !
Stability AI release son modèle Stable Diffusion 3 medium en téléchargement.
Les modèles de la famille Stable Diffusion 3 sont disponibles depuis plusieurs mois via l'API de Stability AI, notamment SD3 Large qui est leur modèle le plus performant.
Le modèle est release avec une licence Open Source qui interdit l'utilisation commerciale.
Après la release de Codestral en MNPL par Mistral, Stability protège aussi ses investissements en restreignant l'utilisation de leur modèle.
D'un côté ça peut se comprendre au vu des investissement nécessaires à l'entrainement, d'un autre côté le succès de Stable Diffusion est beaucoup venu de sa très grande communauté qui ont créé énormément de ressources et beaucoup de valeur autour du modèle de base.
Un retour d'expérience très complet sur le système d'interrogation du datawarehouse de Pinterest avec du langage naturel.
Ils ont construit un RAG avec lequel les utilisateurs peuvent poser des questions en langage naturel. 40% du temps le résultat est bon du premier coup et le reste du temps les utilisateurs doivent affiner leur question en plusieurs messages. (comme toujours, l'IA reste un copilote)
Une idée intéressante, ils utilisent les questions les plus courantes sur une table pour générer un summary de la table et son utilité. Ce summary est ensuite vectorisé.
Ils utilisent OpenSearch (la fork d'Elasticsearch) comme moteur de recherche vectoriel notamment parce qu'ils peuvent utiliser le scoring boost.
L'article est une mine d'information et ils donnent tous leurs prompts!
ElevenLabs propose maintenant de générer des sons d'ambiance.
Ça peut être des bruitages comme des applaudissements mais aussi des voix avec un style particulier comme "voix d'une vieille dame en sanglot".
Bonne nouvelle pour le monde de la création de contenu audio-visuel !
Luma AI sort un modèle de génération vidéo d'une qualité comparable à Sora de OpenAI.
Il reste encore des limitations, notamment sur la représentation du mouvement, des objets qui changent entre les frames ou la difficulté à représenter du texte mais le résultat est déjà de très bonne qualité !
La course aux modèles de génération vidéo semble être lancée mais j'ai l'intuition qu'il y aura beaucoup moins de participants que pour le texte ou l'image car les coûts d'entraînement GPU de ces modèles vidéo sont exorbitants
Un produit NoCode spécialisé dans la création de workflows avec de l'IA.
L'outil est simple à prendre en main même pour des non-tech et en plus ils ont pleins de templates prêt à l'emploi.
Mistral sort une nouvelle licence qui restreint l'utilisation commerciale de ses modèles.
Cette nouvelle licence est similaire à la Server Side Public Licence introduire par MongoDB et qui a pour but d'empêcher les cloud provider de fournir des produits Open Source sur étagère sans reverser des droits à la société qui édite ce produit.
Elle est cependant beaucoup plus restrictive car il est aussi interdit d'utiliser les produits utilisant cette nouvelle licence dans une application alors que la SSPL se borne à interdire la revente via un cloud.
Subject to the foregoing, You shall not supply the Mistral Models or Derivatives in the course of a commercial activity, whether in return for payment or free of charge, in any medium or form, including but not limited to through a hosted or managed service (e.g. SaaS, cloud instances, etc.), or behind a software layer.
Concrètement, seuls les usages non-commerciaux sont autorisés donc la recherche ou l'utilisation à des fins personnelles.
Cette fiction de Amnesty International sur la reconnaissance facile rendue possible grâce à l'IA est à glacer le sang.
Une piqûre de rappel sur la vigilance autour des outils IA qui peuvent être utilisé à des fins néfastes pour la population.
Mistral ouvre le fine-tuning de ses modèles.
Techniquement, c'est un fine tuning LoRa ou très peu de paramètres sont affectés. Ça réduit drastiquement les coûts tout en offrant de bonnes performances de génération (selon eux)
Bon alors techniquement c'était déjà possible vu que les modèles sont open source mais concrètement ils simplifient la tâches aux développeurs en proposant 3 services:
- mistral-finetune: open source et gratuit, c'est un repo qui contient le code nécessaire pour fine tuner un modèle Mistral
- Serverless fine-tuning: une API sur leur cloud pour fine-tuner les modèles sans se prendre la tête ($)
- Custom training service: une offre de service ou le fine tuning est pris en charge de A à Z par les équipes de Mistral ($$$)
Un article qui parle de techniques avancées pour améliorer les résultats d'un RAG.
-
Query Expension: le but est d'améliorer le champ lexical de la requête pour retrouver plus de documents pertinents. On peut aussi parler de la méthode HyDE pour récupérer des documents en provenance de champs lexicaux différents.
-
Self Query: c'est ce que j'appelle l'extraction de facettes, en gros ça consiste à extraire du texte brut les filtres que l'on a définit dans son moteur de recherche (couleur, poids, etc)
-
Hybrid & Filtered vector search: cette étape je conseille de la faire exclusivement avec un vrai moteur de recherche comme Elasticsearch en utilisant les query avancées et le scoring
-
ReRanking: après la récupération des documents potentiellement pertinents (disons 50), on refait une passe en demandant à un LLM de choisir les documents contenant réellement des informations pour répondre à la demande de l'utilisateur.
Anthropic ont sorti un outil pour aider à la rédaction de prompts.
L'outil met notamment l'accent sur la chaine de pensée et la séparation entre données et instructions.
J'avais fait un article qui donnait aussi des techniques pour améliorer les performances des prompts
Pour le CEO de la branche IA de Microsoft, tous le contenu sur internet est libre de droits et ils peuvent donc l'utiliser pour entrainer leurs modèles.
Malgré le lobbyisme de Microsoft pour nous faire croire qu'ils sont du bon côté, on continue d'entrevoir leur vrai visage à des moments.
Florence 2 est un modèle de reconnaissance d'image développé par Microsoft et disponible en open source.
Il est disponible en plusieurs versions et reste assez petit avec moins d'un milliard de paramètres.
Il performe mieux que les modèles actuels comme Flamingo bien qu'il soit 400x plus petit que celui-ci !
A priori c'est la qualité de la donnée d'entraînement qui permet ces performances avec 126 millions d'images et 5.4 milliards d'annotations utilisées.
Même le papier de recherche est Open Source, c'est bizarre de voir Microsoft faire ce qu'est sensé faire OpenAI 🙄
Un travail impressionnant de reverse engineering sur le fonctionnement de l'extension Github Copilot.
Dans la partie sur le prompt engineering, on apprend notamment qu'un "token budget" est alloué à chaque prompt et que des chunks de documents potentiellement pertinents pour la génération sont ajoutés au prompt en fonction de différents scores.
La partie appel au modèle contient toutes les règles pour déclencher le modèle au meilleur moment. (par exemple juste après avoir écrit un caractère espace).
Surtout, il y a un contextual filter score qui est calculé à partir d'un simple modèle de régression local afin de déterminer si cela vaut la peine d'appeler le modèle distant.
Finalement pour la télémétrie, le point principal est un check fait par l'extension à différents intervalles (jusqu'à plusieurs minutes) pour vérifier si le code suggéré est toujours dans le code.
Bref, un très gros travail a été fait et est disponible sur le repo copilot-explorer.
Depuis cela a certainement évolué (par exemple l'utilisation de GPT-4 au lieu de Codex) car ce travail a plus d'un an maintenant.
Un site qui permet d'avoir plein d'info sur l'immobilier.
Par exemple, vous pouvez voir les différentes ventes dans un quartier ou sur une parcelle voir un immeuble.
Perplexity n'utilisent pas le User Agent qu'ils déclarent utiliser.
Cela empêche de bloquer le bot qui scrape les pages web pour Perplexity (et ils ne respectent pas non plus le robot.txt bien évidemment)
Une nouvelle technique qui comme le RAG, est utilisée pour permettre au LLM de répondre à des questions sur des données non présentes dans le corpus d'entrainement initial.
Pour ça, ils se basent sur un fine-tuning de millions de LoRa avec les documents qui seront sélectionnés au moment de l'inférence pour répondre à la question.
Ils annoncent des résultats impressionnants avec 95% de précision sur un cas d'usage Text-to-SQL vs 50% avec un RAG.
Cette méthode permet de remplacer un RAG avec une nouvelle technique d'entrainement mais aussi de réduire énormément les hallucinations.
Ils expliquent les détails de leur méthode dans ce papier de recherche: Banishing LLM Hallucinations Requires Rethinking Generalization
Si ça se concrétise c'est game changer pour l'écosystème LLM qui pourrait délaisser le RAG pour le Memory Tuning dans certains cas d'usage.
Une méta étude qui regroupe toutes les méthodes connues de prompting.
Un article qui parle des timeout en Node.js et de la manière dont ils peuvent être la cause de memory leak même en utilisant clearTimeout.
L'objet Timeout conserve un contexte qui vient de la closure utilisée lors de la déclaration et il conserve aussi les références en provenance de AsyncLocalStorage si un contexte ASL est présent.
Bref, il vaut mieux set la variable à null une fois que l'on a clear le timeout.
Un outil de LLMOps dans la même veine que Langfuse.
Ça permet l'observabilité des applications LLM avec études des étapes de générations et même possibilité de rejouer directement les prompts.
Ils proposent aussi une partie évaluation et une partie création collaborative de prompts.
Un très bon article sur la manière d'évaluer des système de GenAI (RAG mais pas que)
- Avoir des interfaces bien foutues pour l'évaluation des données (question + réponse)
- Pas forcément besoin d'outils sophistiqués (même Excel peut faire l'affaire)
- Chaque système nécessite une évaluation personnalisée
- Écrire beaucoup de tests
- Utiliser les LLM pour générer des données de test
- Réutiliser son infrastructure d'évaluation pour le debug et le fine-tuning
Mistral sort un modèle spécialisé dans la génération de code.
Côté Open Source, il offrirait les meilleurs performances pour le moment avec de meilleurs résultats que CodeLlama et DeepSeek Coder (le précédent SOTA).
Il est disponible dans le cloud de Mistral (La Plateforme) et une intégration est prévue avec TabNine par exemple.
Niveau Open Source, il y a du nouveau avec une release sous la nouvelle licence Mistral AI Non-Production License qui restreint le modèle à une utilisation non commerciale.
Concrètement, Codestral sera payant si vous comptez l'utiliser dans un produit que vous revendez à des utilisateurs.
Un framework Python pour intégrer des LLMs dans son code.
Je trouve la DX bien pensée par rapport à Langchain (pas difficile de faire mieux niveau DX)
On y retrouve simplement les fonctionnalités essentielles pour faire du LLM Engineering:
- choix du modèle, des paramètres
- intégration facile de l'historique de messages
- utilisation de fonctions par le modèle (Function Calling )
- chaines de prompt et sous prompt (vraiment bien foutu je trouve!)
- extraction de données structurées
Il ne manque que la validation et la possibilité de spécifier un format de sortie structuré pour chaque prompt. C'est du super boulot.
(Dommage que ce soit en Python)
Une queue de message construite avec Postgres.
Projet prometteur mais assez récent donc à utiliser avec précaution.
Tout se fait en SQL:
-- creates the queue
SELECT pgmq.create('my_queue');
-- messages are sent as JSON
SELECT * from pgmq.send('my_queue', '{"foo": "bar1"}');
SELECT * FROM pgmq.read('my_queue', 30, 2);
-- or
SELECT pgmq.pop('my_queue');OpenAI partage des technique pour réduire la latence des LLMs.
C'est toujours bon à prendre car le paradigme de latence des LLMs est assez inédit dans le mode du Software Engineering ou on optimise à la dizaine de micro-seconde.
-
Taille du modèle: plus petit = plus rapide mais surtout moins performance. Si vous n'êtes pas capable de mesurer la performance alors il vaut peut-être mieux ne pas risquer un autre modèle que ceux de la gamme GPT4.
-
Générer moins de tokens: les tokens de sortie sont long à générer et en plus coûtent 2x plus cher. Je partage une de mes technique pour Modifier efficacement un texte avec un Agent LLM par exemple
-
Utiliser moins de tokens en entrée: rien à redire ici
-
Faire moins de requêtes: regrouper les requêtes dans le même prompt réduit la latence mais fait baisser les performances (J'en parle dans Spécialisez vos Agents LLM pour de meilleures performances
-
Paralléliser les requêtes: basic software engineering
-
Montrer la progression à l'utilisateur: basic user experience
-
Ne pas utiliser des LLMs partout: cela ne sert à rien de taper sur une vis avec un marteau
Unstructured propose des produits autour de la normalisation de documents en vue de leur ingestion dans un RAG.
Ils proposent des produits en API et SaaS pour ingérer les documents mais aussi des lib open source !
Sur cette page, ils présentent leur format de découpage d'un document en plusieurs éléments standardisés comme NarrativeText, Title, Table, etc
Un papier scientifique qui explique une méthode pour faire tourner un LLM sans la multiplication des matrices.
En gros ça signifie qu'on aurait pas besoin de l'acceleration GPU pour faire tourner des LLMs mais qu'on pourrait faire ça sur des CPU standard que tout le monde a déjà.
Une application qui fait croire au malware qu'il est dans l'environnement d'un chercheur en sécurité.
La plupart des malware ne font rien dans ces cas là pour éviter de se faire détecter
Une étude sur les capacités des modèles ayant de grandes fenêtres de contexte à réaliser des tâches de type RAG.
Il apparaît que les modèles sont autant capable qu'un RAG lorsque l'on met tous les documents dans leur fenêtre de contexte.
A première vue, on pourrait se dire que les RAG sont obsolètes mais:
- le nombre de tokens consommé est de 10 à 100x plus élevé
- même 2 millions de tokens peuvent s'avérer insuffisant pour une grande base de connaissances
En général, les modèles se débrouillent aussi mieux lorsque l'on limite le nombre d'informations présentes dans leur prompt et sur des cas d'usages de raisonnement comme en SQL, cela peut améliorer les performances.
Supermaven est un concurrent de Copilot pour la génération de code dans l'IDE des développeurs.
C'est le créateur de Tabnine, qui propose ce genre de solutions depuis 2018 (!), qui a développé Supermaven.
Leur parti pris c'est d'entrainer des modèles plus petits et plus spécialisés que GPT-4 pour pouvoir les utiliser virtuellement à chaque lettre écrite.
Ils ont donc développé leur propre solution en utilisant un modèle entrainé par leur soins:
- fenêtre de contexte de 300 000 tokens
- utilisation de la majorité du code d'un repo pour la suggestion
- latence faible (250ms annoncées vs ~800 pour Copilot)
Pour moi, des insights donné le plus intéressant est leur utilisation des séquences d'éditions plutôt que des fichiers. C'est à dire qu'ils considèrent l'enchainement des éditions faites par l'utilisateur (renommer des variables, écrire 2 lignes, supprimer 1 ligne, etc)
Je l'ai essayé et même en version gratuite c'est bluffant car les complétions sont instantanés et d'une qualité comparable à Copilot.
Une technique intéressante de prompt injection qui passe tous les niveaux du CTF de Lakera (une entreprise spécialisée dans la sécurité des LLMs)
Ils donnent des instructions en pseudo code qui permettent de faire leak le code secret
La lib Firebase Genkit de Google pour LLM est très bien pensée.
Contrairement à Langchain, le design est simple et le nombre de features limité à des abstraction de bas niveau.
- Abstraction autour des modèles (LLM et aussi image)
- Génération de données structurées avec schéma de validation Zod en entrée et en sortie (on fait la même chose chez Didask)
- Utilisation d'outils par les LLMs (la aussi définis avec Zod!)
Je ne suis pas super fan de leur manière de gérer les templates de prompt par contre, je préfère utiliser du pur Javascript.
Le gros bémol c'est que l'on a pas accès aux modèles d'OpenAI.
Une solution clé en main de Text-to-SQL, un RAG pour poser des questions en langage naturelle à sa base de données.
Une autre solution un peu plus mature: Dataherald
Les deux sont Open Source :-)
Lors des levées de fonds successives, les founders d'une startup se voient parfois offrir de se faire racheter des parts pour se faire de l'argent.
Cela leur permet de sécuriser leur investissement dans la startup en sortant une partie des bénéfices.
A priori cette pratique est entourée de secret aux Etats Unis au moins.
Une nouvelle technique pour planifier et faire exécuter des actions par un Agent en utilisant uniquement du code Python.
Plutôt que de fournir des outils virtuels que l'Agent peut utiliser en répondant un certain format JSON par exemple, CodeAct propose plutôt de permettre à l'Agent d'utiliser directement ces actions dans du code sous la forme de fonctions.
Déjà c'est assez malin car le code est beaucoup plus facile à générer pour un LLM qu'un DSL custom représentant des fonctions.
Aussi, le LLM peut maintenant utiliser directement les primitives de programmation comme les boucles ou les conditions pour arriver à ses fins plus rapidement.
Par contre, il y a du gros travail sur la génération de code pour éviter de faire n'importe quoi (malicious inputs) ou des choses imprévues comme utiliser des paquets externes non disponibles.
Un REX sur l'utilisation de LLMs en production.
Prompt Engineering:
- mettre l'accent sur les techniques de prompting (chain of thought etc)
- travailler sur la structure des données en entrée et en sortie
RAG:
- utiliser de la recherche hybride (vecteur + keyword)
- préférer le RAG au fine tuning pour la recherche de connaissance
- les long contextes des modèles ne rendront pas les RAG obsolètes
LLM Engineering:
- utiliser des workflow LLM qui mélangent prompt engineering et software engineering pour de meilleurs résultats
- faire générer des plans aux Agents afin d'améliorer la reproductibilité des résultats
- ne pas oublier de faire varier les méta-paramètres (temperature, top_p, etc)
- mettre en place des stratégie de cache
Test et évaluation:
- utiliser des tests unitaires avec des exemples réels
- évaluer les résultats avec d'autres LLM
- les évaluations apparaissent entre 5 et 10% du temps même sur des tâches simples
Un article très intéressant sur le caractère probabiliste des LLMs.
En gros, les GPU ont des architectures internes différente, notamment sur la manière de programmer les tâches en parallèle et du à la non associativité de certaines opérations cela cause des infimes différences de calcul qui finissent par affecter significativement le résultat final.
Cela me fait penser à la théorie du chaos ou des différences infimes dans l'état initial amène à des évolutions complètement différentes d'un système.
Toujours intéressant de savoir que ces concepts existent ainsi que de connaitre leur utilité :-)
-
LoRa (Low-Rank Adaptation) : une technique pour spécialiser des modèles afin de les rendre plus performant (en temps) et de "guider" leur génération. C'est par exemple ce qu'on utilise avec StableDiffusion pour forcer la génération dans un style particulier ne faisant pas partie des données d'entrainement
-
PEFT (Parameter-Efficient Fine-Tuning): cette technique permet de fine-tuné uniquement une partie des paramètres du modèle pour réduire les coût. Par exemple, on utilise ça avec LoRa justement car les modèles d'image sont très gros et très cher à fine tuner
-
RAG (Retrieval-Augmented Generation): cette technique permet "d'interroger" des connaissances ne faisant pas partie des données d'entrainement d'un modèle comme les documents internes d'une entreprise par exemple (J'en parle tout le temps)
-
MoE (Mixture of Experts): une architecture de LLM ou le modèle est composé de "sous modèles" ayant été entrainés et spécialisé dans des domaines différents
-
Quantization: cette technique réduit la précision des nombres utilisés pour stocker les paramètres d'un modèle afin d'augmenter la vitesse et le coût au détriment de la performance de génération
Microsoft propose un outil qui prend des screenshots à intervalles réguliers puis les analyse avec de l'IA pour que l'on puisse chercher dedans n'importe quelle information.
Rewind propose la même chose sur Macos par exemple.
Dans l'idée, c'est un RAG automatique sur tout ce que vous faites donc ça peut être pratique.
Dans les faits, la qualité de la donnée est assez mauvaise et l'utilité limitée.
Par contre pour un pirate ayant accès à votre PC c'est une mine d'or 😬