Zestaw przetwarzania wsadowego dla kontenerów mowy

Użyj zestawu do przetwarzania wsadowego, aby uzupełnić i skalować obciążenia w kontenerach mowy. Dostępne w formie kontenera, to otwartoźródłowe narzędzie ułatwia transkrypcję wsadową dużej liczby plików audio na różnych lokalnych i chmurowych punktach końcowych dla systemów rozpoznawania mowy.

Diagram przedstawiający przykładowy przepływ pracy kontenera zestawu batch-kit.

Kontener zestawu wsadowego jest dostępny bezpłatnie na GitHubie i Docker Hubie. Opłaty są naliczane tylko za używane kontenery usługi rozpoznawania mowy.

Funkcja opis
Dystrybucja plików audio w partii Automatycznie wysyłaj dużą liczbę plików do lokalnych lub chmurowych punktów końcowych kontenera usługi Mowa. Pliki mogą znajdować się na dowolnym woluminie zgodnym ze standardem POSIX, w tym w systemach plików sieciowych.
Integracja zestawu SDK usługi mowy Przekaż standardowe flagi do Speech SDK, w tym: najlepsze n-hipotezy, diarizacja, język, maskowanie wulgaryzmów.
Tryby uruchamiania Uruchom klienta wsadowego raz, stale w tle lub utwórz punkty końcowe HTTP dla plików audio.
Odporność na uszkodzenia Automatycznie ponów próbę i kontynuuj transkrypcję bez utraty postępu oraz rozróżniaj, które błędy mogą i nie można ich ponowić.
Wykrywanie dostępności punktu końcowego Jeśli punkt końcowy stanie się niedostępny, klient wsadowy kontynuuje transkrypcję przy użyciu innych punktów końcowych kontenera. Gdy klient jest dostępny, automatycznie rozpoczyna korzystanie z punktu końcowego.
Wymiana punktów końcowych na gorąco Dodawanie, usuwanie lub modyfikowanie punktów końcowych kontenera służącego do przetwarzania mowy podczas wykonywania wsadu, bez przerywania jego postępu. Aktualizacje są natychmiastowe.
Rejestrowanie w czasie rzeczywistym Rejestrowanie żądań, sygnatur czasowych i przyczyn niepowodzenia w czasie rzeczywistym z plikami dziennika zestawu SPEECH SDK dla każdego pliku audio.

Bezpieczne przetwarzanie długiego dźwięku

Kontenery mowy obsługują dźwięk z maksymalnym czasem trwania 24 godzin. Podziel wszystkie pliki audio dłuższe niż 24 godziny przed przesłaniem ich do transkrypcji. Rozmiar pliku nie jest niezawodnym zamiennikiem czasu trwania, ponieważ kodowanie, częstotliwość próbkowania, głębokość bitów i liczba kanałów określają liczbę bajtów. Na przykład 1 GB nie jest uniwersalnym progiem segmentacji.

Niektóre ścieżki przetwarzania dźwięku wykorzystują 32-bitowy licznik do obliczania czasu trwania. Po około 37,3 godziny licznik może ulec przepełnieniu i zwrócić krótszy, pozornie prawidłowy czas trwania. W takim przypadku transkrypcja może zgłosić powodzenie bez ostrzeżenia, że wynik zostanie obcięty. Dokładne miejsce w kodzie, w którym występuje to przepełnienie, nie jest znane.

Po transkrypcji porównaj oryginalny czas trwania dźwięku z końcowym przesunięciem w transkrypcji lub ostatnim rozpoznanym znacznikiem czasu. Traktuj wynik, który kończy się znacząco przed końcem oryginalnego nagrania audio, jako niekompletny, nawet jeśli transkrypcja wskazuje powodzenie.

Jeśli przekonwertujesz dźwięk źródłowy na RIFF/WAV, użyj tych wartości, aby ułatwić zidentyfikowanie miejsca wystąpienia przepełnienia:

  • Długość przekonwertowanego fragmentu danych WAV wynosząca 274,568,704 bajtów wskazuje na przepełnienie podczas konwersji lub zapisu pliku.
  • Fragment danych o długości 4,569,536,000 bajtów lub plik większy niż 4 GB z poprawnym nagłówkiem wskazuje, że plik został zapisany poprawnie, a przepełnienie nastąpiło później w potoku przetwarzania. Skontaktuj się z pomocą techniczną Microsoft, aby zaangażować inżynierów w tym przypadku.

RF64 i Wave64 (W64) nie są bezpośrednim rozwiązaniem tego problemu. Każda ścieżka odczytu i sprawdzania czasu trwania w potoku musi obsługiwać wybrany format. Na przykład wbudowany wave moduł Python odrzuca pliki RF64.

Pobieranie obrazu kontenera za pomocą polecenia docker pull

Użyj polecenia docker pull, aby pobrać najnowszy kontener zestawu batch.

Uwaga

Poniższy przykład ściąga publiczny obraz kontenera z usługi Docker Hub. Zalecamy najpierw uwierzytelnienie przy użyciu konta usługi Docker Hub (docker login) zamiast tworzenia anonimowego żądania ściągnięcia. Aby zwiększyć niezawodność podczas korzystania z zawartości publicznej, zaimportuj obraz i zarządzaj nim w prywatnym rejestrze kontenerów platformy Azure. Dowiedz się więcej o pracy z obrazami publicznymi.

docker pull docker.io/batchkit/speech-batch-kit:latest

Konfiguracja punktu końcowego

Klient wsadowy używa pliku konfiguracji YAML, który określa lokalne punkty końcowe kontenera. Zapisz poniższy przykład w /mnt/my_nfs/config.yaml, którego użyto w poniższych przykładach.

MyContainer1:
  concurrency: 5
  host: 192.168.0.100
  port: 5000
  rtf: 3
MyContainer2:
  concurrency: 5
  host: BatchVM0.corp.redmond.microsoft.com
  port: 5000
  rtf: 2
MyContainer3:
  concurrency: 10
  host: localhost
  port: 6001
  rtf: 4

Ten przykład YAML określa trzy kontenery mowy na trzech hostach. Pierwszy host jest określany przez adres IPv4, drugi host działa na tej samej maszynie wirtualnej co klient wsadowy, a trzeci kontener jest określony przez nazwę hosta DNS innej maszyny wirtualnej. Wartość concurrency określa maksymalną współbieżną transkrypcję plików, które mogą być uruchamiane w tym samym kontenerze. rtf Wartość (współczynnik czasu rzeczywistego) jest opcjonalna i może służyć do dostosowywania wydajności.

Klient wsadowy może dynamicznie wykrywać, czy punkt końcowy stanie się niedostępny (na przykład z powodu problemu z ponownym uruchomieniem kontenera lub siecią), a gdy stanie się ponownie dostępny. Żądania transkrypcji nie są wysyłane do kontenerów, które są niedostępne, a klient kontynuuje korzystanie z innych dostępnych kontenerów. Punkty końcowe można dodawać, usuwać i edytować w dowolnym momencie bez przerywania postępu partii.

Uruchom kontener przetwarzania wsadowego

 

Uwaga

  • W tym przykładzie użyto tego samego katalogu (/my_nfs) dla pliku konfiguracji i danych wejściowych, danych wyjściowych i katalogów dzienników. Dla tych folderów można używać katalogów hostowanych lub zamontowanych w systemie plików NFS.
  • Uruchomienie klienta z flagą –h zawiera listę dostępnych parametrów wiersza polecenia i ich wartości domyślne. 
  • Kontener przetwarzania wsadowego jest obsługiwany tylko na platformie Linux.

Użyj polecenia platformy Docker run , aby uruchomić kontener. To polecenie uruchamia interaktywną powłokę wewnątrz kontenera.

docker run --network host --rm -ti -v /mnt/my_nfs:/my_nfs --entrypoint /bin/bash /mnt/my_nfs:/my_nfs docker.io/batchkit/speech-batch-kit:latest

Aby uruchomić klienta wsadowego:

run-batch-client -config /my_nfs/config.yaml -input_folder /my_nfs/audio_files -output_folder /my_nfs/transcriptions -log_folder /my_nfs/logs -file_log_level DEBUG -nbest 1 -m ONESHOT -diarization None -language en-US -strict_config

Aby uruchomić klienta wsadowego i kontener w jednym poleceniu:

docker run --network host --rm -ti -v /mnt/my_nfs:/my_nfs docker.io/batchkit/speech-batch-kit:latest -config /my_nfs/config.yaml -input_folder /my_nfs/audio_files -output_folder /my_nfs/transcriptions -log_folder /my_nfs/logs

Klient rozpoczyna działanie. Jeśli plik audio został transkrypowany w poprzednim przebiegu, klient automatycznie pomija plik. Pliki są wysyłane z automatycznym ponawianiem w przypadku wystąpienia błędów przejściowych, a Ty możesz zdecydować, które błędy mają być ponawiane przez klienta. W przypadku błędu transkrypcji klient kontynuuje transkrypcję i może ponowić próbę bez utraty postępu.

Tryby uruchamiania

Zestaw przetwarzania wsadowego oferuje trzy tryby, używając parametru --run-mode.

ONESHOT tryb transkrybuje pojedynczą partię plików audio (z katalogu wejściowego i opcjonalnej listy plików) do folderu wyjściowego.

Diagram przedstawiający przetwarzanie plików w kontenerze zestawu "batch-kit" w trybie jednorazowym.

  1. Zdefiniuj punkty końcowe kontenera Speech, które klient wsadowy używa w pliku config.yaml.
  2. Umieść pliki audio na potrzeby transkrypcji w katalogu wejściowym.
  3. Wywołaj kontener w katalogu, aby rozpocząć przetwarzanie plików. Jeśli plik audio został już transkrybowany w poprzednim uruchomieniu z tym samym katalogiem wyjściowym (ta sama nazwa pliku i suma kontrolna), klient pomija ten plik.
  4. Pliki są wysyłane do punktów końcowych kontenera z kroku 1.
  5. Dzienniki i dane wyjściowe kontenera usługi Mowa są zwracane do określonego katalogu wyjściowego.

Rejestrowanie

Uwaga

Klient wsadowy może okresowo nadpisywać plik run.log, jeśli jest zbyt duży.

Klient tworzy plik run.log w katalogu określonym przez -log_folder argument w poleceniu platformy Docker run . Dzienniki są domyślnie przechwytywane na poziomie DEBUG. Te same dzienniki są wysyłane do stdout/stderr i filtrowane w zależności od argumentów -file_log_level lub console_log_level. Ten dziennik jest niezbędny tylko do debugowania lub jeśli konieczne jest wysłanie śladu w celu uzyskania pomocy technicznej. Folder logów zawiera również logi SDK do obsługi mowy dla każdego pliku audio.

Katalog wyjściowy określony przez -output_folder zawiera plik run_summary.json, który jest okresowo przepisywany co 30 sekund lub po zakończeniu nowych transkrypcji. Możesz użyć tego pliku, aby śledzić postępy w miarę postępu przetwarzania wsadowego. Zawiera również końcowe statystyki uruchomienia i stan końcowy każdego pliku po zakończeniu przetwarzania wsadowego. Partia jest zakończona, gdy proces ma czyste zakończenie.

Następne kroki

  • Ostatnia aktualizacja o