1. 数字人这条产品线到底在卖什么先把一个常见的误解掰开很多人第一次听到“腾讯数字人”脑子里浮现的是那种直播间里循环念稿的虚拟主播或者短视频平台上用剪映卡通人物数字人拼出来的口播视频。这类东西确实属于数字人的范畴但它们只是最表层、最廉价的一档。真正在企业侧跑起来的数字人产品卖的根本不是“一个会动的形象”而是一套把知识、话术、交互逻辑和渲染管线打包在一起的交付能力。我在几个项目里接触过不同厂商的数字人方案踩过的坑基本都集中在同一个地方客户以为买的是“人”实际上需要的是“引擎”。形象只是壳子壳子下面的东西才决定这套系统能不能在真实业务里活过三个月。腾讯数字人这条线配合大模型知识引擎一起看逻辑就清楚了——数字人负责“表达层”知识引擎负责“认知层”两者通过一套对话编排和流式渲染管线串起来最终交付的是一个能回答业务问题、能执行特定任务、形象和语音都稳定的虚拟服务入口。这套组合拳解决的核心问题有三个。第一是内容生产的人力瓶颈企业里大量重复性的咨询、导览、讲解、培训场景靠真人录制或实时坐席成本极高数字人可以把这个边际成本压到接近零。第二是知识更新的时效问题传统数字人视频是录播的知识一变就得重录而接上知识引擎之后改的是后台文档前端形象不用动。第三是交互的自然度早期数字人只能播固定话术现在通过大模型做意图理解和多轮对话管理能应对用户临时冒出来的、没在脚本里的问题。适合看这篇内容的人我大致分三类。一类是正在做企业数字化项目的技术负责人需要判断数字人知识引擎这套方案能不能接进现有系统一类是产品经理想搞清楚这套东西的能力边界在哪别被演示视频忽悠还有一类是刚接触AIGC方向、想找一个具体落地场景来练手的开发者数字人这条线涉及渲染、语音、大模型调用、流式传输是个很好的综合练习场。下面我会按“知识引擎怎么搭—数字人怎么接—流式交互怎么跑—实际落地会踩什么坑”这个顺序展开尽量把每个环节里那些文档里不写、但实际做的时候一定会遇到的东西讲透。2. 大模型知识引擎的搭建逻辑与文档处理细节2.1 为什么不能直接把大模型裸接上去我见过太多项目一上来就想省事直接把大模型API接进数字人用户问什么就丢给模型答什么。这么做的结果通常撑不过一周。原因很直接——通用大模型对企业的私有知识一无所知你问它某款产品的保修政策它会用训练数据里最像的答案编一个给你语气还特别自信。这就是典型的幻觉问题在客服、导览这类场景里是致命的。知识引擎存在的意义就是在通用大模型和业务知识之间加一层检索增强生成的机制。用户的问题进来先去知识库里检索最相关的片段把这些片段作为上下文喂给大模型让模型基于真实资料来组织回答。这样既保留了大模型的语言组织能力又把事实来源锚定在企业自己的文档上。腾讯这套知识引擎的产品形态核心是围绕“文档导入—切分—向量化—检索—生成”这条链路做的。听起来简单但每一步都有讲究下面拆开说。2.2 文档切分最容易被低估的一步文档切分chunking这件事新手最容易随手用默认参数糊弄过去然后发现检索效果一塌糊涂。我拿一个真实场景举例某企业的产品手册是一份两百页的PDF里面有章节标题、表格、注意事项、参数列表。如果你按固定字数硬切比如每500字切一块很可能把一条完整的注意事项切成两半前半段在块A后半段在块B。用户问“这个设备能不能在潮湿环境用”检索命中了块A但块A里只有“在潮湿环境下使用时”后半句“必须保持通风且每周检查一次”在块B里没被召回模型就只能基于半句话回答答案自然不完整。我的经验是切分策略要跟文档结构走而不是跟字数走。具体做法上优先按标题层级切一个三级标题下的内容作为一个基本块如果单块超过800字再按段落二次切分但保留一定的重叠overlap重叠量控制在块大小的10%到15%之间。重叠的作用是防止关键信息正好落在切分边界上被割裂。还有一个细节表格和列表要单独处理。表格最好转成结构化的文本描述再入库比如“参数名X参数值Y”这种形式而不是直接把表格的原始文本丢进去。因为表格在PDF里提取出来往往是一堆错位的字符向量化之后检索质量极差。2.3 向量化与检索相似度不等于相关性向量化就是把文本块转成一串数字向量语义相近的文本在向量空间里距离更近。检索的时候把用户问题也转成向量找距离最近的几个块。这套机制的原理不难但实际用起来有个反直觉的点语义相似度高的块不一定是对回答最有用的块。举个例子用户问“你们的退款流程要几天”知识库里有三块内容块A讲的是“退款政策概述”块B讲的是“退款到账时间说明”块C讲的是“如何申请退款”。从语义相似度看块A可能得分最高因为它跟“退款”这个词最贴近。但真正能回答“几天”这个问题的是块B。如果只按相似度取Top1就会答偏。解决办法是混合检索向量检索负责语义匹配关键词检索负责精确命中两路结果做融合排序。腾讯知识引擎这类产品一般会提供混合检索的配置项实际调的时候我建议把向量检索和关键词检索的权重设成大致6:4然后根据业务语料的特点微调。如果业务里有很多专有名词、型号、编号关键词检索的权重可以再往上提。另外检索返回的块数量TopK也不是越多越好。取太多上下文里塞了一堆无关内容反而干扰模型判断取太少可能漏掉关键信息。我的习惯是先设TopK5然后拿一批真实问题做测试看召回率再决定是加到8还是减到3。2.4 提示词编排把检索结果用好的关键检索出来的内容怎么交给大模型这一步的提示词设计直接决定回答质量。一个常见的错误是把检索到的原文直接拼在问题前面不加任何约束。这样模型可能会把检索内容原封不动抄一遍或者把多个块的内容混在一起说逻辑混乱。比较稳的做法是在系统提示词里明确几件事一是告诉模型“只基于提供的参考资料回答资料里没有的信息不要编”二是要求模型“如果参考资料不足以回答问题明确说不知道并建议用户联系人工”三是规定回答的风格和长度比如“用口语化短句控制在三句话以内”。这几条约束看起来简单但能挡掉大部分幻觉和答非所问的情况。还有一点参考资料在提示词里的排列顺序也有影响。把检索得分最高的块放在最前面和最后面模型对这两个位置的注意力更强中间的内容容易被忽略。所以如果有一个块特别关键别把它放在中间。3. 数字人形象与语音链路的工程实现3.1 形象资产2D和3D的取舍数字人的形象分两大技术路线2D和3D。2D路线通常是用真人视频训练一个口型驱动模型输入音频输出口型同步的视频画面。3D路线则是建一个三维模型通过骨骼绑定和表情驱动来生成动画。两者的取舍很实际。2D路线的优势是真实感强、制作周期短一段几分钟的真人视频就能训练出可用的模型适合对形象真实度要求高、预算有限的场景比如企业客服、新闻播报。缺点是灵活性差形象一旦训练好很难做大幅度的动作变化视角也基本固定。3D路线的优势是可塑性强可以换装、换场景、做各种动作适合需要强交互和品牌个性化的场景比如虚拟导览员、游戏NPC。缺点是制作成本高建模、绑定、驱动调试一套下来周期不短。我个人的判断标准是如果业务只需要“一个人在那里说话”2D够用且性价比高如果需要“一个人在那里说话并且做动作、换场景、和用户有肢体互动”才上3D。别为了炫技上3D后期维护成本会让你后悔。3.2 语音合成自然度之外的工程指标语音合成这块大家关注的都是自然度、像不像真人。但在工程落地时有几个比自然度更影响体验的指标。第一个是首包延迟。用户说完话到数字人开口发出第一个音这个间隔如果超过1.5秒用户就会觉得“卡了”。语音合成服务从收到文本到返回第一段音频的时间是整条链路里的大头。选型的时候一定要实测这个指标别只看宣传页上的“自然度MOS分”。第二个是流式合成能力。大模型的回答是一个字一个字往外吐的如果等整段回答生成完再送去合成语音用户要等很久。流式合成是指文本一边生成语音一边合成生成一小段就播一小段。这要求语音合成接口支持流式输入不是所有服务都支持。第三个是多音字和数字读法。中文里多音字是老大难“行”读xing还是hang“重”读zhong还是chong靠模型自己判断经常出错。实际项目里我一般会在文本送合成之前做一层预处理把容易读错的词用拼音标注或者替换成同音字虽然土但有效。数字读法也一样“2024”是读“二零二四”还是“两千零二十四”得根据业务语境定规则。3.3 口型驱动与音画同步口型驱动的目标就一个让嘴型跟声音对得上。2D路线里通常是用一个口型分类模型把音频按帧切成小段每段判断对应哪个口型张嘴、闭嘴、圆唇等然后驱动形象做对应变化。3D路线则是通过音素到视素的映射控制模型的嘴部骨骼。实际做的时候音画同步的容差大概在80毫秒以内超过这个范围人眼就能察觉到“声画不同步”。调试的时候我会拿一段包含大量爆破音b、p、m的文本做测试因为这些音的口型变化最明显对不齐一眼就能看出来。还有一个容易被忽略的点静音段的口型。用户不说话的时候数字人如果完全静止会显得很假。通常会让它保持一个轻微的呼吸动作或者眨眼频率这些微动作能大幅提升“活着”的感觉。腾讯这类产品一般会内置待机动作但动作的幅度和频率要调太频繁显得焦躁太慢显得呆滞。4. 流式交互链路从用户提问到数字人开口4.1 整条链路的拆解把前面几块拼起来一次完整的交互是这样的用户语音输入 → 语音识别转文本 → 文本送知识引擎检索 → 检索结果问题送大模型生成回答 → 回答文本流式送语音合成 → 音频流驱动口型 → 数字人开口。这条链路里串行环节越多延迟越高。优化的核心思路是能并行的并行能流式的流式。比如语音识别可以在用户还在说话的时候就做流式识别不用等他说完大模型生成和语音合成可以流水线作业生成一句合成一句。我实测下来一个优化得比较好的链路从用户说完话到数字人开口端到端延迟可以压到1.2秒左右。其中语音识别占200毫秒检索占150毫秒大模型首token占400毫秒语音合成首包占350毫秒剩下的是网络和调度开销。每个环节省一点加起来就很可观。4.2 SSE流式输出在前端的落地大模型的回答要实时渲染到界面上通常用SSEServer-Sent Events来做。服务端每生成一小段文本就通过SSE推给前端前端追加到对话气泡里。这个机制本身不复杂但实际写的时候有几个坑。第一个坑是中断处理。用户可能在数字人还在说话的时候就想打断它问下一个问题。这时候前端要能发一个中断信号服务端收到后停止生成同时语音合成也要停。如果没做这个用户会觉得“它不听我说话”。实现上一般用AbortController来取消fetch请求服务端配合做生成中断。第二个坑是标点与分句。大模型吐出来的文本是逐字或逐词的如果直接把每个字都送去语音合成合成出来的音频会非常碎语气不连贯。通常的做法是在前端或中间层做缓冲遇到句号、问号、感叹号这类句子结束符才把这一句送去合成。这样合成出来的语音才有正常的语调起伏。第三个坑是错误重试。流式传输过程中网络抖动可能导致连接断开如果直接报错给用户体验很差。稳妥的做法是在前端做自动重连并从断点继续接收。不过这要求服务端支持断点续传实现起来有一定复杂度小项目可以先做简单的整体重试。4.3 多轮对话的状态管理数字人不是一问一答就结束的用户会追问、会切换话题、会指代前文。比如用户先问“你们有哪些产品”数字人答了一串用户接着问“第二个多少钱”这里的“第二个”就需要结合上一轮的回答来理解。多轮对话的状态管理核心是维护一个对话历史每次请求大模型时把最近几轮的历史一起带上。但历史不能无限带太长会超出模型的上下文窗口也会增加延迟和成本。我的做法是保留最近5轮对话更早的做摘要压缩把关键信息提炼成一句话保留。还有一个细节是话题切换检测。如果用户突然问了一个跟当前话题完全无关的问题继续带着旧历史反而会干扰模型。可以在检索阶段判断新问题跟历史的语义距离如果距离过大就清空历史重新开始。5. 实际落地中那些文档不写的坑5.1 知识库冷启动没有文档怎么办很多企业兴致勃勃要上数字人一问知识库发现文档散落在各个员工的电脑里格式五花八门有的还是纸质扫描件。这种情况下冷启动是个大工程。我的建议是分两步走。第一步先圈定高频问题不用一上来就追求大而全。把客服记录、销售话术、常见咨询整理出来通常两三百个问答对就能覆盖80%的咨询量。第二步把这些问答对结构化入库同时把相关的产品文档做切分补充进去。先跑起来再根据实际问不到的问题逐步补充。扫描件和图片里的文字需要先做OCR提取。OCR的质量直接影响后续检索所以这一步别省钱用质量好的OCR服务提取完还要人工抽检一遍把明显的错字改掉。5.2 数字人“答非所问”的排查思路上线之后最常见的投诉就是“它答的不是我问的”。排查这个问题我一般按这个顺序走。先看语音识别有没有转错。用户说的是“退款”识别成了“推款”后面全错。这个通过看识别日志就能确认。如果识别没问题再看检索召回的块是不是相关的。把用户问题和召回的块打出来对比如果召回的内容跟问题八竿子打不着说明检索环节有问题要么是切分不合理要么是向量模型不适合这个领域的语料。如果召回没问题那就是大模型组织答案的问题回去调提示词。这个排查链路看起来简单但实际做的时候很多团队一上来就怀疑大模型不行换模型、调参数折腾半天最后发现是语音识别把关键词转错了。所以顺序很重要从链路前端往后查。5.3 并发与成本控制数字人大模型这套东西每个环节都是要花钱的。语音识别按分钟计费大模型按token计费语音合成按字符计费数字人渲染按并发路数计费。一个看似简单的问答背后是四五个计费项在跑。控制成本的核心是减少不必要的调用。比如用户问了一个知识库里明确有标准答案的问题可以直接返回标准答案不用走大模型生成。再比如一些寒暄类的问题“你好”“谢谢”可以用规则匹配直接回复不用调大模型。这些优化能省下相当可观的费用。并发方面数字人渲染是最吃资源的环节。如果预期同时在线用户多要么提前扩容要么做排队机制。我见过一个项目演示的时候好好的一上线搞活动同时涌进来几百人数字人直接卡成PPT。所以压测一定要做而且要按峰值并发的一点五倍来压。5.4 合规与内容安全企业级应用里内容安全是红线。数字人说的话代表企业一旦输出了不当内容后果很严重。所以知识引擎和大模型之间必须加一层内容过滤。过滤分两个方向。一个是输入过滤用户问的问题里如果有敏感内容直接拦截不送大模型。另一个是输出过滤大模型生成的回答在送语音合成之前过一遍敏感词库和内容审核接口有问题就替换成标准话术。这层过滤会增加一点延迟但跟合规风险比起来这点延迟完全值得。另外知识库里的文档本身也要做审核确保没有过时的、错误的、有歧义的内容。我建议知识库上线前做一轮人工审核上线后定期抽查发现答错的问题及时回溯到知识库修正。6. 从演示到生产一套可复用的上线检查清单6.1 上线前的功能验收项在正式对外之前我会拿一份检查清单逐项过。这份清单是我从几个项目里攒出来的能挡掉大部分低级问题。检查项验收标准常见问题语音识别准确率在业务语料上测试字准确率95%以上专有名词识别错误知识检索召回率100个真实问题召回相关块的比例90%以上切分不合理导致漏召回大模型回答准确率100个问题回答正确的比例85%以上幻觉、答非所问端到端延迟从用户说完到数字人开口1.5秒以内语音合成首包慢口型同步无明显声画不同步爆破音口型对不上打断响应用户打断后1秒内停止说话中断信号未传递到合成环节并发承载峰值并发1.5倍压力下不崩溃渲染资源不足内容安全敏感问题拦截率100%过滤规则有遗漏这张表里的每一项都要拿真实数据测不能靠感觉。特别是准确率类的指标一定要有测试集不能只测几个自己编的问题。6.2 上线后的监控指标上线不是终点是起点。数字人系统跑起来之后有几个指标要持续盯着。首包延迟的P95值也就是95%的请求延迟在什么水平。平均值好看没用要看长尾。如果P95超过2秒说明有一部分用户体验很差要查是哪个环节拖后腿。知识库命中率也就是用户问题能在知识库里找到相关内容的比例。这个比例如果持续下降说明业务在变化知识库该更新了。用户主动中断率用户没等数字人说完就打断的比例。这个比例高说明回答太长或者答得不对用户没耐心听。转人工率用户聊了几句就要求转人工的比例。这是最直接的满意度指标转人工率高说明数字人没解决问题。6.3 迭代节奏的建议我的经验是上线后前两周每天看数据把答错的问题整理出来每天更新一次知识库和提示词。两周之后问题会收敛到一个比较稳定的水平改成每周更新一次。一个月之后如果转人工率稳定在可接受范围就可以进入常规运维了。知识库的更新不是简单地加文档而是要分析用户实际问的问题看哪些问题知识库里没有覆盖针对性地补充。我一般会建一个“未命中问题”的收集表每周过一遍把高频的未命中问题优先处理。7. 关于这套方案后续扩展的一些个人想法数字人知识引擎这套组合目前最成熟的落地场景还是客服、导览、培训这类“问答式”交互。但它的潜力不止于此。我最近在琢磨的一个方向是任务型交互也就是数字人不仅能回答问题还能帮用户完成操作比如查订单、改预约、提交工单。这需要在知识引擎之外再接一层业务系统的API调用能力让大模型能根据用户意图决定调哪个接口、传什么参数。这个方向技术上可行但工程复杂度会上一个台阶主要是意图识别的准确率和接口调用的容错要做好。另一个方向是多模态输入。现在用户主要是用语音跟数字人交互未来可以支持用户上传图片、拍个照数字人识别图片内容后给出回答。比如用户拍一张设备故障的照片数字人识别出故障类型直接给出处理建议。这需要把视觉模型接进链路对整体架构的改动不小但场景价值很高。还有一个我觉得被低估的点是数字人的个性化。同一个知识引擎可以驱动不同形象、不同音色、不同说话风格的数字人服务不同场景。比如面向老年用户的版本语速慢一点、用词通俗一点面向专业用户的版本可以直接上术语、给参数。这种“一个大脑、多个面孔”的架构在成本上比每个场景单独做一套要划算得多。这些扩展方向有的我已经在项目里试了一部分有的还在验证阶段。整体感觉是数字人这条线的技术栈已经比较成熟了真正的门槛不在单点技术而在把各个环节串起来、调稳、控住成本。这也是为什么我前面花了那么多篇幅讲切分、讲延迟、讲排查因为这些才是决定项目能不能活下来的东西。