어셈블리AI, 자체 VAD 팀에 동기식 HTTP 전사 방식 제시

어셈블리AI(AssemblyAI)가 자체 음성 활동 감지(VAD)로 발화 종료를 판단하는 음성 에이전트 개발팀에 동기식 HTTP 전사 방식을 제시했다. 사용자가 말을 마친 뒤 음성 조각을 보내면 같은 HTTP 응답으로 전사문을 받는 구조다.

어셈블리AI는 10월 26일 공개한 기술 글에서 자체 VAD와 대화 흐름 관리 체계를 운영하는 팀에 Sync 방식이 맞는다고 설명했다. 여러 대형 음성 에이전트 개발팀이 이런 API를 요청했다고 밝혔지만, 팀 이름이나 도입 성과는 공개하지 않았다.

이 방식에서는 개발팀의 VAD가 발화의 시작과 끝을 감지해 음성을 모은다. 완성된 음성 조각을 Sync API에 보내면 별도 결과 조회 없이 전사문을 한 번의 응답으로 돌려받고, 이를 대규모 언어모델(LLM)에 넘긴 뒤 생성된 답을 음성 합성(TTS)에 전달한다.

요청과 응답을 주고받는 구조라 통화 내내 음성 인식(STT)용 WebSocket 연결을 유지할 필요는 없다. 다만 발화가 끝나야 음성 파일을 보낼 수 있어, 말하는 도중 전사 결과를 받는 방식과 처리 흐름이 다르다.

Sync는 발화 중 부분 전사문을 제공하지 않는다. 따라서 부분 전사문을 바탕으로 LLM 처리를 먼저 시작하려는 경우에는 실시간 스트리밍과 맞지 않는 차이가 생긴다.

발화 종료 감지가 부정확하면 문장 끝이 잘리거나 불필요한 침묵이 음성 조각에 포함될 수 있다. 발화 경계와 대화 중 끼어들기 처리도 개발팀이 관리해야 한다.

실시간 스트리밍은 음성을 WebSocket으로 연속 전송하고, 발화가 끝나기 전 부분 전사문을 전달한다. 어셈블리AI는 실시간 STT 가이드에서 부분 전사가 필요하거나 STT가 발화 종료를 감지하도록 맡기려는 음성 에이전트에 Universal-3.6 Pro Realtime을 권한다.

Sync 문서가 기본 모델로 안내하는 것은 Universal-3.5 Pro다. 실시간 스트리밍에 권하는 Universal-3.6 Pro Realtime과 모델 버전이 다르다.

따라서 두 방식을 비교할 때는 통신 방식뿐 아니라 모델 차이도 함께 봐야 한다. Sync는 자체 VAD와 대화 흐름 관리 체계를 갖추고 발화 단위로 요청하는 구성을 원하는 팀을 위한 선택지로 제시됐다.

Sync STT 문서는 완성된 음성 파일을 한 번에 전사하는 방식과 실시간으로 발화 중인 단어를 받는 스트리밍 방식을 구분한다. 짧은 음성 명령이나 이미 녹음된 발화를 처리할 때는 발화 종료 뒤 전사문을 받는 Sync의 흐름을 활용할 수 있다.

처리시간 수치는 측정 구간을 나눠 봐야 한다. 어셈블리AI는 미국과 유럽에서 Sync의 중간값(P50) 처리시간을 약 134밀리초로 소개했으며, 이는 서버 처리시간 기준이다.

별도의 기술 설명에는 싱가포르에서 약 15초 분량을 녹음한 시연의 전체 응답시간이 약 1,900밀리초였다고 적혔다. 이 수치는 음성 전송과 응답 수신을 포함해 앞선 처리시간과 측정 구간이 다르며, LLM 답변 생성과 TTS 재생까지 포함한 음성 에이전트의 전체 응답시간은 아니다.

LiveKit의 AssemblyAI 연동 문서는 Universal-3.6 Pro 스트리밍 모델을 음성 에이전트에 연결하는 방법을 안내한다. 이 문서는 스트리밍 연동 경로를 보여주는 자료로, Sync 방식의 채택 현황을 나타내지는 않는다.

본지는 앞서 어셈블리AI가 음성 인식부터 답변 생성과 음성 출력까지 연결하는 구성을 제시한 내용을 다뤘다. 이번 기술 글은 그중 음성 인식 단계에서 발화별 HTTP 요청과 실시간 스트리밍을 구분해 설명했다.