Meta publie un article sur une nouvelle architecture de modèle de langue.
Au lieu de s'appuyer sur des tokens qui représente des "bouts" de mots de quelques lettres, ils proposent de s'appuyer directement sur des concepts de haut niveau.
Un exemple de token avec cette architecture serait "Tim n'était pas très athlétique".
Cela ressemble aux idéogrammes chinois vs les alphabets et d'ailleurs les compromis sont sensiblement les mêmes:
Par exemple, la vitesse d'inférence (= écriture) accrue pour les concepts mais au prix d'un nombre de concepts beaucoup plus importants et donc aussi un coût d'entrainement + inférence (FLOPS) plus élevé.
En tout cas c'est rassurant de voir qu'il y a des architectures radicalement différente des LLMs actuels qui émergent !
Google a fine tuné Gemini 1.5 Pro pour améliorer le modèle dans un cadre d'enseignement en respectant les concepts de la pédagogie.
Les LLMs ont tendance à présenter l'information plutôt qu'à engager l'utilisateur dans un processus de réflexion et de compréhension. C'est justement l'un des axe qu'ils ont essayé d'améliorer.
Les résultats présentés ont été fait sur 2360 conversations pour un total de 58000 messages et chaque pair de message a été évalué par 3 experts en moyenne.
Ils affichent des résultats 13% meilleurs que le modèle Gemini 1.5 Pro de base.
C'est aussi intéressant de voir que dans l'étude, GPT-4o possède les moins bons résultats face à Claude 3.5 Sonnet et Gemini 1.5 Pro. Les meilleurs modèles "pédagogues" seraient donc Claude et Gemini.
Il est possible de le tester en mode chat ici: https://aistudio.google.com/
De nombreux exemples de prompt sont dans la documentation https://ai.google.dev/gemini-api/docs/learnlm
Le modèle est déjà disponible dans le SDK sous le nom learnlm-1.5-pro-experimental
Une liste assez exhaustive de tous les outils disponible pour générer du code
Ça va du niveau de l'outil qui génère une application entière à l'extension comme Copilot en passant par les IDE AI plus ou moins avancés
Un framework clé en main qui permet de faire de la manipulation de site web par un Agent LLM.
On peut bien sur donner la tâche, choisir le modèle mais aussi fournir des outils custom que l'Agent va pouvoir utiliser.
Très pratique pour le brancher avec nos propres outils internes via du code Python ou plus simplement une API
llms.txt c'est le nouveau standard pour aider les LLM à comprendre les pages web.
Concrètement c'est un fichier qui comme le fameux robots.txt (ou security.txt ou humans.txt) donne des informations au format texte.
Ces fichiers ne se mettent pas forcément à la racine, exemple avec la doc de Cursor https://docs.cursor.com/llms-full.txt
E2B propose un service d'exécution de code dans des sandboxs.
C'est ciblé précisément pour les Agents LLM capable d'exécuter directement du code pour accomplir leur tâche.
Les fonctionnalités sont très complètes avec:
- lecture/écriture de fichiers
- accès au réseau de la sandbox (e.g. accéder un serveur web)
- streaming de la sortie standard
- paquets custom (npm, pip, etc)
- Javascript, Python, R, Java, Bash
Un exemple de la manière dont Superlinked utilise un scoring pour rechercher des documents.
Ils ont 3 métadata:
- relevance
- recency
- usefulness
L'API d'Anthropic propose aussi une fonction de conversion de PDF en markdown
Microsoft sort aussi une lib pour convertir les documents PDF, Docx, Excel, etc au format markdown
OpenAI tire à balles réelles sur Elon Musk en publiant des échanges de mails et même des SMS.
Google annonce Gemini 2.0 Flash.
Niveau benchmark comme d'habitude il faut attendre que ça sorte sur Livebench pour avoir une meilleure comparaison mais quand même ils affichent de très bon résultats:
- 89.7% sur MATH (76.6 GPT-4o)
- 62.1% sur GPQA (59.4% Claude 3.5 Sonnet)
- 35.1% sur LiveCodeBench (42% Claude 3.5 Sonnet, 67% o1-mini)
La big new c'est surtout la multi-modalité en entrée et en sortie du modèle qui est capable de générer un mix de texte, son et image pour répondre si besoin.
Google a vraiment rattrapé son retard, c'est cool de voir toutes ces améliorations.
Anthropic propose un optimisateur de prompt.
Pendant son entrainement, Claude a été optimisé sur certains patterns comme l'utilisation de balises XML pour organiser le contenu et ces patterns peuvent améliorer la performance des prompts.
Unsloth est un framework de fine-tuning qui permet d'entrainer plus rapidement et avoir moins de mémoire des modèles Open Source.
Ils annoncent un gain jusqu'à x2 sur la vitesse d'entrainement !
Ça s'utilise en Python mais aussi directement dans un Notebook
Un retour d'expérience sur l'utilisation de o1 et Claude 3.5 Sonnet.
La conclusion c'est que dans la majorité des cas, Claude 3.5 Sonnet est suffisamment bon et que la différence prix + latence entre les deux modèles fait plutôt pencher la balance du côté de Claude 3.5 Sonnet
Tout est dans le titre.
OpenAI recrute des spécialistes de la publicité en provenance de chez Google et Meta pour réfléchir à son offre publicitaire.
À priori, ça sera sûrement du placement de produit dans les résultats de génération de ChatGPT.
Un article proposait une méthode pour transposer le système d'enchères traditionnel de la pub en ligne aux LLM
Une percée potentielle dans l'architecture des LLMs !
L'architecture actuelle (ARM) est une génération "de gauche à droite" ou l'on génère les tokens les un après les autres en concaténant les tokens générés pour faire le nouveau prompt.
En s'inspirant des modèles de diffusion d'image, les chercheurs ont mis au point une nouvelle architecture de modèle (MDM) qui génère les tokens avant et après le prompt.
Ces modèles sont plus cher à entrainer mais ils présentent plusieurs avantages:
- meilleures performances de génération sur des problèmes standards
- capable "d'apprendre" et d'inférer que si A = B alors B = A (les LLMs ont beaucoup de mal à ça)
- jusqu'à 40% plus rapide
C'est un tout nouveau champ de recherche qui commence à prendre de l'ampleur !
Finalement on dirait qu'on a pas encore atteint ce fameux plafond de verre ;-)
Microsoft sort son un écosystème d'exécution d'Agents.
Vu le catalogue de Microsoft, c'est assez énorme avec plus de 1400 "connecteurs" (comprendre "API") disponibles sur étagère pour interagir avec les services Microsoft mais aussi des services externes comme Gmail, Twilio, MongoDB.
Ils ont aussi pas mal de choses assez exclusives sur étagère:
- un Code Interpreter Python
- recherche web avec Bing
- des jeux de données privés comme celui de Tripadvisor par exemple
- un moteur de conversation intégré
Bref, dans l'environnement Azure/Microsoft il y a toute une toolbox pour développer
Encore une étude sur les impact du prompt et du format de réponse sur la qualité de la génération.
Ils ont notamment testé les performances de génération en plusieurs formats de sortie:
- JSON (0.77)
- YAML (0.7)
- text (0.69)
- Markdown (0.35)
Dommage qu'ils n'aient pas inclus XML. (et j'ai vérifié cette fois, les prompts sont les mêmes entre chaque format)
Une autre conclusion est que le modèle GPT 3.5 est plus sensible aux variations de prompt que GPT 4.
C'est quelque chose que je remarque aussi, plus un modèle est performant et moins il est sensible aux subtilités du Prompt Engineering.
Les gens de chez .txt (ce qui font Outlines) ont pris le temps de réfuter l'étude Let Me Speak Freely qui annonçait des performances moindre lorsque l'on utilisait un format contraint comme JSON.
Leurs résultats montrent que la génération structuré améliore un peu la performance de génération (ils ont utilisés les mêmes benchmark que l"étude)
Les erreurs faites dans l'étude:
- certains de leurs résultats présentaient déjà de meilleures performances en génération structurée
- les prompts n'étaient pas les mêmes entre génération structurée et non structurée
- le parsing des outputs était réalisé avec un autre LLM ce qui faussait les résultats
An apt analogy would be to programming language benchmarking: it would be easy to write a paper showing that Rust performs worse than Python simply by writting terrible Rust code.
Finalement c'est plutôt rassurant car il est difficile de se passer de la génération structurée aujourd'hui.
A noter qu'il faut bien faire la différence entre
- génération structurée: JSON-mode d'OpenAI ou lib Outlines qui garantissent le schéma des données en sortie
- génération JSON: on génère du JSON et on vérifie qu'il correspond à un schéma
Le prompt système de Bolt est disponible sur Github et donne pas mal d'info sur la manière dont est organisé leur système:
- création/édition de code avec des GNU diff
- ça tourne dans des WebContainers
- ils contournent la limite de 8K tokens en output avec leur
CONTINUE_PROMPT
Surtout je vois que tout est au format XML (ils utilisent Claude 3.5 Sonnet) plutôt que JSON.
J'aimerais bien savoir pourquoi, sachant que j'avais remarqué que le format XML présentait de meilleures performances de génération que le JSON il y a un an. Je me demande si ils sont arrivés aux mêmes conclusions.