视频课程积累了一大堆真到要看的时候却有种说不出的压力——两小时的课其实核心信息可能只有二十分钟。以前的办法是开倍速硬刷或者手动拉进度条找重点效率是真的低。后来我决定换个思路干脆用 ASR 把语音转成文字再用 LLM 做摘要和知识点提取搭了一条自动化的流水线。这篇文章就把这套方案的完整工程实践拆开讲讲从语音识别选型、文本切分策略到提示词设计、结构化输出再到任务调度、成本控制全程用实际踩坑和参数细节说话适合想自己搭建课程处理工具的开发者和教育从业者参考。1. 内容整体设计与思路拆解1.1 视频课程自动处理的三个核心痛点动手之前我先把问题掰开看了。视频课程的处理难在三个地方这三个问题基本决定了后续的架构方向。第一是非结构化信息的转化问题。视频里是连续的语音流夹杂着板书、PPT 翻页、停顿、口头禅还有演示操作时的背景音。这些信息天然不是文本形态计算机没办法直接索引或者检索。要想让课程变得“可搜索”“可总结”第一步必须把它变成结构化的文本。第二是信息密度的提取问题。一门课可能六七十分钟但真正承载知识点的有效内容往往集中在几个关键片段。剩下的时间可能是例子展开、答疑、重复强调。LLM 的确能做摘要但如果直接把两万字转写稿一次性丢进去既浪费 token又容易让模型“迷失在长文本里”摘要结果会变得笼统甚至丢掉关键细节。第三是知识点的跨段落关联问题。视频课程的上下文是前后连贯的前十分钟讲概念中间二十分钟讲应用后面可能又在回扣前面的概念。如果只是机械地把每一段独立做摘要知识点之间会变得支离破碎根本没法形成完整的知识网。基于这三个问题方案设计原则就很明确了先利用 ASR 完成语音到文本的一次转化再通过分块和结构化设计让 LLM 在可接受的上下文里完成二次提炼。整个过程用流水线串起来每一环节的产物都可以独立检视和复用。1.2 为什么选择 ASR LLM 双引擎的架构有人问过我现在的视频平台不是自带字幕吗直接拿字幕做摘要不行吗这个思路我一开始也试过。但实际处理课程类视频时平台自动生成的字幕存在几个现实问题标点符号基本是乱的、专业术语错别字率偏高、没有段落切分信息、说话人混在一起。这些问题会直接传导给 LLM导致摘要结果质量恶化。自建 ASR 环节的价值在于可以在转写时主动做三件事按语义停顿输出带标点的文本、通过热词表拉高专业术语的识别率、按时间戳保存句子级边界。这些信息都是后边做摘要时的“元数据资产”。那 LLM 在这里承担什么角色它不是简单地把转写稿“压缩一遍”而是要完成三个层次的理解任务抽取识别哪些句子是核心论点哪些是铺垫和举例。重构把跨段落的知识点按逻辑关系重新组织。映射将口语化的表达映射为规范的知识描述生成课程速览、知识图谱、复习提纲等结构化产物。ASR 解决“有没有文字”的问题LLM 解决“文字是什么意思”的问题。两件事分开做每一环都可以独立优化、独立替换、独立测试这就是流水线架构清晰度上的优势。2. 核心细节解析ASR 转写环节的工程要点2.1 语音识别方案选型与对比ASR 方案的选型是个体力活也是整个链路里最影响体验下限的一环。转写稿的错字率如果超过 5%后面 LLM 再聪明也补不回来。我把主流的几类方案放在一起做了对比从项目实际需求出发关注的指标依次是中文识别准确率、标点恢复能力、术语热词支持、是否支持本地化部署。方案中文准确率标点/断句热词定制部署方式备注云端通用 ASR高支持部分支持API 调用成本随时长线性增长开源模型本地部署中高需后处理支持需要 GPU 资源隐私性好可离线端到端多模态模型高较好需微调可 API/本地对长音频支持仍需验证我自己的选择是量产阶段走云端 API私密课程走本地模型。两条路都保留。原因是课程视频的隐私等级不一样公开课和内部培训资料的处理要求完全不同。另外热词表在两种方案里都要用后面细说。如果只让我给一个通用建议我会说先拿 500 分钟真实课程音频做基准测试别只看厂商公布的榜单数据。榜单上的测试集往往偏向标准口音和录音室音质课程视频里的教师口音、教室混响、语速变化才是真正的考验。选型时还要考虑一个容易被忽略的问题说话人分离。课程里经常有师生对话、双人讲解的场景如果 ASR 不输出说话人标签LLM 就很难判断“这句话是提问还是回答”“这段内容是学生反馈还是教师总结”。所以在评估 ASR 方案时我会额外检查它是否提供 speaker diarization 能力哪怕后续不用于摘要对做课程切片也很有价值。2.2 音频前处理、VAD 切分与转写文本清洗原始视频直接丢给 ASR 是很浪费的。我踩过的坑是整段音频一次性转写等了好几分钟结果文本质量还不稳定。后来老老实实做了前处理整个流程变成了这样第一音频提取与重采样。从视频里抽音频这一步看着简单但要注意源文件的编码格式。用 ffmpeg 统一转成 16kHz 单声道 WAV这样做一方面匹配大多数 ASR 模型对输入格式的要求另一方面能显著降低音频文件体积。ffmpeg -i course.mp4 -vn -ac 1 -ar 16000 -f wav course_16k.wav注意有些视频的音轨本身是立体声且左右声道内容不同比如左声道是教师麦克风、右声道是现场收音直接降混会损失清晰度。可以先检查音轨信息再决定如何处理。第二VAD 语音活动检测。课程视频里不可能全程有人说话开头可能有空白、中段可能有长时间停顿。用 VAD 模型把静音和噪音段切掉既能减少转写时长又能避免 ASR 在静音段产生幻觉文本。我这里用的切入参数是静音超过 600ms 切一刀语音前后的 padding 保留 200ms避免切断首尾音素。第三分段转写与时间戳对齐。VAD 切出来的片段不能太长一般控制在 30 秒到 2 分钟之间。太短的片段没有上下文太长的片段容易让 ASR 在中间出错后无法定位。转写时打开时间戳选项保证每一句都带有 start_time 和 end_time。第四转写文本清洗。即便用了热词表ASR 依然会产生一些常见的低级错误。我总结出三类必做的清洗去除重复词和口头填充词“呃”“那个”“嗯”但注意这点只用在最终生成摘要的文本里不能直接覆盖原始转写稿因为原始稿在定位回原视频时是有用的。合并断句。ASR 的标点恢复有时会过度分割把一句话切成两三句。这种问题需要在清洗阶段通过句子相似度合并处理。术语纠错。针对课程领域建立一份专业术语映射表比如“机器学习”和“机气学习”“Transformer”和“传神风马”通过规则或者小模型做一次自动纠错。这一步做完得到的是带时间戳的干净转写文本就像一份有目录的电子书。接下来才轮到 LLM 登场。3. 实操过程LLM 摘要与知识点提取的输入设计3.1 文本分块策略为什么不能整篇丢给 LLM很多人第一次做课程摘要最容易犯的错误就是贪大求全。我自己第一次测试时把一个 90 分钟的课程转写稿大概 1.8 万字完整塞给了 LLM结果显示内容确实覆盖了但摘要显得平庸更像流水账没有重点层级。这背后涉及的是 LLM 对长上下文的注意力分配机制——模型在长文本里会倾向于“均匀用力”导致重要的论点没有被突出。正确的思路是先在文本层面做一次语义分块让 LLM 一个块一个块地去理解。切块粒度要考虑两个因素上下文窗口和 token 成本。我的实践经验是一个块控制在 2500 到 4000 字之间。太短了 LLM 理解不了前后逻辑太长了又回到了老问题。分块时不按固定字数硬切而是按语义边界切——优先用时间戳分段、章节标题、句子间的停顿标记作为自然边界。这样每个块内部都是相对完整的话题不会把一句话从中间拦腰切断。分块之后还要做一个相邻块之间的重叠处理。我让每个块与上一个块重叠 150 字左右这样 LLM 在处理后一个块时承上启下不会因为边界生硬丢失跨段落的上下文。3.2 提示词设计如何让 LLM 输出稳定的结构化内容提示词是整个 LLM 环节里投入产出比最高的部分。我早期用很宽泛的指令“请总结这段文字的主要知识点”结果输出格式千奇百怪有的给列表有的给段落有的给表格很难统一解析。后来我完全改成结构化输出约束效果立刻稳定了。我现在的做法是两层结构。第一层是系统级提示词规定模型的身份和任务你是一名课程内容分析助手。你的任务是从给定的课程转写片段中提取知识点并按统一格式输出。知识点需符合以下标准 1. 必须有明确的核心概念或技能描述。 2. 必须能独立于原视频被理解。 3. 必须标注其在课程中的时间位置。第二层是片段级提示词动态拼接当前块内容和上一块的摘要并要求模型按预定义 JSON 结构输出{ segment_summary: 本段落的简要总结不超过100字, key_points: [ { point: 知识点描述, importance: high|medium|low, time_start: 120.5, time_end: 245.0, related_concepts: [关联知识点A, 关联知识点B] } ] }这样做的原因很直接机器可解析的输出才能进入后续的自动流程。人工阅读时格式随意无所谓但流水线后面还需要对这些结构化结果做合并、去重、组装如果第一步的输出格式就是乱的后续脚本要花大量精力做解析对抗。提示词里还需要明确“不要做什么”。我加了一条硬性规定不要虚构转写稿中没有出现过的内容。这防止了 LLM 在转写稿信息不足时自行“脑补”课程知识导致摘要中出现原课程根本没有讲到的内容。这类幻觉在技术课程里尤其危险因为表面看很有道理实际上是错的。3.3 摘要的层次化生成从单点片段到全局速览摘要并不是只有一种形态。课程学习场景下用户可能有三种不同粒度的需求扫一眼知道这节课讲什么的「一句话摘要」、快速复习用的「段落摘要」、按章节组织的「课程速览」。我在流水线里用两阶段生成解决这个问题。第一阶段每个语义块生成局部摘要和知识点列表。第二阶段把所有局部摘要拼接起来再次交给 LLM 生成全局摘要。这样既避免了直接处理超长文本的问题又保证了全局摘要的每句话都有底层转写内容的支撑。两阶段生成有一个细节值得注意第一阶段生成的局部摘要中间不能只压成一段话而是保留 JSON 结构。这样第二阶段可以在局部摘要的基础上再结合各段的时间戳做时间轴上知识点的对齐和归并。如果第一阶段的输出是纯文本段落第二阶段想恢复这些结构化信息就得重新解析非常麻烦。4. 流水线工程化落地调度、重试、并发的实战经验4.1 流水线的整体架构与任务状态管理ASR 和 LLM 各自跑通之后真正让我投入精力最多的是流水线本身的工程化。如果只是手动跑脚本处理个把视频根本不需要这篇文章。但当要批量处理几十个小时的课程时任务调度的可靠性就成了生死线。我搭的流水线分为五个阶段摄取阶段监听视频上传目录或者通过 API 接收任务记录视频元数据。预处理阶段提取音频、VAD 切分、重采样。ASR 转写阶段逐段调用语音识别服务产出带时间戳的转写稿。LLM 分析阶段转写稿分块后逐块分析产出结构化知识点。组装阶段合并所有分析结果生成课程摘要、知识点列表、知识图谱并写回数据库或导出文档。流水线里最关键的设计是任务状态机。每个任务的状态流转明确为pending → processing → completed / failed / needs_review。任何一步失败任务都不会被静默丢弃而是进入失败队列等待重试超过重试次数则标记 needs_review留给人工处理。任务状态一定要持久化我用的方案是把状态记录在数据库里配合 Redis 做任务队列。这样即使服务重启任务状态也不会丢失。早期我图省事直接用内存队列管理任务结果服务一重启所有未完成任务全部丢失又重新跑了一遍 ASR浪费了不少 API 费用。从那次之后任务状态落库成了我的默认约定。4.2 重试策略、并发控制与成本优化ASR 和 LLM 的 API 调用都不是百分百可靠。网络抖动、服务端限流、超时这些情况在批量任务里是必然出现的。我的重试策略是三层第一次失败立即重试解决偶发的网络问题。第二次失败等待 30 秒后重试解决服务端瞬时限流。第三次失败任务进入失败队列发送告警不再自动重试。并发控制的原则是先小批量试跑再逐步加压。我把 ASR 的并发数控制在 35 路LLM 的并发数控制在 510 路这取决于 API 服务的配额限制和成本预算。并发太高看起来处理得快但遇到限流反而需要更多重试实际吞吐量并没有提升还浪费了配额。成本控制这块我有两个具体做法。第一是缓存机制ASR 转写结果按视频文件的 SHA256 值做缓存同一个视频重复处理时直接读取缓存不再重复调用 API。这在课程视频反复上传、参数调优重跑时特别有用。第二是分级调用短片段用轻量模型长片段用高质量模型而不是全程统一用高配。比如 VAD 切出的短语音片段用响应更快的基础版 ASR 就够用了。提示LLM 对同一份转写稿的不同任务分开调用token 消耗会被成倍放大。我在实践中会把“生成摘要”和“提取知识点”合并到一次调用里用结构化输出一次拿全这样能省下大约 30% 的 token 成本。5. 常见问题与排查技巧实录5.1 ASR 转写质量不佳时的排查路径转写质量不佳是这条流水线里最常遇到的问题而且它不像代码报错那样有明确的错误信息往往是“转写完了但摘要效果很差”。我总结了一套排查路径按顺序走能定位绝大多数问题。第一检查原始音频质量。有些视频的音轨是会议系统录制的采样率低、动态范围大人声和目标声音混在一起。这种音频必须先做降噪和响度标准化再进 ASR直接转写的话错字率会非常高。可以用音频分析工具查看频谱判断是否存在明显的底噪和削波。第二检查 VAD 切分是否合理。VAD 参数太灵敏会把一个完整的句子截断太迟钝又会把不同的说话内容拼在一个片段里。我一般先拿一段 5 分钟的音频手动切分一遍作为基准再调 VAD 参数让自动切分尽量接近人工基准。第三检查热词表是否覆盖专业术语。课程里的专有名词是 ASR 最容易出错的地方。热词表需要持续迭代每次跑完转写把识别错误的术语加入热词表重新测试。我现在的习惯是每门课单独维护一份热词表基表是领域通用术语扩展表是课程内私有名词。5.2 LLM 输出不稳定时的处理策略LLM 的输出不稳定体现在两个层面一是同一段文本多次调用返回的结构不完全一致虽然 JSON 格式约束了但字段内容发散二是明显偏离转写稿的本意出现事实性错误。结构层面我的办法是输出后校验。用轻量的格式校验脚本检查返回的 JSON 是否完整、字段类型是否正确、时间戳是否越界。校验不通过就触发一次带修正指令的重试让 LLM “根据上次错误输出重新生成”。这个办法比盲目重试有效得多因为模型看到自己的错误输出后会更有针对性地修正。内容层面我的办法是置信度分级。如果某个知识点在多个语义块中被反复提及它一定是重点如果只在某一个片段出现且与相邻内容关联弱那它就可能是边缘信息或者幻觉。流水线在组装阶段会统计这个“提及次数”作为知识点重要度分级的参考之一。5.3 长视频处理超时与任务中断问题单个视频课程动辄一两个小时整个流水线跑下来可能需要 1020 分钟。这么长的任务很容易因为服务重启、API 配额耗尽、网络波动而中断。处理这类问题的核心是断点续跑。我把每个阶段的产物都落盘保存文件名带有任务 ID 和阶段标识。比如 ASR 转写完成后保存{task_id}_transcript.jsonLLM 片段分析完成后保存{task_id}_chunks_{index}.json。任务恢复时扫描已存在的产物文件跳过已经完成的阶段只处理未完成的部分。这套机制让批量任务能够空闲时分批跑完即使中断了也能原地续上。另外一个实用技巧是长度预警。预处理阶段计算音频总时长后如果超过预设阈值比如 120 分钟我会主动切分为多个子任务并行处理而不是让一个任务从头跑到尾。单任务处理时间控制在 15 分钟以内运维上会省心很多。6. 这套流水线后续还能怎么用流水线跑通之后我实际感受到的价值远超最初设想。它不只是解决“课程太长没时间看”的问题而是把视频课程变成了一种可以自由组合的信息单元。我现在用这套体系做了三件事。第一给每门课生成知识图谱把提取出的知识点按概念依赖关系连接起来这样学员复习时可以顺着图谱走而不是从头到尾再看一遍视频。第二做跨课程检索因为每门课的知识点都带时间戳标签搜索时可以直接定位到某个知识点在哪些课程里讲过、分别在哪一分钟。第三定期把新生成的摘要和旧版本对比用来发现课程迭代的差异这个在培训内容版本管理时特别实用。关于项目本身的扩展方向如果有足够的算力预算可以把 ASR 和 LLM 的模型都替换成更大规模的版本准确度和理解深度都会提升。另外可以在流水线末端接一个向量化入库的环节把知识点嵌入向量数据库做语义检索和问答。说到底ASR 负责听写LLM 负责理解前面做的所有分块、结构化、状态管理都是为了把这两件事稳定地串联起来。这套链路设计思路不限于课程处理任何涉及“长视频转文字 结构化提炼”的场景比如讲座、会议、播客都可以直接套用。