> **Concern about OpenLLM benchmark and Comparison to SPIN**:
Thanks for checking the rebuttal. TL;DR: 1. we suspect that a different version of baseline "zephyr-7b-sft-full" has been used in the SPIN paper which led to a significantly higher lift of 8-9% improvement, compared to ours of 2.6%. 2. when evaluated on the same baseline and codebase, every iteration our proposed algorithm outperforms every iteration of SPIN.
The SPIN paper reported the following improvements:
*(base model: older version; evaluation codebase: v0.4.0; test without LoRA)*
| Iterations | zephyr-7b-sft-full | iter0 | iter1 | iter2 | iter3 |
| -------- | ------- | ------- | ------- | ------- | ------- |
| Average Performance | 58.14 | 60.80 | 62.12 | 62.97 | 63.16 |
| Absolute increase | | 2.66 | 1.32 | 0.85 | 0.89 |
| Relative increase | | 4.56% | 6.85% | 8.31% | 8.63% |
We believe the result should be interpreted in the following way:
1. First, the baseline in our paper is different from SPIN paper: We believe a different baseline model is used in SPIN as evidenced in the Github discussions & the SPIN paper was released before the baseline is fully trained (Jan 2 vs Jan 10), see for example [this discussion](https://github.com/uclaml/SPIN/issues/12). In particular, in Table 3 of the SPIN paper, the base model yields a "26.76" accuracy for GSM8k dataset, but we observe "31.92" which is significantly higher. We notice that a newer version of both the model zephyr-7b-sft-full (see [their model commit history](https://huggingface.co/alignment-handbook/zephyr-7b-sft-full/commits/main)) and the lm_eval evaluation package which both our paper and SPIN use for evaluation (see [their codebase](https://github.com/EleutherAI/lm-evaluation-harness)) are used in our paper. We run test on different versions of base model and eval codebase and obtain a table as follows:
*(Performance of different version of zephyr-7b-sft-full, note we also change the first two tasks to make it fully aligned with SPIN paper)*
| Base model version| Eval package version | Arc_challenge | TruthfulQA_mc2 | Winogrande | GSM8k | Hellaswag | MMLU | Average |
| -------- | -------| ------- | ------- | ------- | ------- | ------- | ------- | ------- |
| [Newest](https://huggingface.co/alignment-handbook/zephyr-7b-sft-full) | [v0.4.0](https://github.com/EleutherAI/lm-evaluation-harness/tree/v0.4.0) | 58.02 | 40.40 | 76.16 | 34.19 | 80.89 | 57.46 | 57.85 |
| [Version in SPIN](https://huggingface.co/alignment-handbook/zephyr-7b-sft-full/commit/90e0792328bc522e1662a3a7c611b030d563bf5b) | [v0.4.0](https://github.com/EleutherAI/lm-evaluation-harness/tree/v0.4.0) | 60.84 | 43.74 | 78.69 | 26.23 | 82.79 | 58.97 | 58.54 |
where we indeed see that the new version of the base model has a significant lift in the performance on GSM8k comparing to the old version. We remark that SPIN paper observes the most significant increase of SPIN algorithm on GSM8k task (from 26.76 to 35.10). **Since we use the newest model in all our experiments, it leaves much less space for us to improve from.**
2. Second, we should not compare the iter3's 8.63% increase with our paper's 2.66% increase directly. When we say we take $T=5$ and epoch=2 as in Table 3 of our paper, we essential split the data into 5 chunks and generate more frequently than SPIN, but still consume and generate for all the training data for **2 epochs in total** (SPIN iter0 also trained for 2 epochs). So what we need to compare is the first iteration of SPIN (which is SPIN iter0 in SPIN's original paper). In view of Table 3 in our paper, a fair comparison is the following table, note that the baseline is newest version of the model on the newest evaluation codebase (we follow the "iteration" notion in SPIN paper):
*(base model: newest version; evaluation codebase: v0.4.3; test without LoRA)*
| Iterations | zephyr-7b-sft-full | iter0 | iter1 |
| -------- | ------- | ------- | ------- |
| SPIN | 59.48 | 60.32 | 61.02 |
| IRFT | 59.48 | 60.71 | 61.03 |
Essentially **under our fair comparison setting**, every iteration of our proposed algorithm outperforms every iteration of SPIN. We didn't further do experiment for iter2 and iter3 because under our experiment setting, both SPIN and IRFT seem to have less significant improvement from iter0 to iter1 (less than 1 point in average accuracy), and also due to our limited computing resources.
(To be continued)