LLM 적용 방식 : RAG와 PEFT

 

 

 

개요

우리가 LLM하면 떠오르는 ChatGPT, Llama, Claude 등의 모델들은 지구, 웹에서 생성된 거의 대부분의 텍스트 데이터를 긁어모아서 학습시켰다고 볼 수 있다. 지구상의 존재하는 거의 대부분의 텍스트를 읽어가면서 인간의 "언어"라는 개념을 자신들만의 차원 형태로 이해한 것이다. 

 

 

 

서비스 적용의 어려움 

그렇다면 이렇게 똑똑한 모델을 우리 서비스에 바로 적용할 수 있을까? 그렇지 않다.

 

일반적으로 텍스트를 학습하면서 모델은 각자의 도서관(dimension)을 갖추었다고 볼 수 있는데 이 도서관에 있는 책들을 하나씩 이용해서 문장을 생성한다. 한번에 문장을 생성하기 보다는 autoregressive하게 단어 하나하나씩 생성하는 과정에서 높은 확률을 가진 단어를 추출하는 형태로 모델이 돌아간다.

 

앞서 지구상의 모든 텍스트 데이터를 학습한 모델이 갖춘 도서관은 매우 방대할 것이고 확률은 모델이 학습한 데이터의 비중에 비례해서 문장을 생성할 것이다. 전문적인 언어, 문장 생성은 당연히 일반적인 언어, 문장 생성보다 학습한 양이 적기 때문에 우리가 chat을 했을 때 일반적인 문장 생성을 더 잘할 확률이 높다.(당연히 반대로 Hallucination은 전문적인 분야의 문장생성이 어려울 것이다.)

 

이전의 머신러닝에서 특히 라벨링 데이터가 있는 지도학습에서는 class imbalance 문제라고 하고 class 비율을 맞추는 해결책을 사용하는데 LLM에서는 우선 언어 자체를 잘 이해하는 큰 모델을 만드는 경쟁이 치열하게 일어나고 있기 때문에 상대적으로 이 문제를 다른 방식으로 해결하고 있다.

 

그렇다면 이것과 우리 서비스에 LLM을 바로 적용하지 못하는 이유는 무슨 관계가 있을까? 오늘날 대부분의 서비스는 특정 Task를 하기 위해 존재한다. 아래는 미국의 유명한 게시판 웹사이트인 크레이그리스트의 각 게시판들을 모바일 시대가 들어서자 게시판 1개, 1개를 개별 스타트업들이 앱 형태로 만들어내고 있다는 것을 표현한 그림이다.

출처 : https://www.linkedin.com/pulse/disaggregation-craigslist-how-find-your-next-billion-startup-byron-ma/

 

즉, 현재 우리가 사용하는 개별 앱들은 모두 나름의 특정 도메인의 Task를 해결해주는 서비스를 만들고 있고 이를 바로 적용하면 우리가 원하는 답이 아니라, 일반적인 말은 내뱉는 챗봇이 되어버릴 가능성이 크다는 것이다.

 

 

 

해결책

 

1) Fine-tuning 방식

그렇다면 어떻게 이를 해결할 수 있을까? 가장 먼저 떠오르는건 일반적인 머신러닝 개발 방식처럼 특정 도메인과 관련된 데이터들을 싹 긁어모아서 모델을 전체적으로 다시 학습(Fine-tuning)시키는 방식이다.

 

매우 간단하지만 대부분 스타트업에게는 어렵다. 뉴스 기사에 따르면 GPT3를 하루 운영하는데만도 약 9억원이 든다고 한다.(https://www.itworld.co.kr/news/289009) 초기 스타트업은 주로 시드 투자로 5천만원 ~ 1억 정도를 투자받고, 시리즈 C이더라도 학습을 시키는 것만으로도 투자금의 대부분을 사용한다고 생각해보면 경제적으로 매우 비효율적이다.

 

하지만 만일 누군가가 이 모델의 가중치를 고정시키고 몇몇 neuron을 추가해서 그부분만 학습시켰을 때 성능이 원하는대로 나온다면? 모두가 이 방법을 채택할 것이다. 

 

이 방식을 특정 가중치만 학습시켜서 효율적으로 fine-tuning시키는 방식이라고 해서 PEFT(Parameter Efficient Fine-Tuning)이라고 한다. PEFT에는 여러 방법들이 있는데 이에 대해서는 별도 글에서 다루려고 한다.

 

하지만 이조차도 GPU를 사용해서 학습해야한다는 차원과 모델 자체를 돌리는데 드는 Inference 비용이 많이 들기 때문에 일부 단점을 가지고 있다.

 

 

2) RAG

다른 방법으로 RAG라는 솔루션도 있다. RAG는 Retrieval Augmented Generation의 약자로 자체 데이터를 학습시키는 것이 아니라 관련 데이터를 프롬프트의 일부로 같이 전달해서 최대한 사실을 기반으로 원하는 답을 내뱉도록 하는 방식이라고 보면 된다.

 

앞서 GPU를 비롯한 ML Infra를 다 구축하고 관리하는데 어려움을 가지거나 추론에도 비용이 들기 때문에 비용적 부담이 있는 경우에는 LLM 업체에서 제공하는 api를 사용해서 프롬프트를 api 형태로 전달하면 모델이 생성한 답을 output으로 전달받을 수 있는 시스템이다.

 

전반적인 프로세스는 아래와 같다. 우선 사용자는 Prompt를 작성하는데 이 때 그 프롬프트를 바로 api로 llm에 던지는 것이 아니라, 연관 문서를 찾는 일종의 "검색 작업"을 하는 프로세스가 존재한다. 일반적인 "키워드 검색"과 다르게 RAG에서는 이 프롬프트와 연관문서를 같은 차원의 벡터로 임베딩시켜서 나온 두개의 벡터간 유사도를 계산해서 가장 유사도가 높은 문서를 추출한다. 이를 Retrieval이라고 한다.

 

그렇게 유사도가 높은 문서 3개 정도를 다시 프롬프트와 함께 섞어서 답변해달라고 최종적으로 llm api에 요청해서 나온 답을 유저에게 제공하는 방식이 RAG라고 볼 수 있다.

 

사실 이 방식자체도 새롭게 생겨난 엔지니어링 방식이기 때문에 여러 경험적으로 나온 노하우들이 있는데 이런 것들도 추후에 다시 자세히 소개하려고 한다.

 

 

각각의 해결책에 대해서는 이후 블로그 글에서 세부적으로 다뤄보려고 한다.