「반 상자」가 「만박(엑스포)」이 될 때 ── 남기는 전사(Transcription)와 다듬는 전사, AmiVoice는 무엇을 남기고 무엇을

§1. AmiVoice의 하이브리드와 E2E, 같은 발화를 던지면 다른 결과가 돌아온다

AmiVoice의 범용 일본어 엔진에는 「하이브리드 (Hybrid)」와 「End to End (E2E)」 두 가지가 있다. 실제 음성을 병행하여 던져보니, 돌아온 텍스트는 서로 달랐다.

컵라면, 반 상자, 주방

을 E2E에 던지면, 돌아온 결과는 **컵라면, 만박(엑스포), 주방.**이었다.

에 그러니까, 뭐, 컵라면 4개

를 던지면, 하이브리드는 같은 음성을 **지금, 컵라면 4개.**라고 적었다. 「반 상자」는 「만박(엑스포)」이 되고, 「에 그러니까, 뭐」는 「지금」이 된다.

보인 것은 정확도의 차이가 아니라, 「무엇을 남기고 무엇을 버릴 것인가」라는 전사 (Transcription) 방식의 차이였다.

이전 기사에서 방재 비축 관리 앱의 음성 입력을 100건의 발화 패턴으로 공략했던 이야기를 썼다. 그 과정에서 궁금했던 점이 「ASR (음성 인식) 자체는 인간의 흔들림(Fluctuation)을 어떻게 다루고 있는가」라는 질문이었다. 「아니야」, 「반 상자」, 「에 그러니까, 뭐」 ── 사람은 내용만을 말하는 것이 아니다. 이러한 흔들림을 하이브리드와 E2E는 어떻게 처리하고 있는가.

본 기사에서는 AmiVoice의 하이브리드와 E2E에 동일한 실제 음성 30건을 병행하여 던지고, **정정 · 모호함 · 필러 (Filler)**라는 세 가지 흔들림을 하이브리드와 E2E가 어떻게 다루는지 측정했다.

§2. 왜 이 비교가 필요한가 ── 방재 비축을 음성으로 등록하는 서비스의 현장에서

오스소구라(おすそぐら)에서의 음성 입력

나는 「오스소구라」라는 방재 비축 재고를 관리하는 서비스를 만들고 있다. Web 앱 + Apple Watch 앱으로, 가정에 있는 보존식이나 물을 소비 기한별로 기록해 두는 서비스다.

비축품은 수가 많고, 새로 사거나 소비하는 일이 빈번하게 일어난다. 수동 입력으로 재고를 관리하는 것은 지속되지 않는다. 그래서 음성 입력을 구현했다. Apple Watch를 향해 「컵라면 4개, 유통기한 2027년 3월, 주방」이라고 발화하면, 후단의 LLM (대규모 언어 모델)이 JSON으로 구조화하여 재고가 늘어난다.

개발을 진행하면서 곧바로 깨달은 것이 있다. 인간의 발화에는 내용만 포함되어 있는 것이 아니다.

• 「에 그러니까, 컵라면, 4개」 ── 필러 (Filler)
• 「컵라면 4개, 아니, 6개」 ── 정정 (Correction)
• 「컵라면, 반 상자, 주방」 ── 모호한 수량 표현
• 「아마도, 주방」 ── 모호한 위치 표현

이러한 「흔들림」을 어떻게 다루느냐가 서비스의 경험을 결정한다.

엔진 선정이 결정하는 것

ASR (음성 인식 엔진)이 흔들림을 어떻게 텍스트로 만드느냐에 따라 후단의 모든 것이 바뀐다.

• 후단 LLM으로의 입력 ── 필러를 남길 것인가, 깎아낼 것인가
• DB에 저장하는 텍스트 ── 「반 상자」 그대로 저장할 것인가, 「만박(엑스포)」으로 변할 것인가
• 검색 인덱스 (Search Index)의 질 ── 불필요한 단어가 섞이는가
• 현장 작업자가 검토하는 수고 ── 사용자가 결과를 확인하는 UI에서 어떤 텍스트를 보여줄 것인가

AmiVoice에는 범용 일본어용으로 하이브리드와 E2E 두 가지 엔진이 있다. 공식적으로는 다음과 같이 안내되어 있다.

신규 이용이라면 우선 E2E를 시도할 것, 업계 특화 어휘나 하이브리드 고유의 기능이 필요하다면 하이브리드.

하지만 그럼에도 「무엇이 상실되는가」는 공식 안내만으로는 보이지 않았다. 「컵라면 4개, 유통기한 2027년 3월, 주방, 아, 아니, 6개」 ── 이것은 숫자를 포함한 단발성 발화이지만, 정정도 포함되어 있다. 어느 쪽을 선택해야 할지 안내만으로는 판단할 수 없다.

그렇기에 실제 음성으로 측정해 볼 필요가 있었다.

§3. 검증 설계 ── 30건의 실제 음성과 3축의 분석

3가지 질문과 30건의 선정

이전 기사에서 오스소구라의 음성 입력을 100건의 발화 패턴으로 공략했던 이야기를 썼다. 「컵라면 4개, 아니, 6개」, 「코코아... 가루로 된 것」, 「아마도 주방」 ── 방재 비축 음성 등록 시 실제로 일어날 수 있는 흔들림이 있는 발화를 100건 준비해 두었다.

본 기사에서는 그 100건 중에서 「인간의 흔들림」이 특히 나타나는 카테고리를 3개 추출하여, 각 10건씩 총 30건을 실제 음성으로 녹음했다. 이는 ASR에 던지는 3가지 질문에 대응한다.

카테고리(질문)	건수	예시
수량 모호성 ── 모호함은 어떻게 다뤄지는가	10건	「컵라면, 반 상자, 주방」
필러(Filler) ── 필러는 어떻게 다뤄지는가	10건	「에-, 그러니까, 컵라면 4개… 아마 주방」
정정 발화 ── 정정은 어떻게 다뤄지는가	10건	「컵라면 4개, …아, 아니, 6개」

녹음은 Apple Watch를 향해 직접 발화하였으며, 16 kHz mono PCM 방식의 wav 파일로 저장했다.

하이브리드와 E2E에 병행 투입

각 wav 파일을 AmiVoice의 두 가지 엔진 ── **하이브리드 (-a-general)**와 **E2E (-a2-ja-general)**에 병행으로 투입한다. 두 엔진 모두 동일한 profileWords, 동일한 음성, 동일한 타이밍으로 투입하여, 출력 텍스트 + token-level confidence(각 token의 인식 확신도, 0~1 사이의 스코어) + 인식 시간을 JSON 형식으로 저장한다.

이를 통해, "동일한 음성에 대한 두 엔진의 출력"을 token 레벨에서 비교할 수 있는 상태가 된다.

분석의 3개 축

비교를 위해서는 출력 텍스트를 세 가지 축으로 측정한다.

축	의미
잔존율	정정·필러·모호한 표현이 텍스트에 남아 있는가
필러 구조화	%X% 형식으로 유지되고 있는가 (하이브리드 전용)
confidence	각 token에 엔진이 부여하는 확신도가 어떻게 움직이는가

"정확도가 높은가"를 측정하는 것이 아니다. 무엇을 남기고 무엇을 버리는가를 축별로 관찰한다.

발화 패턴은 이전 글의 100건을 사용하며, 구현의 구체적인 내용은 §9에서 다룬다.

이로써 본 기사의 주장은 "30건의 실제 음성과 그것을 어떻게 측정했는가"라는 사실에 근거하게 된다.

결론부터 먼저

§4 이후의 분석에 들어가기에 앞서, 결론만 먼저 적어둔다.

용도	엔진
회의록 / 감사 / 후처리 LLM 입력용	하이브리드
요약 / 문장화 / 검색 / RAG	E2E

이 단순한 용도 구분 뒤에는 세 가지 구체적인 현상이 있다.

• 「반 상자」가 「만박(엑스포)」이 될 때 (§4)
• 「에-, 그러니까」가 「지금」이 될 때 (§5)
• 「아, 아니, 6개」의 「아」가 사라질 때 (§6)

§4~6에서 이 세 가지를 차례대로 살펴본다. §10에서 완전판 결정 트리(Decision Tree)를 구성한다.

§4. 질문 1 「모호함은 어떻게 다뤄지는가」 ── 「반 상자」가 「만박(엑스포)」이 될 때

§1에서 "같은 발화를 던지면 다른 결과가 돌아온다"라고 썼다. 세 가지 대표 사례 중 가장 먼저 제시하고 싶은 것은, 그 차이가 가장 명확하게 드러난 발화 ── **「컵라면, 반 상자, 주방」**이다.

발화와 상황

"반 상자"라는 표현을 나는 방재 비축품을 정리할 때 자주 사용한다. 인스턴트 식품이나 레토르트 식품은 박스 단위로 구매하는 경우가 많다. 그러다 보면 "남은 반 상자가 있다", "반 상자를 사용했다"와 같이, 상자를 절반의 단위로 취급하는 말이 나온다.

이를 Apple Watch를 향해 발화했다.

"컵라면, 반 상자, 주방"

매우 평범한 발화다. 수량 "반 상자", 보관 장소 "주방". ASR에 전달하고 싶은 것은 이 두 가지 정보다.

동일한 음성을 두 엔진에 투입

동일한 wav 파일을 하이브리드 (-a-general)와 E2E (-a2-ja-general)에 병행으로 투입했다.

Engine	출력 텍스트
하이브리드	컵라면한파%코%주방
E2E	컵라면, 만박, 주방.

E2E의 출력을 보고 나는 눈을 의심했다.

「반 상자」가 「만박(엑스포)」이 되어 있었다.

「반 상자」가 「만박」이 된다는 사실 자체도 놀라웠다. 하지만 정말로 의구심이 들었던 점은, 그 「만박」이 confidence 1.0으로 반환되었다는 사실이었다.

confidence를 보고 다시 한번 놀라다

E2E가 반환한 「만박」에는 token별 confidence가 붙어 있다.

Engine	해당 token	confidence
하이브리드	「한파」	0.48 (낮음)
E2E	「만박」	1.0 (최댓값)

E2E는 「만박」을 confidence 1.0으로 반환하고 있다.

「자신 없음」이나 「불확실」과 같은 signal은 token 어디에도 나타나지 않는다. E2E는 그저, 자신만만하게 반환한다.

반면 하이브리드(Hybrid) 방식은 동일한 음성에 대해 はんぱ를 confidence 0.48로 반환하고 있다. 여기에 %こ%라는 filler (filler) 단어가 뒤따른다. 의미가 확정되지 않았고 한자로 변환되지도 않았다. 하지만, 「여기에 무언가 있었다」라는 흔적은 히라가나 + %X% 형식 + 낮은 confidence라는 세 가지 요소로 중복되어 남아 있다.

「confidence 임계값으로 걸러내면 된다」가 통하지 않는 이유

「万博(만박)」은 confidence 1.0으로 반환된다. 임계값(threshold)을 0.7로 설정하든 0.9로 설정하든, 이 token은 통과한다. 애플리케이션 측에 전달되는 것은, 자신만만한 「사용자는 『万博』라고 발화했다」라는 결과다. E2E의 편집형 오확정(mis-transcription)에 대해서는, confidence를 통한 guard (가드)가 구조적으로 작동하지 않는다.

「confidence가 낮으면 의심스럽다」는 여전히 맞는 말이다. 하지만 그 역──「confidence가 높으면 옳다」──은 E2E에서는 성립하지 않는다. 평소의 구현 감각대로 「일단 confidence 0.7 이하는 걸러내면 안전하다」라고 작성하면, 편집형 오확정은 모두 그대로 통과하게 된다.

방재 비축 관리라는 문맥에서 보면

방재 비축 관리에서는 「半箱(반 상자)」가 「万博(만박)」으로 저장되면 수량 정보가 사실상 소실된다. 게다가 confidence 1.0으로 반환되기 때문에, 「low confidence를 경고한다」라는 구현상의 안전책은 기능하지 않는다.

반면, 하이브리드는 はんぱ %こ%와 같이 모호함 그 자체를 남겼다.

여기서 드러난 것은 정밀도의 우열이 아니라, 「무엇을 반환하려고 하는가」의 차이였다.

§5. 질문 2 「filler (필러)는 어떻게 다뤄지는가」 ── 「에— 그러니까, 뭐」가 「지금」이 된다

§4에서 본 것은 confidence 1.0에서 발생하는 오확정이었다. 「半箱」이 「万博」로 변하는 것과 같은 모호한 표현에 관한 이야기였으므로, 「모호한 발화에는 약하다」라고 치부해도 무방하다.

문제는 여기서부터다. filler (필러)가 아주 조금 포함된, 아무것도 아닌 발화 ── 「에— 그러니까, 뭐」와 같은 머뭇거림 + 평범한 내용 ── 에 대해서도, 동일한 엔진은 다른 무언가를 저지른다.

발화와 상황

쇼핑을 마치고 돌아와 선반에 컵라면을 정리하며 자연스럽게 발화했다.

「에— 그러니까, 뭐, 컵라면 4개… 아마 주방」

「에— 그러니까」「뭐」는 일본어 대화에서 빈번하게 등장하는 filler (필러)다. 「아마」는 모호함의 signal이다. 그럼에도 내용은 명확하다 ── 컵라면 4개를 아마 주방에 두었다. ASR (자동 음성 인식)에 전달하고 싶은 정보는 「컵라면, 4개, 주방」의 세 가지다.

이를 하이브리드와 E2E에 병행하여 던졌다.

동일한 음성, 다른 출력

Engine	출력 텍스트
하이브리드	%えーっとー%%まー%カップ麺4個多分キッチン
E2E	今、カップ麺4個。多分キッチン、

E2E의 서두가 「今(지금)」으로 되어 있다.

「에— 그러니까, 뭐」가 통째로 **「今(지금)」**으로 대체되었다.

공식적으로는 「E2E에서는 filler (필러)가 자동 삭제된다」라고 명시되어 있다. 하지만 이번 30건의 사례에서는 삭제되지 않고 낮은 confidence의 별도 단어로 남는 사례도 관찰되었다.

「今(지금)」의 confidence는 0.36

§4와 마찬가지로 token 별 confidence를 확인한다.

Engine	해당 token	confidence
하이브리드	%えーっとー%	0.99
하이브리드	%まー%	1.0
E2E	「今」	0.36(낮음)

여기서 §4와 대조되는 구조가 나타난다.

§4에서는 E2E가 「万博」를 confidence 1.0으로 반환했다. 자신만만하게 오확정한다.

§5에서는 E2E가 「今」을 confidence 0.36으로 반환하고 있다. 스스로도 자신 없다는 signal을 내보내면서도, 그것을 텍스트로서 남긴다.

「자신이 없다면 내보내지 않으면 된다」라고 생각할 수도 있겠지만, E2E는 그렇게 하지 않는다. 출력한 이상 텍스트로서 남는다. 앱 측에 전달되는 것은 「사용자가 『지금, 컵라면 4개』라고 발화했다」라는 결과다. confidence 0.36이라는 signal은 파일 깊숙한 곳에 부수 정보로 남아 있을 뿐, UI에 나타나는 「사용자의 발화」에는 반영되지 않는다.

하이브리드(Hybrid)의 측면을 보다

반면 하이브리드는 동일한 음성에 대해 %えーっとー%와 %まー%를 각각 confidence 0.99 / 1.0으로 반환하고 있다.

「이것은 필러(Filler)입니다」라고 높은 확신을 가지고 써 내려가고 있다. %X%라는 형식은 AmiVoice의 하이브리드가 필러를 구조화하기 위한 약속이며, 후속 단계에서 「%X%로 둘러싸인 token은 내용이 아니다」라고 기계적으로 분리할 수 있다.

즉, 하이브리드는 **필러를 「노이즈는 아니지만, 그렇다고 내용도 아닌 것」**으로서 형태를 바꾸지 않고 유지하고 있다.

같은 「전사(Transcription)」가 아니다

「えーと, まあ(에, 그러니까) → 지금」을 보았을 때, 내 안에서 무언가가 전환되었다.

하이브리드와 E2E는 같은 문제를 풀려고 하지 않는다.

하이브리드에게 「전사해줘」라고 하면 발화의 질감이 남은 텍스트가 돌아온다. E2E에게 같은 요청을 하면 읽기 쉬운 텍스트가 돌아온다. 둘 다 「전사」를 표방하고 있지만, 지향하는 결과물이 다르다.

「정밀도 비교」, 「어느 쪽이 더 우수한가」라는 질문은 양자가 동일한 목적의 엔진이라고 암묵적으로 가정한다. 하지만 그 가정 자체가 성립하지 않았다.

§6. 질문 3 「정정은 어떻게 다뤄지는가」 ── 「아, 아니야, 6개」

§5를 읽고 「그렇다면 언제든 하이브리드를 선택해 두면 안전하지 않을까?」라고 생각한 사람에게. 여기서는 그 가설이 조금 흔들린다.

발화와 상황

방재 비축품을 정리하다가 스스로 「어라, 4개가 아니네」라고 깨닫고 말을 고치는 일은 흔히 있다. 그것을 Apple Watch를 향해 그대로 발화했다.

「컵라면 4개, 유통기한 2027년 3월, 주방, 아, 아니야, 6개」

처음에 「4개」라고 말해버렸지만, 사실은 6개다. 발화 도중에 정정하고 있다. 「아, 아니야, 6개」 ── 「아」가 정정의 기점, 「아니야」가 정정 동사, 「6개」가 올바른 수량이다.

이를 하이브리드와 E2E에 병행하여 던졌다.

동일한 음성, 두 엔진의 결과

Engine	출력 텍스트
하이브리드	컵라면4개유통기한2027년3월,주방%あ%아니야.6개
E2E	컵라면4개, 유통기한 2027년 3월 주방. 아니야. 6개.

언뜻 보기에는 양쪽 모두 나름대로 「올바른 결과」를 반환하고 있다. 「컵라면 4개」와 「6개」가 모두 나오고, 「아니야」도 포착했다. 최종적인 수량을 판단한다면, 후속 단계에서 「마지막 숫자를 채택한다」라는 규칙을 작성하면 양쪽 모두 6개로 귀결될 수 있다.

§4나 §5와 같은 화려한 차이는 없다.

차이는 「아」의 취급뿐

자세히 살펴보면, 정정의 **기점이 되는 감탄사 「아」**의 취급만이 다르다.

• 하이브리드: %あ%로 남았다 (순수 텍스트에는 나오지 않지만, 구조화 토큰으로서는 유지됨)
• E2E: 흔적째 사라졌다

정정 횟수를 분석하고 싶다, 정정 패턴을 학습시키고 싶다 ── 그런 용도에서는 이 차이를 무시할 수 없다. E2E의 출력에는 「사용자가 말을 고쳤다」라는 사실 그 자체가 남아 있지 않다.

「무엇이든 남을」 터인 하이브리드도, 「아」를 버리고 있다

§5에서 「하이브리드는 발화의 질감을 가급적 남기는 설계」라고 썼다. 확실히 필러나 모호함을 %X% 형식이나 히라가나로 남기고 있다.

하지만 이 §6의 출력을 자세히 보면, 하이브리드의 순수 텍스트에도 「아」는 나타나지 않는다. %あ% 안에 갇혀 있어서, 순수 텍스트 결합으로는 컵라면4개...주방 아니야.6개가 되어 있다. 「아」라는 발화가 있었다는 사실은 구조화 토큰을 보지 않으면 추출할 수 없다.

즉,

• 하이브리드의 순수 텍스트 레벨에서는, 정정의 기점 감탄사 「아」는 제외되어 있다
• 구조화 토큰(%X% 형식)을 보면 「여기에 정정의 기점이 있었다」는 복원할 수 있다
• 하지만 순수 텍스트만을 저장·참조하면 그 흔적은 상실된다

이것은 「하이브리드(Hybrid)니까 무엇이든 남는다」라고 생각했던 입장을 한 단계 후퇴시키는 사실이다. 하이브리드도 모든 것을 素텍스트(Raw text)로 남기지는 않는다.

E2E는 한 걸음 더 나아가 흔적도 없이 삭제한다. 따라서 「축어형 하이브리드 vs 편집형 E2E」라는 대비는 대체로 성립하지만 ── 엄밀히 말하면, 양자 모두 「무언가를 素텍스트에서 제외하고 있다」. 하이브리드는 %X% 형식으로 흔적을 남기고, E2E는 흔적조차 남기지 않는다, 라는 차이일 뿐이다.

「의사록에는 하이브리드」가 단순하지 않은 이유

「의사록 / 감사 로그(Audit log)에는 하이브리드가 적합하다」 ── 이것은 지금도 기본적으로 옳다.

다만, §6을 고려하면 한 단계 더 주의가 필요하다. 하이브리드의 素텍스트만을 의사록으로 저장하면, 정정의 기점이 되는 감탄사나 필러(Filler)의 흔적은 상실된다. 완전한 「발화의 질감(Hand-feel)」을 남기고 싶다면, %X% 형식을 포함한 구조화된 포맷 ── 예를 들어 JSON ── 으로 저장해 둘 필요가 있다.

즉, 「하이브리드를 선택한다」는 것만으로는 안심할 수 없으며, 「하이브리드를 어떻게 저장할 것인가」까지 설계에 포함해야 한다.

여기까지 보면, 「축어와 편집 중 어느 쪽이 우월한가」라는 질문은 성립하지 않는다. 「나의 용도에서는 어느 쪽의 대가를 받아들일 것인가?」 ── 이것이 선택의 질문이 된다. §7에서 정리한다.

§7. 총괄: 축어와 편집, 전사(Transcription) 작법의 정리

3가지 대표 사례를 나란히 놓고 보면, 결국 달랐던 것은 「정확도」가 아니라 「무엇을 결과물로 돌려주려 하는가」였다.

하이브리드와 E2E의 설계 사상

하이브리드 = 남기는 전사 (축어형)	E2E = 다듬는 전사 (편집형)
무엇을 최대화하는가	발화의 질감을 가급적 남긴다
필러(Filler) 처리	%X% 형식으로 구조화하여 유지
모호한 표현	히라가나 + 낮은 confidence로 유지 (はんぱ %こ%)
정정 기점의 감탄사 「아」	%あ%로 흔적을 남김 (素텍스트에는 나타나지 않음)
confidence	변동의 signal로 사용 가능 (はんぱ confidence 0.48 등)
적합한 용도	의사록 / 감사 로그 / 후처리 LLM

confidence가 걸렸던 부분

confidence의 거동만은 마지막까지 완전히 정리하지 못했다. 1.0이라고 해서 반드시 옳은 것도 아니고, 0.36이라고 해서 사라지는 것도 아니다. 적어도 이번 30건에 있어서는, 「정확도의 척도」로서 단순하게 다룰 수 없었다.

§8. 공정한 검증 voice의 증거 ── 자신의 가설을 스스로 무너뜨린 이야기

검증 초기에 keepFillerToken=1이 E2E에서 묵묵히 무시되는 것을 관찰했다. 거기서부터 「profileWords도 듣지 않는 것이 아닌가」라고 의심했다.

하지만 probe를 추가하자 정상적으로 작동하고 있었다. 공식 레퍼런스(Reference)에도 처음부터 그렇게 적혀 있었다. 완전히 간과하고 있었다.

가설은 철회.

본 기사는 30건의 실제 음성으로 측정한 범위 내에서는 성립하는 이야기다. 이번처럼 추가적인 probe로 뒤집히는 가설은 앞으로도 나올 수 있다. 나온다면 다시 스스로 무너뜨릴 것이다.

§9. 구현 tips ── 동일한 코드베이스에서 하이브리드와 E2E를 병용하기

d 필드로 전환하기

엔드포인트(Endpoint)는 동일하며, AmiVoice의 범용 일본어 엔진을 두 개 호출하는 경우 엔드포인트는 같다. 동기 HTTP인 https://acp-api.amivoice.com/v1/nolog/recognize에 POST 한다. 엔진의 전환은 요청의 d 파라미터로 엔진 이름을 지정하기만 하면 된다.

const ENGINES = [
{
name: 'hybrid',
d: '-a-general ...'
},
{
name: 'e2e',
d: '-a2-ja-general ...'
},
...
];

하이브리드 엔진은 -a-general

End-to-End (E2E) 엔진은 -a2-ja-general입니다.

동일한 wav 파일을 순서대로 양쪽 엔진에 던지면, 해당 음성에 대한 두 엔진의 출력을 나란히 얻을 수 있습니다. 본 기사의 검증은 이 방법으로 총 30건의 비교를 수행했습니다.

profileWords의 구문(syntax)이 다르다

보정 사전 profileWords는 양쪽 엔진 모두 사용할 수 있습니다 (§8 참조, 처음에 세웠던 가설은 여기서 스스로 깨졌습니다). 다만 구문(syntax)이 다릅니다.

Engine	syntax	예
하이브리드	표기 읽기	カップ麺 かっぷめん
E2E	표기 대체표기 biasing	カップ麺 かっぷめん 0.5

E2E의 세 번째 필드인 biasing은 0~1 사이의 값으로, 해당 단어를 끌어당기는 강도를 지정합니다. 지정하지 않으면 기본값(default)은 0.5입니다. 본 기사의 검증에서는 양쪽 엔진의 공정한 비교를 위해, E2E에서는 명시적으로 0.5를 전달하고 있습니다.

const VOCAB = [['カップ麺', 'かっぷめん'], ...];
const PROFILE_WORDS_HYBRID = VOCAB.map(([w, y]) => `${w} ${y}`).join('|');
const PROFILE_WORDS_E2E = VOCAB.map(([w, y]) => `${w} ${y} 0.5`).join('|');

keepFillerToken은 하이브리드에서만 기능한다

하이브리드의 keepFillerToken=1은 필러(filler)를 %えーっとー%와 같은 형식으로 출력에 남겨줍니다. E2E에 동일한 파라미터를 전달해도 묵묵히 무시됩니다 (§8 참조).

양쪽 엔진을 병용하는 구현에서는 하이브리드 측에만 keepFillerToken=1을 전달하면 됩니다. E2E는 기본 동작(필러는 별도의 단어로 편집 또는 삭제)으로도 충분합니다.

§10. 선택 결정 트리 ── 내일 바로 사용할 수 있는 형태로 정리하기

§4-6에서 확인된 차이점을 운영 시 고민하지 않도록 결정 트리(decision tree)로 만듭니다. "반 상자 → 만박(엑스포)", "에ーっと → 지금", "아 → %아%"와 같은 구체적인 예시는 선택의 근거로서 명확합니다. 나머지는 그것을 눈앞의 용도에 대입하기만 하면, 하이브리드인지 E2E인지는 수십 초 내에 결정됩니다.

Step 1: 용도로 축을 선택하기

먼저, ASR(자동 음성 인식)을 무엇을 위해 사용하는지에 따라 크게 갈립니다.

용도	추천	이유
의사록 / 감사 로그 / 후처리 LLM 입력	하이브리드	변동성(필러 / 정정 / 모호함)을 %X% 형식이나 히라가나로 구조화하여 유지할 수 있음. 후속 단계에서 "여기에 무언가 있었다"를 다룰 수 있음
문장화 / 요약 / 검색 / RAG	E2E	필러가 편집되므로, 인간이나 검색 인덱스(index)에 전달했을 때 노이즈가 적음
자막	중간(용도에 따라 다름)	실시간성이 필요하면 E2E, 정확한 발화 흔적이 필요하면 하이브리드

Step 2: 제약 사항에 따른 불가피한 선택

Step 1에서 망설여진다면, 기술적인 제약 사항으로 좁혀갑니다.

• 업계 특화 사전이 필요한 경우(의료 등): 하이브리드 (엔진 특화 대응 범위가 넓음)
• token-level timestamp가 필요한 경우: 하이브리드 (발화 단위의 시각 정보가 충실함)
• 단발화 지연 시간(latency)을 최우선시하는 경우: E2E (단시간 응답에 최적화되어 있는 경우가 있음)

Step 3: 3가지 대표 사례로 확인하기

여기서 §4-6의 3가지 대표 사례를 다시 대입해 봅니다.

• 모호한 수량 표현(예: "반 상자")을 "있었던 사실"로서 남기고 싶다 → 하이브리드
• 필러(예: "에ーっと, 뭐")를 텍스트에 내보내고 싶지 않고, 정돈된 문장으로 저장하고 싶다 → E2E
• 정정의 흔적(예: "아, 아니, 6개")을 남기고 싶다 → 하이브리드 + 구조화 저장(단순 텍스트 연결만 하면 "아"가 유실됨, §6 참조)

Step 4: 단, 만능인 선택지는 없다

지금까지 선택한 엔진을 마지막으로 다시 한번, 대가(cost)의 측면에서 재검토합니다.

• 하이브리드를 선택한 경우: 정정 시점의 감탄사 "아"는 일반 텍스트에서 제외됩니다. 완전히 남기고 싶다면 %X%

구조 자체를 (JSON 등으로) 저장할 필요가 있다. -
E2E를 선택한 경우: 모호한 발화는 다른 단어로 오확정될 수 있다. 게다가 confidence 1.0으로 반환되기 때문에, confidence 임계값(threshold)에 의한 가드(guard)로는 걸러낼 수 없다 (§4 참조).

결정트리(Decision Tree)의 전체 모습

결정트리를 구현 가이드로 사용할 때의 한마디

실제로는 이 결정트리를 보고도 망설여진다. 그럴 때는 새로운 발화로 테스트해 보는 수밖에 없다.

§11. 요약 ── 3가지 대표 사례가 보여준 것

30건을 통해 알 수 있었던 것은, "어느 쪽이 올바른 전사(Transcription)인가"라는 관점 자체가 별로 도움이 되지 않는다는 점이었다.

하이브리드(Hybrid)와 E2E는 각각 서로 다른 것을 남기고, 서로 다른 것을 버렸다.

ASR은 모든 것을 남기기만 하면 되는 것이 아니다. 하지만 선별에는 대가가 따른다.

"어떤 ASR이 옳은가"가 아니라, "자신의 용도에서는 어떤 대가를 받아들일 것인가"를 선택한다. 이것이 이번 30건을 통해 확인한 선택의 기준이었다.

마치며

검증의 마지막 단계로, 3가지 케이스를 후속 LLM 구조화(prod 파이프라인) 단계로 흘려보내 보았다.

"만박(엑스포)"은 사라졌다. 하지만, "반 상자"도 사라졌다.

마지막에 남은 것은 quantity: 1

이었다.

LLM이나 스키마(schema) 또한 "무엇을 남기고 무엇을 버릴 것인가"를 결정하고 있다.

그 이야기는 다음에 다시 쓰고 싶다.

Discussion