作者简介
Franky Yang，携程技术专家，关注多模态与 AI 系统工程，尤其是知识与检索底座、平台架构以及系统的可靠性和持续进化能力。
导读：随着酒店图片、视频等内容资产持续增长，图搜、首图精选、图片质检、视频理解等场景不断扩展，单点模型和独立链路逐渐难以支撑复杂的业务需求——重复计算、版本不一致、效果难以复现和回滚等问题，也开始成为多模态能力规模化落地的工程瓶颈。
为此，我们建设了一套面向酒店内容场景的多模态理解平台，将数据接入、模型编排、向量检索、内容理解、评测灰度和治理回流串成完整闭环，让图片、视频和文本等内容资产能够被稳定理解、检索、复用和持续迭代。
如果你正关注多模态 AI 工程化、向量检索、模型评测治理，或 AI 基础设施的平台化建设，希望这篇分享能带给你一些启发。
一、背景信息
二、从单点能力到平台化基建
三、总体架构：数据、模型、检索与治理闭环
四、数据底座：把模型结果变成可治理资产
五、向量链路：面向大规模内容的检索中枢
六、内容理解：从图片扩展到视频
七、评测、灰度与可观测：让模型迭代可控
八、阶段性效果与工程沉淀
九、总结：可复用的工程经验
一、背景信息
酒店首图
酒店相册
酒店视频
图搜酒店
当用户预订酒店时，图片和视频往往比文字更先影响决策：房间是否宽敞、窗外视野如何、早餐区是否干净、泳池和健身房是否真实可用，这些信息都藏在海量内容资产里。
但对工程系统来说，酒店图片和视频并不只是“展示素材”。它们需要被理解、检索、精选、质检和复用：用户想用一张图找到相似房型，运营希望从素材库中快速挑出适合首图的图片，平台需要持续识别低质、水印、拼接或误导性内容，视频也需要被拆解成可搜索、可审核、可摘要的结构化信息。
随着内容规模持续增长，单点模型很难支撑这些复杂场景。图片分类、图文检索、质量检测、首图评分、视频摘要看似是不同问题，但底层都依赖同一件事：如何把多模态内容转化为稳定、可复用、可评测、可治理的数据资产。
围绕酒店内容场景，我们建设的不是单点模型服务，而是一套面向图片、视频和文本资产的多模态理解平台。平台将数据接入、模型编排、向量检索、评测灰度和治理回流串成闭环，让图搜、首图精选、图片质检巡检、视频理解等场景可以在同一套底座上组合能力、复用资产、持续迭代。
在真实业务环境中，平台面对的复杂度不只是“多跑几个模型”，而是大规模内容资产的长期治理：存量图片与视频、日新增素材、标签结果、质量分、风险识别结果、Embedding 特征和索引版本会共同形成多层衍生数据。内容规模越大，重复计算、版本不一致、效果不可复现和回滚困难就越容易变成系统性问题。
二、从单点能力到平台化基建
多模态项目早期往往从具体问题出发：图片分类、风险识别、图文检索、视频摘要等能力可以分别上线。但随着场景增多，如果每个需求都独立接模型、建数据链路、做评测和上线治理，系统复杂度会快速放大。我们希望建设的不是一批孤立能力，而是一个可以持续装配业务场景的内容 AI 平台。
平台化之后，业务场景不再从零建设链路，而是按需组合能力模块：图片标签、质量分、Embedding、风险识别、向量召回、重排策略、人工反馈和评测集都可以像积木一样被复用。不同场景的差异，主要体现在积木的组合方式、阈值策略和业务约束，而不是底层链路的重复建设。
三、总体架构：数据、模型、检索与治理闭环
整体架构可以理解为一个面向酒店内容的多模态理解平台：底层接入图片、视频、文本和用户反馈，中间沉淀标签、质量分、风险结果、Embedding 和索引版本，上层通过模型编排、向量检索、任务调度、评测灰度和可观测能力对外服务。各层之间通过标准化协议和版本治理连接，避免模型、存储和业务逻辑深度绑定。
在线链路面向低时延请求，优先读取已有资产；缺失时按策略触发计算，并通过降级、缓存和超时控制保证稳定性。离线链路面向增量回填、存量刷新和大规模索引构建，通过异步编排、批量调度和资源隔离提升吞吐。
这套架构的关键不是引入某一个模型或某一个引擎，而是让每个组件都可以被替换、评测、灰度和回滚。模型在变化，数据规模在变化，业务诉求也会变化，基础设施必须先具备稳定演进的能力。
3.1 典型场景如何在架构里跑起来
不同场景使用的模型和阈值不同，但底层路径是相通的：先把内容资产标准化，再形成可复用的模型结果，最后通过检索、排序、治理或生产工具对外提供能力。
3.2 链路实战：一次图搜请求如何跑起来
以图搜 / 文搜图为例，用户或运营同学提交一张图片、一段文本描述或一组筛选条件后，系统并不会直接调用单个模型返回结果，而是经过“资产读取、特征生产、向量召回、结构化过滤、重排治理、反馈回流”几个阶段。每个阶段都对应前面提到的平台能力，也都可以独立评测、灰度和回滚。
这条链路的重点不是“多调用几个模型”，而是让每次模型升级、索引重建或排序策略调整都有明确的版本边界、评测口径和回滚路径。只有链路可治理，图搜能力才能从一次项目交付变成长期可迭代的基础能力。
四、数据底座：把模型结果变成可治理资产
多模态系统的第一层能力是数据底座。过去，模型输出常常只是一次接口调用的返回值；在平台化体系中，它需要被注册、存储、查询、评测和复用。
Schema 注册：为不同类型的算法结果建立统一描述，支持多版本演进、跨介质存储、压缩策略和降级策略。
模型管理：将垂域模型、Embedding 模型和多模态大模型纳入统一注册体系，模型版本与数据 Schema 显式绑定。
查算分离：优先查询已有版本化结果，缺失时再触发计算，减少重复推理并提升资源利用率。
资源编排：在线请求走低时延同步通道，批量刷新和存量任务走异步通道，并通过优先级和集群隔离削峰填谷。
中间结果缓存：支持多模型流水线编排、断点续跑、失败重试，让复杂任务具备工程可恢复性。
数据底座的价值不只在节省算力，更重要的是把“模型结果”沉淀为组织可复用的工程资产。后续模型替换、场景扩展、效果回溯，都可以基于同一套资产体系完成。
从量级上看，平台需要同时处理“原始内容规模”和“衍生结果规模”：一张图片或一个视频片段可能对应多类标签、多个模型版本、不同维度的质量/风险结果，以及多套 Embedding 和索引版本。随着存量回填、日常增量和模型升级持续发生，元数据平台承担的是长期可追踪、可回放、可复算的资产治理能力。
把内容理解结果资产化：不只负责调用模型，还要把不同模型、不同版本、不同任务产出的结果统一写入元数据平台，供检索、精选、巡检和视频理解复用。
五、向量链路：面向大规模内容的检索中枢
多模态理解不仅要能“看懂”，还要能“找得到”。在酒店内容场景里，图搜和文搜图是最典型的检索能力：用户或运营同学可以用一张图片、一段文本描述、一个标签组合，找到语义相近、风格相似或满足筛选条件的图片与视频片段。向量链路承担的是高吞吐、低延迟、可扩展的召回底座。
5.1 引擎可插拔
我们在向量服务层屏蔽底层搜索引擎差异，将 Elasticsearch、Milvus、Zilliz 等能力抽象成统一接口。上层业务不直接依赖具体引擎，下层可以根据规模、延迟、召回效果和运维成本独立选型。
5.2 索引全生命周期管理
索引构建不是一次性任务，而是持续演进的工程系统。平台支持全量重建、增量回填、批量刷新、快速回滚和索引版本追踪，让模型升级、特征变更和数据扩容都有明确的发布路径。
5.3 Embedding 统一评测
Embedding 模型决定了跨模态召回的上限。我们将模型接入、评测集、离线 Benchmark、线上灰度和回滚串联起来，用统一口径比较不同模型在相关性、细节感知、延迟和资源成本上的表现。
在部分检索链路中，通过引擎升级和索引结构优化，平均延迟和尾延迟都有明显下降，吞吐能力获得倍数级提升。更重要的是，这些优化被沉淀成可复用的接入基线，而不是只服务于单个项目。
5.4 图搜链路的数据流
以图搜和文搜图为例，系统不会把检索做成单一接口，而是拆成内容入库、特征生产、索引构建、在线召回和效果评测几段。这样 Embedding 模型、向量引擎、索引结构和重排策略都可以独立升级。
六、内容理解：从图片扩展到视频
内容理解层采用“垂域模型、Embedding 模型、多模态大模型”协同的方式。垂域模型负责稳定的结构化识别，Embedding 模型负责语义召回，多模态大模型负责更复杂的主观语义理解和泛化判断。
6.1 图片理解的几类典型用法
图片理解并不是单一“识别图片里有什么”的问题。落到酒店内容里，它通常会拆成质量、语义、风险和吸引力几类信号，再按不同场景组合使用。
6.2 质检巡检闭环：从问题发现到样本回流
质检巡检面对的是持续变化的问题空间：低质、遮挡、水印、拼接、误导性、合成内容等问题并不会一次性被穷尽。平台将离线巡检、在线抽验、人工确认和样本回流串成闭环，让新问题可以持续进入评测集和模型迭代流程。
首图精选、图搜、质检巡检并不是三套彼此割裂的系统。它们共享图片标签、质量分、Embedding、风险结果和人工反馈，只是在不同场景里采用不同的组合方式。
图片理解链路将检测、打标、语义理解和检索结果统一沉淀到元数据平台。这样做的好处是，下游不需要反复调用不同模型，而是按版本读取稳定结果；当模型升级时，也可以通过评测和灰度机制验证后再逐步替换。
视频理解则采用“复用优先”的路线：先进行镜头分割和关键帧抽取，再复用已有图片理解能力完成分类、检测、打标和向量化，最后结合多模态大模型生成摘要、主题和可检索语义。这样可以把视频能力建设从重工程投入转为在既有图片能力上的薄层扩展。
七、评测、灰度与可观测：让模型迭代可控
多模态能力的难点不只是模型效果，还包括如何证明效果、如何稳定上线、如何在问题出现时快速回滚。因此，评测与实验能力必须内建到基础设施中。
Benchmark 套件：沉淀标准评测集，覆盖常见检测、检索、理解和生成类任务。
自动化评测：模型提交后触发预跑、指标计算和准入判断，减少临时脚本和人工对齐成本。
人工抽验：对主观语义、复杂风险和边界样本保留人工校验入口，形成模型迭代样本池。
灰度与回滚：按模型版本、数据版本、索引版本和算子版本切流，出现异常时可快速回退。
全链路监控：覆盖任务队列、计算资源、索引更新、检索延迟、模型命中和结果分布等核心指标。
多模态模型的上线不应只看单次离线指标。更稳妥的方式是把离线评测、线上灰度、人工抽验和结果回流组合起来，让系统持续学习，同时保证发布过程可解释、可观测、可回滚。
八、阶段性效果与工程沉淀
经过平台化建设，多模态能力从“项目内能力”逐步沉淀为“跨场景基础设施”。图搜、首图精选、图片质检巡检、视频理解等场景可以复用同一套数据资产、模型注册、任务编排、向量检索和评测灰度能力；重复计算显著下降，模型接入周期由周级缩短到天级，检索延迟和离线资源利用率也获得明显优化。
对工程团队来说，最大的变化是交付模式的变化：过去每个新需求都需要重新拼接数据、模型、脚本和评测；现在可以基于统一平台完成配置、接入、验证和发布。能力复用让团队把更多精力放在模型效果和产品体验上，而不是重复建设底层链路；新场景也可以通过组合已有能力快速试错、灰度和放量。
九、一些可复用的工程经验
先做资产化，再谈智能化。如果模型结果无法被查询、追踪和复用，智能能力越多，系统复杂度越高。
模型要可替换，数据协议要稳定。多模态模型会持续演进，工程系统需要把模型变化限制在可控边界内。
评测要平台化，而不是脚本化。只有评测集、指标、人工抽验和灰度流程沉淀下来，模型迭代才不会依赖个人经验。
视频能力优先复用图片能力。通过关键帧和片段级建模，可以在较低成本下获得可用的视频理解链路。
可观测和回滚是 AI 基建的一部分。模型上线后的分布漂移、延迟抖动和边界样本问题都需要工程化兜底。
多模态 AI 的价值不只来自模型本身，更来自模型背后的工程系统。只有当数据可治理、模型可替换、计算可编排、检索可扩展、效果可评测时，多模态能力才能从一次次项目交付，真正变成长期复用的技术底座。
【推荐阅读】
“携程技术”公众号
分享，交流，成长