2026-09-26

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

• 같은 X 커밋에서 VF가 뷰어의 국가를 About This Account 데이터에서 직접 조회하게 됐다.
• 같은 커밋에서 규칙 골든 테스트가 정책 카테고리별 15개 파일로 나뉘고, 국가 코드를 9개 지역으로 묶는 카탈로그가 생겼다.
• OneTrans-V2는 추천 캐스케이드 세 단계를 Transformer 하나로 합쳐 프로덕션 A/B에서 GMV +9.74%, 처리량 3.2×를 보고했다.

1VF가 판정용 데이터 조회를 데이터 테이블과 스케줄러로 다시 썼다 — X

• 2026-09-23 커밋(4세대+27)에서 생겨 4세대+28까지 이어진 구조는 다음 순서로 돌았다.
  • rule/predicate가 자기에게 필요한 hydrator 집합을 const fn hydrators()로 선언한다.
  • RuleEngine::hydrators_for(safety_level)가 active rule set을 조사한다.
  • 그 결과를 Hydrators bitset으로 union한다.
  • hydrator variant마다 별도 함수/파일로 실행한다.
• 같은 2026-09-23 커밋에서 생긴 conversation_control_hydrator.rs(310줄)가 이 방식의 정점이었다.
• 이번 커밋에서 hydrator 함수 파일들(conversation_control_hydrator.rs·exclusive_content_hydrator.rs·socialgraph_hydrator.rs)은 파일 전체가 삭제됐다. hydration/mod.rs도 787줄이 잘려 169줄만 남았다.
• 그 자리에 plan.rs(471줄 신규)·execute.rs(1,280줄 신규)·sources.rs(445줄 신규) 3파일이 들어갔다.

• hydrator의 종류가 7 → 17 variant로 늘었다 확인 — visibility-filtering/hydration/mod.rs:44-62.

  • 종류를 나열한 enum은 Hydrator이고, 어제 목록에 없던 10개가 이번에 연결됐다.

  • 아래 코드 블록이 variant 목록이다.

    pub enum Hydrator {
        PureCore, Tweet, ConversationControl,          // TES 계열
        TweetSafetyLabels,                              // safety_label
        ViewerProfile,                                  // gizmoduck viewer
        AuthorSafety, AuthorLabels,                     // gizmoduck author (SAFETY / LABELS 필드 분리)
        Follows, Blocks, Mutes, MuteRetweets,          // socialgraph forward edges
        BlockedByAuthor, BlockedByReplyRoot,           // socialgraph reverse
        SuperFollowsExclusive,                          // exclusive_content
        RootFollowsViewer, SuperFollowsRoot,           // conversation_control
        ViewerCountry,                                  // about_this_account (신규 클라이언트)
    }
    

• 각 variant마다 별도 함수가 있는 것이 아니라, 하나의 테이블에 한 행으로 등록된다 확인 — plan.rs:32-45.

  • 테이블의 행 형식은 NodeSpec { source, part, key, label }이다.

• 테이블의 한 행(NodeSpec)은 hydrator 하나를 4개 축의 데이터로 표현한다 확인 — plan.rs:82-192.

  • Source는 어느 backend를 호출하는지다.
  • Part는 백엔드 안에서 무엇을 가져오는지다. 컬럼, 필드셋, edge query가 여기에 해당한다.
  • KeyOrigin은 입력 키가 어디서 오는지다. 요청 tweet id, viewer id, PureCore(트윗 코어 메타)가 채워 준 author id 등이 있다.
  • label은 메트릭용 client·method 문자열 쌍이다.
  • 예를 들어 Hydrator::AuthorSafety는 NodeSpec { source: GizmoduckAuthor, part: Fields([SAFETY]), key: PureCoreAuthor, label: ("gizmoduck", "get_users") }이다.

• 요청된 hydrator 가운데 backend와 입력 dependency가 같은 것들은 한 번의 RPC로 묶이도록 계획된다 확인 — plan.rs:274-305.
  • 계획은 HydrationPlan이 세운다. HydrationPlan::new(level, hydrators)가 요청된 hydrator를 (source, input) 쌍으로 그룹핑한다.
  • 같은 source여도 dependency가 다르면 다른 그룹이 된다. pure_core가 필요한 것과 요청에 이미 있는 것이 그런 경우다.
• 예를 들어 gizmoduck(X의 유저 정보 서비스)에서 가져오는 작성자의 SAFETY 필드와 LABELS 필드는 호출 한 번으로 함께 조회된다 확인 — plan.rs:316-353.
  • Hydrator::AuthorSafety(SAFETY 필드)와 Hydrator::AuthorLabels(LABELS 필드)는 둘 다 GizmoduckAuthor source에 PureCoreAuthor 입력을 요구하므로 한 그룹이 된다.
  • Group::fields()가 두 필드 집합의 합집합을 만들어, gizmoduck.get_users(fields=[SAFETY|LABELS]) 한 번으로 처리한다.
  • Follows·Blocks·Mutes·MuteRetweets도 모두 Flock source, PureCoreAuthor 입력, forward 방향이 같으므로 한 번의 socialgraph/batch_check_relationships 호출로 묶인다.

• 조회 계획은 SafetyLevel(지면별 정책 묶음)마다 정해지고, 골든 테스트가 그 계획을 문자열로 고정한다 확인 — plan.rs:422-460.

  • RuleEngine::plan(level)이 SafetyLevel마다 만드는 계획을 5-safety-level 골든 문자열로 잠근다.
  • SafetyLevel별 호출 수가 다음처럼 고정돼 있다.
    • filter_all: 1 call
    • timeline_home: 7 calls
    • timeline_home_recommendations: 7 calls
    • timeline_home_hydration: 10 calls
    • immersive_expanded_recommendations: 7 calls
  • 문자열에는 계획마다 어느 client·method를 어느 input에 대해 어느 hydrator 노드로 실행하는지가 적혀 있다. viewer가 필요해서 logged-out에서 건너뛰는지까지 들어 있다.

  "filter_all: 1 calls\n tes/get_tweet_core_datas after: - nodes: pure_core\n timeline_home_hydration: 10 calls\n tes/get_tweet_core_datas after: - nodes: pure_core\n tes/get_tweets_for_visibility after: - nodes: tweet\n conversation_control/get_conversation_controls after: - nodes: conversation_control\n safety_labels/get after: - nodes: tweet_safety_labels\n gizmoduck/get_viewer_data after: - nodes: viewer_profile fields: ACCOUNT|EXTENDED_PROFILE|SAFETY (skipped logged out)\n gizmoduck/get_users after: pure_core nodes: author_safety fields: SAFETY|LABELS\n blocked_by/batch_check_blocked_by after: pure_core nodes: blocked_by_author,blocked_by_reply_root blocks-rev[author,reply_root] (skipped logged out)\n exclusive_content/batch_check_super_follows after: tweet nodes: super_follows_exclusive super_follows-fwd[exclusive_author] (skipped logged out)\n conversation_control/batch_check_followed_by+batch_check_super_follows after: conversation_control nodes: root_follows_viewer,super_follows_root follows-rev[root:Community|MyNetwork] super_follows-fwd[root:Subscribers] (skipped logged out)\n conversation_control/tfe_top_country after: conversation_control nodes: viewer_country (skipped logged out)" — visibility-filtering/hydration/plan.rs:422-451

  • 즉, 서비스는 timeline_home_hydration의 조회를 4단계 그래프로 스스로 인식한다.
    1. 다섯 개 조회는 요청 tweet id와 viewer id만으로 바로 시작한다. tes/get_tweet_core_datas와 tes/get_tweets_for_visibility·conversation_control·safety_labels·gizmoduck/get_viewer_data가 여기에 해당한다.
    2. gizmoduck/get_users(author_safety와 labels)와 blocked_by는 pure_core가 채운 author id에 의존한다.
    3. exclusive_content는 tweet 노드(tes/get_tweets_for_visibility)의 결과에 의존한다.
    4. conversation_control 하위 조회(followed_by와 super_follows)와 tfe_top_country는 conversation_control 결과에 의존한다. conversation control은 누가 답글을 달 수 있는지 정하는 X의 대화 설정이다.

• 실행 단계는 그룹 사이의 dependency graph를 FuturesUnordered(여러 비동기 작업을 함께 돌리고 끝난 순서대로 결과를 받는 Rust 자료구조)로 스케줄한다 확인 — execute.rs:80-100.
  • 스케줄러는 execute.rs에 있으며, 다음 순서를 반복한다.
    • 먼저 ready 큐를 input.is_none()인 그룹(외부 dependency가 없는 그룹)으로 초기화한다.
    • 각 ready 그룹의 RPC를 spawn해서 running FuturesUnordered에 넣는다.
    • 어느 하나가 끝나면 그 결과를 Store에 저장한다.
    • waiting_on(group)으로 이 그룹을 기다리던 하위 그룹을 다시 ready로 올린다.

• 새 클라이언트가 유저의 weighted top country를 조회해 국가 hydrator에 공급한다 확인 — visibility-filtering/clients/about_this_account_client.rs:1-42.
  • 새 클라이언트는 about_this_account_client.rs(166줄)다.
  • 조회하는 곳은 Strato(코드가 데이터를 조회하거나 저장할 때 거치는 X 내부 시스템) 컬럼 about_this_account/tfe_top_country.User이고, 결과를 받는 hydrator는 ViewerCountry다.
  • 이 클라이언트 결과는 conversation_control allowed-list 판정의 country 필터에 쓰인다.
  • "About This Account" 자체는 X 앱 계정 프로필 하단의 투명성 UI로, 계정 생성일·top country·이름 변경 이력을 보여 준다. 그 데이터 원천을 VF가 직접 소비하게 됐다.

• VF의 rules 계층도 함께 재편됐다 확인.
  • visibility-filtering/rules/tweet_rules.rs −575줄, author_rules.rs −160줄, registry.rs +226/−58, rule_spec.rs +141/−161이다.
  • 2026-09-22 커밋(4세대+26)에서 도입된 이원 Verdict 트리(Withheld/Shown) 구조는 유지되고, rule 카탈로그 자체가 데이터로 옮겨 가는 방향이 이어진다. 세부는 더 추적해야 한다.
• 규칙의 골든 케이스를 모은 1,493줄짜리 단일 파일이 정책 카테고리별 15개 파일로 나뉘었다 확인 — visibility-filtering/rules/golden_corpus/.
  • 원래 파일은 rules/golden_corpus.rs다.
  • 새 파일과 줄 수는 다음과 같다.
    • age_gating.rs 267줄·author_state.rs 119줄·baseline.rs 56줄·builders.rs 63줄·conversation_control.rs 257줄
    • exclusive_content.rs 61줄·interstitial.rs 334줄·mod.rs 173줄·oon_media.rs 218줄·oon_tweet_label.rs 133줄
    • oon_user_label.rs 234줄·relationship.rs 122줄·takedown.rs 224줄·tweet_label.rs 195줄·tweet_state.rs 90줄
• 국가 코드를 지역 단위로 묶는 카탈로그가 새로 생겼다 확인 — visibility-filtering/models/region.rs:1-97.
  • 새 파일은 models/region.rs(97줄)이고, ISO country code를 9개 지역(AFR·AUS·CAS·EAS·EUR·NAM·SAM·SAS·SEA)으로 매핑한다.
  • 예를 들어 AFR은 AO·BF·BI·BJ·BW·CD 등 57개국, EUR은 AD·AL·AT 등 51개국, SEA는 BN·ID·KH·LA·MM·MY·PH·SG·TH·TL·VN 11개국이다.
  • 4세대+12(2026-09-01)의 NSFW 게이팅 16개국 목록이 국가 단위였다면, 이제 지역 단위의 rule도 표현할 수 있게 된다.
• Phoenix(X의 Grok 기반 Transformer 랭커)의 proto에 34줄짜리 새 필드가 추가됐다 확인.
  • phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto와 phoenix/python/common/xai-proto/proto/recsys.proto 양쪽에 같은 34줄이 추가됐고, lib.rs에는 +58줄이 붙었다.
  • 어떤 필드가 추가됐는지는 이번 배치에서 추적하지 않는다. 후속 커밋에서 소비처가 나오면 그때 정본에 반영한다.
  • Phoenix transformer.py는 +42/−5, recsys_model.py는 +5/−1이다.
• grox(Grok 기반 nearline 분류기)의 key-frame 파이프라인이 정비됐다 확인.
  • 새 파일 frame_sampler.py(124줄)와 embedding_ranked_key_frames.py(193줄)가 추가됐다.
  • key_frames.py는 −53/+14로 재편됐고, media_loader.py는 +62/−34, convo.py는 +112/−61이다.
  • 2026-09-24 커밋(4세대+28)까지 열렸던 32×32 grayscale scene-cut·shot midframe 파이프라인이 embedding 기반 랭킹으로 확장되는 것으로 보이지만, 세부는 추적하지 않는다.
• home-mixer(For You 피드를 조립하는 서비스)에서 브라질 2026 선거 관련 계정 목록을 하드코딩한 필터가 소량 업데이트됐다 확인.
  • 파일은 home-mixer/filters/brazil_2026_election_filter.rs(+22/−2)이고, 필터는 2026-08-14 커밋에서 신설됐다.
  • 코드 주석은 규제 근거로 브라질 선거법원(TSE) Electoral Resolution No. 23.610 Art. 28 §1º-A를 명시한다.
  • 팔로잉 예외는 유지된다.
• 관측 UI 코드(약 600줄)가 새로 추가됐다 확인.
  • 위치는 under-the-hood/jetfuel/이고, routes/index.tsx·report.tsx·download.tsx·_lib/{load,mock,report,ui} 8파일이 추가됐다.
  • 계정 단위 라벨 투명성 툴(4세대에서 파일럿으로 언급)의 프론트엔드 코드가 오픈된 것으로 보인다.
  • 랭킹·retrieval 메커니즘과는 직결되지 않으므로 정본 반영은 하지 않는다.

이번 재작성의 실질적 의미는 세 가지다.

• 첫째, hydration의 인터페이스가 함수에서 데이터로 옮겨 갔다.
  • 직전 구조는 rule마다 hydrators() 리스트를 선언하는 방식이었지만, 실행 자체는 여전히 함수 계층(hydrator variant마다 .rs 파일)이었다.
  • 오늘은 실행도 데이터가 됐다. NodeSpec 테이블 하나만 있으면, 어느 hydrator 조합이 요청되든 스케줄러가 RPC 그룹을 자동으로 계획한다.
  • rule을 추가할 때 hydrator 함수를 새로 쓸 필요가 없고, 테이블에 한 줄을 더하면 된다.
• 둘째, RPC 그룹 병합이 자동화됐다.
  • 어제까지는 gizmoduck의 SAFETY 조회와 LABELS 조회가 서로 다른 hydrator 함수를 거쳤다. 오늘은 Group::fields()가 같은 source·같은 입력을 갖는 hydrator들의 필드 집합을 자동으로 합쳐 한 번의 RPC로 묶는다.
  • 이것은 마이크로 최적화가 아니다. hydration 예산이 gizmoduck·socialgraph 같은 fan-out 서비스에 몰리는 X 구조에서 P99에 직접 영향을 준다.
• 셋째, ViewerCountry hydrator를 연결해 conversation-control country allowed-list가 hydration 예산에 정식으로 들어왔다.
  • 이전 세대에서는 country 정보가 요청 컨텍스트에 실려 왔지만, 이제는 hydration이 about_this_account/tfe_top_country.User Strato 컬럼을 직접 조회해서 채운다.
  • About This Account 투명성 UI의 백엔드가 VF 판정 경로에 붙었다는 의미다. 규제 대응(예: 국가별 콘텐츠 제한) 축이 hydration 계층에 정식으로 들어왔다.

golden_corpus를 15개 파일로 나눈 것은 두 가지를 위한 준비 작업으로 읽힌다. 하나는 정책 카테고리별로 코퍼스 오너십을 나누는 것이고, 다른 하나는 2026-09-22 커밋(4세대+26)에서 열린 이원 Verdict 트리에서 카테고리별 verdict 매트릭스를 독립적으로 잠글 수 있게 하는 것이다.

2OneTrans-V2가 추천 캐스케이드 세 단계를 Transformer 하나로 합쳤다 — 레이더

1. MoE 백본을 확장했다.
2. DCGR(Decision-Conditioned Generative Retrieval)로 목표별 retrieval 채널을 하나의 generative 프로세스로 합쳤다.
3. SNT(Sequence-Native Training)로 유저 lifelong 시퀀스 인코딩을 노출마다 amortize했다.

• 캐스케이드 3단계를 모두 하나의 Transformer로 통합했다 확인 — 초록.
  • user behavior sequence를 shared context로 한 번만 인코딩하고, stage-specific candidate feature와 computation은 유지한다.
  • Joint training으로 세 stage가 서로 강화되며, in-model knowledge distillation이 fine-rank에서 pre-rank로 흐른다.
• 백본을 sparse MoE로 확장하고, μP-style parameterization으로 스케일링을 안정화했다 확인.
  • 활성화되는 연산량은 묶어 둔 채 capacity를 늘리는 표준 recipe다.
  • 다만 산업 스택에서 μP(모델 폭을 바꿔도 하이퍼파라미터를 그대로 옮겨 쓰게 하는 파라미터화) 스타일 hyperparameter transfer를 명시적으로 채택한 첫 진술이다.
• DCGR(Decision-Conditioned Generative Retrieval)은 다가올 상호작용의 유형을 먼저 예측하고, 그 예측에 조건화해서 아이템을 생성한다 확인.
  • 먼저 예측하는 것은 decision prefix, 즉 다가올 상호작용의 유형을 서술하는 짧은 토큰이다.
  • objective별 retrieval 채널을 여러 개 따로 두는 대신 하나의 generative 프로세스로 통합하고, business objective가 decision prefix로 방향을 잡는다.
• SNT(Sequence-Native Training)는 학습을 유저의 lifelong behavior sequence 기준으로 조직해서, 시퀀스 인코딩을 노출(exposure)마다 amortize한다 확인.
  • 유저 표현을 request마다 다시 계산하는 대신 세션·노출 축으로 재사용한다.

• 프로덕션 A/B에서 GMV는 +9.74% 올랐고, 같은 하드웨어 예산에서 throughput은 기존 캐스케이드의 3.2×였다 확인.

  "Deployed across all three stages of a large-scale industrial recommendation system, OneTrans-V2 improves gross merchandise value (GMV) by 9.74% and, with a co-designed serving stack, delivers 3.2× the throughput of the cascade it replaces under the same hardware budget." — arXiv 2609.28589 abstract

• 앞선 두 편은 각각 다른 각도였다.
  • UNIQUE (Baidu, RecSys 2026)는 generative retrieval과 target-aware ranking을 early-fusion single architecture로 묶는 각도였다.
  • UniRec (Kuaishou)는 pre-rank·rank 두 stage fusion agent를 joint learning으로 정렬하는 각도였다.
• 게다가 A/B 수치가 GMV +9.74%·throughput 3.2×로 다른 두 편보다 훨씬 크다.
  • UniRec은 app usage duration +0.616%였고, UNIQUE는 A/B 수치를 abstract에 공개하지 않았다.
• HTML 판이 없고 Semantic Scholar도 affiliation을 반환하지 않아, 이번 배치에서는 판단을 유예한다.
• GMV 지표를 쓰는 e-commerce 플랫폼(Taobao·JD·Meituan·Pinduoduo·Shopee 등)이 가장 유력한 후보다 추정.
• 후속 v2나 학회 accepted 통지에서 affiliation이 확인되면 정본 반영을 재검토한다.

나머지 arXiv 자료는 관찰 대상에서 뺐다. 이번 arXiv triage 30건 중 나머지 29건은 다음 사유로 통과되지 못했다.

• AgentX(2609.30001, Meituan): model research framework, 즉 연구 agent 아키텍처에 대한 자료이지 랭킹·retrieval 메커니즘 자체의 새 각도가 아니다.
  • abstract는 "560 of 636 completed model-changing experiments recorded AUC above their business baselines"와 "10-15% acquisition efficiency, 15-20% target-segment advertising spend, 0.3-0.8% watch time"의 프로덕션 A/B를 주장한다.
  • Meituan은 이 저장소가 정본(canon)으로 추적하는 서비스가 아니다.
  • 이 저장소가 묻는 "실제 서비스가 무엇을 하는가"보다 "실제 서비스를 만드는 팀이 어떻게 연구하는가"에 가까운 자료라서 스레드가 다르다.
• X-Rec(2609.29180): flow matching으로 continuous item embedding space에서 recommendation distribution을 학습한다는 학술 GR(generative retrieval) 자료다. abstract에 프로덕션 배포 진술이 없어 탈락했다.
• From Interests to Semantic IDs(2609.29983)와 Learning Better Reasoning for GR with SIDs(2609.29973): 같은 저자군(Mengdan Zhu·Yufan Zhao 등)의 두 편이다. SID(semantic ID, 아이템을 계층 코드로 표현한 것) 기반 GR의 reasoning trace 학습을 개선하는 학술 방법론이며, 프로덕션 A/B가 없다.
• ScalarLens(2609.29182): Criteo dataset을 쓴 numerical embedding 방법론이다. 학술 벤치마크만 있다.
• Fair Feed Ranking for Participatory Budgeting(2609.29819): Consul Democracy 플랫폼(참여 예산 편성 도구)의 제안 노출 순서를 다룬다. 저장소 관측 대상 밖이다.
• Cross-Country Code-Mixing for GR(2609.28972): cross-country e-commerce GR을 다룬 학술 방법론이다.
• SEEK(2609.29803): industrial search 평가 프레임워크다. 검색 평가 툴이며 랭킹 메커니즘 자체가 아니다.
• Decoupled Learning and Selection in Slate Rec(2609.29453): DP guarantee를 둔 slate(한 화면에 함께 보여 주는 아이템 묶음) recommendation을 다룬 학술 이론이다.
• 나머지 20건은 RAG·LLM eval·문서 검색·QA·비디오 검색 벤치마크·quantum GitHub·knowledge graph 등 이 저장소의 도메인(피드·랭킹·retrieval) 밖이다.

산업 블로그는 오늘(토요일) 훑는 대상이 아니다

배치 규칙상 산업 블로그는 월요일에만 훑는다. Meta·Netflix 블로그의 최신 글은 어제 확인한 상태에서 변화가 없다.

• engineering.fb.com의 최신 글은 2026-09-23 Private Processing to Meta AI Glasses다. 보안 주제의 글이며 건너뛰었다.
• netflixtechblog.com의 최신 글은 2026-09-18 Class Path다. JVM 인프라 주제의 글이며 건너뛰었다.

다음에 볼 것