专题导读

回首过去，传统的需求理解往往停留在"静态规则匹配"的阶段，常常只能"看见请求"却难以"读懂意图"。面向大模型时代，用户产生需求时，需要的不再是被动响应的定位工具，而是具备"时空思考"能力、能敏锐洞察需求的智能助手。

为了实现从"被动响应"到"主动决策"的跨越，本系列文章将带你走进"智能时空思考Agent"的背后，看看我们是如何逐一击破三大核心挑战的：

  • 篇章一 | 需求感知Agent刻画 ，让AI秒懂场景信号。

    面对海量、碎片化的长序列请求信号，我们将其极致压缩为面向AI推理的语义化上下文。通过将时空场景信号转化为大模型能高效理解的语言（向量化、图表示等），我们为规模化的脱敏信息流建立了结构化的数字化Agent模型，在保留完整决策逻辑与溯源能力的同时，夯实了"懂需求"的第一步基础。

  • 篇章二 | LBS-Intent Benchmark —— 统一标尺，让系统能力持续进化。

    没有准确的衡量就无法优化。为了科学评估系统的“思考能力”，我们为意图识别任务量身定制了一套专业“考卷”。通过构建标准化数据集与统一评价体系，这把“游标卡尺”让算法的每一次迭代都有据可依，真正转动体验持续升级的飞轮。

  • 篇章三 | 场景推理与解决方案 —— 主动服务，全面感知真实需求。****

    为了突破仅依赖端内数据的局限，我们将场景化需求与外部真实世界的丰富供给、全局时空状态相融合。通过将前沿的时空推理引擎接入真实业务场景，我们力求全方位感知真实意图，在开口前就提供量身定制的主动决策与贴心服务。

接下来，就让我们深入细节，看看我们是如何打通“需求建模 → 科学度量 → 主动决策”的全链路，用智能时空思考Agent把“懂你”写进每一次的时空交互中。

【声明】本文所涉及的所有数据均基于公开脱敏数据，案例均为模拟案例。

一、范式迁移：Agent时代的需求理解挑战

互联网产品正在经历一次深刻的范式迁移。

过去十年，搜索推荐系统的核心基础设施是规则特征体系——将请求信号压缩为一组特征或向量，供下游排序模型消费。这套体系的消费者是"排序模型"，它擅长处理数值向量，只需要一个可以快速检索的特征空间。

今天，以高德为代表的地图导航产品正在加速向AI Agent驱动的智能助手演进。当系统的决策主体从"排序模型"升级为"LLM Agent"，需求理解的输入要求发生了根本性变化：

  • 排序模型需要的是：preference_score=0.73

  • LLM Agent需要的是：「工作日下班后的晚餐场景，偏好步行可达、菜系多元，停车方便，有宝宝位的餐厅」

前者是一个数字，后者是一段可推理的上下文。LLM天然以自然语言中的因果关系、场景约束、不确定性推理为输入，孤立的数值特征对它而言几乎没有可利用的语义密度。

然而现实问题摆在工程师面前：LLM的上下文窗口是有限的，场景请求信号是海量的。如何将海量、分散、长序列的场景交互信号，极致压缩为"面向AI Agent推理的语义化需求上下文"，同时保留完整的决策逻辑、支持任意结论的证据溯源？

二、地图场景的特殊挑战：信号是散落的碎片，意图是完整的故事

****传统的需求感知，遵循“数据采集 → 特征工程 → 模型训练 → 标签生成 → 下游消费”，****这套体系在LLM时代，其局限性日益凸显：

语义压缩丢失"为什么"，"搜索过附近餐厅"这一信号，无法区分该场景是午间工作餐的高频刚需，还是仅偶发性休闲探店的低频行为。

请求序列缺乏时空因果，LBS场景中46%的前后请求在时空上并不连贯（如跨城规划、异常交互），简单叠加连续搜索权重会误判因果，导致推荐失效。

多线程并行导致"意图漂移"。长线规划（如规划旅游行程）与即时需求（如找厕所）是多线程并行的，高频的短线点击会持续"带偏"系统。

离散特征缺乏"语义描述"。AI模型无法理解"偏好度0.8"的数值，它需要的是"工作日步行、周末驱车"这样包含场景与逻辑的语义化描述，以承接复杂的动态意图。

让我们通过模拟案例，感受传统方案的系统性局限。

模拟案例一：跨越5天的「周末约会」

用户行为日志显示：

图片

传统系统如何处理？ 

将这5天切分为互不相关的时间窗口，分别累加"餐饮需求""书店需求""夜生活需求"的计数权重。

这5条行为的真实逻辑是什么？ 

这是一个完整的「周末约会计划」场景——前四天处于决策期（反复对比餐厅、寻找约会路线、考察书店气氛），周六进入执行期。传统方案将5天有意识的决策过程压缩为5个互不相关的计数事件，造成了系统性的信息毁灭。

模拟案例二：跨越一周的「异地出行」

用户行为序列：

模拟请求序列：用户在周三开始为广州行程做规划，中间穿插本地事务，周日实际到达广州开始游览。

图片

传统系统如何处理？

传统系统将这一周的请求视为孤立事件，由于缺乏时空序列理解，它会机械地将"广州行程规划"与"本地事务"权重简单叠加，导致系统在两个城市间频繁切换推荐，造成"意图漂移"，无法区分哪些是预设的长线规划，哪些是即时的本地需求。

这些行为的真实逻辑是什么？ 

这是一个典型的"长线规划与短线即时需求并行"的复杂场景。请求流处于"跨区域多线程"状态，广州行程是具备时空延续性的核心任务，而本地事务则是即时性的请求。系统应通过因果关联识别出"行程"的长链路意图，将其与琐碎的本地点击剥离，从而保证在行程期间持续提供广州的高质量游玩建议。

三、LBS场景信号体系：需求感知的数据基础

要构建准确的需求感知能力，首先需要一套高质量的场景信号基础设施。高德的LBS场景信号体系，正是这套基础设施的核心。

多维场景信号覆盖

高德LBS场景信号覆盖了地图App上的完整交互链路，涵盖多类请求类型，共同构成了从「需求萌生」到「前往」的完整决策链路观测。

信号质量的三个核心维度

然而，并非所有信号都具有同等的语义价值。场景信号体系在设计上重点解决了三个质量维度的问题：

  • 维度一：信号的去冗余与归并

现有事件采集体系中，语义高度重叠的候选事件往往被分别采集，形成冗余上报，若分别计入需求建模，会引入重复噪声。

场景信号体系通过触发路径标准化、语义等价判定和质量分级机制，将候选信号按准入/降级/合并/淘汰四类质量等级处理，确保进入下游的信号数据语义无冗余、质量受控。

  • 维度二：后验前往信息强化

线上请求（浏览、点击、规划）是否真正转化为实际前往，是判断需求真实性的关键。场景信号体系整合了多路到达信号，共同构成高召回的后验信号覆盖体系，为下游的需求建模提供「信号真实性」的可信依据。

  • 维度三：聚合模式优化

场景信号采用了连续访问聚合机制：同一天内，如果对同一POI发生连续请求（如先规划路线再启动导航），则合并为一行记录。

这种聚合不仅减少了请求冗余，更重要的是保留了请求的序列结构——"先规划后导航"这一完整决策链得以完整呈现，为场景识别提供了关键的时序输入。

层次设计（场景级/页面级/控件集合）

为了有效组织场景信号数据，避免「一堆离散事件」的扁平化堆叠，信号体系在数据组织层面引入了层次化结构设计，将端内请求按照语义粒度由粗到细拆分为三个层次：场景级 → 页面级 → 控件集合级，并通过序列化形式将三层信息串联为完整的请求上下文。

这种层次化串联使得每一条信号记录不再是孤立的事件点，而是携带了完整的语境信息——在什么场景下、经过哪些页面决策、最终触发了哪个控件操作。这为下游需求建模提供了远比单一事件流更丰富的结构化输入。

四、从请求信号到需求理解：三层架构设计

基于LBS场景信号的数据基础，我们提出了一种全新的需求建模体系——因果认知金字塔（Causal-Cognitive Pyramid，CCP）。

其核心理念是：不再将请求视为独立的计数事件，而是将分散在不同时间的离散信号，重组为"环境+信号=决策"的因果推理链。

图片

这套体系的三个层次，对应三个递进的问题：

  • L1 信号层：解决"这条信号本身价值几何"——通过多维度锐度计算，区分信号与噪声

  • L2 场景层：解决"这些分散的信号属于哪个场景、处于什么阶段"——跨天识别完整意图场景，区分单日内的多场景混叠

  • L3 摘要层：解决"当前场景处于什么状态，需求逻辑是什么"——极致压缩为语义化因果需求摘要

**L1：信号锐度——识别重要的，舍弃不重要的
**

问题：信号平权导致噪声淹没信号

传统方案的隐含假设是"信号平权"——每条请求按类型赋予固定权重，累加后形成需求向量。这一假设在工程上简洁，但在语义上失真。

我们的做法：多维锐度评分

我们为每条信号计算一个锐度分（Sharpness Score），量化其对需求建模的实际贡献，而非统一对待。

整体划分为三个逻辑层级：

图片

ID(e)的计算核心是将请求信号映射为触发场景群体在需求特征空间上的条件概率分布，再与同城全量请求的先验分布计算KL散度：

图片

直觉理解：搜索"加油站"的场景群体需求与全城请求高度一致（ID低，<0.1）；导航至"书店"的场景群体则在"小众需求"等维度显著偏离全局（ID高，>0.7）。前者几乎不携带关于场景特质的信息，后者能有力刻画需求的场景特征。

  • 维度二：需求增量度 U(e)——这条信号对当前场景序列有多新奇？

ID(e)回答"信号在全体请求中有多特殊"，U(e)回答"信号对于当前场景序列有多新奇"。两者参照基准严格正交：

图片

以历史场景序列积累的需求分布为参照，U(e)高意味着此次请求与历史场景习惯存在显著偏离，代表需求的潜在迁移，具有较高的更新价值。

两个维度的正交性，覆盖了单一参照方案的系统性盲区：

图片

最后一个情形是传统单参照方案的系统性盲区——该信号在群体层面属于高频常见请求（ID低），若仅凭全局频率逆加权将被严重低估；但在场景序列层面代表重大需求迁移信号（U高），双参照框架能够正确捕获。

  • 维度三：信号成本 C(e)——这次请求付出了多少决策代价？

    高成本请求意味着更强的主动意图。C(e)由四个子维度构成：

    图片

  • 空间跨度成本Cdist：衡量行为涉及的物理距离或空间跨越代价。该维度的评估需基于个体历史行为基线进行相对化处理（而非采用全局绝对阈值），以准确区分个体的“常态化习惯行为”与“偶发性高意图行为”。

  • **时间投入成本Ctime：**衡量完成该次行为所耗费的时间跨度或时间维度的沉没成本。

  • **经济价值成本 Cmoney：**衡量该次行为背后所蕴含的实际或预期资金投入代价。

  • **交互摩擦成本Cfriction：**衡量用户在执行该行为时克服的操作复杂度、决策链路长度或认知负荷。

  • 维度四：信号可信度 R(e) —— 数据底座的真实性检验

    作为核心门控项，本维度采用乘法衰减模型。当 R(e) 评估趋近于极小值时，整体特征置信度（或锐度分）将被强制熔断（压制至零），以阻断噪音数据的传导：

  • 极短时交互特征：赋予极低权重。判定逻辑为缺乏有效交互深度，极大概率为噪音或无效触达。

  • 被动唤醒信源：赋予较低权重。判定逻辑为由外部策略被动触发，缺乏主动意图支撑。

  • 统计分布离群特征：赋予极低权重。判定逻辑为行为频次严重偏离历史正常基线，疑似非真实的异常交互操作。

  • 标准主动交互：赋予高权重。判定逻辑为意图明确且符合正常统计分布规律，具备高可信度。

锐度输出示例

以「周六下午规划至某文创类POI」为例：

图片

通过行为锐度的刻画，能够使高价值信号在需求建模中获得显著优先权。

L2：场景聚合——用AI能读懂的方式描述需求

问题：信号碎片无法被AI理解

L1解决了"哪条信号有价值"，但即便筛选出高锐度信号，依然面临一个更深层的问题：孤立的请求序列，即使质量再高，对LLM而言仍然难以推理。

在处理跨时间节点的离散交互信号时，传统方案通常采用固定时间窗口切片并独立累权的方式。这种处理机制难以识别出跨越较长周期的复合意图链路（例如：前期序列为反复对比的“意向评估阶段”，末端节点为最终的“转化履约阶段”）。

LLM天然以"有因果关系的故事"为输入，而非"离散的事件列表"。要让AI真正读懂需求，需要把请求序列重构为它能理解的结构。

我们的做法：场景重构+PEB因果推演 

图片

场景定义：用户在特定环境约束下，围绕特定目标展开的一组因果关联行为集合。我们区分两类场景——

  • 事件场景：一次完整的出行或决策过程，具备明确的生命周期。

  • 偏好模式：跨越时间周期重复出现的同质化行为特征，是基于多个底层单点事件场景归纳提炼而成的偏好模式。

聚合原则：在进行场景特征融合时，系统严格遵循****“语义意图 ≫ 空间拓扑 > 时序邻近”****的优先级权重。

其中，时间上的邻近仅能作为弱辅助信号，不能直接推出意图一致。即使多个行为发生于相近时间范围内，若其目标、内容语义或任务属性存在显著差异，仍应判定为相互独立的场景，而不应基于时间共现进行强行合并。

PEB因果推演框架：在每个场景内，显性化三要素——

  • E（Environment）：环境约束，用户产生需求时所处的客观条件（时间段、位置、本地/异地状态等）

  • B（Behavior）：请求事实，围绕哪些POI发生了什么请求、频次与深度如何

  • P（Persona/Intent）：基于E和B的反推结论，每条结论强制携带：结论本身 + 支撑证据链 + 推断边界（哪些结论无证据，不推断）

场景生命周期管理：场景不是静态规则，而是动态实体——区分决策期（仅浏览）、执行期（已导航/到达）、已结束；判断场景是长期性、周期性还是一次性；引入频率基线校准，高频场景用短窗口评估，低频场景用长窗口容错，避免将"正常沉默期"误判为需求衰退。

Before（传统方案对「周末约会」案例的处理）：

餐饮信号 +3次 | 文艺信号 +1次 | 夜生活信号 +1次

有意识的决策信号，被压缩为互不相关的计数，决策上下文彻底丢失。

After（L2场景聚合输出）：

场景：周末约会计划（事件场景）状态：执行期（周六已到达日料+清吧，场景闭环）E：工作日夜间-周六，望京/三里屯周边，本地场景B：跨4天浏览日料×3+清吧×2+书店×1，周六实际到达2处P：  - 有意识的约会选址决策，计划性强（证据：跨4天对比，多类型场景考察）  - 约会偏好：餐+酒吧组合，文艺氛围加分（书店考察为辅助验证）

L3：核心决策摘要——双层校验，减少幻觉

问题：LLM生成的需求摘要不可信

有了L1的锐度筛选和L2的场景聚合，最后一步是将其压缩为可直接被下游Agent消费的语义化需求摘要。这里面临一个关键工程挑战：LLM在生成摘要时容易"注意力漂移"——忽略重要场景特质、或在无充分证据时自行填补结论（幻觉）。

传统做法依赖单次生成，无校验环节，输出质量不稳定。

我们的做法：三层内容 + 双层强制校验

  • L3的三类核心内容：

①场景核心需求（coreprofiles）：不只写"某类场景喜欢什么"，而是写"在什么场景下有什么需求"以及"需求的决策模式是什么"——这才是LLM推理所需的完整上下文。

②决策逻辑（core_decision_logic）：不描述场景"是什么"，而是描述场景"如何做决策"——使LLM能在未见过的场景中推演可能的需求响应。

③近期场景快照（recent_scene_map）：提供当下场景状态，帮助下游做即时决策，而非依赖历史静态结论。

  • 双层强制校验机制：

L3每一条结论必须经过两层校验，而非依赖单次生成的自我一致性：

●L1 事实校验（基于定量证据的实证检验）：
利用规模化匿名信息流中的可量化特征，对需求推理结论进行客观验证。任何结论的成立，都必须具备相应频次或强度的客观信号作为支撑（例如满足特定的转化阈值条件）。若缺乏充分的数据事实作为印证，则判定该结论无效。

●L2 场景校验（基于多维信号的交叉验证）：
通过引入跨场景的需求信号，对推理结果进行逻辑互证。系统需审查推断出的需求特征与实际转化记录之间是否存在矛盾。若发现逻辑冲突，必须在后续环节（L3）中显式记录冲突情况并输出消歧结论，严禁对异常或不一致的信号进行选择性过滤。

此外两道覆盖性校验确保不遗漏：

  • 场景覆盖校验：逐一检查L2中每个场景的核心特质是否在coreprofiles中有对应描述，缺失则强制补充

  • 锐度密度校验：对所有高锐度信号（锐度分≥阈值），检查其反映的场景需求特质是否在L3中体现，完全未被反映则必须补充或说明排除理由

  • 效果（以下为模拟数据）

Before（无校验，LLM单次生成）：

周边小半径内内出现过多次"咖啡厅"类搜索，近期有少量的导航规划记录。→ 问题：1)"导航规划"实为信息查询副产品，未消歧，无法判定是否真实出行2)忽略了搜索时段分布差异（工作日午间 vs 周末下午，场景截然不同，L3未反映）

After（双层校验后输出）：

行为信号校验结果：- 周边"咖啡厅"搜索多次，其中大部分发生在工作日中午，判定为午休刚需场景；- 少量的导航规划记录经消歧后判定为**信息查询行为**（规划后未启动导航，未到达），不计入真实出行信号；- ⚠️ 冲突标注：存在少量周末下午实际到达记录，场景与工作日午休需求不同，判定为**独立休闲场景**，不与工作日结论合并推断。信号一致性结论：- 工作日午休咖啡搜索：高频、时段集中、可信度高（保留）；- 导航规划记录：消歧后剔除，不作为出行意图信号；- 周末到达记录：独立标注，不跨场景泛化；近期信号快照：- 近期出现少量新地点搜索但均未到达，判定为"决策评估阶段"，意向存在但尚未转化；- → 建议下游：对该时段、该需求类别触达时，优先推送"距离近、等待时间短"的可选项，降低决策摩擦。

双层校验的核心价值不只在于"纠错"，更在于将不确定性显性化——让下游Agent知道哪些结论是高置信的，哪些存在冲突待消歧，哪些因证据不足主动放弃推断。这比一份"看上去完整但实则混有幻觉"的摘要，对Agent决策的帮助要大得多。

最终效果

传统特征方案输出（模拟数据）：

餐饮搜索频次: 0.73 | 周边导航规划次数: 0.61 | 出行方式信号: 驾车

这组输出对下游Agent而言几乎不可用：在什么场景下有餐饮需求？"驾车"是真实导航方式还是高德默认页面的信息查询副产品？决策时有哪些硬约束？这些问题，数值特征无法回答。

需求感知agent方案输出（模拟数据）：

工作日午间，周边餐饮搜索集中，多次搜索后均步行到达，判定为午休步行就餐场景；规划后均未启动实际导航，消歧后判定为信息查询，非真实出行信号；周末下午存在少量导航记录，场景独立，不与工作日信号合并。决策约束：步行可达优先（近几次均放弃远距离选项），停车复杂区域历史放弃率高（硬约束）。

Agent拿到这段描述，可以直接推演：今晚推荐步行可达的未尝试菜系新店，避免停车复杂的选项，可关联其近期探索意图主动触达。

五、效果分析：Token减少，理解反而更深

直接将海量原始交互信号喂给 LLM，往往会面临“Token爆炸但信息贫乏”的窘境。当模型被淹没在数千个离散的底层信号中时，它必须耗费大量算力去“大海捞针”——自行识别噪声、拼凑场景、推导因果。这不仅成本高昂，且极易引发推理幻觉。

CCP 架构的核心洞察正是为了打破这一瓶颈：将“归纳推理（Inductive Reasoning）”的过程前置到信号处理层。以下是不同方式token量的简要对比：

图片

三种形式的Token量，传统特征与CCP相近；但相同token量下CCP能提供更多的信息量：

  • L1的锐度过滤让LLM无需自行辨别噪声

  • L2的场景聚合让LLM收到的是"有逻辑的场景"而非"离散的事件点"

  • L3的决策摘要让LLM能够直接套用规则而非从头推演。

在高德AI出行场景的实际验证中，基于需求感知引擎结果进行增强生成式训练后，实走率指标提升1.22pp——这一提升背后，正是Agent从"猜测场景需要什么"转变为"理解场景为什么这样决策"的质变。

结语

从海量信号到需求全图，CCP方案走的是一条「信息升维」而非「信息压缩」的路：

  • L1层解决的不是"记录请求"，而是"区分信号与噪声"——用多维锐度量化每条信号对需求建模的真实贡献

  • L2层解决的不是"聚合请求"，而是"还原决策场景"——用PEB因果推演将碎片化的信号重组为完整的意图故事，并为每个场景标注完整的生命周期状态

  • L3层解决的不是"生成摘要"，而是"构建可推理的需求上下文"——用少量token承载完整的决策逻辑、场景关系与趋势动态，让AI Agent真正能够"理解需求"而非"记录请求"

我们相信，真正的需求理解，不是"某类场景发生了多少次请求"的统计汇总，而是"在什么处境下，产生了什么需求，背后是什么决策逻辑"。当机器能够回答后一个问题，AI Agent才真正具备了「服务需求」而非「服务数据」的能力。

高德在这条路上还在持续探索，欢迎有相同思考的同学交流共建

图片

#AI出行 #智慧出行 #AI #Agent #高德 #高德技术

END

图片