Les 3 articles les plus chauds de la veille du 17 août 2026. 🔥

🔥 Top 3

1. Paper claims RL for reasoning only changes 1-3% of tokens, and they replicate the gains without RL at ~1000x less compute

Le RL pour le raisonnement ne réécrirait que 1 à 3 % des tokens. Le reste du modèle reste intact. C’est la conclusion d’un papier qui va plus loin : les auteurs reproduisent les gains du RL sans RL, avec environ 1000 fois moins de calcul.

Le RL, l’apprentissage par renforcement, ne recopie pas des exemples : le modèle propose une réponse, reçoit une récompense ou une pénalité, et ajuste ses poids en conséquence. C’est la technique qui a débloqué le raisonnement des LLM récents, et elle coûte cher en calcul.

Concrètement, ils comparent un modèle fine-tuné par RL avec le modèle de départ. Les différences se concentrent sur une poignée de tokens, souvent dans les étapes de déduction. Le RL ne réapprend pas le langage, il ajuste quelques décisions.

La suite est plus intéressante. Au lieu de lancer un RL complet, ils prennent ces tokens modifiés comme cible d’un apprentissage supervisé classique. Résultat : des performances comparables, pour une fraction du budget. Si le chiffre tient, le fine-tuning RL devient un simple repérage de tokens à corriger, suivi d’un SFT ciblé.

Reste une question : ces 1 à 3 % dépendent-ils du modèle et du domaine ? Si la proportion varie, la méthode perd son avantage. Mais l’idée de mesurer ce que le RL change réellement, plutôt que de l’appliquer en aveugle, mérite qu’on y regarde de près.

🔗 www.reddit.com

2. Split the Labor: Separating Evidence Interpretation from Decision Aggregation

Un LLM qui doit conclure à partir de centaines de sources fait souvent une seule chose: tout concaténer dans le prompt. Erreur. Interpréter une source et combiner des interprétations n’exigent pas les mêmes opérations. La première demande du contexte et de la capacité. La seconde demande de l’arithmétique fixe et de la comparabilité. Elle doit aussi pouvoir ne rien renvoyer.

Les auteurs de l’article arXiv proposent de séparer les deux étapes. Ils définissent un tuple de preuve à quatre champs: (hypothèse, fiabilité, justification, provenance). Une fois ce tuple fixé, les deux moitiés du système sont déterminées.

La séparation révèle un défaut: le count-scale drift. Si vous seuillez une somme de poids non normalisés, vous faites un seuillage bayésien, mais le point de fonctionnement glisse avec le nombre de sources. Plus le lecteur est fiable, plus le glissement est fort. Quand les fiabilités varient, le vote majoritaire et le calcul a posteriori classent les cas différemment. Aucune des deux stratégies ne domine l’autre sur tous les régimes : le bon choix dépend de la distribution des fiabilités, et c’est précisément ce que le tuple de preuve permet d’auditer.

🔗 arXiv

3. Qwen 3.8 27b vs 3.6 27b - how good is with a Turtle library.

Un test posté sur r/LocalLLaMA compare Qwen 3.8 27B et Qwen 3.6 27B sur une tâche précise : générer du code avec la bibliothèque turtle. Le résultat surprend : la version la plus récente ne fait pas mieux, parfois elle fait pire.

Turtle, c’est le module Python qui dessine avec une tortue. Simple, visuel, facile à vérifier. Un bon banc d’essai pour mesurer la capacité d’un modèle à produire du code exécutable, pas seulement du texte qui ressemble à du code.

Les deux modèles tournent en local, en 27B de paramètres. L’ancien sort des scripts propres, la tortue trace des figures correctes. Le nouveau hésite, oublie des commandes, ou produit des boucles infinies. Sur un exemple aussi basique, la différence se voit à l’œil nu.

Ce n’est pas un cas isolé. Les benchmarks classiques ne disent pas tout. Une montée de version peut améliorer le raisonnement général et casser des compétences de niche. Pour ceux qui utilisent ces modèles pour de l’automatisation, la leçon est simple : testez sur vos propres cas d’usage avant de mettre à jour.

La question reste ouverte : quels autres modules simples vont régresser dans les prochaines versions ?

🔗 www.reddit.com

📦 Le reste de la veille