> Source: easy-learn-ai / commit 9527094 > New module: Vector Database
1. The Library Problem
Imagine walking into a library with no classification system: all books piled together, no catalog cards, no shelf numbers, no index. To find a book about "how annual leave is settled when resigning," you would have to flip through every volume one by one.
This is the dilemma traditional databases face with "similar meaning." A traditional database is like a meticulous archivist. Ask it "Where is document number POL-HR-2047?" and it answers instantly. But ask "Can unused annual leave be cashed out after an employee resigns?" and it freezes—because the document says "unused leave conversion rules." Completely different wording, same meaning.
Human language is tricky: the same idea has a hundred phrasings. Traditional databases match characters, not meaning—a fatal shortcoming in the LLM era, where AI must first retrieve *relevant* content, not just *literally matching* content. Vector databases exist to solve this problem.
2. Vectors: A Numeric ID for Every Piece of Text
The core idea in one sentence: turn meaning into numbers, and turn "similar or not" into "near or far."
Step 1: Chunking
A several-hundred-page HR handbook should not become a single vector—that's too coarse. The first step is splitting documents into small chunks, like tearing a book into sticky notes with one or two sentences each. Each note becomes an independent retrieval unit:
> Upon resignation, unused annual leave is converted based on the employee's average salary over the last twelve months.
Step 2: Embedding
An embedding model (such as BGE or OpenAI's text-embedding-3) converts each chunk into a string of numbers—typically hundreds to thousands of dimensions:
> [0.42, -0.11, 0.78, 0.23, -0.36, 0.64, 0.08, -0.51, ...]
The numbers have no human-readable meaning individually. But crucially, texts with similar meanings have vectors that are close together in mathematical space—like an automatic, semantic shelving system.
3. Indexing: Build Roads in Advance
With 100 million vectors, comparing one-by-one is computationally prohibitive. So vector databases build an index in advance, connecting nearby vectors with "roads" in vector space. Queries start from an entry point and walk toward nearer neighbors until no improvement is found.
This is Approximate Nearest Neighbor (ANN) search: it doesn't find the absolute closest vectors, just ones "close enough"—trading a little precision for massive speed. Common index algorithms include HNSW (Hierarchical Navigable Small World graphs) and IVF (inverted file index). Different databases choose different approaches, but the principle is the same: organize ahead of time, retrieve quickly.
4. Querying: Turn the Question into a Vector
When a user asks "Can annual leave be cashed out after resignation?" the system:
1. Embeds the question using the same embedding model used at ingestion. 2. Finds neighbors in vector space and retrieves the corresponding original text.
Example results:
> 1. Resignation settlement rules (similarity 0.94) ← best match > 2. Unused annual leave conversion (similarity 0.89) ← also close > 3. Leave swap application process (similarity 0.52) ← irrelevant, skip
Note: the user said "cash out," but the database returned "conversion." Keyword search would miss this; vector search matches meaning, not wording—that is its power.
5. But Vectors Are Not Omnipotent
Dates, amounts, IDs: one character off, meaning completely changes
- Querying "which version takes effect on 2026-03-01?" might return the "2025 leave policy"—semantically close, but a full year off.
- Asking whether the reimbursement cap is 800 or 1000 might return the right policy with the wrong numbers.
- Querying "POL-HR-2047" might return a broad "HR policy collection" instead of the exact document.
Permissions, regions, versions: hard constraints can't rely on "similarity"
A search for "resignation rules" might return three high-scoring results: the correct current China version, an outdated 2024 version, and an HR-internal document the user isn't allowed to see. Enterprise retrieval isn't just about finding similar content—it must find the right content.
6. Hybrid Search: Meaning Plus Rules
Mature systems don't rely on vector search alone:
1. Vector search handles semantic recall — finding meaning-related candidates ("leave conversion" recalls "cashing out leave"). 2. Keywords/filters handle precise screening — region filters, version filters, permission filters, exact ID matching.
This combination is Hybrid Search: vectors do recall, filters do screening. The easy-learn-ai module includes an interactive slider letting users adjust the balance between vector weight and keyword weight, making the trade-off tangible.
7. Technology Selection: Right Fit, Not Best
| Solution | Best for | Characteristics | |----------|----------|-----------------| | pgvector | Small teams already on Postgres | Plugin form, zero extra ops, good for prototypes and mid-scale | | Qdrant | Dedicated vector service without heavy ops | Ready out of the box, vector + keyword support, solid Rust performance | | Milvus | Very large data with an infra team | Many index options, strong distribution, enterprise features | | Pinecone | Fast launch, minimal ops | Fully managed, simple API, but costly | | Elasticsearch | Existing search systems adding semantics | Strong keyword search; vectors are a bonus |
Three selection questions: How much data? (millions → pgvector is fine; billions → Milvus). Do you want to manage services? (no → Pinecone; yes → Qdrant/Milvus). Do you need keyword queries? (IDs, dates, exact fields → pick one with built-in hybrid search).
8. From Vector Database to RAG: A Bigger Puzzle
A vector database is not the end goal—it's one step in RAG (Retrieval-Augmented Generation):
1. User asks a question 2. Question is embedded 3. Vector retrieval finds the most relevant passages 4. Filtering removes disallowed results (permissions, version, region) 5. Retrieved text + question are assembled into context 6. The LLM generates an answer grounded in real material
The vector database handles step 3 (and part of step 4)—a precise "salvage diver" pulling relevant fragments from an ocean of documents. The easy-learn-ai learning path chains Embedding → Vector Database → RAG so each piece's role becomes clear.
9. Closing Thoughts: Teaching Machines to "Smell" Meaning
Humans instantly recognize that "how is annual leave handled at resignation" and "can unused leave be exchanged for money" mean the same thing—through semantic understanding, not character matching. Vector databases automate and scale this process, letting machines "smell similar scents" across billions of documents.
But they are not omnipotent: dates can't be guessed, amounts can't be off, permissions can't be crossed. Those hard rules need keywords, filters, and human engineering. The best systems always combine intelligent semantics with rigorous rules—vector databases give AI intuition, but human engineering wisdom makes it reliable.
---
> 📚 Further reading: the easy-learn-ai learning path > - Stop 1: Embedding (how text becomes vectors) > - Stop 2: Vector Database (how vectors are stored and searched) ← this article > - Stop 3: RAG (how retrieved content is fed to the AI)
---
*This article is based on easy-learn-ai commit 9527094 (2026-06-08). The project uses interactive web components to break vector database concepts into hands-on steps—from document ingestion, index building, and nearest-neighbor search to filtering rules, hybrid retrieval, and selection guidance, with visual demos at every step.*