1. 从“几百小时视频没法看”说起这套流水线到底解决什么问题1.1 视频课程的痛点人工摘要的三种失败方式今年上半年我被一个很现实的问题折腾了很久团队内部课程库已经有几百个小时的视频课每周还在新增。可当有人问我“哪门课讲了Attention Mask怎么算”时我只能靠记忆或者拿播放器一个视频一个视频地拖进度条。更尴尬的是有些课程是两年前的我自己参与录的但真让我说清楚里面第几分钟讲什么我说不出来。最初我想走人工路线——找人给每门课写摘要。结果试了三个方案全翻了车。第一种是让助教精听做笔记。一门两小时的课听一遍、记一遍、再校一遍通常要耗掉四五个小时。几百小时的课排下去人力成本直接失控。第二种是让讲师自己给大纲。问题在于讲师写的提纲偏向“我讲了什么”而不是“观众能从这里学到什么”而且课程更新后没人记得回来改。第三种是外包给兼职整理。质量完全不可控有人总结成三句话有人写了一万字按照什么标准抽知识点、什么是重点每个人理解都不一样。最后我意识到一个关键点人工摘要最常见的三个失败方式一个是太慢一个是不一致还有一个是根本没法检索。所谓没法检索就是摘要写完之后它跟原始视频的时间轴是脱节的。你想从摘要跳转到视频里对应的讲解片段做不到。没有时间戳索引的课程摘要价值直接砍半。所以我要的东西其实很明确一门课的视频丢进去自动吐出一份结构化摘要包含核心知识点列表、每个知识点对应的起止时间、以及一段适合快速浏览的总览。整个过程不需要人工干预而且课程更新后可以重新跑一遍。1.2 ASR与LLM各自承担什么角色为什么非要分两段这个需求拆开来看本质上是两个完全不同的问题。第一个问题声音怎么变成文字。视频里讲师说的话、屏幕上的演示、偶尔的互动提问都需要转写成可读的文本。这是典型的ASR自动语音识别Automatic Speech Recognition任务解决的是“听到什么”的问题。第二个问题文本怎么变成知识。转写出来的是两三万字的原始文稿里面有大量口语填充、重复解释、铺垫性的废话。需要从这个文本里判断哪些是真正值得记录的知识点怎么概括它它跟其他知识点是什么关系。这是LLM大语言模型Large Language Model擅长的事解决的是“理解什么”的问题。这两个问题必须分开处理原因在于它们的技术栈完全不同迭代节奏也完全不同。ASR这边要跟音频特征、声学模型、解码器打交道优化方向是错字率、时间戳精度LLM这边要跟上下文窗口、提示词、结构化输出打交道优化方向是信息召回率和摘要质量。如果硬把它们耦合在一个环节里——比如期望某个模型直接吃视频吐摘要——那一旦某个环节的效果不达标你连定位问题都费劲。还有一个现实原因ASR和LLM的部署方式不同。ASR通常是GPU密集型的模型推理一次可能要跑几分钟而LLM调用走API或者独立服务延迟在秒级。两者放在同一个进程里同步执行整个流水线会被ASR卡死。分开之后ASR那一端可以慢慢跑LLM这一端可以并发调互不拖后腿。1.3 流水线的整体拓扑与最低可用版本这条流水线的完整链路是视频文件进入系统后第一步用ffmpeg抽取音频轨做采样率、声道、音量归一化处理第二步把音频交给ASR引擎产出带时间戳的转写文本第三步把文本按照语义切成若干片段第四步把每个片段单独喂给LLM提取知识点并生成小结第五步把所有片段的小结汇聚起来生成课程总摘要和导学索引最后一步把结果作为JSON结构化数据落库供前端页面按时间戳跳转渲染。如果只求先跑通一个最小可用版本其实只需三步ffmpeg抽音频Whisper转写然后直接把全文丢给一个大上下文窗口的LLM让它写摘要。我最初就是这么干的跑通只花了一个下午。但当你把它放到几百小时的课程库上反复使用时就会碰到长文本摘要质量不稳定、专有名词错字、时间戳漂移、重复知识点合并、非常规课程结构失败等一堆问题。这篇文章就是把我后来逐个踩掉这些坑的过程记录下来每个环节都给出具体的参数、理由和备选方案。2. ASR这一环如何把2小时视频变成干净的文本2.1 音频预处理采样率、声道、码率这些参数别轻视很多人在ASR这步翻车不是模型选得不好而是音频喂得太脏。视频文件里的音频轨来源五花八门有的是录音棚收声有的是会议室麦克风有的是录屏软件直接采集。常见的坑包括采样率是44100Hz而不是16000Hz声轨是双声道混合了环境噪声响度忽大忽小导致静音检测误判。ASR模型对这种不一致非常敏感所以第一步必须标准化。我用的核心命令长这样ffmpeg -i input.mp4 -vn -acodec pcm_s16le -ar 16000 -ac 1 -af loudnormI-16:TP-1.5:LRA11 output.wav逐项解释一下-vn表示丢掉视频流我们只需要音频-acodec pcm_s16le把编码转为16位PCM这是大多数ASR引擎最认的格式-ar 16000强制采样率为16kHz这是Whisper和FunASR都标准化的采样率过高不会提升准确率反而增加计算量-ac 1合并为单声道双声道叠加的相位差会引入失真-af loudnorm做响度归一化先测再压保证整段音频的音量平稳。这里有个容易被忽略的点可变帧率视频。有些录屏软件产出的视频时间戳不均匀。ffmpeg转音频时如果不去处理ASR返回的时间戳跟原始视频的播放时间会对不上后面做知识点跳转时就会偏。稳妥的做法是在ffmpeg命令里加一行-video_track_timescale 90000处理容器时间基准或者转完音频后把ASR的segment时间戳跟视频的pts流做一次映射校准。我第一版没做这个结果有一门课的所有时间戳整体偏移了三秒排查了好半天。2.2 Whisper与FunASR的模型选型与推理速度实测ASR引擎的选择直接决定了文本质量和后续整个管线的天花板。我实测对比了OpenAI Whisper和阿里开源的FunASR下面是我的结论。Whisper的优势在通用性。它的多语言能力很强语言自动识别靠谱对噪声和口音的容忍度也高。我给英文课用Whisper large-v3中文课用medium或者large-v3都行。推理速度方面在单张V100上跑1小时音频large-v3大概需要4到8分钟medium大约2到3分钟small不到1分钟。如果你的GPU是A10或者4090这类卡时间能再压缩三分之一到一半。FunASR的paraformer系列在中文场景下表现很突出。它的中文识别准确率在标准测试集上跟Whisper large-v3互有胜负但在带口音的中文、有专业术语的课程场景里配合热词功能往往效果更好。更重要的是FunASR支持流式识别而且使用float32解码时对显存要求低很多单卡可以同时跑多个任务。选型没有标准答案我的建议按课程语言分纯英文或混合语言课程首选Whisper large-v3纯中文且术语密集的课程在需要热词强干预的场景下试FunASR。如果两者效果接近优先考虑解码速度更快的那个——在大规模回溯处理课程库时半天和一天的差别是实实在在的成本。模型部署的方式也值得说一句。Whisper我用的是官方whisper.cpp的编译版CPU上就能跑虽然比GPU慢但胜在部署简单。后来因为处理量上来了改成把模型转成CTranslate2格式加载用float16半精度推理速度提升了三倍左右显存占用还降了。这一步优化对后面异步队列处理很有帮助。2.3 专有名词错别字的兜底方案initial_prompt与自定义词典ASR模型对通用词汇识别得很好但到了专业课程里错字率会显著上升。最典型的是算法课里的“Transformer”经常被识别成“变压器”“多头注意力”可能变成“多投资利”课程编号“CS224N”更是五花八门。这些错字看着不起眼等到了LLM做知识点提取时错误会被放大——模型会把错词当成知识点写进摘要用户搜原名搜不到。Whisper有一个很实用的干预手段initial_prompt参数。它会给模型的解码阶段一个“先验文本提示”。我最初以为这是随便给个上下文就行实际测试后发现把课程目录、讲师姓名、课程涉及的核心术语、教材章节名写进去之后同一门课的错字率肉眼可见地下降。写法示例如下import whisper model whisper.load_model(large-v3.ct2) prompt_text ( 关键词Transformer, Self-Attention, Multi-Head Attention, Encoder-Decoder, BERT, GPT, 注意力掩码, 位置编码, 讲师张某某, 课程编号CS-405 ) result model.transcribe( audio.wav, initial_promptprompt_text, languagezh, word_timestampsTrue, condition_on_previous_textFalse )有个细节值得注意condition_on_previous_text这个参数默认是True意味着模型会根据前一段的识别结果来辅助推断当前段。这在长音频上容易造成“越往后越依赖自己之前的话”一旦前文识别错了一个专有名词后面就会反复错。我在处理半小时以上的课程音频时会把它设为False让每个30秒窗口独立解码。代价是偶尔出现语气不连贯但对术语的准确率提升很明显。FunASR那边对应的是热词文件机制。在funasr的接口里传入hotword参数可以直接给自定义词典加权。实测在“Deep Learning”和“PyTorch”这种词上命中率从八成提到接近满分。两种方案我都用Whisper靠initial_prompt给全局先验FunASR靠热词给局部强权。如果你视频里大量出现课程特有的缩写或代号这一步绝对不能省。2.4 时间戳与VAD对齐知识点跳转依赖的底层精度ASR输出的时间戳决定了LLM提取的知识点能不能定位到视频里正确的画面。Whisper自带word-level timestamp但是长视频场景下经常有漂移问题——开头还很准放到四十分钟之后就开始慢慢往后偏到结尾可能偏出十几秒。我排查后发现漂移的来源有两个一是Whisper的30秒窗口之间没有全局时钟约束二是静音段多的课程会让模型在时间轴上的“节奏感”丢失。硬修的办法是做一个强制对齐forced alignment先用VAD语音活动检测识别出哪些区间有人声再把ASR文段与声学特征做对齐映射。VAD这一步我用的还是ffmpeg先算能量特征粗筛出人声区间再用一些简单的后处理校正。FunASR生态里有现成的VAD模型把ASR、VAD串起来调用非常顺手。一个可用的时间戳规整代码如下from funasr import AutoModel model_asr AutoModel(modelparaformer-zh, model_revisionv1, vad_modelfsmn-vad, vad_model_revisionv1) res model_asr.generate(inputaudio.wav, batch_size_s300)做完VAD强制对齐之后时间戳和画面的同步误差从十几秒缩小到半秒以内。这个精度对用户点击知识点跳转来说已经足够体感上是“指哪打哪”了。如果你用的是Whisper可以看一下whisperx这个项目它做的就是强制对齐和说话人分离我后期把链路迁到了它上面时间戳问题基本一次解决。3. 文本切分与知识点提取别把整段文本直接塞给大模型3.1 为什么“长文本整段摘要”看起来香实际效果差我第一版流水线是这样的ASR文本拿到手一个两小时的课大概是两万八千字左右我直接构造一个巨型prompt丢给LLM“请总结以下视频课程全文的核心知识点。”当时用的是支持128K上下文的大模型想着反正装得下。结果效果非常不稳定。有的课程摘要写得很好似乎兼顾了每个章节有的课程模型把前四十分钟的知识点写了十几条然后后半程的内容只用了两句“此外还介绍了若干模型优化方法”带过。还有个更隐蔽的问题明明同一门课第二次跑出来的知识点跟第一次差异巨大抽取的颗粒度完全不一致。这个现象不是偶然业内一般认为长上下文场景存在“Lost in the Middle”效应——模型对输入序列开头和结尾的内容关注度远高于中间部分。当一份两万八千字的文档塞进去中间一万字的“腰部内容”就处于注意力盲区。你以为模型读完了全文其实它只精确感知了个头和个尾。正确的做法是分而治之。先把全文切成若干有语义边界的片段每个片段单独提取知识点最后再把片段级的知识点汇总。这个过程叫map-reduce式摘要map阶段负责局部精确提取reduce阶段负责全局归纳。准确率上升得极其明显。3.2 语义chunk的尺寸、重叠度与切分锚点Chunk策略的好坏直接决定LLM对每个片段的理解质量。一开始我图省事按固定字符数切每5000字符一刀。很快发现问题一刀下去可能正好把一个知识点从中间劈开。比如老师讲“梯度消失问题的成因”前一半在上一段后一半在下一段两个片段各自提取知识点时都因为信息不完整而流于表面。后来我改成按语义锚点切分。优先断句符是ASR转写结果里的句号、问号、感叹号以及VAD识别出的长停顿位置。组合策略是先按句子粒度感知再把句子聚合到目标长度区间。我最终采用的参数是目标chunk长度2500到3500字。这个长度对中文课程来说大约覆盖8到15分钟讲解知识点密度适中。太短比如1000字会导致片段缺少上下文LLM容易把铺垫误当知识点太长比如5000字又回到“Loss in the Middle”的老问题。重叠度相邻两个chunk重叠200到400字。这是为了保证被切在边缘的知识点至少有一个chunk能保留完整上下文代价是后续合并时要处理重复知识点。切分锚点分层优先在段落边界切如果段落太长在“但是、所以、另一方面、此外”这类转折词处切都没有的话才落到句号。重叠区间的重复内容我会在后面去重阶段处理这里先不过度优化——切分阶段的容忍冗余远好过切分阶段把信息切丢。3.3 知识点提取提示词的写法与结构化输出提取阶段我用的提示词有一套固定结构核心目标是让LLM输出稳定的JSON格式。提示词里必须明确三点知识点是什么、输出字段是什么、数量约束是什么。我常用的提示词模板如下prompt f 你是一名课程知识分析专家。请从下面的课程文稿片段中提取核心知识点。 要求 1. 每个知识点必须是可独立学习的完整概念避免把同一概念拆成多条。 2. 对每个知识点给出简洁标题不超过15字、关键词标签3-5个、一句话概括不超过50字。 3. 标注该知识点在文稿中的起止时间区间使用文稿中提供的段落时间戳。 4. 按照重要程度排序只保留最重要的5-8个知识点。 5. 输出严格的JSON数组不要输出其他任何内容。 文稿片段 {fragment_text} 关键在两点。第一明确“可独立学习的完整概念”这个定义避免模型把“讲了第一点”“然后讲了第二点”这种叙述性过程也当知识点提取出来。第二限定了“只保留最重要的5到8个”。不限制的后果是一个片段模型能给你吐二十几个知识点其中一半是无关痛痒的过渡性内容下游merge的负担成倍增加。调用LLM时注意把temperature调低。摘要和提取这类任务要的是稳定不是发散。我全部设置为0.2重试三次结果都基本一致。如果是Claude或GPT系列的老模型日期、模型名称这些参数也要控制好避免模型跑飞。3.4 跨chunk重复知识点的合并策略分片提取之后第二个头疼问题是重复。同一门课里老师会反复强调同一个重点。前一个chunk提取了“反向传播算法的链式法则”三个chunk后又提了一次“链式法则在多层网络中的应用”。如果不合并最终的知识点列表看起来像一篇没整理过的课堂笔记同义表达横飞。我的合并流程分两层。第一层是快速启发式对每个知识点的标题和关键词做向量化计算余弦相似度超过0.85的视为候选重复。这里我用的向量模型是bge-small-zh速度很快单课几十个知识点几秒就算完。第二层是LLM判断把候选重复对的标题和上下文各一句话塞给模型问“这两条是否描述同一知识点如果是保留信息更完整且带演示时间戳的那条。”这层判断准确率高代价是每门课增加几次LLM调用。时间戳的保留规则我单独说一下如果两个重复知识点分别位于第15分钟和第50分钟我会倾向于保留第50分钟的那条。因为后半段的讲解通常包含更完整的推导和总结知识点的呈现形态更成熟。如果你希望用户看到的是某个概念第一次被引入的位置那反过来保留更早的即可。这个策略取决于产品的使用场景没有绝对标准。4. 摘要生成路径分层摘要与上下文窗口的权衡4.1 三层摘要结构章节摘要、全文摘要、导学卡片知识点列表解决了“这门课讲了什么”的问题但用户还需要更整体的东西——这门课到底核心脉络是什么先学什么后学什么重点在哪个章节我最终采用了三层摘要结构。第一层叫“章节摘要”。ASR和chunk之后文本天然就带时间顺序。我把每个chunk的小结按时间顺序拼起来形成若干个“学习单元”每个单元对应视频里的一块连续区域。这一层回答的是“这个时间段在讲什么”。第二层叫“全文摘要”。把所有chunk的小结列表喂给LLM要求生成400到600字的课程概述讲清楚课程的定位、主线、章节分布和适合人群。在这一步我发现一个关键技巧输入时不要给原始文稿只给小结列表。因为小结已经是浓缩信息长度可控模型处理起来远比原文精准。第三层叫“导学卡片”。这是给学习者看的最外层包含课程总时长、核心前置知识、课程目录结构、每章的关键产出学完能掌握什么、推荐的学习顺序。导学卡片不要求长但要求“可决策”——用户看到它就能判断要不要学这门课、按什么顺序学。这三层摘要从底到顶信息一次比一次凝练颗粒度一次比一次粗。它们共用同一条LLM链路只是prompt不同、输入不同。这也是为什么前面要把分块环节做强摘要的质量上限在分块阶段就已经定死了。4.2 “Lost in the Middle”现象为什么输入越长摘要越漏刚才提过这个现象这里展开讲一下因为它直接影响摘要路径的设计。学术界对这个现象有过系统研究当输入序列长度增加时模型对序列中间部分信息的利用率显著低于首尾。通俗地理解你可以把Transformer当成一个阅读者它对开头几句话记忆最深对结尾几句话印象也深但中间那些长段落它在压缩注意力时容易“选择性遗忘”。对摘要来说这就产生了两个典型问题。一个是漏点课程中段的重要知识点在总摘要里消失另一个是颠倒模型把开头讲的不重要的铺垫当成主线把中段真正的核心反而弱化——因为在模型看来开头内容“更值得关注”。避免这个问题的最直接手段就是永远不要试图一次让模型读完整个长文本。分段摘要、分层归纳本质是故意把长序列拆成短序列牺牲一点模型端到端理解全局的能力换取对每个段落稳定的信息捕获。工程上这叫“recursive summarization”递归摘要拿时间换质量非常值得。4.3 缓存、去重与增量更新同一个视频别跑两次流水线拆好之后我发现一个工程层面的问题同样的视频因为改了prompt、换了模型、或者中途失败经常要整体重跑。一次全流程ASR十几分钟LLM调用几十次在课程量上来之后时间和钱都烧不起。所以我加了三个层面的缓存。第一层是音频指纹缓存。用ffmpeg抽完音频之后对音频文件计算SHA-256哈希。如果库里已有相同哈希直接跳过ASR复用之前转写好的文本。有人会问为什么不直接对视频文件哈希因为视频可能只是容器格式变化比如从mp4转成mkv或者分辨率变了但音轨内容一模一样。音频哈希更精准。第二层是转写结果缓存。ASR产物带时间戳的JSON文本按音频哈希模型版本号推理参数做组合key。只要这三者没变Whisper那十几分钟就不用重跑。第三层是LLM结果缓存。每门课程的chunk提取结果按文本hashprompt版本缓存。这样调试prompt时旧数据不会污染新一轮评估反之亦然——prompt没改只是跑了下游展示代码就不需要重新调用LLM。增量更新这块目前还没有做到很智能。如果课程原视频更新了一个片段我的处理是整门课重跑ASR和LLM。因为视频更新后音轨时间轴可能整体变化局部重算需要对旧的时间戳做重映射复杂度较高而课程库的更新频率不高整体重跑的代价在可接受范围。4.4 LLM输出不稳定的兜底JSON解析与重试机制结构化的好处理大家都知道但LLM的输出有时候不听话。最典型的是明明让输出纯JSON数组模型偶尔会加一句“好的以下是提取的知识点”然后才给JSON或者JSON里混入了注释或者json字段值里有未转义引号导致解析失败。我的兜底方案分四层。第一层是后处理剥离正则把回复中的json和标记去掉再把“好的”这类前缀剪掉。第二层是宽松解析用json5或者demjson3这类容错解析库去处理它能容忍尾逗号、单引号等小瑕疵。第三层是重试解析失败时把错误信息和原prompt一起回传给模型要求“重新输出只输出JSON”。第四层是降级如果重试两次还失败就把这个chunk的文本原样丢进“待人工复核”队列同时在最终结果里标记该片段质量存疑。温度参数在这里也很关键。我前面强调过0.2为什么不用0因为温度设为0时虽然最稳定但有些模型反而分叉到重复输出或死循环。0.2既保证输出确定性又留了一点容错空间。指数退避重试的代码我给个示例这是一个在调用OpenAI或兼容API时都通用的模式import time def call_with_retry(func, max_retries5): for i in range(max_retries): try: return func() except Exception as e: wait 2 ** i random.uniform(0, 1) time.sleep(wait) raise RuntimeError(LLM call failed after retries)5. 任务编排与生产化部署的几个硬细节5.1 任务队列与断点续跑中断了不用从头再来整套流水线里ASR是最怕中途失败的环节。一个两小时的音频Whisper跑了一半进程崩了如果没做状态保存重新开始就是白烧十几分钟GPU。我的做法是引入任务队列和状态机。每个视频作为一个任务进入队列状态依次是pending等待、extracting_audio提取音频、transcribingASR转写、chunking分块、extracting_knowledge知识点提取、summarizing摘要生成、done完成。任何一个步骤失败任务状态变为failed并把失败步骤和错误信息记入数据库。断点续跑的机制是每个步骤的输出都独立落盘。ASR转写完成就保存完整的转写JSON分块完成就保存chunk列表LLM每处理完一个chunk就单独保存一个结果文件。重启之后扫描到transcribing状态的任务先检查ASR产物是否已经存在存在就跳过。这套机制让整个流水线具备了天然的幂等性中断恢复后不需要从头再来。队列选型我用的是Celery加Redis。Celery足够成熟Redis够快团队也熟悉。如果任务量再上一个量级可以换到RabbitMQ或者云上的消息队列服务。在这里我要提醒一句不要为了上Kafka而上Kafka你们视频课程处理量级一般每天几十到几百个任务Kafka的吞吐优势完全用不上运维复杂度反而多出不少。5.2 GPU与并发控制显存、QPS与成本怎么平衡资源调度的核心矛盾在于ASR是GPU密集型的串行重型任务LLM是IO密集型的API调用任务。两者如果抢同一批机器资源会互相拖累。我的方案是把任务拆成两个worker池。GPU worker池负责ASR每台机器根据显存大小决定并发路数。一个经验值12GB显存可以同时跑1路Whisper large-v3或者2路medium24GB显存可以跑2路large-v3。超过这个数显存溢出或推理速度骤降反而不划算。CPU worker池负责音频抽取、分块、LLM调用等轻任务这部分主要是IO等待并发开个16到32都没问题。LLM API的QPS限制是另一个隐形瓶颈。很多API是按分钟、按并发数双重限流的。我刚开始写调度时没控制一上来开20个线程同时调LLM结果被打了一堆429限流。后来加了一个简单的令牌桶限速器将全局QPS控制在10以内问题立刻消失。等你的调用量足够大再考虑上独立的限流中间件。成本估算我给你一个大致的数一门两小时的课ASR阶段用GPU大概算0.2到0.5元左右按自建GPU摊销LLM调用看模型定价如果用7B级别的开源模型自部署一次摘要生成可以做到几分钱如果用顶级闭源模型API一次摘要七八块钱也是可能的。做产品规划时要有这个概念——LLM的调用次数和单次token长度才是成本的主要变量ASR反而相对固定。5.3 效果评估知识点的召回率怎么量化写了这么多工程细节最容易被忽略的是怎么知道这套流水线真的有效我有两个评估手段。一个是定量评估手工挑选三十门覆盖不同风格和学科的课程由三个教研同事分别标注出“你期望学习者在学完后掌握的知识点列表”作为ground truth。然后跑流水线计算自动提取的知识点在多大比例上命中了人工期望列表统计召回率和精确率。这个评测集一旦建立每次改动prompt或切换模型都跑一遍回归对比。你会发现很多看起来精妙的prompt改动在评测集上根本没有提升——有了评测集就不会自我感觉良好。另一个是定性评估拿生成的导学卡片给真实学习者看让ta根据卡片决定是否学这门课然后问ta“你从卡片上获得的信息够不够做决策”。这个指标没法自动化但它才是产品最终价值所在。量化指标再漂亮如果用户看了摘要还是不知道怎么学等于白做。我最终把目标定为知识点召回率不低于80%精确率不低于70%导学卡片在20人内测中至少15人认为“内容清晰、可用”。达不到就继续调达到就上线。5.4 实测中遇到的三个失败案例与最终处理最后分享三个我在这个过程中真实遇到、也真实解决的失败案例比任何理论都实用。第一个是双人对话型课程讲师和助教一人一句ASR转写后文本里说话人混在一起甚至把两个人各自讲的内容拼接成了完整句子。知识点提取时模型把助教的一句插科打诨当成了知识点。解决方法是给ASR链路加说话人分离用whisperx或者pyannote的说话人嵌入模型先把文本按说话人分组LLM提取知识点时加上一句约束“只提取主讲人的讲解内容忽略其他说话人的评论性内容。”效果立竿见影。第二个是代码类课程老师在视频里写代码ASR对代码的识别几乎全军覆没缩进丢失、变量名错乱、符号全偏。LLM提取知识点时把识别错的代码片段当成了真代码。处理办法是prompt里加一条提示“文稿中疑似代码、命令、变量名的片段可能包含大量识别误差遇到此类信息时标注为[待核对]不要将其作为知识点正文。”同时配合命令词过滤命中常见代码关键词的chunk单独走带代码修正的辅助模型。第三个是时间戳漂移导致的跳转错位某门3小时的课第48分钟的知识点点击跳转后视频实际停在第52分钟。排查发现是ASR长音频时间戳漂移累积。前面提到的VAD强制对齐方案把误差压了下来。但还有一个细节LLM返回的知识点起止时间是基于ASR文本的segment时间戳如果多个segment共享同一个时间戳会合并出一个过短的时间区间。我在最终写入数据库前加了一层校验知识点时间区间小于10秒的自动扩展到包含它的父segment的完整时间范围。这三个案例对应的是三类常见问题多说话人场景、专业内容域、时间轴精度。遇到类似问题时优先想清楚“是模型能力问题还是工程链路问题”大部分坑出在后者——模型没做错什么是喂给它的数据形态不对。我个人的体会是不要指望有个模型能一步到位输出完美摘要。ASR加LLM的流水线本质上是把不完美的原始信号一层一层处理到足够可靠的过程。每个环节的容错、校验、兜底才是这套系统真正值钱的地方。如果你也在做类似的事情建议先从几十门小样本把链路跑通再逐步放量。前期慢一点比后期重构划算得多。