Dela via

Skapa ett index i Azure AI Search

  • Artikel

I den här artikeln lär du dig hur du definierar ett schema för ett sökindex och push-överför det till en söktjänst. När du skapar ett index upprättas de fysiska datastrukturerna i söktjänsten. När indexet finns läser du in indexet som en separat uppgift.

Förutsättningar

  • Skrivbehörigheter som söktjänstdeltagare eller en administratörs-API-nyckel för nyckelbaserad autentisering.

  • En förståelse för de data som du vill indexeras. Ett sökindex baseras på externt innehåll som du vill göra sökbart. Sökbart innehåll lagras som fält i ett index. Du bör ha en tydlig uppfattning om vilka källfält du vill göra sökbara, hämtningsbara, filterbara, fasettbara och sorterbara i Azure AI Search. Se schemachecklistan för vägledning.

  • Du måste också ha ett unikt fält i källdata som kan användas som dokumentnyckel (eller ID) i indexet.

  • En stabil indexplats. Det går inte att flytta ett befintligt index till en annan söktjänst. Gå tillbaka till programkraven och se till att din befintliga söktjänst (kapacitet och region) är tillräcklig för dina behov. Om du är beroende av Azure AI-tjänster eller Azure OpenAI väljer du en region som tillhandahåller alla nödvändiga resurser.

  • Slutligen har alla tjänstnivåer indexgränser för antalet objekt som du kan skapa. Om du till exempel experimenterar på den kostnadsfria nivån kan du bara ha tre index vid en viss tidpunkt. Inom själva indexet finns gränser för vektorer och indexgränser för antalet enkla och komplexa fält.

Dokumentnycklar

Skapande av sökindex har två krav: ett index måste ha ett unikt namn på söktjänsten och måste ha en dokumentnyckel. Det booleska key attributet i ett fält kan anges till true för att ange vilket fält som innehåller dokumentnyckeln.

En dokumentnyckel är den unika identifieraren för ett sökdokument och ett sökdokument är en samling fält som helt beskriver något. Om du till exempel indexerar en datauppsättning för filmer innehåller ett sökdokument rubriken, genren och varaktigheten för en enda film. Filmnamn är unika i den här datamängden, så du kan använda filmnamnet som dokumentnyckel.

I Azure AI Search är en dokumentnyckel en sträng och måste komma från unika värden i datakällan som tillhandahåller det innehåll som ska indexeras. Som en allmän regel genererar en söktjänst inte nyckelvärden, men i vissa scenarier (till exempel Azure-tabellindexeraren) syntetiserar den befintliga värden för att skapa en unik nyckel för de dokument som indexeras. Ett annat scenario är en-till-många-indexering för segmenterade eller partitionerade data, i vilket fall dokumentnycklar genereras för varje segment.

Under inkrementell indexering, där nytt och uppdaterat innehåll indexeras, läggs inkommande dokument med nya nycklar till, medan inkommande dokument med befintliga nycklar antingen sammanfogas eller skrivs över, beroende på om indexfälten är null eller ifyllda.

Viktiga punkter om dokumentnycklar är:

  • Den maximala längden på värden i ett nyckelfält är 1 024 tecken.
  • Exakt ett fält på den översta nivån i varje index måste väljas som nyckelfält och det måste vara av typen Edm.String.
  • Standardvärdet för key attributet är falskt för enkla fält och null för komplexa fält.

Nyckelfält kan användas för att söka efter dokument direkt och uppdatera eller ta bort specifika dokument. Värdena för nyckelfält hanteras på ett skiftlägeskänsligt sätt när du letar upp eller indexerar dokument. Mer information finns i GET Document (REST) och Index Documents (REST).

Schemachecklista

Använd den här checklistan för att underlätta besluten om utformningen av ditt sökindex.

  1. Granska namngivningskonventionerna så att index- och fältnamn överensstämmer med namngivningsreglerna.

  2. Granska Datatyper som stöds. Datatypen påverkar hur fältet används. Numeriskt innehåll kan till exempel filtreras men kan inte sökas i fulltext. Den vanligaste datatypen är Edm.String sökbar text, som tokeniseras och efterfrågas med hjälp av sökmotorn för fulltext. Den vanligaste datatypen för ett vektorfält är Edm.Single men du kan även använda andra typer.

  3. Identifiera en dokumentnyckel. En dokumentnyckel är ett indexkrav. Det är ett enda strängfält som fylls i från ett källdatafält som innehåller unika värden. Om du till exempel indexerar från Blob Storage används ofta metadatalagringssökvägen som dokumentnyckel eftersom den unikt identifierar varje blob i containern.

  4. Identifiera fälten i datakällan som bidrar med sökbart innehåll i indexet.

    Sökbart icke-innehåll innehåller korta eller långa strängar som efterfrågas med hjälp av sökmotorn för fulltext. Om innehållet är utförligt (små fraser eller större segment) experimenterar du med olika analysverktyg för att se hur texten tokeniseras.

    Sökbart vektorinnehåll kan vara bilder eller text (på valfritt språk) som finns som en matematisk representation. Du kan använda smala datatyper eller vektorkomprimering för att göra vektorfält mindre.

    Attribut som anges för fält, till exempel retrievable eller filterable, avgör både sökbeteenden och den fysiska representationen av ditt index i söktjänsten. Att avgöra hur fält ska tillskrivas är en iterativ process för många utvecklare. För att påskynda iterationer börjar du med exempeldata så att du enkelt kan släppa och återskapa dem.

  5. Identifiera vilka källfält som kan användas som filter. Numeriskt innehåll och korta textfält, särskilt de med upprepade värden, är bra alternativ. Kom ihåg följande när du arbetar med filter:

    • Filter kan användas i vektor- och icke-bevektorfrågor, men själva filtret tillämpas på fält som kan läsas av människor (icke-vektor) i ditt index.

    • Filterbara fält kan också användas i fasetterad navigering.

    • Filterbara fält returneras i godtycklig ordning och genomgår inte relevansbedömning, så överväg att även göra dem sorterbara.

  6. För vektorfält anger du en vektorsökningskonfiguration och de algoritmer som används för att skapa navigeringsvägar och fylla inbäddningsutrymmet. Mer information finns i Lägg till vektorfält.

    Vektorfält har extra egenskaper som icke-bevektorfält inte har, till exempel vilka algoritmer som ska användas och vektorkomprimering.

    Vektorfält utelämnar attribut som inte är användbara för vektordata, till exempel sortering, filtrering och fasettering.

  7. För icke-bevektorfält avgör du om du vill använda standardanalysatorn ("analyzer": null) eller en annan analysator. Analysverktyg används för att tokenisera textfält under indexering och frågekörning.

    För flerspråkiga strängar bör du överväga ett språkanalysverktyg.

    För avstavade strängar eller specialtecken bör du överväga specialiserade analysverktyg. Ett exempel är nyckelord som behandlar hela innehållet i ett fält som en enda token. Det här beteendet är användbart för data som postnummer, ID:t och vissa produktnamn. Mer information finns i Partiell termsökning och mönster med specialtecken.

Kommentar

Fulltextsökning utförs över termer som tokeniseras under indexering. Om dina frågor inte returnerar de resultat du förväntar dig testar du för tokenisering för att verifiera att strängen som du söker efter faktiskt finns. Du kan prova olika analysverktyg på strängar för att se hur token skapas för olika analysverktyg.

Konfigurera fältdefinitioner

Fältsamlingen definierar strukturen för ett sökdokument. Alla fält har namn, datatyp och attribut.

Att ange ett fält som sökbart, filterbart, sorterbart eller fasettbart påverkar indexstorleken och frågeprestandan. Ange inte attributen för fält som inte är avsedda att refereras i frågeuttryck.

Om ett fält inte är inställt på att vara sökbart, filterbart, sorterbart eller fasettbart kan fältet inte refereras till i något frågeuttryck. Detta är önskvärt för fält som inte används i frågor, men som behövs i sökresultaten.

REST-API:erna har standardattribution baserat på datatyper, som också används av importguiderna i Azure Portal. Azure SDK:er har inte standardvärden, men de har fältunderklasser som innehåller egenskaper och beteenden, till exempel SearchableField för strängar och SimpleField för primitiver.

Standardfältsatkretioner för REST-API:erna sammanfattas i följande tabell.

Datatyp Sökbart Hämtningsbart Filtrerbar Fasettbar Sorterbar Lagrat
Edm.String ✅ ✅ ✅ ✅ ✅ ✅
Collection(Edm.String) ✅ ✅ ✅ ✅ ❌ ✅
Edm.Boolean ❌ ✅ ✅ ✅ ✅ ✅
Edm.Int32, , Edm.Int64Edm.Double ❌ ✅ ✅ ✅ ✅ ✅
Edm.DateTimeOffset ❌ ✅ ✅ ✅ ✅ ✅
Edm.GeographyPoint ✅ ✅ ✅ ❌ ✅ ✅
Edm.ComplexType ✅ ✅ ✅ ✅ ✅ ✅
Collection(Edm.Single) och alla andra typer av vektorfält ✅ ✅ eller ❌ ❌ ❌ ❌ ✅

Strängfält kan också associeras med analysverktyg och synonymkartor. Fält av typen Edm.String som är filterbara, sorterbara eller fasettbara kan vara högst 32 kilobyte långa. Det beror på att värden för sådana fält behandlas som en enda sökterm och att den maximala längden på en term i Azure AI Search är 32 kilobyte. Om du behöver lagra mer text än så i ett enda strängfält bör du uttryckligen ange filtreringsbar, sorterbar och facetable till false i indexdefinitionen.

Vektorfält måste associeras med dimensioner och vektorprofiler. Hämtningsbar standard är sant om du lägger till vektorfältet med hjälp av guiden Importera och vektorisera i Azure Portal, annars är det falskt om du använder REST-API:et.

Fältattribut beskrivs i följande tabell.

Attribut Beskrivning
name Obligatoriska. Anger namnet på fältet, som måste vara unikt i fältsamlingen för indexet eller det överordnade fältet.
type Obligatoriska. Anger datatypen för fältet. Fält kan vara enkla eller komplexa. Enkla fält är av primitiva typer, t.ex Edm.String . för text eller Edm.Int32 heltal. Komplexa fält kan ha underfält som själva är enkla eller komplexa. På så sätt kan du modellera objekt och matriser med objekt, vilket i sin tur gör att du kan ladda upp de flesta JSON-objektstrukturer till ditt index. Se Datatyper som stöds för en fullständig lista över typer som stöds.
key Obligatoriskt. Ange det här attributet till true för att ange att ett fälts värden unikt identifierar dokument i indexet. Mer information finns i Dokumentnycklar i den här artikeln.
hämtningsbart Anger om fältet kan returneras i ett sökresultat. Ange det här attributet till false om du vill använda ett fält som filter, sortering eller bedömningsmekanism men inte vill att fältet ska vara synligt för slutanvändaren. Det här attributet måste vara true för nyckelfält och det måste vara null för komplexa fält. Det här attributet kan ändras i befintliga fält. Om du anger hämtningsbar till true ökar inte kraven på indexlagring. Standardvärdet är true för enkla fält och null för komplexa fält.
sökbart Anger om fältet är sökbart i fulltext och kan refereras till i sökfrågor. Det innebär att den genomgår lexikal analys , till exempel ordbrytning under indexering. Om du anger ett sökbart fält till ett värde som "Sunny day" normaliseras det internt till de enskilda tokens "sunny" och "day". Detta möjliggör fulltextsökningar för dessa termer. Fält av typen Edm.String eller Collection(Edm.String) är sökbara som standard. Det här attributet måste vara false för enkla fält med andra datatyper som inte är datatyper, och det måste vara null för komplexa fält.

Ett sökbart fält förbrukar extra utrymme i ditt index eftersom Azure AI Search bearbetar innehållet i dessa fält och organiserar dem i hjälpdatastrukturer för att utföra sökning. Om du vill spara utrymme i indexet och du inte behöver ett fält som ska inkluderas i sökningar anger du sökbart till false. Mer information finns i Så här fungerar fulltextsökning i Azure AI Search .
filtrerbart Anger om fältet ska refereras till i $filter frågor. Filterable skiljer sig från sökbara i hur strängar hanteras. Fält av typen Edm.String eller Collection(Edm.String) som är filterbara genomgår inte lexikal analys, så jämförelser är endast för exakta matchningar. Om du till exempel anger ett sådant fält f till "Solig dag" $filter=f eq 'sunny' hittar du inga matchningar, men $filter=f eq 'Sunny day' kommer att göra det. Det här attributet måste vara null för komplexa fält. Standardvärdet är true för enkla fält och null för komplexa fält. Om du vill minska indexstorleken anger du det här attributet till false på fält som du inte filtrerar på.
sorterbar Anger om fältet ska refereras till i $orderby uttryck. Som standard sorterar Azure AI Search resultat efter poäng, men i många upplevelser vill användarna sortera efter fält i dokumenten. Ett enkelt fält kan bara sorteras om det är envärdesvärde (det har ett enda värde i omfånget för det överordnade dokumentet).

Enkla samlingsfält kan inte sorteras eftersom de är flervärdesfält. Enkla underfält för komplexa samlingar är också flervärdesbaserade och kan därför inte sorteras. Detta gäller oavsett om det är ett omedelbart överordnat fält eller ett överordnat fält, som är den komplexa samlingen. Komplexa fält kan inte sorteras och det sorterbara attributet måste vara null för sådana fält. Standardvärdet för sorterbar är true för enkla enkla fält med enkel värde, false för enkla fält med flera värden och null för komplexa fält.
fasettbart Anger om fältet ska refereras till i fasetterade frågor. Används vanligtvis i en presentation av sökresultat som inkluderar antal träffar per kategori (till exempel söka efter digitalkameror och se träffar efter varumärke, megapixlar, pris och så vidare). Det här attributet måste vara null för komplexa fält. Fält av typen Edm.GeographyPoint eller Collection(Edm.GeographyPoint) kan inte vara fasettbara. Standardvärdet är true för alla andra enkla fält. Om du vill minska indexstorleken anger du det här attributet till false på fält som du inte fasetterar på.
analyzer Anger den lexikala analysatorn för tokenisering av strängar under indexerings- och frågeåtgärder. Giltiga värden för den här egenskapen är språkanalysverktyg, inbyggda analysverktyg och anpassade analysverktyg. Standardvärdet är standard.lucene. Det här attributet kan bara användas med sökbara strängfält, och det kan inte anges tillsammans med antingen searchAnalyzer eller indexAnalyzer. När analysatorn har valts och fältet har skapats i indexet kan det inte ändras för fältet. Måste vara null för komplexa fält.
searchAnalyzer Ange den här egenskapen tillsammans med indexAnalyzer för att ange olika lexikala analysverktyg för indexering och frågor. Om du använder den här egenskapen anger du analyzer till och kontrollerar att null indexAnalyzer är inställt på ett tillåtet värde. Giltiga värden för den här egenskapen omfattar inbyggda analysverktyg och anpassade analysverktyg. Det här attributet kan endast användas med sökbara fält. Sökanalysen kan uppdateras i ett befintligt fält eftersom den endast används vid frågetillfället. Måste vara null för komplexa fält].
indexAnalyzer Ange den här egenskapen tillsammans med searchAnalyzer för att ange olika lexikala analysverktyg för indexering och frågor. Om du använder den här egenskapen anger du analyzer till och ser till null att searchAnalyzer är inställt på ett tillåtet värde. Giltiga värden för den här egenskapen omfattar inbyggda analysverktyg och anpassade analysverktyg. Det här attributet kan endast användas med sökbara fält. När indexanalysatorn har valts kan den inte ändras för fältet. Måste vara null för komplexa fält.
synonymMaps En lista över namnen på synonymkartor som ska associeras med det här fältet. Det här attributet kan endast användas med sökbara fält. För närvarande stöds endast en synonymkarta per fält. Om du tilldelar en synonymkarta till ett fält ser du till att frågetermer som riktar sig mot det fältet expanderas vid frågetillfället med hjälp av reglerna i synonymkartan. Det här attributet kan ändras i befintliga fält. Måste vara null eller en tom samling för komplexa fält.
Fält En lista över underfält om det här är ett fält av typen Edm.ComplexType eller Collection(Edm.ComplexType). Måste vara null eller tomt för enkla fält. Mer information om hur och när du ska använda underfält finns i Modellera komplexa datatyper i Azure AI Search .

Skapa ett index

När du är redo att skapa indexet använder du en sökklient som kan skicka begäran. Du kan använda Azure Portal- eller REST-API:er för tidig utveckling och koncepttestning, annars är det vanligt att använda Azure SDK:er.

Under utvecklingen planerar du frekventa ombyggnader. Eftersom fysiska strukturer skapas i tjänsten är det nödvändigt att släppa och återskapa index för många ändringar. Du kan överväga att arbeta med en delmängd av dina data för att få återskapanden att gå snabbare.

Indexdesign via Azure Portal framtvingar krav och schemaregler för specifika datatyper, till exempel att inte tillåta fulltextsökningsfunktioner i numeriska fält.

  1. Logga in på Azure-portalen.

  2. Sök efter utrymme. tjänsten Search omfattas av maximalt antal index, beroende på tjänstnivå. Se till att du har plats för ett andra index.

  3. På sidan Översikt för söktjänsten väljer du något av alternativen för att skapa ett sökindex:

    • Lägg till index, en inbäddad redigerare för att ange ett indexschema
    • Importera guider

    Guiden är ett arbetsflöde från slutpunkt till slutpunkt som skapar en indexerare, en datakälla och ett färdigt index. Den läser också in data. Om det här är mer än vad du vill använda använder du Lägg till index i stället.

Följande skärmbild visar var Lägg till index, Importera data och Importera och vektorisera data visas i kommandofältet.

Skärmbild av alternativen för att lägga till ett index.

När ett index har skapats kan du hitta det igen på sidan Index i det vänstra navigeringsfönstret.

Dricks

När du har skapat ett index i Azure Portal kan du kopiera JSON-representationen och lägga till den i programkoden.

Ange corsOptions för frågor mellan ursprung

Indexscheman innehåller ett avsnitt för att ange corsOptions. Som standard kan JavaScript på klientsidan inte anropa några API:er eftersom webbläsare förhindrar alla begäranden mellan ursprung. Om du vill tillåta korsande frågor till ditt index aktiverar du CORS (Resursdelning mellan ursprung) genom att ange attributet corsOptions . Av säkerhetsskäl stöder endast fråge-API:er CORS.

"corsOptions": {
  "allowedOrigins": [
    "*"
  ],
  "maxAgeInSeconds": 300

Följande egenskaper kan anges för CORS:

  • allowedOrigins (krävs): Det här är en lista över ursprung som har åtkomst till ditt index. JavaScript-kod som hanteras från dessa ursprung kan köra frågor mot ditt index (förutsatt att anroparen tillhandahåller en giltig nyckel eller har behörigheter). Varje ursprung är vanligtvis av formuläret protocol://<fully-qualified-domain-name>:<port> men <port> utelämnas ofta. Mer information finns i Resursdelning mellan ursprung (Wikipedia).

    Om du vill tillåta åtkomst till alla ursprung ska du inkludera * som ett enskilt objekt i matrisen allowedOrigins . Detta är inte en rekommenderad metod för produktionssökningstjänster , men det är ofta användbart för utveckling och felsökning.

  • maxAgeInSeconds (valfritt): Webbläsare använder det här värdet för att fastställa varaktigheten (i sekunder) för att cachelagras CORS-förhandssvar. Detta måste vara ett icke-negativt heltal. En längre cacheperiod ger bättre prestanda, men det förlänger den tid som en CORS-princip måste börja gälla. Om det här värdet inte anges används en standardvaraktighet på fem minuter.

Tillåtna uppdateringar för befintliga index

Skapa index skapar fysiska datastrukturer (filer och inverterade index) i söktjänsten. När indexet har skapats är din möjlighet att göra ändringar med skapa eller uppdatera index beroende på om dina ändringar ogiltigförklarar dessa fysiska strukturer. De flesta fältattribut kan inte ändras när fältet har skapats i ditt index.

För att minimera omsättning i programkod kan du skapa ett indexalias som fungerar som en stabil referens till sökindexet. I stället för att uppdatera koden med indexnamn kan du uppdatera ett indexalias så att det pekar på nyare indexversioner.

För att minimera omsättningen i designprocessen beskriver följande tabell vilka element som är fasta och flexibla i schemat. Om du ändrar ett fast element måste du återskapa ett index, medan flexibla element kan ändras när som helst utan att den fysiska implementeringen påverkas. Mer information finns i Uppdatera eller återskapa ett index.

Element Kan uppdateras?
Name Nej
Nyckel Nej
Fältnamn och typer Nej
Fältattribut (sökbara, filterbara, fasettbara, sorterbara) Nej
Fältattribut (kan hämtas) Ja
Lagrad (gäller för vektorer) Nej
Analyzer Du kan lägga till och ändra anpassade analysverktyg i indexet. När det gäller analystilldelningar i strängfält kan du bara ändra searchAnalyzer. Alla andra tilldelningar och ändringar kräver en ombyggnad.
Poängprofiler Ja
Förslag på alternativ Nej
resursdelning mellan ursprung (CORS) Ja
Kryptering Ja
Synonymkartor Ja
Semantisk konfiguration Ja

Nästa steg

Använd följande länkar för att lära dig mer om specialiserade funktioner som kan läggas till i ett index:

Använd dessa länkar för att läsa in eller uppdatera ett index: