LEE CHANWOO

📝 Blog 2024 version 1.6.1
🔖 NOV 1, 2024

4 분 소요


image

sLLM (small Large Language Model)

서론

ChatGPT 등장 이후 생성형 AI의 근간인 LLM(Large Language Model, 거대언어모델)의 비즈니스 활용이 주목을 받는 와중에 작년 메타의 라마(LLaMA)가 공개되면서 LLM의 한계를 보완한 sLLM(small Large Language Model, 소형언어모델)가 새로운 대안으로 떠오르고 있다.

LLM(Large Language Model)

LLM은 인간의 언어를 이해하고 생성할 수 있도록 훈련된 언어 모델이다. 생성형 AI의 대표주자인 챗GPT가 이 LLM을 기반으로 만들어졌다. 언어 모델의 크기는 통상 매개변수(시스템상 작동에 영향을 미치는 데이터) 개수에 따라 정해진다. 1000억 개 이상이면 LLM으로 분류된다. 챗GPT에 적용된 ‘GPT-3’의 매개변수는 1750억 개이며, 구글이 개발한 ‘팜(PaLM)’은 5400억 개에 달한다.

sLLM(small Large Language Model)

sLLM은 최소 수십억 개의 매개변수만으로 연산 작업을 단축시켜 보다 효율적으로 운영될 수 있는 언어 모델에 속한다. sLLM이 처음 주목받기 시작한 건 23년 초부터이다.

당시 메타는 LLM인 ‘라마(LLaMA)’를 공개한 데 이어 미국 스탠퍼드대와 함께 라마를 기반으로 한 sLLM ‘알파카(Alpaca)’를 개발했다. 매개변수가 적은 만큼 LLM에 비해 더 적은 컴퓨팅(처리 과정) 자원으로 최대한의 효율을 낼 수 있다. 그만큼 훈련 시간, 비용, 용량, 전력 소모량이 훨씬 절감된다.


스탠퍼드대학교가 메타의 라마 중 매개변수가 가장 적은 버전(7B)을 기반으로 한
소형 언어 모델인‘알파카 7B를 만들었다. /Stanford CRFM



메타가 2023년 7월 18일에 공개한 'Llama2'는 매개변수 규모에 따라
세 가지 모델(70억 개, 130억 개, 700억 개)로 제공된다. /Meta


현재 한국어 언어 모델의 한계

성능 문제


image

네이버와 카카오는 해외 빅테크 기업들이 주력하는 인공지능(AI) 분야에서 아직 경쟁력을 갖추지 못하고 있다. 챗GPT 등장 이후 불과 1년 만에 구글, 마이크로소프트(MS)를 중심으로 AI 패권 경쟁이 격화되자 네이버는 24년 8월 대규모 언어 모델(LLM)인 ‘하이버클로바X’를 내놓았다.

네이버는 한국어와 한국 문화에 최적화된 초거대 AI 모델이란 점을 내세웠지만 챗GPT나 바드 등 빅테크가 내놓은 모델도 한국어 학습 수준을 높이며 네이버의 장점이 희석됐다.

업스테이지의 솔라(SOLAR)는 23년 12월 AI 모델 성능 순위 매기는 허깅페이스의 ‘오픈 LLM 리더보드’ 소형모델 부문서 1위를 기록했다. 알리바바의 ‘큐원’, 메타의 ‘라마 2’, 미스트랄AI의 ‘미스트랄’ 사전학습 모델보다 높은 점수를 받았다. 23년 8월에는 오픈AI의 GPT-3.5 벤치마크 점수도 넘겼다.

서비스 연동 사례 부족


1월 5주 오픈 Ko-LLM 리더보드 /업스테이지, NIA


실제로 Ko-LLM 리더보드를 통해 좋은 성적을 낸 모델이 기업활동에 본격 활용하게 된 사례도 있다.

1월 11일에 업스테이지의 글로벌 1위 대형언어모델(LLM) ‘솔라(SOLAR)’를 카카오톡 ‘아숙업(AskUp)’에 적용했다. 아숙업의 대화 중 10% 정도만 솔라를 적용했다.

롯데정보통신의 ‘LDCC/LDCC-SOLAR-10.7B’ 모델은 1월 3주에 이어 2주째 정상을 지켰다. 23년 11월 1주 차에 ‘라마 2’ 기반 모델로 1위를 차지한 이후 ‘솔라’에 이어 야놀자의 솔라 미세조정 버전을 도입하는 등 다양한 모델로 계속 정상을 차지하고 있다.

이처럼 정상급 LLM 기술력을 선보인 롯데정보통신은 1월 24일 AI 플랫폼 ‘아이멤버(Aimember)’를 롯데그룹 전 계열사에 도입한다고 발표했다. 아이엠버에 적용한 언어모델은 ‘롯데GPT’로, 바로 리더보드 1위의 기술력을 바탕으로 했다.

한국어 언어 모델이 일반 성능에서는 아직 부족하나, 특정 분야에 특화한 언어 모델은 충분한 성능을 보이고 있다. 향후에 사내 다양한 프로젝트에 직접 구축한 언어 모델을 활용하려면 자체 파운데이션 모델 구축, 각 비즈니스에 맞게 미세조정을 진행해 특화 언어 모델을 구축해야 한다.


LLM의 문제와 해결 방안

LLM과 sLLM은 모르는 부분도 그럴싸하게 포장해 오답을 내놓는 ‘할루시네이션(환각)’이라는 고질적인 문제를 갖고 있다.

sLLM의 이점

sLLM은 LLM에 비해 매개변수를 줄여 학습을 위한 비용 및 시간 절감이 가능한 것이 특징이다. 보다 빠르게 미세조정(파인튜닝)을 해 정확도를 높일 수 있는 데다 특정 분야 및 기업에서 기존에 보유한 데이터를 활용해 할루시네이션(환각) 현상을 줄일 수 있다.

파인튜닝과 검색증강생성(RAG)

업계에서 현재 할루시네이션을 줄이기 위해 사용되는 기술은 크게 ‘파인튜닝’과 ‘검색증강생성(RAG)’이 있다. 파인튜닝은 특정 도메인에 LLM이 접목될 경우 높은 답변 적합성을 위해 기존 LLM에 특정 데이터셋을 활용해 미세조정하는 작업을 의미한다. 다만 파인튜닝은 최신성과 적합성을 제고할 수는 있으나, 데이터 용량 증가에 따른 높은 비용과 지속적인 업데이트의 어려움이 수반된다.

반면 RAG는 파인튜닝에 이어 전 세계적으로 주목받는 기술군으로 파인튜닝에 활용한 특정 데이터셋보다 보안성이 높고 최신의 데이터를 답변 생성에 사용한다. 답변 생성 시 자체 데이터를 활용해 답변이 적합한지 확인하고 사용자에게 보여주는 피드백 과정이 추가돼 할루시네이션 방지에 더욱 유리하다. 모델이 사람의 언어를 이해하고 답변을 위한 검색을 하는 과정에서 기존 키워드 검색 방식과 문맥과 의미를 중요하게 생각하는 시맨틱 검색 방식의 혼합형인 하이브리드 검색 방식이 가능하기 때문이다.

💡 파인 튜닝이란, 사전 학습 모델(pre-trained model)에 도메인 특화 데이터를 추가 학습시켜 맞춤형 모델로 업데이트 하는 것을 의미한다.

💡 RAG(Retrieval Augmented Generation)은 베이스 모델의 외부에서 데이터를 가져와 임베딩을 얻어 Vector DB에 저장하고, 사용자가 질문을 하면 관련도가 가장 높은 임베딩을 찾아내서 모델에 이를 제공하는 방식이다.

LLM을 온전히 처음부터 개발하는 방법의 진입 장벽이 워낙 견고하기 때문에 많은 기업들이 현실적으로 파인튜닝과 RAG 사이에서 고민을 하게 된다.

RAG라는 기법이 다소 생소하게 들릴 수도 있고 기업에서 쓰려면 범용 모델에 맥락을 제공하는 수준보다는 맞춤형 모델 정도는 되어야 한다고 당연히 생각할 지도 모르지만, 파인튜닝은 신중하게 접근해야 한다.

  • 파인튜닝된 모델은 특정 시점까지의 데이터만 학습이 된다. 모델 외부 데이터에 대한 상시적 접근이 필요하다면 RAG가 더 효율적인 방법이다.
  • LLM의 행동(Behavior)을 특정한 뉘앙스, 톤, 용어 등에 적합하게 맞추려고 한다면 파인 튜닝이 더 유리하다. RAG가 목표한 DB에서 정보를 불러오는 것은 가능하지만, 데이터의 도메인 특화성 전반을 강화한다던가, 언어적인 스타일 등을 수정할 수 있는 것은 아니다.
  • 파인튜닝시 특정 도메인 데이터를 추가로 학습시키기 때문에 이것이 할루시네이션 문제를 다소간 줄여줄 수는 있지만, 익숙하지 않은 입력(Input)이 들어온다면 할루시네이션이 발생할 가능성은 여전하다. 파인튜닝 방식에서는 이 문제에 대응하기 위해 새로운 데이터를 끊임없이 학습 시켜야 한다. 반면, RAG는 모든 답변을 근거 있게 생성하기 때문에(based on retrieval evidence) 태생적으로 할루시네이션 방지에 더 유리하다.
  • 파인튜닝 모델의 품질은 결국 유관 도메인 데이터의 품질과 양에 달려 있다. 반면 RAG의 결과물은 학습 데이터의 품질과는 독립적이다. 충분한 양의 양질의 라벨링 데이터를 확보할 수 없다면 파인튜닝은 적절한 선택이 아니다.
  • 데이터가 정적(static)인지 역동적(dynamic)인지를 살펴보아야 한다. 데이터의 변동성이 크다면 RAG가 유리하다. Vector DB를 갱신하는 일이 모델을 추가 학습 시키는 것보다 훨씬 간편한 일이기 때문이다.
  • 파인 튜닝 모델의 경우 의사결정 과정이 ‘블랙박스’와 같다. 반면 RAG 방식은 이 보다 그 과정이 투명하다. ‘Retrieval(검색)’과 ‘Generation(생성)’ 이라는 2 단계를 살펴보면, Retrieval 단계에서 어떤 외부 문서나 데이터 포인트가 관련성 있는 것으로 판단되고 있는지를 면밀히 살펴볼 수 있고 Generation 단계에서 이를 기반으로 답변을 생성할 수 있기 때문이다. 높은 수준의 책임성이 필요한 애플리케이션이라면 RAG 방식의 애플리케이션이 파인 튜닝 방식보다 적절하다.

References

태그: ,

카테고리:

업데이트:

댓글남기기

참고