多模态实时交互这个赛道最近有两件事值得放到一起看。一边是 Tavus 发布的全双工视频交互模型 Griffin带着所谓持续读懂表情动作的能力在 VideoFDB 的人像视频生成与感知榜单上拿了双料第一另一边是 Inworld 把语音智能体平台 Ultravox 收入囊中。两件事表面上一个在视频、一个在语音但底层其实是同一条主线实时多模态交互正在从能说会道走向能看懂、能回应、能接住突发事件。这两条进展对做对话系统、数字人、虚拟角色 AI 的团队来说都不是孤立的新闻而是直接改变选型和架构的信号。这篇文章我就围绕这两件事把背后的技术逻辑拆开讲清楚再补上一些实操层的东西尽量帮大家少踩坑。1. 全双工视频交互一场“对话范式”的升级1.1 全双工与半双工的本质区别先把这个词掰开。全双工Full-duplex是从通信领域借来的概念指双方可以同时发送和接收数据。放到人机对话里就是用户和 AI 不用轮流等对方说完可以边听边说、边说边被听就像两个人打电话时随时插嘴、随时回应那样自然。传统语音助手是典型的半双工模式用户按一下唤醒键开始说话说完停顿系统判断用户结束开始识别和处理最终播报回复。这个链条里每一环都是串行的交互节奏被静音检测 语音识别 大模型生成 语音合成四个环节的耗时绑死用户语速越快、内容越长等待感越明显。半双工还有一个致命问题当用户在听 AI 说话的过程中想打断时系统往往没有能力响应只能等当前播报完体验非常机械。截止到 2024 年很多大厂语音助手仍然采用半双工方案就是因为在全双工方案里打断处理、边说边识别、上下文的实时更新都是极高难度的工程问题。Tavus 这次发布 Griffin 打出全双工视频交互的旗号意味着它不只解决了语音层面的全双工还把视频画面中的表情、动作作为一个实时输入通道纳入到交互决策中。这里的难点不再是识别文字对不对而是在几百毫秒内完成多模态感知、意图判断和回应生成。1.2 视频通道加入后交互从“听见”变成“看见”语音助手解决的是听见这件事全双工视频交互解决的是看见。摄像头的数据流里藏着大量语音里捕捉不到的交互信号用户皱眉、微笑、点头、摇头、视线偏移、手臂交叉、身体后仰这些都比单纯的语言信息更早暴露用户的真实状态。举个实际例子。一个用户对 AI 说这个方案我挺满意的但与此同时他不断看手表、眉头微皱、身体往后靠。在纯语音系统里AI 只能根据文字内容判断用户满意做出正向反馈但在视频交互系统里多模态模型可以捕捉到这些强冲突信号——语言内容说满意非语言信息却在说我想离开。Griffin 的持续读懂表情动作强调的不是某一帧的判断而是在时间维度上跟踪表情动作的变化趋势把微表情的漂移纳入交互上下文。比如用户本来微笑但 AI 讲到某个具体参数时笑容消失、嘴角下垂系统就能定位到当前的沟通卡点。这种能力在真实交互里意义非凡。电话客服里我们只能通过语气和停顿猜测客户状态而视频客服里坐席能看到对方表情可以立刻调整话术。以前这项能力属于人类坐席的专属技能现在模型开始具备类似的感知链路这对远程销售、在线教育、心理陪伴等领域会带来比较直观的体验升级。1.3 这条技术路线最典型的应用场景全双工视频交互的应用场景我按落地难易度和收益排个序。第一梯队是数字人客服与远程座席辅助。银行面签、保险顾问、房产带看等场景原本就需要视频窗用户对面是经过培训的人类坐席有表情互动。现在把视频理解能力接入 AI 座席可以做一个全程陪伴的数字顾问实时观察用户表情在用户困惑时主动解释在用户犹豫时给出更多资料这种比问答机器人扎实得多。第二梯队是在线教育与虚拟面试训练。学生听课时走神、困惑、烦躁模型全都看在眼里系统可以动态调整讲解节奏。虚拟面试场景同理模型可以持续监测面试者的紧张度、表达过程中的微表情变化给出复盘报告。第三梯队是游戏与虚拟世界的角色 AI。这正好对应 Inworld 收购 Ultravox 那条线的意义——游戏 NPC 不再只是触发式对话而是能通过摄像头实时观察玩家的表情动作做出符合情境的反应比如看到玩家皱眉就换一条更简单的引导路径。这种体验沉浸感很强但工程链路也最复杂。2. Griffin 模型技术拆解“持续读懂”背后的四层能力很多宣传会把读懂表情包装得像魔法拆开看其实是有明确技术层级的。我把 Griffin 涉及的工程能力分成四层来理解视觉上下文输入、时序动作建模、流式推理与打断处理、多模态对齐。2.1 视觉上下文不止是“截一帧”持续读懂表情动作的这个持续很关键。如果只是每隔几秒截一张图做静态的表情分类那系统只是看脸不是交互。真正的视觉上下文需要的是连续的、实时的人脸信息。工程上一般分成两个阶段先做人脸检测与关键点定位再把关键点坐标、人脸区域图像、头部姿态等特征编排成结构化输入。关键点通常是 68 点或 106 点的人脸关键点覆盖眉毛、眼睛、鼻子、嘴巴、下巴轮廓头部姿态则用旋转矩阵或欧拉角表示用来判断点头、摇头、侧头等动作。这些特征相比直接把原始图像丢给模型维度小、语义更集中训练数据需求量也小一些。但这里有个工程取舍关键点特征丢掉了纹理信息用户肤色变化、微表情的肌肉牵动、眼眶湿润程度这些细节很难用关键点表达。所以更完备的方案是关键点辅助 视觉 Embedding 融合用视觉编码器从人脸上抽一个高维特征向量再把关键点、姿态这些低维特征拼接进去。利弊都清楚前者省算力后者效果好我见过不少团队为了省成本选了前者结果在表情复杂的场景里稳定性很差。2.2 时序建模动作是连续变化的不是分类标签人在交互中不会一直保持同一个表情情绪是随对话内容连续变化的。比如用户听 AI 介绍方案时经历好奇—困惑—放松—犹豫多个阶段表情在几十秒内会走完一条完整的变化曲线。要想抓住这个曲线模型必须有时间维度的建模能力。时序建模目前主流是视频 Transformer 或基于时序注意力机制的编码器。具体实现时把每秒 N 帧的人脸特征拼接成序列模型通过自注意力机制学习表情如何随时间变化。这种建模和单独判断每一帧的表情不同模型可以捕捉到刚才嘴角上扬现在微笑消失这种变化趋势而趋势往往比瞬时状态更能体现用户的真实态度。实操时一个很现实的坑是时间窗口的选取。窗口太长模型会被之前无关的表情干扰对当前状态的响应变慢窗口太短又容易误判瞬间动作。比如用户眨了一下眼如果窗口太短模型可能把它识别成闭眼表情导致系统产生用户是否疲劳的错误推断。合理的窗口一般选 1.5~3 秒还需要结合对话轮次切分在用户语音输入时降低视觉权重、在 AI 播报时提高视觉权重这样整体语义逻辑才不打架。2.3 流式推理与打断处理全双工交互对工程架构的挑战比模型本身更大。语音识别、大模型生成、语音合成流程都必须流式化几个环节并行流水线式工作让延迟控制在人耳舒适的范围内。视频通道也不轻松。摄像头实时帧要抽帧、降低分辨率、提取人脸特征、送入模型推理一级级往下传。每一级都会带来延迟帧率越高、模型越大延迟越高。业界的经验是视频通道不追求高帧率15~20 帧每秒足够捕捉大部分表情动作远高于这个数值只会浪费算力。分辨率同理人脸检测与表情识别不需要 4K 画面320~480 像素宽度的裁剪人脸区域就能满足多数需求。打断处理则是全双工里最难啃的地方。用户很可能在 AI 播放长回复到一半时插话等一下你刚说的那个方案能不能再解释一下系统此时要同时处理多个事件收到新的语音输入、暂停当前合成播报、保留上下文、重新组织回复。如果在播报时还叠加了视频通道扫描到的表情变化——比如用户插话时表情焦虑——系统还需要在暂停的同时感知用户情绪判断当前应该先道歉、先解释还是先安抚。这个决策链路在全双工里是实时多线程的任何一个环节阻塞都会让 AI 看起来反应迟钝。2.4 多模态对齐的工程代价多模态对齐听起来高大上实际落地时要做的其实就是让语音语义和视觉语义在一个统一的语义空间里互相校准。比如用户说好的同时摇头模型要能综合判断这是一个否定信号用户说可以吧同时表情迟疑模型要判断这不是真正的同意。这个对齐过程的训练数据极难获取。需要同时采集人脸视频、语音、标注好的情感/意图标签还要保证标注的准确性和一致性。我见过一些团队为了省事用大规模纯文本数据预训练大语言模型再单独训练一个表情识别头最后两头硬接结果就是表情识别的结果和对话上下文完全对不上AI 经常在用户讲笑话时一脸严肃。一段合理的做法是先分别训练语音语义网络和视觉语义网络再用一对多、多对一的对比学习策略做对齐训练用少量但高质量的双模态数据微调。这个过程对数据质量和模型规模都很考验但这恰恰是 Griffin 这类专有模型的护城河——大量且高质量的视频对话交互数据是后来者短期很难跨越的墙。3. VideoFDB 双榜第一怎么衡量“又懂又真”3.1 生成榜与感知榜分别测什么VideoFDB 这个基准在我理解里是专门面向视频人像生成与人像理解的评估体系。它有两条评测线生成榜Generation和感知榜Perception。生成榜考核的是模型生成的人像视频是否真实、自然、与输入语义一致。指标核心包括画面清晰度、时序连贯性、表情是否跟音频内容匹配、嘴唇动作是否与语音同步、动作是否自然平滑等。有时还考核生成视频与参考视频的身份一致性即生成的人脸特征是否稳定不变形。简单点说拿一段语音和表情令牌让模型生成一个人说话的视频看像不像真人、口型对不对、表情自不自然。感知榜考核的是模型对人像视频内容的理解能力。包括表情分类、情感判断、动作识别、细粒度微表情分析等。比如给一段视频让模型判断这个人在对话中是积极还是消极是困惑还是确定是在点头认同还是摇头否定。感知能力和生成能力是两条不同的技术路线一个重在解码成图像一个重在编码成语义。多模态模型通常很难两条路同时做到顶级。很多生成类模型在视频生成上一骑绝尘但把同一段人像视频丢给它做语义理解表现却不尽如人意因为生成和感知的优化目标、训练范式差异很大。Griffin 这次在 VideoFDB 生成与感知双榜都拿到第一至少说明它在这两个方向都有扎实积累不是只会做视频的嘴或者只会看视频的眼的跛脚模型。3.2 双榜第一的含金量与局限双榜第一的含金量在于生成模型往往能反向增强感知能力。一个能把人脸表情生成得高度自然的模型内部通常已经学到了丰富的表情动作语义表示这些表示同样是感知任务需要的特征。反过来说感知能力强的模型在生成时也能更好地校准表情细节的真实度。两个任务在共享表示空间里互相对齐这比只卷单条线更容易形成一体化能力。但这里要提醒一句基准测试榜单不能等同于实际产品体验。VideoFDB 有设定场景、评价方式、数据分布真实世界的视频交互环境远比评测集复杂——光照变化、摄像头角度偏差、遮挡、网络延迟、低画质都会让模型表现打折扣。我见过不少团队拿着榜单模型去部署结果在真实会议室、手机前摄场景里效果崩盘因为训练数据和真实场景差异太大。评测集还有一个隐藏问题生成视频的自然性很难用单一指标完全衡量。多条指标都是对整体质量某个维度的近似刻画比如嘴唇同步指标只评估口型的时间一致性不能评估 AI 生成的语音内容与用户输入是否逻辑匹配。模型可能在评测集上拿到高分但做出来的视频内容本身有奇怪的表情突变比如眼睛周期性地眨变得很快在真实场景里这种问题会被用户立即感知到。3.3 如何理性看待基准测试我个人的习惯是三条准则。第一看模型在生成与感知上的得分更要看它在两项任务上的得分差。如果生成分高、感知分低说明模型是只会画不会读反过来说如果感知强、生成弱则是只会看不会演。只有两项差距不超过 10% 的模型才可能是真正的多模态平衡模型。第二关注评测集的数据来源。如果数据集中在单一渠道、单一画质、单一语言上迁移到真实场景效果要大打折扣。第三一定要做自己的局部数据验证。哪怕只有几十段视频测试表情精度、延迟、打断反馈都比榜单分数更有工程参考价值。4. Inworld 收购 Ultravox语音智能体平台的价值重估4.1 两家公司都在做什么Tavus 这边发力视频交互的同时Inworld 收购 Ultravox 那条线也值得好好看。Inworld 主要做游戏与互动场景里的 AI 角色对话让虚拟角色具备个性、记忆和行为逻辑跑在游戏引擎里Ultravox 则是一个语音智能体平台提供基于大模型的实时语音对话能力包括语音识别、意图理解、语音合成、流媒体传输等模块化服务。这次收购本质上是一次垂直整合。Inworld 之前偏重对话逻辑和角色 AI 框架语音识别和合成更多依赖外部供应商。Ultravox 补上的正是实时语音管道这一块让 Inworld 可以直接用自有语音模型打通全链路。这一类收购动作往往是模型能力整合的早期信号当一个公司开始把底层模型和平台组件收编到一起说明它准备在产品层面发力了而不是只在实验室里刷榜。4.2 为什么是“语音”先被收购相比视频语音智能体平台的商业化成熟度明显更高。语音交互已经被各种服务接受电话客服、语音助手、智能座舱、语音门禁全都是大量存在的落地场景用 AI 替代或辅助人类服务的商业账已经算得通。而视频交互还需要解决摄像头隐私、算力成本、视觉模型成熟度等一系列问题商业化周期更长。从技术角度讲语音智能体平台的核心壁垒也比视觉更集中。低延迟的 ASR、自然流畅的 TTS、可靠的打断检测、稳定的流媒体传输这些能力可以做成一套标准的 API 服务被不同客户反复调用。对 Inworld 来说与其自己从零研发语音管线不如直接收购一家已经跑通并且有真实客户验证的平台。这也说明语音智能体已经是一个可以直接用钱买到的成熟技术栈而非需要多年攻坚的科研难题。4.3 对游戏和实时交互生态的影响收购次生影响主要在游戏和虚拟社交领域。游戏 NPC 过去说话方式非常刻板触发对话、播放预设台词、等待玩家点击选项。现在有了实时语音智能体和角色 AI 的组合NPC 可以真正听玩家说话用语音回复并根据玩家的态度调整后续行为模式。把这段和 Griffin 结合看一个更完整的实时交互链路已经隐约成型玩家打开摄像头游戏 NPC 不仅能听懂玩家说了什么语音语义还能通过视频通道感知玩家的表情与动作视觉语义再结合角色 AI 设计的行为逻辑做出及时且个性化的反应。这种模式离真正的虚拟存在已经不远了。对开发者来说这意味着不用再从零开发底层多模态模型而是可以通过平台 API 直接组装出一套实时交互数字人系统。这是整个行业从造模型走向做应用的分水岭。5. 落地实操接入这类模型时需要避开的坑这里聊聊实际接手的工程经验包括延迟预算、表情识别边界、数据合规这些偏实操的问题。5.1 延迟预算怎么算实时交互的效果很大程度取决于延迟。人类在对话中可接受的响应时间在 200~500 毫秒之间超过这个范围就会感觉对方反应慢。全双工视频交互里的延迟链路比纯语音更长采集 - 编码 - 网络传输 - 视觉特征提取 - 语义模型推理 - 回复生成 - 合成与渲染。我建议第一步先把链路拆开计时。用标准测试脚本测量每一环的耗时定位瓶颈。实测下来最常见的瓶颈有三个视觉特征提取尤其跑视频 Transformer 时、大模型生成速度、TTS 合成延迟。视觉特征提取可以用轻量级编码器和提前缓存人脸关键点来优化生成速度可以通过流式发 token 来规避TTS 则尽量选支持流式合成的方案首包延迟必须控制在 100 毫秒以内。除此之外网络传输的波动也要考虑。实时视频通话里弱网情况下丢包、抖动是常态。工程上要结合 WebRTC 的拥塞控制、自动码率调节等机制来稳定传输。不要天真地假设客户都坐在光线充足、网络稳定的会议室里。5.2 表情动作识别不是“读心术”持续读懂表情动作这句话在产品宣传里很有效但在工程上必须设边界。现阶段的视觉模型识别的是相关性不是因果。用户皱眉可能是在认真思考也可能是不满还可能是近视看不清屏幕单一的表情信号根本无法区分这些复杂的心理状态。因此在做产品设计时不要让模型单独作为决策依据。最好的方式是把视觉信号作为辅助信号与语音语义、对话历史、用户画像结合做多信号交叉判断。比如用户皱眉时如果语音内容同时出现不对、等一下这类词系统才有较高把握判断用户有异议如果语音内容正常而只在讲到某一处时皱眉系统只能把皱眉作为一个倾向性的弱信号。一个常见的工程错误是团队拿到大模型 API 后把所有摄像头数据一股脑丢进多模态模型期望它直接输出用户当前情绪是 XX。实际效果往往不如只做关键词检测 简单表情阈值判断来得稳定。注意不是说拿到一个好模型就可以放弃基础的规则引擎合理的架构是规则 模型互相兜底。5.3 数据合规与隐私设计摄像头数据是最敏感的数据之一。接入视频交互系统第一件事不是跑 demo而是把数据合规的设计定下来。采集用户视频前必须明确告知获得用户授权数据落盘严格加密并约定清晰的保留期限。系统默认的摄像头数据流尽量只在内存里处理不持久化存储原始视频如果确需存储用于模型迭代必须做去标识化处理。另外一个很容易忽略的问题是儿童隐私。如果产品面向未成年人处理规则更加严格。宁可先不做涉及儿童的视频交互场景也不要冒合规风险。做全球市场还要考虑不同地区的监管框架这里不逐一展开但产品的隐私设计必须一开始就放在架构层面而不是上线前补丁。顺便说一个工程建议不要在前端把原始视频流直接传到第三方大模型 API否则数据落地的边界完全失控。正确的方式是在服务端做加密封装设置访问白名单、通道加密、短时访问令牌等。有条件的话优先选择支持私有化部署的模型服务把原始视频留在自有环境里。5.4 常见问题速查表下面几张表是我搭建这类系统过程中整理出来的高频问题。问题现象常见原因排查方向用户说话时 AI 回复延迟明显语音识别环节未流式化需要等待用户完整句结束才处理查看 ASR 调度策略切到流式半句识别模式AI 播报时无法被用户打断打断检测未生效或合成音频占用了播放通道检查语音合成是否支持流式中断配置 barge-in 信号表情识别频繁误判训练数据与真实场景差异大或时间窗口过短增加场景适配数据拉长时序窗口降低强规则权重视频通道卡顿影响语音质量摄像头帧率设置过高挤占带宽降低帧率到 15~20fps分辨率降到 640 以下用户表情变化但系统无反应视觉特征提取滞后或感知模型跑在离线阶段检查特征提取链路是否实时确认模型输入是否连续数据存储超预算原始视频全部落盘改为内存处理 关键帧抽取 去标识化存储这些坑我基本都踩过一轮其中表情误判最容易引发体验事故。有一次测试中某个测试者天生有一点面部不对称模型反复识别成困惑表情导致 AI 频繁重复解释同一句话整个对话节奏几乎崩溃。后来解决办法是先跑一段静默校准采集用户自然状态下的表情基线再让模型在那个基线上做差分判断准确率大幅提升。这个思路在真实产品里成本不高但效果非常明显。6. 延伸思考下一代交互系统的拼图把两件事放在一个大图里看下一代交互系统至少需要四块拼图实时语音语义理解、实时视频表情动作感知、低延迟生成回复、稳定可靠的数据传输。Griffin 在视频这条线上做到了模型层面的完整Inworld 通过收购 Ultravox 补上了语音这条线的平台能力而剩下的数据传输部分目前靠 WebRTC 生态和实时通信基础设施完成。一个明显的趋势是模型能力正在模块化和平台化。视觉模型、语音模型、对话大模型、视频生成模型分别成为独立的能力模块通过标准 API 开放出来开发者不需要自己从零训练而是像搭积木一样组合出应用。这个模式的优点是降低了开发门槛缺点是系统集成的复杂度由应用层承担延迟、打断、多模冲突这些问题都需要开发者自己调试。对中小开发者和独立团队我的建议是先别急着自研视频模型。先把一个具体场景做深积累用户反馈数据等数据量到了一定程度再评估是微调开源模型还是采购商业 API。数据永远是这类系统的核心资产一个用心运营的数据集比一个从网上扒来的万能模型更能解决实际问题。至于要不要上车视频交互我自己判断这条赛道会在未来一两年内进入快速迭代期。随着视觉模型成本下降、摄像头硬件普及率提升、用户对有表情的数字人的接受度提高视频交互会从尝鲜走向主流。但对于大多数团队上车方式不是直接造模型而是选好平台、搭好链路、攒好数据等风真正刮起来的时候手里有足够硬的落地经验。这是目前这个阶段最理性的打法和最务实的储备。
多模态实时交互这个赛道最近有两件事值得放到一起看。一边是 Tavus 发布的全双工视频交互模型 Griffin带着所谓持续读懂表情动作的能力在 VideoFDB 的人像视频生成与感知榜单上拿了双料第一另一边是 Inworld 把语音智能体平台 Ultravox 收入囊中。两件事表面上一个在视频、一个在语音但底层其实是同一条主线实时多模态交互正在从能说会道走向能看懂、能回应、能接住突发事件。这两条进展对做对话系统、数字人、虚拟角色 AI 的团队来说都不是孤立的新闻而是直接改变选型和架构的信号。这篇文章我就围绕这两件事把背后的技术逻辑拆开讲清楚再补上一些实操层的东西尽量帮大家少踩坑。1. 全双工视频交互一场“对话范式”的升级1.1 全双工与半双工的本质区别先把这个词掰开。全双工Full-duplex是从通信领域借来的概念指双方可以同时发送和接收数据。放到人机对话里就是用户和 AI 不用轮流等对方说完可以边听边说、边说边被听就像两个人打电话时随时插嘴、随时回应那样自然。传统语音助手是典型的半双工模式用户按一下唤醒键开始说话说完停顿系统判断用户结束开始识别和处理最终播报回复。这个链条里每一环都是串行的交互节奏被静音检测 语音识别 大模型生成 语音合成四个环节的耗时绑死用户语速越快、内容越长等待感越明显。半双工还有一个致命问题当用户在听 AI 说话的过程中想打断时系统往往没有能力响应只能等当前播报完体验非常机械。截止到 2024 年很多大厂语音助手仍然采用半双工方案就是因为在全双工方案里打断处理、边说边识别、上下文的实时更新都是极高难度的工程问题。Tavus 这次发布 Griffin 打出全双工视频交互的旗号意味着它不只解决了语音层面的全双工还把视频画面中的表情、动作作为一个实时输入通道纳入到交互决策中。这里的难点不再是识别文字对不对而是在几百毫秒内完成多模态感知、意图判断和回应生成。1.2 视频通道加入后交互从“听见”变成“看见”语音助手解决的是听见这件事全双工视频交互解决的是看见。摄像头的数据流里藏着大量语音里捕捉不到的交互信号用户皱眉、微笑、点头、摇头、视线偏移、手臂交叉、身体后仰这些都比单纯的语言信息更早暴露用户的真实状态。举个实际例子。一个用户对 AI 说这个方案我挺满意的但与此同时他不断看手表、眉头微皱、身体往后靠。在纯语音系统里AI 只能根据文字内容判断用户满意做出正向反馈但在视频交互系统里多模态模型可以捕捉到这些强冲突信号——语言内容说满意非语言信息却在说我想离开。Griffin 的持续读懂表情动作强调的不是某一帧的判断而是在时间维度上跟踪表情动作的变化趋势把微表情的漂移纳入交互上下文。比如用户本来微笑但 AI 讲到某个具体参数时笑容消失、嘴角下垂系统就能定位到当前的沟通卡点。这种能力在真实交互里意义非凡。电话客服里我们只能通过语气和停顿猜测客户状态而视频客服里坐席能看到对方表情可以立刻调整话术。以前这项能力属于人类坐席的专属技能现在模型开始具备类似的感知链路这对远程销售、在线教育、心理陪伴等领域会带来比较直观的体验升级。1.3 这条技术路线最典型的应用场景全双工视频交互的应用场景我按落地难易度和收益排个序。第一梯队是数字人客服与远程座席辅助。银行面签、保险顾问、房产带看等场景原本就需要视频窗用户对面是经过培训的人类坐席有表情互动。现在把视频理解能力接入 AI 座席可以做一个全程陪伴的数字顾问实时观察用户表情在用户困惑时主动解释在用户犹豫时给出更多资料这种比问答机器人扎实得多。第二梯队是在线教育与虚拟面试训练。学生听课时走神、困惑、烦躁模型全都看在眼里系统可以动态调整讲解节奏。虚拟面试场景同理模型可以持续监测面试者的紧张度、表达过程中的微表情变化给出复盘报告。第三梯队是游戏与虚拟世界的角色 AI。这正好对应 Inworld 收购 Ultravox 那条线的意义——游戏 NPC 不再只是触发式对话而是能通过摄像头实时观察玩家的表情动作做出符合情境的反应比如看到玩家皱眉就换一条更简单的引导路径。这种体验沉浸感很强但工程链路也最复杂。2. Griffin 模型技术拆解“持续读懂”背后的四层能力很多宣传会把读懂表情包装得像魔法拆开看其实是有明确技术层级的。我把 Griffin 涉及的工程能力分成四层来理解视觉上下文输入、时序动作建模、流式推理与打断处理、多模态对齐。2.1 视觉上下文不止是“截一帧”持续读懂表情动作的这个持续很关键。如果只是每隔几秒截一张图做静态的表情分类那系统只是看脸不是交互。真正的视觉上下文需要的是连续的、实时的人脸信息。工程上一般分成两个阶段先做人脸检测与关键点定位再把关键点坐标、人脸区域图像、头部姿态等特征编排成结构化输入。关键点通常是 68 点或 106 点的人脸关键点覆盖眉毛、眼睛、鼻子、嘴巴、下巴轮廓头部姿态则用旋转矩阵或欧拉角表示用来判断点头、摇头、侧头等动作。这些特征相比直接把原始图像丢给模型维度小、语义更集中训练数据需求量也小一些。但这里有个工程取舍关键点特征丢掉了纹理信息用户肤色变化、微表情的肌肉牵动、眼眶湿润程度这些细节很难用关键点表达。所以更完备的方案是关键点辅助 视觉 Embedding 融合用视觉编码器从人脸上抽一个高维特征向量再把关键点、姿态这些低维特征拼接进去。利弊都清楚前者省算力后者效果好我见过不少团队为了省成本选了前者结果在表情复杂的场景里稳定性很差。2.2 时序建模动作是连续变化的不是分类标签人在交互中不会一直保持同一个表情情绪是随对话内容连续变化的。比如用户听 AI 介绍方案时经历好奇—困惑—放松—犹豫多个阶段表情在几十秒内会走完一条完整的变化曲线。要想抓住这个曲线模型必须有时间维度的建模能力。时序建模目前主流是视频 Transformer 或基于时序注意力机制的编码器。具体实现时把每秒 N 帧的人脸特征拼接成序列模型通过自注意力机制学习表情如何随时间变化。这种建模和单独判断每一帧的表情不同模型可以捕捉到刚才嘴角上扬现在微笑消失这种变化趋势而趋势往往比瞬时状态更能体现用户的真实态度。实操时一个很现实的坑是时间窗口的选取。窗口太长模型会被之前无关的表情干扰对当前状态的响应变慢窗口太短又容易误判瞬间动作。比如用户眨了一下眼如果窗口太短模型可能把它识别成闭眼表情导致系统产生用户是否疲劳的错误推断。合理的窗口一般选 1.5~3 秒还需要结合对话轮次切分在用户语音输入时降低视觉权重、在 AI 播报时提高视觉权重这样整体语义逻辑才不打架。2.3 流式推理与打断处理全双工交互对工程架构的挑战比模型本身更大。语音识别、大模型生成、语音合成流程都必须流式化几个环节并行流水线式工作让延迟控制在人耳舒适的范围内。视频通道也不轻松。摄像头实时帧要抽帧、降低分辨率、提取人脸特征、送入模型推理一级级往下传。每一级都会带来延迟帧率越高、模型越大延迟越高。业界的经验是视频通道不追求高帧率15~20 帧每秒足够捕捉大部分表情动作远高于这个数值只会浪费算力。分辨率同理人脸检测与表情识别不需要 4K 画面320~480 像素宽度的裁剪人脸区域就能满足多数需求。打断处理则是全双工里最难啃的地方。用户很可能在 AI 播放长回复到一半时插话等一下你刚说的那个方案能不能再解释一下系统此时要同时处理多个事件收到新的语音输入、暂停当前合成播报、保留上下文、重新组织回复。如果在播报时还叠加了视频通道扫描到的表情变化——比如用户插话时表情焦虑——系统还需要在暂停的同时感知用户情绪判断当前应该先道歉、先解释还是先安抚。这个决策链路在全双工里是实时多线程的任何一个环节阻塞都会让 AI 看起来反应迟钝。2.4 多模态对齐的工程代价多模态对齐听起来高大上实际落地时要做的其实就是让语音语义和视觉语义在一个统一的语义空间里互相校准。比如用户说好的同时摇头模型要能综合判断这是一个否定信号用户说可以吧同时表情迟疑模型要判断这不是真正的同意。这个对齐过程的训练数据极难获取。需要同时采集人脸视频、语音、标注好的情感/意图标签还要保证标注的准确性和一致性。我见过一些团队为了省事用大规模纯文本数据预训练大语言模型再单独训练一个表情识别头最后两头硬接结果就是表情识别的结果和对话上下文完全对不上AI 经常在用户讲笑话时一脸严肃。一段合理的做法是先分别训练语音语义网络和视觉语义网络再用一对多、多对一的对比学习策略做对齐训练用少量但高质量的双模态数据微调。这个过程对数据质量和模型规模都很考验但这恰恰是 Griffin 这类专有模型的护城河——大量且高质量的视频对话交互数据是后来者短期很难跨越的墙。3. VideoFDB 双榜第一怎么衡量“又懂又真”3.1 生成榜与感知榜分别测什么VideoFDB 这个基准在我理解里是专门面向视频人像生成与人像理解的评估体系。它有两条评测线生成榜Generation和感知榜Perception。生成榜考核的是模型生成的人像视频是否真实、自然、与输入语义一致。指标核心包括画面清晰度、时序连贯性、表情是否跟音频内容匹配、嘴唇动作是否与语音同步、动作是否自然平滑等。有时还考核生成视频与参考视频的身份一致性即生成的人脸特征是否稳定不变形。简单点说拿一段语音和表情令牌让模型生成一个人说话的视频看像不像真人、口型对不对、表情自不自然。感知榜考核的是模型对人像视频内容的理解能力。包括表情分类、情感判断、动作识别、细粒度微表情分析等。比如给一段视频让模型判断这个人在对话中是积极还是消极是困惑还是确定是在点头认同还是摇头否定。感知能力和生成能力是两条不同的技术路线一个重在解码成图像一个重在编码成语义。多模态模型通常很难两条路同时做到顶级。很多生成类模型在视频生成上一骑绝尘但把同一段人像视频丢给它做语义理解表现却不尽如人意因为生成和感知的优化目标、训练范式差异很大。Griffin 这次在 VideoFDB 生成与感知双榜都拿到第一至少说明它在这两个方向都有扎实积累不是只会做视频的嘴或者只会看视频的眼的跛脚模型。3.2 双榜第一的含金量与局限双榜第一的含金量在于生成模型往往能反向增强感知能力。一个能把人脸表情生成得高度自然的模型内部通常已经学到了丰富的表情动作语义表示这些表示同样是感知任务需要的特征。反过来说感知能力强的模型在生成时也能更好地校准表情细节的真实度。两个任务在共享表示空间里互相对齐这比只卷单条线更容易形成一体化能力。但这里要提醒一句基准测试榜单不能等同于实际产品体验。VideoFDB 有设定场景、评价方式、数据分布真实世界的视频交互环境远比评测集复杂——光照变化、摄像头角度偏差、遮挡、网络延迟、低画质都会让模型表现打折扣。我见过不少团队拿着榜单模型去部署结果在真实会议室、手机前摄场景里效果崩盘因为训练数据和真实场景差异太大。评测集还有一个隐藏问题生成视频的自然性很难用单一指标完全衡量。多条指标都是对整体质量某个维度的近似刻画比如嘴唇同步指标只评估口型的时间一致性不能评估 AI 生成的语音内容与用户输入是否逻辑匹配。模型可能在评测集上拿到高分但做出来的视频内容本身有奇怪的表情突变比如眼睛周期性地眨变得很快在真实场景里这种问题会被用户立即感知到。3.3 如何理性看待基准测试我个人的习惯是三条准则。第一看模型在生成与感知上的得分更要看它在两项任务上的得分差。如果生成分高、感知分低说明模型是只会画不会读反过来说如果感知强、生成弱则是只会看不会演。只有两项差距不超过 10% 的模型才可能是真正的多模态平衡模型。第二关注评测集的数据来源。如果数据集中在单一渠道、单一画质、单一语言上迁移到真实场景效果要大打折扣。第三一定要做自己的局部数据验证。哪怕只有几十段视频测试表情精度、延迟、打断反馈都比榜单分数更有工程参考价值。4. Inworld 收购 Ultravox语音智能体平台的价值重估4.1 两家公司都在做什么Tavus 这边发力视频交互的同时Inworld 收购 Ultravox 那条线也值得好好看。Inworld 主要做游戏与互动场景里的 AI 角色对话让虚拟角色具备个性、记忆和行为逻辑跑在游戏引擎里Ultravox 则是一个语音智能体平台提供基于大模型的实时语音对话能力包括语音识别、意图理解、语音合成、流媒体传输等模块化服务。这次收购本质上是一次垂直整合。Inworld 之前偏重对话逻辑和角色 AI 框架语音识别和合成更多依赖外部供应商。Ultravox 补上的正是实时语音管道这一块让 Inworld 可以直接用自有语音模型打通全链路。这一类收购动作往往是模型能力整合的早期信号当一个公司开始把底层模型和平台组件收编到一起说明它准备在产品层面发力了而不是只在实验室里刷榜。4.2 为什么是“语音”先被收购相比视频语音智能体平台的商业化成熟度明显更高。语音交互已经被各种服务接受电话客服、语音助手、智能座舱、语音门禁全都是大量存在的落地场景用 AI 替代或辅助人类服务的商业账已经算得通。而视频交互还需要解决摄像头隐私、算力成本、视觉模型成熟度等一系列问题商业化周期更长。从技术角度讲语音智能体平台的核心壁垒也比视觉更集中。低延迟的 ASR、自然流畅的 TTS、可靠的打断检测、稳定的流媒体传输这些能力可以做成一套标准的 API 服务被不同客户反复调用。对 Inworld 来说与其自己从零研发语音管线不如直接收购一家已经跑通并且有真实客户验证的平台。这也说明语音智能体已经是一个可以直接用钱买到的成熟技术栈而非需要多年攻坚的科研难题。4.3 对游戏和实时交互生态的影响收购次生影响主要在游戏和虚拟社交领域。游戏 NPC 过去说话方式非常刻板触发对话、播放预设台词、等待玩家点击选项。现在有了实时语音智能体和角色 AI 的组合NPC 可以真正听玩家说话用语音回复并根据玩家的态度调整后续行为模式。把这段和 Griffin 结合看一个更完整的实时交互链路已经隐约成型玩家打开摄像头游戏 NPC 不仅能听懂玩家说了什么语音语义还能通过视频通道感知玩家的表情与动作视觉语义再结合角色 AI 设计的行为逻辑做出及时且个性化的反应。这种模式离真正的虚拟存在已经不远了。对开发者来说这意味着不用再从零开发底层多模态模型而是可以通过平台 API 直接组装出一套实时交互数字人系统。这是整个行业从造模型走向做应用的分水岭。5. 落地实操接入这类模型时需要避开的坑这里聊聊实际接手的工程经验包括延迟预算、表情识别边界、数据合规这些偏实操的问题。5.1 延迟预算怎么算实时交互的效果很大程度取决于延迟。人类在对话中可接受的响应时间在 200~500 毫秒之间超过这个范围就会感觉对方反应慢。全双工视频交互里的延迟链路比纯语音更长采集 - 编码 - 网络传输 - 视觉特征提取 - 语义模型推理 - 回复生成 - 合成与渲染。我建议第一步先把链路拆开计时。用标准测试脚本测量每一环的耗时定位瓶颈。实测下来最常见的瓶颈有三个视觉特征提取尤其跑视频 Transformer 时、大模型生成速度、TTS 合成延迟。视觉特征提取可以用轻量级编码器和提前缓存人脸关键点来优化生成速度可以通过流式发 token 来规避TTS 则尽量选支持流式合成的方案首包延迟必须控制在 100 毫秒以内。除此之外网络传输的波动也要考虑。实时视频通话里弱网情况下丢包、抖动是常态。工程上要结合 WebRTC 的拥塞控制、自动码率调节等机制来稳定传输。不要天真地假设客户都坐在光线充足、网络稳定的会议室里。5.2 表情动作识别不是“读心术”持续读懂表情动作这句话在产品宣传里很有效但在工程上必须设边界。现阶段的视觉模型识别的是相关性不是因果。用户皱眉可能是在认真思考也可能是不满还可能是近视看不清屏幕单一的表情信号根本无法区分这些复杂的心理状态。因此在做产品设计时不要让模型单独作为决策依据。最好的方式是把视觉信号作为辅助信号与语音语义、对话历史、用户画像结合做多信号交叉判断。比如用户皱眉时如果语音内容同时出现不对、等一下这类词系统才有较高把握判断用户有异议如果语音内容正常而只在讲到某一处时皱眉系统只能把皱眉作为一个倾向性的弱信号。一个常见的工程错误是团队拿到大模型 API 后把所有摄像头数据一股脑丢进多模态模型期望它直接输出用户当前情绪是 XX。实际效果往往不如只做关键词检测 简单表情阈值判断来得稳定。注意不是说拿到一个好模型就可以放弃基础的规则引擎合理的架构是规则 模型互相兜底。5.3 数据合规与隐私设计摄像头数据是最敏感的数据之一。接入视频交互系统第一件事不是跑 demo而是把数据合规的设计定下来。采集用户视频前必须明确告知获得用户授权数据落盘严格加密并约定清晰的保留期限。系统默认的摄像头数据流尽量只在内存里处理不持久化存储原始视频如果确需存储用于模型迭代必须做去标识化处理。另外一个很容易忽略的问题是儿童隐私。如果产品面向未成年人处理规则更加严格。宁可先不做涉及儿童的视频交互场景也不要冒合规风险。做全球市场还要考虑不同地区的监管框架这里不逐一展开但产品的隐私设计必须一开始就放在架构层面而不是上线前补丁。顺便说一个工程建议不要在前端把原始视频流直接传到第三方大模型 API否则数据落地的边界完全失控。正确的方式是在服务端做加密封装设置访问白名单、通道加密、短时访问令牌等。有条件的话优先选择支持私有化部署的模型服务把原始视频留在自有环境里。5.4 常见问题速查表下面几张表是我搭建这类系统过程中整理出来的高频问题。问题现象常见原因排查方向用户说话时 AI 回复延迟明显语音识别环节未流式化需要等待用户完整句结束才处理查看 ASR 调度策略切到流式半句识别模式AI 播报时无法被用户打断打断检测未生效或合成音频占用了播放通道检查语音合成是否支持流式中断配置 barge-in 信号表情识别频繁误判训练数据与真实场景差异大或时间窗口过短增加场景适配数据拉长时序窗口降低强规则权重视频通道卡顿影响语音质量摄像头帧率设置过高挤占带宽降低帧率到 15~20fps分辨率降到 640 以下用户表情变化但系统无反应视觉特征提取滞后或感知模型跑在离线阶段检查特征提取链路是否实时确认模型输入是否连续数据存储超预算原始视频全部落盘改为内存处理 关键帧抽取 去标识化存储这些坑我基本都踩过一轮其中表情误判最容易引发体验事故。有一次测试中某个测试者天生有一点面部不对称模型反复识别成困惑表情导致 AI 频繁重复解释同一句话整个对话节奏几乎崩溃。后来解决办法是先跑一段静默校准采集用户自然状态下的表情基线再让模型在那个基线上做差分判断准确率大幅提升。这个思路在真实产品里成本不高但效果非常明显。6. 延伸思考下一代交互系统的拼图把两件事放在一个大图里看下一代交互系统至少需要四块拼图实时语音语义理解、实时视频表情动作感知、低延迟生成回复、稳定可靠的数据传输。Griffin 在视频这条线上做到了模型层面的完整Inworld 通过收购 Ultravox 补上了语音这条线的平台能力而剩下的数据传输部分目前靠 WebRTC 生态和实时通信基础设施完成。一个明显的趋势是模型能力正在模块化和平台化。视觉模型、语音模型、对话大模型、视频生成模型分别成为独立的能力模块通过标准 API 开放出来开发者不需要自己从零训练而是像搭积木一样组合出应用。这个模式的优点是降低了开发门槛缺点是系统集成的复杂度由应用层承担延迟、打断、多模冲突这些问题都需要开发者自己调试。对中小开发者和独立团队我的建议是先别急着自研视频模型。先把一个具体场景做深积累用户反馈数据等数据量到了一定程度再评估是微调开源模型还是采购商业 API。数据永远是这类系统的核心资产一个用心运营的数据集比一个从网上扒来的万能模型更能解决实际问题。至于要不要上车视频交互我自己判断这条赛道会在未来一两年内进入快速迭代期。随着视觉模型成本下降、摄像头硬件普及率提升、用户对有表情的数字人的接受度提高视频交互会从尝鲜走向主流。但对于大多数团队上车方式不是直接造模型而是选好平台、搭好链路、攒好数据等风真正刮起来的时候手里有足够硬的落地经验。这是目前这个阶段最理性的打法和最务实的储备。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
