用 Whisper 与 Pyannote 构建多人转写

把一段巴西葡萄牙语（PT-BR）采访转成文字，难点不只是识别单词，还包括方言、口语、多人插话，以及 WhatsApp 低码率语音。Transcreva 团队给出的方案，是把 Whisper Large-v3 的转写、Pyannote 的说话人分离和字幕导出串成流水线，再通过 MCP 接入编程助手。

这篇值得看的地方是任务拆分：识别内容、判断谁在说、整理成可交付文件，各有一层负责。不过，作者没有给出准确率、处理耗时或对照实验，产品效果还需要验证。

识别出文字之后，为什么还要判断谁在说

作者用一段 45 分钟的播客或学术访谈说明问题：即使语音识别正确，堆成一整块文字也很难阅读。对话稿需要说话人标签和时间信息。

他们把处理分成两步：

• Whisper Large-v3 负责自动语音识别（ASR），生成葡萄牙语及多语言文本片段，并提供词级时间对齐。
• Pyannote 在滑动窗口中计算说话人嵌入，也就是用于比较声音特征的向量，再聚类得到说话人轮次，把 Whisper 的单词时间戳对应到活跃的说话人簇。

转写回答「说了什么」，说话人分离回答「哪一段是谁说的」。

这里的 Speaker 1、Speaker 2 是聚类标签，不代表系统已经知道人物姓名。原文也没有解释两个人同时说话时，单词如何分配，或说话人数量如何确定。

下面这段代码定义了转写片段的数据结构，并把秒数转换成 SRT 时间格式：

interface TranscriptSegment {
  id: string;
  speaker: string; // 例如 "Speaker 1"
  startTime: number; // 秒
  endTime: number;
  text: string;
}

export function formatSrtTimestamp(seconds: number): string {
  const hrs = Math.floor(seconds / 3600);
  const mins = Math.floor((seconds % 3600) / 60);
  const secs = Math.floor(seconds % 60);
  const ms = Math.round((seconds % 1) * 1000);
  return `${String(hrs).padStart(2, "0")}:${String(mins).padStart(2, "0")}:${String(secs).padStart(2, "0")},${String(ms).padStart(3, "0")}`;
}

要留意 Math.round((seconds % 1) * 1000)：毫秒可能舍入到 1000，代码却没有向秒进位。它适合说明格式，直接用于生产还要处理边界值。

文件能转写，还得能交付和调用

作者重点覆盖两类输入输出。

第一类是 WhatsApp 导出的 .opus / .ogg 语音，使用 Opus 编码。团队的工作流会在处理时归一化采样率，输出段落或带说话人标签的对话稿。原文没有给出目标采样率、降噪方法，以及低码率录音的识别结果。

第二类是视频字幕。流水线使用 Whisper Large-v3 的词级时间戳，按每秒字符数（CPS）控制阅读速度、切分字幕行，导出 .srt 和 .vtt，面向 YouTube、Reels、TikTok 等剪辑场景。

CPS 解决的是字幕来不来得及读，时间戳解决的是字幕何时出现。两者需要配合，但不能直接证明字幕已经达到作者所说的帧级准确。

团队还提供了开源 MCP 服务 transcreva-mcp，让 Cursor、Claude Desktop、Windsurf 等助手调用转写工作流。配置如下：

{
  "mcpServers": {
    "transcreva": {
      "command": "npx",
      "args": ["-y", "transcreva-mcp"]
    }
  }
}

关键是 command 和 args：客户端通过 npx -y transcreva-mcp 启动服务。原文没有展示工具清单、鉴权方式、任务提交参数或结果返回结构，因此这份配置还不足以说明完整接入过程。

我的判断

这套拆分有道理。相比只输出整段文字的语音识别流程，它把对话阅读、字幕交付和助手调用都纳入了设计，适合采访、播客和视频内容处理。

但作者提供的是架构描述和代码片段，没有可核对的实测数据。「高准确率」「快速」以及对 PT-BR 地域口音、重叠语音的适应能力，都不能仅凭模型组合得到确认。文中也没有明确的葡萄牙语专项优化步骤。

采用 Whisper Large-v3 和 Pyannote，是一项技术选型，还不是效果证明。

普通团队还需要评估增加说话人分离后的计算成本与错误率。单人语音可能不需要这一层；多人采访则应分别检查转写错误和说话人归属错误。MCP 的价值在于方便助手调用，不能提升底层音频识别质量。

能拿来做什么

• 做采访或播客整理工具时，可以采用 TranscriptSegment 这样的统一结构，让前端按说话人展示文本，并用起止时间关联音频跳转；接入前先验证人物标签是否稳定。
• 做字幕导出时，把时间格式化和 CPS 分行分别处理，并补上接近整秒时的进位检查。不要把拿到词级时间戳当作字幕已经可直接交付。
• 想在日常 AI 工作流中处理录音，可以尝试原文的 MCP 配置，再核对服务实际提供的工具、鉴权和文件传输方式。原文未交代这些接口细节，不能据此假定接入后就能完成整套操作。