Architecture Overview · V1
利用LLM实现视频切片、打标签、智能体语义检索
上传一部电影或一集电视剧后,系统会先拆镜头、对字幕和声音,再按剧情切成片段。 每个环节由合适的工具或模型处理,不会把整部视频一次性交给一个大模型。
上传长视频
MP4 / MOV · 字幕 · 音轨
切成剧情片段
镜头 + 字幕 + 音频 + 推理
补齐标签和关系
属性 · 事件 · 剧情 · 关系
输入一句话找素材
筛选 + 相似度 + 关系 + 排序
最后拿到的是能直接查找和使用的视频片段
每个片段都有准确时间、内容说明和前后关系。 用户可以直接输入一句话找片段,不用再把整部视频从头看到尾。
为什么不把整部视频直接交给大模型?先让 FFmpeg、ASR 和视觉模型把镜头、字幕、 声音等信息整理出来,再让大模型处理需要理解剧情的部分。这样更快、更省钱,出了问题也容易找到原因。
系统分六层,登录、权限和运行记录统一管理
Go 服务管理用户、权限和任务,工作流负责排队和调度,Python Worker 与 Agent 负责具体处理。 每一步结果都会先保存,哪一步失败就只重跑哪一步。
换模型不用推翻重做
模型、Prompt、规则和标签都记录版本。以后只换其中一项,不用把整套系统重新做一遍。
每个结论都有出处
每个标签都会保留对应时间、字幕、画面、声音、可信程度和生成版本。
处理一次,后面反复用
ASR、OCR、Shot、Scene 和 Embedding 生成一次,后面的分析和搜索都能继续使用。
从上传视频到搜到片段,一共八步
能用固定程序完成的工作先处理,只有剧情判断这类需要看上下文的内容才交给模型。 每一步都有输入和结果,失败时也方便单独重试。
检查上传文件
分片上传,检查格式和媒体信息,同时登记版权与访问权限。
准备分析文件
生成方便分析的代理视频,统一时间,并提取音轨和字幕。
同时提取信息
镜头、ASR、OCR、画面特征、静音和声音事件可以一起处理。
把镜头合成场景
根据地点、人物、对话、画面和声音是否连续,把相关镜头放到同一个 Scene。
判断剧情片段
大模型读取前后 Scene 的摘要,判断哪些场景可以组成一个完整片段。
确定切点并切片
一起参考镜头、字幕、静音和模型判断,确定切点后再交给 FFmpeg 输出。
补充四层信息
写入属性、事件、剧情作用和片段关系,同时保存判断依据和可信程度。
建立索引并发布
建立全文、向量和关系索引,检查通过后放进素材搜索库。
切点得分 = 镜头 + 字幕 + 静音 + 场景变化 + 事件完成度 + 模型判断 − 规则扣分
多项线索一起判断
所有视频共用处理队列,不会各起一套 Agent
调度器先看任务的先后关系。ASR、OCR、镜头和声音分析可以同时跑, 全部完成后再合成 Scene。哪类任务排队多,就单独增加哪类 Worker。
Worker 不保存业务状态,模型可以常驻内存。哪个 Worker 空闲就取下一个任务; 某一步失败只重试这一步,前面已经完成的结果继续使用。
每个任务跑到哪一步都看得见,部分结果也能先用
任务进度保存在服务端,不会绑死在某个 Worker 上。任务失败、取消或更换模型时, 已经做完而且还能用的结果会继续保留,不用整部视频从头再跑。
能用的结果先发布,失败的部分单独重试。例如人物聚类失败,不影响已经完成的字幕和切片。
系统会区分临时错误、输入文件问题和无法恢复的错误,只有临时错误会自动重试。
还没开始的步骤直接停止,临时资源及时回收,已经做完而且还能用的结果继续保留。
不重复处理(幂等)
同一个视频、同一个步骤和同一套配置重复提交时,不会再生成一份相同结果。
从中断处接着跑
每一步先保存输入和结果,再开始下一步。Worker 中断后,从最近完成的位置继续。
换个方案继续处理
遇到超时、GPU 显存不足或在线模型不可用,可以换队列、换轻量模型或交给人工处理。
旧版本先保留
重新分析会生成一份新版本,不会直接盖掉旧结果。检查通过后再把新版本设为当前版本。
片段从哪来、标签怎么得出,都能查到
系统不只保存最后的标签,还会保留它对应的 Scene、Shot、媒体轨道和原视频时间。 标签是根据哪句字幕、哪一帧画面或哪段声音判断出来的,也能回头查看。
视频文件和时间
视频、音轨和关键帧这类大文件放在对象存储,基本信息和时间范围放在 PostgreSQL。
- 原视频、代理视频、音轨、字幕、关键帧
- Shot、Scene、Segment 及其包含关系
- 统一毫秒时间与原轨道时间基映射
标签、事件和证据
Observation、Entity、Event、Relation 和 Evidence 分开保存,需要时可以单独更新。
- 事实、推断和人工确认状态分离
- 可信程度、模型、Prompt、规则和标签版本
- 字幕、关键帧、音频区间和上下文证据
搜索索引和版本
搜索索引随时可以重新生成,原始分析结果仍保存在数据库里。
- 全文与标签索引、pgvector、多路 Embedding
- 图关系先放在关系表里,数据量大了再考虑专用图数据库
- 新版本检查通过后整体切换,需要时还能退回旧版本
所有时间都以它为准
保存和原视频的换算关系
只记录开始与结束
再按用途切片或转码
标签分成四层,搜索时更容易找准
第一层记画面里有什么,第二层记发生了什么,第三层判断这段剧情起什么作用, 第四层再把人物、地点、时间和前后片段连起来。
属性层
记录画面里的人、物、环境、拍摄方式和声音。
事件层
把“谁做了什么”连同参与者、地点和时间一起记下来。
剧情层
结合前后片段,判断它是铺垫、冲突、高潮、反转还是结尾。
关系层
把前后顺序、相同地点、人物同场、事件参与和可能的因果关系连起来。
每个由模型生成的标签都要附上来源、时间范围、可信程度、模型版本和判断依据。 看不准时就标成“不确定”,不要硬猜;可信程度低的结果交给人工确认。
搜索 Agent 先拆条件,再去索引里找
比如“雨夜追车”这句话,Agent 会先分出必须满足的条件和只是偏好的条件, 再从标签、字幕、向量和关系数据里一起找,最后只比较少量候选片段。
“找出雨夜城市道路上的追车片段,至少两辆车,不要动画,优先紧张音乐。”
必须满足的条件先筛
权限、项目、内容类型、人数、时间和排除项,都先由数据库和规则严格检查。
偏好只影响排序
“更紧张”“更像电影高潮”这类主观要求,用来调整候选片段的先后顺序。
告诉用户为什么命中
结果里直接显示命中的标签、事件、字幕或关键帧,不只给一个看不懂的模型分数。
原视频留在本地,发到云端的内容统一走模型网关
每个项目都可以选择只在本地处理、本地优先并用云端补充,或者优先使用云端模型。 视频、片段、字幕、关键帧和索引使用同一套项目权限;哪些内容能发出去,由项目的隐私设置决定。
用户与浏览器
用户只能看到当前项目允许访问的内容,并且只拿到短时间有效的凭证。
- 登录身份与项目权限
- 分片直传,不经过 Go 服务中转大文件
- 预览、下载和导出都会留下操作记录
业务控制区
Go 服务检查用户权限、选择处理方式,并创建分析任务。
- 短时上传/下载签名
- 检查模型选择和哪些数据可以发出去
- 密钥只由受控服务使用
本地数据与 GPU 区
原视频、字幕、关键帧和人物聚类优先在内部环境处理。
- 私有对象存储与最小权限访问
- 敏感信息检测、匿名化和脱敏
- 派生数据继承项目权限
外部模型区
外部模型只能通过模型网关接收项目允许发送的必要内容。
- 必要字幕和少量压缩关键帧
- 匿名人物 ID 和整理好的场景摘要
- 调用内容、费用和返回结果都会记录
本地 GPU / 内部环境
- 原视频解码、抽帧与音轨提取
- ASR、OCR、Shot 与人物匿名聚类
- 基础视觉、音频和 Embedding
- 敏感信息检测与脱敏
- 效果达到要求时,优先使用本地 VLM / LLM
检查权限 · 限流 · 记录调用
云端模型
- 高难度剧情边界与前后文判断
- 复杂事件与剧情作用理解
- 人工复核可信程度低的结果
- 重新排列候选片段
- 只接收必要字幕、关键帧和整理好的场景摘要
部分横向内容可左右滑动查看。
| 部分 | V1 建议 | 后面何时升级 | 为什么这样选 |
|---|---|---|---|
| 控制面 | Go | 继续沿用 Aether 服务规范 | 和现有业务保持一致,团队也更熟悉 |
| AI Worker | Python 独立 Worker | 任务量上来后再按资源池拆分 | Python 更适合现有算法和模型 |
| 工作流 | Temporal 或等价持久化工作流 | 哪条队列排队多,就单独扩哪条 | 先保证任务能重试、能接着跑、能排查 |
| 媒体 | FFmpeg / FFprobe / PySceneDetect | 数据量上来后再加 GPU 编解码或专用转场模型 | 能用固定程序做的就先不用大模型 |
| 数据 | S3/MinIO + PostgreSQL | 查询量和关系复杂后再换专用向量库、图数据库 | 先用简单组合把主流程跑通 |
任务运行、GPU 资源与模型费用监控
统一监控任务进度、资源用量、模型调用次数和结果质量, 用于扩容、模型切换、暂停调用或转人工处理。
把运行数据记全
用视频、工作流和任务 ID 把整条处理过程串起来。
- 格式统一的日志和错误分类
- OpenTelemetry 指标与链路追踪
- 模型请求、Token、费用和延迟
- 上传、下载、导出和人工修改记录
控制任务量和排队速度
并发多少要看实际工作量,不能只数有多少个任务。
- 队列长度与预计视频分钟数
- CPU、GPU、显存和模型实例利用率
- 对象存储、网络与磁盘 I/O 峰值
- 租户配额、并发上限与优先级
按错误类型处理
不同错误走不同处理方式,不能所有问题都一遍遍重试。
- 临时错误:退避重试与熔断
- 输入错误:终止节点并提示修复
- GPU OOM:降批次、换队列或降模型
- 不可恢复:进入人工处理队列
及时提醒并处理
发现指标异常后,要直接对应到扩容、停用模型或回滚版本等处理动作。
- P50 / P95 耗时和任务成功率
- 失败、重试、换用备用方案和可信程度低的结果占比
- 单分钟视频成本与预算异常
- 扩容、停用模型或回滚版本
多重质量检测,支持人工审查
先准备一批人工标注的视频作为固定测试集。每次更换模型、Prompt 或规则后, 都用同一批视频重新测试,才能知道效果到底变好了还是变差了。
切片质量
- 边界误差与命中率
- 台词 / 动作截断率
- 覆盖、空洞与重叠率
- 人工接受和修订工作量
语义质量
- 属性标签 Precision / Recall
- 事件与参与者准确率
- 人物、地点关联一致性
- 无证据或幻觉标签比例
搜索与运行质量
- Recall@K / Precision@K
- 零结果与用户采用率
- P50 / P95 延迟
- GPU、费用、失败与重试
可信程度高、又通过规则检查的结果可以直接发布。看不准、互相冲突, 或者涉及身份和敏感属性的结果,再交给人工确认。每次人工修改都保留原结果和修改原因。
先把主流程跑通,再按实际需要扩展
第一阶段先确认切片和搜索效果。等数据量、查询量和并发真的上来以后, 再考虑专用向量库、图数据库和更复杂的资源调度。
先做小范围验证
挑一批有代表性的视频,跑通 Shot、ASR、Scene、剧情切片、基础标签和向量搜索。
做出可用版本
补上分片上传、持久化 DAG、Worker Pool、四层标签、模型选择和审核页面。
把稳定性补齐
完善切点判断、人物地点关联、版本记录、固定测试、权限和操作记录。
数据量上来后再扩展
再加入专用索引、GPU 自动扩缩、领域模型、素材组合和辅助剪辑。