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 report the requested information and speak to the underlying concern. The table below shows six common examples where the reviewer is nominally asking for a fact or a number, but reporting the fact alone does not settle the concern.

Reviewer's question	Literal meaning	Underlying concern	Bad vs. good answer
"How does your method compare to Method A?"	Report the numerical comparison with A.	The reviewer is probing whether your claim of superiority actually holds --- and, if it does not, whether the paper's contribution still stands.	Bad: "Ours: 82.3%. Method A: 83.1%." (Numbers only, no framing.) Good (when you win): "Ours: 85.2% vs. A's 83.7%. This is consistent with our design rationale that [X]." Feel free to add a table row or highlight the gain --- visual attention works in your favor. Good (when you do not win): "Method A reports 83.1% vs. our 82.3%. However, A benefits from [X --- e.g., 10× more pre-training data / access to ground-truth 3D / privileged intrinsic parameters] that our method does not use. Under a matched-input setting, we [outperform / match] A (see row Y of Table Z). Our contribution remains [W], which A cannot address at all." Report inline in text; do not put the losing number in a new table or graph.
"Which metric did you use to evaluate?"	Name the metric.	The reviewer suspects the metric may be self-serving --- perhaps chosen because it flatters your method.	Bad: "We report normalized angular error." (Just the name.) Good: "We report normalized angular error, the standard metric for this task in prior work [refs]. Results under the alternative commonly used metric, mean angular deviation, give the same method ranking (Table X)." If the metric is genuinely well known (e.g., top-1 accuracy on ImageNet), no justification is needed --- but if there is any room for suspicion, name the standard.
"How were the hyperparameters tuned?"	Describe the tuning procedure.	The reviewer worries you tuned on the test set, or that your protocol favors your method over the baselines you compare against.	Bad: "We swept the learning rate over {1e-3, 3e-4, 1e-4} on the validation split and picked 3e-4." Good: "We swept the learning rate over {1e-3, 3e-4, 1e-4} on the validation split and picked 3e-4. This follows the standard protocol of [ref]. All baselines were tuned with the same protocol and the same compute budget, and the final numbers we report are on the held-out test set." Note: the good and bad answers share the same first sentence --- the good one just adds the framing that removes the concern.
"How large is the dataset used in Section 4.2?"	Report the number of samples.	The reviewer is worried the dataset is too small to support the conclusions you draw.	Bad: "N = 500 images." (Just the number.) Good (when N is large): "N = 50,000 images, orders of magnitude beyond typical benchmarks for this task (e.g., dataset X at 3,000)." A brief line is enough; do not over-defend an already-large size. Good (when N is modest): "N = 500 images. This is on par with the widely used benchmarks X (400) and Y (600) for the same task, so results here are directly comparable to prior work. We additionally verified stability with 5-fold cross-validation (std < 0.4%, details in supp)."
"What is the runtime of your method?"	Report the inference time.	The reviewer is worried the method is too slow to be practical, especially relative to lighter baselines.	Bad: "12 ms per image on an A100." (Just the number, no context.) Good (when the number looks great): "12 ms per image on an A100 (~80 FPS), 2× faster than baseline B (25 ms) despite the added [module M], and well within the real-time budget for [use case]." Feel free to add a runtime column to your comparison table --- visual saliency helps here. Good (when the number looks slow): "200 ms per image on an A100. This is slower than baseline B (12 ms) because our method [reason, e.g., iterative refinement over K steps]. The extra cost buys [gain, e.g., +5% accuracy on hard cases]; for latency-critical settings, a lightweight variant reduces runtime to 60 ms with only 1% accuracy drop (Section X, supp)." Report inline in text; do not put the slower number in a new chart.
"The paper does not discuss failure cases."	Add failure examples.	The reviewer suspects the method has systematic failure modes you are hiding, and cannot judge the boundary of the contribution without knowing where it breaks.	Bad: "Failure cases are shown in Figure X (supp)." (Just points to the figure.) Good: "Failure cases are shown in Figure X. They cluster in [condition Y] --- consistent with our discussion in Section 5 on [limit], a known challenge for methods of this class. Addressing [Y] is a natural direction for future work; a promising angle is [Z]." Naming the pattern and the reason turns a weakness question into a controlled framing.

Two habits are worth keeping, and both are about where you place the information.

When your numbers clearly win, use visual formats. Add a table row, a bar in a plot, a bold entry — visual saliency is on your side and the reviewer will absorb the result in a glance.

When your numbers do not win, do not visualize them. Report the fact inline in the text, honestly acknowledge that your method is worse on this axis, and then explain why (a different training regime, a different set of assumptions, a capability the competitor does not offer) and what merits your method retains. Do not put losing numbers in a new table, chart, or highlighted box. This is not about hiding information — you must report it — but about not amplifying it. Visual saliency is enormously strong: a reviewer glancing at a table or chart forms a perception in one second, without reading your careful explanation next to it. Even if they do read your text, the visual signal is very hard to fight. Putting a losing number in a chart is shooting yourself in the foot; putting it in a sentence lets your explanation share the reader's attention.

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.