Embedding

For a long time, search was string matching. If the words someone typed appeared in a document, the document came back; if they didn't, it didn't. So a person asking "when do I get my refund" never reached the article titled "payment cancellation processing times." Same question, no characters in common.

Pagedeck's support queue ran into this. More than a hundred help articles were already published, and the same questions still landed on Sofia's desk every day. The articles existed — the words users typed simply weren't the words the articles used. Typing "close my account" missed the article called "account deletion," and typing "move to a cheaper plan" missed "downgrade." Every one of those misses turned into a ticket someone had to answer by hand.

Solving that by meaning rather than by characters requires meaning in a comparable form. For a computer to measure how close two sentences are, that form has to be numeric. An embedding is that conversion: a model turns a sentence into one list of numbers, and it has been trained so that sentences with similar meanings come out with similar numbers.

Feed a sentence to a dedicated model and a fixed-length list of numbers comes back. The length depends on the model, usually somewhere between a few hundred and a few thousand. With a 1,536-dimension model, "when do I get my refund" becomes 1,536 numbers and "payment cancellation processing times" becomes 1,536 numbers. Because the lengths match, the two lists can be compared position by position and reduced to a single closeness score.

No individual number carries a meaning a person can read. Nobody can explain why the third value is 0.42; the only thing that means anything is the distance between two lists. It's closer to pinning each sentence to a coordinate on a map. You don't read the coordinates — you look at which one sits next to which.

In practice there are four steps.

1. Split the material into chunks. A whole article mixes several topics and lands at a coordinate that represents none of them well, so text is usually cut by paragraph or into spans of a few hundred tokens — a token being the smallest unit a model breaks text into.
2. Compute an embedding per chunk. A hundred articles that split into two thousand chunks produce two thousand lists, each one tied back to the article and position it came from.
3. Store those lists in a form that can be searched. The storage built for this is a vector database.
4. When a question arrives, embed the question with the same model and pull the few stored chunks closest to it.

One rule governs all of it: comparison only means something between numbers produced by the same model. Coordinates from model A and coordinates from model B are points on unrelated maps, and the distance between them says nothing. Change the embedding model and everything stored has to be recomputed.

The most common use is retrieval-augmented generation (RAG), where relevant passages from internal documents are found and pasted into the prompt so a large language model answers from them. The finding step is embedding comparison. Internal search and automated support replies are usually built this way.

Three other uses come up often.

1. Grouping near-duplicates — spotting repeat tickets or duplicate issues. Different titles about the same thing land on adjacent coordinates and collect into one cluster.
2. Automatic routing — sorting incoming tickets into buckets like billing, accounts, or bugs. Embed a representative sentence per bucket and check which one a new ticket sits nearest.
3. Recommendations — surfacing items whose coordinates are near the item someone is looking at.

The limits are just as clear. Opposites often come out close together. "Refunds are available" and "refunds are not available" are about the same subject, so their coordinates sit near each other and distance alone cannot tell you which one answers the question. Proper nouns and numbers are another weak spot. A search for an order number or an error code needs exact characters, and old-fashioned string matching does that better — hand a meaning-based search the number 20250917-0042 and it will happily return other numbers that look similar. Real products usually run both and merge the results, letting exact matches win where they exist and falling back on meaning everywhere else.

"Search isn't finding it because we never re-embedded it, not because the article is missing."

The article was edited, its chunk was never recomputed, and the old text is what search still sees.

"If we switch embedding models we have to regenerate every vector we have."

A warning that switching is a full recomputation job, not a one-line config change.

"Embeddings won't catch this one. Use keyword search for order numbers."

Meaning-based matching is the wrong tool when the match has to be exact.

At Pagedeck, Theo scheduled the help-article chunks to be re-embedded every night. When Sofia edits an article, search reflects it the next morning. The schedule started out weekly and got tightened after a pricing-change announcement was edited and the outdated version kept coming back in search all day. When the people editing documents and the job recomputing numbers run on different clocks, that gap keeps reopening.

Mia never looks at the numbers. She runs the twenty most frequent questions through search and checks whether the right article lands near the top. Embeddings aren't something a person can read and judge, so they get inspected through results.

Many people take an embedding to be the search feature itself, which is where "we'll add embeddings and then search will work" comes from. An embedding only converts a sentence into numbers; it doesn't find anything. Working search also needs storage that keeps those numbers and returns the nearest ones quickly, a decision about how the text gets chunked, and a decision about how many chunks to pull. Add the conversion alone and nothing happens.

The other one is treating the numbers as a one-time job. That looks right while documents stay fixed. But when the source article changes, its chunk still points at the old text, and when the model changes, every stored value becomes worthless. Without a recomputation schedule set up from the start, an announcement nobody has touched in six months ends up at the top of the results.