웨이크 워드(Wake Word)를 로컬에서 실행하는 것이 핵심입니다. 대안은 사용자의 방 소리를 24시간 내내 업체에 스트리밍하는 것인데, 누군가 이름을 부르기 전까지는 아무것도 네트워크에 도달해서는 안 됩니다. 이러한 제약 사항이 아래에서 언급할 대부분의 문제를 야기합니다. 우리는 Windows, macOS, Linux에서 커스텀 문구가 "Hey Google"처럼 작동하도록 만드는 데 수개월을 보냈으며, 우리가 배운 대부분은 값비싼 대가를 치르고 얻은 것들입니다.

1. 볼륨 문제부터 시작하지 마세요
   "내가 소리를 질러야만 작동한다"는 것은 누구나 처음으로 떠올리는 가설입니다. 우리는 확인하기도 전에 두 번의 별도 게인(Gain) 수정을 배포했고, 그 후 로그를 확인해보니 실패하는 모든 시도 동안 마이크가 -10 ~ -22 dBFS라는 건강한 수치에 머물러 있었습니다. 무엇인가를 튜닝하기 전에 실패하는 순간의 실제 RMS를 추출하세요. 수치가 괜찮아 보인다면, 문제는 다른 곳에 있는 것입니다.

2. "두세 번은 시도해야 한다"는 것은 보통 로컬 모델이 끼어버렸음을 의미합니다.
   이는 로컬 추론(Local-inference) 실패 모드이며, 직접 찾아보지 않는 한 보이지 않는 상태로 유지됩니다. ctranslate2나 ONNX 세션과 같은 네이티브 엔진은 스레드 안전(Thread-safe)하지 않으며, 경합(Contention)이 발생하면 깔끔하게 실패하는 것이 아니라 멈춰버립니다(Hang). 우리의 경우, 웨이크 경로가 하루에도 수십 번씩 한 번에 수십 초 동안 완전히 먹통이 되곤 했습니다. 이것이 바로 "두 번 말해야 하는" 경험의 실체입니다. 첫 번째와 두 번째 시도는 데드 윈도우(Dead window) 안에 들어가고, 세 번째 시도가 복구된 후에야 들어가는 것입니다. 사용자들은 이를 불안정성(Flakiness)으로 보고하지만, 실제로는 반복적인 짧은 중단에 가깝습니다. 타임아웃(Timeout)으로는 해결할 수 없습니다. 타임아웃은 아무것도 없는 상태에서 얼마나 기다릴지를 제한할 뿐, 엔진을 복구해주지는 않습니다. 해결책은 인스턴스별 비차단(Non-blocking) 잠금(Lock)과 연속적인 실패가 일정 횟수 이상 발생했을 때 강제로 재빌드(Rebuild)하는 것입니다. 우리는 2회 실패 후 재빌드합니다.

3. 지원하는 가장 사양이 낮은 기기를 기준으로 예산을 잡으세요
   웨이크 모델은 사용자가 실행 중인 다른 모든 것과 CPU를 공유하며, 워크스테이션과 노트북 사이의 격차는 단순한 오차 수준이 아닙니다. 동일하게 녹음된 웨이크 스트림을 기준으로 측정했을 때, 2개의 CPU 스레드에서 실행된 작은 모델은 첫 번째 시도에서 13번 중 8번을 맞췄으며, 단어 끝에서 트리거까지의 중앙값은 1097ms였습니다.

GPU에서 실행된 더 큰 모델은 13번 중 11번을 225ms 만에 맞췄습니다. 모델과 그 아래의 하드웨어 외에는 차이점이 없었습니다. 만약 GPU가 있는 장비에서만 테스트한다면, 대부분의 사용자에게 고장 난 것처럼 느껴지는 제품을 출시하게 될 것이며, 그 문제를 재현할 수도 없을 것입니다.

4. 웨이크 워드(Wake Word)를 전사 내용(transcript content)으로 필터링하지 마세요. 작은 로컬 모델들은 짧은 고유 명사(proper nouns)를 처리하는 데 어려움을 겪으므로, 재현율(recall)을 높이기 위해 모델에 해당 문구를 미리 입력(priming)하는 것이 일반적인 해결책입니다. 하지만 그 대가로, 프라이밍(primed)된 모델은 침묵 속에서도 해당 문구를 만들어내게 되며, 빈 방에서도 오작동(false wakes)이 발생하기 시작합니다. 명백한 방어책은 해당 단어를 포함해야 하는 두 번째 비프라이밍(unprimed) 패스를 거치는 것입니다. 하지만 이 방어책은 실제 웨이크(real wakes)를 거부합니다. 비프라이밍 모델은 실제 음성에서도 동일한 단어를 뭉개뜨립니다. 예를 들어, "Mythos"는 "Mütos"로, "Fable"은 "Farbe"로 돌아옵니다. 모든 웨이크 워드는 어떤 기계의 어떤 모델에게는 어휘 목록(out of vocabulary) 밖에 있습니다. 따라서 콘텐츠 체크는 유령(ghost, 오작동)을 잡아내는 비율과 거의 비슷한 비율로 진양성(true positives, 실제 작동)을 버리게 되며, 두 가지를 구분할 수 있는 유사도 임계값(similarity threshold)도 존재하지 않습니다. 왜냐하면 유령은 해당 문구를 깨끗하게 렌더링한 것이고, 실제 웨이크는 지저분하게 렌더링된 것이기 때문입니다. "침묵 속에서 발화(Fires on silence)"와 "자신의 이름에 귀머거리가 됨(goes deaf on its own name)"은 하나의 버그를 양쪽 끝에서 바라본 모습일 뿐입니다. 우리는 이들을 별개의 티켓으로 추적하며 몇 주를 보냈습니다. 그 대안은 단어에 구애받지 않는 검증(word-agnostic verification)입니다. 즉, 매칭 지점의 원시 오디오 에너지(raw audio energy), 후보 구간(candidate span)의 형태(지속 시간, 단어 수), 그리고 프리 디코더(free decoder)의 신뢰도(confidence)를 활용하는 것입니다. 이 모든 것은 설정된 문구로부터 도출되는 것이지, 문구의 철자(spelling)로부터 도출되는 것이 아닙니다. 철자 일치 방식은 웨이크를 수락할 수는 있지만, 결코 거부할 수는 없습니다.

5. 윈도우(windows) 단위가 아닌 녹음된 스트림(recorded streams)으로 벤치마크하세요. 윈도우당 타이밍(Per-window timings)은 모델이 빠르다고 기분 좋게 알려줄 수 있지만, 정작 사용자는 트리거를 작동시키지 못할 수도 있습니다. 실제 웨이크 시도를 캡처하여 전체 탐지 경로(detection path)를 통해 다시 재생해 보세요. 한 라이브 세션에서는 26분 동안 288개의 전사(transcriptions)가 기록되었지만 매칭은 0건이었으며, 간신히 성공한 웨이크들은 사용자가 허공에 대고 반복해서 말하는 "Hey Hey Nova"와 같은 형태였습니다.

다섯 가지 팁 모두를 약화시키는 한 가지 주의 사항은 웨이크 워드 (Wake Word)에 부적절한 아키텍처 (Architecture)를 사용하는 것이며, 로컬 (Local)로 구현하는 것은 이를 개선하기보다 오히려 악화시킨다는 점입니다. 왜냐하면 단순히 예/아니오(yes-or-no) 질문에 답하기 위해 사용자의 CPU를 사용하여 전체 음성-텍스트 변환 (Speech-to-Text) 과정을 거치는 비용을 지불해야 하기 때문입니다. "Hey Google"은 아무것도 전사 (Transcription)하지 않습니다. 대신 해당 문구 하나만을 위해 학습된 작은 신경망 키워드 스포터 (Keyword Spotter)를 실행하며, 프레임당 몇 밀리초 (ms) 내에 처리됩니다. 이는 끼어들기(wedge)가 불가능하고, 틀릴 전사 결과물 자체가 없으며, GPU 없이도 노트북에서 편안하게 실행됩니다. 위에서 언급한 모든 내용은, 전사 기반의 웨이크 워드를 직접 구축하기 전까지 이를 사용 가능한 수준으로 유지하기 위해 치러야 하는 비용입니다. 구현 내용과 회귀 테스트 (Regression Tests)는 오픈 소스인 Personal Jarvis에 포함되어 있습니다. /u/InternationalGap3698 제출 [link] [comments]