推荐语
告别手忙脚乱的会议记录!揭秘如何用AI语音识别技术实现高效会议速记,从技术选型到K8s部署全解析。
核心内容:
1. 会议场景痛点分析与AI语音识别解决方案
2. FunASR开源框架的技术优势与实现原理
3. 从本地demo到K8s容器化部署的完整实践路径
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
本文从日常会议的场景痛点出发,介绍大参林AI速记在产品搭建过程中遇到的一系列问题,并阐述如何通过一步步的技术调优,结合FunASR框架、语音大模型,提升拾音效果、语音转写效果,实现高精度语音识别能力。日常工作中,开会时总得有个人当 “会议秘书”,左手攥着笔,右手敲着键盘,一边紧跟老板的思路,一边还要把同事们 “嗯…这个…” 的零散发言快速记下来。这活儿不光要脑子转得快,还能即时总结归纳,碰上长会,更是对专注力的极大考验,一不小心就可能漏掉关键信息。伴随着AI的浪潮,人们开始思考:能不能把会议录音转成文字,再让大语言模型来归纳总结会议内容?这样一来,不仅可以减轻人工记录的负担,还能提高会议纪要的生成效率。但要实现这个想法,第一步就得解决 “语音变文本” 的问题。这时候,就需要搭建实时语音转写服务(Real-time ASR)。为方便理解,先整理了搭建AI速记的核心实现链路现状:云服务商ASR能力对比:为了完成语音文本的获取,我们进行了多个主流云服务商的实时语音转写服务产品调研,这些云服务商的服务具有以下特点: - WebSocket协议完成数据接收与结果推送,保证实时性;
- 基础版本只支持普通话、英语,对于部分小众语言或特定场景的语音识别支持不足;
- 个性化热词功能全局生效,某些需要针对特定领域或会议主题进行精准识别的场景下,灵活性不够。
结论:基于FunASR自建语音转写服务;在语音转写准确率差别不大的情况下,基于拓展性、成本、企业内部信息安全等方面的考虑,我们把方向从云服务商转移到私有化搭建语音服务,并且确定了技术选型:Funasr的开源项目。FunASR 是由阿里巴巴达摩院开发的开源语音识别工具包,其凭借高精度模型、多语言支持和友好的技术设计等,提供企业级语音处理解决方案。其核心能力除了语音识别以外,还集成了语音端点检测(VAD),多人对话语音识别,自定义语言模型,与对语言类别支持等能力。其简单的工作流程如下图:该开源项目提供了非常丰富的部署使用资料,依托这个项目我们能快速地在本地搭建起一个使用CPU资源进行实时语音转写的demo,并且经过对比验证,其语音转写文本质量与云服务商并无太大的差异。核心能力实时语音转写依托websocket协议接收推送的语音数据,通过网管完成握手后代理连接到Funasr核心服务。而2pass模型则是同时协调模型,兼顾返回语音的实时性要求的同时,提供结束点监控,当语句结束后会对整体语音信息进行一次回顾重新生成并协作优化结果,该总体服务流程如下图:
上述流程中,SenseVoice负责离线回归部分,Paraformer模型负责实时识别,speech_paramformer负责VAD端点识别,在上述模型协作下完成了2pass模型的语音实时识别工作。整体来看,FunASR是具备了高准确性、多语言支持、实时性高等特点的,满足我们的使用场景。# fastapi实现离线语音转写接口@app.post('/api/v1/asr')async def turn_audio_to_text( file: UploadFile, lang: Annotated[Language, Form(description="语言类型")] = 'auto'): # 生成格式化文件 file_path = await convert_audio(file) try: import librosa import numpy as np # 加载文件 audio_data, _ = librosa.load(file_path, sr=16000, mono=True) print(f'file_path: {file_path}') # 确保音频数据是float32类型 audio_data = audio_data.astype(np.float32) # 语音文件转写文本 text = model.generate( input=audio_data, language=lang, use_itn=True, batch_size_s=60, merge_vad=True) result_txt = clean_result_label(text[0]['text']) # 获取音频元数据 try: info = torchaudio.info(file_path) metadata = { "sample_rate": info.sample_rate, "num_channels": info.num_channels, "num_frames": info.num_frames, "duration": info.num_frames / info.sample_rate if info.sample_rate > 0 else 0, "encoding": str(info.encoding) if hasattr(info, 'encoding') else None, "bits_per_sample": info.bits_per_sample if hasattr(info, 'bits_per_sample') else None } except Exception as meta_error: # 错误处理... finally: # 删除临时文件 os.remove(file_path)
多语言能力基于SenseVoice模型内置支持。并且通过实时语音转写的初始化协议进行定义,默认语言类型为auto(自动识别)。当需要指定语音类型时可以使用参数svs_lang完成。如下:{ "mode": "offline", "wav_name": "wav_name", "wav_format": "pcm", "is_speaking": true, "hotwords": "{}", "itn": true, "svs_lang": "zh"}
SenseVoice:除了上述基础能力外SenseVoice模型还支持一些额外的能力比如ITN(逆文本规范化),该能力可以对于语音输入内容进行矫正,让其更容易被机器理解,如用户语音输入“下午三点”经过逆文本规范化之后会转化为“15:00”。Paraformer:模型是一种高效的非自回归端到端中文通用语音识别模型,在实时语音端点检测上效果较好,适用于实时的语音识别转写。为了语音服务稳定性,在企业内部使用k8s进行服务的部署、管理与调度,因此把该服务落地的最重要的工作就是服务容器化。官方提供了funasr-runtime-sdk-online-cpu的docker基础镜像,虽然该镜像对于快速本地启动与验证提供了非常好的帮助,但是直接使用该镜像存在以下问题:问题2:该项目对部分模型指定了版本,当你想调整模型版本缺少参数注入手段。由于该项目默认拉起服务后检查本地模型文件是否存在,若不存在则会去下载相关模型,而语音识别模型往往比较大,因此会有很长的启动等待时间,若不预下载模型则会出现一个服务拉起需要20到30分钟不等(其中大部分时间等待模型文件下载)。由于内部系统的限制第一个方案无法使用,只能定制化镜像在构建阶段完成模型的下载,确定了方案后,开始深入到项目中寻检预下载的可行性,项目的启动入口为一个启动脚本`run_server_2pass.sh`,我们从脚本开始入手。根据启动脚本能看到实际上使用的可执行`Funasr/runtime/websocket/build/bin/funasr-wss-server-2pass.cpp`,在该入口文件中有这么一段代码:通过上述代码发现,项目里面存在可直接使用的模型下载python代码,因此我们在构建镜像时,只需要使用该脚本提前完成相关模型的下载工作即可。然后我们进入到下载脚本文件,能得知该脚本支持的核心启动参数,而具体执行的命令如下:RUN python -m funasr.download.runtime_sdk_download_tool --type onnx --quantize True --model-name iic/SenseVoiceSmall-onnx --model_revision v2.0.5 --export-dir /workspace/models
至此,需要用到的东西都具备了,我们开始编写镜像构建脚本,在官方基础镜像的基础上加入预下载模型的能力。截至目前,我们通过定制化镜像解决了启动服务模型下载速度慢导致启动等待时间过长的问题。把模型打包到镜像内也能有效的保证服务镜像的稳定,不会出现因为模型仓库删除导致启动时无法下载模型的问题。由于我们并不使用脚本默认的模型,因此我们需要调整官方项目提供的启动脚本。在修改模型的同时,还需要支持指定相关模型的版本信息,而不是使用模型的master分支。从启动脚本入手,通过启动脚本传入额外参数,并调整服务文件支持该参数。从启动文件入手,阅读项目的启动文件,项目支持通过启动参数传入指定的语音识别模型版本信息,分别为: offline_model_revision 和 online_model_revision。找到适配参数,我们不需要修改源文件并重新编译,只需要把参数通过启动脚本传递进去即可,调整启动脚本`run_server_2pass.sh`如下图:完成了启动脚本调整之后只需要在镜像构建时,把新的启动脚本替换到容器内即可。至此,Funasr项目容器定制化的问题基本解决。
Q: 当完成了一个功能的交付之后,就会进入到下一步,如何将该能力提供给内部其他系统使用?如何对系统流量和负载进行监控?是否需要拓展更多语音识别的能力等一系列问题,这些都会影响到系统的稳定性与对内提供服务的质量。A: 为了解决上述问题,在Funasr服务的搭建完成后,我们还需要做一些额外的事情,一个网关,用于监控和提供统一的API接口提供给其他系统。在上述系统架构蓝图描述中,通过Funasr-Api-Gateway作为统一的入口端点,在该系统上完成一些业务需要的能力开发如支持语音文件转写、实时语音转写等。并且能够在该统一入口端点进行系统流量的监控、Funasr服务资源调度与内部系统调用统计等相关服务指标的监测。底层以私有化部署的语音模型为底座。当前,语音服务平台作为AI中台的核心能力之一,已经具备较好的语音识别能力,除了已经在AI速记落地使用,也提供了API供部分业务系统接入。未来可作为企业级的AI语音平台,探索更多可落地的场景。