- En créant hn.unlurker.com, l’auteur a ajouté une fonction
scan au client API HN qu’il écrivait pour récupérer tous les items dans l’ordre, puis a téléchargé l’ensemble des données de Hacker News en local
- Pendant l’exécution de
hn scan --no-cache --asc -c- -o full.json, le téléchargement s’est interrompu plusieurs fois, mais grâce au scan reprenable, il a obtenu quelques heures plus tard un fichier JSON de 20 GiB
- Après avoir transformé le JSON en table avec
read_json_auto de DuckDB, il a agrégé la part des mentions de Python, JavaScript, Java, Ruby et Rust avec text ILIKE et une moyenne mobile sur 12 semaines en SQL
- Avec un simple
grep, il a aussi vérifié que l’expression “correct horse battery staple” apparaissait 231 fois sur Hacker News, et DuckDB semble bien adapté à ce type d’analyse ponctuelle à cette échelle
- Une fois toutes les données disponibles en local, il devient possible d’analyser l’historique de Hacker News de nombreuses façons, mais ce projet s’arrête ici et la suite est laissée à d’autres
Télécharger tous les items de Hacker News
- Pour créer hn.unlurker.com, l’auteur a développé un client API HN
- Il existait déjà plusieurs clients, mais il voulait profiter de ce nouveau projet pour tester les fonctionnalités récentes de Go et des linters
- Dans l’API HN, les commentaires et les stories sont appelés des items
- Le client peut récupérer les items actifs, les listes d’items, etc.
- En pratique, le projet n’avait besoin que des items récents, mais l’auteur a ajouté la fonction
scan pour aller au bout de l’idée
scan télécharge les items dans l’ordre, de 0 jusqu’au plus récent, ou dans le sens inverse
- Le téléchargement complet était estimé non pas à des dizaines de milliers de GiB, mais à quelques dizaines de GiB de JSON, ce qui l’a motivé à essayer
hn scan --no-cache --asc -c- -o full.json
- Le téléchargement s’est arrêté plusieurs fois et il l’a interrompu avec
CTRL-C, mais comme scan est reprenable, l’opération s’est terminée après quelques heures
- Le résultat est un fichier JSON de 20 GiB contenant tout ce qui a été publié sur Hacker News
- En relançant la même commande, on peut le mettre à jour avec les données les plus récentes
Analyser les données locales avec DuckDB
- Au départ, l’auteur a simplement fait des recherches avec
grep
- L’expression “correct horse battery staple” apparaît 231 fois sur Hacker News
- La dernière occurrence au moment de la rédaction était un item publié « aujourd’hui »
- Il est ensuite passé à DuckDB pour l’analyse
- DuckDB est un moteur d’exécution analytique rapide et embarquable, également disponible comme outil en ligne de commande
- Sa nouvelle interface le rend facile à prendre en main, même pour les débutants, et un LLM a aidé à écrire les requêtes SQL
- Les données JSON ont été importées dans DuckDB de cette façon
CREATE TABLE items AS
SELECT *
FROM read_json_auto('/home/jason/full.json', format='nd', sample_size=-1);
- La requête d’exemple regroupe les items par semaine et calcule la proportion d’items contenant certains mots parmi l’ensemble des items
python, javascript, java, ruby, rust sont recherchés avec text ILIKE
- Une moyenne mobile sur 12 semaines est calculée pour chaque proportion
- La même méthode a aussi servi à visualiser des termes liés aux bases de données
- Le graphique d’exemple inclut la proportion moyenne mobile sur 12 semaines des mentions de
mysql, postgres, mongo, redis, sqlite
- DuckDB semble très bien adapté à l’analyse d’un jeu de données de cette taille
- Même si l’auteur dispose désormais d’une copie locale complète du contenu de Hacker News, il a décidé d’arrêter le projet ici
1 commentaires
Avis sur Hacker News
Je connais deux bases de données avec des tables Hacker News mises à jour, qui permettent de lancer des analyses sans avoir à tout télécharger au préalable
BigQuery nécessite un compte Google Cloud, et les requêtes sont probablement possibles dans l’offre gratuite ; il suffit d’utiliser
bigquery-public-data.hacker_news.fullClickHouse ne nécessite pas d’inscription et permet d’exécuter des requêtes directement dans le navigateur : https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
clickhousede ce commentaire : https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...Avant de connaître la base de données HN de ClickHouse, j’avais déjà tenté moi-même de télécharger tout le JSON
Il y a quelque temps, j’ai fait quelque chose de similaire avec le compte Twitter/Bluesky @fesshole. J’ai téléchargé toute l’archive et fine-tuné un modèle pour lui faire produire des confessions encore plus barrées
J’en étais assez fier, jusqu’à ce que je réalise qu’au fond, je n’avais fait qu’apprendre la masturbation et le divorce à une machine innocente
Ça m’a rappelé ces scènes de films de SF où des extraterrestres ou une IA surintelligente parcourent l’histoire de l’humanité à toute vitesse et décident que nous ne valons pas la peine d’être sauvés
S’il n’existe absolument aucun lien avec le monde extérieur pour ces données, comment une personne ou un modèle pourrait-il savoir que cette clé USB contient des données sur la masturbation et le divorce ?
Je considère les deux comme globalement positifs, et je suis reconnaissant de vivre dans une société où ces choses sont normalisées
Une requête sur Java inclut aussi tous les cas de JavaScript, donc Java est suréchantillonné
trust,antitrustoufrustrationLe fait qu’il y ait eu un fichier JSON de 20 Gio contenant tout ce qui s’est passé sur Hacker News est étonnamment volumineux, quand on pense que c’est un site uniquement textuel
Cela veut dire que, pendant les 18 ans d’existence de HN, les gens ont publié plus de 20 milliards d’octets de texte ? Cela ferait en moyenne plus de 2 Mo par jour, soit environ 7,5 Ko par seconde
En plus, une bonne partie de ce volume n’est sans doute pas produite par des humains.
/newestest rempli de spam de botsComme cela inclut aussi les métadonnées et la syntaxe du JSON, la quantité réelle de texte doit être encore plus faible. Le calcul « plus de 2 Mo par jour » était correct
[0] En fait, c’est ChatGPT qui a fait le calcul, mais il a l’air juste : https://chatgpt.com/share/68124afc-c914-800b-8647-74e7dc4f21...
Une grande partie est sans intérêt, mais les premières données, surtout avant 2018–2019 et l’arrivée de bots plus sophistiqués, méritent probablement qu’on s’y penche
Avant Facebook, HN aurait probablement été considéré comme un réseau social assez important, et sa taille raisonnable ainsi que sa modération active lui donnent aussi une valeur assez élevée
En 2019, lorsque Google+ a fermé, j’avais modélisé la quantité de données textuelles contribuéee sur ce site
Par données textuelles, j’entends l’exclusion des médias comme les images, l’audio et la vidéo, ainsi que des éléments de page annexes comme l’ossature HTML, le CSS et le JS
Compte tenu du très faible taux de participation et d’une moyenne d’environ 120 caractères par publication, sept ans d’activité de dizaines de millions de comptes actifs ne représentaient que quelques Gio. Il y avait plus de 4 milliards de profils enregistrés, mais l’activité réelle était bien moindre
Archive Team a travaillé avec Internet Archive, mais séparément, sur la préservation de Google+, avec des résultats mitigés. Beaucoup de contenu a été conservé, mais bien davantage a disparu ; il ne reste presque aucun commentaire, les fils ont été tronqués aux quelque 10 plus récents, et l’absence de recherche rend l’ensemble généralement peu utile. Les « vanity accounts », qui utilisaient un nom de compte choisi plutôt qu’un hash arbitraire, étaient encore moins accessibles
De plus, en scrapant les pages complètes pour tenter de reproduire leur apparence en ligne, on augmente fortement les besoins de stockage tout en passant à côté de beaucoup d’éléments qui rendaient réellement le site intéressant
Même lorsqu’il s’agit de stocker les contributions textuelles d’une grande population, les besoins de stockage restent assez modestes. Par exemple, avec 45 minutes en ligne par jour en moyenne, une vitesse de frappe de 45 wpm, et seulement la moitié du temps en ligne consacrée à écrire plutôt qu’à lire, cela fait environ 1 000 mots par personne et par jour, soit environ 6 Kio. 6 Mio pour 1 000 personnes, 6 Gio pour 1 million, et environ 6 Pio pour 1 milliard
Les valeurs réelles sont presque certainement plus basses. Le temps passé à écrire est surestimé et se rapproche probablement plutôt de 10 %, tandis que la vitesse de saisie sur mobile est vraisemblablement autour de 20 à 30 wpm. Par exemple, environ 2,45 milliards de « fragments de contenu » sont publiés chaque jour sur Facebook, dont la moitié sont des vidéos. En supposant 120 caractères par publication, les données textuelles représentent bien moins de 300 Gio par jour, une quantité étonnamment faible
La majeure partie de la collecte de données actuelle et des systèmes de capitalisme de surveillance concerne des données que les gens ne saisissent pas directement : localisation, vidéo, interactions en ligne, commerce, etc.
Quelle est la nétiquette quand on télécharge HN ? Faut-il d’abord demander à dang avant de mettre de la charge sur les serveurs ?
Ou peut-on considérer que des entreprises tech valant des milliards de dollars l’ont déjà fait plusieurs fois et que cela ne se remarquera même pas ?
https://console.cloud.google.com/marketplace/product/y-combi...
J’ai fait quelque chose de similaire. J’ai utilisé une astuce avec le dataset BigQuery ; pour une raison ou une autre, il continuait d’être mis à jour, puis j’ai exporté les données en Parquet, les ai téléchargées et les ai interrogées avec DuckDB
« Maintenant que tout le contenu de Hacker News a été téléchargé en local, on peut entraîner des centaines de bots basés sur des LLM pour en faire des contributeurs, et remplacer lentement, inévitablement, tout texte humain par la sortie d’un vibreur de chambre chinoise qui répercute et recycle éternellement le passé » : c’est une blague, mais j’ai peur que quelqu’un finisse un jour par essayer.
J’espère que cela n’arrivera pas, mais si c’est le cas, pourra-t-on l’empêcher ?
Il y a beaucoup de problèmes à résoudre, dont la confidentialité. Les relations n’ont pas besoin d’être révélées aux utilisateurs, mais dans une implémentation naïve elles resteraient visibles côté serveur.
On pourrait aussi ajouter des chemins de défiance avec des poids négatifs. Si je me méfie directement ou indirectement de quelqu’un, cela ferait baisser la valeur de la chaîne de confiance qui nous relie.
Comme il s’agit d’un réseau, le système pourrait s’ajuster face aux tentatives de manipulation, mais la question de sa robustesse reste ouverte.
Les commentaires longs et consistants se distinguent généralement, mais c’est devenu bien plus difficile qu’il y a un ou deux ans. Pour de courts commentaires d’une ou deux phrases, je pense que les LLM sont désormais assez bons pour passer pour des humains.
À l’inverse, beaucoup de commentaires sur HN sont des intuitions assez singulières, en décalage avec la pensée populaire moyenne. Si un LLM essaie de les imiter, il ne fera que sortir des absurdités.
Si l’on ajoute à ces absurdités un filtre qui ne laisse passer que les réponses raisonnables et cohérentes, les réponses deviendront ennuyeuses et resteront proches du n’importe quoi.
Pour que les réponses soient exactes, précises et originales, il faudra utiliser autre chose qu’un LLM.
Les heuristiques de karma et de rythme du site sont rudimentaires comparées au machine learning sophistiqué, mais elles fonctionnent parce que la communauté est petite par rapport à Reddit ou Twitter, et parce que les modérateurs interviennent directement.
Pour qu’une horde de faux comptes LLM « remplace » le texte humain, il faudrait qu’elle publie en continu des choses que les gens trouvent réellement intéressantes. Sinon, elle serait limitée ou discrètement supprimée bien avant.
Même en gardant quelques comptes IA en vie, le coût marginal est élevé. Faire tourner de l’inférence 24 h/24 sur des dizaines de nouveaux threads n’est pas gratuit, et empêcher la sortie de glisser vers les habituelles saletés SEO est étonnamment difficile.
Le gain est en pratique nul. On ne peut pas monétiser le trafic de HN, et le karma est une monnaie lamentable pour un opérateur de bots.
Peut-on arrêter un acteur malveillant obstiné et doté de ressources ? Probablement, mais les contre-mesures seraient les mêmes qu’aujourd’hui : fortes limites de débit, plafonds plus stricts pour les nouveaux comptes, revue par des modérateurs humains, et peut-être un peu d’analyse de style.
Ce serait pénible pour les nouveaux utilisateurs légitimes, mais pas fatal. Au bout du compte, HN survit parce que les humains qui s’y trouvent veulent lire d’autres humains. Si les commentaires commencent à ressembler à des perroquets probabilistes, les lecteurs les ignoreront ou les signaleront, et les bots finiront par se parler entre eux.
Rédigé par GPT-3o.
« Dans Metal Gear Solid 2, le scénario ambitieux de Hideo Kojima a parfois été considéré comme le premier exemple de jeu vidéo postmoderne, et comme ayant anticipé des concepts tels que la politique de la post-vérité, les fake news, les chambres d’écho et les faits alternatifs. »
[0] https://en.wikipedia.org/wiki/Metal_Gear
[1] https://en.wikipedia.org/wiki/Dead_Internet_theory
Je pense que, dans les prochaines années, beaucoup d’API commenceront à proposer une option qui renvoie simplement un fichier DuckDB.
Si l’on va de toute façon charger le JSON dans une base de données, il n’y a aucune raison de ne pas recevoir directement une base de données en réponse.
J’aimerais qu’on évite les graphiques empilés. Je pense qu’il est presque impossible de ne pas biaiser l’impression du lecteur.
Il est très difficile d’estimer la hauteur d’un point de données précis au milieu du bruit, et cela suggère des dépendances qui n’existent probablement pas.
La prochaine fois, j’envisage d’empiler plusieurs graphiques en lignes, chacun ne contenant qu’une seule série par région.
Voir le travail de https://flowimmersive.com/.
[1]: https://atlas.web.cern.ch/Atlas/GROUPS/PHYSICS/PUBNOTES/ATL-...
J’en avais créé un auparavant, et https://github.com/ashish01/hn-data-dumps était assez amusant
Une fonctionnalité intéressante à implémenter serait de refléter le fait que, comme les éléments récents sont mis à jour plus souvent au fil du temps, un élément téléchargé récemment devient plus vite un cache périmé qu’un élément ancien
J’utilisais une fonction basée sur l’âge pour déterminer l’obsolescence. Au début, je considérais un élément comme périmé 1 à 2 minutes après sa création, puis je le rafraîchissais fréquemment pendant quelques jours, avant de réduire rapidement après la première semaine et de le traiter comme immuable au bout d’environ deux semaines
// DefaultStaleIf marks stale at 60 seconds after creation, then frequently for the first few days after an item is// created, then quickly tapers after the first week to never again mark stale items more than a few weeks old.const DefaultStaleIf = "(:now-refreshed)>" +"(60.0*(log2(max(0.0,((:now-Time)/60.0))+1.0)+pow(((:now-Time)/(24.0*60.0*60.0)),3)))"https://github.com/jasonthorsness/unlurker/blob/main/hn/core...