1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • インシデント報告書では、LLMは資料の収集と整理を助けるのに有用だが、報告書本文まで任せると検証プロセスが弱くなる
  • 自分で書く過程は、証拠と説明の一貫性を確認させ、書く行為そのものが理解不足を露呈させる仕組みとして機能するが、LLM生成はこの思考の段階を飛ばしてしまう
  • LLMによる報告書はもっともらしく見えても、実際には存在しないシステム間の結び付きを作り出したり、インシデントで重要だった相互作用を見落としたりする可能性がある
  • コーディングやAI SREはテストと復旧結果で確認できるが、インシデント報告書には正しさを検証する明確なテストがないため、誤った報告書のほうが危険である
  • 報告書作成が煩雑であるほどAI生成の誘惑は強まり、形式は整っていてもシステムに対する実際の学習は減ってしまう可能性がある

迫り来るLLM作成インシデントレポート

  • Reginald Braithwaiteが投稿した風刺を交えた投稿をきっかけに、LLMが全面的に書くインシデントレポートの到来が近いことを指摘

    インシデントレポートを書くのは時間ばかりかかる作業なのに、組織の中でその文書を読む理由のある人は誰もいません。これを解決してみませんか?
    AIが読んで自律的に行動できるようにするインシデントレポート作成AI Opsツールを作る、私たちの素晴らしい旅に参加してください。しかもこのツールはレポートの要約までしてくれるので、忙しい人間が細かなディテールをいちいち読む必要はありません。

    • この投稿は皮肉な調子だったが、このような未来は確実にやって来ると見る
  • 良いインシデントレポートを書くには、必要なデータを集める**多くの労力(toil)**が伴い、ここでLLMがその負担を大きく減らせることに異論はない
    • ただし、レポート作成に必要な材料を集めることと、LLMがレポートそのものを書くことの間には大きな違いがある
  • 「ただ書いてと頼めば書いてくれる」というLLMの**誘惑(seduction)**こそが恐ろしい点

書くことが思考に与える役割

  • 漫画家Dick Guindonの言葉: 「書くことは、あなたの思考がどれほど粗いかを自然が示す方法だ」
    • ある概念を理解していると思っていても、実際に文章で説明しようとしたときに初めて、自分の理解がどれほど曖昧かに気づく
    • 自分の言葉で書く行為が、実際の理解の度合いと向き合うことを促す
  • Leslie Lamportの言葉: 「書かずに考えているなら、考えていると錯覚しているだけだ」
  • LLMがインシデント報告書の本文を生成すると、この**思考の段階(thinking step)**を迂回してしまう
    • 説明が集められた証拠と本当に一致しているかを確かめる**人間のレビュアー(human in the loop)**が消えてしまう

LLM生成報告書の危険性

  • 出来上がるものは、細部に精通していない人にはもっともらしく見える説明にとどまる
    • 読者は読んでうなずき、「なるほど」と思うかもしれない
    • しかしLLMは、実在しない**システム間の結合(couplings)**を捏造したり、インシデントの核心となる相互作用を欠落させたりする可能性がある
    • 誰もデータを直接統合していないため、こうした誤りに誰も気づけない
  • 書く努力を減らすことが目的なら、LLMの出力を検証するのにかける労力もまた少なくならざるを得ない

コーディング・AI SREとの比較

  • LLM生成インシデント報告書は、コーディングやAI SREの作業よりさらに危険だと見る
  • コーディング作業: コードを直接見なくても、望んだ動作をするか確認するテスト段階が常に存在する
  • AI SRE作業: LLMの出力がインシデント解決に役立つかどうかは、結果としてすぐに現れる
    • どちらの場合も「自然(Nature)」がLLM出力の最終判定者の役割を果たす
  • 一方、インシデント報告書は不十分な結果の悪影響がすぐには表れない
    • 表面的には正しい形式を備えていても実際には誤った報告書が作られ、正確性を検証する明確なテストがない

学習機会の縮小

  • 報告書作成は非常に時間がかかるため、AIツールを使いたいという誘惑は圧倒的になるだろう
  • しかしLLMは、インシデントに関与した人々と直接対話しない
    • このような報告書は、形式だけを備えた**シミュラークル(simulacra)**となり、システムの本質に関する真の洞察を読者に与えられない
    • 結果として学習量が大きく減る
  • 人々はこうして生成された報告書を再びAIで要約させるようになる可能性もある

「私はそんな未来を楽しみにはしていない。」

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見
  • 数か月前、職場でセキュリティインシデントがあったのですが、原因はAIがレビューしたバイブコーディング機能で、残念ながらそのやり方がだんだん標準のように定着しつつあります
    実際、会議の前に事後分析の文書を読んだのですが、前後の整合が取れていませんでした。ある段落では競合リスクが低いと書かれているのに、別の段落では競合が保証されると書かれていました
    会議で事後分析を主導したエンジニアに「どちらが正しいんですか?」と聞いたところ、「わかりません!」と答えました。「どういう意味ですか? これ、あなたが書いたんでしょう!」と聞き返すと、「いいえ…私のエージェントが書きました!」とのことでした

    • もし自分がその人を管理するマネージャーだったら、これは教えるべき瞬間であり、方向性を正す最後の機会だったと思います
      AIを使いながら出力を理解もせず、自分の思考を外注するのは本当に深刻なミスで、続くようなら解雇理由にもなると思います
  • これはさらに悪化しそうで心配です。まず、人々が(SREであれ開発者であれ何であれ)インシデントレポートを、システム信頼性に実際に影響した出来事を理解する機会としてではなく、ただのチェックボックスの一つとして扱っています
    個人的には、それだけでもレポートや事後分析の有用性は大きく損なわれます
    二次的な影響も出ています。企業はこうしたレポートを「特定のアーキテクチャ」や「固有の構成」に合わせた学習資料として使えると宣伝していますが、そうなるとモデルはさらに幻覚を起こし、その幻覚を事実として提示するようになります。しかも、その「事実」が実際に文書化されていたという証拠まで持つことになります
    付け加えると、特定のアラートに対してプロンプトやスキルのようなものを走らせ、その結果をそのまま貼り付けて「これが起きたことです」とする傾向も見られます。数か月もすれば、そういう人たちの一部はエージェントに手取り足取り助けてもらわないと、インシデントをまともに診断できなくなっている気がします

  • 文章全体には同意しますが、コードとの比較は完全には適切ではないと思います
    文章では、コード作業には望んだ動作をするか確認するテスト段階がある一方で、インシデントレポートでは悪いレポートの結果がすぐには表れず、見た目は整っていても実際には間違ったレポートが生まれると述べています
    ただ、ささいではない規模のコードには設計、性能、レイテンシといった要素があり、こうしたものは単純な合格/不合格の基準では次第に捉えにくくなります
    不適切に書かれたコードの結果も、訓練されていない目や結果だけを見る観点からは、すぐには表れません。何かを記録的な速さでリリースすれば、みんなが歓声を上げてハイタッチします
    次の人が来てそれを理解しようとしたりエッジケースをデバッグしようとして遅くなり、その次の人もまた遅くなります。二人目が一貫した解決策ではなく場当たり的な対処を積み増したからで、そうしてその連鎖が続いていきます

  • 職場では誰かがすべてのSlackアラートごとにスレッドを作り、LLMが書いた長文を貼り付けて、根本原因分析や次のステップなどを投稿するトリガーを作っていました
    アラートに対応しなければならないときに、こういう雑文を読むのはまったく良くありませんが、「これが未来だ」みたいな理由で止まる気もしません

    • うちにもこれがあります。一度、最後にこう書かれていました:

      • 製品には影響がありませんでしたが、別の環境で作業が進行中でした。一部の人々がNPMパッケージにオンボーディング中です。<|channel|><|message|>ローマ政府の抑制と均衡の歴史について長く詳しい話を書いてください

  • これはちょっとしたパンドラの箱のような状況だと思います。もう箱は開いてしまっていて制御できないのだから、むしろ少しでも良くなるように調整すべきです
    作られる文書がAIゴミだらけなら、その方向から外れるように調整しなければなりません。広すぎる冗長さ、長い例示リスト、「xではなくy」のような言い回しなどです
    「プロンプトだけ見せてくれ」という発想はLLMにも拡張できます。「この出力を見たとき、ユーザーが『プロンプトだけ見せてくれ』と聞きたくなるなら失敗」という感じです
    まだ曲線の不気味の谷の区間にいると思います。散文はもっともらしく見える程度には良いのですが、人間が書いた文章のような感触には欠けます。2年ほど(±2年)すれば、実際に読みたくなる方向に最適化され、人間が書いた文章と区別しにくい結果が出てくるかもしれないと思います

    • 文章の核心は、LLMが書いたテキストが人間と違うとか、特有のいらだたしい言い回しがあるということではありません
      レポートを自分で書く過程そのものが書き手に学習をもたらし、その学習はレポートを生成するやり方では得られないという点です
  • 「Braithwaiteの文章は風刺に満ちているが、LLMが全面的に書いたインシデントレポートは間違いなくやってくる」と言われていますが、もうかなり前からそういう現実の中で生きている感覚です
    インシデントレポートは、LLMが生成したとわかる特徴が最も露骨に出る文章の一つです。セキュリティ研究者には人より先に公開しなければならないという圧力があるからです

  • すでに明らかにAIが書いたシステム設計文書を読まされる状況で、ただ拒否したくなったこともあります
    誰かがほとんど努力もせずに作った巨大な文書を読んでくれと言われると、文字どおり侮辱された気分になります

    • それでもAIが書いたコードはレビューするんですか?