背景
去年，我下载了 Percona Live 2022 的一个视频，标题是《High Availability and Disaster Recovery Made Easy With MySQL InnoDB ClusterSet 》。由于英语听力不太好，我就想着把视频上传到飞书上，利用飞书妙记，转为语音和文字对照看，去理解视频的内容知识。但飞书妙记的语音转文字的效果也太糟糕了吧！
以下是开头的节选：
So I'm going to present about. I know to be closer set, which is disaster recovery for I know the big cluster. My name is Leonardo. I'm a senior support engineer at Percona, I've been working with my SQL. And Mongo there for the last 3 years and with other database technologies for the past 8 years. And here is a bit about the agenda for today.
We're going to talk about the concept of I know to be closer set and to do that. We will need to start with I know the closer an? Work away from there. Then we will talk about some use cases and limitations of finally cluster sets. Some requirements that you need to the plight. Then we're going to see how it can be applied and some basic maintenance is which is controlled switch over an emergency fail over.
So the other big cluster set is disaster recovery solution for another big cluster, coupled with a lot of great my SQL shell automation. So too. Talk more about closer set we need to first understand what is the I know to be closer. Which is complete that I know to be closer is the high availability solution for I know Debbie? Which is different from the cluster set? Which is a disaster recovery solution for this HA solution? And I know that be closer.
如果不配图，相信大家都没看懂，他讲的是 InnoDB ClusterSet
方面的内容，因为文中大量的 InnoDB ClusterSet
被飞书妙记听成了 I know to be closer set
。
还有 MySQL
被认为是 my SQL
，这完全不是一个意思了。其他的错误之处我就不说了，我重点关注这两块。
分享嘉宾是 Leonardo Bacchi Fernandes，居住在巴西圣保罗，不清楚母语是哪里，可能他不是英语母语者，我无法确认，或许未来 AI 能帮助我分辨这个人是什么母语者，持有什么口音。我能确认的只有，他不是印度的咖喱味口音，英语还算标准，我能听懂个大概。他某个重点单词的发音和我们不一样，将 "innodb" 读作 "I-no-db"，而不是 "in-no-db"。
我们可以确定的是，飞书妙记的这段文字表达得非常混乱，普通人很难理解！
飞书妙记翻译
飞书妙记可以直接将源语言翻译成中、日、英三种语言。然而，由于英文原文质量非常差，翻译成中文后，效果更糟糕。以下是翻译内容：
所以我要介绍一下。我知道要更紧密，这是灾难恢复，因为我知道大集群。我叫莱昂纳多。我是 Percona 的高级支持工程师，我一直在和我的 SQL 一起工作。过去 3 年和 Mongo 在那里，过去 8 年使用其他数据库技术。这是今天的议程。
我们将讨论我知道要更接近并做到这一点的概念。我们需要从我知道的越近开始？远离那里工作。然后我们将讨论最终集群集的一些用例和限制。你需要困境的一些要求。然后我们将看看它是如何应用的，一些基本的维护是在紧急故障转移时控制开关。
所以另一个大集群集是另一个大集群的灾难恢复解决方案，加上很多很棒的我的 SQLshell 自动化。所以也是。谈论更多关于更近的设置，我们需要首先了解什么是我知道的更近。哪个是完整的，我知道更接近的是高可用性解决方案，因为我知道黛比？与集群集有哪些不同？哪个是此 HA 解决方案的灾难恢复解决方案？
文中可以清楚地看到，翻译中完全没有提及 InnoDB ClusterSet
，因此翻译完全离题。另外，my SQL
被翻译成了 “我的SQL”
。
接下来，我将尝试使用 ChatGPT 的 GPT-4 引擎进行翻译。在翻译之前，我会先给出一个提示(prompt)。
https://docs.qq.com/sheet/DT1FBVlhPclpLc3RG?tab=BB08J2 （提示出处自这里，版权所有：卡兹克）
有了这个提示，AI 相较于飞书，能够主动修改文章中的拼写错误和逻辑错误。
GPT-4 第一次翻译
那么，我将要进行的演讲主题是关于 InnoDB ClusterSet，这是一个针对 InnoDB 大型集群的灾难恢复方案。我叫 Leonardo，是 Percona 的一名高级支持工程师。过去 3 年里，我一直在处理 MySQL 和 MongoDB，而过去 8 年里我一直在处理其他数据库技术。以下是今天演讲的大纲：
我们将讨论 InnoDB ClusterSet 的概念。为了解释这个概念，我们需要从 InnoDB Cluster 开始，然后逐步展开。接下来我们将讨论一些使用场景和 ClusterSet 的局限性。然后我们会讲述实施该方案所需的一些要求。最后，我们将探讨如何应用此方案以及一些基本的维护操作，包括控制切换和紧急故障转移。
InnoDB ClusterSet 是一种为 InnoDB 集群提供灾难恢复的解决方案，搭配了许多实用的 MySQL Shell 自动化功能。为了更深入地了解 ClusterSet，我们首先需要理解 InnoDB Cluster 的概念。InnoDB Cluster 是一种针对 InnoDB 数据库的高可用性解决方案，与 ClusterSet 有所不同。ClusterSet 是为这种高可用性解决方案提供灾难恢复支持的方案，而 InnoDB Cluster 则是针对 InnoDB 数据库的高可用性解决方案。
我们可以看到 GPT-4 不仅修正了 I know to be closer set
为 InnoDB ClusterSet
，还修正了 my SQL
为 MySQL
，并且整个翻译自然，符合人类阅读。
GPT-3.5 翻译
今天我要介绍的主题是灾难恢复方案 - 知道大集群的 InnoDB closer set。我叫 Leonardo，是 Percona 的高级支持工程师，过去三年一直在使用 MySQL 和 Mongo 等数据库技术，总共有 8 年以上的工作经验。接下来，我会简单介绍一下今天的议程。首先，我们会讲一下 InnoDB closer set 的概念，需要先了解 InnoDB closer an。然后，我们会讨论一些使用情况和限制条件，以及使用该技术所需的一些要求。最后，我们会讲解如何应用它，并介绍一些基本的维护方法，如控制转换和紧急故障转移。InnoDB closer set 是另一个大集群的灾难恢复解决方案，同时也提供了很多 MySQL shell 自动化的功能。因此，想要深入了解 closer set，我们首先需要了解什么是 InnoDB closer an，这是 InnoDB 高可用性解决方案，与集群解决方案不同。
接下来，作为对比，我用上一代的 GPT-3.5 引擎进行翻译，效果就差了很多。在我关注的点中，虽然 GPT-3.5 能把 I know to be
修正为 InnoDB
，但 closer set
未修正为 ClusterSet
。此外，不知道为什么 GPT3.5 不排版，文字挤在一起很难看！
GPT-4 第二次翻译
那么，我将介绍关于。我知道要更接近集合，这是灾难恢复，我知道大集群。我叫莱昂纳多。我是 Percona 的高级支持工程师，过去 3 年来一直在使用 MySQL 和 Mongo，过去 8 年里一直在使用其他数据库技术。这里是今天的议程。
我们将谈论关于 InnoDB Cluster Set 的概念，为了做到这一点，我们需要从 InnoDB Cluster 开始？然后从那里继续。接下来我们将讨论一些使用案例和最终的集群集合限制。您需要实现的一些要求。然后我们将看看如何应用它以及一些基本维护，例如控制切换和紧急故障切换。
所以 InnoDB Cluster Set 是 InnoDB Cluster 的灾难恢复解决方案，结合了许多优秀的 MySQL Shell 自动化。所以，要更多地了解 Cluster Set，我们首先需要了解什么是 InnoDB Cluster。它是完整的 InnoDB Cluster，是 InnoDB 的高可用性解决方案？与 Cluster Set 不同？后者是这种高可用性解决方案的灾难恢复解决方案。而 InnoDB Cluster。
在使用了 GPT-3.5 翻译之后，再切换回 GPT-4 进行翻译，居然整个翻译相较于第一次，质量下降了（对比看看标黄部分）。我感觉原因可能是，在 GPT-3.5 引擎翻译后，我没有告诉 GPT 它翻译得不好，所以它继承了部分 GPT-3.5 的糟糕翻译。
GPT-4 第三次翻译
在告诉 ChatGPT 翻译得不好之后，ChatGPT 及时进行了调整，翻译质量又恢复正常了。
总结
GPT-4 引擎的翻译能力非常惊人，它甚至可以修正错误的语料，确实比 GPT-3.5 强很多。不建议在同一段翻译中更换引擎，因为这可能会影响 GPT-4 的翻译质量。当然了，GPT-4 第二次翻译效果不佳也可能只是一个运气问题（概率问题）。
