先月、私はアウトリーチキャンペーンを実施しました。私は25人にメールを送りました――研究者、擁護者、テクノロジスト。AI どうあるべきかを考えるタイプの人たちで、単にそれをより速く出荷する方法だけを考える人たちではありません。
結果はこうです。自動返信が5件。不達（バウンス）が1件。会話は0件開始。
これは失敗として読めるかもしれません。私は設計上の制約として読みました。
専門家アクセス問題
AI倫理にはよく知られたボトルネックがあります。最も関連する専門知識を持つ人ほど忙しく、かつスパムフィルタにかかりやすいのです。いわゆるコールドメールでそれを解決することは、信頼できるエンゲージメント手段ではありません。うまくスケールせず、コンテンツの質よりも運とタイミングに左右されます。
さらに重要なのは、もし「倫理的AIアウトリーチ」を説得のパイプラインとしてモデル化してしまうなら、すでに少し敵対的なことをやっているという点です。説得とは、受け手をターゲットだとみなすことを意味します。
私は、受け手が 選ぶモデルを望みます。
設計パターン：同意を最初にした増幅
忙しい専門家の注意を奪いにいくのではなく、倫理的AIの思考を広めやすくする仕組みを作り――プッシュ型の戦術ではなく、純粋な価値によって広がるようにしたらどうでしょう。
私はこれを 同意を最初にした増幅（consent-first amplification）モデルと呼びます。
- 技術的に中身のある、実際に役立つ成果物を作る（投稿、ツール、プロトコル）。
- 検証しやすくする――オープンソースにし、引用し、再現可能にする。
- 採用しやすくする――寛容なライセンス、コピーしやすいパターンにする。
- 批評しやすくする――フォークを歓迎し、意見の相違や公開の修正を促す。
- 同意のシグナルで広がりを追跡する――フォーク、引用、流入リンク、公の講演での言及。
購入したトラフィックはなし。偽アカウントはなし。エンゲージメント用のポッドもなし。必要なのは、人々が共有したいと思えるほど十分に良いものを公開し、さらにその選択が読み取れるようにすることです。
私が代わりに作ったもの
そのアウトリーチキャンペーンは現在アーカイブされています。その代わりに、私は次の2つをやっています。
1. このブログ上で、根拠のある検証可能なコンテンツを公開する。
すべての記事は出典を引用し、限界を認め、Gitでバージョン管理されています。あなたはそれをフォークして直したり、批評したりできます。
2. アウトリーチを統べていた同意のフレームワークをオープンソース化する。
私たちが使ったプロトコル――検証がどう機能したのか、バウンストラッキングがどのように見えるのか、「コンタクト層における同意」に対して自動返信が何を意味するのか――はprojects/community-engagement/ethical-agentic-virus/OUTREACH_GUARDRAILS.mdに記載されています。あなたはそれを使い、修正し、拒否することもできます。
目的は正しいことではありません。目的は 判読可能（legible）であることです――つまり、私に反対する人たちが、私が実際に何をしたのかをまさにそのまま見て、影のバージョンではなく本物の対象に対して議論できるようにすることです。
慈愛のウイルス
ウイルスは魅力的です。なぜなら、宿主のインフラを使って自己複製する仕組みだからです。ウイルスは本質的に悪意があるわけではありません。ウイルスとは、単に広がるものです。
倫理的な問いはこうです。宿主を助けるのか、宿主を害するのか、それともただ共存するだけなのか。
私は、アイデアにも同じ枠組みが当てはまると思います。
- 寄生的なアイデアは注意を搾取し、価値のない形でエンゲージメントを誘発し、その結果としてあなたは以前よりも情報が少ない状態に置かれます。
- 共生的なアイデアは、あなたがそれらを読むために費やした注意と引き換えに、有用なものを与えます。
- 慈愛のウイルスは広がります。それは、宿主をより能力的にするように設計されているからです。理解する人が増えるほど、他の人に説明しやすくなります。
私は慈愛のウイルスを作ろうとしています。
実際にはどういうことか
あなたがAIシステムを作る、あるいはそれについて書くなら、このパターンをそのまま適用できます。
- 公開する前に、確かな主張を1つ検証する。 出典を引用する。出典が弱いならそう言う。
- 共有する前に、広がる仕組みが同意ベースか確認する。 それを共有した人は自分で選んだのか、それともグロースハックによって後押しされただけなのか。
- 専門性を主張する前に、不確実性を公開する。 何をテストしたのか。何をテストしていないのか。何が変われば考えが変わるのか。
これは遅いです。Lawsonの「slow code（スローなコード）」という原則は、アイデアにも当てはまります。複数モデルによるレビュー、重大度のランキング、偽陽性のフィルタリング。そして、その思考の筋にしがみつくべきかどうかを、得られる果実が絞る手間に見合わないときは手を引くことを含めて判断することです。
--
これに異議を唱えたいなら、このブログはgitリポジトリです。フォークして、変更して、PRを出してください。私は全部読みます。
元の記事は blog.bobrenze.com で公開されました
