Traditional search is a glorified Ctrl+F. If your beach sandals are labeled "water-resistant footwear" in your product database, nobody searching for "beach shoes" will find them. "Water," "resistant," and "footwear" do not match "beach" or "shoes," so the search engine returns nothing. Users who cannot find what they want within two or three searches leave the site entirely. They do not email support. They do not try different keywords. They buy from the competitor whose search finds products where related but missing terms also describe those products.
The familiar fix is synonyms. Teams build elaborate synonym dictionaries: "sneakers = shoes = footwear = kicks = trainers." They maintain spreadsheets with thousands of mappings. Every time a product fails to surface, someone adds another row. One retail team had a dedicated person whose entire job was updating the synonym list. Language is not a lookup table, though. "Kicks" means shoes in one sentence and something else entirely in another. "Trunk" is luggage, part of a car, or an elephant's nose depending on surrounding words. No manual mapping captures the contextual, distributional nature of how words actually cluster in usage.
The other common approach is full semantic search from scratch: spin up ML infrastructure, train or fine-tune embedding models, manage vector databases, build pipelines that transform text into dense numerical representations. Converting text into vectors that correlate terms by co-occurrence works well. But the infrastructure overhead is real. You manage model serving, handle inference latency, version models, monitor drift, and keep everything running at scale. Teams that go this route often discover that their inference costs at production scale are astronomical because the model runs on every single search query. They solved the relevance problem and created a performance and cost problem in its place.
Automatic Semantic Enrichment in Amazon OpenSearch Serverless keeps the relevance without the per-query cost. At index time, the system generates sparse embeddings from your content, capturing which terms co-occur in similar contexts across millions of documents, and stores those embeddings alongside the original text. No ML infrastructure, no model management, no changes to your application code.
Why Sparse Vectors
Automatic Semantic Enrichment supports both sparse and dense embeddings. Sparse is the path worth starting with. A sparse vector is a weighted list of correlated terms: the model identifies which words co-occur with your content across large corpora and stores those associations as rank features in the inverted index. No approximate nearest neighbor graph. No vector database. No new query syntax. You search with text, and the inverted index does what inverted indices have always done, except now the vocabulary is expanded beyond what the author originally wrote.
The model runs once, at ingest time. When a document enters the index, OpenSearch Serverless passes the text through a sparse encoder trained on distributional co-occurrence patterns. The encoder outputs a weighted term list: "beach sandals" produces rank features for "waterproof," "summer footwear," "flip-flops," and other terms that appear in overlapping lexical contexts, even though none of those words exist in the original text. Those features are stored alongside the document. At search time, a lightweight tokenization process matches the query against both the original text and the enriched terms. No full model inference on the hot path.
If your relevance requirements are more demanding, Automatic Semantic Enrichment also supports dense embeddings with bi-encoding: full vector representations for both documents and queries, matched by approximate nearest neighbor search. Dense vectors capture finer-grained distributional relationships and generally rank better on hard queries. But dense requires a vector index, ANN infrastructure, and model inference at query time. Sparse gives you most of the relevance lift for a fraction of the operational weight. Start sparse. Move to dense when you have the query volume and relevance data to justify the added infrastructure.
The cost structure reinforces the choice. With sparse enrichment, you pay for model inference once per document at ingest. Search queries hit the inverted index without touching the model. No per-query inference cost, no GPU fleet at search time, no latency spike when traffic surges. Your search cost scales with query volume against a standard inverted index, not with model inference. For most workloads, this is the difference between a search feature you can afford to run at scale and one that lives permanently in staging because production costs are unpredictable.
The grep Moment
Here is where the grep analogy breaks. Traditional lexical search is grep "scarlet sneakers" catalog.txt. No match, no result, end of story. Automatic semantic enrichment is more like having a pre-built thesaurus of co-occurrence patterns baked into the index itself. The query does not need to match the exact string because the index already knows which terms cluster together based on how they appear across millions of documents.
Back to the beach sandals. A customer searches for "shoes for the beach." Your product catalog says "water-resistant footwear." Lexical search returns nothing. With Automatic Semantic Enrichment, the sparse encoder already identified at ingest time that "beach," "sandals," "water-resistant," "footwear," and "shoes" all co-occur in overlapping lexical contexts across the training corpus. Those correlations are stored as rank features in the index. The query "shoes for the beach" matches against those enriched terms and surfaces the product without a single exact word match in the original listing.
Setup Is Embarrassingly Easy
You create an index, designate which fields should have automatic semantic enrichment, choose a language model (English or multilingual), and OpenSearch Serverless creates the ingest and search pipelines automatically. You index documents as plain text. You search with plain text queries. The semantic enrichment happens invisibly during ingestion. AWS benchmarks show up to 20% better search accuracy compared to pure lexical matching.
The approach augments lexical search rather than replacing it. You keep traditional text fields alongside semantic fields. Exact matching works when you need precision. Semantic correlation works when the user's vocabulary does not match your catalog's vocabulary. Both live in the same index.
Where This Is Heading
The default expectation for search is shifting. Users trained on Google, voice assistants, and ChatGPT do not think in terms of keyword matching anymore. They expect search to correlate vocabulary, not match strings. The companies that ship semantic correlation first have a structural advantage: not because their products are better, but because customers can actually find those products.
If you are running e-commerce search, documentation search, internal knowledge bases, or any retrieval system where vocabulary mismatch causes failed queries, automatic semantic enrichment removes the friction without requiring ML expertise, model management, or changes to your application architecture. Pick one high-value use case where search is failing users. Enable enrichment. Measure the difference in search success rates. The improvement is measurable within days, and the setup takes minutes rather than sprints.
