Indexering av filinnehåll och metadata med hjälp av Azure AI Search

Den här artikeln visar hur du skapar en söktjänst som gör det möjligt för användare att söka efter dokument baserat på dokumentinnehåll utöver metadata som är associerade med dokumentet.

Du kan implementera den här tjänsten med hjälp av flera indexerare i Azure AI Search.

Den här artikeln använder en exempelarbetsbelastning för att visa hur du skapar ett enda sökindex som baseras på dokument i Azure Blob Storage. Filmetadata lagras i Azure Table Storage.

Arkitektur

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

Dataflöde

1. Dokument lagras i Blob Storage, eventuellt tillsammans med en begränsad mängd metadata (till exempel dokumentets författare).
2. Ytterligare metadata lagras i Table Storage, som kan lagra betydligt mer information för varje dokument.
3. En indexerare läser innehållet i varje fil, tillsammans med eventuella blobmetadata, och lagrar data i sökindexet.
4. En annan indexerare läser ytterligare metadata från tabellen och lagrar den i samma sökindex.
5. En sökfråga skickas till söktjänsten. Frågan returnerar matchande dokument, baserat på både dokumentinnehåll och dokumentmetadata.

Komponenter

• Blob Storage tillhandahåller kostnadseffektiv molnlagring för fildata, inklusive data i format som PDF, HTML och CSV och i Microsoft 365-dokument.
• Table Storage tillhandahåller lagring för icke-relationella strukturerade data. I det här scenariot används den för att lagra metadata för varje dokument.
• Azure AI Search är en fullständigt hanterad söktjänst som tillhandahåller infrastruktur, API:er och verktyg för att skapa en omfattande sökupplevelse.

Alternativ

I det här scenariot används indexerare i Azure AI Search för att automatiskt identifiera nytt innehåll i datakällor som stöds, till exempel blob- och tabelllagring, och sedan lägga till det i sökindexet. Du kan också använda API:erna som tillhandahålls av Azure AI Search för att skicka data till sökindexet. Om du gör det måste du dock skriva kod för att skicka data till sökindexet och även parsa och extrahera text från de binära dokument som du vill söka i. Blob Storage-indexeraren stöder många dokumentformat, vilket avsevärt förenklar processen för extrahering och indexering av text.

Om du använder indexerare kan du också utöka data som en del av en indexeringspipeline. Du kan till exempel använda Azure AI-tjänster för att utföra optisk teckenigenkänning (OCR) eller visuell analys av bilderna i dokument, identifiera språket i dokument eller översätta dokument. Du kan också definiera dina egna anpassade kunskaper för att utöka data på sätt som är relevanta för ditt affärsscenario.

Den här arkitekturen använder blob- och tabelllagring eftersom de är kostnadseffektiva och effektiva. Den här designen möjliggör också kombinerad lagring av dokument och metadata i ett enda lagringskonto. Alternativa datakällor som stöds för själva dokumenten är Azure Data Lake Storage och Azure Files. Dokumentmetadata kan lagras i alla andra datakällor som stöds och som innehåller strukturerade data, till exempel Azure SQL Database och Azure Cosmos DB.

Information om scenario

Söka i filinnehåll

Den här lösningen gör det möjligt för användare att söka efter dokument baserat på både filinnehåll och ytterligare metadata som lagras separat för varje dokument. Förutom att söka i textinnehållet i ett dokument kanske en användare vill söka efter dokumentets författare, dokumenttypen (till exempel papper eller rapport) eller dess affärspåverkan (hög, medel eller låg).

Azure AI Search är en fullständigt hanterad söktjänst som kan skapa sökindex som innehåller den information som du vill att användarna ska kunna söka efter.

Dokumenten som genomsöks i det här scenariot lagras i Blob Storage. Därför kan du använda den inbyggda Blob Storage-indexeraren i Azure AI Search för att automatiskt extrahera text från dokumentet och lägga till innehållet i sökindexet.

Söka efter filmetadata

Om du vill inkludera ytterligare information om dokumentet kan du direkt associera metadata med blobarna, utan att använda ett separat arkiv. Den inbyggda Blob Storage-sökindexeraren kan till och med läsa dessa metadata och placera dem i sökindexet. Detta gör det möjligt för användare att söka efter metadata tillsammans med filinnehållet. Mängden metadata är dock begränsad till 8 KB per blob, så mängden information som du kan placera på varje blob är ganska liten. Du kan välja att endast lagra den mest kritiska informationen direkt på blobarna. I det här scenariot lagras endast dokumentets författare på bloben.

För att lösa den här lagringsbegränsningen kan du placera ytterligare metadata i en annan datakälla som har en indexerare som stöds, till exempel Table Storage. Du kan lägga till dokumenttypen, affärspåverkan och andra metadatavärden som separata kolumner i tabellen. Om du konfigurerar den inbyggda Table Storage-indexeraren så att den riktar in sig på samma sökindex som blobindexeraren kombineras blob- och tabelllagringsmetadata för varje dokument i sökindexet.

Använda flera datakällor för ett enda sökindex

För att säkerställa att båda indexerarna pekar på samma dokument i sökindexet är dokumentnyckeln i sökindexet inställd på en unik identifierare för filen. Den här unika identifieraren används sedan för att referera till filen i båda datakällorna. Blobindexeraren använder metadata_storage_path som standard som dokumentnyckel. Egenskapen metadata_storage_path lagrar den fullständiga URL:en för filen i Blob Storage, till exempel https://contoso.blob.core.windows.net/files/paper/Resilience in Azure.pdf. Indexeraren utför Base64-kodning på värdet för att säkerställa att det inte finns några ogiltiga tecken i dokumentnyckeln. Resultatet är en unik dokumentnyckel, till exempel aHR0cHM6...mUucGRm0.

Om du lägger till metadata_storage_path som en kolumn i Table Storage vet du exakt vilken blob som metadata i de andra kolumnerna tillhör, så att du kan använda valfritt PartitionKey värde och RowKey värde i tabellen. Du kan till exempel använda blobcontainerns namn som PartitionKey och den Base64-kodade fullständiga URL:en för bloben RowKeysom , vilket säkerställer att det inte heller finns några ogiltiga tecken i dessa nycklar .

Du kan sedan använda en fältmappning i tabellindexeraren för att mappa metadata_storage_path kolumnen (eller en annan kolumn) i Table Storage till metadata_storage_path dokumentnyckelfältet i sökindexet. Om du använder funktionen base64Encode på fältmappningen får du samma dokumentnyckel (aHR0cHM6...mUucGRm0 i det tidigare exemplet) och metadata från Table Storage läggs till i samma dokument som extraherades från Blob Storage.

Du kan också mappa RowKey (som är inställd på den Base64-kodade fullständiga URL:en för bloben) till metadata_storage_path dokumentnyckeln direkt, utan att lagra den separat och Base64-koda den som en del av fältmappningen. Att behålla den okodade URL:en i en separat kolumn klargör dock vilken blob den refererar till och gör att du kan välja valfri partition och radnycklar utan att påverka sökindexeraren.

Potentiella användningsfall

Det här scenariot gäller för program som kräver möjligheten att söka efter dokument baserat på deras innehåll och ytterligare metadata.

Att tänka på

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

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

Azure AI Search tillhandahåller ett serviceavtal (SLA) för läsningar (frågor) om du har minst två repliker. Det tillhandahåller ett serviceavtal (SLA) för uppdateringar (uppdatera sökindexen) om du har minst tre repliker. Du bör därför etablera minst två repliker om du vill att användarna ska kunna söka på ett tillförlitligt sätt, och tre om faktiska ändringar i indexet också måste vara åtgärder med hög tillgänglighet.

Azure Storage lagrar alltid flera kopior av dina data för att skydda dem mot planerade och oplanerade händelser. Azure Storage tillhandahåller ytterligare redundansalternativ för replikering av data mellan regioner. Dessa skydd gäller för data i blob- och tabelllagring.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Azure AI Search tillhandahåller robusta säkerhetskontroller som hjälper dig att implementera nätverkssäkerhet, autentisering och auktorisering, datahemvist och skydd samt administrativa kontroller som hjälper dig att upprätthålla säkerhet, sekretess och efterlevnad.

När det är möjligt kan du använda Microsoft Entra-autentisering för att ge åtkomst till själva söktjänsten och ansluta söktjänsten till andra Azure-resurser (till exempel blobb- och tabelllagring i det här scenariot) med hjälp av en hanterad identitet.

Du kan ansluta från söktjänsten till lagringskontot med hjälp av en privat slutpunkt. När du använder en privat slutpunkt kan indexerarna använda en privat anslutning utan att blob- och tabelllagringen måste vara tillgänglig offentligt.

Kostnadsoptimering

Kostnadsoptimering handlar om att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Information om kostnaderna för att köra det här scenariot finns i den här förkonfigurerade uppskattningen i Priskalkylatorn för Azure. Alla tjänster som beskrivs här konfigureras i den här uppskattningen. Uppskattningen är för en arbetsbelastning som har en total dokumentstorlek på 20 GB i Blob Storage och 1 GB metadata i Table Storage. Två sökenheter används för att uppfylla serviceavtalet i lässyfte, enligt beskrivningen i avsnittet Tillförlitlighet i den här artikeln. Om du vill se hur prissättningen skulle ändras för ditt specifika användningsfall ändrar du lämpliga variabler så att de matchar din förväntade användning.

Om du granskar uppskattningen kan du se att kostnaden för blob- och tabelllagring är relativt låg. Den största delen av kostnaden uppstår för Azure AI Search eftersom den utför den faktiska indexeringen och beräkningen för att köra sökfrågor.

Distribuera det här scenariot

Information om hur du distribuerar den här exempelarbetsbelastningen finns i Indexera filinnehåll och metadata i Azure AI Search. Du kan använda det här exemplet för att:

• Skapa nödvändiga Azure-tjänster.
• Ladda upp några exempeldokument till Blob Storage.
• Fyll i värdet för författarens metadata på bloben.
• Lagra metadatavärdena för dokumenttyp och affärspåverkan i Table Storage.
• Skapa de indexerare som underhåller sökindexet.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• Jelle Druyts | Huvudtekniker för kundupplevelse

Annan deltagare:

• Mick Alberts | Teknisk författare

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

Nästa steg

• Kom igång med Azure AI Search
• Öka relevansen med hjälp av semantisk sökning i Azure AI Search
• Säkerhetsfilter för att trimma resultat i Azure AI Search
• Självstudie: Index från flera datakällor med hjälp av .NET SDK

Relaterade resurser

• Välj ett sökdatalager i Azure
• Intelligent produktsökmotor för e-handel