ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 카카오클라우드 - 클라우드 개발자 교육 15주차 후기.
    bootcamp 2026. 3. 11. 14:40

     

    1. 파인튜닝이란 무엇인가?

     

    AI 모델을 처음부터 학습시키는 것은 엄청난 비용과 시간이 필요함! 예를 들어 GPT-4 같은 대형 언어 모델을 처음부터 학습시키려면 수백억 원의 GPU 비용과 수개월의 시간이 필요하다.

    그래서 등장한 개념이 바로 파인튜닝(Fine-Tuning) 이다.

     

    더보기

    claude 피셜

     

    구분                                       사전학습                                                                  파인튜닝

    데이터 양 수백 GB ~ TB 규모 수백 ~ 수만 건
    비용 수십억 ~ 수백억 원 수만 ~ 수백만 원
    시간 수주 ~ 수개월 수시간 ~ 수일
    목적 범용 능력 학습 특정 태스크 특화

     

    3. 파인튜닝의 주요 기법들

     

    전체 파인튜닝 (Full Fine-Tuning)

    모델의 모든 파라미터를 업데이트하는 방식.

    [사전학습 모델 전체] ──→ 새 데이터로 전체 재학습

     

     

    전이 학습 (Transfer Learning)

    사전학습된 모델의 앞부분(특징 추출층)은 고정하고, 뒷부분(출력층)만 새로 학습하는 방식.

    [고정된 레이어들] → [고정된 레이어들] → [새로 학습하는 레이어]
       (특징 추출)         (패턴 인식)          (태스크 특화)

     

     

    프롬프트 튜닝 (Prompt Tuning)

    모델 파라미터는 전혀 건드리지 않고, 입력 앞에 붙이는 특수한 토큰(프롬프트)만 학습하는 방식.

    [학습된 특수 토큰들] + [실제 입력] → [고정된 모델] → 출력

     

     

    RLHF (인간 피드백 강화학습)

    ChatGPT 등에 사용된 방식으로, 인간의 평가를 바탕으로 모델을 개선

     
    모델 출력 → 인간이 평가 → 보상 모델 학습 → 모델 개선 → 반복

     

    YOLO란?

    YOLO는 파인튜닝 기법이 아니라, 이미지에서 물체를 감지하는 AI 모델임.. 파인튜닝과 함께 많이 언급되는 이유는, YOLO를 내 데이터에 맞게 파인튜닝해서 사용하는 경우가 매우 많다고 한다.

     

     

    [기존 방식 - R-CNN] 이미지 → 수천 개 영역 후보 생성 → 각각 분석 → 결과 (매우 느림, 2초 이상) [YOLO 방식] 이미지 → 그리드로 분할 → 한 번에 전체 분석 → 결과 (매우 빠름, 실시간 가능)

     

    YOLO의 동작 원리 모식도

    ┌────────────────────────────────┐
    │          입력 이미지            │
    │  ┌──┬──┬──┬──┬──┬──┬──┐       │
    │  │  │  │  │  │  │  │  │       │
    │  ├──┼──┼──┼──┼──┼──┼──┤       │
    │  │  │  │🐱│  │  │  │  │  ← 각 격자(그리드)가
    │  ├──┼──┼──┼──┼──┼──┼──┤       │     "여기 물체 있나?"를
    │  │  │  │  │  │🐶│  │  │       │     동시에 판단
    │  └──┴──┴──┴──┴──┴──┴──┘       │
    └────────────────────────────────┘
            ↓
    각 격자가 예측하는 것:
    1. 여기에 물체가 있을 확률
    2. 물체가 있다면 어떤 물체인가? (고양이? 강아지?)
    3. 물체의 정확한 위치 (바운딩 박스)

     

      전체 비교 요약

    기법                                                용도                        필요 메모리           학습 파라미터              적합한 상황

     

    Full Fine-Tuning 모든 모델 매우 많음 100% 충분한 GPU가 있을 때
    Transfer Learning CV/NLP 보통 10~30% 일반적인 파인튜닝
    Prompt Tuning LLM 적음 매우 적음 모델 수정 불가 시
    LoRA LLM 적음 0.1~1% LLM 파인튜닝의 표준
    YOLO (파인튜닝) 객체 탐지 보통 일부~전체 커스텀 객체 감지

     

     

    의문 1.

    LoRA를 적용하는 것보다 RAG를 효율적이고 안정적으로 구성하면 이게 답변이 더 정확하게 나오는거 아닌가?

     

    -목적이 완전히 다른 기술이다.

     

    [LoRA가 해결하는 문제]

    "모델 자체의 행동 방식, 말투, 추론 능력을 바꾸고 싶다"

    → 모델의 '뇌 구조'를 바꾸는 것

     

    [RAG가 해결하는 문제]

    "모델이 모르는 최신/특정 지식을 검색해서 답하게 하고 싶다"

    → 모델에게 '참고 자료'를 주는 것

     

    2. 그럼 언제 RAG고 언제 LoRA를 사용해야하나?

     

    - RAG를 구축해야 하는 경우

    지식이 자주 바뀌는 경우

     

    데이터 양이 충분하고 명확한 경우

     

    환각(Hallucination)을 줄여야 하는 경우

     

    빠르게 프로토타입을 만들어야 할 때

     

    - LoRA를 적용해야하는 경우

    모델의 말투/형식/도메인 언어를 바꿔야 할 때

     

    검색 자체가 불가능한 암묵적 지식의 경우

     

    지연시간(Latency)이 중요한 경우

     

    RAG의 검색 품질이 나쁠 때

     

     

    여기서 이전 글에서 작성하지 못한 RAG의 구성도? 파이프라인.

    --- ** claude ** ---

    1. 문서 수집 및 전처리

    └─ 어떤 형식? PDF? HTML? 어떻게 정제?

    2. 청킹(Chunking) 전략

    ├─ 고정 길이 청킹 (256, 512 tokens?)

    ├─ 문장 단위 청킹

    ├─ 의미 단위 청킹 (Semantic Chunking)

    └─ 계층적 청킹 (Parent-Child)

    3. 임베딩 모델 선택

    ├─ OpenAI Ada?

    ├─ BGE-m3? (다국어)

    ├─ KoSimCSE? (한국어 특화)

    └─ 도메인 특화 임베딩?

    4. 검색 전략

    ├─ Dense Retrieval (벡터 검색)

    ├─ Sparse Retrieval (BM25 키워드)

    └─ Hybrid Search (둘 다)

    5. 재생성 (Re-ranking)

    ├─ Cross-Encoder 재랭킹

    └─ Cohere Rerank 등

    6. 컨텍스트 구성

    ├─ 몇 개 문서를 넣을 것인가?

    └─ Lost in the Middle 문제 처리

    7. 프롬프트 엔지니어링

    └─ 검색 결과를 어떻게 모델에게 전달?

     

    ┌─────────────────────────────────────────┐
    │     내가 해결하려는 문제는?              │
    └──────────────┬──────────────────────────┘
                   │
           ┌───────┴────────┐
           ▼                ▼
      지식/데이터         행동/스타일
      문제인가?           문제인가?
           │                │
           ▼                ▼
         RAG              LoRA
      (정보 검색)        (모델 특화)
           │                │
           └───────┬────────┘
                   ▼
            둘 다 필요한가?
                   │
                   ▼
          RAG + LoRA 동시 적용
          (현업 최고 성능 조합)

    --- ** claude ** ---

     

    의문 2. 

    RAG는 청킹 전략이 중요하다고 생각하는데 문서 기반이면 이 문서의 청킹 전략들을 적용해서 어떻게 청킹하고 ? 저 전략별로 청킹하는 원리는? 사용자의 질문을 기반으로 질문을 청킹하는건 이했지만 문서를 청킹한다란? 사용자 질문 기반 청킹은 의미단위 청킹, 문장단위 청킹을 사용하는거 같은데 이 전략을 사용하는 이유와, 원리는?

     

    더보기

    claude 피셜

     

    ═══════════════════════════════════════════════════
    [사전 작업 - 문서를 DB에 저장하는 단계]
    ═══════════════════════════════════════════════════

    원본 문서 (PDF, HTML, TXT...)
           │
           ▼
      📄 문서 청킹    ← ✅ 청킹은 여기서 일어남! (문서를 조각냄)
           │
           ▼
      🔢 임베딩 변환  ← 각 청크를 숫자 벡터로 변환
           │
           ▼
      🗄️ 벡터 DB 저장 ← Qdrant, Pinecone 등에 저장


    ═══════════════════════════════════════════════════
    [실시간 - 사용자가 질문하는 단계]
    ═══════════════════════════════════════════════════

    사용자: "봉준호 감독 영화 추천해줘"
           │
           ▼
      🔢 질문 임베딩  ← 질문을 똑같이 숫자 벡터로 변환
      (청킹 없음!)
           │
           ▼
      🔍 유사도 검색  ← 질문 벡터와 가장 비슷한 청크 찾기
           │
           ▼
      📋 관련 청크 추출 (예: 상위 3~5개)
           │
           ▼
      🤖 LLM에 전달  ← "이 자료를 참고해서 답해줘" + 청크들
           │
           ▼
      💬 최종 답변 생성

     

    왜 문서를 청킹해야 하는가?

    통째로 넣으면:

    - LLM의 컨텍스트 윈도우 초과 (GPT-4도 최대 128K 토큰)

    - 비용 폭발 (토큰 수 = 비용)

    - 관련 없는 정보가 너무 많아 답변 품질 저하

    - 벡터 검색 자체가 불가능 (문서 하나 = 벡터 하나면 의미 없음)

     

    청킹 후 넣으면:

    - 딱 관련된 부분만 추출 가능

    - 비용 절감

    - 검색 정확도 향상

    - LLM이 핵심에 집중 가능

     

    청킹 전략은? 

    - 고정 길이 청킹

    글자 수나 토큰 수 기준으로 기계적으로 자르는 방법

    -문장 단위 청킹

    마침표, 줄바꿈, 문단 구분자 등을 기준으로 의미있는 단위에서 자르는 방식

    - 의미 단위 청킹

    문장과 문장 사이의 의미적 유사도를 계산해서, 의미가 바뀌는 지점을 찾아 자르는 방식

    - 계층적 청킹

    큰 청크(Parent)작은 청크(Child)의 두 단계로 구성

     

    의문 3

    질문을 그대로 임베딩하면 사용자의 의도가 무엇인지 의미가 무엇인지 질문 임베딩이 제대로 되는가? 질문을 분석하고 질문의 의미등을 잘라서 키워드? 로 나누고 이걸 기반으로 벡터 검색을 하는거 아닌가? 사용자의 질문이 모호하거나 어려울때, 혹은 벡터, 문서 기반의 질문이 아닐때 임베딩이 잘못되지 않나? 임베딩이 잘못돼면 검색 품질 또한 저하될 우려 발생. 추가질문, 문장단위 청킹 같은 경우는 문서의 사이즈가 크면 청크가 수천만개가 생길텐데, 여기서 청크가 많아도 상관이없나? 검색 품질이 저하됀다거나의 영향을 받지 않나?

     

     

    사용자 질문 임베딩의 대한 궁금증 해결책

    -하이브리드 검색 (현재 개발중)

     

    -쿼리 확장

    -쿼리 분해

    -전체 쿼리 처리 파이프라인

     

    청크가 수천만 개면 발생하는 문제들 

    - 검색 속도

    - 노이즈 증가

    - 의미적 군집 희석

     

    해결책

    - MMR (Maximal Marginal Relevance) 

    유사하면서도 서로 다양한 청크를 선택

    20개 후보 중에서 서로 중복되지 않는 5개 선택

     → 같은 내용의 청크가 중복으로 들어오는 것 방지

     

    - 메타데이터 필터링

    벡터 검색 전에 범위를 좁혀서 청크 수를 줄임

    전체 100만 청크 → 필터 후 1만 청크 → 그 중 벡터 검색 → 속도와 정확도 모두 향상

     

    - 재랭킹 (Re-ranking)

    벡터 검색 결과를 더 정교한 모델로 다시 정렬

    Cross-Encoder: 질문과 각 청크를 함께 보고 관련성 재평가

    벡터 검색으로 20개 후보 선택

    → Cross-Encoder가 각각 정밀 평가

    → 진짜 관련있는 상위 3개만 최종 선택

     

    더보기

    claude 피셜 해답지

     

    청크 수에 따른 전략 정리

    ~10만 개

    └── 기본 벡터 검색으로도 충분 HNSW로 빠른 검색 가능 별도 최적화 불필요

    10~ 100만 개

    └── 메타데이터 필터링 필수 MMR로 다양성 확보 Re-ranking 적용 권장

    100만 개 이상

    └── 계층적 인덱싱 고려 (큰 단위로 먼저 검색 후 세부 검색) 샤딩(Sharding) 고려 앙상블 + Re-ranking 필수

     

     

    —————————————————————————— 
    본 후기는 [카카오엔터프라이즈x스나이퍼팩토리] 카카오클라우드로 배우는 AIaaS 마스터 클래스 3기(B-log) 리뷰로 작성 되었습니다.

Designed by Tistory.