Embeddings convert text into high-dimensional number vectors — 1,536 dimensions with text-embedding-3-small — so that similar meanings sit close together in vector space. Vector databases like pgvector, Pinecone and Azure AI Search store those vectors and answer nearest-neighbour queries in milliseconds. This is the foundation under semantic search, RAG and every AI knowledge assistant.
An embedding is a fixed-length array of floating-point numbers — a vector — that represents the meaning of a piece of text. OpenAI's text-embedding-3-small outputs 1,536 dimensions per input; text-embedding-3-large outputs 3,072. Texts with similar meaning produce vectors that are close together, so “0x87D1041C detection failed” lands near “Win32 app detection rule did not match” even though the two share almost no words. A vector database (pgvector on PostgreSQL, Pinecone, Qdrant, Azure AI Search) stores millions of these vectors and answers “which stored vectors are closest to this query vector?” using cosine similarity — typically in single-digit milliseconds thanks to ANN indexes like HNSW.
Keyword search breaks the moment users describe a problem instead of typing the exact error string. Embeddings fix that: search becomes meaning-based, so “laptop stuck during setup” finds ESP timeout documentation that contains neither word. For IT teams this is the difference between a knowledge base people actually use and one they ignore. It is also the prerequisite for RAG (topic 14), because retrieval quality caps answer quality. And adoption is cheap: pgvector adds vector search to a PostgreSQL database you already run, while Azure AI Search gives hybrid keyword + vector scoring out of the box.
The pipeline has an offline indexing phase and an online query phase. Offline: split source documents into chunks — 500-800 tokens with 50-100 tokens of overlap is a strong default — attach metadata (source URL, product, date), send each chunk to the embedding model, and upsert the resulting vectors into the database. Online: embed the user query with the same model, run a nearest-neighbour search (top_k = 5), filter by metadata, and return the matching chunks. Cosine similarity ranges from -1 to 1 (practically 0-1 for text): a relevant chunk usually scores 0.35-0.55 against a well-phrased query, while irrelevant chunks sit near 0.1-0.2. The same model must embed both documents and queries — mixing models silently destroys accuracy.
Text (log line, KB article, doc page)
↓
Embedding Model (text-embedding-3-small)
↓
Vector [0.12, -0.83, 0.44, … ×1536]
↓
Vector Database (pgvector / Pinecone /
Azure AI Search)
↓
Similarity Search → top_k nearest chunksCloudEngineerHub's Logs Analyzer (/rca) demonstrates the concept in production: alongside its 260-rule database it uses semantic matching so that pasting “company portal stuck at account setup” surfaces the Autopilot ESP symptom rules even though the text contains no error code at all. Enterprise examples: Microsoft's Security Copilot embeds incident summaries to surface similar past incidents, and support teams embed their Intune and Autopilot KB articles so an engineer can ask “Autopilot fails after ESP with 0x800705B4” and get the right article plus its neighbours — prerequisites, related codes — in a single query.
Split each KB article or exported log into 500-800 token chunks with 50-100 tokens of overlap, so a fact that straddles a boundary stays findable. Attach metadata to every chunk: sourceUrl, product (“Intune”, “Autopilot”), docType and lastVerified.
Call the embeddings endpoint — OpenAI: POST /v1/embeddings with model “text-embedding-3-small” and input: [chunk1, chunk2, …]. You get one 1,536-float vector per chunk. Batch 100-500 inputs per request to stay inside rate limits.
With pgvector: CREATE EXTENSION vector; create a table with an embedding vector(1536) column and upsert rows. With Pinecone or Azure AI Search, create an index with the same dimension (1536) and your metadata schema — the dimension must match the model exactly.
At request time embed the question with the same model, then run a top_k = 5 nearest-neighbour query. Filter by metadata first (product = “Autopilot”), then rank by cosine similarity. Log scores with every result.
Relevant chunks typically land at 0.35-0.55 cosine similarity. If your top result scores below ~0.25, the query is probably outside the corpus — return “no confident match” instead of a weak chunk. Watch these bands; they are your quality dashboard.
CREATE EXTENSION vector; -- then: SELECT title, 1 - (embedding <=> $1) AS similarity FROM doc_chunks ORDER BY embedding <=> $1 LIMIT 5;Embeddings are reversible enough to leak: researchers have reconstructed inputs from vectors, so never embed secrets, passwords or unredacted customer data. A vector database inherits every permission problem of its source documents — enforce access control at query time; metadata filters alone are not a security boundary, pair them with row-level security. On Azure, prefer Azure AI Search with Entra ID authentication and RBAC over open API keys, and never ship the embedding API key to the browser.
An embedding is a dense vector — for example 1,536 floats from text-embedding-3-small — produced by a model trained so that semantic similarity maps to geometric proximity. Because the model learned from billions of text pairs, paraphrases and related concepts land near each other even when they share no keywords. Cosine similarity between vectors quantifies that closeness, which is what makes meaning-based search possible.
Chunks of roughly 500-800 tokens with 50-100 tokens of overlap are a strong default. Too small, and a chunk loses surrounding context — an error code separated from its meaning; too large, and one vector must represent several ideas, so it matches everything weakly and nothing well. The right way to tune it is an evaluation set of real queries scored against known-relevant chunks.
pgvector is usually right up to a few million chunks when you already run Postgres — you get relational metadata joins and one system to operate. Dedicated engines like Pinecone, Qdrant or Azure AI Search earn their keep at much higher scale, with managed ANN indexes, hybrid keyword+vector ranking and multi-tenant filtering. Start with pgvector and migrate only when latency or index management actually hurts.
Take three Intune KB paragraphs, chunk them (~500 tokens), embed them with text-embedding-3-small via a small script, and store the vectors in pgvector. Then embed three queries — one paraphrase, one exact phrase, one unrelated — and print cosine similarity for every chunk-query pair. Observe the score bands and where the relevant chunk lands.
Not necessarily. pgvector adds vector columns, HNSW indexes and nearest-neighbour operators to ordinary PostgreSQL, which is enough up to a few million chunks. Managed engines — Pinecone, Qdrant, Azure AI Search, Vertex Vector Search — add scale, hybrid ranking and built-in metadata filtering once you outgrow that.
text-embedding-3-small produces 1,536 floats — about 6 KB per vector at 4 bytes each; 3-large produces 3,072. It matters for storage and index memory: a million vectors at 1,536 dimensions is roughly 6 GB raw, and the dimension must be declared when the index is created, so it is a one-way decision at design time.
Keyword search (BM25, SQL LIKE) matches literal terms and fails on paraphrases and synonyms. Semantic search embeds documents and queries and matches by vector proximity, so “device stuck at account setup” finds ESP documentation. The best production systems do both — hybrid retrieval — because exact strings like 0x87D1041C still need literal matching.