Parsing Queries into Structured Filters

A shopper types "red running shoes under 100 not nike size 10". What the catalogue can answer is a conjunction: category running shoes, colour red, price below 100, size 10, brand not Nike. Embed the raw string instead and the word "nike" pulls Nike products toward the query vector, the one brand the user excluded. The structure was in the query all along. Parsing extracts it so the index can apply it exactly, and passes whatever is left as free text to the ranker.

This is distinct from intent classification, which decides what kind of answer a query needs, and from filtered vector search, which covers how an index executes a filter efficiently once it has one. Parsing is the step in between that produces the filter.

Query tagging as sequence labelling

The classical formulation assigns each query token a label from the schema: COLOR, CATEGORY, PRICE_MAX, BRAND, or O for free text. Li, Wang and Acero framed this as query tagging against structured documents and trained linear-chain conditional random fields (Li, Wang and Acero, 2009, Extracting Structured Information from User Queries with Semi-Supervised Conditional Random Fields, SIGIR). A CRF models the label sequence \(y\) given tokens \(x\) as

where \(f_j\) are feature functions over adjacent labels and the token context, \(\lambda_j\) are learned weights, and \(Z(x)\) normalises over all label sequences. Labelled queries are expensive, so their key move was semi-supervised: a small hand-labelled set plus a large set of queries whose tokens received labels automatically from catalogue resources, such as a query token that exactly matches a known brand name.

Tagging produces spans, not filters. A normalisation step still has to map "nike" to a canonical brand ID, "under 100" to price < 100 in the right currency, and "size 10" to a size system that depends on the category. Most production errors live in this mapping rather than in the tagger.

Schema-constrained LLM parsing

The current pattern hands the schema to a language model and constrains its output to a filter expression:

{"and": [{"category": "running_shoes"}, {"color": "red"},
         {"price": {"lt": 100}}, {"size": "10"},
         {"not": {"brand": "nike"}}],
 "text": ""}

The model sees field names, types and enumerated values, and constrained decoding guarantees the output parses. It handles phrasings no tagger was trained on ("anything but Nike", "less than a hundred bucks") and can emit boolean structure a token tagger cannot. The cost is a model call on the query path, usually on the order of hundreds of milliseconds, which is an estimate that varies widely with model size and hosting. The common production shape runs a fast tagger or a cache on head queries and sends only the long tail to the model.

Negation is where parsing earns its keep

Negation is exactly what similarity-based retrieval gets wrong. NevIR gives models two documents that differ only by a negation and two queries, each matching one document, and scores a model correct only if it ranks both pairs right, so random ranking scores 25 percent. TF-IDF scored 2.0 percent, ColBERTv2 13.0, and the best model, the 2.85-billion-parameter MonoT5 cross-encoder, 50.6; human annotators got every sampled instance right (Weller, Lawrie and Van Durme, 2024, NevIR: Negation in Neural Information Retrieval, EACL, arXiv:2305.07614). QUEST's 3,357 entity-seeking queries with implicit set operations, such as "shorebirds that are not sandpipers", found negation and conjunction particularly hard for retrievers, and harder still in combination (Malaviya et al., 2023, QUEST: A Retrieval Dataset of Entity-Seeking Queries with Implicit Set Operations, ACL, arXiv:2305.11694).

A parsed not is a set difference, and an index executes it exactly. That is the strongest argument for parsing, and it holds only when the negated thing is an attribute in the schema. "Hotels not near the airport" negates a relation the catalogue may not store.

The alternative camp trains retrievers to understand exclusion directly. ExcluIR provides 3,452 annotated exclusionary queries and over 70,000 training pairs, and finds that such training helps but leaves models short of human performance (Zhang et al., 2024, ExcluIR: Exclusionary Neural Information Retrieval, arXiv:2404.17288). NevIR shows the risk: fine-tuning on negation data raised pairwise accuracy, but MonoT5 overfit quickly and lost performance on MS MARCO as it did. Parsing moves the problem into a component you can inspect; training moves it into weights you cannot.

When it breaks

Hard filters destroy recall. A shoe at 101 is excluded by "under 100" though most users would want it. Treating soft constraints such as price, rating and distance as boosts, and hard constraints such as size and exclusions as filters, is a product decision that the parser should not make silently.

The model invents values. An LLM asked for a colour may return "crimson" when the catalogue only knows "red", and the filter matches nothing. Validate every value against the enumeration and fall back to free text when validation fails.

Vague words have no threshold. "Cheap", "recent" and "near me" mean different things per category and per user. Hard-coding a threshold turns a ranking preference into an exclusion.

Negation scope is ambiguous. In "laptops not from Dell with a touchscreen", the parser must decide whether "not" scopes over the touchscreen too. Wrong scope inverts the result set, and nothing downstream will flag it.

A misparse looks like a bad index. The user sees poor results, not a wrong filter. Log the parse beside every query and evaluate the parser by downstream retrieval quality, not only by exact-match against reference parses, the same lesson conversational query rewriting teaches.