RUNLOCALAIv38
->Will it run?Best GPUCompareTroubleshootStartLearnPulseModelsHardwareToolsBench
Run check
RUNLOCALAI

Independently operated catalog for local-AI hardware and software. Hand-written verdicts. Source-cited claims. Reproducible commands when we have them.

OP·Fredoline Eruo
DIR
  • Models
  • Hardware
  • Tools
  • Benchmarks
TOOLS
  • Will it run?
  • Compare hardware
  • Cost vs cloud
  • Choose my GPU
  • Prompting kits
  • Quick answers
REF
  • All buyer guides
  • Learn local AI
  • Methodology
  • Glossary
  • Errors KB
  • Trust
EDITOR
  • About
  • Author
  • How we make money
  • Editorial policy
  • Contact
LEGAL
  • Privacy
  • Terms
  • Sitemap
MAIL · MONTHLY DIGEST
Get monthly local AI changes
Monthly recap. No spam.
DISCLOSURE

Some links on this site are affiliate links (Amazon Associates and other first-class retailers). When you buy through them, we earn a small commission at no extra cost to you. Affiliate links do not influence our verdicts — there are cards we rate highly that we don't have affiliate relationships with, and cards that sell well that we refuse to recommend. Read more →

© 2026 runlocalai.coIndependently operated
RUNLOCALAI · v38
  1. >
  2. Home
  3. /Learn
  4. /Courses
  5. /Capstone: Research AI System
  6. /Ch. 11
Capstone: Research AI System

11. Technical Paper Writing

Chapter 11 of 18 · 15 min
KEY INSIGHT

A technical paper is a communication artifact, not a proof of work. The goal is helping readers understand what you built, why it matters, and how to evaluate it—efficiently. Writing for technical venues requires balancing precision with accessibility. Researchers reviewing your paper have limited time and many submissions to evaluate. Structure your writing so the core contribution is visible within the first two pages. ### Writing Principles for Systems Papers **Lead with the problem, not the solution.** Readers need to understand why anyone should care before investing time in understanding your approach. Start with a concrete pain point that practitioners face. **Quantify claims whenever possible.** "Our system is faster" is weak. "Our system processes queries at 2.3× the throughput of the baseline while maintaining equivalent accuracy" is strong. Specific numbers enable direct comparison. **Name your contributions explicitly.** Use numbered contributions: "We make the following contributions: (1) A novel approach to X that achieves Y... (2) An open-source implementation..." Reviewers look for this section first. ### Handling Uncertainty AI systems involve inherent variability. Write about performance honestly: ```python # Don't write: "Our system achieves top-performing performance." # Write: "Our system achieves 94.2% accuracy on the benchmark (baseline: 91.8%, std dev across 5 runs: ±0.6%). The improvement is statistically significant (p < 0.01, paired t-test)." # Don't write: "Our approach works well for most cases." # Write: "Our approach succeeds on 89% of test cases. The remaining 11% typically involve edge cases involving [specific characteristics]. We discuss limitations in Section 5." ``` ### Common Weaknesses in Systems Papers **Missing baselines** makes claims uninterpretable. Always compare against the current best approach and at least one simple alternative. **Missing ablation studies** makes it unclear which components matter. If you claim component X is essential, show performance without it. **Missing error analysis** wastes the opportunity to learn. Show specific examples where your system fails and analyze why. **Missing reproducibility information** frustrates readers and reviewers. Include model sizes, training durations, hyperparameters, and compute requirements. ### Revision Workflow Technical writing improves through iteration: 1. **First draft**: Get everything down, focus on content over polish 2. **Structure review**: Ensure logical flow, each section has clear purpose 3. **Sentence-level editing**: Cut unnecessary words, clarify ambiguous phrasing 4. **Technical review**: Verify all claims match experiments 5. **External review**: Have someone unfamiliar with the work read it

EXERCISE

Write a one-page summary of your research system covering: the problem addressed, your approach (in one paragraph), key results with specific numbers, and one limitation. Show it to a colleague unfamiliar with your work and ask them to explain back what you built. Note where they struggled or misunderstood.

← Chapter 10
Benchmarking
Chapter 12 →
Paper Structure