信頼のウェブを構築してLLMスパムに対抗する

 (blog.tangled.org)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • Tangled は、ユーザーがやり取りした他のユーザーを保証または非難できる vouching 機能を標準でサポートしており、LLM ベースの投稿増加に対応するための信頼シグナルとして活用している
  • 保証されたユーザーにはプロフィール画像の横に 緑色の盾アイコン、非難されたユーザーには 赤色の盾アイコン が表示され、やり取りするかどうかを判断する手がかりになる
  • LLM ベースのツールによってプロジェクトにコードを投稿するハードルが下がるにつれ、一見正しそうでも微妙に誤っている 「不気味の谷」的な投稿 が増える可能性があり、メンテナーはこうしたツールを誤用して負担を生むコントリビューターを保証または非難できる
  • 保証・非難にはテキストベースの 理由フィールド が含まれ、減衰が適用されるため、ユーザーは自分自身と自分のサークルが下した判断だけを見ることができる
  • Tangled で保証または非難すると、ユーザーの PDS に公開記録が作成され、appview がこれを集計して issue、コメント、プルリクエスト、プルリクエストコメントのプロフィール上に保証の「帽子」を表示する

Tangled の信頼シグナル

  • Tangled は、ユーザーがやり取りした他のユーザーを保証または非難できる vouching 機能を標準でサポートしている
  • 保証されたユーザーにはプロフィール画像の横に 緑色の盾アイコン が表示され、非難されたユーザーには 赤色の盾アイコン が表示される
  • ユーザーは自分のサークルが下した保証・非難の判断も見ることができ、やり取りするかどうかを判断するシグナルとして活用できる
  • LLM ベースのツールによってプロジェクトにコードを投稿するハードルが下がるにつれ、一見正しそうでも微妙に誤っている「不気味の谷」的な投稿が増える可能性がある
  • Tangled ネットワークのメンテナーは、こうしたツールを誤用して保守負担を生むコントリビューターを保証または非難できる

仕組みと設計上の制約

  • 慎重な設計

    • 保証・非難にはテキストベースの 理由フィールド が含まれる
    • 減衰（attenuation）が適用されるため、ユーザーは自分自身と自分のサークルが下した判断だけを見ることができる
    • 現時点で非難されたユーザーはプロジェクトからブロックされず、UI の一部に赤い警告ラベルが表示されるだけである

  • 予定されている追加機能

    • 時間の経過とともにメンテナーやコントリビューターがプロジェクトを離れることがあり得るため、保証は時間とともに弱まり、ときどき更新される必要がある
    • PR をマージした直後にユーザーを保証すると、その PR が保証記録の証拠として追加される 証拠追跡 機能が追加される可能性がある

  • 公開記録と表示場所

    • Tangled で誰かを保証または非難すると、ユーザーの PDS に 公開記録 が作成される
    • この記録には、保証か非難かと任意の理由が含まれる
    • Tangled appview はネットワーク全体の保証データを集計し、やり取りの接点にあるプロフィール上に保証の「帽子」を表示する
    • 表示場所は issue、issue コメント、プルリクエスト、プルリクエストコメントである

  • サークルベースの可視性

    • ユーザーが直接保証・非難した相手、またはユーザーが保証した人がさらに保証・非難した相手に対してのみ、そのユーザーの上に帽子が表示される
    • 帽子をクリックすると、自分のサークル内で誰がそのユーザーを保証または非難したのかを確認できる
    • 現時点で非難の結果は帽子表示のみであり、今後結果が変わる可能性はあるが、今は判断を助けるシグナルとして使われる

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Lobste.rsの意見

  • より良くて単純な方法は、強力な反LLMポリシーを作ってきちんと執行すること。GitHubのようにLLM利用を奨励したり、AI寄りなプラットフォームからも離れるべき
    100%効果的ではないが、LLM利用を隠そうとしてもたいていは露見するので、その時点ですぐに禁止すればよい。企業がLLMスパムを押し付けてくるなら企業全体をブロックし、自前ホスティングのforgeならファイアウォールでその会社のネットワークを遮断すればよい
    プルーフ・オブ・ワークのような中途半端な仕組みは、初めての貢献者や通りすがりの貢献者に不利益を与えるし、信頼保証も結局はプルーフ・オブ・ワーク。弱い立場の人をいじめるより、悪質な行為者を素早く叩くほうが効果的

    • Tangledの目標は、LLM自体を避けることよりスパム回避に近く見える
      引用文でも「このツールを悪用してメンテナンス負荷を生む貢献者」を保証したり非難したりすると書かれている
    • そうするには完全に新しいプラットフォームが必要で、効果も大きくなさそう。多くのプロジェクトはLLMによる提出を受け入れているし、多くの開発者はプロジェクトごとに利用可否を変えることを問題にしていない
      誰かがLLM魔女狩りをしているという理由で、プラットフォーム全体の禁止を受け入れさせるのは逆効果。ここやHNでも、文章がLLMで書かれたという誤った疑いを時々見かけるが、それをPRで処理しなければならないなら本当にうんざりする
    • ここで明示されている目標は「LLM」ではなくスパムを避けること
      このシステムは、ツールを悪用してメンテナンス負荷を生む貢献者を避けるためのもので、昔ながらの方法でメンテナンス負荷を生む貢献者にも使える。より発展したコミット権限モデルのように見える
    • これは、どの具体的なポリシーに違反したかではなく、誰かがポリシーに違反したときに使う対応に近い
      反LLMポリシーがあればこれで執行できるし、ハラスメント禁止ポリシーがあればそれもこれで執行できる

  • PR提出可否と直接結びつかないのなら、これは良く見ても役に立たず、悪くすると有害なモデレーションシステムになりそう。誰かがLLMを使ったことのあるユーザーを大量に非難するだろうし、その後は別の理由による集団攻撃も始まりかねない
    Web of Trust自体は素晴らしいが、このプロジェクトは技術面しか扱わず、社会面を扱っていない。モデレーションシステムを作るなら、「悪用なしにどうスケールさせるか」をシステムの帰結に落とし込んだ大きなセクションがなければ、驚くようなことが起きるはず

    • 保証は、自分が行ったもの、または自分が保証したアカウントが行ったものしか見えないので、知らないユーザーに対する大量非難は見えない設計になっている
    • そういうことが起きるのではと心配しているが、実際には最初の有名なキャンセル事件が起きるまで待たないとはっきり分からない気がする
    • 減衰の概念が入っているのは正しい方向への一歩。現時点ではポリシーを直接制御してもいない
      社会的問題を解決するために、まず社会的インセンティブを付けた実験としてかなり興味深く、設計も巧みだと思う

  • 「非難されたユーザーには何の結果もありません。帽子が付くだけです」なら、いったい何の意味があるのか？ 結局PR処理はそのまま必要になる

    • これはシステムがどう動くかを見るための出発点で、後で信頼レベルベースのブロックのような機能が追加されるのだと思う
    • 後で追加することはできる。最初は@yorickpeterseが言ったことを試してみたくて、その後はユーザーが非難されたユーザーに対してどんな「反応」を取るか選べるようにしたい
      たとえばブロックや優先度を下げるといった方法が考えられる

  • ドメインをいくつも作って、それぞれに100万人のユーザーを生成し、互いに保証し合うのを防ぐ仕組みはあるのか？ そうなれば他の人は見分けにくい評判バンドルを私から買えるようになる
    むしろlobste.rsの招待ツリーモデルのほうが良さそう。誰かが悪用を始めたらサブツリー全体を切り落としやすく、成長も遅いが、それがむしろ利点だ

    • human.jsonモデルが気に入っている: https://codeberg.org/robida/human.json とくに拡張機能で可視化されるやり方が良い。信頼するサイトへの最短経路を探し、距離を色で示し、経路も表示する
      human.jsonでは、おそらく誰もそうしたネットワークのノードを保証しないか、流入リンクが少なすぎて距離が大きく出るはず。ネットワークにサイトを入れられないという意味ではないが、保証と不信で素早く押し出せる。実際にどう機能するかはまだ見てみないと分からない
    • ラベリングはユーザーごと。私が何百万もの任意アカウントを保証しない人だけを保証するなら、Sybil攻撃的な活動は私の保証にはまったく影響しない
      「X、Y、Zが保証」とインラインやマウスオーバーで見られるpetnamesっぽいUIレイヤーがあるとよさそう
    • 保証の異なる度合いをスコア化するモデルがあれば面白そう。lobste.rs式の招待ツリーを活用して、100人が保証していても全員が同じ祖先を共有している場合と、5人が非常に異なる経路から保証している場合なら、後者の5件をより重く数えるといった感じ
      こういうやり方が「評判ファーミング」をどれだけ防げるのか気になる
    • ボット同士で自分たちだけの保証サークルを作る程度しかできないはず。残りのネットワークは、そのボットアカウントを保証し始めない限り、そのサークルの判断を見ることはない
      結局すべてのデータは公開なので、誰かがtangled2.orgを作ってグローバルグラフを作ることはできるかもしれないが、UIでは意図的に自分のサークルの外へ行くほど保証が弱まるようになっている

  • アイデアは良いが、ただ自然にやり取りすればいいのではとも思う。些細なコミュニケーションまで整理されすぎていて一貫しすぎている
    打ち込んだ文章にタイプミスを残しておけば、本物の人間らしい指紋になる

  • このアイデアは良い。lobste.rs自体が使っているtree of trustを思い出す

    • あるいはhuman.jsonもある。自分のサイトではmeat.jsonに名前を変えようかと考えている

  • オープンソース誕生とほぼ同じ時期に進められていたtrust metric researchを、私たちが急速に再現している感じがする。@raphがこれをどう見るのか気になる

    • 昔よく見た名前で懐かしい。Slashdotの三重メタモデレーションシステムも評価されるべき
      完璧ではなかったが、何もないよりは確実にはるかに良かった

  • こういうのはもう6つくらいある気がするのに、なぜ既存のものに加わらず、また1つ作るのか？