{
  "id": 258554,
  "title": "6th place solution (Gaussian process regression (GPR))",
  "content": "<h3>Acknowledgement</h3>\n<p>First of all, we would like to thanks Kaggle &amp; CommonLit for hosting this interesting competition, this has been an interesting journey for us! Also congratulations to all winning teams!</p>\n<p>And special thanks to <a href=\"https://www.kaggle.com/rhtsingh\" target=\"_blank\">@rhtsingh</a>, <a href=\"https://www.kaggle.com/maunish\" target=\"_blank\">@maunish</a>, and <a href=\"https://www.kaggle.com/andretugan\" target=\"_blank\">@andretugan</a> for their knowledgeable and resourceful notebooks. Since our team is fairly new to transformers, leveraging the resources from public notebooks definitely helps in our journey!</p>\n<h3>Summary</h3>\n<p>Our final submission consists of 9 transformer models, and our final solution is based on our 2nd-stage model Gaussian Process Regression (GPR) [1] which we use to correct overconfident transformer predictions due to the small training data. This can be summarized in two steps. </p>\n<ol>\n<li>Extract all the OOF embeddings from the last transformer layer (Attention-head) for all 9 models and concatenate all of them.</li>\n<li>Train a GPR model using the concatenated embeddings. </li>\n</ol>\n<h3>Architecture for final solution</h3>\n<p><img src=\"https://i.imgur.com/ANcnHNt.png\"></p>\n<h3>External data</h3>\n<p>We scraped data from the “url_legal” information which is available in the training data and only use those with licenses of “CC BY” and “CC BY-SA”.</p>\n<h4>Transformers model</h4>\n<p>Like every other team, we first started out fine-tuning transformers model and focus on increasing the single model LB score by training different transformers for diversity. Since our goal is to use GPR to improve the transformer predictions, we need robust transformer models that can generate robust embeddings.</p>\n<p>Our final submission consists of the following 9 transformer models and all models are trained using 5-fold stratified CV with attention head.</p>\n<table>\n<thead>\n<tr>\n<th>Model</th>\n<th>CV</th>\n<th>Public</th>\n<th>Private</th>\n<th>Notes</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>roberta-large</td>\n<td>0.492</td>\n<td>0.471</td>\n<td>0.471</td>\n<td>mlm on training set</td>\n</tr>\n<tr>\n<td>microsoft/deberta-large</td>\n<td>0.485</td>\n<td>0.474</td>\n<td>0.476</td>\n<td>mlm on training set</td>\n</tr>\n<tr>\n<td>xlnet-large-cased</td>\n<td>0.494</td>\n<td>0.475</td>\n<td>0.476</td>\n<td>-</td>\n</tr>\n<tr>\n<td>deepset/roberta-large-squad2</td>\n<td>0.488</td>\n<td>0.464</td>\n<td>0.467</td>\n<td>-</td>\n</tr>\n<tr>\n<td>deepset/roberta-large-squad2</td>\n<td>0.484</td>\n<td>0.466</td>\n<td>0.464</td>\n<td>mlm on train set and external data</td>\n</tr>\n<tr>\n<td>allenai/longformer-large-4096-finetuned-triviaqa</td>\n<td>0.489</td>\n<td>0.467</td>\n<td>0.47</td>\n<td>-</td>\n</tr>\n<tr>\n<td>valhalla/bart-large-finetuned-squadv1</td>\n<td>0.471</td>\n<td>0.462</td>\n<td>0.466</td>\n<td>mlm on train set and external data, remove dropout</td>\n</tr>\n<tr>\n<td>microsoft/deberta-large-mnli</td>\n<td>0.469</td>\n<td>0.462</td>\n<td>0.469</td>\n<td>mlm on train set and external data, remove dropout</td>\n</tr>\n<tr>\n<td>ahotrod/electra_large_discriminator_squad2_512</td>\n<td>0.477</td>\n<td>0.468</td>\n<td>0.468</td>\n<td>remove dropout</td>\n</tr>\n</tbody>\n</table>\n<p>The model selection is based on the individual LB score (preferably &lt;= 0.475)</p>\n<h3>Fine-tune</h3>\n<p>The following are the fine-tuned strategy for the transformer models</p>\n<ul>\n<li>Epochs: 5</li>\n<li>Batch Size: 8</li>\n<li>Optimizer: AdamW with SWA</li>\n<li>LR Scheduler: Linear learning rate scheduler with 6% warmup steps</li>\n<li>Learning rate: 2e-5</li>\n<li>Layer reinitialisation: last 3 transformer layers (reference: <a href=\"https://www.kaggle.com/rhtsingh/on-stability-of-few-sample-transformer-fine-tuning\" target=\"_blank\">https://www.kaggle.com/rhtsingh/on-stability-of-few-sample-transformer-fine-tuning</a>)<br>\nUse attention head. (reference: <a href=\"https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune\" target=\"_blank\">https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune</a>)</li>\n<li>Evaluating for every n steps: 10</li>\n</ul>\n<h3>Gaussian Process Regression (GPR)</h3>\n<p>We are aware of the limited training samples ~2.8k, hence we immediately thought of Gaussian process regression (GPR). Given the constraint of limited training samples, using Bayesian techniques such as GPR could potentially help us make a better approximation/prediction. Since Bayesian/Probabilistic model are proven to performs relatively well in small setting, and it also has a strong notion of uncertainty. The uncertainty is important here as we know the distribution of the training and test data are different, and we do not want the transformer to make overconfident predictions, hence GPR alleviates overconfident predictions from transformers. <strong>A NN with one hidden layer of infinite width is basically a Gaussian Processes.</strong></p>\n<p>The below figure shows the deberta-large model predictions for 100 randomly sampled points. The green curve is the deberta-large predictions, and the red curve is the GPR predictions. We can see that deberta-large will try to fit all the points as closely as possible (Red circle), however, GPR will avoid overconfident predictions and will regress to the mean of nearby samples when it is not confident, thus providing reliable uncertainty estimation.</p>\n<p><img src=\"https://i.imgur.com/yMlaKpG.png\"></p>\n<h3>Gaussian process regression (GPR) as 2nd-stage model</h3>\n<p>We use GPR to correct overconfident transformer predictions. Doing this allows us to further improved the single model score significantly by training a GPR model using all the OOF embeddings extracted from the last transformer layer (attention-head). </p>\n<p>The following submission shows that using deberta-large trained with pseudo-labeling (PL) can achieve a single private score of 0.459, but with GPR it can achieve 0.453 alone!</p>\n<table>\n<thead>\n<tr>\n<th>Model</th>\n<th>CV</th>\n<th>Public</th>\n<th>Private</th>\n<th>GPR Public</th>\n<th>GPR private</th>\n<th>Notes</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>deberta-large</td>\n<td>0.462</td>\n<td>0.465</td>\n<td><b>0.459</b></td>\n<td>0.457</td>\n<td><b>0.453</b></td>\n<td>train with pseudo labeling</td>\n</tr>\n</tbody>\n</table>\n<p>Unfortunately, we didn't include any model trained with pseudo-labeling since many of our PL-trained models has bad single/ensemble LB score as compared to the model trained without pseudo-labeling.. </p>\n<p>This leads us to believe the LB has a different data distribution as compared to the training data, hence we use all the OOF embeddings for training and only validate the individual GPR model performance on LB.   </p>\n<h3>Training GPR using all oof embeddings</h3>\n<p>From the transformer models section above, the 9 models were selected in terms of their individual LB scores and correlations for diversity. We extracted the attention head embeddings which is of size 1024 for each model, hence 1024*9 embeddings for 9 models. We concatenate all 1024*9 embeddings and train all samples using GPR model with an initial RBF kernel hyperparameters of lengthscale=3, variance=1, noise=1, and run for 1000 steps using stochastic variational inference (SVI). Since we are doing inference with GPR, we are able to learn the GPR/kernel hyperparameters directly from the embeddings itself with minimal fine-tuning.</p>\n<p>Our final submission with GPR model achieved public 0.448, private 0.448</p>\n<h3>What worked</h3>\n<p><b>Dropout removal</b><br>\nThe <code>remove dropout</code> note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by this <a href=\"https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch\">kernel</a>. It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.</p>\n<p><b>Pseudo labelling</b><br>\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold, to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.</p>\n<p><b>Pretrained models</b><br>\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as <code>squad</code> and <code>triviaqa</code>. So it's always better to try different pretrained models when using transformer models.</p>\n<p><b>Gaussian process regression</b><br>\nThis is the most important ensembling/preprocessing/correction steps for our solution. All of our single transformer models improved significantly with gains from 0.002 - 0.01 after training a GPR model using the attention-head embedding.</p>\n<h3>What didn't work</h3>\n<p><b>Extreme data and post-processing</b><br>\nWe found that the data with the targets &lt; -3 or &gt; 1 are the ones that make the training unstable. There are only 131 of these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that.</p>\n<p><b>Using different heads</b><br>\nWe tried training transformers using different heads, e.g. cls, mean pooling, pooler, concatenate last 4/8/12 layers, mean max pooling. But attention head works best for us, hence we stick with attention-head for all our models.</p>\n<p><b>Different optimization strategies</b><br>\nInitially, we also tried mixout regularization and multi-sample dropout, doing this stabilizes training, but the individual LB score is bad. And in the end, the transformers w/o dropout works better.</p>\n<h3>Final words</h3>\n<p>We should have trusted our CV for the models trained with pseudo-labeling. Our best submission has public 0.452, private 0.446 which is achieved by using only 6 models trained with pseudo-labeling. Unfortunately, we didn't select that for our final submission since the public LB is bad..</p>\n<p>References:<br>\n[1] <a href=\"https://pyro.ai/examples/gp.html\" target=\"_blank\">https://pyro.ai/examples/gp.html</a></p>",
  "comments": [
    {
      "id": 1444311,
      "author_name": "Frank",
      "author_url": "",
      "post_date": "2021-08-04T05:37:01.043000",
      "content": "<p>I would like to share some more insight about our journey.</p>\n<ul>\n<li><p>Dropout removal<br>\nThe <code>remove dropout</code> note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by <a href=\"https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch\" target=\"_blank\">this kernel</a>. It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.</p></li>\n<li><p>Pseudo labelling<br>\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold,  to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.</p></li>\n<li><p>Pretrained models<br>\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as <code>squad</code> and <code>triviaqa</code>. So it's always better to try different pretrained models when using transformer models.</p></li>\n<li><p>Extreme data and post-processing<br>\nWe found that the data with the targets &lt; -3 or &gt; 1 are the ones that make the training unstable. There are only 131 these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that. </p></li>\n</ul>",
      "votes": 4,
      "replies": [
        {
          "id": 1444390,
          "author_name": "Kelvin",
          "author_url": "",
          "post_date": "2021-08-04T05:50:52.923000",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> for your great contribution to the team! I've added the additional information to our post :)</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1454160,
          "author_name": "Allohvk",
          "author_url": "",
          "post_date": "2021-08-06T05:43:16.397000",
          "content": "<p>actually last comment is very interesting. Do you think it would have made sense to use MAE for these type of cases and MSE for rest and then combine the two for a consolidated loss. For a while I toyed with the idea, but couldn't take it forward due to paucity of time, but I strongly felt that accounting for those extremes somehow would make he training more stable, but just couldn't find a right approach (I had thought to do this by making pred=label where label=extreme value in MSE  loss calculation and pred=label where label !=extreme value in MAE loss calculation and add the 2 losses but maybe this messes gradients?)</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1454254,
          "author_name": "Frank",
          "author_url": "",
          "post_date": "2021-08-06T06:16:17.247000",
          "content": "<p><a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> Thanks for the comment. You mean using MSE loss for extreme data and MAE loss for the rest, or the opposite? Given the same predictions, the MSE loss gives smaller values but actually its gradients are 2x larger than MAE loss, so this could potentially help the learning of extreme data?</p>\n<p>I think those samples are not quite learnable as their standard errors are very high. The model can only learn the general trend and during inference, I observed that it would give more conservative predictions. I tried one experiment where I put all of the extreme data at the front in each training epoch, and it clearly showed that they totally destroyed what the model has learned.</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1454526,
          "author_name": "Allohvk",
          "author_url": "",
          "post_date": "2021-08-06T08:20:44.607000",
          "content": "<p><a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> Thanks for your feedback. I meant opposite - use MAE for extremes and MSE for rest. My logic for same is that I felt we should not try too much to learn extreme values else this will corrupt the learning of regular values. By \"extreme\" we could mean the upper &amp; lower ends of the target data or the high standard error records or a mix of both. Discarding the extremes completely could be one solution. But I was thinking if there is another way. </p>\n<p>Instead of discarding completely, for these particular extreme records can we use a loss function which gives little lesser impact? So hence MAE for such cases and MSE for regular cases. This way extreme/outlier data won't effect the regular row data training too much.</p>\n<p>One way to implement this would be: </p>\n<ul>\n<li>If (extreme&gt;): make pred=label, then feed to MSE loss calculation (so all extremes rows have zero loss)</li>\n<li>else: make pred=label for all non-extremes, then feed to MAE loss calculation (so all non-extreme rows have zero loss)</li>\n<li>Add the two losses to arrive at final loss</li>\n</ul>\n<p>But this is theoritical. not sure if this kind of approach works. Maybe I will experiment it and share further of it works.</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1454588,
          "author_name": "Frank",
          "author_url": "",
          "post_date": "2021-08-06T08:57:20.360000",
          "content": "<p><a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> Cool. That's an interesting approach. Worth a try!</p>\n<p>Just to let you know, I tried discarding either the upper &amp; lower ends of the target data or the high std data (std &gt; 0.6). The cv improved but public LB dropped. And I just checked the private LB, training without high std data (std &gt; 0.6) worsened the public LB by 0.004 but improved the private LB by 0.003 :)</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1454641,
          "author_name": "Allohvk",
          "author_url": "",
          "post_date": "2021-08-06T09:23:24.130000",
          "content": "<p>:) very tricky. It is one of those decisions where we have to take a leap of faith in our CV :)</p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1533895,
          "author_name": "Allohvk",
          "author_url": "",
          "post_date": "2021-10-04T12:51:01.327000",
          "content": "<p><a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> In case you are interested in further analysis of the BT loss - <a href=\"https://www.kaggle.com/c/commonlitreadabilityprize/discussion/276356\" target=\"_blank\">https://www.kaggle.com/c/commonlitreadabilityprize/discussion/276356</a></p>",
          "votes": 1,
          "replies": []
        },
        {
          "id": 1535705,
          "author_name": "Frank",
          "author_url": "",
          "post_date": "2021-10-06T05:54:01.450000",
          "content": "<p>Thanks for sharing! <a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> I'll read it later.</p>",
          "votes": 1,
          "replies": []
        }
      ]
    },
    {
      "id": 1444884,
      "author_name": "Minglei Wang",
      "author_url": "",
      "post_date": "2021-08-04T07:15:04.830000",
      "content": "<p>Thanks <a href=\"https://www.kaggle.com/xyzdivergence\" target=\"_blank\">@xyzdivergence</a> for sharing  the ideas and congrats on the win. <br>\nI had tried to use GPR to ensemble the prediction targets from different models instead of averaging them. It improved on the training set but not on LB. Ensemble the embeddings is really a good idea. <br>\nSince each of your model uses 5-fold, should you have 1024x5x9 embeddings on the test set? or did you average 5 fold embeddings as the one of the model and the concatenate the 9s together? </p>",
      "votes": 1,
      "replies": [
        {
          "id": 1445606,
          "author_name": "Kelvin",
          "author_url": "",
          "post_date": "2021-08-04T09:27:13.357000",
          "content": "<p>Yes,  you are right. In total, we have 1024x5x9 embeddings on the test set, and we took the average of the 5-folds GPR prediction as one final prediction.</p>\n<p>E.g.  Assuming the test size is 7</p>\n<pre><code>embeddings1 = np.concatenate((embedding1_roberta_large), .., (embeddings1_deberta_large), axis=1) # (7, 9216)\n...\nembeddings5 = np.concatenate((embedding5_roberta_large), .., (embeddings5_deberta_large), axis=1) # (7, 9216)\n\nembeddings = [embeddings1, ..., embeddings5] # e.g. [(7, 9216), ..., (7, 9216)]\n\ngpr_preds_concat = [gpr_inference(x) for x in embeddings] # list of gpr predictions array each of size (7,) e.g. [(7,), ..., (7,)]\n\nfinal_gpr_preds = np.mean(gpr_preds_concat, axis=0) # (7,)\n</code></pre>\n<p>I believe that other than GPR u can use the concatenate embeddings for other models as well e.g. SVR. However, I am not sure how well it will perform since we only tested on GPR as the training dataset is small and seems more logical for our approach.</p>",
          "votes": 2,
          "replies": []
        },
        {
          "id": 1446022,
          "author_name": "Minglei Wang",
          "author_url": "",
          "post_date": "2021-08-04T10:48:15.217000",
          "content": "<p>Thank you. That's a lot clearer. I tried SVR and Boost but unfortunately that was applied on the targets. Will try your technique next time. </p>",
          "votes": 0,
          "replies": []
        }
      ]
    },
    {
      "id": 1442217,
      "author_name": "Chris Deotte",
      "author_url": "",
      "post_date": "2021-08-03T22:03:46.060000",
      "content": "<p>Congratulations. Great idea to concatenate all your models' embeddings together and train one meta model. </p>",
      "votes": 1,
      "replies": [
        {
          "id": 1443248,
          "author_name": "Kelvin",
          "author_url": "",
          "post_date": "2021-08-04T02:18:12.593000",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/cdeotte\" target=\"_blank\">@cdeotte</a> and congratulations to you too! We learnt a lot from you as well!</p>",
          "votes": 1,
          "replies": []
        }
      ]
    },
    {
      "id": 1442076,
      "author_name": "Trushant Kalyanpur",
      "author_url": "",
      "post_date": "2021-08-03T21:39:53.783000",
      "content": "<p>Congratulations on the gold finish! Did you use the AttentionHead with dropout and another Linear layer similar to the notebook or jus the AttentionHead? </p>",
      "votes": 1,
      "replies": [
        {
          "id": 1443273,
          "author_name": "Kelvin",
          "author_url": "",
          "post_date": "2021-08-04T02:24:10.410000",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/trushk\" target=\"_blank\">@trushk</a> for your comment :). Yes our transformer models uses AttentionHead with dropout and added another linear layer similar to the public notebook <a href=\"https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune\" target=\"_blank\">https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune</a>.</p>",
          "votes": 1,
          "replies": []
        }
      ]
    },
    {
      "id": 1433171,
      "author_name": "over watch",
      "author_url": "",
      "post_date": "2021-08-03T13:48:20.087000",
      "content": "<p>Congratulations to top finishes in the competition!</p>\n<p>The Gaussian process regression looks like such an interesting way to ensemble models. Does your team plan to share the code public?</p>",
      "votes": 2,
      "replies": [
        {
          "id": 1443280,
          "author_name": "Kelvin",
          "author_url": "",
          "post_date": "2021-08-04T02:26:21.860000",
          "content": "<p>Thank you for your comment :). Yes, we plan to share our code, currently, we are in the midst of tidying up. Will share our training/inference code soon!</p>",
          "votes": 1,
          "replies": []
        }
      ]
    },
    {
      "id": 1973981,
      "author_name": "blAckPearL1376",
      "author_url": "",
      "post_date": "2022-10-06T02:19:43.027000",
      "content": "<p>Tks for sharing！</p>",
      "votes": 0,
      "replies": []
    },
    {
      "id": 1952128,
      "author_name": "WANG ZHIJIAN@NUS",
      "author_url": "",
      "post_date": "2022-09-23T13:14:25.613000",
      "content": "<p>Thanks for sharing.</p>",
      "votes": 0,
      "replies": []
    }
  ],
  "comment_count": 20,
  "messages": [
    {
      "id": 1429879,
      "postDate": "2021-08-03T11:04:51.573Z",
      "content": "<h3>Acknowledgement</h3>\n<p>First of all, we would like to thanks Kaggle &amp; CommonLit for hosting this interesting competition, this has been an interesting journey for us! Also congratulations to all winning teams!</p>\n<p>And special thanks to <a href=\"https://www.kaggle.com/rhtsingh\" target=\"_blank\">@rhtsingh</a>, <a href=\"https://www.kaggle.com/maunish\" target=\"_blank\">@maunish</a>, and <a href=\"https://www.kaggle.com/andretugan\" target=\"_blank\">@andretugan</a> for their knowledgeable and resourceful notebooks. Since our team is fairly new to transformers, leveraging the resources from public notebooks definitely helps in our journey!</p>\n<h3>Summary</h3>\n<p>Our final submission consists of 9 transformer models, and our final solution is based on our 2nd-stage model Gaussian Process Regression (GPR) [1] which we use to correct overconfident transformer predictions due to the small training data. This can be summarized in two steps. </p>\n<ol>\n<li>Extract all the OOF embeddings from the last transformer layer (Attention-head) for all 9 models and concatenate all of them.</li>\n<li>Train a GPR model using the concatenated embeddings. </li>\n</ol>\n<h3>Architecture for final solution</h3>\n<p><img src=\"https://i.imgur.com/ANcnHNt.png\"></p>\n<h3>External data</h3>\n<p>We scraped data from the “url_legal” information which is available in the training data and only use those with licenses of “CC BY” and “CC BY-SA”.</p>\n<h4>Transformers model</h4>\n<p>Like every other team, we first started out fine-tuning transformers model and focus on increasing the single model LB score by training different transformers for diversity. Since our goal is to use GPR to improve the transformer predictions, we need robust transformer models that can generate robust embeddings.</p>\n<p>Our final submission consists of the following 9 transformer models and all models are trained using 5-fold stratified CV with attention head.</p>\n<table>\n<thead>\n<tr>\n<th>Model</th>\n<th>CV</th>\n<th>Public</th>\n<th>Private</th>\n<th>Notes</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>roberta-large</td>\n<td>0.492</td>\n<td>0.471</td>\n<td>0.471</td>\n<td>mlm on training set</td>\n</tr>\n<tr>\n<td>microsoft/deberta-large</td>\n<td>0.485</td>\n<td>0.474</td>\n<td>0.476</td>\n<td>mlm on training set</td>\n</tr>\n<tr>\n<td>xlnet-large-cased</td>\n<td>0.494</td>\n<td>0.475</td>\n<td>0.476</td>\n<td>-</td>\n</tr>\n<tr>\n<td>deepset/roberta-large-squad2</td>\n<td>0.488</td>\n<td>0.464</td>\n<td>0.467</td>\n<td>-</td>\n</tr>\n<tr>\n<td>deepset/roberta-large-squad2</td>\n<td>0.484</td>\n<td>0.466</td>\n<td>0.464</td>\n<td>mlm on train set and external data</td>\n</tr>\n<tr>\n<td>allenai/longformer-large-4096-finetuned-triviaqa</td>\n<td>0.489</td>\n<td>0.467</td>\n<td>0.47</td>\n<td>-</td>\n</tr>\n<tr>\n<td>valhalla/bart-large-finetuned-squadv1</td>\n<td>0.471</td>\n<td>0.462</td>\n<td>0.466</td>\n<td>mlm on train set and external data, remove dropout</td>\n</tr>\n<tr>\n<td>microsoft/deberta-large-mnli</td>\n<td>0.469</td>\n<td>0.462</td>\n<td>0.469</td>\n<td>mlm on train set and external data, remove dropout</td>\n</tr>\n<tr>\n<td>ahotrod/electra_large_discriminator_squad2_512</td>\n<td>0.477</td>\n<td>0.468</td>\n<td>0.468</td>\n<td>remove dropout</td>\n</tr>\n</tbody>\n</table>\n<p>The model selection is based on the individual LB score (preferably &lt;= 0.475)</p>\n<h3>Fine-tune</h3>\n<p>The following are the fine-tuned strategy for the transformer models</p>\n<ul>\n<li>Epochs: 5</li>\n<li>Batch Size: 8</li>\n<li>Optimizer: AdamW with SWA</li>\n<li>LR Scheduler: Linear learning rate scheduler with 6% warmup steps</li>\n<li>Learning rate: 2e-5</li>\n<li>Layer reinitialisation: last 3 transformer layers (reference: <a href=\"https://www.kaggle.com/rhtsingh/on-stability-of-few-sample-transformer-fine-tuning\" target=\"_blank\">https://www.kaggle.com/rhtsingh/on-stability-of-few-sample-transformer-fine-tuning</a>)<br>\nUse attention head. (reference: <a href=\"https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune\" target=\"_blank\">https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune</a>)</li>\n<li>Evaluating for every n steps: 10</li>\n</ul>\n<h3>Gaussian Process Regression (GPR)</h3>\n<p>We are aware of the limited training samples ~2.8k, hence we immediately thought of Gaussian process regression (GPR). Given the constraint of limited training samples, using Bayesian techniques such as GPR could potentially help us make a better approximation/prediction. Since Bayesian/Probabilistic model are proven to performs relatively well in small setting, and it also has a strong notion of uncertainty. The uncertainty is important here as we know the distribution of the training and test data are different, and we do not want the transformer to make overconfident predictions, hence GPR alleviates overconfident predictions from transformers. <strong>A NN with one hidden layer of infinite width is basically a Gaussian Processes.</strong></p>\n<p>The below figure shows the deberta-large model predictions for 100 randomly sampled points. The green curve is the deberta-large predictions, and the red curve is the GPR predictions. We can see that deberta-large will try to fit all the points as closely as possible (Red circle), however, GPR will avoid overconfident predictions and will regress to the mean of nearby samples when it is not confident, thus providing reliable uncertainty estimation.</p>\n<p><img src=\"https://i.imgur.com/yMlaKpG.png\"></p>\n<h3>Gaussian process regression (GPR) as 2nd-stage model</h3>\n<p>We use GPR to correct overconfident transformer predictions. Doing this allows us to further improved the single model score significantly by training a GPR model using all the OOF embeddings extracted from the last transformer layer (attention-head). </p>\n<p>The following submission shows that using deberta-large trained with pseudo-labeling (PL) can achieve a single private score of 0.459, but with GPR it can achieve 0.453 alone!</p>\n<table>\n<thead>\n<tr>\n<th>Model</th>\n<th>CV</th>\n<th>Public</th>\n<th>Private</th>\n<th>GPR Public</th>\n<th>GPR private</th>\n<th>Notes</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>deberta-large</td>\n<td>0.462</td>\n<td>0.465</td>\n<td><b>0.459</b></td>\n<td>0.457</td>\n<td><b>0.453</b></td>\n<td>train with pseudo labeling</td>\n</tr>\n</tbody>\n</table>\n<p>Unfortunately, we didn't include any model trained with pseudo-labeling since many of our PL-trained models has bad single/ensemble LB score as compared to the model trained without pseudo-labeling.. </p>\n<p>This leads us to believe the LB has a different data distribution as compared to the training data, hence we use all the OOF embeddings for training and only validate the individual GPR model performance on LB.   </p>\n<h3>Training GPR using all oof embeddings</h3>\n<p>From the transformer models section above, the 9 models were selected in terms of their individual LB scores and correlations for diversity. We extracted the attention head embeddings which is of size 1024 for each model, hence 1024*9 embeddings for 9 models. We concatenate all 1024*9 embeddings and train all samples using GPR model with an initial RBF kernel hyperparameters of lengthscale=3, variance=1, noise=1, and run for 1000 steps using stochastic variational inference (SVI). Since we are doing inference with GPR, we are able to learn the GPR/kernel hyperparameters directly from the embeddings itself with minimal fine-tuning.</p>\n<p>Our final submission with GPR model achieved public 0.448, private 0.448</p>\n<h3>What worked</h3>\n<p><b>Dropout removal</b><br>\nThe <code>remove dropout</code> note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by this <a href=\"https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch\">kernel</a>. It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.</p>\n<p><b>Pseudo labelling</b><br>\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold, to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.</p>\n<p><b>Pretrained models</b><br>\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as <code>squad</code> and <code>triviaqa</code>. So it's always better to try different pretrained models when using transformer models.</p>\n<p><b>Gaussian process regression</b><br>\nThis is the most important ensembling/preprocessing/correction steps for our solution. All of our single transformer models improved significantly with gains from 0.002 - 0.01 after training a GPR model using the attention-head embedding.</p>\n<h3>What didn't work</h3>\n<p><b>Extreme data and post-processing</b><br>\nWe found that the data with the targets &lt; -3 or &gt; 1 are the ones that make the training unstable. There are only 131 of these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that.</p>\n<p><b>Using different heads</b><br>\nWe tried training transformers using different heads, e.g. cls, mean pooling, pooler, concatenate last 4/8/12 layers, mean max pooling. But attention head works best for us, hence we stick with attention-head for all our models.</p>\n<p><b>Different optimization strategies</b><br>\nInitially, we also tried mixout regularization and multi-sample dropout, doing this stabilizes training, but the individual LB score is bad. And in the end, the transformers w/o dropout works better.</p>\n<h3>Final words</h3>\n<p>We should have trusted our CV for the models trained with pseudo-labeling. Our best submission has public 0.452, private 0.446 which is achieved by using only 6 models trained with pseudo-labeling. Unfortunately, we didn't select that for our final submission since the public LB is bad..</p>\n<p>References:<br>\n[1] <a href=\"https://pyro.ai/examples/gp.html\" target=\"_blank\">https://pyro.ai/examples/gp.html</a></p>",
      "rawMarkdown": "### Acknowledgement\nFirst of all, we would like to thanks Kaggle & CommonLit for hosting this interesting competition, this has been an interesting journey for us! Also congratulations to all winning teams!\n\nAnd special thanks to @rhtsingh, @maunish, and @andretugan for their knowledgeable and resourceful notebooks. Since our team is fairly new to transformers, leveraging the resources from public notebooks definitely helps in our journey!\n\n### Summary\nOur final submission consists of 9 transformer models, and our final solution is based on our 2nd-stage model Gaussian Process Regression (GPR) [1] which we use to correct overconfident transformer predictions due to the small training data. This can be summarized in two steps. \n1. Extract all the OOF embeddings from the last transformer layer (Attention-head) for all 9 models and concatenate all of them.\n2. Train a GPR model using the concatenated embeddings. \n\n### Architecture for final solution\n<img src='https://i.imgur.com/ANcnHNt.png' />\n\n\n### External data\nWe scraped data from the “url_legal” information which is available in the training data and only use those with licenses of “CC BY” and “CC BY-SA”.\n\n#### Transformers model\nLike every other team, we first started out fine-tuning transformers model and focus on increasing the single model LB score by training different transformers for diversity. Since our goal is to use GPR to improve the transformer predictions, we need robust transformer models that can generate robust embeddings.\n\nOur final submission consists of the following 9 transformer models and all models are trained using 5-fold stratified CV with attention head.\n| Model | CV | Public | Private | Notes\n| --- | --- | --- | --- | --- |\n| roberta-large | 0.492 | 0.471 | 0.471| mlm on training set\n| microsoft/deberta-large | 0.485 |0.474 | 0.476| mlm on training set\n| xlnet-large-cased | 0.494 | 0.475 | 0.476| -\n| deepset/roberta-large-squad2 | 0.488 | 0.464 | 0.467| -\n| deepset/roberta-large-squad2 | 0.484 | 0.466 | 0.464 | mlm on train set and external data\n| allenai/longformer-large-4096-finetuned-triviaqa | 0.489 | 0.467 | 0.47 | -\n| valhalla/bart-large-finetuned-squadv1 | 0.471 | 0.462 | 0.466 |  mlm on train set and external data, remove dropout\n| microsoft/deberta-large-mnli | 0.469 | 0.462 | 0.469 | mlm on train set and external data, remove dropout\n| ahotrod/electra_large_discriminator_squad2_512 | 0.477 | 0.468 | 0.468 | remove dropout\n\nThe model selection is based on the individual LB score (preferably <= 0.475)\n\n### Fine-tune\nThe following are the fine-tuned strategy for the transformer models\n- Epochs: 5\n- Batch Size: 8\n- Optimizer: AdamW with SWA\n- LR Scheduler: Linear learning rate scheduler with 6% warmup steps\n- Learning rate: 2e-5\n- Layer reinitialisation: last 3 transformer layers (reference: https://www.kaggle.com/rhtsingh/on-stability-of-few-sample-transformer-fine-tuning)\nUse attention head. (reference: https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune)\n- Evaluating for every n steps: 10\n\n### Gaussian Process Regression (GPR)\nWe are aware of the limited training samples ~2.8k, hence we immediately thought of Gaussian process regression (GPR). Given the constraint of limited training samples, using Bayesian techniques such as GPR could potentially help us make a better approximation/prediction. Since Bayesian/Probabilistic model are proven to performs relatively well in small setting, and it also has a strong notion of uncertainty. The uncertainty is important here as we know the distribution of the training and test data are different, and we do not want the transformer to make overconfident predictions, hence GPR alleviates overconfident predictions from transformers. **A NN with one hidden layer of infinite width is basically a Gaussian Processes.**\n\nThe below figure shows the deberta-large model predictions for 100 randomly sampled points. The green curve is the deberta-large predictions, and the red curve is the GPR predictions. We can see that deberta-large will try to fit all the points as closely as possible (Red circle), however, GPR will avoid overconfident predictions and will regress to the mean of nearby samples when it is not confident, thus providing reliable uncertainty estimation.\n\n<img src='https://i.imgur.com/yMlaKpG.png' />\n\n### Gaussian process regression (GPR) as 2nd-stage model\nWe use GPR to correct overconfident transformer predictions. Doing this allows us to further improved the single model score significantly by training a GPR model using all the OOF embeddings extracted from the last transformer layer (attention-head). \n\nThe following submission shows that using deberta-large trained with pseudo-labeling (PL) can achieve a single private score of 0.459, but with GPR it can achieve 0.453 alone!\n| Model | CV | Public | Private | GPR Public | GPR private | Notes\n| --- | --- | --- | --- | --- | --- | ---\n| deberta-large | 0.462 | 0.465 | <b>0.459</b> | 0.457 | <b>0.453</b> | train with pseudo labeling\n\nUnfortunately, we didn't include any model trained with pseudo-labeling since many of our PL-trained models has bad single/ensemble LB score as compared to the model trained without pseudo-labeling.. \n\nThis leads us to believe the LB has a different data distribution as compared to the training data, hence we use all the OOF embeddings for training and only validate the individual GPR model performance on LB.   \n\n### Training GPR using all oof embeddings\nFrom the transformer models section above, the 9 models were selected in terms of their individual LB scores and correlations for diversity. We extracted the attention head embeddings which is of size 1024 for each model, hence 1024\\*9 embeddings for 9 models. We concatenate all 1024\\*9 embeddings and train all samples using GPR model with an initial RBF kernel hyperparameters of lengthscale=3, variance=1, noise=1, and run for 1000 steps using stochastic variational inference (SVI). Since we are doing inference with GPR, we are able to learn the GPR/kernel hyperparameters directly from the embeddings itself with minimal fine-tuning.\n\nOur final submission with GPR model achieved public 0.448, private 0.448\n\n### What worked\n<b>Dropout removal</b>\nThe `remove dropout` note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by this <a href='https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch'>kernel</a>. It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.\n\n<b>Pseudo labelling</b>\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold, to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.\n\n<b>Pretrained models</b>\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as `squad` and `triviaqa`. So it's always better to try different pretrained models when using transformer models.\n\n<b>Gaussian process regression</b>\nThis is the most important ensembling/preprocessing/correction steps for our solution. All of our single transformer models improved significantly with gains from 0.002 - 0.01 after training a GPR model using the attention-head embedding.\n\n### What didn't work\n<b>Extreme data and post-processing</b>\nWe found that the data with the targets < -3 or > 1 are the ones that make the training unstable. There are only 131 of these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that.\n\n<b>Using different heads</b>\nWe tried training transformers using different heads, e.g. cls, mean pooling, pooler, concatenate last 4/8/12 layers, mean max pooling. But attention head works best for us, hence we stick with attention-head for all our models.\n\n<b>Different optimization strategies</b>\nInitially, we also tried mixout regularization and multi-sample dropout, doing this stabilizes training, but the individual LB score is bad. And in the end, the transformers w/o dropout works better.\n\n### Final words\nWe should have trusted our CV for the models trained with pseudo-labeling. Our best submission has public 0.452, private 0.446 which is achieved by using only 6 models trained with pseudo-labeling. Unfortunately, we didn't select that for our final submission since the public LB is bad..\n\nReferences:\n[1] https://pyro.ai/examples/gp.html",
      "votes": 69
    },
    {
      "id": 1444311,
      "postDate": "2021-08-04T05:37:01.043Z",
      "content": "<p>I would like to share some more insight about our journey.</p>\n<ul>\n<li><p>Dropout removal<br>\nThe <code>remove dropout</code> note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by <a href=\"https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch\" target=\"_blank\">this kernel</a>. It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.</p></li>\n<li><p>Pseudo labelling<br>\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold,  to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.</p></li>\n<li><p>Pretrained models<br>\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as <code>squad</code> and <code>triviaqa</code>. So it's always better to try different pretrained models when using transformer models.</p></li>\n<li><p>Extreme data and post-processing<br>\nWe found that the data with the targets &lt; -3 or &gt; 1 are the ones that make the training unstable. There are only 131 these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that. </p></li>\n</ul>",
      "rawMarkdown": "I would like to share some more insight about our journey.\n\n* Dropout removal\nThe `remove dropout` note in the table above refers to removing dropout in the transformer architecture, instead of the dropout placed in the output head. We were inspired by [this kernel](https://www.kaggle.com/andretugan/lightweight-roberta-solution-in-pytorch). It is a very interesting idea to remove it as the default dropout of 0.1 is used in nearly every transformer model. Previously, we can see that the validation loss is very unstable, which is why a small evaluation interval is commonly used. But after removing dropout in the transformers, the val loss became much more steady, and the converged points were usually much better. The cv score improved by a large margin, but the public LB doesn't reflect the change accordingly. Later we found more and more people used this strategy, so we just adopted it in some of our models.\n\n* Pseudo labelling\nWe scraped the data from the same url in the training data and labelled them with an ensemble model which scored LB 0.450. We didn't train on the pseudo data first and finetune with the competition data. Instead, during each fold training, we only added the pseudo data which have the same id as the training data in that fold,  to avoid potential data leakage. With this method, the CV score improved a lot but the public LB didn't agree. Though we didn't found data leakage in the cv, we abandoned the models trained with pseudo labelling. It turned out that it works well for the private set, and we should've trusted the cv more. The public test set is only ~600 samples so it doesn't reflect the data distribution in the private set well.\n\n* Pretrained models\nWe found that some of the models further pretrained on question answering datasets are better for finetuning in this competition such as `squad` and `triviaqa`. So it's always better to try different pretrained models when using transformer models.\n\n* Extreme data and post-processing\nWe found that the data with the targets < -3 or > 1 are the ones that make the training unstable. There are only 131 these samples in the training set. Their standard errors are also usually higher than the others. By removing these samples, the cv improved a lot. And we found that there are also some patterns in the targets of the extreme data that we can use for post-processing, only if we can detect these extreme samples. But we failed to build a model to achieve that. ",
      "votes": 4,
      "replies": [
        {
          "id": 1444390,
          "postDate": "2021-08-04T05:50:52.923Z",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> for your great contribution to the team! I've added the additional information to our post :)</p>",
          "rawMarkdown": "Thanks @xfffrank for your great contribution to the team! I've added the additional information to our post :)",
          "votes": 1
        },
        {
          "id": 1454160,
          "postDate": "2021-08-06T05:43:16.397Z",
          "content": "<p>actually last comment is very interesting. Do you think it would have made sense to use MAE for these type of cases and MSE for rest and then combine the two for a consolidated loss. For a while I toyed with the idea, but couldn't take it forward due to paucity of time, but I strongly felt that accounting for those extremes somehow would make he training more stable, but just couldn't find a right approach (I had thought to do this by making pred=label where label=extreme value in MSE  loss calculation and pred=label where label !=extreme value in MAE loss calculation and add the 2 losses but maybe this messes gradients?)</p>",
          "rawMarkdown": "actually last comment is very interesting. Do you think it would have made sense to use MAE for these type of cases and MSE for rest and then combine the two for a consolidated loss. For a while I toyed with the idea, but couldn't take it forward due to paucity of time, but I strongly felt that accounting for those extremes somehow would make he training more stable, but just couldn't find a right approach (I had thought to do this by making pred=label where label=extreme value in MSE  loss calculation and pred=label where label !=extreme value in MAE loss calculation and add the 2 losses but maybe this messes gradients?)",
          "votes": 1
        },
        {
          "id": 1454254,
          "postDate": "2021-08-06T06:16:17.247Z",
          "content": "<p><a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> Thanks for the comment. You mean using MSE loss for extreme data and MAE loss for the rest, or the opposite? Given the same predictions, the MSE loss gives smaller values but actually its gradients are 2x larger than MAE loss, so this could potentially help the learning of extreme data?</p>\n<p>I think those samples are not quite learnable as their standard errors are very high. The model can only learn the general trend and during inference, I observed that it would give more conservative predictions. I tried one experiment where I put all of the extreme data at the front in each training epoch, and it clearly showed that they totally destroyed what the model has learned.</p>",
          "rawMarkdown": "@allohvk Thanks for the comment. You mean using MSE loss for extreme data and MAE loss for the rest, or the opposite? Given the same predictions, the MSE loss gives smaller values but actually its gradients are 2x larger than MAE loss, so this could potentially help the learning of extreme data?\n\nI think those samples are not quite learnable as their standard errors are very high. The model can only learn the general trend and during inference, I observed that it would give more conservative predictions. I tried one experiment where I put all of the extreme data at the front in each training epoch, and it clearly showed that they totally destroyed what the model has learned.",
          "votes": 1
        },
        {
          "id": 1454526,
          "postDate": "2021-08-06T08:20:44.607Z",
          "content": "<p><a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> Thanks for your feedback. I meant opposite - use MAE for extremes and MSE for rest. My logic for same is that I felt we should not try too much to learn extreme values else this will corrupt the learning of regular values. By \"extreme\" we could mean the upper &amp; lower ends of the target data or the high standard error records or a mix of both. Discarding the extremes completely could be one solution. But I was thinking if there is another way. </p>\n<p>Instead of discarding completely, for these particular extreme records can we use a loss function which gives little lesser impact? So hence MAE for such cases and MSE for regular cases. This way extreme/outlier data won't effect the regular row data training too much.</p>\n<p>One way to implement this would be: </p>\n<ul>\n<li>If (extreme&gt;): make pred=label, then feed to MSE loss calculation (so all extremes rows have zero loss)</li>\n<li>else: make pred=label for all non-extremes, then feed to MAE loss calculation (so all non-extreme rows have zero loss)</li>\n<li>Add the two losses to arrive at final loss</li>\n</ul>\n<p>But this is theoritical. not sure if this kind of approach works. Maybe I will experiment it and share further of it works.</p>",
          "rawMarkdown": "@xfffrank Thanks for your feedback. I meant opposite - use MAE for extremes and MSE for rest. My logic for same is that I felt we should not try too much to learn extreme values else this will corrupt the learning of regular values. By \"extreme\" we could mean the upper & lower ends of the target data or the high standard error records or a mix of both. Discarding the extremes completely could be one solution. But I was thinking if there is another way. \n\nInstead of discarding completely, for these particular extreme records can we use a loss function which gives little lesser impact? So hence MAE for such cases and MSE for regular cases. This way extreme/outlier data won't effect the regular row data training too much.\n\nOne way to implement this would be: \n- If (extreme>): make pred=label, then feed to MSE loss calculation (so all extremes rows have zero loss)\n- else: make pred=label for all non-extremes, then feed to MAE loss calculation (so all non-extreme rows have zero loss)\n- Add the two losses to arrive at final loss\n\nBut this is theoritical. not sure if this kind of approach works. Maybe I will experiment it and share further of it works.",
          "votes": 1
        },
        {
          "id": 1454588,
          "postDate": "2021-08-06T08:57:20.360Z",
          "content": "<p><a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> Cool. That's an interesting approach. Worth a try!</p>\n<p>Just to let you know, I tried discarding either the upper &amp; lower ends of the target data or the high std data (std &gt; 0.6). The cv improved but public LB dropped. And I just checked the private LB, training without high std data (std &gt; 0.6) worsened the public LB by 0.004 but improved the private LB by 0.003 :)</p>",
          "rawMarkdown": "@allohvk Cool. That's an interesting approach. Worth a try!\n\nJust to let you know, I tried discarding either the upper & lower ends of the target data or the high std data (std > 0.6). The cv improved but public LB dropped. And I just checked the private LB, training without high std data (std > 0.6) worsened the public LB by 0.004 but improved the private LB by 0.003 :)",
          "votes": 1
        },
        {
          "id": 1454641,
          "postDate": "2021-08-06T09:23:24.130Z",
          "content": "<p>:) very tricky. It is one of those decisions where we have to take a leap of faith in our CV :)</p>",
          "rawMarkdown": ":) very tricky. It is one of those decisions where we have to take a leap of faith in our CV :)",
          "votes": 1
        },
        {
          "id": 1533895,
          "postDate": "2021-10-04T12:51:01.327Z",
          "content": "<p><a href=\"https://www.kaggle.com/xfffrank\" target=\"_blank\">@xfffrank</a> In case you are interested in further analysis of the BT loss - <a href=\"https://www.kaggle.com/c/commonlitreadabilityprize/discussion/276356\" target=\"_blank\">https://www.kaggle.com/c/commonlitreadabilityprize/discussion/276356</a></p>",
          "rawMarkdown": "@xfffrank In case you are interested in further analysis of the BT loss - https://www.kaggle.com/c/commonlitreadabilityprize/discussion/276356",
          "votes": 1
        },
        {
          "id": 1535705,
          "postDate": "2021-10-06T05:54:01.450Z",
          "content": "<p>Thanks for sharing! <a href=\"https://www.kaggle.com/allohvk\" target=\"_blank\">@allohvk</a> I'll read it later.</p>",
          "rawMarkdown": "Thanks for sharing! @allohvk I'll read it later.",
          "votes": 1
        }
      ]
    },
    {
      "id": 1444884,
      "postDate": "2021-08-04T07:15:04.830Z",
      "content": "<p>Thanks <a href=\"https://www.kaggle.com/xyzdivergence\" target=\"_blank\">@xyzdivergence</a> for sharing  the ideas and congrats on the win. <br>\nI had tried to use GPR to ensemble the prediction targets from different models instead of averaging them. It improved on the training set but not on LB. Ensemble the embeddings is really a good idea. <br>\nSince each of your model uses 5-fold, should you have 1024x5x9 embeddings on the test set? or did you average 5 fold embeddings as the one of the model and the concatenate the 9s together? </p>",
      "rawMarkdown": "Thanks @xyzdivergence for sharing  the ideas and congrats on the win. \nI had tried to use GPR to ensemble the prediction targets from different models instead of averaging them. It improved on the training set but not on LB. Ensemble the embeddings is really a good idea. \nSince each of your model uses 5-fold, should you have 1024x5x9 embeddings on the test set? or did you average 5 fold embeddings as the one of the model and the concatenate the 9s together? \n\n",
      "votes": 1,
      "replies": [
        {
          "id": 1445606,
          "postDate": "2021-08-04T09:27:13.357Z",
          "content": "<p>Yes,  you are right. In total, we have 1024x5x9 embeddings on the test set, and we took the average of the 5-folds GPR prediction as one final prediction.</p>\n<p>E.g.  Assuming the test size is 7</p>\n<pre><code>embeddings1 = np.concatenate((embedding1_roberta_large), .., (embeddings1_deberta_large), axis=1) # (7, 9216)\n...\nembeddings5 = np.concatenate((embedding5_roberta_large), .., (embeddings5_deberta_large), axis=1) # (7, 9216)\n\nembeddings = [embeddings1, ..., embeddings5] # e.g. [(7, 9216), ..., (7, 9216)]\n\ngpr_preds_concat = [gpr_inference(x) for x in embeddings] # list of gpr predictions array each of size (7,) e.g. [(7,), ..., (7,)]\n\nfinal_gpr_preds = np.mean(gpr_preds_concat, axis=0) # (7,)\n</code></pre>\n<p>I believe that other than GPR u can use the concatenate embeddings for other models as well e.g. SVR. However, I am not sure how well it will perform since we only tested on GPR as the training dataset is small and seems more logical for our approach.</p>",
          "rawMarkdown": "Yes,  you are right. In total, we have 1024x5x9 embeddings on the test set, and we took the average of the 5-folds GPR prediction as one final prediction.\n\nE.g.  Assuming the test size is 7\n```\nembeddings1 = np.concatenate((embedding1_roberta_large), .., (embeddings1_deberta_large), axis=1) # (7, 9216)\n...\nembeddings5 = np.concatenate((embedding5_roberta_large), .., (embeddings5_deberta_large), axis=1) # (7, 9216)\n\nembeddings = [embeddings1, ..., embeddings5] # e.g. [(7, 9216), ..., (7, 9216)]\n\ngpr_preds_concat = [gpr_inference(x) for x in embeddings] # list of gpr predictions array each of size (7,) e.g. [(7,), ..., (7,)]\n\nfinal_gpr_preds = np.mean(gpr_preds_concat, axis=0) # (7,)\n```\n\nI believe that other than GPR u can use the concatenate embeddings for other models as well e.g. SVR. However, I am not sure how well it will perform since we only tested on GPR as the training dataset is small and seems more logical for our approach.",
          "votes": 2
        },
        {
          "id": 1446022,
          "postDate": "2021-08-04T10:48:15.217Z",
          "content": "<p>Thank you. That's a lot clearer. I tried SVR and Boost but unfortunately that was applied on the targets. Will try your technique next time. </p>",
          "rawMarkdown": "Thank you. That's a lot clearer. I tried SVR and Boost but unfortunately that was applied on the targets. Will try your technique next time. "
        }
      ]
    },
    {
      "id": 1442217,
      "postDate": "2021-08-03T22:03:46.060Z",
      "content": "<p>Congratulations. Great idea to concatenate all your models' embeddings together and train one meta model. </p>",
      "rawMarkdown": "Congratulations. Great idea to concatenate all your models' embeddings together and train one meta model. ",
      "votes": 1,
      "replies": [
        {
          "id": 1443248,
          "postDate": "2021-08-04T02:18:12.593Z",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/cdeotte\" target=\"_blank\">@cdeotte</a> and congratulations to you too! We learnt a lot from you as well!</p>",
          "rawMarkdown": "Thanks @cdeotte and congratulations to you too! We learnt a lot from you as well!",
          "votes": 1
        }
      ]
    },
    {
      "id": 1442076,
      "postDate": "2021-08-03T21:39:53.783Z",
      "content": "<p>Congratulations on the gold finish! Did you use the AttentionHead with dropout and another Linear layer similar to the notebook or jus the AttentionHead? </p>",
      "rawMarkdown": "Congratulations on the gold finish! Did you use the AttentionHead with dropout and another Linear layer similar to the notebook or jus the AttentionHead? \n",
      "votes": 1,
      "replies": [
        {
          "id": 1443273,
          "postDate": "2021-08-04T02:24:10.410Z",
          "content": "<p>Thanks <a href=\"https://www.kaggle.com/trushk\" target=\"_blank\">@trushk</a> for your comment :). Yes our transformer models uses AttentionHead with dropout and added another linear layer similar to the public notebook <a href=\"https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune\" target=\"_blank\">https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune</a>.</p>",
          "rawMarkdown": "Thanks @trushk for your comment :). Yes our transformer models uses AttentionHead with dropout and added another linear layer similar to the public notebook https://www.kaggle.com/maunish/clrp-pytorch-roberta-finetune.",
          "votes": 1
        }
      ]
    },
    {
      "id": 1433171,
      "postDate": "2021-08-03T13:48:20.087Z",
      "content": "<p>Congratulations to top finishes in the competition!</p>\n<p>The Gaussian process regression looks like such an interesting way to ensemble models. Does your team plan to share the code public?</p>",
      "rawMarkdown": "Congratulations to top finishes in the competition!\n\nThe Gaussian process regression looks like such an interesting way to ensemble models. Does your team plan to share the code public?",
      "votes": 2,
      "replies": [
        {
          "id": 1443280,
          "postDate": "2021-08-04T02:26:21.860Z",
          "content": "<p>Thank you for your comment :). Yes, we plan to share our code, currently, we are in the midst of tidying up. Will share our training/inference code soon!</p>",
          "rawMarkdown": "Thank you for your comment :). Yes, we plan to share our code, currently, we are in the midst of tidying up. Will share our training/inference code soon!",
          "votes": 1
        }
      ]
    },
    {
      "id": 1973981,
      "postDate": "2022-10-06T02:19:43.027Z",
      "content": "<p>Tks for sharing！</p>",
      "rawMarkdown": "Tks for sharing！"
    },
    {
      "id": 1952128,
      "postDate": "2022-09-23T13:14:25.613Z",
      "content": "<p>Thanks for sharing.</p>",
      "rawMarkdown": "Thanks for sharing."
    }
  ],
  "complete": true,
  "source": "live",
  "fetched_at": "2026-10-19T23:48:01Z",
  "competition_id": 25914,
  "competition_slug": "commonlitreadabilityprize",
  "team_id": 6781642,
  "solution_url": "/competitions/commonlitreadabilityprize/writeups/ofnt-6th-place-solution-gaussian-process-regressio"
}