2026-08-30

오늘 함께 본 다른 변화는 다음과 같다.

• X는 같은 커밋에서 Phoenix(X For You의 랭킹 모델)로 가는 요청에 리랭커 헤드 태그를 실었다. 서버가 읽는 로직은 없고, A/B 실험용 헤드 선택 스위치로 추정된다.
• Phoenix 서빙은 대용량 임베딩 다운로드의 gRPC 콜백이 tokio 런타임 스레드를 붙잡던 것을 blocking pool로 분리했다.
• Netflix는 아트워크·비디오 프리뷰 개인화 시스템에 MAPS라는 이름을 붙인 블로그를 냈다. 2025 TV 홈스크린 개편 홀드백 실측도 담겼다.

1노출 판정 규칙을 정책 변경 없이 리팩터링하고 90건 골든 코퍼스를 넣었다 — X

• 4세대+4: 요청을 shadow 서비스로 복제하는 xai-vf-shadow 미러링 연결
• 4세대+7: VF 재작성의 판정을 실제 판정과 대조하는 reference_compare.rs 하니스 연결
• 4세대+9: TES(X 내부 트윗 메타데이터 조회 서비스)를 부르는 TesHydrator의 media fallback cache 전부 제거

이번 4세대+11 커밋(bc8e5f0)은 그다음 단계로, 개별 rule 파일의 표현을 얇게 만들고 회귀 코퍼스를 코드 안에 넣는 리팩터다.

• 규칙이 조건을 확인할 때 쓰는 컨텍스트가 별도 파일로 분리됐고, 도메인 메서드 25여 개를 노출한다 확인 — visibility-filtering/rules/context.rs.

  • 분리된 것은 RuleContext이고, 새 파일은 214줄이다.
  • 예전에는 각 rule 파일이 context.candidate().nsfw.user처럼 데이터 필드에 직접 접근했다.
  • 이제는 context.has_tweet_nsfw_user_flag(), context.viewer_country_in([...]), context.legal_takedown_in_viewer_country()처럼 판정 근거를 말하는 언어로 통일했다.
  • WORLDWIDE_COUNTRY_CODE = "xx" 상수와 takedown reason 추출 함수가 tes_rules.rs에서 이 파일로 옮겨졌다.

• 개별 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()처럼 옮겨졌다.

• 골든 코퍼스(기대 판정을 고정해 둔 테스트 케이스 모음) 90건이 13개 카테고리로 실렸고, 이 코퍼스에 어설션 세 개가 걸린다 확인 — visibility-filtering/rules/golden_corpus.rs.
  • 카테고리는 filter_all·baseline·author_state·relationship·tweet_label·tweet_shape·age_gating·exclusive_content·interstitial·oon_media·oon_tweet_label·oon_user_label·interaction이다.
  • 케이스는 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 이름 집합에서 코퍼스가 결정자로 쓴 이름 집합을 빼면 공집합이어야 한다고 본다. Policies에 연결된 규칙은 코퍼스에 결정자 케이스(그 규칙이 판정을 내린 케이스)를 최소 한 건 가져야 하고, CI가 이를 강제한다.
    • 이 어설션을 위해 registry.rs에 #[cfg(test)] pub(crate) fn wired_rule_names(level) -> Vec<&'static str> 헬퍼가 새로 생겼다.
  • corpus_case_names_are_unique는 케이스 이름이 겹치지 않게 막는다.
• registry.rs의 −298 가운데 절반은 개별 rule 테스트를 코퍼스로 옮긴 몫이고, 나머지 절반은 Viewer::LoggedIn(999) 같은 반복 인라인 셋업을 지운 몫으로 파악된다 추정.

Phoenix 쪽 두 변경은 VF 리팩터와 별도 문맥이다. 리랭커 헤드 태그(RerankerHeadTag)는 home-mixer 파라미터에서 시작하고, 기본값은 0이다. 이 값은 Rust와 Python 두 recsys.proto의 필드로 나간 뒤, 스코어링 응답으로 다시 돌아온다. 서버가 이 태그를 실제로 어떻게 소비하는지(헤드 라우팅 로직)는 이 커밋에 없다.

• home-mixer 파라미터부터 Phoenix 요청과 proto 필드까지 태그가 연결됐고, 서버가 이 태그를 소비하는 로직은 없다 확인 — home-mixer/params/param.rs.

  • 파라미터 이름은 RerankerHeadTag이고, 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 두 자리에 같은 필드가 대칭으로 추가됐다. Rust proto와 Python proto가 같은 필드 번호로 동시에 갱신됐다.

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

  • 서버 쪽에서 RerankerHeadTag를 읽는 헤드 라우팅 로직은 이 커밋에 없다.

emb_table(Phoenix 서빙 엔진의 임베딩 테이블 모듈)의 gRPC 콜백 변경은 대용량 임베딩 테이블 서빙 인프라가 tokio 런타임과 CPU-바운드 작업의 경계를 계속 다듬는 과정이다. 2026-08-20 커밋(4세대+5)의 load_tensor_into core 분리, 4세대+10의 copy_port shuffle과 같은 흐름에 있다.

• 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으로 결과를 회수하고, drop될 때는 block_in_place와 block_on(handle)로 blocking 태스크를 반드시 종료한다. 핸들·파일 디스크립터 누수 방지가 목적으로 추정된다 추정.

• copy_port 클라이언트에서 반복되던 관용구를 헬퍼 하나로 뽑았고, 동작 변화는 없다 확인.
  • 파일은 copy_port_client.rs이고, 새 헬퍼는 join_transfers다.
  • join_transfers가 대신하는 것은 두 자리에 있던 join_all(...spawn) → collect → map_err 4행 관용구다.
  • 어제 커밋(4세대+10)에서 결정성 셔플을 도입하며 붙었던 테스트 이름("_despite_spawn", "_between_spawned_batches")이 정리됐다.
• proto 파서에 청크를 소유권 이동으로 넘길 수 있는 새 콜백 타입이 생겼다 확인.
  • proto_parser.rs에서 이전 Str 콜백 옆에 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

• 안전성(visibility-filtering) 절에 "4세대+11 (2026-08-28, bc8e5f0) — visibility-filtering 규칙 계층 리팩터 + 90건 골든 코퍼스" 소절을 추가했다. 이 소절에는 RuleContext 도메인 메서드 목록, 13개 카테고리 코퍼스, 규칙 연결과 코퍼스를 묶는 어설션, 개별 rule 축약 예시를 담았다.
• Phoenix 학습·인덱스 절에는 "4세대+11 (2026-08-28, bc8e5f0) — Phoenix serving: rerankerHeadTag 파라미터 배선 + emb_table gRPC 수신을 blocking pool로 분리" 소절을 추가했다.
• 열린 질문 절에는 "4세대+11 공개로 해소된 것 / 신규" 블록을 4세대+10 블록 위에 넣었다.
• 출처 절에는 bc8e5f0 sha와 대표 파일 9개를 나열했다. 나열한 파일은 context.rs·golden_corpus.rs·fixtures.rs·registry.rs·param.rs·recsys.proto·emb_table.rs·copy_port_client.rs·proto_parser.rs다.

• VF 쪽에서는 4세대 초기의 "안전망 걷어냄"(reference_compare 하니스 → media fallback cache 제거)이 이번에 "회귀 방어 자산 안으로 축적"으로 이어졌다.
  • 정책은 그대로다. 다만 앞으로 rule을 추가하거나 고칠 때 판정 근거가 파일 이름과 나란히 도메인 언어로 읽히도록 만들었다.
  • 또 "테스트 없이 배선만" 하는 것을 CI 수준에서 원천 봉쇄했다.
  • 삭제는 1,175줄이지만 커밋 전체로는 775줄 순증이고, 회귀 방어의 커버리지도 늘었다.
  • 이 방향은 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로 나간다.
  • 2026-08-20 커밋(4세대+5)에서는 emb_table core를 pyo3-free로 분리했고, 4세대+10에서는 copy_port shuffle로 peer-load를 균등화했다. 이 변경들과 이번 blocking pool 분리는 대용량 임베딩 테이블 서빙 인프라가 tokio 런타임과 CPU-바운드 작업의 경계를 계속 다듬는 흐름이다.
  • Bytes 콜백 타입 신설은 이 흐름이 다음 커밋에서 진짜 zero-copy로 이어질 가능성을 남겼다.
• 관찰 포인트는 다음과 같다.
  1. RerankerHeadTag의 서버 소비 로직이 언제, 어떤 형식으로 열리는지(Phoenix Python 서빙 코드에 헤드 라우팅 함수가 추가되는 시점)
  2. Bytes 콜백을 emb_table이 언제 소비하는지(진짜 zero-copy 경로)
  3. 골든 코퍼스 90건이 이전 프로덕션 판정과 정확히 일치하는지 검증되는 채널. 4세대+7 reference_compare 하니스가 이번 리팩터 이후에도 계속 돌고 있다면 실 트래픽 검증이 되고 있는 셈이다.

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

기존 시스템은 에셋을 불투명 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로의 확장 계획

• 블로그는 CLIP 아트워크, query-aware 아트워크, MediaFM 비디오 프리뷰 셋을 하나의 시스템 MAPS로 묶는다 확인 — MAPS 블로그.
  • 지금까지 정본은 "아트워크 개인화"와 "비디오 프리뷰 개인화"를 별개 축으로 서술했다.
  • 공통 하부구조는 Embedding Store다.

• 두 아이디어를 하나씩 켠 V1과 V2는 오프라인과 온라인 모두 flat이었다 확인 — MAPS 블로그.
  • V1은 이미지 임베딩만, V2는 캔버스 통합만 켠 버전이다.
  • 캔버스는 billboard나 short panel처럼 아트워크가 놓이는 화면 형식이고, 이전에는 캔버스마다 모델을 따로 뒀다.
  • 오프라인 IPS(inverse propensity scoring, 기록된 노출 정책의 편향을 보정해 새 정책을 오프라인으로 평가하는 방법)도, 온라인 core member metric도 non-significant였다.
• 둘을 함께 켠 V3만 유의한 리프트를 얻어 프로덕션에 배포됐다 확인(MAPS 블로그).
  • short-panel에서 V3의 오프라인 IPS 상대 리프트는 +5.691%로, V1과 V2의 합보다 컸다.
  • "content feature 하나만 켜서는 안 움직이더라"라는 관찰이 명시적으로 나온 사례다.
• 2025 TV 홈스크린 대개편 때의 홀드백 실측에서도 V3는 core discovery 지표와 streaming hours 모두 유의한 리프트를 얻었다 확인 — MAPS 블로그.
  • UI 개편으로 short-panel이 갑자기 지배적 캔버스가 되는 콜드스타트 상황이었다.
  • 개편 직전에 V3를 배포하고 한 달간 홀드백 A/B를 돌렸다. 소규모 대조군은 이전 캔버스별 모델을 유지했다.
  • 두 지표의 리프트는 모두 통계적으로 유의했고, 정상 상태의 ablation보다 더 컸다.
  • 단일 모델의 캔버스 간 신호 전이가 실측된 사례다.

• query-aware artwork에 든 추가 모델링 노력은 사실상 0이다 확인 — MAPS 블로그.
  • 랭킹 점수는 α · personalization + (1−α) · cos(text_emb(query), image_emb(asset))로 blend하고, α는 온라인 A/B로 튜닝한다.
  • CLIP 임베딩이 이미 asset 표현에 있으므로 새 모델을 학습할 필요가 없었다.
  • playthrough rate는 +0.36% (p<0.05) 올랐다.

• 비디오 프리뷰 A/B는 5주간 전 디바이스 플랫폼에서 돌았고, MediaFM이 core streaming metric에서 유의한 리프트를 얻어 전 플랫폼에 배포됐다 확인 — MAPS 블로그.
  • 순위는 MediaFM > SeqCLIP > ID-only다.
  • TV에서 gain이 가장 컸다.
• linear probe proxy가 모든 MediaFM 새 버전 릴리스의 gating으로 채택됐다 확인 — MAPS 블로그.
  • linear probe는 임베딩을 고정한 채 그 위에 선형 분류기만 학습해, 임베딩에 담긴 정보를 재는 방법이다.
  • 이 프로브는 "unpersonalized 정책에서 어떤 에셋이 이길지"를 임베딩만으로 예측하는 binary classification이다. 라벨은 exploration 데이터의 debiased popularity winner다.
  • 프로브 정확도, 오프라인 IPS, 온라인 A/B 세 시그널이 모두 일치해서 gating으로 채택됐다.
  • 후보 공간을 pruning한 뒤에만 A/B로 넘어간다.

• Netflix Embedding Store는 training-serving skew가 없고, FM 업데이트와 personalization 배포를 분리한다 확인 — MAPS 블로그.
  • FM은 foundation model(대규모로 사전 학습해 여러 하위 모델이 가져다 쓰는 모델)을 줄인 말이다.
  • Embedding Store는 AI Platform 컴포넌트이며, 타이틀·게임·회원 프로필·멀티미디어 에셋의 dense 임베딩을 호스팅한다.
  • 첫째 속성으로, training time과 online inference time에 정확히 같은 임베딩을 서빙해서 skew가 없다.
  • 둘째 속성으로, 새 임베딩(또는 기존 임베딩의 새 버전)을 register → 카탈로그 backfill → 자체 검증까지 마친 뒤 downstream이 config 한 줄로 전환할 수 있다.
  • downstream 모델의 학습·서빙 코드 변경 없이 임베딩 세대 전환이 이뤄진다.
• 다음 계획으로 Embedding Store를 image·text·video 공통 semantic space로 확장해 cross-modal retrieval과 통합 asset 랭킹을 열겠다고 명시했다 확인 — MAPS 블로그.
  • 2025년의 회원 쪽 FM과 2026년의 아이템 쪽 MediaFM이 같은 저장소에서 흐르는 그림이 앞으로도 유지될 것을 뜻한다.

• 블로그가 온라인 A/B 정량치를 숨긴 것에 유의한다 관찰 2026-08-30.
  • 블로그의 온라인 A/B는 "statistically significant lift", "gains largest on TV"처럼 정성으로만 서술한다.
  • 정량치(+0.127% 등)는 arXiv 논문(2608.18322)에 있고, 정본에 이미 반영돼 있다.
  • 마지막 그림의 온라인 패널은 "values withheld"로 값을 감췄다. 블로그는 오프라인 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

1. 섹션 헤더가 ## 아트워크·비디오 프리뷰 개인화 — MAPS (Multimodal Asset Personalization at Scale, 2026-08 프로덕션)로 바뀌었고, 도입 문단에 블로그 URL이 병기됐다.
2. CLIP two-tower(회원과 아이템을 각각 임베딩하는 두 타워 구조) 하위 절에 V1/V2 단독 flat vs V3 유의 ablation과 원문 인용을 추가했다. 2025 TV 홈스크린 대개편 홀드백 실측, query-aware artwork blend 수식과 "추가 모델링 노력 사실상 0" 명시도 추가했다.
3. Netflix Embedding Store 하위 절에 블로그가 새로 부여한 이름과 두 속성(training-serving skew 없음, FM 업데이트와 personalization 배포 decouple)을 추가했다. decouple 원문 인용과 다음 계획(공통 semantic space)도 함께 넣었다.
4. 출처 절에 MAPS 블로그 항목을 추가하고, arXiv 논문과의 관계(정량치 vs 아키텍처 맥락)를 명시했다.

• 첫째, 세 프로덕트가 한 시스템으로 묶였다.
  • 지금까지 정본은 "아트워크 개인화"와 "비디오 프리뷰 개인화"를 별개 축으로 서술했다. 블로그는 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 스택이라는 점에서 아키텍처 방향은 하나다.

다음에 볼 것