2026-08-30

1. X 4세대+11 — visibility-filtering 규칙 계층 리팩터 + Phoenix RerankerHeadTag wiring + emb_table gRPC 콜백을 blocking pool로 분리

VF 서브레포는 4세대 초기(2026-08-13)에 Rust로 재작성된 이후 8월 내내 안전망을 걷어내고 회귀 방어 자산을 안으로 축적하는 흐름이 이어져 왔다. 4세대+4에서 xai-vf-shadow 미러링 배선, 4세대+7에서 reference_compare.rs 하니스 배선, 4세대+9에서 TesHydrator의 media fallback cache 통째 제거가 있었다. 이번 4세대+11은 그 다음 단계로 개별 rule 파일의 표현을 얇게 만들고 회귀 코퍼스를 안에 심는 리팩터다. Policies에 배선된 규칙이 코퍼스에 최소 한 건의 결정자 케이스를 가지도록 CI에서 강제하는 어설션이 함께 붙었다.

Phoenix 쪽 두 변경은 별도 문맥이다. RerankerHeadTag는 home-mixer 파라미터(기본 0)로 시작해서 두 개의 recsys.proto(Rust·Python) 필드로 나가고, 다시 스코어링 응답으로 라운드트립하는 wiring이다. 서버가 이 태그를 실제로 어떻게 소비하는지(헤드 라우팅 로직)는 이 커밋에 없다. emb_table의 gRPC 콜백 변경은 4세대+9의 load_tensor_into core 분리, 4세대+10의 copy_port shuffle과 같은 흐름으로, 대용량 임베딩 테이블 서빙 인프라가 tokio 런타임과 CPU-바운드 작업의 경계를 계속 다듬는 과정이다.

• RuleContext가 도메인 메서드 25여 개를 노출하는 파일로 분리됐다 [확인] — 이전에 각 rule 파일이 context.candidate().nsfw.user 같은 데이터 필드 직접 접근을 하던 것을, context.has_tweet_nsfw_user_flag() / context.viewer_country_in([...]) / context.legal_takedown_in_viewer_country() 같은 판정 근거 언어로 통일했다. visibility-filtering/rules/context.rs 214줄 신규. WORLDWIDE_COUNTRY_CODE = "xx" 상수와 takedown reason 추출 함수가 tes_rules.rs에서 이곳으로 이동했다.

• 골든 코퍼스 90건 + 배선-코퍼스 커플링 어설션 [확인] — visibility-filtering/rules/golden_corpus.rs에 13개 카테고리(filter_all·baseline·author_state·relationship·tweet_label·tweet_shape·age_gating·exclusive_content·interstitial·oon_media·oon_tweet_label·oon_user_label·interaction) 90건의 Case { name, level, viewer, candidate, expected_action, expected_decided_by } 표가 실렸다. 세 어설션이 걸린다: golden_corpus_pins_policy_verdicts(모든 케이스가 여전히 같은 액션과 같은 decided_by를 낸다), every_wired_rule_decides_a_corpus_case(배선된 rule 이름 집합에서 코퍼스가 결정자로 사용한 이름 집합을 뺐을 때 공집합), corpus_case_names_are_unique(케이스 이름 중복 금지). 후자 어설션을 위해 registry.rs에 #[cfg(test)] pub(crate) fn wired_rule_names(level) -> Vec<&'static str> 헬퍼가 신설됐다.

• 개별 rule 파일들은 로직 유지, 표현만 얇아짐 [확인] — 예를 들어 tes_rules.rs의 DropStaleTweetsRule은 이전 세 조기 반환(리트윗 검사 + source_tweet_id.is_some() 검사 + is_stale 검사)이 두 줄로 축약됐다.

  if context.is_stale_tweet() && !context.is_retweet() {
      return VfAction::Drop(FilteredReason::UnspecifiedReason);
  }
  

• tweet_flag_rules.rs와 user_rules.rs의 콜백 시그니처가 데이터 → 컨텍스트로 이동 [확인] — fn(&TweetFeatures) -> bool 콜백이 fn(&RuleContext<'_>) -> bool로 바뀌었고, 클로저 본체는 |t| t.nsfw.user → |context| context.has_tweet_nsfw_user_flag()처럼 옮겨졌다. registry.rs의 −298 중 절반은 개별 rule 테스트의 코퍼스 이관, 나머지 절반은 Viewer::LoggedIn(999) 등 반복 인라인 셋업 삭제로 파악된다 [추정].

• RerankerHeadTag 파라미터 wiring — 서버 소비 로직 없음 [확인] — home-mixer/params/param.rs에 param!(RerankerHeadTag, i64, "rust_home_mixer_reranker_head_tag", 0) 신설. PostCandidate에 pub reranker_head_tag: Option<u32> 필드가 붙고, PhoenixScorer가 reranker_head_tag: Some(query.params.get(RerankerHeadTag) as u32)로 요청에 담아 보낸다. phoenix_request.rs도 sequence.reranker_head_tag = Some(...)로 scoring_sequence에 부착한다. proto 두 자리에 대칭 추가:

  message ScoreInfo {
    ...
    optional double rewardRerankSlotProb = 5;
    optional uint32 rerankerHeadTag = 6;
  }
  
  message UserActionSequence {
    ...
    repeated Mask masks = 8;
    optional uint32 rerankerHeadTag = 9;
  }
  

  Rust proto와 Python proto가 같은 필드 번호로 동시 갱신됐다. 서버 쪽 헤드 라우팅 로직은 이 커밋에 없다.

• emb_table gRPC 콜백을 blocking pool로 분리 [확인] — phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs (+79/−12). 이전에는 gRPC proto 콜백이 non-temporal 복사와 Adler-32 계산까지 직접 수행했다. 새 코드는 4 MiB 청크를 sync_channel(2)에 밀어 넣고, 소비자가 tokio::task::spawn_blocking 안에서 실행한다.

  const GRPC_COPY_PIECE: usize = 4 << 20;
  let dest_ptr = buf.as_mut_ptr() as usize;
  let dest_len = buf.len();
  let (tx, rx) = std::sync::mpsc::sync_channel::<bytes::Bytes>(2);
  let copy_join = JoinOnDrop::new(tokio::task::spawn_blocking(move || {
      let dest = unsafe { std::slice::from_raw_parts_mut(dest_ptr as *mut u8, dest_len) };
      let mut pos = 0;
      let mut checksum = 1u32;
      while let Ok(chunk) = rx.recv() {
          install_grpc_chunk(dest, &mut pos, &mut checksum, &chunk);
      }
      (pos, checksum)
  }));
  

  RDMA 경로에서도 최종 Adler-32 합산까지 spawn_blocking으로 옮겼다. 새 헬퍼 **JoinOnDrop<T>**가 정상 경로에서는 join().await으로 결과를 회수하고, 드랍 시에는 block_in_place + block_on(handle)로 blocking 태스크를 반드시 종료한다(핸들·파일 디스크립터 누수 방지가 목적으로 추정된다 [추정]).

• copy_port_client.rs의 join_transfers 헬퍼로 관용구 중복 제거 [확인] — 이전에 join_all(...spawn) → collect → map_err 4행 관용구가 두 자리에 있었는데, 이를 join_transfers 헬퍼 하나로 뽑았다. 동작 변화 없음. 어제 커밋(4세대+10)에서 결정성 셔플을 도입하며 붙었던 테스트 이름("_despite_spawn", "_between_spawned_batches")이 정리됐다.

• proto_parser.rs에 Bytes 콜백 타입 신설 [확인] — 이전 Str 콜백(FnMut(usize, &[u8])) 옆에 Bytes 콜백(FnMut(usize, Bytes))이 열려 청크를 소유권 이동으로 넘길 수 있게 됐다. 이 커밋에서 emb_table은 여전히 Str 시그니처를 쓰므로 진짜 zero-copy 경로는 후속 커밋의 관측 포인트다.

"```rust param!(RerankerHeadTag, i64, "rust_home_mixer_reranker_head_tag", 0);

— [`home-mixer/params/param.rs`](https://github.com/xai-org/x-algorithm/blob/bc8e5f0/home-mixer/params/param.rs), 2026-08-28

VF 쪽은 4세대 초기의 "안전망 걷어냄"(reference_compare 하니스 → media fallback cache 제거)이 이번에 "회귀 방어 자산 안으로 축적"으로 이어졌다. 정책은 그대로다. 다만 향후 rule을 추가·수정할 때 판정 근거가 파일 이름과 나란히 도메인 언어로 읽히도록 만들었고, "테스트 없이 배선만" 하는 것을 CI 수준에서 원천 봉쇄했다. 코드 라인 수는 순감(−1175)이지만 회귀 방어의 커버리지는 순증이다. 이 방향은 X가 8월 내내 반복해 온 "일단 얹고 나중에 걷어내면서 하드닝을 축적"하는 관행과 일치한다(BSR-V2 3→7 여정, Grok 4.6 10%→30%→100% dial, TES media cache 도입 후 제거 등).

Phoenix 쪽은 다르다. RerankerHeadTag는 아직 서버가 안 읽는 스위치이지만, home-mixer 파라미터 + proto 필드 + 라운드트립까지 배선이 끝났다는 점에서 다음 커밋에서 서빙 소비 로직이 열리면 곧바로 A/B 실험이 가능한 상태다. 여러 리랭커 헤드를 학습해 두고 서빙 시 태그로 라우팅하는 패턴은 A/B 성숙기에 흔히 나타나며, 4세대의 다른 dial-up 관행(shadow 배포 → dial-up 커밋 → 프로덕션 승격)과 결합될 가능성이 크다. 두 자리(ScoreInfo·UserActionSequence)에 대칭으로 붙은 것도 요청·응답 대칭(요청은 "이 헤드로 채점" 지시, 응답은 "실제로 이 헤드가 사용됨" 확인)일 가능성을 시사한다.

emb_table의 gRPC 콜백 분리는 좁고 명확한 인프라 최적화다. gRPC 콜백이 tokio 런타임 스레드에서 non-temporal 복사와 Adler-32 계산을 오래 수행하면 같은 런타임의 다른 태스크(요청 라우팅·admission 결정·헬스체크)가 지연된다. 이번 변경으로 gRPC 수신 스레드는 청크 포워딩만 담당하고 CPU-바운드 복사는 blocking pool로 나간다. 4세대+9(emb_table core를 pyo3-free로 분리), 4세대+10(copy_port shuffle로 peer-load 균등화), 그리고 이번 blocking pool 분리는 대용량 임베딩 테이블 서빙 인프라가 tokio 런타임과 CPU-바운드 작업의 경계를 계속 다듬는 흐름이다. Bytes 콜백 타입 신설은 이 흐름이 다음 커밋에서 진짜 zero-copy로 이어질 가능성을 남겼다.

관찰 포인트는 이렇다: RerankerHeadTag의 서버 소비 로직이 언제 어떤 형식으로 열리는가(Phoenix Python 서빙 코드에 헤드 라우팅 함수가 추가되는 시점), Bytes 콜백을 emb_table이 언제 소비하는가(진짜 zero-copy 경로), 골든 코퍼스 90건이 이전 프로덕션 판정과 정확히 일치하는지 검증되는 채널(4세대+7 reference_compare 하니스가 이번 리팩터 이후에도 계속 돌고 있다면 실 트래픽 검증이 되고 있는 셈이다).

2. Netflix — 아트워크·비디오 프리뷰 개인화 시스템에 이름을 붙이다: MAPS

기존 시스템은 에셋을 불투명 ID로만 다뤘다(2017-2018 Artwork Personalization 밴딧 계보): 이미지 안에 무엇이 있는지 모델이 보지 못했고, 신규 타이틀·신규 에셋에는 상호작용 이력이 없어 콜드스타트에서 탐색(exploration)과 인기도 fallback에 의존했다. MAPS는 CLIP과 MediaFM 임베딩으로 모델이 에셋의 내용을 "보고 듣게" 만들어, 상호작용 이력이 쌓이기 전에도 개인화가 작동하도록 만든 프로덕션 시스템이다. 여기서 multimodal은 두 층위에서 쓰인다: (1) CLIP은 image-text 공유 공간, (2) MediaFM은 visual + audio + text tri-modal이다.

블로그가 arXiv 논문 대비 새롭게 세우는 것은 정량치가 아니라 아키텍처 맥락과 인프라 서술이다. 다섯 축이 새롭다: 시스템 이름 MAPS 자체, 2025 TV 홈스크린 개편 홀드백 실측, V1/V2 단독 vs V3 유의 ablation, Netflix Embedding Store의 명명과 두 속성, image·text·video 공통 semantic space로의 확장 계획.

• 시스템 이름은 MAPS [확인] — 지금까지 이 정본은 "아트워크 개인화"와 "비디오 프리뷰 개인화"를 별개 축으로 서술했는데, 블로그는 이 셋(CLIP 아트워크·query-aware 아트워크·MediaFM 비디오 프리뷰)을 하나의 시스템 MAPS로 묶는다. 공통 하부구조가 Embedding Store다. MAPS 블로그
• V1(이미지 임베딩만)·V2(캔버스 통합만) 단독은 오프라인·온라인 flat, V3만 유의 [확인] — 아트워크 실험에서 두 아이디어를 각각 켠 V1·V2는 오프라인 IPS도 온라인 core member metric도 non-significant. 둘을 함께 켠 V3만이 유의한 리프트를 얻어 프로덕션에 배포됐다. short-panel에서 V3 오프라인 IPS 상대 리프트는 **+5.691%**로 V1+V2 합보다 컸다. "content feature 하나만 켜서는 안 움직이더라"라는 관찰이 명시적으로 나온 사례다. MAPS 블로그
• 2025 TV 홈스크린 대개편 홀드백 실측 [확인] — UI 개편으로 short-panel이 갑자기 지배적 캔버스가 되는 콜드스타트 상황이었는데, 개편 직전에 V3를 배포하고 한 달간 홀드백 A/B(소규모 대조군은 이전 캔버스별 모델 유지)를 돌렸다. core discovery 지표와 streaming hours 둘 다 통계적으로 유의한 리프트를 얻었고, 정상 상태의 ablation보다 더 큰 리프트였다. 단일 모델의 캔버스 간 신호 전이가 실측된 사례다. MAPS 블로그
• Netflix Embedding Store — training-serving skew 없음 + FM 업데이트와 personalization 배포 decouple [확인] — Embedding Store는 AI Platform 컴포넌트이며 타이틀·게임·회원 프로필·멀티미디어 에셋의 dense 임베딩을 호스팅한다. 핵심 속성 두 가지: (a) training time과 online inference time에 정확히 같은 임베딩을 서빙해서 skew가 없다, (b) 새 임베딩(또는 기존의 새 버전)을 register → 카탈로그 backfill → 자체 검증까지 마친 뒤 downstream이 config 한 줄로 스위치할 수 있다. downstream 모델의 학습·서빙 코드 변경 없이 임베딩 세대 전환이 이뤄진다. MAPS 블로그
• Query-aware artwork — 추가 모델링 노력 사실상 0 [확인] — 랭킹 점수 = α · personalization + (1−α) · cos(text_emb(query), image_emb(asset))로 blend하고 α를 온라인 A/B로 튜닝한다. CLIP 임베딩이 이미 asset 표현에 있으므로 새 모델을 학습할 필요가 없었다. playthrough rate +0.36% (p<0.05). MAPS 블로그
• 비디오 프리뷰 A/B는 5주간 전 디바이스 플랫폼 [확인] — 순위는 MediaFM > SeqCLIP > ID-only이고, MediaFM이 core streaming metric에서 유의한 리프트를 얻어 전 플랫폼에 배포됐다. TV에서 gain이 가장 컸다. MAPS 블로그
• Linear probe proxy — 새 MediaFM 체크포인트 릴리스의 gating [확인] — "unpersonalized 정책에서 어떤 에셋이 이길지"를 임베딩만으로 예측하는 binary classification. exploration 데이터의 debiased popularity winner를 라벨로 삼는다. 프로브 정확도·오프라인 IPS·온라인 A/B 세 시그널이 모두 일치해서 모든 MediaFM 새 버전 릴리스의 gating으로 채택됐다. 후보 공간을 pruning한 뒤에만 A/B로 넘어간다. MAPS 블로그
• 다음 계획: image·text·video의 shared semantic space [확인] — Embedding Store를 image·text·video 공통 semantic space로 확장해 cross-modal retrieval과 통합 asset 랭킹을 열겠다고 명시했다. 회원 쪽 FM(2025)과 아이템 쪽 MediaFM(2026)이 같은 저장소에서 흐르는 그림이 앞으로도 유지될 것을 뜻한다. MAPS 블로그
• 블로그가 온라인 A/B 정량치를 숨긴 것에 유의 [관찰] 2026-08-30 — 블로그의 온라인 A/B는 "statistically significant lift", "gains largest on TV"처럼 정성으로만 서술한다. 정량치(+0.127% 등)는 arXiv 논문(2608.18322)에 있고 정본에 이미 반영돼 있다. 마지막 그림의 온라인 패널은 "values withheld"로 값을 감췄다. blog는 오프라인 IPS 상대 리프트만 그림에 표시한다.

"Neither idea moved our online core member metrics on its own. V1 and V2 were both flat and non-significant, and only V3 won a statistically significant lift. It is what runs in production today." — MAPS: Netflix's Multimodal Asset Personalization at Scale, 2026-08-28

"We shipped V3 ahead of the launch and measured it with a month-long holdback A/B test, keeping a small control group on the prior per-canvas model. V3 absorbed the shift immediately, with statistically significant gains on both our core discovery metric and streaming hours, and larger gains than in the steady-state ablation." — MAPS: Netflix's Multimodal Asset Personalization at Scale, 2026-08-28

"Its key property is that it decouples foundation-model updates from personalization-model deployments. A new embedding, or a new version of an existing one, can be registered, backfilled across the catalog, and validated entirely on its own, without touching the training or serving code of any model that consumes it." — MAPS: Netflix's Multimodal Asset Personalization at Scale, 2026-08-28

첫째, 세 프로덕트가 한 시스템으로 묶였다. 지금까지 정본은 "아트워크 개인화"와 "비디오 프리뷰 개인화"를 별개 축으로 서술했는데, 블로그는 CLIP 아트워크·query-aware 아트워크·MediaFM 비디오 프리뷰를 하나의 시스템 MAPS로 묶었다. 공통 하부구조가 Embedding Store다. 이는 "회원 쪽 FM은 하나로 통합됐지만 아이템 쪽은 여전히 축이 여러 개"라는 이전 관점을 갱신한다.

둘째, Netflix Embedding Store가 FM 스택의 별도 컴포넌트로 명명됐다. FM(2025, 회원)과 MediaFM(2026, 아이템)의 임베딩이 같은 저장소에서 흐르는 그림이 명확해진다. 회원 쪽 임베딩 배치 생산과 아이템 쪽 임베딩 파이프라인이 대칭이라는 기존 관찰이 인프라 이름 하나로 확정된다. decouple 속성은 특히 중요하다: 새 임베딩 세대가 register + backfill + validate만으로 배포될 수 있다면 FM 스택의 갱신 주기와 personalization 모델의 배포 주기가 완전히 분리된다. 이는 회원 쪽 FM의 "월 단위 재학습 + 일 단위 파인튜닝" 주기(정본 학습 주기 절 참조)와 아이템 쪽 MediaFM의 릴리스 주기가 각자 최적화될 수 있다는 뜻이다.

셋째, V1/V2 단독 flat vs V3 유의 ablation은 "content feature 하나만 켜서는 안 움직이더라"라는 관찰의 실증이다. 블로그가 이를 명시적으로 서술했다는 점 자체가 새롭다 — 추천 시스템에서 흔히 겪는 "오프라인 지표는 이겼는데 온라인 flat"의 반대 경우(오프라인·온라인 모두 flat이 겹치는 것)를 정면으로 인정한 것이다. 이는 이후 유사한 실험 결과가 나올 때 근거로 참조할 수 있는 사례가 된다.

2017 밴딧은 superseded로 봐도 무방하다: 블로그가 "for years, our models answered the first question well and the second poorly"로 이전 세대의 한계를 명시하고, V3가 프로덕션이라고 명언했다. GenRec·GenPage는 랭킹·페이지 생성 축이고 MAPS는 에셋 축이므로 직접 겹치지 않는다. 다만 세 시스템이 모두 회원/아이템 임베딩을 중심에 두는 FM 스택이라는 점에서 아키텍처적 방향은 하나다.

다음에 볼 것

• RerankerHeadTag의 서버 소비 로직이 열리는 커밋 — Phoenix Python 서빙 코드에 헤드 라우팅 함수가 추가되는 시점이 곧 A/B가 켜지는 신호다
• RerankerHeadTag의 첫 experiment 승격 — 0 → 1+로 파라미터 기본값이 바뀌거나 GrowthBook 게이트로 노출되는 커밋
• Bytes 콜백을 emb_table이 소비하는 커밋 — 진짜 zero-copy 경로가 열리는 신호
• 골든 코퍼스가 실제로 회귀를 잡아내는 첫 사례 — 90건이 이전 프로덕션 판정과 정확히 일치하는지의 사후 검증은 4세대+7 reference_compare 하니스가 계속 돌고 있는지에 달렸다
• Netflix Embedding Store의 shared semantic space 확장 — image·text·video 공통 임베딩 공간이 실제로 어떤 아키텍처로 구현되는지(CLIP-style 대조학습을 확장한 것인지, 별도의 tri-modal fusion을 학습한 것인지)
• MAPS의 다음 프로덕트 확장 — asset 축이 아트워크·프리뷰 다음에 어디로 갈지(트레일러? 오디오 프리뷰? UI 요소?)