FR: from word boosting to phrase boosting + UI performance

[thiswillbeyourgithub]

Congrats on the new release and thanks for implementing phrase boosting via #338 , i'm forking into a new issue it to adress the future of this feature. IIRC you said in one message that you planned this for the 1.11 release so I'm creating this to track the ideas.

Btw: your issue template is making it a bit awkward to create feature requests or ask questions. If you'd rather us use discussions instead I recommend making it explicit in the issue template

First a couple of UI nitpicks:

1. UI wise I don't think I saw anywhere recommendations or warning about the number of terms used. Nor on which chars are not allowed unless trying to add it though. Might have looked too quickly though.
2. Adding a humongous dictionnary slows the UI upon loading the dictionnary panel. Clearing out/resetting the dictionnary also was unexpectedly slow.
3. The import seems to tell the file picker to use .csv only (.txt was not offered in my file picker) but I didn't see details on the format to follow, and just renaming the .txt to .csv worked right away IIRC.
   .

Then on the longer game here:

1. Your implementation boosts words but can't boost phrases and AFAIK you don't support all the characters that are in parakeet's vocabulary. Afaik both are only a frontend limitation and your decoding engine supports it.
2. You don't seem to precompile the dictionary into an optimized trie or something to make it tractable with large lists. On my end the optimized trie + MAES does not kill perfs at all but allows adding an entire field's technical words so I definitely think it's worth it. Especially because it would be opt-in: no one would add a large dict like I do without knowing it would be a bit slower. Also even if it's slower than plain parakeet it's way faster than any model with that kind of technical vocabulary (they're much larger and slower). I have an adaptative min-p gating for choosing tokens and so far I don't think i've really seen extra additions of incorrect words.

[Kieirra]

UI wise I don't think I saw anywhere recommendations or warning about the number of terms used. Nor on which chars are not allowed unless trying to add it though. Might have looked too quickly though.

No hard limit right now, just this note in the panel. I take the point that it's not enough though, I'll add a word counter with a green/yellow/red indicator, and maybe a soft limit.

Adding a humongous dictionnary slows the UI upon loading the dictionnary panel. Clearing out/resetting the dictionnary also was unexpectedly slow.

Yeah I saw that too. The panel isn't virtualized yet so a huge dictionary is slow to load and to reset. Since it's not a recommended setup I hadn't bothered, but you're right that the "not recommended" part isn't obvious enough, so I'll fix it.

The import seems to tell the file picker to use .csv only (.txt was not offered in my file picker) but I didn't see details on the format to follow, and just renaming the .txt to .csv worked right away IIRC.

Yeah, the .csv-only filter is a leftover from my old phonetic algorithm, it needed potentially a language per word back then. That algo is gone now and it's just a word list with one word per line, so a .txt makes total sense, I'll add it.

Your implementation boosts words but can't boost phrases and AFAIK you don't support all the characters that are in parakeet's vocabulary. Afaik both are only a frontend limitation and your decoding engine supports it.

• Characters: agreed, I'll add the missing ones.
• Phrases: I'll pass for now. My boost ramps up the deeper you go into an entry, which is great for a single word since it ends fast, but on a phrase it gets too strong. If the dict has "insuffisance chronique rénale" and you only say "insuffisance chronique", by then the boost is high enough that "rénale" gets forced in. So it's not just a frontend toggle.

You don't seem to precompile the dictionary into an optimized trie or something to make it tractable with large lists. On my end the optimized trie + MAES does not kill perfs at all but allows adding an entire field's technical words so I definitely think it's worth it. [...]

It actually already compiles the dictionary into a trie (Aho-Corasick), with a boost weight that scales down as the list grows, so big lists should stay fine on the decode side. I tested with a big dictionary and saw no transcription slowdown. Did you get real lag while transcribing, or was it only the UI panel?