When AI Gets Your Name Wrong
ASR, transcription, NLP, evaluation
Speech models are fluent, but company names still defeat them — and fixing that means knowing when not to guess.
The machines that transcribe our meetings have become remarkably fluent. But the names that matter most to a business can still defeat them. The latest research suggests that fixing the problem requires more than simply teaching a system what to expect.
At the end of a meeting, a transcript arrives. The discussion has been captured, the speakers assigned their turns and a summary is ready for circulation. Everything looks reassuringly professional. Except that Neural Bridge Labs, the company under discussion, has become "Neural Bridge Lab".
It is a hypothetical example, but an entirely plausible class of mistake. A company name is not merely a string of words. It is a reference to a particular organisation. Get the reference wrong and a search index may misfile the discussion; a summary may repeat the error; a future assistant may quote it as if it were established fact.
A well-meaning engineer might reach for a list of approved company names. Whenever a transcription resembles one of them, the software could substitute the official spelling. Yet that creates a second problem. Imagine that the conversation actually concerns "a neural bridge in a lab". The same helpful software might now manufacture a company reference that nobody intended.
The first error is a failure to recognise a name. The second is a failure to resist one. It is this tension, rather than spelling alone, that makes the question unexpectedly difficult: when should a machine trust its expectation more than the words it has heard?
A rare word in a very large vocabulary
Automatic speech recognition, or ASR, has improved enormously. Modern systems learn patterns from audio and language at a scale that would once have seemed extravagant. But language contains an awkward statistical asymmetry. Ordinary phrases appear again and again. New brand names, obscure product codes and the surname of a person attending a single meeting may be encountered rarely, if at all.
That matters because recognising speech is not the mechanical exercise of converting a waveform into an unambiguous word. The signal may be degraded by background noise, accents, microphones and overlapping conversation. To decide among competing interpretations, recognition systems use both acoustic information and patterns learned from language. Common words can consequently have an advantage over unfamiliar names.
A 2026 study in the proceedings of LREC illustrates the gap. Researchers assembled a bilingual English-and-Portuguese dataset of 13,846 utterances designed to examine specialised vocabulary. On its most challenging subsets, the reported error rate on targeted jargon reached 88–90%, while the error rate on ordinary words was far lower, at 6–19%. Those are striking figures, but they come from deliberately difficult research material, some of it synthetic; they must not be mistaken for typical commercial transcription results. [1]
The lesson is more durable than the numbers: a good overall word-error rate can conceal poor performance on the words an organisation cares about most. A meeting assistant might correctly capture every polite greeting and still mishandle the name of the company that made the meeting necessary.
Tell the machine what to expect
One established remedy is to give the recogniser a hint. A speech service can be supplied with a phrase list, a custom vocabulary or contextual terms that are likely to be spoken. Rather than discovering an unfamiliar name unaided, the system is nudged towards it when the sound offers a plausible match.
This is no speculative technology. Google's Speech-to-Text offers phrase sets and adjustable boosting. Microsoft supports phrase lists in several recognition workflows. Amazon Transcribe distinguishes between custom vocabularies, which provide word-specific hints, and custom language models, which learn the surrounding domain language. Deepgram offers keyterm prompting. OpenAI's newer transcription interface also documents contextual prompts and keyword hints. The products differ in what their interfaces support; they should not be treated as interchangeable. [2–6]
There is a subtle price to this assistance. Google's documentation warns that greater boosting may reduce the chance of missing a desired word while increasing the chance of recognising it when it was not actually spoken. That is the central dilemma in miniature. The machine becomes better at hearing what it expects, which is helpful until the expectation is wrong. [2]
The appropriate degree of guidance also depends on the size of the task. A short list of trusted names is one problem. A dynamic catalogue of tens or hundreds of thousands of people, products and places is another. The latter requires deciding not only which word fits the sound, but which few names deserve to be considered in the first place.
New tricks for an old problem
Recent research has treated the search for relevant names as a retrieval problem. Instead of putting a vast dictionary into a speech model's context, a separate mechanism selects a shortlist. In effect, the machine consults a smaller, more relevant directory before settling on a transcript.
In 2025, the RECAST researchers described a method that retrieves likely keywords from speech-model decoder states. In their experiments, with up to 4,000 candidate terms, they reported reductions of up to 54.3% in entity word-error rate against their baseline. Another 2025 approach, BR-ASR, investigated retrieval from vocabularies as large as 200,000 entries. Both are impressive pieces of engineering, but their benchmark configurations, model assumptions and measures differ. Their headline improvements cannot be used to rank the systems for an unfamiliar company's meetings. [7,8]
The value of retrieval is easy to appreciate. If a speech recogniser is handed every conceivable term, the useful hints become a noisy crowd. If it can find the few names likely to matter, the prompt becomes smaller and more relevant. Yet a poor shortlist can exclude the correct name before the recogniser gets a fair chance to choose it.
There is also a different route: allow an ordinary transcription to finish, then inspect its output for suspicious entity names. A correction model can compare a phrase with approved names and decide whether the context supports a change. Research such as DeRAGEC combines candidate retrieval and denoising before attempting to repair named entities. Its authors reported a 28% relative reduction in word-error rate against their uncorrected baseline on the datasets they used. Again, it is an experimental result, not a universal promise. [9]
Post-processing is attractive because it need not disturb the original recogniser. It can be added later, controlled narrowly and disabled if it behaves badly. But a text-only corrector has a fundamental disadvantage: it sees what the recogniser wrote, not necessarily what the speaker said. No amount of elegant language reasoning can recover an acoustic distinction that has vanished from the evidence it receives. For doubtful cases, checking the sound again may be more valuable than asking another text model to sound more confident.
The second error
The obvious measure of a correction system is how many transcription mistakes it fixes. The less obvious measure is how many new ones it creates.
Suppose a meeting assistant sees "Neural Bridge Lab" in a discussion about commercial partnerships. Replacing it with "Neural Bridge Labs" may be reasonable. But if the same sequence appears in an experimental discussion of research facilities, the facts may point elsewhere. And when the available context supports neither interpretation strongly, an accurate system should be allowed to say that it does not know.
That is the logic of abstention. Rather than instructing a language model to polish every suspected error, a narrower system can ask it to choose among three actions: retain the original words, replace a precisely identified span with an approved name, or declare the evidence insufficient. A separate validation step then checks whether an edit is permissible. This is one conservative engineering design, not a claim that every speech service implements it. [10]
Such restraint addresses a real risk in generative correction. Language models are optimised to produce coherent text; when asked to rewrite a transcript, they may improve the prose at the expense of fidelity. A fluent transcription of something that was never said is, for many business purposes, worse than a visibly imperfect one.
The distinction between precision and recall makes the trade-off clear. Precision asks: of the corrections applied, how many were right? Recall asks: of the real errors, how many were fixed? A system can pursue more errors and potentially increase its coverage, but harmful replacements matter too. Neither metric should be interpreted alone. Human-reviewed audio is needed to establish which errors are real.
A company also needs to distinguish ordinary transcription quality from entity quality. Word-error rate is useful, but may overlook a rare company name lost in a sea of correctly transcribed everyday words. Evaluations should therefore track entity errors, false name insertions and damage to already correct passages, as well as overall word-error rate. [1,10]
An audit trail for a spoken sentence
The case for restraint is more than philosophical. In a workplace, one corrected phrase can feed a chain of systems: searchable transcripts, meeting summaries, tasks, reports and later AI assistants. A mistake that spreads across these outputs can become difficult to trace to its source.
For this reason, a defensible correction system should preserve the original transcript, keep a record of each proposed and accepted edit, and generate downstream outputs from the same selected version. The provenance should establish which vocabulary and correction rules were used. If the correction proves wrong, the original must still be recoverable. [10]
This is where the discussion becomes an economic one. It costs money and time to run additional models, maintain vocabularies, review uncertain cases and retain an audit trail. It also costs money to propagate a false company name into customer records or management reporting. The question is not whether the system can correct another word. It is whether the expected benefit of doing so is greater than the cost of being wrong.
That balance depends on the application. A casual caption may tolerate an occasional imperfection. A financial disclosure, clinical note or contractual record may justify far more conservative behaviour and human oversight. A company with 50 trusted names has different engineering needs from a global service juggling 200,000. The latest retrieval techniques are valuable options, but complexity should follow a demonstrated problem, not fashion.
The virtue of not guessing
The most revealing aspect of the new speech-recognition research is that it points in two directions at once. Some systems are becoming better at drawing on enormous bodies of context. Others are learning to make fewer, better justified changes after recognising speech. The strongest practical design may combine these approaches, selecting each only where evidence shows that it helps.
There is no reason to romanticise the uncorrected transcript. A misspelled company name is still an error. But neither should the appearance of a name on an approved list be treated as proof that someone uttered it. Human speech is too varied, and business records too consequential, for that shortcut.
The promise of AI transcription is that the tedious work of recording what people say can increasingly be done by machines. Its next challenge is not simply to hear more words correctly. It is to distinguish what was said from what a machine expected to hear.
An intelligent assistant will sometimes fix your company's name. A trustworthy one will also know when to leave it alone.
Sources and research notes {#sources}
- Klering et al. (2026), "A Dataset for Evaluating ASR on Specialized Vocabulary", LREC. Read source
- Google Cloud Speech-to-Text, "Improve transcription results with model adaptation". Read source
- Microsoft Azure Speech, "Improve recognition accuracy with phrase list". Read source
- Amazon Transcribe, "Improving transcription accuracy with custom vocabularies and custom language models". Read source
- Deepgram, "Keyterm Prompting". Read source
- OpenAI API, "File transcription" (context and keywords). Read source
- Mittal et al. (2025), "RECAST", Findings of EMNLP. Read source
- Gong et al. (2025), "BR-ASR", Interspeech. Read source
- Im et al. (2025), "DeRAGEC", Findings of ACL. Read source
- Illustrative architecture and abstention policy: candidate identification, constrained decisions, validated changes and immutable transcript revisions. This is a design proposal, not a published benchmark or a claim of deployment.