2026-08-16

1. X 알고리즘 4세대+1 후속 드랍 — 가중치 해석 규칙 명시 + 브라질 선거 필터 + Phoenix bool 3종 + Thompson sampling + BDSM enforcement note

어제 daily/2026-08-15.md에서 다룬 4세대 드랍(47c1bcd, 2026-08-13)은 파일 300개+·+363K줄로 파라미터 미러링·visibility-filtering·labeling 서브레포 15개를 통째 열었다. 그 다음날 X는 커밋 하나를 더 추가했는데, 이는 4세대의 후속 정리와 확장이다. 4세대의 성격을 새 README가 자평하듯 이 릴리즈는 이제 "로직의 형태를 보여주는 것"에서 "값과 규칙을 검증 가능한 형태로 붙이는 것"으로 넘어왔고, 오늘 커밋은 그 성격을 하루 만에 다섯 방향으로 확장한 셈이다.

특히 세 방향이 canon에 직접적 영향을 준다.

첫째, 가중치 비율의 해석 규칙이 코드 안에 못박혔다. canon은 3세대까지 인용해온 "reply 13.5 vs favorite 0.5 → 27배" 유의 서술을 여러 곳에서 사용했는데(예: multi-task-ranking.md), 이는 원리적으로 잘못된 프레이밍이라는 것이 X 스스로의 주석으로 확정됐다. 가중치는 예측 확률에 곱해지므로 raw count 비율이 아니다. 이 규칙은 4세대의 미러 공개와 짝지어 판독 가이드가 없으면 오히려 오해를 낳는다는 점을 X가 명시적으로 인정한 것.

둘째, 관할권 필터가 코드 안에서 그대로 관찰되는 첫 사례가 나왔다. DSA·GDPR·NetzDG 등 규제 대응은 지금까지 대부분 규제 제출 문서(EU 투명성 리포트)로만 확인 가능했다. Brazil2026ElectionFilter는 브라질 선거법원(TSE)이 조치한 계정 665개를 코드 상수 FxHashSet<u64>로 하드코딩하고, @username을 각 ID 옆 주석으로 남기며, 뷰어가 그 계정을 팔로우 중이면 예외로 처리한다(균일한 정치적 대칭). 이 관행이 유지된다면 각국 선거 사이클마다 유사 필터가 코드에서 확인 가능해진다는 뜻이고, X가 4세대 README에서 강조한 *"a benefit of open-source is that you can see that changes like this exist, and exactly how they work"*가 규제 대응에도 적용된다는 신호다.

셋째, Phoenix 랭커의 입력 피처 표기가 처음 채워졌다. 4세대 초까지 코드에서 관찰된 bool_features: vec![false; ...]는 canon의 "죽은 필드" 함정 목록에 남아 있었다. 4세대+1에서 3개(stale post 14일·author↔viewer 팔로우 방향 2개)가 처음 실제 값으로 채워진다. 특히 stale post 시그널이 count zeroing과 짝지어 들어간다는 점이 흥미롭다 — 랭커에게 "이 카운트가 낮은 이유는 인기 없어서가 아니라 오래돼서 노출이 끊긴 것"이라고 명시 라벨을 붙여, 3세대까지 canon이 관찰해온 snowball 문제(오래된 포스트의 낮은 count가 낮은 랭킹을 낳고 그것이 다시 낮은 count를 낳는 자기강화 루프)를 랭커가 학습으로 우회하게 하는 설계.

새로 알게 된 것 — 가중치 해석 규칙 (canon 정정)

파일 헤더 주석이 이 규칙을 최우선으로 못박는다 [확인] — home-mixer/params/param.rs:281-306:

"Each weight multiplies the predicted probability of that action (P(favorite), P(repost), …) or a continuous value e.g. watch time -- the weights do not multiply raw engagement counts. One common misinterpretation is that you can read these weight ratios as count equivalences, e.g. the incorrect statement that 'one report cancels 468 likes' -- this is incorrect because the weights apply to the predicted probabilities rather than raw counts." — home-mixer/params/param.rs:283-292

그리고 왜 그 절대값이 그렇게 커 보이는지를 이어서 설명한다:

"And the baseline probability of a Report is more than 1000x lower than a Like, so it's weighted more to allow the prediction to affect the final ranking at all."

즉 report −234의 크기는 가치 × 1/propensity의 곱이며, 리포트 propensity가 like 대비 1000분의 1 이하라 절대값이 큰 것이다. 어제의 정본에서 이미 이 방향으로 caveat을 걸어놨지만 이번엔 코드 안에서 X 스스로 이렇게 서술했다.

같은 주석이 mass reporting 오해도 두 가지 이유로 부정한다:

"It's predicting your likelihood of the action, not summing up raw weights on counts. Also, recommendations are personalized, so reports from bad actors will primarily affect recommendations for users who are similar to the bad actors, rather than having the same effect on the post's ranking to everyone."

즉 봇 계정의 대량 리포트는 (1) 스코어가 당신의 예측 확률이므로 그 봇들과 유사한 유저의 추천에만 우선적으로 영향을 주며 (2) Home Timeline에 서빙된 포스트에서 이뤄진 액션만 랭킹 신호로 반영되므로, 그룹채팅으로 링크 공유해 나타난 반응은 랭킹에 영향이 없다.

같은 주석 블록이 home-mixer/scorers/ranking_scorer.rs:415-446에도 중복 배치됐고, README #scoring-and-ranking 절에도 문단이 삽입됐다. 세 곳에 같은 서술을 배치해서 코드/문서 어디를 읽더라도 오해를 피하게 했다.

새로 알게 된 것 — 브라질 2026 선거 필터

X 공지가 근거를 설명한다 [확인] — README.md #august-14th-2026:

"As announced by X, in accordance with Brazilian electoral law, For You now runs Brazil2026ElectionFilter, which removes posts from accounts reported to Brazil's Electoral Court for the 2026 election, unless the viewer explicitly follows the account. A benefit of open-source is that you can see that changes like this exist, and exactly how they work — take a look at the code." — README.md, 공지 링크 @XBR

필터 본체 home-mixer/filters/brazil_2026_election_filter.rs는 1,573줄로, 그중 대부분이 계정 ID 상수 + 주석 username이다. 핵심 로직은 10줄 남짓:

static BRAZIL_2026_ELECTION_USER_IDS: LazyLock<FxHashSet<u64>> = ...;  // 665개

impl Brazil2026ElectionFilter {
    fn is_excluded_author(user_id: u64, followed_user_ids: &FxHashSet<u64>) -> bool {
        BRAZIL_2026_ELECTION_USER_IDS.contains(&user_id) && !followed_user_ids.contains(&user_id)
    }
    fn should_remove(candidate: &PostCandidate, followed_user_ids: &FxHashSet<u64>) -> bool {
        let is_excluded = |user_id: u64| Self::is_excluded_author(user_id, followed_user_ids);
        if is_excluded(candidate.author_id) { return true; }
        if candidate.retweeted_user_id.is_some_and(is_excluded) { return true; }
        if candidate.quoted_user_id.is_some_and(is_excluded) { return true; }
        candidate.ancestor_users.iter().copied().any(is_excluded)
    }
}

즉 (a) 후보의 작성자, (b) 리트윗 원저자, (c) 인용 원저자, (d) 답글 스레드의 조상 작성자 넷 중 하나라도 리스트에 있고 뷰어가 팔로우하지 않으면 드롭. 팔로우 예외는 유저 개인 그래프 기반이라 정치적 스펙트럼과 관계없이 대칭적이다.

파일 헤더 주석이 근거를 밝힌다 [확인]:

"Application providers that use a recommendation system for users must exclude from the results the channels and profiles reported to the Electoral Court under the terms of § 1º of this article and, except in cases of paid boosting, the content posted on them." — home-mixer/filters/brazil_2026_election_filter.rs:9-11

그리고 리스트의 근거 데이터셋 [확인]:

"https://dadosabertos.tse.jus.br/dataset/candidatos-2026"

배선 지점은 phoenix_candidate_pipeline.rs:356-368 — AuthorSocialgraphFilter 직후, VideoFilter 직전. 즉 사회그래프 필터가 뮤트·차단을 처리한 뒤 곧바로 이 관할권 필터가 붙는 흐름이다.

리스트에는 다양한 정당 소속 인물이 포함돼 있다. 몇 개만 코드에서 발췌:

• 40053694 // @FlavioBolsonaro (Flavio Bolsonaro, 자유당 상원의원)
• 21069302 // @marcelvanhattem (Marcel van Hattem, 신자유당 하원의원)
• 48298703 // @eduardopaes (Eduardo Paes, 사회민주당, 리우데자네이루 시장)
• 25858078 // @ManuelaDavila (Manuela D'Avila, 공산당)
• 33374761 // @cirogomes (Ciro Gomes, 민주노동당)

코드 상단에 이례적인 주석이 있다 [확인]:

"OmarAzizSenador deleted his account at the time this code was written." — home-mixer/filters/brazil_2026_election_filter.rs:15

즉 TSE 리스트에 있으나 X 상 계정이 삭제된 인물은 예외적으로 명시 주석으로 남기는 정도의 세밀함까지 문서화한 것.

의미 (관할권 필터 코드 공개의 관전 포인트)

이 필터의 정본 위치는 services/x.md 필터 21개 절에 4세대+1 신규 1개로 반영. 향후 3가지가 관전 포인트다:

1. 선거 사이클이 지나면 필터가 어떻게 정리되는가. 브라질 2026 선거는 특정 시점 이벤트이므로 이 필터는 시한부다. X가 필터를 (a) 제거하는지 (b) 상수만 비우고 남기는지 (c) 별도 아카이브로 남기는지가 open-source 관행의 지속성을 판단할 지표.
2. 다른 국가 선거·규제 대응이 같은 관행으로 붙는가. EU 의회 선거·인도 총선·미국 대선 등에 유사 필터가 코드로 나타나는지가 다음 6개월의 관전 포인트.
3. docs/BIDIRECTIONAL_BOOST_CHANGE.md가 예고한 diff 문서화 관행과의 연동. 어제 다룬 그 문서가 향후 파라미터 변경을 code diff로 문서화하는 견본이었는데, Brazil 필터의 665개 계정 리스트 변경(추가/삭제)이 미래 커밋에서 어떻게 문서화될지도 이 관행의 성숙도를 보여줄 지표.

새로 알게 된 것 — 콜드스타트 Thompson sampling

author_cold_start.rs가 갱신됐다 [확인] — home-mixer/scorers/author_cold_start.rs:151-190. 콜드스타트 대상 후보 집합 안에서 "슬롯을 어느 후보로 채울지" 선택이 greedy max-score와 Beta reward Thompson sampling 두 갈래로 분기 (Thompson sampling — 후보별로 Bayesian posterior에서 한 번 샘플해서 그 값으로 선택; exploration을 확률적으로 유도하는 표준 밴딧 기법).

새 파라미터 6개 [확인] — home-mixer/params/param.rs:687-724:

• EnableColdStartThompsonSampling = false — 기본 off. 즉 실 프로덕션은 여전히 greedy
• ColdStartBetaAlpha0 = 0.75 — Beta(α₀, β₀) 사전분포의 α (likes 사전관측치)
• ColdStartBetaBeta0 = 49.25 — β₀ (non-like 사전관측치). α₀ + β₀ = 50이 "사전 유효표본 크기". 대략 "50 impression 중 0.75 like"라는 사전
• ColdStartTsTopK = 5 — Beta 샘플링으로 상위 K를 뽑은 뒤 실제 스코어로 tie-break
• ColdStartImpressionScale = 1.0 — view_count 스케일
• ColdStartTrackedIds = "" — 콤마 분리 계정/포스트 ID 리스트, 서빙 통계 계측 대상

샘플링 규칙 [확인] — 같은 파일:

fn sample_reward<R: Rng + ?Sized>(candidate: &PostCandidate, alpha0: f64, beta0: f64, scale: f64, rng: &mut R) -> f64 {
    let n = scale * candidate.view_count.unwrap_or(0) as f64;
    let x = (candidate.fav_count.unwrap_or(0).max(0) as f64).min(n);
    let alpha = alpha0 + x;
    let beta = beta0 + (n - x).max(0.0);
    Beta::new(alpha, beta).map(|d| d.sample(rng)).unwrap_or(0.5)
}

즉 각 후보 i에 대해 posterior Beta(α₀ + likes, β₀ + max(views − likes, 0))에서 한 번 샘플 → 상위 K를 골라 그 안에서 원래 스코어 최대치 선택.

의미 (Thompson sampling A/B 배선)

기본 off라는 사실이 중요하다. 이 릴리즈 시점에서 실제 유저에게 노출되는 콜드스타트는 여전히 max-score greedy다. Thompson sampling은 A/B 인프라만 배선된 상태이며, 실 반영은 향후 A/B 결과에 따라 결정될 것.

ColdStartTrackedIds는 특정 계정/포스트 ID를 등록해두면 home_mixer.cold_start_tracked_ids_total{id, source} 카운터가 그 계정이 콜드스타트 파이프라인의 어느 소스에서 몇 번 등장했는지 추적한다 — 즉 특정 계정을 A/B에서 손으로 관찰 가능한 개별 관찰 훅. 예를 들어 정치인 계정 하나를 등록해두면 그 계정 포스트가 어느 콜드스타트 라우팅으로 몇 번 노출됐는지 셀 수 있다는 뜻. 이 계측 훅의 존재는 4세대의 under-the-hood 투명성 라인과 결이 통한다 (계정 단위 라벨 조회) — 다만 이건 X 내부용 계측이지 외부 공개는 아님.

새로 알게 된 것 — Phoenix bool feature 3개 신설

3세대~4세대 초 코드에서 bool_features는 vec![false; ...]로 통째 stamp돼 있어 입력 자체가 실효 없었다 (canon 함정 목록의 "죽은 필드" 계열). 4세대+1에서 세 개가 처음 채워졌다 [확인] — phoenix/crates/common/xai-recsys/src/util.rs:456-540, 728-900, phoenix/crates/common/xai-recsys/src/model_config.rs:40:

핵심은 코드 diff에서 vec![false; candidate_seq_len * n_post_bool] → candidate_bool_features 교체 지점 두 곳. 후보 시퀀스와 이력 시퀀스 양쪽에 같이 적용됐다.

stale post 처리의 두 신호가 짝지어 들어간다 [확인]:

let creation_valid = candidate_post_creation_ts_sec[j] > 0;
let original_age_sec = now_sec as i64 - candidate_post_creation_ts_sec[j] as i64;
let is_stale = stale_post_enabled && creation_valid && original_age_sec > STALE_POST_14D_TTL_SEC;
candidate_is_stale_post[j] = is_stale;
if is_stale {
    stamp_engagement_counts(..., 0, 0, 0, 0, 0);
} else {
    stamp_engagement_counts(..., candidate.fav_count, candidate.reply_count, ...);
}

즉 stale이면 count zero + bool set, stale이 아니면 실제 count. 랭커 입장에서 "count=0 + is_stale=true"인 후보와 "count=0 + is_stale=false"인 후보를 명시적으로 다른 케이스로 학습할 수 있다.

의미 (snowball 완화 + bidirectional 신호의 모델화)

canon이 3세대에서 관찰해온 "오래된 포스트의 낮은 카운트가 낮은 랭킹을 낳고 그것이 다시 낮은 카운트를 낳는 자기강화 루프" 문제를 랭커가 학습으로 우회하게 하는 설계 [추정] — X 스스로는 이 설계 목적을 문서화하지 않았지만 count zeroing과 bool set을 짝지은 구조가 그 방향을 강력히 시사한다. 4세대에서 인용된 is_mutual_follow 부스트(reply +15)는 스코어러의 하드코딩된 조건이었는데, 이제 모델이 팔로우 방향을 개별 입력 bool로 받아 학습으로 유사한 패턴을 잡을 수 있게 됐다는 점도 중요. 하드코딩 부스트에서 학습 신호로의 이행은 3세대 → 4세대의 전반적 방향(수작업 게이팅에서 모델 학습으로 무게 이동)과 결이 맞는다.

새로 알게 된 것 — BDSM enforcement note 생성기 부분 공개

3세대~4세대 초 bdsm/runtime/score_results_sink_focal.py:78의 build_enforcement_note는 return None뿐인 스텁이었다. 4세대+1에서 gate 로직과 dominant-head 선택 로직이 공개됐고, 템플릿 문자열만 "<redacted>" 센티널로 남았다 [확인] — bdsm/runtime/score_results_sink_focal.py:78-128:

def build_enforcement_note(head_scores_list, action_hist_list):
    if not head_scores_list: return None
    total = sum(h["cnt"] for h in (action_hist_list or ()))
    if total < 30: return None                       # MIN_ACTIONS gate
    bot_heads = [(h["head_name"], h["score"]) for h in head_scores_list
                 if h["head_name"] != "LegitimateUser" and h["score"] > 0.5]
    if not bot_heads: return None
    bot_heads.sort(key=lambda x: x[1], reverse=True)
    dominant_name, dominant_score = bot_heads[0]
    note = _ENFORCEMENT_TEMPLATES.get(dominant_name, _REDACTED_TEMPLATE)
    note += f" [model: {dominant_name}={dominant_score:.2f}"
    if len(bot_heads) > 1:
        secondary = ", ".join(f"{n}={s:.2f}" for n, s in bot_heads[1:3])
        note += f", also: {secondary}"
    note += "]"
    return note

7개 봇 헤드가 정식 노출: FollowBot, LikeBot, EngagementAmplifier, ReplySpamBot, TweetSpamBot, RTBot, MultiActionBot. 각 헤드의 템플릿 문자열은 _REDACTED_TEMPLATE = "<redacted>".

즉 최종 노트 예시: "<redacted> [model: FollowBot=0.91, also: ReplySpamBot=0.60, LikeBot=0.53]". 어떤 봇 계열에 얼마나 걸렸는지는 노트에 그대로 나가지만, 왜(어떤 액션 패턴 때문에) 라는 텍스트 설명은 미공개.

README가 이 절반 공개의 이유를 명시한다 [확인] — bdsm/README.md:

"The public package keeps the gates (MIN_ACTIONS, dominant-head pick) and the enforcement_note proto field. The template strings and the per-head key_actions interpolator are the sentinel '' — same idea as the 9.99 operating points." — bdsm/README.md

같은 원리(구조·이름·게이트는 공개, 튜닝된 실수·프롬프트 문자열은 미공개)가 sink_policy.yaml의 operating point 9.99 센티널과 짝을 이룬다. 어제 정본에 SafetyLevel 3-tier와 54 규칙을 반영했는데, 오늘 그 규칙을 참조하는 상위 계정 스코어러의 노트 생성 로직 절반이 열린 셈이다.

Proto 필드 문서화 갱신 [확인] — bdsm/proto/abuse_inference.proto:98-102:

"Optional human-readable note. In this release templates and key_actions are the sentinel '' (see README); production fills the real appeal paragraph. ActionName enums are unchanged."

의미 (labeling 파이프라인의 관찰 가능한 표층 확대)

X의 4세대+1 패턴은 "구조 공개, 프롬프트/문자열/튜닝 실수 미공개"의 일관성이 매우 높다. sink_policy의 9.99 sentinel, enforcement note의 <redacted> template, botmaker-rules의 일부 게이밍 방지 미공개가 모두 같은 원리로 배치됐다. 즉 게이밍 저항성을 유지하면서 구조·이름·게이트·헤드 조합의 검증 가능성은 최대화하는 방향. abuse-enforcement-service가 이 노트를 받아 실제 조치(label/challenge/suspension)를 판단하는 흐름의 인풋 표층이 오늘 절반 열렸다.

• grox 답글 스팸 임계 상향 [확인] — grox/flows/reply_spam/task_filter.py:17, 185: TaskSpamFilter.FOLLOWER_COUNT_THRESHOLD_FOR_SPAM_DETECTION과 TaskReplyRankingFilter.FOLLOWER_COUNT_THRESHOLD_FOR_REPLY_RANKING을 15,000 → 30,000으로 두 배 상향. 팔로워 30k 미만인 계정의 답글에만 grok으로 스팸/답글 랭킹을 채점한다는 뜻으로, 임계를 올려 grok 리소스를 태우는 답글 범위를 두 배로 확대. 리소스 배분 조정.
• phoenix-rankall에 video_14day SID window 신설 [확인] — phoenix-rankall/src/config/mod.rs:177-180: 기존 video_48h·video_96h·nsfw_video_48h/168h/14day에 video_14day가 짝지어 추가. Phoenix retrieval의 SID 기반 인기도 시그널에 2주 시간창 비디오가 포함된다는 뜻.
• abuse-enforcement-service 목 픽스처 1줄 수정 [확인] — 룰 필드값 하나 변경, 실 로직 영향 없음.

• "한 줄 요약" 절: 4세대+1 후속 드랍 요약 추가, 필터 총 20→21로 갱신
• "공개 소스 4세대" 세대 테이블: 4세대+1 행 신설 (커밋 c65aa17, +2,271/−32)
• "가중치 — 4세대 드랍으로 값이 공개됐다" 절: 해석 규칙 (raw-count 오해 방지) 인용 삽입
• "필터 21개" 절 (헤딩 개정, 이전 "필터 20개"): Brazil2026ElectionFilter 신규 항목 및 배선 위치 명시
• "콜드스타트" 절: Thompson sampling 6개 param 및 샘플링 규칙 신설
• "Phoenix 학습·인덱스" 절: bool feature 3개 신설 및 stale post count zeroing 로직
• "Grox (LLM 주석) — 3세대 그대로" 헤딩을 "+ 2026-08-14 임계 상향"으로 변경, 임계 조정 신설
• "BDSM (계정 행동 시퀀스 부정 계정 탐지) — 4세대+1에서 enforcement note 생성 로직 부분 공개" 새 절 신설
• 열린 질문 절: "4세대+1 드랍으로 해소된 것 (2026-08-16)" 하위절 신설, 5개 항목
• 출처: 5건 추가 (c65aa17 커밋, README #latest-updates, Brazil 필터, TSE 데이터셋, @XBR 공지, BDSM sink)

assets/x-pipeline.svg — 필터 라벨 "17 → 18", 신규 라벨 "4 → 5 (Brazil2026 포함)".

의미 (4세대의 성격을 하루 만에 다섯 방향으로 확장)

4세대 드랍의 성격이 하루 뒤에 곧바로 확장됐다. 어제 관찰한 "코드 diff로 파라미터 변경을 문서화하는 관행"이 오늘 처음 실제로 작동한 것 — README #latest-updates가 이제 날짜별 하위섹션 구조를 가지며 (8월 14일 → 8월 13일 역시간순), 각 하위섹션이 (1) 변경 요약 (2) 관련 파일 링크 (3) 근거 문서·공지 링크 세 요소를 갖춘다. 향후 X 커밋 로그를 매일 추적하는 것의 가치가 확실히 커지는 방향이다. 다음 커밋에서 어떤 param이 바뀌면 그 자체가 A/B 결과의 지연 지표가 되고, 어떤 필터가 새로 붙거나 사라지면 규제 대응의 실시간 관찰 지표가 된다.

심층 분석 필요 항목 (오늘 처리하지 않음):

• Thompson sampling의 A/B가 언제 실 활성화되고 결과 지표가 어떻게 나오는지 (레이더성 지속 관찰)
• 브라질 선거 필터의 665개 계정 리스트 갱신 이력 (커밋 히스토리 별도 tracking)
• BDSM _ENFORCEMENT_TEMPLATES에 다른 봇 헤드(FollowBot 등 7개 이외)가 추후 추가되는지
• Phoenix bool feature slot 나머지가 언제 채워지는지

2. arXiv triage — DrEM 소속 확정 (Kuaishou)

어제 radar.md에서 이 논문을 소속 미확정 상태([추정] Kuaishou 계열 통계적 가능성)로 등록했다. 오늘 arXiv HTML 판을 열어 저자 affiliation 표기를 확인한 결과 Kuaishou 이메일 도메인이 5명 확인돼 이 회사의 프로덕션 논문임이 확정됐다.

Kuaishou는 이번 달에 이미 두 편의 프로덕션 논문을 냈다 (HD-Rec 2026-08-11 radar.md, PushDualGen 2026-08-12). 이번이 세 편째이며, 세 편이 모두 다른 알고리즘 계열(SID cross-domain / SID+CoT 푸시 / ensemble ranking noise robustness)이라는 점이 특징이다. 회사 차원에서 여러 팀·라인이 동시에 프로덕션 SOTA 논문을 낼 수 있는 리소스가 확인된 셈이다.

논문은 ensemble ranking stage의 특유한 문제를 다룬다. 산업 비디오 추천 파이프라인의 다단계 구조에서, 상위의 멀티태스크 모델(멀티태스크 랭커; 여기서 pctr·pvtr·pcmtr·pftr 등 여러 태스크의 예측 확률을 pxtr로 통칭)이 출력한 예측을 하위의 앙상블 랭커가 입력 피처로도, proxy preference 라벨의 소스로도 함께 쓰는 상황을 상정한다. 그런데 pxtr는 상위 모델의 출력이므로 노이즈를 포함할 수밖에 없고, 이 노이즈가 (a) proxy preference 라벨을 뒤집고 (supervision-side 노이즈) (b) feature-side 입력으로 유입돼 순위 스코어를 흔든다 (feature-side 노이즈).

기존 앙상블 랭킹 방법들은 pxtr를 신뢰 가능한 신호로 간주하고 노이즈를 무시했지만, DrEM은 이 노이즈를 양쪽에서 동시에 보정한다:

• Supervision side (라벨 노이즈): pairwise flip probability(어떤 쌍의 진짜 preference가 뒤집혔을 확률)를 추정하고, empirical risk를 그 확률로 정정하는 risk-denoising robust loss를 도입. 이론적으로 flip probability 추정 오차가 있더라도 basic pairwise loss보다 우월함을 증명 (Theorem 1).
• Feature side (입력 노이즈): pxtr의 예측 노이즈 분포에서 perturbation을 샘플링하고, preference-preserving ranking consistency regularizer로 perturbation에 대한 출력 안정성을 학습.

핵심은 두 correction이 공유 노이즈 모델에서 유도된다는 것 — supervision과 feature 양쪽의 correction target이 같은 노이즈 근원에 정렬되므로 파라미터를 공유해 동기화된 보정이 가능하다.

HTML 판 5.4 절 (RQ3)이 A/B 세팅을 명시 [확인]:

"To answer RQ3 and validate real-world performance, we conduct online A/B tests on the industrial short-video platform. We set up two parallel experiment groups to verify the generalization of our DrEM on both representative backbones, applying our DrEM on top of production-grade EMER and EASQ backbone. The experiment runs for 7 days with 5.1% of the main traffic randomly split at the user level via hash-based assignment to each group." — arXiv 2608.12778, 5.4절

메인 A/B 결과 [확인] — 5.4절 Table 2, 모든 p < 0.005:

저자 관찰 (동일 절, 요약): sparse behavior가 dense behavior보다 gain이 크다. 팔로우(+1.20%)·댓글(+1.39%)이 뷰(+0.69%)·롱뷰(+0.40%)보다 압도적으로 크다. 이론과 일치 — 스파스 태스크(pcmtr, pftr)의 pxtr는 예측 분산이 크므로 flip probability도 크고, robust correction의 여지도 크다. 5.5절 (RQ4)의 flip-probability 스트라티피케이션 heatmap도 같은 결론을 시각화 — 낮은 flip prob 구간에서는 dense 태스크(pctr, pvtr)의 개선이 0 또는 살짝 음수인데, 높은 flip prob 구간에서는 급격히 양수로 상승.

두 백본의 gain 격차 해석: EASQ가 EMER보다 gain이 작은 이유는 EASQ가 이미 자체 questionnaire-signal alignment로 supervision-side 노이즈를 부분 완화하고 있어 DrEM의 supervision correction 여지가 적기 때문이라고 저자가 명시. 즉 supervision 정정이 훨씬 실속 있는 개선을 낳고, 이미 그 부분을 다룬 백본에서는 feature-side 정정만 남는다는 계층적 이해.

Kuaishou가 이번 달 세 편의 프로덕션 논문 중 이 논문이 canon과 가장 밀접하다. 다른 어느 서비스도 이런 노이즈 이슈를 겪는다 — X의 26개 헤드 가중합, Meta의 다목적 랭킹, Netflix의 멀티태스크 FM 모두 상위 pxtr가 하위 스코어러의 입력이자 라벨이 되는 구조를 갖는다. 다만 DrEM이 다루는 특정 문제(앙상블 랭킹 단계의 pxtr 노이즈)가 X·Meta·Netflix에서 별도 컴포넌트로 존재하는지, 다른 방식으로 완화되고 있는지는 문헌으로 확인이 안 된다. 두 번째 회사의 유사 진술이 나오면 topics/multi-task-ranking.md에 절 신설 후보.

다음에 볼 것

• c65aa17 후속 커밋 — X의 하루 단위 커밋 리듬이 확립됐다면 매일 배치가 계속 통과분을 뽑아낼 것. Thompson sampling A/B 결과, 브라질 필터 계정 리스트 diff, Phoenix bool feature 채움 진행이 우선 관찰 대상.
• Kuaishou 라인 지속 관찰 — 이번 달 세 편이 각기 다른 알고리즘 계열이라 회사 차원 리소스가 늘어난 신호. 8월 나머지 arXiv triage에서 Kuaishou 라인 통과분이 더 나올 가능성.
• 관할권 필터의 두 번째 사례 — 다른 국가 선거·규제 대응이 같은 open-source 관행으로 붙는지 다음 6개월 관전.