서론
DMM.com의 데이터 사이언스&AI 그룹에서 추천 시스템 개발을 담당하고 있는 데라이입니다.
RecSys Challenge 2026[1]에 참가하여 종합 16위, Industry Track에서는 8위라는 결과를 얻었습니다. 또한, 대회 중 분석한 데이터셋과 평가 지표를 논문[2]으로 정리하여 2026년 10월 2일에 개최된 RecSys Challenge Workshop에서 발표했습니다.
올해 대회의 주제는 사용자와의 대화를 통해 그 시점의 요구에 맞는 음악을 추천하는 '대화형 음악 추천'입니다. 곡 순위(ranking) 외에도, 추천 이유를 전달하는 자연어 응답도 생성합니다.
본 기사에서는 대회의 개요와 데이터셋, 상위 해결 방식을 소개한 후, 저의 참여 과정과 논문에서의 분석 내용을 소개하겠습니다.
대회 개요
RecSys Challenge는 추천 시스템 국제 학회 ACM RecSys에 부속되는 대회입니다.
2026년 과제에서는 각 턴(turn)마다 다음 정보를 입력으로 활용하여 곡 순위와 자연어 응답문을 생성합니다[3]。
입력 (사용 가능한 보조 데이터 포함)
- 현재 사용자 발화까지의 대화 이력: 사용자 발화, 과거 추천된 곡, 시스템 응답문
- 사용자 프로필: 연령대・성별・국가. 일부 평가 세션에서는 비공개
- 음악 메타데이터: 곡명・아티스트・앨범・태그 등
- 음악의 Embedding: 음향・앨범 이미지・태그・가사・메타데이터・협업 필터링(Collaborative Filtering) 6종류
- 사용자의 Embedding: 협업 필터링 기반 표현
출력
- 47,071곡의 카탈로그에서 선택하는 Top 20 곡 순위
- 대화의 문맥과 사용자 취향을 바탕으로 추천 이유를 설명하는 자연어 응답문
사용자 발화에는 곡명을 직접 지정하는 경우도 있고, '좀 더 차분한 곡으로'처럼 직전 추천을 받고 조건을 변경하는 경우도 있습니다. 고유 명사를 정확하게 대조할 뿐만 아니라, 대화를 통해 변화하는 의도를 파악해야 합니다.
각 턴마다 미리 준비된 대화 이력을 입력으로 받아 순위와 응답문을 생성합니다. 생성된 응답에 사용자가 답변하고, 그 상호작용에 따라 대화가 진행되는 방식은 아닙니다.
평가 지표
최종 순위는 다음 4가지 지표를 가중치로 합산한 Composite Score로 결정됩니다.
| 지표 | 가중치 | 평가 내용 |
|---|
| nDCG@20 | 50% | 정답 곡을 순위 상위에 배치했는지 |
| ... | | |
| 각 턴에는 1곡의 정답 곡이 있으며, 그 곡을 상위에 배치할수록 nDCG@20이 높아집니다. Catalog Diversity는 카탈로그 전체에 대해 제출된 순위에 포함된 서로 다른 곡이 차지하는 비율입니다. | | |
Lexical Diversity에는 응답 전체에 포함된 단어의 2-gram 다양성을 측정하는 Distinct-2가 사용됩니다. LLM-as-a-Judge 평점은 15이며, (평점 − 1) / 4로 01 사이로 정규화한 후 가산됩니다.
이 평가에서는 곡을 추천하는 능력과 선택한 곡에 대해 응답하는 능력이 하나의 점수로 종합되었습니다.
데이터셋
대회에서 사용된 것은 TalkPlayData 2를 기반으로 대회용으로 제공된 합성 대화 데이터셋인 TalkPlayData-Challenge입니다. 학습용으로는 15,199 세션, 개발용으로는 1,000 세션이 있으며, 각각 8회의 추천 턴을 포함합니다.
기반이 된 TalkPlayData 2[4]에서는 실제 청취 이력이나 곡 정보를 토대로 역할을 분담한 LLM들이 대화를 생성합니다.
TalkPlayData 2 の生成フロー
TalkPlayData 2의 생성 플로우
중심이 되는 것은 사용자 역할의 Listener LLM과 추천 시스템 역할의 Recsys LLM입니다.
각 대화에는 사용자가 달성하고자 하는 Conversation Goal이 설정됩니다. Listener LLM은 그 목표를 알고 발화하지만, Recsys LLM에게는 목표가 직접 전달되지 않습니다. Recsys LLM은 대화를 통해 요구사항을 이해하고 곡을 선택합니다.
공개 데이터에는 대화 기록과 사용자 프로필 외에도, 대화 목표(Conversation Goal)와 목표 달성 정도를 나타내는 레이블(Goal Progress)이 포함되어 있습니다[5]. 또한 보조 데이터로 곡 메타데이터, 곡의 임베딩(Embedding), 사용자의 임베딩(Embedding)도 제공됩니다.
대화 기록 데이터 샘플
대화의 흐름을 알 수 있도록 공개 학습 데이터에서 처음 2턴(turn)을 발췌했습니다. 여기서는 session_id와 각 발화의 role, turn_number, content를 보여줍니다.
{
"session_id": "b9bbaba3-c014-4435-95be-e6b92b239e37",
"conversations": [
...
1턴째 사용자 발화는 'Muse의 『Madness』를 틀어줘'와 같이 곡명과 아티스트를 지정한 요청입니다. role: "music"의 content에는 곡 ID가 들어가며, 이를 곡 메타데이터와 연결함으로써 추천된 곡의 정보를 확인할 수 있습니다. role: "assistant"의 content는 해당 곡을 안내하는 자연어 응답문입니다.
2턴째에서는 사용자가 추천을 수락한 후, '비슷하게 장대한 사운드의 Muse의 다른 곡'을 요청하고 있습니다. 이에 대해 응답문은 『Supremacy』를 안내하고 있습니다. 이처럼 후속 턴에는 직전 추천에 대한 반응과 추가 조건이 포함됩니다.
상위 해결책
상위 팀의 해결 방식을 다음 관점에 따라 정리했습니다.
- 후보 수집
Retriever - 후보 재정렬
Reranker - 자연어 응답문 생성
응답 생성기 (Response Generator) 기타 개선 사항
| 팀・종합 순위 | Retriever | Reranker | Response Generator | 기타 개선 사항 |
|---|
| hallucinated・1위※[6] | BM25, TF-IDF 등의 어휘 검색, Qwen3-Embedding, 멀티모달 Two-Tower, ItemKNN, BERT4Rec 파생 모델. | 가중치 RRF(각 Retriever의 상위 200개) → XGBoost 앙상블(38개 특징량). 2턴째 이후는 규칙으로 1위를 선택하고, 2~20위를 Reranker로 보완. | Gemma-4-26B-A4B-it (8비트). 취향・제약 요약 → 랭킹에서 독립적인 선곡・설명 → 중복 표현 감소 → 중복 2-gram 대체. | SWAG를 이용한 가상 앙상블. 최초 턴 전용 RRF. 세션 단위의 5-fold CV와, 검증 서브셋 하위 30%를 중요하게 다룬 조정. 평가 데이터 학습 활용 (아래 주석). |
| volart・2위[7] | BM25, text-embedding-3-large, LLM 곡 설명의 밀도 벡터 검색, 학습 대화 내 공기(共起). LLM을 이용한 쿼리 요약과, 곡명・아티스트 등의 일치 후보 우선 추가. | RRF(500개 후보) → LightGBM LambdaMART(69개 특징량). 검색・이력・무드 등의 특징량을 활용하며, 결측값은 0으로 보완. | Gemini-3.1-Flash-Lite로 상위 3곡을 설명. 응답 3개 후보 중 어휘의 신규성으로 선택. 독립적인 gpt-4o-mini Critic에 의한 수정과 Distinct-2를 높이는 정형구 감소. | CPU와 외부 API만으로 작동. 응답의 구조적 재작성을 통한 평가 안정화 (오프라인 검증만). |
| niwatori・3위[8] | BM25, TF-IDF, 태그, 곡명・아티스트 일치, 이력, 공기(共起)・전이 등의 14개 소스. 쿼리 측을 LoRA 조정한 Qwen3-Embedding-0.6B의 Two-Tower. | 소스별로 건수를 제한하고, 중복 제거된 후보 전체에는 상한선을 두지 않고 LightGBM LambdaRank로 순위 지정. 각 Retriever의 출현 유무・순위・스코어, 지지하는 소스 수, 대화・곡 특징량 활용. | Qwen3.6-27B에 상위 3곡의 메타데이터와 대화를 전달하여 2~3문장의 응답을 생성. 각 케이스 10개 후보 중 제출 전체의 어휘 다양성의 대리 지표로 선택. | 5-fold의 OOF 특징량. 정답 곡이 후보 내에 있는 경우 학습. TalkPlayData-1에서 공기・전계 집계만 보강. |
swyoo・4위[9]
|
BM25와 고정 Qwen3-Embedding-0.6B의 하이브리드 검색. 이력/기호 요약/조건/현재 요구를 구조화하고, QLoRA 조정된 Qwen3-Embedding-8B의 5-fold 예측을 RRF로 통합.
|각 풀(pool) 상위 100건을 통합하여 LightGBM으로 순위 지정. 풀별 순위/점수, 풀 간 RRF, 턴/요구 특징량 이용.
|GLM-5.2를 사용한 PAS로 상위 20곡의 근거 정리 및 1회 LLM 호출로 선곡/설명. 18개 예시 응답 집합에서 요구에 맞는 1예시를 프롬프트에 삽입.
|가사・음악적 특징・구조화 메타데이터로 카탈로그의 96.6% 보완. 세션 단위의 OOF(Out-of-Fold) 특징량. 곡명/인용 규칙 검증 및 수정, 정형구 감지 시 재생성.
PoliBaJukebox・5위[10]
|
BM25, Qwen3・CF-BPR・CLAP 임베딩, ALS, 조정된 BGE의 10개 소스. Qwen3 검색 결과는 RRF에 추가하지 않고, 순위/출현 유무를 특징량으로 이용.
|가중치 RRF(300 후보) → 37특징량으로 순위 지정. 상위 2곡의 점수 차이로 LightGBM LambdaRank를 전환하고 CatBoost YetiRank와 Z 스코어로 동등 가중치 통합. 재생된 곡 제외.
|1위 곡의 메타데이터를 기반으로 Gemini-3.1-Pro-Preview에서 초안 작성 → Gemini-3.5-Flash에서 수정. 근거 없는 사용자 속성/기호 기술을 금지하고, 너무 짧은 수정은 미채택.
|정답 정보(ground truth)를 사용하지 않고, 개발 데이터와 Blind A를 식별하는 Adversarial Validation으로 분포 차이 추정. 극단적인 가중치를 억제한 중요도 가중치로 Reranker 재학습.
※종합 1위의 hallucinated에 대해 주최 측 총괄 논문은, Blind B의 대화 턴을 가중치 조정이나 Reranker 학습에 활용한 점을 주석했습니다. 비공개 정답곡을 이용했다는 의미는 아니지만, 미시청 대화에 대한 일반화라는 평가 조건이 다르기 때문에 성능의 단순 비교에는 주의가 필요합니다.
Retriever
후보 생성 단계에서는 이종 후보 소스의 조합과, 대화의 문맥을 활용한 입력 구성 방식이 참고가 되었습니다. 상위 팀들은 어휘・의미・공기(co-occurrence)・전이 등을 단서로 후보를 폭넓게 수집하고 있습니다. 대화를 입력에 사용할 때는 volart는 LLM으로 여러 턴을 쿼리로 요약하고, swyoo는 재생 이력・요약・현재 요구를 구조화하여 인코더에 전달하고 있습니다.
Reranker
순위 지정에서는 후보를 통합한 후에도, 각 Retriever에서의 순위나 점수를 남기는 것이 핵심인 것 같았습니다. niwatori는 여기에 후보의 출현 유무나 여러 소스의 일치, 대화와 곡 간의 관계를 나타내는 특징량을 추가하고 있습니다. swyoo는 2개의 검색 풀의 순위・점수와 풀 간 RRF, 턴이나 요구의 특징을 사용합니다. 게다가 hallucinated는 2번째 턴 이후부터의 첫 곡을 규칙으로 선택하고, PoliBaJukebox는 상위 2곡의 점수 차이에 따라 LightGBM을 전환한 후 CatBoost와 통합하는 등, 최종 순위를 결정하는 방식도 조정했습니다.
Response Generator
응답 생성에서는 설명을 곡 정보에 근거지게 하는 것에 더해, 제출 전체 표현의 다양성 또한 개선 대상이 되고 있습니다. volart・niwatori・PoliBaJukebox는 상위 곡의 메타데이터를 근거로 응답을 생성하고, swyoo는 PAS로 곡과 설명 근거를 대응시킵니다. volart는 Critic에 의한 설명 수정 및 정형구(boilerplate) 제거를 수행하고, niwatori는 제출 전체 어휘의 다양성을 고려하여 응답 후보를 선택합니다.
랭킹과 응답 내 추천곡이 일치하는지도 확인하고 싶은 부분입니다. hallucinated는 응답 내 곡을 랭킹에서 독립적으로 선택하기 때문에, 둘이 일치한다고 보장할 수 없습니다.
평가 조건 대응 및 지표의 한계
개발 데이터에서 얻은 개선 사항을 최종 평가에서도 재현하기 위해, 각 팀은 데이터의 결손이나 분포 차이에 대응하고 있습니다. volart는 비공개된 대화 목표나 사용자 정보에 의존하는 특징량을 0으로 채워 넣음으로써 특징량의 개수를 유지합니다. PoliBaJukebox는 개발 데이터와 Blind A의 입력 정보를 통해 분포 차이를 추정하고, 학습 시 세션별 가중치를 조정하고 있습니다. 또한, niwatori나 swyoo는 이미 학습된 Retriever의 출력을 Reranker 학습에 사용할 때, 해당 세션을 학습에 사용하지 않은 모델의 출력으로부터 OOF 특징량을 생성합니다.
점수가 정체되는 원인을 대화에 포함된 정보나 평가 방법에서 생각해 보는 관점도 참고가 되었습니다. volart는 대화만으로 사용자 취향에 맞는 곡을 어느 정도 좁힐 수는 있어도, 그중에서 정답 1곡을 특정하기에는 정보가 부족하다고 판단하여 응답문 개선에 힘썼습니다. 주최 측의 총괄 논문에서도 사용자 요구에 맞는 곡이 여러 개 있음에도 불구하고, 단 하나의 곡만을 정답으로 평가하는 것의 한계점이 지적되었습니다.
본인의 노력과 논문의 내용
경진 대회에 참여했는데, 도중에 nDCG가 비정상적인 움직임을 보이는 것에気づきました 🤔
예를 들어, Qwen-Embedding을 대화문으로 Fine-tuning하여 의미적으로 맞는 곡을 후보 생성에 추가했을 때, 출력 결과를 보고 정성적으로는 좋아지고 있을 것 같은데도 점수가 그다지 개선되지 않았습니다.
또한, '대화에 등장한 아티스트의 다른 곡을 추천한다'는 로직이 이번 nDCG 평가에서 매우 효과적일 것 같다는 것에 의아함을 느꼈습니다.
본 경진 대회에서는 LLM이 생성한 합성 대화 데이터셋을 사용하며, 생성 시 Recsys LLM이 선택한 곡이 정답곡이 됩니다. 따라서 모델 개선 외에도 이 정답곡이 사용자 요구사항이나 대화 목표에 부합하는지를 조사하기로 했습니다.
구체적으로는, 합성 데이터에 기록된 정답곡과의 일치도(Item Relevance), 직전 추천에 대한 목표 진척도(Goal Progress), 응답문의 질(Response Quality)이 어떻게 대응하고 있는지를 다음 두 가지 관점에서 검증했습니다.
RQ1: Item Relevance와 Goal Progress의 정합성
Goal Progress는 Listener LLM이 직전 추천에 대해 대화 목표에 가까워졌는지 평가한 레이블입니다. 2턴째 이후의 턴 t에 붙는 레이블은, 턴 t−1의 추천에 대한 평가이며, 인간의 만족도를 나타내는 것은 아닙니다.
데이터셋에는 다른 아티스트를 요구했음에도 불구하고 같은 아티스트의 곡이 정답인 대화가 있었습니다. 다음은 그 예시입니다.
| 대화 내 위치 | 내용 |
|---|
| 2턴 추천곡 | Express Yourself — Madonna |
| ... | |
| 응답문도 'Burning Up'을 안내하고 있어, 곡과 설명은 대응하지만, 'Madonna가 아닌 다른 아티스트'라는 요구에는 따르지 않았습니다. | |
이 경향을 조사하기 위해 명시적인 아티스트 변경 요구를 규칙으로 추출하여 그 직후의 정답곡을 집계했습니다. 대화 후반부로 갈수록 이미 등장한 아티스트가 늘어나는 영향을 억제하기 위해, 대화 위치 분포를 맞춰 비교하고 세션 단위의 Bootstrap으로 불확실성도 평가했습니다.
| 케이스 | 다음 정답곡이, 대화 내 이미 등장한 아티스트를 반복하는 비율 |
|---|
| 명시적 아티스트 변경 요구 있음 | 76.0% |
| 변경 요구 없음 | 63.1% |
변경 요구가 있는 케이스에서도 약 4분의 3의 정답곡이 이미 등장한 아티스트의 곡이었습니다.
나아가, 다음 세 가지 조건을 모두 충족하는 케이스로 한정하여 조사했습니다.
- 사용자가 다른 아티스트로 변경을 명시적으로 요구함
- 직전 추천곡의 아티스트가 그 이전에 대화 내에서 추천된 적이 있음
- Listener LLM이, 그 직전 추천을 '목표에 가까워지지 않았다' (
DOES_NOT_MOVE_TOWARD_GOAL)고 평가함
이 5,278건 중, 다음 정답곡도 직전과 같은 아티스트였던 것은 4,529건(85.8%)이었습니다. 즉, 사용자가 변경을 요구하고 직전 추천마저 목표에 가까워지지 않았다고 평가된 케이스에서도, 정답곡은 같은 아티스트를 반복하는 경우가 많았습니다.
상기 분석을 통해, 정답곡을 맞히는 것과 사용자 요구사항이나 대화 목표에 부합하는 것 사이의 괴리감을 발견했습니다.
RQ2: 랭킹을 고정했을 때 응답문의 영향
Blind A의 Top 20 곡과 순서를 고정하고, 응답 문구만 변경하여 공식 평가에 제출했습니다.
| 응답 구성 | Lexical Diversity | LLM Judge | Composite Score |
|---|
| 초기 응답 | 0.5925 | 4.05 | 0.5086 |
| ... | 4.30 | 0.5494 | |
| Claude 기반 메타데이터를 사용한 긴 응답 | 0.7983 | 4.90 | 0.5929 |
| Gemini Pro 및 메타데이터 기반 응답 | 0.7204 | 4.30 | 0.5401 |
초기 응답 대비 가장 높은 구성에서 Composite Score가 0.0843 상승했습니다. nDCG@20의 가중치가 50%이므로, 평가식 상으로는 nDCG@20을 약 0.17 개선하는 것과 동등한 기여임을 알 수 있었습니다.
응답 문구 개선을 평가에 반영하는 것 자체는 타당합니다. 다만, Composite Score의 상승만으로는 선곡의 정확도, 설명의 질, 표현의 다양성 중 어느 부분이 개선되었는지 알 수 없습니다. 응답 문구가 높게 평가되더라도, 추천 곡이 사용자의 요구사항과 일치하는지, 설명이 실제 곡 정보와 일치하는지는 별도로 확인해야 합니다.
평가에 대한 제안
상술한 결과를 바탕으로 논문에서는 nDCG나 LLM-as-a-Judge를 보완하기 위해 다음 3가지를 제안했습니다.
- Goal Adherence 개별 보고: '다른 아티스트로'와 같이 아티스트, 장르, 시대, 템포, 신규성 등에 대한 명시적인 변경 요구에 추천이 따르는지 평가합니다. 이번 탐지 규칙에서는 아티스트 변경을 다루었습니다. -
- Ranking–Response Consistency 평가: 추천 곡의 메타데이터를 Judge에게 전달하여, 설명이 그 곡 정보와 일치하는지를 문장 품질과는 별개로 평가합니다. -
- Judge 교정 및 조건별 결과 공개: 응답의 길이/짧음, 사용자 정보 유무, 추천 곡과 설명의 일치/불일치 등의 조건을 포괄한 수작업 평가를 통해 Judge의 타당성을 확인합니다.
『Madonna』의 예시처럼, 곡과 설명이 대응하더라도 요구사항을 따르고 있다고는 한정할 수 없습니다. 정답 곡과의 일치성, 요구사항 적합성, 응답 문구의 질, 곡과 설명의 일관성을 나누어 볼 필요가 있다고 생각합니다.
논문 채택 및 현지 발표
이번 분석을 정리한 논문은 RecSys Challenge Workshop에 채택되었습니다. 2026년 10월 2일 프로그램에서는 정답 레이블과 요구사항의 관계, 지표의 일관성을 다루는 'Auditing the benchmark' 세션에서 발표했습니다.
Workshop에는 참가 팀의 논문 발표 외에도 Keynote가 2개 있었으므로, 함께 강연 내용을 소개합니다.
Spotify: 대화형 음악 추천 에이전트 구축 및 개선
Spotify의 Enrico Palumbo 씨가 진행한 Keynote는 'From Language to Items: Building Conversational Recommendation Experiences at Spotify'였습니다. Spotify에서는 대화를 통해 선곡이나 추가 조건 지정이 가능한 'Talk to Spotify' [11]와, 자신의 취향이 어떻게 해석되고 있는지 확인하고 자연어로 Home 추천을 조정할 수 있는 'Taste Profile' [12]이 제공됩니다.
강연에서는 아이템 ID를 직접 생성하는 GenRec과, 기존의 검색/추천 기능을 툴로 호출하는 AgentRec 두 가지 모두 자세히 소개되었습니다.
GenRec은 아이템을 나타내는 Semantic ID와 자연어를 같은 시퀀스로 다루며, 추천/검색/추천 이유 생성/사용자 관심사 요약을 단일 모델에서 실행합니다. 자연어 지시를 통해 태스크나 출력 형식을 지정할 수 있으며, 아이템 생성 시에는 Constrained Decoding을 통해 카탈로그에 실제로 존재하는 ID만 출력하는 방식입니다.
AgentRec의 경우, ReAct 기반 구성이나 사용자 의도에 따라 여러 검색/추천 툴을 병렬로 호출하는 Parallel Fusion Router가 설명되었습니다.
AgentRec의 평가 및 개선 과정에서 이번 대회와 공통적으로 사용된 방식은 합성 대화(Synthetic Conversation)와 LLM-as-a-Judge를 활용하는 것이었습니다. RecSys 2026 관련 논문에서는, 합성 대화 100건을 5명의 주석가(Annotator)가 검토했으며, Judge의 판정이 인간 평가와 일치한다고 평가된 비율은 97%였습니다. 또한, 성공 및 실패한 실행 사례를 비교하고 코딩 에이전트(Coding Agent)를 통해 프롬프트나 도구 설명을 수정하는 Self-Improvement Loop를 거치면서, 충분히 수동으로 조정된 프롬프트 대비 pass@1 점수가 상대적으로 8% 개선되었습니다. 개선 예시로는 대화 중간 단계에서의 의도 해석이나 모호한 장르명 해소 등이 언급되었습니다[13].
Netflix Prize: 20년 후의 재도전과 AI를 활용한 실험
또 다른 주제는 Taboola의 Domonkos Tikk와 Istvan Pilaszy가 발표한 "Netflix Prize revisited: a hard problem even after 20 years"입니다. 이 연구는 Netflix Prize에 참여했던 전 Gravity 팀이 현재의 컴퓨팅 환경, 심층 학습(Deep Learning), AI 개발 지원을 활용하여 당시의 과제에 다시 도전한 내용이었습니다[14].
발표에서는 비교적 단순한 모델이 높은 정확도를 보였으며, 심층 학습 모델 중에서는 AutoEncoder가 가장 좋았다고 소개되었습니다. 실 서비스에서 사용 가능한 풍부한 특징량(Feature)이나 다양한 행동 로그가 Netflix Prize에서는 활용할 수 없다는 점 역시 모델 성능을 고려하는 배경으로 제시되었습니다.
AI 활용 사례로는 Claude Code를 이용한 105개 특징량 구현이나, 인간이 개선 방향성을 정하고 AI가 183건의 실험을 진행하는 시도 등이 소개되었습니다. 실험에 사용된 Rust 코드도 공개되었습니다[15].
결론
RecSys Challenge 2026에서는 상위 해결책들을 통해 서로 다른 Retriever를 조합하는 것, 후보 출처(Candidate Source)를 Reranker까지 남겨두는 것, 그리고 응답 생성을 독립적으로 개선하는 것의 중요성을 배웠습니다.
대회에서는 주어진 평가 지표를 어떻게 개선할지에 집중하는 경우가 많다고 생각합니다. 이번에는 모델을 개선하는 과정에서 느낀 의문점을 출발점으로 삼아, "그 지표로 개선되었다는 것이 사용자에게 좋은 추천과 어떻게 관련되는가"를 탐구하는 기회가 되었습니다.
데이터를 다시 읽고 평가의 전제를 확인하며 논문으로 발표할 때까지 진행할 수 있었던 점이 이번 대회에서 얻은 큰 배움이었습니다.
앞으로의 레코멘드 시스템 개발에서도 단순히 점수를 높이는 것 외에, 그 점수가 무엇을 나타내는지, 어떤 측면이 개선되었는지를 확인해 나가고 싶습니다.
마지막으로, 대회 종료 후 급하게 논문 작성부터 현지 발표로 진행하는 과정에서 출장비 조정 등을 도와주시고 발표 기회를 뒷받침해 주신 상사분께 감사드립니다. 또한 업무 조정을 유연하게 대응해 준 팀원들에게도 감사합니다. 여러분의 지지 덕분에 안심하고 논문 작성과 현지 발표에 임할 수 있었습니다.
RecSys Challenge 2026 공식 사이트: https://www.recsyschallenge.com/2026/ ↩︎
Auditing Alignment among Item Relevance, Goal Progress, and LLM-Judged Responses in Music-CRS: https://dl.acm.org/doi/10.1145/3842413.3842423 ↩︎
Overview and Analysis of the RecSys Challenge 2026: Conversational Music Recommendation: https://arxiv.org/abs/2609.33045 ↩︎
TalkPlayData 2: An Agentic Synthetic Data Pipeline for Multimodal Conversational Music Recommendation: https://arxiv.org/abs/2509.09685 ↩︎
TalkPlayData-Challenge-Dataset: https://huggingface.co/datasets/talkpl-ai/TalkPlayData-Challenge-Dataset ↩︎
