亚马逊AWS官方博客

在长视频里“大海捞针”，用多模态 RAG 构建无人机炸机分析系统

摘要：无人机事故分析通常需要在飞行监控数据与长时视频中交叉定位关键证据，人工排查耗时且容易遗漏。本文介绍一套基于 Amazon Nova、Amazon S3 Vectors、MCP 及 Amazon Quick Suite / Quick Desktop 构建的 PoC 工程化方案。系统通过多模态特征提取、任务级向量检索和双路候选合并，快速定位异常片段，再由大模型结合上下文完成事故复盘与原因分析。文章重点分享“重检索、轻生成”的设计思路、关键工程取舍与实践经验，为复杂时序、多模态故障分析场景提供参考。

一、问题：分钟级视频里的 2 秒钟

在无人机作业（如农业植保）的规模化运营中，“炸机”（无人机坠毁）是一类绕不开的事故。每一起炸机背后都涉及故障定责：是设备故障、环境因素，还是飞手操作不当？定责结果直接关系到赔偿处理和飞手管理，因此对准确性要求很高。

传统做法是由专人逐一回看 FPV 飞行录像、比对飞行日志与监控数据，再手工撰写分析报告。这套流程有三个固有矛盾：

  • 信息稀疏：炸机录像总时长是分钟级的，但真正有价值的坠毁瞬间往往只有 2~3 秒。人工要在大段正常飞行画面里精准定位这几秒，效率极低。
  • 质量与一致性：定责报告的口径依赖分析人员的经验，难以标准化。
  • 成本不可线性扩张：随着作业量增长，事故数量同步上升，纯人工分析的人力成本无法跟上业务规模。

我们的目标很明确：用 GenAI 将分析效率提升到可规模化验证的水平，并把故障定责嵌入流程。PoC 阶段以资深分析人员的判断为参照，团队基于样本观察和业务经验，将“约 70% 的可用效果”作为方向性估算，而非经过严格基准测试得出的统计结论。

二、为什么不直接把整段视频交给大模型

最朴素的想法是把整段视频直接交给多模态大模型分析。我们做了几轮验证。在当时使用的模型、样本和成本约束下，直接分析整段视频的稳定性不足，主要表现在：

  • 直接喂完整视频：当关键事件只占整段视频极小比例时，模型容易被大量正常飞行画面干扰，关键坠毁瞬间可能在长上下文中被遗漏，输出未能稳定命中故障点。
  • 依赖通用的视频自动解析：在我们当时测试的方案和配置下，解析结果对“异常从哪一帧开始”这类时序动态线索不够敏感，效果与直接分析整段视频相近。这里的结论仅针对本次 PoC 的测试范围，不代表所有视频理解方案。

这导向一个核心设计原则：先定位，再理解。必须先用检索手段从长视频里把“炸机瞬间”这几秒切出来，再交给多模态模型做精读。这正是检索增强生成（RAG）的思路，只不过检索对象从文本变成了视频片段。

三、设计思路：把 RAG 从文本搬到视频上

如果你要从零构建一套类似的视频分析系统，可以把它抽象成一条“检索增强的视频理解”管线，核心是五个环节，以及每个环节背后的关键权衡。这套蓝图并不限于炸机场景，任何“长视频 + 稀疏关键事件”的问题都适用（安防、质检、医疗影像回放等）。

  1. 分段（Segmentation）——粒度是第一个权衡。 视频必须先切成片段才能逐段编码检索。分段太长，关键瞬间会被无关画面稀释，回到了“喂整段视频”的老问题；分段太短，又会丢失动作的上下文（比如一次完整的姿态失控）。本次 PoC 选择 15 秒作为默认粒度，并让它可配置，方便按场景调参。
  2. 向量化（Embedding）——选一个跨模态统一的嵌入模型。 这是整条管线的地基。要实现“用一句话检索一段视频”，文本查询和视频片段必须落在同一个语义空间里。如果嵌入模型只能处理单一模态，你就被迫在中间插入“视频转文字描述”的环节，既丢信息又增误差。
  3. 检索定位（Retrieval）——把上下文从分钟级压缩到秒级。 用向量近邻检索召回与查询最相关的片段，把后续大模型的处理范围从完整视频缩小到少量候选片段，从而降低输入规模和推理成本。
  4. 多路候选合并（Candidate Aggregation）——单一路召回往往不够。 语义检索擅长找“内容相关”的片段，但很多关键事件（如坠毁瞬间）的信号是运动学层面的（剧烈晃动、姿态突变），语义上不一定最突出。一个更稳健的系统可以叠加第二路、甚至第三路互补的召回信号，再将候选统一汇总。
  5. 多模态精读（Read）——重检索、轻生成。 定位完成后，把合并后的少量候选片段交给多模态大模型做精读和报告生成。由于输入范围已经缩小，可以在模型能力、成本和处理时延之间做更灵活的权衡。

值得强调的是，我们选择自建这条处理管线，并不是因为托管能力无法完成视频分段——Nova Multimodal Embeddings 的异步接口已经支持按用户定义的时长切分长视频——而是因为本次场景需要把业务特定的分段策略、运动异常信号、候选合并和任务流程组合在一起。底层的模型推理和向量存储仍交给亚马逊云科技托管服务，自建精力集中在场景化处理与编排上。

接下来按“自下而上”的顺序，看这套蓝图在我们系统里的具体落地。

四、整体架构

系统分为三层，职责清晰：

[图 1 图 1：无人机炸机分析系统 PoC 总体架构]

下面逐层拆解技术实现和服务选型理由。

五、核心：双路候选合并的视频分析流水线

在本次 PoC 工程化版本中，Video Analysis Service 是计算核心，它是一个基于 FastAPI 的独立异步微服务，对外暴露两个 REST 端点：

  • POST /api/v1/analyze：提交任务（missionId + 视频地址列表 + 自然语言 prompt），目标在 2 秒内返回 job_id
  • GET /api/v1/jobs/{job_id}：轮询任务状态与结果

为什么是异步轮询模式？ 单次视频向量化可能耗时数十秒至数分钟，同步阻塞不适合此类任务。PoC 将任务放入后台处理，状态机在 pending → processing → completed/failed 之间流转，processing 内部又细分为 downloading → uploading → segmenting → vectorizing → retrieving → writing_results 多个子阶段，前端通过轮询近实时感知进度。这里验证的是异步接口与状态机设计；生产化还需要持久化状态和可靠任务队列，才能支持多进程、重启恢复和横向扩展。

5.1 以 missionId 为单位的去重

missionId 是飞手单次飞行任务的编号，一次任务会产生多段视频。本次 PoC 将经过规范化的任务 ID 映射为 Amazon S3 Vectors 索引名，例如 mission-{normalized-id}：字符转为小写，仅保留字母、数字、连字符和点，并控制在 3–63 个字符。当前 PoC 通过索引是否已有数据判断能否复用；更稳妥的生产实现还应同时校验输入清单和“向量化完成”标记，避免复用前次失败留下的部分结果。

这使同一组已完整向量化的视频在后续查询中无需重复处理，可直接进入检索阶段。对于一起事故可能被反复多角度追问的场景，这个设计可以减少重复计算。

需要注意，S3 Vectors 每个 vector bucket 最多支持 10,000 个索引。因此，“一次任务一个索引”适合当前 PoC 和有限规模场景；规模扩大后需要引入索引生命周期与分桶策略，或采用共享索引并通过 missionId metadata filtering 做逻辑分组。

5.2 路径 A：向量检索做语义定位

这是“先定位”的主力：

  1. 视频从外部对象存储下载到本地临时目录（httpx，带重试）
  2. 上传至 Amazon S3（videos/{missionId}/）做持久化
  3. 用 ffmpeg 按固定时长分段（默认 15 秒）
  4. 每个分段通过 Amazon Nova Multimodal Embeddings（Nova MME）生成 1024 维向量
  5. 向量写入 Amazon S3 Vectors
  6. 查询时把自然语言 prompt 用同一个 Nova MME 编码成 query 向量，做 top-k 近邻检索

为什么选 Nova MME？ 它把文本、图片、视频编码到同一个语义空间，这是“用一句话检索一段视频”得以成立的前提——我们可以直接用 prompt 向量去匹配视频片段向量，无需中间的文字描述转换。多模态向量检索正是 Nova MME 的核心优势所在。它支持最长 30 秒的视频片段编码，与我们 15 秒的分段粒度天然契合；同时支持 256/384/1024/3072 多种维度，我们选 1024 维在检索精度和存储/性能之间取得平衡。

为什么选 S3 Vectors？ 按亚马逊云科技官方公开口径，相比传统方案，它可将向量上传、存储和查询的总成本降低最高 90%，并支持向量相似度查询与 metadata filtering。在当前 PoC 规模下，按 missionId 划分索引使任务级复用和逻辑分组更直观，但它不是无限扩展模型；生产化仍需结合配额、生命周期和查询模式，评估是否改用共享索引。

5.3 路径 B：OpenCV 关键帧做视觉补充

PoC 测试中我们发现一个问题：纯向量检索仍会漏掉部分炸机关键瞬间。语义检索擅长找“画面内容相关”的片段，但坠毁那一刻往往伴随剧烈的运动学特征（机身剧烈晃动、姿态突变），这类信号在语义层面不一定最突出。

于是我们补了一路基于 OpenCV 的关键帧提取：每 0.5 秒采样一帧，结合相邻采样帧的视觉变化特征筛选剧烈晃动、姿态异常的候选帧。这一路不依赖语义，从运动异常的角度补充候选，与向量检索形成互补。

5.4 双路候选合并 + 多模态精读

两路召回的结果——向量检索的 top-k 片段和 OpenCV 关键帧——先合并为候选集合，再送入 Amazon Nova 2 Lite，通过 Bedrock Converse API 做逐片段语义理解与汇总分析，最终结构化结果写入 S3（results/{job_id}/result.json）。

为什么选 Nova 2 Lite？ 定位阶段已经把上下文从“分钟级长视频”缩小到“几个候选片段”，精读阶段不再需要模型直接处理整段视频。Nova 2 Lite 的多模态理解能力配合 Converse API 的统一多模态接口，是本次 PoC 在成本和效果之间的折中选择；实际质量与成本仍需结合业务样本持续评估。

5.5 PoC 工程化：为后续生产化打基础

PoC 到生产之间仍有大量工程工作。本次版本已经实现统一重试策略（最大 3 次、指数退避、按错误类型区分可重试/不可重试）、分层异常、缺失必需配置时 fail-fast，以及 83 个以 mock 为主、无需亚马逊云科技凭证即可运行的单元测试；部署形态采用 gunicorn + uvicorn worker。需要说明的是，asyncio.Lock 只能保障单进程内的任务状态并发安全，因此当前版本更准确的定位是“PoC 工程化版本”。若进入生产，还需要补充持久化任务队列、跨进程状态存储、重启恢复、可观测性和容量治理。

六、网关层：让编排工具“静默”调用工具

计算核心之上，需要把“视频分析”和“监控数据查询”两类能力暴露给上层编排。我们选择 Amazon Bedrock AgentCore Gateway + 自建 MCP Server 的组合。

AgentCore Gateway 负责认证与协议路由：它对接 Amazon Cognito User Pool，走 OAuth2 client_credentials 流程签发 JWT，客户端凭 token 访问，Gateway 完成认证后再以 MCP 协议路由到后端工具。选它的理由是把认证、鉴权这类横切关注点从业务代码里剥离到托管网关，后端 MCP Server 只需专注工具逻辑本身。

后端 MCP Server 基于 FastMCP SDK 自建，采用 Streamable HTTP 的 stateless 模式（兼容 Gateway 的会话管理与负载均衡）。

这里有一个值得分享的“踩坑与突破”。我们用 Amazon Quick Suite 的 Flow 做编排时，发现部分工具调用会出现用户确认弹窗。随后我们在自建 MCP Server 中补齐 tool annotations，并验证在当时使用的 Quick Suite、AgentCore Gateway 与 FastMCP 版本组合下，Gateway 能将这些 annotations 暴露给上层。需要特别说明，annotations 只是工具行为提示，必须与真实副作用一致：监控查询可以标为只读；会创建任务并写入 S3 的视频分析工具不能标为只读。是否允许免确认执行，仍由受信任客户端或编排策略决定；idempotentHint 也只有在请求具备真正幂等语义时才应启用。

以下问题均发生在当时使用的 FastMCP、MCP SDK 与 AgentCore Gateway 版本组合中，属于版本相关经验，而非对当前版本的普遍结论：

  • Starlette Mount 路径叠加：当时 app.mount(“/mcp”, …) 会与 FastMCP 默认路径叠加成 /mcp/mcp，改为直接使用 FastMCP 提供的 Streamable HTTP ASGI app 后解决。
  • DNS Rebinding 保护：当时的 MCP SDK 默认主机校验会拒绝未显式允许的域名并返回 421，需要将实际服务域名加入允许列表。
  • outputSchema 兼容性：在当时的 FastMCP 与 Gateway 版本组合中，默认生成的 outputSchema 会触发解析错误，PoC 通过临时兼容处理规避。该做法不应被视为长期方案，发布或升级前需要先在当前版本重新验证。

工具定义同步：Gateway 使用 DEFAULT listing mode 时，工具描述或 annotations 发生变化后，需要重新同步 target capability catalog，确保上层获取最新定义。

七、编排与报告层：Amazon Quick Suite / Quick Desktop

最上层由 Amazon Quick Suite / Quick Desktop 承担：用户用自然语言发起分析，由它编排对各工具的调用，并基于汇总数据生成最终的炸机分析报告。

选它的理由在于“最后一公里”的报告生成质量——结构化、可读、贴近人工报告口径的输出，正是 Quick Suite / Quick Desktop 的强项，而这恰恰是把模型分析结果转化为业务可用交付物的关键环节。

八、方案的后续改进空间

诚实地讲，当前方案还有清晰的改进空间，其中最关键的是反馈闭环的缺失。

反馈闭环（最值得做的一步）。 目前系统是“一锤子买卖”：分析完即结束，无法从分析人员的判断中学习。理想做法是把双路召回的关键帧和高相似度片段呈现给分析人员打标签——确认哪些片段是真正的炸机瞬间、属于哪类故障（电线碰撞、信号丢失、操作失误等）。这些标注既能即时纠偏，又能沉淀成结构化的炸机案例库。

从“文本检索视频”扩展到“视频示例检索视频”。 当前主要走“文本 prompt → 视频片段”的跨模态检索。文本 prompt 便于表达分析意图，但对细粒度动作、姿态和场景特征的描述能力有限。案例库积累后，可以将新事故中的候选视频片段与经人工确认的历史视频或图像向量进行匹配，作为文本检索的补充。由于 Nova MME 把视频、图像和文本编码到统一语义空间，两种检索方式可以组合使用。更丰富的案例库只会扩大可检索覆盖；要真正提高准确率，还需要高质量标注、去噪、重排和持续评估。

其余改进方向包括：

  • 编排减负：把数据预处理前置——监控系统感知到炸机后自动整理相关视频数据，用 Bedrock 上的 Claude 模型先生成各维度分析数据，Quick Suite / Quick Desktop 只聚焦最终报告生成，避免把过多接口串行编排在 Flow 里导致流程冗长。
  • 召回规则增强：当前 OpenCV 关键帧只覆盖晃动/姿态异常，对电线碰撞、信号丢失等复杂场景识别有限，可引入更丰富的视觉特征。
  • 数据源扩展：逐步接入飞行日志、天气、地形等数据，并把视频分析、数据查询、案例检索封装为可复用的 Agent Skill。

九、小结

面对“长视频中的稀疏关键信息”这类问题，先检索定位、再多模态精读的两段式 RAG 是一个可复用的通用范式。在本次 PoC 中，我们用 Nova MME 做跨模态语义定位、用 OpenCV 关键帧补充运动异常候选，双路候选合并降低了单一召回方式漏检的风险；用 S3 Vectors 支持任务级复用；用 Nova 2 Lite 对候选片段做多模态精读；并借助 AgentCore Gateway、自建 MCP Server 与 Amazon Quick Suite / Quick Desktop 串联报告生成流程。

更进一步，一旦补齐反馈闭环，并把审核后的案例用于“视频示例检索视频”和候选重排，这套系统就有机会从一次性分析工具演进为可持续优化的分析平台。需要强调，案例数量本身不会自动带来准确率提升，数据质量、反馈机制和持续评估同样重要。而决定方案能否从 PoC 走向生产的，往往不是模型本身，而是持久化任务、去重、重试、可观测性和测试等工程能力。

十、参考资料

➡️ 下一步行动：

相关产品：

  • Amazon Quick — 人工智能助手，用于研究、业务洞察、自动化和无代码应用程序构建
  • Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
  • Amazon Nova — 提供前沿智能和最高性价比的基础模型
  • Amazon S3 Vectors — 云原生向量存储
  • Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

沈城伟

西云数据解决方案架构师，20 年 IT 服务经验，擅长智能体应用和开发，大型网站架构设计和系统管理。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用