Vector search is one feature of retrieval, and many applications need keyword search or a combination of both.
2
Keyword search does much of its work during ingestion through tokenization, normalization, stemming, and inverted indexes.
3
Semantic search can recover related meaning, but its quality depends on the model, the data, and evaluation for the specific use case.
Summary
Philipp Krenn presents retrieval as the part of RAG that supplies context to a generator. He starts with lexical search, showing how tokenization, lowercasing, stop-word removal, stemming, offsets, and positions turn text into an inverted index. He explains phrase searches, synonyms, n-grams, fuzziness, and BM25 scoring, including why scores should not be treated as percentages. He then compares dense embeddings with learned sparse retrieval using Elastic's ELSER. Dense vectors capture similarity in a less interpretable space and always produce some nearest results, while sparse retrieval expands text into weighted terms and can be easier to inspect. Krenn argues that the right choice depends on the domain. E-commerce may benefit from returning somewhat distant results, while legal search needs more care. He recommends evaluation based on human judgments, user behavior, or LLM-assisted assessment. The workshop closes with chunking, hybrid search, reciprocal rank fusion, filtering, and reranking.
Retrieval is the R in RAG and does not require vector search
Krenn narrows RAG down to retrieval, which he defines as getting the right context to the generation step. He says retrieval is an old problem, potentially 50 or 70 years old depending on the definition. Vector search is only one feature among many. Keyword search, vector search, and hybrid search all have a place, and the same foundations apply broadly to systems built on Apache Lucene and similar technologies. His workshop therefore starts with lexical search instead of assuming that every RAG system needs embeddings.
Lexical search prepares most of its data during ingestion
Krenn uses Elasticsearch's _analyze endpoint to show how the sentence "These are not the droids you're looking for" becomes tokens. Tokenization breaks text at whitespace and punctuation, while offsets record where each token appeared so matching text can be highlighted later. Positions support phrase queries because the engine can compare adjacent token positions without rereading the original text. He describes ingestion as the point where a search engine performs much of its work, unlike a database that does more at query time. The analyzer can also strip HTML, lowercase text, remove stop words, and stem words.
Language-specific analysis can turn bad configuration into garbage
The analyzer must match the language of the content. Krenn shows German and French examples and explains that stop-word lists and stemming rules differ by language. Applying English rules to another language can produce incorrect tokens, such as stripping an ending that has meaning in that language. For multilingual data, he recommends separate fields or indices with the appropriate analyzer, rather than mixing languages and corrupting the statistics used for search. He also mentions language detection as a way to identify the language before applying the matching analysis.
An inverted index makes exact lexical retrieval fast
Krenn explains the inverted index as an alphabetically sorted list of extracted tokens. Each token points to matching document IDs, occurrence counts, and token positions. For a search for "droid," the query is lowercased and stemmed in the same way as the stored text, then the engine follows the pointer to the matching document and position. This makes retrieval and highlighting efficient because the engine does not need to analyze a potentially multi-page text again. The example matches singular and plural forms because both sides pass through lowercasing and stemming.
Simple lexical tools are useful, but each has a cost or limit
Krenn describes synonyms as a way to connect terms such as "droid" and "robot," but says homonyms such as "bat" remain difficult because keyword search has no context. N-grams can match partial words, while edge n-grams are better for prefix typing, but both create more tokens, storage, and query work. Fuzziness uses edit distance to tolerate misspellings, yet it applies per token after tokenization, which can create surprising matches. He presents these techniques as practical tools that work in selected cases, rather than as general solutions.
BM25 ranks matches using frequency, rarity, and field length
Krenn introduces BM25, the current version of the best-match family of scoring algorithms. Term frequency measures how often a term appears, but BM25 flattens the benefit after several occurrences instead of increasing forever. Inverse document frequency gives more weight to rare terms than common terms. Field length also matters, so a match in a short title can rank above the same match in a long body. The score explains ordering within one query. It should not be converted into a percentage because adding or removing documents changes the collection statistics and therefore changes the score.
Dense and sparse semantic retrieval make different trade-offs
Krenn contrasts dense embeddings with learned sparse retrieval. A dense model turns text into an array of floating-point values in a vector space, where nearby points indicate similarity. The dimensions are learned and are not usually understandable labels. His example uses OpenAI's text-embedding-small with 128 dimensions, which he says is useful for demonstration but should not be treated as a quality benchmark. Sparse retrieval, using Elastic's ELSER, expands text into weighted terms. It is more inspectable, but query-time work can grow because many terms and overlaps must be scored.
Search quality depends on the domain and needs evaluation
Semantic search always has some nearest result, even when the result is weakly related, while keyword search can more easily return nothing or apply a cutoff. Krenn says this difference matters by domain. An e-commerce site may prefer to show a somewhat distant product because users may still buy it, while a legal case database should avoid unrelated matches. He recommends evaluation sets with queries and human relevance judgments, user click behavior, or LLM-assisted evaluation. He is direct that tuning one case can make many other cases worse, so search quality cannot be selected through a universal setting.
Hybrid retrieval combines signals and can rerank a smaller candidate set
Krenn's retrieval map includes full-text search, hard filters, dense vectors, sparse vectors, ranking signals, hybrid search, and reranking. Filters make binary inclusion decisions, while ranking features can include ratings, product margin, stock, or click behavior. Reciprocal rank fusion combines result positions from different retrieval methods instead of assuming their scores are comparable. Reranking then applies a more expensive model to a limited candidate window rather than to the whole collection. He also recommends chunking long documents into pages, paragraphs, or sentences so each embedding covers a manageable amount of context.
"You want to kind of like reduce the context per element that you're matching because there's only so much context that a dense vector representation can hold."1:17:59
Who should watch
You are building a RAG system and have assumed that vector search is the entire retrieval layer.
Your search results need to handle exact names, misspellings, phrases, multiple languages, or business signals.
You need to combine lexical and semantic retrieval or decide how to evaluate whether a search change actually helps.
