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 품질이 굉장히 중요했다.