📚 Amazon Bedrock 파인튜닝 & 모델 선택

1. 다양한 제공자와 모델 특징

  • 대표 제공자(Providers): Anthropic, Amazon, DeepSeek, Stability AI 등
  • 각 모델마다 잘하는 분야가 다름:
    • Claude 3.5 Haiku → 텍스트 처리에 최적화
    • Amazon Nova Reel → 텍스트-영상, 이미지-영상 변환
  • 💡 시험 포인트: 시험에서 “어떤 모델이 제일 좋은가?”를 묻지 않음 → 각 모델이 할 수 있는 것과 못 하는 것만 구분

2. 모델 비교하기

  • Bedrock Playground에서 여러 모델을 나란히 테스트 가능
  • 비교 기준:
    • ✅ 지원 기능 (텍스트, 이미지, 비디오)
    • ✅ 출력 스타일/형식
    • ✅ 속도(지연 시간)
    • ✅ 비용(토큰 사용량)
  • 예시:
    • Nova Micro → 이미지 업로드 불가 ❌, 대신 빠르고 간단한 답변
    • Claude 3.5 Sonnet → 이미지 지원 가능 ✅, 길고 상세한 답변

3. 파인튜닝 방법 비교 (시험 자주 출제!)

구분 Instruction-Based Fine-Tuning Continued Pre-Training Transfer Learning
데이터 유형 라벨링된 데이터 (프롬프트–응답 쌍) 라벨링 안 된 원본 텍스트 라벨링/비라벨링 모두 가능
목표 특정 태스크/톤/스타일 맞춤 특정 도메인 전문화 다른 유사한 태스크로 전이
예시 특정 톤으로 대답하는 챗봇 AWS 문서 전체 학습 → AWS 전문가 모델 의료 분야 텍스트 분류
모델 가중치 변경? ✅ 변경됨 ✅ 변경됨 ✅ 변경됨
복잡도 중간 높음 다양
비용 상대적으로 저렴 매우 비쌈 (데이터 많음) 상황에 따라 다름
시험 키워드 “라벨링 데이터”, “프롬프트–응답” “비라벨링 데이터”, “도메인 적응” “새로운 유사 태스크 적응”
Bedrock 지원 일부 모델 지원 일부 모델 지원 일반 ML 개념 (Bedrock 전용 아님)

Instruction-based Fine Tuning

Continued Pre-training

4. 메시징 파인튜닝

  • 단일 턴(Single-Turn): 질문 1개 → 답변 1개, 필요 시 system 컨텍스트 추가

  • 다중 턴(Multi-Turn): 대화처럼 user와 assistant가 번갈아 대화 → 챗봇 훈련에 활용

5. 전이 학습 (Transfer Learning)

  • 정의: 이미 학습된 모델을 새로운 유사한 작업에 활용
  • 예시:
    • 이미지 분류 (고양이 vs 강아지 → 꽃 분류)
    • NLP 모델 (BERT, GPT) 재활용
  • 💡 시험 팁:
    • 일반 ML 문제 → Transfer Learning
    • Bedrock 관련 → Fine-Tuning

6. Bedrock에서 파인튜닝 조건

  • 학습 데이터는 반드시:
    • Amazon S3에 저장
    • 정해진 포맷 준수

  • Provisioned Throughput 필요:

    • 커스텀 모델 생성 시
    • 커스텀 모델 사용 시

  • 모든 모델이 파인튜닝 가능한 건 아님 → 주로 오픈소스 모델 지원

7. 파인튜닝 활용 사례

  • 특정 톤/페르소나 챗봇 제작
  • 최신 지식 반영
  • 기업 내부 비공개 데이터 활용 (고객 로그, 내부 문서)
  • 분류 정확도 향상, 응답 스타일 조정

8. 시험 팁 정리

  • “라벨링 데이터” → Instruction-Based Fine-Tuning
  • “비라벨링 데이터 / 도메인 적응” → Continued Pre-Training
  • “새로운 유사 작업 적응” → Transfer Learning
  • Bedrock에서 커스텀 모델 = Provisioned Throughput 필수
  • 파인튜닝 = 모델 가중치 변경 → 내 전용 모델 생성
  • 모델 비교 시 → 품질뿐 아니라 속도와 비용 고려

9. 추가로 알아두면 좋은 점

  • FM 전체 재학습은 비용·시간 모두 매우 큼
  • Instruction 기반 파인튜닝은 상대적으로 저렴 (적은 데이터, 적은 연산)
  • 하지만 전문 ML 엔지니어 필요
  • 과정: 데이터 준비 → 파인튜닝 → 모델 평가 → 운영
  • 파인튜닝 모델 실행 시도 Provisioned Throughput 필요 → 비용 추가

10. Provisioned Throughput (중요 시험 포인트!)

  • 정의: 커스텀 모델을 위한 전용 처리 용량 예약
  • 필요 이유:
    • 안정적 성능 보장
    • 트래픽 증가 시 성능 저하 방지
    • 예측 가능한 비용 관리
  • 💡 시험 팁: Bedrock에서 커스텀 모델 = 무조건 Provisioned Throughput 필요

✅ 시험 핵심 요약표

구분 핵심 포인트 시험 키워드
모델 제공자 Anthropic, Amazon, DeepSeek, Stability AI 등 “어떤 모델이 제일 좋은가?” ❌, “할 수 있는 것/못하는 것” ✅
모델 비교 기준 기능(텍스트/이미지/비디오), 출력 스타일, 속도, 비용 Compare Mode
Instruction-Based Fine-Tuning 라벨링 데이터 필요 (프롬프트–응답 쌍), 비용 낮음, 특정 톤/스타일 맞춤 Labeled data, Prompt–Response
Continued Pre-Training 비라벨링 데이터로 도메인 전문화, 데이터·비용 큼 Unlabeled data, Domain Adaptation
Transfer Learning 기존 모델을 새로운 유사 작업에 적응 Adapt model to new task
메시징 파인튜닝 단일 턴(Single-Turn), 다중 턴(Multi-Turn) 지원 Chatbot Training
Provisioned Throughput 커스텀 모델 생성/운영 시 필수, 전용 처리 용량 예약 Required for Bedrock Custom Models
비용 절감 Instruction-Based FT가 가장 저렴, Full FM 재학습은 비용 매우 큼 Cost Optimization

📌 추가 시험 포인트

  • 파인튜닝은 모델 가중치를 변경하여 내 전용 모델을 만드는 것
  • Bedrock은 모든 모델이 파인튜닝 가능한 건 아님 → 주로 오픈소스 모델 지원
  • 커스텀 모델은 반드시 Provisioned Throughput 필요
  • 모델 비교 시 속도와 비용도 중요
  • Fine-Tuning 단계: 데이터 준비 → 학습 → 평가 → 운영
  • 실행 비용은 일반 모델보다 높음 (전용 리소스 사용)

👉 결론:
Amazon Bedrock 파인튜닝 = 내 데이터로 맞춤형 모델을 만들 수 있는 기능
시험 핵심 = 키워드 매핑(라벨링 vs 비라벨링 vs 새로운 태스크) + Provisioned Throughput

Prompt Engineering, RAG, Fine-tuning — 쉽게 정리

한 줄 정의

  • 프롬프트 엔지니어링 (Prompt engineering): 모델에게 질문·지시문을 잘 쓰는 기술. 말귀를 잘 알아듣게 질문을 다듬는 것.
  • RAG (Retrieval-Augmented Generation): 모델이 답을 만들기 직전에 외부 데이터(사내 문서·DB 등)를 찾아와 프롬프트에 붙여 주는 방식.
  • 파인튜닝 (Fine-tuning): 이미 학습된 모델의 가중치를 추가로 훈련해서 특정 업무 스타일/태스크에 전문화시키는 것.

비유로 이해하기

  • 프롬프트 엔지니어링 = 똑같은 셰프에게 레시피 지시를 더 똑바로 적어주는 것
    (예: “소금 1작은술, 10분간 약불”처럼 구체화)
  • RAG = 셰프에게 최신 식재료 정보·가게 전단지를 함께 건네는 것
    (예: 오늘 재고·가격표를 같이 보여줌 → 최신 정보 반영)
  • 파인튜닝 = 셰프를 한식 전문 셰프로 재교육하는 것
    (예: 한식 메뉴를 반복 훈련 → 그 스타일에 강해짐)

언제 무엇을 쓰나? (결정 가이드)

  1. 먼저 시도: 프롬프트 엔지니어링

    • 목적: 답변 형식·톤·단계적 사고를 간단히 개선
    • 예: “표로 정리해줘 / 단계별로 설명 / 근거를 점 bullets로”

  2. 데이터가 자주 바뀌거나 사내용 문서를 써야 하면: RAG

    • 목적: 최신·사내 고유 정보 반영, 환각(헛말) 감소
    • 예: 재고·가격, 최신 정책, 내부 위키·매뉴얼

  3. 특정 태스크 성능을 끌어올리고 싶으면: 파인튜닝

    • 목적: 분류/추출/요약 스타일 등 태스크 전용 능력 강화
    • 예: 고객 이메일을 사내 카테고리로 자동 분류, 법률 문체로 항상 답변

장단점 & 난이도

방법 장점 단점 난이도/비용
프롬프트 엔지니어링 빠르고 쉽고 싸다 사실 지식은 외부에서 못 가져옴 ★☆☆ (가장 쉬움)
RAG 최신/사내 데이터 반영, 환각 크게 감소 벡터DB·인덱싱 등 시스템 구축 필요 ★★☆
파인튜닝 특정 업무 성능·스타일 최적화 데이터 준비·ML 역량·비용 필요, 최신성은 별도 ★★★ (가장 어려움)

핵심: RAG는 “사실/지식 보강”, **파인튠은 “능력/스타일 전문화”**에 강합니다. 둘은 대체가 아니라 보완 관계예요. (보통 프롬프트 → RAG → 필요시 파인튜닝 순으로 확장)

간단 사례 (쇼핑 고객 챗봇)

  • 프롬프트 엔지니어링: “말투는 친절하게, 3줄 요약, 마지막 줄에 추천 제품 1개”
  • RAG: 질의 시점에 재고·가격·쿠폰을 검색해 프롬프트에 첨부 → “현재 재고 O, 오늘만 10% 할인”
  • 파인튜닝: 반품 규정 분류·FAQ 라벨링 데이터로 모델을 훈련 → 더 정확한 정책 분류/요약 성능

자주 하는 오해 바로잡기

  • RAG가 모델을 바꾸는가? → 아니요. 가중치를 안 바꾸고 프롬프트에 근거 자료를 붙여 주는 방식입니다.
  • 파인튜닝을 하면 최신 정보가 들어오나? → 아니요. 최신성을 원하면 RAG나 정기 재학습이 필요합니다.
  • 프롬프트만 잘 쓰면 다 되나? → 형식·추론은 좋아지지만 사실성/최신성은 한계가 큽니다 → RAG 병행 권장.

빠른 체크리스트

  • 바뀌는 정보가 핵심? → RAG
  • 태스크 전용 성능·스타일이 핵심? → 파인튜닝
  • 빠르게 형식/추론 개선부터? → 프롬프트 엔지니어링