Gains:
- Understand that embedding turns the text into a vector in the semantic space and similar meanings are close vectors
- Explaining how ANN search works with cosine and dot similarity metrics
- Selecting common vector databases based on cost, scale and need for metadata filtering
At the heart of RAG is a single question: "Which piece of text is most similar to the user's question?" The computer processes text with numbers, not literally. That's why we need to first convert the text into numbers that carry its meaning. That's what embedding is: the process of converting a text into a sequence of numbers (vector) that represents the meaning of that text. When you finish this unit, you will know how embedding works, how similarity is measured, and how to choose the right vector database.
Embedding: Translating Meaning into Coordinates
An embedding model (a specially trained artificial intelligence) converts the text you provide into a vector of, for example, 1024 numbers. Think of this vector as a coordinate in a multidimensional space. The magic is this: texts that are similar in meaning fall into close coordinates in this space.
A simple example: “annual leave”, “vacation entitlement” and “annual paid leave” use different words but mean the same thing — their vectors are close to each other. “Payroll account” is a different matter — its vector is distant. So the user asks "how many days of vacation do I have?" When you ask, we can even find a document that does not contain the word "holiday" but says "annual leave is 14 days". This is what classic keyword search (search that matches the word exactly) cannot do.
Tip: Think of embedding as a “fingerprint of meaning.” The fingerprints of two sentences with the same meaning appear similar; Even if the words are different.
An important rule: the model you use when embedding the question should be the same model you use when embedding documents. Different models produce different spaces; coordinates become incomparable.
How to Measure Similarity?
There are several methods to measure how similar two vectors are. The most common is cosine similarity: it measures the angle between two vectors. If the angle is small (vectors pointing in the same direction), the similarity is high. The value is between −1 and 1; Close to 1 = very similar.
criterion
What does it measure?
When is it preferred?
Cosine
Angle (direction) between vectors
The most common; default in text semantic similarity
Dot product
Direction + magnitude together
If the vectors are normalized, it gives the same result as cosine; is fast
Euclidean (euclidean distance)
Straight distance between coordinates
In some clustering scenarios; less used in text
In practice, most embedding models produce normalized vectors (size set to 1); In this case, cosine and dot product give the same order. Don't be decision paralyzed: start with cosine.
Among millions of vectors, comparing them one by one at a time is slow. That's why vector databases use ANN (Approximate Nearest Neighbor) algorithms. ANN finds "almost exact closest" rather than "exact closest" very quickly. For example, the method called HNSW can return results in a few milliseconds even for 10 million vectors. You gain great speed for a small sacrifice of accuracy.
What Does Vector Database Do?
A vector database does three things at once: (1) stores vectors, (2) quickly finds vectors most similar to a query vector, (3) filters by metadata next to each vector. Metadata are the tags you attach to that piece: source file, date, department, privacy level, etc. Metadata filtering is critical in enterprise RAG; because you need to be able to set restrictions such as "search only in the Finance department's 2025 documents".
# Register to the vector database (conceptual)vektor_db.add( id="izin-politikasi-parca-3", vektor=embed("Annual paid leave is 14 days..."), text="Annual paid leave is 14 days...", metadata={"source": "ik_el_kitabi.pdf", "department": "IK", "date": "2025-06", "privacy": "ic"})
# Metadata filtered search (conceptual)result = vektor_db.search( vektor=embed("how many days of leave do I have?"), top_k=4, filter={"department": "HR", "privacy": ["internal", "on"]})
Choosing the Right Database
vehicle
Featured aspect
Suitable situation
Built-in / file-based (embedded library)
No installation, single machine
Prototype, small kit (< few hundred thousand parts)
Managed cloud service
Scaling and maintenance is not your responsibility
Production, fast growing data, small team
Open source on your own server
Full control, your data stays yours
Privacy obligation, existing infrastructure
Addition to existing database
You do not manage separate systems
Adding vector support to the DB you already use
Ask when choosing: How many pieces will there be? How critical is metadata filtering? Can data go outside the company (confidentiality)? Can the team operate an infrastructure? It's often wise to start small and expand as needed.
Weak Approach / Strong Approach
Weak (storing plain embedding, no metadata):
Just save the text and vector. Search: return the 4 most similar vectors.# Problem: cannot filter like "only current HR docs";# old/unauthorized parts may also be included in the response.
Powerful (rich metadata + filtered search):
Add source, date, department and privacy tag to each piece. Filter according to the user's authority and currentness during the search: filter = {"privacy": user_authority, "date_date": "2024-01"}# Thus, the result is both safe and up-to-date.
Three Mini Cases
Case 1 — Wrong model mix. A team embedded documents with model A and questions with model B. The searches returned meaningless results, and the correct answer rate remained at 31%. When I switched to a single model (both the same embedding model), the rate jumped to 88%. Lesson: question and document should be in the same space.
Case 2 — Privacy risk without metadata. In a healthcare company, all department documents were thrown into a single pool without metadata. When a sales associate asked a question, the system contextualized a piece of patient data. When metadata + filter was added (according to the authorization level), this risk was eliminated; In retrieval, 12 unauthorized pieces are not brought at all.
Case 3 — Scale bottleneck. An e-commerce company searched 8 million product descriptions with a simple "scan all" method; Each query took 6 seconds. When we switched to HNSW-based ANN, the time decreased to 45 milliseconds, with only 1% loss in accuracy. Lesson: ANN is mandatory in the big set.
Common mistakes
- Embedding the question and document with different models: The results are meaningless; always one model.
- Skipping metadata: You can't filter; You lose control of privacy and up-to-dateness.
- Mistaking Embedding for encryption: Embedding carries reversible information; It is wrong to assume that sensitive data is "hidden".
- Building unnecessarily large infrastructure on a small set: A giant cluster managed for 5,000 parts is unnecessary complexity.
- Don't worry too much about the similarity criterion: Start with cosine in the text; Fine tuning comes later.
Caution: Embedding embeds the meaning of the text in numbers, but does not "destroy" the content. If a vector database is leaked, the original stored texts (in most installations the text is also stored) are also compromised. Keep the vector repository as confidential as the documents within it.
In summary
- Embedding turns text into a vector of numbers that carries its meaning; Similar meanings are close vectors.
- Similarity is often measured by cosine; For normalized vectors, dot product gives the same result.
- In big data, ANN (e.g., HNSW) replaces exact search: great speed with little sacrifice of accuracy.
- Vector database performs vector storage + similarity search + metadata filtering; metadata is essential for enterprise RAG.
- The question and the document must be translated with the same embedding model; otherwise the coordinates cannot be compared.
Application task
Extract 10 short passages (3-6 sentences each) from the document you selected in the previous unit. (1) Design at least three metadata tags for each piece (source, date, and a third appropriate to your business context: department, product, privacy, etc.). (2) Write which metadata filter should be applied for 3 different user questions. (3) Find 3 question-part pairs that express the same meaning in different words (e.g. “vacation entitlement” ↔ “annual leave”) and explain in one sentence why they will not match keyword search but will match embedding.
checklist
- [ ] I can tell that embedding turns the text into a vector in the semantic space and similar meanings are close.
- I know that [ ] Cosine similarity measures angle and is the default preference in text.
- [ ] I can explain why ANN is necessary in big data.
- [ ] I know why metadata is critical for confidentiality and freshness control.
- [ ] I follow the rule of translating the question and the document with the same embedding model.