Amazonの採用AIは「女性嫌い」を独学した。私が作ったAIには、それができない。
2014年、エディンバラの機械学習エンジニアのチームが、Amazon規模の採用課題を解決しようと腰を据えた。システムに100件の履歴書を与えれば、上位5件が、商品を評価するように1つ星から5つ星までランク付けされて返ってくる。エレガントで、効率的だ。そして3年のうちに、彼らはそのシステムが、女性であることを不採用に値する特性だと独りでに学習していたことを発見した。
そのAIは、「women's(女性の)」という単語——たとえば「Women's Chess Club Captain(女子チェスクラブのキャプテン)」のような表現——を含む履歴書に低い評価を与えた。2つの女子大学の卒業生の評価を下げた。誰かがそう指示したからではない。男性優位の業界の10年分の採用データでモデルを訓練すると、統計的に「男性であること」が「採用されること」の最も強力な予測因子の一つになるからだ。
そのロイターのスクープが報じられたときに読んだのを覚えている。私はすでにVeriprajnaでナレッジグラフシステムの構築に深く取り組んでいて、最初の反応は衝撃ではなかった——それは「やはりそうか」という納得だった。私は何か月も前から、統計的な相関エンジンには人間の潜在能力について判断を下す資格などない、と主張してきた。Amazonの件は異常事態ではなかった。それは数学的な必然だった。そしてそれは、AI採用に対するアーキテクチャ上のアプローチ全体が——周縁部ではなく、その土台から——壊れているのだ、と信じるほど私を過激にした。
問題はバイアスではない。アーキテクチャだ。
Amazonの失敗について、たいていの人が誤解していることがある。エンジニアが不注意だったと思っているのだ。そうではない。彼らは地球上でも屈指のML(機械学習)エンジニアだった。ジェンダーバイアスを発見したとき、彼らはそれを修正しようとした。性別特有の用語を無視するよう、モデルを明示的にプログラムした。それでも、モデルは抜け道を見つけ出した。
これは代理変数(プロキシ変数)という概念であり、私が夜も眠れなくなる原因そのものだ。ディープラーニングのモデルは、執拗なまでのパターン発見装置だ。入力から「woman(女性)」という単語を取り除いても、モデルは文の構造にしがみつく。研究によれば、男性の履歴書は「executed(実行した)」「captured(獲得した)」のような動詞を使う傾向があり、一方で女性の履歴書はより協調的な言葉に寄りがちだという。モデルは「executed」が「採用」と相関していることを見て取り、言語だけを通じてジェンダーバイアスをひそかに再構築する。
Amazonのエンジニアたちは、モデルの予測能力を破壊せずにバイアスだけを外科的に取り除くことができなかった。そこで彼らは、プロジェクト全体を葬り去った。
偶発的に差別してしまうシステムを修正することはできない。設計上、差別できないシステムを構築しなければならないのだ。
この一文が、3年間、私の道しるべであり続けている。そしてそれこそが、私たちがVeriprajnaの採用エンジンを、ニューラルネットワークではなくナレッジグラフの上に構築した理由だ。
なぜどのAIリクルーターも、いずれ差別を学習してしまうのか?
ディープラーニングが採用の場面でどう機能するのかについて、理解してほしいことがある。というのも、その失敗のあり方は直感に反しているからだ。
ニューラルネットワークは、「Python」が何を意味するのかを理解していない。Pythonがデータサイエンスに役立つプログラミング言語だということを知らない。ただ、「Python」という文字列が、採用された人々の履歴書に頻繁に現れた、ということだけを知っている。もし「Lacrosse(ラクロス)」も同じように頻繁に現れていたら——特定のスポーツと、特定の企業へと人材を送り込む特定の学校との間にある社会経済的な相関のせいかもしれない——モデルは「Lacrosse」を「Python」と同じくらい重く評価するかもしれない。
これは、知性を装った相関にすぎない。モデルは因果関係について推論しない。パターンを見つけ、それに向けて最適化するだけだ。そして厄介なのはここからだ。バイアスの増幅とは、これらのモデルが歴史的なバイアスを単に再現するだけでなく、それを誇張することを意味する。訓練データで男性が労働力の60%を占めていたなら、モデルは自らの精度スコアを最大化するために、男性を80%あるいは90%採用する方向へと押し進めるかもしれない。
初期の頃、ある投資家候補と話をしたことがある。彼はこう言った。「履歴書のスクリーニングにはGPT-4を使えばいい。ほかのみんなもそうしている」。私は彼にこう尋ねた。同じ履歴書をGPT-4に2回入力したら、同じスコアが返ってくるだろうか?彼は言葉に詰まった。答えは「ノー」だ——LLMは確率的なものだ。非決定論的なのだ。同じ入力を2回実行すれば、2つの異なる出力が返ってくる。監査の場面では、それは単なる癖では済まされない。コンプライアンス上の失敗だ。
規制の壁は、じわじわと迫っている
これはもはや机上の話ではない。各国政府はAmazonの一件を目の当たりにし、法制化を進めている。
ニューヨーク市地方法第144号(NYC Local Law 144)は、2023年7月から施行されており、自動雇用意思決定ツールを使用するすべての雇用主に対し、年次の独立したバイアス監査を受けることを義務付けている。「公平性を確認しました」という曖昧な監査ではなく、具体的で定量的な監査だ。この法律は、選択率(selection rates)と影響比率(impact ratios)を、人種、民族、性別のあらゆるカテゴリーについて算出することを義務付けている。ある保護対象グループの選択率を、最も多く選ばれたグループの選択率で割った値が0.8を下回った場合——いわゆる「5分の4ルール」——それは差別的影響(ディスパレート・インパクト)の一応の証拠となる。
EU AI Actはさらに踏み込んでいる。同法は、採用に使われるAIシステムを高リスク(High-Risk)——医療機器や重要インフラと同じカテゴリー——として分類している。第13条は、これらのシステムが「利用者がシステムの出力を解釈できるよう、十分に透明である」ことを求めている。第14条は人間による監督——AIの決定を覆す能力——を要求する。しかし、理解していない決定を意味のある形で覆すことはできない。
そしてGDPRのもとでは、第15条(1)(h)が、データ主体に対し、自動化された決定に「関与するロジックについての意味のある情報」にアクセスする権利を与えている。前文第71項は、「到達した決定についての説明を得る」権利を明示的に言及している。
ニューラルネットワークの決定を説明してみてほしい。さあ、どうぞ。「ニューロン4,502が強度0.8で発火した」は、意味のある説明ではない。「モデルはあなたを73%のマッチだと判定した」というのも、それ以上の詳細がなければ同じことだ。
技術的な複雑さと、平易な説明を求める法的要件との間のこの隔たりこそが、現代のHRテックの中心的な危機だ。
この規制状況については、当社ホワイトペーパーのインタラクティブ版でより詳しく書いた。そこでは、各規制が異なるAIアーキテクチャにどう適用されるのかを正確に解説している。
もしAIが、そもそも性別をいっさい見られなかったら?
ここで、すべてが腑に落ちたあの夜のことを話しておく必要がある。
私たちは、バイアスを取り除くためのさまざまなアプローチ——敵対的学習、反事実的データ拡張、いつもの道具立て——を試していた。夜11時、オフィスに座り、画面上のグラフの可視化を見つめていたとき、私はあの「後から思えば当たり前」の気づきの一つを得た。私たちは、モデルにバイアスを無視するよう教えようとしていた。だが、そもそもバイアスが文字どおり推論エンジンに入り込めないアーキテクチャを構築したらどうだろう?
ナレッジグラフでは、データはノード(エンティティ)とエッジ(関係)として格納される。Personノードは複数のSkillノードに接続する。Skillノードは、意味的な関係を通じて他のSkillノードに接続する。グラフは、「PyTorch」が「Deep Learning(深層学習)」のためのライブラリであり、それが「Artificial Intelligence(人工知能)」の下位集合であることを知っている。だから、ある仕事が「AIの経験」を求め、候補者が「PyTorch」を挙げていれば、グラフはその経路をたどってマッチを見つける——「AI」というキーワードが履歴書のどこにも現れていなくても、だ。
ここに決定的なアーキテクチャ上の判断がある。当社のマッチングアルゴリズムが実行されるとき、それは制限されたサブグラフ上で動作する。この推論グラフには、スキル、役割、経験レベル、資格が含まれる。名前、性別、民族、住所、卒業年月日のノードは明示的に除外されている。
バイアスは抑制されているのではない。それは構造的に切断されているのだ。「候補者」から「性別」を経て「役割」へ至る経路は存在しない。なぜなら、アルゴリズムが見ることのできるグラフには、性別ノードが存在しないからだ。
これを、生のテキスト全体を取り込むディープラーニングモデルと比較してみよう。「性別」フィールドを削除しても、モデルは「Women's Chess Club(女子チェスクラブ)」を読み取り、性別を推論する。当社のシステムでは、履歴書を解析するLLMが「Women's Chess Club」を中立化されたノードにマッピングする:(:Activity {type: "Strategy Club", role: "Leadership"})。ジェンダーを示す修飾語は、推論エンジンに入る前に取り除かれる。
これについてチームで交わした議論を覚えている。あるエンジニアが強く反論した——文脈を剥ぎ取ることで、私たちは価値あるシグナルを失っているのではないか、というのだ。「もしその女子チェスクラブが、実際には一般のクラブよりも競争が激しかったらどうする?」もっともな指摘だ。しかし、私たちは情報抽出を最大化するために最適化していたのではない。法的な精査のもとでの公平性のために最適化していたのだ。そして私は、限界的なシグナルを取りこぼす方を選ぶ——人口の半分にペナルティを与えることを学習するようなシステムを構築するよりは。
バイアスなしで、どうやって実際に才能を測るのか?
私たちは誰が成功するかを予測しない。私たちが測定するのはスキル距離——候補者が持っているものと、仕事が求めているものとの間の幾何学的な隔たりだ。これにより、採用は主観的な確率から客観的な測定へと移行する。
従来の応募者追跡システム(ATS)は、ブール論理を使う。履歴書に「Java」というキーワードが含まれているか?イエスかノーか。これは脆く、そして愚かだ。同じ能力を別の用語で表現している人を、ことごとく取りこぼしてしまう。
私たちはグラフ埋め込み(グラフエンベディング)——当社のオントロジー内のすべてのスキルについてベクトル表現を学習する、Node2Vecのようなアルゴリズム——を用いる。グラフ内で頻繁に共起するスキル(「Python」と「Pandas」など)は、ベクトル空間内で互いに近い位置に配置される。無関係なスキル(「Python」と「Phlebotomy(採血)」など)は、遠く離れて配置される。
候補者をスコアリングするために、私たちはコサイン類似度を、候補者のスキルベクトル集合と、仕事の要件ベクトル集合との間で計算する。これにより部分点が与えられる。「Tableau」を持たないが「Power BI」を持つ候補者は、それらのノードが「ビジネスインテリジェンス」クラスタ内の意味的な隣接ノードであるため、高い類似度スコアを得る。キーワード検索なら、その候補者にゼロ点をつけるところだ。
私たちはさらに、ジャッカード類似度を生のスキル重複のために、そして測地距離(ジオデシック距離)——グラフを通る最短経路の計算——をギャップ分析のために重ねる。ある仕事がKubernetesを求め、候補者がDockerを持っている場合、グラフは次の経路を見つける:Docker → Containerization → Orchestration → Kubernetes。距離:3ホップ。解釈:訓練可能。距離が6ホップ以上であれば、それは埋めがたいギャップだ。
最終的なスキル距離スコアは、純粋に能力に基づく指標であり、属性(デモグラフィック)に対しては完全に盲目だ。私たちは誰が優秀かを当てずっぽうで判断しない。その人がどれだけ近いかを測るのだ。
これらのアルゴリズムの完全な技術的詳細——コサイン類似度の背後にある数式や、当社の複合スコアリングモデルを含む——については、当社のリサーチペーパーを参照してほしい。
「SQLが欠けている」瞬間
テスト中に起きたある出来事で、これを具体的に示そう。
私たちは、ある候補者のプロフィールを、標準的なブラックボックス型のリクルーターと、当社のシステムの両方にかけた。ブラックボックスはその候補者を不採用にした。理由は示されなかった。(後にわかったのだが、その候補者は小規模で知名度の低い大学の出身だった——典型的な「学歴(血統)ペナルティ」だ。)
当社のシステムは、こう返した:「候補者は明示的なSQLの経験を欠いている。しかし、グラフ分析はPandas DataFramesおよびR dplyrに関する豊富な経験を示している。DataFramesとSQLの間のグラフ距離は短い(共有概念:データ操作)。推奨:面接。高い転用可能性。」
その候補者——ブラックボックスが捨て去ったその人物——は、その仕事が必要とするすべてのスキルを持っていた。ただ、それを別の言葉で表現していただけだ。そして彼らは、ブラックボックスが訓練データの中で「成功」と見なせるほど十分に見てこなかった学校の出身だった。
私が「ナレッジグラフは人材プールを広げる」と言うのは、こういうことだ。ナレッジグラフは、能力は備えているが、しかるべき学歴や、ぴったり一致する語彙は持たない人々を見つけ出す。そしてそれは、多様性を自然に高める——クォータ(割り当て)や調整によってではなく、よりよい測定を通じて、だ。
システムが問題を検知したとき、何が起こるのか?
人はこう尋ねる。「それでもあなたのシステムがバイアスのある結果を生み出したらどうするのか?」もっともな問いだ。そして私は、自分のシステムは完璧だと主張するような人物のことは、むしろ疑ってかかる。
違いはこうだ。ブラックボックスがバイアスのある結果を生み出すとき、あなたは行き詰まる。数字の中に差別的影響は見えても、その理由は見えない。大学名のせいか?郵便番号か?文体か?あなたは、数百万のパラメータを持ち、判読可能なロジックを持たないシステムをデバッグしているのだ。
当社のシステムが統計的な異常——たとえば、特定の属性グループに対して0.8を下回る影響比率——を生み出したとき、私たちはそれを追跡できる。格差を引き起こしている特定のグラフノードを特定できるのだ。ある職務記述書が、社会経済的地位と相関する、特定の高価な資格を求めているのかもしれない。私たちはそれを見て、フラグを立てることができ、採用チームは、その資格が本当に必要なのか、それとも誰も疑ってこなかった旧来の要件にすぎないのかを判断できる。
ガラスの箱(グラスボックス)は、システムが常に正しいことを意味するのではない。それが間違ったとき、その理由を突き止め、修正できることを意味するのだ。
LLMにもまだ役割はある——ただし、重要な役割ではない
はっきりさせておこう。私たちはLLMを使っている。私たちはラッダイト(機械打ち壊し派)ではない。ただ、私たちがLLMを使うのは、翻訳者を使うのと同じやり方だ——読むことと書くことのためであって、判断のためではない。
当社のアーキテクチャは、厳格な関心の分離(separation of concerns)を徹底している。LLMは知覚を担う:構造化されていない履歴書のテキストを読み、エンティティを抽出する。「私は5人の開発者からなるチームを率いてReact Nativeアプリを構築した」は、構造化データになる——Skill: React Native、Skill: Team Leadership、Context: Mobile Development。LLMは同義語を正規化する:「ReactJS」と「React.js」は、どちらも同じノードにマッピングされる。
しかし、LLMが採用の決定を下すことは決してない。マッチング、スコアリング、ランク付けのすべては、決定論的なグラフ探索を通じて行われる。同じグラフに同じクエリを与えれば、毎回、同じ結果になる。私たちは出力側でもLLMを使う——LLMは人間が読める説明を生成するが、それはグラフによって検証された事実からのみだ。LLMは、グラフが裏付けないスキルのマッチをでっち上げる(ハルシネーションを起こす)ことができない。
私はこう考えている。LLMはシステムの目と口であり、ナレッジグラフは脳だ、と。あなたは、自分の口に自分の決定を任せたりはしないだろう。(まあ、私たちのほとんどは、そうしないはずだ。)
私たちは本当のところ、何と何のあいだで選んでいるのか?
私の見るところ、この業界は分岐点に立っている。一方の道は、より大きなモデル、より多くのパラメータ、より深い不透明さへと通じている——そして、新たな代理変数を次々と見つけては悪用するバイアスとの、終わりのないモグラ叩きへと。もう一方の道は、構造化された推論、意味的な測定、そして規制当局にも、採用担当者にも、不採用となった候補者にも、自らを説明できるシステムへと通じている。
私は、いまだにブラックボックス型のスクリーニングツールを使っている企業のHR責任者たちと話してきた。彼らはリスクを知っている。Amazonのことも読んでいる。だが、アーキテクチャを切り替えるのは高くつき、不確実に感じられるので、彼らはパッチを当て続ける。根本的にバイアスのあるシステムの上に、「バイアス緩和レイヤー」を積み重ねる。何が壊れているかは教えてくれるが、それを直す道具は与えてくれない年次監査を回すために、コンサルタントを雇う。
データは鏡だ。過去のデータでモデルを訓練すれば、過去を再現することになる。公平さを目指す世界において、過去を再現することは、それ自体が失敗の条件なのだ。
私はこれを、あいまいな留保で締めくくるつもりはない。私は何年もかけてこれを構築し、代替となるアプローチが見事に失敗するのを見てきた。そして、この結論に確信を持っている。採用AIの未来とは、過去に誰が成功したかに基づいて、誰が成功するかを予測することではない。それは、ある人にできることと、仕事が求めることとの間の実際の距離を測ること——そしてその測定を、透明で、決定論的で、構造的に差別が不可能なものにすることなのだ。
過去を予測し続けることもできる。あるいは、未来を測り始めることもできる。
