2026-09-30

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

• X 홈믹서(For You 피드를 조립하는 서비스)의 가중치 미러에서 클릭 가중은 내려가고, 클릭 뒤 체류 가중이 켜졌다.
• X의 노출 판정 서비스 VF가 스테이징에서 자기 판정을 견주는 대상에 tweet 저장·조회 서비스인 Tweetypie를 더했다.
• 익명 e-commerce 검색 팀이 검증을 4계층으로 나눈 자동 리서치 프레임워크 PEAR를 냈고, 레이더에 넣었다.

1overturn-hold 서버가 읽기 전용 조회 서비스로 공개됐다 — X

• 서버는 axum과 PostgreSQL로 만든 읽기 전용(read-only) 조회 서비스다 확인.

  • 서비스 이름은 abuse-ledger-service이고, Cargo 이름은 xai-abuse-ledger-service다.

  • 파일 11개(api.rs·boot.rs·codes.rs·config.rs·lib.rs·main.rs·metrics.rs·pg.rs·repo.rs·sql.rs·tls.rs)에 모두 2,282줄이다.

  • 서버 API의 조회 경로는 2026-09-26 커밋의 클라이언트가 호출하던 /v1/holds/lookup 엔드포인트 하나뿐이다.

  • 경로, 헤더 이름, 한도는 상수로 정해 두었다.

    "pub const LOOKUP_PATH: &str = "/v1/holds/lookup"; pub const DEADLINE_HEADER: &str = "x-request-deadline-ms"; pub const MAX_USER_IDS: usize = 100; pub const MAX_LABELS: usize = 32;" — abuse-ledger-service/src/api.rs, 2026-09-29

  • 요청 스키마는 {user_ids: Vec<i64>, labels: Vec<String>}이고, 응답은 {holds: Vec<Hold>, db_ms: u64}이다.

  • 한 번에 user_ids는 최대 100개, labels는 최대 32개까지 조회할 수 있다.

  • 호출자는 x-request-deadline-ms 헤더로 남은 예산을 지정한다.

  • 서버는 이 값이 statement timeout보다 작으면 그 값을, 크면 statement timeout에 QUERY_DEADLINE_SLACK = 100ms를 더한 값을 실제 DB 예산으로 쓴다(api::budget).

• 서버가 실행하는 SQL은 세 개가 전부다 확인 — abuse-ledger-service/src/sql.rs.

  • 조회 대상 테이블 스키마는 ledger.enforcement_holds다.

  • 아래가 조회 SQL이다.

    "SELECT user_id, hold_id, head, expires_at, case_group_id, reason, action_kind, label FROM ledger.enforcement_holds WHERE user_id = ANY($1::bigint[]) AND cleared_at IS NULL AND expires_at > now() AND (action_kind = 'suspend' OR (action_kind = 'label' AND label = ANY($2::text[])))" — abuse-ledger-service/src/sql.rs, 2026-09-29

  • 이 SQL은 다음 세 조건을 모두 만족하는 행만 돌려준다.

    • 아직 살아 있는 hold다(cleared_at IS NULL).
    • 만료되지 않았다(expires_at > now()).
    • action_kind='suspend'이거나 action_kind='label' AND label ∈ 요청 라벨 집합이다.

  • action_kind에는 두 값(suspend, label)만 정의됐다.

  • cleared_at는 사람 검토자가 hold를 회수했을 때 채워지는 tombstone이다.

  • 기동할 때 SELECT ... LIMIT 0으로 컬럼 프로젝션이 스키마와 맞는지 확인하는 CONTRACT_SQL이 있다.

  • 헬스체크는 SELECT 1(PING_SQL)뿐이다.

  • sql.rs의 테스트는 세 SQL 문자열에 INSERT/UPDATE/DELETE/ALTER/DROP/CREATE가 하나도 들어가지 않음을 assert한다. 서버는 원리적으로 write를 못 한다.

• PostgreSQL 클라이언트는 deadpool-postgres를, TLS는 rustls를 쓴다 확인 — abuse-ledger-service/src/pg.rs.

  • 상수는 POOL_WAIT_TIMEOUT = 1s, POOL_CREATE_TIMEOUT = 1.5s, POOL_RECYCLE_TIMEOUT = 500ms, QUERY_DEADLINE_SLACK = 100ms다.
  • PgError variant는 BadDsn / Connect{Refused|Auth|Tls|Timeout|Other} / Saturated / Transport / Query{sqlstate, message} / Decode / Timeout 7종이다.
  • SQLSTATE 57014(query_canceled)만 ErrorCode::StatementTimeout으로 분류된다. 28P01/28000(auth)는 ErrorCode::AuthFailed로 따로 분류된다.
  • 부팅할 때 boot::contract_check_until_ok가 AtomicBool<ready>를 false에서 시작해, 스키마 검사가 성공할 때까지 /readyz를 200이 아닌 상태로 둔다.

• 서버가 돌려주는 hold 레코드(Hold)의 실제 모양이 공개됐다 확인 — abuse-ledger-service/src/repo.rs.

  "pub struct Hold { pub user_id: i64, pub hold_id: i64, pub action_kind: String, pub label: Option<String>, pub head: Option<String>, pub expires_at: DateTime<Utc>, pub case_group_id: Option<i32>, pub reason: String, }" — abuse-ledger-service/src/repo.rs, 2026-09-29

  • head는 2026-09-26 커밋의 클라이언트 쪽 진단 키(overturn_hold_head)로 이미 등장한 필드이고, 이제 서버 스키마에서 Option<String>으로 확정됐다.
  • 그 내용은 여전히 공개되지 않았다. hold를 발행한 검토 도구의 식별자 정도로 보인다 추정.
  • case_group_id: Option<i32>는 이의제기 case를 여러 hold로 묶는 그룹 키다.
  • reason: String은 사람 검토자가 남긴 사유 문자열이다. 필드가 있다는 것은 확인했지만, 내용 포맷은 공개되지 않았다.

• TLS 모듈은 348줄짜리 별도 파일이다 확인 — abuse-ledger-service/src/tls.rs.

  • PostgreSQL 연결에 rustls를 쓰는 코드다. DSN의 sslmode=require|verify-ca|verify-full을 파싱하고, CA/CRT/KEY 경로는 별도 환경 변수에서 읽어 붙인다.
  • 즉 ledger 저장소에는 mTLS로 접근하며, 이 서비스는 그 저장소의 read-only 프록시 자리에 있다.

visibility-filtering(VF)은 포스트마다 '이 뷰어에게 보여도 되는가'를 판정하는 서비스다. VF에는 오래 걸어 둔 "레퍼런스 비교" 장치(4세대+7, 2026-08-24)가 있고, 이번에 그 위에 두 번째 비교 대상이 붙었다. 기존 대상은 Scala VF 서비스뿐이었다. 새로 붙은 reference/tweetypie.rs(714줄 신설)는 Scala Tweetypie를 직접 호출한다. Tweetypie는 X의 tweet 본문 저장·조회 서비스이고, 그 응답에는 이미 tweet 단위 visibility 결정이 들어 있다. 이 결정을 자체 VF의 판정과 diff한다.

• 레퍼런스 비교 대상을 고르는 값이 Scala VF 서비스 하나에서 Tweetypie까지 둘로 늘었다 확인 — visibility-filtering/reference/mod.rs.

  • 값은 vf_service에서 vf_service | tweetypie 두 값으로 확장됐다.

    "pub enum Reference { None, VfService, Tweetypie, } ... (_, Some("prod")) => Err(format!( "{ENV_REFERENCE} selects {reference:?} but {ENV_APP_ENV}=prod; reference comparisons are staging-only" ))," — visibility-filtering/reference/mod.rs, 2026-09-29

  • 2026-08-24 커밋(4세대+7)부터 dual_call_harness 환경 변수로 켜던 Rust VF ↔ Scala VF 비교는 이번 개편에서 VF_REFERENCE 환경 변수로 옮겨졌다.

  • 새 변수는 값 세 개(none / vf_service / tweetypie) 가운데 하나를 받는다.

  • 옛 ENV_DUAL_CALL_HARNESS_ENABLED 플래그가 남아 있으면 기동이 실패하고, 새 이름을 쓰라는 에러가 나온다(migration).

  • 어느 값이든 APP_ENV=prod에서는 기동이 거부된다.

• Tweetypie 경로는 Strato(코드가 데이터를 조회하거나 저장할 때 거치는 X 내부 시스템)의 컬럼 하나를 호출한다 확인 — visibility-filtering/reference/tweetypie.rs.

  • 컬럼은 tweetypie/getTweetFields.Tweet다.
  • 이 컬럼에 GetTweetFieldsOptions { visibility_policy: VISIBILITY_POLICY_USER_VISIBLE, ... }를 실어 호출한다. 그러면 Tweetypie가 VF 결정(Action::Allow | Drop(reason))까지 이미 붙여서 돌려준다.
  • 상수는 다음과 같다.
    • TWEETYPIE_MAX_BATCH_SIZE = 250: 한 번에 250개 tweet까지 배칭
    • MAX_IN_FLIGHT = 32: semaphore로 거는 fan-out 상한
    • TWEETYPIE_TIMEOUT = 1500ms
    • SAFETY_LEVEL = SafetyLevel::TimelineHomeHydration: Tweetypie에 요청하는 판정 레벨
    • RECORD_CAP_PER_MINUTE = 20: 샘플 로그 상한, 분당 20건
    • WEB_CLIENT_APPLICATION_ID = 3_033_300: 요청에 실리는 클라이언트 앱 ID
  • 결과 클래스는 Allow / BareDrop / Drop / Suppressed / NotFound / Failed / Missing 7가지다.
  • 실패 사유는 NoValue / StratoError / RateLimited / DecodeError / RpcError / OverCapacity / TweetypieFailed 7가지다.
  • 결과 클래스와 실패 사유는 각각 vf_tweetypie_reference_compare 메트릭 라벨로 집계된다.

• 클라이언트마다 어떤 규칙을 켤지가 이제 데이터 테이블로 고정됐다 확인 — visibility-filtering/params/client_switches.rs.

  • 새 파일은 VF params/client_switches.rs(+225줄, 신설)이고, 스위치 6개를 열거한다.

    "enum ClientSwitch { AgeVerification(VerifyBlurSupport), ModernBlur, StaleTweetLimits, GoreBlurIgnoresSettings, FosnrRules, FosnrFallbackDrops, }" — visibility-filtering/params/client_switches.rs, 2026-09-29

  • 각 스위치는 xai_feature_switches::FeatureSwitches의 문자열 키에 매핑된다.

  • VerifyBlurSupport의 4개 상태(Unsupported | IosNeedsUpdate | AndroidNeedsUpdate | Supported)마다 서로 다른 age_verification_*_tombstone_rule_enabled 키를 쓴다.

  • default_on으로 기본 켜지는 것은 세 개(AgeVerification(Unsupported), StaleTweetLimits, FosnrRules)다.

  • 요청이 오면 TwitterContextViewer(client_application_id, user_agent, country_code)와 viewer_id로 RecipientBuilder를 구성해 매치한다.

홈믹서의 파라미터 파일은 x-algorithm 저장소의 오래된 규약대로, 프로덕션 feature-switch 기본값을 주기적으로 옮겨 오는 크론 미러다. 이번에 params/param.rs의 상단 주석 // mirrored from config feature-switch defaults; last sync 2026-09-28T16:00:35Z가 갱신됐고, 세 가중치가 함께 움직였다.

• 클릭 가중치가 내려가고, 그동안 꺼져 있던 클릭 뒤 체류 가중치가 켜졌다 확인 — home-mixer/params/param.rs.

  • 프로덕션 크론 미러에서 ClickWeight 0.4 → 0.3, ContClickDwellTimeWeight 0.0 → 0.4로 동시에 바뀌었다.

  • 파일 상단 주석의 last sync가 2026-09-25T16:24:28Z → 2026-09-28T16:00:35Z로 갱신됐고, 세 값이 함께 움직였다.

    "-param!(ClickWeight, f64, "rust_home_mixer_click_weight", 0.4); +param!(ClickWeight, f64, "rust_home_mixer_click_weight", 0.3); ...

    • "rust_home_mixer_cont_click_dwell_time_weight",
    • 0.0

    • "rust_home_mixer_cont_click_dwell_time_weight",
    • 0.4

    ...

    • "rust_home_mixer_not_interested_weight",
    • -43.2

    • "rust_home_mixer_not_interested_weight",
    • -47.52"

    — home-mixer/params/param.rs 프로덕션 크론 미러, 2026-09-29

  • 클릭 자체의 가중치는 4분의 1 낮아졌다(0.4 → 0.3).

  • 그동안 0으로 꺼져 있던 continue-click-dwell(클릭 뒤에 실제로 오래 머무른 세션) 가중치는 0.4로 켜졌다.

  • Not Interested 가중치는 −43.2에서 −47.52(정확히 1.1배)로 강화됐다.

  • 4세대+22(2026-09-16)에서 binary continuous loss type이 click-dwell BCE로 프로덕션에 적용된 뒤, 학습된 head 하나가 오프라인에서 효과를 보였고 그 head를 실제 서빙 가중합에 넣은 것으로 보인다 추정.

• VF의 리트윗 소스 병합 로직이 별도 모듈로 분리됐다 확인 — visibility-filtering/retweet.rs.
  • 새 모듈 visibility-filtering/retweet.rs는 318줄이고, evaluate_tweets.rs는 +101/−102로 줄었다.
  • 4세대+28(2026-09-24)에서 인라인으로 도입된 in-batch vs fetched 두 세트 소스 verdict 병합이, 이번에 evaluate_merging_sources 함수로 분리됐다.
  • 구조는 같다. 요청 후보 안에 원본이 이미 있으면 in-batch로, 없으면 별도 hydration으로 가져와 fetched로 판정한 뒤 병합한다.
  • 대신 evaluate_tweets_retweet_sources { outcome=in_batch | fetched } 메트릭이 retweet.rs로 옮겨 왔다. 이 메트릭은 2026-09-24 커밋(4세대+28)에서 evaluate_tweets.rs에 처음 생겼다. 리트윗 원본을 판정하는 데 별도 fetch가 얼마나 자주 필요한지를 보여 주는 메트릭이다.
• age verification golden corpus 705줄과 legacy interstitial 130줄이 새로 생겼다 확인 — visibility-filtering/rules/golden_corpus/age_verification.rs와 legacy_interstitial.rs.
  • 4세대+29(2026-09-25)에서 시작된 golden corpus 15-파일 분할의 후속이다.
  • age_verification.rs는 C 카드의 AgeVerification(*) 스위치가 각 클라이언트 상태(Unsupported/iOS 갱신 필요/Android 갱신 필요/Supported)에서 만들어 내는 verdict를 role×tweet 매트릭스로 고정한다.
  • Role은 web_in_fr·web_in_us·sensitive_opt_in_web_in_fr 등이고, 후보는 nsfw_admin_flag_media·limited·blurred 등이다.
  • local_regulations.rs와 takedown.rs도 같은 커밋에서 새 파일로 갈라졌다.
• Phoenix(X For You의 랭킹·retrieval 모델)의 retrieval이 이미 본 포스트를 후보에서 빼는 토글이 새로 생겼다 확인 — home-mixer/params/param.rs.
  • 새 파라미터는 PhoenixRetrievalExcludeSeenPosts이고, 기본값은 false다.
  • 기본이 false이므로 아직 활성 정책은 아니다.
• impression 부스트에 쓰던 파라미터 하나가 홈믹서 파라미터 파일에서 제거됐다 확인 — home-mixer/params/param.rs.
  • 제거된 파라미터는 UseEngagementCounterViewCountForImpressionBoost다.
  • impression 부스트를 위한 view count 소스가 engagement counter에서 다른 소스로 옮겨 갔거나, 부스트 자체가 폐기됐다.
• 홈믹서 시그널에서 author_policy_zeroed 필드가 완전히 제거됐다 확인 — home-mixer/models/candidate.rs, scorers/value_model.rs, scorers/vm_ranker.rs, scorers/vm_ranker_request.rs.
  • VMRanker(홈믹서 뒤에 붙어 다양성 재정렬을 맡는 별도 랭킹 서비스)의 요청 shape에서도, 후보 dict에서도 이 boolean이 사라졌다.
  • 이 신호가 무엇을 억제하던 플래그였는지 이번 공개에 직접 적힌 곳은 없지만, 이름과 사용 위치(scoring 때 후보에 실려 있던 boolean)로 보아 author policy 때문에 점수가 0으로 눌린 후보를 표시하던 마커였다 추정.
  • 4세대에서 policy-driven 후보 억제는 이제 VF verdict에서 직접 판정된다.
• Phoenix 서빙 응답에 view-through 값 두 종류도 실리게 됐다 확인 — phoenix/crates/serving/xai-recsys-proto/src/purchase_value.rs.
  • Phoenix purchase_value.rs의 PUBLISHED 배열이 4개에서 6개(= ALL)로 늘었다.
  • 직전 커밋(4세대+30)에서는 PUBLISHED = [PURCHASE_CT, PURCHASE_VT, CONTENT_VIEW_CT, ADD_TO_CART_CT]로 고정돼 있었다. 이번에 PUBLISHED = ALL로 바뀌어 CONTENT_VIEW_VT와 ADD_TO_CART_VT(view-through 두 종류)도 서빙 응답에 실린다.
  • 프로토 PurchaseValueBaseline의 인코딩 크기 상한 assert도 ≤64 바이트 → = 73 바이트로 갱신됐다.

1. 자동화 정지 정책의 신뢰 계층이 두 서비스로 물리적으로 분리됐다.
   • abuse-enforcement 서비스는 조치를 실제로 내보낼지(dispatch) 결정한다. abuse-ledger-service는 사람 검토자의 결정(overturn)을 조회만 한다(쓰기 경로는 미공개).
   • 두 서비스는 별도 DB를 쓴다. 전자는 자체 스토어를, 후자는 ledger.enforcement_holds를 쓴다.
   • 후자는 SQL 세 개(PROBE_SQL, CONTRACT_SQL, PING_SQL)로만 통신하며, 그 세 SQL에 어떤 write verb도 들어가지 않음이 assert로 고정돼 있다.
   • 즉 dispatch 경로에서 사람 판정을 "우회하지 않았다"는 사실을 코드 밖에서 감사할 수 있게 됐다. ledger DB의 write 권한을 dispatch 시스템이 갖지 않는다.
2. VF의 레퍼런스 비교 대상이 자체 참조인 Scala VF를 벗어나 tweet 원 저장소인 Tweetypie까지 넓어졌다.
   • Rust VF와 Scala VF는 같은 정책 집합을 두 언어로 재구현한 관계라, 둘의 diff는 정책 차이보다 구현 drift 쪽으로 치우친다.
   • Tweetypie는 storage 계층에서 이미 붙여 두는 tweet 자체의 visibility 결정을 갖고 있으므로, 그것과 diff하면 "storage 축의 결정"과 "serving 축의 결정" 사이의 drift가 잡힌다.
   • SafetyLevel::TimelineHomeHydration으로 특정 Safety Level에 고정한 것과 prod 기동을 거부하는 것은, 이 harness가 안전망이 아니라 정확성 검증 도구임을 보여 준다.
3. 랭킹이 "클릭"을 덜 믿기 시작했다.
   • click_weight 0.4 → 0.3과 cont_click_dwell_time_weight 0.0 → 0.4가 같은 크론 sync에서 함께 바뀌었다.
   • 4세대+22(2026-09-16)에서 학습 loss에 들어간 click-dwell head가 학습 curve와 홀드아웃을 통과한 뒤, 서빙 가중합의 계수로 승격된 순서로 보인다.
   • 두 head는 확률 스케일이 서로 달라 정확한 합계는 비교할 수 없다. 그래도 "클릭했다"보다 "클릭한 뒤에도 머물렀다"가 프로덕션 목적에 더 부합하는 방향이 명시적으로 고정된 것이다.
   • Not Interested의 −43.2 → −47.52(정확히 ×1.1)도 사용자의 명시적 부정 신호를 함께 강화하는 방향이다.

2산업 검색 실험을 4계층 검증으로 자동화하는 PEAR가 나왔다 — arXiv

• verifier ladder는 4계층이고, 저비용 지표부터 높은 신뢰 지표까지 차례로 통과해야 다음 단계로 넘어간다 확인.
  • 순서는 Offline Replay → Shadow-Traffic Evaluation → Rapid Online Evaluation → Decision-Grade Online Evaluation이다.
  • 통과 여부는 confidence-gated로 정해진다.

• 온라인 A/B 두 실험에서 Main Order/DAU가 각각 +2.7336%, +3.2957% 올랐다 확인.

  "In a real-world industrial search system, strategies optimized with PEAR significantly increased Main Order/DAU by 2.7336% and 3.2957% relative to their respective baselines in two A/B experiments." — PEAR abstract, 2026-09-28

  • 자릿수를 4자리까지 준 것과 "Main Order/DAU"(주문 수 / DAU)라는 지표는 e-commerce 지면의 표준 KPI 표기다.
  • 회사명은 적혀 있지 않다. 소속 표기가 Alibaba International Digital Commerce(AliExpress/Lazada) 라인의 "Global E-Commerce" 팀 브랜딩과 일치해 Alibaba 라인이다 추정. 다만 v1 HTML에서 도메인이 렌더링되지 않아 확정할 수 없다.

레이더

• PEAR(arXiv 2609.35031)는 익명 e-commerce 팀이 낸 산업 검색 시스템용 progressive autoresearch 프레임워크다. 소속은 Alibaba 라인이다 추정. 4계층 verifier ladder와 hypothesis-guided per-task state를 쓰고, A/B 두 건에서 Main Order/DAU +2.7336%·+3.2957%를 보고했다. 지표는 확인, 소속은 추정이다. radar.md 이번 달 신규에 넣었다.

다음에 볼 것