【ITニュース解説】Stop Your UMAP From Moving: The Pipeline Randomness You're Missing

システムエンジニアを目指す初心者の皆さんが、将来IT開発の現場で出会うかもしれない興味深い問題解決のプロセスについて解説する。この記事は、特定の機械学習アルゴリズムであるUMAP（Uniform Manifold Approximation and Projection）を使ってデータのクラスター（集まり）を可視化するウェブアプリケーションを開発する中で、実行するたびにクラスターの位置が変わってしまうという現象に直面し、その原因を特定して解決するまでの道のりを扱っている。

まず、この問題の核となるのは「ランダム性」という概念だ。ITの分野、特に機械学習や最適化アルゴリズムにおいて、ランダム性は非常に重要な役割を果たす。私たちが「完全にランダム」と考える事柄も、コンピュータ上では「擬似乱数」として生成されることが多い。擬似乱数は、ある初期値（シード）から特定の計算式を適用して、一見するとランダムに見える数列を生成する。

最適化アルゴリズムにおいて、ランダム性が役立つのは、より良い解を見つけるためだ。例えば、地図上で最も低い地点（最適解）を探すような状況を想像してみよう。もし常に一番低い方向にしか進めないルールだと、小さな窪地（局所最適解）にたどり着いたとき、そこが全体の最低地点（大域最適解）だと誤解してしまう可能性がある。しかし、時折ランダムに少しだけ高い方へ進むことを許容すれば、その窪地から抜け出して、より低い地点、つまり本当に一番低い地点を見つけ出すチャンスが生まれる。機械学習アルゴリズムは、このランダムな「悪い選択」を許容することで、より良い学習結果や最適解に到達できることがあるのだ。

UMAPもこのランダム性を活用している。UMAPは、高次元の複雑なデータポイントを2次元や3次元といった低次元の空間にマッピングし、似たデータポイント同士を近くに、似ていないデータポイント同士を遠くに配置することで、データの構造やクラスターを可視化するアルゴリズムだ。UMAPがデータから学習する際、データポイントの初期配置をランダムに決めたり、クラスターを形成するための移動をランダムに行ったりする。このプロセスが、コードを再実行するたびに異なるクラスタープロットが生成される原因となっていた。

この「実行ごとに結果が変わる」という問題を解決するために、最初に試したのは、UMAPのランダム性を制御することだった。UMAPライブラリにはrandom_stateというパラメータが用意されている。これは、擬似乱数生成のシードとして機能する。例えば、random_state=42と設定すると、乱数生成器はこの「42」という値を初期入力（シード）として使い、そこから特定の数学的計算によって一連の乱数を生成する。このシードが毎回同じであれば、そこから生成される乱数のシーケンスも常に同じになる。

具体的には、最初に42を式に入れてAという数値を得、次にAを式に入れてBという数値を得る、というように、直前の出力が次の入力となる形で一連の数値が生成される。この仕組みにより、UMAPの内部で使われる乱数系列が固定され、同じデータセットをUMAPに入力すれば、毎回同じクラスタープロットが生成されるはずだと考えた。実際にUMAPのリデューサー（変換器）を設定する際に、random_state=42と指定し、データを変換（fit_transform）してみた。

しかし、この変更を加えても、再度プロジェクトを実行するとデータポイントの位置が動いてしまうことが判明した。これは、UMAPの内部だけでなく、さらに他の部分にもランダム性の原因が潜んでいることを意味していた。詳細な調査を進める中で、データの処理方法自体にランダム性が含まれる可能性があることが示唆された。

この問題の根源を探る中で、二つの新たなランダム性の発生源が見つかった。一つは、ウェブアプリケーションで使用するツイートデータのサンプリング方法だ。アプリケーションはデフォルトで21,000件のツイートを処理する設定になっていたが、毎回実行するたびに、利用可能な全ツイートの中からランダムに21,000件を選び出していた。つまり、UMAPに入力される「生データ」が毎回異なっていたのだ。もう一つは、ユーザーがアプリケーション上で「テストツイート」を追加したり削除したりできる機能だ。これもまた、UMAPが処理する生データセットの内容を実行ごとに変化させていた。

「生データが毎回全く同じ方法で再処理される場合のみ結果が安定する」という重要な原則を理解し、これらの問題に対処する必要があった。そこで、ツイートをサンプリングする処理にもrandom_state=42を設定した。これにより、毎回同じ21,000件のツイートが選ばれるようになり、UMAPに入力されるデータセットが固定された。この二つ目のrandom_stateを設定した後、プロジェクトを再実行すると、驚くべきことにクラスターの動きは完全に止まり、実行するたびに同じクラスタープロットが得られるようになった。

しかし、この成功はユーザーがテストツイートを追加・削除する機能において一時的なものだった。ユーザーがツイートを入力したり削除したりするたびに、データポイントは再び動き始めたのだ。これは、前述の「生データが毎回全く同じ方法で再処理される場合のみ結果が安定する」という原則がここでも破られていたためだ。UMAPは、ユーザーがデータを変更するたびに、新しいデータセットとしてすべてを最初から再計算していると解釈していたのである。

この最終的な課題を解決するためのアプローチは、UMAPの学習済みモデルを再利用するというものだった。具体的な解決策は以下のようになる。まず、UMAPを安定した固定のデータセット（例えば、最初にサンプリングしてrandom_stateで固定した21,000件のツイートの埋め込みデータ）で一度だけ学習させる（fit_transform）。この学習によってUMAPの「reducer」（変換器）が生成される。このreducerは、データの特徴を低次元空間にマッピングするルールを学習した状態になる。

次に、この学習済みのreducerを保持（キャッシュ）しておく。ユーザーが新しいテストツイートを追加したり削除したりした場合でも、UMAPに最初からすべてを学習させるのではなく、キャッシュしておいた学習済みのreducerを使って、新しいツイートの埋め込みデータをtransform()メソッドで変換する。transform()メソッドは、既存の学習済みルールに基づいて新しいデータをマッピングする機能だ。これにより、基本的なデータセットのクラスターは常に同じ位置に保たれ、新しいテストツイートもその学習済みルールに従って既存のクラスター構造内の適切な場所に配置されるようになる。

この一連の問題解決を通じて得られた教訓は大きい。機械学習の分野には、一見すると些細に見えるような「ニュアンス」が多数存在し、それらを考慮することが非常に重要だということだ。もしユーザーによるテストツイートの追加・削除機能がなければ、二つのrandom_state設定だけで問題は解決したかもしれない。しかし、複雑な要件が加わることで、問題はより深く、多層的になる。

また、単に「この解決策で問題は修正されるか？」という問いに答えるだけでなく、「なぜ」その問題が発生するのか、そして「なぜ」その解決策が機能するのかを深く理解することの重要性も再認識させられた。確率的なアルゴリズムがどのように動作し、ランダム性がどのような特性を持つのかを深く理解していなければ、今回の問題解決ははるかに困難で時間のかかるものになっていただろう。最終的に、当初は非常に厄介でフラストレーションのたまるバグだったものが、非常に重要な学びの機会となり、システムの理解を深める貴重な経験となった。