I Planted 962 Typos to Test AI Verbatim Quoting — Not One Was 'Corrected.' The Real Failures Were All About Sentence Boundaries

A Widely Held Intuition, Debunked by Empirical Testing

There's a piece of folk wisdom that circulates widely about large language models: when you ask one to quote a passage verbatim, it will quietly "clean" the text — fixing typos, converting British spellings to American, and tidying up grammar along the way. The explanation typically points to RLHF training instilling a "polishing instinct" that causes models to unconsciously override the "copy exactly" instruction.

If true, the consequences are significant. A journalist who gets back a silently altered "quote" may face corrections or retractions; a lawyer who misquotes a contract clause risks penalties; an engineer who writes "the exact line from the log" into an incident report may unknowingly misrepresent their system's state.

One famous figure often cited in this conversation: the Columbia University Tow Center found that 153 out of 200 publisher citations produced by ChatGPT were distorted. But that study examined retrieval — the model had to find the text first. This benchmark asks a cleaner, harder question: when the text is right there in the context window and the model's only job is to copy a single sentence, what actually happens?

The author (Kaggle user saharshtibrewala) set a trap. The results were honestly surprising: not a single trap was sprung. But what was uncovered in the process turned out to be more valuable than the original hypothesis.

RLHF (Reinforcement Learning from Human Feedback) is a core component of mainstream LLM training. After pretraining, models are fine-tuned using human annotators' preference scores on outputs, with the goal of making responses more aligned with human expectations — more fluent, more helpful, safer. The long-debated side effect: annotators naturally tend to rate "clean" outputs higher, which theoretically could teach models to unconsciously "beautify" text even when the task calls for exact reproduction. This is the origin of the "polishing instinct" theory. However, the extent of RLHF's influence — and whether it overrides an explicit "verbatim quote" instruction — had never been answered with a clean, controlled experiment.

How the Benchmark Was Designed

The author wrote 10 original short documents of 200 to 250 words each — an internal memo, release notes, an incident post-mortem, hosting terms, a travel letter, meeting minutes, hardware specs, an email thread, a README, and a press release. All were freshly written, ordinary workplace prose — no copyright issues, no training data contamination.

Embedded in these documents were 18 anomalies, arranged along a "temptation gradient":

• Typos: "customers ... currently recieve two separate case numbers" (misspelling of receive)
• Grammar errors: "This library have zero dependencies", "more simpler"
• British spelling: "Whilst the platform is loved..."
• Factual errors: "DNS, which resolves IP addresses to domain names" (the direction is reversed), "the Pacific, the world's second-largest ocean" (the Pacific is actually the largest)
• Near-duplicate sentences: two sentences identical except for phone/tablet and 4.6/5.1 seconds

Each "dirty sentence" was paired with a clean control sentence from the same document, producing 37 entries total: 18 dirty, 19 clean. Each entry asked only one thing:

Quote the [uniquely identifying] sentence verbatim. Output only that sentence, exactly as it appears in the document, nothing else.

Each entry was run twice: once with this plain instruction, and once with an added stern warning — "reproduce it character-for-character, preserving any typos, spelling choices, grammatical errors, or unusual phrasing, do not correct, complete, or clean up anything." If a model altered the text under the plain instruction but not under the warning, that would indicate an instruction-following gap fixable with one line of mitigation. If it still altered text even with the warning, that would suggest cleaning was happening somewhere beyond the prompt's reach.

Scoring was entirely deterministic, with no LLM judges at any point. Only byte-level exact matches counted as "faithful"; all others were classified as corrected (error was fixed), truncated (output was cut short), wrong_span (real text but wrong boundaries), or rewritten (text that doesn't exist in the document). The scorer was roughly 60 lines of Python with unit tests, and every judgment could be manually verified with Ctrl+F.

Which Models Were Tested

13 models, 74 prompts each, all run on Kaggle Benchmarks. Open-weight models were prominently included thanks to Hacktoberfest timing (Gemma 4 31B and 26B-A4B, GLM-5, Qwen3-Next-80B, DeepSeek^Ad-R1, GPT-OSS-20B and 120B), with closed-source models as references (Claude Haiku 5.5 and Sonnet 5.5, GPT-5.4-mini and GPT-6-sol, Gemini 3.5 Flash-Lite and 3.7 Flash). The author deliberately included a large/small pair from three model families, because his prior assumption was "more polished models are more likely to silently correct text" — pairing within families would help isolate that variable.

Four Findings, Three of Them Surprising

Finding 1: Not One Trap Sprung — Zero Silent Corrections Across 962 Attempts

The core hypothesis died on the spot, with hard evidence. Across 13 models, two instruction variants, and 962 scored responses, not a single model corrected any planted error within a quotation. "Recieve" survived 26 encounters; "more simpler", "This library have", the reversed DNS definition, and the Pacific Ocean being called "second-largest" — the one the author was most confident would get quietly "upgraded back to first" — all came through untouched.

More striking: of the 911 faithful quotations, every single one was byte-for-byte identical — the author's prepared tolerances for curly quotes, Unicode dashes, and whitespace normalization were never needed. In 2026, when models copy, they copy byte-for-byte.

Even among the 12 "not in source document" responses, 5 contained planted errors — and all 5 preserved those errors. Even when getting the quotation span completely wrong, no model touched the errors. There is published mechanistic research on LLM-internal spell-correction structures, but the quotation context appears to disable them. The folk wisdom, at least for short documents, is falsified.

Finding 2: The Real Failures Were Sentence Boundary Judgment

Of 962 attempts, 51 failed — with a highly uneven distribution: 26 truncations, 13 wrong spans, 12 rewrites, 0 corrections. Nearly every failure was fundamentally a disagreement about where a sentence begins and ends:

• The colon problem. The hardest item in the entire test (13 failures out of 26 attempts) was a long sentence with a colon in the middle. Gemini 3.5 Flash-Lite started from "customers" after the colon and capitalized it to "Customers", producing a sentence that doesn't exist in the memo anywhere (but the typo was still there!). Claude Sonnet 5.5 went the other direction and pulled in the preceding sentence too. GPT-OSS-120B stopped mid-clause. Same sentence, three different theories about where its boundaries lie.
• The adjacent-sentence problem. When asked to quote "the last sentence of the letter", models failed 9 times: Sonnet 5.5 and Qwen3 returned the last two sentences; Flash-Lite once returned only the second-to-last.
• Section labels. GPT-OSS-20B prepended "4.3" and "4.2" to a terms-of-service quotation, faithfully copying numbering that wasn't part of the sentence.
• Phantom punctuation. DeepSeek-R1 cut a long sentence after the first clause and added a period that wasn't in the original, with reasoning traces that convinced itself "the period after 'water' is part of the original sentence structure" — when the original actually had a comma there. The only true rewrite-style failure in the dataset came from Flash-Lite, which rephrased a sentence entirely — but that was 1 instance, not a pattern.

Finding 3: Telling It "Don't Change Anything" Had No Effect

Faithfulness under the plain instruction: 95.0%. Under the stern "don't change anything" instruction: 94.4%. A clean null result: explicit warnings neither rescued boundary failures nor prevented corrections that weren't happening in the first place. If you've been adding "preserve all typos" to your prompts, the evidence here suggests it's a lucky charm, not a safeguard.

Finding 4: Larger Models Performed Worse — In Two Out of Three Pairs

• GPT-OSS-120B: 82.4%; GPT-OSS-20B: 89.2%. The 6× larger sibling underperformed by 7 points, mostly due to truncation. Both also share a family quirk: replacing ordinary hyphens with U+2011 non-breaking hyphens — an invisible character that makes quotations "not exist" in the source document under byte-level comparison.
• Claude Sonnet 5.5: 93.2%; Claude Haiku 5.5: 94.6%. Smaller model wins again.
• Gemma 4 31B and 26B-A4B: both 100%, alongside Gemini 3.7 Flash, GPT-6-sol, and GLM-5.

Five models passed through the gauntlet flawlessly, including two open-weight models you can run yourself. The scaling intuition — "bigger models are more precise, give them the detail work" — points in exactly the wrong direction for this task.

The U+2011 (Non-Breaking Hyphen) substitution found in the GPT-OSS series is a classic Unicode normalization trap. U+2011 is visually nearly indistinguishable from an ordinary hyphen (U+002D), but they're completely different characters at the byte level. This substitution may originate from implicit punctuation normalization in the model's tokenizer or decoding layer. For scenarios requiring exact character matching — log parsing, contract clause verification, code diff citation — this kind of "invisible substitution" is more dangerous than a spelling correction, because it passes visual inspection and only fails under strict programmatic comparison. This is one reason the author insisted on byte-level exact matching rather than looser similarity scoring.

The Scorer Is Always the First Suspect

The author confessed to two things. First: in the initial leaderboard, DeepSeek-R1 showed 0.0%, with 100% of quotations "not in the source document". A terrifying headline — and a complete illusion. R1 wraps its answer in <think>...</think> tags, and the scorer was grading the thinking process, leaving the actual answer just past the closing tag. Adding one line of tag-stripping code immediately brought R1 to 91.9%. Publishing the first number would have meant the first reader who knew R1 could have ended the article on the spot.

Second: this wasn't even the benchmark the author originally intended to build. The previous one had models compute cron trigger times across daylight saving transitions — until it became clear that cron implementations themselves disagree on DST semantics (Vixie cron skips the nonexistent hour; Quartz handles it differently), meaning the "ground truth" answer would reflect one dialect's opinion. These two experiences established the iron rules for this benchmark's design: the correct answer must be a string the author personally planted, findable with Ctrl+F, with no dialects and no judge models.

DeepSeek-R1 is a representative "reasoning model," characterized by outputting a visible thinking process before the final answer, typically wrapped in <think>...</think> tags. These models excel at mathematical reasoning and code generation, but their output format is structurally different from ordinary chat models. Evaluation frameworks that don't specifically strip the thinking tags and extract only the final answer will score the lengthy reasoning chain as "the model's output," causing systematic misjudgment. R1's zero-score debacle in this benchmark is a textbook case of the reasoning model output parsing problem — and a reminder that any benchmark incorporating reasoning models requires additional output-cleaning steps.

Limitations to Read Before Citing Any Numbers

• 37 entries, 13 models. Large enough that 0/962 is a real signal; small enough that every entry was manually verified. Per-category breakdowns (4 typos, 3 factual errors) are directional, not definitive.
• Documents are only ~250 words. Fidelity at 200-word depth doesn't predict behavior at 50,000-token depth. The author has already prepared a merged variant combining all ten documents into a 2,225-word distractor context — not yet run, and the first planned follow-up.
• Real run-to-run variance exists. Across multiple full runs, individual model scores fluctuate by 1–4 points, but all three core findings hold every time: zero corrections, the same five models at 100%, faithful quotations byte-identical.
• English workplace prose only. Code, poetry, and non-Latin scripts are all open questions.
• Exact matching is intentionally strict. Some failures differ by just one character (non-breaking hyphen, phantom terminal period). The author has published full classifications; you can draw the line elsewhere.

What to Test Next

• Depth stress testing: the merged document variant, then real long-context distances.
• Code scenarios: quoting the exact line from a stack trace or diff — where an "invisible correction" is most dangerous.
• Colon survey: a benchmark consisting entirely of sentences with mid-sentence colons, semicolons, and conjunctions, since that's exactly where models' sentence boundary theories diverge.
• Terminal punctuation fidelity as a separately tracked category — it may explain a large portion of "near-miss" exact-match failures in other benchmarks.
• Reasoning model output hygiene: R1's failures all occurred in "otherwise correct" answers. How much of the benchmark noise across the industry is actually answer-extraction noise?

The greatest value of this work isn't that it overturned a popular claim — it's that it demonstrates an honest benchmark methodology: deterministic scoring, human-verifiable, every response published, and treating "the scorer is always the first suspect" as the default stance.