企業級 Spatial AI 架構會把語言模型、地圖、業務資料、空間計算、權限、工具與操作分開，讓每一項工作都留在真正能執行其規則的層級。回答再流暢，也可能把使用者帶到錯誤的分店。主系統保留身分與交易。空間服務負責地理計算。語言模型則理解請求，並解釋已經由這些系統完成事實 grounding 的結果。
以下章節將說明所有權、授權、憑證、工具、請求路徑，以及三種部署模式。相關閱讀包括 Spatial AI Accuracy Evaluation 與 An Enterprise Spatial AI Pilot。相較於沒有任何 system of record 支持、但聽起來合理的推薦，正確拒絕有時反而是更好的結果。
企業級 Spatial AI 架構重點
- 分離職責： 語言模型負責理解與說明。庫存、權限、路線與交易不應由模型擁有。
- 先授權，再檢索： 在私有脈絡送進模型前，先解析使用者、租戶、物件與欄位。
- 事實維持型別化： 穩定 ID 與營運欄位維持結構化。不要用自然語言取代它們。
- 限制每一項工具： 讀取、地圖、草稿與寫入操作應採用不同的核准規則。
- 衡量工作流程： 關注位置決策與主系統結果，而不只是 token 與延遲。
什麼是企業級 Spatial AI 架構？
客戶可能會問：哪一個服務中心今天可以處理某項工作、位於合約範圍內，而且相對目前路線增加的移動時間最少。這樣一個問題需要意圖層、客戶與合約紀錄、設施資料、服務區域規則、路線計算以及地圖工作流程。正式上線的系統還需要身分、租戶隔離、工具限制、操作檢查、紀錄，以及讓人員核准高影響步驟的位置。把所有這些職責都塞進同一個 prompt，會讓產品既難以保護，也難以修改。模型可以指出下一步應該做什麼，但真正的規則執行應留在模型之外。
左側讓單一模型直接連接資料庫、路由與交易。右側則把身分、資料、空間工具、排序與已驗證操作放在不同層級。這裡展示的是架構模式，而不是 Kaleidr benchmark。
更實際的路徑，不是讓使用者直接與一個可以存取所有系統的模型對話，而是建立一條主系統可以檢查的處理流程。應用程式保留使用者與目前地圖狀態。身分與授權在檢索前完成。之後，意圖理解只要求已核准的資料與空間計算。資格檢查會在排序前移除無效選項。通過驗證的操作更新地圖或工作流程，分析層記錄任務是否成功。這種順序讓團隊可以更換模型、地圖供應商或排序規則，而不需要圍繞一個不透明依賴重新建構整個產品。
每一項事實應該由哪個系統擁有？
架構討論應在選模型之前，先明確指定每一項關鍵事實的擁有者。主系統的身分提供者擁有使用者身分。主應用程式擁有租戶成員資格、產品使用權、工作流程與業務成果。業務系統擁有設施身分、庫存、可用性、價格、預訂狀態與政策。經核准的位置資料來源擁有座標。空間計算層擁有距離、移動時間與 point-in-polygon。用戶端應用程式擁有 viewport 與目前選取的地點。AI 層擁有意圖理解，以及建立在已 grounding 證據上的說明。主系統工作流程擁有最終交易。
| 事實或決策 | 權威擁有者 |
|---|---|
| 使用者身分與租戶 | 主系統身分服務 |
| 庫存、價格、預訂、政策 | 業務 system of record |
| 距離、移動時間、包含關係 | 空間計算 |
| 地圖 viewport 與選取地點 | 用戶端應用程式 |
| 意圖與說明 | 建立在 grounding 證據上的 AI 層 |
| 最終交易 | 主系統工作流程 |
每一欄都有一個主要擁有者。AI 層負責協調意圖與說明。主系統與業務系統仍然是 system of record，而這張圖是架構框架，不是產品清單。
如果團隊無法說明某項關鍵事實究竟由誰擁有，助理通常只會把這個缺口遮住。Kaleidr 關於 grounded Spatial AI 的指南採用相同分工：模型負責理解複合意圖，而庫存、政策、權限與路由仍留在專門保存這些事實的系統中（Kaleidr, 2026）。retrieval 負責找到脈絡。authority 決定哪一個來源可以回答事實問題。被檢索到的文件不會自動成為 system of record。
為什麼一定要先授權，再檢索？
常見錯誤是先檢索私有資料、送進模型，然後才讓模型判斷使用者可以看哪些列。正確順序應該相反。先驗證使用者身分，解析租戶，解析角色與權限，授權物件，最小化欄位，檢索已核准紀錄，最後才把必要脈絡往後傳。權限邊界應該是確定性的，而且可稽核。語言模型不應決定區域經理能否看某個設施、一位客戶能否讀取另一位客戶的位置紀錄，或員工能否取得受限制的工作場所資料。
私有紀錄只有在通過租戶、角色、物件與欄位檢查後才能跨越邊界。下方那條要求模型根據完整資料庫推論權限的路徑保持封鎖。平台憑證與最終使用者授權仍是兩項不同檢查。
平台憑證可以證明應用程式被允許使用某項能力，但它不決定哪一位最終使用者可以讀取哪些列。CORS、憑證驗證、API capability scope 與應用程式層級的使用者授權處理的是不同問題；把它們混在一起會造成錯誤的失敗模式（Kaleidr, 2026）。因此，私有資料路徑應該是一連串疊加檢查，而不是一個「代表全部權限」的 token。
瀏覽器憑證與伺服器憑證應如何分離？
瀏覽器可以被檢查，因此送進瀏覽器的任何內容都應視為執行它的人可以看見。長期秘密、私有業務資料存取、政策執行與 server-to-server 呼叫應放在 backend。瀏覽器可以持有一個可公開、對用戶端安全、且只針對有限地圖能力的憑證。完成身分驗證的產品請求送到主系統 backend，由 backend 套用使用者脈絡、存取私有資料，並使用 server credential 呼叫空間或 AI 操作。兩個執行環境不應共用同一個秘密。
瀏覽器端依照「可能被看見」來設計，只保留有限範圍的用戶端能力。伺服器端保留 server credential、私有紀錄與使用者授權。圖中的勾選只是邊界示意，不代表安全認證。
Kaleidr 目前的 key 文件定義了瀏覽器使用的 publishable key，以及 backend 整合使用的 server key。publishable key 綁定 origin，SDK 會在執行期間把它交換成短期 session，而不是長期把這個字串當作 server bearer 使用。server key 保留在可信任的伺服器上（Kaleidr, 2026）。同一組文件也把 Chat、Editor、Tile 與 Viewer 描述為不同的 surface，分別透過 attach、embed 與 tile 等入口接入，並不是全部採用相同的 mount 方式（Kaleidr, 2026）。應依照每一個 surface 目前的 contract 實作，而不是假設單一憑證與單一 mount 方法可以涵蓋整個技術堆疊。
業務事實與地理資訊應放在哪裡？
Enterprise Spatial AI 的價值，在於它能對公開模型不知道的事實進行推理，例如目前庫存、合作夥伴資格、設施能力、合約涵蓋範圍、臨時關閉與即時可用性。這些事實屬於 system of record。不要讓模型記住今天下午就可能變更的數值。不要把查詢就能回傳的營運欄位拿去做模型 fine-tune。不要把大範圍內部資料庫貼進 system prompt。正確流程是：理解請求、判斷需要哪些已授權紀錄、只檢索最小集合、保留穩定 ID 與型別化欄位、執行硬性篩選、計算地理關係，最後才解釋完成 grounding 的結果。
{
"branch_id": "b_1042",
"open_now": true,
"inventory_status": "in_stock",
"service_eligible": true,
"lat": 38.91,
"lng": -77.22
}
型別化紀錄可以被篩選、寫入紀錄、檢查權限，也能傳給後續操作。寫著某家分店「看起來有營業」而且「可能」有庫存的句子做不到這些。自然語言仍然適合用來說明，但不應取代應用程式可以直接儲存的欄位。
空間計算也應該基於相同理由擁有獨立層級。point-in-polygon、路線距離、駕車時間、步行時間、服務區域成員關係、路線偏離程度，以及能否在指定時間內抵達等分析，如果產品能夠計算，就應由地理服務提供。AI 層可以判斷「需要計算」，實際計算則交給空間服務。之後說明層再解釋這種關係為什麼對目前請求重要。更換語言模型，不應迫使團隊重新定義應用程式如何計算移動時間或包含關係。
硬性條件與軟性偏好應維持分離。診所查詢可能要求接受特定保險方案、18:00 後仍營業、地點目前啟用，而且使用者有權存取該紀錄。只有通過這些規則的候選項，才應依照駕車時間、路線偏離或指定偏好排序。正確順序是 retrieval、授權、資格檢查、空間計算、排序、說明。先排序，再期待模型記得所有條件，會讓無效選項藏在一份看似流暢的 shortlist 裡。零售、房地產、預訂、工作場所與多據點網路都可以使用同樣順序，因為這些限制關係到有效性，而不是產業術語。
工具與操作應如何設限？
Agentic Spatial AI 會讓工具目錄本身成為重要邊界之一。任意 SQL 字串、shell command 或自由格式內部 URL 這類開放工具，本質上是執行環境，而不是業務能力。更適合的是輸入與輸出都明確的窄工具，例如：搜尋合格地點、計算移動時間、讀取分店可用性、顯示地點、請求路線，或建立預訂草稿。每一項工具都可以有自己的權限檢查、驗證、rate limit、紀錄與失敗模式。
當呼叫者已完成授權時，讀取與地圖工具可以執行。草稿會建立可供審查的物件。確認預訂、派發工作或修改紀錄的寫入操作，則需要等待明確的政策 gate。這些層級是架構指引，不是固定的 Kaleidr 權限清單。
讀取紀錄與改變業務狀態屬於不同風險類別。正式環境中的工具目錄可以把能力分成 read、map、draft 與 write。通過授權後，讀取與低影響地圖操作可以自動執行。draft 可以先準備預訂或服務請求供人工審查。確認預訂、派遣車輛或發佈變更的 write，則可能需要使用者確認、第二次政策檢查，有時還需要人工核准。confidence score 不是權限系統。
OWASP 2025 年關於 excessive agency 的指南，把過度功能、過度權限與過度自主性視為不同原因。它建議把 agent 能夠呼叫的 extension 限制在最低必要範圍，優先使用細粒度函式而非開放能力，對高影響操作要求核准，並在 downstream system 真正執行授權，而不是依賴模型判斷是否允許呼叫（OWASP, 2025）。即使如此，應用程式仍應驗證每一個提議的呼叫。對地圖操作而言，應檢查該操作是否允許、place ID 是否屬於已授權結果集、使用者是否有權存取，以及參數格式是否正確。對 write 則應使用更嚴格的檢查。prompt、被檢索文件或格式錯誤的工具結果，都不能變成繞過授權的管道。
OWASP 關於 system prompt 的指南從另一側強調了同樣邊界。system prompt 不是秘密，也不是安全控制。權限分離與授權檢查不能透過 prompt 或其他方式委派給模型（OWASP, 2025）。地圖操作應採用語意化詞彙，例如顯示地點、調整畫面以容納地點、選取地點、繪製路線、清除路線，再由確定性 adapter 把這些操作轉換成 Mapbox、MapLibre、Google Maps 或其他 renderer 的具體行為。模型不應在每一輪都輸出 renderer code。
地圖狀態應如何進入請求？
地圖狀態會改變使用者所說的「這些」「這裡以北」或「第二個選項」實際指什麼。有用的 snapshot 可以包含 viewport bounds、已選取地點 ID、目前可見 result ID、active filter、目前 route ID，以及依任務所需精度核准使用的位置。應明確標示哪些欄位永遠可用、哪些是選填、哪些屬於私有、哪些已獲使用者同意、哪些可能過期、哪些是權威資料、哪些是推論值。不要只是因為地圖可以讀取精確 device location，就在每個請求中傳送它。對於「這些地點中哪一個營業較晚」這類問題，最可靠的參照不是截圖，而是目前結果集合中的穩定 ID。Kaleidr 關於 map-aware assistant 的指南也明確指出這個邊界：共享 viewport、selection、filter 與 result ID，不要讓模型從像素中推論應用程式狀態（Kaleidr, 2026）。
協調層可以決定某個請求是否需要業務資料 retrieval、路由、地圖操作、釐清問題，或證據摘要。這一層可以由模型驅動、規則驅動，也可以混合兩者。但它不應是唯一的安全邊界。協調層可以判斷是否需要查詢可用性。授權層則回答：這個呼叫者是否有權針對這些紀錄檢索可用性。協調層可以判斷是否要開始預訂。交易層則回答：使用者是否已確認，以及該操作是否有效。即使模型出錯，這種分離仍然有效。
租戶隔離也屬於同一路徑。在查詢前解析已驗證身分、租戶、角色與允許物件，並把查詢 scope 限制在該租戶。不要依賴一個 prompt 告訴模型「不要提到其他租戶」。除非應用程式有明確的跨租戶目的與政策，否則模型不應接收到其他租戶的資料。tenant-scoped query、物件檢查、欄位最小化，以及經過遮罩的紀錄才是真正控制措施。prompt 中的一句話不是。
一個正式環境請求如何穿過整套技術堆疊？
完整請求可以畫成十二個階段，但並非每一個請求都需要全部階段。先取得已驗證的使用者、租戶、地圖狀態與工作流程狀態。理解任務、地理條件、業務條件與預期操作。在進行任何私有檢索前，先解析允許使用的資料來源、紀錄、欄位、工具與操作。
檢索已授權事實與 canonical place ID，然後計算距離、移動時間、包含關係或服務區域成員關係。移除未授權、不可用、已關閉或區域外的候選項，再針對剩餘候選排序。說明完成 grounding 的結果，提出語意化地圖或工作流程操作，並在模型之外驗證該操作。執行操作後，再記錄決策與結果。
這些階段從地圖狀態與意圖開始，經過授權、grounding、地理計算、資格檢查與排序，再進入說明、提議操作、驗證、執行與衡量。簡單的「顯示這個地點」請求可以略過 retrieval 與排序。服務推薦則可能使用幾乎整條路徑。
失敗處理也是同一條路徑的一部分。如果業務資料不可用，不要編造可用性。應明確說明目前無法驗證可用性。如果路由服務不可用，就不要聲稱已依移動時間排序；若使用直線距離替代，應清楚標示為 fallback。如果沒有任何候選項通過硬性規則，應回傳 no result，而不是默默放寬關鍵條件。如果授權失敗，不要讓模型解釋它從未收到的私有資訊。如果模型不可用，確定性搜尋與篩選仍可以繼續支援地圖功能。如果工具結果格式錯誤，就在驗證階段拒絕。當產品沒有明確 degraded mode 時，語言模型很容易無意間變成「缺少基礎設施」的 fallback。
人工核准應依照影響程度，而不是每一個按鈕都套用相同規則。顯示三個公開地點屬於低影響。確認預約、派遣車輛、修改設施紀錄或送出付費預訂則不是。可以把搜尋、retrieval 與路線預覽歸類為低影響；已儲存偏好或草稿歸為中等影響；購買、派遣、營運寫入或權限變更歸為高影響。接著再分別對應自動執行、使用者確認或獨立核准。NIST 的 AI Risk Management Framework 是自願採用的框架，目的是把可信性納入 AI 產品的設計、開發、使用與評估。NIST 同一頁面也說明 AI RMF 1.0 正在修訂（NIST, 2023）。該框架是產品自行做風險決策時的背景，不是 Kaleidr 的控制清單。
控制平面位於哪裡？
請求路徑負責即時工作：使用者、授權、retrieval、空間工具、模型、操作與回應。控制平面決定這條路徑允許以什麼方式執行。憑證、scope、模型選擇、prompt、工具政策、資料來源設定、rate limit、環境、評估套件、feature flag 與稽核設定都放在這裡。兩者分離後，團隊可以不重寫每一條對話流程就修改政策。停用一個 write tool 不應需要設計新的介面。控制平面是管理這些設定的一種架構模式，圖中並沒有宣稱某個產品一定提供所有方塊。
上排是設定：憑證、scope、模型、prompt、工具政策、資料來源、限制、評估、flag 與稽核設定。下排是即時請求。政策箭頭指向它所控制的階段，因此團隊可以修改規則，而不必重寫整條路徑。
可觀測性應追蹤決策，而不只是 token 費用。值得記錄的事件包括：意圖解析完成、授權通過或拒絕、retrieval 完成、因資格檢查移除候選、空間計算完成、排序完成、no-result 回應、工具被提議、工具被拒絕、地圖操作已執行、地點已選取，以及工作流程完成。這些名稱是一種需要設計的模式，不是平台自動輸出的固定清單。它們回答的是實務問題：錯誤來自地點解析還是排序？使用者是否拒絕一份其實有效的 shortlist？某個市場是否產生更多空結果？工具呼叫是因為權限失敗，還是因為參數格式錯誤？使用者選取地點後，是否完成主系統任務？NIST AI RMF core 指出，應記錄 test、evaluation、verification 與 validation 中使用的測試集、指標，以及工具細節（NIST, 2023）。對 Spatial AI 而言，文件化測試應涵蓋地理與業務決策，而不只是生成的句子。
空間分析與主系統結果回答的是不同問題，架構應使用穩定 ID 把兩者連接起來。Kaleidr Analytics 目前描述了 reach、view、engagement、受眾位置與活動、每張地圖的 session、view、interaction，以及空間模式的 dashboard（Kaleidr, 2026）。預訂、購買、qualified lead、派遣與已完成服務，仍保留在真正擁有它們的主系統中。recommendation ID 可以指向 selected place ID，再指向 host workflow ID，最後連到結果。公開的 Analytics 資料並沒有宣稱所有業務 conversion 都會自動被擷取。
三種部署模式是什麼？
三種模式可以涵蓋大多數企業部署，但沒有任何一種模式永遠最好。公開地圖助理適合旅遊、探索、編輯型地圖與活動搜尋。瀏覽器地圖使用可公開的 client capability、map-aware AI、公開或已核准的地點資料，以及空間工具，最後回傳地圖操作。因為工作流程大多處理公開資訊，所以資料邊界較單純。經過驗證的業務助理適合客戶入口網站、考量庫存的門市選擇、房地產、合作夥伴網路與私人設施。瀏覽器連接主系統登入與主系統 backend，backend 先套用 tenant 與 object 授權，之後私有資料、空間工具與說明才回到地圖。具備業務操作能力的 spatial agent 適合預訂、派遣與營運工作流程。這條路徑會增加型別化 tool proposal、確定性 validation、在高影響情況下所需的 confirmation、transaction system 與結果 audit。第三種模式會改變業務狀態，因此需要最嚴格的 governance。
公開模式只處理已核准的公開地點。驗證模式把私有紀錄保留在主系統後方。操作模式則在交易前增加 validation 與 confirmation。圖中的範例 place card 僅作示意，並不是 Kaleidr 的實測結果。
Kaleidr 在這套架構中位於哪裡？
Kaleidr 目前把 Enterprise 描述為面向產品團隊的 location-intelligence infrastructure，提供 inference API、ranking、Analytics，以及主系統可以加入的 SDK surface（Kaleidr, 2026）。開發者文件在同一個 SDK 中列出四種 surface。Chat 把 AI interaction 接到主系統已經運行的地圖。Editor 在產品內 mount 地圖編輯。Tile 提供設計過的 basemap。Viewer 發布地圖供 embed。現行 Chat 文件列出 Mapbox、MapLibre 與 Google Maps 作為主系統自有地圖的整合路徑（Kaleidr, 2026）。主系統繼續保留最終使用者、身分驗證、tenant 授權、私有業務系統、工作流程規則、交易與業務成果。Kaleidr 加入所需的空間 surface，但不取代主系統技術堆疊中仍具權威性的系統。
主系統這一列保留使用者、tenant 授權、工作流程、私有系統、交易與結果。Chat、Editor、Tile、Viewer 與 platform API、Analytics 並列。憑證標示遵循公開瀏覽器與伺服器的分離方式，圖中沒有顯示真實秘密資訊。
哪些錯誤常常要到正式環境才會暴露？
把模型直接連接到所有系統會造成過度權限，也更難定位究竟是哪一層失敗。把 prompt 當成授權層也會因同樣原因失敗：prompt 可以引導措辭，卻無法確定性地允許或拒絕某一筆紀錄。把整個內部資料庫送進 context 違反最小化原則。把硬性篩選與排序混在一起，會讓不合格地點繼續留在平均結果中。要求模型估算原本應由空間服務計算的距離，是用語言流暢度取代真正計算。一個沒有任何限制的工具，或一個繼承 read tool 政策的 write tool，會讓推薦取得交易等級的權限。把地圖當成圖片會遺失下一輪需要的穩定 ID。只監控延遲與 token 成本，會漏掉地點解析、資格檢查、路由、排序、工具失敗與主系統結果。單一模型 benchmark 無法證明組裝完成的工作流程已經可以正式上線。
NIST 的 TEVV-Athlon framework——NIST AI 200-2——initial public draft 於 2026 年 8 月 7 日公布，並開放意見至 2026 年 10 月 6 日。該文件把評估描述為證明系統達到個人或組織目標的證據，並強調測量應依應用與其真實世界影響調整，包括 agentic system（NIST, 2026）。這份文件仍是徵求意見中的草案，也不是 Kaleidr 的控制清單。對這套架構而言，評估脈絡應是位置依賴決策本身：意圖、授權、grounding、地理、資格、排序、工具、操作、失敗處理，以及主系統結果。
企業級 Spatial AI 架構如何成為發布門檻？
在 pilot 往正式環境推進前，先確認所有擁有者。在工作流程需要的地方完成使用者身分驗證，租戶成員關係則在模型之外解析。每一個關鍵欄位都應有權威來源；私有 retrieval 在推論前執行；欄位最小化；穩定 ID 在跨層傳遞時持續保留。地理服務執行產品宣稱可以提供的計算，評估使用的 tolerance 應事先記錄。工具必須維持窄範圍，read 與 write 分離，參數經過驗證，高影響操作可以被確認並稽核。瀏覽器憑證與伺服器憑證保持分離，scope 維持有限，環境也保持隔離。團隊應能看見整條決策鏈，並把地點選取連到主系統結果。不可用資料、空候選集合與 degraded mode 都應明確處理；關鍵操作應 fail closed，而不是編造事實。探索 Kaleidr Enterprise，可了解如何在產品既有技術堆疊旁加入 spatial intelligence API、ranking、Analytics 與 SDK surface。實作前請 閱讀 Kaleidr 開發者文件，確認 Chat、Editor、Tile、Viewer、key 與 scope 的現行 contract。
常見問題
什麼是企業級 Spatial AI 架構？
企業級 Spatial AI 架構是一種系統設計，用來連接語言模型、地圖、地理服務、業務資料、權限、工具、操作與分析，並把每一項責任留在真正能執行相關規則的層級。
語言模型應該直接存取業務資料庫嗎？
通常不應把它當成不受限制的介面。先授權目前使用者，只檢索任務需要的最少紀錄，保持欄位結構化，並暴露範圍清楚的窄工具。開放式資料庫存取會讓模型變成權限引擎。
語言模型應該負責什麼？
模型適合處理自然語言意圖、已核准能力之間的協調，以及說明已完成 grounding 的結果。授權、交易、業務事實與地理計算，應留在專門為這些職責設計的系統中。
平台驗證與使用者授權有什麼差別？
平台驗證確認某個應用程式可以使用平台能力。使用者授權則決定哪一個人或租戶可以存取某筆紀錄或執行某項業務操作。一種檢查不能取代另一種。
Spatial AI 應該使用 retrieval-augmented generation 嗎？
retrieval 可以提供相關文件或紀錄，但 retrieval 本身不能建立 authority。庫存、可用性、價格、權限與服務區域成員關係，仍應綁定各自的 system of record 與確定性規則。
Spatial AI 工具應該如何保護？
使用窄函式、最小權限、基於使用者脈絡的授權、參數驗證、rate limit、監控，以及針對高影響操作的獨立核准。不要把模型或 system prompt 當作授權機制。
Spatial AI 操作需要人工核准嗎？
核准應依影響程度決定。顯示地點這類低風險地圖操作可以自動執行。購買、預訂、派遣、管理寫入與權限變更，則可能需要明確確認或獨立核准。
地圖助理應如何使用目前的地圖？
傳遞結構化狀態，例如 viewport bounds、已選取 place ID、active filter、可見 result ID、route ID，以及符合任務所需精度的位置。既然已有結構化狀態，就不要要求模型從截圖推論應用程式狀態。
Spatial AI 可以和既有地圖搭配使用嗎？
可以。Spatial AI 層可以接入主系統已經運行的地圖與應用程式。Kaleidr 目前的 Chat 文件說明如何把 conversational Spatial AI 接到主系統運行的 Mapbox、MapLibre 或 Google Maps 實例。
團隊在擴大規模前應如何評估這套架構？
應評估整個組裝完成的工作流程：意圖、授權、grounding、地理計算、資格、排序、說明、工具、操作、失敗處理與業務成果。通用語言模型 benchmark 無法取代這項測試。
參考資料
- Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
- Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
- Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
- Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
- OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
- Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
- National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
- National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
- Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
- Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
- National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
- Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
- Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling
@misc{kaleidr_grounded_architecture_2026,
title = {Grounded Spatial AI for Business Data},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}
@misc{kaleidr_map_api_auth_2026,
title = {Map API Authentication},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/map-api-authentication}
}
@misc{kaleidr_get_api_key_2026,
title = {Get an API Key},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://docs.kaleidr.com/get-an-api-key}
}
@misc{kaleidr_docs_intro_2026,
title = {Introduction},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
url = {https://docs.kaleidr.com/}
}
@misc{owasp_llm06_2025,
title = {LLM06:2025 Excessive Agency},
author = {{OWASP Gen AI Security Project}},
year = {2025},
note = {Accessed September 30, 2026},
url = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}
@misc{owasp_llm07_2025,
title = {LLM07:2025 System Prompt Leakage},
author = {{OWASP Gen AI Security Project}},
year = {2025},
note = {Accessed September 30, 2026},
url = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}
@misc{kaleidr_map_aware_2026,
title = {How to Build a Map-Aware AI Assistant},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}
@misc{nist_ai_rmf_2023,
title = {AI Risk Management Framework},
author = {{National Institute of Standards and Technology}},
year = {2023},
note = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
url = {https://www.nist.gov/itl/ai-risk-management-framework}
}
@misc{nist_ai_rmf_core_2023,
title = {AI RMF Core},
author = {{National Institute of Standards and Technology}},
year = {2023},
note = {Measure 2.1. Accessed September 30, 2026},
url = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}
@misc{kaleidr_analytics_architecture_2026,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_enterprise_architecture_2026,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_chat_docs_2026,
title = {Chat},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://docs.kaleidr.com/chat}
}
@techreport{nist_ai_200_2_2026,
title = {The TEVV-Athlon Framework for Evaluating AI Systems},
author = {{National Institute of Standards and Technology}},
institution = {National Institute of Standards and Technology},
number = {NIST AI 200-2},
year = {2026},
note = {Initial public draft, announced August 7, 2026},
url = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}