hotchpotch
commited on
Update README.md
Browse filesfixed 512-dims JMTEB scores
README.md
CHANGED
@@ -24,10 +24,9 @@ library_name: sentence-transformers
|
|
24 |
|
25 |
# static-embedding-japanese
|
26 |
|
27 |
-
|
28 |
文章の密ベクトルは、情報検索・文章判別・類似文章抽出など、さまざまな用途に使うことができます。しかしながら最先端のTransformerモデルは小さいモデルでも、とりわけCPU環境では処理速度が遅いため実用でないこともしばしばあります。
|
29 |
|
30 |
-
|
31 |
|
32 |
というわけで、早速日本語(と英語)で学習させたモデル sentence-embedding-japanese を作成し、公開しました。
|
33 |
|
@@ -185,20 +184,21 @@ JMTEB では、出力時にモデルのパラメータを制御できるため
|
|
185 |
|
186 |
| 次元数 | Avg(micro) | スコア割合(%) | Retrieval | STS | Classification | Reranking | Clustering | PairClassification |
|
187 |
|--------|------------|---------------|-----------|-------|----------------|-----------|------------|---------------------|
|
188 |
-
| 1024 | 67.17 | 100.00
|
189 |
-
| 512 |
|
190 |
-
| 256 | 65.94 | 98.17
|
191 |
-
| 128 | 64.25 | 95.65
|
192 |
-
| 64 | 61.79 | 91.98
|
193 |
-
| 32 | 57.93 | 86.24
|
194 |
|
195 |
|
196 |
-
|
197 |
|
198 |
-
|
199 |
|
200 |
-
|
201 |
|
|
|
202 |
|
203 |
## StaticEmbedding モデルを作ってみて
|
204 |
|
|
|
24 |
|
25 |
# static-embedding-japanese
|
26 |
|
|
|
27 |
文章の密ベクトルは、情報検索・文章判別・類似文章抽出など、さまざまな用途に使うことができます。しかしながら最先端のTransformerモデルは小さいモデルでも、とりわけCPU環境では処理速度が遅いため実用でないこともしばしばあります。
|
28 |
|
29 |
+
この課題を解決する新しいアプローチとして、先日公開されたTransformerモデル「ではない」 [StaticEmbeddingモデル](https://huggingface.co/blog/static-embeddings)は、例えば [intfloat/multilingual-e5-small](https://huggingface.co/intfloat/multilingual-e5-small) (以下mE5-small)とのベンチマーク比較では85%のスコアという最低十分な性能で、何よりCPUで動作時に126倍高速に文ベクトルを作成することができる、という驚きの速度です。
|
30 |
|
31 |
というわけで、早速日本語(と英語)で学習させたモデル sentence-embedding-japanese を作成し、公開しました。
|
32 |
|
|
|
184 |
|
185 |
| 次元数 | Avg(micro) | スコア割合(%) | Retrieval | STS | Classification | Reranking | Clustering | PairClassification |
|
186 |
|--------|------------|---------------|-----------|-------|----------------|-----------|------------|---------------------|
|
187 |
+
| 1024 | 67.17 | 100.00 | 67.92 | 80.16 | 67.96 | 91.87 | 40.39 | 62.37 |
|
188 |
+
| 512 | 66.57 | 99.10 | 67.63 | 80.11 | 65.66 | 91.54 | 41.25 | 62.37 |
|
189 |
+
| 256 | 65.94 | 98.17 | 66.99 | 79.93 | 63.53 | 91.73 | 42.55 | 62.37 |
|
190 |
+
| 128 | 64.25 | 95.65 | 64.87 | 79.56 | 60.52 | 91.62 | 41.81 | 62.33 |
|
191 |
+
| 64 | 61.79 | 91.98 | 61.15 | 78.34 | 58.23 | 91.50 | 39.11 | 62.35 |
|
192 |
+
| 32 | 57.93 | 86.24 | 53.35 | 76.51 | 55.95 | 91.15 | 38.20 | 62.37 |
|
193 |
|
194 |
|
195 |
+
~~スコアの変化を見ると、512次元へと次元削減した場合はやたらRetrieval, Classification,Reranking の性能が悪くなります。むしろ256次元まで次元削減してしまった方が良好な結果に。256次元では、スコア的には次元削減する前のモデルの98.93%なんですが、これはクラスタリングの結果がなぜか1024次元よりも良くなってしまったためですね。~~
|
196 |
|
197 |
+
512次元でのスコア計測が間違っていたので修正しました。マトリ���ーシカ表現学習がうまく反映され、次元数を削ると若干のスコア低下が見られますが、次元数が減ったためその後のコストが抑えられそうですね。
|
198 |
|
199 |
+
クラスタリングタスクにおいては128次元まで次元削減しても1024次元よりもスコアが高い、という本来情報量を削らない方がスコアが良いくなりそうなのに、クラスタリングタスクのみは逆にスコアが上がってしまう興味深い結果となりました…。マトリョーシカ表現学習では、先頭の次元の方が全体的な特徴を踏まえているので、クラスタリング用途には(クラスタリングのアルゴリズムにもよると思いますが)、特徴的な前の方の次元のみで後ろの次元を使わない方が良質な結果が得られる、ということなのかもしれません。
|
200 |
|
201 |
+
というわけで、static-embedding-japanese モデルで次元削減する時は、512,256,128次元あたりが性能と次元削減のバランスが取れてそうですね。
|
202 |
|
203 |
## StaticEmbedding モデルを作ってみて
|
204 |
|