[REFACTOR] 추천 후보 탐색/RRF/MMR 책임 분리

[Dimo-2562]

Parent: #419

✨ 리팩토링 할 부분

LlmRecommendationService의 후보 탐색, RRF 변환, MMR 적용, 저장 orchestration 책임을 분리한다.

🏷️ 도메인 (해당하는 것에 체크)

• 📝 domain:post (게시글)
• 👤 domain:useraccount (사용자 계정)
• 🧠 domain:personalization (개인화 프로필)
• 🏢 domain:source (테크블로그 출처)
• 🔍 domain:search (검색)
• 🔔 domain:notification (알림)
• 📊 domain:recommendation (추천)
• 🎯 domain:activity (사용자 활동)
• 🔐 domain:auth (인증/보안)
• 🌐 infra (인프라/배포)

📌 현재 코드의 문제점

• LlmRecommendationService가 Elasticsearch kNN/BM25 검색, RRF, time decay, MMR 호출, 추천 이력화/저장을 모두 담당한다.
• 테스트 대상이 커져 edge case를 좁게 검증하기 어렵다.
• 후보 탐색 정책과 추천 목록 저장 정책이 한 클래스에 섞여 있다.

🎯 리팩토링 방향

• 후보 탐색 책임을 별도 컴포넌트로 분리한다.
  • ES kNN/BM25 실행
  • 읽은 게시글 제외 filter 적용
• RRF/후보 조립 책임을 별도 컴포넌트로 분리한다.
  • vector hits + keyword hits → MmrCandidate
  • time decay 반영
  • summary embedding 없는 후보 제외
• MmrService는 MMR 선택 책임으로 유지한다.
• LlmRecommendationService는 프로필 확인 → 후보 탐색 → MMR → RecommendationSet 교체 orchestration만 담당한다.

💡 기대 효과

• 가독성 향상
• 성능 개선
• 유지보수성 향상
• 코드 중복 제거
• 기타: 추천 알고리즘 단계별 테스트 용이성 향상

[Dimo-2562]

#452 / PR #455 이후 구현 기준점

• 현재 위치: com.techfork.recommendation.application.ranking.MmrService
• LlmRecommendationService에 남은 분리 대상 메서드: searchCandidates, applyRrf, mapToMmrCandidate
• MmrService는 현재 @Service이며 RecommendationProperties, VectorUtil, 내부 Random에 직접 의존한다.
• 따라서 이 이슈에서 MMR을 domain policy로 판단한다면 단순 패키지 이동보다 알고리즘 입력값(lambda, finalSize, topK, embedding weights)과 랜덤 선택 전략을 명시적 인자로 분리해 Spring/config 의존이 없는 순수 정책으로 만드는 방향을 먼저 검토한다.
• 후보 탐색/ES hit 변환은 infrastructure/application 경계에 남기고, MmrCandidate/MmrResult의 소유 위치를 책임 분리 결과에 맞춰 결정한다.
• 기존 회귀 기준은 recommendation.application.ranking.MmrServiceTest와 recommendation.application.generation.LlmRecommendationServiceTest다.

#452에서는 재이동을 피하기 위해 application.ranking에 임시 배치했으며, 최종 소유권 결정은 이 이슈 범위다.