一文读懂推荐系统中的debias

动手点关注 干货不迷路 👆

引言

我们说到的 bias,一般是指一种相对不公平、偏离客观公正的理想状态,或者在整体的各个方面上表现出 unbalanced issues 的现象。对于“客观公正的理想状态”,在各种场景中没有一个统一的定义,而是在各自场景的讨论中会产生一些达成共识的概念。然而,这个概念也是随着人们认知的加深而不断延展的。因此 bias 仍然是一个非常 open 的话题。

推荐系统是一个涉及到众多环节的复杂系统。在系统中,推荐模型基于发生过的用户行为进行学习,对用户进行 item(视频、文章、商品等)的展现,用户对展现出来的 item 产生反馈,反馈的用户行为数据继续被模型学习。在整个链路中,没有哪个环节是绝对意义上的“因”和“果”,它们是一个相互影响的关系。(见图 1)

cae7240ea09daf6ae7c67896a434ed0f.png

图 1. 推荐系统中各个环节和 bias 产生的阶段(来自文献[1])

推荐系统的各个环节都依赖于用户与 item 的交互,交互是有限且需要花费成本的,在某些情况下不会是客观事实的充分反映。在此 bias 就会产生,并且对推荐系统的整个链路产生着影响。

一些比较公认的 bias 包括:

Position bias(位置偏差):

  • 概念解释:用户的精力是有限的,用户有更大概率与展现在靠前位置的 item 发生交互,产生正向行为,而与 item 是否符合用户偏好无关。

  • 负面影响:数据中的正负例 label 不一定客观反映用户偏好。

  • 典型场景:电商/文章 推荐中一个页面内有多个位置展现的点击行为。

Exposure Bias(曝光偏差):

  • 注意:这里的 exposure 曝光,是指 item 真正被用户注意到,而不是 item 简单地在客户端展现。下文会使用曝光一词来代指用户真正注意到了 item,而使用展现一词来代指 item 在客户端展现的埋点上报,以此作为区别。

  • 概念解释:存在于基于隐式反馈(implicit feedback)建模的场景中(比如 CTR 场景),对于全量的 item,用户只会被曝光到其中的少数一部分,并与之产生显式正向行为。那些没有显式行为的 item,可能是用户不感兴趣,也可能是没有曝光给用户。如果简单地将它们都处理为负例用作训练模型,那么将会产生严重的偏差(一些论文将其称为 positive-unlabeled 问题)。另一方面,在推荐结果中,热度越高 item, 会更可能曝光给用户。对于用户来说,一个 item 是否会产生显式正向行为的记录,是非随机缺失的(missing not at random,很多论文中又简称为 MNAR)。这样会导致收集到的数据分布与真实的分布是不一致的。

  • 负面影响:没有正向行为的 item,并非都是真实的负例,简单粗暴处理会带来 false negative。在曝光偏差产生的场景中,有的是将未展现给用户的 item,进行随机负采样作为用户的负反馈;有的是将展现但未产生互动行为的 item 作为用户的负反馈,两者都会带来偏差。

  • 典型场景:使用隐式反馈的电商/视频等推荐。

Selection Bias(选择偏差):

  • 概念解释:存在于基于显式反馈(explicit feedback)建模的场景中(比如商品评分),用户倾向于对喜好的 item 进行评分,并且用户倾向于对非常好或非常坏的 item 进行评分。因此,所观察到的评分结果的数据分布,并不是真实的全量分布。

  • 负面影响:观测数据的分布是有偏的。

  • 典型场景:预测用户对电影的评分。

还有其他的 bias 比如 Conformity Bias(人在社会环境中意见与群体趋同导致的偏差),Popularity Bias(高热度 item 获得的流量远超过合理水平,造成马太效应),不在该文中做更多讨论。

上述 bias 的存在,给推荐系统的服务效果带来了负面影响。在笔者看来,Position bias 和 Exposure Bias 是推荐系统中最重要和常见的两类 bias。因此,下文针对这两类 bias,介绍学术界过去提出的一些主流 debias(消除偏差)的解决方案。

以笔者之见,从技术方案的实现角度而言,Position bias 和 Exposure Bias 的主流 debias 方案可以归类为曝光建模和样本调权两种思路。

  • 曝光建模: 在理论上假设,用户显式行为的发生可以解耦为“item 是否曝光给用户”和“item 是否符合用户偏好”两个事件。在算法设计中,显式地对“是否曝光”进行建模,从而使模型真正地从数据样本中,学习到 item 与用户相关性的客观规律。曝光建模思路的特点是,需要对“是否曝光”的依赖变量做一定假设,并且需要实际数据样本能反映出假设的规律,因此也需要样本量足够充分。

  • 样本调权: 根据业务场景的特性,对不同的样本赋予不同的权重,特别是对置信度较小的样本(例如隐式反馈场景中的负例)赋予较小的权重,使得样本层面上反映出的 bias 得到减轻。另外,根据业务场景中 bias 的产生机理,对于观测到的样本,重新定义损失函数,使其近似趋近于无偏的情况,也是一种 debias 的思路。由于重新定义损失函数的做法,本质上也是改变了不同样本的权重,本文将这一思路归类到样本调权的思路下。样本调权思路的特点是,需要较强的人工经验和业务理解。

需要注意的是,两种思路并没有绝对的区别。在某些方案中,建模了曝光概率,同时利用模型预估得到的曝光概率对样本进行调权。因为这类思路依赖于对曝光的建模,本文将其归类到曝光建模之下。

本文内容组织主要参考综述文献 Jiawei Chen, Hande Dong, Xiang Wang, Fuli Feng, Meng Wang, and Xiangnan He. Bias and Debias in Recommender System: A Survey and Future Directions [1].

本文后续内容安排如下:

  • 曝光建模: 介绍曝光建模思路分别在 position bias 和 exposure bias 场景对应的具体技术方案。在每个 bias 场景标题的开头,简要回顾了 bias 的含义和产生机理。

  • 样本调权: 介绍样本调权思路分别在 position bias 和 exposure bias 场景的方案。其中,在 exposure bias 标题下,将样本调权的方案分为“启发式调权”和“损失函数重定义”两个方向进行叙述。

  • 评估指标的 debias: 介绍在模型评估指标(即 metrics)中消除偏差的思路。

曝光建模

Position bias

位置偏差在 learning-to-rank 系统中是一种常见偏差,它的基本假设是展现在靠前位置的 item 有更大概率被用户点击,无论 item 是否符合用户偏好,在广告系统和搜索排序场景中都比较常见。

对 position bias 采用曝光建模来 debias,思路是,将用户点击行为发生的中间过程拆分出来,对中间的曝光事件进行建模,并利用这些中间过程的模型预测值进行消偏。如何去拆分点击的中间过程,就涉及到了不同的假设,对应着不同的具体方案。

其中一个比较有影响力的方案是PAL(Position-bias Aware Learning)模型 [2],该模型假设:

  • 用户(u)点击(C,click)事件的发生,是 item(i)被用户注意到(E,examined)且 item 有一定概率符合用户偏好(relevant)两者同时满足的结果;

  • 一旦 item 被用户注意到(E),那么用户点击(C)item 的概率,仅仅于 item 与用户本身有关,而与位置无关;

  • item 被用户注意到的概率(E),仅仅与 item 所在的 position(p)有关, 而与 item 是否符合用户偏好无关.

总结起来就是:

其中,r_ui 是用户与 item 是否符合的真正概率,h_q 是仅依赖于位置的 item 被用户注意到的概率。令模型分别建模这两个行为,然后只取 r_ui 作为线上服务时排序的依据。

具体来说,如下图所示,在深度学习模型中,使用位置相关的特征输入构建一个 tower,其他特征输入构建另一个 tower,两个 tower 的最终输出分别经过 sigmoid 之后,相乘到一起(pCTR * ProbSeen),作为一个用于计算 loss 的输出(bCTR)。当模型训练时,样本 label 与 bCTR 计算得到 loss,用于梯度的反向传播。而在线上预估服务时,仅使用 pCTR 的预估值,因为它是去除了 position 之后的消偏结果。

6e6de88c9967f6b42e78fa32ed76310c.png

图 2. PAL 模型示意图(来自文献[2])

另一种思路类似的方案是采用级联模型(cascade model)[3]。该方案假设用户从靠前位置到靠后位置,按顺序逐个地浏览 item,那么是否点击某个位置上的 item,就与该位置以及之前所有位置上的 item 有关。令 E_q 和 C_q 分别代表 q 位置上 item 曝光和被点击的概率。级联模型描述用户行为的发生是如下的关系:

5bbb67ce0834ef6ae03b2481be03a86b.png

其中,第三个等式假设了用户一旦点击了处于 q 位置的 item,那么就会终止本次阅读的过程,不再往下浏览,否则用户还会继续往下浏览。该方案也假设了在每次浏览过程(session)中,最多只能有一次点击。

级联模型建模各个位置处的 E_q 和 C_q,同样使用消偏之后的 r_uq,i 来作为真实的排序依据。

曝光建模的思路有两个缺点,一是对点击行为中间过程的拆分需要大量的数据来支持模型学习,尤其是 user-item 之间的数据是较为稀疏的,在一些数据量偏少的场景中使用难度大;二是引入了人为假设,如果假设不正确,那么就会导致最终结果与预期的南辕北辙。

Exposure Bias

Exposure bias(曝光偏差)产生于需要利用用户的隐式反馈(implicit feedback)来建模的场景中。用户的显式行为(比如点击、评论、收藏)只会发生在极少数的 item 上,因为用户只会被到少量的 item 曝光到。因此,把未观察到互动行为的 item 都作为用户的负反馈,会造成偏差(positive-unlabelled问题)。另一方面,高热的 item 相对中长尾 item,获得了更多的曝光,更可能产生显式正向行为的样本。因此所观测数据中的正向行为,是非随机缺失的(Missing-not-at-Random,MNAR问题),与真实分布不一致。

因为 exposure bias 产生的直接原因是滥用了并非真实的负样本,在这些负样本中无法直接区分哪些是曝光了但用户不感兴趣了、哪些是没有实际上曝光的。那么,如果能对 item 是否曝光进行建模,然后削弱那些曝光概率低的负样本的权重,是会减轻 bias 的影响的。

具体地,训练模型学习一个 item 是否曝光给用户的概率,item 曝光的概率越高(对应地,item 在客户端展现的次数越多),那么说明 item 对应的隐式反馈样本的置信度也就越大。因此,可以将模型学习到的曝光概率赋值给损失函数里面样本的权重。

在早期朴素的 WMF 思路影响下,研究者考虑在矩阵分解的过程中,加入 item 是否曝光给用户的隐变量 O_ui, 通过模型学习到 O_ui,来更好地辅助损失函数里面的权重赋值[12],被称为ExMF(Exposure Matrix Factorization,含有曝光的矩阵分解)方法。具体地,考虑如下的概率生成过程:

a37463e58880f8a7905e54f9f8b16a51.png

其中 N 表示高斯分布,Bern 表示伯努利分布,μ_u,i 是 item i 曝光给用户 u 的概率,U,V 分别是储存用户向量和 item 向量的矩阵,

代表用户 u 对 item i 的偏好程度;

表示在用户 u 被 item i 曝光后,是否与 item 产生显式正向行为的变量;

都是表达高斯分布方差的超参数。

要确定用户和 item 矩阵 U,V 以及曝光矩阵 μ,就需要采用极大似然法最大化以下概率:

402 Payment Required

由于是否曝光{o_u,i}是隐变量,需要采用一个类似 EM 的算法来不断更新参数,最终,可以获得 E[Ou,i|Yu,i=0]的先验概率,来对损失函数中的样本置信度赋值。

样本调权

样本调权思路,从逻辑上说是直观的:在有 bias 的场景下,某些样本携带的信息可信度小,但是不能完全丢弃它们,因此赋予较小权重,使得它们对模型整体的影响减轻;或者,同样是展现给用户的 item,某些 item 有更高的曝光几率,它们的正反馈占比更高,因此它们的正样本权重应当被削弱,而另外一些 item 的正样本权重应该被增强。

Position bias

Propensity Score(倾向性打分,下文简称 PS)是修正位置偏差的一种通用方法[4],在计算每条样本的 loss 时,每条样本基于它所在的位置被重新赋予了权重。这个权重是和位置相关的,该方案里正样本对应的 loss 函数被修正为:

其中 U 和 I 分别是用户集合与 item 集合,

对应着在模型 f 下(u,i)这条样本的 loss;ρ(q)是倾向性打分(即 PS),仅仅与位置 q 有关,这也是倾向性打分这一方法中的一个重要假设。

如果一个 item 展现的位置越靠前,它的 PS 就越高,那么这条样本对应的 loss 被降权得越厉害。同时,那么展现在靠后位置的 item,它们的 loss 将可能被加权。

由于倾向性打分方法做了一个非常强的假设(倾向性打分仅仅与位置相关, 而与用户和 item 无关),因此估算各个位置上的 PS 就变得非常简单。

一个很直接的做法是 result randomization(结果随机化):将模型排序的结果打乱,展现在用户面前,然后收集各个位置上的用户点击率。因为在各个位置上,item 与用户的相关性已经是均等的了,因此不同位置上的点击率就是各个位置上的倾向性打分的无偏估计。

但是这种做法对自然推荐的结果进行了人为干预,有损用户体验,并不是一个最优的办法。除了这种简单粗暴的 result randomization 之外,人们也提出了一些基于模型的方法来学习各个位置上的倾向性得分。将 item 是否被用户注意到作为一个隐变量,设计了一个包含倾向性打分模型和推荐模型的 EM 算法来求解该问题。[5,6]

Exposure Bias

在利用隐式反馈的场景中,为了提取负反馈的信息,一般会将未观察到显式反馈的 item 一律作为负例,然后对每个负例赋予一定的置信度。对应的损失函数表达如下:

402 Payment Required

其中 S_ui 是用户 u 与 item i 之间是否有正向行为的 label;

是推荐模型 r 预估的正向行为发生概率;W_ui 是表达置信度的权重;δ 是损失函数的具体表达式(比如交叉熵代价函数)。在模型训练中的 debias 相关思路,一般是围绕如何给隐式反馈的负例赋予恰当的权重来进行的。

启发式调权

对隐式反馈的负例进行调权,针对的更多是 positive-unlabeled 问题。一个早期的朴素思路是加权分解矩阵(weighted factorization matrix,简称 WMF)[8]。该思路采用:

即,对正例加权,对未观察到正向行为的 item 采用普通的权重。这就相当于等价地对

的样本降权。这种做法背后的动机是,未观察到正向行为的样本,无法确定用户是否真的不喜欢,因此需要降低样本的置信度。

在此基础上利用更多的用户信息或 item 信息,提出的其他方案包括:利用用户的活跃度进行权重赋值:

因为有更多正向行为的用户,其对应的样本的置信度越大[9];利用 item 的热度进行权重赋值,因为越流行的 item,有更高的几率曝光,样本的置信度也应当越大[10];利用用户与 item 的特征相似度来确定权重[11]。

虽然方法众多,启发式调权仍然是一个有较大难度的方案,其一是用户与 item 之间隐式反馈样本的置信度的确定,需要大量数据与计算资源;其二是权重的设定,也引入了人为的经验与假设,如果人为的经验就是带有偏差的,那么会加重偏差。

损失函数重定义

在 exposure-based model 方案中,曝光概率越高的 item,对应的样本的置信度越高。但是它没有处理另一个问题,那就是隐式反馈建模中的非随机缺失(missing not at random)问题。

高曝光概率 item,一般也是高热度的 item。通过调大它们的样本的权重,模型将会偏向于对高热度的 item 学习更准,而在中长尾的 item 上的学习变差。

因此,将是否曝光与曝光后是否发生显式反馈这两个变量进行进一步的解耦,并重新定义损失函数,使之完全依赖于客观的 user-item 相关性,是一种更进一步的思路[13]。

基于以上的动机,研究者将显式反馈的发生解耦为“曝光”(O_u,i = 1)与“item 符合用户偏好”(R_u,i = 1)同时发生。

7276b8dd9ba3593ee6a9f6651afa25db.png

其中

11a4146c468483d82e7ec9cbb67728f1.png

分别表示 item i 曝光给用户 u 的概率,和 item i 符合用户 u 的偏好的概率(又称 item 与用户的相关性)。

如果把模型的评估指标,从拟合 click 数据:

8b4dee7cd2c13f107a2554c78efa28fe.png

转变为,拟合 item i 与用户 u 的真实相关性;

2776e650ce4e6c652e724a428aeabfa9.png

那么,损失函数需要重新定义为如下的形式:

462ef15dcf66ebd7a2ce2a9b245e38c8.png

其中 δ(·)为具体的损失函数(比如交叉熵代价函数);

7085b7a389b2e34df1a9e7cea87b2de9.png

为模型预估的用户 u 与 item i 的相关性;

括号里的两项分别代表 item 与用户有相关性,或没有相关性的预估损失。

可以证明的是,以上两种方法(Heuristic Weighting 和 Exposure-based model)定义的损失函数,都不是上述理想损失函数的无偏估计。

实际上,可以证明,理想损失函数的无偏估计的表达式为:

4cb4f0e8665bbd6b3852bf8fcab8079f.pnge44a4875af418e0f6d7ea018c55ecb8b.png

那么,问题就转移到了,如何去估计 item i 对用户 u 的曝光概率,这是一个倾向性打分的估计问题。最简单的做法是,使用 item 的相对热度来估算倾向性打分,即:

c78ac6d48dde828959fb1647e9e3ed99.png

其中分母是正向行为次数最多的 item 对应的总次数,分子是当前 item 的正向行为次数。ŋ≤1 作为一个超参数来调节曝光概率的大小,因为相对于统计得到的后验点击率,曝光概率应当大于后验点击率。需要注意到,这个估算是对用户无差别的,存在一定局限性。(文献[13]中的做法)更多地倾向性打分的估算思路,可以参考上文“启发式调权”。

评估指标的 debias

在样本层面就包含了 bias 的场景中,人们把所有样本一视同仁地加入到模型的评估指标中,也会造成评估指标的 bias,所以需要矫正评估指标当中的偏差。

一个比较直接的办法是利用 inverse propensity score(倾向性打分的倒数,下文简称 IPS)来矫正评估指标中的偏差[7]。从直观上去理解 IPS 方法,即对那些频繁出现的 item 降权,而对那些较少出现的 item 做加权。

对于推荐系统而言,理想情况下的评估指标都可以表达成如下的形式:

eeced87749c076cab9e71d9607252291.png

其中全量 item 的集合标记为|I|;

7c56defbcd8953db0e59a5d4770529d5.png

是用户发生过正向行为(比如点击、观看)的所有 item 的集合(即正例集合);

是推荐模型 Z 对(u,i)预测后返回 i 在|I|中排序的位置,排在首位即:

U 是用户 u 的集合,c(·)是待评估指标的具体表达式,与指标定义有关,比如对于 AUC 来说,它的表达式为:

在上述理想的评估指标中,假定用户浏览了全量 item 并做出反馈。但在实际产品场景下是不可能的:用户只会被曝光到部分 item。因此,上述评估指标在实际场景下成为:

7107d9b19adafdb14fa6552e50c1b54f.png

其中 O_ui 表示 item i 是否曝光到了用户 u;

a4ef93a0c7c4cac1d406a932ec9bc4f1.png

表示用户对曝光的 item 发生了正向行为的 item 集合;指标的下角标 AOA 表示 Average-over-all。可以发现,在实际的评估指标中,指标也受曝光变量 O 的影响。

曝光变量 O_ui 即 item i 是否曝光给用户 u,并不是无偏的,往往高热 item 更可能曝光给用户。具体来说,会导致

对曝光变量 O 的期望值,并不等于理想的指标

(参考文献[7]中的证明):

如果把 IPS 加入到指标的定义中,即采用如下形式的指标:

就会发现它是

的一个无偏估计:

其中 IPS P_u,i 形式上定义为

即 item i 曝光给用户 u 的概率。现在问题就转移到了如何去估计

这是用户 u 在全量 item 中会发生正向行为的 item 集合大小。[7]中提出了一种自归一化的 IPS 指标(Self-Normalized Inverse-Propensity-Scoring evaluator),形式如下:

该指标被证明了在数据量 n 极大的情况下,将会收敛到

af5dcbb67d2958c9293544d334f6bf8f.png

在该框架下,问题即转换成为了如何去估计 IPS,则成为一个较为开放的问题,有相关的各种解决方案。(参考上文“启发式调权”)

参考文献

[1] Jiawei Chen, Hande Dong, Xiang Wang, Fuli Feng, Meng Wang, and Xiangnan He. 2020. Bias and Debias in Recommender System: A Survey and Future Directions.

[2] Huifeng Guo, Jinkai Yu, Qing Liu, Ruiming Tang, Yuzhou Zhang. 2019. PAL: A Position-bias Aware Learning Framework for CTR Prediction in Live Recommender Systems.

[3] Nick Craswell, Onno Zoeter, Michael Taylor, and Bill Ramsey. 2008. An experimental comparison of click position-bias models.

[4] Aman Agarwal, Kenta Takatsu, Ivan Zaitsev, and Thorsten Joachims. 2019. A general framework for counterfactual learning-to-rank.

[5] Qingyao Ai, Keping Bi, Cheng Luo, Jiafeng Guo, and W Bruce Croft. 2018. Unbiased learning to rank with unbiased propensity estimation.

[6] Thorsten Joachims, Adith Swaminathan, and Tobias Schnabel. 2017. Unbiased learning-to-rank with biased feedback.

[7] LongqiYang, YinCui, YuanXuan, ChenyangWang, SergeBelongie, and DeborahEstrin. 2018. Unbiased offline recommender evaluation for missing-not-at-random implicit feedback.

[8] Yifan Hu, Yehuda Koren, and Chris Volinsky. 2008. Collaborative filtering for implicit feedback datasets.

[9] Rong Pan and Martin Scholz. 2009. Mind the gaps: weighting the unknown in large-scale one-class collaborative filtering.

[10] Xiangnan He, Hanwang Zhang, Min-Yen Kan, and Tat-Seng Chua. 2016. Fast matrix factorization for online recommendation with implicit feedback.

[11] Yanen Li, Jia Hu, ChengXiang Zhai, and Ye Chen. 2010. Improving one-class collaborative filtering by incorporating rich user information.

[12] Dawen Liang, Laurent Charlin, James McInerney, and David M Blei. 2016. Modeling user exposure in recommendation.

[13] Yuta Saito. 2020. Unbiased Pairwise Learning from Biased Implicit Feedback.

相关推荐

2024 抖音欢笑中国年(五):Wasm、WebGL 在互动技术中的创新应用

前言随着 Web 前端技术的不断发展,越来越多的新兴技术方案被引入到 Web 开发中,其中 Wasm 和 WebGL 作为前端领域的两大利器,为开发者带来了更多的可能性。本文将结合2024 年抖音欢笑中国年的部分项目,重点介绍如何利用 Wasm 和 WebGL 对目前流行的一些前端互动技术(比如 Lottie、渲染引擎、动画图片等)进行创新和实践,利用 Wasm 和 WebGL 等新技术方案的特性...

字节跳动技术团队官方博客 2万+

2024 抖音欢笑中国年(四):渲染技术实践与探索

作者:陈瑞、欧阳浩铸、王武俊、倪梵云前言抖音在2024年春节期间推出了欢笑中国年系列活动,为用户带来了全新的体验和乐趣。而SAR Creator则为该项目研发工作提供了重要的技术支持。SAR Creator是一款基于 Typescript 的高性能、轻量化的互动解决方案,目前支持了浏览器和跨端框架平台,服务于字节内部的各种互动业务。这些绚烂多彩的互动场景当然也离不开实时渲染技术的支持,因此本文将专...

字节跳动技术团队官方博客 2万+

2024 抖音欢笑中国年(三):编辑器技巧与实践

前言本次春节活动中,我们大部分场景使用内部的 SAR Creator互动方案来实现。SAR Creator 是一款基于 TypeScript 的高性能、轻量化的互动解决方案,目前支持了Web和字节内部跨端框架平台,服务于字节内部的各种互动业务,包括但不限于抖音春节、抖音直播礼物、抖音UG活动等。SAR Creator 编辑器支持了图形化界面,提供了各类完善的系统(光照、动画、脚本等)供用户快速便捷...

字节跳动技术团队官方博客 1万+

2024 抖音欢笑中国年(二):AnnieX互动容器创新玩法解析

本文基于24年抖音春节活动业务背景,介绍了字节跨端容器AnnieX在游戏互动套件上的探索,致力于提升容器在游戏互动场景的优化能力。业务背景AnnieX作为字节一方游戏统一容器,服务字节内部电商、直播、UG等跨端场景业务。在字节一方游戏互动场景,有大量的一方游戏业务对容器有特定的流量、端能力和游戏优化的诉求。因此我们不断深入互动游戏业务特点,为字节游戏提供完善游戏端能力和流量运营能力,同时提供游戏互...

字节跳动技术团队官方博客 1万+

2024 抖音欢笑中国年(一):招财神龙互动技术揭秘

字节跳动旗下的抖音等 App 在 2024 年春节期间推出了欢笑中国年系列活动,在实现增长业务目标的同时,为用户带来了全新的体验和乐趣。「招财神龙」是其中的一个重要玩法。前言本次春节活动,使用到了字节内的主要前端、跨端、互动技术产品。主要涉及:跨端框架提供了首屏直出的方案使其具有较短的首屏时间,能够大大提升业务加载成功率。跨端框架也提供了 Canvas 作为 SAR Creator 等渲染引擎的...

字节跳动技术团队官方博客 1万+

Monorepo 解决方案 — 基于 Bazel 的 Xcode 性能优化实践

背景介绍书接上回《Monorepo 解决方案 — Bazel 在头条 iOS 的实践》,在头条工程切换至 Bazel 构建系统后,为了支持用户使用 Xcode 开发的习惯,我们使用了开源项目 Tulsi 作为生成工具,用于将 Bazel 工程转换为 Xcode 工程。但是在使用的过程中,我们发现了一些问题,其中影响较大的是,Xcode 工程卡顿:对于头条这种大型项目来说,Xcode 卡顿一直是本地...

字节跳动技术团队官方博客 1万+

抖音 ANR 自动归因平台建设实践

背景介绍本文在 2024 年初最新一期『抖音客户端基础技术大揭秘』技术沙龙活动中已做过专题分享,本次将内容重新整理文章进行分享。公众号后台回复技术沙龙可查看沙龙回放及 PPT~抖音作为一个超大型的应用,我们在 ANR 问题治理上面临着很大的挑战。首先对于存量问题的优化,由于缺少有效的归因手段,一些长期的疑难问题一直难以突破解决,例如长期位于 Top 1 的 nativePollOnce 问题。同时...

字节跳动技术团队官方博客 2万+

CVPR 2024 | CAMixerSR 动态注意力分配的超分辨率加速框架

背景随着相关技术和应用的发展,比如超高清屏幕、虚拟现实(VR)等沉浸式体验的增加,用户对超高分辨率图像和视频的需求变得越来越强烈。在这些场景中,图像的质量和清晰度对于提供最佳的用户体验至关重要。超高分辨率不仅能提供更清晰、更真实的视觉效果,还能在一定程度上增强人们的互动和沉浸感,在一些VR场景中我们需要8K甚至16K的才可以满足需求。然而要生成或者处理这些超高分辨率的内容,对算力的要求也是与日增长...

字节跳动技术团队官方博客 1万+

CVPR 2024 | Modular Blind Video Quality Assessment:模块化无参视频质量评估

无参视频质量评估 (Blind Video Quality Assessment,BVQA) 在评估和改善各种视频平台并服务用户的观看体验方面发挥着关键作用。当前基于深度学习的模型主要以下采样/局部块采样的形式分析视频内容,而忽视了实际空域分辨率和时域帧率对视频质量的影响,随着高分辨率和高帧率视频投稿逐渐普及,特别是跨分辨率/帧率视频转码档位画质评估场景中,这种影响变得更加不可忽视。在本文中,我们...

字节跳动技术团队官方博客 1万+

2024 AI & 前端:回首展望,光芒未至,破晓之前!

前言回望 2023 年,ChatGPT 的突然爆火,让 AI 无疑成为最为值得注目的新兴领域之一,我们也一起见证了生成式 AI 的寒武纪大爆发。这一年来,国内外的生成式 AI 、大模型和相关产品以令人眼花缭乱的速度更新迭代,新的创业浪潮风起云涌。在这 AI 浪潮下,也让我们有了新的开发思考,探索着在各个环节中“前端 & AI”的应用场景。勇于探索的前端开发者们已经开始挥舞着 AI 的“魔法...

字节跳动技术团队官方博客 1万+

Kotlin 云端差分缓存技术

本文由字节跳动 Buildinfra 团队出品。在我们的工程上线 Monorepo 全源码后,Kotlin 编译成了整个编译中最耗时的步骤,全源码过程中大量的 BuildCache Miss 导致我们的编译数据落后原来多仓二进制时代很多,且业界没有相关的解决方案。本篇文章我们来具体阐述下 BuildInfra 团队自研的解决方案 - Kotlin 云端差分方案的原理和技术实现。一、Monorepo...

字节跳动技术团队官方博客 1万+

字节跳动基础架构SRE-Copilot获得2023 CCF国际AIOps挑战赛冠军

近日,2023 CCF国际AIOps挑战赛决赛暨“大模型时代的AIOps”研讨会在北京成功举办,活动吸引了来自互联网、运营商、科研院所、高校、软硬件厂商等领域多名专家学者参与,为智能运维的前沿学术研究、落地生产实践打开了新思路。决赛中,从初赛两百多支队伍中脱颖而出的十支入围队伍分别展示了各自的方案,并进行了现场答辩,评审专家从选题方向、创新性、实用性、完整度和实验复现结果等多角度进行了综合评定,最...

字节跳动技术团队官方博客 2万+

字节跳动百万级Metrics Agent性能优化的探索与实践

背景metricserver2 (以下简称Agent)是与字节内场时序数据库 ByteTSD 配套使用的用户指标打点 Agent,用于在物理机粒度收集用户的指标打点数据,在字节内几乎所有的服务节点上均有部署集成,装机量达到百万以上。此外Agent需要负责打点数据的解析、聚合、压缩、协议转换和发送,属于CPU和Mem密集的服务。两者结合,使得Agent在监控全链路服务成本中占比达到70%以上,对Ag...

字节跳动技术团队官方博客 1万+

西瓜视频RenderThread引起的闪退问题攻坚历程

背景影响西瓜之前存在过一类RenderThread闪退,从堆栈上看,全部都是系统so调用,给人的第一印象像是一个系统bug,无从下手。闪退集中在Android 5~6上,表现为打开直播间立即闪退。该问题在2022年占据Native Crash Top5,2023年更是上升到到Top1。因此有必要投入时间和精力再重新审视一下这个问题。在历经多周的源码分析和排查后,逐步明确了问题根因并修复,最终取得了...

字节跳动技术团队官方博客 2万+

字节电商双11 大促容量保障是如何做的?

前言Rhino 简介Rhino是字节自研全链路容量评估产品,致力于构建完整的全链路容量评估解决方案(覆盖:容量预估->资源准备->数据准备->容量验证->监控->分析->决策->处理反馈);围绕容量在稳定性、成本、效率 三方面提供业务全方位基础支撑。Rhino 目前已经成为字节各业务容量评估主流解决方案,并且历年来在业务大型活动稳定性保障中(抖音春节项目、...

字节跳动技术团队官方博客 10万+

使用火山引擎 APMPlus 解决抖音Top 1 Java 崩溃的通用优化方案

背景近3个月,抖音 Android 版面临一个多次触发线上报警的崩溃问题,全量版本和灰度版本的异常数据激增,该问题不仅容易触发报警,更成为了 Java Top 1 崩溃问题,带来巨大困扰,急需攻坚解决。本文展现了具体的分析过程、优化思路和解决方案,同时提供了已集成该方案的实用工具。初步分析多维特征我们以某发版期间数据为例进行分析:机型方面:比较分散,有聚集部分samsung sm-s9180 占比...

字节跳动技术团队官方博客 2万+

用 Addon 增强 Node.js 和 Electron 应用的原生能力

前言Node.js Addon 是 Node.js 中为 JavaScript 环境提供 C/C++ 交互能力的机制。其形态十分类似 Java 的 JNI,都是通过提供一套 C/C++ SDK,用于在 C/C++ 中创建函数方法、进行数据转换,以便 JavaScript / Java 等语言进行调用。这样编写的代码通常叫做 Bindings。此外还有基于 C ABI Calling Convent...

字节跳动技术团队官方博客 2万+

火山引擎 ByteHouse 的增强型数据导入技术实践

作为企业数字化建设的必备要素,易用的数据引擎能帮助企业提升数据使用效率,更好提升数据应用价值,夯实数字化建设基础。数据导入是衡量OLAP引擎性能及易用性的重要标准之一,高效的数据导入能力能够加速数据实时处理和分析的效率。作为一款OLAP引擎,火山引擎云原生数据仓库ByteHouse源于开源ClickHouse,在字节跳动多年打磨下,提供更丰富的能力和更强性能,能为用户带来极速分析体验,支撑实时数据...

字节跳动技术团队官方博客 1万+

打造企业级智能问答系统的秘密:如何使用云数据库 PostgreSQL 版实现向量检索

本文就如何利用火山引擎云数据库 PostgreSQL 版和大语言模型技术(Large Language Model,简称 LLM),实现企业级智能交互式问答系统进行介绍。通过本文,你将会了解交互式问答系统的原理,学习 PostgreSQL 的向量化存储和检索技术,以及大语言模型交互技术等。背景在大数据的浪潮下,众多企业建立了自己的知识库,以便于信息检索和知识查询。然而,随着知识库内容的膨胀,传统的...

字节跳动技术团队官方博客 2万+

抖音大型直播的画质优化实践

面临挑战随着抖音内容生态的不断丰富,越来越多的大型赛事在抖音平台进行直播,世界杯/春晚/亚运会等各项赛事节目引来大量用户观看。卡塔尔世界杯期间,抖音提供的稳定高质直播画面为观众带来了完美的观赛体验,决赛的 PCU 高达 3700W+。不同赛事节目涉及链路众多,且不同赛事之间存在差异,如何保障各链路的画质稳定并进一步提升画质,是一个巨大的挑战。如何应对挑战?画质优化链路大型赛事直播涉及链路较长,不同...

字节跳动技术团队官方博客 2万+

抖音直播新一代BVC编码器正式亮相

面临挑战在直播行业发展如火如荼的今天,用户对视频体验的要求也水涨船高。视频基础体验的关键要素包括清晰度、流畅度、低延迟等,而这些要素的“第一性原理”,就是视频本身的编码效率,也就是压缩率。视频编码是整个技术体系的基座,编码效率的显著提升,能够在同等码率下极大提高画质,从而改善用户体验。视频编码效率的重要性不言而喻,但进一步地提升也并非易事,尤其在直播场景中,对编码速度、延迟、码率控制等方面都有很高...

字节跳动技术团队官方博客 7356

Go Metrics SDK Tag 校验性能优化实践

背景Metrics SDK 是与字节内场时序数据库 ByteTSD 配套的用户指标打点 SDK,在字节内数十万服务中集成,应用广泛,因此 SDK 的性能优化是个重要和持续性的话题。本文主要以 Go Metrics SDK 为例,讲述对打点 API 的 hot-path 优化的实践。用户在使用 SDK API 进行打点时,需要传入指标对应的 Tag:tags:=[]m.T{{Name:"foo...

字节跳动技术团队官方博客 1万+

云上智能驾驶三维重建最佳实践

智能驾驶技术的不断发展,正在改变着我们的出行方式和交通系统。作为其中的一个关键技术,三维重建在智能驾驶系统中起着重要的作用。除去车端本身的感知、重建算法,自动驾驶技术的落地与发展需要庞大的云端重建能力支撑,火山引擎多媒体实验室通过行业领先的自研三维重建技术,结合强大的云平台资源与能力,助力相关技术在云端大规模重建、自动标注、真实感仿真等场景的落地与应用。本文重点介绍火山引擎多媒体实验室三维重建技术...

字节跳动技术团队官方博客 6305

火山引擎实时、低延时拥塞控制算法的优化实践

摘要火山引擎智能拥塞控制算法 VICC(Volcano Intelligent Congestion Control)是一种自适应的拥塞控制算法,旨在解决全球不同网络环境下,不同音视频应用对带宽利用率和延时的差异化要求。它结合了传统拥塞控制算法(如 GCC 和 BBR)的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应带宽探测幅度、自适应丢包检测策...

字节跳动技术团队官方博客 6735

veImageX 演进之路:Web 图片加载提速50%

背景说明火山引擎veImageX演进之路主要介绍了veImageX在字节内部从2012年随着字节成长过程中逐步演进的过程,演进中包括V1、V2、V3版本并最终面向行业输出;整个演进过程中包括服务端、客户端、网络库、业务场景与优化等多个角度介绍在图像处理压缩、省成本与体验优化的经验与方案;本篇文章重点介绍在web端演进和提供的能力,图片是 Web 站点中的重要元素,图片体积、格式、分辨率以及渲染方式...

字节跳动技术团队官方博客 6589

自研多模态追踪算法 PICO 为「手柄小型化」找到新思路

作者:张韬、林泽一 、闻超 、赵洋研发背景作为头戴的追踪配件,VR手柄可以通过HMD(头戴显示设备)的inside-out光学追踪定位原理,计算出手柄的空间运动轨迹,同时结合6轴传感器实现6DoF空间定位。与此同时,结合手柄控制器的物理按键、马达反馈、摇杆等,用户还能获得逼真、细腻的触觉反馈,进一步增强虚拟现实人机交互的能力以及沉浸感,这也是目前无手柄方案所难以实现的。目前主流VR手柄的追踪技术方...

字节跳动技术团队官方博客 7818

如何利用播放器节省20%点播成本

点播成本节省的点其实涉及诸多部分,例如:CDN、转码、存储等,而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践,播放器恰恰是成本优化中最重要和最为依赖的部分。火山引擎的视频团队做了份数据统计,在一个很经典的视频业务中,我们在2022年至2023年大约1年半的时间里,针对这个业务进行了33次成本优化点,其中13次是播放器主导的优化,其余的有12次也是需要播放器强...

字节跳动技术团队官方博客 6176

火山引擎 ByteHouse:ClickHouse 如何保证海量数据一致性

背景ClickHouse是一个开源的OLAP引擎,不仅被全球开发者广泛使用,在字节各个应用场景中也可以看到它的身影。基于高性能、分布式特点,ClickHouse可以满足大规模数据的分析和查询需求,因此字节研发团队以开源ClickHouse为基础,推出火山引擎云原生数据仓库ByteHouse。在日常工作中,研发人员经常会遇到业务链路过长,导致流程稳定性和数据一致性难保障的问题,这在分布式、跨服务的场...

字节跳动技术团队官方博客 6900

抖音集团都在用的画质评估工具,确定不试试吗?

导读本文从抖音集团内部画质评估体系的建设历程着笔,主要分享了画质评测对于业务的重要性、主要应用场景和内部产品的一些典型实践案例。通过分享业务视角遇到的一些问题和我们的解决思路,希望能抛砖引玉,为遇到类似困扰的伙伴们提供有价值的参考。画质评估体系建设历程为何评测画质如此重要?我们通过线上业务大量实验发现,图片画质优劣对点击率、 停留时长等消费类指标有正相关影响,间接影响用户收益指标。因此,建设一套行...

字节跳动技术团队官方博客 7940

VLDB 2023 | CDSBen: 字节跳动 veDB 数据库存储系统性能测试模型

背景随着业务爆炸式增长与云原生技术的日渐成熟,大量云原生分布式数据库产品如雨后春笋般涌现,其中一部分主打 OLTP 场景的分布式数据库强调的是从计算-存储分离架构获得弹性收益;对于业界各种计算-存储分离架构的数据库而言,怎么用真实的端到端数据库 workload 去 benchmark 其底层存储系统一直存在以下难题:对于数据库专用存储系统,不存在如 fio 一样的“事实标准” benchmark...

字节跳动技术团队官方博客 5896
上一篇: 实战!如何从零搭建10万级 QPS 大流量、高并发优惠券系统
下一篇: DanceNN:字节自研千亿级规模文件元数据存储系统概述
 字节跳动技术团队
字节跳动技术团队 企业官方账号 企业官方账号
博客等级 码龄7年 8152粉丝 316原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值