An embedding is a list of numbers that locates a piece of text in a space where distance measures similarity of meaning.OpenAI's embeddings guide defines an embedding as a vector of floating point numbers where the distance between two vectors measures their relatedness, and lists search, clustering, recommendations, and classification as the standard uses. Two pieces of text that mean similar things get placed near each other, whether or not they share a single word. That one property quietly governs most of this discipline, because the retrieval step in AI search finds your content by its position in that space, and much of the writing advice later in this book is really instructions for landing your passages near the queries that matter.
From words to coordinates
The idea is old by machine-learning standards. The word2vec paper showed in 2013 that useful word vectors could be computed from large text corpora, with quality measured by how well distances in the space matched human judgments of similarity.Mikolov et al., Efficient Estimation of Word Representations in Vector Space (2013), the foundational word-vector paper. Modern embedding models do the same for whole sentences and passages: feed in a piece of text, get back a vector, typically a few hundred to a few thousand numbers long.OpenAI's current models return vectors of 1,536 numbers (text-embedding-3-small) or 3,072 (text-embedding-3-large), per the embeddings guide.
Each number is a coordinate. No single coordinate means anything readable on its own; the meaning lives in the position the full vector describes, the way a latitude means little until it is paired with a longitude. Similarity between two texts is then computed as the distance, or more commonly the angle, between their vectors; cosine similarity, the standard measure, scores how closely the two vectors point in the same direction.
A worked example
Take a page whose heading is "Affordable CRM software for small teams" and a searcher who types "best tools to manage sales leads for a five-person company". The query and the page share no meaningful words. Keyword search has to get lucky with synonyms or fail. An embedding model, though, has read millions of pages where "CRM" and "manage sales leads" occur in the same contexts, and where "small teams" and "five-person company" do the same job in a sentence, so it assigns the two texts nearby vectors. The retrieval system computes similarity between the query vector and every candidate passage vector, and your page comes back as a top match despite the zero-word overlap.
This is the mechanism doing the work that exact-match keywords used to do. Vocabulary overlap has been demoted; proximity in meaning-space has taken its place. You stop asking "does my page contain the phrase people search for" and start asking "does my page say the thing those queries mean". The two questions overlap heavily in practice, which is why keyword habits still mostly work, and diverge exactly where the old habits fail: synonyms, paraphrases, and the machine-generated query variants covered in Retrieval and Grounding: How an AI Answer Gets Assembled.
Chunking: retrieval sees passages, never pages
A single vector for a 3,000-word page would average too many topics into one position and match none of them well. So retrieval systems chunk: they split pages into passages, often a few hundred words or less, and embed each chunk separately. The unit that gets retrieved, scored, and handed to the model is the chunk.
The consequence deserves stating plainly: the machine never rewards your page as a whole. Each section competes alone, carried only by the words inside it. A chunk that opens mid-thought, leans on a pronoun whose referent lives three paragraphs up, or buries its point under a transition, embeds as a vaguer vector than the same content stated self-contained. Structuring pages so every section can stand alone as a retrieved passage is the subject of Content Architecture: Building for the Chunk.
Where embeddings sit in the pipeline
Retrieval is the visible use, and the same vectors get reused throughout the machinery. Reranking scores retrieved chunks against the query a second time with a stronger model. Clustering groups similar documents; deduplication drops near-identical ones, both from indexes and from training corpora. When a query has several near-duplicate pages to choose from, embedding similarity is often what decides that only one of them gets through, which is one reason republishing lightly reworded versions of a competitor's content works so poorly.
What embedding-based retrieval rewards
Once the mechanism is clear, two long-standing pieces of advice stop being folklore and become engineering. First, describe your brand consistently. Every page that says "X is a CRM for small teams" in roughly those terms pulls the embedding of any passage mentioning X toward the CRM region of the space; scattered, conflicting descriptions pull it nowhere in particular. Second, co-occur with your category terms. A brand that appears in text surrounded by its category's vocabulary embeds near that category's queries, and a brand that appears mostly in generic press-release language does not.
Neither of these is a trick, and neither has a shortcut. They amount to writing passages that state what you are, in the vocabulary of the people who need you, in units that stand alone. The craft details are in Writing for Retrieval and Citation, and the work of making machines hold consistent facts about your brand is in Entities: Becoming a Thing the Machine Knows.