所有文章 產業

面向場館的 AI 尋路助理

作者 The Kaleidr Team · 發布於 2026年8月27日 · 19 分鐘讀完

AI 尋路架構將目的地探索、路線計算和可選的室內定位功能分開，最後顯示經過驗證的地圖導航。

AI尋路助理能夠解讀自然語言導航請求，從可信任的場館記錄中解析目的地，並協調地圖或路線引導，而無需將發現、路徑規劃和定位視為單一功能。訪客可以詢問應該使用哪個入口、如何到達B廳，或是最近的無障礙洗手間在哪裡。語言模型可以將這些欄位恢復為可檢查的意圖；場地系統、路徑規劃引擎以及任何定位基礎設施仍然對幾何形狀、連通性、存取權限和即時位置具有權威性。

以下章節涵蓋目的地解析、室內連通性、無障礙存取和存取過濾器、起點、共享尋路狀態、Kaleidr 目前的公共適用性、測量和故障模式。相關閱讀包括活動導向的 AI 場地地圖、如何建構地圖感知型 AI 助理、位置智慧客戶體驗地圖、面向飯店的 AI 賓客禮賓服務 和用於 AI 地圖工作流程的私有位置資料。

AI尋路要點

  • **發現並非路徑規劃：**找到B廳並不等於計算通往B廳的路徑。
  • **路徑規劃並非定位：**在產品知道訪客所在位置之前，可能已經存在有效的路徑。
  • **平面圖並非網路：**室內導航需要空間、門、走廊和樓層過渡之間的拓撲結構。
  • **無障礙和存取是硬性篩選條件：**樓梯、員工走廊和封閉邊緣必須從圖中移除，而不僅僅是降低評分。
  • **語言模型解讀意圖：**地理空間與場館系統計算路徑；主辦單位驗證地圖操作。

AI尋路架構在顯示已驗證的地圖導航之前，將目的地發現、路徑計算和可選的室內定位分開。

什麼是AI尋路助理？

AI 尋路助理是一個面向使用者的介面，它利用對話、地圖上下文和可靠的位置資料，回答使用者在複雜場所應該去哪裡以及如何到達目的地。普通的搜尋只能返回房間名稱，靜態海報可以展示建築物的平面圖，但兩者都無法將起點、樓層、門票資格、無障礙設施、即時封閉情況以及當前顯示的路線整合到一個可查看的狀態中。會議廳、校園、醫院、機場、度假村和購物中心每隔幾分鐘就會產生這種複雜的需求。這款實用的產品會在地圖上清楚地顯示目的地、路線和樓層，而不是讓使用者從標牌、PDF 文件和無法移動相機的聊天面板中自行建立這些資訊。

Kaleidr 的空間 AI 頁面將「導航」列為地圖體驗之一，並描述了符合使用者出行方式的路線 (AI Map Chat for Customer Discovery)。該頁面權威地介紹了 Kaleidr 自身面向戶外和旅行的導航定位功能。室內逐嚮導航屬於不同的範疇：它包含目的地資訊、可路由的網路，以及（僅在實際部署時）定位系統。面向客戶的位置資訊仍採用「發現→比較→行動」的流程。「發現」用於檢索符合條件的目的地。「比較」使樓層、行程關係、無障礙設施和存取權限可查看。「行動」用於突出顯示、樓層切換、在存在路由的情況下請求路線，或人員交接。

任務應該在堆疊之前編寫。例如，場地訪客可能需要離座位最近的入口。會議參與者可能需要從目前會場到下一個會場的路徑。機場旅客可能需要靠近登機口的指定休息室。校園使用者可能需要離教室最近的建築入口。醫院訪客可能需要從公共入口取得影像。每個任務的候選對象、硬性約束、垂直過渡以及是否需要即時定位都會有所不同。如果從「室內AI導航」入手，就會忽略這些差異，並導致產品聲稱能夠滿足場地無法支援的需求。

為什麼發現、路由和定位必須分開？

目的地發現回答了哪個地點是相關的。路由計算回答了符合條件的訪客可以使用哪條連通路徑。定位回答了訪客目前的位置、樓層，以及（如果硬體支援）訪客的朝向。這三層可以互相協作，但彼此不可取代。例如，一張平面圖可以顯示204房間，但仍缺少走廊連通性、開放的門、無障礙的過渡、通往目標樓層的電梯服務以及可靠的起點資訊。諸如“十米後左轉”之類的逐向導航指令需要路線和實時位置資訊，且位置資訊必須具有可用的精度和方向性。語言模型可以協調該請求。但語言模型無法提供缺失的拓樸結構或藍點。

Open Geospatial Consortium 的 IndoorGML 2.0 第 1 部分概念模型是目前室內導航網路的 OGC 概念模式。該標準對空間及其細分、幾何和語義屬性、連接類型以及邏輯和度量導航網路進行建模（OGC IndoorGML 2.0 Part 1 – Conceptual Model，OGC 22-045r5，發佈於 2025 年 6 月 26 日）。生產產品無需序列化 IndoorGML。但產品必須遵循相同的差異：視覺幾何並非導航圖。OGC 於 2025 年 8 月 28 日發布的公告稱 IndoorGML 2.0 第 2 部分編碼即將發布 (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard)。IndoorGML 1.1 仍然是已發布的面向編碼的 IndoorGML 標準 (IndoorGML 1.1, OGC 19-011r4, 2020 年 11 月 5 日)。請引用第 1 部分作為概念性契約；在第 2 部分發布之前，請勿將 GML、JSON 或 SQL IndoorGML 2.0 編碼視為已發布的實現標準。

室內地圖資料格式 (IMDF) 是一個補充性的 OGC 社區標準，用於存儲室內位置資訊，以進行定向、導航和發現，其中包括機場、購物中心和火車站的建模說明（Indoor Mapping Data Format，OGC 20-094，版本 1.0.01 年，發佈於 2011 年 2011 年 2011 年）。IndoorGML 2.0 第 1 部分本身描述了 IMDF 提供了一個綜合模型，應用程式可以從中導出路徑，而 IndoorGML 則旨在實現統一的空間圖方法。對於 AI 尋路助理而言，其操作要點更為明確：在對話承諾導航之前，必須先存在結構化的室內資料。

室外尋路通常更簡單，因為道路或行人網路、路徑 API 和 GNSS 已經存在。助理可以對目的地進行地理編碼，向服務提供者請求路線，並將結果繪製出來。室內和混合校園人流通常需要額外的基礎設施：樓層狀態、垂直過渡、門禁邊界，以及可能並非來自瀏覽器的起點。一條校園路徑可能將室外路徑 GNSS 連接到建築物入口，然後連接到室內路徑。對話層可以解釋這種過渡。路由引擎仍然擁有每個路徑的所有權。

路由前如何進行目的地解析？

路由到原始字串“B廳”是一個產品缺陷。應用程式應該在路由引擎運作之前解析出穩定的目的地識別碼、建築物和樓層。顯示名稱衝突：12號門和12號入口是不同類型的實體。房間、隔間和會話標識符在人類語言中也會衝突，原因與AI場地地圖 將幾何圖形與事件疊加層分開的原因相同。建築物、樓層、入口、房間、大門、亭子、洗手間、電梯、樓梯、停車區域和服務台等資訊的輸入記錄，可在標籤變更時保持搜尋、地圖、路線、無障礙設施和分析功能的同步。

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

資格認定應在同一步驟中進行。即使休息室與房間物理相連，仍可能因票級、安檢區域或僅限工作人員進入等原因而被禁止進入。候選空間應在進行空間比較和解釋之前通過授權和運行狀態驗證。受限多邊形應在檢索前進行過濾，以便語言模型無需「記住」哪些走廊是私有的。OWASP’s LLM01:2025 Prompt Injection 描述了使用者或檢索到的文字如何改變模型行為，包括對連結功能的影響。OWASP Top 10 for LLM Applications 2025 列出了 LLM06:2025 Excessive Agency：當系統被賦予過多的功能、權限或自主權時，意外或被篡改的模型輸出可能導致的有害行為。尋路助理應建議目的地和允許的操作。主機應用程式應在模式、存取權限和網路狀態驗證之後執行攝影機移動、樓層切換或路線請求。

歧義是首要結果。「正門」、「北門」和「VIP 入口」都可以是有效的解析結果。該產品應該詢問使用者輸入的候選地點，在地圖上列出，或要求使用者點擊，而不是透過字串相似度進行猜測。即使對話失敗，直接目的地搜尋也必須有效。輸入 Hall B 的訪客不應該需要對話。確定性查找、篩選器、地圖和複合問題的對話應該使用相同的識別碼。

為什麼室內路線規劃需要連結性，而不是平面圖？

地點查找會突顯幾何圖形。室內路線規劃基於連通圖進行計算：從房間到走廊，再到門，再到樓梯或電梯，最後到達另一層。顯示多邊形和路線節點可以有意地分開。房間多邊形可以連接到門口節點；走廊邊代表行程；電梯和樓梯邊代表樓層變更、無障礙設施和運作狀態。裝飾性折線的柵格平面圖並非這樣的圖。場地地圖指南 也明確區分了顯示房間和提供逐向路徑之間的區別。

多層場館地圖及其路徑圖用於展示室內導航依賴於空間、門、走廊、電梯和樓層之間的明確連接。

多層狀態必須明確。起點和終點應包含建築物和樓層識別碼。使用者介面應顯示路徑何時切換樓層，而不是將轉換隱藏在一條二維線內。垂直邊緣需要類型化的屬性：樓梯、電梯、自動扶梯、坡道、無障礙設施、服務樓層以及開放或關閉狀態。路徑引擎使用這些屬性。語言模型可以在引擎返回結構化步驟後解釋這些屬性。理想的流程是：路徑引擎→結構化步驟→更清晰的措辭，而不是隨意編造方向。即使指南針方向不可用，諸如“繼續前往中央大廳，然後使用東側電梯”之類的地標相對指示仍然可用。

臨時關閉是營運記錄，而不是地圖裝飾。自動扶梯故障、走廊堵塞、入口關閉、樓層限製或電梯故障都應標記為路徑閉合，並強制重新計算路徑。訪客閱讀的說明應反映目前路徑版本。在實際場所中，使用對話式文字繪製的過時幾何圖形是一個安全問題，而不是複製問題。重新路由屬於引擎的職責：當起點改變或路徑閉合時，先前的路徑失效，系統會計算新的路徑。要求語言模型修補座標是錯誤的控制方式。

無障礙、存取規則和閉合如何篩選路徑？

無障礙要求是路徑規劃的硬性約束。如果訪客要求提供無障礙路徑，則樓梯路徑可能會被排除。完整的無障礙路徑可能需要無階梯通行、正常運作的電梯、無障礙入口以及場所實際記錄的門寬。將無障礙因素融入軟性偏好權重中，仍可能導致不無障礙的路徑被排在第一位。缺少無障礙資料並不意味著可以隨意創建完全無障礙的路徑。當系統僅識別出無障礙入口和電梯時，只能說明這些設施已在地圖上顯示，但並不代表完整的無障礙路徑已獲得認證。法律上的無障礙義務仍由合格的律師和場地運作方進行判斷；本文主要介紹資料合約。

根據可及性、存取權限和目前運行狀態篩選三條候選路徑，直至只剩下有效路徑。

物理連通性只是資格審查的一個維度。員工走廊、VIP通道、保全區域、售票區域和員工入口在圖中可能顯示為可通行，但對該訪客而言仍禁止通行。路徑資格取決於實體連通性、存取權限和運行狀態。受限路徑在應用存取控制之前絕不應到達通訊層。安全的流程是：身份驗證、確定存取權限、檢索允許的空間、計算允許的路徑，然後進行解釋。計算跨越所有空間的路徑並在之後隱藏受限步驟會洩漏拓撲結構。地圖 API 驗證涵蓋了將通訊附加到主機地圖的Kaleidr表面的可發布金鑰與伺服器金鑰；場館存取規則仍然存在於主機的身分和票務系統中。

緊急和安全路由至關重要。生成式導航助理不應基於通用模型知識自行建立疏散路徑、緊急程序或受限的安全指南。應使用場館認可的緊急內容、官方計劃、現場工作人員以及運行警報。當相關記錄具有權威性時，尋路產品可以顯示已批准的急救或出口位置。高風險路線規劃應由專為此設計的運行系統負責。

尋路何時需要定位，何時不需要？

每條路線都需要一個起點。起點可以來自明確的地圖選擇、已知的地標（例如主入口）、上次指定的區域（「我在A廳」）、室外設備位置或室內定位基礎設施。即使存在自動定位，也必須保留手動起點選項。置信度取決於資料。幾米精度的定位報告可以支援走廊範圍內的導航。而室內定位誤差達數十公尺的報告則可能導致選擇錯誤的走廊或樓層。產品應能提示室內位置不確定，並要求訪客選擇目前區域。從錯誤源頭出發的可靠路徑規劃比簡短的澄清更糟糕。

W3C Geolocation 規格（一份日期為 2026 年 3 月 26 日的候選推薦快照）規定，只有在獲得明確許可後才能存取設備位置，且 API 不保證設備的實際位置。瀏覽器定位並非室內藍點。Bluetooth 信標、Wi-Fi 定位、ultra-wideband 視覺定位和特定場所繫統屬於基礎設施，而非語言模型功能。方向資訊是「左轉」指令的另一個必要條件。地圖仍然可以顯示正確的路線，即使沒有方向資訊。當方向資訊不可用時，應使用地標或地圖相對位置資訊來取代指南針指示。

許多場所無需持續的室內追蹤即可提供有效的尋路功能。訪客選擇一個地標，引擎返迴路線，地圖上保留靜態步數，訪客手動前進。會議場所、校園、度假村和博物館通常更需要這種模式，而不是一個即時顯示的藍點。這種模式還能降低隱私和基礎設施成本。尋路功能可以建立詳細的移動歷史記錄：目前室內位置、路線、重複目的地、工作場所、醫療部門或活動參與。NIST Privacy Framework (NIST.CSWP.01162020，2020 年 1 月 16 日) 將隱私視為企業風險管理：明確收集哪些資料、收集原因以及收集時長。優先使用臨時的起點、終點和路線上下文，而不是持久的移動軌跡。用於 AI 地圖工作流程的私有位置資料 涵蓋相同的主機所有邊界。

對話式尋路如何與地圖分享狀態？

當目的地或路線已顯示在地圖上時，對話功能才真正發揮作用。後續操作，例如詢問目前路徑上的洗手間、要求避開樓梯或從選定的起點前往更近的入口，都依賴共享狀態，而不是第二個非官方的結果清單。地圖、清單、說明和聊天資訊應讀取同一尋路記錄：起點、目的地、目前樓層、路線識別碼、路線版本、無障礙模式以及定位系統啟用時的位置置信度。選擇目的地即可顯示路線。更改無障礙模式可能會使當前版本失效並要求重新計算。助理結果應顯示在訪客已使用的同一張地圖上。

共用尋路狀態同步對話請求、路線資料、樓層上下文、場所資訊和已驗證的地圖操作。 

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

語意操作應保持簡潔：設定起點、聚焦目的地、顯示路線、切換樓層、高亮顯示過渡區域、開啟目的地記錄、清除路線、請求重新規劃路線。在渲染器適配器運作之前，主機將根據目前識別碼、存取權限和網路版本驗證每個有效負載。任意地圖 JavaScript 並非控制契約。這些操作的權限屬於應用程式和基礎設施，而非語言模型。地圖感知助理指南 涵蓋了共享地圖狀態和該切換的已驗證操作。

運行更新應同時對網路和路線進行版本控制。例如，電梯關閉可能會導致網路版本 18 上的路線版本 4 失效，並需要使用版本 5。版本控制使得過時的導航資訊可以進行調試。應用路線前的驗證應確認起點、終點、權限、路線新鮮度、關閉情況和出行方式仍然相符。在即時場所中，尋路狀態會快速變化。室內離線或連接較弱也是正常現象。在適當情況下，快取場所幾何形狀、標籤、最後一層以及最後一條有效路線。如果對話層發生故障，則必須保留直接地點查找功能。空間分析儀錶板 KPI 屬於產品衡量範疇，而非以聊天量作為衡量成功的標準。

Kaleidr 如何融入現有的尋路堆疊？

Kaleidr 目前的開發者文件將聊天功能定位為附加到主機已執行地圖上的對話圖層。Quickstart 展示如何將聊天功能整合到正在運行的 Mapbox、MapLibre、Google Maps 或 Leaflet 實例上。Chat attach 將控制塔描述為基於聊天的導航、地點摘要以及在主機地圖上標記地點的功能。可發佈的鍵值對瀏覽器具有來源鎖定；伺服器鍵值不會顯示在頁面上 (Auth & Scopes)。程式碼片段應使用明顯的佔位符，而不是實際運行的鍵值。

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

這些平台支援自然語言目的地發現、地圖感知對話、地點答案、即時標記和攝影機更新。主機仍然擁有渲染器、場地資料、路線引擎、室內拓撲、定位和存取控制。Kaleidr 的公開文件描述了 AI 地圖聊天、已發布地圖、設計的底圖和地圖編輯。這些文件目前沒有記錄專用的室內定位引擎或專門的逐向室內導航產品。因此，正確的架構是在 Kaleidr 上實現對話式和地圖感知交互，而專門的室內路線規劃或定位功能則保留在場地或導航系統中，以便在部署需要時使用。Location Intelligence APIs and Map SDK 是目前用於推理 API、排名系統、分析和部署支援的商業平台。排名和室內路線規劃仍然是不同的產品；不要根據行銷宣傳來建立虛構的室內導航路線。

混合型場所仍符合這種劃分。室外路段可以使用路線規劃提供者。室內場景可以使用場地地圖。如場地地圖文章所述，活動疊加層可以在不重建牆體的情況下更改展位和會議區域。醫院和機場的請求通常首先在目的地識別和存取權限方面失敗，而不是在路徑繪製方面失敗：“成像”和“我可能在42號登機口附近使用的休息室”首先是資格問題，然後才是幾何問題。語言模型可以解釋請求。授權的業務資料和地理空間服務仍然提供事實依據。

團隊該如何衡量人工智慧尋路助理？

衡量的是尋路效果，而非聊天量。目的地解析率、無結果率、路線成功率、樓層錯誤修正率、重新規劃路線率、存取拒絕率、返迴路線所需時間、目的地確認率和路線放棄率，這些指標描述了訪客是否真正到達了目的地。如果有定位功能，則需新增偏離路線事件、位置置信度失敗和樓層偵測失敗。將發現與導航區分開來：已解析的目的地但路線失敗與查找失敗是不同的缺陷。諸如「目的地已解析」、「路線請求」、「路線失敗」、「樓層已更改」和「重新規劃路線」之類的編輯事件名稱屬於產品分析，而非已記錄的自動事件Kaleidr Analytics。

評估應包括歧義、跨樓層路徑、閉合路徑、存取受限、缺少無障礙資料以及低連接性回退。測試地圖、清單和語音或書面步驟是否顯示相同的路線版本。延遲應按階段進行歸因；將延遲歸咎於「AI」的團隊通常會發現，路線規劃或起點解析才是主要原因。任務完成情況比互動次數更為重要。一位訪客無需交談即可透過搜尋找到 B 廳，這就算成功。而冗長的對話最終卻導致他走到了錯誤的樓層，則不算成功。

尋路產品應避免哪些故障模式？

反覆出現的故障是將三個系統合併成一個產生的段落。樓層平面圖被當作路由圖。語言模型被當作定位系統。樓層資訊消失。無障礙設施變成了優先權重。受限區域洩漏。逐嚮導航文字出現時沒有方向指示。對話成為強制性要求。移動歷史記錄預設保留。以下每一行都是一個產品缺陷及其具體的修正方案。

錯誤 結果 更佳方案
將地圖影像視為導航網路 路線不可信 建立連通性模型
將語言模型視為定位系統 起點變得不可靠 使用明確的起點
忽略樓層 錯誤的樓層引導 在共享狀態下追蹤樓層
讓模型產生路線 不安全或過時的路徑 使用路線引擎
將可存取性視為優先級 不可存取的路線也可能優先 使用硬性約束
忽略臨時封閉區域 過時的路線 更新邊的狀態並重新計算
穿越限制區域的路線 存取洩漏 路線規劃前過濾圖
承諾提供逐嚮導航，但不提供方向資訊 誤導性指示 使用地標或地圖相關的措詞
強制對話 聊天失敗時基本導航失效 保持確定性搜尋
預設保持移動狀態 隱私風險 保留臨時路線上下文

移動尋路需要大的目標、清晰易讀的步驟，以及在模型或耗時的路線逾時時仍然可用的地圖。快取基礎幾何資訊。以可控制的方式降低資訊豐富度。即使對話不可用，也要保留透過文字搜尋獲得的路徑以進行高亮顯示。

建立對話式導航體驗

可靠的架構包括意圖識別、目的地解析、授權路由、路線計算、路線解釋以及已驗證的地圖操作。室內定位是一個可選的後續層，僅當場所運行合適的系統時才添加。Kaleidr 可以將對話式空間 AI 附加到主機已運行的地圖上，而場所拓撲結構和專用路由器在需要真正室內導航時仍然具有權威性。

探索 Kaleidr Enterprise，了解目前的 API、SDK 介面和部署支援。在確定整合路徑之前，請查看 Kaleidr 開發者文件中的連接模式和金鑰類型。

常見問題解答

什麼是 AI 導航助理？

AI 導航助理可以理解自然語言導航問題，從可信任記錄中解析目標目的地，並協調地圖或路線引導。路由和定位仍然是獨立的系統。

AI 導航與室內導航相同嗎？

否。對話可以解讀導航請求。室內導航也需要結構化的路由網路，並且可能需要室內定位。

平面圖影像可以用於逐嚮導航嗎？

不能單獨使用。可靠的路由需要空間、門、走廊、樓梯、電梯和其他過渡區域之間的連結性。

什麼是 IndoorGML？

IndoorGML 是室內空間和導航資料的 OGC 標準。IndoorGML 2.0 第 1 部分是目前空間、連結性和導航網路的概念模型 (OGC 22-045r5)。OGC 描述了 IndoorGML 2.0 的編碼方案，預計於 2025 年 8 月發布；IndoorGML 1.1 仍然是已發布的面向編碼的版本。

什麼是 IMDF？

室內地圖資料格式 (IMDF) 是用於定向、導航和發現的室內位置存檔的 OGC 社區標準 (OGC 20-094，版本 1.0.0)。

Kaleidr 目前是否提供室內定位？

Kaleidr 目前的公開文件描述了空間人工智慧、地圖聊天、自訂地圖、發布和現有地圖整合。文件中並未提及專用的室內定位系統，因此除非宿主程式整合了室內定位功能，否則應將室內定位視為一項獨立的部署功能。

Kaleidr 能否與室內地圖搭配使用？

Kaleidr 可以將對話式人工智慧附加到相容的現有地圖實作中。宿主應用程式仍然負責地圖資料、路線網路和任何室內定位。

無障礙導航該如何運作？

無障礙需求應使用經過驗證的場所資料編碼為硬性路線約束。助理不應根據不完整的資訊創建無障礙路線。

人工智慧地圖助理能否為訪客重新規劃路線？

助理可以請求或解釋新的路線。權威的路線引擎應使用目前的網路狀況和存取規則重新計算路線。

導航功能是否應該持續追蹤使用者的位置？

僅當產品需要且使用者已收到適當通知或同意時才需要。許多導航任務無需持續追蹤使用者位置，只需選擇起點或地標即可。

參考資料

@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/}
}

相關內容

將您的地圖變成成長引擎