Traditional retrieval systems are largely optimized around query text. Ranking models attempt to infer intent from words alone and identify the most relevant documents. In practice, however, users rarely speak in the same language as index. They do not know field names, metadata values, scoring rules, or indexed taxonomies. Important retrieval signals often remain embedded in natural language where the search engine cannot directly exploit them.
As retrieval systems become increasingly agentic, customers are asking whether search systems can move beyond keyword matching and automatically generate retrieval guidance from user queries. Rather than requiring customers to author filters, select facets, or configure search options manually, can LLMs infer those signals directly from language?
We refer to this capability as agentic query hint generation. In this post, we explore three complementary mechanisms to extract structured retrieval signals from user inputs leveraging LLMs:
- Filtering determines which documents are eligible for retrieval.
- Boosting prioritizes documents matching inferred preferences.
-
Multi-Word Expression (MWE) identifies phrase-level concepts that should be treated as single semantic units.
Figure 1. From user inputs to retrieval signals: filtering, boosting, and multi-word expression.
Filtering: Turning Language into Retrieval Constraints
OData filters are already widely used by Foundry IQ customers to shape retrieval, but they are usually hand-authored, generated from fixed rules, or assembled through structured UI controls. These approaches work when the filtering choices are known in advance, but it requires extra work from customers. Now we propose an agentic way to construct filters automatically.
How filtering works?
For a query such as:
Show me SEC filings from 3M in FY2018
the agent would generate the following OData filter:
company eq '3M' and fiscal_year eq 2018
The generated filters act as gates and determine whether documents satisfy the condition or not. This makes filtering powerful, but also risky. A correctly applied filter can narrow the search space and potentially make retrieval more efficient, but an incorrect one can remove relevant evidence before retrieval and ranking have an opportunity to consider it.
Thus, we designed the system to favor grounded, conservative decisions rather than the most expressive filter it could produce. The model receives the query alongside the index schema, allowed values, OData syntax guidance, and optional field-level instructions that explain the local meaning of metadata. It may also abstain and return no filter when the query does not justify a hard constraint.
In current release, we limit the initial generation surface to high-confidence equality, inequality, and Boolean combinations over supported filterable fields. This reduces opportunities for syntactically valid but semantically unsafe expressions while keeping the feature aligned with the behaviors we can evaluate thoroughly.
Experiment setup
To evaluate the capability, we constructed five retrieval environments spanning product support documents, device manuals, SEC filings, multilingual industry corpora, and vehicle configuration datasets. Together these environments cover schema mapping, multilingualism, abstention behavior, Boolean logic, and typed metadata fields.
Evaluating these outputs requires more than checking whether the generated filter looks right. A valid expression can still change the user’s intent; different strings can select the same candidate set, and a plausible filter may not improve retrieval. We therefore evaluated both the filtering decision and its downstream effect.
The evaluation focused on:
- Accepted decision rate: outputs judged equivalent to, or defensibly better than, the ground-truth oracle filter.
- Harmful over-filtering: unsupported or incorrect restrictions that could exclude valid results.
- Under-filtering: missing required constraints or abstaining when a filter was warranted.
- Semantic repeatability: whether repeated generations expressed the same filtering decisions.
-
Retrieval lift: the change in retrieval quality when using the generated filter instead of no filter.
Retrieval impact
Figure 2. Retrieval quality with generated filters across evaluated environments.
Generated filters improved retrieval quality across all evaluated environments, with the largest gains where metadata carried eligibility information that was only weakly visible in text. In Product support, Device manuals and Vehicle configurations datasets, many documents can look similar in prose while differing in structured fields such as product family, access level, manual type, drivetrain, equipment, or warranty. The filter helped by restricting the candidate set before retrieval began, leading to huge improvement in retrieval quality.
Error analysis showed that most rejected outputs were conservative omissions: false abstentions or missing constraints. That is safer than adding unsupported restrictions, but it still weakens the benefit of filtering. The pattern suggested that the model was not struggling with OData syntax but rather deciding when user language was grounded enough to become a hard constraint.
This points to a practical recommendation for customers using filters: provide field-level FilterInstructions wherever raw schema names and values do not explain local meaning. Product nicknames, access-level terminology, aliases, and domain-specific values can all affect whether a phrase should become a filter. FilterInstructions supply that missing context, helping the model decide which phrases are safe to filter on, and which should remain part of retrieval intent. It’s an effective technique to help customers mitigate filter issues.
Boosting: Turning Preferences into Ranking Signals
Not every retrieval signal should become a hard constraint. A company, topic, model, or language may express a preference that should influence ranking without excluding other useful evidence.
Consider: What did 3M report about property and equipment? The company name is clearly important, but restricting retrieval to only 3M documents may be unnecessarily narrow. Boosting provides a softer alternative: it prioritizes matching documents while keeping the broader candidate set eligible.
How boosting works
At query time, the agent emits a structured metadata hint such as $company:3M. The retrieval layer rewrites it as a soft Lucene clause, company:(3M)^3, and prepends it to the escaped free-text query. The boosting clause reweights ranking rather than filtering. It only takes effect when the hinted value matches an indexed, searchable token. Text fields use their configured analyzer, while slug-like values require an exact indexed token. A matched hint can move preferred evidence upward; an unmatched hint is usually a no-op.
Experimental setup
We evaluated boosting across FreshStack, SEC filings, and Device manuals using various models from the GPT-4.1 and GPT-5.4 families. FreshStack contains realistic technical questions and documentation across recent software topics. The sweep covered English and multilingual settings and compared Microsoft language analyzers with standard.lucene where applicable. We measured answer match, document coverage, no-answer rate, and total tokens. The broader sweep showed a consistent benefit across the GPT-5.4 family.
Retrieval impact
Boosting improved answer match on both FreshStack and SEC. The same overall pattern was consistent across the GPT-5.4 family: boosting generally improved answer quality or coverage while reducing the context required downstream. Across the non-English evaluation covering Spanish, German, Chinese, Japanese, and French, pooled answer match improved from 69.2 to 71.5, grounding improved from 87.8 to 89.0, and no-answer decreased from 2.31 to 1.25. Coverage improved in Spanish, German, Chinese, and Japanese, with a slight regression in French. Device manuals was already near the quality ceiling, with no-answer equal to zero, so boosting produced little answer lift. Its main benefit was efficiency. This suggests that answer-quality gains require both retrieval headroom and metadata values the model can map to searchable index tokens.
Table 1. Answer match and coverage results from the GPT-5.4-mini run.Efficiency impact
Boosting reduced retrieved context across evaluated datasets. Token use fell by 13.6% on SEC, 12.4% on FreshStack, and 9.0% on Device manuals, while answer quality was maintained or improved. The broader sweep showed the same efficiency trend across the GPT-5.4 family. In the multilingual pooled analysis, token use decreased in every language, with the largest reductions in Japanese and Chinese at 22.7% and 22.0%, respectively. The practical interpretation is that a useful boost can surface the right chunk earlier, reducing the amount of context that must be processed downstream.
Table 2. Retrieved-context token results from the GPT-5.4-mini run.Failure analysis and grounding
Boosting failures were usually low-risk because the intervention is soft. In the SEC analysis, only 1 of 620 emitted hints in our evaluation pointed to the wrong company, and FreshStack produced no wrong-topic sibling matches across the tested arms. Most misses were aliases or fine-grained values that did not match an indexed token, so the boost had no effect rather than promoting a competing entity.
- SEC alias mismatch: a hint such as $company:JnJ may be emitted for Johnson & Johnson, but if the indexed company token is Johnson & Johnson, the rewritten clause does not match. The original query remains intact, so retrieval proceeds without the boost.
- SEC former-name mismatch: a hint such as $company:Square may be emitted for Block. If Square is not an indexed company token, the clause becomes a no-op; it does not redirect ranking toward another company.
- FreshStack taxonomy mismatch: the model may emit a fine-grained hint such as $topic:php, $topic:vector-databases, $topic:ultralytics, or $topic:chromadb when the index contains only a small set of coarser topic tokens. Because none of these values match the topic field, the boost matches zero documents and leaves the baseline ranking unchanged.
No-op failures still leave retrieval gains unrealized, especially for opaque Device manuals metadata. For example, a user may ask “SQ40 multifunction printer” while the index stores model=sq40 and device=mfp_printer. Grounding supplies these valid tokens, helping the boost match the intended manual. In our evaluation, grounding increased Device manuals document coverage from 95.4 to 96.6 while answer match remained unchanged.
Multi-Word Expressions: Preserving Non-Compositional Meaning
Some phrases have a specific domain meaning that cannot be inferred by interpreting each word independently. These are non-compositional multi-word expressions. When retrieval separates the words, documents about the wrong sense can outrank documents about the actual concept.
Examples include:
- “deferred tax,” an accounting asset or liability arising from timing differences, not simply a tax that is delayed;
- “wash sale,” a tax rule involving a loss and a substantially identical repurchase, not a retail sale involving washing; and
- “material weakness,” an internal-control deficiency, not a physical weakness in a material.
The customer problem is therefore narrower than generic phrase matching. The goal is to recognize the phrases for which literal word-by-word interpretation would be materially wrong, and to favor evidence that contains the concept intact.
How MWE-aware retrieval works
Non-compositional MWEs are detected while the agent forms the queries when calling an Azure search tool. When an identified phrase also appears in the generated search query, the retrieval layer keeps the original query and appends a soft Lucene clause.
For example:
Original query:
Coca-Cola deferred tax asset valuation allowance beginning 2015
MWE-aware query:
(Coca-Cola deferred tax asset valuation allowance beginning 2015) OR "deferred tax"^5.0
The important behavior is concept preservation: “deferred tax” should remain intact in the model’s interpretation rather than being reduced to unrelated signals for “deferred” and “tax”. This is a soft ranking intervention, not a hard quoted filter, so broader evidence remains eligible.
Detection and retrieval results
Generic datasets often emphasize proper nouns, identifiers, or compositional technical terms. To isolate the intended failure mode, the SEC-MWE benchmark contains 134 synthesized queries built around non-compositional financial expressions, for example material weakness, wash sale, deferred tax etc.
The evaluation asks two separate questions:
- Detection: does the expected MWE survive in the model-emitted retrieval query?
- Retrieval impact: does MWE boosting improve recall, ranking, and downstream answer success compared with the original simple query?
On the curated SEC-MWE dataset, model-side detection preserved the expected expression in all samples. In the end-to-end evaluation, MWE-aware retrieval improved success rate, evidence recall, nDCG@8, and recall AUC relative to the baseline. The ranking improvement is also visible at the query level: for a Coca-Cola question about the deferred tax asset valuation allowance beginning in 2015, the relevant evidence moved from rank 2 to rank 1 after the MWE-aware rewrite, surfacing the ground-truth passage that reported a $649 million valuation allowance.
Table 3. Quality comparison on SEC-MWE dataset.Failure analysis and limits
The gains were not uniform. Broad or repeated expressions can occur across multiple years, filings, or neighboring sections, so a phrase boost may promote a contextually related passage without surfacing the exact evidence the question requires. Similar losses appeared for boilerplate expressions such as mark-to-market or sinking fund, which are not always discriminative enough on their own. Multilingual results showed consistent coverage gains across Spanish, German, Chinese, and Japanese. Improvements ranged from +1.56 to +4.70 points with standard.lucene and from +0.28 to +2.55 points with language-specific analyzers; French was the only small regression in both settings.
Get started
Starting with the 2026-08-01-preview API version, query hints guide the query-planning model to generate filters and ranking boosts from a user's request. See Configure query hints for configuration details.
Microsoft