Hoe ruilt HNSW zoeken geheugen in voor recall in een lokale vectordatabase?
HNSW ruilt geheugen in voor recall door een navigeerbare buurgraph op te slaan. De verbondenheid en zoekbreedte daarvan bepalen hoe grondig zoekopdrachten nabijgelegen vectoren verkennen.
Een lokale vectordatabase kan embeddings bevatten voor huishoudelijke documenten, OCR-tekst, fotometadata, handleidingen, transcripten en applicatierecords. Bij een brute-forcezoekopdracht wordt de query met elke vector vergeleken, terwijl HNSW via een gelaagde graph dezelfde bruikbare omgeving probeert te bereiken. Die snelkoppeling is snel omdat de database vooraf extra graphstructuur opslaat. De nauwkeurigheid hangt af van hoe sterk die graph verbonden is en hoeveel kandidaten een query mag verkennen.
HNSW voegt een gelaagde nabijheidsgrafiek rond de opgeslagen vectoren toe
Elke vector wordt een knooppunt dat met geselecteerde buren is verbonden. Een kleine subset van de knooppunten komt ook in hogere lagen voor, waardoor langeafstandsroutes ontstaan die de zoekopdracht snel naar het gebied leiden waar waarschijnlijk nabije vectoren te vinden zijn.
Een gelaagde nabijheidsgrafiek geeft HNSW grove routes in de bovenste lagen en steeds fijnmazigere buur-navigatie onderaan de hiรซrarchie.
Die opgeslagen verbindingen vormen de eerste geheugenafweging. In tegenstelling tot een platte vectorarray bewaart de index topologie die tijdens het doorlopen beschikbaar moet blijven.
De hiรซrarchie vermindert hoeveel van de collectie een normale query bezoekt, maar blijft benaderend: het pad kan een echte buur missen wanneer de graph of het zoekbudget niet de juiste route blootlegt.
De M-parameter gebruikt meer graphgeheugen om meer routes te creรซren
HNSW-implementaties bieden een verbindingsparameter die meestal `m` of `M` wordt genoemd. Als deze waarde wordt verhoogd, kunnen knooppunten meer buurverbindingen onderhouden. Daardoor ontstaan alternatieve paden door dichte of onregelmatige delen van de vectorruimte.
Een hogere HNSW-m-waarde slaat meer buurverbindingen per knooppunt op. Dit verbetert doorgaans de navigatiemogelijkheden en recall, maar verhoogt ook het graphgeheugen en de bouwwerkzaamheden.
De toename in geheugengebruik komt door graphverbindingen en bijbehorende indexstructuren, niet doordat de oorspronkelijke embeddingwaarden groter worden. Bij miljoenen vectoren stapelen enkele extra verbindingen per knooppunt zich op over de hele collectie. Een lagere `m` kan een geheugenbeperkte homeserver beter hanteerbaar maken, maar een te ijle graph biedt de zoekopdracht minder manieren om lokale doodlopende wegen te omzeilen en kan de recall verlagen.
Ef-constructie gebruikt meer bouwwerk om de graph zelf te verbeteren
De kwaliteit van de graph wordt ook bepaald terwijl vectoren worden ingevoegd. `ef_construct` bepaalt hoe breed de kandidaatbuurt wordt onderzocht voordat verbindingen voor een nieuw knooppunt worden gekozen.
Met efConstruction als regelknop voor bouwkwaliteit kan het construeren van de index een bredere kandidaatbuurt onderzoeken voordat verbindingen worden gekozen. Dit verbetert de graphkwaliteit, maar kost meer werk tijdens het bouwen.
Deze kosten worden tijdens het construeren of opnieuw opbouwen betaald, niet bij elke query. Voor een privรฉcorpus dat langzaam verandert, kan meer bouwtijd aanvaardbaar zijn als dit de zoekkwaliteit verbetert zonder de vectorprecisie permanent te verhogen.
Extra bouwwerk kan echter niet onbeperkt compenseren voor een ernstig te kleine graph. `m`, de constructiebreedte, de gegevensverdeling en de invoeggeschiedenis beรฏnvloeden elkaar.
Ef-search gebruikt querywerk in plaats van permanent graphgeheugen
Bij het uitvoeren van een query houdt HNSW een kandidatenfront bij en onderzoekt het veelbelovende graphknooppunten. Een parameter die meestal `ef`, `ef_search` of `hnsw_ef` wordt genoemd, bepaalt hoeveel kandidaten tijdens die doorloop in aanmerking blijven komen.
Door de zoekbreedte te vergroten, kan een verzoek meer graphkandidaten bekijken voordat de dichtstbijzijnde resultaten worden gekozen. Dit verhoogt meestal de recall, maar ook de querylatentie.
In tegenstelling tot `m` vereist een hogere query-`ef` niet dat elk opgeslagen knooppunt permanent meer verbindingen bijhoudt. De belangrijkste kosten bestaan uit extra afstandsberekeningen, geheugentoegangen en latentie voor dat verzoek. Hierdoor heeft een homeserver twee verschillende knoppen: graphverbondenheid bepaalt de permanente voetafdruk van de index, terwijl de querybreedte alleen kan worden verhoogd voor moeilijke zoekopdrachten die het extra werk rechtvaardigen.
Vectorcompressie neemt de kosten van de HNSW-graph niet weg
Door embeddings te kwantiseren kan elke opgeslagen vector veel kleiner worden, maar HNSW heeft nog steeds de buurrelaties nodig. De totale index bevat daarom ten minste twee belangrijke geheugencomponenten: vectordata en graphtopologie.
Zelfs wanneer vectorwaarden zijn gecomprimeerd, verkleint kwantisatie de graphverbindingen niet; HNSW heeft nog steeds topologie, ID's en gerelateerde structuren rond die vectoren nodig.
Daarom leidt een vectorcompressieverhouding van 4x of meer niet automatisch tot een even grote totale vermindering van het HNSW-geheugen. Graphverbindingen, object-ID's, metadata, allocator-overhead en caches blijven bestaan.
Meet op een kleine homeserver de volledige resident set van de collectie in plaats van het RAM-gebruik alleen op basis van vectordimensies te schatten.
Recall moet worden gemeten aan de hand van exacte buren, niet afgeleid uit instellingen
Een hogere `m` en `ef` sturen het systeem meestal richting een betere recall, maar geen enkele parameterwaarde garandeert een vaste nauwkeurigheid voor elk embeddingmodel, elke corpusgrootte of elke documentverdeling.
De kosten van HNSW-graphgeheugen in meerdere RAG-collecties stapelen zich op wanneer verschillende privรฉcollecties actief blijven naast lokale modellen, metadata-indexen, caches en andere homeserverdiensten.
Maak een representatieve queryset en vergelijk benaderende resultaten met een exacte scan op een beheersbaar sample. Houd recall, latentie, index-RAM, bouwtijd en het effect van gelijktijdige verzoeken bij. De praktische HNSW-afweging is dus niet: โmeer RAM betekent altijd beter zoeken.โ Het gaat erom voldoende graphverbondenheid en queryverkenning te kiezen om de gemeten recall te halen zonder de rest van de lokale AI-stack te verdringen.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kunnen thuiscamera's gebeurtenissen synchroniseren zonder cloudtijdservices?
Een mechanismegerichte uitleg van cameratiijd zonder cloud, de afwegingen bij gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een lokale AI-service beschadigde modellagen detecteren vรณรณr de inferentie?
Een mechanismegerichte uitleg van detectie van beschadigingen in modellagen, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een RAG-systeem worden hersteld zonder elke embedding opnieuw te genereren?
Een mechanismegerichte uitleg van RAG-herstel zonder opnieuw te embedden, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
