설문 신호 — 물어보고, 그 답으로 랭커를 학습시킨다

최종 갱신: 2026-08-09

참여 로그는 유저가 무엇을 했는지만 알려준다. 설문은 직접 묻는다. "이 포스트가 시간을 쓸 가치가 있었나", "이 영상이 네 관심사에 얼마나 맞나". 그 답을 라벨로 써서 랭커를 바꾼다.

문제는 하나로 요약된다. 설문 응답은 참여 로그보다 4자릿수 이상 희소하다.

"the model has a limited number of labeled positive and negative examples for user-item pairs, accounting for less than one ten-thousandth of the total video exposures"

[확인] — USM (TikTok), arXiv:2412.10674, 2024. 설문 커버리지를 숫자로 밝힌 유일한 1차 출처다.

Meta도 같은 말을 정성적으로만 한다: "User perception feedback collected using surveys are extremely sparse" [확인] engineering.fb.com, 2026-01-14.

이 정도 데이터로는 랭커를 직접 학습시킬 수 없다. 그래서 공개된 시스템은 전부 설문을 밀집 신호로 환산하는 중간 장치를 갖고 있다. 그 장치가 무엇인지가 이 노트의 본론이다. "설문을 랭킹에 반영한다"는 문장은 아무것도 설명하지 않는다.

지렛대 4가지 — 희소한 설문이 랭커를 움직이는 법

[확인] 각 항목은 아래에서 개별 인용.

①만 유일하게 모델을 건드리지 않는다. 나머지 셋은 전부 "설문 응답을 예측하는 함수"를 만들어 희소성을 우회한다. ②와 ③의 차이가 특히 중요하다 — ②는 원시 피처에서 설문을 새로 예측하고, ③은 이미 학습된 참여 예측들 위에 얇은 층을 얹는다. ③이 훨씬 적은 라벨로 수렴한다 [추정] (근거: 입력 차원이 헤드 개수 수준으로 줄고, 본 모델이 이미 표현학습을 끝냈다).

① 가중치를 설문으로 정한다 — Meta 2021

Meta의 value model V = Σ w·Y에서 w를 무엇으로 고르느냐의 답이 설문이다.

"the way we take each prediction into account for Juan is based on the actions that people tell us (via surveys) are more meaningful and worth their time" "People with higher correlation gain more value from that specific event, as long as we make this method incremental and control for potential confounding variables."

[확인] — engineering.fb.com, 2021-01-26

두 번째 문장이 기계적으로 더 중요하다. **"correlation"**이라고 썼다 — 설문 응답과 각 참여 이벤트의 상관을 재서 가중치를 조정한다는 뜻이다 [추정]. 즉 설문은 라벨이 아니라 가중치 캘리브레이션의 기준점으로 쓰인다. 수식도, 상관 계수도, 갱신 주기도 공개되지 않았다.

수식·헤드 구조 자체는 → multi-task-ranking.md, Meta 쪽 맥락은 → facebook.md.

② 설문 응답을 예측하는 모델을 만든다 — YouTube 2021

가장 오래되고 가장 널리 알려진 방식.

• 척도: "rate the video you watched from one to five stars" [확인]
• 후속 질문이 양쪽에 다 붙는다: 1–2점이면 왜 낮은지, 4–5점이면 "was it inspirational or meaningful?" [확인]
• valued watchtime 정의: "the time spent watching a video that you consider valuable", 4–5점 시청만 센다 [확인]
• 희소성 해법: "we trained a machine learning model to predict potential survey responses for everyone" [확인]
• 검증: "purposely hold back some of the survey responses from the training" — 홀드아웃으로 예측 정합을 상시 감시 [확인]

[확인] — On YouTube's recommendation system, Cristos Goodrow, 2021-09-15

구조적으로 이게 가장 공격적인 선택이다. 설문을 보조 신호로 쓰는 게 아니라 최적화 대상 자체를 설문 예측치로 바꿨다(watchtime → valued watchtime). 대신 대리 모델이 틀리면 목적함수 전체가 틀린다. YouTube가 홀드아웃 감시를 명시하는 이유가 이것으로 보인다 [추정].

모델 구조·투입 지점(랭커의 어느 헤드인지, 가중치가 몇인지)은 블로그에 없다. [관찰] 2026-08-09 (검사한 코퍼스: 이 절이 인용한 YouTube 블로그 본문 1건)

③ 기존 예측 위에 정렬 레이어를 얹는다 — Meta UTIS, 2026

이 저장소가 찾은 설문 신호에 대한 가장 기계적인 1차 출처다. 전부 [확인] — Adapting the Facebook Reels RecSys AI Model Based on User Feedback, engineering.fb.com, 2026-01-14.

UTIS = User True Interest Survey.

"Daily, a certain proportion of users viewing sessions on the platform are randomly chosen to display a single-question survey asking, 'To what extent does this video match your interests?' on a 1-5 scale."

핵심 메커니즘 세 문장:

"User perception feedback collected using surveys are extremely sparse but such feedback can be generalized in large scale recommendation systems using our novel model 'Perception Layer' architecture that uses existing event predictions as additional features."

"We trained a lightweight UTIS alignment model layer on the collected user survey responses using existing predictions of the main model as input features."

"The survey responses used to train our model were binarized for easy modelling and denoises variance in responses."

→ 이게 희소성 문제의 답이다. 설문 모델의 입력이 원시 피처가 아니라 본 랭킹 모델이 이미 뱉고 있는 참여 예측 벡터다. 입력 차원이 헤드 개수 수준으로 줄어드니 수만 건 규모의 라벨로도 학습이 된다 [추정]. 그리고 1–5 척도를 이진화해서 응답 분산을 죽인다 — 5단계 회귀를 포기하고 노이즈를 줄이는 쪽을 택했다.

투입 지점이 두 군데로 갈린다:

• Late Stage Ranking: "UTIS is deployed in parallel to the LSR model, providing an additional input feature into the final value formula." → 헤드가 아니라 value formula의 추가 입력항이다.
• Early Stage / retrieval: "large sequences based on user-to-item retrieval models are aligned using knowledge distillation based objectives trained on UTIS predictions from LSR as labels." → 2단 증류다. 설문 → LSR의 UTIS 예측 → 그 예측을 라벨 삼아 retrieval 모델을 정렬. 설문 응답이 직접 retrieval까지 가는 게 아니다.

성과 (전부 [확인], 같은 글):

⚠ 성과 지표 해석 주의. "high survey ratings +5.4%"는 설문 응답률 지표가 개선됐다는 뜻이고, 이 모델은 바로 그 설문을 예측하도록 학습됐다. 목적함수와 평가지표가 같은 축이다. 진짜 반증력은 engagement +5.2%가 같이 올랐다는 데 있다 — 설문 최적화가 참여를 깎지 않았다는 것 [추정].

⚠ 오프라인 baseline이 무엇인지 안 밝혔다. accuracy 59.5%의 비교 대상이 "설문 헤드 없는 본 모델"인지 "다수 클래스 예측"인지 글에 없다. [관찰] 2026-08-09 (UTIS 블로그 본문 1건)

④ 헤드로 넣되 "누가 답하는가"를 보정한다 — TikTok USM, 2024

[확인] — USM: Unbiased Survey Modeling for Limiting Negative User Experiences in Recommendation Systems, TikTok, 2024

• 설문 2종: Satisfaction("I like it" / "Neither like nor dislike it" / "I don't like it" 3점), Inappropriate(사유 선택 — sexually suggestive, disgusting, hateful, violent, spammy, uninteresting) [확인]
• 결합식이 공개된 유일한 사례다: final_s(item) = Σ wᵢ·p(surveyᵢ) + other_s(item) — 설문 예측이 참여 헤드와 나란히 가중합에 들어간다. [확인]
• 응답 편향 보정이 핵심 기여다. "users' willingness to answer and submit the survey is not uniform" → 별도의 survey-submit model이 응답 확률을 예측하고 1/P(ans|ss)로 샘플에 IPW를 건다. [확인]
• 온라인 성과: reports −1.75%, dislikes −2.57%, survey inappropriate rate −2.06% [확인]

→ ①②③이 다루지 않는 문제를 여기서만 다룬다. 설문에 답하는 사람은 무작위 표본이 아니다. 화난 사람이 더 답한다면 설문 모델은 불만을 과대추정한다. Meta UTIS 글에도 YouTube 블로그에도 이 보정에 대한 언급이 없다. [관찰] 2026-08-09 (검사한 코퍼스: 두 블로그 본문 2건)

X — 설문 프롬프트는 있는데, 랭킹으로 가는 경로가 안 보인다

X는 For You 타임라인에 설문 프롬프트를 실제로 꽂는다. 그런데 공개 코드에서 그 응답이 랭커로 흘러가는 배선을 찾을 수 없다.

있는 것 (전부 [확인], twitter/the-algorithm @ c54bec0, 2025-09-03):

• 전용 후보 파이프라인 ForYouRelevancePromptCandidatePipelineConfig.scala. 후보 ID가 문자열 리터럴 "feed-survey-prompt" (:55)
• 클라이언트 이벤트 컴포넌트명이 "for_you_survey_feed", 액션은 "served_prompts" (ClientEventsBuilder.scala:54,60,113-114)
• UI 형태: 제목 + positive / negative / neutral 3버튼, 자유 텍스트 후속 입력(RelevancePromptFollowUpTextInput), 표시 타입 4종(Normal / Compact / Large / ThumbsUpAndDown) — RelevancePromptFollowUpFeedbackType.scala, RelevancePromptDisplayType.scala
• 노출 빈도 상한이 파라미터로 박혀 있다: for_you_relevance_prompt_min_injection_interval_minutes default 1440분 = 24시간 (min 0 / max 144000분 ≈ 100일), 삽입 위치 for_you_relevance_prompt_position default 15. ForYouParam.scala:568-585
• 마스터 스위치 for_you_relevance_prompt_enable default false (:562-566), 질문·버튼 문구 4종은 전부 default "" (:587-609) — 문구가 레포에 없다. 이 레포의 일관된 패턴(값은 런타임, 형태만 코드)과 같다.
• 2026 Rust 세대도 여전히 요청한다: PromptsSource가 supported_prompt_types에 **PromptType::RELEVANCE_PROMPT**를 넣어 보낸다. [확인] — xai-org/x-algorithm, home-mixer/sources/prompts_source.rs

없는 것 — 여기가 결론이다:

1. 홈 타임라인 응답이 학습 신호 스트림(UUA)으로 구조화되지 않는다. BaseFeedbackSubmitClientEvent는 eventNamespace.page로 분기하는데 case "search" 하나만 처리하고 나머지는 case _ => None으로 버린다 (:16,39). 구조화되는 건 검색 결과 페이지의 relevance_prompt_module(→ TweetRelevantToSearch)과 did_you_find_it_module(→ DidYouFindItSearch)뿐이다. [확인]
2. 홈 쪽 로깅은 "몇 개 띄웠나"만 센다. eventValue = count(relevancePrompt) — 응답 내용이 아니라 노출 카운트다. [확인] ClientEventsBuilder.scala:113-114
3. 랭커에 설문 헤드가 없다. Phoenix 공개 체크포인트 19개, 프로덕션 22개, 2025 Navi 15개 — 어느 목록에도 설문 계열 헤드가 없다. [확인] → multi-task-ranking.md

→ [추정]: X는 설문을 랭킹 라벨이 아니라 제품 지표·수동 분석용으로 쓰거나, 소비 경로가 공개 범위 밖이다. 근거는 위 3가지의 조합이다. "X는 설문을 랭킹에 쓴다"고도 "안 쓴다"고도 단정할 수 없고, 공개된 것은 수집 장치뿐이라고만 말할 수 있다.

지면·랭커 맥락은 → x.md.

Netflix — 설문이 아니라 명시적 평점, 그리고 온보딩 취향 조사

Netflix의 공개 자료는 랜덤 표본 설문이 아니라 모든 유저가 언제든 누를 수 있는 제품 컨트롤(별점 → thumbs → two thumbs up) 쪽이다. 이건 이 노트의 주제와 구조가 다르다 — 희소하지만 무작위가 아니고, 응답 편향 성격도 다르다.

1차 출처 확보 (2026-08-09 갱신 — 이전 판의 "no primary source found"에서 승격):

• 2017 별점 → thumbs 전환 [확인] Goodbye Stars, Hello Thumbs, about.netflix.com: thumbs up = "비슷한 것 더 추천", thumbs down = "그만 추천"으로 버튼의 의미가 랭킹 동작으로 정의돼 있다. 별점 대비 평점 활동 200% 증가 — 척도를 낮출수록 응답이 는다는 실측(UTIS의 이진화, YouTube의 4–5점 축약과 같은 방향의 선택을 제품 레벨에서 한 것).
• 같은 발표의 % Match: "시청 습관·행동 분석만으로" 산출되는 표시용 점수 — 명시 평점이 랭킹의 입력이고, 화면의 퍼센트는 별개라는 분리가 명시돼 있다.
• 2022 Two Thumbs Up [확인] 발표: "정말 좋았음"을 별도 신호로 — 추천에 더 강하게 반영. 3단계 명시 척도의 복원이다(별점 5단계 → 이진 → 3단계).
• 온보딩 타이틀 픽커 [확인] TMIS 2015 §5.5 + help.netflix.com: 가입 시 좋아하는 타이틀을 고르게 하는 명시적 취향 조사가 2015 논문부터 현행 헬프 문서까지 이어진다. 선택사항이고, 건너뛰면 "다양하고 인기 있는" 기본 셋으로 시작. 콜드스타트 한정의 elicitation 장치 — 이 노트의 지렛대 분류로는 ②(신규 유저 한정의 직접 라벨 수집)에 가깝다.

랜덤 표본 설문(UTIS류)을 랭킹 라벨로 쓴다는 1차 출처는 여전히 없다. [추정] — 검사한 코퍼스는 netflixtechblog.com과 about.netflix.com의 추천 관련 글(2026-08-09 열람)이고, 미공개 자료까지 없다는 근거는 아니다. 2024 장기 만족 블로그의 보상 함수 r=f(play, complete, thumb)에 thumb이 항으로 들어 있어 명시 평점의 랭킹 소비는 확인된다 [확인] → netflix.md. 유사 기능(Meta의 Show more/less, X의 not_interested)은 설문이 아니라 유저 컨트롤로 분류하는 게 맞다 → facebook.md의 "유저 컨트롤" 절.

Meta 자체 문서 간 불일치 — Reels

UTIS 블로그는 Facebook Reels를 명시하는데, Facebook Reels system card에는 "survey"라는 단어가 한 번도 안 나온다. 카드가 나열하는 예측 태스크 10개(시청시간, 풀스크린 진입, 완주, 스킵, like, hide, "see less" 요청, 세션 시작, 다음 릴 이동 등)는 전부 참여·부정 행동이고 설문 항목이 없다.

[관찰] 2026-08-09 — 검사한 코퍼스는 fb-reels system card 본문 1건(최종 갱신 2026-06-19)이고 survey 문자열이 0회다. 대조 대상은 UTIS 블로그 2026-01-14. ⚠ 카드 인용의 유효기간 주의 → facebook.md의 "system card 인용의 유효기간" 절.

[추정] 두 가지 해석이 가능하고 구분할 근거가 없다: (a) UTIS는 헤드가 아니라 value formula의 추가 입력항이라 "예측 태스크" 목록에 안 들어간다 (블로그 서술과 일관됨), (b) system card가 갱신 시점 기준으로 아직 반영하지 않았다.

→ 이 저장소 규칙의 실전 사례다. 엔지니어링 블로그가 규제 공개 문서보다 앞서 있고, 두 문서를 합쳐야 그림이 나온다. 규제 문서를 정본으로 삼으면 UTIS가 통째로 안 보인다.

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

• "설문을 랭킹에 쓴다"는 문장은 정보가 0이다. 가중치를 정하는가(①), 대리 모델을 만드는가(②), 기존 예측 위에 얹는가(③), 헤드로 넣는가(④) — 네 개가 전부 다른 시스템이다. 어느 쪽인지 안 밝힌 서술은 인용 가치가 없다.
• 희소성 해법은 결국 "설문을 예측하는 함수"다. 라벨이 0.01% 미만이면 직접 학습이 불가능하므로, 전 노출에 적용 가능한 밀집 예측치로 환산한 뒤 그걸 랭킹에 넣는다. 세 서비스가 독립적으로 같은 형태에 도달했다.
• 입력을 본 모델의 출력으로 잡으면 라벨이 훨씬 적게 든다. Meta UTIS의 핵심이 이것이고, 이 선택이 "경량 레이어"를 가능하게 한다. 반대로 대리 모델을 원시 피처에서 새로 학습하면(YouTube 방식) 데이터가 더 필요하고 목적함수 전체가 그 모델에 걸린다.
• 응답 편향을 다루는 곳이 하나뿐이다. TikTok만 submit propensity를 IPW로 보정한다. 설문 기반 지표를 비교할 때 이 보정 유무를 확인해야 한다.
• 설문 최적화 성과는 설문 지표로 보고된다 — 순환이다. 반증력은 참여·integrity 같은 다른 축 지표가 같이 개선됐는가에만 있다.
• 1–5 척도는 그대로 안 쓰인다. Meta는 이진화, YouTube는 4–5점만 valued로 계산. 5단계 순서 정보는 둘 다 버린다.
• 설문 프롬프트가 코드에 있다고 랭킹 신호라는 뜻이 아니다. X가 정확히 그 경우다. 수집 장치와 소비 경로를 따로 확인해야 한다.

누가 이걸 쓰는가

• Facebook / Meta — 가장 깊게 공개했다. 2019-05 도입(친한 친구 목록, "worth your time", Page 관심도, Group 중요도), 2021-04 확장(inspirational / 토픽 관심 / angry 반응 많은 포스트), 2021-01 가중치 w 결정 근거, 2026-01 UTIS. 지면 맥락과 value model은 → facebook.md [확인]
• X — For You에 feed-survey-prompt를 서빙하는 파이프라인이 실재하고 2026 세대에도 살아 있다. 다만 응답이 랭킹으로 가는 경로는 공개 코드에 없다. → x.md [확인](수집) / [추정](소비 부재)
• YouTube — 1–5점 설문 → 대리 모델 → valued watchtime을 목적함수로. 이 저장소에 서비스 노트 없음. [확인]
• TikTok — 설문 헤드를 가중합에 직접 넣고 응답 편향을 IPW로 보정. 이 저장소에 서비스 노트 없음. [확인]
• Netflix — 랜덤 표본 설문의 1차 출처는 없음. 대신 명시 평점의 1차 출처가 가장 충실하다: thumbs(2017, 활동 200%↑)·two thumbs(2022)·온보딩 타이틀 픽커(2015~현행), 그리고 thumb이 보상 함수의 항으로 확인됨. → netflix.md [확인]

아직 확인 못한 것

• Meta의 설문 샘플링률. *"a certain proportion of users viewing sessions"*가 전부다. TikTok의 < 1/10,000에 대응하는 Meta 수치가 없다.
• UTIS alignment layer의 실제 구조 — 레이어 수, 입력으로 쓰는 예측 헤드가 몇 개인지, 학습 주기. 블로그에 없다.
• UTIS가 value formula에 들어갈 때의 가중치. Meta는 어느 문서에서도 w 실값을 공개한 적이 없다 → facebook.md.
• Meta가 응답 편향(누가 설문에 답하는가)을 보정하는가. 언급 자체가 없다.
• YouTube 대리 모델이 랭커의 어느 지점에 들어가는가 — 헤드인지 별도 모델인지, valued watchtime이 리트리벌까지 내려가는지.
• 2021 Meta 블로그의 "correlation" 방법론 — 설문 응답과 참여 이벤트의 상관을 어떻게 재고 얼마나 자주 갱신하는지.
• Instagram / Threads의 설문 운용 여부. 서비스 노트 자체가 아직 없다.

출처

• Adapting the Facebook Reels RecSys AI Model Based on User Feedback — 2026, 블로그(engineering.fb.com). UTIS. 설문 신호에 대한 가장 기계적인 1차 출처.
• How machine learning powers Facebook's News Feed ranking algorithm — 2021, 블로그. 설문으로 value model 가중치를 정한다는 유일한 서술.
• Using Surveys to Make News Feed More Personal — 2019, 블로그(뉴스룸). 설문 4종 도입.
• Incorporating More Feedback Into News Feed Ranking — 2021, 블로그(뉴스룸). inspirational / 토픽 / angry 확장.
• Facebook Reels system card — 2026-06-19 갱신, 규제 대응 문서. 설문 언급 0.
• On YouTube's recommendation system — 2021, 블로그(Cristos Goodrow). 1–5점 설문, valued watchtime, 대리 모델.
• USM: Unbiased Survey Modeling for Limiting Negative User Experiences in Recommendation Systems — 2024, 논문(TikTok). 설문 커버리지 수치와 결합식이 나오는 유일한 출처. PDF 아닌 HTML 판을 봤다.

Netflix (1차)

• Goodbye Stars, Hello Thumbs — 2017, 발표. thumbs 의미 정의, 활동 200%, % Match.
• Two Thumbs Up, Even Better Recommendations — 2022, 발표.
• The Netflix Recommender System (TMIS) §5.5 — 2015, 논문. 온보딩 타이틀 픽커.
• How Netflix's recommendations system works — 현행 헬프 문서. 픽커 존속 확인.

2차 (참고용 — 1차 확보로 강등 해제)

• Variety — Netflix Launches 'Two Thumbs Up' · TechCrunch — 2022, 보도. 2021 하반기 글로벌 테스트 시점 등 1차에 없는 디테일만 참고.

공개 소스코드

• twitter/the-algorithm — 2025-09-03 커밋 c54bec0. ForYouRelevancePromptCandidatePipelineConfig.scala, ForYouParam.scala:562-609, ClientEventsBuilder.scala:54-114, BaseFeedbackSubmitClientEvent.scala, ItemTypeFilterPredicates.scala, RelevancePrompt*.scala.
• xai-org/x-algorithm — 2026, home-mixer/sources/prompts_source.rs.