做 AI 基础架构研究这几年我一直对视频会议这个赛道格外关注因为它几乎集齐了 AI 工程化最难处理的一类问题音频、视频、文字三种模态同时存在实时性要求到秒级隐私合规约束又特别严格。Zoom AI Companion 推出之后我花了两三周时间把它的技术架构从公开文档、专利申请材料、工程分享到行业分析做了一轮完整梳理核心聚焦在联合式方法Federated Approach和多模态集成这两条主线上。这篇文章就是那次研究的完整记录包括我的判断依据、拆解思路以及验证过程中踩过的坑。先说结论Zoom 的 AI 架构能带给人的启发不是某个模型的参数有多惊艳而是一套在真实产品约束下AI 能力如何被组织起来的工程方法论。它用多个专用模型协同而不是依赖一个全能大模型它把数据合理地分置在端侧和云侧而不是一股脑都搬到服务器上它用多模态融合的方式去理解会议内容而不是只靠一份语音转写文本硬撑。对于正在规划音视频产品 AI 功能的人这套思路几乎可以直接复制。1. 整体架构思路拆解AI 能力为什么不能只靠一个大模型1.1 三个绕不开的现实约束研究一个系统的技术架构最忌讳脱离它的业务场景空谈模型选型。Zoom AI Companion 要服务的场景是视频会议这个场景天然带着三重约束。第一层是实时性。会议进行中就要提供实时转写、实时问答、实时字幕翻译这意味着 AI 链路里的每一环从音频采集到结果返回延迟预算通常是几百毫秒到几秒。你不能等整场会议结束再跑一个大模型去理解内容那样摘要功能倒是能做但实时助手就废了。第二层是多模态数据的密度。一段 60 分钟的视频会议音频流约 300MB 左右视频流按 720p 算要接近 1GB再加上共享屏幕、聊天消息、参会人列表数据种类极其庞杂。而且这些数据在时间上是严格对齐的第 15 分钟第 20 秒说的那句话对应着当时屏幕上展示的某个 PPT 页面还对应着发言人的表情和动作。理解这类内容必须做多模态融合不能只看单一模态。第三层是隐私与合规。会议内容往往涉及商业机密、个人隐私很多企业客户要求数据处理必须限定在特定区域甚至要求在私有化环境里闭环。这意味着 AI 能力不能简单粗暴地全部丢给云端大模型。这三重约束叠加在一起直接排除了一个超级大模型吃下所有输入的技术路线——那成本高到无法接受延迟也满足不了实时要求。合理的选择只能是拆分任务、分层部署。1.2 联合式方法的本质从一个模型扛所有到一组模型协作联合式方法在 Zoom 的技术语境里核心含义是模型编排与协同而不是联邦学习。联邦学习讲的是数据不出本地、只交换模型参数而联合式方法在这里更多指推理阶段的架构策略——把复杂任务拆解成多个子任务每个子任务分配给最适合的专用模型再由上层的调度和编排逻辑把结果组装成最终输出。这个选择背后有很实际的理由。单体大模型在处理多步骤任务时存在两个致命问题一是单点故障影响面大模型只要在某个环节输出错误整个结果就崩了二是调试困难你很难定位到底哪一步出了问题。而联合式架构把链路拆开之后每个环节可以独立优化、独立替换、独立评测。Zoom 的联合式方法落在地上可以拆成三个层面来理解任务级联合转写、说话人分离、会议摘要、行动项提取、实时问答分别由不同的模型负责每个模型只解决一个窄而明确的问题。部署级联合端侧设备或边缘节点跑轻量模型处理简单任务比如语音活动检测、基础转写云侧跑大模型处理复杂生成任务比如长文本摘要、跨模态推理。决策级联合多个模型对同一事件给出输出后通过交叉校验或打分机制得到最终结果降低单一模型的错误率。这三层联合的好处非常明显。任务拆细之后每个模型都可以用较小的参数规模获得较高的准确率训练和部署成本都更可控。部署级联合则让隐私敏感的数据尽量留在端侧只有必要的脱敏信息才上云。决策级联合更是对抗模型幻觉的有效手段——后面讲多模态集成时我会展开说。2. 联合式方法的核心机制任务路由、端云协同与成本平衡2.1 任务路由谁来决定每个请求该交给哪个模型联合式架构的第一个工程难点是任务路由。一个用户说帮我总结一下刚才的讨论系统怎么知道该把这句话发给摘要模型还是问答模型一个实时转写请求进来应该走端侧轻量模型还是云端大模型从 Zoom 公开的架构描述和行业惯例来看路由层通常由意图识别加规则引擎共同完成。意图识别模型负责理解用户请求的类型——是生成摘要、提取行动项、还是回答关于会议的具体问题规则引擎负责判断任务的复杂度、数据敏感性、实时性要求从而决定走端侧还是云侧。我在自己的项目中复现过类似的调度逻辑经验是路由规则不要一开始就设计得过于复杂。先用三个维度打分——任务类型分数、数据敏感分数、实时性分数然后按阈值分派。比如敏感分数高于某个值强制走端侧实时性分数高但敏感分数低走云侧 fast model两者都低走云侧大模型。跑一段时间积累真实流量之后再根据实际延迟和成本数据调整阈值。2.2 端云协同哪些模型放端侧哪些放云侧端云协同是联合式方法里最考验架构师判断力的部分。放太多到端侧设备的内存、算力、功耗可能吃不消放太少到端侧隐私和成本压力又会回到云侧。Zoom 的做法从已有信息推断是三类任务优先放端侧一是语音活动检测这类高频低复杂度的任务二是关键词语音识别这类需要即时响应的任务三是需要保护隐私的敏感内容分析。云侧负责的则是长文本理解、复杂推理、知识库问答这类需要大参数模型的任务。这里有一个值得单独强调的判断标准某个任务是否可以拆成端侧初筛 云侧精排两段式。比如转写任务端侧先做语音活动检测和说话人分段把谁在什么时候说了什么的粗粒度信息提取出来云侧的强转写模型只需要处理有效语音区间既省流量又省计算资源。这种两段式设计比单纯选端侧或云侧要聪明得多。2.3 成本与延迟的平衡算一笔实务账联合式架构的成本优化空间在会议场景里特别明显。我做过一次估算一段 60 分钟的双人会议原始音频如果全部交给云端语音识别模型处理按当前主流商用 API 的价格计算成本大约是每小时 1.5 到 2 元人民币但如果端侧先做 VAD 过滤把静音片段和不含语音的垃圾段去掉实际需要送云端的音频通常能缩减 30% 到 50%成本直接打六折。转写文本进入大模型做摘要时Token 消耗是另一笔大账。60 分钟会议的转写文本大约 8000 到 12000 个字符换算成 Token 在 6000 到 10000 之间做一次性摘要的调用成本并不高。但如果是多轮交互式问答每一轮都要把会议全文塞进上下文成本就变成调用次数乘以全文 Token 数十分钟之内就能烧掉几块钱。Zoom 在成本控制上用得比较多的一招是分片摘要 分层合并。先把长会议切成 10 到 15 分钟的小段每段独立生成局部摘要再用一个轻量模型把这些局部摘要合并成全局摘要。这样做的好处不只是省 Token更重要的是规避了大模型上下文窗口的限制——两小时的会议全量塞进一个窗口注意力分布早就稀烂了。3. 多模态集成的关键链路时间对齐、上下文拼接与交叉验证3.1 音频、视频、文本三类信号的时间同步问题多模态集成最难的部分不是模型选型而是数据对齐。会议场景里音频流、视频流、屏幕共享流、聊天消息各自独立产生但必须放在同一条时间轴上理解。我踩过的坑是语音转写文本和视频帧的时间戳如果不对齐后面所有多模态推理都是空中楼阁。转写引擎输出的时间戳和视频帧的时间戳分属两套体系转写基于音频帧索引视频基于显示时间戳两者之间有一个固定的偏移量需要校准。校准的方法也很朴素——找一个明确的同步点比如某一帧画面里出现了某个发言人同时音频里也能检测到这个人开始讲话的声音把这个时刻作为两个时间轴的公共锚点。工程上更稳妥的做法是在采集端统一打点。会议客户端在采集音频和视频时就用同一个时钟源生成时间戳转写和视觉分析都基于这个公共时钟。这一点看似基础但在实际项目中很多团队为了省事让各模态独立打点结果到了融合阶段追悔莫及。3.2 融合策略的选择早融合、晚融合还是混合融合多模态融合通常有三种策略早融合、晚融合、混合融合。早融合是指把不同模态的特征向量直接拼接喂给同一个模型晚融合是指各模态先独立推理再把输出结果合并混合融合则是在不同层级做交叉。会议场景下我倾向于采用晚融合为主、关键环节做交叉注意力的混合方案。原因是会议各模态的任务独立性比较强——音频主要出转写和情感视频主要出动作和表情文字主要出语义。这些信息先各自处理损失小、可替换性强每个模态的子系统都可以独立升级。但到了发言人身份识别这类任务就需要交叉注入了单靠声纹识别会出错单靠人脸识别也会出错把声音特征和视觉特征做一次注意力融合准确率能大幅提升。Zoom 在专利材料里也透露过类似思路——采用基于注意力机制的多模态融合层让模型在生成输出时能够动态决定当前应该侧重哪个模态的信息。这比静态拼接特征的做法灵活得多也更贴近人类理解会议的方式。3.3 长会议上下文管理把两小时塞进一个模型一个现实的问题大模型有上下文窗口限制两小时会议产生的转写文本加上视觉描述可能超过 8 万个 Token直接塞进去不现实。Zoom 的应对方案除了前面提到的分片摘要还有一个关键技巧上下文压缩与结构化提取。我的实现路径是先用规则和轻量模型把会议中的实体人名、项目名、时间节点、决策项、问题点提取出来形成结构化的事件流然后让摘要模型只基于这些结构化事件生成内容而不是面对全文。这比直接让模型读全文再总结准确率更高幻觉率更低——因为模型拿到了明确的事实清单不需要从冗长的对话里自己找重点。这个思路其实和人做会议纪要的逻辑一致先记事实再写总结。模型也是一样给它结构化的事实它输出可靠总结的概率会高很多。4. 实操落地用现有工具搭建一个会议 AI 分析最小链路4.1 数据采集与预处理前面讲的都是架构和研究思路这一节给出一套可以直接上手跑通的最小实现方案。目标很小录制一段会议视频输出一份结构化摘要包含发言人、主题和行动项。第一步是数据采集。你可以用任一会议软件的本地录制功能拿到音视频文件。然后把音频轨抽离出来用 ffmpeg 一行命令搞定ffmpeg -i meeting.mp4 -vn -acodec pcm_s16le -ar 16000 -ac 1 meeting.wav。这里做两个关键转换采样率降到 16kHz声道合并成单声道这是大部分语音模型的期望输入格式直接输入原始采样率反而可能出问题。视频部分按每秒一帧的采样率抽帧用于后续的发言人视觉特征提取ffmpeg -i meeting.mp4 -vf fps1 frame_%04d.jpg。抽帧频率不用太高人脸识别和表情分析每秒一帧足够太高反而浪费存储和算力。4.2 转写、说话人分离与摘要生成拿到音频后转写用开源 Whisper 系列模型就能跑出不错的效果。我的建议是使用带 timestamp 参数的调用方式确保输出每个分句的起止时间whisper --model large-v3 --language zh --output_format json meeting.wav。说话人分离是另一个关键环节。最简单的做法是用 pyannote.audio 的预训练模型做声纹聚类把音频按说话人切成多个片段再把切片时间对应到 Whisper 的转写结果上。注意这里有个容易出错的地方两套模型生成的时间戳体系不同需要先做一次时间轴校准。摘要生成直接用大模型的 API 即可但提示词值得认真打磨。我的模板固定包含三部分角色设定你是会议记录整理专家、输入结构说话人标签加对应发言、输出要求分类输出主题、决策、行动项行动项必须标注责任人格式。实测下来结构化输出的提示词比开放式的帮我总结一下效果好出一大截——输出的内容几乎不需要二次处理就能直接用。4.3 异步任务队列与结果回写真实产品里会议录制文件通常很大处理链路又长必须走异步任务系统。我用的方案很简单Python Celery Redis任务队列切分成四个阶段——音频预处理、转写、说话人分离、摘要生成每个阶段一个任务前一个完成自动触发后一个。结果回写注意一点不要把原始文件、中间产物、最终结果混在一个存储里。原始音视频放在对象存储转写 JSON 放数据库最终摘要生成 Markdown 文件再存对象存储数据库里只保留引用链接。这样数据流转清晰也方便后续做数据清理——会议数据有很强的时效性过期删除是硬需求。5. 常见问题与排查技巧实录5.1 转写时间戳错位导致的多模态对齐失败这是我实操中遇到频率最高的问题。症状是摘要文本里提到的某个话题和视频画面对不上或者说话人标记混乱。排查路径是从数据源头查起。先用一段 10 秒的测试音频同时在固定时间点拍屏验证转写时间戳和视频时间戳是否对齐。如果发现固定偏移直接在代码里做补偿如果偏移量不稳定问题大概率出在音频采集端的缓冲策略要重新设计采集逻辑。实操提示无论你用哪个转写引擎上线前务必做一次时间戳精度验证。别信默认对齐这种话测量过的才是真的。5.2 大模型摘要幻觉严重影响可信度用大模型做会议摘要最头疼的问题就是幻觉——模型正经其事地编造出一个张总提出增加预算但实际上张总全程没说话。我的应对策略有三层。第一层是在提示词里强制要求只能基于输入文本不得补充外部知识第二层是在生成结果里标注每一条内容的输入来源时间区间便于回溯第三层是做一个简易的事实校验器——把摘要里出现的实体人名、项目名、数字和原始转写文本做匹配校验匹配不上的直接打标签警告。这三层下来幻觉导致的信息污染基本能被拦截住。5.3 长会议上下文溢出与成本失控两小时以上的会议Token 消耗会指数级增长。第一次跑测试的时候我试过把全部转写文本直接塞给大模型结果调用直接报上下文超限改模型参数也没用。后来采用的方案是分片加分层合并。先把会议按 10 分钟切片每片单独生成局部摘要和行动项再用一个专门的合并模型把所有局部摘要汇总成全局结果。这个方法有两个额外的好处局部摘要本身就带时间戳合并时可以自然形成时间线而且即使某个切片处理失败只需要重跑那一段不用整个会议重来。5.4 说话人分离效果差的场景化调优双人对话的场景说话人分离准确率很高但到了多人会议、远场拾音、多人同时说话的场景错误率直线上升。实测下来的经验是不要只依赖声纹特征要结合视频画面做交叉验证。当声纹聚类置信度低的时候用抽帧图片做的人脸识别结果来修正说话人标签。虽然这套方案会增加计算量但在多人会议场景下准确率提升是非常明显的。6. 一点额外的体会研究 Zoom AI 架构的这段经历让我对 AI 工程有了几个新的认识。一AI 能力的核心瓶颈往往不在模型本身而在于数据的组织方式——多模态对齐、上下文管理这些脏活累活决定了模型在真实场景里能不能用。二联合式方法的最大价值不是单个模型的精度而是系统级的稳定性——一个环节坏了还能降级运行这在线上产品里是生死攸关的属性。三做 AI 架构方案设计时成本模型一定要前置别等功能做完了再算账那会儿改动代价就大了。如果你也想在自己的产品里落地类似的 AI 能力我建议从会议摘要这一个点切入跑通端到端链路后再横向扩展。先把录音转写、说话人分离、摘要输出这三板斧练熟再逐步加入视频分析和实时交互。这条路我走过坑虽然不少但每个坑都有对应的解法走通之后的成就感非常值。