Mi az a kötegelt átírás?

A kötegelt átírás segítségével nagy mennyiségű hangadatot írhat át a tárolóból. A Speech to text REST API és a Speech CLI egyaránt támogatja a kötegelt átírást.

Kérésenként több fájlt kell megadnia, vagy az átírandó hangfájlokat tartalmazó Azure Blob Storage-tárolóra kell mutatnia. A kötegelt átírási szolgáltatás nagyszámú beküldött átírási feladatot képes kezelni. A szolgáltatás egyszerre írja át a fájlokat, ami csökkenti az átfutási időt.

Hogyan működik?

Kötegelt átiratokkal elküldheti a hangadatokat, majd aszinkron módon lekérheti az átírási eredményeket. A szolgáltatás átírja a hangadatokat, és egy tárolóban tárolja az eredményeket. Ezután lekérheti az eredményeket a tárolóból.

Tipp

Alacsony kódszámú vagy kód nélküli megoldás esetén használja a Batch Speech-összekötőt olyan Power Platform-alkalmazásokban, mint a Power Automate, a Power Apps és a Logic Apps. Első lépésként tekintse meg a Power Automate kötegelt átírási útmutatót.

A kötegelt átíráshoz használt REST API használata:

  1. Hangfájlok megkeresése kötegelt átíráshoz – Feltöltheti saját adatait, vagy használhat meglévő hangfájlokat nyilvános URI vagy közös hozzáférésű jogosultságkód (SAS) URI használatával.
  2. Kötegelt átírás létrehozása – Küldje el az átírási feladatot olyan paraméterekkel, mint a hangfájlok, az átírás nyelve és az átírási modell.
  3. Kötegelt átírási eredmények lekérése – Ellenőrizze az átírás állapotát, és aszinkron módon kérje le az átírási eredményeket.

Fontos

A szolgáltatás a kötegátírási feladatokat a legjobb munkamennyiség alapján ütemezi. Csúcsidőben akár 30 percet is igénybe vehet, amíg egy átírási feladat elkezdi a feldolgozást, és akár 24 órát is igénybe vehet. Megtudhatja, hogyan ellenőrizheti egy kötegelt átírási feladat aktuális állapotát ebben a szakaszban.

Ajánlott eljárások a teljesítmény javításához

Kérelem mérete: A batch-átírás aszinkron, és minden régió egyenként dolgozza fel a kéréseket. A feladatok magasabb sebességgel történő elküldése nem felgyorsítja a feldolgozást. Például 600 vagy 6000 kérés küldése percenként nincs hatással az átviteli sebességre. Egyetlen kérelemben körülbelül 1000 fájlt küldhet el, hogy összességében Transcription_Create kevesebb kérést küldjön.

Időeloszlás: A kérések elosztása az idő függvényében. Küldje el őket több órán keresztül ahelyett, hogy néhány percen belül elküldené őket. A háttérfeldolgozás a rögzített sávszélesség miatt stabil teljesítményszintet tart fenn, így a kérések túl gyors elküldése nem javítja a teljesítményt.

Feladatfigyelés: A feladat állapotának figyelésekor nincs szükség az állapot néhány másodpercenkénti lekérdezésére. Ha több feladatot küld el, a szolgáltatás kezdetben csak az első feladatot dolgozza fel; a következő feladatok várnak, amíg az első feladat befejeződik. Az összes feladat lekérdezése gyakran előny nélkül növeli a rendszer terhelését. Az állapot 10 percenkénti ellenőrzése elegendő, és nem ajánlott percenként többször lekérdezni.

  • A szekvenciális feldolgozás miatt a feladatok állapotát úgy kaphatja meg, hogy csak a fájlok egy részhalmazát ellenőrzi: ellenőrizze az első 100 fájlt, és ha még nem fejeződött be, a későbbi kötegek valószínűleg nem is fejeződnek be. Várjon legalább egy percet (ideális esetben öt percet) az újbóli ellenőrzés előtt.

Kerülje az API-hívások maximális forgalmát: Minimalizálja a ListFiles, Updateés Get API-hívásokat a csúcsforgalom idején. Ezek a hívások úgy viselkednek, mint a Create hívás.

Terheléselosztás: A nagy léptékű kötegelt átírás áteresztőképességének optimalizálása érdekében érdemes a feladatokat több támogatott Azure-régió között elosztani. Ez a megközelítés segíthet a terhelés elosztásában és az általános feldolgozási idő csökkentésében, feltéve, hogy az adatok és a megfelelőségi követelmények lehetővé teszik a többrégiós használatot. Tekintse át a régiók rendelkezésre állását , és győződjön meg arról, hogy a tárterület és az erőforrások minden használni kívánt régióból elérhetők.

A késés hozzávetőleges becslése

A késleltetés az a teljes folyamat ideje, amely egy kötegnyi hangadat átírásához szükséges. Nehéz megbecsülni, mert több tényező határozza meg:

  • A kérelemben szereplő teljes hanghossz.
  • Szükség van-e további funkciókra, például a diarizálásra és a nyelvazonosításra.
  • A feladatsor hossza a rendszerben abban az időben.
  • A rendszer hardvererőforrás-konfigurációja.

De biztosak vagyunk abban, hogy a 90. percentilis késés kevesebb, mint 6 óra. A normalizált késés számítási módszerét az alábbiak szerint határozzuk meg:

Normalizált késés = ProcessDuration – AudioLength/5

Ha például a AudioLength 120 perc, és a végpontok közötti ProcessDuration 30 perc: 30 – 120/5 = 6, ahol az 5 tényező azt jelenti, hogy a rendszer nagyjából 5x valós idejű sebességgel dolgozza fel a hangokat. A 6 perc normál körülmények között az üzenetsor várakozási idejét jelöli, amely nem haladja meg a hat órát. Szélsőséges esetekben ez akár 24 óra vagy annál is több lehet, mivel a függőben lévő várólista nagyon hosszú lehet, ami megnövelheti a teljes ProcessDuration időtartamot.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: