Why Mac dictation gets names wrong
Speech models predict likely words, and your colleague’s name is not a likely word. Why a personal dictionary fixes what a bigger model cannot.
Dictate a sentence about the weather and a speech model will get every word. Dictate the same sentence with your colleague’s surname in it and the surname is the word that comes out wrong -- reliably, in the same place, every time.
That is not a bug, and it is not a sign that the model is too small. It follows from what a speech model is. These systems do not identify words one at a time from sound alone; they search for the most likely sequence of words given the audio, and likelihood is learned from an enormous amount of text in which your colleague’s surname appears approximately never.
The failure is structural, and so is the fix. Understanding why the obvious remedies do not work is what makes the actual remedy make sense.
Why a rare word loses to a common one
At every step the decoder weighs candidate continuations against each other. The acoustic evidence votes for what it heard; the language prior votes for what usually follows. A name occurring once in ten million words of training text starts that contest far behind, and it takes only a common word that sounds roughly similar to win.
The result is worse than an obviously wrong word, and this is the part people underestimate. A recogniser producing gibberish would at least mark the spot. Instead it produces something plausible.
Sarah Vestergaard becomes Sarah Vester Guard. Your product Quotient becomes quotient, lowercase, indistinguishable from the ordinary noun. A teammate called Minjun becomes min june. Every one of those reads smoothly -- you proofread the message, your eye slides over a well-formed English phrase, and you send it. The errors people catch on re-read are the ones that look wrong, and these do not.
It is also why the problem stays invisible in reviews and demos. Nobody dictates a stranger’s surname into a demo, so a tool can look flawless and still fail on the first sentence you actually need to write.
Why a bigger model does not fix it
The natural next move is to reach for a larger model. It helps with plenty of things -- accents, noise, long sentences, punctuation -- but not with this, and the reason is worth being precise about.
A larger model shifts the probability distribution. It does not add entries to it. Your colleague’s surname was not in the training data before and is not in it now; what changed is how confidently everything else gets resolved. In some cases a bigger model makes this specific failure worse, because a stronger language prior is more willing to override the acoustics in favour of a common phrase.
Model size is a real axis with real trade-offs, covered in choosing a model size. It is simply not the axis this problem lives on.
What context can and cannot do
Context helps, within limits worth knowing. Inside a single utterance the decoder conditions on what it has already produced, so a name recognised correctly early is more likely to come out the same way later in the same dictation. That is why a long dictation sometimes gets a name right on the second mention and wrong on the first.
But each dictation starts cold. The recogniser has no access to your address book, your repository, your message history or the document you are typing into. It cannot know that the window in front of you contains that surname eleven times. Whatever it worked out within one utterance is gone by the next one.
That is the gap a personal dictionary fills, and the shape of the gap explains the shape of the fix: a small, stable set of terms you supply once, present for every dictation, rather than something the system is asked to infer.
The dictionary as a decoder hint
In Voicecape, the terms you add are handed to the recogniser before each session as an initial prompt. The decoder conditions on that text, which biases it toward your vocabulary without constraining it.
The distinction between bias and constraint matters. A constraint -- forcing the output to contain your terms, or running find-and-replace over the finished transcript -- is a blunt instrument that will eventually rewrite a legitimate word into a name you once typed into a settings panel. A bias only changes which candidate wins when the acoustics are close, which is exactly the situation where a rare name loses today. If you did not say the word, the audio does not support it and the hint does not put it there.
An entry is a term plus an optional reading -- how it sounds -- for the case where the spelling is a poor guide to the pronunciation. Both forms are handed to the recogniser, so a name written one way and spoken another has both available when the decoder is choosing. A hint is not a guarantee, and should not be sold as one. It moves the odds on the words that were losing narrowly.
What conditioning on a prompt costs
There is a real hazard in this design, and it is instructive because it is the same hazard the rest of the product is built to avoid.
A model conditioned on a prompt will, given nothing else to work with, decode the prompt back. Measured while building it: a few seconds of silence with a vocabulary prompt set returns the prompt itself as the transcript. That is the product inserting words the user did not say, which is the one thing it promises never to do.
So a loudness gate sits in front of the prompt rather than beside it: below a measured threshold the session counts as silence and nothing is transcribed at all. The threshold uses the average energy of the audio rather than its peak, because a single keyboard click is a high peak and is not speech. It is the same principle as the artifact filter described in verbatim versus cleaned dictation -- anything that could put words into your document that you did not speak gets a guard in front of it, including a feature you asked for.
Local, and per language
The dictionary is stored on your Mac in the app’s own local database, alongside your settings. It is not synced, not uploaded and not consulted over a network, which follows from the fact that recognition itself never leaves the machine.
Entries are filed per language, and that is not bureaucratic. The same term genuinely needs different treatment in different languages: a product name spoken inside an English sentence and inside a Korean one are different acoustic targets, and the spelling you want may differ too. Filing them separately lets both be right. When the language is set explicitly, that language’s terms are used; under automatic language, the union of every language’s terms is used, since a hint that does not apply to what you are speaking is harmless while guessing one language would make the dictionary appear to vanish the moment you switched.
For Korean in particular -- where romanisation, spacing and given-name conventions each give the decoder several defensible spellings of one sound -- the dictionary does more work than in English. Korean voice typing on a Mac covers that ground, and one model, five languages covers what happens when you switch languages mid-sentence.
What belongs in it
A dictionary is most useful when it is small and specific. It is not a place to list words you know; it is a place for the words a general-purpose model has no reason to know: surnames of people you write to often, product names that collide with ordinary nouns, internal jargon and codenames, acronyms your team says aloud, and anything whose spelling differs from its sound.
The way to build one is to notice. The next time a name comes back wrong, add it instead of fixing the sentence and moving on, because the fix you make by hand is one you will make again tomorrow. Ten or fifteen entries usually covers what a working week throws at you.
And when a word still comes out wrong, the correction is yours to make. Nothing further along decides on your behalf that a word you dictated was probably meant to be a different one -- the cleanup stage is a fixed list of removals, set out in what cleaned, never rewritten actually removes, and substituting words is not on it.