Kunskapsarkivet "projektioner" i Azure AI Search
Projektioner definierar fysiska tabeller, objekt och filer i ett kunskapslager som accepterar innehåll från en Azure AI Search-pipeline för berikning. Om du skapar ett kunskapslager är det mesta av arbetet att definiera och forma projektioner.
Den här artikeln beskriver projektionsbegrepp och arbetsflöden så att du har lite bakgrund innan du börjar koda.
Projektioner definieras i Azure AI Search-kompetensuppsättningar, men slutresultatet är tabell-, objekt- och bildfilprojektionerna 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 | Förbrukning |
---|---|---|
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 formningsfärdighet eller använda infogad formning för att ange kolumner och rader. Du kan ordna innehåll i flera tabeller baserat på välbekanta 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 under indexerarens anrop för att skapa och läsa in objekt i Azure Storage med berikat innehåll. Om du inte känner till de här begreppen börjar du med AI-berikande 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 för ömsesidig exklusivitet och släktskap.
Princip | beskrivning |
---|---|
Ömsesidig exklusivitet | Varje grupp är helt isolerad från andra grupper för att stödja olika scenarier för dataformning. Om du till exempel testar olika tabellstrukturer och kombinationer placerar du 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 för alla peer-projektionsgrupper. |
Relateradhet | I en projektionsgrupp är innehåll i tabeller, objekt och filer relaterade. Kunskapsarkivet 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 fil-URL:en. |
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 tillhandahålls i Azure AI 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 som du behöver) för att stödja projektionerna i kunskapsarkivet.
Former används ofta med tabellprojektioner, där formen inte bara anger vilka rader som ska gå in i tabellen, utan även vilka kolumner som skapas (du kan också skicka en form till en objektprojektion).
Former kan vara komplexa och det är utanför omfånget att diskutera dem på djupet här, men följande exempel illustrerar kort en grundläggande form. Utdata från Shaper-färdigheten anges som källa för en tabellprojektion. I själva tabellprojektionen finns kolumner för "metadata-storage_path", "reviews_text", "reviews_title" och så vidare, enligt beskrivningen i 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 datakällan. När källdata uppdateras och indexeras om uppdateras projektionerna med resultatet av berikningen, vilket säkerställer att dina projektioner så småningom överensstämmer med data i datakällan. Projektioner lagras dock också separat 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 Azure Portal för att verifiera skapande av objekt och innehåll i Azure Storage.
Använd Power BI för datautforskning. 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 dina data från kunskapsarkivet, har 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 uteslutande för kunskapslager och inte används för att strukturera ett sökindex.
I Azure Storage hämtar du en anslutningssträng från Åtkomstnycklar och kontrollerar att kontot är StorageV2 (generell användning V2).
När du är i Azure Storage kan du bekanta dig med befintligt innehåll i containrar och tabeller så att du väljer namn som inte konfigureras 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 Azure AI Search aktiverar du cachelagring av berikning (förhandsversion) i indexeraren och kör sedan indexeraren för att köra kompetensuppsättningen och fylla i cacheminnet. Det här är en förhandsgranskningsfunktion, så se till att använda förhandsversionens REST API på indexerarens begäran. När cacheminnet har fyllts i kan du ändra projektionsdefinitioner i ett kunskapslager kostnadsfritt (så länge själva kunskaperna inte ändras).
I koden definieras alla projektioner enbart i en kompetensuppsä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-egenskap och kompetensmatris.
Under knowledgeStore anger du tabell, objekt, filprojektioner i avsnittet
projections
. Objekttyp, objektnamn och kvantitet (per antal projektioner som du definierar) bestäms i det här avsnittet.Från kunskapsmatrisen avgör du vilka kunskapsutdata som ska refereras i
source
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. Projektionens sammansättning bestäms genom former.
Om du lägger till projektioner i en befintlig kompetensuppsättning uppdaterar du kompetensuppsättningen och kör indexeraren.
Kontrollera dina resultat i Azure Storage. Vid efterföljande körningar bör du undvika att namnge kollisioner genom att ta bort objekt i Azure Storage eller ändra projektnamn i kompetensuppsättningen.
Om du använder tabellprojektioner kontrollerar du Förstå tabelltjänstens datamodell och skalbarhets- och prestandamål för Table Storage för att se till att dina datakrav ligger inom dokumenterade gränser för Table Storage.
Nästa steg
Granska syntax och exempel för varje projektionstyp.