Bottom line: for a beginner ask-your-docs feature in a SaaS help center, I would start with embeddings-based semantic retrieval over document chunks, retain keyword search as a fallback, and add reranking only after I can measure weak top results. It is the least complicated architecture that handles the natural-language questions support teams actually receive while still giving an operator clear levers for relevance, cost, and SLOs.
I learned to treat retrieval as a production dependency after a token bill landed at $8,742 for a help-center experiment I had estimated at under $1,000. The expensive part wasn't one dramatic model call; it was sending whole articles, navigation chrome, and duplicate chunks to the answering model for every vaguely phrased question. That mistake changed my order of operations: retrieve a small, attributable set first, inspect it, then generate. A chat model is a poor index.
Small index. Big difference.
How should a SaaS help center use semantic search, embeddings, and keyword search?
Semantic search turns both a question and each document chunk into vectors, then retrieves chunks that are close in that vector space. For an ask-your-docs semantic search feature, that means a customer asking "Why can't I invite another teammate?" can reach a passage titled "Adding users to a workspace" even when the words do not line up. Keyword search remains useful for exact error identifiers, product SKUs, and freshly published terms, but by itself it is a thin answer to the way people phrase support questions.
