prithivida
commited on
Commit
•
3f34dd1
1
Parent(s):
473551f
Update README.md
Browse files
README.md
CHANGED
@@ -74,12 +74,12 @@ SPLADE models are a fine balance between retrieval effectiveness (quality) and r
|
|
74 |
|
75 |
**TL;DR of Our attempt & results**
|
76 |
1. FLOPS tuning: Seperate **Seq lens and Severely restrictive FLOPs schedule and token budget** doc(128) & query(24) NOT 256 unlike Official SPLADE++. Inspired from **SparseEmbed**
|
77 |
-
3. Init Weights:
|
78 |
-
4. Yet achieves competitive effectiveness of MRR@10 **37.
|
79 |
4. For Industry setting: Effectiveness on custom domains needs more than just **Trading FLOPS for tiny gains** and The Premise "SPLADE++ are not well suited to mono-cpu retrieval" does not hold.
|
80 |
5. Owing to query-time inference latency we still need 2 models one for query & doc, This is a Doc model and Query model will be **released soon.**
|
81 |
|
82 |
-
<img src="./ID.png" width=
|
83 |
|
84 |
*Note: The paper refers to the best performing models as SPLADE++, hence for consistency we are reusing the same.*
|
85 |
|
@@ -130,7 +130,7 @@ This is why Google's SparseEmbed is interesting as they also achieve SPLADE qual
|
|
130 |
document terms with a linear complexity as ColBERT’s late interaction i.e. all query-document term pairs takes a quadratic complexity. The Challenge with SparseEmbed is it uses a hyperparameter called **Top-k to restrict number of tokens used to learn contextual dense representations.** Say 64 and 256 tokens for query and passage encoding.
|
131 |
But it is unclear how well these hyperparameters are transferable to other domains or languages (where the notion of tokens changes a lot like our mother tongue Tamil which is Agglutinative in nature).
|
132 |
|
133 |
-
<img src="./Metrics.png" width=
|
134 |
|
135 |
<details>
|
136 |
|
@@ -251,7 +251,7 @@ print("SPLADE BOW rep:\n", bow_rep)
|
|
251 |
```
|
252 |
|
253 |
## BEIR Zeroshot OOD performance:
|
254 |
-
<img src="./
|
255 |
|
256 |
|
257 |
## Training details:
|
|
|
74 |
|
75 |
**TL;DR of Our attempt & results**
|
76 |
1. FLOPS tuning: Seperate **Seq lens and Severely restrictive FLOPs schedule and token budget** doc(128) & query(24) NOT 256 unlike Official SPLADE++. Inspired from **SparseEmbed**
|
77 |
+
3. Init Weights: **Middle Trained bert-base-uncased with MLM Loss**. Some corpus awarness like Official splade++ / ColBERT
|
78 |
+
4. Yet achieves competitive effectiveness of MRR@10 **37.8** in ID data (& OOD) and a retrieval latency of - **48.27ms**. (multi-threaded) all On **Consumer grade-GPUs** with **only 5 negatives per query**.
|
79 |
4. For Industry setting: Effectiveness on custom domains needs more than just **Trading FLOPS for tiny gains** and The Premise "SPLADE++ are not well suited to mono-cpu retrieval" does not hold.
|
80 |
5. Owing to query-time inference latency we still need 2 models one for query & doc, This is a Doc model and Query model will be **released soon.**
|
81 |
|
82 |
+
<img src="./ID.png" width=850 height=750/>
|
83 |
|
84 |
*Note: The paper refers to the best performing models as SPLADE++, hence for consistency we are reusing the same.*
|
85 |
|
|
|
130 |
document terms with a linear complexity as ColBERT’s late interaction i.e. all query-document term pairs takes a quadratic complexity. The Challenge with SparseEmbed is it uses a hyperparameter called **Top-k to restrict number of tokens used to learn contextual dense representations.** Say 64 and 256 tokens for query and passage encoding.
|
131 |
But it is unclear how well these hyperparameters are transferable to other domains or languages (where the notion of tokens changes a lot like our mother tongue Tamil which is Agglutinative in nature).
|
132 |
|
133 |
+
<img src="./Metrics.png" width=1000/>
|
134 |
|
135 |
<details>
|
136 |
|
|
|
251 |
```
|
252 |
|
253 |
## BEIR Zeroshot OOD performance:
|
254 |
+
<img src="./splade_v2.png" width=100%/>
|
255 |
|
256 |
|
257 |
## Training details:
|