Hoe beïnvloedt vectorindexcompressie de zoekreproductie en het RAM-gebruik?
Vectorindexcompressie vermindert het RAM-gebruik door representaties met een lagere precisie op te slaan, maar de daaruit voortvloeiende vervorming van afstanden kan de recall van nearest-neighborzoekopdrachten verlagen.
Een lokale RAG-index kan comfortabel passen bij honderdduizend chunks, maar na jaren aan documenten, foto’s en transcripties tegen de geheugenlimiet aanlopen. Kwantisatie kan ervoor zorgen dat er meer vectoren in het geheugen blijven, maar de zoekkwaliteit hangt ervan af of gecomprimeerde afstanden dezelfde volgorde van kandidaten behouden als afstanden met volledige precisie. Het resultaat verandert afhankelijk van de verdeling van embeddings, de compressieverhouding, het indextype, de kandidaatbreedte en de vraag of de oorspronkelijke vectoren beschikbaar blijven voor rescoring.
Compressie verkleint de vectorpayload, niet alle indexkosten
Een vectorindex gebruikt geheugen voor de embeddingwaarden, grafiek- of partitiestructuren, identificatiegegevens, metadata, allocator-overhead en tijdelijke querybuffers. Compressie vermindert voornamelijk de representatie van de embeddings. HNSW-koppelingen en metadata kunnen vergelijkbaar blijven, waardoor de totale RAM-besparing kleiner kan zijn dan de compressieverhouding van de vectoren doet vermoeden.
hoogdimensionale vectoren zijn duur omdat elke dimensie die als een waarde met volledige precisie wordt opgeslagen, bijdraagt aan het geheugen- en afstandsberekeningskosten. Door die waarden te vervangen door compacte codes, wordt de payload in het geheugen kleiner en kan de cache-efficiëntie verbeteren.
De daadwerkelijke besparing hangt daarom af van de samenstelling van de index. Vectoren met hoge dimensionaliteit en floats bieden doorgaans een groot besparingspotentieel; kleine vectoren met veel grafiekkoppelingen leveren proportioneel mogelijk minder op. Meet het resident memory van het proces en de indexbestanden vóór en na compressie, in plaats van het aantal onbewerkte vectorbytes met het aantal documenten te vermenigvuldigen.
Kwantisatie introduceert vervorming van afstanden
Scalaire kwantisatie brengt elke dimensie in kaart op een kleiner numeriek bereik, terwijl productkwantisatie een vector opsplitst in deelruimten en codeboekkeuzes opslaat. Beide methoden vervangen exacte coördinaten door benaderingen. De queryafstand wordt vervolgens berekend op basis van gereconstrueerde waarden of codeboekafstanden, in plaats van de oorspronkelijke floatvector.
Experimenten met productkwantisatie evalueren compressie door de vervorming van gereconstrueerde afstanden en de recall te meten. Compactere codes kunnen de latentie of het geheugengebruik verlagen, maar maken het ook moeilijker om nabije kandidaten correct te rangschikken wanneer hun werkelijke afstanden dicht bij elkaar liggen.
Recall daalt wanneer een relevante buur onder de kandidaatgrens terechtkomt, niet simpelweg omdat elke afstand een beetje onjuist is. Query’s met een duidelijk verschil tussen relevante en irrelevante chunks kunnen zware compressie doorstaan; dichte semantische buurten met veel bijna-gelijke afstanden zijn gevoeliger.
Meer kandidaten en rescoring kunnen recall herstellen
Een zoekopdracht in twee fasen gebruikt gecomprimeerde vectoren om een ruime shortlist te vinden en berekent daarna de afstanden voor die kandidaten opnieuw met vectoren met een hogere precisie. Oversampling geeft relevante items meer kans om de eerste, benaderende fase te overleven; rescoring herstelt de volgorde wanneer compacte codes kleine afstandsverschillen hebben vervaagd.
hogere compressieniveaus verlagen de recall doorgaans, terwijl oversampling en rescoring de nauwkeurigheid kunnen verbeteren. Dat herstel vereist extra leesbewerkingen, geheugen en querywerk, waardoor compressie de middelen verschuift in plaats van de kwaliteitskosten weg te nemen.
Volledige vectoren op schijf bewaren kan het RAM-gebruik laag houden, maar tijdens het opnieuw rangschikken extra opslaglatentie veroorzaken. Ze in het RAM bewaren verbetert de latentie, maar vermindert het geheug voordeel. De nuttigste configuratie hangt ervan af of de lokale server wordt beperkt door geheugencapaciteit, opslag-IOPS of responstijddoelen.
Recall moet worden gemeten op de lokale retrievaltaak
Stel een referentieset samen door voor representatieve query’s een exacte zoekopdracht of een zoekopdracht met hoge precisie uit te voeren. Vergelijk vervolgens of de gecomprimeerde zoekopdracht dezelfde relevante buren binnen top-k retourneert. Neem parafrasen, eigennamen, bijna-duplicaatdocumenten, zeldzame termen en query’s op waarvan het antwoord afhankelijk is van een klein verschil in het bewijsmateriaal.
Dit vormt een aanvulling op vertrouwen in retrieval-grounding: overeenkomst tussen buren en ondersteuning van een antwoord hangen samen, maar zijn niet identiek. Meet Recall@k ten opzichte van de zoekbaseline en controleer ook of verdwenen of anders gerangschikte chunks het bewijsmateriaal voor de generator veranderen.
Er is geen universele winnaar tussen maximale compressie en maximale precisie. Verhoog de compressie totdat RAM-gebruik, latentie en taakrecall de gewenste balans bereiken en test opnieuw na wijzigingen in het embeddingmodel of corpus. Een configuratie die goed werkt voor brede fotosimilariteit kan te veel informatie verliezen voor het ophalen van technische documenten met veel semantisch aangrenzende passages.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waarom de architectuur van je Jellyfin-thuisserver verandert naarmate je meer services toevoegt
Een Jellyfin-box wordt een dienstenstack naarmate er meer apps worden toegevoegd. Daarom moeten CPU, opslag, netwerk, geheimen, back-ups en herstelgrenzen expliciet worden toegewezen.
Jellyfin-prestaties meten zonder cache met capaciteit te verwarren
Een betrouwbare Jellyfin-benchmark labelt de koude en warme toestand afzonderlijk, zodat metadata uit de cache of bestandssysteempagina’s niet wordt aangezien voor permanente hardwarecapaciteit.
Hoeveel iGPU-capaciteit heeft Jellyfin nodig voor meerdere gebruikers?
De iGPU-reservecapaciteit van Jellyfin is werkbelastingsspecifiek: houd marge boven de zwaarste herhaalbare combinatie van gelijktijdige transcoderingen aan, in plaats van een willekeurig gebruikspercentage.
