腾讯云AI语音识别实战：会议纪要自动生成方案

1. 从会议记录这件苦差事说起如果你在团队里负责过会议纪要大概经历过这种循环开会时拼命敲键盘生怕漏掉关键结论会后对着两小时录音反复拖动进度条一句一句往回听好不容易整理完发现某个行动项的责任人没记清楚又得在群里所有人确认。一场一小时的会整理纪要往往要花掉一个半小时效率低不说还容易漏掉重点。这两年语音识别技术成熟了不少尤其是云端AI语音识别服务把录音转文字这件事的门槛降到了几乎为零。我最近用腾讯云AI语音识别搭了一套会议小帮手从录音上传到结构化纪要输出整个流程跑通之后整理一场会的耗时从90分钟压缩到了15分钟以内。这套东西不复杂核心就是调几个API但中间有不少细节值得说道说道——比如长音频怎么切分、说话人怎么区分、识别结果怎么后处理成能看的纪要。这篇内容适合两类人看一类是经常要做会议纪要、想用技术手段解放自己的职场人另一类是想了解语音识别API实际落地流程的开发者。我会把整个搭建过程拆开讲包括为什么这么选型、每一步的参数怎么定、踩过哪些坑以及最终怎么把一堆识别文本变成真正能用的会议纪要。代码部分以Python为主都是可以直接跑的完整逻辑。2. 为什么是腾讯云AI语音识别而不是本地模型2.1 本地语音识别的三个现实门槛一开始我也想过用开源方案本地部署比如Whisper这类模型。想法很美好数据不出本地、没有调用费用、想怎么改怎么改。但实际跑下来三个问题绕不过去。第一是硬件成本。要在合理时间内转写一小时的中文会议录音本地跑需要一块像样的GPU。如果只是偶尔用用为这个专门配一台带显卡的机器投入产出比太低。第二是中文场景的准确率。会议录音的特点是多人、有口音、有专业术语、有背景噪音通用开源模型在中文会议场景下的识别准确率实测下来比云端专门优化过的服务要低一截尤其是专业术语和数字部分。第三是维护成本。模型要更新、要调参、要处理各种音频格式这些活儿加起来远不如直接调API省心。2.2 云端方案的核心优势在哪腾讯云AI语音识别在这几个维度上的表现是我最终选它的原因。它提供了一整套语音识别能力包括一句话识别、录音文件识别、实时语音识别等不同接口覆盖了从短语音到长音频的各种场景。对于会议场景来说最核心的是录音文件识别这个能力——它专门针对长音频做了优化支持小时级的音频文件还能返回说话人分离的结果也就是把不同说话人的内容区分开。说话人分离这个功能对会议纪要太重要了。一场会有五六个人发言如果转出来的文字是一整块根本分不清谁说了什么整理纪要时还得靠记忆去对应。有了说话人分离输出就是说话人1…… 说话人2……这样的结构整理起来效率完全不一样。另外腾讯云在中文语音识别上的积累比较深对普通话、带口音的普通话、中英文混说这些情况都有针对性优化。会议里经常出现的这个Q3的OKR、ROI大概是多少这类中英夹杂的表达识别效果比通用模型好不少。2.3 成本账怎么算费用方面录音文件识别按音频时长计费具体价格以官方最新公布为准。对于个人或小团队来说如果一个月开20场会、每场1小时总时长20小时这个量级的费用完全在可接受范围内。相比专门雇人做纪要或者自己花大量时间整理这个投入产出比是很划算的。提示正式使用前建议先开通服务并领取免费额度用真实会议录音跑一遍确认识别效果和费用符合预期再批量使用。3. 搭建前的环境准备与账号配置3.1 开通服务与获取密钥第一步是在腾讯云控制台开通语音识别服务。开通之后需要在访问管理里创建一对API密钥也就是SecretId和SecretKey。这对密钥是调用所有API的凭证务必保管好不要硬编码在代码里提交到代码仓库。我的做法是把密钥放在环境变量里代码通过读取环境变量获取。这样既安全换环境时也方便。export TENCENT_SECRET_ID你的SecretId export TENCENT_SECRET_KEY你的SecretKey3.2 Python环境与SDK安装腾讯云提供了官方的Python SDK封装了签名、请求、重试这些底层逻辑直接用SDK比手写HTTP请求省事得多。安装命令如下pip install tencentcloud-sdk-python除了SDK还需要几个辅助库requests用于下载识别结果录音文件识别是异步的结果通过URL返回pydub用于音频格式处理和切分python-docx用于最后生成Word格式的纪要。pip install requests pydub python-docx3.3 音频格式的前置处理腾讯云录音文件识别支持的音频格式包括wav、mp3、m4a、aac等常见格式但有几个硬性要求需要注意采样率建议16kHz位深16bit单声道效果最好。手机录的会议音频往往是双声道、44.1kHz直接上传虽然也能识别但为了效果和体积建议先转成标准格式。用ffmpeg做格式转换是最稳的一条命令搞定ffmpeg -i input.m4a -ar 16000 -ac 1 -acodec pcm_s16le output.wav这里-ar 16000指定采样率16kHz-ac 1指定单声道-acodec pcm_s16le指定16bit PCM编码。转完之后文件体积会小很多上传也快。注意如果会议录音本身质量很差比如离麦克风太远、环境噪音大前置处理能改善的有限。这种情况建议在录音环节就下功夫用指向性麦克风或者让发言的人靠近录音设备。4. 录音文件识别的完整调用链路4.1 异步识别的任务模型腾讯云录音文件识别是异步的整个流程分三步创建任务、查询结果、获取转写文本。为什么设计成异步因为长音频转写需要时间一小时音频大概需要几分钟到十几分钟不等同步接口会超时。异步模型下你提交任务后拿到一个TaskId然后轮询查询任务状态等状态变成成功后再去拿结果。这个模型理解起来不难但实际写代码时有个细节容易忽略轮询要有退避策略。如果每秒查一次既浪费调用次数也可能触发频率限制。我的做法是第一次等10秒之后每次间隔递增最多等到5分钟还没结果就报错。4.2 创建识别任务的参数详解创建任务时有几个参数直接决定识别效果值得逐个说清楚。EngineModelType是引擎模型类型会议场景建议用16k_zh16kHz中文通用模型。如果会议里有较多英文内容可以考虑16k_zh_en这类中英混合模型。ChannelNum是声道数单声道填1。SpeakerDiarization是说话人分离开关会议场景必须打开设为true。SpeakerNumber是说话人数量如果不确定可以填0让系统自动判断但如果你大概知道参会人数填一个接近的数字能提升分离准确率。ResTextFormat是返回结果格式建议设为1这样返回的是带时间戳和说话人标记的详细结果方便后续处理。SourceType是音频来源类型如果是通过URL传入音频就填0如果是直接上传文件就填1。from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.asr.v20190614 import asr_client, models import os, json, time cred credential.Credential( os.environ[TENCENT_SECRET_ID], os.environ[TENCENT_SECRET_KEY] ) http_profile HttpProfile(endpointasr.tencentcloudapi.com) client_profile ClientProfile(httpProfilehttp_profile) client asr_client.AsrClient(cred, ap-shanghai, client_profile) def create_task(audio_url): req models.CreateRecTaskRequest() req.EngineModelType 16k_zh req.ChannelNum 1 req.ResTextFormat 1 req.SourceType 0 req.Url audio_url req.SpeakerDiarization True req.SpeakerNumber 0 resp client.CreateRecTask(req) return resp.Data.TaskId4.3 轮询查询与结果获取创建任务后拿到TaskId接下来就是轮询。查询接口返回的Status字段0表示等待中1表示识别中2表示识别完成3表示识别失败。识别完成后Result字段里就是转写文本ResultDetail里是带时间戳和说话人信息的结构化数据。def wait_for_result(task_id, max_wait300): interval 10 waited 0 while waited max_wait: req models.DescribeTaskStatusRequest() req.TaskId task_id resp client.DescribeTaskStatus(req) status resp.Data.Status if status 2: return resp.Data if status 3: raise RuntimeError(f识别失败: {resp.Data.ErrorMsg}) time.sleep(interval) waited interval interval min(interval * 1.5, 30) raise TimeoutError(识别超时)这里有个实操经验ResultDetail里的时间戳单位是毫秒说话人标记是SpeakerId字段。拿到这些数据后就可以按说话人聚合生成结构化的纪要底稿。4.4 音频上传的两种方式SourceType为0时音频需要是一个可公网访问的URL。这意味着你得先把音频传到对象存储生成一个临时链接。SourceType为1时可以直接上传音频文件的数据适合小文件。会议录音通常比较大建议走对象存储的方式。上传到对象存储后生成一个带签名的临时URL有效期设长一点比如1小时确保识别任务能在链接失效前完成。这个细节不注意的话会出现任务创建成功但识别失败的情况排查半天才发现是URL过期了。5. 把识别文本变成能用的会议纪要5.1 原始识别结果长什么样识别完成后拿到的ResultDetail大概是这样的结构每个元素包含FinalSentence这句话的文本、StartTime和EndTime起止时间毫秒、SpeakerId说话人编号。如果开了标点预测文本里会带标点如果没开就是一连串没有标点的文字。原始结果直接看是能看但离纪要还差得远。它只是把语音转成了文字没有结构、没有重点、没有行动项。接下来要做的就是在这堆文本上做后处理。5.2 按说话人和时间聚合第一步是按说话人聚合。把同一个SpeakerId的句子合并成段落每个段落前面标上说话人X。这样一眼就能看出谁说了什么。如果知道参会人名单还可以做一个映射把说话人1替换成真实姓名。映射关系可以手动配也可以根据第一轮发言的自我介绍自动推断。def group_by_speaker(result_detail): segments [] current_speaker None buffer [] for item in result_detail: speaker item[SpeakerId] if speaker ! current_speaker: if buffer: segments.append((current_speaker, .join(buffer))) current_speaker speaker buffer [item[FinalSentence]] else: buffer.append(item[FinalSentence]) if buffer: segments.append((current_speaker, .join(buffer))) return segments聚合之后文本的可读性提升了一大截。但还不够因为会议里有很多嗯那个就是说这类口语填充词还有大量重复表达直接放进纪要显得很啰嗦。5.3 口语化文本的清洗策略清洗这块我试过几种方案。最简单的规则清洗把常见的填充词用正则替换掉比如嗯啊那个就是说然后呢这些。规则清洗的好处是快、可控坏处是容易误伤比如然后在有些语境下是有实际意义的连接词。更进一步的方案是用大语言模型做摘要和改写。把聚合后的文本按段落喂给模型让它输出精简版。这个方案效果最好但要注意两点一是要控制输入长度长会议要分段处理二是要保留关键信息不能让模型把行动项、数字、人名这些关键内容摘要掉了。我的做法是混合策略先用规则清洗掉明显的填充词再用模型做段落级精简最后人工过一遍确认关键信息没丢。纯自动化的方案目前还做不到完全放心人工确认这一步省不掉但工作量已经从从头整理变成了检查校对。5.4 行动项和决议的自动提取会议纪要最有价值的部分是行动项和决议。这部分可以用关键词规则来初筛比如包含负责跟进下周之前完成决定确定这些词的句子大概率是行动项或决议。把这些句子单独抽出来放在纪要开头一目了然。ACTION_KEYWORDS [负责, 跟进, 完成, 截止, 下周, 明天, 决定, 确定, 结论] def extract_actions(segments): actions [] for speaker, text in segments: for sent in text.split(。): if any(kw in sent for kw in ACTION_KEYWORDS): actions.append(f[说话人{speaker}] {sent.strip()}) return actions这个规则肯定不完美会漏也会误判但作为初筛已经能覆盖大部分情况。剩下的靠人工补比从头找快得多。6. 实测中踩过的坑和应对办法6.1 说话人分离不准的几种情况说话人分离不是万能的实测下来有几种情况容易出错。多人同时说话时系统只能识别出一个说话人内容会混在一起。说话人音色接近时比如两个声音相似的男性可能会被识别成同一个人。说话人中途换位置比如从远处走到麦克风前音色特征变化可能被识别成两个人。应对办法录音时尽量用多个麦克风或者让每个人发言前先报一下名字。如果条件允许用带阵列麦克风的会议设备拾音和分离效果都会好很多。另外SpeakerNumber参数如果填得接近实际人数分离准确率会提升别偷懒填0。6.2 长音频超时与分段处理腾讯云录音文件识别对单个文件有时长限制具体以官方文档为准。如果会议超过这个时长需要先切分再分别识别。切分不能随便切最好在静音段切避免把一句话切成两半。用pydub做静音检测切分from pydub import AudioSegment from pydub.silence import split_on_silence audio AudioSegment.from_wav(meeting.wav) chunks split_on_silence( audio, min_silence_len700, silence_threshaudio.dBFS - 16, keep_silence300 )min_silence_len是静音段最短长度毫秒silence_thresh是静音判定阈值keep_silence是切分后保留的静音长度。这几个参数要根据实际录音调整没有万能值。切分后每段单独识别最后按时间顺序拼接结果。6.3 专业术语识别错误的修正每个团队都有自己的黑话通用模型不认识这些词识别出来就是错别字。解决办法是使用热词功能。腾讯云支持配置热词表把团队常用的专业术语、产品名、人名加进去识别时会优先匹配这些词。热词表通过API创建创建后拿到热词表ID在创建识别任务时通过HotwordId参数传入。热词不是越多越好太多会稀释效果建议控制在几百个以内只放真正高频且容易识别错的词。6.4 网络波动导致的任务失败异步任务偶尔会因为网络问题失败这时候不要慌先查任务状态里的错误信息。常见的失败原因包括音频URL失效、音频格式不支持、音频时长超限、账户余额不足。排查时按这个顺序过一遍基本能定位到问题。我的做法是在代码里加重试机制任务失败后自动重试一次重试前先检查URL是否还有效。如果连续失败两次就记录日志并通知人工处理不要无限重试。7. 整套流程的串联与自动化7.1 从录音到纪要的一键脚本把前面所有环节串起来就是一个完整的处理脚本输入音频文件自动转格式、上传、创建识别任务、轮询结果、聚合文本、清洗、提取行动项、生成Word文档。整个流程跑下来一小时会议的处理时间大概在10到15分钟其中大部分时间是等识别结果。def process_meeting(audio_path, output_path): # 1. 格式转换 wav_path convert_to_wav(audio_path) # 2. 上传获取URL audio_url upload_to_cos(wav_path) # 3. 创建识别任务 task_id create_task(audio_url) # 4. 等待结果 result wait_for_result(task_id) # 5. 聚合与清洗 segments group_by_speaker(result.ResultDetail) cleaned clean_segments(segments) # 6. 提取行动项 actions extract_actions(cleaned) # 7. 生成文档 generate_docx(cleaned, actions, output_path) return output_path7.2 定时任务与批量处理如果团队会议多可以把这个脚本做成定时任务监听某个文件夹有新录音就自动处理。或者做成一个简单的Web服务上传音频后返回纪要下载链接。这部分看团队的实际需求核心的识别逻辑是通用的。批量处理时要注意并发控制。同时提交太多识别任务可能触发频率限制建议加一个队列控制同时进行的任务数量。我的做法是最多同时跑3个任务其他的排队等待。7.3 纪要模板与格式规范生成的Word文档建议用固定模板包含几个部分会议基本信息时间、参会人、议题、行动项汇总放在最前面方便快速查看、讨论纪要按说话人聚合的正文、决议事项。模板固定下来后每次生成的纪要格式一致团队看起来也习惯。模板可以用python-docx定义把样式、字体、标题层级都设好生成时直接套用。这样出来的文档不用再手动调格式直接就能发出去。8. 一些实际使用中的体会这套东西我用了几个月最大的感受是语音识别解决的是转写问题不是理解问题。它能帮你把录音变成文字但哪些是重点、哪些是行动项、哪些需要跟进还是得靠人来判断。所以别指望完全自动化把它当成一个强大的助手而不是替代品。另外录音质量决定上限。再好的识别服务遇到糟糕的录音也无力回天。如果团队经常要开会做纪要建议在录音设备上投入一点一个几百块的会议麦克风带来的识别准确率提升比在软件层面折腾半天都管用。最后分享一个小技巧识别结果里的时间戳很有用。整理纪要时如果对某句话有疑问可以根据时间戳快速定位到录音的对应位置听一下原话确认。这个功能在核对关键数字和人名时特别方便比从头听录音快得多。