Fix Jargon Errors in Transcription: The Glossary Pass

Why Jargon Breaks

The short answer: the word was never in the model's training distribution. AI transcription models learn from millions of hours of audio, but that data skews heavily toward everyday conversation. "Kubernetes" appears in a fraction of a percent of training utterances. "Electrocardiogram" appears even less. So when the acoustic signal arrives, the model substitutes phonetically similar words it does know. "Kubernetes" becomes "cuban itties." "PostgreSQL" becomes "postgrass quill." "gRPC" gets written as "g-rpc" with a stray hyphen.

The substitutions are predictable, not random. The model is doing exactly what it was trained to do: pick the highest-probability word sequence given the sounds. The problem is that probability reflects general English, not your domain. This is the training distribution gap, and it explains why the garbling is consistent, not scattered. Every time a speaker says "Kubernetes" in that recording, the transcript says "cuban itties."

The good news is the fix is structural. Solve the distribution gap once, and the problem largely disappears for every subsequent transcript in that domain.

Three Fix Paths, Ranked by Setup Cost

Path 1: Find-and-Replace (Quick, Per-Transcript)

For a single transcript with a handful of garbled terms, find-and-replace takes under 10 minutes and scales to any tool. Build a substitution list as you read the output:

cuban itties     → Kubernetes
postgrass quill  → PostgreSQL
g-rpc            → gRPC
docker compose   → Docker Compose
postgres equal   → PostgreSQL

Run find-and-replace for each pair. Save the list. On the next transcript covering the same topic, apply the list before you start reading. You get most of the value from the first 20 substitutions.

The ceiling is clear: this is reactive and transcript-specific. It is the right call for a one-off recording. It is the wrong architecture for a team producing 50 transcripts a week.

Path 2: Custom Vocabulary and Keyterm Prompting (Permanent Fix)

Custom vocabulary tells the engine which terms to prioritize before it ever hears a word. Most production-grade APIs now support this natively, and the setup is a one-time cost.

The implementations differ by platform:

A few verified details worth knowing:

Deepgram Nova-3 keyterm prompting (verified July 2026): pass keyterm=TERM as a query parameter, repeating it for each term. Per Deepgram's documentation, terms are limited to 500 tokens total per request; the practical recommendation is 20-50 high-value terms. Keyterm prompting is specific to Nova-3 models and Flux; the older Nova-2 uses a separate keywords parameter.

AssemblyAI keyterms prompting is currently documented for streaming transcription, with up to 100 terms at 50 characters each. The parameter is keyterms_prompt in the streaming configuration. For batch transcription, AssemblyAI's legacy word_boost parameter with boost_param values of low, default, or high still applies.

OpenAI Whisper API prompt parameter: the prompt field accepts up to 224 tokens and works by having the model emulate the spelling patterns of whatever you include. Per OpenAI's cookbook (checked July 2026), natural sentence-style prompts outperform bare lists. Write "The engineer discussed Kubernetes clusters and PostgreSQL replication" rather than "Kubernetes, PostgreSQL." The model copies your spellings. It cannot add information that is not in the audio, but it will strongly prefer the spellings you gave it.

AWS Transcribe custom vocabulary: uses a four-column table format (Phrase, IPA, SoundsLike, DisplayAs) uploaded to S3. Up to 100 vocabulary files per account, 50 KB per file, 256 characters per entry. The medical variant (Amazon Transcribe Medical) supports a separate vocabulary for clinical terms, US English only.

The workflow for a permanent fix on any of these:

1. Build a list of 30-100 terms that recur in your domain.
2. Upload or pass the list to your engine's vocabulary feature.
3. From that point forward, every transcription in that domain benefits.
4. Review and extend the list quarterly as your vocabulary evolves.

For API-based workflows, see the best speech-to-text APIs comparison for 2026 for a side-by-side of which engines handle custom vocabulary with the least friction.

Path 3: Domain-Specific Model Training (Heavy Setup, Best Ceiling)

For very high-volume, single-domain transcription, a fine-tuned model outperforms vocabulary hints on the hardest terms. This is what Deepgram Nova-3 Medical represents: a model pre-trained on clinical audio, not a base model with a vocabulary list attached. AWS Transcribe Medical takes a similar approach. Azure Custom Speech lets you train on your own labeled audio.

The cost-benefit inflection point is rough: below roughly 50,000 minutes per month of domain-specific audio, custom vocabulary on a strong base model is more practical than model training. Above that, the accuracy and maintenance tradeoffs start favoring a fine-tuned model.

For most teams reading this, Path 2 is the answer.

Building a Good Vocabulary List

A well-built list shares characteristics across domains, regardless of the transcription tool.

Product and Technology Names

Every product your conversations reference, including your own, your competitors', and your vendors'. "Kubernetes" and "K8s" may both need separate entries since the model encounters each phonetically differently. "PostgreSQL" and "Postgres" are worth separate entries for the same reason.

Acronyms as You Want Them Written

Technical acronyms that the model would otherwise expand or mangle. Write them exactly as they should appear in the transcript: "gRPC" not "g-r-p-c," "SaaS" not "sass," "DDoS" not "duh-dos," "LLM" not "elm." The DisplayAs column in AWS Transcribe and the string format in Deepgram keyterms both let you specify the output form precisely.

Compound Terms and Multi-Word Phrases

Phrases the model might break apart incorrectly. "Test-driven development" passed as a keyterm produces that exact phrase rather than three disconnected words. "Myocardial infarction" handled as a unit transcribes more reliably than each word individually.

Specialized Jargon

The terms that only practitioners in your field use regularly. For security: specific CVE patterns, exploit frameworks, protocol names. For medicine: drug names by their clinical designation (not just brand names), procedure names, anatomical terms. For legal: Latin phrases, specific doctrines, procedural motion types.

Names That Sound Like Common Words

Some names for people, companies, or technologies collide phonetically with common English. "Apache" the server project versus the everyday word. "Vue" the JavaScript framework. "Rust" the programming language. "Swift" the language. The model needs a strong prior to avoid interpreting them as their dictionary meanings.

Domain Reference Lists

These are starting points, not complete solutions. Read your first transcript and add whatever the model got wrong.

Software Engineering

Kubernetes, k8s, PostgreSQL, Postgres, gRPC, GraphQL, Docker,
TypeScript, async/await, monorepo, microservices, OAuth, JWT,
SQLite, MongoDB, Cassandra, Kafka, Redis, Elasticsearch,
LangChain, OpenAI, Anthropic, Claude, GPT-4o,
WebAssembly, WASM, RAG, vector database, embedding

Medical

electrocardiogram, ECG, EKG, echocardiogram, defibrillator,
endotracheal intubation, laparoscopic, cholecystectomy,
metformin, lisinopril, atorvastatin, amoxicillin, ondansetron,
hypertension, hyperlipidemia, hypothyroidism, diabetes mellitus,
osteoarthritis, atrial fibrillation, myocardial infarction

Legal

voir dire, habeas corpus, prima facie, mens rea, res ipsa loquitur,
amicus curiae, certiorari, en banc, stare decisis, sub judice,
deposition, interrogatory, subpoena, discovery, motion in limine,
summary judgment, demurrer, appellate, statute of limitations

Finance

EBITDA, ARR, MRR, churn, LTV, CAC, IRR, NPV, IPO, SPAC,
revenue recognition, accrual basis, deferred revenue, GAAP, IFRS,
preferred stock, common stock, dilution, cap table, term sheet,
liquidation preference, anti-dilution, mezzanine

For proper nouns that belong to a specific person rather than a domain, the fix for mistranscribed names covers the same mechanism with personal name examples.

Tool Choice Matters for Jargon-Heavy Work

Not all transcription tools expose vocabulary controls to regular users. The tools worth using for specialized domains:

Deepgram Nova-3 via API: keyterm prompting is well-documented and takes effect immediately per request. No upload step, no waiting period.

AssemblyAI via API: word_boost for batch, keyterms_prompt for streaming. Both are request-level parameters.

AWS Transcribe: custom vocabulary files require an S3 upload and a creation step before they are usable, but they persist and can be reused across jobs.

AWS Transcribe Medical: a separate product with a preloaded clinical vocabulary and US English support. The medical custom vocabulary feature adds to that base.

Google Cloud STT (Chirp 3): speech adaptation phrases are passed per-request, similar to Deepgram. Chirp 3 is the current generation as of mid-2026.

OpenAI Whisper API via prompt parameter: weaker than dedicated custom vocab features, but zero setup. Useful when the jargon list is short (under 30 terms) and the prompt fits in 224 tokens.

Tools that will struggle regardless of your vocabulary work: browser-based tools using the Web Speech API, and any free-tier service that does not expose vocabulary parameters at all.

My take: for a team with stable domain vocabulary, Deepgram Nova-3 keyterm prompting is the lowest-friction path from jargon-garbled to clean. The vocabulary takes effect immediately, requires no upload step, and costs nothing extra beyond the per-minute rate. For medical specifically, Nova-3 Medical is purpose-built enough that it often handles clinical terminology without any custom terms at all.

If you just need a clean transcript without managing an API integration, ConvertAudioToText's audio-to-text tool supports file upload for a direct turnaround. Use the corrected output to build your substitution list, then graduate to API-level vocabulary controls once your term list stabilizes.

When AI Still Loses to a Human

Some jargon is genuinely out of reach for AI transcription, even with vocabulary controls:

• Drug names from clinical trials that postdate any model's training cutoff.
• Narrow subfields of engineering where the vocabulary has never appeared in any public audio corpus (semiconductor process chemistry, for instance).
• Archaic legal terminology that appears in few modern recordings.

For those cases, a human transcriber with domain expertise is the honest answer. The AI vs human transcription post covers when that escalation makes financial sense. For everything else in 2026, custom vocabulary on a strong base model plus a light manual proofread produces publication-quality results.

Common Questions

Why does the model transcribe general words correctly but fail on domain terms?

The model's probability estimates come from its training data. Common English words appear millions of times; domain terms appear rarely or not at all. When the model hears "Kubernetes," the phonetic signal matches "cuban itties" more strongly in the training distribution than the correct term, so the wrong output wins. Vocabulary controls override that prior by explicitly boosting the target terms.

Does the Whisper API support custom vocabulary?

Not with a dedicated vocabulary feature. The prompt parameter (224-token max) accepts example text, and the model will try to match the spellings in your prompt. Writing a natural sentence that uses your technical terms as they should appear ("The team migrated the PostgreSQL cluster to Kubernetes") is more effective than listing bare terms. For serious jargon problems, Deepgram or AssemblyAI with proper vocabulary APIs are more reliable.

How many terms should I put in my vocabulary list?

Start with the 20-30 terms that caused the most errors in your first transcript. Deepgram Nova-3 supports up to 500 tokens (~100 terms) per request. AssemblyAI streaming allows up to 100 terms at 50 characters each. AWS Transcribe files can hold more, but larger vocabulary lists sometimes hurt accuracy on terms that are not actually present in the audio, so smaller focused lists tend to outperform kitchen-sink lists.

Does custom vocabulary help with acronyms or only full words?

Both. Acronyms are often the highest-value entries because the model frequently expands them ("SaaS" to "sass," "gRPC" to "g rpc"). Pass the acronym in the exact output format you want: gRPC, DDoS, LLM. On platforms like AWS Transcribe where you specify a DisplayAs field, you have precise control over capitalization and punctuation in the output.

Sources

• Deepgram Keyterm Prompting documentation (checked July 2026): https://developers.deepgram.com/docs/keyterm
• Deepgram Nova-3 Medical announcement: https://deepgram.com/learn/introducing-nova-3-medical-speech-to-text-api
• AssemblyAI Streaming Keyterms Prompting blog post: https://www.assemblyai.com/blog/streaming-keyterms-prompting
• AWS Transcribe Custom Vocabularies documentation (checked July 2026): https://docs.aws.amazon.com/transcribe/latest/dg/custom-vocabulary.html
• AWS Transcribe Medical Custom Vocabularies: https://docs.aws.amazon.com/transcribe/latest/dg/vocabulary-med.html
• Google Cloud Speech-to-Text Speech Adaptation: https://docs.cloud.google.com/speech-to-text/docs/adaptation-model
• OpenAI Whisper Prompting Guide: https://developers.openai.com/cookbook/examples/whisper_prompting_guide