Search RAG Retrieval
Search RAG - Query Understanding
Users do not write retrieval queries. They write incomplete thoughts.
Why this matters in production
Real queries contain pronouns, acronyms, typos, product nicknames, IDs, and missing scope. Pretending the raw query is retrieval-ready is a demo habit.
This works in demos but fails in production: embedding the raw question and hoping semantic similarity handles domain language.
What breaks
Acronyms collide. 'Summarize it' loses the referent. Product names mean different things across tenants. Date-specific questions retrieve timeless docs. Query expansion can drift from the user's intent.
Bad query understanding creates bad retrieval traces. The answer may sound reasonable while answering a subtly different question.
What works
Normalize without destroying exact terms. Detect IDs, dates, names, languages, and scope. Expand aliases only when the system has evidence for the alias. Generate variants, but keep attribution for each variant.
Do not do broad synonym expansion unless you can measure precision loss. Recall without intent control is just noise with better branding.
Practical guidance
Log the raw query, normalized query, generated variants, inferred filters, and exact terms preserved for lexical search. Debugging retrieval without this is guesswork.
What happened
A user asked, 'Does Mercury support SSO?' and the system answered from astronomy onboarding docs because Mercury was both a product name and a project codename.
Why retrieval failed
Query understanding did not resolve scope or tenant vocabulary before retrieval.
Why it was hard to detect
The answer had citations and looked grounded. The wrong Mercury was only visible in the retrieval trace.
What fixed it
The fix was alias resolution with source scope, ambiguity detection, and a clarification path when multiple canonical meanings matched.
Practical Guidance
Resolve ambiguity before retrieval.
Preserve exact technical tokens.
Trace every query rewrite.