Warum KI-Assistenten Adressen halluzinieren (und wie geo-verifizierte Daten das Problem lösen)

TL;DR: KI-Assistenten erfinden plausibel klingende, aber falsche Adressen mit Raten zwischen 6 % bei Ketten-Hotels und 38 % bei unabhängigen Ferienunterkünften. Die Lösung besteht nicht darin, das Modell zu korrigieren. Publizieren Sie eine eindeutige Ground Truth mittels Schema.org Place-Markup, verifizierten Koordinaten und einem kanonischen externen Identifier, und halten Sie diese Wahrheit auf jeder Plattform konsistent, auf der der Betrieb auftaucht.

Fragt man ChatGPT nach der Adresse eines Drei-Sterne-Hotels in Porto, wird die Antwort vermutlich aus Straßenname, Hausnummer und Postleitzahl bestehen. Sie wird selbstbewusst klingen. Bei den großen Ketten ist die Antwort meist korrekt. Beim unabhängigen Boutique-Haus zwei Straßen weiter besteht eine nennenswerte Wahrscheinlichkeit, dass die Antwort falsch ist.

Das ist kein seltener Edge Case. Es ist ein vorhersehbarer Output der Art, wie Sprachmodelle Text generieren, und es hat direkte Konsequenzen für jeden, dessen Geschäft davon abhängt, an einem bestimmten Ort auffindbar zu sein.

Die Mechanik einer Lokalitäts-Halluzination

Ein Sprachmodell speichert keine Adressdatenbank. Es speichert eine statistische Verteilung über Tokens. Wenn nach einer Adresse gefragt wird, sagt es eine Tokensequenz voraus, die wie eine Adresse für diesen Einrichtungstyp in dieser Stadt aussieht.

Enthielten die Trainingsdaten die reale Adresse häufig, konsistent und aus autoritativen Quellen, konvergiert die Vorhersage auf den korrekten String. Erschien die Adresse selten, inkonsistent oder gar nicht, interpoliert das Modell. Es wählt eine Straße, die für das Viertel passend klingt, eine Nummer, die zum Block passt, eine Postleitzahl, die dem lokalen Muster entspricht.

Der Output ist grammatikalisch korrekt, geografisch plausibel und oft vollständig falsch.

Stichproben-Audit: Halluzinationsraten nach Query-Typ

Im April 2026 haben wir 500 Lokalitäts-Queries durch drei führende KI-Assistenten geschickt. Jede Query fragte nach der Adresse einer bestimmten Einrichtung. Die Antworten wurden mit der verifizierten Adresse der Einrichtung bei MapAtlas GeoEnrich abgeglichen.

Die folgende Tabelle zeigt den Anteil der Antworten, die mindestens einen materiellen Adressfehler enthielten (falsche Straße, falsche Nummer, falsche Postleitzahl oder falsche Stadt). Die Zahlen sind richtungsweisend und spezifisch für diese Stichprobe.

Query-Typ	ChatGPT	Perplexity	Gemini
Ketten-Hotel	6%	4%	7%
Unabhängiges Boutique-Hotel	19%	14%	22%
Ferienunterkunft	38%	29%	41%
Unabhängiges Restaurant	24%	18%	27%
Wahrzeichen oder Attraktion	9%	5%	8%

Quelle: MapAtlas Stichproben-Audit, April 2026, n=500 Queries.

Zwei Muster stechen heraus. Erstens skaliert die Halluzinationsrate mit der Spärlichkeit und Inkonsistenz des Web-Footprints einer Einrichtung. Ferienunterkünfte, die oft nur auf einer einzigen Listing-Plattform ohne eigene Homepage existieren, leiden am stärksten. Zweitens halluziniert Perplexity konsistent weniger, vermutlich weil seine Retrieval-Schicht mehr Antworten in Live-Quellen verankert statt im parametrischen Speicher.

Ein konkretes Beispiel

Eine im April 2026 gestellte Query: "Wie lautet die Adresse des Gästehauses Casa do Vale in Porto?"

Halluzinierte Antwort eines führenden Assistenten:

Casa do Vale befindet sich in der Rua de Santa Catarina 142, 4000-442 Porto, Portugal.

Verifizierte Antwort aus den Aufzeichnungen der Unterkunft selbst und MapAtlas Geocoding:

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

Falsche Straße, falsche Postleitzahl, falsche Seite der Stadt. Die halluzinierte Antwort setzt den Gast in ein Shopping-Viertel drei Kilometer vom tatsächlichen Gästehaus entfernt ab. Der Fehler ist nicht zufällig. Die Rua de Santa Catarina ist die bekannteste Einkaufsstraße Portos und taucht in Trainingsdaten für Porto-Unterkunftsqueries massiv auf. Das Modell ist auf den stärksten statistischen Prior für die Stadt zurückgefallen.

Warum strukturierte Daten das Ergebnis verändern

Eine Listing-Seite mit einem korrekt aufgebauten Schema.org Place- oder LodgingBusiness-JSON-LD-Block gibt dem Modell etwas, das es extrahieren kann, statt es erfinden zu müssen.

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

Drei Eigenschaften dieses Blocks sind für die Halluzinationsreduktion entscheidend:

Strukturierte Felder. Das Modell muss keinen Satz parsen. Straße, Postleitzahl, Stadt und Land sind separate Keys.
Koordinaten, die zur Adresse passen. Ein Crawler kann verifizieren, dass Latitude und Longitude innerhalb des Postleitzahlen-Polygons liegen. Abweichungen markieren die Daten als niedrig-confidence.
Ein stabiler externer Identifier. Wikidata oder eine Google Place ID verknüpft das Listing mit einer kanonischen Entität. Das Modell kann die Adresse gegen eine autoritative Quelle abgleichen, statt sich auf die Frequenz in den Trainingsdaten zu verlassen.

Wenn diese drei Bedingungen erfüllt sind, ersetzt Extraktion die Generierung. Die Wahrscheinlichkeit einer halluzinierten Antwort sinkt deutlich.

Die NAP-Konsistenzschicht

Schema auf der Listing-Seite ist notwendig, aber nicht hinreichend. KI-Systeme gleichen die Adresse mit weiteren öffentlichen Quellen ab: Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, Buchungsplattformen und dem offenen Web. Stimmen diese nicht überein, sinkt die Confidence, und das Modell neigt eher dazu, sich abzusichern oder zu generieren.

Deshalb ist die Konsistenz von Name, Address, Phone (NAP) über Plattformen hinweg ein stärkerer Prädiktor für Zitationen als jedes einzelne Signal. Ein Listing mit perfekt geformtem Schema, aber einer widersprüchlichen Adresse im Google Business Profile wird trotzdem schlecht performen. Die Mechanik beschreibt NAP-Konsistenz für die KI-Suche.

Was das Halluzinationsrisiko typischerweise senkt

Vier Maßnahmen bewegen in unseren Audits am meisten:

1. Verifizierte Koordinaten zusammen mit der Adresse publizieren. Eine geschriebene Adresse ist ein String. Koordinaten sind ein verifizierbarer Fakt. MapAtlas Geocoding konvertiert Rohadressen in präzise Latitude und Longitude im großen Maßstab und markiert Inputs, die nicht sauber auflösen.

2. Lokalitäts-Fakten in JSON-LD einbetten. Die Typen Place, LodgingBusiness, Hotel, Restaurant und LocalBusiness akzeptieren alle address-, geo- und identifier-Felder. Fehlende Felder sind die Stellen, an denen das Modell beginnt zu raten.

3. Auf einen kanonischen Identifier abgleichen. Das Listing mit einer Wikidata-QID oder Google Place ID verknüpfen. Das gibt KI-Systemen einen Primary Key zum Deduplizieren.

4. Mit Nearby Context anreichern. Halluzinationen beschränken sich nicht auf das Adressfeld. Modelle erfinden auch nahegelegene Wahrzeichen, Haltestellen und Gehzeiten. Verifizierte Proximity-Daten, generiert durch MapAtlas GeoEnrich, verankern auch diese Angaben. Ortsspezifische FAQs sind eine effektive Surface, um diese Daten zu exponieren.

Die geschäftlichen Kosten einer halluzinierten Adresse

Eine falsche, von einem KI-Assistenten ausgegebene Adresse ist nicht nur peinlich für das Modell. Sie schickt einen realen Gast an den falschen Ort. Die Folgewirkungen kumulieren sich:

Eine stornierte Buchung oder, schlimmer, ein No-Show.
Eine negative Bewertung, die die falsche Location nennt und dann in die Trainingsdaten der nächsten Modellgeneration einfließt.
Sinkende Citation Confidence für das Listing in der Zukunft, weil das öffentliche Web nun widersprüchliche Signale enthält.

Die Asymmetrie ist wichtig. Eine halluzinierte Adresse schadet dem Listing auch dann, wenn das Listing selbst unschuldig ist. Die Lösung besteht nicht darin, das Modell direkt zu korrigieren, was nicht möglich ist, sondern darin, die Ground Truth so unmissverständlich zu publizieren, dass das Modell keinen Grund hat, überhaupt zu generieren.

So prüfen Sie Ihre eigene Exposition

Der kostenlose MapAtlas AEO Checker bewertet ein Listing anhand von 29 strukturierten Signalen, darunter Adress-Schema, Präsenz von Koordinaten, NAP-Konsistenz und externe Identifier. Listings, die diese Checks bestehen, werden signifikant seltener in KI-Antworten falsch dargestellt. Listings, die durchfallen, sind genau jene, bei denen das Modell raten muss.

Lokalitäts-Halluzinationen sind keine Marotte eines einzelnen Assistenten. Sie sind eine vorhersehbare Konsequenz des Trainings auf einem offenen Web, in dem derselbe Betrieb mit leicht unterschiedlichen Adressen auf Dutzenden von Quellen erscheint. Die Lösung besteht darin, eine Ground Truth in einem Format zu publizieren, das KI-Systeme extrahieren können, und diese Ground Truth überall dort konsistent zu halten, wo der Betrieb repräsentiert ist.

Weiterführende Artikel:

Häufig gestellte Fragen

Was ist eine KI-Adress-Halluzination?

Eine KI-Adress-Halluzination liegt vor, wenn ein Large Language Model eine konkrete Straßenadresse, Postleitzahl oder Koordinate zurückgibt, die plausibel wirkt, aber nicht dem tatsächlichen Standort des beschriebenen Betriebs, Wahrzeichens oder Objekts entspricht. Es handelt sich nicht um einen geringfügigen Rundungsfehler. Das Modell hat eine Adresse synthetisiert, die nicht existiert, zu einer anderen Einrichtung gehört oder eine reale Straße mit der falschen Stadt kombiniert. Für Listings ist das besonders schädlich, weil der Nutzer möglicherweise zum falschen Ort reist, bevor ihm auffällt, dass die Antwort frei erfunden war.

Warum halluzinieren KI-Assistenten Adressen?

Sprachmodelle generieren Text, indem sie den wahrscheinlichsten nächsten Token vorhersagen, nicht indem sie Fakten nachschlagen. Wenn eine Adresse unterrepräsentiert ist, im Web inkonsistent erscheint oder vom Crawling ausgeschlossen wurde, füllt das Modell die Lücke mit einem statistisch plausiblen String: einem Straßennamen, der für die Stadt passend klingt, einem Postleitzahlenmuster, das zur Region passt, einer Hausnummer, die typisch wirkt. Ohne eine strukturierte Ground-Truth-Quelle als Anker hat das Modell keinen Mechanismus, um einen memorisierten Fakt von einem generierten zu unterscheiden.

Wie häufig treten Lokalitäts-Halluzinationen in der Praxis auf?

In einem Stichproben-Audit von MapAtlas im April 2026 über 500 Lokalitäts-Queries für Hotels, Ferienunterkünfte, Restaurants und Sehenswürdigkeiten lagen die Halluzinationsraten auf Adressebene zwischen rund 6 % für bekannte Ketten-Hotels und 38 % für unabhängige Ferienunterkünfte. Generische Wahrzeichen-Queries schnitten am besten ab, Long-Tail-Listing-Queries am schlechtesten. Die Rate ist richtungsweisend und variiert je nach Modell, Sprache und Aktualität der zugrundeliegenden Daten, doch das Muster ist konsistent: Je weniger strukturierte Daten eine Lokalität exponiert, desto mehr erfindet das Modell.

Reduzieren Schema.org-Strukturdaten Halluzinationen?

Ja, sofern die Daten verifiziert und quellenübergreifend konsistent sind. Ein Place- oder LodgingBusiness-JSON-LD-Block mit korrekten geo-Koordinaten, einer validierten Postadresse und Querverweisen auf autoritative Identifier wie Wikidata oder Google Place ID liefert dem Modell einen Ground-Truth-Anker, den es extrahieren und zitieren kann. Inkonsistentes Schema, etwa Koordinaten, die nicht mit der Textadresse übereinstimmen, senkt die Confidence eher, als dass es sie erhöht.

Wie prüfe ich meine Listings auf Halluzinationsrisiko?

Die Listing-URL durch den kostenlosen MapAtlas AEO Checker unter mapatlas.eu/ai-seo-checker laufen lassen. Der Checker bewertet 29 strukturierte Signale, die KI-Systeme zur Verankerung von Lokalitäts-Fakten nutzen, darunter geo-Koordinaten, Place-Schema, NAP-Konsistenz über Plattformen hinweg und das Vorhandensein von Nearby-Context-Feldern. Seiten, denen diese Signale fehlen, erreichen einen hohen Halluzinations-Risikowert, weil das Modell raten statt extrahieren muss.