Academic Writing in AI: Summaries, Citations & Clear Papers

Section 1.1: What “academic” means: clarity, evidence, and traceability

Academic writing is writing that other people can check. In a blog post or marketing page, the writer often aims for speed, excitement, and a single takeaway. In academic work, the reader expects more: definitions, boundaries, and enough detail to evaluate whether a claim is supported. “Academic” does not mean long sentences or fancy vocabulary; it means clarity under scrutiny.

Three habits distinguish academic writing in AI. First is clarity: the reader should know what problem you address, what you did, and what happened. Second is evidence: you support claims with data, experiments, or citations to prior work. Third is traceability: a reader can follow the chain from a statement back to its source—either your method/results or a referenced paper.

Engineering judgment matters here. You rarely have space to include every detail, so you choose what a reasonable reader must know to interpret your results. Beginners often make two predictable mistakes: (1) summarizing conclusions without describing the conditions (dataset, metric, baseline), and (2) stating background facts without citations because they feel “common knowledge.” In AI, few facts are truly universal; be cautious and cite when the reader might reasonably ask, “Says who?”

• Practical outcome: write so that a skeptical peer could reproduce the reasoning, even if they cannot reproduce the exact experiment.
• Rule of thumb: if a sentence would be weaker when you remove numbers, conditions, or a citation, it probably needs one of them.

As you work through this course, treat writing as part of your research process, not a decoration at the end. The moment you read a paper or run an experiment, start recording what you learned and where it came from.

Section 1.2: AI research in plain words: models, data, and results

Most AI papers can be understood at a beginner level by translating them into three plain components: models, data, and results. The model is the system being proposed or tested (a transformer variant, a classifier, a diffusion model, a prompting method). The data is what the model learns from or is evaluated on (a benchmark dataset, synthetic data, a curated corpus). The results are the measured outcomes (accuracy, F1, BLEU, ROUGE, perplexity, human ratings, cost/latency).

When you skim a paper, try to name each component in one sentence. For example: “They fine-tune a pretrained model (model) on a medical question dataset (data) and report improved accuracy and calibration (results).” This is not a full summary; it is a map that keeps you oriented.

Scanning is different from skimming. Skimming finds the shape of the paper—what it is about. Scanning searches for specific items: dataset names, metrics, baselines, training budget, evaluation protocol, and failure cases. In AI, these details often determine whether a result is meaningful. A reported improvement might disappear if the baseline is weak, the test set overlaps with training data, or the metric does not match the task’s real goals.

• Practical outcome: build the habit of extracting “model/data/results” before you attempt paragraph-level summaries.
• Common mistake: repeating the paper’s motivation section as if it were the result. Motivation explains why a problem matters; results show what changed.

As you read, separate what the authors built (method) from what they observed (results). That separation will later help you paraphrase safely: you will describe the method in your own structure while keeping the meaning intact.

Section 1.3: Anatomy of a paper: abstract, intro, methods, results

Academic AI papers follow a recognizable structure. You do not need to read every word in order; you need to know what each part is for. A practical reading workflow starts by skimming the title, abstract, and figures/tables to understand the “headline” contribution. Then you use the remaining sections to check how well the contribution is supported.

The title and abstract should answer: What problem? What approach? What key result? The introduction expands the motivation and lists contributions, often in bullet form. The related work positions the paper among prior methods—useful for building citations and understanding baselines. The methods section is the recipe: model architecture, training procedure, prompts, hyperparameters, data preprocessing, and evaluation design. The results section reports metrics and comparisons. The discussion/analysis interprets results, explores errors, and acknowledges limitations. The conclusion summarizes what was achieved and what remains. Finally, references provide traceability: where ideas, datasets, and methods came from.

For beginner-level reading, do not aim for perfect comprehension on pass one. Use a two-pass approach: (1) skim to identify the central claim and the evidence types (experiments, ablations, human studies), then (2) scan methods and results for the conditions that make the claim trustworthy (datasets, metrics, baselines, and controls).

• Practical outcome: you can write a structured summary that mirrors the paper’s logic: problem → method → evaluation → findings → limits.
• Common mistake: summarizing only the abstract. Abstracts can oversell; methods and results reveal what actually happened.

When you later draft your own reports, this structure becomes a template. Even short assignments benefit from clear sections that signal to your reader where to find purpose, procedure, and proof.

Section 1.4: Claims and support: what counts as evidence

A core academic skill is separating claims, evidence, and opinions. A claim is a statement that could be true or false (“Method A improves robustness to noise”). Evidence is what supports it (experiments, statistics, comparisons, or citations). Opinion is a value judgment or interpretation (“This is a significant step forward”). Opinions are allowed, but they must be labeled and should not masquerade as results.

In AI writing, evidence often comes in specific forms: benchmark results, ablation studies (removing components to test impact), error analysis, significance testing, human evaluation protocols, and compute/cost measurements. Not all evidence is equally strong. For example, a single benchmark gain without a strong baseline or without controlling training data is weaker than a gain demonstrated across datasets, with ablations and clear evaluation.

Practice a simple tagging habit when taking notes: mark each sentence as C (claim), E (evidence), or O (opinion/interpretation). This reduces common mistakes in summaries, such as copying an author’s confident tone while omitting the conditions. It also helps you paraphrase safely: you will restate claims in neutral language and preserve the evidence trail via citations.

• Example (claim): “Our approach reduces hallucinations in long-form QA.”
• Example (evidence): “On Dataset X, hallucination rate drops from 18% to 11% using metric Y, averaged over n=500 prompts.”
• Example (opinion): “This makes the system reliable enough for deployment.”

Engineering judgment appears when deciding what you can responsibly conclude. If evidence is limited, write narrower claims (“on these datasets,” “under this setup,” “for this model size”). Overclaiming is not just bad style; it is a technical error because it misstates what the evidence supports.

Section 1.5: Your reader: audience, level, and expectations

Academic writing is always written to someone. Before you draft, define your reader and purpose. Are you writing for a classmate who knows basic ML but not your subfield? A reviewer who expects precise experimental detail? A manager who needs a careful summary with citations? The answer changes how much background you include, which terms you define, and how you justify your choices.

A practical way to set this is a one-minute self-check: write a single sentence that states (1) your topic, (2) your reader, and (3) your purpose. Example: “This paper summary explains how retrieval-augmented generation is evaluated to a beginner ML reader, so they can compare it to fine-tuning approaches.” That sentence becomes your filter: anything not serving it is likely noise.

Reader expectations in AI are often about specificity. A beginner may accept “we evaluate on standard benchmarks,” but an academic reader expects the benchmark names, splits, and metrics. Conversely, too much low-level detail can bury your point if your reader needs an overview. Good judgment is choosing the level that makes your work usable.

• Practical outcome: clearer summaries that separate main ideas (contribution, core result) from details (hyperparameters) and from your own opinions.
• Common mistake: writing as if the reader already agrees with you. Academic tone assumes the reader needs to be shown, not told.

As you move through the course outcomes—summarizing, paraphrasing, and citing—your reader definition keeps you consistent. You will know when to add a citation, when to define a term, and when a detail belongs in a footnote or appendix rather than the main text.

Section 1.6: Building a simple source log from day one

A source log is your safety net for accurate summaries and consistent citations. It is a simple table (spreadsheet, note app, or plain text) where you record what you read and what you used. Start it immediately—before you “need” it—because missing information is hardest to reconstruct later. In AI, you will often revisit a paper for a dataset detail, a metric definition, or a baseline configuration; the log prevents repeated searching.

Set up a basic writing workspace with a predictable folder structure. For example: /papers (PDFs), /notes (your reading notes), /drafts (your writing), and /bib (citation exports). Name files consistently (e.g., “2020_Brown_GPT3.pdf”) so you can locate them quickly. The goal is not perfection; it is reducing friction so you keep the habit.

Your source log should include, at minimum: full citation info (authors, year, title, venue), a link/DOI, what question the paper addresses, the key claim, the evidence type, and the exact pages/sections you relied on. Add a “Used in my draft?” column so you can separate background reading from cited sources. This directly supports APA/IEEE basics: when you later write in-text citations and a reference list, you will not guess at author order, year, or title formatting.

• Practical outcome: fewer citation errors and faster writing because you always know where an idea came from.
• Common mistake: copying quotes into notes without labeling them as quotes. In your log or notes, mark direct text clearly and prefer paraphrase summaries alongside it.

From day one, treat source tracking as part of writing. It supports traceability, makes paraphrasing safer, and lets you build credible academic papers that a reader can verify and learn from.

The fastest way to get oriented is a 3-pass method. It maps directly to a 10-minute plan: skim (2 minutes), scan (3 minutes), and zoom (5 minutes). This keeps you from getting trapped in equations or unfamiliar jargon before you know whether the paper is even relevant.

Pass 1 — Skim (structure and promise). Read the title, abstract, section headings, and conclusion. Look at the first figure and the main results table. Your output is one sentence: “This paper claims X by doing Y, achieving Z.” If you cannot write that sentence, the paper is either poorly written or you haven’t found the core yet—don’t start deep reading until you have it.

Pass 2 — Scan (evidence and ingredients). Now scan for what you will need to judge credibility: datasets, baselines, metrics, and ablations. Read figure captions and table headers. Locate the method diagram. Your output is a quick checklist: what data, what comparison, what metric, what main result. This is also where you start spotting warning signs: only one dataset, unclear baselines, or results without error bars or variance reporting.

Pass 3 — Zoom (one narrow slice). Choose one section to read carefully based on your goal. If you are writing a literature review, zoom into the method and results. If you are implementing, zoom into the experimental setup and hyperparameters. If you are summarizing, zoom into the problem statement and contributions. In this pass, highlight only what you can paraphrase accurately later: the research question, the approach, and the key result.

• Common mistake: reading linearly from page 1 and getting stuck on background. Fix: always skim first; background is optional until you confirm relevance.
• Practical outcome: in 10 minutes you should be able to decide “use, maybe, or skip,” and record enough to cite the paper correctly later.

Abstracts are designed to persuade you that the paper matters. They often contain the most compressed form of the “sales pitch,” so your job is to extract facts while resisting hype. A beginner-friendly technique is to annotate the abstract with four labels: Problem, Approach, Result, and Scope/Setting.

As you read, underline phrases that answer these questions:

• What is the research question? (e.g., “Can we improve robustness to distribution shift?”)
• What is the approach? (model type, training trick, architecture change, or algorithmic idea)
• What is the key result? (numbers, datasets, comparisons; “outperforms” alone is not enough)
• Where does it apply? (task, dataset, language, modality, constraints)

Now apply skepticism. Watch for warning patterns: “state-of-the-art” without naming the benchmark; “significant improvement” without an actual delta; “generalizes well” without describing evaluation settings; or claims of broad impact from narrow experiments. Abstracts also commonly omit failure cases, compute costs, and limitations—items that matter for engineering decisions and fair academic summaries.

When you write a summary, separate what the paper claims from what the paper shows. For example, you can safely paraphrase: “The authors propose a method for X and report improvements on Y benchmark,” but avoid strengthening it into “This method is better” unless you specify the context and evidence. This habit reduces accidental distortion and makes your writing easier to cite accurately.

In AI papers, the real story is often told in figures and tables. A practical reading move is to treat each figure/table as a mini-argument: it makes a claim, supported by measured evidence, under a specific setup. Your job is to translate that into plain language and capture the conditions.

Start with the caption and axes. For plots, identify what is on the x-axis (often compute, data size, steps, noise level) and y-axis (accuracy, F1, BLEU, loss, error rate). Then ask: does “higher” mean better? Not always—error rates and perplexity are lower-is-better. For tables, read column headers as constraints: dataset name, metric, baseline models, and sometimes resource budgets.

Translate metrics into meaning. Accuracy is “percent correct,” but can hide class imbalance. F1 balances precision and recall. BLEU/ROUGE are overlap-based measures and may not reflect factuality. Perplexity is a language modeling proxy, not a direct measure of usefulness. In your notes, write a short interpretation: “Metric M here reflects ____; it can miss ____.” This is how you show judgment without doing deep math.

Look for comparisons that matter. A strong results table includes: (1) competitive baselines, (2) a clear main metric, and (3) enough information to replicate. Weak evidence often looks like cherry-picked baselines, missing variance, or unclear evaluation protocol. Another warning sign is a table with many bold numbers but no explanation of what changed between rows (e.g., different data, different compute, different tuning). If you cannot tell what is controlled, you cannot trust the comparison.

• Practical outcome: for each main table/figure, write one “claim-evidence” sentence: “Under setting S, method A improves metric M by Δ over baseline B.” That sentence becomes summary-ready and citation-ready.

You can extract a meaningful understanding of most AI methods without following every equation. Focus on the method as a pipeline: inputs → transformation → learning signal → output. Read the method section looking for the “moving parts” and what is actually new.

Method questions to answer (no math required):

• What is the model family? (transformer, CNN, diffusion model, graph neural network, retrieval-augmented model)
• What is the training objective? (classification loss, contrastive loss, likelihood, reinforcement learning reward)
• What is the key modification? (new architecture block, new loss term, data augmentation, sampling strategy, prompting scheme)
• What is the compute story? (training steps, parameters, hardware, inference cost)

Dataset literacy matters as much as model literacy. For each dataset, record: domain (medical, web, code), size, labeling source, language(s), and known biases. A model that “beats SOTA” on a small, curated dataset may not transfer to messy real-world data. Also watch for data leakage risk: if the dataset overlaps with pretraining corpora or includes test contamination, results can be inflated.

Spot missing details early. Common weak points include unspecified preprocessing, undisclosed hyperparameter tuning, or vague baseline implementation (“we follow prior work”). If you plan to cite the paper as evidence, missing details reduce how strongly you should word your summary. A careful writer uses calibrated language: “The paper reports…” rather than “The method guarantees…”

Practical outcome: after scanning methods and datasets, you should be able to write a three-line description: “They train model X on data Y using objective Z, and the novelty is N.” This is enough for a beginner-level literature map and a safe paraphrase.

Limitations sections are not filler; they are where authors quietly state the boundaries of their claims. If you only read one “non-results” part carefully, read limitations (and sometimes ethical considerations). This is where you learn what the method fails at, what assumptions it relies on, and what evidence is missing.

What to extract:

• Scope limits: which tasks, domains, languages, or modalities were not tested?
• Resource limits: heavy compute, large memory, slow inference, expensive labeling.
• Evaluation gaps: lack of robustness testing, missing human evaluation, no out-of-domain results.
• Risk factors: bias, privacy issues, harmful outputs, misuse potential.

Future work can also reveal what the authors believe is unresolved. If they say “we plan to evaluate on larger datasets,” that implies current evidence may be narrow. If they say “we will explore ablations,” that implies the causal story (what component caused the improvement) may be incomplete.

For academic writing, limitations help you summarize responsibly. They allow you to separate the core contribution from the conditions under which it holds. They also prevent over-citation—using a paper as universal proof when it only supports a limited claim. In engineering terms, limitations are your compatibility notes and known failure modes.

Practical outcome: add one “boundary sentence” to your notes, such as: “Evidence is limited to datasets A and B; performance under distribution shift is not evaluated.” This makes your later summaries more accurate and defensible.

Good notes are reusable: they support summaries, safe paraphrases, and correct citations. The key is to record both what the paper says and where it says it (page/section/figure), so you can cite later without scrambling. Use a simple source log alongside your notes: authors, year, title, venue, link/DOI, and a one-line relevance tag.

Three beginner-friendly formats:

• Bullets (fast): best for the 10-minute read. Use 6–10 bullets: problem, approach, data, baselines, metric, key result, limitation. Add “(Abstract)” or “(Fig. 2)” to each bullet to anchor it.
• Q&A (clarity): write questions you need answered: “What baseline did they compare to?” “What does ‘robust’ mean here?” Then fill answers as you find them. This prevents passive reading and highlights missing details.
• Claim–Evidence (citation-ready): format each important point as: Claim: … Evidence: dataset/metric/result … Conditions: evaluation setup … Location: section/figure/table.

Practice: turn one paper’s abstract into bullet-point notes. Copy the abstract into your notes, then rewrite it into 6 bullets: (1) research question, (2) approach in one line, (3) what is new, (4) evaluation setting (datasets/tasks), (5) key numeric result with metric, (6) stated limitation or implied boundary. Keep your language neutral (“reports,” “proposes,” “evaluates”) and avoid copying distinctive phrases. This makes paraphrasing safer while preserving meaning.

Common mistake: mixing your opinion into factual notes (e.g., “great method,” “obviously better”). Fix: separate a “My take” subsection from “Paper claims/results,” so your later summaries remain objective and easy to cite in APA/IEEE styles.

Practical outcome: after one reading session, you should have (1) a source log entry, (2) a set of bullets you can paraphrase into a summary paragraph, and (3) at least two claim–evidence notes that can become properly cited sentences in a paper.

A strong academic summary answers three questions quickly: (1) What problem does the paper address? (2) What approach does it use? (3) What result does it report? If you can cover those in one paragraph, you have the backbone of a reliable summary. In AI papers, “approach” might be a model architecture, a training objective, a dataset strategy, or an evaluation setup. “Result” should be concrete: performance changes, robustness findings, efficiency gains, or qualitative outcomes, ideally with the evaluation context (task, dataset, metric).

Equally important is what you leave out. A summary is not a literature review, not a critique, and not a methods section rewrite. Avoid long lists of hyperparameters, full dataset descriptions, or every baseline comparison. Those details matter, but they belong in notes, not in a short summary. Your summary also should not include your opinions (“This is groundbreaking,” “This seems flawed”) unless the assignment explicitly asks for critique. Keep the summary descriptive first; evaluation can come later in a separate paragraph.

• Include: problem context, the paper’s main contribution, the approach at a high level, key evaluation setting, and the main finding.
• Leave out: minor implementation details, exhaustive related work, unsupported speculation, and your personal reactions.
• Check for completeness: if a reader asked “So what?” your summary should already contain the paper’s stated answer.

A practical workflow is to draft a “problem–method–result” paragraph first, then verify each sentence against the source. For every sentence, you should be able to point to a section, table, or figure that supports it. If you cannot, either add a citation note for later verification or remove/rewrite the sentence.

When you need more structure than a single paragraph, use a template. Templates reduce the chance that you forget an essential element (a common beginner issue) and help you produce consistent summaries across multiple papers. A useful pattern for AI research is “problem–approach–result–impact.” The first three map to the core of scientific reporting; the last one forces you to state why the result matters without adding hype.

Here is a practical abstract-style template you can fill in from your notes:

• Problem: The paper addresses [task/setting] where [limitation or gap] makes current methods insufficient.
• Approach: The authors propose [method name/type], which [one-sentence mechanism or key idea], and evaluate it on [datasets/tasks] using [metrics/baselines].
• Result: The method achieves [main quantitative/qualitative outcomes] compared to [baseline], with notable findings such as [one secondary result if truly central].
• Impact: These results suggest [practical or research implication stated by the authors], particularly for [who/what context], while [constraints or scope if the paper emphasizes them].

Use the template as a drafting scaffold, then compress it. In many cases, you can merge “impact” into the final sentence of the paragraph. The engineering judgment is deciding what counts as “impact” without inventing implications. A safe rule: phrase impact in terms of what the authors claim or what the results directly support (“suggests,” “indicates,” “shows”), and avoid broad predictions (“will revolutionize”).

This template also supports consistent citation later. If you later write a related-work paragraph, you can reuse the same four elements in shorter form and attach an in-text citation to the claim you are summarizing.

Many summaries fail because they treat the paper like a sequence of equal facts. Academic writing is hierarchical: one main contribution is supported by several arguments and experiments. Your summary should reflect that hierarchy. Start by identifying the paper’s “one-sentence claim”: what does the paper want the reader to believe or accept by the end? Often this appears in the introduction, contributions list, or conclusion.

Next, separate key ideas from supporting details. Key ideas usually include: the task definition, the novelty (what is new compared to prior work), and the primary result that validates the novelty. Supporting details include: additional ablations, secondary datasets, implementation choices, and extended discussion. Supporting details matter for credibility, but they should only appear in a summary if they change the interpretation of the main result (for example, “improves accuracy but increases compute cost significantly,” if that trade-off is central).

• Technique: write a 5-bullet note list: (1) problem, (2) contribution, (3) method idea, (4) main evaluation, (5) main conclusion. Then convert those bullets into 3–5 sentences.
• Compression rule: if two details serve the same purpose (e.g., two similar datasets), mention only one and generalize (“across standard benchmarks”).
• Accuracy rule: do not generalize beyond what is tested. If results are on one dataset, say so.

This skill is essential when you practice producing a 150-word summary from your notes. With only 150 words, you cannot “fit everything,” so your ability to rank importance becomes the difference between an informative summary and a misleading one.

Clarity is not “dumbing down.” It is removing avoidable friction so a reader can focus on the ideas. Beginner academic writing often suffers from long sentences, undefined terms, and vague verbs (“improves,” “handles,” “addresses”) without specifying how. Your goal is to write shorter sentences that carry one main idea each, while still using precise technical vocabulary.

Start with sentence structure. Prefer: subject → verb → object. For example, instead of “A novel approach is presented for the improvement of robustness,” write “The authors propose a method to improve robustness.” Then add the necessary specificity: “...against distribution shift on image classification benchmarks.” This style keeps technical content while making the grammar easy to parse.

• Define terms once: if you introduce an acronym or specialized term, define it the first time (“reinforcement learning (RL)”).
• Use measurable language: replace “better” with “higher F1,” “lower error,” “reduced latency,” or “improved calibration.”
• Limit clause stacking: if a sentence has more than one “which/that/while,” consider splitting it.
• Maintain logical flow: problem → approach → evaluation → result. Do not jump directly to numbers before the reader knows the setup.

Clarity also supports safe paraphrasing. When you rewrite in your own words, you reduce the risk of copying the source’s sentence structure. A good paraphrase preserves meaning and constraints (dataset, metric, scope) while changing wording and grammar. If you find yourself keeping many of the same phrases, step back and restate the idea from your notes rather than the paper’s prose.

A summary should sound like reporting, not debating. Neutral voice does not mean “boring”; it means your statements are anchored to what the paper claims and shows. The fastest way to introduce inaccuracy is to add evaluation disguised as description (“The authors cleverly solve…”), or to overstate conclusions (“proves,” “guarantees”) when the evidence is limited.

Use attribution and evidence verbs that match the strength of the paper’s support. Common choices: “proposes,” “introduces,” “evaluates,” “reports,” “finds,” “shows,” “suggests.” Avoid “demonstrates” unless the paper truly provides strong evidence; avoid “proves” in empirical ML contexts. When the paper is uncertain, mirror that uncertainty (“the authors hypothesize,” “the results indicate”).

• Separate summary from critique: if you need to evaluate, add a clearly labeled second paragraph later (e.g., “Limitations:”); do not blend it into the summary.
• Avoid opinion adjectives: “important,” “novel,” “promising,” unless the paper explicitly argues for those terms and you attribute them (“The authors claim the method is novel because…”).
• Do not invent motivations: if the paper does not state why something was chosen, do not guess.

Neutral writing also makes citations cleaner. When you later add an in-text citation, it should attach to a descriptive claim about the source, not to your personal stance. This keeps your literature use transparent and reduces the chance of misrepresenting an author’s position.

Revision is where summaries become reliable. Draft quickly using the templates, then revise with a checklist that focuses on accuracy, clarity, and scope. This is especially important for the practical task of producing a 150-word summary from your notes: the word limit forces tough cuts, so you must confirm that what remains is both true and representative.

• Main point present: Does the first (or second) sentence state the paper’s problem and main contribution?
• Problem–method–result covered: Can you underline a phrase for each? If any are missing, add them before polishing style.
• Evidence aligned: For each numeric or comparative claim, do you have the dataset/metric/baseline context correct?
• No opinion leakage: Remove words like “clearly,” “obviously,” “excellent,” unless directly attributed and necessary.
• Defined terms: Are key acronyms defined once, and are specialized terms used consistently?
• Sentence length: Split any sentence that tries to do two jobs (e.g., method description plus results plus implications).
• Scope is accurate: If the paper tests only one setting, your summary should not imply general performance.
• Word budget: In 150 words, keep one main result and one key context detail; move extra details back to notes.

A practical finishing move is the “trace-back pass.” Read your summary and, for each sentence, ask: “Where is this in the paper?” If you cannot point to a section, table, or figure, revise. This habit trains you to summarize from evidence rather than impression—exactly what academic writing in AI demands.

Plagiarism, in plain terms, is presenting someone else’s words, ideas, data, or structure as if you created them. Many students only think of “copying sentences,” but plagiarism also includes copying distinctive phrasing with minor edits, copying the organization of an argument too closely, or reusing an image/table without attribution. In AI writing, it can also include reusing evaluation wording, dataset descriptions, or model architecture explanations from a paper or documentation without indicating the source.

Accidental plagiarism is common and usually comes from workflow errors rather than intent. Typical causes include: copying a sentence into notes “temporarily” and later pasting it into a draft; losing track of which phrases came from the paper; mixing your own commentary with source text in the same paragraph; or paraphrasing by swapping a few words while keeping the original sentence structure. If you cannot reconstruct where a claim came from, you cannot cite it reliably—and that is a warning sign.

What plagiarism is not: using common knowledge in the field (e.g., “gradient descent is used to optimize neural networks”); using standard terminology (e.g., “precision, recall, F1”); or independently arriving at an idea that is genuinely yours. Still, even common knowledge can become “source-specific” if you rely on a particular paper’s framing or if you are repeating a paper’s unique classification, taxonomy, or set of design principles. When in doubt, cite. Citations are cheap; credibility is not.

Practical outcome: you should be able to point to any technical statement in your draft and answer two questions: (1) Did I observe/derive this myself, or did I learn it from a source? (2) If it came from a source, is the relationship clear—quote, paraphrase, or summary—plus a citation?

Safe paraphrasing starts with meaning. If you keep the original text in front of you and “rewrite,” you will almost certainly echo the structure and key phrases. Instead, use a step-by-step method that forces comprehension before wording.

• Step 1: Read once for gist. Ask: What claim is being made? What evidence supports it? What conditions or limitations are stated?
• Step 2: Close the source. Literally minimize the PDF or switch tabs away.
• Step 3: Write a one-sentence meaning statement. Use your own language, aiming for the core idea only.
• Step 4: Add required technical details. Numbers, dataset names, metrics, assumptions, and constraints should be preserved accurately.
• Step 5: Re-open and verify. Check for missing qualifiers (e.g., “on this dataset,” “under these settings”), and confirm you did not change the claim.
• Step 6: Cite immediately. Attach an in-text citation right after the paraphrase, not later.

Engineering judgment matters most in Step 4. You decide what details are necessary for your purpose. If you are writing a background section, you may paraphrase at a higher level (“The authors report improved robustness under distribution shift”). If you are writing a methods comparison, you may need the exact setting (“robustness evaluated via corruption benchmarks at severity levels 1–5”). The safer your paraphrase is, the more it preserves constraints and avoids overclaiming.

Common mistakes: removing hedging words (turning “may improve” into “improves”), changing the scope (turning “for image classification” into “for computer vision”), or keeping the original sentence skeleton. A safe paraphrase can reuse necessary technical terms, but it should not reuse distinctive phrasing or mirrored clause order.

Summary, paraphrase, and quotation are three different tools. Choosing the right one reduces plagiarism risk and improves clarity.

Summarize when you need the high-level point and not the mechanics. A summary compresses multiple parts of a source (or multiple sources) into a shorter statement in your own words. In AI writing, you might summarize a paper’s contribution in one or two sentences as part of a related-work paragraph. A summary should not contain long strings of the author’s original phrasing; it should reflect your understanding of the key message.

Paraphrase when a specific idea is important but you do not need the exact wording. Paraphrasing keeps the original meaning at roughly similar detail level while changing the expression. This is the default choice for explaining methods, results, and limitations, because it integrates the information into your paper’s voice and structure.

Quote when exact wording matters. In technical writing, quotations are less common than in humanities, but they are appropriate for: formal definitions (“fairness” definitions, problem statements), policy or ethical claims where wording is legally or socially loaded, or when you are analyzing the authors’ phrasing itself. If you quote, make it unmistakable: quotation marks (or block quote for longer passages) plus an in-text citation with a page/section pointer. Avoid “quote dumping”: do not paste a large quote without explaining why it matters and what you want the reader to learn from it.

Practical labeling habit: if you are close enough to the source that your sentence could be aligned phrase-by-phrase, you are likely paraphrasing (and must cite). If you preserve exact words, you are quoting (and must mark with quotation formatting). If you compress multiple ideas or multiple paragraphs, you are summarizing (and must cite). The distinction is about your relationship to the source, not about whether you “changed enough words.”

Patchwriting is the most common “gray zone” problem in student drafts: you copy a sentence or two and then change a few words, swap synonyms, or adjust grammar while keeping the original structure. It may feel like paraphrasing, but it is too close to the source to be considered original writing. Even with a citation, patchwriting is risky because it can still be judged as copying, and it often signals shallow understanding.

You can detect patchwriting by doing a structure check. Compare your sentence to the source: do the clauses appear in the same order? Are the same rare adjectives or metaphors present? Do you have the same sequence of “because… therefore… however…” moves? If yes, you are patchwriting.

Fixes are practical and repeatable:

• Re-paraphrase from memory: Close the source and rewrite the idea as if explaining it to a peer. This forces a new sentence structure.
• Change the unit of writing: Instead of rewriting one sentence, rewrite the whole paragraph’s idea flow. Patchwriting often happens when you paraphrase sentence-by-sentence.
• Anchor on your purpose: Ask what role the source plays in your argument (supporting evidence, contrast, definition). Then write that role first, and insert the sourced idea where it serves your point.
• Quote selectively if wording is essential: If a phrase is genuinely distinctive and important, quote just that phrase and paraphrase the rest.

Also watch for “technical patchwriting”: copying a method description but swapping a few verbs. For model architectures or algorithm steps, you can reuse standard terms, but you should express the workflow in your own sentence logic and include the citation. The goal is not to hide the source; it is to show you understand it and can integrate it responsibly.

Citations are most useful when they are traceable. A traceable citation lets a reader (or your future self) find the supporting passage quickly. This matters in AI because claims can be sensitive to experimental setup: the difference between a main result and an ablation, or between validation and test performance, may be one table away.

Build a lightweight source log while reading. For each source, record: full reference info (enough for APA/IEEE later), a stable identifier (PDF filename or DOI), and a set of pinpoint locators. Use page numbers for PDFs with stable pagination, section headings for web pages or arXiv HTML, and timestamps for talks/videos. Your notes should store both the locator and the content type (quote, paraphrase note, or summary note).

• Example locator formats: “p. 4, Sec. 3.2, Table 1”; “Sec. 2 ‘Method’, para 3”; “00:12:48–00:13:20”.
• Note labeling: Prefix with Q: for direct quotes (verbatim), P: for paraphrase-ready notes (your words), S: for summary bullets (high-level).

This tracking habit prevents accidental plagiarism because it keeps source boundaries visible. It also improves technical accuracy: when you draft a claim about results, you can verify whether it was the best run, an average over seeds, or a single cherry-picked configuration. Practical outcome: you should be able to click or open a source and re-locate the supporting passage within 30–60 seconds.

A reliable way to avoid copy-paste plagiarism is to separate reading, note-making, and drafting into distinct stages. When these stages blur, you end up writing with the source open, copying phrasing unconsciously, and forgetting which lines are yours.

Use this source-to-draft workflow:

• 1) Read and log: Skim the paper, then scan for the passages you need. In your source log, capture locator info and write either Q-notes (verbatim with quotation marks) or P-notes (your own words). Never store unmarked copied text.
• 2) Create “draftable” notes: For each paragraph you plan to write, assemble 2–4 P-notes and one sentence of your own synthesis (what you will argue or explain). This forces you to integrate rather than transcribe.
• 3) Draft with notes, not with PDFs: Write from your P-notes and synthesis sentence. Open the PDF only to verify a detail, not to generate sentences.
• 4) Cite as you write: Insert the in-text citation immediately after the sentence/paragraph it supports. Do not leave “add citation later” placeholders unless you track them rigorously.
• 5) Run a boundary check: Before submitting, highlight any sentence that contains numbers, dataset names, or specific claims. Confirm each has either (a) a citation, (b) your own experiment reference, or (c) is common knowledge.

This routine also supports the skill of labeling writing moves. In your notes and draft, you should be able to identify: summary sentences (compressed, high-level), paraphrases (same idea, similar detail, new wording), and quotes (exact words, clearly marked). The practical outcome is a draft that is both safer and easier to revise: when feedback arrives, you can quickly trace each claim back to its source and adjust meaning, detail level, or citation style without re-reading everything from scratch.

Section 5.1: What a citation does: credit and verification

A citation is a labeled pointer from your sentence to a specific source. In academic AI writing, that pointer carries three kinds of meaning. First, it gives credit: you signal which ideas, methods, datasets, or results are not originally yours. Second, it supports verification: readers can inspect the original context, check if you interpreted it fairly, and evaluate the strength of evidence. Third, it creates traceability: other researchers can reproduce your reading path, follow a method, or locate an implementation detail.

Use citations as “evidence tags.” If you write, “Transformers outperform recurrent models on long-range dependencies,” you are making an empirical claim that should be tied to a paper (or multiple papers). If you write, “In this project, we prioritize latency over peak accuracy,” that is a design decision and usually does not need a citation—unless you are adopting a standard framework or definition.

• When to cite: claims of fact, reported results, definitions you did not invent, datasets/tools you used, and quotations.
• When not to cite: common knowledge in your field (careful for beginners), your own results, or purely logistical statements.
• What to cite: the most authoritative and direct source (e.g., the original paper for a method, not a blog summary).

Engineering judgment matters: over-citing makes your writing choppy, and under-citing makes it untrustworthy. A practical rule is: if removing the citation would make the reader ask “how do you know that?”, you probably need it. And if you read a secondary source, try to follow its references and cite the primary paper instead.

Section 5.2: In-text citations: APA-style basics (author, year)

Author-date citations (often associated with APA) are common in many interdisciplinary areas because they are readable: the reader immediately sees who wrote the work and when. The basic patterns are simple, and you can apply them without memorizing dozens of edge cases.

Parenthetical form places the citation at the end of a clause or sentence: “Self-attention enables parallelization during training (Vaswani et al., 2017).” Narrative form makes the author part of the sentence: “Vaswani et al. (2017) introduce the Transformer architecture…” Both are acceptable; choose based on flow. Use narrative form when the authors are important to your story (e.g., comparing approaches), and parenthetical form when the citation is just support.

• One author: (Ng, 2020) or Ng (2020).
• Two authors: (Smith & Lee, 2021) or Smith and Lee (2021).
• Three+ authors: (Chen et al., 2022) after the first mention in many simplified academic contexts; some strict styles vary, but consistency is the key skill here.

Place citations as close as possible to the claim they support. If one sentence contains two claims from two different papers, split the sentence or cite both sources precisely. Avoid the common beginner move of “citation dumping” at the end of a paragraph; readers can’t tell which statement came from where.

If you are paraphrasing, the citation still goes with the paraphrase. A citation does not replace good paraphrasing: you must change structure and wording while preserving meaning. If you reuse distinctive phrasing, you are effectively quoting—use quotation marks and cite the page or section if available.

Section 5.3: Numbered citations: IEEE-style basics

Numbered systems (often associated with IEEE) use bracketed numbers like [1], [2] that point to the reference list. They are compact and widely used in engineering and computer science venues, including many AI conferences. The trade-off is that the in-text citation is less informative by itself—you must look at the reference list to see authors and year.

The core rule: numbers correspond to entries in the reference list, and you typically number sources in the order they first appear in the paper. Once a source is [3], it stays [3] throughout. Example: “Transformers scale effectively with data and compute [1].” If you refer to the same paper later, you reuse [1].

• Single source: “…as shown in [4].”
• Multiple sources: “…supported by prior work [2], [5], [7].” (or a range like [2]–[4] if consecutive and your venue allows it).
• Author in text: you can still name the author: “In [6], Brown et al. report…” but the formal link is the number.

A practical workflow tip: numbered styles are unforgiving if you manually reorder paragraphs. If you insert a new citation early in the paper, every later number might change. This is one reason reference managers are so useful (Section 5.5). If you must manage numbers by hand (e.g., short assignments), finalize structure first, then assign numbers, then do a final pass to ensure every bracketed number maps to the right entry.

Common mistake: mixing systems. Do not write “(Vaswani et al., 2017) [12]” unless a specific style guide requires dual citations (rare). Pick one system per document and apply it consistently.

Section 5.4: Reference list essentials: authors, title, venue, year, DOI

Your reference list is the “address book” that makes in-text citations retrievable. Regardless of APA or IEEE formatting details, strong reference entries share the same essential metadata: authors, year, title, venue (journal or conference), and a stable locator such as a DOI (preferred) or a reliable URL.

When you have a DOI, treat it like a durable identifier. A DOI is usually more stable than a random PDF link. A practical method for building an entry is:

• Start from the paper’s first page (or publisher page) and capture: full author list (in order), exact title capitalization (as shown), venue name, year, and DOI.
• If you only have an arXiv URL, record the arXiv identifier and version if relevant (e.g., v2), and keep the stable abstract page link rather than a local PDF file path.
• For web resources (tool docs, datasets), record the organization/author, page title, year (or “n.d.” if none), and an access date if your style requires it.

Be careful with “paper metadata drift.” Google Scholar and random BibTeX exports sometimes contain errors: missing conference names, wrong years (online first vs. print), or truncated author lists. For important sources, verify metadata against the publisher page, ACL Anthology, IEEE Xplore, ACM DL, or the PDF itself.

Finally, ensure the reference list and in-text citations are a two-way match: every cited source appears once in the reference list, and every reference list entry is cited somewhere in the text. Uncited references look like padding; missing references look like sloppiness.

Section 5.5: Using reference managers at a beginner level (Zotero/Mendeley concepts)

Reference managers (such as Zotero or Mendeley) are not just “formatting tools.” They are small databases for your research reading. As a beginner, focus on three capabilities: (1) capturing metadata correctly, (2) inserting citations into your document in a chosen style, and (3) keeping a clean, searchable library that supports your source log.

Capture workflow: install the browser connector, then when you land on a publisher page or arXiv abstract page, save the item to your library. Immediately check the fields: author names, year, title, venue, DOI, URL. Fix obvious issues now; errors compound later when you generate the reference list.

• Attachments: store the PDF as an attachment, but do not rely on the PDF filename as “metadata.”
• Notes: add a short note: what claim you plan to cite it for, and which section/figure mattered.
• Tags/collections: group items by topic (e.g., “LLM evaluation,” “alignment,” “retrieval”).

Writing workflow: pick a style early (APA-like author-date or IEEE-like numbered). Insert citations as you write, not at the end. This prevents the common problem of losing track of which claim came from which source. When you revise and reorder paragraphs, the manager updates author-year parentheses or renumbers IEEE citations automatically.

Beginner warning: a reference manager produces consistent formatting, but it cannot guarantee correctness if the underlying metadata is wrong. Treat the manager as an assistant, not an authority. For final submission, spot-check your most important references against the original pages.

Section 5.6: Citation quality check: consistency, completeness, and retrievability

Before you submit any AI-related assignment, run a quick citation quality check. This is a practical routine that catches most citation errors: missing authors, broken links, inconsistent style, and mismatches between in-text citations and references. Think of it as a lint pass for academic writing.

• Consistency: Are you using exactly one system (APA-like author-date or IEEE-like numbered) throughout? Are punctuation and spacing consistent (e.g., “et al.” formatting, bracket style, comma placement)?
• Completeness: For each reference entry, do you have authors, year, title, venue, and DOI/URL? For each in-text citation, is there a matching reference entry?
• Retrievability: Can a reader find the source in under a minute? Click every URL. Prefer DOI links or stable landing pages over temporary PDF links.

Now do a small practice run as part of your workflow (not a separate test): pick three sources you actually used while reading—e.g., one journal/conference paper with a DOI, one arXiv preprint, and one software or dataset webpage. Create a mini reference list in your chosen style and insert one in-text citation for each into a short paragraph of your own writing. As you do this, watch for common traps: inconsistent author initials, missing venues (“just a title and link”), and accidental mixing of APA and IEEE conventions.

Finally, update your source log. For each of the three sources, record: full citation, what you used it for (one sentence), and where it appears in your draft (section/paragraph). This habit turns citation work from a last-minute formatting scramble into a reliable research practice—and it makes your future self grateful when you revise or expand the paper.

Section 6.1: What a literature review is: mapping what’s known

A literature review is not a book report. Its purpose is to map what is known about a question, how researchers know it, and what remains uncertain. Even a mini review should do three things: (1) define the question and scope, (2) synthesize what the sources collectively show, and (3) identify gaps or tensions that motivate further work. In AI topics, this often includes clarifying what “performance” means (accuracy, robustness, fairness), what data conditions apply, and what evaluation settings are comparable.

Think of your review as a small “research briefing.” Readers should finish with a structured understanding: which approaches exist, which assumptions they rely on, and what trade-offs appear. This is why your writing must separate claims (what authors conclude), evidence (what experiments or analyses support those conclusions), and limitations (what the study does not establish). You will frequently use verbs that signal evidence strength, such as “reports,” “finds,” “suggests,” or “demonstrates,” rather than overstating.

To keep yourself honest, maintain a lightweight source log. For each source, record: full citation details, one-sentence takeaway, key method/dataset, two notable results, and one limitation. Add the page/section number (or figure/table) for anything you might cite. This practice prevents “summary drift,” where your memory gradually replaces what the paper actually said.

• Common mistake: writing paper-by-paper summaries with no synthesis.
• Practical outcome: a reader can see the landscape and your rationale for how the sources connect.

Section 6.2: Choosing and narrowing a question you can finish

Your mini review must be finishable with 2–3 sources, which means your question must be narrow and operational. Avoid questions like “How does AI impact society?” Instead, choose a question that can be answered by comparing a small set of approaches, evaluations, or claims. A good pattern is: In a specific setting, how do two approaches compare on a specific criterion? Examples: “How do two methods for detecting dataset shift differ in assumptions and evaluation?” or “What evidence exists that prompt-based methods improve few-shot classification on benchmark X?”

Define scope boundaries up front. Specify: (1) the application area (e.g., medical imaging, text classification), (2) the technique family (e.g., transformers, retrieval-augmented generation), (3) the evaluation focus (e.g., robustness, interpretability, fairness), and (4) what is excluded (e.g., “not covering deployment policy or legal analysis”). These boundaries are not a weakness—they are responsible academic practice.

Use a two-pass reading plan. First pass: skim abstracts, introductions, and conclusions to confirm relevance. Second pass: scan methods and results for what you will actually cite. If you cannot find at least two comparable points across sources (same metric, similar dataset, or comparable claim type), your question is still too broad or too mismatched.

• Mini deliverable: a 2–3 sentence problem statement plus a bullet list of inclusion criteria for sources.
• Common mistake: selecting “famous” papers that don’t answer the same question, making comparison impossible.

Section 6.3: Synthesis writing: grouping sources by themes, not by paper

Synthesis is the core skill of literature review writing. Instead of narrating “Paper A says…, Paper B says…,” you organize by themes that answer your question. With only 2–3 sources, your themes might be simple: assumptions, data and evaluation, results, and limitations. The key is that each paragraph should have a controlling idea (a theme claim), followed by evidence from multiple sources.

A practical method is to build a small synthesis matrix. Make rows as themes and columns as sources. Fill each cell with a short note and a quote-free paraphrase of the relevant point (plus page/section). When you draft, each paragraph draws across a row (theme) rather than down a column (paper). This keeps your writing comparative by default.

When summarizing, separate main ideas from details. Main ideas are the claims that would still matter if the dataset changed; details are specific hyperparameters, training durations, or minor ablations. You may include details only when they explain a difference between findings (e.g., one paper’s evaluation uses synthetic noise while another uses real-world shift). Use citations whenever you report a study’s specific claim, method choice, or numerical result.

• Common mistake: copying sentence structure while “paraphrasing.” Instead, change both wording and structure, and verify meaning remains the same.
• Practical outcome: theme-based paragraphs that read like an argument, not a list.

Section 6.4: Comparing studies: agreement, disagreement, and gaps

A strong mini literature review includes at least one compare-and-contrast paragraph with citations. Comparison is not only about results; it also covers assumptions, datasets, metrics, and threats to validity. Start by naming the comparison dimension: “Across these studies, the main difference lies in how robustness is evaluated…” Then describe where they agree (shared findings), where they disagree (conflicting results or interpretations), and what gap remains (what neither study addresses).

Use disciplined language. If two papers show different outcomes, do not immediately claim one is “wrong.” First consider whether the studies are actually comparable. Differences in training data, preprocessing, evaluation splits, or baseline strength can easily explain divergent results. Your job is to surface these differences clearly, with evidence.

A useful compare-and-contrast paragraph structure is:

• Topic sentence: state the comparison focus.
• Agreement: one sentence synthesizing a shared point, with both citations.
• Contrast: one or two sentences describing the key difference, citing each source in the relevant clause.
• Interpretation: explain why the difference may matter (without inventing causes).
• Gap: state what remains unknown and what a future study would need to test.

Engineering judgment matters here: you are allowed to be uncertain. Phrases like “may indicate,” “is consistent with,” or “suggests” are appropriate when the evidence is limited. The “gap” should be concrete—e.g., “neither study evaluates out-of-distribution shift on real user data”—not vague (“more research is needed”).

Section 6.5: Responsible AI assistance: prompts for editing, not inventing

AI tools can help you write more clearly, but they can also introduce serious academic integrity problems—especially fabricated citations, incorrect claims, and “confident” paraphrases that subtly change meaning. The rule for this chapter is simple: use AI for editing and clarity checks, not for generating factual content you cannot verify from your sources.

Safe uses include: improving sentence clarity, tightening paragraph cohesion, checking for repeated wording, suggesting transitions, and flagging places where a citation is needed. Risky uses include: asking the tool to “find sources,” generate a reference list from memory, or summarize a paper you did not provide. If you do use AI to summarize text, paste the relevant excerpt from the paper and verify every claim against the original.

Practical prompt patterns (you still verify and keep your voice):

• “Rewrite this paragraph for clarity while preserving meaning. Do not add new claims or citations: [paste paragraph].”
• “List any sentences that sound like they need a citation or specify which source supports them: [paste paragraph + list of your sources].”
• “Check for hedging and overclaiming. Mark sentences that sound stronger than the evidence provided.”
• “Suggest a clearer compare-and-contrast structure using the same information and the existing citations only.”

Build a habit: never accept an AI-suggested citation unless you can open the source and confirm the cited claim. If you cannot verify, delete it. Your credibility depends less on sounding sophisticated and more on being accurate and traceable.

Section 6.6: Final polish: coherence, citations audit, and submission checklist

Now turn your outline into a 1–2 page draft. A workable mini review outline is: (1) introduction with review question and scope, (2) 2–3 theme paragraphs synthesizing the sources, (3) one compare-and-contrast paragraph highlighting agreement/disagreement and a gap, and (4) a short conclusion stating what the mini map implies. Keep paragraphs purposeful: each should answer “So what?” in the context of your question.

Next, run a citations audit. Go line by line and ask: “Could a reader trace this sentence to a source?” Add in-text citations for specific claims, methods, or numbers. Ensure your citation style is consistent (APA or IEEE basics). In APA, citations typically look like (Author, Year); in IEEE, like [1]. Your reference list must match your in-text citations exactly: every in-text citation has a reference entry, and every reference entry is cited in the text.

Also check paraphrase safety. If a sentence is structurally too close to the original, rewrite it from your notes rather than from the paper’s phrasing. Keep technical terms that must remain exact, but express explanations in your own structure.

• Coherence check: does each paragraph start with a clear theme sentence and end with a takeaway?
• Source log check: can you point to where each cited claim came from (page/section/figure)?
• Formatting check: consistent heading, spacing, and reference style.
• Integrity check: no citations you did not personally verify; no “phantom” references.

Your final deliverable is a polished mini literature review with a reference list. If you can hand it to a classmate and they can (1) restate your question, (2) summarize what the sources collectively show, and (3) identify the gap you highlight, then you have successfully completed your first literature review—small in size, but built with professional habits.