2026-08-26

1. X 4세대+7 드랍 — VF 레퍼런스 비교 하니스 + BrandSafetyVerdict HighRisk + PTOS 심판 3카테고리 확장

이 드랍의 세 축은 VF 서브레포(visibility-filtering, 4세대 헤드라인의 하나로 통째로 공개된 안전 필터 스택), home-mixer의 브랜드 안전 판정(광고 인접성 게이팅), grox의 PTOS 파이프라인(Grok LLM 기반 policy-to-safety 재분류)이다. 각각이 서로 다른 방향으로 성숙 중인데 이번 커밋에서 세 축이 나란히 진화했다.

1-1. visibility-filtering/reference_compare.rs (812줄 신규) — dark_traffic 위에 얹힌 실측 canary

VF는 4세대 헤드라인 드랍에서 처음으로 소스가 통째로 공개된 서브레포다. 이전 세대(1·2세대 Scala)의 VF와 병존하며 재작성이 진행 중인데, 재작성은 canon 함정 #1: fail-closed 때문에 정책 변경 리스크가 큰 서브레포다(판정 없는 모든 결과가 drop으로 처리됨). 이 리스크에 대응하는 인프라가 세 단계로 배선됐다:

• 4세대+4 (aad7179, 2026-08-19): dark_traffic_setup.rs(109줄 신규)가 프로덕션 트래픽 요청을 xai-vf-shadow.prod.visibility로 병렬 미러링. 트래픽 자원 소비만.
• 4세대+6 (28e414f, 2026-08-21): dark_traffic 타깃이 xai-vf-service.staging.visibility:grpc로 리네이밍 — shadow prod가 아니라 staging 배포를 프로덕션 트래픽으로 검증.
• 4세대+7 (d011592, 2026-08-24): reference_compare.rs(812줄 신규)가 staging 배포 안에서 요청마다 Strato 기반 레퍼런스 VF(StratoVfClient)에 병렬 호출 → verdict 엄격 비교 → 다른 결과만 JSON 라인으로 로깅. 즉 dark_traffic이 흘려보낸 프로덕션 트래픽이 staging VF에 도착하면 자기 verdict를 계산하면서 동시에 이전 세대(Strato-backed) 레퍼런스를 대조.

begin_compare(viewer_id, country_code, safety_level, tweet_ids)가 별도 tokio task를 spawn — main path는 자기 verdict를 oneshot::channel로 harness task에 흘려보내고 응답에는 영향 없음(read-only). Timeout 1.5초. is_exact_match(&VfAction, &Option<FilteredReason>)은 정규화 없이 엄격 비교(action 라벨 + FilteredReason 완전 일치)한다.

diff 로깅 포맷 — 같은 (service_verdict, reference_verdict) 조합끼리 tweet_id를 그룹화 → 12KiB 라인 예산으로 청킹 → println!("{line}")으로 stdout에 흘림. 각 라인은:

{"h":"vf_reference_compare","v":1,"batch":"...","chunk":[1,1],"build":"<12자 SHA>","dc":"atla","level":"TimelineHome","viewer":<u64>,"diffs":[["drop:AuthorIsSuspended","allow",[123, 456]], ...]}

메트릭 6종은 xai_stats_receiver::global_stats_receiver()로 노출: vf_reference_compared, _exact_match, _differed, _error(kind=timeout|reference_item|missing_result), _skipped(reason=level_unmapped|logged_out_viewer), _enabled. 모든 메트릭에 build_sha 라벨 부착 — 특정 빌드에서 diff율이 튀면 어느 배포가 원인인지 즉시 추적 가능.

Staging 강제:

pub(crate) fn should_build_harness(
    flag_enabled: bool,
    app_env: Option<&str>,
) -> Result<bool, &'static str> {
    match (flag_enabled, app_env) {
        (false, _) => Ok(false),
        (true, Some("prod")) => Err(
            "VF_DUAL_CALL_HARNESS_ENABLED is set but APP_ENV=prod; the reference comparator is staging-only",
        ),
        (true, _) => Ok(true),
    }
}

그리고 server_deps.rs의 build_reference_compare_harness()가 이 Err를 panic!()으로 승격 → 부팅 실패. 즉 코드 레벨에서 staging 전용을 강제 — production에서 dual-call이 무리로 켜지는 사고 방지.

"the reference comparator is staging-only" — reference_compare.rs:31-33

• VF 검증 스택 3단 완성 [확인] — dark_traffic(트래픽만) → dark_traffic 타깃이 staging(프로덕션 트래픽으로 staging 검증) → reference_compare(staging 안에서 verdict 대조). 정책 변경 리스크가 큰 fail-closed 안전 서브레포에 대해 프로덕션 트래픽 규모로 회귀 감사 가능해짐. VF 배선 리스크가 크게 감소.
• StratoVfClient = 레퍼런스 VF의 정체 [추정] — Strato는 X의 실시간 스토리지/서비스 조회 레이어. StratoVfClient가 감싸는 실제 VF 스택이 1·2세대 Scala VF의 잔재인지, 별도의 참조 구현인지는 명시적으로 코드에 없음. client_id = "visibility-filtering-service.{APP_ENV}" 형식으로 identify하는 것을 보면 별도 인스턴스가 돌고 있는 것으로 보임 [추정].
• diff 그룹화 최적화 [확인] — 같은 (service, reference) 조합끼리 tweet_id를 묶어 로그 라인 하나에 담고, 12KiB 예산을 넘으면 균등 분할. 즉 로그 라인 개수가 diff 조합 수에 비례하지 tweet_id 개수에 비례하지 않음 — 다수의 tweet이 같은 방식으로 divergent해도 로그 폭발 방지.

1. 4세대 표에 +7 행 추가 — 파일 목록·+1,428/−121·핵심 8건 요약
2. 한 줄 요약 문단 확장 — 여덟 번째 후속 드랍 서술 추가
3. 안전성 절에 새 subsection "4세대+7 (2026-08-24) — VF 레퍼런스 비교 하니스 (reference_compare.rs) 배선" — 동작·게이팅·의미 상세

1-2. home-mixer/models/brand_safety.rs — BrandSafetyVerdict::HighRisk = 4 tier 신설

브랜드 안전 판정이 3단계(Safe/LowRisk/MediumRisk) → 4단계(+ HighRisk)로 확장됐다. 이전엔 medium risk 뭉치에 있던 라벨 5종이 승격됐고 새 라벨 1종이 추가됐다.

HighRisk로 승격/신설된 6종 [확인]:

pub(crate) const HIGH_RISK_LABELS: &[SafetyLabelType] = &[
    SafetyLabelType::NSFW_HIGH_PRECISION,           // medium에서 승격
    SafetyLabelType::NSFW_HIGH_RECALL,              // medium에서 승격
    SafetyLabelType::GORE_AND_VIOLENCE_HIGH_PRECISION, // medium에서 승격
    SafetyLabelType::PDNA,                          // medium에서 승격 (Photo DNA — 아동 성착취 이미지 해시)
    SafetyLabelType::EGREGIOUS_NSFW,                // medium에서 승격
    SafetyLabelType::SOFT_NSFW,                     // 신규
];

compute_verdict()와 compute_verdict_v2() 둘 다 HighRisk 체크를 캐스케이드 최상단으로 이동. worst_verdict()의 >= 비교가 자동 확장돼 HighRisk가 이제 최상위.

광고 유틸 has_avoid() 확장:

pub(crate) fn has_avoid(post: &ScoredPost) -> bool {
    matches!(
        post.brand_safety_verdict(),
        BrandSafetyVerdict::MediumRisk | BrandSafetyVerdict::HighRisk
    )
}

이전엔 MediumRisk만이었다 — 이제 High도 avoid 대상. 인용 인접성 escalation도 승격: ads_brand_safety_vf_hydrator.rs에서 NSFW author인 조상 포스트를 인용한 경우 verdict를 MediumRisk → HighRisk로 escalate. 즉 인접성 판정에서 High가 Medium과 동일한 회피 대상이지만 (아직은) 추가 조치가 명시적으로 다르지 않다 — 강도는 실험 흐름·다운스트림 추적 목적으로 보인다.

V2 라벨 5종의 proto 노출 시작 [확인] — scored_posts_server.rs의 safety_label_to_proto mapping에 다섯 개 신설: GROK_SFA_V2 → HM::GrokSfaV2, GROK_NSFA_LIMITED_V2 → HM::GrokNsfaLimitedV2, GROK_NSFA_V2 → HM::GrokNsfaV2, GROK_NSFA_EXPANDED_V2 → HM::GrokNsfaExpandedV2, PTOS_REVIEWED → HM::PtosReviewed. 이전엔 V2 라벨이 home-mixer 내부 판정에만 쓰이고 다운스트림 소비자(feed 응답을 받는 다른 서비스·클라이언트)에겐 감춰져 있었는데, 이제 실제로 실려 나감.

DDG experiment 트래킹 [확인]:

ddg_experiment_bucket: query
    .params
    .experiment_buckets(EnableAdsBrandSafetyVerdictV2)
    .first()
    .map(|b| format!("{}:{}", b.experiment, b.bucket))
    .unwrap_or_default(),

ads_injection_logging_side_effect.rs가 EnableAdsBrandSafetyVerdictV2 experiment의 버킷을 로깅에 노출. DDG는 X의 광고 리포팅 파이프라인으로 추정 [추정] (Data Dashboard / Data 유사 시스템). V2 실험군의 매출/안전 metric을 관측 가능하게 함. V2 판정 로직이 experiment 단계라는 방증. 4세대+2(도입) → +3(재설계) → +7(experiment 실측 인프라 완비)의 8일 여정 완결.

"MEDIUM_RISK_LABELS_V2에서 위 5종 제거" — home-mixer/models/brand_safety.rs

1-3. grox/flows/ptos/classifier.py — SafetyPtosPolicyCrossValidator 신설, Grok 4.5가 X_ALGO 엔드포인트로 재도입

PTOS(Policy-to-Safety) 심판 계층이 성인 컨텐츠 하나에서 세 카테고리(ChildSafety, ViolentMedia, IllegalAndRegulatedBehaviors)로 확장됐고, 3일 전(4세대+6) 완전 제거된 Grok 4.5가 다른 엔드포인트로 심판 전용 재도입됐다.

Grok 4.5의 8일 진화:

• 4세대+2 (2026-08-17): EAPI_GROK_4_5_INTERNAL이 성인 컨텐츠 심판으로 도입 (SafetyPtosAdultContentCrossValidationJudge)
• 4세대+4 (2026-08-19): Grok 4.6 internal 10% dial 도입(shadow)
• 4세대+5 (2026-08-20): 4.6 dial 10% → 30%
• 4세대+6 (2026-08-21): 4.6 dial 30% → 100%, 4.5 internal 코드에서 완전 제거(breaker·sampler·dial 상수 모두 삭제)
• 4세대+7 (2026-08-24): EAPI_GROK_4_5_X_ALGO가 심판 전용으로 재도입 — primary가 아니라 judge

X_ALGO 접미사는 x-algorithm 도메인 튜닝 변형을 시사 [추정] — 4.5 base + x-algorithm 파인튜닝인지 완전 별개 모델인지 미공개. 회로차단기 _eapi_4_5_x_algo_breaker (window 600초·회복 600초·half-open 5회, 4.6 internal과 같은 파라미터).

SafetyPtosPolicyCrossValidator 클래스 신규:

진입점 validate(category, post, policy)가 세 카테고리를 각 전용 메서드로 라우팅. 세 카테고리 모두 강등만 허용 — cross-validator가 primary보다 엄격한 판정을 낼 수는 없고, primary가 오탐한 것을 심판이 풀어주는 방향으로만 작동. 이는 4세대+2의 성인 컨텐츠 judge와 같은 설계 철학.

• ChildSafety (_validate_child_safety): 4.5로 재확인 → policy type 일치면 유지, 불일치면 NoViolation으로 강등. 파싱 실패·에러도 NoViolation fallback. _build_policy_convo에 post creation date를 넣어 child_safety_policy_prompt(post_creation_time) 사용 — 즉 아동 안전은 시점 의존적인 요소가 있음.
• ViolentMedia (_validate_violent_media): 4.5로 재확인 → 일치면 유지, NoViolation이면 강등, type_mismatch면 ViolentMediaGraphicMedia(약한 형)로 downgrade. 강등 옵션이 3가지로 세분화.
• IllegalAndRegulatedBehaviors (_validate_illegal_and_regulated_behaviors): 4.5로 재확인 → 일치면 policy type 유지하되 reason은 4.5가 준 것으로 덮어쓰기(더 정확한 사유 설명), 불일치면 NoViolation으로 강등.

메트릭 safety_ptos.<category>_cross_model_validate_with_grok_4_5 카운터가 세 카테고리별로 outcome 태그(agreed/disagreed/unparseable/no_violation/type_mismatch/error) 부착.

USE_REASONING_CATEGORIES = {ViolentSpeech, SuicideOrSelfHarm} — 이 두 카테고리에서만 SafetyPtosPolicyClassifier.build_convo()가 _strip_thinking_restrictions를 프롬프트에 적용(reasoning 활성) + assistant 메시지를 빈 상태로 두어 모델이 자유롭게 사고. 다른 카테고리는 여전히 THINKING_CONTROL_END로 사고 억제(빠르고 저렴한 응답).

USE_THREAD_RENDERER_CATEGORIES = {ViolentSpeech, SuicideOrSelfHarm} — 이 두 카테고리에서만 (post에 ancestors가 있으면) ThreadRenderer로 부모 스레드 전체를 사용자 메시지로 렌더. 이유는 근본적: "죽고 싶어" 같은 문장은 스레드 문맥 없이 판정 불가 — 이전 발화가 게임에서 진 얘기면 무해, 자해 지원 스레드면 위중. 마찬가지로 폭력 발언도 인용/응답 맥락이 결정. 다른 카테고리(성인·NSFW 미디어·불법)는 대상 post 자체가 신호를 담아 스레드 확장 불필요.

"USE_REASONING_CATEGORIES = { ViolentSpeech, SuicideOrSelfHarm }" "USE_THREAD_RENDERER_CATEGORIES = { ViolentSpeech, SuicideOrSelfHarm }" — grox/flows/ptos/classifier.py:582-594

1-4. Phoenix 체크포인트 로더 하드닝 (xai_checkpointing/load.py, +178/−36)

Muon + GB300 세대 이후 Phoenix 학습이 지금까지의 규모를 넘으면서 restore path의 실무 이슈가 정리됐다. load_checkpoint에 새 인자 3개:

• domains: dict[str, Any] | None — per-tensor ts.IndexDomain 슬라이스. JSON 스펙 또는 인덱싱 표현식 두 형식 지원. 특정 tensor만 부분 로드하거나 로컬 shape이 체크포인트 shape과 다를 때 명시적 슬라이스.
• tag: str | None = None — 기본 "orbax-ckpt". 체크포인트 서브디렉토리 이름. 하나의 base path에 여러 tag의 체크포인트를 공존시키는 관행이 배선됨.
• concurrent_gb: float | None — 동시 디코딩되는 tensor 바이트 상한(int(concurrent_gb * 10**9)). 배치 단위로 read를 끊음 — cur_bytes + nbytes가 예산을 넘으면 배치 flush → drain → 다음 배치. None이면 스로틀 없이 병렬 issue.

노드 레벨 restore 직렬화:

_NODE_SERIALIZE_ENV = "XAI_RESTORE_NODE_SERIALIZE"
_NODE_LOCK_FILE_ENV = "XAI_RESTORE_NODE_LOCK_FILE"

class _NodeBatchLock:
    def __init__(self, path: str):
        self._fd = os.open(path, os.O_CREAT | os.O_RDWR, 0o666)

    def __enter__(self):
        t0 = time.time()
        fcntl.flock(self._fd, fcntl.LOCK_EX)
        ...

기본 락 파일 경로 /dev/shm/xai_restore_node_lock (없으면 /tmp/...). 같은 노드의 여러 JAX 워커가 동시에 restore하는 것을 막아 노드 하나가 한 번에 한 배치만 처리하도록 강제. 1초 이상 대기 시 로그. 배치 사이에 gc.collect() + ctypes.CDLL("libc.so.6").malloc_trim(0) — glibc 할당자 슬랙 반환.

1-5. 소소한 변경 3건 (grox reply_spam · X Spaces 컨텍스트)

• grox reply_spam follower 임계 80k → 100k — TaskSpamFilter·TaskReplyRankingFilter 둘 다. 11일 5단계(15k → 30k → 60k → 80k → 100k)로 계속 완화. 이 흐름 자체가 신호 — grox reply spam 검사 대상이 계속 좁혀지고 있는 것.
• grox/flows/reply_spam/strato_loader.py(49줄 신규) — ReplyRankingScoreStratoLoader가 reply ranking 점수를 Strato put + score ≤ 1.0이면 지역 캐시(Atla, Pdxa)에 병렬 팬아웃 + Kafka v2 emit. grox reply_spam 파이프라인의 오프라인 결과가 온라인 서빙 stack이 소비 가능하게 write-back 채널 완비. 스코어 임계 1.0 이상은 캐시 fanout 스킵 — 낮은 신뢰도 판정은 정본에만 남기고 서빙 캐시는 오염 방지 [추정].
• X Spaces(오디오) 컨텍스트가 grox에 유입 — SpaceMetadata 클래스 신설(현재 title 하나), Post.space_metadata 필드, post_mapper.py가 매핑, grox/core/lm/post.py renderer가 \n\nThis post has the following audio space card attached:\nAudio Space title: {title}로 LLM 프롬프트에 포함. 오디오 자체는 안 듣지만 스페이스 제목이 브랜드 안전·성인 컨텐츠 판정 재료가 됨.

2. HEGM — VK 러시아, 짧은 비디오 watch-time 분포 예측, 프로덕션 1.5개월 A/B 상세 수치 (레이더)

• EGMN의 실패 모드 3종 [확인]:

  • variance collapse — MLE 학습이 특정 컴포넌트의 σ_k(x)를 0으로 몰아 그 샘플에 likelihood spike를 만들고 분포는 무의미해짐
  • component redundancy — 여러 Gaussian이 μ_i≈μ_j, σ_i≈σ_j로 수렴해 사실상 동일 컴포넌트 복제
  • inactive components — 대부분 mixture weight가 0으로 붕괴, entropy regularizer가 있어도 발생

  이 세 실패가 대규모 재현 연구에서 반복되는 것을 발견한 게 HEGM의 출발.

• HEGM의 다섯 가지 수정 [확인]:

  • Hierarchical skip-watch decomposition — sigmoid gate가 skip 확률 예측: p_skip(x) = σ(W_skip · h + b_skip) ∈ (0, 1). 최종 밀도는 exponential × p_skip + Gaussian mixture × (1−p_skip). "quick skip = 무관심"과 "engaged viewing"을 판정 층에서 분리 — 해석 가능성 + 각각 다른 실패 모드를 다른 sub-model이 담당
  • KL 기반 variance regularization (variance collapse 대응)
  • Structured initialization
  • Forced Gaussian shift 제거
  • Entropy regularizer 제거

• 프로덕션 A/B 상세 [확인] — HTML 판 결과 절에서 매우 구체적으로 공개:

  • 지면: 짧은 비디오 (VK로 추정 [추정] — 저자가 명시하진 않지만 "serving millions of active users" + AI VK 소속으로 강한 시사)
  • 기간: 1.5개월 (1개월 forward + 2주 reverse swap)
  • 트래픽: 처리·대조군 각 5%, 일당 각 그룹 ~11M 요청
  • 결과 (모두 통계적 유의):
    • session depth +9.26%
    • deep watch (≥10s) +5.75%
    • non-short watch (≥3s) +4.59%
    • skips (<3s) −6.23%
    • shares +14.59%
    • dislikes −8.34%

"A 1.5-month production A/B test confirms statistically significant engagement lifts." — HEGM abstract, 2026-08-24

• VK가 프로덕션 진술을 하나 더 쌓았다 — 짧은 비디오 프로덕션 랭킹 논문은 최근 몇 달에 Kuaishou(DrEM, HD-Rec, PushDualGen)와 Yandex Music Gryphon-v2/Sona가 계속 나왔는데 이번에 VK가 또 다른 러시아 리서치 소스로 진술을 추가. AI VK의 프로덕션 규모(수천만 DAU 추정 [추정])와 상세 수치 공개 관행은 이후 러시아 플랫폼 연구를 트래킹할 가치를 확인.
• watch-time 예측이 두 갈래로 진화 중 — (a) Netflix Foundation Model의 watch-time head + X Phoenix의 quantile head 5분위(4세대+4 P10/P25/P50/P75/P90)는 point estimate + quantile 조합, (b) EGMN 계열은 conditional density 전체 예측(HEGM은 그 계보의 최신). 두 접근이 어떤 트레이드오프(계산 비용, 해석성, CDF 이벤트 정확도)를 갖는지가 관전 포인트. 두 번째 회사(VK 외)의 EGMN 계열 프로덕션 진술이 나오면 topics/multi-task-ranking.md에 절 후보.

3. User Behavioral Densing Law — Ant/Alipay가 유저 시퀀스 tokenization의 스케일링 법칙 정식화 (레이더)

• raw text 스케일링의 병목 — billion-scale에서 raw behavioral text 입력을 늘려도 성능이 diminishing return에 걸림. tokenization(behavior를 discrete token으로 변환)이 이를 완화하지만
• tokenization 설정이 데이터 스케일과 어떻게 함께 커야 하는가는 정량적 분석이 없었음

• densing law 수식 [확인] — 단일 차원(사용자 수 또는 시퀀스 길이 하나만 스케일):

  ln C*(s) = β + α ln(s / s_0)
  

  다차원 (사용자 수 + 시퀀스 길이 동시 스케일):

  ln C*(s) = β + Σ_i α_i ln(s_i / s_{i,0})
  

  여기서 C*는 최소 충분 tokenization capacity, s는 데이터 스케일, α는 데이터 특성·tokenization 방식에 의존하는 지수. 즉 데이터 스케일의 로그와 tokenization capacity의 로그가 대략 선형 관계 — Densing Law(arXiv 2412.04315)가 LLM에 대해 명명한 관계를 추천 도메인의 tokenization 축으로 옮긴 것.

• ALGN (Adaptive Length Group Nested) [확인] — 데이터 스케일에 따라 tokenization capacity를 적응적으로 조절하는 variable-length 방식. Densing Law가 지침. abstract에 "ALGN outperforms existing baselines" 라고만 언급, 구체 개선 수치는 abstract에 없음.

• 평가 규모 [확인] — billion-scale Alipay PayBill dataset. 3가지 downstream task: classification, text-based retrieval, user-to-user retrieval. 각 held-out test는 0.5M user 규모.

• 프로덕션 배포 진술은 없음 [확인] — offline 벤치마크만. Alipay 서빙 스택에 ALGN이 반영됐다는 진술은 abstract·HTML 어디에도 없음. "billion-scale Alipay dataset"이라는 데이터 규모 진술만 있고 A/B 결과·uplift 숫자·서빙 지연 등 프로덕션 진술 부재.

"we conduct a pilot study on raw & tokenized scaling comparison on billion-scale Alipay dataset" — Densing Law abstract, 2026-08-24

• 스케일링 법칙 스레드에 세 번째 회사가 다른 축으로 붙었다 — Meta HSTU·Wukong·GEM과 Netflix Foundation Model이 파라미터·데이터 스케일링 법칙을 진술했고, ByteDance 광고 TM20K가 시퀀스 스케일링을 KD로 뽑았는데, 이번은 tokenization capacity 스케일링 — 데이터 규모가 커질 때 얼마나 큰 tokenization 어휘·구조가 필요한지의 법칙. LLaTTE("semantic feature 필요 여부") vs HSTU("scaling만으로 됨") 미해소 논쟁의 세 번째 각도로 붙는다.
• Ant Group의 유저 시퀀스 라인 — DeepFind Team이 Ant Group의 유저 표현 학습 라인 이름으로 보임 [추정] — 이후 Ant Group의 다른 프로덕션 진술(예: 이 densing law가 Alipay 서빙 스택에 반영됐다는 후속, 또는 다른 downstream task의 A/B 결과)이 나오면 topics/sequence-transformer-ranking.md 승격 후보.
• 다만 offline만이라는 한계 — 프로덕션 A/B 진술이 없어 "실제 서빙에 얼마나 도움되는가"는 미확인. 다음 논문 또는 tech report에서 온라인 결과가 나올 때까지 관찰 등급 유지.

4. Spotify가 SID + reasoning trace의 프로덕션 라인에 첫 반박 실험을 제출했다 (레이더)

이 논문은 그 gap을 메운다 — 2×2 factorial 통제 실험으로 (a) 아이템 표현이 SID인지 자연어 title인지, (b) reasoning trace가 있는지 없는지, 두 factor를 독립적으로 변화. 공통 backbone Qwen3-1.7B, 3개 Amazon product 도메인.

• 핵심 negative result [확인]:

  "introducing explicit descriptive reasoning traces reduces traditional offline recommendation effectiveness under standard SFT and RL training" — abstract

  구체 수치 (Office Products + Titles, SFT):

  • R@10: .1587 → .1416 (약 −11% 저하 trace 추가 시)
  • 전체 domain 범위: Titles는 −19% ~ 0%, SIDs는 −9% ~ 0%

• Title이 더 좋은 trace를 만들지만 지표는 안 나옴 [확인] — SID는 opaque learned identifier이므로 LLM이 그 위에서 자연어처럼 reasoning하기 어렵고, extensive alignment(SID를 자연어와 정렬시키는 추가 학습)를 붙여야 겨우 trace가 grounded해짐. 자연어 title은 alignment 없이도 grounded·interpretable한 trace를 뽑음. 그런데 trace가 좋아도 recommendation R@10은 하락. trace quality와 recommendation effectiveness가 독립이라는 것.

• Richer reward signal이 부분 완화 [확인] — RL 학습에서 reward를 recommendation R@10 자체가 아니라 더 rich한 신호로 바꾸면 gap이 부분 축소. 하지만 여전히 no-reasoning baseline을 완전히 못 따라잡음.

• industry 참조 언급 없음 [확인] — 관련 연구 절에 SIDReasoner류는 등장하지만 Kuaishou PushDualGen이나 그 유사 프로덕션 배포에 대한 명시적 인용은 없음. 논문의 논조가 "이 흐름이 옳은가"를 묻는 것이 아니라 자체 controlled 실험으로 조건부 관찰을 정리하는 방식.

"R@10 drops from .1587 to .1416" — Office Products domain, Titles condition Section: Results, arXiv 2608.23154 HTML

• negative result의 조건부 유효성이 중요 — 두 자료의 조건이 다르다:
  • Kuaishou PushDualGen: push 지면 · 프로덕션 A/B · 실 카탈로그 · reward 설계는 프로덕션 목적(effective play, 불만족률)
  • Spotify: offline · Amazon reviews · Qwen3-1.7B backbone · reward 설계는 standard R@10 즉 두 결과는 직접 모순이 아니라 다른 조건에서의 다른 관찰. 하지만 재현 가능한 반박점이 하나 생겼다는 게 중요 — 이후 SID+CoT 프로덕션 진술이 나올 때 이 조건들(backbone 크기, offline vs online, reward 설계)이 관건이 됨.
• Spotify가 SID+CoT 라인을 프로덕션 배포하지 않는 이유 — Spotify는 이미 SID(semantic tokenization) 라인에 진지하게 진출한 회사(PRS 2025 semantic tokenization 발표 참조). 그런데 자체 실험이 negative를 보였다면 그 결과가 회사의 프로덕션 로드맵에 반영됐을 가능성 [추정] — 즉 Spotify 프로덕션은 SID는 채택하되 CoT는 안 붙일 것이라는 예측.
• 관전 포인트 — 두 번째 회사의 유사 실험 진술이 나오면 topics/llm-in-recsys.md에 별도 절(SID + reasoning trace: production vs benchmark 논쟁) 후보.

검증에서 뒤집힌 것

없음 — 이번 배치의 세 신규 자료(HEGM, Densing Law, Spotify SID+CoT)는 기존 정본을 뒤집지 않고 각 관찰 스레드(watch-time 예측, 스케일링 법칙, LLM-in-recsys)에 새 데이터 포인트로 붙는다. X 4세대+7은 4세대 시리즈의 자연스러운 연장.

레이더

• 신규 3건:
  • HEGM (VK, arXiv 2608.23356)
  • User Behavioral Densing Law (Ant/Alipay, arXiv 2608.23392)
  • Spotify SID+CoT negative result (arXiv 2608.23154)

다음에 볼 것

• X 4세대+8 (다음 커밋) — 지금까지 12일 연속(4세대 원본 08-13부터) 커밋 흐름. 관전 포인트: (a) VF reference_compare가 로깅에서 대시보드/알람으로 승격되는 시점, (b) BrandSafetyVerdict::HighRisk가 광고 avoid 외의 후속 조치(랭커 감쇠·유기 노출 차단)를 트리거하는지, (c) PTOS 심판이 스팸·혐오 발화 카테고리로 확장되는지, (d) V2 experiment의 승격/롤백 결정, (e) grox reply_spam follower 임계 다음 조정(100k → 120k? 150k?).
• VK HEGM 후속 — 오픈소스 코드가 있으므로 재현 실험이 다른 회사에서 나올 가능성. 특히 짧은 비디오 프로덕션 라인의 다음 회사(TikTok/ByteDance, Reels, Meta) 진술.
• Ant/Alipay densing law의 서빙 반영 후속 — 프로덕션 A/B 진술이 나오면 정본 승격.
• Spotify SID+CoT의 정본 반영 여부 — 두 번째 회사의 유사 실험이 필요. Netflix/Meta/Google 중 하나가 controlled 반박 실험을 내놓으면 topics/llm-in-recsys.md에 절 신설.
• 월요일(2026-08-31) 산업 블로그 스윕 — Pinterest engineering(medium.com/pinterest-engineering), research.atspotify.com, Google Research blog.