{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"ai/nearest-neighbour-search","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/ai/nearest-neighbour-search/","da":"https://cmaintz.github.io/tech-atlas/da/terms/ai/nearest-neighbour-search/"},"term":{"en":"Nearest-neighbour search","da":"Nærmeste-nabo-søgning"},"aka":{"en":["approximate nearest neighbour search","vector search"],"da":["approksimativ nærmeste-nabo-søgning","vektorsøgning"]},"domain":["ai"],"cluster":"retrieval","layer":"application","status":"current","summary":{"en":"Finding the few stored items that sit closest to a given one, usually trading a little exactness for a lot of speed.","da":"At finde de få gemte elementer, der ligger tættest på et givet element, som regel ved at ofre en smule grundighed for meget mere fart."},"body":{"formal":{"en":"The task of returning the k stored embeddings closest to a query embedding under a chosen distance or cosine similarity; approximate methods group or link the stored items in advance so only a small share must be checked.","da":"Opgaven at returnere de k gemte embeddings, der ligger tættest på en forespørgsels embedding målt med en valgt afstand eller cosinuslighed; approksimative metoder grupperer eller forbinder de gemte elementer på forhånd, så kun en lille del skal tjekkes."},"plain":{"en":"Like looking for the nearest open pharmacy - you do not measure the distance to every pharmacy in the country, you check the few in your part of town.","da":"Som at lede efter det nærmeste åbne apotek - man måler ikke afstanden til hvert apotek i landet, man tjekker de få i sin egen bydel."},"inPractice":{"en":"When a case officer in a municipality opens a building case, the system shows “similar earlier cases” from four million documents within a twentieth of a second by checking only a few thousand likely ones.","da":"Når en sagsbehandler i en kommune åbner en byggesag, viser systemet “lignende tidligere sager” blandt fire millioner dokumenter på en tyvendedel af et sekund ved kun at tjekke nogle få tusinde sandsynlige."},"whyItMatters":{"en":"Without the shortcut, meaning-based search over large collections would be far too slow; with it, the true best match is sometimes silently missed.","da":"Uden genvejen ville betydningsbaseret søgning i store samlinger være alt for langsom; med den bliver det bedste match af og til overset uden varsel."}},"deepDive":{"en":"Exact k-nearest-neighbour search compares the query with all N stored vectors, costing O(N · d) per query for dimension d. That is fine for tens of thousands of vectors, especially on a GPU, but not for hundreds of millions under a latency budget. Space-partitioning trees such as k-d trees, which work well in two or three dimensions, degrade towards brute force at the several hundred dimensions typical of embeddings, a symptom of the curse of dimensionality. Approximate nearest-neighbour (ANN) methods therefore accept that some true neighbours are missed, and are evaluated by recall@k (the share of the exact top k that the index returns) against queries per second, memory and build time, as in the public ann-benchmarks suite.\n\nThree families dominate. Locality-sensitive hashing (Indyk and Motwani, 1998) hashes vectors so that close ones collide with high probability; it has strong theoretical guarantees but usually needs much memory for high recall. Inverted-file indexes (IVF) cluster the data with k-means into nlist cells and, at query time, scan only the nprobe cells whose centroids are nearest; recall and cost both rise with nprobe. Product quantization (Jégou, Douze and Schmid, 2011) compresses each vector by splitting it into m sub-vectors and replacing each with the index of one of 256 learned centroids, so a vector takes m bytes and distances are computed from lookup tables; IVF-PQ in the FAISS library (Johnson, Douze and Jégou, 2017) scales this to billions of vectors on GPUs.\n\nGraph indexes are the current default in vector databases. HNSW (Malkov and Yashunin, 2018) builds a multi-layer proximity graph: each node links to up to M neighbours (2M on the bottom layer), upper layers are sparse samples that act as express lanes, and search descends greedily from the top layer, keeping a candidate list of size efSearch on the bottom layer. Larger M and efConstruction improve graph quality at the cost of memory and build time; efSearch is the per-query recall/latency dial. HNSW is memory-resident and fast but costly in RAM, so DiskANN (Subramanya et al., 2019), built on the Vamana graph, keeps the graph on SSD with compressed vectors in memory for billion-scale collections.\n\nMost production problems come from filters and churn. Post-filtering, where the index is searched first and metadata or permission conditions are applied afterwards, can return fewer than k results when the filter is selective: pgvector's documentation notes that with the default hnsw.ef_search of 40 and a condition matching 10 % of rows, only about four rows match on average, which is why pgvector 0.8.0 (November 2024) added iterative index scans. Pre-filtering can break graph connectivity or fall back to brute force. Deletions in graph indexes are usually tombstones that degrade recall until the index is compacted or rebuilt, and recall should be monitored in production against an exact search on a sample of queries rather than assumed from benchmarks.","da":"Eksakt k-nærmeste-nabo-søgning sammenligner forespørgslen med alle N gemte vektorer, hvilket koster O(N · d) pr. forespørgsel ved dimension d. Det går fint for titusinder af vektorer, især på en GPU, men ikke for hundreder af millioner inden for et latenstidsbudget. Rumopdelende træer som k-d-træer, der virker godt i to eller tre dimensioner, forringes mod brute force ved de flere hundrede dimensioner, som embeddings typisk har, et symptom på dimensionalitetens forbandelse. Metoder til approksimativ nærmeste-nabo-søgning (ANN) accepterer derfor, at nogle rigtige naboer overses, og vurderes efter recall@k (andelen af den eksakte top k, som indekset returnerer) over for forespørgsler pr. sekund, hukommelse og byggetid, som i den offentlige ann-benchmarks-suite.\n\nTre familier dominerer. Locality-sensitive hashing (Indyk og Motwani, 1998) hasher vektorer, så nærliggende vektorer med høj sandsynlighed kolliderer; metoden har stærke teoretiske garantier, men kræver som regel meget hukommelse for høj recall. Inverted file-indeks (IVF) klynger data med k-means i nlist celler og scanner ved forespørgslen kun de nprobe celler, hvis centroider ligger nærmest; både recall og pris stiger med nprobe. Produktkvantisering (Jégou, Douze og Schmid, 2011) komprimerer hver vektor ved at dele den i m delvektorer og erstatte hver med indekset for en af 256 lærte centroider, så en vektor fylder m bytes, og afstande beregnes ud fra opslagstabeller; IVF-PQ i FAISS-biblioteket (Johnson, Douze og Jégou, 2017) skalerer det til milliarder af vektorer på GPU'er.\n\nGrafindeks er i dag standard i vektordatabaser. HNSW (Malkov og Yashunin, 2018) bygger en proksimitetsgraf i flere lag: Hver knude forbindes med op til M naboer (2M i det nederste lag), de øvre lag er tynde udsnit, der fungerer som motorveje, og søgningen går grådigt nedad fra det øverste lag og holder en kandidatliste af størrelsen efSearch i det nederste lag. Større M og efConstruction forbedrer grafens kvalitet mod mere hukommelse og længere byggetid; efSearch er drejeknappen mellem recall og ventetid pr. forespørgsel. HNSW ligger i hukommelsen og er hurtig, men dyr i RAM, så DiskANN (Subramanya m.fl., 2019), bygget på Vamana-grafen, holder grafen på SSD med komprimerede vektorer i hukommelsen til samlinger i milliardskala.\n\nDe fleste driftsproblemer kommer fra filtre og løbende ændringer. Efterfiltrering, hvor indekset søges først og metadata- eller rettighedsbetingelser anvendes bagefter, kan returnere færre end k resultater, når filteret er selektivt: pgvectors dokumentation bemærker, at med standardværdien hnsw.ef_search på 40 og en betingelse, der matcher 10 % af rækkerne, matcher kun omkring fire rækker i gennemsnit, og derfor tilføjede pgvector 0.8.0 (november 2024) iterative indeksscanninger. Forfiltrering kan bryde grafens sammenhæng eller falde tilbage til brute force. Sletninger i grafindeks er som regel tombstones, der forringer recall, indtil indekset komprimeres eller genopbygges, og recall bør overvåges i drift mod en eksakt søgning på et udsnit af forespørgsler frem for at blive antaget ud fra benchmarks."},"edges":[{"type":"requires","to":"ai/embedding","confidence":"high","strength":"normal"},{"type":"part-of","to":"ai/vector-database","why":{"en":"Fast lookup of the closest embeddings is the core job a vector database is built around.","da":"Hurtigt opslag af de nærmeste embeddings er kerneopgaven, som en vektordatabase er bygget op omkring."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"ai/semantic-search","why":{"en":"Semantic search depends on it to pick the closest texts out of millions in time to answer.","da":"Semantisk søgning er afhængig af den for at udvælge de nærmeste tekster blandt millioner, hurtigt nok til at svare."},"confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"Malkov & Yashunin (2018), Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs","tier":"reference","publisher":"IEEE TPAMI"},{"title":"Johnson, Douze & Jégou (2017), Billion-scale similarity search with GPUs","tier":"reference"},{"title":"pgvector - Open-source vector similarity search for Postgres (README)","url":"https://github.com/pgvector/pgvector","tier":"official-doc","publisher":"pgvector project"}],"draft":true}