An embedding turns meaning into coordinates. A piece of text goes in, a long list of numbers comes out, and the numbers work like a position on a map: ideas that mean similar things sit near each other, even when they share no words. The sentence about ending a subscription lands next to the sentence about cancellation, because the map is organized by meaning, not spelling.
A vector database is that map at working scale, built to hold these positions in bulk and find nearest neighbours fast. Ask it what sits closest to this, and it returns the passages whose meaning lands nearest yours. Together, embeddings and the vector database are the engine under RAG: they are how the fetch step finds the right documents to hand the model.
For an operator, the payoff is search that finally matches how people actually ask. Keyword search fails the moment your customer and your documentation use different words for the same thing, which is most of the time. Meaning-based search closes that gap without anyone maintaining lists of synonyms. If your business sits on years of messy internal knowledge, this is the technology that makes it findable.
A concrete example. A support team's knowledge base calls it account termination. Customers write in about cancelling, closing, stopping the charge. Keyword search returns nothing useful and the team answers by hand, again. The same knowledge base behind embeddings returns the termination article for every one of those phrasings, because they all sit in the same neighbourhood on the map. That is the whole trick, and it is quietly one of the most useful in the stack.
“It searches by meaning instead of keywords. That's what the embeddings are for.”
// this page is the full text. the packaged PDF, all fifteen terms, comes with the free library.