Test semantic search with real embeddings, no infrastructure
Before you build a vector database, you often just want to know: will embeddings actually rank the right document at the top for my queries? This tool lets you paste a query and a list of candidates, embeds them all with your own OpenAI key in a single batched request, and ranks the candidates by cosine similarity — the same operation a vector store performs, but with zero setup.
How it works
You provide your OpenAI API key, a query, and one candidate per line. The tool sends all the texts to the embeddings endpoint in one request, retrieves the vectors, and computes cosine similarity between the query vector and each candidate vector. Because OpenAI embeddings are normalized, cosine similarity is a clean relevance measure: scores near 1 mean strong semantic overlap. Candidates are sorted highest-first so the best match is at the top.
Understanding cosine similarity scores
Cosine similarity measures the angle between two vectors in high-dimensional space, not the distance between their endpoints. It ranges from -1 to +1:
- Scores above 0.90 usually indicate the candidate is closely related to the query — either a paraphrase, a direct answer, or content from the same specific domain.
- Scores 0.75–0.90 often represent topically related content. In a retrieval system, these are typically the chunks you want in your top-5.
- Scores below 0.70 usually indicate weak or coincidental similarity. In a vector database, you would typically set a minimum score threshold here to filter noise.
- Scores near 0 indicate orthogonal meaning — the model found no strong semantic relationship.
These thresholds are approximate and vary by model and domain. Code embeddings behave differently from prose; medical text sits in a different part of the embedding space from general language.
Iterating on chunking with this tool
This tool is particularly useful for testing how different chunking strategies affect retrieval. A common workflow:
- Write 5 representative queries for your use case.
- Paste the same source document chunked in different ways — for example, 200-token chunks versus 500-token chunks — as your candidates.
- Compare which chunking strategy puts the right candidate at rank 1 for each query.
If the 200-token chunks outrank the 500-token chunks for most queries, that is a strong signal that finer chunking is better for your content type. If the opposite, your content benefits from more context in each chunk.
Worked example: FAQ retrieval test
Suppose you are building a support chatbot over a product FAQ. Your query is “how do I reset my password?” and you paste five candidate chunks from the FAQ:
Candidate 1: To reset your password, visit the login page and click "Forgot password"...
Candidate 2: Account security features include two-factor authentication and session management...
Candidate 3: You can update your billing details in the Billing section of Settings...
Candidate 4: If you are locked out of your account, contact [email protected]...
Candidate 5: Password requirements: minimum 8 characters, at least one number and one symbol...A well-trained embedding model should rank Candidate 1 highest (it directly answers the question), with Candidate 4 second (locked out is related to password reset), and the others trailing. If Candidate 2 or 3 ranks above Candidate 4, the embedding model is not capturing the intent of the query well for this content — which tells you to try a different model or query phrasing.
Tips and notes
Your key never leaves your browser except to call OpenAI directly, and it is not stored. Start with text-embedding-3-small — it is inexpensive and accurate enough to validate most retrieval ideas; move to 3-large only if you need the extra precision. For production, layer a reranker on top of the top vector results to push relevance even higher for the final response.