> ## Documentation Index
> Fetch the complete documentation index at: https://www.bolna.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Improving transcription accuracy with keywords and context
> Bias your agent's speech-to-text towards the words your callers actually say. Covers the keywords list, the context field, and what each transcriber provider supports.
Speech-to-text models are trained on general speech. They have never heard your product names, your competitors, or the way your customers say your company's name down a noisy phone line. Left alone, a model transcribes the nearest common word it knows, and your agent answers the wrong question.
Bolna gives you two fields on the transcriber to fix this.
| Field | What it is | Use it for |
| ---------- | -------------------------------------- | --------------------------------------------------------- |
| `keywords` | A comma-separated list of terms | Proper nouns, SKUs, brand names, jargon |
| `context` | A sentence or two of plain description | What the call is about, so the model knows what to expect |
They work together. Keywords tell the model *what the words are*, context tells it *what they mean*.
***
## Quick config
```json theme={"system"}
"transcriber": {
"provider": "assembly",
"model": "universal-3-6-pro",
"language": "en",
"keywords": "Bolna, Plivo, Exotel, Twilio",
"context": "Inbound support line for a voice AI platform. Callers ask about telephony setup, call routing and billing."
}
```
Both fields are optional and both live in `tools_config.transcriber`. You can set either, both, or neither. In the dashboard they sit side by side under the agent's **Audio** tab.
***
## The difference in practice
A caller says *"Hi, I'm calling about my Plivo and Exotel setup on Bolna."*
With no biasing, a general model hears:
```
hi i am calling about my clivo and exodel setup on valna
```
Every proper noun is wrong, and the LLM now has to answer a question about "clivo". With `keywords` set to `Bolna, Plivo, Exotel`:
```
Hi, I am calling about my Plivo and Exotel setup on Bolna.
```
This is not a cosmetic improvement. The transcript is what reaches your prompt, your extracted data and your post-call webhooks, so an ASR error propagates through everything downstream.
***
## Writing good keywords
* **Be specific, not exhaustive.** 20 to 50 terms that actually get misheard beat a dump of your whole catalogue. Every extra term slightly dilutes the boost, and some providers cap the list.
* **Include the terms callers say, not the ones you write.** If your product is "BolnaAI" but people say "Bolna", list "Bolna".
* **Multi-word phrases are fine.** `account number, customer service, order status` is three terms, not six.
* **Do not list common words.** Boosting "the" or "order" costs you accuracy elsewhere.
* **Spell them as you want them transcribed.** The boosted term is what appears in the transcript.
### Weights
Some engines accept a per-term weight using `term:number`:
```
Bolna:5, account number:2, customer service:3
```
Higher means a stronger nudge. Only some providers support this, see the table below. On providers that do not, Bolna strips the `:number` suffix automatically and sends the bare terms, so a config copied from a weighted provider keeps working rather than boosting a term literally named `Bolna:5`. The dashboard shows a warning when it is going to do this.
A colon that is not a weight is left alone, so `3:30 pm` stays intact.
***
## Writing good context
Context is free-form prose. Two or three sentences describing the call is usually enough.
```
Inbound support line for an electronics retailer. Callers ask about order
status, returns and warranty claims, and often read out order numbers.
```
* **Describe the situation, not the instructions.** This is not a prompt for an LLM. "Callers ask about returns" helps, "always transcribe accurately" does nothing.
* **Mention the shape of what callers will say.** Telling the model to expect order numbers, postcodes or dates measurably helps it format them.
* **Keep it short.** Providers cap it, and a wall of text dilutes the signal the same way an over-long keyword list does.
***
## Provider support
Not every engine accepts both fields. Bolna sends each provider only what it can use and drops the rest, so an agent stays valid when you switch providers.
| Provider | `keywords` | Weights | `context` | Limits |
| ------------------------------------- | ---------- | -------------------- | --------- | ----------------------------------- |
| [AssemblyAI](/docs/assemblyai) | Yes | No | Yes | 100 terms, context 1,750 characters |
| [Deepgram](/docs/deepgram-transcriber) | Yes | `nova-2` family only | No | about 500 tokens across all terms |
| [Soniox](/docs/soniox) | Yes | No | Yes | context about 10,000 characters |
| [Sarvam](/docs/sarvam-transcriber) | No | n/a | Yes | n/a |
| [Azure](/docs/azure-transcriber) | Yes | No | No | 2,000 phrases |
| [Smallest](/docs/smallest-transcriber) | Yes | Yes | No | 100 terms |
| [ElevenLabs](/docs/elevenlabs-transcriber) | Yes | No | No | 50 terms |
| [Gladia](/docs/gladia) | Yes | No | No | n/a |
Deepgram's `nova-3` and Flux models use keyterm prompting, which takes plain terms and no weights. The `nova-2` family uses the older keywords parameter, which does accept `term:weight`. Bolna picks the right one from the model you choose.
In the dashboard, a field your provider does not support is shown disabled rather than hidden, so you can see what you would gain by switching.
***
## Multilingual agents
Multilingual agents inherit `keywords` and `context` from the base transcriber for every language leg. You do not need to repeat them per language, and a term list of brand names is usually correct in every language anyway.
***
## FAQ
Start with the 10 to 20 terms you have actually seen mistranscribed in your call transcripts, rather than guessing. Review your transcripts after a day of calls and add what you find. Lists in the hundreds rarely help and can hurt.
No. Biasing raises the probability the model picks your term over a similar-sounding common word. It does not force it. A term that is acoustically very close to a common word, a two-letter brand name for example, may still be missed.
Bolna rejects the agent save with a message naming the limit, so you find out at configuration time rather than mid-call.
No. Context biases recognition, it is not a prompt. Describe the call and the vocabulary; behavioural instructions belong in your agent prompt.
That provider's streaming API has no equivalent field. Switch to AssemblyAI, Soniox or Sarvam if context biasing matters for your use case.
***
## Related
* [Languages Tab](/docs/agent-setup/audio-tab): where both fields live in the dashboard
* [Capturing precise transcripts](/docs/customizations/capturing-precise-transcripts): how Bolna reconstructs transcripts around interruptions
* [Create Agent API](/docs/api-reference/agent/v2/create): the full transcriber schema