企业官网建设流程全解析

在技术团队做过视频课程知识库、线上课程平台的同学，大概率都遇到过同一个问题：课程视频越来越多，但内容消费的效率始终提不上去。一小时讲座，学员要么开倍速硬看，要么靠人工写摘要、整理大纲，整理一集花的时间经常比课程本身还长。我们团队去年把这条链路彻底自动化了，核心思路用一句话就能讲明白：先用 ASR 把语音转成文本，再用 LLM 做摘要、大纲和知识点抽取，最后把结构化结果送进检索系统。这篇文章就是 ASR + LLM 流水线从技术选型、参数调优到生产落地的完整复盘，适合正在做在线课程、培训素材、会议录像处理，想用大模型改造内容生产流程的工程团队参考。

先声明一下：本文讨论的 ASR 特指自动语音识别（Automatic Speech Recognition），所有模型调用均通过合规接口完成，不涉及灰色工具或非正规渠道。下面的内容不是我第一天就能写出来的，很多结论都是被线上故障逼出来的，希望你能少踩几个坑。

1. 整体设计与技术选型：为什么必须拆成 ASR + LLM 两步

1.1 先想清楚：我们到底要产什么

很多团队一上来就想“把视频直接丢给大模型”，让多模态模型边看画面边听声音，直接输出摘要。这个思路听起来很省事，实际落地会撞上好几堵墙。我们梳理需求后发现，真正要产出的东西其实分两层：一是把一小时口播压缩成三五个自然段落的摘要；二是把课程里的概念、公式、案例、结论逐个摘出来，最好还带时间锚点——用户点击知识点就能跳到视频对应位置。

如果直接喂视频给多模态大模型，推理成本高不说，输出还经常丢失视频中段的内容，更别提准确返回“这句话出现在第几分钟”这种带定位信息的结构化结果。把任务拆成 ASR + LLM 两步之后，每个环节只做自己最擅长的事，出了问题也方便定位。我们的处理链路是固定的：原视频 -> 抽音轨 -> 音频预处理 -> ASR 转写 -> 文本清洗 -> LLM 分段摘要 -> LLM 全局摘要与知识点提取 -> 结构化 JSON 入库 -> 前端渲染与检索索引。

这个链路看上去长，但每一步的输入输出都非常清晰，哪个环节质量不行，单独替换就行。

1.2 技术选型：两条可替换的核心链路

ASR 模块和 LLM 模块是整个系统的两大引擎，选型时不能只盯着榜单数字，要结合自己的课程语言分布、部署预算和隐私要求来定。我们内部做过一轮对比，结论大致这样：

我们最终采用“双 ASR 引擎”架构：ASR 服务层做统一接口，接口内部根据课程语言自动路由。中文课程走 FunASR + Paraformer，英文和混合语言课程走 Whisper。这样做的代价是维护两套模型，但换来的是中文口音和专业术语上的明显提升，这在以国内讲师为主的课程库里非常值。

LLM 层我们没有绑定某一款模型，而是封装成独立 service。摘要和知识点提取这类任务对推理深度的要求不是最高的，7B 到 32B 的开源模型也能跑出不错的 JSON 结构；但如果课程涉及大量数学推导和技术概念，需要严谨推理，闭源大模型或更大参数模型会更稳。真正的工程要点是：把模型选择做成配置项，随时可以替换，而不是把 prompt 和模型强耦合。

1.3 为什么“分段 + 两轮 LLM”是性价比最高的结构

对一小时视频来说，ASR 转出来的纯文本大约有 8000 到 12000 字。一次性把这么多字塞给 LLM，有两个很难受的问题：一是长文本会让模型注意力分散，中段内容容易被“遗忘”，摘要会偏向开头和结尾；二是上下文越长，token 费用越高，线上跑起来成本控制不住。

所以我们采用分段处理加两轮汇总的结构：先把 ASR 文本按语义段落切块，每个 chunk 单独做一次局部摘要（map 阶段），再把所有局部摘要拼成一份“中间稿”，让模型做全局摘要和知识点提取（reduce 阶段）。这种 map-reduce 思路在长文本处理里非常可靠，之后的章节会展开讲切块大小和 prompt 设计的细节。

整体耗时通过并发可以打平，一小时课程从提交到产出结构化结果，实测两到三分钟完成，完全在可接受的范围内。

2. ASR 转写环节的工程化踩坑与调优

2.1 抽音轨与音频预处理：九成转写问题其实出在这里

ASR 转写质量首先由音频决定，不是模型决定。这是我们第一版系统上线后得到的最痛教训。当时我们直接把课程 mp4 丢给 Whisper，结果有相当一部分视频开头几十秒是纯音乐或者远程会议里的环境音，转写输出出现大段莫名其妙的“合理句子”，也就是幻觉。

后来我们把预处理固定成四步，缺一不可：

第一步，抽音轨并统一参数。用 ffmpeg 把视频里的音频抽出来，统一转成 16kHz 采样率、单声道、16bit 位深的 wav 格式。命令很常规：

ffmpeg -i input.mp4 -vn -ac 1 -ar 16000 -sample_fmt s16 output.wav

不统一采样率的话，有的视频是 44.1kHz，有的是 48kHz，ASR 模型处理时性能会波动。

第二步，响度归一化。不同讲师录课的音量差异非常大，有人离麦克风远，整节课音量偏低，直接转写时识别率会明显下降。我们用 ffmpeg 的 loudnorm 滤镜把整体响度拉平，确保模型吃到的音频能量稳定。

第三步，降噪。用高通滤波或者 RNNoise 去掉环境底噪、电流声。这里特别提醒一句：别过度降噪。我们曾经用很强的降噪参数处理一段带轻微键盘声的课程，结果人声的齿音和尾音也被削掉，转写准确率反而下降。降噪的目标是“去掉明显噪声，保留人声完整”。

第四步，VAD 切分。用 silero-vad 或 FunASR 自带的 VAD（语音活动检测）模型，把长音频切成 10 到 30 秒的片段，再逐段送识别。直接拿 1 小时音频让 Whisper 处理，模型内部要对整个长上下文做注意力计算，中后段经常漏字。切成短片段后，每段独立识别，准确率提升非常明显，这是走过弯路之后确定的稳定方案。

2.2 并发调度与 GPU 使用：吞吐量和延迟要平衡

ASR 推理有个特点：单条音频推理不算慢，但多条音频凑成 batch 一起跑，GPU 吞吐能翻好几倍。我们在调度上的做法是：

• 同一个视频的多个 VAD 片段组成一个批次，并发转写；
• 不同视频的任务进队列，按优先级调度，直播回放优先于历史归档；
• 每个任务设置超时和最大重试次数，超过三次自动进入人工复核队列。

这里要注意一个细节：为了追求吞吐量把所有片段都无限等待凑批，单个任务的首包返回时间会变得很长，体感就是转写迟迟不出结果。所以我们给每批设置了最大等待窗口，比如两秒内攒够四片就立刻推理，没有攒满也按时发出。吞吐和延迟之间要取平衡，不要极端优化。

2.3 转写质量的事后修正：热词、错词替与标点修复

ASR 永远会出错，尤其是课程里的专业术语。我们要接受这个现实，然后分三个层次去补：

第一层，识别前挂热词表。FunASR 支持自定义热词权重，Whisper 可以在 initial prompt 里塞课程标题和高频关键词。实测下来，把讲师反复提到的概念提前喂给模型，常见术语的谐音错误率能下降三成以上。

第二层，识别后做错词修正。用规则维护一张“高频误识别替换表”，比如某个课程里“Transformer”被识别成“变革者”，直接通过替换表拉回来。这类表需要从真实错误样本里积累，前期人工盯一段时间是值得的。

第三层，标点与分句修复。ASR 输出经常没有标点，或者标点乱加。我们用 LLM 做一轮轻量的“清洗 + 加标点 + 分句”任务，同时删除明显重复的句子。这一步用很小的模型就能做好，不占用主模型的资源。

这里再多说一句 Whisper 的参数感受：temperature 降到 0 确实能减少自由发挥式的幻觉，但在口音很重的音频上，温度设为 0.2 左右反而能生成多个候选结果，再挑最优路径，整体效果更好。参数不是越小越好的，要按数据情况调。

2.4 时间戳对齐：给每个知识点打上定位锚点

只有摘要没有定位，产品价值会少掉一大截。用户经常想点击摘要里的知识点，直接跳到视频对应位置。所以 ASR 不仅要输出文本，还要输出时间信息。Whisper 支持 word-level timestamps，FunASR 也支持时间戳输出。

我们的做法是：把 word-level 时间戳聚合成 sentence-level 时间戳，便于前端渲染和检索定位；对 ASR 文本按句对齐到原视频播放时间，并做一个偏移校准——比如片头广告、延迟开讲的空场都要考虑进去。校准逻辑不复杂，但一定要做，否则前端跳转永远差三到五秒，用户体验会很差。

3. LLM 摘要与知识点提取的 Prompt 设计

3.1 让模型永远输出 JSON，别跟自然语言搏斗

LLM 输出解析是这套系统里最早折磨我们的环节。模型天然会说自然语言，但我们后端要的是能直接入库的结构化数据。前期我们让模型输出 Markdown 再正则解析，效果惨不忍睹，只要模型稍微换个列表格式，解析就崩。

后来我们统一改成强制 JSON 输出，在 system prompt 里明确写：只输出 JSON，不输出任何解释性文本。同时定义好 JSON Schema，让模型按固定结构填充：

{ "title": "课程标题", "duration_minutes": 52, "summary": "课程摘要，不超过300字", "key_points": [ { "point": "知识点一句话描述", "timestamp_seconds": 1260 } ], "keywords": ["关键词1", "关键词2"] }

在调用参数里开启 JSON response format 或者生成多个候选结果，取第一个可解析的 JSON。如果解析失败，用低温度重试一次，再用正则从返回值里提取 JSON 片段兜底。这套组合下来，输出解析成功率能稳定在 99% 以上。

3.2 两段式摘要：长文本处理的经典思路

直接让模型“总结这一小时课程”，结果往往空泛。我们改成先分段总结，再全局总结。

具体做法是：把 ASR 文本按语义段落切成 chunk，每个 chunk 大约 800 到 1200 字，过长就再切，尽可能保持一个完整知识点不被拆散。每个 chunk 单独调用 LLM，生成两三百字的 mini-summary。然后把这些 mini-summary 拼在一起，作为第二轮的输入，让模型生成最终的全局摘要、关键知识点和关键词。

这样处理有三个好处：一是长文本被切到模型处理得动的范围内，上下文不会溢出；二是每个局部摘要在并发下是同时进行的，整体吞吐不差；三是全局摘要基于局部分析生成，不会出现只覆盖前十分钟内容这种偏科现象。我们第一次用这个结构跑一批历史课程后，明显感觉摘要的完整度比单轮直出高很多。

3.3 知识点提取的粒度：分类别、去重、防空话

课程知识点并不是同质的。我们让模型按“概念定义 / 公式与推导 / 案例 / 结论 / 易错点”五类分别提取，这样比笼统地说“提取知识点”效果稳定得多。Prompt 里还明确要求：每个知识点用一句完整的话写清楚，使用具体名词和数字，不要出现“本课程介绍了”这类空话。

举个例子，如果模型输出“本课程介绍了注意力机制”，这就是不合格的。我们希望它输出“注意力机制通过计算 query 和 key 的相似度，决定 value 的加权权重，核心公式为 Attention(Q,K,V) = softmax(QK^T / sqrt(d_k))V”。后者有概念、有细节，甚至可以直接当复习卡片用。

提取完还会有相似知识点反复出现的问题。我们用 embedding 模型计算相邻知识点的语义相似度，相似度高于 0.92 的自动去重，保留信息最全的那条。这套去重逻辑不复杂，但能显著提升知识点的可读性。

3.4 Token 预算与输出长度控制

做这套系统，脑子里必须时刻有一本 token 账。量化一下：1 小时中文课程的 ASR 文本约 9000 到 12000 字，中文每字大致对应 1 到 2 个 token，原始文本在 10000 到 20000 token 之间。如果不分段处理，一轮调用的成本就很可观，还容易超上下文窗口。

分段处理之后，每个 chunk 的输入控制在 3000 token 以内，全局总结的输入约 3000 到 4000 token，整门课的总消耗变得非常可控。

Prompt 里一定要限制输出长度。我们的设定是：summary 不超过 300 字；一篇课程的 key_points 不超过 12 条；每条 point 不超过 50 字。限制输出长度不只是为了省钱，更是为了保证下游渲染稳定，避免前端被超长字段撑坏。模型参数方面，温度 0.3、top_p 0.7 是我个人比较习惯的组合，结果在稳定性和多样性之间比较均衡。

4. 工程落地：异步任务队列、缓存与检索闭环

4.1 流程必须异步化，不能做同步接口

视频转写加摘要的耗时动辄几分钟，不可能做成同步 HTTP 接口。我们把这套流程拆成异步任务，队列用 Redis Stream，任务类型分成 extract_audio、transcribe、clean_text、summarize、index 五类。

每个任务都有完整的状态流转：pending -> running -> succeeded / failed。失败的任务自动重试，重试退避策略是 1 分钟、5 分钟、30 分钟递增，重试三次后进入死信队列，由人工排查。

异步化带来的一个明显好处是扩缩容很灵活。ASR 和 LLM 是两套独立 worker，可以分别扩机器。视频上传高峰时多开几个转写 worker，模型调用积压时多开 LLM worker。每个 worker 的并发数、内存上限、单任务超时时间都是配置项，不用动代码。

4.2 缓存三件套：音频指纹、ASR 文本、LLM 结果

很多课程视频存在重复上传、改版重传的情况。不加缓存的话，同一门课会被反复转写、反复总结，纯属烧钱。我们设计了三级缓存：

第一级是音频级缓存。给每个源视频算音频感知哈希，简单做法是对音频分帧提取频谱特征再哈希。直接对视频文件算 MD5 是不可靠的，因为转码重封装会让文件哈希变化，但内容没变。

第二级是文本级缓存。ASR 文本清洗前后都存下来，方便追溯。如果发现某段转写质量有问题，可以直接在文本层面修正并重新触发后续流程。

第三级是模型结果缓存。LLM 的输出按文本哈希加模型版本缓存，切换模型时整体失效。这层缓存带来的成本节省非常可观，实测能减少三成以上的重复计算。

4.3 对接检索与问答：让摘要和知识点真正被用起来

摘要如果只是存进数据库展示，价值会小很多。我们把它接进了知识库检索，形成了人找知识、知识找人的闭环。

每个知识点在数据库中存成一条独立记录，metadata 带上课程 ID、章节号、时间戳、关键词等字段。用 embedding 模型把知识点向量化，存入向量数据库，比如 pgvector 就能满足需求。用户提问时，系统先做向量检索，召回相关知识点，再让 LLM 基于召回内容组织回答，回答末尾附上“来源课程 + 时间点”，用户点击即可跳转。

这正好解释了为什么前面要花那么大力气做结构化 JSON：只有把知识点拆成独立条目，检索系统才能做到精准定位，而不是给用户一整页摘要让人自己找。

4.4 质量评估：摘要好不好，不能只靠感觉

摘要质量评估是这类系统的老大难问题。我们用的是人工抽检加自动指标的组合策略。

人工抽检方面，每周随机抽 20 节课，让人工对照转写文本检查摘要是否准确、知识点是否遗漏。自动指标方面，看关键词覆盖率，也就是课程标题和讲师强调的词有没有在摘要里出现；看知识点条数分布，比如一门课少于 3 条或超过 20 条都要怀疑异常；看时间锚点有效性，统计点击后用户停留在对应位置的时长。

现在很多团队喜欢用 LLM-as-judge 做自动评分，我们也试过，但发现打分 prompt 必须设计得足够细，否则分数会漂移，同一个摘要换个 prompt 就从 8 分变 4 分。这部分我们还在完善，不建议一开始就依赖自动评分来决定质量。

5. 常见问题与排查技巧实录

5.1 转写结果出现幻觉内容

最典型的场景是音频里只有音乐或静音，ASR 却输出一大段“合理”但完全不存在的句子。排查思路是先看 VAD 是否漏掉了静音段，再看置信度分布。

我们的解决方案有两个：一是在 ASR 输入里加入提示词“背景音乐、静音”，让模型知道当前音频可能是无效内容；二是在后处理环节过滤低置信度段落，置信度低于阈值的文本直接丢弃，不进下游 LLM。幻觉数据一旦进了知识库，比识别错误更可怕，因为它会污染检索结果。

5.2 摘要过于空泛，像“正确的废话”

摘要输出“本课程介绍了人工智能的基本概念和发展历程”，这种内容对用户毫无价值。排查时先看 prompt 里是否明确要求使用具体名词和数字，再检查示例是否给到位。

我们在 prompt 里加了一句很有效的话：“像给同事转述这节视频的重点，使用具体名词和数字，只写内容本身，不要做总结性评价。”同时放了一个 good / bad 示例，模型立刻就理解了。few-shot 示例在摘要任务里比调整 temperature 有用得多。

5.3 长视频超时或内存暴涨

视频超过两小时后，单任务很容易触发超时或内存限制。我们的解决办法是把任务按课程章节或时间区间拆成子任务，先转写子串，再做 merge 式总结。同时给 worker 设置内存上限和单任务时长上限，宁可拆任务也不让进程被拖垮。

5.4 LLM 返回内容解析失败

JSON 解析失败是上线初期的高频故障，因为模型偶尔会在 JSON 前后夹带 Markdown 代码块或解释性文字。我们做了三层防护：优先使用结构化输出接口，让模型按 JSON Schema 生成；解析失败后降温度重试一次；最后兜底用正则提取 JSON 片段，如果还不行就直接降级为纯文本摘要入库，不让任务白白失败。

5.5 问题排查速查表

最后说几句实际体会

这套 ASR + LLM 流水线跑了大半年，我最深的感受是：真正的工程量不在模型本身，而在模型前后的数据治理。先把音频预处理做扎实，再谈模型选型和 prompt 优化；先把转写文本的结构化做好，再谈摘要质量。如果你准备从零开始做类似系统，我建议不要一上来就追求全自动，先拿三五节不同类型课程跑通链路，人工盯几遍 ASR 输出，积累一份自己的错词表和常见问题清单，再逐步放量。知识点的时间锚点这个设计，是我们整个系统里用户反馈最好的一块功能，要是重新做一次，我会更早把它加进去。