1. 项目定位与整体方案选型1.1 需求清了三次才真正对齐先说这个项目的来头。某公司想做一个线上虚拟展厅用于展示自己的核心产品和历年技术成果。需求文档初版写得比较空核心词就那么几个“AI驱动虚拟展示”“沉浸式体验”“智能导览”。这些词看着没什么门槛但落到系统设计上分歧非常大。筹备阶段我们内部先后出了三版需求拆解第一版偏向静态3D展厅用户进去只能漫游和点展品第二版加了预设讲解第三版才把AI真正放进去——自然语言问答、按兴趣推荐展品、数字人随行讲解。客户最终采纳的是第三版的思路理由也很实在静态3D展馆市场上已经很多他们不缺一个“能看的壳”缺的是一个“能聊、能问、能带你看”的虚拟导览员。这里有一个关键判断AI驱动虚拟展示核心不是“虚拟展示”而是“驱动”。虚拟展示本身是成熟技术WebGL、3D引擎、全景图、模型压缩这些都能实现。但一旦加上AI驱动系统架构就要从“资产管理渲染”变成“多模态交互实时计算渲染”三层协同。展示是载体AI是体验差异化的关键。对应到不同角色这个项目有明确的受益方。对客户而言AI导览替代了部分线下讲解人力而且能支持7x24小时在线不用再受限于展厅开放时间。对内容运营团队来说展品知识库可以持续更新问答效果随着内容迭代越来越准。对技术团队来说这套架构沉淀下来的能力可以复用到后续的线上发布会、虚拟展厅、品牌馆等不同项目。1.2 技术栈选型四个关键判断技术选型决定了项目后续的走向。我们当时的选型原则很简单上线速度要快、迭代要灵活、部署不依赖特定平台、后续能剥离出可复用能力。四个关键判断具体是展示端选用Web技术栈而非原生App或VR一体机。虚拟展厅需要最大限度降低用户访问门槛。用户点开链接就能进入不需要安装应用不需要购买VR设备。WebGL作为渲染底座浏览器兼容性和性能已经足够支撑中低复杂度的3D场景。如果选原生引擎做VR一体机版本开发周期至少多一个月而且受众面会急剧收窄。3D场景基于通用引擎封装不自己造轮子。场景搭建、材质编辑、灯光处理这些能力直接用现成引擎的方案开发团队只做上层定制和AI能力对接。好处是资产管线通畅设计师用常用工具导出模型后可以直接进场景不用经过复杂的格式转换。AI能力全部走服务化接口渲染端与AI端解耦。大模型对话、语音识别、语音合成、视觉识别这些都是独立服务。渲染端只负责采集用户输入、展示结果不直接承载大模型推理。这样AI服务的并发压力和渲染层的性能压力可以独立扩缩容不会因为一轮问答高峰把整个3D场景拖垮。数据层单独建知识库不做端到端黑盒。很多AI展示项目喜欢把知识直接塞进提示词里让大模型自由发挥。但我们坚持把展品信息结构化后放入独立知识库每次问答时先做检索再把检索结果和相关展品上下文一起交给大模型生成回答。为什么要这么做后面讲问答幻觉的时候细说。1.3 架构分层与核心模块划分整个系统从下到上分成四层因为篇幅足够我用表格呈现便于对照层级职责核心组件资产层3D模型、贴图、展品信息、多媒体素材的存储与管理对象存储、资产管理系统、模型处理管线AI能力层自然语言理解、语音交互、视觉识别、推荐引擎大模型服务、语音识别/合成、向量检索、视觉模型应用层用户交互逻辑、场景渲染、状态管理Web渲染引擎、前端框架、状态同步服务展馆层展厅编排、导览路线的配置、运营后台后台管理平台、数据看板AI能力层是项目里最花心思的部分。拆开看它包含五类子服务智能导览对话、语音交互识别合成、视觉识别拍照找展品、兴趣推荐、数字人驱动。每一个子服务都可以独立演进但由应用层的“交互编排器”统一下发指令。用户在前端说的每一句话、点的每一个展品都会统一进入一条交互链路经过意图判断之后再分发到对应的AI服务。2. 核心链路拆解AI能力如何落到展示场景2.1 智能导览对话检索增强比纯大模型更稳智能导览是这个项目的门面功能。用户进入虚拟展厅可以语音或文字提问“你们这款产品主要解决什么问题”“这台设备的功耗大概是多少”数字人会在场景中给出回答并在必要时联动展示相关展品。第一个版本我们直接用大模型裸答把展品资料一股脑写进系统提示词结果发现两个问题一是回答质量不稳定同一个问题换一种问法答案经常跑偏二是展品多了之后上下文塞不下回答越来越含糊。后来改成检索增强生成RAG架构先检索后生成。每次提问先通过向量检索召回若干条相关文本再把这些文本作为上下文交回大模型组织答案。效果立刻就不一样了起码事实准确率提升了一个量级。落地的步骤可以拆成三条线知识处理线。每个展品的详情、参数、故事背景、常见问答全部整理成条目按段落切分后做向量化。向量化模型用的是通用中文向量模型维度不高检索速度和准确率对当前知识量来说是够用的。问答服务线。用户输入先做意图分类判定是“直接问展品信息”“对比两个产品”还是“闲聊”。对比类问题单独处理先把两个展品的关键信息抽出来再用大模型做对比。闲聊类问题直接拦截不会浪费检索资源。上下文管理线。每轮问答都带上用户当前所在展品的位置信息、浏览历史、上一轮问题。这样用户问“那它呢”这样指代不清的问题时系统可以通过上下文推测指的是哪个展品。这里必须说明一个很容易忽略的点AI导览的体验瓶颈往往不在模型本身而在知识库的数据质量。知识库里的信息如果本身矛盾、口径不统一再强的模型也答不出准确内容。所以项目里专门加了“知识库运营”环节无论是技术人员还是内容运营都可以通过后台对每条知识做版本管理改动后系统自动重新向量化效果有显著变化就保留没有变化就回滚。2.2 视觉识别与兴趣推荐把“看展”变成“逛展”视觉识别这块我们做了两个场景拍图识展品和兴趣推荐。拍图识展品是用户拿着手机拍下一件实物或一张海报系统通过视觉模型识别出对应展品然后直接定位到虚拟展厅的对应位置。这在线上平台对接线下物料时特别有用比如客户在宣传册上看到一台设备拍一下就能直接跳转到虚拟展厅查看详情。兴趣推荐就更有意思了。它不依赖用户主动输入而是根据用户在虚拟展厅的浏览轨迹来实时调整推荐内容。我们把每个展品打上标签记录用户在每个展品前的停留时间、交互次数、提问内容然后用向量相似度计算用户偏好与展品之间的匹配度。用户在A展区多停留了30秒并问了一个关于技术参数的问题系统会在右下角推荐同技术路线但更高阶的B展品。这个模块让我对“AI驱动虚拟展示”的理解更具体了AI驱动的价值不只是把解说词念出来更是让每一个用户的浏览路径都不一样。传统展厅是一对多的广播虚拟展厅可以做到一对一的动态编排。推荐模块的改造空间非常大第一版算法可以不用复杂。冷启动阶段用户首次进馆就推荐热门展品有行为数据后再切换到协同过滤加标签匹配。等积累到一定量级可以去尝试序列推荐但第一版不建议投入太多。2.3 数字人随行讲解语音合成与驱动细节数字人几乎是AI驱动虚拟展示的标配。需求方普遍会觉得没有数字人的AI展厅不够“AI”。但数字人这块的坑比想象中大尤其是“开口说话”这一瞬间的口型同步。数字人的核心链路是文本对话系统输出→ 语音合成 → 音频驱动口型 → 骨骼动作混合 → 渲染显示。四个环节都有可踩的坑。语音合成阶段我强烈建议不要用纯拼接式合成。统一使用神经网络语音合成方案自然度才够看否则数字人一开口就是机器感用户立刻出戏。口型驱动阶段可以按音素级别对齐也可以直接基于音频特征预测 blendshape 权重。前者更准但需要音频包含音素时间戳后者实现更简单适合快速上线。我们实际采用的做法是语音合成服务返回带时间戳的音频前端拿到时间戳后把每个音素映射到口型权重再通过骨骼动画混合器叠加到数字人模型上。这个方案对音频质量有一点要求但稳定性高适配多种语速。口型同步的延迟在180毫秒以内人眼基本看不出来。数字人的动作管理也不可忽视。一直说话没有动作切换视觉上很“僵”。我们在后台定义了几套动作模板比如“介绍”“展开双臂”“低头示意”。在生成回答时根据语义段落切分插入动作节点。例如“首先”对应“抬起右手”“最后一件事”对应“往前一步”。这些不需要模型参与规则匹配就能做到但体感上真实很多。3. 实操落地从原型到可上线的具体步骤3.1 3D模型资产处理与轻量化虚拟展厅如果没有好的3D资产AI能力再强也白搭。模型源文件是从设计团队拿的一般是高精度版本单个模型动辄几百MB直接扔进Web渲染引擎里跑用户浏览器不是卡死就是风扇狂转。所以第一步就是轻量化处理。轻量化管线三条路同时走模型压缩、纹理压缩、资源流式加载。模型压缩用的是Draco算法针对几何数据进行编码可以把顶点数据体积压缩掉70%以上。纹理压缩更关键很多材质的高清贴图一张就是几十MB而且用户不一定都会走到跟前仔细看。我们把大纹理统一降到1K分辨率重要展品才保留2K。不明显的细节损失换来的是加载性能的大幅提升。资源流式加载则是配合场景编排用户进入大厅先只加载大厅本身走近某个展台时再动态加载该展台的模型和贴图。一个容易被忽略的地方所有压缩操作必须在资产入库时自动完成而不是人工处理。模型入库就走管线导出GLB格式、跑Draco压缩、生成多级LOD、上传对象存储。运营人员甚至都不需要知道什么是LOD只要把源文件丢进系统后台全自动处理。这个自动化管线我建议所有做Web 3D展示项目的团队都建一个省下的时间远超开发成本。3.2 AI能力层的接入与协同AI能力层接入有几个关键节点我按实际推进顺序来说。第一步是打通对话服务。前端通过WebSocket建立长连接消息格式统一用JSON字段包括sessionId、exhibitId、text。后端收到文本后先做意图分类再走检索最后调大模型。整个过程对前端是异步的前端会先看到“正在输入”的状态等后端推送完整回答后再渲染。这里我用一个简洁的流程说明用户提问前端带当前展品ID和会话ID发送到网关网关校验会话状态转发给对话服务对话服务做意图分类决定是否走知识检索检索结果拼装上下文调用大模型生成回答回答返回并切成对话流前端流式展示如果命中数字人展示同一步把回答文本送入语音合成服务第二步是打通语音链路。用户在页面说话浏览器录音前端做实时语音识别识别文本交给对话服务。这里要处理的一个细节是“语音识别打断”。如果用户话没说完识别服务按静音切分可能会把句子截断。所以前端录音要加VAD检测一句话结束再发送不要一边说一边发。实测下来VAD静音阈值设为800毫秒左右比较合理太快容易误切太慢又觉得迟钝。第三步是打通推荐服务。推荐服务不直接参与对话流程它消费用户行为事件。用户在场景中的每一次点击、驻足、提问都以事件形式上报。事件流进入推荐服务后实时更新用户偏好向量。每隔一段时间推荐服务计算当前展馆内与偏好向量最匹配的几个展品推送到前端展示。延迟方面从行为发生到推荐卡片出现控制在1~2秒内即可没必要做到毫秒级。3.3 性能预算与上线前压测性能问题在虚拟展示项目里属于一等公民。用户首屏加载超过5秒流失率是断崖式的。我们当时给自己定的硬性指标首屏可达时间不超过4秒场景交互帧率不低于30FPS内存占用控制在1GB以内。先算首屏预算假设用户主力带宽是20Mbps理论下载速度大约2.5MB/s。4秒内能下载约10MB数据。所以首屏资源包H5框架代码、大厅低精度模型、初始贴图、AI服务的JS SDK不能超过10MB。我们压完初始包后实测在6.8MB左右留了一些余量给网络波动。这个预算在立项时就应该算清楚否则后面优化会非常被动。压测分两层接口层和场景层。接口层压的是对话服务和推荐服务。压测脚本模拟并发问答每秒100个请求起步逐步加到500。对话服务在纯检索模型调用的路径上P95延迟稳定在2.5秒左右。场景层压测更复杂一些需要用真实浏览器模拟用户逛展厅统计页面帧率和长任务耗时。实测下来低端安卓机上全屏加载高精度展品时会发生明显的掉帧最后靠多级LOD和纹理压缩把帧率拉回了33FPS上下算是及格。我特别提醒一下上线前压测一定要带完整的AI服务不能只压渲染层。部署环境里如果GPU资源不足数字人渲染和高精度场景同时跑可能会抢占CPU资源导致语音识别停顿。我们上线前就踩过这个坑数字人一开口后台模型推理变慢问答延迟从2秒飙到6秒整个交互体验直接崩掉。后来把数字人的渲染材质降了一档并单独限制了推理服务的CPU配额才算稳定下来。4. 常见问题与排查心得4.1 大模型回答幻觉与指代不明问答幻觉是所有RAG系统都会遇到的问题AI虚拟展示项目尤其明显。用户问的是展品的具体技术参数模型如果没检索到相关信息就开始“自由发挥”编造一个看着合理的参数这在B端客户面前是灾难级的失误。排查之后我们发现问题不只出在模型身上还出在“检索”这一个环节上。第一版知识库把展品详细说明按固定段落切分模型回答时经常只取到概述部分关键参数在另一段落里没有被召回。改进方案是双管齐下一方面调整切分策略每个展品都单独建一条“参数汇总”参数增改后自动更新另一方面在提示词里加严格要求检索不到时明确回答“该信息暂未收录请咨询人工客服”不允许编造。指代不明的问题也很典型。用户说“那它的功耗呢”如果上下文里有三个展品每个都有功耗参数模型不知道“它”指谁。我们当时的处理是在检索条件里把当前展厅的视野中心展品作为默认指代对象。前端每切换一次焦点展品都会上报到会话上下文对话服务在做意图分析时优先把它作为指代候选项。这个方案准确率非常高因为虚拟展厅和线下展厅一样用户提问时关注的通常就是眼前那个展品。4.2 首屏加载慢与场景切换卡顿首屏问题在上线前后反复出现。某次压测中我们发现首屏资源包虽然只有6.8MB但实际加载耗时远超预期。原因是部分用户处于弱网环境同时浏览器解析大尺寸JSON配置文件也占用了不少时间。于是做了两步优化一是把场景配置JSON从单文件拆成按展区拆分首屏只需要加载大厅配置进入展区后再加载该区配置二是所有静态资源从对象存储走CDN同时在本地做缓存二次访问直接走浏览器缓存。场景切换卡顿则是另一类问题。用户从大厅走进展区需要卸载大厅模型、加载新模型这个过程如果设计不好页面会白屏一两秒。我们改成了双场景无缝过渡预加载下一个场景的模型切换时新旧场景交叉淡入淡出。视觉上用户会觉得只是画面过渡了一下体感顺滑很多。代价是内存峰值上涨了一些但通过LOD控制模型精度后完全在预算内。4.3 并发峰值下的稳定性上线当天客户做了渠道推广瞬间涌进大量用户。对话服务扛住了但语音合成服务先扛不住了。因为对话回答后文本要送去语音合成合成服务依赖的外部资源有限峰值时排队时间长直接导致数字人“开口延迟”。排查发现是服务间缺乏熔断机制。对话服务不关心下游服务的健康状况只要回答生成了就往语音合成服务里发。下游一旦慢上游还在疯狂发请求雪球效应就出现了。修复方案分三步第一步在对话服务与语音合成之间加入请求队列队列满则直接丢弃非关键合成请求改由前端用纯文本展示第二步给语音合成加上限流超过阈值就返回繁忙状态第三步前端增加降级逻辑如果语音合成在3秒内未返回自动隐藏数字人说话动画只展示字幕。这套降级策略上线后后续几次推广活动再也没有出现过服务雪崩。核心思路是当AI服务不可用时系统要“降级但不崩”用户只是少了一个语音功能但问答和浏览还能正常继续。4.4 数字人口型错位与动作僵硬口型错位是数字人项目里最容易被用户感知的细节问题。现象是数字人的嘴巴已经闭上了语音还在继续播放或者嘴巴在动但完全对不上音。排查层次从前往后逐个看第一层音频与文本时间戳是否对齐。语音合成返回的时间戳是按字切的前端收到后要根据当前播放位置插值计算口型权重不能直接拿第一帧的时间戳去驱动。这里需要一个播放进度与时间戳的同步机制。第二层数学上有没做平滑。连续两帧的 blendshape 系数突变视觉上就是“卡壳”需要做一阶低通滤波把跳变大的帧平滑掉。第三层音素到口型的映射表是否合理。中文音节和元音辅音的组合非常多映射表不全时合成器只能选相近的音素口型自然不准。动作僵硬的问题没法完全靠算法解决只能靠动作模板数量。我们在后台一共预设了20多套动作覆盖讲解、致意、移动、交互引导等多个场景。每套动作之间用过渡动画衔接。实测下来动作模板数量多比动作本身精细更重要因为观众对“突然变动作”的敏感度远高于“动作幅度不够精确”。5. 项目复盘架构师视角的经验沉淀这个项目做完我对AI应用架构师这个角色的理解加深了不少。AI应用架构师不是单纯做模型调参的也不是单纯做后端开发的。真正的核心能力是把AI能力、场景体验、工程稳定性三者拧在一起做出一个能在真实业务里持续运转的系统。项目里最有价值的沉淀不是代码本身而是几条架构原则我试着总结一下AI能力一定做服务化永远不要让渲染端直接依赖模型。渲染端有自己的性能问题要处理如果它还要等待大模型推理、语音合成这些重计算瓶颈会互相放大。AI能力独立成服务后可以分别优化、独立降级也能复用到其他项目。知识库是AI展示项目的“内容供应链”优先级等同核心架构。知识整理、向量化、版本管理的管线要尽早搭好。后续所有内容更新包括新增展品、改参数、补FAQ都要能走同一套流程否则AI问答效果会随着内容维护的深入而逐渐退化。降级方案不是最后才做的而是架构的一部分。强依赖大模型的项目一定要预想“模型服务挂了”“语音服务慢了”这些场景。前端必须有无声模式、纯文字模式、静态展厅模式。用户感知体验降级永远好过系统直接不可用。最后说一个我做项目中特别深刻的体会AI驱动虚拟展示这类项目最能体现架构师价值的时间点不是代码写得多快而是问题出现时能快速定位是哪一个环节的锅。AI交互链路过长一旦体验出了问题排查链路往往跨越前端、网络、AI服务、语音服务、渲染引擎。能把这条排查链路理顺把每一层的日志、指标、降级开关都布好比单纯调优某个算法指标更重要。如果后续再扩展这个项目我会优先做两件事。一是用户行为数据的深度分析把浏览轨迹、问答记录、停留时长整合输出更精准的个性化观展路线。二是把数字人方案做成配置化让运营人员可以直接在后台配置数字人形象、动作模板和音色不用再依赖研发发版。这样项目就能真正从一个一次性的案例落地变成一个可以持续复用的产品。