Volltextsuche in Azure KI-Suche

Die Volltextsuche ist eine Methode der Informationsbeschaffung, bei der ein in einem Index gespeicherter Klartext durchsucht wird. Bei einer Abfragezeichenfolge "Hotels in San Diego am Strand" sucht die Suchmaschine beispielsweise basierend auf diesen Begriffen nach tokenisierten Zeichenfolgen. Um Scans effizienter zu gestalten, werden Abfragezeichenfolgen lexikalisch analysiert: Kleinschreibung aller Ausdrücke, Entfernen von Stoppwörtern wie "das" und Verringern von Ausdrücken auf primitive Stammformen. Wenn übereinstimmende Ausdrücke gefunden werden, ruft die Suchmaschine Dokumente ab, bewertet sie in der Reihenfolge der Relevanz und gibt die wichtigsten Ergebnisse zurück.

Die Abfrageausführung kann komplex sein. Dieser Artikel richtet sich an Entwickler, die ein tieferes Verständnis darüber benötigen, wie die Volltextsuche in Azure KI-Suche funktioniert. Bei Textabfragen liefert Azure KI-Suche in den meisten Szenarien nahtlos die erwarteten Ergebnisse. Gelegentlich erhalten Sie jedoch möglicherweise ein Ergebnis, das irgendwie unerwartet erscheint. In diesen Situationen können Sie mit einem Hintergrund in den vier Phasen der Abfrageausführung von Lucene (Abfrageanalyse, lexikalische Analyse, Dokumentabgleich und Bewertung) bestimmte Änderungen an Abfrageparametern oder indexkonfigurationen identifizieren, die das gewünschte Ergebnis erzeugen.

Architekturübersicht und Diagramm

Die Abfrageausführung umfasst vier Phasen:

1. Abfrageanalyse
2. Lexikalische Analyse
3. Abrufen von Dokumenten
4. Bewertung

Eine Volltextsuchabfrage beginnt mit der Analyse des Abfragetexts, um Suchbegriffe und Operatoren zu extrahieren. Es gibt zwei Parser, sodass Sie zwischen Geschwindigkeit und Komplexität wählen können. Als Nächstes wird eine Analysephase ausgeführt, in der einzelne Abfragebegriffe manchmal in neue Formulare aufgeteilt und wiederhergestellt werden. Dieser Schritt hilft dabei, eine größere Abdeckung für mehr potenzielle Übereinstimmungen zu erreichen. Die Suchmaschine durchsucht dann den Index, um Dokumente mit passenden Begriffen zu finden und bewertet jede Übereinstimmung. Ein Resultset wird dann nach einer Relevanzbewertung sortiert, die jedem einzelnen übereinstimmenden Dokument zugewiesen ist. Die in der Liste ganz oben aufgeführten Dokumente werden an die aufrufende Anwendung zurückgegeben.

Das folgende Diagramm veranschaulicht die Komponenten, die zum Verarbeiten einer Suchanforderung verwendet werden:

Anatomie einer Suchanfrage

Eine Suchanforderung ist eine vollständige Spezifikation, was in einem Resultset zurückgegeben werden soll. In ihrer einfachsten Form handelt es sich um eine leere Abfrage ohne Kriterien jeglicher Art. Ein realistischeres Beispiel enthält Parameter und mehrere Abfragebegriffe, die möglicherweise auf bestimmte Felder beschränkt sind, mit einem möglichen Filterausdruck und Sortierregeln.

Das folgende Beispiel ist eine Suchanforderung, die Sie mithilfe der API REST:

POST /indexes/hotels/docs/search?api-version=2026-04-01
{
    "search": "Spacious, air-condition* +\"Ocean view\"",
    "searchFields": "description, title",
    "searchMode": "any",
    "filter": "price ge 60 and price lt 300",
    "orderby": "geo.distance(location, geography'POINT(-159.476235 22.227659)')", 
    "queryType": "full" 
}

Für diese Anforderung führt die Suchmaschine die folgenden Vorgänge aus:

1. Sucht Dokumente, bei denen der Preis mindestens 60 $ und weniger als 300 $ beträgt.

2. Führt die Abfrage aus. In diesem Beispiel besteht die Suchabfrage aus Ausdrücken und Begriffen: "Spacious, air-condition* +\"Ocean view\"" (Benutzer geben normalerweise keine Interpunktion ein, aber durch die Einbeziehung in das Beispiel können wir erklären, wie Analysetools damit umgehen.)

   Bei dieser Abfrage durchsucht die Suchmaschine die in "searchFields" angegebenen Beschreibungs- und Titelfelder nach Dokumenten, die den Ausdruck "Ocean view" enthalten, und zusätzlich nach dem Ausdruck "spacious" oder nach Ausdrücken, die mit dem Präfix "air-condition" beginnen. Der Parameter „searchMode“ wird verwendet, um eine Übereinstimmung für einen beliebigen Begriff (Standard) oder alle Begriffe zu erzielen, wenn ein Begriff nicht explizit erforderlich ist (+).

3. Sortiert die resultierende Gruppe von Hotels anhand der Nähe zu einem bestimmten geografischen Standort und gibt dann die Ergebnisse an die aufrufende Anwendung zurück.

Der Großteil dieses Artikels befasst sich mit der Verarbeitung der Suchabfrage: "Spacious, air-condition* +\"Ocean view\"". Das Filtern und Sortieren ist nicht im Umfang enthalten. Weitere Informationen finden Sie in der Such-API-Referenzdokumentation.

Phase 1: Abfrageanalyse

Wie bereits erwähnt, ist die Abfragezeichenfolge die erste Zeile der Anforderung:

 "search": "Spacious, air-condition* +\"Ocean view\"", 

Der Abfrageparser trennt Operatoren (wie * und + im Beispiel) von Suchbegriffen und zerlegt die Suchanfrage in Unterabfragen, die einem unterstützten Typ entsprechen:

• Abfrage von Begriffen für eigenständige Begriffe (wie z.B. geräumig)
• Ausdrucksabfrage für zitierte Ausdrücke (z. B. Meerblick)
• Präfixabfrage für Begriffe gefolgt von einem Präfixoperator * (z. B. Klimaanlage)

Eine vollständige Liste der unterstützten Abfragetypen finden Sie unter Lucene-Abfragesyntax.

Operatoren, die einer Unterabfrage zugeordnet sind, bestimmen, ob die Abfrage "muss sein" oder "sollte" erfüllt sein, damit ein Dokument als Übereinstimmung betrachtet werden kann. +"Ocean view" „muss“ aufgrund des Operators + beispielsweise erfüllt sein.

Der Abfrageparser strukturiert die Unterabfragen in eine Abfragestruktur (eine interne Struktur, die die Abfrage darstellt), die sie an die Suchmaschine übergibt. In der ersten Phase der Abfrageanalyse sieht die Abfragestruktur wie folgt aus:

Unterstützte Parser: Simple und Full Lucene

Azure KI-Suche stellt zwei verschiedene Abfragesprachen zur Verfügung: simple (Standard) und full. Indem Sie den Parameter mit Ihrer Suchanforderung festlegen, teilen Sie dem queryType Abfrageparser mit, welche Abfragesprache Sie auswählen, damit sie weiß, wie die Operatoren und die Syntax interpretiert werden.

• Die Einfache Abfragesprache ist intuitiv und robust, häufig geeignet für die Interpretation von Benutzereingaben as-is ohne clientseitige Verarbeitung. Es unterstützt Abfrageoperatoren, die denjenigen ähneln, die von Websuchmaschinen bekannt sind.

• Die vollständige Lucene-Abfragesprache, die Sie durch Festlegen queryType=fullerhalten, erweitert die standardsprache "Einfache Abfrage" durch Hinzufügen der Unterstützung für weitere Operatoren und Abfragetypen wie Platzhalter, Fuzzy, Regex und Feldbereichsabfragen. Beispielsweise würde ein regulärer Ausdruck, der in der Syntax der einfachen Abfrage gesendet wird, als Abfragezeichenfolge und nicht als Ausdruck interpretiert. Die Beispielanforderung in diesem Artikel verwendet die Abfragesprache "Full Lucene".

Auswirkungen von searchMode auf den Parser

Ein weiterer Suchanforderungsparameter, der sich auf die Analyse auswirkt, ist der Parameter "searchMode". Er steuert den Standardoperator für boolesche Abfragen: irgendein (Standard) oder alle.

Bei „searchMode=any“, also der Standardeinstellung, lautet die Trennung zwischen „spacious“ und „air-condition“ OR (||), sodass der Text der Beispielabfrage Folgendem entspricht:

Spacious,||air-condition*+"Ocean view" 

Explizite Operatoren, z.B. + in +"Ocean view", sind in der booleschen Abfrage eindeutig (der Begriff muss übereinstimmen). Weniger offensichtlich ist, wie die übrigen Begriffe interpretiert werden: Geräumigkeit und Klimatisierung. Soll das Suchmodul nach Übereinstimmungen für „ocean view“ und „spacious“ und „air-condition“ suchen? Oder soll nach „ocean view“ und einem der beiden anderen Begriffe gesucht werden?

Standardmäßig ("searchMode=any") setzt die Suchmaschine die breitere Interpretation voraus. Eines der Felder sollte abgeglichen werden, wobei die "oder"-Semantik widergespiegelt wird. Die anfängliche Abfragestruktur, die zuvor mit den beiden "should"-Vorgängen veranschaulicht wurde, zeigt die Standardeinstellung an.

Angenommen, wir legen jetzt "searchMode=all" fest. In diesem Fall wird das Leerzeichen als "und"-Operation interpretiert. Beide verbleibenden Begriffe müssen im Dokument vorhanden sein, um als Übereinstimmung qualifiziert zu werden. Die resultierende Beispielabfrage würde wie folgt interpretiert:

+Spacious,+air-condition*+"Ocean view"

Eine geänderte Abfragestruktur für diese Abfrage, bei der ein übereinstimmende Dokument die Schnittmenge aller drei Unterabfragen ist, würde wie folgt aussehen:

Phase 2: Lexikalische Analyse

Lexikalische Analysegeräte verarbeiten Begriffsabfragen und Satzabfragen, nachdem die Abfragestruktur festgelegt ist. Ein Analyzer akzeptiert die vom Parser übergebenen Texteingaben, verarbeitet den Text und sendet dann tokenisierte Ausdrücke zurück, die in die Abfragestruktur integriert werden sollen.

Die gebräuchlichste Form der lexikalischen Analyse ist die linguistische Analyse, bei der Abfragebegriffe auf der Grundlage von sprachspezifischen Regeln transformiert werden. Dazu gehören:

• Reduzieren eines Abfrageausdrucks auf die Stammform eines Worts.
• Entfernen nicht wesentlicher Wörter (Stoppwörter, z. B. "das" oder "und" in Englisch).
• Aufteilen eines zusammengesetzten Worts in Komponententeile.
• Konvertieren eines groß geschriebenen Worts in ein klein geschriebenes Wort.

Alle diese Vorgänge neigen dazu, Unterschiede zwischen der vom Benutzer bereitgestellten Texteingabe und den im Index gespeicherten Begriffen zu löschen. Solche Vorgänge gehen über die Textverarbeitung hinaus und erfordern umfassende Kenntnisse der Sprache selbst. Um diese Ebene des sprachlichen Bewusstseins hinzuzufügen, unterstützt Azure KI-Suche eine lange Liste von language Analyzers von Lucene und Microsoft.

In unserem Beispiel enthält die erste Abfragestruktur vor der Analyse den Begriff „Spacious“ mit einem großen „S“ und einem Komma, das vom Abfrageparser als Teil des Abfrageausdrucks interpretiert wird (ein Komma wird nicht als Operator einer Abfragesprache angesehen).

Wenn der Standard-Analysator den Begriff verarbeitet, wird "Ozeanblick" und "geräumig" kleingeschrieben und das Kommazeichen entfernt. Die geänderte Abfragestruktur sieht wie folgt aus:

Testen des Analyseverhaltens

Das Verhalten eines Analyzers kann mithilfe der Analyse-API getestet werden. Geben Sie den Text an, den Sie analysieren möchten, um zu sehen, welche Begriffe der angegebene Analysator generiert. Um beispielsweise zu sehen, wie der Standardanalysator den Text "Klimaanlage" verarbeitet, können Sie die folgende Anforderung ausstellen:

{
    "text": "air-condition",
    "analyzer": "standard"
}

Die Standardanalyse teilt den Eingabetext in die folgenden beiden Token auf und fügt Attribute wie Start- und Endoffset (zur Hervorhebung von Treffern) und die Position (für den Wortgruppenabgleich) hinzu:

{
  "tokens": [
    {
      "token": "air",
      "startOffset": 0,
      "endOffset": 3,
      "position": 0
    },
    {
      "token": "condition",
      "startOffset": 4,
      "endOffset": 13,
      "position": 1
    }
  ]
}

Ausnahmen von lexikalischer Analyse

Lexikalische Analyse gilt nur für Abfragetypen, die vollständige Begriffe erfordern, entweder eine Term-Abfrage oder eine Phrasenabfrage. Sie gilt nicht für Abfragetypen mit unvollständigen Begriffen – Präfixabfrage, Wildcardabfrage und regex-Abfrage – oder für eine Fuzzy-Abfrage. Diese Abfragetypen, einschließlich der Präfixabfrage mit dem Ausdruck air-condition* in unserem Beispiel, werden direkt zur Abfragestruktur hinzugefügt, wobei die Analysestufe umgangen wird. Die einzige Transformation, die für Abfragebegriffe dieser Typen ausgeführt wird, ist die Kleinschreibung.

Phase 3: Dokumentabruf

Der Dokumentabruf bezieht sich auf das Suchen von Dokumenten mit übereinstimmenden Begriffen im Index. Diese Phase wird am besten durch ein Beispiel verstanden. Beginnen wir mit einem Hotelsindex mit dem folgenden einfachen Schema:

{
    "name": "hotels",
    "fields": [
        { "name": "id", "type": "Edm.String", "key": true, "searchable": false },
        { "name": "title", "type": "Edm.String", "searchable": true },
        { "name": "description", "type": "Edm.String", "searchable": true }
    ] 
} 

Gehen Sie weiter davon aus, dass dieser Index die folgenden vier Dokumente enthält:

{
    "value": [
        {
            "id": "1",
            "title": "Hotel Atman",
            "description": "Spacious rooms, ocean view, walking distance to the beach."
        },
        {
            "id": "2",
            "title": "Beach Resort",
            "description": "Located on the north shore of the island of Kauaʻi. Ocean view."
        },
        {
            "id": "3",
            "title": "Playa Hotel",
            "description": "Comfortable, air-conditioned rooms with ocean view."
        },
        {
            "id": "4",
            "title": "Ocean Retreat",
            "description": "Quiet and secluded"
        }
    ]
}

Wie Begriffe indiziert werden

Um den Abruf zu verstehen, hilft es ihnen, einige Grundlagen zur Indizierung zu kennen. Die Speichereinheit ist ein invertierter Index, eins für jedes durchsuchbare Feld. Innerhalb eines invertierten Indexes ist eine sortierte Liste aller Ausdrücke aus allen Dokumenten. Jeder Begriff ist der Liste der Dokumente zugeordnet, in denen er auftritt, wie im folgenden Beispiel ersichtlich.

Um die Begriffe in einem invertierten Index zu erzeugen, führt die Suchmaschine lexikalische Analysen über den Inhalt von Dokumenten durch, ähnlich wie bei der Abfrageverarbeitung:

1. Texteingaben werden an einen Analyzer übergeben, der sie je nach Konfiguration in Kleinbuchstaben umwandelt, Interpunktionszeichen entfernt und weitere Anpassungen vornimmt.
2. Token sind die Ausgabe lexikalischer Analysen.
3. Ausdrücke werden dem Index hinzugefügt.

Es ist üblich, aber nicht erforderlich, dieselben Analysegeräte für Such- und Indizierungsvorgänge zu verwenden, damit Abfragebegriffe eher wie Ausdrücke im Index aussehen.

Invertierter Index für Beispieldokumente

Wenn Sie zu unserem Beispiel zurückkehren, sieht der invertierte Index für das Titelfeld wie folgt aus:

Im Titelfeld wird nur das Hotel in zwei Dokumenten angezeigt: 1 und 3.

Für das Beschreibungsfeld sieht der Index wie folgt aus:

Abgleichen von Abfragebegriffen mit indizierten Ausdrücken

Angesichts der oben invertierten Indizes kehren wir zur Beispielabfrage zurück und sehen, wie übereinstimmende Dokumente für unsere Beispielabfrage gefunden werden. Denken Sie daran, dass die endgültige Abfragestruktur wie folgt aussieht:

Während der Abfrageausführung werden einzelne Abfragen unabhängig von den durchsuchbaren Feldern ausgeführt.

• Die TermQuery, "spacious", entspricht Dokument 1 (Hotel Atman).

• Das PrefixQuery-Element "Air-condition*" stimmt nicht mit Dokumenten überein.

  Dieses Verhalten verwirrt manchmal Entwickler. Obwohl der Begriff "klimatisiert" im Dokument vorhanden ist, wird er in zwei Begriffe durch den Standardanalysator aufgeteilt. Erinnern Sie sich daran, dass Präfixabfragen, die Teilbegriffe enthalten, nicht analysiert werden. Daher werden Begriffe mit dem Präfix "Klimaanlagen-" im invertierten Index nachgeschlagen und nicht gefunden.

• Die PhraseQuery, "Ozeanansicht", sucht nach den Begriffen "Ozean" und "Ansicht" und überprüft die Nähe von Begriffen im originalen Dokument. Dokumente 1, 2 und 3 stimmen mit dieser Abfrage im Beschreibungsfeld überein. Beachten Sie, dass Dokument 4 den Begriff "Ozean" im Titel hat, aber nicht als Übereinstimmung betrachtet wird, da wir nach dem Ausdruck "Ozeanansicht" und nicht nach einzelnen Wörtern suchen.

Insgesamt sind für die betreffende Abfrage die Dokumente, die übereinstimmen, 1, 2 und 3.

Phase 4: Bewertung

Jedem Dokument in einem Suchergebnissatz wird eine Relevanzbewertung zugewiesen. Die Funktion der Relevanzbewertung besteht darin, die Dokumente höher zu platzieren, die eine Benutzerfrage am besten beantworten, wie in der Suchanfrage ausgedrückt. Die Bewertung wird basierend auf statistischen Eigenschaften von Begriffen berechnet, die übereinstimmen. Im Kern der Bewertungsformel steht die Termfrequenz-Inverse Dokumenthäufigkeit (TF/IDF). In Abfragen mit seltenen und häufig verwendeten Ausdrücken fördert TF/IDF Ergebnisse, die den seltenen Begriff enthalten. Für einen hypothetischen Index mit allen Wikipedia-Artikeln gilt für Dokumente, für die die Abfrage the president durchgeführt wurde, beispielsweise Folgendes: Dokumente, die Übereinstimmungen für president enthalten, werden mit einer höheren Relevanz als Dokumente versehen, die Übereinstimmungen für the enthalten.

Bewertungsbeispiel

Rufen Sie die drei Dokumente zurück, die mit unserer Beispielabfrage übereinstimmen:

search=Spacious, air-condition* +"Ocean view"  

{
  "value": [
    {
      "@search.score": 0.25610128,
      "id": "1",
      "title": "Hotel Atman",
      "description": "Spacious rooms, ocean view, walking distance to the beach."
    },
    {
      "@search.score": 0.08951007,
      "id": "3",
      "title": "Playa Hotel",
      "description": "Comfortable, air-conditioned rooms with ocean view."
    },
    {
      "@search.score": 0.05967338,
      "id": "2",
      "title": "Ocean Resort",
      "description": "Located on a cliff on the north shore of the island of Kauai. Ocean view."
    }
  ]
}

Dokument 1 entsprach der Abfrage am besten, da sowohl der Begriff geräumig als auch die erforderliche Phrase Meerblick im Beschreibungsfeld vorkommen. Die nächsten beiden Dokumente entsprechen nur dem Ausdruck Ozeanansicht. Möglicherweise sind Sie überrascht, dass die Relevanzbewertungen für Dokumente 2 und 3 unterschiedlich sind, obwohl sie mit der Abfrage auf die gleiche Weise übereinstimmen. Das liegt daran, dass die Bewertungsformel mehr Komponenten aufweist als nur TF/IDF. In diesem Fall wurde Dokument 3 ein etwas höheres Bewertungsergebnis zugewiesen, da die Beschreibung kürzer ist. Erfahren Sie mehr über die praktische Bewertungsformel von Lucene , um zu verstehen, wie die Feldlänge und andere Faktoren die Relevanzbewertung beeinflussen können.

Einige Abfragetypen (Wildcard, Präfix und Regex) tragen immer zu einer konstanten Punktzahl in der Gesamtbewertung des Dokuments bei. Dadurch können Übereinstimmungen, die durch die Abfrageerweiterung gefunden werden, in die Ergebnisse aufgenommen werden, ohne dass sich dies auf die Rangfolge auswirkt.

Ein Beispiel zeigt, warum dies wichtig ist. Platzhaltersuchen, einschließlich Präfixsuchen, sind per Definition mehrdeutig, da die Eingabe eine Teilzeichenfolge mit potenziellen Übereinstimmungen für eine sehr große Anzahl unterschiedlicher Begriffe ist. Stellen sich die Eingabe „tour*“ vor, für die Übereinstimmungen mit „Touren“, „Tourette“ und „Tourist“ gefunden werden. Angesichts der Natur dieser Ergebnisse gibt es keine Möglichkeit, vernünftigerweise zu ableiten, welche Begriffe wertvoller sind als andere. Aus diesem Grund ignorieren wir Begriffshäufigkeiten beim Bewerten von Abfragen des Typs Wildcard, Präfix und Regex. Bei einer mehrteiligen Suchanfrage, die Teilbegriffe und vollständige Begriffe enthält, werden Ergebnisse aus der Teileingabe mit einer konstanten Bewertung eingebunden, um die Bevorzugung von potenziell unerwarteten Übereinstimmungen zu vermeiden.

Relevanzoptimierung

Es gibt zwei Möglichkeiten, Relevanzbewertungen in Azure KI-Suche zu optimieren:

• Bewertungsprofile stufen Dokumente in der Rangfolgenliste der Ergebnisse höher, basierend auf einer Gruppe von Regeln. In unserem Beispiel könnten wir Dokumente berücksichtigen, die im Titelfeld relevanter sind als Dokumente, die im Beschreibungsfeld übereinstimmen. Wenn unser Index ein Preisfeld für jedes Hotel hatte, könnten wir Dokumente mit niedrigeren Preisen bewerben. Erfahren Sie mehr über das Hinzufügen von Bewertungsprofilen zu einem Suchindex.

• Das Term-Boosting (nur in der vollständigen Lucene-Abfragesyntax verfügbar) stellt einen Verstärkungsoperator ^ bereit, der auf einen beliebigen Teil des Abfragebaums angewendet werden kann. In unserem Beispiel könnte man anstelle der Suche nach dem Präfix "Klimaanlage*" entweder nach dem exakten Ausdruck "Klimaanlage" oder nach dem Präfix suchen, aber Dokumente, die mit dem exakten Ausdruck übereinstimmen, werden höher bewertet, indem ein Boost auf die Suchanfrage angewendet wird: Klimaanlage^2||Klimaanlage*. Weitere Informationen zum „Term Boosting“ einer Abfrage.

Bewertung in einem verteilten Index

Alle Indizes in Azure KI-Suche werden automatisch in mehrere Shards aufgeteilt, sodass wir den Index während der Dienstskalierung nach oben oder unten schnell auf mehrere Knoten verteilen können. Wenn eine Suchanforderung ausgestellt wird, wird sie für jeden Shard unabhängig ausgestellt. Die Ergebnisse der einzelnen Shards werden dann nach Score zusammengeführt und sortiert (wenn keine andere Sortierung definiert ist). Es ist wichtig, dass Sie Folgendes wissen: Die Bewertungsfunktion wägt die Vorkommenshäufigkeit von Abfragebegriffen gegenüber der inversen Dokumenthäufigkeit für alle Dokumente des Shards ab. Nicht übergreifend für alle Shards!

Dies bedeutet, dass eine Relevanzbewertung für identische Dokumente unterschiedlich sein könnte , wenn sie sich auf verschiedenen Shards befinden. Glücklicherweise verschwinden solche Unterschiede tendenziell, da die Anzahl der Dokumente im Index aufgrund einer gleichmäßigeren Begriffsverteilung wächst. Es ist nicht möglich, davon auszugehen, auf welchen Shard ein bestimmtes Dokument platziert wird. Wenn sich ein Dokumentschlüssel jedoch nicht ändert, wird er immer derselben Shard zugewiesen.

Im Allgemeinen ist die Dokumentbewertung nicht das beste Attribut zum Sortieren von Dokumenten, wenn die Reihenfolgestabilität wichtig ist. Wenn z. B. zwei Dokumente mit einer identischen Bewertung vorhanden sind, besteht keine Garantie dafür, dass ein Dokument zuerst in nachfolgenden Ausführungsläufen derselben Abfrage angezeigt wird. Die Dokumentbewertung sollte nur einen allgemeinen Überblick über die Dokumentrelevanz im Verhältnis zu anderen Dokumenten im Resultset geben.

Schlussfolgerung

Der Erfolg kommerzieller Suchmaschinen hat erwartungen an die Volltextsuche über private Daten erhöht. Für fast jede Art von Sucherfahrung erwarten wir jetzt, dass die Engine unsere Absicht versteht, auch wenn Ausdrücke falsch geschrieben oder unvollständig sind. Möglicherweise erwarten wir sogar Übereinstimmungen basierend auf ähnlichen Begriffen oder Synonymen, die wir nie angegeben haben.

Aus technischer Sicht ist die Volltextsuche hochkomplex und erfordert anspruchsvolle linguistische Analysen und einen systematischen Ansatz zur Verarbeitung in der Art und Weise, wie Abfragebegriffe destilliert, erweitert und transformiert werden, um ein relevantes Ergebnis zu liefern. Angesichts der inhärenten Komplexitäten gibt es viele Faktoren, die das Ergebnis einer Abfrage beeinflussen können. Aus diesem Grund bringt die Investition von Zeit, um die Mechanik der Volltextsuche zu verstehen, greifbare Vorteile, wenn man versucht, unerwartete Ergebnisse zu verstehen.

In diesem Artikel wurde die Volltextsuche im Kontext von Azure KI-Suche untersucht. Wir hoffen, dass es Ihnen genügend Hintergrund gibt, um potenzielle Ursachen und Lösungen für die Behandlung allgemeiner Abfrageprobleme zu erkennen.

Nächste Schritte

• Erstellen Sie den Beispielindex, probieren Sie verschiedene Abfragen aus, und überprüfen Sie die Ergebnisse. Anweisungen finden Sie unter Erstellen und Abfragen eines Indexes im Azure-Portal.

• Probieren Sie eine andere Abfragesyntax aus dem Search Documents Beispielabschnitt oder aus Simple-Abfragesyntax im Such-Explorer im Azure-Portal aus.

• Überprüfen Sie bewertungsprofile , wenn Sie die Rangfolge in Ihrer Suchanwendung optimieren möchten.

• Wenden Sie sprachspezifische lexikalische Analysegeräte an.

• Konfigurieren Sie benutzerdefinierte Analysatoren entweder für minimale Verarbeitung oder spezielle Verarbeitung auf bestimmten Feldern.

Verwandte Inhalte

• REST-API für Dokumente durchsuchen

• Einfache Abfragesyntax

• Vollständige Lucene-Abfragesyntax

• Behandeln von Suchergebnissen