(한국어) AWS Certified AI Practitioner (4) - Amazon Bedrock 파인튜닝 & 모델 선택
📚 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 = 셰프에게 최신 식재료 정보·가게 전단지를 함께 건네는 것
(예: 오늘 재고·가격표를 같이 보여줌 → 최신 정보 반영) - 파인튜닝 = 셰프를 한식 전문 셰프로 재교육하는 것
(예: 한식 메뉴를 반복 훈련 → 그 스타일에 강해짐)
언제 무엇을 쓰나? (결정 가이드)
먼저 시도: 프롬프트 엔지니어링
- 목적: 답변 형식·톤·단계적 사고를 간단히 개선
- 예: “표로 정리해줘 / 단계별로 설명 / 근거를 점 bullets로”
데이터가 자주 바뀌거나 사내용 문서를 써야 하면: RAG
- 목적: 최신·사내 고유 정보 반영, 환각(헛말) 감소
- 예: 재고·가격, 최신 정책, 내부 위키·매뉴얼
특정 태스크 성능을 끌어올리고 싶으면: 파인튜닝
- 목적: 분류/추출/요약 스타일 등 태스크 전용 능력 강화
- 예: 고객 이메일을 사내 카테고리로 자동 분류, 법률 문체로 항상 답변
장단점 & 난이도
방법 | 장점 | 단점 | 난이도/비용 |
---|---|---|---|
프롬프트 엔지니어링 | 빠르고 쉽고 싸다 | 사실 지식은 외부에서 못 가져옴 | ★☆☆ (가장 쉬움) |
RAG | 최신/사내 데이터 반영, 환각 크게 감소 | 벡터DB·인덱싱 등 시스템 구축 필요 | ★★☆ |
파인튜닝 | 특정 업무 성능·스타일 최적화 | 데이터 준비·ML 역량·비용 필요, 최신성은 별도 | ★★★ (가장 어려움) |
핵심: RAG는 “사실/지식 보강”, **파인튠은 “능력/스타일 전문화”**에 강합니다. 둘은 대체가 아니라 보완 관계예요. (보통 프롬프트 → RAG → 필요시 파인튜닝 순으로 확장)
간단 사례 (쇼핑 고객 챗봇)
- 프롬프트 엔지니어링: “말투는 친절하게, 3줄 요약, 마지막 줄에 추천 제품 1개”
- RAG: 질의 시점에 재고·가격·쿠폰을 검색해 프롬프트에 첨부 → “현재 재고 O, 오늘만 10% 할인”
- 파인튜닝: 반품 규정 분류·FAQ 라벨링 데이터로 모델을 훈련 → 더 정확한 정책 분류/요약 성능
자주 하는 오해 바로잡기
- RAG가 모델을 바꾸는가? → 아니요. 가중치를 안 바꾸고 프롬프트에 근거 자료를 붙여 주는 방식입니다.
- 파인튜닝을 하면 최신 정보가 들어오나? → 아니요. 최신성을 원하면 RAG나 정기 재학습이 필요합니다.
- 프롬프트만 잘 쓰면 다 되나? → 형식·추론은 좋아지지만 사실성/최신성은 한계가 큽니다 → RAG 병행 권장.
빠른 체크리스트
- 바뀌는 정보가 핵심? → RAG
- 태스크 전용 성능·스타일이 핵심? → 파인튜닝
- 빠르게 형식/추론 개선부터? → 프롬프트 엔지니어링
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.