Vektorindexgröße und Untergrenzen bleiben
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.
Hinweis
Eine Notiz zur Terminologie. Intern enthalten die physischen Datenstrukturen eines Suchindex rohen Inhalt (verwendet für Abrufmuster, die nicht tokenisierte Inhalte erfordern), invertierte Indizes (für durchsuchbare Textfelder verwendet) und Vektorindizes (für durchsuchbare Vektorfelder verwendet). In diesem Artikel werden die Grenzwerte für die internen Vektorindizes erläutert, die jedes Ihrer Vektorfelder zurückgibt.
Tipp
Die Vektorquantisierung und Speicherkonfiguration ist jetzt allgemein verfügbar. Verwenden Sie Funktionen wie schmale Datentypen, skalare Quantisierung und Eliminierung von redundantem Speicher, um Vektor- und Speicherkontingente nicht zu überschreiten.
Wichtige Punkte zur Kontingent- und Vektorindexgröße
Die Vektorindexgröße wird in Bytes angegeben.
Vektorkontingente basieren auf Arbeitsspeichereinschränkungen. Alle durchsuchbaren Vektorindizes müssen in den Arbeitsspeicher geladen werden. Gleichzeitig muss auch genügend Arbeitsspeicher für andere Laufzeitvorgänge vorhanden sein. Vektorkontingente sind vorhanden, um sicherzustellen, dass das Gesamtsystem für alle Workloads stabil und ausgeglichen bleibt.
Vektorindizes unterliegen ebenfalls dem Datenträgerkontingent, und zwar in dem Sinn, dass alle Indizes dem Datenträgerkontingent unterliegen. Es gibt kein separates Datenträgerkontingent für Vektorindizes.
Vektorkontingente werden für den Suchdienst als Ganzes und pro Partition erzwungen. Das heißt, wenn Sie Partitionen hinzufügen, wird das Vektorkontingent erhöht. Vektorkontingente pro Partition sind für neuere Dienste höher. Weitere Informationen finden Sie unter Vektorindexgrößenbeschränkungen.
Überprüfen der Partitionsgröße und -menge
Wenn Sie nicht sicher sind, was Ihre Suchdienstgrenzwerte sind, sind hier zwei Möglichkeiten zum Abrufen dieser Informationen:
Im Azure-Portal auf der Seite Übersicht im Suchdienst zeigen sowohl die Registerkarte Eigenschaften als auch die Registerkarte Nutzung Partitionsgröße und -speicher sowie Vektorkontingent- und Vektorindexgröße an.
Im Azure-Portal können Sie auf der Seite Skalieren die Anzahl und Größe von Partitionen überprüfen.
Überprüfen des Erstellungsdatums des Dienstes
Neuere Dienste, die nach dem 3. April 2024 erstellt wurden, bieten fünf bis zehnmal mehr Vektorspeicher als ältere Dienste mit dem gleichen Tarif für die Abrechnung. Wenn Ihr Dienst älter ist, sollten Sie einen neuen Dienst erstellen und Ihre Inhalte migrieren.
Öffnen Sie im Azure-Portal die Ressourcengruppe, die Ihren Suchdienst enthält.
Wählen Sie im ganz linken Bereich unter Einstellungen die Option Bereitstellungen aus.
Suchen Sie nach Ihrer Suchdienstbereitstellung. Wenn viele Bereitstellungen vorhanden sind, verwenden Sie den Filter, um nach „search“ zu suchen.
Wählen Sie die Bereitstellung aus. Wenn Sie mehrere haben, klicken Sie darauf, um festzustellen, ob diese zu Ihrem Suchdienst führt.
Erweitern Sie die Bereitstellungsdetails. Der Status Erstellt und das Erstellungsdatum sollten angezeigt werden.
Nachdem Sie nun das Alter Ihres Suchdiensts kennen, überprüfen Sie die Vektorkontingentgrenzen basierend auf der Diensterstellung: Vektorindexgrößenbeschränkungen.
Abrufen 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.
Nutzungsinformationen finden Sie auf der Registerkarte Syntax der Seite Übersicht. 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 belegen die Vektorindizes nicht 93 MB. 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 Speichergröße eines einzelnen Vektors wird durch seine Dimensionalität bestimmt. 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 |
Overhead des Arbeitsspeichers durch den ausgewählten Algorithmus
Jeder ANN-Algorithmus (Approximate Nearest Neighbor, ungefährer nächster Nachbar) generiert zusätzliche Datenstrukturen im Arbeitsspeicher, um eine effiziente Suche zu ermöglichen. Diese Strukturen beanspruchen zusätzlichen Platz im Arbeitsspeicher.
Beim HNSW-Algorithmus liegt der Overhead des Arbeitsspeichers zwischen einem und 20 Prozent.
Bei höheren Dimensionen ist der Overhead des Arbeitsspeichers geringer, da die Rohgröße der Vektoren zunimmt. Die zusätzlichen Datenstrukturen bleiben dagegen eine feste Größe, da sie Informationen zur Konnektivität innerhalb des Graphen speichern. Folglich ist der Anteil der zusätzlichen Datenstrukturen an der Gesamtgröße geringer.
Der Overhead des Arbeitsspeichers ist für größere Werte des HNSW-Parameters m höher. Dies bestimmt die Anzahl bidirektionaler Verknüpfungen, die für jeden neuen Vektor während der Indexerstellung erstellt werden. Dies liegt daran, dass m etwa 8 Byte zu 10 Bytes pro Dokument beiträgt, multipliziert mit m.
In der folgenden Tabelle sind die in internen Tests beobachteten Overhead-Prozentsätze zusammengefasst:
| Maße | HNSW-Parameter (m) | Overhead in Prozent |
|---|---|---|
| 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.
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 Ihrer 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. Wenn Sie mehr über die Vektorgröße auf dem Datenträger wissen möchten, so ist der Datenträgerverbrauch für Vektordaten ungefähr dreimal so groß wie der Vektorindex im Arbeitsspeicher. Wenn Ihr vectorIndexSize-Verbrauch beispielsweise bei 100 Megabyte (10 Millionen Bytes) liegt, würden Sie mindestens 300 MB des storageSize-Kontingents zum Speichern Ihrer Vektorindizes nutzen.