Anthropic a sorti une mise à jour importante de Claude 3.5 Sonnet et il obtient des résultats impressionnant sur les benchmark !
Il dépasse GPT4-o sur la plupart des benchmarks existants et de loin mais c'est surtout sur la partie code qu'il réalise un exploit car il dépasse tous les autres modèles spécialisés sur le benchmark SWE-Bench avec 49% des tâches de réalisées.
La progression des modèles pour les tâches de programmation est vertigineuse, pour rappel en août le SOTA était Aider avec 19%
Personnellement, j'utilise uniquement Claude 3.5 Sonnet dans Cursor et c'est vrai qu'il y a une différence notable avec GPT-4o.
Un article qui propose d'intégrer des publicités dans les réponses des LLMs.
Par exemple, si vous recherchez un livre de science fiction similaire à un que vous avez aimé, le LLM vous proposera un nouveau livre ainsi qu'un lien vers un site de vente de ligne pour l'acheter.
Le système utiliserait un système type RAG pour intégrer des instructions spécifiques de publicité dans la réponse du LLM.
Autant ce genre de système pourrait apparaitre dans les applications finales comme ChatGPT, autant cela parait difficile de faire utiliser une API incluant de la publicité à un client qui intègre de la GenAI dans son produit.
Je serais assez frileux d'utiliser ce système, même si l'API était gratuite car cela introduit encore plus imprédictibilité des résultats à cause de l'injection d'instructions potentiellement différentes à chaque utilisation.
Pour des cas d'usage très simple cela serait moins problématique mais dans des workflows LLM un peu complexe cela peut avoir des effets très dur à contrôler.
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 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é" à 1bit)
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.
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.
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](http://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.
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.
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.
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
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.
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 !
Google a commencé à distribuer son modèle Gemini Nano directement dans Chrome.
Le modèle fonctionne totalement en local avec une API dédiée:
const ts = ai.createTextSession()
const gemi = await ts
const output = gemi.prompt('Tell me you best programmer joke')
C'est une grande avancée car il sera maintenant beaucoup plus simple de créer des applications utilisant des LLM directement en utilisant les API du navigateur.
Par contre en faisant cela, Google va encourager la fragmentation du web par navigateur avec des sites web qui ne fonctionneront que sur Chrome car exploitant des API non standards.
J'espère qu'une standardisation de ce genre d'API arrivera sous peu, comme cela a été le cas pour la reconnaissance vocale avec les Web Speech API
La recherche en optimisation des modèles de langue fais des pas de géant avec GaLore et maintenant Q-GaLore !
Concrètement ces techniques permettent de réduire la mémoire nécessaire pour entraîner un LLM.
Un modèle comme LlaMa 7B ne peut être entraîné que sur des GPU de datacenter car les poids pèsent lourd en mémoire.
Avec Q-GaLore, on peut entraîner ce modèle avec seulement 16Go de RAM et donc sur des GPU grand publique comme la RTX 4060 de Nvidia.
Autant du vote de l'inférence que de l'entraînement, les exigences en matériel dont de plus en plus basses, ce qui contribue à la baisse de coût du token.
Outlines propose une bibliothèque Python pour contrôler la génération et produire un JSON valide à tous les coups.
Pour cela, ils vont tout d'abord créer un regex qui correspond au JSON à parser, puis ils vont transformer cette regex en une Finite-State Machine (FSM).
Chaque token généré est une étape de cette state machine et la prochaine étape peut avoir une ou plusieurs possibilité de token.
Par exemple, si format du JSON est { "age": <number> }
et les tokens générés ont été: {"ag
alors le prochain token est forcément e":
afin de respecter le format ({"age":
)
Donc en faisant appel au modèle, ils peuvent aller sélectionner dans les tokens potentiels ceux qui correspondent au format attendu et en quelque sorte "force la main" du LLM.
Ils peuvent aussi ignorer des appels au LLM lorsqu'il n'y a qu'un seul token de possible pour la prochaine étape de la state machine.
C'est une technique très maline et intéressante car elle permet de s'assurer de la structure du JSON mais aussi de réduire le nombre d'appels au LLM.
A noter que cela n'est vraiment intéressant que sur un modèle local dont on contrôle l'inférence, si on utilise l'API d'OpenAI par exemple alors cela ne va pas accélérer l'inférence ou réduire les coûts car il faudrait envoyer le prompt entier et payer le coût de tous les tokens à l'intérieur pour chaque étape de la state machine. (Par contre la sortie sera du JSON à 100% grâce au choix du prochain token via les logprobs)
Un retour d'expérience sur le fine tuning de modèles pour améliorer les performances sur un cas d'usage d'extraction de données structurées.
Les modèles fine tuné offrent de meilleures performances que GPT-4o !
Ici le processus de fine tuning a permis au modèle d'augmenter les poids lui permettant de "comprendre" ou étaient les données à extraire.
C'est intéressant mais compliqué à mettre en place entre la constitution du jeu de données et l'évaluation des modèles fine tuné.
Les résultats sont quand même très encourageant, je pense qu'il va falloir de plus en plus considérer le fine tuning pour certains cas d'usages.
Un article de recherche assez impressionnant d’Anthropic, ils ont cartographié l’activation des “neurones” du LLM.
Cela me fait beaucoup penser à l’IRM qui permet de repérer quels sont les zones du cerveau qui s’activent pour une tâche ou à l’évocation d’un concept.
De la même manière, ils ont observé l’activation des “neurones” du LLM lors de la génération afin de repérer quelles zones encodaient les concepts.
C’est une grande avancée dans le domaine de l'explicabilité qui est cruciale pour comprendre le fonctionnement interne des réseaux de neurones informatiques.
OpenAI est arrivé à un tel niveau de qualité dans les réponses faites par ses modèles qu’il est maintenant difficile pour les évaluateurs humains de choisir une meilleur réponse dans leurs processus de Reinforcement Learning (RLHF).
Ils ont donc fine-tuné un modèle (aussi par RLHF) pour aider les évaluateurs à discerner des erreurs ou améliorations.
Le modèle se trompe souvent mais cela améliore quand même de 60% la qualité de l’évaluation.
C’est un très bon exemple de “copilot” IA ou la collaboration entre IA et humain donne de meilleurs résultats la ou l’utilisation de l’IA seule n’aurait pas été possible car trop d’erreurs.
Inflection 2.5 est un modèle aux performances comparables à GPT-4.