Turn your real chunks into real vectors, and watch semantic similarity measured against an actual embeddings API instead of a toy example.
1What an Embedding Actually Is
An embedding model reads a piece of text and outputs a fixed-length list of numbers — typically hundreds or thousands of them — that represent the text's meaning as a point in a high-dimensional space. Texts with similar meaning end up as nearby points, regardless of whether they share any of the same words. That's what lets a search for 'PTO' find a chunk that talks about 'rolling over unused vacation days' without ever containing the literal word 'PTO'.
2Why This Uses a Real API Call
Earlier chunking exercises could run entirely offline with toy numbers, because the algorithm itself — splitting, filtering — doesn't depend on real semantic meaning. Embeddings are different: the entire value of the vector comes from a model trained on enormous amounts of real language. There's no meaningful way to fake that locally, so this lesson calls the real OpenAI embeddings endpoint with your own key.
3Step-by-Step Breakdown
From Text to Real Vectors. The chunks from last lesson are still just text — a computer can't do 'similarity search' on strings directly. An embedding model converts each chunk into a vector of numbers positioned in meaning-space, so that texts about similar topics end up geometrically close together. This lesson calls a real embeddings API, not a toy example.
Embed the Real Chunks and the Real Question. These are the PTO chunk and the Remote Work chunk from last lesson, plus the question your future chatbot needs to answer. Generate real embeddings for all three and check the similarity scores: the question should score noticeably higher against the PTO chunk than against the unrelated Remote Work chunk.
In the embeddings you just generated, why should the PTO chunk score higher against the question than the Remote Work chunk does?
- →Because the embedding model places semantically related text closer together in vector space — the PTO chunk and the PTO question share meaning, so their vectors point in a similar direction.
- →Because 'PTO' comes before 'Remote' alphabetically.
Real Vectors, Ready to Search. You just generated real embedding vectors and measured real semantic distance between them — the exact mechanism a vector database automates at scale. Next module: storing many chunks like this and building the actual similarity-search function your chatbot will call at query time.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Never Require Sight-Only Interpretation of Similarity Scores
When displaying similarity scores in a UI, pair the raw number with a text label (e.g. 'strong match') so users relying on screen readers get the same signal as a sighted user scanning for the highest number.
<span>0.87 (strong match)</span>SEO Implications
- 1
Target 'OpenAI embeddings tutorial' and 'cosine similarity example' separately
Developers search for the API mechanics and the underlying math as distinct problems while building a real retrieval pipeline.
Best Practices
Embed Your Query With the Same Model You Used for Your Documents
Vectors from different embedding models exist in incompatible spaces — mixing models between your document chunks and your live queries silently breaks similarity search.
Frequent Bugs
Re-embedding the same unchanged document chunks on every request instead of caching them.
Embed each chunk once when it's ingested and store the vector alongside the text — only the live user query needs to be embedded on every request.
Real-World Examples
Support Ticket Search
A support tool embeds every past ticket once at ingestion time and stores the vectors, so answering a new question only requires embedding the new query and comparing it against the pre-computed vectors — not re-embedding the whole ticket history every time.
query_vector = embed(user_question) # only this happens per-request