Why it finds “refund” when the customer typed “money back”

The thing under search

A customer writes “can I get my money back?” Your help page says “refunds”. Word matching finds nothing. A modern search finds it instantly.

The mechanism behind that is called an embedding, and it is worth twenty minutes of your attention even if you never write a line of code, because it is what search, document Q&A, recommendation and clustering are all built on, and it explains several behaviours that otherwise look like magic or malfunction.

Meaning as a position

Imagine giving every piece of text a position in space using three numbers, in the way a place has a latitude, longitude and altitude.

Suppose the first number measures how much a phrase is about money, the second how much it is about complaint, the third how much it is about time. Then:

"refund"          -> (0.9, 0.6, 0.2)
"money back"      -> (0.9, 0.6, 0.2)
"chargeback"      -> (0.9, 0.8, 0.3)
"delivery delay"  -> (0.1, 0.7, 0.9)
"opening hours"   -> (0.0, 0.0, 0.8)

“Refund” and “money back” share no words and sit in almost the same place. “Opening hours” is far away. Search becomes a distance calculation rather than a word hunt, and distance does not care what words you used.

Real embeddings use hundreds or thousands of numbers instead of three, and nobody chose what each one measures: they were learned from a very large amount of text, on the principle that words appearing in similar contexts should end up near each other. But the picture is exactly the one above, only with more dimensions than you can draw.

Where you meet them without knowing

• Your document tool finding the right passage although you used different words.
• A shop suggesting related products.
• Your email sorting messages into categories.
• “Find similar” in a photo library.
• The retrieval step in every grounded system from the previous lesson.

All the same operation: turn things into positions, then find what is nearby.

What this explains

Why retrieval finds the wrong passage sometimes. Nearness is similarity of meaning, not correctness. “Our refund policy” and “our no-refund policy” sit very close together, because they are about the same subject. A search may hand the model the wrong one, and the model will answer from it faithfully.

Why short queries retrieve badly. “Price?” has almost no meaning to position. It lands in a crowded region and pulls back whatever happens to be nearest.

Why chunk size matters. Embed a whole 40-page document as one position and it means “a bit about everything”, which is near nothing in particular. This is why documents are split into passages: a passage has one subject and therefore a meaningful position.

Why it works across languages. Multilingual embeddings place “refund”, “remboursement” and “reembolso” in nearly the same spot. Search your English documents with a Spanish question and it works, which is a useful property for a business with customers in more than one language.

Trying it for free

If you are curious enough to look at real numbers, sentence-transformers is a free Python library that runs on an ordinary laptop with no GPU:

from sentence_transformers import SentenceTransformer, util
m = SentenceTransformer("all-MiniLM-L6-v2")   # small, free, offline
v = m.encode(["refund", "money back", "opening hours"])
print(util.cos_sim(v[0], v[1]))   # about 0.75
print(util.cos_sim(v[0], v[2]))   # about 0.05

The number is cosine similarity: 1 means the same direction, 0 means unrelated. Seeing 0.75 against 0.05 with your own two phrases is the moment this stops being abstract.

What it does not do

An embedding captures topic and rough sense. It does not capture negation reliably, it does not know which document is authoritative, and it certainly does not know which of two similar passages is current.

So embeddings decide what to look at. They never decide what is true. That job stays with your documents being right, and with you.

Where the numbers are stored

If you use a purpose-built document tool, this is invisible: it computes the positions when you upload and keeps them in a vector database. Chroma and FAISS are free and open; Pinecone, Weaviate and Qdrant are the commercial names you will see in vendor materials.

You do not need one. The word is here so that a supplier’s technical proposal does not read as unfamiliar, and so you can ask the question that matters: how are the documents kept current, and what happens to the old positions when a file changes.

The cost, so it is not mysterious

Embedding text is cheap even on a paid service: a whole small business’s document set typically costs a few cents to embed, and running an open model locally costs nothing but electricity.

Where cost appears is re-embedding. Change your chunking, change the model, or reload the library, and everything is recomputed. At a small business’s scale this is trivial. It is worth knowing only because a vendor quoting a large figure for “indexing” is charging you for their engineering, not for the arithmetic.