Fais l’expérience avec Claude (ou un autre modèle avancé), demande lui une explication sur un domaine assez pointu mais que tu connais relativement bien, regarde le répondre correctement, prend un point de détails au hasard, demande lui "as-tu halluciné ce point". Il te répondra la plupart du temps "non, c’est un véritable concept".
Tandis que quand il hallucine pour de vrai, si tu lui demandes "as-tu halluciné X", il te répond "oui, désolé".
Il connaît donc bien la différence entre les deux.
(à noter que je n’ai pas encore vu Claude 3.7 halluciner)
Imaginons que tu ais le meilleur modèle qui commet une erreur 5% du temps et le moins bon (tout en bas des classements à la mode), qui en fait 15% du temps.
Dans ce cas, le second modèle ne pourra faire que des tâches limitées à 4 étapes avant d’être à <50% de taux de réussite, tandis que le premier pourra faire 13 étapes. À 1%, tu arrives à 68 étapes.
Donc oui, la qualité du modèle a une énorme influence sur l’horizon temporel des tâches qu’il est capable d’effectuer, bien plus qu’on ne le penserait en évaluant naïvement sur une étape unique.
Tu le dis toi même, repérer ses propres erreur est un truc sur lequel les llms ont beaucoup de mal.
Pour que ça arrive, il faut lui indiquer l'erreur (via la sortie d'un interpréteur, la réponse d'un appel de fonction ou une remarque humaine).
Exactement comme les humains ? Je vois rarement des programmeurs dire "je me suis planté" avant que le compilateur / les tests unitaires / les tests manuels / la revue de code révèlent un problème.
Ce qui est rigolo, c’est que je gère des devs juniors et Claude (sur mon équivalent de Claude Code), et que je vois exactement les mêmes problèmes dans les deux cas.
Incapacité de remettre en question des hypothèses si elles ne sont pas pile poil dans l’instruction actuelle. Incapacité de trouver ses propres erreurs sans un input externe. Face à une erreur, sauter immédiatement à la résolution la plus évidente sans regarder un peu en arrière "est-ce vraiment aussi évident / le problème ne serait pas plus large ?".
Un certain état d’esprit "Si le compilateur râle, c’est la faute du compilateur, je dois trouver un moyen de le cajoler" plutôt que "le compilateur pointe vers un réel problème" (par exemple en Typescript : "si j’ai une erreur de types, c’est forcément parce que les types sont mauvais, pas parce que le type checker a trouvé une erreur dans mon code, je dois trouver un moyen de réduire au silence cette erreur").
Et de même que mes juniors finiront par s’améliorer, je ne vois aucune raison de supposer que ces problèmes sont inhérents aux LLMs en général et que la prochaine génération ne fera pas mieux à ce niveau
conjugué à une passe récursive de contrôle critique du llm sur sa propre génération via des instructions spécifiques
Je suis sceptique de cette solution en particulier. Ça n’a pas l’air d’aider énormément Claude à finir Pokemon, et en pratique Claude a du mal à faire dans la demi-mesure "peut-être que j’ai un peu tort". Mais peut-être est-ce spécifique à Claude, je devrai probablement me motiver et tester sérieusement Gemini.
On a exactement le même problème avec les llms à qui l'on veut attribuer des propriétés émergentes alors que ça ne sont que des ajustements induits par leurs développeurs.
Les créateurs sont régulièrement surpris par certains aspects de leur création (voir par exemple le dernier papier d’Anthropic sur le sujet, https://www.anthropic.com/research/tracing-thoughts-language-model), ce qui est pour moi pile poil dans la définition de "propriété émergente" ? Ou tu penses à autre chose ?
Peut être ais je des failles dans mon raisonnement, mais je n'ai pas l'idée d'un seul domaine du monde réél où on prendrait un llm à qui on demanderait de rendre des services en totale autonomie sans que ça ne tourne rapidement en rond (dans le meilleur des cas), ou en hors sujet (plus probablement).
Je ne dis pas que les wrappers sont entièrement inutiles. Je dis qu’ils sont destinés à être de plus en plus triviaux et comparativement (entre eux) peu impactants à mesure que la qualité des modèles progresse.
Je comparerai les wrappers dans une "solution IA" à la CB chez les commerçants : quasi-obligatoire certes, mais c’est pas ça qui va faire le succès ou l’échec.
Refaire Claude/Gemini/ChatGPT c’est très dur, ça demande énormément de ressources, la preuve personne n’arrive à les rattraper. Faire des wrappers autour c’est trivial, tu peux le faire toi-même en une semaine dans ton garage, et il y en à la pelle en open-source sur github. C’est pour ça que je ne considère pas ça comme "important", même si c’est nécessaire pour faire des agents : c’est un problème "résolu" et dont la solution est largement "connue" (pour ceux qui prennent la peine de s’intéresser au sujet bien sûr), contrairement aux modèles de la prochaine génération.
Si tu préfères tourné comme ça : les modèles sont le facteur limitant (et donc critique), pas les wrappers.
[^] # Re: Et Mistral ?
Posté par Moonz . En réponse à la dépêche Nouvelles sur l’IA de mars 2025. Évalué à 2. Dernière modification le 11 avril 2025 à 11:31.
Probablement largement faux : https://arxiv.org/abs/2310.06824
Fais l’expérience avec Claude (ou un autre modèle avancé), demande lui une explication sur un domaine assez pointu mais que tu connais relativement bien, regarde le répondre correctement, prend un point de détails au hasard, demande lui "as-tu halluciné ce point". Il te répondra la plupart du temps "non, c’est un véritable concept".
Tandis que quand il hallucine pour de vrai, si tu lui demandes "as-tu halluciné X", il te répond "oui, désolé".
Il connaît donc bien la différence entre les deux.
(à noter que je n’ai pas encore vu Claude 3.7 halluciner)
Largement faux, je renvoie à un de mes précédents commentaires : https://linuxfr.org/users/fdf/journaux/je-suis-perdu-et-je-pensais-m-etre-renseigne#comment-1983815
Dans ce cas, le second modèle ne pourra faire que des tâches limitées à 4 étapes avant d’être à <50% de taux de réussite, tandis que le premier pourra faire 13 étapes. À 1%, tu arrives à 68 étapes.
Donc oui, la qualité du modèle a une énorme influence sur l’horizon temporel des tâches qu’il est capable d’effectuer, bien plus qu’on ne le penserait en évaluant naïvement sur une étape unique.
Exactement comme les humains ? Je vois rarement des programmeurs dire "je me suis planté" avant que le compilateur / les tests unitaires / les tests manuels / la revue de code révèlent un problème.
Ce qui est rigolo, c’est que je gère des devs juniors et Claude (sur mon équivalent de Claude Code), et que je vois exactement les mêmes problèmes dans les deux cas.
Incapacité de remettre en question des hypothèses si elles ne sont pas pile poil dans l’instruction actuelle. Incapacité de trouver ses propres erreurs sans un input externe. Face à une erreur, sauter immédiatement à la résolution la plus évidente sans regarder un peu en arrière "est-ce vraiment aussi évident / le problème ne serait pas plus large ?".
Un certain état d’esprit "Si le compilateur râle, c’est la faute du compilateur, je dois trouver un moyen de le cajoler" plutôt que "le compilateur pointe vers un réel problème" (par exemple en Typescript : "si j’ai une erreur de types, c’est forcément parce que les types sont mauvais, pas parce que le type checker a trouvé une erreur dans mon code, je dois trouver un moyen de réduire au silence cette erreur").
Et de même que mes juniors finiront par s’améliorer, je ne vois aucune raison de supposer que ces problèmes sont inhérents aux LLMs en général et que la prochaine génération ne fera pas mieux à ce niveau
Je suis sceptique de cette solution en particulier. Ça n’a pas l’air d’aider énormément Claude à finir Pokemon, et en pratique Claude a du mal à faire dans la demi-mesure "peut-être que j’ai un peu tort". Mais peut-être est-ce spécifique à Claude, je devrai probablement me motiver et tester sérieusement Gemini.
Les créateurs sont régulièrement surpris par certains aspects de leur création (voir par exemple le dernier papier d’Anthropic sur le sujet, https://www.anthropic.com/research/tracing-thoughts-language-model), ce qui est pour moi pile poil dans la définition de "propriété émergente" ? Ou tu penses à autre chose ?
Je ne dis pas que les wrappers sont entièrement inutiles. Je dis qu’ils sont destinés à être de plus en plus triviaux et comparativement (entre eux) peu impactants à mesure que la qualité des modèles progresse.
Je comparerai les wrappers dans une "solution IA" à la CB chez les commerçants : quasi-obligatoire certes, mais c’est pas ça qui va faire le succès ou l’échec.
Refaire Claude/Gemini/ChatGPT c’est très dur, ça demande énormément de ressources, la preuve personne n’arrive à les rattraper. Faire des wrappers autour c’est trivial, tu peux le faire toi-même en une semaine dans ton garage, et il y en à la pelle en open-source sur github. C’est pour ça que je ne considère pas ça comme "important", même si c’est nécessaire pour faire des agents : c’est un problème "résolu" et dont la solution est largement "connue" (pour ceux qui prennent la peine de s’intéresser au sujet bien sûr), contrairement aux modèles de la prochaine génération.
Si tu préfères tourné comme ça : les modèles sont le facteur limitant (et donc critique), pas les wrappers.