1.Close in Meaning, Not in Spelling

Sarah types "cozy jacket for cold weather" into the search bar built back in Act 7. It comes back empty. GreenMart's own "Insulated Winter Coat" is exactly the right product — but it shares not one single word with the query. "Cozy" isn't "insulated." "Jacket" isn't "coat."

Fuzzy matching, from Act 7, tolerates a typo — a few wrong letters in an otherwise-similar word. It has nothing for two totally different words that happen to mean almost the same thing.

A vector, for this purpose, is a long list of numbers — hundreds of them — that represents a piece of text's actual meaning, not its exact wording. Each number is one dimension, one measured aspect of that meaning (not a human-readable one, like "warmth" or "formality" — a real embedding model learns hundreds of dimensions on its own, in a way no person hand-labels or fully interprets, but the numbers work).

The real, useful property is this: two pieces of text with semantically similar meaning end up as two vectors that are mathematically close together, even if they don't share a single word. Two pieces of text with unrelated meaning end up far apart, even if they happen to share a word.

This is exactly GreenMart's "cozy jacket for cold weather" problem, solved the same way. Run through the same real model, that query and "Insulated Winter Coat" score 0.6770 — genuinely, verifiably close in meaning, despite zero shared vocabulary. "Waterproof Hiking Jacket" scores 0.6047, also a real, relevant match. "Mechanical Keyboard" scores 0.0739 — correctly, almost completely unrelated.

This is the shift Act 7 never made, on purpose — Act 7's own search engine was always going to be about matching words, however tolerantly. A vector database asks a genuinely different question, at the actual level meaning lives at, not spelling.