현 시점, 화자 구분 문제점

화자 구분 고도화 관련 내용을 지난 포스트에서 다루었으며, 이후 화자 구분을 실질적으로 적용해보며 겪고 있는 문제점들을 여기서 다뤄본다. API를 이용한 화자 구분 보다는 성능이 많이 좋아지긴 했지만, 여전히 개선해야 할 부분들이 여럿 있다. 그러면 바로 시작해보자 

---

0. 실제 API 보다 성능이 좋아졌는가 ?

화자 구분 고도화 파이프라인은 다음과 같으며, 각 단계별로 개선할 수 있어 보이는 부분들을 고도화하여 로컬에서 사용 가능한 화자 구분 모델을 구축했다(Segmentation, Embedding 모델은 Pyannote과 Wespeak 모델 사용, 이전 포스트들에서 소개함).

Traditional speaker diarization system

* 아직 청크별 화자 연결이 남아 있고, 이 과정을 진행하면서 발견한 문제점이라, 이 부분은 아래에서 추가적으로 다룬다. 

 

잡음이 어느정도 있는 회의록 음성 파일에 대해 Whisper API를 돌린 결과를 먼저 보여주자면 다음과 같다. 

일단 팀장과 영업팀 수석의 발화 자체를 동일 화자로 분류해버렸다. 이후 팀장을 SPEAKER_00으로 분류하였으나, 2~19초 동안 서로간 대화가 오고 갔는데 이를 단일 화자의 발화로 레이블링 한건 실제 서비스에서는 치명적이라 할 수 있다. 이외에도, 타임라인이 맞지 않거나 하는 등의 문제가 추가로 발견되었다. 

 

고도화한 화자 구분 모델을 사용해 동일 오디오 파일에 대한 화자 구분을 수행한 결과는 다음과 같다. 

API에서 잘 구분하지 못하던 2~19초 부분에 대해 2명의 화자간 대화라는 것을 잘 분류하는 것을 볼 수 있었고, 새로운 화자가 등장한 58초에서도 새로운 화자 SPEAKER_01로 레이블링했다. 

 

또 다른 경우로, 전화통화 녹취록에 대해 화자 구분 API 모델과 고도화 모델을 각각 돌려 보았을 때, 아래와 같은 결과를 얻었다. 

API 결과(왼쪽)을 살펴보면, 전화통화인데, 화자가 3명으로 레이블링되어 있는 것을 볼 수 있었다. 한 두번 새로운 화자가 등장하는 것이 아니라, 그것도 꽤 많이. 반면, 고도화한 화자 구분 모델은 SPEAKER_00을 비롯한 짧은 발화의 경우 filler 처리를 진행하였기에 SPEAKER_01과 SPEAKER_02 위주로 대화가 진행되는 것을 확인할 수 있었다. 

 

화자 구분 성능 평가 지표(DER, Diarization Error Rate)에 대한 값도 계산해볼 예정이며, 완료되는대로 공유토록 하겠다.

 

1. 현 시점, 화자 구분 모델 문제

앞의 화자 구분 모델 성능에 만족하며, 청크간 화자 연결을 수행하려 했는데, 문제점을 발견했다.

 

문제점 # 01. 현재 화자 구분 모델은 전체 오디오를 청크 단위로 분할 후, 청크별 화자 구분을 수행하는 방식을 사용하고 있다 (전체 오디오 파일에 대해 한번에 수행 시 성능이 저하되는 이슈 존재). 근데, 청크 중 간혹 가다 화자 정보가 튀는 현상이 발생한 것을 확인했다. 안정적인 미팅 환경에서는 청크 내 화자 구분을 잘 수행하였으나, 녹음 중간에 새로운 참여자가 개입하거나, 발화자가 흥분해 목소리가 높아지는 경우, 동일 화자를 새로운 화자로 분류하고, 이후부터는 해당 화자로 레이블링 해버린다는 것이다. 

또 다른 상황에서는, 전화 통화 중에 녹음된 오디오 파일인데, 화자 구분 결과 3명의 화자가 등장하는 것으로 레이블되었다.

해당 파일을 들어보니, SPEAKER_00으로 등장한 화자는 SPEAKER_01과 SPEAKER_02가 동시에 말하는 구간에서, SPEAKER_02가 말할 때 기록된 화자로, 두 화자 간 임베딩 값이 혼합(Hybrid)되어 새로운 화자가 탄생하게 된 문제다. 근처 화자로 배정하려 해도, 위 그림에서 SPEAKER_00은 SPEAKER_01과 SPEAKER_02의 경계에 있어 특정 화자에 배정하기 어려운 상황이다. 

 

이러한 상황을 해결하지 않고, 오디오 청크 중 처음 등장하는 화자들을 기본 베이스 화자로 설정하고, 이후 청크부터 화자별 대표 임베딩 값을 이용해 화자 매핑을 수행하면 다음과 같은 결과값을 얻게 된다. 새로운 화자로 잘못 인식된 경우, 기존 동일 화자와의 임베딩 유사도 값도 낮게 나타나며, 이로 인해 매번 새로운 화자로 등록하게 되고, 실질적으로 4명이 참여한 회의에서 9명이 참여한 회의로 탈바꿈해버리게 되는데 .. 이거 때문에 골머리를 앓고 있는 중이다. 

문제점 # 02. non overlapped diar result 기준으로 임베딩 값을 계산하고, 이를 KNN Clustering을 통해 재레이블링 하는 과정은 오히려 정확도가 저하된 듯한 느낌을 받았다. 화자 구분 결과에서, 화자별 발화가 겹치지 않는 구간을 추출해 해당 구간에 대한 임베딩 값을 얻고, KNN 클러스터링을 적용해 기존 레이블을 재레이블링을 진행했다. 하지만, 실제로 노이즈가 거의 없는 회의 환경에서 해당 과정을 거친 결과 파일과 거치지 않은 결과 파일을 비교 분석해본 결과, 재레이블링을 적용하지 않은 결과가 보다 좋은 성능을 보이는 것을 알 수 있었다.  

위 이미지에서 왼쪽이 재레이블링 적용 전 화자 구분 결과, 오른쪽이 재레이블링 적용 후 화자 구분 결과이다. 138~157초 사이의 구간을 들어보면, 처음에 팀장(남성)의 목소리가 살짝 섞인 매니저(남성, SPEAKER_00)의 발화 구간인데, 재레이블링 적용한 화자 구분 결과는 여성(SPEAKER_01)으로 레이블을 할당해버렸다. 이후에도, 204~230초 사이의 구간 또한 여성이 발화한 구간인데, 재레이블링을 적용하고 난 뒤의 화자 구분 결과 값을 살펴보면 매니저 발화 구간으로 분류하고 있는 것을 볼 수 있다. 

 

2. 대응 방안

문제점 2: 'KNN Clustering 적용 전의 성능이 적용 후보다 뛰어남'에 대한 부분은 KNN Clustering을 적용하지 않는 것으로 쉽게 대응할 수 있었다. 다만, 문제점 1: '목소리가 겹치는 지점에 대해 새로운 화자로 분류해버림'에 대해서는, 아직까지 명확한 해답을 찾지 못한 상황이다. 임시 방편으로, 청크 내 특정 화자 발화 수가 임계치보다 낮거나, 해당 화자의 평균 발화 시간이 임계치보다 짧은 경우, UNKNOWN 화자로 레이블링해서 사용중인데, 나름 괜찮은거 같아 일단 해당 방식으로 진행중이다. 해당 문제에 대해서는 이후 명확한 해결 방안이 떠오르면 공유하겠다.