KI-Wegfindungsassistent für Veranstaltungsorte

Ein KI-Wegfindungsassistent interpretiert Navigationsanfragen in natürlicher Sprache, ermittelt das Ziel anhand vertrauenswürdiger Veranstaltungsdaten und koordiniert Karten- oder Routenführung, ohne Suche, Routenplanung und Positionierung als eine einzige Funktion zu behandeln. Besucher können beispielsweise fragen, welchen Eingang sie benutzen sollen, wie sie Halle B erreichen oder wo sich die nächste barrierefreie Toilette befindet. Das Sprachmodell kann diese Felder als überprüfbare Absicht erfassen. Das Veranstaltungssystem, die Routing-Engine und jegliche Positionierungsinfrastruktur bleiben maßgeblich für Geometrie, Konnektivität, Zugang und Live-Standort.

Die folgenden Abschnitte behandeln Zielauflösung, Indoor-Konnektivität, Zugänglichkeit und Zugriffsfilter, Ursprungsquellen, den Status der gemeinsamen Wegfindung, die aktuelle öffentliche Eignung von Kaleidr, Messung und Fehlermodi. Weiterführende Informationen finden Sie unter anderem in KI-Veranstaltungskarte für Events, Wie man einen kartenbasierten KI-Assistenten entwickelt, Standortintelligenz-basierte Kundenerlebniskarten, KI-Gästeconcierge für Hotels und Private Standortdaten für KI-Karten-Workflows.

Grundlagen der KI-gestützten Wegfindung

• Zielfindung ist nicht gleich Routing: Die Ermittlung von Halle B ist nicht dasselbe wie die Berechnung eines zusammenhängenden Pfades dorthin.
• Routing ist nicht gleich Positionsbestimmung: Eine gültige Route kann existieren, bevor das System den Standort des Besuchers kennt.
• Ein Grundriss ist kein Netzwerk: Für die Indoor-Navigation ist die Topologie von Räumen, Türen, Fluren und Übergängen zwischen Etagen erforderlich.
• Barrierefreiheit und Zugang sind harte Filter: Treppen, Personalflure und geschlossene Kanten müssen aus dem Graphen entfernt werden und dürfen nicht nur eine niedrigere Punktzahl erreichen.
• Das Sprachmodell interpretiert die Absicht: Geodaten- und Veranstaltungs-Systeme berechnen Routen; der Host validiert die Kartenaktionen.

Was ist ein KI-gestützter Wegfindungsassistent?

Ein KI-gestützter Wegweiser ist eine kundenorientierte Ebene, die mithilfe von Konversation, Kartenkontext und verlässlichen Standortdaten beantwortet, wohin eine Person in einem komplexen Umfeld gehen und wie sie dorthin gelangen soll. Eine herkömmliche Suche liefert lediglich einen Raumnamen. Ein statisches Poster zeigt eine Zeichnung des Gebäudes. Beides erfasst jedoch nicht Startpunkt, Etage, Ticketberechtigung, Barrierefreiheit, aktuelle Schließungen und die aktuell angezeigte Route als einen einzigen, überprüfbaren Zustand. Konferenzzentren, Universitätsgelände, Krankenhäuser, Flughäfen, Resorts und Einkaufszentren erzeugen diese komplexe Anfrage alle paar Minuten. Das nützliche Produkt hält Ziel, Route und Etage auf der Karte sichtbar, anstatt den Besucher diese Informationen anhand von Beschilderungen, PDFs und einem Chatfenster, das die Kamera nicht bewegen kann, rekonstruieren zu lassen.

Die Seite „Spatial AI“ von Kaleidr listet die Navigation unter den Kartenfunktionen auf und beschreibt Routen, die zum Reiseverhalten eines Nutzers passen (AI Map Chat for Customer Discovery). Diese Seite ist maßgeblich für die Positionierung der Outdoor- und reiseorientierten Navigation von Kaleidr. Die Navigation in Innenräumen erfordert eine andere Vorgehensweise: Zielinformationen, ein routingfähiges Netzwerk und, sofern die Infrastruktur dies zulässt, ein Positionierungssystem. Kundenorientierte Standortinformationen nutzen weiterhin den Prozess „Erkennen → Vergleichen → Handeln“.„Erkennen“ ermittelt ein geeignetes Ziel.„Vergleichen“ ermöglicht die Überprüfung von Etage, Reiseverlauf, Barrierefreiheit und Zugangsberechtigungen.„Handeln“ markiert ein Ziel, wechselt die Etage, fordert eine Route an (sofern Routing vorhanden ist) oder übergibt den Standort an einen Mitarbeiter.

Die Aufgabenstellung sollte vor dem Stack definiert werden. Ein Besucher benötigt möglicherweise den Eingang, der seinem Sitzplatz am nächsten liegt. Ein Konferenzteilnehmer benötigt eventuell einen Weg vom aktuellen Saal zur nächsten Session. Ein Flughafenpassagier benötigt möglicherweise eine geeignete Lounge in der Nähe eines Gates. Ein Campusnutzer benötigt möglicherweise den Gebäudeeingang, der seinem Hörsaal am nächsten liegt. Ein Krankenhausbesucher benötigt möglicherweise Bildmaterial vom Haupteingang. Jede Aufgabe verändert die Kandidaten, die harten Randbedingungen, die vertikalen Übergänge und die Frage, ob eine Live-Positionsbestimmung erforderlich ist. Wenn man mit „KI-Navigation in Innenräumen“ beginnt, werden diese Unterschiede verwischt, was zu der Behauptung führen kann, dass das Produkt die Anforderungen des Veranstaltungsortes nicht erfüllt.

Warum müssen Discovery, Routing und Positioning getrennt bleiben?

Die Zielerkennung klärt, welcher Ort relevant ist. Die Routenberechnung ermittelt, welchen zusammenhängenden Weg ein berechtigter Besucher nutzen kann. Das Positioning ermittelt, wo sich der Besucher gerade befindet, auf welcher Etage und, falls die Hardware es unterstützt, in welche Richtung er blickt. Die drei Ebenen können zusammenarbeiten. Keine ersetzt die anderen. Ein Grundriss kann Raum 204 zeigen, aber dennoch die Korridorverbindungen, offene Türen, barrierefreie Übergänge, einen Aufzug zur Zieletage und einen verlässlichen Startpunkt vermissen lassen. Eine detaillierte Wegbeschreibung, wie z. B. „In zehn Metern links abbiegen“, benötigt sowohl eine Route als auch eine aktuelle Position mit ausreichender Genauigkeit und Orientierung. Das Sprachmodell kann die Anfrage koordinieren. Es kann jedoch keine fehlende Topologie oder einen blauen Punkt liefern.

Das konzeptionelle Modell Open Geospatial Consortium 2.0 Teil 1 ist das aktuelle konzeptionelle Schema OGC für Indoor-Navigationsnetzwerke. Der Standard modelliert Räume und Raumunterteilungen, geometrische und semantische Eigenschaften, Verbindungsarten sowie logische und metrische Navigationsnetzwerke (OGC IndoorGML 2.0 Part 1 – Conceptual Model, OGC 22-045r5, veröffentlicht am 26. Juni 2025). Ein Produkt muss IndoorGML nicht serialisieren. Es muss jedoch dieselbe Unterscheidung beachten: Visuelle Geometrie ist kein Navigationsgraph. In der Veröffentlichungsmitteilung vom 28. August 2025 von OGC wurden die Kodierungen von IndoorGML 2.0 Teil 2 als in Kürze verfügbar angekündigt (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard). IndoorGML 1.1 bleibt ein veröffentlichter, kodierungsorientierter IndoorGML-Standard (IndoorGML 1.1, OGC 19-011r4, 5. November 2020). Für den konzeptionellen Vertrag ist Teil 1 heranzuziehen; eine GML-, JSON- oder SQL-Kodierung von IndoorGML 2.0 gilt erst dann als veröffentlichter Implementierungsstandard, wenn Teil 2 als solcher vorliegt.

Das Indoor Mapping Data Format (IMDF) ist ein ergänzender Community-Standard OGC für Indoor-Standortarchive, die für Orientierung, Navigation und Erkundung genutzt werden. Es enthält auch Modellierungshinweise für Flughäfen, Einkaufszentren und Bahnhöfe (Indoor Mapping Data Format, OGC 20-094, Version 1.0.0, veröffentlicht am 18. Februar 2021). IndoorGML 2.0 Teil 1 beschreibt IMDF als umfassendes Modell, aus dem Anwendungen Wege ableiten können, während IndoorGML einen einheitlichen Raumgraphen-Ansatz verfolgt. Für einen KI-gestützten Wegfindungsassistenten ist die praktische Schlussfolgerung konkreter: Strukturierte Indoor-Daten müssen vorhanden sein, bevor die Konversation eine Navigation verspricht.

Die Wegfindung im Freien ist oft einfacher, da Straßen- oder Fußwegenetze, Routing-APIs und GNSS bereits existieren. Der Assistent kann dann ein Ziel geokodieren, eine Route von einem Anbieter anfordern und das Ergebnis darstellen. Indoor- und Hybrid-Campus-Routen benötigen in der Regel zusätzliche Infrastruktur: Etagenstatus, vertikale Übergänge, zugangskontrollierte Kanten und einen Ursprung, der nicht vom Browser stammen muss. Ein Campus-Pfad kann beispielsweise einen Abschnitt im Außenbereich GNSS mit einem Gebäudeeingang und anschließend mit einem Indoor-Graph verbinden. Die Dialogschicht kann den Übergang erklären. Die Routen-Engines sind weiterhin für jeden Abschnitt verantwortlich.

Wie sollte die Zielauflösung vor dem Routing funktionieren?

Das Routing zur Zeichenkette „Halle B“ ist ein Produktfehler. Die Anwendung sollte eine stabile Ziel-ID, ein Gebäude und eine Etage ermitteln, bevor die Routen-Engine ausgeführt wird. Anzeigenamen kollidieren: Tor 12 und Eingang 12 sind unterschiedliche Entitäten. Raum-, Kabinen- und Sitzungs-IDs kollidieren in der menschlichen Sprache aus demselben Grund, aus dem die KI-Veranstaltungskarte die Geometrie von der Ereignisdarstellung trennt. Typisierte Datensätze für Gebäude, Etagen, Eingänge, Räume, Tore, Kabinen, Toiletten, Aufzüge, Treppen, Parkzonen und Service-Desks sorgen dafür, dass Suche, Karte, Routen, Barrierefreiheit und Analysen bei Änderungen der Bezeichnungen synchronisiert bleiben.

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

Die Berechtigungsprüfung gehört zum selben Schritt. Eine physisch verbundene Lounge kann weiterhin durch Ticketklasse, Sicherheitszone oder die Kennzeichnung „Nur für Mitarbeiter“ gesperrt sein. Kandidatenbereiche sollten vor räumlichem Vergleich und Erläuterung auf Autorisierung und Betriebsstatus geprüft werden. Eingeschränkte Bereiche sollten vor dem Abruf gefiltert werden, damit das Sprachmodell sich nicht merken muss, welche Korridore privat sind. OWASP’s LLM01:2025 Prompt Injection beschreibt, wie Benutzer- oder abgerufener Text das Modellverhalten beeinflussen kann, einschließlich des Einflusses auf verbundene Funktionen. OWASP Top 10 for LLM Applications 2025 listet LLM06:2025 Excessive Agency auf: schädliche Aktionen durch unerwartete oder manipulierte Modellausgabe, wenn einem System zu viel Funktionalität, Berechtigung oder Autonomie gewährt wird. Ein Wegweiser sollte ein Ziel und eine zulässige Aktion vorschlagen. Die Host-Anwendung sollte die Kamerabewegung, den Etagenwechsel oder die Routenanfrage nach Schema-, Zugriffs- und Netzwerkstatusvalidierung ausführen.

Mehrdeutigkeit ist ein erwünschtes Ergebnis.„Haupteingang“, „Nordeingang“ und „VIP-Eingang“ können allesamt gültige Analysen sein. Das Produkt sollte nach den eingegebenen Kandidaten fragen, diese auf der Karte anzeigen oder eine Eingabe per Fingertipp erfordern, anstatt anhand der Ähnlichkeit der Zeichenkette zu raten. Die direkte Zielsuche muss auch dann funktionieren, wenn die Konversation fehlschlägt. Ein Besucher, der Hall B eingibt, sollte keinen Dialog benötigen. Deterministische Suche, Filter, Karte und Konversation für komplexe Fragen sollten dieselben Kennungen verwenden.

Warum benötigt die Indoor-Routenplanung Konnektivität und keinen Grundriss?

Die Ortssuche hebt eine Geometrie hervor. Die Indoor-Routenplanung berechnet die Route über einen zusammenhängenden Graphen: Raum → Flur → Tür → Treppe oder Aufzug → anderes Stockwerk. Anzeigepolygone und Routing-Knoten können bewusst getrennt sein. Ein Raumpolygon kann an einen Türknoten angehängt werden; Flurkanten repräsentieren die Wege; Aufzugs- und Treppenkanten repräsentieren Stockwerkswechsel, Barrierefreiheit und Betriebsstatus. Ein Rastergrundriss mit einer dekorativen Polylinie ist nicht dieser Graph. Die Ortsplan-Anleitung zieht dieselbe Grenze zwischen der Anzeige eines Raumes und der Angabe eines detaillierten Routenverlaufs.

Der Status „mehrgeschossig“ muss explizit angegeben werden. Start- und Zielpunkt sollten Gebäude- und Etagenkennungen enthalten. Die Benutzeroberfläche sollte Etagenwechsel anzeigen, anstatt den Übergang in einer einzelnen 2D-Linie zu verbergen. Vertikale Kanten benötigen typisierte Attribute: Treppen, Aufzüge, Rolltreppen, Rampen, Barrierefreiheit, bediente Etagen und Status (geöffnet/geschlossen). Die Routenberechnungs-Engine verwendet diese Attribute. Das Sprachmodell kann sie erläutern, nachdem die Engine strukturierte Schritte zurückgegeben hat. Der bevorzugte Ablauf ist: Routenberechnungs-Engine, strukturierte Schritte, verständlichere Beschreibung – keine freie Formulierung von Wegbeschreibungen. Orientierungspunktebezogene Anweisungen wie „Gehen Sie weiter in Richtung der zentralen Lobby und benutzen Sie dann den östlichen Aufzug“ bleiben auch dann nutzbar, wenn keine Kompassrichtung angegeben werden kann.

Temporäre Schließungen sind Betriebsaufzeichnungen, keine kartografische Darstellung. Ein Rolltreppenausfall, ein blockierter Flur, ein geschlossener Eingang, eine gesperrte Etage oder ein Aufzugsausfall sollten eine Kante als geschlossen markieren und eine Neuberechnung erzwingen. Die Beschreibung, die der Besucher liest, sollte die aktuelle Routenversion widerspiegeln. Veraltete Geometrie in gesprochener Sprache ist in realen Veranstaltungsorten ein Sicherheitsrisiko, kein Kopierproblem. Die Routenneuberechnung obliegt der Engine: Ändert sich der Ausgangspunkt oder schließt sich eine Kante, wird die vorherige Route ungültig und eine neue berechnet. Die Koordinatenkorrektur durch das Sprachmodell ist der falsche Ansatz.

Wie filtern Barrierefreiheit, Zugriffsregeln und Schließungen Routen?

Erforderliche Barrierefreiheit ist eine harte Routenbeschränkung. Fragt der Besucher nach einer barrierefreien Route, können Treppenkanten ausgeschlossen werden. Ein vollständig barrierefreier Weg kann Stufenfreiheit, einen funktionierenden Aufzug, einen barrierefreien Eingang und eine vom Veranstaltungsort erfasste Türbreite erfordern. Die Einbeziehung von Barrierefreiheit in eine weiche Gewichtung kann dazu führen, dass ein nicht barrierefreier Weg immer noch an erster Stelle steht. Fehlende Barrierefreiheitsdaten sind keine Berechtigung, eine vollständig barrierefreie Route zu erfinden. Wenn das System lediglich einen barrierefreien Eingang und einen Aufzug kennt, bedeutet die korrekte Aussage, dass diese Merkmale auf der Karte angezeigt werden, nicht aber, dass ein vollständig barrierefreier Weg zertifiziert wurde. Die rechtlichen Verpflichtungen zur Barrierefreiheit bleiben eine Ermessensfrage für qualifizierte Rechtsberater und den Betreiber des Veranstaltungsortes; dieser Beitrag beschreibt den Datenvertrag.

Die physische Konnektivität ist nur ein Kriterium für die Zutrittsberechtigung. Mitarbeiterkorridore, VIP-Eingänge, Sicherheitszonen, Ticketbereiche und Mitarbeitereingänge können im Graphen zwar begehbar sein, aber dennoch für diesen Besucher gesperrt sein. Die Zutrittsberechtigung einer Route ergibt sich aus physischer Konnektivität, Zugriffsberechtigung und Betriebsstatus. Eingeschränkte Pfade dürfen die Konversationsebene erst erreichen, nachdem die Zugriffskontrolle angewendet wurde. Die sichere Vorgehensweise ist: Authentifizierung, Zugriffsprüfung, Abruf der zulässigen Bereiche, Berechnung einer zulässigen Route und anschließende Erläuterung. Die Berechnung eines Pfades durch alle Bereiche und das anschließende Ausblenden eingeschränkter Schritte führt zu einem Offenlegungsfehler in der Topologie. Map-API-Authentifizierung regelt die Verwendung von öffentlich zugänglichen Schlüsseln im Vergleich zu Serverschlüsseln für die Kaleidr Oberflächen, die die Konversation mit einer Host-Karte verknüpfen; die Zugangsregeln für den Veranstaltungsort bleiben in den Identitäts- und Ticketsystemen des Hosts gespeichert.

Notfall- und Sicherheitsrouting ist von höchster Wichtigkeit. Ein generativer Assistent sollte keine Evakuierungswege, Notfallmaßnahmen oder eingeschränkte Sicherheitshinweise auf Basis generischer Modellinformationen erstellen. Verwenden Sie stattdessen vom Veranstaltungsort genehmigte Notfallinhalte, offizielle Pläne, Informationen von Mitarbeitern und betriebliche Warnmeldungen. Ein Wegeleitsystem kann genehmigte Erste-Hilfe- oder Notausgangspunkte anzeigen, sofern diese Informationen verlässlich sind. Die Routenführung in kritischen Situationen gehört zum dafür vorgesehenen Betriebssystem.

Wann benötigt die Wegeführung eine Positionsbestimmung und wann nicht?

Jede Route benötigt einen Ausgangspunkt. Dieser kann durch eine explizite Kartenauswahl, ein bekanntes Orientierungsmerkmal wie den Haupteingang, den zuletzt angegebenen Bereich („Ich bin in Halle A“), den Standort eines Außengeräts oder die Indoor-Positionierungsinfrastruktur bestimmt werden. Die manuelle Ausgangspunktbestimmung muss auch bei vorhandener automatischer Positionsbestimmung möglich bleiben. Zuverlässigkeit basiert auf Daten. Ein auf wenige Meter genauer Positionsbericht kann die Navigation im Korridorbereich unterstützen. Ein Bericht mit einer Unsicherheit von mehreren zehn Metern im Innenbereich kann zur Auswahl des falschen Korridors oder der falschen Etage führen. Das System sollte in der Lage sein, auf die Unsicherheit des Standorts im Innenbereich hinzuweisen und den Besucher aufzufordern, den aktuellen Bereich auszuwählen. Eine zuverlässige Routenführung von einem ungenauen Ausgangspunkt aus ist schlechter als eine kurze Erläuterung.

Die Spezifikation W3C Geolocation, ein Candidate Recommendation Snapshot vom 26. März 2026, gewährt Zugriff auf den Gerätestandort nur nach ausdrücklicher Genehmigung und stellt fest, dass die API keine Garantie für den tatsächlichen Standort des Geräts übernimmt. Eine Standortbestimmung durch den Browser ist kein blauer Punkt in Innenräumen. Bluetooth Beacons, Wi-Fi Positionsbestimmung, ultra-wideband, visuelle Positionsbestimmung und standortspezifische Systeme sind Infrastruktur und kein Merkmal des Sprachmodells. Die Orientierung ist eine weitere Voraussetzung für Anweisungen wie „Links abbiegen“. Eine Karte kann auch ohne Richtungsangabe eine korrekte Route anzeigen. Wenn keine Richtungsangabe verfügbar ist, sollten Kompassangaben durch markante oder kartenbezogene Formulierungen ersetzt werden.

Viele Veranstaltungsorte können eine nützliche Wegweisung ohne kontinuierliche Indoor-Ortung bereitstellen. Der Besucher wählt ein markantes Merkmal aus, die Engine berechnet eine Route, die einzelnen Schritte bleiben auf der Karte sichtbar, und der Besucher bewegt sich manuell weiter. Konferenzen, Universitätsgelände, Resorts und Museen benötigen dieses Muster oft dringender als einen einzelnen blauen Punkt. Das Muster reduziert zudem Datenschutzrisiken und Infrastrukturkosten. Wegeleitsysteme können eine detaillierte Bewegungshistorie erstellen: aktueller Standort in Innenräumen, Route, wiederholte Ziele, Arbeitsplatz, medizinische Abteilung oder besuchte Veranstaltungen. Die NIST Privacy Framework (NIST.CSWP.01162020, 16. Januar 2020) behandelt Datenschutz als Risikomanagement für Unternehmen: Es muss festgelegt werden, welche Daten erfasst werden, warum und wie lange. Temporäre Start-, Ziel- und Routenkontexte sind einem permanenten Bewegungsprofil vorzuziehen. Private Standortdaten für KI-Karten-Workflows decken denselben vom Betreiber festgelegten Bereich ab.

Wie sollte die dialogbasierte Wegeleitung den Status mit der Karte teilen?

Die Konversation wird erst dann sinnvoll, wenn ein Ziel oder eine Route bereits auf der Karte angezeigt wird. Folgeanfragen wie die Suche nach einer Toilette entlang des aktuellen Weges, die Bitte, Treppen zu vermeiden, oder ein näher gelegener Eingang vom gewählten Startpunkt basieren auf einem gemeinsamen Status und nicht auf einer zweiten, inoffiziellen Ergebnisliste. Karte, Liste, Anweisungen und Chat sollten einen einzigen Wegfindungsdatensatz verwenden: Startpunkt, Ziel, aktive Etage, Routenkennung, Routenversion, Barrierefreiheitsmodus und Positionsgenauigkeit (sofern ein Ortungssystem vorhanden ist). Die Auswahl eines Ziels kann eine Route anzeigen. Die Änderung des Barrierefreiheitsmodus kann die aktuelle Version ungültig machen und eine Neuberechnung anfordern. Die Ergebnisse des Assistenten sollten auf derselben Karte angezeigt werden, die der Besucher bereits verwendet.

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

Semantische Aktionen sollten kurz und prägnant sein: Startpunkt festlegen, Ziel fokussieren, Route anzeigen, Etage wechseln, Übergang hervorheben, Zieldatensatz öffnen, Route löschen, Umleitung anfordern. Der Host validiert jede Nutzlast anhand aktueller Kennungen, Zugriffsrechte und Netzwerkversion, bevor der Renderer-Adapter ausgeführt wird. Eine beliebige Karte JavaScript ist kein Kontrollvertrag. Berechtigungen für diese Aktionen gehören der Anwendung und Infrastruktur, niemals dem Sprachmodell. Die Kartenbasierte Assistentenanleitung beschreibt den gemeinsamen Kartenstatus und die validierten Aktionen für diese Übergabe.

Betriebliche Aktualisierungen sollten sowohl das Netzwerk als auch die Route versionieren. Eine Aufzugssperrung kann die Routenversion 4 in Netzwerkversion 18 ungültig machen und Version 5 erforderlich machen. Die Versionierung ermöglicht die Fehlersuche bei veralteten Routen. Die Validierung vor der Anwendung einer Route sollte bestätigen, dass Ursprung, Ziel, Berechtigung, Aktualität der Route, Sperrungen und Reisemodus weiterhin übereinstimmen. Der Status der Wegfindung ändert sich in belebten Umgebungen schnell. Offline- oder schwache Verbindungen sind in Innenräumen ebenfalls normal. Speichern Sie gegebenenfalls die Geometrie des Veranstaltungsortes, Beschriftungen, das letzte Stockwerk und eine letzte funktionierende Route im Cache. Die direkte Ortssuche muss auch bei einem Ausfall der Dialogschicht funktionieren. KPIs des Dashboards für räumliche Analysen dienen der Produktmessung und nicht der Erfolgsmessung anhand des Chatvolumens.

Wie passt Kaleidr in eine bestehende Wegeleit-Architektur?

Die aktuelle Entwicklerdokumentation von Kaleidr beschreibt Chat als Dialogschicht, die an eine bereits auf dem Host ausgeführte Karte angehängt ist. Quickstart zeigt die Einbindung von Chat in eine Live-Instanz von Mapbox, MapLibre, Google Maps oder Leaflet. Chat attach beschreibt den Control Tower als Chat-gesteuerte Navigation, Ortsübersichten und Ortsmarkierungen auf dieser Host-Karte. Veröffentlichbare Schlüssel sind für den Browser ursprungsgebunden; Serverschlüssel bleiben außerhalb der Seite (Auth & Scopes). Code-Snippets sollten einen eindeutigen Platzhalter anstelle eines Live-Schlüssels verwenden.

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

Diese Oberflächen unterstützen die Suche nach Zielen in natürlicher Sprache, kartenbasierte Konversation, Ortsangaben, Live-Markierungen und Kamera-Updates. Der Host behält die Kontrolle über Renderer, Veranstaltungsortdaten, Routenplanung, Indoor-Topologie, Positionierung und Zugangskontrolle. Die öffentliche Dokumentation von Kaleidr beschreibt KI-gestützten Kartenchat, veröffentlichte Karten, entworfene Basiskarten und Kartenbearbeitung. Diese Dokumentation beschreibt derzeit weder eine dedizierte Indoor-Positionierungs-Engine noch ein spezialisiertes Indoor-Navigationsprodukt mit Abbiegehinweisen. Eine korrekte Architektur sieht daher dialogbasierte und kartenbasierte Interaktion auf Kaleidr vor, wobei spezialisierte Indoor-Routenplanung oder -Positionierung im Veranstaltungsort- oder Navigationssystem verbleiben, wenn die Bereitstellung diese erfordert. Location Intelligence APIs and Map SDK ist die aktuelle kommerzielle Oberfläche für Inferenz-APIs, Ranking-Systeme, Analysen und Bereitstellungsunterstützung. Ranking und Indoor-Routenplanung sind weiterhin separate Produkte; kodieren Sie keine fiktive Indoor-Navigationsroute aus Marketing-Sprache.

Hybride Orte passen weiterhin in diese Aufteilung. Für Streckenabschnitte im Freien kann ein Routing-Anbieter verwendet werden. Für die Navigation in Innenräumen kann ein Veranstaltungsdiagramm verwendet werden. Event-Overlays ermöglichen den Wechsel von Ständen und Sessions, ohne dass Wände neu gebaut werden müssen, wie im Artikel zur Veranstaltungskarte beschrieben. Anfragen an Krankenhäuser und Flughäfen scheitern oft zuerst an der Zielidentität und dem Zugang, nicht an der Wegfindung: „Bildgebung“ und „die Lounge, die ich in der Nähe von Gate 42 nutzen möchte“ sind zunächst Berechtigungsprobleme, bevor sie geometrische Probleme darstellen. Das Sprachmodell kann die Anfrage interpretieren. Autorisierte Geschäftsdaten und Geodienste liefern weiterhin die Fakten.

Wie sollten Teams einen KI-gestützten Wegweiser messen?

Messen Sie die Leistung des Wegeleitsystems, nicht das Chatvolumen. Zielauflösungsrate, Rate ohne Ergebnis, Routenerfolg, Korrekturen falscher Etagen, Umleitungsrate, Zugriffsverweigerungen, Zeit bis zur Rückkehr zur Route, Zielbestätigung und Routenabbruch beschreiben, ob Besucher ihr Ziel erreichen. Falls Positionsdaten vorhanden sind, ergänzen Sie diese um Ereignisse wie Abweichungen von der Route, Fehler bei der Standortbestimmung und Fehler bei der Etagenerkennung. Trennen Sie die Suche von der Navigation: Ein aufgelöstes Ziel mit einer fehlgeschlagenen Route ist ein anderer Fehler als eine fehlgeschlagene Suche. Redaktionelle Ereignisnamen wie „Ziel aufgelöst“, „Route angefordert“, „Route fehlgeschlagen“, „Etage geändert“ und „Umleitung“ sind Produktanalysen und keine dokumentierten automatischen Ereignisse Kaleidr Analytics.

Die Bewertung sollte Mehrdeutigkeiten, Wege zwischen Etagen, geschlossene Verbindungen, eingeschränkten Zugriff, fehlende Barrierefreiheitsdaten und Ausweichmöglichkeiten bei geringer Konnektivität berücksichtigen. Testen Sie, ob Karte, Liste und gesprochene oder geschriebene Schritte dieselbe Routenversion anzeigen. Die Latenz sollte pro Phase erfasst werden; Teams, die die „KI“ verantwortlich machen, stellen oft fest, dass die Routenführung oder die Ursprungsauflösung die Hauptursache ist. Die Aufgabenerfüllung ist wichtiger als die Anzahl der Interaktionen. Ein Besucher, der Halle B per Suche ohne Chat findet, hat Erfolg. Ein längeres Gespräch, das im falschen Stockwerk endet, hingegen nicht.

Welche Fehler sollten Wegeleitsysteme vermeiden?

Der wiederkehrende Fehler besteht darin, drei Systeme in einem generierten Absatz zu verschmelzen. Ein Grundrissbild wird als Router behandelt. Das Sprachmodell wird als Positionierungssystem verwendet. Stockwerke verschwinden. Barrierefreiheit wird zu einer Gewichtung. Eingeschränkte Bereiche werden undicht. Wegbeschreibungen erscheinen ohne Orientierung. Gespräche werden obligatorisch. Der Bewegungsverlauf wird standardmäßig gespeichert. Jede Zeile unten beschreibt einen Produktfehler mit einer konkreten Korrektur.

Mobile Navigation benötigt große Ziele, gut lesbare Schritte und eine Karte, die auch bei Timeout des Modells oder einer aufwändigen Route nutzbar bleibt. Basisgeometrie zwischenspeichern. Anreicherung kontrolliert reduzieren. Pfad aus der Textsuche zur Hervorhebung beibehalten, auch wenn kein Chat verfügbar ist.

Konversationelle Navigation entwickeln

Die zuverlässige Architektur umfasst Absicht, Zielauflösung, autorisiertes Routing, Routenberechnung, Erklärung und eine validierte Kartenaktion. Die Indoor-Positionierung ist eine optionale, spätere Ebene, die nur hinzugefügt wird, wenn der Veranstaltungsort über ein geeignetes System verfügt. Kaleidr kann dialogbasierte räumliche KI in die bereits vorhandene Karte eines Hosts integrieren, während die Topologie des Veranstaltungsortes und spezialisierte Router weiterhin maßgeblich sind, wenn eine echte Indoor-Navigation erforderlich ist.

Kaleidr Enterprise entdecken – für aktuelle APIs, SDK-Oberflächen und Bereitstellungsunterstützung. Prüfen Sie vor der Umsetzung eines Integrationspfads die Anbindungsmuster und Schlüsseltypen in der Kaleidr-Entwicklerdokumentation.

FAQs

Was ist ein KI-Wegfindungsassistent?

Ein KI-Wegfindungsassistent interpretiert Navigationsfragen in natürlicher Sprache, ermittelt das gewünschte Ziel anhand vertrauenswürdiger Datensätze und koordiniert die Karten- oder Routenführung. Routing und Positionierung bleiben separate Systeme.

Ist KI-Wegfindung dasselbe wie Indoor-Navigation?

Nein. Dialog kann eine Navigationsanfrage interpretieren. Indoor-Navigation erfordert zusätzlich ein strukturiertes Routing-Netzwerk und gegebenenfalls eine Indoor-Positionierung.

Kann ein Grundrissbild für die Routenführung verwendet werden?

Nicht allein. Eine zuverlässige Routenführung erfordert die Vernetzung von Räumen, Türen, Fluren, Treppen, Aufzügen und anderen Übergängen.

Was ist IndoorGML?

IndoorGML ist ein OGC-Standard für räumliche Daten und Navigationsdaten in Innenräumen. IndoorGML 2.0 Teil 1 ist das aktuelle konzeptionelle Modell für Räume, Konnektivität und Navigationsnetzwerke (OGC 22-045r5). OGC kündigte die Kodierungsschemata für IndoorGML 2.0 ab August 2025 an; IndoorGML 1.1 ist weiterhin eine veröffentlichte, kodierungsorientierte Version.

Was ist IMDF?

Das Indoor Mapping Data Format ist ein OGC-Community-Standard (OGC 20-094, Version 1.0.0) für Archivdaten von Innenräumen, die zur Orientierung, Navigation und zum Auffinden von Orten verwendet werden.

Bietet Kaleidr derzeit Indoor-Positionierung?

Die aktuelle öffentliche Dokumentation von Kaleidr beschreibt räumliche KI, Kartenchat, benutzerdefinierte Karten, Veröffentlichung und die Integration bestehender Karten. Sie dokumentiert kein dediziertes Indoor-Positionierungssystem. Daher sollte Indoor-Positionierung als separate Bereitstellungsfunktion betrachtet werden, sofern der Host kein solches System integriert.

Kann Kaleidr mit einer Indoor-Karte verwendet werden?

Kaleidr kann dialogbasierte KI in kompatible bestehende Kartenimplementierungen integrieren. Die Host-Anwendung bleibt für Kartendaten, das Routennetz und die Indoor-Positionierung verantwortlich.

Wie sollte barrierefreie Wegfindung funktionieren?

Barrierefreiheitsanforderungen sollten als feste Routenbeschränkungen anhand verifizierter Standortdaten kodiert werden. Der Assistent sollte keine barrierefreie Route aus unvollständigen Informationen erstellen.

Kann ein KI-Kartenassistent einen Besucher umleiten?

Der Assistent kann eine neue Route anfordern oder erläutern. Die autoritative Routing-Engine sollte die Route unter Berücksichtigung der aktuellen Netzwerkbedingungen und Zugriffsregeln neu berechnen.

Sollte die Wegfindung den Standort eines Nutzers kontinuierlich verfolgen?

Nur wenn das Produkt dies erfordert und der Nutzer entsprechend informiert wurde oder seine Einwilligung erteilt hat. Viele Wegfindungsfunktionen funktionieren auch mit einem ausgewählten Startpunkt oder Orientierungspunkt ohne dauerhafte Standortverfolgung.

Referenzen

• Kaleidr. AI Map Chat for Customer Discovery. Accessed 27 August 2026. https://kaleidr.com/ai
• Kaleidr. Auth & Scopes. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
• Kaleidr. Chat attach. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/sdk/chat-attach
• Kaleidr. Introduction. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/
• Kaleidr. Location Intelligence APIs and Map SDK. Accessed 27 August 2026. https://kaleidr.com/enterprise
• Kaleidr. Quickstart. Kaleidr Developer Docs. Accessed 27 August 2026. https://docs.kaleidr.com/quickstart
• National Institute of Standards and Technology. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. NIST.CSWP.01162020. 16 January 2020. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf
• Open Geospatial Consortium. IndoorGML 1.1. OGC 19-011r4. 5 November 2020. https://docs.ogc.org/is/19-011r4/19-011r4.html
• Open Geospatial Consortium. Indoor Mapping Data Format. OGC 20-094. Version 1.0.0. 18 February 2021. https://docs.ogc.org/cs/20-094/index.html
• Open Geospatial Consortium. OGC IndoorGML 2.0 Part 1 – Conceptual Model. OGC 22-045r5. 26 June 2025. https://docs.ogc.org/is/22-045r5/22-045r5.html
• Open Geospatial Consortium. OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard. 28 August 2025. Accessed 27 August 2026. https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/
• OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Accessed 27 August 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. Accessed 27 August 2026. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
• W3C. Geolocation. W3C Candidate Recommendation Snapshot, 26 March 2026. Accessed 27 August 2026. https://www.w3.org/TR/geolocation/

@misc{kaleidr_wayfinding_ai_2026_08_27,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/ai}
}

@misc{kaleidr_auth_scopes_2026_08_27,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

@misc{kaleidr_enterprise_wayfinding_2026_08_27,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 27 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}