[SK TECH SUMMIT 2023] LLM 적용 방법인 RAG VS PEFT, Domain 적용 승자는?

주제

• LLM 도메인 적용 방법 RAG VS PEFT PoC

LLM 적용 방법인 PEFT vs RAG(출처: SK TECH SUMMIT 유튜브 채널)

 

---

강연자

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

---

발표 자료

발표 자료는 SK TECH SUMMIT 2023에서 다운로드⭕️

👉 [SK TECH SUMMIT 2023] AI Everywhere for a better future

---

강의 내용

1. LLM 배경

2. 사내 적용 시 Challenge point

3. PEFT vs RAG

4. 결론

---

1. LLM 배경

LLM과 Foundation Model

Foundation Model(FM)

✅ 다양한 task 도메인에서 방대한 양의 데이터로 Self-supervised Learning으로 학습된 모델

✅ 특정 task 지정하지 않아도 범용적으로 일반화된 성능 보임

Large Language Model(LLM)

✅ 그중 LLM은 요약, 분류, 생성, Q&A, 번역 등의 언어 분야에 특화된 태스크 수행할 수 있음

---

LLM 발전 계보/LLM 기반 서비스/서비스 중인 LLM의 한계

✅ GPT-3 등장 이후, 본격적으로 큰 사이즈 모델들 많이 나옴 ✅ 특히, 2023년에 ChatGPT, Bard(바드) 등의 LLM 기반 서비스들도 출시	✅ 일반 사용자용 ChatGPT, Bard 같은 LLM 기반 서비스들이 출시됨 ✅ 기업에서도 자체적인 데이터, 도메인 적용한 LLM 서비스화 하기 위해 다양한 시도	✅ ChatGPT, Bard는 API 형태로 서비스  ✅ 사내 적용시 제약사항 발생 ✅ Meta가 공개한 'Llama(라마)' 기반 다양한 파생 모델 공개 ✅ Controllable한, ownership 가지고 운용 가능한 모델들 공개되는 추세

---

2.  사내 적용 시 Challenge Point

23년 2분기 ChatGPT 활용 PoC 사례

 

✅ 2Q Azure 환경에서 ChatGPT에 RAG 아키텍처 적용해 사내 데이터 연동할 수 있는지 PoC 진행

✅ 발견했던 문제는 크게 4가지

1️⃣ Fine Tuning 하기에는 상대적 cost가 큼

2️⃣ Hallucination 현상 방지하기 위해 prompt 잘 꾸미는 방법밖에 없음

3️⃣ 대부분 한국어로 답변 잘하는데, 가끔 영문으로 답변하는 사례

4️⃣ 최신 데이터 학습 못했기 때문에, ChatGPT가 알고 있는 정보의 특정 시점에 대한 한계 존재

➡️ 해당 모델 외, 도메인 적용할 수 있는 LLM 모델 발굴 필요성

---

추가적인 공통  Challenge Point  3가지

보안과 운영	비용	Domain Adaption
✅ (보안) 자체 *Landing Zone 구축, *Opt-out 적용해 사내 데이터 유출 방지 가능 ✅ (운영) 모델이 혼자 업데이트되면, 답변의 일관성 떨어질 수 있음 ➡️ 모델, 데이터에 온전한 ownership 가지기 어려움	✅ Chat-GPT 같은 서비스들은 token 당 비용 발생(사용량 🔺, 비용 🆙) ✅ 대고객향 서비스로 가면 사용자들이 얼마나 많은 정보를 실시간으로 넣느냐에 따라 과금 많이 될 수 있음	✅ (좌측) Fine-tuning별 성능. 전체 모델 업데이트 때, 시간 소요 크지만 성능 가장 좋음  ✅ (우측) 파라미터 수 많은 거대 모델들 ✅  초거대모델 전체 파인튜닝은 비효율적  ➡️ 학습 데이터 양, 인프라, 학습 속도 등 고려 필요

 

Azure Landing Zone?

참고: Azure 랜딩 존이란 무엇인가요?

8개 디자인 영역에서 주요 디자인 원칙 따르는 환경

모든 애플리케이션 포트폴리오 수용하고 대규모로 애플리케이션 마이그레이션, 현대화 및 혁신 가능하게 함

구독을 사용해 애플리케이션 리소스와 플랫폼 리소스 격리하소고 크기 조절

애플리케이션 리소스에 대한 구독을 애플리케이션 랜딩 존이라고 함

 

Opt-out(옵트아웃)?

정보주체의 동의받지 않고 개인정보 수집·이용한 후, 당사자가 거부 의사 밝히면 개인정보 활용 중지하는 방식

---

Challenge point 요약

✅ Challenge Point 극복할 수 있는 오픈소스 sLLM 활용한 사내 데이터 적용 PoC 추진

1️⃣ Opt-out 적용해 자체 모델 운용 환경 구성

2️⃣ 자체 모델 Hosting

3️⃣ RAG 활용 지식 연동 or PEFT 이용 Domain 학습

---

3. PEFT VS RAG

PoC 소개

✅ PoC 접근 방식 크게 2가지

1️⃣ Fine-Tuning 기반 PEFT

2️⃣ 검색 기반 RAG

---

PoC 활용 내부 데이터 소개

✅ (활용 데이터) 고객 상담원들이 업무 참고자료(매뉴얼)로 활용하는 데이터 ✅ (원천 데이터 크기) 원천 + 첨부 파일: 90GB  ✅ (텍스트 정제) HTML 1.2만개를 텍스트, 표 , 이미지로 나눔 ✅ (학습 데이터) 텍스트, 표 정보만 별도 추출	✅ 텍스트, HTML 활용해 RAG에서 활용할 chunk, PEFT에서 사용할 instruction 생성 1️⃣ 각 데이터에서 텍스트, 테이블(JSON) 추출 2️⃣ json 포맷은 LLM 통해 자연어 형태로 변환 3️⃣ HTML에서 텍스트 parsing한 plain text + json 정보 기반 자연어 형태로 푼 문장 2개 합쳐서 LLM 입력 위한 instruction 생성 4️⃣ Embedding 위한 chunk 사이즈별 데이터 생성

---

Instruction 증강-PEFT

1️⃣ 단계 ✅ 35,000개 데이터에서 LLM 통해 생성한 instruction set 가지고 사람이 filtering 진행해 25,000개 데이터셋만듬   ✅ 25,000개 데이터셋으로 1차 학습 진행했을 때, 성능 굉장히 안 좋았음 ➡️ 생성된 instruction 품질👎 2) 메뉴얼 세부 카테고리 항목이 기호로 표현되어 모델 이해 어려웠을 것으로 추정 2️⃣ 단계 ✅ (상품 메뉴얼 집중) 상품 카테고리에 집중해, 상품 특성 맞춤 가공 작업으로 10,000여개 instruction 생성➡️데이터 개수 아쉬움 3️⃣ 단계 ✅ (데이터 증강) 상품 특화 프롬프트 추가 개발해 25,000개 데이터 생성 ✅ (Instruction 증강) 70,000개로 증강	✅ (좌측) Instruction 원문 ✅ (우측) 증강 Instuction 예시 ➡️ 전처리 된 문서 기반 instruction 생성 방식 한계 인식 ➡️ 유사 표현 갖는 비슷한 형태의 문장 구조를 변형하는 방식으로 데이터 증강 진행

---

PoC 활용 모델 소개

1️⃣ KoAlpaca

✅ sLLM 한국어 모델 중, 거의 baseline 격으로 많이 활용되고 있는 모델

2️⃣ KoVicuna

✅ sLLM에서 영어모델들까지 포함했을 때, 성능 가장 뛰어난 모델

✅ KoAlpaca, KuLLM과 비교했을 때, 파라미터 수 상대적으로 적어 동등하게 비교하는 것은 의미 없을 것 같아 검토 단계에서 제외

3️⃣ KuLLM

✅ 고려대학교에서 개발한 모델

✅ Polyglot-ko 기반으로 LoRA 기법으로 PEFT로 파인튜닝해 학습한 모델

---

PEFT?

Fine-Tuning?

✅ 모델이 가지고 있는 전체 파라미터를 데이터에 맞게끔 업데이트하는 과정 거침
✅ 파라미터 수 굉장히 많아지면 상당한 cost 발생하기에, 전체 파라미터 갱신하는 것이 아니라 모델의 일부 파라미터만 갱신하면서 학습된 효과 충분히 누릴 수 있게끔 하는 기법

---

PEFT PoC 진행 방법

1️⃣단계 학습 데이터 구축	✅ 원천 데이터 문서를 학습시키기 용이한 형태로 가공 ➡️ instruction set으로 만듬
2️⃣단계 모델 학습/개발	✅ 모델 학습하고 배포하는 단계
3️⃣단계 모델 평가	✅ (정량적) Loss 기준으로 해당 모델이 얼마나 수렴했는지  ✅ (정성적) 모델 답변이 얼마나 정확하고, 표현이 풍부한지를 완결성, 정확도 지표를 기준으로 사람이 비교
PEFT 장점	✅ (도메인 특화에 강건) 도메인 데이터 직접 학습하다보니, 별도 prompt engineering 필요 없음
PEFT 단점	✅ 최신 데이터 유지하기 위한 모델 재학습 필요

---

RAG?

✅(좌측 - RAG 동작 원리) 사용자가 질문하면, 질문이 벡터 형태로 임베딩

✅ 사전에 chunk 단위로 나눠서 임베딩한 벡터 DB에서 context search, similarity search 등을 통해 해당 질문과 가장 유사한 정보들의 document 가져옴

(우측) 기본 프롬프트 + 질문으로부터 찾은 유사도 높은 정보 + 사용자 질문 3가지롤 통합해 맨 우측의 [Query] 형태로 모델에 입력해 답변 가져오는 방법

---

RAG PoC 진행 방법

1️⃣단계 지식 DB 구축	✅ 데이터 전처리 -> chunk 단위로 분할 -> 임베딩 -> vector DB 구축
2️⃣단계 RAG Architecture 개발	✅ AWS Sagemaker 환경에서 Open Search 활용
3️⃣단계 모델 평가	✅ 별도 학습 과정 없다보니, Loss 값 나오지 않음 ✅ PEFT 모델과 동일한 지표(완결성, 정확도)로 평가 진행
RAG 장점	✅ 최신 데이터 적용 용이
RAG 단점	✅ 프롬프트 의존도 높아 프롬프트 엔지니어링 필요

 

 

PEFT Baseline 결정 실험

Model 비교	Epoch 비교
✅ Kullm이 KoAlpaca 보다 근소한 차이로 더 잘 수렴(0.03) ✅ Kullm 모델을 Base로 선정	✅ 일반적으로 LLM 모델 파인튜닝은 3 epoch 많이 사용 ✅ 3 ~ 10 epoch별로 답변이 어떻게 변화하는지 확인 ✅ 3 ~ 5 에폭 모델 우선적으로 활용 ✅ overfitting되면 hallucination 사라지나 -? 결과 ❌

---

PEFT Data Augmentation 실험

(가설) 데이터 수 많아지면 정답 달라지는지 ✅ 기본 10K 데이터셋 기준, 랜덤 샘플링 통해 1천개, 2.5천개, 5천개, 1만개 4개 데이터셋 추가 생성 ✅ 2만5천여개 데이터를 새롭게 생성한 다음, 위의 데이터와 합쳐 33만 5천개 데이터셋 만듬 ✅ 2.5k 데이터를 증강해 70k개 데이터셋 ➡️ 총 7개 데이터셋으로 구성	실험 결과 ✅ 데이터셋 많아질수록 모델이 빠르고 잘 수렴 ✅ 생성 모델 특성상 Loss 값이 낮다고 답변의 품질이 뛰어나게 좋아지는 걸 담보하지 않음 ✅ 실제 답변에 대한 검증 추가로 진행

---

PEFT Data Augmentation 실험 답변

✅ 데이터셋 많을수록 확실히 질문에 대한 정답 이야기하는 비중 많아짐

✅ 10K 모델 답변보다 증강으로 생성된 데이터들로 학습된 모델들의 답변 길이가 훨씬 짧음

✅ 10K-3EP 기준으로 테스트하다, 오버피팅된 것처럼 이상한 답변 나오는 사례 있어,  학습 덜 시키는 70K-1EP 추가 테스트 진행

---

✅ 데이터셋 확인해 보니 Baseline으로 잡은 10K 데이터셋 보다 증강된 데이터셋 분포가 훨씬 짧음

---

PEFT 단독 사용 시 문제점

1️⃣ 지속적인 파인튜닝 필요

✅ 예를 들어, 상품 데이터에 새로운 상품 내용을 모델에 반영하려면, 모델을 다시 학습해야 함

✅ 상품이 일 단위, 주 단위로 들어오는 경우, 그때마다 모든 걸 학습할 수 없음

2️⃣ 망각(Forgetting) 대응 어려움

✅ 상품 내용 일부 수정 되었을 때, 사용 모델에 추가 데이터로 재학습하더라도 기존 학습된 내용들이 잊혀지지 않음

✅ 기존 + 새로운 내용 섞여 새로운 답변 나올 수 있음

3️⃣ 원문 위치, 첨부파일 제공 ㅇ려움

✅ PoC 진행 목적? 상담사 분들이 업무에 활용

✅ Rag 같은 경우, 원문 혹은 첨부 파일을 인덱스로 물어와서 같이 답변줄 수 있음

✅ PEFT만 단독 사용할 때, 이 부분 불가능

➡️ RAG(검색 증강 생성) 결합 필요

---

PEFT + RAG 결합

✅ RAG, PEFT 각각의 장단점 조합

✅ RAG의 장점인 최신 데이터 적용 용이, 외부 첨부 자료 연결 가능에 PEFT의 도메인 특성 파인튜닝 결합하면 답변 자체 품질도 향상될 수 있음

---

PEFT & RAG 결합 Architecture

✅ AWS 환경에서 도메인에 특화된 모델로 자체 호스팅해 성능과 가용성 개선된 아키텍처 구성

---

평가 방법

✅ 정성적 요소 평가 위해 5개 카테고리 질문(프로세스에 대한 설명, 기능/내용, 상품 추천, 조건 탐색, 비교) 생성

✅ 질문의 표현법? 단답형, 간결한 문장형, 일반 문장형 등 다양하게 준비해 총 50개 데이터 구축

✅ 평가 항목인 정확도, 상세함의 경우, 정답이고 문장 구조가 괜찮으면 각 2점, 일부 미흡하거나 부족하면 1점, 오답이고 이상한 구조로 답변하면 0점으로 평가 진행

 

---

평가 화면 예시

 

---

PEFT, RAG, PEFT & RAG 실험 결과 1

✅ Base KuLLM은 파인튜닝 거치지 않고, 배포된 pretrained 된 모델 + RAG 아키텍처 결합

✅ RAG & PEFT? RAG 아키텍처에서 답변 생성하는 모델을 PEFT 모델에 결합했을 때 성능(주황색 그래프)

➡️ 도메인 적용했을 때, Base KuLLM 보다 성능 훨씬 향상

➡️ 일부 모델들의 경우, 오버피팅이 발생했는지 RAG에서 제공하는 Document 정보를 잘 활용하지 못한 것 확인

➡️ RAG + PEFT 모델이 단독 PEFT 보다 전반적으로 성능 향상

---

PEFT, RAG, PEFT + RAG 실험 결과 2

✅ 평가 시 사용한 생성 질문 5개 카테고리별 정답 비율 높은 카테고리 ✅ 단순 설명(기능/내용, 조건)은 타 항목 대비 높은 성능 ✅ 논리 요소 포함(상품 추천, 비교, 프로세스)에서는 상대적으로 낮은 성능 확인	카테고리별 성능 상이함 원인 분석 ✅ 허깅페이스 Base KuLLM(파인튜닝 전)이 pretrained되는 과정에서 학습되었던 데이터 찾아보았음 ✅ 프로세스, 비교 데이터들이 단순 설명 데이터보다 비중 적음 ➡️ 특정 카테고리 성능 올리기 위해서는 해당 데이터셋 위주로 데이터 보완해 학습 필요

 

---

4. 결론 및 향후 계획

✅ sLLM 모델과 RAG 아키텍처 결합해 어떻게 하면 성능 향상할 수 있는지 확인할 수 있는 PoC

✅ PoC 단계에서는 12.8B를 사용했는데, 추후 사내 적용에는 70B 등 큰 모델을 활용해 PoC 고려하고 있음

✅ Instruction 품질 굉장히 중요. 데이터를 많이 타는 모델인 만큼 좋은 데이터가 있어야지 좋은 모델 나올 수 있음

✅ RAG 아키텍처에서도 prompt 보강, embedding 모델에서 나오는 결과물과 질문에 대한 검색 알고리즘 보완해 추후 개선 계획