Kunskapslager "projektioner" i Azure Cognitive Search
Projektioner är fysiska tabeller, objekt och filer i ett kunskapslager som accepterar innehåll från en Cognitive Search AI-berikningspipeline. Om du skapar ett kunskapslager är det mesta av arbetet att definiera och forma projektioner.
I den här artikeln introduceras projektionsbegrepp och arbetsflöden så att du har lite bakgrundsinformation innan du börjar koda.
Projektioner definieras i Cognitive Search kunskapsuppsättningar, men slutresultatet är tabell-, objekt- och bildfilsprojektioner i Azure Storage.
Typer av projektioner och användning
Ett kunskapslager är en logisk konstruktion som fysiskt uttrycks som en lös samling tabeller, JSON-objekt eller binära bildfiler i Azure Storage.
| Projektion | Storage | Användning |
|---|---|---|
| Tabeller | Azure Table Storage | Används för data som bäst representeras som rader och kolumner, eller när du behöver detaljerade representationer av dina data (till exempel som dataramar). Med tabellprojektioner kan du definiera en schematiserad form med hjälp av en Formarfärdighet eller använda infogad formning för att ange kolumner och rader. Du kan ordna innehåll i flera tabeller baserat på bekanta normaliseringsprinciper. Tabeller som finns i samma grupp är automatiskt relaterade. |
| Objekt | Azure Blob Storage | Används när du behöver en fullständig JSON-representation av dina data och berikanden i ett JSON-dokument. Precis som med tabellprojektioner kan endast giltiga JSON-objekt projiceras som objekt, och formning kan hjälpa dig att göra det. |
| Filer | Azure Blob Storage | Används när du behöver spara normaliserade binära bildfiler. |
Projektionsdefinition
Projektioner anges under egenskapen "knowledgeStore" för en kompetensuppsättning. Projektionsdefinitioner används vid indexeraranrop för att skapa och läsa in objekt i Azure Storage berikat innehåll. Om du inte är bekant med de här begreppen kan du börja med AI-berikning för en introduktion.
I följande exempel visas placeringen av projektioner under knowledgeStore och den grundläggande konstruktionen. Namn, typ och innehållskälla utgör en projektionsdefinition.
"knowledgeStore" : {
"storageConnectionString": "DefaultEndpointsProtocol=https;AccountName=<Acct Name>;AccountKey=<Acct Key>;",
"projections": [
{
"tables": [
{ "tableName": "ks-museums-main", "generatedKeyName": "ID", "source": "/document/tableprojection" },
{ "tableName": "ks-museumEntities", "generatedKeyName": "ID","source": "/document/tableprojection/Entities/*" }
],
"objects": [
{ "storageContainer": "ks-museums", "generatedKeyName": "ID", "source": "/document/objectprojection" }
],
"files": [ ]
}
]
Projektionsgrupper
Projektioner är en matris med komplexa samlingar, vilket innebär att du kan ange flera uppsättningar av varje typ. Det är vanligt att bara använda en projektionsgrupp, men du kan använda flera om lagringskraven omfattar stöd för olika verktyg och scenarier. Du kan till exempel använda en grupp för design och felsökning av en kompetensuppsättning, medan en andra uppsättning samlar in utdata som används för en onlineapp, med en tredje för datavetenskapsarbetsbelastningar.
Samma kunskapsuppsättningsutdata används för att fylla i alla grupper under projektioner. I följande exempel visas två.
"knowledgeStore" : {
"storageConnectionString": "DefaultEndpointsProtocol=https;AccountName=<Acct Name>;AccountKey=<Acct Key>;",
"projections": [
{
"tables": [],
"objects": [],
"files": []
},
{
"tables": [],
"objects": [],
"files": []
}
]
}
Projektionsgrupper har följande viktiga egenskaper vad gäller ömsesidig exklusivitet och relaterat.
| Princip | Beskrivning |
|---|---|
| Ömsesidig exlusivitet | Varje grupp är helt isolerad från andra grupper för att stödja olika dataformningsscenarier. Om du till exempel testar olika tabellstrukturer och kombinationer skulle du placera varje uppsättning i en annan projektionsgrupp för AB-testning. Varje grupp hämtar data från samma källa (berikande träd) men är helt isolerad från kombinationen table-object-file av alla peer-projektionsgrupper. |
| Relaterat | I en projektionsgrupp är innehåll i tabeller, objekt och filer relaterade. Kunskapslagret använder genererade nycklar som referenspunkter till en gemensam överordnad nod. Tänk dig till exempel ett scenario där du har ett dokument som innehåller bilder och text. Du kan projicera texten till tabeller och bilder till binära filer, och både tabeller och objekt har en kolumn/egenskap som innehåller filens URL. |
Projektion "källa"
Källparametern är den tredje komponenten i en projektionsdefinition. Eftersom projektioner lagrar data från en AI-berikningspipeline är källan till en projektion alltid utdata från en färdighet. Därför kan utdata vara ett enda fält (till exempel ett fält med översatt text), men ofta är det en referens till en dataform.
Dataformer kommer från din kompetensuppsättning. Bland alla inbyggda kunskaper som finns i Cognitive Search finns det en verktygsfärdighet som kallas Shaper-färdigheten som används för att skapa dataformer. Du kan inkludera Shaper-kunskaper (så många du behöver) som stöd för projektionerna i kunskapslagret.
Former används ofta med tabellprojektioner, där formen inte bara anger vilka rader som ska gå till tabellen, utan även vilka kolumner som skapas (du kan också skicka en form till en objektprojektion).
Former kan vara komplexa och det är inte omfånget att diskutera dem på djupet här, men i följande exempel visas en kort beskrivning av en grundläggande form. Utdata från Shaper-färdigheten anges som källa för en tabellprojektion. I själva tabellprojektionen blir kolumner för "metadata-storage_path", "reviews_text", "reviews_title" och så vidare, enligt formen.
{
"@odata.type": "#Microsoft.Skills.Util.ShaperSkill",
"name": "ShaperForTables",
"description": null,
"context": "/document",
"inputs": [
{
"name": "metadata_storage_path",
"source": "/document/metadata_storage_path",
"sourceContext": null,
"inputs": []
},
{
"name": "reviews_text",
"source": "/document/reviews_text"
},
{
"name": "reviews_title",
"source": "/document/reviews_title"
},
{
"name": "reviews_username",
"source": "/document/reviews_username"
},
],
"outputs": [
{
"name": "output",
"targetName": "mytableprojection"
}
]
}
Projektionslivscykel
Projektioner har en livscykel som är kopplad till källdata i din datakälla. När källdata uppdateras och indexeras om uppdateras projektionerna med resultatet av berikandet, vilket säkerställer att dina projektioner så småningom överensstämmer med data i datakällan. Projektioner lagras dock också oberoende i Azure Storage. De tas inte bort när indexeraren eller själva söktjänsten tas bort.
Använda i appar
När indexeraren har körts ansluter du till projektioner och använder data i andra appar och arbetsbelastningar.
Använd Storage Browser för att verifiera skapande av objekt och innehåll.
Använd Power BI för datagranskning. Det här verktyget fungerar bäst när data finns i Azure Table Storage. I Power BI kan du ändra data till nya tabeller som är enklare att köra frågor mot och analysera.
Använd berikade data i blobcontainer i en datavetenskapspipeline. Du kan till exempel läsa in data från blobar till en Pandas DataFrame.
Slutligen, om du behöver exportera data från kunskapslagret, Azure Data Factory anslutningsappar för att exportera data och landa dem i valfri databas.
Checklista för att komma igång
Kom ihåg att projektioner är exklusiva för kunskapslager och inte används för att strukturera ett sökindex.
I Azure Storage du en anslutningssträng från Åtkomstnycklar och kontrollerar att kontot är StorageV2 (generell användning V2).
När du Azure Storage bör du bekanta dig med befintligt innehåll i containrar och tabeller så att du väljer namn som inte är motstridiga för projektionerna. Ett kunskapslager är en lös samling tabeller och containrar. Överväg att använda en namngivningskonvention för att hålla reda på relaterade objekt.
I Cognitive Search aktiverar du cachelagring av berikning (förhandsversion) i indexeraren och kör sedan indexeraren för att köra kunskapsuppsättningen och fylla i cachen. Det här är en förhandsgranskningsfunktion, så se till att använda förhandsversionen REST API (api-version=2020-06-30-preview eller senare) på indexerarbegäran. När cachen har fyllts i kan du ändra projektionsdefinitioner i ett kunskapslager kostnadsfritt (så länge själva kompetenserna inte ändras).
I din kod definieras alla projektioner endast i en kunskapsuppsättning. Det finns inga indexeraregenskaper (till exempel fältmappningar eller utdatafältmappningar) som gäller för projektioner. Inom en kompetensuppsättningsdefinition fokuserar du på två områden: knowledgeStore-egenskaper och kompetensmatris.
Under knowledgeStore anger du tabell, objekt och filprojektioner i
projectionsavsnittet. Objekttyp, objektnamn och kvantitet (per det antal projektioner som du definierar) fastställs i det här avsnittet.Från kompetensmatrisen bestämmer du vilka kunskapsutdata som ska refereras i
sourceför varje projektion. Alla projektioner har en källa. Källan kan vara utdata från en överordnad färdighet, men är ofta utdata från en Shaper-färdighet. Sammansättningen av din projektion bestäms med hjälp av former.
Om du lägger till projektioner i en befintlig kompetensuppsättning uppdaterar du kompetensuppsättningen och kör indexeraren.
Kontrollera resultatet i Azure Storage. Undvik namngivningskollisioner i efterföljande körningar genom att ta bort objekt Azure Storage eller ändra projektnamn i kunskapsuppsättningen.
Nästa steg
Granska syntax och exempel för varje projektionstyp.