TL;DR: AI assistants plausible लगने वाले लेकिन ग़लत addresses गढ़ देते हैं, जिसकी दर chain hotels में लगभग 6% से लेकर independent vacation rentals में 38% तक होती है। समाधान model को सही करना नहीं है। Schema.org Place markup, verified coordinates और एक canonical external identifier के ज़रिए एक unambiguous ground truth publish कीजिए, और फिर उस जानकारी को हर उस platform पर consistent रखिए जहाँ वह business दिखता है।
ChatGPT से Porto के किसी three-star होटल का पता पूछिए और वह शायद आपको एक street name, number, और postal code बता देगा। जवाब पूरे आत्मविश्वास के साथ आएगा। बड़े chain होटलों के लिए जवाब आमतौर पर सही होगा। लेकिन दो गलियाँ आगे स्थित किसी स्वतंत्र boutique property के लिए, उत्तर गलत होने की संभावना काफ़ी ज़्यादा होती है।
यह कोई दुर्लभ मामला नहीं है। यह language model द्वारा text generate करने के तरीके का एक अनुमानित परिणाम है, और जिन businesses की पहचान किसी विशिष्ट location पर पाए जाने पर निर्भर करती है, उनके लिए इसके सीधे परिणाम होते हैं।
Location Hallucination की कार्यप्रणाली
एक language model पतों का database नहीं रखता। वह tokens पर एक statistical distribution रखता है। जब पता पूछा जाता है, तो वह tokens की एक ऐसी sequence predict करता है जो उस शहर में उस प्रकार के venue के पते जैसी लगती है।
यदि training data में असली पता कई बार, consistently, और authoritative sources में आया था, तो prediction सही string पर converge हो जाती है। यदि पता कम, inconsistent तरीके से, या बिल्कुल नहीं आया था, तो model interpolate करता है। वह neighbourhood के लिए सही लगने वाली सड़क चुनता है, block में फ़िट होता नंबर, और local pattern से मेल खाता postal code।
Output व्याकरण की दृष्टि से सही, geographically प्लॉज़िबल, और अक्सर पूरी तरह से गलत होता है।
Sample Audit: Query Type के अनुसार Hallucination Rates
हमने अप्रैल 2026 में तीन प्रमुख AI assistants के ज़रिए 500 location queries चलाए। हर query एक विशिष्ट venue का पता पूछती थी। उत्तरों की तुलना MapAtlas GeoEnrich में venue के verified पते से की गई।
नीचे दी गई table में उन responses का प्रतिशत है जिनमें कम से कम एक महत्वपूर्ण address error था (गलत street, गलत number, गलत postal code, या गलत शहर)। ये आँकड़े directional हैं और इस sample के लिए विशिष्ट हैं।
| Query प्रकार | ChatGPT | Perplexity | Gemini |
|---|---|---|---|
| Chain होटल | 6% | 4% | 7% |
| स्वतंत्र boutique होटल | 19% | 14% | 22% |
| Vacation rental | 38% | 29% | 41% |
| स्वतंत्र रेस्टोरेंट | 24% | 18% | 27% |
| लैंडमार्क या attraction | 9% | 5% | 8% |
स्रोत: MapAtlas sample audit, अप्रैल 2026, n=500 queries।
दो patterns साफ़ दिखते हैं। पहला, hallucination rate उस हद तक बढ़ती है जितना sparse और inconsistent किसी venue का web footprint होता है। Vacation rentals, जो अक्सर किसी एक listing platform पर होते हैं और जिनकी कोई स्वतंत्र homepage नहीं होती, सबसे ज़्यादा प्रभावित होते हैं। दूसरा, Perplexity लगातार कम hallucinate करता है, शायद इसलिए क्योंकि इसकी retrieval layer parametric memory के बजाय live sources पर जवाब ground करती है।
एक वास्तविक उदाहरण
अप्रैल 2026 में पूछी गई query: "What is the address of Casa do Vale guesthouse in Porto?"
एक प्रमुख assistant का hallucinated जवाब:
Casa do Vale is located at Rua de Santa Catarina 142, 4000-442 Porto, Portugal.
Property के अपने records और MapAtlas Geocoding से verified जवाब:
Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal.
गलत सड़क, गलत postal code, शहर का गलत छोर। Hallucinated उत्तर guest को असली guesthouse से तीन किलोमीटर दूर किसी shopping district में भेज देता है। यह गलती random नहीं है। Rua de Santa Catarina Porto की सबसे प्रसिद्ध commercial street है और Porto accommodation queries के training data में भारी मात्रा में दिखती है। Model ने शहर के लिए सबसे मज़बूत statistical prior को default मान लिया।
Structured Data परिणाम क्यों बदल देता है
सही ढंग से बना Place या LodgingBusiness JSON-LD block वाला listing page model को कुछ ऐसा देता है जिसे वह बनाने के बजाय extract कर सकता है।
{
"@context": "https://schema.org",
"@type": "LodgingBusiness",
"name": "Casa do Vale",
"address": {
"@type": "PostalAddress",
"streetAddress": "Rua do Vale 38",
"postalCode": "4200-512",
"addressLocality": "Porto",
"addressCountry": "PT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 41.1621,
"longitude": -8.5937
},
"identifier": {
"@type": "PropertyValue",
"propertyID": "wikidata",
"value": "Q00000000"
}
}
इस block की तीन विशेषताएँ hallucination कम करने के लिए महत्वपूर्ण हैं:
- Structured fields. Model को वाक्य parse नहीं करना पड़ता। Street, postal code, शहर, और देश अलग-अलग keys हैं।
- ऐसे coordinates जो पते से मेल खाते हैं. Crawler verify कर सकता है कि latitude और longitude postal code polygon के अंदर हैं। Mismatch होने पर data low confidence के रूप में flag हो जाता है।
- एक stable external identifier. Wikidata या Google Place ID listing को एक canonical entity से जोड़ता है। Model training-data frequency पर निर्भर रहने के बजाय authoritative source के सामने पते को reconcile कर सकता है।
जब ये तीनों शर्तें पूरी होती हैं, तो generation की जगह extraction आ जाता है। Hallucinated उत्तर की संभावना तेज़ी से गिरती है।
NAP Consistency Layer
Listing page पर schema ज़रूरी है लेकिन पर्याप्त नहीं। AI systems पते को दूसरे public sources के साथ cross-check करते हैं: Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, booking platforms, और open web। जब इनमें असहमति होती है, तो confidence गिरती है और model hedge करने या generate करने की ओर झुक जाता है।
इसीलिए platforms के बीच Name, Address, Phone (NAP) consistency citation की किसी भी एक signal से ज़्यादा मज़बूत predictor है। एक ऐसा listing जिसमें perfectly बना schema है लेकिन Google Business Profile पर पता अलग है, फिर भी ख़राब प्रदर्शन करेगा। मेक्निक्स के लिए NAP consistency for AI search देखें।
Hallucination Risk क्या ठीक करता है
हमारे audits में जिन चार उपायों का सबसे ज़्यादा असर रहा है:
1. पते के साथ verified coordinates publish करें. लिखित पता एक string है। Coordinates एक verifiable fact हैं। MapAtlas Geocoding raw addresses को scale पर सटीक latitude और longitude में बदलता है और उन inputs को flag करता है जो ठीक से resolve नहीं होते।
2. Location facts को JSON-LD में wrap करें. Place, LodgingBusiness, Hotel, Restaurant, और LocalBusiness types सभी address, geo, और identifier fields accept करते हैं। जो fields गायब होते हैं, वहीं से model अनुमान लगाना शुरू करता है।
3. एक canonical identifier से reconcile करें. Listing को Wikidata QID या Google Place ID से link करें। इससे AI systems को deduplicate करने के लिए एक primary key मिलती है।
4. Nearby context से enrich करें. Hallucinations सिर्फ़ address field तक सीमित नहीं हैं। Model पास के landmarks, transit stops, और walk times भी बना लेते हैं। MapAtlas GeoEnrich द्वारा generated verified proximity data इन claims को भी anchor करता है। Location-specific FAQs इस data को उजागर करने का एक प्रभावी surface हैं।
Hallucinated पते की कारोबारी लागत
AI assistant द्वारा दिखाया गया गलत पता सिर्फ़ model को शर्मिंदा नहीं करता। यह एक असली guest को गलत जगह भेज देता है। आगे के असर जुड़ते जाते हैं:
- एक रद्द की गई booking, या इससे भी बुरा, एक no-show।
- एक negative review जो गलत location का ज़िक्र करती है, जो फिर अगली model generation के लिए training data बन जाती है।
- आगे चलकर listing के लिए citation confidence कम हो जाती है, क्योंकि public web में अब विरोधाभासी signals हैं।
यह असमानता महत्वपूर्ण है। एक hallucinated पता listing को नुकसान पहुँचाता है भले ही listing खुद निर्दोष हो। इसका समाधान model को सीधे ठीक करना नहीं है, जो संभव नहीं है, बल्कि ground truth को इतना स्पष्ट बनाना है कि model के पास generate करने का कोई कारण ही न बचे।
अपनी Exposure कैसे जाँचें
मुफ्त MapAtlas AEO Checker किसी listing का 29 structured signals के ख़िलाफ़ मूल्यांकन करता है, जैसे address schema, coordinate presence, NAP consistency, और external identifiers। जो listings ये checks pass करते हैं, उनके AI answers में गलत रूप से दिखाई देने की संभावना काफ़ी कम होती है। जो fail होते हैं, वही वे हैं जहाँ model को अंदाज़ा लगाना पड़ता है।
Location hallucinations किसी एक assistant की खामी नहीं हैं। वे एक ऐसे open web पर training का अनुमानित परिणाम हैं जहाँ एक ही business अलग-अलग pato और दर्जनों sources में थोड़े-बहुत अलग पते के साथ दिखाई देता है। समाधान यह है कि एक ground truth को ऐसे format में publish किया जाए जिसे AI systems extract कर सकें, और उस ground truth को हर जगह consistent रखा जाए जहाँ business represented है।
संबंधित पठन:
- AI search के लिए Location-specific FAQs
- SEO पहले keyword-to-keyword था, अब यह database-to-database है
- AI search के लिए NAP consistency
- अपना AI visibility score मुफ्त में जाँचें
अक्सर पूछे जाने वाले प्रश्न
AI address hallucination क्या है?
AI address hallucination तब होता है जब कोई large language model किसी ऐसे street address, postal code, या coordinate को बताता है जो सुनने में सही लगता है लेकिन असल व्यवसाय, लैंडमार्क, या property के वास्तविक स्थान से मेल नहीं खाता। यह कोई छोटी rounding गलती नहीं है। model ने एक ऐसा पता बना दिया है जो मौजूद ही नहीं है, या किसी और जगह का है, या असली सड़क को गलत शहर के साथ जोड़ दिया गया है। listings के लिए यह बहुत नुकसानदेह है क्योंकि user गलत जगह पहुँचने के बाद ही समझ पाता है कि उत्तर झूठा था।
AI असिस्टेंट गलत पते क्यों बताते हैं?
Language model अगला सबसे संभावित token predict करके text बनाते हैं, facts देखकर नहीं। जब कोई पता web पर कम दिखाई देता है, अलग-अलग जगह अलग-अलग लिखा है, या crawling से ब्लॉक है, तो model उस gap को एक statistically संभावित string से भर देता है: शहर के लिए सही लगने वाला street name, क्षेत्र से मेल खाता postal code pattern, एक सामान्य-सा नंबर। जब उत्तर को anchor करने के लिए कोई structured ground-truth source नहीं होता, तो model के पास याद की गई fact और बनाई गई fact के बीच अंतर करने का कोई तरीका नहीं होता।
Location hallucination असल में कितनी बार होते हैं?
अप्रैल 2026 में MapAtlas द्वारा किए गए एक sample audit में, जिसमें होटल, vacation rental, रेस्टोरेंट और लैंडमार्क के 500 location queries शामिल थे, address-level hallucination rate प्रसिद्ध chain होटलों के लिए लगभग 6% से लेकर स्वतंत्र vacation rentals के लिए 38% तक थे। सामान्य लैंडमार्क queries सबसे अच्छा प्रदर्शन करते हैं; long-tail listing queries सबसे खराब। यह rate directional है और model, भाषा, और डेटा की ताज़गी के अनुसार बदलती है, लेकिन pattern consistent है: जिस venue के पास जितना कम structured data होता है, model उतना ज़्यादा बनाता है।
क्या Schema.org structured data hallucinations को कम करता है?
हाँ, जब data verified है और सभी sources में consistent है। Place या LodgingBusiness JSON-LD block को सही geo coordinates, validated postal address, और Wikidata या Google Place ID जैसे authoritative identifiers के cross-reference के साथ publish करने से model को एक ground-truth anchor मिलता है जिसे वह extract और cite कर सकता है। Inconsistent schema, जैसे ऐसे coordinates जो लिखित पते से मेल नहीं खाते, confidence बढ़ाने के बजाय कम कर देते हैं।
मैं अपनी listings का hallucination risk कैसे audit करूँ?
अपना listing URL mapatlas.eu/ai-seo-checker पर मुफ्त MapAtlas AEO Checker में चलाएँ। यह checker उन 29 structured signals का मूल्यांकन करता है जिनका उपयोग AI systems location facts को anchor करने के लिए करते हैं, जैसे geo coordinates, Place schema, प्लेटफ़ॉर्म्स में NAP consistency, और nearby-context fields की उपस्थिति। जिन pages में ये signals नहीं होते वे hallucination risk पर ज़्यादा score करते हैं क्योंकि model को extract करने के बजाय अंदाज़ा लगाना पड़ता है।
