Planera din QnA Maker-app

Om du vill planera din QnA Maker-app måste du förstå hur QnA Maker fungerar och interagerar med andra Azure-tjänster. Du bör också ha ett gediget grepp om 知識庫 begrepp.

Anteckning

QnA Maker-tjänsten dras tillbaka den 31 mars 2025. En nyare version av fråge- och svarsfunktionen är nu tillgänglig som en del av Azure Cognitive Service for Language. Information om funktioner för frågesvar i språktjänsten finns i frågor som besvaras. Från och med den 1 oktober 2022 kan du inte skapa nya QnA Maker-resurser. Information om hur du migrerar befintliga QnA Maker-kunskapsbaser till frågesvar finns i migreringsguiden.

Azure-resurser

Varje Azure-resurs som skapas med QnA Maker har ett specifikt syfte. Varje resurs har sitt eget syfte, gränser och prisnivå. Det är viktigt att förstå funktionen hos dessa resurser så att du kan använda den kunskapen i planeringsprocessen.

Resurs Syfte
QnA Maker-resurs Redigering och frågeförutsägelse
Cognitive Search-resurs Datalagring och sökning
Serviço de Aplicativo resurs och App Plan Service-resurs Slutpunkt för frågeförutsägelse
Application Insights-resurs Telemetri för frågeförutsägelse

Resursplanering

Den kostnadsfria nivån, F0, för varje resurs fungerar och kan ge både redigerings- och frågeförutsägelseupplevelsen. Du kan använda den här nivån för att lära dig redigering och frågeförutsägelse. När du flyttar till ett produktions- eller livescenario utvärderar du om ditt resursval.

Kunskapsbasstorlek och dataflöde

När du skapar en riktig app ska du planera tillräckliga resurser för storleken på din 知識庫 och för dina förväntade begäranden om frågeförutsägelse.

En 知識庫 storlek styrs av:

Den 知識庫 begäran om frågeförutsägelse styrs av webbappplanen och webbappen. Se rekommenderade inställningar för att planera prisnivån.

Resursdelning

Om du redan har några av dessa resurser som används kan du överväga att dela resurser. Se vilka resurser som kan delas med förståelsen att resursdelning är ett avancerat scenario.

Alla kunskapsbaser som skapats i samma QnA Maker-resurs delar samma slutpunkt för förutsägelse av testfrågor .

Förstå effekten av resursval

Korrekt resursval innebär att din 知識庫 svarar på frågeförutsägelser.

Om din 知識庫 inte fungerar korrekt är det vanligtvis ett problem med felaktig resurshantering.

Felaktigt resursval kräver undersökning för att avgöra vilken resurs som behöver ändras.

Kunskapsbaser

En 知識庫 är direkt knuten till QnA Maker-resursen. Den innehåller de QnA-par (fråga och svar) som används för att besvara begäranden om frågeförutsägelse.

Språköverväganden

Den första 知識庫 som skapats på QnA Maker-resursen anger resursens språk. Du kan bara ha ett språk för en QnA Maker-resurs.

Du kan strukturera dina QnA Maker-resurser efter språk eller använda Translator för att ändra en fråga från ett annat språk till 知識庫 språk innan du skickar frågan till frågeförutsägelseslutpunkten.

Mata in datakällor

Du kan använda någon av följande inmatade datakällor för att skapa en 知識庫:

  • Offentlig URL
  • Privat SharePoint-URL
  • Fil

Inmatningsprocessen konverterar innehållstyper som stöds till markdown. All ytterligare redigering av svaret görs med markdown. När du har skapat en 知識庫 kan du redigera QnA-par i QnA Maker-portalen med RTF-redigering.

Överväganden för dataformat

Eftersom det slutliga formatet för ett QnA-par är markdown är det viktigt att förstå markdown-stöd.

Länkade bilder måste vara tillgängliga från en offentlig URL som ska visas i testfönstret i QnA Maker-portalen eller i ett klientprogram. QnA Maker tillhandahåller inte autentisering för innehåll, inklusive bilder.

Robotpersonlighet

Lägg till en robotpersonlighet i 知識庫 med chit-chat. Denna personlighet kommer igenom med svar som tillhandahålls i en viss konversationston som professionell och vänlig. Denna chit-chat tillhandahålls som en konversationsuppsättning, som du har total kontroll över att lägga till, redigera och ta bort.

En robotpersonlighet rekommenderas om roboten ansluter till din 知識庫. Du kan välja att använda chit-chat i din 知識庫 även om du även ansluter till andra tjänster, men du bör granska hur robottjänsten interagerar för att veta om det är rätt arkitekturdesign för din användning.

Konversationsflöde med en 知識庫

Konversationsflödet börjar vanligtvis med en hälsning från en användare, till exempel Hi eller Hello. Din 知識庫 kan svara med ett allmänt svar, till exempel Hi, how can I help you, och det kan också ge ett urval av uppföljningsprompter för att fortsätta konversationen.

Du bör utforma konversationsflödet med en loop i åtanke så att en användare vet hur du använder din robot och inte överges av roboten i konversationen. Uppföljningsprompter tillhandahåller länkning mellan QnA-par, vilket möjliggör konversationsflödet.

Redigering med medarbetare

Medarbetare kan vara andra utvecklare som delar hela utvecklingsstacken för 知識庫-programmet eller kan begränsas till att bara redigera 知識庫.

Kunskapsbasredigering stöder flera rollbaserade åtkomstbehörigheter som du tillämpar i Azure-Portal för att begränsa omfattningen av en medarbetares förmågor.

Integrering med klientprogram

Integrering med klientprogram utförs genom att skicka en fråga till slutpunkten för förutsägelsekörning. En fråga skickas till din specifika 知識庫 med en SDK eller REST-baserad begäran till QnA Maker-webbappens slutpunkt.

Om du vill autentisera en klientbegäran korrekt måste klientprogrammet skicka rätt autentiseringsuppgifter och 知識庫-ID. Om du använder en Azure-Служба Bot konfigurerar du de här inställningarna som en del av robotkonfigurationen i Azure-Portal.

Konversationsflöde i ett klientprogram

Konversationsflöde i ett klientprogram, till exempel en Azure-robot, kan kräva funktioner före och efter interaktion med 知識庫.

Stöder klientprogrammet konversationsflödet, antingen genom att tillhandahålla alternativa sätt att hantera uppföljningsprompter eller genom att inkludera chit-chit? I så fall utformar du dessa tidigt och kontrollerar att klientprogramfrågan hanteras korrekt av en annan tjänst eller när den skickas till din 知識庫.

Dispatch mellan QnA Maker och Language Understanding (LUIS)

Ett klientprogram kan tillhandahålla flera funktioner, varav endast en besvaras av en 知識庫. Andra funktioner behöver fortfarande förstå konversationstexten och extrahera innebörden från den.

En vanlig klientprogramarkitektur är att använda både QnA Maker och Language Understanding (LUIS) tillsammans. LUIS tillhandahåller textklassificering och extrahering för alla frågor, inklusive till andra tjänster. QnA Maker ger svar från din 知識庫.

I ett sådant scenario med delad arkitektur utförs sändningen mellan de två tjänsterna av dispatch-verktyget från Bot Framework.

Aktiv inlärning från ett klientprogram

QnA Maker använder aktiv inlärning för att förbättra din 知識庫 genom att föreslå alternativa frågor till ett svar. Klientprogrammet ansvarar för en del av den här aktiva inlärningen. Via konversationsanvisningarna kan klientprogrammet avgöra att 知識庫 returnerade ett svar som inte är användbart för användaren och det kan avgöra ett bättre svar. Klientprogrammet måste skicka tillbaka informationen till 知識庫 för att förbättra förutsägelsekvaliteten.

Ange ett standardsvar

Om 知識庫 inte hittar något svar returneras standardsvaret. Det här svaret kan konfigureras på sidan Inställningar i QnA Maker-portalen eller i API:erna.

Det här standardsvaret skiljer sig från standardsvaret för Azure-roboten. Du konfigurerar standardsvaret för din Azure-robot i Azure-Portal som en del av konfigurationsinställningarna. Den returneras när tröskelvärdet för poäng inte uppfylls.

Förutsägelse

Förutsägelsen är svaret från din 知識庫 och innehåller mer information än bara svaret. Om du vill få ett svar på frågeförutsägelse använder du GenerateAnswer-API:et.

Förutsägelsepoängfluktuationer

En poäng kan ändras baserat på flera faktorer:

  • Antal svar som du begärde som svar på GenerateAnswer med top egenskapen
  • Olika tillgängliga alternativa frågor
  • Filtrering för metadata
  • Fråga som skickas till test eller production 知識庫

Det finns en svarsrankning i två faser:

  • Cognitive Search – första rangordningen. Ange det antal svar som tillåts tillräckligt högt för att de bästa svaren ska returneras av Cognitive Search och sedan skickas till QnA Maker-rankaren.
  • QnA Maker – andra rangordningen. Använd funktionalisering och maskininlärning för att fastställa bästa svar.

Tjänstuppdateringar

Använd de senaste körningsuppdateringarna för att automatiskt hantera tjänstuppdateringar.

Skalning, dataflöde och återhämtning

Skalning, dataflöde och återhämtning bestäms av Azure-resurserna, deras prisnivåer och eventuell omgivande arkitektur, till exempel Traffic Manager.

Analys med Application Insights

Alla frågor till din 知識庫 lagras i Application Insights. Använd våra viktigaste frågor för att förstå dina mått.

Utvecklingscykel

Utvecklingslivscykeln för en 知識庫 pågår: redigering, testning och publicering av 知識庫.

Kunskapsbasutveckling av QnA Maker-par

Dina QnA-par bör utformas och utvecklas baserat på klientprogramanvändningen.

Varje par kan innehålla:

  • Metadata – kan filtreras vid frågor så att du kan tagga dina QnA-par med ytterligare information om källan, innehållet, formatet och syftet med dina data.
  • Uppföljningsprompter – hjälper till att fastställa en sökväg via din 知識庫 så att användaren får rätt svar.
  • Alternativa frågor – viktigt att tillåta att sökningen matchar ditt svar från olika former av frågan. Aktiva inlärningsförslag omvandlas till alternativa frågor.

Utveckling av DevOps

Att utveckla en 知識庫 för att infoga i en DevOps-pipeline kräver att 知識庫 är isolerad under batchtestning.

En 知識庫 delar Cognitive Search-indexet med alla andra kunskapsbaser på QnA Maker-resursen. Även om 知識庫 är isolerad efter partition kan delning av indexet orsaka en skillnad i poängen jämfört med den publicerade 知識庫.

Om du vill ha samma poäng på kunskapsbaserna test och production isolerar du en QnA Maker-resurs till en enda 知識庫. I den här arkitekturen behöver resursen bara leva så länge som det isolerade batchtestet.

Nästa steg