Teilen über

Reduzieren der Vektorgröße durch Quantisierung, schmale Datentypen und Speicheroptionen

  • Artikel

In diesem Artikel werden die Vektorquantisierung und andere Techniken zum Reduzieren der Vektorgröße in Azure KI-Suche beschrieben. Der Suchindex gibt Vektorfelddefinitionen an, darunter Eigenschaften für gespeicherte und schmale Datentypen. Die Quantisierung wird ebenfalls im Index angegeben und dem Vektorfeld über das Vektorprofil zugewiesen.

Diese Features sind in der REST-API 2024-07-01 und in den Azure SDK-Paketen für diese Version allgemein verfügbar. Das Beispiel am Ende dieses Artikels zeigt die Variationen der Vektorgröße für jeden der in diesem Artikel beschriebenen Ansätze.

Auswerten der Optionen

Überprüfen Sie zunächst die drei Ansätze zum Reduzieren der Speichermenge, die von Vektorfeldern belegt wird. Diese Ansätze schließen sich nicht gegenseitig aus und können kombiniert werden, um eine maximale Reduzierung der Vektorgröße zu erzielen.

Wir empfehlen die integrierte Quantisierung, da sie die Vektorgröße im Arbeitsspeicher und auf dem Datenträger mit minimalem Aufwand komprimiert und in den meisten Szenarien den größten Nutzen bietet. Schmale Typen (mit Ausnahme von „float16“) erfordern dagegen zusätzlichen Aufwand. Zudem speichert stored auf Datenträgerspeicher, was kostengünstiger ist als Arbeitsspeicher.

Vorgehensweise Warum sollten Sie diese Option verwenden?
Hinzufügen der skalaren oder binären Quantisierung Verwenden Sie die Quantisierung, um native float32- oder float16-Einbettungen in „int8“ (skalar) oder „Byte“ (binär) zu komprimieren. Mit dieser Option wird der Speicher im Arbeitsspeicher und auf dem Datenträger reduziert, ohne dass die Abfrageleistung beeinträchtigt wird. Kleinere Datentypen wie „int8“ oder „Byte“ führen beispielsweise zu Vektorindizes mit weniger Inhalt als Datentypen mit größeren Einbettungen. Um den Informationsverlust zu verrechnen, enthält die integrierte Komprimierung Optionen für die Nachabfrageverarbeitung mit nicht komprimierten Einbettungen und Oversampling, um relevantere Ergebnisse zurückzugeben. Neubewertung (Neusortierung) und Überquotierung sind spezifische Features der integrierten Quantisierung von float32- oder float16-Felder und können nicht für Einbettungen verwendet werden, die einer benutzerdefinierten Quantisierung unterzogen werden.
Zuweisen kleinerer primitiver Datentypen zu Vektorfeldern Schmale Datentypen wie „float16“, „int16“, „int8“ und „Byte“ (binär) verbrauchen weniger Speicherplatz im Arbeitsspeicher und auf dem Datenträger. Sie müssen jedoch über ein Einbettungsmodell verfügen, das Vektoren in einem schmalen Datenformat ausgibt. Oder Sie müssen über eine benutzerdefinierte Quantisierungslogik verfügen, die kleine Daten ausgibt. Ein dritter Anwendungsfall, der weniger Aufwand erfordert, ist die Umwandlung von nativen float32-Einbettungen, die von den meisten Modellen erzeugt werden, in „float16“. Weitere Informationen zu binären Vektoren finden Sie unter Index-Binärvektoren.
Entfernen optionaler Speicher von abrufbaren Vektoren In einer Abfrageantwort zurückgegebene Vektoren werden getrennt von Vektoren gespeichert, die während der Abfrageausführung verwendet werden. Wenn Sie keine Vektoren zurückgeben müssen, können Sie den abrufbaren Speicher deaktivieren, wodurch der gesamte Datenträgerspeicher pro Feld um bis zu 50 Prozent reduziert wird.

Alle diese Optionen werden für einen leeren Index definiert. Verwenden Sie zum Implementieren dieser Optionen das Azure-Portal, REST-APIs oder ein Azure SDK-Paket für diese API-Version.

Nachdem der Index definiert wurde, können Sie Dokumente als separaten Schritt laden und indiziert werden.

Option 1: Konfigurieren der Quantisierung

Die Quantisierung wird zum Reduzieren der Vektorgröße empfohlen, da sie den Speicherplatzbedarf im Arbeitsspeicher und auf dem Datenträger für float16- und float32-Einbettungen verringert. Um die Auswirkungen eines kleineren Index auszugleichen, können Sie die Überquotierung und Neubewertung für nicht komprimierte Vektoren hinzufügen.

Die Quantisierung gilt für Vektorfelder, die Vektoren vom Typ „float“ empfangen. In den Beispielen in diesem Artikel wird der Felddatentyp Collection(Edm.Single) für eingehende float32-Einbettungen verwendet, „float16“ wird jedoch ebenfalls unterstützt. Wenn die Vektoren in einem Feld mit konfigurierter Komprimierung empfangen werden, führt die Engine automatisch eine Quantisierung durch, um den Speicherbedarf der Vektordaten im Arbeitsspeicher und auf dem Datenträger zu reduzieren.

Zwei Quantisierungstypen werden unterstützt:

  • Die skalare Quantisierung komprimiert Float-Werte in schmalere Datentypen. Azure KI Suche unterstützt derzeit den Typ „int8“, der 8 Bit belegt und die Größe des Vektorindex um das Vierfache reduziert.

  • Die binäre Quantisierung konvertiert float-Typen in binäre Bits, die 1 Bit belegen. Dies führt zu einer bis zu 28-mal geringeren Vektorindexgröße.

Um die integrierte Quantisierung zu verwenden, gehen Sie wie folgt vor:

  • Verwenden Sie die API zum Erstellen eines Index (Create Index) oder Erstellen oder Aktualisieren eines Index (Create Or Update Index), um die Vektorkomprimierung anzugeben.
  • Fügen Sie einem Suchindex vectorSearch.compressions hinzu.
  • Fügen Sie eine scalarQuantization- oder binaryQuantization-Konfiguration hinzu, und benennen Sie sie.
  • Legen Sie optionale Eigenschaften fest, um die Auswirkungen einer verlustbehafteten Indizierung zu verringern.
  • Erstellen Sie ein neues Vektorprofil, das die benannte Konfiguration verwendet.
  • Erstellen Sie ein neues Vektorfeld mit dem neuen Vektorprofil.
  • Laden Sie den Index mit float32- oder float16-Daten, die während der Indizierung mit der von Ihnen definierten Konfiguration quantisiert werden.
  • Optional können Sie mithilfe des Oversampling-Parameters quantisierte Daten abfragen, wenn Sie die Standardeinstellung außer Kraft setzen möchten.

Hinzufügen von „compressions“ (Komprimierungen) zu einem Suchindex

Das folgende Beispiel zeigt eine partielle Indexdefinition mit einer Feldsammlung, die ein Vektorfeld und einen Abschnitt vectorSearch.compressions enthält.

Dieses Beispiel umfasst sowohl scalarQuantization als auch binaryQuantization. Sie können beliebig viele Komprimierungskonfigurationen angeben und einem Vektorprofil dann die gewünschten Konfigurationen zuweisen.

POST https://[servicename].search.windows.net/indexes?api-version=2024-07-01

{
  "name": "my-index",
  "fields": [
    { "name": "Id", "type": "Edm.String", "key": true, "retrievable": true, "searchable": true, "filterable": true },
    { "name": "content", "type": "Edm.String", "retrievable": true, "searchable": true },
    { "name": "vectorContent", "type": "Collection(Edm.Single)", "retrievable": false, "searchable": true },
  ],
  "vectorSearch": {
        "profiles": [ ],
        "algorithms": [ ],
        "compressions": [
          {
            "name": "use-scalar",
            "kind": "scalarQuantization",
            "scalarQuantizationParameters": {
              "quantizedDataType": "int8"
            },
            "rerankWithOriginalVectors": true,
            "defaultOversampling": 10
          },
          {
            "name": "use-binary",
            "kind": "binaryQuantization",
            "rerankWithOriginalVectors": true,
            "defaultOversampling": 10
          }
        ]
    }
}

Die wichtigsten Punkte:

  • kind muss auf scalarQuantization oder binaryQuantization festgelegt werden.

  • rerankWithOriginalVectors verwendet die ursprünglichen, nicht komprimierten Vektoren, um Die Ähnlichkeit neu zu berechnen und die top-Ergebnisse zu reranken, die von der ursprünglichen Suchabfrage zurückgegeben werden. Die nicht komprimierten Vektoren sind im Suchindex vorhanden, auch wenn stored "false" ist. Diese Eigenschaft ist optional. Der Standardwert ist korrekt.

  • defaultOversampling betrachtet eine breitere Reihe potenzieller Ergebnisse, um die Verringerung der Informationen aus der Quantisierung zu verrechnen. Die Formel für potenzielle Ergebnisse besteht aus der k Abfrage mit einem Oversampling-Multiplikator. Wenn die Abfrage beispielsweise einen k Wert von 5 angibt und die Oversampling 20 ist, fordert die Abfrage effektiv 100 Dokumente für die Verwendung in Reranking an, wobei der ursprüngliche nicht komprimierte Vektor zu diesem Zweck verwendet wird. Es werden nur die top rerangierten k Ergebnisse zurückgegeben. Diese Eigenschaft ist optional. Der Standardwert ist 4.

  • quantizedDataType ist optional und gilt nur für die skalare Quantisierung. Wenn Sie diesen Typ hinzufügen, muss er auf int8 festgelegt werden. Dies ist der einzige primitive Datentyp, der derzeit für die skalare Quantisierung unterstützt wird. Der Standardwert ist int8.

Hinzufügen des HNSW-Algorithmus

Stellen Sie sicher, dass Ihr Index über den Hierarchical Navigable Small Worlds (HNSW)-Algorithmus verfügt. Integrierte Quantisierung wird nicht mit erschöpfenden KNN unterstützt.

"vectorSearch": {
    "profiles": [ ],
    "algorithms": [
      {
          "name": "use-hnsw",
          "kind": "hnsw",
          "hnswParameters": {
              "m": 4,
              "efConstruction": 400,
              "efSearch": 500,
              "metric": "cosine"
          }
      }
    ],
     "compressions": [ <see previous section>] 
}

Erstellen und Zuweisen eines neuen Vektorprofils

Um eine neue Quantisierungskonfiguration zu verwenden, müssen Sie ein neues Vektorprofil erstellen. Die Erstellung eines neuen Vektorprofils ist erforderlich, um komprimierte Indizes im Arbeitsspeicher zu erstellen. Das neue Profil verwendet HNSW.

  1. Erstellen Sie in derselben Indexdefinition ein neues Vektorprofil, und fügen Sie eine Komprimierungseigenschaft sowie einen Algorithmus hinzu. Das folgende Beispiel zeigt zwei Profile, eins für jeden Quantisierungsansatz.

    "vectorSearch": {
    "profiles": [
       {
          "name": "vector-profile-hnsw-scalar",
          "compression": "use-scalar", 
          "algorithm": "use-hnsw",
          "vectorizer": null
       },
       {
          "name": "vector-profile-hnsw-binary",
          "compression": "use-binary", 
          "algorithm": "use-hnsw",
          "vectorizer": null
       }
     ],
     "algorithms": [  <see previous section> ],
     "compressions": [ <see previous section> ] 
}

  2. Weisen Sie einem neuenVektorfeld ein Vektorprofil zu. Der Datentyp des Felds ist „float32“ oder „float16“.

    Die Entity Data Model (EDM)-Entsprechungen der Typen „float32“ and „float16“ in Azure KI-Suche sind Collection(Edm.Single) bzw. Collection(Edm.Half).

    {
   "name": "vectorContent",
   "type": "Collection(Edm.Single)",
   "searchable": true,
   "retrievable": true,
   "dimensions": 1536,
   "vectorSearchProfile": "vector-profile-hnsw-scalar",
}

  3. Laden Sie den Index mithilfe von Indexern für die Pullmodellindizierung oder APIs für die Pushmodellindizierung.

Die skalare Quantisierung reduziert die Auflösung jeder Zahl innerhalb der Vektoreinbettung. Anstatt jede Zahl als 16-Bit- oder 32-Bit-Gleitkommazahl zu beschreiben, wird eine ganze 8-Bit-Zahl verwendet. Er identifiziert einen Zahlenbereich (in der Regel 99. Quantil Minimum und Maximum) und dividiert sie in eine begrenzte Anzahl von Ebenen oder Bins, wobei jedem Bin ein Bezeichner zugewiesen wird. In der 8-Bit-Skalar-Quantisierung gibt es 2^8 oder 256 mögliche Bins.

Jede Komponente des Vektors wird dem nächstgelegenen repräsentativen Wert innerhalb dieses Satzes von Quantisierungsebenen in einem Prozess zugeordnet, der einer reellen Zahl auf die nächste ganze Zahl entspricht. Im quantisierten 8-Bit-Vektor steht die Bezeichnernummer anstelle des ursprünglichen Werts. Nach der Quantisierung wird jeder Vektor durch ein Array von Bezeichnern für die Bins dargestellt, zu denen seine Komponenten gehören. Diese quantisierten Vektoren erfordern im Vergleich zum ursprünglichen Vektor viel weniger Bits zu speichern, wodurch die Speicheranforderungen und der Speicherbedarf reduziert werden.

Funktionsweise der binären Quantisierung in Azure KI-Suche

Die binäre Quantisierung komprimiert hochdimensionale Vektoren, indem jede Komponente als einzelnes Bit (0 oder 1) dargestellt wird. Diese Methode reduziert den Speicherbedarf erheblich und beschleunigt Vorgänge zum Vergleichen von Vektoren, die für Such- und Abrufaufgaben von entscheidender Bedeutung sind. Benchmarktests zeigen eine Verringerung der Vektorindexgröße um bis zu 96 %.

Die binäre Quantisierung ist besonders effektiv für Einbettungen mit Dimensionen, die größer als 1.024 sind. Für kleinere Dimensionen wird empfohlen, die Qualität der binären Quantisierung zu testen oder stattdessen die skalare Quantisierung auszuprobieren. Darüber hinaus haben wir festgestellt, dass die binäre Quantisierung sehr gut funktioniert, wenn Einbettungen um Null zentriert sind. Die beliebtesten Einbettungsmodelle wie OpenAI, Cohere und Mistral sind um Null zentriert.

Option 2: Zuweisen schmaler Datentypen zu Vektorfeldern

Eine einfache Möglichkeit zum Verringern der Vektorgröße ist das Speichern von Einbettungen in einem kleineren Datenformat. Die meisten Einbettungsmodelle geben 32-Bit-Gleitkommazahlen aus. Wenn Sie Ihre Vektoren jedoch quantisieren oder dies nativ von Ihrem Einbettungsmodell unterstützt wird, ist eine float16-, int16- oder int8-Ausgabe möglich, die deutlich kleiner ist als „float32“. Sie können diese kleineren Vektorgrößen verwenden, indem Sie einem Vektorfeld einen schmalen Datentyp zuweisen. Im Vektorindex belegen schmale Datentypen weniger Speicherplatz.

  1. Informationen zur empfohlenen Verwendung finden Sie unter EDM-Datentypen für Vektorfelder:

    • Collection(Edm.Single) 32-Bit-Gleitkomma (Standard)
    • Collection(Edm.Half) 16-Bit-Gleitkommazahl (schmal)
    • Collection(Edm.Int16) ganze 16-Bit-Zahl mit Vorzeichen (schmal)
    • Collection(Edm.SByte) ganze 8-Bit-Zahl mit Vorzeichen (schmal)
    • Collection(Edm.Byte) ganze 8-Bit-Zahl ohne Vorzeichen (nur zulässig bei gepackten Binärdatentypen)

  2. Bestimmen Sie anhand dieser Liste, welcher Datentyp für die Ausgabe Ihres Einbettungsmodells oder für Vektoren mit benutzerdefinierter Quantisierung gültig ist.

    Die folgende Tabelle enthält Links zu mehreren Einbettungsmodellen, die einen schmalen Datentyp (Collection(Edm.Half)) ohne zusätzliche Quantisierung verwenden. Sie können „float32“ ohne zusätzlichen Aufwand in „float16“ umwandeln (mit Collection(Edm.Half)).

    Einbettungsmodell Native Ausgabe Diesen Typ in Azure KI-Suche zuweisen
    text-embedding-ada-002 Float32 Collection(Edm.Single) oder Collection(Edm.Half)
    text-embedding-3-small Float32 Collection(Edm.Single) oder Collection(Edm.Half)
    text-embedding-3-large Float32 Collection(Edm.Single) oder Collection(Edm.Half)
    Cohere V3 Einbettungsmodell mit int8 Einbettungstyp Int8 Collection(Edm.SByte)

    Andere schmale Datentypen können verwendet werden, wenn Ihr Modell Einbettungen im kleineren Datenformat ausgibt oder wenn Sie eine benutzerdefinierte Quantisierung verwenden, die Vektoren in ein kleineres Format konvertiert.

  3. Stellen Sie sicher, dass Sie die Kompromisse eines schmalen Datentyps verstehen. Collection(Edm.Half) hat weniger Informationen, was zu einer niedrigeren Auflösung führt. Wenn Ihre Daten homogen oder dicht sind, kann der Verlust zusätzlicher Details oder Nuancen zu inakzeptablen Ergebnissen zur Abfragezeit führen, da es weniger Details gibt, die verwendet werden können, um nahe gelegene Vektoren voneinander zu unterscheiden.

  4. Definieren und erstellen Sie den Index. Sie können für diesen Schritt das Azure-Portal, die REST-API zum Erstellen oder Aktualisieren eines Index (Create or Update Index) oder ein Azure SDK-Paket verwenden.

  5. Prüfen Sie die Ergebnisse. Wenn das Vektorfeld als abrufbar gekennzeichnet ist, überprüfen Sie mit dem Suchexplorer oder mit Search – POST, ob der Feldinhalt dem Datentyp entspricht.

    Verwenden Sie zum Überprüfen der Vektorindexgröße das Azure-Portal oder die REST-API zum Abrufen von Statistiken (GET Statistics).

Hinweis

Der Datentyp des Felds wird verwendet, um die physische Datenstruktur zu erstellen. Wenn Sie später einen Datentyp ändern möchten, legen Sie den Index ab, und erstellen Sie ein zweites Feld mit der neuen Definition.

Option 3: Festlegen der stored-Eigenschaft zum Entfernen des abrufbaren Speichers

Die stored-Eigenschaft ist ein boolescher Wert für eine Vektorfelddefinition, der bestimmt, ob Speicher für abrufbare Vektorfeldinhalte zugeordnet wird. Die stored-Eigenschaft ist standardmäßig „true“. Wenn Sie Vektorinhalte in einer Abfrageantwort nicht benötigen, können Sie bis zu 50 Prozent Speicherplatz pro Feld sparen, indem Sie auf "false" festlegen stored.

Überlegungen zum Festlegen von stored auf „false“:

  • Da Vektoren nicht für Menschen lesbar sind, können Sie sie aus den Ergebnissen, die in RAG-Szenarien an LLMs gesendet werden, und aus den Ergebnissen, die auf einer Suchseite angezeigt werden, weglassen. Behalten Sie sie jedoch bei, wenn Sie Vektoren in nachgelagerten Prozessen verwenden, die Vektorinhalte nutzen.

  • Wenn Ihre Indizierungsstrategie jedoch teilweise Dokumentaktualisierungen enthält, z. B. „merge“ oder „mergeOrUpload“ in einem Dokument, beachten Sie, dass das Festlegen von stored auf „false“ dazu führt, dass Vektoren im nicht gespeicherten Feld während der Zusammenführung ausgelassen werden. Bei jedem „merge“- oder „mergeOrUpload“-Vorgang müssen Sie zusätzlich zu anderen Nichtvektorfeldern, die Sie aktualisieren, die Vektorfelder bereitstellen, da der Vektor andernfalls gelöscht wird.

Denken Sie daran, dass die stored-Zuordnung nicht rückgängig gemacht werden kann. Sie wird während der Indexerstellung für Vektorfelder festgelegt, wenn physische Datenstrukturen erstellt werden. Wenn Sie später abrufbare Vektorinhalte benötigen, müssen Sie den Index löschen und neu erstellen oder ein neues Feld mit der neuen Zuordnung erstellen und laden.

Das folgende Beispiel zeigt die Fields-Auflistung eines Suchindexes. Legen Sie stored diesen Wert auf "false" fest, um den abrufbaren Speicher für das Vektorfeld dauerhaft zu entfernen.

PUT https://[service-name].search.windows.net/indexes/demo-index?api-version=2024-07-01 
   Content-Type: application/json  
   api-key: [admin key]  
 
     { 
       "name": "demo-index", 
       "fields": [ 
         { 
           "name": "vectorContent", 
           "type": "Collection(Edm.Single)", 
           "retrievable": false, 
           "stored": false, 
           "dimensions": 1536, 
           "vectorSearchProfile": "vectorProfile" 
         } 
       ] 
     }

Die wichtigsten Punkte:

  • Gilt nur für Vektorfelder.

  • Wirkt sich auf den Speicher auf dem Datenträger, nicht auf den Arbeitsspeicher aus, und hat keine Auswirkungen auf Abfragen. Die Abfrageausführung verwendet einen separaten Vektorindex, der von der stored Eigenschaft nicht betroffen ist.

  • Die stored Eigenschaft wird während der Indexerstellung für Vektorfelder festgelegt und ist unumkehrbar. Wenn Sie später abrufbare Inhalte abrufen möchten, müssen Sie den Index ablegen und neu erstellen oder ein neues Feld erstellen und laden, das über die neue Zuordnung verfügt.

  • Standardwerte sind stored auf "true" festgelegt und retrievable auf "false" festgelegt. In einer Standardkonfiguration wird eine abrufbare Kopie gespeichert, aber sie wird nicht automatisch in Ergebnissen zurückgegeben. Wenn stored dies der Fall ist, können Sie jederzeit zwischen "true" und "false" umschalten retrievable, ohne einen Index neu erstellen zu müssen. Ist stored "false", retrievable muss "false" sein und kann nicht geändert werden.

Beispiel: Techniken zur Vektorkomprimierung

Der folgende Python-Code veranschaulicht die Quantisierung, schmale Datentypen und die Verwendung der stored-Eigenschaft: Codebeispiel: Vektorquantisierung und Speicheroptionen mit Python.

Dieser Code erstellt und vergleicht die Speicher- und Vektorindexgröße für jede Option:

****************************************
Index Name: compressiontest-baseline
Storage Size: 21.3613MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-compression
Storage Size: 17.7604MB
Vector Size: 1.2242MB
****************************************
Index Name: compressiontest-narrow
Storage Size: 16.5567MB
Vector Size: 2.4254MB
****************************************
Index Name: compressiontest-no-stored
Storage Size: 10.9224MB
Vector Size: 4.8277MB
****************************************
Index Name: compressiontest-all-options
Storage Size: 4.9192MB
Vector Size: 1.2242MB

Such-APIs melden die Speicher- und Vektorgröße auf Indexebene. Der Vergleich muss daher auf der Grundlage von Indizes durchgeführt werden, nicht mit Feldern. Verwenden Sie GET Index Statistics oder eine entsprechende API in den Azure SDKs, um die Vektorgröße abzurufen.

Abfragen eines quantisierten Vektorfelds mithilfe von Oversampling

Die Abfragesyntax für ein komprimiertes oder quantisiertes Vektorfeld ist identisch mit der für nicht komprimierte Vektorfelder, es sei denn, Sie möchten Parameter im Zusammenhang mit der Überquotierung oder Neubewertung mit ursprünglichen Vektoren überschreiben.

Beachten Sie, dass die Vektorkomprimierungsdefinition im Index Einstellungen für rerankWithOriginalVectors und defaultOversampling enthält, um die Auswirkungen eines kleineren Vektorindex zu verringern. Sie können die Standardwerte überschreiben, um das Verhalten zur Abfragezeit zu ändern. Wenn defaultOversampling z. B. 10,0 ist, können Sie ihn in eine andere Abfrageanforderung ändern.

Sie können den Oversampling-Parameter auch dann festlegen, wenn der Index nicht explizit über eine rerankWithOriginalVectors Oder defaultOversampling Definition verfügt. Wenn Sie oversampling zur Abfragezeit angeben, werden die Indexeinstellungen für diese Abfrage außer Kraft gesetzt und die Abfrage mit einem effektiven rerankWithOriginalVectors Wert als "true" ausgeführt.

POST https://[service-name].search.windows.net/indexes/demo-index/docs/search?api-version=2024-07-01   
  Content-Type: application/json   
  api-key: [admin key]   

    {    
       "vectorQueries": [
            {    
                "kind": "vector",    
                "vector": [8, 2, 3, 4, 3, 5, 2, 1],    
                "fields": "myvector",
                "oversampling": 12.0,
                "k": 5   
            }
      ]    
    }

Die wichtigsten Punkte:

  • Gilt für Vektorfelder, die sich einer Vektorkomprimierung pro Vektorprofilzuweisung unterziehen.

  • Überschreibt den defaultOversampling Wert oder führt die Oversampling zur Abfragezeit ein, auch wenn die Komprimierungskonfiguration des Indexes keine Oversampling- oder Reranking-Optionen angegeben hat.

Weitere Informationen