Ein Web des Vertrauens aufbauen, um LLM-Spam zu bekämpfen

 (blog.tangled.org)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Tangled unterstützt standardmäßig die Funktion vouching, mit der Nutzer andere Nutzer, mit denen sie interagiert haben, befürworten oder missbilligen können, und nutzt dies als Vertrauenssignal, um auf die Zunahme von LLM-basierten Einreichungen zu reagieren
  • Bei befürworteten Nutzern wird neben dem Profilbild ein grünes Schildsymbol angezeigt, bei missbilligten Nutzern ein rotes Schildsymbol – ein Hinweis, um zu entscheiden, ob man mit ihnen interagieren möchte
  • Da LLM-basierte Tools die Hürde senken, Code in Projekte einzureichen, könnten äußerlich korrekt wirkende, aber subtil fehlerhafte „Uncanny-Valley“-artige Einreichungen zunehmen; Maintainer können Mitwirkende, die solche Tools missbrauchen und dadurch zusätzlichen Aufwand verursachen, befürworten oder missbilligen
  • Befürwortungen und Missbilligungen enthalten ein textbasiertes Begründungsfeld und unterliegen einer Abschwächung, sodass Nutzer nur die Bewertungen sehen, die sie selbst oder ihr eigener Kreis abgegeben haben
  • Wenn man in Tangled jemanden befürwortet oder missbilligt, wird im PDS des Nutzers ein öffentlicher Eintrag erstellt; die Appview aggregiert dies und zeigt über Profilen in Issues, Kommentaren und Pull Requests einen Befürwortungs-„Hut“ an

Vertrauenssignale in Tangled

  • Tangled unterstützt standardmäßig die Funktion vouching, mit der Nutzer andere Nutzer, mit denen sie interagiert haben, befürworten oder missbilligen können
  • Bei befürworteten Nutzern wird neben dem Profilbild ein grünes Schildsymbol angezeigt, bei missbilligten Nutzern ein rotes Schildsymbol
  • Nutzer können auch die Befürwortungen und Missbilligungen sehen, die ihr eigener Kreis abgegeben hat, und diese als Signal für die Entscheidung über Interaktionen nutzen
  • Da LLM-basierte Tools die Hürde senken, Code in Projekte einzureichen, könnten äußerlich korrekt wirkende, aber subtil fehlerhafte „Uncanny-Valley“-artige Einreichungen zunehmen
  • Maintainer im Tangled-Netzwerk können Mitwirkende, die solche Tools missbrauchen und dadurch Wartungsaufwand verursachen, befürworten oder missbilligen

Funktionsweise und Designbeschränkungen

  • Sorgfältiges Design

    • Befürwortungen und Missbilligungen enthalten ein textbasiertes Begründungsfeld
    • Es wird eine Abschwächung (attenuation) angewendet, sodass Nutzer nur die Bewertungen sehen, die sie selbst oder ihr eigener Kreis abgegeben haben
    • Derzeit werden missbilligte Nutzer nicht aus Projekten ausgeschlossen; in Teilen der UI wird lediglich ein rotes Warnlabel angezeigt

  • Geplante zusätzliche Funktionen

    • Da Maintainer und Mitwirkende Projekte im Laufe der Zeit verlassen können, sollen Befürwortungen mit der Zeit schwächer werden und gelegentlich erneuert werden müssen
    • Wenn ein Nutzer direkt nach dem Mergen eines PRs befürwortet wird, könnte eine Funktion zur Nachverfolgung von Belegen ergänzt werden, bei der der entsprechende PR als Nachweis zum Befürwortungseintrag hinzugefügt wird

  • Öffentliche Einträge und Anzeigeorte

    • Wenn man in Tangled jemanden befürwortet oder missbilligt, wird im PDS des Nutzers ein öffentlicher Eintrag erstellt
    • Dieser Eintrag enthält, ob es sich um eine Befürwortung oder Missbilligung handelt, sowie eine optionale Begründung
    • Die Tangled-Appview aggregiert Befürwortungsdaten aus dem gesamten Netzwerk und zeigt an den Interaktionspunkten über Profilen einen Befürwortungs-„Hut“ an
    • Anzeigeorte sind Issues, Issue-Kommentare, Pull Requests und Pull-Request-Kommentare

  • Sichtbarkeit auf Basis von Kreisen

    • Ein Hut wird über einem Nutzer nur dann angezeigt, wenn der Nutzer ihn direkt befürwortet oder missbilligt hat oder wenn eine von ihm befürwortete Person diesen Nutzer wiederum befürwortet oder missbilligt hat
    • Durch Klick auf den Hut lässt sich sehen, wer innerhalb des eigenen Kreises den betreffenden Nutzer befürwortet oder missbilligt hat
    • Derzeit ist die einzige Folge einer Missbilligung die Anzeige des Huts; das kann sich künftig ändern, im Moment dient es nur als Signal zur Unterstützung der eigenen Einschätzung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Lobste.rs-Kommentare

  • Der bessere und einfachere Weg ist, eine strikte Anti-LLM-Politik festzulegen und sie konsequent durchzusetzen. Man sollte sich auch von Plattformen fernhalten, die wie GitHub den Einsatz von LLMs fördern oder generell AI-freundlich sind
    Das ist nicht zu 100 % wirksam, aber wenn jemand den Einsatz von LLMs zu verbergen versucht, kommt das meist trotzdem ans Licht, und dann kann man sofort sperren. Wenn ein Unternehmen LLM-Spam forciert, sollte man das ganze Unternehmen blockieren; bei selbst gehosteten Forge-Instanzen kann man das Netzwerk der Firma an der Firewall sperren
    Halbgares wie Proof-of-Work benachteiligt Erstbeitragende und Gelegenheitsbeitragende, und Vertrauensbürgschaften sind letztlich auch nur eine Form von Proof-of-Work. Es ist wirksamer, nicht die Schwächeren zu schikanieren, sondern schlechte Akteure schnell hart zu treffen

    • Das Ziel von Tangled scheint weniger darin zu liegen, LLMs selbst zu vermeiden, sondern eher darin, Spam zu vermeiden
      Schon im Zitat geht es darum, Beitragende zu verbürgen oder zu tadeln, die dieses Tool missbrauchen und dadurch Wartungsaufwand erzeugen
    • Dafür bräuchte man eine komplett neue Plattform, und der Nutzen scheint mir trotzdem gering. Viele Projekte akzeptieren Einsendungen mit LLM-Unterstützung, und viele Entwickler haben kein Problem damit, je nach Projekt unterschiedlich damit umzugehen
      Wegen ein paar Leuten, die eine LLM-Hexenjagd betreiben, Plattformverbote in Kauf zu nehmen, wäre eher kontraproduktiv. Schon hier oder auf HN sieht man gelegentlich falsche Verdächtigungen, ein Text sei mit einem LLM geschrieben; wenn man sich damit auch noch bei PRs herumschlagen müsste, wäre das wirklich ermüdend
    • Das hier ausdrücklich genannte Ziel ist nicht „LLM“, sondern Spam zu vermeiden
      Das System soll Beitragende vermeiden helfen, die Tools missbrauchen und dadurch Wartungsaufwand erzeugen, und es ließe sich ebenso gegen Beitragende einsetzen, die auf herkömmliche Weise Wartungsaufwand verursachen. Es wirkt wie ein weiterentwickeltes Modell von Commit-Rechten
    • Es geht hier weniger um eine konkrete Politikverletzung, sondern eher um eine Antwort für den Fall, dass jemand eine Politik verletzt
      Mit einer Anti-LLM-Politik könnte man das damit durchsetzen, und mit einer Anti-Belästigungs-Politik ebenfalls

  • Wenn das nicht direkt mit dem Einreichen von PRs verknüpft ist, wirkt das bestenfalls nutzlos und schlimmstenfalls wie ein schädliches Moderationssystem. Irgendjemand wird Nutzer massenhaft tadeln, nur weil sie irgendwann einmal LLMs benutzt haben, und danach könnten gruppenweise Angriffe aus anderen Gründen beginnen
    Das Web of Trust an sich ist cool, aber dieses Projekt behandelt nur die technische Seite und nicht die soziale. Wenn man ein Moderationssystem baut, ohne einen großen Abschnitt dazu zu haben, wie es ohne Missbrauch skaliert werden soll, dann wird es böse Überraschungen geben

    • Bürgschaften zeigen nur Dinge an, die ich selbst getan habe oder die von Accounts stammen, für die ich gebürgt habe; massives Tadeln unbekannter Nutzer soll also gerade unsichtbar bleiben
    • Ich mache mir Sorgen, dass so etwas passieren könnte, aber sicher wissen wird man es wohl erst, wenn der erste prominente Cancel-Vorfall eintritt
    • Dass das Konzept der Abschwächung eingebaut ist, ist ein Schritt in die richtige Richtung. Im Moment steuert es die Richtlinie noch nicht direkt
      Als Experiment, das zuerst soziale Anreize ansetzt, um soziale Probleme zu lösen, ist es ziemlich interessant, und das Design wirkt clever

  • Wenn es heißt: „Getadelte Nutzer erfahren keinerlei Konsequenzen. Sie bekommen nur einen Hut“, was soll das dann überhaupt bringen? Die PR-Bearbeitung muss am Ende trotzdem genauso gemacht werden

    • Das ist ein Ausgangspunkt, um zu sehen, wie das System funktioniert; später dürften Funktionen wie Blockieren anhand von Vertrauensstufen hinzukommen
    • Das könnte später dazukommen. Anfangs möchte ich erst testen, was @yorickpeterse gesagt hat, und danach Nutzern die Wahl geben, wie sie auf getadelte Nutzer „reagieren“ möchten
      Zum Beispiel könnte man blockieren oder niedriger priorisieren

  • Gibt es irgendeinen Mechanismus, der verhindert, dass ich mehrere Domains anlege, auf jeder eine Million Nutzer erzeuge und sie sich gegenseitig verbürgen lasse? Dann könnten andere von mir gebündelte Reputation kaufen, die sich kaum auseinanderhalten lässt
    Ehrlich gesagt scheint mir das Einladungsbaum-Modell von lobste.rs besser. Wenn jemand Missbrauch beginnt, kann man den ganzen Unterbaum leicht abschneiden, und es wächst langsamer, was eher ein Vorteil ist

    • Mir gefällt das human.json-Modell: https://codeberg.org/robida/human.json Besonders gut finde ich, wie es in Erweiterungen visualisiert wird. Es sucht den kürzesten Pfad zu einer vertrauenswürdigen Seite, markiert die Distanz farblich und zeigt auch den Pfad an
      In human.json würde vermutlich niemand Knoten in so einem Netzwerk verbürgen, oder es gäbe zu wenige eingehende Verbindungen, sodass die Distanz groß ausfiele. Das heißt nicht, dass man solche Seiten nicht ins Netzwerk bringen könnte, aber Bürgschaften und Misstrauen könnten sie schnell wieder hinausdrängen. Wie das in der Praxis funktioniert, muss man erst noch sehen
    • Die Kennzeichnung ist nutzerspezifisch. Wenn ich nur für Personen bürge, die nicht ihrerseits Millionen zufälliger Accounts verbürgen, dann beeinflusst Sybil-angriffsartiges Verhalten meine Bürgschaften überhaupt nicht
      Ein petnames-ähnliches UI-Layer, in dem man inline oder per Mouseover sehen kann: „X, Y, Z bürgen dafür“, wäre schön
    • Ein Modell, das unterschiedliche Grade von Bürgschaften gewichtet, wäre interessant. Man könnte den lobste.rs-artigen Einladungsbaum nutzen und etwa den Fall, dass 100 Leute bürgen, aber alle denselben Vorfahren teilen, geringer zählen als 5 Bürgschaften aus sehr unterschiedlichen Pfaden
      Ich frage mich, wie gut so etwas „Reputation Farming“ verhindern könnte
    • Das Höchste, was möglich sein dürfte, ist, dass Bots ihren eigenen Bürgschaftszirkel bilden. Der Rest des Netzwerks kann die Entscheidungen dieses Zirkels nicht sehen, solange er nicht anfängt, diese Bot-Accounts zu verbürgen
      Da alle Daten letztlich öffentlich sind, könnte natürlich jemand tangled2.org bauen und einen globalen Graphen erzeugen, aber im UI ist bewusst vorgesehen, dass Bürgschaften außerhalb des eigenen Zirkels schwächer werden

  • Die Idee ist gut, aber vielleicht sollte man einfach natürlich kommunizieren. Selbst banale Kommunikation ist inzwischen zu ordentlich und zu konsistent
    Wenn man Tippfehler im Geschriebenen stehen lässt, entsteht ein echter menschlicher Fingerabdruck

  • Ich mag die Idee. Sie erinnert an den tree of trust, den lobste.rs selbst verwendet

    • Oder es gibt human.json. Auf meiner Seite überlege ich, es in meat.json umzubenennen

  • Es fühlt sich an, als würden wir die trust metric research, die fast zeitgleich mit der Entstehung von Open Source lief, gerade im Schnellverfahren nachstellen. Ich frage mich, wie @raph das sehen würde

    • Schön, einen Namen aus alten Zeiten wiederzusehen. Auch das dreifache Meta-Moderationssystem von Slashdot verdient Anerkennung
      Es war nicht perfekt, aber eindeutig viel besser als gar nichts

  • Es scheint davon schon ein halbes Dutzend zu geben; warum also noch eins bauen, statt bei einem bestehenden mitzumachen?