做视频课程摘要系统这件事，圈里人应该都有同感：课程不是短视频，一段 40 分钟的录播课，要准确知道老师到底讲了哪些核心知识点，纯靠人工啃既慢又不稳定。我去年帮内部团队搭过一套自动摘要与知识点提取的流水线，核心链路说穿了就是三句话：先用 ASR 把语音转成带时间戳的文本，再把文本丢给 LLM 按结构化模板做摘要和知识点抽取，最后落成课程目录、速读笔记和知识点定位索引。这套方案在工程上不算难，但坑不少，尤其是长视频分段、prompt 泛化、时间戳对齐和成本控制这几块，今天就把我实际跑通的方案、参数和踩过的坑完整写出来，给想搭类似能力的同学一个可以直接抄的参考。
这套组合拳适合谁？如果你在做在线教育、企业内部培训视频库、知识库问答前置处理，或者单纯想让录播课变成“可搜索的知识资产”，那这条 ASR + LLM 流水线基本能覆盖你 80% 的需求。下面我从整体设计开始讲，不会只给结论，每个选型都会解释为什么这样做。
1. 整体设计：为什么要把 ASR 和 LLM 串成流水线
1.1 视频课程摘要的痛点
视频课程和普通文档最大的区别在于，信息是线性、口语化的。老师讲课时会有停顿、重复、口头禅，还会随手在黑板上写公式然后口头解释。如果只截关键帧或者只做文字稿校对，会丢掉很大一部分有价值的信息。更现实的问题是，课程往往按章节推进，每个章节内又有多个知识点，这些知识点之间的层次关系和依赖关系很难用传统的关键词提取来解决。
我最早试过直接用 TF-IDF、TextRank 这类统计方法做摘要，效果在干净文本上尚可，但放到 ASR 转录出来的口语文本上就很惨：大量重复词拉高权重，真正承上启下的逻辑连接词被忽略，更不用说“这个”“那个”等指代导致的语义断裂。后来也试过基于规则抽取“章节标题+加粗文字”，但视频课程里根本没有固定的排版信息，规则怎么都覆盖不全。这些尝试给我一个启发：如果不能把语音中的语义信息先完整解开，后续任何摘要和知识点抽取都是地基不稳。
1.2 流水线的核心链路与模块划分
我最终落地的流水线拆成四个模块：输入归整、ASR 转写、LLM 提取、输出结构化。输入归整负责从视频文件抽帧、抽音频，并做格式标准化；ASR 模块输出带时间戳的句子级文本；LLM 模块消费这些文本，生成多级摘要和知识点列表；最后的输出模块统一封装成 JSON，提供给前端展示或知识库索引。
这样做的好处是模块间用数据契约解耦。ASR 不关心后面是摘要还是翻译，LLM 也不关心音频怎么来的。每次升级 ASR 引擎或者换更聪明的 LLM，只动单一模块就行，不需要重写整条链路。另外，每个模块都能独立验证：ASR 可以用字错误率（CER）评估，LLM 提取结果可以用人工抽检命中率评估，哪一环出了问题都能快速定位。
1.3 为什么是 ASR + LLM 而不是端到端
有人会问，现在多模态大模型不是能直接看视频生成摘要吗，为什么还要绕一道 ASR？我自己的实测结论是：直接丢视频给多模态模型，先不说成本，光是上下文窗口就撑不住。一节 40 分钟的课，画面信息量很大，但核心语义几乎全在语音里。如果把音频波形、关键帧和语音通通塞给模型，很容易出现“看完了但没抓住重点”的现象，而且无法做到精确到秒的知识点定位。ASR 先把语音转成文本，等于把问题从“理解视频”降维成“理解长文本”，这条路成熟度高、可解释性强，出问题时也好排查。端到端方案可以作为补充，但现阶段做生产系统，ASR + LLM 流水线是最稳的架构。
2. ASR 模块：从音频到文本的工程落地
2.1 音频前处理：分辨率、降采样与分段策略
ASR 对音频格式很敏感，不能直接把 MP4 丢给识别引擎。我这边统一用 ffmpeg 把音轨抽出来转成 16kHz 单声道 WAV，再根据 ASR 引擎要求做分帧处理。为什么要 16kHz？大多数开源语音识别模型（比如 Whisper 系）是在 16kHz 采样率下训练的，直接用 44.1kHz 音频喂进去，模型内部也会重采样，但如果你自己先转好，可以避免很多诡异的重采样伪影。
分段策略是 ASR 模块里最容易影响准确率的一步。整段音频一次性送进模型，在长视频场景下几乎必超时或爆显存。我按静音检测（VAD）切分，并设置最大分段时长，比如 60 秒一段，带 5 秒重叠。这里要注意，重叠不是为了效果，而是为了给后续 LLM 合并分段文本时保留上下文衔接。纯按固定时长硬切会在句中被切断，导致“神经网络”变成“神经网 + 络”，后面摘要里出现莫名其妙的话。所以我的做法是：先用 silero-vad 做端点检测，在静音处切，同时保留一个最大时长兜底，如果 VAD 长时间检测不到静音，就在句号、停顿处强制切。
ffmpeg -i course.mp4 -vn -ac 1 -ar 16000 -f wav audio.wav2.2 ASR 引擎选型对比
我测试过三套方案：Whisper 系开源模型、云厂商转写 API、以及基于汉语普通话优化的开源模型。结论是，如果团队有 GPU 资源且重视成本，faster-whisper 是目前性价比最高的选择。它把原始 Whisper 的推理过程做了优化，在同等精度下速度快 3 到 4 倍，显存占用也更低。我用的是 large-v3 模型，配合 int8 量化，在单张 24G 显存的卡上处理一小时音频大约需要 12 到 15 分钟，这个速度对离线流水线完全够用。
云厂商 API 的优势是省运维、并发高，且对中文口语、专有名词的泛化通常好一些，但成本会随调用时长线性上涨，数据也要过一遍外部服务，对不少团队来说合规环节会卡住。我的建议是：初期验证直接用云端 API 跑通全链路，等数据量上来了再迁到开源模型，两个模块的接口设计成相同的文本输出结构，切换成本可以压到很小。
| 对比项 | faster-whisper 开源 | 云厂商 ASR |
|---|---|---|
| 部署成本 | 需 GPU/内存资源 | 按量付费，零运维 |
| 中文效果 | 良好，专有名词需热词表 | 较好，可定制热词 |
| 数据隐私 | 数据不出内网 | 依赖外部服务 |
| 批量处理 | 排队自控 | 并发配额限制 |
| 延迟 | 离线批处理为主 | 实时性更好 |
2.3 文本后处理：时间戳、说话人与清洗
ASR 输出如果不能跟视频时间轴对应起来，那后面做出的知识点定位就是假的。faster-whisper 的转录结果会给出每个片段的 start/end 时间戳，我一般把输出切成“句子级”片段，然后保存成 JSON 或 SRT 格式。这里有个细节：如果后续要做知识点点击跳转到视频对应位置，时间戳就必须保留到句子粒度，而不是段落粒度。用户看到“梯度下降法的三种变体”这个知识点时，最好能直接跳转到老师说到这个概念的那句话。
中文 ASR 转写文本还有个清洗问题。模型会把“嗯”“啊”这些语气词转成文字，也会把“3 个”写成“三 个”。我的处理流程是：用规则过滤语气词，同时保留停用词表中对语义有作用的否定词和逻辑连接词，再把数字做归一化。千万别小看这一步，不干净的口语文本直接进 LLM，你会发现摘要里到处都是“然后然后”。
3. LLM 摘要与知识点提取：Prompt 设计与结构化输出
3.1 摘要粒度设计：整体摘要、章节摘要与知识点级
LLM 不是一把梭直接生成摘要就行，粒度必须分开。我的数据模型里分三级：课程级摘要、章节级摘要、知识点条目。课程级摘要面向用户快速了解这门课讲了什么，一般控制在 200 到 300 字；章节级摘要对应 ASR 分段或视频原有章节，用于目录导航；知识点条目则是更细的原子信息，每条包含知识点名称、相关原文引用、出现时间点和一句话解释。
为什么这么分？如果只生成一个大摘要，用户在检索时无法快速落到具体位置；如果只有知识点列表，又缺少宏观概览。三级结构最实用。实际实现时，我会让 LLM 先生成章节级摘要，再基于章节摘要和知识点条目汇总成课程级摘要，这样比直接让 LLM 跨几千字生成摘要更稳定，也更省钱。
3.2 Prompt 模板与 JSON 输出约束
Prompt 设计是整个 LLM 模块最值得花时间的部分。我用的是“角色设定 + 任务分解 + 输出约束”三段式模板。角色设定会让模型以“资深课程编辑”的身份处理内容，任务分解把摘要、知识点抽取分成明确的子任务，输出约束则强制模型生成合法 JSON，而不是自由文本。
{ "course_summary": "课程整体内容的概要说明", "chapters": [ { "chapter_id": 1, "title": "章节标题", "summary": "章节摘要", "knowledge_points": [ { "name": "知识点名称", "start_sec": 120, "end_sec": 245, "evidence": "原文中的关键句", "explanation": "一句话解释" } ] } ] }为了让模型稳定输出 JSON，我会在 prompt 末尾显式加一句“只输出 JSON，不要输出 Markdown 或额外解释”。同时把 JSON Schema 直接写在模板里，配合 LLM 的 response_format 参数（如果后端支持）一起用。实测下来，结构完整的输出率能从 60% 提到 95% 以上，剩下 5% 靠重试也能救回来。
3.3 长文本分段与合并策略
ASR 转出来的长课程文本动辄上万字，直接塞进 LLM 上下文基本都会爆。我采用的方案是“分段落 + 层次化合并”：先把每个 ASR 分段的文本交给 LLM 做局部摘要和知识点抽取，再把这些局部结果合并成完整章节的处理单元，最后做一轮整体一致性修正。这个过程类似在工程中常见的 map-reduce，map 阶段做局部提炼，reduce 阶段做全局整合。
分段合并时要留意重叠区间的去重。我在 ASR 分段时留了 5 秒重叠，在 LLM 阶段就要通过时间戳去重，比如后一段的前 5 秒和前一段的后 5 秒是重复内容，生成知识点时要按照前一段的时间戳为准。另外，合并时我会显式把“章节编号”和“上下文主题”传给模型，让模型知道当前文本属于课程的第几部分，避免模型把前一章的内容混进来。
4. 流水线编排与工程化细节
4.1 任务队列与并发控制
批处理视频课程时，我会把每个视频定义成一个任务，任务状态包括 pending、processing、succeeded、failed。落地的队列方案就是 Redis + Celery / 或轻量一点的 arq，看团队熟悉哪个就用哪个。队列的好处是能控制并发度，防止 ASR 任务把 GPU 显存占满，也能防止 LLM API 并发太高触发限流。
在并发控制上有个容易被忽视的点：ASR 吃的是 GPU，LLM 吃的是 token 配额 / API 并发，两者瓶颈完全不同，所以不能共用一套并发数配置。我把 ASR worker 并发数设为 GPU 数量的 1 到 2 倍，LLM worker 则根据 API 提供的 RPM 和 TPM 来限制。一个任务在 ASR 排队时并不占用 LLM 的配额，反而能让整条流水线的资源利用率更平滑。首次跑大批量课程时，建议先拿 3 到 5 个视频“预热”，观察峰值占用，再确定最终并发数。
4.2 失败重试与容错
长任务最怕跑到一半失败，尤其是在 LLM 调用阶段，经常会出现偶发的网络超时或返回内容不合法。我的策略是分错误类型处理：ASR 失败大多是显存不足或音频文件损坏，这类错误重试意义不大，直接记录失败原因并标记人工处理；LLM 调用失败则区分限流、超时、输出格式错误，分别做指数退避重试和基于 JSON 修复的重试。
对于 LLM 输出非法 JSON 的情况，我会写一个简单的修复逻辑：先尝试提取第一个{到最后一个}之间的内容，再尝试用正则修正常见的转义问题，最后实在不行才重新调用模型。重试次数默认 3 次，超过就直接把任务标记为“需人工复核”，避免无限循环把账单跑爆。
4.3 缓存、增量更新与效果评估
如果同一门课程有多个版本，或者用户反复请求摘要，重复调用 ASR 和 LLM 是非常浪费的。我给流水线加了两级缓存：文本缓存和摘要缓存。ASR 转写结果按视频文件的 MD5 做 key 缓存，只要视频没变就直接复用文本；摘要结果则按（文本 hash + prompt 版本 + 模型版本）做 key，换 prompt 或模型后自动失效。这样既能快速迭代 prompt，又不会让历史视频全部重跑。
效果评估是很多团队容易跳过的一环。我在内部会抽 10% 的课程做人工评测，主要看三个指标：摘要事实正确率、知识点覆盖率、时间戳定位准确率。不要只看模型生成内容读起来通顺不通顺，因为 LLM 很容易生成“看起来没问题但实际错了”的内容。知识点的每个 evidence 都要能回溯到原文才算有效，这一点我会在评测表里单独打勾。
5. 常见问题与排查实录
5.1 中文专有名词识别错误
视频课程里充满算法名、论文名、英文缩写，比如“Transformer”“ResNet”“对比学习”等。ASR 默认模型没有针对你的专属词汇优化，转写时经常把这些词变成同音字。解决方案是给 ASR 配热词表。faster-whisper 的初始提示词可以塞入专有名词列表，但要注意热词表不能太长，否则会引入错误替换。我的经验是：先从课程大纲和 PPT 文字里抓取高频术语，形成 100 到 300 个词的热词表，定期根据 ASR 错误分析补充。
5.2 LLM 摘要发散
有时候模型生成的摘要会过度概括，甚至把老师没讲过的内容脑补出来。这个问题我排查下来的主要原因是分段太小，上下文清洗过度，或者 prompt 里没有约束“只能基于原文”。解法是在 prompt 里加入“不要推测，不要使用原文未出现的知识点”，同时把课程标题、章节列表作为额外上下文塞给模型。如果你发现改 prompt 之后依然发散，可以检查一下是否在前处理阶段把“不是”“无法”这类否定词过滤掉了，这种操作会严重改变原意。
5.3 时间戳错位导致知识点无法定位
时间戳错位是工程上最常被忽略、一旦爆发又最严重的 bug。现象是知识点显示在第 5 分钟，点击跳到视频却已经讲到了下一节。通常原因是 ASR 切分时时间戳没有按原始音频偏移量加上分段起始时间，导致所有片段的时间戳都从 0 开始了。我踩过这个坑后，给每段 ASR 处理单元都记录一个 base_offset，所有句子时间戳在合并输出时统一加上 base_offset，并在最终 JSON 里做一次单调性校验，如果后一个片段的结束时间大于前一个片段的开始时间则不通过。
5.4 成本与配额控制：token 用量和并发配额
LLM 的成本大头不在摘要生成，而在重试和越权长输出。有一次我发现单节课的 token 消耗比预期高了 3 倍，排查后才发现是两个原因：一是模型生成知识点时把“evidence”字段写成了完整段落，二是因为上下文窗口塞入了整个转录全文而不是分段摘要。后来我在 prompt 里显式限制每个字段的最大长度，并在业务侧对知识点的 evidence 做截断，成本立刻降下来了。如果你用云 API，强烈建议给每个任务设置 token 上限，并开启 streaming，这样在模型超时前至少能拿到部分结果。
5.5 一个可以快速复现的最小骨架
最后分享一个最小实现思路，方便你自己验证。整个流水线你不需要一开始就搞复杂，先用 Python 脚本串起来即可：faster-whisper 转写一段 5 分钟的课程片段，送到 LLM 的公开 API，prompt 里要求返回上面那个 JSON 结构，然后把 JSON 存成文件。跑通这一个最小闭环之后，再加入队列、缓存和监控。我实际验证过，这个最小骨架从零到跑通大约只需要两天，但后面打磨 prompt 和处理边界情况才是真正花时间的部分。
个人经验来讲，把 ASR 和 LLM 接起来不难，难的是让输出的摘要结构稳定、可追溯、能定位。我建议你在设计 JSON 结构时就预留好 “evidence” 和 “start_sec”，哪怕第一版不展示，也要先存上。后面做知识库检索、视频跳转、问答增强，靠的都是当时留下的这些元数据。我过去返工最多的一版就是因为只存了摘要文本没存时间戳，导致后面所有功能都补得很痛苦。如果你正在设计这套流水线，先把时间戳和证据字段刻进数据结构里，绝对不亏。
