Author Responses to Reviewer ZgrR
We thank the reviewer for the valuable feedback and constructive suggestions! We hope our responses adequately address the following questions raised about our work. Please let us know if there is anything we can clarify further.
**1. Difference from previous work**
Sorry for being unclear. To the best of my knowledge, there are currently two existing works titled MotionGPT, both of which focus on finetuning large language models (LLMs) for motion generation. However, a critical observation from these studies is that MotionGPT demonstrates suboptimal performance in motion generation. This limitation arises from the unresolved gap between motion and language. In contrast, we utilize a smaller model specifically designed for motion generation, employing a text encoder capable of producing motion-informative text embeddings to bridge the gap between motion and language. This approach yields significantly improved results in motion generation.
Additionally, while MotionGPT requires instruction tuning of the LLM for the motion captioning task, our method for motion captioning does not necessitate such an operation, as our motion embeddings are inherently compatible with the LLM’s understanding. Consequently, we have effectively addressed the intermodal gap, and our proposed method, LaMP, can be integrated with MotionGPT. This integration would involve using LaMP to obtain motion embeddings, followed by instruction tuning of the LLM, potentially leading to enhanced performance on motion captioning tasks. We have added the differences from previous methods in the appendix. (L831-848)
**2. BERT vs. LLM**
Thanks for this insightful question. I believe your question revolves around why LaMP is based on BERT rather than a Large Language Model (LLM). LaMP consists of a motion transformer and a text transformer, both of which are structured based on BERT with shared parameters. If we were to use an LLM as the backbone, we would face several challenges: firstly, the number of parameters that would need fine-tuning would be substantial, resulting in significantly slower inference speeds. Our goal is to ensure that LaMP bridges the gap between motion and language, as well as facilitates motion-text retrieval; hence, a lightweight module is preferable. Otherwise, using it as a text encoder would lead to inefficiencies in processing speed.
Secondly, akin to the first concern, motion embeddings cannot be directly understood by LLMs and may even compromise the LLM's inherent capabilities. LLMs are not well-suited for training with representation tasks as their objective. Consequently, the four proxy tasks we utilize for training would not be effective. Thus, we choose BERT as the backbone for this purpose. To address your concern, we also attempt to train using LLMs; however, due to their large number of parameters, they present significant challenges in terms of training feasibility.
**3. Text caption model**
Thanks for this constructive comment. In the field of natural language processing, decoder-only model architectures are generally considered more suitable for text generation tasks, such as GPT. BERT, as an encoder-only model, employs a bidirectional attention mask, making it more adept at text understanding and inference tasks. Thus, you are correct that BERT does indeed have its limitations. Furthermore, during the first stage of training LaMP, we also utilized motion-grounded text generation as one of the proxy tasks. To address the reviewer's concerns, we conduct an evaluation of LaMP's own motion-to-text capability, as illustrated in the first row of Table 1.
| Method | Top 1 ↑ | Top 3 ↑ | MultiModal Dist ↓ | BertScore ↑ | Bleu@1 ↑ | Bleu@4 ↑ | Rouge ↑ | Cider ↑ |
| -------------- | ------------- | ---------- | ----------------- | ----------- | -------- | -------- | ------- | ------- |
| LaMP | 0.397 | 0.663 | 4.076 | 17.8 | 30.1 | 6.87 | 26.6 | 16.2 |
| LaMP-M2T (Ours)| 0.547 | 0.831 | 2.808 | 32.7 | 47.8 | 13.04 | 37.1 | 28.9 |
Table 1. The quantitative results of motion captioning on the HumanML3D.
**4. CFG scale**
Sorry for being unclear. We did not make any further adjustments to these two parameters and simply followed MoMask. Additionally, I apologize for not specifying the CFG scale of HumanML3D in the text. In HumanML3D, CFG scale is 4, and in KIT-ML, CFG scale is 2.
We have corrected this in the revised manuscript (L459).