标签：#vectorsearch

Every system that does "semantic" anything — RAG pipelines, recommendation engines, image search, dedup — boils down to one operation: given this vector, find the closest ones out of millions. The vectors are embeddings, a few hundred to a couple thousand numbers each, and "closest" means closest in meaning. You'd assume the database either scans all of them (slow but correct) or uses some clever tree to jump straight to the answer. It does neither. Instead it deliberately settles for the approximately closest vectors — and that compromise is the entire reason vector search is fast enough to exist. Two algorithms do almost all the heavy lifting in practice, in pgvector, Qdrant, FAISS, and the rest: IVF and HNSW . Here's what they're actually doing under the hood, and how to choose between them. Why "exact" is off the table The natural objection is: why approximate? Just find the real nearest neighbor. In two or three dimensions you could — a k-d tree or similar structure prunes away big regions of space and finds the true closest point quickly. The trouble is that embeddings live in hundreds of dimensions, and high-dimensional space is deeply weird. It's called the curse of dimensionality . As dimensions grow, the distance to your nearest point and the distance to your farthest point drift toward being almost the same. Formally, the contrast (d_max − d_min) / d_min shrinks toward zero. When everything is roughly equidistant from everything else, a tree can't confidently say "skip this whole branch, it's too far" — the bounding regions all overlap, every branch looks plausible, and the search degrades into checking nearly everything. Exact indexes quietly collapse back into brute force. So we change the question. Instead of "prove you found the nearest," we ask "quickly find something very probably among the nearest." That's approximate nearest neighbor (ANN) search, and it swaps a guarantee for speed. The quality knob becomes recall : of the true top-k neighbors, wh

EDRSR — the Unified State Register of Court Decisions — is effectively all of Ukraine's judicial practice in open access. Today Qdrant holds **44M+ vectors : criminal (19M), civil (14.3M), commercial (5.1M), misdemeanors (5.6M). Vectorization of civil cases (CPC, justice_kind=1) — the largest cohort at 33.7M documents — runs on a dedicated EC2 instance (r6a.xlarge, 32 GB RAM, 2 TB gp3). Here's what's under the hood: models, pipeline, cost, rakes, and current status. Why Vectorize Courts When a lawyer searches "is there case law on recovering bank prepayment fees" — they don't want to open 40 decisions and read them through. They want the system to surface the top 5 most relevant ones, pull out key paragraphs, and show how courts reasoned. Full-text search (FTS) over keywords doesn't give that — it returns every document containing the word "fee", and there are thousands. For this semantic task you need vector representations of text. The model turns a paragraph from a decision into a point in a 1024-dimensional space; semantically similar paragraphs sit near each other. A kNN search in Qdrant returns the top K nearest, and an LLM composes the answer from exactly those relevant fragments. The only problem: the register is big. Very big. Scale Our prod database holds full texts of decisions starting from 2006. Breakdown by procedural type: Civil (CPC) — 33.7M documents. The largest category. Consumer, housing, labor, family. Criminal (CrPC) — 12M+ Administrative (CAS) — 14M+ Commercial (CC) — 6M+ Misdemeanors (CUaP) — 6M+ The Qdrant collection edrsr_decisions on a dedicated EC2 currently holds 44M+ vectors (122 segments, on_disk=true): | Proceeding type | justice_kind | Vectors | |—|—|—| | Criminal (CrPC) | 2 | 19,036,347 | | Civil (CPC) | 1 | 14,328,427 | | Misdemeanors (CUaP) | 5 | 5,579,432 | | Commercial (CC) | 3 | 5,098,662 | | Total | | 44,042,868 | Civil cases processed: 14.3M out of 33.7M — that's 42%. After CPC completes there will be roughly 63M+ vectors in