검색 대신 챗봇에 먼저 물어보는 게 일상이 되어 버린 요즘, 이제 LLM(Large Language Model)은 혁신 기술에서 하나의 트렌드가 된 것 같습니다. 특정 산업 분야 가리지 않고 LLM이 사용되고 있다 보니, 모든 기업에서 LLM을 도입해 새로운 서비스를 제공하길 원하고 있습니다. 이로 인해 LLM을 도입하기 위해 어떻게 해야 하는지 궁금한 분들이 있을 것 같아 한 번 정리해 봤습니다. 이 글은 LLM을 만드는 대표적인 방법 두 가지, 파인튜닝(fine tuning)과 RAG(Retrieval Augmented Generation) 기법에 대한 개괄적인 내용을 다루고 있어 LLM에 대해 이제 막 공부를 시작한 사람들, LLM 도입을 검토 중인 사람들이 보면 좋을 것 같습니다.
✔️ LLM 모델을 만드는 3가지 방법
(1) 사전학습하기 (Pretraining)
기업이 맞춤형 모델을 처음부터 개발하는 방법입니다. 이를 위해서는 숙련된 ML 엔지니어, 대량의 데이터, 그리고 충분한 인프라가 필요합니다. 이렇게 대량의 데이터로 모델을 사전 학습하는 과정을 Pretraining 라고 부릅니다. 그리고 pretraining을 통해 만들어진 모델을 사전학습 모델(pre-trained model)이라고 부르며, Google, Meta, 네이버, LG AI Research 등 대규모 기업들만이 이 방식으로 LLM을 출시했습니다. 대규모 언어 모델을 처음부터 사전 학습하려면 막대한 비용이 들기 때문에 해당 방법을 시도하기엔 진입장벽이 매우 높습니다. 참고로 GPT-3 모델의 경우 사전 학습 비용은 약 180만 달러(한화 약 25억 원)가 들었다고 합니다.
(2) 파인 튜닝하기 (Fine Tuning)
사전 학습 모델에 도메인 특화 데이터를 추가로 학습시켜 모델을 최적화하는 방식입니다. 이를 통해 모델은 특정 분야에 대한 전문 지식을 습득하고 정확하고 전문적인 답변을 제공할 수 있습니다. 예를 들어, 의학분야에서 의학전문지식으로 파인튜닝을 진행한 모델은 환자의 의학적 질문에도 답할 수 있게 되고, 법률지식을 학습한 모델은 법적 문제에 대해 전문적으로 답변할 수 있습니다. 그러나 파인튜닝을 하는 데에도 시간과 비용이 많이 소요되고, 모델이 범용적으로 쓰이기 어렵습니다.
(3) 사전 훈련 모델을 활용한 맥락 검색 (RAG, Retrieval Augmented Generation)
외부 데이터를 Vector DB에 저장하고, 질문과 관련된 데이터를 찾아 모델에 제공해 답변하는 RAG(Retrieval Augmented Generation) 기법을 활용합니다. 개발 비용이 저렴하고 최신 데이터를 활용할 수 있으며, 할루시네이션 문제도 줄일 수 있어 최근 가장 많이 활용되고 있습니다.
Vector DB : 외부 데이터를 저장하고 유사도 검색을 수행하는 DB (예: FAISS, Milvus)
할루시네이션(Hallucination) : 편향되거나 불충분한 학습 데이터로 인해 LLM이 부정확한 정보를 생성하는 현상
✔️ 파인튜닝 (Fine-Tuning)
파인튜닝의 정의
파인튜닝은 사전학습된 모델을 특정 작업에 맞게 추가로 학습시키는 과정입니다. 기존 LLM도 성능이 좋아 웬만한 질문에 대답을 잘해주고 있지만 LLM이 학습하지 않은 내용에 대해 질문을 한다면 대답을 못할 수밖에 없습니다. 그렇기에 전문적인 답변을 하는 챗봇을 만든다면 전문적인 내용이 담긴 데이터셋을 구성하여 학습을 시켜야 합니다.
파인튜닝의 주요 단계
파인튜닝은 데이터를 기반으로 학습을 진행하는 것이기 때문에 머신러닝, 딥러닝의 학습 과정과 매우 유사합니다. 대량의 데이터로 학습한 Base LLM을 기반으로 새로운 train data를 이용해 재학습(finetuning)을 진행하고, 답변을 통해 성능을 테스트하며 다시 재학습(re-finetuning)을 진행하게 됩니다.
구체적인 프로세스를 정리해 보면 다음과 같습니다.
(1) 데이터셋 준비
목표 작업에 적합한 데이터를 수집하고 전처리를 진행합니다. 전처리에는 불필요한 데이터를 제거, 데이터 정규화, 토큰화 등 수행하는 작업이 포함됩니다. 레이블링이 필요한 경우에는 적절한 기준을 마련하여 데이터셋에 대한 레이블링을 진행합니다.
레이블링(labeling) : 학습을 위해 데이터셋의 정답을 부여하는 과정
1. 감성분석 레이블링 예시
- "이 제품 정말 만족스러워요! 추천합니다." -> 긍정
- "배송이 너무 늦고, 제품도 불량이네요." -> 부정
2. 문서 분류 레이블링 예시
- "비트코인 가격이 급등하면서 암호화폐 시장이 다시 활기를 띠고 있다." -> 금융
- "손흥민 선수의 골로 토트넘이 3연승을 기록했다." -> 스포츠
(2) 사전 학습 모델 선택
작업 성격(문서 요약, 감성 분석, 질의응답 등)에 맞는 사전 학습 모델(Pretrained Model) 선택합니다. 선택할 때는 데이터셋 크기, 모델의 구조 (GPT, BERT, LLaMA 등), 모델의 강점과 한계 (성능, 비용, 속도), 사용 가능한 컴퓨팅 리소스 등을 고려해서 선택해야 합니다.
(3) 파인튜닝 전략 정의
전체 모델을 조정할지, 특정 레이어만 조정할지 결정해야 하는데요. 모델 전체를 재학습하는 Full Fine-tuning 방법을 쓰게 되면 높은 성능을 얻을 수 있지만 많은 자원이 필요합니다. 반면 상위 레이어만 조정하여 학습을 진행하는 Partial Fine-tuning (Adapter-based, LoRA 등) 방법을 쓰게 되면 특정 레이어만 조정하게 되어 효율적으로 학습이 가능합니다. 다만 성능이 다소 낮을 수는 있습니다. 작업 특성과 가용할 수 있는 자원을 고려해, 작업이 기존 모델과 크게 다르면 Full Fine-tuning을, 유사하면 Partial fine-tuning 방법을 선택합니다.
(4) 모델 매개변수 초기화
선택한 파인튜닝 방식에 따라 모델 매개변수를 초기화합니다. Full Fine-tuning 은 모델 전체 가중치를 업데이트하게 되고, 특정 레이어만 미세 조정하거나, 모델의 특정 부분에 Adapter 모듈 추가 후 학습할 수 있습니다.
(5) 하이퍼파라미터 설정
적절한 학습률(Learning Rate), 배치 크기(Batch Size), 훈련 에포크(Epochs) 등 훈련에 필요한 하이퍼파라미터를 설정합니다. 하이퍼파라미터는 정해진 것은 없기에 초기에는 가용할 수 있는 자원에 따라서 적절하게 하이퍼파라미터를 설정합니다.
(6) 파인튜닝 진행
준비된 데이터와 설정값을 바탕으로 모델 학습을 진행합니다. 학습 과정 중에 Loss 가 줄어들고 있는지, validation 성능은 어떤지, 과적합이 발생하지는 않는지를 체크하며 학습을 진행합니다.
(7) 모델 평가 및 튜닝
학습된 모델을 검증 데이터로 평가하며 모델을 최적화하는 단계입니다. 성능 지표 (Accuracy, F1-score, BLEU, ROUGE 등)를 기반으로 하이퍼파라미터를 조정하며 추가 학습을 진행하여 최적의 하이퍼파라미터를 찾습니다.
(8) 최종 성능 테스트
모델을 실전 환경에서 테스트하여 예상 성능을 확인합니다.
(9) 모델 배포 및 적용
모델을 실서비스 환경에 배포 (API 형태, 온프레미스, 클라우드 등)하는 단계입니다. MLOps 도구(Jenkins, ArgoCD, MLflow 등)를 활용하여 배포를 자동화하고 지속적인 모델 모니터링을 통해 모델을 업데이트합니다.
✔️ RAG(Retrieval-Augmented Generation)
RAG 등장배경
LLM은 방대한 데이터를 기반으로 학습되어 인간처럼 창작도 잘하고 논리적으로 사고도 잘해 다양한 분야에서 뛰어난 성능을 보여주고 있습니다. 하지만 상용화 과정에서 알지 못하는 내용도 마치 정답처럼 그럴싸하게 답변하는 '할루시네이션' 문제가 발생하였습니다. LLM이 학습된 데이터 기반으로 답변을 제공하기 때문에 최신 정보에 대한 답변을 못하는 것이 당연하지만, LLM이 워낙 인간처럼 답변하는 걸 잘 학습해서 명확한 출처 없이도 그럴싸하게 답변을 하게 됩니다. 이런 문제를 해결하기 위해 근거있게 말할 수 있도록 RAG(Retrieval-Augmented Generation, 검색 증강 생성)가 나왔습니다. RAG는 Retrieval(정보를 검색) + Augmented(증강) + Generation(응답 생성)의 줄임말로, 외부 지식을 활용해 질문과 관련된 정보를 검색하고 해당 정보를 기반으로 답변을 하는 방법입니다.
RAG의 주요 단계
1. 사용자 질문 입력 (Query)
사용자가 알고자 하는 정보를 입력합니다.
2. 데이터베이스에서 관련 정보 검색 (Search)
사용자 질문에 대한 정확한 답변을 제공하기 위해, 외부 데이터(모델이 학습하지 않은 데이터)를 활용하여 관련 정보를 검색합니다. 외부 데이터를 검색하기 위해 데이터베이스를 만들고 해당 데이터베이스에서 정보를 추출합니다.
- (1) 데이터 임베딩
- 기업이나 조직의 내부 데이터(예: 문서, 보고서, 지식 베이스 등)를 임베딩 모델을 사용하여 텍스트를 컴퓨터가 이해할 수 있게 벡터 형태로 변환합니다.
임베딩(Embedding) : 텍스트를 벡터화하여 의미를 수치적으로 표현
- (2) 벡터 DB 구축
- 임베딩된 데이터를 효율적으로 저장하고 검색하기 위해 벡터 데이터베이스를 구축합니다.
- (3) 쿼리(사용자 질문) 벡터화
- 사용자의 질문을 임베딩 모델을 통해 벡터로 변환합니다.
- (4) 관련 문서 추출
- 벡터 데이터베이스에서 사용자 질문 벡터와 유사도가 높은 상위 k개의 문서를 검색합니다.
3. 검색된 정보를 LLM에 전달 (Deliver relevant documents)
추출된 상위 k개의 문서를 LLM에 입력하여, 모델이 사용자 질문과 관련된 세부 정보를 이해할 수 있도록 합니다.
4. 쿼리와 검색 정보를 바탕으로 최종 답변 생성 (Response)
LLM은 사용자 질문과 제공된 문서를 기반으로 종합적인 답변을 생성합니다. 이를 통해 최신 정보나 특정 도메인 지식을 반영하여 정확하고 상세한 답변을 제공할 수 있습니다.
RAG의 장점
이처럼 RAG의 장점은 최신 데이터를 기반으로 답변하기 때문에 (1) 할루시네이션이 감소되고 답변에 대한 (2) 참고 문서도 함께 제공하여 신뢰성을 확보할 수 있습니다. 또한, 외부 데이터를 활용하기 때문에 별도의 학습이 불필요해 (3) 시간과 비용이 절감되고, 특정 데이터셋에 맞춰 학습하지 않고 기존 LLM 모델을 그대로 사용하여 다양한 분야, 다양한 질문에도 응답이 가능한 (4) 범용성 있는 모델을 만들 수 있습니다.
✔️ Fine tuning vs. RAG
그래서 Fine tuning 과 RAG 중 어떤 기법을 사용해야 할까요?
Towards Data Science의 아티클 ‘Which is the best tool to boost your LLM application?’에서 RAG와 파인튜닝 선택을 위해 고민해야 할 사항들을 다음과 같이 정리하고 있습니다.
RAG vs. 파인튜닝 선택을 위한 질문리스트
1. 애플리케이션이 모델 외부 데이터 리소스에 접근할 수 있어야 하는가?
2. 모델의 행동과 스타일 수정이 필요한가?
3. 할루시네이션 방지가 중요한가?
4. 라벨링된 데이터 확보가 가능한가?
5. 데이터가 얼마나 자주 변하는가?
6. 의사결정 과정의 투명성이 필요한가?
각 질문에 대한 적절한 기법을 답변하면 아래와 같습니다.
1. 애플리케이션이 모델 외부 데이터 리소스에 접근할 수 있어야 하는가?
: 파인튜닝된 모델은 특정 시점까지의 데이터만 학습되기 때문에 외부 데이터에 대한 상시 접근이 필요하면 RAG 사용이 효율적입니다.
2. 모델의 행동과 스타일 수정이 필요한가?
: 특정 뉘앙스나 용어 적용 시 파인튜닝이 유리합니다. RAG는 정보 검색만 가능하며 스타일 수정은 불가능합니다. 하지만 프롬프트 엔지니어링으로 충분히 뉘앙스나 용어 적용도 가능하기 때문에 RAG와 프롬프트 엔지니어링을 결합해서 사용한다면 리포트 형식으로 출력을 하거나 특정 말투로 답변하게 만들 수도 있습니다.
3. 할루시네이션 방지가 중요한가?
: 파인튜닝은 추가 데이터를 학습하여 할루시네이션을 줄일 수 있으나, 학습되지 않은 새로운 정보를 묻는 질문에서 여전히 할루시네이션이 발생할 수 있습니다. RAG는 적재된 정보 기반으로 답변하기 때문에 할루시네이션 방지에 더 효과적입니다. 다만, 마찬가지로 적재된 정보에 의존적이기 때문에 정보 자체가 틀린 정보이거나 적재되지 않은 정보라면 틀린 답변을 할 수 있습니다.
4. 라벨링된 데이터 확보가 가능한가?
: RAG는 라벨링 데이터셋이 필요하지 않지만, 파인튜닝은 양질의 도메인 데이터가 반드시 필요합니다. 충분한 라벨링 데이터를 확보하지 못한다면 파인튜닝의 성능은 기대하기 어렵습니다.
5. 데이터가 얼마나 자주 변하는가?
: 데이터 변동이 잦다면 RAG가 유리합니다. 파인튜닝은 데이터를 반영하기 위해 추가 학습이 필요하지만 RAG는 Vector DB에 데이터를 추가하면 되기 때문에 더 간편합니다.
6. 의사결정 과정의 투명성이 필요한가?
: 파인튜닝은 블랙박스지만, RAG는 검색 단계를 거쳐 의사결정 과정이 투명합니다. 답변을 참고한 문서가 어떤 것인지, 몇 번째 중요한 문서를 참고했는지 알 수 있기 때문에 높은 책임성이 필요하다면 RAG가 적합합니다.
Fine tuning | RAG | |
정의 | 기존의 사전학습(Pretrained) 모델을 추가 학습시켜 특정 task에 최적화하는 기법 | 외부 데이터베이스(벡터 DB 등)에서 관련 정보를 검색하여 LLM의 응답 생성에 반영하는 기법 |
장점 | - 도메인 특화 지식 학습하여 전문 지식 답변 가능 - 특정 용어나 스타일 반영하여 답변의 일관성 확보 - 모델이 이미 지식을 학습한 상태로 빠른 응답 가능 |
- 최신 데이터 반영 용이 - 범용성 유지 : 별도 학습 없이 다양한 도메인에 적용 가능 - 할루시네이션 감소 및 참고 문서 제공 |
단점 | - 추가 학습에 시간, 비용, 자원이 많이 소요됨 - 학습 데이터셋에 맞춰 응답하므로 범용적이지 않음 - 잘못된 학습 데이터로 학습 시 틀린 답변 가능 |
- 검색 품질에 민감 :검색 결과가 부정확하면 잘못된 정보 전달 가능 - 검색을 위한 latency 존재 - 실시간 검색을 위한 인프라 구축 필요 |
적용 상황 | - 도메인 특화 서비스(의료, 법률 등) 구축 | - 최신 정보 반영이 필요한 동적 환경 - 비교적 범용적이고 빠른 개발 및 유지보수가 필요한 경우 |
개발 및 운영 비용 | 상대적으로 높음 (데이터 수집, 라벨링, 재학습 비용 등) | 상대적으로 낮음 (외부 데이터 연결 및 검색 인프라 구축 비용) |
✔️ 결론
LLM이 많은 도메인, 많은 task(예측, 분류, 감성분석 등)에서 혁신을 가져온 것은 분명한 사실입니다. 하지만 워낙 모델이 커서 기존의 머신러닝과 딥러닝보다 더 많은 자원과 시간을 소모하기 때문에 쉽게 시도하고 간단하게 실험해 보기가 어렵습니다. 개인적인 경험 상 OOM없이 파인튜닝을 진행하려고 한다면 최소 64GB 메모리, 100GB SSD 용량 정도가 필요하기 때문에 처음부터 LLM에 대한 학습을 진행하기보다 시도할 수 있는 것(프롬프트 엔지니어링)부터 차근차근 LLM에 대한 도입을 진행하는 것이 좋다고 생각합니다.
프롬프트 엔지니어링을 우선적으로!
우선, 프롬프트 엔지니어링을 통해 컨텍스트 학습을 시켜 모델 응답을 확인해 봅니다. 최근 나온 LLM이 워낙 성능이 좋다 보니 따로 fine-tuning을 하지 않고도 프롬프트 엔지니어링을 통해서 충분히 원하는 답변을 얻을 수 있습니다. 원하는 답변 형식을 출력할 수 있고, 예측, 분류, 통계적 처리 등도 프롬프트에서 어떻게 답변을 출력하라고 명시함으로써 처리가 가능합니다.
최신 정보가 필요하다면? -> RAG
최신 정보가 계속 업데이트가 되어야 하는 동적 태스크에서는 RAG 사용이 좋습니다. 또한, 사실 정확성이 중요한 상황이라면 답변에 대한 출처를 명시할 수 있기 때문에 RAG가 적절합니다. Fine tuning은 특정 도메인의 데이터로 모델을 최적화하지만 시간과 비용이 많이 들고 범용성이 떨어진다는 단점이 있습니다. 반면, RAG는 모델의 범용성을 유지하면서도 도메인 특화 정보를 검색하여 도메인 특화 질문에 대해서도 잘 답변할 수 있기에 fine tuning 전 RAG를 먼저 시도해보는 것이 시간과 비용을 좀 더 절약할 수 있을 것이라 생각합니다.
도메인 특화,Specialized Tasks? -> Fine-tuning
일관성이 중요한 작업이지만 프롬프트 엔지니어링으로 일관된 응답이 어려울 경우 파인튜닝을 통해 일관성을 확보할 수 있습니다. 또한, 도메인 특화 지식이 필요한 작업(의료, 법률, 제조 등)은 라벨링 데이터가 충분히 확보된 상황이라면 파인튜닝을 통해 도메인 특화 LLM을 만들 수 있습니다. 하지만 OpenAI가 제공하는 파인튜닝 가이드 문서에서도 언급된 것처럼 파인튜닝은 시간과 자원이 많이 소모되기 때문에 프롬프트 엔지니어링 등 다양한 방법을 먼저 시도해 본 후에 파인 튜닝을 하는 것이 좋습니다.
어떤 기법을 적용해서 LLM을 개발할지 정하기 전 제공하려는 서비스가 어떤 것인지, task가 어떤 것인지 명확히 하는 것이 제일 중요합니다. 해당 task에 적합한 기법을 선택해서 모델 개발이 이루어져야 쓸데없는 자원 낭비를 막을 수 있습니다. 그렇다고 두 기법 중 하나만 선택해야 한다는 의미는 아닙니다. 만약 자원이 충분하고 실험할 수 있는 시간도 넉넉하다면 두 기법을 모두 사용해 성능을 최대화할 수도 있습니다. 하지만 대부분의 경우 한정된 자원 속에서 개발을 진행하기 때문에 기본적으로는 프롬프트 엔지니어링 -> RAG -> 파인튜닝 순으로 적용해보는 것을 추천드립니다.
'AI' 카테고리의 다른 글
[Causal Analysis] PC 알고리즘 (0) | 2025.03.30 |
---|---|
효과적인 프롬프트 엔지니어링 (기초) : 프롬프트 구성요소와 효과적인 프롬프트 구조 (0) | 2025.03.02 |
[최적화 알고리즘] 유전알고리즘 기본 개념 및 배낭문제 실습 (with python) (1) | 2024.12.22 |
[LLM] Fine-tuning시 early stopping 적용하기 (0) | 2024.03.14 |