2026-09-03

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

• 같은 커밋에서 X 랭킹 모델 Phoenix에 semantic ID(SID, 아이템을 계층 코드로 표현한 것)를 dense 벡터로 되돌리는 복원 모드가 처음 생겼다.
• 같은 커밋은 학습한 모델을 CUDA 서빙용 번들로 내보내는 경로와 암호화 체크포인트 저장기도 새로 넣었다.
• Tencent PCG는 랭킹, 생성 retrieval, 슬레이트(한 번에 함께 보여 주는 아이템 묶음) 생성, 추론 토큰을 한 프레임에 묶은 TGR을 5개 지면에 적용했다.

1노출 판정 규칙을 데이터 정의로 다시 쓰고, 랭커에 SID 복원 모드를 넣었다 — X

• 4세대 공개에는 세 가지가 들어 있었다.
  • 안전 파이프라인의 4단계 labeling path(Content Understanding → Labeling Rules → Storage → Visibility Filtering)
  • VF의 세 SafetyLevel에 나뉘어 걸린 규칙. 추천 포스트용 TimelineHomeRecommendations에 54개(팔로잉용 TimelineHome의 28개 포함), FilterAll에 1개다 확인 — registry.rs 테스트. VF(visibility-filtering)는 포스트마다 '이 뷰어에게 보여도 되는가'를 판정하는 서비스다.
  • Phoenix 랭킹 모델의 학습 코드와 프로덕션 크론 미러 param. 크론 미러는 프로덕션 설정 값을 매일 동기화해 옮겨 오는 파일이다.
• 2026-08-28의 4세대+11(bc8e5f0)은 RuleContext를 도메인 메서드 25여 개로 넓혔다. 13개 카테고리 90건짜리 golden corpus도 넣고, 규칙 연결 코드와 테스트 어설션을 서로 묶었다. 테스트에 없는 rule을 연결하면 CI가 깨지는 구조다.
• 2026-09-01 새벽의 4세대+12(6384ca7)는 NSFW 게이팅 대상 16개국을 처음 코드에 명시했고, motion-reveal 기반 특수 영상 안전 파이프라인을 새로 만들었다.

이번 커밋(4세대+13, 같은 날 20:47 UTC)은 6384ca7 뒤 20시간 만에 나왔고, 세 가지를 함께 연다. 정책 변화는 없지만, 정본(이 저장소의 서비스·주제별 노트)이 몰랐던 사실 여러 개가 코드 층에서 확정된다.

• VF 규칙의 물리 구조가 규칙마다 구조체를 두는 방식(struct-per-rule)에서 데이터 기반 spec으로 바뀐다. 4세대+11이 골든 코퍼스로 표현을 고정했다면, 이번에는 표현 자체가 데이터 리터럴로 얇아졌다.
• Phoenix 랭킹 모델에서 RQ-VAE 계열 semantic ID 코드를 dense vector로 되돌리는 복원(recon) 경로가 처음 코드에 드러난다. RQ-VAE는 레벨별 잔차 codebook에서 코드를 하나씩 골라 더해 벡터를 표현하는 방식이다. X 내부에서 SID를 학습된 랭커 입력으로 어떻게 쓰는지가 처음 드러났다.
• JAX 학습에서 CUDA 서빙으로 넘기는 과정의 StableHLO 번들 export와, envelope 암호화를 쓰는 Orbax 체크포인트 writer가 인프라 층에서 표준화된다.

A. 노출 판정 규칙이 규칙마다 둔 구조체 대신 한 줄짜리 데이터 정의가 됐다

• 규칙 파일 9개가 지워지고 3개가 새로 생겼다 확인.

  • 새 파일은 visibility-filtering/rules/rule_spec.rs (89줄 신규), visibility-filtering/rules/tweet_rules.rs (1,125줄 신규), visibility-filtering/rules/author_rules.rs (354줄 신규)다. 셋을 합치면 1,568줄이다.
  • 지워진 파일 9개(총 2,670줄): nsfw_age_gating.rs(639) · nsfw_interstitial.rs(242) · nullcast_rule.rs(79) · socialgraph_rules.rs(301) · tes_rules.rs(446) · tweet_flag_rules.rs(114) · tweet_label_drops.rs(327) · user_label_drops.rs(239) · user_rules.rs(283).

• 새 공용 추상화는 규칙 하나를 한 줄짜리 리터럴로 적게 한다. 이 추상화가 RuleSpec이고, 변형은 세 가지다.

  • Tweet은 트윗 조건 predicate와 drop 또는 interstitial 액션으로 이뤄진다.

  • Author는 작성자 조건 predicate와 drop으로 이뤄진다.

  • Custom은 임의의 함수 포인터다. 조건을 predicate로 잡기 어려운 경우(예: 뷰어의 상태와 관계를 동시에 봐야 하는 규칙)에 쓴다.

  • 액션은 Drop과 SensitiveMediaInterstitial 둘뿐이다. interstitial 액션은 뷰어의 sensitive-media 옵트인 상태를 자동으로 확인한다.

  • RuleSpec의 정의는 다음과 같다.

    #[derive(Clone)]
    pub(super) enum RuleSpec {
        Tweet {
            name: &'static str,
            when: fn(TweetPredicates<'_>) -> bool,
            action: RuleAction,
            exempt_author: bool,
        },
        Author {
            name: &'static str,
            when: fn(AuthorPredicates<'_>) -> bool,
            reason: FilteredReason,
            exempt_follower: bool,
        },
        Custom {
            name: &'static str,
            evaluate: fn(&RuleContext<'_>) -> VfAction,
        },
    }
    

• 규칙마다 반복하던 공통 예외가 spec의 필드로 들어갔다. 예전에는 "저자가 본인이면 Allow", "팔로워면 Allow"를 규칙마다 따로 코드로 썼다. 이제는 두 필드가 이 검사를 맡고, 한 곳에서 처리한다.

  • 두 필드는 Tweet.exempt_author와 Author.exempt_follower이고, 처리하는 곳은 RuleSpec::evaluate다.

• 규칙은 옛 파일 단위로 그대로 옮겨지지 않았다. 정책을 촉발하는 유형끼리 다시 묶였다.

  • nsfw_interstitial.rs는 label이 촉발하는 interstitial(label-triggered)과 작성자 플래그가 촉발하는 interstitial(author-flag-triggered)로 나뉘었다. 앞의 것은 홈 base 규칙에 속하는 NSFW_MEDIA_INTERSTITIALS이고, 뒤의 것은 NSFW_AUTHOR_INTERSTITIAL이다.
  • tes_rules.rs는 홈 공통 규칙(stale과 takedown, TES_HOME_DROPS)과 recs 전용 규칙(DMCA와 geo-restricted media, RECS_MEDIA_DROPS)으로 나뉘었다. recommendations 전용 규칙 축이 코드에서 처음 명시적으로 드러났다.

• NSFW 게이팅 국가 목록을 이제 규칙이 아니라 컨텍스트가 들고 있다 확인 — visibility-filtering/rules/tweet_rules.rs sensitive_viewer_no_stated_age.

  • 옮겨 간 것은 Arc<NsfwGatingCountries>다. 4세대+12(6384ca7, 같은 날 새벽)에서는 nsfw_age_gating.rs가 struct와 Arc<NsfwGatingCountries> 필드로 국가 목록을 들고 있었다.

  • 이제는 RuleContext가 참조를 갖고 context.nsfw_gating_country(code)로 조회한다.

  • 규칙은 이제 상태를 갖지 않는 zero-sized data literal이다. 대신 Policies struct가 nsfw_gating_countries: Arc<NsfwGatingCountries> 필드를 갖는다. evaluate 시에는 RuleContext::new(..., &self.nsfw_gating_countries)로 참조를 넘긴다.

  • 규칙 이름 세 개(SensitiveViewerLoggedOutDropRule · SensitiveViewerUnderageDropRule · SensitiveViewerNoStatedAgeDropRule)는 그대로 유지된다. 감사 로그, 회귀 테스트, 투명성 리포트(Under the Hood)가 이 이름을 리터럴로 참조하기 때문이다.

  • 새 코드는 이렇다.

    fn sensitive_viewer_no_stated_age(context: &RuleContext<'_>) -> VfAction {
        if context.viewer().has_no_stated_age()
            && context.viewer().country()
                .is_some_and(|country| context.nsfw_gating_country(country))
            && sensitive_base_condition(context)
        {
            VfAction::Drop(FilteredReason::ContainNsfwMedia)
        } else {
            VfAction::Allow
        }
    }
    

base: !context.viewer().is_author() && tweet.has_media() && (tweet.has_safety_label(SafetyLabelType::NSFW_HIGH_PRECISION) || tweet.has_safety_label(SafetyLabelType::NSFW_HIGH_RECALL) || (tweet.is_nsfw_flagged() && !tweet.is_retweet())) ... if context.viewer().has_no_stated_age() && context.viewer().country().is_some_and(|c| self.gating_countries.contains(c)) && sensitive_base_condition(context) → Drop(FilteredReason::ContainNsfwMedia) (4세대+12 기준의 옛 코드, 4세대+13에서 위 형태로 옮겨졌다) — 4세대+12 visibility-filtering/rules/nsfw_age_gating.rs

• 회귀 방지 테스트가 정책이 바뀌지 않았음을 고정한다 확인 — visibility-filtering/rules/registry.rs.
  • 새 테스트 wired_rule_order_matches_pre_migration_sequence가 규칙 이름을 순서까지 리터럴로 검증한다. 대상은 TimelineHome 28개, TimelineHomeRecommendations 추가 26개, FilterAll 1개다.
  • 이 커밋이 정책 시맨틱 변경이 아니라 순수 리팩터라는 점이 코드로 확정됐다.

• 이번 커밋의 핵심 신호는 정책이 바뀌지 않았다는 사실을 코드로 어설션했다는 점이다. 4세대+11(2026-08-28)이 90건 골든 코퍼스로 규칙 판정을 고정한 지 나흘 만에, 표현 자체를 재구조화한 커밋이 나왔다. X는 VF 재작성 이후 회귀 방어 자산을 먼저 쌓고, 그 위에서 리팩터를 진행하는 순서를 굳혔다.
• 규칙 목록을 파악하고 감사하기가 크게 쉬워진다. 예전에는 "이 저장소에 어떤 NSFW/드랍 규칙이 있는가"를 확인하려면 파일 9개를 훑어야 했다. 이제는 tweet_rules.rs 하나만 열면 상수 그룹별로 모든 규칙이 한눈에 보인다. 규제 대응이나 투명성 리포트(Under the Hood)에서 원문을 인용하기에도 이 형태가 알맞다.
• 추천(recs) 전용 규칙 축이 코드에 명시됐다. RECS_MEDIA_DROPS(DMCA/geo)가 별도 상수로 나왔다. 이는 앞으로 추가될 recs 전용 규칙이 홈 base와 섞이지 않고 이 상수에만 붙는다는 뜻이다.

B. Phoenix 랭커가 semantic ID 코드를 dense 벡터로 복원해 입력에 더할 수 있게 됐다

• 새 파일은 retrieval 모델이 아니라 랭커 입력용 decoder다 확인 — phoenix/xrex/models/recsys_sid.py.
  • 파일은 phoenix/xrex/models/recsys_sid.py(72줄)다. 오프라인에서 학습된 SID 아티팩트를 로드해, 랭킹 시점에 SID 코드에서 dense vector를 되돌리는 함수 하나가 들어 있다.
• 아티팩트에는 잔차 codebook과 2층 MLP decoder가 들어 있다. _load_sid_decoder(path)가 .safetensors에서 아래 텐서를 로드한다.
  • stages는 형태가 (num_levels, codebook_size, code_dim)인 stacked residual codebook이다. RQ-VAE style로, 레벨별 잔차 임베딩을 골라 더한다(sum). codebook 크기와 레벨 수는 아티팩트에서 정해지고, 코드에는 하드코딩되어 있지 않다.
  • dec_w0 · dec_b0 · dec_w1 · dec_b1은 2-layer MLP decoder(relu → linear)다.
• 복원 함수는 아래 순서로 돈다.
  • codes = sids - 1로 1-based 코드를 0-based로 바꾼다. sids[..., 0] == 0인 행은 missing으로 표시한다.
  • 레벨별로 stages[l, code_l, :]를 뽑아 잔차를 더한다(residual sum).
  • 2-layer MLP와 relu로 dense vector를 복원한다.
  • L2 정규화한다(eps=1e-12).
  • missing 행을 0으로 마스킹한다.
  • stop_gradient로 decoder를 완전히 고정(frozen)한다.
  • recon_dim → target_dim 선형 project 하나({prefix}_sid_recon_proj, 학습 가능)만 매개변수로 둔다. 결과는 dtype을 캐스팅해 랭커 post tower에 돌려준다.
• 복원 모드는 config 필드로 켜고, 기본값은 기존 방식이다 확인.

  • RecsysAggregatedModelConfig에 두 필드가 추가됐다.

    sid_embedding_mode: Literal["learned", "recon"] = "learned"
    sid_decoder_path: str = ""
    

  • 기본값 "learned"는 기존의 학습 SID 임베딩 테이블을 그대로 쓴다.

  • "recon"으로 켜면 학습 SID 테이블을 우회한다. 대신 history_seq와 candidate_seq의 SID 코드에서 recon 벡터를 만들어 post tower 임베딩에 더한다(add).

  • 켜려면 legacy build_inputs 경로를 쓰고, sid_hash_level과 sid_cross_attn을 쓰지 않으며, sid_decoder_path를 지정해야 한다.

• 이번 커밋은 X SID 라인의 첫 코드 공개다. 그 SID 코드 자체를 어떻게 dense feature로 되돌리는지를 처음 코드로 드러낸다. 지금까지 공개된 X의 SID 관련 자료는 세 가지였다.
  • 2026-08-18의 4세대+3(11a71f8)에서 VMRanker(별도 서버에서 후보를 다시 정렬하는 value model 단계)에 sid_known·sid_k_l1/2/3·sid_gap_l1/2/3 필드가 연결됐다.
  • 2026-08-19의 4세대+4(aad7179)에서 Phoenix proto에 SlateContext.sid* 필드가 생겼다.
  • 2026-08-20의 4세대+5(d0cef2f)에서 서빙 응답의 slate context에 SID가 실려 왔다.
• decoder는 완전히 고정(frozen)된다. stop_gradient를 쓰고 아티팩트를 오프라인에서 만들므로, 서빙에는 codebook과 MLP 행렬만 배포하면 된다. 학습되는 것은 recon_dim → target_dim project 하나뿐이다. codebook 튜닝은 오프라인에서만 이뤄지고, 랭커를 학습해도 codebook은 흔들리지 않는다.
• 이 경로는 retrieval 모델이 아니다. codebook에서 벡터를 복원해 랭커 입력에 붙이는 것은 후보 표현의 밀도를 높이는 일이지, 후보 생성 자체를 SID로 대체하는 일은 아니다. Kuaishou OneRec(Kuaishou의 one-model 생성 추천 계보)이나 Tencent TGR(이 daily의 §2)처럼 "SID를 autoregressive 생성 대상으로 삼는" 접근과는 계보가 다르다. X는 아직 캐스케이드 안에서 SID를 입력 신호로 쓴다.
• 코드는 연결됐지만 꺼진 상태(wired-but-off)이고, 기본값은 "learned"다. 다음 커밋에서 sid_embedding_mode="recon"이 프로덕션 config에 나오면, X SID 파이프라인이 "학습 테이블"에서 "오프라인 codebook + 서빙 시 recon"으로 옮겨 갔다는 신호다.

C. JAX로 학습한 랭커를 CUDA 서빙용 StableHLO 번들로 내보내는 경로가 생겼다

• 새 진입점이 랭킹 모델의 forward를 낮춰(lower) 세 종류의 파일로 내보낸다 확인 — phoenix/xrex/train/recsys_bundle_export.py.
  • 파일은 phoenix/xrex/train/recsys_bundle_export.py(634줄)이고, 진입점 build_bundle(trainer)가 forward를 jax.export로 낮춘다.
  • 내보내는 호출은 jit(...).lower().as_text(dialect="stablehlo")와 jax_export.export(platforms=("cuda",)).serialize()다.
  • 세 파일은 StableHLO MLIR bytecode(.mlirbc), .jax_export 컨테이너, MANIFEST.json이다. StableHLO는 XLA 계열 컴파일러가 읽는 연산 그래프 형식이다.
• 임베딩 조회는 내보낸 그래프 밖에 있다. forward의 입력은 이미 조회된 임베딩 로우들을 이어 붙인(concat) 텐서다.
  • 입력 이름은 merged_embeddings다.
  • MANIFEST.embedding이 {rows, rows_padded, num_shards, width, dtype, merged_slices, hash_table}를 담아, 서빙 측이 임베딩 서버 결과를 어떻게 이어 붙일지 안다.
  • 이것은 X 랭커의 서빙 아키텍처가 "임베딩 서버가 조회 → GPU 서버가 StableHLO 실행"이라는 분리 구조임을 코드에서 드러낸 사실이다.
• 배치 크기별로 버킷을 여러 개 만든다. 버킷마다 별도 프로그램을 낮추고, 서빙 시 요청 배치 크기에 맞는 버킷을 고른다.
  • 설정은 export_bundle_bs_per_device이고, 기본값은 "1,2,4"다.
• seqpack 경로는 attention 커널 하나만 지원하고, FA4의 block-sparse 레이아웃은 지원하지 않는다.
  • pallas_ranker_varlen_attn만 지원한다. FA4(cutedsl_ranker_varlen_attn)의 block-sparse 레이아웃은 명시적으로 NotImplementedError를 낸다.
  • 4세대+6(2026-08-21, 28e414f)의 GB300 config가 attn_impl="cutedsl_ranker_varlen_attn"을 쓰므로, GB300 학습 config를 그대로 export하려면 attn kernel을 pallas로 바꿔야 한다.
  • 학습에서 서빙으로 넘어가는 지점에서 attention 구현이 달라지는 연결이 코드에 드러났다.
• 매니페스트에 SID 레벨 수가 함께 기록돼, 서빙 측이 SID 레벨을 몇 개 배치에 실을지 안다. §B의 SID 복원 모드와 짝을 이룬다.
  • sid_num_levels가 매니페스트 prep_spec에 그대로 기록(echo)된다.
• 번들 export는 체크포인트 배포 파이프라인의 copy_port(hot checkpoint 배포)에 붙어서만 켜진다. copy_port로 배포할 때마다 번들이 함께 나간다.

  • Trainer에 새 4개 필드가 추가됐다.

    export_stablehlo_bundle: bool = False
    export_bundle_bs_per_device: str = "1,2,4"
    export_bundle_history_seq_len: int = 0
    export_bundle_candidate_seq_len: int = 0
    

  • __post_init__은 export_stablehlo_bundle가 켜졌는데 checkpoint_config.copy_port가 꺼져 있으면 ValueError를 낸다.

  • 번들은 {OUT_PATH}/.{prefix}/export/로 나간다.

• X가 JAX 학습에서 CUDA 서빙으로 넘기는 과정을 StableHLO로 표준화했다는 것을 코드로 처음 공개했다. 이전까지 정본의 이해는 "Phoenix가 JAX/Haiku로 학습되고 서빙은 별도 스택"이었다. 이 커밋으로 서빙 스택이 컴파일된 StableHLO를 받아 실행하는 형태임을 확인할 수 있다.
• 임베딩 조회와 dense forward의 명시적 분리가 아키텍처 사실로 확정됐다. 이 사실은 X가 임베딩 테이블을 GPU 하나에 담지 않고 별도 서버에서 조회한다는 정본의 이해를 정확하게 뒷받침한다.
  • 테이블 규모는 4세대+4 xrecsys_search의 vocab 100M/100M/30M이고, 별도 서버는 임베딩 서버와 mm_embedding_client.rs다.
• export는 기본으로 꺼져 있다. 이 커밋만으로는 프로덕션 서빙이 실제로 StableHLO 번들을 소비하는지 확정할 수 없다. 다음 커밋에서 export_stablehlo_bundle=True가 프로덕션 config에 나오면, 서빙이 이 경로에 붙었다는 신호다.

D. 학습 체크포인트를 envelope 암호화로 저장하는 Orbax writer가 생겼다

• 새 파일이 Orbax(JAX용 체크포인트 라이브러리)의 handler를 감싸 envelope encryption을 저장소 안(in-tree)에 구현했다 확인 — phoenix/python/training/xai-checkpointing/xai_checkpointing/orbax_encrypted.py.

  • 파일은 orbax_encrypted.py(288줄)이고, 감싸는 대상은 Orbax PyTreeCheckpointHandler다.
  • envelope encryption은 AWS KMS 계열의 표준 패턴이다. KMS가 발급한 마스터 키로 디렉터리별 Data Encryption Key(DEK)를 감싸고, 데이터는 DEK로 대칭 암호화한다.

• 저장한 파일은 모두 매직 헤더로 시작해야 하고, 하나라도 헤더가 없으면 finalize 뒤에 커밋을 거부한다.

  • 헤더는 b"XAIENC01"이다. _DEK와 _DEK.claim(KMS가 발급한 DEK 파일과 claim)만 예외로 둔다.

  • 검사 코드는 이렇다.

    def assert_all_enveloped(path: pathlib.Path) -> None:
        offenders = []
        for f in sorted(path.rglob("*")):
            if not f.is_file() or f.name in ("_DEK", "_DEK.claim"):
                continue
            with f.open("rb") as fh:
                if fh.read(8) != b"XAIENC01":
                    offenders.append(f)
        if offenders:
            raise RuntimeError(
                f"encrypted save left plaintext at rest; not committing: {list(map(str, offenders))}"
            )
    

• 체크포인트에는 배열 리프만 허용하고, 문자열·dict·Python scalar 리프는 명시적으로 거부한다. 이 제한은 서빙 측에서 이 checkpoint를 로드할 때의 임의 코드 실행 리스크를 없앤다.

  • 허용하는 리프는 오직 jax.Array이고, _ArraysOnlyRegistry와 _require_array_leaves가 이를 강제한다.

• 메타데이터와 저장 계층도 암호화된다. tensorstore KvStore가 암호화된 wrapper로 교체되고, _METADATA·_CHECKPOINT_METADATA·sharding metadata도 모두 encrypt_write로 처리된다.

• 암호화된 체크포인트에서 복원한 프로세스는 평문으로 저장할 수 없다. 평문 저장을 시도하면 저장 자체가 실패한다. 실수로 암호화 상태를 잃는 일을 코드 수준에서 원천 차단하는 downgrade 금지 장치다.

  • checkpoint_write.py에 새로 생긴 가드다.

    if getattr(self, "_restored_encrypted", False):
        raise ValueError(
            "restored from an ENCRYPTED checkpoint but the orbax writer cannot "
            "produce encrypted saves — refusing to downgrade to plaintext saves"
        )
    

• 암호화 여부, 키, 컨텍스트, 청크 크기를 정하는 config 필드가 새로 생겼다.

  • CheckpointConfig에 새로 생긴 값이다.

    encrypt: bool = False
    encryption_key_id: str | None = None
    encryption_context: dict[str, str] = field(default_factory=dict)
    encryption_chunk_size_bytes: int = 8 * 1024 * 1024
    

  • encryption_context: dict[str, str]는 AWS-KMS의 encryption-context 패턴을 그대로 따른다. KMS 호출자가 키 사용을 메타데이터에 바인딩할 수 있게 하는 표준 필드다.

  • 청크 크기는 기본 8 MiB다.

• X가 학습 체크포인트를 저장 상태(at rest)에서 암호화한다는 사실이 코드로 확정됐다. 이전에는 인프라 층에서 처리한다고만 짐작할 수 있었다. 이제는 xrex 학습 파이썬 코드 안에 envelope encryption, KMS, 매직 헤더 강제가 들어 있다(in-tree). 규제 프레임워크(SOC2·FedRAMP·GDPR 등)를 소스에서 명시하지는 않았다.
• downgrade 금지 가드가 특히 눈에 띈다. 4세대+7의 VF reference_compare 하니스가 APP_ENV=prod에서 부팅 시 panic으로 스테이징 전용을 강제한 것과 같은 방향이다. 정책을 config 값이 아니라 fail-close 어설션으로 코드에 굳힌다. 이는 X의 이번 사이클 전반에 보이는 패턴이다.

E. 상품 광고(DPA)의 제품 정보에 SID 코드가 실렸다

• 서빙 proto의 DPA 상품 메시지에 SID 코드 필드가 추가됐다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto.

  • Dynamic Product Ads(DPA)는 광고주가 상품 카탈로그를 업로드하면 X가 유저 맞춤으로 자동 생성해서 노출하는 광고 포맷이다.

  • 추가된 필드는 DpaProductInfo의 repeated int32 sid_codes = 8이다.

    message DpaProductInfo {
      int64 product_key = 1;
      bool is_hero = 2;
      int64 gender_impressions = 3;
      int64 gender_clicks = 4;
      int32 gpc_l1_id = 5;
      int32 gpc_l2_id = 6;
      int32 gpc_l3_id = 7;
      repeated int32 sid_codes = 8;
    }
    

• 같은 커밋은 행동 이름 enum에 번호 구간 하나를 한꺼번에 예약했다. 광고 conversion 액션이 앞으로 더 확장될 자리를 확보한 것이다 추정.

  • DiscreteActionName enum에 reserved 214 to 252(39자리)가 예약됐다.

• DPA SID의 codebook이 유기 post SID와 같은지 다른지
• sid_codes를 소비하는 서버 측 연결이 이미 있는지
• A/B 결과가 있는지

F. 그 밖의 변경: 광고 블렌더 기본값이 바뀌고 임베딩 경로가 정리됐다

• 멀티모달 임베딩 조회(fetch)가 zero-copy 리팩터로 정리됐다. 이제 호출자가 목적지 슬라이스를 넘긴다.
  • 파일은 phoenix/crates/serving/xai-recsys-mm-server/src/mm_embedding_client.rs(+33/−8)이다. fetch_mm_embeddings_sync가 새 fetch_mm_embeddings_into(&self, post_ids, emb_dim, dest: &mut [f16])에 위임한다.
• 검색 쿼리 임베딩을 후보마다 복제해 저장하지 않고 한 번만 저장한다. 서빙 시에는 padding이 아닌 실제 후보에만 복제한다. 메모리와 명확성이 개선됐다.
  • 파일은 phoenix/crates/common/xai-recsys/src/util.rs(+68/−14)와 phoenix/crates/serving/xai-recsys-engine/src/python.rs(+10/−2)다.
  • 이전에는 candidate_search_query_embeddings가 후보마다 복제돼 CPU-side buffer에 N개 복사본으로 저장됐다.
  • 이제는 서빙 시 num_real_candidates(num_item_hashes, cap)만큼의 실 후보에만 repeat_query_into(dest, query, n_slots)로 복제한다.
• grox(Grok 기반 nearline 분류기 서브레포)의 멀티모달 임베딩 Kafka publisher가 multi-region producer로 옮겨 갔고, async 친화적인 구조로 바뀌었다.
  • 파일은 grox/flows/mm_emb/task_embedding_pub.py(+29/−26)이고, ScramKafkaProducer에서 MultiRegionKafkaProducer로 마이그레이션됐다.
• SCRAM 패스워드를 env-var로 직접 주입하던 코드가 제거됐다. multi-region config로 옮겨 간 것으로 보인다.
  • 파일은 grox/core/data_loaders/kafka_loader.py(0/−16)다.
• 광고 블렌더의 기본값이 multi-risk 방식으로 바뀌었다 확인. VF 리팩터와는 직접 관련이 없다.
  • home-mixer(For You 피드를 조립하는 서비스)의 home-mixer/params/param.rs(+2/−2)에서 바뀐 것은 이것 하나다. AdsBlenderType 기본값이 partition_organic_low_risk → multi_risk로 바뀌었다.
  • MultiRiskAdsBlender는 4세대+9(45b48ba, 2026-08-26)에서 새로 생겼다. 이 커밋에서 프로덕션 크론 미러상의 기본값이 그쪽으로 옮겨 간 것으로 보인다.

• 한 줄 요약과 세대 표에 4세대+13 행을 추가했다(commit sha 7ba7768, +2,964/−2,861, 파일 34).
• "안전성 / visibility-filtering / labeling 파이프라인" 절에 "4세대+13 — visibility-filtering rules 재구조화" 서브섹션을 새로 만들었다. 내용은 rule_spec.rs 89줄, tweet_rules.rs 1125줄, author_rules.rs 354줄, 9개 파일 삭제, 그리고 회귀 방지 테스트가 규칙 이름 순서를 리터럴로 검증한다는 점이다.
• "Phoenix 학습·인덱스" 절 하단에 "4세대+13 Phoenix 랭킹 모델에 SID recon 모드 배선", "StableHLO 번들 export 배선", "envelope-encrypted Orbax checkpoint writer" 세 블록을 새로 만들었다.
• "광고" 절에 "4세대+13 DPA 제품 SID가 서빙 wire format에 실렸다" 블록을 새로 만들었다.
• ## 출처의 커밋 sha 목록에 7ba7768(2026-09-01, 4세대+13)을 추가했다.
• git 로그 직접 확인 줄을 갱신했다(2026-09-02 → 2026-09-03, 커밋 12개 → 13개).
• 최종 갱신을 2026-09-02 → 2026-09-03으로 바꿨다.

• 정책 시맨틱은 그대로지만, 정본이 몰랐던 사실 여러 개가 코드 층에서 확정된다.
  • X 랭커에서 SID가 RQ-VAE 계열 codebook을 거쳐 dense vector로 되돌아가는 형태
  • 학습에서 서빙으로 넘기는 과정이 StableHLO 번들을 통해 이뤄지는 구조와, 임베딩 조회가 그 그래프 밖에 있다는 사실
  • checkpoint가 envelope encryption으로 저장 상태(at rest)에서 암호화된다는 사실(in-tree)
  • DPA 광고 제품 SID가 서빙 payload에 실린다는 사실
• VF 리팩터는 4세대+11(2026-08-28)의 골든 코퍼스 뒤에 오는 자연스러운 다음 단계다. X는 안전망을 걷어내면서 대신 회귀 방어 자산을 안으로 쌓고, 그 위에서 표현을 얇게 하는 순서를 굳혔다. 걷어낸 것은 4세대+9의 media fallback cache다. 쌓은 자산에는 4세대+7(d011592)에서 812줄로 새로 생긴 비교 하니스 reference_compare.rs가 있다. 이 순서는 이번 사이클의 다른 커밋(dark_traffic, reference_compare, golden corpus, 이번 rules 재구조화)에서도 일관된다.
• SID, StableHLO, 암호화 세 기능이 한 커밋에 몰린 것은 우연이라기보다, 이 커밋이 특정 프로덕션 롤아웃을 위한 사전 연결일 가능성이 크다 추정. 셋 모두 연결만 되고 꺼져 있으므로(wired-but-off), 다음 커밋에서 config 게이트가 켜지면 프로덕션이 어느 방향으로 움직이는지 관찰할 수 있다.

↑ 목차

2TGR이 생성형 랭킹·retrieval·슬레이트 생성·추론을 한 프레임에 묶었다 — Tencent

• 저자 13인이 팀 서명("TGR Team, Lei Cheng, Haonan Hu, Beibei Kong, Yudong Li, Zang Li, Yunsheng Pang, Hongyang Su, Jianchao Tu, Yunlong Wang, Bing Wen, Junzhang Zhu, Shaojie Zhu, Chengxiang Zhuo") 형식으로 이름을 올렸다.
• 대상 지면은 §1 "Our setting"에 "news feeds, short videos, long videos, music, and web novels"로 명시되어 있다. PCG 산하 제품에 대응시키면 Tencent News, Weishi, Tencent Video, QQ음악, 阅文/QQ阅读 계열일 것이다 추정. 근거는 지면 종류뿐이고, 논문 본문은 다섯 지면을 Scenario 1~5로 익명화한다.

이 프레임워크가 중요한 이유는 두 갈래다.

• 첫째, Kuaishou OneRec 계열에 대한 프로덕션 대응 진술로 회사 규모가 두 번째로 커진 사례다. Kuaishou는 OneRec-V1 → OneRec-V2 → OneRec-Think → OneReason으로 이어지는 단일 회사 시리즈였는데, Tencent PCG가 같은 방향(one-model recommendation)에서 프로덕션 배포를 진술했다.
  • 논문 §1이 명시적으로 이렇게 밝힌다: "Aligned with the one-model direction of OneRec at Kuaishou".
• 둘째, HSTU와 OneRec를 한 프레임 안에서 각각 대체 대상으로 명시한 첫 자료다. CCFormer가 Scenario 2~5에서 HSTU를 대체하고, BARGE·HiGR가 OneRec를 오프라인 베이스라인으로 대체한다. Meta HSTU 계보(랭킹)와 Kuaishou OneRec 계보(one-model)를 두 축으로 통합하려는 시도다.

A. 랭킹 모델 CCFormer는 두 지면에서 프로덕션 트래픽 전체를 맡고 있다

• CCFormer(TGR-GenRank)는 생성 패러다임의 Transformer 랭커다. feature-field separated cross attention, subspace token mixing, hierarchical sequence compression을 도입했다. HSTU 계보를 이어받되 랭킹에 특화된 요소들이다.
• Scenario 1(비디오 추천)에서는 "long-standing, iteratively optimized DLRM ranker"를, Scenario 2~5에서는 "already deployed HSTU model"을 대체한다.
• 두 지면에서는 전면 launch해 프로덕션 트래픽 전체를 맡고 있다(§3.6): "CCFormer was fully launched in Scenarios 1 and 2 and now serves the entire production traffic of both." Scenario 3~5는 A/B 상태로 명시했다.
• 주요 온라인 수치는 다음과 같다(§3.6, Table 6).
  • Scenario 1: CTR +3.57%, UCTR +1.93%, Page View +3.86%, Video View +3.47%, Watch Time +1.29%, Ad revenue +1.64%.
  • Scenario 2(광고 랭킹): Ad revenue +1.71%.
• HSTU보다 적은 연산으로 더 빨리 학습한다고 밝혔다(§3.5): "scales predictably at roughly half the GFLOPs of HSTU, trains 2.21× faster."

B. 생성 retrieval BARGE는 retrieval 채널 하나로 전면 배포됐다

• BARGE(TGR-GenRec)는 계층 semantic ID를 생성하는 retrieval이고, 두 가지 구조적 공백을 겨냥한다(Abstract): "two structural gaps in hierarchical semantic-ID generation — the loss of item boundaries when multi-token items are flattened and semantic drift caused by early prefix errors."
• 구조는 item context-aware attention, hierarchical path reranking, orthogonal dual-path decoding 세 가지다. 첫째는 문서에서 "item-boundary-aware"로도 부른다.
• 코드북은 Table 1에 "OSQ-VAE (dual)"로 명시되어 있다. §4.2의 상세 학습 목적은 이번 daily의 fetch 범위에서 확보하지 못해 심층 분석이 필요하다.
  • TIGER 계열(Kuaishou HD-Rec와 Alibaba MetaStrategy가 참조하는 RQ-VAE 계보)과의 관계는 표에서 "TIGER lineage"로 언급된다. 다만 codebook 초기화 방식(RQ-KMeans 여부)은 확인하지 못했다.
• retrieval 채널 가운데 하나로 전면 launch됐고, 다른 retrieval 채널과 나란히 존재한다(Abstract): "is fully rolled out as a generative retrieval channel with parameters, beam width, and serving latency unchanged, delivering +0.60% CTR and +1.70% total reading time — gains that grew larger and more stable after full launch."
• 오프라인에서는 OneRec보다 Hit@5가 높았다: "outperforms OneRec by 10.2–16.9% in Hit@5 across two industrial scenarios." 온라인에서는 CTR이 +0.60%, reading time이 1.70% 올랐다.

C. 슬레이트 전체를 생성하는 HiGR는 A/B에 그쳤다

• HiGR(TGR-GenRec)는 슬레이트 전체를 생성한다. 구성은 PCRQ-VAE(Prefix-Contrastive RQ-VAE) 토크나이저, Hierarchical Slate Decoder(HSD)의 coarse-to-fine 디코딩, listwise multi-objective alignment다.
• 논문 Table 1은 OneRec-V1/V2/Think와 축별로 비교한다. "prefix-structured semantic IDs"의 구체 구현과 HSD의 단계별 디코딩은 fetch 범위 밖이라 심층 분석이 필요하다. Meituan OneSug와 Xiaohongshu RankMixer 언급은 이 논문의 fetch 범위에서 확인되지 않았다.
• 전면 launch했다는 표현은 없고 A/B에 그친다. Abstract는 이렇게 썼다: "serves whole slates below 50 ms P99 latency at roughly 60% lower GPU demand than full-sequence decoding." 또 "consistently lifts engagement, traffic consumption, and commercial value across three A/B-tested scenarios"라고 했다.
• 오프라인에서는 같은 용량의 OneRec보다 슬레이트 품질이 높고 추론이 빠르다: "improves offline slate quality by 15.9–21.3% over matched-capacity OneRec with a 5× inference speedup." 온라인 3개 시나리오에서는 Average Watch Time이 +1.22%, Average Video Views가 1.73%, CTR이 0.68%, ad revenue가 0.56% 올랐다.

D. TGR-Reason은 텍스트가 아니라 semantic ID로 된 추론 토큰을 디코딩에 주입한다

• 오프라인에서 Think 모델이 semantic ID 형태의 reason token을 만들고, 온라인 디코딩 때 이를 프롬프트로 주입해 조건화한다(Abstract): "Offline, a LatentRec-trained Think model materializes complete semantic-ID reason tokens; Direct Reasoning Injection uses them as hierarchy-aligned prompts to condition online decoding."
• reason token은 텍스트 CoT가 아니라 semantic ID 형태의 사고 토큰이다. Table 1 캡션이 "reasoning-enriched semantic IDs generated offline by a LatentRec-trained Think model"이라고 정의한다.
  • Think 모델이 latent reasoning을 학습하고 그 결과를 semantic ID 코퍼스로 오프라인 export하면, 서빙 시 이 SID를 프롬프트로 주입해 디코딩을 조건화한다.
  • Kuaishou PushDualGen(SID와 skippable copy의 조합)과 접근이 비슷하지만, 여기서는 copy가 텍스트가 아니라 SID다.
• 배포 상태는 "statistically significant gains" 정도로만 표현했고, 전면 launch는 아니다. 적용 지면은 "one of our commercial content platforms"라고 익명화했다.
• 오프라인에서는 cold-start 신규 유저의 Hit@1을 올렸다고 밝혔지만, 베이스라인 절대값은 공개하지 않았다: "raises cold-start new-user Hit@1 by +477.8%". 온라인에서는 Effective Consumption Rate가 +1.75%, new-user Exposure-to-Conversion Rate가 13.09% 올랐다.

E. 오프라인 비교는 공개 데이터셋 두 개와 Tencent 산업 데이터셋에서 했다(§3.4)

• 공개 데이터셋은 Taobao와 KuaiRec이다(Table 2).
• 산업 데이터셋은 Tencent 추천 시스템의 한 달 치 프로덕션 로그다(§3.4): "industrial dataset of one month of production logs from a Tencent recommendation system: over 4 billion samples, 3 million users, and 10 million items."
• 베이스라인은 공개 벤치에서 DIN, DeepFM, SASRec, MIMN, HSTU, OneTrans, STCA이고, 산업 벤치에서 HSTU, OneTrans, STCA다.
• Table 1의 정성 비교 대상은 HSTU, OneTrans, OneRec-V1, OneRec-V2, OneRec-Think, OneReason, GPR, PinRec이다. HLLM, PinnerFormer, TIGER, LC-Rec는 fetch 범위 안에서 명시적으로 등장하지 않았다.

"Within Tencent's Platform and Content Group (PCG), recommendation runs across a deliberately heterogeneous portfolio of surfaces — news feeds, short videos, long videos, music, and web novels — which together serve hundreds of millions of daily active users." — arXiv 2609.00986v1 §1

"delivers statistically significant lifts in all five A/B-tested production scenarios (+3.57% CTR in the video-recommendation scenario; +1.71% advertising revenue in the advertising-ranking scenario)" — arXiv 2609.00986v1 Abstract

• HSTU와 OneRec가 한 프레임 안에서 각각 대체 대상으로 명시된 첫 자료다. 지금까지 정본의 이해는 HSTU 계보가 Meta 랭킹의 표준이고, OneRec 계보가 Kuaishou의 one-model 방향이라는 것이었다. TGR은 이 두 계보를 서로 다른 컴포넌트로 통합한다. CCFormer가 HSTU를, BARGE·HiGR가 OneRec를 대체한다.
• 가장 강한 배포 주장은 BARGE나 HiGR가 아니라 CCFormer다. 두 Scenario에서 전체 트래픽을 맡고 있는 것은 CCFormer뿐이고("fully launched, now serves the entire production traffic of both"), 다른 시나리오도 launch 쪽으로 나아갈 수 있는 상태다. BARGE는 retrieval 채널 하나로 launch됐고, HiGR는 A/B 상태에 그친다. Tencent는 랭킹에서는 확신을 표현했지만, retrieval과 slate 생성에서는 아직 그렇지 않다.
• reason token이 SID다. Kuaishou PushDualGen이 SID와 skippable copy(텍스트)를 조합했다면, TGR-Reason은 copy 자리에 텍스트가 아닌 semantic ID를 넣는다. 텍스트 CoT가 아니라 SID CoT로 다시 해석할 수 있다.
  • Spotify Research(2608.23154)는 통제 실험에서 "explicit reasoning trace가 SFT/RL 모두에서 offline effectiveness를 낮춘다"는 결과를 냈고, TGR-Reason은 이와 정면으로 대비된다. TGR-Reason은 텍스트 trace를 쓰지 않으므로 Spotify의 반증점을 우회하는 형태다.
• 다음 사이클에 심층 분석할 항목은 아래 6개다. 모두 이 daily의 범위 밖이므로 심층 분석 필요로 표시하고, 사람이 직접 시작하는 후속 작업으로 남긴다.
  • BARGE OSQ-VAE 코드북의 학습 목적과 초기화(RQ-VAE인지 RQ-KMeans인지, TIGER 계열인지 신설인지)
  • item-boundary-aware attention의 구체 구현(mask인지 loss term인지)
  • HiGR PCRQ-VAE의 Prefix-Contrastive 목적함수와 OneRec SID의 실질 차이
  • Think 모델의 백본(Hunyuan? Qwen? 사내 LLM?)과 reason token 코퍼스 규모
  • cold-start Hit@1 +477.8%의 베이스라인 절대값
  • Scenario 1~5의 실제 Tencent 제품 매핑(외부 발표·블로그에서 확정 가능한지)

↑ 목차

3arXiv 신규 30건 가운데 2건이 레이더 기준을 통과했다 — arXiv

오늘 arXiv cs.IR 신규 30건(파싱 성공, 조회 정상) 가운데 2건이 수용 기준을 통과했고, 나머지 28건은 탈락했다. 수용 기준은 플랫폼 기업 저자이거나 프로덕션 배포·A/B 진술이 있는 것이다.

• Tencent PCG의 TGR(arXiv 2609.00986)은 위 §2에서 자세히 읽었다. 통과하자마자 SID 스레드에 정본 반영했고, 이번 달 신규에도 별도로 등록했다.
• ByteDance의 ReST(arXiv 2609.01240)는 TikTok Shop Ads에 배포한 rec-native Transformer 랭킹 프레임워크다. radar.md 이번 달 신규에 추가했다.
  • 저자 12명 전원이 ByteDance 소속이다.
  • 구성 요소는 Dual-gated attention, rotary positional/temporal embedding, stabilized residual normalization, training-only auxiliary objectives, heavy reusable encoder와 lightweight cross decoder(projection-free KV attention)다.
  • 한 주 동안 온라인 A/B를 했다고 명시했다: "conduct a one-week online A/B test on TikTok Shop Ads, one of the largest advertising platforms".
  • 결과는 이렇게 밝혔다: "This latency-constrained configuration improves AUC by +1.31% and lifts Advv by a statistically significant +11.93% (p<0.01), while satisfying all other monitored production guardrails".
  • 그 뒤 배포를 진술했다: "ReST has since been fully deployed in production".
  • 50 ms P99 지연을 유지했고, 크기는 large 5.36M–5.69M 파라미터다.
  • 스케일링 법칙 스레드에서 Meta HSTU/Wukong/LLaTTE, Alibaba TransRetrieval에 이은 네 번째 회사 진술이다.
  • LLM 스타일 Transformer 블록이 saturate하는 sequence length·depth·width에서 rec-native 설계가 일관되게 scaling된다고 주장한다.

탈락한 28건은 대부분 세 부류다. benchmark·평가·RAG 방법론처럼 플랫폼 프로덕션 진술이 없는 논문, POI·의료·과학·전자상거래처럼 도메인을 제한한 학술 실험, 저자 소속을 확인할 수 없는 논문이다. 이 가운데 두 편만 인접 자료로 남긴다.

• CoGR(arXiv 2609.00638) "It Takes Two to Match: Co-Evolving Generative Retriever with Reinforcement Learning"은 오프라인 벤치마크만 있고 프로덕션 배포 진술이 없다.
  • 저자는 Runpeng Dai(UNC Chapel Hill)와 Kaili Huang · Changsung Kang · Ciya Liao(Apple 소속)다 관찰 2026-09-03 — 소속 확인은 논문 HTML 저자 목록이다.
  • GRPO 기반 co-evolving RL로 query와 item 양쪽의 keyword generator를 대칭으로 학습한다.
  • 내부 데이터셋("Internal APP Marketplace")과 공개 벤치(WANDS)에서 sparse/dense/generative 10개 베이스라인보다 F1이 각각 +10.9% / +36.1% 높았다고 진술한다.
  • Kang·Liao의 Apple 소속과 데이터셋 이름을 고려하면 App Store로 추정되나, 회사명은 논문이 밝히지 않는다.
  • radar 수용 기준의 프로덕션 조건을 넘지 못해 탈락했다.
• UEWM/WMG-RL(arXiv 2609.01067) "World Model-Guided Reinforcement Learning via Counterfactual User Engagement Simulation"은 프로덕션 진술이 없어 탈락했다.
  • 저자는 Ang Li 외 7인이다.
  • 유저 시뮬레이터(UEWM)로 오프라인 reward supervision을 만든다. 정책이 여러 후보를 제안하면 UEWM이 각 후보에 대한 피드백을 병렬로 예측해 dense reward로 바꾼다.
  • 1.7B student가 downstream recommendation에서 큰 LLM과 맞먹거나 앞선다고 주장한다.
  • 유저 시뮬레이터 라인이 다른 회사에서 프로덕션 진술로 나오면 다시 검토한다.

↑ 목차

레이더

• Tencent PCG의 TGR(arXiv 2609.00986)은 HSTU와 OneRec를 한 프레임에서 각각 대체 대상으로 명시한 첫 사례다. radar.md 이번 달 신규와 생성형 retrieval / semantic ID 스레드 두 곳에 반영했다.
  • 4-in-1 구성은 CCFormer(랭킹), BARGE(생성 retrieval), HiGR(slate 생성), TGR-Reason(SID reason token 주입)이다.
  • CCFormer는 Scenario 1·2에 fully launched됐고, HSTU를 대체한다. CTR +3.57%, ad revenue 1.71% 상승, HSTU 대비 GFLOPs 절반과 훈련 2.21x를 보고했다.
  • BARGE는 retrieval channel로 fully rolled out됐고, OneRec 대비 Hit@5가 +10.2–16.9%다.
  • HiGR는 OneRec 대비 slate quality +15.9–21.3%에 5x 속도다.
• ByteDance의 ReST(arXiv 2609.01240)는 TikTok Shop Ads에 fully deployed됐다. radar.md 이번 달 신규에 반영했다.
  • 1주 A/B에서 AUC +1.31%, Advv +11.93% (p<0.01)를 얻었고, 조건은 50 ms P99였다.
  • rec-native Transformer가 LLM 블록보다 sequence·depth·width에서 일관되게 scaling된다고 주장한다.
  • 스케일링 법칙 스레드의 네 번째 회사 진술이다.

↑ 목차

다음에 볼 것

↑ 목차