Voice AI speech recognition needs a word-list test

A word list can help voice AI speech recognition pick up a store term. It can also favor the wrong word. For dealership operations and technology leaders, the useful test includes both cases: the term the caller said and the similar term they did not say.

Do not judge the list only by the names it fixes. Compare the same approved audio with and without the proposed list. Record missed terms and added terms separately. Then check what the agent does with the text. This guide describes an evaluation method, not a new TrafficDriver feature or a measured customer result.

Start with a missed word, not the whole catalog

Suppose a test caller asks about a trim name and the transcript turns it into an ordinary word. That is a specific problem to investigate. Adding every model, trim, employee name, and service term at once makes the change harder to judge.

Keep a short record of the actual failure. Save the approved sample, the words spoken, the text returned, and the step that went wrong next. Use test audio or recordings you are authorized to review. Do not put customer details into a public test tool or a shared glossary.

A product list and a recognition list have different jobs. The product list describes what the store sells. A recognition list supplies context for words that a speech service may hear. Neither list proves that a vehicle is available or that a caller chose it.

Voice AI speech recognition uses provider-specific hints

Speech recognition phrase hints are not the same as instructions for the agent's reply. Google Cloud describes model adaptation as a way to make selected words or phrases more likely in the transcript.[2] That is a change in recognition bias, not proof of the caller's intent.

The request format also matters. Deepgram's current Keyterm Prompting feature accepts plain terms rather than the weights used by its legacy Keywords feature. Separate keyterms use repeated query parameters. Deepgram warns that unsupported formats can be accepted as one literal term without an error.[1]

Ask the integration owner to show which model and feature the call actually uses. A settings screen that saves a list is not enough. The owner should check how the request carries that list and whether the active model supports it. Do this in an approved test setup rather than changing a live account to see what happens.

Do not copy a boost value or list format from a different provider. The names may sound similar while the controls behave differently.

Test the words you do not want added

A list can look successful if the review only includes the desired words. Google Cloud warns that stronger boosting can also produce false matches: a word appears in the transcript even though it was not in the audio.[2]

Build a small comparison set around the known error. Include the intended term in a normal request. Add a similar-sounding phrase that does not contain it. Include routine calls with none of the list terms. Keep the audio and other settings fixed when comparing versions.

For a hypothetical test, use an invented product called "Cedar" alongside the ordinary phrase "seat heater." These are sample phrases, not a claim that a particular model confuses them. Listen to each clip and write the expected words before checking the output.

Count a missed "Cedar" separately from an added "Cedar." A list that fixes one but creates the other has a tradeoff to review. Do not collapse both into a single favorable accuracy statement.

Follow the word into the next action

A transcript is an input to the conversation. It is not the whole customer experience.

After each sample, check the agent's response. Did it ask about the intended vehicle, search the right term, or offer an unrelated service? If it was unsure, did it ask a short clarifying question rather than make a choice for the caller?

Keep recognition and pronunciation separate. Correct text does not prove that the spoken reply sounds right. Listen to the reply as its own check. Likewise, a clear spoken reply cannot repair an incorrect search that happened earlier.

The weekly voice AI review guide explains how to trace a call problem to its owning layer. Use that approach here: change the word list only when the evidence points to recognition, rather than rewriting every prompt after one bad call.

Copy this word-list review sheet

Use one row per sample. Fill the expected words before running the comparison.

Review field	What to record
Audio reference	Approved test clip and who may review it
Expected words	The words the test speaker actually said
Active setup	Provider, model, language, and list version
Original output	Transcript without the proposed change
Changed output	Transcript with the proposed list
Recognition result	Desired term missed, unwanted term added, or neither
Next action	What the agent said or did with that text
Decision	Keep testing, accept within the tested scope, or reject

Keep the comparison sheet with the sample references. Do not describe it as a production benchmark. A limited test can support a limited decision; it cannot establish results for every caller, accent, or phone connection.

Questions to resolve before changing the list

What does a word list control?

It gives the recognizer context for transcription. It does not change inventory facts, confirm a caller's choice, or teach the speech output how to pronounce a name. Ask the integration owner which component receives the list and which parts of the call remain unchanged.

Can a hint create a false match?

Yes. Google Cloud documents that boost can increase the chance of a phrase appearing when it was not spoken.[2] Test nearby words and ordinary requests alongside the desired term. Review both the transcript and the next action instead of counting only the examples that improved.

Can the same settings move between providers?

Do not assume so. Deepgram distinguishes current keyterms from its older weighted Keywords syntax, and warns that some wrong formats do not return an error.[1] Verify the exact active feature and request. A successful request does not establish that the intended terms received the intended treatment.

What does a passing comparison establish?

It shows how the tested setup handled those samples. It does not prove live performance or eliminate the need for a caller to clarify a choice. Keep the sample scope visible, preserve the prior configuration, and use the team's approved change process for any release.

Make the next test specific

Voice AI speech recognition needs more than a long vocabulary list. Start with one known error, compare fixed audio, and look for words the change adds by mistake.

For a walkthrough of the wider call flow, see how TrafficDriver works. To discuss this evaluation with the team, book a demo and bring one approved sample plus the expected words.

Sources

[1] https://developers.deepgram.com/docs/keyterm.md [2] https://docs.cloud.google.com/speech-to-text/docs/adaptation-model