BenTo: Benchmark Reduction with In-Context Transferability

Thank you for your insightful comments! Below, we address each of your concerns in detail.

Q1: "Evaluating with a smaller sample size poses a risk of overfitting."

A1: Please refer to Q2/A2 in the general response.

Q2: "It is challenging to ensure that the evaluation data in the benchmark is not used in supervised fine-tuning. Reducing the scale of evaluation data likely increases the chances of data contamination bias."

A2: Please refer to Q1/A1 in the general response.

Q3: "This method may be more beneficial for deduplicating training data than for selecting benchmark data. Training typically involves multiple iterations and back-propagation, which entail higher costs and thus require deduplication."

A3: This is an excellent extension of BenTo to training task reduction! In fact, we demonstrate this use case in E2 in the general response, where BenTo is applied to select training tasks for specific target tasks. By identifying high-transferability tasks, BenTo helps focus training on the most relevant subsets of data, reducing computational overhead and increasing efficiency. Your observation aligns well with the broader applicability of our method.

Q4: "I do not think using BENTO to remove evaluation data as a practical approach. Instead, I view BENTO as a metric for assessing benchmark quality rather than eliminating 95% of existing benchmark data."

A4: Thank you for this perspective! While the primary purpose of BenTo is to provide a lightweight and efficient benchmark for rapid iteration and development of models, it might be necessary to still evaluate the final version of a model on the full benchmark.

Your suggestion to use BenTo as a metric for assessing benchmark quality is particularly interesting. A high-quality benchmark should indeed be harder to reduce effectively, as it would require retaining a larger portion of its data to maintain performance. This aligns with our framework, and we appreciate this novel perspective on leveraging BenTo in this context.

Dear reviewer,

Thank you again for your thoughtful comments! We hope that our response and the updated experimental results have addressed the concerns you raised and provided additional clarity on the key points.

As the discussion period draws to a close, we wanted to kindly check if you had any further questions or aspects you’d like to discuss. Additionally, we were wondering if our clarifications and results have sufficiently addressed your concerns to potentially reconsider your evaluation of the paper.

We greatly appreciate your time and feedback and look forward to hearing any additional thoughts you might have.

Dear Reviewer pNg5,

Thanks for your response! However, with all due respect, we would like to argue that our previous response has addressed your concerns with detailed clarifications. To be more specific:

fewer test samples increases the possibility of the test data being included in the training data

Data contamination is out of the main scope of our paper as we focus on improving inference efficiency rather than training. Data contamination is an important open problem and a risk for almost all existing benchmarks because they are public and current large models can easily learn them. Reducing the size of benchmarks may not make it better, but it does not make it worse. Instead of growing the benchmark size, keeping the benchmark dynamically changing and non-public is more effective and efficient to resolve this issue. But this is outside the scope of our work.

testing these benchmarks may not constitute a significant computational overhead

We respectfully disagree. It is a widely known fact that the sequential decoding of LLMs in generating responses does suffer from important computational overhead, especially for tasks requiring longer responses. The overhead multiplicatively or exponentially grows because the evaluation of the benchmarks needs to be repeated many times: they have been repeatedly used worldwide to evaluate different models or checkpoints in the development of every single model. In addition, various recent works [1,2,3] also find benchmark reduction important and share the motivations with us.

I would prefer to apply this method during training

We already provided solid experimental results for training task reduction using BenTo in General Response Part2 - E2 BenTo for selecting training data, which demonstrated the effectiveness of our method in improving the training.

We are eager to hear your feedback and opinions on these. Thanks!

[1] Tinybenchmarks: Evaluating LLMs with fewer examples. 2024

[2] Anchor points: Benchmarking models with much fewer examples. 2024

[3] Improving Model Evaluation using SMART Filtering of Benchmark Datasets. 2024

Thank you for your comment! Our detailed responses regarding each of your concern are listed below.

Q1: "Currently, LLM benchmarks are highly vulnerable to contamination, which diminishes their reliability and credibility. The proposed BENTO method could exacerbate this issue, potentially causing LLMs to focus on a narrower range of tasks, thereby increasing the risk of contamination."

A1: Please refer to Q1/A1 in the general response.

Q2: "It would be valuable to see results on more advanced models, such as Gemini or GPT-4o, to assess the generalizability and scalability of the approach."

A2: Thank you for the suggestion. We have included GPT-4o-mini and GPT-4o in our evaluation. Please refer to E3 in the general response.

Q3: "ICL results can be quite variable. It would be informative to evaluate ICL performance across different models and model sizes."

A3: We have addressed this concern in E1 in the general response. Specifically, we conducted ICL experiments using Phi-2, a smaller model with 2.7B parameters. The results are highly consistent with those obtained using Llama2-13B, the primary model discussed in the paper. This consistency suggests that our method is robust to variations in model size and architecture.

Q4: "Since ICL requires additional sampling iterations, it would be helpful to provide the associated computation costs for reference."

A4: The computational cost of ICL is given by $\sum_{j=1}^N n_jME$, where:

• $N$ is the number of tasks,
• $M$ is the number of ICL exemplar sets,
• $n_j$ is the number of test batches used for the $j$th task, and
• $E$ is the cost of a single forward pass.

In our experiments:

• $N \approx 50$,
• $M = 10$,
• $n_j \approx 10$ to $20$.

This results in approximately 5000 to 10,000 forward passes. However, this does not weaken the efficiency of our method: please see Q3/A3 in the general response.

Q6: "The authors only used 9 models for evaluation, raising concerns about whether the method would still perform consistently across more models. For example, LLaMA2-72B, Qwen2-7B, Qwen2-13B, etc."

A6: We appreciate this suggestion and have added evaluations for additional models, including LLaMA2-70B, Qwen2.5-7B, Qwen2.5-14B, GPT-4o-mini and GPT-4o. Please refer to E3 in the general response.

Q7: "Will the difference in ICL capabilities of different models lead to bias in the evaluation?"

A7: As demonstrated in E1 in the general response, we used Phi-2, a 2.7B parameter model, for ICL testing. The results showed high correlation with those obtained using Llama2-13B, indicating that our method is robust to variations in ICL capabilities across models. This consistency minimizes the risk of evaluation bias.

Q8: "...the methodology for integrating data from these models is not specified—do you simply average the results?"

A8: Apologies for the confusion. We only use one model for ICL testing and estimate ICT only once on each benchmark: as mentioned in Section 5, "ICL is performed on Llama-2-13B and Llama-2-7B to estimate ICT for MMLU tasks and FLAN tasks, respectively." We used the 7B model for FLAN as our computational resources were limited for evaluating some particularly long examples with the 13B model.

Q9: "In the author's experimental setup for FLAN's 66 tasks, 100 questions were selected for each task to be considered as "whole benchmark"(Line 274-275). Does this simplification ensure the validity of the experimental results since FLAN contains 700k+ samples?"

A9: The subsampled FLAN is used as a new evaluation benchmark that is not necessarily of the same distribution as the original FLAN. We demonstrate BenTo's effectiveness and efficiency on further reducing this benchmark—featuring diverse task formats.

When FLAN is used for training, we showed that our method is applicable to the full dataset of FLAN tasks; please refer to E2 in the general response for details.

Q10: "The NRMSE is used to compare the performance differences among methods. If the values were to be expressed in terms of absolute accuracy, what would the corresponding values for the other methods be? (Similar to the data presented in Table 1)"

A10: Please refer to the E3 in the general response.

Q11: "The letter "Q" in Appendix B experiment details has not been defined."

A11: Apologies for the oversight. $Q$ denotes the sizes of the test samples.

Thank you for your detailed and thoughtful comments! We have addressed each of your concerns below.

Q1: "For the ICL transfer tests from task i to task j, what are the sizes of the test samples n_j?"

A1: In our experiments, we use approximately 100 test samples for most tasks. Batch decoding with a batch size of 8 leads to 10–20 forward passes for each ICL exemplar set. Since we have $M=10$ exemplar sets, the total number of forward passes required for each task is 100–200. Note this only need to be done once. Then the reduced benchmark can be repeatedly to replace the original benchmark in many scenarios, e.g., evaluating other models, hyperparameter tuning, etc.

Q2: "...Extensive ICL testing suggests that the model has been evaluated on a full dataset, which contradicts the authors' motivation for efficiently reducing the test set size."

A2: Please refer to Q3/A3 in the general response.

Q3: "The method heavily relies on the careful selection of the parameter k. In real scenarios without prior knowledge, determining the appropriate value for k is a significant challenge that could limit the method's usability in practical applications."

A3: The nature of the greedy algorithm for facility location allows for an adaptive and automatic selection of $k$ with minimal prior knowledge. Specifically, the facility location is submodular (diminishing return) so the objective value will saturate as more tasks being added by the greedy procedure. Hence, we can determine an adaptive $k$ by trying a much larger $K$ and find $1\leq k\leq K$ where the saturation happens or when the transferability is sufficiently large. We will investigate it in more detail for future works.

Q4: "The approach is currently limited to task-level improvements and does not address example-level enhancements."

A4: As discussed in the related works section and section 5.2's experiments ("Task selection and example selection" paragraph), our method can be seamlessly combined with any example-level reduction methods and further improve them. Therefore, we consider task-level and example-level benchmark reduction as two parallel directions.

Q5: "...the subtasks of dataset FLAN used by the authors, such as ReCoRD and SQuADv2, where the number of examples exceeds 10k, does this indicate a lack of usability for the method?"

A5: Our method does not require evaluation on the full test set. As outlined in E2 in the general response, we conduct ICL testing on only 50 samples from the validation set while evaluating on the full test set. Despite this reduced samples for ICT estimation, our method still achieves promising performance, demonstrating its usability and efficiency even for large-scale datasets.

Dear reviewer,

Thank you again for your thoughtful comments! We hope that our response and the updated experimental results have addressed the concerns you raised and provided additional clarity on the key points.

As the discussion period draws to a close, we wanted to kindly check if you had any further questions or aspects you’d like to discuss. Additionally, we were wondering if our clarifications and results have sufficiently addressed your concerns to potentially reconsider your evaluation of the paper.

We greatly appreciate your time and feedback and look forward to hearing any additional thoughts you might have.

Thank you for your thoughtful comments! Below, we provide detailed responses to each of your concerns.

Q1: “... it assumes that in-context performance accurately reflects task transferability, which may not hold true across all tasks or models, especially for weak LLMs. More experiments for weak LLMs should be added.”

A1: We verified the assumption that in-context transfer learning's performance reliably reflects task transferability. To further demonstrate the assumption, we have provided additional experiments with Phi-2, a weaker LLM with only 2.7B parameters much smaller than the Llama2-13B in the main paper. The results, as outlined in E1 in the general response, show high consistency between the transferability estimated using Phi-2 and that of Llama2-13B. These findings strongly imply that the assumption is solid and holds even on weaker models, validating our approach across varying LLM capacities.

Q2: "...Reducing a benchmark to a small subset of tasks may overlook nuanced skills or specific task requirements that LLMs need to perform well in specialized applications, potentially leading to incomplete evaluations in some cases."

A2: As discussed in the limitations section of the paper, there may exist an inherent trade-off between evaluation efficiency and comprehensiveness (the number of evaluation tasks). The very aim of BenTo is to stay on the Pareto frontier, and, maximally preserve the evaluation results on all the benchmark tasks by only evaluating models on a given budget of tasks. While a few nuanced and rare skills or specific task requirements may inevitably be overlooked, BenTo preserves most important skills to be evaluated by selecting representative tasks with the greatest transferability to others.

Q3: "It is necessary to analyze if the reduced benchmark would cause the hurt of robustness for benchmark leakage issue or overfitting to few dimensions."

A3: Please refer to Q1/A1 and Q2/A2 in the general response.

Dear reviewer,

Thank you again for your thoughtful comments! We hope that our response and the updated experimental results have addressed the concerns you raised and provided additional clarity on the key points.

As the discussion period draws to a close, we wanted to kindly check if you had any further questions or aspects you’d like to discuss. Additionally, we were wondering if our clarifications and results have sufficiently addressed your concerns to potentially reconsider your evaluation of the paper.

We greatly appreciate your time and feedback and look forward to hearing any additional thoughts you might have.

Dear Reviewer 3D6d,

Thanks for your positive ratings for the soundness, presentation, and contribution of our paper! We provided new experimental results as requested in your original comments. To summarize:

• We showed that our method is still effective on much smaller LLMs.
• As previous work [1-3] pointed out, benchmark reduction is significant as the benchmarks are supposed to be used for hundreds or thousands of times in the development of many LLMs. There may exist a trade-off between the saved evaluation cost and the robustness/coverage, but we showed that the saving is big and the negative impact is minimal.
• Data leakage is an important open problem. Reducing benchmark size may not make it better, but it does not make it worse, because current LLMs can easily fit and memorize the original benchmarks as well. Instead of growing the benchmark size, keeping the benchmark dynamically changing and non-public is more effective and efficient to resolve this issue. But this is outside the main scope of our work.
• Overfitting to a few dimensions does not happen in our study since our method selects the tasks with the greatest transferability to others, i.e., the ones that bring the greatest improvement to generalization capabilities. We further demonstrated it by new experiments finetuning LLMs on BenTo selected source tasks.

Would you please check if our rebuttal and clarifications above addressed your concerns? We are eager to hear your feedback and would like to answer any further questions before the discussion period ends (which is in two days). Thanks!

Best regards,

Authors

[1] Tinybenchmarks: Evaluating LLMs with fewer examples. 2024

[2] Anchor points: Benchmarking models with much fewer examples. 2024

[3] Improving Model Evaluation using SMART Filtering of Benchmark Datasets. 2024