有道技术沙龙博客-新全讯平台

　　有道纵横是网易有道旗下专为-8岁孩子量身打造的在线年启动，自研了全国首部在线交互式围棋动漫课程，从孩子的理解力和喜好出发，采用直播互动的课程形式将围棋知识变得简单有趣、易懂好学，帮助孩子掌握围棋的各类规则和技巧。不仅如此，课后还设有ai对弈功能，能够智能识别孩子的段位水平匹配对局练习，从根源培养孩子的思维习惯。每局对弈结束后的智能分析，会从大局观、计算力、稳定性、战斗和棋型五方面进行全方位分析，帮助孩子在复盘中进步。

　　google旗下deepmind提出的alphago、alphago zero、alphazero系列算法展示了深度强化学习在棋类领域超凡的能力。6年alphago横空出世击败欧洲围棋冠军樊麾二段，2017年以4：1击败韩国围棋职业九段，14个世界冠军得主李世石，2018年无师自通的alphago zero以：0击败zui年轻的六冠王柯洁九段。至此以后再无人质疑ai在围棋领域的霸主地位，同时引发了职业棋手学习ai招法的热潮。在职业围棋赛场上，时常出现“狗招”，学习、研究ai招法的背后的逻辑，已是职业棋手的必修课。

　　github上已经有了leela zero、katago等基于alphazero系列算法的优秀围棋ai开源项目，它们的主要目标是提升ai的棋力，目前上述围棋ai的棋力已远超人类职业棋手。然而当强ai应用在少儿围棋教学时，出现了“水土不服”的现象，比如：

　　• ai实在是太强了，人很难在与ai对弈的过程中体会到“旗鼓相当”的感觉，这极易引起用户的挫败感。

　　• 授人以鱼而未授人以渔，ai只告诉人应该这么下，而不教会人为什么这么下。

　　• ai的学习路径与人大相径庭，一些在人早期围棋学习阶段就可以掌握的知识（如征子），ai在训练后期才掌握。

　　有道围棋ai团队隶属于有道人工智能语音组，负责有道纵横产品与围棋ai相关的研发、落地工作，主要发力点在于ai的人机对弈和复盘。现有的工作成果引用一段ceo周枫的话：

　　总体上有道纵横是一个面向孩子的围棋启蒙课程，大班直播、名师教学，在边学边练过程中有丰富的互动，同时也具备ai对弈能力。与此同时，有道纵横将教、学、练、测、评五个环节做了非常好的整合，形成了这个产品的全貌。

　　技术团队永远都说ai老师特别有用，可以解决个性化教学的问题，可以因材施教；老师背景的团队往往觉得ai老师就是洪水猛兽，既没有用而且骗了很多vc的钱。

　　纵横项目当中做了比较多的ai老师的思考和实践。我们看法是，大众对于ai的认知，其实对于产品团队来说是个双刃剑，只有认识到双刃剑的作用才能做出正确的设计。

　　什么是双刃剑？一方面ai是一个非常好的营销抓手；另外一方面，用户不懂做产品，团队必须去自己寻找真正的ai价值点。如果你听用户对哪个东西兴奋就做哪个，zui后往往掉坑里了。

　　在ai场景下，我们思考了非常久。首先想到alphago，不管多牛都下得过你，但这么和用户讲显然不可能，所以本身对弈的难度和棋力不是教学当中ai的指标，而是如何降低难度，怎么能够灵活的调整难度。

　　所以，diyi，我们团队花了大量功夫做难度可控的、棋力可控的围棋ai；第二，可控棋力的ai和复盘能力；第三，我们推的是学员和学员、学员和老师之间的对弈，强调人人对弈而不是人机对弈，人机对弈只是找不到人对弈时候的补充手段。

　　通过这样的手段，我们实现了自主研发的围棋ai，教学过程当中能够代替掉人的部分工作，提高了团队的生产效率。

　　一些其他方案在实现人机对弈系统时，一般使用ai训练过程早期的模型，然后使用模型的top-n输出，随机抽样进行落子行为，避免ai落子过于单一。

　　这种方案除了易于想到之外没有其他优点，由于早期模型训练量不大，采用top-n的采样方法会导致ai的招式没有条理，用户很容易诱导出这种落子逻辑的******（如征子）。其次，在对弈过程中，ai模型和落子策略是固定的，但我们在实践中发现，ai对于围棋中的布局、中盘、收官等阶段的招法学习速度并不相同，ai对布局的掌握速度远远超出中盘、收官，使用相同的模型和策略会导致ai在整盘棋的表现差异极大。再者，ai的自对弈训练中，没有定式的概念（定式是围棋高手在某些局部的经验总结，用户学习定式走法可以快速提升棋力），低水平的ai很难在局部中下出zui优解，而人可以通过学习高手的棋谱快速掌握局部zui佳下法，即使人的水平并没有达到提出该定式的围棋高手水平。上述问题的根源在于ai与人的学习路径大相径庭，难以直接移植。

　　• 弃用top-n随机抽样的落子策略，使用ai引擎的policy输出，按概率采样。保证了ai招法逻辑性、连贯性。

　　• 在不同手数阶段，结合胜率和目差信息，调用不用的ai模型。保证ai在不同阶段的水平表现相近。

　　• 结合教学内容，实现ai模型和定式模板的混合输出。巩固用户学到的定式知识。

　　复盘指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。一般用以自学，或请高手给予指导分析。下围棋的高手都有复盘的习惯。复盘就是每次博弈结束以后，双方棋手把刚才的对局再重复一遍，这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的******，是提高自己水平的好方法。在有道纵横产品中，ai承担了复盘老师的角色。

　　一些其他方案中，ai复盘主要是展示整局棋的胜率或目差曲线、ai的推荐变化图、以及一些基础的统计数据，这些内容更适合专业的用户，专业用户的需求在于快速定位自己下的不好的棋，然后根据ai提供的变化图等推理ai的落子逻辑，此类用户仅根据围棋ai引擎的原始数据就可以完成自我学习。

　　但是当用户群体定位到少儿时，上述的0008全讯注册的解决方案效果就会大打折扣，少儿用户很难理解统计数据背后的意义，同时对ai提供的变化图的逻辑缺乏分析能力，甚至注意力很难集中在变化图上，仅关注整局棋的胜率、目差的变化。此外，其他方案采用的复盘使用的gpu资源消耗很大，有的用户甚至需要半天时间才能拿到对局的复盘结果。

　　• 引入语音组的tts技术，将复盘结果翻译成少儿用户易于接受的文案，提升用户的注意力。

　　• 性能优化，在少儿用户的使用场景中，用户并不需要高算力ai产生的复盘结果，我们指定了根据局面的复杂程度分配算力的方案。

　　目前围棋ai的技术主要集中于提升ai水平上，这固然为专业用户自我训练提供了极大的便利，但由于高水平ai背后的行棋逻辑较为高深，当围棋ai为少儿用户提供服务时，少儿用户很难直接从高水平ai获取知识。

　　接下来我们希望可以在人机对弈场景中，为用户提供水平更合适、逻辑更连贯的ai陪练；在复盘场景中，为用户提供更清晰易懂的复盘报告。

　　本次以redis为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，主要将从声明式管理，operator工作原理，容器编排，主从模式，集群模式，高可用策略，集群扩缩容等方面展开。

　　redis 是业务系统中较为常用的缓存服务，常用于流量高峰、数据分析、积分排序等场景，并且通过中间件可以实现系统之间的解耦，提升系统的可扩展性。

　　传统物理机部署中间件，需要运维人员手动搭建，启动时间较长，也不利于后期维护，无法满足业务快速发展的需求。

　　云原生相较于传统it，可以助力业务平滑迁移、快速开发、稳定运维，大幅降低技术成本，节约硬件资源。

　　云原生中间件是指依托容器化、服务网格、微服务、serverless等技术，构建可扩展的基础设施，持续交付用于生产系统的基础软件，在功能不变的前提下，提高了应用的可用性与稳定性。

　　在这种大趋势下，有道基础架构团队开始了云原生中间件的实践，除了本文介绍的 redis，还包括 elasticsearch、zookeeper 等。

　　利用云原生技术可以解决当前redis部署缓慢，资源利用率低等问题，同时容器化 redis 集群也面临着一些挑战：

　　对于一个 redis 集群，我们的期望是能够 724 小时无间断提供服务，遇故障可自行修复。这与kubernetes api的声明式特点如出一辙。

　　所谓“声明式”, 指的就是我们只需要提交一个定义好的 api 对象来“声明”我所期望的状态是什么样子，kubernetes中的资源对象可在无外界干扰的情况下，完成当前状态到期望状态的转换，这个过程就是reconcile过程。例如，我们通过yaml创建了一个deployment ,kubernetes将“自动的”根据yaml中的配置，为其创建好pod，并拉取指定存储卷进行挂载，以及其他一系列复杂要求。

　　因此，我们的redis集群是否可以使用一个类似的服务去完成这个过程呢？即我们需要定义这样的对象，定义服务reconcile的过程。kubernetes的operator刚好可以满足这个需求，可以简单的理解operator由资源定义和资源控制器构成，在充分解读集群和operator的关系后，我们将整体架构图设计如下

　　哨兵模式中redis服务用一套哨兵集群，使用statefulset部署，持久化配置文件。redis server也采用 statefulset部署, 哨兵模式的实例为一主多从。

　　redis的资源定义在etcd中存储一份即可，我们只需要预先提交自定义资源的 yaml配置。如下所示为创建三个副本的redis主从集群：

　　operator 无需任何修改，即可从 kubernetes 核心中获得许多内置的自动化功能，如使用 kubernetes 自动化部署和运行工作负载， 甚至可以自动化 kubernetes 自身。

　　kubernetes 的 operator 模式可在不修改 kubernetes 自身的代码基础上，通过控制器关联到一个以上的定制资源，即可以扩展集群的行为。operator 是 kubernetes api 的客户端，核心功能是充当定制资源的控制器。

　　用户创建一个crd自定义资源，apiserver把crd转发给webhook，webhook 进行缺省值配置 验证配置和修改配置，webhook处理完成后的的配置会存入etcd中 ，返回给用户是否创建成功信息。controller 会监测到crd，按照预先写的业务逻辑，处理这个crd，比如创建pod、处理新节点与旧集群关系等，保证运行的状态与期望的一致。

　　redis 集群在 kubernetes 中的zui小部署单位为 pod，因此在架构设计之前，需预先考虑redis特性、资源限制、部署形态、数据存储、状态维护等内容，为不同类型的redis集群配置合适的部署方式。

　　• request(资源需求)：即运行pod的节点必须满足运行pod的zui基本需求才能启动。

　　• limit(资源限制)：即运行pod期间，可能内存使用量会增加，那zui多能使用多少内存，这就是资源限额。

　　redis 基本不会滥用 cpu，因此配置1-2个核即可。内存根据具体业务使用分配，考虑到部分场景下会fork较多的内存，例如 aof 频繁刷写，aof 重写过程中，redis 主程序称依旧可以接收写操作，这时会采用 copy on write (写时复制)的方法操作内存数据，若业务使用特点为“写多读少”，那么刷写期间将产生大量的内存拷贝，从而导致 oom，服务重启。

　　一个有效的解决方式为减少刷写次数，将刷写操作放在夜间低流量时段进行。减少刷写次数的方法为适当增加auto-aof-rewrite-min-size的大小，可配置使用内存的5倍甚至更大的zui小刷写量；其次可以主动触发刷写，判断内存使用达到的配额两倍时进行刷写，实际部署时一般也会预留50%的内存防止oom。

　　依据数据是否需要持久化或是否需要weiyi标识区分服务为无状态和有状态的服务，redis集群需要明确主从、分片标识，大部分场景也需要数据持久化，kubernetes使用statefulset来满足这一类需求。statefulset的顺序部署、逆序自动滚动更新更能提高redis集群的可用性。

　　• proxy无需存储任何数据，使用deployment部署，便于动态扩展。

　　redis server 启动时需要一些配置文件，里面涉及到用户名和密码，我们使用 configmap 和 secret 来存储的。configmap 是 kubernetes的api 对象，常用于存储小于1mb的非机密键值对。而 secret 可以用于存储包含敏感信息的密码、令牌、密钥等数据的对象。

　　两种资源均可以在 pod 运行的时候通过 volume 机制挂载到 pod 内部。

　　redis容器化后建立的每个 cr 表示一个完整的redis服务，具体的服务模式包括哨兵模式和集群模式两种，在进行容器化过程中，除覆盖裸服务器部署结构外，也对架构进行了一定程度的优化。

　　所有实例共用一组哨兵将进一步提高实例启动速度，并在一定程度上可提高硬件资源利用率，实测单组哨兵可轻松应对百规模的主从集群。

　　检查是否按照预期启动了全部的pod，比如创建3个server，那么需要按照预期启动三个才能继续进行后面的操作。

　　检查master的数量，确保该实例仅有一个主节点（数量为0主动选一个；数量大于1手动修复）。

　　检查redis config是否有做修改，有则对所有节点重写config参数。

　　通过在传统redis cluster架构中引入代理功能，实现动态路由分发，并基于kubernetes原生动态扩缩容特性，更易应对突发流量，合理分配使用资源。

　　• 对于操作单个key的命令，proxy会根据key所属的slot（槽）将请求发送给所属的数据分片。

　　• 对于操作多个key的命令，如果这些key是储存在不同的数据分片，proxy会将命令拆分成多个命令分别发送给对应的分片。

　　（1）处理失败节点, 对部分节点重启后的无效ip、状态为noaddr的僵尸节点进行forget操作；

　　（2）处理不可信节点 (所有handshake状态的节点)，发生于某一个节点被移除（由forget node触发），但试图加入集群时，即该pod在operator角度下存在，但实际集群节点并不需要该节点，处理方式为删掉这个pod，并再次做forget操作直到pod被删除。

　　为statefulset中的pod建立主从关系，同时给其分配slots。若当前master数量同预期不一致，则对应扩缩容操作，具体见’集群扩缩容’的横向扩缩容小节。

　　检查redis config是否有做修改，有则对所有节点重写config参数。

　　从代理获取redis server信息，将集群信息同步到所有的代理上，代理中不存在的server ip做移除操作。

　　若代理中无可用redis server, 表示被全部移除，则添加一个，代理可自动发现集群其他redis节点。

　　redis部署zui小资源对象为pod，pod是kubernetes创建或部署的zui小/zui简单的基本单位。

　　当启动出错，例如出现“crashloopbackoff”时，kubernetes将自动在该节点上重启该pod,当出现物理节点故障时，kubernetes将自动在其他节点上重新拉起一个。

　　pod未出问题，但程序不可用时，依托于健康检查策略，kubernetes也将重启该redis节点。

　　节点纵向扩容时，使用statefulset的滚动升级机制，kubernetes将逆序重启更新每个pod，提高了服务的可用性。

　　kubernetes本身不处理redis 多个pod组建的集群之间的部署关系，但提供了部署策略，为保证特定场景下的高可用，如因物理节点导致所有redis节点均宕机，crd在设计中加入了亲和与反亲和字段。

　　默认使用 podantiaffinity 做节点打散，如下所示实例instance1的所有 pod 将被尽可能调度到不同的节点上。

　　redis 服务运行期间不可避免的出现各种特殊情况，如节点宕机、网络抖动等，如何持续监测这类故障并进行修复，实现 redis 集群的高可用，也是 operator 需解决的问题，下面以哨兵模式模式为例描述集群如何进行故障恢复。

　　主节点宕机：因物理节点驱逐、节点重启、进程异常结束等导致的redis主节点宕机情况，哨兵会进行切主操作，然后kubernetes会在可用物理节点上重新拉起一个pod。

　　从节点宕机：哨兵模式的redis集群未开启读写分离，从节点宕机对服务无影响，后续kubernetes会重启拉起一个pod，operator会将该pod设置为新主节点的从节点。

　　集群全部节点宕机：发生概率极小，但基于持久化可将服务影响降至zui低，集群恢复后可继续提供服务。

　　节点网络故障：主从模式下配置了三个哨兵用于集群选主操作，哨兵集群的每一个节点会定时对 redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复sentinel节点的心跳包，则该redis节点被该sentinel节点主观下线。

　　当节点被一个 sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要sentinel集群的其他sentinel节点共同判断为主观下线才行。

　　如果客观下线的 redis 节点是从节点或者是sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。

　　集群模式故障转移与上述类似，不过不需要哨兵干预，而是由节点之间通过ping/pong实现。

　　纵向扩缩容主要指pod的cpu、内存资源的调整，基于kubernetes的特性，只需修改实例对应的spec字段，operator的调和机制将持续监测参数变化，并对实例做出调整 。当修改cpu 、内存等参数时，operator同步更新statefulset的limit、request信息，kubernetes将逆序滚动更新pod，滚动更新时，若停掉的是主节点，主节点的prestop功能会先通知哨兵或者集群进行数据保存，然后做主从切换操作，从而将服务的影响降至zui低。更新后的主从关系建立以及哨兵monitor主节点功能也由operator一并处理，全过程对客户端无感知。主从版、集群版在该场景下均支持秒级断闪。

　　横向扩缩容主要指副本数或节点数的调整，得益于 kubernetes 的声明式 api，可以通过更改声明的资源规模对集群进行无损弹性扩容和缩容。

　　redis server扩容操作时，主从版本中operator将获取新节点ip, 新启动节点将在下一轮调和时触发slaveof 主节点操作，且同步过程中，哨兵不会将该节点选为主节点。集群版本中operator将在同步节点信息后进行分片迁移，保证所有节点上的slots尽可能均匀分布。

　　redis server缩容操作时，主从版本中operator将逆序销毁pod，销毁时会先询问哨兵，自己是否为主节点，若为主节点则进行先failover操作再退出。集群版本中operator中会先进行分片迁移，再对该节点做删除操作。

　　代理的扩缩容，更易实现，根据流量波峰波谷规律，可手动定期在波峰到来时对 proxy 进行扩容，波峰过后对 proxy 进行缩容；也可根据hpa实现动态扩缩容，hpa也是kubernetes的一种资源，可以依据kubernetes 的metrics api的数据，实现基于cpu使用率、内存使用率、流量的动态扩缩容。

　　本次以 redis 为范例，阐述了有道基础架构团队在基础设施容器化道路上的实践，redis上云后将大幅缩短集群部署时间，支持秒级部署、分钟级启动、启动后的集群支持秒级自愈，集群依托于哨兵和代理的特性，故障切换对用户无感知。

　　有道架构团队zui终以云平台的形式提供中间件能力，用户无需关注基础设施的资源调度与运维，重点关注具体业务场景，助力业务增长。未来，将进一步围绕redis实例动态扩缩容、故障分析诊断、在线迁移、混合部署等内容展开探索。

　　kubernetes 是一个容器编排系统，可以自动化容器应用的部署、扩展和管理。kubernetes 提供了一些基础特性：

　　部署：部署更快，集群建立无需人工干预。容器部署后可保证每个的redis节点服务正常，节点启动后将由operator持续监测调和redis集群状态，包括主从关系、集群关系、哨兵******、故障转移等。

　　资源隔离：如果所有服务都用同一个集群，修改了redis集群配置的话，很可能会影响到其他的服务。但如果你是每个系统独立用一个redis群的话，彼此之间互不影响，也不会出现某一个应用不小心把集群给打挂了，然后造成连锁反应的情况。

　　(2) 网络故障：因宿主机网络故障带来的实例延迟高，哨兵可进行主从切换，而为了保证集群的健康，将由operator负责同步集群信息。

　　扩缩容：容器部署可根据limit和request限制实例的cpu和内存，也可以进行扩缩容操作，扩容后的故障恢复由operator处理。

　　节点调整：基于operator对crd资源的持续调和，可在operator的controller中为每个redis实例进行状态维护，因此，节点调整后带来的主副关系建立、集群slots迁移等均可自动完成。

　　数据存储：容器化可挂载cephfs、localstorage等多种存储卷。

　　******与维护：实例隔离后搭配exporter、prometheus等******工具更容易发现问题。

　　自 2017 年 10 月推出有道翻译蛋开始，网易有道已先后推出了二十余款智能学习硬件产品，包括有道翻译王、有道口袋打印机、有道超级词典、有道词典笔、有道听力宝等。

　　其中，有道词典笔开创了智能词典笔品类，连续两年获天猫、京东销量diyi，并广受用户好评。

　　在近期有道词典笔的全新软件升级中（关联阅读：全新软件升级！真的很有料），有两个重要的优化，分别是：

　　为了给用户带来更好的体验，有道 ai 团队选取了多种真人发音素材，从来自公司内部、真实用户和 native speakers 等人群中选取足够大的样本发放调查问卷，从发音准确度、音色喜爱度等方面进行打分，并和专业的发音进行比较，zui终选取了目前版本中的音色。

　　在语言学习场景中，机械式的发音不仅让人觉得枯燥乏味，而且会影响口语学习的效果。zui自然、zui理想的交互莫过于通过人的声音进行交流。如何让智能学习硬件的发音接近真人，是一个重要的课题。

　　同时，通过有道 ai 团队对语言模型的不断训练，有道词典笔的发音准确度再一次得到突破，在******句子的过程中，有道词典笔可以快速预判语义，轻松读对一些英语学习者和 ai 都非常容易读错的单词，比如「多音词」。

　　以包含“read过去式”的句子为例，我们来听听有道词典笔的发音和传统机械式发音：

　　这些能力的背后，是有道 tts 语音合成技术的加持。本文将会详细介绍有道 tts 技术的相关思考和实践。

　　有道 tts 语音合成技术建模流程包括文本分析模块、声学模型模块和声码器模块。

　　文本分析前端的主要作用是将语句转换为语言学特征，主要是音素序列和韵律特征, 其中音素序列决定 tts 是否正确读对了文本；韵律特征决定 tts 的停顿位置、自然度等，这也是有道 tts 技术能够实现接近真人发音和正确朗读多音词的关键所在。

　　传统的文本分析模块会单独建模每个任务，并且串行处理效率较低，这种做法在嵌入式场景中难以实现性能和质量的平衡，多个任务分离也会提高系统的维护成本。

　　相比于传统方案，有道 ai 团队基于 bert 预训练模型进行了多任务建模，将多个任务进行统一建模，大大提高了效率。

　　这些优化能够支持 tts 前端的文本正则化、多音字判别、韵律预测等任务，使有道系统能够在设备端合成低发音错误、韵律自然和感情丰富的高质量语音。

　　基于这些问题，我们主要做了以下几个方面的工作，分别是资源收集、模型实验、系统集成：

　　结合词性、词义等细化多音字模型标签，使得建模更高效；在中文古诗词、文言文发音上，通过 ssml 技术将词典笔海量权威发音词典资源应用到tts 发音中；

　　模型实验：在模型实验阶段，前端包含有多音字、韵律预测、分词、词性预测等这些任务，

　　通过构建bert多任务模型，联合预测多音字、韵律、分词、词性任务，多个任务之互相促进不仅了提升多音字模型和韵律模型的准确率，同时也节省了参数量；zui后通过蒸馏技术，小参数量多任务模型在保证质量的同时，也达到嵌入式性能要求；

　　系统集成:在系统集成阶段，工程化团队通过自研bert pipeline技术，更进一步优化了内存和推理时间；

　　通过这些方面的工作，zui终推出了基于预训练模型的多任务架构 tts 中英混前端，保证了 tts 合成的发音正确性和韵律停顿。

　　声学模型的主要作用是将语言学特征转换为对应的声学特征。常见的神经网络声学模型大致可以分成两大类：

　　一是自回归声学模型：比如 tacotron、tacotron2，优点是高自然度，缺点是性能较差；基于 attention 的自回归声学模型难以建模长语音，更容易出现丢字、重复的现象。

　　二是非自回归声学模型：比如fastspeech、fastspeech2，优点是并行生成声学特征，性能好，对长句建模足够鲁棒；缺点是韵律建模略差于自回归声学模型。

　　综合质量和性能，有道 ai 团队zui终选择了基于 vae 的非自回归声学模型。原因在于它有以下优势：

　　同时，我们针对一部分算子的计算耗时占总时长比例较大的问题进行了工程上的优化，进一步改善了系统整体的实时率。

　　声码器的作用是将声学模型输出的声学特征转换成语音时域信号。它直接影响着合成语音的音质，因此对于用户体验来说至关重要。

　　一是音质问题。声码器模型的建模能力不足，会直接导致合成语音产生底噪或者电音。但如果仅仅只是单纯地加大模型的参数，则会影响系统的推理速度。

　　二是性能问题。声码器的计算量在语音合成的整个框架中占比较大。要在嵌入式场景中合成高质量的语音，需要一个足够大、建模能力足够强的声码器模型。

　　但由于设备芯片的算力弱、内存小，大的声码器会导致体验延时明显上升。从用户的角度出发，延时过长，用户等待时间过久，自然不会有好的体验效果。

　　为了解决以上难题，通过大量实验和综合比对，zui终有道 ai 团队选择了基于 gan 方案的声码器。

　　首先是针对不同场景使用不同的模型配置，有道 ai 团队对 gan 声码器中的*********模块进行了参数的细致调整，让它能够成功应用在嵌入式场景下，不同于传统参数声码器的机械感与模糊感，基于 gan 的神经网络声码器可以合成高自然度、高清晰度的音频，缩短了离线 tts 和在线 tts 质量上的差距。

　　此外，我们还在模型的量化、压缩方面做了大量的工作，大大提升了语音合成的速度，明显降低了系统的资源占用。

　　在智能硬件产品人机交互中，语音合成技术扮演着非常重要的角色，但在落地中面临着很多挑战，其核心是硬件计算资源与合成语音质量之间的矛盾。

　　如何更快地、更稳定地在有限资源下提供高质量的语音合成技术是有道 ai 团队的目标和关注的重点。

　　目前，有道 tts 语音合成技术已应用在许多内部和外部的在线场景和嵌入式场景，并表现出了相对传统方案更加稳定、更加鲁棒的合成效果。

　　相信了解算法同学经常会说动态规划太难了，看到题目完全不知从何下手，或者是说“一看题解就会，一看题目就废”这样的一个状态。本质上是由于学习动态规划的时候，学习方法不对，zui终导致南辕北辙，没有掌握其中精髓。而动态规划与递推算法又有着暧昧不清的关系，我们选择先从递推算法入手，一步一步揭开动态规划的神秘面纱。

　　本文是《玩转typescript工具类型》系列的zui后一篇，包含了如下几部分内容：

　　本文是《玩转typescript工具类型》系列的第二篇，包含了如下几部分内容：

产业招商/厂房租售：
或微信/******： 
请说明您的需求、用途、税收、公司、联系人、******号，以便快速帮您对接资源。 
长按/扫一扫加葛毅明的微信号