آدرس‌های توهم‌زده هوش مصنوعی: چرا رخ می‌دهد و چگونه داده جغرافیایی

TL;DR: دستیارهای AI آدرس‌هایی می‌سازند که باورپذیر به نظر می‌رسند اما اشتباه‌اند، با نرخی از حدود ۶٪ برای هتل‌های زنجیره‌ای تا ۳۸٪ برای اجاره‌های تعطیلات مستقل. راه‌حل این نیست که مدل را اصلاح کنی. با markup از نوع Schema.org Place، مختصات تأییدشده و یک شناسه‌ی خارجیِ استاندارد، یک ground truth روشن منتشر کن و آن حقیقت را روی هر پلتفرمی که کسب‌وکار در آن دیده می‌شود هماهنگ نگه دار.

اگر از ChatGPT آدرس یک هتل سه‌ستاره در پورتو را بپرسی، احتمالاً با اسم خیابان، شماره و کد پستی جواب می‌دهد. جواب مطمئن به گوش می‌رسد. برای زنجیره‌های بزرگ معمولاً درست است. اما برای آن بوتیک هتل مستقلِ دو خیابان آن‌طرف‌تر، احتمال معناداری وجود دارد که جواب غلط باشد.

این یک حالت حاشیه‌ای و نادر نیست. این خروجی قابل‌پیش‌بینی نحوه‌ی تولید متن در مدل‌های زبانی است و برای هر کسب‌وکاری که بقایش به پیدا شدن در یک مکان مشخص وابسته است پیامد مستقیم دارد.

مکانیسم یک توهم مکانی

مدل زبانی یک دیتابیس از آدرس‌ها ذخیره نمی‌کند. چیزی که ذخیره می‌کند یک توزیع آماری روی توکن‌هاست. وقتی آدرسی را می‌خواهی، مدل دنباله‌ای از توکن‌ها را پیش‌بینی می‌کند که شبیه آدرس همان نوع مکان در همان شهر به نظر می‌رسد.

اگر آدرس واقعی در داده‌ی تمرین بارها، به‌طور سازگار و در منابع معتبر آمده باشد، پیش‌بینی به رشته‌ی درست همگرا می‌شود. اگر آدرس کم، ناسازگار یا اصلاً ظاهر نشده باشد، مدل درون‌یابی می‌کند. خیابانی انتخاب می‌کند که برای آن محله مناسب به نظر می‌رسد، شماره‌ای که به بلوک می‌خورد، کد پستی که با الگوی محلی جور است.

خروجی از نظر گرامری درست، از نظر جغرافیایی باورپذیر و اغلب کاملاً غلط است.

نمونه‌بازرسی: نرخ توهم بر اساس نوع پرس‌وجو

در آوریل 2026 ما 500 پرس‌وجوی مکانی را از سه دستیار AI پیشرو عبور دادیم. هر پرس‌وجو آدرس یک مکان مشخص را می‌خواست. جواب‌ها با آدرس تأییدشده‌ی مکان در MapAtlas GeoEnrich مقایسه شدند.

جدول زیر سهم جواب‌هایی را نشان می‌دهد که حداقل یک خطای آدرسی واقعی داشته‌اند (خیابان غلط، شماره‌ی غلط، کد پستی غلط یا شهر غلط). اعداد جهت‌دار و مخصوص همین نمونه‌اند.

منبع: نمونه‌بازرسی MapAtlas، آوریل 2026، n=500 پرس‌وجو.

دو الگو اینجا به چشم می‌آید. اول، نرخ توهم با کم‌ردپا بودن و ناسازگار بودن حضور وب یک مکان بالا می‌رود. اقامتگاه‌های اجاره‌ای که اغلب فقط روی یک پلتفرم listing وجود دارند و وبسایت مستقل ندارند، بیشترین آسیب را می‌بینند. دوم، Perplexity به‌طور مستمر کمتر توهم می‌زند، احتمالاً چون لایه‌ی retrieval آن جواب‌ها را بیشتر در منابع زنده لنگر می‌اندازد و نه در حافظه‌ی پارامتری.

یک مثال واقعی

پرس‌وجو در آوریل 2026: «آدرس اقامتگاه Casa do Vale در پورتو چیست؟»

جواب توهم‌زده از یکی از دستیارهای پیشرو:

Casa do Vale در Rua de Santa Catarina 142، 4000-442 Porto، Portugal واقع است.

جواب تأییدشده از سوابق خود ملک و MapAtlas Geocoding:

Casa do Vale، Rua do Vale 38، 4200-512 Porto، Portugal.

خیابان غلط، کد پستی غلط، سمت غلط شهر. جواب توهمی مهمان را به یک منطقه‌ی خرید می‌فرستد که سه کیلومتر از اقامتگاه واقعی فاصله دارد. خطا تصادفی نیست. Rua de Santa Catarina معروف‌ترین خیابان تجاری پورتو است و در داده‌ی تمرین برای پرس‌وجوهای اقامت در پورتو به‌شدت ظاهر می‌شود. مدل به قوی‌ترین prior آماری برای شهر پناه برده است.

چرا داده‌ی ساخت‌یافته نتیجه را عوض می‌کند

یک صفحه‌ی listing با یک بلوک JSON-LD درست‌شکل از نوع Place یا LodgingBusiness به مدل چیزی می‌دهد که استخراج کند، نه چیزی که بسازد.

{
  "@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"
  }
}

سه ویژگی این بلوک برای کاهش توهم اهمیت دارد:

1. فیلدهای ساخت‌یافته. مدل لازم نیست جمله را parse کند. خیابان، کد پستی، شهر و کشور کلیدهای مجزا هستند.
2. مختصاتی که با آدرس جور درمی‌آیند. یک crawler می‌تواند بررسی کند که latitude و longitude داخل چندضلعی کد پستی قرار دارند. ناسازگاری‌ها داده را به‌عنوان کم‌اعتماد پرچم‌گذاری می‌کنند.
3. یک شناسه‌ی خارجی پایدار. Wikidata یا Google Place ID، listing را به یک موجودیت استاندارد گره می‌زند. مدل می‌تواند آدرس را با یک منبع معتبر تطبیق دهد، نه با فراوانی داده‌ی تمرین.

وقتی این سه شرط برقرارند، استخراج جای تولید را می‌گیرد. احتمال یک جواب توهمی به‌شدت افت می‌کند.

لایه‌ی سازگاری NAP

مخطط روی صفحه‌ی listing لازم است اما کافی نیست. سیستم‌های AI آدرس را در مقابل منابع عمومی دیگر هم چک می‌کنند: Google Business Profile، OpenStreetMap، Yelp، Tripadvisor، پلتفرم‌های رزرو و وب باز. وقتی این‌ها با هم تناقض دارند، اعتماد پایین می‌آید و مدل بیشتر تمایل پیدا می‌کند به احتیاط یا ساختن.

به همین دلیل سازگاری Name، Address، Phone (NAP) در بین پلتفرم‌ها پیش‌بینی‌کننده‌ی قوی‌تری برای استناد است تا هر سیگنال منفرد. یک listing با مخطط کامل ولی آدرس متناقض در Google Business Profile باز هم ضعیف عمل می‌کند. برای جزئیات به سازگاری NAP در جست‌وجوی AI مراجعه کن.

چه کارهایی ریسک توهم را کم می‌کند

چهار اقدام در بازرسی‌هایی که انجام داده‌ایم بیشترین تأثیر را داشته‌اند:

۱. مختصات تأییدشده را کنار آدرس منتشر کن. آدرس نوشتاری یک رشته‌ی متنی است. مختصات یک واقعیت قابل‌راستی‌آزمایی است. سرویس Geocoding از MapAtlas آدرس خام را در مقیاس به latitude و longitude دقیق تبدیل می‌کند و ورودی‌هایی را که تمیز resolve نمی‌شوند پرچم می‌زند.

۲. واقعیت‌های مکانی را در JSON-LD بپیچ. نوع‌های Place، LodgingBusiness، Hotel، Restaurant و LocalBusiness همه فیلدهای address، geo و identifier را می‌پذیرند. فیلدهای گم‌شده همان‌جایی هستند که مدل شروع به حدس زدن می‌کند.

۳. با یک شناسه‌ی استاندارد تطبیق بده. listing را به یک Wikidata QID یا Google Place ID وصل کن. این به سیستم‌های AI یک کلید اصلی می‌دهد تا داده‌های تکراری را حذف کنند.

۴. با context نزدیک غنی کن. توهم به فیلد آدرس محدود نیست. مدل‌ها همچنین landmarkهای نزدیک، ایستگاه‌های حمل‌ونقل و زمان پیاده‌روی را هم می‌سازند. داده‌ی تأییدشده‌ی مجاورت که توسط GeoEnrich از MapAtlas تولید می‌شود این ادعاها را هم لنگر می‌اندازد. پرسش‌های متداول مخصوص مکان یک سطح مؤثر برای نمایش این داده است.

هزینه‌ی تجاری یک آدرس توهمی

یک آدرس غلط که دستیار AI اعلام می‌کند فقط مدل را شرمنده نمی‌کند. یک مهمان واقعی را به جای اشتباه می‌فرستد. اثرات بعدی روی هم تلنبار می‌شوند:

• یک رزرو لغوشده، یا بدتر از آن، یک no-show.
• یک نقد منفی که مکان اشتباه را ذکر می‌کند و همان نقد بعداً می‌شود داده‌ی تمرین برای نسل بعدی مدل.
• کاهش اعتماد استنادی برای listing در آینده، چون وب عمومی حالا پر از سیگنال‌های متناقض است.

این عدم‌تقارن مهم است. یک آدرس توهمی به listing آسیب می‌زند حتی وقتی خود listing بی‌تقصیر است. راه‌حل این نیست که مدل را مستقیم تصحیح کنی، چون ممکن نیست. راه‌حل این است که حقیقت زمینه‌ای را آن‌قدر بی‌ابهام کنی که مدل دلیلی برای تولید نداشته باشد.

چطور میزان مواجهه‌ی خودت را بسنجی

ابزار رایگان MapAtlas AEO Checker یک listing را در مقابل 29 سیگنال ساخت‌یافته ارزیابی می‌کند، شامل مخطط آدرس، وجود مختصات، سازگاری NAP و شناسه‌های خارجی. listingهایی که این تست‌ها را پاس می‌کنند به‌طور ملموس کمتر در جواب‌های AI اشتباه معرفی می‌شوند. listingهایی که رد می‌شوند همان‌هایی‌اند که مدل مجبور به حدس زدن است.

توهم مکانی یک ویژگی خاص یک دستیار نیست. یک پیامد قابل‌پیش‌بینی از آموزش روی یک وب باز است که یک کسب‌وکار در ده‌ها منبع با آدرس‌های کمی متفاوت ظاهر می‌شود. راه‌حل این است که یک حقیقت زمینه‌ای در قالبی که سیستم‌های AI می‌توانند استخراج کنند منتشر کنی و همان حقیقت را در همه‌ی جاهای دیگری که کسب‌وکار بازنمایی می‌شود سازگار نگه داری.

خواندنی‌های مرتبط:

• پرسش‌های متداول مخصوص مکان برای جست‌وجوی AI
• سئو قبلاً کلمه به کلمه بود، حالا دیتابیس به دیتابیس است
• سازگاری NAP در جست‌وجوی AI
• امتیاز دیده‌شدن AI خودت را رایگان بررسی کن