Freigeben über

Textnormalisierung für Filter, Facetten und Sortierungen ohne Beachtung der Groß-/Kleinschreibung

  • Artikel

Wichtig

Dieses Feature befindet sich in der Public Preview-Phase und unterliegt zusätzlichen Nutzungsbedingungen. Die Vorschau-REST-API unterstützt dieses Feature.

Eine Normalisierungsfunktion in Azure KI Search ist eine Komponente, die Text für den Schlüsselwortabgleich über Felder, die als „filterable“ (filterbar), „facetable“ (facettierbar) oder „sortable“ (sortierbar) gekennzeichnet sind, vorverarbeitet. Im Gegensatz zu „durchsuchbaren“ Volltextfeldern, die mit Textanalysetools gekoppelt sind, durchlaufen Inhalte, die für Filter-Facetten-Sortierungsvorgänge erstellt werden, keine Analyse oder Tokenisierung. Das Auslassen einer Textanalyse kann zu unerwarteten Ergebnissen führen, wenn Unterschiede bei der Groß- und Kleinschreibung sowie bei Zeichen auftreten, weshalb Sie eine Normalisierungsfunktion benötigen, um Variationen in Ihrem Inhalt zu homogenisieren.

Durch Anwenden einer Normalisierungsfunktion können Sie leichte Texttransformationen erzielen, die die Ergebnisse verbessern:

  • Konsistente Groß-/Kleinschreibung (z. B. alles Kleinbuchstaben oder alles Großbuchstaben)
  • Normalisierung von diakritischen Zeichen wie „ö“ oder „ê“ in entsprechende ASCII-Zeichen wie „o“ und „e“
  • Zuordnung von Zeichen wie - und Leerzeichen zu einem vom Benutzer festgelegten Zeichen

Vorteile von Normalisierungsfunktionen

Beim Suchen und Abrufen von Dokumenten aus einem Suchindex muss die Abfrageeingabe mit den Inhalten des Dokuments abgeglichen werden. Der Abgleich erfolgt entweder über tokenisierte Inhalte, wie beim Aufrufen von „Suchen“ oder über nicht tokenisierte Inhalte, wenn die Anforderung ein filter, facet oder orderby-Vorgang ist.

Da nicht tokenisierte Inhalte ebenfalls nicht analysiert werden, werden kleine Unterschiede im Inhalt als unterschiedliche Werte ausgewertet. Betrachten Sie die folgenden Beispiele:

  • $filter=City eq 'Las Vegas' gibt nur Dokumente zurück, die die exakte Textzeichenfolge "Las Vegas" enthalten, und schließt Dokumente aus, die die Zeichenfolgen "LAS VEGAS" und "las vegas" enthalten, was unzureichend ist, wenn der Anwendungsfall alle Dokumente unabhängig von der Groß-/Kleinschreibung erfordert.

  • search=*&facet=City,count:5 gibt "Las Vegas", "LAS VEGAS" und "las vegas" als unterschiedliche Werte zurück, obwohl es sich um dieselbe Stadt handelt.

  • search=usa&$orderby=City gibt die Städte in lexikografischer Reihenfolge zurück: "Las Vegas", "Seattle", "las vegas". Das ist auch der Fall, wenn die Absicht darin besteht, dieselben Städte unabhängig der Groß-/Kleinschreibung in einer Reihenfolge zu sortieren.

Eine Normalisierungsfunktion, die während der Indizierung und Abfrageausführung aufgerufen wird, fügt leichte Transformationen hinzu, die geringfügige Unterschiede im Text für Filter-, Facetten- und Sortierszenarien glätten. In den vorherigen Beispielen würden die Varianten von "Las Vegas" entsprechend der von Ihnen ausgewählten Normalisierungsfunktion verarbeitet (z. B. wenn der gesamte Text kleingeschrieben ist), um einheitlichere Ergebnisse zu erzielen.

So geben Sie eine Normalisierungsfunktion an

Normalisierungsfunktionen werden in einer Indexdefinition auf Feldbasis für Textfelder (Edm.String und Collection(Edm.String)) angegeben, für die mindestens eine der Eigenschaften „filterable“ (filterbar), „sortable“ (sortierbar) oder „facetable“ (facettierbar) auf „true“ festgelegt ist. Das Festlegen einer Normalisierungsfunktion ist optional, und der Standardwert ist „NULL“. Es wird empfohlen, vordefinierte Normalisierungsfunktionen in Betracht zu ziehen, bevor Sie eine benutzerdefinierte Normalisierungsfunktion konfigurieren.

Normalisierungsfunktionen können nur angegeben werden, wenn Sie dem Index ein neues Feld hinzufügen. Versuchen Sie daher, wenn möglich, die Normalisierungsanforderungen vorab zu bewerten und Normalisierungsfunktionen in den ersten Entwicklungsphasen zuzuweisen, wenn das Löschen und Neuerstellen von Indizes häufig erfolgt.

  1. Beim Erstellen einer Felddefinition im Index legen Sie die Eigenschaft „normalizer“ auf einen der folgenden Werte fest: eine vordefinierte Normalisierungsfunktion wie „lowercase“ oder eine benutzerdefinierte Normalisierungsfunktion (die im gleichen Indexschema definiert wird).

    "fields": [
 {
   "name": "Description",
   "type": "Edm.String",
   "retrievable": true,
   "searchable": true,
   "filterable": true,
   "analyzer": "en.microsoft",
   "normalizer": "lowercase"
   ...
 }
]

  2. Benutzerdefinierte Normalisierungsfunktionen werden zuerst im Abschnitt „normalizers“ des Index definiert und dann wie im vorherigen Schritt gezeigt der Felddefinition zugewiesen. Weitere Informationen finden Sie unter Erstellen des Index und unter Hinzufügen benutzerdefinierter Normalisierungsfunktionen.

    "fields": [
 {
   "name": "Description",
   "type": "Edm.String",
   "retrievable": true,
   "searchable": true,
   "analyzer": null,
   "normalizer": "my_custom_normalizer"
 },

Hinweis

Zum Ändern der Normalisierungsfunktion eines vorhandenen Felds müssen Sie den Index vollständig neu erstellen (Sie können einzelne Felder nicht neu erstellen).

Eine gute Problemumgehung für Produktionsindizes, bei denen die Neuerstellung von Indizes kostspielig ist, besteht darin, ein neues Feld zu erstellen, die mit dem alten Feld identisch ist, aber die neue Normalisierungsfunktion umfasst, und dieses anstelle des alten Felds zu verwenden. Integrieren Sie das neue Feld mit Update Index (Index aktualisieren), und füllen Sie es mit mergeOrUpload. Später können Sie den Index als Bestandteil der geplanten Indexwartung bereinigen, um veraltete Felder zu entfernen.

Vordefinierte und benutzerdefinierte Normalisierungsfunktionen

Azure KI Search stellt integrierte Normalisierungsfunktionen für gängige Anwendungsfälle bereit und bietet die Möglichkeit, diese nach Bedarf anzupassen.

Category Beschreibung
Vordefinierte Normalisierungsfunktionen Diese sind vorgefertigt verfügbar und können ohne Konfiguration verwendet werden.
Benutzerdefinierte Normalisierungsfunktionen 1 Diese sind für fortgeschrittene Szenarios vorgesehen. Sie erfordern eine benutzerdefinierte Konfiguration einer Kombination vorhandener Elemente, die aus Char- und Tokenfiltern bestehen.

(1) Benutzerdefinierte Normalisierungsfunktionen legen keine Tokenizer fest, da Normalisierungsfunktionen immer ein einzelnes Token erzeugen.

Referenz zu Normalisierungsfunktionen

Vordefinierte Normalisierungsfunktionen

Name Beschreibung und Optionen
Standard Der Text wird klein geschrieben und anschließend wird Asciifolding durchgeführt.
Kleinbuchstaben Zeichen werden in Kleinbuchstaben umgewandelt.
Großbuchstaben Zeichen werden in Großbuchstaben umgewandelt.
asciifolding Zeichen, die nicht im Unicodeblock Basis-Lateinisch enthalten sind, werden in ihre ASCII-Entsprechungen umgewandelt, sofern eine vorhanden ist. Beispiel: Änderung von à in a.
elision Die Elision wird vom Anfang der Token entfernt.

Unterstützte Char-Filter

Normalisierungsfunktionen unterstützen zwei Zeichenfilter, die mit ihren Entsprechungen in Zeichenfiltern benutzerdefinierter Analysetools identisch sind:

Unterstützte Tokenfilter

In der folgenden Liste sind die Tokenfilter aufgeführt, die für Normalisierungsfunktionen unterstützt werden. Es handelt sich um eine Teilmenge der allgemeinen in benutzerdefinierten Analysetools verwendeten Tokenfilter.

Hinzufügen benutzerdefinierter Normalisierungsfunktionen

Benutzerdefinierte Normalisierungsfunktionen werden innerhalb des Indexschemas definiert. Die Definition umfasst einen Namen, einen Typ und jeweils mindestens einen Zeichen- und Tokenfilter. Die Zeichen- und Tokenfilter sind die Bausteine für eine benutzerdefinierte Normalisierungsfunktion und für die Verarbeitung des Texts verantwortlich. Diese Filter werden von links nach rechts angewendet.

token_filter_name_1 ist der Name des Tokenfilters, char_filter_name_1 und char_filter_name_2 sind die Namen der Zeichenfilter (zulässige Werte finden Sie in den unten aufgeführten Tabellen Unterstützte Tokenfilter und Unterstützte Zeichenfilter).

"normalizers":(optional)[
   {
      "name":"name of normalizer",
      "@odata.type":"#Microsoft.Azure.Search.CustomNormalizer",
      "charFilters":[
         "char_filter_name_1",
         "char_filter_name_2"
      ],
      "tokenFilters":[
         "token_filter_name_1"
      ]
   }
],
"charFilters":(optional)[
   {
      "name":"char_filter_name_1",
      "@odata.type":"#char_filter_type",
      "option1": "value1",
      "option2": "value2",
      ...
   }
],
"tokenFilters":(optional)[
   {
      "name":"token_filter_name_1",
      "@odata.type":"#token_filter_type",
      "option1": "value1",
      "option2": "value2",
      ...
   }
]

Benutzerdefinierte Normalisierungsfunktionen können während der Erstellung des Index oder später hinzugefügt werden, indem Sie einen vorhandenen Index ändern. Für das Hinzufügen einer benutzerdefinierten Normalisierungsfunktion zu einem vorhandenen Index muss das Flag „allowIndexDowntime“ im Update-Index angegeben werden, was dazu führt, dass der Index einige Sekunden lang nicht verfügbar ist.

Beispiel für eine benutzerdefinierte Normalisierungsfunktion

Im folgenden Beispiel wird eine Definition einer benutzerdefinierten Normalisierungsfunktion mit entsprechenden Zeichen- und Tokenfiltern veranschaulicht. Benutzerdefinierte Optionen für Zeichen- und Tokenfilter werden separat in Form von benannten Konstrukten festgelegt und dann in der Definition der Normalisierungsfunktion referenziert (siehe unten).

  • Eine benutzerdefinierte Normalisierungsfunktion namens „my_custom_normalizer“ wird im Abschnitt „normalizers“ der Indexdefinition definiert.

  • Die Normalisierungsfunktion besteht aus zwei Zeichen- und drei Tokenfiltern: „elision“, „lowercase“ und einem benutzerdefinierten Asciifolding-Filter namens „my_asciifolding“.

  • Der erste Zeichenfilter namens „map_dash“ ersetzt alle Bindestriche durch Unterstriche, und der zweite namens „remove_whitespace“ entfernt alle Leerzeichen.

  {
     "name":"myindex",
     "fields":[
        {
           "name":"id",
           "type":"Edm.String",
           "key":true,
           "searchable":false,
        },
        {
           "name":"city",
           "type":"Edm.String",
           "filterable": true,
           "facetable": true,
           "normalizer": "my_custom_normalizer"
        }
     ],
     "normalizers":[
        {
           "name":"my_custom_normalizer",
           "@odata.type":"#Microsoft.Azure.Search.CustomNormalizer",
           "charFilters":[
              "map_dash",
              "remove_whitespace"
           ],
           "tokenFilters":[              
              "my_asciifolding",
              "elision",
              "lowercase",
           ]
        }
     ],
     "charFilters":[
        {
           "name":"map_dash",
           "@odata.type":"#Microsoft.Azure.Search.MappingCharFilter",
           "mappings":["-=>_"]
        },
        {
           "name":"remove_whitespace",
           "@odata.type":"#Microsoft.Azure.Search.MappingCharFilter",
           "mappings":["\\u0020=>"]
        }
     ],
     "tokenFilters":[
        {
           "name":"my_asciifolding",
           "@odata.type":"#Microsoft.Azure.Search.AsciiFoldingTokenFilter",
           "preserveOriginal":true
        }
     ]
  }

Siehe auch