最近两年在线课程和企业培训视频越来越多很多团队仓库里躺着上千小时的录播课真正能被搜到、被二次利用的内容却少得可怜。我接手过一个内部培训平台库里压了三千多节课大部分用户只能靠标题猜内容想看一个具体知识点就得从头拖进度条。这个痛点催生了一套 AI 视频课程自动摘要与知识点提取流水线视频送进去后台走 ASR自动语音识别转写文本再用 LLM大语言模型抽取摘要和结构化知识点最后落到搜索和知识库。整套链路打通之后一节 45 分钟的课大约 3 到 5 分钟就能产出摘要和知识点清单检索效率提升非常明显。这篇文章复盘整套流水线的设计思路、关键技术选型、踩过的坑以及一份可以直接参考的工程方案。适合正在做网课平台、培训系统、知识库建设或者音视频内容智能化的朋友尤其对如何从零搭一条靠谱的 ASR LLM 处理链路感兴趣的人应该能少走不少弯路。1. 项目概述与整体架构设计1.1 需求定位为什么课程摘要必须做成流水线刚接到需求时甲方只提了一句想给视频课自动生成摘要和知识点。听起来很简单实际上手才发现里面全是细节视频时长差异巨大从 5 分钟微课到 3 小时直播回放都有口音五花八门术语密集课程之间表述差异大有的老师喜欢念 PPT有的喜欢脱稿讲案例。更麻烦的是摘要和知识点最终要进入搜索系统必须带时间戳、章节、标签能够被精准定位而不是生成一段看起来不错的总结就完事。这决定了它不能靠单一脚本跑一把必须设计成一条可复现、可监控、可断点续跑的流水线。我最初的方案是先拿到音轨ASR 转写成带时间戳的文本清洗后按章节切分再分批交给 LLM 生成章节摘要、全局摘要和知识点列表最后把结构化结果写回知识库。每一步都有中间产物落盘任何一个环节出错只需要重跑该环节不需要整个视频重新处理。这点在后来的多轮调优中帮了大忙。另一个关键决策是不要把 ASR 和 LLM 耦合。最初我试过一句话一个接口同时转写和总结的做法效果不稳定而且排障非常痛苦。后来把两个阶段彻底解耦中间用文本文件传递两边可以各自升级模型、单独测速、单独监控。阶段性产物还能用于回归测试——比如换了一个 ASR 模型后可以拿同一批文本比对下游摘要质量有没有变化这比黑盒整体重跑靠谱得多。1.2 整体流水线从视频文件到知识点的四段旅程整条流水线按功能可以拆成四段预处理与转写、文本清洗与切分、LLM 结构化抽取、入库与检索。每一段都可以独立运行也可以由调度器串起来跑。第一段负责把视频变成文本。输入是 mp4、flv、m3u8 这类格式先用 ffmpeg 抽取音轨降低采样率、转成单声道 wav再做 ASR。我推荐在转写前跑一遍静音检测VAD目的是把长音频切成适合送入模型的分片同时保留原始时间戳后面知识点定位全靠它。第二段做文本精修。ASR 出来的文本通常有大量口语词、重复语气词、无意义填充词需要过滤同时要把分片文本按演讲语义重新合并成段落或小节生成带时间范围的章节块。第三段是核心把章节块分批送给 LLM产出章节摘要、全局摘要、知识点 JSON 数组。最后一段把结果向量化并写入搜索服务前端拿到的是带时间戳的知识点列表和摘要卡片。这条链路的顺序是有讲究的。文本精修必须放在 ASR 之后、LLM 之前因为 LLM 对噪声非常敏感ASR 输出里的嗯啊那个这个看起来无害却会让摘要越发发散也会污染知识点名称。文本切分也必须发生在 LLM 之前否则超长输入会让模型在长文本上注意力涣散首尾信息丢失摘要质量断崖式下降。这么设计之后整体任务就从一个大 prompt 吃掉全部文本变成了若干个小而明确的任务每一步的输出都稳定、可控、可检查。2. ASR 语音识别方案选型与工程适配2.1 转写引擎选型Whisper 还是 FunASRASR 是整个流水线的地基转写文本一旦质量差后续 LLM 再强也救不回来。工程落地时我主要对比了 OpenAI Whisper 和阿里 FunASR 两个方向。Whisper 的优势是通用性强中英文和多种语言都支持标点恢复能力好对带口音的普通话容忍度也不错劣势是显存占用偏高原始开源版本在 CPU 上较慢。FunASR 的优势是中文场景表现突出推理速度更快有 Paraformer 系列轻量模型部署成本更低尤其适合纯中文课程。我的真实选择是主力用 faster-whisper而不是开箱即用的 openai-whisper 包。faster-whisper 基于 CTranslate2 重写推理速度能快 3 到 5 倍显存占用也更低。我们内部测试了一节 45 分钟的 PPT 录屏课在 T4 GPU 上 large-v3 模型大约 4 分钟跑完而原版 Whisper 接近 15 分钟。FunASR 在中文课堂上确实更快但它在时间戳精度和标点分段上不如 Whisper 细致而后端知识点定位偏偏特别依赖这两点所以最终选了 faster-whisper。如果你手里全是中文课程、对时间戳要求不高选 FunASR 完全合理。不同模型档次也要选对。我只推荐 large-v3 或者 medium不推荐小模型。小模型在通用术语和口音场景下的错字率明显升高错字到了 LLM 阶段会被一本正经地加工成错误知识点这种错误特别难排查。与其在清洗环节拼命补词表不如在 ASR 阶段就上更大模型这是性价比最高的投入。2.2 长音频分片策略静音切分、定长切分还是章节切分ASR 模型都有上下文窗口限制直接喂整段两小时音频通常不现实分片是绕不开的环节。我试过三种策略静音切分、定长切分、章节切分。静音切分是最自然的方式用 VAD 检测出静音段把长音频切成几十秒到几分钟不等的片段。优点是每段语义相对完整不会从一句话中间切断缺点是长度不均匀容易切出大量短片段处理效率偏低而且如果课程背景音乐一直不停VAD 可能失效。定长切分是最稳妥的做法固定 30 秒一刀重叠 2 秒代码最简单GPU 利用率也最高缺点是真的会从句子中间切断导致某些词被截成两半。章节切分更适合已有章节标记的视频比如带章节标题的慕课按章节边界切语义最干净但对没有章节信息的视频无效。我的最终方案是组合拳先跑 VAD把音频切成长度在 20 到 120 秒之间的大片段如果某个片段超过 30 秒再按 30 秒窗口重叠 3 秒定长切分。这样既保证了大多数片段语义相对完整又避免了 VAD 消极情况下的长文本失活。分片的元数据里要记录每个子片段相对原音频的偏移量这一步很关键因为后面重建完整时间戳、给知识点定位时全依赖它。我在实际项目里踩过一次坑最初没记录偏移量LLM 给出的知识点时间戳全部错位用户点击跳转总停在错误位置返工成本很高。2.3 提高转写质量的经验性参数Whisper 默认参数能出结果但想达到课程摘要可用的标准需要针对场景调几个参数。首先是 language在纯中文课程里直接固定为 zh不要让模型自动检测。自动检测在高质量音频上问题不大但遇到课程开头有英文歌、片头宣传语时容易出现语言切换混乱导致整段中文转写变成半中半英。其次是 temperature推理时固定为 0 或者极低值转写任务不希望有任何随机性高温度会让同一段音频多次转写出现不同词下游摘要就跟着抖动。我把 temperature 设为 0 之后重跑同一段音频结果完全一致这对回归测试非常有价值。initial_prompt 也是提升中文转写准确率的利器。Whisper 虽然支持中文但对特定领域专有名词、人名、模型名、产品名经常写错。我维护了一个课程热词表比如将Transformer注意力机制反向传播这些词以自然语言形式写进 initial_prompt转写准确率立刻上一个台阶。另外我建议开启 word_timestamps 选项。transcript 级别的时间戳只能定位到句子开启词级时间戳后才可能把知识点精确到某句话甚至某个词这对视频内跳转体验很重要。还有一点容易被忽略音频前处理。输入 Whisper 之前先用 ffmpeg 把音频统一转成 16kHz 单声道 wav。课程录音设备千奇百怪有的采样率 44.1kHz有的是双声道甚至带环绕直接喂原始格式会徒增计算量还可能引入无声通道的噪声。ffmpeg 一行命令解决的问题不要在模型侧硬扛。3. LLM 摘要与知识点提取的关键实现3.1 为什么不能把全部转写文本直接塞给 LLM转写完成后看起来最自然的做法是把整篇文本和一个大 prompt 一起发给 LLM让它总结一下。我最早也是这么干的结果很惨一节 90 分钟的课程转写出来将近 3 万字主流模型的上下文窗口勉强装得下但输出质量完全不可控。模型容易抓住开头和结尾的内容做文章中段的重要内容经常被丢掉知识点列表东拼西凑甚至编造原文没有的细节。原因在于长文本上的注意力分布是有限的。上下文窗口再大模型在实际生成时也无法均匀关注每个 token中间段落的信息容易被稀释。更现实的问题是单次请求处理 3 万字会非常慢token 成本高且一旦超时就是全盘失败。正确思路是分治法先在章节块粒度上做局部摘要和局部知识点提取再做全局合并。这个思路本质上就是经典 Map-ReduceMap 阶段每个章节独立总结Reduce 阶段把所有章节摘要汇总成全局摘要知识点列表直接拼接去重。分块粒度也需要拿捏。我用 ASR 的分片时间戳结合语义边界把文本切成 5 到 15 分钟左右的章节块。块太小知识点碎片化严重块之间重复率太高块太大又会回到长文本失效的老问题。实践中按课程内容自然分段比按固定字数切要稳定所以我在清洗阶段会先识别出明显的主题切换点比如接下来我们看第二个问题是这类信号再据此切块。3.2 分块摘要用 Map-Reduce 思路控制质量MAP局部摘要阶段我会为每个章节块构建一个专门 prompt。核心要求是只根据给定文本输出该章节的摘要禁止引入文本之外的知识输出控制在 150 字以内提炼凡是与主线无关的技术铺垫可以省略必须保留关键术语和结论。为了让摘要风格统一我给了模型一个固定输出模板模板里包含三个小字段本节主题、核心结论、涉及的关键词。REDUCE全局合并阶段把所有章节摘要拼接在一起交给模型生成整节课的全局摘要。全局摘要要求控制在 300 到 500 字结构上先讲课程整体目标再按内容演进列出 3 到 5 个核心主题。每个主题写一句定位再写这个主题与传统做法的差异或关键结论。这样生成的摘要不是流水账式复述而是真正能帮用户判断这节课值不值得看、重点在哪里的卡片。实际执行时我会把 MAP 阶段的 prompt 里明确加上如果该章节是纯寒暄或课程导入请如实说明不要强行提炼知识点。这个指令非常管用因为很多课程开场会把五分钟的自我介绍和课程安排废话算进去模型硬要去总结反而生成了本课程介绍课程安排这种垃圾摘要丢弃掉更干净。3.3 知识点提取用 JSON 约束结构化输出摘要只是第一步知识点提取才是整个项目能落地检索的关键。知识点不能是散文必须结构化。我设计的知识点对象包含字段知识点名称、一句话定义、所属章节、出现时间戳、重要程度等级。要求 LLM 以 JSON 数组返回每条数据遵循同一 Schema。为了让模型稳定输出 JSON我在 system prompt 里明确了 JSON Schema 样例并给出三个字段约束知识点名称必须用名词短语不超过 20 个字定义不超过 80 字时间戳必须使用视频内部的毫秒时间戳重要程度只能是 high、medium、low 三选一。同时在 user prompt 中附带了真实文本片段因为只有文本还不够——时间戳需要对应到文本的字符位置所以我会在切分文本时保留每个段落的起始时间戳并在送给 LLM 的文本中插入形如[12:30] 的标记。模型在提取知识点时会引用最近的标记作为时间戳实现自动对齐。实际运行中JSON 输出偶尔会解析失败常见情况是模型在 JSON 前后加了解释性文字或者某个字段中包含了多余引号。我设计了专门的修复环节如果 json.loads 失败就把模型原始输出作为错误信息让 LLM 重新生成一次规范 JSON并要求只输出 JSON不要任何说明。一般重试一次就能通过。这里还涉及温度设置知识点提取任务我把 temperature 设为 0.1temperature 太高会让模型自由发挥把注意力机制编成神经网络的注意力机制在自然语言处理中非常重要此类扩展不够精准。3.4 时间戳关联与章节归属让知识点可点击回跳知识点只有能定位到视频具体位置才算真正可用。这套系统的检索体验是用户在搜索框输入transformer 结构返回的知识点卡片上直接显示该知识点出现于第 3 章视频 12:35 处点击就跳转到对应画面。要做到这一点必须在 ASR 阶段保存精确到词的时间戳然后在文本切分、LLM 提取的每个环节都保留时间戳标记。我维护了一个简单的时间戳传播规则。ASR 输出是一串带 start 和 end 的分词结果清洗阶段把这些词合并成句子句子的 start 为第一个词的 startend 为最后一个词的 end。切分章节块时章节块的起止时间等于第一句话和最后一句话的时间。LLM 提取知识点时文本中插入的[12:30]标记被复制到知识点的 timestamp 字段。这三步只要有一处没对齐后面的时间戳就是乱的。为了验证对齐我会定期抽查某几个知识点的回跳位置看是否落在老师讲到该知识点的那十几秒区间内。章节归属的判定也依赖这个信息。视频课程里两个章节的边界不一定正好在静音处但文本语义边界通常能判断。我在 LLM 提取章节摘要时顺带让模型输出当前章节的主题名称再拿这些主题名称与知识点的语义做匹配。匹配不到的就归到最近的前一个章节之下保证每个知识点都有归属不会悬空。4. 流水线工程化落地与效果评估4.1 任务编排与状态管理流水线设计得再漂亮没有工程化支撑就是一堆 Jupyter Notebook。团队最终需要一套可监控的任务系统。我采用的状态机非常简单pending、running、success、failed、retrying 五个状态。视频进来先落库创建一条 pending 任务ASR 进程拉起后标记 running每个阶段完成状态和产物路径写到数据库失败则记录错误信息和当前阶段索引便于断点续跑。调度层面我用的是 Redis 队列加一组 worker。每个 worker 负责一个阶段audio_worker 处理音轨抽取asr_worker 跑转写clean_worker 做清洗切分llm_worker 调模型。阶段之间通过消息传递握手而不是靠一个大脚本从头串到尾。这样做的好处是只要某个阶段 worker 积压可以单独横向扩容。比如 ASR 阶段最耗 GPU我维护了三个 GPU worker其余阶段都是 CPU 就够。断点续跑是真实生产环境中最实用的设计。有一次 LLM 供应商接口限流两百个视频任务全部卡在 llm_worker按老方案只能整体重跑现在只需要把失败任务重新插入 llm 队列前面 ASR 清洗的结果原封不动复用几分钟全部恢复。为此每个阶段产物的文件名都带任务 ID 和阶段名比如{task_id}.srt、{task_id}.clean.json看到文件名就知道跑到哪一步。4.2 错误处理与重试策略这条流水线里每个环节都有可能失败但失败的模式完全不同不能一套重试逻辑打天下。ASR 阶段最常遇到的问题就是 OOM 显存不够和音频超时OOM 一般发生在长片并行分片同时进 GPU 的时候解法是给每个 GPU worker 限制并发数或者对超长音频先降采样、再分片排队。网络和临时文件问题是偶发重试一次就能成功我设置了三次重试、指数退避。LLM 阶段失败模式更多。供应商限流是高频问题返回 429 或者 503。我的策略是请求级别限流加本地令牌桶把每秒请求数降到一个保守水平不要等到上游限流才被动退避。超时也常见尤其是长章节一次生成超长知识点列表的时候。我把单次 LLM 请求的响应时长上限设置为 120 秒超过就切换更小的章节块重试而不是无限拉长等待。模型输出本身的问题如 JSON 解析失败走的是重新生成一次并严格约束格式的路径。还有一类错误发生在数据层。MySQL 或者向量库偶发连接超时这类错误重试意义不大先做健康检查确认服务可用再重试。我维护了一张错误类型表把错误按照可重试、不可重试、需降级三类归档。可重试的直接自动重试不可重试的进入人工审核队列需要降级的任务比如 LLM 输出长期不可用就先只用 ASR 文本入库至少保搜索功能可用避免整个任务积压。4.3 效果评估除了肉眼还要有可量化的指标摘要和知识点质量评估是这个项目中最难被量化的部分。很多人最后选择人工看几条示例就拍板但生产环境每天新增几百条视频必须建立可持续的评估维度。我从三个方向设计评估转写质量、摘要忠实度、知识点实用性。转写质量用 WER词错误率做参考指标在测试集上人工转写一小段音频作为参照再算 ASR 结果的错字率。我们的标准是常见课程场景 WER 控制在 10% 以内语速极快或者口音较重的课允许放宽到 15%。摘要忠实度我采用人工打分结合对照检查法随机抽选一条摘要中的若干结论句回到原文找对应段落如果不匹配就扣分。每月抽 30 条做一次维护一份质量趋势记录。知识点实用性看两个数点击跳转使用率以及搜索命中率。用户通过知识点卡片点击跳转视频的比例高说明结构提取有效搜索命中率则反映知识点命名是否符合用户预期。这套评估体系上线后直接推动了两处优化。一是知识点的名称措辞早期模型喜欢写XX 技术的原理与实现但用户搜索会输入XX 怎么用后来通过在 prompt 中加入名称尽量贴近用户口语检索习惯点击率明显上升二是时间戳定位的准确度优化清洗环节后用户跳转后停留时长变长不再频繁回退重跳。4.4 一组实测数据与投入产出直接在内部平台上线了两周积累了一些真实数据。测试视频库共 860 条课程总时长 287 小时平均单节时长 20 分钟。处理后平均单节生成全局摘要 380 字章节摘要 6 个知识点 14 个。知识点的自动提取准确率在人工抽检中约为 86%错的主要是术语名称过粗和个别时间戳偏移。ASR 端到端处理速度GPU 环境下约为视频时长的 0.1 到 0.2 倍速CPU 环境下约为 0.5 到 1 倍速。检索侧变化更直观。原本平台只能搜视频标题和简介上线后用户可以从摘要、知识点名称、知识点定义三个字段搜索搜索 UV 中约 23% 的人会点击知识点的跳转链接点击后平均观看时长 2 分 40 秒。这个数字说明用户确实通过知识点找到了想看的内容。按人力估算如果纯靠人工给课程打标签和写摘要860 条课程至少需要三个人干一个月成本大约六万到十万元而流水线运行成本主要是 GPU 租赁和 LLM token 费用总计不到四千元性价比差距非常明显。5. 常见问题速查与避坑实录5.1 高频问题排查表现象常见原因解决办法ASR 转写结果大量英文夹杂语言检测失败或音频开头有引导语固定 languagezh或裁剪片头后再转写同一个词转写两次结果不同temperature 过高或没有固定随机种子温度设为 0并固定翻译模式不启用自动解码策略知识点时间戳全部不准分片文本未携带偏移量或词级时间戳丢失切分时保存相对偏移量重建对齐关系LLM 输出 JSON 解析失败模型在 JSON 前后加了说明或字段引号冲突增加严格 JSON 修复重试system prompt 明确只输出 JSON摘要包含原文中没有的内容章节块太长模型脑补缩小切分粒度降低 temperatureprompt 强调只依据文本任务积压在 LLM 阶段上游接口限流或单次请求过慢本地令牌桶限流短块重试、调整并发视频中有背景音乐导致转写混乱VAD 无法识别静音模型被音乐干扰对音频做降噪预处理必要时用伴奏分离工具去人声表格不是万能钥匙很多问题需要结合日志看。我建议从项目第一天就给每个任务挂上唯一 ID日志里所有阶段都打印 task_id 和当前阶段排查时一条命令就能拉出任务全貌。别小看这个环节没有统一日志线上出问题基本靠猜。5.2 几个值得反复看的细节ASR 文本里的语气词和口头禅必须彻底清除。有人觉得嗯啊那个在摘要阶段被 LLM 自动忽略实际上不是。这些词会占 token更重要的是会干扰知识点名称的生成那个神经网络中的那个注意力机制这种带口头禅的知识点名称检索时几乎不可能被命中。我清洗时用正则过滤常见语气词再把相邻重复字压缩比如模型模型合并成模型。章节边界的自动识别需要按课程类型微调。实操类课程适合按操作步骤切理论类课程适合按概念演进切。我用一个轻量方法在清洗阶段检测时间戳标记附近是否出现接下来然后我们第二个这类转折词有转折就切一刀。最开始我用固定 10 分钟一刀结果把一气呵成的小节切成两半摘要和知识点重复率飙升改成语义转折再切后效果立刻稳定下来。还有关于 LLM 请求的 token 计费问题。很多人觉得把整章文本送进 LLM 做摘要很贵实际上按照分块策略token 消耗并不夸张。我统计过20 分钟课程转写约 8000 字全流程 LLM token 消耗大约 9000 到 12000换算成成本只有几毛钱。真正贵的是无限重试和模型开关失控所以一定要给每个 LLM 调用设置上限并监控 token 消耗的异常趋势哪个视频的 token 消耗远超同类大概率是切分失败进入了死循环。5.3 不要忽略的人工兜底最后给一个不太AI的建议自动流水线之外必须留人工审核入口。哪怕准确率到了 86%那 14% 的错误在知识库里会持续误导用户尤其是课程涉及专业操作时。我设计了一个简易审核界面前端展示 ASR 文本、生成的摘要、知识点列表审核员可以对知识点名称和时间戳做修正。修正后的结果回写数据库并作为后续 prompt 的 few-shot 示例形成一个不断自我改善的闭环。第一周审核量是最大的一天大概需要处理两百条知识点后来模型学会了优秀修正案例的命名风格需要人工动的越来越少。到第二周每天审核时间降到半小时准确率也从 86% 逐步上升到 92%。自动化永远不能完全替代人工但把人工工作集中在纠正迁移而不是从零标注效率提升是非常客观的。根据我个人经验这类 AI 流水线项目最容易翻车的不是模型选型而是数据在环节之间的流转失真。文本经过 ASR、清洗、切分、LLM每一步看起来都只是格式转换但信息损失却在静默累积。所以但凡关键环节我都坚持在产物里留下版本号和原始对照字段比如 ASR 转写腔调不准时可以回头查到底是清洗误删还是模型选型问题。把这套审计思路做进工程里比任何华丽的 prompt 都更管用。