구축하고 배포하고 자랑스러워하는 기능들이 있습니다. 그리고 2주간 작업한 기능들이 있습니다. 거울 앞에서 스스로 시연하고, 기본 수준에서 완전히 깨져 있음을 깨닫고, 완전히 삭제하는 기능들이 있습니다. VORA의 화자 식별은 확실히 두 번째 범주에 속했습니다. 이것이 솔직한 사후 분석입니다.
원래 비전
여러 사람이 말할 때 전사본이 누가 무엇을 말했는지 알아야 한다는 것은 명백해 보였습니다. "Alice가 X라고 말했고, Bob이 Y라고 말했습니다." 모든 엔터프라이즈 회의 녹음기가 이것을 가지고 있습니다. Google Meet이 합니다. Otter.ai가 합니다. 얼마나 어려울까요?
우리는 그것에 헌신했습니다. SpeakerDetector 클래스를 구축했습니다. UI 요소를 추가했습니다: 앱 헤더의 "주 화자 설정" 버튼, 랜딩 페이지의 화자 프로파일링 카드, 전사 표시의 화자 열. 설정 모달은 화자 감지 전용 섹션이 있었습니다. 우리는 피치 복사를 작성했습니다: "화자 프로파일링 — 실시간으로 음성 트랙 식별 및 분리".
그것은 제품에 있었습니다. 마케팅에 있었습니다. 그것은 거짓이었습니다.
너무 오래 무시한 근본적인 문제
VORA는 Web Speech API를 기반으로 합니다. 브라우저의 기본 제공 음성 인식 인터페이스입니다. VORA가 전사용 서버 인프라를 요구하지 않고, 완전히 브라우저에서 작동하며, 정말로 무료로 실행될 수 있는 이유입니다. Web Speech API는 그것이 하는 일에 대해 우아하고 강력합니다.
화자 분류는 절대 하지 않습니다. API는 단일 텍스트 스트림을 반환합니다. 여러 화자의 개념이 없고, 오디오 채널 분리가 없고, 음성 임베딩이 없습니다. recognition.onresult를 호출하면 SpeechRecognitionResultList를 얻습니다. 그냥 텍스트입니다. 그게 전부입니다.
우리는 이것을 알고 들어갔습니다. 하지만 우리는 영리한 휴리스틱을 통해 작동할 수 있다고 우리 자신을 확신했습니다:
- 볼륨 임계값: 아마도 "주 화자"는 일관되게 더 크습니까? 사용자에게 기준 볼륨 수준을 설정하도록 요청할 수 있습니다.
- 일시 중지 기반 분할: 긴 일시 중지가 화자 변경을 나타낼 수 있습니다. 우리는 합성 화자 마커를 삽입할 수 있습니다.
- AudioContext 분석: 우리는 이미 시각화기용
AudioContext를 사용하고 있습니다. 마이크 스트림에서 실시간 음성 지문을 할 수 있을까요?
이러한 아이디어 각각은 약 5분 동안 그럴듯해 들립니다. 그러면 구현합니다.
구현에서 실제로 일어난 것
볼륨 접근 방식은 즉시 벽에 부딪혔습니다: 회의실에서 모두가 마이크로부터 대략 동일한 거리에 있습니다. "주 화자" 임계값은 무작위 거짓 양성을 생성했습니다. 조용한 일대일에서는 어느 정도 작동했습니다. 실제 회의에서? 무용지물입니다.
일시 중지 기반 분할은 더 나빴습니다. 침묵이 2초를 초과할 때마다 화자 휴식 마커를 삽입했습니다. 이것은 화자 변경처럼 보이는 전사를 생성했지만 단지... 단일 사람의 음성 내 일시 중지였습니다. "Alice: 나는 우리가 con—" 휴식 "Bob: 예산 영향을 고려해야 한다고 생각합니다." 이것들은 동일 인물의 동일 문장이었습니다. 전사는 이제 적극적으로 오도했습니다.
실시간 음성 지문 아이디어는 기술적으로 가장 흥미롭고 가장 치명적으로 결함이 있었습니다. Web Audio API의 AnalyserNode를 사용하여 마이크 스트림에서 주파수 데이터를 추출할 수 있습니다. 우리는 JavaScript에서 계산한 스펙트럼 중심 및 MFCC 같은 기능을 사용하여 기초적인 음성 임베딩 시스템을 구축했습니다. 단일 화자에서 잘 작동했습니다. 상당히 다른 목소리를 가진 두 명의 화자의 경우 약 60% 정확도로 올바르게 했습니다. 이것은 괜찮아 들릴 때까지 회의 전사에서 40% 틀렸다는 것을 깨달을 때까지 완전히 사용할 수 없습니다.
// 우리가 시도한 것 - AudioContext를 통한 음성 지문
const analyser = audioCtx.createAnalyser();
analyser.fftSize = 2048;
const dataArray = new Float32Array(analyser.frequencyBinCount);
analyser.getFloatFrequencyData(dataArray);
// 스펙트럼 중심을 기초적인 음성 ID 기능으로 계산
const centroid = dataArray.reduce((sum, val, i) => sum + (val * i), 0)
/ dataArray.reduce((sum, val) => sum + val, 0);
// 알려진 화자 프로필과 매치...
// 이것은 약 60% 정확도로 작동했습니다. 충분하지 않습니다.실제 비용: 사용자 신뢰와 UI 혼란
제대로 작동하지 않는 기능을 배포하는 것에 대한 것은: 그것이 적극적으로 신뢰를 훼손합니다. "주 화자 설정" 버튼을 보는 사용자는 의미 있는 것을 한다고 가정합니다. 화자 레이블이 잘못되었을 때 — 지속적으로 — 사용자는 "기술적으로 어렵다"고 생각하지 않습니다. 그들은 "이 제품이 깨진 것 같다"고 생각합니다.
우리는 랜딩 페이지에 화자 프로파일링 카드가 있었습니다. 앱 설정에 있었습니다. 제품 설명의 한국어 버전에 있었습니다. 사용자가 잘못된 화자 귀속을 보았을 때마다 VORA의 신뢰도가 타격을 입었습니다. 깨진 기능을 배포하는 것이 기능을 배포하지 않는 것보다 나쁩니다.
모든 것을 삭제하기로 한 결정
커밋 메시지는 다음과 같습니다: "화자 식별 UI 및 논리 제거(Web Speech API 제한)". 그것이 캡처하지 못한 것은 그것으로 이어진 대화입니다.
우리는 대안을 진지하게 평가하는 오후를 소비했습니다. 서버 측 아키텍처로 이동하고 적절한 분류 모델을 사용할 수 있을까요? 예, 하지만 그러면 VORA는 더 이상 완전히 브라우저 기반이 아니고 무료이며, 이것이 우리가 구축하고 있는 핵심입니다. Whisper를 브라우저에 통합하고 로컬 화자 분류 모델을 실행할 수 있을까요? 이론상으로는 그러하지만 WASM 성능은 실시간 사용에는 너무 느렸습니다(이에 대한 별도의 게시물). 휴리스틱 기반 시스템을 더 잘 만들 수 있을까요? 우리는 시도했습니다. 해결할 수 있는 문제가 아니었습니다.
삭제할 많은 코드였습니다. 삭제하기가 좋지 않았습니다. 하지만 코드베이스가 더 깔끔했고, 제품이 더 정직했으며, 비판적으로 — 정리된 버전을 테스트한 사용자는 거짓 화자 레이블 없이 전사만 표시되기 때문에 일관되게 더 나은 피드백을 제공했습니다.
대신 배포한 것
화자 감지가 없으면 개발 용량이 해제되었습니다. 우리는 실제로 전사를 더 유용하게 만드는 것들에 투자했습니다: AI 수정 파이프라인(Gemini 통합이 됨), N-Best 후보 재순위 시스템, 도메인 특화 용어 수정에 도움이 되는 회의 컨텍스트 주입. 이러한 기능은 무엇이 말했는지는 말하지 않지만 무엇이 말했는지가 정확하게 전사되도록 합니다. 이것이 훨씬 더 가치 있다는 것으로 밝혀졌습니다.
우리가 계속 돌아오는 교훈
"우리 아키텍처 제약이 주어졌을 때 이것을 받을 수 있는 품질로 할 수 없고, 그렇지 않으면 하는 것이 제품을 더 나쁘게 만드는" 엔지니어링 결정의 범주가 있습니다. 순수 브라우저 기반, Web Speech API 기반 애플리케이션에서 화자 분류는 그런 종류의 문제입니다. JavaScript 영리함은 누락된 API 기능을 고칠 수 없습니다.
교훈은 "야심을 갖지 마세요"가 아닙니다. 이것입니다: 그 제약이 하드인지 소프트인지 확인하기 위해 기능을 구축하는 사용자 대면 기능을 구축하기 전에 플랫폼의 하드 제한을 이해하세요. 우리는 빠른 프로토타입을 구축했어야 했고, 60% 정확도를 보았고, 즉시 컷을 했습니다. 대신 우리는 2주 동안 깨진 UI를 광택 냈습니다.
향후 참조 — 그리고 Web Speech API를 기반으로 구축하는 다른 모든 사람을 위해 — 하드 한계는: 화자 분류 없음, 원본 오디오 접근 없음, Chrome에서만 실제로 프로덕션 품질, 그리고 Google 서버에 대한 네트워크 연결에 따라 다름. 그 제약 주위에 못생긴 해킹을 만들기보다는 그 제약 내에서 아름다운 것들을 구축하세요.
VORA는 기능 없이 더 낫습니다. 그것이 우리가 그것에 대해 말할 가장 솔직한 것입니다.