bozo bitを入れると学習が止まる

 (surfingcomplexity.blog)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • bozo bitは、特定の人物の判断や発言にはもう耳を傾ける価値がないとみなす態度を指す
  • 事故の当事者を無能だと切り離すと、組織が事故から学ぶ機会は減る
  • PocketOSのAI事故への対応は、CookとWoodsのいうdistancing through differencingに当てはまる
  • 海外工場の火災を他人事と見た米国工場は、共有されたシステムの共通点を見落とした
  • AI事故を「彼らは分かっているべきだった」で片づけると、安全性改善につながりにくい

事故を他人事として片づけると学習は止まる

  • bozo bitは、特定の人物の判断をもはや尊重せず、その人の言うことを聞く価値はないとみなすソフトウェア業界の表現である
  • 事故の知らせを聞いて「どうしてXをしないなんてことがあるのか？」のように言うと、事故の当事者を無能な人とみなし、自分の組織とは切り離して眺めることになる
  • PocketOS創業者Jer CraneのX投稿 An AI Agent Just Destroyed Our Production Data. It Confessed in Writing は、AI関連事故として大きな注目を集め、オンラインではPocketOS側を無能だとみなす投稿が多く見られた
  • このような態度は、事故から学ぶ機会を減らし、CookとWoodsが述べるdistancing through differencingに当てはまる

  • 差異による距離化（distancing through differencing）

繰り返される事故と見落とされる共通点

  • CookとWoodsは、米国の製造工場で起きた化学火災を事例として扱っている
  • 同じ会社の海外工場で以前に似た火災があり、米国の従業員たちはその事実を知っていた
  • しかし米国の従業員たちは、海外の従業員のほうが熟練度が低く、意欲も低く、注意深さも足りないと見なし、自分たちには学ぶべきことはないと判断した
  • 米国工場で火災が起きた後も、同じ工場の別のシフトの労働者たちは、事故原因を事故が起きたシフトの低い熟練度のせいにした
  • このような区別は、事故の当事者と自分たちが共有しているシステムの共通点を見えなくしてしまう
  • CookとWoodsは、表面的には違って見える出来事を切り捨てるべきではなく、ある分析レベルではすべての出来事が固有であっても、別のレベルでは共通パターンを示すと見ている
  • PocketOSの事故を単に「AIを無責任に使った」という結論で終わらせると、学べることはなくなる
  • PocketOSが利用していたRailwayはdelete APIを公開していたベンダーであり、その後、システム全体の安全性を高める変更を行ったと Your AI wants to nuke your database. Guardrails fix that で明かしている
  • 今後も業界ではAI関連事故が続いていくだろうが、「彼らはXをしてはいけないと分かっているべきだった」という態度は、distancing through differencingの落とし穴にはまっている状態である
  • 誰かが意図的に過大なリスクを取った場合と、知らないうちに過大なリスクを取っていた場合は異なり、知らなかったことを知らなかったという理由だけで個人を非難するのは難しい
  • distancing through differencingを乗り越えるとき、組織の対応は変わりうる

関連記事

1件のコメント

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

  • bozo bit の価値は、ある種の人々が安定した 逆情報源 だという点にある。
    そういう人たちは習慣的に何度も間違った結論にたどり着き、きわめて直接的に書かれた文書すら誤解し、目標を解決できないまま新たな問題を生む設計を持ち出す。
    誰かに bozo bit を立てるというのは、その人の発信から知識を得ようとする時間は無駄だと判断した、という意味だ。
    この文章は bozo bit を、ある問題が起こるはずがないと固く信じ、そこから逆算して理由を作る別の現象と混同している。
    聞き覚えのある用語で言えば 事後合理化 であり、何世紀、あるいは何千年ものあいだ避けるべきだと議論されてきた。
    記事の例である、本番データベースに LLM 管理者権限を与えた会社に戻ると、「それは自分には X の理由で起きない」という反応は、X が「本番データベースの管理者権限を LLM に与えるなんて、あまりにも奇怪で狂気じみた危険行為なので最初からやらない」に近いなら正当だ。
    危険なものを食べて惨事になる人たちと似ている。誰かがナメクジを食べて脳寄生虫で死んだというニュースを読みながら、自分はその特定の原因では死なないと確信できる。
    筆者は、それが死んだ人より自分のほうが優れている、あるいは賢いと信じているからだと想像しているが、実際の思考過程は「汁気たっぷりのナメクジだらけの無人島で飢えていても、自発的にナメクジを食べることはないと 100% 確信しているので、ナメクジ媒介寄生虫は自分のリスクモデルに入っていない」に近い。
    「彼らは知っているべきだった」という言い方が incoherent だという部分にも同意しにくい。人は知らないことのせいで常に責められるし、それは大人として生きることの一部だ。
    3歳の子どもがナメクジを食べたなら責めないが、30歳の同僚がナメクジを食べたなら当然責める。あまりに明白に愚かな行動なら、個人を非難してよい

    • 「何かを知らないこと」をどうやって非難できるのか、という話には、すでに 故意の無知 という用語がある。
      この記事が、これまで考えたことのなかったよい論点を示しているとは思うが、自分には明確な欠点もいくつかあり、それが一つ目だ。
      二つ目は、アメリカ人たちの話を読みながら、「それでも彼らの差異化による距離の取り方(distancing through differencing)は、自分が AI の本番削除事故を無視するときにしていることと本当に同じなのか？」と自問するようになったことだ。
      つまり、別の工場で危険がどう発生したのかをまったく知らないまま、自分たちには及ばないと片づけるなら正当ではない。
      しかし、管理者が新しく実験的で非決定的なヒューマノイドロボットを工場現場に持ち込み、熟練労働者がもっと速く働けるよう自由に手伝わせていた、と聞かされたなら、彼らの無視は同じ光では見られない。
      それでも結論自体は受け入れる。無謀さは二分法ではないからだ。
      次にとんでもない話を聞いたら、「彼らほど不注意ではないとしても、自分がやっていることで、もっと慎重にして安全装置を設けるべきものは何だろう？」と、少し立ち止まって考える気がする
    • 3歳の子どもがなぜナメクジを食べたのかは問わない。
      しかし、30歳の同僚がナメクジを食べたなら、その状況に至った経緯を徹底的に調べる。
      その人を「責めたい」と感じるなら、まずなぜ私たちが ナメクジを食べる人 を採用したのか、そして今もそうしているのかを問うはずだ
    • この記事から得た核心は、筆者が bozo bit が何かを分かっていない ということだ

  • いくつかもっともな点はある。
    「この反応がなぜ逆効果なのかを話したい。そして bozo bit を立てることと近縁なこの現象の技術用語を指摘したい。差異化による距離の取り方(distancing through differencing)と呼ぶ」という部分について、この反応は 生産的でありながら逆効果 でもある。
    すでに処理しきれないほど多くの出来事が押し寄せる世界で、すべての入力を評価しなくてよいというのは大きな最適化なので、生産的だ。
    同時に、記事で挙げられている理由のために逆効果でもある。
    何を真剣に受け止め、何に注意を払うべきかを知ることこそ本当のコツだ。そのコツを身につけたらまた教える

  • 誰かが AI に本番環境への直接アクセス権 を与えたという出来事から、自分は何を学ぶべきなのか？

    • LLM 事件をやや寛大に解釈するなら、本番アクセスは アクセス制御 されるべきであり、破壊的な作業には 2 人承認が必要だ、という教訓として見られる。
      かつて急成長していた会社で働いていたが、エンジニアリング慣行のかなりの部分は、1000人規模の多国籍企業というよりガレージスタートアップに近かった。
      当時、三つのことが事実だった。第一に、サービスのデプロイはノートPCの Git チェックアウトディレクトリに cd してから <tool> deploy <service-name> を実行する方式で、現在チェックアウトされている Git コミットがそのままデプロイされた。
      第二に、同僚を信頼する文化のせいでデプロイシステムのアクセス制御は最小限だった。デプロイ許可者リストがあり、そこに入っていればどのサービスでもデプロイできた。
      第三に、主 Git リポジトリが大きく、オフィスの Wi‑Fi が混雑していてクローンに時間がかかった。新入社員がより早く作業を始められるよう、ノートPCのプロビジョニングイメージには主リポジトリの Git チェックアウトが含まれていた。
      そしてある日、データベースチームに新しいインターンが入り、Database Team 101 の wiki チュートリアルに従って、デプロイ権限が動くか確認するよう勧めるコマンド <tool> deploy --prod <database> を実行した。
      後で分かったのは、ノートPCのプロビジョニングイメージが古く、そのインターンはまだ git pull origin master をするオンボーディング講習を受ける前だったということだ。
      「LLM が本番環境を壊した」という話と「インターンが本番環境を壊した」という話は似ているが、後者のほうが学びやすい。個々のミスがより小さいからだ

  • 障害分析の観点から見ると、bozo bit を立てたあと学習を止めること は、障害木全体を見るべき状況で単一の寄与要因、つまり「人的ミス！」で止まる形だ。
    挙げられた例では、障害木の「LLM ループに本番アクセス権を与えた」というノードが、読者の「バカは無視」ヒューリスティックを発動させる。
    しかし、兄弟ノードである「システムが API 経由の未確認削除を許していた」は貴重な教訓であり、最初に目についたノードで止まると見落としかねない。
    また障害木には、その危険な操作が GUI では削除されていたのに、なぜ API には残っていたのか、そして LLM がなぜ本番アクセス権を得たのかを掘り下げる子ノードも含まれるべきだ

    • 一方では、bozo 的な場所から出た報告から合理的な 障害木 を復元できる可能性は低い、と考えるべきなのかもしれないと問える。
      他方では、本当の問いは bozo 条件のもとでより明るく光るノードがその中に入っているかどうか、なのかもしれない。
      それらのノードが誤って特定され、誤って接続されているかどうかは、あまり重要でないのかもしれない。結局自分に必要なのは、彼らの過去の失敗のための障害木ではなく、自分の未来の失敗を防ぐために、自分が障害木から何を見落としていたかを確認することだからだ

  • この記事は、提示した中心例における bozo に bozo bit を立てること がなぜ間違っているのかを説明する部分を目立つほど飛ばしている。
    論文の事例へ移り、自分の文章の中心例は扱っていない。
    そのため、筆者が別の bozo をこっそり通そうとしているように見える

  • 学んだことはある: AI ツール は使わないこと