Vad orsakar att en vektordatabas returnerar olika grannar efter komprimering?
En vektordatabas kan returnera andra grannar efter komprimering eftersom samma embeddingar kan organiseras om i en ny struktur för approximativ sökning.
För en lokal RAG-server kan förändringen verka misstänkt: inga dokument har avsiktligt bäddats in på nytt, men en välbekant fråga returnerar en något annorlunda top-k-lista efter underhåll. Den viktiga skillnaden är mellan vektorvärdena och ANN-indexet som söker bland dem. Komprimering kan bevara det första samtidigt som det andra byggs om.
Komprimering kan ersätta flera söksegment med ett nytt index
En vektordatabas samlar ofta på sig separata segment när dokument infogas, uppdateras och tas bort. Komprimering konsoliderar dessa delar så att systemet får färre strukturer att söka i och mindre föråldrad data att bära.
Qdrant erbjuder optimerare som riktar in sig på antalet och storleken på segmenten i stället för att behandla samlingen som en enda permanent fast graf. När komprimering skapar ett större optimerat segment kan den fysiska sökstrukturen byggas om även om de logiska vektorerna är oförändrade.
Den skillnaden är viktig för ett privat RAG-index: embeddingarna kan ha identiska numeriska värden före och efter underhållet, medan den approximativa sökgraf som sammanlänkar dem är annorlunda.
Approximerad sökning efter närmaste granne beror på grafens topologi
HNSW jämför inte en fråga med varje vektor. I stället navigerar den i en skiktad graf och följer ett begränsat antal lovande anslutningar, så vägen genom grafen påverkar vilka kandidater som undersöks.
Elasticsearch förklarar att segmentöverslagningar kan behöva beräkna om HNSW-grafer. En ombyggd graf kan ansluta samma vektorer på olika sätt eftersom byggordning, borttagningsstatus och grafheuristik påverkar kanterna.
Om två kandidater har mycket liknande avstånd kan en liten förändring av topologin göra att den ena hamnar i kandidatmängden medan den andra aldrig besöks. Resultatet blir andra approximativa grannar utan att embeddingmodellen har förändrats.
Sökparametrarna avgör hur mycket av den nya grafen som utforskas
Efter komprimering kan databasen söka i en större graf i stället för flera mindre. Samma top-k-begäran kan därför gå igenom ett annat kandidatlandskap även när den konfigurerade sökbudgeten verkar oförändrad.
Weaviate dokumenterar HNSW:s avvägning mellan ef och sökkvalitet: en större kandidatlista förbättrar i allmänhet träffsäkerheten, men kräver mer arbete. Nära en rangordningsgräns gör låg sökinsats resultaten känsligare för hur grafen byggs.
Ett användbart diagnostiskt test är att jämföra approximativa resultat med en sökning med högt ef-värde eller en exakt sökning på en liten testmängd. Om de exakta grannarna förblir stabila medan ANN-grannarna förändras har komprimeringen ändrat sökvägen, inte vektorerna.
Borttagningar och uppdateringar ändrar vilka noder som överlever ombyggnaden
Före komprimering kan borttagna eller ersatta poster fortfarande finnas fysiskt, med borttagningsmarkeringar eller bokföring på segmentnivå. Sökningar filtrerar bort dem, men deras historiska närvaro kan ha påverkat grafen som byggdes tidigare.
Milvus förklarar att HNSW lagrar en explicit grafstruktur utöver råvektorerna. En ombyggnad efter att föråldrade poster har tagits bort skapar en graf från den kvarvarande mängden.
Det kan ändra den lokala anslutningen kring ett dokument i hemmet även när dokumentet självt aldrig har redigerats. En anteckning kan få eller förlora en närliggande bryggnod, vilket ändrar vilken del av grafen ANN-vandringen når först.
Likheter och nästan-likheter kan vända även när avstånden inte gör det
Många privata korpusar innehåller nästan-dubbletter: upprepade manualer, versionshanterade filer, bildtexter, kopierade anteckningar eller textstycken med samma standardtext. Deras cosinus- eller skalärproduktsvärden kan vara nästan omöjliga att skilja åt.
Pinecones förklaring av HNSW visar hur grafnavigering begränsar vilka vektorer som undersöks. När två objekt ligger nära gränsen kan en annan kandidatsökväg eller ordning vid lika resultat ändra den returnerade top-k-listan utan någon meningsfull semantisk skillnad.
Applikationer bör därför undvika att behandla grannens rang 7 jämfört med rang 8 som ett beständigt identitetsanspråk. Lagra stabila dokument-ID:n och jämför de faktiska avstånden när deterministiskt beteende är viktigt.
Exakt sökning skiljer datadrift från ANN-drift
Den tydligaste metoden är att behålla en liten reproducerbar uppsättning frågor och registrera embeddingarna, avståndsmåttet, exakt top-k, approximativ top-k, indexinställningar och databasversion före underhållet.
ZimaSpaces diskussion om förändringar av embeddingdomänen vid privat sökning tar upp en annan typ av fel: själva vektorrummet förändras. Komprimering bör diagnostiseras separat eftersom den kan ändra den approximativa sökningen samtidigt som vektorrummet förblir intakt.
ZimaSpaces guide till dokumentsökning och RAG-arbetsflöden ger applikationskontexten: stabil dokumentidentitet och utvärdering är viktiga även när ANN-lagret tillåts vara approximativt.
Om de exakta resultaten förändras bör du kontrollera vektorer, filter, normalisering, mått eller dataversioner. Om de exakta resultaten förblir oförändrade men ANN-resultaten ändras är orsaken indexombyggnad, sökinsats, hantering av lika resultat eller segmentlayout.
Komprimering förväntas alltså inte garantera exakt samma rangordning av grannar byte för byte i ett approximativt index. För deterministisk rangordning krävs striktare sökning eller regler för lika resultat på applikationsnivå.
Vanliga frågor
Ändrar komprimering embeddingvektorerna?
Inte i sig. En normal komprimering eller segmentöverslagning organiserar om lagringen och indexen. Embeddingar ändras endast om applikationen bäddar in på nytt, kvantiserar om, normaliserar om eller på annat sätt skriver om vektorvärdena.
Bör exakta närmaste grannar ändras efter komprimering?
De bör förbli desamma när de kvarvarande vektorerna, måttet och den numeriska representationen är oförändrade, bortsett från verkliga poänglikheter eller detaljer i flyttalsimplementeringen.
Kan en ombyggnad av HNSW återskapa exakt den gamla rangordningen?
Inte alltid. HNSW är approximativt, och grafkonstruktionen kan vara känslig för insättningsordning, randomisering, borttagningar och implementeringsdetaljer. Exakt rangordning kräver uttömmande eller på annat sätt deterministisk jämförelse.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Tillstånd under körning kontra beständigt tillstånd i Home Assistant: Vad måste överleva en omstart?
Home Assistant sparar inte varje aktuellt värde permanent; konfiguration, register, utvalda återställda tillstånd, historik och distributionsdata har olika roller vid omstart.
Hur autentiserar Home Assistant lokala och fjärranslutna sessioner?
Lokala och fjärranslutna Home Assistant-sessioner använder samma identitetsmodell på serversidan; fjärråtkomst ändrar routningen och TLS-gränsen, men inte det grundläggande tokenflödet.
Varför kan historikfrågor i Home Assistant bli långsammare när Recorder-data växer?
Ökad loggstorlek kan höja kostnaden för historikfrågor när det begärda intervallet omfattar fler rader, cachemissar ökar eller arbete med lagring och index blir långsammare.
