大模型助力抖音用户体验智能化

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 老师在线解除疑惑！

✅ 有心得体会想分享？群里聊！

扫码入群参与讨论

01

背景介绍

1. 平台发展阶段与体验重要性

在抖音早期阶段，增长驱动主要来自用户红利和产品功能创新，但目前整体用户增长趋于饱和，特别是移动端渗透率已接近 80%。当前阶段，平台的核心目标已从"抢用户"转向"抢时长"，并通过优化体验获取用户停留与忠诚度。

平台发展的四个阶段：

• 红利驱动阶段：依靠用户增长红利

• 饱和渗透阶段：功能创新驱动增长

• 泛化突破阶段：场景扩展与生态建设

• 最后一公里体验优化阶段：精细化体验治理

在当前阶段，"用户体验"成为抖音增长的下一个关键量。

2. 用户体验问题的根源分析

用户体验问题往往源于用户的预期与平台感知之间的落差，这一"体验 Gap"主要来自四个层面：

• Gap 1：价值冲突

  平台定义"好内容"是基于价值主张（如反拨流、提倡优质创作），但部分用户仅关注流量指标，导致预期冲突。

• Gap 2：过度审核

  平台治理规则若制定不合理，容易引发用户被"误伤"，如轻内容跳舞视频也被判违规。

• Gap 3：执行质量低

  审核手段（模型/人工）准确率有限，容易出现误判、审核滞后等问题。

• Gap 4：沟通不到位

  用户对平台的主张、规则缺乏理解或获得不及时的申诉反馈，进一步加剧不满。

3. 用户旅程中的体验痛点

体验问题贯穿用户全旅程，包括但不限于以下环节：

• 账号入驻阶段：实名认证失败、资料审核慢

• 创作发布阶段：缺失高清发布、编辑上传难

• 审核处罚阶段：误判、违规申诉难

• 内容分发阶段：流量低、曝光少

• 社交互动阶段：转粉率低、评论少

• 成长变现阶段：伙伴计划门槛高

• 权益保护阶段：侵权举报流程繁琐

4. 体验治理思路

抖音的用户体验治理并非停留在单点优化，而是基于完整的闭环体系。整个路径围绕三大核心问题展开：

（1）基于什么来做？

数据基础：月均千万级用户反馈，覆盖电话、邮件、客服对话、举报、评论、搜索等全渠道链路

信号维度：既包括用户主动上报（显性信号），也包括用户行为流和内容数据中挖掘出的隐性信号

（2）做什么样的事情？

打造"从问题发现到问题解决一体化用户体验中台"

（3）有什么样的收益？

• 负向指标下降：

  用户负反馈总量下降

  客服进线求助率下降

• 正向指标提升：

  用户满意度上升

  投稿率、互动率等生产意愿指标提升

  业务指标联动增长：

  用户生命周期（LTV）拉长

  留存、活跃与平均会话时长显著提升

①业务架构

为了支撑体验中台的运行，抖音构建了完整的体验治理业务架构：

第一层：用户交互层（数据入口）

主要面向 C 端用户，负责获取用户的主观体验反馈：

• 反馈入口：内容页、设置页反馈模块

• 申诉入口：处罚后的页面引导或客服渠道

• 举报系统：安全、版权、违规等举报通道

• 自助产品：FAQ、自助工具、机器人答疑等

第二层：用户服务层（反馈处理）

负责第一步反馈响应与交付：

• 人力交付：客服排班、SOP 流程响应、人工运营等

• 智能交付：智能客服、预判规则匹配、推荐话术、FAQ 推荐等

• 服务运营系统：

  排班预测

  多渠道场控调度

  策略模块配置与调优

第三层：体验问题层（分析与理解）

这是整个中台的大脑，负责对用户反馈进行深度处理和价值提取：

• 信号识别：多模态信号识别，召回负面反馈样本

• 内容理解：摘要提取、分类、观点聚合、质量评分

• 问题分析与归因：聚类、打标签、实验归因、异常突发识别

• 规则沉淀与标准化：构建统一的问题分类体系、问题等级标准、治理流程规则等

第四层：治理执行层（问题修复）

针对分析出的核心问题，自动化或人工推动治理动作：

• 问题治理执行：召集对应团队（产品/策略/规则）进行改进

• 策略优化：迭代产品策略

• 治理复盘机制：定期回顾改动效果，迭代治理框架

• 知识回流：将治理方案沉淀为自助产品、客服知识库等，提升后续响应效率

②用户体验中台

为了系统性支撑用户体验优化目标，团队搭建了一套"用户体验中台"能力系统：

数据接入层

整合多元数据来源，确保反馈信号完整性：

数据中间件与基础设施

• 技术栈：ES / Hive / ClickHouse / Kafka / Redis / MySQL

• 能力：实现高频数据实时处理与归档存储，支持多任务并发执行与流式推理

算法层（核心智能能力）

构建了丰富的模型能力体系：

• 内容摘要：基于 SFT + DPO 微调的小模型，提取精简反馈摘要

• 反馈分类：支持多种分类方式（BERT MLP / 生成式 / token-based）

• 语义观点提取：基于 Reward 优化生成并去重

• 情感识别与质量评分：强化训练质量分等级模型

• 突发事件识别：通过向量聚类、趋势识别算法定位突发问题

• 归因分析模型：结合规则库与大模型生成判断反馈成因

• 隐私与安全问题检测：内嵌仿冒诈骗、侵权分级识别算法

智能引擎层（业务赋能引擎）

每个引擎对应体验中台的一个关键环节：

• 体验信号识别引擎：多模态信号过滤与召回

• 内容理解引擎：摘要/分类/观点融合

• 问题挖掘引擎：语义聚类、痛点问题发现

• 归因诊断引擎：与业务流程联动，对问题根因进行定位

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 老师在线解除疑惑！

✅ 有心得体会想分享？群里聊！

扫码入群参与讨论

02

体验信号识别

1. 隐性信号分析

用户体验信号分为两大类：

显性信号

来源于用户在反馈入口、举报渠道等主动上报，特点是：

• 表达明确，指向性强

• 获取成本低，处理相对简单

• 但存在门槛，覆盖面有限

隐性信号

存在于发文、评论、搜索等非结构化渠道中，需要额外挖掘，特点是：

• 表达隐晦，需要智能识别

• 覆盖面广，数据量大

• 可能反映更深层次的体验问题

由于显性反馈存在一定门槛，许多用户选择通过发文、评论、搜索等方式表达不满，但这些信号往往更分散、更模糊，因此需要更强的感知和理解能力。

隐性信号的场景示例：

• 用户在发文中用"阴阳怪气"口吻表达对平台规则不满

• 评论中指责系统推荐不合理

• 搜索"如何提高抖音流量""作品总是审核不过"等

这些未显式表达的内容，可能正是埋藏最深、最广泛的用户体验痛点。

面临的挑战：

• 视频量级巨大（日均千万级）

• 内容多模态

• 有效样本稀疏

2. 隐性信号分析多模态视频理解解决方案

分层架构建模：

体验信号识别采用分层结构：

• 召回层：使用轻量策略+向量检索

• 特征层/决策层：采用多模态大模型，做精细分类

多模态视频理解模型架构：

召回模型结构：

输入模态：

• 视频帧（视觉特征）：使用 Vision Transformer（ViT）

• 视频标题：DistilBERT 编码

• 评论 ASR：语音转文字（可选）

• OCR 文字：提取屏幕中的文本信息

模型架构：

• 多路子模型提取各模态特征

• 借鉴 CLIP 的方法进行双组对齐（Group-wise Alignment）+ Self-Attention 融合

• 输出融合向量，供向量召回使用

训练方式：

• 多任务联合训练，包括视频分类、视频-文本匹配（ITM）、跨模态对比学习（ITC）等

• 数据来源：千万级真实视频样本 + 人工/弱监督标注

提准阶段：InternVL2.5 全参数微调

• 使用万级人工标注样本

• 精调 InternVL2.5-8B 模型，对召回视频进行精细判断

• 精排目标：提升 precision，打上"负向体验"标签

3. 异常信号识别

用户反馈中还隐藏着一些"异常信号"，包括：

（1）小声量敏感问题处理

问题特点：

• 涉政、涉黄、诈骗等，体量极小但严重影响平台声誉

• 数据极度稀疏

• 表达形式多变（变体、隐喻等）

• 传统微调模型效果差，容易过拟合

技术方案：RAG + Prompt 式判断框架

为了实现高召回、高解释性、高灵活性的判断机制，采用如下结构：

①离线阶段：构建知识库
从审核团队沉淀的规则库中提取：

• 敏感文本进行分块处理（Chunking）

• 构建向量索引库（Embedding）

②在线阶段：RAG 检索增强识别流程

• 反馈原声文本改写（Rewriter）

• Embedding 检索+重排

• Prompt 拼接& LLM 判断：

  构造带上下文的判断式 prompt，送入 LLM

  LLM 结合用户文本与对比案例，输出是否敏 + 判断依据

（2）突发大声量问题识别

问题特点：

• 某类问题在短时间内集中爆发

• 语义上高度聚集

• 表现出明显的趋势性

技术方案：Embedding + 时序聚类 + 趋势检测

①信号向量化

• 所有用户进线反馈通过 Doubao Embedding 转为语义向量

• 向量库实时维护

②语义检索聚类

• 新反馈样本进入后，计算其与历史反馈的向量相似度

• 若命中多个相似样本，将其纳入同一线索聚类

③趋势曲线绘制
对每一类语义聚类构建反馈时间序列，设定多维趋势指标：

• 30 分钟增量

• 72 小时累计增量

• 相对 7 日均值涨幅

• 峰值区间变化

④策略模块触发报警

• 运维配置策略模板

• 报警后写入"异常线索库"，供体验运营人工确认治理

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 老师在线解除疑惑！

✅ 有心得体会想分享？群里聊！

扫码入群参与讨论

03

体验内容理解

"体验内容理解"是用户体验中台的核心组件之一，主要通过多模态技术与大模型能力，对用户反馈进行深度处理，包括：

• 反馈摘要：将冗长多轮反馈压缩为精炼表达，助力快速洞察

• 反馈分类：统一结构标签，便于流转和治理

• 质量评分：评估反馈有效性，优先展示高价值样本

• 语义观点提取：在分类标签下进一步细化出动态子问题，构建问题图谱

• 情感分析与总结：进一步强化体验趋势分析与热点问题发现

1. 反馈摘要

（1）背景与挑战

• 用户反馈往往来自电话录音、文本交互等非结构化渠道，内容长、表达冗杂

• 体验运营需要快速洞察，但原文阅读成本高

• 通用大模型虽然具备摘要能力，但缺乏体验视角（如"用户诉求、影响、场景"）

• 标注数据稀缺，无法直接进行监督微调

（2）自动摘要数据生成方案

为解决标注成本高问题，设计了一套基于 Doubao TOT 结构的自动摘要样本生成流程：

Step 1：反馈分类识别

• 将反馈划分为"咨询类 / 办事类 / 举报类 / 功能类 / 吐槽类"等

• 每一类定义专属的"摘要要素结构"（如咨询类：诉求 + 场景+ 原因 + 影响）

Step 2：多分支大模型提要素

• 通过多个版本的 Doubao 模型并行提取要素

• 最终通过"评估模型 + 投票机制"选择最优摘要结果

Step 3：重组润色摘要

• 将多个要素自然语言重构为通顺精炼的摘要句子

• 可复用于微调训练集

（3）模型微调与迭代优化

基于 Qwen2.5-7B 进行全参数微调（SFT），再结合多轮 DPO（对比偏好优化）迭代增强模型的摘要质量：

• DPO 阶段，人工标注或评估模型判断"哪一个摘要更好"，用于构建正负样本对

• 后续摘要判别模型可自动完成版本优劣判断，替代人工评测

（4）自动化摘要评估机制

为减少人工评测摘要质量的成本，构建了一套基于大模型的评估链路：

• 输入原始反馈(多轮对话) → 由 LLM 自动生成多个维度的问题（选择题 + 简答题）

• 将不同版本的摘要代入回答问题

• 判断回答正确率以评估摘要保留关键信息的程度

参考《ConvFaithEval》等大模型摘要信度评估研究。

2. 反馈分类

目前两种主要的分类实现路径：

（1）判别式分类方案（传统结构）

技术实现：

• 基座模型如 BERT、RoBERTa 等

• 将文本编码为向量，通过分类头输出所有类别的概率分布

• 使用 Cross Entropy 训练损失，推理时选择概率最大者作为预测类别

适用场景：

• 类别数量有限

• 对推理速度有强要求的在线服务

局限性：

• 对于长文本表达理解力弱

• 多标签语义相似时，容易出现误分类

• 对低频类别（long tail）支持较差

（2）生成式分类方案（大模型思路）

技术实现：

• Prompt +原文输入，模型直接"生成"标签名称

• 可基于 Qwen、Doubao、GPT-3.5 等通用 LLM 实现

• 支持复杂规则表达，增强解释性

优点：

• 模型能利用预训练知识

• 在小样本、冷启动、新类目场景下效果显著

• 可扩展性强（支持零样本/少样本学习）

挑战：

• 标签"开放式生成"，可能偏离平台定义的闭集标签体系

• 多轮微调成本高

• 推理速度较慢，部署成本高

（3）创新方案：LLM+Token 化标签融合建模

为了融合以上两类方案优势，团队提出一种基于大模型、但标签输出封闭可控的新型分类框架：

核心思路：

• 将所有标签文本加入大模型的 Tokenizer

• 在训练阶段，LLM 按 token-level 预测"下一个标签 token"，完成分类

• 标签仍然来自预定义集合，但预测方式使用生成式路径

优势：

• 兼具大模型的理解能力与封闭式分类的稳定性

• 解决了"生成出来的标签不在集合中"的问题

• 模型仍然能从 LLM 的上下文建模与指令遵循中受益

• 在多标签、多层级分类任务中表现更稳定

工程细节：

• 标签加入 LLM 词表后，可以指定特定 prompt 触发分类

• 可与 SFT 微调、LoRA 等轻量方案结合部署

• 支持多标签、多层级体系（如一级类-二级类-三级类-四级语义观点）

3. 反馈质量评分

（1）背景与挑战

即使完成了反馈分类，许多大类（如"审核误伤"、"发布失败"等）仍会每日积压数千条反馈，不具备人工全部查看的可能。因此需要构建一个"质量分模型"，将高价值反馈优先展示，提升运营效率。

核心挑战：

• 某些三级标签反馈数量庞大，人工运营难以一一分析

• 高质量反馈（明确、结构清晰、指向明确）更具洞察价值

• 需要构建模型对反馈质量打分，赋予"质量等级"标签

（2）数据构建与思维链生成

数据构建策略：

构建质量分训练数据是最核心也最困难的一步。通过"Prompt + 大模型自监督"的方式自动生成标注数据：

使用 Doubao1.5-ThinkingPro 大模型：

• 输入业务规则（如：什么是有价值的反馈）

• 输出：带有问题要素+思维链+质量标签的样本

生成过程：

反馈解析 → 问题要素抽取 → 思维链生成 → 质量判断 → 格式标准化

数据格式：

• 输入：用户反馈

• 输出：

  思维链（reasoning chain）

  最终质量分等级标签

• 为避免过长链路影响微调，设定链长度控制在 200 字以内

（3）模型训练流程

SFT 微调（冷启动）：

• 使用上述标注数据对小模型进行SFT训练

• 输出格式为"思维链 + 分类结果"

• 指令模板化设计，保证统一输出结构，便于 RL 阶段解析奖励

RL 微调（推理导向优化）：

基于 GRPO（Reward Preference Optimization）进行强化微调：

• 奖励函数设计：

  分类准确率

  思维链长度惩罚（鼓励精炼）

  输出格式化奖励（鼓励"过程+结论"结构）

• 训练经验：

  初始模型选用SFT性能最佳版本

  控制步数避免过拟合

  Temperature 调高（如 0.9）鼓励多样性采样

4. 语义观点提取

（1）背景与目标

在抖音用户反馈系统中，分类体系通常为三级结构（如："基础产品-收藏-异常"）。但在具体的三级标签下，仍然存在大量语义多样的反馈内容，无法进一步细化分析。

例如，同属于"作品收藏异常"类下，用户反馈可能具体指向：

• 收藏数量不展示

• 收藏列表无法打开

• 点赞数和收藏数不一致

• 收藏后无法找到作品

为此，团队提出了"语义观点（Semantic Viewpoints）"的机制，旨在从用户反馈中自动抽取出四级标签或"共性子问题"，实现：

• 提升运营的体验洞察效率

• 降低人工聚类成本

• 为归因、治理与内容改进提供结构化输入

（2）离线观点生成流程

Step 1：训练观点生成模型（Qwen2.5-7B）

• 采用有监督微调（SFT）对大模型进行训练，输入为三级分类下的反馈样本，输出为语义观点

• 模型训练数据来源为人工标注和 Doubao 大模型的辅助标注

• 提取的观点具备通用性和可读性，如：

  "收藏数显示异常"

  "点赞后数据未更新"

  "页面加载卡顿"

Step 2：偏好对齐（DPO/GRPO）

• 将候选观点对进行"好/坏"判断，由人工或 reward model 给出偏好标注

• 用 DPO（Direct Preference Optimization）或 GRPO（Generalized）进行训练

• 目标是生成更有业务解释力、概括力强的观点句式

Step 3：观点去重（Deduplication）

由于自动生成的观点中往往存在大量冗余和语义重复的表达，必须引入观点去重机制：

①基于 Embedding 相似度
使用句向量模型计算候选观点之间的相似度（如 <0.9 即认为不同）

例：

• A："无法收到验证码"

• B："收不到验证短信，想联系客服"

这类语义重复但表述差异大的观点，靠 embedding 很难完全判别。

②基于优化的观点覆盖选择
引入线性规划算法，优化目标为：

• 使用最少的观点数

• 覆盖最多的反馈原文

• 保证观点之间交集最小

③业务知识辅助去重
面对业务语义深度依赖型场景，Embedding 无法完全捕捉。此时构建领域知识图谱来进行实体识别与上下文关系判断，辅助判断是否语义等价。

构建方式：

• 实体识别

• 实体上下文关系建模

• 用 RAG 框架辅助检索上下文，输入 LLM 判断观点是否重复

（3）在线观点匹配机制

离线构建好的观点库之后，在用户实时进线反馈时，需要自动判断其对应的语义观点：

Step 1：候选观点召回（Coarse Retrieval）

• 首先根据反馈所属分类召回该类下所有观点

• 将用户反馈生成摘要并编码为向量

• 在分类下的观点库中做向量检索，获取 Top-K 候选观点

Step 2：观点精细匹配（Reranking）

• 将候选观点与用户反馈摘要、原文一起送入微调后的 Qwen2.5-7B 模型

Step 3：观点覆盖监控与新增更新

• 如果反馈未被已有观点所覆盖（得分低于阈值），将反馈作为新增候选

• 新候选会在离线批处理中进入观点生成流程，实现观点体系的动态更新与扩充

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 老师在线解除疑惑！

✅ 有心得体会想分享？群里聊！

扫码入群参与讨论

04

体验归因与诊断

1. 体验归因背景与难点

反馈本身只能表征用户的痛点，但真正降低反馈量，需要深入探查其成因。当前主要依赖人工运营经验，归因过程费时费力。

典型归因场景

产品功能问题：功能缺失或设计不合理

规则/治理问题：审核误伤、风控过严

A/B实验问题：新功能上线或流量策略调整导致波动

系统性故障问题：后端 Bug 或服务不稳定

2. 实验类反馈归因方案

实验归因步骤

Step 1：指标监控

• 监控情感倾向、解决率、语义观点占比等维度

• 设置报警阈值，捕捉反馈异常上升

Step 2：异常分析

• 抽取摘要 + 典型反馈

• 分析反馈所处实验组 vs 对照组差异（TGI）

• 输出异常特征、实验描述、上线时间等

Step 3：LLM归因分析

• 构建 prompt，输入异常特征+实验元信息

• 由大模型判断是否实验变动导致反馈问题，并提供理由

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 老师在线解除疑惑！

✅ 有心得体会想分享？群里聊！

扫码入群参与讨论

05

总结与展望

1. 从事后到事前治理

用户反馈是"事后体验"的表现形式，而真正要做"体验领先"，就需要拓展至：

事中监控：行为数据、滑动速率、跳出率等指标提前感知用户不满

事前建模：在策略变动（如推荐算法调整）前模拟体验指标波动，加入用户视角建模机制

2. 构建体验 Agent 框架

未来目标是将整个用户体验治理流程——从数据接入、信号识别、洞察抽取、归因分析、反馈回流——构建成统一的 Agent 框架，真正实现体验问题的自动识别、自动理解、自动归因、自动治理的一体化闭环。

结语：抖音用户体验智能化方案通过构建完整的体验治理闭环，从被动响应转向主动洞察，从人工运营转向智能化驱动，实现了用户体验的系统性提升。这一实践为大规模平台的用户体验优化提供了可参考的技术路径和方法论。

分享嘉宾

INTRODUCTION

蔡聪怀

字节跳动

算法专家

哈尔滨工业大学硕士毕业，先后就职于腾讯、字节跳动。从事 AI 算法多年，在内容理解、体验智能化等业务场景有丰富的落地经验。

点个在看你最好看

SPRING HAS ARRIVED