260624_NLP-colloquium: Hubness

Transcript

1. © NTT, Inc. 2026 単一のhubテキストがCLIPを壊す： hubnessによる埋め込みの脆弱性特定 出口 祥之 NTT株式会社 hiroyuki.deguchi@ntt.com • EACL2026 Main採択 • ACL2026 Main採択 • NLP2026 委員特別賞 2026/06/24: NLPコロキウム
2. 2 © NTT, Inc. 2026 自己紹介：出口 祥之 ◼ ポスドク@NTTコミュニケーション科学基礎研究所（CS研） ◼ NLPコロキウム 2回目 • 前回：高速・柔軟パターン検索「SoftMatcha」 ◼ 研究分野 • 機械翻訳、（最近は音声認識も少々） • デコーディング • 近似近傍探索、SoftMatcha • 埋め込みの脆弱性 本日のメイントピック
3. 3 © NTT, Inc. 2026 突然ですが・・・ そのSOTAなモデル、 ◼ 安全ですか？ ◼ 信頼できますか？
4. 4 © NTT, Inc. 2026 突然ですが・・・ そのSOTAなモデル、 ◼ 安全ですか？ ◼ 信頼できますか？ ◼ LLMは…？→ 2026/04/15 金子さん回（おすすめ） ◼ 埋め込みは…？ • ベンチマークの評価指標 • 強化学習の報酬関数 • 情報検索（ベクトル検索）のための類似度計算
5. 5 © NTT, Inc. 2026 今日の内容 today color photo __: dishstaged mms middle ], croc ée ✬ trot maker gely bw 8 boarded <U+FE0F>: garethapproached cision openai/clip-vit-base-patch32によるCLIPScore (CLIP-S) (Hessel+, EMNLP 2021) キャプション/hubテキスト CLIP-S 画像 参照 A couple of young boys with skateboards pass a city bus 0.793 hub today color photo ... 1.012 参照 Cat sitting right next to keyboard on laptop 0.780 hub today color photo ... 0.981 Hessel+, EMNLP 2021, “CLIPScore: A Reference-free Evaluation Metric for Image Captioning”. ◼ 埋め込みにおける脆弱性「hubテキスト」 • どんなデータに対しても高い類似度を示してしまうテキスト hubテキスト
6. 6 © NTT, Inc. 2026 背景：埋め込み ◼ 埋め込み：入力データを高次元空間上のベクトルに変換する写像 • ベクトル同士の類似度により、データ間の意味的類似度を表現 › テキストの表層が全く異なっていても意味的な近さを表現可能：言い換え、類義語、翻訳等 › モダリティ（データの種類）が異なっていても意味的な近さを表現可能 ◼ 応用先 • 情報検索：クエリに対して類似度が高くなるデータを探す • 評価指標：正解データとの意味的な近さを測る 埋め込み 埋め込みベクトル 入力データ
7. 7 © NTT, Inc. 2026 背景：CLIP (Radford+, ICML2021) ◼ 画像とテキストを共有の空間に埋め込む ◼ モダリティをまたいだ（クロスモーダル） 類似度計算が可能 ◼ キャプションの品質評価、画像 テキスト 検索などに応用 Radford+, ICML2021, “Learning Transferable Visual Models From Natural Language Supervision”. “Contrastive Language—Image Pre-training” の略 ⚫ 画像の埋め込みベクトル ⚫ テキストの埋め込みベクトル
8. 8 © NTT, Inc. 2026 Hubness問題 (Radovanović+, JMLR 2010) ◼ 無関係な多くのデータとの類似度が高くなってしまうベクトルがしばしば発生 • 埋め込みに頼らざるを得ないクロスモーダル検索やクロスモーダル評価指標では、 特に問題となりうる ◼ 性質はまだあまり解明されていない • なぜ発生するのか？ • どうすれば発生しないか？ • どんなデータがhubになってしまうのか？ › hubの性質や挙動を理解する上で重要 テキスト Radovanović+, JMLR 2010, “Hubs in Space: Popular Nearest Neighbors in High-Dimensional Data”. ???
9. 9 © NTT, Inc. 2026 hubテキスト探索の難しさ Q. どんなデータがhubになってしまうのか？ • 連続的なデータ（画像等）：勾配降下法によりhubとなるデータを求められる › 多くの無関係なデータとの平均類似度を最大化する勾配を入力データに流す (Zhang+, IEEE S&P 2026) • 離散的なデータ（テキスト等）：勾配降下法がそのまま使えない › 素朴には、とりうる全てのテキストについて「hubになるかどうか」を調べる必要があり、 現実的な時間で探索不能 【詳細】 テキスト Zhang+, IEEE S&P 2026, “Adversarial Hubness in Multi-Modal Retrieval”. ???
10. 10 © NTT, Inc. 2026 研究目的 ◼ hubとなってしまうようなテキスト（hubテキスト）を見つけ、 hubness問題の性質や挙動の理解をめざす • 本トークでは、より問題が顕在化しやすいクロスモーダル埋め込みに着目 • テキスト埋め込みにおけるhubテキスト探索にも応用可能 › 機械翻訳の埋め込みベース評価指標COMETにおけるhubテキストを探索 (Deguchi+, EACL2026) テキスト Deguchi+, EACL2026, “Hacking Neural Evaluation Metrics with Single Hub Text”. ???
11. 11 © NTT, Inc. 2026 hubテキスト探索に向けて ◼ 前述のとおり、テキスト空間全体から探すことは現実時間で実行不能 テキスト空間→埋め込み空間：テキストがhubベクトルに埋め込まれるかどうか調べる テキスト ???
12. 12 © NTT, Inc. 2026 hubテキスト探索に向けて ◼ 前述のとおり、テキスト空間全体から探すことは現実時間で実行不能 テキスト空間→埋め込み空間：テキストがhubベクトルに埋め込まれるかどうか調べる ◼ そこで、問題を逆向きに考える 埋め込み空間→テキスト空間：hubベクトルを求め、それをテキストへと逆変換する テキスト ???
13. 13 © NTT, Inc. 2026 hubテキスト探索に向けて ◼ 前述のとおり、テキスト空間全体から探すことは現実時間で実行不能 テキスト空間→埋め込み空間：テキストがhubベクトルに埋め込まれるかどうか調べる ◼ そこで、問題を逆向きに考える 埋め込み空間→テキスト空間：hubベクトルを求め、それをテキストへと逆変換する ◼ ただし、厳密な逆変換は不能：埋め込みは全射でない • そもそもhubベクトルに対応するテキストが常に存在するとは限らない • 埋め込みの逆関数（のようなもの）をどう作るか？ › 類似度を最大化：hubベクトルのできるだけ近くに埋め込まれるテキストを探索
14. 14 © NTT, Inc. 2026 提案法：hubテキスト探索法 ◼ hubベクトルԦ 𝐡⋆ ∈ ℝ𝐷を特定→Ԧ 𝐡⋆に対応するテキスト𝐡⋆へと逆変換 • 本スライドでは、データ𝑥に対する埋め込みベクトルを Ԧ 𝑥と表す • 探索用データ（画像集合 𝒟 ≔ 𝐈𝑖 𝑖=1 𝒟 ）に対する平均類似度を最大化するテキストを探索 クトル特定 クトル ー 探索 埋め込み空間（連続）での探索 テキスト空間（離散）での探索 クトル モデル テキスト 平均類似度 換
15. 15 © NTT, Inc. 2026 提案法の定式化 ◼ 探索用データ𝒟 ≔ 𝐈𝑖 𝑖=1 𝒟 ⊆ ℐに対する平均類似度ℱを最大化するテキスト 𝐡⋆ ∈ 𝒱∗を探索 𝐡⋆ ≔ argmax 𝐡∈𝒱∗ ℱ 𝑓𝜃 𝐡 ; 𝒟 ℱ Ԧ 𝐡; 𝒟 ≔ 1 𝒟 ෍ 𝐈∈𝒟 𝑠 Ԧ 𝐡, 𝑓𝜃 𝐈 = 1 𝒟 ෍ 𝐈∈𝒟 𝑠 Ԧ 𝐡, Ԧ 𝐈 • ℐ 画像空間 • 𝒱∗ 語彙𝒱のKleene閉包 • 𝑠: ℝ𝐷 × ℝ𝐷 → ℝ ベクトルの類似度関数（cosine類似度など） • 𝑓𝜃 : 𝒱∗ ∪ ℐ → ℝ𝐷 テキスト・画像埋め込み（𝜃 はモデルパラメータ） › つまり、𝑓𝜃 𝐈 = Ԧ 𝐈 • ℱ: ℝ𝐷 × 2 ℐ → ℝ 探索用データに対する平均類似度を計算する関数（目的関数） 【詳細】
16. 16 © NTT, Inc. 2026 提案法：(1) hub クトル特定 ◼ 探索用データ（画像集合）に対する平均類似度 を最大化する𝐷次元hubベクトルԦ 𝐡⋆ ∈ ℝ𝐷を特定 Ԧ 𝐡⋆ = argmax Ԧ 𝐡∈ℝ𝐷 ℱ Ԧ 𝐡; 𝒟 • よく用いられる類似度関数（cosine類似度、内積、 負の二乗Euclid距離）では、解析的に求まる • 類似度関数にニューラルネットワーク等が含まれる 場合は解析解が求められないので、勾配降下法に よって求める クトル
17. 17 © NTT, Inc. 2026 提案法：(2) hub クトル ◼ 特定したhubベクトルから、それに対応する テキストへと復号 • 事前に反転モデル (Morris+, EMNLP 2023) 𝑝𝜙 𝐰 ∣ 𝐰 を訓練 › テキスト 𝐰 ∈ 𝒱∗ と、その埋め込みベクトル 𝐰 = 𝑓𝜃 𝐰 ∈ ℝ𝐷 の 対を用い、埋め込みベクトルから元のテキストへの復元を学習 › 埋め込みの逆関数近似ともいえる モデル Morris+, EMNLP 2023, “Text Embeddings Reveal (Almost) As Much As Text”.
18. 18 © NTT, Inc. 2026 提案法：(2) hub クトル ◼ 特定したhubベクトルから、それに対応する テキストへと復号 • 事前に反転モデル (Morris+, EMNLP 2023) 𝑝𝜙 𝐰 ∣ 𝐰 を訓練 › テキスト 𝐰 ∈ 𝒱∗ と、その埋め込みベクトル 𝐰 = 𝑓𝜃 𝐰 ∈ ℝ𝐷 の 対を用い、埋め込みベクトルから元のテキストへの復元を学習 › 埋め込みの逆関数近似ともいえる ◼ 復号時は、生成確率を最大化せず、目的関数を最大化 • 生成確率を最大化しない：argmax 𝐡∈𝒱∗ 𝑝𝜙 𝐡 ∣ Ԧ 𝐡⋆ • 目的関数 ℱ を最大化：argmax 𝐡∈𝒱∗ ℱ 𝑓𝜃 𝐡 ; 𝒟 › 生成確率にしたがって多様な仮説を大量にサンプリング生成し、 目的関数を最大化する仮説を選択： argmax 𝐡∼𝑝𝜙 ⋅∣Ԧ 𝐡⋆ ℱ 𝑓𝜃 𝐡 ; 𝒟 モデル 最小Bayesリスク復号とほぼ同じ（詳細は割愛） Morris+, EMNLP 2023, “Text Embeddings Reveal (Almost) As Much As Text”.
19. 19 © NTT, Inc. 2026 提案法：(3) ー 探索 ◼ 復号されたテキストを初期解とし、よりԦ 𝐡⋆ の近くに埋め込まれるテキストを探索 ◼ 復号されたテキスト中のトークンを、目的 関数を最大化するトークンに 復的に 換 • 復号されたテキストを始点とし、少しずつԦ 𝐡⋆に 近づけていくような山登り法 • （図は貪欲に 換しているが、実際は）上位𝑘候補 を残しながら枝刈りするビーム探索を採用 テキスト 平均類似度 換
20. 20 © NTT, Inc. 2026 提案法：全体像 ✓ 埋め込み空間上で、探索用 データとの平均類似度（目的 関数）を最大化するベクトル を特定 クトル特定 クトル ー 探索 埋め込み空間（連続）での探索 テキスト空間（離散）での探索 クトル モデル テキスト 平均類似度 換 ✓ (1)で特定したベクトル から、それに対応する テキストへと復号 ✓ (2) で出力されたテキスト中の トークンを、目的関数を最大化 するトークンに、 復的に 換
21. 21 © NTT, Inc. 2026 実験：hubテキスト探索 ◼ 探索用データ：MSCOCO開発セットの画像5,000枚 (Lin+, ECCV 2014) ◼ モデル • 事前訓練済みモデル：multilingual T5 base (Xue+, NAACL 2021) のデコーダ側 • 訓練データ：MSCOCO訓練セットのキャプションテキスト113,287文 • 最適化：AdamW (𝛽1 = 0.9, 𝛽2 = 0.999, 𝜖 = 10−8, 重み減衰：0.01, 学習率：10−5) • パラメータ更新回数：10,000回 ◼ 復号：𝜀サンプリング (𝜀 = 0.02) (Hewitt+, Findings of EMNLP 2022) により4,096個仮説を生成 ◼ ビーム局所探索：ビーム幅𝑘は埋め込みモデルごとに 5,10,20 からチューニング Lin+, ECCV 2014, “Microsoft COCO: Common Objects in Context”. Xue+, NAACL 2021, “mT5: A Massively Multilingual Pre-trained Text-to-Text Transformer”. Hewitt+, Findings of EMNLP 2022, “Truncation Sampling as Language Model Desmoothing”.
22. 22 © NTT, Inc. 2026 実験：画像キャプション評価 ◼ データセット • MSCOCO (Lin+, ECCV 2014) : 探索用データ（MSCOCO valid）と同じドメイン • nocaps (Agrawal+, ICCV 2019) : 探索用データ（MSCOCO valid）と異なるドメイン ◼ モデル：CLIPとその派生10モデル ◼ 評価指標：CLIPScore (Hessel+, EMNLP 2021) ClipS 𝐚, 𝐛 ≔ 2.5 × max cos 𝐚, 𝐛 , 0 次の2つのテキストに対するスコアを比較 • 画像ごとに人間が作った参照キャプション • 画像によらない単一のhubテキスト Lin+, ECCV 2014, “Microsoft COCO: Common Objects in Context”. Agrawal+, ICCV 2019, “nocaps: novel object captioning at scale”. Hessel+, EMNLP 2021, “CLIPScore: A Reference-free Evaluation Metric for Image Captioning”.
23. 23 © NTT, Inc. 2026 探索結果 (openai/clip-vit-base-patch32) today color photo __: dishstaged mms middle ], croc ée ✬ trot maker gely bw 8 boarded <U+FE0F>: garethapproached cision ◼ hubテキスト キャプション/hubテキスト CLIP-S 画像 参照 A couple of young boys with skateboards pass a city bus 0.793 hub today color photo ... 1.012 参照 Cat sitting right next to keyboard on laptop 0.780 hub today color photo ... 0.981 Hessel+, EMNLP 2021, “CLIPScore: A Reference-free Evaluation Metric for Image Captioning”. ◼ 結果：画像と無関係にもかかわらず、単一のhubテキストが参照キャプション より高いCLIPScore (Hessel+, EMNLP 2021) を得てしまっている
24. 24 © NTT, Inc. 2026 実験結果：画像キャプション評価 ◼ 結果：多くのモデルで、単一のhubテキストが、画像ごとに作成された参照 キャプションより平均的に高いスコアを得ている モデル MSCOCO (in-domain) nocaps (out-of-domain) 参照 単一hub 参照 単一hub openai/clip-vit-base-patch32 0.759 0.842 0.758 0.814 openai/clip-vit-large-patch14 0.639 0.649 0.623 0.622 openai/clip-vit-large-patch14-336 0.654 0.701 0.631 0.663 laion/CLIP-ViT-L-14-laion2B-s32B-b82K 0.748 0.782 0.740 0.729 laion/CLIP-ViT-H-14-laion2B-s32B-b79K 0.771 0.825 0.759 0.716 laion/CLIP-ViT-g-14-laion2B-s12B-b42K 0.721 0.747 0.714 0.680 apple/DFN2B-CLIP-ViT-L-14 0.722 0.814 0.712 0.737 apple/DFN5B-CLIP-ViT-H-14 0.838 0.974 0.837 0.841 apple/DFN5B-CLIP-ViT-H-14-378 0.837 1.023 0.841 0.814 BAAI/AltCLIP 0.635 0.643 0.623 0.628
25. 25 © NTT, Inc. 2026 実験結果：hub > 参照 な事例の割合 (%) ◼ 結果 • MSCOCOでは、どのモデルでも過半数（最大9割）の事例でhub > 参照 • nocapsでも3割以上の事例で hub > 参照 モデル MSCOCO nocaps openai/clip-vit-base-patch32 78.6 71.1 openai/clip-vit-large-patch14 54.7 49.5 openai/clip-vit-large-patch14-336 67.7 62.6 laion/CLIP-ViT-L-14-laion2B-s32B-b82K 60.1 44.3 laion/CLIP-ViT-H-14-laion2B-s32B-b79K 65.9 35.4 laion/CLIP-ViT-g-14-laion2B-s12B-b42K 58.2 38.4 apple/DFN2B-CLIP-ViT-L-14 76.6 56.8 apple/DFN5B-CLIP-ViT-H-14 83.9 51.1 apple/DFN5B-CLIP-ViT-H-14-378 90.0 41.1 BAAI/AltCLIP 52.1 51.8 この中では人手評価 との相関が最も強い… (Gomes+, Findings of NAACL2025) Gomes+, Findings of NAACL 2025, “Evaluation of Multilingual Image Captioning: How far can we get with CLIP models?”.
26. 26 © NTT, Inc. 2026 実験：画像→テキスト検索 ◼ 評価：hubテキストがDBに混入したときの検索性能 hubテキストが0件 / 1件 / 1,000件混入したときの性能を比較： • 0件：通常のDBに対する検索性能 • 1件：hubテキストがたった1件だけ混入したDBに対する検索性能 • 1,000件： 1,000件複製したhubテキストが混入したDBに対する検索性能
27. 27 © NTT, Inc. 2026 実験結果：画像→テキスト検索 ◼ 設定 • 埋め込みモデル：openai/clip-vit-base-patch32 • データセット：MSCOCO ◼ 結果 • hubテキストがたった1件でも混入すると検索性能が大幅に低下 NDCG MAP Recall Precision MRR 混入数 @1 @10 @1 @10 @1 @1k @1 @5 @1 @10 0 50.5 44.3 10.1 33.0 10.1 99.0 50.5 34.2 50.5 60.9 1 44.2 42.8 8.8 31.4 8.8 99.0 44.2 33.3 44.2 57.2 1,000 44.1 35.1 8.8 26.3 8.8 52.2 44.1 27.5 44.1 51.5
28. 28 © NTT, Inc. 2026 実験結果：画像→テキスト検索 ◼ 結果：どのモデルでも同様にhubテキストの混入により検索性能が低下
29. 29 © NTT, Inc. 2026 検索デモをご覧ください
30. 30 © NTT, Inc. 2026 CLIPの埋め込み空間上でのhubの性質 ◼ テキストであるにもかかわらず、 画像が密集している付近に埋め込まれている • 画像とテキストでそれぞれモダリティごとに密集 • 意味を考慮することなく、多くの画像との 類似度が高くなってしまう ◼ モダリティギャップ問題 (Liang+, NeurIPS 2022) と関連？ • 空間を広く使えばよいのか？（等方性・異方性） • タスク予測にあまり必要ではないはずのモダリティ情報を 強く保持しすぎている？ Liang+, NeurIPS 2022, “Mind the Gap: Understanding the Modality Gap in Multi-modal Contrastive Representation Learning”. PCA白色化による3次元可視化
31. 31 © NTT, Inc. 2026 hub対策 ◼ hubの影響を軽減 • モデルアンサンブル • 複数データに対する類似度平均を差し引く (Chowdhury+, EMNLP2024) ◼ 脆弱性対策 • サービス用のモデルを公開しない：順伝播計算できなければ探索法が適用できない • DB追加は慎重に：データをDBに追加するときはチェックやテストを挟む等 • 信頼できるソースに絞る Chowdhury+, EMNLP2024, “Nearest Neighbor Normalization Improves Multimodal Retrieval”.
32. 32 © NTT, Inc. 2026 本研究を通して思ったこと ◼ ベンチマーク性能が高い ≠ 脆弱性に対して頑健 • 「綺麗な評価セットに対する平均性能の高さ」だけを求めるべきか？ • テールリスク、クラッキングなどに対する耐久性は？ ◼ （研究者向け）単一の評価指標だけを過度に信頼しないことが重要 • ベンチマーク競争だけでなく、強化学習の報酬関数などでも同様（報酬ハック問題） › 気をつけていても現実世界でSEOハックが無くならないことから、難しい問題ではある ◼ （個人的興味）hubのような、ある意味極端な挙動を観察することで、 これまで見えなかったNNの内部機序の解明や性質理解に繋がらないか…？
33. 33 © NTT, Inc. 2026 本研究を始めた経緯・ACL採択まで (1) ◼ 博士課程時代：研究・開発で大規模な ベクトル検索を扱っていた • NII/LLMセンタにて、LLMの訓練コーパスを 検索するためのベクトルDBを構築していた • クエリによらず検索結果の上位によく現れて しまう謎のデータの存在に悩まされていた › 根本的な解決法はなく、場当たり的に対処 【余談】 清丸さん@NII/LLMC の検索クエリ
34. 34 © NTT, Inc. 2026 本研究を始めた経緯・ACL採択まで (2) ◼ 2024年末～2025年初：NLP2025 WS「LLM時代のことばの評価の現在と未来」 • 2024年の年末くらいに主催者の須藤さんのツイートを見かける： Shared Taskは自動評価の頑健性（脆弱性）の検証を目的として、「いかにうまく自動評価を騙せるか」 という観点で機械翻訳と文法誤り訂正のタスクを実施します。 › 機械翻訳の研究でよく使っている埋め込みベースの評価指標COMET（翻訳文と参照訳文との 埋め込みベクトルの近さを測るモデル）がshared taskの対象 • ひらめく › あの厄介なhubテキストがもし作れてしまったら、たった一つのhubテキストを吐き続けるだけで SOTAなスコアを達成できてしまうのでは…？ › 評価指標や報酬関数の脆弱性にもなるので、実は真面目に向き合わないといけない問題…？ • shared taskは約2か月程度。実装・実験、さまざまなアイデアを試し、締切の直前まで戦った。 • 頑張った甲斐があり、我々チーム「きょなら」がBest Hacking Award受賞、盛り上がった 【余談】
35. 35 © NTT, Inc. 2026 本研究を始めた経緯・ACL採択まで (3) ◼ 2025年前半～半ば：論文化に苦しむ • NLP2025 WSだけで終わらせず、論文化をめざす • しかし、 ARR2025 May, July と、2連続reject › 好みがかなり分かれる研究でもあり、評価は二極化 • 査読コメントを 映してresubmissionを重ね、なんとかEACL2026に採択 › 後になって振り返ると、コアとなるアイデアは面白いものの、「研究の位 づけ」や「どういう問 題を見据えているのか」という視点が弱かった › 特にコメント「テキスト同士の類似度だと、文字列一致に基づく表層類似度を使えば、ある程度 フィルタリングできるから、問題はそこまで深刻でないのでは？」が結構クリティカルだった 【余談】
36. 36 © NTT, Inc. 2026 本研究を始めた経緯・ACL採択まで (4) ◼ 2025年後半～2026年初：ACL採択へ • EACLでやり残したことや、根本的な問題設定を考え直し、この研究を完遂することを決意 › 問題設定を見直す：クロスモーダル検索・評価では、表層の比較ができないため、問題がより深刻 › 手法を改善する：EACL論文と比べて明確に新規性と呼べる差分を作り改良 › 議論を深める：分析から何がわかり今後何に繋がるのかまで議論する。「hubはこういう性質を持 つことがわかったので、今後こういう観点から問題解決に繋がる可能性がある」など • rebuttalもかなり頑張り、2.5/3.5/3→3/4/4 • その後、無事採択 【余談】
37. 37 © NTT, Inc. 2026 まとめ ◼ 提案：hubテキストの探索法 ◼ 実験結果：hubテキストがさまざまなタスクで悪影響を及ぼすことを確認 • 画像キャプション評価（MSCOCO、nocaps）：単一のhubテキストが、多くの無関係な 画像に対し、参照キャプションより不当に高いCLIPScoreを得た • 画像・テキスト検索（MSCOCO、Flickr30k）：hubテキストがDBに混入すると検索性能が 大幅に低下 ◼ 今後の課題：hubテキストの性質や発生原因を明らかにし、hubness問題の 根本的な解決をめざす 共同研究等、気軽にご相談ください！