Skapa en konversationsrobot i företagsklass

Bot Service
Cognitive Services

Den här referensarkitekturen beskriver hur du skapar en konversationsrobot i företagsklass (chattrobot) med hjälp av Azure Bot Framework.

Arkitektur

Diagram över arkitekturen

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Arkitekturen som visas här använder följande Azure-tjänster. Din egen robot kanske inte använder alla dessa tjänster eller kan innehålla ytterligare tjänster.

Robotlogik och användarupplevelse

  • Bot Framework Service (BFS). Den här tjänsten ansluter din robot till en kommunikationsapp som Cortana, Facebook Messenger eller Slack. Det underlättar kommunikationen mellan roboten och användaren.
  • Azure App Service. Robotprogramlogik finns i Azure App Service.

Robotkognition och intelligens

  • Language Understanding (LUIS). Luis är en del av Azure Cognitive Services och gör det möjligt för roboten att förstå naturligt språk genom att identifiera användar avsikter och entiteter.
  • Azure Search. Sökning är en hanterad tjänst som ger ett snabbt sökbart dokumentindex.
  • QnA Maker. QnA Maker är en molnbaserad API-tjänst som skapar ett konversationsanpassat lager för frågor och svar över dina data. Vanligtvis läses den in med halvstrukturerat innehåll, till exempel vanliga frågor och svar. Använd den för att skapa en kunskapsbas för att besvara frågor på naturligt språk.
  • Webbapp. Om din robot behöver AI-lösningar som inte tillhandahålls av en befintlig tjänst kan du implementera din egen anpassade AI och vara värd för den som en webbapp. Detta ger en webbslutpunkt som roboten kan anropa.

Datainhämtning

Roboten förlitar sig på rådata som måste matas in och förberedas. Överväg något av följande alternativ för att orkestrera den här processen:

  • Azure Data Factory. Data Factory samordnar och automatiserar dataförflyttning och datatransformering.
  • Logic Apps. Logic Apps är en serverlös plattform för att skapa arbetsflöden som integrerar program, data och tjänster. Logic Apps tillhandahåller dataanslutningsprogram för många program, inklusive Office 365.
  • Azure Functions. Du kan använda Azure Functions för att skriva anpassad serverlös kod som anropas av en utlösare, till exempel när ett dokument läggs till i Blob Storage eller Azure Cosmos DB.

Loggning och övervakning

  • Application Insights. Använd Application Insights för att logga robotens programmått för övervakning, diagnostik och analys.
  • Azure Blob Storage. Blob Storage är optimerad för lagring av enorma mängder ostrukturerade data.
  • Azure Cosmos DB. Azure Cosmos DB passar bra för lagring av halvstrukturerade loggdata, till exempel konversationer.
  • Power BI. Använd Power BI för att skapa övervakningsinstrumentpaneler för din robot.

Säkerhet och styrning

Kvalitetssäkring och förbättringar

  • Azure DevOps. Tillhandahåller många tjänster för apphantering, inklusive källkontroll, skapande, testning, distribution och projektspårning.
  • VS Code. En enkel kodredigerare för apputveckling. Du kan använda andra IDE med liknande funktioner.

Komponenter

Scenarioinformation

Varje robot är olika, men det finns några vanliga mönster, arbetsflöden och tekniker att känna till. Särskilt för en robot för att hantera företagsarbetsbelastningar finns det många designöverväganden utöver bara kärnfunktionerna.

De exempel på bästa praxis som används i den här arkitekturen är helt öppen källkod och tillgängliga på GitHub.

Potentiella användningsfall

Denna lösning är idealisk för telekommunikationsindustrin. Den här artikeln beskriver de viktigaste designaspekterna och introducerar de verktyg som behövs för att skapa en robust, säker och aktivt inlärningsrobot.

Rekommendationer

På hög nivå kan en konversationsrobot delas in i robotfunktionen ("hjärnan") och en uppsättning omgivande krav ("kroppen"). Hjärnan innehåller de domänmedvetna komponenterna, inklusive robotlogik och ML-funktioner. Andra komponenter är domänagnostiska och hanterar icke-funktionella krav som CI/CD, kvalitetssäkring och säkerhet.

Logiskt diagram över robotfunktioner

Innan vi går in på detaljerna i den här arkitekturen ska vi börja med dataflödet genom varje delkomponent i designen. Dataflödet innehåller användarinitierade och systeminitierade dataflöden.

Användarmeddelandeflöde

Autentisering. Användarna börjar med att autentisera sig själva med den mekanism som tillhandahålls av deras kommunikationskanal med roboten. Bot Framework stöder många kommunikationskanaler, inklusive Cortana, Microsoft Teams, Facebook Messenger, Kik och Slack. En lista över kanaler finns i Ansluta en robot till kanaler. När du skapar en robot med Azure Bot Service konfigureras Webbchatt-kanalen automatiskt. Med den här kanalen kan användare interagera med din robot direkt på en webbsida. Du kan också ansluta roboten till en anpassad app med hjälp av Direct Line kanalen. Användarens identitet används för att tillhandahålla rollbaserad åtkomstkontroll samt för att hantera personligt innehåll.

Användarmeddelande. När användaren har autentiserats skickar den ett meddelande till roboten. Roboten läser meddelandet och dirigerar det till en tjänst för förståelse av naturligt språk, till exempel LUIS. Det här steget hämtar avsikter (vad användaren vill göra) och entiteter (vad användaren är intresserad av). Roboten skapar sedan en fråga som den skickar till en tjänst som innehåller information, till exempel Azure Search för dokumenthämtning, QnA Maker för vanliga frågor och svar eller en anpassad kunskapsbas. Roboten använder dessa resultat för att konstruera ett svar. För att ge bästa resultat för en viss fråga kan roboten göra flera fram och tillbaka-anrop till dessa fjärrtjänster.

Svar. Nu har roboten fastställt det bästa svaret och skickar det till användaren. Om konfidenspoängen för det bäst matchade svaret är låg kan svaret vara en tvetydig fråga eller en bekräftelse på att roboten inte kunde svara tillräckligt.

Loggning. När en användarbegäran tas emot eller ett svar skickas ska alla konversationsåtgärder loggas till ett loggningsarkiv, tillsammans med prestandamått och allmänna fel från externa tjänster. Dessa loggar är användbara senare när du diagnostiserar problem och förbättrar systemet.

Feedback. En annan bra idé är att samla in feedback från användare och nöjdhetspoäng. Som en uppföljning av robotens slutliga svar bör roboten be användaren att betygsätta sin nöjdhet med svaret. Feedback kan hjälpa dig att lösa kallstartsproblemet med förståelse av naturligt språk och kontinuerligt förbättra noggrannheten för svar.

System Dataflöde

ETL. Roboten förlitar sig på information och kunskap som extraheras från rådata av en ETL-process i serverdelen. Dessa data kan vara strukturerade (SQL Database), halvstrukturerade (CRM-system, vanliga frågor och svar) eller ostrukturerade (Word-dokument, PDF-filer, webbloggar). Ett ETL-undersystem extraherar data enligt ett fast schema. Innehållet transformeras och berikas och läses sedan in i ett mellanliggande datalager, till exempel Azure Cosmos DB eller Azure Blob Storage.

Data i det mellanliggande arkivet indexeras sedan i Azure Search för dokumenthämtning, läses in i QnA Maker för att skapa fråge- och svarspar eller läses in i en anpassad webbapp för ostrukturerad textbearbetning. Data används också för att träna en LUIS-modell för avsikts- och entitetsextrahering.

Kvalitetssäkring. Konversationsloggarna används för att diagnostisera och åtgärda buggar, ge insikt i hur roboten används och spåra övergripande prestanda. Feedbackdata är användbara för omträning av AI-modeller för att förbättra robotprestanda.

Skapa en robot

Innan du ens skriver en enda kodrad är det viktigt att skriva en funktionell specifikation så att utvecklingsteamet får en tydlig uppfattning om vad roboten förväntas göra. Specifikationen bör innehålla en ganska omfattande lista över användarindata och förväntade robotsvar i olika kunskapsdomäner. Det här levande dokumentet är en ovärderlig guide för att utveckla och testa din robot.

Mata in data

Identifiera sedan de datakällor som gör det möjligt för roboten att interagera intelligent med användare. Som tidigare nämnts kan dessa datakällor innehålla strukturerade, halvstrukturerade eller ostrukturerade datamängder. När du kommer igång är en bra metod att göra en engångskopia av data till ett centralt lager, till exempel Azure Cosmos DB eller Azure Storage. När du fortsätter bör du skapa en pipeline för automatisk datainmatning för att hålla dessa data aktuella. Alternativ för en automatiserad inmatningspipeline är Data Factory, Functions och Logic Apps. Beroende på datalager och scheman kan du använda en kombination av dessa metoder.

När du kommer igång är det rimligt att använda Azure Portal för att skapa Azure-resurser manuellt. Senare bör du fundera mer på att automatisera distributionen av dessa resurser.

Grundläggande robotlogik och UX

När du har en specifikation och vissa data är det dags att börja förverkliga roboten. Nu ska vi fokusera på den grundläggande robotlogik. Det här är koden som hanterar konversationen med användaren, inklusive routningslogiken, disambiguationslogiken och loggningen. Börja med att bekanta dig med Bot Framework, inklusive:

Det finns många alternativ för en omfattande användarupplevelse.

  • Du kan använda kort för att inkludera knappar, bilder, karuseller och menyer.
  • En robot har stöd för tal.
  • Du kan även bädda in din robot i en app eller webbplats och använda funktionerna i appen som är värd för den.

För att komma igång kan du skapa din robot online med hjälp av Azure Bot Service genom att välja från tillgängliga C# och Node.js mallar. När roboten blir mer avancerad måste du dock skapa din robot lokalt och sedan distribuera den till webben. Välj en IDE, till exempel Visual Studio eller Visual Studio Code, och ett programmeringsspråk. SDK:er är tillgängliga för följande språk:

Som utgångspunkt kan du ladda ned källkoden för roboten som du skapade med hjälp av Azure Bot Service. Du kan också hitta exempelkod, från enkla ekorobotar till mer avancerade robotar som integreras med olika AI-tjänster.

Lägga till smarts i din robot

För en enkel robot med en väldefinierad lista med kommandon kan du kanske använda en regelbaserad metod för att parsa användarindata via regex. Detta har fördelen av att vara deterministisk och begriplig. Men när din robot behöver förstå avsikter och entiteter i ett mer naturligt språkmeddelande finns det AI-tjänster som kan hjälpa dig.

  • LUIS är särskilt utformat för att förstå användar avsikter och entiteter. Du tränar den med en måttlig samling relevanta användarindata och önskade svar, och den returnerar avsikter och entiteter för en användares angivna meddelande.

  • Azure Search kan fungera tillsammans med LUIS. Med Hjälp av Search skapar du sökbara index för alla relevanta data. Roboten frågar dessa index efter de entiteter som extraherats av LUIS. Azure Search stöder också synonymer, vilket kan bredda nätet av rätt ordmappningar.

  • QnA Maker är en annan tjänst som är utformad för att returnera svar för givna frågor. Den tränas vanligtvis över halvstrukturerade data, till exempel vanliga frågor och svar.

Din robot kan använda andra AI-tjänster för att ytterligare utöka användarupplevelsen. Cognitive Services-sviten med fördefinierade AI-tjänster (som inkluderar LUIS och QnA Maker) har tjänster för vision, tal, språk, sökning och plats. Du kan snabbt lägga till funktioner som språköversättning, stavningskontroll, attitydanalys, OCR, platsmedvetenhet och innehållsmoderering. Dessa tjänster kan kopplas upp som mellanprogrammoduler i din robot för att interagera mer naturligt och intelligent med användaren.

Ett annat alternativ är att integrera din egen anpassade AI-tjänst. Den här metoden är mer komplex, men ger dig fullständig flexibilitet när det gäller maskininlärningsalgoritm, träning och modell. Du kan till exempel implementera din egen ämnesmodellering och använda algoritmer som LDA för att hitta liknande eller relevanta dokument. En bra metod är att exponera din anpassade AI-lösning som en webbtjänstslutpunkt och anropa slutpunkten från den grundläggande robotlogik. Webbtjänsten kan finnas i App Service eller i ett kluster med virtuella datorer. Azure Machine Learning tillhandahåller ett antal tjänster och bibliotek som hjälper dig att träna och distribuera dina modeller.

Kvalitetssäkring och förbättring

Loggning. Logga användarkonversationer med roboten, inklusive underliggande prestandamått och eventuella fel. Dessa loggar visar sig vara ovärderliga för felsökning av problem, förståelse av användarinteraktioner och förbättring av systemet. Olika datalager kan vara lämpliga för olika typer av loggar. Du kan till exempel överväga Application Insights för webbloggar, Azure Cosmos DB för konversationer och Azure Storage för stora nyttolaster. Se Skriva direkt till Azure Storage.

Feedback. Det är också viktigt att förstå hur nöjda användarna är med sina robotinteraktioner. Om du har en post med användarfeedback kan du använda dessa data för att fokusera ditt arbete på att förbättra vissa interaktioner och träna om AI-modellerna för bättre prestanda. Använd feedbacken för att träna om modellerna, till exempel LUIS, i systemet.

Testar. Testning av en robot omfattar enhetstester, integreringstester, regressionstester och funktionella tester. För testning rekommenderar vi att du spelar in verkliga HTTP-svar från externa tjänster, till exempel Azure Search eller QnA Maker, så att de kan spelas upp under enhetstestning utan att behöva göra riktiga nätverksanrop till externa tjänster.

Anteckning

Om du vill komma igång med utvecklingen i dessa områden kan du titta på Botbuilder Utils för JavaScript. Den här lagringsplatsen innehåller exempelverktygskod för robotar som skapats med Microsoft Bot Framework v4 och som kör Node.js. Den innehåller följande paket:

  • Azure Cosmos DB-loggningsarkiv. Visar hur du lagrar och frågar efter robotloggar i Azure Cosmos DB.
  • Application Insights-loggningsarkiv. Visar hur du lagrar och frågar efter robotloggar i Application Insights.
  • Mellanprogram för feedbackinsamling. Exempel på mellanprogram som tillhandahåller en mekanism för feedbackbegäran från robotanvändare.
  • Http Test Recorder. Registrerar HTTP-trafik från tjänster utanför roboten. Den är förbyggd med stöd för LUIS, Azure Search och QnAMaker, men tillägg är tillgängliga för att stödja alla tjänster. På så sätt kan du automatisera robottestning.

Dessa paket tillhandahålls som verktygsexempelkod och har ingen garanti för support eller uppdateringar.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillgänglighet

När du distribuerar nya funktioner eller felkorrigeringar till din robot är det bäst att använda flera distributionsmiljöer, till exempel mellanlagring och produktion. Med hjälp av distributionsfack från Azure DevOps kan du göra detta utan driftstopp. Du kan testa dina senaste uppgraderingar i mellanlagringsmiljön innan du växlar dem till produktionsmiljön. När det gäller hantering av belastning är App Service utformat för att skala upp eller ut manuellt eller automatiskt. Eftersom roboten finns i Microsoft globala datacenterinfrastrukturen utlovar App Service serviceavtal hög tillgänglighet.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Precis som med andra program kan roboten utformas för att hantera känsliga data. Begränsa därför vem som kan logga in och använda roboten. Begränsa även vilka data som kan nås baserat på användarens identitet eller roll. Använd Azure AD för identitets- och åtkomstkontroll och Key Vault för att hantera nycklar och hemligheter.

DevOps

Övervakning och rapportering

När roboten körs i produktion behöver du ett DevOps-team för att behålla den på det sättet. Övervaka systemet kontinuerligt för att säkerställa att roboten fungerar med hög prestanda. Använd loggarna som skickas till Application Insights eller Azure Cosmos DB för att skapa instrumentpaneler för övervakning, antingen med hjälp av själva Application Insights, Power BI eller en anpassad instrumentpanel för webbappar. Skicka aviseringar till DevOps-teamet om kritiska fel inträffar eller om prestandan understiger ett acceptabelt tröskelvärde.

Automatiserad resursdistribution

Själva roboten är bara en del av ett större system som förser den med de senaste data och säkerställer att den fungerar korrekt. Alla dessa andra Azure-resurser – dataorkestreringstjänster som Data Factory, lagringstjänster som Azure Cosmos DB och så vidare – måste distribueras. Azure Resource Manager tillhandahåller ett konsekvent hanteringslager som du kan komma åt via Azure Portal, PowerShell eller Azure CLI. För hastighet och konsekvens är det bäst att automatisera distributionen med någon av dessa metoder.

Kontinuerlig robotdistribution

Du kan distribuera robotlogiken direkt från din IDE eller från en kommandorad, till exempel Azure CLI. När roboten mognar är det dock bäst att använda en kontinuerlig distributionsprocess med hjälp av en CI/CD-lösning som Azure DevOps, enligt beskrivningen i artikeln Konfigurera kontinuerlig distribution. Det här är ett bra sätt att underlätta friktionen vid testning av nya funktioner och korrigeringar i din robot i en nära produktionsmiljö. Det är också en bra idé att ha flera distributionsmiljöer, vanligtvis åtminstone mellanlagring och produktion. Azure DevOps stöder den här metoden.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över grundpelare för kostnadsoptimering.

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Här följer några andra överväganden.

Robotprogram

I den här arkitekturen är den huvudsakliga kostnadsdrivare Azure App Service där robotprogramlogik finns. Välj en App Service plannivå som passar dina behov bäst. Här följer några rekommendationer:

  • Använd nivåerna Kostnadsfri och Delad (förhandsversion) i testsyfte eftersom de delade resurserna inte kan skalas ut.
  • Kör produktionsarbetsbelastningen på nivåerna Basic, Standard och Premium eftersom appen körs på dedikerade virtuella datorinstanser och har allokerat resurser som kan skalas ut. App Service planer faktureras per sekund.

Du debiteras för instanserna i App Service-planen, även när appen stoppas. Ta bort planer som du inte tänker använda på lång sikt, till exempel testdistributioner.

Mer information finns i Hur mycket kostar min App Service plan?.

Datainhämtning

  • Azure Data Factory

    I den här arkitekturen automatiserar Data Factory pipelinen för datainmatning. Utforska en rad dataintegreringsfunktioner som passar dina budgetbehov, från hanterade SQL Server Integration Services för sömlös migrering av SQL Server projekt till molnet (kostnadseffektivt alternativ) till storskaliga, serverlösa datapipelines för integrering av data i alla former och storlekar.

    Ett exempel finns i Azure Data Factory – exempel på kostnadsanalys.

  • Azure Functions

    I den här referensarkitekturen debiteras Azure Functions enligt förbrukningsplanen. Du debiteras baserat på resursförbrukning per sekund och varje gång en händelse utlöser körningen av funktionen. Att bearbeta flera händelser i en enda körning eller batchar kan minska kostnaderna.

    Azure skalar den infrastruktur som krävs för att köra funktioner efter behov. När arbetsbelastningen är låg skalas infrastrukturen ned till noll utan någon associerad kostnad. När arbetsbelastningen växer använder Azure tillräckligt med kapacitet för att hantera all efterfrågan. Eftersom du betalar per faktisk användning hanterar du den exakta kostnaden för varje komponent.

Logic Apps

Prissättningen för Logic Apps fungerar enligt modellen betala per användning. Logic Apps har en prismodell där du betalar per användning. Utlösare, åtgärder och anslutningskörningar mäts varje gång en logikapp körs. Alla lyckade och misslyckade åtgärder, inklusive utlösare, betraktas som körningar.

Logikappen bearbetar till exempel 1 000 meddelanden om dagen från Azure Service Bus. Ett arbetsflöde med fem åtgärder kostar mindre än 6 USD. Mer information finns i Prissättning för Logic Apps.

Andra kostnadsöverväganden finns i avsnittet Kostnad i Microsoft Azure Well-Architected Framework.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

  • Robert Alexander | Senior Software Engineer
  • Abhinav Mithal | Huvudprogramtekniker

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Produktdokumentation:

Microsoft Utbildningsmoduler för Learn: