Multilingual Meeting Notes Generator：基于 AssemblyAI 与 LLM 的多语言会议纪要自动生成实战

Multilingual Meeting Notes Generator：基于 AssemblyAI 与 LLM 的多语言会议纪要自动生成实战

【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub

导读

本教程围绕multilingual-meeting-notes-generator项目展开，讲解如何构建一个自动检测会议口语语种、输出英文结构化纪要（含议题、关键决策、下一步）、发言人级分析与行动项提取的多语言会议纪要生成器。读完本文你将掌握：AssemblyAI 语音转写与说话人分离（speaker diarization）的配置方法、以任意多语言 LLM 驱动结构化摘要与行动项抽取的 Prompt 工程要点，以及用 Streamlit 将整套流水线封装为可直接运行的 Web 应用的全过程。

源码位置：app.py，核心服务在 src/services 目录，配置依赖见 pyproject.toml。

一、整体工作流程：从音频到完整会议纪要

项目以**流水线（pipeline）**方式串联多个能力，正如 README 的 How It Works 所述，整个流程分为五步：

1. 音频输入：用户上传会议录音文件；
2. 语言检测：AssemblyAI 自动检测会议使用语言（转写方向支持 99 种语言）；
3. 语音转写：高质量转写并开启说话人分离（diarization）以区分不同发言人；
4. 智能处理：由任意的多语言 LLM 完成摘要、发言人识别与行动项提取；
5. 结果输出：综合生成英文摘要、发言人分析、行动项与完整转写文本。

这套流水线在源码中由 MeetingProcessor 统一编排：它持有两个子服务，转写交给AudioTranscriber（AssemblyAI），语义分析交给TextAnalyzer（多语言 LLM），最终把各环节结果封装为一个 MeetingResult 数据对象交给前端展示。其关键流程如下：

音频文件 │ AudioTranscriber（AssemblyAI） │ ① language_detection=True → 自动检测语种 │ ② speaker_labels=True → 说话人分离 ▼ 全量转写 + 分段(utterances) + 说话人 + 语种 │ TextAnalyzer（LLM） │ ① identify_speaker_names → 给说话人分配真实姓名 │ ② generate_meeting_summary → 英文结构化摘要 │ ③ extract_action_items → 提取行动项 │ ④ generate_meeting_title → 生成会议标题 ▼ MeetingResult（标题/摘要/说话人/分段/行动项/语种/时长） │ Streamlit UI（ui_components + export） ▼ 英文纪要 + 说话人分析 + 行动项 + 完整转写 + Markdown 导出

值得注意的健壮性设计：process_meeting_audio在转写内容过短或分段为空时主动抛错；而 LLM 分析（说话人名识别、摘要、行动项、标题）则各自包在try/except中，单项失败只打印 Warning 并走兜底值，不会中断整场处理——例如摘要失败时返回提示文案、标题失败时自动回退为 "Meeting - 日期"（见 audio_processor.py）。

二、环境准备与依赖安装

1. 准备 API Key

参照项目根目录的 env_example.txt，在项目根目录创建.env文件并填入两组密钥（README 只写了 AssemblyAI Key，但实际运行还需要一个 LLM 的 Key，见源码与 UI 校验逻辑）：

ASSEMBLYAI_API_KEY=<your_assemblyai_api_key> OPENAI_API_KEY=<your_openai_api_key>

其中ASSEMBLYAI_API_KEY用于语音转写与说话人分离；OPENAI_API_KEY由文本分析服务使用（默认模型gpt-4o，见 text_analyzer.py）。也可以改用任意多语言 LLM——项目通过 OpenAI 兼容接口调用，凡是支持 Chat Completions 接口且具备多语言能力的模型均可按此模式替换。

2. 安装依赖

项目使用 uv 管理依赖（见 pyproject.toml），Python 要求>=3.9，核心依赖包括：

• streamlit>=1.49.1—— Web 界面
• assemblyai>=0.21.0—— 语音转写/语言检测/说话人分离
• openai>=1.99.9—— 多语言 LLM 分析与摘要
• python-dotenv>=1.0.0—— 加载.env

执行以下命令即可一键同步环境：

uv sync

三、运行应用

安装完成后，运行下面命令启动 Streamlit 应用：

uv run streamlit run app.py

启动后浏览器会打开交互界面，app.py从上传音频到纪要生成再到导出 Markdown 的完整闭环均由该页面承载。

四、界面使用指南

README 的 Usage 章节把操作分为四个步骤，结合 app.py 的侧边栏实现可以拆得更细：

1. 配置 API Key：在左侧Configuration区域输入 AssemblyAI API Key 与 OpenAI API Key（密码框形式）。代码会先做基础格式校验——两把 Key 都不能为空且长度 ≥ 20 字符（见 app.py 中 _validate_api_keys），不合法会提示Invalid API key format。
2. 上传音频：在Audio Input区域上传会议录音，支持mp3 / wav / m4a / mp4 / webm / flac六种格式（注意比 README 列举的四种更多）。上传文件会被写入临时文件后再交给处理管线，处理完毕自动删除并执行垃圾回收（见 app.py 中 _save_uploaded_file / _cleanup_temp_file）。
3. 开始处理：点击🚀 Start Processing，处理全程有状态提示（Processing… → Processing complete!），失败则显示具体错误原因。
4. 查看结果：主区域按序展示以下五块内容（渲染逻辑见 ui_components.py）：
   • 顶部指标卡：会议时长、说话人数、行动项数量；
   • Meeting Summary：按 Topics Discussed / Key Decisions / Next Steps 三类渲染英文纪要；
   • Speaker Diarization：每位说话人的发言时长与词数，并可展开查看其全部发言片段；
   • Action Items：按负责人分组展示行动项（含截止时间与优先级），无归属的归入 Unassigned；
   • Meeting Transcript 与 Transcript Statistics：可开关时间戳/置信度的分段转写，附总分段数、总词数、平均置信度、独立说话人数。
5. 下载报告：点击📥 Download as Markdown即可将完整纪要导出，文件名自动带上处理时间（如meeting_notes_20260908_1030.md），内容包含标题、处理时间、时长、纪要、说话人明细、行动项以及带时间戳和置信度的完整转写（见 app.py 中 _generate_markdown_export）。

仓库还自带一段示例音频 audio/sample-audio-meeting.mp3，可用于快速体验完整流程。

五、源码解析：AssemblyAI 转写与语言检测配置

转写服务 transcriber.py 直接使用官方 SDK：构造时通过aai.settings.api_key注入密钥并创建aai.Transcriber()（见 L13-L16）。真正核心的是TranscriptionConfig配置项（见 L22-L33）：

配置参数	取值	作用说明
speaker_labels	True	开启说话人分离，让返回结果带 speaker 标识
language_detection	True	开启自动语言检测，无需预知语种
language_detection_options.expected_languages	["en","es","fr","de","it","pt","hi","zh","ja","ko"]	给出优先候选语种，提高检出准确率
language_detection_options.fallback_language	"auto"	候选之外仍自动兜底识别
punctuate	True	自动加标点
format_text	True	输出规范化文本（大小写等）
dual_channel	False	不按双声道分离
webhook_url	None	关闭异步回调，采用轮询方式

AssemblyAI 官方能力上，语言检测与转写覆盖 99 种语言，说话人分离覆盖 95 种语言，因此英文、西班牙语、法语、德语、意大利语、葡萄牙语、俄语、日语、韩语、中文、阿拉伯语、印地语等常见语种都落在支持范围内（README 的 Supported Languages 章节有专门说明）。

请求发出后采用轮询等待：最多等待 300 秒、每 2 秒通过transcript.id拉取一次状态，直到completed或error；超时会抛出 "Transcription timeout"。转写失败时还会根据错误信息中是否出现speaker/language关键词，给出针对性的排查提示（音频质量与说话人区分度、语种是否受支持），见 L37-L57。

结果解析部分有四处关键处理：

• 分段提取_extract_segments：把transcript.utterances逐条映射为TranscriptSegment（开始/结束毫秒时间戳、speaker_id、文本、置信度），并按开始时间排序保证时序（L86-L109）；
• 说话人统计_extract_speakers：对每个 speaker_id 汇总发言时长（毫秒转秒）与词数（L111-L136）；
• 语种回读_get_detected_language：优先从json_response的language_code字段取语言码，回退字段取不到时默认"en"（L138-L153）；
• 时长获取get_transcript_duration：优先读audio_duration，否则从 json 响应取，再不行由MeetingProcessor用最后一段的结束时间换算（毫秒→秒）兜底（transcriber.py L76-L84）。

六、源码解析：多语言 LLM 的四类文本分析

文本分析服务 text_analyzer.py 内置gpt-4o，通过 Chat Completions 完成四项子任务，且每个任务都有明确的英文输出约束，这是"多语言输入 → 统一英文纪要"的核心实现：

1. 生成结构化英文摘要

generate_meeting_summary使用前 3000 字符，要求 LLM无论原文是什么语言都输出英文，并返回严格 JSON（topics_discussed/key_decisions/next_steps三个数组），明确禁止把具体任务分派写进摘要（例如不要出现 "Juan will work on…"），随后格式化为三段要点文本（L17-L104）。请求参数：max_tokens=800、temperature=0.1，以保证低随机、格式稳定。

2. 提取行动项

extract_action_items使用前 2000 字符，要求返回 JSON 数组，每个元素含description / assignee / due_date / priority(high|medium|low)四个字段（L106-L178）。Prompt 中的关键语言规则是：行动描述必须译为英文，但人名、公司名、技术术语保留原文；同时引导模型捕捉任务指派、后续跟进、截止日期、参会承诺、需跟进决策等六类信号。参数max_tokens=500、temperature=0.2。

3. 识别说话人真实姓名

identify_speaker_names使用前 1500 字符，把 AssemblyAI 返回的A、B、C…这类 speaker ID 映射为真实姓名（L180-L277）。Prompt 内置了一套分析策略：先找主持人（通常开场/收尾、点名他人，如 "Juan, sigues tú"），再根据"点名后谁接着发言"来建立映射（A先被叫到且随后发言，则A很可能就是被叫到的名字）；不确定时回退为Speaker X，参数max_tokens=300、temperature=0.1。

4. 生成会议标题

generate_meeting_title使用前 1000 字符，只返回 3–8 个词的标题式短语（Title Case），例如 "Weekly Team Standup"，参数max_tokens=20、temperature=0.3（L282-L317）。

容错细节：四类请求都会剥掉模型可能输出的 ```json 代码围栏，再对 JSON 做json.loads解析；失败时先用正则兜底抽取 JSON 片段，仍失败才走默认值/返回空，最大程度保证整条流水线不因一次 JSON 解析异常而中断。

七、数据模型一览

所有中间与最终结果都由 data_models.py 中的 dataclass 承载，便于前端统一消费：

• Speaker：id、name、speaking_time（秒）、word_count；
• TranscriptSegment：start_time/end_time（毫秒）、speaker_id、text、confidence（默认 0.8）；
• ActionItem：description、assignee（可空）、due_date（可空）、priority（默认"medium"）；
• MeetingResult：聚合标题、摘要、说话人、分段、行动项、语种、时长与处理时间，并通过total_words、avg_confidence、unique_speakers_count三个计算属性直接给出转写统计，供指标卡与导出文件使用。

八、局限性与扩展建议

从当前仓库实现出发，以下几点是继续使用时需要注意的前提与可扩展方向：

• 依赖外部 API：转写依赖 AssemblyAI，文本分析依赖 OpenAI 兼容服务，两者都需要真实 Key 且按调用量计费；把TextAnalyzer的client/model替换为任意多语言 LLM（本地部署模型或兼容网关）即可实现完全本地化的分析链路；
• 长文本截断策略：摘要/行动项/说话人识别/标题分别只取前 3000/2000/1500/1000 字符，超长会议的中后段内容可能未被语义分析覆盖——若会议较长，可考虑先分段再聚合（map-reduce）的方式改进；
• 语言回退默认值：检测不到语种时默认"en"，在 UI 上不会明显报错，但会影响后续统计的语种语义；
• 说话人姓名识别依赖点名模式：Prompt 对"点名后接话"的会议模式效果较好，对无点名的自由讨论可能部分 speaker 落回Speaker X兜底，属预期行为。

结语

结合 README 与仓库源码可以看到，这个多语言会议纪要生成器把"语音转写 + 说话人分离 + 多语言 LLM 文本分析"这条成熟技术链组装成了一个开箱即用的 Streamlit 应用：AssemblyAI 负责把任意语种的口语转为带说话人标签的文本，LLM 负责统一产出英文纪要、真实姓名映射与可执行的行动项清单。对于团队有多语言会议纪要需求、或想上手打通"ASR → LLM 结构化抽取 → Web 交付"整条链路的开发者而言，这份代码是很好的可运行范本。

【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub