Embed the world: Multimodal AI for searchable aerial imagery at scale

嵌入世界：用于大规模可搜索航空图像的多模态 AI | 人工智能

嵌入世界：用于大规模可搜索航空图像的多模态 AI

将航空图像库转换为可通过自然语言搜索的知识库，是一个影响所有依赖地理空间数据的行业的问题，包括保险、房地产、政府、基础设施和农业。传统的方法要么需要手动逐块检查图像，要么为每个新问题训练一个定制的计算机视觉模型。多模态嵌入、大型语言模型（LLM）的标题生成，以及在 AWS 上的向量搜索提供了一种更快的替代方案：只需索引一次，然后就可以使用自然语言进行查询。

我们与 Vexcel 合作，Vexcel 是一家提供航空图像和地理空间数据的服务商，运营着全球最大的航空图像项目之一。我们评估了多视角航空图像上的嵌入模型、融合策略、标题集成和搜索方法。使用自己的传感器和专用的飞机机队，Vexcel 在 45 多个国家和地区收集高分辨率数据，提供正射影像、多角度的倾斜影像以及高程模型。这些数据已经存在，应用场景也很多，但将数十亿像素转化为对现实世界的答案需要更快的路径。

在本文中，我们将探讨问题空间，我们在 Amazon Bedrock 和 Amazon OpenSearch Serverless 上的架构，我们基于 OpenStreetMap 真实数据构建的评估方法，四个实验比较了嵌入模型、融合策略、标题生成和搜索方法，以及您在构建类似系统时可以应用的实际指导。您将了解到哪些设计选择对地理空间语义搜索有显著影响，包括为什么在我们的评估中，Amazon Nova 多模态嵌入模型在两个基准查询中都实现了最高的 F1 分数。本文中描述的工作演变为 Vexcel Intelligence，这是一个可搜索的图像产品。

在无需逐特征训练的情况下搜索数百万张航空图像

当客户需要在某个郊区定位游泳池、识别开发区中的道路网络，或统计城市中太阳能板的数量时，有人必须手动逐块查看（依次检查每个地图块）数百万张图像。另一种方法是为每个特征训练一个计算机视觉模型，这需要标记数据、工程时间和持续的再训练。当下一个客户想要查找侧面有涂鸦的仓库（见图 1）时，他们又会重复这个过程。由向量嵌入支持的语义搜索消除了逐特征训练的步骤，可以在几秒钟内将自然语言查询转换为结果。

图 1. Vexcel 提供的典型倾斜图像，提供丰富的 360 度世界视图

Vexcel 之前通过三个概念验证（POC）探索了这个问题：一个结合图像与房产数据的基于代理的方法，一个用于相似性搜索的房产嵌入系统，以及一个使用大型语言模型（LLM）生成标题的分块多模态嵌入管道。第三个方法显示出前景，但也提出了关键问题：使用哪种嵌入模型，如何处理每个位置的多个视角，以及标题是否真的能提高结果，还是仅仅增加了成本。

AWS Generative AI Innovation Center（GenAIIC）与Vexcel合作，针对一个具体问题进行了探索：在多视角航拍图像上进行语义搜索时，嵌入模型、融合策略、描述方法和搜索方法的最佳组合是什么？Vexcel带来了领域专业知识和真实世界的数据，而GenAIIC则贡献了机器学习架构、完整的从摄入到评估的流程以及AWS服务集成。最终的成果是一个系统，Vexcel后来将其发展为Vexcel Intelligence，这是一个目前处于预览阶段的产品，能够将他们的图像库转化为可搜索、可通过AI查询的解决方案。

为什么地理空间图像搜索不同

地理空间图像搜索本质上与搜索消费类照片不同。在Google Images中搜索“游泳池”会返回从单一视角拍摄的独立照片。航拍图像并不是这样工作的。

单个地图瓦片不是一个图像。它是同一位置的七个互补视角。

每个瓦片包括正射影像（从上到下的RGB视图）、从北、南、东、西四个方向拍摄的四个倾斜照片、一个数字表面模型（DSM）编码包括建筑物在内的高程，以及一个数字地形模型（DTM）表示裸地高度。下图展示了单个瓦片的这七个视角——每个视角都捕捉了同一地理位置的不同细节。

图2. 同一瓦片的七个互补视角（第一行：正射、北倾斜、南倾斜、东倾斜；第二行：西倾斜、DTM、DSM）

这些视角揭示了截然不同的细节。在前面的图中，建筑物的正面立面（带有类似小屋的窗户）仅在南倾斜视角中可见；正射影像、其他倾斜视角和高程模型完全看不到它。与此同时，DSM捕捉到了遮挡RGB视图中地面特征的树冠，而DTM则完全去除了植被。仅看到一个视角的嵌入模型使用的是不完整的信息。而看到七个视角的嵌入模型则需要一种融合它们的策略。

真实数据的挑战

消费类图像搜索拥有数十年的标记数据集，如ImageNet、COCO和Open Images。而这种规模的航拍特征检测却没有。我们需要一种方法来在没有预标记语料库的情况下评估搜索质量，这使我们选择了OpenStreetMap作为自动的真实数据来源，这一决定塑造了整个评估框架。

什么是正确结果的模糊性

第三个挑战是模糊性，它比视角选择更深层次。考虑一个搜索“游泳池”的查询，返回了一个瓦片，其中游泳池仅在正射影像中可见，而在任何倾斜视角中都不可见。不清楚这个结果是否正确。相反的情况同样模糊：一个瓦片中游泳池仅在南倾斜视角中可见，而在上方视角中不可见。

缩放级别会加剧这一问题。根据瓦片的分辨率，一个瓦片可能覆盖一个街区或整个社区。在人口密集的郊区，一个瓦片中可能包含十几个游泳池。如果地面真实数据要求系统在瓦片中包含匹配特征时返回该瓦片，还是需要考虑瓦片中所有实例？瓦片级别的匹配（至少有一个游泳池）和特征级别的匹配（每个游泳池都被识别）是根本不同的评估标准，它们奖励的系统行为也不同。在我们能够衡量之前，必须先定义“正确”是什么意思。

共同设计研究议程

在编写任何一行优化代码之前，我们构建了评估框架。这是有意为之：先衡量，再调整。如果没有一种严谨的方式来衡量搜索质量，每一个架构决策都只是个人观点。

我们的研究围绕以下六个问题展开，每个问题都针对影响搜索质量的特定架构决策：

• 哪种嵌入模型最能理解航拍图像？我们比较了 Amazon Nova Multimodal Embeddings、Amazon Titan Multimodal Embeddings G1 和 Cohere Embed v4，这些模型都可以在 Amazon Bedrock 上使用，Amazon Bedrock 是一项完全托管的服务，通过单一 API 提供来自领先 AI 公司的高性能基础模型（FMs）选择。Amazon Nova 是一组可通过 Amazon Bedrock 使用的基础模型。

• 如何处理每个地理位置的七张图像？我们测试了每视角嵌入、晚期融合（平均和最大池化）、LLM 加权注意力融合以及 Cohere 的原生多图像批量编码。

• LLM 生成的描述是否能提高搜索准确性？我们设计了一个自定义的描述提示，指导基础模型同时分析七张图像，作为同一地理位置的互补视角，识别每张图像的类型（正射、倾斜角度、DSM、DTM），并在土地利用、建成环境、基础设施、自然特征、物体和空间关系方面合成统一的描述。该提示明确指示模型交叉参考视角：当某个事物在一个视角中不清晰时，利用其他角度或高程数据来解决。我们使用 Amazon Nova 2 Lite 和 Amazon Bedrock 上的 Anthropic Claude 测试了该提示，衡量将这些描述与图像嵌入一起索引是否提高了检索效果。

• LLM 提取的元数据是否能提高过滤效果？我们使用第二个基础模型对每个生成的描述提取最多 25 个关键词标签（例如，“游泳池”、“成熟树木”、“商业区”），并将它们与嵌入一起存储在 Amazon OpenSearch Serverless 的文本字段中。在查询时，相同的提取过程也应用于用户的搜索查询。Amazon OpenSearch Serverless 的 k-最近邻（k-NN）过滤随后使用这些标签作为预过滤器，在运行向量相似性之前，将候选集缩小到标签与查询术语匹配的文档。这使用了原生过滤后的 k-NN，将结构化元数据与语义搜索结合。

• 哪种搜索策略最适合不同类型的特征？我们比较了基本的 k-NN、多视角融合搜索、混合图像+描述评分、元数据过滤搜索和纯文本搜索。

• 是否可以使用公开的地面真实数据构建自动评估框架？我们通过 Overpass API 从 OpenStreetMap 获取了地面真实数据，使基准测试可重复，无需手动标注。

评估区域是芝加哥的格兰特公园，有两个基准查询：“游泳池”（离散对象检测）和“道路”（分布式基础设施检测）。我们在这些维度上测试了大约 100 个不同的配置。

架构概述

系统遵循一个五阶段的流程（图 3），每个阶段都可以独立替换，用于 A/B 实验。

图 3. 五阶段流程架构

阶段 1. 探索感兴趣区域（AOI）。用户在交互式地图上绘制一个多边形，以定义他们的感兴趣区域。AOI 会保存到 Amazon Simple Storage Service（Amazon S3）中，以确保可重复性。

阶段 2. 导入影像。系统从 Vexcel 的 API 获取与 AOI 相交的每个地图瓦片的影像，这些瓦片在可配置的缩放级别上。每个瓦片最多生成七张图像。速率限制（每秒 100 次请求）和 Amazon S3 缓存有助于防止重复的 API 调用。凭证通过 AWS Secrets Manager 管理（图 4）。

图 4. 导入界面：选择影像类型和缩放级别

阶段 3. 嵌入与索引。每张图像都会通过所选的 Amazon Bedrock 嵌入模型进行处理。可选地，七种视图会被发送到一个视觉 LLM（Amazon Nova 2 Lite 或 Anthropic 的 Claude）以生成结构化文本描述。嵌入和标题随后会被索引到 Amazon OpenSearch Serverless 或 Amazon S3 Vectors 中。界面提供标题生成控制、实时维度影响分析、嵌入模型和融合策略选择（图 5 和 6）。

阶段 4. 搜索。使用相同的模型对自然语言查询进行嵌入，然后与索引进行匹配。系统会自动检测索引中存在哪些字段（每视图嵌入、融合嵌入、标题文本、标题嵌入），并动态启用索引支持的搜索方法。

阶段 5. 评估。使用精确度、召回率和 F1 分数，将搜索结果与 OpenStreetMap 的真实数据进行评分。评估框架会在所有启用的搜索方法上运行相同的查询，并报告比较指标。

模块化设计是关键的架构决策。每个组件（嵌入模型、融合策略、搜索方法、向量存储）都通过一个通用接口连接。将 Amazon Nova Multimodal Embeddings 替换为 Cohere Embed v4 只需更改配置，而无需更改代码。这使我们能够在几小时内测试大约 100 个配置，而不是几周。

图 5. 嵌入与索引界面 – 标题生成部分

下图显示了嵌入配置面板，用户在此选择用于索引运行的嵌入模型和融合策略。

图 6. 嵌入与索引界面 – 嵌入配置部分

选择合适的 K

每个向量搜索都会返回前 K 个最近邻（k-NN）结果。K 是一个具有实际影响的杠杆，合适的值取决于特征在数据集中的常见程度。

当特征稀疏（例如，数百个瓦片中只有少数游泳池）时，较大的 K 会导致结果中充斥着不相关的瓦片。系统会检索 K 个结果，无论是否存在 K 个相关瓦片。当只有 8 个瓦片包含泳池时，设置 K=50，其中 42 个结果是噪声。精确度会崩溃，F1 分数随之下降。

当特征丰富（例如，大多数瓦片中都有道路）时，较小的 K 会人为地限制召回率。当 60 个瓦片包含道路时，设置 K=5，只能找到其中的 8%。召回率崩溃，F1 分数随之下降。

这种关系是机械的。Precision@K = relevant_found / K。如果 K 超过了相关瓦片的数量，那么 precision 就不可能达到 1.0。Recall@K = relevant_found / total_relevant。如果 K 小于总相关瓦片的数量，那么完美的 recall 是不可能实现的。

我们同时在多个 K 值（K = 3, 5, 7, 10, 15, 20, 25, 30, 50）上进行了评估，并跟踪了 precision、recall 和 F1 分数在整个范围内的变化。最优的 K 值始终接近真实数据中相关瓦片的实际数量，这个数字在生产环境中是未知的。在实践中，对于一般性查询，建议从 K=10–20 开始，观察评估结果中 precision 和 recall 的权衡，并根据特征类别进行调整。评估框架使这种校准变得快速；使用不同的 K 值重新运行只需几秒钟，而不是几个小时。

两种衡量方式：基于瓦片的评估与基于实体的评估

根据你将什么视为命中，单一指标可能会掩盖重要的行为。我们构建了评估框架，提供了两种互补的模式，以回答不同的问题。

基于瓦片的评估问的是：我们是否找到了正确的地点？一个瓦片要么是相关的（包含至少一个特征实例），要么不是。不管一个瓦片中有一个游泳池还是十二个，它都算作一个相关瓦片。precision、recall 和 F1 是基于瓦片计算的。

基于实体的评估问的是：我们是否找到了最多的特征？每个单独的实体（每个游泳池、每条道路段）都分别计数。一个包含 5 个游泳池的瓦片会为相关总数贡献 5 个。找到该瓦片可以恢复 5 个实体；错过它则会损失 5 个。

当特征分布不均匀时，这两种模式会出现分歧，在航拍图像中，这种情况几乎总是存在的。考虑我们评估中的以下场景：

| 情景 | 基于瓦片的 Recall | 基于实体的 Recall | |------|------------------|------------------| | 找到 1 个包含 5 个游泳池的瓦片，错过 1 个包含 1 个游泳池的瓦片（共 6 个） | 50% | 83% | | 找到 1 个包含 1 个游泳池的瓦片，错过 1 个包含 5 个游泳池的瓦片（共 6 个） | 17% | |

在两种情况下，基于瓦片的 recall 是相同的：找到了 2 个瓦片中的 1 个。基于实体的 recall 显示了关键的差异：第一种情景恢复了大部分实际的游泳池，而第二种情景则错过了大部分。

使用哪种模式取决于你要回答的问题。当地理位置覆盖范围重要时，例如“找到每个有游泳池的地点”，基于瓦片的评估是合适的视角。当密度重要时，例如“找到游泳池最多的区域”，基于实体的评估则更为关键。我们报告两种模式，因为它们之间的差距揭示了特征的分布情况：较大的差距表明特征集中在少数密集的瓦片中，而不是均匀地分布在区域内。评估框架还使用实体数量作为分级相关性，计算了 nDCG（归一化折扣累积增益），并提供了分层指标，将性能分为稀疏瓦片（恰好 1 个实体）和密集瓦片（2 个及以上），这样你可以清楚地看到系统在哪些地方表现良好，在哪些地方存在困难。

实验 1：哪个模型理解航拍图像？

我们对相同的 Grant Park 数据集进行了三次索引，每次使用不同的嵌入模型，保持其他变量不变。每个模型处理相同的瓦片、相同的视图以及相同的 Amazon OpenSearch Serverless 配置。然后，我们在每种融合和搜索配置上运行了两个基准查询，并计算了每个模型的平均 F1 分数。

Amazon Nova 多模态嵌入在我们的评估中，对于游泳池（0.621）和道路（0.555）都取得了最高的平均 F1 分数（图 7）。在游泳池方面，与 Cohere Embed v4 的差距较小（0.621 对比 0.606），但在道路方面差距显著（0.555 对比 0.415），这是一个显著的差异。Cohere Embed v4 的原生多图像批量编码在处理离散对象时表现良好，但在我们测试中，对于如道路网络等分布式基础设施特征的敏感度有所下降。

我们原本预计 Amazon Titan 多模态嵌入 G1 会表现得非常接近。但它并没有。其在游泳池上的平均 F1 分数为 0.340，显著低于 Amazon Nova 多模态嵌入的分数。更糟糕的是，在基于图像的搜索中，几种配置的 F1 分数几乎接近于零：模型返回的结果几乎完全不相关。这些情况并不是孤立事件，它们在特定融合和搜索方法组合中持续出现。

图 7. 各嵌入模型在两个基准查询中的平均 F1 分数。

实际的启示是：模型选择对地理空间搜索质量有显著影响，且这种影响因特征类型而异。对于道路，两种特征类型在不同模型中的性能差异明显。如果你正在 AWS 上启动一个地理空间搜索项目，可以默认使用 Amazon Nova 多模态嵌入。

实验 2：每个位置应如何处理七张图像？

每个瓦片有七张图像，这带来了索引上的两难。你可以将它们分别存储（每个瓦片有 7 个嵌入），合并成一个（融合），或者让模型原生处理组合。

我们测试了四种方法：

• 每个视角的嵌入：每个瓦片有 7 个独立的向量，每个向量都可以独立搜索。在查询时，结果会跨视角进行汇总。

• 晚期融合（平均/最大池化）：计算 7 个嵌入，然后将它们平均或最大池化为一个向量。索引更简单，但合并后的向量会丢失视角特定的信号。

• 注意力融合：一个 LLM 根据查询为每个视角分配权重，然后加权组合生成一个嵌入。例如，“游泳池”查询可能将正射影像的权重设为 0.4，而“高层建筑”查询可能将 DSM 的权重设为 0.35。

• Cohere 批量：Cohere Embed v4 的原生多图像 API 在一次调用中处理七种视角，生成一个内部捕捉跨视角关系的嵌入。

图 8. 各融合策略在两个基准查询中的最佳 F1 分数。

对于游泳池，三种策略（Cohere 批量、注意力融合和晚期平均）各自达到了 0.638 的平均 F1 分数，这是最高分数（图 8）。每个视角的方法表现较差，为 0.612，这主要是因为在跨 7 个独立嵌入字段操作时，元数据过滤行为不一致。Cohere 批量与每个视角之间的 4.2% 差距表明，融合技术的选择对可靠性有显著影响，尤其是在不同搜索方法之间。

对于道路，情况相反。注意力融合以 0.535 领先。晚期平均紧随其后，为 0.522。每个视角的方法为 0.485。Cohere 批量下降至 0.479，最佳与最差之间有 12% 的差距。在游泳池上并列第一的相同策略在道路上却排在最后。

没有一种融合方法在所有特征类型上都占主导地位。最佳策略取决于你正在搜索的内容。

实验 3：描述性文字是否有帮助？

我们使用了 Amazon Nova 2 Lite 同时从七个视角生成结构化描述。提示指令要求模型描述土地利用、建成环境、基础设施、自然特征以及在所有视角中可见的空间关系。结果是每个瓦片生成一个文本描述，综合了单个视角中无法单独包含的信息。

描述整合是我们测试的优化措施中影响最大的一项。

对于游泳池，最佳的 Amazon Nova 多模态嵌入配置结合描述整合（“两种方法”：图像和描述嵌入融合成综合评分）实现了最佳配置的 F1 分数为 0.638，而未使用描述时的 F1 分数为 0.573。这是 11% 的提升。对于道路，差距更大：13%（F1 分数为 0.555 对比 0.490）。

让我们感到意外的是：描述整合策略比嵌入模型的选择更重要。Cohere Embed v4 和 Amazon Nova 多模态嵌入在与最佳描述整合配对时，对于游泳池都实现了相同的最佳配置 F1 分数 0.638。描述提供了文本基础，弥补了视觉嵌入质量的差异。

但仅靠描述是不够的。仅文本搜索（将查询词与描述匹配，不使用图像嵌入）在游泳池上的 F1 分数下降了 17%，达到 0.532。视觉信号携带了文本描述中缺失的信息。最佳结果来自于结合两种模态。

描述模型的选择对后续处理有可衡量的影响。不同的描述模型在描述中生成了不同的词汇，这影响了后续基于标签的过滤。在某些情况下，一个模型的描述发现了另一个模型遗漏的特征，导致基于元数据过滤的搜索 F1 分数不同。如果你的流程使用基于标签的过滤，描述模型的词汇直接影响召回率。

我们还测试了 DSM 和 DTM 数据是否有助于目标检测。结果是它们没有帮助。使用 4 个视角（正射 + 斜视）的配置与使用 7 个视角（包括高程）的配置相匹配或更优。对于标准目标检测任务，如游泳池和道路，可以跳过高程数据；它增加了嵌入成本，但并未提高准确性。

实验 4：正确的搜索方式是什么？

我们实现了五种搜索方法（图 9），每种方法代表了复杂度、成本和准确性之间的不同权衡。

基本 k-NN：直接对聚合图像嵌入进行向量相似度搜索。延迟最低，无需额外的 FM 调用。当描述已经包含在索引中时，这是默认的正确方法。

图像 + 描述融合：分别对图像嵌入和描述嵌入字段进行并行 k-NN 搜索，然后使用可调节的 alpha 权重（默认 0.7 图像 / 0.3 描述）融合评分。同时捕捉视觉和语义相似度。

元数据过滤：在向量搜索之前应用基于标签的预过滤，将候选集缩小到生成标签与查询词匹配的瓦片。当用户提到已知特征（如“游泳池”或“停车场”）时，这是最快的路径。

图 9. 显示五种方法及其可用性指示的搜索页面

仅文本搜索：在描述字段中进行关键词匹配，不使用向量相似度。

7种图像融合方式：在七个视图嵌入字段和标题中并行执行k-NN搜索，同时根据每个查询动态分配权重。一个FM分析搜索查询，并为每个视图分配相关性权重。例如，“棒球场”查询将正射影像的权重设为约0.3，用于场地标记；而“多层建筑”查询将DSM的权重设为约0.35，用于高度数据。加权得分将合并为最终排名。

没有一种搜索方法在所有特征类型上都占主导地位。最佳策略取决于你正在搜索的内容，因此系统暴露了每种方法，并且评估框架会衡量哪种方法在每个查询类别中表现最佳。

以下表格总结了每种搜索方法在我们两个基准查询中的表现。对于游泳池，多种方法达到了相同的最高F1分数，而道路则表现出更明显的差异。

游泳池

搜索方法

最佳配置F1

使用场景

基本k-NN

0.638

通用型，低延迟

图像 + 标题融合

平衡的多模态查询

元数据过滤

高精度目标检测

纯文本

0.532

低成本，视觉特征不具决定性

7种图像融合

—

查询映射到特定视角

道路

备注

基本k-NN（Nova标题）

0.524

基础设施最佳整体表现

0.506

视觉特征优于标题信号

0.395

道路描述过于多样化，无法进行纯文本匹配

0.358

道路描述的标签匹配不一致

游泳池的F1分数为0.638的三种方法：基本k-NN、图像 + 标题融合和元数据过滤。对于道路，基本k-NN表现最佳，得分为0.524。最佳搜索方法完全取决于特征类型。

元数据过滤显示出最明显的对比。它在游泳池上表现最佳，因为FM提取了“游泳池”的标签，与标题文本精确匹配，从而在k-NN之前实现了严格的预过滤。对于道路，它下降到0.358。标题中的道路描述更加多样化，标签也不够一致，使得关键词预过滤不可靠。

图像 + 标题融合方法计算加权组合：α × 图像得分 + (1−α) × 标题得分。我们测试了手动调整的权重和FM分配的动态权重。两者在游泳池上的F1得分均为0.638。对于这些相对简单的查询，手动调整已经足够。动态加权可能在复杂、多方面的搜索中更有价值，其中最佳alpha因查询而异；例如，“靠近水的住宅区有商业建筑”需要不同的图像与文本权重，而不是“停车场”。

如果你要选择一个搜索方法作为起点，基本k-NN在标题丰富的嵌入上表现最一致，适用于各种特征类型。当识别出某些查询类别表现不佳时，可以添加专门的方法。

我们学到的经验

在对两个基准查询测试了约100种配置后，以下七个发现成为构建地理空间语义搜索系统的最实用指导：

• 从Amazon Nova多模态嵌入开始。它在游泳池（0.621）和道路（0.555）的配置中提供了最高的平均F1分数。你可以将其作为地理空间语义搜索的强默认选项。

• 整合 FM 生成的描述信息。这是我们测试中 ROI 最高的优化方式：对于水池，F1 分数提升了 11%；对于道路，提升了 13%。这种提升效果甚至超过了切换嵌入模型或调整融合策略。如果你在基线 k-NN 搜索之外只做一件事，那就是添加描述信息。

• 对于标准目标检测，跳过高程数据。DSM 和 DTM 对水池或道路的性能提升没有可测量的影响，同时增加了约 40% 的嵌入成本（七种视角对比五种）。将高程数据保留给那些高度信息具有语义相关性的查询任务，例如建筑分类、洪水风险评估或植被冠层分析。

• 根据特征类型匹配融合策略。注意力融合最适合分布式的基础设施（如道路）。对于离散对象（如水池），Cohere 批处理、注意力融合和晚期平均效果相当；当特征在视觉上明显时，融合策略的选择影响较小。没有通用的最佳选择，因此你可以使用评估框架来确定每类查询的最佳设置。

• 根据查询类型选择搜索方法。带有描述信息的基本 k-NN 搜索最适合低延迟下的视觉明显特征。对于已知标签的查询，元数据过滤速度最快。FM 加权融合适用于复杂、多维度的查询，其中最佳视角权重因查询而异。避免使用纯文本搜索。

• 首先构建评估框架。我们在两种查询类型中测试了约 100 种配置。如果没有与 OpenStreetMap 真实数据进行自动化评估，这将需要数周的手动检查。该框架是主要交付成果：它能够随着新模型的发布和新特征类型的增加，持续找到最佳配置。

• 为生产规模下的成本效益操作做好规划。全球图像语义搜索的成本主要由一次性索引和嵌入流程决定。一旦完成嵌入，查询时的搜索成本可以忽略不计，与文本、音乐或视频等领域的搜索相当。相比之下，在运行时让模型分析像素本质上成本很高，但可以通过优化来最小化。

结论与下一步

这次合作证明了多模态 AI 可以将航拍图像从一个你浏览的视觉档案转变为一个你可以查询的知识库。几年前，对数百万地理瓦片进行自然语言搜索（这需要手动检查或定制训练模型）现在可以通过通用基础模型（FMs）和标准 AWS 服务实现。

这一切之所以成为可能，得益于 AWS 与 Vexcel 的紧密合作：我们带来了机器学习架构和评估方法，而 Vexcel 则带来了领域专业知识、真实世界数据和生产需求，使工作始终扎根于实际应用场景。

模块化架构意味着当更好的模型出现时，Vexcel 不需要重新构建整个流程。当新的 Amazon Nova 或 Cohere 模型在 Amazon Bedrock 上发布时，只需进行配置更改即可替换使用。评估框架会立即检测新模型是否提升了效果。

除了搜索流程，AWS GenAIIC 还提供了一个 AI 驱动的代码入门聊天服务，该服务通过 Amazon CloudFront 提供，由 Amazon Bedrock 支持，使 Vexcel 工程师能够用自然语言询问代码库本身的问题。例如，“应用程序中有哪些嵌入融合方法？”或“我应该修改哪个文件以添加更多的描述生成模型？”等问题会返回针对性答案，减轻工程师在继承系统时手动探索代码的负担。

这项工作的最强验证来自于 Vexcel 对它的应用。此次合作中所采用的概念和架构已经演变为 Vexcel Intelligence，这是一款目前处于预览阶段的产品，它提供了可搜索的向量嵌入、API 以及一个适用于 Vexcel 全球影像库（覆盖 45 个国家以上）的应用程序。像“地中海风格的住宅，配有地下泳池和网球场”或“日本境内可用于增加设备的通信塔”这样的查询，也就是我们在芝加哥格兰特公园原型设计时所展示的语义搜索，现在已经成为生产功能。

我们的评估涵盖了某一地理区域内两种类型的查询。Vexcel 的生产路径分为三个阶段：首先在高价值地区进行集中部署，然后随着评估框架验证性能，逐步扩展到更广泛的地理区域，最终实现对其全球影像库的全面覆盖。在每个阶段中，用于衡量、比较和优化的工具已经就绪。

关于作者

'"`