TL;DR: KI-Assistenten erfinden plausibel klingende, aber falsche Adressen, und am stärksten trifft es unabhängige Listings mit dünnem, inkonsistentem Web-Footprint. Die Lösung: 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.
Am höchsten ist das Risiko bei Einrichtungen mit spärlichem oder inkonsistentem Web-Footprint. Eine Ferienunterkunft, die nur auf einer einzigen Buchungsplattform existiert, bietet dem Modell weit weniger Anhaltspunkte als ein Ketten-Hotel, das in Hunderten Quellen mit derselben Adresse gelistet ist.
Ein konkretes Beispiel
Eine beispielhafte Query, mit erfundenem Namen und erfundener Adresse der Unterkunft: "Wie lautet die Adresse des Gästehauses Casa do Vale in Porto?"
Eine typische halluzinierte Antwort:
Casa do Vale befindet sich in der Rua de Santa Catarina 142, 4000-442 Porto, Portugal.
Die korrekte Adresse in diesem Beispiel:
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 bewirken 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?
Eine einzelne verlässliche Quote gibt es nicht. Sie hängt vom Modell, von der Sprache, vom Query-Typ und von der Aktualität der zugrundeliegenden Daten ab. Das Muster ist trotzdem konsistent: Je weniger strukturierte, einheitliche Daten eine Lokalität bereitstellt, desto mehr erfindet das Modell. Ketten-Hotels und bekannte Sehenswürdigkeiten, die in vielen maßgeblichen Quellen mit derselben Adresse auftauchen, werden in der Regel korrekt beantwortet. Am schlechtesten schneiden Long-Tail-Listings ab, etwa unabhängige Ferienunterkünfte, Boutique-Hotels und kleine Restaurants, weil das Modell kaum verifizierte Daten zum Extrahieren findet und die Lücken selbst füllt.
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.
