Keyword search vs. vector search

MongoDB (and most databases) has had fast, simple full-text search for years: index a field, run a $text query, get back documents whose text contains the words you typed. It works well when the searcher speaks the same vocabulary as the data.

It breaks down fast with conversational input. A user asking for "something eco-friendly for staying hydrated on the go" won't match a product described as "sustainable reusable bottle", none of the literal words overlap, even though the meaning is identical.

The shift in question

• Keyword search asks: does this document contain these words?
• Vector search asks: is this document semantically close to what the user meant?

Both the query and the underlying content get converted into embeddings, vectors in a high-dimensional space, and the search returns whichever content is geometrically nearest. A "reusable bottle" ends up close to "eco-friendly hydration" in that space, because the model learned they live in the same neighbourhood of meaning.

Trade-offs

• Keyword search: fast, exact, brittle, breaks whenever the searcher and the data use different words for the same thing.
• Vector search: slightly slower, approximate, resilient, works with synonyms, vague phrasing, or a different language than the underlying data.

For a conversational interface, the user is never going to type catalogue keywords, so vector search is the right fit. See Building ShiftGreenBot: a RAG Product Finder for a real implementation of this, Azure OpenAI embeddings, MongoDB vector search, and the three-step retrieval flow it's built on.