Possessed : votre vérificateur de liens est au vert, et huit de ces liens ouvrent maintenant un casino

Un vérificateur de liens pose une seule question

design-resources-for-developers est une liste de liens qui compte 67 000 étoiles. Elle a un vérificateur de liens, et il passe. Ouvrez la section React UI Libraries, cliquez sur Chakra Templates, et vous tombez sur une page en indonésien sur les machines à sous qui paient. Le domaine a expiré, quelqu'un l'a acheté, et le serveur répond 200, la seule question que pose un vérificateur de liens. Huit entrées de cette liste ouvrent aujourd'hui des sites de jeux d'argent. Vingt-deux autres ouvrent une page de domaine à vendre, un moulin à dissertations, un atelier d'esthétique automobile ou une autre entreprise sans rapport avec les mots à côté du lien. Aucun n'échoue au vérificateur.

Gemma lit la page, puis l'archive

Possessed passe après votre vérificateur de liens. Pour chaque lien approuvé, Gemma 4 ouvre ce que le lien affiche aujourd'hui et la capture de l'Internet Archive du jour où le lien a été ajouté (git log -S trouve ce commit), lit les deux à côté de la phrase qui cite le lien, et rend l'un de quatre verdicts : correct, déménagé, possédé, mort. Gemma choisit ses propres preuves. Il a fetch_live, find_snapshot, list_snapshots et read_snapshot, et quatre outils de verdict. Un lien possédé lui prend habituellement trois ou quatre étapes : ouvrir la page en ligne, trouver la capture la plus proche du jour d'ajout, la lire, décider. Quand la capture la plus proche est déjà la page parquée, il liste les captures et remonte plus loin. Le lien Chakra Templates a pris quatre appels d'outils et 9,5 secondes sur le GPU de mon portable.

Rien dans la demande de tirage n'est deviné

Un verdict qui propose un remplacement est refusé par le code si ce remplacement n'est pas une page que Gemma a ouverte pendant la session : une capture d'archive qu'il a lue, ou une URL en ligne qu'un vérificateur de liens passerait. Le refus retourne au modèle comme une erreur d'outil qui dit quoi faire à la place. La barrière a commencé comme une consigne, « n'invente jamais d'URL », et est devenue vingt lignes dans tools.py, parce qu'une règle qui a un test objectif a sa place dans le code. Sur 597 jugements dans cinq listes, elle s'est déclenchée 18 fois, et les 18 étaient mes bogues plutôt que ceux de Gemma : sept venaient d'une barre oblique finale que j'avais stockée autrement que le modèle réécrivait l'URL, onze de captures rendues en JavaScript que ma règle prenait pour des pages vides. Pas une seule fois Gemma n'a proposé une URL qu'il n'avait pas ouverte. J'ai corrigé les deux bogues, gardé la barrière et les traces, et rejugé la grande liste avec la barrière corrigée : zéro refus.

Deux demandes de tirage que vous pouvez ouvrir

L'Action en a écrit une toute seule, sur un fork de design-resources-for-developers, à partir d'un exécuteur GitHub hébergé sans GPU : sept liens, dont six sites de jeux d'argent, chacun redirigé vers la capture d'archive du mois de son ajout. Sur le processeur, Gemma lit un lien en deux à trois minutes, alors l'exécution a pris 30 minutes au total sur une liste de 1 245 liens, dont dix-huit où Gemma lisait huit liens, et l'Action a un paramètre limit qui prend d'abord les signaux les plus forts. L'autre est allée à un responsable, sur vuejs/awesome-vue : six entrées, dont une listée en 2018 comme une PWA d'échange de jeux vidéo usagés qui ouvre aujourd'hui un guide coréen des sites de baccara. Les six ont survécu au nettoyage des liens morts de la liste en janvier, parce qu'elles répondent encore 200. Pour celle-là, j'ai utilisé le mode confirmé, qui n'applique que les corrections sur lesquelles les deux modèles s'entendent.

Ce que chaque modèle a ajouté

Quatre détecteurs ont reçu la même question sur les mêmes 188 liens de design-resources : ce lien a-t-il besoin d'une correction? Un vérificateur de codes d'état n'en signale aucun, par construction. Les heuristiques d'URL (un autre domaine, une page d'accueil, des mots de parking) en ont signalé 61 et avaient raison pour 29, une précision de 0,47. La similarité EmbeddingGemma seule en a signalé 30 et avait raison pour 22, 0,73. Gemma 4 qui lit la page en a signalé 67 et avait raison pour 49, 0,73, et sur le seul verdict possédé, il avait raison pour 30 sur 37, là où les heuristiques avaient raison pour 19 sur 61. C'est aussi EmbeddingGemma qui rend la lecture abordable : sur design-resources, il a ramené 1 114 liens approuvés à 200 lectures.

Puis je l'ai pointé sur DEV

J'ai pris les 1 000 billets les plus aimés de DEV et extrait leurs 13 788 liens uniques; un vérificateur de codes d'état en passe 11 119 comme pages lisibles. Le triage a retenu 2 951 candidats, plus 150 témoins au hasard parmi les liens qu'il n'avait pas signalés, et Gemma 4 a jugé les 3 101 pendant la nuit sur mon portable. 145 des 150 témoins étaient corrects, alors le triage ne cache pas grand-chose. Qwen a rejugé chaque lien signalé, à l'aveugle. Là où les deux modèles s'entendent indépendamment et où les vérifications manuelles le confirment, 183 liens dans 96 billets, totalisant 95 627 réactions, ouvrent maintenant autre chose que ce que l'auteur citait. Une collection de ressources React à 3 438 réactions pointe vers js.coach, aujourd'hui un répertoire suédois de casinos. Une liste de livres de programmation à 3 135 réactions sert maintenant une page de loterie indonésienne.

Ce qui n'est pas revendiqué

Les chiffres de précision sont mesurés contre des étiquettes qui viennent des cas où Gemma et Qwen s'entendent, plus des vérifications manuelles quand ils ne s'entendent pas, et c'est Claude Code qui a écrit le premier jet de ces étiquettes manuelles (les fichiers d'étiquettes le disent), donc l'examen est en partie autocorrigé. Un lien que les deux modèles ont raté n'est pas dans l'ensemble, alors le rappel ne peut pas être mesuré ainsi, et je ne le revendique pas. L'accord n'est pas non plus la vérité : en vérifiant les premières lignes de DEV avec de nouvelles requêtes, j'ai trouvé les deux modèles dans l'erreur ensemble sur sept liens d'un même blogue dont les articles se chargent encore derrière une redirection de ressources, et ces lignes sont corrigées à la main; les 399 liens que Gemma a signalés sans confirmation de Qwen ne sont pas comptés du tout. Gemma fait des erreurs connues : un profil GitHub crédité comme auteur d'un projet lui paraît possédé, et une bannière promotionnelle a été lue comme une prise de contrôle. L'Action seule applique les verdicts de Gemma, c'est pourquoi chaque ligne porte ses preuves, et c'est le mode confirmé que j'ai utilisé pour la liste d'un responsable. Les pages derrière un mur anti-robots et les coquilles JavaScript vides ne peuvent pas être lues sans navigateur (42 des 1 114 sur design-resources), et Possessed les compte au lieu de les juger. Il ne peut pas vous dire qu'une page est bonne, seulement qu'elle correspond encore à ce que l'archive a vu quand vous l'avez liée. Aucune des deux demandes de tirage n'a été fusionnée, et design-resources-for-developers a suspendu les contributions externes, alors ses corrections vivent sur un fork.