There is a strong idea here, but “make my draft closer to the liked embeddings” is probably the wrong objective. That would produce imitation, and ordinary embeddings often capture topic more strongly than style anyway.
The more useful goal is:
Use admired and disliked writing to infer the writer’s editorial taste, then use that taste to diagnose drafts—not generate prose toward a centroid.
A contrastive taste model
The corpus should contain more than binary likes and dislikes. Writers could highlight passages and annotate why they react to them:
- “Concrete without over-explaining”
- “Earns this aphorism through the preceding example”
- “Too polished; sounds airless”
- “False profundity”
- “Good alternation of long and short sentences”
- “Abrupt transition, but productively so”
- “Too many abstract nouns”
- “I admire this but do not want to sound like it”
- “This is already a tendency of mine; don’t reinforce it”
That last distinction is crucial. Taste, aspiration, and identity are not the same thing. I can admire Borges without wanting my product review rewritten as Borges.
Rather than one “style embedding,” the system could build several partial models:
- sentence rhythm
- degree of abstraction
- explicitness versus implication
- use of examples
- rhetorical temperature
- humor and irony
- structural density
- tolerance for digression
- strength and frequency of claims
- relationship to the reader
- patterns the writer finds mannered or clichéd
The writer could activate different profiles by project: “reported feature,” “personal essay,” “technical explanation,” or “correspondence.”
Comparison should produce questions, not grades
A system should not say:
Your draft is 63% similar to writers you like.
That number would be nearly meaningless and dangerously seductive.
It could instead say:
You tend to favor passages that introduce abstractions through concrete cases. In this draft, the first concrete case appears after 900 words.
Or:
In passages you dislike, emphatic one-sentence paragraphs often state conclusions already implied by the previous paragraph. This draft contains five such cases.
Or:
Your reference corpus usually alternates exposition with complication. Sections 2–4 only accumulate evidence, so the argument may feel predetermined.
These are inspectable claims. The system should show the passages that led it to infer a preference, and let the writer correct the inference.
Preventing parroting
Several design choices would help.
1. Separate content from stylistic features
Before comparing passages, control for subject matter. Otherwise, a writer who saves many essays about cities may be told that an essay sounds “right” merely because it discusses streets and buildings.
Comparisons should operate on explicit features, syntactic representations, rhetorical roles, and structural patterns—not only generic semantic embeddings.
2. Use references for discrimination, not continuation
The system can learn to answer “Which of these two paragraphs would this writer probably prefer, and why?” without being trained to complete prose in the manner of a named author.
That makes it an editorial model rather than an imitation model.
3. Retrieve counterexamples
For every suggestion, show both:
- an admired passage exhibiting the relevant property
- an admired passage succeeding by violating it
This prevents preferences from hardening into rules. Good writers often have taste for multiple, incompatible effects.
4. Protect productive deviation
The system should identify when the draft differs from the taste profile without assuming that difference is bad:
This ending is more explicit than endings you usually admire. Is that deliberate?
A distinctive voice often emerges from the gap between what someone admires and what they naturally produce. Automatically closing that gap could erase the interesting part.
5. Detect mimicry directly
It could flag unusually close phrase-level, syntactic, or rhetorical resemblance to a source. “You appear to have absorbed this author’s cadence” is useful feedback, especially if the exact parallel is shown.
The writer’s own archive matters more
A corpus of favorite authors models taste. A writer’s drafts, revisions, journals, emails, published work, and rejected sentences model actual voice.
Version history is especially valuable. Every accepted and rejected edit is a preference signal:
- The model suggested a cleaner sentence; the writer restored the awkward one.
- The editor asked for a clearer thesis; the writer made it more qualified.
- The writer repeatedly removed summary sentences.
- The writer preserved certain fragments and irregular rhythms.
Those decisions reveal voice more accurately than finished prose alone. The harness could learn:
You routinely reject edits that replace physical verbs with abstract summaries.
That is both specific and grounded in the writer’s behavior.
A possible workflow
- The writer imports a private reference library.
- They highlight and annotate a small number of passages; the system proposes additional inferred dimensions.
- The system presents pairs—“Which do you prefer, and in what context?”—to refine the profile.
- It separately analyzes the writer’s own revision history.
- On a draft, it produces a taste-aware editorial report:
- where the draft aligns with recurring preferences
- where it deviates
- where it resembles a source too closely
- where the writer’s habitual weaknesses are being mistaken for voice
- which trade-offs each proposed revision would make
- The writer requests local alternatives, but the tool does not automatically normalize the whole document.
The deepest opportunity is not “write like the library.” It is make tacit taste explicit. Skilled editors do this: they gradually learn what a writer is trying to become, then point out where the draft betrays or exceeds that intention. Embeddings could provide part of the memory and pattern recognition, but annotations, contrastive judgments, revision history, and interpretable features would make the system genuinely useful.