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