대화 내용 기록 일괄 처리란 무엇인가요?

일괄 처리 전사는 스토리지에서 대량의 오디오 데이터를 전사하는 데 사용됩니다. 음성 텍스트 변환 REST API와 Speech CLI 모두 일괄 처리 대화 내용 기록을 지원합니다.

요청당 여러 파일을 제공하거나 전사할 오디오 파일이 있는 Azure Blob Storage 컨테이너를 가리킵니다. 일괄 처리 대화 내용 기록 서비스는 제출된 많은 대화 내용 기록을 처리할 수 있습니다. 이 서비스는 파일을 동시에 필사하여 처리 시간을 줄입니다.

작동 방식

일괄 처리 대화 내용 기록을 사용하면 오디오 데이터를 제출한 다음, 대화 내용 기록 결과를 비동기적으로 검색합니다. 이 서비스는 오디오 데이터를 전사하고 결과를 스토리지 컨테이너에 저장합니다. 그런 다음, 스토리지 컨테이너에서 결과를 검색할 수 있습니다.

일괄 처리 전사 REST API를 사용하려면:

1. 일괄 처리 전사용 오디오 파일 찾기 - 사용자 고유의 데이터를 업로드하거나 퍼블릭 URI 또는 SAS(공유 액세스 서명) URI를 통해 기존 오디오 파일을 사용할 수 있습니다.
2. 일괄 처리 전사 만들기 - 오디오 파일, 전사 언어 및 전사 모델과 같은 매개 변수를 사용하여 전사 작업을 제출합니다.
3. 일괄 처리 전사 결과 가져오기 - 전사 상태를 확인하고 전사 결과를 비동기적으로 검색합니다.

성능 향상을 위한 모범 사례

요청 크기: 일괄 처리 전사는 비동기적이며 요청은 각 지역에서 한 번에 하나씩 처리됩니다. 작업을 더 높은 속도로 제출해도 처리 속도가 빨라지지 않습니다. 예를 들어 분당 600개 또는 6,000개의 요청을 보내는 것은 처리량에 영향을 주지 않습니다. 단일 Transcription_Create 요청으로 최대 1,000명의 파일을 제출하는 것이 좋습니다. 이렇게 하면 전체적으로 요청을 더 적게 보냅니다.

시간 분포: 시간에 따라 요청 배포: 몇 분 내에 모두 전송하지 않고 몇 시간에 걸쳐 제출합니다. 백 엔드 처리는 고정 대역폭으로 인해 안정적인 성능 수준을 유지하므로 요청을 너무 빨리 보내면 성능이 향상되지 않습니다.

작업 모니터링: 작업 상태를 모니터링할 때 몇 초마다 폴링할 필요가 없습니다. 여러 작업을 제출하는 경우 첫 번째 작업만 처음에 처리됩니다. 후속 작업은 첫 번째 작업이 완료될 때까지 대기합니다. 모든 작업을 자주 폴링하면 이점 없이 시스템 부하만 증가합니다. 10분마다 상태를 확인하는 것으로 충분하며 분당 두 번 이상 폴링하는 것은 권장되지 않습니다.

• 순차적 처리로 인해 파일의 하위 집합만 확인하여 작업 상태를 얻을 수 있습니다. 처음 100개 파일을 확인하고 완료되지 않은 경우 이후 일괄 처리도 경쟁하지 않을 수 있습니다. 다시 확인하기 전에 적어도 1분(이상적으로 5분)을 기다리는 것이 좋습니다.

API 호출의 최대 트래픽을 방지합니다. , Update및 Get API 호출은 ListFiles호출과 유사하게 Create 동작하며 최대 트래픽 시간 동안 최소화되어야 합니다.

부하 분산: 대규모 일괄 처리 전사에 대한 처리량을 최적화하려면 여러 지원되는 Azure 지역에 작업을 분산하는 것이 좋습니다. 이 방법은 데이터 및 규정 준수 요구 사항이 다중 지역 사용을 허용하는 경우 부하를 분산하고 전체 처리 시간을 줄이는 데 도움이 될 수 있습니다. 지역 가용성을 검토하고 사용하려는 각 지역에서 스토리지 및 리소스에 액세스할 수 있는지 확인합니다.

관련 콘텐츠

• 일괄 처리 대화 내용 기록을 위한 오디오 파일 찾기
• 일괄 처리 기록 만들기
• 일괄 처리 기록 결과 가져오기
• GitHub에서 일괄 처리 대화 내용 기록 코드 샘플 보기