혜야의 코딩스토리

[LLM 활용] 파인튜닝과 RAG 본문

꿈 : 멋진 개발자 🧸/AI, LLM

[LLM 활용] 파인튜닝과 RAG

hyeya_ 2024. 11. 25. 16:16

파인튜닝, RAG를 활용해 어떤 서비스를 만들 수 있는지 공부하고,
공부한 내용을 비개발자분들께 설명하기 위해 정리했던 내용입니다. 😶


📍 Pre-trained Model (사전 학습 모델)

Pre-trained Model(사전 학습 모델)은 방대한 양의 데이터를 사용하여 미리 학습한 후, 새로운 작업을 수행할 때 이 학습된 지식을 활용하는 모델을 말합니다.

ex) GPT, Llama, Gemini 등

 

이해를 돕기 위해 사전 학습 모델 방식으로 이메일이 스팸인지 아닌지 판단하는 자연어 처리 기능을 만든다고 생각해보겠습니다.

✉️ 이메일이 스팸인지 아닌지 판단하는 모델 만드는 방법 📧

  1. 이메일 데이터를 많이 모읍니다.
  2. 각 이메일이 스팸인지 아닌지 표시합니다.
  3. 이렇게 만든 데이터를 훈련 데이터 삼아서 Machine Learning 모델(Deep Learning도 물론 포함입니다)을 훈련시킵니다.

이 방법은 신뢰도 있고 안정적인 방법이지만 당연히 만족스럽지 못한 점들이 있습니다.

  • 좋은 성능을 내려면 모아야할 데이터가 아주 많습니다. 특히 각 이메일에 스팸인지 아닌지 표시하는 일은 더더욱 어렵습니다.
  • 이렇게 모아도 언어라는 특성상 전 세계의 다양한 이메일을 처리하기에는 한계가 있습니다.

💡 그 때 누군가 아이디어를 냅니다.
▼  

  • 스팸인지 아닌지 표시된 이메일 데이터를 많이 모으는 것은 어렵다.
  • 하지만 스팸인지 아닌지 표시 안 된 이메일 데이터를 모은 건 상대적으로 쉽다.

=> 이메일인지 아닌지 관계없이 일반 텍스트 데이터는 인터넷에 넘쳐난다. 그렇다면...

  1. (스팸인지 아닌지) 아무 레이블링이 안 된 그냥 텍스트를 잔뜩 모아서 언어를 이해하는 모델을 하나 만들고
    => Pre-trained Mode (사전 학습 모델)
  2. 이 모델을 이메일 스팸 기능으로 특화시키면 비슷한 효과가 나지 않을까? 바닥부터 만들 때보다는 스팸인지 아닌지 표시된 데이터가 훨씬 덜 필요하겠지?
    => Fine Tuning(미세 조정)

📍 Fine Tuning (파인 튜닝)

 

Pre-training과 Fine-Tuning은 딥러닝 훈련 관점에서 본질적으로 같은 일입니다.

그렇다면 Pre-training와 Fine Tuning의 차이는 무엇일까요?

▼  

 

Pre-training은 아무것도 없는 바닥에서 부터 훈련을 시작하는 반면,

Fine Tuning은 이미 Pre-training을 통해 언어 관점에서 최적화된 상태에서 훈련을 시작합니다. 바닥부터 시작하는 것이 아니기 때문에 최적값을 찾기까지 시간이 훨씬 덜 걸립니다.

 

서울에서 출발해서 부산이나 광주로 간다고 생각해보죠. Pre-training은 나를 대전까지 데려다주는 역할입니다. 그렇다면, Fine Tuning 은 대전->부산 만큼만 가면 되는 원리입니다.


Pre-trained Model(사전 학습 모델)을 직접 만드는 어려움과 Fine Tuning의 장점이 맞물려 다양한 Fine Tuning 기법과 Fine Tuning 된 모델들이 쏟아져 나오기 시작합니다.

 

이렇게 모두가 행복해질 즈음 또다른 문제가 생깁니다. Pre-trained Model(사전 학습 모델)이 점점 커지고 강력해지면서 Fine Tuning 또한 매우 어려운 일이 되갑니다.

 

Fine Tuning은 Pre-training 보다 가벼운 훈련은 맞지만 여전히 모델 전체를 훈련시키는 방식입니다. Pre-training이 70억개의 파라미터를 훈련시켜야한다면, Fine Tuning도 동일하게 70억개의 파라미터를 훈련시켜야합니다.

 

Fine Tuning이 Pre-training 보다는 가볍다고는 하지만 Pre-trained Model 자체가 커지면서 Fine Tuning을 위한 시간, 노력, 비용도 기하급수적으로 늘어나기 시작합니다.


📍 Parameter Efficient Fine Tuning (PEFT) : 효율적 파라미터 파인튜닝

Parameter Efficient Fine Tuning (PEFT)은 이름 그대로 Fine Tuning을 하되 (전체 다 훈련하지 말고) Parameter Efficient 하게 해보자는 아이디어입니다.

핵심 아이디어는 "파인튜닝 할 때 정말로 Pre-trained Model(사전 학습 모델)의 파라미터 전체를 훈련시켜야할까?"에서 시작합니다.

내가 하려는 일은 겨우 이메일이 스팸인지 아닌지 판단하는 일인데 이 거대한 Pre-trained Model(사전 학습 모델) 전체를 학습시킬 필요는 없을 것 같은데?”라는 생각이죠.

 

그래서 최근에는 적은 양의 파라미터만 훈련시켜 Full Fine Tuning과 같은성능을 내는 PEFT(Parameter Efficient Fine-tuning) 기법이 많이 사용됩니다.


📍 LoRA (Low-Rank Adapation)

PEFT 중 가장 유명하고 요즘 표준처럼 쓰이는 방법이 바로 LoRA입니다.

Full Fie Tuning 대비 아주 적은 양의 파라미터만 훈련시키면서, Full Fine Tuning과 같거나 심지어 더 좋은 성능을 내기도 합니다.

 

하지만, LoRA 기법으로 파인튜닝을 진행하더라도 학습 데이터 수집, 태깅(가공), 학습(GPU 필요) 과정이 필요합니다. 적은 양의 파라미터만 훈련시키기 때문에 이 파라미터의 데이터 품질이 매우 중요합니다.

 

학습시키는 파라미터가 자주 변경되는 데이터라면, 파인튜닝 작업을 여러 번 진행해야 하고, 그때마다 시간, 비용, 자원이 필요합니다. 따라서 파인튜닝을 진행하는 데이터는 고정된 형식의 데이터여야 좋습니다.

 

그렇다면 변경이 잦은 데이터는 어떻게 활용할 수 있을까요?


📍 RAG (Retrieval Augmented Generation) : 검색 증강 생성

=> 변경이 잦은 데이터라면 RAG 기법을 사용하면 좋습니다.

 

Retrieval이란 ‘검색’이라는 의미보다는 ‘어디선가 가져오는 것, 집어오는 것‘입니다.

즉 어딘가에 가서 요청된 무엇인가를 집어오는 것을 의미합니다.

Augmented는 ‘증강되었다’라는 의미이며 즉 무언가 덧붙이거나 보태어 더 충실하게 좋아졌다는 의미입니다.

Generation은 사용자 질문/질의에 대한 응답을 텍스트로 생성하는 것을 의미합니다.

 

🍀 RAG의 이점

  1. 최신의 정확한 응답 제공: RAG는 LLM의 응답이 정적이고 오래된 학습 데이터에만 의존하지 않도록 보장합니다. 오히려 모델은 최신 외부 데이터 소스를 사용하여 응답을 제공합니다.
  2. 부정확한 응답 및 환각 현상 감소: LLM 모델의 출력은 관련된 외부 지식에 기반하므로 RAG는 부정확하거나 허구의 정보를 사용한 대응(환각 현상)의 위험을 완화하기 위해 노력합니다. 출력에는 원본 출처의 인용이 포함될 수 있으므로 사람이 확인할 수 있습니다.
  3. 도메인별 관련 응답 제공: LLM은 RAG를 사용하여 조직의 독점 데이터 또는 도메인별 데이터에 맞게 상황에 맞는 관련성 높은 응답을 제공할 수 있습니다.
  4. 탁월한 효율성 및 비용 효과성: 도메인별 데이터로 LLM을 맞춤 구성하는 다른 접근 방식에 비해 RAG는 간단하고 비용 효율적입니다. 조직은 모델을 맞춤 구성할 필요 없이 RAG를 배포할 수 있습니다. 이는 모델을 새로운 데이터로 자주 업데이트해야 할 때 특히 유용합니다.

🍀 RAG의 사용 사례

  1. 질의 응답 챗봇: LLM을 챗봇과 통합하면 회사 문서 및 지식 베이스에서 보다 정확한 답변을 자동으로 도출할 수 있습니다. 챗봇은 고객 지원 및 웹사이트 리드 후속 조치를 자동화하여 질문에 답변하고 문제를 신속하게 해결하는 데 사용됩니다.
  2. 검색 증강: LLM에서 생성된 답변으로 검색 결과를 보강하는 검색 엔진과 LLM을 통합하면 정보 쿼리에 대한 응답을 개선하고 사용자가 업무를 수행하는 데 필요한 정보를 더 쉽게 찾을 수 있습니다.
  3. 지식 엔진 — 데이터에 대한 질문하기(예: HR, 규정 준수 문서): 회사 데이터를 LLM의 컨텍스트로 사용할 수 있으며, 이를 통해 직원들은 복리후생 및 정책과 관련된 HR 질문, 보안 및 규정 준수 질문을 포함하여 질문에 대한 답변을 쉽게 얻을 수 있습니다.

📍 RAG기법을 활용한 서비스 워크 플로우

  1. 문서에서 텍스트를 추출하여 청크로 분할 -> 분할된 청크는 임베딩 처리 후 -> 벡터스토어에 저장 (인덱싱 과정)
  2. 사용자의 질문(Query)은 임베딩 처리하여 벡터스토어에서 유사도 검색
  3. 벡터화된 질문으로 벡터화된 문서들 중 가장 관련도가 높은 문서 도출 -> 문서 검색 결과를 포함하여 기존 프롬프트 확장
  4. 프롬프트 + 사용자의 질문 + 문서 검색 결과를 LLM에 전달하여 자연어 답변 생성 요청
  5. LLM이 생성해준 답변을 사용자에게 전달

📍 파인튜닝과 RAG, 어떻게 활용할 수 있을까?

파인튜닝과 RAG 각 접근 방식의 장점을 살리고 단점을 보완한다면, 강력하고 유용한 서비스를 만들 수 있습니다.

 

1. 기본 성능 향상

  • 파인튜닝된 모델을 사용하여 도메인 특화된 지식과 성능을 확보할 수 있습니다.
  • 파인튜닝된 모델이 기본적으로 제공하는 높은 품질의 응답을 통해 사용자 만족도를 높일 수 있습니다.

2. 최신 정보 제공

  • RAG를 통해 최신 정보를 실시간으로 반영할 수 있습니다.
  • 새로운 데이터가 필요한 질문에 대해 빠르게 최신 정보를 검색하고 이를 기반으로 답변을 생성할 수 있습니다.

3. 환각 최소화

  • 파인튜닝된 모델은 특정 도메인에서 높은 정확성을 제공하며, RAG를 통해 검색된 정보로 이를 보완하여 환각을 줄일 수 있습니다.
  • 검색된 정보에 기반하여 더 신뢰할 수 있는 답변을 제공할 수 있습니다.

4. 유연성과 확장성

  • 파인튜닝된 모델을 기본으로 하고 RAG를 추가하여 더 유연하고 확장 가능한 시스템을 만들 수 있습니다.
  • 파인튜닝된 모델이 잘 처리하는 부분은 그대로 사용하고, 추가적인 정보가 필요한 경우 RAG를 활용하여 보완할 수 있습니다.

📍 파인튜닝 활용 시 고려할 점

  • 데이터가 고정되어 있어 최신 정보 반영, 변경이 어렵습니다
  • 프로젝트가 진행되면서 학습시켰던 데이터의 변경이 필요한 경우 다시 파인튜닝 작업이 다시 진행되어야 합니다.
  • 파인튜닝 작업을 위해 선택했던 Pre-trained Model을 변경하고 싶은 경우에도 파인튜닝 작업이 다시 진행되어야 합니다.
    (ex. GPT에서 Llama로 변경)
  • 모델의 크기나 복잡성에 따라 파인튜닝에 많은 자원이 필요할 수 있습니다.

📍 RAG 사용 시 고려할 점

  • 검색 단계와 생성 단계를 거치기 때문에 응답 시간이 길어질 수 있습니다.
  • 검색된 정보의 품질에 따라 생성된 응답의 품질이 좌우됩니다.