空間脈絡工程：地點感知 AI

空間脈絡工程是一種在模型回答前，選出它可以使用的地點、時間、路線與業務事實的實務。提示可以詢問最近的充電站，但真正有用的回答仍需要路線、當下時間，以及主機選擇分享的事實，而且只能使用這些事實。空間服務負責計算地理關係，模型則負責解釋結果。

什麼是空間脈絡工程？

一篇 2025 年的綜述整理了 1,400 多篇研究論文，把脈絡工程定義為一門超越提示設計、系統化最佳化語言模型所接收資訊的學科 (Mei et al., 2025)。這篇綜述把這項工作分為脈絡擷取與生成、脈絡處理與脈絡管理。空間脈絡工程把同樣的方法套用到地點問題。承載資料必須說明對象在哪裡、事實在什麼時間有效、哪一條路線或哪個區域重要，以及呼叫端可以使用哪些業務紀錄。

脈絡不是越多越好。Liu 等人發現，當相關資訊位於輸入的開頭或結尾時，語言模型的表現往往最好；而當模型必須使用長脈絡中段的資訊時，表現會明顯下降 (Liu et al., 2024)。因此，空間脈絡封包應保持精簡：符合資格的地點、已計算的距離或包含關係結果、這些結果的資料新鮮度，以及呼叫端可以執行的動作。把目前地圖檢視裡的所有圖層全部塞進去，並不符合這個原則。

實務指南也已經在使用這個術語。Vercel 的開發者指南提出四種模式：擷取、記憶、壓縮與工具脈絡 (Vercel, 2026)。地圖產品可以同時使用四者，但任何一種都不能取代空間計算。擷取可以帶回政策段落，記憶可以帶回先前偏好，壓縮可以移除目錄中不需要的內容。工具脈絡可以保存路線或包含關係檢查結果，模型應解釋這些結果，而不是自行編造替代數值。

提示與脈絡有什麼不同？

提示提出問題，脈絡則是回答前已組裝好的證據。「替一條配送路線找最近的充電站」是一條指令，但只靠這條指令，可能產生一份通用的充電站清單，忽略車輛、時間與實際開放的道路。圖中把這種資訊不足的回答，與一個包含地點、時間、路線、業務狀態、權限與地圖狀態的封包做比較。

左側是一條短指令與關於附近充電站的通用回答。右側在產生地點感知回答前，加入地點、時間、路線、業務狀態、權限與地圖狀態。地點 ID、2024 年 6 月時間戳記、5.2 km 標記與充電站圖釘都是示例標籤。右側封包只是參考草圖，不是 Kaleidr 的請求格式。

資訊不足的回答在文法上沒有錯，但在實務操作上不可用，因為「附近」沒有起點、沒有最大繞行範圍，也沒有規則說明車隊可以使用哪些充電站。圖中資訊較完整的一側仍使用示例識別碼，因此那些值不是即時查詢結果。正式環境中的封包應攜帶主機自己的 ID，以及空間服務自己的計算數值。

為什麼擷取只是其中一個資料來源？

擷取會從文件、政策、說明與說明文章中擷取文字段落。這些段落可以解釋規則，但無法告訴調度人員某個停靠點是否在服務區域內，因為多邊形檢查是一項計算，不是一段文字。空間脈絡會保留擷取到的文字，同時加入結構化業務事實、授權結果、目前地圖狀態與空間計算結果。

左欄把文件、政策文字、說明與知識擷取成段落。右欄在這些文字上加入結構化業務事實、授權、地圖狀態與空間計算。圖中的結果是一個用於地點感知回答的決策封包。畫出的路線與圖釘只是示例圖像，不是實測行程。

如果團隊只停在擷取文字，聽起來可能很有根據，但仍可能對地圖做出錯誤判斷。政策段落可以說明晚間配送需要有人值守的地點，但只有營業時間資料、包含關係檢查與呼叫端權限，才能判斷該地點現在是否符合條件。圖中的決策封包就是這些資訊匯合的地方。

為什麼目前證據必須優先於過時的記憶？

記憶適合保存不容易失效的偏好，例如固定倉庫或語言。但它不適合作為交通、臨時關閉、庫存，或「今天誰可以查看某個私人地點」的事實來源。上週記住的「最佳停靠點」可能與空間服務剛剛回傳的路線衝突。兩者不一致時，應優先採用目前計算與目前授權，而記憶仍應標示為偏好，不應被當成事實。

同樣規則也適用於工作階段稍早產生的摘要。壓縮後的摘要可能漏掉臨時關閉或已撤銷的權限。下一輪應重新讀取會改變的欄位；如果摘要沒有時間戳記，呼叫端就不應依據它執行動作。資料新鮮度應當作資料寫入封包，而不是期待先前答案仍然正確。

為什麼地點身分要先於搜尋？

兩筆紀錄可以同名，但仍然代表不同地點。「市中心那間門市」只是一段搜尋文字，不是 ID。封包應攜帶來自主機自身系統的穩定地點 ID，以及空間服務要使用的座標或幾何；顯示名稱應只是標籤，而不能當作主鍵。沒有這個 ID，後續輪次無法區分改名後的門市與另一間門市，引用也無法指向真正符合資格的紀錄。

封包應攜帶哪一種幾何？

幾何必須符合問題。查詢最近充電站需要點與路線；查詢服務區域需要多邊形與包含關係結果；查詢廊道則需要線與到該線的距離。GeoJSON 定義了幾何物件，而點是其中一種幾何類型，因此封包可以直接標明類型，而不必把形狀藏在文字敘述裡 (IETF, 2016)。如果判斷依賴多邊形，卻只傳點，後續說明可能看起來很精確，但真正需要的檢查其實從未執行。

為什麼視埠不是權限？

一個地點即使出現在鏡頭範圍內，也可能仍然禁止使用。圖中在同一個檢視裡放了三個示例地點：兩間呼叫端可以使用的公開門市，以及一個雖然圖釘可見、但被排除在脈絡之外的私人設施。可見性只是提示使用者正在看什麼。授權則是另一項獨立檢查，用來決定請求可以包含什麼。

虛線框是目前地圖檢視，裡面有三個示例地點。Public Store A 與 Public Store B 被標示為已授權。Private Facility C 即使圖釘出現在畫面上，仍不會進入模型脈絡。視埠提供位置脈絡，而獨立的權限檢查決定哪些內容可以使用。

相同區分也適用於主機地圖。Kaleidr 開發者文件說明，Chat 會加入自己的標記、移動鏡頭並繪製路線，但不會修改頁面的圖層、來源或標記，也不會把這些物件傳給 Kaleidr (Kaleidr, 2026)。畫面上的圖釘不是授權。哪些事實可以跨過邊界由主機決定，封包應記錄這項決定，而不是假設鏡頭已經替代權限判斷。

空間服務首先應計算什麼？

先讓空間服務計算數字，再讓模型解釋。圖中顯示路線繞行、是否位於服務區域內，以及旅行時間，這些結果共同支持「為什麼某間門市符合條件」的說明。旁邊另一個框則明確拒絕猜測的旅行時間。模型不適合作為距離、包含關係或抵達時間的事實來源，因為這些數值來自道路網路、多邊形與時間。

空間服務回傳 6 分鐘路線繞行、真的服務區域內檢查，以及 14 分鐘旅行時間。接著說明為什麼圖中的 Store 104 被選為停靠點。被拒絕的框展示語言模型沒有使用服務結果，而自行編造旅行時間。分鐘數、門市編號與被引用的猜測值都是圖中的示例標籤。

說明本身仍然有價值。空間服務回傳符合條件的停靠點後，模型可以用呼叫端的語言，說明哪一項已計算事實讓該停靠點成為合適選擇。說明應引用服務結果，而不是取代它。圖中的門市編號與分鐘標籤只是標籤，不是 Kaleidr 基準測試。

什麼樣的脈絡封包才算夠精簡？

封包應夠小，方便人工閱讀，同時也要夠完整，讓決策不依賴隱藏表格。圖中從門市資料庫、庫存、營業時間、路徑規劃與權限等原始系統開始，最後壓縮成一個很短的物件：任務、少量候選地點、資格判定、路線繞行、資料新鮮度時間戳記，以及允許執行的動作。任何沒有影響資格判定的內容，都可以繼續留在來源系統。

門市資料庫、庫存、營業時間、路徑規劃與權限的原始紀錄進入脈絡建構器。建構器輸出一個短封包，包含任務、少量候選門市、資格標記、路線繞行、時間戳記以及允許的動作。這個封包應夠小，方便檢查，同時又夠完整，可以支援一次決策。門市 ID、距離與 2024 年 6 月時間戳記都是示例標籤，JSON 也是參考草圖，而不是 Kaleidr API。

關於長脈絡的這項研究結果，正是應該省略無關資訊的理由。候選地點擷取可以先寬後窄：不符合資格的地點在模型看到之前就被移除，封包則保留原因，例如門市已關閉，或包含關係檢查失敗。Kaleidr 的公開聊天請求比這張草圖定義的契約更窄，下一節會說明該請求實際攜帶哪些內容。團隊不應把圖裡的 JSON 直接 POST，好像平台真的定義了這種物件。

一個參考管線包含什麼？

實用管線應明確每個風險由哪個階段負責。依序解析任務、識別呼叫端、檢查授權、設定地理範圍、擷取候選地點、附加業務狀態、執行空間計算、套用資格判定、組裝封包、把封包送給模型、執行地圖動作、重新驗證易變欄位，並記錄發生的事情。圖上方再加入四個控制項：來源、新鮮度規則、政策與追蹤 ID。

這條流程從任務解析開始，經過身分識別、授權、地理範圍、候選擷取、業務狀態、空間計算、資格判定、脈絡封包、模型、地圖動作、重新驗證與觀測。來源、新鮮度、政策與追蹤 ID 位於上方，作為每個階段的控制項。這張圖是團隊設計自己脈絡建構器時使用的參考管線。下方畫出的路線只是示例圖像。

這個順序是設計輔助，不是 Kaleidr 產品的執行順序。有些團隊可能會把候選地點擷取與空間計算合併。應持續清楚呈現的階段包含授權、計算、資格判定，以及在指派停靠點等動作前立即重新驗證。適用於業務資料的有依據的空間 AI 是 Kaleidr 關於授權、擷取與排序的相關指南。

Kaleidr 在哪裡劃定脈絡邊界？

在主機地圖上，這條邊界是明確的。支援的地圖指南介紹如何把 Kaleidr Chat 接到 Mapbox GL JS、MapLibre GL JS、Google Maps 與 Leaflet 等函式庫；Google Maps 金鑰仍只存在於頁面與 Google 之間，因為 Kaleidr 不會收到該金鑰 (Kaleidr, 2026)。圖釘、移動到某個地點與路線都是面板新增的繪圖內容，並不是主機私人資料表的副本。

主機應用程式保留使用者、私有資料、庫存、政策、自訂圖層與業務動作。圖中只有明確的一小部分資訊會跨越邊界，例如已授權位置、地圖縮放級別、工作階段與核准事實。右側 Kaleidr Chat 根據這部分共享內容解析地點、規劃路線並執行地圖動作。頁尾是圖中標籤，門市名與車輛名也只是示例。單純接上 Chat 並不會自動傳送主機的圖層或業務系統。

Platform API 對聊天請求也定義相同邊界。messages 代表對話，location 物件是用來理解「這附近」的地圖中心，map_zoom 是縮放級別，lang 是回覆語言。同一頁說明，沒有系統指令、角色設定、工具或呼叫端自身脈絡的欄位；未知欄位會被接受但忽略。app_snapshot 與 auto_actions 會被接受，但並不需要，因此文件建議不要傳入 (Kaleidr, 2026)。

上傳業務資料走的是另一條獨立路徑。組織自己的業務資料若要上傳並用於 AI 回答，只能使用 Enterprise；基於這些上傳資料的以金鑰取得的回答也只有 Enterprise 支援，How Kaleidr works 對此有明確說明。配套文章 如何建立地圖感知 AI 助理 則說明團隊如何圍繞同樣的邊界建立助理。

同一個頁面如何更容易被找到與引用？

介紹這套實務的頁面應該容易引用。圖中把這個目標拆成一般搜尋、問答引擎與生成式引用。搜尋需要規範詞組、一組相關方法，以及指向支援性指南的連結。問答引擎需要直接定義、幾個具體問題，以及類似擷取與空間脈絡封包的比較。

圖中央是空間脈絡工程，周圍是搜尋、問答引擎與生成式引用三個管道。搜尋需要規範關鍵字、主題集群與內部連結。問答引擎需要直接定義、常見問題與比較。生成式引用需要原創框架、有說明的結構、失敗清單與引用來源，而且這些方框都不代表排名承諾。

圖中的方框是內容撰寫檢查清單，不是流量保證。Kaleidr 不負責讓頁面取得排名，這張圖也沒有回報任何測量值。頁面真正能做的是，在同一處給出清楚定義，把脈絡封包展示成參考草圖而不是傳輸格式，並引用支撐這些主張的標準與文件。如此一來，讀者可以分辨哪一句是在下定義，哪一句是在說明產品限制。

團隊下一步該做什麼？

先針對一個真實任務寫出脈絡封包，再去修改提示。包含地點 ID、時間、幾何類型、空間計算結果，以及允許每一項事實進入的權限。接著把這份清單與主機今天實際能傳送的聊天請求對照：對話、地圖中心、縮放級別與語言，並沒有一個供主機私有脈絡使用的欄位。如果回答必須依賴上傳的業務資料，就從 Kaleidr Enterprise 開始。

註：Kaleidr 在創意與開發工作流程中使用 AI 輔助工具進行圖像製作、內容優化與研究。

常見問題

空間脈絡工程和提示工程是同一件事嗎？

不是。提示工程改變的是指令文字。空間脈絡工程改變的是這條指令可以使用的證據，包括地點、時間、路線或區域，以及呼叫端可以查看的業務事實。就算句子寫得更好，也無法補出空間服務從未計算過的包含關係結果。

接上 Kaleidr Chat 會讀取主機地圖的圖層嗎？

不會。在 Chat 執行於主機文件的頁面裡，Chat 會加入自己的標記、移動鏡頭並繪製路線。Chat 不會修改頁面的圖層、來源或標記，也不會把這些物件傳給 Kaleidr。除非另有獨立 Enterprise 方案用於上傳業務資料，否則私有資料表仍留在邊界的主機端。

公開 Chat 請求可以攜帶自訂脈絡封包嗎？

文件化的請求只攜帶對話、用於地圖中心的位置、可選縮放級別與語言。沒有系統指令、角色設定、工具或呼叫端自身脈絡的欄位。app_snapshot 與 auto_actions 會被接受但並不需要，因此團隊不應把它們視為本指南中畫出的封包。未知欄位會被接受但忽略。

為什麼行程時間應留在空間服務裡？

行程時間取決於道路網路與時間，猜出的分鐘數可能和服務剛剛計算的路線衝突。計算圖中的拒絕框，用一段示例引用呈現這種失敗模式，而不是即時結果。數字應留在空間服務，由模型負責解釋。

References

1. Mei, L., et al. A Survey of Context Engineering for Large Language Models. A review of more than 1,400 papers that treats context engineering as more than prompt design and splits it into retrieval and generation, processing, and management. arXiv:2507.13334. 2025. https://arxiv.org/abs/2507.13334
2. Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. Performance is often highest when relevant information is at the start or end of the input and degrades significantly in the middle of long contexts. 2024. https://doi.org/10.1162/tacl_a_00638
3. Vercel. What is context engineering? A developer's guide. A practitioner guide naming four patterns: retrieval, memory, compression, and tool context. Accessed October 22, 2026. https://vercel.com/i/context-engineering
4. IETF. RFC 7946: The GeoJSON Format. GeoJSON defines a geometry object, and a Point is one of the geometry types. 2016. https://www.rfc-editor.org/info/rfc7946
5. Kaleidr Developer Docs. How Kaleidr works. Chat adds its own markers, moves the camera, and draws routes, and does not change the page's layers, sources, or markers or send them to Kaleidr. Uploaded business data for AI answers, and key-backed answers that draw on that data, are Enterprise only. Accessed October 22, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
6. Kaleidr. Grounded Spatial AI for Business Data. A related guide covering authorization, retrieval, ranking, evaluation, and a narrow pilot. Accessed October 22, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
7. Kaleidr Developer Docs. Supported maps. Attach targets include Mapbox GL JS, MapLibre GL JS, Google Maps, and Leaflet. A Google Maps key stays between the page and Google; Kaleidr does not receive it. Accessed October 22, 2026. https://docs.kaleidr.com/chat/supported-maps
8. Kaleidr Developer Docs. Platform API endpoints. The chat request carries the conversation, a map-center location, optional zoom, and a language. There is no field for system instructions, a persona, tools, or the caller's own context. app_snapshot and auto_actions are accepted and not needed. Accessed October 22, 2026. https://docs.kaleidr.com/platform-api/endpoints
9. Kaleidr. Map-Aware AI Assistant: How to Build One. A companion guide for building the assistant around a map. Accessed October 22, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
10. Kaleidr. Kaleidr Enterprise. The enterprise page for spatial AI integrated with a customer's own data. Accessed October 22, 2026. https://kaleidr.com/enterprise

References in BibTeX

@misc{mei_context_engineering_survey_2025,
  title         = {A Survey of Context Engineering for Large Language Models},
  author        = {Mei, Lingrui and others},
  year          = {2025},
  eprint        = {2507.13334},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2507.13334}
}

@article{liu_lost_in_the_middle_2024,
  title   = {Lost in the Middle: How Language Models Use Long Contexts},
  author  = {Liu, Nelson F. and Lin, Kevin and Hewitt, John and Paranjape, Ashwin and Bevilacqua, Michele and Petroni, Fabio and Liang, Percy},
  journal = {Transactions of the Association for Computational Linguistics},
  volume  = {12},
  pages   = {157--173},
  year    = {2024},
  doi     = {10.1162/tacl_a_00638}
}

@misc{vercel_context_engineering_2026,
  title  = {What is context engineering? A developer's guide},
  author = {{Vercel}},
  year   = {2026},
  url    = {https://vercel.com/i/context-engineering}
}

@misc{ietf_rfc7946_2016,
  title  = {RFC 7946: The GeoJSON Format},
  author = {{IETF}},
  year   = {2016},
  url    = {https://www.rfc-editor.org/info/rfc7946}
}

@misc{kaleidr_how_it_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}

@misc{kaleidr_grounded_spatial_ai_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_supported_maps_2026,
  title  = {Supported maps},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/chat/supported-maps}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr Developer Docs}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_map_aware_assistant_2026,
  title  = {Map-Aware AI Assistant: How to Build One},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{kaleidr_enterprise_2026,
  title  = {Kaleidr Enterprise},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/enterprise}
}