모델 신선도 — 얼마나 자주 다시 만드는가, 그리고 왜 지면마다 다른가

Meta는 신호를 수집하고 학습하고 추천에 쓰기까지의 속도를 신선도라고 부른다. 학습 주기만이 아니라 데이터 수집부터 서빙까지 end-to-end를 가리킨다 확인(3번 절).

같은 회사 안에서도 컴포넌트별 재생성 주기가 주 단위에서 분 단위까지 4자릿수 차이가 난다. 이것은 엔지니어링 성숙도 차이가 아니라 계층마다 신선도의 경제학이 다르기 때문이다. 이 노트의 본론은 주기 표가 아니라 그 이유다.

관측된 주기 — 한 표

같은 지면 안에서도 컴포넌트마다 갱신 주기가 갈린다. Instagram Explore는 2023년 글 기준으로 랭킹 모델을 1시간마다 fine-tune하지만, item tower 임베딩은 1일마다 만든다 확인(2번 절).

출처와 인용문은 아래 각 절에 적었다.

↑ 목차

왜 다른가 — 구조 4가지

갱신 주기가 컴포넌트마다 갈리는 구조적 이유로 이 노트는 네 가지를 꼽는다 추정(1번~4번).

• 인덱스에서 빠진 아이템은 아예 노출되지 않지만, 낡은 랭커는 순위가 조금 나빠질 뿐이다(1번).
• 출력을 캐싱한 타워는 캐시 재구축 비용이 재학습 주기를 정한다(2번).
• 같은 랭커 안에서도 파라미터 종류마다 감당할 수 있는 지연이 다르다 확인(3번).
• 그래프는 무엇을 담았느냐에 따라 갱신 주기가 달라진다 추정(4번).

1. 인덱스는 커버리지 문제이고 랭커는 정확도 문제다

후보 생성 인덱스에 없는 아이템은 점수가 낮은 것이 아니라 아예 존재하지 않는다. 신규 아이템이 인덱스에 들어가기 전까지 도달 확률은 정확히 0이다. 이것은 이진 문제다.

랭킹 모델은 다르다. 하루 지난 랭커도 여전히 모든 후보에 점수를 준다. 순위가 조금 나빠질 뿐이고, 이것이 graceful degradation이다.

이 차이가 "인덱스 갱신은 분·초 단위, 랭커 재학습은 시간·일 단위"라는 비대칭을 만든 1차 원인이다 추정. 근거는 두 가지다.

• Meta가 신선도 예산을 컴포넌트별로 다르게 잡는다고 직접 서술한다(3번).
• SilverTorch(인덱스를 모델 안의 텐서로 옮긴 Meta의 retrieval 시스템)가 인덱스 신선도만을 위해 별도 스트리밍 경로를 만들었다.

Meta 자신도 신선도를 인덱스 문제로 재정의한다. 인덱스를 모델의 한 모듈로 두면, 인덱스 신선도를 지키는 일은 서빙을 멈추지 않고 프로덕션 모델의 가중치를 갱신하는 일과 같아진다는 것이다.

"With index as a model module, maintaining index freshness equates to updating the model weights of a neural network in production, at scale, without taking the model offline."

확인 — SilverTorch, engineering.fb.com, 2026-05-26

2. 출력을 캐싱하는 순간 그 타워의 재학습 주기는 캐시 재구축 비용이 정한다

Two-tower 모델(user tower와 item tower가 사용자 임베딩과 아이템 임베딩을 따로 만드는 구조)의 핵심 이점은 캐싱이다. 그런데 바로 그 캐싱이 제약이 된다.

"The main advantage of the Two Tower approach is that user and item embeddings can be cached, making inference for the Two Tower model extremely efficient." "we can use an item tower to generate embeddings for items that can be used as candidates during retrieval. And we can do this on a daily basis using an offline pipeline." "During online retrieval we use the user tower to generate user embedding on the fly by fetching the freshest user-side features."

확인 — Scaling the Instagram Explore recommendations system, Vladislav Vorotilov·Ilnur Shugaepov, 2023-08-09

같은 모델의 두 타워가 정반대 주기로 갱신된다. user tower는 요청마다 실행하므로 언제든 바꿔도 되지만, item tower를 바꾸면 인덱스 전체를 다시 만들어야 한다. 즉 item tower의 재학습 주기는 모델 품질이 아니라 인덱스 재구축 비용이 정한다.

같은 블로그는 랭킹 쪽 주기를 훨씬 짧게 잡는다. 새 데이터가 들어오는 대로 모델을 매시간 다시 학습(fine-tune)할 수 있다고 썼다.

"neural networks allow us to do this by utilizing continual online training, meaning we can re-train (fine-tune) our models every hour as soon as we have new data."

확인 — 같은 글

한 지면 안에서 랭킹은 1시간, item tower는 1일이라 24배 차이가 나고, 그 차이를 만든 것은 캐싱 여부다.

SilverTorch는 이 결합을 끊으려는 시도로 보인다 추정. 블로그에 따르면 SilverTorch는 전체 모델을 주기적으로 스냅샷으로 publish한다. 그 사이에는 스트리밍 서비스가 실시간 신호를 읽어 메모리에 올라 있는 모델의 특정 텐서를 그 자리에서 고친다. 서빙을 멈추거나 모델을 다시 배포하지 않는다.

"SilverTorch decouples freshness from the full model publish cycle through streaming updates. As model parameters get updated based on the latest training, we periodically publish the full model as a complete snapshot. Between publishes, a continuous streaming service reads real-time signals — new items, updated engagement features, changed eligibility — and applies targeted updates in-place to the specific tensors in the in-memory model." "Updates land without interrupting serving and without redeploying the model."

확인 — SilverTorch 블로그, 2026

publish 자체도 빨라졌다. GPU로 item embedding과 클러스터링을 계산해, 모델 스냅샷을 만드는 publish 시간을 며칠에서 1시간으로 줄였다 확인 — SilverTorch 논문 HTML, 2026.

"The publish leverages GPUs to compute item embeddings and clustering which reduce the publish time to build the model snapshot from days to 1 hour."

⚠ 단, 스트리밍 갱신 지연 수치는 논문에도 없다 확인 — 같은 논문. 논문은 신선한 인덱스의 세부를 후속 연구로 미뤘다: "We leave the details of fresh index for future work." 블로그가 메커니즘을 설명하고 논문이 수치를 유보한, 흔치 않은 조합이다.

3. 파라미터 종류마다 신선도 예산이 다르다

같은 랭커 안에서도 파라미터 종류마다 감당할 수 있는 갱신 지연이 다르다 확인. 이것을 가장 기계적으로 서술한 것은 Meta의 @Scale 2025 발표다. 후기 단계 랭킹(late-stage ranking, 표의 LSR) 모델에서 item embedding은 지연 0초로 갱신하면 큰 이득을 얻을 수 있고, dense parameter는 성능을 해치지 않고 수십 분 지연을 견딜 수 있다 확인.

"For instance, updates to item embeddings in late-stage ranking models can yield substantial gains with zero-second latency, whereas dense parameters can tolerate delays of tens of minutes without compromising performance."

확인 — Model Freshness Systems at Scale, Xianzheng Dou·Lujia Zhang·Vahid Jazayeri·Vivek Khurana (Meta), @Scale 2025

"모델을 얼마나 자주 재학습하는가"라는 질문 자체가 잘못됐다. 하나의 랭커 안에서도 임베딩 테이블과 dense 층의 신선도 요구가 다르다. 이유는 추정이지만 명확하다. item embedding은 새 아이템과 새 인기도를 담아서 분포가 빨리 변하고, dense 층은 "참여를 어떻게 조합할 것인가"라는 느린 함수를 담는다 추정.

같은 발표는 신선도의 정의와 세대별 개선을 함께 제시한다.

• 신선도는 신호를 수집하고 학습하고 추천에 쓰기까지 얼마나 빠른가를 가리킨다 확인 — 같은 발표: "How quickly the signals can be ingested, trained on, and used for providing recommendations is referred to as 'freshness.'"
  • 즉 신선도는 데이터 수집부터 서빙까지 end-to-end를 가리킨다. 학습 주기만을 뜻하지 않는다.
• 2021~22 시점의 모델 업데이트 지연은 약 3–6시간이었다 확인: "At this stage, the model-update latency was approximately three to six hours."
• 개선 기법을 적용한 뒤에는 신선도가 약 10–30분이 됐다 확인: "By leveraging these techniques, we achieved freshness at approximately 10-30 minutes."
• @Scale 2025 기준 현행 신선도는 O(1분)이다 확인: "This brings freshness down to O (one minute)."

4. 그래프는 무엇을 담고 있느냐가 주기를 정한다

X 팔로우 그래프의 커뮤니티 탐지는 7일 주기이고, Meta co-engagement(같은 대상에 함께 참여한 관계) 그래프의 재구축은 3시간 주기다 확인 — 아래 코드와 RankGraph-2 논문. 56배 차이가 나는 이유는 두 그래프가 담은 대상이 다르기 때문이다 추정. 팔로우 관계는 사람의 사회 구조라서 느리게 변하고, co-engagement 엣지는 콘텐츠에 붙어 있어서 콘텐츠 수명만큼 빨리 무효가 된다. 24시간 윈도로 만든 그래프를 3시간마다 다시 만든다는 것은 엣지 절반 이상이 하루 안에 무의미해진다는 뜻이다.

X의 팔로우 그래프 커뮤니티 탐지는 7일 주기다. 이 주기는 SimClusters(팔로우 그래프를 커뮤니티로 나누고 소속 정도를 벡터로 삼는 X의 임베딩)에서 계정별 커뮤니티 소속인 KnownFor를 만드는 잡에 설정돼 있다.

override val firstTime: RichDate = RichDate("2020-10-04")
override val batchIncrement: Duration = Days(7)

확인 — twitter/the-algorithm @ c54bec0, simclusters_v2/scalding/update_known_for/UpdateKnownFor20M145K2020.scala:44,46

이 숫자는 인용해도 되는 상수다. 같은 파일의 하이퍼파라미터들은 args.int(name, default) 형태라서, 코드에 적힌 값이 프로덕션 실행값과 다르다. embedding-retrieval.md에 정리한 maxNeighbors 400 vs 100 사례가 그런 경우다. 반면 batchIncrement는 override val로 스케줄 자체에 명시되어 있다. 런타임 인자로 덮이지 않는다 확인.

Meta의 co-engagement 그래프는 3시간 주기다. RankGraph-2(co-engagement 그래프를 retrieval 인덱스로 쓰는 Meta의 시스템) 논문에 따르면, 그래프는 24시간치 참여 데이터로 만들고 3시간마다 전부 다시 만든다. 파이프라인 전체가 1시간 안에 끝나서 3시간 주기가 가능하다. 논문은 시간에 극도로 민감한 상황에서는 3시간 갱신도 부족할 수 있다고 덧붙였다.

"The graph is constructed from 24 hours of engagement data and fully reconstructed every 3 hours" "The entire pipeline completes within one hour, enabling the 3-hour refresh cycle" "the 3-hour refresh may be insufficient for extremely time-sensitive scenarios"

확인 — RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation, Meta, 2026 (HTML 판. PDF 아님)

같은 논문은 서빙 단계에서 신선도 조건을 한 번 더 적용한다. 후보 풀을 최근 활동한 유저(예: 지난 15분)로 좁혔을 때 품질이 가장 좋았다 확인: "filtering the candidate pool to recently active users (e.g., past 15 minutes) yields the best quality"

3시간마다 다시 만드는 인덱스 갱신 주기와 15분 안의 활동으로 거르는 서빙 시점 필터는 별개의 조절 수단이다. 인덱스를 더 자주 만들지 못하면 조회 범위를 좁혀서 보완한다.

↑ 목차

X — 재학습 주기 대신 시간 감쇠로 신선도를 관리한다

X 공개 코드에는 모델 재학습 주기에 대한 단서가 거의 없다 확인. 대신 신선도가 감쇠 상수와 TTL로 표현된다 확인.

4세대 공개 전인 2026-08-09에는 2026 Rust 레포 전체에서 hourly / daily / retrain / continual 문자열이 0건이었다 확인 — GitHub code search, xai-org/x-algorithm, 2026-08-09

HEAD(862a123, 2026-10-17)의 phoenix/에서는 이 문자열이 멀티모달 임베딩 스냅샷 경로와 proto 필드에만 나오고, 랭커 재학습 주기를 말하는 문구는 없다 확인 — 2026-10-19 git grep.

감쇠 상수와 TTL은 아래 표와 같다. 위치는 twitter/the-algorithm @ c54bec0 기준이고, Thunder 행만 xai-org다.

같은 시스템 안에서 두 반감기가 300배 차이가 난다 확인 — InterestedInFromKnownFor.scala:291-292, summingbird/common/Configs.scala:38 (c54bec0). 취향의 반감기는 100일이고 콘텐츠의 반감기는 8시간이므로 100 × 24 ÷ 8 = 300이다. 자세한 내용은 embedding-retrieval.md에 정리했다.

X와 Meta는 신선도를 다른 층위에서 푼다 추정. Meta는 모델 파라미터를 계속 갱신하고, X 공개 코드에서 보이는 방식은 "모델과 커뮤니티는 오래 두고 입력을 시간 감쇠시킨다"에 가깝다 추정. 다만 X의 랭커 재학습 주기가 공개되지 않았을 뿐일 수 있으므로 비교로 확정하면 안 된다. 지금 있는 것은 근거의 부재이지 반증이 아니다.

Thunder(팔로우한 계정의 최신 포스트를 메모리에 담는 X 2026 코드의 인네트워크 인덱스)의 2일 보존에는 부작용이 하나 따른다. 스레드 루트가 만료되면 그 밑의 답글이 전부 사라진다. 인덱스 보존 기간이 제품 동작을 결정하는 사례다 확인 — x.md

↑ 목차

케이스: Netflix — 가장 구체적으로 공개된 재학습 주기, 그리고 신선도 압력이 낮은 이유

Netflix는 빅테크 추천 모델 가운데 재학습 주기를 가장 정확히 공개한 사례다. Foundation Model(FM, 상호작용 데이터로 사전학습하는 Netflix의 추천 모델)은 매달 처음부터 사전학습하고 매일 파인튜닝한다.

"pre-trained from scratch every month on interaction data, then fine-tuned everyday"

확인 — Integrating Netflix's Foundation Model, 2025-11

전체를 다시 만드는 월 사전학습과 증분으로 반영하는 일 파인튜닝의 이중 주기다. 이것은 3번 구조의 파라미터 종류별 신선도 예산을 모델 단위로 옮긴 형태다. 표현 공간 전체는 느리게 갱신하고 최신 데이터는 빠르게 반영한다.

GenRec(Netflix의 LLM 랭커)도 같은 패턴을 반복한다. Netflix-adapted LLM은 드물게 갱신하고, 랭킹 post-training은 자주 수행한다 확인 — GenRec 블로그 2026.

그런데 이 주기가 X나 Meta보다 느슨해도 되는 구조적 이유가 있다 추정.

• 신규 아이템이 스케줄에 따라 들어온다. UGC(사용자가 올리는 콘텐츠)는 초당 수천 개가 무작위로 생기지만, 편성 카탈로그는 출시일이 사전에 알려져 있다. "인덱스에 없으면 도달 0"이라는 1번의 커버리지 압력이 약하다. 그래서 신규 타이틀 문제는 신선도 문제가 아니라 프로모션 문제(빌보드 밴딧)로 넘어간다. 자세한 내용은 netflix.md에 있다.
• 콘텐츠 수명이 길다. 트윗 임베딩 반감기가 8시간인 세계와 달리, 영화와 시리즈는 몇 달 동안 소비된다. co-engagement 그래프를 3시간마다 다시 만들 이유가 없다.

Netflix는 추천 결과 자체를 미리 계산해 캐시한다. 이것은 구조 2의 극단적인 사례다.

• 2013년 3계층(offline/nearline/online) 구조부터 결과 프리컴퓨트가 기본이다 확인 — 2013 블로그
• 라이브 이벤트 때는 시작 전에 추천을 만들어 디바이스로 미리 내려보낸다(1억 디바이스에 1분 내) 확인 — 라이브 전달 블로그 2025

구조 2의 명제 "출력을 캐싱하면 캐시 재구축 비용이 재학습 주기를 정한다"에 비추면, 여기서는 캐싱 대상이 임베딩이 아니라 추천 리스트 전체다.

고전 세대 수치로 보정한다. TMIS 2015 논문이 오프라인 실험 프로토콜 예시로 "이틀 전까지의 데이터"를 든다 확인. 프로덕션 학습 주기 진술은 아니지만, 일 단위 이상의 지연을 정상 운영으로 전제한 서술이라서 당시 신선도 우선순위가 낮았다는 방증으로는 유효하다 추정.

↑ 목차

광고 — 신선도를 "측정 가능한 비용"으로 다룬 사례가 가장 오래됐다

광고 쪽에서는 2014년 Facebook 광고 클릭 예측 논문의 초록이 이미 freshness를 조정 가능한 요소로 나열한다 확인. 초록에 따르면 데이터 freshness, 학습률 스키마, 데이터 샘플링의 처리를 최적으로 고르면 모델이 약간 나아진다. 다만 그 효과는 고가치 피처를 추가하거나 처음부터 맞는 모델을 고르는 것보다 훨씬 작다 확인.

"Picking the optimal handling for data freshness, learning rate schema and data sampling improve the model slightly, though much less than adding a high-value feature, or picking the right model to begin with."

— Practical Lessons from Predicting Clicks on Ads at Facebook, He et al., ADKDD 2014

⚠ 이 논문의 "학습–테스트 간격이 벌어지면 NE가 얼마나 나빠지는가" 수치는 본문 PDF에만 있어서 확인하지 않았다. NE(normalized entropy)는 이 논문이 쓰는 예측 손실 지표다. 이 저장소 규칙상 PDF에서 얻은 수치는 인용하지 않는다. 초록의 정성 서술까지만 확인이다.

현행 광고 쪽 서술은 정성적이다 확인 — Meta's Generative Ads Model (GEM), 2025-11-10. GEM은 Meta 광고의 foundation model(FM)이다. 이 FM에서 지면별 vertical model(VM)로 지식을 증류하는 구조다.

• VM은 FM 학습·평가 지연에서 오는 낡은 감독 신호(stale supervision)에 자주 시달린다고 썼다 확인 — 같은 글. 같은 문장은 GEM이나 FM의 예측과 VM의 지면별 목표 사이의 불일치도 함께 든다.
  • "VMs often suffer from stale supervision caused by delays in FM training and evaluation as well as domain mismatches between GEM or FM predictions and the VMs' surface-specific objectives."
• 대응책이 student adapter다 확인. 최신 정답 데이터로 선생 모델의 출력을 다듬는 가벼운 구성 요소다: "a lightweight component that refines the teacher's outputs using the most recent ground-truth data"
• FM 자체도 continuous online training으로 계속 갱신한다 확인: "we also perform continuous online training to refresh the FMs"

여기서 신선도 문제가 한 단계 더 복잡해진다. foundation model에서 vertical model로 증류하는 구조에서는 선생 모델의 낡음이 학생 모델의 편향으로 전파된다. 그래서 학생 쪽에 최신 라벨로 보정하는 층을 따로 추가한다. 단일 모델 시대에는 없던 형태의 staleness다.

⚠ "광고 모델이 몇 시간 단위로 낡는다"는 시간 수치의 1차 출처는 찾지 못했다. 가장 가까운 근거는 @Scale 2025의 이 구절이다 추정: "three to six hours". 그러나 그것은 추천 모델 전반에 대한 서술이고 광고에 한정된 것이 아니다 추정. 광고 수치로 인용하면 안 된다.

↑ 목차

신선도가 인프라 지표에서 제품 지표로 승격됐다

Meta는 2025년부터 "당일 게시물 비중"을 실적발표에서 직접 보고한다 확인. IR 전사본 출처는 facebook.md에 있다.

SilverTorch 블로그(2026)는 같은 지표를 자기 성과로 연결한다 확인.

"The result shows up in the recency of recommended content. Same-day posts now represent a significant portion of recommendations..."

인프라 신선도와 제품 recency 지표가 같은 기준 위에 놓였다 추정. 3개 분기 연속으로 별도 지표로 보고된다는 것은 recency가 명시적인 랭킹 목표로 승격됐다는 뜻이고, 그렇다면 신선도 투자는 지연 최적화가 아니라 목적함수의 일부다 추정.

↑ 목차

이 케이스에서 일반화할 수 있는 것

갱신 주기는 모델마다 하나로 정해지지 않고, 같은 모델 안에서도 컴포넌트마다 다르다 확인(2번, 3번). 이 절의 일반화가 주기를 가르는 요인으로 꼽는 것은 캐싱 여부, 파라미터 종류, 그래프가 담은 대상, 아이템이 들어오는 형태다 추정(2번, 3번, 4번, Netflix 케이스).

• "모델을 얼마나 자주 재학습하나"는 단수형 질문이라서 답이 없다. 한 지면인 IG Explore에서도 랭커는 1시간, item tower는 1일로 갱신 주기가 다르다. 다른 시스템까지 보면 RankGraph-2 그래프는 3시간, X 캐시는 600초이고, SilverTorch 인덱스는 스트리밍으로 갱신된다. 어느 컴포넌트인지 밝히지 않은 주기 수치는 무의미하다.
• 신선도는 학습 주기가 아니라 end-to-end 지연이다. Meta의 정의는 수집, 학습, 추천에 쓰기까지를 모두 넣는다: "ingested, trained on, and used". "매시간 학습"이라고 써도 데이터 수집이 3시간 늦으면 신선도는 3시간이다.
• 파라미터 종류별로 신선도 예산이 다르다. item embedding은 지연 0초가 이득이고 dense 층은 수십 분을 견딘다. 전체 모델을 한꺼번에 자주 publish하는 것은 비싼 데다 필요도 없다.
• "전체 재구축 + 증분 갱신" 이중 주기가 반복 패턴이다. 아래 세 사례가 모두 이 구조를 따른다. 규모가 큰 표현일수록 느린 주기에 배치하고, 최신성은 빠른 주기에 맡긴다.
  • SilverTorch: 스냅샷 publish(주기 미공개), 그 사이는 스트리밍 in-place 갱신
  • Netflix FM: 월 사전학습, 일 파인튜닝
  • GenRec: 어댑티드 LLM은 드물게, post-training은 자주
• 출력을 캐싱하면 그 컴포넌트의 재학습 주기는 캐시 재구축 비용이 정한다. two-tower의 item tower가 교과서 사례다. 신선도를 높이려면 모델을 자주 학습시킬 것이 아니라 캐시 갱신 방식을 바꿔야 하고, SilverTorch의 in-place tensor 갱신이 정확히 그 답이다.
• 인덱스 신선도와 서빙 시점 필터는 별개의 조절 수단이다. RankGraph-2는 3시간마다 그래프를 다시 만들면서, 서빙에서는 15분 내 활동 유저로 후보를 좁힌다. 인덱스를 더 자주 만들지 못하면 조회 범위로 보완할 수 있다.
• 그래프의 갱신 주기는 그래프가 담은 대상의 수명을 따라간다. 팔로우 그래프는 7일이고 co-engagement 그래프는 3시간이라서 56배 차이가 난다.
• 신선도 압력은 아이템이 들어오는 형태가 정한다. 무작위 대량 유입(UGC)이면 인덱스 커버리지가 분·초 문제가 된다. 스케줄된 소량 유입(편성 카탈로그)이면 신선도가 프로모션 문제로 바뀐다. Netflix가 월과 일의 이중 주기로 감당하는 것은 기술 격차가 아니라 문제 형태의 차이다.
• 증류 구조에서는 선생의 낡음이 새로운 종류의 staleness가 된다. GEM의 student adapter가 그 대응이다.
• 주기 수치를 코드에서 확인할 때는 상수 종류를 봐야 한다. X의 batchIncrement = Days(7)은 override val이라서 인용할 수 있지만, 같은 파일의 args.int(name, default) 값들은 프로덕션 실행값이 아니다(embedding-retrieval.md).

↑ 목차

누가 이걸 쓰는가

Meta는 신선도 인프라를 가장 상세히 공개했고, Netflix는 재학습 주기를 가장 구체적으로 공개했다 확인. X에서는 감쇠 상수와 TTL은 확인했지만, 랭커 재학습 주기는 찾지 못했다 추정.

• Meta / Facebook: 신선도 인프라를 가장 상세히 공개했다 확인. 콜드스타트와 retrieval 맥락은 facebook.md에 있다.
  • @Scale 2025: 3–6시간에서 O(1분)으로
  • SilverTorch: index as model, 스냅샷 publish 소요 1시간과 스트리밍 in-place
  • RankGraph-2: 3시간
  • GEM: continuous online training과 student adapter
• Instagram Explore: 랭킹 모델은 1시간마다 fine-tune하고, item tower는 1일 주기다 확인. 이 저장소에는 아직 서비스 노트가 없다.
• X: 감쇠 상수와 TTL은 확인했고, 랭커 재학습 주기는 찾지 못했다. 근거는 x.md와 embedding-retrieval.md에 있다.
  • 감쇠·TTL 확인: SimClusters KnownFor는 7일, 트윗 임베딩은 실시간 누적, 반감기는 100일과 8시간, Thunder는 2일, 캐시 TTL은 600초다.
  • 재학습 주기 추정: 공개 레포 2세대에 학습 스케줄러가 없고, X 공식 블로그에도 진술이 없다. 미공개 내부 파이프라인까지 없다는 근거는 아니다.
• Netflix: FM은 월 사전학습에 일 파인튜닝을 더한 형태이고, 이것이 가장 구체적인 공개 주기다 확인 — netflix.md. 임베딩 스토어는 일 단위이고, 추천 결과 프리컴퓨트가 기본이다 확인 — 같은 문서. 신선도 압력 자체가 낮은 구조로 보인다 추정(Netflix 케이스).
• 그 외: 아직 조사하지 않았다. 열린 질문으로 남는다.

↑ 목차

아직 확인하지 못한 것

남은 질문은 주로 공개되지 않은 재학습 주기, 수치나 적용 범위가 빠진 공개, 지금도 유효한지 모르는 오래된 근거에 관한 것이다.

• X의 랭커(Phoenix/Navi) 재학습 주기. Phoenix 학습 코드는 4세대 공개(47c1bcd)부터 레포에 있지만, 재학습 주기를 말하는 문구는 HEAD(862a123)에도 없다 확인(x.md Phoenix 학습 절).
• SilverTorch 스트리밍 갱신의 실제 지연. 논문은 이 부분을 유보했고("future work"), 블로그도 수치를 주지 않는다.
• Meta 광고 모델의 시간 단위 staleness 비용. 1차 출처를 확보하지 못했다. 2014년 논문 본문에 실험이 있으나 PDF라서 이 저장소 규칙상 인용할 수 없다. HTML 판이나 ACM 판을 찾으면 해결된다.
• Facebook Feed 본체(비 Reels)의 랭커 재학습 주기. system card와 2021년 블로그 어디에도 나오지 않는다.
• @Scale 2025의 "O(1분)"이 어느 지면과 어느 파라미터에 적용되는지. 발표 요약만 확인했고 세부 범위는 알지 못한다.
• Instagram Explore의 1시간 fine-tune이 2026년에도 유효한지. 근거가 2023년 글 하나뿐이다.
• X의 simclusters_v2 배치 잡(KnownFor 7일 주기)이 지금도 도는지. simclusters_v2/는 2023-04 이후 한 바이트도 바뀌지 않았다. 2026 레포에는 3세대까지 SimClusters 참조가 없었고, 4세대(47c1bcd)에서 home-mixer의 SimClusters 후보 소스가 돌아왔다 확인 — home-mixer/sources/simclusters_source.rs. 코드가 남아 있다고 해서 실행되고 있는 것은 아니다.

↑ 목차

출처

• Model Freshness Systems at Scale — 2025, 발표(@Scale, Meta). Xianzheng Dou·Lujia Zhang·Vahid Jazayeri·Vivek Khurana. 신선도 정의와 세대별 수치의 1차 출처다.
• SilverTorch: Index as Model — A New Retrieval Paradigm for Recommendation Systems — 2026, 블로그.
• SilverTorch: A Unified Model-based System to Democratize Large-Scale Recommendation on GPUs — 2026, 논문. HTML 판. publish 시간이 "days to 1 hour"로 줄었다.
• RankGraph-2: Lifecycle Co-Design for Billion-Node Graph Learning in Recommendation — 2026, 논문(Meta). HTML 판. 3시간 재구축, 24시간 윈도, 15분 활성 유저 필터.
• Scaling the Instagram Explore recommendations system — 2023, 블로그. 시간당 fine-tune, item tower 일 단위.
• Meta's Generative Ads Model (GEM) — 2025, 블로그. stale supervision, student adapter.
• Practical Lessons from Predicting Clicks on Ads at Facebook — 2014, 논문(ADKDD). 초록만 확인했고 본문 수치는 인용하지 않았다.
• twitter/the-algorithm — 2025-09-03 커밋 c54bec0, 공개 소스코드. UpdateKnownFor20M145K2020.scala:44,46, InterestedInFromKnownFor.scala:286-301, summingbird/common/Configs.scala:38, Utils.scala:47-49.
• xai-org/x-algorithm — 2026, 공개 소스코드. thunder/posts/post_store.rs:521-526.
• Meta IR 전사본 (Q3 2025 / Q4 2025 / Q1 2026) — same-day 비중 수치. 링크는 facebook.md 출처 절에 있다.
• Integrating Netflix's Foundation Model — 2025, 블로그. 월 사전학습과 일 파인튜닝의 1차 출처다.
• System Architectures for Personalization and Recommendation — 2013, 블로그. offline/nearline/online 3계층.
• The Netflix Recommender System (TMIS) — 2015, 논문. 학습 데이터가 "최대 이틀 전"이다.
• Behind the Streams: Real-Time Recommendations for Live Events — 2025, 블로그. 프리컴퓨트와 1억 디바이스 1분 내 전달.

↑ 목차