以内容电商中的 AI 打标业务为例，许多企业在推进“AI 进生产”的过程中，常面临一个共通误区：将 AI 打标简单等同于模型推理。
在实际生产链路中，仅记录最终标签往往无法支撑复杂的业务诉求。当运营团队追溯标签生成依据、排查“其他”类异常分类、核算模型与人工调用成本，或评估素材的后续转化效果时，仅仅依靠模型输出的标签向量是远远不够的。
本文基于实际业务场景，通过具体案例探讨内容 AI 在生产链路中的数据管理痛点，并阐述如何基于 Apache Doris 4.x 构建内容事实数据体系，实现从推理结果到全链路可追溯的数据治理。
说明：
- 本文涉及的数据口径、评估案例及模拟指标均来自内部测试及测试数据集，性能数据参考 Apache Doris 官方 Benchmark。
- 本文示例图只为更清晰说明案例，如有侵权可联系删除。
1. 业务挑战：为什么“最终标签”无法满足生产需求？
在一线运营场景中，如果只保存模型生成的“最终标签”，在面对复杂的工程与运营分析时，往往会暴露出以下三大问题：
1.1 业务逻辑与视觉事实耦合，复用性差
运营标签往往依赖特定的业务规则组合，而不仅是模型识别。
案例 1：服装素材打标
下方素材包含 8 张图片，最终被打上了 #街头穿搭、#运动休闲风、#夏季套装、#细节质感 等标签。但运营需要进阶追溯：“这条素材重点是整体搭配还是商品细节？原始生产成本如何分配？”
如果直接存标签，后续业务新增“穿搭精选”推荐池时，就无法判断该素材是否满足“包含全身完整搭配+生活化场景”的入池规则。
案例 2：“性能测试”标签的条件校验
规则规定，“性能测试”标签必须同时满足视频素材、连续运动过程以及明确的产品科技讲解。若仅有一张图片展示鞋底纹路或科技图解，只能归为“产品科技展示”，不能算“性能测试”。如果模型直接给出最终结果，一旦规则调整，历史数据将因缺乏底层视觉事实而无法进行“无模型重新推理”的批量规则重计算。
1.2 工程异常被业务掩盖，“其他”类目不可控
在多图或长视频的综合打标阶段，多图上下文拼接容易导致系统异常。
案例：上下文过载引发的误判
在一次综合判断阶段，系统需要同时处理 12–18 张图片，Prompt 长度超过 3000 字符，触发了接口错误（如 MiniMax Error 1026）。由于系统未做异常拦截，直接将调用失败兜底回退为“其他”标签。
结果导致：系统调用失败被记录成了正常分类，业务侧看到“其他”标签占比从 17% 暴涨至 82%，误以为模型准确率大幅下降，排查成本极高
1.3 数据链路断层，难以归因与核算 ROI
打标过程涉及单图识别、小批综合、规则决策、人工审核等多个步骤。以低分样本（Case 442003342）为例，素材因部分信息缺失被打上“其他”，但图片中依然能识别出“运动鞋、鞋底标识、手持展示”等客观事实。
若数据链路没有将过程特征、重试日志与审核修改记录关联，就无法精准下钻：“这次打标耗费了多少次模型调用？人工补录成本是多少？高曝光素材到底归因于哪个模型版本？”
2. 解决方案：基于 Apache Doris 构建内容事实库
针对上述挑战，核心治理思路在于：实现特征（Feature）、决策（Decision）与结果（Result）解耦，并将围绕标签表设计升级为基于 Apache Doris 搭建统一的内容事实库。
2.1 数据解耦：三层打标数据模型与异常分流
一条生产可用的内容标签，通常需要包含三层数据：
- Feature（特征）：记录模型识别出的客观事实，例如人物是否全身出镜、是否存在运动画面；
- Decision（决策）：记录规则如何使用这些事实，包括命中的条件和排除的标签；
- Result（结果）：保存最终标签、置信度、模型版本、规则版本和审核结果。
同时将“其他”标签强制拆分为三类：
- 语义其他： 确不属于当前业务体系；
- 低置信待审： 识别证据不足，流转至人工审核；
- 系统失败待重试： 超时或接口报错，进入工程队列重试。
[数据流向示意]
单图/单段解析 ──> 提取 P1-P5 基础事实 (Feature: 主体、场景、风格、产品、制作)
│
▼
小批综合判断 ──> 记录规则引擎过滤与决策条件 (Decision)
│
▼
生成最终结果 ──> 最终标签 + 结构化状态 (Result: 成功、低置信、系统错误)
2.2 存储选型：半结构化与结构化混合建模
内容 AI 的模型特征演进极快，但业务查询（如按标签筛选、核算成本）要求 Schema 保持稳定。
基于 Apache Doris 4.x，构建了“固定列 + 半结构化 JSON”的表结构设计：
- 核心业务列：
content_id、tag_id、confidence、model_version、status等采用强类型结构化列，保障高效索引与聚合。 - 动态输出列： 借助 Apache Doris 的
VARIANT半结构化数据类型，将原始 Prompt、自定义识别特征及错误回溯信息存入VARIANT列。Doris 会自动提取高频访问子列进行列式存储，既避免了频繁修改 Schema，又保留了极高的查询性能。
2.3 数据流接入、增量计算与混合检索
- 实时与批量接入： 批量历史数据通过 Stream Load 高速导入，实时生产事件、模型调用日志及投放效果数据通过 Kafka + Routine Load 接入，确保
workflow_trace_id贯穿全链路。 - 增量预聚合： 利用 Doris 4.x 的增量物化视图（Incremental Materialized Views），对生产耗时 P90/P99、低置信率、系统失败率及单素材生产成本进行实时预聚合，显著降低高频看板的计算开销。
- 向量/标量混合检索： 运营不仅需要“找相似图片”，还需要限制条件（如：“近 30 天审核通过、属于运动鞋类、包含产品科技展示”）。通过 Doris 4.x 的 HNSW 混合检索，可在单条 SQL 中同时完成
Vector Similarity（向量相似度）与Product Category（品类）、Content Tag（标签）、Review Status（审核状态）等标量条件的联合检索，无需引入复杂的外部独立向量数据库。
注：在 Apache Doris 官方向量索引性能测试中，Doris 4.0.2 在 VectorDBBench Performance 768D 1M 测试条件下给出了 989.1 QPS、Recall >97% 的结果。实际业务中仍需根据真实维度与并发量单独压测。
3. 业务价值：从成本管控到 Agent 智能赋能
通过 Apache Doris 将分散在视觉模型、工作流、审核系统及经营系统中的数据归集于统一分析平面，带来了以下核心价值：
3.1 全链路归因与精准 ROI 核算
将打标成本从单纯的“API 消耗”扩展为“全链路生产成本”。企业可基于明细事实表精准计算净收益：
打标净收益=节省初始人工时间−新增审核时间−重试与返工成本−错误标签损失
假设某营销方案测算得出 CPM 为 380 元、模拟 ROI 为 2.8，但实际上线后发现成本异常飙升。通过 Doris 的事实库进行下钻，团队可以快速判断成本上升到底是源于模型 Provider 单价变动、Prompt 上下文过载导致的重复重试，还是“其他”类误判增加引发的人工审核反转，避免将工程失败成本误计为模型本身开销。
3.2 提升模型评估与数据治理效率
摆脱单一 Accuracy 指标的局限，能够基于解耦的数据体系评估 Macro-F1、Per-class Recall、审核反转率及系统失败率。
比如在内部 573 份分镜头脚本评估中，李宁品牌样本占比高达 77%，且视频素材极少（仅 2 份）。若仅看整体准确率（如测试集平均得分 5.42/8.0），极易掩盖长尾品牌和视频素材的表现缺陷。
通过 Doris 将“语义其他”、“低置信待审”与“系统失败待重试”拆开统计后，当“其他”标签占比突然从 17% 暴涨至 82% 时，团队能瞬间定位是 API 报错（如 Error 1026）集中爆发，而非模型分类能力下降。
3.3 为上层 AI Agent 提供可靠的数据底座
缺乏完整上下文时，让 Agent 自动化诊断或推荐容易产生幻觉。基于 Doris 构建的内容事实库，能为 Agent 提供包含内容事实、生产状态、规则版本、成本及业务效果在内的完整上下文。
当运营想要寻找可复用素材时，Agent 不再只是盲目进行向量匹配，而是在 Doris 中结合向量相似度、SPU/SKC 关联覆盖率以及历史点击转化效果进行多模态智能推荐。
对于系统异常，Agent 可以自动捕获错误码、定位产生异常的模型版本与图片批次，并给出低置信样本的审核建议，执行完成后将决策过程重新写回事实库，形成闭环。
4. 结束语
在内容电商场景下，AI 打标并非一次性的模型推理，而是一套需要持续运营与调优的数据系统。
Apache Doris 在该架构中充当了统一事实分析层的角色。它借助 VARIANT 类型无缝承接演进中的模型特征，通过向量索引与标量过滤能力支撑业务检索，利用增量物化视图高效生成运营指标，成功将原本孤立的 AI 打标过程转化为可计算、可追溯、可归因的数字资产。
说明：本文结构图均根据内部材料整理，用于说明数据架构、业务决策和数据流关系，不代表 Apache Doris 官方产品架构图，也不作为原始业务系统截图使用。
