Sök index i Azure AI Search
I Azure AI Search är ett sökindex ditt sökbara innehåll som är tillgängligt för sökmotorn för indexering, fulltextsökning, vektorsökning, hybridsökning och filtrerade frågor. Ett index definieras av ett schema och sparas i söktjänsten, med dataimport som följer som ett andra steg. Det här innehållet finns i söktjänsten, förutom dina primära datalager, vilket är nödvändigt för de millisekunders svarstider som förväntas i moderna sökprogram. Förutom indexeringsdrivna indexeringsscenarier ansluter söktjänsten aldrig till eller frågar dina källdata.
Om du vill skapa och hantera ett sökindex hjälper den här artikeln dig att förstå följande punkter:
- Innehåll (dokument och schema)
- Fysisk datastruktur
- Grundläggande åtgärder
Föredrar du att vara praktisk direkt? Se Skapa ett sökindex i stället.
Schema för ett sökindex
I Azure AI Search innehåller index sökdokument. Konceptuellt är ett dokument en enda enhet med sökbara data i ditt index. En återförsäljare kan till exempel ha ett dokument för varje produkt, en nyhetsorganisation kan ha ett dokument för varje artikel, en resewebbplats kan ha ett dokument för varje hotell och destination och så vidare. Mappa dessa begrepp till mer välbekanta databasekvivalenter: ett sökindex motsvarar en tabell och dokument motsvarar i stort sett rader i en tabell.
Strukturen för ett dokument bestäms av indexschemat, som illustreras i följande exempel. Samlingen "fält" är vanligtvis den största delen av ett index, där varje fält namnges, tilldelas en datatyp och tilldelas med tillåtna beteenden som avgör hur det används.
{
"name": "name_of_index, unique across the service",
"fields": [
{
"name": "name_of_field",
"type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
"searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
"filterable": true (default) | false,
"sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
"facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
"key": true | false (default, only Edm.String fields can be keys),
"retrievable": true (default) | false,
"analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
"searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
"indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
"normalizer": "name_of_normalizer", (applies to fields that are filterable)
"synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
"dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
"vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
}
],
"suggesters": [ ],
"scoringProfiles": [ ],
"analyzers":(optional)[ ... ],
"charFilters":(optional)[ ... ],
"tokenizers":(optional)[ ... ],
"tokenFilters":(optional)[ ... ],
"defaultScoringProfile": (optional) "...",
"corsOptions": (optional) { },
"encryptionKey":(optional){ },
"semantic":(optional){ },
"vectorSearch":(optional){ }
}
Andra element komprimeras för korthet, men följande länkar innehåller information:
- förslagsgivare stöder typ-framåt-frågor som automatisk komplettering.
- scoringProfiles används för relevansjustering.
- analysverktyg används för att bearbeta strängar till token enligt språkregler eller andra egenskaper som stöds av analysatorn.
- corsOptions, eller CORS (Cross-origin remote scripting), används för appar som utfärdar begäranden från olika domäner.
- encryptionKey konfigurerar dubbelkryptering av känsligt innehåll i indexet.
- semantik konfigurerar semantisk reranking i fulltext och hybridsökning.
- vectorSearch konfigurerar vektorfält och frågor.
Fältdefinitioner
Ett sökdokument definieras av samlingen "fält" i brödtexten i Begäran om att skapa index. Du behöver fält för dokumentidentifiering (nycklar), lagring av sökbar text och fält för stödfilter, fasetter och sortering. Du kan också behöva fält för data som en användare aldrig ser. Du kanske till exempel vill ha fält för vinstmarginaler eller marknadsföringskampanjer som du kan använda i en bedömningsprofil för att öka en sökpoäng.
Om inkommande data är hierarkiska kan du representera dem i ett index som en komplex typ som används för kapslade strukturer. Den inbyggda exempeldatauppsättningen Hotell illustrerar komplexa typer med hjälp av en adress (innehåller flera underfält) som har en en-till-en-relation med varje hotell och en rumskomplex samling, där flera rum är associerade med varje hotell.
Fältattribut
Fältattribut avgör hur ett fält används, till exempel om det används i fulltextsökning, fasetterad navigering, sorteringsåtgärder och så vidare.
Strängfält markeras ofta som "sökbara" och "hämtningsbara". Fält som används för att begränsa sökresultaten är "sortable", "filterable" och "facetable".
| Attribut | beskrivning |
|---|---|
| "sökbar" | Fulltext- eller vektorsökningsbar. Textfält är föremål för lexikal analys, till exempel ordbrytning under indexering. Om du anger ett sökbart fält till ett värde som "solig dag" delas det internt upp i de enskilda tokensna "sunny" och "day". Mer information finns i Hur fulltextsökning fungerar. |
| "filterbar" | Refereras till i $filter-frågor. Filterbara fält av typen Edm.String eller Collection(Edm.String) genomgår inte ordbrytning, 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. |
| "sorterbar" | Som standard sorterar systemet resultaten efter bedömning, men du kan konfigurera sortering som baseras på fält i dokumenten. Fält av typen Collection(Edm.String) kan inte vara "sorterbara". |
| "facetable" | Används vanligtvis i en presentation av sökresultat som innehåller ett antal träffar efter kategori (till exempel hotell på en viss ort). Det här alternativet kan inte användas med fält av typen Edm.GeographyPoint. Fält av typen Edm.String som är filterbara, "sorterbara" eller "facetable" kan vara högst 32 kilobyte långa. Mer information finns i Skapa index (REST-API). |
| "nyckel" | Unik identifierare för dokument i indexet. Exakt ett fält måste väljas som nyckelfält, och det måste vara av typen Edm.String. |
| "hämtningsbar" | Anger om fältet kan returneras i ett sökresultat. Detta är användbart när du vill använda ett fält (till exempel vinstmarginal) som ett 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 key-fält. |
Du kan visserligen lägga till nya fält när som helst, men befintliga fältdefinitioner är låsta under indexets hela livslängd. Av den anledningen använder många utvecklare portalen för att skapa enkla index, testa idéer och använda portalsidorna för att söka reda på en inställning. Frekvent upprepning av en indexdesign är mer effektiv om du följer en kodbaserad metod så att du enkelt kan återskapa indexet.
Kommentar
De API:er som du använder för att skapa ett index har olika standardbeteenden. För REST-API:er är de flesta attribut aktiverade som standard (till exempel "sökbara" och "hämtningsbara" är sanna för strängfält) och du behöver ofta bara ange dem om du vill inaktivera dem. För .NET SDK är motsatsen sant. På alla egenskaper som du inte uttryckligen anger är standardinställningen att inaktivera motsvarande sökbeteende om du inte specifikt aktiverar det.
Fysisk struktur och storlek
I Azure AI Search är den fysiska strukturen för ett index till stor del en intern implementering. Du kan komma åt dess schema, fråga dess innehåll, övervaka dess storlek och hantera kapacitet, men själva klustren (index, fragment och andra filer och mappar) hanteras internt av Microsoft.
Du kan övervaka indexstorleken på fliken Index i Azure-portalen eller genom att skicka en GET INDEX-begäran mot din söktjänst. Du kan också utfärda en tjänststatistikbegäran och kontrollera värdet för lagringsstorleken.
Storleken på ett index bestäms av:
- Kvantitet och sammansättning av dina dokument
- Attribut för enskilda fält
- Indexkonfiguration (specifikt om du inkluderar förslagsgivare)
Dokumentsammansättning och kvantitet bestäms av vad du väljer att importera. Kom ihåg att ett sökindex endast ska innehålla sökbart innehåll. Om källdata innehåller binära fält utelämnar du dessa fält om du inte använder AI-berikning för att knäcka och analysera innehållet för att skapa sökbar textinformation.
Fältattribut bestämmer beteenden. För att stödja dessa beteenden skapar indexeringsprocessen nödvändiga datastrukturer. För ett fält av typen Edm.Stringanropar "sökbar" till exempel fulltextsökning, som söker igenom inverterade index efter den tokeniserade termen. Däremot stöder ett "filterbart" eller "sorterbart" attribut iteration över oförändrade strängar. Exemplet i nästa avsnitt visar variationer i indexstorlek baserat på de valda attributen.
Förslagsgivare är konstruktioner som stöder frågor av typen framåt eller komplettera automatiskt. När du inkluderar en förslagsspelare skapar indexeringsprocessen därför de datastrukturer som krävs för ordagranna teckenmatchningar. Förslagsgivare implementeras på fältnivå, så välj endast de fält som är rimliga för typ-framåt.
Exempel som visar lagringskonsekvenserna av attribut och förslagsgivare
Följande skärmbild visar indexlagringsmönster som beror på olika kombinationer av attribut. Indexet baseras på exempelindexet för fastigheter, som du enkelt kan skapa med hjälp av guiden Importera data och inbyggda exempeldata. Även om indexscheman inte visas kan du härleda attributen baserat på indexnamnet. Till exempel har realestate-searchable-index attributet "sökbar" valt och inget annat, realestate-retrievable index har attributet "hämtningsbar" markerat och inget annat, och så vidare.
Även om dessa indexvarianter är något artificiella kan vi referera till dem för breda jämförelser av hur attribut påverkar lagringen:
- "hämtningsbar" har ingen effekt på indexstorleken.
- "filterable", "sortable", "facetable" förbrukar mer lagringsutrymme.
- suggester har en stor potential för att öka indexstorleken, men inte så mycket som skärmbilden skulle indikera (alla fält som kan göras suggestermedvetna har valts, vilket inte är ett troligt scenario i de flesta index).
Inte heller återspeglas i föregående tabell är effekten av analysverktyg. Om du använder edgeNgram-tokeniseraren för att lagra ordagranna teckensekvenser (a, ab, abc, abcd) är indexet större än om du använder standardanalysatorn.
Grundläggande åtgärder och interaktion
Nu när du har en bättre uppfattning om vad ett index är introducerar det här avsnittet åtgärder för indexkörning, inklusive anslutning till och skydd av ett enda index.
Kommentar
När du hanterar ett index bör du vara medveten om att det inte finns något portal- eller API-stöd för att flytta eller kopiera ett index. I stället pekar kunderna vanligtvis sin programdistributionslösning på en annan söktjänst (om de använder samma indexnamn) eller ändrar namnet för att skapa en kopia på den aktuella söktjänsten och skapar den sedan.
Indexisolering
I Azure AI Search arbetar du med ett index i taget, där alla indexrelaterade åtgärder riktar sig mot ett enda index. Det finns inget begrepp om relaterade index eller sammanfogning av oberoende index för indexering eller frågor.
Kontinuerligt tillgänglig
Ett index är omedelbart tillgängligt för frågor så snart det första dokumentet indexeras, men kommer inte att fungera fullt ut förrän alla dokument har indexerats. Internt distribueras ett sökindex mellan partitioner och körs på repliker. Det fysiska indexet hanteras internt. Det logiska indexet hanteras av dig.
Ett index är kontinuerligt tillgängligt, utan möjlighet att pausa eller ta det offline. Eftersom det är utformat för kontinuerlig drift sker alla uppdateringar av innehållet eller tillägg till själva indexet i realtid. Därför kan frågor tillfälligt returnera ofullständiga resultat om en begäran sammanfaller med en dokumentuppdatering.
Observera att frågekontinuitet finns för dokumentåtgärder (uppdatering eller borttagning) och för ändringar som inte påverkar den befintliga strukturen och integriteten för det aktuella indexet (till exempel att lägga till nya fält). Om du behöver göra strukturella uppdateringar (ändra befintliga fält) hanteras de vanligtvis med hjälp av ett drop-and-rebuild-arbetsflöde i en utvecklingsmiljö eller genom att skapa en ny version av indexet för produktionstjänsten.
För att undvika att index återskapas väljer vissa kunder som gör små ändringar att "version" ett fält genom att skapa ett nytt som samexisterar tillsammans med en tidigare version. Med tiden leder detta till överblivet innehåll i form av föråldrade fält eller föråldrade anpassade analysverktygsdefinitioner, särskilt i ett produktionsindex som är dyrt att replikera. Du kan åtgärda dessa problem vid planerade uppdateringar av indexet som en del av indexets livscykelhantering.
Slutpunktsanslutning och säkerhet
Alla indexerings- och frågebegäranden riktar sig mot ett index. Slutpunkter är vanligtvis en av följande:
| Slutpunkt | Anslut ion och åtkomstkontroll |
|---|---|
<your-service>.search.windows.net/indexes |
Riktar sig till indexsamlingen. Används när du skapar, listar eller tar bort ett index. Administratörsrättigheter krävs för dessa åtgärder, tillgängliga via administratörs-API-nycklar eller en sökdeltagareroll. |
<your-service>.search.windows.net/indexes/<your-index>/docs |
Riktar in sig på dokumentsamlingen för ett enda index. Används när du kör frågor mot ett index eller en datauppdatering. För frågor är läsbehörigheter tillräckliga och tillgängliga via fråge-API-nycklar eller en dataläsarroll. För datauppdatering krävs administratörsbehörighet. |
Så här ansluter du till Azure AI Search
Börja med Azure-portalen. Azure-prenumeranter, eller den person som skapade söktjänsten, kan hantera söktjänsten i Azure-portalen. En Azure-prenumeration kräver behörigheter som deltagare eller högre för att skapa eller ta bort tjänster. Den här behörighetsnivån är tillräcklig för att fullständigt hantera en söktjänst i Azure-portalen.
Prova andra klienter för programmatisk åtkomst. Vi rekommenderar snabbstarterna för de första stegen:
Nästa steg
Du kan få praktisk erfarenhet av att skapa ett index med nästan alla exempel eller genomgångar för Azure AI Search. Till att börja med kan du välja någon av snabbstarterna från innehållsförteckningen.
Men du vill också bekanta dig med metoder för att läsa in ett index med data. Strategier för indexdefinition och dataimport definieras tillsammans. Följande artiklar innehåller mer information om hur du skapar och läser in ett index.