Paper: GPT-Driver: Learning to Drive with GPT (ICLR-2024)

Reviewer comment (Novelty):
While I personally appreciate the simplicity and effectiveness of this research, I do not believe it possesses sufficient novelty to be a paper for ICLR. The article simply utilizes the ChatGPT API for finetuning, which can be regarded as an application experiment report on motion planning using ChatGPT. Since it does not introduce any new modules or methodologies, I think its actual contribution to the field is quite limited.

Author response:
**While I personally appreciate the simplicity and effectiveness of this research, I do not believe it possesses sufficient novelty to be a paper for ICLR. The article simply utilizes the ChatGPT API for finetuning, which can be regarded as an application experiment report on motion planning using ChatGPT. Since it does not introduce any new modules or methodologies, I think its actual contribution to the field is quite limited.**

We believe our method has sufficient novelty to be a paper for ICLR for the following reasons:

(1) Our proposed motion planning as language modeling is a fundamental change to the current regression-based planning methods. As we mentioned in Section 3.2, motion planning as language modeling is **essentially transforming the typical regression problem into a coarse-to-fine region classification problem**, which overcomes the weaknesses of regression (e.g. sensitive to scale variation). Hence we argue that we did introduce new methodologies in our paper.

(2) From the architecture's perspective, our approach **transforms the conventional MLP-based planner by introducing fine-tuned LLM as a motion planner**, which is a fundamental architectural change. Compared to the MLP-based planner, our approach can benefit from the LLM and demonstrates superior generalization ability (see the few-shot learning results) and interpretability, thus enabling a more robust and transparent decision-making process. 

(3) Our observation that **LLMs can perform low-level motion planning and estimate very accurate numerical coordinates** is also unique. While a lot of papers are working on leveraging LLMs for language-based task planning, we are the first to demonstrate that LLMs can also perform motion planning and accurate numerical predictions. We believe this observation also brings new insights and merits to the research community.

Overall, the proposed method is simple and can be implemented in a few lines of code. Although the idea is intuitive, the learning objective, architecture, and observations are unique and completely different from existing approaches. Hence, we believe our method has sufficient technical contributions to be accepted to ICLR.

Reviewer comment (Experiments):
Motion planning ultimately needs to be validated in a closed-loop system, as the results from open-loop and closed-loop scenarios are not always aligned, as highlighted in [1]. In cases where perception results (or ground truth) are directly used as input, it is easy to integrate into a closed-loop system, and there are numerous readily available public datasets for closed-loop testing, such as Nuplan, Waymo Motion Dataset, MetaDrive, etc. If closed-loop results could be obtained, I believe it would significantly enhance the credibility and contribution of the paper.

Author response:
**Motion planning ultimately needs to be validated in a closed-loop system, as the results from open-loop and closed-loop scenarios are not always aligned, as highlighted in [1]. In cases where perception results (or ground truth) are directly used as input, it is easy to integrate into a closed-loop system, and there are numerous readily available public datasets for closed-loop testing, such as Nuplan, Waymo Motion Dataset, MetaDrive, etc. If closed-loop results could be obtained, I believe it would significantly enhance the credibility and contribution of the paper.**

We appreciate the review's suggestion and we also agree with this point. We're now working on adapting GPT-Driver to close-loop evaluation on nuPlan. Since nuPlan is much larger than nuScenes, we are unable to get the close-loop performance in this short discussion phase. We will update the paper once we have finished the experiments.

Reviewer comment (Novelty):
The descriptions in the RELATED WORKS section of the article are somewhat inaccurate. Dauner et al. (2023)[1] is actually a rule-based method.

Author response:
**The descriptions in the RELATED WORKS section of the article are somewhat inaccurate. Dauner et al. (2023)[1] is actually a rule-based method.**

From our understanding, Dauner et al. (2023)[1] is a hybrid approach that leverages rule-based IDM to generate an initial trajectory and then applies a learning-based neural network to refine the trajectory. For better clarification, we have moved this literature to the rule-based method according to the review's feedback.

Reviewer comment (Experiments):
I hope to see closed-loop results; please refer to the "Weaknesses" section for more details.

Author response:
**Motion planning ultimately needs to be validated in a closed-loop system, as the results from open-loop and closed-loop scenarios are not always aligned, as highlighted in [1]. In cases where perception results (or ground truth) are directly used as input, it is easy to integrate into a closed-loop system, and there are numerous readily available public datasets for closed-loop testing, such as Nuplan, Waymo Motion Dataset, MetaDrive, etc. If closed-loop results could be obtained, I believe it would significantly enhance the credibility and contribution of the paper.**

We appreciate the review's suggestion and we also agree with this point. We're now working on adapting GPT-Driver to close-loop evaluation on nuPlan. Since nuPlan is much larger than nuScenes, we are unable to get the close-loop performance in this short discussion phase. We will update the paper once we have finished the experiments.

Reviewer comment (Experiments):
The benchmark comparison seems a bit apples to oranges. You compare against end-to-end computer vision approaches from CVPR, but your approach assumes the object detections are given and only solves the planning part. Even if you use the detections from a competing CV method, it is unclear to me how strong this result is as planning is perhaps not the main focus of their approach. It would have been good to have some conventional planning stack as baseline as well.

Author response:
The benchmark comparison is **clearly not apples to oranges** for the following reasons: 

(1) We are comparing against end-to-end driving approaches in CVPR mainly because these papers are the state-of-art approaches on the nuScenes motion planning benchmark. 

(2) Our approach assumes the object detections are given because our approach focuses on motion planning. As we mentioned in the experiments, we also leverage the same detection outputs as UniAD. Hence from the perspective of motion planners, our approach and UniAD have the same detection inputs, which is a fair comparison. 

(3) Planning is the main focus and the ultimate optimization goal of these end-to-end driving methods. The title of UniAD is "Planning-oriented Autonomous Driving", and all the detection and prediction modules are optimized for better planning. Hence, it is clear that motion planners in these baseline methods are strong enough for comparison. Our comparison is completely fair with these baselines.

(4) We agree with the point that it's good to have conventional planning baselines. We didn't compare with conventional planning mainly because there are no published convention planning methods on the nuScenes motion planning benchmark. We will try reproducing some approaches on the nuScenes benchmark in the future.

Reviewer comment (Novelty):
Your portrayal of related work outside of CV/learning seems weak/dated with the most recently cited planning paper being from 2018. I quite frequently see conventional planning/optimization papers for autonomous driving at other venues (robotics, AI...). Check some recent surveys, I include one which does not use your terminology of "rule-based" for these either (not sure what you mean by that). [1] S. Teng et al., "Motion Planning for Autonomous Driving: The State of the Art and Future Perspectives," in IEEE Transactions on Intelligent Vehicles, vol. 8, no. 6, pp. 3692-3711, June 2023, doi: 10.1109/TIV.2023.3274536.

Author response:
Learning-based and rule-based planning are two mainstream motion planning approaches in the context of autonomous driving. In the survey paper "Motion Planning for Autonomous Driving: The State of the Art and Future Perspectives" you have provided, they focus on introducing planning methods based on imitation learning and reinforcement learning, which has already been covered in this paper. For other optimization-based planning approaches, we believe you're referring to control methods, which aim to output more low-level control signals to trace the trajectory and avoid collisions. Optimization-based control is actually a downstream task to motion planning and is out of the scope of this paper.

Reviewer comment (Experiments):
This really is "GPT"-driver, it just uses the web APIs for ChatGPT for prompting and fine tuning. GPT is state of the art (at least if you had used 4.0) so is somewhat defensible, but it would have been interesting to see how this generalized across other LLMs.

Author response:
We agree with this point. We are working on fine-tuning llama 2 for motion planning, and we will update the results soon.

Reviewer comment (Theory):
You write "Albeit simple, these approaches attempt to simultaneously regress waypoints across different scales, e.g. coordinate values ranging from 0 to over 50, which generally results in imprecise coordinate estimations of the more distant waypoints": This seems like it would be fixed by a simple rescaling, is this really a fundamental problem with IL approaches? This also does not mention RL-based approaches (see [1]).

Author response:
Rescaling mitigates the effects but the errors can be amplified when you rescale the regression outputs back to their real values. Hence it is an innate weakness of leveraging regression to resolve the imitation learning problem.

Reviewer comment (Theory):
Sec 3.2: Does all of the IL approaches really use absolute value loss, that seems oddly specific? The discussion of how a number is encoded as a text string seems pretty obvious/trivial.

Author response:
State-of-the-art methods (e.g., UniAD, ST-P3) on nuScenes rely on the regression of real-world coordinates. Our discussion reveals the essential difference between regression and language modeling in imitation learning for motion planning, and our language modeling approach is simple to implement and demonstrates promising results compared to those regression-based methods, which we believe is a major contribution and not trivial.

Reviewer comment (Writing):
"It is worth noting that these state-of-the-art planners heavily rely on multiple heterogeneous observations such as detections, predictions, occupancy grids, and maps, which makes their systems intricate and time consuming." You rely on their detections (maybe predictions, unclear) so this seems at least half misleading.

Author response:
These state-of-the-art planners, such as UniAD, take compact maps (H xW grids) and occupancy (H x W x T grids), in addition to perception and prediction, as inputs to their motion planner. Extracting those compact maps and occupancy grids makes their system intricate and time-consuming. By contrast, our approach only leverages text-based perception and prediction (instead of compact maps and occupancy grids) as inputs to GPT-Driver, which is more lightweight compared to these methods. We have revised this part for better clarification.

Reviewer comment (Experiments):
What data did you use for fine tuning vs evaluation? I am not very familiar with this particular benchmark, but your trajectory prediction errors are surprisingly low. The optimal trajectory for driving is in reality sometimes ambiguous, possibly multi-modal and an open research problem, so it seems a bit suspicious that you can get centimeter precision on trajectory prediction.

Author response:
As we mentioned in Section 4.1, we leverage the training set of nuScenes for fine-tuning our GPT-Driver, and the validation set for evaluating our approach. This is a commonly adopted training and evaluation protocol on nuScenes and ensures a fair comparison with the baselines on the nuScenes dataset. Trajectory prediction errors are low compared to the baselines, demonstrating the effectiveness of our approach. Although trajectory prediction can be multi-modal, on the nuScenes benchmark we focus on the most likely mode/trajectory and computing the errors w.r.t human driving trajectory. 

The results are fully validated on widely used benchmarks and we have followed the same training and evaluation protocol to ensure a fair comparison with baselines. We argue that the reviewer's current suspicion is not based on facts and thus not convincing.

Reviewer comment (Reproducibility):
Can you clarify what prompts you used in your three-stage approach for training. Fig 3. seems to only include the prompt for the final stage?

Author response:
We only fine-tune the GPT-Driver **once**. The prompting-reasoning-finetuning strategy means that we design proper prompts as inputs to the GPT-Driver, we enumerate the reasoning process as one of the learning targets, and we fine-tune the LLM using the prompts as inputs and the reasoning target as one of the outputs. Hence, Figure 2 and Figure 3 already include all the inputs and outputs to GPT-Driver during fine-tuning.

Reviewer comment (Experiments):
Isn't your information about the obstacles both incomplete and technically cheating (acausal) in the simple prompting baseline, since you do not include obstacle velocities, but seemingly where they will be in the future? Care to comment on what this description really means, where they will stop / be x seconds? in the future?

Author response:
Clearly, the information about obstacles **is not technically cheating**. As we mentioned, we transform **both detection and prediction** results into text descriptions. This means we describe not only the current location of the object but also the future moving trajectory (in 6 waypoint coordinates) of this object. In this paper, we simplify the prediction by describing the location where the object ends up in the 3rd second. Prediction, or motion forecasting, is a commonly adopted sub-task in the context of autonomous driving, Most state-of-the-art driving systems rely on a perception-prediction-planning paradigm where detection and prediction results are leveraged as inputs to the motion planners. Here we adopted the detection and prediction results from the state-of-the-art UniAD to ensure a fair comparison with this baseline approach.

Reviewer comment (Experiments):
For example, an ablation study should be conducted to evaluate the benefit of having chain-of-thought reasoning in the LLM's output. While it is well-known that chain-of-thought reasoning boosts LLM's performance, it is worth evaluating its contribution to the motion planning task.

Author response:
Thanks for your advice!

**For example, an ablation study should be conducted to evaluate the benefit of having chain-of-thought reasoning in the LLM's output.**

Here is the ablation study of removing chain-of-thoughts reasoning:

Method | L2   |      |      |      | Collision |      |      |      |
|------|------|------|------|------|-----------|------|------|------|
GPT-Driver  | 1s   | 2s   | 3s   | Avg. | 1s        | 2s   | 3s   | Avg. |
w/ cot. reason | 0.21 | 0.43 | 0.79 | 0.48 | 0.16      | 0.27 | 0.63 | 0.35 |
w/o cot. reason | 0.22 | 0.45 | 0.82 | 0.49 | 0.16      | 0.25 | 0.63 | 0.34 |

Removing chain-of-thoughts reasoning slightly harms the L2 but performs slightly better in the collision. We interpret this insignificant synergy as the LLM does not benefit from a joint language modeling of reasoning and trajectory. Since reasoning will account for most of the output tokens, simultaneously optimizing reasoning and trajectory will cause the LLM to pay less attention to trajectory prediction. Recently we found a cascaded design where the LLM first outputs reasoning and then uses reasoning to output trajectory works better.

Reviewer comment (Experiments):
Also, there should be an ablation study to evaluate the benefit of having the auto-generated chain-of-thought reasoning labels during fine-tuning. While the proposed method to auto-label the chain-of-thought reasoning through hypothetical ego-trajectory is sensible, it is not guaranteed to generate the ground-truth reasoning process (i.e., identifying the actual causal objects and their relations to the ego agents). The authors claimed that this strategy worked well in practice. I wonder how the authors evaluated the quality of the auto-generated labels and drew such a conclusion. There should be numerical results to examine the quality of the auto-generated labels, and an ablation study to validate that the fine-tuning process indeed benefits from the plausibly noisy and inaccurate reasoning labels.

Author response:
We're still working on the ablation studies you mentioned. It takes some time before we are able to release the response to you. We sincerely apologize for this inconvenience.

Reviewer comment (Reproducibility):
Could the authors clarify how the hypothetical ego trajectory is generated? Whether an object is identified as critical seems to highly depend on the hypothetical ego trajectory. The authors should discuss how they designed the generation algorithm and adjusted the hyperparameters.

Author response:
**Could the authors clarify how the hypothetical ego trajectory is generated? Whether an object is identified as critical seems to highly depend on the hypothetical ego trajectory. The authors should discuss how they designed the generation algorithm and adjusted the hyperparameters.**

The hypothetical ego trajectory is generated by calculating the future waypoint locations based on the current velocity and acceleration (assuming the vehicle maintains the current speed and drives without interference.) We will identify those objects that fall into a 5x3 m region of any waypoint as critical objects. This auto-generation process is essentially which objects will affect driving when we don't take any special actions.

Reviewer comment (Evaluation):
Is the motion planning performance evaluated with the most likely output sequence? How stable and reliable is the GPT-Driver in generating sensible reasoning processes and trajectories? Is it able to account for multi-modality in driving behavior?

Author response:
**Is the motion planning performance evaluated with the most likely output sequence? How stable and reliable is the GPT-Driver in generating sensible reasoning processes and trajectories? Is it able to account for multi-modality in driving behavior?**

The LLM only generates one sequence at a time. The outputs of LLMs are quite stable and very few outputs over the whole validation set contain invalid format. It is able to account for multi-modality when we turn up the temperatures of LLMs and perform multiple runs.

Reviewer comment (Experiments):
The method does not seem to be very feasible for online execution.

Author response:
**Latency.** We admit that our system is not real-time as of now due to GPT API latency. However, if we use a Llama2 7B model, we believe it is possible to achieve real-time inference. Again, the goal of this paper is to investigate the potentials of LLMs applied to motion planning and we have some surprising discoveries in this study. We will leave efficiency optimization for future study.

Reviewer comment (Novelty):
The method seems to critically depend on the existing SOTA methods as its integral part, making the overall system quite complex.

Author response:
**Dependency on the existing methods.** Again, our method can incorporate any perception modules and can tolerate certain perception errors, as verified in Table 1. We don't know what downsides you're referring to. We are happy to address any further concerns in this regard if you provide a specific example.

Reviewer comment (Experiments):
The method seems far from being actually applicable in the real world, which the authors don't really explore or address beyond a very brief explanation in Section 4.6 that seems insufficient and handwavy.

Author response:
**Latency.** We admit that our system is not real-time as of now due to GPT API latency. However, if we use a Llama2 7B model, we believe it is possible to achieve real-time inference. Again, the goal of this paper is to investigate the potentials of LLMs applied to motion planning and we have some surprising discoveries in this study. We will leave efficiency optimization for future study.

Reviewer comment (Novelty):
The explanations of the method can be improved significantly, and the methodology itself seems quite complex and dependent on the existing SOTA methods.

Author response:
**Dependency on the existing methods.** Again, our method can incorporate any perception modules and can tolerate certain perception errors, as verified in Table 1. We don't know what downsides you're referring to. We are happy to address any further concerns in this regard if you provide a specific example.

Reviewer comment (Presentation):
The authors should fix the format of the references. Instead of "P3 (Sadat et al., 2020)" they use "P3 Sadat et al. (2020)" throughout the work, which is incorrect and adds some confusion in several places.

Author response:
Thanks for pointing out. We have updated the paper to fix the typos in citations.

Reviewer comment (Presentation):
Figure 1 is not referenced in the text.

Author response:
Thanks for pointing out. We have added the reference to Figure 1 in the updated version of this paper.

Reviewer comment (Experiments):
The method assumes the existing strong method for perception and prediction, which seems like quite a large requirement. The input to GPT assumes detections and their predicted trajectories, which seems to add quite a lot of complexity both from the training and inference standpoint.

Author response:
Our method does not assume **strong** perception and prediction methods. On the contrary, our method can adapt to **any** perception and prediction methods, and here we choose the perception and prediction modules in UniAD mainly for a fair comparison with this approach. 

Perception and prediction are indispensable for safe motion planning in the context of autonomous driving. In most state-of-the-art approaches (e.g. UniAD, ST-P3), their motion planners take perception and prediction data as inputs. Hence, it is not a large requirement for the GPT-Driver to take perception and prediction as inputs.

Reviewer comment (Experiments):
The authors do not conduct an ablation study of the perception/prediction module, which would give an indication of how robust GPT is to this part of the methodology.

Author response:
We have actually ablated the effects of perception and prediction in Table 5, where we use perfect and UniAD's perception and prediction results as inputs to GPT-Driver. As we mentioned in Section 4.2, when replacing the perfect perception and prediction with the learned ones, the planning performance only drops slightly, which indicates the robustness of our GPT-Driver to perception and prediction errors. We are also working on ablating more perception and prediction approaches.

Reviewer comment (Writing):
In equation (2) the authors say that the input to their model is a map, yet that is not the case as they don't provide the map to the model.

Author response:
What we want to present in Eq (2) is motion planning, in general, can take maps as input data. Since our approach currently doesn't rely on maps, we have revised this part for better clarification.

Reviewer comment (Reproducibility):
Although the authors later say that their model can take the map as an input, it is far from clear how this can be done given that they represent all inputs as text.

Author response:
Maps in autonomous driving can be represented in vectorized format, where the compact representation can be expressed as a graph denoting the locations and connections of lanes. The vectorized map can be further transformed into texts describing the locations and connections of the lanes. Hence, our approach has the potential to incorporate vectorized map information.

Reviewer comment (Novelty):
In Section 4.2 the authors say that other approaches depend on various heterogeneous inputs "which makes their systems intricate and time-consuming", yet the proposed method also depends on the same inputs since it depends on UniAD. This suggests the authors are not being entirely honest in this case.

Author response:
Other approaches, such as UniAD, take compact maps (H xW grids) and occupancy (H x W x T grids), in addition to perception and prediction, as inputs to their motion planner.  Extracting those compact maps and occupancy grids makes their system intricate and time-consuming. By contrast, our approach only leverages text-based perception and prediction (instead of compact maps and occupancy grids) of UniAD as inputs to GPT-Driver. Hence, we believe our argument here is **correct** and **honest**. We have revised this part to make more clarifications.

Reviewer comment (Reproducibility):
In Section 4.3 it is unclear whether the authors use fully trained UniAD for generating input strings for their method, or if they use partially trained UniAD. This should be clarified.

Author response:
In Section 4.3, since we are comparing the motion planning performance, the perception and prediction in both UniAD and our approach are fully trained, and only the motion planner in UniAD and GPT-Driver are trained with 1%, 10%, 50% data. We have added more clarifications in this section.

Reviewer comment (Evaluation):
Some sort of latency analysis should be provided, beyond just a handwavy explanation from Section 4.6. This is important for the practical application of their method and is something that the authors should explore.

Author response:
We agree with this point. As we discussed in Section 4.6, the major problem here is that we are unable to obtain very accurate inference time through the OpenAI APIs. Hence the latency analysis is not feasible at this moment. We will keep track of the updates of OpenAI and see whether we could add this analysis in the future.