Optimieren der Kosten für das Serverless-Preismodell in Azure KI-Suche

Azure KI-Suche unterstützt zwei Preismodelle, die jeweils für unterschiedliche Workloadmuster ausgelegt sind:

• Dedicated: Feste Preise, die anhand der Sucheinheiten (SUs) bemessen werden. Sie wählen eine Dienstebene aus, und Sie werden stündlich abgerechnet, basierend auf bereitgestellten Einheiten.

• Serverless (Vorschau): Verbrauchsbasierte Preisgestaltung basierend auf Compute-Einheiten pro Stunde (CU/hr) und pro GB/Monat für indizierten Speicher.

Weitere Informationen zu Preismodell- und Dienstebenenunterschieden finden Sie unter Auswählen eines Preismodells und einer Serviceebene.

Wie die Kosten im Serverless-Modell bestimmt werden

Die Preismodelle "Dedicated" und "Serverless" berücksichtigen die Arbeit innerhalb des Suchdiensts unterschiedlich. Dedizierte Dienste führen Abfragen, Indizierung und Ergebnisverarbeitung auf der bereitgestellten Kapazität aus, die Sie bereits erworben haben. Serverless-Dienste messen den Rechen-, Arbeitsspeicher- und Datenträger-E/A-Aufwand, den diese Vorgänge verbrauchen, und rechnen diese Nutzung in Compute Units (CUs) um. Daher wirkt sich die Leistungsoptimierung direkt auf serverlose Kosten aus.

Serverlose Kosten sind an die Workloadausführung gebunden:

• Abfragen und Indizierung verbrauchen Rechenleistung, gemessen in Compute Units pro Stunde (CU/h).
• Aktive Indizes verbrauchen Rechenressourcen abhängig von ihrer Ressourcennutzung und davon, wie lange sie aktiv bleiben.
• Ein Index bleibt 10 Minuten nach der letzten Abfrage oder Indizierungsanforderung aktiv, bevor er inaktiv wird.
• Inaktive Indizes haben keine minimale oder reservierte Berechnungsgebühr. Die Berechnungsauslastung für inaktive Indizes wird auf Null skaliert. Es gibt keine minimale Berechnungsgebühr, wenn ein Index inaktiv ist.
• Der Speicher wird separat auf Grundlage der Indexgröße auf dem Datenträger abgerechnet, und die Abrechnung läuft weiter, unabhängig davon, ob ein Index verwendet wird oder nicht.
• Die agentenbasierte Suche verbraucht Rechenleistung für Suchabfragen und für die Orchestrierung innerhalb des Suchdiensts.

Speichergebühren werden nur beendet, wenn Sie den Index löschen.

Wenn Sie die Kostenaufschlüsselung und die Nutzungssätze für Ihren aktuellen Abrechnungszyklus anzeigen möchten, zeigen Sie die Registerkarte "Skalierung + Kosten" in Ihrem Azure-Portal an.

Wie sich die Indexgröße auf die Rechennutzung auswirkt

Während ein Index aktiv ist, wertet Azure KI-Suche zwei endliche Ressourcen aus, um die Berechnungsnutzung zu bestimmen:

• Gesamtindexgröße: Der Gesamtspeicherplatz, den der Index auf dem Datenträger belegt, einschließlich Text, Metadaten und Vektoren.
• Vektorindexgröße: Der vom Vektorindex verwendete Speicher. Der Speicher ist ressourcenintensiver als der Datenträger, sodass die Größe des Vektorindex bei der Konvertierung in CUs eine höhere Gewichtung aufweist.

Azure KI-Suche addieren die beiden resultierenden CU-Beträge nicht zusammen. Die Berechnungsauslastung basiert auf dem höheren Betrag. Beispielsweise kann die Vektorindexgröße die Berechnungsauslastung bestimmen, auch wenn die Gesamtindexgröße auf dem Datenträger relativ klein ist.

Um die Auslastung der Aktiven Indexberechnung zu reduzieren, identifizieren Sie, welche Ressource den höheren CU-Wert erzeugt. Reduzieren Sie dann die Gesamtindexgröße, die Vektorindexgröße oder beides. Der indizierte Speicher bleibt eine separate Gebühr pro GB/Monat.

Das Serverless-Preismodell ist für Workloads mit variablem, intermittierenden oder unvorhersehbaren Datenverkehr am kostengünstigsten, wobei die bereitgestellte Kapazität unterlastet wäre.

Grundlegendes zu Computeeinheiten (CUs)

Eine Compute Unit (CU) stellt die gemessenen Systemressourcen dar, die zum Ausführen von Such- und Indizierungsvorgängen im Serverless-Modell erforderlich sind. Die CU-Kosten werden in erster Linie durch die Auslastung von CPU, Arbeitsspeicher und E/A sowie in zweiter Linie durch die Indexgröße und die Größe der Dokumentnutzlast bestimmt, wobei die Nutzung pro Compute Unit und Stunde (CU/h) abgerechnet wird.

Berechnen von Kostenskalen mit:

• Abfragekomplexität
• Indexgröße (GB) und Struktur
• Dokumentnutzlastgröße (KB)
• Anzahl der Felder und abgerufenen Ergebnisse

Verschiedene Vorgänge weisen unterschiedliche Kostenprofile auf:

• Suche: Geringe Kosten. Das Abrufen eines einzelnen Dokuments anhand seiner ID ist der effizienteste Vorgang.
• Stichwortsuche: Niedrige Kosten. Bei der Textsuche werden invertierte Indizes verwendet, die für geschwindigkeits- und niedrige Berechnungsauslastung optimiert sind.
• Vektorsuche: Hohe Kosten. Vektorabfragen sind rechenintensiv, da sie Ähnlichkeitsberechnungen für hochdimensionale Einbettungen erfordern. Im Vergleich zur Schlüsselwortsuche verbrauchen sie deutlich mehr Compute.
• Hybridsuche: Kombiniert die Kosten von Schlüsselwortsuche und Vektorsuche, da beide Pipelines für jede Abfrage ausgeführt werden, plus einen kleinen zusätzlichen Aufwand für Reciprocal Rank Fusion (RRF) zur Zusammenführung der Ergebnisse.

Rechenauslastung überwachen

Die Überwachung des Berechnungsverbrauchs hilft Ihnen, teure Vorgänge zu identifizieren, Abfragemuster zu optimieren und Kosten zu schätzen. Die Kosten pro Compute-Einheit (CU) für jede Anforderung werden im HTTP-Antwortheader x-ms-azs-compute-units-consumed als Gleitkommazahl zurückgegeben. Verwenden Sie diesen Header, um teure Vorgänge zu identifizieren und Abfragemuster zu optimieren. Sie können die CU-Kosten jeder Anforderung nachverfolgen, indem Sie die HTTP-Antwortheader und Vorgangsereignisse in Azure Monitor überprüfen. Weitere Informationen zu den verfügbaren Arten von Überwachungsdaten und zu Methoden zum Analysieren dieser Daten finden Sie unter Überwachen von Azure KI-Suche.

• Header:x-ms-azs-compute-units-consumed: <value>
• Wert: Eine Gleitkommazahl, die die verbrauchten CUs darstellt.

Beispiel:

Status: 200 OK
Content-Type: application/json
x-ms-azs-compute-units-consumed: 12.45

In diesem Beispiel verbrauchte die Anforderung 12,45 Computeeinheiten. Sie können diesen Wert verwenden, um Vorgänge mit hohen Kosten zu identifizieren und die relativen Kosten verschiedener Abfragemuster zu vergleichen.

Um die historische Rechennutzung für einen serverlosen Suchdienst zu überprüfen, verwenden Sie die Metriken in Azure Monitor im Azure-Portal:

1. Navigieren Sie zu Ihrem Suchdienst.
2. Klicken Sie auf Metriken.
3. Wählen Sie + Metrik hinzufügen.
4. Wählen Sie in der Metrikliste Auslastung der Compute-Einheiten aus.
5. Verwenden Sie das Diagramm, um Nutzungstrends zu analysieren und Zeiträume mit erhöhter Berechnungsauslastung zu identifizieren.

Die Überwachung der aggregierten Nutzung hilft Ihnen, die Allgemeinen Dienstkosten zu verstehen und Workloads zu identifizieren, die die meisten Computeressourcen verbrauchen. Beschreibungen der verfügbaren Überwachungsmetriken finden Sie unter Monitoring Data Reference. Sie können Azure Monitor Protokolle verwenden, um die aggregierte CU-Nutzung im Laufe der Zeit nachzuverfolgen und mit Abfragevolumen- und Workloadänderungen zu korrelieren.

Konfigurieren Sie Warnungen für die Rechennutzung

Sie können eine Warnungsregel erstellen, die benachrichtigt werden soll, wenn der Berechnungsverbrauch einen angegebenen Schwellenwert im Azure-Portal erreicht.

1. Wechseln Sie zu "Benachrichtigungen " in Ihrem Suchdienst.
2. Wählen Sie + Warnungsregel erstellen aus.
3. Wählen Sie unter Bedingung die Nutzung der Recheneinheiten als Signal aus.
4. Definieren Sie die Warnungslogik. Wird beispielsweise ausgelöst, wenn die Gesamtnutzung größer als ein angegebener Wert ist.
5. Konfigurieren von Aktionen, z. B. E-Mail-, SMS- oder Webhook-Benachrichtigungen.
6. Führen Sie die verbleibenden Schritte aus, und wählen Sie "Überprüfen+ Erstellen" aus.

Warnungen helfen Ihnen dabei, proaktiv auf unerwartete Nutzungsspitzen zu reagieren und Kosten zu verwalten.

Schätzung der serverlosen Kosten

Der Azure-Preisrechner und die auf Search Units (SU) basierende Anleitung zur Kapazitätsplanung gelten nicht für Dienste, die das serverlose Preismodell verwenden.

So schätzen Sie serverlose Kosten:

1. Indizieren Sie repräsentative Musterdaten.
2. Führen Sie typische Indizierungs- und Abfrageworkloads aus.
3. Notieren Sie den x-ms-azs-compute-units-consumed für jeden Vorgang zurückgegebenen Wert.
4. Verwenden Sie Azure Monitor Metriken, um die aggregierte Nutzung im Laufe der Zeit zu messen.
5. Extrapolieren Sie die Kosten basierend auf dem erwarteten Produktionsverkehr.

Verwenden Sie die Registerkarte "Skalieren + Kosten" im Azure-Portal, um Ihre aktuellen Nutzungs- und Kostenschätzungen anzuzeigen.

Da dieselbe Anforderung mit denselben Daten im Allgemeinen einen ähnlichen Berechnungsverbrauch erzeugt, können repräsentative Workloads eine zuverlässige Grundlage für die Kostenschätzung bieten.

Die serverlose Nutzung wird kontinuierlich gemessen und für die Abrechnung aggregiert. Der Berechnungsverbrauch wird in jeder Minute nachverfolgt und nur ausgegeben, wenn Rechenressourcen verwendet werden.

Verwenden Sie bei der Kostenschätzung die Werte der Anforderungsgebühr, um die Kosten einzelner Vorgänge zu verstehen, und Azure Monitor-Metriken, um allgemeine Verbrauchsmuster des Diensts zu verstehen.

Verwenden Sie beide Datenquellen zusammen, um Kosten zu verstehen: Daten pro Anforderung helfen Ihnen bei der Auswertung einzelner Vorgänge, während Azure Monitor Metriken Ihnen helfen, den aggregierten Dienstverbrauch im Laufe der Zeit zu verstehen. Berücksichtigen Sie für ein vollständiges Kostenbild auch Features, die separat von Compute Units in Rechnung gestellt werden.

Die Abrechnung basiert auf der aggregierten Computenutzung und nicht auf einzelnen Anforderungen. Die Nutzung wird in Intervallen von einer Minute gemessen und auf die nächsten 0,25 CU je Minute aufgerundet. Diese einminütigen Nutzungsintervalle sammeln sich im Laufe einer Stunde an, um den abrechnungsfähigen KU/Stundenbetrag zu ermitteln. Intern werden Nutzungswerte von Milli-Compute-Einheiten (mCU) zu Compute-Einheiten (CU) aggregiert und in die stündliche, für die Abrechnung ausgewiesene Nutzung umgerechnet.

Unterschiedliche Vorgänge verbrauchen unterschiedliche Berechnungsmengen. Im Allgemeinen:

• Schlüsselwortsuchen verwenden in der Regel die am wenigsten berechneten Ressourcen.
• Vektorsuchen verwenden in der Regel mehr Computeressourcen als Stichwortsuchen.
• Hybridsuchen kombinieren Die Ausführung von Schlüsselworten und Vektorsuchvorgängen, sodass sie in der Regel mehr Computeressourcen als beide Techniken allein verwenden.

Die tatsächliche Berechnungsauslastung hängt von Faktoren wie Abfragekomplexität, Indexgröße, Datenvolumen, Vektorkonfiguration und der Anzahl der zurückgegebenen Ergebnisse ab. Die Überwachung von Anforderungsgebühren und aggregierten Nutzungsmetriken kann Ihnen helfen, Optimierungsmöglichkeiten zu identifizieren und Produktionskosten besser vorherzusagen.

Reduzieren der Berechnungskosten durch Optimierung

Effiziente Abfragen und Indexdesign reduzieren den Berechnungsverbrauch und senken die Kosten.

Optimieren Ihres Schemas

Ihr Indexschema bestimmt die geplanten Berechnungs- und Speicherkosten:

• Feldattribute begrenzen: Aktivieren Sie Attribute (durchsuchbar, filterbar, facettierbar, sortierbar) nur bei Bedarf. Jedes Attribut erhöht die Indexgröße und die Indizierungskosten.
• Vereinfachen komplexer Typen: Ordnen Sie verschachtelte JSON-Strukturen einfachen Feldern oder Sammlungen zu, sofern dies möglich ist.
• Legen Sie für Felder, die nur zum Filtern oder Sortieren dienen, retrievable=false fest: Wenn ein Feld zum Filtern oder Sortieren verwendet wird, aber nicht in den Ergebnissen zurückgegeben werden muss, lassen Sie es indiziert und setzen Sie retrievable=false, um den Speicherplatz auf dem Datenträger sowie die Speicherkosten pro GB und Monat zu reduzieren.
• Verwenden Sie nur abrufbare Felder, wenn möglich: Beispielsweise sollten Felder, die nur für die Anzeige (z. B. Bild-URLs) verwendet werden, nicht durchsuchbar sein.
• Reduzieren Sie die Vektordimensionen: Höherdimensionale Vektoren erhöhen die Speicher- und Abfragekosten. Verwenden Sie bei Bedarf kleinere Einbettungsmodelle oder Quantisierungen.
• Minimieren Sie die Größe der Dokumentnutzlast vor der Indizierung: Größere Dokumente kosten mehr zum Indizieren. Entfernen Sie unnötige Felder, kürzen Sie langen Text, und entfernen Sie HTML,bevor Sie Dokumente an den Index senden.

Optimieren von Indizierungsanforderungen

Wie Sie Daten an den Index senden, wirkt sich sowohl auf Kosten als auch auf den Durchsatz aus:

• Verwenden Sie nach Möglichkeit größere Batches: Die Batchindizierung reduziert den Aufwand pro Anforderung, indem Netzwerk- und Verarbeitungskosten in mehr Dokumenten verteilt werden. Im Allgemeinen sind Batches von bis zu ca. 1.000 Dokumenten oder ~16 MB cueffizienter als viele kleine Anforderungen. Die optimale Batchgröße hängt jedoch von Ihrer Workload ab. Testen Sie, um Durchsatz, Latenz und Zuverlässigkeit auszubalancieren.

• Indizieren Sie nur neue oder geänderte Daten: Vermeiden Sie nach Möglichkeit ein vollständiges Neuindizieren. Durch das Senden von Ergänzungen und Updates wird die Anzahl der verarbeiteten Dokumente reduziert, die Berechnungskosten gesenkt und die Aufnahmegeschwindigkeit verbessert.

• Überspringen Sie die Bildextraktion, wenn Sie sie nicht benötigen: Die Bildextraktion verursacht zusätzlichen Verarbeitungsaufwand und kann zu einem separaten Kostenfaktor werden. Aktivieren Sie sie nur für Dokumente oder Workflows, die tatsächlich Bildinhalte benötigen.

• Berücksichtigen Sie das Wachstum der Indexgröße: Erstellen Sie nach Möglichkeit kleinere Indizes. Da ein Index wächst, steigen die Indizierungskosten, da mehr Daten gespeichert und verwaltet werden müssen, und Vorgänge erfordern mehr Berechnung. Bei sehr großen Datasets sollten Sie die Partitionierung von Daten über mehrere Indizes hinweg in Betracht ziehen, um die Leistung und Kosten zu verwalten. Obwohl die Kosten mit der Indexgröße steigen, ist die Erhöhung teillinear. Größere Indizes kosten mehr pro Vorgang, aber nicht proportional mehr.

Weitere Anleitungen finden Sie unter Tips für eine bessere Leistung in Azure KI-Suche.

Optimieren von Indexervorgängen

Die Rechenauslastung des serverless Indexers hängt von der während jeder Ausführung ausgeführten Arbeit ab. Verwenden Sie für zeilenorientierte Quellen die Anzahl der Dokumente, die als Indikator für das Arbeitsauslastungsvolumen verarbeitet wurden. Überwachen Sie für dateibasierte Quellen wie Azure Blob Storage und Azure Data Lake Storage Gen2 die Menge der verarbeiteten Quelldaten. Die tatsächliche Berechnungsauslastung hängt auch von Dokumentnutzlasten, Indexstruktur, Anreicherung und anderer Verarbeitung ab, die während der Ausführung ausgeführt werden.

So reduzieren Sie die Rechenauslastung des Indexers:

• Verwenden Sie die Änderungserkennung und inkrementelle Indizierung: Verarbeiten Sie nur neue oder geänderte Daten, anstatt die vollständige Datenquelle wiederholt indizieren zu müssen.

• Indexerzeitpläne richtig dimensionieren: Wählen Sie einen Zeitplan aus, der Ihren Anforderungen an die Datenaktualität entspricht. Verwenden Sie Compute Unit-Telemetrie, um die Auswirkungen der Zeitplanhäufigkeit auszuwerten.

• Reduzieren Sie unnötige Dokumentinhalte: Entfernen Sie Inhalte, die nicht indiziert werden müssen, und schließen Sie Dateien oder Dateitypen aus, die nicht erforderlich sind.

• Den Einsatzbereich von Anreicherungsskills sorgfältig festlegen: Führen Sie Skills nur für Felder und Dokumente aus, die eine Anreicherung erfordern, und vermeiden Sie es, Ausgaben zu erzeugen, die in nachgelagerten Prozessen nicht verwendet werden. Rechnungsfähige Fähigkeiten können separate Transaktionsgebühren verursachen.

• Fehlgeschlagene und wiederholte Ausführungen überwachen: Ein Indexer kann Rechenleistung für Arbeiten verbrauchen, die vor dem Fehlschlag abgeschlossen wurden. Überprüfen Sie den Ausführungsverlauf und die Verwendung der Computeeinheit, um wiederkehrende Fehler und Wiederholungsmuster zu identifizieren.

Optimieren Ihrer Abfragen

Abfrageentwurf ist ein primärer Treiber für variable Kosten:

• Verwenden Sie $select, um die zurückgegebenen Felder zu begrenzen: Dadurch werden die Nutzlastgröße und der für die Serialisierung erforderliche Rechenaufwand reduziert.

  GET /docs?search=test&$select=id,title,url
  

• Wird searchFields verwendet, um zu begrenzen, wo Text durchsucht wird: Einschränken des Abfragezeitabgleichs mit den Feldern, die für das Szenario wichtig sind. Jedes zusätzliche durchsuchbare Feld erhöht die Abfragearbeit und kann CU/h erhöhen.

• Bevorzugen Sie genaue Übereinstimmungs- oder einfache Stichwortabfragen: Fuzzy-, Wildcard-, Regex- und Präfix-Abfragen können allgemeine Indexüberprüfungen erzwingen und deutlich mehr CU/h verbrauchen. Verwenden Sie sie nur, wenn Sie partielles Abgleichsverhalten benötigen, und wählen Sie nach Möglichkeit genaue Übereinstimmungs- oder einfachere Stichwortabfragen aus.

• Verwenden Sie Nachschlagevorgänge anstelle von Suchvorgängen, wenn möglich: Das Abrufen eines Dokuments nach ID ist effizienter als das Ausführen einer Suchabfrage. Wenn Sie die Dokument-ID kennen, verwenden Sie eine Nachschlagefunktion anstelle einer Suchabfrage. Nachschlagevorgänge sind effizienter, da sie ein Dokument direkt nach Schlüssel abrufen, während Suchabfragen die vollständige Abfragepipeline aufrufen (Analyse, Indexdurchlauf, Bewertung und Rangfolge), wodurch die Berechnungskosten erhöht werden.

• Vermeiden Sie tiefes Paging ($skip): Große $skip-Werte erhöhen den Rechenaufwand, da die Engine die Ergebnisse verarbeiten, bewerten und einordnen muss, die vor der angeforderten Seite liegen. Zum Beispiel erfordert $skip=5000, dass die Engine mindestens 5.000 Ergebnisse verarbeitet, die nicht zurückgegeben werden. Diese Wahl verbraucht zusätzliche Recheneinheiten (CUs) und kann die Kosten erhöhen. Verwenden Sie stattdessen Filter, um das Ergebnis set einzuschränken und $top die Anzahl der zurückgegebenen Ergebnisse einzuschränken. Passende Größe $top für Ihre Anwendung oder Benutzeroberfläche. Obwohl $top nichts daran ändert, wie viele übereinstimmende Dokumente bewertet werden, verringert ein kleinerer Wert die Anzahl der Ergebnisse, die erfasst, sortiert und serialisiert werden müssen. Fordern Sie nur so viele Ergebnisse an, wie Ihre Anwendung benötigt, und vermeiden Sie Paginierungsmuster, die die Engine dazu zwingen, große Mengen nicht verwendeter Ergebnisse zu verarbeiten.

• Minimieren Sie die Facetanzahl und den Facetbereich: Fordern Sie nur die Facets an, die in der Benutzeroberfläche angezeigt werden, und behalten Sie jeden Facetwert count so niedrig wie praktisch. Facets erfordern Aggregationen pro Abfrage, und hohe Anzahlen erhöhen den Rechenaufwand.

• Verwenden Sie search.in zum Filtern: Wenn Sie nach einer Liste von IDs oder Werten filtern, verwenden Sie die search.in-Funktion anstelle mehrerer or-Bedingungen (z. B. id eq '1' or id eq '2'). Dieser Ansatz ist effizienter und reduziert den Rechenaufwand. Außerdem sollten Sie es vermeiden, Felder mit hoher Kardinalität (d. h. Felder mit einer großen Anzahl eindeutiger Werte, wie z. B. eindeutigen IDs oder Freitextbeschreibungen) als filterbar oder facettierbar zu markieren, sofern es nicht erforderlich ist. da dies die Indexgröße und die Abfragekosten erhöht.

Optimieren Sie Ihre administrativen Anfragen

Zusätzlich zu Abfrage- und Indizierungsvorgängen umfasst Azure KI-Suche Verwaltungsvorgänge auf Objektebene und Verwaltungsvorgänge auf Dienstebene (z. B. Abrufen von Indexschemas oder Dienststatistiken). Diese Anfragen haben pauschale Kosten pro Anfrage. Während jede Anforderung kostengünstig ist, können sich wiederholte oder unnötige Aufrufe im Laufe der Zeit ansammeln und die allgemeine Berechnungsauslastung erhöhen.

• Vermeiden Sie übermäßige administrative Anforderungen: Zwischenspeichern von Metadaten, z. B. Indexschemas, auf der Clientseite, anstatt sie wiederholt abzurufen. Beispielsweise führt das Abrufen des Indexschemas vor jedem Schreibvorgang zu unnötigen Kosten. Im Serverless-Modell erhöht dieses Muster die Berechnungsgebühren direkt, während die Auswirkungen in dedizierten Diensten häufig durch feste stundenweise Abrechnung ausgeblendet werden.

Vektorkosten optimieren

Vektor-Workloads stellen für das serverlose Preismodell bei der Suche in der Regel die kostenintensivste Komponente dar, da sie sich sowohl auf die Compute-Einheiten (Abfragen und Indizierung) als auch auf den Speicher (Vektorgröße auf dem Datenträger) auswirken. Um die Kosten zu reduzieren, optimieren Sie sowohl, wie Vektoren gespeichert werden, als auch wie sie abgefragt werden.

Optimieren von Vektorspeicher und -schema

Vektorfelder können die Indexgröße und die Indizierungskosten erheblich erhöhen. Verwenden Sie die folgenden Techniken, um den Speicheraufwand zu reduzieren:

• Verwenden Sie die Komprimierung, um die Vektorgröße zu reduzieren: Wenden Sie die Quantisierung an, um den Speicherbedarf mit minimaler Relevanz zu reduzieren. Die skalare Quantisierung kann z. B. die Vektorspeicherung um bis zu 4× mit minimalen Auswirkungen auf die Suchqualität reduzieren.

• Deaktivieren Sie den Speicher für Vektoren, wenn sie nicht benötigt werden: Legen Sie "stored=false" für Vektorfelder fest, wenn Sie nur Vektoren für die Suche benötigen, nicht abrufen. Dadurch wird verhindert, dass die ursprünglichen Vektoren im Index gespeichert werden, wodurch die Speicherkosten reduziert werden, ohne das Abfrageverhalten zu beeinträchtigen.

• Verwenden Sie nach Möglichkeit kleinere Einbettungsmaße: Höhere dimensionale Vektoren erhöhen sowohl Speicher- als auch Abfragekosten. Verwenden Sie für nicht kritische Workloads kleinere Einbettungsmodelle (z. B. 384 oder 768 Dimensionen anstelle von 1536), um Kosten zu reduzieren.

Optimieren der Vektorabfrageausführung

Vektorabfragen sind rechenintensiv, da sie Ähnlichkeitsberechnungen über hochdimensionale Datenstrukturen erfordern.

• Selektive Verwendung der Hybridsuche: Hybridabfragen führen schlüsselwort- und Vektorabrufe aus. Wird nur verwendet, wenn dies für die Relevanz erforderlich ist.

• maxTextRecallSize bei Hybridabfragen verringern: Die hybridSearch.maxTextRecallSize Einstellung steuert, wie viele nach BM25 eingestufte Ergebnisse in die Reciprocal Rank Fusion einfließen. Der Standardwert ist 1.000 (Bereich 1 bis 10.000). Der Rechenressourcenverbrauch skaliert annähernd linear mit diesem Wert, daher ist die Senkung dieses Werts für Hybrid-Workloads einer der direktesten Hebel zur Kostensenkung.

• Werte um 500 reduzieren den Rechenaufwand oft deutlich bei nur geringem Relevanzverlust.

• Ein niedrigerer Wert kann dazu führen, dass Keyword-Treffer verloren gehen, die von der Vektorsuche verpasst werden, etwa exakte Begriffe, IDs und Akronyme.

• Steuern Sie Vektorkandidaten separat mit k für jede Vektorabfrage.

• Testen Sie repräsentative Abfragen, und vergleichen Sie die Relevanz, Latenz und den x-ms-azs-compute-units-consumed Header, bevor Sie einen Wert festlegen.

• Anwenden von Filtern vor Vektorabfragen: Schränken Sie den Kandidatensatz vor der Vektorsuche ein, um die Menge der verarbeiteten Daten zu reduzieren. Informationen zur Funktionsweise der Filterung in Vektorabfragen.

Kosten reduzieren, indem Sie die Nutzung minimieren

Das Serverless-Modell berechnet nur für verbrauchte Ressourcen. Wenn keine Anforderungen vorhanden sind, fällt die Berechnungsauslastung entsprechend ab.

So minimieren Sie die Nutzungskosten:

• Führen Sie Abfragen nur bei Bedarf aus.
• Vermeiden Sie redundante oder übermäßig häufige Anforderungen.
• Überwachen Sie die Nutzung und optimieren Sie Workloads basierend auf Bedarf.

Optimieren der Speicherkosten

Der Speicher wird pro GB/Monat basierend auf der Datenträgerindexgröße in Rechnung gestellt, wodurch die Rohdatengröße überschritten werden kann. So reduzieren Sie die Speicherkosten:

• Entfernen Sie nicht verwendete Indizes.
• Minimieren Sie gespeicherte Felder.
• Entwerfen Sie Schemas mit Berücksichtigung des Speicheraufwands.
• Verwenden Sie Suggester selektiv, da sie die Speichergröße erheblich erhöhen können.

Vektorspezifische Techniken (Komprimierung, Pruning und Speichereinstellungen) finden Sie unter Optimieren für Vektorspeicher und -verarbeitung.

Weitere Anleitungen zu Speicher- und Abfrageleistungskonflikten finden Sie unter Tips für eine bessere Leistung in Azure KI-Suche.