A 26M-parameter edit tagger out-corrects LoRA-tuned Gemma 3 270M and SmolLM2 360M on a phone keyboard

The gap starts with what each model is allowed to output. A generative corrector rewrites the sentence token by token. The post's authors describe the consequence: "Generative correction regenerates every token, so every token is a chance to change something that was fine." ^[9] Fine-tuning reduces that risk a lot, they wrote, but does not remove it. ^[22]

The tagger's output space is a fixed set of 15,000 edit labels on an 8-layer encoder with 26.2M parameters. ^[11] $KEEP is a real answer: 30% of the 12.02M training pairs are identity pairs. ^[13] The model has roughly 10 to 14 times fewer parameters than the two LLMs it was compared with ^[30], and its F0.5 is 0.136 higher ^[27].

Three additions sit around the network, and the authors say they "do a lot of the work". ^[23] A constant added to the $KEEP logit sets strictness. Values 1, 2 and 3 map to the "Catch more", "Balanced" and "Only sure fixes" settings. ^[14] Inside a detected name, number, email or URL only $KEEP is allowed, and the suite shows 0.0% lost protected spans for every tagger version. ^[15] A $REPLACE is accepted only if it is a known kind of fix or a small edit distance. ^[16]

The post's summary gives one set of LLM numbers. The portion we have does not break them out by model, and does not say whether the LoRA models ran behind equivalent filters. If they did not, part of the 0.136 gap belongs to the filters.

Treat the 0.799 as a claim about this workload. The LLM side is one configuration: LoRA r32 on the same correction data, served with llama.cpp. ^[8] The tagger's training mix leans on synthetic phone typos such as QWERTY neighbours, apostrophes, their/there/they're and agreement errors, plus real misspellings, CoEdIT and casual messages written by a local Qwen2.5-14B. ^[24] The 4,356 test cases were kept out of training by a deterministic hash split. ^[7] For the score to transfer, your users' errors have to look like that mix, and the LoRA run has to be a fair stand-in for what you would tune.

The false-change rate also moves with the set. The summary says 2.4%; on the 2,000 held-out real-style messages v1.5 scores 1.9%. ^[2][17] Tense is still weak, according to the authors. ^[26]

The post documents a failure in full. Versions 1.3 and 1.4 lost to 1.2, with false positives on correct text going from 3.1% to 7.4% and 9.1%. ^[18] The fine-tune script set the number of training steps from a time budget, using the speed it timed at step 300. For v1.2, that timing landed during a VRAM spill into WSL shared memory, and the run was accidentally given a short schedule. ^[19] So the best early version owed its short schedule to a GPU that was swapping. Once the spill was fixed, v1.3 and v1.4 ran 2.6 to 2.9 epochs against 1.4. ^[19] The authors wrote: "The comparison wasn't fair, and the long runs were the bad ones." ^[20] The extra errors were mostly preposition swaps next to names, such as "booked table 27 at Kyiv" becoming "in Kyiv". ^[21]

The evidence supports a narrow claim. One task, two LLMs and one LoRA configuration produced a win for a purpose-built tagger on the authors' own benchmark. ^[1][8] We think the design is the right trade for a keyboard. The iOS extension has no GPU guarantees ^[5], the OS enforces the no-network rule ^[25], and the authors wrote that "A false correction costs more user trust than a missed one". ^[6] Whether that generalises to other on-device tasks is not tested here. The weights are Apache-2.0, so anyone can run the check on their own text. ^[4]