Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In Azure KI-Suche ist ein normalizer eine Komponente, die Text für den Schlüsselwortabgleich in Feldern vorverarbeitet, die als "filtrierbar", "facetable" oder "sortierbar" gekennzeichnet sind. Im Gegensatz zu durchsuchbaren Volltextfeldern, die mit Textanalysatoren gekoppelt sind, werden Inhalte, die für Filter-Facet-Sortierungsvorgänge erstellt werden, keine Analyse oder Tokenisierung durchlaufen. Das Auslassen einer Textanalyse kann zu unerwarteten Ergebnissen führen, wenn Groß- und Kleinschreibungsunterschiede auftreten, weshalb Sie einen Normalisierer benötigen, um Variationen in Ihrem Inhalt zu homogenisieren.
Durch Anwenden eines Normalisierers können Sie Lichttexttransformationen erzielen, die Die Ergebnisse verbessern:
- Konsistente Groß-/Kleinschreibung (z. B. alles Kleinbuchstaben oder alles Großbuchstaben)
- Normalisieren von Akzenten und diakritischen Zeichen wie ö oder ê auf ASCII-äquivalente Zeichen "o" und "e"
- Zeichen wie
-und Leerzeichen einem vom Benutzer angegebenen Zeichen zuordnen
Vorteile von Normalisierern
Das Suchen und Abrufen von Dokumenten aus einem Suchindex erfordert, dass die Abfrageeingabe dem Inhalt des Dokuments entspricht. Der Abgleich erfolgt entweder über tokenisierte Inhalte, wie beim Aufrufen von "Suche" 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 den genauen Text"Las Vegas"enthalten, und schließt dabei Dokumente mit"LAS VEGAS"und"las vegas"aus. Dies ist unangemessen, wenn der Anwendungsfall alle Dokumente unabhängig von der Groß-/Kleinschreibung erfordert.search=*&facet=City,count:5gibt"Las Vegas","LAS VEGAS"und"las vegas"als unterschiedliche Werte zurück, obwohl es sich um dieselbe Stadt handelt.search=usa&$orderby=Citywird die Städte in lexikografischer Reihenfolge zurückgeben:"Las Vegas","Seattle","las vegas", auch wenn die Absicht besteht, die gleichen Städte unabhängig vom Fall zusammenzuordnen.
Ein Normalisierer, der während der Indizierung und Abfrageausführung aufgerufen wird, fügt leichte Transformationen hinzu, die geringfügige Unterschiede bei Text für Filter-, Facet- und Sortierszenarien glätten. In den vorherigen Beispielen würden die Varianten von "Las Vegas" gemäß dem von Ihnen ausgewählten Normalisierer verarbeitet (z. B. wird der gesamte Text kleingeschrieben), um einheitlichere Ergebnisse zu erzielen.
So geben Sie einen Normalisierer an
Normalisierer werden in einer Indexdefinition auf Feldbasis für Textfelder (Edm.String und Collection(Edm.String)) angegeben, die mindestens eine der Eigenschaften "filterbar", "sortierbar" oder "facetable" auf "true" festgelegt haben. Das Festlegen eines Normalisierers ist optional und standardmäßig NULL. Es wird empfohlen, vordefinierte Normalisierer auszuwerten, bevor ein benutzerdefinierter Normalisierer konfiguriert wird.
Normalisierer können nur angegeben werden, wenn Sie dem Index ein neues Feld hinzufügen. Wenn möglich, versuchen Sie, die Normalisierungsanforderungen im Vorfeld zu bewerten und Normalisierer in den ersten Entwicklungsphasen zuzuweisen, wenn das Löschen und Neuanlegen von Indizes routinemäßig erfolgt.
Legen Sie beim Erstellen einer Felddefinition im Index die Eigenschaft "normalizer" auf einen der folgenden Werte fest: einen vordefinierten Normalisierer wie "Kleinbuchstaben" oder einen benutzerdefinierten Normalisierer (definiert im selben Indexschema).
"fields": [ { "name": "Description", "type": "Edm.String", "retrievable": true, "searchable": true, "filterable": true, "analyzer": "en.microsoft", "normalizer": "lowercase" ... } ]Benutzerdefinierte Normalisierer werden zuerst im Abschnitt "Normalizer" des Indexes definiert und dann der Felddefinition zugewiesen, wie im vorherigen Schritt gezeigt. Weitere Informationen finden Sie unter Create Index and also Add custom normalizers.
"fields": [ { "name": "Description", "type": "Edm.String", "retrievable": true, "searchable": true, "analyzer": null, "normalizer": "my_custom_normalizer" },
Hinweis
Um den Normalisierer eines vorhandenen Felds zu ändern, erstellen Sie den Index vollständig neu (Einzelne Felder können nicht neu erstellt werden).
Eine gute Problemumgehung für Produktionsindizes, bei denen die Neuerstellung von Indizes kostspielig ist, besteht darin, ein neues Feld zu erstellen, das mit dem alten, aber mit dem neuen Normalisierer identisch ist, und es anstelle des alten zu verwenden. Verwenden Sie Update Index, um das neue Feld zu integrieren, und mergeOrUpload, um es zu füllen. Später können Sie im Rahmen der geplanten Indexwartung den Index bereinigen, um veraltete Felder zu entfernen.
Vordefinierte und benutzerdefinierte Normalisierer
Azure KI-Suche bietet integrierte Normalisierer für gängige Anwendungsfälle sowie die Möglichkeit, nach Bedarf anzupassen.
| Kategorie | Beschreibung |
|---|---|
| Vordefinierte Normalisierer | Diese sind vorgefertigt verfügbar und können ohne Konfiguration verwendet werden. |
| Benutzerdefinierte Normalisierer1 | Für erweiterte Szenarien. Erfordert eine benutzerdefinierte Konfiguration einer Kombination vorhandener Elemente, bestehend aus Zeichen- und Tokenfiltern. |
(1) Benutzerdefinierte Normalisierer geben keine Tokenizer an, da Normalisierer immer ein einzelnes Token erzeugen.
Testen eines Normalisierers
Sie können den Test Analyzer (REST) verwenden, um zu sehen, wie ein Normalisierer eine Eingabe verarbeitet.
Anfrage
POST https://[search service name].search.windows.net/indexes/[index name]/analyze?api-version=[api-version]
Content-Type: application/json
api-key: [admin key]
{
"normalizer":"asciifolding",
"text": "Vis-à-vis means Opposite"
}
Antwort
HTTP/1.1 200 OK
{
"tokens": [
{
"token": "Vis-a-vis means Opposite",
"startOffset": 0,
"endOffset": 24,
"position": 0
}
]
}
Referenz zu Normalisierern
Vordefinierte Normalisierer
| Namen | Beschreibung und Optionen |
|---|---|
| Standard | Der Text wird klein geschrieben und anschließend wird Asciifolding durchgeführt. |
| Kleinbuchstaben | Wandelt Zeichen in Kleinbuchstaben um. |
| Großbuchstaben | Wandelt Zeichen in Großbuchstaben um. |
| asciifolding | Transformiert Zeichen, die sich nicht im Unicode-Block "Basic Latin" befinden, in ihre ASCII-Entsprechung, sofern vorhanden. Beispiel: Wechseln à zu a. |
| Elision | Entfernt Elision vom Anfang der Tokens. |
Unterstützte Zeichenfilter
Normalisierer unterstützen zwei Zeichenfilter, die mit ihren Gegenstücken in benutzerdefinierten Analysezeichenfiltern identisch sind:
Unterstützte Tokenfilter
Die folgende Liste zeigt die tokenfilter, die für Normalisierer unterstützt werden, und ist eine Teilmenge der allgemeinen Tokenfilter, die in benutzerdefinierten Analysen verwendet werden.
- Arabische Normalisierung
- asciifolding
- cjk_width
- Elision
- german_normalization
- hindi_normalization
- indic_normalization
- persian_normalization
- scandinavian_normalization
- scandinavian_folding
- sorani_normalization
- Kleinbuchstaben
- Großbuchstaben
Hinzufügen von benutzerdefinierten Normalisierern
Benutzerdefinierte Normalisierer werden innerhalb des Indexschemas definiert. Die Definition enthält einen Namen, einen Typ, einen oder mehrere Zeichenfilter und Tokenfilter. Die Zeichenfilter und Tokenfilter sind die Bausteine für einen benutzerdefinierten Normalisierer und für die Verarbeitung des Texts verantwortlich. Diese Filter werden von links nach rechts angewendet.
Dies token_filter_name_1 ist der Name des Tokenfilters und char_filter_name_1char_filter_name_2 sind die Namen von Zeichenfiltern (siehe unterstützte Tokenfilter und unterstützte Zeichenfiltertabellenunten für gültige Werte).
"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 Normalisierer können während der Indexerstellung oder später durch Aktualisieren einer vorhandenen hinzugefügt werden. Das Hinzufügen eines benutzerdefinierten Normalisierers zu einem vorhandenen Index erfordert, dass das Flag "allowIndexDowntime" im Updateindex angegeben wird und bewirkt, dass der Index einige Sekunden lang nicht verfügbar ist.
Beispiel für einen benutzerdefinierten Normalisierer
Das folgende Beispiel veranschaulicht eine benutzerdefinierte Normalisierungsdefinition mit entsprechenden Zeichenfiltern und Tokenfiltern. Benutzerdefinierte Optionen für Zeichenfilter und Tokenfilter werden separat als benannte Konstrukte angegeben und dann wie unten dargestellt in der Normalisierungsdefinition referenziert.
Ein benutzerdefinierter Normalisierer mit dem Namen "my_custom_normalizer" wird im Abschnitt "Normalizer" der Indexdefinition definiert.
Der Normalisierer besteht aus zwei Zeichenfiltern und drei Tokenfiltern: Elision, Kleinbuchstaben und angepasster Asciifolding-Filter "my_asciifolding".
Der erste Zeichenfilter "map_dash" ersetzt alle Striche durch Unterstriche, während die zweite "remove_whitespace" alle Leerzeichen entfernt.
{
"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
}
]
}