我一直在研究主要使用开源工具创建高质量转录的工作流。最近，当有人询问我们的转录工具栈时，我在推特上分享了这个流程的简要版本。我觉得为可能面临类似挑战的人写一篇更详细的帖子可能会有帮助。通过掌控整个工具栈并利用开源大型语言模型（LLM）和开源转录模型，我们实现了令自己非常满意的定制化程度和准确性。而且我认为在这种情况下，完全掌控流程并使用开源工具实际上证明比依赖现成的付费商业解决方案更优。#问题 开源语音转文本模型已经取得了惊人的进展。它们速度快、成本效益高（免费！），对于基本转录通常也很准确。然而，当你需要出版级质量的转录时，你很快就会开始注意到一些问题：1. 专有名词识别；2. 标点准确性；3. 拼写一致性；4. 可读性的格式设置。当你为公众发布转录时，这一点尤其重要。例如，我们负责一个热门播客（每周约5万次下载）的制作，并且我们会发布该播客的转录（以及其他内容），我们需要确保准确性。所以……#解决方案：100%自动化、开源的工作流 我们开发了一个由LLM和转录模型驱动的全自动工作流。我会尝试简要写下它。以下是其工作原理：1. 初始转录 * 使用最新的开源模型whisper - turbo进行第一轮转录。 * 我们在本地运行它。你会得到一个原始转录。 * 有很多很棒的开源库你可以直接插入使用（如whisperx等）。2. 名词提取 * 这一步很重要。基本上上面的原始转录很可能会有名词和特殊（技术）术语错误。你需要纠正它。但在此之前你需要收集这些特殊单词，怎么做呢？ * 使用开源LLM（如Outlines）的结构化API响应从主文档中提取名词列表。如果你不想在这里使用开源工具，几乎所有商业API也提供结构化API响应。你也可以使用它们。 * 在我们的案例中，对于我们的播客，我们为每一集维护一个主文档，基本上就像一个脚本（用于不同用途），其中包含所有专有名词、特殊技术术语等。我们如何提取呢？ * 我们只需将其简单地放入一个LLM（带有结构化生成）中，它就会返回我们需要关注的特殊单词的正确数组列表。 * 提示：“从这段文本中提取所有专有名词、技术术语和重要概念。以JSON列表形式返回。”带有结构生成。类似这样……3. 转录校正 * 将初始转录和提取的名词列表提供给你的LLM。 * 提示：“校正这个转录，特别注意提供列表中的专有名词和术语。确保标点和格式正确。”（这不是真正的提示，但你能明白意思……） * 输入：原始转录 + 名词列表 * 输出：清理后的转录。4. 说话人识别 * 使用pyannote.audio（开源！）进行说话人分割。 * 额外操作：提示你的LLM根据上下文将说话人标签映射到实际姓名。5. 最终格式化 * 使用一个简单的脚本来将转录格式化为你想要的输出（例如，Markdown、HTML - > 如果需要的话带有说话人标签和时间）。然后直接发布。#为什么这种方法更优 1. 完全掌控：通过掌控工具栈，我们可以定制流程的每一步。2. 灵活性：我们可以轻松添加像在转录中突出显示提到的书籍或论文这样的功能。3. 成本效益：初始设置后，运行成本极低 - > 基本上就是GPU托管或电费成本。4. 持续改进：我们可以针对我们的特定内容微调模型以随着时间推移提高准确性。#未来增强 我们计划添加对播客中提到的书籍和论文的自动突出显示功能。凭借我们的开源工具栈，实现这样的功能很简单，不需要等待API提供商提供新功能。我们可以简单地在上述步骤中插入一个LLM来做我们想做的事情。我们实际上最初使用的是商业解决方案，但对我们来说，使用封闭的解决方案感觉太受限且太慢了。构建我们自己的工作流真是太棒了。#结论 这个100%自动化的工作流在最少的人工干预下持续生成高质量的转录。根据我们的经验，它的准确率约为98% - 我们有时仍然会手动检查。特别是，当说话人相互交叉说话时，我们注意到分割仍然不完美。所以我们手动纠正它。而且，目前我们仍然在高层次上检查转录 - 2%的人工工作就来自于此。我们的目标是弥补最后2%的准确性。好的，这就是我的思路整理。希望结构足够清晰能让人理解。如果有人有后续问题，请告诉我，很乐意回答。我很想知道是否有人尝试过类似的方法或有改进的建议。如果有问题或需要讨论的事情，最好在这个帖子下写评论，这样其他人可以受益并参与讨论。但如果你想私下联系我，也可以随时联系，最好的联系地点在下面。干杯，阿迪 [领英](https://www.linkedin.com/in/adithyan - ai/)，推特，邮箱：[email protected]
讨论总结
原帖作者分享了使用开源工具创建高质量转录工作流的经验，包含多个步骤及这样做的优势。评论者主要针对工作流相关内容展开讨论，如请求演示以便尝试、询问工作流中特定工具的使用原因、探讨优化方式、对工作流表示认可与感兴趣、进行技术对比等，整体氛围积极，大家都在探索工作流相关的知识与技术。
主要观点
- 👍 原帖的工作流很有吸引力，但教程缺乏可操作性
- 支持理由：评论者表示感兴趣，但原帖仅提供思路，没有足够资源用于尝试。
- 反对声音：无。
- 🔥 对原工作流中使用“whisper - turbo”提出疑问并得到解答
- 正方观点：使用“whisper - turbo”是因为未损失准确性且速度更快。
- 反方观点：无，但有人认为V2版本更准确。
- 💡 微调Whisper初步测试效果不好，文本到文本操作应使用LLM
- 支持理由：微调存在标记长度和性能问题，LLM在文本到文本操作更擅长。
- 反对声音：无。
- 🌟 原帖工作流程很棒且有很多可借鉴之处
- 支持理由：可用于帮助参加长会议的人，有很多值得学习的地方。
- 反对声音：无。
- 🤔 原工作流与whisperX存在差异且有whisper - x自身的局限
- 正方观点：原工作流第一步使用whisper - x，但存在名词和标点出错问题，会结合LLMs处理。
- 反方观点：无。
金句与有趣评论
- “😂 Wow, I like the sound of this.”
- 亮点：简洁表达对原帖工作流的兴趣。
- “🤔 The tutorial gives the idea, but not enough to actually try it.”
- 亮点：指出原帖教程的不足。
- “👀 We used V3 before and we simply switched to Turbo (one line change) when it was released. We found no loss in accuracy in our case (primarily English) and it’s much faster. So turbo.”
- 亮点：详细解释了切换到“whisper - turbo”的原因。
- “💡 We publish transcripts for every episode, so the noun list changes for every episode in the podcast.”
- 亮点：解答关于名词列表稳定性的疑问。
- “👍 Great workflow.”
- 亮点：直接对原帖工作流程表示认可。
情感分析
总体情感倾向是积极的，大部分评论者对原帖分享的工作流表示认可、感兴趣或者提出建设性的疑问。主要分歧点在于工具版本的准确性比较，如“whisper - turbo”与其他版本的比较，可能的原因是不同的使用场景和数据会导致对工具准确性的不同感受。
趋势与预测
- 新兴话题：可能会有更多关于优化这个工作流的讨论，如结合评论中推荐的CrisperWhisper等项目进行改进。
- 潜在影响：如果原帖作者开源相关代码或者制作更多可用于尝试的资源，可能会推动更多人在音频转录领域使用开源工具构建类似工作流。
详细内容：
《利用开源工具打造高质量转录本的创新方法引发Reddit热议》
近日，Reddit上一篇关于使用开源工具创建高质量转录本的帖子引发了广泛关注。该帖子获得了众多点赞和大量评论。
原帖作者分享了自己在打造高质量转录本工作流程方面的经验。作者指出，通过拥有整个工作流程并利用开源的LLMs和转录模型，实现了高度的定制化和准确性，并且认为在这种情况下，完全掌控流程并使用开源工具优于依赖现成的商业付费解决方案。
讨论的焦点主要集中在以下几个方面： 有人对作者使用的Turbo模型表示好奇，询问为何选择它。有用户表示曾使用过不同版本的Whisper模型，并分享了使用体验。还有人关注名词提取和说话者识别的具体实现方式，以及是否进行了音频预处理等。有人好奇这套流程与其他类似项目的差异和优势。另外，关于模型的微调以及处理音频的时间等问题也引发了热烈讨论。
比如，有用户分享道：“我们使用V3之前，Turbo一发布我们就切换了（仅一行代码更改），在我们的案例中（主要是英语）没有发现准确性的损失，而且速度快得多。所以选择了Turbo。”
在讨论中，存在一些争议点。比如对于不同版本Whisper模型准确性的看法存在分歧，有人认为V2比V3更准确，而作者的体验则有所不同。但也有一些共识，大家普遍认可作者分享的工作流程具有一定的创新性和参考价值。
特别有见地的观点是作者关于保持语音转文本和文本处理环节的抽象性，以便灵活切换不同模型的看法。
未来，作者计划为播客添加自动突出提到的书籍和论文的功能。相信随着更多的交流和实践，这套开源工作流程会不断完善和优化。
总之，这次关于开源转录本工作流程的讨论为相关领域的探索提供了丰富的思路和经验。
感谢您的耐心阅读！来选个表情，或者留个评论吧！