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.

C'est peut-être vrai que l'IA consomme moins qu'un humain pour écrire une page de texte mais à cause de l'effet rebond, l'IA pourrait quand même générer beaucoup plus de CO2 car la ou l'humain écrit une page par jour, ChatGPT en écrit 100 000.

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.

Les poursuites judiciaires engagées contre GitHub pour violation de copyright par Copilot ont été abandonnées par les juges.

GitHub modifie légèrement les exemples de code par rapport aux sources originelles et c'est entre autre cette raison qui a convaincu les juges.

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.

Un clone de Perplexity à vocation pédagogique pour comprendre et apprendre les différents concepts du moteur de recherche augmenté par IA.

Techno: Next.js, Vercel AI SDK, Mistral, Langchain.js, Serper et Brave API (search), OpenAI Embeddings

OpenAI propose une API de RAG sur étagère (c’est en bêta encore)

Concrètement ça permet d’ingérer des documents dans une base de données vectorielle et de faire un RAG en très peu de code.

Il n’y a pas beaucoup de contrôle sur les différentes étapes, par exemple le chunking c’est uniquement chunking simple avec overlap, mais c’est très pratique pour faire un POC rapide par exemple.

Supermaven propose un assistant code comme Copilot.

Supermaven possède so propre modèle (Babble) et se démarque sur plusieurs points:

• Fenêtre de 1 millions de token
• Latence de 250 ms au lieu de 800ms pour Copilot
• Prédiction à chaque frappe du clavier

Ils ont testé le modèle sur des benchmark de type “needle in a haystack” et il est capable de retrouver correctement les informations même dans 1 millions de tokens !

Je l’utilise depuis quelques semaines et c’est un sérieux concurrent à Copilot.

Certaines choses sont néanmoins moins bien, par exemple Supermaven raisonne beaucoup moins bien que Copilot (GPT-3.5 ou GPT-4).

Github permet maintenant de coder des extensions à Github Copilot.

Concrètement, il est possible d'utiliser les modèles utilisés par Copilot et de créer des assistants spécialisés que l'on peut ensuite solliciter dans le chat.

Il y a deux API:

• Chat API: permet de s'intégrer dans le chat de Copilot
• Language API: permet de faire des requêtes aux modèles basés sur GPT-3.5 et GPT-4 (le contexte maximum est de 4000 tokens)

Par exemple, l'assistant @stripe est capable d'aider un développeur à développer et debuguer une intégration Slack.
J'imagine que derrière, il y a un RAG avec la documentation à jour de Stripe.

C'est la porte ouverte à la création d'un écosystème, très bonne initiative de la part de Github à un moment ou la concurrence sur les assistant de code est rude (Supermaven par exemple)

Scaleway propose une offre d'inférence managé avec les modèles de Mistral (aussi LlaMa 3 et quelques autres).

Le prix dépend du GPU, c'est 0.93€/h sur des L4 (670€/mois) et 3.40€/h sur des H100 (2482€/mois)

Les plus gros modèles (LlaMa 3 et Mistral 8x7b) nécessitent des H100.

A noter qu'ils développent aussi une Generative API pour proposer de l'inférence à la demande comme sur l'API d'OpenAI (c'est encore en beta)

Inflection 2.5 est un modèle aux performances comparables à GPT-4.

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.

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à.

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 🙄

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)

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.

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.