Augmenting Prompts with User Intents, Key Fields and Terms

1.Where user-input context enters the chain

When a user sends a request to a RAG application, a fixed series of steps runs. Databricks calls this series the RAG chain. In outline, the chain has to understand the user's question, retrieve supporting data, augment the prompt with that data, and generate a response. Augmentation means combining the supporting data with the user's request, usually inside a template that also carries formatting rules and instructions for the LLM.

This lesson is about the first step and how it shapes the third. The raw text a user types is rarely the best retrieval query, and it is rarely the best way to fill a prompt template either. The Databricks RAG inference guide describes an optional user query preprocessing step. It can format the query in a template, use another model to rewrite it, or pull out keywords. Its output is a *retrieval query*, which the retrieval step uses. Prompt augmentation then puts together the final prompt. That prompt joins the user's query with the retrieved context in a template that tells the model how to use each part.

These choices affect quality. The cookbook warns that the way you combine retrieved chunks with the user's query can significantly affect the model's ability to produce good responses. So building the augmented prompt is a real design decision. The rest of this lesson covers the three kinds of signal you can extract from user input to improve it: intents, key fields and terms.

Sources12

2.Intents: deciding what the user is asking for

You could pass a user query straight to retrieval, and for some queries that works. Databricks' guidance, though, is that reformulating the query before retrieval is generally beneficial. The first thing to get from the query is its intent: which kind of request this is. In the cookbook's customer-support example, an LLM sorts each query into predefined categories such as "product information", "troubleshooting" or "account management".

Intent is useful because it shapes every later step. A troubleshooting question needs different entities pulled out of it, and different supporting context, than an account-management question.

This point is easy to get backwards. A single carefully written prompt is efficient. But the cookbook offers a general rule of thumb: when you try to pack several complex logic steps into one prompt, splitting them up often works better. For query understanding, that means one LLM call to classify intent, another to extract entities, and a third to rewrite the query. Each call depends on the one before. Entity extraction runs *based on the identified intent*, and rewriting *uses the extracted intent and entities*. The trade-off is clear: the extra calls add latency, and in return you get finer control and possibly better retrieved documents.

Sources3

3.Key fields: turning parts of the query into retrieval filters

Many queries contain hard constraints mixed into everyday language, for example "reports from 2023", "laptops" or a city name. The cookbook calls the technique for handling these filter extraction. You identify the constraints in the query and pass them to the retrieval step as extra parameters, so search covers only the relevant subset of data. The cookbook gives three kinds of example:

- Time periods, such as articles from the last 6 months or reports from a given year - Products, services or categories, such as a named service or a product type - Geographic entities, such as city names or country codes

In the support-bot example, the entities are product names, reported errors and account numbers. The AI Search retrieval quality guide describes an agent that does this automatically. It extracts relevant entities from the query, generates SQL-like filter strings, and runs a search that combines semantic matching with precise filtering. The guide calls filtering the biggest lever for retrieval quality and says it can reduce the search space by 90% or more. For customer support it suggests filtering by product line, region and issue category.

The reflect question points to the catch. An extracted filter only helps if there is something to filter on. The cookbook says filter extraction has to be built together with two other parts. The data pipeline's metadata extraction step must make the relevant fields available on every document or chunk. The retrieval step must also be built to accept and apply the extracted filters. If you extract region = EMEA from the query but no chunk carries a region field, the filter cannot work.

Sources34

4.Terms: rewriting and expanding the user's wording

Intents and key fields are structured. Terms are the actual words of the query, and they often don't match the documents' vocabulary. Query rewriting turns a user query into one or more queries that better express the original intent. It helps most with complex or ambiguous queries whose wording differs from the wording in the documents. The cookbook gives three examples:

- Paraphrasing conversation history in a multi-turn chat, so a follow-up such as "what about the second one?" becomes a standalone query - Correcting spelling mistakes in the user's query - Replacing words or phrases with synonyms to capture a broader range of relevant documents

The AI Search retrieval quality guide puts the synonym idea into practice as query expansion: generate several variations of the query to improve recall. An LLM writes the variations, and the system searches with the original query plus each variation.

# Use LLM to expand query with synonyms and related terms
def expand_query(user_query):
    prompt = f"""Generate 3 variations of this search query including synonyms:
    Query: {user_query}
    Return only the variations, one per line."""

for query in  ?  + variations:
        results = index.similarity_search(query_text=query, num_results=10)
        all_results.extend(results)

In the guide's example, "car maintenance" also searches "automobile repair", "vehicle servicing" and "auto maintenance". The stated benefit is better recall, because the search finds documents that use different wording. As with filters, rewriting is not a standalone fix. The cookbook says query rewriting must be done together with changes to the retrieval component. A rewritten query only helps if the retriever is set up to use it well. For example, it may need to search with several variations and merge the results, as expand_query does.

Sources34

5.Assembling the augmented prompt from extracted context

After query understanding has produced an intent, key fields and better search terms, the final step is to put them into the prompt the LLM will see. The usual approach is a template with named variables. The MLflow Prompt Registry example registers a customer-support template whose variables are the company name, the customer's topic and the customer's question. The application fills in each variable at request time.

initial_template = """\
You are a helpful customer support assistant for {{company_name}}.

Please help the customer with their inquiry about: {{topic}}

Customer Question: {{question}}

Provide a friendly, professional response that addresses their concern.
"""

The template keeps two things apart: what the customer is asking about ({{topic}}) and what they actually wrote ({{question}}). That is exactly the split query understanding gives you. A classified intent is one value you could put in a slot like {{topic}}, while the original question stays as written. Retrieved context, chosen using the extracted filters and rewritten terms, is added alongside them. The template's instructions then tell the model how to use each part, which matches the Databricks description of prompt augmentation. The registry example's second version adds explicit response guidelines (acknowledge the concern, give clear next steps, keep a professional tone) on top of the same variables. Because the template is versioned, changes like these can be tracked against the application version.

Sources35

Exam traps

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

1. 1.Adding an LLM step that extracts filters from the user's query is enough to make filtered retrieval work.Why is that wrong?

   Filters only work if each chunk carries the matching metadata fields and the retriever accepts and applies them. Both the data pipeline and the retriever have to change.

   Covered in Key fields: turning parts of the query into retrieval filters

2. 2.Query rewriting is a self-contained prompt change that does not affect the rest of the chain.Why is that wrong?

   Databricks states that rewriting must be paired with changes to the retrieval component, for example searching with several variations and deduplicating the results.

   Covered in Terms: rewriting and expanding the user's wording

3. 3.A single LLM call that classifies intent, extracts entities and rewrites the query together is always the better design, because fewer calls means better quality.Why is that wrong?

   A single call is efficient, but splitting query understanding into several calls can give finer control and better retrieved documents, at the cost of some latency.

   Covered in Intents: deciding what the user is asking for

4. 4.The user's raw query is the best retrieval query because it states exactly what the user wants.Why is that wrong?

   Using the raw query works for some cases, but Databricks advises reformulating it before retrieval so it better expresses intent.

   Covered in Intents: deciding what the user is asking for