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.
Für jedes Vektorfeld erstellt Azure KI-Suche einen internen Vektorindex mithilfe der im Feld angegebenen Algorithmusparameter. Da Azure KI-Suche Kontingente für die Vektorindexgröße aufzwingt, sollten Sie wissen, wie Sie die Vektorgröße schätzen und überwachen, um sicherzustellen, dass Sie unter den Grenzwerten bleiben.
Intern umfassen die physischen Datenstrukturen eines Suchindex:
- Unformatierter Inhalt (wird für Abrufmuster verwendet, die nichttokenisierte Inhalte erfordern)
- Invertierte Indizes (wird für durchsuchbare Textfelder verwendet)
- Vektorindizes (für durchsuchbare Vektorfelder verwendet)
In diesem Artikel werden die Grenzwerte für die internen Vektorindizes erläutert, die Ihren Vektorfeldern zugrunde liegen.
Tipp
Vektoroptimierungstechniken sind allgemein verfügbar. Verwenden Sie Funktionen wie schmale Datentypen, Skalare und binäre Quantisierung sowie die Eliminierung redundanter Speicher, um den Vektorkontingent- und Speicherkontingentverbrauch zu reduzieren.
Wichtige Punkte zur Kontingent- und Vektorindexgröße
Die Vektorindexgröße wird in Bytes angegeben.
Der gesamte Speicher Ihres Diensts enthält alle Ihre Vektorindexdateien. Azure AI Search verwaltet unterschiedliche Kopien von Vektorindexdateien für verschiedene Zwecke. Wir bieten weitere Optionen, um den Speicheraufwand von Vektorindizes zu reduzieren, indem einige dieser Kopien eliminiert werden.
Vektorkontingente werden für den Suchdienst als Ganzes pro Partition erzwungen. Wenn Sie Partitionen hinzufügen, erhöht sich auch das Vektorkontingent. Vektorkontingente pro Partition sind für neuere Dienste höher. Weitere Informationen finden Sie unter Vektorindexgrößenbeschränkungen.
Nicht alle Algorithmen verbrauchen das Kontingent für die Vektorindexgröße. Vektorkontingente werden basierend auf den Speicheranforderungen der Suche nach ungefähren nächsten Nachbarn (ANN) festgelegt. Die mit dem Hierarchischen Navigable Small World (HNSW)-Algorithmus erstellten Vektorfelder müssen sich während der Abfrageausführung im Arbeitsspeicher befinden, da der Zugriff per Zufallszugriff auf grafbasierte Durchläufe erforderlich ist. Vektorfelder, die den erschöpfenden K-Nearest Neighbors (KNN)-Algorithmus verwenden, werden während der Abfrageausführung dynamisch in den Speicher geladen und verbrauchen daher kein Vektorkontingent.
Größe und Menge der Partitionen überprüfen
Wenn Sie nicht sicher sind, was Ihre Suchdienstgrenzwerte sind, sind hier zwei Möglichkeiten zum Abrufen dieser Informationen:
Im Azure-Portal zeigen sowohl auf der Registerkarte "Eigenschaften" als auch auf der Registerkarte "Verwendung" auf der Seite "Suchdienstübersicht" Partitionsgröße und -speicher sowie Vektorkontingent- und Vektorindexgröße an.
Im Azure-Portal können Sie auf der Seite " Skalierung " die Anzahl und Größe von Partitionen überprüfen.
Ihr Vektorgrenzwert variiert je nach Erstellungsdatum des Diensts.
Überprüfen der Vektorindexgröße
Eine Anforderung für Vektormetriken ist ein Vorgang der Datenebene. Sie können das Azure-Portal, die REST-APIs oder Azure-SDKs verwenden, um die Vektornutzung auf Dienstebene über Dienststatistiken und für einzelne Indizes abzurufen.
Vektorgröße pro Index
Um die Vektorindexgröße pro Index abzurufen, wählen Sie Suchverwaltung>Indizes aus, um eine Liste der Indizes und die Dokumentanzahl, die Größe von In-Memory-Vektorindizes und die Gesamtindexgröße anzuzeigen, wie sie auf dem Datenträger gespeichert sind.
Beachten Sie, dass das Vektorkontingent auf Speichereinschränkungen basiert. Für Vektorindizes, die mit dem HNSW-Algorithmus erstellt wurden, werden alle durchsuchbaren Vektorindizes dauerhaft in den Speicher geladen. Für Indizes, die mit dem umfassenden KNN-Algorithmus erstellt wurden, werden Vektorindizes während der Abfragezeit sequenziell in Blöcken geladen. Für vollständige KNN-Indizes ist keine Speicherbelegung erforderlich. Die Lebensdauer der geladenen Seiten im Arbeitsspeicher ähnelt der der Textsuche. Es gibt keine anderen Metriken als den gesamten Speicher, die für umfassende KNN-Indizes gelten.
Der folgende Screenshot zeigt zwei Versionen desselben Vektorindexes. Eine Version wird mit dem HNSW-Algorithmus erstellt, wobei das Vektordiagramm speicherresident ist. Eine weitere Version wird mit einem umfassenden KNN-Algorithmus erstellt. Mit dem exhaustiven KNN gibt es keinen speziellen In-Memory-Vektorindex, daher zeigt das Portal eine Vektorindexgröße von 0 MB an. Diese Vektoren sind noch vorhanden und werden in der gesamten Speichergröße gezählt, belegen aber nicht die In-Memory-Ressource, die von der Metrik der Vektorindexgröße nachverfolgt wird.
Vektorgröße pro Dienst
Wenn Sie die Vektorindexgröße für den Suchdienst insgesamt abrufen möchten, wählen Sie auf der Seite Übersicht die Registerkarte Verbrauch aus. Die Portalseiten werden alle paar Minuten aktualisiert. Wenn Sie also kürzlich einen Index aktualisiert haben, warten Sie eine Weile, bevor Sie die Ergebnisse überprüfen.
Der folgende Screenshot stellt einen älteren Standard 1- (S1)-Suchdienst dar, der für eine Partition und ein Replikat konfiguriert ist.
Das Speicherkontingent ist eine Datenträgereinschränkung und schließt alle Indizes (Vektor und Nichtvektor) für einen Suchdienst ein.
Das Kontingent für die Vektorindexgröße ist eine Arbeitsspeichereinschränkung. Es ist die Menge an Arbeitsspeicher, die zum Laden aller internen Vektorindizes, die für jedes Vektorfeld in einem Suchdienst erstellt wurden, benötigt wird.
Der Screenshot zeigt an, dass Indizes (Vektor und Nichtvektor) fast 460 MB des verfügbaren Datenträgerspeichers belegen. Vektorindizes verbrauchen auf Dienstebene fast 93 MB Arbeitsspeicher.
Die Kontingente für die Speicher- und Vektorindexgröße werden beim Hinzufügen oder Entfernen von Partitionen vergrößert bzw. verkleinert. Wenn Sie die Partitionsanzahl ändern, wird auf der Kachel eine entsprechende Änderung des Speicher- und Vektorkontingents angezeigt.
Hinweis
Auf dem Datenträger sind die Vektorindizes nicht 93 MB groß. Die Vektorindizes auf dem Datenträger belegen etwa dreimal mehr Speicherplatz als die Vektorindizes im Arbeitsspeicher. Weitere Informationen finden Sie unter Auswirkungen von Vektorfeldern auf den Datenträgerspeicher.
Faktoren, die sich auf die Vektorindexgröße auswirken
Es gibt drei Hauptkomponenten, die sich auf die Größe Ihres internen Vektorindex auswirken:
- Rohgröße der Daten
- Overhead durch den ausgewählten Algorithmus
- Overhead durch das Löschen oder Aktualisieren von Dokumenten im Index
Rohgröße der Daten
Jeder Vektor ist ein Array von Gleitkommazahlen mit einfacher Genauigkeit in einem Feld vom Typ Collection(Edm.Single).
Vektordatenstrukturen benötigen Speicher, dargestellt in der folgenden Berechnung als „Rohgröße“ Ihrer Daten. Verwenden Sie diese Rohgröße, um die Größenanforderungen des Vektorindex Ihrer Vektorfelder zu schätzen.
Die Dimensionalität eines Vektors bestimmt seine Speichergröße. Multiplizieren Sie die Größe eines einzelnen Vektors mit der Anzahl von Dokumenten, in denen dieses Vektorfeld enthalten ist, um die Rohgröße zu ermitteln:
raw size = (number of documents) * (dimensions of vector field) * (size of data type)
| EDM-Datentyp | Größe des Datentyps |
|---|---|
Collection(Edm.Single) |
4 Byte |
Collection(Edm.Half) |
2 Bytes |
Collection(Edm.Int16) |
2 Bytes |
Collection(Edm.SByte) |
1 Byte |
Speicher-Overhead durch den ausgewählten Algorithmus
Jeder ANN-Algorithmus generiert zusätzliche Datenstrukturen im Arbeitsspeicher, um eine effiziente Suche zu ermöglichen. Diese Strukturen beanspruchen zusätzlichen Platz im Arbeitsspeicher.
Für den HNSW-Algorithmus reicht der Speicheraufwand zwischen 1% und 20% für unkomprimierte Float32-Vektoren (Edm.Single).
Da die Dimensionalität zunimmt, verringert sich der Arbeitsspeicher-Overhead-Prozentsatz. Dies tritt auf, da die rohe Größe der Vektoren vergrößert wird, während die anderen Datenstrukturen, die Graph-Konnektivitätsinformationen speichern, eine feste Größe für eine bestimmte Zeit mbeibehalten. Infolgedessen nimmt die relative Auswirkung dieser zusätzlichen Datenstrukturen im Verhältnis zur Gesamtvektorgröße ab.
Der Arbeitsspeicheraufwand erhöht sich mit größeren Werten des HNSW-Parameters m, der die Anzahl der bidirektionalen Verknüpfungen angibt, die für jeden neuen Vektor während der Indexerstellung erstellt wurden. Dies geschieht, da jeder Link etwa 8 bis 10 Byte pro Dokument beiträgt, und der gesamte Overhead skaliert proportional mit m.
In der folgenden Tabelle sind die in internen Tests für nicht komprimierte Vektorfelder beobachteten Overheadprozentsätze zusammengefasst:
| Maße | HNSW-Parameter (m) | Overheadprozentsatz |
|---|---|---|
| 96 | 4 | 20% |
| 200 | 4 | 8 % |
| 768 | 4 | 2 % |
| 1536 | 4 | 1 % |
| 3072 | 4 | 0,5 % |
Diese Ergebnisse veranschaulichen die Beziehung zwischen Dimensionen, dem HNSW-Parameter m und dem Overhead des Arbeitsspeichers für den HNSW-Algorithmus.
Bei Vektorfeldern, die Komprimierungstechniken verwenden, z. B. skalare oder binäre Quantisierung, scheint der Overheadprozentsatz einen größeren Prozentsatz der Gesamtvektorindexgröße zu verbrauchen. Da sich die Größe der Daten verringert, werden die relativen Auswirkungen der Datenstrukturen mit fester Größe, die zum Speichern von Graphkonnektivitätsinformationen verwendet werden, erheblicher.
Overhead durch das Löschen oder Aktualisieren von Dokumenten im Index
Wenn ein Dokument mit einem Vektorfeld gelöscht oder aktualisiert wird (Aktualisierungen werden intern als Lösch- und Einfügevorgang dargestellt), wird das zugrunde liegende Dokument bei nachfolgenden Abfragen als gelöscht markiert und übersprungen. Wenn neue Dokumente indiziert werden und die Größe des internen Vektorindex zunimmt, bereinigt das System diese gelöschten Dokumente und gibt die Ressourcen frei. Das bedeutet, dass es zwischen der Löschung von Dokumenten und der Freigabe der zugrunde liegenden Ressourcen wahrscheinlich zu einer Verzögerung kommt.
Wir bezeichnen dies als das Verhältnis gelöschter Dokumente. Da das Verhältnis gelöschter Dokumente von den Indizierungsmerkmalen Ihres Diensts abhängt, gibt es keine universelle Heuristik, um diesen Parameter zu schätzen, und es gibt keine APIs oder Skripts, die das Verhältnis für Ihren Dienst zurückgeben. Nach unserer Erfahrung liegt das Verhältnis gelöschter Dokumente bei der Hälfte unserer Kunden unter 10 Prozent. Wenn Sie viele Lösch- oder Aktualisierungsvorgänge durchführen, ist das Verhältnis gelöschter Dokumente bei Ihnen möglicherweise höher.
Dies ist ein weiterer Faktor, der sich auf die Größe Ihres Vektorindex auswirkt. Leider gibt es keinen Mechanismus, um Ihr aktuelles Verhältnis gelöschter Dokumente anzuzeigen.
Schätzen der Gesamtgröße von Daten im Arbeitsspeicher
Wenn Sie die zuvor beschriebenen Faktoren berücksichtigen, verwenden Sie die folgende Berechnung, um die Gesamtgröße Ihres Vektorindexes zu schätzen:
(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))
Nehmen wir zur Berechnung der Rohgröße (raw_size) beispielsweise an, dass Sie das beliebte Azure OpenAI-Modell text-embedding-ada-002 mit 1.536 Dimensionen verwenden. DAs bedeutet, dass ein Dokument 1.536 Edm.Single (Gleitkommazahlen) oder 6.144 Bytes beansprucht, da pro Edm.Single jeweils 4 Bytes anfallen. 1.000 Dokumente mit einem einzelnen Vektorfeld mit 1.536 Dimensionen würden insgesamt 1.536.000 Gleitkommazahlen oder 6.144.000 Bytes beanspruchen (1.000 Dokumente · 1.536 Gleitkommazahlen/Dokument).
Wenn Sie über mehrere Vektorfelder verfügen, müssen Sie diese Berechnung für jedes Vektorfeld in Ihrem Index durchführen und anschließend alle addieren. 1.000 Dokumente mit zwei Vektorfeldern mit jeweils 1,536 Dimensionen würden also beispielsweise 12,288,000 Bytes beanspruchen (1.000 Dokumente · 2 Felder · 1.536 Gleitkommazahlen/Dokument · 4 Bytes/Gleitkommazahl).
Um die Vektorindexgröße zu erhalten, muss diese Rohgröße (raw_size) mit dem Algorithmus-Overhead und dem Verhältnis gelöschter Dokumente multipliziert werden. Wenn Ihr Algorithmus-Overhead für die von Ihnen gewählten HNSW-Parameter sowie Ihr Verhältnis gelöschter Dokumente jeweils zehn Prozent beträgt, erhalten wir Folgendes: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.
Auswirkungen von Vektorfeldern auf den Datenträgerspeicher
Die meisten dieser Artikel enthalten Informationen zur Größe von Vektoren im Arbeitsspeicher. Informationen zum Speicheraufwand von Vektorindizes finden Sie unter Entfernen optionaler Vektorinstanzen aus dem Speicher.