去年年中我接了一批在线课程视频累计将近三百小时。刚开始让团队成员人工逐课标知识点试了两周实在撑不住——一门四十分钟的课光听一遍再整理结构就要一个半小时更别说几十门课排队等着。于是我把目标定成搭一条“ASR LLM”自动化流水线视频文件进去结构化摘要和知识点列表出来。这套系统跑到现在大半年每周稳定处理几十小时新课人力基本降到抽检级别。这篇就把整个工程实践拆开聊从架构选型、ASR细节、提示词设计到知识库落地全部是我实际跑过的方案。适合看这篇内容的人主要是这么几类手里有一批课程视频需要做结构化索引的内容团队准备做在线学习平台、知识库产品的开发者以及想用大模型处理音视频转写文本但不知道怎么设计流水线的朋友。看完之后你应该能直接照着搭出一套可用的版本并且知道哪些地方会翻车。1. 为什么偏偏要用“ASR LLM”流水线做课程视频1.1 课程视频的核心痛点是“不可检索”课程视频和普通短视频最不一样的地方在于它有强结构、强逻辑而且用户回看成本极高。短视频用户看不明白可以划走课程用户看不明白会反复拖进度条拖两次找不到重点就不学了。所以对课程内容来说最值钱的不是“能被播放”而是“能被定位”——哪一章讲什么、某个术语在哪几分钟出现、某个关键结论在第几个知识点里。但视频本身是连续帧加连续音频天生没有结构。整段转写文本虽然把语音变成了文字可一条几万字的转写内容照样翻不动。只有把文本继续拆成“摘要、知识点、术语表、起止时间”这种结构化产物它才真正变成能被检索、被导航、被复习的内容资产。这也是我坚持要跑完整条流水线而不是随便找个ASR转一下就算完事的原因。1.2 先转写再提取而不是让多模态大模型直接看视频我见过不少团队一开始想走“多模态大模型直接理解视频”的路线把视频帧抽出来丢给视觉语言模型让它输出摘要。这个思路在演示场景很惊艳但在生产环境有三个现实问题。第一是成本。一小时视频的帧数极多哪怕抽关键帧传递和计算的开销也远高于处理纯文本。第二是可控性差。模型看到画面加字幕加语音内容维度太多摘要结构容易飘你很难判断它到底基于哪部分信息生成的知识点。第三是不可编辑、不可审计。万一摘要内容有错或者学员投诉某个知识点不准纯多模态生成的中间过程根本没法定位修改。转成文本之后就不一样了ASR出了偏差可以针对性修LLM生成错了可以把对应文本片段找出来复核。文本就是整条流水线的“中间表示”所有后续处理都建立在这个表示之上。这个思路借鉴了传统软件工程里“数据与逻辑分离”的做法中间表示越干净后续每一步就越可控。1.3 我给自己定的三个可量化目标项目启动前我写死了几个指标避免后面被“差不多能用”带偏节奏一小时课程视频从上传到产出完整摘要和知识点总耗时不超过20分钟单门课程的知识点提取完整度抽样人工评估不低于85分百分制摘要和知识点中不出现转写文本里没有的关键术语幻觉率控制在5%以内。这三个指标分别对应了流水线效率、提取质量、可信度三条线。后面的所有技术选型基本都是围绕这几个数字展开的。事实证明把指标提前定下来的确很有用因为后期优化时会反复用它们判断“哪个环节出了问题”。2. 流水线总体设计一个视频进、一个JSON出2.1 模块划分和每一段的产物整个流水线我拆成了五个阶段每个阶段只做一件事并且只向下游传递一份明确产物预处理阶段视频文件输入提取音轨、做静音检测输出清洗后的音频文件。ASR转写阶段音频输入输出带时间戳的转写文本格式是句子级JSON。文本清洗阶段转写文本输入做标点恢复、去除水词、合并断句输出干净的段落文本。LLM提取阶段段落文本输入按Schema产出课程摘要、知识点列表、相关术语和推荐提问。入库应用阶段结构化JSON输入做时间戳合并、去重、向量化写入知识库并建立索引。这样拆有一个很直接的好处每个阶段的产物都能独立验证。转写文本质量不行不会赖到LLM头上LLM输出格式乱了也不会回去重跑ASR。排错的时候定位特别快基本看产物文件就能判断是哪一段的问题。我最初也试过把步骤合并到一个脚本里一气呵成结果排查问题的时候无从下手后来老老实实拆开了。2.2 为什么用共享存储而不是数据表搬来搬去模块之间传递产物最简单的方案是每个模块直接读写共享文件目录。我在服务器上开了pipeline_workspace目录下面按课程ID/阶段名/文件组织。一个模块完成后写一个.done标记文件下游模块通过轮询这些标记来触发执行。有人可能会问为什么不把每一步结果写进数据库或者消息队列对于这种批处理流水线数据库的强约束反而成为负担——转写文本可能是十几万的句子每句都建表更新会很慢消息队列适合流式任务而课程视频本质是批量作业没必要引入额外组件。共享文件加标记文件的方式足够简单、容易调试而且对人工介入也友好哪一步有问题直接进目录打开对应文件看就是。2.3 并发与重试流水线首先要容错课程视频处理不像在线接口那样要求毫秒级响应它更看重吞吐量和稳定性。我用的是最简单的任务队列方案用一个Redis队列保存待处理课程ID四个Worker进程并发拉取任务。每拉到一个任务就顺序执行五个阶段任何阶段失败就整体重试最多重试三次。这里有个容易踩的坑重试不能无脑从第一步重跑否则ASR费用会翻好几倍。我给每个阶段都做了断点恢复比如ASR已经跑完、只是LLM调用超时那是直接从LLM阶段续跑而不是回头重新转写。实现方式不复杂每阶段开始时先检查对应的.done文件已经完成就直接跳过。就这一个设计帮我省掉了不少重复计算成本。3. ASR转写环节中间表示的工程含量决定后面所有质量3.1 音轨提取、采样率与噪声音量的预处理ASR质量是整个流水线的天花板转写错了后面怎么救都有限。预处理阶段我做了三件事把视频的音轨抽成单声道WAV、统一降到16kHz采样率、做响度归一化。为什么要统一到16kHz是因为大多数ASR模型训练时就用的这个采样率高于它属于浪费低于它会有信息损失。响度归一化可以用ffmpeg的loudnorm滤镜把音频统一到-16 LUFS左右这样不同课程音量差异就不会影响识别率。我还顺手去了开头和结尾的静音段避免ASR把无意义静音当成段落边界。ffmpeg -i input.mp4 -vn -ac 1 -ar 16000 -af loudnormI-16:TP-1.5:LRA11 audio.wav这条命令我在几百个视频上反复跑过稳定可靠。值得提醒的是课程视频里如果夹杂大量板书翻页声、鼠标点击声可以考虑加一个轻量降噪滤镜但不要下重手不然会把语音高频成分一并削掉识别率反而下降。3.2 切分策略固定时长加重叠窗口ASR模型处理长音频时通常有两种方式流式识别整段或者分片识别后拼接。流式方案延迟低但速度慢而且长音频的段落切分很难控制我采用的是分片方案每片60秒相邻片之间重叠10秒。重叠窗口是为了避免句子在切片边界处被硬生生切断。转写后重叠区域的内容会出现在前后两个片里我再通过文本比较去重保留时间戳更准确的那份。这个策略增加了大概20%的ASR调用量但显著减少了跨片句子断裂的问题。如果你没有重叠经常会看到一句话在上一片结尾说了半句、下一片开头又重复半句的情况LLM后面理解会很吃力。3.3 标点恢复、说话人信息与文本清洗裸ASR输出通常没有标点而且会把“呃”“那个”“就是”这类水词原样转写出来。这种文本直接喂给LLM模型理解起来非常费劲尤其标点缺失会让句间边界一团模糊。我的解决办法是在ASR后面加一个标点恢复模型把转写文本重新加上逗号、句号、问号再做一次水词过滤。说话人信息要不要做取决于课程类型。如果视频是单人讲解那不需要。但如果课程是访谈、多人对谈说话人分离就很有必要——它是后续知识点归属的关键。我用了一个预训练的说话人日志模型给每句转写打上speaker_id。实测下来单人课占大多数说话人分离在多人场景才开启避免浪费算力。3.4 时间戳对齐词汇级还是句级最后还得解决一个比较微妙的问题转写结果里的时间戳到底精确到词还是精确到句。词级时间戳定位更准但成本高而且ASR对某些词的起止时间本身就有误差句级时间戳足够用于课程导航同时天然和自然语言单元对齐。我最后选了句级时间戳并且要求ASR输出的每个句子必须带三部分开始时间、结束时间、文本内容。时间戳对后续知识点定位特别关键。学员看到一个知识点的卡片点进去要能直接跳到对应视频位置靠的就是这套句子级时间戳。这一步做扎实了后面LLM提取知识点时能直接引用时间范围体验非常加分。4. LLM提取环节提示词、Schema与令牌预算的三角博弈4.1 我给LLM的结构化输出模板LLM部分是整个流水线的“大脑”也是最需要精细调教的地方。我给模型定义了一个严格的输出Schema要求它必须按JSON返回字段包括summary整门课程或本段内容的摘要控制在150到200字key_points知识点数组每个知识点带标题、详细说明、起止时间terms关键术语表包含术语名和一句话解释questions针对课程内容生成的3到5个推荐提问。不要小看这个Schema的作用。我一开始只给模型说“请总结这门课”结果输出风格千奇百怪有人给列表有人给段落还有人自己发明字段名。把Schema固化下来以后下游解析逻辑可以写得很死稳定性立刻提高了。下面是我实际在用的系统提示词精简版{ role: system, content: 你是课程内容分析助手。你只能基于提供的转写文本来总结和提取信息不能补充任何外部知识。必须严格按JSON格式输出。key_points中的每个知识点必须包含start_time和end_time单位是秒。不要输出转写内容中不存在的术语。 }4.2 分段摘要与层级合并防止上下文撑爆一小时课程的转写文本中文大约会有八千到一万两千字按Token算差不多一万五到两万直接塞进单次LLM请求不但成本高还有概率超出上下文窗口。更现实的问题在于一次给模型太多内容它对后面的部分“记忆力”会下降总结质量和理解深度都不够。我用的是“先分段、后合并”的层级摘要方案每10分钟转写文本分成一段先让LLM针对单段做小摘要和知识点提取然后再把所有分段摘要汇总生成整门课程的最终摘要和整合过的知识点列表。这个过程很像人看书先读章节再读全书信息压缩有层次丢失率明显低于一次性处理。但是这里要非常小心一点合并时模型只看到各段摘要可能会漏掉只出现在某一段里的重要术语。我的补救办法是分段提取时就要求模型把关键术语列为结构化字段合并阶段把这些术语表一起合并不和摘要混在一起处理。4.3 幻觉控制模型只能引用转写文本提取知识点的场景里幻觉比摘要冗余更让人头疼。模型一旦自由发挥可能会生成老师根本没讲过的概念或者把相似术语张冠李戴。这是知识库产品的大忌因为学员一旦发现术语对不上会对整个内容的可信度产生怀疑。我采用的防幻觉手段有三个。第一系统提示词里明确写“只能引用转写文本中的信息”。第二要求每个知识点的说明部分必须引用原句片段我会用正则检查输出里面有没有出现来自原文本的连续子串没有引用的知识点直接判为可疑。第三把生成温度调到0.2以下宁要保守也不要天马行空。这三招叠加之后幻觉率从初版的8%降到了2%左右。4.4 令牌成本怎么估以及如何压降成本这块我算过一笔账。一小时课程大约12000个汉字按一个汉字约1.5到2个Token折算大概两万Token。分十段跑加上摘要合并总输入输出Token大约三万左右。如果按商用模型每百万Token几十块钱算一小时课程的处理成本在几块钱到十几块钱之间对内容团队来说完全可以接受。想压成本我试过几个办法都有效一是把转写文本里明显重复的口头禅先去掉减少无效Token二是重复内容较多的课程可以开启缓存避免同一段文本反复计费三是把“全文细节抽取”和“整体摘要生成”拆成两个请求细节抽取用便宜模型摘要合并才用更强模型。这样配合下来单门课成本能再降三成。5. 生成结果到知识库后处理、检索与质量评估5.1 时间戳合并与知识点去重LLM输出的原始知识点列表直接入库是不行的必须做一遍后处理。最常见的问题是同一个知识点在不同分段中被重复提取比如前一段讲了“Transformer架构”的定义后一段又讲它的变体模型可能生成两条相似条目。我的后处理逻辑是这样先把所有知识点的标题做归一化去掉空格、标点、改成小写再计算标题相似度相似度超过0.85的视为重复保留时间跨度较长、说明更完整的那条另一条的时间戳并入同一个知识点的“相关片段”数组里。最后再把时间戳有交叉或者相隔小于5秒的知识点合并这样学员看到的导航不会出现两条几乎一样的条目。5.2 入库设计metadata和向量化后处理完成的JSON我会拆成三种数据写入存储摘要文本存成一个总文档知识点按条拆成独立记录术语表单独建一个字段。入库的时候最关键的是metadata设计我固定维护这几个字段课程ID、章节名、开始时间、结束时间、来源转写段落、生成模型版本。Metadata的意义在检索时特别明显。向量检索可以按语义召回知识点但召回结果必须通过metadata过滤掉其他课程的数据并且能精确跳转到视频位置。我用的方案是每个知识点做向量化后存入向量库id设置为课程ID_知识点序号查询时直接带课程ID作为过滤条件。5.3 质量抽检一份能落地的评测表质量评估不能只看感觉我专门做了一张抽检表每周随机抽三门课每门课由两个人独立打分主要看四个维度内容完整度知识点是否覆盖了课程的主要章节和关键概念准确度每个知识点的描述是否与转写内容一致有没有出现错误理解结构合理度摘要是否逻辑通顺、知识点排序是否清晰幻觉扣分出现了转写文本里没有的信息直接扣大分。完整度和准确度各占40%结构占15%幻觉直接扣20分。这样四项加权后我得到的是一个相对客观的评估分数。团队连续评测了几周以后也发现了一个很有价值的结论ASR转写错误率如果超过8%后面LLM部分无论怎么调提示词质量分都上不去。这反过来验证了中间表示的重要性。5.4 我踩过的失败模式与针对性修复流水线跑了这么久各种怪问题都见过挑几个有代表性的说。第一个是高并发时LLM接口偶发超时导致整条任务重试。解决办法是给每段LLM请求增加接口层面的指数退避重试同时允许单个分段失败后不影响其他分段最后统一汇总失败分段再补跑。第二个是模型偶尔把代码块或者Markdown标记混进摘要里破坏JSON解析。这个问题我靠两层防御解决一层是提示词中明确“不要输出Markdown”另一层是解析时用一次容错JSON解析器它能自动修复一部分格式问题。第三个更隐蔽某门课的PPT上有大量板书内容但老师口头没有完整念出来。ASR转写不到板书LLM自然提取不到。这种案例提醒我纯ASR方案对纯口播课效果最好对强烈依赖视觉的课程会有天然盲区。我现在的处理方案是增加一个“板书增强”分支对这类课程单独抽关键帧并做OCR识别把OCR结果一并送入LLM。效果明显改善。6. 收尾这套流水线沉淀下来的经验6.1 中间表示是可审计的资产回看整个项目最大的收获是“永远让中间产物保持透明”。ASR转写文本、清洗后的段落、LLM分段的JSON结果每一步我都原样保存在工作目录里。最开始这么做只是为了方便调试后来发现它有更大的价值——当学员对某个知识点提出异议时我可以顺着数据链路一层层回溯定位到具体是哪句话、哪个时间点产生了这个问题。这种可审计性在教育类产品里特别重要它决定了你的内容团队敢不敢放心地把知识库交给流水线维护。6.2 迭代生成优于一次完美输出我以前很容易追求“一次跑完直接得到完美结果”后来发现不现实。与其让模型一口气生成完美的全课程摘要不如让它在分段阶段尽量丰富合并阶段再做压缩和筛选。早期版本里分段摘要写得很简略合并时信息损失特别大。把策略改成“分段阶段宁多勿少合并阶段宁精勿杂”之后整体质量才稳定住了。6.3 给刚准备动手的人的三个建议最后分享三条实践建议。第一先跑通一个最小闭环哪怕是单门课程、只做摘要不做知识点先把端到端的数据流跑顺再逐步加模块。第二给每一个阶段留好人工干预入口不要迷信全自动——遇到ASR明显识别错误的段落人工修正的成本比重新设计模型低得多。第三控制好提示词和Schema的版本变化每次改Schema都要回归测试一遍旧课程数据别让后处理逻辑悄无声息地失效。这套流水线我不会说是最省事的技术方案但它一定是一条能持续积累内容资产的路。数据越积越多每一门新课的摘要和知识点都在充实整个知识库学员检索和复习的效率也水涨船高。如果后续再把自动出题和个性化推荐加进去这套底座的延展空间还很大。