Dela via

När du ska använda arbetsflödesappar för konversationsspråktolkning eller orkestrering

  • Artikel

När du skapar stora program bör du överväga om ditt användningsfall hanteras bäst av en enda konversationsapp (platt arkitektur) eller av flera appar som är orkestrerade.

Översikt över orkestrering

Arbetsflöde för orkestrering är en funktion som gör att du kan ansluta olika projekt från LUIS, förståelse för konversationsspråk och svar på anpassade frågor i ett projekt. Du kan sedan använda det här projektet för förutsägelser med hjälp av en slutpunkt. Orkestreringsprojektet gör en förutsägelse om vilket underordnat projekt som ska anropas, dirigerar automatiskt begäran och returnerar med sitt svar.

Orkestrering omfattar två steg:

  1. Förutsäga vilket underordnat projekt som ska anropas.
  2. Dirigera yttrandet till den underordnade målappen och returnera den underordnade appens svar.

Orkestreringsfördelar

  • Tydlig nedbrytning och snabbare utveckling:

    • Om ditt övergripande schema har ett stort antal domäner kan orkestreringsmetoden hjälpa till att dela upp programmet i flera underordnade appar (var och en betjänar en specifik domän). En konversationsapp för bilar kan till exempel ha en navigeringsdomän eller en mediedomän.
    • Det är enklare att utveckla varje domänapp parallellt. Personer och team med specifik domänexpertis kan arbeta med enskilda appar tillsammans och parallellt.
    • Eftersom varje domänapp är mindre blir utvecklingscykeln snabbare. Mindre domänappar tar mycket mindre tid att träna än en enda stor app.

  • Mer flexibla tröskelvärden för konfidenspoäng:

    • Eftersom separata underordnade appar betjänar varje domän är det enkelt att ange separata tröskelvärden för olika underordnade appar.

  • Förbättringar av AI-kvalitet där det är lämpligt:

    • Vissa program kräver att vissa entiteter måste vara domänbegränsade. Orkestrering gör den här uppgiften enkel att uppnå. När orkestreringsprojektet förutsäger vilken underordnad app som ska anropas anropas inte de andra underordnade apparna.

      Om din app till exempel innehåller en fördefinierad entitet Person.Name bör du överväga yttrandet "Hur gör jag för att använda ett uttag?" i samband med en fordonsfråga. I det här sammanhanget är Jack ett fordonsverktyg och bör inte identifieras som en persons namn. När du använder orkestrering kan det här yttrandet omdirigeras till en underordnad app som skapats för att besvara en sådan fråga, som inte har någon entitet Person.Name .

Orkestreringsnackdelar

  • Redundanta entiteter i underordnade appar:

    • Om du behöver en viss fördefinierad entitet som returneras i alla yttranden oavsett domän, till exempel Quantity.Number eller Geography.Location, finns det inget sätt att lägga till en entitet i orkestreringsappen (det är en modell med endast avsikt). Du skulle behöva lägga till den i alla enskilda underordnade appar.

  • Efficiency:

    • Orkestreringsappar har två modellinferenser. En för att förutsäga vilken underordnad app som ska anropas och en annan för förutsägelsen i den underordnade appen. Slutsatsdragningstider är vanligtvis långsammare än enskilda appar med en platt arkitektur.

  • Träna/testa delning för orchestrator:

    • När du tränar en orkestreringsapp kan du inte dela upp data i detalj mellan test- och träningsuppsättningarna. Du kan till exempel inte träna en 90–10-delning för underordnad app A och sedan träna en delning på 80–20 för underordnad app B. Den här begränsningen kan vara mindre, men det är värt att tänka på.

Översikt över platt arkitektur

Platt arkitektur är den andra metoden för att utveckla konversationsappar. I stället för att använda en orkestreringsapp för att skicka yttranden till en av flera underordnade appar utvecklar du en enskild (eller platt) app för att hantera yttranden.

Platta arkitekturfördelar

  • Enkelhet:

    • För små appar eller domäner kan orkestreringsmetoden vara alltför komplex.
    • Eftersom alla avsikter och entiteter är på samma appnivå kan det vara enklare att göra ändringar i dem alla tillsammans.

  • Det är enklare att lägga till entiteter som alltid ska returneras:

    • Om du vill att vissa fördefinierade entiteter eller listentiteter ska returneras för alla yttranden behöver du bara lägga till dem tillsammans med andra entiteter i en enda app. Om du använder orkestrering, som nämnts, måste du lägga till den i varje underordnad app.

Nackdelar med platt arkitektur

  • Otymplig för stora appar:

    • För stora appar (t.ex. fler än 50 avsikter eller entiteter) kan det bli svårt att hålla reda på framväxande scheman och datauppsättningar. Den här svårigheten är uppenbar i fall där appen måste hantera flera domäner. En konversationsapp för bilar kan till exempel ha en navigeringsdomän eller en mediedomän.

  • Begränsad kontroll över entitetsmatchningar:

    • I en platt arkitektur finns det inget sätt att begränsa att entiteter endast returneras i vissa fall. När du använder orkestrering kan du tilldela dessa specifika entiteter till vissa underordnade appar.

Relaterat innehåll