Suchindizes in der Azure KI-Suche

Ein Suchindex in der Azure KI-Suche ist Ihr durchsuchbarer Inhalt, welcher der Suchmaschine für Indizierung, Volltextsuche, Vektorsuche, Hybridsuche und gefilterte Abfragen zur Verfügung steht. Ein Index wird durch ein Schema definiert und im Suchdienst gespeichert, der Datenimport folgt in einem zweiten Schritt. Dieser Inhalt ist in Ihrem Suchdienst vorhanden, abgesehen von Ihren primären Datenspeichern, was für die in modernen Suchanwendungen erwarteten Antwortzeiten von Millisekunden notwendig ist. Mit Ausnahme von indexergesteuerten Indizierungsszenarien stellt der Suchdienst niemals eine Verbindung zu Ihren Quelldaten her oder fragt diese ab.

Wenn Sie einen Suchindex erstellen und verwalten wollen, hilft Ihnen dieser Artikel, die folgenden Punkte zu verstehen:

• Inhalt (Dokumente und Schema)
• Physische Datenstruktur
• Basisvorgänge

Sie möchten am liebsten gleich selbst Hand anlegen? Siehe stattdessen Erstellen eines Suchindexes.

Schema eines Suchindexes

Indizes in Azure AI Search enthalten Suchdokumente. Konzeptionell ist ein Dokument eine einzelne Einheit mit durchsuchbaren Daten im Index. Beispielsweise könnte ein Einzelhändler ein Dokument für jedes Produkt haben, eine Universität ein Dokument für jeden Artikel, eine Reiseseite ein Dokument für jedes Hotel und jedes Reiseziel und so weiter. So lassen sich diese Konzepte vertrauteren Entsprechungen in der Datenbank zuordnen: Ein Suchindex entspricht einer Tabelle, und Dokumente entsprechen ungefähr den Zeilen einer Tabelle.

Die Struktur eines Dokuments wird durch das Indexschema bestimmt, wie im folgenden Beispiel dargestellt. Die „Feldsammlung“ ist typischerweise der größte Teil eines Index, wobei jedes Feld benannt ist, einen Datentyp hat und mit zulässigen Verhaltensweisen versehen wird, die bestimmen, wie es verwendet wird.

{
  "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 Elemente sind der Kürze halber ausgeblendet, aber die folgenden Links liefern Details:

• suggesters unterstützen Vorausabfragen wie die automatische Vervollständigung.
• scoringProfiles werden für die Relevanzabstimmung verwendet.
• analyzers werden verwendet, um Zeichenketten nach linguistischen Regeln oder anderen vom Analysator unterstützten Merkmalen in Token zu zerlegen.
• corsOptions oder CORS (Cross-Origin-Remote-Scripting) wird für Anwendungen verwendet, die Anfragen von verschiedenen Domänen aus stellen.
• encryptionKey konfiguriert die doppelte Verschlüsselung von sensiblen Inhalten im Index.
• semantic konfiguriert die semantische Neubewertung in Volltext- und Hybridsuche.
• vectorSearch konfiguriert Vektorfelder und Abfragen.

Felddefinitionen

Ein Suchdokument wird durch die Sammlung „Felder“ im Text der Anforderung zur Indexerstellung definiert. Sie benötigen Felder für die Dokumentidentifikation (Schlüssel), in denen durchsuchbarer Text gespeichert ist, und Felder zur Unterstützung von Filtern, Facetten und Sortierungen. Möglicherweise benötigen Sie auch Felder für Daten, die einem Benutzer nie angezeigt werden. Sie könnten z. B. in einem Bewertungsprofil Felder für Gewinnspannen oder Marketingaktionen verwenden, um einen Suchscore zu erhöhen.

Wenn die eingehenden Daten hierarchischer Natur sind, können sie in einem Index als komplexer Typ dargestellt werden, der für verschachtelter Strukturen verwendet wird. Das integrierte Beispieldataset „Hotels“ veranschaulicht komplexe Typen anhand einer Adresse (enthält mehrere untergeordnete Felder) mit einer 1:1-Beziehung zu den einzelnen Hotels und einer komplexen Zimmersammlung, wobei jedem Hotel mehrere Zimmer zugeordnet sind.

Feldattribute

Feldattribute bestimmen, wie ein Feld verwendet wird, z.B. ob es in der Volltextsuche, in der Facettennavigation, für Sortiervorgänge usw. verwendet wird.

Zeichenfolgenfelder werden häufig als „durchsuchbar“ und „abrufbar“ gekennzeichnet. Zu den Feldern zum Eingrenzen der Suchergebnisse gehören „sortierbar“, „filterbar“ und „facettenreich“.

Obwohl Sie jederzeit neue Felder hinzufügen können, sind vorhandene Felddefinitionen für die Lebensdauer des Index gesperrt. Aus diesem Grund verwenden Entwickler in der Regel das Portal zum Erstellen einfacher Indizes und zum Testen von Ideen. Oder sie verwenden Seiten des Portals, um eine Einstellung zu suchen. Häufige Iterationen über einen Indexentwurf sind effizienter, wenn Sie einem codebasierten Ansatz folgen, sodass Sie den Index einfach neu erstellen können.

Physische Struktur und Größe

In Azure AI Search ist die physische Struktur eines Indexes weitgehend eine interne Implementierung. Sie können auf das Schema zugreifen, seinen Inhalt abfragen, seine Größe überwachen und die Kapazität verwalten, aber die Cluster selber (invertierte Indizes und Vektorindizes, Shards sowie andere Dateien und Ordner) werden intern von Microsoft verwaltet.

Sie können die Indexgröße auf der Seite Suchverwaltung > Indizes im Azure-Portal überwachen oder eine GET INDEX-Anforderung an Ihren Suchdienst stellen. Sie können auch eine Dienststatistikanforderung stellen und den Wert der Speichergröße überprüfen.

Die Größe eines Indexes wird bestimmt durch:

• Umfang und Zusammensetzung Ihrer Dokumente
• Attribute zu einzelnen Feldern
• Indexkonfiguration (insbesondere, ob Sie Vorschlagsfunktionen einbeziehen)

Die Zusammensetzung und Menge der Dokumente hängt davon ab, was Sie importieren möchten. Denken Sie daran, dass ein Suchindex nur durchsuchbare Inhalte enthalten sollte. Wenn Quelldaten binäre Felder enthalten, lassen Sie diese Felder aus, es sei denn, Sie verwenden KI-Anreicherung, um den Inhalt zu knacken und zu analysieren, um durchsuchbare Textinformationen zu erstellen.

Feldattribute bestimmen das Verhalten. Um diese Verhaltensweisen zu unterstützen, erstellt der Indizierungsprozess die erforderlichen Datenstrukturen. Zum Beispiel ruft „searchable“ für ein Feld vom Typ Edm.String die Volltextsuche auf, die invertierte Indizes nach dem tokenisierten Begriff durchsucht. Im Gegensatz dazu unterstützt ein Attribut "filterable" oder "sortable" die Iteration über unveränderte Zeichenketten. Das Beispiel im nächsten Abschnitt zeigt Variationen in der Indexgröße basierend auf den ausgewählten Attributen.

Suggesters sind Konstrukte, die Type-Ahead- oder Autocomplete-Abfragen unterstützen. Wenn Sie also einen Suggestor einbinden, erstellt der Indizierungsprozess die Datenstrukturen, die für wortwörtliche Zeichenübereinstimmungen erforderlich sind. Suggestoren werden auf Feldebene implementiert. Wählen Sie daher nur die Felder aus, die sich für die Vorauswahl eignen.

Beispiel zur Veranschaulichung der Auswirkungen von Attributen und Suggestoren auf die Speicherung

Der folgende Screenshot veranschaulicht die Indexspeichermuster aus verschiedenen Kombinationen von Attributen. Der Index basiert auf dem Immobilien-Musterindex, den Sie mit dem Datenimport-Assistenten und den integrierten Beispieldaten leicht erstellen können. Obwohl die Indexschemas nicht angezeigt werden, können Sie die auf dem Indexnamen basierenden Attribute ableiten. Beispielsweise ist für den realestate-searchable-Index das searchable-Attribut ausgewählt und sonst nichts, für den realestate-retrievable-Index ist das retrievable-Attribut ausgewählt und nichts anderes usw.

Obwohl diese Indexvarianten etwas künstlich sind, können wir sie für allgemeine Vergleiche der Auswirkungen von Attributen auf die Speicherung heranziehen:

• „abrufbar“ hat keine Auswirkungen auf die Indexgröße.
• „filterbar“, „sortierbar“, „facettierbar“ verbrauchen mehr Speicher.
• Die Vorschlagsfunktion führt mit hoher Wahrscheinlichkeit zu einer Vergrößerung des Index. Diese fällt allerdings nicht so stark aus, wie es der Screenshot vermuten lässt. (In diesem Beispiel wurden alle Felder ausgewählt, die für die Vorschlagsfunktion verwendet werden können, was bei den meisten Indizes äußerst unwahrscheinlich ist.)

Außerdem werden in der vorherigen Tabelle auch die Auswirkungen von analyzers nicht berücksichtigt. Wenn Sie den Tokenizer edgeNgram zum Speichern von direkten Zeichensequenzen (a, ab, abc, abcd) verwenden, ist der Index größer als bei Verwendung des Standardanalysetools.

Grundlegende Vorgänge und Interaktionen

Nachdem Sie nun eine bessere Vorstellung davon haben, was ein Index ist, werden in diesem Abschnitt die Operationen zur Laufzeit eines Index vorgestellt, einschließlich der Verbindung zu einem einzelnen Index und dessen Sicherung.

Index-Isolierung

In der Azure KI-Suche arbeiten Sie jeweils mit einem Index, wobei alle indexbezogenen Operationen auf einen einzigen Index abzielen. Es gibt kein Konzept für verwandte Indizes oder die Verknüpfung unabhängiger Indizes, weder für die Indizierung noch für die Abfrage.

Ständig verfügbar

Ein Index ist sofort für Abfragen verfügbar, sobald das erste Dokument indiziert ist, aber erst dann vollständig funktionsfähig, wenn alle Dokumente indiziert sind. Intern wird ein Suchindex über Partitionen verteilt und für Replikate ausgeführt. Der physische Index wird intern verwaltet. Der logische Index wird von Ihnen verwaltet.

Ein Index ist ständig verfügbar, ohne dass er angehalten oder offline genommen werden kann. Da er für einen kontinuierlichen Betrieb ausgelegt ist, erfolgen alle Aktualisierungen seines Inhalts oder Ergänzungen des Index selbst in Echtzeit. Daher kann es vorkommen, dass Abfragen vorübergehend unvollständige Ergebnisse liefern, wenn eine Anforderung mit einer Dokumentenaktualisierung zusammenfällt.

Beachten Sie, dass die Abfragekontinuität für Dokumentoperationen (Aktualisieren oder Löschen) und für Änderungen besteht, die sich nicht auf die bestehende Struktur und Integrität des aktuellen Index auswirken (z. B. Hinzufügen neuer Felder). Wenn Sie strukturelle Aktualisierungen vornehmen müssen (Änderung vorhandener Felder), werden diese in der Regel durch einen Drop-and-Rebuild-Workflow in einer Entwicklungsumgebung oder durch die Erstellung einer neuen Version des Indexes im Produktionsdienst verwaltet.

Um die Neuerstellung eines Indexes zu vermeiden, entscheiden sich einige Kunden, die kleine Änderungen vornehmen, für die Versionsverwaltung eines Felds, indem sie ein neues Feld erstellen, das neben einer früheren Version existiert. Im Laufe der Zeit führt dies zu verwaisten Inhalten in Form von veralteten Feldern oder veralteten benutzerdefinierten Analyzer-Definitionen, insbesondere in einem Produktionsindex, der teuer zu replizieren ist. Sie können diese Probleme bei geplanten Aktualisierungen des Index im Rahmen des Index-Lebenszyklusverwaltung angehen.

Endpunktverbindung und Sicherheit

Alle Indizierungs- und Abfrage Anforderung zielen auf einen Index ab. Endpunkte sind in der Regel einer der folgenden:

Herstellen einer Verbindung mit Azure KI-Suche

1. Beginnen Sie mit dem Azure-Portal. Azure-Abonnenten oder die Person, die den Suchdienst erstellt hat, können den Suchdienst im Azure-Portal verwalten. Ein Azure-Abonnement benötigt zum Erstellen oder Löschen von Diensten mindestens die Berechtigung für Mitwirkende. Diese Berechtigungsebene reicht aus, um einen Suchdienst im Azure-Portal vollständig zu verwalten.

2. Versuchen Sie andere Clients für den programmgesteuerten Zugriff. Wir empfehlen die Schnellstarts für die ersten Schritte:

   • Schnellstart: REST
   • Schnellstart: Azure SDKs
   • Schnellstart: RAG (mit Visual Studio Code und einem Jupyter-Notebook)

Nächste Schritte

Praktische Erfahrungen mit der Erstellung eines Index können Sie mit fast jedem Beispiel oder jeder exemplarischen Vorgehensweise für Azure AI Search sammeln. Als Einstieg können Sie einen der Schnellstarts im Inhaltsverzeichnis auswählen.

Sie sollten sich aber auch mit Methoden zum Laden eines Index mit Daten vertraut machen. Strategien zur Indexdefinition und zum Datenimport werden zusammen definiert. Die folgenden Artikel bieten Informationen zum Erstellen und Laden eines Index.

• Erstellen von Suchindizes in Azure Cognitive Search
• Erstellen eines Vektorspeichers
• Erstellen eines Indexalias
• Übersicht über den Datenimport
• Laden eines Index