2026-09-24

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

• 같은 커밋에서 X의 노출 판정 서비스는 답글 제한 규칙 4개와 역방향 팔로우 조회를 넣어, 어제 예약된 답글 제한 슬롯을 완성했다.
• 같은 커밋은 영상 안전 판정에 쓸 대표 프레임(key frame)을 장면 전환 기준으로 뽑는 파이프라인도 넣었다.
• Spotify의 LLM reranker 학습법 논문이 온라인 A/B 결과와 함께 레이더 기준을 통과했다.

1VM-Ranker 서비스가 value model 계산을 맡게 됐다 — X

• 첫째, 홈믹서의 VMRanker 스코어러가 score-only DPP wrapper에서 벗어나 후보, 유저 컨텍스트, PhoenixScores 26필드까지 실어 보내는 두 파라미터를 얻었다. 하지만 수신 측에서 실제로 무엇을 어떻게 계산할지는 아직 코드가 없었다.
  • 두 파라미터는 VMRankerSendValueModelInputs와 VMRankerComputeValueModel이다.
• 둘째, VF(visibility-filtering, 포스트마다 '이 뷰어에게 보여도 되는가'를 판정하는 서비스)의 verdict 트리에 새 슬롯 두 개가 예약됐다. 하지만 아무 rule도 이 슬롯을 채우지 않는 상태(#[expect(dead_code)])였다.
  • 두 슬롯은 TombstoneReason::LocalRegulations와 LimitedEngagementReason::ConversationControl이다.
• 셋째, grox(Grok 기반 nearline 분류기 서브레포)에는 성인 콘텐츠 판정에 필요한 프레임 샘플링 유틸이 아직 없었다.

이번 커밋(2026-09-23, 1b3fec20, 4세대+27)은 이 세 슬롯을 실제 코드로 채운다.

A. VM-Ranker 서비스가 value model을 직접 계산하기 시작했다(신규 파일 4개, 파라미터 56개)

• VM-Ranker의 value model 계산은 별도 모델 서버를 부르지 않는 순수 Rust 코드다 확인.
  • 계산은 vm-ranker 서비스의 vm-ranker/scoring/value_model.rs(신규 191줄)가 맡는다. 이 파일은 shared crate의 xai_value_model::compute_value_scores()를 인라인으로 호출한다.
  • 입력은 세 가지다.
    • ValueModelWeights: 38개 행동-가중치 파라미터
    • QueryScoringContext: 유저 cohort별 OON(out-of-network, 팔로우하지 않는 계정의 글) 배수
    • CandidateScoringInputs: 후보별 Phoenix 참여 확률
  • 출력은 두 벡터다. scores는 최종 정렬용이고, weighted는 DPP 조정 전 가중합이다.
• 가중치가 프로덕션 값과 함께 공개됐다 확인 — vm-ranker/params.rs.
  • 신규 파일이고, 211줄에 파라미터 56개가 들어 있다.
  • 핵심 게이팅 플래그 ComputeValueModel은 기본 false다. 아직 실험 단계라는 뜻이다.
  • 긍정 신호의 가중치는 FavoriteWeight=0.5, ReplyWeight=5.0, RetweetWeight=1.0, QuoteWeight=5.0, ShareWeight=2.0, FollowAuthorWeight=4.0, ClickWeight=0.4, VideoOpenWeight=0.07, PhotoExpandWeight=0.05다.
  • 부정 신호의 가중치는 NotInterestedWeight=-43.2, BlockAuthorWeight=-31.2, MuteAuthorWeight=-58.8, ReportWeight=-234.0이다.
  • DPP 설정은 DppEnabled=true, DppTheta=0.65, DppMaxSelectedRank=150이다.
  • OON 배수는 OonWeightFactor=0.75, TopicOonWeightFactor=0.5, NewUserOonWeightFactor=0.00001이다.
• 작성자 다양성 파라미터가 VM-Ranker에도 노출됐다 확인. VM-Ranker 프로세스는 홈믹서 param 미러와 별도로 이 값을 자체적으로 읽어 쓴다.
  • 파라미터는 EnableAuthorDiversity=true, AuthorDiversityDecay=0.5, AuthorDiversityFloor=0.25다.
  • 홈믹서 param 미러 쪽 값의 예는 AuthorSoftmaxOutputDecayFactor=0.5다.
• 파라미터는 git remote를 폴링해 프로세스 재시작 없이 갱신된다(hot-reload) 확인 — vm-ranker/config_sync.rs.
  • 신규 파일(235줄)의 ConfigSync 태스크가 30초 주기로 sparse-clone된 git remote를 git fetch → reset으로 폴링한다. 주기 설정은 config_sync_interval_secs이고, 기본값은 30이다.
  • 폴링으로 갱신하는 파일은 features/home-mixer/main/rust_home_mixer.yml과 abdecider/abdecider.yml이다.
  • FeatureSwitches는 다음 match_recipient() 호출부터 새 값을 읽는다.
  • 진행 중인 요청 안에서는 값이 바뀌지 않는다(immutable).
• fallback 로직이 명시적으로 들어갔다 확인. 아래 세 조건 가운데 하나에라도 걸리면 상위 스코어(홈믹서가 넘긴 weighted sum)를 그대로 반환하고, 스로틀된 warning 로그를 남긴다.
  • 세 조건은 params 미해결, viewer context 결측, ComputeValueModel=false다.
  • 이 로직은 compute_or_fallback(vm-ranker/scoring/value_model.rs:108 부근)이다.
  • 관측 지점은 메트릭 세 개다.
    • vm_ranker_value_model_requests_total{mode=passthrough|value_model|fallback}
    • vm_ranker_value_model_fallback_total{reason=...}
    • vm_ranker_value_model_stage_total{stage=heads|cached_weighted}
• 캐시된 후보의 재계산을 건너뛰는 경로가 새로 생겼다 확인.
  • 홈믹서 신규 param CachedPostsReuseWeightedScore(기본 false)가 true이면, 캐시된 후보의 weighted_score를 그대로 재사용하고 head 재계산을 건너뛴다.
  • 게이팅 함수 RankingScorer::reuses_cached_weighted_score()와, 오프셋 변환을 역산하는 헬퍼 unoffset_score()가 home-mixer/scorers/ranking_scorer.rs에 새로 생겼다.
• debias 페이로드를 보내는 채널이 새로 생겼다 확인 — home-mixer/scorers/vm_ranker_debias_payload.rs.
  • 신규 파일(52줄)이다. 홈믹서 신규 param VMRankerSendDebiasInputs(기본 false)가 true이면, 후보별 콘텐츠 피처와 요청 컨텍스트를 experiment_payload proto 필드에 실어 보낸다.
  • 콘텐츠 피처는 has_video, max_video_duration_ms, has_photo, media_count, weighted_text_len, newline_count, has_url과, quoted tweet의 같은 피처다.
  • 요청 컨텍스트는 engine_time_hint_ms, columnar user-sequence ArrowIPC bytes, product surface, client_app_id다.
  • 이름은 debias이지만 코드만으로는 무엇을 debias하는지 알 수 없고, 실험용 페이로드 예약 슬롯일 가능성이 크다 추정.
• 홈믹서 쪽 vm_ranker 스코어러는 얇아졌다 확인 — home-mixer/scorers/vm_ranker.rs.
  • 기존 파일에서 15줄이 추가되고 31줄이 삭제됐다.
  • 4개 모드를 고르던 인라인 branching이 신규 struct OptionalInputs { value_model, compute_value_model, cached_weighted_score, debias }로 캡슐화됐다. OptionalInputs::from_query()가 홈믹서 param을 읽어 4개 플래그를 정한다.
  • write_request()/write_candidate()는 헬퍼로 분기한다.
  • 스코어 응답도 (tweet_id → score)에서 (tweet_id → (score, weighted_score)) 튜플로 넓어졌고, 이 값이 candidate.weighted_score에 실린다.

B. VF가 어제 예약된 답글 제한 슬롯을 규칙 4개로 채웠다

• conversation control(작성자가 답글을 달 수 있는 사람을 제한하는 설정)을 판정하는 rule 4종이 새로 생겼다 확인 — visibility-filtering/rules/tweet_rules.rs:328-383.
  • 네 rule은 LIMIT_REPLIES_CONVERSATION_RULES에 묶여 있다.
  • LimitRepliesByInvitationConversationRule(:338-346)의 결과는 LimitedEngagementReason::ConversationControl이다. 조건은 HasConversationControl(ByInvitation) AND NOT_LOGGED_OUT AND NOT_RETWEET AND NOT_CONVERSATION_ROOT_AUTHOR AND NOT_INVITED_TO_CONVERSATION이다.
  • LimitRepliesCommunityConversationRule(:347-359)은 같은 베이스에 NOT ViewerIsFollowedByConversationRootAuthor를 더한다.
  • LimitRepliesSubscribersConversationRule(:360-372)은 같은 베이스에 NOT ViewerSuperFollowsConversationRootAuthor를 더한다.
  • LimitRepliesVerifiedConversationRule(:373-382)의 조건은 HasConversationControl(Verified) AND ... AND NOT ViewerHasVerifiedBadge다.
  • LimitedEngagementReason::ConversationControl 슬롯은 어제 예약된 그대로 이 4개 rule에서 채워진다.
• 새 hydrator(판정 전에 필요한 데이터를 채워 넣는 단계)가 TES와 socialgraph 양쪽에서 데이터를 가져온다 확인 — visibility-filtering/hydration/conversation_control_hydrator.rs.
  • 신규 파일(310줄)이고, 흐름은 세 단계다.
    1. TES(Tweet Entity Service, X 내부의 트윗 메타데이터 서비스)의 get_conversation_controls()가 arm, root author, invited user IDs를 반환한다.
    2. arm이 Community이면 socialgraph batch_check_followed_by(viewer_id, root_authors)로 root 저자가 viewer를 팔로우하는지(역방향 엣지) 확인한다.
    3. arm이 Subscribers이면 socialgraph batch_check_super_follows(viewer_id, root_authors)로 viewer가 root 저자를 super-follow하는지 확인한다.
  • 결과는 신규 타입 ConversationControlFeatures { control, root_author_follows_viewer: Option<bool>, viewer_super_follows_root_author: Option<bool> }에 담긴다. 이 타입은 visibility-filtering/models/conversation_control.rs에 있다.
• socialgraph client가 역방향 엣지(reverse-edge) 조회를 얻었다 확인 — visibility-filtering/clients/socialgraph_client.rs.
  • 변경 규모는 +130/−67이고, 신규 메서드 batch_check_followed_by(viewer_id, user_ids)가 붙었다.
  • 이 메서드는 FlockDB 500-ID 청크 페이지네이션으로 FOLLOWS_GRAPH의 역방향 엣지를 조회하고, membership dict로 반환한다.
  • edge_membership_query() 시그니처는 direction: EdgeDirection을 받도록 일반화됐다.
• 로그인한 뷰어를 나타내는 값이 이제 프로필을 함께 싣는다 확인 — visibility-filtering/models/viewer.rs.
  • Viewer::LoggedIn이 프로필을 인라인으로 실어 나른다. Viewer::LoggedIn(u64)가 Viewer::LoggedIn { id, profile: ViewerProfile }로 확장됐다.
  • ViewerProfile에는 allows_sensitive_media·viewer_age·has_verified_badge·account_country_code 4필드가 들어간다.
  • has_verified_badge는 Gizmoduck(X의 유저 정보 서비스)의 VerifiedType::Business/Government이거나 is_blue_verified일 때 true다. 앞에서 본 LimitRepliesVerifiedConversationRule이 이 값을 소비한다.
• hydration이 lazy 방식으로 재편됐고, 이것이 이번 리팩터의 핵심이다 확인 — visibility-filtering/hydration/mod.rs. 결과적으로 hydration 지연이 각 지면에서 실제로 참조되는 rule 집합에만 좌우된다.
  • 변경 규모는 +360/−77이다. 신규 enum Hydrator와 bitset Hydrators(u8)가 도입됐다.
  • 이 enum의 variant는 ViewerProfile, TweetSafetyLabels, Tweet, ExclusiveContent, Author, Relationship, ConversationControl 7개다.
  • 각 predicate는 const fn hydrators()로 자신에게 필요한 hydrator를 선언한다. RuleClause::hydrators()는 절 안의 모든 predicate를 합집합(union)해 hydrator 요구 집합을 정한다.
  • RuleEngine::hydrators_for(safety_level)는 active policy가 요구하는 hydrator만 실행한다.
  • 예를 들어 TweetPredicate::HasConversationControl(_)는 Hydrator::ConversationControl을 요구한다. 이 hydrator는 SafetyLevel(지면별 정책 묶음)이 이 predicate를 참조하는 rule을 켤 때만 돈다.
• TES 하이드레이션 코드의 대량 삭제는 방향 전환의 반작용이다 확인.
  • 삭제 규모는 tes_hydrator.rs -333, models/mod.rs -223이다.
  • 11필드는 2026-09-18 커밋(4세대+25, 8b25829)에서 Strato(코드가 데이터를 조회하거나 저장할 때 거치는 X 내부 시스템) 컬럼 TweetForVisibility로 이관된 것이다.
  • 그 뒤로 TES는 순수 PureCoreData(author_id·text·source_tweet_id)만 담당한다.
  • 오늘 커밋에서는 PureCoreHydration 래퍼 struct와 캐시-recovery 로직이 모두 제거됐다.
  • fetch_pure_core() → fetch_author_ids()로 이름이 바뀌면서 반환 타입이 TweetHydrationBatch<AuthorId>로 단순화됐다.
  • resolve_candidates()도 wrapper struct를 받지 않고 inline fallback으로 압축됐다.

C. grox 영상 안전 판정에 key frame을 뽑는 파이프라인이 생겼다

• PyAV와 OpenCV로 장면 전환(scene-cut)을 찾아 대표 프레임을 뽑는다 확인 — grox/libs/video_tools/key_frames.py.
  • 신규 파일(206줄)의 KeyFramesExtractor.extract_key_frames()가 이 일을 한다.
  • 프레임을 32×32 grayscale로 리사이즈해 정규화된 시그니처를 만든다. 인접 프레임의 L2 거리가 max(6.0, 4.0 × median_delta)를 넘으면 컷으로 판정한다.
  • shot마다 미드프레임 시그니처가 비디오 미디언에서 얼마나 떨어졌는지로 순위를 매긴다. stddev<8.0인 blank shot은 후순위다.
  • 상위 max_key_frames=3 프레임을 PTS 기준으로 정확히 디코딩한다.
  • 스캔 창은 window_sec=3, max_fps=15(default)다.
• key frame 추출은 PTOS(grox의 정책 위반 판정 스택) 안전 파이프라인에 새 태스크로 결합된다 확인 — grox/flows/ptos/plan_safety_ptos_key_frames.py.
  • 신규 파일(52줄)의 DAG는 rate limit → key frames filter → media hydration → adult-only init → policy detection → safemodel sex/nudity → adult content cross-validation → result sink다.
  • 필터(task_safety_ptos_key_frames_filter.py:26-83)를 통과하려면 비디오여야 하고 HIGH_FAV_THRESHOLD=128 이상이어야 한다. 그리고 기존 adult label이 있거나, fav가 KEY_FRAMES_UNCONDITIONAL_FAV=512 이상이어야 한다.
  • rate limit(60초 TTL, 10,000 엔트리 dedupe)으로 중복 처리를 억제한다.
• 미디어 스토리지가 blobstore에서 O2로 넘어간다 확인 — grox/core/data_loaders/media_reference_bundle.py.
  • 변경 규모는 +51/−18이다. 새 클래스 S3Store가 boto3로 O2 스토리지(https://o2-https.o2-prod.atla-prod-storage.cluster.kube.int-x.ai)를 감싼다.
  • s3://<bucket>/<prefix> URI 파싱이 기존 blobstore://namespace/subpath를 대체한다.
  • 4세대+6(2026-08-21)에는 phoenix/crates/storage/xai-o2/의 trait 인터페이스만 공개되고, 구현은 빌드에서 빠져 있었다. 그 백엔드가 grox 미디어 경로에서는 boto3 S3 프로토콜로 실제로 쓰인다.
• 미디어 로더에 key frame 경로가 옵션으로 열렸다 확인 — grox/core/data_loaders/media_loader.py.
  • 변경 규모는 +39이고, _construct_convo_video_from_key_frames()가 새로 생겼다.
  • config MediaHydrationConfig.use_key_frames(기본 False)를 켜면 원본 비디오 대신 key frame 3장으로 합성한 ConvoVideo를 반환한다.
  • 창 3초, 15fps, 최대 3프레임이 config로 노출된다.

D. Phoenix MoE의 cold-start 옵션이 바뀌었다

• Phoenix MoE(mixture of experts, 여러 전문가 서브네트워크 가운데 일부를 골라 쓰는 모델 구조)의 cold-start 파라미터 이름이 실험 이관 중이다 확인 — home-mixer/params/param.rs.
  • PhoenixMOEMaxResults와 PhoenixMoeColdStartMaxResults의 default 값 배치가 바뀌었다.
  • PhoenixRetrievalMOEInferenceClusterId는 다른 클러스터 상수로 회전됐다.
  • cold-start MoE 슬라이스의 실험을 돌리는 중에 파라미터를 갈아 끼우는 작업으로 보인다 추정.

pub compute_value_model: bool = false; pub weights: ValueModelWeights = ValueModelWeights { favorite: 0.5, reply: 5.0, retweet: 1.0, quote: 5.0, share: 2.0, follow_author: 4.0, click: 0.4, video_open: 0.07, photo_expand: 0.05, not_interested: -43.2, block_author: -31.2, mute_author: -58.8, report: -234.0 }; — 요약, vm-ranker/params.rs, 2026-09-23

1. 홈믹서 param.rs가 유일한 가중치 미러라는 서술은 부분적으로 갱신된다. 지금까지 x.md는 홈믹서 home-mixer/params/param.rs를 프로덕션 크론 미러(프로덕션 값을 매일 동기화해 공개하는 미러 파일)로 다뤘다. 오늘 vm-ranker/params.rs라는 두 번째 채널이 열렸다.
   • 홈믹서 미러는 홈믹서 프로세스가 소비하는 가중치이고, VM-Ranker 미러는 VM-Ranker 프로세스가 소비하는 별도 값이다. 둘의 관계는 아직 모호하다.
   • ComputeValueModel=false가 기본인 상황에서 VM-Ranker의 값은 shadow(관측·비교용)로만 도는 것으로 보인다 추정.
2. 홈믹서 랭킹이 "가중합 → 필터 → DPP → 광고 블렌드"라는 서술은 유지되지만, "vm-ranker가 score-only wrapper"라는 설명은 폐기된다. 이제 VM-Ranker가 세 모드 가운데 어느 것으로 돌지는 실행 시 결정된다.
   • 세 모드는 DPP 재정렬만 하는 모드, inputs 발송만 하는 모드, value model을 인라인으로 계산하는 모드다.
   • send_inputs 모드가 홈믹서에서 항상 켜져 있는지, compute_value_model이 실험군에서 언제 켜지는지는 커밋만으로는 알 수 없다.
3. VF verdict 트리의 예약 슬롯에 관한 서술은 정정된다. 어제 daily는 "LimitedEngagementReason::ConversationControl 슬롯은 wire만 있고 아직 rule 없음"이라고 기록했지만, 하루 만에 4종 rule이 이 슬롯을 채웠다. TombstoneReason::LocalRegulations는 여전히 예약 상태다.

심층 분석 필요 아래 4가지는 따로 조사해야 하므로, 사람이 시작하는 별도 세션에서 다룬다.

• vm-ranker/scoring/value_model.rs의 인라인 계산이 정확히 어떤 함수 형태인지(가중합의 aggregation, DPP 이전의 스코어 조합 규칙)
• xai_value_model crate가 이 저장소에 공개되어 있는지
• 홈믹서와 VM-Ranker의 가중치 이원화가 어떤 편집 워크플로로 동기화되는지
• SendDebiasInputs의 의도는 무엇인지

2arXiv 신규 5건 가운데 Spotify 논문 1건이 레이더 기준을 통과했다 — arXiv

어제 이후 새로 나온 arXiv cs.IR 논문 5건을 레이더 요건으로 훑었고, 1건이 통과했다. 오늘 받은 cs.IR 신규는 30건(파싱한 <entry> 개수 30, 2026-09-19~09-22 제출)이고, 이 가운데 어제 이후 신규는 2026-09-22 제출 5건이다. 요건은 플랫폼 기업 저자, 프로덕션 A/B 진술, 메커니즘·스케일 신규성의 세 가지다.

• Spotify가 개인화 검색용 LLM reranker의 과의존 문제를 줄이는 학습법을 온라인 A/B 결과와 함께 냈다 확인 — arXiv 2609.25825.
  • 논문 제목은 Robust Fusion of Semantic and Behavioural Signals for LLM Reranking in Personalised Search다(2026-09-22, USRW Workshop at RecSys 2026 accepted).
  • HTML 판에서 저자 7명 전원의 이메일 도메인이 @spotify.com임을 확인했다.
  • 문제는 개인화 검색의 LLM cross-encoder reranker에 Query Slice Stats(QSS, 쿼리-후보 쌍별 과거 성공률 요약)를 프롬프트로 넣을 때 생기는 shortcut learning이다. 모델이 QSS에 과도하게 의존해 rare/unseen 쿼리에 취약해진다.
  • 이를 완화하기 위해 deterministic dual-sample feature-dropout으로 학습한다. 각 예를 QSS를 넣어 1회, QSS를 빼고 1회, 모두 두 번 학습에 넣는다.
  • 오프라인에서는 QSS가 있을 때 랭킹 품질이 +13.3% 올랐고, QSS-removed 슬라이스에서는 naive QSS 대비 +4.0% 개선됐다.
  • 온라인 A/B에서는 QSS-aware 두 변형 모두 search success가 ≈+2%였다.
  • radar.md에 편입했다.

나머지 4건은 탈락했고, 관찰 대상도 아니다. 네 건 모두 학술 연구다.

• SpeakerMem-R1: 멀티파티 대화 메모리
• Discovery-Driven Table Integration: 데이터 통합
• Knowledge-as-Skill LLM Agents: 벤치마크
• ARAFA: 아랍어 fact-checking 데이터셋

산업 블로그 훑기는 월요일에만 하고, 오늘(목요일)은 대상이 아니다.

Meta engineering blog의 최신 글은 2026-09-21의 두 건(Rebalancer 오픈소스, Petal 해저 케이블)이다. 둘 다 인프라 글이므로 건너뛴다. Netflix Tech Blog의 최신 글은 2026-09-18의 "Leave the Class Path in the Rearview Mirror"(JVM 인프라)이고, 이것도 건너뛴다.

레이더

• Spotify Robust Fusion: QSS와 dual-sample dropout을 쓴 LLM reranker이고, 프로덕션 A/B를 거쳤다. 오프라인 +13.3%, 온라인 A/B search success ≈+2%다. USRW Workshop @ RecSys 2026에 채택됐다.

다음에 볼 것