Spatial AI 延遲

Spatial AI 延遲是從提出位置問題到出現第一個有用地圖回饋所需的時間，而且它不是單一的模型計時器。等待時間可能包含授權、擷取、路線計算，以及語言模型產生的詞元。即使模型很快，也可能排在緩慢的路線計算之後。反過來，即使最後一段文字生成得較慢，只要合格地點或路線先出現，體驗仍然可以顯得反應迅速。

Spatial AI 延遲包含哪些部分？

一個位置問題會經過多個計時階段，把它們平均成單一的「AI 延遲」會掩蓋使用者實際等待的環節。瀏覽器回應速度指頁面對點擊做出反應的速度。首次進度時間是介面顯示工作已開始的時間點。首個詞元時間是生成流程產生第一個詞元的時間點。首次空間動作時間是合格地點或路線開始可見的時間點。末個詞元時間是生成完成的時間點。完成動作時間是使用者可以依據結果採取行動的時間點。

首次進度時間、首次空間動作時間與完成動作時間是 Kaleidr 用來描述產品體驗的名稱。這三個名稱不是 Web 標準。首個詞元時間與末個詞元時間則是已建立的模型指標。

六張卡片把瀏覽器回應與請求的其他部分分開。首次進度時間、首次空間動作時間與完成動作時間被標示為 Kaleidr 的編輯性指標。首個詞元時間與末個詞元時間被標示為已建立的模型延遲指標。下次繪製前的互動是瀏覽器指標。任何一張卡片都沒有報告 Kaleidr 的實際量測結果。

Google 的 Web 效能指南把 Interaction to Next Paint（下次繪製前的互動）視為實際環境中的回應性指標，並把頁面載入第 75 百分位上的 INP 不高於 200 毫秒視為良好（web.dev, 2025）。這個門檻衡量的是點擊後的下一次繪製，而不是路線計算或生成段落。頁面可以達到這個標準，卻仍讓使用者等待擷取。模型呼叫較慢本身也不會讓 INP 變差。兩個預算應分開呈現，否則團隊可能會透過調整一個從未位於關鍵路徑上的點擊處理器來「修正 AI 延遲」。

為什麼關鍵路徑很重要？

關鍵路徑是必須依序完成的步驟中最長的一條鏈。彼此獨立的查詢可以重疊執行。需要同時取得已解析地點與業務事實的路線計算，只有在兩者都準備好後才能開始。把這些查詢串行化會加總它們的時間。並行執行只能消除重疊部分，並不會讓路線計算本身更快。在顯示任何私有記錄之前，授權仍然必須先完成。

上方一列會等每個步驟完成後再開始下一步。下方一列同時執行地點查詢與業務資料讀取，接著把兩者匯合給路線與模型使用。圖中描述的是等待結構，沒有報告經過量測的加速結果；路線仍然依賴這兩次查詢。

有用的追蹤應記錄時段，而不是產品名稱。Geocoding、業務資料讀取、路線計算、排序與生成都可能在不同問題中成為最慢的時段。Spatial AI Observability 是相關指南，用來分別記錄這些時段，包括結果為空時的結構化原因。如果不做這種拆分，一個緩慢的下午可能看起來像是「模型變差了」，實際上只是路線服務變慢。

為什麼第一個詞元不是第一個地圖結果？

首個詞元時間與末個詞元時間回答的是不同問題，而且兩者都不等於地圖變得有用的時間點。Azure OpenAI 把兩者的關係描述為：末個詞元時間等於首個詞元時間，加上詞元之間的時間乘以生成詞元數量（Microsoft, 2026）。同一篇文章還指出，每個提示詞元增加的時間相較每個生成詞元很少，而串流只是讓詞元一準備好就返回，並不會改變生成所有詞元所需的總時間。OpenAI 的延遲指南提供一個相關經驗法則：輸出詞元大約減半時，延遲也可能大約減半（OpenAI, 2026）。因此，較短的說明可以更快完成。地點、營業時間與路線應由地圖卡片承載，而不是依賴一段文字。

系統 A 很早顯示文字，但地圖動作較晚。系統 B 的文字稍晚，但地圖動作較早。圖中的秒數標記與總時間只是示意，而且圖中明確說明它們不是 benchmark 資料。這些標記不是 Kaleidr 追蹤，也不是 Azure 或 OpenAI 文章中的結果。比較只討論順序：更早的詞元不等於更早的地圖。

這個差異會影響產品把什麼視為成功。只依首個詞元時間排名的儀表板會偏好先說話、後畫地圖的系統。地圖產品也應記錄首次空間動作時間，而且只有在通過資格檢查後才記錄這個動作。為已關閉或未授權地點提早顯示圖釘，只是一個快速錯誤。Spatial Context Engineering 討論了相關規則：在合格集合形成後，哪些事實可以進入模型。

哪些內容可以快取，哪些必須重新驗證？

只有在儲存的值仍然正確時，快取才能省下一次往返請求。已知地點的穩定識別碼與座標很少改變，因此通常適合長期快取。營業時間、已計算路線與描述文字變化得夠頻繁，因此較短的 time-to-live 才是誠實的政策。庫存、車輛位置、授權與交易狀態應在決策時間重新讀取。今天早上快取的「有庫存」不能證明今天下午仍然有庫存。

左欄是很少變化的內容。中欄需要較短的生命週期。右欄應在使用前重新驗證。圖的底部說明這些類別仍受供應商條款、隱私與業務規則約束。中欄中的路線只是快取的計算結果，並不保證道路仍然開放。圖中的任何內容都不是 Kaleidr 的快取政策。

供應商的地點資料還帶來第二個限制。原記錄附帶的條款會繼續適用於副本，包括 attribution 與任何使用限制。私有記錄又增加第三個限制：使用者之間共用的快取不能成為繞過授權的方式。未知應維持未知。庫存逾時不能成為顯示「缺貨」的依據，路線逾時也不能成為編造分鐘數的依據。

說明結束前，地圖什麼時候可以先移動？

地圖上最有用的順序通常是先地點，再路線，最後是解釋它們的句子。語言模型仍在生成文字時，使用者已經可以查看合格候選。這個模式不會讓擷取或路線規劃本身更快，它只是更早顯示已經完成的工作。串流 text 也有相同限制。Azure 的說明是，串流改變的是第一個詞元可見的時間，而不是生成完整序列所需的時間。

順序是候選區域、圖釘、路線、簡短說明。商店數量、步行兩分鐘、評分、地址與營業時間都是圖中的範例標籤，不是即時查詢結果。這個模式裡的圖釘與路線對應的是已經通過資格檢查的地點。提早出現的 marker 不能取代這項檢查。

Kaleidr 的公開串流使用 Server-Sent Events 的 text/event-stream，其協定定義了正文結束前可能到達的內容（Kaleidr, 2026）。phase 事件表示請求已被接受而且工作已開始，它的階段值永遠是 thinking。靜默 10 秒後會收到一個 : keep-alive 註解。對困難問題而言，第一段正文可能要數十秒才到達，這也是階段事件與 heartbeat 存在的原因。對路線問題，route 可能在正文前到達，因此文字仍在串流時就可以先畫出路線。early_actions 攜帶可以在答案完成前套用的地圖動作，當至少兩個地點具有座標時會傳送。end 事件是權威最終結果，其動作會取代早期動作。並不是每個請求都會出現所有事件。

請求圖應該怎麼畫？

先畫出相依關係，再刪掉不會改變答案的步驟。地點解析與業務資料讀取可以在授權後並行執行。資格檢查是匯合點。路線規劃與其他空間處理都使用這個匯合結果。排序對剩餘候選排序。生成負責解釋。地圖顯示相同的識別碼。如果生成放在資格檢查之前，就會把詞元浪費在產品根本不能推薦的地點上。Grounded Spatial AI for Business Data 說明如何把這種資格檢查留在擁有事實的系統中。

授權最先發生。地點解析與業務資料讀取構成並行的一對。之後是資格檢查、路線、排序、生成與地圖。實線是關鍵路徑，虛線是重疊執行的讀取。這張圖強調應畫出完整請求圖。它沒有報告實測節省，也沒有展示私有記錄跨越授權邊界。

同一張圖也顯示了語言模型不適合處理的工作。包含關係測試、授權檢查、「目前營業中」篩選條件與距離門檻都是確定性的。模型適合讀取請求、解釋服務已經計算好的結果，並在合格地點之間對軟性偏好進行排序。OpenAI 的延遲指南也用更一般的方式做出相同區分：當任務不需要語言推理時，傳統方法通常更快。把所有語言步驟放在一個提示中回傳，也可能比串接多次模型呼叫更快，因為每多一次呼叫就會多一次 round trip。路線、庫存與權限仍來自各自的服務。

為什麼平均值會掩蓋慢請求？

平均值並不適合概括等待時間，因為少數慢請求往往主導使用者的記憶。應對每個時段報告中位數、95 百分位與 99 百分位，並依請求類別拆分。路線問題與簡短地點問題不應放在同一個桶裡。長尾可能來自多個工具的 fan-out、重試、大型提示、供應商差異或較長的生成回答。Azure 的公式已經說明，最後一種會隨輸出詞元數增加。其他原因不會體現在詞元數量中，因此時段必須分開觀察。

這條曲線只是形狀示意，不是 Kaleidr 追蹤，也不是某個供應商儀表板的樣本。標籤採用百分位的一般解讀：一半請求位於中位數或以下，大多數請求位於 95 百分位或以下，幾乎全部請求位於 99 百分位或以下。圖下的五個原因只是排查位置清單，並不是 Kaleidr 流量的實測比例。

長尾政策應說明某個時段超出預算時產品要做什麼。路線逾時應維持未知，並在說明中告知使用者路線不可用。庫存逾時也應維持未知，而不是被轉成「缺貨」。重試應記錄在追蹤中，避免把暫時性故障誤認為模型變慢。只最佳化中位數，而 99 百分位仍讓使用者盯著 spinner 等待，並不算完成效能改善。

哪些階段應納入預算？

先替階段命名，再分配目標。一個實用預算可以有七行：介面接收請求、檢查身分與授權、擷取情境、計算路線或距離、生成說明、套用地圖動作、完成業務動作。正如請求圖所示，其中有些階段會重疊。有些請求根本不會進入預訂或交接。這個清單用來判斷哪一行發生變化，並不表示所有問題都串行執行這七個步驟，也不是一組毫秒目標。

每個階段只有一項職責，沒有設定時間。接收請求是瀏覽器的工作。授權發生在私有資料之前。擷取、空間計算與生成是獨立階段。地圖動作會顯示圖釘、路線或調整後的視圖。業務動作是交接，如果問題不需要，就不存在。這張圖沒有設定任何數值目標。

只有當追蹤顯示使用者確實在等待某個階段時，才應該替那個階段設定目標。「兩秒內回答」這種統一數字會把點擊、路線與段落混在一起，而本文沒有引用這種數字。上面的 INP 門檻是瀏覽器目標。上面的詞元公式描述的是模型時間。首次空間動作時間是地圖目標，在團隊用自己的追蹤定義它之前，它仍然只是編輯性指標。

團隊應該從哪裡開始？

先把等待時間拆開。記錄頁面的下次繪製前的互動、首次進度時間、首個詞元時間、首次空間動作時間、末個詞元時間與完成動作時間。繼續把三個編輯性名稱標示為產品指標。依請求類別查看 p50、p95 與 p99。如果地圖已經顯示細節，就縮短生成回答。只讓彼此沒有相依關係的查詢重疊執行。任何可能改變決策的內容都要重新驗證。讓 end 事件，而不是第一個圖釘，成為使用者可以依據採取行動的最終結果。

當這條路徑需要包含組織自己的地點與規則時，請查看 Kaleidr Enterprise。SSE wire contract 定義了上文引用的事件順序，包括階段事件、保活、早期地圖動作與最終結果。

說明：Kaleidr 在創意與開發工作流程中使用 AI 輔助工具進行圖片建立、內容優化與研究。

常見問題

什麼是 Spatial AI 延遲？

Spatial AI 延遲是從位置問題到有用地圖回饋的時間。它包含介面、授權、擷取、空間計算、生成、地圖動作，以及任何業務交接。它與模型時間不是同一個數字。

下次繪製前的互動和模型延遲一樣嗎？

不一樣。下次繪製前的互動衡量頁面回應點擊的速度。頁面載入第 75 百分位上不高於 200 毫秒的良好數值，並不能說明路線或段落會在什麼時候完成。

什麼是首個詞元時間？

首個詞元時間是從提交提示到回傳第一個生成詞元的時間。Azure OpenAI 使用它，再加上詞元間時間與生成詞元數量，來描述末個詞元時間。

為什麼第一個詞元對地圖來說還不夠？

地圖在合格地點或路線可見時才真正有用。這個時間點可能比第一個詞元更早，也可能晚很多。首次空間動作時間記錄地圖時間點，首個詞元時間記錄文字時間點。

串流會讓路線規劃更快嗎？

不會。串流只會改變已完成工作何時可見，並不會縮短路線、擷取或完整生成所需的時間。Azure 的延遲文章指出，串流不會改變生成全部詞元所需的時間。

回答結束前 Kaleidr 會傳送什麼？

公開串流可能傳送值為 thinking 的 phase 事件、靜默期間的保活、路線問題中正文前的 route，以及至少兩個地點有座標後傳送的 early_actions。end 事件是權威最終結果，並會取代早期動作。不是每個請求都會出現所有事件。

為了降低延遲，應該快取私有庫存嗎？

不應該。庫存、授權、即時位置與交易狀態都應在決策時間重新驗證。Timeout 應維持未知。穩定的地點識別碼通常適合長期快取，但也必須符合供應商條款。

團隊應該關注哪個百分位？

應依請求類別查看每個時段的中位數、95 百分位與 99 百分位。中位數可以改善，而使用者記得的慢長尾仍然不變。

References

1. web.dev. Interaction to Next Paint (INP). A good INP is at or below 200 milliseconds at the 75th percentile of page loads recorded in the field. An INP above 200 milliseconds and at or below 500 milliseconds needs improvement. Updated September 2, 2025. https://web.dev/articles/inp
2. Microsoft. Azure OpenAI in Microsoft Foundry Models performance & latency. Time to last token equals time to first token plus the time between tokens multiplied by tokens generated. Streaming returns tokens as they are ready and does not change the time required to produce all of them. Accessed October 31, 2026. https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency
3. OpenAI. Latency optimization. A stated heuristic: cutting about half of the output tokens may cut about half of the latency. Accessed October 31, 2026. https://developers.openai.com/api/docs/guides/latency-optimization
4. Kaleidr Developer Docs. SSE wire contract. Documents text/event-stream, a phase event that is always thinking, a keep-alive after 10 seconds of silence, tens of seconds before first prose on a hard question, early_actions once two or more places have coordinates, a route before the prose on a directions question, and end as the authoritative result. Accessed October 31, 2026. https://docs.kaleidr.com/platform-api/sse-wire-contract
5. Kaleidr. Spatial AI Observability. A related guide for recording each stage, including a structured reason when the result is empty. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-ai-observability
6. Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for which facts reach the model after eligibility. Accessed October 31, 2026. https://kaleidr.com/blog/spatial-context-engineering
7. Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 31, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data

References in BibTeX

@misc{webdev_inp_2025,
  title  = {Interaction to Next Paint (INP)},
  author = {{web.dev}},
  year   = {2025},
  url    = {https://web.dev/articles/inp}
}

@misc{microsoft_azure_openai_latency_2026,
  title  = {Azure OpenAI in Microsoft Foundry Models performance \& latency},
  author = {{Microsoft}},
  year   = {2026},
  url    = {https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency}
}

@misc{openai_latency_optimization_2026,
  title  = {Latency optimization},
  author = {{OpenAI}},
  year   = {2026},
  url    = {https://developers.openai.com/api/docs/guides/latency-optimization}
}

@misc{kaleidr_sse_wire_contract_2026,
  title  = {SSE wire contract},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/sse-wire-contract}
}

@misc{kaleidr_spatial_ai_observability_2026,
  title  = {Spatial AI Observability},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-observability}
}

@misc{kaleidr_spatial_context_engineering_2026,
  title  = {Spatial Context Engineering for Map-Aware AI},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-context-engineering}
}

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