The Silent English Default

"The model wasn't bad at Korean. Nobody ever told it the audio was Korean."

The Bug Report

Early Firekeeper had a damning symptom: Korean dictation came out as garbage — English-ish word salad that had nothing to do with what was said. English dictation was fine. The obvious conclusion — "WhisperKit is bad at Korean" — was completely wrong, and chasing it would have wasted days. The real cause was a single default buried in the decoding options.

What the Default Actually Does

WhisperKit's default DecodingOptions are usePrefillPrompt: true, language: nil, and detectLanguage: false. Read those three together and the trap is obvious: prefill is on, no language is set, and detection is off — so the decoder prefills the English language token and never reconsiders. Every utterance is force-decoded as English. Feed it Korean and it does its best to hear Korean sounds as English words. The output isn't a Korean transcription failure; it's a perfect English transcription of audio that was never English.

usePrefillPrompt: true   +   language: nil   +   detectLanguage: false
            |                     |                        |
            v                     v                        v
   prefill a language      you didn't pick one     don't auto-detect either
            \_____________________|________________________/
                                  v
              defaults to the English token -> Korean decoded as English

The Fix Is One Line of Intent

You must always tell WhisperKit the language, one of two ways: set language explicitly ("ko" or "en") when you know it, or set detectLanguage: true when you want it inferred from the audio. Never ship the silent default. Firekeeper exposes this as a language mode in settings — Auto, 한국어, English — and Auto maps to audio language detection, not to "whatever the library felt like."

A silent default is worse than a loud failure. If WhisperKit had thrown an error on ambiguous language, the bug would've been found in minutes. Instead it quietly did something plausible-looking and wrong. When you wrap any model, audit its defaults for this shape: a setting that 'works' on the happy path and silently corrupts everything else.

I almost filed this under 'WhisperKit needs a better Korean model.' Dad's instinct was sharper: "It's too confident to be a model problem. A bad model is uncertain; this is certain and wrong. Something is telling it the answer." That reframe pointed straight at the prefill token. Confidently wrong is a configuration smell, not a capability smell.

Code

The trap and the fix·swift

// TRAP — the library defaults silently force English:
// usePrefillPrompt: true, language: nil, detectLanguage: false
let result = try await whisperKit.transcribe(audioArray: samples)
// Korean in -> English word-salad out. Looks like a Korean bug. It isn't.

// FIX — always state intent. Either force the language you know...
var options = DecodingOptions()
options.language = languageMode == .korean ? "ko" : "en"

// ...or ask the model to detect it from the audio (the 'Auto' mode):
if languageMode == .auto {
    options.language = nil
    options.detectLanguage = true
}
let result = try await whisperKit.transcribe(audioArray: samples,
                                             decodeOptions: options)

Exercise

Find a library you use that has a default which 'just works' for the common case. Ask: what does it silently do in the uncommon case, and would that failure be loud or quiet? If quiet, write down the one explicit setting you'd always pass to make the intent visible.

Hint

The dangerous defaults are the ones tuned for the maintainer's most common scenario (here, English audio). If your scenario differs (Korean, mixed language), the default doesn't error — it quietly does the wrong thing. Passing the setting explicitly, every time, is cheap insurance against a silent corruption you'd otherwise misdiagnose for days.

The Bug Report

What the Default Actually Does

The Fix Is One Line of Intent

Code

External links

Exercise

Progress

Comments 0