2026-09-27

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

• 같은 X 커밋에서 노출 판정 서비스 VF(visibility-filtering)는 데이터 조회의 상태 관리 로직을 떼어 내고, 조회 함수 파일 두 개를 지웠다.
• 같은 커밋부터 Phoenix(X의 Grok 기반 트랜스포머 모델)의 Cold retrieval 후보는 작성자 cold-start 실험의 Treatment 팔에만 노출된다.
• 리서치 자동화 논문 AgentX-Model은 프로덕션 A/B 5건에서 acquisition +10-15%, ad spend +15-20%, watch time +0.3-0.8%를 보고했다.

1사람 검토자가 뒤집은 정지·라벨의 재적용을 막는 게이트가 생겼다 — X

• abuse-enforcement 쪽에서는 X 내부의 안전 조치 dispatcher인 abuse-enforcement-service(이하 AES)에 overturn-hold gate라는 새 프리체크 계층이 신설됐다.
  • 신설된 overturn_hold_gate 5,270줄은 overturn_hold.rs 한 파일로 등장한다.
  • 이 게이트는 사람 검토자가 이의제기 처리 중 뒤집은(overturned) 정지 또는 라벨을, 그 hold가 유효한 동안 다시 걸지 못하게 막는 마지막 문이다.
  • 계정을 정지했다가 유저 이의제기가 승인되어 풀렸는데도, 자동화된 후속 판정이 다시 정지를 걸어 버리는 재발을 막는 장치다.
• VF hydration 쪽에서는 어제 신설된 execute.rs(1,280줄)의 상태 관리 로직이 오늘 별도 파일 store.rs로 분리됐다.
  • 어제 재작성의 결과인 데이터 테이블과 스케줄러는 plan.rs, execute.rs, sources.rs로 이루어져 있었다.
  • store.rs는 339줄짜리 신규 파일이다.
  • safety_label_hydrator.rs(167줄)와 tes_hydrator.rs(79줄)는 파일 전체가 삭제됐다.
  • 어제까지 남아 있던 함수 기반 잔재가 모두 제거되고, 스케줄러가 데이터 테이블만 참조한다.

• 이 게이트는 정지나 게이트 대상 라벨을 dispatch하기 전의 마지막 프리체크다 확인. 파일 상단 주석이 목적을 한 문장으로 밝힌다. 사람 검토자가 이의제기에서 이미 뒤집은 조치를 다시 적용하지 않으려고 둔다는 것이다.

  "Overturn-hold gate: the last precheck before a suspend (or a gated label) is dispatched. It exists so we do not re-apply an enforcement that a human reviewer already overturned on appeal." — abuse-enforcement-service/service-lib/src/overturn_hold.rs

• 게이트는 Off, Shadow, Enforce 세 모드로 동작하고, 기본값은 Off다 확인.

  • 모드는 GateMode::Off | Shadow | Enforce로 정의된다.
  • Shadow는 판정 라인을 실행하되 실제 조치는 하지 않고, metric과 decision outcome에만 기록한다.
  • Enforce는 실제 dispatch를 막는다.

• gate 종류는 정지 재적용 차단과 라벨 재적용 차단 두 가지다 확인.

  • 각각 GateKind::Suspend와 GateKind::Label이다.
  • 두 종류는 HOLD_KIND_SUSPEND="suspend", HOLD_KIND_LABEL="label" 상수와 대응한다.

• 정지는 임시 정지와 영구 정지로 나뉘고, 정지 종류마다 별도 판정이 흐른다 확인.

  • 임시 정지는 GatedAction::Suspend, 영구 정지는 GatedAction::PermSuspend다.

• 게이트는 원격 ledger 서비스에서 활성 hold 목록을 받는다 확인.

  • HTTP 클라이언트가 ledger 서비스의 /v1/holds/lookup 경로에 접근한다.
  • connect timeout은 200ms다.
  • positive cache는 60초이고, 최대 3,600초까지 튜닝할 수 있다.
  • 응답 본문 상한은 64 KiB다.
  • moka 캐시의 최대 weight는 100,000, config publish 주기는 15초다.

• 회로 차단기(circuit breaker)는 연속 실패 5회에서 열리고, 10초간 요청을 차단한다 확인.

  • 재시도는 half-open으로 한 요청씩 시험 통과하는 방식이다.
  • 이와 별도로, 도달 가능한 에러(예: HTTP 5xx)가 연속 5회 나면 5초 back-off로 완화한다.

• 게이트는 lib.rs의 두 지점에서 통합된다 확인.

  • 시작 시 HoldGate::from_url(cfg.overturn_hold_ledger_url, ..., cfg.overturn_hold_env)로 게이트를 만든다. 그리고 Arc<overturn_hold::HoldGate>를 EnforcementCtx에 주입한다.
  • 실행 경로에서는 gated_actions(&specs, &cfg)가 dispatch 후보에서 gate 대상 액션(Suspend/Label)만 골라 반환한다. dispatch 후보의 타입은 Vec<ActionSpec>다.
  • strip_held_labels(&mut specs, &gate.strip_labels)는 이미 뒤집힌 라벨 이름을 spec 리스트에서 제거한다.

• 판정 결과는 두 상태 코드로 표출된다 확인.

  • STATUS_HOLD_OVERTURNED = "hold_overturned"는 hold가 활성이라 실제로 차단된 경우다.
  • STATUS_HOLD_LOOKUP_FAILED = "hold_lookup_failed"는 ledger 조회 자체가 실패한 경우다.

• 같은 결정 outcome dict에 다음 진단 키들이 실린다 확인.

  • overturn_hold_id는 어느 hold가 매치됐는지를 나타낸다.
  • overturn_hold_mode는 off/shadow/enforce 중 어느 모드에서 판정됐는지를 나타낸다.
  • overturn_hold_head는 ledger 응답의 헤드 fingerprint다.
  • overturn_hold_expires_at는 hold 만료 시각이다.
  • overturn_hold_labels_stripped는 라벨 gate가 제거한 라벨 이름 목록이다.

• 이 진단 키들은 dedup retention 계층에도 진입한다 확인 — abuse-enforcement-service/service-lib/src/lib.rs:2469-2501.

  • 두 상태 각각의 dedup retention 항목이 새로 잡히므로, 중복 조치 제거 파이프라인이 두 상태를 별도 슬라이스로 취급한다 확인 — 같은 파일.
    • 새로 잡힌 항목은 dedup_retention_for(STATUS_HOLD_LOOKUP_FAILED)와 dedup_retention_for(STATUS_HOLD_OVERTURNED)다.

• hydration 실행 중 in-flight 결과를 담는 새 구조체가 도입됐다 확인.

  • 구조체는 Store이고, 새 파일 store.rs(339줄 신규)가 도입했다.
  • 필드는 다음 8종이고, 모두 Option<...>로 소지한다.
    • pure_cores: 트윗의 최소 골격
    • tweets: TweetForVisibility
    • controls: ConversationControl arm
    • labels: SafetyLabelMap
    • viewer: ViewerProfile
    • authors: DecodedAuthor
    • edges: socialgraph edge 결과 Vec<(Hydrators, RawHydrationBatch<Hydrators>)>
    • viewer_country: Arc<str>

• 하위 hydrator가 필요한 입력 키는 store가 origin 축으로 뽑아낸다 확인.

  • 이 일을 하는 함수는 Store::keys(origin: KeyOrigin) -> Vec<u64>다.
  • KeyOrigin::RequestTweets, Viewer, ViewerForCoAllowedList, PureCoreAuthor, PureCoreReplyRoot, ExclusiveConversationAuthor 등의 축이 정의돼 있다.
  • 어제 plan.rs에서는 NodeSpec { source, part, key, label }의 key가 이 origin이었다. 이제는 execute 경로에서 store가 origin별 실제 값을 리졸브한다.

• edges 필드는 이번 요청에서 실행 가능한 hydrator 집합의 부분집합으로만 채워진다 확인.

  • Store::callable: Hydrators가 이 집합을 bitset으로 소지해, edges 필드가 그 부분집합으로만 채워지도록 잠근다.

• follows 관계 조회가 socialgraph 직접 호출에서 wingman이라는 별도 서비스 경로로 옮겨졌다 확인.

  • 이 조회를 맡는 wingman_client는 새 파일 clients/wingman_client.rs(54줄 신규)다.

  const FOLLOWS_GRAPH: u32 = 1;
  const FOLLOWS_FLEET: Fleet<'static> = Fleet {
      wily_path: "/s/wingman/wingman-api-follows",
      authority_template: "wingman.wingman-api-follows.prod.{datacenter}.s2s.twttr.net",
      ...
  };
  

  — visibility-filtering/clients/wingman_client.rs:1-14

• wingman 클라이언트의 인터페이스는 batch_exists_intersect(viewer_id, root_author_ids) 하나뿐이고, mode는 IntersectMode::FwdXRev다 확인.

  • FwdXRev는 viewer → author 정방향 엣지와 author → viewer 역방향 엣지의 곱을 확인하는 모드다.
  • 이 모드는 "reply root 작성자와 뷰어가 서로 팔로우하고 있는가"를 한 번의 RPC 호출로 확인하는 데 쓰인다.
  • FOLLOWS_GRAPH가 상수 1인 것에서 wingman 안에 다중 그래프가 있음을 짐작할 수 있다. 2번 이후는 아직 공개 코드에 없다.

• 어제 함수가 필요 없어진 hydrator 파일 두 개가 이번 커밋에서 완전 삭제됐다 확인.

  • 두 파일은 safety_label_hydrator.rs(167줄)와 tes_hydrator.rs(79줄)다.
  • 두 파일은 어제 데이터 기반 스케줄러로 옮겨질 때 함수 자체가 필요 없어졌지만, 24시간 유예된 채 남아 있었다.

• 규칙 레지스트리 파일이 사실상 완전히 재작성됐다 확인.

  • rules/registry.rs가 +206/−203으로 바뀌었다.

• VF rules 계층이 Policy 구조체로 통일됐다 확인. 핵심은 각 SafetyLevel의 규칙 세트를 담는 Policy<'a> 구조체다.

  pub(super) struct Policy<'a> { base: &'a [RuleClause], additional: &'a [RuleClause] }
  static FILTER_ALL_POLICY: Policy = Policy::new(&[tweet_rules::FILTER_ALL]);
  static TIMELINE_HOME_POLICY: Policy = Policy::new(&TIMELINE_HOME_SHARED_RULES);
  static TIMELINE_HOME_RECOMMENDATIONS_POLICY: Policy = Policy::with_additional(...);
  static TIMELINE_HOME_HYDRATION_POLICY: Policy = Policy::new(&[...]);
  static IMMERSIVE_EXPANDED_RECOMMENDATIONS_POLICY: Policy = Policy::new(&[...]);
  

  — visibility-filtering/rules/registry.rs:28-215

  • RuleEngine::select(level) -> &'static Policy가 요청된 SafetyLevel마다 위 5개 static 중 하나를 참조한다.
  • Policy::with_additional(base, additional)은 두 슬라이스를 이어 붙여 파생 정책을 만드는 도구다.

• 정책이 데이터로 잠긴 static이 되면서, 골든 테스트가 정책 명세를 직접 pin할 수 있게 됐다 확인.

  • 이전 구조에서는 각 SafetyLevel마다 규칙을 함수 안에서 인라인으로 조립했다.
  • pin에 쓰는 함수는 wired_rule_names(level)이고, registry.rs:346 이후 테스트에서 실제로 사용한다.

• 규칙 계층 전용 metric 모듈이 새로 생겼다 확인.

  • 새 파일은 rules/metrics.rs(58줄 신규)다.
  • 어제까지는 hydration의 metrics.rs가 rule 판정에 관련된 metric까지 소지하고 있었다. 판정과 하이드레이션이 분리되면서 metric도 분리됐다.

• 부수적으로 filter 코드가 줄었다 확인.

  • filter.rs는 −94줄 감량됐다.
  • Verdict 트리(4세대+26, 2026-09-22 도입)가 안착하면서, filter가 더는 rule 실행 흐름을 직접 조절할 필요가 없어졌다.

• 광고 구매액 예측의 event × level 조합이 데이터 구조로 명시됐다 확인.

  • 파일은 phoenix/crates/serving/xai-recsys-proto/src/purchase_value.rs이고, +230/−4로 재작성됐다.

  pub const ACTION_INDEX: usize = ContinuousActionName::AdsWebCtPurchaseValue as usize;
  pub const MAX_EVENT_USD: f64 = 100_000.0;
  pub fn is_countable_usd(usd: f64) -> bool {
      usd.is_finite() && usd > 0.0 && usd <= MAX_EVENT_USD
  }
  pub enum ValueEvent { Purchase, ContentView, AddToCart }
  pub enum ValueLevel { ClickThrough, ViewThrough }
  pub struct ValueTarget { event: ValueEvent, level: ValueLevel }
  impl ValueTarget {
      pub const ALL: [ValueTarget; 6] = [ ... ];
      pub const PUBLISHED: [ValueTarget; 4] = [ ... ];
      pub const REQUIRED: [ValueTarget; 2] = [Self::PURCHASE_CT, Self::PURCHASE_VT];
  }
  

  — phoenix/crates/serving/xai-recsys-proto/src/purchase_value.rs

• 광고 구매액 continuous head는 3 이벤트 × 2 시점 = 6 target을 가진다 확인.

  • ValueEvent는 세 가지다.
    • Purchase: conversion_type 2, clickhouse 저장명 purchase
    • ContentView: 19, content_view
    • AddToCart: 12, add_to_cart
  • ValueLevel은 두 가지다. ClickThrough는 광고 클릭 후 발생한 경우이고, ViewThrough는 광고 노출만 있고 클릭 없이 발생한 경우다.
  • REQUIRED는 모델이 반드시 예측하는 2개로, purchase_ct와 purchase_vt다.
  • PUBLISHED는 웹훅 대상 4개로, purchase_ct, purchase_vt, content_view_ct, add_to_cart_ct다.
  • is_countable_usd는 이벤트 하나가 $100,000 USD를 넘으면 학습·평가에서 제외한다. NaN·음수·무한대도 제외한다.
  • 이 상수(6/4/2 조합)는 어느 event × level이 학습되고, 어느 것이 뽑아만 두고 노출되지 않는지를 데이터로 잠근다.

• 앞선 세 커밋에서 파편적으로 공개된 광고 구매액 예측 계층이 오늘 target 카탈로그로 통합됐다 확인.

  • 4세대+21(2026-09-15, ADS_WEB_CT_PURCHASE_VALUE 신설)
  • 4세대+22(2026-09-16, purchase-value loss 정식 연결)
  • 4세대+24(2026-09-18, purchase-value loss가 early-relabel 슬라이스로 좁혀짐)

• 4세대+21에서 신설된 baseline 필드가 event × level 축을 어떻게 소지하는지가 이제 코드에서 확정된다 확인.

  • 그 필드는 PurchaseValueBaseline request 필드다.
  • ValueTarget::mean(&PurchaseValueBaseline)이 6 target별 mean을 반환한다.

• home-mixer(For You와 Following 피드 요청을 받는 서비스)의 작성자 cold-start 스코어러에서 arm-gating 대상 served_type이 확장됐다 확인.

  • home-mixer/scorers/author_cold_start.rs에서 is_phoenix_moe 헬퍼가 is_arm_gated_retrieval로 이름이 바뀌었다.

  fn is_arm_gated_retrieval(c: &PostCandidate) -> bool {
      matches!(
          c.served_type,
          Some(
              pb::ServedType::ForYouPhoenixRetrievalMoe | pb::ServedType::ForYouPhoenixRetrievalCold
          )
      )
  }
  

  — home-mixer/scorers/author_cold_start.rs:167-173

• 오늘부터 Cold 채널의 후보는 cold-start 실험의 Holdout/Control/Treatment 팔 중 Treatment 팔에게만 노출된다 확인.

  • 즉 Cold 채널의 후보는 MoE retrieval 후보(served_type ForYouPhoenixRetrievalMoe)와 동일한 arm-gating 규칙을 따른다.
  • 신규 테스트 cold_retrieval_is_gated_like_moe가 이를 검증한다. Holdout·Control에서는 Cold 후보 점수가 0, Treatment에서는 5.0로 잔존한다.
  • Cold 채널은 4세대+28(2026-09-24, 44d37eb)에서 Phoenix retrieval에 HOME_HOT=14와 함께 신설된 HOME_COLD=13 채널이다 확인 — retrieval_dataset.py:280-281.
  • 이 채널은 1fav_1day.parquet 소스를 fav<8 & views<500 마스크로 분리하고 있었다.

• Phoenix async embedding CUDA 계층이 축소됐다 확인.
  • async_emb_api.cc +123/−191, async_emb_comm.cc +86/−63이다.
  • gradient 교환 API surface가 더 데이터 중심으로 정리되는 방향이다.
• optimizer와 trainer의 boilerplate가 줄었다 확인.
  • trainer_recsys.py +48/−200, rowwise_adagrad.py +51/−120이다.
• VF hydration의 두 파일이 소폭 조정됐다 확인.
  • visibility-filtering/hydration/tes_composite.rs(+29/−32)와 hydration/plan.rs(+48/−12)다.
  • plan의 조정은 wingman이 추가된 것과 대응한다.
• 하이드레이션과 규칙 개편에 맞춰 dispatch가 정리됐다 확인.
  • 바뀐 파일은 visibility-filtering/server.rs(+35/−21), filter.rs(+26/−120), evaluate_tweets.rs(+57/−51)다.

• abuse-enforcement의 overturn-hold gate 구조와 상수
• VF hydration의 store/execute 분리와 wingman 이관
• rules registry의 Policy static 화
• Phoenix 구매액 target 카탈로그
• cold-start의 Phoenix Cold 채널 편입

1. 자동화 판정과 사람 판정의 우선순위가 데이터로 잠긴다.
   • 이전에는 이의제기가 승인된 뒤에도 자동화 재판정이 다시 정지를 걸어 버리는 문제를 정책·프로세스로 관리했을 가능성이 크다.
   • 이제 자동화 dispatch 경로에서 정지 스펙이 만들어질 때마다 hold ledger 조회로 "이 조치가 이미 사람 손에서 취소된 적이 있는가"를 확인하고 gate하는 마지막 문이 코드에 들어 있다.
   • 이 재발 방지가 명시적 코드 경로가 됐다.
2. 정지의 취소가 "지속 상태"로 취급된다.
   • hold는 만료 시각(expires_at)을 갖는 시간 창이다. 그동안 특정 대상에 대한 자동화 조치를 막으며, 대상은 계정 또는 라벨이다.
   • 즉 사람 검토자의 이의제기 승인이 "1회성 취소"가 아니라 "이후 시간 T까지의 재적용 금지"라는 정책 항목이 된다.
   • 4세대+13(2026-09-01)에서 정책 파일 리팩터가 있었고, 4세대+26(2026-09-22)에서 verdict 이원 트리가 도입됐다. overturn-hold는 그 위에 놓이는 enforcement 상태 관리 계층이다.
   • dedup retention이 두 상태(hold_overturned·hold_lookup_failed)를 별도로 취급하는 것도 사후 감사(audit) 필요성을 함의한다.

VF 개편에서는 24시간 반감기 패턴이 반복된다. 어제까지 함수였던 safety_label_hydrator/tes_hydrator가 오늘 삭제됐고, 어제 신설된 execute.rs의 상태 로직이 오늘 store.rs로 분리됐다.

2AgentX-Model이 추천 모델 리서치 루프를 두 에이전트로 자동화했다 — arXiv

• Research Agent는 논문과 이전 실험 결과에서 독립적으로 리뷰된 제안을 만든다.
• Model Agent는 그 제안을 실제 코드와 측정으로 옮긴다.
• 결과에 따라 다음 질문을 짜는 것도 Research Agent가 한다.

• 저자 소속은 Kuaishou로 추정된다 추정. 논문 v1 HTML 판에는 소속이 렌더링되지 않는다.
  • 저자 23인에 Peng Jiang·Zhaojie Liu·Wenwu Ou가 포함돼 있고, 이 세 이름은 공개적으로 Kuaishou 라인이다.
  • Peng Jiang은 VP이고, Wenwu Ou는 Alibaba에서 Kuaishou로 이적했으며, Zhaojie Liu도 Kuaishou 소속이다.
  • 같은 팀의 선행 논문 AgentX v1(arXiv 2603.xxxxx, "Towards Agent-Driven Self-Iteration of Industrial Recommender Systems")에는 Kun Gai·Han Li 등 잘 알려진 Kuaishou 이름이 더 있어서, "AgentX"라는 코드네임이 Kuaishou 내부 프레임워크로 판단된다.

• 아키텍처는 Research Agent와 Model Agent로 이루어진 dual-agent 구조다 확인. 논문의 abstract를 그대로 옮긴다.

  "AgentX-Model adopts a dual-agent architecture comprising a Research Agent and a Model Agent. The Research Agent develops independently reviewed proposals from papers and experimental findings, while the Model Agent conducts multi-round investigations and returns code, measurements, and unresolved questions. Using the returned results, the Research Agent selects a starting implementation and formulates the next research question, allowing subsequent experiments to build on earlier findings." — AgentX-Model abstract

  • 리서치 루프는 4개 액션으로 조직된다.
    • Reproduce: 선행 실험을 재현한다.
    • Follow-up: 그 위에 확장한다.
    • Composition: 여러 기법을 결합한다.
    • Diagnose: 예를 들어 온라인 평가에서 발견된 이슈나 PCOC로 측정된 예측 편향 같은 것을 수리하기 위해 필요한 근거를 수집한다.
  • 앞의 세 액션이 일상적 리서치를 굴리고, Diagnose는 문제가 감지됐을 때 진단→수리 후보 선택을 담는다.

• 논문은 abstract에서 프로덕션 결과를 이렇게 진술한다 확인.

  "Across the production evaluation, 560 of 636 completed model-changing experiments recorded AUC above their business baselines. As research continued, some experiments recorded AUC above every comparable ancestor in their lineages. The five latest online A/B evaluations across different business settings reported gains including 10-15% in acquisition efficiency, 15-20% in target-segment advertising spend, and 0.3-0.8% in watch time; the watch-time model used approximately 10% fewer FLOPs and parameters." — AgentX-Model abstract

  • 진술을 풀면 세 가지다.
    1. 진행 중 완료된 636개 모델 변경 실험 중 560개(88%)가 비즈니스 baseline보다 오프라인 AUC가 높았다.
    2. 최근 온라인 A/B 5건에서 acquisition efficiency +10-15%, target-segment ad spend +15-20%, watch time +0.3-0.8%가 나왔다.
    3. watch-time 모델은 FLOPs와 파라미터를 약 10% 줄이면서 이걸 달성했다.
  • 사업 지표 셋(신규 유저 확보·광고 지출·시청 시간)을 각각 +10-15%·+15-20%·+0.3-0.8% 개선했다는 진술 구조는 자동화 리서치 프레임워크의 성과 프로파일로 상당히 크다.

• 논문은 dependency-aware historical-replay 벤치마크를 함께 낸다. 리서치 자원 할당, 즉 어느 실험에 다음 예산을 태울 것인가를 평가하는 벤치마크다.
• 초기 결과는 "에이전트가 이미 구체 후보를 분석·선택하는 경우 더 복잡한 스케줄링이 일관된 효율 이득을 주지 않는다"고 진술한다.
  • 즉 스케줄러 자체보다 후보 판단의 질이 병목이라는 관찰이다.

• 첫 번째 사례는 Meta VDD MBR + EvoPilot의 "37일 human-gated autoresearch 캠페인이 evaluator output-depth 3000/600 결함을 잡아 offline +3.20pp 회복"이었다(2026-09-22).
• Meta가 검색 retrieval 개선을 자동화한 각도라면, AgentX-Model(Kuaishou 추정)은 전 recommendation 모델 리서치 루프 그 자체를 자동화한 각도다.
• 두 회사가 자동화 리서치 프레임워크를 명시적으로 이름 붙여 공개한 일이 이번 달에 이어졌다는 점에서 관찰 스레드로 붙는다.

레이더

• AgentX-Model (Kuaishou 추정)을 이번 달 신규로 편입했다.

다음에 볼 것