CONCEPT Cited by 1 source
Implicit query location rewrite¶
Definition¶
Implicit query location rewrite is the search-pipeline technique of rewriting the location portion of a user's search request (typically the geobox — the rectangular latlong region retrieval is constrained to) based on a location-segment extracted from the query text, without asking the user and without showing the change in the UI.
It's "implicit" in two senses:
- The rewrite happens in the search backend, not the UI — the user's displayed location picker is unchanged.
- The rewrite is gated on a confidence threshold — only high-confidence location-intent segmentations trigger the rewrite; low-confidence segmentations leave the user's location untouched.
Canonical wiki instance: Yelp¶
Canonical reference: Yelp's 2025-02-04 post (sources/2025-02-04-yelp-search-query-understanding-with-llms). Three canonical examples from the post's table:
| Original query | User's location | Rewritten location (search backend only) |
|---|---|---|
| Restaurants near Chase Center | San Francisco, CA | 1 Warriors Way, San Francisco, CA 94158 |
| Ramen Upper West Side | New York, NY | Upper West Side, Manhattan, NY |
| Epcot restaurants | Orlando, FL | Epcot, Bay Lake, FL |
Mechanism verbatim:
"One of our POC leverages query segmentation to implicitly rewrite text within location boxes to a refined location within 30 miles of the user's search if we have high confidence in the location intent. For example, the segmentation 'epcot restaurants => {location} epcot {topic} restaurant' helps us to understand the user's intent in finding businesses within the Epcot theme park at Walt Disney World. By implicitly rewriting the location text from 'Orlando, FL' to 'Epcot' in the search backend, our geolocation system was able to narrow down the search geobox to the relevant latlong."
Why it's load-bearing¶
Two joint failure modes it fixes:
- User-specified location is too coarse. A user in Orlando searching "Epcot restaurants" really wants restaurants inside Epcot (the theme park), not any restaurant within Orlando. Without location rewrite, retrieval returns hundreds of irrelevant results from outside the park.
- Users don't use the location picker. The location field on Yelp defaults to a broad geographic area (the user's city); users typically don't narrow it before typing a query, even when they know the precise location they want. Rewriting implicitly catches the mismatch without requiring UI gesture.
Preconditions¶
The pattern is load-bearing only when these hold:
- Query segmentation produces a reliable
{location}tag. This is why the Yelp post fuses spell-correction with segmentation — a mis-spelled location has to be corrected before it can be rewritten. See systems/yelp-query-understanding. - Confidence-gating is available. Rewriting on every location tag over-commits and degrades results on ambiguous cases. Yelp's gate: the location-tag confidence must be "high" AND the rewritten location must be "within 30 miles of the user's search."
- Geolocation backend accepts arbitrary latlong constraints. Coarse-grained city-level geoboxes can't be refined to "Epcot, Bay Lake, FL" without a rich geographic database.
Tradeoffs / gotchas¶
- Over-specificity failure. If the rewrite targets a latlong that turns out to be wrong (e.g. user's ambiguous "Chase Center" could be the one in SF or the one in Wilmington), a tight rewrite can miss correct results entirely. Confidence gating + distance cap are the mitigations.
- Downstream UI surprise. If the rewrite materially changes results (e.g. a user's "my favourite sushi place" doesn't show up because the search is now narrowed to "Epcot"), the user may not realise why and can't undo the rewrite via the UI. The trade is usually worth it because the median case improves, but edge cases confuse users.
- Ambiguous named locations. "Chase Center" exists in multiple cities. Without a disambiguation signal (user's coarse location, session history), the rewrite can go to the wrong one.
- Must be reversible. If a confidence-gated rewrite produces zero results, falling back to the user's original location (without showing an error) is the correct graceful-degradation behaviour.
Related¶
- concepts/query-understanding — the upstream pipeline
that produces the
{location}tag. - concepts/token-probability-as-ranking-signal — the companion trick of retaining segmentation confidence past the discrete tag, used for ranking; location rewrite uses the confidence similarly but for a gating decision, not a ranking one.
- Implicit vs. explicit query rewrite — Yelp's other query-understanding consumers (business-name matching, filter auto-enablement) are similarly implicit. The explicit variant — "Did you mean Epcot?" — is a dialogue pattern, orthogonal to this one.
Seen in¶
- sources/2025-02-04-yelp-search-query-understanding-with-llms — canonical reference; three worked examples (Chase Center, Upper West Side, Epcot) + explicit confidence-gate + 30-mile radius cap.