Vector Embedding Visualizer

Why Visualize Embeddings

Embeddings are the engine behind modern AI search, RAG, and semantic understanding, but they're invisible. A 1536-dimensional vector is just a list of numbers. You can't look at it and tell whether two pieces of text are similar.

That opacity is a problem when you're building RAG systems. The retriever returns the wrong chunk; you don't know why. Re-ranking helps but adds latency. You tune chunk size and pray. A visualizer makes embeddings concrete: paste in texts, see scores, build intuition.

Cosine Similarity in Practice

Cosine similarity measures the angle between two vectors:

The result ranges from -1 (opposite) to 1 (identical). For embedding models trained on natural language, almost all pairs fall between 0 and 1, true opposites are rare. Typical ranges:

• 0.95–1.0: paraphrase or near-duplicate ("The cat sat on the mat" ↔ "A cat is sitting on the mat").
• 0.85–0.95: same topic, different wording ("How do I reset my password?" ↔ "Forgot my password").
• 0.70–0.85: related topic ("password reset" ↔ "account security").
• 0.50–0.70: tangentially related ("password reset" ↔ "user profile settings").
• Below 0.50: unrelated ("password reset" ↔ "weather forecast").

These ranges depend on the model. Some models compress similarity into a narrower band (everything between 0.6 and 0.95); others spread it wider. Calibrate your thresholds per model.

Common Embedding Failure Modes

Surface-form bias. Models often score lexically similar texts higher than semantically similar ones. "The dog barked" might score higher against "The dog ran" (shared subject) than against "The puppy made noise" (true paraphrase). Modern models handle this better, but it still happens with shorter texts.

Length sensitivity. Embeddings of very short text (1–3 words) are unstable. Two single words can have surprisingly high similarity for nonsensical reasons. RAG works best when chunks are roughly comparable in length.

Domain mismatch. A model trained on web data may not understand medical or legal jargon well. "MI" (myocardial infarction) won't cluster near "heart attack" if the model never saw the abbreviation. Specialized domains often benefit from fine-tuned embedding models.

Negation blindness. "I love this" and "I hate this" can score surprisingly high. Embedding models often capture topic and tone but miss simple negation. If your application depends on detecting sentiment polarity, embeddings alone aren't enough.

Using the Visualizer for RAG Debugging

A standard RAG debugging workflow:

1. Paste your user question as the first text.
2. Paste the chunks your retriever returned as additional texts.
3. Compare similarity scores. The highest-scoring chunk is what the retriever ranked first.
4. Compare against ground truth. If you know which chunk should have won, paste that too. Is it close in similarity, or is the model fundamentally not seeing it as relevant?

If the wrong chunk wins by a small margin, try:

• Rewording the question to match the chunk's vocabulary.
• Splitting chunks differently (smaller chunks often score higher).
• Adding metadata (document title, section header) to chunks.
• Re-ranking with a cross-encoder for the top-K candidates.

If the wrong chunk wins by a large margin, the embedding model may not be a good fit for your domain. Consider a fine-tuned or domain-specific model.

Building Intuition

Some experiments worth running:

Test paraphrases. Generate 5 ways to ask the same question. Verify they all have high similarity. If one paraphrase scores much lower, your retriever will miss users who phrase things that way.

Test distractors. Take a real query and a chunk that seems relevant but isn't. Score them. If similarity is high, you've found a false-positive pattern that will hurt RAG precision.

Test scaling. Compare a 50-word chunk to a 500-word chunk on the same topic. Embedding quality often degrades for longer text, the embedding averages too many meanings. This guides your chunking strategy.

Test multilingual. If your app supports multiple languages, check whether the same idea in English and Spanish has high similarity. Some models are strongly multilingual; others aren't.

Embedding Models in Production

Common production choices:

• OpenAI text-embedding-3-small (1536 dims, cheap, strong): good default.
• OpenAI text-embedding-3-large (3072 dims): better quality, higher cost.
• Cohere embed-english-v3 (1024 dims): strong English performance, supports compression.
• BGE / E5 / Nomic Embed (open source): self-hosted alternatives, competitive quality.
• Voyage AI (various): domain-specialized models for code, finance, law.

This tool runs a smaller in-browser model. Use it to build intuition and prototype; verify thresholds against your production model before shipping.

Beyond Cosine: Other Similarity Measures

• Dot product: similar to cosine but sensitive to vector magnitude. Some models recommend dot product because their vectors are normalized.
• Euclidean distance: physical distance in vector space. Inversely related to similarity. Rarely used directly for retrieval.
• Manhattan distance: sum of absolute differences. Used in some specialized contexts.

For most embedding models, cosine and dot product give similar rankings. Differences matter at the margins, verify with A/B testing in your specific setup.

Practical Workflows

1. RAG retrieval debugging. Paste query + retrieved chunks; identify why retrieval succeeded or failed.
2. Chunking strategy tuning. Test how different chunk sizes affect retrieval scores for known good pairs.
3. Synonym expansion. Find synonyms a user might use; verify the embedding model treats them as similar.
4. Threshold calibration. Run many positive and negative pairs to find the right similarity cutoff for your application.
5. Cross-domain testing. Verify your embedding model handles your domain's jargon before committing to it.
6. Prompt engineering for retrieval. When using HyDE or query rewriting, compare the rewritten query's embedding to chunks vs. the original.

Privacy

Embedding generation runs locally in the browser. Queries, document chunks, and prompts never leave the page, important when debugging over confidential customer data, internal documentation, or unreleased product specs.