Le choix des mots > "Combler la solitude" - très mal choisi comme expression je trouve
Alors quand j'entends Ferry dire qu'il n'y avait pas une virgule à changer dans un texte traduit par GPT et que, dans sa maison d'édition, il n'y a plus aucun traducteur humain... J'ai de très gros doutes sur cette affirmation et/ou sur la qualité de dites traductions (outre le fait que je pourrais en avoir aussi sur les textes "originaux" de Luc Ferry). Bien entendu, on pourrait juste dire qu'il grossit le trait, qu'il exagère pour servir son propos. Mais c'est bien ça le problème dans ces auditions et plus généralement dans les discours plus ou moins catastrophistes... On affirme une demi-vérité, un demi-mensonge et puis on déroule, alors que la base n'est déjà pas très solide. Après je ne dis pas que l'IA ne va pas bouleverser entièrement le secteur de la traduction (puisque c'est déjà le cas), je dis juste que ça n'est pas "hop on appuie sur un bouton et c'est fait".
Mon expérience récente
Bon, j'ai traduit moi-même un de mes textes dans les trois langues que je parle (plus ou moins bien) avec l'aide de GPT, Claude et Mistral. Juste pour préciser : ç'était pas un simple copier-coller dans un chat. J’avais préparé un corpus de textes, mais aussi des fichiers d’analyse sur ma manière d’écrire, obsessions de style, les effets que je voulais préserver, un fichier anti-lissage aussi... Je ne suis pas un expert, donc c'était un peu de la bidouille, mais j'étais content, ça m'a fait progresser. À partir du dossier de cadrage, j’ai utilisé un agent pour le workflow GPT, Claude (Le Chat de Mistral en parallèle plutôt manuellement), comparer leurs traductions, pointer des pertes de ton ou de sens... Le texte me paraissait trop long aussi pour être traité en une seule fois (enfin je préférais découper aussi). Je faisais donc plusieurs passes (texte global, puis morceau par morceau, puis reprise du tout)
Puis j'ai repris le tout, petit morceau par petit morceau. J'y ai passé des heures très très intéressantes. Je savais déjà que la traduction était de la réécriture, mais je ne m'imaginais pas à quel point. J'ai parfois passé 20 minutes sur quelques mots qui se révélaient intraduisibles en l'état (avec des spécificités différentes pour chaque langue. D'ailleurs parfois, j'utilisais plusieurs langues pour faire comprendre ce que je voulais).
Les cas les plus compliqués c'était lorsque, dans mon texte français, j'utilisais une expression qui n'était pas idiomatique. Quelque chose qui "ne se dit/écrit pas", mais qui, dans le contexte, apporte une certaine poésie, un second degré. La traduction automatique était soit du mot à mot, soit "corrigée". J'ai vraiment dû me retrousser les manches (et c'était très plaisant) pour retrouver les mêmes sensations que je voulais, à la base, provoquer chez le public francophone. Les LLMs me rétorquaient que ça n'était pas idiomatique dans la langue traduite, me proposant des sens qui n'étaient pas du tout les mêmes, ne comprenant pas la finesse de la réflexion, l'humour, le cynisme...
L'audition complète du trio Laurent Alexandre, Luc Ferry et Olivier Babeau
>>> https://www.youtube.com/watch?v=t_z9p9O90xE
Source de la vidéo complète : https://www.youtube.com/watch?v=lXUZvyajciY
Transcript/Traduction (générée via LLM)
Interviewer : Tu as tweeté que les modèles de code t’avaient finalement très peu aidé pour assembler ce dépôt. Pourquoi ?
Andrej Karpathy : J’ai construit ce dépôt sur un peu plus d’un mois. Je dirais qu’il y a aujourd’hui trois grandes façons d’interagir avec le code.
La première, c’est celle des gens qui rejettent complètement les LLM et qui écrivent tout à la main. Ce n’est probablement plus la bonne approche.
La deuxième, qui est plutôt la mienne, consiste à continuer à écrire beaucoup de choses soi-même, mais en utilisant l’autocomplétion fournie par ces modèles. Tu commences à écrire un morceau de code, le modèle complète, tu valides, tu avances. La plupart du temps, c’est correct ; parfois ça ne l’est pas, et tu corriges. Mais tu restes vraiment l’architecte de ce que tu écris.
Et puis il y a le vibe coding : tu dis “implémente-moi ceci ou cela”, tu appuies sur Entrée, et tu laisses le modèle faire. Là, on est plutôt du côté des agents.
Je pense que les agents fonctionnent dans certains contextes très précis, et je les utilise dans ces cas-là. Mais ce sont des outils : il faut apprendre ce qu’ils savent faire, ce qu’ils ne savent pas faire, et à quel moment les utiliser.
Par exemple, ils sont très bons pour le boilerplate, le code répétitif, les choses un peu copier-coller. Ils sont aussi très bons pour tout ce qui existe déjà en grande quantité sur Internet, parce qu’il y a énormément d’exemples dans leurs données d’entraînement.
Mais nanochat n’est pas vraiment dans cette catégorie. C’est un dépôt assez particulier. Il n’y a pas beaucoup de code écrit de cette manière-là, avec cette structure. Ce n’est pas du boilerplate. C’est presque du code intellectuellement dense, où chaque chose doit être placée très précisément.
Et les modèles ont encore beaucoup de déficits cognitifs. Par exemple, ils comprenaient souvent mal le code parce qu’ils avaient trop en tête les manières habituelles de faire les choses sur Internet, alors que moi je ne les suivais pas.
Ils pensaient que j’écrivais du code “normal”, alors que ce n’était pas le cas.
Interviewer : Tu as un exemple ?
Andrej Karpathy : Oui. Imagine huit GPU qui font tous un forward/backward. La manière habituelle de synchroniser les gradients entre eux, c’est d’utiliser le conteneur Distributed Data Parallel de PyTorch. Pendant le backward, il lance automatiquement les communications et synchronise les gradients.
Mais moi, je n’ai pas utilisé DDP, parce que je ne voulais pas l’utiliser. Ce n’était pas nécessaire. Je l’ai supprimé et j’ai écrit ma propre routine de synchronisation, directement dans l’étape de l’optimiseur.
Les modèles essayaient sans cesse de me faire revenir au conteneur DDP. Ils étaient très inquiets. Là, ça devient très technique, mais je n’utilisais pas ce conteneur parce que je n’en avais pas besoin : j’avais ma propre implémentation de quelque chose d’équivalent.
Interviewer : Ils n’arrivaient pas à intégrer le fait que tu avais ta propre version.
Andrej Karpathy : Exactement. Ils n’arrivaient pas à dépasser ça. Ils essayaient de modifier le style, ils étaient beaucoup trop défensifs, ils ajoutaient des try/catch partout. Ils essayaient constamment de transformer ça en base de code de production, alors que mon code repose sur un certain nombre d’hypothèses, et c’est très bien comme ça. Je n’ai pas besoin de toute cette couche supplémentaire.
Donc ils gonflaient la base de code, ils ajoutaient de la complexité, ils comprenaient de travers, ils utilisaient parfois des API dépréciées. Bref, c’était un bazar. Je pouvais passer derrière et nettoyer, mais au final ça ne m’apportait pas vraiment de gain.
Et puis je trouve aussi pénible de devoir taper en anglais ce que je veux. Ça demande trop de frappe. Si je vais directement à l’endroit du code où je sais que quelque chose doit apparaître, que je place le curseur là, et que je commence à taper les premières lettres, l’autocomplétion comprend et me propose le code. C’est une manière beaucoup plus dense en information de spécifier ce que je veux : tu pointes l’endroit exact dans le code, tu tapes les premiers morceaux, et le modèle complète.
Donc ce que je veux dire, c’est que ces modèles sont utiles à certains endroits précis de la pile.
Il y a deux exemples qui illustrent bien quand je les utilise. Le premier, c’est quand j’ai généré le rapport. C’était plutôt du boilerplate, donc j’ai fait une partie de ça en vibe coding. Ce n’était pas critique, et ça fonctionnait correctement.
Le deuxième cas, c’est quand je réécrivais le tokenizer en Rust. Je ne suis pas très bon en Rust, je débute plutôt dans ce langage. Donc il y avait une part de vibe coding dans l’écriture de ce code Rust. Mais j’avais déjà une implémentation Python que je comprenais complètement. Je voulais simplement en faire une version plus efficace, et j’avais des tests, donc je me sentais plus en sécurité.
Dans ce genre de cas, les modèles rendent certains langages ou paradigmes plus accessibles, même quand on ne les maîtrise pas parfaitement. Et là, ils sont très utiles. Il y a énormément de code Rust sur Internet, les modèles sont plutôt bons dessus, et comme je ne connais pas très bien Rust, ils m’aident beaucoup.
C'est pas la première fois que je tombe sur des how to de A à Z, mais je ne prends jamais le temps de partager. C'est tombé sur lui, ça aurait pu être un autre.
Des salariés d’Amazon utilisent un outil maison équivalent à OpenClaw pour brûler des tokens et générer artificiellement de l’activité IA pour éviter de mauvaises évaluations. Ce phénomène du « tokenmaxxing » n’est pas propre à Amazon.
Alors déjà la source l'étude pose la question : "Does Overwork Make Agents Marxist? Preference Drift and the Political Economy of AI Agents", qui n'est pas encore un article académique peer-reviewed publié dans une revue. Dans un décor d’exploitation, ils parlent exploitation. Dans un décor corporate, ils parleront optimisation, KPI, feedback, accountability, performance durable et autres.
Article source > https://aleximas.substack.com/p/does-overwork-make-agents-marxist
L’idée est de faire écrire à un LLM des programmes Python capables de construire des objets avec des parties, de la géométrie et des articulations, plutôt que de générer directement un mesh 3D. Le projet est accompagné d’un papier scientifique, d’un dépôt GitHub public et d’un dataset de plus de 10 000 objets articulés.