This PR enables hot-word boosting (from the C client) with the two new flags --hot_words and --boost_coefficient.

Can we not limit that to the C-client? It's very much likely people will want to use this part of the API from elsewhere, and in the current state, it's completely unknown whether this works or not.

For example, if KenLM returns -3.5 as the likelihood for the word sequence "i like cheese", if we multiply this number by 0.5, we get -1.75, therefore doubling the likelihood of that sequence.

This isn't how log probabilities work, you're making exponential increases in the probability here. exp(-3.5) ~= 0.03 and exp(-1.75) ~= 0.17. This, combined with the fact that a single word will be boosted several times in the same beam as it appears in multiple n-grams, makes it hard to reason about the behavior of the coefficient. It should probably be an additive factor (multiplication in probability space).

See for example https://www.isca-speech.org/archive/Interspeech_2018/pdfs/2416.pdf

@JRMeyer To keep your API simpler, I suggest you move to a single entry point:

DEEPSPEECH_EXPORT
int DS_AddHotWord(ModelState* aCtx, const char* word, float boostCoefficient)

This entry point would add a new word to your std::vector (or set, maybe, because it would guarantee unicity). If the hot word does not exists, we add it with the given boost, and if it is already in the set, we update the coefficient

Depending on usecase, it could also be cool to expose (though I'm unsure it is really required):

DEEPSPEECH_EXPORT
int DS_ClearHotWords(ModelState* aCtx)

This would simply re-init the set of hot words

With this API, you could more easily expose and update all our bindings (const char ** are a bit painful via SWIG) to make the feature available.

For example, if KenLM returns -3.5 as the likelihood for the word sequence "i like cheese", if we multiply this number by 0.5, we get -1.75, therefore doubling the likelihood of that sequence.

This isn't how log probabilities work, you're making exponential increases in the probability here. exp(-3.5) ~= 0.03 and exp(-1.75) ~= 0.17. This, combined with the fact that a single word will be boosted several times in the same beam as it appears in multiple n-grams, makes it hard to reason about the behavior of the coefficient. It should probably be an additive factor (multiplication in probability space).

Even though my initial intuition was wrong about how the boosting compounds, I still like the UX. Namely, if you're using this feature, and trying to find the right boosting coefficient for your data, you would know to sweep between 0 and 1, which isn't hard.

with an additive effect, the search space now goes from (0,1) to (0,infinity). The math is better, but the UX seems worse. I make the changes in 184189c, but I still have doubts. Thoughts?

Nice @JRMeyer, just missing the following on the IDeepSpeech interface:

        /// <summary>
        /// Add a hot-word.
        /// </summary>
        /// <param name="aWord">Some word</param>
        /// <param name="aBoost">Some boost</param>
        /// <exception cref="ArgumentException">Thrown on failure.</exception>
        public void AddHotWord(string aWord, float aBoost);

        /// <summary>
        /// Erase entry for a hot-word.
        /// </summary>
        /// <param name="aWord">Some word</param>
        /// <exception cref="ArgumentException">Thrown on failure.</exception>
        public void EraseHotWord(string aWord);

        /// <summary>
        /// Clear all hot-words.
        /// </summary>
        /// <exception cref="ArgumentException">Thrown on failure.</exception>
        public void ClearHotWords();

I set these as unsafe void in 5432f56

I set these as unsafe void in

Sorry, I forgot to delete the public, you did it right.

@lissyx -- it's one commit, but all the previous commit messages got appended into the one commit message :/ it doesn't look pretty, but yes it is one commit