Amazon Transcribe企业级语音识别实战：从ASR到业务数据流

1. 项目概述：这不是一个“语音转文字”的简单工具，而是一套可嵌入业务流程的语音智能中枢

Amazon Transcribe 是 AWS 推出的全托管式自动语音识别（ASR）服务，它不依赖你自建模型、不操心 GPU 集群调度、不处理音频预处理流水线——你只需把一段音频或实时流推过去，它就返回结构化、带时间戳、可搜索、可编辑的文字结果。我第一次在客户现场用它替换掉某国产语音 SDK 时，最震撼的不是准确率提升 12%，而是整个语音处理模块的运维成本从每月 3 人日骤降到近乎零。它真正解决的，从来不是“能不能转文字”，而是“如何让语音数据像文本一样被系统原生消费”。比如客服录音分析，传统方案要先转成 WAV，再调用本地 ASR，再清洗标点，再存进 Elasticsearch；而 Transcribe 一条 API 就完成音频上传→语音识别→标点恢复→说话人分离→关键词高亮→JSON 输出→自动存入 S3，全程无须人工干预。它面向的不是开发者，而是业务架构师、合规负责人、客户体验总监——因为它的输出天然适配 GDPR 数据脱敏、PCI-DSS 录音归档、ISO 9001 服务过程留痕等真实企业级需求。核心关键词 Amazon Transcribe、语音识别、ASR、实时转录、说话人分离、自定义词汇表、医疗/金融行业适配，全部不是功能罗列，而是业务能力接口。如果你还在用 Python 调用开源模型跑 batch 转录，或者靠外包团队人工听写千条通话录音，那这个服务不是“可选”，而是你技术栈里缺失的那块关键拼图。

2. 整体设计与思路拆解：为什么 AWS 不做“更准的模型”，而专注“更稳的管道”

2.1 架构本质：从“模型即服务”到“语音数据流操作系统”

很多人误以为 Transcribe 的核心竞争力是声学模型有多深，其实恰恰相反——它的底层模型（基于 Transformer 的端到端 ASR）在纯学术 benchmark 上，并不比 Whisper-large-v3 或 Google’s Speech-to-Text v2 高出一个数量级。它的真正壁垒在于将语音识别彻底解耦为可编排的数据流环节。整个服务不是“一个黑盒API”，而是由五个原子能力层构成的管道：

1. 接入层（Ingestion Layer）：支持 HTTP POST 上传文件（MP3/WAV/FLAC 最大 2GB）、Kinesis Video Stream 实时流、S3 事件触发（如新录音自动转录）；
2. 预处理层（Preprocessing Layer）：自动降噪、采样率归一化（16kHz）、静音段裁剪、双声道分离（左/右声道独立识别）；
3. 识别层（Recognition Layer）：核心 ASR 引擎，支持多语言混合识别（如中英夹杂会议）、自定义发音词典（“AWS Lambda” 读作 /æwɛs ˈlæmdə/ 而非 /ˈæməzɒn/）、专业术语增强（医疗名词“bradycardia” 识别率从 68% 提升至 94%）；
4. 后处理层（Postprocessing Layer）：自动添加标点（句号/问号/感叹号）、大小写恢复（“apple” → “Apple”）、说话人分离（Speaker Diarization，区分 A/B/C 多人对话）、敏感词模糊（“身份证号” → “ID***”）；
5. 交付层（Delivery Layer）：输出 JSON 格式结果（含每个词的时间戳、置信度、说话人 ID），自动存入指定 S3 桶，触发 Lambda 进行后续分析（如情绪识别、合规关键词告警）。

这种分层设计意味着：当你的业务需要“仅提取客服话术中的产品名”，你不需要重训模型，只需在交付层加一个 Lambda 函数，用正则匹配{"word": "iPhone", "start_time": 12.3}；当监管要求“所有通话必须保留原始音频+文字+时间戳三者哈希值”，你也不用改识别逻辑，直接在交付层调用 KMS 加密 S3 对象并生成 SHA256 校验码。这才是它区别于其他 ASR 服务的本质——它不卖“识别能力”，它卖“语音数据的可控性”。

2.2 方案选型逻辑：为什么放弃自建 Whisper + FastAPI，选择全托管 Transcribe

2023 年底，我们为一家保险集团搭建理赔电话分析系统，面临两个技术路径：

• 路径 A（自建）：部署 Whisper-large-v3 模型在 EC2 p3.2xlarge 实例上，用 FastAPI 封装 REST 接口，前端上传 MP3 后异步轮询结果；
• 路径 B（托管）：Transcribe 直接对接 S3 事件，录音存入 s3://claims-audio/ 后自动触发转录，结果写入 s3://claims-transcript/。

我们最终选 B，决策依据不是成本（B 比 A 贵 17%），而是三个不可量化的风险点：

提示：自建方案在以下场景会暴露致命短板

• 突发流量洪峰：月底集中提交 5000 通录音，自建服务需手动扩容实例、调整负载均衡权重、监控 GPU 显存溢出，而 Transcribe 自动弹性伸缩，峰值 QPS 从 100 瞬间拉到 2000 无感知；
• 模型漂移维护：方言口音（如粤语+潮汕话混合）识别率下降，自建需重新收集语料、微调模型、AB 测试，Transcribe 只需启用“领域自适应”开关并上传 200 条标注样本，2 小时内生效；
• 合规审计盲区：监管检查要求提供“从录音上传到文字输出的完整链路日志”，自建需在 Nginx、FastAPI、Whisper 日志中交叉关联 trace_id，Transcribe 原生提供 CloudTrail 日志，每条请求含 request_id、source_s3_uri、output_s3_uri、duration_ms、error_code，审计报告一键生成。

实测下来，路径 B 的上线周期从预估 6 周压缩到 3 天——第一天配置 S3 事件通知，第二天写 Lambda 处理 JSON 结果，第三天联调测试。而路径 A 在第四周才解决 CUDA 版本兼容问题。这印证了一个经验：当你的核心价值不在 ASR 模型本身，而在语音数据如何驱动业务决策时，“省心”就是最高 ROI。

2.3 场景适配哲学：不是“通用识别”，而是“为特定业务长出的语音器官”

Transcribe 的功能列表看似平庸（实时/批量、多语言、说话人分离），但它的真正威力在于按行业场景预埋了“业务语义钩子”。以金融行业为例：

• 信贷面谈场景：要求识别“年化利率”“LPR”“抵押物评估价”等术语，且需 100% 区分客户陈述与客户经理复述。Transcribe 的“自定义词汇表”支持上传 CSV 文件，其中一列写term,literal_pronunciation,weight，例如LPR,"el pee ar",10（weight 越高，模型越倾向识别为该词）；
• 反洗钱监控场景：需实时检测“现金交易”“境外汇款”“虚拟货币”等高危关键词。Transcribe 的“敏感词过滤”功能可在识别过程中标记这些词，并在 JSON 输出中增加"is_sensitive": true字段；
• 监管报送场景：银保监要求通话记录保存满 5 年，且文字稿需与原始音频哈希值绑定。Transcribe 的 S3 输出天然支持对象版本控制和 S3 Object Lock，配合 Lifecycle Policy 自动设置 5 年保留期。

再看医疗场景：医生口述病历常含拉丁文术语（如 “tachycardia”）、缩写（“SOB”=shortness of breath）、数字单位混用（“150 mg/dL”）。Transcribe 的“医疗领域模型”（需显式启用）针对这些做了专项优化——它不是简单增加词表，而是重构了声学模型的输出层，将 “SOB” 解析为 “shortness of breath” 而非 “ess oh bee”，将 “150 mg/dL” 识别为带单位的数值实体，便于后续 EHR 系统直接提取结构化字段。这种深度场景耦合，是通用 ASR 模型永远无法通过 fine-tuning 达成的，因为它需要 AWS 与 Mayo Clinic、Johns Hopkins 等机构长达数年的临床语料合作。所以，当你评估是否采用 Transcribe，别问“它准不准”，而要问：“我的业务里，哪些语音片段一旦识别错误，会导致合规风险、客户投诉或财务损失？”——答案指向的，就是它最该发力的地方。

3. 核心细节解析与实操要点：那些文档里不会写的参数陷阱与配置心法

3.1 音频输入规范：为什么 8kHz 电话录音比 44.1kHz 音乐更难识别

Transcribe 官方文档写着“支持 8kHz–48kHz 采样率”，但实际项目中，我们发现 8kHz 的 PSTN 电话录音识别错误率比 16kHz 录音高 3.2 倍。原因在于：低采样率音频丢失了辅音高频成分（如 /s/ /f/ /th/），而 Transcribe 的声学模型训练数据中，8kHz 样本占比不足 5%。解决方案不是强行升频（插值毫无意义），而是启用“电话音频优化模式”：

aws transcribe start-transcription-job \ --transcription-job-name "call-20240501" \ --language-code "zh-CN" \ --media MediaFileUri="s3://my-bucket/calls/20240501.wav" \ --media-format wav \ --settings '{"ChannelIdentification":false,"ShowSpeakerLabels":true,"MaxSpeakerLabels":2,"VocabularyName":"finance-vocab","LanguageModelName":"telephone-zh"}'

关键参数LanguageModelName必须设为telephone-zh（中文）或telephone-en-US（英文），这是 AWS 针对窄带语音单独训练的轻量模型，它牺牲了音乐/播客场景的泛化能力，换取电话场景下 /sh/ /ch/ /zh/ 等音素的识别鲁棒性。实测显示，在客服通话中，“是的”（shì de）被误识为“似的”（shì de）的概率从 22% 降至 3.7%。注意：此参数仅对批量转录有效，实时流（StartStreamTranscription）需在客户端 SDK 中设置languageModelName: 'telephone-en-US'。

注意：不要迷信“更高采样率更好”。我们曾用 Audacity 将 8kHz 通话升频至 44.1kHz 再提交，结果识别率反而下降 8%——因为升频引入的伪高频噪声干扰了模型注意力机制。正确做法是保持原始采样率，仅启用对应领域的语言模型。

3.2 说话人分离（Speaker Diarization）：不是“分几个人”，而是“谁在什么时间说了什么”

很多用户开启ShowSpeakerLabels: true后，发现输出 JSON 中 speaker_label 字段是spk_0,spk_1，误以为这就是“客户 vs 客服”。错。Transcribe 的说话人分离本质是声纹聚类（speaker clustering），它只保证同一 label 下的语音段来自同一声源，但不保证 label 与角色一一对应。例如一次三方通话（客户、客服、主管），可能聚类出spk_0（客户 70% + 主管 30%）、spk_1（客服 100%）、spk_2（主管 70% + 客户 30%），因为主管和客户声纹相似（同地域口音）。

要实现真正的角色绑定，必须结合业务上下文做二次映射。我们的标准做法是：

1. 在呼叫中心系统中，通话开始时通过 CTI 接口获取caller_id（客户号码）和agent_id（客服工号）；
2. 将这两个 ID 作为元数据，随音频一起存入 S3，文件名格式为s3://calls/{caller_id}_{agent_id}_{timestamp}.wav；
3. 在 Transcribe 输出的 JSON 中，提取spk_0和spk_1的首句文本（通常含自我介绍，如“您好，我是工号 12345”）；
4. 用正则匹配工号 (\d+)，将匹配到的工号与agent_id关联，从而确定spk_1= 客服，剩余spk_0= 客户。

这样做的好处是：即使客户和客服都姓“张”，声纹聚类失败，也能通过业务标识精准归因。我们在某银行项目中，将角色识别准确率从 81% 提升至 99.4%。记住：说话人分离是技术手段，角色识别是业务逻辑，二者必须分层解耦。

3.3 自定义词汇表（Custom Vocabulary）：不是“加词”，而是“重写发音规则”

官方文档说“上传 CSV 文件，每行一个词”，但实际效果远不止于此。CSV 格式支持三列：phrase, pronunciation, weight。其中pronunciation不是拼音，而是CMU Pronouncing Dictionary 格式（如 “AWS” → “AH W E S”）。我们曾为某云服务商客户配置 “Lambda” 一词：

• 错误写法：Lambda,lan-ma-da,10（拼音式，Transcribe 忽略）
• 正确写法：Lambda,L AE M D AH,10（CMU 音标，AE 表示 /æ/，AH 表示 /ə/）

更关键的是weight参数：它不是“权重越高越优先”，而是影响模型 softmax 输出层的 logits 缩放系数。当weight=10，模型对 “Lambda” 的预测概率会被指数级放大，即使声学特征更接近 “Lambada”（一种舞蹈），也会强制输出 “Lambda”。我们在测试中发现，weight设为 5 时，专业术语识别率提升 15%；设为 15 时，提升 28%，但开始出现“过度矫正”（把 “lamp” 也识别为 “Lambda”）。因此，我们的经验公式是：weight = 5 + (业务关键性 × 5)，其中“业务关键性”按 1~3 分打分（1=普通名词，3=合同条款关键词）。

提示：自定义词汇表有 5000 词上限，但可通过创建多个词汇表（如vocab-finance,vocab-legal）并在不同转录任务中指定，实现无限扩展。切记：词汇表更新后，需等待 15 分钟生效，且仅对新发起的转录任务生效。

3.4 实时流（Real-time Streaming）的延迟与稳定性控制

实时转录（StartStreamTranscription）的标称延迟是 300ms，但实测中，当网络抖动超过 50ms，延迟会飙升至 2s+。根本原因在于：Transcribe 的流式协议基于 HTTP/2，要求客户端严格按 100ms 分片发送音频帧（PCM 格式，16bit，16kHz，单声道）。我们踩过的最大坑是：用 WebRTC 获取麦克风流后，直接MediaRecorder录制为 WAV，再切片发送——WAV 头部导致首帧数据错位，Transcribe 返回BadRequestException。

正确解法是绕过 WAV，用 Web Audio API 直接操作音频缓冲区：

// 获取麦克风流 navigator.mediaDevices.getUserMedia({ audio: true }).then(stream => { const context = new AudioContext(); const source = context.createMediaStreamSource(stream); const processor = context.createScriptProcessor(4096, 1, 1); // 已废弃，但兼容性好 source.connect(processor); processor.connect(context.destination); processor.onaudioprocess = (e) => { const inputData = e.inputBuffer.getChannelData(0); // 单声道 PCM 数据 const int16Data = new Int16Array(inputData.length); for (let i = 0; i < inputData.length; i++) { int16Data[i] = Math.max(-32768, Math.min(32767, inputData[i] * 32767)); } // 将 int16Data 发送给 Transcribe WebSocket sendToTranscribe(int16Data); }; });

关键点：sendToTranscribe()必须确保每 100ms 发送一次 1600 字节（16kHz × 16bit ÷ 8 = 32000 bytes/s → 3200 bytes/100ms，但 Transcribe 要求单帧 ≤ 1600 字节，故每 50ms 发一次）。我们用setTimeout精确控制发送间隔，实测端到端延迟稳定在 320±20ms。另外，务必启用enable_partial_results_stabilization: true，否则部分识别结果（如“今天”）会频繁被刷新为“今...今天...今天天气”，影响前端展示体验。

4. 实操过程与核心环节实现：从零搭建一个客服质检系统

4.1 环境准备与权限配置：最小权限原则下的 IAM 策略设计

在 AWS 控制台创建 Transcribe 服务前，必须配置 IAM 角色。我们绝不使用AmazonTranscribeFullAccess全权限策略，而是按最小权限原则定制：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "transcribe:StartTranscriptionJob", "transcribe:GetTranscriptionJob", "transcribe:ListTranscriptionJobs" ], "Resource": "arn:aws:transcribe:us-east-1:123456789012:transcription-job/*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::customer-calls-audio", "arn:aws:s3:::customer-calls-audio/*" ] }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::customer-calls-transcript", "arn:aws:s3:::customer-calls-transcript/*" ] }, { "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:process-transcript" } ] }

此策略明确限定：

• Transcribe 只能操作transcription-job/*命名空间下的任务；
• 只能读取customer-calls-audio桶的录音，不能列出其他桶；
• 只能向customer-calls-transcript桶写入结果，不能删除；
• 只能调用指定 Lambda 函数，不能创建/删除其他函数。

权限收紧后，即使攻击者获取该角色密钥，也无法横向移动到 EC2 或 RDS。我们在某次红队演练中，验证了该策略成功阻断了所有越权尝试。

4.2 批量转录全流程：S3 事件驱动的自动化流水线

以下是生产环境已验证的完整流程（以客服通话质检为例）：

步骤 1：S3 存储桶配置

• 创建两个桶：s3://customer-calls-audio（存放原始录音）、s3://customer-calls-transcript（存放转录结果）；
• 在audio桶启用事件通知：当*.wav文件上传时，触发 Lambda 函数trigger-transcribe；
• 设置生命周期规则：audio桶中文件 90 天后转为 Glacier 存储，transcript桶中文件永久保留（满足监管要求）。

步骤 2：Lambda 触发函数（trigger-transcribe）

import json import boto3 import os transcribe = boto3.client('transcribe', region_name='us-east-1') def lambda_handler(event, context): for record in event['Records']: bucket = record['s3']['bucket']['name'] key = record['s3']['object']['key'] # 生成唯一任务名（避免重名冲突） job_name = f"qc-{key.replace('.wav', '').replace('/', '-')}-{int(time.time())}" # 启动转录任务 transcribe.start_transcription_job( TranscriptionJobName=job_name, LanguageCode='zh-CN', Media={'MediaFileUri': f's3://{bucket}/{key}'}, OutputBucketName='customer-calls-transcript', Settings={ 'VocabularyName': 'customer-service-vocab', 'ShowSpeakerLabels': True, 'MaxSpeakerLabels': 2, 'ChannelIdentification': False } ) return {'statusCode': 200}

步骤 3：转录结果处理（process-transcript）当 Transcribe 完成任务，会向transcript桶写入{job_name}.json，同时触发此 Lambda：

import json import boto3 import re def lambda_handler(event, context): # 从 S3 读取 JSON 结果 s3 = boto3.client('s3') bucket = event['Records'][0]['s3']['bucket']['name'] key = event['Records'][0]['s3']['object']['key'] response = s3.get_object(Bucket=bucket, Key=key) transcript_data = json.loads(response['Body'].read().decode('utf-8')) # 提取关键信息 results = transcript_data['results'] transcripts = results['transcripts'][0]['transcript'] # 检测违规话术（正则匹配） violations = [] if re.search(r'保证|绝对|肯定', transcripts): violations.append("承诺性话术") if re.search(r'身份证|银行卡号', transcripts): violations.append("敏感信息泄露") # 写入 DynamoDB 质检表 dynamodb = boto3.resource('dynamodb') table = dynamodb.Table('call-quality-report') table.put_item(Item={ 'call_id': key.split('-')[1], # 从文件名提取 'transcript': transcripts[:500] + "...", # 截断存储 'violations': violations, 'created_at': int(time.time()) }) return {'statusCode': 200}

整个流水线无需任何服务器，月均处理 20 万通录音，Lambda 执行费用约 $12，Transcribe 费用约 $850（按 1000 小时音频计费），总成本不足自建方案的 1/5。

4.3 实时转录集成：Web 应用中的低延迟语音交互

为某在线教育平台开发“实时课堂字幕”，要求教师语音 500ms 内显示字幕。我们采用以下架构：

前端（React）

// 使用 @aws-sdk/client-transcribe-streaming import { TranscribeStreamingClient, StartStreamTranscriptionCommand } from "@aws-sdk/client-transcribe-streaming"; const client = new TranscribeStreamingClient({ region: "us-east-1", credentials: { accessKeyId: "YOUR_ACCESS_KEY", secretAccessKey: "YOUR_SECRET_KEY" } }); const command = new StartStreamTranscriptionCommand({ LanguageCode: "zh-CN", MediaSampleRateHertz: 16000, MediaEncoding: "pcm", SessionId: "session-" + Date.now(), EnablePartialResultsStabilization: true, PartialResultsStabilizationMode: "high" }); const response = await client.send(command); const stream = response.TranscriptResultStream; stream.on("data", (event) => { if (event.TranscriptEvent) { const transcript = event.TranscriptEvent.Transcript; // 更新 React state 显示字幕 setSubtitle(transcript); } });

后端（Node.js）为避免前端硬编码 AKSK，我们用 API Gateway + Lambda 生成临时凭证：

// Lambda 函数 generate-temp-creds import { STSClient, GetFederationTokenCommand } from "@aws-sdk/client-sts"; export const handler = async (event) => { const sts = new STSClient({ region: "us-east-1" }); const command = new GetFederationTokenCommand({ Name: "web-client", Policy: JSON.stringify({ Version: "2012-10-17", Statement: [{ Effect: "Allow", Action: ["transcribe:StartStreamTranscription"], Resource: "*" }] }), DurationSeconds: 3600 }); const response = await sts.send(command); return { statusCode: 200, body: JSON.stringify({ Credentials: response.Credentials, SessionToken: response.Credentials.SessionToken }) }; };

此方案将前端凭证有效期控制在 1 小时，且权限精确到StartStreamTranscription单一动作，杜绝了长期密钥泄露风险。实测在 4G 网络下，端到端延迟 420ms，字幕刷新无卡顿。

4.4 行业适配实战：医疗问诊记录的结构化提取

某三甲医院要求将医生口述的门诊记录，自动提取为结构化 JSON，供 HIMS 系统调用。Transcribe 本身不提供结构化输出，但我们通过组合能力实现：

输入音频：医生口述 “患者张三，男，45岁，主诉头痛三天，血压140/90，诊断为紧张性头痛，开具布洛芬缓释胶囊，每日两次，每次一片。”

Transcribe 输出 JSON 片段：

{ "results": { "transcripts": [{"transcript": "患者张三，男，45岁，主诉头痛三天，血压140/90，诊断为紧张性头痛，开具布洛芬缓释胶囊，每日两次，每次一片。"}], "items": [ {"start_time": "0.2", "end_time": "1.5", "type": "pronunciation", "alternatives": [{"content": "患者"}]}, {"start_time": "1.5", "end_time": "2.1", "type": "pronunciation", "alternatives": [{"content": "张三"}]}, ... ] } }

Lambda 后处理逻辑：

# 使用 spaCy 医疗 NER 模型（zh_core_medical_sm） import spacy nlp = spacy.load("zh_core_medical_sm") def extract_medical_entities(text): doc = nlp(text) result = { "patient_name": "", "age": "", "symptom": [], "vital_sign": [], "diagnosis": [], "medication": [] } for ent in doc.ents: if ent.label_ == "PERSON": result["patient_name"] = ent.text elif ent.label_ == "AGE": result["age"] = ent.text elif ent.label_ == "SYMPTOM": result["symptom"].append(ent.text) elif ent.label_ == "VITAL_SIGN": result["vital_sign"].append(ent.text) elif ent.label_ == "DIAGNOSIS": result["diagnosis"].append(ent.text) elif ent.label_ == "MEDICATION": result["medication"].append(ent.text) return result # 调用示例 text = "患者张三，男，45岁，主诉头痛三天..." structured = extract_medical_entities(text) # 输出：{"patient_name": "张三", "age": "45岁", "symptom": ["头痛"], ...}

此方案将 Transcribe 的语音识别能力与专业 NER 模型解耦，既利用了 AWS 的高可用 ASR，又保留了医疗语义理解的自主可控性。我们在试点科室，将结构化提取准确率从人工录入的 92% 提升至 98.7%，医生确认时间减少 65%。

5. 常见问题与排查技巧实录：那些凌晨三点救了项目的真经验

5.1 问题速查表：高频故障现象、根因与修复命令

5.2 独家避坑技巧：来自 127 个生产事故的血泪总结

技巧 1：用 S3 Inventory 替代 ListObjects，规避海量文件扫描超时
当customer-calls-audio桶有 50 万+ 录音时，Lambda 触发函数若用s3.list_objects_v2()扫描新文件，会因分页过多导致超时。正确做法是：启用 S3 Inventory（每天生成 CSV 清单到指定桶），Lambda 改为监听 Inventory 清单生成事件，再解析 CSV 获取新增文件列表。实测处理 100 万文件耗时从 47 分钟降至 3.2 分钟。

技巧 2：Transcribe 任务名长度限制是 200 字符，但 S3 对象键名支持 1024 字符
我们曾用完整路径s3://calls/2024/05/01/123456789012345678901234567890.wav作为任务名，触发ValidationException。解决方案：任务名截取为call-12345678901234567890-20240501（前缀+关键 ID+日期），既保证唯一性，又符合长度限制。

技巧 3：批量转录的MediaFormat参数必须与文件扩展名严格一致
即使 WAV 文件实际是 MP3 编码，若扩展名为.wav，就必须设--media-format wav。Transcribe 不校验文件头，只认扩展名。我们曾因运维脚本错误将.mp3文件重命名为.wav，导致全部转录失败，错误日志只显示Unsupported media format，排查耗时 8 小时。

技巧 4：实时流的SessionId不是 UUID，而是任意字符串，但必须全局唯一
为避免会话冲突，我们用MD5(teacher_id + class_id + timestamp)生成 SessionId，而非简单用uuid4()。因为同一教师在不同班级上课时，若 SessionId 重复，Transcribe 会合并两个流的识别结果，造成字幕错乱。

技巧 5：Transcribe 的LanguageCode不支持方言代码（如zh-yue），必须用zh-CN+ 自定义词汇表
某粤语项目初期尝试LanguageCode=zh-yue，返回BadRequestException。AWS 官方文档明确：仅支持标准语言代码。正确方案是zh-CN+ 上传粤语发音词典（如 “你好” → “nei5 hou2”），实测粤语识别率提升至 89.3%。

5.3 成本优化实战：如何将 Transcribe 费用降低 40%

Transcribe 按音频时长计费（$0.0004/秒），看似简单，但隐藏着巨大优化空间：

• 音频裁剪：客服通话中，平均 35% 时长是静音、坐席系统提示音（“请稍候”）、客户挂机忙音。我们在上传前用 FFmpeg 自动裁剪：

  ffmpeg -i input.wav -af "silencedetect=noise=-30dB:d=0.5" -f null - 2> silence.log # 解析 silence.log，提取有效语音区间，再裁剪 ffmpeg -i input.wav