2026-10-14

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

• X는 같은 커밋에서 후보 검색(retrieval) 모델에 체류 기반 헤드를 추가했다.
• Meta는 광고 foundation model GEM의 백본을 InterFormer에서 Kunlun으로 바꾸고 지면별 모델을 하나로 합쳤다고 발표했다.
• Meta는 남는 추론 GPU 용량으로 광고 후보를 더 평가하거나 요청을 더 큰 모델로 보내는 서빙 방식을 소개했다.

1home-mixer 미러에서 영상 열기 가중치가 내려가고 좋아요·체류 가중치가 올랐다 — X

• 바뀐 가중치 3개 가운데 좋아요와 체류 시간 가중치는 올랐고, 영상 열기 가중치는 내려갔다 확인 — home-mixer/params/param.rs:320, 341-346, 401-406.

  • 좋아요 가중치 FavoriteWeight는 0.5에서 0.6으로 올랐다.

    param!(FavoriteWeight, f64, "rust_home_mixer_favorite_weight", 0.6);
    

    — home-mixer/params/param.rs:320 (코드), 2026-10-13

  • 영상 열기 가중치 VideoOpenWeight는 0.07에서 0.02로 내려갔다.

  • 체류 시간 가중치 ContDwellTimeWeight는 0.004에서 0.006으로 올랐다.

  • 미러 sync 시각은 2026-10-12T16:00:33Z다.

• VM-Ranker 쪽 미러는 같은 feature switch 키를 쓰고, 세 값은 0.5·0.07·0.004 그대로다 확인 — vm-ranker/params.rs:3, 12-17, 54-59.
  • VM-Ranker는 home-mixer가 1차로 계산한 점수를 받아 value model과 DPP(determinantal point process) 다양성 재순위를 다시 계산하는 별도 서비스다.
• 두 미러가 갈라진 것은 4세대+37 커밋의 새 작성자 부스트(PostUnexploredWeight) 이후 두 번째다. 그래서 실제 서빙값이 어느 쪽인지는 이번에도 확정할 수 없다 추정.
  • VM-Ranker가 응답하는 요청에서는 VM-Ranker 값이 최종값일 가능성이 있다.

two-tower retrieval은 유저와 포스트를 각각 벡터로 만들고, 내적이 큰 포스트를 후보로 가져오는 방식이다. 어떤 행동을 positive(정답)로 학습시키느냐가 곧 retrieval의 목적 함수가 된다.

• home·immersive를 함께 학습하는 combined 프리셋의 후보 헤드가 2개에서 3개가 됐다 확인 — phoenix/xrex/configs/xrecsys_two_tower.py:251-300.

  • 세 헤드의 이름은 home, immersive, ld다.

  • ld 헤드의 positive 행동은 CLIENT_TWEET_RECAP_DWELLED 하나다.

            "ld_positive_actions": [recsys_pb2.ActionName.CLIENT_TWEET_RECAP_DWELLED],
            "num_candidate_heads": 3,
            "head_names": ["home", "immersive", "ld"],
            "w_ld": 0.75,
    

    — xrecsys_two_tower.py:293-296 (코드), 2026-10-13

• 서빙 점수는 home 슬롯과 ld 슬롯의 내적을 가중합한 값이다 확인 — recsys_two_tower_model.py:93-120, 1916-1920, 2385-2412.

  • 식은 "home 슬롯 내적 × 1.0 + ld 슬롯 내적 × 0.75"다.
  • 포스트 임베딩 테이블의 한 행에 두 슬롯을 나란히 넣고, 같은 유저 벡터로 각 슬롯을 채점해 가중합한다.

• 이번 변경으로 홈 retrieval의 목적이 "좋아요할 포스트"에서 "좋아요하거나 오래 머물 포스트"로 넓어졌다 확인(config 값).

  • 지금까지 home 헤드의 positive는 좋아요(SERVER_TWEET_FAV) 하나였다.

• 헤드 이름 ld는 long dwell의 약자로 본다 추정. 근거는 positive 이름이 RECAP_DWELLED이고, "Recap"이 Twitter가 랭크드 홈 타임라인을 부르던 내부 이름이라는 점이다.

  • 몇 초를 넘어야 "dwelled"인지는 공개 코드에 없다.

• 같은 프리셋에서 유저의 설치 앱 목록 피처(enable_user_installed_apps)가 꺼졌다 확인(259행).

• 포스트 하나에 달린 답글을 최대 64개까지 유저별로 채점하는 모델이 새로 공개됐다 확인 — xrecsys_reply_two_tower_v2.py.
  • 모델 이름은 reply_two_tower_v2다.
  • 모델 코드는 recsys_reply_two_tower_v2_model.py(1,077줄)다.
  • 서빙 등록 파일은 이 모델을 "reply-ranker"라고 부른다.
• 모델은 홈 랭커보다 훨씬 작다 확인. Transformer 1층, 임베딩 256차원, 히스토리 127개다.
• 홈 Phoenix와 달리 손으로 만든 피처가 많다 확인 — phoenix/crates/common/xai-recsys/src/reply.rs.
  • 답글의 참여 수
  • 작성자 팔로워 수와 인증 여부
  • 원글 작성자가 좋아요를 눌렀는지·답했는지
  • 누적 리포트·차단·뮤트 수
  • Grok이 매긴 답글 점수(grox_score)
• 이 랭커를 부르는 쪽 코드는 공개되지 않았다 확인. home-mixer 변경 파일 17개에 호출이 없다.

• 영상 제외 요청에서는 인용 원글이 영상이거나 대화 조상 포스트에 영상이 있는 후보도 걸러진다 확인 — 신규 filters/ancestor_video_filter.rs.
• 영상 캐러셀에 작성자 중복 제거와 SID(의미 기반 아이템 ID) 앞자리 중복 제거 옵션이 생겼고, 둘 다 기본 off다 확인 — home-mixer/util/video_carousel.rs.
  • 영상 캐러셀은 For You 6번째 자리의 세로 영상 묶음이며, 기본 off다.
• value model에 새 항이 하나 추가됐고, 가중치 기본값은 0.0이다 확인 — xai-value-model/scoring.rs:136.
  • 항 이름은 react_with_video다.
  • 행동 SERVER_TWEET_REACT_WITH_VIDEO는 CLIENT_CARD_CLICK이 있던 proto ActionName 44번 자리를 차지했다.
• 좋아요가 0인 포스트를 모으는 것으로 보이는 retrieval 데이터셋 ZERO_FAV(16번)와 그 통계 기록이 추가됐다 확인. 채널을 채우는 코드는 없어서 이름 이상의 해석은 추정이다.
• home-mixer가 피드 요청 맥락(FeedRequestContext) 값을 처음으로 채운다. 다만 채우는 곳은 광고 인덱스 요청이고, Phoenix 랭킹 요청은 아니다 확인 — sources/ads_source.rs.
  • 이 값은 2026-10-09 커밋(4세대+39)에서 Phoenix 요청에 추가됐다.
• abuse-enforcement-service에 규칙별 집행 조치를 런타임에 바꾸는 파일과 집행 전체를 끄는 파일이 새로 생겼다 확인. 피드 랭킹과 직접 관계는 없다고 본다 추정. 심층 분석이 필요하다.
  • 두 파일은 action_control.rs(3,218줄)와 off_switch.rs(1,619줄)다.

• 가중치 미러 값이 바뀐 것은 새 작성자 부스트에서 두 미러가 갈라진 4세대+37 커밋 이후 처음이고, 방향은 "영상 열기 비중을 줄이고 좋아요·체류 비중을 늘린다"이다 확인(값). 다만 VM-Ranker 미러는 그대로라서 실제 서빙값은 확정할 수 없다 추정.
• retrieval까지 체류를 목적에 넣은 것이 새롭다 확인. 클릭 후 체류 가중치를 0에서 0.4로 올린 4세대+31 커밋, 손실을 CREAD(임계값별 분류 후 복원)로 바꾼 4세대+38 커밋과 함께 보면, X는 retrieval부터 랭킹까지 체류 신호의 비중을 계속 늘리고 있다 추정.
• 답글 랭커는 README의 "hand-engineered feature를 전부 없앴다"는 주장이 홈 피드에만 해당한다는 근거다 확인(피처 목록).

↑ 목차

2GEM 2026 세대가 백본을 Kunlun으로 바꾸고 지면별 모델을 하나로 합쳤다 — Facebook·Instagram (광고)

• 백본이 InterFormer에서 Kunlun으로 바뀌었다 확인. Kunlun은 2026-02 논문으로 먼저 나왔고, 그 초록은 이미 이렇게 썼다: "Kunlun is now deployed in major Meta Ads models".

  "Compared to the previous version (Interformer), Kunlun delivers 2x performance gains with the same computation scaling." — GEM 2026 블로그 (블로그), 2026-10-13

• 블로그는 CompSkip(학습 중 일부 구성요소를 꺼서 계산을 건너뛰는 기법)으로 FLOPs를 43% 줄였다고 쓴다 확인.

  "By selectively deactivating the specific components, which is based on the assumption that the network can recover quickly after re-activating, we reduce FLOPS by 43% with negligible quality loss." — 같은 블로그 (블로그), 2026-10-13

• 지면별 모델을 하나로 합쳤다 확인. 공유 expert와 도메인 전용 expert를 함께 두고, 지면별 학습 데이터는 물리적으로 합치지 않고 가상으로 섞는다.

  "The 2026 generation of GEM shifts from isolated per-domain optimizations — such as Facebook, Instagram, Reels — to a single central foundation model." — 같은 블로그 (블로그), 2026-10-13

• 장기 참여 이력 길이를 프로덕션에서 2배로 늘렸고, 25배까지 늘릴 역량을 확인했다 확인.

• 모델 복잡도는 이전 GEM 대비 2.5배이며, 그 규모에서 LLM과 비슷한 스케일링 법칙을 관찰했다고 쓴다 확인.

• 학습 효율(MFU 20-25%, FLOPs 4배)은 2026-08-03 글과 같은 수치다 확인.

• 하위 모델로 지식을 옮기는 경로가 세 가지다 확인.

  • LoopFM은 GEM의 내부 표현과 이력 메모리를 하위 모델에 넘기는 post-training 기법이다. 일반 knowledge distillation(선생 모델의 예측 확률을 학생 모델의 정답으로 쓰는 학습)보다 전이 효과가 2배라고 주장한다.

  • soft label distillation도 함께 쓴다.

  • Solaris는 다음 요청에 필요할 user-ad 쌍의 GEM 임베딩을 미리 계산해 두는 방식이다.

    "It speculatively precomputes foundation model embeddings for the user-ad pairs a future request is likely to need, and delivers them just-in-time on the serving hot path." — 같은 블로그 (블로그), 2026-10-13

• 블로그는 전환과 광고 클릭률의 개선 수치를 냈다 확인.

  "GEM has delivered 18.9% conversion improvement and 12% ad click-through rate (CTR) improvement across Meta's ad surfaces and objectives, and additionally contributed 5.8%, 4.1%, and 1.6% conversion uplift on Facebook, Instagram, and off-site conversion for targeted users over the past year." — 같은 블로그 (블로그), 2026-10-13

  앞의 두 수치는 기간과 기준선이 없고, 뒤의 세 수치는 지난 1년 누적이다. A/B 설계는 본문에 없다.

• 유기 피드 데이터로 확장할 계획을 밝혔다 확인(계획 진술).

  "Looking forward, we are excited to extend GEM to learn from all of Meta's platform data, capturing behavior across organic and ads engagements spanning text, images, and video." — 같은 블로그 (블로그), 2026-10-13

• ⚠ 주장 변경: 정본의 "GEM = Wukong·InterFormer 통합"은 2025-11 세대 설명이 됐고, 2026 세대의 백본은 Kunlun이다 확인.
• Solaris는 LLaTTE(Meta 광고 랭킹의 시퀀스 모델)가 공개한 "무거운 시퀀스 계산을 비동기 upstream 모델로 빼낸다"는 설계와 방향이 같다 추정. 다만 두 글이 서로를 인용하지 않아 같은 시스템인지는 알 수 없다.
• 이 노트들이 추적해 온 "유기(HSTU) 계보와 광고(GEM) 계보가 서로를 인용하지 않는다"는 관찰에 처음으로 합류 계획이 나왔다 추정. 계획 진술일 뿐 배포 사실은 아니다.

↑ 목차

3남는 추론 용량으로 광고 후보를 늘리거나 더 큰 모델을 쓴다 — Facebook·Instagram (광고)

• 남는 용량을 쓰는 조절 수단은 두 가지다 확인.
  • 랭킹 단계에서 평가하는 광고 후보 수를 늘린다(Rank More Ads).
  • 요청을 더 큰 모델로 보낸다(Serve Better Models). 이때는 가치가 큰 요청부터 우선한다.
• 기본 서비스를 보호하려고 물리·논리 격리, 지연 기반 피드백, 가치 기반 load shedding(과부하 시 덜 중요한 요청부터 버리기)을 쓴다 확인.
• 지연, 전환, 매출의 효과 수치는 공개하지 않았다 확인(본문에 수치가 없다).

"Inference fleets must maintain enough capacity to meet demand under strict latency and reliability targets. However, demand and capacity rarely align perfectly across time, regions, resource combinations, and accelerator types." — Turning Opportunistic AI Inference Capacity Into Better Ads Recommendations (블로그), 2026-10-12

↑ 목차

레이더

• "추천 모델 스케일링 법칙" 스레드에 GEM 2026 세대를 추가 근거로 붙였다(정본 반영 건). 근거는 블로그와 Kunlun arXiv 2602.10016이다.

↑ 목차

다음에 볼 것

↑ 목차

소스 점검 메모

• X: 2026-10-12 이후 커밋은 2026-10-13 커밋 1건이고, 릴리스는 없다.
  • 커밋은 e1a0375다.
• Meta: engineering.fb.com에는 2026-10-12 이후 글이 4건 있다.
  • 위 2건 외의 두 글은 피드와 무관해 건너뛰었다. 하나는 네트워크 하드웨어를 다룬 "OCP Summit 2026"이고, 다른 하나는 라이브 송출을 다룬 "Shipping Media Over QUIC at Meta Scale for Instagram Live Ingest"다.
  • ai.meta.com/blog의 최신 글은 2026-07로, 새 글이 없다.
  • transparency.meta.com 랭킹 설명 페이지의 갱신 표시는 2023-12-31 그대로다.
  • WebSearch 교차 확인에서는 이미 정본에 있는 Threads Dear Algo·Your Algo만 나왔다.
• Netflix: netflixtechblog.com RSS의 최신 글은 2026-09-25로, 새 글이 없다. research.netflix.com publications archive의 최신 항목은 2026-02-24다.
• arXiv cs.IR: 30건을 파싱했고, 통과한 것은 0건이다.
  • 근접 탈락은 2610.10920이다. e-commerce 검색 페이지의 추천 모듈 배치를 LM으로 오프라인 평가한 RecSys 2026 OARS 워크숍 논문이고, 검색 지면에 한정되며 배포 주장이 없다.
  • 이번 응답의 최신 제출일은 2026-10-09로, 10-12 배치가 본 목록과 상당 부분 겹친다.
• 수요일이라 산업 블로그 훑기는 하지 않았다.

↑ 목차