X (Twitter)

한 줄 요약

2026-10-20 커밋(74d49a4, 4세대+45) 기준으로 X For You는 인네트워크 최신 포스트를 Thunder에서, OON 후보를 Phoenix retrieval, SimClusters, 2026-10-07부터 기본 on인 인기 포스트 소스에서 모으고, 레거시 tweet-mixer와 SID retrieval 소스는 기본 off다. Grok 기반 트랜스포머 Phoenix가 후보마다 행동별 참여 확률을 예측하고, 2026-09-24부터 공유 crate xai-value-model이 이 확률의 가중합에 작성자 다양성 감쇠와 OON 배수를 적용한다. 필터는 스코어링 전 20개와 선택 뒤 5개이고, 정렬된 후보는 VMRanker DPP 슬레이트 재정렬(θ=0.65, K=150, topic 요청은 생략)과 광고·팔로우 추천 블렌딩을 거쳐 나간다.

↑ 목차

공개 소스 4세대 — 이걸 먼저 알아야 나머지가 안 헷갈린다

X의 추천 코드 공개는 네 세대로 나뉜다. 1세대는 Scala/Java, 2세대는 Scala로 된 트위터 레포 코드이고, 3·4세대는 xAI 레포의 Rust/Python 코드다. 4세대부터는 가중치 파라미터 미러와 안전 파이프라인, 학습 코드도 함께 공개됐다 확인.

2026-09-10에 git 로그를 직접 확인했을 때 xai-org/x-algorithm의 커밋은 18개(전일 대비 +1: 49815da)였고, twitter/the-algorithm은 커밋 31개로 변화가 없었다 확인.

이 노트들은 4세대 공개(47c1bcd, 2026-08-13) 뒤에 나온 xai-org/x-algorithm 커밋에 4세대+1부터 차례로 번호를 붙여 부른다. 커밋별 상세 기록은 파일 끝 변경 이력에 있다.

네 가지 사실이 특히 중요하다.

1. 1세대와 2세대 사이에 26개월 공백이 있다. 2023-07-07 이후 2025-09-03까지 커밋이 하나도 없다 확인.

2. 2세대는 아무것도 지우지 않았다. 삭제 0건, 리네임 0건이다. 2023 파일 집합 6,906개는 2025 파일 집합 7,667개의 진부분집합이다. 즉 cr-mixer/, navi/, ann/, simclusters-ann/, src/, product-mixer/ 등은 2023-04 이후 한 바이트도 바뀌지 않은 채 그대로 남아 있다. 2025 커밋이 건드린 최상위 경로는 home-mixer/, tweet-mixer/, README.md뿐이고, 파일 수는 각각 603개, 384개, 1개다 확인.

   • 확인에 쓴 명령은 git show --name-only --pretty='' c54bec0 | awk -F/ '{print $1}' | sort | uniq -c다.

   레포에 파일이 있다고 해서 지금 쓰이는 코드라는 뜻은 아니다. 폐기는 파일 삭제가 아니라 README에서 그 줄을 빼는 방식으로만 드러난다. cr-mixer가 바로 그런 경우다. 2025 커밋의 유일한 문서 변경은 README의 cr-mixer 행에서 문구는 그대로 두고 서비스명만 tweet-mixer로 바꾼 것이다 확인 — git show c54bec0 -- README.md.

3. 3세대는 별개 레포다. xai-org/x-algorithm의 초기 3커밋(aaa167b→e414c17→0bfc279)은 코드를 다시 쓰고 grox/를 추가해 216파일에 이르렀다 확인.

4. 4세대는 3세대의 성격을 바꿨다. 3세대까지는 "로직의 형태만 공개, 값·배선·안전규칙 미공개"였지만, 4세대는 다음 세 가지를 공개했다 확인 — README.md #latest-update--august-13th-2026.

   • 가중치와 상수의 프로덕션 크론 미러를 home-mixer/params/param.rs로 공개했다 확인 — 같은 README.
   • visibility-filtering/과 labeling 서브레포 15개로 안전 파이프라인 전체를 공개했다 확인 — 같은 README.
   • phoenix/에 학습 코드와 합성 데이터를 넣어 end-to-end로 실행할 수 있게 했다 확인 — 같은 README.

   상세 분석은 daily/2026-08-15.md에 있다.

↑ 목차

용어

↑ 목차

피드 지면

이 문서가 주로 다루는 피드 지면은 알고리즘이 추천하는 For You다. For You 안의 세로 영상 캐러셀은 2026-10-08 커밋(4세대+38)에서 기본 off로 신설됐다 확인(변경 이력의 4세대+38). 2026-10-15 커밋(4세대+42)에서 캐러셀 정렬 점수에 immersive 지면 모델의 VQV 예측 항이 더해졌지만, 그 가중 기본값이 0.0이라 기본 동작은 그대로다 확인(변경 이력의 4세대+42). 2026-10-17 커밋(4세대+44)부터는 캐러셀 안의 중복 제거 세 가지가 기본 on이고, 같은 응답에 Who-to-Follow 모듈이 있으면 캐러셀을 넣지 않는다 확인(변경 이력의 4세대+44). 2026-10-20 커밋(4세대+45)부터는 메인 피드 상위 35개에 이미 든 영상과 같은 미디어를 캐러셀에서 빼고, 캐러셀 자체는 이 커밋 기준으로도 기본 off다 확인(daily 2026-10-21). Thunder에 구현된 비디오 전용 경로는 공개되지 않은 별도 지면(Reels 상당)이 켜서 쓴다 추정.

• For You는 이 문서의 주 대상인 알고리즘 추천 피드이고, gRPC 메서드는 get_for_you_feed와 get_for_you_feed_urt다 확인 2026 — home-mixer/server.rs:273-346
• For You 피드 6번째 자리에 세로 영상 3~5개를 묶어 넣는 세로 영상 캐러셀 모듈이 2026-10-08 커밋(4세대+38)에서 기본 off로 신설됐다 확인 — home-mixer/util/video_carousel.rs
  • 기본 off는 home-mixer/params/param.rs의 EnableVideoCarousel = false다.
  • For You 요청에서만 켜지고, 직전 캐러셀 노출 후 60분(VideoCarouselFatigueMinutes)이 지나야 다시 나온다.
  • 넣는 자리는 피드 6번째(VideoCarouselPosition)다. 세로 영상은 가로/세로 비가 1.0 미만인 영상이다.
  • 2026-10-15 커밋(4세대+42)부터 정렬 점수는 video_open 가중과 immersive 지면 모델(GalleryPage)의 VQV 예측 가중을 더한 값이다. VQV 가중 기본값이 0.0이라 기본 동작은 video_open 순 그대로다 확인 — home-mixer/util/video_carousel.rs:104-123.
  • 2026-10-17 커밋(4세대+44)부터 캐러셀 안의 중복 제거 세 가지(같은 작성자, SID 앞 3단계 일치, 멀티모달 임베딩 코사인 0.72 이상)가 기본 on이다 확인 — params/param.rs:1095-1112.
    • 같은 커밋부터 같은 응답에 Who-to-Follow 모듈이 있으면 캐러셀을 넣지 않는다(파라미터 없음) 확인 — selectors/blender_selector.rs:50, 156-161.
    • 캐러셀 자체(EnableVideoCarousel)는 2026-10-20 커밋(74d49a4)에서도 기본 off다 확인 — params/param.rs:1102.
  • 2026-10-20 커밋(4세대+45)부터 캐러셀은 메인 피드 상위 35개와 같은 미디어 ID나 MD5 해시를 가진 영상, 캐러셀 안에서 앞서 고른 영상과 같은 미디어를 건너뛴다(파라미터 없음) 확인 — util/video_carousel.rs:52-108.
    • 메인 피드 범위는 캐러셀 후보 풀과 같은 경계(RESULT_SIZE)로 자른다 — filters/video_carousel_filter.rs:26-29. 세부는 daily 2026-10-21에 있다.
  • 신설 시점(4세대+38, 2026-10-08)에는 세로 영상을 video_open 예측 확률 순으로 묶었다.
  • 자세한 선정 경로는 변경 이력의 4세대+38에 있다.
• Following은 인네트워크 포스트만 다루고, 2026-10-17 커밋(862a123) 기준으로 For You와 별도인 gRPC 서비스와 후보 파이프라인을 갖는다 확인 — home-mixer/lib.rs
  • 서비스는 FollowingFeedService와 RankedFollowingFeedService이고, 파이프라인은 following_candidate_pipeline.rs, ranked_following_candidate_pipeline.rs, reverse_chron_posts_pipeline.rs다. 4세대 공개(47c1bcd)에도 같은 구성이 있었다 확인 — home-mixer/server.rs:522-680, home-mixer/candidate_pipeline/
  • 두 Following 서비스는 쿼리를 만든 뒤 in_network_only를 true로 둔다 확인 — home-mixer/server.rs:555, 658
  • 중요: For You 요청이라도 사용자가 allow_for_you_recommendations = false이면 서버가 요청을 in_network_only로 강등한다 확인 — home-mixer/server.rs:96-97
  • Phoenix에 들어가는 product_surface 값도 이 플래그에 따라 HomeTimelineRankedFollowing과 HomeTimelineRanking으로 갈린다 확인 — home-mixer/scorers/phoenix_scorer.rs:86-90.
  • 3세대(0bfc279)에는 Following 전용 서비스가 없었고, 같은 파이프라인의 in_network_only 플래그로만 갈렸다 확인 — home-mixer/server.rs:75-76
  • 2026-08-18 커밋(4세대+3)에서 reverse-chron(Following) 전용 VF hydrator가 분기됐다 확인 — home-mixer/candidate_hydrators/vf_following_candidate_hydrator.rs
    • 새 hydrator는 신규 파일이고 95줄이다.
    • 다른 근거 위치는 home-mixer/candidate_pipeline/reverse_chron_posts_pipeline.rs:141-144다.
    • 이전에는 For You와 Following이 같은 VFCandidateHydrator를 썼다.
    • 새 hydrator는 Following 파이프라인에만 연결된다.
    • should_drop_ancillary 헬퍼는 기존 파일에서 pub(crate)로 재사용한다.
    • 새 hydrator는 VF 조회 결과(visibility_reason, drop_ancillary_posts)만 반환하고, 나머지 후보 필드는 ..Default::default()로 재설정한다.
    • 즉 Following 파이프라인은 하이드레이션 산출이 VF 결과 두 개로 줄고, 나머지 필드는 다른 하이드레이터가 채우는 구조로 분리됐다.
    • VF의 SafetyLevel은 TimelineHome 그대로다. Following과 For You가 안전 레벨은 공유한다.
    • 의미: 이 커밋으로 For You와 Following의 하이드레이션 필드 세트가 명시적으로 갈렸고, 이는 Following에서 쓰지 않는 후보 필드에 로직과 리소스를 들이지 않으려는 최적화 방향이다 추정
• 토픽 피드는 topic_ids가 붙은 요청이고, 토픽 id가 7개 이상(> 6)이면 "bulk topic request"로 취급해 후보 소스가 달라진다 확인 2026 — home-mixer/models/query.rs:201-203
• 비디오 지면: Thunder에는 비디오 전용 ring buffer와 is_video_request 경로가 완전히 구현돼 있지만, 공개된 유일한 호출자는 is_video_request: false로 하드코딩한다 확인(코드) — thunder/thunder_service.rs:287
  • 다른 근거 위치는 home-mixer/sources/thunder_source.rs다.
  • 구현이 다 갖춰져 있고 stub이 아니므로, 공개되지 않은 별도 지면(Reels 상당)이 이 플래그를 켜서 쓴다 추정.

↑ 목차

후보 생성 (retrieval)

후보 생성(retrieval)은 랭킹에 넘길 포스트를 여러 소스에서 모으는 단계다. 2026 파이프라인은 소스들을 병렬로 돌려 결과를 그대로 이어 붙이고, 인네트워크와 OON 사이의 할당 비율 대신 소스별 상한을 둔다 확인(후보 배분 절). 2026-10-07 커밋(4세대+37)부터는 오프라인 잡이 미리 만든 인기 포스트 목록을 내는 소스가 기본 on이다 확인(변경 이력의 4세대+37). 2026-10-02~03 커밋(4세대+34~35)이 공개한 SID generative retrieval 소스는 기본 off다 확인(4세대+34, 4세대+35).

현행 (2026-08 4세대)

4세대 공개 기준으로 For You의 후보 소스는 내부 Phoenix 파이프라인 소스 7개와 외부 For You 파이프라인 소스 5개, 모두 12개다 확인. 근거는 home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs, for_you_candidate_pipeline.rs, 그리고 home-mixer/params/param.rs의 EnableXxxSource 기본값이다.

같은 기준에서 기본 on으로 확인된 retrieval 소스는 인네트워크 최신 포스트를 내는 Thunder와, OON 후보를 내는 Phoenix retrieval·SimClusters다 확인. 표의 SID 소스와 인기 포스트 소스는 그 뒤 2026-10-02~03 커밋(4세대+34~35)에서 추가됐다 확인(아래 세부). 표의 값은 4세대 공개 기준이지만, 이 두 소스의 행과 PhoenixSource의 cold 슬라이스 상한은 그 뒤 커밋에서 추가된 항목이다.

표에서 줄인 세 소스의 세부는 다음과 같다.

• 2026-09-18 커밋(4세대+25)에서 PhoenixSource에 cold-start 슬라이스가 dataset_type 태그로 first-class로 연결됐다 확인(콜드스타트 절).
  • 응답 후보의 dataset_type == HOME_COLD_DATASET_TYPE(=13)이면 served_type이 ForYouPhoenixRetrievalCold이고, 그 외는 기존 ForYouPhoenixRetrieval이다.
  • 이 슬라이스의 상한 PhoenixColdStartMaxResults는 4세대+25에서 0(기본 off)으로 신설됐고, 2026-09-30 커밋(4세대+32)부터 200이다 확인 — params/param.rs:16. 2026-10-17 커밋(862a123)에서도 200이다.
• SidSource는 2026-10-02~03 커밋(4세대+34~35)에서 공개된 SID generative retrieval microservice를 부른다 확인(4세대+34, 4세대+35).
  • 유저의 positive engagement post ID들을 seed로 넘기면, 서비스는 세 단계로 후보를 만든다.
    1. seed를 6-level 코드로 바꾼다. seed post가 로컬 SID 트라이에 있으면 트라이에서, 없으면 외부 SidLookupService에서 찾는다.
    2. seed마다 max_prefix_depth에서 min_prefix_depth까지 깊이가 깊은 순으로 공유 접두사 범위에서 후보를 뽑는다. 이미 더 깊은 수준에서 소비된 범위는 뺀다.
    3. 모든 seed의 후보 리스트를 round-robin 인터리브하고, 중복을 제거해 돌려준다.
  • seed는 simclusters_source::post_signal_ids와 같은 함수를 재사용해 유저 engagement 신호에서 뽑는다.
  • 각 Candidate에는 shared_prefix_depth가 점수로 담긴다.
  • 응답 후보는 served_type=ForYouPhoenixRetrievalMoe로 라벨된다. PhoenixMOE와 같은 라벨이다.
  • 호출에는 300ms gRPC 데드라인이 걸리고, 연결 경로는 xDS P2C → DNS 폴백의 2-경로다.
  • 서버는 parquet 스냅샷(post_sid_snapshot.parquet, 컬럼 post_id/author_id/post_sid)을 30초마다 폴링해 전부 다시 적재한다.
  • 트라이는 by_key(prefix 범위 이진탐색용)와 by_post(seed lookup용) 두 벡터로 이뤄진다.
  • 서버 측 상한은 max_results=800 / max_per_seed=100 / min_prefix_depth=3 / max_prefix_depth=6 / max_seeds=200이고, 하드캡은 MAX_RESULTS_CAP=5000 · MAX_PER_SEED_CAP=2000 · MAX_CALLER_LEN=64다.
• PopularPostsSource는 2026-10-03 커밋(4세대+35)에서 생겼고, 2026-10-06 커밋(4세대+36)에서 구조가 전면 교체됐다 확인(4세대+35, 4세대+36).
  • 교체된 구조에서는 요청 시점에 Thunder를 부르지 않는다. 오프라인 잡 두 개가 미리 만든 인기 포스트 목록(최대 500개)을 Manhattan KV에서 60초마다 읽어 오고, 유저가 이미 본 포스트(seen_ids)만 빼고 그대로 후보로 낸다.
  • 첫째 잡 popular_authors_job(1시간 주기)은 BigQuery 스냅샷에서 최근 7일 안에 글을 쓴 작성자 중 팔로워 수 상위 0.005%(TOP_POSTING_AUTHORS_FRACTION=0.00005)를 뽑는다.
  • 둘째 잡 popular_posts_job(5분 주기)은 그 작성자들의 원본 포스트(답글·리트윗 제외)를 Thunder에서 모은다. 24시간 이내 포스트의 조회수를 engagement counts에서 받아 점수를 매긴 뒤, 작성자당 5개, 전체 500개로 자른다.
    • 점수 식은 quality = views × (1−e^{−λ·24h}) / (1−e^{−λ·max(age,0.5h)})(반감기 8시간)이다.
  • 라벨은 2026-10-16 커밋(4세대+43)부터 자체 served type ForYouPopularPosts이고, 그 전까지는 ForYouPhoenixRetrieval이었다(popular_posts_source.rs:13).
  • 캐시 재사용 요청과 in_network_only 요청에서는 꺼진다(popular_posts_source.rs:27-31).
  • 4세대+35에 있던 PopularPostsTopAuthors·PopularPostsMaxPerAuthor·PopularPostsMaxRepliesRepostsPerAuthor는 삭제됐고, 잡 CLI 인자(--popular-posts-per-author=5, --popular-posts-budget=500, --popular-posts-half-life-hours=8)로 옮겨졌다.
  • 저장 포맷 v1은 13바이트 헤더 뒤에 포스트마다 24바이트(post_id·author_id·quality)가 붙는 구조다.

Thunder는 2026에 새로 만든 인네트워크 인덱스다. Earlybird 검색 인덱스를 대체한다 추정. 근거는 역할이 같고 Earlybird 참조가 사라졌다는 점이다.

• 포스트는 DashMap<post_id, LightPost>에 담고, 작성자마다 ring buffer 3개(원본, 답글·리트윗, 비디오)를 둔다 확인 — thunder/posts/post_store.rs:20-53
• LightPost에는 텍스트도 미디어도 참여수도 안전라벨도 없다 확인 — thunder/kafka/tweet_events_listener.rs:230-248
  • 들어 있는 필드는 post_id, author_id, created_at, in_reply_to_*, is_retweet, is_reply, source_*, has_video, conversation_id뿐이다.
• Thunder 안의 랭킹은 일부러 recency 정렬 한 줄로 뒀다. Phoenix가 어차피 다시 매기기 때문이다 확인 — thunder/thunder_service.rs:334-339
• 기본 보존 기간은 2일이다 확인 — post_store.rs:521-526
• 과부하가 걸리면 요청을 큐에 넣지 않고 즉시 거절한다 확인 — thunder_service.rs:160-171
  • try_acquire가 실패하면 resource_exhausted가 된다.
• 답글 노출 규칙은 코드에 명시된 제품 정책이다 확인 — post_store.rs:291-315
  • 부모가 원본이면 통과한다.
  • 부모가 원본이 아니면, 부모가 대화 루트에 대한 직접 답글이면서 답글 대상이 내 팔로잉일 때만 통과한다.
  • 부모가 스토어에 없으면 그냥 버린다. 그래서 2일 지난 스레드 루트가 만료되면 그 밑 답글이 전부 안 보인다.
• 자기 자신의 리트윗은 hot path의 한 줄로 막는다 확인 — post_store.rs:287-289

2023 세대에서 살아남은 retrieval은 tweet-mixer와 SimClusters다. tweet-mixer는 기본 off로 미러링돼 있고, SimClusters는 부활했다. ⚠ 주장 변경 (2026-08-13): canon은 오랫동안 "SimClusters, TwHIN, UTEG/GraphJet, FRS, Earlybird, Lists, Communities — 이 이름들은 home-mixer/ 어디에도 안 나온다"고 명시해 왔다. 4세대 공개는 simclusters/ 서브레포를 홈믹서 OON retrieval 소스로 다시 들여왔다(EnableSimclustersSource=true 기본 on). TwHIN/UTEG/GraphJet/FRS/Earlybird/Lists/Communities는 4세대에도 없다 확인 — home-mixer/params/param.rs, README.md #candidate-sources

SimClusters 코어 알고리즘의 세부(SVD 파이프라인, k, 인덱스 형식, 업데이트 주기)는 심층 분석이 필요하다. simclusters/ 서브레포는 파일 목록만 확인했고, 개별 파일은 읽지 않았다. 심층 분석이 필요한 항목은 daily/2026-08-15.md의 목록에 있다.

후보 배분 — 비율이 아니라 소스별 상한

"인네트워크 50% / 아웃오브네트워크 50%"는 할당량이 아니다.

2026 파이프라인에는 allocator도, ratio 파라미터도, 전역 상한도 없다 확인 — candidate-pipeline/candidate_pipeline.rs:257-272

• 소스들을 join_all로 병렬 실행하고, 결과를 그냥 이어 붙인다.
• 에러가 난 소스는 조용히 사라진다.

각 소스가 FeatureSwitch 파라미터에서 읽는 max_results 값은 4세대 공개(2026-08-13)에서 프로덕션 크론 미러로 공개됐다 확인 — home-mixer/params/param.rs

• ThunderMaxResults = 1200
• PhoenixMaxResults = 1000
• TweetMixerMaxResults = 800. 단 EnableTweetMixerSource = false로 기본 off다.
• PhoenixMOEMaxResults는 해당 param을 확인해야 한다.

2026 파이프라인에서 인네트워크와 OON의 비중을 조절하는 수단은 retrieval이 아니라 스코어링의 배수다 확인 — home-mixer/scorers/ranking_scorer.rs:220-239, 272-275

let final_score = match c.in_network {
    Some(false) => after_diversity * effective_oon,
    _ => after_diversity,
};

effective_oon은 세 갈래로 계산되고, 그 값은 4세대 공개에서 전부 공개됐다 확인 — home-mixer/params/param.rs:247,269,275

일반화 노트는 candidate-allocation.md에 있다.

레거시 (2025 Scala, tweet-mixer)

tweet-mixer는 2025-09-03에 파일 384개로 한꺼번에 등장했다. README도 .md 파일도 하나 없어서 모든 사실을 코드에서만 확인해야 한다 확인.

이 세대에서 새로 들어온 retrieval 계열은 다음과 같다.

• DeepRetrieval 관련 파일이 19개 새로 생겼다(2023 스냅샷에는 0개) 확인
• SimClusters를 소비하는 새 파일이 20개 생겼고, SimClusters 코어 자체는 2023 그대로다 확인 — git show --diff-filter=M c54bec0 | grep -ci simclusters = 0
  • 새 파일에는 SimclusterColdPostsCandidateSource.scala가 들어 있다.
  • 코어는 src/scala/com/twitter/simclusters_v2와 simclusters-ann/이다.
  • 즉 엔진은 고치지 않고 소비 지점만 늘렸다.
• Earlybird를 소비하는 파일이 15개 새로 생겼고, 인덱스 본체(src/java/com/twitter/search)는 바뀌지 않았다 확인
• Hydra는 2023 cr-mixer에 thrift 클라이언트로 이미 있었고, 2025에 scorer와 embedding generation service로 승격됐다. "Hydra는 2025 신규"는 틀린 말이다 확인

SimClusters, TwHIN, DeepRetrieval 각각의 임베딩 생성·인덱스·조회 방식과 그 안에서 발견한 코드 결함은 embedding-retrieval.md에 정리했다.

↑ 목차

랭킹

4세대 공개(2026-08-13) 기준으로 X For You의 랭킹 모델 Phoenix는 후보 포스트마다 좋아요, 답글, 신고 같은 행동이 일어날 확률을 예측한다 확인(Phoenix 절). 같은 공개 기준으로 점수는 이 확률에 행동별 가중치를 곱해 더한 값에서 출발하고, 오프셋을 거친 뒤 작성자 다양성 감쇠, OON 배수, 새 작성자 부스트를 차례로 적용한다 확인(Phoenix 절, 새-작성자 부스트 절). 2026-09-24 커밋(4세대+28)부터 이 계산은 공유 crate인 xai-value-model이 맡고, 홈믹서의 랭킹 스코어러 파일은 삭제됐다 확인(Phoenix 절). 같은 공개의 param에서는 VMRanker의 DPP 슬레이트(사용자에게 함께 내보내는 후보 묶음) 재정렬도 켜져 있다 확인(Phoenix 절의 VMRanker 표). 가중치 값은 이 공개부터 프로덕션 기본값을 매일 옮겨 오는 크론 미러로 레포에서 읽을 수 있고, 2026-10-14 커밋(4세대+41)까지 일부 미러 값이 바뀌었다 확인(가중치 절, 변경 이력의 4세대+41).

Phoenix (2026, 현행) — 4세대 공개 반영

Phoenix는 Grok-1을 포팅한 트랜스포머다. 유저 이력과 후보를 한 시퀀스에 넣고 한 번에 채점한다. 구조, 마스크, 파라미터 분포는 sequence-transformer-ranking.md에 정리돼 있다.

예측 헤드는 문서 기준 24개이고, 카테고리 5개로 나뉜다 확인 — README.md #scoring-and-ranking (2026-08-13). 표는 이 README 기준이고, 그 뒤 빠지거나 새로 생긴 가중치 항은 가중치 표에 있다.

체류 시간을 다루는 click dwell time 헤드와 dwell time 헤드는 공개 뒤에 학습 방식이나 랭킹 항이 바뀌었다 확인(변경 이력의 4세대+22, 4세대+23, 4세대+38).

• 2026-09-16 커밋(fad2f71, 4세대+22)에서 click dwell time 헤드가 sigmoid BCE(threshold=10s) 이진 분류로 학습되기 시작했다 확인(변경 이력의 4세대+22). 그 전의 공개 학습 코드에는 이 헤드의 손실 설정이 없었다 확인 — 2d4a03c phoenix/xrex grep.
  • 헤드 이름은 click_dwell_time이다.
  • 서빙 헤드는 확률 [0,1]로 남는다. _rescale_sigmoid_heads_for_inference가 binary 예외로 원단위 복원을 건너뛴다.
• 2026-09-17 커밋(42266f3, 4세대+23)에서 click dwell의 랭킹 항이 재정의됐다 확인(변경 이력의 4세대+23).
  • 4세대 공개(47c1bcd)부터 있던 EnableClickDwellLowFavRatePenalty가 전부 삭제됐다(param.rs:387-416). 이 heuristic은 baseline·alpha·floor·cap 4개 튜닝 param과 (fav/baseline)^alpha를 써서, fav가 저조할 때 dwell 예측을 낮췄다.
  • 그 자리에 새 파라미터 EnableCdwellOnImpr(기본 off)가 들어왔다. 켜면 click_dwell_term = click_dwell_time × click_score로 계산한다. click dwell 항을 임프레션당 기대 dwell로 재정의한 것이다.
  • ContClickDwellTimeWeight는 미러상 바뀌지 않았다.
• 2026-10-08 커밋(35650fb, 4세대+38)에서 dwell_time 헤드의 학습 손실이 Tweedie·MAE에서 CREAD로 바뀌었다 확인 — phoenix/xrex/configs/xrecsys.py:272-275, 715-742.
  • 새로 켜진 CREAD 손실은 체류 시간을 로그 간격 임계 30개(2초~상한) 초과 여부의 이진 분류로 학습한 뒤, 기댓값으로 복원한다.
  • 홈 기본 학습 config에서 CREAD 손실 두 개가 각 0.1로 켜졌다. 상한은 일반 지면 120초, 갤러리/몰입형 지면 240초다.
  • 같은 config에서 Tweedie(0.1)·MAE(0.1) 가중치는 0이 됐다.
  • 서빙 헤드 이름과 랭킹 가중치(ContDwellTimeWeight)는 그대로다.

README 카테고리에는 없지만 점수에 기여하는 param이 2개 더 있다. 총 유효 weight param은 26개다.

• QuotedVqvWeight는 인용 포스트의 video quality view 가중치다. README 카테고리에는 없으나 param은 존재한다.
• PostUnexploredWeight는 새 작성자 부스트다. 자세한 내용은 새-작성자 부스트 절에 있다.

canon이 오래 관찰한 "레포 안에서 헤드 수가 세 가지로 갈린다(공개 체크포인트 19 / 랭킹 스코어러 22 / VMRanker proto 21)"는 3세대까지의 사실이다. 4세대 README가 문서 기준으로 24로 명시하고, home-mixer/params/param.rs의 weight 심볼도 25(prediction head) + 1(post_unexplored heuristic)로 정리됐다. 다만 3세대에서 관찰됐던 candidate_pipeline/candidate.rs의 죽은 19필드 PhoenixScores 구조체가 4세대에서 정리됐는지는 심층 분석이 필요하다. 확인(문서) / 추정(코드 정리 여부)

헤드 설계를 일반화한 내용은 multi-task-ranking.md에 있다.

4세대 공개(47c1bcd) 기준으로 최종 점수는 다음 순서로 계산했다 확인 — home-mixer/scorers/ranking_scorer.rs.

1. 26개 weight × P(head)를 가중합한다. negative_sum은 부호를 뒤집어 뺀다.
   • 상호팔로우 원본 포스트에 한해 reply 가중치에 BidirectionalFollowReplyWeightBoost=15.0을 더한다. 조건은 !in_reply_to && !retweeted && is_mutual_follow_author다.
2. offset_score를 적용한다. 점수가 음수면 (score + negative_sum) / total_sum * NEGATIVE_SCORES_OFFSET, 양수면 score + NEGATIVE_SCORES_OFFSET이다.
3. 작성자 다양성 감쇠를 곱한다. 같은 작성자의 k번째 등장에 (1-0.25)*0.5^(k-1) + 0.25를 곱하므로 첫 등장은 1.0배다.
   • 지수는 그 작성자가 앞서 나온 횟수다(ranking_scorer.rs:614-615, 635).
   • 설정은 AuthorDiversityDecay=0.5, AuthorDiversityFloor=0.25, EnableAuthorDiversity=true다.
4. OON 배수 OonWeightFactor=0.75를 곱한다. 토픽 요청이면 TopicOonWeightFactor=0.5를 쓴다.
5. 새-작성자 부스트를 적용한다.

3세대 코드(0bfc279)에 있던 normalize_score 정규화 단계는 4세대 공개의 ranking_scorer.rs에 없다 확인 — ranking_scorer.rs:4, 259.

2026-09-24 커밋(4세대+28, 44d37eb)에서 ranking_scorer.rs가 삭제됐고, 가중합과 offset, 작성자 다양성 감쇠, OON 배수 계산은 공유 crate xai-value-model로 옮겨졌다 확인 — xai-value-model/scoring.rs.

• 2026-10-17 커밋(862a123) 기준 스코어러 체인은 PhoenixScorer, ImmersiveVideoScorer, VMRanker 순이다 확인 — phoenix_candidate_pipeline.rs:487-488.
  • 4세대 공개 때의 체인은 vec![phoenix_scorer, ranking_scorer, vm_ranker]였다(phoenix_candidate_pipeline.rs:395-396).
• 같은 기준에서 홈믹서의 VMRanker 스코어러는 로컬 가중합(fuse_heads)과 새-작성자 조정을 먼저 계산하고, vm-ranker 서비스가 돌려준 점수로 덮어쓴다 확인 — home-mixer/scorers/vm_ranker.rs:59-131.

영상 길이와 쿼리의 유저 팔로워 수에 따라 vqv 가중치를 0으로 바꾸는 heuristic은 4세대 공개부터 레포의 home-mixer/util/candidates_util.rs에 있다 확인 — candidates_util.rs:19-60.

• 관련 식별자는 vqv_weight, quoted_vqv_weight, MinVideoDurationMs 임계다. vqv_weight는 영상 길이가 MinVideoDurationMs를 넘고 query.user_features.follower_count가 10,000 이상이 아닐 때 가중치를 그대로 쓴다. 팔로워 수가 비어 있어도 가중치를 쓴다(candidates_util.rs:4, 25-38).
• 4세대 공개에서는 ranking_scorer.rs:230이 이 함수를 호출했다.

VMRanker와 DPP의 설정값이 이제 공개됐다 확인 — home-mixer/params/param.rs:579-618. 표의 값은 4세대 공개 시점의 것이고, VMRankerClusterId만 2026-10-06 값이다.

• VMRankerClusterId는 "Experiment3"에서 출발해 중간에 여러 번 바뀌었다. 4세대+35에서 "Experiment6", 4세대+36(2026-10-06)에서 "Experiment1"이 됐다 확인.
• 2026-09-24 커밋(4세대+28)에서 DPP 설정은 홈믹서 param.rs에서 빠져 vm-ranker/params.rs로 옮겨졌다. 2026-10-17 커밋(862a123) 기준으로 그 파일의 값은 DppEnabled=true, DppTheta=0.65, DppMaxSelectedRank=150, TopicDppEnabled=false다 확인 — vm-ranker/params.rs:235-248.

VMRanker 서비스 본체는 4세대 공개부터 vm-ranker/에 있다 확인 — vm-ranker/ranker_service.rs.

• 같은 디렉토리에 main.rs, DPP 구현인 dpp.rs, scoring/dpp_model.rs가 있다 확인 — vm-ranker/.
• 2026-09-23 커밋(4세대+27)에서 scoring/value_model.rs, params.rs, config_sync.rs가 더해졌다 확인 — vm-ranker/.
• VMRanker 응답이 후보의 score를 덮어쓰는 구조는 3세대부터 그대로다 확인 — vm_ranker.rs:116-131.
• gRPC 호출이 실패하면 2026-09-24 커밋(4세대+28)부터 DPP 없이 로컬 가중합 점수를 내보내고, 실패를 VMRanker.local_score_fallback 메트릭으로 센다 확인 — vm_ranker.rs:107-113, 170-178.
  • 그 전에는 실패하면 모든 후보에 Err를 돌려줬다(vm_ranker.rs:44-66).

2026-08-18 커밋(4세대+3)에서 VMRanker 요청에 SID(semantic ID) 필드 7개가 새로 연결됐다 확인 — home-mixer/scorers/vm_ranker.rs:194-206:

• 이 필드들이 기존 필드와 나란히 후보 소스별로 전달되면서, VMRanker가 아이템 다양성 판정에서 collaborative pool rank뿐 아니라 semantic ID 계층 위치를 볼 수 있게 됐다.
  • 기존 필드는 k, pool_rank, pool_rank_gap이다.
  • VMRanker는 레거시 이름을 유지하지만 이제 DPP 슬레이트 재정렬을 담당한다.
  • Kuaishou HD-Rec/PushDualGen에서 관찰된 SID 계열에 대응하는 X 쪽 연결이다 추정.
• 의미: VMRanker의 다양성 판단은 이제 후보 소스별 rank, 3-level semantic ID codeword, 이웃 gap의 3축 정보를 갖는다.
  • 3레벨 코드북 계층(coarse → fine)이 있다는 사실 자체가 새로 확인된 아키텍처 정보다.
  • 이 연결은 Phoenix retrieval의 SID window와 같은 SID 인프라를 rank/rerank 쪽에서 소비하는 자리다. SID window(video_14day·video_48h 등)는 Phoenix 학습·인덱스 절의 4세대+1 항목에 있다.
• 미공개: 다음은 공개되지 않았다.
  • SID 코드북 정의(각 level의 vocabulary 크기·훈련 방식)
  • sid_gap의 정확한 계산식
  • VMRanker 응답 로직에서 이 필드들이 어떻게 활용되는지

새-작성자 부스트 (New-Author Boost) — 4세대에서 문서화된 세 번째 조정 인자

새-작성자 부스트는 노출이 기준치보다 적은 작성자의 포스트를 목표 위치 쪽으로 끌어올리는 조정 인자다. README는 이렇게 설명한다.

"New-Author Boost: posts from authors whose impressions are below a threshold are lifted toward a target position."

새 README는 스코어링 조정 인자를 세 개로 명시한다 확인 — README.md #scoring-and-ranking.

1. Author Diversity Decay
2. Out-of-Network Discount
3. New-Author Boost

이 부스트를 정하는 param은 아래 표와 같다 확인 — home-mixer/params/param.rs:351-374, #coldstart-threshold.

ColdStartImpressionThreshold는 2026-09-30 커밋(4세대+32)에서 1000에서 200으로 내려갔다 확인 — params/param.rs:459(변경 이력의 4세대+32). 2026-10-17 커밋(862a123)에서도 200이다.

• 이 임계를 쓰는 콜드스타트 슬롯 선택기는 후보 포스트의 view_count_on_home이 임계보다 작은 후보만 고른다 확인 — author_cold_start.rs:293-294.
• 4세대 공개 코드도 후보 포스트의 view_count로 같은 비교를 했다 확인 — author_cold_start.rs:179.

canon이 콜드스타트 절에서 "신규 아이템: 2026 코드에 아무 장치가 없다"고 관찰했던 것은 3세대까지의 사실이다. 4세대에서 새 작성자(계정 단위) 부스트가 문서화됐다. 4세대 공개 기준으로는 개별 새 포스트(아이템 단위)에 붙는 부스트가 없었고, hash embedding 충돌 문제도 그대로였다 확인. 그 뒤의 포스트 단위 장치는 콜드스타트 절에 있다.

가중치 — 4세대 릴리스로 값이 공개됐다 (⚠ 주장 대량 변경, 2026-08-13)

결론 (2026-08-15 갱신): 가중치 값은 프로덕션 크론 미러로 공개됐다. 미러 파일은 home-mixer/params/param.rs다. 이전 판의 결론 "가중치 값은 어느 세대에서도 1차 출처가 없다"는 4세대 공개로 뒤집혔다. 이 절이 이 문서에서 제일 중요하다.

새 결론은 프로덕션 primary value를 매일 sync한 미러가 존재하고, 마지막 sync 시각은 파일 헤더에 명시된다는 것이다.

파일 헤더가 이 미러의 성격을 규정한다 확인 — home-mixer/params/param.rs:1:

// mirrored from config feature-switch defaults; last sync 2026-08-12T04:09:22Z

README가 미러링의 의미를 명시한다 확인 — README.md #experiments-and-configuration:

"To help people understand the production defaults, we run cron scripts that set the defaults in this repository's code to be the primary production values"

엔게이지먼트 헤드 가중치는 아래 표와 같다(파일 등장 순, 2026-08-12 sync) 확인.

• click·vqv·dwell·cont_click_dwell_time 칸의 나중 값은 home-mixer/params/param.rs와 vm-ranker/params.rs에서 확인했다 확인. vqv와 dwell은 0d3cdd8의 param.rs:342, 356에서, click과 cont_click_dwell_time은 a707cc2의 param.rs에서 처음 바뀌었다.

상호팔로우 부스트는 2026-07에 도입돼 2026-07-24에 조정됐다 확인 — docs/BIDIRECTIONAL_BOOST_CHANGE.md.

reply 부스트 값은 세 단계를 거쳐 정해졌다 확인 — 같은 문서.

• 2026-07-10: 5/10/15/20으로 A/B를 시작했다 확인 — 같은 문서.
• 07-13: 20으로 롤아웃했다 확인 — 같은 문서.
• 07-24: 20에서 15로 내렸다. 월드컵 시즌 유저 피드백을 반영한 조정이다 확인 — 같은 문서.

부스트 대상인지는 아래 함수가 판정한다 확인 — home-mixer/scorers/ranking_scorer.rs:

fn bidirectional_boost_eligible(candidate: &PostCandidate) -> bool {
    candidate.in_reply_to_tweet_id.is_none()
        && candidate.retweeted_tweet_id.is_none()
        && candidate.is_mutual_follow_author == Some(true)
}

즉 원본 포스트에 한해서만 reply 가중치가 5.0에서 20.0이 된다. 답글과 리트윗은 부스트 대상이 아니다.

부정 헤드 가중치는 아래 표와 같다 확인.

파일 자체 주석이 가중치 부호와 크기의 의미를 규정한다 확인:

"These weights reflect a combination of how much an action is valued in ranking and typical propensities of these actions across the X network (e.g. negative feedback is overall rare)."

즉 report −234의 크기는 "리포트 한 번의 상대 중요도"가 아니라 가치 × 1/propensity의 곱이다. 여기서 propensity는 그 행동이 X 네트워크 전체에서 보통 얼마나 일어나는지를 뜻한다. 리포트가 워낙 드물기 때문에 큰 절대값이 붙어 있다.

2026-08-14 커밋(4세대+1)은 이 해석 규칙을 코드 주석과 README에 명시했다 확인 — home-mixer/params/param.rs:281-306, home-mixer/scorers/ranking_scorer.rs:415-446, README.md #scoring-and-ranking:

"Each weight multiplies the predicted probability of that action (P(favorite), P(repost), …) or a continuous value e.g. watch time -- the weights do not multiply raw engagement counts. One common misinterpretation is that you can read these weight ratios as count equivalences, e.g. the incorrect statement that 'one report cancels 468 likes' -- this is incorrect because the weights apply to the predicted probabilities rather than raw counts. And the baseline probability of a Report is more than 1000x lower than a Like, so it's weighted more to allow the prediction to affect the final ranking at all." — home-mixer/params/param.rs:283-292

같은 주석은 "mass reporting으로 도달이 균일하게 억눌린다"는 오해도 두 가지 이유로 부정한다 확인 — 같은 주석 블록.

1. 스코어는 당신의 예측 확률에 곱하므로, 봇 계정의 리포트는 그 봇들과 유사한 유저의 추천에 주로 영향을 준다(개인화) 확인 — 같은 주석.
2. Home Timeline에 서빙된 포스트에서 이뤄진 액션만 랭킹 신호로 반영된다. 그룹채팅으로 링크를 공유해서 나타난 반응은 랭킹에 영향을 주지 않는다 확인 — 같은 주석.

가중치 미러의 caveat 다섯 가지

이 미러를 읽을 때 주의할 점이 다섯 가지 있다.

1. 크론 sync는 하루 단위로 따라가는 미러라 시차가 있다. 헤더에 적힌 sync 시각 이후의 프로덕션 변경은 아직 반영되지 않았을 수 있다. 확인
2. 부호와 크기는 propensity를 감안해 해석해야 한다. 파일 자체 주석이 "값 = 가치 × 1/propensity"라고 명시한다. 절대값 비율(report −234 vs favorite 0.5의 468배)이 그대로 상대 중요도가 아니다.
3. 2026-09-23 커밋(4세대+27)부터 가중치 미러가 두 파일로 나뉘었고, 2026-10-17 커밋 기준으로 두 파일의 가중치 값이 서로 다르다.
   • 4세대+27에서 56개 파라미터를 담은 vm-ranker/params.rs가 신설되면서, 홈믹서 프로세스용인 기존 home-mixer/params/param.rs와 함께 미러가 둘이 됐다 확인.
   • 다음날(4세대+28, 2026-09-24) 홈믹서 param.rs에서 가중치가 아닌 랭킹 파라미터 22개가 삭제됐다 확인 — 1b3fec20과 44d37eb의 param.rs 비교.
     • 삭제된 파라미터는 author diversity·OON·new-user·weight perturbation·VMRanker DPP·value model 스위치 계열 등이고, 가중치는 ContActiveSecs5mResidualNormWeight 하나뿐이다.
   • 행동별 가중치는 두 파일에 모두 남았고, 2026-10-17 커밋(862a123) 기준으로 favorite·video_open·cont_dwell_time·post_unexplored·not_interested 다섯 개 값이 서로 다르다 확인 — home-mixer/params/param.rs, vm-ranker/params.rs.
   • 공유 crate xai-value-model이 실물 파일로 공개되면서 두 프로세스가 같은 코드로 value model을 계산한다 확인. 다만 각 프로세스는 자기 쪽 파라미터 파일의 가중치를 읽는다 확인 — home-mixer/scorers/value_model.rs:8-51, vm-ranker/scoring/value_model.rs:68.
   • phoenix 학습 hyperparameter와 botmaker 규칙 상수는 여전히 레포 밖에 있다. 3세대 canon이 레포 밖이라고 본 crate::util은 4세대 공개부터 home-mixer/util/로 공개돼 있다 확인 — home-mixer/lib.rs.
4. Phoenix 학습 코드는 "학습 가능한" 것이지 "프로덕션과 같은" 것이 아니다. README는 규모가 다르다는 점을 이렇게 명시한다: "a small model can be trained and served end-to-end".
5. 일부 botmaker rules는 게이밍 방지 목적으로 공개되지 않는다. README가 이를 명시한다. visibility-filtering이 참조하는 라벨 중 일부는 규칙이 열려 있지 않다.

파라미터 변경을 문서화하는 관행 — 4세대에서 신설

파라미터 변경을 코드 diff로 문서화하는 관행은 4세대에서 생겼다. docs/BIDIRECTIONAL_BOOST_CHANGE.md가 앞으로 파라미터 변경을 코드 diff로 어떻게 문서화할지 보여 주는 견본이다 확인:

"Going forward, you'll see future algorithm updates published to this open source repository, and you should be able to understand what changed by checking the diffs."

같은 문서가 상호팔로우 부스트의 3단계 롤아웃(A/B 시작 → 광범위 롤아웃 → 파라미터 조정)을 코드 diff 3개로 재현해 보여 준다. 다른 회사(Meta·Netflix·YouTube 어디)에서도 지금까지 사례가 없던 문서화 방식이다.

이 저장소가 앞으로 X 커밋 로그를 매일 추적하는 일의 가치가 상당히 커진다. 다음 커밋에서 어떤 param이 어떻게 바뀌는지가 A/B 결과의 지연 지표가 된다.

세대 대비 — 왜 canon 이전 판이 "값 미공개"라고 명시했나

1·2·3세대에서는 실제로 값이 공개되지 않았고, 4세대가 이를 새로 열었다.

• 1세대 (2023 Scala): ScoredTweetsParam.scala:151의 object ModelWeights에 파라미터 17개가 있다. 기본값은 10개가 1.0, 7개가 0.0이고, 실제 프로덕션 값이 아니다. 범위 경계값(예: ReportParam −20000..0)은 상대 스케일 단서로만 유효하다.
• 2세대 (2025 Scala): HomeGlobalParams.scala:786으로 옮겨졌고, 파라미터는 17개에서 30개로 늘었다. 30개 전부 default = 0.0으로 의도적으로 삭제됐다. 상대 스케일 단서만 남았다.
• 3세대 (2026-01 Rust): params:: 모듈 자체가 레포에서 빠졌다. FavoriteWeight 같은 심볼은 호출부만 있고 정의가 없었다.
• 4세대 (2026-08 Rust): ⚠ home-mixer/params/param.rs로 실 프로덕션 미러를 공개했다.

널리 인용되는 "reply 13.5" 표는 여전히 2023-04-05 스냅샷 그대로다. 4세대 미러와 일치하는 항목은 favorite 0.5·retweet 1.0 두 개뿐이고, 나머지는 3년 사이 대폭 개편됐다. 확인 — twitter/the-algorithm-ml projects/home/recap/README.md

• 그 표의 값은 다음과 같다.
  • 양수 항목: fav 0.5 / retweet 1.0 / reply 13.5 / good_profile_click 12.0 / video_playback50 0.005 / reply_engaged_by_author 75.0 / good_click 11.0 / good_click_v2 10.0
  • 음수 항목: negative_feedback_v2 −74.0 / report −369.0

세대를 건너뛰어 복원되는 상수도 있다. 3세대 offset_score는 2세대 Scala RerankerUtil.weightedScoresSum의 직역이다. 3세대에서 crate::params에 숨었던 NEGATIVE_SCORES_OFFSET의 2세대 대응물은 val Epsilon = 0.001이다. 4세대에서 NEGATIVE_SCORES_OFFSET도 param.rs에 노출됐는지는 grep이 필요하다. 자세한 내용은 multi-task-ranking.md에 있다.

2세대 코드에서 X는 랭킹 가중치에 유저×날짜로 시드 고정된 Beta 분포 곱셈 노이즈를 주입할 수 있다 확인 — HeavyRankerWeightsQueryFeatureHydrator.scala, 시드 Objects.hash(userId, startOfDay). 4세대에서 이 노이즈 주입이 유지됐는지는 심층 분석이 필요하다.

레거시 heavy ranker (2023~2025)

레거시 heavy ranker는 멀티태스크 신경망이 참여 확률들을 예측하고, 그 가중합으로 정렬하는 구조다. 2026 Phoenix와 비교하면 목적함수 형태는 같고 입력이 다르다. 레거시는 수작업 피처를, Phoenix는 ID 임베딩을 입력으로 쓴다.

2025 세대에서는 랭커 두 개가 나란히 돈다 확인 — ScoredTweetsRerankingScoringPipelineConfig.scala:35-39.

• Navi는 프로덕션 heavy ranker이고, 헤드는 15개다 확인 — home-mixer/.../model/PredictedScoreFeature.scala:294-311.
• Phoenix는 트랜스포머 rescorer(앞 랭커가 매긴 점수를 다시 매기는 모델)이고, 헤드는 13개다. ParamGatedScorer(EnablePhoenixScorerParam, …)로 Navi 뒤에 붙고, 가중치는 Navi와 같은 ModelWeights를 공유한다 확인 — PhoenixPredictedScoreFeature.scala:174-189.

트랜스포머 랭커는 기존 heavy ranker를 한 번에 갈아치우지 않았다. param으로 켜는 rescorer로 먼저 옆에 붙었다가, 2026에 전면 교체됐다. 확인 — 근거는 파일 8개가 전부 c54bec0에서 새로 생겼다는 것(git log --diff-filter=A)과 위 파이프라인 연결이다.

2025 Phoenix 호출 규격은 아래와 같다 확인 — home-mixer/.../util/PhoenixUtils.scala.

• 후보를 1400개로 자른다(MaxCandidates = 1400 :36). 설정값 TopLogProbsNum = 50도 있다(:35).
• 재시도는 2회, 시도당 500ms, 총 1초다(:119-121). 매 시도마다 채널을 무작위로 다시 고른다(:108-109).
• 응답이 logprob(로그 확률)이라 math.exp(logProb)로 확률을 복원한다(:151-158).
• 후보에 실려 가는 boolean은 5개뿐이다: isRetweet, isForYouPage(항상 true), isPromotedTweet(항상 false), isReply, isQuote :48-68.

점수 결합식과 세대별 헤드 목록 전체는 multi-task-ranking.md에 있다. 이 결합식은 음수 헤드를 곱하지 않고 임계값 상수 페널티로 처리하며, 마지막에 Epsilon = 0.001로 압축한다.

2025 코드에서는 주의할 점이 있다. PredictedScoreFeature라는 이름의 파일이 두 개 있고, 헤드 세트가 다르다. model/의 15개가 실제로 쓰이고, product/scored_tweets/scorer/의 17개는 레거시다. 후자를 근거로 헤드 목록을 쓰면 틀린다. 확인 — RerankerUtil.scala:4의 import 경로

Grok은 2025 랭킹 점수에 산술적으로 기여하지 않는다. 필터(GrokGoreFilter 등 4종)와 토픽 태그로만 들어간다. PredictedScoreFeatures 어디에도 Grok 헤드가 없다. 확인 — repo-wide, ScoredTweetsRecommendationPipelineConfig.scala:543-546

인증(verified) 작성자 랭킹 부스트는 없다. AuthorIsBlueVerifiedFeature 등을 참조하는 파일 10개가 전부 하이드레이션·로깅·캐싱·마셜링이다. 단 학습 모델의 입력 피처로는 들어간다(GizmoduckFeaturesAdapter.scala:12-17). 규칙 기반 가점은 없고 모델이 알아서 쓰는 구조다. 확인 — repo-wide grep

↑ 목차

재순위·다양성·필터

2026-10-17 커밋(862a123) 기준으로 X For You의 필터는 25개이고, 20개는 스코어링 전에, 5개는 후보 선택 뒤에 걸린다 확인(필터 절). 4세대 공개 기준으로 다양성 장치는 작성자 다양성 감쇠, VMRanker의 DPP 슬레이트 재정렬, 대화 dedup의 세 겹이다 확인(다양성 절, Phoenix 절). 2026-10-14 커밋(4세대+41)부터는 topic 요청이면 VMRanker가 DPP 다양성 재순위를 기본으로 건너뛴다 확인(변경 이력의 4세대+41). 2026-10-08 커밋(4세대+38) 기준으로 최종 배치는 점수 순이 아니고, 블렌더가 광고, 프롬프트, 팔로우 추천, 기본 off인 영상 캐러셀을 차례로 넣고 push-to-home 포스트를 맨 앞에 고정한다 확인(최종 배치 절).

필터 21개 (2026-08, 4세대+1) — 스코어링 전 18 + 후 3

2026-10-17 커밋(862a123) 기준으로 스코어링 전에 걸리는 필터는 20개이고, 아래 순서대로 실행된다 확인 — phoenix_candidate_pipeline.rs:419-451. 2026-08-14 커밋(4세대+1) 기준으로는 18개였다. 그 근거는 README.md #filtering과 phoenix_candidate_pipeline.rs다.

• DropDuplicatesFilter
• ZeroFavCodivertFilter(4세대+44 신규, 2026-10-17)
• CoreDataHydrationFilter
• AgeFilter
• SelfTweetFilter
• OONRetweetReplyFilter(4세대 신규)
• OONNsfwSimclustersFilter(4세대 신규)
• RetweetDeduplicationFilter
• IneligibleSubscriptionFilter
• PreviouslySeenPostsFilter
• PreviouslySeenPostsBackupFilter
• PreviouslyServedPostsFilter
• ViewerMutedKeywordFilter(2026-08-19 커밋(4세대+4)에서 MutedKeywordFilter를 대체)
• AuthorSocialgraphFilter
• Brazil2026ElectionFilter(4세대+1 신규, 2026-08-14)
• VideoFilter
• TopicIdsFilter
• NewUserMinEngagementFilter(4세대 신규, NewUserTopicIdsFilter 대체)
• InventoryHoldoutFilter(4세대 신규)
• FavHoldoutFilter(4세대+23 신규, 2026-09-17)

2026-10-17 커밋(862a123) 기준으로 선택 후에 걸리는 필터는 VFFilter, AncillaryVFFilter, AncestorVideoFilter, DedupConversationFilter, VideoCarouselFilter 5개다 확인 — phoenix_candidate_pipeline.rs:518-524.

• 2026-08-14 커밋(4세대+1)까지는 VFFilter, AncillaryVFFilter, DedupConversationFilter 3개였고, 3세대와 같았다 확인.
• VideoCarouselFilter는 2026-10-08 커밋(4세대+38)에서, AncestorVideoFilter는 2026-10-13 커밋(4세대+40)에서 더해졌다 확인 — 35650fb, e1a0375의 phoenix_candidate_pipeline.rs.

아래 불릿 가운데 처음 4개가 4세대 공개에서 새로 생긴 필터다.

• OONRetweetReplyFilter는 팔로우하지 않는 계정의 리트윗과 답글, 그리고 부모 없는 답글을 거른다. RetweetDeduplicationFilter와는 별개다.
• OONNsfwSimclustersFilter는 SimClusters 부활과 짝을 이뤄 새로 생겼다. SimClusters 소스에서 나온 성인 콘텐츠 계정의 포스트를, 그 계정을 팔로우하지 않는 유저의 피드에서 걸러 낸다.
• NewUserMinEngagementFilter는 신규 유저에게 보여 줄 OON 포스트 중 참여 임계에 못 미치는 것을 제거한다. 관련 param은 6개다.
  • NewUserMinEngagementThreshold, NewUserMinEngagementFilterMetric, NewUserMinEngagementFilterUseRatio, NewUserMinEngagementFilterMaxAccountAgeSecs, NewUserMinEngagementFilterMaxResurrectionAgeSecs, EnableNewUserMinEngagementFilter
• InventoryHoldoutFilter는 결정론적 유저×포스트 해싱으로 3-tier 비율만큼 인벤토리를 홀드아웃하고, 2026-09-17 커밋(4세대+23, 42266f3)에서 params가 확인됐다 확인 — home-mixer/filters/inventory_holdout_filter.rs
  • 해싱은 splitmix64 계열 이중 mixing을 거쳐 100-modular 버킷으로 나눈다.
  • Param은 InventoryHoldoutOriginalsPercent, InventoryHoldoutRepliesPercent, InventoryHoldoutRetweetsPercent 3개이고, 각각 .min(100)으로 클램프한다.
  • 포스트 종류는 retweeted_tweet_id.is_some() → Retweet, in_reply_to_tweet_id.is_some() → Reply로 판별하고, 그 외는 Original로 본다. quoted post는 Original로 취급한다.
  • 게이트는 EnableInventoryHoldout=true이면서 동시에 세 값 중 하나라도 0보다 클 때 열린다.
  • 리트윗은 get_original_tweet_id()(원본)에 대해 판정하므로, 원본과 홀드아웃 결정을 공유한다.
• FavHoldoutFilter는 2026-09-17 커밋(4세대+23, 42266f3)에서 새로 생겼고, fav count 계단별로 홀드아웃한다. Param EnableFavHoldout=false로 기본 off다 확인 — home-mixer/filters/fav_holdout_filter.rs
  • 계단 테이블은 다음 23-tier다.
    • 10K+ fav = 15%, 5K+ = 15%, 3K+ = 15%, 2K+ = 14%, 1.5K+ = 13%, 1K+ = 13%, 750+ = 12%, 500+ = 11%, 300+ = 10%, 200+ = 9%, 150+ = 8%, 100+ = 7%, 75+ = 7%, 50+ = 6%, 30+ = 6%, 20+ = 5%, 15+ = 5%, 10+ = 5%, 7+ = 4%, 5+ = 4%, 3+ = 3%, 2+ = 3%, 1+ = 2%, ≤1 = 0%
  • 홀드아웃 판정은 InventoryHoldoutFilter::is_held_out(post_id, viewer_id, percent)를 재사용하므로(같은 splitmix64 해시) 뷰어별로 결정론적이다.

4세대+1(2026-08-14, c65aa17)에서 새 필터 1개가 생겼다.

• Brazil2026ElectionFilter는 브라질 선거법원(TSE)이 브라질 2026 총선과 관련해 조치한 계정과 엮인 포스트를, 뷰어가 그 계정을 팔로우하지 않으면 걸러 낸다 확인 — home-mixer/filters/brazil_2026_election_filter.rs
  • 계정 목록은 665개 계정을 하드코딩한 FxHashSet<u64>이다.
  • 후보에서 대조하는 필드는 author_id, retweeted_user_id, quoted_user_id, ancestor_users이고, 이 중 하나라도 그 집합에 있으면 대상이 된다.
  • 파이프라인에서는 AuthorSocialgraphFilter 직후, VideoFilter 직전에 놓인다. 다른 근거 위치는 phoenix_candidate_pipeline.rs:356-368다.
  • 근거 자료는 브라질 선거법원 열린 데이터셋과 X의 공지 (@XBR, 2026-08-14)다. README는 이렇게 명시한다: "in accordance with Brazilian electoral law, For You now runs Brazil2026ElectionFilter, which removes posts from accounts reported to Brazil's Electoral Court for the 2026 election, unless the viewer explicitly follows the account."
  • 2026-10-14 커밋 17c96bf(4세대+41)에서 목록이 10월 25일 결선 투표 후보 관련 25개 계정으로 줄었다(해당 diff 구간이 5,654줄에서 63줄이 됐다) 확인. 근거로 TSE 공문 번호를 주석에 적었다 확인 — brazil_2026_election_filter.rs:17-74
  • 코드는 각 계정 ID 옆에 @username을 주석으로 남긴다("obfuscated ID + 투명성 목적 username 병기"). 예는 40053694 // @FlavioBolsonaro, 21069302 // @marcelvanhattem, 48298703 // @eduardopaes다.
  • 팔로우 예외는 유저 개인 팔로잉 그래프 기반이라, 정치적 스펙트럼과 무관하게 대칭적이다. 판정식은 is_excluded_author(user_id, followed_user_ids) = LIST.contains(user_id) && !followed_user_ids.contains(user_id)다.
  • 리스트 사이즈는 코드 상수 665다. 코드에는 이런 이례적 주석이 있다: "OmarAzizSenador deleted his account at the time this code was written."
  • 이 필터는 관할권 필터가 코드 안에서 그대로 관찰되는 첫 사례다. DSA·GDPR·NetzDG 같은 규제 대응은 지금까지 대부분 규제 제출 문서(투명성 리포트)로만 봤다. 이 코드 공개 관행이 유지된다면, 각국 선거 사이클마다 유사한 필터를 코드로 확인할 수 있게 된다는 뜻이다.

필터 가운데 눈여겨볼 점은 다음과 같다.

• AuthorSocialgraphFilter가 보는 조건은 6가지다 확인 — filters/author_socialgraph_filter.rs:8-61
  • 뮤트, 차단, 작성자가 나를 차단, 인용된 작성자가 나를 차단, 내가 인용 작성자 차단, 내가 리트윗 원저자 차단
• VFFilter는 여전히 fail-closed지만, 4세대+18(2026-09-09, 75d93d9)부터 판정 축이 FilteredReason variant 매칭에서 명시적 Action enum으로 옮겨졌다 확인 — home-mixer/filters/vf_filter.rs:16-21
  • should_drop_action이 Drop(_)·Tombstone·NotEvaluated를 drop으로, Allow·Interstitial·Avoid·Downrank를 keep으로 분류한다.
  • 상류 StratoVfClient는 non-SafetyResult reason(뮤트·차단·null-cast·exclusive 등)을 client 층에서 Drop으로 바꾸고, SafetyResult 안의 NotEvaluated는 Allow로 바꾼다 확인 — visibility-filtering-client/vf_client.rs:178-187. 그래서 이 경로에서는 판정 없음이 drop되지 않는다.
  • 반대로 Rust VF 클라이언트는 응답에서 빠진 포스트를 NotEvaluated로 채우고, VFFilter는 이것을 drop한다 확인 — vf_client.rs:360-378. fail-closed는 이 경로의 누락 결과에 해당한다.
  • 2026-10-17 커밋(862a123)에서도 두 처리와 should_drop_action은 같다 확인 — vf_client.rs, vf_filter.rs.
• 인네트워크와 OON에는 다른 안전 레벨이 적용된다(TimelineHome vs TimelineHomeRecommendations). 조상 포스트와 인용 포스트에는 항상 더 엄격한 쪽이 적용된다 확인 — vf_candidate_hydrator.rs:62-67, 76-90
• TopicIdsFilter는 572줄짜리 파일이고, 그 안에 약 90개 토픽 상수와 손으로 짠 supertopic 계층이 들어 있다. 이 부분은 "수작업 피처 전부 제거"와 정면으로 배치된다. 확인 — filters/topic_ids_filter.rs:109-515
• PreviouslySeenPostsBackupFilter는 영구 no-op다. 그 입력을 채울 ImpressedPostsQueryHydrator가 생성만 되고, _에 바인딩된 채 파이프라인에 등록되지 않는다. 매 요청마다 돌지만 아무것도 거르지 않는다 확인 — phoenix_candidate_pipeline.rs:234-236

4세대+4(2026-08-19, aad7179)에서 Following 파이프라인 전용 뮤트 키워드 필터와, 이를 뒷받침하는 quoted-post text hydrator가 새로 붙었다 확인 — home-mixer/filters/following_viewer_muted_keyword_filter.rs(65줄 신규), home-mixer/candidate_hydrators/quoted_post_text_hydrator.rs(106줄 신규). 이 커밋은 Following 파이프라인이 2026-08-18 커밋(4세대+3)에서 VFFollowingCandidateHydrator로 분기된 흐름의 연장선이다.

• FollowingViewerMutedKeywordFilter는 기존 MutedKeywordFilter(For You 파이프라인용)와 별개 파일로 분리됐다.
  • TweetTokenizer로 muted_keywords를 토큰화하고, MatchTweetGroup으로 매처를 구성한다.
  • 후보의 tweet_text, quoted_tweet_text, ancestor_texts.values() 세 텍스트 소스 중 하나라도 매치하면 걸러 낸다.
  • 이 매칭은 tokio::task::block_in_place로 감싼 CPU-bound 작업이다.
  • 특이점은 기존 For You 필터가 tweet_text만 봤을 가능성이다. 근거는 2026-08-18 커밋(4세대+3)에 quoted-text 연결이 없었다는 점이다.
  • 이제 인용된 포스트와 ancestor(답글 조상)까지 뮤트 대상이 넓어졌다. 이 확장은 인용이나 답글로 뮤트를 우회하는 길을 좁힌다.
• QuotedPostTextHydrator는 이 필터의 입력을 준비하는 hydrator다. 필터가 quoted text를 매치하려면 이 필드를 먼저 채워야 한다.
  • quoted_tweet_id가 있는 후보에 대해 TESClient.get_tweet_core_datas로 일괄 조회한 뒤 quoted_tweet_text 필드에 채운다.
  • HashSet으로 중복을 없애고, gRPC를 배치로 호출한다.
• 의미: 이제 For You와 Following은 필터·hydrator 스택에서 서로 다른 컴포넌트를 쓴다. 2026-08-18 커밋(4세대+3)의 VF hydrator 분기와 짝지어 보면, Following 파이프라인은 For You 파이프라인의 subset이 아니라 병렬 구조로 재구성되고 있다 추정

4세대+5(2026-08-20, d0cef2f)에서 For You에 "AI trend" feedback context 채널이 새로 생겼다.

기존 topic feedback context(사용자 관심 topic 추론용 컨텍스트 라벨)와 나란히 두 번째 컨텍스트 채널이 열렸다 확인 — home-mixer/candidate_hydrators/ai_trend_feedback_context_hydrator.rs(157줄 신규). 파이프라인에서는 TopicFeedbackContextHydrator 뒤에 나란히 연결됐다 확인 — home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:424-428. 다른 근거 위치는 home-mixer/util/urt/post_marshaller.rs:72-110다.

• 게이트는 3중이다. 스위치는 EnableAiTrendFeedbackContext=false로 기본 off이고, 나머지 두 조건은 !query.is_topic_request()와 !query.in_network_only다. 즉 topic 지면·Following 지면과 겹치지 않고, For You OON 후보만 대상으로 한다.
• 후보는 standalone original post 4중 조건으로 거른다. 즉 AI trend 라벨은 답글, 리트윗, 대화 조상이 있는 포스트, 팔로잉이 답글을 단 대상이 아닌 원본 포스트에만 붙는다.
  • 조건식은 in_reply_to_tweet_id.is_none() && retweeted_tweet_id.is_none() && ancestors.is_empty() && following_replied_user_ids.is_empty()다.
• 한 페이지에 AI trend 라벨은 최대 2개가 붙고, trend마다 한 후보에만 붙는다. 이 제한은 같은 trend의 여러 후보를 같은 라벨로 도배하지 않게 하는 억제 장치다.
  • 선정 방식은 Top-2 trend와 trend당 후보 1개 랜덤이다.
  • 후보들의 trend_id를 Strato batch_get_tweet_ai_trend로 조회하고, 빈도 히스토그램에서 상위 2개 trend를 고른다(TOP_TREND_COUNT = 2). 동률이면 trend_id가 작은 쪽이 우선이다.
  • 각 trend에 대해 그 trend로 라벨링된 후보 중 1개를 무작위로 고르고, Strato batch_get_ai_trend_name로 표시 이름을 조회한다.
• 렌더할 때는 topic feedback이 우선한다. post_marshaller에서 topic feedback이 있으면 topic이 이기고, 없을 때만 AI trend가 폴백으로 들어간다.
  • 둘 다 URT에서 ContextType::TOPIC 타입으로 나간다.
  • AI trend는 landing_url = "https://x.com/i/trending/{trend_id}"를 채우고, TopicFeedbackContext.topic_id가 None이다.
  • 즉 chip을 탭하면 topic feedback 페이지가 아니라 trending 지면으로 이동한다.
• 의미: 이 채널은 랭킹 상류의 컨텍스트·시그널 소스 자체를 넓히는 방향이다. 사용자가 이 chip을 탭하거나 닫거나 무시하는 반응이 "이 유저는 이 AI trend에 관심 있는가"의 라벨 소스가 된다.
• 미공개: 다음은 공개되지 않았다.
  • AI trend의 정의(Grok으로 트윗 클러스터링? 사람 큐레이션?)
  • batch_get_tweet_ai_trend upstream 파이프라인의 위치
  • EnableAiTrendFeedbackContext 실 배포 여부

다양성

X For You의 다양성 장치는 세 겹이다.

1. 작성자 다양성 감쇠는 4세대 공개 때 랭킹 스코어러 안에서 적용됐고, 2026-09-24 커밋(4세대+28)부터는 vm-ranker 서비스가 공유 crate xai-value-model로 계산한다 확인(Phoenix 절의 최종 점수 계산 순서).
2. VMRanker DPP는 후보를 집합 단위로 최적화하고, 서비스 본체는 4세대 공개부터 vm-ranker/에 있다 확인(Phoenix 절의 VMRanker 문단).
   • 4세대+20(6bb4594, 2026-09-12)에서 optional seed_tweet_id 인자가 추가됐다.
   • 이 id의 임베딩이 있으면 seed가 greedy DPP의 첫 슬롯에 pinning되고 최종 결과에서는 걸러져 나가므로, top_k 예산은 소진하지 않으면서 seed와 유사한 후보만 페널티를 받는다.
   • 즉 다양성 축을 집합 내부에서 참조 tweet 대비로도 확장할 수 있게 됐다.
   • 프로덕션 지면 중 이 필드를 실어 주는 곳이 어디인지는 아직 공개되지 않았다.
3. 대화 dedup은 스레드당 최고점 1개만 남긴다 확인 — filters/dedup_conversation_filter.rs:6-48
   • 대화를 묶는 id는 conversation_id = min(ancestors) 또는 자기 자신이다.

VMRanker 호출이 실패해도 피드는 DPP 없이 나간다. 2026-09-24 커밋(4세대+28)부터는 gRPC가 실패하면 로컬 가중합 점수를 내보내고, 그 실패를 VMRanker.local_score_fallback 메트릭으로 센다 확인 — vm_ranker.rs:107-113.

• 그 전(3세대~4세대+27)에는 모든 후보에 Err를 반환했고, 파이프라인의 update_all이 Err를 로그도 없이 건너뛰었다. 그래서 DPP 다양성이 빠진 점수순 피드가 아무 표시 없이 나갔다 확인 — candidate-pipeline/scorer.rs(update_all 기본 구현), vm_ranker.rs:44-66

X는 피드가 뷰어에게 새로운 토픽을 얼마나 보여 주는지 재는 장치를 기본 off로 만들었다. 2026-10-20 커밋(4세대+45)에서 뷰어가 최근 참여한 포스트의 SID 앞 1·2단계를 토픽으로 세고, 응답 포스트 가운데 그 이력에 없는 토픽의 비율을 메트릭으로 남기는 경로가 생겼다 확인 — side_effects/serendipity_stats_side_effect.rs.

• 이력 토픽 계산은 스위치 HistoryTopicsEnabled가 기본 false라 꺼져 있고, 켜지면 메트릭은 28일 이력을 기준으로 잰다 확인 — params/param.rs:508-529.
• 같은 이력 토픽을 VMRanker 요청에 실어 보내는 스위치도 기본 off로 생겼다 확인 — 같은 파일. VMRanker가 이 값을 어떻게 쓰는지는 공개 코드에 없다 확인.
• 메트릭만 있고 재순위에 쓰는 코드는 없다 확인. 측정을 먼저 넣은 순서로 보아, 이력 기반 토픽 탐색을 다양성 목표로 시험할 준비로 본다 추정. 세부는 daily 2026-10-21에 있다.

2025 Scala 세대는 방식이 지금과 달랐다. MMR은 거리에 보상을, SimClusters 카테고리 페널티는 같은 것에 벌점을 주는 방식이었고, 둘이 param-gated로 나란히 있었다. dedup 필터는 6종이었다. 네 방식(감쇠, MMR, DPP, dedup)의 비교와 세대별 전체 목록은 feed-diversity.md에 있다.

최종 배치는 점수 순이 아니다

최종 배치를 맡는 블렌더는 프레임워크의 정렬을 의도적으로 무력화한다 확인. 근거는 home-mixer/selectors/blender_selector.rs:25-114다. 이 파일의 BlenderSelector에서 score()는 상수 0.0을 반환한다 확인. 블렌더는 그다음 아래 단계를 실행한다.

• 프롬프트를 0..n번 자리에 삽입한다 확인 — 같은 파일
• Who-to-Follow(WTF)를 지정 위치에 삽입한다 확인 — 같은 파일
• push-to-home 포스트를 항상 0번에 고정한다 확인 — 같은 파일
• 광고 블렌더를 실행한다. 2026-10-17 커밋(862a123) 기준으로 AdsBlenderType이 partition_organic_low_risk·safe_gap·multi_risk·time_gap 가운데 하나를 고르고, 기본값은 2026-09-01 커밋(4세대+13)부터 multi_risk다 확인 — blender_selector.rs:55-72, params/param.rs:817
• 2026-10-08 커밋(4세대+38)부터 기본 off인 영상 캐러셀 모듈을 VideoCarouselPosition(기본 6)번째 자리에 삽입한다. 실행 순서는 광고 블렌딩 → 프롬프트 → WTF → 캐러셀 → push-to-home 고정 → 프레임 → 설문이다 확인 — home-mixer/selectors/blender_selector.rs:72-85, 137-153

↑ 목차

콜드스타트

콜드스타트는 이력이나 노출이 아직 쌓이지 않은 유저, 작성자, 포스트를 추천에서 어떻게 다루느냐의 문제다. 4세대 공개 기준으로 X For You 코드에는 신규 유저와 새 작성자를 위한 장치가 있었지만, 개별 새 포스트를 위한 장치는 없었다 확인(신규 유저, 새-작성자 부스트, 신규 아이템 절). 2026-09-30 커밋(4세대+32)부터는 노출과 좋아요가 적은 새 포스트를 따로 모으는 Phoenix retrieval cold 슬라이스가 켜졌고, 콜드스타트 슬롯 선택기는 홈 노출이 200 미만인 포스트만 고른다 확인(신규 아이템 절). 새 작성자의 인네트워크 포스트에 붙는 새-작성자 부스트는 2026-10-07 커밋(4세대+37)부터 home-mixer 미러에서 0.015, VM-Ranker 미러에서 0.02다 확인(변경 이력 4세대+37). 콜드스타트 슬롯 선택기의 Thompson sampling과 Phoenix retrieval의 cold-start 슬라이스는 기본 off로 들어왔다가, 홈믹서 cold-start 파라미터를 프로덕션 값으로 튜닝한 커밋에서 함께 켜졌다 확인.

신규 유저 (계정 단위)

이력 길이가 임계보다 짧은 신규 유저는 랭킹과 retrieval 모두에서 별도 모델 플릿으로 보낸다 확인. 근거는 phoenix_scorer.rs:29-43과 phoenix_source.rs:25-39다. 임계는 Phoenix*NewUserHistoryThreshold이고, 이 유저들이 갈 플릿은 Phoenix*NewUserInferenceClusterId다.

• 2026-09-18 커밋(4세대+25)에서 Phoenix retrieval의 cold-start 슬라이스가 first-class로 연결됐다 확인 — home-mixer/sources/phoenix_source.rs.
  • 이 슬라이스는 Phoenix retrieval 응답에 담긴 dataset_type 축으로 구분한다.
  • HOME_COLD_DATASET_TYPE=13 태그가 붙은 후보는 served_type이 ForYouPhoenixRetrievalCold로 매핑된다.
  • record_phoenix_retrieval_cold_stats가 PhoenixRetrievalColdTweets.* stat block을 발행한다.
  • 이 슬라이스의 별도 상한 param PhoenixColdStartMaxResults는 0(기본 off)으로 신설됐다.
  • 앞의 라우팅이 유저 이력 임계로 모델 플릿을 가르는 것과 달리, 이 슬라이스는 같은 Phoenix retrieval RPC가 반환하는 후보 세트 안을 dataset_type 태그로 나눈다.
  • 신설 시점에는 기본 off라 프로덕션 지분이 없었다.
  • 이 상한은 그 뒤 홈믹서 cold-start 파라미터를 프로덕션 값으로 튜닝한 커밋에서 200으로 켜졌다 확인 — params/param.rs:16.
• 신규 유저 라우팅 임계는 4세대 공개 기준으로 NewUserAgeThresholdSecs = 0이다 확인. 0초이므로 신규 유저 경로가 사실상 비활성 상태로 미러링돼 있다고 본다 추정.
  • 이 param은 2026-09-24 커밋(4세대+28)에서 홈믹서 param.rs에서 빠졌고, 2026-10-17 커밋(862a123)의 vm-ranker/params.rs에서도 0이다 확인.
• 4세대에 새로 생긴 OON 참여 임계 필터 NewUserMinEngagementFilter는 참여 임계에 못 미치는 OON 포스트를 제거한다.
• 3세대에 있던 NEW_USER_OON_WEIGHT_FACTOR, NewUserTopicIdsFilter, EnableNewUserTopicRetrieval은 4세대 param.rs에 없다. 심층 분석이 필요하다.

신규 작성자 (계정 단위)

새 작성자는 임프레션 수로 가려내고, 그 작성자의 인네트워크 포스트에 새-작성자 부스트를 준다 확인(랭킹의 새-작성자 부스트 절). 부스트와 임계 param은 4세대에서 문서화됐고, 부스트 param 전체는 그 절의 표에 있다.

• 새-작성자 부스트는 2026-10-07 커밋(4세대+37)부터 home-mixer 미러에서 0.015, VM-Ranker 미러에서 0.02다. 인네트워크 포스트에만 붙는다.
  • 4세대에서 문서화된 값은 PostUnexploredWeight = 0.02다.
• 4세대 README는 노출이 임계 미만인 작성자를 "새 작성자"로 설명하고, 그때 임계 param은 ColdStartImpressionThreshold = 1000이었다. 코드는 이 임계를 작성자가 아니라 후보 포스트의 홈 노출 수에 적용한다 확인(새-작성자 부스트 절).
  • 이 임계는 그 뒤 홈믹서 cold-start 파라미터를 프로덕션 값으로 튜닝한 커밋에서 200으로 바뀌었다 확인.

콜드스타트 슬롯 선택기

콜드스타트 슬롯 선택기는 콜드스타트 대상 후보 집합 안에서 "슬롯을 어느 후보로 채울지"를 고른다. 2026-08-14 커밋(4세대+1)에서 이 선택 방식이 greedy max-score와 Beta reward Thompson sampling 두 갈래로 나뉘었다 확인 — home-mixer/scorers/author_cold_start.rs:151-190. Thompson sampling은 처음에는 기본 off였고, 홈믹서 cold-start 파라미터를 프로덕션 값으로 튜닝한 커밋부터 기본으로 켜져 있다 확인.

param 정의와 4세대+1 시점의 기본값은 param.rs에 있다 확인 — home-mixer/params/param.rs:687-724.

EnableColdStartThompsonSampling은 A/B용으로 붙인 스위치다. 2026-08-14 커밋(4세대+1)의 기본값은 false이고, 기본은 여전히 greedy(현행 유지)다. 기본 off라는 점이 중요하다. 이 릴리즈 시점(2026-08-14)에 실제 유저에게 노출되는 콜드스타트는 여전히 max-score greedy이고, Thompson은 A/B 인프라만 연결돼 있다.

• Thompson sampling은 후보마다 posterior에서 샘플을 한 번 뽑아 상위 K개를 고르고, 그 안에서 원래 스코어가 가장 높은 후보를 고른다.
  • 각 콜드스타트 후보 i에 대해 n_i = scale × view_count_i, x_i = min(fav_count_i, n_i)로 둔다.
  • posterior는 Beta(α₀ + x_i, β₀ + max(n_i − x_i, 0))이고, 여기서 한 번 샘플한다.
  • 즉 Bayesian exploration(어떤 후보가 좋을지에 대한 불확실성)을 하되, 최종 선택은 원래 스코어 tie-break로 정한다.
• α₀=0.75, β₀=49.25는 "50 impression 중 대략 0.75 like"라는 사전분포를 둔다. 실측 like rate가 이보다 높은 새 작성자가 후하게 뽑히도록 한 값이다.
• 2026-08-14 커밋(4세대+1) 기준으로 계측 훅 record_tracked_ids는 A/B에서 특정 계정을 손으로 관찰할 수 있게 하는 개별 관찰 훅이다.
  • 이 훅은 ColdStartTrackedIds에 등록된 tweet_id/author_id가 콜드스타트 파이프라인의 어느 소스에서 몇 번 나왔는지 센다.
  • 카운터는 home_mixer.cold_start_tracked_ids_total{id, source}다.
• 2026-08-18 커밋(4세대+3)에서 이 계측의 집계 키가 단순화됐다 확인 — home-mixer/scorers/author_cold_start.rs:92-108.
  • 바뀐 함수는 count_tracked_ids다.
  • 이전에는 tweet_id와 author_id를 별도 항목으로 집계했다.
  • 이후에는 tweet_id나 author_id가 tracked 목록에 든 후보를 그 후보의 tweet_id 하나로 센다. author_id 별도 항목은 없어졌다.
  • tracked 목록 필터는 남아 있어서, 목록이 비어 있으면 아무것도 세지 않는다. 2026-10-17 커밋(862a123)의 함수도 같다 확인 — author_cold_start.rs:151-185.
• 2026-09-04 커밋(4세대+16)에서 record_tracked_ids를 호출하는 쪽과 param 연결이 확정됐다 확인 — home-mixer/scorers/author_cold_start.rs. 이 tracked ID 관측 훅은 A/B와 무관한 상시 관측 채널이다.
  • ColdStartParams::read(query)가 모든 param을 한 번에 읽어 params.tracked_ids에 담는다.
  • record_tracked_ids(candidates, &params.tracked_ids)는 EnableViewerColdStart 게이팅과 무관하게 항상 호출된다.
• 같은 2026-09-04 커밋(4세대+16)에서 codivert 실험의 impression 대칭성을 회귀 테스트로 고정했다 확인 — 같은 파일.
  • 신규 experiment moe_codivert_viewer의 두 arm이 각각 enable_viewer_cold_start_boost=true/false로 대칭으로 갈리도록 YAML rule 한 쌍이 들어왔다.
  • experiment param은 PhoenixMoeCodivertViewerIsControl과 PhoenixMoeCodivertViewerIsTreatment다.
  • apply()는 실행 순서를 바꿔 viewer_arm(query)과 author_corpus(...)를 enabled 게이팅보다 먼저 호출한다.
  • 두 arm은 각각 moe_codivert_viewer bucket impression을 3회, author 대상인 moe_exp bucket impression을 2회 정확히 남긴다. 테스트 both_arms_log_the_same_codivert_impressions와 both_viewer_arms_log_the_same_author_impressions가 이를 고정한다.
  • triggered-analysis는 파이프라인에 들어온 사용자만 비교하고, intent-to-treat는 할당된 모든 사용자를 비교한다. 두 정의의 불일치를 회귀 테스트로 막는 방법론이 코드로 들어왔다.
• 같은 2026-09-04 커밋(4세대+16)에서 Treatment arm의 후보 필터가 Phoenix MoE 후보에만 걸리도록 좁혀졌다 확인 — 같은 파일.
  • cold_start_corpus_eligible(Treatment)에 && is_phoenix_moe(c) 조건이 추가됐다.
  • 이 커밋 기준으로 Treatment 뷰어의 cold-start 후보는 treatment corpus author의 포스트이면서 served_type == ForYouPhoenixRetrievalMoe인 후보만이었다.
  • 테스트 이름도 treatment_viewer_cold_starts_treatment_moe_only로 바뀌었다.
  • Cold-start와 Phoenix MoE가 하나의 codivert 실험 안에 묶여, 두 효과가 서로 뒤섞이지(confounded) 않게 격리된다.
  • 이 MoE 조건은 2026-09-17 커밋(4세대+23)에서 Treatment 갈래에서 빠졌고, 2026-10-17 커밋(862a123)의 cold_start_corpus_eligible에는 MoE 조건이 없다 확인 — 42266f3, 862a123의 author_cold_start.rs.
• 같은 2026-09-04 커밋(4세대+16)에서 engagement counts hydration이 cold-start 게이팅과 분리됐다 확인 — home-mixer/candidate_hydrators/engagement_counts_hydrator.rs.
  • enable()은 EnableViewerColdStart 종속을 없애고, EnableEngagementCountsHydration || is_shadow_traffic만으로 켜질지를 정한다.
  • enable()의 !query.has_cached_posts 게이팅도 없앴다. 후보마다 조회 여부를 정하는 쪽의 has_cached_posts 분기는 2026-10-01 커밋(4세대+33)까지 남았고 2026-10-02 커밋(4세대+34)에서 없어졌다 확인 — engagement_counts_hydrator.rs:123, 76843a5의 같은 파일.
  • Cold-start Thompson sampling이 view_count_on_home, fav_count에 의존하던 4세대+1(2026-08-14) 초기 연결의 강결합이 풀린다.

신규 아이템 (포스트 단위)

4세대 공개 기준으로는 작성자와 상관없이 새 포스트 자체를 밀어 주는 별도 장치가 없었다 확인. 2026-10-17 커밋(862a123) 기준으로 포스트 단위 조건으로 작동하는 장치는 두 가지다.

• 2026-09-24 커밋(4세대+28)에서 Phoenix retrieval 학습 데이터에 HOME_COLD(13)와 HOME_HOT(14) 데이터셋이 생겼다. HOME_COLD는 조회 500 미만, 좋아요 8 미만인 최근 포스트만 남긴다 확인 — retrieval_dataset.py:280-281, cold_pool_filter.py:26-46.
  • 홈믹서는 2026-09-18 커밋(4세대+25)부터 이 태그(13)가 붙은 retrieval 후보를 cold 슬라이스로 따로 구분하고, 2026-09-30 커밋(4세대+32)부터 200개까지 받는다 확인(후보 생성 현행).
• 콜드스타트 슬롯 선택기는 작성자 팔로워가 50,000 이하이고, 올라온 지 2시간 이내이며, 홈 노출이 200 미만인 원본 포스트 가운데 하나를 골라 순위를 올린다 확인 — author_cold_start.rs:296-309, params/param.rs:507-531.
  • 이 선택기는 4세대 공개부터 후보 포스트의 노출 수를 조건으로 썼고, 그때 임계는 1000이었다(새-작성자 부스트 절).

새 포스트의 해시 임베딩은 지속학습 중인 테이블이 현재 갖고 있는 값이고, 처음 보는 ID면 해시 충돌로 섞인 다른 포스트들의 평균이 된다 추정.

2025 Scala 코드에는 SimclusterColdPostsCandidateSource.scala가 있었다. 4세대에서 SimClusters가 부활했으므로, 이 소스가 4세대 simclusters/에 살아 있는지는 심층 분석이 필요하다(열린 질문).

↑ 목차

안전성 / visibility-filtering / labeling 파이프라인 (4세대에서 통째 공개)

4세대 공개(2026-08-13)는 X가 안전 라벨을 만들고 그 라벨로 포스트 노출을 판정하는 경로를 전부 공개했다. 4세대 README 기준으로 이 경로는 콘텐츠 이해, 라벨링 규칙, 저장, 가시성 필터링(VF)의 네 단계다 확인(4단계 Labeling Path). 2026-10-15 커밋 기준으로 VF가 쓰는 SafetyLevel(안전 레벨)은 다섯 개다 확인(변경 이력의 2026-10-15 커밋).

3세대까지 home-mixer/에는 VFFilter와 AncillaryVFFilter가 fail-closed로 걸려 있었다. 하지만 그 필터가 참고하는 라벨을 누가 언제 어떻게 붙이는지는 완전한 블랙박스였다. 4세대 공개 때 visibility-filtering과 labeling 서브레포 15개가 새로 들어왔다 확인(공개 소스 4세대).

4단계 Labeling Path 확인 — README.md #labeling-path

1~3단계가 라벨을 만들어 저장하고, 4단계가 요청 경로에서 그 라벨로 판정한다 확인.

Content Understanding → Labeling Rules → Storage → Visibility Filtering

1단계(Content Understanding)는 요청 경로 밖에서 도는 nearline 단계다. README 그림의 1단계에는 grox, media-model-proxy, clip, agatha, bdsm, user-cred-v2 여섯 개가 나온다 확인. 관련 서브레포는 아래 표와 같다.

2단계(Labeling Rules)는 이벤트와 스코어를 라벨로 바꾼다 확인.

• scarecrow/는 이벤트에 반응해 도는 규칙 러너이고, botmaker/를 규칙 엔진으로 임베드한다 확인.
• botmaker/는 규칙 DSL·컴파일러·런타임이다 확인.
• botmaker-rules/는 scarecrow가 로드하는 실제 규칙이다 확인. README에 따르면 일부는 게이밍 방지 목적으로 공개하지 않았다 확인.
• abuse-enforcement-service/는 모델 스코어를 근거로 계정 조치(라벨링·챌린지·서스펜션)를 내린다 확인.
• safety-label-user-agg/는 계정이 소유한 포스트의 라벨을 계정 레벨로 집계한다 확인.

3단계(Storage)에서는 라벨이 저장소에 쓰이고, 요청 경로에서 읽힌다.

4단계(Visibility Filtering)는 요청 경로에서 돈다 확인 — visibility-filtering/rules/registry.rs. 클라이언트 라이브러리는 visibility-filtering-client/에 있다 확인.

2026-10-15 커밋(92f0918) 기준으로 SafetyLevel은 다섯 개이고, 레벨별 규칙 상수 항목 수는 다음과 같다 확인 — visibility-filtering/rules/levels.rs.

판정은 2026-09-22 커밋(4세대+26)부터 Allow/Interstitial/Drop 3분류가 아니라, 보류와 표시로 나뉘는 트리다 확인 — visibility-filtering/models/verdict.rs(커밋 요약표의 4세대+26 행).

• 보류 쪽은 Drop·Tombstone이다.
• 표시 쪽에는 media·engagement 슬롯이 있고, notice 슬롯은 2026-10-06 커밋(4세대+36)에서 더해졌다 확인 — verdict.rs(변경 이력의 4세대+36).
• 그 앞 단계로 2026-09-09 커밋(4세대+18)은 판정 축을 FilteredReason에서 평평한 Action enum으로 바꿨다(변경 이력의 4세대+18).

4세대 공개 시점(2026-08-13)에는 SafetyLevel 정책이 세 개였다 확인 — 4세대 registry.rs.

• FilterAll은 모든 것을 드롭한다 확인.
• TimelineHome은 팔로잉 대상에 쓰는 정책이고, base 28 규칙으로 이뤄진다 확인.
  • base_home_rules()의 28개 규칙은 계정 상태 5개, 뷰어 관계 3개, 트윗 라벨 8개, 트윗 상태 4개, NSFW 뷰어 게이팅 3개, 배제 트윗 1개, NSFW 인터스티셜 4개로 이뤄진다 확인.
• TimelineHomeRecommendations는 추천 대상에 쓰는 정책이고, base 28개에 OON 전용 26개를 더한 54 규칙으로 이뤄진다 확인.
  • OON 전용 규칙 26개는 DMCA/지리 제한 미디어 2개, NSFW 계정 4개, NSFW/폭력/DoNotAmplify/스팸 라벨 트윗 9개, NSFW/스팸/impersonation/deactivated/adult 유저 라벨 11개로 이뤄진다 확인.

4세대 registry.rs에서는 첫 번째 드롭 판정이 나오면 평가가 끝난다(short-circuit) 확인. OON 전용 규칙군은 드롭만 할 수 있고, 인터스티셜이나 알로우 판정은 내지 않는다 확인. 판정은 Allow, Interstitial(reason), Drop(FilteredReason) 세 가지다 확인. 인터스티셜은 UI 처리로 넘기며, 이 레포에는 인터스티셜을 그리는(draw) 코드가 없다 확인.

canon 주의 목록 #1·#2의 실체 확인 (부분)

두 항목 모두 실체가 부분적으로 확인됐고, 항목마다 심층 분석이 필요한 질문이 하나씩 남았다.

• VFFilter의 fail-closed 동작: VFFilter가 판정 없는 모든 FilteredReason 변종을 무조건 drop한다는 3세대 관찰은 유효하다. visibility-filtering/ 서브레포가 판정 없이 리턴하는 경우(에러·타임아웃)를 어떻게 처리하는지는 심층 분석이 필요하다.
• 인네트워크와 OON에 다른 safety level을 쓰는 동작: 4세대 Policies 구조체는 FilterAll·TimelineHome·TimelineHomeRecommendations 세 레벨을 그대로 노출한다. 조상·인용 포스트에 더 엄격한 쪽을 적용하는 3세대 규칙(vf_candidate_hydrator.rs)이 4세대에서도 유지됐는지는 심층 분석이 필요하다.

Under the Hood 투명성 툴 — 4세대와 짝지어 신설 확인

Under the Hood는 유저가 자기 계정과 포스트에 붙은 visibility-impacting 라벨을 조회하는 투명성 툴이다 확인. 라벨은 일일 배치가 수집하고, 서빙 층이 집계한다 확인. X가 밝힌 목적은 유저가 이 레포 코드와 맞춰 보며 "왜 내 포스트가 이렇게 취급됐나"를 직접 감사할 수 있게 하는 것이다 확인.

• 주소: x.com/i/under_the_hood
• 서브레포: under-the-hood/

↑ 목차

피드백 신호

X 추천 코드는 좋아요, 답글, 리포스트 같은 긍정 행동과 관심 없음, 차단, 뮤트, 신고 같은 부정 행동을 피드백 신호로 쓰고, 프로덕션은 포스트에 머물지 않은 것까지 부정 신호로 센다 확인. Phoenix의 이력 인코딩은 하지 않은 행동을 0이 아니라 −1로 넣고, 행동이 하나도 없는 이력 항목은 마스킹한다 확인. 이미 본 포스트는 6겹으로 처리하며, 유저 쪽 피처에는 나이와 추론된 성별 같은 인구통계가 들어간다 확인. 세로 영상 캐러셀 모듈을 기본 off로 신설한 커밋에서, 이력의 체류 시간을 버킷 임베딩으로 입력하는 Phoenix 피처는 기본 on이 됐다 확인(변경 이력).

• 긍정 신호는 좋아요, 답글, 리포스트, 인용, 클릭, 체류 같은 행동이다 확인 — phoenix/runners.py:233-253
  • 전체 목록은 favorite, reply, repost, quote, click, profile_click, photo_expand, video quality view, share(DM·링크 복사 포함), dwell, dwell_time, follow_author다.
• 부정 신호는 관심 없음, 작성자 차단, 작성자 뮤트, 신고이고, 프로덕션은 not_dwelled(안 머물렀음)까지 부정 신호로 센다 확인 — ranking_scorer.rs:83
  • 네 행동의 식별자는 not_interested, block_author, mute_author, report다.
• 이력 인코딩에서 행동 없음은 0이 아니라 −1이다 확인 — phoenix/recsys_model.py:404-432
  • 식은 actions_signed = 2*actions - 1이다.
  • 즉 "이 포스트에 좋아요를 안 눌렀다"가 명시적인 음의 신호로 들어간다.
  • 다만 행동이 하나도 없는 이력 항목은 항목 전체가 마스킹된다 확인 — 같은 파일.
• 이미 본 포스트 처리는 6겹이다 확인 — query_hydrators/, side_effects/의 각 파일
  • 6겹을 이루는 것은 클라이언트가 보낸 seen_ids, impression bloom filter, 서버 쪽 served history(최근 N분/M개), Redis 후보 캐시, Phoenix 요청 캐시, URT 커서다.
• 클라이언트가 보고한 노출은 Kafka로 다시 내보낸다 확인 — side_effects/publish_seen_ids_to_kafka_side_effect.rs
• 유저 쪽 피처에는 나이, 추론된 성별, IP 위치 같은 인구통계가 들어간다 확인 — home-mixer/models/query.rs:24-95
  • 들어가는 필드로 user_age_in_years, user_inferred_gender, ip_location, subscription_level이 있다.
  • 토픽과 스타터 팩 쪽 필드로는 followed_grok_topics[32], inferred_grok_topics[32], followed_starter_packs[20]가 있다.
  • user_inferred_gender에는 전용 GenderPredictionGrpcClient가 있다.
  • 하이드레이터 쪽 근거는 phoenix_candidate_pipeline.rs:210-231이다.

↑ 목차

광고

공개 코드 기준으로 X For You는 유기 포스트 사이에 광고를 끼워 넣고, 광고 옆에 오는 포스트의 브랜드 안전 등급을 보고 광고 자리를 정한다 확인. 기본 광고 블렌더는 4세대+13 커밋(2026-09-01, 7ba7768)부터 multi-risk 블렌더다 확인(변경 이력의 4세대+13). 이 블렌더는 HighRisk 포스트 옆에는 어떤 광고도 놓지 않고, MediumRisk 포스트 옆에는 광고주가 그 맥락을 허용한 광고만 놓고, 그런 광고에는 MediumRisk 자리를 먼저 준다 확인(변경 이력의 4세대+10). 브랜드 안전 판정의 V2 판정 스위치와, 포스트 단위 Grok 안전 라벨이 없을 때 작성자 단위 라벨을 대신 넣는 fallback 스위치는 2026-10-15 커밋 기준으로 둘 다 기본 on이다 확인(변경 이력의 2026-10-15 커밋).

광고 블렌딩과 브랜드 안전 판정

공개 코드에는 광고 블렌딩이 전부 들어 있다. 이 점이 이번 공개에서 의외인 부분이다.

• 광고를 붙이려면 유기적 포스트가 최소 5개 있어야 한다 확인 — home-mixer/ads/util.rs:10
• 광고의 기본 간격은 {requested: 3, min: 2}이고, 최소 요청 간격은 3이다 확인 — ads/util.rs:12-17
• "안전 갭"의 절반까지만 광고를 넣는다 확인 — ads/partition_organic_blender.rs:35
  • 식은 max_from_safe = safe_count / 2다.
• 마지막이 광고면 잘라낸다 확인 — ads/util.rs:164-198
• 브랜드 안전성은 인접성 판정이다. 2026-09-01 커밋(4세대+13) 전까지 기본이던 partition_organic_low_risk 블렌더는 MediumRisk·HighRisk 포스트 옆에 광고를 붙이지 않는다(has_avoid()가 두 tier 모두 avoid로 본다). 4세대+13부터 기본인 multi_risk 블렌더는 BSR-high 광고를 MediumRisk 포스트 두 개 사이에 먼저 놓아 보고, 겹침 검사에 걸리면 Safe 자리로 넘긴다 확인 — multi_risk_blender.rs:68-179. 판정은 손으로 짠 규칙 캐스케이드에 Grok 채점 여부와 PTOS 심사 여부를 더해 내린다 확인 — home-mixer/models/brand_safety.rs:5-13, 15-22, 45-48
  • 2026-08-24 커밋(4세대+7, d011592)에서 BrandSafetyVerdict::HighRisk = 4 tier가 신설됐다 확인 — home-mixer/models/brand_safety.rs
    • 이전에 medium에 있던 5종과 신규 SOFT_NSFW가 HIGH_RISK_LABELS로 승격됐다. v1과 v2가 대칭이다.
      • 5종은 NSFW_HIGH_PRECISION·NSFW_HIGH_RECALL·GORE_AND_VIOLENCE_HIGH_PRECISION·PDNA·EGREGIOUS_NSFW다.
    • ads_brand_safety_vf_hydrator.rs의 NSFW ancestor 상속 escalation이 MediumRisk에서 HighRisk로 바뀌었다.
    • scored_posts_server.rs가 V2 라벨 5종의 proto HM enum 매핑을 새로 만들었다(다운스트림 노출 시작).
      • 5종은 GROK_SFA_V2·GROK_NSFA_LIMITED_V2·GROK_NSFA_V2·GROK_NSFA_EXPANDED_V2·PTOS_REVIEWED다.
• 인용 포스트 조회가 실패하면 비관적으로 MediumRisk로 강등한다 확인 — ads/../ads_brand_safety_hydrator.rs:144-145
• 4세대+2 (2026-08-17, b089ce6)에서 V2 판정 함수가 나란히 연결됐고, 4세대+3 (2026-08-18, 11a71f8)에서 그 시맨틱이 하루 만에 재설계됐다.
• 4세대+2 원안(b089ce6, 2026-08-17)은 V2용 라벨 목록 두 개와 마이그레이션 헬퍼, 검증 테스트를 넣었다 확인 — home-mixer/models/brand_safety.rs
  • MEDIUM_RISK_LABELS_V2는 16개다. V1과 비교해 GROK_NSFA가 GROK_NSFA_V2로 이름이 바뀌었고 GROK_NSFA_EXPANDED_V2가 신설됐으며, NSFA_HIGH_PRECISION을 포함한다.
  • LOW_RISK_LABELS_V2는 3개다. V1과 비교해 GROK_NSFA_LIMITED가 GROK_NSFA_LIMITED_V2로 이름이 바뀌었고, NSFA_LIMITED_INVENTORY를 포함한다.
  • 마이그레이션 헬퍼 strip_v1_grok_written은 V2 판정 전에 두 조건을 모두 만족하는 라벨을 입력 라벨 집합에서 제거한다.
    • 첫째 조건은 라벨이 NSFA_HIGH_PRECISION 또는 NSFA_LIMITED_INVENTORY인 것이다.
    • 둘째 조건은 그 라벨의 botmaker rule id가 PROMPT_OWNED_RULES = [1400, 1410, 1420, 1500, 1510, 1610, 1700] 7개 중 하나인 것이다.
    • 즉 V1 프롬프트가 dual-write한 라벨을 V2 로직이 무시하고, 순수 V2 라벨만으로 판단한다.
  • 검증 테스트 v2_mirrors_v1_across_tier_matrix는 6가지 라벨 조합 × 두 tweet_id 시점(PTOS_CUTOFF 전/후)에서 V1과 V2 판정이 정확히 일치해야 한다고 assert한다.
• 4세대+3 재설계(11a71f8, 2026-08-18)는 이 헬퍼를 지우고, V2가 쓴 라벨이 하나라도 있을 때만 V2로 판정하고 없으면 V1으로 폴백하는 게이트를 넣었다 확인 — home-mixer/models/brand_safety.rs
  • strip_v1_grok_written이 완전히 삭제됐다(Cow import까지 제거). 즉 어제 canon이 반영한 PROMPT_OWNED_RULES 7개 rule id 로직은 하루 만에 폐기됐다.
  • 대신 새 상수 V2_WRITTEN_LABELS가 생겼다. GROK_SFA_V2·GROK_NSFA_V2·GROK_NSFA_LIMITED_V2·GROK_NSFA_EXPANDED_V2의 4개다.
  • 새 게이트는 compute_verdict_v2 초입에서 V2_WRITTEN_LABELS 중 하나라도 라벨 집합에 있는지 검사한다. 없으면 compute_verdict(v1)으로 폴백하고, 있으면 순수 V2 라벨 세트로 판정한다.
  • MEDIUM_RISK_LABELS_V2에서 NSFA_HIGH_PRECISION이, LOW_RISK_LABELS_V2에서 NSFA_LIMITED_INVENTORY가 제거됐다. 즉 V2가 판정을 내리면 V1 heuristic 라벨은 무시된다.
  • 새 테스트 v2_defers_to_v1_when_v2_has_not_ruled는 결정적 케이스를 명시적으로 assert한다.
    • 특히 NSFA_HIGH_PRECISION + GROK_NSFA + GROK_SFA_V2 라벨 세트에서 V1 판정은 MediumRisk이고 V2 판정은 Safe다.
    • 즉 V2가 판정 신호(GROK_SFA_V2 하나)를 보내면 V1의 전통 heuristic까지 다 무시하고 V2 결정이 지배한다.
  • 해석: dual-write 마이그레이션 전략이 "V2 판정 시 특정 rule id를 필터"에서 "V2가 판정했으면 V2 결정, 아니면 V1 폴백"으로 옮겨 갔다. 후자가 훨씬 깔끔한 dual-write 시맨틱이다. V2 라벨러가 아직 도달하지 못한 포스트는 V1 안전망이 계속 잡고, 도달한 포스트는 V2가 완전히 대체한다.
  • 미공개: V1 판정 함수의 최종 제거 시점, V2 라벨러 커버리지, V2_WRITTEN_LABELS 4개 라벨의 유래(Grok 프롬프트 변경? 파이프라인 재훈련?)
• 4세대+7 커밋(d011592, 2026-08-24)이 브랜드 안전 판정에 HighRisk tier를 신설했다 확인 — home-mixer/models/brand_safety.rs
  • BrandSafetyVerdict::HighRisk = 4라는 네 번째 등급이 기존 Unspecified/Safe/LowRisk/MediumRisk 위에 신설됐다. enum discriminant를 4로 배정해서 worst_verdict()의 >= 비교가 자동으로 확장된다.
  • 5종이 medium에서 high로 승격됐다. 대상은 NSFW_HIGH_PRECISION, NSFW_HIGH_RECALL, GORE_AND_VIOLENCE_HIGH_PRECISION, PDNA, EGREGIOUS_NSFW다. 신규 1종 SOFT_NSFW도 HighRisk다. V1(compute_verdict)과 V2(compute_verdict_v2) 모두 HighRisk 체크가 최상단으로 이동했다.
  • V2도 대칭으로 바뀌었다. MEDIUM_RISK_LABELS_V2에서도 위 5종이 제거됐다. V2에는 원래 NSFW_HIGH_PRECISION·NSFW_HIGH_RECALL·GORE_AND_VIOLENCE_HIGH_PRECISION·PDNA·EGREGIOUS_NSFW가 있었다.
  • 광고 유틸은 두 tier를 모두 avoid로 대한다. home-mixer/ads/util.rs의 has_avoid()가 MediumRisk | HighRisk matches로 확장됐다(기존은 MediumRisk만).
    • 즉 인접성 판정에서 HighRisk 포스트에도 MediumRisk와 똑같이 광고를 붙이지 않는다.
    • 추가 조치는 아직 없고, 강도는 flag나 기록 목적일 가능성이 있다.
  • 인용 인접성도 승격됐다. ads_brand_safety_vf_hydrator.rs는 인용된 조상 포스트가 NSFW author면 verdict를 MediumRisk가 아니라 HighRisk로 escalate한다.
  • 다운스트림 노출이 시작됐다. scored_posts_server.rs의 safety_label_to_proto mapping에 V2 라벨 5종이 추가됐다.
    • 5종은 GROK_SFA_V2·GROK_NSFA_LIMITED_V2·GROK_NSFA_V2·GROK_NSFA_EXPANDED_V2·PTOS_REVIEWED다.
    • 이제 이 라벨들이 feed 응답 proto에 실제로 실려 나간다. 이전에는 V2 라벨이 내부 판정에만 쓰이고 다운스트림으로는 나가지 않았다.
  • DDG 실험 트래킹이 생겼다. ads_injection_logging_side_effect.rs가 EnableAdsBrandSafetyVerdictV2 experiment 버킷을 ddg_experiment_bucket = "experiment_id:bucket" 형식으로 로깅에 노출한다.
    • DDG는 광고 리포팅 파이프라인(Data Dashboard 또는 유사 시스템으로 추정 추정)으로 넘어가서 V2 실험군의 매출/안전 metric을 관측할 수 있게 한다.
    • 의미: V2가 아직 실험 단계(experiment 버킷팅)라는 방증이다. 4세대+2에서 V2 판정 함수만 도입됐고, 4세대+3에서 시맨틱이 재설계됐으며, 4세대+7에서 experiment 실측 인프라가 갖춰졌다.
  • 미공개: HighRisk tier가 광고 avoid 외에 어떤 후속 조치(랭커 강한 감쇠, 유기 노출 완전 차단 등)를 트리거하는지, V2 experiment의 홀드아웃/처리군 비율

광고 conversion 액션 대폭 확장 — 4세대+6 (2026-08-21, 28e414f)

Phoenix 랭커의 광고 매출 예측 헤드가 2026-08-21 커밋(4세대+6)에서 20개 늘고 학습 손실이 재편됐다 확인. 그 뒤 4세대+9 커밋(2026-08-26, 45b48ba)이 픽셀 발화 관련 헤드 3종을 더했고, 2026-09-17 커밋(4세대+23)이 delayed conversion 액션에 tier 2와 tier 3를 10종씩 더했다 확인.

4세대+6 이전에는 광고 conversion 계열이 사실상 몇 개(설치·click-attributed 컨버전)뿐이었다. 4세대+6 커밋으로 다음처럼 늘었다.

Proto에 ActionName 20개가 신설됐다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto

• MACT 6종 × click/view = 12개(171–182)가 생겼다.
  • MACT는 Mobile App Conversion Tracking이다. 광고 클릭·노출 이후의 앱 내 이벤트(구매·장바구니·레벨 달성·튜토리얼 완료·회원 가입·커스텀)를 광고에 귀속한다.
  • 이벤트마다 click-attributed(MACT_<이벤트>)와 view-attributed(MACT_VIEW_<이벤트>) 두 버전이 있다.
• View-through conversion 8개(183–190)가 생겼다.
  • 대상은 purchase·add_to_cart·checkout_initiated·sign_up·site_visit·session·landing_page_view·upper_funnel이다.
  • 각각 기존 click-attributed(ADS_PURCHASE_CONVERSION = 200 등)에 대응하는 view-through 헤드다.

engagement metric group이 바뀌었다 확인 — phoenix/xrex/data/recsys/constants.py

• ads_conversion_engagement_to_action_types에 신규 MACT 매핑 12개와 view-through 매핑 8개를 추가했다.
• 새 metric group ads_slim은 긍정 신호 3개와 부정 신호 4개, primary가 아닌 conversion click들만 학습한다. 광고 랭킹 라인의 slim signal 조합이다.
  • 긍정 신호는 open link, external link long dwell, video quality view다.
  • 부정 신호는 not interested, block, report, mute다.
• NEGATIVE_FEEDBACK_HEAD_INDICES에 CLIENT_TWEET_SEARCH_QUERY_REFORMULATED가 추가됐다. 유저가 검색 결과가 마음에 안 들어 쿼리를 재작성하면 부정 피드백으로 취급한다. xrecsys_search config와 방향이 같다.

Delayed feedback 학습 분기가 생겼다 확인 — phoenix/xrex/models/recsys_model.py

새 config 옵션은 4개다. 표의 기본값은 4세대+6 커밋 기준이다.

새 batch 필드는 두 개다.

• sample_source (bool)는 kafka record의 is_delayed_feedback 컬럼에서 들어온다. True면 이 샘플은 conversion delayed 재관측분이다.
• conversion_keep_mask (bool per-candidate)는 kafka conversionKeepMask 컬럼이다. False면 이 후보를 conversion 학습에서 제외한다.
  • sequence packing에서는 all(True)만 허용한다(연결되지 않은 경우).

새 메트릭 슬라이스는 fresh (delayed=0), delayed_clicked (delayed=1 & clicked=1), delayed_non_clicked (delayed=1 & clicked=0)다. condition_conversion_on_click이 delayed 학습에도 유지되므로 delayed 샘플이라도 "click 있었나"라는 조건 아래에서 conversion을 학습한다.

2026-09-18 커밋(4세대+24)에서 세 옵션이 단일 ads_head_masking: bool = False로 통합됐다. 세 옵션은 split_head_training_by_source·train_view_through_heads·condition_conversion_on_click이다. 세 슬라이스 이름(fresh·delayed_clicked·delayed_non_clicked)은 유지되고, 새 슬라이스 late_split_no_early가 추가됐다. Sample source는 3-값 카테고리컬(FRESH=0·EARLY_RELABEL=1·LATE_SPLIT=2)이다. twin 헤드 매핑은 변경 이력의 4세대+24에 정리했다.

의미: 4세대+6 커밋으로 광고 conversion 예측에 두 가지가 동시에 붙었다. 하나는 헤드 수의 대폭 증가(20개 신설)이고, 다른 하나는 delayed feedback 학습을 정식으로 분기 처리하는 인프라다. 이는 X 랭커 학습이 광고 delayed conversion prediction 문헌(Chapelle 2014 이후)의 표준 처리 방식과 명시적으로 정렬됐다는 신호다. 4세대~+5까지 canon이 반영해 온 랭킹 signal 채널·SID·SlateContext 확장 축과 별개로, 광고 매출 예측 스택이 새 축으로 붙었다.

4세대+9 (2026-08-26, 45b48ba)에서 픽셀 발화·long-dwell 결합 헤드 3종이 생기고 conv_asset_ids가 연결됐다 확인 — phoenix/python/common/xai-proto/proto/recsys.proto (+12)

• 다른 근거 파일은 phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto와 home-mixer/models/candidate.rs (+8)다.
• 새 ActionName 3종(191–193)이 생겼다.
  • 191 ADS_PIXEL_FIRE는 광고주가 자기 사이트/앱에 심어 둔 전환 픽셀(웹 트래킹 픽셀)이 발화하는 것이다. 웹 컨버전 이벤트를 직접 예측한다.
  • 192 ADS_LONG_DWELL_AND_PIXEL_FIRE는 픽셀 발화와 long dwell(랜딩 페이지에 오래 머무름)을 AND로 결합한다. 즉 픽셀만 터진 것이 아니라 유저가 실제로 오래 머무른 케이스다.
  • 193 P_LONG_DWELL_AND_PIXEL_FIRE의 접두 P_는 4세대+6 관행상 primary 또는 predicted target 계열을 시사한다 추정.
• ConvAssetIds message가 신설돼 PredictNextActionsRequest.conv_asset_ids = 18 필드로 연결됐다.
  • 구성은 impressed_time_ms(int64), author_id(int64), asset_id(int64)의 3배열이다.
  • Phoenix 서빙에 유저가 최근 노출된 광고 크리에이티브(asset) 이력을 요청 시에 함께 넘긴다.
  • 광고 asset이 여러 광고주에 재사용되거나 유저가 같은 asset을 여러 번 봤을 때 컨버전 예측에 이 이력을 참조한다 추정.
• home-mixer의 SlateContext struct에 Option<u32> 필드 두 개(SlateContext.recon_count_above, recon_gap_above)가 추가됐다.
  • served_slate_context의 recon 재구성 metrics를 세분화하는 필드다.
  • proto 쪽에는 아직 반영되지 않았다. proto에는 13번 reconCosMilli 필드만 있다.
  • home-mixer 로컬 연결이 proto 이관을 기다리는 상태다.
• 의미: 4세대+6이 광고 conversion 예측 헤드를 20개 대폭 확장한 것의 후속이다. 4세대+9는 픽셀 발화와 long dwell을 합성한 3종을 추가하고, asset 이력을 서빙 요청에 실을 채널을 만든다. constants.py나 models/recsys_model.py에는 아직 반영이 없다. proto 신설만 있으므로 학습·서빙 연결은 다음 커밋에서 볼 관측 포인트다.

4세대+13 (2026-09-01, 7ba7768)에서 DPA 제품 SID가 서빙 wire format에 실렸다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto, phoenix/python/common/xai-proto/proto/recsys.proto

Dynamic Product Ads(DPA)는 광고주가 상품 카탈로그를 업로드하면 X가 유저 맞춤으로 자동 생성해서 노출하는 광고 포맷이다. 이 커밋에서 DPA의 DpaProductInfo에 repeated int32 sid_codes = 8이 추가됐다. 즉 광고 DPA 제품에 대해 SID 코드가 요청 페이로드에 실려서 랭커로 들어간다. 이는 유기 post의 SID와는 별개 파이프라인이고, 유기 post SID는 이미 history_seq·candidate_seq의 post_sids로 실려 있다.

같은 커밋에서 DiscreteActionName enum에 reserved 214 to 252가 추가됐는데, 39개 자리를 미리 예약해 놓은 것으로 광고 conversion 액션이 앞으로 더 확장될 자리를 확보한 것이다 추정.

의미: 광고 DPA 랭킹이 SID 계열 시그널에 편입되기 시작했다. Phoenix 랭커의 4세대+13 SID recon 모드와 짝을 이루면, 광고 DPA 제품과 유기 post가 같은 SID 어휘 밑에서 표현될 가능성이 열린다. 다만 이 커밋만으로는 다음 세 가지를 알 수 없다.

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

4세대+23 (2026-09-17, 42266f3)에서 delayed conversion attribution이 3-tier로 확장됐다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto, phoenix/python/common/xai-proto/proto/recsys.proto

기존 reserved 214 to 252가 reserved 234 to 252로 좁혀지고, 214-233에 tier 2와 tier 3가 붙었다.

• Tier 2 10종(214-223)이 생겼다.
  • ADS_ATTRIBUTED_KEY_CLICK_CONVERSION_DELAYED_TIER_2·ADS_ATTRIBUTED_CLICK_CONVERSION_DELAYED_TIER_2·ADS_PURCHASE_CONVERSION_DELAYED_TIER_2·ADS_MID_FUNNEL_CONVERSION_DELAYED_TIER_2·ADS_ADD_TO_CART_CONVERSION_DELAYED_TIER_2·ADS_UPPER_FUNNEL_CONVERSION_DELAYED_TIER_2·ADS_WEB_CONVERSION_DELAYED_TIER_2·ADS_SEARCH_CONVERSION_DELAYED_TIER_2·ADS_SIGN_UP_CONVERSION_DELAYED_TIER_2·ADS_CHECKOUT_INITIATED_CONVERSION_DELAYED_TIER_2
• Tier 3 10종(224-233)은 동일 10종의 _TIER_3 대칭이다.

의미: 2026-09-01 커밋(4세대+12)이 넣은 *_DELAYED(204-213) 10종이 16일 만에 tier 2·3으로 확장됐다 확인 — 6384ca7의 recsys.proto:446-455. 이제 delayed 창은 하나가 아니라 시차별 3개 구간으로 나뉜다. Chapelle(2014)·Yasui&Sakata(2020) 계열의 delayed feedback 문헌이 시차별 mask로 propensity 편향을 완화하는 접근을 취해 왔는데, 이번 변경은 그와 방향이 일치한다 추정. 각 tier가 관측 창의 어느 구간을 커버하는지와 tier 간 loss weight 조합은 이번 커밋에 명시되지 않았다. 학습 config에서 mparams["*_tier_2_loss_weight"]류 값이 등장하는지가 관측 포인트다.

↑ 목차

Phoenix 학습·인덱스 (4세대에서 신설)

Phoenix는 4세대 공개(2026-08-13)부터 작은 모델을 end-to-end로 학습하고 서빙할 수 있지만, 프로덕션 checkpoint·데이터·infra는 공개되지 않았다 확인(학습 코드). 랭커의 dense-parameter optimizer는 2026-08-19 커밋(4세대+4)에서 Adam에서 Muon으로 바뀌었다 확인(학습 코드). home-mixer가 Phoenix 서빙이 계산한 slate context를 쓰는 경로는 2026-08-20 커밋(4세대+5)에 들어왔고, 그 게이트의 기본값은 false였다 확인(예측 출력). SID 재구성 입력과 StableHLO 번들 export는 4세대+13 커밋(2026-09-01, 7ba7768)에 들어왔고, 둘 다 기본 off였다 확인(입력 피처, 인프라).

학습 코드, optimizer, 학습 config

2026-08-21 커밋(4세대+6) 기준으로, 공개된 flagship 랭킹 config와 nano config는 프로덕션 홈 랭커와 같은 Muon optimizer 레시피를 쓴다 확인. 검색 랭킹용 학습 config는 2026-08-19 커밋(4세대+4)에서 For You 피드용 config 옆에 나란히 추가됐다 확인.

4세대 공개부터 Phoenix를 end-to-end로 실행할 수 있다 확인 — README.md #deployment-related-code.

• Cargo workspace, pyproject.toml, QUICKSTART, 합성 데이터 생성기가 함께 들어 있다 확인 — README.
• README가 밝힌 범위는 작은 모델이다: "a small model can be trained and served end-to-end". 이 README 기준으로 프로덕션 checkpoint·데이터·infra는 여전히 공개되지 않았다 확인 — README.
• loss와 negative sampling 세부는 심층 분석이 필요하다. optimizer는 2026-08-19 커밋(4세대+4)에서 공개됐다.

2026-08-19 커밋(4세대+4)에서 Phoenix의 dense-parameter optimizer가 Adam에서 Muon으로 바뀌었다 확인 — phoenix/xrex/optimizers/recsys/muon.py(240줄 신규).

• 같은 커밋에서 phoenix/xrex/optimizers/recsys/dense_optim.py(47줄)가 새로 생겼고, phoenix/xrex/configs/xrecsys.py의 기본 config가 바뀌었다.

Muon은 Newton-Schulz orthogonalization으로 gradient momentum을 근사 직교화하는 optimizer다. 이 코드의 Muon은 optax.contrib._muon을 감싸 쓰고, Phoenix ranker의 dense-parameter 기본 optimizer가 됐다. 적용 방식은 하이브리드다. matrix-shaped 파라미터만 Muon을 쓰고, 이름이 아래 패턴에 걸리는 파라미터는 여전히 Adam을 쓴다.

muon_adam_patterns = "embed,_emb,logits,vocab,norm,table"

다시 말해 임베딩 테이블, 출력 logits 헤드, vocab, norm(layernorm/rmsnorm)은 Adam에 남는다. Muon으로 가는 것은 트랜스포머 body의 attention·FFN weight matrix뿐이다. 이 구성은 Muon의 표준 하이브리드 패턴(Keller Jordan 2024와 Kimi/Moonshot K2 계열 라인)과 같다.

_home_direct_packed_base()의 기본 config는 아래 표처럼 바뀌었다.

GB300 override도 같은 방향으로 갱신됐다. 값은 Muon, LR 5e-4, half_life_steps=5000, weight_decay=0.01이다.

이 저장소가 반영해 온 대규모 프로덕션 recsys 학습 파이프라인 가운데 Muon 채택을 코드로 확인한 것은 이번이 처음이다. LLM 학습에서 시작된 optimizer가 랭커·retrieval 학습으로 넘어왔다는 관찰 축이 새로 생긴다. topics/sequence-transformer-ranking.md에 optimizer 축을 추가해야 한다.

2026-08-21 커밋(4세대+6)에서 Muon 학습 레시피가 export에 정식으로 포함됐다 확인 — phoenix/TRAINING.md.

• 같은 커밋에서 phoenix/README.md와 phoenix/reference/README.md도 바뀌었다.

canon의 이전 서술은 이랬다: "Phoenix export의 dense optimizer는 standard Optax AdamW, 프로덕션의 tuned RMS-normalized-Adam derivative는 미공개." Muon을 도입한 4세대+4에서 muon.py·dense_optim.py가 export된 뒤에도, TRAINING.md는 여전히 AdamW만 export한다고 적고 있었다. 이 커밋에서 TRAINING.md는 아래처럼 바뀌었다.

Two dense-parameter optimizer families ship in this export:

• Muon (xrex/optimizers/recsys/muon.py): the production home-ranker recipe — consistent-RMS scaling with decoupled weight decay on the matrix and embedding partitions. The flagship ranking configs and home_direct_packed_nano select it (optim="muon"), so the nano trains with the same dense-optimizer recipe production runs.
• Standard Optax AdamW: the slot used by the remaining shipped configs (two-tower retrieval, gen-recs, and the legacy ranking presets). ...

— phoenix/TRAINING.md

• flagship ranking config와 home_direct_packed_nano는 프로덕션 Muon 레시피로 end-to-end 학습한다 확인 — TRAINING.md. export의 nano 모델을 그대로 돌리면 프로덕션과 같은 Muon 학습이 된다.
• AdamW arm은 two-tower retrieval, gen-recs, legacy ranking preset에만 남는다 확인 — TRAINING.md. 이쪽은 여전히 프로덕션 tuned RMS-normalized-Adam derivative의 export-safe 등가물이다.
• flagship과 nano의 임베딩 rowwise AdaGrad에도 옵션 세 개가 함께 붙는다고 명시했다 확인 — TRAINING.md.
  • 세 옵션은 accumulator half-life decay, lazy per-row decay, decoupled weight decay다.
  • 4세대+4에서 들어온 emb_optim_config(LR 0.28, half-life 2500 step) 파라미터가 정본으로 굳었다.
• reference/README.md의 train_step.py 항목도 "dense optimizer + rowwise-AdaGrad"로 일반화됐다 확인 — reference README. reference 학습 스크립트는 AdamW arm을 구성하고, flagship·nano config는 Muon 레시피를 쓴다.

의미: 이 커밋으로 export되는 학습 파이썬 코드를 그대로 돌리면 프로덕션 Muon 레시피와 같은 학습이 되는 상태가 됐다. 4세대+4(2026-08-19)에 Muon이 코드로 들어왔을 때 canon의 이해는 "코드는 export됐지만 학습 레시피는 여전히 프로덕션 특화"였다. 재현성 문서가 좁혀졌지만 데이터와 infra는 여전히 공개되지 않았다(README caveat 유지).

같은 커밋(4세대+6)에서 nano config가 GB300 하드웨어 전용 오버라이드의 LR과 optimizer 설정을 물려받게 됐다 확인 — phoenix/xrex/configs/xrecsys.py:330-345.

• _GB300_OVERRIDES 자체는 4세대 공개부터 있었다(배치·EP·attention·remat·LR 항목) 확인 — xrecsys.py:305-313, 368. optimizer 항목은 2026-08-19 커밋(4세대+4)에서 더해졌다.
• 아래 블록은 4세대+6 시점의 값이다.

_GB300_OVERRIDES = {
    "bs_per_device": 512,
    "ep": 64,
    "attn_impl": "cutedsl_ranker_varlen_attn",
    "remat_policy": RematType.SAVE_GB300_RECSYS,
    "unroll_layer_stack": True,
    "learning_rate": 5e-4,
    "checkpoint_every_n": 300,
    "optim_config": RecsysDenseOptimConfig(
        optim="muon",
        muon_consistent_rms=0.2,
        muon_matrix_weight_decay=0.01,
        muon_split_fused="qkv:128",
        adam_embedding_weight_decay=0.01,
        b1=0.95,
        b2=0.98,
        ...
    ),
    ...
}

• bs_per_device=512는 이전 _home_direct_packed_nano의 bs_per_device=64의 8배다. GB300의 HBM 여유를 반영했다.
• ep=64는 expert parallelism을 64-way로 둔다.
• attn_impl="cutedsl_ranker_varlen_attn"은 NVIDIA CUTLASS/CUTe DSL 기반의 variable-length attention 커널이다. GB300에 최적화된 신규 impl이다.
  • 오픈소스 카탈로그에 이 이름이 없으므로, xAI 자체 커널일 가능성이 있다 추정.
• remat_policy=RematType.SAVE_GB300_RECSYS는 GB300 메모리 계층에 맞춘 rematerialization 정책이다.
• unroll_layer_stack=True는 트랜스포머 layer stack을 unroll해 컴파일한다. XLA 최적화 여지가 있다.
• checkpoint_every_n=300은 300 step마다 checkpoint를 저장한다.

_home_direct_packed_nano는 이 오버라이드의 LR, optim_config, emb_optim_config를 상속한다. 이전에는 nano가 따로 learning_rate=2e-3이었지만, 이 커밋부터 GB300 기준으로 통일됐다.

의미: X가 하드웨어 세대 전환을 코드에 드러낸 첫 사례다. NVIDIA GB300(Grace Blackwell 300)은 2025년 하반기에 출하가 시작된 최신 데이터센터 GPU로, Blackwell B200의 후속이다. LLM 회사들이 대량으로 확보하는 세대인데, xAI는 이 세대를 랭커 학습·서빙 파이프라인에도 그대로 적용했다. canon이 이전에 몰랐던 사실은 Phoenix 프로덕션 학습이 GB300에서 돈다는 것이다. nano조차 GB300 config로 튜닝됐다는 것은 export 자체가 GB300을 상정한 재현 시나리오라는 뜻이다.

H100용 remat 정책은 그 뒤 커밋에서 추가됐다 확인(변경 이력의 4세대+15 D).

2026-08-19 커밋(4세대+4)에서 Phoenix가 xrecsys_search config를 신설하며 검색 랭킹으로 확장됐다 확인 — phoenix/xrex/configs/xrecsys.py:435-473.

xrecsys_search는 For You 피드 학습 config xrecsys 옆에 나란히 추가됐다. For You config와 비교한 주요 차이는 다음과 같다.

• vocab이 크게 늘었다. 검색 쿼리·클릭 코퍼스는 사용자·아이템 다양성이 커서, For You config의 훨씬 작은 vocab보다 vocab을 키워야 한다.
  • 값은 user_vocab_size=100_000_000, item_vocab_size=100_000_000, author_vocab_size=30_000_000, ip_vocab_size=10_000_000이다.
• 아키텍처 값은 num_layers=8, emb_size=2560, emb_table_width=1024, query_heads=20, kv_heads=4(GQA), history_seq_len=1022, candidate_seq_len=64다.
• 분산 설정은 ep=512, dp=2, fsdp=1, tp=1이다. expert-parallel 512로 For You base config보다 EP 축이 훨씬 크고, MoE 라우팅도 검색 config에서 훨씬 크다.
• 검색에 특화된 플래그가 있다. use_product_surface=True는 제품 지면 컨디셔닝을 켜고, output_vocab_size=128은 action을 128종으로 늘린다.
  • 나머지는 condition_search_relevance_on_prompt=True, use_dense_action_table=True, metric_group="search"다.
• 학습 신호는 group_id="user_action_sequence_xrecsys"라는 별도 그룹을 쓰고, log_q_correction=True다.
• 학습 규모는 total_samples=1e11로 For You base와 같다.

의미: Phoenix가 For You 피드 랭커에서 검색 지면 랭커로 확장되고 있다. 이 config는 proto에서 161/162에서 105/106으로 번호를 옮긴 action 두 개(CLIENT_TWEET_RELEVANT_TO_SEARCH = 105, CLIENT_TWEET_NOT_RELEVANT_TO_SEARCH = 106)와 짝을 이룬다(예측 출력 스키마). 이전에 canon은 각 지면(For You, Following, 검색)이 별개 코드베이스라고 이해했다. 이 커밋으로 같은 Phoenix 트랜스포머 아키텍처가 지면별 config만 갈아 끼워 검색과 피드를 모두 서빙하는 방향으로 통합이 진행 중이라는 새 사실이 확인됐다. Netflix UniCoRn·GenRec의 "검색·추천 단일 랭커" 흐름과 방향이 같다(topics/llm-in-recsys.md).

2026-08-21 커밋(4세대+6)에서 two-tower retrieval의 nano config에 옵션 3개가 추가됐다 확인 — phoenix/xrex/configs/xrecsys_two_tower.py:429-431.

옵션이 들어간 곳은 MODEL_CFGS의 xrecsys_two_tower_nano 항목이다 확인 — xrecsys_two_tower.py:411-431. 이 항목은 combined base를 물려받지 않아서, 그전까지는 세 키 모두 모델 생성 코드의 기본값을 썼다 확인 — 같은 파일 530·627·675·681행. combined base에는 4세대 공개부터 세 키가 False·80.0·True로 있었고, 이 커밋은 base를 바꾸지 않았다 확인 — xrecsys_two_tower.py:274-275, 318.

• qk_norm=True
• attn_logit_cap=-1: logit capping을 끈다.
• right_anchored_rope=True: RoPE positional encoding을 right-anchored로 둔다.

LLM 학습의 안정성 트릭이 retrieval two-tower로 넘어왔다. 이와 별개로 EVERGREEN retrieval dataset 파일이 evergreen_video_1825day.parquet에서 video_4to14day.parquet로 극단적으로 축소됐다. 이름과 실체가 어긋난 상태이고, 임시적일 가능성이 있다 추정.

같은 커밋(4세대+6)에서 retrieval post-embedding 계산이 65k row 단위로 나뉘었다 확인 — phoenix/xrex/train/trainer_recsys.py _forward_chunked.

maybe_build_retrieval_post_embeddings는 이전에 shard 전체를 candidate_tower_forward_jit 한 번으로 계산했다. 이 커밋부터는 total_samples % data_world_size == 0인 균등 shard에서 _chunk_rows = min(_shard_rows, 65536) 단위로 나눠 계산한다. Muon 승격과 GB300 config로 학습 규모가 커지는 흐름에서 이 서브루틴을 안정화한 것이다.

예측 출력 스키마와 slate context

2026-08-19 커밋(4세대+4)에서 Phoenix 예측 출력 스키마에 reward 출력과 링크 열림 확률의 5분위 헤드가 생겼다 확인. home-mixer가 Phoenix 서빙이 계산한 slate context를 받아 쓰는 경로는 2026-08-20 커밋(4세대+5)에 들어왔고, 그 게이트의 기본값은 false였다 확인.

2026-08-19 커밋(4세대+4)에서 Phoenix proto에 reward 헤드와 link-open 5분위 헤드가 생겼다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto.

Phoenix 예측 출력 스키마는 두 방향으로 확장됐다.

1. RewardOutputs 메시지가 생겨, Phoenix가 확률 예측 헤드 24개 옆에 reward value 헤드와 policy logits 헤드를 나란히 낼 수 있는 스캐폴딩이 갖춰졌다 확인 — recsys.proto.
   • NextActionDistribution에 RewardOutputs rewardOutputs = 8 필드가 추가됐다. RewardOutputs의 두 필드는 스칼라 array인 values와 정책 로짓인 policyLogits다.
   • ScoreInfo에도 optional double rewardRerankSlotProb = 5가 추가됐다.
   • RL 스타일(actor-critic value+policy) 학습이나 reward-model-guided 재순위 슬레이트 결정에 쓰는 것으로 추정되며, 이 필드를 소비하는 스코어러는 아직 연결되지 않았다 추정. 아직 hidden state 스캐폴딩 단계다 추정.
   • 그 뒤 공개된 immersive 지면용 페이지 단위 RL 재순위기의 학습 코드는 rewardRerankSlotProbSeq 컬럼을 rl_rerank_prob로 읽어 페이지 RL 손실의 로깅 확률로 쓴다 확인 — recsys_batch.py:284, page_rl.py:206, 216, 233(변경 이력의 페이지 단위 RL 재순위기 커밋).
     • 이 컬럼이 서빙 응답의 rewardRerankSlotProb 필드를 모은 것이라는 연결은 이름이 같다는 점에 기댄 것이다 추정.
2. 링크 열림 확률을 단일 스칼라가 아니라 분위 5개(P10/P25/P50/P75/P90)의 분포로 예측하는 헤드가 생겼다 확인 — recsys.proto.
   • PLACE_HOLDER_167/168/169/170/253 다섯 자리가 각각 P_OPEN_LINK_P10·P_OPEN_LINK_P25·P_OPEN_LINK_P50·P_OPEN_LINK_P75·P_OPEN_LINK_P90으로 바뀌었다.
   • 이 커밋 전까지 X의 예측 헤드는 단일 확률·스칼라 계열이었다. 랭커에 분포 형태의 예측이 들어온 것은 이 헤드가 처음이다.

같은 proto 변경에는 이런 것도 있다.

3. 검색 관련성 action이 CLIENT_TWEET_RELEVANT_TO_SEARCH = 105와 CLIENT_TWEET_NOT_RELEVANT_TO_SEARCH = 106으로 다시 번호를 받았다 확인 — recsys.proto. 기존 161/162는 *_DEPRECATED로 남았다. 이 action은 xrecsys_search config와 짝을 이룬다.
4. SlateContext에 SID 필드 7개가 생겼다 확인 — recsys.proto. 필드는 sidKnown, sidK1/2/3, sidGap1/2/3이다. 2026-08-18 커밋(4세대+3)이 VMRanker에 SID를 연결한 것과 proto 수준에서 맞춘 변경이다.

다음 질문은 심층 분석이 필요하다.

• RewardOutputs가 실제로 어느 학습 루프에서 채워지는가. 이 커밋에서 recsys_model.py가 +265/−25로 크게 바뀌었다. actor-critic 헤드를 더했는지, reward model을 따로 학습하는지가 관건이다.
• link-open 5분위는 quantile regression인가, categorical mixture인가.
• xrecsys_search config는 프로덕션에 배포됐는가, 아직 오프라인 학습에만 쓰이는가.

2026-08-20 커밋(4세대+5)에서 home-mixer가 Phoenix 서빙이 계산한 slate context를 받아 쓰기 시작했다 확인 — home-mixer/models/candidate.rs:26-27, 76-77, 99-118.

• 나머지 근거는 home-mixer/scorers/phoenix_scorer.rs:107-125, home-mixer/scorers/ranking_scorer.rs:700-710, 806-825, 875-895, home-mixer/params/param.rs:243-249다.

4세대+4에서 Phoenix proto에 생긴 SlateContext.sid* 필드가 이 커밋에서 실제 파이프라인의 소비 경로에 연결됐다. 세 파일(candidate.rs, phoenix_scorer.rs, ranking_scorer.rs)에서 네 군데가 동시에 바뀌었다.

1. PostCandidate에 served_slate_context: Option<SlateContext> 필드가 새로 생겼다. 기존 slate_context(home-mixer가 로컬에서 계산한 뒤 캐시하는 값)와 나란한 두 번째 저장 슬롯이고, Phoenix 응답에서 온 slate context만 담는다.
2. proto와 Rust 사이의 변환 impl From<xai_recsys_proto::SlateContext>이 생겼다. 이 impl은 proto의 sid_k1/2/3·sid_gap1/2/3을 home-mixer 명명인 sid_k_l1/l2/l3·sid_gap_l1/l2/l3로 바꾼다. "l"은 level을 뜻한다.
3. PhoenixScorer가 예측 응답에서 slate context를 꺼내 이 필드에 넣는다. Phoenix 예측 응답이 후보 스코어 24개와 함께 SlateContext를 담아 오면 그대로 쓴다.
   • 이때 SlateContext에는 pool_rank, pool_rank_gap, fatigue, pre_diversity_score, sid_known, sid_k_l1/2/3, sid_gap_l1/2/3이 들어 있다.
   • 코드는 predictions.candidate_slate_context(&c.get_original_tweet_id()).map(Into::into)다.
4. RankingScorer는 세 갈래 폴백으로 어느 slate context를 쓸지 정한다. 새 게이트는 UseServedSlateContext이고 기본값은 false다.

   let persisted_contexts: Option<Vec<SlateContext>> =
       match Self::served_slate_contexts(query, candidates) {
           Some(served) => Some(served),
           None if query.has_cached_posts => Self::stored_slate_contexts(candidates),
           None => Some(Self::compute_slate_contexts(candidates, &weighted_scores)),
       };
   

   폴백은 위에서부터 차례로 적용되고, 두 랭킹 브랜치(mpn_scoring, diversity)가 모두 같은 폴백을 쓴다.
   1. 게이트가 켜져 있고 Phoenix가 모든 후보의 slate context를 보내 왔으면 그대로 쓴다.
   2. 게이트가 꺼져 있고 Redis 캐시가 히트하면 저장된 컨텍스트를 쓴다.
   3. 그 밖의 경우에는 로컬에서 계산한다.

의미: slate context를 계산하는 곳을 home-mixer 로컬에서 Phoenix 서빙으로 옮기는 마이그레이션의 첫 단계다. Phoenix는 예측을 만드는 순간 이미 각 후보의 pool 랭크·fatigue·pre-diversity·SID 3계층 정보를 알고 있다. 그러므로 home-mixer가 다시 계산하는 대신 서빙 응답에 실어 보내면 두 가지를 얻는다.

• (a) 랭커 CPU를 아낀다.
• (b) Phoenix가 가진 더 풍부한 컨텍스트를 반영할 수 있다. SID 3계층은 home-mixer가 로컬에서 계산할 수 없다.

2026-08-18 커밋(4세대+3)에서 SID가 VMRanker에 연결된 것과 방향이 같다. SID는 정의상 Phoenix 학습 산출물이라 로컬에서 계산할 수 없다. 이 커밋은 UseServedSlateContext를 기본 false로 두어 게이트만 열어 두었고, 실제 롤아웃은 후속 파라미터 변경으로 예정돼 있다. 앞으로 지켜볼 것은 이 게이트를 true로 올리는 커밋이다. 그 커밋이 Phoenix 서빙의 slate context가 프로덕션 트래픽에 반영되는 시점이다.

2026-08-21 커밋(4세대+6)에서 NextActionDistribution에도 SlateContext가 필드 #9로 추가됐다 확인 — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto.

SlateContext는 4세대+4에서 ScoreInfo의 필드 slateContext = 4로 처음 등장했다. 재순위 슬레이트 결정에 붙는 컨텍스트다. 4세대+5에서는 PostCandidate.served_slate_context로 연결돼 home-mixer가 쓰기 시작했다. 이 커밋에서는 각 후보의 action별 예측 분포인 NextActionDistribution에도 SlateContext slateContext = 9 필드가 추가됐다. 각 액션 분포마다도 slate context가 붙는 것이다. 이 커밋부터 slate context는 ScoreInfo와 NextActionDistribution 두 자리에 실릴 수 있다. 소비 경로는 아직 연결되지 않았고 스캐폴딩 단계다 추정.

랭커 입력 피처와 SID 재구성

Phoenix 랭커의 bool 입력 피처 세 개는 2026-08-14 커밋(4세대+1)부터 실제 값으로 채워진다 확인. 이 셋은 2026-08-19 커밋(4세대+4)에서 학습 기본 입력이 됐다 확인. SID 코드를 dense 벡터로 되돌려 랭커 입력에 더하는 recon 모드는 4세대+13 커밋(2026-09-01, 7ba7768)에서 공개됐지만, 공개 당시 기본값은 기존 learned 모드였다 확인.

2026-08-14 커밋(4세대+1)에서 Phoenix 입력 피처 3개가 새로 생겼다 확인 — phoenix/crates/common/xai-recsys/src/util.rs:456-540.

• 같은 커밋의 phoenix/crates/common/xai-recsys/src/model_config.rs:40도 근거다.

• 3세대부터 4세대 초까지의 코드에서는 bool_features가 vec![false; ...]로 전부 stamp돼 있어, 입력 자체가 실효가 없었다(canon 주의 목록의 "죽은 필드" 계열). 4세대+1에서 세 개가 처음 채워졌다 확인.
  • 근거는 patch의 bool_features: vec![false; ...] → bool_features: candidate_bool_features 교체다.
• stale 신호는 count zeroing과 bool set이 짝을 이뤄 들어간다. 랭커에게 "이 카운트가 낮은 이유는 인기 없어서가 아니라 오래돼서 노출이 끊긴 것"이라고 알려 주는 명시 라벨이다. 목적은 3세대의 snowball 문제를 완화하는 것이다 추정.
• is_mutual_follow 부스트(reply +15)는 스코어러에 하드코딩된 조건이었다. 이 커밋부터는 모델이 팔로우 방향을 개별 입력 bool로 받아, 학습으로 비슷한 패턴을 잡을 수 있다.
• 2026-08-19 커밋(4세대+4)에서 네 피처가 모두 train-default ON으로 승격됐다 확인 — phoenix/xrex/configs/xrecsys.py:270-290.
  • _home_direct_packed_base() 기본 config에서 enable_stale_post=True, enable_is_author_followed_by_viewer=True, enable_is_author_following_viewer=True, enable_engagement_counts=True 4개가 FeaturePrepConfig의 기본값으로 올라갔다.
  • 4세대+1에서 채워진 bool 3종이 이 커밋부터 학습 파이프라인의 기본 입력이다.
  • 별도로 grpc_recsys dataset type만 enable_stale_post=False로 override해, 실시간 서빙 경로에서는 stale 판정 stamp를 끈다. 끈 이유는 실시간에는 count zeroing이 위험할 수 있어서다 추정.

4세대+13 커밋(2026-09-01, 7ba7768)에서 Phoenix 랭킹 모델에 SID recon 모드가 들어왔다. 기본은 off다. 확인 — phoenix/xrex/models/recsys_sid.py(72줄 신규).

• 같은 커밋에서 phoenix/xrex/models/recsys_model.py가 +35/−2 바뀌었다.

이 커밋은 X가 RQ-VAE 계열 SID를 랭커 입력에 붙이는 경로를 코드로 처음 공개한 것이다. retrieval 모델을 SID로 바꾼 것이 아니라, SID 코드를 랭커 post tower의 입력 임베딩으로 재구성해 넣는 경로다.

_load_sid_decoder(path)가 오프라인 .safetensors에서 아래 텐서를 읽는다.

• stages는 형태가 (num_levels, codebook_size, code_dim)인 stacked residual codebook(RQ-VAE style)이다. 레벨마다 stages[l, code_l, :]를 골라 더한다. codebook 크기와 레벨 수는 아티팩트가 정하며, 코드에는 하드코딩되지 않았다.
• dec_w0·dec_b0·dec_w1·dec_b1은 2-layer MLP decoder(relu → linear)다. SID 시퀀스를 dense vector로 복원한다.

recon 함수 reconstruct_entity_sid는 SID 코드를 아래 순서로 랭커 입력 벡터로 바꾼다 확인 — phoenix/xrex/models/recsys_sid.py.

• (a) codes = sids - 1로 1-based를 0-based로 바꾸고, sids[..., 0] == 0인 행을 "missing"으로 표시한다.
• (b) 레벨마다 stages[l, code_l, :]를 뽑아 residual sum을 구한다.
• (c) 2-layer MLP와 relu로 복원한다.
• (d) L2 정규화한다(eps=1e-12).
• (e) missing 행을 0으로 마스킹한다.
• (f) stop_gradient로 decoder를 완전히 frozen 상태로 둔다.
• (g) recon_dim → target_dim 선형 project 하나({prefix}_sid_recon_proj, 학습 가능)만 매개변수로 둔다. 결과는 랭커 post tower에 맞게 dtype을 캐스팅해 반환한다.

모드는 config 게이트로 고른다 확인. RecsysAggregatedModelConfig에 두 필드가 추가됐다.

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

• 기본값 "learned"는 기존 SID 임베딩 테이블(post tower 안에서 학습되는 lookup)을 그대로 쓴다.
• "recon"으로 켜면 학습 SID 테이블을 우회한다. 대신 history_seq와 candidate_seq의 SID 코드에서 recon 벡터를 만들어 post tower 임베딩에 더한다(add).
  • 요구 조건은 legacy build_inputs 경로(feature_prep_enabled=False), sid_hash_level 미사용, sid_cross_attn 미사용, sid_decoder_path 지정이다.

의미

• X SID 라인의 첫 코드 공개다. 이번 커밋은 SID 코드 자체를 어떻게 dense feature로 되돌리는지를 처음 코드로 보여 준다. 이전까지 X의 SID 관련 공개 자료는 셋이었다.
  • (a) 4세대+3(11a71f8, 2026-08-18)에서 VMRanker에 sid_known·sid_k_l1/2/3·sid_gap_l1/2/3 필드가 연결됐다.
  • (b) 4세대+4(aad7179, 2026-08-19)에서 Phoenix proto에 SlateContext.sid* 필드가 생겼다.
  • (c) 4세대+5(d0cef2f, 2026-08-20)에서 서빙 응답의 slate context에 SID가 실려 오는 경로가 생겼다.
• decoder는 완전히 frozen이다. stop_gradient와 오프라인 아티팩트를 쓰므로 서빙에는 codebook과 MLP 매트릭스만 배포하면 되고, 학습되는 것은 recon_dim → target_dim project 하나뿐이다. codebook 튜닝은 오프라인에서만 이뤄지고, 랭커 학습이 codebook을 흔들지 않는다.
• "learned"와 "recon"이 A/B 축이 된다. 기본값이 그대로 learned인 것은 recon 모드의 프로덕션 유효성이 아직 검증되지 않았거나 dial-up 이전이라는 뜻으로 읽힌다 추정. 다음 커밋에서 sid_embedding_mode="recon"이 프로덕션 config에 나오면, X SID 파이프라인이 "학습 테이블"에서 "오프라인 codebook + 서빙 시 recon"으로 옮겨 갔다는 신호가 된다.
• 이 경로는 retrieval 모델이 아니다. codebook에서 벡터를 복원해 랭커 입력에 붙이는 것은 후보 표현의 밀도를 높이는 일이지, 후보 생성 자체를 SID로 대체하는 일은 아니다. Kuaishou OneRec, Tencent TGR(radar.md 생성형 retrieval 스레드)의 "SID를 autoregressive 생성 대상으로 삼는" 접근과는 계보가 다르다. 이 커밋 기준으로 X는 아직 캐스케이드 안에서 SID를 입력 신호로 쓴다. SID를 후보 생성에 쓰는 generative retrieval 소스는 그 뒤 기본 off로 공개됐다 확인(후보 생성 절).

이 커밋에서도 공개되지 않은 것이 있다.

• 아티팩트를 만드는 SID 학습 파이프라인(encoder와 VQ 학습)의 코드
• codebook 크기와 레벨 수의 실측 값
• 프로덕션에서 sid_embedding_mode="recon"이 켜져 있는지 여부
• learned와 recon 두 모드의 A/B 지표

Phoenix retrieval 인덱스

Phoenix retrieval이 조회하는 포스트 인덱스와, 포스트가 어느 인덱스에 들어갈지 정하는 이벤트 층이 4세대에서 공개됐다 확인. 포스트에는 인덱스에 들어가기 전에 visibility 판단이 붙는다 확인. 2026-08-17 커밋(4세대+2)부터는 좋아요가 없는 후보도 인덱싱 이벤트로 발행된다 확인.

4세대 공개에서 Phoenix retrieval 인덱스 서비스도 공개됐다 확인 — README.md #retrieval-index.

• phoenix-rankall/은 Phoenix retrieval이 조회하는 포스트 인덱스다. 이벤트가 도착하면 업데이트된다 확인 — README.
• phoenix-rankall-strato/는 포스트가 어느 인덱스에 속할지 정하는 이벤트 층이다. 이 층은 visibility-filtering을 먼저 참조한다 확인 — README.
• 2026-08-14 커밋(4세대+1)에서 SID window video_14day가 하나 추가됐다 확인 — phoenix-rankall/src/config/mod.rs:177-180.
  • 기존 video_48h·video_96h·nsfw_video_48h/168h/14day와 짝을 이룬다.
  • 2주 시간창의 비디오 인기도 신호가 retrieval SID에 들어갔다.
• 2026-10-20 커밋(4세대+45)에서 시간 단위 영상 window video_6h와 video_6hto2day가 더해져, SID 인덱스의 video window 가운데 가장 짧은 것이 48시간에서 6시간이 됐다 확인 — phoenix-rankall/src/config/mod.rs:212-213.

인덱싱 파이프라인은 랭킹 쪽 visibility 규칙과 이미 맞춰져 있다. 포스트에는 인덱스에 들어가기 전에 이미 visibility 판단이 붙는다. 3세대까지 canon이 완전히 몰랐던 아키텍처 사실이다.

2026-08-17 커밋(4세대+2)에서 인덱싱 게이트 두 개가 제거됐다 확인 — phoenix-rankall-strato/columns/phoenix_rank_all/phoenixRankAllCandidateProcessor.strato.

• build1FavIndex는 이 커밋부터 모든 후보를 발행한다. 다시 말해 "1fav" 인덱스 이름은 backward compat 라벨이 됐고, 실제 인덱스는 유입 후보 전체를 담는다.
  • 변경 전에는 favoriteCount >= 1인 후보만 "1fav" 인덱싱 이벤트를 Kafka로 발행했다.
  • 변경 후에는 favoriteCount == 0인 후보만 새 카운터 1fav_uec_count_race로 계측한다.
• buildMMEmbMetadataDump도 게이트가 사라졌고, 모든 후보에 대해 멀티모달 임베딩 세 버전을 fetch해 덤프한다.
  • 변경 전에는 같은 favoriteCount >= 1 게이트로 fav가 있는 후보만 세 버전(v3·v5_1·v6_dev)을 조회해 Kafka 메타데이터로 덤프했다.
• 새로 생긴 주의점이다. canon이 3세대~4세대에서 반영한 "phoenix-rankall이 인기 신호로 인덱스를 갱신한다"는 이해는 이 커밋부터 정확하지 않다. 인덱스 이름이 필터 조건을 뜻하지는 않는다.
• 의미: Phoenix retrieval이 롱테일 포스트에도 임베딩 기반 매칭을 시도할 수 있게 하는 인프라 확장 방향이다 추정. 다음 커밋에서는 두 가지를 본다. 1fav_uec_count_race 카운터의 실제 관측치가 어느 비율로 나오는지, 인덱스 커버리지 확대가 어떤 param 게이트(Phoenix retrieval의 top-k, SID window)와 짝지어 켜지는지다.

2026-08-18 커밋(4세대+3)에서 Phoenix postCreationEventForwarder가 unified posts topic V3로 마이그레이션됐다 확인 — phoenix-rankall-strato/stream_forwarders/postCreationEventForwarder.strato.

• 같은 커밋에서 phoenix-rankall-strato/columns/phoenix_rank_all/postCreationEventProcessor.strato도 바뀌었다.

• 이 마이그레이션은 콘텐츠 이해(content understanding) 도메인의 공유 이벤트 스트림을 v1에서 v3로 올린다. 바뀐 방향은 두 가지다.
  • (a) postId를 Kafka key로 올려, 파티셔닝·중복 제거·역인덱스 조회를 순수하게 key 기반으로 할 수 있게 했다.
  • (b) Phoenix retrieval용 Kafka 클러스터를 X 메인에서 떼어 내, 격리와 튜닝을 따로 할 수 있게 했다.
• hydra/sharedConfig로 import를 옮긴 것도 Phoenix 계열이 hydra 인프라 아래로 편입되고 있다는 신호다.
• 이 변경으로 Phoenix retrieval 인덱스 유지(build1FavIndex·buildMMEmbMetadataDump)의 upstream 이벤트 경로가 X 메인 Kafka에서 Phoenix 격리 Kafka로 완전히 옮겨 갔다. 4세대+2의 "인덱싱 게이트 제거"와 방향이 같다. 인덱싱 파이프라인의 처리량이 커지므로 별도 클러스터가 필요해졌다고 보면 방향이 들어맞는다 추정.
• 공개되지 않은 것도 있다. v2가 있었는지(v1에서 v3로 바로 뛰었는지, v2에서 v3로 가는 세 번째 마이그레이션인지), Phoenix Kafka 클러스터의 규모와 격리 이유, v1 forwarder의 최종 shutdown 시점이다.

학습·서빙 인프라

2026-08-20 커밋(4세대+5)은 임베딩 테이블 로더의 core를 pyo3에 묶이지 않은 함수로 따로 뽑았다 확인. 2026-08-21 커밋(4세대+6)은 hotswap 뒤 메모리를 돌려주는 옵션과 내부 오브젝트 스토리지 xai-o2의 인터페이스를 공개했다 확인. 학습한 랭킹 모델을 CUDA 서빙용 StableHLO 번들로 내보내는 경로는 4세대+13 커밋(2026-09-01, 7ba7768)에서 기본 off로 들어왔다 확인.

2026-08-20 커밋(4세대+5)에서 emb_table.rs가 Python wrapper와 pyo3-free core로 나뉘었다 확인 — phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs(+189/−169, 근본은 동치 리팩터).

기존 load_tensor는 pyo3 타입과 에러에 얽매여 non-Python 컨텍스트에서 재사용할 수 없었다. 이 커밋은 그 core를 아래 함수로 뽑았고, 기존 load_tensor는 pyo3 wrapper로 다시 정의됐다.

• load_tensor_into(&str, &str, &[(String, String, usize, usize)], &mut [u8], usize, usize) -> Result<(), String>

안전성도 보강됐다.

• tokio runtime의 unwrap()이 map_err로 바뀌었다.
• prefix.len() < 3 방어(checkpoint path too short: {path})가 추가됐다.
• modulo 체크가 is_multiple_of API로 통일됐다.

큰 임베딩 테이블(4세대+4 xrecsys_search의 vocab 100M/100M/30M)을 여러 서빙·학습 컨텍스트에서 로드해야 할 필요가 커지는 흐름에 대비한 리팩터 준비다 추정.

2026-08-21 커밋(4세대+6)에서 inference hotswap에 malloc_trim(0) 옵션이 생겼다 확인 — phoenix/xrex/inference/model_runner.py.

• 같은 커밋에서 launch_inference.py도 바뀌었다.

새 CLI 옵션 --hotswap_malloc_trim의 기본값은 True다. _malloc_trim_after_swap() 메소드가 hotswap cycle마다 마지막에 libc malloc_trim(0)을 호출한다. 관측 지표는 checkpoint_reload_step_seconds.labels(step="malloc_trim")이다.

CLI 도움말은 이렇게 쓴다.

glibc malloc_trim(0) on the coordinator thread after each applied hotswap; returns the cycle's freed pages (glibc slots otherwise ratchet ~196 MiB/cycle). No-op under jemalloc.

의미: Phoenix 서빙에서 embedding table hotswap이 glibc 아래에서 사이클마다 ~196MiB씩 RSS를 누수해 왔다는 사실이 처음 문서화됐다. hotswap은 프로덕션에서 오래 도는 인프라라, 이 패치가 필요할 만큼 누적 부담이 있었다는 관찰이다.

같은 커밋(4세대+6)에서 xai-o2 스토리지 crate의 인터페이스가 공개됐다 확인 — phoenix/crates/storage/xai-o2/.

Cargo.toml의 description은 이렇다.

Client interface for the xai-o2 (S3-compatible) object storage backend

crate는 파일 3개로 이뤄진다.

• base_client.rs(12줄)는 BaseO2Client async trait을 정의하며, 메서드는 put(key, data) -> Result<()> 하나뿐이다.
• o2_client_builder.rs(115줄)에서는 O2ClientBuilder가 builder method 15개를 제공한다.
  • endpoint·bucket·prefix·access_key_id·secret_access_key·allow_anonymous·timeout·io_timeout·retry_max_times(6)·retry_min_delay(1s)·retry_max_delay(32s)·write_chunk_size_mib(8)·write_chunk_concurrency(16)·max_concurrent_write_requests(64)·trace_always
• lib.rs는 7줄이다.

다만 오픈소스 빌드에서는 build()가 항상 아래 에러를 반환한다.

pub const BACKEND_UNAVAILABLE: &str =
    "the xai-o2 backend is not included in this build; use the default object_store backend";

xai-recsys-engine crate는 xai-o2 = { workspace = true }로 의존성을 선언했지만, 실제로 쓸 때는 표준 object_store crate로 폴백해야 한다.

의미: xAI 내부에 xai-o2라는 이름의 S3 호환 오브젝트 스토리지 시스템이 있다는 것이 처음 확정됐다. builder param 15개는 프로덕션에서 실제로 튜닝되는 항목이라 유의미하다. 프로덕션 checkpoint와 데이터 저장이 여기에 붙는다는 신호다 추정.

SID recon 모드와 같은 커밋(4세대+13)에서 StableHLO 번들 export 경로가 새로 생겼다. 기본은 off다. 확인 — phoenix/xrex/train/recsys_bundle_export.py(634줄 신규).

• 같은 커밋에서 phoenix/xrex/train/trainer_recsys.py가 +53/−0 바뀌었다.

진입점 build_bundle(trainer)는 랭킹 모델의 forward를 jax.export로 낮춘다. 대상은 RecsysAggregatedModelConfig뿐이고, RecsysGenRecsModelConfig는 명시적으로 unsupported다. export 결과는 세 가지다.

• jit(...).lower().as_text(dialect="stablehlo")로 만든 StableHLO MLIR bytecode(.mlirbc)
• jax_export.export(platforms=("cuda",)).serialize()로 만든 .jax_export
• MANIFEST.json

번들 구조에서 서빙 아키텍처의 특징이 드러난다.

• 임베딩 조회는 export된 그래프 밖에 있다. forward의 입력 merged_embeddings는 이미 룩업된 임베딩 로우들을 concat한 텐서다.
  • MANIFEST.embedding이 {rows, rows_padded, num_shards, width, dtype, merged_slices, hash_table}를 담고 있어, 서빙 측은 임베딩 서버 결과를 어떻게 concat할지 안다.
  • X 랭커의 서빙 아키텍처가 "임베딩 서버가 조회 → GPU 서버가 StableHLO 실행"이라는 분리 구조임이 코드에서 드러났다.
• batch bucket이 여럿이다. export_bundle_bs_per_device의 기본값은 "1,2,4"다. 버킷마다 별도 프로그램을 lower하고, 서빙할 때 요청 배치 크기에 맞는 버킷을 고른다.
• target은 CUDA뿐이다. MANIFEST에 device_kind와 compute_capability가 실린다.
• seqpack은 pallas_ranker_varlen_attn만 지원한다. FA4(cutedsl_ranker_varlen_attn)의 block-sparse 레이아웃은 명시적으로 NotImplementedError를 낸다.
  • 4세대+6의 GB300 config가 attn_impl="cutedsl_ranker_varlen_attn"을 쓰므로, GB300 학습 config를 그대로 export하려면 attn kernel을 pallas로 바꿔야 한다 관찰. 이 제한이 GB300 학습에서 GB300 서빙으로 가는 파이프라인의 단절점이다 관찰.
• custom-call target이 매니페스트에 실린다. ranker 전용 pallas/CUDA 커널이 StableHLO에 baked-in돼 있어, 서빙 로더가 커스텀 콜을 허용해야 한다. 허용 범위는 jax_export.DisabledSafetyCheck.custom_call(...)로 넓힌다.
• sid_num_levels가 매니페스트 prep_spec에 echo된다. 서빙 측은 이 값으로 SID 레벨을 몇 개 배치에 실을지 안다. 이 필드는 SID recon 모드와 짝을 이룬다.

번들 export를 켜고 조정하는 것은 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

export_stablehlo_bundle이 켜졌는데 checkpoint_config.copy_port가 꺼져 있으면 __post_init__에서 ValueError가 난다. 다시 말해 export는 checkpoint 배포 파이프라인의 copy_port(hot checkpoint 배포)에 붙어서만 켜진다. copy_port 배포 때마다 {OUT_PATH}/.{prefix}/export/에 번들이 함께 나간다.

의미

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

아직 공개되지 않은 것도 있다.

• 서빙 로더(StableHLO를 소비하는 런타임)의 코드
• 임베딩 서버가 merged_embeddings 텐서를 구성하는 세부 규약. MANIFEST.embedding의 merged_slices 스키마는 코드에 있지만, 소비자 측 코드는 공개되지 않았다.
• 프로덕션에서 이 번들이 켜져 있는지 여부

4세대+13 커밋은 학습 체크포인트를 envelope encryption으로 암호화해 저장하는 Orbax writer를 추가했다. 기본값은 off다. 확인 — phoenix/python/training/xai-checkpointing/xai_checkpointing/orbax_encrypted.py

링크한 orbax_encrypted.py는 새로 생긴 288줄짜리 파일이고, phoenix/xrex/train/misc.py(+5/0)와 phoenix/xrex/train/checkpoint_write.py(+6/0)도 함께 바뀌었다 확인 — 같은 커밋.

envelope encryption은 데이터를 데이터 키(DEK)로 암호화하고, 그 데이터 키를 다른 키로 다시 암호화해 두는 방식이다.

이 writer는 Orbax PyTreeCheckpointHandler를 감싸 다음을 강제한다.

• 체크포인트의 모든 파일은 매직 헤더로 시작해야 한다. 헤더가 없는 파일이 하나라도 있으면 커밋을 거부한다 확인 — 같은 커밋.

  • 매직 헤더 값은 b"XAIENC01"다.
  • finalize 뒤에 assert_all_enveloped(path)가 checkpoint 디렉터리를 walk한다. 헤더 없는 파일을 찾으면 RuntimeError("encrypted save left plaintext at rest; not committing: ...")를 낸다.
  • _DEK와 _DEK.claim(KMS가 발급한 DEK 파일과 그 claim)은 예외다.

• 리프는 jax.Array만 허용하고, 문자열·dict·Python scalar 리프는 명시적으로 거부한다 확인 — 같은 커밋.

  • 가드는 _ArraysOnlyRegistry와 _require_array_leaves다.
  • 이 가드는 서빙 측에서 이 checkpoint를 로드할 때의 임의 코드 실행 리스크를 없앤다.

• tensorstore KvStore도 암호화된 wrapper로 교체한다 확인 — 같은 커밋.

  • 해당 옵션은 use_encrypted_kvstore다.

• 메타데이터도 암호화한다 확인 — 같은 커밋.

  • _METADATA, _CHECKPOINT_METADATA, sharding metadata를 모두 encrypt_write로 쓴다.

• 암호화된 checkpoint에서 restore한 프로세스는 평문으로 저장할 수 없다(downgrade 금지) 확인 — 같은 커밋.

  • 새 가드는 checkpoint_write.py에 있다.
  • 평문 저장을 시도하면 ValueError("restored from an ENCRYPTED checkpoint but the orbax writer cannot produce encrypted saves — refusing to downgrade to plaintext saves")를 낸다.

• 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 필드는 AWS-KMS의 encryption-context 패턴을 그대로 따른다.
  • 청크 크기의 기본값은 8 MiB다.

의미

• 학습 체크포인트를 저장 상태(at rest)에서 암호화하는 writer가 코드로 들어왔다 확인. X가 프로덕션에서 이 writer를 쓴다고 본다 추정. 근거는 downgrade 금지 가드처럼 운영 사고를 겨냥한 장치까지 들어 있다는 점이다.
  • 이전에는 인프라 층에서 처리하는 것으로만 짐작할 수 있었다(canon 미확인).
  • 이제는 xrex 학습 파이썬 코드에 envelope encryption, KMS, 매직 헤더 강제가 in-tree로 들어 있다.
  • 소스는 규제 프레임워크(SOC2·FedRAMP·GDPR 등)를 명시하지 않았다. 일반적인 "data at rest" 보호로 읽힌다.
• CheckpointConfig.encrypt는 기본 False이고, 2026-10-17 커밋(862a123)까지 공개 학습 config 가운데 이 값을 켜는 곳은 없다 확인 — phoenix/xrex/train/misc.py:56. 그래서 프로덕션이 실제로 이 writer를 쓰는지는 코드만으로 확정할 수 없다.
• downgrade 금지 가드가 특히 눈에 띈다. 실수로 암호화 상태를 잃는 일을 코드 수준에서 원천 차단한다.
  • 4세대+7의 VF reference_compare 하니스가 APP_ENV=prod에서 부팅하면 panic을 일으켜 스테이징 전용을 강제했던 것과 같은 방향이다.
  • 두 경우 모두 정책을 config 값이 아니라 fail-close 어설션으로 코드에 굳힌다.

다음은 공개되지 않았다.

• kms_client의 실제 구현(파일 안에서는 밖에서 넘겨받는다)
• DEK 회전 주기
• encryption context의 실제 사용 값
• 어느 KMS(AWS·Azure·자체)를 쓰는지

↑ 목차

Grox (LLM 주석) — 3세대 그대로 (+ 2026-08-14 임계 상향)

Grox는 Grok 기반의 nearline 주석 파이프라인이다. 답글 스팸 판정과 답글 랭킹 채점 대상을 가르는 팔로워 임계는 2026-09-24 커밋(4세대+28)부터 250k다. 스레드 root와 답글 대상이 모두 이 값 이하인 답글은 스팸 판정을, 하나라도 넘는 답글은 답글 랭킹 채점을 받는다 확인. 이 임계는 4세대 공개의 15k에서 시작해 열한 번 올랐고, 올릴 때마다 스팸 판정 대상은 넓어지고 답글 랭킹 채점 대상은 좁아졌다 확인. 별도였던 스팸 감지 흐름은 2026-08-18 커밋(4세대+3)에서 답글 랭킹 흐름에 흡수됐다 확인. 두 임계는 그 뒤에도 바뀌었고, 바뀐 값은 변경 이력에서 coordinated spam 임계를 10k에서 30k로 올린 커밋의 임계 이력 정리와 답글 스팸 모델을 스레드 팔로워 기준으로 나눈 커밋에 있다 확인.

grox/는 slop score, 안전 라벨, 토픽, 답글 점수, 멀티모달 임베딩을 만든다. 4세대에서는 grox/가 상위 labeling 파이프라인의 Content Understanding 1단계로 명시적으로 자리 잡았다(안전성 절). 자세한 내용은 llm-in-recsys.md에 있다.

2026-08-14 커밋은 답글 스팸 판정과 답글 랭킹 채점의 팔로워 임계를 두 배로 올렸다 확인 — grox/flows/reply_spam/task_filter.py:17,185.

• grox/flows/reply_spam/task_filter.py의 두 임계 상수가 15000 → 30000으로 바뀌었다.
  • TaskSpamFilter.FOLLOWER_COUNT_THRESHOLD_FOR_SPAM_DETECTION: 15,000 → 30,000
  • TaskReplyRankingFilter.FOLLOWER_COUNT_THRESHOLD_FOR_REPLY_RANKING: 15,000 → 30,000

의미: 스레드 root와 답글 대상이 모두 팔로워 30k 이하인 답글은 grok 스팸 판정을, 하나라도 30k를 넘는 답글은 답글 랭킹 채점을 받는다 확인 — task_filter.py:77-92, 214-225. 임계를 두 배로 올려 스팸 판정 대상은 넓히고 답글 랭킹 채점 대상은 좁혔다. 원 코드 상수 이름에 "spam detection"·"reply ranking"이 붙어 있어, 이 조정은 어느 답글에 grok 리소스를 쓸지 정하는 리소스 배분 조정이다.

2026-08-18 커밋(4세대+3, 11a71f8)은 두 임계를 다시 올리고, 별도였던 스팸 감지 흐름을 답글 랭킹 흐름에 합쳤다 확인 — grox/flows/reply_spam/.

• 두 상수 모두 40,000 → 60,000으로 올랐다 확인 — 같은 커밋. 2026-08-17 커밋(4세대+2)의 30,000 → 40,000에 이은 세 번째 상향이다(b089ce6의 task_filter.py:17, 185).
  • root와 답글 대상이 모두 60k 이하인 답글만 grok 스팸 판정 대상이 되고, 나머지 답글은 답글 랭킹 채점을 받는다.
  • 스팸 판정과 답글 랭킹 채점을 가르는 경계가 40k에서 60k로 옮겨 갔다.
• post 전체 스트림에서 스팸을 감지하던 별도 task generator가 삭제되고, spam detection이 답글 랭킹 흐름으로 흡수됐다 확인 — 같은 커밋.
  • 삭제된 generator는 PostStreamTaskGenerator다. TOPIC_UNIFIED_POSTS(v3 아닌 원본) 상수도 삭제됐다.
  • 남은 ReplyRankingTaskGenerator가 아래 세 플랜을 함께 주입하고, TOPIC_UNIFIED_POSTS_V3 단일 소스에서 소비한다.
    • PlanReplyRanking(기존)
    • PlanSpamComment(신규 흡수)
    • PlanCoordinatedSpam(신규 흡수)
• 의미: grox 스팸 판정 파이프라인은 판정 대상 계정 확대(60k 이하)와 흐름 단일화로 정리됐다 확인 — 같은 커밋. 단일화는 reply ranking과의 통합을 가리킨다.
  • 이 변경은 Phoenix unified_posts_v3 topic 마이그레이션(Phoenix 학습·인덱스 절)과 같은 커밋에서 나왔다. 그래서 grox와 Phoenix 양쪽이 v3 콘텐츠 이해 스트림으로 동시에 옮겨 갔다는 관찰이 붙는다.

4세대+6 커밋(2026-08-21, 28e414f)은 두 상수를 모두 60,000 → 80,000으로 올렸다 확인 — grox/flows/reply_spam/task_filter.py.

• 3일 만의 네 번째 상향이고, 폭은 1.33배다.
• 임계는 4세대 공개 뒤 8일 사이 네 번 올랐다(15k → 30k → 40k → 60k → 80k).
• 첫 상향(2배) 뒤로 폭이 1.33~1.5배로 줄어든 것은 grok 예산 병목 근접, 그 이상 계정에서 스팸 답글 유입이 적어 생긴 marginal utility 감소, 다음 단계에서 임계 없이 전면 온으로 넘어갈 준비 가운데 하나다 추정.

이 절의 변경 이력은 다음과 같다. 값은 TaskSpamFilter와 TaskReplyRankingFilter가 함께 쓰는 임계이고, 각 커밋의 task_filter.py와 constants.py에서 확인했다 확인.

• 2026-08-13(4세대 공개): 15k
• 2026-08-14(4세대+1): 30k
• 2026-08-17(4세대+2): 40k
• 2026-08-18(4세대+3): 60k
• 2026-08-21(4세대+6): 80k
• 2026-08-24(4세대+7): 100k
• 2026-08-25(4세대+8): 120k
• 2026-09-08(4세대+17): 150k
• 2026-09-16(4세대+22): 180k. 상수가 GROK_GEMMA_FOLLOWER_SPLIT으로 바뀌었다.
• 2026-09-17(4세대+23): 200k
• 2026-09-23(4세대+27): 225k
• 2026-09-24(4세대+28): 250k. 2026-10-17 커밋(862a123)에서도 250k다.

↑ 목차

Grox → PtOS Adult Content Cross-Validation (4세대+2 신규, 2026-08-17)

grox 안전 판정의 심판(judge)은 1차 판정을 Grok 모델에게 한 번 더 판단하게 하는 계층이다. 성인 콘텐츠 심판은 2026-08-17 커밋(4세대+2)에서, 아동 안전·폭력 미디어·불법·규제 행위를 함께 맡는 심판 클래스(cross-validator)는 2026-08-24 커밋(4세대+7)에서 생겼다 확인(판정 흐름, 모델 변천). 두 심판은 각각 생긴 커밋(4세대+2와 4세대+7) 기준으로 1차 판정을 유지하거나 강등할 뿐, 더 엄격하게 바꾸지 않는다 확인(판정 흐름, 모델 변천). 그 뒤 고인기 영상 경로와 leading-frames 재스캔 경로에도 cross-validation 단계가 들어갔고, 불법·규제 행위 심판은 모델이 바뀌었다 확인(고인기 영상 경로를 만든 커밋, 4세대+15 B, 4세대+17).

표의 심판 모델 칸은 칸에 적은 커밋 기준이고, 나머지 칸은 심판 클래스가 생긴 커밋 기준이다.

• 불법·규제 행위 심판은 심판 모델을 카테고리별로 나눈 커밋(4세대+15)부터 EAPI_GROK_4_5_X_ALGO 대신 표의 모델을 쓰고, 이 모델은 서킷브레이커 없이 직접 호출한다 확인(변경 이력의 4세대+15 B).
• motion-reveal 기반 특수 영상 파이프라인을 만든 커밋의 고인기 영상 전용 경로에도 성인 콘텐츠 cross-validation 단계가 있다 확인(이 경로를 만든 커밋).
  • 그 커밋 기준으로 이 경로만, 심판 호출이 예외로 실패하면 원 판정을 유지하지 않고 Soft로 강제 강등한다(다른 경로는 원 판정 유지가 기본) 확인 — 같은 소절.
• 4세대+17 커밋에서 생긴 성인 콘텐츠 leading-frames 재스캔 경로에도 cross-validation 단계가 있다 확인(변경 이력의 4세대+17).
  • 4세대+17 기준으로 이 경로는 30초 이상 영상의 앞 10초만 잘라 다시 판정한다 확인 — 같은 소절.
  • 4세대+17 기준으로 진입 대상은 fav 수가 deluxe 임계 이상이고, 이미 PTOS 판정을 받았지만 NSFW로 판정되지 않은 영상 가운데 일부다 확인 — 같은 소절.
  • broadcast를 PTOS 안전 파이프라인에 편입한 커밋(4세대+18)에서 이 경로는 deluxe fav 게이트가 빠졌고, 30초 이상 영상이 없어도 broadcast가 있으면 진입하게 됐다 확인(변경 이력의 4세대+18).
  • 4세대+17 소절은 이 경로를 강등된 판정을 다시 뒤집을 수 있는 두 번째 심판으로 본다.

성인 콘텐츠 심판의 판정 흐름

성인 콘텐츠 판정에 판정 불일치에 대비한 심판(judge) 계층이 붙었다. 4세대에서 처음 공개된 grox 안전 파이프라인은 두 판정을 병렬로 돌리고, 결과가 다를 때는 로그만 남겼다.

• 두 판정은 TaskSafetyPtosSafemodelSexNudity(자체 비전 모델 기반 sex/nudity 판정)와 PtOS(정책 기반 위반 카테고리 판정)다.
• 2026-08-17 커밋(4세대+2)에서 이 로직이 두 파일로 나뉘었고, 두 판정이 어긋날 때(disagreement) Grok 4.5 심판이 다시 판단하는 새 태스크가 추가됐다 확인 — grox/flows/ptos/task_safety_ptos_adult_content_cross_validation.py (162줄 신규)
  • safemodel 태스크는 grox/flows/ptos/task_safety_ptos_safemodel_sex_nudity.py로 옮겨졌다(32줄 이동).
  • 심판 클래스는 grox/flows/ptos/classifier.py:597-608에 새로 생겼다.

심판 태스크는 네 단계로 동작한다.

1. 두 판정을 비교한다. enum CompareOutcome이 BOTH_POSITIVE·BOTH_NEGATIVE·SAFEMODEL_ONLY_POSITIVE·PTOS_ONLY_POSITIVE를 구분한다. is_disagreement는 SAFEMODEL_ONLY 또는 PTOS_ONLY일 때 true다.
2. 게이트 두 개를 확인한다.
   • deluxe 플로우에서만 동작하고, 일반 플로우는 로그만 남긴다. 조건은 is_deluxe = ctx.payload.task_type == SAFETY_PTOS_DELUXE다.
   • 이미 NSFW 플래그된 포스트면 건너뛴다. 플래그는 StratoSafetyPostAnnotationsResultDirectMh로 조회한다.
3. Grok 4.5 심판을 부른다. 새 클래스 SafetyPtosAdultContentCrossValidationJudge가 ModelName.EAPI_GROK_4_5_X_ALGO를 쓴다.
   • 전용 서킷브레이커는 실패율 50%, 600초 창, 회복 600초, half-open 5회다.
   • system 프롬프트는 _strip_thinking_restrictions(adult_content_policy_prompt())다. user 메시지는 UserRenderer.render(user)와 PostRenderer.render(post, include_reply_to=True)로 만든다.
   • 응답은 re.compile(r"(.*)<json>(.*)</json>", re.DOTALL)로 파싱해, 자유 텍스트 사고 과정과 JSON 판정을 나눈다.
4. 심판 결과를 적용한다. 심판이 AdultContentSexualHard이면 원래 판정을 유지한다. 그 밖의 결과이면 세 가지를 한다.
   • 모든 AdultContent 위반의 safetyPolicy.policyType을 AdultContentSexualSoft로 강등한다.
   • 강등된 위반에 reason = "Grok 4.5 Cross Validation disagreed"를 적어 감사 로그에 남긴다.
   • safemodel_sex_nudity.positive를 false로 바꾼다.

이 설계에서 눈여겨볼 점은 네 가지다.

• 강등 방향(hard → soft)만 있고 격상 방향은 없다.
  • 이 심판 계층은 과다 게이팅을 완화하는 방향으로만 작동한다.
  • false negative가 아니라 false positive를 줄이려는 정책 방향을 코드에서 관찰할 수 있다.
• 답글이면 부모 포스트도 컨텍스트로 넣어서, "이건 그 포스트에 대한 반응이다"라는 맥락이 판정에 영향을 준다(include_reply_to=True).
• 심판 컨텍스트에서는 원 프롬프트에 담긴 "사고 과정 노출 금지" 유의 제약을 _strip_thinking_restrictions()로 벗겨, 사고 과정을 볼 수 있게 한다(감사 목적).
• 판정 계층은 safemodel, PtOS, Grok 4.5 심판의 세 층이 됐다. 4세대의 "labeling 파이프라인 통째 공개" 흐름과 방향이 같다.

심층 분석이 필요한 질문은 세 가지다.

• 이 심판 계층이 다른 카테고리(폭력·혐오·스팸)로 확장되는가
• Grok 4.5 추론 비용을 어느 정도까지 소화할 수 있는가
• EAPI_GROK_4_5_X_ALGO 모델이 기존 EAPI_GROK_4_5_INTERNAL과 어떻게 다른가. 아마도 x-algorithm 전용 튜닝과 내부 일반 심판의 차이다.

2026-08-18 커밋(4세대+3)은 이 태스크의 로깅을 개선했다.

• Metrics.counter(metric)의 outcome attribute가 "hard"|"soft" 이분 라벨에서 판정된 policyType.value 원본으로 바뀌었다 확인 — grox/flows/ptos/task_safety_ptos_adult_content_cross_validation.py:128-131
  • 심판이 hard/soft 이외의 policyType(예: 다른 성인 카테고리 세분화)을 반환해도 손실 없이 관측할 수 있게 됐다.
  • 계측 세분화 조정이지 판정 로직 자체의 변경은 아니다.

심판 모델과 심판 대상 카테고리의 변천

4세대+7까지의 변화로 X는 primary와 judge를 서로 다른 모델 세대·튜닝으로 유지하는 이중 스택을 굳혔다. PTOS 분류기에서 Grok 4.5 internal을 부르던 두 호출 위치(아동 안전 심판과 고-fav deluxe 재분류)는 2026-08-19부터 08-21까지 세 커밋에 걸쳐 Grok 4.6 internal로 넘어갔다 확인(28e414f의 분류기). 사흘 뒤인 2026-08-24 커밋(4세대+7)에서는 4세대+2의 성인 콘텐츠 심판이 쓰던 4.5 X_ALGO 엔드포인트를 새 심판 클래스도 쓰게 됐고, 범위도 3개 카테고리로 넓어졌다 확인(d011592의 분류기).

4세대+4부터 +6까지 4.5 internal을 쓰던 두 호출 위치가 4.6 internal로 옮겨 갔고, 4세대+7에서 아동 안전 심판은 새 cross-validator 클래스로 옮겨 4.5 X_ALGO를 쓰게 됐다. 성인 콘텐츠 심판은 4세대+2부터 4.5 X_ALGO를 그대로 쓴다 확인. 커밋별 흐름은 다음과 같다.

• 4세대+2(b089ce6, 08-17): 성인 콘텐츠 전용 심판 SafetyPtosAdultContentCrossValidationJudge가 생겼다(safemodel↔PtOS disagreement 시). 모델은 EAPI_GROK_4_5_X_ALGO이고, 이 엔드포인트와 전용 서킷브레이커도 이 커밋에서 생겼다 확인 — classifier.py:85, 100, 561.
• 4세대+3(11a71f8, 08-18): 위 심판의 metric outcome을 세분화했다.
• 4세대+4(aad7179, 08-19): Grok 4.6 internal을 10% dial로 붙였다(고-fav deluxe 재분류와 아동 안전 심판 두 위치).
• 4세대+5(d0cef2f, 08-20): 4.6 internal dial을 10% → 30%로 올렸다.
• 4세대+6(28e414f, 08-21): 4.6 internal로 100% 전환했고, 4.5 internal은 코드에서 완전히 제거됐다.
• 4세대+7(d011592, 08-24): 4세대+2부터 성인 콘텐츠 심판이 쓰던 EAPI_GROK_4_5_X_ALGO를 새 cross-validator 클래스도 쓰게 됐고, 범위가 3개 카테고리(child safety, violent media, illegal)로 넓어졌다.
  • 성인 콘텐츠 심판은 별개 클래스(SafetyPtosAdultContentCrossValidationJudge)로 여전히 유지된다.

심판이 primary와 같은 모델이면 같은 실수를 확대 재생산하므로, 별개 모델의 관점이 강등만 허용하는 것이 이 설계의 합리다.

2026-08-19 커밋(4세대+4)은 Grok 4.6 internal을 트래픽 10%에 붙이고, NSFW 재분류를 건너뛰기 위한 캐시를 추가했다. 확인

판정 스택이 두 방향으로 정교해졌다.

• 첫째, 아동 안전 심판과 고-fav deluxe 재분류에 Grok 4.6을 도입했다 확인 — grox/flows/ptos/classifier.py (+66/−7)

  • 새 모델명 ModelName.EAPI_GROK_4_6_INTERNAL을 등록하고, EapiSampler 인스턴스와 전용 서킷브레이커(_eapi_4_6_internal_breaker)를 붙였다.

  • 서킷브레이커 파라미터는 실패율 50%, 600초 창, 회복 600초, half-open 5회로 4.5 internal과 같다.

  • 두 호출 위치에서 확률적으로 모델을 고른다.

    _GROK_4_6_INTERNAL_DIAL = 0.1
    ...
    if random.random() < _GROK_4_6_INTERNAL_DIAL:
        async with _eapi_4_6_internal_breaker.guard():
            raw = await self.eapi_4_6_internal.sample(...)
    else:
        async with _eapi_4_5_internal_breaker.guard():
            raw = await self.eapi_4_5_internal.sample(...)
    

  • 첫 위치는 아동 안전 카테고리 cross-model validation을 맡는 기존 함수 _cross_model_validate_with_4_5다. 메트릭명이 safety_ptos.cross_model_validate_with_grok_4_5에서 safety_ptos.child_safety_cross_model_validate_with_grok_4_5로 바뀌었다.

  • 둘째 위치는 classify_policy_for_violation 안의 deluxe 4.3 카테고리 재분류다. fav_count >= 1024일 때 deluxe-4.5-internal 대신 10% 확률로 deluxe-4.6-internal을 쓴다.

    • 이 위치는 심판이 아니라, fav가 높은 포스트의 1차 분류를 일반 sampler 대신 이 모델로 하는 경로다 확인 — classifier.py:461-489.

  • 요청마다 10% 확률로 4.6을, 나머지는 4.5를 부르는 배타적 트래픽 분할이다 확인 — 위 코드. 같은 요청을 두 모델에 함께 보내는 dual-write나 shadow는 아니다.

  • 4세대+2가 도입한 성인 콘텐츠 심판은 이 dial의 대상이 아니다.

• 둘째, 포스트가 이미 NSFW로 플래그됐는지 조회하는 post_is_already_flagged_nsfw가 새 모듈로 나왔다 확인 — grox/flows/ptos/prior_nsfw.py (34줄 신규)
  • 새 모듈 prior_nsfw.py는 StratoSafetyPostAnnotationsResultDirectMh(X 내부 Strato http/Manhattan에서 안전 어노테이션 결과 조회)로 확인한다.
  • 결과를 state.prior_nsfw에 캐시해, 같은 태스크 컨텍스트 안에서 다시 조회하지 않는다.
  • 조회에 실패하면 카운터 safety_ptos.prior_nsfw_lookup_error.count를 올리고 not-flagged로 fallback한다.
  • 4세대+2 cross-validation 태스크가 조회하던 것을 별도 모듈로 리팩터링한 것으로 보인다 추정.
  • cross-validation 태스크의 sync_task_kwargs가 post_is_already_flagged_nsfw import로 바뀌었다.

의미: PTOS 판정 계층은 4.5 → 4.6 모델 전환 트래픽 분할과 prior classification lookup 캐시 분리로 정리되고 있다. 4세대+2 → +3 → +4의 3커밋에 걸쳐 이 판정 스택이 매일 정교화되는 흐름이 확인된다.

2026-08-20 커밋(4세대+5)은 Grok 4.6 internal dial을 0.1에서 0.3으로 올렸다(하루 만에 3배). 확인 — grox/flows/ptos/classifier.py:114

-_GROK_4_6_INTERNAL_DIAL = 0.1
+_GROK_4_6_INTERNAL_DIAL = 0.3

• _EAPI_4_6_INTERNAL_BREAKER_CONFIG 회로차단기 파라미터와 적용 위치(아동 안전 cross-model validation, deluxe 4.3 카테고리 재분류)는 그대로다.
• 의미: 이 승격은 4.6 트래픽이 회로차단에 걸리지 않았고 판정 disagreement rate가 허용 범위였음을 뒷받침한다 추정. 그렇지 않으면 3배 dial 승격이 불가능하다.
• 4세대+2 성인 콘텐츠 심판 도입 → +3 로깅 세분화 → +4 4.6 dial 10% → +5 dial 30%로 PTOS 판정 스택이 매일 바뀌었다. 4.6 dial은 4세대+2 심판이 아니라 아동 안전 심판과 deluxe 재분류에 걸린다.

2026-08-21 커밋(4세대+6)은 Grok 4.5 internal을 완전히 제거하고, 4.6 internal로 100% 전환했다. 확인 — grox/flows/ptos/classifier.py (+6/−63)

4세대+5의 관전 포인트("다음 커밋에서 50%/100%로 뛰면 4.6 완전 전환 근접")가 하루 만에 100%로 해소됐다. 삭제된 항목은 일곱 개다.

• _EAPI_4_5_INTERNAL_BREAKER_CONFIG
• _eapi_4_5_internal_breaker (breaker instance)
• _GROK_4_6_INTERNAL_DIAL 상수(하루 전 0.3)
• self.eapi_4_5_internal (두 클래스에서 초기화 제거)
• _sample_4_5_internal method
• _cross_model_validate_with_4_5의 확률 분기 (이제 항상 4.6 internal 직접 호출)
• classify_policy_for_violation의 deluxe 4.3 재분류 확률 분기 (이제 항상 deluxe-4.6-internal)

의미: 2026-08-19 커밋(4세대+4)에 시작한 4.6 internal dial-up(10%→30%→100%)이 이틀 만에 끝났다. Grok 4.5 internal은 분류기 코드와 grox config의 ModelName 목록에서 모두 빠져 롤백할 수 없다 확인 — grox/config/config.py:82-93. 아동 안전 심판과 deluxe 재분류는 Grok 4.6 internal로 단일화됐고, 성인 콘텐츠 심판은 계속 EAPI_GROK_4_5_X_ALGO를 쓴다. 관전 포인트는 4.5→4.6에서 4.6→4.7 전환 시점으로 옮겨간다.

하루 앞선 2026-08-20 커밋(4세대+5)에서는 grox의 다른 두 곳이 바뀌었다 확인 — aad7179와 d0cef2f 사이의 diff.

• grok_sampler에 stop_predicate callback과 aclosing이 들어갔다 확인 — grox/libs/grok_sampler/llm.py (+27/−13)
  • raw stream을 async with aclosing(...) 컨텍스트로 감싸, 조기 종료 때도 정리를 보장한다.
  • 각 토큰을 yield한 뒤 stop_predicate(resp)를 확인하고, True면 llm.sample.early_stop.count 카운터를 올린 뒤 break한다.
  • 안전 판정 응답이 <json>...</json> 태그로 오는 경우, 태그가 닫히면 뒤 토큰은 무의미하다. 조기 종료로 토큰 비용과 지연을 줄인다.
  • 4.6 트래픽 증가에 맞춘 sampling 인프라 최적화다 추정.
• grox User 스키마에 profile_image 필드가 생겼다 확인 — grox/core/data_loaders/data_types.py
  • 매핑은 grox/core/data_loaders/post_mapper.py에 있다. AuthorMetadata.profileImageUrl이 있으면 Image(url=...)로 채운다.
  • Grok classifier가 프로필 이미지를 판정 컨텍스트로 참조할 수 있게 됐다. 예를 들어 광고 브랜드 안전이나 성인 콘텐츠 심판에서 프로필 이미지도 판단 재료가 된다.
  • upstream 데이터 연결을 준비하는 단계다 추정.

2026-08-24 커밋(4세대+7)은 SafetyPtosPolicyCrossValidator를 새로 만들고, 4세대+2부터 있던 Grok 4.5 X_ALGO 엔드포인트를 이 judge에도 썼다. 확인 — grox/flows/ptos/classifier.py (+223/−52)

4세대+6이 Grok 4.5 internal을 완전히 제거한 지 사흘 만에, 4.5 X_ALGO 엔드포인트가 새 판정 심판(cross-validator)에도 쓰였다. 범위는 3개 카테고리로 넓어졌다.

• 엔드포인트는 ModelName.EAPI_GROK_4_5_X_ALGO이고, 서킷브레이커 _eapi_4_5_x_algo_breaker(window 600초, 회복 600초, half-open 5회)를 쓴다 확인 — 같은 커밋. 둘 다 4세대+2(b089ce6)에서 성인 콘텐츠 심판용으로 이미 생겼다.
  • 4세대+6에서 완전히 삭제된 EAPI_GROK_4_5_INTERNAL과는 별개 모델이다.
  • 이름의 X_ALGO 접미사는 x-algorithm 전용 튜닝 변형을 시사한다 추정.
• 새 클래스 SafetyPtosPolicyCrossValidator의 진입점 validate(category, post, policy)는 세 카테고리를 각 전용 메서드로 보낸다 확인 — 같은 커밋.
  • ChildSafety(_validate_child_safety)는 4.5로 재확인한다. policy type이 일치하면 유지하고, 불일치하면 NoViolation으로 강등만 한다. 파싱 실패와 에러도 NoViolation으로 fallback한다. 4세대+2의 아동 안전 심판을 이 클래스로 흡수한 것이다.
  • ViolentMedia(_validate_violent_media)는 4.5로 재확인한다. 일치하면 유지하고, 심판이 NoViolation으로 판정하면 강등하고, type_mismatch면 ViolentMediaGraphicMedia(약한 형)로 downgrade한다. 강등 옵션이 NoViolation, GraphicMedia, 유지의 3가지로 세분화됐다.
  • IllegalAndRegulatedBehaviors(_validate_illegal_and_regulated_behaviors)는 4.5로 재확인한다. 일치하면 policy type을 유지하되 reason은 4.5가 준 것으로 덮어쓰고, 불일치하면 NoViolation으로 강등한다.
• 세 카테고리 모두 _build_policy_convo로 표준 프롬프트를 만들고 _strip_thinking_restrictions를 적용한다(reasoning 활성) 확인 — 같은 커밋.
  • 프롬프트는 child_safety_policy_prompt(post_creation_time), violent_media_policy_prompt(), illegal_and_regulated_behaviors_policy_prompt()다.
• 강등만 허용하는 원칙을 유지한다 확인 — 같은 커밋. 4세대+2의 성인 콘텐츠 judge와 같은 설계 철학이다.
  • cross-validator가 primary보다 엄격한 판정을 낼 수는 없다.
  • 심판은 primary가 놓친 위해 콘텐츠를 새로 잡아내지 않고, primary가 오탐한 것을 풀어 주는 방향으로만 작동한다.
• 메트릭은 세 카테고리별 safety_ptos.<category>_cross_model_validate_with_grok_4_5 카운터다 확인 — 같은 커밋.
  • 카운터에는 outcome 태그(agreed/disagreed/unparseable/no_violation/type_mismatch/error)가 붙는다.

같은 커밋에서 분류기는 ViolentSpeech와 SuicideOrSelfHarm 두 카테고리에서만 추론(reasoning)을 켜고, 부모 스레드가 있으면 스레드 전체를 함께 넣게 했다 확인.

• SafetyPtosPolicyClassifier.build_convo()는 이 두 카테고리에서만 _strip_thinking_restrictions를 프롬프트에 적용한다(reasoning 활성) 확인 — 같은 커밋.
  • 이때 assistant 메시지를 빈 상태로 두어 모델이 자유롭게 사고하게 한다.
  • 집합은 USE_REASONING_CATEGORIES = {ViolentSpeech, SuicideOrSelfHarm}이다.
  • 다른 카테고리는 여전히 THINKING_CONTROL_END로 사고를 억제한다(빠르고 저렴한 응답).
• 같은 두 카테고리에서만, post에 ancestors가 있으면 ThreadRenderer로 부모 스레드 전체를 사용자 메시지로 렌더한다 확인 — 같은 커밋.
  • 집합은 USE_THREAD_RENDERER_CATEGORIES = {ViolentSpeech, SuicideOrSelfHarm}이다.
  • 이유는 근본적이다. "죽고 싶어" 같은 문장은 스레드 문맥 없이는 판정할 수 없다. 이전 발화가 게임에서 진 얘기면 무해하고, 자해 지원 스레드면 위중하다.
  • 마찬가지로 폭력 발언도 인용과 응답 맥락이 판정을 결정한다.
  • 다른 카테고리(성인·NSFW 미디어·불법)는 대상 post 자체가 신호를 담고 있어서 스레드 확장이 필요 없다.

4세대+7 커밋 기준으로 공개되지 않은 것은 네 가지다.

• EAPI_GROK_4_5_X_ALGO가 4.5 base에 x-algorithm 도메인 파인튜닝을 더한 것인지, 완전 별개 모델인지
• 세 카테고리 확장의 A/B 결과
• 다음 확장 후보(스팸·혐오 발화)
• SafetyPtosAdultContentCrossValidationJudge와 새 SafetyPtosPolicyCrossValidator의 관계(합쳐질지 병렬 유지될지)
  • 두 클래스는 같은 함수 시그니처(judge vs validate)를 갖지만 라우팅 방식이 다르다.

grox 답글 스팸 경로와 LLM 입력의 변화

grox 답글 스팸 파이프라인은 4세대 공개(2026-08-13)부터 답글 랭킹 점수를 Strato에 되쓰는 경로를 갖고 있었고, 2026-08-24 커밋(4세대+7)은 이 경로에 지역 캐시 팬아웃을 추가했다 확인(47c1bcd의 저장 모듈, d011592의 저장 모듈). 2026-08-28 커밋(4세대+10) 기준으로, grox는 새 답글 랭킹 점수가 기존 점수보다 낮지 않으면 Manhattan 쓰기를 건너뛴다 확인(24c6094의 쓰기 태스크). 즉 이 경로로 나가는 답글 랭킹 점수는 시간이 지나도 낮아지기만 하고 오르지 않는다 확인(45b48ba의 쓰기 태스크).

2026-08-24 커밋(4세대+7)에서는 grox의 다른 곳도 세 군데 바뀌었다.

• 답글 스팸 필터와 답글 랭킹 필터의 follower 임계가 80k → 100k로 올랐다(grox/flows/reply_spam/task_filter.py:17).
  • 두 필터는 grox/flows/reply_spam/task_filter.py의 TaskSpamFilter와 TaskReplyRankingFilter다.
  • 11일 동안 다섯 번(15k → 30k → 40k → 60k → 80k → 100k) 올라 스팸 판정 대상이 계속 넓어졌다.
  • 4세대+3 뒤의 상향 폭은 1.25~1.5배다. 임계를 올릴수록 팔로워가 더 많은 계정의 스레드까지 grok으로 검사하므로, 큰 계정 스레드의 스팸 답글을 더 검사하려는 조정으로 본다 추정.
• 답글 랭킹 점수 저장 모듈이 점수를 지역 캐시 두 곳에도 쓰게 됐다 확인 — grox/flows/reply_spam/strato_loader.py (+17/−0).
  • 이 파일과 ReplyRankingScoreStratoLoader 클래스는 4세대 공개 때부터 있었다(32줄) 확인 — 47c1bcd의 같은 파일.
  • 그때부터 점수를 StratoReplyRankingScore.put()로 저장하고, StratoReplyRankingScoreV2Kafka.insert()로 이벤트를 냈다.
  • 4세대+7은 put() 뒤에 단계 하나를 더했다. score ≤ 1.0이면 지역 캐시 두 곳(StratoReplyRankingScoreCacheAtla, StratoReplyRankingScoreCachePdxa)에 병렬로 쓴다.
  • 스코어가 1.0을 넘으면 캐시 fanout을 건너뛴다 확인 — strato_loader.py:20, 34-41. 낮은 신뢰도 판정은 정본(strato)에만 남고, 서빙 캐시는 오염되지 않는다 추정.
• X Spaces(오디오) 컨텍스트가 LLM 판정에 들어왔다. 오디오 스페이스 카드가 붙은 포스트를 Grok 안전 심판이 처음으로 인식한다.
  • grox/core/data_loaders/data_types.py에 SpaceMetadata 클래스가 생겼다(이 커밋 기준 title 하나). Post에는 space_metadata: SpaceMetadata | None 필드가 붙었다.
  • post_mapper.py가 StratoSpaceMetadata에서 매핑한다.
  • grox/core/lm/post.py renderer가 \n\nThis post has the following audio space card attached:\nAudio Space title: {title}로 LLM 프롬프트에 넣는다.
  • 오디오 콘텐츠 자체를 듣지는 않지만, 스페이스 제목 텍스트가 판정 재료가 된다. 예를 들어 스페이스 제목에 명시된 주제가 성인/폭력이면 브랜드 안전 판정에 반영된다.

4세대+9(2026-08-26, 45b48ba)는 reply_spam LM 프롬프트에 팔로워 수와 bio를 넣는 옵션을 만들고, Manhattan 쓰기에 monotone-only 게이트를 걸었다. 확인

• LM 판정에 들어가는 유저 메타가 넓어졌다 확인 — grox/core/lm/post.py (+18/−6), grox/core/lm/thread.py (+25/−4)

  • 이전 PostRenderer.render는 유저 메타를 Metadata: <name> @<handle> 한 줄로 뽑았다. 이제 include_follower_count, include_bio 두 옵션을 받아 다음처럼 나눠 렌더링한다.

    User Handle: @<handle>
    [User Follower Count: <N>]     # include_follower_count=True
    User Name: "<name>"
    [User Bio: "<bio>"]              # include_bio=True
    

  • ThreadRenderer._render_thread가 include_follower_count 인자를 받으면, 스레드 모든 포스트의 팔로워 카운트를 렌더링한다. bio는 post 0(원본, 스레드 root)에만 렌더링한다(include_bio=include_follower_count and post_idx == 0).

  • 답글 대상(evaluate 대상)에도 팔로워 카운트를 포함한다.

  • 메시지 앞에는 # Reply Author Info\n\nThe user profile and any signals below describe the author of the reply being evaluated (the final post of the thread).\n 헤더가 붙는다. 이 헤더는 LLM에게 "이 정보는 evaluate하려는 reply 작성자에 관한 것"이라고 명시한다.

    • 헤더 아래에서 UserRenderer.render(post.user)가 답글 작성자의 이름, 핸들, bio를 따로 렌더링한다 확인 — thread.py:25-27, user.py:18-24. 그래서 bio는 원 포스트(post 0) 작성자와 평가 대상 답글 작성자 두 사람 것이 들어간다.

  • 의미:

    • 팔로워 카운트는 이미 grox reply_spam 게이팅 임계(4세대+7에서 100k)로 쓰이고 있었는데, 이제 LM 판정 자체에도 이 신호가 직접 참조된다.
    • Bio는 스팸/봇 탐지에 강한 근거라서, 원 post와 reply-under-eval 두 저자의 profile을 함께 노출하면 신뢰도가 올라갈 것으로 기대된다.
    • 근거가 되는 bio 내용은 "링크 in 프로필" 같은 스팸 힌트, 정치·상업 조직 소속, 관심사다.
    • 다른 스레드 참여자의 bio는 넣지 않고(context 폭주 방지) 두 저자만 profile을 확장한다.
• Manhattan으로 나가는 답글 랭킹 스코어는 시간에 따라 낮아지기만 하고 오르지 않는다 확인 — grox/flows/reply_spam/task_write.py (+22)
  • _publish_to_reply_ranking_manhattan 안에서 ReplyRankingScoreStratoLoader.fetch_reply_ranking_score(post.id)로 기존 스코어를 조회한다.
  • 새 스코어가 기존보다 크면 쓰기를 건너뛰고 Metrics.counter("task.write_reply_ranking_manhattan.skipped.count", reason="higher_than_existing")를 올린다. 낮으면 그대로 쓴다.
  • 의미:
    • 답글의 첫 판정이 낮게(스팸에 가깝게) 나오면 그 답글은 계속 낮은 스코어를 유지한다. 새 판정이 관대해져도 서빙 스코어는 갱신되지 않는다.
    • 반대로 첫 판정이 높게(관대하게) 나온 답글은 이후 새 판정이 엄격해지면 낮아진다.
    • 이는 답글 스팸 판정의 monotone 안전 방향(한번 스팸으로 잡히면 계속 스팸 취급, 정상→스팸 재분류만 허용)과 정합적이다.
    • 답글 랭킹 스코어의 시간축 진동(label flapping)을 원천 제거해, UI나 A/B에서 같은 답글의 랭킹이 오르락내리락하지 않게 만든다 추정.
    • reply ranking 채널에서 label flap이 실제로 관측됐을 것이다 추정.

4세대+10(2026-08-28, 24c6094)은 Kafka-first 저장 순서와 동점 건너뛰기를 더하고, coordinated spam 판정에 팔로워 수를 상시 주입하게 했다. 확인

_publish_to_reply_ranking_manhattan은 4세대+9의 monotone-only 위에서 세 갈래로 더 조여졌다 확인 — grox/flows/reply_spam/task_write.py (+15/−21)

1. 동점도 쓰지 않는다. 비교 연산자가 >에서 >=로 바뀌어, score >= existing.score이면 건너뛴다.
   • 이전에는 새 스코어가 기존과 같으면 그대로 썼다(idempotent write).
   • 정확히 같은 스코어가 다시 계산됐을 때 Manhattan put을 아끼고, Kafka 이벤트도 나가지 않는다.
   • 카운터 이름도 higher_than_existing → not_lower_than_existing으로 바꿔 시맨틱을 분명히 했다.
2. Kafka 이벤트를 Manhattan 쓰기 앞으로 옮겼다. 이전 순서는 save_reply_ranking_score(Manhattan) → save_reply_ranking_kafka_v2(Kafka)였고, 새 순서는 그 반대인 Kafka publish first, Manhattan write second다.
   • 이유 추정: Kafka는 append-only라 실패 시 재시도할 수 있다. 반면 Manhattan은 monotone-only 로직에 걸려 not_lower_than_existing 판정이 나와 재시도 자체가 생략될 수 있다. 또 Manhattan은 side-effect가 있는 upsert라 Kafka publish보다 무겁다. Kafka를 먼저 성공시키면 오프라인 재처리 파이프라인이 Manhattan write 실패를 나중에 복구할 수 있다. 반대로 Manhattan을 먼저 성공시키면, Kafka publish가 실패했을 때 downstream(서빙 캐시 warm-back, 다른 소비자)이 Manhattan에 이미 반영된 새 스코어를 보지 못한다. 즉 Kafka-first가 시스템 전체의 관측 가능성 정합성을 보장하는 durability 순서다.
3. fetch_reply_ranking_score의 try/except를 걷어냈다. 이전에는 fetch에 실패하면 warning 로그를 남기고 existing = None으로 진행해 항상 썼다. 이제는 예외를 그대로 위로 던져, flow task가 실패로 표시되고 재시도된다.
   • fetch가 조용히 실패해 monotone 비교가 무효화되고 write가 튀는 사고를 원천 차단한다.
   • defensive 예외 처리를 걷어내고 로직 정확성을 우선했다.

같은 커밋에서 4세대+9의 팔로워 카운트 옵션이 coordinated spam 판정에서 상시 활성으로 채택됐다 확인 — grox/flows/reply_spam/classifier_coordinated_spam.py (+5/−1)

• classifier_coordinated_spam.py의 _to_convo에 인자가 추가됐다. 이제 PostRenderer.render(p, max_media=MAX_MEDIA_PER_POST)를 include_follower_count=True로 호출한다.
• coordinated spam 판정은 스레드 각 참여 계정의 팔로워 카운트를 프롬프트로 받는다. bio는 include_bio=False 기본을 유지하고, 팔로워 카운트만 넣는다.

의미: 4세대+9가 도입한 두 축은 4세대+10에서 이렇게 바뀌었다. LM 프롬프트 유저 메타 확장은 상시 활성화됐다. Manhattan monotone-only는 idempotency 강화와 Kafka-first 순서로 정합성이 강화됐다. reply_spam 판정 스택의 durability 계약이 훨씬 명시적이 됐다.

↑ 목차

BDSM (계정 행동 시퀀스 부정 계정 탐지) — 4세대+1에서 enforcement note 생성 로직 부분 공개

BDSM은 계정의 시계열 행동 시퀀스에서 부정·어뷰징 신호를 뽑는 계정 스코어러다. c65aa17 커밋(4세대+1) 기준으로 enforcement note 생성 로직은 일부 공개됐다 확인(커밋 요약표). 노트를 만들 조건과 노트에 실을 봇 헤드를 고르는 로직은 공개됐고, 템플릿 문자열과 튜닝된 판정 임계값은 공개되지 않았다 확인(해소 기록). 노트에는 어떤 봇 계열에 얼마나 걸렸는지가 점수로 실리지만, 어떤 액션 패턴 때문인지를 설명하는 텍스트는 공개되지 않았다 확인(BDSM 절 본문).

3세대부터 4세대 초까지 bdsm/runtime/score_results_sink_focal.py:78의 build_enforcement_note는 return None뿐인 스텁이었다. 4세대+1 커밋에서 gate 로직과 dominant-head 선택 로직이 공개됐고, 템플릿 문자열만 "<redacted>" 센티널로 남았다 확인 — bdsm/runtime/score_results_sink_focal.py:78-128, bdsm/README.md, bdsm/proto/abuse_inference.proto:98-102.

• 노트는 액션이 30개 이상인 시퀀스에서, LegitimateUser가 아닌 헤드 가운데 점수가 0.5를 넘는 것이 있어야 만든다 확인 — 앞 문단의 세 파일.
  • 액션 수 조건은 MIN_ACTIONS = 30, total_actions >= 30이고, 점수 조건은 score > 0.5다.
• 조건을 통과하면 점수가 가장 높은 헤드를 dominant로 뽑고, 노트 문자열에 상위 3개 헤드까지 이름과 점수를 싣는다 확인 — 앞 문단의 세 파일.
  • 노트 문자열은 "<redacted> [model: FollowBot=0.91, also: ReplySpamBot=0.60, LikeBot=0.53]" 형태다.
  • 어떤 봇 계열에 얼마나 걸렸는지는 노트에 그대로 나가지만, 어떤 액션 패턴 때문에 걸렸는지를 설명하는 텍스트는 공개되지 않았다.
• 봇 헤드 7개가 정식으로 공개됐다 확인 — 앞 문단의 세 파일.
  • 이름은 FollowBot, LikeBot, EngagementAmplifier, ReplySpamBot, TweetSpamBot, RTBot, MultiActionBot이다.
• sink_policy.yaml의 operating point(판정 임계값)를 채운 9.99는 센티널이며, README가 이를 명시적으로 규정한다 확인 — bdsm/runtime/sink_policy.yaml:5-13.
  • operating point는 확률 [0, 1] 범위인데, 9.99로 채워져 있으면 절대 트리거되지 않는다.
  • 게이팅 구조와 헤드 이름은 진짜이고, 튜닝된 실수는 게이밍 방지 목적으로 공개하지 않았다는 뜻이다.
• 주의할 점은 노트에 실리는 헤드 점수가 봇 확률이지 "리포트 심사자 결정"이 아니라는 것이다 확인 — 앞 문단의 세 파일.
  • abuse-enforcement-service가 이 노트를 받아 실제 조치(label/challenge/suspension)를 판단한다.
  • abuse-enforcement-service(AES) 쪽의 관련 변경은 변경 이력의 AES generic_actions 패스스루 소절에 있다.

↑ 목차

소스 읽는 법 — 주의 목록

이 목록은 X 공개 소스를 읽을 때 "코드에 있으니 사실이다"라고 판단하지 않도록 주의할 점을 모은 것이다. 2026-08-15 갱신 기준으로 4세대 xai-org/x-algorithm에는 가중치와 상수 값이 채워졌고, Phoenix도 완전히 빌드할 수 있게 됐지만 프로덕션 규모는 아니다 확인(1번 항목). 3세대 canon이 레포 밖이라고 본 점수 후처리 유틸과 외부 서비스 클라이언트 모듈도 4세대 공개에는 들어 있다 확인(1번 항목). 3세대 코드에서는 어떤 모듈에도 연결되지 않은 파일과, 리터럴 치환으로 문법이 깨진 파일도 관찰됐다 확인(2·3번 항목).

1. xai-org/x-algorithm은 3세대까지 빌드되지 않았고, 4세대에서 일부가 해소됐다. ⚠ 이 항목은 2026-08-15에 갱신했다.

   • 3세대에 없던 crate::params는 4세대에서 home-mixer/params/param.rs로 채워졌다 확인.
     • 이 파일은 1084줄이고, 가중치와 상수의 프로덕션 크론 미러다.
     • FavoriteWeight 같은 심볼이 호출부만 있고 정의가 없다는 canon의 3세대 관찰은 해소됐다 확인.
   • 3세대에 없던 crate::util은 4세대 공개에서 home-mixer/util/로 채워졌다 확인 — home-mixer/lib.rs.
     • vqv_weight와 quoted_vqv_weight는 util/candidates_util.rs:19, 42에 있다.
     • 3세대 코드가 부르던 score_normalizer는 4세대에 없고, 정규화 단계 자체가 빠졌다(Phoenix 절).
   • crate::clients도 4세대 공개에서 home-mixer/clients/(파일 19개)로 채워졌다 확인 — home-mixer/clients/.
   • Phoenix는 4세대에서 완전히 빌드할 수 있게 됐다 확인.
     • Cargo workspace, pyproject.toml, QUICKSTART, 합성 데이터(synthetic data)가 함께 들어 있다.
     • 다만 README는 작은 모델을 학습하고 서빙할 수 있다고 명시한다: "a small model can be trained and served". 프로덕션 규모는 아니다 확인.
   • 옆 크레이트(component_library)가 4세대에서도 공개되지 않은 상태인지는 심층 분석이 필요하다.

   위 변화를 반영해 레포의 성격을 다시 정의한다. 3세대까지는 "로직의 형태만 공개, 값·배선 빠짐"이었고, 4세대는 "값 공개 + 안전 규칙 공개 + Phoenix end-to-end 실행 가능, 단 서비스 접착층은 여전히 미공개"로 옮겨 갔다. 빠진 부분은 우연한 누락이 아니라 여전히 일관된 성격을 띤다.

2. 3세대(0bfc279) 코드에서는 README가 꼽는 스코어러 3개가 모듈 트리에서 끊겨 있었다. README는 "Weighted Scorer / Author Diversity Scorer / OON Scorer"라고 썼지만, 실제 파이프라인은 vec![phoenix_scorer, ranking_scorer, vm_ranker]였다 확인 — phoenix_candidate_pipeline.rs:299-300 vs README.md:251-255

   • 세 파일은 scorers/mod.rs가 선언하지 않고, 외부 참조도 0건이다 확인.
     • 세 파일은 weighted_scorer.rs, author_diversity_scorer.rs, oon_scorer.rs이고, 구조체 이름은 WeightedScorer/AuthorDiversityScorer/OONScorer다.
   • 그런데 그 파일들에는 하드코딩 상수가 있어서, README를 따라간 독자는 도달할 수 없는 상수를 프로덕션 값으로 착각하게 된다 확인.
     • 하드코딩 상수의 예는 p::AUTHOR_DIVERSITY_DECAY다.
   • 연결되지 않은 파일은 이 셋만이 아니다. home-mixer/ 안에는 어떤 mod 선언에도 걸리지 않은 .rs 파일이 11개 있다 확인.
     • 11개 파일은 다음과 같다.
       • candidate_hydrators/engagement_counts_hydrator.rs
       • candidate_pipeline/{candidate,candidate_features,query,query_features}.rs
       • query_hydrators/{user_action_seq,user_features}_query_hydrator.rs
       • scorers/{author_diversity,oon,weighted}_scorer.rs
       • side_effects/cache_request_info_side_effect.rs
   • 판별법(3세대 기준): 죽은 파일은 crate::candidate_pipeline::{candidate, query}를 import하고, 살아 있는 ranking_scorer.rs는 crate::models::{candidate, query}를 import한다. 같은 이름의 타입이 두 디렉토리에 있으며, models/가 현행이고 candidate_pipeline/이 구세대다 추정. 연결 방향으로만 추론했고, 커밋 이력에는 단서가 없다.
   • pub(crate) mod도 선언이다. ads/util.rs는 ads/mod.rs:3에 pub(crate) mod util;로 걸려 있어 살아 있다 확인.
     • ^\s*(?:pub )?mod 같은 정규식으로 세면 이 파일을 죽은 파일로 잘못 판단한다 확인.
   • 4세대 공개(47c1bcd)에서는 이 11개 가운데 10개가 레포에서 사라졌고, engagement_counts_hydrator.rs는 candidate_hydrators/mod.rs:6에 선언돼 연결됐다 확인. 같은 공개의 README도 이 세 스코어러를 더 이상 나열하지 않는다 확인 — README.md.

3. 3세대(0bfc279) 코드에서는 문자열과 숫자 리터럴이 ""로 기계적으로 치환된 곳이 있었다. 문법 검사를 하지 않아서 컴파일이나 파싱이 깨진 파일이 있었다 확인.

   • 예를 들어 grox/classifiers/content/safety_ptos.py:241-244는 and가 피연산자 없이 남아 SyntaxError가 나고, 그래서 PTOS plan 자체를 import할 수 없다 확인.
   • grox/tasks/task_summarizer_for_post_embedding.py:14는 import 시점에 FileNotFoundError를 던져서, Grox가 아예 기동하지 못한다 확인.
   • 두 파일 모두 4세대 공개(47c1bcd)에는 없다 확인.

4. git log --diff-filter=D <commit>은 그 커밋의 삭제가 아니라 조상 전체의 삭제를 보여 준다. 이 명령의 결과로 "2025 리프레시가 DiversityScorer.scala를 지웠다"고 결론 내리면 틀린다. 그 파일은 2023-07-07에 지워졌다 확인.

5. the-algorithm-ml 클론이 shallow clone이면 모든 파일이 "new file"로 보인다. 그런 클론으로는 가중치 히스토리를 읽으면 안 된다 확인.

6. has_cached_posts가 가장 영향이 큰 스위치인데, 모델이 아니라 캐시 임계값이다. Redis 워밍 캐시에 500개 이상 쌓여 있으면 이 불리언이 켜지고, 그러면 retrieval 소스와 상당수 하이드레이터가 꺼진다 확인 — cached_posts_query_hydrator.rs:11, 69

   • 2026-10-17 커밋(862a123) 기준으로 home-mixer 안에서 !query.has_cached_posts 게이트가 있는 파일은 25개다. retrieval 소스 8개와 후보 하이드레이터 12개가 여기에 든다 확인 — 862a123 home-mixer/ grep. 3세대 코드(0bfc279)에서는 18개 파일이었다.
   • 같은 기준에서 Phoenix 스코어러에도 has_cached_posts 분기가 있다 확인 — phoenix_scorer.rs:70. EngagementCountsHydrator는 2026-09-04 커밋(4세대+16)에서 이 게이트를 뺐다(콜드스타트 슬롯 선택기).
   • 스크롤 중의 "더 보기"는 상당 부분 모델 추론 없이 이전 요청의 잔여 후보로 응답된다 확인.
   • 그 비중이 얼마인지는 추정조차 할 수 없다. 레포에 단서가 없다.

7. 3세대(0bfc279) 코드 기준으로 CoreDataHydrationFilter는 이름과 달리 코어 데이터 조회에 실패한 후보를 실제로는 거르지 못한다. 하이드레이터가 author_id를 쓰지 않기 때문이다 확인(코드) — core_data_candidate_hydrator.rs:108-113, filters/core_data_hydration_filter.rs:13

   • README는 이 필터를 "코어 메타데이터 hydration 실패한 포스트 제거"라고 설명한다.
   • 버그로 본다 추정. 코드 흐름상 다른 설명이 어렵다.

8. 3세대(0bfc279) 코드 기준으로 실패가 전부 조용하다. 프레임워크 레벨의 타임아웃도, 서킷브레이커도, 폴백도 없다 확인 — candidate-pipeline/candidate_pipeline.rs:202-218, 266, 419-428

   • 에러가 난 소스와 쿼리 하이드레이터는 사라진다 확인.
   • 후보 하이드레이터에서 에러가 나면 해당 필드가 설정되지 않은 채로 남는다 확인.
   • 사이드이펙트는 detached로 실행된다 확인.

9. 3세대(0bfc279) 코드 기준으로 로깅이 샘플링돼 있다. 가장 풍부한 두 로그 스트림이 대표성 없는 슬라이스다 확인 — side_effects/reranking_kafka_side_effect.rs:14,29

   • 리랭킹 Kafka 로그는 프로덕션에서 5%를 샘플링하고, 상위 50개만 남긴다 확인.
   • 나머지 하나는 shadow traffic에서만 남는다 확인.

10. 2025 Scala 코드에는 주석이 코드와 어긋난 곳이 있다. 저신호 유저 게이트의 주석 두 곳은 "< 25 users"라고 쓰지만, 실제 상수는 SmallFollowGraphSize = 5다. 주석을 근거로 임계값을 인용하면 5배 틀린다 확인 — SignalUtils.scala:17-23 vs AllowLowSignalUserGate.scala:12, DenyLowSignalUserGate.scala:12

11. "랭커 점수"라는 단일 값은 없다. 2025 MMR과 2026 VMRanker는 둘 다 score 필드를 덮어쓴다. 로그나 코드에서 점수를 볼 때는 어느 단계의 값인지 확인해야 한다. 2026 코드가 weighted_score와 score를 별도 필드로 남기는 이유가 이것이다 확인 — DiversityRescoringFeatureHydrator.scala:70, vm_ranker.rs:47-52, ranking_scorer.rs:277-281(둘 다 3세대 코드). 2026-10-17 커밋(862a123)에서도 VMRanker가 두 필드를 따로 채운다(vm_ranker.rs:93-131).

↑ 목차

이 서비스에서 나온 일반화 노트

X에서 관찰한 기법 가운데 여러 서비스에 걸치는 것은 topics 폴더의 주제 노트에 따로 정리했다. 각 노트는 X의 사례를 Meta 같은 다른 서비스의 사례와 나란히 놓고 비교한다.

↑ 목차

열린 질문

4세대 공개(2026-08-13) 뒤에도 X 공개 코드로 답하지 못한 질문 가운데 가장 최근 것은 2026-10-16·10-17 커밋(4세대+43·+44)이 남긴 질문이다(변경 이력의 4세대+43, 4세대+44). 그 앞은 2026-10-14 커밋(4세대+41)이 남긴 심층 분석 과제다(변경 이력의 4세대+41). 랭킹 요청에 추가된 피드 요청 맥락 값은 2026-10-13 커밋(4세대+40)부터 광고 인덱스 요청에만 채워진다 확인(변경 이력의 4세대+40). 같은 커밋 기준으로 Phoenix 랭킹 요청 쪽은 아직 답이 없다.

미해소·심층 분석 필요 (4세대 공개 이후)

4세대 공개 뒤에도 공개 코드로 답하지 못했거나 심층 분석이 필요한 질문이다. 취소선을 그은 항목은 2026-09-17 커밋(4세대+23)에서 풀렸다.

• has_cached_posts 경로가 실제 노출의 몇 %인가. 외부에서 추정할 방법이 있는가. 레포에 단서가 여전히 없어 추정조차 못 한다.
• SimClusters 코어 알고리즘의 세부를 아직 확인하지 못했다. SVD 파이프라인, k, 인덱스 형식, 업데이트 주기가 질문이다. simclusters/ 서브레포를 심층 분석해야 한다.
  • SimclusterColdPostsCandidateSource에 대응하는 4세대 구성 요소가 있는지도 묻는다.
• agatha/bdsm/user-cred-v2 계정 스코어러의 세부는 무엇인가. 각 스코어러의 실제 모델, 업데이트 주기, 라벨 임계가 질문이다.
• pnsfwmedia는 어떻게 캘리브레이션되는가. CLIP 임베딩과 agatha 스코어를 결합하는 방식이 질문이다.
• phoenix/ 학습 파이프라인의 세부는 무엇인가. loss, negative sampling, synthetic data 형식이 질문이다. optimizer는 2026-08-19 커밋(4세대+4)에서 공개됐다(학습 코드).
• phoenix-rankall/·phoenix-rankall-strato/ 인덱싱 파이프라인은 어떻게 동작하는가. visibility 사전 참조 로직과 이벤트 층의 세부가 질문이다.
• abuse-enforcement-service/에서 어떤 스코어가 어떤 조치(라벨/챌린지/서스펜션)로 매핑되는가.
• scarecrow/botmaker/botmaker-rules의 DSL과 규칙 카테고리는 무엇인가. 공개 규칙과 미공개 규칙의 비율도 질문이다.
• under-the-hood/의 라벨 taxonomy는 무엇인가. 유저에게 노출되는 라벨이 규칙 코드와 어떻게 연결되는지가 질문이다.
• InventoryHoldoutFilter의 홀드아웃 비율 param: 2026-09-17 커밋 42266f3(4세대+23)에서 3개 param을 확인해 해소했다(필터 21개 절).
  • 세 param은 InventoryHoldoutOriginalsPercent·InventoryHoldoutRepliesPercent·InventoryHoldoutRetweetsPercent다.
• RECSYS_EMBED_V4 멀티모달 임베딩은 어디서 쓰는가. 홈 랭킹은 아니다.
• 2025 Scala 세대 heavy ranker(Navi)의 아키텍처는 무엇인가. MaskNet/DCN 계열의 세부가 질문이다. 모델 정의가 the-algorithm-ml 쪽에 있어 따로 확인해야 한다.
• Phoenix retrieval의 two-tower 구조와 ANN 인덱스는 어떻게 생겼는가. phoenix/recsys_retrieval_model.py는 봤다. 서빙 쪽 인덱스는 4세대에서 부분 공개됐다(phoenix-rankall/). 전체를 다시 검증해야 한다.
• 2026 세대의 models/와 candidate_pipeline/ 이중 레이아웃이 4세대에서 정리됐는가. 아직 확인해야 한다.
• 2세대의 가중치 노이즈 주입이 4세대에서도 유지됐는가. 2세대의 노이즈는 HeavyRankerWeightsQueryFeatureHydrator.scala의 Beta 분포다. 유지 여부는 심층 분석이 필요하다.
• 2026-10-08 커밋(4세대+38)은 네 가지 심층 분석 과제를 남겼다(변경 이력: 35650fb).
  1. 영상 캐러셀의 최종 응답 크기, 그리고 본 피드와 겹치는지
  2. VF hydration/sources/exchange.rs(528줄)와 clients/user_location_client.rs(345줄)가 위치 기반 판정을 새로 추가하는지
  3. phoenix-rankall/src/hydrate/*(약 1,300줄)로 새로 생긴 hydration 스케줄러
  4. MoL two-tower가 실제 실험 config에서 켜졌는지
• 2026-10-09 커밋(4세대+39)이 랭킹 요청에 넣은 FeedRequestContext·FeedCursorDirection은 어디서 채워지고 어디서 읽히는가.
  • Phoenix 랭커가 이 값을 피처로 읽는 코드가 언제 공개되는지, home-mixer가 어느 요청 정보로 이 값을 채우는지 확인이 필요하다.
  • 4세대+40(e1a0375)에서 home-mixer가 RequestContext::parse(query.request_context)로 값을 만들어 광고 인덱스 요청에만 채우기 시작했다 확인.
  • Phoenix 랭킹 요청 쪽은 여전히 미해소다.
• 2026-10-13 커밋(4세대+40)은 네 가지 심층 분석 과제를 남겼다(변경 이력: e1a0375).
  1. two-tower ld 헤드의 CLIENT_TWEET_RECAP_DWELLED 판정 임계와 combined 프리셋이 프로덕션 retrieval인지
  2. 답글 랭커 reply_two_tower_v2를 부르는 서비스, 그리고 grox 답글 점수와의 연결
  3. abuse-enforcement action_control·off_switch(약 6,000줄)와 VF explain.rs·rules/levels.rs 리팩터가 정책 변화를 포함하는지
  4. home-mixer와 vm-ranker 미러에서 갈라진 가중치 4개(PostUnexploredWeight, favorite, video_open, cont_dwell_time) 가운데 어느 쪽이 서빙값인지
• 2026-10-14 커밋(4세대+41)은 네 가지 심층 분석 과제를 남겼다(변경 이력: 17c96bf).
  1. serve_page_decoder(기본 False)를 켠 서빙 인스턴스가 있는지, 그리고 디코딩 결과를 home-mixer의 어느 단계가 소비하는지
  2. 학습 로그에 이미 rl_rerank_prob·rl_decode_prob가 있는데, 이 값을 만든 behavior 정책이 무엇인지
  3. immersive_page_rl이 immersive 영상 지면 전용인지, 홈 For You에도 쓰이는지
  4. TopicDppEnabled를 켜는 실험이 있는지
• 2026-10-16·10-17 커밋(4세대+43·+44)은 네 가지 질문을 남겼다(변경 이력: bc3948b, 862a123).
  1. Phoenix 모델이 TweetInfo.postEngagers를 어떤 인코더로 읽는지
  2. RankingScoreWeights를 채우는 home-mixer 호출 측
  3. IsBrandEngagement 라벨을 쓰는 헤드가 광고 랭커인지
  4. ZeroFav 양면 실험의 작성자 버킷 규모
• 2026-10-20 커밋(4세대+45)은 두 가지 질문을 남겼다(daily 2026-10-21).
  1. VMRanker가 요청에 실린 뷰어 이력 토픽을 어떤 재순위 목표에 쓰는지
  2. 섀도 클러스터 Experiment16Fou가 쓰는 이력 집계 DENSE_WITH_LONG_DWELL_HOME_EXCURSION이 기존 집계와 무엇이 다른지
• X는 EU DSA 투명성 보고서에서 무엇을 바꾸는가. X가 이번 8-13 공개 뒤 무엇을 새로 제출하거나 삭제하는지가 질문이다. 규제 문서와 코드가 서로 맞는지(sync 여부)가 새로운 검증 각도다.

4세대 공개로 해소된 것 (2026-08-15)

4세대 공개로 가중치 실값, VMRanker와 DPP의 활성 여부, Phoenix 헤드 개수에 관한 질문이 풀렸다. 학습 파이프라인과 콜드스타트 질문은 풀렸지만 남은 부분이 있다.

• ✅ 가중치 실값: home-mixer/params/param.rs가 프로덕션 크론 미러로 공개됐다.
• ✅ VMRanker/DPP가 켜져 있는가: 켜져 있다(EnableVMRanker=true, DPP θ=0.65, K=150).
• ✅ Phoenix 헤드 개수: 문서 기준 24개로 확정됐다.
  • 구성은 Engagement 7 + Clicks 6 + Attention 5 + Author 1 + Negative 5다.
• ✅ 2026 Rust 학습 파이프라인: phoenix/에 학습 코드, synthetic 데이터, QUICKSTART가 있다. 단 loss, negative sampling, optimizer는 심층 분석이 필요하다.
• ✅ 신규 아이템 콜드스타트 부재: 4세대에서 새-작성자 부스트가 공개됐다(PostUnexploredWeight=0.02, ColdStartImpressionThreshold=1000). 단 개별 새 포스트를 위한 별도 장치는 여전히 없다.

4세대+1 공개로 해소된 것 (2026-08-16)

이 공개로 가중치 비율을 읽는 규칙, 콜드스타트 슬롯 선택기, 관할권 필터에 관한 질문이 풀렸다. Phoenix bool feature와 BDSM enforcement note는 일부만 풀렸다.

• ✅ 가중치 비율의 해석 규칙: param.rs·ranking_scorer.rs 주석과 README가 "ratio를 raw count 등가로 읽지 말라"고 명시했다.
  • canon은 3세대까지 "reply 13.5 = favorite 27개 값"으로 해석한 문서를 인용해 왔다. 이 해석이 원리적으로 틀린 프레이밍이었음이 확정됐다.
• ✅ Phoenix bool feature 채움 상태: bool_features 전체가 zero stamp된다는 관찰이 4세대+1에서 부분 해소됐다.
  • 3개가 채워졌다(IS_STALE_POST14D·IS_AUTHOR_FOLLOWED/FOLLOWING).
  • 나머지 bool 슬롯을 쓰는지는 여전히 공개되지 않았다.
• ✅ 콜드스타트 슬롯 선택기 로직: greedy와 Beta Thompson sampling의 두 갈래가 param으로 연결됐다. 단 Thompson은 기본 off이고, 실제 프로덕션은 여전히 greedy다.
• ✅ 관할권 필터 존재 여부: Brazil2026ElectionFilter로 코드 수준에서 확인됐다. 앞으로 다른 나라의 선거·규제 대응이 같은 관행으로 붙을지가 새로 지켜볼 점이다.
• ✅ BDSM enforcement note 생성 로직: gate와 dominant head 로직이 공개됐다. 템플릿 문자열과 operating point 실수는 여전히 공개되지 않았다.

4세대+2 공개로 해소된 것 (2026-08-19)

이 공개로 Grok 안전 라벨의 마이그레이션 방식, 성인 컨텐츠 판정이 엇갈릴 때의 처리, Phoenix retrieval의 인덱싱 게이트가 드러났다. 첫 항목의 판단은 다음 날 뒤집혔다.

• ✅ Grok 안전 라벨의 스키마 마이그레이션 관행: 라벨 스키마가 버전으로 관리되고, 그 마이그레이션이 코드 안의 dual-write 감지 로직으로 들어가 있음이 확정됐다. 주의: 이 판단은 4세대+3(다음 날)에서 재설계로 뒤집혔다(4세대+3 기록).
  • compute_verdict_v2가 _V2 라벨 6종을 참조한다.
  • strip_v1_grok_written이 PROMPT_OWNED_RULES = [1400, 1410, 1420, 1500, 1510, 1610, 1700]에 속한 V1 dual-write 라벨을 걸러 낸다.
  • v2_mirrors_v1_across_tier_matrix 테스트가 6가지 라벨 조합과 2 tweet_id 시점에서 V1/V2 동치를 assert한다.
• ✅ 성인 컨텐츠 판정이 엇갈릴 때의 처리: safemodel과 PtOS가 엇갈리면 Grok 4.5 심판이 다시 판정하고, hard→soft 강등만 허용한다.
  • safemodel은 자체 비전 모델이고, PtOS는 정책 판정이다. 격상은 없다.
  • 판정 계층이 3층(safemodel, PtOS, Grok 4.5 심판)으로 확장됐다.
  • EAPI_GROK_4_5_X_ALGO 전용 서킷브레이커를 두고, 감사 로그에 "Grok 4.5 Cross Validation disagreed" 텍스트를 명시한다.
• ✅ Phoenix retrieval의 인덱싱 게이트: build1FavIndex·buildMMEmbMetadataDump의 favoriteCount >= 1 조건이 제거됐다. 실제 인덱스는 유입 후보 전체다.
  • 인덱스 이름 "1fav"는 backward compat 라벨이 됐다.
  • 1fav_uec_count_race 카운터로 fav 없이 도달한 케이스만 계측한다.
• 심층 분석 필요 (신규):
  • Grok 4.5 심판이 다른 카테고리로 확장되는지
  • 1fav_uec_count_race의 실제 관측 비율(외부에서는 관측할 수 없다)

4세대+3 공개로 해소된 것 / 뒤집힌 것 (2026-08-20)

이 공개는 하루 전 4세대+2에서 확정됐다고 본 브랜드 안전 V2의 dual-write 판단을 뒤집었다. VMRanker의 SID 연결, For You와 Following의 하이드레이션 분기, Phoenix 이벤트 스트림의 v3 이동, grox reply_spam 흐름 통합도 확인됐다.

• ⚠ 주장 변경 (하루 만에): V2 브랜드 안전 dual-write 로직이 완전 재설계됐다.
  • 4세대+2의 방식은 strip_v1_grok_written과 PROMPT_OWNED_RULES 7개 rule id였다. 4세대+3의 방식은 V2_WRITTEN_LABELS 4개 게이트와 V1 폴백 시맨틱이다.
  • PROMPT_OWNED_RULES 7개는 코드에서 완전히 사라졌다. 그 rule id 매핑을 묻던 심층 분석 항목은 자동 해소됐다(질문 자체가 없어졌다).
  • 새 시맨틱은 훨씬 깔끔하다: "V2 라벨이 하나라도 있으면 V2가 결정하고 V1 heuristic까지 완전 무시, 없으면 V1 폴백".
  • 이 사례는 X가 "매일 커밋"의 dual-write 마이그레이션 실체를 그대로 노출한다는 관찰의 강한 근거다.
• ✅ VMRanker의 SID 연결: SID 필드 7개가 VMRanker 요청에 들어갔다. Phoenix retrieval의 SID window와 짝을 이루는 재순위 쪽 SID 소비자가 있음을 확인했다.
  • 필드는 sid_known·sid_k_l1/2/3·sid_gap_l1/2/3이다.
  • SID가 3-level 계층 코드북이라는 아키텍처 사실이 새로 드러났다.
• ✅ For You와 Following의 하이드레이션 분기: For You와 Following이 파이프라인 단계에서 명시적으로 갈리기 시작했다.
  • VFFollowingCandidateHydrator가 새로 연결됐다.
  • Following은 이제 VF 결과만 남기고, 다른 후보 필드는 default로 둔다.
• ✅ Phoenix 이벤트 스트림이 v3로 옮겨 가고 Kafka 클러스터가 분리됐다.
  • content_understanding_realtime_unified_posts → ..._v3
  • main-2 → phoenix-kafka-external-bootstrap
  • ValueOnly → KeyValue(key=Long)
  • grox reply_spam도 같은 커밋에서 v3로 옮겨 갔고, 흐름도 통합됐다.
• ✅ grox reply_spam 흐름이 통합되고 임계가 다시 조정됐다.
  • PostStreamTaskGenerator가 삭제되고, ReplyRankingTaskGenerator가 PlanSpamComment·PlanCoordinatedSpam을 흡수했다.
  • Follower 임계가 40k → 60k로 올랐다. 2026-08-17 커밋(4세대+2)의 30k → 40k에 이은 세 번째 상향이다.
• 심층 분석 필요 (신규):
  • V2_WRITTEN_LABELS 4개 라벨의 유래(Grok 프롬프트 변경? 재훈련?)
  • SID 코드북 정의(각 level의 vocabulary 크기·훈련 방식)
  • sid_gap의 계산식
  • Phoenix Kafka unified_posts_v2가 있었는지(v1 → v3 직접 점프인지)
  • ColdStartTrackedIds param과 단순화된 count_tracked_ids 계측이 실제로 어떻게 연결되는지

4세대+4 공개로 해소된 것 / 신규 (2026-08-21)

이 공개로 Phoenix의 optimizer가 코드로 확정됐고, Phoenix가 검색 지면으로 넓어지는 첫 신호가 나왔다. reward head와 분포 예측 헤드, Following 쪽 필터, PTOS의 Grok 4.6 shadow, VF shadow 배포 기반도 새로 드러났다.

• ✅ Phoenix dense-param optimizer의 정체가 4세대+4에서 코드로 확정됐다. 오랜 미공개 항목이었던 이 optimizer는 Muon (Newton-Schulz orthogonalization)과 Adam의 하이브리드다.
  • muon_adam_patterns="embed,_emb,logits,vocab,norm,table"
  • base LR 1e-3 → 7.1e-4, muon_split_fused="qkv:128", muon_consistent_rms=0.2
  • embedding은 rowwise_adagrad를 쓴다(LR 0.28, half-life 2500 step, lazy_decay, weight_decay 2.8e-4).
  • GB300 override는 LR 5e-4·half-life 5000이다.
  • 이 저장소가 반영해 온 대규모 프로덕션 recsys 학습 파이프라인 가운데 Muon 채택을 코드로 확인한 첫 사례다. LLM optimizer가 랭커/retrieval 학습으로 넘어온 것을 보는 관찰 축이 새로 생겼다.
• ✅ Phoenix가 검색 지면으로 확장하는 첫 코드 신호가 나왔다. 검색용 config가 새로 생겼고, proto의 CLIENT_TWEET_(NOT_)RELEVANT_TO_SEARCH 두 액션이 짝을 이룬다.
  • config는 xrecsys_search다(vocab 100M/100M/30M, EP 512, use_product_surface=True, condition_search_relevance_on_prompt=True).
  • 이전 canon은 지면마다 코드베이스가 따로라고 이해했다. 이제는 같은 Phoenix 트랜스포머가 config만 갈아 끼우면 검색과 피드를 모두 서빙하는 방향으로 통합되고 있다.
• ✅ Phoenix proto에 reward head의 뼈대가 생겼다. RL(actor-critic value+policy) 학습이나 reward-model-guided 재순위 슬레이트 결정으로 가는 연결이 시작됐다. 어느 스코어러가 소비하는지는 심층 분석이 필요하다.
  • 새로 생긴 것은 RewardOutputs(values와 policyLogits)와 ScoreInfo.rewardRerankSlotProb다.
  • 2026-10-14 커밋 17c96bf(4세대+41)에서 immersive 지면용 페이지 디코더(actor)와 twin critic 학습 코드가 공개됐고, 이 학습은 rewardRerankSlotProbSeq 컬럼을 로깅 확률 rl_rerank_prob로 읽는다 확인(변경 이력의 4세대+41).
    • 같은 커밋에서 proto 밖의 코드는 RewardOutputs(rewardOutputs·policyLogits)를 참조하지 않는다 확인 — 17c96bf 전체 grep.
• ✅ X 랭커의 예측 스키마가 처음으로 분포 형태를 담기 시작했다. 링크 열림 확률을 단일 스칼라가 아니라 P10/P25/P50/P75/P90의 5분위 헤드로 예측한다.
• ✅ Following 파이프라인의 병렬 구조가 넓어졌다. 4세대+3의 하이드레이터 분기에 이어, 4세대+4에서 필터와 hydrator가 하나씩 새로 붙었다.
  • 4세대+3의 분기는 VFFollowingCandidateHydrator다.
  • FollowingViewerMutedKeywordFilter(65줄)는 quoted text와 ancestor까지 매치한다.
  • QuotedPostTextHydrator(106줄)는 TES에서 quoted text를 가져온다.
  • For You와 Following이 필터·hydrator 스택에서 서로 다른 컴포넌트를 쓰므로 병렬 구조가 재확인된다.
• ✅ PTOS 판정 계층에서 Grok 4.6 shadow가 시작됐다. 아동 안전 cross-validation과 deluxe 4.3 카테고리에서 트래픽 10%만 4.6으로 보낸다. 4.5 → 4.6 gradual rollout의 dual-write 단계가 시작됐다.
  • 비율은 _GROK_4_6_INTERNAL_DIAL = 0.1로 정한다.
  • 새 모델(EAPI_GROK_4_6_INTERNAL)과 전용 서킷브레이커가 연결됐다.
  • prior_nsfw.py(34줄 신규)로 Manhattan lookup 캐시를 분리했다.
• ✅ VF shadow 배포 인프라가 연결됐다. fail-closed인 VF의 규칙 변경을 shadow로 검증하는 기반이 확립됐다(변경 이력의 4세대+4).
  • visibility-filtering/dark_traffic_setup.rs(109줄 신규)가 env-gated로, 특정 ordinal pod만 요청을 xai-vf-shadow.prod.visibility로 미러링한다.
  • mTLS를 쓰고, /config/dark-traffic/dark_traffic.yaml 규칙 파일을 reload한다.
• ✅ 4세대+1에서 채워진 Phoenix bool feature 3종이 학습 기본값 ON으로 올라갔다.
  • enable_stale_post·enable_is_author_followed_by_viewer·enable_is_author_following_viewer·enable_engagement_counts 4개가 _home_direct_packed_base()의 기본값이다.
  • grpc_recsys dataset type만 enable_stale_post=False로 override한다(실시간 서빙에서는 count zeroing 위험을 회피 추정).
• 심층 분석 필요 (신규):
  • RewardOutputs가 어느 학습 루프에서 채워지고 어느 스코어러가 소비하는지(recsys_model.py의 +265/−25 대폭 개편을 추적해야 한다)
  • link-open 5분위가 quantile regression인지 categorical mixture인지
  • xrecsys_search config가 프로덕션에 배포됐는지
  • Muon의 실제 성능 관찰치(공개 지표 없음)
  • dark_traffic YAML 실물(미공개)
  • condition_search_relevance_on_prompt의 프롬프트 형태

4세대+5 공개로 해소된 것 / 신규 (2026-08-22)

이 공개로 Phoenix 서빙이 만든 slate context를 home-mixer가 받아 쓰는 경로가 연결됐다(게이트는 기본 false). For You 후보에는 AI trend 맥락이 붙기 시작했다. Grok 4.6 shadow 비율은 하루 만에 세 배가 됐다.

• ✅ Phoenix 서빙이 만든 slate context를 소비하는 경로가 생겼다. 4세대+4에서 proto에 신설된 SlateContext.sid*가 실제 파이프라인까지 연결됐다. 게이트는 기본 false로 연결됐다.
  • 구성 요소는 PostCandidate.served_slate_context, From<xai_recsys_proto::SlateContext> 변환 impl, PhoenixScorer의 candidate_slate_context() 추출, RankingScorer의 3갈래 폴백이다.
  • 폴백 순서는 UseServedSlateContext 게이트 우선 → 캐시 → 로컬 계산이다.
  • slate context 계산 지점이 home-mixer 로컬에서 Phoenix 서빙으로 옮겨 가는 첫 단계가 확정됐다.
• ✅ AI trend feedback context 채널이 새로 생겼다. For You 후보에 "AI trend" 라벨을 topic feedback과 나란한 두 번째 컨텍스트 채널로 붙인다. topic feedback이 없을 때만 폴백으로 진입해 겹치지 않는다.
  • TOP_TREND_COUNT = 2다(페이지당 최대 2개).
  • trend당 후보 1개를 랜덤으로 고른다.
  • standalone original post, non-topic, non-in-network의 3중 게이트를 둔다.
  • 랜딩 URL은 https://x.com/i/trending/{trend_id}다.
• ✅ emb_table 로더의 core가 pyo3-free로 분리됐다. 큰 임베딩 테이블을 non-Python 컨텍스트에서 로드할 수 있게 준비했다. xrecsys_search의 vocab 100M/100M/30M 흐름과 방향이 같다.
  • core는 load_tensor_into(&str, &str, &[(String, String, usize, usize)], &mut [u8], usize, usize) -> Result<(), String>이고, Python wrapper가 따로 있다.
• ✅ Grok 4.6 트래픽 분할 dial이 하루 만에 10% → 30%로 3배 올랐다. 4.6 트래픽이 회로차단 트립 없이 disagreement rate 허용 범위 안에 있었음을 뒷받침한다 추정. 4세대+2→+3→+4→+5로 매일 정교해지는 흐름이 이어진다.
• ✅ grok_sampler에 스트리밍 응답을 일찍 끝내는 콜백이 들어갔다. 4.6 트래픽 증가에 맞춘 sampling 인프라 최적화다 추정.
  • stop_predicate와 aclosing이 연결됐고, llm.sample.early_stop.count 카운터가 생겼다.
• ✅ grox User에 profile_image 필드가 새로 생겼다. Grok classifier가 프로필 이미지를 판정 컨텍스트로 참조할 수 있게 스키마를 확장했다.
• 심층 분석 필요 (신규):
  • AI trend의 upstream 정의(Grok 클러스터링? 사람 큐레이션?)와 batch_get_tweet_ai_trend 파이프라인 소스
  • UseServedSlateContext 게이트가 true로 올라가는 시점. 이 시점이 곧 Phoenix 서빙 slate context가 프로덕션 트래픽에 반영되는 시점이다(다음 커밋에서 볼 관측 포인트).
  • Grok 4.6 dial의 다음 이동(30% → 50%/100% 또는 하락)
  • stop_predicate의 실제 사용 위치(안전 판정 JSON tag 매칭 콜백으로 쓰는지)

4세대+6 공개로 해소된 것 / 신규 (2026-08-23)

이 공개로 광고 conversion 예측 헤드 20개와 delayed feedback 학습 분기가 생겼고, export nano config가 GB300 오버라이드의 학습 레시피를 물려받게 됐다. PTOS의 아동 안전 cross-validation과 deluxe 재분류는 Grok 4.6 internal로 완전히 넘어갔다.

• ✅ 광고 conversion 예측 헤드 20개가 새로 생겼다. 이전에는 앱 설치만 예측했지만, 이제 앱 설치 이후의 참여 이벤트 6개를 click·view 각각으로 예측한다(광고 conversion 소절).
  • proto ActionName 171–190에 들어갔다. MACT 6종 인앱 이벤트(purchase·add_to_cart·level_achieved·tutorial_complete·sign_up·custom) × click/view 2계열 = 12개 + view-through conversion 8개(웹 컨버전)다.
  • 이전에는 ADS_ATTRIBUTED_MACT_CLICK_INSTALL(=140) 하나뿐이었다.
  • NEGATIVE_FEEDBACK_HEAD_INDICES에 CLIENT_TWEET_SEARCH_QUERY_REFORMULATED가 추가됐다.
• ✅ 학습 손실이 delayed feedback 여부로 갈리게 됐다. X 랭커 학습이 광고 delayed conversion prediction 문헌(Chapelle 2014)의 표준 처리 방식과 명시적으로 정렬됐다.
  • split_head_training_by_source config가 kafka의 is_delayed_feedback 컬럼을 sample_source로 들여온다.
  • engagement head는 fresh 샘플만, conversion head는 delayed 샘플만 학습한다(loss mask가 갈린다).
  • 메트릭 슬라이스는 fresh/delayed_clicked/delayed_non_clicked 3개다.
  • 튜닝 노브는 mact_in_app_loss_weight·train_view_through_heads·conversion_keep_mask다.
• ✅ ads_slim metric group이 새로 생겼다. 광고 랭킹 라인의 slim signal 조합이다.
  • 긍정 신호 3개(open link, external link long dwell, video quality view)가 들어간다.
  • 부정 신호 4개(not interested, block, report, mute)가 들어간다.
  • non-primary conversion click들도 들어간다.
• ✅ Muon 학습 레시피가 export에 정식으로 들어갔다. export되는 학습 파이썬 코드를 그대로 돌리면 프로덕션 Muon 학습이 되는 상태로 옮겨 갔다.
  • TRAINING.md·README·reference/README.md가 재작성됐다. flagship ranking config와 home_direct_packed_nano가 프로덕션 Muon 레시피로 end-to-end 학습된다고 명시한다.
  • 임베딩 rowwise AdaGrad에는 accumulator half-life decay, lazy per-row decay, decoupled weight decay의 세 옵션이 있다.
• ✅ home_direct_packed_nano가 NVIDIA GB300 하드웨어 오버라이드의 LR과 optimizer 설정을 상속하게 됐다. 오버라이드 자체는 4세대 공개부터 있었다 확인 — xrecsys.py:305-313. 같은 파일에는 4세대 공개부터 _H100_OVERRIDES도 있다(같은 파일 297행).
  • _GB300_OVERRIDES는 bs_per_device=512·ep=64·attn_impl="cutedsl_ranker_varlen_attn"·remat_policy=RematType.SAVE_GB300_RECSYS·unroll_layer_stack=True·LR 5e-4·checkpoint_every_n=300을 정의한다.
  • 이 attention 커널은 NVIDIA CUTLASS/CUTe DSL 기반 varlen attention 커널이고, xAI 자체 커널일 가능성이 있다.
• ✅ xAI 내부에 xai-o2 스토리지 시스템이 있음이 처음 확정됐다. S3 호환 오브젝트 스토리지 클라이언트인 xai-o2 crate의 인터페이스가 공개됐다.
  • BaseO2Client trait과 15 builder method(endpoint·bucket·access_key·chunk_size_mib·retry·timeout 등)를 노출한다.
  • 다만 build()가 오픈소스 빌드에서 항상 "the xai-o2 backend is not included in this build" 에러를 반환한다.
• ✅ PTOS의 아동 안전 cross-validation과 deluxe 재분류에서 Grok 4.5 internal이 완전히 빠지고 4.6 internal로 100% 전환됐다. 2026-08-19 커밋(4세대+4)에 시작한 dial-up(10%→30%→100%)이 이틀 만에 끝났다 확인 — aad7179, d0cef2f, 28e414f의 classifier.py.
  • 성인 콘텐츠 심판(4세대+2)은 이 dial과 무관하게 EAPI_GROK_4_5_X_ALGO를 계속 쓴다 확인 — classifier.py:563.
  • 4.5 관련 breaker·sampler·dial 상수가 모두 삭제됐다. 롤백할 수 없다.
• ✅ SlateContext가 NextActionDistribution의 필드 #9로 추가됐다. 이제 action distribution마다도 slate context가 붙는다. 소비 경로는 아직 뼈대 단계다.
  • 앞서 4세대+4에서는 ScoreInfo.slateContext(재순위 슬레이트 결정), 4세대+5에서는 PostCandidate.served_slate_context(home-mixer 소비)가 생겼다.
• ✅ grox reply_spam의 follower 임계가 60k → 80k로 올랐다. 4세대 공개 뒤 8일 사이 네 번째 상승(15k→30k→40k→60k→80k)이고, 이번 상승은 1.33배다.
• ✅ visibility-filtering dark_traffic의 타깃이 shadow에서 staging으로 바뀌었다. ⚠ 4세대+4 canon 재해석이 필요하다(변경 이력의 4세대+4).
  • 3일 만에 shadow 워크로드가 삭제되고 staging 미러링으로 재정의됐다.
  • 타깃은 xai-vf-shadow.prod.visibility → xai-vf-service.staging.visibility:grpc로 바뀌었다.
• 심층 분석 필요 (신규):
  • is_delayed_feedback upstream 파이프라인의 소스(kafka에 이 컬럼을 흘리는 conversion 재관측 이벤트 로거)
  • split_head_training_by_source가 _home_direct_packed_base()나 flagship config에서 True로 승격되는 시점(광고 conversion 학습이 프로덕션으로 전환된다는 신호)
  • train_view_through_heads opt-in이 승격되는 시점
  • GB300 override를 flagship도 명시적으로 상속하는지
  • xai-o2 실제 구현이 공개될지(가능성 낮음 추정)
  • EVERGREEN retrieval dataset의 재정의 방향(이름 변경 vs 원상 복구)
  • Grok 4.6이 정착한 뒤 4.7 shadow가 시작되는 시점
  • cutedsl_ranker_varlen_attn 커널이 xAI 자체 커널인지

4세대+7 공개로 해소된 것 / 신규 (2026-08-26)

이 공개로 가시성 필터링 재작성의 정합성을 실측하는 회귀 검증 채널이 생겼고, 브랜드 안전 판정이 4단계로 늘었다. PTOS 심판은 3개 카테고리로 넓어졌다.

• ✅ VF 재작성의 회귀 검증 채널이 연결됐다. 4세대 헤드라인이었던 VF 서브레포 재작성의 정합성을 이제 프로덕션 트래픽 규모로 감사할 수 있게 됐다. 적용 리스크가 크게 줄었다(변경 이력의 4세대+7).
  • visibility-filtering/reference_compare.rs(812줄 신규)가 dark_traffic 스택(4세대+4/+6) 위에 더해져, 실제 verdict 대조를 실측할 수 있게 했다.
  • VF_DUAL_CALL_HARNESS_ENABLED와, APP_ENV=prod이면 panic하도록 한 강제 장치로 staging 전용이다.
• ✅ BrandSafetyVerdict가 4단계로 늘었다. 이전에는 브랜드 안전 판정이 3단계(Safe/Low/Medium)로만 광고 인접성을 제어했고, 위험 정도가 다른 라벨들을 같은 tier에 뭉쳐 두었다. 이 한계가 해소됐다.
  • 새 tier는 HighRisk = 4다.
  • 기존 medium에 있던 5종 라벨(NSFW_HIGH_PRECISION·NSFW_HIGH_RECALL·GORE_AND_VIOLENCE_HIGH_PRECISION·PDNA·EGREGIOUS_NSFW)과 신규 SOFT_NSFW가 HighRisk로 승격됐다. V1과 V2가 대칭으로 이동했다.
  • 광고 유틸 has_avoid()가 Medium과 High를 둘 다 다루고, 인용 인접성 escalation도 Medium → High로 바뀌었다.
• ✅ V2 라벨 5종이 다운스트림 proto에 노출됐다. 이전에는 V2 라벨이 home-mixer 내부에만 있었다. 이제 feed 응답을 소비하는 다른 서비스에서도 V2 판정을 확인할 수 있다.
  • scored_posts_server.rs의 safety_label_to_proto mapping에 GROK_SFA_V2·GROK_NSFA_LIMITED_V2·GROK_NSFA_V2·GROK_NSFA_EXPANDED_V2·PTOS_REVIEWED가 추가됐다.
• ✅ V2 experiment의 DDG 트래킹이 연결됐다. V2가 experiment 단계이며, 매출/안전 metric을 관측하는 인프라가 완성됐다. 4세대+2(도입) → +3(재설계) → +7(experiment 실측) 8일 여정이 완결됐다.
  • ads_injection_logging_side_effect.rs가 EnableAdsBrandSafetyVerdictV2 experiment 버킷을 ddg_experiment_bucket 필드로 로깅한다.
• ✅ PTOS 심판 계층이 3개 카테고리로 넓어졌다. 이전에는 성인 콘텐츠 심판 클래스와, 4세대 공개부터 분류기 안에 있던 아동 안전 cross-model validation이 따로 있었다. 이제 ChildSafety, ViolentMedia, IllegalAndRegulatedBehaviors의 3개가 한 심판 클래스로 묶였다(Grox → PtOS 절).
  • 새로 생긴 심판은 SafetyPtosPolicyCrossValidator다. 이전의 성인 컨텐츠 심판은 SafetyPtosAdultContentCrossValidationJudge(4세대+2)다.
  • 새 심판 클래스는 4세대+2부터 성인 콘텐츠 심판이 쓰던 EAPI_GROK_4_5_X_ALGO 엔드포인트를 쓴다. 4세대+6에서 완전 제거된 EAPI_GROK_4_5_INTERNAL과는 별개다 확인 — classifier.py:100, 561.
  • X가 primary(4.6)와 judge(4.5 X_ALGO)를 서로 다른 모델·튜닝으로 유지하는 이중 스택을 굳혔다.
• ✅ PTOS의 ViolentSpeech·SuicideOrSelfHarm 카테고리에서 부모 스레드 렌더링이 켜졌다. 이제 grox가 post와 ancestors를 함께 LLM 프롬프트에 넣는다.
  • 이 두 카테고리는 대상 post의 문장만으로는 위해를 판정할 수 없다는 근본 이유가 있다.
    • 예를 들어 "죽고 싶어"는 게임 얘기냐 자해냐가 스레드 문맥으로만 판정된다.
  • USE_THREAD_RENDERER_CATEGORIES가 새로 생겼다.
  • USE_REASONING_CATEGORIES도 이 두 개에만 켜졌다(thinking 억제 해제).
• ✅ Phoenix 체크포인트 로더가 다중 노드 환경에 맞게 보강됐다. Muon과 GB300 세대의 restore path OOM 이슈에 대응한다(체크포인트 스택 소절).
  • 4세대+6이 flagship Muon 학습을 export에 정식 포함한 뒤 나온 후속 검증 결과다 추정.
  • xai_checkpointing/load.py에 domains(per-tensor slice), tag(checkpoint subdir), concurrent_gb(동시 디코딩 스로틀) 인자가 새로 생겼다.
  • XAI_RESTORE_NODE_SERIALIZE와 fcntl.flock()으로 노드당 restore를 직렬화한다.
• ✅ grox reply_spam이 답글 랭킹 점수를 지역 캐시에도 쓰기 시작했다. 점수를 Strato에 되쓰는 경로는 4세대 공개 때부터 있었고, 이번에는 지역 캐시 팬아웃이 더해졌다 확인 — d011592의 저장 모듈.
  • ReplyRankingScoreStratoLoader는 4세대 공개(47c1bcd) 때부터 점수를 Strato에 put하고 Kafka v2로 emit했다.
  • 4세대+7부터는 score ≤ 1.0이면 지역 캐시(Atla, Pdxa)로도 팬아웃한다.
• ✅ grox reply_spam의 follower 임계가 80k → 100k로 올랐다. 11일 동안 다섯 번(15k→30k→40k→60k→80k→100k) 올라 스팸 판정 대상이 계속 넓어졌다.
• ✅ X Spaces(오디오) 컨텍스트가 grox LLM 판정에 들어간다. 오디오 자체는 듣지 않지만, 스페이스 제목이 브랜드 안전·성인 컨텐츠 판정의 재료가 된다.
  • SpaceMetadata 클래스와 Post.space_metadata 필드가 새로 생겼다.
  • 렌더러는 오디오 스페이스 카드를 \n\nThis post has the following audio space card attached:\nAudio Space title: {title} 꼴로 프롬프트에 넣는다.
• 심층 분석 필요 (신규):
  • VF reference diff가 로그로만 나가는지, 별도 대시보드로 가는지(승격 임계값 정의: "diff율 X% 이하면 promote")
  • StratoVfClient가 감싸는 레퍼런스 VF의 실체(1·2세대 Scala VF의 잔재? 별도 스택?)
  • HighRisk tier가 광고 avoid 외의 후속 조치를 트리거하는지(랭커 강한 감쇠, 유기 노출 완전 차단)
  • V2 experiment의 홀드아웃/처리군 비율
  • EAPI_GROK_4_5_X_ALGO 튜닝 방식(4.5 base에 x-algorithm 파인튜닝을 한 것인지, 완전 별개 모델인지)
  • PTOS 심판 확장의 다음 카테고리(스팸·혐오 발화가 순차 확장 대상 추정)
  • SafetyPtosAdultContentCrossValidationJudge와 새 SafetyPtosPolicyCrossValidator의 통합 여부(같은 함수 시그니처, 다른 라우팅)
  • grox reply_spam score threshold 1.0의 의미(캐시 fanout 게이팅 임계가 확률인지 점수인지)
  • 오디오 컨텐츠 자체를 LLM이 듣는 파이프라인(스페이스 제목 텍스트만 vs 실 오디오 스트림 STT)
  • concurrent_gb의 프로덕션 튜닝 값과 restore 시간 증가 폭

4세대+8 공개로 해소된 것 / 신규 (2026-08-27)

이 공개로 스코어러가 요청한 조치를 abuse-enforcement 서비스가 실행하는 일반 경로가 생겼다. VMRanker 경로는 크게 단순해졌고, Following 파이프라인은 인용·리트윗 체인의 원 저자까지 블록 관계를 따지게 됐다.

• ✅ 스코어러가 요청한 액션을 AES가 실행하는 일반 파이프라인이 연결됐다. 이제 하드코딩 YAML 규칙 밖에서도 스코어러가 requested_actions를 직접 추가해 보낼 수 있다(변경 이력의 4세대+8).
  • 새 파일은 abuse-enforcement-service/service-lib/src/generic_actions.rs(663줄 신규)이고, 규칙 짝은 platform_row_without_requested_actions skip과 act_requested_actions act다.
  • 검증은 두 겹의 fail-closed다.
    • (a) 하드코딩 kind allowlist(user 5종·post 2종, MAX 16개/msg)
    • (b) GrowthBook 동적 allowlist(kinds·suspend_policies·labels)
  • 거부된 요청은 버리지 않고 outcome.info["requested_actions_skipped"] JSON과 GENERIC_ACTION_TOTAL{outcome=skipped, reason} 메트릭으로 남긴다.
  • 첫 클라이언트로 panda_reports_embedding_v10_rough_spam 라벨이 임시 PlatformManipulation suspend 규칙에 등장했다. embedding 기반 spam 검출기가 v10까지 재학습되는 지속 파이프라인이라는 방증이다.
• ✅ VMRanker 경로가 크게 단순해졌다. VMRanker는 rank server가 반환한 점수를 그대로 통과시키고, DPP 다양성은 서버 쪽 자체 로직이 담당한다.
  • AUTHOR_DIVERSITY_VALUE_MODEL_ID, MPN 폴드백 128줄, AuthorColdStart 후처리, ranking_scorer::effective_head_weights 88줄이 모두 삭제됐다.
  • 새 상수는 DPP_VALUE_MODEL_ID = "dpp" 하나뿐이다.
  • 4세대+5의 UseServedSlateContext(slate context를 Phoenix 서빙으로 이관)와 짝을 이루는 아키텍처 리팩터링이다. home-mixer는 얇게 두고 gRPC 서버들이 계산을 맡는다.
• ✅ Following 파이프라인이 quote/retweet 체인의 원 저자까지 블록 관계를 존중한다. X가 quote/retweet을 통한 블록 우회를 명시적으로 차단한다.
  • 새 hydrator FollowingBlockedByHydrator(65줄)가 각 candidate의 quoted/retweeted 저자 리스트로 SocialGraphClient에 batch check_blocked_by 조회를 한다.
  • AuthorSocialgraphFilter가 여섯 갈래로 거른다.
    • (i) 뷰어→저자 mute
    • (ii) 뷰어→저자 block
    • (iii) 저자→뷰어 block
    • (iv) quoted 저자→뷰어 block
    • (v) 뷰어→quoted 저자 block
    • (vi) 뷰어→retweeted 저자 block
  • reverse_chron_posts_pipeline.rs에 연결됐다(VF 필터 앞).
• ✅ Brazil2026ElectionFilter의 계정 리스트가 갱신됐다. 정기 갱신 관행이 정착했다는 신호다. 필터 시맨틱은 바뀌지 않았다(팔로우 예외 유지).
  • TSE dadosabertos 2026-08-25 판을 반영했다(+3,379줄, 파일 전체 4,947줄).
  • README에도 명시했다: "(Account list updated August 25, 2026.)".
• ✅ phoenix-rankall에 prefloor 스냅샷이 연결됐다. 신규 후보는 min_age 문턱을 넘기 전에는 별도 pool에 머물다가, 통과하면 곧바로 프로덕션에 반영된다.
  • 변경 파일은 store/base.rs(+202/−61)와 config/mod.rs(+51/−12)다.
  • min_age가 있는 window에 대해 prefloor_<window>.parquet 파일을 함께 로드한다(PREFLOOR_SLACK_SECS = 6.0 * 3600.0, 6시간 여유).
  • 4세대+2의 favoriteCount>=1 게이트 제거와 방향이 같은 freshness 개선이다.
• ✅ Phoenix copy_port의 rate-limit이 정확해졌다. 이전에는 순차 폴링으로 실제 in-flight concurrency가 상한을 넘을 수 있었다. 4세대+7의 restore path 보강과 짝을 이루는 서빙 쪽 보강이다.
  • copy_port_client.rs(+155)에서 join_all(futures)가 join_all(futures.map(tokio::task::spawn))로 바뀌었다.
  • 이제 tokio 스케줄러가 진짜 병렬로 실행하고, rate limit은 in-flight 카운트를 기준으로 다음 배치를 낸다.
  • 회귀 테스트는 2개다(rate_limit_caps_in_flight_despite_spawn, rate_limit_paces_between_spawned_batches).
• ✅ README의 Latest Updates가 Notable Updates로 바뀌었다. 매일 후속 커밋이 붙는데 README를 매일 갱신하지 않겠다는 선언이다 추정.
• ✅ 홈믹서 크론 미러(sync 2026-08-25)에서 가중치 두 개와 광고 브랜드 안전 V2 스위치가 바뀌었다 확인 — home-mixer/params/param.rs:342, 356, 908.
  • VqvWeight가 0.05에서 0.0으로, DwellWeight가 0.0에서 0.05로 바뀌었다.
  • EnableAdsBrandSafetyVerdictV2가 false에서 true로 바뀌었다. 이 값은 2026-09-16 커밋(4세대+22)에서 false로 돌아갔다가 2026-10-03 커밋(4세대+35)에서 다시 true가 됐다.
• 심층 분석 필요 (신규):
  • generic_actions allowlist의 첫 프로덕션 GrowthBook 설정(어떤 스코어러들에게 최초로 열리는지)
  • panda_reports_embedding_v10의 이전 v1~v9 진화 흐름과 v11 시점
  • DPP_VALUE_MODEL_ID의 실제 값 모델 아키텍처(재순위 절의 DPP(θ=0.65, K=150)와 같은 것인지 다른 것인지)
  • AuthorColdStart의 새 소비자 지점(vm_ranker에서 빠진 뒤 어디로 갔는지)
  • AuthorSocialgraphFilter가 For You 파이프라인에도 연결되는지
  • prefloor 스냅샷의 첫 활성 window
  • grox/flows/upa/ 서브플로우의 역할
  • URT client_event.rs +27줄의 새 event 유형

4세대+9 공개로 해소된 것 / 신규 (2026-08-28)

이 공개로 Phoenix 체크포인트의 저장과 복원이 모두 배치 파이프라인이 됐고, 학습 스텝의 유효성 게이팅이 dense와 embedding 사이에서 통일됐다. VF는 media fallback cache를 걷어 냈고, 광고 conversion 헤드 3종이 proto에 새로 생겼다.

• ✅ Phoenix 체크포인트 스택이 저장과 복원 양쪽에서 RSS 상한을 갖도록 다시 정리됐다. Muon+GB300 체크포인트 라운드트립 전체가 이제 batched pipeline이 됐다(체크포인트 스택 소절).
  • 4세대+7의 복원 쪽 보강(concurrent_gb throttle과 node-lock)에 대칭으로, 이번에는 저장 쪽이 정리됐다.
  • 저장 쪽에는 ThrottledD2HArrayHandler가 새로 생겼다. Orbax ArrayHandler.serialize를 오버라이드해 배치별로 D2H와 write를 하고, 예산은 save_concurrent_gb로 정한다.
  • XAI_SAVE_NODE_SERIALIZE env와 /dev/shm/xai_save_node_lock flock으로 저장을 노드 단위로 직렬화한다.
  • 배치 사이에 gc.collect()와 malloc_trim(0)을 부른다.
  • 복원 쪽의 새 함수 load_checkpoint_streamed는 stage→copy→evict를 tensor 단위로 밀어 가는 restore 변형이다. auto-window = min(max(max_leaf, total/16), 32GB)다.
  • 이 함수는 on_replaced 콜백으로 old/new array 쌍을 넘기고, copy_aliased_arrays로 aliased 참조를 미리 분리한다.
  • Trainer.warm_start_staging_spec 훅은 params-only 복원 때 pinned-host에 opt_state 사본을 만들지 않는다(keep_emb_opt_state=True 옵션).
  • admission.reset_estimates가 서빙 admission controller의 EWMA를 zero로 리셋한다.
  • copy_port_client 로깅에 GB/s를 함께 적는다.
• ✅ trainer_recsys의 valid_step 게이팅이 통일됐다. 이제 dense·embedding 중 어느 한쪽이라도 실패하면 양쪽 다 원본을 유지한다. Muon+GB300에서 dense·emb grad 스케일 divergence의 잔여 영향을 원천 차단한다.
  • dense sync와 async_no_deferred 두 경로에서 param update 순서가 재정렬됐다.
  • 이전에는 dense params가 dense grad-norm 검사만 통과하면 갱신되고, emb grad-norm이 실패하면 emb table만 롤백돼 몇 스텝 동안 비대칭 상태가 생길 수 있었다.
  • 통일된 조건은 keep_step = valid_step & emb_valid_step이다.
  • async 경로도 AsyncEmbGradientUpdate.pending=keep_step으로 동기화했다.
  • _create_async_emb_executables의 grad_norm_keep_threshold is None assert가 제거됐다(async에서도 threshold를 실제로 소비한다).
• ✅ grox reply_spam의 LM 프롬프트에 팔로워 카운트와 bio를 넣는 옵션이 생겼고, Manhattan 쓰기가 monotone-only가 됐다. 답글 랭킹 스코어가 시간에 따라 낮아지기만 하고 오르지 않아 label flapping을 원천 제거한다.
  • PostRenderer.render에 include_follower_count, include_bio 두 옵션이 추가돼, 유저 메타를 Handle / Follower Count / Name / Bio 4단으로 나눠 렌더링한다.
  • ThreadRenderer._render_thread는 include_follower_count가 켜지면 스레드의 모든 포스트에 팔로워 카운트를 넣고, bio는 post 0(원본)만 렌더링한다.
  • # Reply Author Info 헤더로 판정 대상을 명시한다.
  • _publish_to_reply_ranking_manhattan은 ReplyRankingScoreStratoLoader.fetch_reply_ranking_score로 기존 스코어를 조회한다. 새 스코어 > 기존이면 쓰기를 건너뛴다(higher_than_existing 카운터).
• ✅ VF TesHydrator에서 media fallback cache가 전부 제거됐다. 4세대+8의 VMRanker 대폭 단순화와 방향이 같은 "안정화 뒤 안전망 걷어냄" 흐름이다(변경 이력의 4세대+9).
  • 292줄이 삭제됐다. 1M-entry LRU, serve-stale/shadow 모드, 두 env 플래그(VF_MEDIA_FALLBACK_CACHE_SERVE_STALE_ENABLED, ..._POPULATE_ENABLED)가 모두 사라졌다.
  • VF 재작성 초기의 안전망이, 4세대+7 reference_compare 하니스로 정합성을 감사할 수 있게 되고 TES가 안정된 뒤에 걷혔다는 흐름이다.
• ✅ dark_traffic이 canary 워크로드를 미러링하지 않게 됐다. canary 이슈가 shadow verdict를 오염시키는 사고를 방지한다.
  • should_enable이 should_mirror(workload, ordinal, max_ordinal)로 바뀌었다.
  • workload=None이면 fail-closed이고, -canary 접미사가 붙은 워크로드는 mirror하지 않는다.
• ✅ 광고 conversion 헤드 3종이 proto에 새로 생겼다. 광고주 픽셀 발화를 랭커가 직접 예측하고, 픽셀과 long dwell의 결합도 별개 헤드로 둔다.
  • proto ActionName 191 ADS_PIXEL_FIRE, 192 ADS_LONG_DWELL_AND_PIXEL_FIRE, 193 P_LONG_DWELL_AND_PIXEL_FIRE다.
  • constants.py·recsys_model.py에는 아직 반영되지 않았다(proto 신설만). 학습·서빙 연결은 다음 커밋에서 볼 관측 포인트다.
• ✅ 광고 asset 재사용 이력이 서빙 요청에 실린다. 같은 크리에이티브가 여러 광고주에 노출되거나 재노출된 케이스를 attribution한다.
  • PredictNextActionsRequest.conv_asset_ids가 연결됐다. 새 ConvAssetIds message(impressed_time_ms / author_id / asset_id 3-array)가 필드 18로 추가됐다.
• ✅ home-mixer 로컬 SlateContext에 재구성 metrics용 필드 두 개가 추가됐다. served_slate_context 재구성 metrics를 세분화한다. proto 이관은 대기 중이다.
  • 필드는 SlateContext.recon_count_above와 recon_gap_above이고, 둘 다 Option<u32>다.
• ✅ retrieval 유저 타워에 use_history_segment_ids 플래그가 새로 생겼다. 기본은 꺼져 있다.
  • 기본값은 RecsysTwoTowerModelConfig.use_history_segment_ids=False다.
  • user_tower_segment_ids(B, T, ...)가 켜지면 히스토리 토큰에 zeros 대신 HISTORY_SEGMENT_ID를 부여한다.
  • pallas varlen flash-attention의 segment mask가 유저 히스토리 세그먼트를 다른 특수 토큰(예: user_features 토큰)과 격리한다.
• 심층 분석 필요 (신규):
  • save_concurrent_gb 프로덕션 튜닝 값과 저장 시간 증가폭
  • load_checkpoint_streamed가 기본 load_checkpoint를 언제 대체하는지(현재 두 함수 병존)
  • warm_start_staging_spec의 첫 활성 config(flagship에 이미 반영됐는지)
  • admission reset_estimates의 실제 호출 트리거(hot-swap 완료? traffic shift 감지?)
  • Manhattan reply_ranking monotone-only write가 실제 label flap 관측을 뒤집는다는 데이터
  • VF media fallback cache 제거 후 TES 실패 시 media feature fail-close 비율
  • ADS_PIXEL_FIRE·ADS_LONG_DWELL_AND_PIXEL_FIRE의 학습·서빙 연결(constants.py 반영 시점)
  • conv_asset_ids의 실제 소비 지점(recsys_model에서 어떤 헤드가 이 asset 이력을 쓰는지)
  • use_history_segment_ids의 프로덕션 승격 시점(flagship에서 True로 바뀌는 커밋)
  • recon_count_above/recon_gap_above의 계산식과 proto 이관 시점

4세대+10 공개로 해소된 것 / 신규 (2026-08-28)

2026-08-28 커밋(4세대+10)에서 광고 블렌더 신설, VF 안전 라벨 캐시 워머, Phoenix 체크포인트 복원과 서빙 수정이 공개됐다 확인(블렌더, 워머, Phoenix). 롤아웃 비율, 초기 설정값, 프로덕션 지표 같은 운영 값은 새 질문으로 남았다.

• ✅ 광고 블렌더에 네 번째 옵션인 MultiRiskAdsBlender가 생겼다. 광고의 BSR 등급과 포스트의 위험 등급을 조합한 인접성 매트릭스로 광고 슬롯을 정한다.
  • 기존 옵션은 safe_gap·partition_organic·time_gap이고, 이번에 multi_risk가 더해졌다.
  • 광고는 BsrNormal/BsrHigh 2단, 포스트는 Safe/MediumRisk/HighRisk 3단으로 나눈다.
  • BSR-high 광고에게만 medium-medium 슬롯을 허용한다. 광고주가 medium-risk 컨텍스트 노출을 opt-in하면 노출 총량이 늘어난다.
  • HighRisk 포스트는 어떤 광고와도 인접할 수 없다.
  • MultiRisk.enforcement·MultiRisk.slot_outcome·MultiRisk.serving_limitation 3종 metric으로 두 가지를 슬라이스해 관측한다.
    • 어느 안전 필터가 slot을 비우게 했는지
    • ads_supply/spacing/safe_posts 중 어느 것이 binding constraint였는지
  • 같은 커밋에서 blender_selector에 "partition_organic_low_risk" 앨리어스도 추가돼 옵션이 총 5개가 됐다.
  • experiment 게이트 뒤에 배치됐고, AdsBlenderType param 기본값은 아직 승격되지 않았다.
• ✅ safety-label twemcache에서 miss가 나면 그 일부를 표본으로 골라 비동기로 캐시를 채우는 워머가 생겼다.
  • visibility/baseTweetSafetyLabelMap 컬럼 조회에서 twemcache가 Miss(cache가 이 키를 모름)를 반환하면, SampledWarmer가 VF_CACHE_WARM_SAMPLE_PCT env로 확률 샘플링한다.
  • 샘플된 키는 tokio bounded mpsc(용량 1024)에 fire-and-forget으로 publish된다.
  • 백그라운드 drain이 500ms linger·최대 50 ID로 배치를 묶어 Strato batch fetch를 한다. 결과는 twemcache에 write-back된다.
  • NotFound(정의적 미존재)는 워밍 대상이 아니고, FallThrough(에러/타임아웃)도 워밍 대상이 아니다. 워밍은 캐시 미채워짐만 해소한다는 원칙이다.
  • bounded 채널이 포화하면 요청 처리를 절대 막지 않고 DroppedChannelFull 카운터만 올린다.
  • VF_GIZMODUCK_CLIENT_ID·VF_TWEMCACHE_CLIENT_NAME·APP_ENV 3개 env도 새로 생겼다(staging/prod 자동 분리).
• ✅ Phoenix trainer가 restore_streamed를 실제로 쓰게 됐다.
  • 4세대+9의 load_checkpoint_streamed 스캐폴딩이 이 커밋에서 maybe_load_checkpoint에 연결됐다.
  • 활성 조건은 restore_streamed=True AND format == "orbax" AND save_method != "tensorstore"다.
  • warm_start(do_not_load_opt_state) 경로에서 특히 이득이다. 이 경로에서는 opt state pinned-host 사본이 아예 생성되지 않는다.
  • _graft_replaced 콜백이 loaded tensor를 원래 state tree 자리에 in-place로 grafting한다. aliased state leaves는 조기 assertion으로 차단한다.
• ✅ Phoenix gRPC 압축 경로가 응답 트레일러를 잃던 버그가 고쳐졌다.
  • GrpcCompressionService는 zstd 압축 시 응답 body를 새 axum::body::Body::from(data)로 감싸면서 gRPC trailers(grpc-status·grpc-message)를 전부 잃었다.
  • 클라이언트가 status trailer 없이 EOF로 처리했을 가능성이 컸다.
  • 이제 collected.trailers().cloned()와 rebuild_response 헬퍼로 trailer를 복원한다. 압축이 성공할 때와 실패할 때 모두 같은 방식으로 통일됐다.
  • 회귀 테스트가 두 개 붙었다.
  • 같은 파일에 새 히스토그램 recsys_engine_response_compress_ms{method}가 생겼다(zstd encode 큐잉·CPU 시간).
• ✅ Phoenix copy_port가 shard 다운로드 순서를 pod마다 섞어 peer 부하를 고르게 했다.
  • 이전에는 각 pod가 sharded tensor를 다운로드할 때 모든 pod가 index 0부터 순서대로 요청했고, 첫 shard peer에 스파이크가 생겼다.
  • 새 shuffle_sharded_schedule(n, tensor_name)은 POD_NAME/HOSTNAME과 tensor name을 hash로 섞고, StdRng::seed_from_u64(hash)로 결정론적으로 셔플한다. 그 결과 각 pod가 다른 순서로 요청한다.
  • 완료된 결과는 restore_piece_order로 원래 순서로 되돌린다.
  • 두 소비 지점 emb_table.rs·copy_port_client.rs가 같은 방식으로 통일됐다.
  • replicated ownership은 in-order를 유지한다.
  • 4세대+7의 노드-serialize·concurrent_gb 하드닝을 peer 축까지 확장한 변경이다.
• ✅ home-mixer에 polling 요청을 관측하는 카운터 3종이 생겼다. 정기 polling refresh와 유저의 초기 요청을 서빙 지표에서 나눠 볼 수 있다.
  • 새 파일 home-mixer/util/strato_context.rs(신규 75줄)가 stratocontext[-bin] metadata에서 StratoContext.is_polling proto 필드를 뽑는다.
  • response_stats_side_effect.rs에 stat_request_context 함수가 연결됐다.
  • 요청마다 3종 카운터를 올린다.
    • <feed>.request.polling{polling=true|false, client}
    • <feed>.request.request_context{request_context, client}
    • <feed>.request.client{client, client_version}
• ✅ grox reply_spam이 점수를 Kafka에 먼저 저장하게 됐고, >= idempotency와 fetch 실패 처리도 바뀌었다.
  • 4세대+9의 monotone-only 규칙이 >에서 >=로 바뀌어 동점일 때도 쓰기를 건너뛴다. 카운터 이름도 higher_than_existing에서 not_lower_than_existing으로 바뀌었다.
  • 저장 순서가 Manhattan-first에서 Kafka-first로 뒤집혔다. Kafka append-only durability를 우선하고, Manhattan write 실패는 오프라인으로 복구할 수 있다.
  • fetch_reply_ranking_score의 방어적 try/except가 제거됐다. 이제 fetch 실패가 flow task 실패로 전파된다.
  • 같은 커밋에서 classifier_coordinated_spam.py의 PostRenderer.render 호출에 include_follower_count=True가 상시 켜졌다. coordinated spam 판정이 스레드 각 참여자의 팔로워 카운트를 프롬프트로 받는다.
• ✅ abuse-enforcement에 AIS thrift 스키마 conformance 테스트가 생겼다. AES의 payload 스키마가 다운스트림 thrift 서비스와 drift하지 않도록 CI로 보장한다.
  • 새 테스트 every_action_shape_encodes_against_the_ais_schema는 액션 형태를 실제 AIS thrift 스키마로 인코드해 회귀를 막는다.
  • 인코드 대상은 생성자 6종(suspend_user·add_user_label·add_post_label·bounce_arkose·bounce_captcha·spam_liveness_check)으로 만든 EnforcementAction 형태 8개다. suspend_user와 add_user_label은 두 가지씩 들어간다 확인 — service.rs:2104-2139.
  • 대상 스키마는 ActionIntakeService.intakeAction이다.
  • 스코어러를 새로 만들거나 payload 필드를 추가할 때 이 테스트가 조기 실패로 감지한다.
• ✅ home-mixer의 CJK muted keyword가 whole-token으로만 매칭되는지 확인하는 회귀 테스트가 생겼다.
  • 새 테스트는 viewer_muted_keyword_filter.rs의 test_cjk_keyword_whole_token_only다.
  • 京都를 뮤트하면 I visited 京都 last week는 걸러내야 하지만, 東京都に行くのが楽しみ는 걸러내지 않아야 한다(京都가 東京都의 부분 문자열).
  • 필터 본체는 이미 CJK word boundary를 다루고 있다. 이번에는 테스트만 추가됐고, 목적은 시맨틱을 잠그는 것이다.
• ✅ Brazil2026ElectionFilter의 계정 리스트 주석이 다시 정리됐다. 필터 시맨틱은 그대로다(팔로우 예외 유지).
  • 이전에는 665개 계정을 no live account was found / deleted account 등 단일 반복 주석으로 나열했다.
  • 이번에는 10개의 "not the candidate's actual account" 판정과 다수의 no live account found로 다시 정리했다.
  • 4세대+8의 리스트 갱신 관행과는 별개로, 이번 변경은 문서와 주석의 톤을 정리한 것이다.
• ✅ simclusters의 SimClustersInterestedIn2020 스냅샷 읽기에 폴백이 연결됐다. 배치 잡이 스냅샷 결측에 더 관대해졌다.
  • EntityToSimClustersEmbeddingsJob.scala에서 InterestedInSources.simClustersInterestedIn2020Source(dateRange, timeZone) 헬퍼를 직접 인라이닝했다.
  • 인라이닝한 코드는 세 부분으로 이뤄진다.
    • DAL.readMostRecentSnapshot(..., dateRange.prepend(Days(28)(timeZone)))
    • ExplicitLocation(ProcAtla)
    • fallbackPath = "viewfs://.../simclusters_v2_interested_in_20M_145K_2020/_TMP_RECOVERY/{timestamp}"
  • 28일 룩백, 특정 데이터센터 pin, 임시 복구 경로 폴백을 함께 쓴다.
• 이 커밋으로 새로 생긴 심층 분석 질문은 다음과 같다.
  • multi_risk 블렌더의 experiment 롤아웃 비율과 BSR-high opt-in 광고주 비중
  • medium-medium 배치가 revenue/브랜드 안전 metric에서 만드는 uplift
  • VF_CACHE_WARM_SAMPLE_PCT의 초기 프로덕션 값과 twemcache miss rate 변화
  • gizmoduck_client_id() staging 분리가 어떤 서비스 quota를 나누는지
  • restore_streamed의 첫 활성 config(현재 기본 false로 추정 추정)
  • recsys_engine_response_compress_ms의 P99 목표치와 gRPC trailer 유실 버그의 프로덕션 관측 증거
  • copy_port shard 셔플 도입 전후 shard 0 peer의 request rate 분포
  • home-mixer polling 요청 비율의 실제 분포(feed·client별)
  • reply_spam이 Manhattan write를 건너뛰는 비율의 시간축 변화(monotone-only와 >= 이후 몇 %를 건너뛰는지)
  • AIS conformance 테스트가 스코어러 개발 사이클에서 실제로 잡아내는 회귀 빈도

4세대+11 공개로 해소된 것 / 신규 (2026-08-28)

2026-08-28 커밋(4세대+11)에서 home-mixer가 Phoenix에 보내는 요청에 리랭커 헤드 태그 파라미터가 연결됐고, Phoenix의 임베딩 테이블 수신 처리가 blocking pool로 옮겨졌다 확인(변경 이력). 같은 커밋의 VF 규칙 계층 리팩터는 정책을 바꾸지 않았다 확인(변경 이력).

• ✅ visibility-filtering 규칙 계층이 리팩터됐다. 정책은 바뀌지 않았고, 회귀를 막는 자산이 쌓였다.
  • 24개 rule 파일이 +1,522/−1,151로 얇아졌다.
  • RuleContext가 새 파일 context.rs로 분리됐고, 25여 개 도메인 메서드(is_stale_tweet, viewer_country_in, has_tweet_nsfw_user_flag 등)를 노출한다.
  • 개별 rule의 조건 검사는 도메인 메서드 호출로 대체됐고, 시맨틱은 유지됐다.
  • 90건 골든 코퍼스(golden_corpus.rs, +1039)가 13개 카테고리로 판정 결과를 pin한다.
  • CI에는 every_wired_rule_decides_a_corpus_case 어설션이 걸린다. 연결된 rule마다 최소 한 건의 결정자 케이스가 있어야 한다는 검사다.
  • 4세대+7 reference_compare, 4세대+9 media fallback cache 제거로 이어진 흐름의 다음 단계다.
• ✅ home-mixer가 Phoenix에 보내는 요청에 RerankerHeadTag 파라미터가 연결됐다. 서버 소비 로직은 이 커밋에 없다.
  • 새 파라미터는 param!(RerankerHeadTag, i64, "rust_home_mixer_reranker_head_tag", 0)다.
  • PostCandidate.reranker_head_tag: Option<u32> 필드가 생겼다. PhoenixScorer가 이 값을 요청과 scoring_sequence에 실어 보내고, 응답에서 라운드트립한다.
  • proto 두 자리에 대칭으로 추가됐다: ScoreInfo.rerankerHeadTag = 6, UserActionSequence.rerankerHeadTag = 9(Rust/Python proto 동시).
  • 헤드 라우팅을 켜기 전의 wiring 단계다 추정.
  • 모델 안 여러 리랭커 헤드 중 하나를 A/B 실험으로 고르는 스위치로 읽힌다 추정.
• ✅ Phoenix emb_table의 gRPC 수신 처리가 blocking pool로 분리됐다.
  • 이전에는 대용량 임베딩 테이블을 다운로드할 때 non-temporal 복사와 Adler-32 계산이 gRPC 콜백에서 직접 실행돼 tokio 런타임 스레드를 붙잡았다.
  • 이제는 데이터를 sync_channel(2)에 4 MiB 청크로 밀어 넣고, tokio::task::spawn_blocking으로 따로 실행한다.
  • RDMA 경로에서도 최종 합산까지 spawn_blocking으로 소비한다.
  • 새 헬퍼 JoinOnDrop<T>는 blocking 태스크를 반드시 종료해 핸들 누수를 막는다. 정상 경로에서는 join().await를 쓰고, drop될 때는 block_in_place와 block_on(handle)을 쓴다.
  • 4 MiB 청크와 sync_channel(2) 백프레셔가 수신 속도를 조절한다.
• ✅ copy_port_client에 join_transfers 헬퍼가 생겼고, proto_parser에 Bytes 콜백 타입이 생겼다.
  • 이전 join_all(...spawn) → collect → map_err 4행 관용구를 join_transfers 헬퍼 하나로 뽑았다(동작 변화 없음).
  • proto_parser.rs의 새 Bytes 콜백 타입(FnMut(usize, Bytes))은 청크를 소유권 이동으로 넘길 수 있다.
  • emb_table은 아직 Str 시그니처를 유지한다. 진짜 zero-copy는 후속 관측 포인트다.
• 이 커밋으로 새로 생긴 심층 분석 질문은 다음과 같다.
  • RerankerHeadTag의 서버 쪽 소비 로직(Phoenix Python 서빙 코드에서 헤드 라우팅)
  • UserActionSequence와 ScoreInfo 두 자리에 붙은 이유(요청·응답 대칭 vs 다른 목적)
  • RerankerHeadTag의 첫 experiment 승격 시점(0 → 1+로 바뀌는 커밋)
  • Bytes 콜백을 emb_table이 언제 소비하는지(진짜 zero-copy 경로)
  • gRPC 콜백 분리 도입 전후 tokio 런타임의 tail latency 개선폭
  • 골든 코퍼스 90건이 이전 프로덕션 판정과 일치하는지 검증(리팩터가 시맨틱 변경을 숨겼을 가능성)

4세대+15 공개로 해소된 것 / 신규 (2026-09-04)

2026-09-04 커밋(4세대+15)은 grox 답글 스팸 판정, PTOS 심판 모델 배정, Phoenix 서빙과 학습, VF hydration을 한꺼번에 바꿨다 확인(변경 이력). 새 질문에는 새 판정 경로의 활성 비율, SID를 요청에 채우는 지점, H100 학습 config가 있다.

• ✅ grox에 스레드 chain 단위로 판정하는 두 번째 답글 스팸 경로가 생겼다. 이름은 PlanMultiStepReplySpam이다.
  • Gemma 2에 스레드 전체를 프롬프트로 넣고 "spam_post_indexes" 집합을 뽑아낸다.
  • 진입 조건은 8개다: 답글이며, ancestors 있음, root 팔로워 ≥ 1,000, root 저자 ≠ 답글 저자, 직계 부모 저자 = 답글 저자, high page-rank/grey badge 아님, Grok/Gork 아님, 깊이 ≥ 2.
  • 이 조건들이 잡으려는 패턴은 "한 저자가 자기 답글에 자기가 답한 chain으로 root 노출을 훔치는 시간축 담합 스팸"이다.
  • LM 출력에는 3단 안전장치가 있다: newest reply not flagged → drop, other-author → drop, singleton → drop.
  • 스팸으로 판정하면 score = 0.0으로 강제 저장한다.
  • ReplyRankingTaskGenerator·RecoveryTaskGenerator 두 스트림에 plan이 주입된다.
  • Coordinated_spam(계정 담합)과 나란한 시간축 담합 축이 canon에 추가된다.
• ✅ PTOS 심판 스택에서 카테고리마다 다른 모델을 쓰는 첫 실체가 확인됐다.
  • 4세대+7은 3개 카테고리(ChildSafety·ViolentMedia·IllegalAndRegulatedBehaviors)의 SafetyPtosPolicyCrossValidator에 단일 모델 EAPI_GROK_4_5_X_ALGO를 배정했다.
  • 이번 커밋에서 IllegalAndRegulatedBehaviors만 EAPI_GROK_4_1_FAST_X_ALGO로 이관됐다.
  • 이 호출은 Breaker 없이 직접 하고, 메트릭 이름도 ..._with_grok_4_1로 바뀌었다.
  • X가 심판 모델을 카테고리별로 따로 튜닝하는 정책이 명시화됐다.
• ✅ Gemma 4가 IllegalAndRegulatedBehaviors의 first-pass로 승격됐고, Gemma 확률 dial이 제거됐다.
  • USE_GEMMA_CATEGORIES = {Spam, IllegalAndRegulatedBehaviors}가 됐다(이전 Spam만).
  • if random.random() < self.use_oai_gemma4_dial 확률 게이트가 아예 제거돼, 두 카테고리가 100% Gemma로 라우팅된다.
  • 지워진 dial 값은 4세대 공개부터 1.0이었으므로, Spam 쪽 동작은 바뀌지 않았다 확인 — 47c1bcd와 85ac72a의 classifier.py. 실제 변화는 IllegalAndRegulatedBehaviors가 Gemma로 간 것이다.
  • task_safety_ptos_policy.py도 재분류 트리거에 IllegalAndRegulatedBehaviors를 추가했다. 이로써 3단 스택(Gemma first-pass → deluxe cross-model → Grok 4.1-fast judge)이 완성됐다.
• ✅ Phoenix 서빙에서 SID retrieval 사이드카가 완전히 제거됐다. 이제 히스토리 SID는 요청에 실려 들어온다.
  • 삭제된 것은 다섯 가지다.
    • sid_client.rs(189줄)
    • sid_retrieval_runner.py(17줄)
    • --sid_endpoint CLI
    • xai-recsys-sid-proto 의존성
    • PySemanticIdClient 파이썬 바인딩
  • 로그에는 "Parsing history SIDs from the request (sid_num_levels=%d); no sid_endpoint"라는 문구가 남았다.
  • SID codeword 조회 책임이 online serving 밖으로 옮겨졌다. home-mixer(또는 candidate hydration 층)가 request를 만들 때 이미 SID를 담아 보낸다는 계약이다.
  • 요청당 gRPC 호출이 하나 줄고, SID 인프라의 fault domain이 줄어든다.
• ✅ Phoenix use_pinned_d2h의 기본값이 False에서 True로 바뀌었다.
  • D2H 전송 속도는 CUDA pinned host memory로 ~50 GB/s이고, JAX 기본은 ~3 GB/s다. 추론당 ~29ms를 절감한다.
  • 이 옵션은 4세대+6에서 도입됐고, 이번 커밋에서 기본값이 바뀌었다.
• ✅ Phoenix 학습에 H100용 remat 정책이 생겼다. GB300 외에 H100에서도 학습이 도는 첫 코드 신호다.
  • 새 정책은 SAVE_H100_RECSYS = 32이고, custom_remat_policy에 새 분기로 들어갔다.
  • GB300과 같은 이름 리스트(attn_outputs·dense_outputs·gate_up_proj·query_heads·key_heads·value_heads 등)를 rematerialization 저장 대상으로 지정한다.
  • _H100_OVERRIDES 같은 hardware-specific config block은 이 커밋에 아직 없다.
  • X 학습 하드웨어가 GB300만이 아니라는 사실 자체가 canon에 새로 반영할 내용이다.
• ✅ FA4 attention 커널이 가변 길이 히스토리를 네이티브로 지원하게 됐다.
  • build_dense_block_sparse_layout 시그니처에 hist_valid_len이 추가됐다.
  • layout 계산이 numpy에서 jax.numpy로 옮겨졌다(캐시 제거).
  • valid_block_upper·valid_block_lower 두 마스킹 필드가 추가돼, 커널이 partial-history block을 직접 처리한다. partial-history block은 tile 안 유효 토큰이 tile 크기 이하인 block이다.
  • 신규 유저와 짧은 세션에서 학습·추론 정확성이 개선된다.
  • 4세대+6 cutedsl_ranker_varlen_attn의 varlen 시맨틱이 히스토리 축까지 확장됐다.
• ✅ visibility-filtering의 hydration과 safety-label 코드가 크게 단순화됐다. 800+ 줄이 순 감소했다.
  • 줄어든 파일은 registry.rs −378, safety_label_source/codec.rs −206, hydration/mod.rs −90, hydration/fallback_cache.rs −87, config.rs −118 등이다.
  • "재작성 안정화 뒤 안전망 걷어냄" 흐름이 이어진다. 앞선 단계는 4세대+9의 media fallback cache 제거, +8의 VMRanker 128줄 삭제, +11의 rules 리팩터, +14의 Box<dyn Rule> 소거다.
  • 같은 커밋에서 fixtures.rs +81, golden_corpus.rs +102로 회귀 방어망은 더 두꺼워졌다.
• ✅ Brazil2026ElectionFilter가 정기 갱신됐다. 4세대+8의 정기 갱신 관행이 이어진다. 정치인 X 계정 매핑을 매주 계속 검증한다는 신호다.
  • 계정 ID 166개가 하드코딩으로 추가돼, 집합이 2,388개에서 2,554개가 됐다 확인 — brazil_2026_election_filter.rs. 추가된 계정의 예는 +@nanacachen·+@AecioNeves·+@lgmbrasilia·+@crismonteirosp·+@rodrigolimamdh·+@samiabomfim·+@gabrielmagno_13이다.
  • "not the candidate's actual account" 판정도 몇 건 추가됐다.
• ✅ 외부 기여자의 PR #88 (e4dcedd)이 머지됐다. 4세대의 오픈소스 태도가 실제로 외부 PR을 받는다는 증거다.
  • vf_candidate_hydrator.rs에서 VF lookup 전에 in_network_ids를 dedup하는 두 줄이 추가됐다.
• 이 커밋으로 새로 생긴 심층 분석 질문은 다음과 같다.
  • PlanMultiStepReplySpam의 초기 활성 트래픽 비율과 판정 metric(experiment 게이팅이 이번 diff에 없음)
  • FOLLOWER_COUNT_THRESHOLD_FOR_SPAM_DETECTION = 1000 튜닝 이력
  • multi-step 판정 결과가 experiments에서 답글 랭킹에 어떻게 반영되는지
  • home-mixer 또는 candidate hydration 층에서 SID를 채우는 hydrator의 이름·소스(sid_client 제거 이후 SID를 request에 담는 지점)
  • SID codeword storage 백엔드(Manhattan? Strato? phoenix-rankall 자체?)
  • SAVE_H100_RECSYS의 첫 활성 config(어느 recipe가 H100에서 학습되는지)
  • _H100_OVERRIDES 등장 시점과 H100 vs GB300 batch/attn/remat 튜닝 차이
  • safety_label_source/codec.rs 206줄 삭제 실체(어떤 wire 포맷·라벨 소스를 걷어냈나)
  • EAPI_GROK_4_1_FAST_X_ALGO가 4.5 X_ALGO와 어떻게 다른지(latency·비용·정확도 trade-off)
  • 다음 카테고리 확장 후보(Spam·IllegalAndRegulatedBehaviors 다음 Gemma 승격 대상, ChildSafety·ViolentMedia 심판을 4.1-fast로 이관하는 시점)

↑ 목차

출처

xai-org/x-algorithm(2026, 공개 소스코드, Apache 2.0)의 git 로그는 2026-10-21 기준으로 직접 확인했다. 그 시점까지 4세대 이후 커밋은 46개이고, 가장 최근 커밋은 2026-10-20 커밋(4세대+45)이다.

아래 절과 표 행은 기준 커밋이 따로 정해져 있다.

• visibility-filtering-client/vf_client.rs — 2026-09-09, +130/−62. TweetVisibility.action 필드와 TweetVisibility::to_visibility_reason() 헬퍼를 새로 만들었다. action_from_strato_reason()은 Strato non-SafetyResult reason을 Drop으로 바꾸고, NotEvaluated를 Allow로 승격한다.
• visibility-filtering-client/models.rs — 2026-09-09, +7. FilteredReason::ViewerBlocksAuthor variant와 proto to/from 매핑을 추가했다.
• home-mixer/filters/vf_filter.rs — 2026-09-09, +27/−69. should_drop_action은 Drop(_)·Tombstone·NotEvaluated만 버리고 Allow·Interstitial·Avoid·Downrank는 남긴다. 테스트는 partition 매트릭스 8-case로 다시 썼다.
• home-mixer/candidate_hydrators/vf_candidate_hydrator.rs — 2026-09-09, +159/−23. visibility_fields 헬퍼를 새로 만들고, should_drop_ancillary를 action 기반으로 다시 썼다.
• home-mixer/util/urt/ad_marshaller.rs — 2026-09-09, +258/−3. marshal_header_image_prompt_ad와 HeaderImagePromptAdInfo 진입 분기를 새로 만들었다. entry namespace는 header-image-prompt-ad이고, URT MessageContent::HeaderImagePrompt에 연결했다. secondary CTA를 지원하며 테스트는 3개다.
• grox/core/data_loaders/media_loader.py — 2026-09-09, +100/−19. hydrate_video_preview에 30초+ 영상용 4-gate를 두었다. _extract_broadcast_video는 BroadcastLoader.load_broadcast로 프레임을 정규화하고, _get_broadcast_loader는 lazy init 방식이다.
• grox/core/lm/convo.py — 2026-09-09, +18. Video.preview_image: bytes | None 필드와 PREVIEW_IMAGE_LABEL = "[Video Preview Thumbnail]" 상수를 추가했다. interleave_storyboard·_image_part는 미리보기 이미지를 앞부분에 삽입한다.
• grox/flows/ptos/task_safety_ptos_adult_content_leading_frames_filter.py — 2026-09-09, +18/−8. deluxe fav 게이트를 지우고 broadcast 진입을 정식으로 허용했다. eligible.count에는 media = both|broadcast|video 태그를 붙인다.
• grox/flows/ptos/task_safety_ptos_safemodel_sex_nudity.py — 2026-09-09, +21/−2. _FRAME_KINDS = {video_frame, broadcast_frame} 상수와 _iter_broadcast_videos를 추가했다. enable_local_broadcast_frame_extraction으로 gate하는 분기도 넣었다.
• phoenix/README.md — 2026-09-09, +3/−3. nano config 표의 Multimodal post embedding 행을 고쳤다.
  • v5 on xrecsys_seqpack; off on home_direct_packed에서 off (home_direct_packed and xrecsys_seqpack)로 바뀌었다.
• phoenix/xrex/utils/gpu.py — 2026-09-09, +32/−3. _parse_cpulist와 schedulable_cpus(*nodes)를 새로 만들었다. pin_process_to_local_numa는 os.sched_setaffinity(0, schedulable_cpus(node))로 isolated CPU를 뺀다.
• home-mixer/scorers/ranking_scorer.rs — 2026-09-08, +93/−29. ScoringWeights::perturbed(), perturbation_sign(), weights_mut()를 새로 만들었다. 참여 헤드 26개의 가중치를 요청마다 exp(σ×md5-sign)으로 곱해 스케일링하고, recompute_sums()로 다시 계산한다.
• home-mixer/params/param.rs — 2026-09-08, 파라미터 두 개를 새로 만들었다. 헤더의 sync 시각은 2026-09-08T16:24:06Z다.
  • WeightPerturbationSigma: f64, 기본값 0.0
  • WeightPerturbationSalt: String, 기본값 ""
• grox/flows/mm_emb/embedder_v8_search.py — 2026-09-08, 113줄 신규. MultimodalPostEmbedderV8Search와 MultimodalPostEmbedderV8SearchBackfill이 들어 있다.
• grox/flows/mm_emb/renderer_v8_search.py — 2026-09-08, 461줄 신규. V8SearchEmbedPostRenderer.render_for_embedding이 들어 있다.
  • 렌더링 구성은 instruction prefix, 저자 블록(팔로워 humanize와 tier), 본문 4000자, quoted 1000자, ASR 2000자, 16-frame media budget이다.
• grox/flows/mm_emb/adaptive_min_fav.py — 2026-09-08, 63줄 신규. PI 컨트롤러가 target QPS를 관측해 fav 임계를 조정한다. window는 30초, deadband는 0.1, gain은 0.3이다.
• grox/flows/mm_emb/task_backfill_fanout.py — 2026-09-08, 85줄 신규. TaskBackfillBatchFanout, Semaphore(240), BackfillConsumerDedup, BatchedFavHydrator가 들어 있다.
• grox/flows/mm_emb/task_backfill_gate.py — 2026-09-08, 60줄 신규. TaskBackfillFavGate와 TaskBackfillPreloadGate가 들어 있다. 뒤의 게이트는 이미 V8_SEARCH_MODEL_VERSION="v8_search_1"로 임베딩된 포스트를 건너뛴다.
• grox/flows/mm_emb/plan_post_embedding_v8_search.py, plan_post_embedding_v8_search_for_reply.py, plan_post_embedding_v8_search_backfill.py, plan_post_embedding_v8_search_backfill_batch.py — 2026-09-08, 총 130줄 신규. 네 개의 Plan이다.
• grox/flows/mm_emb/backfill_consumer_dedup.py, batched_fav_hydrator.py — 2026-09-08, 총 114줄 신규.
• grox/flows/mm_emb/constants.py — 2026-09-08, +9줄. 상수를 추가했다.
  • POST_EMBEDDING_V8_SEARCH_STREAM·POST_EMBEDDING_V8_SEARCH_FOR_REPLY_STREAM·POST_EMBEDDING_BACKFILL_STREAM·TOPIC_EMBEDDING_V8_SEARCH·RECSYS_V8_SEARCH_EMBED·RECSYS_V8_SEARCH_BACKFILL_EMBED·V8_SEARCH_STATE_KEY·V8_SEARCH_MODEL_VERSION
• phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto, phoenix/python/common/xai-proto/proto/recsys.proto — 2026-09-08, 양쪽 proto에 ContentFeatures message와 TweetInfo.contentFeatures=36·quotedContentFeatures=37 필드를 동시에 새로 만들었다.
• home-mixer/models/content_features.rs — 2026-09-08, 185줄 신규. build·build_quoted·TextMetrics::of가 들어 있다. Twitter 텍스트 길이 규칙(URL=23, CJK=2, ZWJ/skin-tone modifier=0)을 회귀 테스트 5개로 고정했다.
• grox/flows/ptos/plan_safety_ptos_adult_content_leading_frames.py — 2026-09-08, 56줄 신규. 8단 DAG다.
• grox/flows/ptos/task_safety_ptos_adult_content_leading_frames_filter.py — 2026-09-08, 81줄 신규. 진입 필터는 6단이다(작성자 존재·deluxe fav·30초+ 영상·prior PTOS 통과·non-NSFW·prior_adult 또는 fav≥512). video.crop_seconds = 10.0으로 설정한다.
• grox/flows/ptos/constants.py — 2026-09-08, 상수를 추가했다.
  • SAFETY_PTOS_ADULT_CONTENT_LEADING_FRAMES·TOPIC_ADULT_CONTENT_LEADING_FRAMES·ADULT_CONTENT_LEADING_FRAMES_CROP_SECONDS=10.0·MIN_DURATION_SECONDS=30.0·UNCONDITIONAL_FAV=512
  • DELUXE_TIER_TASK_TYPES에도 새 항목이 들어갔다.
• phoenix/xrex/cutedsl/ranker_fa4/flash_fwd.py, flash_fwd_sm90.py, flash_bwd.py, flash_bwd_sm90.py, flash_bwd_preprocess.py, ampere_helpers.py — 2026-09-08, 총 5,080줄 신규. Dao-AILab flash-attention 원본을 fork한 코드다. SM80/SM90 forward·backward를 완전히 오픈소스로 공개했다.
  • 라이선스 표기는 SPDX Apache-2.0, Copyright 2026 X.AI Corp.이다.
• phoenix/xrex/cutedsl/ranker_fa4/block_sparse_utils.py, ranker_attention_fa4.py, ranker_attention_varlen_fa4.py, mask.py — 2026-09-08, 4파일 대규모 수정(+926/−656). 변경 범위는 block-sparse iterator, fwd 진입점, varlen 정리, AttentionMask backward 확장이다.
• phoenix/NOTICE — 2026-09-08, +198줄. flash-attention 서브구성요소의 저작권 표기를 추가했다.
• phoenix/xrex/utils/aot.py — 2026-09-08, +54/−1. _sanitize_cutlass_calls와 cutlass_module_device_digest가 들어 있다. 뒤의 함수는 ELF 헤더를 파싱한 뒤 device blob의 SHA256을 구한다. AOT_CACHE_VERSION은 "20260705"→"20260904"로 바뀌었다.
• phoenix/crates/serving/xai-recsys-engine/src/copy_port_client.rs — 2026-09-08, +207/−9. full_prefixes_newest_first·select_bundle_checkpoint·download_named_files가 들어 있다. MANIFEST.json이 있는 checkpoint만 번들이 완료된 것으로 보고 고른다.
• phoenix/xrex/train/recsys_bundle_export.py — 2026-09-08, +48. _serving_sequence_len을 새로 만들고 MANIFEST에 model_sequence_len 필드를 넣었다.
• home-mixer/candidate_hydrators/quote_hydrator.rs — 2026-09-08, +142/−12. MediaInfoCacheClient를 주입한다. get_quoted_content는 core data와 media info의 200ms 병렬 hydration, 그리고 QuickCache로 이뤄진다.
• home-mixer/candidate_hydrators/media_info_hydrator.rs — 2026-09-08, +70/−15. 미디어 정보 조회를 리팩터했다.
• home-mixer/bin/pipeline_components_json.rs — 2026-09-08, 파일 전체를 삭제했다(76줄).
• grox/flows/reply_spam/task_multi_step_reply_spam.py — 2026-09-04, 206줄 신규. TaskMultiStepReplySpamFilter(8축 게이팅), TaskMultiStepReplySpamDetection, TaskWriteMultiStepReplySpamReplyRanking이 들어 있다.
• grox/flows/reply_spam/plan_multi_step_reply_spam.py — 2026-09-04, 29줄 신규. filter → media hydration → detection → write로 이어지는 4-태스크 DAG다.
• grox/flows/reply_spam/classifier_multi_step_reply_spam.py — 2026-09-04, 226줄 신규. MultiStepReplySpamScorer가 들어 있다(Gemma 2, _thread_posts MAX_THREAD_SIZE=10 앞뒤 5씩). 후처리는 _drop_if_newest_reply_not_flagged·_drop_other_author_posts·_drop_singleton 3단이다.
• grox/flows/reply_spam/state_multi_step_reply_spam.py — 2026-09-04, 13줄 신규. MultiStepReplySpamResult pydantic 모델이다.
• grox/flows/reply_spam/prompts.py — 2026-09-04, multi_step_reply_spam_system_prompt()를 추가했다. 프롬프트 원문은 gameability 방지를 목적으로 export에서 제외됐다.
• grox/flows/reply_spam/generators.py — 2026-09-04, ReplyRankingTaskGenerator·ReplyRankingRecoveryTaskGenerator의 PLANS_TO_INJECT에 PlanMultiStepReplySpam.KEY를 추가했다.
• grox/flows/ptos/classifier.py — 2026-09-04, EAPI_GROK_4_1_FAST_X_ALGO sampler를 등록했다. _validate_illegal_and_regulated_behaviors를 4.5에서 4.1-fast로 옮겼다. USE_GEMMA_CATEGORIES에 IllegalAndRegulatedBehaviors를 추가하고, use_oai_gemma4_dial 확률 게이트를 없앴다.
• grox/flows/ptos/task_safety_ptos_policy.py — 2026-09-04, classify_policy_for_violation의 재분류 트리거에 IllegalAndRegulatedBehaviors를 추가했다.
• phoenix/crates/serving/xai-recsys-engine/src/sid_client.rs — 2026-09-04에 삭제됐다(−189줄). 링크는 이전 커밋을 가리킨다.
• phoenix/xrex/inference/model_runner.py — 2026-09-04, sid_endpoint 필드와 create_server의 sid_client 조립 코드를 지웠다. use_pinned_d2h default는 False → True로 바뀌었다.
• phoenix/xrex/inference/launch_inference.py — 2026-09-04, --sid_endpoint CLI 인자를 지우고, --use_pinned_d2h default를 True로 바꿨다.
• phoenix/crates/serving/xai-recsys-engine/src/python.rs — 2026-09-04, sid_client: Option<Arc<SemanticIdClient>> 필드를 두 struct에서 지웠다. server_impl 매크로 인자와 add_class::<PySemanticIdClient>() 등록도 지웠다.
  • 두 struct는 RecsysPredictorImpl·RecsysRetrievalPredictorImpl이다.
• phoenix/crates/serving/xai-recsys-engine/Cargo.toml — 2026-09-04, xai-recsys-sid-proto 의존성을 지웠다.
• phoenix/xrex/models/remat.py — 2026-09-04, RematType.SAVE_H100_RECSYS = 32를 새로 만들고, custom_remat_policy에 분기를 넣었다.
• phoenix/xrex/cutedsl/ranker_attention_fa4.py — 2026-09-04, build_dense_block_sparse_layout의 시그니처에 hist_valid_len을 추가하고 batch_size를 제거했다. jax.numpy로 옮기고 valid_block_upper·valid_block_lower 필드를 넣었다. _DENSE_BS_LAYOUT_CACHE는 지웠다.
• visibility-filtering/rules/registry.rs — 2026-09-04, +8/−378. 코드를 대폭 삭제했다.
• visibility-filtering/safety_label_source/codec.rs — 2026-09-04, +15/−206. wire 포맷을 통합했다.
• visibility-filtering/hydration/mod.rs — 2026-09-04, +11/−90. hydration entry를 지웠다.
• visibility-filtering/hydration/fallback_cache.rs — 2026-09-04, +25/−87. 캐시 계층이 얇아졌다.
• visibility-filtering/config.rs — 2026-09-04, +7/−118. config 계층을 통합했다.
• home-mixer/filters/brazil_2026_election_filter.rs — 2026-09-04, +339/−4. 정기 갱신이다. 계정 ID 166개를 추가했고(2,388 → 2,554개), "not the candidate's actual account" 판정 몇 건과 소수의 "no live account found"가 있다.
• home-mixer/candidate_hydrators/vf_candidate_hydrator.rs — 2026-09-03, PR #88이다(외부 기여, joshs1017dev). in_network_ids를 VF lookup 전에 dedup하는 두 줄을 추가했다.
• home-mixer/server.rs — 2026-09-02, gRPC 피드 서비스 진입점 5개에서 query.return_backbone_scores = true를 하드코딩했다.
  • 진입점은 ScoredPosts·ForYouFeed·ForYouFeed polling·RankedFollowingFeed·FollowingFeed다.
• home-mixer/models/candidate.rs — 2026-09-02, PostCandidate.backbone_scores: Option<PhoenixScores> 필드를 새로 만들었다.
• home-mixer/models/query.rs — 2026-09-02, ScoredPostsQuery.return_backbone_scores: bool 필드를 새로 만들었다(기본 false).
• home-mixer/scorers/phoenix_scorer.rs — 2026-09-02, predictions.candidate_backbone_scores()를 소비한다.
• home-mixer/util/phoenix_request.rs — 2026-09-02, return_backbone_scores 필드를 request context에서 proto로 넘긴다.
• phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto — 2026-09-02, proto 필드가 들어 있다.
  • PredictNextActionsRequest.returnBackboneScores = 20, NextActionDistribution.backboneTopLogProbs = 10, .backboneContinuousValues = 11
• home-mixer/params/param.rs — 2026-09-02, PhoenixRetrievalAggregationType default가 DENSE_WITH_SHORT_DWELL → DENSE_WITH_LONG_DWELL로 바뀌었다. 헤더의 sync 시각은 2026-09-02T16:03:45Z다.
• phoenix/crates/serving/xai-recsys-engine/src/python.rs — 2026-09-02, candidate/search-query embedding에 zero-fill 방어와 copy_len > 0 조건을 넣었다.
• scarecrow/legacy/XReviewIntakeRegistry.scala — 2026-09-02, 179줄 신규. CreateXReviewReportProd/Staging 함수 유닛과 mTLS 클라이언트 프로바이더가 들어 있다.
• scarecrow/legacy/XReviewReportBuilder.scala — 2026-09-02, 59줄 신규. SubmitReportRequest 페이로드 스키마가 들어 있다.
  • 필드는 report_source="proactive", subject="Botmaker report", reporter_id="0", detection_bot_id, detection_timestamp_ms다.
  • entityType 화이트리스트는 "post"/"profile"이다.
• scarecrow/legacy/XReviewReportSubmitter.scala — 2026-09-02, 91줄 신규. prod/staging 이중 클라이언트, 5종 카운터, noop 폴백이 들어 있다.
• scarecrow/legacy/DownstreamServices.scala — 2026-09-02, XReviewIntake를 DownstreamService로 등록했다.
• visibility-filtering/rules/registry.rs — 2026-09-02, Policy struct와 세 static 정책이 들어 있다. Policies는 RuleEngine으로 이름을 바꿨다.
  • 세 정책은 FILTER_ALL_POLICY·TIMELINE_HOME_POLICY·TIMELINE_HOME_RECOMMENDATIONS_POLICY다.
• visibility-filtering/rules/mod.rs — 2026-09-02, Rule trait과 evaluate_rules 함수를 전부 지웠다(−155줄).
• visibility-filtering/rules/tweet_rules.rs — 2026-09-02, 새 테스트 wired_rule_names_are_unique_and_nonempty를 추가했다. 15개 rule slice 이름이 유일한지 검증한다.
• phoenix/python/training/xai-checkpointing/xai_checkpointing/dek.py — 2026-09-02, +91/−2. adopt_tree_dek(사이드카 또는 in-envelope 폴백)와 _header_wrapped_master가 들어 있다. 뒤의 함수는 4096바이트 envelope 헤더, magic XAIENC01, xai-dek1:<salt>:<master> 파생 형태를 쓴다. rank_logger 관측도 확장했다.
• phoenix/python/training/xai-checkpointing/xai_checkpointing/load.py — 2026-09-02, reader가 xai_encrypted tensorstore 드라이버를 직접 쓴다. KMS-proxy KvStore를 없애고, DEK를 한 번 unwrap한 뒤 로컬에서 대칭 복호화한다.
• phoenix/python/training/xai-checkpointing/xai_checkpointing/orbax_encrypted.py — 2026-09-02, decrypt_read와 wait_until_finished를 추가했다.
• phoenix/xrex/train/checkpoint_write.py — 2026-09-02, encryption_context에 domain·run이 필수가 됐고, mint_nonce = sha256(path)를 자동으로 넣는다. downgrade 방지 메시지도 구체화했다.
• phoenix/xrex/train/trainer.py — 2026-09-02, _uses_tensorstore_save가 더 이상 encrypt와 결합되지 않는다.
• phoenix/xrex/utils/checkpointing.py — 2026-09-02, _AsyncCheckpointer는 orbax_encrypted.wait_until_finished()까지 기다린다. save_checkpoint는 kms_client/encryption_chunk_size 인자를 받는다.
• phoenix/xrex/configs/xrecsys_two_tower.py — 2026-09-02, qk_norm: False → True, attn_logit_cap: 80.0 → -1로 바꿨다.
• visibility-filtering/rules/context.rs — 2026-08-28, 214줄. RuleContext에 도메인 메서드 25여 개를 새로 만들었다.
• visibility-filtering/rules/golden_corpus.rs — 2026-08-28, 1039줄 신규. 13개 카테고리 90건의 회귀 코퍼스와 every_wired_rule_decides_a_corpus_case 어설션이 들어 있다.
• visibility-filtering/rules/fixtures.rs — 2026-08-28, 116줄 신규(#[cfg(test)]). CandidateBuilder와 뷰어 헬퍼가 들어 있다.
• visibility-filtering/rules/registry.rs — 2026-08-28, +49/−298. wired_rule_names(level) 헬퍼를 새로 만들고, 개별 rule 테스트를 옮겼다.
• home-mixer/params/param.rs — 2026-08-28, RerankerHeadTag 파라미터를 새로 만들었다(기본 0).
• phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto — 2026-08-28, ScoreInfo.rerankerHeadTag = 6과 UserActionSequence.rerankerHeadTag = 9가 들어 있다.
• phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs — 2026-08-28, +79/−12. gRPC 수신 → 목적지 복사 경로를 spawn_blocking으로 분리했고, JoinOnDrop<T>가 들어 있다.
• phoenix/crates/serving/xai-recsys-engine/src/copy_port_client.rs — 2026-08-28, +16/−15. join_transfers 헬퍼로 관용구 중복을 없앴다.
• phoenix/crates/serving/xai-recsys-engine/src/proto_parser.rs — 2026-08-28, +11. Bytes 콜백 타입을 새로 만들었다.
• home-mixer/ads/multi_risk_blender.rs — 2026-08-28, 332줄. MultiRiskAdsBlender를 새로 만들었다. 구조는 광고 tier × 포스트 tier 인접성 매트릭스다.
• home-mixer/ads/tests/multi_risk_blender_tests.rs — 2026-08-28, 215줄. 인접성 매트릭스 회귀 테스트다.
• home-mixer/selectors/blender_selector.rs — 2026-08-28, AdsBlenderType param에 "multi_risk"·"partition_organic_low_risk" 앨리어스를 연결했다.
• visibility-filtering/safety_label_source/warmer.rs — 2026-08-28, 203줄 신규. SampledWarmer와 StratoWarmFetcher가 들어 있다.
• visibility-filtering/safety_label_source/lookup.rs — 2026-08-28, +84. RemoteSource::with_warmer가 들어 있고, Miss-only warm 조건을 연결했다.
• visibility-filtering/config.rs — 2026-08-28, VF_CACHE_WARM_SAMPLE_PCT·VF_GIZMODUCK_CLIENT_ID·VF_TWEMCACHE_CLIENT_NAME·APP_ENV env 4개를 새로 만들었다.
• phoenix/xrex/train/trainer.py — 2026-08-28, +102/−31. restore_streamed를 실제로 소비하도록 연결했고, _graft_replaced 콜백이 들어 있다.
• phoenix/python/training/xai-checkpointing/xai_checkpointing/load.py — 2026-08-28, load_checkpoint_streamed의 인자를 window_gb·window_cap_gb·on_replaced로 확장했다.
• phoenix/crates/serving/xai-recsys-engine/src/grpc_compression.rs — 2026-08-28, +109/−13. gRPC trailer 보존 버그를 고쳤고, recsys_engine_response_compress_ms 히스토그램을 넣었다.
• phoenix/crates/serving/xai-recsys-engine/src/copy_port_client.rs — 2026-08-28, +113/−10. shuffle_sharded_schedule과 restore_piece_order가 들어 있다(peer-load 균등화).
• phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs — 2026-08-28, shuffle_sharded_schedule을 소비한다.
• home-mixer/util/strato_context.rs — 2026-08-28, 75줄 신규. StratoContext.is_polling proto 필드를 추출한다.
• home-mixer/side_effects/response_stats_side_effect.rs — 2026-08-28, <feed>.request.polling|request_context|client 3종 카운터가 들어 있다.
• grox/flows/reply_spam/task_write.py — 2026-08-28, 비교 연산자를 > → >=로 바꾸고, 저장 순서를 Kafka-first로 했다. try/except는 없앴다.
• grox/flows/reply_spam/classifier_coordinated_spam.py — 2026-08-28, PostRenderer.render(..., include_follower_count=True)를 상시 활성화했다.
• abuse-enforcement-service/service-lib/src/service.rs — 2026-08-28, +58. AIS thrift 스키마 conformance 테스트를 새로 만들었다.
• home-mixer/filters/viewer_muted_keyword_filter.rs — 2026-08-28, +18. CJK whole-token matching 회귀 테스트를 새로 만들었다.
• home-mixer/filters/brazil_2026_election_filter.rs — 2026-08-28, 계정 리스트 주석을 다시 정리했다. 필터 시맨틱은 그대로다.
• simclusters/simclusters_v2/scalding/embedding/EntityToSimClustersEmbeddingsJob.scala — 2026-08-28, SimClustersInterestedIn2020 스냅샷 폴백 경로를 인라이닝했다.
• README.md #latest-updates — 2026-08-21 기준 최신이다. README 자체는 4세대+4·+5·+6에서 갱신되지 않았다. 4세대+1의 August 14th 항목이 여전히 최신 게시다.
• phoenix/xrex/utils/checkpointing.py — 2026-08-26, +215/−6. ThrottledD2HArrayHandler, _NodeBatchLock(save), save_concurrent_gb 인자를 새로 만들었다.
• phoenix/python/training/xai-checkpointing/xai_checkpointing/load.py — 2026-08-26, +311/−88. load_checkpoint_streamed를 새로 만들었다. auto-window와 on_replaced 콜백이 들어 있고, 헬퍼도 리팩터했다.
• phoenix/xrex/train/trainer.py — 2026-08-26, warm_start_staging_spec 훅과 RecsysTrainer.keep_emb_opt_state 옵션이 들어 있다.
• phoenix/xrex/train/trainer_recsys.py — 2026-08-26, keep_step = valid_step & emb_valid_step로 lock-step gating을 한다(+29/−19). grad_norm_keep_threshold is None assert는 없앴다.
• phoenix/xrex/models/recsys_two_tower_model.py — 2026-08-26, use_history_segment_ids config 플래그와 user_tower_segment_ids 유틸이 들어 있다.
• phoenix/crates/serving/xai-recsys-engine/src/admission.rs, request_metrics.rs — 2026-08-26, admission reset_estimates는 EWMA zero 처리와 Prometheus gauge 동기화를 한다.
• phoenix/crates/serving/xai-recsys-engine/src/copy_port_client.rs — 2026-08-26, dense·emb_table load 로그에 총 바이트와 GB/s를 함께 적는다.
• phoenix/python/common/xai-proto/proto/recsys.proto — 2026-08-26, ActionName 191 ADS_PIXEL_FIRE / 192 ADS_LONG_DWELL_AND_PIXEL_FIRE / 193 P_LONG_DWELL_AND_PIXEL_FIRE가 들어 있다. ConvAssetIds message, PredictNextActionsRequest.conv_asset_ids = 18, SlateContext.reconCosMilli = 13도 있다.
• home-mixer/models/candidate.rs — 2026-08-26, SlateContext.recon_count_above와 recon_gap_above, 두 Option<u32> 필드가 들어 있다.
• grox/core/lm/post.py, grox/core/lm/thread.py — 2026-08-26, PostRenderer/ThreadRenderer에 include_follower_count·include_bio 옵션과 # Reply Author Info 헤더가 들어 있다.
• grox/flows/reply_spam/task_write.py — 2026-08-26, Manhattan write를 monotone-only로 했다(higher_than_existing 건너뛰기).
• visibility-filtering/hydration/tes_hydrator.rs, config.rs, server_deps.rs, hydration/mod.rs — 2026-08-26, 총 −323. TesHydrator media fallback cache와 env 플래그 두 개를 전부 지웠다.
• visibility-filtering/dark_traffic_setup.rs — 2026-08-26, should_mirror를 canary opt-out과 missing workload fail-closed로 확장했다.
• phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto — 2026-08-21, ActionName 171–190에 광고 conversion 20개를 새로 만들고, NextActionDistribution.slateContext = 9 필드를 추가했다.
• phoenix/xrex/data/recsys/constants.py — 2026-08-21, MACT_IN_APP_LOSS_ACTION_INDICES·VIEW_THROUGH_ACTION_INDICES·SOURCE_SPLIT_CONVERSION_HEAD_INDICES·ads_slim_engagement_to_action_types를 새로 만들었다.
• phoenix/xrex/models/recsys_model.py — 2026-08-21, split_head_training_by_source·train_view_through_heads·mact_in_app_loss_weight·conversion_keep_mask와 delayed feedback loss mask 분기가 들어 있다.
• phoenix/xrex/data/recsys/recsys_batch.py — 2026-08-21, sample_source(is_delayed_feedback)를 연결했다. conversion_keep_mask(conversionKeepMask)도 연결했다.
• phoenix/TRAINING.md — 2026-08-21, Muon flagship과 nano 학습을 정식 문서로 정리했다.
• phoenix/xrex/configs/xrecsys.py — 2026-08-21, _home_direct_packed_nano가 4세대 공개부터 있던 _GB300_OVERRIDES의 LR·optimizer 설정을 상속.
• phoenix/crates/storage/xai-o2/ — 2026-08-21, BaseO2Client trait과 O2ClientBuilder (154줄 신규, 구현 미공개).
• grox/flows/reply_spam/task_filter.py — 2026-08-21, follower 임계 60k → 80k.
• visibility-filtering/dark_traffic_setup.rs — 2026-08-21, dark_traffic 타깃 shadow → staging 전환.
• grox/flows/ptos/classifier.py — 2026-08-21, Grok 4.5 internal 완전 제거·4.6 internal 100% 전환.
• phoenix/xrex/train/trainer_recsys.py — 2026-08-21, retrieval post-embedding 65k row 청킹.
• phoenix/xrex/inference/model_runner.py — 2026-08-21, _glibc_malloc_trim()·_malloc_trim_after_swap() 신설 (hotswap ~196MiB/cycle 누수 수정).
• phoenix/xrex/configs/xrecsys_two_tower.py — 2026-08-21, qk_norm=True·attn_logit_cap=-1·right_anchored_rope=True 옵션 3개 추가.
• phoenix/xrex/data/retrieval_dataset.py — 2026-08-21, EVERGREEN 파일을 evergreen_video_1825day에서 video_4to14day로 축소.
• home-mixer/candidate_hydrators/ai_trend_feedback_context_hydrator.rs — 2026-08-20, AI trend feedback context 신규 (157줄).
• home-mixer/util/urt/post_marshaller.rs — 2026-08-20, topic feedback / AI trend 폴백 렌더.
• home-mixer/models/candidate.rs — 2026-08-20, served_slate_context·ai_trend_name/ai_trend_id 필드, From<xai_recsys_proto::SlateContext> 변환 impl.
• home-mixer/scorers/phoenix_scorer.rs — 2026-08-20, candidate_slate_context()를 뽑아 쓰도록 연결.
• home-mixer/scorers/ranking_scorer.rs — 2026-08-20, served_slate_contexts()와 3갈래 폴백.
• home-mixer/params/param.rs — 2026-08-20, UseServedSlateContext·EnableAiTrendFeedbackContext 신규 param.
• phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs — 2026-08-20, load_tensor_into core 분리 (+189/−169).
• grox/flows/ptos/classifier.py — 2026-08-20, Grok 4.6 dial 0.1 → 0.3.
• grox/libs/grok_sampler/llm.py — 2026-08-20, stop_predicate·aclosing 도입.
• grox/core/data_loaders/data_types.py — 2026-08-20, User.profile_image 필드 신설.
• phoenix/xrex/optimizers/recsys/muon.py — 2026-08-19, Muon optimizer 신규 (240줄, optax.contrib._muon 감쌈).
• phoenix/xrex/optimizers/recsys/dense_optim.py — 2026-08-19, RecsysDenseOptimConfig로 Muon config 노출.
• phoenix/xrex/configs/xrecsys.py — 2026-08-19, _home_direct_packed_base() Muon 승격, xrecsys_search config 신설.
• phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto — 2026-08-19, RewardOutputs, rewardRerankSlotProb, link-open P10-P90, SlateContext.sid* 필드.
• home-mixer/filters/following_viewer_muted_keyword_filter.rs — 2026-08-19, Following 파이프라인 전용 muted-keyword 필터 (65줄).
• home-mixer/candidate_hydrators/quoted_post_text_hydrator.rs — 2026-08-19, quoted post text hydrator 신규 (106줄).
• grox/flows/ptos/classifier.py — 2026-08-19, Grok 4.6 internal 10% dial 도입.
• grox/flows/ptos/prior_nsfw.py — 2026-08-19, Manhattan lookup 캐시 신규 (34줄).
• visibility-filtering/dark_traffic_setup.rs — 2026-08-19, xai-vf-shadow로 보내는 미러링 연결 (109줄).
• home-mixer/models/brand_safety.rs — 2026-08-18, strip_v1_grok_written 제거, V2_WRITTEN_LABELS 게이트 재설계, v2_defers_to_v1_when_v2_has_not_ruled 테스트.
• home-mixer/candidate_hydrators/vf_following_candidate_hydrator.rs — 2026-08-18, Following 파이프라인 전용 VF 하이드레이터 신규 (95줄).
• home-mixer/scorers/vm_ranker.rs — 2026-08-18, VMRanker 요청 시그니처에 SID 필드 7개를 추가로 연결.
• phoenix-rankall-strato/stream_forwarders/postCreationEventForwarder.strato — 2026-08-18, Phoenix 이벤트 스트림 v3 마이그레이션, Kafka 클러스터 이동, KeyValue 매핑.
• grox/flows/reply_spam/generators.py — 2026-08-18, PostStreamTaskGenerator 삭제, ReplyRankingTaskGenerator가 spam plan을 흡수.
• grox/flows/reply_spam/task_filter.py — 2026-08-18, follower 임계 40k → 60k.
• home-mixer/models/brand_safety.rs — 2026-08-17, 광고 브랜드 안전 V2 판정 함수·라벨 세트·strip_v1_grok_written 헬퍼·v2_mirrors_v1_across_tier_matrix 검증 테스트 (하루 만에 재설계됨).
• grox/flows/ptos/task_safety_ptos_adult_content_cross_validation.py — 2026-08-17, safemodel↔PtOS disagreement 때 Grok 4.5 심판을 호출해 강등 판정.
• grox/flows/ptos/classifier.py — 2026-08-17, SafetyPtosAdultContentCrossValidationJudge 클래스 신설, EAPI_GROK_4_5_X_ALGO 전용 서킷브레이커.
• phoenix-rankall-strato/columns/phoenix_rank_all/phoenixRankAllCandidateProcessor.strato — 2026-08-17, build1FavIndex·buildMMEmbMetadataDump에서 favoriteCount>=1 게이트 제거, 1fav_uec_count_race 카운터 신설.
• home-mixer/filters/brazil_2026_election_filter.rs — 2026-08-14, 브라질 선거법원 조치 계정 665개를 하드코딩하고 팔로잉 예외를 둔 필터.
• 브라질 선거법원 candidatos-2026 데이터셋 — Brazil2026ElectionFilter가 참조하는 규제 근거.
• @XBR 공지 — 2026-08-14, X의 Brazil 2026 필터 공지 (README에서 인용).
• bdsm/runtime/score_results_sink_focal.py — 2026-08-14, enforcement note 생성기 부분 공개.
• home-mixer/params/param.rs — 2026-08-13, 프로덕션 크론 미러 (헤더 sync 시각 2026-08-12T04:09:22Z).
• visibility-filtering/rules/registry.rs — 2026-08-13, 3-tier 정책, 규칙 54개.
• docs/BIDIRECTIONAL_BOOST_CHANGE.md — 2026-08-13, 파라미터 diff 문서화 견본 (2026-07 상호팔로우 부스트 도입·조정).
• x.com/i/under_the_hood — 2026-08-13, 계정 단위 라벨 투명성 툴 파일럿.
• twitter/the-algorithm — 2023 초판(ef4c5eb) 및 2025-09-03 리프레시(c54bec0), 공개 소스코드.
• twitter/the-algorithm-ml — 2023, 공개 소스코드. projects/home/recap/README.md가 유일한 수치 가중치 출처(2023-04-05 기준).
• Twitter Engineering, "Twitter's Recommendation Algorithm" — 2023, 공식 블로그. 모델 가중치·학습데이터 미공개를 명시.

↑ 목차

변경 이력 (커밋별 상세)

4세대 공개 뒤에 나온 X 공개 저장소의 커밋마다 무엇이 바뀌었는지를 날짜순으로 남긴 기록이다. X For You의 현재 동작은 앞쪽 주제 절이 설명하고, 이 기록은 각 변화가 어느 커밋에서 들어왔는지를 보여 준다.

커밋 요약표