AI 엔지니어 필독 논문 10개 — ③ 실무 적용과 학술의 속도 (RAG, LoRA, PEFT)

지금까지 본 7개 논문들은 기초 이론이었다. 이제 현실의 문제를 푼 논문들을 본다.

2020~2023년 사이:

• GPT-3 (1750억 파라미터) → ChatGPT → GPT-4
• BERT 수백 개의 변형
• Stable Diffusion 배포 버전들

이들을 실제로 운영하려면:

• 비용이 어마어마하다
• 동작이 불안정하다 (환각)
• 새로운 지식을 주입하기 어렵다

문제를 풀기 위한 세 논문

RAG (2020):          환각 감소, 실시간 정보
LoRA (2021):         효율적 미세조정, 저비용 학습
PEFT (2023):         범용 파라미터 효율화 프레임워크

8. RAG: Retrieval-Augmented Generation (2020)

문제: LLM의 환각(Hallucination)

ChatGPT에게 물음:
"한국 대통령 xxx의 생년월일은?"

답변: 1948년 3월 15일 (❌)
실제: 1950년 2월 22일 (또는 다른 값)

왜 틀렸나?
- 학습 데이터는 2021년까지
- 그 데이터의 정확도도 100%가 아님
- 모델은 "그럴듯한" 답을 생성할 뿐

환각의 근본 원인:

LLM은 "확률 게임"
→ P(단어|이전단어들)을 최대화할 뿐
→ 진실 유무는 관심 없음

예: "한국 대통령은 일반적으로 19xx년생이고, 이름은 두 글자..."
→ 그럴듯한 조합을 찾아낼 뿐

아이디어: 생성 전에 검색

RAG의 혁신은 간단하다:

"답을 만들기 전에, 관련 문서를 찾아서 답변 과정에 포함시키자"

기존 LLM:
질문 → [생성] → 답변 (환각 위험)

RAG:
질문
├─ [검색] 관련 문서 조회
│  (데이터베이스, 위키피디아, 회사 문서 등)
│
├─ [문맥에 추가] 검색된 정보를 프롬프트에 포함
│
└─ [생성] 신뢰할 수 있는 답변
   (근거 있는)

구체적 흐름:

질문: "한국 대통령 xxx의 생년월일?"

1. 검색 (Retriever):
   데이터베이스 검색 → 
   [문서1: "xxx 대통령, 1950년 2월 22일 태어남..."]
   [문서2: "xxx의 경력 흐름..."]

2. 문맥 강화:
   프롬프트 = "질문" + [문서1, 문서2]

3. 생성 (Generator):
   "문서에 따르면, xxx 대통령은 1950년 2월 22일..."

아키텍처

질문 임베딩 (Dense Vector)
    ↓
데이터베이스 검색 (FAISS, Elasticsearch 등)
    ↓
관련 문서 K개 반환
    ↓
프롬프트 구성
    ↓
LLM 생성 (근거 기반)

중요한 점:

• 검색 부분(Retriever)은 따로 학습 가능
• 생성 부분(Generator)은 기존 LLM 사용
• 두 부분 모두 개선 가능 (모듈화)

임팩트

• 환각 문제의 부분적 해결 — 근거 없는 답변 감소
• 최신 정보 반영 — 고정된 학습 데이터 대신 실시간 조회
• 출처 제시 가능 — 답변의 근거 문서 제공
• LLM 업데이트 불필요 — 검색 데이터만 갱신

실무 사례:

회사 내부 문서 RAG:
"2026년 연봉 인상 정책은?"
→ 회사 공식 문서 검색
→ 정확한 답변 생성

의료 진단 보조:
"증상 xxx에 대한 진단?"
→ 의료 논문/가이드라인 검색
→ 근거 기반 제안

9. LoRA: Low-Rank Adaptation of Large Language Models (2021)

문제: 거대 모델의 미세조정은 너무 비싸다

GPT-3 (1750억 파라미터) 미세조정 비용:

방법 1: 전체 모델 업데이트 (Full Fine-tuning)
- 메모리: 800GB+ (불가능)
- 계산: A100 GPU × 1개월
- 비용: $10,000+

방법 2: 필요할까? 너무 비싸서 아무도 못 함

왜 이렇게 비싼가?

모델 크기 = 파라미터 수
GPT-3: 175B (1750억개)

각 파라미터마다:
- 값 저장 (4 바이트)
- 그래디언트 저장 (4 바이트)
- 옵티마이저 상태 저장 (8 바이트)
→ 파라미터당 16 바이트

175B × 16 = 2.8 TB 메모리 필요
(A100은 40GB... 70배 모자람)

아이디어: 저-랭크 어댑터 (Low-Rank Adapter)

LoRA의 통찰은 모든 파라미터를 업데이트할 필요는 없다는 것:

가설:
"미세조정 중에 가중치 변화는 저-랭크 공간에 있다"
→ 즉, 작은 수의 "방향"으로 표현 가능

예:
[175억 파라미터 전체 업데이트] 대신
[작은 매트릭스 2개만 업데이트]로도 충분

구체적으로:
W (원래 가중치, 고정)
ΔW = A × B (학습할 부분)
     ↑   ↑
  r×d d×r  (r은 작은 값, 예: 4, 8, 16)

최종 가중치 = W + ΔW

숫자로 비교:

전체 미세조정:
175B × 4 바이트 = 700 GB 메모리

LoRA (r=4):
학습할 파라미터:
- A: 175B × 4 = 700M
- B: 4 × 175B = 700M
총: 1.4B (원래의 0.8%)

메모리: 1.4B × 4 바이트 = 5.6 MB (100배 이상 작음!)

구조

입력 → W (고정, 175B 파라미터)
    ↓
    + ΔW (학습, r=4인 경우 1.4B 파라미터)
    ↓
    출력

장점:

1. 메모리: 700GB → 56GB (충분한 GPU 1개)
2. 속도: 1개월 → 1일
3. 비용: $10,000 → $100
4. 유연성: 작업별 LoRA 모듈 여러 개 만들 가능

임팩트

• 온디바이스 LLM 가능 — 스마트폰에서 미세조정 가능
• 비용 혁명 — 모든 회사가 자기 모델 커스터마이징 가능
• LoRA 모듈 라이브러리 — HuggingFace에 수천 개 모듈 공유
• 표준 기법 — 현재 거의 모든 기업이 사용

실무 활용:

회사 1: LoRA-1 (고객 서비스 특화)
회사 2: LoRA-2 (의료 진단 특화)
회사 3: LoRA-3 (코딩 보조 특화)

모두 같은 기본 모델을 공유하면서
각자 커스터마이징된 동작

10. PEFT: Parameter-Efficient Fine-Tuning (2023)

맥락: LoRA 이후의 확장

LoRA는 혁신이었지만, 많은 변형이 나타났다:

2020: Adapter (스몇 레이어 삽입)
2021: LoRA (저-랭크 어댑팅)
2021: Prefix Tuning (접두사 학습)
2021: Prompt Tuning (프롬프트 최적화)
2022: DoRA (Direction and Magnitude)
2023: PEFT (모든 방법을 통합)

문제:

연구자 입장: 각 기법을 일일이 구현? → 지옥
개발자 입장: 어떤 기법을 쓸까? → 혼란

해결책: 통합 라이브러리

아이디어: 통합 프레임워크

PEFT는 파라미터 효율적 미세조정의 표준 라이브러리:

from peft import get_peft_model, LoraConfig, TaskType
 
# LoRA 설정
peft_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=8,  # LoRA의 랭크
    lora_alpha=32,
    lora_dropout=0.1
)
 
# 모델에 LoRA 적용
model = get_peft_model(base_model, peft_config)
 
# 학습하면 끝
model.fit(train_data)

통합하는 기법들:

LoRA              ← 가장 인기
Prefix Tuning     ← 접두사 토큰 학습
Prompt Tuning     ← 입력 프롬프트 최적화
P-Tuning          ← Prompt Tuning 개선
Adapter           ← 작은 네트워크 모듈 추가

임팩트

• 표준화 — 업계 표준 도구
• 접근성 — 연구자, 개발자 모두 사용 가능
• 조합 가능 — LoRA + Adapter 동시 사용 등
• 벤치마크 — 각 기법을 공정하게 비교

현재 생태계:

HuggingFace Transformers
    ↓
PEFT (파라미터 효율화)
    ↓
bitsandbytes (양자화)
    ↓
Flash Attention (빠른 어텐션)
→ 모두 함께 사용하면 온디바이스 LLM 가능

섹션: AI 논문의 "속도" — 왜 arXiv가 Nature를 이겼나?

이 10개 논문을 다시 보면:

학회 발표 경로:
1. 논문 작성 (6개월)
2. 컨퍼런스 투고 (1개월)
3. 심사 대기 (2개월)
4. 피드백 반영 (1개월)
5. 발표 (1개월)
→ 총 11개월 (최소)

arXiv 경로:
1. 논문 작성 (6개월)
2. arXiv 올리기 (24시간)
→ 총 6개월

시간 차이: 5개월 (40%)

AI는 왜 다른가?

전통 과학 (생물학, 화학):
- 실험 재현에 시간 걸림
- 동료 심사 필수
- 속도보다 신뢰성

AI (2010년대 이후):
- 코드 + 데이터 공개 (재현 쉬움)
- 커뮤니티 검증 빠름 (GitHub, Twitter)
- 논문 이전에 구현이 먼저
→ 속도 경쟁

사례: Transformer (2017) → ChatGPT (2022)의 진화 속도

2017/06: Attention Is All You Need (arXiv)
2017/07: Pytorch에서 구현 공개
2017/09: 컨퍼런스 발표 (NeurIPS)
2017/10: 수십 개 변형 논문 나옴

2018/10: BERT (Google)
2018/11: 공개 코드 (PyTorch)
2019/02: Hugging Face Transformers 라이브러리

2018/06: GPT (OpenAI)
2019/02: GPT-2 (더 큼)
2020/06: GPT-3 (1750억 파라미터)
2022/11: ChatGPT (공개)
→ 5년 만에 혁명

같은 기간 Nature 논문들:
- 여전히 리뷰 받는 중...

결과: 세 가지 관찰

1. 출판 속도가 아니라 공개 속도가 경쟁

   빠른 논문: arXiv (24시간)
   느린 논문: Nature (1년+)
   

2. 산업 채택이 평가 기준

   성공 논문: Google Search (BERT)
             ChatGPT (GPT 계열)
             Stable Diffusion (DDPM)
   
   실패 논문: 인용 많지만 미사용
   

3. 코드 공개 = 논문

   논문 + 코드 없으면: "종이일 뿐"
   코드 공개: "업계 표준"
   

10개 논문의 진화 경로

2013: VAE (생성 모델 이론)
      ↓
2014: GANs (경쟁 학습)
      ↓
2017: Transformer (효율적 처리)
      ↓
2018: BERT (이해)
2018: GPT (생성)
      ↓
2020: ViT (이미지 처리)
2020: DDPM (안정적 생성)
2020: RAG (정보 검색 통합)
      ↓
2021: LoRA (효율적 미세조정)
      ↓
2023: PEFT (통합 프레임워크)

결과: 모두 "대규모 모델을 효율적으로"라는 방향

최종 정리

인사이트: "논문 시대"는 끝났다

전통 학술 생태계:

논문 → 동료 심사 → 저널 게재 → 인용 → 영향력

시간: 1~3년
평가: 인용 수
영향력: 천천히

AI 생태계 (2020년 이후):

아이디어 → 코드 작성 (병렬)
    ↓
arXiv 올림 (24시간)
    ↓
코드 공개 (GitHub)
    ↓
커뮤니티 검증 (소셜, 이슈)
    ↓
상용 적용 (기업)
    ↓
컨퍼런스 발표 (선택)

시간: 1~6개월
평가: 채택도, 영향도
영향력: 즉각적

결론: AI 시대의 필독서는 Nature/Science가 아니라 arXiv + GitHub + 기업 블로그다.

다음 글: "실제 이 논문들을 구현하려면?" — 각 논문별 코드 가이드.