▲

신뢰의 웹을 구축해 LLM 스팸에 맞서기

 (blog.tangled.org)
1P by GN⁺ 1시간전 | ★ favorite | 댓글 1개
  • Tangled는 사용자가 상호작용한 다른 사용자를 보증하거나 비난할 수 있는 vouching 기능을 기본 지원하며, LLM 기반 제출물 증가에 대응하는 신뢰 신호로 활용함
  • 보증된 사용자는 프로필 사진 옆에 초록색 방패 아이콘, 비난된 사용자는 빨간색 방패 아이콘이 표시되어 상호작용 여부를 판단하는 단서가 됨
  • LLM 기반 도구로 프로젝트에 코드를 제출하는 장벽이 낮아지면서 겉보기에는 맞지만 미묘하게 잘못된 “불쾌한 골짜기”식 제출물이 늘어날 수 있고, 유지보수자는 이런 도구를 오용해 부담을 만드는 기여자를 보증하거나 비난할 수 있음
  • 보증·비난에는 텍스트 기반 사유 필드가 포함되고 감쇠가 적용되어, 사용자는 자신과 자신의 서클이 내린 판단만 볼 수 있음
  • Tangled에서 보증하거나 비난하면 사용자의 PDS 에 공개 기록이 생성되며, appview가 이를 집계해 이슈, 댓글, 풀 리퀘스트, 풀 리퀘스트 댓글의 프로필 위에 보증 “모자”를 표시함

Tangled의 신뢰 신호

  • Tangled는 사용자가 상호작용한 다른 사용자를 보증하거나 비난할 수 있는 vouching 기능을 기본 지원함
  • 보증된 사용자는 프로필 사진 옆에 초록색 방패 아이콘이 표시되고, 비난된 사용자는 빨간색 방패 아이콘이 표시됨
  • 사용자는 자신의 서클이 내린 보증·비난 판단도 볼 수 있으며, 이를 상호작용 여부를 판단하는 신호로 활용할 수 있음
  • LLM 기반 도구로 프로젝트에 코드를 제출하는 장벽이 낮아지면서, 겉보기에는 맞지만 미묘하게 잘못된 “불쾌한 골짜기”식 제출물이 늘어날 수 있음
  • Tangled 네트워크의 유지보수자는 이런 도구를 오용해 유지보수 부담을 만드는 기여자를 보증하거나 비난할 수 있음

동작 방식과 설계 제약

  • 신중한 설계

    • 보증·비난에는 텍스트 기반 사유 필드가 포함됨
    • 감쇠(attenuation)가 적용되어, 사용자는 자신과 자신의 서클이 내린 판단만 볼 수 있음
    • 현재 비난된 사용자는 프로젝트에서 차단되지 않으며, UI 일부에 빨간 경고 라벨만 표시됨

  • 예정된 추가 기능

    • 시간이 지나며 유지보수자와 기여자가 프로젝트를 떠날 수 있으므로, 보증은 시간이 지남에 따라 약해지고 때때로 갱신되어야 함
    • PR을 병합한 직후 사용자를 보증하면 해당 PR이 보증 기록의 증거로 추가되는 증거 추적 기능이 추가될 수 있음

  • 공개 기록과 표시 위치

    • Tangled에서 누군가를 보증하거나 비난하면 사용자의 PDS에 공개 기록이 생성됨
    • 이 기록에는 보증인지 비난인지와 선택적 사유가 포함됨
    • Tangled appview는 네트워크 전반의 보증 데이터를 집계하고, 상호작용 지점의 프로필 위에 보증 “모자”를 표시함
    • 표시 위치는 이슈, 이슈 댓글, 풀 리퀘스트, 풀 리퀘스트 댓글임

  • 서클 기반 가시성

    • 사용자가 직접 보증·비난한 대상이거나, 사용자가 보증한 사람이 다시 보증·비난한 대상일 때만 해당 사용자 위에 모자가 표시됨
    • 모자를 클릭하면 자신의 서클 안에서 누가 해당 사용자를 보증하거나 비난했는지 확인할 수 있음
    • 현재 비난의 결과는 모자 표시뿐이며, 향후 결과가 달라질 수 있지만 지금은 판단을 돕는 신호로 쓰임

함께 보면 좋은 글 β

▲
GN⁺ 1시간전  [-]
Lobste.rs 의견들

  • 더 낫고 단순한 방법은 강한 반 LLM 정책을 만들고 제대로 집행하는 것임. GitHub처럼 LLM 사용을 장려하거나 친 AI 성향인 플랫폼에서도 벗어나야 함
    100% 효과적이진 않지만, LLM 사용을 숨기려는 경우도 대개 드러나고 그때 바로 금지하면 됨. 기업이 LLM 스팸을 밀어붙이면 기업 전체를 차단하고, 자체 호스팅 포지라면 방화벽에서 그 회사 네트워크를 막으면 됨
    작업 증명 같은 어설픈 시스템은 처음 기여자와 지나가던 기여자에게 불이익을 주며, 신뢰 보증도 결국 작업 증명임. 약한 사람을 괴롭히지 말고 나쁜 행위자를 빠르게 때리는 쪽이 더 효과적임

    • Tangled의 목표는 LLM 자체를 피하는 것보다 스팸 회피에 가까워 보임
      인용문에서도 “이 도구를 오용해 유지보수 부담을 만드는 기여자”를 보증하거나 비난한다고 되어 있음
    • 그러려면 완전히 새 플랫폼이 필요하고, 효과도 크지 않을 것 같음. 많은 프로젝트는 LLM 제출을 받아들이고, 많은 개발자는 프로젝트별로 사용 여부를 바꾸는 데 괜찮아함
      누군가 LLM 마녀사냥을 벌인다는 이유로 플랫폼 차원의 금지를 감수하게 만드는 건 역효과임. 여기나 HN에서도 글이 LLM으로 쓰였다는 잘못된 의심이 가끔 보이는데, 그걸 PR에서 처리해야 한다면 정말 피곤해짐
    • 여기서 명시한 목표는 “LLM”이 아니라 스팸을 피하는 것임
      이 시스템은 도구를 오용해 유지보수 부담을 만드는 기여자를 피하려는 것이고, 예전 방식으로 유지보수 부담을 만드는 기여자에게도 쓸 수 있음. 더 발전된 커밋 권한 모델처럼 보임
    • 이건 어떤 구체적 정책을 어겼는지가 아니라, 누군가가 정책을 어겼을 때 쓰는 답에 가까움
      반 LLM 정책이 있으면 이걸로 집행할 수 있고, 괴롭힘 금지 정책이 있으면 그것도 이걸로 집행할 수 있음

  • PR 제출 여부와 직접 연결되지 않는다면, 이건 좋게 봐도 쓸모없고 나쁘게는 유해한 조정 시스템이 될 것 같음. 누군가는 LLM을 쓴 적 있는 사용자를 대량으로 비난할 것이고, 이후엔 다른 이유의 집단 공격도 시작될 수 있음
    웹 오브 트러스트 자체는 멋지지만, 이 프로젝트는 기술적 측면만 다루고 사회적 측면은 다루지 않음. 조정 시스템을 만들면서 “남용 없이 어떻게 확장할 것인가”를 시스템 결과에 녹여낸 큰 섹션이 없다면 놀랄 일이 생길 것임

    • 보증은 내가 한 것 또는 내가 보증한 계정이 한 것만 보이므로, 모르는 사용자를 향한 대량 비난은 보이지 않게 설계되어 있음
    • 그런 일이 생길까 봐 걱정되지만, 실제로는 첫 번째 유명한 취소 사건이 터질 때까지 기다려 봐야 확실히 알 수 있을 듯함
    • 감쇠 개념이 들어가 있는 건 올바른 방향의 한 걸음임. 지금은 정책을 직접 제어하지도 않음
      사회적 문제를 해결하기 위해 사회적 동기를 먼저 붙인 실험이라 꽤 흥미롭고 설계도 영리해 보임

  • “비난받은 사용자에게는 아무 결과도 없습니다. 모자만 생깁니다”라면, 대체 무슨 의미가 있나? 결국 PR 처리는 그대로 해야 함

    • 시스템이 어떻게 동작하는지 보기 위한 시작점이고, 나중에 신뢰 수준 기반 차단 같은 기능이 추가될 것으로 보임
    • 나중에 추가할 수도 있음. 처음에는 @yorickpeterse가 말한 것을 테스트해 보고 싶고, 이후에는 사용자가 비난받은 사용자에게 어떤 “반응”을 할지 선택하게 하고 싶음
      예를 들면 차단, 우선순위 낮추기 같은 방식이 가능함

  • 도메인을 여러 개 만들고 각각 백만 명의 사용자를 생성해 서로 보증하게 하는 걸 막는 장치가 있나? 그러면 다른 사람들은 분리하기 어려운 평판 묶음을 나한테서 살 수 있게 됨
    차라리 lobste.rs의 초대 트리 모델이 더 나아 보임. 누군가 남용을 시작하면 하위 트리 전체를 잘라내기 쉽고, 더 느리게 성장하는데 그게 오히려 장점임

    • human.json 모델이 마음에 듦: https://codeberg.org/robida/human.json 특히 확장에서 시각화되는 방식이 좋음. 신뢰하는 사이트와의 최단 경로를 찾고, 거리를 색으로 표시하며 경로도 보여줌
      human.json에서는 아마 아무도 그런 네트워크의 노드를 보증하지 않거나, 들어오는 연결이 너무 적어서 거리가 크게 나올 것임. 네트워크에 사이트를 넣을 수 없다는 뜻은 아니지만, 보증과 불신이 빠르게 밀어낼 수 있음. 실제로 어떻게 작동할지는 아직 봐야 함
    • 라벨링은 사용자별임. 내가 수백만 개의 임의 계정을 보증하지 않을 사람만 보증한다면, 시빌 공격식 활동은 내 보증에 전혀 영향을 주지 않음
      “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의 3중 메타 조정 시스템도 인정받을 만함
      완벽하진 않았지만, 아무것도 없는 것보다는 확실히 훨씬 나았음

  • 이미 이런 게 여섯 개쯤 있는 것 같은데, 왜 기존 것에 합류하지 않고 또 하나를 만들까?

답변달기