所有文章 空間 AI

為互動地圖加入 AI 聊天助理

作者 Kaleidr 團隊 · 發布於 2026年7月15日 · 更新於 2026年7月16日 · 19 分鐘讀完

AI 驅動的地圖體驗，將自然語言提問連結到地點、路線、物件、服務與已授權的商家資訊。

AI 地圖助理把對話介面與互動式地圖、地理空間服務以及經授權的資料集結合在一起，將自然語言的請求轉換成搜尋、地理計算、檢索操作，以及經過驗證的視覺動作。傳統的互動式地圖把這層轉換工作丟給使用者：使用者得自行把目標拆解成一連串的搜尋、篩選、視野調整、標記點選與空間比較。具備 AI 能力的地圖則反轉了這個安排——它直接接受以自然語言表達的目標本身。

造訪者可能會問：「幫我找步行 15 分鐘內、適合全家用餐的餐廳」、「哪些物件靠近捷運站而且至少有三房？」或是「找出最近一個可預約的服務據點並規劃路線」。每一個請求陳述的都是目標，而不是預先設定好的介面操作步驟；決定要用哪些搜尋、篩選與計算來滿足它的，是助理而不是造訪者。地圖因此不再只是傳統的視覺顯示工具：助理可以檢索相關紀錄、篩選地理資料、調整視野、highlight 結果、開啟商家或物件資訊，並向合適的路徑規劃服務請求路線。

語言、地理空間資料與視覺互動三者整合之後，會產生一種對話式地圖：它能解讀使用者意圖，並同時透過說明性的語言與結構化的應用程式動作來回應。對話因此成為空間搜尋與決策支援的介面，而不是附在介面旁邊的評註。這個區別之所以重要，是因為它決定了應用程式要把答案的每一個部分交給哪一個元件負責。

從地圖搜尋到空間對話

傳統的地圖介面要求使用者理解應用程式如何組織資訊：先選類別、輸入精確地點、套用篩選條件、逐一檢視多個標記，然後在沒有直接協助的情況下比較各個地點。對話式介面則把其中一部分的認知與操作負擔從使用者轉移到系統身上，因為使用者只要陳述目標，由應用程式決定哪些搜尋、資料集、篩選條件、計算與地圖操作能夠處理它。這個轉移改變的是責任歸屬而不是能力範圍，畢竟兩種介面最終查詢的都是同一批底層資料。

以這個請求為例：「飯店附近現在還有營業、最適合吃晚餐的地方有哪些？」系統可能需要先確定飯店的位置、搜尋附近餐廳、取得目前的營業時間資料、計算步行時間、套用已陳述的偏好、對結果排序、顯示選定的地點，並說明排序的依據。整個流程遠遠超出一般的語言生成：語言模型負責解讀請求並協調獲准使用的工具，而專門的地理服務與經授權的商家資料集則提供答案所依賴的地點、屬性、路線與營業資訊。文字再流暢，也無法讓這些輸入變得更準確。

AI 地圖助理實際上在做什麼

1. 助理解讀自然語言意圖

使用者很少會把地理目標寫成正式的資料庫查詢，而自然語言的請求經常在一個句子裡同時混雜距離、時間、偏好、營業狀態、無障礙需求與情境限制。看看這個請求：「幫我找會議中心附近一家安靜、可以待兩小時工作的咖啡店。」它一次施加了好幾個隱含條件：系統必須找出指定地標附近的咖啡店、判斷現有資料是否顯示該處適合工作，並確認該地點在預計時段內很可能仍在營業。這些條件沒有一項是以明確的篩選器形式出現，而且各自依賴不同的資料來源。

「附近」這個詞還需要一個可操作的定義，編排層可以把它設定成步行距離門檻、旅行時間門檻或地理半徑。這個選擇有實質後果而非表面差異，因為同一個請求在不同定義下會回傳不同的結果集。因此，語言模型應該把請求轉換成結構化的搜尋參數，並在歧義導致無法可靠執行時主動請求釐清，而不是默默替使用者做出決定，再把結果當成使用者原本就指定過的樣子呈現出來。

2. 助理檢索有依據的資訊

可靠的 AI 地圖助理絕不能自行捏造地址、路線、營業時間、庫存、物件屬性、可用狀態或地理座標；這些事實應該全部由已連接且經授權的資料來源提供。相關來源可能包括地理資訊系統圖層、地點搜尋服務、路徑規劃服務、商家資料庫、客戶關係管理系統、不動產登錄資料、庫存系統、場館資訊、組織內部文件，以及即時營運 API。這份清單之所以這麼長，是因為一個有差異化的答案通常同時取用多個來源，而每個來源都有各自的新鮮度與授權特性。

檢索增強生成把語言模型與外部資訊檢索結合起來，這正是 Lewis and colleagues 為知識密集型任務所確立的作法。空間應用則在此基礎上加入地理限制條件，因此地圖助理可能需要在某個半徑、地圖邊界、路線廊帶、行政區、選定圖層或目前視野範圍內搜尋，而不是在一個未區分的索引裡全面搜尋。語言模型負責協調請求，但權威資料仍由專門的地理與商業系統負責提供；正是這種責任分工，才能避免流暢的語言掩蓋掉缺乏依據的地理或營運主張。

3. 助理產生結構化的地圖動作

出色的 AI 地圖助理回傳的不該只有對話式文字，它還應該提出可供應用程式驗證與執行的結構化指令。這種把推理與外部動作交錯進行的模式，正是 Yao and colleagues 針對透過工具行動的語言模型所描述的作法。把文字敘述與結構化動作清楚分開，同時有利於可靠性與問責：語言模型可以提出一項操作，但由應用程式決定該操作是否屬於核可的動作集合、每個參數是否符合對應的 schema，以及目前使用者是否具備必要權限。提出建議的一方與有權執行的一方，始終分屬不同角色。

{
  "message": "I found four hotels within a 10-minute walk of the venue.",
  "actions": [
    {
      "type": "fit_bounds",
      "feature_ids": ["hotel-14", "hotel-22", "hotel-31", "hotel-45"]
    },
    {
      "type": "highlight_features",
      "feature_ids": ["hotel-14", "hotel-22", "hotel-31", "hotel-45"]
    },
    {
      "type": "open_result_panel",
      "sort_by": "walking_time"
    }
  ]
}

核可的動作集合可能包含以下操作：

  • 在目前視野範圍內搜尋
  • 平移或縮放到某個地理區域
  • highlight 標記或地理圖徵
  • 篩選資料集
  • 切換地圖圖層
  • 開啟某筆物件或商家紀錄
  • 比較選定的地點
  • 繪製路線或服務範圍
  • 摘要目前可見的圖徵
  • 顯示某個區域相關的分析資料

應用程式只應接受符合明確 schema 的白名單動作。新興的整合標準也在處理同一種分離原則：Model Context Protocol 定義了應用程式如何透過一個宣告式介面（而非開放式執行）把工具與資源提供給模型。驗證層應該拒絕不支援的操作、無法存取的紀錄、無效的識別碼、未經授權的資料集，以及不安全的參數。應用程式絕不應該賦予語言模型不受限制地執行任意 JavaScript、SQL、shell 指令或應用程式碼的權限。

4. 助理說明結果

出色的助理應該說明系統為何挑出這個結果、有哪些證據支持這個選擇，以及不確定性還留在哪裡。像「A 餐廳是附近最好的選擇」這樣的說法，若系統沒有定義排序標準就可能誤導使用者，因為「最好」可能指距離、營業時間、價格、使用者評分、無障礙程度、飲食選項，或其他完全不同的可衡量屬性。這個詞恰恰藏起了使用者最想檢視的那個判斷。

更透明的回應會這樣寫：「這三家餐廳都在步行 12 分鐘內，營業時間至少到晚上 10:00，也符合您對素食選項的需求。介面依照估計步行時間排序。」修改後的回應把篩選標準攤開來，並將可觀察的事實與主觀判斷區分開來。透明的標準還有第二個好處：使用者可以質疑、調整或替換排序假設，而不是只能全盤接受或整個放棄這個答案。

對話式地圖的參考架構

面向正式環境的對話式地圖，通常仰賴六個彼此串接的層。每一層執行不同的功能，並限制語言模型的權限範圍。

對話介面

對話介面提供使用者看得到的聊天或語音體驗。此介面接收使用者請求、串流回應、顯示相關的來源資訊、讓對話輸出與地圖保持同步，並在執行影響重大或涉及敏感內容的動作前請求確認。

推論與編排層

推論與編排層負責判斷哪些資料、服務與核可工具能夠處理某個請求。這一層可以分類使用者意圖、解析地理指涉、取得商業情境、挑選獲准使用的工具、產生結構化參數、彙整回傳的證據，並記錄錯誤或遙測資料。

地理空間服務層

地理空間服務層負責執行地理編碼（geocoding）、反向地理編碼、附近地點搜尋、空間交集運算、距離計算、旅行時間估算、路線生成與視野範圍計算。這些運算應該由專門服務執行，因為自由形式的語言生成無法提供具權威性的地理計算。語言模型可以判斷出「這裡需要一條路線」，但路線本身應該交由路徑規劃引擎計算。

商業資料層

一般性的地點資料，通常不足以支撐具差異化的顧客體驗。飯店可能需要揭露設施、入住資訊、活動行程、餐廳與館內興趣點。房地產平台可能需要物件、價格、平面圖、學區資訊與可售狀態。零售業者則可能需要各據點的庫存與服務資訊。所有私有或租戶專屬的資料集，都必須由應用層級的授權機制控管存取。

地圖動作驗證層

地圖動作驗證層會在使用者介面執行動作之前，先對提出的動作進行評估。這一層應該強制檢查明確的 schema、使用者權限、租戶邊界、支援的動作類型、有效的參數，以及適當的資料存取範圍。語言模型提出動作；應用程式則決定授權、拒絕或執行這項提議。

分析與可觀測性層

分析與可觀測性層負責記錄技術效能與使用者成果。相關訊號包括追蹤紀錄、延遲、工具呼叫、檢索結果、綱要驗證失敗、錯誤、成本、可見的地圖變化、已完成的任務，以及業務轉換。OpenTelemetry 的生成式 AI 系統語意慣例描述了一套逐漸成形的模型追蹤與指標詞彙，不過該慣例仍屬 Development 狀態，日後可能變動。將模型與地圖的遙測資料整合起來，維運人員才能評估完整的體驗，而不是把 AI 地圖助理當成孤立的元件看待。

事實依據：展示品與可靠產品的分界線

語言流暢並不等於系統可靠。一個值得信賴的對話式地圖，必須確保文字回應與可見的地圖狀態源自同一份經過授權的證據，這代表助理必須區分模型知識、檢索到的資訊、計算得出的地理資訊、使用者提供的脈絡，以及模型生成的詮釋。每一類證據的效力都不同：模型知識可能不完整或過時；連接的資料來源提供檢索資訊；專門服務則產出距離、行車時間、邊界、路線等計算值；而使用者則提供偏好、選定的地點與自願分享的脈絡。任何跨類別推導出的推論，都應標示為估計值，而非既定事實。

這項區分會帶來具體後果。助理不應該只因為某個舊網頁列出了晚間營業時間，就斷定一家餐廳目前有營業；系統反而應該指出營業時間資料的來源、時間戳記與相關限制。同樣地，除非有經核可的地理來源或授權的組織資料集提供座標，否則應用程式不應在地圖上放置任何圖徵——因為一個標記所斷言的事實，力道並不亞於一句話。因此，可靠的回應會說明推薦的依據，在資料新鮮度會影響結果時標示相關時間戳記，在適當情況下註明底層資料集，在證據仍不完整時傳達不確定性，並拒絕捏造缺失的地理事實。

高價值應用場景

旅宿與觀光

飯店與目的地業者可以把對話式地圖當成數位禮賓介面。房客可能會詢問哪些景點在步行範圍內、特定時間後還能去哪裡用餐、某個設施該走哪個入口、如何前往機場，或附近正在舉辦哪些活動。介面可以直接在地圖上顯示相關地點與路線，減少在不同應用程式之間搬運資訊的需求。

房地產與物件探索

物件探索結合了結構化條件與依賴位置的偏好。潛在買家或租客可能會要求找出通勤鐵路附近的房屋、某個行政區內的可租售物件、鄰近公園或學校的物件，或是比較各個物件到工作地點的通勤時間。助理能把這些需求轉換成物件篩選條件、空間查詢與比較用的地圖檢視。

零售與多據點企業

對話式門市查詢可以把地理資訊與庫存、營業時間及服務資料結合起來。顧客可能會問哪家門市有這項商品、哪家提供當日取貨、哪家營業到最晚，或哪個服務中心的交通時間最短。業務資料是否即時，決定了這次互動能否支撐一項營運決策，而不只是單純的地點查詢。同樣的證據品質，也早在訪客抵達地圖之前，就決定了 AI 搜尋系統是否會推薦這家店家。

活動、校園與複雜場館

大型場館往往透過靜態 PDF、指示牌或標記密集的地圖來傳達空間資訊。對話式地圖可以協助訪客找到停車區、無障礙動線、入口、參展單位、會議室、餐飲服務與緊急設施。當使用者逐步釐清目標時，介面也能同步收斂可見的資訊量。

公部門與營運資料

公家機關與營運團隊可以運用對話式地圖，輔助探索土地分區、基礎建設、交通、環境、公民事務與災害管理等資料。後果較嚴重的應用需要更嚴格的控管，因為不準確、未經授權或過時的答案，可能影響公共服務、資源配置或個人安全。

安全與隱私考量

提示注入

當惡意的使用者輸入或檢索到的內容試圖覆寫應用程式指令、揭露受限資訊，或觸發未經授權的操作時，就會發生提示注入。OWASP Gen AI Security Project 在其 2025 年 LLM 應用程式十大風險中，將提示注入列為首位。因此，安全的地圖助理應該把使用者訊息、檢索內容與模型輸出一視同仁地視為不可信輸入，直到應用程式完成驗證為止。適當的防護措施包括：嚴格區隔系統指令與檢索資料、工具白名單、綱要驗證、外部授權檢查、租戶層級隔離、輸入與輸出過濾、對重大操作要求人工確認，以及針對工具呼叫與資料存取留存稽核紀錄。

檢索能提升事實依據的品質，但光靠檢索無法消除提示注入風險。檢索到的文件、資料庫欄位與外部網頁本身就可能包含惡意或誤導性的指令，這意味著檢索層在縮小準確度落差的同時，也擴大了攻擊面。把檢索到的文件當成資料而非指令來處理，正是讓這兩種效應得以分離的關鍵。

位置隱私

精確位置屬於敏感個人資訊。應用程式只應在所要求的功能能為使用者帶來明確好處時才提出請求，並且必須尊重瀏覽器與裝置的權限控制；W3C 的 Geolocation 規範定義了管理精確座標存取的瀏覽器權限模型。因此，重視隱私的應用程式會說明請求的目的、延後到必要時才索取精確座標、盡量減少保存期間、限制只有授權服務能存取、避免把原始座標寫進不必要的記錄檔，並在使用者拒絕授權時仍保留可用的替代方案。最後一點在實務上尤其重要，因為一個沒有精確位置就毫無用處的助理，等於把權限詢問變成了強制要求。

資料存取與租戶隔離

對話式請求絕不能繞過那些保護企業客戶私有地點、物件、分析資料、庫存或營運紀錄的存取控制。授權判斷不該交給語言模型：在檢索資訊或把任何資料交給模型之前，應用程式與資料基礎架構必須先驗證身分、角色、租戶、資料集存取權與允許的操作。因此，授權層會針對每一次請求，逐一比對已驗證的使用者、所屬租戶、使用者角色、可存取的資料集與核可的操作集合，而且不論該請求是透過表單還是透過一句話送出，都一視同仁。模型從未收到未經授權的資料，就不可能被誘導揭露它。

風險管理

正式上線的系統除了評估回應品質之外，還應評估地理準確度、來源新鮮度、隱私、授權、工具行為、營運影響，以及錯誤操作所帶來的後果。有效的風險管理需要在設計、開發、部署、監控與評估的整個過程中持續進行。NIST 的生成式人工智慧概況文件即以生成式系統特有的風險，以及組織可採取的因應行動為軸線來組織這項工作。

衡量助理是否真的創造價值

光看訊息量，並不足以衡量 AI 地圖助理的價值。高訊息量可能反映持續的互動投入，但同樣可能代表語意含糊、反覆出錯或任務未能完成，而單純的計數無法區分這幾種情況。因此，更完整的評估架構會同時衡量採用率、任務成功率、技術品質與業務成果，並把對話行為與可見的地圖互動、後續的使用者行動串連起來，而不是把對話逐字稿當成全部的紀錄。

採用率

  • 開啟助理的地圖訪客百分比
  • 送出提問的訪客百分比
  • 首次提問完成率
  • 回訪使用助理的使用者比例

任務成功率

  • 成功的地點或圖徵搜尋次數
  • 已啟動的路線規劃數
  • 已開啟的物件或地點數
  • 透過對話套用的篩選條件數
  • 達成既定業務成果的工作階段數
  • 澄清與重述提問的比率

技術品質

  • 回應延遲
  • 工具呼叫成功率
  • 檢索成功率
  • 無依據答案比率
  • 綱要驗證失敗次數
  • 取得答案後的中離率
  • 文字回應與可見地圖狀態的一致性
  • 每完成一項任務的成本

業務成果

  • 開始訂房／訂位的次數
  • 物件諮詢數
  • 到店造訪數
  • 路線查詢數
  • 商品與門市的媒合數
  • 名單留資數
  • 活動參與度
  • 轉換率
  • 找到相關資訊所需的時間

任務是否完成，往往比對話長度更具參考價值。一次兩則訊息的互動如果能把房客帶到正確的入口，價值可能遠高於一段冗長卻未解決問題的對話。

用 Kaleidr 打造這樣的體驗

Kaleidr 把 AI 互動與互動式地圖、地理資料、已授權的業務資訊、結構化視覺動作、網站體驗及開發者整合串連起來。以 Kaleidr 實作時，可以讓對話與可見的地圖協同運作，而不是把聊天當成一個獨立的小工具；依照所選的設定，助理能檢索已授權的資訊、找出相關地點、提出結構化的地圖動作，並同時以說明文字與視覺互動回傳結果。企業可以把 Kaleidr 體驗部署成獨立的互動式地圖、嵌入既有網站的地圖、以地圖為核心的網站範本、開發者整合，或客製化的位置感知應用程式——沒有前端工程師的團隊，也能不寫程式就上線一個完整的地圖網站。

Kaleidr 的分析介面設計目標是把對話與地圖遙測資料和業務成果串在一起，但截至撰稿時仍在開發中，尚未全面開放，因此打算採用上述衡量架構的團隊，過渡期間應自行規劃埋點與量測。無論如何，有效的實作絕不只是在地圖旁邊加一個聊天面板：一個有事實依據的對話式介面，應該讓使用者能探索地點、業務資料與空間關係，同時保全資料來源溯源、權限邊界與應用程式層級的控制權。

限制與待解問題

對話式地圖會遇到不少限制：資料不完整、記錄過時、需求語意模糊、模型出錯、服務延遲、地理涵蓋範圍有缺口，以及來源品質參差不齊。就算檢索結果正確，也不代表最終回覆一定正確——語言模型可能把可靠的資料摘要錯誤、在正確判讀意圖後卻挑了不合適的工具，或者產生語法有效、但參數超出當前使用者權限的動作。這幾種失誤都會產出一個看起來很有把握的答案，也正因如此，光看對話記錄很難察覺問題。

因此，正式上線的部署必須具備持續評估、權限強制執行、綱要驗證、來源監控、可觀測性、備援程序，並明確傳達不確定性。組織也應該區分實驗性展示與正式系統：展示只要能漂亮地答對一次就算成功，正式系統則必須針對地理準確度、授權、隱私、失敗復原、營運韌性與可量測的任務完成率進行測試。

結論

AI 對話能讓互動地圖更好搜尋、更貼近使用者目標，也更緊密地連結相關的商業資訊。自然語言理解、對地理與組織資料的可溯源存取，以及對可見地圖的結構化控制，三者共同決定對話式地圖能否交出這樣的成果，缺一不可。語言模型應該扮演協調者的角色，串起地理空間資料庫、路徑規劃引擎、授權系統與應用程式邏輯，而不是取代這些專門元件。

職責劃分清楚，所得到的就不只是一張會產生對話文字的地圖。這樣的系統能夠解讀使用者的目標、檢索相關證據、呈現合適的空間脈絡，並協助完成明確定義的任務，而且每一步都能追溯到實際執行它的元件。Kaleidr 可以提供這層對話與空間介面，讓使用者在其中提問、探索已獲授權的地點資料，並依據得到的資訊採取行動。

常見問題

什麼是 AI 地圖助理？

AI 地圖助理結合了對話介面、互動地圖、地理空間服務與相關資料集。系統會解讀自然語言問題，並透過經過驗證的應用程式動作來搜尋、篩選、標示、比較或規劃地理資訊的路徑。

AI 對話在互動地圖上如何運作？

語言模型會解讀使用者的需求，並從一組經核可的工具中做選擇。地理與商業系統負責檢索或計算所需資訊，應用程式則在更新可見地圖之前驗證這些動作。

AI 聊天機器人可以控制地圖嗎？

AI 模型可以提出結構化動作，例如標示標記、變更視野範圍（viewport）、套用篩選條件、開啟記錄或請求路徑規劃。應用程式必須在執行前驗證並授權每一項動作。

對話式地圖和一般聊天機器人有什麼不同？

傳統聊天機器人主要回傳文字。對話式地圖則把語言與地理檢索、專門計算、已授權的商業資料以及地圖視覺動作結合起來，讓應用程式能在空間上呈現答案。

AI 地圖助理可以使用哪些資料？

可用資料取決於授權與系統設定。AI 地圖助理可能會用到地點記錄、GIS 圖層、不動產資訊、庫存、場館資料、客戶資料庫、組織文件、路徑規劃服務，以及即時營運 API。

AI 會取代地點或路徑規劃 API 嗎？

不會。語言模型負責解讀需求、找出可能有用的操作。權威的地點記錄、座標、距離、行車時間與路徑，仍應由專門的地理服務提供。

AI 助理可以使用私有的商業資料嗎？

只要應用程式提供了經授權的連線，AI 助理就可以使用私有的商業資料。在系統檢索或處理私有記錄之前，應用程式基礎架構必須落實身分驗證、權限控管與租戶隔離。

主要的安全風險有哪些？

主要風險包括提示注入（prompt injection）、惡意的檢索內容、未經授權的工具呼叫、敏感資料外洩、權限過大、跨租戶存取、記錄機制不安全，以及精確位置資訊外流。應用層的控管措施應該獨立於語言模型之外，逐一因應這些風險。

企業該如何衡量 AI 地圖的互動成效？

相關指標包括助理採用率、成功搜尋次數、建立的路徑數、開啟的記錄數、工具錯誤、回應延遲、澄清提問比率、任務完成率，以及相應的商業轉換。整體而言，使用者實際完成的任務比訊息總量更能說明問題。

Kaleidr 如何支援導入 AI 的地圖體驗？

Kaleidr 把對話式 AI 與互動地圖、已授權的商業資料、結構化視覺動作、網站範本以及開發者整合串連起來。每個 Kaleidr 體驗涵蓋的範圍，取決於所選的實作方式與啟用的功能。

參考文獻

@techreport{nist_genai_profile,
  title       = {Artificial Intelligence Risk Management Framework: Generative
                 Artificial Intelligence Profile},
  author      = {Autio, Chloe and Schwartz, Reva and Dunietz, Jesse and Jain, Shomik
                 and Stanley, Martin and Tabassi, Elham and Hall, Patrick and Roberts, Kamie},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 600-1},
  year        = {2024},
  month       = jul,
  doi         = {10.6028/NIST.AI.600-1},
  url         = {https://doi.org/10.6028/NIST.AI.600-1}
}

@inproceedings{lewis2020retrieval,
  title         = {Retrieval-Augmented Generation for Knowledge-Intensive {NLP} Tasks},
  author        = {Lewis, Patrick and Perez, Ethan and Piktus, Aleksandra and Petroni, Fabio
                   and Karpukhin, Vladimir and Goyal, Naman and K{\"u}ttler, Heinrich
                   and Lewis, Mike and Yih, Wen-tau and Rockt{\"a}schel, Tim
                   and Riedel, Sebastian and Kiela, Douwe},
  booktitle     = {Advances in Neural Information Processing Systems (NeurIPS)},
  year          = {2020},
  eprint        = {2005.11401},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2005.11401}
}

@misc{mcp_specification,
  title  = {Model Context Protocol Specification},
  author = {{Model Context Protocol}},
  year   = {2025},
  note   = {Revision 2025-11-25},
  url    = {https://modelcontextprotocol.io/specification/2025-11-25/}
}

@misc{opentelemetry_genai,
  title  = {Semantic Conventions for Generative {AI} Systems},
  author = {{OpenTelemetry Authors}},
  note   = {Development status; accessed 15 July 2026},
  url    = {https://github.com/open-telemetry/semantic-conventions-genai}
}

@misc{owasp_prompt_injection,
  title  = {{LLM01:2025} Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {OWASP Top 10 for LLM Applications, 2025 edition},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{w3c_geolocation,
  title  = {Geolocation},
  author = {{W3C}},
  year   = {2026},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026},
  url    = {https://www.w3.org/TR/2026/CR-geolocation-20260326/}
}

@inproceedings{yao2023react,
  title         = {{ReAct}: Synergizing Reasoning and Acting in Language Models},
  author        = {Yao, Shunyu and Zhao, Jeffrey and Yu, Dian and Du, Nan
                   and Shafran, Izhak and Narasimhan, Karthik and Cao, Yuan},
  booktitle     = {International Conference on Learning Representations (ICLR)},
  year          = {2023},
  eprint        = {2210.03629},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2210.03629}
}

相關內容

將您的地圖變成成長引擎