声明：本文来自网络资源学习整理，如有错漏，欢迎评论交流~

1. 语义检索定义

语义检索模型，是把感知结果从“固定类别 + 数值输出”，升级为“可被文本/概念查询的语义空间”，用于完成目标定位、场景理解、记忆对齐和风险检索的能力模块。

以智驾中语义检索为例，传统智驾感知是：

但系统层面真正需要的是：

这些问题的特点是：

• 类别不固定

• 语义是组合的、抽象的

• 很多在训练时没有显式标注

这正是 开放词汇 + 语义检索 的用武之地。

2. 语义检索模型上下游

2.1 上游

2.2 结构化语义承载层

通常包括三个关键部分：

• Semantic Occupancy

• BEV Feature Grid

• Instance-level Feature（proposal / mask）

没有这一层，语义检索只能停留在“图像相似度”，有了这一层，语义检索才能具备“可定位、可决策”的能力，语义检索本质是“语义 × 空间 ”的联合问题，而不是单纯 embedding 相似度

Semantic Occupancy（语义占据）：不是传统意义上的 free / occupied，而是：每一个 BEV / voxel cell，携带一个“可用于语义匹配的特征向量”，可以理解为：

没有 Occ：只能说“这张图像像 construction”，但你不知道 construction 在哪

有 Occ：每个 cell 都有坐标，语义检索 = 在 BEV 空间里做“语义过滤”，也就是：Occ = 语义检索的空间索引

Semantic Occ 中的语义 embedding：不对应 class_id（非固定类别），而是连续语义空间，因此可以支持：

• “像不像 X”

• “和 Y 的距离多远”

• “是否落在危险语义簇”

BEV Feature Grid（BEV 特征网格）：更像“语义检索友好的中间视觉表示”，它和occ有一些区别

BEV Feature Grid 会保留高维特征，适合做 embedding 投射，常见做法

Instance-level Feature（proposal / mask）：Occ / BEV 都是 dense 表达，语义是“铺开的”，但决策更喜欢“对象化”的结果，Instance-level Feature 会 把语义收敛到对象，降低搜索空间。Instance-level Feature通常来源于：open-vocab segmentation mask、detection proposal、tracking instance。每个 instance：

instance在语义检索中用于：快速粗筛、高置信度语义命中、提供给 planner，需要注意：instance-level 覆盖不了“未知组合语义”，所以它不能单独使用，必须依附 Occ / BEV feature。

总而言之，结构化语义承载层，提供可决策接口。

• Occ：空间索引 + 物理约束 + 粗语义过滤，高频更新：10–20 Hz，例如

• Instance Feature：把 dense Occ 聚合成对象，提供“可决策接口”，中频更新：5–10 Hz，例如：

• BEV Feature Grid：提供更丰富的语义 embedding，支撑复杂场景检索，低频更新：

三者共同构成：语义检索的“地基层”。这三者应该怎么用呢？能分开用吗？

三者不是“非此即彼”，而是“分层互补”；实际系统里大多是「一起用，但用在不同环节、不同频率、不同粒度」。具体解读如下：

• BEV Feature Grid：没有明确“可通行 / 不可通行”，planner 无法直接消费，特征维度高，对算力要求高，BEV Feature Grid 停留在“感知内部”，是走不到系统后面的。

• Instance Feature：instance 只能覆盖“被识别出来的对象”，无法表达：未成形区域、连续语义（湿滑、施工趋势）、未知物。也就是说，开放词汇能力会被“检测框”束缚住。

• Occ：语义是铺开的、planner 不擅长处理 dense map、“对象级决策”成本高。系统能跑，但复杂交互决策会退化。

2.3 语义编码与检索模块

语义编码与检索模块，是把“结构化语义承载层（Occ / BEV / Instance）”转化为“可检索、可对齐、可泛化语义空间”的引擎。上游给你的是：“哪里 + 原始语义特征”，这一层要做的是：“把它们变成统一的语义坐标系”。它们的结构如下：

1. Vision Encoder，输入是：BEV Feature Grid、Occ 中的 semantic embedding、Instance feature（mask / proposal），输出是：visual_embedding

2. Text Encoder，负责把 "施工区域"+"像路障但不确定"+"前方异常可通行区域" 映射成 text_embedding

3. 投射到统一的embedding space(语义对齐协议)，将如下embedding落在同一个语义空间中，这样才能做：cosine/clustering

如果没有统一空间：

• text → vision = 不可比

• region → region = 无意义

• history → current = 对不上

4. 将 BEV cell / instance / mask 映射为 embedding 向量，并支持：

• text → region（直观的语义检索）

• region → region（历史 / 相似度），当前场景中某区域，和“历史中出现过的哪类区域最像”

• condition → scene（条件选择场景），例如根据 天气/驾驶模式 检索“满足条件的场景模式”，是 策略选择/大模型接入 的接口

总而言之，Occ 负责“把语义放到正确的位置”；语义编码与检索模块负责“在这些位置上进行语义计算”。

2.4 下游

智驾系统如何“用”检索结果？常见如下：

1. 感知增强（Perception Augmentation）

   • 补充固定类别感知盲区

   • 标记“未知但重要”的区域

例如：未知类别，但与“construction”文本相似度高

2. 记忆与历史对齐

   • 当前场景 embedding

   • 与历史事故 / corner case embedding 对齐

实现：“这个场景像不像之前出过问题的那个？”

3. 算法示例

3.1 MobileCLIP（语义检索-图文匹配）

https://github.com/apple/ml-mobileclip （原生非用在自动驾驶领域，思想可以参考）

智驾输入改造：

• 将网格特征（BEV Feature Grid）、实例特征（Instance feature）、语义（Occ semantic embedding）做维度转换后输入

• 自然语言文本（如 “施工区域”“像路障但不确定”），经 Tokenizer 编码为序列特征后输入，与视觉编码器输出维度统一，保证语义空间一致

3.2 CLIP-BEVFormer

https://arxiv.org/pdf/2403.08919
https://zhuanlan.zhihu.com/p/688870044

让模型生成的BEV特征和当前真值BEV特征进行对齐，从而提高模型的精度。对bevfeature进行增强 会提升模型表现，算法架构如下：

3.3 BEV-TSR

https://arxiv.org/pdf/2401.01065
代码未开源（从CLIP-BEV很容易切换到BEV-TSR的想法）

BEV-TSR：将检索空间从 2D 图像迁移到 BEV（鸟瞰图）空间，结合大语言模型（LLM）增强文本理解，通过跨模态对齐技术实现检索增强，从而在数据集中更好的检索需要的驾驶场景。

如上图，将多视角相机图像转化为 BEV 空间的全局特征，可以解决 2D 图像局部性问题。

整体框架分为 “特征提取”+“特征对齐” 两大模块：

BEV-TSR是利用LLM语义检索+BEV全局特征结合的 多模态数据检索方法，仅从该算法功能角度，主要是数据挖掘。

4. 总结

语义检索模型实现：即使没见过“鸭嘴兽”，也能通过描述理解它。在智驾中，可能是：即使没标过“临时施工+湿滑+夜间”，也能通过语义相似性把它归入“高风险场景”。这不是替代感知，而是：补全感知，增强系统鲁棒性，减少长尾场景的工程成本。