회의 녹음을 엔진에 넣었는데, 참석자 이름만 계속 다르게 적힙니다. 한 번은 “박서연”, 다음 줄에서는 “박서현”, 그다음에는 “박수연”. 나머지 문장은 멀쩡합니다. 이런 경우 자주 겪으실 텐데요, 이때 손이 가는 기능이 사용자 사전, 핫워드, 단어 부스팅 같은 이름으로 불립니다. 기술 쪽에서 부르는 이름은 Contextual Biasing입니다.

사전 등록은 학습이 아니라 점수 조정입니다

핵심은 단어를 다시 배우게 만드는 것이 아니라, 후보 선택 과정에서 특정 단어가 이길 가능성을 높여주는 것입니다.

저는 처음에 이걸 작은 재학습쯤으로 생각했습니다. 아니었습니다. 인식이 끝난 뒤에 문자열을 바꿔치기하는 후처리도 아니고, 후보를 고르는 도중에 개입하는 일입니다.

왜 이름이 자꾸 틀리는지도 여기서 설명이 됩니다. 모델은 학습에서 거의 본 적 없는 단어에 아주 낮은 확률을 줍니다. 그래서 발음이 비슷하면서 더 흔한 단어가 이깁니다. 목록에 이름을 넣는 건 그 저울 한쪽에 추를 하나 올려놓는 일입니다.

점수에 얹는 방식과 모델 안에 넣는 방식

구현은 크게 두 갈래입니다.

하나는 shallow fusion입니다. 디코딩 중 후보 점수에 목록에서 온 점수를 더합니다. 목록을 WFST 같은 문맥 그래프로 만들어 두고 디코더가 참조하는 형태가 흔합니다. 모델 구조를 건드리지 않아도 되니 요청마다 목록을 갈아 끼울 수 있습니다.

다른 하나는 deep biasing입니다. 단어 목록 자체를 벡터로 만들어 모델 안에서 어텐션으로 참조하게 합니다. 목록이 크고 지저분할 때 덜 무너지는 대신, 모델을 학습할 때부터 biasing을 염두에 두고 만들어야 합니다. 엔진을 직접 만들지 않는 쪽에서는 사실상 선택지에 없습니다.

결국 질문은 “단어를 다시 배우게 만들 것인가”가 아니라, 후보를 고르는 순간 어느 쪽으로 저울을 기울일 것인가에 더 가깝습니다.

틀리면 바로 눈에 띄는 단어가 몰리는 자리

쓰이는 자리는 대체로 비슷합니다.

상담 기록에서는 상품명과 약관 용어, 회의록에서는 참석자 이름과 조직명, 사내 약어, 자막에서는 등장인물 이름과 지명이 걸립니다. 의료나 금융처럼 용어가 폐쇄적인 분야도 마찬가지입니다.

공통점이 하나 있습니다. 전체 발화에서 차지하는 비중은 낮은데, 틀리면 읽는 사람 눈에 가장 먼저 들어오는 단어라는 것입니다. 조사 하나 어긋난 문장은 넘어가도, 이름 한 번 틀린 문서는 그냥 못 씁니다.

목록과 가중치는 요청에 실어 보냅니다

대부분의 상용 엔진은 이 기능을 요청 파라미터로 열어두고 있습니다.

Google Cloud Speech-to-Text는 PhraseSet에 구절과 boost 값을 넣고, 관련된 항목을 묶는 CustomClass도 함께 씁니다. NVIDIA Riva는 word boosting이라는 이름으로 단어 목록과 weight를 요청에 함께 보냅니다. Deepgram은 Nova-3에서 keyterm prompting을 쓰고, 이전 모델의 keywords를 대신합니다. 오픈소스 쪽에서는 WeNet처럼 문맥 그래프 기반 biasing을 넣어둔 구현이 있습니다.

요청은 대개 이런 모양입니다.

"phrases": [
  { "value": "전세권설정", "boost": 10 },
  { "value": "박서연 책임", "boost": 15 }
]

값의 범위와 기본값은 엔진마다 다르니 문서에서 확인하는 편이 낫습니다.

여기서 한 가지 구분할 게 있습니다. Whisper의 initial_prompt는 이름은 비슷해 보여도 성격이 다릅니다. 앞선 문맥인 척 텍스트를 넣어주는 것이라 단어가 살아날 때도 있고 통째로 무시될 때도 있습니다. 결과를 재현해야 하는 작업이라면 이걸 boosting으로 치고 쓰지 않는 편이 좋습니다.

목록이 커지면 효과가 줄어듭니다

여기서부터가 실제로 값을 만지는 대목입니다.

가중치를 올리면 목표한 단어는 잘 잡힙니다. 대신 발음이 비슷한 일반 단어까지 목록 안의 단어로 바뀌어 적히기 시작합니다. 키워드 정확도는 올라가는데 문장 전체 정확도가 내려가는 관계라, 한쪽만 보고 값을 정하면 나중에 검수에서 다 드러납니다. Riva 문서도 가중치를 이진 탐색으로 찾되 WER와 용어 오류율을 같이 보라고 권합니다.

목록 크기도 그냥 늘릴 수 없습니다. 수천, 수만 건을 한 번에 밀어 넣으면 목록 안의 단어끼리 경쟁합니다. 그래서 발화와 관련 있는 후보만 골라 넣는 필터링이 연구되고 있고, 서비스들도 한 번에 보낼 수 있는 항목 수에 상한을 둡니다.

실무에서 정할 것은 셋입니다. 목록을 세션 단위로 쪼갤지, 짧은 단어를 뺄지, 가중치를 몇으로 둘지. 두 음절 이하 단어는 넣어봐야 오인식만 늘리는 경우가 많아 저는 빼는 쪽으로 기울었습니다.

말을 글로 옮기는 작업에서는

같은 값이라도 작업 형태에 따라 부담이 다릅니다. 긴 회의 하나를 통으로 돌릴 때는 목록을 한 번 정해두면 되지만, 자막은 이름 하나가 시퀀스마다 반복해서 나오기 때문에 오인식이 훨씬 눈에 띕니다.

HAIV 음성인식 엔진은 사용자 사전을 따로 두고 인명, 지명, 전문용어를 미리 등록해 둡니다. 도메인마다 이 등록이 인식률을 크게 바꾸기 때문에 한꺼번에 등록하는 기능이 따로 있습니다. 밖에서 만든 엔진이 금융, 보험, 공공 전문용어에 약한 것도 같은 조건에서 나오는 이야기입니다.

등록하기 전에 표기부터 정합니다

목록을 만들 때 제일 먼저 걸리는 건 가중치가 아니라 표기입니다. 같은 회사 이름을 한글로 쓸지 영문으로 쓸지, 띄어쓰기를 어떻게 할지가 정해져 있지 않으면 목록에 두 표기가 같이 들어가고, 결과물에도 두 표기가 섞여 나옵니다.

사전 등록은 단어를 늘리는 일이 아니라, 어떤 단어를 어느 표기로 얼마나 세게 밀지 정하는 일입니다. 이름이 계속 틀린다면 단어를 하나 더 넣기보다, 지금 목록에 몇 개가 들어 있고 가중치가 얼마인지 세어보는 것이 빠릅니다.

• 표기 통일 같은 이름을 한글/영문/띄어쓰기 변형으로 중복 등록하고 있지 않은지 먼저 봅니다.
• 세션 단위 분리 모든 도메인 단어를 한 번에 넣지 말고, 회의/상담/자막 등 실제 발화 맥락에 맞는 목록만 보냅니다.
• 짧은 단어 제거 두 음절 이하처럼 모호한 단어는 오히려 일반 단어를 끌어당겨 오인식을 늘릴 수 있습니다.
• 가중치 튜닝 한 번에 크게 올리기보다, WER와 용어 오류율을 같이 보면서 탐색하는 편이 안전합니다.