SK Tech Summit 2023 - LLM 적용 방법인 PEFT vs RAG, Domain 적용 승자는?

https://youtu.be/WWaPGDS7ZQs?si=YK9YnKfo0v3G2BG6

 

SK브로드밴드 AI/DT Tech팀 김현석.

LLM 배경

 

Foundation Model: 다양한 Task를 Self-supervised Learning 수행한 것.

• LLM의 경우 '언어' 라는 분야에 특화된 형태로, 요약 / 분류 / 번역, QA 등 다양한 task를 수행할 수 있다.

2023년에는 ChatGPT, Bard 등 LLM 기반 서비스가 많이 출시됐음.

• 기업에서도 자체 도메인을 적용하려는 시도 + LLaMa 오픈소스

사내 적용 시 Challenge Point

 

Azure 환경 + ChatGPT RAG 적용해서 사내 데이터 연동하려는 PoC 진행 시 겪은 문제

• Fine Tuning에 드는 비용
• Hallucination이 발생하는데, 해결방법이 Prompt 조정하는 것밖에 없음.
• 한국어 이슈.
• Data 변경이 어려움.

특정 도메인에 적합한 LLM 모델이 필요할 거 같다..

 

그 외에도 '보안' / '운영' / '비용' 에서도 이슈가 하나씩 있었는데

• 보안: 자체 Landing Zone / Opt out 적용해서 방지할 수는 있음
• 운영: 모델이 업데이트되면, 답변 품질이나 답변결과가 달라질 수 있다

즉, Ownership을 온전히 확보하기는 힘들다

 

대 고객형 서비스로 간다면, 사용량에 따라 비용이 선형적으로 증가하는 구조...

 

Fine Tuning의 문제

• Specific Domain / Task를 효과적으로 처리하는 가장 좋은 방법은 fine tuning
• 그러나 LLM은 규모가 너무 커서 Full Fine Tuning은 비효율적이다.
  • 데이터 양 / 인프라 / 학습속도...

 

오픈소스 + sLLM 활용하는 형태로 PoC를 진행.

PEFT vs RAG

 

PoC 접근 방법

• PEFT: Fine Tuning 기반
• RAG: 검색 기반

사용한 데이터: 상담원이 업무 참고자료 메뉴얼로 사용하는 것.

• html Text / Table 정보만 활용했음.

 

Raw Data 전처리

• Table: json 형태 -> LLM 돌려서 자연어로 변환.
• Plain Text + Json을 자연어로 변환한 것 -> instruction 생성, embedding chunk size로 구분.

 

Instruction 증강 - PEFT

• 최초에는 PoC 진행하는 인원들끼리 Prompt (instruction) 생성 / 수동 필터링 거쳐서 총 25,000 개 instruction 구축.
  • 성능이 매우 안좋았음. 사후 분석해보니 instruction 품질 이슈 + 특정 카테고리는 기호문자 위주로 되어 있어서 LLM이 이해하기는 어려운 구조였음
• 상품 카테고리 하나에 집중... New Data 선별. 특성에 맞춘 전처리... instruction 생성. 10,000개 정도
  • instruction 개수가 아쉬웠음.
• 상품 특화 Prompt를 만들어서 instruction을 LLM으로 추가 생성함. 70,000여 개까지.

 

instruction 원문이 오른쪽, LLM으로 생성한 instruction은 오른쪽.

• 문서를 보고 instruction을 매번 새로 만드는 건 한계가 뚜렷하다.
• 유사 표현을 가진 문장 형태로 Data Augmentation 진행.

---

 

검증에 사용한 LLM 모델들

• KoAlpaca-Polyglot-12.8B : sLLM 한국어모델의 baseline 격으로 많이 쓰임
• KoVicuna-7B : 영어모델 자체는 sLLM 계열에서 성능이 좋은데, 파라미터 수가 적은 걸로 테스트 + 한국어라서 살짝 아쉽. 실험에서는 제외함
• KuLLM-Polyglot-12.8B : polyglot + PEFT + LoRA 기법으로 학습한, 고려대에서 개발한 모델.

PEFT

 

모델의 일부 파라미터만 갱신하면서도 학습효과를 누리기 위한 기법.

학습 방법

• 데이터 구축: 원천 데이터 -> 학습에 용이한 형태로 전처리해서 instruction set
• 모델 학습 / 개발
• 모델 평가: Loss 기준으로 수렴도 확인, PoC 인원의 정성평가

장점

• 도메인 학습이므로 별도의 Prompt 필요 없었음
• sLLM 활용 가능

단점

• 최신 데이터 반영하려면 재학습해야 함.

RAG

 

사용자가 질문 -> Vector Embedding -> vector DB 구축해둔 곳에서 similarity search 수행

• 유사 context 찾아서, 언어모델에 질문과 함께 입력하는 방식.

 

• 지식 DB 구축: Text chunking, Embedding
• RAG Architecture 개발: AWS Sagemaker에서 OpenSearch 활용.
• 모델 평가: train loss는 없고, 처리량 / 응답속도 / 완결성 / 정확도 등을 정성적으로 평가.

장점

• 최신 데이터 적용이 편함

약점

• Prompt 의존도가 높음

---

 

각 기법별로 Baseline 결정하는 실험

• PEFT의 경우 KuLLM이 가장 좋았음
• epoch의 경우 3 ~ 10 Epoch까지 학습시킨 결과 비교했는데, 3, 5 epoch 모델 선택.
  • overfit 한다고 hallucination이 사라지는 건 아니었음.

 

데이터 수가 많아지면 응답이 달라지는가?

• Augmentation으로 1K, 2.5K, 5K, 10K 생성.
• Base dataset 25K, 이걸 augmentation으로 70K까지 생성

-> 7가지 방식으로 실험 데이터 구성 & 실험 진행

결론: 데이터 많아질수록 Loss가 빠르게 수렴한다.

 

생성한 응답도 보다 정답에 근접해가는 것을 확인할 수 있었음

• 단, loss가 낮을수록 생성모델의 성능이 더 좋다고 단언할 수는 없다.

 

특이점: Augmentation으로 많은 데이터를 학습시킨 모델일수록 답변 길이가 짧다. 왜?

• Augment로 생성한 instruction set의 질문 / 답변 길이가 훨씬 짧았음

 

PEFT 단독 사용 시 문제점

• 데이터 업데이트 -> 모델 재학습 부담.
• 상품내용이 일부 수정되었을 때, 수정하기 이전 데이터를 Forget하지 못함. 수정 이전 / 이후 데이터가 합쳐진 채 응답으로 포함되는 이슈가 있음
• RAG는 원본 파일 / 첨부파일을 제공할 수 있는데, PEFT는 그게 안 됨.

따라서, RAG 장점을 어떻게든 결합해야 했다.

장단점 보완을 위해, 조합이 필요하다

 

둘다 사용하는 형태의 아키텍처 예시

평가

 

정성적인 평가 진행.

• 질문 유형 5개 선별
• 질문의 표현법은 3개로 구분 - 단어, 간결한 문장, 일반 문장.
• 정확도 / 상세함 평가지표 설정

'어느 답변이 보다 적합한가' 판단.

 

평가 결과

• Fine tuning은 해야 유의미한 성능 향상을 기대할 수 있다. Base 모델 대비 fine tuning 평가결과가 훨씬 좋았다.
• PEFT + RAG 결합했을 때 전반적으로 성능이 좋았다.
• Overfit이 발생한 모델은 RAG 결합 시 주어진 Docs를 활용하지 못한다.

 

상품 기능이나 내용설명, 조건 설명 등 단순한 부분에서는 높은 성능을 보여주었으나

• 단순한 문의 -> 설명 방식에서는 뛰어났으나

논리적인 상품 추천, 비교, 프로세스 설명하는 등의 작업에서는 낮은 성능이 확인됨.

• 어려워지면 바보 된다

 

아마도 원인으로는 baseline 모델인 KuLLM이 학습된 데이터 비중 문제 아닐까 함.

• 학습데이터 까보니까 과정, 비교 쪽 instruction 비중이 낮았다.
• 무언가를 설명하는 유형의 instruction이 많았음.

결론

 

• 당장 도입하기는 어렵다고 판단
• 성능이 향상될 수 있는 여지 / 방법은 파악했음
• 보다 큰 모델을 써서 다른 PoC를 해보고 있음.

Instruction 품질이 굉장히 중요했다.