In the era of large language models, model merging is a promising way to combine multiple task-specific models into a single multitask model without extra training. However, two challenges remain: (a) interference between different models and (b) heterogeneous data during testing. Traditional model merging methods often show significant performance gaps compared to fine-tuned models due to these issues. Additionally, a one-size-fits-all model lacks flexibility for diverse test data, leading to performance degradation. We show that both shared and exclusive task-specific knowledge are crucial for merging performance, but directly merging exclusive knowledge hinders overall performance. In view of this, we propose Twin-Merging, a method that encompasses two principal stages: (1) modularizing knowledge into shared and exclusive components, with compression to reduce redundancy and enhance efficiency; (2) dynamically merging shared and task-specific knowledge based on the input. This approach narrows the performance gap between merged and fine-tuned models and improves adaptability to heterogeneous data. Extensive experiments on $20$ datasets for both language and vision tasks demonstrate the effectiveness of our method, showing an average improvement of $28.34\%$ in absolute normalized score for discriminative tasks and even surpassing the fine-tuned upper bound on the generative tasks. Our implementation is available in \url{https://github.com/LZY-the-boys/Twin-Merging}
Paper
Similar papers
Peer review
Summary
This paper investigates a dynamic and compressive merging method for adapting large-scale models to multiple tasks. The authors claim that adjusting the ratio between shared knowledge and exclusive knowledge is crucial for high-performing model merging, and they devise an algorithm that learns proper coefficients to merge those two kinds of knowledge in a data-dependent manner. They further compress the task-specific exclusive knowledge via SVD to reduce memory storage during merging. They validate their method with language models on discriminative and generative tasks.
Strengths
- Remarkable performance improvement compared with baselines - The proposed dynamic merging method can be memory-intensive during inference time because it requires all task-specific modules to be stored, but the author mitigates this somewhat via SVD compression. The combination of dynamic merging and compressive merging is very impressive, which induces better performance while considering practical usefulness
Weaknesses
- Lack of technical details on the most important part of the methodology - The router module plays a crucial rule that produces input-dependent merging coefficients during inference time. However, the authors do not provide any technical details on the training of the router module (including appendix). - Model architecture and training configurations should be provided. - Moreover, a description of the validation set the authors to use for the router training should be provided. The authors only describe that dataset as '**_a small validation set_**'. Does the validation set consist of the integration of downstream tasks? or general text corpus? and how the construction of the validation set affects the final merged model performance. - I believe details on the construction and amount of samples for the validation set should be presented. - Limited scope of validation - While they evaluate their method with fully fine-tuned models on discriminative tasks, they only validate it on the parameter-efficient fine-tuning regime for the generative tasks. As one of the proposed method's main contributions is parameter compression, it would be more effective when they show the applicability of their method on fully fine-tuned model merging with decoder-only LM or encoder-decoder LM. - Concerns about scalability - While the compressive merging reduces the requirements of memory storage during the inference phase, I speculate that the amount of computation for the merging operation is still a huge burden. The input-dependent dynamic merging requires computations for merging operation per every sample, and I wonder about the **runtime and computation cost during inference phase when the fully fine-tuned models are the target of validation** rather than the parameter-efficient fine-tuning regime in Table 7.
Questions
- details on router network architecture and its training (refer to weakness section) - details on the validation set construction (refer to weakness section) --- If there is a misunderstanding from me, please don't hesitate to refute it. I would be happy to discuss this further.
Rating
6
Confidence
4
Soundness
3
Presentation
2
Contribution
3
Limitations
Lack of scalability to larger models due to increasing inference cost of instance-dependent dynamic merging.
I appreciate the authors' kind response! Some of my concerns are addressed. * I still think that TwinMerging's inference time overhead compared with the vanilla task arithmetic in Table 2 of global response is significant (about two times), given that group-wise extension is not included in the reviewed manuscript. * Moreover, as from your answer, TwinMerging requires labeled samples from ALL test domains in advance (even though it is validation splits), which is an optimistic assumption compared with AdaMerging, which only requires unlabeled test domain data.
We thank the reviewer for the feedback. We will address the additional concerns below. > Q1 Our original approach significantly outperforms both AdaMerging and Surgery in terms of speed and performance. As evidenced by 1st table from the global rebuttal, our method completes in just 47m22s, compared to 185m35s / 215m01s for AdaMerging/Surgery. Despite the substantial time savings, our approach also delivers superior performance, achieving a score of 95.33, versus 88.50 / 94.40 for AdaMerging / Surgery, **the latter methods invest over 10 times the effort to marginally improve performance**. Furthermore, our group-wise variant that matches the efficiency of Task-Arithmetic (5m14s vs 4m52s) still holds superior performance (92.02 vs 67.80). We will include this variant in the revised version of our paper. > Q2 To clarify, AdaMerging requires **the actual test sets** (as confirmed in Section 3.2.2 of the original paper, or the code from `src/datasets/common.py` line 142 in the original codebase). This means that, for the example in Table 5, for the unseen domain dataset, AdaMerging theoretically requires access to these unseen domain test sets to approximate the optimal model, though without true labels. This poses a significant challenge for online deployment scenarios, where test inputs are unpredictable and streaming. Even if we can access to the test set in in offline scenarios, scaling the test set to a large number, such as 1,000, makes the process highly inefficient. Additionally, AdaMerging relies on entropy optimization for unsupervised training, making it **applicable only to classification tasks**. Given the growing dominance of large **generative** foundation models like LLaMA, GPT-4, and diffusion models, AdaMerging’s focus on classification limits its scalability and applicability. In contrast, our approach only requires in-domain validation data corresponding to each expert. For instance, in Table 5, we used 5 experts to handle 3 unseen datasets, necessitating only the validation sets corresponding 5 experts. This is because the validation dataset is meant to enable the router to learn and identify specific exclusive knowledge in domain. Please notice that this training process is **agnostic to the actual test distribution**. Whether the test distribution scales to 10, 100, or even 1000 tasks, we still only need those initial 5 validation datasets. Our method, however, is versatile and can handle any type of task, including generative tasks with Qwen-14B in Table 2, and scales up to **72B** on generative tasks (Table 3), offering broader applicability and alignment with current AI trends.
I want to express my severe gratitude for the authors' kind response and my regret for my unprofessionalizm, such as the score-reversing behavior. Thanks to the discussion with the authors, I could also extend my sight, not only gain a clearer understanding of the paper. I will raise my rating accordingly.
Thank you
We appreciate the reviewer's recognition of our work's effectiveness and the score increase. We will revise our work to include clearer illustrations. Thank you for your time and valuable suggestions!
Summary
This paper attempts to resolve an issue of destructive interference with model merging techniques. It proposes to maintain a shared base model and separate task-specific knowledge structures that can dynamically be combined at test time. The paper presents some a nice to buttress the drive home their methodology
Strengths
- Code provided - Initial analyses of the existence of interference even when separate parameter sets are fine-tuned with LoRA is interesting though a bit obvious in hindsight be useful to empirically validate - Initial experiments validate the hypotheses of interference and shared / exclusive knowledge - Reasonably thorough experimentation
Weaknesses
1. My primary issue with the paper is why this is a viable alternative to just keeping the base model back-bone and LoRA low-rank vectors of similar rank to the $v_t$s (Algo 1) (and instantiating the task specific model on the fly). Twin-Merge has memory overhead (v_t for T tasks) which brings it more into the realm of “saving task-wise adapters/LoRA” whose size grows as the number of tasks. It is unclear from the existing set of experiments why a practitioner would use this method over keeping separate task low-rank (small memory footprint) adapters and just using these at test time (either statically per task or dynamically — https://arxiv.org/pdf/2306.14870 ) ? 1. I understand that the paper performs a primary comparison to other model merging methods like DARE and Task Arithmetic but these methods have zero extra memory overhead (after the model is merged) — they don’t enjoy the expressivity that test time adaptation + extra memory gives them. 2. Claims of generalization to unseen tasks might not be valid. Specifically, it is interesting to see that the boost in performance for Twin Merging in Table 2 is much more significant than for Table 5 with unseen generalization. This makes me wonder if the deltas in table 5 are actually significant. I am open to raising my score if the authors can convince me of the utility of the method -- in light of [1] above.
Questions
* How are the $v_t$s represented / stored (Algorithm 1) ? * Are the v_ts stored as the low rank matrices that are later multiplied to obtain the appropriate matrix size ? As written, it seems like each $v_t$ is of size equal to the size of the full parameter space and so ends up as a memory burden. * For Figure 4 (right), is the fine-tuned storage size much larger because you are doing full fine-tuning instead of LoRA fine-tuning ? * If you are doing LoRA fine-tuning is the gap because the rank of the lora matrices are larger >> than the rank of the final $v_t$s above ? * Maybe I missed this but where is the “(Best Storage)” option for Twin Merging in Table 2 described ? * For Table 4, would it be possible to provide the results for Twin-Merging only before showing the additive results ? It’s hard to make out whether the other methods are contributing anything at all
Rating
6
Confidence
4
Soundness
3
Presentation
4
Contribution
3
Limitations
Broader impact statements and limitations are discussed in the paper
Summary
`Twin-Merging` proposes a method for task merging which tackles two issues: * Task interference: The proposed `Twin-Merging` explicitly model shared vs task-specific knowledge to potentially reduces redundancies across the task vectors, which may lead to subpar task merging results * Dynamic merging: Usually, task merging weights are only task dependent and determined only once. In contrast, here, the weights are determined at the input level using a router akin to Mixture of Experts design.
Strengths
* Compressing the task vectors using SVD is beneficial for memory usage * Performance improves over standard task merging approaches * Experiments are also conducted on large scale models (72B)
Weaknesses
* **The per-input routing design seems highly impractical**. If I understood correctly, the task merging weights are compute on-the-fly for each individual input. This means that: * The design does not support batching as we need a different merged model for each input in the batch * Every time a new input comes, we need to first get the merging weights by executing the fuser, then uncompress the task vectors, build the merged model, and finally run the inputs through it. This does not seem very hardware friendly, even if the task vectors are low-rank compressed using SVD. In contrast, in standard task merging, we only ship one merged model. * Because the fuser $\mathcal{R}$ takes as inputs the *last-layer token embeddings from the shared expert* (line 186), does it mean that every input require two forward passes (one through the fuser, then one through the merged model) ? - The paper does not really convey the importance/novelty of **knowledge modularization** strongly enough. In essence, the basic task arithmetic (**A**) already performs some form of modularization where the pretrained model is the *shared knowledge* and task finetuned models (task vectors) are *task specific*. In contrast, knowledge modularization(**B**) **redefined the task vectors** relatively to the merged model (rather than the pretrained one) and compress them via SVD. In my opinion, comparing **A** and **B** would be a better ablation experiment than the one in Table 6 where the merged expert is replaced by a random specific one. - **Baseline**: Since the proposed design uses additional validation data (to finetune the router), it would be fair to also compare to the more recent/stronger baseline `AdaMerging: # Adaptive Model Merging for Multi-Task Learning` (Yang et al), which also assumes extra data available.
Questions
* I do not fully understand the conclusion of **Section 3.1**: * the assumption of `Ties Merging` is that redundant parameters can be hard to merge. But they do not really make assumptions on whether these parameters were trained jointly/with overlap > therefore I'm not sure how the LoRA experiments contradicts this insight: Even if the LoRA modules are trained separately, they may still have redundant statistics at the end of training ? * Similarly, the notion of *similar tasks* or *task interference* is hard to define in general. So it is not clear to me how significant the results of the XSUM/DailyMail experiment are. * Based on the result of table 4.5 it looks like Twin Merging does not often behave as a model merging method ? It seems that most of the time the samples are routed to their respective task-specific experts. If that insight is true, it is not too surprising that `TwinMerging` performs on-par with the finetuned baseline. * In Table 7: Shouldn't `Model Merging` and `Twin Merging` also integrates the cost of training the initial task vectors in **training cost** ? Otherwise it seems unfair to the MTL baseline.
Rating
6
Confidence
3
Soundness
2
Presentation
3
Contribution
2
Limitations
The paper discusses limitations inherent to task merging in appendix F. However, as discussed in the Weaknesses section.
Summary
In this paper, the authors introduce the Twin-Merging to merge language models, aiming to close the performance gap between conventional model merging techniques and fine-tuned models, while improving adaptability to data heterogeneity. By modularizing and dynamically merging shared and task-specific knowledge, the authors show that Twin-Merging outperforms existing model-merging methods and approaches the performance of fine-tuned models across various settings and domains.
Strengths
+ The paper is overall well written and easy to follow. The idea of dynamic merging to dynamically merge shared and exclusive knowledge based on the test inputs is interesting. + The experiments show clear superiority over prior methods.
Weaknesses
+ The proposed method dynamically merges the models with the varying inputs, which can be extremely time-consuming in practice. It would be better if the authors propose some mechanisms to address this issue. + In figure 3, the authors compare 1-model merging with 8-model merging. Why here 8-model merging is used for comparisons? Why not 2-models merging is compared? More explanations should be provided here. + Some highly related works are missing in the related work section, such as MuDSC[1]. The differences between these works should be clarified. [1] Training-Free Pretrained Model Merging, CVPR 2024 [2] REPAIR: REnormalizing Permuted Activations for Interpolation Repair, ICLR 2023.
Questions
Please see the Weaknesses
Rating
5
Confidence
5
Soundness
3
Presentation
3
Contribution
3
Limitations
N/A
Response
Hi authors, Thanks for your response. And including the additional baselines. > Directly Route to Top-1 Expert I'm wondering why you decided to do only Top-1 expert in this baselines instead of soft router weights like you do. I think a better comparison would have been to have Top-K or even just a soft routing like you guys have in the paper. This would then be a better way of demonstrating that Twin merge is superior. As it stands I don't think there is sufficient evidence to say your method is better than the simple LoRA adapter router baseline -- esp given the relatively small delta (102.38 > 100.0) (how does this breakdown to individual task scores btw ?) Based on the explanations and updated experiments. I'm raising my score -- but it would be great if the more extensive version of the experiment above (as I mentioned, is included in the paper)
We thank the reviewer for raising the score! We will address the additional comments below. > Q1. why listed Top-1 expert as baseline in original paper, not the "soft merging" method We choose the "Route to Top-1 Expert" as an **oracle** baseline to highlight the performance gap between common merging techniques and **the ideal scenario**. Because this baseline typically performs the best [1], as shown in the table below (taken from the response to Q1): | Method | RoBERTa | Qwen| |-|-|-| | Top-1 (oracle) | 100.00 | 100.00 | | Pretrain+Dynamic Merging(A) | 85.90 | 97.03 | | Shared+Dynamic Merging(TwinMerging,B) | 96.14 | 102.38 | The "soft merging" (A) performs worse than the oracle, due to the interference between the different models, which is consistent with the findings in [1]. However,Twin-Merging mitigates it by modularizing shared and exclusive knowledge, leading to improved performance and, in some cases, even surpassing the oracle baseline (102.38 > 100.00). We appreciate the reviewer's suggestion to include the "soft merging" as a baseline for better clarity. We will incorporate this into our revised version of the paper. > Q2. unsufficient evidence to say your method is better than the simple LoRA adapter router baseline -- esp given the relatively small delta (102.38 > 100.0) (how does this breakdown to individual task scores btw ?) We’ve provided a detailed breakdown of the scores in Table 9, Appendix D7. It’s important to note that the LoRA router baseline represents the **oracle performance**, which typically achieves the best results, as explained in the above. Surpassing this baseline is extremely challenging. However, our method achieves nearly identical performance ( 99.87 vs. 100 on MMLU) or even outperforms the oracle in some datasets (over a 14% improvement on CNN/DM). Additionally, a key limitation of the simple LoRA router baseline is its difficulty in adapting to unseen tasks, as the router often struggles to predict the correct top-1 result. In contrast, our approach demonstrates better performance on unseen tasks (as shown in Table 5), leveraging complementary knowledge from different exclusive sources to enhance collective intelligence. [1] Exploring the Benefits of Training Expert Language Models over Instruction Tuning [ICML23]
Sorry for my reverse (6 -> 5), but I would like to discuss my second worry with the authors further. After reviewing the authors' responses, I still lean toward the negative side due to their reliance on the validation set. While the method is agnostic to the test distribution, its effectiveness is unclear under severe distribution shifts in image domains (that AdaMerging focuses on) compared to distribution shifts in language domains. That is, I still doubt the performance sensitivity against distribution shifts and varying amounts of validation set. Moreover, in the real-world deployment scenario, I think it is much harder to gather validation sets for each merging ingredient fine-tuned model from different institutions (due to commercial / privacy issues) compared with test-time unlabeled incoming samples. Given that, my concerns about Twin-Merging's reliance on ID validation still seem to be weaknesses, even though it boosts performance significantly.
Thanks for your feedback. We will address the concerns below. > Q1: image domain distribution shift & varying amounts of validation set We want to clarify that **our method addresses distribution shifts through dynamic merging, which adapts to test inputs**, as shown in our NLP results (Table 5) and Section 4.5, although the preprocessing stage (router training/knowledge modularization) is indeed agnostic to the test distribution. To address your specific concern, we conduct additional experiments on image domain shifts using Gaussian noise corruption. The results demonstrate that Twin-Merging is robust against image domain distribution shift. | Method | Avg. Before Corruption | Avg. After Corruption | |-|-|-| | Task-Arithmetic | 84.3 | 65.6 | | AdaMering | 91.7 | 73.4 | | **Twin-Merging** | **96.9** | **79.2** | In terms of varying amounts of validation set, we actually have a related experiment in Figure 4, where the router validation set is varied from 2,000 to 7,000, and we can observe consistent superior performance. To further demonstrate, We also add experiments with reducing the validation data number to 100 per task for generative tasks, which is 1/10 of the original size, and we observe that the performance does not change significantly: | Method | val-1000 | val-100 | |-|-|-| | Twin-Merging | 102.38 | 101.23 | > Q2: harder to gather validation sets for each merging ingredient fine-tuned model from different institutions (due to commercial / privacy issues) Firstly, to clarify, **our approach does not strictly require the validation set to be taken from each in-domain dataset used by the experts**. For example, we can utilize the opensource Dolly dataset to represent the MMLU expert (L619-L620). Furthermore, **we do not need to gather validation datasets for all experts**. As illustrated in Table 5, our approach still works effectively without gathering specific validation datasets for QNLI, MNLI, RTE, and MMLU. In practice, we can select a subset of accessible experts and gather representative validation data for them, which is typically not difficult. This actually stems from the key assumption of our approach, that **in-domain knowledge contains complementary elements that can effectively address out-of-domain inputs when combined properly [1,2]**. By dynamically inferring optimal weights to combine this modularized knowledge based on the test input, our method offers better collective generalization against the unpredictable heterogeneous input. In contrast, AdaMerging may limits in imprecise entropy approximation and the lack of supervised guidance. To better demonstrate the advantage of our approach, we conducted additional generalization experiments using the same settings as in the AdaMerging paper: | Method | EuroSAT | MNIST | Avg. Acc | |-|-|-|-| | AdaMering | 45.9 | 90.1 | 68.0 | | **Twin-Mering** | **53.2** | **92.9** | **73.5** | Secondly, we want to emphasize that our approach is primarily designed for **real-world LLM online serving**, where models are deployed with a continuous stream of inputs without gradient updates, aligning with trends in LLM deployment [3,4]. - **Unpredictable, Heterogeneous Data Streams**: The nature of these data streams means that traditional batch techniques are inefficient, and any single expert is insufficient. This is why we introduce our dynamic merging technique. - **Latency and Storage Considerations**: To address critical concerns around latency and storage, we shift time-consuming router training and knowledge modularization to the preprocessing stage. Additionally, we employ SVD techniques to reduce storage requirements. A detailed analysis of the FLOPs for these serving scenarios is provided in the global rebuttal. - **Broad Applicability**: Our method applies to both NLP and CV domains, spanning discriminative and generative tasks, making it highly adaptable for deploying and scaling AI models. In contrast, the AdaMerging post-training technique incurs significant latency due to its reliance on test-time training, making it more suitable for offline evaluations rather than real-time LLM deployment. [1] Fusing Models with Complementary Expertise [ICLR24] [2] Knowledge Fusion of Large Language Models [ICLR24] [3] Mooncake: Kimi's KVCache-centric Architecture for LLM Serving [4] LLM Inference Serving: Survey of Recent Advances and Opportunities
Sincerely looking forward to your feedbacks
We sincerely appreciate your valuable feedback and concerns regarding the clarity of our descriptions and the validation sets. We hope our response has effectively addressed all your concerns. Your insights are crucial for improving our work, and we are open to further discussion if you have any questions about our response. With the effectiveness in merging performance (even outperforming the oracle at times), efficient storage, minimal time cost, and a reasonable assumption regarding the validation dataset—as recognized by Reviewer `2gMR` and `Q3uE`—we believe that our approach will become increasingly practical and significant in the era of large language models. We hope that these insights and outcomes can contribute to the community. We appreciate your time and would be very grateful if you could re-evaluate the paper’s rating.
Dear authors, thanks for your response and clarifications: * The new ablation on A vs B is more convincing in showing the benefit of explicitly building shared/specific task vectors * The group-wise variant of Twin-Merging is interesting, and it's good to see that performance of the method does not drop significantly in that case. However I do wonder how it would perform Since my main concerns have been addressed, I will raise my score to weak accept: Overall I think the paper is technically solid, and I appreciate the authors' effort in clearly portraying the efficiency/memory cost of the method. However, I also think that the paper introduces several new assumptions departing from traditional task merging (labeled data + extra parameters/router model + per-input dynamic behaviour requiring extra processing for batched inference), and the writing would further benefit from making these differences clearer for fair comparison (e.g. it would be more fair to make Adamerging the standard baseline in the experiments section since it also requires extra but unlabelled data in contrast to Ties-Merging). **Note:** ~[NIPS23]~ -> [NeurIPS23]
We thank the reviewer for their feedback and for raising the score! We will address the additional comments below. > Q1. I wonder how group-wise merging would perform The insight is that the router logits indicate the relevance of different exclusive knowledge modules to specific input samples. Inputs have similar router logits require similar knowledge, i.e., similar merging models. To leverage this similarity, inputs can be grouped based on their router logits. Within these groups, the merging weights are expected to be similar and can be approximated by an averaged representation. To begin, you can divide the inputs into bins based on the arg-max indices of the router logits, which represents the most relevant domain or knowledge module for each input. To further refine into groups, apply K-means clustering within each bin directly on the router weights. Once the clustering is done, average the router weights within each group. The model is then merged based on these averaged router weights, allowing the inference for the entire group to be performed using a single model. > Q2. the paper introduces several new assumptions departing from traditional task merging (labeled data + extra parameters/router model + per-input dynamic behaviour requiring extra processing for batched inference) To clarify, we want to highlight that these assumptions are not entirely new but build upon those in previous works such as FisherMerging (NeurIPS22), DARE (ICML24), and Surgery (ICML24). FisherMerging, for instance, utilizes a validation dataset to adjust merging weights. DARE introduces pre-merging techniques like Sparsify to enhance performance, while AdaMerging and Surgery focus more on post-merging techniques. Specifically, AdaMerging assumes access to an offline test set and dynamically adapts to it by introducing additional coefficients at every layer, conducting unsupervised training across multiple iterations on the test set (without labels) to refine the model. Surgery goes even further by assuming that test data IDs are accessible during inference, allowing it to insert corresponding task-specific adapters to leverage task-specific knowledge. In contrast, our key insight is that **in-domain knowledge, when combined appropriately, can effectively address out-of-domain inputs**, eliminating the need for offline test dataset access or test ID information. To achieve this, we significantly reduce the additional parameters required, moving from several task-specific adapters across the entire model to highly sparsed exclusive knowledge representation and a single, simple MLP that infers optimal weights for combining modularized knowledge based on the test input. We train this MLP using a small validation dataset rather than an unlabeled test set, which is more suitable for LLM serving, a current trend in AI. It is important to emphasize that, like previous methods, our approach only uses **a single merged model** to actually perform the task during the inference phase. In summary, while our method introduces techniques across preprocessing, additional parameters, and post-merging stages—similar to previous methods—it is distinct in its approach and insight. This distinction is validated by our experimental results, which demonstrate superior performance with only 1/4 the effort of AdaMerging and 1/5 the effort of Surgery (47m22s vs. 185m35s/215m01s) and just 15.4% of the storage cost of Surgery (5.0GB vs. 32.4GB). We aim to further refine these assumptions in future work. > Q3. the writing would further benefit from making these differences clearer for fair comparison We thank the reviewer for the suggestion. We will further elaborate on the differences between previous merging methods and incorporate the AdaMerging comparison into our revised version of the paper.
We sincerely appreciate your valuable feedback and concerns regarding the clarity of our descriptions. We hope our response has effectively addressed all your concerns. Your insights are crucial for improving our work, and we are open to further discussion if you have any questions about our response. With the effectiveness in merging performance (even outperforming the oracle at times), efficient storage, minimal time cost, and a reasonable assumption regarding the validation dataset—as recognized by Reviewer `2gMR` , `Q3uE` and `LqLU`—we believe that our approach will become increasingly practical and significant in the era of large language models. We hope that these insights and outcomes can contribute to the community. We appreciate your time and would be very grateful if you could re-evaluate the paper’s rating.
Decision
Accept (poster)