backup materials and knowledge-base docs
This commit is contained in:
admin
@@ -0,0 +1,25 @@
|
||||
# Operating Modes
|
||||
|
||||
Use this file to decide how much of the writing stack to load.
|
||||
|
||||
## Modes
|
||||
|
||||
### 1. drafting
|
||||
Use when writing or rewriting a paper section from repo evidence.
|
||||
Load: core SKILL + writing guide + citation workflow.
|
||||
|
||||
### 2. related-work
|
||||
Use when searching, comparing, and integrating literature.
|
||||
Load: citation workflow + reviewer guidelines + relevant venue notes.
|
||||
|
||||
### 3. citation-only
|
||||
Use when the task is primarily reference verification or bibliography repair.
|
||||
Load: citation workflow first; do not load the full paper-writing stack unless needed.
|
||||
|
||||
### 4. format-conversion
|
||||
Use when moving between conference templates or preparing camera-ready assets.
|
||||
Load: template / format references and only the relevant venue rules.
|
||||
|
||||
### 5. camera-ready
|
||||
Use when compliance, formatting, and final verification dominate over drafting.
|
||||
Load: venue-specific checklist + citation workflow + final verification notes.
|
||||
@@ -0,0 +1,361 @@
|
||||
# Conference Paper Checklists
|
||||
|
||||
This reference documents the mandatory checklist requirements for major ML/AI conferences. All major venues now require paper checklists—missing them results in desk rejection.
|
||||
|
||||
---
|
||||
|
||||
## Contents
|
||||
|
||||
- [NeurIPS Paper Checklist](#neurips-paper-checklist)
|
||||
- [ICML Paper Checklist](#icml-paper-checklist)
|
||||
- [ICLR Requirements](#iclr-requirements)
|
||||
- [ACL Requirements](#acl-requirements)
|
||||
- [Universal Pre-Submission Checklist](#universal-pre-submission-checklist)
|
||||
|
||||
---
|
||||
|
||||
## NeurIPS Paper Checklist
|
||||
|
||||
### Mandatory Components
|
||||
|
||||
All NeurIPS submissions must include a completed paper checklist. Papers lacking this element face **automatic desk rejection**. The checklist appears after references and supplemental material, outside the page limit.
|
||||
|
||||
### 16 Required Checklist Items
|
||||
|
||||
#### 1. Claims Alignment
|
||||
Authors must verify that abstract and introduction claims match theoretical and experimental results, with clearly stated contributions, assumptions, and limitations.
|
||||
|
||||
**What to check:**
|
||||
- [ ] Abstract claims match actual results
|
||||
- [ ] Introduction doesn't overclaim
|
||||
- [ ] Contributions are specific and falsifiable
|
||||
|
||||
#### 2. Limitations Discussion
|
||||
Papers should include a dedicated "Limitations" section addressing strong assumptions, robustness to violations, scope constraints, and performance-influencing factors.
|
||||
|
||||
**What to include:**
|
||||
- [ ] Dedicated Limitations section
|
||||
- [ ] Honest assessment of scope
|
||||
- [ ] Conditions where method may fail
|
||||
|
||||
#### 3. Theory & Proofs
|
||||
Theoretical contributions require full assumption statements and complete proofs (main paper or appendix with proof sketches for intuition).
|
||||
|
||||
**What to check:**
|
||||
- [ ] All assumptions stated formally
|
||||
- [ ] Complete proofs provided (main text or appendix)
|
||||
- [ ] Proof sketches for intuition in main text
|
||||
|
||||
#### 4. Reproducibility
|
||||
Authors must describe steps ensuring results verification through code release, detailed instructions, model access, or checkpoints appropriate to their contribution type.
|
||||
|
||||
**What to provide:**
|
||||
- [ ] Clear reproducibility statement
|
||||
- [ ] Code availability information
|
||||
- [ ] Model checkpoints if applicable
|
||||
|
||||
#### 5. Data & Code Access
|
||||
Instructions for reproducing main experimental results should be provided (supplemental material or URLs), including exact commands and environment specifications.
|
||||
|
||||
**What to include:**
|
||||
- [ ] Exact commands to run experiments
|
||||
- [ ] Environment specifications (requirements.txt, conda env)
|
||||
- [ ] Data access instructions
|
||||
|
||||
#### 6. Experimental Details
|
||||
Papers must specify training details: data splits, hyperparameters, and selection methods in the main paper or supplementary materials.
|
||||
|
||||
**What to document:**
|
||||
- [ ] Train/val/test split details
|
||||
- [ ] All hyperparameters used
|
||||
- [ ] Hyperparameter selection method
|
||||
|
||||
#### 7. Statistical Significance
|
||||
Results require error bars, confidence intervals, or statistical tests with clearly stated calculation methods and underlying assumptions.
|
||||
|
||||
**What to include:**
|
||||
- [ ] Error bars or confidence intervals
|
||||
- [ ] Number of runs/seeds
|
||||
- [ ] Calculation method (std dev vs std error)
|
||||
|
||||
#### 8. Compute Resources
|
||||
Specifications needed: compute worker types (CPU/GPU), memory, storage, execution time per run, and total project compute requirements.
|
||||
|
||||
**What to document:**
|
||||
- [ ] GPU type and count
|
||||
- [ ] Training time per run
|
||||
- [ ] Total compute used
|
||||
|
||||
#### 9. Ethics Code Compliance
|
||||
Authors confirm adherence to the NeurIPS Code of Ethics, noting any necessary deviations.
|
||||
|
||||
**What to verify:**
|
||||
- [ ] Read NeurIPS Code of Ethics
|
||||
- [ ] Confirm compliance
|
||||
- [ ] Note any deviations with justification
|
||||
|
||||
#### 10. Broader Impacts
|
||||
Discussion of potential negative societal applications, fairness concerns, privacy risks, and possible mitigation strategies when applicable.
|
||||
|
||||
**What to address:**
|
||||
- [ ] Potential negative applications
|
||||
- [ ] Fairness considerations
|
||||
- [ ] Privacy implications
|
||||
- [ ] Mitigation strategies
|
||||
|
||||
#### 11. Safeguards
|
||||
High-risk models (language models, internet-scraped datasets) require controlled release mechanisms and usage guidelines.
|
||||
|
||||
**What to consider:**
|
||||
- [ ] Release strategy for sensitive models
|
||||
- [ ] Usage guidelines if needed
|
||||
- [ ] Access controls if appropriate
|
||||
|
||||
#### 12. License Respect
|
||||
All existing assets require creator citations, license names, URLs, version numbers, and terms-of-service acknowledgment.
|
||||
|
||||
**What to document:**
|
||||
- [ ] Dataset licenses cited
|
||||
- [ ] Code licenses respected
|
||||
- [ ] Version numbers included
|
||||
|
||||
#### 13. Asset Documentation
|
||||
New releases need structured templates documenting training details, limitations, consent procedures, and licensing information.
|
||||
|
||||
**For new datasets/models:**
|
||||
- [ ] Datasheet or model card
|
||||
- [ ] Training data documentation
|
||||
- [ ] Known limitations
|
||||
|
||||
#### 14. Human Subjects
|
||||
Crowdsourcing studies must include participant instructions, screenshots, compensation details, and comply with minimum wage requirements.
|
||||
|
||||
**What to include:**
|
||||
- [ ] Task instructions
|
||||
- [ ] Compensation details
|
||||
- [ ] Time estimates
|
||||
|
||||
#### 15. IRB Approvals
|
||||
Human subjects research requires documented institutional review board approval or equivalent, with risk descriptions disclosed (maintaining anonymity at submission).
|
||||
|
||||
**What to verify:**
|
||||
- [ ] IRB approval obtained
|
||||
- [ ] Risk assessment completed
|
||||
- [ ] Anonymized at submission
|
||||
|
||||
#### 16. LLM Declaration
|
||||
Usage of large language models as core methodology components requires disclosure; writing/editing use doesn't require declaration.
|
||||
|
||||
**What to disclose:**
|
||||
- [ ] LLM used as core methodology component
|
||||
- [ ] How LLM was used
|
||||
- [ ] (Writing assistance doesn't require disclosure)
|
||||
|
||||
### Response Format
|
||||
|
||||
Authors select "yes," "no," or "N/A" per question, with optional 1-2 sentence justifications.
|
||||
|
||||
**Important:** Reviewers are explicitly instructed not to penalize honest limitation acknowledgment.
|
||||
|
||||
---
|
||||
|
||||
## ICML Paper Checklist
|
||||
|
||||
### Broader Impact Statement
|
||||
|
||||
ICML requires a Broader Impact Statement at the end of the paper, before references. This does NOT count toward the page limit.
|
||||
|
||||
**Required elements:**
|
||||
- Potential positive impacts
|
||||
- Potential negative impacts
|
||||
- Mitigation strategies
|
||||
- Who may be affected
|
||||
|
||||
### ICML Specific Requirements
|
||||
|
||||
#### Reproducibility Checklist
|
||||
|
||||
- [ ] Data splits clearly specified
|
||||
- [ ] Hyperparameters listed
|
||||
- [ ] Search ranges documented
|
||||
- [ ] Selection method explained
|
||||
- [ ] Compute resources specified
|
||||
- [ ] Code availability stated
|
||||
|
||||
#### Statistical Reporting
|
||||
|
||||
- [ ] Error bars on all figures
|
||||
- [ ] Standard deviation vs standard error specified
|
||||
- [ ] Number of runs stated
|
||||
- [ ] Significance tests if comparing methods
|
||||
|
||||
#### Anonymization
|
||||
|
||||
- [ ] No author names in paper
|
||||
- [ ] No acknowledgments
|
||||
- [ ] No grant numbers
|
||||
- [ ] Prior work cited in third person
|
||||
- [ ] No identifiable repository URLs
|
||||
|
||||
---
|
||||
|
||||
## ICLR Requirements
|
||||
|
||||
### LLM Disclosure Policy (New for 2026)
|
||||
|
||||
ICLR has a specific LLM disclosure requirement:
|
||||
|
||||
> "If LLMs played a significant role in research ideation and/or writing to the extent that they could be regarded as a contributor, authors must describe their precise role in a separate appendix section."
|
||||
|
||||
**When disclosure is required:**
|
||||
- LLM used for significant research ideation
|
||||
- LLM used for substantial writing
|
||||
- LLM could be considered a contributor
|
||||
|
||||
**When disclosure is NOT required:**
|
||||
- Grammar checking
|
||||
- Minor editing assistance
|
||||
- Code completion tools
|
||||
|
||||
**Consequences of non-disclosure:**
|
||||
- Desk rejection
|
||||
- Potential post-publication issues
|
||||
|
||||
### ICLR Specific Requirements
|
||||
|
||||
#### Reproducibility Statement (Optional but Recommended)
|
||||
|
||||
Add a statement referencing:
|
||||
- Supporting materials
|
||||
- Code availability
|
||||
- Data availability
|
||||
- Model checkpoints
|
||||
|
||||
#### Ethics Statement (Optional)
|
||||
|
||||
Address potential concerns in ≤1 page. Does not count toward page limit.
|
||||
|
||||
#### Reciprocal Reviewing
|
||||
|
||||
- Authors on 3+ papers must serve as reviewers for ≥6 papers
|
||||
- Each submission needs ≥1 author registered to review ≥3 papers
|
||||
|
||||
---
|
||||
|
||||
## ACL Requirements
|
||||
|
||||
### Limitations Section (Mandatory)
|
||||
|
||||
ACL specifically requires a Limitations section:
|
||||
|
||||
**What to include:**
|
||||
- Strong assumptions made
|
||||
- Scope limitations
|
||||
- When method may fail
|
||||
- Generalization concerns
|
||||
|
||||
**Important:** The Limitations section does NOT count toward the page limit.
|
||||
|
||||
### ACL Specific Checklist
|
||||
|
||||
#### Responsible NLP
|
||||
|
||||
- [ ] Bias considerations addressed
|
||||
- [ ] Fairness evaluated if applicable
|
||||
- [ ] Dual-use concerns discussed
|
||||
|
||||
#### Multilingual Considerations
|
||||
|
||||
If applicable:
|
||||
- [ ] Language diversity addressed
|
||||
- [ ] Non-English languages included
|
||||
- [ ] Translation quality verified
|
||||
|
||||
#### Human Evaluation
|
||||
|
||||
If applicable:
|
||||
- [ ] Annotator details provided
|
||||
- [ ] Agreement metrics reported
|
||||
- [ ] Compensation documented
|
||||
|
||||
---
|
||||
|
||||
## Universal Pre-Submission Checklist
|
||||
|
||||
### Before Every Submission
|
||||
|
||||
#### Paper Content
|
||||
|
||||
- [ ] Abstract ≤ word limit (usually 250-300 words)
|
||||
- [ ] Main content within page limit
|
||||
- [ ] References complete and verified
|
||||
- [ ] Limitations section included
|
||||
- [ ] All figures/tables have captions
|
||||
- [ ] Captions are self-contained
|
||||
|
||||
#### Formatting
|
||||
|
||||
- [ ] Correct template used (venue + year specific)
|
||||
- [ ] Margins not modified
|
||||
- [ ] Font sizes not modified
|
||||
- [ ] Double-blind requirements met
|
||||
- [ ] Page numbers (for review) or none (camera-ready)
|
||||
|
||||
#### Technical
|
||||
|
||||
- [ ] All claims supported by evidence
|
||||
- [ ] Error bars included
|
||||
- [ ] Baselines appropriate
|
||||
- [ ] Hyperparameters documented
|
||||
- [ ] Compute resources stated
|
||||
|
||||
#### Reproducibility
|
||||
|
||||
- [ ] Code will be available (or justification)
|
||||
- [ ] Data will be available (or justification)
|
||||
- [ ] Environment documented
|
||||
- [ ] Commands to reproduce provided
|
||||
|
||||
#### Ethics
|
||||
|
||||
- [ ] Broader impacts considered
|
||||
- [ ] Limitations honestly stated
|
||||
- [ ] Licenses respected
|
||||
- [ ] IRB obtained if needed
|
||||
|
||||
#### Final Checks
|
||||
|
||||
- [ ] PDF compiles without errors
|
||||
- [ ] All figures render correctly
|
||||
- [ ] All citations resolve
|
||||
- [ ] Supplementary material organized
|
||||
- [ ] Conference checklist completed
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference: Page Limits
|
||||
|
||||
| Conference | Main Content | References | Appendix |
|
||||
|------------|-------------|------------|----------|
|
||||
| NeurIPS 2025 | 9 pages | Unlimited | Unlimited (checklist separate) |
|
||||
| ICML 2026 | 8 pages (+1 camera) | Unlimited | Unlimited |
|
||||
| ICLR 2026 | 9 pages (+1 camera) | Unlimited | Unlimited |
|
||||
| ACL 2025 | 8 pages (long) | Unlimited | Unlimited |
|
||||
| AAAI 2026 | 7 pages (+1 camera) | Unlimited | Unlimited |
|
||||
| COLM 2025 | 9 pages (+1 camera) | Unlimited | Unlimited |
|
||||
|
||||
---
|
||||
|
||||
## Template Locations
|
||||
|
||||
All conference templates are in the `templates/` directory:
|
||||
|
||||
```
|
||||
templates/
|
||||
├── icml2026/ # ICML 2026 official
|
||||
├── iclr2026/ # ICLR 2026 official
|
||||
├── neurips2025/ # NeurIPS 2025
|
||||
├── acl/ # ACL style files
|
||||
├── aaai2026/ # AAAI 2026
|
||||
└── colm2025/ # COLM 2025
|
||||
```
|
||||
@@ -0,0 +1,562 @@
|
||||
# Citation Management & Hallucination Prevention
|
||||
|
||||
This reference provides a complete workflow for managing citations programmatically, preventing AI-generated citation hallucinations, and maintaining clean bibliographies.
|
||||
|
||||
---
|
||||
|
||||
## Contents
|
||||
|
||||
- [Why Citation Verification Matters](#why-citation-verification-matters)
|
||||
- [Citation APIs Overview](#citation-apis-overview)
|
||||
- [Verified Citation Workflow](#verified-citation-workflow)
|
||||
- [Python Implementation](#python-implementation)
|
||||
- [BibTeX Management](#bibtex-management)
|
||||
- [Common Citation Formats](#common-citation-formats)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
|
||||
---
|
||||
|
||||
## Why Citation Verification Matters
|
||||
|
||||
### The Hallucination Problem
|
||||
|
||||
Research has documented significant issues with AI-generated citations:
|
||||
- **~40% error rate** in AI-generated citations (Enago Academy research)
|
||||
- NeurIPS 2025 found **100+ hallucinated citations** slipped through review
|
||||
- Common errors include:
|
||||
- Fabricated paper titles with real author names
|
||||
- Wrong publication venues or years
|
||||
- Non-existent papers with plausible metadata
|
||||
- Incorrect DOIs or arXiv IDs
|
||||
|
||||
### Consequences
|
||||
|
||||
- Desk rejection at some venues
|
||||
- Loss of credibility with reviewers
|
||||
- Potential retraction if published
|
||||
- Wasted time chasing non-existent sources
|
||||
|
||||
### Solution
|
||||
|
||||
**Never generate citations from memory—always verify programmatically.**
|
||||
|
||||
---
|
||||
|
||||
## Citation APIs Overview
|
||||
|
||||
### Primary APIs
|
||||
|
||||
| API | Coverage | Rate Limits | Best For |
|
||||
|-----|----------|-------------|----------|
|
||||
| **Semantic Scholar** | 214M papers | 1 RPS (free key) | ML/AI papers, citation graphs |
|
||||
| **CrossRef** | 140M+ DOIs | Polite pool with mailto | DOI lookup, BibTeX retrieval |
|
||||
| **arXiv** | Preprints | 3-second delays | ML preprints, PDF access |
|
||||
| **OpenAlex** | 240M+ works | 100K/day, 10 RPS | Open alternative to MAG |
|
||||
|
||||
### API Selection Guide
|
||||
|
||||
```
|
||||
Need ML paper search? → Semantic Scholar
|
||||
Have DOI, need BibTeX? → CrossRef content negotiation
|
||||
Looking for preprint? → arXiv API
|
||||
Need open data, bulk access? → OpenAlex
|
||||
```
|
||||
|
||||
### No Official Google Scholar API
|
||||
|
||||
Google Scholar has no official API. Scraping violates ToS. Use SerpApi ($75-275/month) only if Semantic Scholar coverage is insufficient.
|
||||
|
||||
---
|
||||
|
||||
## Verified Citation Workflow
|
||||
|
||||
### 5-Step Process
|
||||
|
||||
```
|
||||
1. SEARCH → Query Semantic Scholar with specific keywords
|
||||
↓
|
||||
2. VERIFY → Confirm paper exists in 2+ sources
|
||||
↓
|
||||
3. RETRIEVE → Get BibTeX via DOI content negotiation
|
||||
↓
|
||||
4. VALIDATE → Confirm the claim appears in source
|
||||
↓
|
||||
5. ADD → Add verified entry to .bib file
|
||||
```
|
||||
|
||||
### Step 1: Search
|
||||
|
||||
Use Semantic Scholar for ML/AI papers:
|
||||
|
||||
```python
|
||||
from semanticscholar import SemanticScholar
|
||||
|
||||
sch = SemanticScholar()
|
||||
results = sch.search_paper("transformer attention mechanism", limit=10)
|
||||
|
||||
for paper in results:
|
||||
print(f"Title: {paper.title}")
|
||||
print(f"Year: {paper.year}")
|
||||
print(f"DOI: {paper.externalIds.get('DOI', 'N/A')}")
|
||||
print(f"arXiv: {paper.externalIds.get('ArXiv', 'N/A')}")
|
||||
print(f"Citation count: {paper.citationCount}")
|
||||
print("---")
|
||||
```
|
||||
|
||||
### Step 2: Verify Existence
|
||||
|
||||
Confirm paper exists in at least two sources:
|
||||
|
||||
```python
|
||||
import requests
|
||||
|
||||
def verify_paper(doi=None, arxiv_id=None, title=None):
|
||||
"""Verify paper exists in multiple sources."""
|
||||
sources_found = []
|
||||
|
||||
# Check Semantic Scholar
|
||||
sch = SemanticScholar()
|
||||
if doi:
|
||||
paper = sch.get_paper(f"DOI:{doi}")
|
||||
if paper:
|
||||
sources_found.append("Semantic Scholar")
|
||||
|
||||
# Check CrossRef (via DOI)
|
||||
if doi:
|
||||
resp = requests.get(f"https://api.crossref.org/works/{doi}")
|
||||
if resp.status_code == 200:
|
||||
sources_found.append("CrossRef")
|
||||
|
||||
# Check arXiv
|
||||
if arxiv_id:
|
||||
resp = requests.get(
|
||||
f"http://export.arxiv.org/api/query?id_list={arxiv_id}"
|
||||
)
|
||||
if "<entry>" in resp.text:
|
||||
sources_found.append("arXiv")
|
||||
|
||||
return len(sources_found) >= 2, sources_found
|
||||
```
|
||||
|
||||
### Step 3: Retrieve BibTeX
|
||||
|
||||
Use DOI content negotiation for guaranteed accuracy:
|
||||
|
||||
```python
|
||||
import requests
|
||||
|
||||
def doi_to_bibtex(doi: str) -> str:
|
||||
"""Get verified BibTeX from DOI via CrossRef content negotiation."""
|
||||
response = requests.get(
|
||||
f"https://doi.org/{doi}",
|
||||
headers={"Accept": "application/x-bibtex"},
|
||||
allow_redirects=True
|
||||
)
|
||||
response.raise_for_status()
|
||||
return response.text
|
||||
|
||||
# Example: "Attention Is All You Need"
|
||||
bibtex = doi_to_bibtex("10.48550/arXiv.1706.03762")
|
||||
print(bibtex)
|
||||
```
|
||||
|
||||
### Step 4: Validate Claims
|
||||
|
||||
Before citing a paper for a specific claim, verify the claim exists:
|
||||
|
||||
```python
|
||||
def get_paper_abstract(doi):
|
||||
"""Get abstract to verify claims."""
|
||||
sch = SemanticScholar()
|
||||
paper = sch.get_paper(f"DOI:{doi}")
|
||||
return paper.abstract if paper else None
|
||||
|
||||
# Verify claim appears in abstract
|
||||
abstract = get_paper_abstract("10.48550/arXiv.1706.03762")
|
||||
claim = "attention mechanism"
|
||||
if claim.lower() in abstract.lower():
|
||||
print("Claim appears in paper")
|
||||
```
|
||||
|
||||
### Step 5: Add to Bibliography
|
||||
|
||||
Add verified entry to your .bib file with consistent key format:
|
||||
|
||||
```python
|
||||
def generate_citation_key(bibtex: str) -> str:
|
||||
"""Generate consistent citation key: author_year_firstword."""
|
||||
import re
|
||||
|
||||
# Extract author
|
||||
author_match = re.search(r'author\s*=\s*\{([^}]+)\}', bibtex, re.I)
|
||||
if author_match:
|
||||
first_author = author_match.group(1).split(',')[0].split()[-1]
|
||||
else:
|
||||
first_author = "unknown"
|
||||
|
||||
# Extract year
|
||||
year_match = re.search(r'year\s*=\s*\{?(\d{4})\}?', bibtex, re.I)
|
||||
year = year_match.group(1) if year_match else "0000"
|
||||
|
||||
# Extract title first word
|
||||
title_match = re.search(r'title\s*=\s*\{([^}]+)\}', bibtex, re.I)
|
||||
if title_match:
|
||||
first_word = title_match.group(1).split()[0].lower()
|
||||
first_word = re.sub(r'[^a-z]', '', first_word)
|
||||
else:
|
||||
first_word = "paper"
|
||||
|
||||
return f"{first_author.lower()}_{year}_{first_word}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Python Implementation
|
||||
|
||||
### Complete Citation Manager Class
|
||||
|
||||
```python
|
||||
"""
|
||||
Citation Manager - Verified citation workflow for ML papers.
|
||||
"""
|
||||
|
||||
import requests
|
||||
import time
|
||||
from typing import Optional, List, Dict, Tuple
|
||||
from dataclasses import dataclass
|
||||
|
||||
try:
|
||||
from semanticscholar import SemanticScholar
|
||||
except ImportError:
|
||||
print("Install: pip install semanticscholar")
|
||||
SemanticScholar = None
|
||||
|
||||
@dataclass
|
||||
class Paper:
|
||||
title: str
|
||||
authors: List[str]
|
||||
year: int
|
||||
doi: Optional[str]
|
||||
arxiv_id: Optional[str]
|
||||
venue: Optional[str]
|
||||
citation_count: int
|
||||
abstract: Optional[str]
|
||||
|
||||
class CitationManager:
|
||||
"""Manage citations with verification."""
|
||||
|
||||
def __init__(self, api_key: Optional[str] = None):
|
||||
self.sch = SemanticScholar(api_key=api_key) if SemanticScholar else None
|
||||
self.verified_papers: Dict[str, Paper] = {}
|
||||
|
||||
def search(self, query: str, limit: int = 10) -> List[Paper]:
|
||||
"""Search for papers using Semantic Scholar."""
|
||||
if not self.sch:
|
||||
raise RuntimeError("Semantic Scholar not available")
|
||||
|
||||
results = self.sch.search_paper(query, limit=limit)
|
||||
papers = []
|
||||
|
||||
for r in results:
|
||||
paper = Paper(
|
||||
title=r.title,
|
||||
authors=[a.name for a in (r.authors or [])],
|
||||
year=r.year or 0,
|
||||
doi=r.externalIds.get('DOI') if r.externalIds else None,
|
||||
arxiv_id=r.externalIds.get('ArXiv') if r.externalIds else None,
|
||||
venue=r.venue,
|
||||
citation_count=r.citationCount or 0,
|
||||
abstract=r.abstract
|
||||
)
|
||||
papers.append(paper)
|
||||
|
||||
return papers
|
||||
|
||||
def verify(self, paper: Paper) -> Tuple[bool, List[str]]:
|
||||
"""Verify paper exists in multiple sources."""
|
||||
sources = []
|
||||
|
||||
# Already found in Semantic Scholar via search
|
||||
sources.append("Semantic Scholar")
|
||||
|
||||
# Check CrossRef if DOI available
|
||||
if paper.doi:
|
||||
try:
|
||||
resp = requests.get(
|
||||
f"https://api.crossref.org/works/{paper.doi}",
|
||||
timeout=10
|
||||
)
|
||||
if resp.status_code == 200:
|
||||
sources.append("CrossRef")
|
||||
except:
|
||||
pass
|
||||
|
||||
# Check arXiv if ID available
|
||||
if paper.arxiv_id:
|
||||
try:
|
||||
resp = requests.get(
|
||||
f"http://export.arxiv.org/api/query?id_list={paper.arxiv_id}",
|
||||
timeout=10
|
||||
)
|
||||
if "<entry>" in resp.text and "<title>" in resp.text:
|
||||
sources.append("arXiv")
|
||||
except:
|
||||
pass
|
||||
|
||||
return len(sources) >= 2, sources
|
||||
|
||||
def get_bibtex(self, paper: Paper) -> Optional[str]:
|
||||
"""Get BibTeX for verified paper."""
|
||||
if paper.doi:
|
||||
try:
|
||||
resp = requests.get(
|
||||
f"https://doi.org/{paper.doi}",
|
||||
headers={"Accept": "application/x-bibtex"},
|
||||
timeout=10,
|
||||
allow_redirects=True
|
||||
)
|
||||
if resp.status_code == 200:
|
||||
return resp.text
|
||||
except:
|
||||
pass
|
||||
|
||||
# Fallback: generate from paper data
|
||||
return self._generate_bibtex(paper)
|
||||
|
||||
def _generate_bibtex(self, paper: Paper) -> str:
|
||||
"""Generate BibTeX from paper metadata."""
|
||||
# Generate citation key
|
||||
first_author = paper.authors[0].split()[-1] if paper.authors else "unknown"
|
||||
first_word = paper.title.split()[0].lower().replace(',', '').replace(':', '')
|
||||
key = f"{first_author.lower()}_{paper.year}_{first_word}"
|
||||
|
||||
# Format authors
|
||||
authors = " and ".join(paper.authors) if paper.authors else "Unknown"
|
||||
|
||||
bibtex = f"""@article{{{key},
|
||||
title = {{{paper.title}}},
|
||||
author = {{{authors}}},
|
||||
year = {{{paper.year}}},
|
||||
{'doi = {' + paper.doi + '},' if paper.doi else ''}
|
||||
{'eprint = {' + paper.arxiv_id + '},' if paper.arxiv_id else ''}
|
||||
{'journal = {' + paper.venue + '},' if paper.venue else ''}
|
||||
}}"""
|
||||
return bibtex
|
||||
|
||||
def cite(self, query: str) -> Optional[str]:
|
||||
"""Full workflow: search, verify, return BibTeX."""
|
||||
# Search
|
||||
papers = self.search(query, limit=5)
|
||||
if not papers:
|
||||
return None
|
||||
|
||||
# Take top result
|
||||
paper = papers[0]
|
||||
|
||||
# Verify
|
||||
verified, sources = self.verify(paper)
|
||||
if not verified:
|
||||
print(f"Warning: Could only verify in {sources}")
|
||||
|
||||
# Get BibTeX
|
||||
bibtex = self.get_bibtex(paper)
|
||||
|
||||
# Cache
|
||||
if bibtex:
|
||||
self.verified_papers[paper.title] = paper
|
||||
|
||||
return bibtex
|
||||
|
||||
|
||||
# Usage example
|
||||
if __name__ == "__main__":
|
||||
cm = CitationManager()
|
||||
|
||||
# Search and cite
|
||||
bibtex = cm.cite("attention is all you need transformer")
|
||||
if bibtex:
|
||||
print(bibtex)
|
||||
```
|
||||
|
||||
### Quick Functions
|
||||
|
||||
```python
|
||||
def quick_cite(query: str) -> str:
|
||||
"""One-liner citation."""
|
||||
cm = CitationManager()
|
||||
return cm.cite(query)
|
||||
|
||||
def batch_cite(queries: List[str], output_file: str = "references.bib"):
|
||||
"""Cite multiple papers and save to file."""
|
||||
cm = CitationManager()
|
||||
bibtex_entries = []
|
||||
|
||||
for query in queries:
|
||||
print(f"Processing: {query}")
|
||||
bibtex = cm.cite(query)
|
||||
if bibtex:
|
||||
bibtex_entries.append(bibtex)
|
||||
time.sleep(1) # Rate limiting
|
||||
|
||||
with open(output_file, 'w') as f:
|
||||
f.write("\n\n".join(bibtex_entries))
|
||||
|
||||
print(f"Saved {len(bibtex_entries)} citations to {output_file}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## BibTeX Management
|
||||
|
||||
### BibTeX vs BibLaTeX
|
||||
|
||||
| Feature | BibTeX | BibLaTeX |
|
||||
|---------|--------|----------|
|
||||
| Unicode support | Limited | Full |
|
||||
| Entry types | Standard | Extended (@online, @dataset) |
|
||||
| Customization | Limited | Highly flexible |
|
||||
| Backend | bibtex | Biber (recommended) |
|
||||
|
||||
**Recommendation**: Use BibLaTeX with Biber for new papers.
|
||||
|
||||
### LaTeX Setup
|
||||
|
||||
```latex
|
||||
% In preamble
|
||||
\usepackage[
|
||||
backend=biber,
|
||||
style=numeric,
|
||||
sorting=none
|
||||
]{biblatex}
|
||||
\addbibresource{references.bib}
|
||||
|
||||
% In document
|
||||
\cite{vaswani_2017_attention}
|
||||
|
||||
% At end
|
||||
\printbibliography
|
||||
```
|
||||
|
||||
### Citation Commands
|
||||
|
||||
```latex
|
||||
\cite{key} % Numeric: [1]
|
||||
\citep{key} % Parenthetical: (Author, 2020)
|
||||
\citet{key} % Textual: Author (2020)
|
||||
\citeauthor{key} % Just author name
|
||||
\citeyear{key} % Just year
|
||||
```
|
||||
|
||||
### Consistent Citation Keys
|
||||
|
||||
Use format: `author_year_firstword`
|
||||
|
||||
```
|
||||
vaswani_2017_attention
|
||||
devlin_2019_bert
|
||||
brown_2020_language
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Citation Formats
|
||||
|
||||
### Conference Paper
|
||||
|
||||
```bibtex
|
||||
@inproceedings{vaswani_2017_attention,
|
||||
title = {Attention Is All You Need},
|
||||
author = {Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and
|
||||
Uszkoreit, Jakob and Jones, Llion and Gomez, Aidan N and
|
||||
Kaiser, Lukasz and Polosukhin, Illia},
|
||||
booktitle = {Advances in Neural Information Processing Systems},
|
||||
volume = {30},
|
||||
year = {2017},
|
||||
publisher = {Curran Associates, Inc.}
|
||||
}
|
||||
```
|
||||
|
||||
### Journal Article
|
||||
|
||||
```bibtex
|
||||
@article{hochreiter_1997_long,
|
||||
title = {Long Short-Term Memory},
|
||||
author = {Hochreiter, Sepp and Schmidhuber, J{\"u}rgen},
|
||||
journal = {Neural Computation},
|
||||
volume = {9},
|
||||
number = {8},
|
||||
pages = {1735--1780},
|
||||
year = {1997},
|
||||
publisher = {MIT Press}
|
||||
}
|
||||
```
|
||||
|
||||
### arXiv Preprint
|
||||
|
||||
```bibtex
|
||||
@misc{brown_2020_language,
|
||||
title = {Language Models are Few-Shot Learners},
|
||||
author = {Brown, Tom and Mann, Benjamin and Ryder, Nick and others},
|
||||
year = {2020},
|
||||
eprint = {2005.14165},
|
||||
archiveprefix = {arXiv},
|
||||
primaryclass = {cs.CL}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue: Semantic Scholar returns no results**
|
||||
- Try more specific keywords
|
||||
- Check spelling of author names
|
||||
- Use quotation marks for exact phrases
|
||||
|
||||
**Issue: DOI doesn't resolve to BibTeX**
|
||||
- DOI may be registered but not linked to CrossRef
|
||||
- Try arXiv ID instead if available
|
||||
- Generate BibTeX from metadata manually
|
||||
|
||||
**Issue: Rate limiting errors**
|
||||
- Add delays between requests (1-3 seconds)
|
||||
- Use API key if available
|
||||
- Cache results to avoid repeat queries
|
||||
|
||||
**Issue: Encoding problems in BibTeX**
|
||||
- Use proper LaTeX escaping: `{\"u}` for ü
|
||||
- Ensure file is UTF-8 encoded
|
||||
- Use BibLaTeX with Biber for better Unicode
|
||||
|
||||
### Verification Checklist
|
||||
|
||||
Before adding a citation:
|
||||
|
||||
- [ ] Paper found in at least 2 sources
|
||||
- [ ] DOI or arXiv ID verified
|
||||
- [ ] BibTeX retrieved (not generated from memory)
|
||||
- [ ] Entry type correct (@inproceedings vs @article)
|
||||
- [ ] Author names complete and correctly formatted
|
||||
- [ ] Year and venue verified
|
||||
- [ ] Citation key follows consistent format
|
||||
|
||||
---
|
||||
|
||||
## Additional Resources
|
||||
|
||||
**APIs:**
|
||||
- Semantic Scholar: https://api.semanticscholar.org/api-docs/
|
||||
- CrossRef: https://www.crossref.org/documentation/retrieve-metadata/rest-api/
|
||||
- arXiv: https://info.arxiv.org/help/api/basics.html
|
||||
- OpenAlex: https://docs.openalex.org/
|
||||
|
||||
**Python Libraries:**
|
||||
- `semanticscholar`: https://pypi.org/project/semanticscholar/
|
||||
- `arxiv`: https://pypi.org/project/arxiv/
|
||||
- `habanero` (CrossRef): https://github.com/sckott/habanero
|
||||
|
||||
**Verification Tools:**
|
||||
- Citely: https://citely.ai/citation-checker
|
||||
- ReciteWorks: https://reciteworks.com/
|
||||
@@ -0,0 +1,58 @@
|
||||
# Academic Writing Knowledge Base
|
||||
|
||||
This knowledge base contains reusable academic writing knowledge mined from papers.
|
||||
|
||||
## Canonical maintained memory
|
||||
|
||||
The canonical paper-miner memory is:
|
||||
|
||||
- `paper-miner-writing-memory.md`
|
||||
|
||||
This is the **only maintained paper-miner writing memory**.
|
||||
|
||||
It stores:
|
||||
- writing patterns mined,
|
||||
- structure signals,
|
||||
- reusable phrasing,
|
||||
- venue-specific signals,
|
||||
- how those signals help future writing,
|
||||
- and a source index.
|
||||
|
||||
## Maintenance rule
|
||||
|
||||
`paper-miner` always writes mined writing knowledge into `paper-miner-writing-memory.md`.
|
||||
|
||||
This memory is:
|
||||
- **global**,
|
||||
- **cross-project**,
|
||||
- **not project-specific**.
|
||||
|
||||
If `paper-miner` is invoked inside a project, it may use project context to understand relevance, but it still writes only to the global memory.
|
||||
|
||||
## Legacy files
|
||||
|
||||
Older files such as:
|
||||
- `structure.md`
|
||||
- `writing-techniques.md`
|
||||
- `submission-guides.md`
|
||||
- `review-response.md`
|
||||
|
||||
may still exist as historical material, but new paper-miner updates should treat `paper-miner-writing-memory.md` as the canonical maintained memory.
|
||||
|
||||
## Usage
|
||||
|
||||
Use this knowledge base when:
|
||||
- drafting papers,
|
||||
- improving section structure,
|
||||
- borrowing reusable phrasing patterns,
|
||||
- preparing rebuttals,
|
||||
- studying venue-facing writing signals.
|
||||
|
||||
## Contributing
|
||||
|
||||
When `paper-miner` analyzes a new paper:
|
||||
1. extract actionable writing knowledge,
|
||||
2. merge it into `paper-miner-writing-memory.md`,
|
||||
3. preserve source attribution,
|
||||
4. avoid duplicate patterns,
|
||||
5. keep the memory compact and reusable.
|
||||
@@ -0,0 +1,605 @@
|
||||
# Design Simplification Papers: Less Is More
|
||||
|
||||
**Source**: Kaiming He et al., "Exploring Plain Vision Transformer Backbones for Object Detection" (ViTDet, 2022)
|
||||
|
||||
**Paper Type**: Design simplification / Minimal adaptations paper
|
||||
|
||||
**Core Pattern**: Challenge design assumptions → Minimize changes → Surprising effectiveness → Fair comparison
|
||||
|
||||
---
|
||||
|
||||
## 1. Abstract Structure: The "Surprisingly" Framework
|
||||
|
||||
### Pattern: Conventional Practice → Simple Alternative → Unexpected Results
|
||||
|
||||
**Template**:
|
||||
```markdown
|
||||
Abstract:
|
||||
1. [Context] Standard practice in [domain] is [conventional design]
|
||||
2. [Challenge] With [new technology], this faces [challenges]
|
||||
3. [Common Solution] Most work addresses this by [abandoning philosophy / adding complexity]
|
||||
4. [Our Direction] We explore [different direction]: [minimal approach]
|
||||
5. [Surprisingly 1] Surprisingly, we observe: (i) [simple finding 1]
|
||||
and (ii) [simple finding 2]
|
||||
6. [Surprisingly 2] More surprisingly, [stronger claim under conditions]
|
||||
7. [Implications] This enables [benefit] without [traditional requirement]
|
||||
```
|
||||
|
||||
### ViTDet Abstract Example (annotated):
|
||||
|
||||
```latex
|
||||
Modern object detectors consist of hierarchical backbone feature extractors
|
||||
and detection-specific necks/heads (e.g., FPN, RPN).
|
||||
|
||||
With Vision Transformers (ViT) emerging as powerful backbones, their plain,
|
||||
non-hierarchical nature poses challenges: How to address multi-scale objects?
|
||||
|
||||
One solution abandons the plain ViT philosophy, re-introducing hierarchical
|
||||
designs (e.g., Swin).
|
||||
|
||||
We pursue a different direction: plain ViT backbones with minimal adaptations.
|
||||
|
||||
Surprisingly, we observe: (i) A simple feature pyramid from a single-scale map
|
||||
is sufficient (without FPN), and (ii) Window attention without shifting is
|
||||
sufficient (with a few propagation blocks).
|
||||
|
||||
More surprisingly, under some circumstances, our ViTDet can compete with
|
||||
leading hierarchical detectors like Swin.
|
||||
|
||||
With MAE pre-training, ViTDet outperforms hierarchical counterparts,
|
||||
especially for larger models.
|
||||
|
||||
This decouples pre-training from fine-tuning, maintaining independence of
|
||||
upstream vs downstream tasks.
|
||||
```
|
||||
|
||||
### Key Techniques:
|
||||
|
||||
1. **"Modern...consist of..."** - Establish conventional practice
|
||||
2. **"With...emerging as..."** - New technology, new challenge
|
||||
3. **"abandons the...philosophy"** - Critique common solutions
|
||||
4. **"We pursue a different direction"** - Clear positioning
|
||||
5. **"Surprisingly, we observe: (i)... and (ii)..."** - First surprise
|
||||
6. **"More surprisingly..."** - Second, deeper surprise
|
||||
7. **"under some circumstances"** - Measured claim
|
||||
8. **"sufficient"** - Scientific (not "optimal")
|
||||
9. **"without [common practice]"** - Negative emphasis
|
||||
|
||||
---
|
||||
|
||||
## 2. Introduction: The "Challenge Assumptions" Framework
|
||||
|
||||
### Pattern: Tradition → New Challenge → Common Compromise → Your Alternative → Philosophy
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Traditional Practice] Established design in [field]
|
||||
2. [Evolution] How this emerged historically ("For a long while...")
|
||||
3. [New Challenge] [New technology] with [different characteristics]
|
||||
4. [Philosophy Clash] Original [tech] has "'minimalist' pursuit"
|
||||
- Questions: "How can we...?" "Is [X] too inefficient?"
|
||||
5. [Common Solution] One solution: [abandon philosophy] → [revert to old design]
|
||||
- Acknowledge: "has shown successful results"
|
||||
6. [Your Direction] "we pursue a different direction"
|
||||
- Motivation: "If successful, enables [benefit]"
|
||||
7. [Philosophy] "in part follows the [philosophy] of '[concept]'"
|
||||
8. [Surprising Findings] "Surprisingly, we observe..."
|
||||
9. [Implications] "More surprisingly..." → Competitive results
|
||||
```
|
||||
|
||||
### ViTDet Introduction Flow:
|
||||
|
||||
#### Traditional Practice (Establish Context)
|
||||
```latex
|
||||
Modern object detectors in general consist of a backbone feature extractor
|
||||
that is agnostic to the detection task and a set of necks and heads that
|
||||
incorporate detection-specific prior knowledge.
|
||||
|
||||
Common components in the necks/heads may include Region-of-Interest (RoI)
|
||||
operations, Region Proposal Networks (RPN) or anchors, Feature Pyramid
|
||||
Networks (FPN), etc.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"in general consist of"** - Standard architecture
|
||||
- **"agnostic to"** vs **"detection-specific"** - Clear division
|
||||
- **"may include"** - Examples, not exhaustive
|
||||
|
||||
#### Historical Evolution
|
||||
```latex
|
||||
For a long while, these backbones have been multi-scale, hierarchical
|
||||
architectures due to the de facto design of convolutional networks (ConvNet),
|
||||
which has heavily influenced the neck/head design for detecting objects at
|
||||
multiple scales (e.g., FPN).
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"For a long while"** - Historical dimension
|
||||
- **"due to...which has heavily influenced"** - Causal chain
|
||||
- **"de facto design"** - Established convention
|
||||
|
||||
#### New Technology Challenge
|
||||
```latex
|
||||
Over the past year, Vision Transformers (ViT) have been established as a
|
||||
powerful backbone for visual recognition.
|
||||
|
||||
Unlike typical ConvNets, the original ViT is a plain, non-hierarchical
|
||||
architecture that maintains a single-scale feature map throughout.
|
||||
|
||||
Its 'minimalist' pursuit is met with challenges when applied to object
|
||||
detection—e.g., How can we address multi-scale objects in a downstream task
|
||||
with a plain backbone from upstream pre-training? Is a plain ViT too
|
||||
inefficient to use with high-resolution detection images?
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"Over the past year...have been established as"** - Timeframe
|
||||
- **"Unlike typical ConvNets"** - Direct contrast
|
||||
- **"plain, non-hierarchical"**, **"single-scale"** - Key characteristics
|
||||
- **"'minimalist' pursuit"** - Philosophy (in quotes)
|
||||
- **Two questions**: Challenge reader to think
|
||||
|
||||
#### Common Solution (Acknowledge then Pivot)
|
||||
```latex
|
||||
One solution, which abandons this pursuit, is to re-introduce hierarchical
|
||||
designs into the backbone.
|
||||
|
||||
This solution, e.g., Swin Transformers and related works, can inherit the
|
||||
ConvNet-based detector design and has shown successful results.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"which abandons this pursuit"** - Critique (respectful)
|
||||
- **"can inherit"** - Acknowledge advantage
|
||||
- **"has shown successful results"** - Don't deny effectiveness
|
||||
|
||||
#### Your Different Direction
|
||||
```latex
|
||||
In this work, we pursue a different direction: we explore object detectors
|
||||
that use only plain, non-hierarchical backbones.
|
||||
|
||||
If this direction is successful, it will enable the use of original ViT
|
||||
backbones for object detection; this will decouple the pre-training design
|
||||
from the fine-tuning demands, maintaining the independence of upstream vs.
|
||||
downstream tasks, as has been the case for ConvNet-based research.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"we pursue a different direction"** - Clear positioning
|
||||
- **"If this direction is successful, it will enable..."** - Motivation
|
||||
- **"decouple"**, **"independence"** - Philosophy keywords
|
||||
- **"as has been the case for..."** - Historical precedent
|
||||
|
||||
#### Philosophy Elevation
|
||||
```latex
|
||||
This direction also in part follows the ViT philosophy of 'fewer inductive
|
||||
biases' in the pursuit of universal features.
|
||||
|
||||
As the non-local self-attention computation can learn translation-equivariant
|
||||
features, they may also learn scale-equivariant features from certain forms
|
||||
of supervised or self-supervised pre-training.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"in part follows the...philosophy of"** - Theoretical connection
|
||||
- **"fewer inductive biases"** - Core concept
|
||||
- **Analogy**: translation-equivariant → scale-equivariant
|
||||
- **"may also learn"** - Speculation (honest)
|
||||
|
||||
#### Surprising Findings
|
||||
```latex
|
||||
Surprisingly, we observe: (i) it is sufficient to build a simple feature
|
||||
pyramid from a single-scale feature map (without the common FPN design) and
|
||||
(ii) it is sufficient to use window attention (without shifting) aided with
|
||||
very few cross-window propagation blocks.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"Surprisingly, we observe:"** - Marker
|
||||
- **(i)** and **(ii)** - Structured list
|
||||
- **"sufficient to"** - Not "optimal", scientific phrasing
|
||||
- **"without the common [X]"** - Negative differentiation
|
||||
|
||||
#### Deeper Surprise
|
||||
```latex
|
||||
More surprisingly, under some circumstances, our plain-backbone detector,
|
||||
named ViTDet, can compete with the leading hierarchical-backbone detectors
|
||||
(e.g., Swin, MViT).
|
||||
|
||||
With Masked Autoencoder (MAE) pre-training, our plain-backbone detector can
|
||||
outperform the hierarchical counterparts that are pre-trained on ImageNet-1K/21K
|
||||
with supervision (Figure 3).
|
||||
|
||||
The gains are more prominent for larger model sizes.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"More surprisingly"** - Progressive emphasis
|
||||
- **"under some circumstances"** - Measured claim
|
||||
- **"named ViTDet"** - Brand at results
|
||||
- **Specific comparison**: MAE vs ImageNet supervised
|
||||
- **"The gains are more prominent for..."** - Pattern observation
|
||||
|
||||
---
|
||||
|
||||
## 3. Methods Section: The "Minimal Adaptations" Narrative
|
||||
|
||||
### Pattern: We Don't Aim to Invent, We Minimize
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Declaration] We do NOT aim to develop new components
|
||||
2. [Philosophy] Instead, make minimal adaptations sufficient to overcome challenges
|
||||
3. [Specific] In particular, [what we actually do]
|
||||
4. [Abandonment] This abandons [traditional component]
|
||||
5. [Decoupling] Adaptations only during fine-tuning, do not alter pre-training
|
||||
6. [Contrast] This is in contrast to [recent methods] that [what they do]
|
||||
7. [Benefit] Our scenario enables [benefit], without [cost]
|
||||
```
|
||||
|
||||
### ViTDet Methods Narrative:
|
||||
|
||||
```latex
|
||||
In our study, we do not aim to develop new components; instead, we make
|
||||
minimal adaptations that are sufficient to overcome the aforementioned
|
||||
challenges.
|
||||
|
||||
In particular, our detector builds a simple feature pyramid from only the
|
||||
last feature map of a plain ViT backbone (Figure 1).
|
||||
|
||||
This abandons the FPN design and waives the requirement of a hierarchical
|
||||
backbone.
|
||||
|
||||
These adaptations are made only during fine-tuning and do not alter pre-training.
|
||||
|
||||
This is in contrast to the recent methods that modify the attention computation
|
||||
directly with backbone pre-training (e.g., Swin, MViT).
|
||||
|
||||
Our scenario enables us to use the original ViT backbone for detection, without
|
||||
redesigning pre-training architectures.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"we do not aim to develop new components"** - Clear scope
|
||||
- **"minimal adaptations"** - Philosophy
|
||||
- **"sufficient to"** - Not maximal, necessary
|
||||
- **"This abandons..."** - What you give up
|
||||
- **"only during fine-tuning"** - Temporal boundary
|
||||
- **"do not alter pre-training"** - Upstream independence
|
||||
- **"This is in contrast to"** - Competitor positioning
|
||||
- **"enables us to use"** - Practical benefit
|
||||
|
||||
---
|
||||
|
||||
## 4. Fair Comparison: The "Equal Effort" Declaration
|
||||
|
||||
### Pattern: Admit Complexity → Claim Effort → Demonstrate Fairness
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Admit] Modern systems involve [complexity]
|
||||
2. [Claim] To compare as fairly as possible, we [effort]
|
||||
3. [Specific 1] Use same [implementation] for all
|
||||
4. [Specific 2] Different backbones get [appropriate treatment]
|
||||
5. [Validation] Our results for [competitor] are [better/equal] to original
|
||||
6. [Implication] Since we reproduce others well, comparisons are fair
|
||||
```
|
||||
|
||||
### ViTDet Fair Comparison Statement:
|
||||
|
||||
```latex
|
||||
Modern detection systems involve many implementation details and subtleties.
|
||||
|
||||
To focus on comparing backbones under as fair conditions as possible, we
|
||||
incorporate the Swin and MViTv2 backbones into our implementation.
|
||||
|
||||
We use the same implementation of Mask R-CNN and Cascade Mask R-CNN for all
|
||||
ViT, Swin, and MViTv2 backbones.
|
||||
|
||||
We use FPN for the hierarchical backbones of Swin/MViTv2.
|
||||
|
||||
We search for optimal hyper-parameters separately for each backbone.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"involve many implementation details and subtleties"** - Admit difficulty
|
||||
- **"under as fair conditions as possible"** - Effort disclaimer
|
||||
- **"incorporate...into our implementation"** - What we did
|
||||
- **"use the same...for all"** - Unified framework
|
||||
- **"search for optimal...separately"** - Equal effort
|
||||
|
||||
#### Self-Validation
|
||||
```latex
|
||||
Our Swin results are better than their counterparts in the original paper;
|
||||
our MViTv2 results are better than or on par with those reported in the
|
||||
original paper.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- Report self-results → Show competence → Imply fairness
|
||||
|
||||
---
|
||||
|
||||
## 5. Results: Multi-Factor Analysis
|
||||
|
||||
### Pattern: Factors, Trends, Wall-Clock Time
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Acknowledge Complexity] Comparisons involve [factors]
|
||||
2. [Identify Trend] Our method presents better [trend behavior]
|
||||
3. [Qualify] When [condition], our method [advantage]
|
||||
4. [Expand] Moreover, [second dimension advantage]
|
||||
5. [Explain] as [reason related to simplicity]
|
||||
```
|
||||
|
||||
### ViTDet Results Narrative:
|
||||
|
||||
```latex
|
||||
Figure 3 plots the trade-offs.
|
||||
|
||||
The comparisons here involve two factors: the backbone and the pre-training
|
||||
strategy.
|
||||
|
||||
Our plain-backbone detector, combined with MAE pre-training, presents better
|
||||
scaling behavior.
|
||||
|
||||
When the models are large, our method outperforms the hierarchical
|
||||
counterparts of Swin/MViTv2, including those using IN-21K supervised
|
||||
pre-training.
|
||||
|
||||
Moreover, the plain ViT has a better wall-clock performance (Figure 3 right),
|
||||
as the simpler blocks are more hardware-friendly.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"involve two factors"** - Analysis depth
|
||||
- **"presents better scaling behavior"** - Trend, not just points
|
||||
- **"When the models are large"** - Qualify claim
|
||||
- **"Moreover"** - Second dimension
|
||||
- **"better wall-clock performance"** - Practical metric
|
||||
- **"simpler blocks are more hardware-friendly"** - Explain why
|
||||
|
||||
---
|
||||
|
||||
## 6. "Surprisingly" Usage: Multi-Level Pattern
|
||||
|
||||
### Level 1: Basic Surprise (Abstract)
|
||||
|
||||
```latex
|
||||
Surprisingly, we observe: (i) [simple sufficient without common practice]
|
||||
and (ii) [simple sufficient without common practice]
|
||||
```
|
||||
|
||||
**Characteristics**:
|
||||
- Two findings (i) and (ii)
|
||||
- "sufficient" not "optimal"
|
||||
- "without [common practice]"
|
||||
- Structured presentation
|
||||
|
||||
### Level 2: Competitive Surprise (Introduction)
|
||||
|
||||
```latex
|
||||
More surprisingly, under some circumstances, our [method] can compete
|
||||
with the leading [competitors].
|
||||
```
|
||||
|
||||
**Characteristics**:
|
||||
- "More surprisingly" - Progressive
|
||||
- "under some circumstances" - Measured
|
||||
- "compete with" - Not "beat", competitive
|
||||
- Name competitors specifically
|
||||
|
||||
### Level 3: Superiority Surprise (Introduction)
|
||||
|
||||
```latex
|
||||
With [specific condition], our [method] can outperform the [competitors]
|
||||
that use [stronger condition].
|
||||
|
||||
The gains are more prominent for [specific condition].
|
||||
```
|
||||
|
||||
**Characteristics**:
|
||||
- Specific conditions compared
|
||||
- "outperform" - Stronger claim here
|
||||
- Pattern observation: "more prominent for"
|
||||
- Shows understanding of when/where
|
||||
|
||||
---
|
||||
|
||||
## 7. Ablation Study: Incremental + Destructive
|
||||
|
||||
### Pattern: Baseline → Incremental Additions → Sufficient
|
||||
|
||||
**Table Design**:
|
||||
```markdown
|
||||
Table X: [Component] Ablation
|
||||
┌──────────────────────────────────────────┐
|
||||
│ Baseline | Metric | Δ │
|
||||
├──────────────────────────────────────────┤
|
||||
│ no [component] | 47.8 | - │
|
||||
│ (a) [common] | 50.3 | +2.5 │
|
||||
│ (b) [variant] | 50.9 | +3.1 │
|
||||
│ (c) ours: simple | 51.2 | +3.4 ✓ │
|
||||
├──────────────────────────────────────────┤
|
||||
│ Conclusion: Our simple [X] is sufficient │
|
||||
└──────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### ViTDet Table 1 Example:
|
||||
|
||||
```latex
|
||||
pyramid design APbox APmask
|
||||
─────────────────────────────────────────
|
||||
no feature pyramid 47.8 42.5
|
||||
(a) FPN, 4-stage 50.3 44.9
|
||||
(b) FPN, last-map 50.9 45.3
|
||||
(c) simple feature pyramid 51.2 45.5
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **Baseline**: "no [X]" shows it's needed
|
||||
- **(a), (b), (c)**: Progressive variations
|
||||
- **Δ标注**: (+2.5) - Show incremental gains
|
||||
- **Conclusion text**: "our simple pyramid is sufficient"
|
||||
|
||||
---
|
||||
|
||||
## 8. "Interestingly" Usage: Pattern + Explanation
|
||||
|
||||
### Pattern: Observation → Literature Support → Explanation
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
Interestingly, [observation].
|
||||
|
||||
This is in line with the observation in [paper] that [their finding].
|
||||
|
||||
[Additional explanation or hypothesis].
|
||||
```
|
||||
|
||||
### ViTDet Example:
|
||||
|
||||
```latex
|
||||
Interestingly, performing propagation in the last 4 blocks is nearly as
|
||||
good as even placement.
|
||||
|
||||
This is in line with the observation in ViT [14] that ViT has longer
|
||||
attention distance in later blocks and is more localized in earlier ones.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"Interestingly"** - Marker for unexpected
|
||||
- **Observation**: Specific finding
|
||||
- **"in line with the observation in"** - Literature support
|
||||
- **Explanation**: Why it makes sense
|
||||
|
||||
---
|
||||
|
||||
## 9. Minimalism Keywords: Design Simplification Vocabulary
|
||||
|
||||
**Philosophy Keywords**:
|
||||
- "minimal" - "minimal adaptations"
|
||||
- "sufficient" - "is sufficient to" (not "optimal")
|
||||
- "simple" - "simple feature pyramid"
|
||||
- "plain" - "plain backbone"
|
||||
- "decouple" - "decouple pre-training from fine-tuning"
|
||||
- "independence" - "independence of upstream vs downstream"
|
||||
|
||||
**Direction Keywords**:
|
||||
- "pursue a different direction" - Positioning
|
||||
- "in contrast to" - Differentiation
|
||||
- "abandons" - What you give up
|
||||
- "enables" - What your approach allows
|
||||
|
||||
**Measured Claim Keywords**:
|
||||
- "under some circumstances" - Not always
|
||||
- "can compete with" - Competitive, not dominant
|
||||
- "more prominent for" - When effect is stronger
|
||||
- "is sufficient" - Necessary, not maximal
|
||||
|
||||
**Surprise Markers** (use in order):
|
||||
1. "Surprisingly" - First finding
|
||||
2. "More surprisingly" - Deeper finding
|
||||
3. "Interestingly" - Pattern observation
|
||||
4. "Notably" - Important detail
|
||||
5. "It is worth noting that" - Caveat/clarification
|
||||
|
||||
---
|
||||
|
||||
## 10. Common Mistakes in Design Simplification Papers
|
||||
|
||||
### ❌ Don't:
|
||||
- Claim your method is "optimal" - You're simplifying, not optimizing
|
||||
- Attack common practices - Acknowledge their value first
|
||||
- Overgeneralize - "under some circumstances" is honest
|
||||
- Forget to show fair comparison - Prove you tried hard with baselines
|
||||
- Hide complexity - Admit what you don't address
|
||||
|
||||
### ✅ Do:
|
||||
- Use "sufficient" instead of "optimal"
|
||||
- Say what you DON'T do ("do not aim to develop new components")
|
||||
- Emphasize minimal changes ("minimal adaptations")
|
||||
- Report when your method wins and when it doesn't
|
||||
- Show "surprisingly" findings with proper qualification
|
||||
- Demonstrate fair comparison effort
|
||||
- Adapt only where necessary (fine-tuning, not pre-training)
|
||||
|
||||
---
|
||||
|
||||
## 11. Revision Checklist for Design Simplification Papers
|
||||
|
||||
**Before Submission, Verify:**
|
||||
|
||||
- [ ] Abstract has "Surprisingly, we observe: (i)... and (ii)..."
|
||||
- [ ] Introduction establishes conventional practice first
|
||||
- [ ] Common solution is acknowledged ("has shown successful results")
|
||||
- [ ] "We pursue a different direction" is stated clearly
|
||||
- [ ] Philosophy is elevated ("fewer inductive biases")
|
||||
- [ ] "More surprisingly" used for deeper claim
|
||||
- [ ] Methods section says "we do not aim to develop new components"
|
||||
- [ ] "minimal adaptations" philosophy stated
|
||||
- [ ] "only during fine-tuning" boundary specified
|
||||
- [ ] Fair comparison effort described explicitly
|
||||
- [ ] Self-validation shown (our reproduction of others is good)
|
||||
- [ ] Multi-factor analysis in results (scaling, wall-clock)
|
||||
- [ ] Ablations show incremental progression
|
||||
- [ ] "sufficient" used, not "optimal"
|
||||
- [ ] Under what conditions is stated ("under some circumstances")
|
||||
|
||||
---
|
||||
|
||||
## 12. Example: Applying This Pattern
|
||||
|
||||
### Original Idea (Not Design Simplification):
|
||||
"We propose a new feature pyramid that improves detection AP by 3%."
|
||||
|
||||
### Design Simplification Version:
|
||||
"Modern detectors use hierarchical backbones with FPN. With plain ViT
|
||||
emerging as powerful backbones, a common solution re-introduces hierarchy
|
||||
(abandoning the plain philosophy). We pursue a different direction: plain
|
||||
backbones with minimal adaptations. Surprisingly, we observe a simple feature
|
||||
pyramid from a single-scale map is sufficient (without FPN). More
|
||||
surprisingly, with MAE pre-training, ViTDet competes with hierarchical
|
||||
detectors, especially for larger models. This decouples pre-training from
|
||||
fine-tuning, maintaining upstream/downstream independence."
|
||||
|
||||
**The Design Simplification Frame**:
|
||||
- Conventional: Hierarchy + FPN
|
||||
- Challenge: Plain ViT is...plain
|
||||
- Common: Swin (abandons philosophy)
|
||||
- Ours: Minimal adaptations
|
||||
- Surprise: Simple is sufficient
|
||||
- Philosophy: Decoupling, independence
|
||||
|
||||
---
|
||||
|
||||
## Paper Metadata
|
||||
|
||||
**Title**: Exploring Plain Vision Transformer Backbones for Object Detection (ViTDet)
|
||||
|
||||
**Authors**: Yanghao Li, Hanzi Mao, Kaiming He
|
||||
|
||||
**Venue**: ECCV 2022
|
||||
|
||||
**arXiv**: 2203.16527
|
||||
|
||||
**Key Concepts**:
|
||||
- Plain ViT for detection (no hierarchy needed)
|
||||
- Simple feature pyramid (no FPN needed)
|
||||
- Minimal adaptations philosophy
|
||||
- Decoupling pre-training from fine-tuning
|
||||
- MAE pre-training synergy
|
||||
|
||||
---
|
||||
|
||||
## Extracted by
|
||||
|
||||
**Date**: 2026-01-26
|
||||
|
||||
**Source**: Analysis of ViTDet paper (21 pages)
|
||||
|
||||
**Extraction Focus**: Design simplification paper writing patterns, "surprisingly"
|
||||
findings reporting, minimal adaptations philosophy, fair comparison strategies
|
||||
|
||||
**For Integration**: ml-paper-writing skill knowledge base
|
||||
@@ -0,0 +1,153 @@
|
||||
{
|
||||
"metadata": {
|
||||
"source": "Kaiming He Papers Analysis",
|
||||
"date": "2026-01-26",
|
||||
"papers_analyzed": 11,
|
||||
"analysis_method": "Text extraction and pattern mining",
|
||||
"latest_addition": {
|
||||
"papers": ["Mean Flows", "ViTDet", "MoCo v2", "Deconstructing Denoising Diffusion Models", "Autoregressive Image Generation (MAR)"],
|
||||
"extraction_date": "2026-01-26",
|
||||
"new_knowledge_files": [
|
||||
"theory-driven-papers-kaiming-he.md",
|
||||
"design-simplification-papers-kaiming-he.md"
|
||||
]
|
||||
}
|
||||
},
|
||||
"knowledge_files": {
|
||||
"structure.md": {
|
||||
"status": "updated",
|
||||
"last_update": "2026-01-26",
|
||||
"contains": "Basic structure patterns from 19 Kaiming He papers"
|
||||
},
|
||||
"writing-techniques.md": {
|
||||
"status": "needs_update",
|
||||
"last_update": "2026-01-26",
|
||||
"contains": "Basic writing techniques from 19 Kaiming He papers"
|
||||
},
|
||||
"rethinking-papers-kaiming-he.md": {
|
||||
"status": "complete",
|
||||
"focus": "Rethinking papers, challenging conventional wisdom",
|
||||
"source_paper": "Autoregressive Image Generation without Vector Quantization (NeurIPS 2024 Spotlight)"
|
||||
},
|
||||
"theory-driven-papers-kaiming-he.md": {
|
||||
"status": "new",
|
||||
"focus": "Theory-driven papers, first principles, MeanFlow Identity",
|
||||
"source_paper": "Mean Flows for One-step Generative Modeling (2025)"
|
||||
},
|
||||
"design-simplification-papers-kaiming-he.md": {
|
||||
"status": "new",
|
||||
"focus": "Design simplification, minimal adaptations, 'Surprisingly' findings",
|
||||
"source_paper": "Exploring Plain Vision Transformer Backbones for Object Detection (ViTDet, ECCV 2022)"
|
||||
}
|
||||
},
|
||||
"patterns_extracted": {
|
||||
"introduction_frameworks": {
|
||||
"principle_introduction": {
|
||||
"source": "MeanFlows",
|
||||
"pattern": "Background → Problem → Critique (Despite...) → Core Concept → Theory → Advantage → Results",
|
||||
"keywords": ["principled", "intrinsic", "well-defined", "naturally", "first principles"]
|
||||
},
|
||||
"challenge_assumptions": {
|
||||
"source": "ViTDet",
|
||||
"pattern": "Traditional → New Challenge → Common Solution → Our Direction → Philosophy → Surprisingly → Implications",
|
||||
"keywords": ["minimal adaptations", "sufficient", "decouple", "independence", "surprisingly"]
|
||||
},
|
||||
"rethinking_conventional_wisdom": {
|
||||
"source": "MAR",
|
||||
"pattern": "Conventional wisdom → Question → Analysis → Alternative → Results → Vision",
|
||||
"keywords": ["Conventional wisdom holds that", "Is it necessary", "not a necessity"]
|
||||
}
|
||||
},
|
||||
"surprisingly_findings": {
|
||||
"level_1": {
|
||||
"pattern": "Surprisingly, we observe: (i)... and (ii)...",
|
||||
"usage": "First-level surprise - basic findings",
|
||||
"example": "ViTDet Abstract"
|
||||
},
|
||||
"level_2": {
|
||||
"pattern": "More surprisingly, under some circumstances...",
|
||||
"usage": "Second-level surprise - competitive results",
|
||||
"example": "ViTDet Introduction"
|
||||
},
|
||||
"level_3": {
|
||||
"pattern": "With [condition], outperforms... gains more prominent for...",
|
||||
"usage": "Third-level surprise - superiority under conditions",
|
||||
"example": "ViTDet Introduction"
|
||||
},
|
||||
"variants": {
|
||||
"interestingly": "Observation + literature support + explanation",
|
||||
"notably": "Important detail or counter-intuitive result",
|
||||
"it_is_worth_noting": "Technical caveat or clarification"
|
||||
}
|
||||
},
|
||||
"ablation_techniques": {
|
||||
"incremental_tables": {
|
||||
"pattern": "Baseline → (a) → (b) → (c) with Δ标注",
|
||||
"source": "ViTDet Table 1"
|
||||
},
|
||||
"destructive_comparison": {
|
||||
"pattern": "Intentionally wrong values to prove necessity",
|
||||
"source": "MeanFlows Table 1b"
|
||||
},
|
||||
"narrative_structure": {
|
||||
"observation_then_explain": "Observe pattern → Provide explanation (literature/hypothesis/theory)"
|
||||
}
|
||||
},
|
||||
"theoretical_derivation": {
|
||||
"naming_identity": {
|
||||
"pattern": "Define → Derive → Name ('X Identity')",
|
||||
"source": "MeanFlows MeanFlow Identity"
|
||||
},
|
||||
"step_by_step": {
|
||||
"pattern": "Motivation → Derivation with 'Now we...' → Justification with 'where...'",
|
||||
"source": "MeanFlows Section 2"
|
||||
}
|
||||
},
|
||||
"comparison_techniques": {
|
||||
"principled_vs_heuristic": {
|
||||
"pattern": "At the core...does not depend on...In contrast, typically rely on...",
|
||||
"source": "MeanFlows"
|
||||
},
|
||||
"fair_comparison_declaration": {
|
||||
"pattern": "Admit complexity → Claim effort → Demonstrate fairness",
|
||||
"source": "ViTDet"
|
||||
},
|
||||
"multi_factor_analysis": {
|
||||
"pattern": "Factors identified → Trend behavior → Wall-clock time",
|
||||
"source": "ViTDet Results"
|
||||
}
|
||||
},
|
||||
"keyword_strategies": {
|
||||
"theory_paper": ["principled", "intrinsic", "well-defined", "naturally", "self-contained", "solely originated from"],
|
||||
"design_paper": ["minimal", "sufficient", "decouple", "independence", "surprisingly", "abandons"],
|
||||
"rethinking_paper": ["Conventional wisdom holds that", "not a necessity", "orthogonal to", "uncharted realm"]
|
||||
}
|
||||
},
|
||||
"papers_analyzed_list": [
|
||||
"Non-local Neural Networks",
|
||||
"SlowFast Networks",
|
||||
"Rethinking ImageNet Pre-training",
|
||||
"Faster R-CNN",
|
||||
"Delving Deep into Rectifiers (PReLU)",
|
||||
"Spatial Pyramid Pooling (SPP-net)",
|
||||
"Deconstructing Denoising Diffusion Models",
|
||||
"Autoregressive Image Generation without Vector Quantization (MAR)",
|
||||
"Mean Flows for One-step Generative Modeling",
|
||||
"Exploring Plain Vision Transformer Backbones for Object Detection (ViTDet)",
|
||||
"MoCo v2: Improved Baselines with Momentum Contrastive Learning"
|
||||
],
|
||||
"integration_summary": {
|
||||
"total_papers": 11,
|
||||
"knowledge_files": 5,
|
||||
"patterns_extracted": 25,
|
||||
"paper_types_identified": [
|
||||
"Theory-driven (MeanFlows)",
|
||||
"Design simplification (ViTDet)",
|
||||
"Rethinking (MAR)",
|
||||
"Deconstruction (DDM)",
|
||||
"Milestone (PReLU)",
|
||||
"Multi-task (SPP-net)",
|
||||
"Technical note (MoCo v2)"
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,37 @@
|
||||
# Paper-Miner Writing Memory
|
||||
|
||||
This is the **active installed writing memory** maintained by `paper-miner`.
|
||||
|
||||
It stores reusable academic writing knowledge mined from papers across venues and projects.
|
||||
|
||||
## Rules
|
||||
|
||||
- This is the **only maintained paper-miner writing memory**.
|
||||
- `paper-miner` writes here even when invoked inside a specific project.
|
||||
- Do **not** create project-specific paper-miner writing memory.
|
||||
- Do **not** split new mined knowledge across multiple maintained category files.
|
||||
- Keep source attribution explicit and avoid duplicate entries.
|
||||
|
||||
## Writing patterns mined
|
||||
|
||||
<!-- paper-miner adds reusable rhetorical patterns here -->
|
||||
|
||||
## Structure signals
|
||||
|
||||
<!-- paper-miner adds section-flow and organization signals here -->
|
||||
|
||||
## Reusable phrasing
|
||||
|
||||
<!-- paper-miner adds concise reusable phrasing and transition templates here -->
|
||||
|
||||
## Venue-specific signals
|
||||
|
||||
<!-- paper-miner adds venue-facing style and convention signals here -->
|
||||
|
||||
## How this helps our writing
|
||||
|
||||
<!-- paper-miner explains how mined signals can inform future writing decisions here -->
|
||||
|
||||
## Source index
|
||||
|
||||
<!-- one short source entry per analyzed paper -->
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,429 @@
|
||||
# Review Response and Rebuttal Strategies
|
||||
|
||||
This file contains effective strategies for responding to reviewer comments and addressing reviewer concerns, extracted from successful ML conference paper rebuttals.
|
||||
|
||||
---
|
||||
|
||||
## General Rebuttal Principles
|
||||
|
||||
### Core Philosophy
|
||||
**Source:** Analysis of successful NeurIPS/ICML rebuttals
|
||||
|
||||
**Key Principles:**
|
||||
1. **Respectful tone**: Thank reviewers for their time
|
||||
2. **Direct addressing**: Respond point-by-point to each concern
|
||||
3. **Evidence-based**: Support claims with data, experiments, or citations
|
||||
4. **Concise communication**: Be clear but brief
|
||||
5. **No over-committing**: Only promise what can be done
|
||||
|
||||
### Response Structure
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Reviewer [Number]
|
||||
|
||||
Thank you for this insightful comment. We [address the concern].
|
||||
|
||||
[Specific response to concern].
|
||||
|
||||
[Additional evidence/experiments if needed].
|
||||
|
||||
We have revised the manuscript to clarify this point (see changes marked in blue).
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Addressing Specific Concerns
|
||||
|
||||
### Concern: Clarity Issues
|
||||
|
||||
**Strategy:**
|
||||
- Acknowledge the confusion
|
||||
- Clarify with revised text
|
||||
- Add examples if helpful
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Clarity Concern
|
||||
|
||||
We apologize for the confusion. The original text was:
|
||||
|
||||
[Original unclear text]
|
||||
|
||||
We have revised this to:
|
||||
"Revised text with clearer explanation"
|
||||
|
||||
We also added an example (Figure X) to illustrate this concept.
|
||||
```
|
||||
|
||||
**Real Example:**
|
||||
- **Concern:** "The algorithm description is unclear."
|
||||
- **Response:** "We've rewritten Algorithm 1 with more detailed steps and added pseudocode. We also included a concrete example in Appendix B to illustrate the algorithm's execution."
|
||||
|
||||
### Concern: Missing Experiments
|
||||
|
||||
**Strategy:**
|
||||
- Assess whether experiment is feasible
|
||||
- If yes: add experiment and report results
|
||||
- If not: explain why experiment is not essential
|
||||
- Offer alternative evidence if possible
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Missing Experiment Request
|
||||
|
||||
We agree that [experiment] would strengthen the evaluation. We have:
|
||||
[Option 1: Added experiment and results]
|
||||
OR
|
||||
[Option 2: Explained why not essential with alternative evidence]
|
||||
|
||||
We believe this addresses the concern while maintaining focus on our core contribution.
|
||||
```
|
||||
|
||||
**Real Example:**
|
||||
- **Concern:** "Add comparison with Method X on dataset Y."
|
||||
- **Response:** "We've added results on dataset Y (Table 3). Our method outperforms Method X by 5%. We also include ablation showing our improvement comes from [feature], not just better optimization."
|
||||
|
||||
### Concern: Statistical Significance
|
||||
|
||||
**Strategy:**
|
||||
- Add statistical tests if appropriate
|
||||
- Report confidence intervals
|
||||
- Discuss practical significance vs statistical significance
|
||||
- Note sample size limitations
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Statistical Significance
|
||||
|
||||
We agree statistical testing is important. We have:
|
||||
- Added paired t-test results showing significance (p<0.01)
|
||||
- Included 95% confidence intervals in Figure 3
|
||||
- Reported standard deviations across 5 runs
|
||||
- Noted that while some differences are not statistically significant due to sample size, they are practically meaningful for [application]
|
||||
|
||||
We have updated Section 4.2 with these statistical details.
|
||||
```
|
||||
|
||||
### Concern: Insufficient Baselines
|
||||
|
||||
**Strategy:**
|
||||
- Add missing baselines if available
|
||||
- Explain why certain baselines are inappropriate
|
||||
- Cite reasons for exclusions with references
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Baseline Concern
|
||||
|
||||
We have added comparisons with:
|
||||
- [Method A]: Added in Table 2
|
||||
- [Method B]: Excluded because [reason with citation]
|
||||
|
||||
For Method B, while it seems related, it [specific reason why not comparable], making direct comparison inappropriate.
|
||||
```
|
||||
|
||||
### Concern: Writing Quality
|
||||
|
||||
**Strategy:**
|
||||
- Revise problematic text
|
||||
- Fix grammatical issues
|
||||
- Improve flow and clarity
|
||||
- Add signposting
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Writing Concern
|
||||
|
||||
We've revised the writing to address your concerns:
|
||||
- Restructured Section 3 for better flow
|
||||
- Fixed typos and grammar
|
||||
- Added transition sentences between paragraphs
|
||||
- Clarified technical terminology
|
||||
|
||||
The revised manuscript has been proofread and edited for clarity.
|
||||
```
|
||||
|
||||
### Concern: Overclaiming
|
||||
|
||||
**Strategy:**
|
||||
- Tone down absolute statements
|
||||
- Add qualifications where appropriate
|
||||
- Acknowledge limitations more explicitly
|
||||
- Reframe claims to match evidence
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Overclaiming Concern
|
||||
|
||||
We accept that our original claim was too strong. We have revised the text:
|
||||
|
||||
Original: "Our method achieves state-of-the-art on all tasks."
|
||||
Revised: "Our method achieves state-of-the-art on [specific tasks] and competitive performance on [other tasks]."
|
||||
|
||||
We also added a Limitations section acknowledging that our method may not generalize to [condition].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tone and Phrasing Patterns
|
||||
|
||||
### Opening Statements
|
||||
|
||||
**Thanking:**
|
||||
- "Thank you for this insightful comment."
|
||||
- "We appreciate the reviewer's suggestion to..."
|
||||
- "We thank the reviewer for pointing this out."
|
||||
|
||||
**Acknowledging Valid Points:**
|
||||
- "The reviewer is right that..."
|
||||
- "We agree this is a limitation."
|
||||
- "This is an excellent suggestion."
|
||||
|
||||
### Addressing Disagreements
|
||||
|
||||
**Respectful Disagreement:**
|
||||
- "We respectfully disagree with this assessment based on..."
|
||||
- "While we understand the concern, our results suggest..."
|
||||
- "We believe our approach is justified because..."
|
||||
|
||||
**Providing Evidence:**
|
||||
- "Our experimental results (Table 3) show..."
|
||||
- "As shown in Figure 4, the difference is..."
|
||||
- "This is supported by prior work [Citation]."
|
||||
|
||||
### Making Commitments
|
||||
|
||||
**Full Commitments:**
|
||||
- "We will add this experiment in the revised version."
|
||||
- "We have added additional ablation studies in Section 5."
|
||||
|
||||
**Partial Commitments:**
|
||||
- "We have added clarification in the appendix due to space constraints."
|
||||
- "We've expanded discussion of this point in the revision."
|
||||
|
||||
**Declining Requests:**
|
||||
- "Unfortunately, due to [constraint], we cannot add this experiment."
|
||||
- "This would require substantial additional resources beyond our current scope."
|
||||
- "We believe this is beyond the scope of the current paper but note it as future work."
|
||||
|
||||
---
|
||||
|
||||
## Common Rebuttal Strategies
|
||||
|
||||
### Strategy: Organized Response
|
||||
|
||||
**Structure:**
|
||||
```markdown
|
||||
# Summary of Changes
|
||||
|
||||
We thank the reviewers for their constructive feedback. In this response, we:
|
||||
- [Major change 1]
|
||||
- [Major change 2]
|
||||
- [Improvement 3]
|
||||
|
||||
We believe these changes have significantly strengthened the paper.
|
||||
|
||||
# Response to Reviewer 1
|
||||
|
||||
[Point-by-point responses]
|
||||
|
||||
# Response to Reviewer 2
|
||||
|
||||
[Point-by-point responses]
|
||||
```
|
||||
|
||||
### Strategy: Evidence-Based Arguments
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Response to Technical Concern
|
||||
|
||||
Our approach is valid because:
|
||||
1. [Reason 1 with reference/evidence]
|
||||
2. [Reason 2 with data/figure]
|
||||
3. [Reason 3 with theoretical justification]
|
||||
|
||||
This is supported by [Citation], which demonstrates that [fact].
|
||||
```
|
||||
|
||||
### Strategy: Highlighting Improvements
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# Major Revisions
|
||||
|
||||
1. **New Experiments**: Added comparison with [method] on [dataset]
|
||||
2. **New Analysis**: Included ablation study in Table 4
|
||||
3. **Clarified Writing**: Rewrote Section 3 for clarity
|
||||
4. **Added Limitations**: New section 5.2 acknowledging constraints
|
||||
|
||||
These additions strengthen our core claims about [contribution].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Venue-Specific Considerations
|
||||
|
||||
### NeurIPS
|
||||
|
||||
**Emphasis:**
|
||||
- Novelty and conceptual contribution
|
||||
- Broader impact (lay summary)
|
||||
- Reproducibility checklist
|
||||
|
||||
**Rebuttal Focus:**
|
||||
- How work advances understanding
|
||||
- Significance of contribution
|
||||
- Ethical considerations
|
||||
|
||||
### ICML
|
||||
|
||||
**Emphasis:**
|
||||
- Methodological rigor
|
||||
- Theoretical contributions
|
||||
- Broader impact statement
|
||||
|
||||
**Rebuttal Focus:**
|
||||
- Soundness of methods
|
||||
- Theoretical guarantees
|
||||
- Practical implications
|
||||
|
||||
### ICLR
|
||||
|
||||
**Emphasis:**
|
||||
- Experimental thoroughness
|
||||
- Limitations acknowledgment
|
||||
- LLM usage disclosure
|
||||
|
||||
**Rebuttal Focus:**
|
||||
- Comprehensive evaluation
|
||||
- Honest limitation discussion
|
||||
- Transparency about methods
|
||||
|
||||
### ACL
|
||||
|
||||
**Emphasis:**
|
||||
- Linguistic appropriateness
|
||||
- Ethical considerations
|
||||
- Clear limitations
|
||||
|
||||
**Rebuttal Focus:**
|
||||
- Language quality and appropriateness
|
||||
- Data provenance and ethics
|
||||
- Practical utility
|
||||
|
||||
---
|
||||
|
||||
## Tips for Successful Rebuttals
|
||||
|
||||
### Before Writing
|
||||
|
||||
1. **Understand the concerns**: Read carefully, identify key issues
|
||||
2. **Prioritize**: Address major concerns first
|
||||
3. **Be realistic**: Only promise what can deliver
|
||||
4. **Gather evidence**: Collect data, results, citations
|
||||
5. **Coordinate**: Discuss with co-authors if applicable
|
||||
|
||||
### While Writing
|
||||
|
||||
1. **Be specific**: Reference exact sections, figures, tables
|
||||
2. **Be concise**: Keep responses focused and brief
|
||||
3. **Be respectful**: Thank reviewers, acknowledge good points
|
||||
4. **Be confident**: Defend your work appropriately
|
||||
5. **Be honest**: Acknowledge limitations, don't overpromise
|
||||
|
||||
### Common Mistakes to Avoid
|
||||
|
||||
- **Defensive tone**: Don't argue excessively
|
||||
- **Vague responses**: Be specific about changes
|
||||
- **Ignoring concerns**: Address every point
|
||||
- **Over-promising**: Only commit to feasible additions
|
||||
- **Disorganized:**
|
||||
- **Poor formatting:** Use clear sections and structure
|
||||
- **Rude language:** Maintain professional tone
|
||||
|
||||
---
|
||||
|
||||
## Rebuttal Examples
|
||||
|
||||
### Example 1: Clarity Concern
|
||||
|
||||
**Reviewer:** "The method description in Section 3 is unclear and hard to follow."
|
||||
|
||||
**Response:**
|
||||
```markdown
|
||||
We apologize for the confusion. We have rewritten Section 3.2 to clarify our algorithm:
|
||||
|
||||
**Original:** "We process the data using our method and get results."
|
||||
|
||||
**Revised:** "Our method consists of three stages: (1) We first normalize the input
|
||||
features using [technique]. (2) We then apply our core algorithm, which iteratively [process].
|
||||
(3) Finally, we post-process the outputs using [method]."
|
||||
|
||||
We also added Algorithm 1 with detailed steps and included a concrete example in
|
||||
Appendix A. We believe this revision makes the method reproducible and clear.
|
||||
```
|
||||
|
||||
### Example 2: Missing Baseline
|
||||
|
||||
**Reviewer:** "You should compare with Method X (Smith et al., 2022)."
|
||||
|
||||
**Response:**
|
||||
```markdown
|
||||
Thank you for this suggestion. We have added comparisons with Method X in our
|
||||
revised manuscript:
|
||||
|
||||
**Results in Table 3:** Our method achieves 92% accuracy compared to Method X's
|
||||
85% on dataset Y. This 7% improvement demonstrates the value of our [key innovation].
|
||||
|
||||
**Ablation Study:** We show in Table 4 that our improvement comes specifically from
|
||||
[feature], not just better optimization.
|
||||
|
||||
We chose not to include Method Z because [reason with citation].
|
||||
```
|
||||
|
||||
### Example 3: Overclaiming
|
||||
|
||||
**Reviewer:** "The abstract claims 'state-of-the-art' too broadly."
|
||||
|
||||
**Response:**
|
||||
```markdown
|
||||
We accept this critique. Our original claim was too broad. We have revised the
|
||||
abstract:
|
||||
|
||||
**Original:** "Our method achieves state-of-the-art performance across all tasks."
|
||||
|
||||
**Revised:** "Our method achieves state-of-the-art on [specific tasks A and B] (Table 1)
|
||||
and competitive performance on [other tasks C and D] (Table 2)."
|
||||
|
||||
We also added a Limitations section (Section 5) noting that performance may vary
|
||||
across domains and tasks.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Final Checklist
|
||||
|
||||
Before submitting rebuttal:
|
||||
|
||||
- [ ] All reviewer concerns addressed
|
||||
- [ ] Responses are clear and specific
|
||||
- [ ] Tone is respectful and professional
|
||||
- [ ] Changes are marked in manuscript
|
||||
- [ ] Evidence provided for claims
|
||||
- [ ] Feasible commitments made
|
||||
- [ ] Co-authors agree with responses
|
||||
- [ ] Proofread for errors
|
||||
- [ ] Check formatting requirements
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Learn from successful rebuttals**: Read well-received papers' reviewer exchanges
|
||||
- **Practice humility**: Acknowledge mistakes, show willingness to improve
|
||||
- **Focus on core contribution**: Defend your main contribution without overclaiming
|
||||
- **Keep it concise**: Reviewers are busy; be respectful of their time
|
||||
|
||||
**Updates:** This file is periodically updated with new strategies and examples from successful rebuttals.
|
||||
@@ -0,0 +1,349 @@
|
||||
# Paper Structure Patterns
|
||||
|
||||
This file contains actionable patterns for organizing ML conference papers, extracted from successful publications.
|
||||
|
||||
---
|
||||
|
||||
## Introduction Patterns
|
||||
|
||||
### Pattern: Contribution Statement Structure
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
**Context:** Introducing the main contribution
|
||||
|
||||
**Pattern:**
|
||||
1. Start with broader context or problem
|
||||
2. Narrow down to specific limitation
|
||||
3. Present your approach as solution
|
||||
4. State clear contribution upfront
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Context/Problem]: Existing approaches struggle with [limitation] due to [reason].
|
||||
|
||||
[Our Approach]: We propose [method name], which [key innovation].
|
||||
|
||||
[Contribution]: This achieves [result] and enables [capability].
|
||||
```
|
||||
|
||||
**Application:** Use this pattern when introducing your main contribution in the first or second paragraph of the introduction.
|
||||
|
||||
---
|
||||
|
||||
### Pattern: Bulleted Contribution List
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
**Context:** Summarizing contributions for clarity
|
||||
|
||||
**Pattern:**
|
||||
- Place near end of Introduction (after Related Work)
|
||||
- Use 2-4 bullets
|
||||
- Each bullet: 1-2 lines max (in two-column format)
|
||||
- Start with strong verbs ("We propose", "We demonstrate", "We show")
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
Our contributions are three-fold:
|
||||
- We propose [method], which achieves [result].
|
||||
- We demonstrate that [technique] improves [metric].
|
||||
- We show that [approach] enables [new capability].
|
||||
```
|
||||
|
||||
**Application:** Use this when you need to clearly delineate multiple contributions for reviewers.
|
||||
|
||||
---
|
||||
|
||||
### Pattern: Related Work Organization
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
**Context:** Structuring literature review
|
||||
|
||||
**Pattern:**
|
||||
- Organize methodologically, not chronologically
|
||||
- Group papers by approach/assumption
|
||||
- Contrast your approach with each group
|
||||
- Use "One line of work uses X whereas we use Y because..."
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Approach Category]: Several approaches use [assumption A] [refs].
|
||||
[Contrast]: We adopt [assumption B] because it allows [benefit].
|
||||
|
||||
[Alternative Category]: Other methods focus on [aspect C] [refs].
|
||||
[Positioning]: We build on this by adding [our innovation].
|
||||
```
|
||||
|
||||
**Application:** Use this to position your work relative to existing literature without paper-by-paper reviews.
|
||||
|
||||
---
|
||||
|
||||
## Methods Section Patterns
|
||||
|
||||
### Pattern: Algorithm Presentation
|
||||
**Source:** "Adam: A Method for Stochastic Optimization", ICLR (2015)
|
||||
**Context:** Describing algorithms clearly
|
||||
|
||||
**Pattern:**
|
||||
1. High-level overview first
|
||||
2. Mathematical formulation
|
||||
3. Algorithm pseudocode (if complex)
|
||||
4. Implementation details
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Overview]: We formulate [problem] as optimization. Let [objective] be our goal.
|
||||
|
||||
[Method]: Our approach optimizes [objective] using [technique].
|
||||
Specifically, we [algorithm description].
|
||||
|
||||
[Algorithm]: The full procedure is shown in Algorithm 1.
|
||||
|
||||
[Implementation]: In practice, we [practical details].
|
||||
```
|
||||
|
||||
**Application:** Use this when presenting novel algorithms or optimization methods.
|
||||
|
||||
---
|
||||
|
||||
### Pattern: Component Breakdown
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
**Context:** Describing multi-component systems
|
||||
|
||||
**Pattern:**
|
||||
- Present model architecture first
|
||||
- Break down into key components
|
||||
- Explain each component's role
|
||||
- Show how components interact
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Architecture]: Our model consists of [N components]: [list].
|
||||
|
||||
[Component 1]: The [component] module [function].
|
||||
[Component 2]: The [component] layer [operation].
|
||||
|
||||
[Integration]: These components are stacked sequentially, with [connection pattern].
|
||||
```
|
||||
|
||||
**Application:** Use this when describing complex architectures with multiple interacting parts.
|
||||
|
||||
---
|
||||
|
||||
## Results Section Patterns
|
||||
|
||||
### Pattern: Quantitative Opening
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
**Context:** Presenting main findings
|
||||
|
||||
**Pattern:**
|
||||
- Start with strongest quantitative result
|
||||
- Use exact numbers and metrics
|
||||
- Include comparison to baselines
|
||||
- State statistical significance
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Main Result]: Our method achieves [score] on [dataset], improving
|
||||
over the previous best of [baseline] by [margin] (p<0.001).
|
||||
|
||||
[Comparison]: Compared to baselines:
|
||||
- [Method A]: [score]
|
||||
- [Method B]: [score]
|
||||
- Ours: [score]
|
||||
|
||||
[Significance]: Results are averaged over N runs; standard deviations shown in parentheses.
|
||||
```
|
||||
|
||||
**Application:** Use this to open your Results section with your strongest finding.
|
||||
|
||||
---
|
||||
|
||||
### Pattern: Table Integration
|
||||
**Source:** "Attention Is All All You Need", NeurIPS (2017)
|
||||
**Context:** Presenting results in tables
|
||||
|
||||
**Pattern:**
|
||||
- Bold best results in each column
|
||||
- Include direction indicators (↑↓)
|
||||
- Provide table caption that stands alone
|
||||
- Reference table in text before presenting
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
Table 1 shows our method's performance. Our model (bold) outperforms
|
||||
all baselines across datasets.
|
||||
|
||||
[Table content]
|
||||
|
||||
As shown in Table 1, we achieve state-of-the-art on [datasets].
|
||||
```
|
||||
|
||||
**Application:** Use this when presenting comparative results in table format.
|
||||
|
||||
---
|
||||
|
||||
## Discussion Section Patterns
|
||||
|
||||
### Pattern: Limitations First
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
**Context:** Acknowledging limitations proactively
|
||||
|
||||
**Pattern:**
|
||||
- State limitations clearly in first paragraph
|
||||
- Explain why limitations don't undermine core claims
|
||||
- Distinguish between limitations and future work
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Limitation Statement]: Our approach has [limitation]. Specifically,
|
||||
[constraint].
|
||||
|
||||
[Mitigation]: Despite this, our core findings about [main contribution] remain
|
||||
valid because [reason].
|
||||
|
||||
[Future Work]: Addressing this limitation is an important direction for
|
||||
future research.
|
||||
```
|
||||
|
||||
**Application:** Use this to acknowledge limitations honestly while maintaining paper strength.
|
||||
|
||||
---
|
||||
|
||||
### Pattern: Broader Impact Framing
|
||||
**Source:** "Language Models are Few-Shot Learners", GPT-3 Paper (2020)
|
||||
**Context:** Discussing wider implications
|
||||
|
||||
**Pattern:**
|
||||
- Start with direct implications
|
||||
- Expand to related domains
|
||||
- Consider societal impact (if appropriate)
|
||||
- End with forward-looking statement
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Direct Impact]: Our findings suggest that [implication for domain].
|
||||
|
||||
[Broader Implications]: Beyond [specific domain], this approach could
|
||||
enable [application in other areas].
|
||||
|
||||
[Future Outlook]: As [trend] continues, methods like ours will become
|
||||
increasingly important for [reason].
|
||||
```
|
||||
|
||||
**Application:** Use this when writing the final paragraphs of Discussion or Conclusion.
|
||||
|
||||
---
|
||||
|
||||
## Transition Patterns
|
||||
|
||||
### Pattern: Section Transitions
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
**Context:** Moving between sections
|
||||
|
||||
**Pattern:**
|
||||
- Introduction → Methods: "We now describe our approach."
|
||||
- Methods → Results: "We evaluate our method on [tasks]."
|
||||
- Results → Discussion: "These results suggest that [insight]."
|
||||
|
||||
**Example Template:**
|
||||
```markdown
|
||||
[Transition to Methods]: Having established [motivation], we present
|
||||
our method.
|
||||
|
||||
[Transition to Results]: To validate our approach, we conduct experiments
|
||||
on [datasets].
|
||||
|
||||
[Transition to Discussion]: The experimental results reveal several insights
|
||||
about [phenomenon], which we discuss next.
|
||||
```
|
||||
|
||||
**Application:** Use these to create smooth transitions between major sections.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Consistency**: Maintain consistent terminology throughout the paper
|
||||
- **Flow**: Each section should logically lead to the next
|
||||
- **Clarity**: Make structure explicit with signposting
|
||||
- **Audience**: Write for tired reviewers - make their job easy
|
||||
|
||||
|
||||
|
||||
## 何凯明（Kaiming He）的论文结构模式
|
||||
|
||||
> 来源: 分析了何凯明的 19 篇代表性论文
|
||||
> 添加时间: {datetime.now().strftime('%Y-%m-%d')}
|
||||
|
||||
### 摘要结构模式
|
||||
|
||||
何凯明在摘要中常用的开场模式：
|
||||
|
||||
**模式 1: 直接陈述贡献**
|
||||
```
|
||||
We introduce [method name], a [key feature] framework for [task].
|
||||
We show that [method] achieves [result] on [dataset].
|
||||
```
|
||||
|
||||
**模式 2: 问题-解决方案**
|
||||
```
|
||||
[Problem] is difficult for [task]. We present [solution]
|
||||
that addresses this by [key mechanism].
|
||||
```
|
||||
|
||||
**示例** (来自 ResNet):
|
||||
```
|
||||
Deeper neural networks are more difficult to train. We present a
|
||||
residual learning framework to ease the training of networks that
|
||||
are substantially deeper than those used previously.
|
||||
```
|
||||
|
||||
### 引言结构模式
|
||||
|
||||
**三段式引言:**
|
||||
1. **问题陈述** (2-3段) - 描述挑战和现有方法
|
||||
2. **方法概述** (1-2段) - 简洁介绍解决方案
|
||||
3. **主要贡献** (1段) - 列表形式，每条 1-2 行
|
||||
|
||||
**贡献列表模式:**
|
||||
```markdown
|
||||
- 我们提出了 [方法]，解决了 [问题]
|
||||
- 我们展示了 [方法] 在 [数据集] 上的 [性能提升]
|
||||
- 我们证明了 [原理] 是有效的
|
||||
```
|
||||
|
||||
### 方法部分结构
|
||||
|
||||
何凯明的方法部分通常包含：
|
||||
|
||||
1. **符号定义** - 清晰定义所有变量和符号
|
||||
2. **问题形式化** - 数学公式表达
|
||||
3. **方法描述** - 逐步算法解释
|
||||
4. **实现细节** - 网络架构、训练设置
|
||||
|
||||
**常用句式:**
|
||||
- "Let us consider [变量] as [定义]"
|
||||
- "Formally, we define [公式]"
|
||||
- "We hypothesize that [假设]"
|
||||
- "To the extreme, [极端情况]"
|
||||
|
||||
### 实验部分结构
|
||||
|
||||
1. **实验设置** - 数据集、评价指标、实现细节
|
||||
2. **主要结果** - 核心性能对比
|
||||
3. **消融实验** - 组件分析
|
||||
4. **可视化分析** - 图表展示
|
||||
|
||||
**结果描述模式:**
|
||||
- "Table X shows that [结果]"
|
||||
- "Fig. Y illustrates that [观察]"
|
||||
- "Our method achieves [指标] on [任务]"
|
||||
- "This represents a [X]% improvement over baseline"
|
||||
|
||||
### 相关工作部分组织
|
||||
|
||||
何凯明倾向于**主题式组织**而非时间顺序：
|
||||
|
||||
**好的组织方式:**
|
||||
- "One line of work uses [方法A] [引用], whereas we use [方法B]"
|
||||
- "[方法A] [引用] assumes [假设], but we show [反驳]"
|
||||
|
||||
**避免:**
|
||||
- "X et al. introduced [方法]. Y et al. improved [方法]"
|
||||
@@ -0,0 +1,326 @@
|
||||
# Submission Guides and Venue Requirements
|
||||
|
||||
This file contains venue-specific submission requirements, formatting guidelines, and checklist items extracted from ML conference and journal publications.
|
||||
|
||||
---
|
||||
|
||||
## NeurIPS Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** NeurIPS 2025 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 9 pages (excluding references)
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
- Appendices: Allowed but reviewers not required to read
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: 150-250 words
|
||||
- Introduction: Must clearly state contribution
|
||||
- Methods: Sufficient for reproduction
|
||||
- Experiments: Comprehensive evaluation
|
||||
- Discussion: Interpret results and limitations
|
||||
- References: Complete citations
|
||||
- **Checklist**: Mandatory submission checklist (16 items)
|
||||
- **Lay Summary**: Required for accepted papers (1 page, non-technical)
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- LaTeX template required
|
||||
- 9pt font, two-column format
|
||||
- Margins: 1 inch on all sides
|
||||
|
||||
**Submission Checklist Items:**
|
||||
1. Do the main claims of the paper match the checklist?
|
||||
2. Have you checked the checklist for missing items?
|
||||
3. Is the paper anonymized?
|
||||
4. Are all figures/tables clear and readable?
|
||||
5. Have you included code and data availability statements?
|
||||
6. Are all equations properly formatted?
|
||||
7. Is the abstract within word limit?
|
||||
8. Are all citations complete and correct?
|
||||
9. Have you addressed potential ethical concerns?
|
||||
10. Are experimental settings clearly described?
|
||||
11. Is statistical significance properly reported?
|
||||
12. Have you included limitations?
|
||||
13. Is the broader impact discussed (if required)?
|
||||
14. Are all figures referenced in text?
|
||||
15. Is the supplementary material well-organized?
|
||||
16. Have you proofread for typos and grammar?
|
||||
|
||||
---
|
||||
|
||||
## ICML Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** ICML 2026 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 8 pages
|
||||
- Camera-ready: +1 page (9 total)
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: Clear summary of contribution
|
||||
- Introduction: Problem and contribution
|
||||
- Methods: Complete description
|
||||
- Experiments: Thorough evaluation
|
||||
- **Broader Impact Statement**: Required (after conclusion)
|
||||
- References: Complete citations
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- LaTeX template required
|
||||
- Two-column format
|
||||
- Margins as per template
|
||||
|
||||
**Broader Impact Statement:**
|
||||
- Discuss positive and negative societal impacts
|
||||
- Consider biases, fairness, environmental impact
|
||||
- 1 page maximum
|
||||
- Required for all submissions
|
||||
|
||||
---
|
||||
|
||||
## ICLR Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** ICLR 2026 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 9 pages
|
||||
- Camera-ready: +1 page (10 total)
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: Summary of contribution
|
||||
- Introduction: Clear problem statement
|
||||
- Methods: Reproducible description
|
||||
- Experiments: Comprehensive evaluation
|
||||
- **Limitations Section**: MANDATORY
|
||||
- **LLM Disclosure**: Required if using LLMs
|
||||
- References: Complete citations
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- LaTeX template required
|
||||
- Two-column format
|
||||
|
||||
**LLM Disclosure Requirements:**
|
||||
- Describe LLM use in the paper
|
||||
- Include model details (architecture, training data, compute)
|
||||
- Acknowledge LLM limitations
|
||||
- Note any automated text generation
|
||||
|
||||
---
|
||||
|
||||
## ACL Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** ACL 2025 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 8 pages (long papers)
|
||||
- Short papers: 4 pages
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: 150-200 words
|
||||
- Introduction: Background and contribution
|
||||
- Methods: Technical description
|
||||
- Experiments: Evaluation
|
||||
- **Limitations Section**: MANDATORY
|
||||
- **Ethics Statement**: Required if applicable
|
||||
- References: Complete citations
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- LaTeX template required (ACL style files)
|
||||
- Two-column format
|
||||
|
||||
**Ethics Considerations:**
|
||||
- Human subjects research: IRB approval required
|
||||
- Data privacy: Anonymization and consent
|
||||
- Environmental impact: Compute resource usage
|
||||
|
||||
---
|
||||
|
||||
## AAAI Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** AAAI 2026 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 7 pages
|
||||
- Camera-ready: +1 page (8 total)
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: 150-250 words
|
||||
- Introduction: Problem and contribution
|
||||
- Methods: Technical description
|
||||
- Experiments: Evaluation
|
||||
- References: Complete citations
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- **Strict style file adherence**: Must use official template
|
||||
- Two-column format
|
||||
- No modifications to style files
|
||||
|
||||
**Strict Requirements:**
|
||||
- Follow AAAI template exactly
|
||||
- No custom formatting beyond template
|
||||
- Font sizes and margins as specified
|
||||
- Page limits strictly enforced
|
||||
|
||||
---
|
||||
|
||||
## COLM Requirements
|
||||
|
||||
### Format Requirements
|
||||
**Source:** COLM 2025 Conference Guidelines
|
||||
|
||||
**Page Limits:**
|
||||
- Main paper: 9 pages
|
||||
- Camera-ready: +1 page (10 total)
|
||||
- References: Unlimited (don't count toward page limit)
|
||||
|
||||
**Required Sections:**
|
||||
- Abstract: Summary of contribution
|
||||
- Introduction: Problem and contribution
|
||||
- Methods: Technical description
|
||||
- Experiments: Evaluation
|
||||
- **Focus**: Language models specifically
|
||||
- References: Complete citations
|
||||
|
||||
**Formatting:**
|
||||
- Double-blind review (anonymize submissions)
|
||||
- LaTeX template required
|
||||
- Two-column format
|
||||
|
||||
**Language Model Focus:**
|
||||
- Papers should address language model challenges
|
||||
- Method contributions applicable to LM community
|
||||
- Experimental setup relevant to language tasks
|
||||
|
||||
---
|
||||
|
||||
## Common Submission Requirements
|
||||
|
||||
### Double-Blind Review
|
||||
**Applies to:** NeurIPS, ICML, ICLR, ACL, AAAI, COLM
|
||||
|
||||
**Requirements:**
|
||||
- Remove author names and affiliations
|
||||
- Anonymize citations to own work (use [Anonymous, 2024])
|
||||
- Remove acknowledgments that reveal identity
|
||||
- Avoid distinctive phrases that identify authors
|
||||
- Supplementary materials must also be anonymized
|
||||
|
||||
**Common Mistakes:**
|
||||
- Forgetting to anonymize GitHub links
|
||||
- Including author names in file paths
|
||||
- Thanking specific colleagues in acknowledgments
|
||||
- Citing own work with author names
|
||||
|
||||
### Code and Data Availability
|
||||
|
||||
**Increasingly Required:**
|
||||
|
||||
**NeurIPS:** Encourages code/data availability statements
|
||||
**ICML:** Encourages reproducibility
|
||||
**ICLR:** Recommends code sharing
|
||||
|
||||
**Best Practices:**
|
||||
- Include code repository link (anonymized if under review)
|
||||
- Provide data access instructions
|
||||
- Describe hyperparameters and settings
|
||||
- Note any proprietary constraints
|
||||
|
||||
### Supplementary Materials
|
||||
|
||||
**General Guidelines:**
|
||||
- Appendices allowed but not required reading
|
||||
- Use for additional experiments, proofs, tables
|
||||
- Keep main paper self-contained
|
||||
- Reference supplementary in main text
|
||||
|
||||
**Formatting:**
|
||||
- Same style as main paper
|
||||
- Clear section numbering (S1, S2, etc.)
|
||||
- Include in submission PDF or as separate file
|
||||
|
||||
---
|
||||
|
||||
## Citation Styles
|
||||
|
||||
### Common Styles in ML
|
||||
|
||||
**IEEE Style (Numbered):**
|
||||
```
|
||||
[1] J. Doe, "Paper title," Conference Name, Year.
|
||||
[2] A. Smith, "Another paper," Journal Name, vol. 10, pp. 1-15, 2020.
|
||||
```
|
||||
|
||||
**ACM Style (Numbered):**
|
||||
```
|
||||
[J. Doe and A. Smith, "Paper title," Conference Name, Year.
|
||||
[A. Smith and B. Jones, "Another paper," Journal Name, 2020.
|
||||
```
|
||||
|
||||
**Author-Year (APA-like):**
|
||||
```
|
||||
Doe (2020) J. Doe. Paper title. Conference Name.
|
||||
Smith (2019) A. Smith. Another paper. Journal Name.
|
||||
```
|
||||
|
||||
### Reference Management
|
||||
|
||||
**Best Practices:**
|
||||
- Use consistent style throughout
|
||||
- Include DOIs when available
|
||||
- Provide arXiv links for preprints
|
||||
- Check for broken links
|
||||
- Verify all citations before submission
|
||||
|
||||
---
|
||||
|
||||
## Checklists and Templates
|
||||
|
||||
### Pre-Submission Checklist
|
||||
|
||||
**Content:**
|
||||
- [ ] Novel contribution clearly stated
|
||||
- [ ] Related work comprehensive
|
||||
- [ ] Methods reproducible
|
||||
- [ ] Results support all claims
|
||||
- [ ] Limitations acknowledged
|
||||
- [ ] Broader impact addressed (if required)
|
||||
- [ ] Ethics compliance verified
|
||||
|
||||
**Formatting:**
|
||||
- [ ] Page limits respected
|
||||
- [ ] Style file followed exactly
|
||||
- [ ] References complete and consistent
|
||||
- [ ] Figures/tables clear and readable
|
||||
- [ ] Equations numbered and referenced
|
||||
- [ ] Supplementary material organized
|
||||
|
||||
**Anonymity:**
|
||||
- [ ] Author names removed
|
||||
- [ ] Acknowledgements anonymized
|
||||
- [ ] Self-citations anonymized
|
||||
- [ ] GitHub links anonymized
|
||||
- [ ] Identifying information removed
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Always verify**: Requirements change between years - always check current conference guidelines
|
||||
- **Plan ahead**: Some venues have strict formatting - start early
|
||||
- **Read examples**: Look at well-received papers from previous years
|
||||
- **Ask for help**: If unsure about a requirement, consult program chairs or experienced colleagues
|
||||
|
||||
**Updates:** This file is regularly updated as new conference requirements become available.
|
||||
@@ -0,0 +1,561 @@
|
||||
# Theory-Driven Papers: From First Principles
|
||||
|
||||
**Source**: Kaiming He et al., "Mean Flows for One-step Generative Modeling" (2025)
|
||||
|
||||
**Paper Type**: Theory-driven / First-principles paper
|
||||
|
||||
**Core Pattern**: Start from first principles → Derive theory → Build method → Demonstrate superiority
|
||||
|
||||
---
|
||||
|
||||
## 1. Abstract Structure: The "Principle Introduction" Framework
|
||||
|
||||
### Pattern: From Theory to Results
|
||||
|
||||
**Template**:
|
||||
```markdown
|
||||
Abstract:
|
||||
1. [Background] Established framework provides [foundation]
|
||||
2. [Problem] Recent research focuses on [challenge], but existing methods have [limitation]
|
||||
3. [Critique] Despite encouraging results, [specific problem with prior approaches]
|
||||
4. [Core Concept] We introduce [new concept], in contrast to [old concept]
|
||||
5. [Theory] Solely from definition, we derive [theoretical foundation]
|
||||
6. [Advantage] This provides [principled basis] vs [heuristic approaches]
|
||||
7. [Results] Achieves [strong result] - [relative improvement] over SOTA
|
||||
8. [Significance] Self-contained, [independence from external components]
|
||||
```
|
||||
|
||||
### MeanFlows Abstract Example (annotated):
|
||||
|
||||
```latex
|
||||
Flow Matching provides an intuitive and conceptually simple framework for
|
||||
constructing flow paths that transport one distribution to another.
|
||||
|
||||
Recent research has paid significant attention to few-step—and in
|
||||
particular, one-step, feedforward—generative models.
|
||||
|
||||
Despite encouraging results, the consistency constraint is imposed as a
|
||||
property of the network's behavior, while the properties of the underlying
|
||||
ground-truth field that should guide learning remain unknown.
|
||||
|
||||
The core idea is to introduce a new ground-truth field representing the
|
||||
average velocity, in contrast to the instantaneous velocity typically
|
||||
modeled in Flow Matching.
|
||||
|
||||
Solely originated from this definition, we derive a well-defined, intrinsic
|
||||
relation between the average and instantaneous velocities, which naturally
|
||||
serves as a principled basis for guiding network training.
|
||||
|
||||
Our method achieves an FID of 3.43 using 1-NFE generation, significantly
|
||||
outperforming previous state-of-the-art methods by a relative margin of 50%
|
||||
to 70%.
|
||||
|
||||
It is trained entirely from scratch, without any pre-training, distillation,
|
||||
or curriculum learning.
|
||||
```
|
||||
|
||||
### Key Techniques:
|
||||
|
||||
1. **"Provides an intuitive and conceptually simple framework"** - Light touch introduction
|
||||
2. **"Recent research has paid significant attention to..."** - Establish context
|
||||
3. **"Despite encouraging results..."** - The critique pattern (acknowledge then problem)
|
||||
4. **"The core idea is to introduce..."** - Clear concept statement
|
||||
5. **"in contrast to"** - Conceptual differentiation
|
||||
6. **"Solely originated from this definition"** - First-principles emphasis
|
||||
7. **"well-defined, intrinsic relation"** - Theory keywords
|
||||
8. **"naturally serves as a principled basis"** - Naturalness emphasis
|
||||
9. **Relative improvement (50-70%)** - More impactful than absolute numbers
|
||||
10. **Negative list** - What you DON'T need (pre-training, distillation, curriculum)
|
||||
|
||||
---
|
||||
|
||||
## 2. Introduction: The "Critique-First" Framework
|
||||
|
||||
### Pattern: Build Up → Identify Flaw → Propose Alternative
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Background] Established field with [characteristic]
|
||||
2. [Problem Shift] Research focus has moved to [new direction]
|
||||
3. [Specific Problem] Existing approaches address this by [method]
|
||||
4. [The Critique] Despite [acknowledgment], [fundamental problem]
|
||||
- "imposed as a property of [X]"
|
||||
- "[Y] remains unknown"
|
||||
5. [Consequences] Consequently, [practical problems]
|
||||
6. [Your Concept] We propose [alternative] with [differentiation]
|
||||
7. [Theory] From [first principles], we derive [result]
|
||||
8. [Advantage] This is [principled/natural/intrinsic] vs [heuristic/artificial]
|
||||
9. [Results] [Quantitative result] with [qualitative advantage]
|
||||
```
|
||||
|
||||
### MeanFlows Introduction Flow:
|
||||
|
||||
#### Background (Light Touch)
|
||||
```latex
|
||||
Flow Matching provides an intuitive and conceptually simple framework
|
||||
for constructing flow paths that transport one distribution to another.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- "intuitive and conceptually simple" - Modest, not revolutionary
|
||||
- Focus on what it IS, not how important it is
|
||||
|
||||
#### Problem Shift
|
||||
```latex
|
||||
Closely related to diffusion models, Flow Matching focuses on the velocity
|
||||
fields that guide model training.
|
||||
|
||||
Both Flow Matching and diffusion models perform iterative sampling during
|
||||
generation. Recent research has paid significant attention to few-step
|
||||
—and in particular, one-step, feedforward—generative models.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- "Closely related to" - Establish connection
|
||||
- "Recent research has paid significant attention to" - Research trend
|
||||
- "few-step—and in particular, one-step" - Progressive emphasis
|
||||
|
||||
#### The Critique (Key Pattern)
|
||||
```latex
|
||||
Consistency Models [46, 43, 15, 31] achieve few-step generation by enforcing
|
||||
a consistency constraint on the velocity field.
|
||||
|
||||
Despite encouraging results, the consistency constraint is imposed as a
|
||||
property of the network's behavior, while the properties of the underlying
|
||||
ground-truth field that should guide learning remain unknown.
|
||||
|
||||
Consequently, training can be unstable and requires a carefully designed
|
||||
'discretization curriculum' to progressively constrain the time domain.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"Despite encouraging results"** - Always acknowledge first
|
||||
- **"imposed as a property of the network's behavior"** - It's artificial
|
||||
- **"underlying ground-truth field...remain unknown"** - Missing theory
|
||||
- **"Consequently"** - Show practical consequences
|
||||
- **Specific problems**: "training can be unstable", "requires...curriculum"
|
||||
|
||||
#### Your Concept
|
||||
```latex
|
||||
The core idea is to introduce a new ground-truth field representing the
|
||||
average velocity, in contrast to the instantaneous velocity typically
|
||||
modeled in Flow Matching.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"The core idea is to introduce"** - Direct statement
|
||||
- **"in contrast to"** - Conceptual differentiation
|
||||
- **Old vs New**: "average velocity" vs "instantaneous velocity"
|
||||
|
||||
#### Theory First
|
||||
```latex
|
||||
Average velocity is defined as the ratio of displacement to a time interval,
|
||||
with displacement given by the time integral of the instantaneous velocity.
|
||||
|
||||
Solely originated from this definition, we derive a well-defined, intrinsic
|
||||
relation between the average and instantaneous velocities, which naturally
|
||||
serves as a principled basis for guiding network training.
|
||||
```
|
||||
|
||||
**Technique**:
|
||||
- **"Solely originated from this definition"** - Pure derivation
|
||||
- **"well-defined, intrinsic relation"** - Theory keywords
|
||||
- **"naturally serves as"** - Not forced
|
||||
- **"principled basis"** - Foundation
|
||||
|
||||
---
|
||||
|
||||
## 3. Methods Section: The "Named Identity" Pattern
|
||||
|
||||
### Pattern: Define → Derive → Name
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Concept Name] Define with formal notation
|
||||
2. [Motivation] Explain why we need this
|
||||
3. [Derivation] Step-by-step with justifications
|
||||
4. [Naming] Give it a memorable name
|
||||
5. [Comparison] Contrast with prior approaches
|
||||
```
|
||||
|
||||
### MeanFlows Example:
|
||||
|
||||
#### Step 1: Concept Naming
|
||||
```latex
|
||||
Average Velocity. We define average velocity as the displacement between
|
||||
two time steps t and r (obtained by integration) divided by the time interval.
|
||||
|
||||
Formally, the average velocity u is:
|
||||
|
||||
u(zt, r, t) ≜ 1/(t−r) ∫_r^t v(zτ, τ)dτ. (3)
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **Bold heading**: "Average Velocity." - Makes it memorable
|
||||
- **Text description first**: Explain before formula
|
||||
- **"Formally,"**: Signals math coming
|
||||
- **≜ symbol**: "defined as" (clearer than =)
|
||||
|
||||
#### Step 2: Derivation with Motivation
|
||||
```latex
|
||||
To have a formulation amenable to training, we rewrite Eq. (3) as:
|
||||
|
||||
(t−r)u(zt, r, t) = ∫_r^t v(zτ, τ)dτ. (4)
|
||||
|
||||
Now we differentiate both sides with respect to t, treating r as independent
|
||||
of t. This leads to:
|
||||
|
||||
d/dt(t−r)u = d/dt∫_r^t v(zτ, τ)dτ
|
||||
|
||||
⇒ u + (t−r)d/dt u = v(zt, t), (5)
|
||||
|
||||
where the manipulation of the left hand side employs the product rule and
|
||||
the right hand side uses the fundamental theorem of calculus.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"To have a formulation amenable to training"** - Explain why
|
||||
- **"Now we differentiate..."** - Guide reader
|
||||
- **Step-by-step**: Don't skip
|
||||
- **"where..."**: Explain each manipulation
|
||||
- **"⇒" symbol**: Clear direction
|
||||
|
||||
#### Step 3: Naming the Identity
|
||||
```latex
|
||||
Rearranging terms, we obtain the identity:
|
||||
|
||||
u(zt, r, t) = v(zt, t) − (t−r)d/dt u(zt, r, t) (6)
|
||||
|
||||
We refer to this equation as the "MeanFlow Identity", which describes the
|
||||
relation between v and u.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"Rearranging terms, we obtain..."** - What you did
|
||||
- **"We refer to this equation as the 'X Identity'"** - Brand it
|
||||
- **Explain**: "which describes..." - What it does
|
||||
|
||||
---
|
||||
|
||||
## 4. Comparison: Principled vs Heuristic
|
||||
|
||||
### Pattern: Emphasize Theoretical Independence
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Your Core] At the core of our method is [fundamental principle]
|
||||
2. [Independence] This [does not depend on / is independent of] [implementation]
|
||||
3. [Contrast] In contrast, prior works typically rely on [heuristic/artificial constraint]
|
||||
4. [Qualitative] [Natural/principled/intrinsic] vs [imposed/empirical/heuristic]
|
||||
```
|
||||
|
||||
### MeanFlows Example:
|
||||
|
||||
```latex
|
||||
At the core of our method is the functional relationship between two
|
||||
underlying fields v and u, which naturally leads to the MeanFlow Identity
|
||||
that u must satisfy (Eq. (6)).
|
||||
|
||||
This identity does not depend on the introduction of neural networks.
|
||||
|
||||
In contrast, prior works typically rely on extra consistency constraints,
|
||||
imposed on the behavior of the neural network.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"At the core of our method is..."** - What matters
|
||||
- **"naturally leads to"** - Not forced
|
||||
- **"does not depend on"** - Independence
|
||||
- **"In contrast"** - Clear pivot
|
||||
- **"imposed on"** - Theirs is artificial
|
||||
|
||||
### Specific Method Comparison
|
||||
|
||||
```latex
|
||||
Consistency Models [46, 43, 15, 31] are focused on paths anchored at the
|
||||
data side: in our notations, this corresponds to fixing r≡0 for any t.
|
||||
|
||||
As a result, Consistency Models are conditioned on a single time variable,
|
||||
unlike ours.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"focused on X"** - Their scope
|
||||
- **"in our notations, this corresponds to..."** - Precise mapping
|
||||
- **"As a result"** - Consequence
|
||||
- **"unlike ours"** - One-word differentiation
|
||||
|
||||
---
|
||||
|
||||
## 5. Results: Significant Improvements with Context
|
||||
|
||||
### Pattern: Relative Improvement + Independence
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
1. [Absolute] We achieve [metric] on [task]
|
||||
2. [Relative] This represents [X-Y%] relative improvement over [comparison]
|
||||
3. [Context] Our method is [self-contained / independent]
|
||||
4. [Negative List] without [list of things you don't need]
|
||||
```
|
||||
|
||||
### MeanFlows Example:
|
||||
|
||||
```latex
|
||||
Our method achieves an FID of 3.43 using 1-NFE generation.
|
||||
|
||||
This result significantly outperforms previous state-of-the-art methods in
|
||||
its class by a relative margin of 50% to 70% (Fig. 1).
|
||||
|
||||
In addition, our method stands as a self-contained generative model: it is
|
||||
trained entirely from scratch, without any pre-training, distillation, or
|
||||
curriculum learning.
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **Absolute first**: "FID of 3.43"
|
||||
- **"significantly outperforms"** - Strong but not "dramatically"
|
||||
- **"by a relative margin of 50% to 70%"** - Range, not single number
|
||||
- **Reference to figure**: "(Fig. 1)"
|
||||
- **"In addition"** - Second dimension of value
|
||||
- **"self-contained"** - Independence keyword
|
||||
- **"trained entirely from scratch"** - Complete independence
|
||||
- **Negative list**: "without any pre-training, distillation, or curriculum learning"
|
||||
|
||||
---
|
||||
|
||||
## 6. Table Design: System-Level Comparison
|
||||
|
||||
### Pattern: Multiple Paradigms, Clear Highlighting
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
Table X:
|
||||
┌────────────────────────────────────┐
|
||||
│ Left side: Your direct competitors │
|
||||
│ (1-NFE and 2-NFE methods) │
|
||||
├────────────────────────────────────┤
|
||||
│ Right side: Other paradigms │
|
||||
│ (GANs, autoregressive, etc.) │
|
||||
├────────────────────────────────────┤
|
||||
│ **Your method** (bold, positioned) │
|
||||
└────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### MeanFlows Table 2 Organization:
|
||||
|
||||
```latex
|
||||
Table 2: Comparison on ImageNet 256×256.
|
||||
|
||||
Left: 1-NFE and 2-NFE diffusion/flow models
|
||||
Right: Other generative models
|
||||
|
||||
Highlighted: MeanFlow (our method)
|
||||
```
|
||||
|
||||
**Key Techniques**:
|
||||
1. **Split paradigm**: Direct competitors on left, others on right
|
||||
2. **Fair metrics**: params, NFE, FID (same for all)
|
||||
3. **Bold your method**: Visual emphasis
|
||||
4. **Position strategically**: Where you look best
|
||||
5. **Comprehensive**: Include all major paradigms
|
||||
|
||||
---
|
||||
|
||||
## 7. Figure Design: Visual Storytelling
|
||||
|
||||
### Pattern: Multi-Panel Narrative
|
||||
|
||||
**MeanFlows Figure 1**: "One-step generation on ImageNet 256×256 from scratch"
|
||||
|
||||
**Structure**:
|
||||
- **Main panel**: Generated images (visual evidence)
|
||||
- **Caption**: Detailed comparison table
|
||||
- **Annotations**: FID scores of competing methods
|
||||
- **Highlight**: "Our MeanFlow (MF) model achieves significantly better..."
|
||||
|
||||
**Techniques**:
|
||||
1. **Title tells the story**: "from scratch" - key differentiator
|
||||
2. **Images + numbers**: Both visual and quantitative
|
||||
3. **Competitor scores in caption**: Reader doesn't need to flip pages
|
||||
4. **"significantly better"**: In the figure caption itself
|
||||
|
||||
---
|
||||
|
||||
## 8. Ablation Study: Destructive Testing
|
||||
|
||||
### Pattern: Prove Necessity by Breaking Things
|
||||
|
||||
**Structure**:
|
||||
```markdown
|
||||
Table X:
|
||||
┌──────────────────────────────────┐
|
||||
│ (a) Vary one design dimension │
|
||||
│ - Show effect of parameter │
|
||||
│ - Mark default in gray │
|
||||
├──────────────────────────────────┤
|
||||
│ (b) Destructive comparison │
|
||||
│ - Intentionally use WRONG values │
|
||||
│ - Show only correct works │
|
||||
└──────────────────────────────────┘
|
||||
```
|
||||
|
||||
### MeanFlows Table 1 Example:
|
||||
|
||||
#### Part (a): Design Sweep
|
||||
```latex
|
||||
(a) Ratio of sampling r≠t
|
||||
% of r≠t FID, 1-NFE
|
||||
0% (= FM) 328.91
|
||||
25% 61.06
|
||||
50% 63.14
|
||||
100% 67.32
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **Descriptive caption**: "Ratio of sampling r≠t"
|
||||
- **Show failure mode**: "0% (= FM) 328.91" - pure FM fails
|
||||
- **Range**: 0% to 100% of parameter
|
||||
- **Default marked**: In original (not shown here)
|
||||
|
||||
#### Part (b): Destructive Testing
|
||||
```latex
|
||||
(b) JVP computation
|
||||
jvp tangent FID, 1-NFE
|
||||
(v, 0, 1) 61.06
|
||||
(v, 0, 0) [wrong] 268.06
|
||||
(v, 1, 0) [wrong] 329.22
|
||||
(v, 1, 1) [wrong] 137.96
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **"Destructive comparison"** in caption
|
||||
- **"intentionally performed"** in text
|
||||
- **Only first row works**: Others are wrong by design
|
||||
- **Proves necessity**: "meaningful results are achieved only when..."
|
||||
|
||||
---
|
||||
|
||||
## 9. Writing Style: Theory Keywords
|
||||
|
||||
### Emphasis Words for Theory-Driven Papers
|
||||
|
||||
**Naturalness Keywords** (use these to describe your theory):
|
||||
- "naturally" - "This naturally leads to..."
|
||||
- "intrinsic" - "intrinsic relation"
|
||||
- "well-defined" - "well-defined problem"
|
||||
- "principled" - "principled basis"
|
||||
- "first principles" - "from first principles"
|
||||
- "solely originated from" - "solely from definition"
|
||||
|
||||
**Independence Keywords**:
|
||||
- "does not depend on" - Theory independence
|
||||
- "independent of" - Implementation independence
|
||||
- "self-contained" - System independence
|
||||
- "from scratch" - No external dependencies
|
||||
- "without any X" - Negative list
|
||||
|
||||
**Differentiation Keywords**:
|
||||
- "in contrast to" - Conceptual contrast
|
||||
- "unlike" - Direct comparison
|
||||
- "typically" - "typically modeled" (their approach)
|
||||
- "prior works typically rely on" - Their limitation
|
||||
- "imposed as" - Artificial constraint (theirs)
|
||||
|
||||
### Avoid These (Too Promotional):
|
||||
- ❌ "revolutionary" - Too strong
|
||||
- ❌ "breakthrough" - Let others say it
|
||||
- ❌ "completely eliminates" - Too absolute
|
||||
- ✅ "significantly outperforms" - Strong but measured
|
||||
- ✅ "substantial improvement" - Professional
|
||||
|
||||
---
|
||||
|
||||
## 10. Common Mistakes in Theory Papers
|
||||
|
||||
### ❌ Don't:
|
||||
- Derive without explaining motivation - Why are we doing this?
|
||||
- Skip steps in derivation - Readers aren't you
|
||||
- Use heuristics without admitting it - Be honest
|
||||
- Overclaim - "proves optimal" vs "improves over"
|
||||
- Forget to acknowledge dependencies - If you use X, say it
|
||||
|
||||
### ✅ Do:
|
||||
- Start from first principles explicitly
|
||||
- Give each equation/dentity a memorable name
|
||||
- Show "destructive" ablations to prove necessity
|
||||
- Report relative improvements (more impactful)
|
||||
- Use "principled" keywords consistently
|
||||
- Admit what you DON'T need (negative list)
|
||||
|
||||
---
|
||||
|
||||
## 11. Revision Checklist for Theory-Driven Papers
|
||||
|
||||
**Before Submission, Verify:**
|
||||
|
||||
- [ ] Abstract starts from established framework (not "X is important")
|
||||
- [ ] Introduction has "Despite encouraging results..." critique
|
||||
- [ ] Core concept has a memorable name
|
||||
- [ ] Derivation is step-by-step with justifications
|
||||
- [ ] Key equation is named ("X Identity")
|
||||
- [ ] Theory is contrasted as "principled" vs "heuristic"
|
||||
- [ ] Results include relative improvement (X-Y%)
|
||||
- [ ] Self-containment is emphasized (what you don't need)
|
||||
- [ ] Ablations include destructive tests
|
||||
- [ ] Tables organize by paradigm, highlight your position
|
||||
- [ ] Figures tell visual story with captions
|
||||
- [ ] Theory keywords used consistently (principled, intrinsic, natural)
|
||||
|
||||
---
|
||||
|
||||
## 12. Example: Applying This Pattern
|
||||
|
||||
### Original Idea (Not Theory-Driven):
|
||||
"We propose a new training method that improves FID by 20%."
|
||||
|
||||
### Theory-Driven Version:
|
||||
"Flow Matching provides an intuitive framework for generative modeling,
|
||||
but recent one-step methods impose consistency constraints heuristically.
|
||||
Despite encouraging results, the underlying ground-truth field properties
|
||||
remain unknown. We introduce average velocity (in contrast to instantaneous
|
||||
velocity), deriving the MeanFlow Identity solely from first principles.
|
||||
This provides a principled basis for training, achieving 3.43 FID with
|
||||
50-70% relative improvement. Our method is self-contained, trained from
|
||||
scratch without pre-training or distillation."
|
||||
|
||||
**The Theory-Driven Frame**:
|
||||
- Foundation: Flow Matching (established)
|
||||
- Problem: Heuristic constraints (theory gap)
|
||||
- Concept: Average velocity (new)
|
||||
- Theory: MeanFlow Identity (derived)
|
||||
- Result: Strong + independent (no external deps)
|
||||
|
||||
---
|
||||
|
||||
## Paper Metadata
|
||||
|
||||
**Title**: Mean Flows for One-step Generative Modeling
|
||||
|
||||
**Authors**: Kaiming He et al.
|
||||
|
||||
**Year**: 2025
|
||||
|
||||
**Key Concepts**:
|
||||
- Average velocity vs instantaneous velocity
|
||||
- MeanFlow Identity
|
||||
- Principled vs heuristic training
|
||||
- Self-contained generative models
|
||||
|
||||
---
|
||||
|
||||
## Extracted by
|
||||
|
||||
**Date**: 2026-01-26
|
||||
|
||||
**Source**: Analysis of Mean Flows paper (16 pages)
|
||||
|
||||
**Extraction Focus**: Theory-driven paper writing patterns, first-principles
|
||||
derivations, principled vs heuristic positioning
|
||||
|
||||
**For Integration**: ml-paper-writing skill knowledge base
|
||||
@@ -0,0 +1,637 @@
|
||||
# Writing Techniques and Patterns
|
||||
|
||||
This file contains actionable sentence patterns, transition phrases, and writing techniques extracted from successful ML conference papers.
|
||||
|
||||
---
|
||||
|
||||
## Transition Phrases
|
||||
|
||||
### Literature Review Transitions
|
||||
**Source:** Various NeurIPS/ICML papers
|
||||
|
||||
**Introducing Problems:**
|
||||
- "However, these methods suffer from [limitation]."
|
||||
- "Despite recent progress, [challenge] remains unsolved."
|
||||
- "While existing approaches address [aspect], they struggle with [issue]."
|
||||
|
||||
**Presenting Solutions:**
|
||||
- "To address this, we propose..."
|
||||
- "We overcome this limitation by..."
|
||||
- "Our key insight is that..."
|
||||
|
||||
**Connecting to Related Work:**
|
||||
- "Building on [prior work], we extend..."
|
||||
- "Unlike approaches that [method], we instead..."
|
||||
- "Following the success of [paper], we apply..."
|
||||
|
||||
### Methods Section Transitions
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
|
||||
**Describing Components:**
|
||||
- "Our model consists of two main components: [A] and [B]."
|
||||
- "We divide our approach into [N] stages: [list]."
|
||||
|
||||
**Explaining Rationale:**
|
||||
- "We choose this architecture because..."
|
||||
- "This formulation allows us to..."
|
||||
- "Motivated by [intuition], we design..."
|
||||
|
||||
### Results Section Transitions
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
|
||||
**Presenting Findings:**
|
||||
- "Our method achieves [result], outperforming baselines by [margin]."
|
||||
- "As shown in Table 1, our approach..."
|
||||
- "Figure 2 demonstrates that..."
|
||||
|
||||
**Analyzing Results:**
|
||||
- "These results suggest that [insight]."
|
||||
- "Notably, we observe that..."
|
||||
- "This improvement indicates that..."
|
||||
|
||||
### Discussion Transitions
|
||||
**Source:** "Language Models are Few-Shot Learners", GPT-3 (2020)
|
||||
|
||||
**Interpreting Findings:**
|
||||
- "These findings reveal that..."
|
||||
- "This performance gap suggests that..."
|
||||
- "The strong correlation between...indicates..."
|
||||
|
||||
**Connecting to Broader Context:**
|
||||
- "Beyond the specific task, our results imply..."
|
||||
- "This has important implications for..."
|
||||
|
||||
**Acknowledging Limitations:**
|
||||
- "It is important to note that our study is limited to..."
|
||||
- "While these results are promising, several questions remain..."
|
||||
|
||||
---
|
||||
|
||||
## Sentence Patterns
|
||||
|
||||
### Claim Presentation
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
|
||||
**Strong Claims:**
|
||||
- "We show that [approach] achieves [result]."
|
||||
- "We demonstrate that [method] outperforms..."
|
||||
- "We prove that [technique] converges to..."
|
||||
|
||||
**Nuanced Claims:**
|
||||
- "Our results suggest that [factor] contributes to..."
|
||||
- "We observe that [phenomenon] emerges when..."
|
||||
- "Experiments indicate that [approach] is particularly effective for..."
|
||||
|
||||
### Technical Description
|
||||
**Source:** "Adam: A Method for Stochastic Optimization", ICLR (2015)
|
||||
|
||||
**Algorithm Description:**
|
||||
- "Formally, we optimize [objective] using [method]."
|
||||
- "The update rule for [parameter] is given by..."
|
||||
- "We modify the standard [approach] by..."
|
||||
|
||||
**Implementation Details:**
|
||||
- "In practice, we implement [feature] as..."
|
||||
- "For computational efficiency, we approximate..."
|
||||
- "We initialize [parameters] using..."
|
||||
|
||||
### Results Presentation
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
|
||||
**Quantitative Results:**
|
||||
- "Our model achieves [score] (±[std]), improving over..."
|
||||
- "On [dataset], we obtain [result], compared to..."
|
||||
- "We observe a [percentage]% improvement over baselines."
|
||||
|
||||
**Statistical Reporting:**
|
||||
- "Results are averaged over N runs with different seeds."
|
||||
- "Standard deviations are shown in parentheses."
|
||||
- "The improvement is statistically significant (p<0.01)."
|
||||
|
||||
---
|
||||
|
||||
## Clarity Techniques
|
||||
|
||||
### Active Voice Usage
|
||||
**Source:** Various well-written papers
|
||||
|
||||
**Passive (avoid):**
|
||||
- "The model was trained using..."
|
||||
- "Experiments were conducted on..."
|
||||
|
||||
**Active (prefer):**
|
||||
- "We trained the model using..."
|
||||
- "We conducted experiments on..."
|
||||
|
||||
**Guideline:** Use active voice for actions you performed. Use passive for general facts or when the actor is unclear.
|
||||
|
||||
### Specificity Over Generality
|
||||
**Source:** "Attention Is All You Need", NeurIPS (2017)
|
||||
|
||||
**Vague (avoid):**
|
||||
- "This approach improves performance."
|
||||
- "The method learns good representations."
|
||||
|
||||
**Specific (prefer):**
|
||||
- "This approach improves accuracy by 15%."
|
||||
- "The method learns representations that transfer to downstream tasks."
|
||||
|
||||
**Guideline:** Be quantitative whenever possible. Use specific numbers and metrics.
|
||||
|
||||
### Signposting
|
||||
**Source:** "BERT: Pre-training of Deep Bidirectional Transformers", NAACL (2019)
|
||||
|
||||
**Section Openings:**
|
||||
- "We now describe our model architecture."
|
||||
- "We evaluate on three tasks: [list]."
|
||||
- "The results suggest three key insights:"
|
||||
|
||||
**Internal Structure:**
|
||||
- "First, we [action]. Next, we [action]. Finally, we [action]."
|
||||
- "Our approach has three stages: [A], [B], and [C]."
|
||||
|
||||
**Guideline:** Use explicit signposting to help tired reviewers follow your paper.
|
||||
|
||||
---
|
||||
|
||||
## Common Phrase Templates
|
||||
|
||||
### Opening Abstract
|
||||
**Good Examples:**
|
||||
- "We introduce [method], a novel approach for [task]."
|
||||
- "We present [method], which achieves [result] by [mechanism]."
|
||||
- "We propose [framework] to address [challenge]."
|
||||
|
||||
**Avoid:**
|
||||
- "In this paper, we study..." (generic)
|
||||
- "Large language models have..." (overused opening)
|
||||
|
||||
### Introducing Related Work
|
||||
**Good Examples:**
|
||||
- "Recent work has shown promise in [area] [refs]."
|
||||
- "Several approaches have been proposed for [task] [refs]."
|
||||
- "The standard approach to [problem] is [method] [refs]."
|
||||
|
||||
### Describing Experiments
|
||||
**Good Examples:**
|
||||
- "We evaluate on [datasets], comparing against [baselines]."
|
||||
- "We conduct ablation studies to validate [component]."
|
||||
- "To verify [claim], we experiment with [variations]."
|
||||
|
||||
### Presenting Results
|
||||
**Good Examples:**
|
||||
- "Table 1 shows that our method outperforms all baselines."
|
||||
- "As shown in Figure 3, performance improves as [factor] increases."
|
||||
- "Our method achieves state-of-the-art on [task/metric]."
|
||||
|
||||
### Discussing Limitations
|
||||
**Good Examples:**
|
||||
- "Our approach has limitations: [constraint]."
|
||||
- "We note that our method is currently restricted to [condition]."
|
||||
- "A key limitation is [issue], which we leave for future work."
|
||||
|
||||
---
|
||||
|
||||
## Writing Principles
|
||||
|
||||
### From Top Papers
|
||||
|
||||
**Clarity First:**
|
||||
- "Make it easy for reviewers to understand your contribution."
|
||||
- "Use concrete examples and specific language."
|
||||
- "Avoid vague or ambiguous statements."
|
||||
|
||||
**Rigorous Presentation:**
|
||||
- "Provide enough detail for reproduction."
|
||||
- "Include error bars and statistical tests."
|
||||
- "Show negative results when relevant."
|
||||
|
||||
**Storytelling:**
|
||||
- "Your paper tells a story: problem → approach → solution → impact."
|
||||
- "Make the narrative clear in the introduction."
|
||||
- "Each section should advance the story."
|
||||
|
||||
**Honesty:**
|
||||
- "Acknowledge limitations explicitly."
|
||||
- "Don't overclaim results."
|
||||
- "Trust reviewers to appreciate honesty."
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Adapt patterns**: These templates can and should be adapted to your specific context
|
||||
- **Venue matters**: Some venues prefer certain styles (check venue-specific guides)
|
||||
- **Consistency**: Use consistent terminology throughout
|
||||
- **Tone**: Maintain professional, objective tone
|
||||
- **Length**: Keep transitions concise; don't over-explain
|
||||
|
||||
**Attribution:** All patterns extracted from analyzed papers with source citations for traceability.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## "Surprisingly" Findings: Multi-Level Reporting Pattern
|
||||
|
||||
**Source**: Kaiming He et al., "Exploring Plain Vision Transformer Backbones for Object Detection" (ViTDet, ECCV 2022), "Mean Flows" (2025)
|
||||
|
||||
**Paper Type**: Design simplification, unexpected findings
|
||||
|
||||
### The Three-Level "Surprisingly" Pattern
|
||||
|
||||
#### Level 1: Basic Surprise (Abstract/Opening)
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
Surprisingly, we observe: (i) [simple sufficient without common practice]
|
||||
and (ii) [simple sufficient without common practice]
|
||||
```
|
||||
|
||||
**Example (ViTDet Abstract)**:
|
||||
```latex
|
||||
Surprisingly, we observe: (i) it is sufficient to build a simple feature
|
||||
pyramid from a single-scale feature map (without the common FPN design) and
|
||||
(ii) it is sufficient to use window attention (without shifting) aided with
|
||||
very few cross-window propagation blocks.
|
||||
```
|
||||
|
||||
**Key Techniques**:
|
||||
- **Structured list**: Use (i) and (ii) to separate findings
|
||||
- **"sufficient"**: Scientific phrasing (not "optimal")
|
||||
- **"without [common practice]"**: Negative differentiation
|
||||
|
||||
#### Level 2: Competitive Surprise (Introduction)
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
More surprisingly, under some circumstances, our [method] can compete
|
||||
with the leading [competitors].
|
||||
```
|
||||
|
||||
**Example (ViTDet Introduction)**:
|
||||
```latex
|
||||
More surprisingly, under some circumstances, our plain-backbone detector,
|
||||
named ViTDet, can compete with the leading hierarchical-backbone detectors
|
||||
(e.g., Swin, MViT).
|
||||
```
|
||||
|
||||
**Key Techniques**:
|
||||
- **"More surprisingly"**: Progressive emphasis
|
||||
- **"under some circumstances"**: Measured claim
|
||||
- **"can compete with"**: Not "beat", competitive
|
||||
- **Name competitors**: Specific (Swin, MViT)
|
||||
|
||||
#### Level 3: Superiority Surprise (Results)
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
With [specific condition], our [method] can outperform the [competitors]
|
||||
that use [stronger condition]. The gains are more prominent for [condition].
|
||||
```
|
||||
|
||||
**Example**:
|
||||
```latex
|
||||
With Masked Autoencoder (MAE) pre-training, our plain-backbone detector can
|
||||
outperform the hierarchical counterparts that are pre-trained on ImageNet-1K/21K
|
||||
with supervision (Figure 3). The gains are more prominent for larger model sizes.
|
||||
```
|
||||
|
||||
**Key Techniques**:
|
||||
- **Specific conditions compared**: MAE vs ImageNet supervised
|
||||
- **"outperform"**: Stronger claim here (qualified by conditions)
|
||||
- **"The gains are more prominent for..."**: Pattern observation
|
||||
|
||||
---
|
||||
|
||||
### "Surprisingly" Variants
|
||||
|
||||
#### "Interestingly" - Pattern Observation + Explanation
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
Interestingly, [observation]. This is in line with the observation in [paper]
|
||||
that [their finding]. [Additional explanation].
|
||||
```
|
||||
|
||||
**Example (ViTDet)**:
|
||||
```latex
|
||||
Interestingly, performing propagation in the last 4 blocks is nearly as
|
||||
good as even placement. This is in line with the observation in ViT [14]
|
||||
that ViT has longer attention distance in later blocks and is more localized
|
||||
in earlier ones.
|
||||
```
|
||||
|
||||
**Use when**: You have literature support for your observation
|
||||
|
||||
#### "Notably" - Important Detail
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
Notably, [counter-intuitive result or impressive number].
|
||||
```
|
||||
|
||||
**Examples**:
|
||||
- "Notably, even embedding only the interval t−r yields reasonable results."
|
||||
- "Notably, our method is self-contained and trained entirely from scratch."
|
||||
|
||||
**Use when**: Emphasizing importance or counter-intuitive finding
|
||||
|
||||
#### "It is worth noting that" - Caveat/Clarification
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
It is worth noting that [technical caveat or clarification].
|
||||
```
|
||||
|
||||
**Examples**:
|
||||
- "It is worth noting that even when the conditional flows are designed to be straight ('rectified'), the marginal velocity field typically induces a curved trajectory."
|
||||
- "It is worth noting that the 3.34× memory (49G) is estimated as if the same training implementation could be used, which is not practical and requires special memory optimization."
|
||||
|
||||
**Use when**: Preventing misunderstanding or clarifying technical details
|
||||
|
||||
---
|
||||
|
||||
### When to Use "Surprisingly"
|
||||
|
||||
**DO use**:
|
||||
- When finding genuinely contradicts common practice
|
||||
- When simple solution works as well as complex one
|
||||
- When you have explanation (literature, hypothesis, theory)
|
||||
- With measured claims ("under some circumstances", "can compete")
|
||||
- With "sufficient" not "optimal"
|
||||
|
||||
**DON'T use**:
|
||||
- For incremental improvements (use "additionally" instead)
|
||||
- Without explanation/justification
|
||||
- Overgeneralizing ("always", "proves")
|
||||
- For expected results
|
||||
|
||||
---
|
||||
|
||||
## Ablation Study Writing Techniques
|
||||
|
||||
**Source**: Kaiming He papers (ViTDet, MeanFlows, MoCo v2)
|
||||
|
||||
### Table Design: Incremental Progression
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
Table X: [Component] Ablation
|
||||
┌──────────────────────────────────────────┐
|
||||
│ no [component] | AP | Δ │
|
||||
│ (a) [common variant] | AP | +X.X │
|
||||
│ (b) [another variant] | AP | +Y.Y │
|
||||
│ (c) ours: simple | AP | +Z.Z ✓ │
|
||||
└──────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Example (ViTDet Table 1)**:
|
||||
```latex
|
||||
pyramid design APbox APmask
|
||||
─────────────────────────────────────────
|
||||
no feature pyramid 47.8 42.5
|
||||
(a) FPN, 4-stage 50.3 44.9
|
||||
(b) FPN, last-map 50.9 45.3
|
||||
(c) simple feature pyramid 51.2 45.5
|
||||
```
|
||||
|
||||
**Techniques**:
|
||||
- **Baseline**: "no [X]" shows it's needed
|
||||
- **(a), (b), (c)**: Progressive variations
|
||||
- **Δ标注**: (+2.5) - Show incremental gains
|
||||
- **Correspondence**: "The entries (a-c) correspond to Figure X (a-c)"
|
||||
- **Conclusion**: "our simple pyramid is sufficient"
|
||||
|
||||
---
|
||||
|
||||
### Destructive Ablation: Proving Necessity
|
||||
|
||||
**Pattern**:
|
||||
```markdown
|
||||
We conduct a destructive comparison in which [wrong choice] is intentionally
|
||||
performed. Meaningful results are achieved only when [correct choice].
|
||||
```
|
||||
|
||||
**Example (MeanFlows Table 1b)**:
|
||||
```latex
|
||||
In Tab. 1b, we conduct a destructive comparison in which incorrect JVP
|
||||
computation is intentionally performed.
|
||||
|
||||
jvp tangent FID, 1-NFE
|
||||
(v, 0, 1) [correct] 61.06
|
||||
(v, 0, 0) [wrong] 268.06
|
||||
(v, 1, 0) [wrong] 329.22
|
||||
(v, 1, 1) [wrong] 137.96
|
||||
|
||||
It shows that meaningful results are achieved only when the JVP computation
|
||||
is correct.
|
||||
```
|
||||
|
||||
**Use when**: You need to prove a design choice is necessary (not just optional)
|
||||
|
||||
---
|
||||
|
||||
### Ablation Narrative: Observation → Explanation
|
||||
|
||||
**Pattern 1: Observation + Literature Support**
|
||||
```latex
|
||||
We observe that [observation]. This is consistent with the observation in
|
||||
[paper] that [their finding].
|
||||
```
|
||||
|
||||
**Pattern 2: Observation + Hypothesis**
|
||||
```latex
|
||||
We hypothesize that this is because [reason 1] and also because [reason 2].
|
||||
```
|
||||
|
||||
**Pattern 3: Observation + Theory**
|
||||
```latex
|
||||
[Observation]. This indicates that [theoretical explanation].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Theory-Driven Paper Keywords
|
||||
|
||||
**Source**: Kaiming He et al., "Mean Flows for One-step Generative Modeling" (2025)
|
||||
|
||||
### Naturalness Keywords (use to describe your theory)
|
||||
|
||||
- **"naturally"** - "This naturally leads to..."
|
||||
- **"intrinsic"** - "intrinsic relation between..."
|
||||
- **"well-defined"** - "well-defined problem"
|
||||
- **"principled"** - "principled basis for..."
|
||||
- **"first principles"** - "from first principles"
|
||||
- **"solely originated from"** - "solely from definition"
|
||||
|
||||
### Independence Keywords
|
||||
|
||||
- **"does not depend on"** - Theory independence from implementation
|
||||
- **"independent of"** - Independent of specific choices
|
||||
- **"self-contained"** - System independence
|
||||
- **"from scratch"** - No external dependencies
|
||||
- **"without any X"** - Negative list (what you don't need)
|
||||
|
||||
### Differentiation Keywords
|
||||
|
||||
- **"in contrast to"** - Conceptual contrast
|
||||
- **"unlike"** - Direct comparison
|
||||
- **"typically"** - "typically modeled" (their approach)
|
||||
- **"prior works typically rely on"** - Their limitation
|
||||
- **"imposed as"** - Artificial constraint (theirs)
|
||||
|
||||
### Avoid (Too Promotional)
|
||||
|
||||
- ❌ "revolutionary" - Let others say it
|
||||
- ❌ "breakthrough" - Overused
|
||||
- ❌ "completely eliminates" - Too absolute
|
||||
- ✅ "significantly outperforms" - Strong but measured
|
||||
- ✅ "substantial improvement" - Professional
|
||||
|
||||
---
|
||||
|
||||
## Design Simplification Paper Keywords
|
||||
|
||||
**Source**: Kaiming He et al., "Exploring Plain Vision Transformer Backbones for Object Detection" (ViTDet, 2022)
|
||||
|
||||
### Philosophy Keywords
|
||||
|
||||
- **"minimal"** - "minimal adaptations"
|
||||
- **"sufficient"** - "is sufficient to" (not "optimal")
|
||||
- **"simple"** - "simple feature pyramid"
|
||||
- **"plain"** - "plain backbone"
|
||||
- **"decouple"** - "decouple pre-training from fine-tuning"
|
||||
- **"independence"** - "independence of upstream vs downstream"
|
||||
|
||||
### Direction Keywords
|
||||
|
||||
- **"pursue a different direction"** - Clear positioning
|
||||
- **"in contrast to"** - Differentiation
|
||||
- **"abandons"** - What you give up (respectfully)
|
||||
- **"enables"** - What your approach allows
|
||||
|
||||
### Measured Claim Keywords
|
||||
|
||||
- **"under some circumstances"** - Not always
|
||||
- **"can compete with"** - Competitive, not dominant
|
||||
- **"more prominent for"** - When effect is stronger
|
||||
- **"is sufficient"** - Necessary, not maximal
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Updated: 何凯明的写作技巧
|
||||
|
||||
> 来源: 分析了何凯明的 11 篇代表性论文（扩展分析，包括 MeanFlows、ViTDet、MAR 等）
|
||||
> 添加时间: 2026-01-26
|
||||
|
||||
> 扩展内容包括：
|
||||
> - "Surprisingly" 发现的多层次报告模式
|
||||
> - Ablation Study 的增量式和破坏性实验设计
|
||||
> - 理论驱动型论文的关键词策略
|
||||
> - 设计简化型论文的关键词策略
|
||||
|
||||
### 句子结构偏好
|
||||
|
||||
**主动语态优先** (被动语态仅 9.3%)
|
||||
何凯明偏好使用主动、直接的陈述：
|
||||
|
||||
**✅ 推荐 (何凯明的风格):**
|
||||
- "We present a framework for [task]"
|
||||
- "Our method achieves [result]"
|
||||
- "This formulation enables [benefit]"
|
||||
|
||||
**❌ 避免:**
|
||||
- "A framework is presented for [task]"
|
||||
- "Results are achieved by our method"
|
||||
|
||||
### 贡献表达方式
|
||||
|
||||
何凯明常用的贡献表达模式：
|
||||
|
||||
**模式 1: 直接陈述**
|
||||
```
|
||||
We propose [method] that [feature].
|
||||
We demonstrate [result] on [dataset].
|
||||
```
|
||||
|
||||
**模式 2: 对比强调**
|
||||
```
|
||||
Unlike [previous work], our approach [difference].
|
||||
This leads to [improvement] in [metric].
|
||||
```
|
||||
|
||||
**模式 3: 问题-解决方案**
|
||||
```
|
||||
[Challenge] remains difficult. We address this by [solution].
|
||||
```
|
||||
|
||||
### 技术术语使用
|
||||
|
||||
何凯明论文中的高频术语组合：
|
||||
|
||||
| 术语类别 | 常用术语 |
|
||||
|---------|---------|
|
||||
| **网络架构** | deep neural networks, convolutional, residual, activation |
|
||||
| **训练过程** | training, validation, optimization, convergence |
|
||||
| **性能评估** | outperforms, achieves, improves, surpasses |
|
||||
| **方法定位** | state-of-the-art, baseline, framework, algorithm |
|
||||
| **所有权** | our method, our approach, our framework |
|
||||
|
||||
### 过渡短语
|
||||
|
||||
何凯明论文中常用的过渡短语（按频率排序）：
|
||||
|
||||
1. **however** - 用于对比不同观点
|
||||
2. **in addition/additionally** - 补充信息
|
||||
3. **furthermore** - 递进说明
|
||||
4. **therefore/thus** - 得出结论
|
||||
5. **specifically** - 举例说明
|
||||
6. **conversely** - 对比说明
|
||||
|
||||
### 数值结果呈现
|
||||
|
||||
何凯明在呈现数值结果时的模式：
|
||||
|
||||
**精确性优先:**
|
||||
```
|
||||
Our method achieves 76.4% accuracy (Table X).
|
||||
This represents a 28% relative improvement.
|
||||
```
|
||||
|
||||
**对比式呈现:**
|
||||
```
|
||||
Compared to baseline (73.2%), our method (76.4%) improves
|
||||
by 3.2 percentage points.
|
||||
```
|
||||
|
||||
**强调意义:**
|
||||
```
|
||||
This result won the 1st place in [competition/task].
|
||||
```
|
||||
|
||||
### 图表引用模式
|
||||
|
||||
何凯明引用图表的标准格式：
|
||||
|
||||
**图表引入:**
|
||||
- "Fig. X shows [现象]"
|
||||
- "Table Y summarizes [结果]"
|
||||
- "As shown in Fig. Z, [结论]"
|
||||
|
||||
**图表描述:**
|
||||
- "The solid line denotes [条件 A], the dashed line [条件 B]"
|
||||
- "The blue curve shows [指标], while the red curve shows [指标]"
|
||||
|
||||
### 网络架构描述
|
||||
|
||||
何凯明在描述网络架构时的特点：
|
||||
|
||||
1. **表格化呈现** - 使用表格列出层配置
|
||||
2. **可视化辅助** - 配合架构图
|
||||
3. **简洁符号** - 使用清晰的数学符号
|
||||
4. **示例:**
|
||||
```
|
||||
layer name | output size | configuration
|
||||
conv1 | 112×112 | 7×7, 64, /2
|
||||
```
|
||||
@@ -0,0 +1,199 @@
|
||||
# arXiv Literature Search Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide provides workflows for discovering and evaluating recent ML research papers on arXiv. Use this when conducting literature reviews, finding related work, or staying updated on recent publications.
|
||||
|
||||
---
|
||||
|
||||
## Search Strategies
|
||||
|
||||
### 1. Keyword-Based Search
|
||||
|
||||
**arXiv Search URL Pattern:**
|
||||
```
|
||||
https://arxiv.org/search/?searchtype=all&query=KEYWORDS&abstracts=show&order=-announced_date_first
|
||||
```
|
||||
|
||||
**Common ML Search Keywords:**
|
||||
- **General ML**: `machine learning`, `deep learning`, `neural networks`
|
||||
- **Specific Areas**: `reinforcement learning`, `transformer`, `attention mechanism`, `graph neural networks`
|
||||
- **Applications**: `computer vision`, `natural language processing`, `reinforcement learning`
|
||||
- **Methods**: `self-supervised learning`, `contrastive learning`, `foundation models`
|
||||
|
||||
**Tips:**
|
||||
- Combine keywords with `+` for AND operation
|
||||
- Use `|` for OR operation
|
||||
- Put phrases in quotes for exact matches: `"attention is all you need"`
|
||||
|
||||
### 2. Category-Based Search
|
||||
|
||||
**Recommended arXiv Categories for ML:**
|
||||
- `cs.LG` (Machine Learning)
|
||||
- `cs.AI` (Artificial Intelligence)
|
||||
- `cs.CV` (Computer Vision and Pattern Recognition)
|
||||
- `cs.CL` (Computation and Language)
|
||||
- `cs.NE` (Neural and Evolutionary Computing)
|
||||
- `stat.ML` (Machine Learning - Statistics)
|
||||
|
||||
**Category Filter URL:**
|
||||
```
|
||||
https://arxiv.org/search/?cat:cs.LG+OR+cat:cs.AI+AND+all:transformer&abstracts=show&order=-announced_date_first
|
||||
```
|
||||
|
||||
### 3. Time-Based Filtering
|
||||
|
||||
**Recent Papers (Last 3 Months):**
|
||||
- Use `order=-announced_date_first` for newest first
|
||||
- Manually filter by submission date
|
||||
- Check paper metadata for submission date
|
||||
|
||||
---
|
||||
|
||||
## Using Chrome MCP for arXiv Search
|
||||
|
||||
When available, use Chrome MCP tools for automated arXiv searching:
|
||||
|
||||
1. **Navigate to arXiv search** using Chrome MCP navigation
|
||||
2. **Extract paper information** from search results:
|
||||
- Paper title
|
||||
- Authors
|
||||
- arXiv ID
|
||||
- Abstract preview
|
||||
- Publication date
|
||||
|
||||
3. **Navigate to individual papers** for detailed review
|
||||
|
||||
---
|
||||
|
||||
## Paper Quality Evaluation
|
||||
|
||||
Evaluate papers using the 5-dimension criteria below:
|
||||
|
||||
| Dimension | Weight | Key Points |
|
||||
|-----------|--------|------------|
|
||||
| **Innovation** | 30% | Novelty of contribution |
|
||||
| **Method Completeness** | 25% | Clarity and reproducibility |
|
||||
| **Experimental Thoroughness** | 25% | Validation depth |
|
||||
| **Writing Quality** | 10% | Clarity of expression |
|
||||
| **Relevance & Impact** | 10% | Domain importance |
|
||||
|
||||
### Scoring Guidelines (1-5 scale)
|
||||
|
||||
**Innovation (30%):**
|
||||
- 5: Breakthrough contribution, major impact
|
||||
- 4: Significant improvement, new insights
|
||||
- 3: Methodological innovation
|
||||
- 2: Incremental improvement
|
||||
- 1: Minor improvements
|
||||
|
||||
**Method Completeness (25%):**
|
||||
- 5: Complete and rigorous, easily reproducible
|
||||
- 4: Very detailed, mostly reproducible
|
||||
- 3: Core method clear, basically reproducible
|
||||
- 2: Lacks key details
|
||||
- 1: Unclear description
|
||||
|
||||
**Experimental Thoroughness (25%):**
|
||||
- 5: Comprehensive multi-dataset, ablation studies
|
||||
- 4: Multiple datasets, reasonable ablations
|
||||
- 3: Main experiments complete
|
||||
- 2: Limited experiments
|
||||
- 1: Minimal validation
|
||||
|
||||
**Writing Quality (10%):**
|
||||
- 5: Excellent clarity and rigor
|
||||
- 4: Clear and well-structured
|
||||
- 3: Understandable
|
||||
- 2: Some ambiguity
|
||||
- 1: Confusing
|
||||
|
||||
**Relevance & Impact (10%):**
|
||||
- 5: Solves important problem, wide impact
|
||||
- 4: Important domain problem
|
||||
- 3: Meaningful contribution
|
||||
- 2: Niche problem
|
||||
- 1: Limited impact
|
||||
|
||||
### Selection Process
|
||||
|
||||
1. **Screen by title/abstract** for relevance
|
||||
2. **Navigate to full paper** for detailed review
|
||||
3. **Score each dimension** (1-5)
|
||||
4. **Calculate weighted total**
|
||||
5. **Rank and select** top papers
|
||||
|
||||
---
|
||||
|
||||
## Extracting Paper Metadata
|
||||
|
||||
**From arXiv Abstract Page (`https://arxiv.org/abs/ARXIV_ID`):**
|
||||
|
||||
- Title (from `<h1>` tag)
|
||||
- Authors (from `.authors` element)
|
||||
- Abstract (from `blockquote.abstract`)
|
||||
- Submission date (from `.dateline`)
|
||||
- arXiv ID (from URL)
|
||||
- Categories (from `.subjects`)
|
||||
- Comments (if present)
|
||||
- Code repository (check abstract for GitHub links)
|
||||
|
||||
---
|
||||
|
||||
## Integration with Citation Workflow
|
||||
|
||||
After finding relevant papers:
|
||||
|
||||
1. **Verify citations** using Semantic Scholar API (see `../citation-workflow.md`)
|
||||
2. **Fetch BibTeX** programmatically via DOI
|
||||
3. **Store in bibliography** with verification status
|
||||
|
||||
---
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Finding Related Work
|
||||
|
||||
When writing a paper, use arXiv search to:
|
||||
1. Find recent papers on your topic
|
||||
2. Identify state-of-the-art methods
|
||||
3. Discover competing approaches
|
||||
4. Find baseline comparisons
|
||||
|
||||
### Staying Updated
|
||||
|
||||
Set up regular searches for:
|
||||
- Your specific research area
|
||||
- Competing labs/researchers
|
||||
- New methods in your domain
|
||||
- Conference proceedings (preprints)
|
||||
|
||||
### Literature Reviews
|
||||
|
||||
For comprehensive reviews:
|
||||
1. Start with broad keyword searches
|
||||
2. Filter by recent publications (last 1-3 years)
|
||||
3. Use citation chaining (forward and backward)
|
||||
4. Evaluate and select high-quality papers
|
||||
5. Organize by theme/contribution
|
||||
|
||||
---
|
||||
|
||||
## Tips for Effective Searching
|
||||
|
||||
1. **Use specific keywords** rather than broad terms
|
||||
2. **Combine techniques** (keywords + categories + time filters)
|
||||
3. **Check code availability** (many arXiv papers link to GitHub)
|
||||
4. **Look for citations** to understand impact
|
||||
5. **Read abstracts carefully** before full papers
|
||||
6. **Use paper metrics** (citation count, code stars) as indicators
|
||||
|
||||
---
|
||||
|
||||
## External Resources
|
||||
|
||||
- **arXiv**: https://arxiv.org/
|
||||
- **Semantic Scholar**: https://www.semanticscholar.org/
|
||||
- **Papers With Code**: https://paperswithcode.com/
|
||||
- **Connected Papers**: https://www.connectedpapers.com/
|
||||
- **arXiv API**: http://export.arxiv.org/api_help/
|
||||
@@ -0,0 +1,303 @@
|
||||
# ML Paper Quality Evaluation Criteria
|
||||
|
||||
## Overview
|
||||
|
||||
Use these criteria to evaluate ML research papers found during literature search or when selecting papers for detailed review. The 5-dimension framework provides structured assessment for paper selection and comparison.
|
||||
|
||||
---
|
||||
|
||||
## Evaluation Dimensions
|
||||
|
||||
| Dimension | Weight | Description |
|
||||
|-----------|--------|-------------|
|
||||
| **Innovation** | 30% | Novelty and originality of contribution |
|
||||
| **Method Completeness** | 25% | Clarity, rigor, and reproducibility |
|
||||
| **Experimental Thoroughness** | 25% | Validation depth and analysis quality |
|
||||
| **Writing Quality** | 10% | Clarity and presentation |
|
||||
| **Relevance & Impact** | 10% | Domain importance and potential impact |
|
||||
|
||||
---
|
||||
|
||||
## Detailed Scoring Rubrics
|
||||
|
||||
### 1. Innovation (30%)
|
||||
|
||||
**Score 5 - Breakthrough:**
|
||||
- Proposes entirely new paradigm or framework
|
||||
- Solves long-standing open problem
|
||||
- Major impact expected on the field
|
||||
- Challenges fundamental assumptions
|
||||
|
||||
**Score 4 - Significant Innovation:**
|
||||
- Substantial improvement over existing methods
|
||||
- New insights or perspectives
|
||||
- Novel combination of techniques
|
||||
- Clear advancement over state-of-the-art
|
||||
|
||||
**Score 3 - Methodological Innovation:**
|
||||
- New method or architecture proposed
|
||||
- Some novelty but incremental
|
||||
- Reasonable contribution
|
||||
- Standard type of innovation
|
||||
|
||||
**Score 2 - Incremental Improvement:**
|
||||
- Minor improvements to existing methods
|
||||
- Limited novelty
|
||||
- Small advancement
|
||||
- Mostly derivative
|
||||
|
||||
**Score 1 - Trivial:**
|
||||
- Minimal contribution
|
||||
- Obvious extension
|
||||
- No real innovation
|
||||
- Known results
|
||||
|
||||
**Evaluation Questions:**
|
||||
- Does this paper propose something genuinely new?
|
||||
- Does it advance the state-of-the-art?
|
||||
- Will this influence future work?
|
||||
- Is the contribution significant or marginal?
|
||||
|
||||
---
|
||||
|
||||
### 2. Method Completeness (25%)
|
||||
|
||||
**Score 5 - Complete and Rigorous:**
|
||||
- Full mathematical derivation
|
||||
- All hyperparameters specified
|
||||
- Complete algorithmic details
|
||||
- Easily reproducible
|
||||
- Code available
|
||||
|
||||
**Score 4 - Very Complete:**
|
||||
- Detailed method description
|
||||
- Most important details included
|
||||
- Mostly reproducible
|
||||
- Minor gaps in documentation
|
||||
|
||||
**Score 3 - Reproducible:**
|
||||
- Core method clearly described
|
||||
- Key details present
|
||||
- Can be reproduced with effort
|
||||
- Some ambiguity in details
|
||||
|
||||
**Score 2 - Lacks Details:**
|
||||
- Key details missing
|
||||
- Difficult to reproduce
|
||||
- Incomplete description
|
||||
- Ambiguous in important areas
|
||||
|
||||
**Score 1 - Unclear:**
|
||||
- Method description unclear
|
||||
- Missing critical information
|
||||
- Cannot determine validity
|
||||
- Poorly explained
|
||||
|
||||
**Evaluation Questions:**
|
||||
- Can another researcher reproduce this work?
|
||||
- Are all important details specified?
|
||||
- Is mathematical derivation sound?
|
||||
- Is code available and documented?
|
||||
|
||||
---
|
||||
|
||||
### 3. Experimental Thoroughness (25%)
|
||||
|
||||
**Score 5 - Comprehensive:**
|
||||
- Multiple diverse datasets
|
||||
- Extensive ablation studies
|
||||
- Statistical significance testing
|
||||
- Thorough analysis and discussion
|
||||
- Comparison with strong baselines
|
||||
|
||||
**Score 4 - Very Thorough:**
|
||||
- Multiple datasets
|
||||
- Reasonable ablation studies
|
||||
- Proper baseline comparisons
|
||||
- Good analysis
|
||||
|
||||
**Score 3 - Adequate:**
|
||||
- Main experiments complete
|
||||
- Standard datasets
|
||||
- Basic baselines
|
||||
- Results are credible
|
||||
|
||||
**Score 2 - Limited:**
|
||||
- Limited experiments
|
||||
- Few datasets
|
||||
- Weak baselines
|
||||
- Minimal analysis
|
||||
|
||||
**Score 1 - Insufficient:**
|
||||
- Minimal validation
|
||||
- Toy examples only
|
||||
- No meaningful comparisons
|
||||
- Results not convincing
|
||||
|
||||
**Evaluation Questions:**
|
||||
- Are experiments comprehensive?
|
||||
- Are baselines strong and appropriate?
|
||||
- Are statistical tests used?
|
||||
- Is there ablation analysis?
|
||||
- Are results on standard datasets?
|
||||
|
||||
---
|
||||
|
||||
### 4. Writing Quality (10%)
|
||||
|
||||
**Score 5 - Excellent:**
|
||||
- Clear, precise, well-structured
|
||||
- Logical flow throughout
|
||||
- Professional presentation
|
||||
- High-quality figures
|
||||
- No ambiguity
|
||||
|
||||
**Score 4 - Very Good:**
|
||||
- Clear and well-written
|
||||
- Mostly logical structure
|
||||
- Good presentation
|
||||
- Minor issues
|
||||
|
||||
**Score 3 - Understandable:**
|
||||
- Basically clear
|
||||
- Some organizational issues
|
||||
- Acceptable presentation
|
||||
- Understandable with effort
|
||||
|
||||
**Score 2 - Fair:**
|
||||
- Some confusing sections
|
||||
- Organization problems
|
||||
- Presentation issues
|
||||
- Hard to follow at times
|
||||
|
||||
**Score 1 - Poor:**
|
||||
- Unclear or confusing
|
||||
- Poor organization
|
||||
- Difficult to understand
|
||||
- Major presentation problems
|
||||
|
||||
**Evaluation Questions:**
|
||||
- Is the paper easy to understand?
|
||||
- Is the structure logical?
|
||||
- Are figures/tables clear?
|
||||
- Is the writing professional?
|
||||
|
||||
---
|
||||
|
||||
### 5. Relevance & Impact (10%)
|
||||
|
||||
**Score 5 - High Impact:**
|
||||
- Solves important problem
|
||||
- Broad applicability
|
||||
- Expected wide influence
|
||||
- Addresses fundamental challenge
|
||||
|
||||
**Score 4 - Domain Important:**
|
||||
- Important problem in field
|
||||
- Significant potential impact
|
||||
- Relevant to many researchers
|
||||
|
||||
**Score 3 - Meaningful:**
|
||||
- Meaningful contribution
|
||||
- Moderate impact expected
|
||||
- Relevant to subset of field
|
||||
|
||||
**Score 2 - Niche:**
|
||||
- Specialized problem
|
||||
- Limited applicability
|
||||
- Narrow impact
|
||||
|
||||
**Score 1 - Limited:**
|
||||
- Very narrow problem
|
||||
- Minimal impact expected
|
||||
- Limited relevance
|
||||
|
||||
**Evaluation Questions:**
|
||||
- Is this an important problem?
|
||||
- Will this influence future work?
|
||||
- Is it relevant to current research needs?
|
||||
- Does it address a significant challenge?
|
||||
|
||||
---
|
||||
|
||||
## Scoring Calculation
|
||||
|
||||
**Weighted Total:**
|
||||
```
|
||||
Total = (Innovation × 0.30) + (Method × 0.25) + (Experiments × 0.25) + (Writing × 0.10) + (Impact × 0.10)
|
||||
```
|
||||
|
||||
**Example Calculation:**
|
||||
- Innovation: 4/5
|
||||
- Method: 3/5
|
||||
- Experiments: 4/5
|
||||
- Writing: 3/5
|
||||
- Impact: 4/5
|
||||
|
||||
```
|
||||
Total = (4 × 0.30) + (3 × 0.25) + (4 × 0.25) + (3 × 0.10) + (4 × 0.10)
|
||||
= 1.20 + 0.75 + 1.00 + 0.30 + 0.40
|
||||
= 3.65 / 5.0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Selection Process
|
||||
|
||||
### For Literature Reviews
|
||||
|
||||
1. **Screen papers** by title/abstract for relevance
|
||||
2. **Full review** of potentially relevant papers
|
||||
3. **Score each paper** using all 5 dimensions
|
||||
4. **Rank by total score**
|
||||
5. **Select top papers** for detailed review
|
||||
|
||||
### Quality Thresholds
|
||||
|
||||
- **Excellent**: 4.0+ (include definitely)
|
||||
- **Good**: 3.5-3.9 (include if relevant)
|
||||
- **Fair**: 3.0-3.4 (include if highly relevant)
|
||||
- **Poor**: <3.0 (exclude unless essential)
|
||||
|
||||
---
|
||||
|
||||
## Quick Screening Indicators
|
||||
|
||||
Before detailed review, check:
|
||||
|
||||
**Positive Indicators:**
|
||||
- Published at top venue (NeurIPS, ICML, ICLR)
|
||||
- Citations in top papers
|
||||
- Code available with stars
|
||||
- Authors from top labs
|
||||
- Clear novelty in abstract
|
||||
|
||||
**Negative Indicators:**
|
||||
- Vague abstract
|
||||
- Limited experiments mentioned
|
||||
- No baselines mentioned
|
||||
- Poor writing in abstract
|
||||
- incremental claims only
|
||||
|
||||
---
|
||||
|
||||
## Integration with Paper Discovery
|
||||
|
||||
When using arXiv search (`arxiv-search-guide.md`):
|
||||
|
||||
1. **Search** for relevant papers
|
||||
2. **Extract metadata** from arXiv pages
|
||||
3. **Quick screen** by abstract/relevance
|
||||
4. **Detailed review** of promising papers
|
||||
5. **Score using** these criteria
|
||||
6. **Rank and select** top candidates
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- These criteria are designed for ML papers specifically
|
||||
- Adjust weights based on your specific needs
|
||||
- Use scores as relative comparisons, not absolute judgments
|
||||
- Consider venue reputation as additional signal
|
||||
- Code availability is increasingly important for reproducibility
|
||||
@@ -0,0 +1,367 @@
|
||||
# Reviewer Guidelines & Evaluation Criteria
|
||||
|
||||
This reference documents how reviewers evaluate papers at major ML/AI conferences, helping authors anticipate and address reviewer concerns.
|
||||
|
||||
---
|
||||
|
||||
## Contents
|
||||
|
||||
- [Universal Evaluation Dimensions](#universal-evaluation-dimensions)
|
||||
- [NeurIPS Reviewer Guidelines](#neurips-reviewer-guidelines)
|
||||
- [ICML Reviewer Guidelines](#icml-reviewer-guidelines)
|
||||
- [ICLR Reviewer Guidelines](#iclr-reviewer-guidelines)
|
||||
- [ACL Reviewer Guidelines](#acl-reviewer-guidelines)
|
||||
- [What Makes Reviews Strong](#what-makes-reviews-strong)
|
||||
- [Common Reviewer Concerns](#common-reviewer-concerns)
|
||||
- [How to Address Reviewer Feedback](#how-to-address-reviewer-feedback)
|
||||
|
||||
---
|
||||
|
||||
## Universal Evaluation Dimensions
|
||||
|
||||
All major ML conferences assess papers across four core dimensions:
|
||||
|
||||
### 1. Quality (Technical Soundness)
|
||||
|
||||
**What reviewers ask:**
|
||||
- Are claims well-supported by theoretical analysis or experimental results?
|
||||
- Are the proofs correct? Are the experiments properly controlled?
|
||||
- Are baselines appropriate and fairly compared?
|
||||
- Is the methodology sound?
|
||||
|
||||
**How to ensure high quality:**
|
||||
- Include complete proofs (main paper or appendix with sketches)
|
||||
- Use appropriate baselines (not strawmen)
|
||||
- Report variance/error bars with methodology
|
||||
- Document hyperparameter selection process
|
||||
|
||||
### 2. Clarity (Writing & Organization)
|
||||
|
||||
**What reviewers ask:**
|
||||
- Is the paper clearly written and well organized?
|
||||
- Can an expert in the field reproduce the results?
|
||||
- Is notation consistent? Are terms defined?
|
||||
- Is the paper self-contained?
|
||||
|
||||
**How to ensure clarity:**
|
||||
- Use consistent terminology throughout
|
||||
- Define all notation at first use
|
||||
- Include reproducibility details (appendix acceptable)
|
||||
- Have non-authors read before submission
|
||||
|
||||
### 3. Significance (Impact & Importance)
|
||||
|
||||
**What reviewers ask:**
|
||||
- Are the results impactful for the community?
|
||||
- Will others build upon this work?
|
||||
- Does it address an important problem?
|
||||
- What is the potential for real-world impact?
|
||||
|
||||
**How to demonstrate significance:**
|
||||
- Clearly articulate the problem's importance
|
||||
- Connect to broader research themes
|
||||
- Discuss potential applications
|
||||
- Compare to existing approaches meaningfully
|
||||
|
||||
### 4. Originality (Novelty & Contribution)
|
||||
|
||||
**What reviewers ask:**
|
||||
- Does this provide new insights?
|
||||
- How does it differ from prior work?
|
||||
- Is the contribution non-trivial?
|
||||
|
||||
**Key insight from NeurIPS guidelines:**
|
||||
> "Originality does not necessarily require introducing an entirely new method. Papers that provide novel insights from evaluating existing approaches or shed light on why methods succeed can also be highly original."
|
||||
|
||||
---
|
||||
|
||||
## NeurIPS Reviewer Guidelines
|
||||
|
||||
### Scoring System (1-6 Scale)
|
||||
|
||||
| Score | Label | Description |
|
||||
|-------|-------|-------------|
|
||||
| **6** | Strong Accept | Groundbreaking, flawless work; top 2-3% of submissions |
|
||||
| **5** | Accept | Technically solid, high impact; would benefit the community |
|
||||
| **4** | Borderline Accept | Solid work with limited evaluation; leans accept |
|
||||
| **3** | Borderline Reject | Solid but weaknesses outweigh strengths; leans reject |
|
||||
| **2** | Reject | Technical flaws or weak evaluation |
|
||||
| **1** | Strong Reject | Well-known results or unaddressed ethics concerns |
|
||||
|
||||
### Reviewer Instructions
|
||||
|
||||
Reviewers are explicitly instructed to:
|
||||
|
||||
1. **Evaluate the paper as written** - not what it could be with revisions
|
||||
2. **Provide constructive feedback** - 3-5 actionable points
|
||||
3. **Not penalize honest limitations** - acknowledging weaknesses is encouraged
|
||||
4. **Assess reproducibility** - can the work be verified?
|
||||
5. **Consider ethical implications** - potential misuse or harm
|
||||
|
||||
### What Reviewers Should Avoid
|
||||
|
||||
- Superficial, uninformed reviews
|
||||
- Demanding unreasonable additional experiments
|
||||
- Penalizing authors for honest limitation acknowledgment
|
||||
- Rejecting for missing citations to reviewer's own work
|
||||
|
||||
### Timeline (NeurIPS 2025)
|
||||
|
||||
- Bidding: May 17-21
|
||||
- Reviewing period: May 29 - July 2
|
||||
- Author rebuttals: July 24-30
|
||||
- Discussion period: July 31 - August 13
|
||||
- Final notifications: September 18
|
||||
|
||||
---
|
||||
|
||||
## ICML Reviewer Guidelines
|
||||
|
||||
### Review Structure
|
||||
|
||||
ICML reviewers provide:
|
||||
|
||||
1. **Summary** - Brief description of contributions
|
||||
2. **Strengths** - Positive aspects
|
||||
3. **Weaknesses** - Areas for improvement
|
||||
4. **Questions** - Clarifications for authors
|
||||
5. **Limitations** - Assessment of stated limitations
|
||||
6. **Ethics** - Any concerns
|
||||
7. **Overall Score** - Recommendation
|
||||
|
||||
### Scoring Guidelines
|
||||
|
||||
ICML uses a similar 1-6 scale with calibration:
|
||||
- Top 25% of accepted papers: Score 5-6
|
||||
- Typical accepted paper: Score 4-5
|
||||
- Borderline: Score 3-4
|
||||
- Clear reject: Score 1-2
|
||||
|
||||
### Key Evaluation Points
|
||||
|
||||
1. **Reproducibility** - Are there enough details?
|
||||
2. **Experimental rigor** - Multiple seeds, proper baselines?
|
||||
3. **Writing quality** - Clear, organized, well-structured?
|
||||
4. **Novelty** - Non-trivial contribution?
|
||||
|
||||
---
|
||||
|
||||
## ICLR Reviewer Guidelines
|
||||
|
||||
### OpenReview Process
|
||||
|
||||
ICLR uses OpenReview with:
|
||||
- Public reviews (after acceptance decisions)
|
||||
- Author responses visible to reviewers
|
||||
- Discussion between reviewers and ACs
|
||||
|
||||
### Scoring
|
||||
|
||||
ICLR reviews include:
|
||||
- **Soundness**: 1-4 scale
|
||||
- **Presentation**: 1-4 scale
|
||||
- **Contribution**: 1-4 scale
|
||||
- **Overall**: 1-10 scale
|
||||
- **Confidence**: 1-5 scale
|
||||
|
||||
### Unique ICLR Considerations
|
||||
|
||||
1. **LLM Disclosure** - Reviewers assess whether LLM use is properly disclosed
|
||||
2. **Reproducibility** - Emphasis on code availability
|
||||
3. **Reciprocal Reviewing** - Authors must also serve as reviewers
|
||||
|
||||
---
|
||||
|
||||
## ACL Reviewer Guidelines
|
||||
|
||||
### ACL-Specific Criteria
|
||||
|
||||
ACL adds NLP-specific evaluation:
|
||||
|
||||
1. **Linguistic soundness** - Are linguistic claims accurate?
|
||||
2. **Resource documentation** - Are datasets/models properly documented?
|
||||
3. **Multilingual consideration** - If applicable, is language diversity addressed?
|
||||
|
||||
### Limitations Section
|
||||
|
||||
ACL specifically requires a Limitations section. Reviewers check:
|
||||
- Are limitations honest and comprehensive?
|
||||
- Do limitations undermine core claims?
|
||||
- Are potential negative impacts addressed?
|
||||
|
||||
### Ethics Review
|
||||
|
||||
ACL has a dedicated ethics review process for:
|
||||
- Dual-use concerns
|
||||
- Data privacy issues
|
||||
- Bias and fairness implications
|
||||
|
||||
---
|
||||
|
||||
## What Makes Reviews Strong
|
||||
|
||||
### Following Daniel Dennett's Rules
|
||||
|
||||
Good reviewers follow these principles:
|
||||
|
||||
1. **Re-express the position fairly** - Show you understand the paper
|
||||
2. **List agreements** - Acknowledge what works well
|
||||
3. **List what you learned** - Credit the contribution
|
||||
4. **Only then critique** - After establishing understanding
|
||||
|
||||
### Review Structure Best Practices
|
||||
|
||||
**Strong Review Structure:**
|
||||
```
|
||||
Summary (1 paragraph):
|
||||
- What the paper does
|
||||
- Main contribution claimed
|
||||
|
||||
Strengths (3-5 bullets):
|
||||
- Specific positive aspects
|
||||
- Why these matter
|
||||
|
||||
Weaknesses (3-5 bullets):
|
||||
- Specific concerns
|
||||
- Why these matter
|
||||
- Suggestions for addressing
|
||||
|
||||
Questions (2-4 items):
|
||||
- Clarifications needed
|
||||
- Things that would change assessment
|
||||
|
||||
Minor Issues (optional):
|
||||
- Typos, unclear sentences
|
||||
- Formatting issues
|
||||
|
||||
Overall Assessment:
|
||||
- Clear recommendation with reasoning
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Reviewer Concerns
|
||||
|
||||
### Technical Concerns
|
||||
|
||||
| Concern | How to Pre-empt |
|
||||
|---------|-----------------|
|
||||
| "Baselines too weak" | Use state-of-the-art baselines, cite recent work |
|
||||
| "Missing ablations" | Include systematic ablation study |
|
||||
| "No error bars" | Report std dev/error, multiple runs |
|
||||
| "Hyperparameters not tuned" | Document tuning process, search ranges |
|
||||
| "Claims not supported" | Ensure every claim has evidence |
|
||||
|
||||
### Novelty Concerns
|
||||
|
||||
| Concern | How to Pre-empt |
|
||||
|---------|-----------------|
|
||||
| "Incremental contribution" | Clearly articulate what's new vs prior work |
|
||||
| "Similar to [paper X]" | Explicitly compare to X in Related Work |
|
||||
| "Straightforward extension" | Highlight non-obvious aspects |
|
||||
|
||||
### Clarity Concerns
|
||||
|
||||
| Concern | How to Pre-empt |
|
||||
|---------|-----------------|
|
||||
| "Hard to follow" | Use clear structure, signposting |
|
||||
| "Notation inconsistent" | Review all notation, create notation table |
|
||||
| "Missing details" | Include reproducibility appendix |
|
||||
| "Figures unclear" | Self-contained captions, proper sizing |
|
||||
|
||||
### Significance Concerns
|
||||
|
||||
| Concern | How to Pre-empt |
|
||||
|---------|-----------------|
|
||||
| "Limited impact" | Discuss broader implications |
|
||||
| "Narrow evaluation" | Evaluate on multiple benchmarks |
|
||||
| "Only works in restricted setting" | Acknowledge scope, explain why still valuable |
|
||||
|
||||
---
|
||||
|
||||
## How to Address Reviewer Feedback
|
||||
|
||||
### Rebuttal Best Practices
|
||||
|
||||
**Do:**
|
||||
- Thank reviewers for their time
|
||||
- Address each concern specifically
|
||||
- Provide evidence (new experiments if possible)
|
||||
- Be concise—reviewers are busy
|
||||
- Acknowledge valid criticisms
|
||||
|
||||
**Don't:**
|
||||
- Be defensive or dismissive
|
||||
- Make promises you can't keep
|
||||
- Ignore difficult criticisms
|
||||
- Write excessively long rebuttals
|
||||
- Argue about subjective assessments
|
||||
|
||||
### Rebuttal Template
|
||||
|
||||
```markdown
|
||||
We thank the reviewers for their thoughtful feedback.
|
||||
|
||||
## Reviewer 1
|
||||
|
||||
**R1-Q1: [Quoted concern]**
|
||||
[Direct response with evidence]
|
||||
|
||||
**R1-Q2: [Quoted concern]**
|
||||
[Direct response with evidence]
|
||||
|
||||
## Reviewer 2
|
||||
|
||||
...
|
||||
|
||||
## Summary of Changes
|
||||
If accepted, we will:
|
||||
1. [Specific change]
|
||||
2. [Specific change]
|
||||
3. [Specific change]
|
||||
```
|
||||
|
||||
### When to Accept Criticism
|
||||
|
||||
Some reviewer feedback should simply be accepted:
|
||||
- Valid technical errors
|
||||
- Missing important related work
|
||||
- Unclear explanations
|
||||
- Missing experimental details
|
||||
|
||||
Acknowledge these gracefully: "The reviewer is correct that... We will revise to..."
|
||||
|
||||
### When to Push Back
|
||||
|
||||
You can respectfully disagree when:
|
||||
- Reviewer misunderstood the paper
|
||||
- Requested experiments are out of scope
|
||||
- Criticism is factually incorrect
|
||||
|
||||
Frame disagreements constructively: "We appreciate this perspective. However, [explanation]..."
|
||||
|
||||
---
|
||||
|
||||
## Pre-Submission Reviewer Simulation
|
||||
|
||||
Before submitting, ask yourself:
|
||||
|
||||
**Quality:**
|
||||
- [ ] Would I trust these results if I saw them?
|
||||
- [ ] Are all claims supported by evidence?
|
||||
- [ ] Are baselines fair and recent?
|
||||
|
||||
**Clarity:**
|
||||
- [ ] Can someone reproduce this from the paper?
|
||||
- [ ] Is the writing clear to non-experts in this subfield?
|
||||
- [ ] Are all terms and notation defined?
|
||||
|
||||
**Significance:**
|
||||
- [ ] Why should the community care about this?
|
||||
- [ ] What can people do with this work?
|
||||
- [ ] Is the problem important?
|
||||
|
||||
**Originality:**
|
||||
- [ ] What specifically is new here?
|
||||
- [ ] How does this differ from closest related work?
|
||||
- [ ] Is the contribution non-trivial?
|
||||
@@ -0,0 +1,159 @@
|
||||
# Source Bibliography
|
||||
|
||||
This document lists all authoritative sources used to build this skill, organized by topic.
|
||||
|
||||
---
|
||||
|
||||
## Writing Philosophy & Guides
|
||||
|
||||
### Primary Sources (Must-Read)
|
||||
|
||||
| Source | Author | URL | Key Contribution |
|
||||
|--------|--------|-----|------------------|
|
||||
| **Highly Opinionated Advice on How to Write ML Papers** | Neel Nanda | [Alignment Forum](https://www.alignmentforum.org/posts/eJGptPbbFPZGLpjsp/highly-opinionated-advice-on-how-to-write-ml-papers) | Narrative framework, "What/Why/So What", time allocation |
|
||||
| **How to Write ML Papers** | Sebastian Farquhar (DeepMind) | [Blog](https://sebastianfarquhar.com/on-research/2024/11/04/how_to_write_ml_papers/) | 5-sentence abstract formula, structure templates |
|
||||
| **A Survival Guide to a PhD** | Andrej Karpathy | [Blog](http://karpathy.github.io/2016/09/07/phd/) | Paper structure recipe, contribution framing |
|
||||
| **Heuristics for Scientific Writing** | Zachary Lipton (CMU) | [Blog](https://www.approximatelycorrect.com/2018/01/29/heuristics-technical-scientific-writing-machine-learning-perspective/) | Word choice, section balance, intensifier warnings |
|
||||
| **Advice for Authors** | Jacob Steinhardt (UC Berkeley) | [Blog](https://jsteinhardt.stat.berkeley.edu/blog/advice-for-authors) | Precision over brevity, consistent terminology |
|
||||
| **Easy Paper Writing Tips** | Ethan Perez (Anthropic) | [Blog](https://ethanperez.net/easy-paper-writing-tips/) | Micro-level tips, apostrophe unfolding, clarity tricks |
|
||||
|
||||
### Foundational Scientific Writing
|
||||
|
||||
| Source | Author | URL | Key Contribution |
|
||||
|--------|--------|-----|------------------|
|
||||
| **The Science of Scientific Writing** | Gopen & Swan | [PDF](https://cseweb.ucsd.edu/~swanson/papers/science-of-writing.pdf) | Topic/stress positions, old-before-new, 7 principles |
|
||||
| **Summary of Science of Scientific Writing** | Lawrence Crowl | [Summary](https://www.crowl.org/Lawrence/writing/GopenSwan90.html) | Condensed version of Gopen & Swan |
|
||||
|
||||
### Additional Resources
|
||||
|
||||
| Source | URL | Key Contribution |
|
||||
|--------|-----|------------------|
|
||||
| How To Write A Research Paper In ML | [Blog](https://grigorisg9gr.github.io/machine%20learning/research%20paper/how-to-write-a-research-paper-in-machine-learning/) | Practical walkthrough, LaTeX tips |
|
||||
| A Recipe for Training Neural Networks | [Karpathy Blog](http://karpathy.github.io/2019/04/25/recipe/) | Debugging methodology that translates to paper structure |
|
||||
| ICML Paper Writing Best Practices | [ICML](https://icml.cc/Conferences/2022/BestPractices) | Official venue guidance |
|
||||
| Bill Freeman's Writing Slides | [MIT](https://billf.mit.edu/sites/default/files/documents/cvprPapers.pdf) | Visual guide to paper structure |
|
||||
|
||||
---
|
||||
|
||||
## Official Conference Guidelines
|
||||
|
||||
### NeurIPS
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Paper Checklist Guidelines | [NeurIPS](https://neurips.cc/public/guides/PaperChecklist) | 16-item mandatory checklist |
|
||||
| Reviewer Guidelines 2025 | [NeurIPS](https://neurips.cc/Conferences/2025/ReviewerGuidelines) | Evaluation criteria, scoring |
|
||||
| Style Files | [NeurIPS](https://neurips.cc/Conferences/2025/PaperInformation/StyleFiles) | LaTeX templates |
|
||||
|
||||
### ICML
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Paper Guidelines | [ICML](https://icml.cc/Conferences/2024/PaperGuidelines) | Submission requirements |
|
||||
| Reviewer Instructions 2025 | [ICML](https://icml.cc/Conferences/2025/ReviewerInstructions) | Review form, evaluation |
|
||||
| Style & Author Instructions | [ICML](https://icml.cc/Conferences/2022/StyleAuthorInstructions) | Formatting specifications |
|
||||
|
||||
### ICLR
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Author Guide 2026 | [ICLR](https://iclr.cc/Conferences/2026/AuthorGuide) | Submission requirements, LLM disclosure |
|
||||
| Reviewer Guide 2025 | [ICLR](https://iclr.cc/Conferences/2025/ReviewerGuide) | Review process, evaluation |
|
||||
|
||||
### ACL/EMNLP
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| ACL Style Files | [GitHub](https://github.com/acl-org/acl-style-files) | LaTeX templates |
|
||||
| ACL Rolling Review | [ARR](https://aclrollingreview.org/) | Submission process |
|
||||
|
||||
### AAAI
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Author Kit 2026 | [AAAI](https://aaai.org/authorkit26/) | Templates and guidelines |
|
||||
|
||||
### COLM
|
||||
|
||||
| Document | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Template | [GitHub](https://github.com/COLM-org/Template) | LaTeX templates |
|
||||
|
||||
---
|
||||
|
||||
## Citation APIs & Tools
|
||||
|
||||
### APIs
|
||||
|
||||
| API | Documentation | Best For |
|
||||
|-----|---------------|----------|
|
||||
| **Semantic Scholar** | [Docs](https://api.semanticscholar.org/api-docs/) | ML/AI papers, citation graphs |
|
||||
| **CrossRef** | [Docs](https://www.crossref.org/documentation/retrieve-metadata/rest-api/) | DOI lookup, BibTeX retrieval |
|
||||
| **arXiv** | [Docs](https://info.arxiv.org/help/api/basics.html) | Preprints, PDF access |
|
||||
| **OpenAlex** | [Docs](https://docs.openalex.org/) | Open alternative, bulk access |
|
||||
|
||||
### Python Libraries
|
||||
|
||||
| Library | Install | Purpose |
|
||||
|---------|---------|---------|
|
||||
| `semanticscholar` | `pip install semanticscholar` | Semantic Scholar wrapper |
|
||||
| `arxiv` | `pip install arxiv` | arXiv search and download |
|
||||
| `habanero` | `pip install habanero` | CrossRef client |
|
||||
|
||||
### Citation Verification
|
||||
|
||||
| Tool | URL | Purpose |
|
||||
|------|-----|---------|
|
||||
| Citely | [citely.ai](https://citely.ai/citation-checker) | Batch verification |
|
||||
| ReciteWorks | [reciteworks.com](https://reciteworks.com/) | In-text citation checking |
|
||||
|
||||
---
|
||||
|
||||
## Visualization & Formatting
|
||||
|
||||
### Figure Creation
|
||||
|
||||
| Tool | URL | Purpose |
|
||||
|------|-----|---------|
|
||||
| PlotNeuralNet | [GitHub](https://github.com/HarisIqbal88/PlotNeuralNet) | TikZ neural network diagrams |
|
||||
| SciencePlots | [GitHub](https://github.com/garrettj403/SciencePlots) | Publication-ready matplotlib |
|
||||
| Okabe-Ito Palette | [Reference](https://jfly.uni-koeln.de/color/) | Colorblind-safe colors |
|
||||
|
||||
### LaTeX Resources
|
||||
|
||||
| Resource | URL | Purpose |
|
||||
|----------|-----|---------|
|
||||
| Overleaf Templates | [Overleaf](https://www.overleaf.com/latex/templates) | Online LaTeX editor |
|
||||
| BibLaTeX Guide | [CTAN](https://ctan.org/pkg/biblatex) | Modern citation management |
|
||||
|
||||
---
|
||||
|
||||
## Research on AI Writing & Hallucination
|
||||
|
||||
| Source | URL | Key Finding |
|
||||
|--------|-----|-------------|
|
||||
| AI Hallucinations in Citations | [Enago](https://www.enago.com/academy/ai-hallucinations-research-citations/) | ~40% error rate |
|
||||
| Hallucination in AI Writing | [PMC](https://pmc.ncbi.nlm.nih.gov/articles/PMC10726751/) | Types of citation errors |
|
||||
| NeurIPS 2025 AI Report | [ByteIota](https://byteiota.com/neurips-2025-100-ai-hallucinations-slip-through-review/) | 100+ hallucinated citations |
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference by Topic
|
||||
|
||||
### For Narrative & Structure
|
||||
→ Start with: Neel Nanda, Sebastian Farquhar, Andrej Karpathy
|
||||
|
||||
### For Sentence-Level Clarity
|
||||
→ Start with: Gopen & Swan, Ethan Perez, Zachary Lipton
|
||||
|
||||
### For Word Choice & Style
|
||||
→ Start with: Zachary Lipton, Jacob Steinhardt
|
||||
|
||||
### For Conference-Specific Requirements
|
||||
→ Start with: Official venue guidelines (NeurIPS, ICML, ICLR, ACL)
|
||||
|
||||
### For Citation Management
|
||||
→ Start with: Semantic Scholar API, CrossRef, citation-workflow.md
|
||||
|
||||
### For Reviewer Expectations
|
||||
→ Start with: Venue reviewer guidelines, reviewer-guidelines.md
|
||||
@@ -0,0 +1,476 @@
|
||||
# ML Paper Writing Philosophy & Best Practices
|
||||
|
||||
This reference compiles writing advice from prominent ML researchers including Neel Nanda, Andrej Karpathy, Sebastian Farquhar, Zachary Lipton, and Jacob Steinhardt.
|
||||
|
||||
---
|
||||
|
||||
## Contents
|
||||
|
||||
- [The Narrative Principle](#the-narrative-principle)
|
||||
- [Time Allocation](#time-allocation)
|
||||
- [Abstract Writing Formula](#abstract-writing-formula)
|
||||
- [Introduction Structure](#introduction-structure)
|
||||
- [Sentence-Level Clarity](#sentence-level-clarity)
|
||||
- [Word Choice and Precision](#word-choice-and-precision)
|
||||
- [Mathematical Writing](#mathematical-writing)
|
||||
- [Figure Design](#figure-design)
|
||||
- [Common Mistakes to Avoid](#common-mistakes-to-avoid)
|
||||
|
||||
---
|
||||
|
||||
## The Narrative Principle
|
||||
|
||||
### From Neel Nanda
|
||||
|
||||
"A paper is a short, rigorous, evidence-based technical story with a takeaway readers care about."
|
||||
|
||||
The narrative rests on three pillars that must be crystal clear by the end of your introduction:
|
||||
|
||||
**The "What"**: One to three specific novel claims fitting within a cohesive theme. Vague contributions like "we study X" fail immediately—reviewers need precise, falsifiable claims.
|
||||
|
||||
**The "Why"**: Rigorous empirical evidence that convincingly supports those claims, including strong baselines honestly tuned and experiments that distinguish between competing hypotheses rather than merely showing "decent results."
|
||||
|
||||
**The "So What"**: Why readers should care, connecting your contribution to problems the community recognizes as important.
|
||||
|
||||
### From Andrej Karpathy
|
||||
|
||||
"A paper is not a random collection of experiments you report on. The paper sells a single thing that was not obvious or present before. The entire paper is organized around this core contribution with surgical precision."
|
||||
|
||||
This applies whether you're presenting a new architecture, a theoretical result, or improved understanding of existing methods—NeurIPS explicitly notes that "originality does not necessarily require an entirely new method."
|
||||
|
||||
**Practical Implication**: If you cannot state your contribution in one sentence, you don't yet have a paper. Everything else—experiments, related work, discussion—exists only to support that core claim.
|
||||
|
||||
---
|
||||
|
||||
## Time Allocation
|
||||
|
||||
### From Neel Nanda
|
||||
|
||||
Spend approximately **the same amount of time** on each of:
|
||||
1. The abstract
|
||||
2. The introduction
|
||||
3. The figures
|
||||
4. Everything else combined
|
||||
|
||||
This isn't hyperbole—most reviewers form preliminary judgments before reaching your methods section. Readers encounter your paper in a predictable pattern: **title → abstract → introduction → figures → maybe the rest.**
|
||||
|
||||
### Reviewer Reading Patterns
|
||||
|
||||
Studies of reviewer behavior show:
|
||||
- Abstract is read 100% of the time
|
||||
- Introduction is skimmed by 90%+ of reviewers
|
||||
- Figures are examined before methods by most reviewers
|
||||
- Full methods are read only if interest is established
|
||||
|
||||
**Implication**: Front-load your paper's value. Don't bury the contribution.
|
||||
|
||||
---
|
||||
|
||||
## Abstract Writing Formula
|
||||
|
||||
### Sebastian Farquhar's 5-Sentence Formula
|
||||
|
||||
1. **What you achieved**: "We introduce...", "We prove...", "We demonstrate..."
|
||||
2. **Why this is hard and important**
|
||||
3. **How you do it** (with specialist keywords for discoverability)
|
||||
4. **What evidence you have**
|
||||
5. **Your most remarkable number/result**
|
||||
|
||||
### Example (Good Abstract)
|
||||
|
||||
```
|
||||
We prove that gradient descent on overparameterized neural networks
|
||||
converges to global minima at a linear rate. [What]
|
||||
This resolves a fundamental question about why deep learning works
|
||||
despite non-convex optimization landscapes. [Why hard/important]
|
||||
Our proof relies on showing that the Neural Tangent Kernel remains
|
||||
approximately constant during training, reducing the problem to
|
||||
kernel regression. [How with keywords]
|
||||
We validate our theory on CIFAR-10 and ImageNet, showing that
|
||||
predicted convergence rates match experiments within 5%. [Evidence]
|
||||
This is the first polynomial-time convergence guarantee for
|
||||
networks with practical depth and width. [Remarkable result]
|
||||
```
|
||||
|
||||
### What to Avoid
|
||||
|
||||
From Zachary Lipton: "If the first sentence can be pre-pended to any ML paper, delete it."
|
||||
|
||||
**Delete these openings**:
|
||||
- "Large language models have achieved remarkable success..."
|
||||
- "Deep learning has revolutionized..."
|
||||
- "In recent years, neural networks have..."
|
||||
|
||||
**Start with your specific contribution instead.**
|
||||
|
||||
---
|
||||
|
||||
## Introduction Structure
|
||||
|
||||
### Requirements
|
||||
|
||||
- **1-1.5 pages maximum** (in two-column format)
|
||||
- **Methods should start by page 2-3**
|
||||
- Must include **2-4 bullet contribution list** (max 1-2 lines each)
|
||||
|
||||
### Structure Template
|
||||
|
||||
```markdown
|
||||
1. Opening Hook (2-3 sentences)
|
||||
- State the problem your paper addresses
|
||||
- Why it matters RIGHT NOW
|
||||
|
||||
2. Background/Challenge (1 paragraph)
|
||||
- What makes this problem hard?
|
||||
- What have others tried? Why is it insufficient?
|
||||
|
||||
3. Your Approach (1 paragraph)
|
||||
- What do you do differently?
|
||||
- Key insight that enables your contribution
|
||||
|
||||
4. Contribution Bullets (2-4 items)
|
||||
- Be specific and falsifiable
|
||||
- Each bullet: 1-2 lines maximum
|
||||
|
||||
5. Results Preview (2-3 sentences)
|
||||
- Most impressive numbers
|
||||
- Scope of evaluation
|
||||
|
||||
6. Paper Organization (optional, 1-2 sentences)
|
||||
- "Section 2 presents... Section 3 describes..."
|
||||
```
|
||||
|
||||
### Contribution Bullets: Good vs Bad
|
||||
|
||||
**Good:**
|
||||
- We prove that X converges in O(n log n) time under assumption Y
|
||||
- We introduce Z, a 3-layer architecture that reduces memory by 40%
|
||||
- We demonstrate that A outperforms B by 15% on benchmark C
|
||||
|
||||
**Bad:**
|
||||
- We study the problem of X (not a contribution)
|
||||
- We provide extensive experiments (too vague)
|
||||
- We make several contributions to the field (says nothing)
|
||||
|
||||
---
|
||||
|
||||
## Sentence-Level Clarity
|
||||
|
||||
### From Gopen & Swan: "The Science of Scientific Writing"
|
||||
|
||||
The seminal 1990 paper by George Gopen and Judith Swan establishes that **readers have structural expectations** about where information appears in prose. Violating these expectations forces readers to spend energy on structure rather than content.
|
||||
|
||||
> "If the reader is to grasp what the writer means, the writer must understand what the reader needs."
|
||||
|
||||
#### The 7 Principles of Reader Expectations
|
||||
|
||||
**Principle 1: Subject-Verb Proximity**
|
||||
|
||||
Keep grammatical subject and verb close together. Anything intervening reads as interruption of lesser importance.
|
||||
|
||||
**Weak**: "The model, which was trained on 100M tokens and fine-tuned on domain-specific data using LoRA with rank 16, achieves state-of-the-art results"
|
||||
|
||||
**Strong**: "The model achieves state-of-the-art results after training on 100M tokens and fine-tuning with LoRA (rank 16)"
|
||||
|
||||
**Principle 2: Stress Position (Save the Best for Last)**
|
||||
|
||||
Readers naturally emphasize the **last words of a sentence**. Place your most important information there.
|
||||
|
||||
**Weak**: "Accuracy improves by 15% when using attention"
|
||||
**Strong**: "When using attention, accuracy improves by **15%**"
|
||||
|
||||
**Principle 3: Topic Position (First Things First)**
|
||||
|
||||
The beginning of a sentence establishes perspective. Put the "whose story" element first—readers expect the sentence to be about whoever shows up first.
|
||||
|
||||
**Weak**: "A novel attention mechanism that computes alignment scores is introduced"
|
||||
**Strong**: "To address the alignment problem, we introduce a novel attention mechanism"
|
||||
|
||||
**Principle 4: Old Information Before New**
|
||||
|
||||
Put familiar information (old) in the topic position for backward linkage; put new information in the stress position for emphasis.
|
||||
|
||||
**Weak**: "Sparse attention was introduced by Child et al. The quadratic complexity of standard attention motivates this work."
|
||||
**Strong**: "Standard attention has quadratic complexity. To address this, Child et al. introduced sparse attention."
|
||||
|
||||
**Principle 5: One Unit, One Function**
|
||||
|
||||
Each unit of discourse (sentence, paragraph, section) should serve a single function. If you have two points, use two units.
|
||||
|
||||
**Principle 6: Articulate Action in the Verb**
|
||||
|
||||
Express the action of each sentence in its verb, not in nominalized nouns.
|
||||
|
||||
**Weak**: "We performed an analysis of the results" (nominalization)
|
||||
**Strong**: "We analyzed the results" (action in verb)
|
||||
|
||||
**Principle 7: Context Before New Information**
|
||||
|
||||
Provide context before asking the reader to consider anything new. This applies at all levels—sentence, paragraph, section.
|
||||
|
||||
**Weak**: "Equation 3 shows that convergence is guaranteed when the learning rate satisfies..."
|
||||
**Strong**: "For convergence to be guaranteed, the learning rate must satisfy the condition in Equation 3..."
|
||||
|
||||
#### Summary Table
|
||||
|
||||
| Principle | Rule | Mnemonic |
|
||||
|-----------|------|----------|
|
||||
| Subject-Verb Proximity | Keep subject and verb close | "Don't interrupt yourself" |
|
||||
| Stress Position | Emphasis at sentence end | "Save the best for last" |
|
||||
| Topic Position | Context at sentence start | "First things first" |
|
||||
| Old Before New | Familiar → unfamiliar | "Build on known ground" |
|
||||
| One Unit, One Function | Each paragraph = one point | "One idea per container" |
|
||||
| Action in Verb | Use verbs, not nominalizations | "Verbs do, nouns sit" |
|
||||
| Context Before New | Explain before presenting | "Set the stage first" |
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Micro-Level Writing Tips
|
||||
|
||||
### From Ethan Perez (Anthropic)
|
||||
|
||||
These practical micro-level tips improve clarity at the sentence and word level.
|
||||
|
||||
#### Pronoun Management
|
||||
|
||||
**Minimize pronouns** ("this," "it," "these," "that"). When pronouns are necessary, use them as adjectives with a noun:
|
||||
|
||||
**Weak**: "This shows that the model converges."
|
||||
**Strong**: "This result shows that the model converges."
|
||||
|
||||
**Weak**: "It improves performance."
|
||||
**Strong**: "This modification improves performance."
|
||||
|
||||
#### Verb Placement
|
||||
|
||||
**Position verbs early** in sentences for better parsing:
|
||||
|
||||
**Weak**: "The gradient, after being computed and normalized, updates the weights."
|
||||
**Strong**: "The gradient updates the weights after being computed and normalized."
|
||||
|
||||
#### Apostrophe Unfolding
|
||||
|
||||
Transform possessive constructions for clarity:
|
||||
|
||||
**Original**: "X's Y" → **Unfolded**: "The Y of X"
|
||||
|
||||
**Before**: "The model's accuracy on the test set"
|
||||
**After**: "The accuracy of the model on the test set"
|
||||
|
||||
This isn't always better, but when sentences feel awkward, try unfolding.
|
||||
|
||||
#### Words to Eliminate
|
||||
|
||||
Delete these filler words in almost all cases:
|
||||
- "actually"
|
||||
- "a bit"
|
||||
- "fortunately" / "unfortunately"
|
||||
- "very" / "really"
|
||||
- "quite"
|
||||
- "basically"
|
||||
- "essentially"
|
||||
- Excessive connectives ("however," "moreover," "furthermore" when not needed)
|
||||
|
||||
#### Sentence Construction Rules
|
||||
|
||||
1. **One idea per sentence** - If struggling to express an idea in one sentence, it needs two
|
||||
2. **No repeated sounds** - Avoid similar-sounding words in the same sentence
|
||||
3. **Every sentence adds information** - Delete sentences that merely restate
|
||||
4. **Active voice always** - Specify the actor ("We find..." not "It is found...")
|
||||
5. **Expand contractions** - "don't" → "do not" for formality
|
||||
|
||||
#### Paragraph Architecture
|
||||
|
||||
- **First sentence**: State the point clearly
|
||||
- **Middle sentences**: Support with evidence
|
||||
- **Last sentence**: Reinforce or transition
|
||||
|
||||
Don't bury key information in the middle of paragraphs.
|
||||
|
||||
---
|
||||
|
||||
## Word Choice and Precision
|
||||
|
||||
### From Zachary Lipton
|
||||
|
||||
**Eliminate hedging** unless genuine uncertainty exists:
|
||||
- Delete "may" and "can" unless necessary
|
||||
- "provides *very* tight approximation" drips with insecurity
|
||||
- "provides tight approximation" is confident
|
||||
|
||||
**Avoid vacuous intensifiers**:
|
||||
- Delete: very, extremely, highly, significantly (unless statistical)
|
||||
- These words signal insecurity, not strength
|
||||
|
||||
### From Jacob Steinhardt
|
||||
|
||||
**Precision over brevity**: Replace vague terms with specific ones.
|
||||
|
||||
| Vague | Specific |
|
||||
|-------|----------|
|
||||
| performance | accuracy, latency, throughput |
|
||||
| improves | increases accuracy by X%, reduces latency by Y |
|
||||
| large | 1B parameters, 100M tokens |
|
||||
| fast | 3x faster, 50ms latency |
|
||||
| good results | 92% accuracy, 0.85 F1 |
|
||||
|
||||
**Consistent terminology**: Referring to the same concept with different terms creates confusion.
|
||||
|
||||
**Choose one and stick with it**:
|
||||
- "model" vs "network" vs "architecture"
|
||||
- "training" vs "learning" vs "optimization"
|
||||
- "sample" vs "example" vs "instance"
|
||||
|
||||
### Vocabulary Signaling
|
||||
|
||||
**Avoid words signaling incremental work**:
|
||||
- Never: "combine," "modify," "expand," "extend"
|
||||
- Instead: "develop," "propose," "introduce"
|
||||
|
||||
**Why**: "We combine X and Y" sounds like you stapled two existing ideas together. "We develop a method that leverages X for Y" sounds like genuine contribution.
|
||||
|
||||
---
|
||||
|
||||
## Mathematical Writing
|
||||
|
||||
### From Ethan Perez
|
||||
|
||||
**Unfold apostrophes** for clarity:
|
||||
- Weak: "X's Y"
|
||||
- Strong: "The Y of X"
|
||||
|
||||
Example: "the model's accuracy" → "the accuracy of the model"
|
||||
|
||||
### General Principles
|
||||
|
||||
1. **State all assumptions formally** before theorems
|
||||
2. **Provide intuitive explanations** alongside proofs
|
||||
3. **Use consistent notation** throughout the paper
|
||||
4. **Define symbols at first use**
|
||||
|
||||
### Notation Conventions
|
||||
|
||||
```latex
|
||||
% Scalars: lowercase italic
|
||||
$x$, $y$, $\alpha$, $\beta$
|
||||
|
||||
% Vectors: lowercase bold
|
||||
$\mathbf{x}$, $\mathbf{v}$
|
||||
|
||||
% Matrices: uppercase bold
|
||||
$\mathbf{W}$, $\mathbf{X}$
|
||||
|
||||
% Sets: uppercase calligraphic
|
||||
$\mathcal{X}$, $\mathcal{D}$
|
||||
|
||||
% Functions: roman for named functions
|
||||
$\mathrm{softmax}$, $\mathrm{ReLU}$
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Figure Design
|
||||
|
||||
### From Neel Nanda
|
||||
|
||||
Figures should tell a coherent story even if the reader skips the text. Many readers DO skip the text initially.
|
||||
|
||||
### Design Principles
|
||||
|
||||
1. **Figure 1 is crucial**: Often the first thing readers examine after abstract
|
||||
2. **Self-contained captions**: Reader should understand figure without main text
|
||||
3. **No title inside figure**: The caption serves this function (ICML/NeurIPS rule)
|
||||
4. **Vector graphics**: PDF/EPS for plots, PNG (600 DPI) only for photographs
|
||||
|
||||
### Accessibility Requirements
|
||||
|
||||
8% of men have color vision deficiency. Your figures must work for them.
|
||||
|
||||
**Solutions**:
|
||||
- Use colorblind-safe palettes: Okabe-Ito or Paul Tol
|
||||
- Avoid red-green combinations
|
||||
- Verify figures work in grayscale
|
||||
- Use different line styles (solid, dashed, dotted) in addition to colors
|
||||
|
||||
### Tools
|
||||
|
||||
```python
|
||||
# SciencePlots: Publication-ready styles
|
||||
import matplotlib.pyplot as plt
|
||||
plt.style.use(['science', 'ieee'])
|
||||
|
||||
# Or for Nature-style
|
||||
plt.style.use(['science', 'nature'])
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Mistakes to Avoid
|
||||
|
||||
### Structure Mistakes
|
||||
|
||||
| Mistake | Solution |
|
||||
|---------|----------|
|
||||
| Introduction too long (>1.5 pages) | Move background to Related Work |
|
||||
| Methods buried (after page 3) | Front-load contribution, cut intro |
|
||||
| Missing contribution bullets | Add 2-4 specific, falsifiable claims |
|
||||
| Experiments without explicit claims | State what each experiment tests |
|
||||
|
||||
### Writing Mistakes
|
||||
|
||||
| Mistake | Solution |
|
||||
|---------|----------|
|
||||
| Generic abstract opening | Start with your specific contribution |
|
||||
| Inconsistent terminology | Choose one term per concept |
|
||||
| Passive voice overuse | Use active voice: "We show" not "It is shown" |
|
||||
| Hedging everywhere | Be confident unless genuinely uncertain |
|
||||
|
||||
### Figure Mistakes
|
||||
|
||||
| Mistake | Solution |
|
||||
|---------|----------|
|
||||
| Raster graphics for plots | Use vector (PDF/EPS) |
|
||||
| Red-green color scheme | Use colorblind-safe palette |
|
||||
| Title inside figure | Put title in caption |
|
||||
| Captions require main text | Make captions self-contained |
|
||||
|
||||
### Citation Mistakes
|
||||
|
||||
| Mistake | Solution |
|
||||
|---------|----------|
|
||||
| Paper-by-paper Related Work | Organize methodologically |
|
||||
| Missing relevant citations | Reviewers authored papers—cite generously |
|
||||
| AI-generated citations | Always verify via APIs |
|
||||
| Inconsistent citation format | Use BibLaTeX with consistent keys |
|
||||
|
||||
---
|
||||
|
||||
## Pre-Submission Checklist
|
||||
|
||||
Before submitting, verify:
|
||||
|
||||
**Narrative**:
|
||||
- [ ] Can state contribution in one sentence
|
||||
- [ ] Three pillars (What/Why/So What) clear in intro
|
||||
- [ ] Every experiment supports a specific claim
|
||||
|
||||
**Structure**:
|
||||
- [ ] Abstract follows 5-sentence formula
|
||||
- [ ] Introduction ≤1.5 pages
|
||||
- [ ] Methods start by page 2-3
|
||||
- [ ] 2-4 contribution bullets included
|
||||
- [ ] Limitations section present
|
||||
|
||||
**Writing**:
|
||||
- [ ] Consistent terminology throughout
|
||||
- [ ] No generic opening sentences
|
||||
- [ ] Hedging removed unless necessary
|
||||
- [ ] All figures have self-contained captions
|
||||
|
||||
**Technical**:
|
||||
- [ ] All citations verified via API
|
||||
- [ ] Error bars included with methodology
|
||||
- [ ] Compute resources documented
|
||||
- [ ] Code/data availability stated
|
||||
Reference in New Issue
Block a user