尧图网站建设 
简介这是一份以DeepSeek视频理解技术为核心的教学视频分析方案PDF文档面向教育技术研究者、AI算法工程师及教学视频平台产品人员针对教学视频中关键教学点难以自动定位、内容缺乏结构化组织等痛点提供从技术原理到工程落地的完整解决思路。文档共394页压缩包内只有一个PDF文件约12.9MB支持目录章节跳转与书签大纲快速定位排版完整清晰。内容覆盖45个章节从前20章即可看到完整技术链路包括视频理解底层原理拆解、教学视频数据预处理、帧级特征提取、音频轨道分离、语音转文字、文本语料清洗、多模态特征融合、音视频与文本时间轴对齐、关键教学点定义与候选区域筛选以及浅层深层语义匹配、技术术语识别、教学动作与互动场景识别、无监督预训练等关键环节并配有标注规范、评估指标与工程优化方法。这份材料可作为教学视频结构化分析项目落地的系统参考框架便于按模块查阅和复用。目前已有64人学习下载。1. 教学视频分析落到 DeepSeek 上真正要解决的是对齐问题在线课程、教师实录、教研录像这类素材最尴尬的不是“没有内容”而是“内容无法检索”。一节课 40 到 60 分钟人工把知识切片、标注重点通常要花掉两倍以上的时间纯字幕文件又只能保留台词板书、PPT 翻页、实验演示动作全部丢失。这个标题把 DeepSeek、视频理解、关键教学点自动提取和结构化标注放在一起典型的解决路径是先通过视频理解技术把画面和音频变成“带时间戳的文本语义”交给 DeepSeek再用提示词约束模型输出 JSON 结构最后回填时间轴生成可检索、可跳转、可同步到素材库的教学知识结构。这套方案适合课程平台研发、教研中台、知识库团队也适合正在做本地视频资产整理的运维和算法工程师。比较反直觉的一点是视频理解模型在这里通常不承担“总结”工作它的职责是去噪和对齐真正做提取和结构化的是 DeepSeek。只要对齐做不好后面再怎么调提示词得到的也只是一堆没有位置参照的文字草稿。2. 视频理解管线搭法先把音轨和画面语义变成 DeepSeek 能读的时间线DeepSeek 本身是文本模型不能直接“看”视频。所以工程上说的视频理解要先拆成两条相互独立的信号流一条是音频转写后的讲义文本另一条是抽帧后由多模态视觉模型生成的画面描述。两条流都保留起始时间秒数再交给 DeepSeek 做跨模态合并。这样既避开了让大模型直接处理高维视频输入的算力成本也能在纯文本链路上做格式控制、缓存和重试。2.1.1 用 ffmpeg 抽帧和 faster-whisper 拿时间戳文本音频处理建议直接认准 whisper 的工程化实现。先看命令# 抽关键帧8 秒一帧长边缩到 1280JPEG 质量拉高保证板书可读 ffmpeg -i lecture.mp4 -vf fps1/8,scale1280:-1 -q:v 2 frames/%04d.jpg这个命令里fps1/8表示每 8 秒抽一帧。对于正常语速的课堂教学8 秒是经验起点如果课程以 PPT 讲解为主板书停留时间在 20 秒以上可以放宽到 15 秒如果是实验课或白板推导公式会快速更新建议改到 4 秒一帧。scale1280:-1把画面等比缩到 1280 宽度视觉模型输入分辨率太高会显著增加显存和耗时但太低又看不清公式下标1280 是一个折中值。-q:v 2控制 JPEG 质量范围是 2 到 31数值越小越好2 在这个场景下几乎无可见压缩损失。抽帧之后的音频侧用 faster-whisper 转写它比原始 openai-whisper 在 CPU 上快很多也多 GPU 半精度支持from faster_whisper import WhisperModel model WhisperModel(medium, devicecuda, compute_typefloat16) segments, info model.transcribe( lecture.mp4, languagezh, vad_filterTrue, beam_size5, ) for seg in segments: print(f{seg.start:.1f}\t{seg.end:.1f}\t{seg.text})参数里devicecuda是显式指定 GPUcompute_typefloat16可以显著降低显存占用medium 模型在 8 GB 显存上基本可跑。vad_filterTrue会先用语音活动检测跳过片头音乐、静音段和长时间翻书声避免产生无意义的空转写片段。beam_size5是解码宽度越大精度越高但速度越慢教学场景 3 到 5 都够用。2.1.2 用视觉模型给每一帧补一句“画面语义”抽出的关键帧需要转成一段短文本。这里不建议自己训练模型直接用现成的图像描述或轻量级 VLM 即可from transformers import pipeline cap pipeline( image-to-text, modelQwen/Qwen2-VL-2B-Instruct, ) frame_desc cap( frames/0001.jpg, generate_kwargs{max_new_tokens: 200}, )[0][generated_text]这段代码输出的frame_desc可能像“黑板左侧写着勾股定理公式右侧有直角三角形教师在图中标出直角符号”。注意这里的max_new_tokens不要开太大200 token 足够描述一帧过大反而会产生模型自己的推断把画面没有的信息写进去干扰后续关键教学点判定。画面描述生成后要和音频转写片段按时间轴对齐。常见做法是把抽帧时间点作为中心向两侧各扩展 3 秒找到所有与该时间区间有交集的 whisper 片段拼成一个结构体。2.1.3 DeepSeek 接入API 调用与本地部署的取舍DeepSeek 的兼容层是 OpenAI SDK这是整个管道里最值得确定的部分。官方 API 的调用方式以deepseek-chat为主所有文本提取任务都走同一套接口from openai import OpenAI client OpenAI( api_keyDEEPSEEK_API_KEY, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是教学视频分析助手。}, {role: user, content: 请提取关键教学点。}, ], temperature0.2, max_tokens2048, streamFalse, ) print(resp.choices[0].message.content)base_url一定不能写错拼成https://api.deepseek.com/v1也兼容但官方开放平台文档推荐的根路径就是https://api.deepseek.com。temperature0.2是结构化提取任务的最常用温度太低容易让模型在格式上变得死板太高则会在 JSON 内容中引入随机解释。max_tokens2048要按“一次传入一个课堂教学片段”来估算通常一个 10 分钟片段的提取结果不会超过 1500 token。如果你在私有网络环境部署或者需要压测大量视频本地部署是更可控的选择。常见做法是先在小参数模型上跑通流程再换更大模型做批量。本地服务也可以用 OpenAI SDK 接入只需要把base_url改成http://localhost:8000/v1消息格式完全不变。VSCode 里调试提示词时也可以直接把这个地址配进支持自定义端点的编辑器和客户端重点不是“接哪套 UI”而是让所有端都统一走同一条 OpenAI 兼容协议。另外要考虑 API 的限流和偶发超时。视频分析是长时间批处理任务不适合交互式调用。在真实项目中我会给每个请求包一层指数退避重试最多重试 5 次并把失败的视频记录到单独的待重跑队列。表格里是管线各环节的关键参数和推荐值模块关键参数推荐值配置说明抽帧fps1/8 到 1/15依据板书变化频率调整抽帧scale1280 宽边平衡清晰度与模型输入转写modelmedium中文教学足够large 更高但慢转写vad_filterTrue过滤静音与噪声段视觉描述max_new_tokens200只保留画面客观信息DeepSeek 调用temperature0.2控制随机性DeepSeek 调用max_tokens2048覆盖单片段提取结果3. 关键教学点自动提取用 DeepSeek 提示词把自由文本变成教学结构教学视频和普通视频最大的差异是“知识点密度高且有明显层次”。老师可能用 10 分钟讲同一个定理中间穿插例题、易错提醒和板书推导。这种情况下如果只让模型输出“内容摘要”得到的结果根本无法指导学习者精确回看。关键教学点的提取本质上是把连续视频切成有语义标签的段落。3.1.1 教学点类型要由业务方先定义提示词工程的第一步不是写 prompt而是定义教学点的类型枚举。类型定义越具体模型输出的 JSON 越稳定后续查询和素材组织越容易。一般课程需要这几个类型concept概念讲解、procedure步骤方法、example例题演示、misconception易错点辨析、checkpoint互动提问、summary总结回顾。这里先给一张类型判据表后续提示词会直接引用这些判据类型提取判据典型句子concept老师明确给出定义或条件“这就是勾股定理注意它只适用于直角三角形”procedure解题步骤或操作顺序“第一步先求平方第二步再比较斜边”example具体题目或实例计算“以 3 和 4 为例斜边等于 5”misconception出现错误、纠正、强调边界条件“很多同学这里会漏掉平方符号”checkpoint提问让学生回答或暂停思考“大家想一下如果不是直角三角形还能用吗”summary回顾本节知识点“今天我们讲了三个关键点”3.1.2 两阶段 Prompt先抽取候选片段再合并去重一次调用完成所有工作容易导致教学点粒度不一致。我会拆成两个阶段第一阶段让 DeepSeek 在单个时间片段里抽取候选点第二阶段把多个候选点合并且统一编号。第一阶段的 system prompt 写成这样你是教学视频标注助手。用户会给你一个带时间戳的文本片段和画面描述。 请抽取其中“老师明确强调、值得学习者回看”的最小语义单元。 只输出 JSON{key_points: [{type: ..., start: 秒, end: 秒, title: ..., reason: ...}]} 时间戳必须使用输入片段中出现的秒数范围。注意最后一句“时间戳必须使用输入片段中出现的秒数范围”。如果视频片段本身是 120 秒到 186 秒那么模型输出的 start 和 end 只能落在 [120, 186] 这个区间不能在原始视频时间轴上自由猜测。这一步能去掉大量时间戳漂移问题。调用时的 user message 用模板拼装。脚本里我通常会写成def build_user_prompt(chunk): return ( f视频时间段: [{chunk[start]} - {chunk[end]}] 秒\n f讲义文本: {chunk[text]}\n f画面描述: {chunk[frame_desc]}\n 输出完整 JSON。 )字段顺序是有讲究的先给时间边界再给文本和画面描述最后是格式要求。这样模型在生成时后面的 JSON 字段会自然地参照前面已出现的时间数字。实测中这种顺序比“文本在前、时间在后”的时间戳命中率更高。第二阶段把同一节课的所有候选点丢给 DeepSeek 做合并。系统指令只有两句话合并重复的关键教学点。判断标准内容主题相同且时间区间重叠超过 60% 时只保留 reason 更完整、时间范围更大的那一条。输出与原 JSON 相同的结构。这一步能解决滑动窗口切片的边界重复问题。比如同一个例题跨越两个窗口第一段结尾讲了一半第二段开头重复讲述候选点会几乎相同地出现两次第二阶段就是去重的最后防线。3.1.3 JSON 输出失败的兜底策略即便有response_format{type: json_object}也不能保证每一条输出都是合法 JSON。模型偶尔会多输出一个尾部说明或者把层叠引号写错。处理方式不是反复重试而是先用正则提取外层 JSONimport json import re def parse_json_response(content): start content.find({) end content.rfind(}) if start -1 or end -1: raise ValueError(no json) return json.loads(content[start:end 1])这个兜底逻辑在多轮批量任务中能显著降低失败率。注意find和rfind搭配使用find找第一个左花括号rfind找最后一个右花括号可以容忍模型在输出前后追加解释性文字。4. 内容结构化标注落地从 JSON 到 Obsidian 素材库和时间轴跳转自动提取出的关键教学点如果只是写进一个 Excel 或 JSON 文件价值会大打折扣。结构化标注的最终目的是让教研人员能够在素材库中按“课程、主题、类型、时间位置”快速找到片段同时能跳回原视频。因此标注格式必须同时适合程序读取和 Markdown 编辑器浏览。4.1.1 以 JSONL 作为中间格式每一堂课处理完成后会生成一条 JSONL每条记录代表一个关键教学点。字段固定为id、video_id、type、start_sec、end_sec、title、reason、frame_desc、created_at。示例{id: KP-001, video_id: L01, type: concept, start_sec: 120, end_sec: 186, title: 勾股定理适用条件, reason: 老师强调只在直角三角形成立, frame_desc: 黑板上有直角三角形直角标记清晰, created_at: 2025-01-15T10:00:00Z} {id: KP-002, video_id: L01, type: example, start_sec: 202, end_sec: 278, title: 3-4-5 验证勾股定理, reason: 完整计算过程中演示公式使用, frame_desc: 幻灯片显示题目与计算过程, created_at: 2025-01-15T10:00:00Z}把数据存成 JSONL 而不是一个巨大的 JSON 数组最直接的好处是可以逐行追加、逐行解析批量入库失败时只需要重跑失败行。每个字段都有明确长度和类型最终导入 SQLite、PostgreSQL 或观测数据库都很容易。4.1.2 生成 Obsidian 可用的时间轴素材库Obsidian 对视频片段支持用时间戳链接实现跳转。针对每个关键教学点生成一个 Markdown 卡片文件结构按课程/节/知识点三层组织。--- type: concept video: L01 start_sec: 120 end_sec: 186 tags: [数学, 勾股定理] --- # 勾股定理适用条件 **时间**[[L01.mp4#t120,186]] **教学类型**概念讲解 老师强调这个定理只在直角三角形中成立。时间戳链接的语法格式是[[视频文件名#t起始秒]]如果希望视频自动停止可以写成#t120,186这种带结束时间的写法Obsidian 在播放时支持这个定位。生成脚本只需要拼接字符串即可def to_obsidian(item): title item[title] sec f#t{item[start_sec]},{item[end_sec]} return f[[{item[video_id]}.mp4{sec}]] {title}这里最实用的技巧是给数字补零到三位例如120直接转成120没问题但如果是 15 秒建议写成#t15,78。不同播放器对t参数的解析差异不大Obsidian 本身都能识别。务必保证video_id和实际文件名完全一致否则链接在素材库中会变成无法跳转的纯文本。4.1.3 向量检索让“回看哪一段”变成语义查询当结构化标注数量积累到上百节课程之后按类型和时间轴找片段已经不够用。更常见的搜索句式是“讲过的平方和公式的易错题”这需要向量检索。建议用本地向量库完成避免频繁调用外部接口增加延迟和成本。以 Chroma 为例import chromadb from chromadb import Documents, EmbeddingFunction, Embeddings client chromadb.PersistentClient(path./teaching_db) collection client.get_or_create_collection( nameteaching_points, metadata{hnsw:space: cosine}, ) collection.add( ids[KP-001, KP-002], documents[勾股定理适用条件, 3-4-5 验证勾股定理], metadatas[ {type: concept, video_id: L01, start_sec: 120}, {type: example, video_id: L01, start_sec: 202}, ], ) results collection.query( query_texts[斜边的平方等于什么], n_results5, )metadata{hnsw:space: cosine}是让向量检索用余弦相似度适合教学视频中的短文本映射查询时n_results设置为 5是因为一个知识点通常有多个冗余说法取前 5 之后的片段主题相关性会明显下降。需要说明的是这里嵌入向量模型和 DeepSeek 是分开的。DeepSeek 负责理解视频语义并生成结构化文本嵌入模型负责把生成结果映射为向量。两者各干各的避免在同一模型上又做生成又做检索否则系统会非常笨重。使用场景数据格式检索方式人工翻阅教研素材Markdown 卡片Obsidian 时间戳链接机器批量审核JSONL逐行解析入库语义查询Chroma 向量库余弦相似度精确回看[[视频#tstart,end]]播放器跳转5. 用回归集验证提取质量时间重叠、漂移与字段缺失结构化标注系统最容易出现的问题不是“提取不出来”而是版本更新后输出格式悄悄地变化。比如换了模型版本或改了一条提示词JSON 字段名变了、时间戳重叠了、同一知识点重复出现了。提高质量之前先要建立一整套可重复执行的回归验证。回归集不要选整节 40 分钟的课建议从每个课程类别中各选 3 到 5 分钟小段组成一个总量 15 分钟的验证集。基准是人工标注结果。每次修改提示词或更换模型后跑一遍同样的视频用脚本对比新旧结果。检查重点是时间重叠率和重复率。一个最小的时间重叠检查如下def find_overlaps(items, tolerance3.0): ordered sorted(items, keylambda x: x[start_sec]) for i in range(len(ordered) - 1): cur ordered[i] nxt ordered[i 1] if nxt[start_sec] cur[end_sec] - tolerance: yield (cur[id], nxt[id], cur[end_sec] - nxt[start_sec])tolerance3.0表示允许两个教学点之间最多有 3 秒时间重叠如果重叠超过这个值说明两个片段边界划分存在问题。正常教学视频中相邻知识点之间存在教师停顿或过渡语句3 秒足够覆盖这些自然间隔。指标建议关注三个时间漂移、重复率和 JSON 解析成功率。时间漂移用抽样的方式人工核对比如随机抽 20 条关键点比较机器给出的时间戳与被截取视频对比人工找到的时间点漂移超过 6 秒则判定失败。重复率计算回归结果中重叠片段对数量除以总片段数建议控制在 5% 以下。JSON 解析成功率要求在 100 条测试样例中不低于 98%低于这个值说明提示词或参数存在不稳定性需要调整。回归集可以做成一个pytest测试用例读入 New JSON 输出和基准 golden JSON逐项比较字段存在性、start_sec 是否落在对应片段区间、播放链接能否解析出有效的视频文件名。把这个测试挂到 CI 流水线每次改动提示词就自动跑一遍可以用定时任务对线上新增视频做每日抽样回归保证新模型版本不会引入批量错误。真正要盯住的两条曲线是 overlap 数量和 keypoint_count 数量前者反映边界质量后者反映是否存在大规模漏检。当这两条曲线与基准曲线偏离超过 20% 时立刻冻结模型版本并回滚提示词而不是等到课程入库后才发现整节课的标注结构已经变了。本文还有配套的精品资源点击获取 DeepSeek驱动教学视频关键点自动提取与结构化标注方案
简介这是一份以DeepSeek视频理解技术为核心的教学视频分析方案PDF文档面向教育技术研究者、AI算法工程师及教学视频平台产品人员针对教学视频中关键教学点难以自动定位、内容缺乏结构化组织等痛点提供从技术原理到工程落地的完整解决思路。文档共394页压缩包内只有一个PDF文件约12.9MB支持目录章节跳转与书签大纲快速定位排版完整清晰。内容覆盖45个章节从前20章即可看到完整技术链路包括视频理解底层原理拆解、教学视频数据预处理、帧级特征提取、音频轨道分离、语音转文字、文本语料清洗、多模态特征融合、音视频与文本时间轴对齐、关键教学点定义与候选区域筛选以及浅层深层语义匹配、技术术语识别、教学动作与互动场景识别、无监督预训练等关键环节并配有标注规范、评估指标与工程优化方法。这份材料可作为教学视频结构化分析项目落地的系统参考框架便于按模块查阅和复用。目前已有64人学习下载。1. 教学视频分析落到 DeepSeek 上真正要解决的是对齐问题在线课程、教师实录、教研录像这类素材最尴尬的不是“没有内容”而是“内容无法检索”。一节课 40 到 60 分钟人工把知识切片、标注重点通常要花掉两倍以上的时间纯字幕文件又只能保留台词板书、PPT 翻页、实验演示动作全部丢失。这个标题把 DeepSeek、视频理解、关键教学点自动提取和结构化标注放在一起典型的解决路径是先通过视频理解技术把画面和音频变成“带时间戳的文本语义”交给 DeepSeek再用提示词约束模型输出 JSON 结构最后回填时间轴生成可检索、可跳转、可同步到素材库的教学知识结构。这套方案适合课程平台研发、教研中台、知识库团队也适合正在做本地视频资产整理的运维和算法工程师。比较反直觉的一点是视频理解模型在这里通常不承担“总结”工作它的职责是去噪和对齐真正做提取和结构化的是 DeepSeek。只要对齐做不好后面再怎么调提示词得到的也只是一堆没有位置参照的文字草稿。2. 视频理解管线搭法先把音轨和画面语义变成 DeepSeek 能读的时间线DeepSeek 本身是文本模型不能直接“看”视频。所以工程上说的视频理解要先拆成两条相互独立的信号流一条是音频转写后的讲义文本另一条是抽帧后由多模态视觉模型生成的画面描述。两条流都保留起始时间秒数再交给 DeepSeek 做跨模态合并。这样既避开了让大模型直接处理高维视频输入的算力成本也能在纯文本链路上做格式控制、缓存和重试。2.1.1 用 ffmpeg 抽帧和 faster-whisper 拿时间戳文本音频处理建议直接认准 whisper 的工程化实现。先看命令# 抽关键帧8 秒一帧长边缩到 1280JPEG 质量拉高保证板书可读 ffmpeg -i lecture.mp4 -vf fps1/8,scale1280:-1 -q:v 2 frames/%04d.jpg这个命令里fps1/8表示每 8 秒抽一帧。对于正常语速的课堂教学8 秒是经验起点如果课程以 PPT 讲解为主板书停留时间在 20 秒以上可以放宽到 15 秒如果是实验课或白板推导公式会快速更新建议改到 4 秒一帧。scale1280:-1把画面等比缩到 1280 宽度视觉模型输入分辨率太高会显著增加显存和耗时但太低又看不清公式下标1280 是一个折中值。-q:v 2控制 JPEG 质量范围是 2 到 31数值越小越好2 在这个场景下几乎无可见压缩损失。抽帧之后的音频侧用 faster-whisper 转写它比原始 openai-whisper 在 CPU 上快很多也多 GPU 半精度支持from faster_whisper import WhisperModel model WhisperModel(medium, devicecuda, compute_typefloat16) segments, info model.transcribe( lecture.mp4, languagezh, vad_filterTrue, beam_size5, ) for seg in segments: print(f{seg.start:.1f}\t{seg.end:.1f}\t{seg.text})参数里devicecuda是显式指定 GPUcompute_typefloat16可以显著降低显存占用medium 模型在 8 GB 显存上基本可跑。vad_filterTrue会先用语音活动检测跳过片头音乐、静音段和长时间翻书声避免产生无意义的空转写片段。beam_size5是解码宽度越大精度越高但速度越慢教学场景 3 到 5 都够用。2.1.2 用视觉模型给每一帧补一句“画面语义”抽出的关键帧需要转成一段短文本。这里不建议自己训练模型直接用现成的图像描述或轻量级 VLM 即可from transformers import pipeline cap pipeline( image-to-text, modelQwen/Qwen2-VL-2B-Instruct, ) frame_desc cap( frames/0001.jpg, generate_kwargs{max_new_tokens: 200}, )[0][generated_text]这段代码输出的frame_desc可能像“黑板左侧写着勾股定理公式右侧有直角三角形教师在图中标出直角符号”。注意这里的max_new_tokens不要开太大200 token 足够描述一帧过大反而会产生模型自己的推断把画面没有的信息写进去干扰后续关键教学点判定。画面描述生成后要和音频转写片段按时间轴对齐。常见做法是把抽帧时间点作为中心向两侧各扩展 3 秒找到所有与该时间区间有交集的 whisper 片段拼成一个结构体。2.1.3 DeepSeek 接入API 调用与本地部署的取舍DeepSeek 的兼容层是 OpenAI SDK这是整个管道里最值得确定的部分。官方 API 的调用方式以deepseek-chat为主所有文本提取任务都走同一套接口from openai import OpenAI client OpenAI( api_keyDEEPSEEK_API_KEY, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是教学视频分析助手。}, {role: user, content: 请提取关键教学点。}, ], temperature0.2, max_tokens2048, streamFalse, ) print(resp.choices[0].message.content)base_url一定不能写错拼成https://api.deepseek.com/v1也兼容但官方开放平台文档推荐的根路径就是https://api.deepseek.com。temperature0.2是结构化提取任务的最常用温度太低容易让模型在格式上变得死板太高则会在 JSON 内容中引入随机解释。max_tokens2048要按“一次传入一个课堂教学片段”来估算通常一个 10 分钟片段的提取结果不会超过 1500 token。如果你在私有网络环境部署或者需要压测大量视频本地部署是更可控的选择。常见做法是先在小参数模型上跑通流程再换更大模型做批量。本地服务也可以用 OpenAI SDK 接入只需要把base_url改成http://localhost:8000/v1消息格式完全不变。VSCode 里调试提示词时也可以直接把这个地址配进支持自定义端点的编辑器和客户端重点不是“接哪套 UI”而是让所有端都统一走同一条 OpenAI 兼容协议。另外要考虑 API 的限流和偶发超时。视频分析是长时间批处理任务不适合交互式调用。在真实项目中我会给每个请求包一层指数退避重试最多重试 5 次并把失败的视频记录到单独的待重跑队列。表格里是管线各环节的关键参数和推荐值模块关键参数推荐值配置说明抽帧fps1/8 到 1/15依据板书变化频率调整抽帧scale1280 宽边平衡清晰度与模型输入转写modelmedium中文教学足够large 更高但慢转写vad_filterTrue过滤静音与噪声段视觉描述max_new_tokens200只保留画面客观信息DeepSeek 调用temperature0.2控制随机性DeepSeek 调用max_tokens2048覆盖单片段提取结果3. 关键教学点自动提取用 DeepSeek 提示词把自由文本变成教学结构教学视频和普通视频最大的差异是“知识点密度高且有明显层次”。老师可能用 10 分钟讲同一个定理中间穿插例题、易错提醒和板书推导。这种情况下如果只让模型输出“内容摘要”得到的结果根本无法指导学习者精确回看。关键教学点的提取本质上是把连续视频切成有语义标签的段落。3.1.1 教学点类型要由业务方先定义提示词工程的第一步不是写 prompt而是定义教学点的类型枚举。类型定义越具体模型输出的 JSON 越稳定后续查询和素材组织越容易。一般课程需要这几个类型concept概念讲解、procedure步骤方法、example例题演示、misconception易错点辨析、checkpoint互动提问、summary总结回顾。这里先给一张类型判据表后续提示词会直接引用这些判据类型提取判据典型句子concept老师明确给出定义或条件“这就是勾股定理注意它只适用于直角三角形”procedure解题步骤或操作顺序“第一步先求平方第二步再比较斜边”example具体题目或实例计算“以 3 和 4 为例斜边等于 5”misconception出现错误、纠正、强调边界条件“很多同学这里会漏掉平方符号”checkpoint提问让学生回答或暂停思考“大家想一下如果不是直角三角形还能用吗”summary回顾本节知识点“今天我们讲了三个关键点”3.1.2 两阶段 Prompt先抽取候选片段再合并去重一次调用完成所有工作容易导致教学点粒度不一致。我会拆成两个阶段第一阶段让 DeepSeek 在单个时间片段里抽取候选点第二阶段把多个候选点合并且统一编号。第一阶段的 system prompt 写成这样你是教学视频标注助手。用户会给你一个带时间戳的文本片段和画面描述。 请抽取其中“老师明确强调、值得学习者回看”的最小语义单元。 只输出 JSON{key_points: [{type: ..., start: 秒, end: 秒, title: ..., reason: ...}]} 时间戳必须使用输入片段中出现的秒数范围。注意最后一句“时间戳必须使用输入片段中出现的秒数范围”。如果视频片段本身是 120 秒到 186 秒那么模型输出的 start 和 end 只能落在 [120, 186] 这个区间不能在原始视频时间轴上自由猜测。这一步能去掉大量时间戳漂移问题。调用时的 user message 用模板拼装。脚本里我通常会写成def build_user_prompt(chunk): return ( f视频时间段: [{chunk[start]} - {chunk[end]}] 秒\n f讲义文本: {chunk[text]}\n f画面描述: {chunk[frame_desc]}\n 输出完整 JSON。 )字段顺序是有讲究的先给时间边界再给文本和画面描述最后是格式要求。这样模型在生成时后面的 JSON 字段会自然地参照前面已出现的时间数字。实测中这种顺序比“文本在前、时间在后”的时间戳命中率更高。第二阶段把同一节课的所有候选点丢给 DeepSeek 做合并。系统指令只有两句话合并重复的关键教学点。判断标准内容主题相同且时间区间重叠超过 60% 时只保留 reason 更完整、时间范围更大的那一条。输出与原 JSON 相同的结构。这一步能解决滑动窗口切片的边界重复问题。比如同一个例题跨越两个窗口第一段结尾讲了一半第二段开头重复讲述候选点会几乎相同地出现两次第二阶段就是去重的最后防线。3.1.3 JSON 输出失败的兜底策略即便有response_format{type: json_object}也不能保证每一条输出都是合法 JSON。模型偶尔会多输出一个尾部说明或者把层叠引号写错。处理方式不是反复重试而是先用正则提取外层 JSONimport json import re def parse_json_response(content): start content.find({) end content.rfind(}) if start -1 or end -1: raise ValueError(no json) return json.loads(content[start:end 1])这个兜底逻辑在多轮批量任务中能显著降低失败率。注意find和rfind搭配使用find找第一个左花括号rfind找最后一个右花括号可以容忍模型在输出前后追加解释性文字。4. 内容结构化标注落地从 JSON 到 Obsidian 素材库和时间轴跳转自动提取出的关键教学点如果只是写进一个 Excel 或 JSON 文件价值会大打折扣。结构化标注的最终目的是让教研人员能够在素材库中按“课程、主题、类型、时间位置”快速找到片段同时能跳回原视频。因此标注格式必须同时适合程序读取和 Markdown 编辑器浏览。4.1.1 以 JSONL 作为中间格式每一堂课处理完成后会生成一条 JSONL每条记录代表一个关键教学点。字段固定为id、video_id、type、start_sec、end_sec、title、reason、frame_desc、created_at。示例{id: KP-001, video_id: L01, type: concept, start_sec: 120, end_sec: 186, title: 勾股定理适用条件, reason: 老师强调只在直角三角形成立, frame_desc: 黑板上有直角三角形直角标记清晰, created_at: 2025-01-15T10:00:00Z} {id: KP-002, video_id: L01, type: example, start_sec: 202, end_sec: 278, title: 3-4-5 验证勾股定理, reason: 完整计算过程中演示公式使用, frame_desc: 幻灯片显示题目与计算过程, created_at: 2025-01-15T10:00:00Z}把数据存成 JSONL 而不是一个巨大的 JSON 数组最直接的好处是可以逐行追加、逐行解析批量入库失败时只需要重跑失败行。每个字段都有明确长度和类型最终导入 SQLite、PostgreSQL 或观测数据库都很容易。4.1.2 生成 Obsidian 可用的时间轴素材库Obsidian 对视频片段支持用时间戳链接实现跳转。针对每个关键教学点生成一个 Markdown 卡片文件结构按课程/节/知识点三层组织。--- type: concept video: L01 start_sec: 120 end_sec: 186 tags: [数学, 勾股定理] --- # 勾股定理适用条件 **时间**[[L01.mp4#t120,186]] **教学类型**概念讲解 老师强调这个定理只在直角三角形中成立。时间戳链接的语法格式是[[视频文件名#t起始秒]]如果希望视频自动停止可以写成#t120,186这种带结束时间的写法Obsidian 在播放时支持这个定位。生成脚本只需要拼接字符串即可def to_obsidian(item): title item[title] sec f#t{item[start_sec]},{item[end_sec]} return f[[{item[video_id]}.mp4{sec}]] {title}这里最实用的技巧是给数字补零到三位例如120直接转成120没问题但如果是 15 秒建议写成#t15,78。不同播放器对t参数的解析差异不大Obsidian 本身都能识别。务必保证video_id和实际文件名完全一致否则链接在素材库中会变成无法跳转的纯文本。4.1.3 向量检索让“回看哪一段”变成语义查询当结构化标注数量积累到上百节课程之后按类型和时间轴找片段已经不够用。更常见的搜索句式是“讲过的平方和公式的易错题”这需要向量检索。建议用本地向量库完成避免频繁调用外部接口增加延迟和成本。以 Chroma 为例import chromadb from chromadb import Documents, EmbeddingFunction, Embeddings client chromadb.PersistentClient(path./teaching_db) collection client.get_or_create_collection( nameteaching_points, metadata{hnsw:space: cosine}, ) collection.add( ids[KP-001, KP-002], documents[勾股定理适用条件, 3-4-5 验证勾股定理], metadatas[ {type: concept, video_id: L01, start_sec: 120}, {type: example, video_id: L01, start_sec: 202}, ], ) results collection.query( query_texts[斜边的平方等于什么], n_results5, )metadata{hnsw:space: cosine}是让向量检索用余弦相似度适合教学视频中的短文本映射查询时n_results设置为 5是因为一个知识点通常有多个冗余说法取前 5 之后的片段主题相关性会明显下降。需要说明的是这里嵌入向量模型和 DeepSeek 是分开的。DeepSeek 负责理解视频语义并生成结构化文本嵌入模型负责把生成结果映射为向量。两者各干各的避免在同一模型上又做生成又做检索否则系统会非常笨重。使用场景数据格式检索方式人工翻阅教研素材Markdown 卡片Obsidian 时间戳链接机器批量审核JSONL逐行解析入库语义查询Chroma 向量库余弦相似度精确回看[[视频#tstart,end]]播放器跳转5. 用回归集验证提取质量时间重叠、漂移与字段缺失结构化标注系统最容易出现的问题不是“提取不出来”而是版本更新后输出格式悄悄地变化。比如换了模型版本或改了一条提示词JSON 字段名变了、时间戳重叠了、同一知识点重复出现了。提高质量之前先要建立一整套可重复执行的回归验证。回归集不要选整节 40 分钟的课建议从每个课程类别中各选 3 到 5 分钟小段组成一个总量 15 分钟的验证集。基准是人工标注结果。每次修改提示词或更换模型后跑一遍同样的视频用脚本对比新旧结果。检查重点是时间重叠率和重复率。一个最小的时间重叠检查如下def find_overlaps(items, tolerance3.0): ordered sorted(items, keylambda x: x[start_sec]) for i in range(len(ordered) - 1): cur ordered[i] nxt ordered[i 1] if nxt[start_sec] cur[end_sec] - tolerance: yield (cur[id], nxt[id], cur[end_sec] - nxt[start_sec])tolerance3.0表示允许两个教学点之间最多有 3 秒时间重叠如果重叠超过这个值说明两个片段边界划分存在问题。正常教学视频中相邻知识点之间存在教师停顿或过渡语句3 秒足够覆盖这些自然间隔。指标建议关注三个时间漂移、重复率和 JSON 解析成功率。时间漂移用抽样的方式人工核对比如随机抽 20 条关键点比较机器给出的时间戳与被截取视频对比人工找到的时间点漂移超过 6 秒则判定失败。重复率计算回归结果中重叠片段对数量除以总片段数建议控制在 5% 以下。JSON 解析成功率要求在 100 条测试样例中不低于 98%低于这个值说明提示词或参数存在不稳定性需要调整。回归集可以做成一个pytest测试用例读入 New JSON 输出和基准 golden JSON逐项比较字段存在性、start_sec 是否落在对应片段区间、播放链接能否解析出有效的视频文件名。把这个测试挂到 CI 流水线每次改动提示词就自动跑一遍可以用定时任务对线上新增视频做每日抽样回归保证新模型版本不会引入批量错误。真正要盯住的两条曲线是 overlap 数量和 keypoint_count 数量前者反映边界质量后者反映是否存在大规模漏检。当这两条曲线与基准曲线偏离超过 20% 时立刻冻结模型版本并回滚提示词而不是等到课程入库后才发现整节课的标注结构已经变了。本文还有配套的精品资源点击获取