Nova-2 models fail when specifying alternatives in request

[antxv]

Which Deepgram product feature are you using?

Deepgram API - STT Streaming

Details

When using the streaming API with the Go SDK, you can set the Alternatives live transcription option to get multiple transcript possibilities. This works fine for the enhanced-general model, but fails when the nova-2 model is used. To reproduce, edit the streaming microphone example to add Alternatives: 3 to the live transcription options. Transcription fails when you do this, and connection errors are reported in logging.

If you are making a request to the Deepgram API, what is the full Deepgram URL you are making a request to?

No response

If you are making a request to the Deepgram API and have a request ID, please paste it below:

No response

If possible, please attach your code or paste it into the text box.

No response

If possible, please attach an example audio file to reproduce the issue.

No response

[team-deepgram]

Thanks for asking your question about Deepgram! If you didn't already include it in your post, please be sure to add as much detail as possible so we can assist you efficiently, such as:

• The request_id if you have a question about your requests or transcription responses.
• The features you used or the full api.deepgram.com URL you sent your request to, including parameters.
• Any code snippets you can share.

[dvonthenen]

hi @antxv

Alternatives is no longer supported in nova-2.

The goal is to make it just to give you the correct transcription. Having said that... That is easier said than done. With all the advances in speech recognition, the need for Alternatives isn't needed. I would bet that in most modern (as in the past few months) and advanced (like DG) transcription models, any second plausible transcription of a given audio probably has such a low probability of correctness that it isn't worth generating.

[antxv]

Hello, thanks for the response. It would be good to document this somewhere. It took me a while to figure out that my code was failing due to the alternative setting.

Having alternatives is the only way to apply any custom biasing. I am the lead developer for Utterly Voice, which can be configured to use Deepgram and other recognizers. The application applies bias to each possible transcript using regular expressions. The keyword approach used by Deepgram is insufficient when trying to listen for possible voice commands in the transcript. In addition, the maximum of 100 keywords is too small for our use case.

I disagree about the plausibility of a second transcription possibly being correct. My application can infer the context for short audio better than the recognizer: "stuff he knows" versus "stuffy nose".

[dvonthenen]

Yeah, the parameter should no longer be documented, and the field should be deprecated. It still exists in code because there are certain "legacy" models which this is required. I will look into seeing how we can better expose this deprecation notice in code.

[dvonthenen]

I will pass your note along to engineering about alternatives.

I think there is a revamp coming in this area.

Not sure if you are aware, but we have a conversationalai model for voice commands. I haven't used it myself, but one of the listed use cases is for command type prompts for voice assistants.

[antxv]

Thanks, let them know that I am happy to discuss further if it would help.

I am trying out the conversationalai model now. Using it to enter this comment. So far, it seems to work pretty well.