One error code explains why RAG pipelines keep a keyword index

Call an embedding retriever with "What is the error code ERR-1042?" and the query becomes a single vector, ranked by similarity against the document vectors ^[1]. Nothing in that comparison requires the returned document to contain the string ERR-1042. Rijul's dev.to post says such a search tends to surface documents about errors, failures and troubleshooting, and that an exact match is not necessarily what semantic similarity is best at ^[3][15].

He hedged that sentence, and the post argues the whole case from example queries; it includes no retrieval metrics ^[16]. For the failure to show up in your system, two things have to hold: your users type identifiers, and the documents that answer them carry those identifiers verbatim. Both are cheap to check against a sample of your own query log. Take the queries containing an identifier and see whether the document that answers each one comes back in the top k from the vector index alone. In my view that test settles it locally: where identifier lookups are a real share of traffic, lexical retrieval is a correctness requirement, and the post shows how the failure happens without measuring how often.

"Keyword search doesn't need to understand the meaning of the query. It looks for matching terms," Rijul wrote ^[6]. The identifier case is covered because the match is on the term itself. The post lists seven classes where that matters: product IDs, error codes, part numbers, names, file names, exact technical terms and code snippets ^[4][5].

The pipeline he sketches runs keyword and meaning search together, merges the results, ranks them, then hands the best candidates to a smarter model for re-ranking before any context reaches the LLM ^[10]. Two ranking stages sit between retrieval and generation, and the second is itself a model call ^[11]. Every question pays both searches and both passes, including the ERR-1042 lookup that the keyword index answered on its own.

The second limitation in the post is a different problem. "Why did our payment service start failing after the latest deployment?" may need deployment documentation, error logs, configuration changes and troubleshooting guides ^[7]. The post breaks it into three sub-questions and lets the system choose the next search from what it has already found ^[8][9]. The number of searches per question stops being fixed. Rijul says this approach is more useful for complicated questions than for simple lookups ^[9].

His librarian analogy covers the same split: you can describe what a book is about, or hand over the title The Innovators, or give the book ID ^[14]. Few readers describe the plot of a book whose title they already know. The published text breaks off mid-sentence where it starts to say what the system can do when a document ranks highly in both searches ^[17].