基于ASR与LLM的视频课程知识点提取流水线设计与实践

去年我接手了一个挺头疼的活儿公司在线培训平台上积压了上百小时的录播课程内容质量很高但学员检索困难、课程大纲缺失、学习笔记基本靠人工抄写。销售团队反馈说新人想找某个知识点得整段整段拖进度条。于是我搭了一套基于ASR加LLM的自动化流水线把视频课程自动转成结构化文本再由大模型生成摘要、关键词、知识点卡片和时间戳索引。这套系统跑通之后我整理一门两小时的课程从原来的大半天压缩到了十几分钟而且产出物可以直接进知识库检索。这篇文章就把整个流水线的设计思路、工程细节和踩过的坑完整写出来给同样被视频内容整理逼疯的同行一个可复制的参考方案。整条流水线不算复杂核心就是“语音转文字”加“大模型抽取”两段式处理但真正落地时音频分段策略、口语清洗规则、提示词设计、长文本窗口管理、幂等重跑机制每一环都有不少容易被忽视的细节。下面我按实际的工程推进顺序来讲从需求分析一直聊到质量评估和后续扩展。1. 为什么课程内容的摘要和知识点提取不能靠人工硬扛1.1 人工整理的真实成本我一开始也想过找实习生人工整理但算了一笔账之后彻底放弃了。一门两小时的课程按照正常的语速大概有一万五千到两万字的口语转写内容。一个熟悉业务的人要一边听一边记录重点、核对术语、标注时间点完完整整整理出一份像样的大纲和学习笔记最少要四到六个小时。如果是那种课堂问答多、案例穿插多的课程时间还会更久。一百小时的课程就意味着至少两百到三百个工时按兼职时薪算也是一笔不小的开支更别提人工整理的主观性——两个人整理同一门课出来的大纲结构可能完全不同术语口径也不统一后期维护非常痛苦。1.2 系统适用边界什么人需要这套流水线这套系统适合三类场景。第一类是内容运营团队手上有大量视频课程需要生成配套文档、宣传文案、课程简介用这套流水线可以快速产出初稿。第二类是企业培训部门需要把内部录播课变成可检索的知识库让员工按关键词查知识点而不是从头到尾看视频。第三类是个人学习者如果你有大量网课需要整理学习笔记搭一个轻量级版本也完全可行。但也要说清楚边界这套流水线做的是“整理”和“索引”不是“理解”。它能把“老师讲过的所有内容点”按结构呈现出来但不能替代人工对课程质量的判断。如果你需要的是针对课程内容做深度批判性分析那还是得靠人。2. 流水线整体设计从视频文件到知识地图的四道工序2.1 四道工序与模块化选型我的流水线分成四个独立工序音轨抽取、ASR语音转写、文本清洗与结构化、LLM摘要与知识点提取。每一步都独立成模块中间产物以文件形式落盘方便单独调试和替身换件。音轨抽取直接用 ffmpeg 处理把视频文件的音频流单独导出成 wav 格式方便后续喂给ASR引擎。ASR这块我选了目前开源社区口碑最稳的 whisper 系列具体用的是 faster-whisper 这个加速版实现识别精度和速度都比较均衡。文本清洗环节是我自己写的一套规则引擎主要处理语气词、重复片段、数字和单位规范化。LLM抽取环节我用的方案是让大模型基于清洗后的转写文本生成结构化输出商用闭源模型和开源模型我都试过只要提示词设计得当效果差距不大更重要的是输出格式的稳定性。这里要特意说一下为什么不搞端到端的“视频直接输入大模型”。虽然现在有些多模态大模型能直接理解视频但成本高得离谱而且对长视频的上下文窗口限制很严。一个两小时的视频直接塞给多模态模型先不说理解效果光是视觉画面的token消耗就是纯音频转写文本的好几十倍。而ASR加LLM的两段式方案每一段都可以单独优化转写错了可以只改ASR参数抽取结构不对可以只调提示词不会互相污染。工程上这种“每一环都可替换”的架构后期维护会轻松很多。2.2 为什么先转写、再抽取而不是一步到位有人可能会问直接用ASR转出来的原文喂给LLM不行吗为什么中间还要插一道文本清洗因为ASR的原始输出直接进大模型效果会打很大折扣。我实测过whisper 转写的口语文本里语气词和重复占比高的时候能到百分之十五左右。“呃”“嗯”“就是说”“那那那那个”这类词大量存在大模型不是不能处理但它们会稀释真正的语义密度导致摘要抓偏重点知识点提取时把一句“我们这个课程呢呃主要讲的是……”里的“我们”当成关键主体。清洗这道工序是用非常简单的规则把噪声压下去让后面的LLM把钱花在刀刃上。3. ASR转写环节长视频分段、说话人分离与口语清洗3.1 音频抽取与分段策略如果你直接把一个两小时的视频丢给whisper大概率会遇到两个问题一是显存不够二是即便显存够长时间转写累积的微误差会导致后半段时间戳漂移。我自己踩过这个坑一小时以上的音频一次性转写最后的时间戳能偏出去好几分钟知识点索引完全没法用。解决办法是先分段再转写我通常按半小时一段切分段与段之间留两到三秒重叠后续拼接时通过重叠区做边界对齐。音轨抽取和分段的命令很简单ffmpeg 一条命令就能搞定ffmpeg -i input.mp4 -vn -ac 1 -ar 16000 -f wav audio_16k.wav这里把音频转成单声道、16kHz采样率的wav是ASR引擎最友好的输入格式。分段可以用 ffmpeg 的 segment 参数也可以自己写脚本按时长切我更推荐后者因为你可以在分段的同时记录每一段在原视频里的绝对起止时间import subprocess def split_audio(input_wav, segment_seconds1800, overlap_seconds3): # 用 ffmpeg 按固定时长切片保留重叠区 for i, (start, end) in enumerate(segments): subprocess.run([ ffmpeg, -i, input_wav, -ss, str(start), -to, str(end), -c, copy, fsegment_{i}.wav ]) # segments 列表需要根据音频总时长计算 # 例总时长 7200s步长 1797s窗口 1800s分段之后每一段独立交给ASR转写再把转写结果按时间戳拼回去。实测下来分段转写还有一个额外的好处单段音频越短whisper 的幻觉问题越少。所谓幻觉就是音频里某个停顿处whisper会凭空生成一句并不存在的话这在长音频里更容易出现。分段处理后每一段的错误被限制在局部拼接时更容易识别和剔除。3.2 说话人分离让转写文本带上“谁在讲”的信息纯课程讲解场景整段都是老师一个人在说说话人分离不是必需品。但只要有问答环节、嘉宾对谈、多人讨论转写文本里就必须带说话人标记否则LLM提取知识点时会出现严重的指代混乱。比如一段师徒对话如果转写文本只是连续的流水账大模型很可能会把学员的提问当成讲师的结论抽出来的知识点就错了。我的做法是给ASR环节增加一个说话人分离的后处理模块用的是 pyannote 这套开源方案。它会把音频按说话人聚类给每句话打上 spk_0、spk_1 这样的标签我再用后处理脚本把连续同一人说话的片段合并并且把“spk_0”替换成“讲师”、“spk_1”替换成“学员”。这一步完成后喂给LLM的文本就是带角色对话结构的格式[讲师] 今天我们讲的是向量数据库的索引结构。 [学员] 那HNSW和IVF在实际场景里怎么选 [讲师] 这个问题非常好如果你的数据量在百万级别以下IVF就够用了……有了这种带角色的文本LLM在提取“讲师核心观点”和“学员高频疑问”时就能区分开生成的知识点也更贴合实际学习需求。3.3 口语清洗哪些要洗哪些必须保留口语清洗规则我维护了三类。第一类是删除纯噪声词“呃”“嗯”“啊”“然后然后”“就是说”“那那那”这类语气词和重复词直接删掉。第二类是规范化数字和符号“百分之二十”改成“20%”“三到五个”改成“3到5个”这能让LLM生成的摘要更精炼。第三类是修正ASR常见的错别字这个需要维护一个课程领域的术语词表比如“Transformer”被转写成“全神父末”这种离谱错误就需要人工发现后加入纠错字典。但清洗的度要把握好有些内容坚决不能动。数学公式里的“阿尔法”“贝塔”不要强行替换成希腊字母因为ASR转写通常把公式读成中文发音保留中文反而更连贯。代码片段、专有名词、人名、产品名一个字都不要改改错了LLM生成的知识点术语就全偏了。还有引号内的直接引语比如讲师引用某本书的原文哪怕听起来有语法问题也不要清洗那是语义的一部分。4. LLM知识点提取提示词设计与长文本处理策略4.1 先定义输出结构摘要、术语、知识点、结论LLM抽取之前我花最多时间想清楚的一件事是到底要什么样的输出结构。这个结构最终决定了整个系统的可用性。我做的是六件套输出课程摘要、关键术语表、知识点列表、核心结论、常见疑问、时间戳索引。其中知识点列表是重头戏每条知识点必须有标题、一句话概述、详细说明、起始时间戳、所属章节。结构化输出用JSON最稳无论是接数据库还是接知识库都方便。我给的输出格式模板大致长这样{ course_summary: 用3-5句话概括课程核心内容, key_terms: [向量数据库, HNSW, IVF, 余弦相似度], knowledge_points: [ { title: HNSW算法的基本原理, summary: HNSW通过分层图结构实现近似最近邻搜索, detail: 讲师从跳表结构引入解释了多层图的构建与检索过程, timestamp: 00:12:35-00:18:20, chapter: 第2章 索引算法 } ], core_conclusions: [百万级数据量优先选IVF千万级以上考虑HNSW], common_questions: [HNSW和IVF怎么选型, 内存占用如何估算] }这种输出格式的好处是后续无论你要生成课程大纲、做知识库条目、还是生成学员复习卡片都能直接复用不需要二次解析。4.2 提示词拆解角色、任务、格式、示例提示词我从来不用一段话写完而是固定拆成四个板块角色设定、任务描述、输出格式、few-shot示例。角色设定很关键我一般写成“你是教育内容分析专家擅长从讲师口语授课中提取结构化知识点你的输出必须忠实于原文不得补充原文未提及的内容”。任务描述里要显式声明几个约束只能基于给定的转写文本作答、不确定的信息不要编造、时间戳必须参考文本中的段标记。few-shot示例一定要给而且最好给两个以上一个展示标准场景一个展示边界场景。比如有一个示例专门讲“老师闲聊了一段行业八卦请不要把这段提取为知识点”。我发现大模型对“不要做什么”的示例比对“要做什么”的示例更敏感。如果你只告诉它“提取知识点”它会把所有内容都当知识点但你给它看一个“闲聊被排除”的例子它就能学会区分主线和支线。4.3 长上下文窗口的Key-Query-Value组织方式处理两小时课程转写文本最麻烦的是上下文长度。两小时课程清洗后的文本至少一万五千字中文token数大概在一万八到两万二之间。有些模型的上下文窗口足够大能一次塞进去但窗口越大模型对早期内容的注意力越弱生成的摘要往往头重脚轻。我的做法是借鉴检索增强的思路把输入组织成Key-Query-Value三段式。把课程元信息课程标题、讲师背景、章节列表作为Key解决“这门课是谁在什么背景下讲的”这个定位问题把任务指令和输出格式要求作为Query解决“我需要从文本里找什么”这个导向问题把转写全文作为Value解决“内容素材在哪里”这个供给问题。实际效果是同样一版提示词用这种组织方式比把元信息埋在文本末尾的版本知识点覆盖率能提高十几个百分点。4.4 分段提取与全局聚合的Map-Reduce模式如果你不想花太多钱买超大上下文窗口的模型可以用Map-Reduce的分段提取策略。我目前的线上版本用的就是这种方案。先把两小时的转写文本按课程节奏切分成四到六个片段每个片段大约三十分钟独立调用一次LLM做局部分析生成局部的摘要和知识点列表。然后把所有局部分析结果合并成一份中间文档再做一次全局聚合调用让LLM做三件事合并重复知识点、调整章节归属、生成全局摘要和核心结论。这个方案有两个明显的好处。第一是成本单次调用的token数控制在五千以内可以用性价比更高的模型整体费用可以降一半以上。第二是质量分段让LLM专注于局部内容知识点提取更细不会漏掉后半个小时的讲解。代价是需要处理合并时的重复项我在全局聚合的提示词里明确要求“如果多个片段的知识点指向同一个主题只保留信息最完整的那条并在时间戳中标注起止范围”。5. 流水线工程化落地幂等、断点续跑、并发与成本控制5.1 用任务ID和中间产物实现可重跑流水线真正跑起来之后你会发现最影响效率的不是模型效果而是工程可靠性。视频转写和LLM调用都是耗时的外部操作任何一环失败整条流水线就得重跑这是不可接受的。我的方案是给每个课程建一个任务ID每一道工序的输出都落盘保存文件名带任务ID和工序编号。ASR转写结果存一份清洗后文本存一份局部LLM结果存一份全局聚合结果存一份。任何一道工序挂了只需要重跑那一道工序前面的结果直接复用。5.2 断点续跑与失败重试断点续跑的具体实现不复杂核心是中间产物缓存。每次调用ASR或LLM之前先检查缓存目录里有没有对应的结果文件有就直接读没有才发起调用。调用失败时做指数退避重试比如第一次失败等5秒第二次等25秒第三次等125秒最多重试5次。LLM接口经常有瞬时限流这种重试策略基本能覆盖绝大多数故障。5.3 并发控制与限流并发这块我踩过坑。一开始我图快同时跑八路ASR转写结果GPU显存直接爆掉机器卡死。后来老老实实做了并发控制ASR按显存余量动态调度最多同时跑两路。LLM的并发也要限流商用模型的API都有速率限制超了会被返回429我在重试逻辑里专门识别这个状态码遇到429就拉长退避时间。课程多的时候我维护一个任务队列一个课程跑完再从队列里取下一个而不是全部铺开。5.4 成本估算与降级策略成本是这套系统能不能长期跑下去的关键。我按一小时课程粗算过ASR转写成本可以忽略不计本地GPU跑LLM调用成本是主要开销。用中档商用模型一小时课程转写文本约一万八到两万二token分段提取加全局聚合总消耗大概在输入四万到六万token、输出一万到一万五token之间折算人民币大概在两到四块钱。一百小时课程就是两百到四百块跟人工整理的几千块比优势明显。如果预算更紧张还有一个降级方案不分段直接把整段文本投给模型做一次提取。效果会略差但成本能再降一半。另一个降级思路是只在低峰时段跑重课程比如凌晨批量处理很多API的夜间价格更低。6. 质量评估用LLM当裁判也要保留人工抽检6.1 先建评测集再调提示词我调试提示词的过程中发现一个规律凭感觉改提示词越改越虚。真正有效的做法是先建一个评测集选五门不同风格的课程每门抽两三段代表性内容人工整理一份“标准答案”包括该提取的核心知识点、术语、时间戳。每次改提示词之后拿这个评测集批量跑一遍对比新版结果和标准答案的差异用数据决定留哪版。没有评测集的提示词优化基本等于闭着眼调参。6.2 LLM as Judge的评估维度评测集的人工标注成本高不可能天天标。我的做法是让大模型当裁判用固定的评估维度给生成结果打分。一共四个维度摘要一致性、知识点覆盖率、时间戳准确率、术语正确率。每个维度满分五分让LLM裁判给出分数和扣分理由。实测下来LLM裁判的评分和人工评分的相关性能够达到可接受的水平虽然偶尔会有误判但趋势判断基本准确。我用的评估提示词也比较简单核心就一句话“请对比标准答案和待评估结果按以下维度打分每个扣分点必须指出具体位置。”评估维度满分扣分参考摘要一致性5摘要是否覆盖课程主线有无遗漏核心章节知识点覆盖率5标准答案中的知识点是否全部出现时间戳准确率5知识点的起止时间是否落在真实讲解区间术语正确率5专有名词是否翻译或转写正确6.3 人工抽检与迭代闭环LLM裁判不能完全替代人工我的兜底方案是按百分之十的比例人工抽检每周抽几门课的结果直接看。人工抽检的重点不是逐条核对知识点而是看两类问题一是LLM有没有生成原文完全不存在的“幻觉知识点”二是清洗环节有没有误伤关键信息。这两类问题一旦发现就回填到评测集里作为新的回归测试用例。这样每一轮迭代评测集都会变大系统质量会稳定提升。7. 从“能跑”到“好用”知识库对接与后续扩展7.1 知识点卡片接入RAG知识库流水线生成的JSON知识点结构最直接的应用是接入RAG知识库。我这边是把知识点卡片按“课程ID加知识点标题”作为文档ID写入知识库摘要和详细说明作为检索字段时间戳作为跳转字段。这样学员提问“HNSW和IVF怎么选”知识库能直接命中对应知识点并返回可跳转视频的时间点。这套方案比直接拿原始转写文本做RAG的效果好了非常多因为知识点卡片已经是高度结构化的信息检索命中率更高回答也能落到具体讲解片段上。我在实现时把Dify这类知识库流水线也考虑过其实知识点卡片的结构可以直接对接这类系统的数据结构不需要额外转换。如果你用的是开源的向量检索方案那更简单直接把详细说明字段切段向量化即可。7.2 课程更新与增量处理课程更新是另一个容易忽略的问题。讲师一年后重新录制了同一门课或者对旧课做增补如果直接覆盖式重跑流水线成本太高。我的方案是对比新旧课程的视频指纹只对新片段做ASR和LLM抽取旧片段的知识点保留不动然后做一次全局聚合刷新。这个增量处理能省下大量重复计算。实现的细节是给每个知识点的JSON里加一个source_version字段聚合时以最新版本为准。7.3 多模态信息的补充语音转写丢掉了很多视觉信息比如PPT上的图表、屏幕上的代码、板书。纯文字抽取对这类内容无能为力。我的后续迭代方向是在ASR转写的同时做屏幕OCR每十秒截一帧画面识别PPT标题和关键文字把这些OCR结果作为一种“视觉知识点”补充到知识点卡片里。比如讲师嘴上说“我们来看这个架构图”转写文本里没有架构图内容但OCR能识别出图表的标题和字段名补上这块信息知识点完整度会提升不少。7.4 一个容易被忽略的细节时间戳跳转的准确性最后补充一个我调了很久的细节。知识点的timestamp字段最终是要给学员跳转用的如果跳转不准整套系统的信任度就没了。ASR分段转写的时间戳在拼接时一定要做偏移校正不能简单累加每段的起始时间。我的做法是保留段间重叠区在拼接时用重叠区内的相似文本对齐边界校正每段的时间偏移量。这个时间校正模块写好之后时间戳误差从几十秒控制到了三秒以内。这套流水线做到现在已经稳定跑了几个月的线上任务。我最大的体会是AI工具在内容整理这件事上价值不在于“替代人工写出一份完美的笔记”而在于把人工从重复劳动里解放出来让人只做最后一道审核和判断。当你把摘要、知识点、术语、时间戳这些结构化解出来后你会发现这些中间产物还能衍生出很多玩法——自动生成课程简介、按知识点生成测试题、给学员做学习路径推荐。流水线本身只是一个开始真正值钱的是你手上那批已经结构化好的课程知识资产。如果你也在折腾视频课程的内容整理建议先从一门课跑通全流程把中间产物格式先定好再考虑规模化和优化——这比我当初一上来就铺大规模踩的坑要少得多。