인터페이스 구분 사용
AmiVoice API는 용도에 따라 3가지 인터페이스를 제공합니다.
이 섹션에서는 각각의 차이점과 구분해서 사용하기 위한 기준에 대해 설명합니다.
동기 HTTP 인터페이스
구현이 가장 간단한 방법입니다. 요청 파라미터를 추가하여 음성 파일을 HTTP POST로 전송하면, 응답으로 발화 내용의 텍스트를 얻을 수 있습니다. 음성 파일의 크기가 16MB 이하인 경우에만 사용할 수 있습니다.
유스 케이스
- 인식 정확도 등의 검증을 하고 싶은 경우
- 애플리케이션에 쉽게 통합하고 싶은 경우
- 짧은 발화를 인식하고 싶은 경우
인식 결과를 순차적으로 받을 수는 없지만, 인식하고자 하는 발화가 몇 초 정도로 충분히 짧고 결과의 실시간성도 그다지 강하게 요구되지 않는 경우에는 프로덕션에서도 사용할 수 있습니다.
장점
음성과 몇 가지 파라미터만 HTTP POST로 전송하면 되므로 쉽게 구현할 수 있습니다. 또한, curl, Postman, Visual Studio Code의 REST Client 등 HTTP 요청을 보낼 수 있는 도구가 있으면 바로 시도해볼 수 있습니다.
주의사항
- 음성 파일이 16MB를 초과하는 경우 오류가 발생합니다.
- Chunked 형식으로 분할 전송할 수도 있습니다. 단, 결과는 한꺼번에 반환합니다.
- 전송한 음성 데이터에 여러 발화 구간이 포함된 경우에도 발화 구간의 시간 정보를 반환하지 않습니다. 발화 구간의 결과가 필요한 경우에는 비동기 HTTP 인터페이스나 WebSocket 인터페이스를 사용하십시오.
- 인식 중간 결과(음성 인식 결과의 확정 전 가설)는 반환하지 않습니다. 인식 중간 결과가 필요한 경우에는 WebSocket 인터페이스를 사용하십시오.
리소스
- 튜토리얼의 짧은 음성 파일 받아쓰기에 단계별 실행 예시가 나와 있습니다.
- 사용 가이드의 동기 HTTP 인터페이스에 요청 전송 방법이 설명되어 있습니다.
- 자세한 사양은 API 레퍼런스의 동기 HTTP 인터페이스를 참조하십시오.
비동기 HTTP 인터페이스
음성 인식 작업으로 서버 측에서 비동기적으로 음성 인식 처리가 실행됩니다. 작업이 완료될 때까지 폴링하고, 작업이 완료되면 인식 결과를 얻을 수 있습니다.
유스 케이스
- 큰 음성 파일(16MB보다 큰 경우)을 텍스트로 변환하고 싶은 경우
- 순차적 응답을 받을 필요가 없고, 조금이라도 정확도를 높이고 싶은 경우
예를 들어, 콜센터의 통화 녹음 파일이나 회의 녹음 파일을 일괄적으로 텍스트화하는 배치 처리를 상정하고 있습니다.
음성 인식에 걸리는 시간은 전송한 음성의 0.51.5배 정도입니다. 예를 들어, 1시간의 음성을 전송한 경우 결과를 얻기까지 3090분 정도의 시간이 걸립니다. 이런 경우, 하나의 HTTP 세션으로 요청과 결과 취득을 수행하면 장시간 세션을 유지해야 하며, 중간에 세션이 끊어질 경우 결과를 얻지 못할 가능성이 있습니다. 따라서 동기 HTTP 인터페이스에서는 음성 파일의 크기를 16MB 이하로 제한하고 있으며, 그보다 큰 음성 파일은 비동기 HTTP 인터페이스를 사용하여 요청과 결과 취득을 분리하여 수행하도록 하고 있습니다.
장점
- 다른 인터페이스보다 정확도가 좋아질 가능성이 있습니다.
노트
당사의 다양한 테스트 세트에 대해, 비동기 HTTP 인터페이스는 다른 인터페이스보다 오류 개선율이 평균 5%포인트 높은 결과를 보였습니다. 이는 다음과 같은 이유 때문입니다:
- 응답을 즉시 반환할 필요가 없으므로, 특정 시점의 음성 발화 내용을 추정할 때 많은 미래 정보를 미리 읽은 후 처리할 수 있습니다.
- 동기 HTTP나 WebSocket 인터페이스를 사용하여 인식할 때보다 더 많은 계산 리소스를 사용할 수 있도록 설정되어 있습니다.
- 토큰 별 시간 정보뿐만 아니라 발화 구간의 결과로부터 발화 시작 및 종료 시간 정보를 얻을 수 있습니다. 음성 파일에 여러 발화 구간이 포함된 경우, 발화의 시작 시각, 종료 시각을 이용할 수 있습니다.
주의사항
- 작업을 시작하기까지 수십 초~수 분 정도의 지연이 있으므로, 짧은 음성을 인식하는 경우에는 상대적으로 지연 시간의 영향이 크게 됩니다. 또한, 짧은 음성에 대해서는 위의 장점인 정확도 개선 효과도 작아집니다.
- 인식 중간 결과(음성 인식 결과가 확정되기 전의 가설)는 반환하지 않습니다. 인식 중간 결과가 필요한 경우에는 WebSocket 인터페이스를 사용하십시오.
리소스
- 튜토리얼의 긴 음성 파일 받아쓰기에 단계별 실행 예시가 나와 있습니다.
- 사용 가이드의 비동 기 HTTP 인터페이스에 요청 전송 방법이 설명되어 있습니다.
- 자세한 사양은 API 레퍼런스의 비동기 HTTP 인터페이스를 참조하십시오.
WebSocket 인터페이스
WebSocket 연결을 통해 양방향 통신이 가능해집니다. 스트리밍 음원에서 음성을 서버로 조금씩 전송하고, 음성 인식 결과를 순차적으로 얻을 수 있습니다. 실시간성이 요구되는 애플리케이션에 적합합니다.
유스 케이스
- 음원이 음성 스트림이며 순차적으로 결과를 얻어 사용하고 싶은 경우
- 음성 인식의 중간 결과(음성 인식 결과의 확정 전 가설)를 이용하고 싶은 경우
- 사용자의 말하기 끝 검출의 정확도를 높이고 싶은 경우
장점
- 음성 인식 결과를 순차적으로 얻을 수 있습니다.
- 인식 중간 결과(음성 인식 결과가 확정되기 전의 가설)를 얻을 수 있습니다. 음성 인식 결과는 발화의 끝단을 검출한 후에 결과가 확정되므로, 실시간 애플리케이션에서는 결과를 얻기까지 시간이 걸립니다. 화면에 중간 결과를 표시함으로써 사용자에게 빠른 응답을 실현할 수 있습니다.
- 발화의 끝단 검출을 API 측에서 수행할 수 있습니다. 예를 들어, 동기 HTTP 인터페이스를 사용하여 대화형 애플리케이션을 구현하려고 하면, 사용자가 말을 끝낸 타이밍에 녹음을 종료하고 음성 파일을 생성해야 합니다. 녹음 시스템이 끝단 검출 기능을 가지고 있지 않거나 단순한 음량 기반 구현만 가지고 있는 경우, 배경 노이즈가 큰 경우나 사용자의 목소리가 작은 경우 등에는 제대로 작동하지 않을 수 있습니다. WebSocket 인터페이스의 경우, 음성 데이터를 순차적으로 전송하기만 하면 AmiVoice API의 심층 학습 모델을 사용한 발화의 끝단 검출을 이용할 수 있어, 단순한 음량에 의한 끝단 검출보다 좋은 정확도로 말하기 끝을 검출하고 결과를 얻을 수 있습니다.
- 토큰 단위의 시간 정보뿐만 아니라 발화 단위의 결과를 얻을 수 있습니다. 음성 파일에 여러 발화 구간이 포함된 경우, 발화의 시작 시각, 종료 시각을 이용할 수 있습니다.
주의사항
- WebSocket 연결 후, 음성 인식 서버와는 독자적인 텍스트 기반 프로토콜로 통신해야 하므로 구현이 복잡해집니다.
리소스
- 사용 가이드의 WebSocket 인터페이스에 요청 전송 방법이 설명되어 있습니다.
- 프로토콜의 세부 사항을 숨기고 다양한 프로그래밍 언어에서 쉽게 다룰 수 있도록 한 클라이언트 라이브러리를 제공하고 있습니다. 실시간 음성 인식 라이브러리 Wrp 사용법에서 설명하고 있습니다.
- 자세한 사양은 API 레퍼런스의 WebSocket 인터페이스를 참조하십시오.