Writing a conference paper rebuttal

When addressing reviewer questions, be sure to respond to the underlying concern or criticism, not just the literal wording of the question. Reviewers may phrase feedback as a question, but often they are implying a deeper issue or suggestion.

Know your audience

A rebuttal is written to answer the reviewers’ questions, but do not assume the reviewers still remember exactly what they asked. Reviews are often written weeks earlier, and reviewers will not want to re-read their own review to figure out what your rebuttal is responding to. Your summary of each question must therefore stand on its own and immediately remind the reviewer of the concern they raised.

A rebuttal is also read by the area chair (AC), who typically has not read the paper or the reviews in detail (they are handling many submissions) but who needs to see that the reviewers’ main concerns have been addressed. Both your summary of each question and your answer must be understandable to this third party who has none of the context.

The practical consequence: an over-brief summary such as “Comparison to A” fails both audiences. The reviewer does not immediately recall what they meant, and the AC has no way to judge whether your answer is on point. A good summary makes the concern legible on first read, without forcing anyone back to the original review.

Two things to keep in mind:

Address the core concern, not just the surface question.
Summarize the reviewer comment in your rebuttal in a way that is concise but still informative. The summary should clearly convey the reviewer's intent or implication.

Address the core concern, not just the surface question

Reviewers rarely ask a question just for information. Behind a question there is almost always an implicit concern about the paper. Your reply should target that concern. The table below shows three examples.

Reviewer's question	Literal meaning	Underlying concern / criticism
"How does your method compare to Method A?"	Please tell me the numerical comparison to A.	You are missing a key baseline; without it, your claim of state-of-the-art is not supported.
"Why did you choose hyperparameter λ = 0.1?"	Explain how λ = 0.1 was picked.	The choice looks arbitrary or hand-tuned to your dataset; a sensitivity analysis is expected.
"How large is the dataset used in Section 4.2?"	Report the number of samples.	The dataset may be too small to draw the conclusions you draw; the empirical evidence is thin.
"Do you report standard deviations across multiple training runs?"	Please add error bars.	Your single-run numbers may be within noise; the reported improvement over the baseline may not be statistically significant.
"Have you evaluated your method on task/domain Y?"	Please try Y and report the numbers.	Your evaluation is too narrow; it is unclear whether the method generalizes beyond the setting you tested.
"Isn't approach B a much simpler alternative?"	Compare against B.	The proposed method may be unnecessarily complex; a simpler baseline could reach similar performance and undermine the contribution.
"Can you explain the difference between Figure 2 and Figure 3?"	Clarify what the two figures show.	The presentation is confusing; the reviewer could not follow the paper's core exposition.

For each of these, a good rebuttal not only answers the surface question (add the number, cite the value, report the size) but also directly speaks to the underlying concern (add the missing baseline, provide a sensitivity plot, argue why the dataset is adequate or add results on a larger one).

Summarize the reviewer comment concisely but informatively

Rebuttals have strict length limits, so you must summarize each reviewer comment before responding to it. A summary that is too short loses the critical framing (reviewer's intent, what is missing, what is wrong) and forces the reviewer to re-read their own review to figure out what you are replying to; it also leaves the area chair with no way to judge whether your reply is on point. A summary that is too long wastes space that should go to your response. Aim for the middle: short enough to fit, long enough that both the original reviewer (who does not remember the exact wording of their review) and the area chair (who has not read the paper or reviews in detail) can understand the concern on first read.

Original reviewer comment	Too-short summary	Good summary
"The authors do not provide any theoretical justification for why their proposed loss function outperforms cross-entropy in the low-data regime, which is central to the paper's main contribution."	"Loss function justification."	"No theoretical justification for the proposed loss vs. cross-entropy in low-data regime."
"It is not clear from the experimental section whether the reported gains persist when the model is trained on a smaller subset of the training data, which is important for practical deployment."	"Training data size."	"Missing ablation: do gains persist with smaller training subsets?"
"The comparison in Table 3 uses different backbones for the baselines than for the proposed method, making it hard to attribute the improvement to the proposed contribution rather than the stronger backbone."	"Table 3 comparison."	"Table 3 uses stronger backbones for our method than baselines; gain may come from backbone, not method."
"Section 3.2 introduces a new attention mechanism, but the authors do not discuss how it relates to prior work on sparse attention such as [7, 12], which appears to solve a very similar problem."	"Related work."	"No discussion of how our attention differs from prior sparse-attention [7, 12]."
"It is unclear whether the improvement over the baseline is statistically significant, since the authors only report results from a single training run and the gap in Table 2 is within one percentage point."	"Statistical significance."	"Table 2 gain <1% from a single run; may not be statistically significant."
"The qualitative results in Figure 5 appear cherry-picked in the sense that the authors show mostly success cases; it would be helpful to see typical failure modes so that the reader can judge when the method breaks."	"Qualitative results."	"Figure 5 shows only successes; add failure cases to show when the method breaks."
"The claim in the abstract that the method runs in real time is not supported by any wall-clock measurements, and the reported FLOPs alone do not tell us whether the system meets a real-time budget on standard hardware."	"Real-time claim."	"No wall-clock timings for the 'real-time' claim; FLOPs alone are not enough."

Notice that the too-short summaries are just topic labels; a reader has no idea what the reviewer actually objected to. The good summaries preserve the reviewer's implied critique, so your rebuttal that follows is understandable on its own.