Skapa en transkriptionspipeline för tal till text med Azure Cognitive Services

Azure Active Directory
API Management
Blob Storage
Cognitive Services
Event Grid
Functions
Key Vault
Storage

Kundtjänstcenter är en viktig del av framgången för många företag. Du kan förbättra effektiviteten i dina callcenter med hjälp av speech AI. Taligenkänning och analys av stora volymer av registrerade kundsamtal kan ge din verksamhet värdefull information om aktuella trender, produktbrister och framgång. Företagslösningar som använder Speech-API:er för Azure Cognitive Services kan implementeras för att använda och bearbeta så stora mängder diskreta data.

Referensarkitekturen som beskrivs i den här artikeln visar hur du skapar en pipeline för ljudinmatning och transkription från tal till text för kundtjänster. Den här pipelinen bearbetar batchar med inspelade ljudfiler och lagrar de transkriberade textfilerna i Azure Blob Storage. Den här arkitekturen implementerar inte talbearbetning i realtid.

Den här pipelinen kan senare matas in i nästa fas i din speech AI-implementering. I den fasen kan du bearbeta transkriberad text för att identifiera och ta bort känslig information, utföra attitydanalys och så vidare.

Referensimplementering för den här arkitekturen finns på GitHub.

Arkitektur

Arkitekturdiagram: mata in och konvertera tal till text med hjälp av Azure Cognitive Services

Du kan implementera den här arkitekturen med hjälp av ditt Azure-konto och tillåta klientprogram åtkomst till pipelinen via REST-API:er. Programmet går igenom en trestegsprocess för att ladda upp en ljudfil:

  1. Autentiserar med hjälp Azure Active Directory (Azure AD). Det här steget krävs för den första filuppladdningen.
  2. Anropar REST API för att hämta den SAS-token (signatur för delad åtkomst) som krävs för åtkomst Azure Blob Storage.
  3. Överför ljudfilerna till en blobcontainer.

Referensklientprogrammet använder JavaScript för att ladda upp filerna, som du ser i det här exemplet på blobuppladdning. När filen har laddats upp genereras Azure Event Grid utlösare som anropar en Azure-funktion. Funktionen bearbetar filen med hjälp av Azure Cognitive Services Speech-API:er. Den transkriberade texten lagras i en separat blobcontainer som är redo att konsumeras till nästa fas i pipelinen: talanalys och lagring i en databas.

Arkitekturen använder följande Azure-tjänster:

Azure Blob Storage lagrar objekt i molnet. Blob Storage är optimerat för att lagra stora mängder ostrukturerade data, till exempel text eller binära data. Eftersom känslig information kan sparas i bloben måste du skydda åtkomsten med hjälp av autentiseringsmetoder som SAS-nycklar.

Azure Event Grid har inbyggt stöd för effektiv händelsedriven arkitektur i Azure. När uppladdningen av ljudfilen är klar Event Grid en BlobCreated-händelse för transkriptionsfunktionen.

Azure Functions tillhandahåller händelsedrivna beräkningsfunktioner utan att du behöver bygga infrastrukturen. Funktionen i den här referensarkitekturen transkriberar talljudfilerna till text. Modellen är en serverlös modell, vilket innebär att förbrukningsplanen används som värd för funktionen.

Azure Cognitive Services är en samling API:er som kan hjälpa utvecklare att skapa intelligenta program utan omfattande AI- eller datavetenskapskunskaper. Transkriptionsfunktionen anropar Cognitive Services-API:er för tal till text. Utdata för en exempeltranskribering av ljudfiler kan se ut ungefär som följande metadata:

ResultId:19e70bee8b5348a6afb67817825a9586 Reason:RecognizedSpeech Recognized text:<Text for sample audio.>. Json:{"DisplayText":"Text for sample audio.","Duration":53700000,"Id":"28526a6304da4af1922fedd4edcdddbb","Offset":3900000,"RecognitionStatus":"Success"}.

Azure API Management ger säker åtkomst till REST-API:er. Eftersom endast klienter som autentiseras via API Management kan begära en SAS-token ger den här tjänsten ytterligare ett säkerhetslager.

Azure Active Directory identitetshantering och säker åtkomst till resurser på Azure-molnplattformen. Klienten i den här arkitekturen måste först autentisera med hjälp av Azure AD för att kunna komma åt REST API. Den REST API skapar åtkomsttoken för bloblagringen med hjälp av Azure AD-autentiseringsuppgifterna för företagsägaren. Rollbaserad åtkomstkontroll i Azure (Azure RBAC) ger klienten de lägsta åtkomstbehörigheter som krävs för att ladda upp ljudfiler.

Azure Key Vault tillhandahåller säker lagring av hemligheter och nycklar. Den här referensarkitekturen lagrar kontoautentiseringsuppgifter och andra hemligheter som behövs för att generera SAS-token i nyckelvalvet. REST-API:erna och taltranskriskriptionsfunktionen använder det här valvet för att hämta hemligheterna.

Skalbarhetsöverväganden

Azure Blob Storage

Skalbarhet under uppladdning – För att skapa en högpresterande och kostnadseffektiv skalbar lösning använder den här referensarkitekturen designmönstret Valet-nyckel. Klientprogrammet ansvarar för den faktiska datauppladdningen. SAS-token begränsar åtkomsten till bloblagring. Klienten måste först hämta denna token med hjälp av REST API. API:et i referensimplementering genererar en användardelegat-SAS-token som skapas med hjälp Azure Active Directory autentiseringsuppgifterna för företagsägaren. I de flesta fall är den här metoden säkrare och föredras framför SAS-token som skapas med hjälp av en kontonyckel. Mer information om SAS-token finns i Typer av signaturer för delad åtkomst.

Skalbarhet för filstorlek – Referensarkitekturen gör att stora ljudfiler kan laddas upp till molnet genom att dela upp dem i segment på 4 KB. Segmentering är en vanlig teknik som används för att ladda upp stora blobar, vilket beskrivs i den här artikeln om att ladda upp stora blobar. Den maximala filstorleken som kan laddas upp beror på den maximala storleksgränsen för bloben, som kan vara upp till 4,77 TB.

Skalbarhet för lagring – Azure Blob Storage kan begränsa tjänstbegäranden per blob eller per lagringskonto. Begränsningsgränserna på blobnivå kanske inte är ett problem i det här scenariot eftersom varje uppladdad fil motsvarar en enda blob. Flera klienter som laddar upp flera filer till ett enda lagringskonto kan dock överskrida kontots gränser. Om det är möjligt kan du överväga att använda flera lagringskonton och partitionera dataobjekten mellan dem. En detaljerad lista över skalbarhetsöverväganden för bloben finns i Checklista för prestanda och skalbarhet för Blob Storage.

Azure Event Grid

Funktionen som transkriberar ljudfilerna utlöses när uppladdningen är klar. Den här referensarkitekturen använder en Event Grid utlösare i stället för Blob Storage-utlösaren. En Event Grid utlösare används eftersom blobutlösarhändelser kan missas när antalet blobar i en container ökar avsevärt. Saknade utlösare påverkar programmets dataflöde och tillförlitlighet negativt. Mer information finns i Alternativ för blobutlösare.

Azure Cognitive Services

API:er för Cognitive Services kan ha begärandegränser baserat på prenumerationsnivån. Överväg att använda dessa API:er i containrar för att undvika begränsning av bearbetning av stora volymer. Containrar ger dig flexibiliteten att distribuera, oavsett om det är i molnet eller lokalt. Du kan också minska sidoeffekterna av nya versionsutföranden med hjälp av containrar. Mer information finns i Containerstöd i Azure Cognitive Services.

Säkerhetsöverväganden

Många av säkerhetsaspekterna för serverlösa webbprogram gäller för den här referensarkitekturen. I följande avsnitt beskrivs överväganden som är specifika för den här arkitekturen.

Azure Active Directory

Ljudfilerna som lagras i bloben kan innehålla känsliga kunddata. Om flera klienter använder den här lösningen är det viktigt att begränsa åtkomsten till dessa filer. Den här referensarkitekturen använder SAS-token för att skydda dessa filer från attacker utifrån. Dessa token, som kallas SAS-token för användardelegering, skapas med hjälp av tjänstägarens Azure AD-autentiseringsuppgifter.

Med en SAS-token kan du styra:

  • Vilka resurser klienter kan komma åt, eftersom den skapas per resurs.
  • Vilka behörigheter klienter har vid åtkomst till resurserna, via rollbaserad åtkomstkontroll i Azure (Azure RBAC). Vi rekommenderar att du beviljar den lägsta behörighet som krävs. Klienterna i den här arkitekturen har skrivskyddade åtkomst till blobarna. Den här åtkomstnivån hindrar dem från att läsa andra klienters ljudfiler, antingen av misstag eller på ett skadligt sätt.
  • När enskilda token upphör att gälla. Den här kontrollen begränsar exponeringsfönstret för token, vilket begränsar risken för obehörig åtkomst till resursen. För större filer kan SAS-token upphöra att gälla innan uppladdningen är klar. Klienten kan begära flera token för samma fil. Eftersom endast autentiserade klienter kan göra det påverkar inte flera begäranden av dessa token den övergripande säkerheten.

Se Bevilja begränsad åtkomst till Azure Storage resurser med hjälp av signaturer för delad åtkomst (SAS) för en detaljerad diskussion om SAS-token. Mer information om SAS-token för användardelegering finns i Skapa en SAS för användardelegering.

API Management

Förutom att begränsa åtkomsten till resurser med hjälp av SAS-token ger den här referensarkitekturen ett annat säkerhetslager med hjälp av API Management. Klienter måste autentisera med hjälp av API Management innan de begär SAS-token. API Management har inbyggda åtkomstkontroller för REST API. Vi rekommenderar detta extra säkerhetslager eftersom överladdade data kan innehålla känslig information.

När flera klienter laddar upp filer parallellt API Management:

Att tänka på om återhämtning

Om det finns ett mycket stort antal händelser kan Event Grid kan misslyckas med att utlösa funktionen. Sådana missade händelser läggs vanligtvis till i en container med dead letter. Överväg att göra arkitekturen mer motståndskraftig genom att lägga till en övervakarfunktion. Den här funktionen kan regelbundet aktiveras på en timerutlösare. Den kan sedan hitta och bearbeta missade händelser, antingen från containern dead letter eller genom att jämföra blobarna i uppladdnings- och transkriberingscontainrarna.

Det här mönstret liknar mönstret för Scheduler-agentövervakaren. Det här mönstret implementeras inte i den här referensarkitekturen för enkelhetens skull. Mer information om hur Event Grid hanterar fel finns i Event Grid för leverans av meddelanden och återförsök.

Ett annat sätt att förbättra återhämtningen är att använda Azure Service Bus i stället för Event Grid. Den här modellen bearbetar filöverföringar sekventiellt. Klienten signalerar Service Bus när uppladdningen är klar. Service Bus sedan funktionen för att transkribera den uppladdade filen. Den här modellen är mer tillförlitlig. Det kommer dock att ha mindre dataflöde än en händelsebaserad arkitektur. Överväg noga vilken arkitektur som gäller för ditt scenario och program.

Lösningsdistribution

Information om hur du distribuerar referensimplementering för den här arkitekturen finns i GitHub readme.

Nästa steg

Granska viktig produktdokumentation som används i den här arkitekturen:

Microsoft Learn moduler: