
A Microsoft élő átírása 60 nyelvet kezel – a 100 ms-os szám könnyen félreérthető

A Microsoft 2026. október 1-jei bejelentésében elérhetővé tette a MAI-Transcribe-2-Streaming modellt: 60 nyelven készít élő átiratot, és a vállalat szerint a hang beérkezése után valamivel több mint 100 ms alatt adhat első részleges szöveget. A Microsoft Speech SDK útmutatója nyilvános előzetes verzióként jelöli a szolgáltatást, szolgáltatási szintű megállapodás nélkül; ebben az állapotban a gyártó nem ajánlja éles terheléshez.
A BenchLM induláskori összefoglalója szerint a bevezető ár 2026 végéig 0,54 dollár egy órányi hang feldolgozására, az első részleges eredmény ideje pedig más mérőszám, mint a beszédvég után mért végleges átiratkésleltetés. Hangügynöknél egy harmadik idő is számít: mennyi telik el addig, amíg az alkalmazás válasza valóban hallhatóvá válik.
Mit kap az alkalmazás beszéd közben?
A streaming átírás a teljes megszólalás vége előtt ad szöveget. Ez élő feliratnál azonnal látható előny, ügyfélszolgálati hangügynöknél pedig lehetőséget ad arra, hogy a rendszer már a mondat közben előkészítsen egy keresést vagy más, később szükséges műveletet. A köztes átirat azonban újabb hang érkezésekor módosulhat. Ha az alkalmazás minden frissítést új mondatként fűz hozzá a naplóhoz, ugyanazt a beszédet többször is rögzítheti; a köztes szöveg az aktuális változatot helyettesíti, a végleges eredmény pedig külön lezár egy szakaszt.
A folyamatos automatikus nyelvfelismerés többnyelvű beszélgetésnél hasznos, és a támogatott nyelvek között a magyar is szerepel. Van egy fejlesztői szempontból lényeges különbség: a jelenlegi SDK eredménye nem adja vissza külön adatként a felismert nyelvet. Bizalmi pontszám és szószintű időbélyeg sincs az eredményekben; a végleges szakaszhoz csak szakaszszintű időadat tartozik. Ez korlátozza azokat a felületeket, amelyeknek az átirat mellett pontos nyelvkódra vagy szavanként szinkronizált feliratra van szükségük.
Miért nem teljes válaszidő az első részleges szöveg?
Az első időpont az, amikor a beérkező hang alapján megjelenik egy olvasható köztes átirat. A beszélő ekkor még folytathatja a mondatot, a szöveg pedig később változhat. A következő időpont a beszédszakasz lezárása után érkező végleges eredmény. Ennek késleltetése más eseménynél kezdődik: a beszéd végénél, illetve annak felismerésénél. Az első részleges szöveg gyors megjelenéséből ezért nem számolható ki, mikor áll rendelkezésre a lezárt átirat.
A teljes hangügynöki válasz további lépésektől függ. A hangot továbbítani kell, fel kell ismerni a beszéd végét, az átirat alapján esetleg eszközt kell hívni vagy adatot keresni, majd meg kell fogalmazni és beszéddé kell alakítani a választ. A korai részleges szöveg egyes előkészítő lépéseket előrébb hozhat, de nem méri a teljes láncot. Különösen olyan ügyfélszolgálati műveletnél fontos ez, ahol egy név, cím vagy azonosító végleges változatát meg kell várni a továbblépés előtt.
Ugyanaz a rendszer ezért három eltérő élményt adhat: gyorsan induló feliratot, később rögzülő ügyintézési szöveget és még később megszólaló választ. Ha mindháromra egyetlen késleltetési értéket használnak, nem látszik, hogy az átírás, a beszédvég érzékelése, az alkalmazás logikája vagy a beszéd előállítása okozza a várakozást. Az élő feliratnál a köztes szöveg megjelenése és változása feltűnő; egy ügyfélrekordhoz viszont a véglegesített szakasz időpontja fontosabb.
Mit fed a bevezető díj?
Az átírás ára a feldolgozott hang időtartamához kötődik, így a költségbecslés alapja a beküldött hang mennyisége. Az átirat karaktereinek száma vagy a hívások darabszáma önmagában nem adja meg az átírás díját. Egy hangügynök teljes költségében ráadásul külön tétel lehet a válasz megfogalmazása, az esetleges eszközhasználat és a beszédszintézis. Az átírásra meghirdetett díjból ezeket nem lehet levezetni.
A kedvezményes időszak utáni árat az induláskori közlés nem rögzíti. Emiatt a hosszabb távú üzemeltetés költségét nem érdemes a bevezető díj változatlanságára építeni. Az előzetes verzió státusza ugyanilyen fontos a tervezésnél: a hozzáférés ténye nem jelent vállalt rendelkezésre állást egy éles ügyfélszolgálati folyamat számára.
Mit mutathat meg egy magyar próba?
Magyarországi alkalmazásnál a nyelvi támogatás ténye még nem válaszolja meg, hogyan viselkedik a modell a saját hívásokon. Hasznos próbaanyag lehet természetes tempójú magyar beszéd megszakított mondatokkal, nevekkel, címekkel, számokkal, háttérzajjal és nyelvváltással. A köztes és a végleges szöveget külön érdemes összevetni egy előre elkészített pontos átirattal: így kiderülhet, mely kifejezések stabilak már beszéd közben, és melyek módosulnak a szakasz lezárásáig.
Az időmérésben külön eseményként szerepeljen a hang elküldése, az első részleges szöveg, a beszéd vége, a végleges eredmény és a hallható alkalmazásválasz. Ez saját alkalmazásra vonatkozó próba, nem általános teljesítményállítás a modellről. Ha egy ügyintézési művelet pontos névtől, címtől vagy ügyfélazonosítótól függ, a véglegesítés előtti javítások közvetlenül meghatározzák, mikor biztonságos azt elindítani.
Olvassa el ezt is:
Kapcsolódó cikkek


DeepL vagy Google Fordító: magyar szövegnél a feladat típusa dönt

Veo 3.1 vagy Runway Gen-4.5: a valósághűség egyiknél sem garancia

Turnstile vagy reCAPTCHA: az ingyenes keret nem az egyetlen kockázat

GitHub Actions vagy GitLab CI: a csapatlétszám fordíthatja meg a számlát

GitHub Actions cache: a gyorsítás titkokat is kiszivárogtathat
Iratkozzon fel hírlevelünkre
A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.