Zoekindexen in Azure AI Search

  • Artikel

In Azure AI Search is een zoekindex uw doorzoekbare inhoud, beschikbaar voor de zoekmachine voor indexering, zoeken in volledige tekst, vectorzoekopdrachten, hybride zoekopdrachten en gefilterde query's. Een index wordt gedefinieerd door een schema en opgeslagen in de zoekservice, waarbij gegevens worden geïmporteerd als een tweede stap. Deze inhoud bestaat in uw zoekservice, afgezien van uw primaire gegevensarchieven, die nodig zijn voor de milliseconde reactietijden die worden verwacht in moderne zoektoepassingen. Met uitzondering van indexeerscenario's voor indexeerfuncties maakt de zoekservice nooit verbinding met uw brongegevens of voert deze query's uit.

Als u een zoekindex wilt maken en beheren, helpt dit artikel u de volgende punten te begrijpen:

  • Inhoud (documenten en schema)
  • Fysieke gegevensstructuur
  • Basisbewerkingen

Wilt u liever meteen hands-on zijn? Zie In plaats daarvan een zoekindex maken.

Schema van een zoekindex

In Azure AI Search bevatten indexen zoekdocumenten. Conceptueel gezien is een document één eenheid met doorzoekbare gegevens in uw index. Een detailhandelaar kan bijvoorbeeld een document voor elk product hebben, een nieuwsorganisatie kan een document voor elk artikel hebben, een reissite kan een document hebben voor elk hotel en elke bestemming, enzovoort. Deze concepten toewijzen aan meer vertrouwde database-equivalenten: een zoekindex komt overeen met een tabel en documenten zijn ongeveer gelijk aan rijen in een tabel.

De structuur van een document wordt bepaald door het indexschema, zoals wordt geïllustreerd in het volgende voorbeeld. De verzameling 'velden' is meestal het grootste deel van een index, waarbij elk veld een naam heeft, een gegevenstype heeft toegewezen en wordt toegeschreven aan toegestaan gedrag dat bepaalt hoe het wordt gebruikt.

{
  "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){ }
}

Andere elementen zijn samengevouwen voor beknoptheid, maar de volgende koppelingen bevatten details:

  • suggesties ondersteunen type-ahead-query's, zoals automatisch aanvullen.
  • scoringProfiles worden gebruikt voor het afstemmen van relevantie.
  • analyzers worden gebruikt om tekenreeksen te verwerken in tokens volgens taalkundige regels of andere kenmerken die door de analyse worden ondersteund.
  • corsOptions of Cross-Origin Remote Scripting (CORS) wordt gebruikt voor apps die aanvragen van verschillende domeinen afhandelen.
  • encryptionKey configureert dubbele versleuteling van gevoelige inhoud in de index.
  • semantisch configureert semantische herrankering in volledige tekst en hybride zoekopdrachten.
  • vectorSearch configureert vectorvelden en query's.

Velddefinities

Een zoekdocument wordt gedefinieerd door de verzameling 'velden' in de hoofdtekst van de aanvraag Index maken. U hebt velden nodig voor documentidentificatie (sleutels), het opslaan van doorzoekbare tekst en velden voor ondersteunende filters, facetten en sorteren. Mogelijk hebt u ook velden nodig voor gegevens die een gebruiker nooit ziet. U wilt bijvoorbeeld velden voor winstmarges of marketingpromoties die u in een scoreprofiel kunt gebruiken om een zoekscore te verhogen.

Als binnenkomende gegevens hiërarchisch van aard zijn, kunt u deze in een index weergeven als een complex type, dat wordt gebruikt voor geneste structuren. De ingebouwde voorbeeldgegevensset Hotels illustreert complexe typen met behulp van een Adres (bevat meerdere subvelden) met een een-op-een-relatie met elk hotel en een complexe verzameling kamers, waarbij meerdere kamers aan elk hotel zijn gekoppeld.

Veldkenmerken

Veldkenmerken bepalen hoe een veld wordt gebruikt, zoals of het wordt gebruikt bij zoeken in volledige tekst, facetnavigatie, sorteerbewerkingen enzovoort.

Tekenreeksvelden worden vaak gemarkeerd als 'doorzoekbaar' en 'ophaalbaar'. Velden die worden gebruikt om zoekresultaten te beperken, zijn 'sorteerbaar', 'filterbaar' en 'facetable'.

Kenmerk Beschrijving
"doorzoekbaar" Doorzoekbare volledige tekst of vector. Tekstvelden zijn onderworpen aan lexicale analyse, zoals woordonderbreking tijdens het indexeren. Als u een doorzoekbaar veld instelt op een waarde zoals 'zonnige dag', wordt het intern gesplitst in de afzonderlijke tokens 'zonnig' en 'dag'. Zie Hoe zoeken in de volledige tekst werkt voor meer informatie.
"filterbaar" Hier wordt naar verwezen in $filter-query's. Filterbare velden van het type Edm.String of Collection(Edm.String) ondergaan geen woordbreking, dus vergelijkingen zijn alleen voor exacte overeenkomsten. Als u een dergelijk veld bijvoorbeeld instelt op 'zonnige dag', $filter=f eq 'sunny' vindt u geen overeenkomsten, maar $filter=f eq 'sunny day' wel.
"sorteerbaar" Het systeem sorteert de resultaten standaard op score, maar u kunt het sorteren configureren op basis van velden in de documenten. Velden van het type Collection(Edm.String) kunnen niet worden 'sorteerbaar'.
"facetable" Wordt doorgaans gebruikt bij een weergave van zoekresultaten met een treffertelling per categorie (bijvoorbeeld hotels in een specifieke stad). Deze optie kan niet worden gebruikt met velden van het type Edm.GeographyPoint. Velden van het type Edm.String die kunnen worden gefilterd, 'sorteerbaar' of 'facetable' kunnen maximaal 32 kilobytes lang zijn. Zie Index maken (REST API) voor meer informatie.
"sleutel" Unieke id voor documenten binnen de index. Er moet precies één veld worden uitgekozen als sleutelveld. Dit veld moet van het type Edm.String zijn.
"ophaalbaar" Hiermee bepaalt u of het veld in een zoekresultaat kan worden geretourneerd. Dit is handig als u een veld (zoals winstmarge) wilt gebruiken als filter-, sorteer- of scoremechanisme, maar niet wilt dat het veld zichtbaar is voor de eindgebruiker. Dit kenmerk moet true zijn voor key-velden.

Hoewel u op elk gewenst moment nieuwe velden kunt toevoegen, worden bestaande velddefinities voor de hele levensduur van de index vergrendeld. Daarom gebruiken ontwikkelaars de portal doorgaans om eenvoudige indexen te maken, om ideeën uit te testen of om een instelling op te zoeken met behulp van de portalpagina's. Een frequente iteratie van een index-ontwerp is efficiënter als u een op code gebaseerde benadering hanteert, zodat u uw index eenvoudig kunt herbouwen.

Notitie

De API's die u gebruikt om een index te bouwen, hebben verschillende standaardgedragen. Voor de REST API's zijn de meeste kenmerken standaard ingeschakeld (bijvoorbeeld 'doorzoekbaar' en 'ophaalbaar' zijn waar voor tekenreeksvelden) en hoeft u ze vaak alleen in te stellen als u ze wilt uitschakelen. Voor de .NET SDK is het tegenovergestelde waar. Bij een eigenschap die u niet expliciet instelt, is het standaardinstelling om het bijbehorende zoekgedrag uit te schakelen, tenzij u deze specifiek inschakelt.

Fysieke structuur en grootte

In Azure AI Search is de fysieke structuur van een index grotendeels een interne implementatie. U kunt toegang krijgen tot het schema, de inhoud ervan opvragen, de grootte ervan bewaken en capaciteit beheren, maar de clusters zelf (indexen, shards en andere bestanden en mappen) worden intern beheerd door Microsoft.

U kunt de indexgrootte bewaken op het tabblad Indexen in Azure Portal of door een GET INDEX-aanvraag uit te geven voor uw zoekservice. U kunt ook een servicestatistiekenaanvraag indienen en de waarde van de opslaggrootte controleren.

De grootte van een index wordt bepaald door:

  • Hoeveelheid en samenstelling van uw documenten
  • Kenmerken voor afzonderlijke velden
  • Indexconfiguratie (met name of u suggesties opneemt)

Documentsamenstelling en hoeveelheid worden bepaald door wat u wilt importeren. Houd er rekening mee dat een zoekindex alleen doorzoekbare inhoud mag bevatten. Als brongegevens binaire velden bevatten, laat u deze velden weg, tenzij u AI-verrijking gebruikt om de inhoud te kraken en te analyseren om doorzoekbare tekstgegevens te maken.

Veldkenmerken bepalen gedrag. Ter ondersteuning van dit gedrag maakt het indexeringsproces de benodigde gegevensstructuren. Voor een veld van het type Edm.Stringroept 'doorzoekbaar' bijvoorbeeld zoekopdrachten in volledige tekst aan, waarmee omgekeerde indexen voor de tokenized term worden gescand. Een kenmerk 'filterbaar' of 'sorteerbaar' ondersteunt daarentegen iteratie boven ongewijzigde tekenreeksen. In het voorbeeld in de volgende sectie ziet u variaties in de indexgrootte op basis van de geselecteerde kenmerken.

Suggesties zijn constructies die ondersteuning bieden voor query's voor automatisch aanvullen of automatisch aanvullen. Als u dus een suggestie opneemt, worden met het indexeringsproces de gegevensstructuren gemaakt die nodig zijn voor exacte tekens. Suggesties worden geïmplementeerd op veldniveau, dus kies alleen de velden die redelijk zijn voor type-vooruit.

Voorbeeld waarin de opslageffecten van kenmerken en suggesties worden gedemonstreerd

In de volgende schermopname ziet u indexopslagpatronen die het gevolg zijn van verschillende combinaties van kenmerken. De index is gebaseerd op de voorbeeldindex van onroerend goed, die u eenvoudig kunt maken met behulp van de wizard Gegevens importeren en ingebouwde voorbeeldgegevens. Hoewel de indexschema's niet worden weergegeven, kunt u de kenmerken afleiden op basis van de indexnaam. De realestate doorzoekbare index heeft bijvoorbeeld het kenmerk Doorzoekbaar en niets anders, de realestate-ophaalbare index heeft het kenmerk ophalen geselecteerd en niets anders, enzovoort.

Index size based on attribute selection

Hoewel deze indexvarianten enigszins kunstmatig zijn, kunnen we ernaar verwijzen voor brede vergelijkingen van hoe kenmerken van invloed zijn op de opslag:

  • 'ophaalbaar' heeft geen invloed op de indexgrootte.
  • 'filterbaar', 'sorteerbaar', 'facetable' verbruiken meer opslagruimte.
  • de suggestiefunctie heeft een groot potentieel voor het vergroten van de indexgrootte, maar niet zo veel als in de schermopname zou worden aangegeven (alle velden die suggesties kunnen worden gemaakt, zijn geselecteerd, wat niet waarschijnlijk een scenario is in de meeste indexen).

Ook niet weerspiegeld in de vorige tabel is het effect van analysen. Als u de edgeNgram-tokenizer gebruikt om exacte tekensreeksen op te slaan (a, ab, abc, abcd), is de index groter dan wanneer u de standaardanalyse gebruikt.

Basisbewerkingen en interactie

Nu u een beter idee hebt van wat een index is, worden in deze sectie uitvoeringsbewerkingen voor indexen geïntroduceerd, waaronder het maken van verbinding met en het beveiligen van één index.

Notitie

Houd er bij het beheren van een index rekening mee dat er geen portal- of API-ondersteuning is voor het verplaatsen of kopiëren van een index. In plaats daarvan verwijzen klanten doorgaans hun toepassingsimplementatieoplossing naar een andere zoekservice (als ze dezelfde indexnaam gebruiken) of passen ze de naam aan om een kopie te maken op de huidige zoekservice en bouw deze vervolgens.

Indexisolatie

In Azure AI Search werkt u met één index tegelijk, waarbij alle indexgerelateerde bewerkingen gericht zijn op één index. Er is geen concept van gerelateerde indexen of het samenvoegen van onafhankelijke indexen voor indexering of query's.

Continu beschikbaar

Een index is onmiddellijk beschikbaar voor query's zodra het eerste document is geïndexeerd, maar is pas volledig operationeel als alle documenten zijn geïndexeerd. Intern wordt een zoekindex verdeeld over partities en uitgevoerd op replica's. De fysieke index wordt intern beheerd. De logische index wordt door u beheerd.

Een index is continu beschikbaar, zonder de mogelijkheid om deze te onderbreken of offline te halen. Omdat het is ontworpen voor continue werking, vindt elke update van de inhoud of toevoegingen aan de index zelf in realtime plaats. Als gevolg hiervan kunnen query's tijdelijk onvolledige resultaten retourneren als een aanvraag samenvalt met een documentupdate.

U ziet dat querycontinuïteit bestaat voor documentbewerkingen (vernieuwen of verwijderen) en voor wijzigingen die geen invloed hebben op de bestaande structuur en integriteit van de huidige index (zoals het toevoegen van nieuwe velden). Als u structurele updates moet uitvoeren (bestaande velden wijzigen), worden deze meestal beheerd met behulp van een werkstroom voor neerzetten en opnieuw opbouwen in een ontwikkelomgeving of door een nieuwe versie van de index in de productieservice te maken.

Om te voorkomen dat een index opnieuw wordt opgebouwd, kiezen sommige klanten die kleine wijzigingen aanbrengen ervoor om een veld 'versie' te maken door een nieuw veld te maken dat naast een eerdere versie wordt gebruikt. Na verloop van tijd leidt dit tot zwevende inhoud in de vorm van verouderde velden of verouderde aangepaste analysedefinities, met name in een productieindex die duur is om te repliceren. U kunt deze problemen oplossen bij geplande updates van de index als onderdeel van het levenscyclusbeheer van de index.

Eindpuntverbinding en -beveiliging

Alle indexerings- en queryaanvragen richten zich op een index. Eindpunten zijn meestal een van de volgende:

Eindpunt Verbinding maken ion en toegangsbeheer
<your-service>.search.windows.net/indexes Is gericht op de verzameling indexen. Wordt gebruikt bij het maken, weergeven of verwijderen van een index. Beheer rechten zijn vereist voor deze bewerkingen, beschikbaar via beheerder API-sleutels of de rol Inzender voor zoeken.
<your-service>.search.windows.net/indexes/<your-index>/docs Is gericht op het verzamelen van documenten van één index. Wordt gebruikt bij het uitvoeren van query's op een index of gegevensvernieuwing. Voor query's zijn leesrechten voldoende en beschikbaar via query-API-sleutels of een rol van gegevenslezer. Voor het vernieuwen van gegevens zijn beheerdersrechten vereist.

  1. Begin met Azure Portal. Azure-abonnees of de persoon die de zoekservice heeft gemaakt, kunnen de zoekservice beheren in Azure Portal. Voor een Azure-abonnement zijn inzender- of bovenstaande machtigingen vereist om services te maken of te verwijderen. Dit machtigingsniveau is voldoende voor het volledig beheren van een zoekservice in Azure Portal.

  2. Probeer andere clients voor programmatische toegang. We raden de quickstarts aan voor de eerste stappen:

Volgende stappen

U kunt praktijkervaring opdoen met het maken van een index met behulp van vrijwel elk voorbeeld of overzicht voor Azure AI Search. Om te beginnen kunt u een van de quickstarts uit de inhoudsopgave kiezen.

Maar u wilt ook vertrouwd raken met methodologieën voor het laden van een index met gegevens. Indexdefinitie en strategieën voor gegevensimport worden samen gedefinieerd. De volgende artikelen bevatten meer informatie over het maken en laden van een index.