Update README.md

README.md

@@ -23,25 +23,25 @@ datasets:
 library_name: sentence-transformers
 ---
 
-以下の文章は、ブログ記事⭐️からの転載です。
+以下の文章は、ブログ記事[100倍速で実用的な文章ベクトルを作れる、日本語 StaticEmbedding モデルを公開](https://secon.dev/entry/2025/01/21/060000-static-embedding-japanese/)からの転載です。
 
-# 100倍速で実用的な文章ベクトルを作れる、日本語 StaticEmbedding を公開
+# static-embedding-japanese
 
 文章の密ベクトルは、情報検索・文章判別・類似文章抽出など、さまざまな用途に使うことができます。しかしながら最先端のTransformerモデルは小さいモデルでも、とりわけCPUでは遅く、変換速度が実用でないこともしばしばです。
 
-しかしながら、先日公開されたTransformerモデル「ではない」 [StaticEmbedding](https://huggingface.co/blog/static-embeddings)は、例えば [intfloat/multilingual-e5-small](https://huggingface.co/intfloat/multilingual-e5-small) (以下mE5-small)とのベンチマーク比較では85%のスコアという実用できる性能で、かつCPUで動作時に126倍高速に文ベクトルを作成することができる、という驚きの速度です。
+しかしながら、先日公開されたTransformerモデル「ではない」 [StaticEmbeddingモデル](https://huggingface.co/blog/static-embeddings)は、例えば [intfloat/multilingual-e5-small](https://huggingface.co/intfloat/multilingual-e5-small) (以下mE5-small)とのベンチマーク比較では85%のスコアという実用できる性能で、かつCPUで動作時に126倍高速に文ベクトルを作成することができる、という驚きの速度です。
 
 というわけで、早速日本語(と英語)で学習させたモデル sentence-embedding-japanese を作成し、公開しました。
 
 - https://huggingface.co/hotchpotch/static-embedding-japanese
 
-日本語の文章ベクトルの性能を評価する JMTEB の結果は以下です。確かに mE5-small には若干及ばないまでも、タスクによっては勝っていたりしますし、[他の日本語baseサイズbertモデルよりもスコアが高いこともある](https://github.com/sbintuitions/JMTEB/blob/main/leaderboard.md)ぐらい、最低限実用に達している性能が出ていますね。本当にそんなに性能出るのか実際に学習させてみるまで半信半疑でしたが、すごいですね。
+日本語の文章ベクトルの性能を評価する [JMTEB](https://github.com/sbintuitions/JMTEB) の結果は以下です。総合スコアでは mE5-small には若干及ばないまでも、タスクによっては勝っていたりしますし、[他の日本語baseサイズbertモデルよりもスコアが高いこともある](https://github.com/sbintuitions/JMTEB/blob/main/leaderboard.md)ぐらい、最低限実用に達している性能が出ていますね。本当にそんなに性能出るのか実際に学習させてみるまで半信半疑でしたが、すごいですね。
 
 | Model                                    | Avg(micro) | Retrieval | STS   | Classification | Reranking | Clustering | PairClassification |
 | ---------------------------------------- | ---------- | --------- | ----- | -------------- | --------- | ---------- | ------------------ |
 | text-embedding-3-small            | 69.18      | 66.39     | 79.46 | 73.06          | 92.92     | 51.06      | 62.27              |
 | multilingual-e5-small           | 67.71      | 67.27     | 80.07 | 67.62          | 93.03     | 46.91      | 62.19              |
-| **static-embedding-japanese** | 66.66  | **67.92**     | **80.16** | **67.96**          | 91.87     | 35.83      | **62.37**              |
+| **static-embedding-japanese** | 67.17  | **67.92**     | **80.16** | **67.96**          | 91.87     | 40.39      | **62.37**              |
 
 
 なお、StaticEmbedding 日本語モデル学習などの技術的なことは記事の後半に書いているので、興味がある方はどうぞ。
@@ -99,15 +99,15 @@ StaticEmbedding はTransformerモデルではありません。つまりTrasform
 
 ## 評価結果
 
-JMTEBでの全ての評価結果は[こちらJSONファイルに記載](https://huggingface.co/hotchpotch/static-embedding-japanese/blob/main/JMTEB/summary.json)しています。[JMTEB Leaderboard](https://github.com/sbintuitions/JMTEB/blob/main/leaderboard.md)で見比べると、差がわかるでしょう。JMTEBの全体の評価結果はモデルサイズを考えると、すこぶる良好です。なお、JMTEB で評価された方は、mr-tidy タスクの700万文章のベクトル化に時間がかなりかかる(モデルにもよりますがRTX4090で1~4時間ほど)と思います。これもStaticEmbeddingsでは非常に速く、RTX4090では約4分で処理終えることができました。
+JMTEBでの全ての評価結果は[こちらJSONファイルに記載](https://huggingface.co/hotchpotch/static-embedding-japanese/blob/main/JMTEB/summary.json)しています。[JMTEB Leaderboard](https://github.com/sbintuitions/JMTEB/blob/main/leaderboard.md)で他のモデルと見比べると、相対的な差がわかるでしょう。JMTEBの全体の評価結果はモデルサイズを考えると、すこぶる良好です。なお、JMTEB で評価された方は、mr-tidy タスクの700万文章のベクトル化に時間がかなりかかる(モデルにもよりますがRTX4090で1~4時間ほど)と思います。これもStaticEmbeddingsでは非常に速く、RTX4090では約4分で処理終えることができました。
 
 ### 情報検索でBM25の置き換えができそうか?
 
-JMTEBの中の情報検索タスクの[Retrievalの結果](https://huggingface.co/hotchpotch/static-embedding-japanese/blob/main/JMTEB/summary.json)を見てみましょう。StaticEmbedding では mr-tidy の項目が著しく悪いですね。mr-tidyは他のタスクに比べて文章量が圧倒的に多く(700万文章)、つまる所大量の文章を検索するようなタスクでは結果が悪い可能性がありそうです。文脈を無視したた単純なトークンの平均なので、増えれば増えるほど似た平均の文章が出てくるとすると、そういう結果にもなり得そうですね。
+JMTEBの中の情報検索タスクの[Retrievalの結果](https://huggingface.co/hotchpotch/static-embedding-japanese/blob/main/JMTEB/summary.json#L21-L39)を見てみましょう。StaticEmbedding では mr-tidy の項目が著しく悪いですね。mr-tidyは他のタスクに比べて文章量が圧倒的に多く(700万文章)、つまる所大量の文章を検索するようなタスクでは結果が悪い可能性がありそうです。文脈を無視したた単純なトークンの平均なので、増えれば増えるほど似た平均の文章が出てくるとすると、そういう結果にもなり得そうですね。
 
 ので、大量の文章の場合、BM25よりもだいぶ性能が悪い可能性がありそうです。ただ、少ない文章で、ずばりの単語マッチが少ない場合は、BM25よりも良好な結果になることが多そうですね。
 
-なお情報検索タスクの jaqket の結果が他のモデルに対してやたら良いのは、JQaRa (dev, unused)を学習しているからといっても高すぎる感じで謎です。test の情報リークはしていないとは思うのですが…。
+なお情報検索タスクの jaqket の結果が他のモデルに対してやたら良いのは、jaqket の問題を含む JQaRa (dev, unused)を学習しているからといっても、高すぎる感じで謎です。test の情報リークはしていないとは思うのですが…。
 
 ### クラスタリング結果が悪い
 
@@ -133,7 +133,7 @@ JMTEBの中の情報検索タスクの[Retrievalの結果](https://huggingface.c
 
 JQaRa 評価は BM25 よりは若干良く、mE5-small よりは若干低い、JaCWIR は BM25, mE5よりだいぶ低い感じの結果になりました。
 
-JaCWIR はWeb文章のタイトルと概要文なので、いわゆる「綺麗な」文章ではないケースも多く、transformerモデルはノイズに強いので、単純なトークン平均のStaticEmbeddingでは悪い結果になりそうです。BM25は特徴的な単語にマッチしやすいので、JaCWIR でもノイズとなるような単語はクエリにマッチしないため、Transformer モデルと競争力のある結構良い結果を残します。
+JaCWIR はqueryから探しあてる文章が、Web文章のタイトルと概要文なので、いわゆる「綺麗な」文章ではないケースも多いです。transformerモデルはノイズに強いので、単純なトークン平均のStaticEmbeddingではスコアに差がつけられるのも納得ですね。BM25は特徴的な単語が出現した文章にマッチするので、JaCWIR でもノイズとなるような文章上の単語はクエリにそもそもマッチしないため、Transformer モデルと競争力のある結構良い結果を残しています。
 
 この結果から、StaticEmbedding は Transformer / BM25 に比べ、ノイズを多く含む文章の場合はスコアが悪い可能性があります。
 
@@ -147,6 +147,28 @@ MRLは、学習時に先頭のベクトルほど重要な次元を持ってく
 
 このグラフ参照元の[StaticEmbedding の記事](https://huggingface.co/blog/static-embeddings#matryoshka-evaluation)によると、128次元で91.87%, 256次元で95.79%, 512次元で98.53%の性能を維持しているようです。精度にそこまでシビアではないが、その後の計算コストを下げたい場合、ガッと次元削減して使う、という用途にも使えそうですね。
 
+
+### StaticEmbdding 日本語モデルでの次元削減結果
+
+JMTEB では、出力時にモデルのパラメータを制御できるため、truncate_dim オプションを渡すことで、次元削減した結果のベンチ��ークも簡単に計測できます。素晴らしいですね。というわけで、StaticEmbdding 日本語モデルでも、次元削減した結果でベンチマークをとってみました。
+
+| 次元数 | Avg(micro) | スコア割合(%) | Retrieval | STS   | Classification | Reranking | Clustering | PairClassification |
+|--------|------------|---------------|-----------|-------|----------------|-----------|------------|---------------------|
+| 1024  | 67.17      | 100.00     | 67.92     | 80.16 | 67.96          | 91.87     | 40.39      | 62.37               |
+| 512   | 56.65      | 84.34      | 47.85     | 80.11 | 55.57          | 88.27     | 43.11      | 62.37               |
+| 256   | 65.94      | 98.17      | 66.99     | 79.93 | 63.53          | 91.73     | 42.55      | 62.37               |
+| 128   | 64.25      | 95.65      | 64.87     | 79.56 | 60.52          | 91.62     | 41.81      | 62.33               |
+| 64    | 61.79      | 91.98      | 61.15     | 78.34 | 58.23          | 91.50     | 39.11      | 62.35               |
+| 32    | 57.93      | 86.24      | 53.35     | 76.51 | 55.95          | 91.15     | 38.20      | 62.37               |
+
+
+スコアの変化を見ると、512次元へと次元削減した場合はやたらRetrieval, Classification,Reranking の性能が悪くなります。むしろ256次元まで次元削減してしまった方が良好な結果に。256次元では、スコア的には次元削減する前のモデルの98.93%なんですが、これはクラスタリングの結果がなぜか1024次元よりも良くなってしまったためですね。
+
+クラスタリングタスクにおいては128次元まで次元削減しても1024次元よりもスコアが高い、という本来情報量を削らない方がスコアが良いくなりそうなのに、クラスタリングタスクのみは逆にスコアが上がってしまう興味深い結果となりました…。マトリョーシカ表現学習では、先頭の次元の方が全体的な特徴を踏まえているので、クラスタリング用途には(クラスタリングのアルゴリズムにもよると思いますが)、特徴的な前の方の次元のみで後ろの次元を使わない方が良質な結果が得られる、ということなのかもしれません。
+
+というわけで、static-embedding-japanese モデルで次元削減する時は、256,128次元あたりが性能と次元削減のバランスが取れてそうですね。逆に512次元はとりわけRetrievalの結果が悪いので、使わない方が良さそうです。
+
+
 ## StaticEmbedding モデルを作ってみて
 
 正直、単純なトークンのembeddingsの平均でそんなに性能出るのか半信半疑だったのですが、実際に学習させてみてシンプルなアーキテクチャなのに性能の高さにびっくりしました。Transformer 全盛のこの時代に、古き良き単語埋め込みの活用モデルで、実世界で利活用できそうなモデルの出現に驚きを隠せません。
@@ -247,7 +269,7 @@ StaticEmbedding を学習するためには、HuggingFace のトークナイザ
 - memory
   - 64GB
 
-このマシンリソースでの学習にかかった時間は約4時間でした。GPUのコア負荷は非常に小さく、他のtransformerモデルでは学習時に90%前後で張り付くのに対して、StaticEmbeddingではほとんど0%でした。これは、巨大なバッチをGPUメモリに転送する時間が大半を占めているためかと思われます。そのため、GPUメモリの帯域幅が速くなれば、学習速度がさらに向上する可能性があります。
+このマシンリソースで、フルスクラッチ学習にかかった時間は約4時間でした。GPUのコア負荷は非常に小さく、他のtransformerモデルでは学習時に90%前後で張り付くのに対して、StaticEmbeddingではほとんど0%でした。これは、巨大なバッチをGPUメモリに転送する時間が大半を占めているためかと思われます。そのため、GPUメモリの帯域幅が速くなれば、学習速度がさらに向上する可能性があります。
 
 ## さらなる性能向上へ
 
@@ -263,4 +285,4 @@ StaticEmbedding を学習するためには、HuggingFace のトークナイザ
 
 ## ライセンス
 
-static-embedding-japanese は MIT ライセンスで公開しています。
+static-embedding-japanese はモデル重み・学習コードを MIT ライセンスで公開しています。