企业官网建设流程全解析

最近两年在线课程和企业培训视频越来越多，很多团队仓库里躺着上千小时的录播课，真正能被搜到、被二次利用的内容却少得可怜。我接手过一个内部培训平台，库里压了三千多节课，大部分用户只能靠标题猜内容，想看一个具体知识点就得从头拖进度条。这个痛点催生了一套 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 还是 FunASR

ASR 是整个流水线的地基，转写文本一旦质量差，后续 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-Reduce：Map 阶段每个章节独立总结，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.1，temperature 太高会让模型自由发挥，把"注意力机制"编成"神经网络的注意力机制在自然语言处理中非常重要"，此类扩展不够精准。

3.4 时间戳关联与章节归属：让知识点可点击回跳

知识点只有能定位到视频具体位置，才算真正可用。这套系统的检索体验是：用户在搜索框输入"transformer 结构"，返回的知识点卡片上直接显示"该知识点出现于第 3 章，视频 12:35 处"，点击就跳转到对应画面。要做到这一点，必须在 ASR 阶段保存精确到词的时间戳，然后在文本切分、LLM 提取的每个环节都保留时间戳标记。

我维护了一个简单的时间戳传播规则。ASR 输出是一串带 start 和 end 的分词结果，清洗阶段把这些词合并成句子，句子的 start 为第一个词的 start，end 为最后一个词的 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 高频问题排查表

表格不是万能钥匙，很多问题需要结合日志看。我建议从项目第一天就给每个任务挂上唯一 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 都更管用。