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)

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

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 👌

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 !

OpenAI ajoute un nouveau mode à son API qui permet de spécifier un JSON Schema pour assurer à 100% la génération d'un JSON valide.

Ils ne disent pas comment ils font mais il y a de fortes chances qu'ils utilisent une technique similaire à celle de Outlines en transformant le JSON en une machine à état qu'il est facile de suivre à chaque étape.

Concrètement c'est une très bonne nouvelle pour limiter les erreurs de génération structuré !

Bonus dans le SDK TS avec le support des schéma Zod directement:

const MathResponse = z.object({
    steps: z.array(Step),
    final_answer: z.string(),
})
const client = new OpenAI();
const completion = await client.beta.chat.completions.parse({20
    model: 'gpt-4o-2024-08-06',
    messages: [
        {
            "role": "system",
            "content": "You are a helpful math tutor. Only use the schema for math responses.",
        },
        { "role": "user", "content": "solve 8x + 3 = 21" },
    ],
    response_format: zodResponseFormat(MathResponse, 'mathResponse'),
});

Une explication sur le fonctionnement du stockage de données avec Postgres

Un papier de recherche de Google DeepMind sur un nouveau type de modèle d'IA basée sur l'architecture Mixture of Expert (MoE).

L'idée c'est d'entrainer des millions de plus petits modèles sur des connaissances différentes puis lors d'une requête, sélectionner les modèles les plus à même de répondre.

Un des avantages de ce genre d'architecture c'est qu'il serait plus facile de "désapprendre" ou "apprendre" de nouvelles choses au modèle en supprimant certains des petits modèles ou en ajoutant de nouveaux.

Pour l'instant c'est encore à l'état de recherche mais c'est encourageant pour la suite, notamment pour palier au problème de "désapprentissage" des modèles actuels qui rend leur fine-tuning pour du RAG peu efficace.

Aider est un assistant pour développement dans le terminal.

L'outil est vraiment bien foutu, je suis impressionné par sa capacité à réaliser des tâches en autonomie. Je l'utilise beaucoup pour du refacto par exemple.

C'est actuellement le meilleur assistant, ils obtiennent 18.9% sur le SWE Bench qui évalue les assistants à leur capacité à réaliser des tâches de programmation.

Le dernier SOTA était Devin.

Bref, c'est un super projet et en plus tout est open source! A utiliser d'urgence

OpenAI travaille sur de meilleures techniques pour éviter les instructions malicieuses (prompt injection, prompt extraction, etc).

Ils ont créé une hiérarchie dans les instructions entre les instructions système, celles des utilisateurs et celles des outils.

Notamment, ils décrivent un concept d'instruction "alignées" ou "non-alignées" par rapport au message système que le LLM doit être capable de détecter afin de refuser de répondre à des instructions potentiellement malicieuses.

Comme toujours c'est un travail assez difficile car d'un côté il faut être capable de bloquer les instructions malicieuses et de l'autre ne pas dégrader les capacités du modèle à répondre à des questions ouvertes ou complexes.

En tout cas, leur technique est efficace car elle bloque 80% des prompt injection vs 60 auparavant et sur d'autre types d'instruction malicieuses comme l'extraction de prompt on parle de 95% vs 32%.

Pour l'instant ces techniques ne sont pas encore disponibles dans les modèles de OpenAI mais les prochains seront très certainement entrainés pour mieux résister aux instructions malicieuses.

Une explication intéressante des mécanismes internes des LLMs qui conduise à la génération de résumés incorrects.

L'auteur fait remarquer que dans la plupart des cas, le soit disant résumé est enfaite une version raccourcie du texte car le LLM ne comprend pas vraiment ce qui est important.

Les poids de l'entrainement du modèle pèsent souvent beaucoup plus lourd que le contexte fourni dans le prompt et on peut remarquer une "dérivation" du modèle vers ces poids plutôt que vers le contexte: ce sont les hallucinations.

Une alternative aux runner CI de GitHub avec un pricing 2x moins cher et de meilleures performances.

Ils utilisent des CPU plus modernes, conçus pour le jeu vidéo et avec de meilleures performances par cœur.

Ils proposent aussi une action de cache plus performante qui remplace celle fournie par GitHub

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.