Summary

• Fixes Fluent Speech Commands WER wrong since eos is counted as token #2863: WER was inflated because the eos (end-of-sequence) token was included in predicted sequences during metric computation
• The decoded eos token (appearing as ⁇) was being counted as insertion errors, causing e.g. ~33% WER on perfectly predicted utterances
• Uses the existing filter_seq2seq_output utility from speechbrain.decoders.utils to strip eos tokens from predicted sequences before decoding and WER/CER evaluation

Affected recipes

All SLU recipes that use seq2seq decoding with tokenizer.decode_ids() were affected:

• recipes/fluent-speech-commands/direct/train.py
• recipes/timers-and-such/direct/train.py
• recipes/timers-and-such/direct/train_with_wav2vec2.py
• recipes/timers-and-such/decoupled/train.py
• recipes/timers-and-such/multistage/train.py
• recipes/SLURP/direct/train.py
• recipes/SLURP/direct/train_with_wav2vec2.py
• recipes/SLURP/NLU/train.py

Root cause

The beam searcher returns predicted token sequences that may contain the eos token (index 0). When these sequences are passed directly to tokenizer.decode_ids(), the eos token ID gets decoded by SentencePiece as ⁇, which is then included in the WER computation as extra tokens (insertions).

Fix

Each affected recipe now wraps the token sequence with filter_seq2seq_output(utt_seq, eos_id=self.hparams.eos_index) before passing to decode_ids(). This truncates the sequence at the first eos occurrence, matching the expected behavior described in the issue.

Test plan

• Verify that WER computation no longer includes the eos token for the fluent-speech-commands recipe
• Verify that the fix does not affect training loss (only evaluation metrics)
• Run the fluent-speech-commands recipe and confirm wer_test.txt no longer shows ⁇ insertions