Skapa en indexerare i Azure AI Search
Den här artikeln fokuserar på de grundläggande stegen för att skapa en indexerare. Beroende på datakällan och arbetsflödet kan det krävas mer konfiguration.
Du kan använda en indexerare för att automatisera dataimport och indexering i Azure AI Search. En indexerare är ett namngivet objekt i en söktjänst som ansluter till en extern Azure-datakälla, läser data och skickar dem till en sökmotor för indexering. Om du använder indexerare minskar antalet och komplexiteten avsevärt för den kod som du behöver skriva om du använder en datakälla som stöds.
Indexerare har stöd för två arbetsflöden:
Textbaserad indexering: Extrahera strängar och metadata från textinnehåll för fulltextsökningsscenarier.
Kunskapsbaserad indexering: Använd inbyggda eller anpassade kunskaper som lägger till integrerad maskininlärning för analys över bilder och stort likgiltigt innehåll, extraherar eller härleder text och struktur. Med kunskapsbaserad indexering kan du söka efter innehåll som annars inte är lätt att söka i fulltext. Mer information finns i AI-berikande i Azure AI Search.
Förutsättningar
En datakälla som stöds och som innehåller det innehåll som du vill mata in.
En indexerares datakälla som konfigurerar en anslutning till externa data.
Ett sökindex som kan acceptera inkommande data.
Var under de maximala gränserna för din tjänstnivå. Den kostnadsfria nivån tillåter tre objekt av varje typ och 1–3 minuters indexerarebearbetning, eller 3–10 minuter om det finns en kompetensuppsättning.
Indexerarmönster
När du skapar en indexerare är definitionen ett av två mönster: textbaserad indexering eller kunskapsbaserad indexering. Mönstren är desamma, förutom att kompetensbaserad indexering har fler definitioner.
Indexerareexempel för textbaserad indexering
Textbaserad indexering för fulltextsökning är det primära användningsfallet för indexerare. För det här arbetsflödet ser en indexerare ut som i det här exemplet.
{
"name": (required) String that uniquely identifies the indexer,
"description": (optional),
"dataSourceName": (required) String indicating which existing data source to use,
"targetIndexName": (required) String indicating which existing index to use,
"parameters": {
"batchSize": null,
"maxFailedItems": 0,
"maxFailedItemsPerBatch": 0,
"base64EncodeKeys": false,
"configuration": {}
},
"fieldMappings": (optional) unless field discrepancies need resolution,
"disabled": null,
"schedule": null,
"encryptionKey": null
}
Indexerare har följande krav:
- En
name
egenskap som unikt identifierar indexeraren i indexerarsamlingen - En
dataSourceName
egenskap som pekar på ett datakällans objekt. Den anger en anslutning till externa data - En
targetIndexName
egenskap som pekar på målsökningsindexet
Andra parametrar är valfria och ändrar körningstidsbeteenden, till exempel hur många fel som ska accepteras innan hela jobbet misslyckas. Obligatoriska parametrar anges i alla indexerare och dokumenteras i REST API-referensen.
Datakällaspecifika indexerare för blobar, SQL och Azure Cosmos DB tillhandahåller extra configuration
parametrar för källspecifika beteenden. Om källan till exempel är Blob Storage kan du ange en parameter som filtrerar filnamnstillägg, till exempel:
"parameters" : { "configuration" : { "indexedFileNameExtensions" : ".pdf,.docx" } }
Om källan är Azure SQL kan du ange en tidsgränsparameter för frågor.
Fältmappningar används för att explicit mappa käll-till-mål-fält om det finns avvikelser efter namn eller typ mellan ett fält i datakällan och ett fält i sökindexet.
Som standard körs en indexerare omedelbart när du skapar den i söktjänsten. Om du inte vill att indexeraren ska köras anger du disabled
till sant när du skapar indexeraren.
Du kan också ange ett schema eller ange en krypteringsnyckel för tilläggskryptering av indexerarens definition.
Indexerareexempel för kunskapsbaserad indexering
Kunskapsbaserad indexering använder AI-berikning för att bearbeta innehåll som inte kan sökas i dess råa form. Alla ovanstående egenskaper och parametrar gäller, men följande extra egenskaper är specifika för AI-berikning: skillSetName
, cache
, outputFieldMappings
.
{
"name": (required) String that uniquely identifies the indexer,
"dataSourceName": (required) String, provides raw content that will be enriched,
"targetIndexName": (required) String, name of an existing index,
"skillsetName" : (required for AI enrichment) String, name of an existing skillset,
"cache": {
"storageConnectionString" : (required if you enable the cache) Connection string to a blob container,
"enableReprocessing": true
},
"parameters": { },
"fieldMappings": (optional) Maps fields in the underlying data source to fields in an index,
"outputFieldMappings" : (required) Maps skill outputs to fields in an index,
}
AI-berikning är ett eget ämnesområde och omfattas inte av den här artikeln. För mer information, börja med AI-berikning, Kompetensuppsättningar i Azure AI Search, Skapa en kompetensuppsättning, Mappa berikade utdatafält och Aktivera cachelagring för AI-berikande.
Förbereda externa data
Indexerare arbetar med datauppsättningar. När du kör en indexerare ansluter den till datakällan, hämtar data från containern eller mappen, och serialiserar dem eventuellt till JSON innan de skickas till sökmotorn för indexering. I det här avsnittet beskrivs kraven för inkommande data för textbaserad indexering.
Källdata | Uppgifter |
---|---|
JSON-dokument | Kontrollera att strukturen eller formen på inkommande data motsvarar schemat för ditt sökindex. De flesta sökindex är ganska platta, där fältsamlingen består av fält på samma nivå. Hierarkiska eller kapslade strukturer är dock möjliga via komplexa fält och samlingar. |
Relation | Ange data som en utplattad raduppsättning, där varje rad blir ett fullständigt eller partiellt sökdokument i indexet. Om du vill platta ut relationsdata till en raduppsättning bör du skapa en SQL-vy eller skapa en fråga som returnerar överordnade och underordnade poster på samma rad. Exempeldatauppsättningen för inbyggda hotell är till exempel en SQL-databas som har 50 poster (en för varje hotell), länkad till rumsposter i en relaterad tabell. Frågan som plattar ut kollektiva data till en raduppsättning bäddar in all rumsinformation i JSON-dokument i varje hotellpost. Den inbäddade rumsinformationen genereras av en fråga som använder en FOR JSON AUTO-sats . Du kan lära dig mer om den här tekniken i definiera en fråga som returnerar inbäddad JSON. Det här är bara ett exempel. du hittar andra metoder som ger samma resultat. |
Filer | En indexerare skapar vanligtvis ett sökdokument för varje fil, där sökdokumentet består av fält för innehåll och metadata. Beroende på filtyp kan indexeraren ibland parsa en fil i flera sökdokument. I en CSV-fil kan till exempel varje rad bli ett fristående sökdokument. |
Kom ihåg att du bara behöver hämta sökbara och filterbara data:
- Sökbara data är text
- Filterbara data är alfanumeriska
Azure AI Search kan inte söka efter binära data i något format, även om det kan extrahera och härleda textbeskrivningar av bildfiler (se AI-berikning) för att skapa sökbart innehåll. På samma sätt kan stor text delas upp och analyseras av naturliga språkmodeller för att hitta struktur eller relevant information, vilket genererar nytt innehåll som du kan lägga till i ett sökdokument.
Med tanke på att indexerare inte löser dataproblem kan andra former av datarensning eller manipulering behövas. Mer information finns i produktdokumentationen för din Azure-databasprodukt.
Förbereda en datakälla
Indexerare kräver en datakälla som anger typ, container och anslutning.
Kontrollera att du använder en typ av datakälla som stöds.
Skapa en definition för datakälla . Följande datakällor är några av de vanligaste källorna:
Om datakällan är en databas, till exempel Azure SQL eller Cosmos DB, aktiverar du ändringsspårning. Azure Storage har inbyggd ändringsspårning via
LastModified
egenskapen för varje blob, fil och tabell. Länkarna för de olika datakällorna förklarar vilka metoder för ändringsspårning som stöds av indexerare.
Förbereda ett index
Indexerare kräver också ett sökindex. Kom ihåg att indexerare skickar data till sökmotorn för indexering. Precis som indexerare har egenskaper som bestämmer körningsbeteendet har ett indexschema egenskaper som påverkar hur strängar indexeras (endast strängar analyseras och tokeniseras).
Börja med Skapa ett sökindex.
Konfigurera fältsamlingen och fältattributen.
Fält är de enda receptorerna av externt innehåll. Beroende på hur fälten tilldelas i schemat analyseras värdena för varje fält, tokeniseras eller lagras som ordagranna strängar för filter, fuzzy-sökning och typeahead-frågor.
Indexerare kan automatiskt mappa källfält till målindexfält när namnen och typerna är likvärdiga. Om ett fält inte kan mappas implicit kan du komma ihåg att du kan definiera en explicit fältmappning som talar om för indexeraren hur innehållet ska dirigeras.
Granska analystilldelningarna för varje fält. Analysverktyg kan transformera strängar. Därför kan indexerade strängar skilja sig från vad du skickade in. Du kan utvärdera effekterna av analysverktyg med hjälp av Analysera text (REST). Mer information om analysverktyg finns i Analyserare för textbearbetning.
Under indexeringen kontrollerar en indexerare endast fältnamn och typer. Det finns inget verifieringssteg som säkerställer att inkommande innehåll är korrekt för motsvarande sökfält i indexet.
Skapa en indexerare
När du är redo att skapa en indexerare på en fjärrsökningstjänst behöver du en sökklient. En sökklient kan vara Azure Portal, en REST-klient eller kod som instansierar en indexerarklient. Vi rekommenderar Azure Portal- eller REST-API:er för tidig utveckling och koncepttestning.
Logga in på Azure Portal och leta sedan upp söktjänsten.
På sidan Översikt för söktjänsten väljer du mellan två alternativ:
Guiden Importera data: Guiden är unik eftersom den skapar alla nödvändiga element. Andra metoder kräver en fördefinierad datakälla och ett index.
Lägg till indexerare: Ett visuellt redigeringsprogram för att ange en indexeraredefinition.
Köra indexeraren
Som standard körs en indexerare omedelbart när du skapar den i söktjänsten. Du kan åsidosätta det här beteendet genom att ange disabled
sant i indexerarens definition. Indexerarens körning är sanningens ögonblick där du får reda på om det finns problem med anslutningar, fältmappningar eller kompetensuppsättningskonstruktion.
Det finns flera sätt att köra en indexerare:
Kör när indexeraren skapas eller uppdateras (standard).
Kör på begäran när det inte finns några ändringar i definitionen eller före med återställning för fullständig indexering. Mer information finns i Kör eller återställ indexerare.
Schemalägg indexerarens bearbetning så att körningen anropas med jämna mellanrum.
Schemalagd körning implementeras vanligtvis när du behöver inkrementell indexering så att du kan hämta de senaste ändringarna. Därför är schemaläggning beroende av ändringsidentifiering.
Indexerare är ett av de få undersystem som gör överutgående anrop till andra Azure-resurser. När det gäller Azure-roller har indexerare inte separata identiteter. en anslutning från sökmotorn till en annan Azure-resurs görs med hjälp av en söktjänsts system- eller användartilldelade hanterade identitet . Om indexeraren ansluter till en Azure-resurs i ett virtuellt nätverk bör du skapa en delad privat länk för den anslutningen. Mer information om säkra anslutningar finns i Säkerhet i Azure AI Search.
Kontrollera resultat
Övervaka indexerarens status för att söka efter status. Lyckad körning kan fortfarande innehålla varningar och meddelanden. Se till att kontrollera både lyckade och misslyckade statusmeddelanden för mer information om jobbet.
För innehållsverifiering kör du frågor på det ifyllda indexet som returnerar hela dokument eller valda fält.
Ändringsidentifiering och internt tillstånd
Om datakällan stöder ändringsidentifiering kan en indexerare identifiera underliggande ändringar i data och bearbeta bara de nya eller uppdaterade dokumenten på varje indexerare som körs, vilket lämnar oförändrat innehåll i befintligt skick. Om indexerarens körningshistorik säger att en körning lyckades med 0/0-dokument som bearbetats innebär det att indexeraren inte hittade några nya eller ändrade rader eller blobbar i den underliggande datakällan.
Logik för ändringsidentifiering är inbyggd i dataplattformarna. Hur en indexerare stöder ändringsidentifiering varierar beroende på datakälla:
Azure Storage har inbyggd ändringsidentifiering, vilket innebär att en indexerare kan identifiera nya och uppdaterade dokument automatiskt. Blob Storage, Azure Table Storage och Azure Data Lake Storage Gen2 stämplar varje blob- eller raduppdatering med datum och tid. En indexerare använder automatiskt den här informationen för att avgöra vilka dokument som ska uppdateras i indexet. Mer information om borttagningsidentifiering finns i Ändra och ta bort identifiering med hjälp av indexerare för Azure Storage.
Molndatabastekniker tillhandahåller valfria funktioner för ändringsidentifiering på sina plattformar. För dessa datakällor är ändringsidentifiering inte automatiskt. Du måste ange i datakällans definition vilken princip som används:
Indexerare håller reda på det sista dokument som bearbetas från datakällan via ett internt högvattenmärke. Markören exponeras aldrig i API:et, men internt håller indexeraren reda på var den stoppades. När indexeringen återupptas, antingen via en schemalagd körning eller ett anrop på begäran, refererar indexeraren till högvattenmärket så att det kan fortsätta där det slutade.
Om du behöver rensa högvattenmärket för att indexera om fullständigt kan du använda Återställ indexerare. Om du vill ha mer selektiv omindexering använder du Återställ kunskaper eller Återställ dokument. Via återställnings-API:erna kan du rensa internt tillstånd och även rensa cacheminnet om du har aktiverat inkrementell berikning. Mer bakgrund och jämförelse av varje återställningsalternativ finns i Köra eller återställa indexerare, färdigheter och dokument.