5 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Kimi K2.6, le modèle à poids ouverts de Moonshot AI, a remporté le AI Coding Contest Day 12 sur le Word Gem Puzzle avec 22 points de match et un bilan de 7-1-0
  • MiMo V2-Pro de Xiaomi a terminé 2e avec 20 points, ChatGPT GPT-5.5 3e avec 16 points, GLM 5.1 4e avec 15 points et Claude Opus 4.7 5e avec 12 points ; les modèles d'Anthropic, OpenAI, Google et xAI ont tous fini derrière les deux premiers
  • Word Gem Puzzle est un puzzle de lettres en tuiles coulissantes allant de 10×10 à 30×30 ; les mots de moins de 7 lettres subissent une pénalité, ceux de 7 lettres ou plus valent longueur - 6 points, et chaque paire de modèles joue 5 manches par taille de grille avec une limite de 10 secondes
  • Kimi K2.6 a totalisé 77 points grâce à une stratégie gloutonne de glissement choisissant de façon répétée les coups qui ouvrent des mots à valeur positive, tandis que MiMo V2-Pro a pris la 2e place avec 43 points cumulés en soumettant d'un coup les mots de 7 lettres ou plus présents dans la grille initiale, sans réellement faire glisser les tuiles
  • Ce résultat ne signifie pas qu'un seul puzzle renverse les benchmarks généraux, mais le fait que Kimi K2.6, un modèle téléchargeable, atteigne 54 points dans l'Artificial Analysis Intelligence Index, contre 60 pour GPT-5.5 et 57 pour Claude, montre que l'écart concurrentiel s'est resserré

Composition du tournoi et modèles participants

  • GLM 5.1 de Zhipu AI a fini 4e, tandis que DeepSeek V4 n'a pris que la 8e place
  • Le code produit par Nemotron Super 3 de Nvidia contenait des erreurs de syntaxe et n'a pas pu se connecter au serveur du jeu ; la compétition réelle s'est donc jouée entre 9 modèles
  • Kimi K2.6 est un modèle à poids ouverts publiquement disponible de la startup chinoise Moonshot AI, fondée en 2023, tandis que MiMo V2-Pro est pour l'instant réservé à l'API
  • Xiaomi a confirmé que les poids du modèle plus récent V2.5 Pro seront bientôt publiés
  • Ce résultat ne se résume pas à un simple récit du type « la Chine a battu l'Occident », mais à la victoire de deux modèles précis : Kimi K2.6 et MiMo V2-Pro

Règles du Word Gem Puzzle

  • Word Gem Puzzle est un puzzle de lettres en tuiles coulissantes joué sur une grille rectangulaire remplie de tuiles alphabétiques et d'une case vide
  • La taille de la grille est l'une des suivantes : 10×10, 15×15, 20×20, 25×25 ou 30×30, et le bot peut pousser dans la case vide une tuile adjacente
  • Le bot peut à tout moment soumettre un mot anglais valide formé en ligne droite horizontalement ou verticalement
  • Les mots en diagonale et les mots à l'envers ne sont pas acceptés
  • Le score est conçu pour récompenser les mots longs et pénaliser les mots courts
    • Les mots de moins de 7 lettres font perdre des points
    • Un mot de 5 lettres coûte 1 point, un mot de 3 lettres en coûte 3
    • Les mots de 7 lettres ou plus valent longueur - 6 points ; un mot de 8 lettres vaut donc 2 points
  • Un même mot ne peut être soumis qu'une seule fois, et un mot déjà soumis par un autre bot ne rapporte aucun point
  • Chaque paire de modèles a disputé une manche par taille de grille, soit 5 manches au total, avec une limite de 10 secondes en temps mur par manche
  • Les grilles sont générées en plaçant de vrais mots de dictionnaire à la manière de mots croisés, puis en remplissant les cases restantes avec des lettres selon la fréquence des tuiles du Scrabble, avant de mélanger la position de la case vide
  • Plus le plateau était grand, plus le mélange était intense : sur 10×10, beaucoup de mots semés restaient intacts, alors que sur 30×30 il n'en restait presque plus

Comportement des modèles et facteurs de réussite ou d'échec

  • Kimi K2.6

    • Kimi K2.6 a gagné en faisant activement glisser les tuiles et a signé le meilleur score du tournoi avec un total de 77 points
    • Sa stratégie était gloutonne : chaque coup possible était évalué selon les mots à valeur positive qu'il ouvrait, puis le meilleur coup était exécuté, et ainsi de suite
    • Lorsqu'aucun coup n'ouvrait de mot positif, il choisissait la première direction légale par ordre alphabétique
    • Cette méthode pouvait créer des inefficacités de type 2-cycle, où la case vide rebondissait d'avant en arrière sur un bord sans réel progrès
    • Sur les petites grilles, de nombreux mots semés restaient en place, donc cette inefficacité lui coûtait des points ; mais sur 30×30, presque tous les mots étaient brisés et devaient être reconstruits, si bien que le grand nombre de glissements a fini par se transformer en score
  • MiMo V2-Pro

    • Le code de glissement de MiMo existait bien dans le dépôt, mais la condition « meilleure valeur > 0 » ne se déclenchait pas, si bien qu'il n'a en pratique jamais glissé
    • Il parcourait la grille initiale à la recherche de mots de 7 lettres ou plus, puis envoyait toutes ses soumissions dans un seul paquet TCP
    • Cette stratégie était fragile, car elle dépendait entièrement du fait que des mots semés restent intacts après le mélange
    • Quand ces mots restaient présents, il marquait vite ; quand ils ne restaient pas, il ne marquait rien du tout
    • Son score cumulé final a été de 43 points, ce qui lui a valu la 2e place au général
  • Claude Opus 4.7

    • Claude non plus n'a pas glissé les tuiles
    • D'après les journaux de déplacement, il a tenu sur les plateaux 25×25 où la densité de mélange restait encore gérable, mais il s'est effondré sur 30×30, où de vrais déplacements de tuiles devenaient nécessaires
    • Dans un puzzle à tuiles coulissantes, ne pas faire glisser les tuiles constitue une limite évidente
  • GPT-5.5

    • GPT-5.5 a adopté une approche plus prudente, avec environ 120 glissements par manche et une borne supérieure pour éviter les allers-retours infinis
    • Il a affiché ses meilleurs résultats sur les grilles 15×15 et 30×30
  • Grok Expert 4.2 et GLM 5.1

    • Grok n'a pas glissé non plus, mais a obtenu des scores relativement corrects sur les grands plateaux
    • GLM a été le modèle le plus agressif en matière de glissement sur l'ensemble du tournoi, avec plus de 800 000 glissements au total
    • GLM se bloquait fortement chaque fois que les coups positifs disparaissaient
  • DeepSeek V4

    • DeepSeek envoyait à chaque manche des données au mauvais format
    • Sa sortie n'était d'aucune utilité, mais au moins il n'a pas aggravé son score en jouant
  • Muse Spark

    • Muse soumettait tous les mots qu'il trouvait, quelle que soit leur longueur
    • Les règles de score ont été conçues pour pénaliser les mots courts afin d'empêcher une stratégie consistant à soumettre en masse des mots comme « the », « and » ou « it », et tous les modèles compétitifs filtraient donc leur dictionnaire pour ne garder que les mots de 7 lettres ou plus
    • Sur les grilles 30×30, Muse trouvait et soumettait tous les centaines de mots courts valides visibles à un instant donné
    • Son score cumulé a été de −15 309 points ; il a perdu ses 8 matchs et n'a remporté aucune manche
    • S'il avait existé une version de Muse se contentant de se connecter au serveur sans rien faire, elle aurait obtenu 0 point, soit 15 309 points de plus que le vrai Muse
    • L'écart entre Muse et le 8e était plus grand que l'écart entre le 8e et le 1er

Le rôle décisif de la grille 30×30

  • La grille 30×30 a été celle qui a le plus nettement séparé les modèles participants
  • Sur les petits plateaux, l'écart entre les scanners statiques et les glisseurs actifs restait limité ; mais à la taille maximale, les modèles qui se contentaient de chercher des mots déjà présents ne trouvaient plus rien à soumettre
  • La boucle gloutonne de Kimi avait des défauts, mais elle continuait à produire des sorties même lorsque les scanners statiques n'avaient plus de mots à proposer
  • MiMo et Kimi ont utilisé des stratégies presque opposées, et pourtant l'écart final n'a été que de 2 points
  • L'écart entre le 1er et le 2e reflétait donc non seulement une différence de capacité, mais aussi en partie la variabilité des seeds

Les risques mis en lumière par les tâches structurées

  • La sortie au mauvais format de DeepSeek donne un signal sur la manière dont les modèles gèrent une spécification de protocole peu familière sous contrainte de temps
  • Muse trouvait bien des mots valides et les soumettait, mais n'appliquait pas une définition de la « validité » tenant compte des règles de score
  • Son échec illustre un cas où le modèle lit partiellement la tâche, puis exécute jusqu'au bout cette interprétation partielle
  • Lorsqu'on déploie un modèle sur une tâche structurée assortie de pénalités, une exécution qui n'intègre pas l'ensemble des règles peut entraîner de lourdes pertes

Limites d'interprétation et portée du résultat

  • Ce système de score récompense les soumissions agressives de mots, et des modèles fortement ajustés pour la sûreté peuvent être plus prudents face à ce type de stratégie de soumission massive
  • Dans ce cas, le résultat peut refléter moins une différence de capacité pure qu'un décalage entre la conception de la tâche et le comportement aligné du modèle
  • Un seul défi ne renverse pas les benchmarks généraux
  • Ce puzzle évalue la prise de décision en temps réel et la capacité à écrire du code opérationnel capable de se connecter à un serveur TCP et de jouer correctement à un nouveau jeu
  • Il ne s'agit pas d'une épreuve de raisonnement à long contexte ni d'un test général de génération de code à partir de spécifications
  • Kimi K2.6 obtient 54 points dans l'Artificial Analysis Intelligence Index, contre 60 points pour GPT-5.5 et 57 points pour Claude
  • Ces scores ne signifient pas une égalité parfaite, mais ils restent proches, et le fait que Kimi K2.6 soit un modèle que tout le monde peut télécharger change la dynamique concurrentielle
  • Pouvoir exécuter librement en local un modèle situé à seulement quelques points de l'état de l'art crée une situation concurrentielle différente de celle d'il y a un an
  • Ce défi constitue un point de donnée montrant que l'écart s'est réduit au point de permettre ce type de résultat

1 commentaires

 
GN⁺ 2 시간 전
Commentaires Hacker News
  • J’ai l’impression qu’on va continuer à voir ce genre d’articles pendant l’année à venir, parce qu’il n’existe pas de méthode objective pour comparer les modèles. Mis à part des chiffres de bas niveau comme la vitesse de génération de tokens, le nombre moyen de tokens de raisonnement, le nombre de paramètres ou le nombre d’experts actifs, les usages diffèrent selon les modèles, les utilisateurs diffèrent aussi, et rien n’est déterministe
    Donc on continuera à voir des benchmarks et des déclarations du type « ce modèle a battu cet autre modèle », mais il n’y a pas de meilleur modèle absolu. Il n’y a que des modèles adaptés à des critères différents, et au final on risque d’aboutir à un monde où chacun reste dans son camp, comme avec Windows vs MacOS vs Linux

    • Le vrai point n’est pas la manière de comparer les modèles, mais le fait que Kimi K2.6 et DeepSeek v4 Pro soient quasiment au niveau d’Opus, et c’est déjà énorme
      Ils sont open source et coûtent bien moins cher par token que les modèles américains. En ce moment, j’utilise le plan cloud Ollama à 20 $, et je peux réellement faire avancer des projets perso sur lesquels j’atteignais la limite après un ou deux prompts avec le plan Claude Pro à 20 $. J’ai choisi Ollama surtout parce que son CLI est pratique, et comme beaucoup d’acteurs proposent ces modèles, on n’est pas non plus coincé avec de mauvaises conditions ou des règles d’usage contraignantes. J’y vois un signal assez mauvais pour l’économie américaine
    • Il existe bien une méthode objective pour comparer les modèles. Il faut utiliser l’échantillonnage répété et l’analyse statistique pour déterminer si un résultat a des chances de se maintenir ou s’il ne s’agit que d’un hasard
      Si on ajuste finement chaque modèle pour obtenir sa meilleure performance sur les tâches visées, les classements de différents benchmarks concordent à un degré assez élevé : https://arxiv.org/abs/2507.05195
      Mais l’auteur de ce billet n’a pas suivi cette procédure. Il n’a exécuté chaque modèle qu’une seule fois sur 13 problèmes jusqu’à présent, puis a mis en avant le résultat du 12e problème. Il est difficile de parler de p-hacking puisqu’il n’a même pas réfléchi à la p-value. La qualité des grands modèles de langage varie fortement d’une exécution à l’autre, donc exécuter chaque modèle une seule fois revient un peu à lancer deux pièces une fois, obtenir pile pour l’une et face pour l’autre, puis prétendre dire laquelle est la plus biaisée
    • Je suis en partie d’accord, mais le travail pour rendre les métriques comparables est en cours. Par exemple : https://ghzhang233.github.io/blog/2026/03/05/train-before-te...
      Ce n’est pas encore largement adopté, et selon les intérêts de chacun, il peut même être avantageux que cela reste ainsi pendant un moment. En pratique, c’est assez proche du p-hacking
    • Mes cas d’usage des grands modèles de langage et mes environnements d’exécution agentique sont assez limités, donc à chaque nouveau modèle ou nouvel outil d’exécution, je ne teste qu’un ou deux de mes cas d’usage, je me fais un avis subjectif, puis j’ignore la plupart des benchmarks
      Les blogs et les articles sont soit un business en soi, soit un moyen d’amener du trafic vers des activités liées à la tech, et une grande partie des articles d’évaluation sert surtout à attirer l’attention. Ce n’est pas forcément mauvais en soi, mais cela génère beaucoup de bruit
    • Je pense qu’on finira dans une situation similaire au recrutement de personnes. On peut regarder le CV, autrement dit les benchmarks, mais on ne peut pas être sûr avant d’avoir travaillé avec quelqu’un pendant six mois
      L’industrie est presque incapable de déterminer objectivement si un ingénieur logiciel est meilleur qu’un autre, sur pratiquement n’importe quelle dimension. Je ne vois donc pas pourquoi on pense pouvoir établir un classement objectif des modèles
  • Je suis content qu’on s’oriente vers des tests à notation objective
    Nous faisons cela à grande échelle sur https://gertlabs.com/rankings, et même si l’auteur semble n’avoir fait tourner qu’un échantillon ponctuel, les bonnes performances de Kimi K2.6 ne sont pas surprenantes. D’après nos tests, surtout en programmation, Kimi se situe dans la marge d’incertitude statistique de MiMo V2.5 Pro, qui est le meilleur modèle à poids ouverts, et il est nettement meilleur que DeepSeek V4 Pro pour l’usage d’outils. GPT 5.5 garde une nette avance, mais Kimi est au niveau d’Opus 4.6, voire meilleur. En revanche, le problème de Kimi 2.6, c’est qu’il fait partie des modèles lents parmi ceux que nous avons testés

    • La notation peut être objective, mais cela ne montre pas la capacité à coder de qui que ce soit. Ce test mesure plutôt quel modèle a trouvé, presque par hasard, la meilleure stratégie contre d’autres bots
      Pour que cela soit représentatif du code, il faudrait tester plus de 100 puzzles de ce type, sur tout le spectre des puzzles, afin de voir qui trouve le mieux des stratégies exploitant un dictionnaire anglais
    • Dans les workflows agentiques, Qwen Flash et les modèles DeepSeek Flash semblent plutôt bons
      Cela correspond aussi à un commentaire vu ici hier disant que les modèles Flash gèrent mieux les appels d’outils. Une combinaison avec GPT 5.5 pour la planification et un modèle Flash pour l’implémentation pourrait offrir un bon rapport qualité-prix
    • D’après mon expérience, les benchmarks n’ont pas beaucoup de sens
      Les performances dépendent non seulement de la langue et de la tâche, mais aussi du prompt utilisé et du résultat attendu. Lors de tests internes, il a été vraiment difficile de déterminer si GPT 5.5 était meilleur qu’Opus 4.7. Les styles sont différents, et au final cela tient presque au goût personnel. Il m’est même arrivé de donner la victoire à un modèle, puis de reconsidérer la chose et de changer d’avis. Au final, j’ai une légère préférence pour Opus 4.7
    • Les tests et les résultats sont-ils open source ?
    • Je me demande pourquoi on ne peut pas fournir une mesure de la taille de contexte chez les humains. On dirait qu’il devrait exister assez de science pour en faire au moins une bonne approximation
  • D’après une étude que j’ai lue il y a quelques jours, au rythme actuel, les modèles open source devraient dépasser les modèles cloud d’ici quelques années
    Quand on repense à ChatGPT et Claude d’il y a quelques années, même un très petit modèle Qwen est aujourd’hui presque équivalent à ce que faisaient alors les modèles cloud en programmation. En tenant compte des lois d’échelle, passer de 9B à 18B représente environ 40 % d’augmentation, alors que de 18B à 35B, c’est plutôt 20 %, donc il semble probable qu’au minimum les modèles cloud voient évoluer leurs prix. Adobe aussi coûtait autrefois 600 $ par mois, puis c’est tombé à 20 $ avec l’augmentation de l’échelle de distribution

    • Ça n’a pas de sens, et ça sent l’extrapolation de tendance bien au-delà de conditions valides
      La vérité simple, c’est que les modèles cloud pourront toujours être strictement supérieurs aux modèles ouverts. Les fournisseurs de modèles cloud peuvent eux aussi exécuter les mêmes modèles ouverts. En plus, ils conservent les économies d’échelle et les gains d’efficacité liés à l’exploitation de grands datacenters remplis de matériel spécialisé. Ils peuvent au minimum proposer ces modèles ouverts à un prix par token inférieur à la facture d’électricité de n’importe qui. Par-dessus cela, ils ont aussi les équipes qui recherchent sur les modèles et les systèmes périphériques, ainsi que les moyens d’affecter les meilleurs ingénieurs à des environnements d’exécution toujours en avance sur les outils à la mode sur GitHub
    • C’est possible, mais ce qui m’inquiète, c’est surtout le matériel
      Même si on a un modèle suffisamment bon, que se passe-t-il si les fournisseurs de modèles cloud sont simplement meilleurs pour sécuriser le matériel d’inférence ?
    • Je ne vois pas de quel produit il s’agit quand tu dis qu’« Adobe coûtait 600 $ par mois avant de tomber à 20 $ avec l’extension de la distribution ». Je n’ai jamais entendu parler d’un produit Adobe aussi cher
    • 600 $ par mois ? Tu veux parler d’une licence perpétuelle achetée en une fois à 600 $ ? Je n’ai jamais entendu parler d’une offre Adobe aussi chère
    • Si tu as le lien vers l’étude dont tu parles, ce serait bien de le partager
  • Kimi est vraiment bon
    J’ai utilisé Sonnet, DeepSeek, ChatGPT, MiniMax, Qwen et d’autres sur un projet de compilateur / machine virtuelle, et le plan Claude Pro est quasiment inutilisable pour un vrai travail de programmation. Du coup, je l’utilise en mode chat dans le navigateur pour l’empêcher de relire inutilement tout le projet, et j’utilise Kimi avec pi sur le plan OpenCode Go. Sur les projets C+Python, Kimi a constamment surpassé Sonnet, et je n’ai jamais craint qu’il fasse autre chose que ce que je lui avais demandé. GLM a gravement déraillé une ou deux fois, mais Kimi non

    • Je me demande pourquoi tu dis que « le plan Claude Pro est quasiment inutilisable pour un travail de programmation sérieux ». Cela semble à l’opposé de l’opinion générale selon laquelle Claude Pro est surtout utilisé pour le code sérieux
  • Il s’agit d’un résultat sur une tâche unique, mesuré uniquement à la performance de la solution
    Kimi K2.6 est clairement un modèle de taille frontier, donc le voir aux côtés des modèles frontier fermés n’a rien d’extraordinaire. Le fait qu’il soit ouvert est appréciable, mais pour moi qui n’ai qu’un seul GPU grand public, cela ne change pas grand-chose

    • La valeur de l’open source ne tient pas au fait que je puisse l’exécuter en local, mais au fait que quelqu’un puisse l’exécuter
      Même si je n’ai pas les moyens d’acheter le matériel nécessaire pour faire tourner de grands modèles open source, quelqu’un les aura, et pourra rester rentable en les vendant à la moitié du coût des modèles fermés. La seule raison pour laquelle on ne le voit pas encore, c’est que les leaders actuels subventionnent le coût de l’inférence. Dès qu’ils commenceront à dégrader la qualité et à forcer la monétisation, un marché alternatif deviendra possible. Sans modèles open source, il n’y a pas d’alternative réelle. Même si un acteur veut facturer seulement 80 % du coût développeur, l’existence de modèles open source qui ne sont pas très loin derrière joue comme une contrainte. Ils n’ont pas de moat
    • Bien sûr que si, cela a de l’importance. C’est précisément ce qui permet des offres bien moins chères que les plans de code d’Anthropic et d’OpenAI
      Pour un usage personnel, j’utilise des plans de code GLM 5.1, Kimi K2.6, MiniMax M2.7 et Xiaomi MiMo V2.5 Pro, et le rapport qualité-prix est excellent
    • C’est vraiment important
      La dégradation de qualité ne sera pas évidente au début, mais je vois déjà des modèles frontier que j’aimais beaucoup s’affaiblir fortement et se mettre à faire des choses absurdes qu’ils ne faisaient pas avant. Plus nous en dépendons, plus nous avons besoin de modèles à poids ouverts jouant le rôle de plateforme stable
    • L’avenir est de ce côté. Des modèles à poids ouverts tournant sur H200 offrent bien plus d’occasions de construire des produits et une véritable infrastructure
      Pour un petit RTX à la maison, on pourra toujours distiller. Mais les modèles conçus pour du matériel grand public auront du mal à être largement adoptés ou à rester compétitifs face aux laboratoires frontier. En revanche, cette forme peut rivaliser, et elle nécessitera tout en stimulant une nouvelle génération d’infrastructure cloud ouverte pour l’inférence. Au début, on verra des produits du type « déployer en un clic » ou « fine-tuner en un clic », puis plus tard des produits bien plus avancés rendus possibles uniquement par des poids ouverts non verrouillés derrière une API. Il ne manque plus maintenant que l’équivalent en poids ouverts de Nano Banana Pro / GPT Image 2 et Seedance 2.0. La bataille et l’attention devraient se concentrer sur les poids ouverts pour datacenter
  • J’ai été surpris par le classement, mais après avoir lu le contenu du test, j’ai compris. Cela ne semble pas avoir grand-chose à voir avec la programmation
    Le classement actuel de l’ensemble des tests paraît plus logique, sauf peut-être pour la performance de Gemini : https://aicc.rayonnant.ai

    • En regardant le détail du classement, Kimi K2.6 n’a participé qu’aux 5 derniers challenges. Avant cela, c’était Claude qui dominait, et si on ne compte que les 5 derniers, Kimi est premier
    • Le classement aux médailles d’or n’a de sens que si tous les modèles participent à tous les tests
      DNP signifie qu’ils n’ont pas participé. Sous cet angle, Kimi a obtenu plus de médailles, et de meilleures, que Claude
    • C’est ironique qu’un site qui gère autant de modèles ne soit pas responsive sur mobile
    • Le lien fourni confirme en fait l’avantage de Kimi
  • C’est anecdotique, mais après avoir utilisé uniquement Claude Code pendant les derniers mois, j’ai été agréablement surpris par les capacités de Pi + Kimi K2.6. Via OpenRouter, c’est bien plus rapide et bien moins cher

  • Malheureusement, Kimi n’est pas du tout au niveau de GPT ou d’Opus. J’aimerais vraiment que ce soit le cas, mais ce n’est pas le cas
    Je fais tourner une évaluation où le modèle doit générer du code pour créer des modèles 3D, et il est clair qu’il lui manque de la compréhension spatiale et qu’il produit beaucoup plus d’erreurs de code avant de réussir. Il peut être meilleur sur certains cas particuliers, et je suppose que ce billet de blog en est un exemple

    • Un peu hors sujet, mais j’ai utilisé DeepSeek V4 Pro ces dernières semaines, et dans l’ensemble il est au niveau d’Opus. Sauf pour Blender
      Ce n’est même pas une question de vision. DeepSeek n’est pas multimodal, mais pour une raison que j’ignore, Opus comprend bien mieux l’API Blender. J’ai l’impression qu’il existera toujours de petits domaines où les modèles frontier fermés seront légèrement meilleurs
    • Pour être juste, tout le monde n’a pas besoin de modèles 3D
  • Cela ressemble moins à une preuve que Kimi code mieux que Claude qu’au fait qu’il ait trouvé la bonne stratégie pour un jeu donné
    Cela reste intéressant. Le vrai point essentiel est peut-être que les modèles à poids ouverts se sont suffisamment rapprochés pour que l’écart devienne significatif

  • Je ne connais pas très bien le domaine de l’IA, mais vouloir entraîner n’importe quel modèle à tout faire pour tout le monde me semble vraiment être une idée absurde
    Cela demande des ressources énormes et crée des pénuries ainsi que des distorsions de marché sur toutes les ressources qu’utilisent les entreprises d’IA : RAM, SSD, datacenters, etc. Dans la vraie vie, quand on engage un plombier, on n’attend pas aussi de lui qu’il fasse du paysagisme, de la réparation automobile et de la retouche de vêtements. Par exemple, il semblerait bien plus efficace en ressources de pouvoir télécharger une app spécialisée en shell, Python et C, ou même trois apps de ce type qui communiquent entre elles. Cela pourrait peut-être tourner sur une machine ordinaire avec 16 Go de RAM. On n’a pas forcément besoin d’un énorme modèle capable de coder aussi bien en Fortran, COBOL et Lisp. Les humains s’en sortent très bien avec la spécialisation, et j’aimerais voir davantage de petits modèles d’IA ciblés être explorés plutôt que cette trajectoire actuelle du « un seul modèle domine tout et ne tourne que dans des datacenters de taille étatique »

    • C’est globalement vrai, mais il y a aussi des cas où ce n’est pas le cas
      Depuis GPT-3, des gens affirment qu’aucun modèle ne peut être aussi généraliste et que le fine-tuning est donc préférable, mais au fil des générations, cela devient de moins en moins vrai