Query Understanding Techniques: Rewriting, Filter Extraction, Intent Classification

1.Query rewriting: restating what the user meant

In a Databricks RAG chain, user intent is resolved in query understanding, the step at the start of the chain that turns the raw user query into the retrieval query. Retrieval sees nothing except that query. This page covers the techniques that go into this step.

The first is query rewriting: "Query rewriting involves translating a user query into one or more queries that better represent the original intent." Its stated purpose is to make it more likely that retrieval finds the most relevant documents. It helps most with complex or ambiguous queries, or with queries whose wording doesn't match the terminology in the documents. Databricks gives three examples:

- Paraphrasing conversation history in a multi-turn chat. A follow-up like "what about the other one?" is meaningless to a vector search on its own. The rewrite folds in the earlier turns so the retrieval query stands alone. - Correcting spelling mistakes in the user's query. - Replacing words or phrases with synonyms to capture a broader range of relevant documents.

A rewrite can also produce several queries from one request, which suits a question that really asks two things.

Databricks attaches a constraint to rewriting that's easy to overlook: "Query rewriting must be done in conjunction with changes to the retrieval component". A rewrite is only useful if the retriever is set up to make use of it. If the rewritten query is written in terminology or a form that the index and retrieval strategy don't handle well, rewriting can just move the mismatch to a different place. Treat query understanding and retrieval as one unit that you tune together.

Sources1

2.Filter extraction: turning stated criteria into retrieval parameters

Some intent is better expressed as constraints than as reworded text. If a user asks for "reports from 2023" or about a specific product, a semantic search over the whole corpus may return content that's similar but from the wrong year or for the wrong product. That's the accurate-but-mismatched pattern again. Filter extraction handles this. It "involves identifying and extracting these filters from the query and passing them to the retrieval step as additional parameters." Databricks' examples are time periods ("articles from the last 6 months"), products, services or categories ("laptops"), and geographic entities such as city names or country codes.

Filter extraction has more dependencies than rewriting. It requires changes to both the metadata extraction data pipeline and the retriever chain. The metadata step has to make sure the relevant fields exist on every document or chunk, and "the retrieval step should be implemented to accept and apply extracted filters." Extracting "2023" from the query is pointless if no chunk has a year field, or if the retriever ignores the parameter.

Sources1

3.Multi-step intent resolution and clarification

Another design decision is whether query understanding should be one LLM call or several. A single, carefully written prompt is efficient. Databricks notes that splitting complex logic across several calls often gives better results, and calls this a general rule of thumb whenever many complex steps would otherwise go into one prompt. For example, "you might use one LLM call to classify the query intent, another to extract relevant entities, and a third to rewrite the query". The tradeoff is stated directly: "Although this approach may add some latency to the overall process, it can allow for more fine-grained control". It can also improve the quality of what gets retrieved.

For a customer support bot, the multi-step component looks like this:

1. Intent classification. An LLM assigns the query to predefined categories such as product information, troubleshooting or account management. 2. Entity extraction. "Based on the identified intent, use another LLM call to extract relevant entities from the query", for example product names, reported errors or account numbers. 3. Query rewriting. "Use the extracted intent and entities to rewrite the original query into a more specific and targeted format", for example a query that names the deployment target and the exact error.

Sometimes intent can't be inferred because the user simply hasn't given the key detail. Databricks' Genie Agent guidance handles this with an explicit clarification rule. For example, when a user asks for a sales breakdown without a time range, sales channel or KPIs, the agent "must ask a clarification question first to gather necessary information." The instruction should name the trigger condition, the missing details, the required action, and an example question to ask. It's still intent resolution that happens before retrieval and answering. The difference is that the agent gets the missing piece from the user instead of guessing.

Sources12

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Adding a query rewriting step by itself is enough to fix mismatched retrieval.Why is that wrong?

   Databricks says rewriting must be paired with changes to the retrieval component. A rewrite the retriever isn't set up to use can just move the mismatch elsewhere.

   Covered in Query rewriting: restating what the user meant

2. 2.Filter extraction only needs a change to the query understanding prompt.Why is that wrong?

   The data pipeline also has to provide the matching metadata fields on each chunk, and the retriever has to accept and apply the filters.

   Covered in Filter extraction: turning stated criteria into retrieval parameters

3. 3.A single LLM call is always the better design for query understanding because it adds no latency.Why is that wrong?

   Separate calls for intent classification, entity extraction and rewriting add latency but give finer control and can improve what gets retrieved. It's a tradeoff to weigh, not a fixed rule.

   Covered in Multi-step intent resolution and clarification