Construire une toile de confiance pour lutter contre le spam des LLM

• Tangled prend en charge nativement une fonctionnalité de vouching permettant aux utilisateurs d’appuyer ou de dénoncer d’autres utilisateurs avec lesquels ils ont interagi, comme signal de confiance pour répondre à la hausse des soumissions basées sur des LLM
• Les utilisateurs appuyés affichent une icône de bouclier vert à côté de leur photo de profil, tandis que les utilisateurs dénoncés affichent une icône de bouclier rouge, ce qui sert d’indice pour décider s’il faut interagir avec eux
• À mesure que les outils basés sur les LLM abaissent la barrière pour soumettre du code à un projet, les soumissions de type « vallée dérangeante », apparemment correctes mais subtilement erronées, peuvent se multiplier ; les mainteneurs peuvent alors appuyer ou dénoncer les contributeurs qui abusent de ces outils et alourdissent la charge de maintenance
• Les appuis et dénonciations incluent un champ de justification textuel et sont soumis à une atténuation, de sorte que les utilisateurs ne voient que les jugements émis par eux-mêmes et par leur cercle
• Lorsqu’on appuie ou dénonce quelqu’un dans Tangled, un enregistrement public est créé sur le PDS de l’utilisateur ; l’appview l’agrège ensuite pour afficher un « chapeau » d’appui au-dessus des profils dans les issues, commentaires, pull requests et commentaires de pull requests

---

Signaux de confiance de Tangled

• Tangled prend en charge nativement la fonctionnalité de vouching, qui permet aux utilisateurs d’appuyer ou de dénoncer d’autres utilisateurs avec lesquels ils ont interagi
• Les utilisateurs appuyés affichent une icône de bouclier vert à côté de leur photo de profil, et les utilisateurs dénoncés une icône de bouclier rouge
• Les utilisateurs peuvent aussi voir les jugements d’appui ou de dénonciation émis par leur cercle et s’en servir comme signal pour décider s’ils veulent interagir
• À mesure que les outils basés sur les LLM abaissent la barrière pour soumettre du code à un projet, les soumissions de type « vallée dérangeante », apparemment correctes mais subtilement erronées, peuvent se multiplier
• Les mainteneurs du réseau Tangled peuvent appuyer ou dénoncer les contributeurs qui abusent de ces outils et augmentent la charge de maintenance

Fonctionnement et contraintes de conception

• Conception prudente

  • Les appuis et dénonciations incluent un champ de justification textuel
  • Une atténuation est appliquée, de sorte que les utilisateurs ne voient que les jugements émis par eux-mêmes et par leur cercle
  • Actuellement, les utilisateurs dénoncés ne sont pas bloqués dans un projet ; seule une étiquette d’avertissement rouge apparaît dans certaines parties de l’interface

• Fonctionnalités prévues

  • Comme les mainteneurs et les contributeurs peuvent quitter un projet avec le temps, les appuis s’affaiblissent progressivement et doivent être renouvelés de temps à autre
  • Une fonctionnalité de suivi des preuves pourrait être ajoutée : si un utilisateur est appuyé juste après la fusion d’une PR, cette PR serait ajoutée comme preuve dans l’enregistrement d’appui

• Enregistrements publics et emplacement d’affichage

  • Lorsqu’on appuie ou dénonce quelqu’un dans Tangled, un enregistrement public est créé sur le PDS de l’utilisateur
  • Cet enregistrement contient l’information indiquant s’il s’agit d’un appui ou d’une dénonciation, ainsi qu’une justification facultative
  • L’appview de Tangled agrège les données d’appui de l’ensemble du réseau et affiche un « chapeau » d’appui au-dessus des profils aux points d’interaction
  • Les emplacements d’affichage sont les issues, les commentaires d’issues, les pull requests et les commentaires de pull requests

• Visibilité basée sur le cercle

  • Le chapeau n’est affiché au-dessus d’un utilisateur que si cet utilisateur a été directement appuyé ou dénoncé par vous, ou s’il a été appuyé ou dénoncé par une personne que vous avez vous-même appuyée
  • En cliquant sur le chapeau, on peut voir qui, dans son propre cercle, a appuyé ou dénoncé cet utilisateur
  • Pour l’instant, la seule conséquence d’une dénonciation est l’affichage du chapeau ; cela pourra évoluer plus tard, mais sert actuellement de signal d’aide à la décision

[GN⁺]

Avis sur Lobste.rs

• Une méthode meilleure et plus simple consiste à établir une politique fortement anti-LLM et à l'appliquer correctement. Il faut aussi quitter les plateformes qui encouragent l'usage des LLM ou sont pro-IA, comme GitHub
  Ce n'est pas efficace à 100 %, mais même quand quelqu'un essaie de cacher l'usage d'un LLM, cela finit généralement par se voir, et il suffit alors de bannir immédiatement. Si une entreprise pousse du spam LLM, il faut bloquer toute l'entreprise et, sur une forge auto-hébergée, bloquer le réseau de cette société au niveau du pare-feu
  Les systèmes bancals comme la preuve de travail pénalisent les nouveaux contributeurs et les contributeurs de passage, et le cautionnement de confiance revient lui aussi à une forme de preuve de travail. Mieux vaut ne pas harceler les plus faibles et frapper vite les mauvais acteurs, c'est plus efficace

  • L'objectif de Tangled semble plus proche de l'évitement du spam que de l'évitement des LLM eux-mêmes
    Même dans la citation, il est dit qu'on cautionne ou qu'on blâme les contributeurs qui détournent cet outil et créent une charge de maintenance
  • Cela exigerait une plateforme entièrement nouvelle, et l'effet ne semble pas devoir être énorme. Beaucoup de projets acceptent les soumissions faites avec des LLM, et beaucoup de développeurs acceptent de varier leur usage selon les projets
    Forcer les gens à accepter une interdiction au niveau de la plateforme sous prétexte que quelqu'un lance une chasse aux sorcières anti-LLM serait contre-productif. Ici comme sur HN, on voit parfois de faux soupçons affirmant qu'un texte a été écrit par un LLM ; si en plus il fallait gérer ça dans les PR, ce serait vraiment épuisant
  • L'objectif explicitement énoncé ici n'est pas le « LLM », mais le spam
    Ce système cherche à éviter les contributeurs qui détournent les outils et créent une charge de maintenance, et il pourrait aussi servir contre ceux qui créent une charge de maintenance de manière plus traditionnelle. Cela ressemble à un modèle de droits de commit plus évolué
  • Il ne s'agit pas tellement d'une politique précise qu'on aurait violée, mais plutôt d'une réponse à utiliser quand quelqu'un enfreint une politique
    S'il existe une politique anti-LLM, on peut l'appliquer avec ça ; s'il existe une politique contre le harcèlement, on peut l'appliquer avec ça aussi

• Si ce n'est pas directement lié au fait de pouvoir soumettre une PR, alors au mieux c'est inutile, et au pire cela risque de devenir un système de modération nocif. Quelqu'un va se mettre à blâmer en masse les utilisateurs qui ont déjà utilisé des LLM, puis cela pourra dériver vers des attaques groupées pour d'autres raisons
  Le web of trust en lui-même est élégant, mais ce projet ne traite que l'aspect technique et pas l'aspect social. Si l'on construit un système de modération sans grande section expliquant comment il peut passer à l'échelle sans abus et en intégrant cela dans les résultats du système, on va au-devant de surprises

  • Les cautions n'affichent que ce que j'ai moi-même fait ou ce qu'ont fait les comptes que j'ai cautionnés, donc le blâme de masse visant des inconnus est conçu pour rester invisible
  • Je m'inquiète que cela puisse arriver, mais en pratique il faudra sans doute attendre le premier grand cas d'annulation très médiatisé pour savoir réellement ce qu'il en est
  • Le fait d'introduire une notion d'atténuation va dans la bonne direction. Pour l'instant, cela ne contrôle pas directement la politique
    C'est une expérience assez intéressante, qui ajoute d'abord une motivation sociale pour traiter un problème social, et la conception semble intelligente

• Si « les utilisateurs blâmés ne subissent aucune conséquence. Ils ont juste un chapeau », alors à quoi cela sert-il au juste ? Au final, il faut toujours traiter les PR de la même manière

  • C'est un point de départ pour voir comment le système fonctionne, et il semble probable que des fonctions comme le blocage selon le niveau de confiance soient ajoutées plus tard
  • Cela pourrait être ajouté plus tard. Au départ, je veux tester ce qu'a dit @yorickpeterse, puis ensuite permettre aux utilisateurs de choisir quelle « réaction » ils veulent avoir vis-à-vis des utilisateurs blâmés
    Par exemple, on pourrait imaginer des options comme bloquer ou abaisser la priorité

• Y a-t-il un mécanisme pour empêcher quelqu'un de créer plusieurs domaines, puis un million d'utilisateurs sur chacun, afin qu'ils se cautionnent mutuellement ? Sinon, d'autres pourraient m'acheter des lots de réputation difficiles à distinguer du reste
  Le modèle d'arbre d'invitation de lobste.rs me semble préférable. Quand quelqu'un commence à abuser, il est facile de couper toute la sous-branche, et la croissance plus lente est plutôt un avantage

  • J'aime bien le modèle human.json : https://codeberg.org/robida/human.json en particulier la manière dont c'est visualisé dans l'extension. Elle cherche le chemin le plus court vers un site de confiance, colore la distance et montre aussi le chemin
    Dans human.json, personne ne cautionnerait sans doute les nœuds d'un tel réseau, ou alors ils auraient trop peu de liens entrants, donc une grande distance. Cela ne veut pas dire qu'on ne peut pas faire entrer ces sites dans le réseau, mais les cautions et la défiance peuvent rapidement les repousser. Il faut encore voir comment cela marcherait en pratique
  • L'étiquetage est propre à chaque utilisateur. Si je ne cautionne que des personnes qui, elles, ne vont pas cautionner des millions de comptes arbitraires, alors une activité de type attaque Sybil n'aura aucun effet sur mes cautions
    Ce serait bien d'avoir une couche d'interface façon petnames permettant de voir en ligne ou au survol « cautionné par X, Y, Z »
  • Un modèle qui noterait les différents degrés de cautionnement serait intéressant. En réutilisant l'arbre d'invitation façon lobste.rs, si 100 personnes cautionnent mais qu'elles partagent toutes le même ancêtre, alors que 5 personnes cautionnent via des chemins très différents, on pourrait compter davantage ces 5-là
    Je me demande dans quelle mesure cela permettrait d'empêcher la « culture de réputation »
  • Les bots ne pourraient guère faire plus que créer leur propre cercle de cautionnement. Le reste du réseau ne verrait pas les décisions de ce cercle tant qu'il ne commencerait pas à cautionner ces comptes de bots
    Au final, toutes les données sont publiques, donc quelqu'un pourrait créer tangled2.org et en faire un graphe global, mais dans l'interface, l'affaiblissement des cautions en dehors de son propre cercle est volontaire

• L'idée est bonne, mais pourquoi ne pas simplement communiquer naturellement ? Tout est trop bien rangé et trop cohérent, jusque dans les plus petits échanges
  Laisser quelques fautes de frappe dans ce qu'on écrit crée une empreinte plus humaine

• J'aime bien cette idée. Cela me rappelle le tree of trust utilisé par lobste.rs lui-même

  • Ou bien il y a aussi human.json. Sur mon site, je pense peut-être renommer cela en meat.json

• On a l'impression de recréer à toute vitesse les trust metric research menées presque au même moment que la naissance de l'open source. Je me demande ce que @raph en penserait

  • Ça fait plaisir de revoir un nom de cette époque. Le système de méta-modération à trois niveaux de Slashdot mérite aussi d'être salué
    Ce n'était pas parfait, mais c'était clairement bien mieux que de n'avoir absolument rien

• J'ai l'impression qu'il en existe déjà six du même genre ; pourquoi ne pas rejoindre l'un d'eux au lieu d'en créer encore un autre ?

  • https://xkcd.com/927/