1부는 여기에서
LLM with Recommender System 논문 리뷰 - 1부 [M6-Rec: Generative Pretrained Language Models are Open-Ended Recommender Syste
원문 보기 : https://arxiv.org/pdf/2205.08084.pdf 오랜만에 추천 관련 기술 논문을 두 개 정도 읽게 됐다. 업무 연차가 올라가다보니, 새로운 기술을 접목하거나 논문을 읽어보는 데 할
yamalab.tistory.com
RS(Recommender System) 분야에 대한 연구는 이제(원래도 그랬지만) 서비스를 가진 기업 단위로만 유의미하게 이루어지고 있다. 그도 그럴 것이, 실제 서비스에서 발생하는 로그데이터로 이 분야를 연구하는 것 말고는 별다른 의미도 없을 뿐더러 사용처도 없기 때문.
그 와중에 ChatGPT가 쏘아올린 LLM(Large Language Model) 만능주의는 RS 관련 페이퍼들을 온통 LLM으로 도배하도록 만들고 있다. 개인적으로 LLM이라는 기술은 “오 신기한데?” 에서 아직 크게 벗어나지 못했다고 생각한다. 인터넷이 생겨날 때, 그리고 스마트폰이 생겨날 때와 같이 세상의 패러다임을 바꿀 정도의 AI 기술은 아니라는 것이 내 사견이다. 이 기술이 로봇 공학이라던지, 무언가 물리적 형태와 결합된 killer 서비스가 나와야 가능하지 않을까?
아무튼 각설하고 다시 RS에 대한 이야기로 돌아오면, “그래서 RS 기술이 나아가야 할 방향은 결국 LLM과의 접목인가?” 라는 주제로 생각해봤을 때는, 이건 Yes 라고 답할 수 있을 것 같다. 개인적으로 생각하는 지구상에서 가장 정확한 추천은 도메인 지식을 아주 잘 이해하고 있는 전문가와, 이를 추천 받는 사람이 나누는 대화 속에서 도출되는 추천이기 때문이다.
예를 하나 들어보자. 로맨스 영화를 좋아하지만 한국식 즙짜기 신파 로맨스 영화는 싫고, <해리포터>나 <반지의 제왕> 같은 판타지 영화는 또 곧잘 보는 사람에게 추천할 만한 작품은 아마도 <이터널 선샤인> 같은 작품일 것이다. 추천에서 사용된 정보는 다음과 같다. 이 사람이 “즙짜기 신파 로맨스를 싫어한다” 라는 주관적 사실을 차용하는 것과, “해리포터나 반지의 제왕 같은 작품을 재밌게 봤기 때문에 상상력과 허구가 결합된 스토리를 좋아하는 경향이 있다”는 숨은 맥락을 파악하는 일이다. 그리고 <이터널 선샤인>이 그 두가지 조건을 모두 충족하는 컨텐츠라는 것을 이해하고 있어야 한다. 이건 영화의 맥락을 정확히 이해하는 전문가(혹은 추천자)가 소비자와 직접 대화를 나누는 것 밖에 방법이 없다.
그래서 전통적인 추천 방식으로는 이게 많이 어렵다. 가장 재현하기 좋은 상황이라고 한다면, 해리포터와 반지의 제왕을 시청한 이력이 남아있는 유저가 OTT 검색창에 “로맨스”를 입력하는 상황이라고 가정할 수 있다. 그러나 이 상황이 재현되기도 힘들 뿐더러, 이 모든 맥락을 고려하기 위해서는 인간 수준의 semantic embedding 및 retrieval 기술과 스토리텔링이 적용되어야 한다.
그러나 LLM은 이 문제를 근본적으로 해결 가능한 기술이다. 기존의 RS 방식(일반적으로는 categorized 된 피처를 활용하여 CTR prediction task를 수행하는 것)과 달리 LLM은 “즙짜기 신파 로맨스를 싫어한다”, “상상력과 허구가 결합된 스토리를 좋아하는 경향이 있다”는 두 가지 사실을, 시청 이력에 남아있는 컨텐츠의 메타 데이터를 문장 형태로 해석함으로써 어느정도 추론이 가능하다.
서론이 길었지만, 앞으로 내가 먹고살려면 LLM이 결합된 모델을 공부해야 한다는 게(..) 요지이다. 그래서 지난 번에 리뷰했던 논문의 연장선이 아니라, 사고를 오히려 위로 확장시켜 전반적인 생태계를 다루는 서베이를 리뷰해보았다.
[A Survey on Large Language Models forRecommendation]
0. Abstract
RS에서 LLM이라는 기술은 점점 강력하게 결합되고 있다. 본 서베이에서는 LLM-based RS를 잘 이해하기 위해 가장 큰 두 개의 패러다임을 기준으로 기술을 분류하여 기술하고 있다. 첫 번째는 Discriminative LLM for Recommendation (DLLM4Rec), 그리고 두 번째는 Generative LLM for Recommendation (GLLM4Rec)이다.
1. Introduction
RS에 LLM을 통합하는 주요 이점은 텍스트 특징의 고품질 표현을 추출하고, 모델에 내재된 방대한 외부 지식을 활용할 수 있다는 점이다. 또한 추천 시스템의 data sparsity 문제를 해결할 수 있는 좋은 대안이 될 수 있는데, 텍스트의 형태로 모델 추론이 진행되기 때문에 unseen candidate에 대해서도 유연한 대처가 가능하기 때문이다 (역주).
또한 기존에 사용되던 discriminative model(e.g. BERT) 같은 경우와 다르게, generative model(e.g. GPT)은 추천 시스템과 융합될 경우 언어 생성 능력을 활용하여 추천의 설명 가능성을 확장시킬 수 있다. 이를 통해 XAI를 더 잘 수행하며, 개인화된 프롬프트와 연결될 확장성 또한 가지고 있기 때문에 사용자 경험을 더 좋게 만들 여지가 크다고 할 수 있다.
앞으로 본 서베이에서는 RS with LLM을 크게 세 가지 패러다임으로 분류하여 설명할 것이고, 이는 generative model의 큰 대분류에 속하는 방법들이 될 것이다.
2. Modeling Paradigms and Taxonomy
LLM 모델의 기본적인 형태는 transformer block의 구성이라고 할 수 있다. GPT나 LLaMA 같은 유명 모델에서 사용하는 방식이기도 하다. input은 token embedding, 혹은 position embedding으로 구성된 구조를 가지고 있고, 결과물 역시 embeddings or tokens 으로 output module에서 생성된다. 그리고 본 서베이에서는 이 방식을 3가지 패러다임으로 나누어서 소개한다.
1) LLM Embeddings + RS
이 패러다임은 LLM을 단순 임베딩 모델로 활용하는 것이다. 아이템과 사용자 input을 LLM에 입력하여 임베딩을 생성하는 구조. 이렇게 생성된 지식 기반 임베딩은 전통적인 RS 모델에서 활용하는 것이 목적이라고 할 수 있다.
2) LLM Tokens + RS
위 패러다임과 유사한 패러다임이지만, 임베딩 벡터를 추출하는 것이 아닌 token을 생성하는 것을 목적으로 한다. 생성된 토큰은 semantic mining을 비롯한 RS의 의사결정 과정에 사용된다.
3) LLM as RS
앞선 두 패러다임과 달리, 이 방법은 LLM을 추천 엔진 그 자체로 활용한다. 입력 시퀀스로 주로 프로필 정보, 행동 프롬프트 및 작업 지침이 활용되며, 아래의 그림을 보는 것이 가장 직관적으로 이해될 것이다.
3. Discriminative LLMs for Recommendation
RS에서 Discriminative LLM(이하 DLLM)은 주로 BERT 계열 모델을 의미한다. DLLM은 다양한 분야에서 downstream task로 활용되고 있으며, 주로 임베딩 모델의 backbone 으로 활용된다. 이는 추천 시스템에서도 마찬가지이다.
대부분의 기존 연구는 BERT와 같은 사전 학습 모델의 표현을 도메인별 데이터와 정렬하기 위해 fine-tuning 전략을 사용한다.
3.1 Fine-tuning
파인 튜닝의 핵심 아이디어는 대규모 텍스트 데이터에서 풍부한 언어적 표현을 학습한 언어 모델을 특정 작업이나 도메인에 맞게 적응시키는 데 있다. 이를 위해 모델을 해당 작업에 특화된 데이터로 추가 학습한다. 아래의 그림을 보면 더 직관적으로 이해할 수 있다.
기존 연구중에서는 U-BERT 라는 모델이 언급 대상이 되는데, 이 모델을 예로 드는 이유는 레이블이 없는 유저 데이터를 사전학습 하기위한 방법을 소개하기 위함인듯 하다(역주). 이를 설명하면서 사용자와 아이템의 리뷰 간의 implicit한 의미 관계를 포착하기 위해 도입된 review co-matching layer도 언급한다.
Fine-tuning을 통해 사전학습이 완료된 BERT 모델은 ranking task 에도 SOTA의 성능을 많이 냈다고 하는데, BECR 이라는 모델은 코드 예제 추천이라는 특정 task에서, 자연어 쿼리(BERT + LSH)를 사용하는 것이 API 기반 쿼리보다 더 나은 랭킹 결과를 제공함을 밝혔다고 한다.
그리고 BERT4REC과 같은 specific한 task 에서도 BERT 기반 파인 튜닝 메커니즘이 사용되었다. 그러나 이전 포스팅에서 리뷰했듯이, 이 모델은 LLM의 장점을 활용한 모델은 아니기 때문에 이 페이퍼에서도 언급만 할 뿐 주요하게 다루지는 않는다.
그리고 여러가지 모델들이 언급되지만 너무 아카데믹하게 리뷰가 되는 것을 막기 위해 야마GPT로 요약하자면, MoRec 모델을 언급한 것 정도를 보면 될 것 같다. MoRec 모델은 아이템을 임베딩 할 때, ID를 임베딩 하는 것과 LLM 기반의 purely modality-based 임베딩을 하는 것 간의 차이를 비교하며 LLM 기반의 임베딩이 anti-cold start 측면에서 더 낫다는 것을 증명한 논문이다.
그래서 요약하자면 BERT 기반의 파인 튜닝을 RS에 접목하면 추천의 정확도가 올라갈 뿐만 아니라, cold-start 문제에 robust한 추천 모델이 된다는 것이다.
3.2 Prompt-tuning
기존의 LLM을 다양한 다운스트림 추천 작업에 적응시키기 위해 특정 목적 함수를 설계하는 대신, 프롬프트 튜닝은 추천 튜닝 목표를 사전 학습된 손실(pre-trained loss)과 정렬시키는 것을 목표로 한다. 이는 hard, soft prompt를 사용하여 이루어진다. 이러한 프롬프트 튜닝에 관한 자세한 설명은 아래 블로그를 참고하면 좋다.
https://blog.harampark.com/blog/llm-prompt-tuning/
요약하면, 프롬프트 튜닝은 LLM 모델 자체의 파라미터는 건드리지 않고 프롬프트를 base 모델에 맞게 학습시키는 방법이라고 할 수 있는데, 파인 튜닝에 비해 조금 간단한 작업이라고 보면 될 것 같다. 주요 차이점을 요약하면 아래와 같다(역주).
| 특징 | Fine-tuning | Prompt Tuning |
| 모델 파라미터 | 전체 파라미터 업데이트 | 고정 (프롬프트만 변경) |
| 학습 데이터 요구량 | 많을수록 유리 | 적은 데이터로도 가능 |
| 전이 학습(재사용성) | 작업별로 모델 다시 학습 필요 | 프롬프트만 수정하여 다양한 작업에 활용 가능 |
| 컴퓨팅 비용 | 높음 | 낮음 |
| 적용 방식 | 작업별로 모델을 특화 | 프롬프트 설계를 통해 작업에 적응 |
| 추천 시스템에서의 활용 | 사용자-아이템 상호작용 데이터를 통한 모델 재학습 | 프롬프트로 사용자 선호를 모델의 사전 학습 목표와 정렬 |
4. Generative LLMs for Recommendation
DLLM 기반 접근법이 LLM이 학습한 표현을 추천 도메인에 정렬시키는 데 초점을 맞추는 반면, GLLM 기반 접근법은 추천 작업을 자연어 작업으로 변환한 뒤, in-context learning, prompt tuning, instruction tuning 등의 기술을 적용하여 LLM이 직접 추천 결과를 생성하도록 유도한다. 그리고 GLLM은 또 다시 두개의 패러다임으로 나뉘는데, 하나는 튜닝을 하지 않는 non-tuning 방식이고, 하나는 DLLM과 같은 튜닝 기반의 패러다임이다.
4.1) Non-tuning Paradigm
4.1.1) Prompting
Is chatgpt a good recommender? A preliminary study 라는 논문에서는 ChatGPT의 추천 작업을 일반적인 추천 작업 5개의 기준(평점 예측, 순차적 추천, 직접 추천, 설명 생성, 리뷰 요약)으로 나눠서 체계적으로 평가하였다. 이를 통해 일반 추천 프롬프트 구성 프레임워크를 제안하였고, 해당 내용은 다음과 같다.
1) 작업 설명(task description): 추천 작업을 자연어 처리 작업으로 적응시킴.
2) 행동 삽입(behavior injection): 사용자-아이템 상호작용을 통합하여 LLM이 사용자 선호와 요구를 더 잘 파악할 수 있도록 지원.
3) 형식 표시(format indicator): 출력 형식을 제한하여 추천 결과를 더 이해하기 쉽고 평가 가능하게 만듦.
그리고 몇가지 더 언급한 논문이 있지만, 아주 아카데믹한 내용이기 때문에, 위 내용 정도만 간략하게 언급하도록 하겠다(역주). 조금 더 downstream research로 내려오면, 다음과 같은 세 가지 프롬프트 입력 전략을 평가하는 논문들을 언급하는데, 전략은 아래와 같다.
1) Items only: 아이템 속성만 포함.
2) Language only: 사용자의 선호를 언어로만 기술.
3) Language + Items: 언어와 아이템 속성을 결합.
이 세 가지 전략을 평가하는 여러 논문들과 방법론들을 설명하면서 내리는 서베이의 결론은 첫번째, 언어 모델 기반 추천에서 제로샷 및 퓨샷 전략은 효율적이며 콜드스타트 문제 해결에 유용하다는 것이다. 그리고 두번째는 결합 데이터를 활용한 모델 학습은 베이스라인과 비교해 우수한 성능을 발휘한다는 것이다.
본문에서 언급하는 46번부터 51번까지의 레퍼런스는, 모델의 구조와 파인튜닝의 지엽적인 방법 변경을 이용하여 성능 향상을 이끌어내는 연구들과 그 시사점들을 간단하게 나열한다. 다시 또 3줄 요약하면 다음과 같다.
1) 특정 작업 맞춤형 프롬프트 설계는 추천 성능과 해석 가능성을 동시에 향상시킬 수 있음.
2) 슬라이딩 윈도우 전략은 LLM의 입력 제한을 극복하며, 긴 후보 목록 처리에 효과적.
3) 대화형 추천에서 LLM은 추가 학습 없이도 강력한 성능을 발휘하며, 실제 대화 데이터를 활용한 새로운 데이터셋이 발전 가능성을 제시.
다음으로 언급하는 52번부터 60번까지의 레퍼런스는 LLMs를 추천 시스템 자체로 사용하는 것 외에, 기존 추천 시스템을 개선하기 위해 모델 feature를 생성하거나 보강하는 데 활용하는 연구 결과들이다. 그리고 61번부터 72번까지의 레퍼런스는 추천 결과를 생성하는 LLM이 아닌, 추천시스템 자체를 설계하는 컨트롤러 역할로써의 LLM을 조명했는데, 이는 내 개인적인 기준에서는 페이퍼의 큰 맥락에서 조금 벗어나 있다고 생각하기 때문에 리뷰 내용은 생략하도록 하겠다.
결론적으로 4.1 문단의 서베이 내용을 요약하면, LLM의 제로샷(zero-shot) 능력은 추천이라는 도메인에 강력한 도구가 될 것이고, LLM으로 추천 작업을 수행하는 데 핵심이라는 것이다. 하지만 fine-tuning 기법에 비해 당연히 성능은 떨어질 수밖에 없을 것이다(역주).
그럼 제로샷이라는 게 무엇이냐 하면, 사전학습 없이 LLM이 가지고 있는 일반화 능력을 믿고 적절한 프롬프트를 작성하여 추천을 유도하는 걸 의미한다. 아래와 같은 상황들이 있을 수 있다.
1. 영화 추천
상황: 모델이 특정 사용자와 아이템 데이터에 대한 학습 없이 추천 수행.
프롬프트 예시:"사용자가 로맨틱 코미디 영화를 좋아한다고 합니다. 'Love Actually'와 비슷한 영화 세 편을 추천해주세요."
결과: 모델은 로맨틱 코미디 장르의 지식을 기반으로 'Notting Hill', 'The Proposal', 'Crazy Rich Asians'와 같은 영화를 추천.
2. 뉴스 요약
상황: 모델이 뉴스 요약 작업을 학습한 적 없으나, 프롬프트를 통해 수행 가능.
프롬프트 예시:"다음 기사를 간단히 요약해주세요: [기사 내용]"
결과: 모델은 기사를 읽고 주요 내용을 간결하게 요약.
3. 제품 추천
상황: 사용자가 특정 카테고리의 제품을 찾고 있을 때.
프롬프트 예시: "사용자가 뛰어난 노이즈 캔슬링 기능을 가진 헤드폰을 원합니다. 추천해주세요."
결과: 모델은 "Sony WH-1000XM5, Bose 700, Apple AirPods Max"와 같은 제품을 추천.
4.1.2) In-context Learning
그리고 간단하게 In-context Learning에 대해 언급하는데, 이건 거의 프롬프트 엔지니어링이라고 보면 되기 때문에 이 내용도 리뷰에서는 패스.
4.2) Tuning Paradigm
zero-shot, few-shot 방법이 성능을 끌어올리는 좋은 방법인 것은 맞지만, RS 도메인에 LLM을 실용적인 수준으로까지 접목하려면 fine-tuning과 prompt-tuning 레벨의 작업까지 필요한 것은 어찌보면 당연하다. 본 서베이에서는 이제 GLLM의 튜닝 패러다임에 대해 다루고 있다.
튜닝 방법은 세 가지로, Fine-tuning, Prompt Tuning, Instruction Tuning이다. 이 세 가지 방법에 대한 설명은 DLLM 파트를 리뷰하면서 작성하였으니, 전체 생략(..) 하도록 하겠다. 본문에서도 뻘쭘한지 3장의 내용과 4장의 내용이 유사하다는 밑밥을 깔고 있다.
(Instruction Tuning은 zero-shot, few-shot 등을 포함하는 프롬프트를 통한 성능 향상 방법. 즉 프롬프트 엔지니어링이다)
5. Findings
그래서 바로 5장으로 넘어오면, LLM with RS 에서 발견된 공통적인 결론 요약은 다음과 같다.
[앞으로의 기술적 과제]
1) 효율성 문제
- 대규모 모델의 높은 연산 비용과 메모리 요구 사항.
- 실시간 추천 시스템에 적용하기 위한 최적화 필요.
2) 일반화 능력
- 특정 도메인 또는 작업에 과도하게 특화되지 않으면서도 보편적인 추천 성능 유지.
- 다양한 사용자와 아이템 데이터를 다룰 수 있는 더 나은 적응성 필요.
3) 데이터 제한
- 콜드스타트 문제(새로운 사용자와 아이템).
- 사용자-아이템 상호작용 데이터가 부족한 환경에서의 모델 성능.
4) 해석 가능성
- LLM의 추천 이유를 이해하고 설명할 수 있는 능력 부족.
- 사용자 신뢰를 향상시키기 위한 투명한 추천 프로세스 필요.
5.1 Model Bias
1) Position Bias
LLM과 RS 패러다임에서는 유저 정보, 아이템 정보 등의 텍스트 기반 input 데이터가 순서가 있는 형태로 모델에 입력되기 때문에 Position Bias를 일으킬 수 있다는 내용. 이에 대한 명확한 해결책을 함께 제안한 모델이나 연구는 아직 없는 것으로 보임. 이게 별로 큰 문제도 아닌 것 같고, 파라미터 사이즈가 커지면 자연스럽게 해결 될 문제같기도 하다(역주).
2) Popularity Bias
추천시스템에서 절대 빠질 수 없는 문제점인 popularity bias, 즉 cold-start에 관한 내용이다. 모델의 pre-train 단계에서 자주 언급되거나 일반적인 용어를 포함하는 아이템의 경우, 자연스럽게 높은 랭크를 가질 수 밖에 없다.
3) Fairness Bias
챗지피티에서 한때 화제가 되었던 공정성 편향에 관한 내용이다. 이건 뭐 그냥 페이퍼 분량 채우려고 넣은 것 같다.
4) Personalization Bias
CF 같은 모델에서 생성되는 implicit signal 같은 개인화의 미묘한 요소를 LLM에서도 수행되게끔 하려면 (텍스트나 메타 정보로는 알 수 없는 내적 유사성 등) 아직은 ID 기반 CF 모델에 비해 정확도 면에서 갈 길이 멀다는 이야기를 하고 있다. 그 많은 논문에서 자기가 SOTA 라고 주장하고 있을텐데, 이런 얘기를 하는 거 보면 이 중국인들은 솔직한 서베이를 하는 것 같다.
5.2 Recommendation Prompt Designing
1) User/Item Representation
대부분의 기존 LLM 기반 연구에서는 아이템을 이름만으로, 유저를 아이템 이름 리스트만으로 표현하고 있으며, 이는 사용자와 아이템을 정확하게 모델링하기에 불충분하다. 이를 보완하기 위해서는 사용자의 행동 시퀀스(예: 클릭, 장바구니 추가, 구매 등)를 자연어로 변환하여 활용하는 등, 최대한 자연어에 가깝고 풍부한 정보를 제공하는 것이 중요하다고 할 수 있다. 기존의 ID 기반의 임베딩이나 latent factor를 추출하는 방식을 넘어서려면 부지런히 연구가 이루어져야 할 것이라고 한다. 이 역시 아직은 기존 RS를 대체할 수 없다는 솔직한 서베이 결과인 것 같다.
2) Limited Context Length
LLM의 입력 토큰 수 제한은 당연하게도 최적의 성능을 끌어내는 데 큰 걸림돌이다. 근데 이건 해결책이 명확하게 나온 연구도 없는 것 같고, 트릭을 조금 써서 더 나아졌다는 한두개의 레퍼런스를 언급하기는 하지만, 서베이의 저자 역시 별 반응은 없는 것 같다. 아마 이 문제는 모델과 컴퓨팅 자원이 더 커질수록 언급의 빈도가 점점 낮아지지 않을까 싶다.
5.3 Promising Ability
1) Zero/Few-shot Recommendation Ability
cold-start 문제를 효과적으로 해결할 수 있는 방법이 LLM 이다 라는 골지의 문단이다. 현재는 warm-start 문제조차 성능이 떨어지지만, 언젠가 그렇게 될 것이라고 나도 생각한다.
2) Explainable Ability
추천에서 XAI의 역할이 중요한 도메인이 분명 존재한다. 쇼핑이나 뉴스처럼 아묻따 컨텐츠부터 보여주는 경우에는 해당하지 않지만, 넷플릭스처럼 직관적인 XAI를 제공하는 도메인의 경우에는 LLM 파워를 활용한 XAI가 점점 유용해질 것이다.
5.4 Evaluation Issues
1) Generation Controlling
추천 도메인에서의 LLM은 프롬프트의 지시를 잘 따르는 출력 결과가 중요하다. 예를 들어 binary(예: 예/아니오)로 응답하라고 하는 경우이거나, JSON 포맷으로 출력해달라고 명령할 수 있다. 하지만 LLM을 많이 써 본 사람은 알겠지만, LLM의 출력이 가끔 제멋대로일 때가 있다. 버전이 올라갈수록 이 문제는 해결되겠지만, 그럼에도 LLM은 확률적으로 오류가 발생할 수밖에 없는 구조이다.
특히나 LLM은 리스트 방식 추천(list-wise recommendation) task에서 어려움을 겪는데, 이 방식이 중요한 RS 에서는 꽤나 큰 문제라고 할 수 있다.
이를 해결하기 위해 Pairwise Ranking Prompting의 개념이나 Pointwise Ranking Prompting의 개념에 대한 연구가 진행되고 있다고 하는데, 아직은 연산 속도 때문에 break trough 되는 연구는 없는 듯 하다. 모델 구조의 패러다임이 바뀌지 않는 이상 당분간은 inference 속도 문제에 걸려있을 듯.
2) Evaluation Criteria
LLM이 수행하는 작업이 prediction 이거나 ranking 문제인 경우, NDCG나 MSE 같은 지표를 사용할 수도 있다. 그러나 LLM이 잘하는 전문 분야는 그런 종류의 작업보다는, autoregressive한 종류의 작업을 더 잘하기 때문에 LLM의 RS 결과를 어떻게 평가할지는 아직 미해결 과제이다. 일례로 추천 결과에 대한 XAI를 어떻게 평가할 지에 대해서도 아직은 별다른 방법이 없다.
3) Datasets
현재 이 분야의 대부분의 연구는 MovieLens, Amazon Books 등과 같은 벤치마크 데이터셋을 사용하여 LLM의 추천 결과를 평가하고 있는데, 이 데이터를 사용하면 규모가 적을 뿐더러 도메인의 문제가 있다. 영화나 책은 이미 LLM의 사전학습 단계에서 웹 문서에 많이 등장한 내용에 포함된 경우가 많기 때문에, 새로운 도메인의 추천 결과와 아마도 많이 다를 것이다. 그래서 조금 더 포괄적인 평가가 가능한 RS 데이터셋이 LLM에서는 필요한 상황이라고 볼 수 있다.
6. Conclusion
결론은 뭐 본문의 요약 + “우리가 이렇게 서베이 열심히 했다 칭찬해줘” 이니 굳이 읽을 필요는 없다. 그래도 중국인들이 쓴 서베이 치고는 나름 객관적으로 한 것 같아서 좋았고, 전반적인 연구와 활용 동향에 대해서도 잘 정리한 듯 하다. 사실 몇 가지 모델의 학습 메커니즘을 소개한 것 말고는 “아직 잘 모르겠다”가 결론 같기는 한데.. 몇 년 뒤에는 좀 더 정립이 잘 된 서베이도 내줬으면 좋겠다.
