Data Eng Wiki

Rebuilding LinkedIns Follows Recommendations with LLM-Based Semantic Retrieval and Ranking

12 min read

Rebuilding LinkedIn’s Follows Recommendations with LLM-Based Semantic Retrieval and Ranking

Source: linkedin.com/blog/engineering/ai | Published: 2026-08-24

한 줄 요약

휴리스틱 후보 생성 + 인기도 기반 랭킹은 인기 없지만 강한 매치를 놓치고 신규 회원에게 쓸 것이 거의 없었는데, 프로필을 서술형 프롬프트로 바꿔 LLM 임베딩을 만들고 retrieval과 ranking에 같은 임베딩을 재사용함으로써 파이프라인 전체가 하나의 이해를 공유하게 만들었다.

핵심 주장/내용

  • 문제 — 두 가지를 동시에 이해해야 한다: 좋은 매치는 회원이 무엇에 관심 있는지, 그리고 크리에이터가 무엇으로 알려져 있는지를 동시에 이해하는 데 달려 있다. 이전 시스템은 대규모 추천에 흔한 표준 다단계 아키텍처로, 휴리스틱 후보 생성과 인기도 주도 랭킹으로 그것을 근사했다
    • 인기 있고 명백한 추천에는 충분히 좋았지만 두 가지로 부족했다:
      • 우연히 인기 없었던 강한 매치를 놓쳤다 — 예: embodied AI에 대해 쓰는 덜 알려진 연구자를 가치 있게 여길 로봇공학 엔지니어
      • 아직 활동이 거의 없는 신규 회원에게는 쓸 것이 가장 적었다
  • 접근 — 하나의 공유 임베딩 공간: 각 회원과 크리에이터에 대해 프로필을 짧은 텍스트로 써서 LLM에 통과시켜 임베딩으로 만든다. 모든 회원과 크리에이터가 이 하나의 공유 공간에 앉으면 인기도가 아니라 무엇에 관한 사람인지로 찾고 순위를 매길 수 있다
  • 프로필 인코딩을 프롬프팅 작업으로 프레이밍: LinkedIn 프로필은 풍부하지만 노이즈가 많은 시맨틱 정보 원천이다 — bio, headline, tagline, skill, experience 등 여러 필드가 완전성·스타일·신호 품질에서 제각각이다. raw 프로필 텍스트를 직접 임베딩하면 노이즈가 많거나, 중복되거나, 맥락이 빈약한 표현이 된다
    • 그래서 반정형 속성을 자연어 프롬프트로 변환해 회원과 크리에이터 양쪽의 잠재 관심사와 전문성을 포착한다
    • Templated Prompting vs Narrative Prompting 두 접근을 평가하고 Narrative Prompting을 채택. 이유: 결측 필드를 자연스럽게 다루고, 미묘한 의미를 보존하고, LLM의 자연어 코퍼스 사전학습과 정렬되며, latent interest 추론을 지원 — 명시적 태그나 키워드가 없어도 관련 크리에이터와 매칭하는 데 결정적
    • 베이스 모델: 여러 오픈소스 임베딩 모델을 평가해 중간 크기의 instruction-tuned 인코더 선택. 세 가지를 out of the box로 제공 — instruction tuning을 통한 task-aware 임베딩, LinkedIn 글로벌 회원층을 위한 다국어 지원, MTEB retrieval·semantic-similarity 벤치마크에서의 경쟁력 있는 성능. 크기가 시맨틱 품질과 효율적 GPU 추론 사이 균형을 잡는다
  • Follow 예측을 위한 supervised fine-tuning: 사전학습 인코더는 강한 범용 임베딩을 내지만 follow 예측에 최적화되어 있지 않다. supervised contrastive learning으로 bi-encoder를 학습해 follow 가능성이 높은 viewer-creator 쌍이 임베딩 공간에서 더 가까이 위치하게 한다
    • bi-encoder 구조 — 파라미터를 공유하는 두 개의 별도 LLM 인코더, 하나는 viewer 프롬프트를, 다른 하나는 creator 프롬프트를 처리. 유사도는 temperature scaling을 적용한 코사인 유사도, 손실은 InfoNCE. 배치 내 positive 쌍의 유사도를 최대화하고 negative와의 유사도를 최소화
    • 프로덕션 규모의 효율화 3종:
      • PEFT (LoRA) — 가중치 갱신을 더 작은 행렬로 근사. query·key·value·dense 모듈에만 적용해 학습 가능 파라미터를 크게 줄이면서 품질 보존
      • Mixed Precision Training — 속도·메모리를 위해 16-bit, 수치 안정성이 중요한 곳(정규화 등)은 32-bit
      • Gradient Checkpointing — forward에서 선택된 activation만 저장하고 나머지는 backprop에서 재계산. 컴퓨트를 메모리 여유와 교환
  • 두 개의 EBR 파이프라인 — 레이턴시·freshness·규모 요구가 다르다:
    • 오프라인 EBR (배치 후보 생성) — 검색 레이턴시가 중요하지 않은 야간 배치용
      • Ray로 LinkedIn 분산 GPU 클러스터에 임베딩 추론을 확장. 각 워커가 공유 fine-tuned 인코더를 로드해 프롬프트 배치를 처리하고 dense 벡터 계산. Ray의 actor 모델이 GPU 메모리를 재사용하고, 오토스케일링과 fault tolerance가 수억 레코드에 걸쳐 처리량을 유지한다. 임베딩은 정규화되어 HDFS에 영속화
      • FAISS 인덱스: 적격 크리에이터 집합이 중간 규모(1천만 미만)이므로 IVFPQ나 HNSW 같은 근사 방법 대신 exact KNN 검색을 쓴다 — 이 크기의 인덱스에서는 허용 가능한 레이턴시로 정밀도를 높게 유지. 모든 임베딩을 L2 정규화하고 IndexFlatIP 를 써서 inner product = 코사인 유사도
    • 온라인 EBR (실시간) — 특히 회원 온보딩 중, viewer 신호가 신선하고 실시간 개인화가 결정적일 때
      • fine-tuned 인코더를 LinkedIn 내부 모델 호스팅 인프라 Proxima에 배포해 on-the-fly 추론. 신규 회원이 온보딩 중에 직함·위치·회사를 채우면 온라인 프롬프트 생성 레이어가 그 신호를 자연어 프롬프트로 바꾸고 Proxima가 정규화된 viewer 임베딩으로 인코딩
      • 사전 계산된 크리에이터 임베딩은 고처리량·저지연 KNN을 지원하는 호스팅 벡터 검색 서비스로 서빙
  • L2 랭킹 모델과의 통합 — 이 글의 핵심 설계 결정: 임베딩이 retrieval만이 아니라 다운스트림 L2 랭킹 모델의 피처로도 쓰인다
    • 행동·범주형·협업 필터링 피처가 많은 것을 포착하지만 profession-level 정렬에는 약하고, 상호작용 이력이 적은 cold-start 회원에게 특히 그렇다. 임베딩이 그 격차를 메운다
    • 더 중요한 것 — 스코어링 일관성 유지: EBR이 레거시 생성기와 나란히 돌 때 같은 임베딩으로 랭커를 학습시키면 랭커가 LLM 출처 후보를 그래프·인기도 출처 후보 대비 잘못 스코어링하는 것을 방지한다
    • 차원 문제와 해법: LLM 임베딩은 1,024~4,096차원으로 커서 스토리지·feature dominance·레이턴시 우려가 있다. task-aware supervised projection — 각 side(member, creator)에 하나씩 가벼운 feedforward 레이어 2개를 두어 4,096 → 64 또는 128차원으로 축소한 뒤 다른 피처와 concat한다
      • 이 레이어들이 랭킹 DNN(fully connected + ReLU + batch norm + dropout)과 함께 follow 확률에 대한 binary cross-entropy로 공동 학습되므로, 압축된 임베딩이 목적함수와 정렬된 채로 컴퓨트·메모리·온라인 스토리지를 절감한다
      • 학습 후 두 projection 레이어를 각각 standalone 서브모듈로 추출해 저차원 임베딩을 온라인에서 효율적으로 사전 계산·서빙

주요 수치 / 사실

  • 프로덕션 A/B 테스트에서 회원 세그먼트 전반에 걸쳐 follow rate의 통계적으로 유의미한 상승, 가장 큰 이득은 신규 회원 — 옛 시스템이 fallback하던 희소한 인기도 기반 제안 대신 첫 세션부터 관련 매치를 받는다
  • 적격 크리에이터 집합 1천만 미만 → exact KNN(IndexFlatIP) 이 실용적
  • 임베딩 차원 1,0244,096 → projection으로 64128
  • 결론의 핵심: “시작한 문제는 시스템이 크리에이터를 진짜로 이해하지 않은 채 순위를 매긴다는 것이었다. 회원과 크리에이터를 공유 임베딩 공간으로 옮기니 그것이 고쳐졌고, 그 임베딩을 후보 찾기와 순위 매기기 둘 다에 재사용한 것이 파이프라인 전체가 서로 다른 방향으로 당기는 대신 같은 이해에서 작동하게 만들었다. 그 일관성이 결과가 모든 세그먼트에서, 특히 옛 접근이 기댈 이력이 가장 적었던 신규 회원에게서 유지된 큰 이유다”
  • 다음 단계 둘: 더 풍부한 프롬프트 (오늘날 headline·직함·skill 같은 프로필 필드에 의존하는데, 최근 콘텐츠 engagement·브라우징 활동·연결을 더하면 프로필이 진술하는 것이 아니라 회원이 지금 관심 있는 것을 포착) / 더 표현력 있는 매칭 (bi-encoder는 회원과 크리에이터를 따로 임베딩해 코사인으로 비교하므로, late-interaction(ColBERT)이나 multi-vector 프로필 표현이 규모에서 서빙할 만큼 효율적이면서 더 세밀한 매치를 포착할 수 있다)

관련 위키

Source: 원문 보기

그래프 뷰

백링크