L’innovation mémoire de GPT-4o – une aiguille dans une pile d’aiguilles

• needle-in-a-needlestack est une page publique qui rassemble au même endroit des articles d’expérimentation et du code liés à GPT-4o, Llama, Jamba, Sonnet et Gemini
• Le dépôt de code du projet est également fourni, ce qui permet de consulter directement les ressources des expériences Needle in a Needlestack
• Les articles par modèle comparent les résultats de Llama 3.1 8B, Jamba 1.5 et d’autres, en se concentrant sur les différences de traitement de longs contextes et de scalabilité
• GPT-4o-mini est présenté comme un cas comparable à GPT-4 Turbo tout en étant 98,5 % moins cher, tandis que Sonnet 3.5 est présenté comme meilleur que Sonnet 3.0 sur NIAN
• La page elle-même est open source, et il est possible de contribuer à la modification de la documentation via le lien « Improve this page » sur GitHub

---

Liens liés à Needle in a Needlestack

• Needle in a Needlestack Code : dépôt de code Needle in a Needlestack
• GPT-4o’s Memory Breakthrough! : article sur l’innovation mémoire de GPT-4o
• GPT4o-mini comparable to GPT-4 Turbo, for 98.5% lower price : article indiquant que GPT-4o-mini est comparable à GPT-4 Turbo, tout en étant 98,5 % moins cher

Articles comparatifs par modèle

• Llama 3.1 8B: Excels in 8K Contexts, Challenged by Expansion : contenu indiquant que Llama 3.1 8B est performant sur les contextes 8K, mais rencontre des difficultés lors de l’expansion
• Jamba 1.5: New model with new architecture crushes Needle-in-a-Needlestack : contenu indiquant que Jamba 1.5, avec sa nouvelle architecture, surpasse largement Needle-in-a-Needlestack
• Sonnet 3.5 Does Much Better at NIAN Than 3.0 : contenu indiquant que Sonnet 3.5 est nettement meilleur que Sonnet 3.0 sur NIAN
• Gemini 1.5 Flash Outperforms Much More Expensive Models : contenu indiquant que Gemini 1.5 Flash surpasse des modèles beaucoup plus coûteux

Documentation open source

• Ce site est open source
• Le lien Improve this page permet de modifier la page sur GitHub

[wedding]

Les avancées technologiques sont vraiment incroyables.. T_T

[GN⁺]

Avis de Hacker News

• Ce test repose sur le jeu de données de limericks publié en 2021 : https://zenodo.org/records/5722527
  Je pense qu’il est très probable que GPT-4o ait été entraîné sur ces données. Il n’y aurait pas vraiment de raison de ne pas les inclure. Je me demande pourquoi l’équipe NIAN ne génère pas des limericks avec plusieurs modèles, puis ne vérifie pas que les résultats ne figurent pas dans le jeu de données. Cela permettrait d’exclure la possibilité que les modèles aient été entraînés sur ces limericks

  • Ils ont testé si les LLM pouvaient répondre aux questions sans fournir les limericks. À l’exception de 4o, les performances sont très mauvaises sur ce benchmark, donc je ne pense pas que la présence dans les données d’entraînement invalide le test
  • Pourquoi ne pas simplement créer un texte totalement aléatoire et leur demander de chercher dedans ?
  • NIAN est une très bonne idée, mais ne pourrait-on pas simplement traduire dans N langues différentes puis poser les questions ? On pourrait aussi mélanger DeepL, Google Translate, la traduction par les LLM eux-mêmes, etc.

• J’ai comparé deux petits documents juridiques, et il a complètement halluciné en affirmant qu’une clause figurait dans l’un mais pas dans l’autre. Il l’a fait à trois endroits différents du contrat
  En vérifiant avec ctrl-f, elle figurait bien à l’identique dans les deux. Ce n’est qu’un échantillon, mais le chiffre de 90 % ne me semble pas crédible. L’ensemble faisait environ 80 000 tokens

  • Même impression. Je lui ai demandé de trouver des doublons dans une liste de 6 000 éléments, et il a presque entièrement halluciné la réponse à plusieurs reprises. Il trouve parfois quelques doublons, mais il y mélange des éléments halluciné entre les deux
    Je ne m’attendais pas à une bonne réponse, car je pense que c’est une tâche difficile avec un nombre fixe de têtes d’attention, mais il m’a semblé bien pire que Claude Opus ou GPT-4
  • Ce n’est pas une recherche d’aiguille dans une botte de foin
    Les LLM s’en sortent mieux pour cette tâche si l’on découpe les deux documents en sections plus petites et qu’on les traite section par section de façon répétée. Ils n’ont ni capacité de raisonnement ni mémoire leur permettant d’analyser structurellement deux gros blocs de texte au-delà de fragments relativement petits. En revanche, si on les parcourt progressivement sous forme de petits morceaux sémantiquement indépendants et pertinents, cela fonctionne plutôt bien
    C’est une erreur de les considérer comme des machines magiques. Ils ont des limites et des capacités, et comme pour tout autre outil, il faut comprendre ce qui marche, ce qui ne marche pas, et idéalement pourquoi. Pour 99,9 % des développeurs, cela reste une avancée assez nouvelle ; je ne comprends pas pourquoi les attentes sont pratiquement infinies. Avec les technologies précédentes, le critère était plus raisonnable : « bon, trouvons comment bien l’utiliser ». Peut-être est-ce parce qu’ils parlent comme des humains et semblent donc posséder des capacités qu’ils n’ont pas, ou parce qu’ils ressemblent trop à des humains, au point qu’on leur reproche de ne pas en être. Il y a à la fois de l’emballement et de la sous-estimation. Même XML a connu un cycle de hype similaire, où l’on aurait presque cru qu’il allait mettre fin à la faim dans le monde
  • C’est un test différent de needle-in-a-needlestack, mais il montre bien à quel point les modèles sont fragiles. Ils sont compétents dans certains domaines, et catastrophiquement mauvais dans d’autres
    Needle-in-a-needlestack consiste à retrouver une donnée précise parmi des données similaires, contrairement à needle-in-a-haystack, qui consiste à chercher parmi des éléments différents. Par exemple, retrouver un limerick particulier parmi des milliers de limericks
  • J’ai fait la même expérience avec la réglementation locale, et j’ai vu GPT halluciner des amendes et frais. C’est un vrai problème
  • Intéressant, d’autant qu’au moins officiellement, la fenêtre de contexte de GPT-4o est de 128k

• Le test needle-in-a-haystack ne montre que de manière très limitée la capacité réelle d’un modèle à gérer de longs contextes. Il est surtout utilisé parce que les premiers modèles étaient très mauvais sur cette tâche et qu’elle est facile à tester
  En réalité, la plupart des modèles récents s’en sortent plutôt bien sur cette tâche isolée, mais leur capacité à effectuer des tâches complexes au-delà de 32K tokens chute fortement. RULER est un bien meilleur test : https://github.com/hsiehjackson/RULER

  Malgré des performances presque parfaites au test needle-in-a-haystack (NIAH) de base, tous les modèles (à l’exception de Gemini-1.5-pro) montrent une forte dégradation des performances sur les tâches RULER à mesure que la longueur de séquence augmente
  Bien que tous les modèles revendiquent une taille de contexte supérieure à 32k tokens (sauf Llama3), seuls la moitié parviennent à traiter efficacement des séquences de 32K en dépassant le critère qualitatif correspondant aux performances de Llama2-7b à 4K (85,6 %). Les performances dépassant ce seuil sont soulignées

  • C’est possible, mais d’abord, cet article ne traite pas du NIHS, mais de son propre test dérivé, qui peut donc être plus pertinent. Ensuite, l’argument central de l’article est que GPT-4o fait mieux, or le test mentionné n’a pas benchmarké GPT-4o
  • Les modèles benchmarkés par RULER obtiennent de moins bons résultats sur needle-in-a-needlestack. Je serais curieux de voir ce que donne 4o sur RULER

• J’aimerais aussi voir ça avec Gemini Pro 1.5. La semaine dernière, j’ai essayé d’y mettre Moby Dick en entier, et une autre fois tous les livres publiés par Byung Chul-Han ; dans les deux cas, il a retrouvé à chaque fois, mot pour mot, les passages qui mentionnaient ma question ou y répondaient, sans hallucination.

  • Plusieurs personnes au labo travaillent sur l’évaluation en contexte long des LLM appliquée aux œuvres de fiction. Moby Dick a de très fortes chances de faire partie des données d’entraînement. C’est pourquoi les gens du labo ont exploré des livres récemment publiés pour éviter ce problème.
    Voir BooookScore (https://openreview.net/forum?id=7Ttk3RzDeu), présenté à l’ICLR la semaine dernière, et le preprint récent FABLES (https://arxiv.org/abs/2404.01261).
  • Ce contenu ne fait-il probablement pas partie du jeu d’entraînement ? Ce serait intéressant de refaire la même chose avec un ensemble de livres publiés après la dernière version du modèle.
  • J’ai donné à Gemini 1.5 Flash les 2 500 exemples liés dans l’article, et il a trouvé la bonne réponse : « The tree has diseased leaves and its bark is peeling. » : https://aistudio.google.com/
  • J’ai accès à ce modèle, et j’ai déjà vu une extraction de contexte impressionnante. J’y ai mis une grosse base de code en entier, et il l’a aussi très bien résumée.
    J’ai aussi vu quelqu’un analyser un énorme fichier de logs, mais pour identifier le moment où le modèle commence à rater quelque chose, il faut vraiment un test de type needle-in-a-needlestack comme celui-ci. À tout le moins, les développeurs de modèles peuvent s’en servir pour analyser les modèles proposés.
  • D’ici 2 à 5 ans environ, on pourra sans doute fournir un ePub et obtenir en quelques minutes une version roman graphique exacte. Je suis prêt à voir 4 000 dessins d’arbres façon Tolkien.

• Quelqu’un devrait créer un test de « synthèse dans la meule de foin » qui évalue non seulement la recherche, mais aussi la profondeur de compréhension, les connexions et l’abstraction entre différents éléments d’information.
  Quand une personne lit un livre, elle développe une « intuition globale » de ce livre. Il nous faut un moyen de quantifier cela. Les tests needle-in-haystack me semblent trop simples et ne vont pas assez loin.

  • On pourrait faire un whodunit sophistiqué à la Agatha Christie : ajouter plusieurs retournements et alibis, puis couper la fin de l’œuvre de sorte que le suspect le plus probable change.
  • On pourrait aussi avoir des aiguilles qui forment un graphe, et un prompt qui pose une tâche fondée sur ce graphe.
  • Il y a l’idée d’acheter un roman ou un scénario inédit, avec un univers détaillé et cohérent en interne et des personnages aux motivations bien conçues, puis de demander au modèle de continuer l’histoire à partir d’un point arbitraire après le milieu en reliant deux personnages qui ne se sont pas encore rencontrés.
    S’il comprend le contexte, il devrait être capable d’écrire une nouvelle partie de l’histoire et d’utiliser les motivations des personnages, telles qu’un lecteur les perçoit intuitivement, pour développer leur arc narratif. Mais pour que ce soit utile, il faudrait garder l’ensemble strictement privé, donc cela ne pourrait presque servir que de benchmark privé. Ou alors en faire une sorte de prix prestigieux, jugé sur la crédibilité même de ses conclusions plutôt que sur une méthodologie publiée pour faire progresser le domaine.
  • J’ai eu une idée similaire. Une partie de la question fournirait assez d’informations pour que le LLM retrouve le limerick, et la seconde partie poserait quelque chose nécessitant une compréhension plus profonde de ce limerick ou d’un autre texte.
  • C’est impossible, parce que la compréhension n’existe pas.
    GPT-4o n’arrive toujours pas à traiter l’intersection de deux idées différentes absentes du jeu d’entraînement. Il n’arrive même pas à produire des variations aléatoires sur l’intersection de deux idées différentes. Plus largement, il ne faut pas s’attendre à ce que le modèle fasse ce genre de choses. Ce n’est pas juste envers les modèles, leur utilité réelle et les choses étonnantes qu’ils accomplissent sans compréhension. Croire que le modèle comprend, c’est se tromper soi-même.

• On peut maintenant utiliser GPT pour transformer à la volée des données dynamiques brutes en belles mises en page HTML. Pour des pages peu consultées comme des journaux de changements ou des journaux d’audit, cela peut réduire fortement le temps de développement et maintenir le HTML à jour même quand la structure des données change.
  Les tentatives précédentes ne fonctionnaient pas de façon cohérente, car GPT-4-Turbo ignorait parfois presque entièrement le contexte et les consignes.

• Cet article montre à quel point la capacité de GPT-4o à prêter attention à toute la fenêtre d’entrée s’est améliorée par rapport à GPT-4 Turbo et Claude-3 Sonnet.
  Il fallait depuis un moment une évolution du test needle-in-a-haystack, et ce « Needle In A Needlestack » est une bonne étape suivante. NIAN crée un prompt contenant des milliers de limericks, puis pose une question sur un limerick situé à une position précise.

  • D’accord. J’ai payé Claude pendant un moment. Il met fortement en avant la prise en charge de grands contextes, et utiliser un grand contexte consomme énormément de tokens, mais il devenait presque inutilisable dès qu’il devait tenir compte de code source situé à seulement quelques pages en arrière.
    C’était d’autant plus frustrant que tout le reste était correct et que j’aimais bien son ton. J’ai essayé 4o hier soir, et il reconnaissait encore parfaitement une classe C++ que j’avais collée 20 questions plus tôt. Je me moque de savoir s’il est intelligent ; ce qui compte, c’est qu’il soit utile, et ça contribue énormément à son utilité.

• Je suis de plus en plus convaincu que presque personne sur l’Internet public ne sait faire une évaluation sérieuse des LLM.

  • Au moins, on a enfin dépassé les évaluations de LLM que tout le monde faisait en 2022-2023, du type « qui était le 29e président des États-Unis ? » ou « dessine dans le style de Van Gogh ».

• Pour que ce test ait du sens, il faut savoir que les données du jeu de test ne figuraient pas dans les données d’entraînement.

  • Si on pose la question sans fournir d’abord le limerick, il ne trouve jamais la bonne réponse. Quand le LLM se trompe, il revient généralement aux données d’entraînement et donne une réponse générique qui ne correspond pas au limerick.
  • Ce n’est pas forcément nécessaire. Il suffit de comparer les performances du modèle avant et après avoir téléversé les documents.
  • Je pensais que les limericks de test avaient été générés automatiquement.

• Ça fait plaisir à entendre. Le plus gros problème avec GPT-4.0 était la baisse de qualité à mesure que la conversation s’allongeait, ce qui comptait particulièrement pour les projets de code.
  Je me demande si cela s’est amélioré. Je vais le tester aujourd’hui.

  • Jusqu’ici, c’est aussi mon expérience. Mes conversations actuelles sont devenues absurdement plus longues que mes anciennes conversations GPT-4. Avant, je devais souvent copier le contexte et recommencer dans un nouveau chat.
  • Même expérience. Sur des prompts de 16k, Turbo était presque parfait ; à 32k, il était médiocre, et au-delà de 100k il était inutilisable. Pour obtenir de bons résultats avec de longs prompts, il faut y répéter les informations.