이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Supervised Fine-Tuning의 성능 한계는 학습 인프라보다 데이터 준비 품질에서 먼저 결정됩니다. Continued Pre-training은 도메인 지식을 넓히고 SFT는 응답 행동을 바꾸며 RFT는 보상 신호로 최적화하므로, foundation model에 필요한 지식이 이미 있다면 SFT와 RFT를 순차 적용하는 구성이 적합합니다. 학습 전에는 정답성·다양성·일관성·중복·안전성을 점검하고, 추론 시 사용할 system prompt와 Chat Template을 JSONL 데이터에 동일하게 반영해야 하며, reasoning trace와 tool calling도 각 역할과 필드 규칙에 맞춰 구성해야 합니다. 데이터의 10–20%를 운영 분포를 대표하는 평가 세트로 분리하고 수정하지 않은 모델의 baseline과 비교해야 SFT의 개선과 overfitting을 구분할 수 있습니다.
섹션별 상세
Supervised Fine-Tuning은 foundation model의 지식을 새로 확장하기보다 이미 가진 능력을 원하는 응답 방식으로 재구성하는 단계입니다. Continued Pre-training은 도메인 텍스트를 넣어 용어와 개념을 넓히고, Reinforcement Fine-tuning은 보상 신호로 행동을 최적화하므로 세 방법의 목적이 다릅니다. Amazon Nova처럼 폭넓은 사전 학습을 거친 모델에서는 보통 SFT 뒤에 RFT를 적용하는 순서가 실용적이며, 핵심 도메인 지식이 부족할 때만 CPT가 먼저 필요합니다.
원시 데이터를 형식화하기 전에 정확성, 다양성, 일관성, 중복, 안전성을 차례로 감사해야 학습 과정에 잘못된 행동을 주입하는 문제를 줄일 수 있습니다. 각 응답은 실제 배포에 사용해도 되는 gold-standard 답변이어야 하며, LIMA의 1,000개 curated examples와 AlpaGasus의 가장 깨끗한 20% 선별 결과는 데이터 양보다 품질이 중요하다는 근거로 제시됩니다. 사람 주석 데이터는 다중 검토를 거치고, exact-match와 semantic deduplication으로 중복을 제거하며, 유해하거나 편향된 사례는 자동 분류기와 사람 검토를 함께 거쳐야 합니다.
다양한 사용자 표현과 작업 범위를 포함해야 SFT 모델이 실제 트래픽으로 일반화할 수 있습니다. 같은 의도를 서로 다른 prompt로 표현하고, 도메인별 비율과 난이도 범위를 맞추며, 모호하거나 정보가 부족하거나 범위를 벗어난 요청에 대한 목표 응답도 넣어야 합니다. 예제를 embedding similarity로 cluster한 뒤 빈 영역을 찾으면 운영 환경에는 존재하지만 학습 데이터에 빠진 요청 유형을 찾아 보강할 수 있습니다.
서로 비슷한 작업을 처리하는 예제는 같은 기본 동작과 출력 형식을 가져야 모델이 상충하는 신호를 받지 않습니다. 고정된 label 집합을 요구하면서 대소문자를 섞거나, 두 문장 요약을 요구하면서 긴 문단과 preamble을 함께 넣으면 응답 구조가 불안정해집니다. 따라서 같은 task type에는 고정 문장, 고정 길이, 고정 형식을 일관되게 적용하고 예외 요청에도 원하는 거절 문장을 하나의 기준으로 맞춰야 합니다.
jsonl
{
"schemaVersion": "bedrock-conversation-2024",
"system": [{"text": "You are a helpful coding assistant."}],
"messages": [
{
"role": "user",
"content": [{"text": "Write a Python function to check if a string is a palindrome."}]
},
{
"role": "assistant",
"content": [
{"text": "def is_palindrome(s):
cleaned = s.lower().replace(' ', '')
return cleaned == cleaned[::-1]"}
]
}
]
}Amazon Nova의 Converse API 형식으로 한 대화 예제를 하나의 JSON 객체에 담는 구조입니다.
학습 데이터는 추론 시 사용할 입력 구조를 그대로 반영해야 하며, 특히 system prompt가 distribution mismatch를 일으키지 않도록 주의해야 합니다. 운영 환경에서 system prompt를 쓰면 각 학습 대화에도 같은 위치에 넣고, Amazon Nova에서는 Converse API 형식의 JSONL을 사용해 한 줄에 하나의 JSON 객체를 배치하며 user와 assistant 역할을 엄격히 교대합니다. 업로드 전 모든 줄의 JSON 파싱을 확인하고, 여러 줄 pretty-printing을 피해야 형식 오류와 학습 입력 불일치를 막을 수 있습니다.
jsonl
{
"schemaVersion": "bedrock-conversation-2024",
"system": [{"text": "You are a financial analyst. Provide data-driven answers with supporting calculations."}],
"messages": [
{
"role": "user",
"content": [{"text": "Calculate YoY revenue growth. 2024: $4.2M, 2025: $5.1M"}]
},
{
"role": "assistant",
"content": [
{
"reasoningContent": {
"reasoningText": {
"text": "The user asks for year-over-year revenue growth. I need to calculate the percentage change: (new - old) / old x 100. That gives (5.1 - 4.2) / 4.2 x 100 = 21.43%."
}
}
},
{"text": "YoY revenue growth is approximately 21.4 percent: ($5.1M - $4.2M) / $4.2M x 100."}
]
}
]
}reasoningContent 필드에 계산 과정을 넣고 최종 응답과 연결하는 추론 Trace 예제입니다.
reasoning 기능을 학습시킬 때는 reasoningContent에 최종 답변으로 이어지는 중간 단계를 넣어야 합니다. 좋은 reasoning trace는 문제 난이도에 비례하는 길이를 가지며, 생략된 단계 없이 답변과 충실하게 연결되어야 하고, s1과 LIMO의 사례처럼 1,000개 미만의 엄선된 reasoning demonstrations도 충분한 신호가 될 수 있습니다. 학습에서 reasoning_enabled를 켜면서 데이터에 추론 Trace가 없으면 모델이 추론 없이 답하는 패턴을 배울 수 있으므로 추론 시에도 같은 설정을 유지해야 합니다.
jsonl
{
"schemaVersion": "bedrock-conversation-2024",
"system": [{"text": "You are an expert in composing function calls."}],
"toolConfig": {
"tools": [
{
"toolSpec": {
"name": "getItemCost",
"description": "Retrieve the cost of an item from the catalog",
"inputSchema": {
"json": {
"type": "object",
"properties": {
"item_id": {
"type": "string",
"description": "The ASIN of item to retrieve cost for"
}
},
"required": ["item_id"]
}
}
}
}
]
},
"messages": [
{
"role": "user",
"content": [{"text": "How much does item id-456 cost?"}]
},
{
"role": "assistant",
"content": [
{
"toolUse": {
"toolUseId": "getItemCost_0",
"name": "getItemCost",
"input": {"item_id": "id-456"}
}
}
]
},
{
"role": "user",
"content": [
{
"toolResult": {
"toolUseId": "getItemCost_0",
"content": [
{"text": "{"name": "getItemCost", "results": {"cost": "$29.99"}}"}
]
}
}
]
},
{
"role": "assistant",
"content": [
{"text": "Item id-456 costs $29.99."}
]
}
]
}toolUse와 toolResult를 서로 다른 역할에 배치하고 동일한 toolUseId로 호출과 결과를 연결하는 형식입니다.
jsonl
{
"schemaVersion": "bedrock-conversation-2024",
"system": [{"text": "You are a document analysis assistant."}],
"messages": [
{
"role": "user",
"content": [
{
"document": {
"format": "pdf",
"name": "quarterly_report",
"source": {"s3Location": {"uri": "s3://<your-bucket-name>/report.pdf"}}
}
},
{"text": "Summarize the key findings from this quarterly report."}
]
},
{
"role": "assistant",
"content": [
{"text": "The quarterly report highlights three key findings..."}
]
}
]
}Amazon S3 위치의 PDF 문서와 텍스트 요청을 함께 넣어 multimodal 학습 사례를 구성합니다.
Tool calling과 multimodal 이해도 SFT 데이터의 대화 구조 안에서 학습할 수 있습니다. toolUse는 assistant turn에만, toolResult는 user turn에만 배치하고, 각 결과는 앞선 호출의 유효한 toolUseId를 정확히 한 번 참조해야 하며, 문서와 이미지 입력은 Amazon S3 위치를 가리키는 content block으로 넣습니다. 이 구조를 지키면 함수 호출, PDF 분석, 이미지 이해처럼 텍스트만으로 표현하기 어려운 입력과 출력을 모델의 학습 형식에 포함할 수 있습니다.
원래 foundation model의 Chat Template과 학습 데이터를 정확히 맞추면 모델이 새로운 구분자 형식을 동시에 학습하는 부담을 피할 수 있습니다. Amazon Nova는 Converse API schema를 사용하고, open source 모델은 Hugging Face Transformers의 apply_chat_template()을 활용하며, ShareGPT나 Alpaca 데이터를 변환할 때 delimiter를 직접 조립하지 않아야 합니다. 형식화 후 샘플을 tokenize하고 다시 decode해 role boundary, special token, content가 보존되는지 확인하는 검증도 필요합니다.
전체 데이터의 10–20%는 평가 세트로 보류하고, 학습 전 수정하지 않은 모델의 baseline 성능을 같은 평가 세트에서 측정해야 SFT의 실제 효과와 overfitting을 구분할 수 있습니다. 1,000개 미만의 데이터에서는 각 task category가 학습과 평가 세트에 모두 들어가도록 stratified split을 사용하고, 더 큰 데이터에서는 random split 뒤 분포를 점검합니다. 평가 세트는 단순한 무작위 표본이 아니라 운영 분포를 대표해야 하며, 드물지만 중요한 범주도 빠지지 않아야 합니다.
용어 해설
- 지도 Fine-tuning(Supervised Fine-Tuning)
- — 이미 알고 있는 지식을 새로 주입하기보다 입력과 정답의 curated pair를 반복 학습해 모델의 응답 방식을 바꾸는 방법입니다. 지시 준수, 출력 형식, 말투, 구조화된 응답을 조정하는 데 쓰입니다.
- Continued Pre-training
- — 대규모 비정형 도메인 텍스트를 추가로 학습해 foundation model의 용어, 개념, 데이터 패턴에 대한 지식 기반을 넓히는 방식입니다. 기본 모델이 특정 분야의 핵심 지식을 모를 때 필요합니다.
- 강화 Fine-tuning(Reinforcement Fine-tuning)
- — 명시적인 모범 답안 대신 보상 신호를 사용해 모델의 행동을 최적화하는 방식입니다. 출력 품질을 프로그램으로 평가할 수 있지만 대규모로 추론 과정을 직접 작성하기 어려운 작업에 적합합니다.
- 의미적 커버리지(Semantic Coverage)
- — Fine-tuning 데이터가 얼마나 다양한 작업 영역과 사용자 표현 방식을 포함하는지를 나타내는 기준입니다. 실제 요청의 의도와 표현 범위를 충분히 포함해야 특정 사례에만 맞춘 모델을 피할 수 있습니다.
- 정보 깊이(Information Depth)
- — 개별 학습 예제가 담고 있는 정보와 문제 해결 과정의 풍부함을 뜻합니다. 단순한 사례만 모으기보다 복잡한 문제, 여러 단계의 처리, 적절한 답변 근거를 포함해야 일반화에 도움이 됩니다.
- Chat Template
- — 모델이 system, user, assistant 메시지를 구분하기 위해 사용하는 정확한 토큰 배열과 구분자 형식입니다. 학습 데이터와 추론 시 구조가 다르면 모델이 system prompt를 무시하거나 잘못된 형식의 출력을 만들 수 있습니다.
- 추론 Trace(Reasoning Trace)
- — 문제의 입력에서 최종 답변에 이르는 중간 사고 단계를 기록한 학습 데이터입니다. 단계가 실제 답변을 뒷받침하고 문제 난이도에 비례해야 하며, reasoning 기능을 사용하는 학습과 추론 환경에서 일관되게 다뤄야 합니다.
기술
- Amazon Nova
- Amazon Bedrock
- Amazon SageMaker HyperPod
- Llama Guard
- Hugging Face Transformers
- Amazon S3
활용 사례
- 출력 schema를 준수하는 구조화된 응답
- 도메인 분류 taxonomy에 맞춘 분류
- 지정된 말투를 유지하는 대화 시스템
- Tool calling과 function calling
- PDF·이미지·비디오 기반 multimodal 이해
- 다중 turn 고객 지원 대화
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 27.수집 2026. 08. 27.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
