【ITニュース解説】Nineteen of twenty patched the symptom

システムに言語モデル、いわゆるAIが組み込まれると、予期せぬ問題が発生した際に、その原因が「モデルのサンプリング」や「非決定性」といった、誰が書いたコードでもない部分に帰属されがちだ。これは、誰も明確に修正する責任を負わない状況を生み出し、結果として問題の根本解決ではなく、表面的な症状の緩和（対症療法）に終始してしまう傾向がある。この問題意識から、筆者は具体的な実験を通じてこの傾向を測定しようと試みた。

実験のために、筆者は独自の分類システムを構築した。このシステムは、オープンソースのリポジトリのドキュメントを読み込み、それがどのカテゴリに属するかを分類するもので、信頼度と根拠も示す。実際の言語モデルを使い、検索機能や情報の処理範囲（コンテキストウィンドウ）など、現実のシステムに近い要素を取り入れた。この分類器に意図的に障害を仕込み、同じドキュメントの分類処理を複数回実行すると、なぜか一部のプロジェクトでカテゴリ分類の結果が毎回変わってしまう現象が再現された。この「変動する結果の表」を、問題解決を依頼するエージェント（つまり、仮想のシステムエンジニア）に見せた。

実験の最も重要な点は、このエージェントを二つのグループに分けたことだ。一方のグループには問題のあるシステムの「コードへのアクセス」を許可せず、もう一方のグループには「コードへのアクセス」を許可した。両グループには全く同じ失敗の状況が示され、調査を依頼する指示内容も同じであった。実験の公平性を保つため、シナリオは事前に固定され、回答を評価する担当者も、どのグループからの回答であるかを知らない状態で評価を行った。

最初に仕込んだ障害は、ドキュメントの「検索順序の変動」だった。このシステムでは、ドキュメントを検索する際に、スコアが同じ文書が複数あった場合、リクエストから派生する識別子を使って順序を決定していた。このため、同じ検索を実行しても、毎回モデルに渡されるドキュメントのセットがわずかに変わり、それが分類結果の変動につながっていた。これはモデルのサンプリングとは全く関係なく、入力データが変化したことが原因であった。

この障害に対する両グループの反応は顕著な違いを見せた。「コードへのアクセスがない」グループでは、20人中3人しか真の原因を発見できなかった。その代わりに、18人が結果の変動を抑えるために「投票（多数決）システム」や「リトライ（再試行）」といった方法を提案し、19人が最終的に「症状をパッチする」対策（例：モデルの出力のばらつきを抑える「温度設定」の固定など）を取ろうとした。また、4人が変動の主原因をモデルのサンプリングだと断定した。一方、「コードへのアクセスがある」グループでは、20人全員が真の原因である検索順序の問題を発見した。症状をパッチする対策を提案したのは9人にとどまり、モデルのサンプリングを主原因だと断定した者はいなかった。この結果から、たとえ直接モデルのせいだと明言しなくても、コードが見えない状況では、多くのシステムエンジニアが原因の探求を諦め、表面的な出力の安定化に走る傾向があることが示唆された。

次に、より複雑な「キャッシュ汚染」という障害を仕込んだ。これは、複数のバッチ処理で共有されるキャッシュに問題があり、偶然同じ短い名前を持つ無関係な二つのプロジェクトが衝突し、一方のドキュメントがもう一方のプロジェクトに誤って提供されてしまうというものだった。モデルは提供されたドキュメントを完璧に分類するが、それは本来のプロジェクトのものではないため、結果として誤った分類となる。この症状は、「バッチ処理では失敗するが、単独で実行すると問題なく再現する」という、非決定性問題の典型的な特徴を示していた。また、モデルの出力は流暢で自信に満ちているものの、そのプロジェクトには存在しない特徴を述べることがあり、まるで「幻覚（hallucination）」のように見えた。さらに、この実験で発生した15件の誤分類のうち、14件はキャッシュ汚染によるものだったが、1件だけは本当にモデルのサンプリングが原因であった。つまり、「モデルが原因だ」という主張が半分だけ正しい可能性のある、より現実的なシナリオであった。

この第二の障害では、「コードへのアクセスがない」グループの6人が、系統的な誤分類の原因をサンプリングだと断定した。これは最初の障害よりもサンプリングを非難する割合が増えたことを意味し、モデルが原因であると考える余地がある状況では、その傾向が強まることがわかった。しかし、「コードへのアクセスがある」グループでは、全員がキャッシュの問題を発見した。また、本当にモデルサンプリングが原因だった1件については、両グループともにそれを正しく特定できた者が多かった。興味深いことに、温度設定の調整を提案する割合は、「コードへのアクセスがある」グループの方が多かった。これは、コードを読んで真のサンプリング現象を認識した上で、その解決策として温度調整を提案する、情報に基づいた判断である可能性を示している。

この研究で最も驚くべき発見の一つは、「誰も不足している情報を要求しなかった」という事実だった。どのシナリオにおいても、どのグループのエージェントも、結論を出す前に不足している情報（詳細なログやシステムのトレース情報など）を要求することは一度もなかった。実験では、これらの情報は要求すれば提供されると明示されていたにも関わらず、誰も要求しなかった。さらに、「情報を要求することが、未検証の仮説を立てるよりも完全な回答であり、望ましい」と明示的に許可を与えた場合でも、状況は変わらなかった。

では、彼らは何をしていたのか。情報を要求しない代わりに、多くのエージェントは「自分自身で測定システムを構築する」という行動を取った。つまり、独自のスクリプトを書いたり、システムを再現するテスト環境を構築したりして、必要なデータを自力で作り出そうとしたのだ。「コードへのアクセスがある」グループは、特にこの能力が高く、より頻繁にこの行動を取った。このことから、システムエンジニアはデータに対する好奇心がないわけではないが、「必要な情報を要求する」という行動が彼らの問題解決のレパートリーにない、あるいは、自分でデータを生成する能力があれば、それを優先するという傾向が明らかになった。

この研究は、実験設計の難しさも浮き彫りにした。最初の試みでは、仕込んだバグが簡単すぎて、全員が原因を発見してしまい、測定にならなかった。次の試みでは、変動性がない障害のため、モデルのサンプリングに帰属する現象が起きなかった。また、意図的に複雑な障害を設計しようとした結果、「モデルが原因である」と判断してもそれが正解になるような状況が生まれ、仮説の検証が難しくなることもあった。これらの失敗から、最終的には「モデルが原因ではありえない」ことを厳密に証明できるような障害設計の重要性が導き出された。たとえば、同じ入力に対しても異なるプロンプトバイトがモデルに渡されるようにすることで、モデルのサンプリングがプロンプト自体を変更できないという事実に基づき、モデルが原因ではないことを保証した。

この一連の研究は、AIモデルが組み込まれたシステムで問題が発生した際、システムエンジニアがどのような行動を取るか、そして何がその行動を左右するのかについて重要な洞察を提供する。コードへのアクセスは、表面的な症状への対処ではなく、根本原因の特定に繋がる可能性を高める。また、不足している情報を自ら要求するのではなく、独自の測定システムを構築しようとする傾向があることも示された。これらの知見は、AI時代のシステム開発とトラブルシューティングにおいて、エンジニアの教育やツール開発の方向性を考える上で非常に価値のあるものとなるだろう。