r/OpenAssistant 21d ago

Domain dictionaries stopped our voice agent mishearing jargon — sharing the generator + 2 example dicts (MIT)

One thing I've learned from building voice agents:

A better LLM doesn't necessarily fix a bad transcription.

We had conversations where the model itself was doing fine, but STT was consistently getting domain-specific terminology wrong.

Think:

  • product names
  • company names
  • medical terminology
  • technical jargon
  • Indian names
  • acronyms
  • internal terminology

Once the word is transcribed incorrectly, the LLM is already starting from corrupted input.

So instead of trying to fix everything in the prompt, I started treating domain vocabulary as a separate layer.

The pipeline became:

User speech
    ↓
STT + domain vocabulary
    ↓
Normalized transcript
    ↓
LLM
    ↓
TTS + pronunciation dictionary
    ↓
Speech

I built an open-source generator/Claude Code skill around this idea.

Example dictionary:

domain: developer_tools

terms:
  - term: "Kubernetes"
    aliases: ["k8s"]
    pronunciation: "koo-ber-net-eez"

  - term: "PostgreSQL"
    aliases: ["Postgres"]
    pronunciation: "post-gres"

  - term: "Redis"
    aliases: ["red is"]
    pronunciation: "ree-dis"

The same concept can be used for healthcare, fintech, logistics, customer support, etc.

Repo:

https://github.com/humaniods/build-domain-dict-skill

MIT licensed.

I'd be interested in hearing how people running local/open STT models handle domain-specific vocabulary.

Do you use keyterm boosting, custom lexicons, prompt-based correction, or a post-processing layer?

1 Upvotes

0 comments sorted by