想象一下,你要组建一支“即兴话剧小剧组”:编剧负责现场想台词,配音负责把台词念得动听,演员负责用表情和肢体把情绪演出来,舞台监督则掐着秒表调度全场。观众抛来一句话,所有角色必须在两三秒内默契配合,完成一次滴水不漏的即兴演出。对话驱动数字人系统,就是把这支剧组装进服务器和浏览器里:LLM 是编剧,TTS 是配音,口型与表情模块是演员,延迟优化是舞台监督的调度艺术。这篇文章会带你从零组建这支“数字人剧组”,把系统架构、角色人设、对话管理、语音合成、口型同步、表情动作和延迟优化这七块拼图逐一装好——读完你就能把一个能聊天、有表情、会动作的完整数字人“导演”出来。

岗位关联

数字人正从“短视频道具”走向“实时交互入口”,掌握对话驱动数字人系统的搭建方法论,是你在 AIGC 应用层建立差异化竞争力的关键技术资本,更是通往虚拟客服、虚拟陪伴、智能助手等落地场景的直通车。

目录
  1. 可视化演示
  2. 1. 系统架构设计
  3. 2. LLM角色人设
  4. 3. 对话管理
  5. 4. 语音合成TTS
  6. 5. 口型同步
  7. 6. 表情动作联动
  8. 7. 延迟优化
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示对话驱动数字人ASR→LLM→TTS→动画全流程、多模态输入融合、实时优化与性能指标,步进切换探索系统架构。

本节配有交互动效(进入视口后自动加载,约 3KB)。

对话流程:四阶段管线 ASR语音识别转文本 LLM理解生成回应 TTS语音合成+ANI动作渲染 pipeline = ASR → LLM → TTS → Animation 端到端对话响应延迟控制在500ms内

1. 系统架构设计

剧组开演前,第一件事是画一张组织架构图:导演管全局、编剧管台本、配音管声音、演员管表演。没有这张图,二十个人挤在台上只会乱成一团。对话驱动数字人系统也一样——用户面前是一个会说话的形象,背后却是无数模块的协同作战。先想清楚“谁负责什么、消息怎么传”,系统才不会变成一锅粥。

在工程上,我们把这支剧组分成三层。交互层是前台:负责采集用户语音、展示数字人画面;决策层是编剧组:LLM 在这里接收指令、生成回复,对话管理模块负责记忆“之前聊到哪了”;表达层是表演组:TTS 把文字变成声音,口型同步让嘴动起来,表情动作模块让身体活起来。三层之间通过“消息总线”传递数据,就像剧组里对讲机传话——每个部门只依赖消息格式,不关心对方内部怎么工作,这就是模块解耦。

理解了三层架构,你就掌握了评估数字人体验的总公式:从用户说完话,到看见数字人开口,总耗时是三层耗时的累加:

这张架构图就是剧组的“部门墙”。有了清晰的分工,后面每一块拼图都可以单独打磨:编剧(LLM)写得再快,配音(TTS)跟不上,观众照样觉得卡壳。所以接下来,我们就逐个部门进场。

T端到端=T交互+T决策+T表达T_{\text{端到端}} = T_{\text{交互}} + T_{\text{决策}} + T_{\text{表达}}
端到端延迟由交互、决策、表达三部分串联相加,每一环都可能成为体验瓶颈。
  1. 端到端总耗时这是用户感知到的“数字人反应速度”,从麦克风收音结束到画面出现回应动作的总时间。
    T端到端T_{\text{端到端}}
  2. 交互层耗时包括音频上传、网络传输、画面渲染刷新的时间,相当于“前线士兵传令”的成本。
    T交互T_{\text{交互}}
  3. 决策层耗时LLM 等待输入、生成首个 token 的时间,是“编剧构思”的成本,通常占比最大。
    T决策T_{\text{决策}}
  4. 表达层耗时TTS 合成第一段音频、口型表情驱动起效的时间,是“演员准备出场”的成本。
    T表达T_{\text{表达}}

2. LLM角色人设

一个剧组如果让编剧随心所欲地写台词,演员今天演成霸气总裁、明天演成邻家小妹,观众一定会疯掉。数字人开演前,必须先给 LLM 写一份“人物小传”——这就是人设提示词。它决定数字人是温柔客服、知心姐姐,还是毒舌主播。

这份人物小传一般放在系统提示词(System Prompt)里,在每次对话开始时发送给 LLM。它像一份拼接出来的简历,把所有约束清清楚楚写进去:你是谁、你什么性格、你懂什么、你说话什么语气、哪些话打死不能说。例如“你是小云,一名温柔耐心的产品咨询顾问,只回答产品相关问题,不聊八卦、不说脏话”。别小看这段话——它同时干了两件事:性格一致性保证 100 轮对话后数字人还是“同一个人”;知识边界防止它一本正经地编造公司不存在的产品功能。

人设提示词可以抽象成一个拼接公式:

人物小传写得好,数字人一出场就“立住了”;写不好,它就会像人格分裂的演员,把观众吓跑。但小传只是剧本的第一步——聊天的台词还得有人管。

P人设=[身份]+[性格]+[知识]+[语气]+[边界]P_{\text{人设}} = [\text{身份}] + [\text{性格}] + [\text{知识}] + [\text{语气}] + [\text{边界}]
人设提示词由身份、性格、知识、语气、边界五要素拼接而成,共同约束数字人的言行风格。
  1. 身份定位告诉 LLM 它扮演的是客服、老师还是主播,这是人物小传的第一行。
    [身份][\text{身份}]
  2. 性格刻画用“温柔耐心”“活泼外向”等词约束回复的情感底色。
    [性格][\text{性格}]
  3. 知识范围写明可调用的产品资料、常见 FAQ,让回答有据可依。
    [知识][\text{知识}]
  4. 语气风格规定用词习惯,比如“多用'您'、少用网络梗”。
    [语气][\text{语气}]
  5. 边界约束列出禁区,如“不评价竞品、不讨论政治”。
    [边界][\text{边界}]

3. 对话管理

即兴话剧最怕忘词。演员需要一台提词器,随时能看到“刚才说到哪了、观众问了什么”。数字人的提词器就是对话管理模块——它负责把多轮对话的上下文组织好,喂给 LLM。

但提词器不能把整本剧本全背下来:LLM 有上下文长度限制,塞得越多,费用越高、反应越慢,而且旧信息会“淹没”新指令。工程上最常用的策略叫滑动窗口:只保留最近 K 轮问答,更早的内容直接丢弃。就像舞台上的提词屏只显示最近几行台词,演员反而演得更专注。当用户问到窗口外的话题,或者 LLM 忍不住“跑偏”时,还需要兜底策略——预先写好的万能回复,比如“这个话题我还没学会,换个问题好吗”,避免冷场。

滑动窗口的保留内容可以精确描述为:

提词器稳住了台词,下一步该配音演员上场了——让文字变成有温度的声音。

S窗口={Qi,Ai}i=N−K+1NS_{\text{窗口}} = \{ Q_i, A_i \}_{i = N-K+1}^{N}
对话管理只保留最近 K 轮问答对,超出窗口的早期内容被丢弃,以平衡记忆与性能。
  1. 当前轮次 NN 代表累计对话总轮数,每多一轮对话它就加一。
    NN
  2. 窗口大小 KK 是保留轮数上限,常见的取值为 5~10 轮。
    KK
  3. 窗口起点从第 \(N-K+1\) 轮开始截取,前面的内容被滑动出去。
    N−K+1N-K+1
  4. 窗口内容从起点到第 N 轮的问答对集合,就是喂给 LLM 的上下文。
    {Qi,Ai}i=N−K+1N\{ Q_i, A_i \}_{i = N-K+1}^{N}

4. 语音合成TTS

台词写在纸上是死的,得有人把它念出来。TTS(语音合成)就是数字人的配音演员,负责把 LLM 的回复文本变成充满感情的语音。

这可不是随便找个机械音念稿子。现代 TTS 支持音色定制:你可以克隆、调节声线,让数字人拥有专属嗓音——温柔的女声、沉稳的男声,甚至明星音色。合成时还要做韵律控制:哪里停顿、哪里加重、什么语速,都要按文本语义和情感来调整,否则听起来像机器人读说明书。

但配音演员如果非要把整段话念完才开口,观众早等急了。所以生产环境必须用流式合成:TTS 一边生成前几个字的音频,一边就把数据包发给播放器,实现“边生成边播”。流式合成的总等待时间可以这样理解:

配音演员的声音出来了,但观众看到的是“人在说话”——嘴必须跟声音对得上。这就轮到口型同步登场了。

T流式=T首包+L剩余R合成T_{\text{流式}} = T_{\text{首包}} + \frac{L_{\text{剩余}}}{R_{\text{合成}}}
流式 TTS 的总延迟等于首个音频包的等待时间,加上剩余文本长度除以合成速度。
  1. 首包时间从文本送入 TTS 到生成第一段音频数据的时间,这是用户感知的“开口速度”。
    T首包T_{\text{首包}}
  2. 剩余文本量整段回复减去首包已覆盖部分的文本长度。
    L剩余L_{\text{剩余}}
  3. 合成速率TTS 每秒能合成的文本字符数,硬件越强、模型越快,这个值越高。
    R合成R_{\text{合成}}
  4. 流式总延迟首包时间加后续文本分批合成的时间,远小于整段合成再播发的方案。
    T流式T_{\text{流式}}

5. 口型同步

配音演员在录音棚里念台词,前台演员在舞台上做口型——如果两边各演各的,观众看到的就是一部“译制片腔”的灾难现场。口型同步就是让声音和嘴形严丝合缝的那场排练。

具体怎么做?TTS 生成语音时,我们能拿到文本对应的音素序列(比如“你好”拆成 n、i、h、ao)。每个音素都对应一种嘴部形态,叫口型(Viseme)——发“a“张大嘴,发”m”抿嘴。系统把音素映射成口型系数,再去驱动 3D 模型的嘴部骨骼网格变形。关键在时序对齐:哪个音素的音频在 0.3 秒播放,口型帧就必须在 0.3 秒摆到位。

人眼其实很宽容,只要误差控制在一定阈值内就察觉不到“穿帮”。对齐误差公式:

口型对上后,数字人勉强像个人了,但还像个“面瘫演员”。要让她真正活起来,得加上表情和动作。

D对齐=∣t音频−t口型∣≤δD_{\text{对齐}} = |t_{\text{音频}} - t_{\text{口型}}| \leq \delta
音频播放时刻与口型帧时刻的绝对差值必须小于容差阈值 δ,通常取 0.1~0.2 秒。
  1. 音频播放时刻某个音素对应的声音真正从扬声器传出的时间点。
    t音频t_{\text{音频}}
  2. 口型呈现时刻同一个音素对应的嘴部动画帧渲染出来的时间点。
    t口型t_{\text{口型}}
  3. 绝对误差两者之差的绝对值,正值或负值都代表偏移。
    ∣t音频−t口型∣|t_{\text{音频}} - t_{\text{口型}}|
  4. 容差阈值工程上允许的误差上限,小于它人眼看不出别扭。
    δ\delta

6. 表情动作联动

一个优秀的演员不只是念台词——说到开心事会笑,提到难过处会皱眉,激动时还会挥手。表情动作联动模块,就是数字人的“即兴表演体系”。

表演的第一步是情绪识别:从 LLM 的输出文本或 TTS 的音频特征中,判断当前这句话的情绪是高兴、难过、惊讶还是中性。第二步是动作触发:根据情绪从动作库里挑选合适的动作——识别到“开心”就微笑加挥手,识别到“抱歉”就低头加摊手。为了让动作选择更聪明,工程上会给每个动作算一个触发得分,综合情绪强度、动作出现频率、上次播放时间等因素:

有了这套“表演体系”,数字人终于能演出一场完整的戏了。但观众最敏感的还是“快不快”——最后一块拼图,就是让一切发生得更快。

S动作=we⋅E情绪+wf⋅F频率−wd⋅D打断S_{\text{动作}} = w_e \cdot E_{\text{情绪}} + w_f \cdot F_{\text{频率}} - w_d \cdot D_{\text{打断}}
动作触发得分由情绪强度、频率偏好加权求和,再减去打断惩罚项,得分超过阈值才触发动作。
  1. 情绪强度当前语句表达某种情绪的程度,比如“太开心啦”得分高于“还行”。
    E情绪E_{\text{情绪}}
  2. 频率偏好该动作历史触发频率的偏好项,让常用动作更容易被选中。
    F频率F_{\text{频率}}
  3. 打断惩罚距离上一个动作结束的时间越短,惩罚越大,防止疯狂抽搐。
    D打断D_{\text{打断}}
  4. 权重系数\(w_e\)、\(w_f\)、\(w_d\) 分别控制三项的权重,需要调参找到最佳观感。
    we,wf,wdw_e, w_f, w_d

7. 延迟优化

话剧演得再好,如果观众抛出一句话要等十秒才有回应,再精彩的表演也会被喝倒彩。舞台总监的职责,就是想办法让各个部门并行开工,把等待压到最短。

延迟优化的三板斧如下。首包优化:让 LLM 用流式输出,第一个字刚生成就传给 TTS,TTS 也流式合成,音频边到边播——观众听到的不是“整段话”,而是“最先冒出来的半句话”。并行管线:传统串行是“用户→LLM→TTS→表情”一步步排队,流水线并行则让 ASR 在 LLM 思考的同时预先处理下一句,各环节重叠执行。缓存机制:把高频问题(“你叫什么名字”“怎么退货”)的回复和对应音频预先算好,命中缓存就直接播放,连 LLM 都不必惊动。

流水线并行之后,总延迟不再等于所有模块之和,而是大幅压缩:

到这里,这支“数字人剧组”完整成型了:编剧想词、提词器记话、配音念白、演员对口型做表情,舞台总监让全场高效运转。把这套体系交给任意一家公司,你都能导演出一台合格的“数字人好戏”。

T流水线=T首+max⁡i(Ti)T_{\text{流水线}} = T_{\text{首}} + \max_{i} \left( T_i \right)
流水线并行下,总延迟约等于首模块耗时加上所有模块中最慢的那一个,而不是串行累加。
  1. 首模块耗时流水线第一棒(通常是语音识别或取缓存)的固定启动耗时。
    T首T_{\text{首}}
  2. 所有模块耗时LLM、TTS、表情等各环节各自的处理时间集合。
    {Ti}\{ T_i \}
  3. 取最大值并行执行时,总时长由最慢的模块决定,就像合唱由最慢的声部拖节奏。
    max⁡i(Ti)\max_{i} \left( T_i \right)
  4. 流水线总延迟首模块耗时加最慢模块耗时,远小于串行累加总和。
    T流水线T_{\text{流水线}}

AI 应用场景

电商平台虚拟客服

阶段:系统架构设计 + LLM 角色人设 + 对话管理

解决的问题:传统客服依赖人工,夜间无人值守、高峰期排队严重。数字人客服用 LLM 理解用户问题,配合 TTS 语音回答和 3D 形象表情安抚,实现 7×24 小时零等待服务,且通过人设提示词圈定知识边界,避免答错售后政策。

具体案例:某电商平台上线数字人“小云”。用户问“这款手机支持 5G 吗”,小云调取产品库给出肯定答复,同时 TTS 流式发声、口型同步开合、嘴角上扬做出微笑表情。遇到超纲问题,兜底话术自动接管:“我帮您转接人工客服哦。”

教育数字人陪练老师

阶段:对话管理 + 表情动作联动

解决的问题:口语学习用户不敢开口、缺乏反馈。数字人老师利用滑动窗口记住学生前几轮的发音错误,用鼓励语气对话,并在答对时触发“点赞竖拇指”动作,营造无压力的练习场。

具体案例:英语陪练数字人检测到学生反复读错“th“音,在对话中温和纠正:”注意舌尖要轻触上齿哦。”纠正时配合微微前倾的关切表情和放慢的语速,学生更愿意开口尝试。

直播弹幕互动虚拟主播

阶段:语音合成 TTS + 口型同步 + 延迟优化

解决的问题:真人主播无法同时回应海量弹幕,且长时间直播声音疲劳。虚拟主播用 LLM 聚合弹幕问题,TTS 流式合成声音,口型同步自动配音,延迟优化保证弹幕提问后 2 秒内得到回应。

具体案例:一场带货直播中,观众刷“这个杯子能保温多久”,虚拟主播 0.8 秒后开口回答,同时做出“双手捧杯”展示动作,声音与嘴型严丝合缝,几乎感觉不到机器感。

Python 演示

python62 行
class DigitalHumanPipeline:    def __init__(self, persona):        self.persona = persona        self.history = []        self.max_turns = 5        self.gc_count = 0     def build_prompt(self, user_text):        recent = self.history[-self.max_turns * 2:]        lines = [self.persona["system"]]        for role, text in recent:            lines.append("{}: {}".format(role, text))        lines.append("user: " + user_text)        return "\n".join(lines)     def generate_reply(self, user_text):        self.gc_count += 1        prompt = self.build_prompt(user_text)        reply = self.simple_rules(user_text)        self.history.append(("user", user_text))        self.history.append(("assistant", reply))        return reply     def simple_rules(self, text):        name = self.persona["name"]        if "你好" in text:            return "{}:你好呀,见到你真开心!".format(name)        if "名字" in text:            return "{}:我叫{},是你的专属数字助手。".format(name, name)        return "{}:嗯嗯,我在认真听你说哦。".format(name)     def tts_chunks(self, reply, chunk_size=6):        return [reply[i:i + chunk_size] for i in range(0, len(reply), chunk_size)]     def render_events(self, reply):        emotion = "happy" if ("开心" in reply or "你好" in reply) else "neutral"        return {            "mouth": [("a", 0.1), ("o", 0.3), ("e", 0.5)],            "emotion": emotion,            "gesture": "wave" if emotion == "happy" else "nod"        }  def main():    persona = {        "name": "小云",        "system": "你是小云,一名温柔耐心的产品咨询顾问,"                  "只回答产品相关问题,不聊八卦,不说脏话。"    }    dp = DigitalHumanPipeline(persona)    for q in ["你好", "你叫什么名字", "给我讲个笑话吧"]:        reply = dp.generate_reply(q)        events = dp.render_events(reply)        print("Q: " + q)        print("A: " + reply)        print("TTS chunks: " + str(dp.tts_chunks(reply)))        print("动画事件: " + str(events))        print()  if __name__ == "__main__":    main()
目的:模拟一个最小可跑的对话驱动数字人后端管线,包含人设提示词、滑动窗口对话管理、流式 TTS 分块和表情动作事件生成。
  1. self.history[-self.max_turns * 2:]滑动窗口取最近 max_turns 轮问答对(每轮两条记录),超出窗口的旧对话被丢弃。
  2. lines = [self.persona["system"]]每次构建提示词都把“人物小传”放在最前面,确保 LLM 始终记得自己的角色人设。
  3. self.history.append(("user", user_text))把当前用户提问写入记忆,供下一轮构建上下文时使用。
  4. dp.tts_chunks(reply)将完整回复切成 6 字一块的音频分块列表,模拟流式 TTS 的“边生成边播”。
  5. render_events(reply)根据回复文本判断情绪,输出口型音素、表情和手势事件,对应真实系统中的表情动作联动模块。

常见误区

误区我以为做个数字人就是找个好看的 3D 模型,再调个 ChatGPT 接口,就能上台跟用户对话了。结果模型导进去之后,数字人只会发呆,嘴都不张。

正解3D 模型只是演员的“皮囊”,真正让她像活人的是 TTS 配音、口型同步、表情动作和延迟优化这整套“表演管线”。就像光有演员不配音、不动肢体,戏根本演不起来。一个能用的数字人必须把决策层和表达层全部打通,缺一环都会变成“念稿木偶”。

为何常见:Demo 视频只展示最终效果,观众看不到背后十几套模块的协同,天然以为“看起来简单”。

误区为了让数字人记住更多细节,我把所有历史对话、产品手册全塞进提示词,结果它反应越来越慢,还经常答非所问。

正解LLM 有上下文长度硬限制,塞太满不仅 token 成本飙升、延迟暴增,还可能让关键指令被淹没。滑动窗口只保留最近 K 轮,配合摘要记忆保存长期信息,才是工程正解——就像舞台上只给演员看最近几页台词,反而演得更专注。

为何常见:人类直觉是“记得越多越聪明”,忽略了 Transformer 的注意力会被超长上下文稀释。

误区我给数字人设计了上百个动作,每说一个词就配一个手势,结果它看起来像个抽搐的提线木偶,观众直呼可怕。

正解动作过密会抢占注意力、破坏口型同步,还会显得机械。真人表演讲究“留白”,动作只在情绪高点出现,且必须有打断控制:上一个动作没播完之前,新动作触发会被扣分或直接拦截。

为何常见:特效大片看多了,以为动态越多越震撼,忽略了现实表演的节奏感。

误区我以为给数字人接入 TTS 语音,她自然就会动嘴——毕竟声音和画面是同一个“人”发出来的嘛。

正解TTS 输出的是音频流,口型同步是独立的动画驱动系统:先从文本提取音素,映射到口型系数,再驱动网格变形,最后做时间轴对齐。两者在架构上分属不同部门,靠对齐机制“拧”在一起,工程上甚至可能是两台服务器上的不同服务。

为何常见:人说话时嘴和声音天然同步,这种根深蒂固的体感让人误以为软件里也是自动的。

误区数字人回复慢,我盯着 LLM 推理速度死磕,GPU 换了、量化做了,结果用户还是说卡——一查才发现 TTS 合成和网络传输各占了一秒。

正解端到端延迟是各环节串行时间的总和,任何一个部门掉队都是瓶颈。正确姿势是全面优化:ASR 并行、LLM 流式首 token、TTS 流式分块、表情动作缓存,再用流水线把串行变并行。

为何常见:LLM 是全场最耀眼的明星,大家都盯着明星化妆,忘了后台的灯光、音响、道具每个环节都在计时。

面试题

Q1. 对话驱动数字人系统中,LLM 最主要的职责是什么?

单选题 · easy

  • A.绘制数字人的三维角色模型
  • B.理解意图并生成自然语言回复← 正确答案
  • C.控制扬声器的音频播放音量
  • D.渲染面部表情的逐帧动画

答案:B。LLM 相当于剧组的“编剧”,负责听懂用户的话并写出回复;三维建模、音量控制、表情渲染分别归属美术、播放器和动画模块。把编剧的活派给道具组,戏就演砸了。

Q2. 口型同步系统最核心的输入数据是什么?

单选题 · easy

  • A.用户端的摄像头实时画面流
  • B.文本内容转换出的音素序列← 正确答案
  • C.数字人模型的顶点贴图文件
  • D.后台服务器的负载监控指标

答案:B。口型同步需要知道每个字怎么读——音素序列就是发音的最小单位。顶点贴图属于建模资产,摄像头画面属于交互输入,负载指标属于运维数据,都与嘴型驱动无直接关系。

Q3. 对话管理中滑动窗口策略的直接作用是?

单选题 · mid

  • A.让大模型看到全部历史对话记录
  • B.截断早期对话避免上下文过长← 正确答案
  • C.给用户的每条回复添加表情符号
  • D.提升语音合成引擎的音色自然度

答案:B。滑动窗口只保留最近 K 轮问答,把更早的内容“滑出窗外”,避免上下文长度爆炸。它并不会增加历史记录,也与表情、音色无关。

Q4. 流式 TTS 相比传统整段式 TTS 的最大优势是?

单选题 · mid

  • A.消耗更少的 GPU 量级推理资源
  • B.首包音频到达用户端的时间更早← 正确答案
  • C.自动纠正模型产生的发音错误
  • D.完全不需要任何文本预处理操作

答案:B。流式 TTS 生成第一个音频块就立刻送出播放,用户听到“开口声”的等待大幅缩短。它并不省显卡、不能纠错,预处理也依然要做。就像配音演员先说一句“你好”让观众听到,再补后面的台词。

Q5. 表情动作联动中“打断控制”机制的核心目的是?

单选题 · mid

  • A.减少服务器端的显存占用压力
  • B.避免动作过密导致表现不自然← 正确答案
  • C.加快语音合成引擎的合成速度
  • D.压缩表情动画的媒体传输带宽

答案:B。打断控制给动作加“冷却时间”,防止上一个动作没播完又触发新动作,避免数字人变成抽搐木偶。它与显存、合成速度、带宽都不是一个层面的问题。

Q6. 流水线并行模式下端到端总延迟约等于什么?

单选题 · hard

  • A.全部模块延迟叠加求和的最终值
  • B.首模块延迟加最慢模块延迟两项← 正确答案
  • C.最慢模块延迟数值的约一半左右
  • D.平均每个模块延迟的固定倍数

答案:B。流水线并行让模块重叠执行,总时长由“第一棒启动时间 + 最慢一棒用时”决定,而不是串行求和。好比合唱队不是等第一个人唱完再唱第二个,而是大家一起开口,整体时长由最慢的声部决定。

Q7. 人设提示词中明确“知识边界”的主要作用是?

单选题 · hard

  • A.防止数字人回答超出设定范围问题← 正确答案
  • B.提升语音合成模型的发声响度等级
  • C.增加对话日志的存储持久化时间
  • D.加速口型同步模块的逐帧渲染速度

答案:A。知识边界在提示词中写明“能说什么、不能说什么”,LLM 遇到超纲问题时会拒绝回答或转人工。这项约束管的是“编剧”,跟音色响度、日志存储、口型渲染完全不沾边。

Q8. 以下哪些模块属于对话驱动数字人的核心组成?

多选题 · mid

  • A.LLM 对话生成与人设管理模块← 正确答案
  • B.语音合成 TTS 与流式播放模块← 正确答案
  • C.口型同步与表情动作驱动模块← 正确答案
  • D.机房 UPS 不间断电源供电模块

答案:ABC。数字人的核心管线是“决策层(LLM)→ 表达层(TTS)→ 表演层(口型表情)”,这三者缺一不可。UPS 属于机房基础设施,任何软件系统都用得到,不是数字人特有的核心模块。

Q9. 下列措施中能有效降低数字人交互延迟的有?

多选题 · mid

  • A.TTS 边合成边播的流式输出方案← 正确答案
  • B.缓存高频问题的历史回复内容← 正确答案
  • C.ASR、LLM、TTS 串行逐段等待
  • D.各模块建立重叠执行的并行管线← 正确答案

答案:ABD。流式输出边生成边播、缓存高频答案、并行管线都是延迟优化的经典三板斧。串行等待恰恰是延迟问题的根源,会让用户在每一环都干等,属于应该被优化的反例。

Q10. 关于口型同步的时序对齐机制,正确的说法有?

多选题 · extreme

  • A.音频播放时刻需与口型帧严格对齐← 正确答案
  • B.允许微小容差范围内的对齐误差存在← 正确答案
  • C.对齐误差只影响音质不影响观看体验
  • D.工程上通常设置对齐误差阈值进行控制← 正确答案

答案:ABD。口型与音频必须在时间轴上对准(A 对),但人眼有一定容忍度,工程上设置阈值\[\delta\]来控制即可(B、D 对)。对齐误差影响的是“嘴型与声音对不上”的视觉穿帮,跟音质无关,C 说反了。