Tutorial: Erstellen eines benutzerdefinierten Analysetools für Telefonnummern

Bei Suchlösungen können Zeichenfolgen mit komplexen Mustern oder Sonderzeichen schwierig zu bearbeiten sein, da der Standard-Analyser aussagekräftige Teile eines Musters entfernt oder falsch interpretiert. Dies führt zu einer schlechten Sucherfahrung, bei der Benutzer die erwarteten Informationen nicht finden können. Telefonnummern sind ein klassisches Beispiel für Zeichenfolgen, die schwer zu analysieren sind. Sie kommen in verschiedenen Formaten und enthalten Sonderzeichen, die der Standardanalysator ignoriert.

Mit Telefonnummern als Betreff verwendet dieses Lernprogramm die REST-APIs des Suchdiensts , um musterbasierte Datenprobleme mithilfe eines benutzerdefinierten Analyzers zu lösen. Dieser Ansatz kann wie für Telefonnummern verwendet oder für Felder mit denselben Merkmalen (mit Sonderzeichen gemustert) wie URLs, E-Mails, Postleitzahlen und Datumsangaben angepasst werden.

In diesem Tutorial erfahren Sie:

Verstehen des Problems
Entwickeln eines ersten benutzerdefinierten Analysetools für die Behandlung von Telefonnummern
Testen des benutzerdefinierten Analysetools
Optimieren des Designs des benutzerdefinierten Analysetools zur weiteren Verbesserung der Ergebnisse

Voraussetzungen

Ein Azure-Konto mit einem aktiven Abonnement. Kostenlos ein Konto erstellen.
Ein Azure AI Search-Dienst.
Visual Studio Code mit der REST-Clienterweiterung.

Herunterladen von Dateien

Der Quellcode für dieses Lernprogramm befindet sich in der Datei "custom-analyzer.rest " im GitHub-Repository "Azure-Samples/azure-search-rest-samples ".

Kopieren eines Administratorschlüssels und einer URL

Die REST-Aufrufe in diesem Tutorial erfordern einen Suchdienstendpunkt und einen Administrator-API-Schlüssel. Diese Werte erhalten Sie im Azure-Portal.

Melden Sie sich beim Azure-Portal an, und wählen Sie Ihren Suchdienst aus.
Wählen Sie im linken Bereich die Option "Übersicht" aus, und kopieren Sie den Endpunkt. Er sollte in diesem Format vorliegen: https://my-service.search.windows.net
Wählen Sie im linken Bereich "Einstellungen" die Option "Einstellungen>" aus, und kopieren Sie einen Administratorschlüssel für vollständige Rechte für den Dienst. Es gibt zwei austauschbare Administratorschlüssel, die zur Gewährleistung der Geschäftskontinuität bereitgestellt wurden, falls ein Schlüssel ausgetauscht werden muss. Sie können einen der Schlüssel für Anforderungen verwenden, um Objekte hinzuzufügen, zu ändern oder zu löschen.

Erstellen eines Anfangsindexes

Öffnen Sie eine neue Textdatei in Visual Studio Code.
Legen Sie Variablen auf den Suchendpunkt und den API-Schlüssel fest, den Sie im vorherigen Abschnitt gesammelt haben.
```
@baseUrl = PUT-YOUR-SEARCH-SERVICE-URL-HERE
@apiKey = PUT-YOUR-ADMIN-API-KEY-HERE
```
Speichern Sie die Datei nicht mit einer .rest-Dateierweiterung.

Verwenden Sie das folgende Beispiel, um einen kleinen Index namens phone-numbers-index mit zwei Feldern zu erstellen: id und phone_number.

### Create a new index
POST {{baseUrl}}/indexes?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
  "name": "phone-numbers-index",  
  "fields": [
    {
      "name": "id",
      "type": "Edm.String",
      "key": true,
      "searchable": true,
      "filterable": false,
      "facetable": false,
      "sortable": true
    },
    {
      "name": "phone_number",
      "type": "Edm.String",
      "sortable": false,
      "searchable": true,
      "filterable": false,
      "facetable": false
    }
  ]
}

Sie haben noch keine Analyse definiert, sodass der standard.lucene Analyzer standardmäßig verwendet wird.

Klicken Sie auf Anforderung senden. Sie sollten eine HTTP/1.1 201 Created Antwort haben, und der Antworttext sollte die JSON-Darstellung des Indexschemas enthalten.

Laden Sie Daten in den Index mithilfe von Dokumenten, die verschiedene Telefonnummernformate enthalten. Dies sind Ihre Testdaten.

### Load documents
POST {{baseUrl}}/indexes/phone-numbers-index/docs/index?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
  "value": [
    {
      "@search.action": "upload",
      "id": "1",
      "phone_number": "425-555-0100"
    },
    {
      "@search.action": "upload",
      "id": "2",
      "phone_number": "(321) 555-0199"
    },
    {
      "@search.action": "upload",
      "id": "3",
      "phone_number": "+1 425-555-0100"
    },
    {
      "@search.action": "upload",
      "id": "4",
      "phone_number": "+1 (321) 555-0199"
    },
    {
      "@search.action": "upload",
      "id": "5",
      "phone_number": "4255550100"
    },
    {
      "@search.action": "upload",
      "id": "6",
      "phone_number": "13215550199"
    },
    {
      "@search.action": "upload",
      "id": "7",
      "phone_number": "425 555 0100"
    },
    {
      "@search.action": "upload",
      "id": "8",
      "phone_number": "321.555.0199"
    }
  ]
}

Probieren Sie Abfragen aus, die dem, was ein Benutzer eingeben kann, ähneln. Beispielsweise kann ein Benutzer nach einer beliebigen Anzahl von Formaten suchen (425) 555-0100 und dennoch erwarten, dass Ergebnisse zurückgegeben werden. Beginnen Sie mit der Suche (425) 555-0100.

### Search for a phone number
POST {{baseUrl}}/indexes/phone-numbers-index/docs/search?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
  "search": "(425) 555-0100"
}

Die Abfrage gibt drei von vier erwarteten Ergebnissen zurück, gibt aber auch zwei unerwartete Ergebnisse zurück.

{
    "value": [
        {
            "@search.score": 0.05634898,
            "phone_number": "+1 425-555-0100"
        },
        {
            "@search.score": 0.05634898,
            "phone_number": "425 555 0100"
        },
        {
            "@search.score": 0.05634898,
            "phone_number": "425-555-0100"
        },
        {
            "@search.score": 0.020766128,
            "phone_number": "(321) 555-0199"
        },
        {
            "@search.score": 0.020766128,
            "phone_number": "+1 (321) 555-0199"
        }
    ]
}

Versuchen Sie es erneut ohne Formatierung: 4255550100.

### Search for a phone number
POST {{baseUrl}}/indexes/phone-numbers-index/docs/search?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
  "search": "4255550100"
}

Diese Abfrage schneidet noch schlechter ab, da sie nur eine von vier richtigen Übereinstimmungen zurückgibt.

{
    "value": [
        {
            "@search.score": 0.6015292,
            "phone_number": "4255550100"
        }
    ]
}

Wenn diese Ergebnisse verwirrend finden, sind Sie nicht allein. Im nächsten Abschnitt wird erläutert, warum Sie diese Ergebnisse erhalten.

So funktionieren Analysetools

Um diese Suchergebnisse zu verstehen, müssen Sie verstehen, was die Analyse tut. Von dort aus können Sie die Standardanalyse mithilfe der Analyse-API testen und eine Grundlage für das Entwerfen eines Analyzers bereitstellen, der Ihre Anforderungen besser erfüllt.

Ein Analyzer ist eine Komponente der Volltextsuchmaschine , die für die Verarbeitung von Text in Abfragezeichenfolgen und indizierten Dokumenten verantwortlich ist. Verschiedene Analysetools bearbeiten Text je nach Szenario auf verschiedene Arten. In diesem Szenario müssen wir ein Analysetool erstellen, das auf Telefonnummern zugeschnitten ist.

Analysetools bestehen aus drei Komponenten:

Zeichenfiltern, die einzelne Zeichen aus dem Eingabetext entfernen oder ersetzen.
Ein Tokenizer , der den Eingabetext in Token umbricht, wodurch Schlüssel im Suchindex werden.
Tokenfilter, die die vom Tokenizer generierten Token manipulieren.

Das folgende Diagramm zeigt, wie diese drei Komponenten zusammenarbeiten, um einen Satz zu tokenisieren.

Abbildung des Analysetoolvorgangs zum Zerlegen eines Satzes in Token

Diese Token werden dann in einem invertierten Index gespeichert, der eine schnelle Volltextsuche ermöglicht. Ein invertierter Index ermöglicht Volltextsuche, indem er alle eindeutigen Begriffe, die bei der lexikalischen Analyse extrahiert wurden, den Dokumenten zuordnet, in denen sie vorkommen. Sie können ein Beispiel im folgenden Diagramm sehen:

Beispiel für invertierten Index

Die gesamte Suche läuft auf die Suche nach den im invertierten Index gespeicherten Begriffen hinaus. Wenn ein Benutzer eine Abfrage ausgibt:

Wird die Abfrage analysiert, und die Abfragebegriffe werden analysiert.
Der invertierte Index wird nach Dokumenten mit übereinstimmenden Begriffen gescannt.
Der Bewertungsalgorithmus bewertet die abgerufenen Dokumente.

Abbildung des Analysetoolvorgangs zum Ermitteln der Ähnlichkeitsrangfolge

Wenn die Abfragebegriffe nicht mit den Begriffen in Ihrem invertierten Index übereinstimmen, werden keine Ergebnisse zurückgegeben. Weitere Informationen zur Funktionsweise von Abfragen finden Sie unter "Volltextsuche" in Azure AI Search.

Hinweis

Bei partiellen Begriffsabfragen handelt es sich um eine wichtige Ausnahme von dieser Regel. Im Gegensatz zu regulären Ausdrucksabfragen umgehen diese Abfragen (Präfixabfrage, Wildcardabfrage und regex-Abfrage) den lexikalischen Analyseprozess. Partielle Begriffe werden nur in Kleinbuchstaben umgewandelt, bevor Sie mit Begriffen im Index verglichen werden. Wenn eine Analyse nicht für die Unterstützung dieser Arten von Abfragen konfiguriert ist, erhalten Sie häufig unerwartete Ergebnisse, da übereinstimmende Ausdrücke nicht im Index vorhanden sind.

Testen des Analysetools mit der Analyse-API

Die Azure KI-Suche stellt eine Analyse-API zur Verfügung, die es Ihnen ermöglicht, Analysetools zu testen, um zu verstehen, wie sie Text verarbeiten.

Rufen Sie die Analyse-API mithilfe der folgenden Anforderung auf:

### Test analyzer
POST {{baseUrl}}/indexes/phone-numbers-index/analyze?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
  "text": "(425) 555-0100",
  "analyzer": "standard.lucene"
}

Die API gibt die Token zurück, die aus dem Text extrahiert wurden, wobei das von Ihnen angegebene Analysetool verwendet wird. Der Standardmäßige Lucene Analyzer teilt die Telefonnummer in drei separate Token auf.

{
    "tokens": [
        {
            "token": "425",
            "startOffset": 1,
            "endOffset": 4,
            "position": 0
        },
        {
            "token": "555",
            "startOffset": 6,
            "endOffset": 9,
            "position": 1
        },
        {
            "token": "0100",
            "startOffset": 10,
            "endOffset": 14,
            "position": 2
        }
    ]
}

Umgekehrt wird die ohne jegliche Interpunktion formatierte Telefonnummer 4255550100 in ein einziges Token umgewandelt.

{
  "text": "4255550100",
  "analyzer": "standard.lucene"
}

Antwort:

{
    "tokens": [
        {
            "token": "4255550100",
            "startOffset": 0,
            "endOffset": 10,
            "position": 0
        }
    ]
}

Denken Sie daran, dass sowohl die Suchbegriffe als auch die indizierten Dokumente analysiert werden. Denken Sie an die Suchergebnisse aus dem vorherigen Schritt zurück, können Sie sehen, warum diese Ergebnisse zurückgegeben werden.

In der ersten Abfrage werden unerwartete Telefonnummern zurückgegeben, 555da eines ihrer Token mit einem der von Ihnen durchsuchten Begriffe übereinstimmte. In der zweiten Abfrage wird nur die eine Zahl zurückgegeben, da es sich um den einzigen Datensatz handelt, der einen Tokenabgleich 4255550100aufweist.

Erstellen eines benutzerdefinierten Analysetools

Nachdem Sie nun die angezeigten Ergebnisse verstanden haben, erstellen Sie eine benutzerdefinierte Analyse, um die Tokenisierungslogik zu verbessern.

Ziel ist es, eine intuitive Suche nach Telefonnummern zu ermöglichen, unabhängig davon, in welchem Format die Abfrage oder die indizierte Zeichenfolge vorliegt. Um dieses Ergebnis zu erzielen, geben Sie einen Zeichenfilter, einen Tokenizer und einen Tokenfilter an.

Zeichenfilter

Zeichenfilter verarbeiten Text, bevor er in den Tokenizer eingespeist wird. Allgemeine Verwendung von Zeichenfiltern sind das Filtern von HTML-Elementen und das Ersetzen von Sonderzeichen.

Bei Telefonnummern möchten Sie Leerzeichen und Sonderzeichen entfernen, da nicht alle Telefonnummernformate dieselben Sonderzeichen und Leerzeichen enthalten.

"charFilters": [
    {
      "@odata.type": "#Microsoft.Azure.Search.MappingCharFilter",
      "name": "phone_char_mapping",
      "mappings": [
        "-=>",
        "(=>",
        ")=>",
        "+=>",
        ".=>",
        "\\u0020=>"
      ]
    }
  ]

Der Filter entfernt die Zeichen -()+. und Leerzeichen aus der Eingabe.

Eingabe	Output
`(321) 555-0199`	`3215550199`
`321.555.0199`	`3215550199`

Tokenizer

Tokenizer teilen Text in Token auf und verwerfen einige Zeichen, z. B. Interpunktion. In vielen Fällen besteht das Ziel der Tokenisierung darin, einen Satz in einzelne Wörter aufzuteilen.

Verwenden Sie für dieses Szenario einen Schlüsselworttokenizer, keyword_v2, um die Telefonnummer als einzelner Begriff zu erfassen. Dies ist nicht die einzige Möglichkeit, dieses Problem zu lösen, wie im Abschnitt "Alternative Ansätze " erläutert.

Schlüsselwort-Tokenizer geben immer denselben Text aus, den sie als ein einzelner Term erhalten.

Eingabe	Output
`The dog swims.`	`[The dog swims.]`
`3215550199`	`[3215550199]`

Tokenfilter

Tokenfilter ändern oder filtern die vom Tokenizer generierten Token. Eine häufige Verwendung eines Tokenfilters besteht darin, alle Zeichen mithilfe eines Kleinbuchstabentokenfilters in Kleinbuchstaben umzuwandeln. Eine weitere häufige Verwendung ist das Filtern von Stoppwörtern, z. B. the, and oder is.

Sie müssen zwar keine dieser Filter für dieses Szenario verwenden, aber verwenden Sie einen nGram-Tokenfilter, um teilweise Suchvorgänge von Telefonnummern zu ermöglichen.

"tokenFilters": [
  {
    "@odata.type": "#Microsoft.Azure.Search.NGramTokenFilterV2",
    "name": "custom_ngram_filter",
    "minGram": 3,
    "maxGram": 20
  }
]

NGramTokenFilterV2

Der nGram_v2-Tokenfilter teilt Token basierend auf den Parametern minGram und maxGram in n-Gramme einer bestimmten Größe auf.

Für den Telefonanalysator ist minGram auf 3 gesetzt, da dies die kürzeste Teilzeichenfolge ist, nach der Benutzer voraussichtlich suchen. maxGram wird auf 20 festgelegt, um sicherzustellen, dass alle Telefonnummern (selbst mit Durchwahlen) in ein einzelnes N-Gramm passen.

Die unglückliche Nebenwirkung von n-Gramme ist, dass einige falsch-positive Ergebnisse zurückgegeben werden. Sie beheben dies in einem späteren Schritt, indem Sie einen separaten Analyzer für Suchvorgänge erstellen, die den n-Gramm-Tokenfilter nicht enthalten.

Eingabe	Output
`[12345]`	`[123, 1234, 12345, 234, 2345, 345]`
`[3215550199]`	`[321, 3215, 32155, 321555, 3215550, 32155501, 321555019, 3215550199, 215, 2155, 21555, 215550, ... ]`

Analysetool

Nachdem die Zeichenfilter, den Tokenizer und die Tokenfilter eingerichtet wurden, können Sie das Analysetool definieren.

"analyzers": [
  {
    "@odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
    "name": "phone_analyzer",
    "tokenizer": "keyword_v2",
    "tokenFilters": [
      "custom_ngram_filter"
    ],
    "charFilters": [
      "phone_char_mapping"
    ]
  }
]

Aus der Analyse-API werden bei den folgenden Eingaben die Ausgaben des benutzerdefinierten Analyzers wie folgt generiert:

Eingabe	Output
`12345`	`[123, 1234, 12345, 234, 2345, 345]`
`(321) 555-0199`	`[321, 3215, 32155, 321555, 3215550, 32155501, 321555019, 3215550199, 215, 2155, 21555, 215550, ... ]`

Alle Token in der Ausgabespalte sind im Index vorhanden. Wenn Ihre Abfrage einen dieser Begriffe enthält, wird die Telefonnummer zurückgegeben.

Neuerstellen mithilfe des neuen Analysetools

Löschen Sie den aktuellen Index.

### Delete the index
DELETE {{baseUrl}}/indexes/phone-numbers-index?api-version=2025-09-01 HTTP/1.1
api-key: {{apiKey}}

Erstellen Sie den Index mithilfe des neuen Analysetools neu. Dieses Indexschema fügt eine benutzerdefinierte Analysator-Definition und eine benutzerdefinierte Analysatorzuweisung im Telefonnummer-Feld hinzu.

### Create a new index
POST {{baseUrl}}/indexes?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

{
    "name": "phone-numbers-index-2",  
    "fields": [
      {
          "name": "id",
          "type": "Edm.String",
          "key": true,
          "searchable": true,
          "filterable": false,
          "facetable": false,
          "sortable": true
      },
      {
          "name": "phone_number",
          "type": "Edm.String",
          "sortable": false,
          "searchable": true,
          "filterable": false,
          "facetable": false,
          "analyzer": "phone_analyzer"
      }
    ],
    "analyzers": [
        {
          "@odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
          "name": "phone_analyzer",
          "tokenizer": "keyword_v2",
          "tokenFilters": [
          "custom_ngram_filter"
        ],
        "charFilters": [
          "phone_char_mapping"
          ]
        }
    ],
    "charFilters": [
        {
          "@odata.type": "#Microsoft.Azure.Search.MappingCharFilter",
          "name": "phone_char_mapping",
          "mappings": [
            "-=>",
            "(=>",
            ")=>",
            "+=>",
            ".=>",
            "\\u0020=>"
          ]
        }
      ],
      "tokenFilters": [
        {
          "@odata.type": "#Microsoft.Azure.Search.NGramTokenFilterV2",
          "name": "custom_ngram_filter",
          "minGram": 3,
          "maxGram": 20
      }
    ]
}

Testen des benutzerdefinierten Analysetools

Nachdem Sie den Index neu erstellt haben, testen Sie den Analyzer mithilfe der folgenden Anforderung:

### Test custom analyzer
POST {{baseUrl}}/indexes/phone-numbers-index-2/analyze?api-version=2025-09-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}} 

{
  "text": "+1 (321) 555-0199",
  "analyzer": "phone_analyzer"
}

Nun sollte die Sammlung von Token angezeigt werden, die sich aus der Telefonnummer ergeben.

{
    "tokens": [
        {
            "token": "132",
            "startOffset": 1,
            "endOffset": 17,
            "position": 0
        },
        {
            "token": "1321",
            "startOffset": 1,
            "endOffset": 17,
            "position": 0
        },
        {
            "token": "13215",
            "startOffset": 1,
            "endOffset": 17,
            "position": 0
        },
        ...
        ...
        ...
    ]
}

Überarbeiten des benutzerdefinierten Analysetools zur Behandlung falsch positiver Ergebnisse

Nachdem Sie den benutzerdefinierten Analyzer verwendet haben, um Beispielabfragen gegen den Index zu erstellen, sollten Sie sehen, dass die Abrufquote verbessert wurde und alle übereinstimmenden Telefonnummern jetzt abgerufen werden. Der n-Gramm-Tokenfilter bewirkt jedoch auch, dass einige falsch positive Ergebnisse zurückgegeben werden. Dies ist ein gängiger Nebeneffekt eines n-Gramm-Tokenfilters.

Um falsch positive Ergebnisse zu verhindern, erstellen Sie einen separaten Analyzer für die Abfrage. Dieser Analysator ist identisch mit dem vorherigen, mit der Ausnahme, dass er dieses custom_ngram_filter auslässt.

    {
      "@odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
      "name": "phone_analyzer_search",
      "tokenizer": "custom_tokenizer_phone",
      "tokenFilters": [],
      "charFilters": [
        "phone_char_mapping"
      ]
    }

Geben Sie in der Indexdefinition sowohl eine indexAnalyzer als auch eine searchAnalyzer an.

    {
      "name": "phone_number",
      "type": "Edm.String",
      "sortable": false,
      "searchable": true,
      "filterable": false,
      "facetable": false,
      "indexAnalyzer": "phone_analyzer",
      "searchAnalyzer": "phone_analyzer_search"
    }

Mit dieser Änderung haben Sie alles erledigt. Führen Sie als Nächstes folgende Schritte aus:

Löschen des Indexes.
Erstellen Sie den Index neu, nachdem Sie den neuen benutzerdefinierten Analysator (phone_analyzer-search) hinzugefügt haben und weisen Sie diesen Analysator der phone-number-Eigenschaft des searchAnalyzer-Felds zu.
Laden Sie die Daten neu.
Testen Sie die Abfragen erneut, um zu überprüfen, ob die Suche wie erwartet funktioniert. Wenn Sie die Beispieldatei verwenden, erstellt dieser Schritt den dritten Index mit dem Namen phone-number-index-3.

Alternative Ansätze

Das im vorherigen Abschnitt beschriebene Analysetool dient dazu, die Flexibilität für die Suche zu maximieren. Dies geschieht jedoch auf Kosten der Speicherung vieler potenziell unwichtiger Begriffe im Index.

Das folgende Beispiel zeigt einen alternativen Analyzer, der bei der Tokenisierung effizienter ist, hat jedoch Nachteile.

Aufgrund einer Eingabe von 14255550100 kann das Analysetool die Telefonnummer nicht logisch abblocken. Beispielsweise kann die Landesvorwahl (1) nicht von der Ortsvorwahl (425) getrennt werden. Diese Diskrepanz führt dazu, dass die Telefonnummer nicht zurückgegeben wird, wenn ein Benutzer keinen Ländercode in die Suche einschließt.

"analyzers": [
  {
    "@odata.type": "#Microsoft.Azure.Search.CustomAnalyzer",
    "name": "phone_analyzer_shingles",
    "tokenizer": "custom_tokenizer_phone",
    "tokenFilters": [
      "custom_shingle_filter"
    ]
  }
],
"tokenizers": [
  {
    "@odata.type": "#Microsoft.Azure.Search.StandardTokenizerV2",
    "name": "custom_tokenizer_phone",
    "maxTokenLength": 4
  }
],
"tokenFilters": [
  {
    "@odata.type": "#Microsoft.Azure.Search.ShingleTokenFilter",
    "name": "custom_shingle_filter",
    "minShingleSize": 2,
    "maxShingleSize": 6,
    "tokenSeparator": ""
  }
]

Im folgenden Beispiel wird die Telefonnummer in die Blöcke aufgeteilt, nach den Sie normalerweise erwarten, dass ein Benutzer gesucht wird.

Eingabe	Output
`(321) 555-0199`	`[321, 555, 0199, 321555, 5550199, 3215550199]`

Je nach Ihren Anforderungen ist dies möglicherweise ein effizienterer Ansatz für das Problem.

Wesentliche Punkte

In diesem Lernprogramm wurde der Prozess des Erstellens und Testens eines benutzerdefinierten Analyzers veranschaulicht. Sie haben einen Index erstellt, Daten indiziert und dann anhand des Index abgefragt, um zu sehen, welche Suchergebnisse zurückgegeben wurden. Dann haben Sie die Analyse-API verwendet, um den lexikalischen Analyseprozess in Aktion zu sehen.

Während das in diesem Tutorial definierte Analysetool eine einfache Lösung für die Suche nach Telefonnummern bietet, kann derselbe Prozess verwendet werden, um ein benutzerdefiniertes Analysetool für jedes denkbare Szenario mit ähnlichen Merkmalen zu erstellen.

Bereinigen von Ressourcen

Wenn Sie in Ihrem eigenen Abonnement arbeiten, ist es ratsam, nach Abschluss eines Projekts die nicht mehr benötigten Ressourcen zu entfernen. Ressourcen, die weiterhin ausgeführt werden, können Sie Geld kosten. Sie können entweder einzelne Ressourcen oder aber die Ressourcengruppe löschen, um den gesamten Ressourcensatz zu entfernen.

Sie können Ressourcen im Azure-Portal über den Link „Alle Ressourcen“ oder „Ressourcengruppen“ im linken Navigationsbereich suchen und verwalten.

Nächste Schritte

Nachdem Sie nun wissen, wie Sie einen benutzerdefinierten Analyzer erstellen, sehen Sie sich alle verschiedenen Filter, Tokenizer und Analysegeräte an, die für die Erstellung einer umfassenden Suchumgebung verfügbar sind:

Benutzerdefinierte Analysegeräte in Azure AI Search

Feedback

War diese Seite hilfreich?

Last updated on 2025-11-22