← → 翻页 · B 静态 · ESC 索引
Multimodal Labeling · Kraft Edition
01 / 18
DA in AI Video Generation

多模态打标

与数据飞轮

通过分析线上用户的 AI 视频生成请求,构建多模态标签、视频质量评估与场景分析框架,为模型、产品、数据方向的迭代提供决策输入。

PromptImageVideoAgentBusiness Feedback
多模态内容打标专项
2026
Context · Why Labeling
02 / 18
视频生成赛道里,DA 的切入点

基础模型很卷,用户数据更近。

团队的大方向仍然是卷模型能力。但距离线上用户请求和行为反馈最近的团队,是 DA 团队。

DAU、下载次数、生成次数只能回答“用户有没有用”。
Prompt、图片、视频和生成结果,才更接近“用户为什么这样用”。
Insight · Content Understanding
Industry
Model
基础模型竞争仍是主线,线上请求和反馈尚未被充分结构化。
DA Role
User
通过看清线上用户数据,推动模型、产品和数据方向迭代。
Method
Label
把 Prompt、图片、视频等非结构化内容转成能分析的标签。
Page 02 · 项目背景
Content → Signal
System Map · Native Rebuild
03 / 18

一条从输入到业务决策的打标链路

01 · Input

输入数据层

用户 Prompt
输入图片 / 视频
模型生成结果
Excel / 样本数据
分析任务需求

02 · Product

可标

团队级打标产品
数据上传
Prompt 配置
批量调度
结果导出

03 · Engine

内容理解与打标引擎

A · Framework

标签树
维度设计
输出 Schema
Prompt 模板

B · Model

文本理解
图片理解
视频理解
Good / Bad Case

C · Agent

任务拆解
证据提取
多轮判断
结果校验

04 · Assets

结果沉淀层

结构化标签
结果表
Prompt 模板库
标签树资产
样本案例库

05 · Business

业务应用层

用户意图分析
产品分析
场景分析
Good / Bad Case
数据补齐判断
模型优化支持

分析结果会反哺标签树、Prompt 与 Agent,形成持续迭代闭环;底层由前后端、任务调度、数据库、文件存储、模型服务接口、日志与权限共同支撑。
Architecture · Feedback Loop
Page 03 · 系统架构
Input → Product → Engine → Assets → Business
Act I · Pain
04 / 18
Act I

三重痛点

不是“需要打标签”这么简单,而是工具、框架和模型能力同时到了边界。

第一幕 · 问题定义
Pain Points
Pain 01 · Platform Gap
05 / 18
痛点一

AI 打标,不该只属于会写代码的人。

对普通分析师和整个团队来说,批量调用模型、调 Prompt、处理多模态输入和解析结果,本身就是一套复杂工程。

目标体验很简单:上传 Excel,输入 Prompt,就能完成打标。代码、环境、接口和模型适配都应该被产品封装。
From Script To Platform
Friction
Code
普通分析师不该先理解 API、环境和批处理脚本。
Iteration
Prompt
调 Prompt、切模型、多轮试验,需要被沉淀成团队流程。
Goal
Excel
分析师只需要上传表格、输入 Prompt,然后等待结构化结果。
Page 05 · AI 打标门槛
Script → Product
Pain 02 · Framework Gap
06 / 18
痛点二

缺少统一打标框架。

现在的痛点不是没人打标签,而是标签五花八门,各打各的,结构很散。

Fragment
五花八门
不同分析师、不同场景各自打标,口径和粒度不断漂移。
Relation
业务关系
基础模态、用户输入、画面元素、用户意图和应用之间缺少统一关系。
Asset
话语体系
统一框架后,团队才能用同一套语言分析、比较和复用标签。
Page 06 · 统一框架缺口
Labels → Business Asset
Pain 03 · Model Ceiling
07 / 18
痛点三
复杂多模态判断,
已经触及模型上限。

判断一个 AI 视频是否真正可用,往往涉及长上下文、时序关系、多模态参考和质量标准。单轮调用会漏判、误判,或者给出不稳定结论。

NeedEvidenceReviewTrace
Page 07 · 模型能力上限
Single Shot → Workflow
Act II · Platform
08 / 18
Solution 01

可标

从个人脚本走向团队级打标产品,把接口调用、批量处理、重试、解析和模型适配封装起来。

Upload ExcelPromptModelResult
第二幕 · 从脚本到团队级打标产品
No-code Labeling
Klabel · Vibe Coding
09 / 18
可标不是外包需求,而是自己用 AI 做出来的完整产品

从想法到产品,一路 vibe coding。

它经历了产品构想、MVP 验证、架构设计与开发,再到真实用户反馈驱动的持续迭代。

Step 01
构想
从团队打标痛苦出发,定义“上传 Excel + 输入 Prompt”的产品愿景。
Step 02
MVP
用最小可用版本验证流程,先证明分析师真的能用起来。
Step 03
开发
把批量、重试、解析、模型适配等复杂性封进后台。
Step 04
迭代
根据试标、回查、统计和标签树反馈,持续调整产品形态。
Page 09 · 可标构建总览
Idea → MVP → Product → Iteration
Klabel · Problem To MVP
10 / 18
产品构造一

先把痛苦变成 MVP。

传统打标常常要 1-2 周:取数、拆字段、写脚本、调接口、清洗结果,分析师很难把这件事变成日常能力。

产品愿景很直接:上传 Excel,写 Prompt,点击运行,然后得到可回查、可导出的结构化结果。
Product Vision · Excel + Prompt
Pain

非开发背景同学不熟 API、批处理、结构化输出和多模态输入,脚本能力无法团队化。

MVP

先搭出最短链路:选列、写指令、试跑小样本、确认效果,再启动全量打标。

Validation

MVP 验证重点不是功能堆满,而是确认分析师是否真的能不用代码完成一次打标。

Page 10 · 产品构造一
Problem → MVP
Klabel · Product Architecture
11 / 18
产品构造二

从交互层到数据层。

分析师看到的是上传 Excel、填写 Prompt、查看结果;背后则由前端、后端、云服务和数据库共同支撑,让一次打标任务可以被运行、追踪、复用和沉淀。

Frontend

React

面向分析师的任务配置、Excel 上传、试标、结果回查和模板管理界面。

Backend

FastAPI

承接任务创建、批量调度、失败重试、结果解析和模型调用适配。

Cloud Deploy

Google Cloud

后端服务部署在 Cloud Run,前端通过 Firebase Hosting 承载,模型接入 Vertex AI。

Database

PostgreSQL

保存任务、样本、标签结果、Prompt 模板、回查记录和结构化输出。

这套架构让“上传 Excel + 输入 Prompt”的轻量体验背后,具备云端任务处理、模型服务接入、数据沉淀和团队协作能力。
React · FastAPI · Google Cloud · PostgreSQL
Page 11 · 产品架构
Cloud Product Architecture
Klabel · Iteration
12 / 18
产品构造三

真实反馈,决定产品形态。

可标的功能不是一次想完整,而是在使用中不断暴露新的摩擦点,再用产品能力接住。

试标、网页回查、统计分布和模板库,都是从真实打标流程里长出来的迭代。
User Feedback → Product Iteration
Frequent Iterations

先试标少量样本,在线回查原文与结果,用统计分布判断质量,再把成熟 Prompt 放进模板库。

Hardest Iteration

面对 700+ 节点标签树,直接一次性让模型判断会带来上下文溢出和错判。

解决方式是级联打标:先判断大类,再沿标签树逐层缩小候选范围。
Cascade Labeling
Page 12 · 产品构造三
Feedback → Iteration
Act III · Framework
13 / 18
Solution 02

统一框架

不再把标签当成一堆字段,而是把用户输入、画面元素、意图和业务应用放进同一条链路。

第三幕 · 让标签进入业务
Framework
Framework · Full Chain
14 / 18
用一个图生视频请求跑一遍

一张人物照片,如何变成五层标签

用户素材:一张人物半身照。
用户 Prompt:“让照片里的女生在霓虹街头回头微笑,镜头慢慢推近,电影感,保持人物长相和服饰一致。”
Case Input · Image To Video
Why This Case

这类请求看起来只是一个 Prompt,但实际同时包含素材类型、主体参考、动作控制、镜头控制、风格偏好和质量评估标准。

Case Mapping · Five Layers
01
基础模态
输入是一张图片和一段文本 Prompt,输出是一段视频。
02
输入形式
图生视频;人物主体参考;动作、镜头和风格都由文本控制。
03
画面元素
主体是女生;环境是霓虹街头;动作是回头微笑;风格是电影感。
04
用户意图
保持长相和服饰一致,生成指定动作,并获得可发布的人像短视频。
05
业务应用
识别人像创作需求,评估主体一致性、牙齿、手部和动作 Bad Case。
统一框架的价值,是把“用户想要什么”和“模型哪里做不好”落到同一组标签里,后续才能服务需求判断、质量评估和数据补齐。
One Case · Multiple Decisions
Page 14 · 打标框架
Five Layers · Static View
Application · Product And Model
15 / 18
业务应用不是单一出口

同一批标签,服务两类决策。

Product View

产品视角

  • 识别用户真实使用场景
  • 判断哪里交互不顺
  • 决定哪些输入能力值得继续做
  • 扩展 Prompt、图片、视频、音频和主体资产能力
Model View

模型视角

  • 评估生成结果是否满足用户意图
  • 理解人群偏好和高频需求
  • 定位 Good Case / Bad Case 分布
  • 为训练、评测和数据补齐提供方向
Page 15 · 业务应用
Product / Model
Act IV · Agent
16 / 18
Solution 03

Agent

单轮调用已经触及多模态理解模型的能力上限,所以复杂内容判断必须被拆成可规划、可取证、可复核的工作流。

PlanEvidenceProsecuteJudgeReduce
第四幕 · 用 Agent 弥补模型能力上限
Workflow Not Prompt
Agent Workflow · Evidence Trial
17 / 18
从单轮推理改成证据审理

复杂 case 的处理链路

Investigation · 查什么、怎么查
01
CaseSpec
明确输入元素、核心约束、参考保持和预期序列。
02
Plan
决定检查维度、路由、采样和证据策略。
03
EvidencePack
抽取帧、ASR、OCR、reference match 和 sync signals。
04
Materialize
把 finding 绑定到 canonical ref registry。
Trial · 谁提出、谁复核、谁裁决
05
Prosecutor
按任务完成、静态质量、动态质量、物理合理性、音频、一致性六维立案。
06
Judge
只复核已提交问题项,输出 accepted / revised / rejected / needs_more_evidence。
07
ChiefJudge
汇总维度结论,生成 usability、critical failures 和 optimization signal。
08
Trace
保存执行轨迹、审理动作和最终 schema,方便回查纠偏。
Page 17 · Agent 工作流
All Steps Visible · Static View
Outcome · Impact
18 / 18
最终收益

效率与业务反馈

可标先降低团队打标成本;更关键的是,标签体系把线上用户需求转成业务反馈,反哺模型训练和行业判断。

Scale
20亿
月均处理 token 量级,经济成本约 $600。
Analysis Cycle
2-3d
模型效果分析从 2-3 周缩短到 2-3 天。
模型训练收益:发现问题,反哺优化。
人物主体需求很高,但牙齿、手部、服饰、配饰、动作等细节问题高频出现,可直接反哺模型优化和数据补齐。
Model Training Feedback
行业判断收益:看清创作动机。
通过观察用户在不同场景里的创作动机,判断未来产品和数据能力应优先投入到 XX 行业等高潜方向。
Industry Direction Signal
Page 18 · 数据飞轮
Efficiency + Model Training + Industry Signal