Module 04 · Lesson 1 of 10Free

Semantic search: finding by meaning, not keywords

Level

Beginner

Topic

Embeddings and vector search

Reading time

12 min

The panel suggests the wrong tickets

Deskora is a help desk app. A shop’s support team uses it to answer customer emails from one shared inbox. Each customer problem becomes a ticket: one customer’s whole conversation with the support team.

Tomás, an engineer at Deskora, is building a new panel called “Suggested answers”. When a support agent opens a ticket, the panel shows the 3 most similar resolved tickets and the 2 most relevant help-center articles from the same shop. The agent types nothing. The ticket itself is the search.

Priya is a support agent at a kitchenware shop that uses Deskora. She opens a new ticket from Ngozi: “Hi, my parcel never came. It’s order 48213 and I paid for express.”

Tomás’s first version uses keyword search. It ranks documents by the words they share with the ticket, using an inverted index that maps each word to the documents containing it ^{4Introduction to Information RetrievalChristopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, Cambridge University Press, 2008}.

The article Priya needs is called “Delivery not received: what to do”. It means exactly what Ngozi wrote and shares none of her words. So Priya ignores the panel and searches the help center by hand, and Ngozi waits longer.

This lesson answers one question: how can the panel find documents that mean the same thing as the ticket, and what does that cost across Deskora?

Deskora’s 1,500 shops and 120,000 new tickets a day are facts used across this course. The other numbers in this lesson are estimates for Deskora’s retrieval features, or assumptions labelled where they appear.

Semantic search ranks by meaning

Semantic search finds the documents whose meaning is closest to the query. It works on embeddings. An embedding is a list of numbers, a vector, that a model produces for a piece of text. Texts with similar meaning get vectors that point in similar directions. Embeddings shows how they work.

So “parcel never came” and “delivery not received” get vectors that sit close together, with no shared words. Closeness is one number, such as cosine similarity. Similarity measures compares the choices.

Semantic search is that comparison, run against every document a shop has.

Two paths: write time and query time

The work splits into two paths. The write path runs once per document, in the background. The query path runs every time an agent opens a ticket.

Write path, when a ticket is resolved or an article is saved:

1. An indexing worker picks up the document’s text.
2. It sends the text to an embedding model, a model that returns a vector instead of writing text.
3. It stores the vector in a vector store, next to the document’s id. Here a vector store is a table of vectors that can be searched by closeness; Vector databases covers what dedicated ones add.

One stored record looks like this:

{
  "doc_id": "article-0093",
  "shop_id": "shop-0412",
  "kind": "article",
  "title": "Delivery not received: what to do",
  "model": "voyage-4",
  "vector": [0.0213, -0.0087, 0.0441 /* ... 1,021 more numbers */]
}

The shop_id is there because a shop must never see another shop’s tickets, so every search is filtered by shop (Filtering vector search by metadata). The model is there because vectors from two different models can’t be compared.

Query path, when Priya opens a ticket:

1. The app server sends Ngozi’s ticket to the same embedding model, and gets one vector back.
2. It asks the vector store for the nearest vectors with Priya’s shop_id: the top 3 tickets and the top 2 articles.
3. It loads those documents by id and shows them in the panel.

The simplest way to find the nearest vectors is to compare the query with every stored vector and keep the best five. For Priya’s shop that is 40,150 vectors of 1,024 numbers each, about 41 million multiplications per panel. One server core does that in well under a second, by our estimate.

The numbers for Deskora

How big is this index, and what does it cost to build? Three numbers decide it: how many vectors, the storage they take, and the embedding bill.

Two of the inputs are assumptions. Deskora uses voyage-4, which returns 1,024 numbers per text by default, each a 32-bit number of 4 bytes ^{1EmbeddingsAnthropic, Claude API documentation}. Its price, as of September 2026, is $0.06 per million input tokens ^{2PricingVoyage AI, Voyage AI documentation}. Treat both as assumed: Embedding models covers how to choose a model.

Ticket counts and token sizes are estimates for this scenario. The price is Voyage AI’s list price for voyage-4 as of September 2026, used as an assumption.

After the first build, the costs are small. Keeping 12 months means about 82,000 tickets join the index each day (30 million ÷ 365). At 1,500 tokens each, that is about $7.40 a day.

The unit of cost is one completed task: one panel shown. A panel needs one embedding call for the ticket. Assume 500 tokens when the ticket is first opened: 500 × $0.06 ÷ 1,000,000 = $0.00003. For 120,000 new tickets a day, that is about $3.60 a day. For comparison, Deskora’s ticket summaries cost about $38 a day on Claude Haiku 5.5, as of October 2026 (an estimate from Calling a model API). Retries and panels opened more than once are left out.

So the embedding bill is not the hard part. The 124 GB of vectors and the search over them are.

Where semantic search misses: order 48213

Tomás switches the panel to semantic search. The article “Delivery not received: what to do” now ranks first. But something else has gone.

The two searches fail in opposite places:

A common belief is that semantic search replaces keyword search. It is half right. On question answering, a dense retriever found the right passage in its top 20 for 9 to 19 percentage points more questions than a strong keyword ranker ^{3Dense Passage Retrieval for Open-Domain Question AnsweringVladimir Karpukhin, Barlas Oğuz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen and Wen-tau Yih, EMNLP 2020, 2020}. But order numbers, codes and names are exact strings, and only keyword search matches exact strings. Many systems run both and merge the results, covered in Hybrid search.

What changes at Deskora’s scale

Checking every vector works for Priya’s 40,150. Two things break as Deskora grows:

• Search work grows with every document. A shop with 2 million tickets needs about 2 billion multiplications per panel. Approximate nearest neighbours explains how indexes skip most of them, at the price of sometimes missing a match.
• Storage grows with dimensions. Halving the dimensions halves the 124 GB. Fewer dimensions can cost some search quality, so test the change on real tickets first.

Where this shows up

• Design: a support assistant over company docs grows this panel into an assistant that drafts a reply from the documents it finds.
• Design: an AI customer support platform uses the same write and query paths for tickets and help articles, across many customers.

Tomás assumed 1,024 numbers from one model, and every number above depends on that choice. Which model should he pick, and how would he know?

Common mistakes

Check your understanding

Summary