个人报告#

在此次深度学习大作业中，我深切感受到了网络环境、训练数据以及计算资源的多重“摧残”。先不说网络环境的种种问题，单是在寻找训练数据和资源时，就已经感到极其繁琐。深度学习的训练需要大量标注数据，而数据标注本身就是一项费时费力的工作。因此，我们只能选择公开的数据集。按深度学习常见的输入格式划分，数据通常包括图像、文本和音频三种类型。实际上，它们在向量空间中都可以统一表达，但在处理方式上仍有显著差异。

我们决定跳过图像和文本领域，因为这两个方向的应用相对成熟，而音频方向的实际案例较少且挑战性更大。于是，我们在 GitHub 上搜索与 voice deep-learning 相关的项目，找到了几个热门的声音克隆项目，如 fish、GPT-SoVITS 和 MockingBird。由于我们希望实现一个判断声音是否为克隆生成的模型，因此需要先使用这些项目克隆出音频数据。

首先，这些声音克隆项目在 Linux 系统上的部署普遍较为复杂。不过值得一提的是，大多数国人开发者都会准备 Windows 的一键整合包（大概率是考虑到网络环境或方便小白用户）。但对于我们来说，这种整合包不适用，因为我们需要能够提供 API 的项目，以便通过批量调用 API 来生成克隆音频。然而，在仔细阅读多个项目的 README 文件后，我们惊讶地发现，几乎所有项目都没有提到如何通过 API 使用这些工具。

这一点让人十分头疼。尽管项目的整体复杂性较高，但提供一个简单的 API 接口本应该是常见需求。然而，我们在文档中一无所获，最后不得不通过查阅 GPT-SoVITS 的 issue 页面才找到相关说明。坦白说，我完全不理解为什么这些关键信息不直接写进 README 中。

这一步解决后，新的问题接踵而至：程序调用时不支持异步和多线程。按照程序现状测算，完整克隆所有音频数据大约需要 60 小时。起初我们也无计可施，但后来想到可以通过在同一台机器上多开几个 API 调用实例，并在文件生成时增加“是否已存在”的判断逻辑，从而加速数据生成。这一调整让我们节省了不少时间。

可是运行程序所需的训练资源太大，显存需要18G，内存30多G，将我们训练数据上传到服务器，耗费了大量的时间，在服务器上安装环境又有网络因素从本地下载后再上传上去，总时长四个多小时。不等上传完，什么也不能干，但是这个是没办法改变的，带宽就这么大。与此同时，在服务器上安装训练环境又因网络原因问题频出，无法直接从官方源获取依赖，不得不选择从本地打包后再上传。整个过程耗时冗长且无法并行进行，导致项目的时间大部分浪费在数据传输和环境配置上，而代码实现和参数调优的时间相对较少。（提一句，linux nohup命令跟踪log挺好用的，可以实时看训练日志极大地方便了模型的调试和监控）

克隆出来音频后又发现了问题，有大量音频是0s的，也就是没有音频数据，对于这些情况，只能归咎于模型api问题，可能是流数据传输问题。我们用的是迁移学习，需要从huggingface上拉取模型，不知道为什么我们本地下载完后传到服务器上根据官方文档引用不能使用，没办法，从服务器上也不能直接连huggingface。好在，国内有个镜像https://hf-mirror.com/ 使用了这个后成功拉取下来了模型，又是一个网络环境问题。后面开始训练后就还一切顺利了，只需等待训练完成看看准确率就好了，一开始我们想的是搭建前后端分离带数据库的应用项目的，时间有限，就用Gradio几十行命令搭建出来界面了。对于应用，当然是部署到公网上才算酷，只能内网本地访问也太不行了。我们就利用本地服务器然后使用frp进行穿透，再配置域名成功部署到公网上。

我们从一开始便没对模型的最终效果抱有太高的期望，因为在项目初期，当我们用克隆出来的音频进行试听时，发现这些音频的质量实在是太好了——它们和原声几乎一模一样，甚至让人完全听不出来是克隆出来的。这种初步的直观感受让我们对任务的难度有了更清晰的认知：如果人耳都无法分辨，那么依靠机器学习来判断，会有胜算吗？

不过，正如一句玩笑所说的那样，“深度学习虽然不可理解，但总是能带来惊喜。”这句话在我们项目中得到了充分体现。我们用深度学习训练模型来判断是否是深度学习生成的数据，这种“自我较劲”的做法乍一听似乎有点矛盾，但恰恰展示了深度学习技术的强大之处。最终，尽管模型在一些方面的表现并不完美（例如仍存在一定误判），但它的整体效果已经远超我们的初衷。通过对克隆音频的训练和测试，模型能够捕捉到一些人耳无法察觉的细微特征，准确区分克隆音频与真实音频。这一点正是深度学习的魅力所在：它可以从海量数据中学习到人类难以显式描述的规律，并将其转化为具体的判断能力。

这个项目算什么？如果从学术意义上来说，这个项目可以被归类为 生成对抗与检测 的研究领域。近年来，生成模型（如 GAN 和 VAE）以及音频克隆技术的快速发展，让合成数据的质量越来越高。然而，与此同时，检测这些数据的真实性也变得越来越重要，特别是在一些需要高可信度的应用场景中（如语音识别、法律取证等）。因此，我们的项目其实是站在了这类研究的边缘：试图用深度学习来对抗深度学习，用 AI 来识别 AI。

更广泛地看，这也是当下 AI 技术发展的一个趋势——生成与检测的对抗赛。生成模型在不断提升合成数据的质量，而检测模型也在不断进化，以便更好地区分真伪。我们的项目虽然规模不大，但也算是这一趋势的一个微小实践。

以下是本次项目的总结与反思#

1、时间分配上的反思

从整个项目来看，数据准备和模型部署耗费了我们大部分时间，而代码实现和模型调参的时间相对较少。这与我们最初的时间规划有所偏差。如果能在项目开始时更合理地安排任务（如提前下载模型和数据集，或利用网速更快的服务器），可能会提升整体效率。

2、网络环境的限制

项目过程中，网络问题成为一个反复出现的瓶颈。不论是数据上传、环境安装还是模型下载，都受到带宽限制。建议以后可以提前缓存所需的依赖和数据，或者选择国内的开源镜像（如 TUNA 和上文提到的 Hugging Face 国内镜像）。

3、对深度学习工具链的依赖

现代深度学习的工具链非常丰富，但很多工具的文档仍然不够友好。特别是对于音频领域的项目，API 的使用方式和代码示例非常有限，这导致了我们在初期花费大量时间摸索。未来，希望更多项目可以注重文档的完善性，减少学习和使用成本。

总体来说，这次深度学习大作业让我深刻感受到了深度学习项目的复杂性。从数据准备、模型部署到训练优化，每一步都充满挑战，但也收获了许多宝贵的经验。