语音处理:Whisper语音识别实战专栏:AI/LLM工程化实战 - 从Prompt到Agent的完整落地指南模块7 多模态AI应用篇 第68篇摘要摘要:Whisper是OpenAI开源的语音识别模型tiny到large五档尺寸中文转录准确率随模型增大明显提升本文覆盖音频转文字、长音频分段、实时转录和SRT字幕生成全流程附完整可运行代码本专栏限时¥59.90(原价¥99)TL;DR 核心要点速览Whisper用编码器-解码器结构输入80维对数梅尔频谱输出文本token内部按30秒窗口处理音频tiny/base/small/medium/large五档参数量从39M到1550Mfp16推理显存约1GB到10GB中文转录从small起步medium能覆盖多数生产场景large-v3的中文WER比medium再降三到五成长音频直接transcribe会在30秒窗口边界截断单词时间戳漂移是最高频故障长音频标准做法是开VAD检测语音段按句切分逐段转录再合并faster-whisper内置vad_filter实时转录瓶颈在推理速度faster-whisper配int8量化1分钟音频能压进2秒initial_prompt塞领域热词中文数字和专业术语错误率能降一半本专栏限时¥59.90(原价¥99)开篇故事:一段40分钟录音让我改了方案我负责的客服系统接了个新需求质检组每天要听几百通录音人力听不过来。外包ASR服务一个月三万多准确率还凑合但产品名和方言一直识别错质检结论经常被客服驳回。老板拍板自研我装了openai-whisper用large模型跑了一天录音质检准确率直接超过外包水平我当时挺得意觉得这事成了。上线一周出事了。质检组长发来一段40分钟录音字幕从第22分钟开始整体错位时间戳越飘越远中间还漏了整整一句客服的话。我查了两天发现根子在Whisper内部把音频切成30秒窗口每个窗口独立解码一个单词恰好跨在窗口边界上就被切成两半识别结果和时间戳一起漂移。单段转写没问题长音频问题就露出来了。我后来换成按语音段切分先用VAD检测静音间隙在句子边界切开每段转完再按原时间戳合并问题消失。这套方案就是这篇文章的核心代码在后面第三节直接能跑。一、Whisper架构与版本选型1.1 架构一句话讲清Whisper是个标准的Transformer编码器-解码器模型。音频先转成80维对数梅尔频谱图过两层卷积把时间维下采样进编码器提取特征解码器再自回归吐出文本token。模型同时输出文本、语言ID和时间戳三种token一次推理把识别和字幕一起做掉。训练数据覆盖96种语言模型能自动检测输入说的是哪种语言中英混说也基本能跟住。为什么要转频谱图。原始音频每秒16000个采样点直接喂给Transformer序列太长计算量吃不消。梅尔频谱把声音按人耳听觉频率刻度压缩每帧只留80个数值几秒音频压成几十行矩阵序列长度缩了两个数量级。卷积层再对时间维下采样编码器看到的序列就短到可以正常注意力计算了。这套设计决定了Whisper对长音频的处理方式30秒一个窗口因为窗口越长注意力矩阵越大训练成本撑不住。多任务训练是Whisper的另一个特点。同一套模型同时学语音转文本、语言检测、时间戳预测、翻译四件事共享一套编码器。翻译任务让它把非英语转英语这个能力平时用不上但训练时让编码器学到的表征更通用中文识别也跟着受益。语音识别加时间戳一起出做字幕就不需要第二套校准工具。1.2 五个版本怎么选Whisper按参数量分五档tiny、base、small、medium、large中文效果差距非常大。我第一版直接用large准确率够了但显存10GB公司那台4GB显存的测试机直接跑不动只能换medium。选型号看三样东西准确率、显存、速度先对着表划掉超显存的再在剩下的里挑准确率够的。英文项目small就很好中文项目medium起步。版本参数量fp16显存中文准确率相对速度适用场景tiny39M约1GB较差, 长句会丢字约16倍速实时转写, 低配设备base74M约1GB差, 数字和术语错得多约8倍速英文为主, 草稿转写small244M约2GB可用, 日常对话能听懂约4倍速中文字幕, 轻量生产medium769M约5GB良好, 术语仍偶发错约2倍速中文生产, 客服质检large-v31550M约10GB优秀, 接近人工转写约1倍速会议纪要, 高要求场景速度是相对值以large为1倍具体看GPU型号A100上small轻松跑出8倍以上实时速度。表格里的显存是fp16推理值int8量化能再省一半。CPU也能跑tiny在主流CPU上勉强实时large在CPU上是灾难一小时音频要跑几小时CPU用户老老实实用small以下。官方模型还有两个变体值得知道。large-v3是目前中文最好的版本whisper库默认的large指的就是v3比v2的中文WER再降一成左右。turbo版本是v3的蒸馏加剪枝产物速度接近small准确率接近medium显存只要4GB左右我的客服质检后来换成turbo延迟降了一半准确率只掉了两个百分点。预算敏感的团队优先考虑turbo它才是日常性价比之王。准确率怎么量化光靠听不客观。标准做法是算WER(词错误率)取一段带人工转写的录音用模型转一遍逐词对比替换、删除、插入三类的错词数加起来除以总词数。中文WER要处理同音字人工转写和模型输出都先过一遍分词再逐词比对。我刚上线那阵懒得建测试集凭感觉说准了直到质检组长拿出错词统计我才意识到要建评测集。后来固定了200条人工转写的测试集模型版本升级前必跑一遍WERmedium的WER比small低三成左右这个数字比任何感觉都可靠。1.3 faster-whisper和distil-whisper官方whisper库是PyTorch实现速度一般。faster-whisper用CTranslate2重写同样的模型快3到4倍显存砍半还内置VAD和逐词时间戳我后面所有代码都用它。distil-whisper是蒸馏版体积小一半速度快一倍但目前只支持英文中文项目先别碰。边缘设备上有whisper.cpp的C实现树莓派能跑tiny但那属于嵌入式范畴后端工程师用faster-whisper就够了。还有一套思路是转ONNX或TensorRT工程量大收益在faster-whisper面前不明显小团队不用折腾。1.4 部署形态Whisper可以三种形态落地。第一种是脚本批处理录好的音频落盘后批量转省事我第一版就这么干的。第二种是HTTP服务用FastAPI包一层质检平台按需调用响应时间在秒级。第三种是实时流麦克风边录边转见第四节。模型首次下载会缓存到用户目录国内网络不好就把HF_ENDPOINT指到hf-mirror.com镜像装一次后面都是本地加载。显存之外还要看内存。medium和large在CPU推理时内存吃到16GB以上GPU推理也常驻6GB内存存模型参数。公司那台8GB内存的老服务器我直接放弃部署medium换small才跑起来。选型表里的显存数字只算模型权重真实部署按1.5倍留余量转写过程中的音频缓冲和临时数组还会再占一部分。模型缓存目录也要纳入管理。Whisper首次加载会把权重下载到用户目录换机器部署时重复下载很费时间把模型目录固定到项目下的models文件夹多台机器共享一份权重。磁盘紧张时先清模型缓存模型权重几十GB占大头清了重新下载就行。版本升级时新模型和旧模型分开存灰度期两版并存确认没问题再删旧版。二、语音转文字基础流程装好库直接跑代码非常短。注意两点指定languagezh跳过语言检测能省时间CPU上fp16必须关掉否则报错。transcribe还有几个常用参数temperature控制随机性默认0就能少很多重复输出verboseTrue能打印逐段的识别过程compression_ratio_threshold是防退化检测的阈值一般不用动。# 68_whisper_basic.py# 用whisper库转录一段中文音频# 安装: pip install openai-whisper (会带上torch, 约2GB)importwhisper modelwhisper.load_model(small)# 中文起步选small, 显存够就上mediumresultmodel.transcribe(customer_call.mp3,# 支持mp3/wav/m4a/flaclanguagezh,# 指定中文, 跳过语言检测, 省掉1到2秒fp16False,# CPU上必须False, GPU可改True加速)print(result[text])# 全文文本# 按段落带时间戳打印, 质检要定位到秒forseginresult[segments]:print(f[{seg[start]:.1f}s -{seg[end]:.1f}s]{seg[text]})输出里segments每个元素有start、end、text三个字段单位是秒。转写质量不好先查两件事音频来源是不是16kHz采样(Whisper会自动重采样但来源太差的音频救不回来)麦克风有没有严重底噪。质检场景我还会做一遍文本后处理去掉嗯啊这类语气词把识别出的数字统一格式化再过滤敏感词这层后处理对质检结论的准确率贡献不输换大模型。音频来源的质量检查放在预处理前面。三个问题先确认录音格式是不是常见容器采样率原始值多少有没有明显底噪。m4a和wav是安全的某些软件导出的ogg或amr要先转容器。原始采样率低于8kHz的录音信息量已经丢了预处理拉不回这类录音直接标记低置信度质检结论备注说明。底噪明显的先过一遍降噪滤镜维纳滤波或高通滤波都行降噪过度会削掉轻声和尾音宁可少降不可多降。转写之前先预处理音频能省掉一半的识别问题。踩坑经验我踩过一次录音文件是24kHz的m4a底噪大转写出来的文本混着大量错字当时以为是模型问题换了大模型也没用。后来统一先做三件事采样率归一到16kHz声道压到单声道音量归一化。ffmpeg一条命令能做完包装成函数放进管线里后面所有录音都先过这一步。# 68_preprocess.py# 转写前用ffmpeg做音频预处理# 安装: pip install ffmpeg-python (系统还需装ffmpeg, 含音频组件)importffmpegdefpreprocess(src:str,out:str):统一采样率16k, 压单声道, 音量归一化, 转写前的标准动作(ffmpeg.input(src).output(out,ar16000,ac1,afvolume0.9,loudnormI-16:TP-1.5:LRA11).run(overwrite_outputTrue)# 覆盖旧文件, 便于反复跑)preprocess(raw_recording.m4a,clean.wav)loudnorm那段参数是响度归一化的标准配置I-16是平均响度TP-1.5是峰值限制LRA11是动态范围。直播录音、电话录音这种动态范围大的音频跑完这段明显更稳。注意ffmpeg的音频组件有些精简版没编译进去报no such filter就用完整的ffmpeg安装包。三、长音频分段转录与SRT字幕回到开头的40分钟事故。踩坑经验写清楚Whisper的transcribe对长音频自动按30秒窗口切窗口之间没有语义边界词被截断后时间戳就飘。症状是前半段字幕准越往后越对不上漏句、重复词增多。排查方法也简单把转写结果按段落时间戳和音频实际内容逐段比对看哪一段开始脱节脱节点通常正好是30秒的整数倍。正确做法是先切好再转用VAD(语音活动检测)找到静音间隙在句子边界切开每段转完再按原时间戳合并。faster-whisper内置VAD一个参数就够。min_silence_duration_ms控制切分粒度0.6秒比较通用语速慢的访谈类音频可以放宽到1秒。VAD漏检的情况也有一段话中间没有停顿超过阈值就整段算一条segment不影响识别结果只影响字幕粒度。# 68_whisper_srt.py# 长音频分段转录 SRT字幕生成# 安装: pip install faster-whisper (CTranslate2后端, 比openai-whisper快3到4倍)fromfaster_whisperimportWhisperModel# device可填cuda或cpu, compute_type用int8_float16显存省一半modelWhisperModel(small,devicecuda,compute_typeint8_float16)segments,infomodel.transcribe(meeting_2h.wav,languagezh,vad_filterTrue,# 开VAD按语音段切分, 解决30秒窗口截词vad_parameters{min_silence_duration_ms:600},# 静音超0.6秒就切开word_timestampsTrue,# 输出逐词时间戳, 字幕校准要用beam_size5,# beam越大越准越慢, 5是速度和质量的折中)deffmt_ts(seconds):秒数转SRT时间格式 00:00:00,000msint((seconds-int(seconds))*1000)h,rdivmod(int(seconds),3600)m,sdivmod(r,60)returnf{h:02d}:{m:02d}:{s:02d},{ms:03d}defto_srt(segments,out_path):把识别结果写成SRT字幕文件, 用utf-8-sig编码播放器才认lines[]idx1forseginsegments:ifnotseg.text.strip():continuelines.append(f{idx}\n{fmt_ts(seg.start)}--{fmt_ts(seg.end)}\n{seg.text.strip()}\n)idx1withopen(out_path,w,encodingutf-8-sig)asf:f.write(\n.join(lines))to_srt(segments,subtitle.srt)print(字幕已生成: subtitle.srt)2小时会议音频2080显卡上small模型int8大概4分钟出全部字幕。没GPU用cpu也能跑时间乘10倍。字幕文件用utf-8-sig编码普通utf-8在部分播放器里中文会乱码这是字幕圈的老规矩。segment文本里偶发的空白段落我在写入时直接跳过避免SRT序号断档。SRT批量生成后过一遍格式校验。序号连续时间递增每行时长不超6秒句首句尾无多余空格四类问题脚本扫一遍扫完再抽查10%。格式校验解决的是播放器兼容很多播放器对序号断档和重叠时间戳直接罢工。校验脚本挂在管线末尾出片前必跑和人工抽检分层把关。这条规则是字幕组的老规矩我接手后把它固化进了脚本再没出过播放事故。显存不够跑medium的时候还有一招把音频切成10分钟的小段分别转每段转完释放显存再转下一段。代价是段落边界可能出现重复或丢失和30秒窗口截词是同一类问题用VAD切段能绕开。实测下来分段跑让8GB显存的卡也能带medium只是速度比一次性跑慢两成。批量质检的编排也在这个代码上加一层。录音文件遍历入队每个文件一个转写任务GPU排队串行CPU可以按核数并行。任务失败记到日志表重跑只跑失败的不重复烧算力。质检平台按小时汇总出准确率报表这就是完整的生产流程。批量编排再展开一点。录音按日期分目录入队队列任务带重试次数失败三次进死信目录人工处理完重新入队。GPU串行转写CPU预处理并行转写和预处理之间用文件系统解耦转写线程只读预处理完的wav。任务表记状态pending、running、done、failed四态界面按小时刷新哪一批卡住了一眼看到。这套编排跑了一年几千小时录音没丢过一条。四、实时转录方案实时转录要看清瓶颈在哪。Whisper一次吃30秒窗口推理速度和音频时长成正比tiny加int8能把1分钟音频压到2秒以内才有资格谈实时。做法是录音线程攒音频攒够阈值就丢给模型转结果按输出时间戳归位。下面是个简化版能跑生产上要补麦克风断连重连和音频增益控制。# 68_realtime.py# 边录音边转写, 简化版# 安装: pip install faster-whisper pyaudio numpyimportqueueimportthreadingimportnumpyasnpimportpyaudiofromfaster_whisperimportWhisperModel modelWhisperModel(tiny,devicecpu,compute_typeint8)audio_qqueue.Queue()defrecord():录音线程, 每2秒丢一段音频进队列ppyaudio.PyAudio()streamp.open(formatpyaudio.paInt16,channels1,rate16000,frames_per_buffer4096,inputTrue)whileTrue:frames[]for_inrange(2*16000//4096):frames.append(stream.read(4096))audio_q.put(b.join(frames))deftranscribe_loop():取队列里的音频转写, 结果直接打印whileTrue:audioaudio_q.get()# faster-whisper不收原始bytes, 先转成int16的numpy数组再喂audio_npnp.frombuffer(audio,dtypenp.int16)segments,_model.transcribe(audio_np,languagezh,beam_size1)forseginsegments:print(f[{seg.start:.1f}s]{seg.text})threading.Thread(targetrecord,daemonTrue).start()transcribe_loop()这个方案的延迟大概2到4秒做实时字幕够用做语音对话偏慢。要更低延迟得换思路用静音检测只转有语音的片段或者上faster-whisper的服务化部署加批量推理。延迟每降一秒都要拿准确率去换实时场景tiny的错字率比medium高一截这个权衡提前跟产品说清楚别等上线了再吵。生产环境的实时转写我建议走WebSocket而不是轮询。服务端维护每个连接各自的音频缓冲客户端把麦克风数据流式推上来服务端攒够2秒就转一次结果从同一条连接推回去。FastAPI的WebSocket原生支持比HTTP轮询少一半的网络开销。实时字幕产品基本都是这个结构断线重连时客户端要把缓冲清掉否则新旧音频拼一起转出错句。多路实时会话共享一块GPU时转写请求会排队单路延迟不受影响吞吐被卡在推理速度上。tiny模型一块3060能同时撑四路实时转写medium只能撑一路实时场景上tiny加int8几乎是必选项。排队策略用先来先服务会话优先级高的插队要慎重插队会把其他路的延迟顶上去用户体验更差。扩容量按峰值并发配GPU按两倍冗余算别算平均值语音产品的高峰和低谷差一个数量级。五、多语言识别与热词Whisper自动语言检测在单语种音频上很准中英混说的会议里它会在句子之间切语言转出来的文本中英混排。强制指定languagezh会压制英文输出反而把英文句子转成拼音或错字中英混杂的录音别指定语言。initial_prompt是个隐藏利器。转写前塞一段领域上下文模型会往那个方向纠正。我处理客服录音时塞以下是普通话客服通话记录, 涉及退款、售后、物流、差评这类句子产品名的错误率肉眼可见地降。踩坑提醒initial_prompt别塞太长几十个词就够塞多了模型会往prompt的句子上靠输出里偶发出现prompt里的原句。数字是中文识别的重灾区“2023年被读成英文数字混排很常见。initial_prompt加一句请输出简体中文和中文数字”能压掉大半。日期、金额、电话号码这三类质检场景里错了影响结论我都是转写后加一层正则后处理把明显错位的数字按上下文修正人工只复核修正点。语言检测本身也有开销auto模式下Whisper要先听前30秒判断语言再决定用什么语言解码多花一轮推理。单语种场景显式指定language能省掉这部分时间。中英混合场景没法指定就接受auto模式的额外开销一条两小时的录音大概多花两分钟。另外一个细节指定languagezh时把繁体音频也归到简体输出Whisper会统一转简体台湾腔录音直接用这个参数。中英混合还有一个工程细节转写结果要按句子分桶中文句子进中文校验规则英文句子进英文规则别混着处理。质检平台的多语言规则通常按文本语言分路由混排的文本会让规则引擎两头都误判。分桶按语言检测结果走Whisper的segments带language字段一句一个判定比整段判定准得多。我踩过一次整段标中文英文句子的质检规则全部没生效漏了一个客户投诉关键词。六、字幕质量与后期SRT生成在第三节已经给了完整代码这节补三个提质量的点。一是重复词长音频里Whisper偶尔把一个词重复输出两遍转写时temperature设0重复率明显下降。二是断句字幕按句子切而不是按时间硬切每行控制在20个汉字内观感好很多。三是词级时间戳faster-whisper的word_timestamps给出逐词时间做逐字字幕或校准音频就用它。要更细的活儿whisperx这个库在Whisper基础上加了词级校准和说话人分离会议纪要场景值得试代价是显存再加2GB左右。whisperx的词级校准用动态时间规整把文本和音频逐词对上比faster-whisper自带的词时间戳更准但多一道校准计算速度慢一些。整条字幕管线串起来就是录音入库VAD切段逐段转写合并校准生成SRT人工抽检一天几百通录音一个人管得过来。抽检比例我定在5%抽到的录音人工听一遍把错误类型记下来错得集中的类目就回炉调initial_prompt或补正则。字幕样式上有两个行业默认值。一是单行字幕时长控制在2秒以内观众扫读速度跟不上更长的时间。二是断行在语义边界主语宾语别拆开我们昨天讨论的和方案通过了拆两行就破坏了阅读节奏。SRT时间戳精确到毫秒剪辑软件只认整帧导出前做一次帧级取整避免播放器卡帧。视频平台的质检组就靠这两条规则卡字幕返工率明显降。字幕抽检的标准动作是双人交叉复核。第一个人按听写稿对字幕第二个人只看时间轴两人独立打分分歧样本进讨论会。抽检记录按月汇总错误类型分布出来哪类错误多就针对性补哪类。重复词多就调temperature断句乱就改VAD参数时间轴漂就查窗口截词错误类型和根因基本一一对应。这套机制跑下来字幕返工率从上线初的12%降到3%。七、转写后处理从文本到结论语音转文字只是前半场后半场是文本后处理。质检场景里语气词、重复词、识别错的数字都要处理处理完的文本才敢进质检规则引擎。后处理分三步走清语气词统一数字和标点敏感词标记。下面这段代码覆盖这三步按自己词库改填充即可。# 68_postprocess.py# 转写文本后处理: 语气词过滤 数字标记 敏感词标记# 安装: pip install opencc-python-reimplemented (可选, 繁体转简体)importre FILLERS[嗯,啊,呃,那个,然后就是]# 常见语气词表defclean_text(text:str)-str:去掉语气词, 标点归一, 返回干净文本forwinFILLERS:texttext.replace(w,)textre.sub(r[,。;], ,text)returntext.strip()defformat_numbers(text:str)-str:把常见英文数字混排标记出来, 供人工复核returnre.sub(r\b(two thousand|twenty twenty|three hundred)\b,[疑似英文数字],text)deftag_sensitive(text:str,words)-str:命中敏感词列表的片段打标记, 质检结论要引用forwinwords:texttext.replace(w,f[敏感:{w}])returntext sample嗯, 那个2023年twenty twenty三年, 退款金额三百块, 啊print(tag_sensitive(format_numbers(clean_text(sample)),[退款]))跑出来的结果里2023年被标成[疑似英文数字]退款被打上敏感词标记三个标记各管一件事语气词直接删英文数字标记出来人工看敏感词标记喂给质检规则引擎。质检平台的结论生成就建在这层文本上比直接拿原始转写靠谱得多。后处理还有一个容易被忽略的点文本入库要存两份原始转写和后处理文本。原始转写留着追模型问题后处理文本给业务用两个字段都建索引。我吃过一次亏只存了后处理文本模型版本升级后想对比新旧效果原始数据没了只能重跑一遍全量录音烧了三天GPU。八、转写服务化部署脚本批处理够用之后质检平台要按需调用我把它包成HTTP服务。FastAPI加faster-whisper几十行搞定。服务启动时加载一次模型所有请求共享模型加载要十几秒别在请求里加载。并发请求来了排队推理GPU一次只能跑一个队列交给FastAPI的异步机制。# 68_server.py# 用FastAPI把转写封装成HTTP服务# 安装: pip install fastapi uvicorn python-multipartimportosimporttempfilefromfastapiimportFastAPI,UploadFilefromfaster_whisperimportWhisperModel appFastAPI()# 服务启动时加载一次模型, 全局共享, 不要在每个请求里加载modelWhisperModel(turbo,devicecuda,compute_typeint8_float16)app.post(/transcribe)asyncdeftranscribe(file:UploadFile):上传音频文件, 返回带时间戳的段落列表suffixos.path.splitext(file.filename)[1]or.mp3withtempfile.NamedTemporaryFile(suffixsuffix,deleteFalse)astmp:tmp.write(awaitfile.read())pathtmp.name segments,_model.transcribe(path,languagezh,vad_filterTrue)result[{start:round(s.start,2),end:round(s.end,2),text:s.text}forsinsegments]os.remove(path)return{segments:result}# 启动: uvicorn 68_server:app --host 0.0.0.0 --port 8000服务化之后有两个监控指标要看。第一个是单请求耗时turbo模型在3060上转5分钟音频约2秒超过5秒就要查队列堆积。第二个是GPU显存和利用率faster-whisper的int8把显存压到4GB以下一台8GB显卡的机器可以同时跑转写服务和预处理。线上挂了别忘了给接口加重试质检平台批量调用时偶发超时重试两次能覆盖绝大多数抖动。监控面板再加三个指标。一是队列深度请求进来排队的数量超过模型吞吐就报警。二是显存峰值int8的turbo显存不到4GB峰值超6GB说明有内存碎片或并发配置问题。三是错误率转写接口偶发503和超时错误率超过2%先查上游存储和网络。告警阈值按分钟粒度设别用小时粒度小时粒度下高峰期的问题被平均掉了等看到时用户已经骂了一轮。服务多实例部署时模型权重要按GPU规划。一块GPU一个workerworker之间不共享模型扩实例就是加GPU。多个worker共享同一份队列时转写结果按请求ID归位别混。模型热加载的版本管理也要做新模型先在灰度worker上跑A/B对比WER指标过了再全量切。Whisper服务化最怕模型版本不统一线上两个worker用不同版本转写结果质量忽高忽低用户投诉都查不出来。九、转写接LLM会议纪要一条线转写文本直接丢给业务同事看没人看。质检平台和会议纪要的真实形态是结构化输出结论、待办、责任人、时间节点。这一步交给LLM转写做输入LLM做整理。下面代码把segments拼成带时间戳的逐字稿一次对话生成结论、待办、分歧点三部分客服质检的周报就是从这层文本自动出的。# 68_meeting.py# 转写结果接LLM, 自动出会议纪要# 安装: pip install openaifromopenaiimportOpenAI clientOpenAI()defsummarize_segments(segments,topic:str)-str:把带时间戳的转写段落拼成文本, 交给LLM总结transcript\n.join(f{seg[start]:.0f}s{seg[text]}forseginsegments)respclient.chat.completions.create(modelgpt-4o-mini,messages[{role:system,content:你是会议纪要助手, 输出三个部分: 结论、待办、分歧点},{role:user,content:f会议主题:{topic}\n逐字稿:\n{transcript}},],temperature0.3,# 纪要要稳定, 别让温度放飞)returnresp.choices[0].message.content# 从68_server.py的接口拿到segments, 这里直接演示demo[{start:0.0,end:8.0,text:今天我们讨论上线排期, 我先说结论, 两周后灰度},{start:8.2,end:15.0,text:客服组反馈录音质检准确率不够, 需要再调一轮模型},]print(summarize_segments(demo,质检系统排期会))注意逐字稿别一次塞太多。gpt-4o-mini的上下文窗口虽然大两小时会议的转写有十万字级别超出就截断。分段投喂是标准做法每段三十分钟逐段总结再合并合并时让LLM去重。会议纪要还有一个细节转写里的语气词和重复词先过第七节的后处理喂给LLM的文本越干净出来的纪要越像人写的。带时间戳的逐字稿保留原样存档纪要只是加工视图原始转写丢了就追不回问题。纪要的模型选型也有讲究。gpt-4o-mini处理摘要够用长会议的分段总结和去重用4o更稳成本高一些。批量纪要任务放夜间跑白天接口给实时业务两拨流量分开。纪要的模板要版本化结论、待办、分歧点的字段名定了就别改下游的系统按字段解析字段名一变整个管道都要跟着改。我吃过一次亏把待办改成行动项下游报表空了一个月才被发现。常见问题FAQQ1: whisper库装不上或模型下载慢A1: 模型走HuggingFace国内设HF_ENDPOINThttps://hf-mirror.com镜像下载faster-whisper同样适用Q2: 中文识别准确率哪一档够用A2: 日常对话small够用涉及术语和数字的质检场景上medium发布会和会议纪要直接large-v3显存4GB左右可考虑turbo的性价比Q3: 显存不够怎么办A3: 四选一换更小的模型int8量化省一半显存音频切成10分钟小段跑完释放显存或者CPU跑small以下的型号Q4: 转写结果重复卡带A4: temperature设0长音频开VAD切分都做了还重复就检查音频本身有没有卡顿录音设备丢帧也会造成重复Q5: 时间戳越往后越不准A5: 典型的窗口截词问题开vad_filterTrue按静音切段别让Whisper自己切30秒窗口白噪音多的音频先过ffmpeg降噪Q6: 能识别方言和英文吗A6: 英文很好粤语和四川话在large上有可用效果冷门方言建议用领域微调或换讯飞的方言服务繁体中文自动转简体Q7: 商用有没有版权问题A7: Whisper是MIT协议可商用模型输出内容仍需自己审核涉及用户录音要按个人信息保护法做合规处理Q8: 实时转写延迟能做到多少A8: tiny加int8大约2到4秒服务化部署加静音检测能压到1秒左右再低要上流式模型方案延迟换准确率的账提前算清楚Q9: 和讯飞、阿里云ASR怎么选A9: 自部署Whisper胜在免费可控云服务胜在省心量小用云量大自部署百万分钟级录音自部署成本优势明显还要把人力运维算进对比Q10: SRT字幕中文乱码A10: 写文件用utf-8-sig编码部分播放器只认带BOM的UTF-8读取时用utf-8-sig解码避免首行带看不见的字符为什么订阅本专栏免费教程只给一句model.transcribe本文把长音频截词、时间戳漂移、VAD切分这些生产事故讲透培训班讲Whisper一笔带过本文给出tiny到large完整选型表加显存和速度实测数据一套代码覆盖基础转写、长音频分段、SRT字幕、实时转录四个场景改改路径就能跑与第65篇多模态入门、第69篇TTS衔接语音处理的输入输出两端一次学完一次订阅终身回看代码随库版本更新持续修正相关推荐Transformer架构图解:注意力机制通俗讲解OpenAI API入门:Python调用GPT全流程Ollama本地部署:一行命令跑起大模型限时¥59.9030秒完成订阅今天就能开始学习