Un auteur de Habr entraîne une Random Forest sur 81 articles et découvre une fuite de données et du copier-coller par un LLM

Certains articles publiés sur Habr recueillent quelques milliers de vues, tandis que d’autres sont lus des centaines de milliers de fois. L’auteur d’un article consacré à la plateforme Kwork, qui avait atteint 30 000 vues, a décidé d’en rechercher les causes à l’aide de Python et de l’apprentissage automatique. Il en est ressorti une expérience modeste, mais instructive, où les erreurs sont plus intéressantes que les chiffres finaux.

Comment les données ont été collectées

L’entraînement nécessitait un échantillon contrasté : 80 articles d’autres auteurs issus du hub « Freelance » de Habr — pour moitié tirés du fil récent et pour moitié des meilleurs articles de tous les temps — auxquels s’ajoutait l’article de l’auteur. Soit 81 lignes au total. Pour chaque article, l’auteur a relevé la longueur du titre, le nombre de mots, d’images, de liens et de blocs de code, ainsi que le nombre de vues, converti d’une notation comme « 30K » en nombres entiers. Il a également conservé les 3 000 premiers caractères du texte afin de les faire évaluer par un modèle de langage.

L’annotation par LLM a ensuite commencé : caractère racoleur du titre, qualité de l’introduction, actualité du sujet et lisibilité, chacun sur une échelle de 1 à 10. Gemma, utilisé gratuitement via OpenRouter, a immédiatement renvoyé une erreur 429 en raison de la saturation du pool. L’auteur est alors passé à une instance locale de Qwen3 4B dans LM Studio sur un Mac mini M4.

Le modèle a traité les 81 articles, mais leur a tous attribué exactement les mêmes notes : 7, 6, 8 et 7. La raison était banale : l’auteur avait fourni précisément ces nombres dans le prompt comme exemple JSON. Le modèle de 4 milliards de paramètres n’analysait pas les textes, il recopiait le modèle de sortie.

La conclusion est simple : une annotation de ce type doit être contrôlée, par exemple en vérifiant le nombre de valeurs uniques dans chaque colonne. L’auteur a ajouté ce contrôle, puis remplacé les évaluations du modèle par des caractéristiques calculées à l’aide d’expressions régulières : présence d’une question, de chiffres ou de mots déclencheurs comme « argent » ou « client » dans le titre, ainsi que nombre d’images pour 1 000 mots.

Ce qu’a montré la Random Forest

Sur le logarithme du nombre de vues, le modèle a attribué les poids suivants. La longueur du titre représente 34,5 % de l’influence, le volume du texte 26,3 %, et les liens et images réunis 33,7 %. Les blocs de code ne comptent que pour 0,3 %, ce qui est logique pour un hub consacré au travail en freelance : les lecteurs y cherchent des situations professionnelles, pas des extraits de code.

La comparaison entre groupes donne le tableau suivant. Dans les 20 % d’articles les plus performants — seuil fixé à 148 000 vues —, le titre moyen compte 46,9 caractères, contre 61,9 pour les articles peu performants et 71 pour celui de l’auteur. Les meilleurs articles comptent environ 1 774 mots, contre 1 255 pour les articles peu performants et 766 pour celui de l’auteur. Les textes les plus performants contiennent en moyenne 4,2 images et 4,8 liens ; celui de l’auteur ne comportait qu’une image et aucun lien.

Fuite de données et test honnête

L’auteur a ensuite développé un prédicteur : un classificateur estime la probabilité d’atteindre 25 000 vues, tandis qu’un régresseur prédit le nombre de vues. Il a comparé l’article brut à une version « améliorée » dotée d’un titre plus court, et, contre toute attente, la version brute a gagné. Deux raisons l’expliquent.

Premièrement, son propre article, avec ses 30 000 vues, était resté dans l’échantillon d’entraînement, et les arbres sans limite de profondeur en avaient simplement mémorisé les paramètres. Il s’agit d’une fuite de données classique. Deuxièmement, le chiffre ajouté au titre était pénalisé : dans les articles peu performants, les chiffres apparaissent trois fois plus souvent que dans les meilleurs articles — 0,3 contre 0,1 — en raison des études de cas promotionnelles présentes dans le fil récent.

Après correction — retrait de l’article de l’ensemble train et limitation de la profondeur des arbres avec max_depth=4 —, les résultats sont devenus cohérents. La structure initiale a obtenu 26 % de probabilité de succès et une prévision de 14 795 vues. La version améliorée — titre de 46 caractères, 1 800 mots, 4 images et 5 liens — a atteint 41 % et 34 919 vues. Les 30 000 vues réellement obtenues par l’original représentent le double de la prévision : le modèle ne voit que « l’emballage », pas le sujet. Pour mesurer la dispersion, l’auteur a ajouté l’écart interquartile des prédictions produites par les 200 arbres.

Les enseignements à retenir

Il faut garder les limites à l’esprit : 81 observations provenant d’un seul hub, un biais d’échantillonnage — fil récent contre meilleurs articles de tous les temps — et aucune validation sur des données mises de côté. Les chiffres constituent donc davantage des repères que des lois. Deux enseignements sont néanmoins universels. Premier point : n’insérez pas dans le prompt un exemple de sortie complet contenant des valeurs réelles et validez systématiquement les réponses des petits modèles. Deuxième point : l’objet utilisé pour tester le modèle ne doit pas participer à son entraînement, et la profondeur des arbres doit être limitée.

Pour publier dans un hub similaire, les repères pratiques sont les suivants : un titre de 45–50 caractères, un texte de 1 500–1 800 mots, au moins quatre illustrations et 4–5 liens. L’auteur a lui-même rédigé un nouvel article respectant ces paramètres et promet de comparer le nombre réel de vues à l’intervalle prévu par le modèle.