STT 오류율 5% 벽 앞에서 나온 답은 결국 데이터였다

16일 오후 4시 27분, 에이전트코리아 방에서 한 참여자가 STT(Speech-to-Text, 음성을 텍스트로 변환하는 기술) 정확도를 두고 질문을 던졌다.

여기 stt 고수 계세요? cer 낮출려면 어케 해야돼요?

1분 뒤 다른 참여자가 짧고 단호하게 답했다.

STT CER는…. 데이터가 다죠

CER(Character Error Rate, 인식된 텍스트와 실제 발화를 문자 단위로 비교해 오류 비율을 계산하는 지표)을 낮추는 방법을 묻는 질문에, 모델 구조나 튜닝 기법이 아니라 학습 데이터 품질이 관건이라는 진단이었다. 이 답을 전후해 groq·grok 같은 상용 STT 서비스 정보도 함께 오갔다. 오후 4시 31분, 처음 질문했던 참여자는 실제 겪고 있는 어려움을 구체적으로 밝혔다.

cer 5퍼미만으로 절대 안내려감..

5%라는 벽이 단순한 목표치가 아니라 실제로 부딪히고 있는 한계로 제시된 셈이다. 오후 4시 37분, 앞서 데이터를 강조했던 참여자는 자사가 구축한 구조를 구체적으로 설명하며 대화를 이어갔다.

스트리밍에 화자 분리면 저희는 인식용이랑 화자 분리랑 따로 두고 있어요

음성 인식과 화자분리(Speaker Diarization, 여러 사람이 말한 음성에서 "누가 언제 말했는지"를 구분해내는 기술)를 별도 모델이 아니라 하나의 모델 안에서 인식용·화자분리 두 갈래로 나눠, 각각 병렬로 추론하도록 이미 구축돼 있다는 설명이었다. 공유된 내용에 따르면 이 구조는 하나의 공통 인코더에서 출발해 두 개의 헤드로 갈라지는 Trunk+2 Head 형태이고, 전체 규모는 2.5B 수준이라고 밝혔다. 인식용 헤드와 화자분리 헤드를 나눈 이 구조는 스트리밍 환경에서 두 작업을 동시에 처리해야 하는 부담을 나눠 맡기는 방식으로 보인다.

10분 남짓한 짧은 대화였지만, 질문과 답변이 오간 순서 자체가 흥미롭다. "낮추는 법"을 물었을 때 돌아온 첫 답은 구체적인 기법이 아니라 데이터였고, 실제 수치(5% 미만 불가)를 밝히자 그제서야 Trunk+2 Head라는 구체적인 구조 설명이 뒤따랐다. 문제를 먼저 데이터 품질로 좁히고 그다음 아키텍처 이야기로 넘어가는 진단 순서가, 이 짧은 대화 안에 그대로 드러난 셈이다. 상용 서비스 정보와 자체 구축 구조가 같은 대화 안에서 함께 오갔다는 점도, STT 정확도 개선이 기성 API를 가져다 쓰는 선택과 직접 구조를 나눠 짜는 선택 사이에서 갈린다는 것을 보여준다. 참여 인원은 8명으로 다른 화두보다 적었지만, 질문 하나에 구체적인 수치와 아키텍처까지 답이 나왔다는 점에서 밀도는 오히려 높은 대화였다.

이 화두에는 8명이 참여해 75건의 메시지를 남겼다.