Here's the question that's been sitting in the back of my head since I read this one — if you want a model to write more like you, do you teach it what to say, or just what not to say?
That's the whole thing, isn't it. And Daniel's given us three different answers.
Daniel's been circling this for a few episodes, the fine-tuning thing, and this time he wants to bring it together properly. He's happy with DeepSeek — that's the starting point, it's not a complaint. It's that there are small nudges to the dialogue he can't get out of system prompting reliably, which is true, and he's stopped pretending it isn't.
System prompting gets you ninety percent there and then plateaus.
And then plateaus forever. So he's got three methods. Method A — take twenty transcripts, write a global comment on each one, good, bad, could be better, hand the transcript back to the model, let it regenerate, and train on the diff against the original. Method B — same twenty transcripts, but he edits them by hand, light touch, targeted, removing the phrases he's tired of and finding alternatives, and the diff is the training signal. Method C — he prints the transcripts, reads them, underlines the overused phrases, and trains a purely negative counterweight against them.
And he tells us he likes C the least.
He does, he says it explicitly. It's purely negative, whereas B gives him latitude to actually find better phrasing. So let's take these one at a time, and then get to the part Daniel actually asked for — the recipe.
I want to push back on one thing before we start, because I think the framing matters. This isn't a question of whether fine-tuning works. That's settled, we've done episodes on the mechanics. The actual question is which data-generation strategy produces a model that writes the way Daniel wants, and what the minimum viable version of that is.
Which is a better question.
It's a harder one. So where DeepSeek actually sits right now — V4.1-Flash shipped in September, and it's the live API model. V4-Pro traffic got rerouted onto V4.1-Flash at V4.1-Flash pricing a few days later, which tells you something about how DeepSeek feels about their own flagship.
They consolidated.
The V4-Flash official version went open-weight in August, three hundred and four billion parameters, GGUF quantization published. And here's the constraint that shapes everything: DeepSeek's hosted API doesn't document a first-party managed fine-tuning endpoint. Not for Flash, not for V4-Pro.
So you can't just click a button and hand them your transcripts.
You cannot. Fine-tuning here means open weights, or you manage the training yourself, or you go through a third party. That's the landscape.
Twenty transcripts. Before we get into which method, I want to know if twenty is even a number.
It's not, and we'll get there properly, because that's the part where the literature has an actual answer. But look — before we can pick a winner, we need to understand what each method is actually doing under the hood. And there's a paper from July that tested almost exactly this.
The epanorthosis one.
Federico Boggia, posted to arXiv in July. Epanorthosis is the rhetorical term for going back and correcting yourself mid-sentence, and the paper is about a model that does it too much. Which is the same shape of problem Daniel has, just one tic instead of twenty.
So it's a proof case.
It's better than a proof case, because he ran it twice, two different ways, and one of them failed in a way that's instructive. Method A, if you implement it as preference ranking — original transcript versus regenerated transcript, which is better — that's DPO. Direct preference optimization.
And the paper says that fails.
Preference optimisation fails, supervised fine-tuning works. That's the finding, near enough verbatim. The DPO adapter was trained on five hundred and seventy preference pairs. High preference accuracy on the training set — it learned to rank the pairs correctly. And then it failed to generalise completely. It actually raised the density of the target phrase. From about sixty per ten thousand words to sixty-nine.
It made it worse than the base model.
Boggia's line is that the small-data DPO learned to rank the pairs without moving the generation policy in the intended direction. That's the whole failure in one sentence. It learned the discriminator, not the generator.
Which is the trap Daniel walks straight into with Method A.
If he implements it as preference ranking, yes. And the reason is mechanical, and it's worth sitting on for a second. Preference optimisation tells the model which of two outputs is better. It doesn't tell the model how to produce the better one. Those are different skills. Ranking is a judgment task. Generation is a production task. With enough data the two converge — the model learns the judgment and the generation tracks it. With five hundred pairs they don't converge. The model gets very good at the test and no better at the job.
So the fix is to stop asking it to judge and start showing it the answer.
Which is exactly what he did in the second run. Dropped the preference framing entirely, kept the chosen responses, and did plain supervised fine-tuning on those. Three epochs, LoRA rank thirty-two, over seven hundred and ninety-seven semantically filtered pairs, on Qwen two point five seven B Instruct. Cut the density by about ninety-eight percent.
From what to what?
Seventy-five per ten thousand words down to one point seven.
So it didn't reduce the tic. It removed it.
It very nearly removed it. And that's the part I'd flag, actually, because Boggia says something about this that I think is the most important sentence in the paper. The target is calibration to the human rate for each genre, not elimination. And the risk he names is that we begin to write like the machines.
Meaning a model that writes nothing like a machine but also nothing like a person.
A model with no fingerprints at all. Which is its own kind of tell.
Now map that back onto the three methods, because that's the thing Daniel asked for and it's cleaner than I expected. Method A as preference ranking — that's the DPO trap. Method A implemented as direct SFT on the regenerated transcript avoids the trap, but the improvement signal is the model's own output. You're training it on its own idea of better. There's no human calibration anywhere in the loop.
You're asking it to grade its own homework and then teaching it the grade.
Method B is the classic style-transfer approach, and it's what the paper actually did. Human edits, minimal diff, train on the diff. That's the run that worked.
And Method C maps almost exactly onto what Boggia built — the anti-epanorthosis adapter, purely negative, suppress the tic. And he shows that can work. It does work, via SFT. But the failure mode is the one he names: it eliminates the figure rather than calibrating it, and it lands below the human rate.
So C doesn't fail. It overshoots.
It overshoots in the direction of sterile. And Daniel's instinct — he says he likes C least because it's purely negative, whereas B lets him find alternatives — that instinct is supported by the evidence. Calibration beats elimination. And the way you calibrate is by showing the model what you'd have written instead, which is Method B by definition.
Method B wins.
Method B wins on the evidence. Now the data question, which is where twenty dies.
Twenty dies.
Twenty is below the practical floor for a reliable style adapter. It's not close. What the sources converge on is roughly two hundred to five hundred diverse examples as the safe target, with one hundred to two hundred being the defensible minimum for a narrow task like this.
And twenty is a fifth of that, at best.
Twenty puts you in the memorization regime. That's the phrase worth knowing — below the threshold, the model isn't learning a style, it's memorising your examples. You'll see beautiful training loss and a model that has learned those twenty transcripts and nothing about how to write the twenty-first.
It'll quote him back to himself.
It will quote him back to himself, in the wrong voice, forever. And there's a nice datapoint on the other end: a study from last year, Marquardt and Brule, found fine-tuning beat system prompting on tone of voice even with only a hundred samples. So a hundred is not nothing. A hundred is a real adapter for a narrow task.
But a hundred is five times what he's proposing.
It is. And on the question of what counts as a sample — there's a useful distinction here. It's not two hundred transcripts. It's two hundred edited examples. If he splits each script into individual turns or exchanges, one episode might yield forty or fifty usable training pairs rather than one. That's how the arithmetic actually works in his favour.
So the number that sounds impossible isn't.
The number that sounds impossible is a function of how you count. Twenty episodes, cut into turns, hand-edited, is somewhere in the low thousands of pairs. He's not short of data. He's short of patience for editing it.
Which is the real bottleneck.
Which is the real bottleneck, and it's the same thing everyone says about this. A strong fine-tuning project is a data project first and a GPU project second. The GPU time is trivial. The editing is the whole job.
Hold on. If twenty episodes cut into turns gets him to a thousand pairs, why does anyone say two hundred to five hundred?
Because diversity matters more than volume past a point. Two hundred turns from one episode share that episode's vocabulary, its topic, its register. The floor isn't a count of pairs, it's a count of distinct situations the model has seen the style applied in. Which is why his hand-editing has to be spread across different kinds of episodes rather than concentrated in the ones he enjoyed editing.
So Method B wins on the evidence, and the data number is more forgiving than he thinks as long as he spreads it. Now the question is what we actually build, and how.
And the fine-tune versus LoRA question has an unambiguous answer for this use case. LoRA. Or QLoRA. Not a full fine-tune.
Because he's changing style, not knowledge.
Because he's changing style and format, which is exactly the case the guidance is written for. Train a LoRA when you want to teach a model one specific thing without changing who it is. That's the line, and it's the right line for this. For narrow objectives — tone, format, voice — LoRA consistently reaches parity with full fine-tuning. You don't need the full thing.
And the economics are not close.
They're not. LoRA trains about a tenth of a percent of the parameters. Memory drops from something like sixty-four gigabytes to twenty-one. Cost per run, on the order of eight dollars down to about a dollar and a quarter. There's a half-percent accuracy gap on classification tasks, which for style transfer is noise.
A dollar twenty-five a run means he can iterate.
A dollar twenty-five a run means he can iterate fifty times for the price of one full fine-tune, and the iterating is where the model actually gets good. And QLoRA — the quantized version — fits a seven or eight billion parameter model on sixteen to twenty-four gigabytes of VRAM. That's a single consumer card. That's his home server.
So what's the base model? Because he says DeepSeek 4.1 and that's not a fine-tuning target.
It isn't. V4.1-Flash is seven hundred and sixty-three billion parameters total, five hundred and fifty-two of them in the mixture, and V4-Pro is one point six trillion. Those are not ordinary fine-tuning targets. The practical base is one of the distilled models — DeepSeek-R1-Distill-Qwen-7B, or the Llama eight B distill. Seven or eight billion, dense, trains on one card, and it's still DeepSeek's lineage.
But it isn't the model he's using.
It isn't, and this is the honest caveat. The epanorthosis adapter that cut density by ninety-eight percent was trained on Qwen two point five seven B Instruct. Not DeepSeek. The paper explicitly leaves transfer of the trained adapter to larger models as future work. So the ninety-eight percent is a mechanism proof. It tells us the approach works. It does not tell us it works on V4.1-Flash, because nobody has shown that yet.
So the real experiment is still ahead of him.
The real experiment is still ahead of him. He can prove the mechanism on a small base and he'll have to, because that's the only base he can train.
Walk me through the actual recipe, then. The steps.
Seven steps, and they're not exotic. Pick the base — the R1-Distill-Qwen-7B or the Llama 8B. Prepare the data as JSONL, prompt and completion pairs, with a five to fifteen percent validation split held back and a separate test set you never touch during training.
Never touch.
Never touch, because that's the only honest measurement you'll have. Then load the base in four-bit with bitsandbytes — nf4, double quantization — and run the k-bit preparation. Configure the LoRA: rank sixteen, alpha thirty-two, dropout zero point zero five, targeting the attention and feed-forward projections — query, key, value, output, and the gate, up and down projections in the MLP. Then train with the standard supervised fine-tuning trainer: two epochs, learning rate one e-four, cosine schedule, gradient checkpointing on, max length two thousand and forty-eight.
Two epochs sounds low.
Two epochs is right for this. Style adapters overfit fast — you're teaching a mannerism, not a subject, and the third epoch is where it starts parroting. Then save the adapter, run inference through the adapter wrapper, and optionally merge it back into the base weights if you want a standalone model. And the last step is the one people skip —
Evaluate against the base.
Evaluate against the base on the held-out examples. A lower training loss does not prove the fine-tune worked. That's the standard line and it's the standard line because it's the standard mistake. The only question that matters is whether a human reading the output prefers it, blind.
Which he can actually do, because he's the human who'll be reading it.
He's the ideal evaluator. He's the one whose taste we're trying to install.
But here's the thing I keep circling back to. Why this instead of a better system prompt and a poster on the wall?
Because prompting plateaus, and the plateau is the reason he's asking. You can tell a model to avoid a phrase and it'll avoid it for a page and drift back. What the LoRA gives him is something else, and it's the best part of the whole paper. The adapter is separable and it's scalable. You can dial its coefficient at inference.
Meaning.
Meaning it's a rhetoric dial. At coefficient zero you get the base model. At one you get the full adapted style. And you can sit anywhere in between. If he wants a five percent nudge on a serious episode and a heavier one on something lighter, he changes a single number.
That's the subtle nudge he said prompting can't produce.
In his own words. And there's a warning attached. The relationship isn't monotonic. In the paper, promotional density spiked to ninety-six at a coefficient of zero point two five before collapsing at higher values. So there's a band where turning the dial up makes the tic worse, not better.
Because you're amplifying the part of the adapter that fights the base style.
Because the adapter is doing two things at once and at low strength you get more of the wrong one. So the coefficient has to be tuned per genre, measured, not guessed.
The other thing this buys him — he can ship the base model and the adapter separately. Keep one model, apply a style layer. When DeepSeek ships the next base, he retrains the adapter against it and keeps the dial.
And the adapter is small. Megabytes, not gigabytes. He could keep three of them, one per register, and switch.
That's a different relationship with the model than prompting allows.
It's a different relationship entirely. Prompting is a request. This is a setting.
That's the recipe.
How many times does a person say "at the end of the day" before somebody stops them.
I agree with you two. Method B. It's not close. But I didn't come to that from a paper. I've been keeping a tally.
A tally.
On paper. I print the transcripts. Every time a phrase turns up that I've decided counts, it gets a stroke. "At the end of the day" is the main one. There's a column for it.
How long have you been doing this.
Since about two thousand and eleven. Two thousand and twelve, maybe. The folder at the front goes back further than the folder at the back, if that's any use to you.
Since before the podcast.
Well before the podcast. It started with the newsletter. The newsletter had a phrase problem and nobody wanted to hear about it.
What's the count.
Twenty-three thousand, four hundred and sixteen. That's the main column. There's a second column for "it's worth noting" and that one's at eleven thousand odd and I stopped filling it in because the pen ran out and I didn't like the new pen.
This is for your own writing?
It's for everything that crosses the desk. It's a reading habit, not a writing habit. You read enough of it and you start to see the seams.
And the council knows about this.
The what?
Nothing.
The point is I agree with you both, and I'd have put money on it, because I've been doing by hand what you're talking about doing with a graphics card. Method B is right. You show it what you'd have written instead. You don't tell it what not to write, because it'll just write the next worst thing. Underline "at the end of the day" and the model learns to say "when all is said and done." You haven't fixed anything. You've taught it a synonym.
That's the calibration argument.
That's the argument. The paper's right about elimination being the wrong target. But here's what it doesn't say, because it can't, because it's never had to sit with the folder.
Go on.
The number's real. I've got a ring binder of it. But the binder's in my brother-in-law's garage, because he borrowed the shelf in two thousand and nineteen and never brought the shelf back, and I've been adding to it there ever since. Which he knows about. Which I've told him about. Twice.
You keep the count in a garage you don't own.
It's a good shelf. It's level. And he's not moving it, because I asked him not to.
You have a rhetorical tic dashboard eleven years old, three miles from your house, on a shelf you don't own.
It's a mile and a bit. And no dashboard. It's a binder. That's the last of it.
The count is a story about how much of this survives in a model. Mine is that twenty-three thousand strokes is a body of work and the paper's a few hundred examples and it still worked. You don't need the binder. You need enough of it to show it what you'd rather have said.
Okay. So if the dial works, what does it mean to have a model that writes like you but can be turned up or down? Is that a tool, or is it a collaborator?
That's the part the paper leaves open. The ninety-eight percent was Qwen two point five seven B. The transfer to the larger DeepSeek models is explicitly future work. So Daniel has a mechanism that's proven and a result that isn't his yet. The real experiment is still ahead of him, and he's the one positioned to run it.
If you want to hear more about fine-tuning, or LoRA, or the specific phrases Daniel is trying to eliminate, leave us a review and tell us which one.
Producing today's episode was Hilbert Flumingtop, whose binder we do not have access to.
If this was your kind of episode, go back for episode six, How To Fine Tune Whisper; episode eleven, How Does Fine Tuning Work Anyway; and episode five, Fine-Tuning ASR For Maximal Usability. This has been My Weird Prompts.
Send us your own prompt on Telegram at t dot me slash MWP listener bot. We'll be back soon.
