Field Log · Entry

Instruction Tuning과 SFT: Chat Template·Loss Mask·데이터 품질 (4/10)

System user assistant 대화를 chat template로 직렬화하고 assistant response에만 loss를 적용한 뒤 instruction tool grounding retention 평가로 연결하는 SFT pipeline

오늘의 결론

Pretraining은 다음 token 분포를 학습하고, SFT는 요청·대화·형식에 맞는 응답을 supervised target으로 학습합니다.

system → user → assistant → tool은 추상 message가 아니라 special token과 delimiter를 가진 versioned chat template로 직렬화됩니다.

Response-only SFT에서는 prompt token label을 ignore하고 assistant token과 종료 token에 loss를 적용합니다. Mask 경계 한 칸 오류도 잘못된 behavior를 학습시킵니다.

데이터 양만 늘리기보다 정답성·다양성·난이도·출처·중복·평가 오염을 관리하고, train loss가 아니라 held-out behavior와 base capability retention을 봅니다.

RAG Agent SFT는 정답 text뿐 아니라 tool 선택·argument·tool result 처리·근거 인용·abstention을 trajectory record로 설계해야 합니다.

앞 글에서는 decoder block을 열었습니다. 그 base model에 다음 prompt를 주면 어떻게 될까요?

사용자: 검색 결과만 사용해 세 줄로 답해 줘.

Base model은 대화를 이어 쓸 수는 있어도 “사용자의 요청을 따른다”는 role contract를 안정적으로 수행한다고 보장되지 않습니다.

pretraining:
  broad next-token capability

SFT:
  demonstrations of desired behavior
  → instruction-following policy

Versioned conversation record가 품질 gate와 chat template, assistant-only loss mask, packing을 거쳐 SFT batch가 되고 instruction tool grounding safety retention 평가로 연결되는 pipeline

그림 1. Message schema, token serialization, labels는 하나의 contract다. 학습과 serving의 chat template가 다르면 model이 배운 role boundary를 깨뜨린다.

Base Model과 Instruct Model

Base Model

대규모 corpus에서 causal language modeling을 학습한 checkpoint입니다.

input prefix
  → likely continuation

질문 뒤에 답을 이어 쓸 수 있지만, 다음 behavior가 명시적으로 정렬되어 있다고 볼 수 없습니다.

요청 우선순위
답변 형식
안전한 거절
tool 호출 syntax
근거 없는 경우 abstention
system/user/assistant role 경계

Instruct Model

Instruction과 원하는 response pair 또는 multi-turn conversation으로 후학습한 model입니다.

instruction + context
  → desired response

Instruction tuning은 넓은 개념이고, SFT는 정답 demonstration에 cross-entropy를 적용하는 대표 방법입니다.

SFT도 Next-token Loss다

새로운 종류의 neural network를 붙이는 것이 아닙니다. 같은 decoder가 target response token의 likelihood를 높입니다.

Sequence token을 x₁...x_T, loss mask를 m_t라 하면 다음과 같습니다.

L_SFT(θ)
= − Σₜ mₜ log pθ(xₜ | x₍<t₎)

Response-only SFT에서는 보통:

mₜ = 0  for system/user/tool-input prompt tokens
mₜ = 1  for target assistant response tokens

Implementation에서는 ignore label -100 같은 값을 사용해 loss에서 제외할 수 있습니다.

Prompt에도 Loss를 줄 수 있는가

가능합니다. 전체 sequence language modeling을 할 수 있습니다. 그러나 원하는 목적을 분명히 해야 합니다.

Prompt distribution 자체도 재현하도록 학습
User가 쓴 text까지 model target으로 삼음
긴 prompt가 response보다 loss를 지배할 수 있음
System policy text를 생성하도록 학습할 수 있음

Instruction-following 목적에서는 assistant response-only loss가 흔한 선택이지만 절대 규칙은 아닙니다.

Conversation Record를 먼저 정의한다

Text 한 줄에 ### User:를 붙이는 것으로 시작하지 않습니다.

type SFTConversation = {
  conversationId: string;
  messages: Array<
    | { role: "system"; content: string }
    | { role: "user"; content: string }
    | { role: "assistant"; content: string; target: boolean }
    | { role: "assistant"; toolCall: ToolCall; target: boolean }
    | { role: "tool"; toolCallId: string; content: string }
  >;
  taskTypes: string[];
  language: string;
  source: string;
  license: string;
  qualityStatus: "accepted" | "quarantine" | "rejected";
  split: "train" | "validation" | "test";
};

Target Flag가 필요한 이유

Multi-turn에서 모든 assistant message를 학습할지 마지막 response만 학습할지 결정해야 합니다.

system
user 1
assistant 1  ← target?
user 2
assistant 2  ← target?

둘 다 valid한 recipe입니다.

모든 assistant turn: 더 많은 supervised token
마지막 turn만: 앞 assistant turn을 context로만 사용
Quality가 낮은 중간 turn: target에서 제외

Record에 target을 명시하지 않고 serializer가 role만 보고 추측하게 두지 않습니다.

Chat Template는 Model ABI다

Message object는 model이 직접 읽지 못합니다. Token sequence로 직렬화합니다.

가상의 template는 다음과 같습니다.

<bos><system>
You answer only from evidence.<eot>
<user>
What changed?<eot>
<assistant>
The limit changed to 20. [S1]<eot>

Template가 결정하는 것

BOS 사용 여부
role 시작 token
role 이름 text
message delimiter
end-of-turn token
assistant generation prompt
tool call encoding
tool result encoding
whitespace와 newline
final EOS 또는 EOT

같은 Message, 다른 Token

Template A:
<|user|>hello<|assistant|>

Template B:
[INST] hello [/INST]

Template C:
User: hello
Assistant:

사람에게 비슷해 보여도 tokenizer가 보는 sequence는 다릅니다.

학습과 Serving이 달라지면

train:
  <assistant>answer<eot>

serve:
  Assistant: answer</s>

Model이 학습한 role boundary와 stopping pattern이 깨집니다.

답변 시작이 불안정
role token을 출력
종료하지 않음
system text를 반복
tool call 형식 오류
user 역할을 이어 생성

Tokenizer artifact와 함께 chat template hash를 배포합니다.

Special Token을 검증한다

{
  "bos_token_id": 1,
  "eos_token_id": 2,
  "pad_token_id": 0,
  "additional_special_tokens": {
    "system": 64001,
    "user": 64002,
    "assistant": 64003,
    "tool": 64004,
    "eot": 64005
  }
}

확인할 사항은 다음과 같습니다.

Token이 실제 vocabulary의 단일 ID인가?
Text fallback으로 여러 token으로 쪼개지지 않는가?
EOS와 EOT의 의미가 구분되는가?
Padding과 EOS를 같은 ID로 쓸 때 attention/loss mask가 맞는가?
Generation stop rule이 template 종료와 같은가?

Label Mask를 눈으로 검사한다

가상의 token sequence입니다.

index:  0    1       2      3      4         5      6    7
token: BOS  <user>  질문   EOT  <assistant> 답변   EOT  EOS

Response-only label은 예를 들어 다음과 같습니다.

label: -100 -100    -100  -100  -100        답변ID EOTID EOSID

Assistant Role Token은 Target인가

Recipe에 따라 다릅니다.

Role token까지 predict: assistant 시작 형식을 학습
Role token은 prompt, content부터 predict: generation prompt가 role token을 이미 제공

Serving 때 어떤 prefix까지 넣는지와 일치해야 합니다.

종료 Token은 학습해야 한다

Assistant content만 target으로 하고 EOT/EOS를 mask하면 model은 답을 언제 끝낼지 충분히 학습하지 못할 수 있습니다.

Unit Test

expect(decoded(inputIds)).toBe(expectedSerializedText);
expect(labels.slice(0, assistantStart).every((x) => x === -100)).toBe(true);
expect(labels[assistantContentStart]).toBe(inputIds[assistantContentStart]);
expect(labels[endOfTurnIndex]).toBe(inputIds[endOfTurnIndex]);
expect(nonIgnoredLabelCount).toBe(expectedAssistantTokenCount);

Template와 mask는 sample을 눈으로 decode하는 golden test가 필요합니다.

Tool Call을 Text 흉내로만 만들지 않는다

RAG Agent의 tool call은 structured action입니다.

{
  "name": "search_documents",
  "arguments": {
    "query": "refund limit 2026",
    "top_k": 5
  }
}

Conversation record는 call과 result를 연결합니다.

{
  "messages": [
    {"role": "user", "content": "환불 한도가 바뀌었어?"},
    {
      "role": "assistant",
      "tool_call": {
        "id": "call-17",
        "name": "search_documents",
        "arguments": {"query": "환불 한도 변경", "top_k": 5}
      }
    },
    {
      "role": "tool",
      "tool_call_id": "call-17",
      "content": "[{\"source_id\":\"S1\",\"text\":\"...\"}]"
    },
    {
      "role": "assistant",
      "content": "한도가 10에서 20으로 변경됐습니다. [S1]"
    }
  ]
}

무엇에 Loss를 줄까

Tool name
Arguments JSON
Final answer
필요하면 intermediate textual rationale는 별도 정책

Tool result는 환경 관측값이므로 보통 target이 아니라 context입니다.

Tool Schema도 Versioning한다

tool_schema:
  name: search_documents
  version: 3
  input_schema_hash: sha256:...
  output_schema_hash: sha256:...

SFT data가 old argument를 쓰고 production tool이 new schema를 쓰면 model 문제가 아니라 contract drift입니다.

Instruction Data의 기본 단위

좋은 example은 prompt와 response만 있지 않습니다.

type InstructionExample = {
  id: string;
  instruction: string;
  optionalInput?: string;
  response: string;
  constraints: string[];
  taskType: string;
  difficulty: "easy" | "medium" | "hard";
  language: string;
  sourceProvenance: string;
  authorOrGenerator: string;
  verifier: string[];
  qualityScores: Record<string, number>;
};

“고품질”을 Rubric으로 쪼갠다

Correctness

Response의 사실과 계산이 맞는가?

Instruction Adherence

요청한 형식, 길이, 언어, 금지 조건을 따르는가?

Relevance

질문에 필요한 내용만 답하는가?

Completeness

여러 요구를 빠뜨리지 않았는가?

Grounding

제공한 evidence가 claim을 지지하는가?

Safety

위험 요청에서 정책에 맞는 도움과 제한을 제공하는가?

Style

불필요한 서론, 반복, 과도한 면책 문구가 없는가?

단일 model-judge 점수로 모두 합치지 않고 dimension별 label과 reason을 남깁니다.

Data 양보다 Coverage가 중요하다

같은 쉬운 요약 example을 백만 개 추가해도 tool call·근거 충돌 능력이 생기지 않습니다.

Capability Matrix

축	Slice 예
task	QA, 요약, 추출, 분류, 변환, code
instruction	단일, 다중 constraint, 부정 constraint
context	없음, 짧음, long, noisy, conflict
output	prose, bullet, JSON, tool call
language	한국어, 영어, mixed
answerability	충분, 부분, 불충분
risk	low, medium, high

Count만 보지 말고 slice별 response token과 난이도를 봅니다.

Mixture와 Sampling

sft_mixture:
  general_instruction: 0.30
  korean_instruction: 0.15
  code_and_debugging: 0.15
  structured_output: 0.10
  tool_use: 0.15
  rag_grounding: 0.10
  safety_and_abstention: 0.05

위 값은 예시입니다. Raw example 비율이 아니라 target sampling probability입니다.

Response Token Ratio

Prompt가 긴 RAG example은 batch token을 많이 쓰지만 supervised response token은 적을 수 있습니다.

supervised_token_ratio
= non_ignored_label_tokens / all_non_padding_tokens

Batch throughput만 보면 실제 학습 signal의 양을 오해할 수 있습니다.

Packing

짧은 conversation을 같은 context에 묶어 padding을 줄입니다.

sample A: BOS ... assistant ... EOT EOS
sample B: BOS ... assistant ... EOT EOS

필요한 경계

sample별 EOS
attention isolation 여부
position ID reset 여부
label mask 경계
sample ID와 token span

Implementation에 따라 packed sample 사이 attention을 차단하거나 causal stream으로 이어 둘 수 있습니다. 어느 방식이든 학습·평가 recipe에 명시합니다.

잘못된 Packing

assistant A end
user B start

without boundary:
model learns that assistant should generate another user's message

종료 token과 mask를 unit-test합니다.

Sequence Truncation

Max length를 넘는 conversation을 단순 뒤에서 자르면 target response가 사라질 수 있습니다.

strategy candidates:
  drop sample
  truncate oldest turns
  truncate tool payload
  select evidence
  split task if semantically valid

반드시 측정할 것

target token이 하나도 없는 sample 수
system prompt 손실
user question 손실
tool call/result pair 분리
citation source 손실
task별 truncation rate

Target 없는 batch는 optimizer update에 signal을 주지 않거나 numerical 문제를 만들 수 있습니다.

Deduplication과 Leakage

Instruction data는 template와 boilerplate가 많습니다.

Dedup Key

exact normalized prompt
prompt+response pair
near-duplicate prompt
semantic intent cluster
source document ID
generated seed instruction lineage

Split 먼저, Augmentation 나중

wrong:
  paraphrase all examples
  → random split

right:
  group source examples
  → split groups
  → augment train only

같은 instruction의 paraphrase가 train과 test에 나뉘는 것을 막습니다.

Benchmark Contamination

Public benchmark를 instruction data로 변환하면 평가 점수가 암기 영향을 받을 수 있습니다.

question
answer
rationale
translated variant
reformatted multiple choice
generated paraphrase

모두 lineage로 묶어 locked evaluation과 비교합니다.

Human-written Data

장점:

실제 사용자 intent와 ambiguity
자연스러운 constraint
domain expert correction
novel failure 발견

위험:

annotator별 style bias
guideline drift
평균적이고 안전한 답만 생성
어려운 문제의 정답 오류
privacy와 proprietary content

Annotation Workflow

task specification
  → author demonstration
  → independent verifier
  → disagreement adjudication
  → policy / safety review
  → accepted dataset version

Writer와 verifier를 가능하면 분리합니다.

Synthetic Instruction Data

Self-Instruct는 seed task에서 instruction, input, output을 model로 생성하고 filtering해 instruction-following data를 확장하는 접근을 제안했습니다.

필요한 Provenance

synthetic_example:
  generator_model: model-v7
  prompt_template_hash: sha256:...
  seed_instruction_ids: [seed-17, seed-92]
  decoding:
    temperature: 0.8
    top_p: 0.95
  verifier_models: [judge-v3]
  deterministic_checks: [json-schema, citation-exists]

위험

Teacher model의 style homogenization
Hallucinated facts
같은 쉬운 pattern 반복
Generator와 judge의 shared blind spot
Public benchmark 재생성
Long answer 선호
Model artifact가 정답처럼 굳음

검증 순서

deterministic checks
  → retrieval / calculator / code execution when applicable
  → independent model judge
  → sampled human audit
  → small SFT ablation

Model judge 하나가 통과시켰다고 ground truth가 되지 않습니다.

LIMA를 어떻게 읽어야 하는가

LIMA 연구는 65B LLaMA를 1,000개의 carefully curated prompt-response pair로 SFT해 연구 설정에서 강한 alignment 결과를 보고했습니다.

배울 점은 “SFT data는 1,000개면 충분하다”가 아닙니다.

strong base model capability
+ carefully curated demonstrations
+ task and evaluation conditions
→ surprisingly strong behavior adaptation

작은 model, 전문 domain, tool use, multilingual, safety 요구에서는 필요한 coverage가 다릅니다. 수치를 보편 threshold로 쓰지 않습니다.

FLAN이 보여 준 Task Diversity

FLAN 계열 연구는 여러 dataset을 instruction 형식으로 표현하고 task 수, model scale, chain-of-thought data를 확장해 unseen task generalization을 연구했습니다.

핵심 실무 교훈은 다음입니다.

같은 task example 수만 늘리지 않는다.
Task family와 prompt formulation을 다양화한다.
Held-out task로 generalization을 본다.
특정 benchmark 결과를 모든 deployment에 일반화하지 않는다.

InstructGPT Pipeline에서 SFT의 위치

InstructGPT 연구는 labeler demonstration으로 먼저 SFT한 뒤 preference ranking과 RLHF를 적용했습니다.

pretrained model
  → demonstration SFT
  → preference data
  → reward model
  → PPO-based RLHF

SFT는 preference optimization의 안정적인 시작 policy 역할도 합니다.

Tulu 3에서 배우는 Open Recipe

Tulu 3는 SFT, DPO, verifiable reward 기반 RL을 포함하는 open post-training recipe와 data·evaluation을 공개했습니다.

실무적으로 중요한 점은 알고리즘 이름보다 다음입니다.

Data mixture와 curation 공개
Development와 unseen evaluation 분리
Benchmark decontamination
성공하지 않은 시도도 분석
Recipe·code·checkpoint 재현성

Post-training도 pretraining처럼 data product와 experiment discipline이 필요합니다.

SFT Hyperparameter

Learning Rate

Pretraining보다 작은 learning rate를 쓰는 경우가 많지만 고정 규칙은 아닙니다.

영향 요소:

full fine-tuning vs adapter
model size
data token 수
batch size
base checkpoint maturity
task distribution shift

Epoch

작은 dataset을 여러 번 반복하면 train loss는 빠르게 낮아지지만 memorization과 forgetting이 늘 수 있습니다.

monitor by tokens, not epoch only:
  train response loss
  validation behavior
  base retention
  memorization

Batch Composition

같은 batch에 task를 섞을지, domain-homogeneous batch를 쓸지 gradient variance와 distributed packing에 영향을 줍니다.

Warmup과 Scheduler

Short SFT run에서 warmup step 수가 전체 학습의 큰 비율이 될 수 있습니다. Token 기준으로 기록합니다.

Weight Decay와 Dropout

Base recipe를 그대로 복사하지 말고 small ablation으로 결정합니다. Adapter와 full fine-tuning의 regularization 효과가 다릅니다.

Catastrophic Forgetting과 Retention

좁은 SFT data가 base capability를 덮을 수 있습니다.

before SFT:
  broad language · code · factual completion

after narrow SFT:
  excellent one domain
  degraded unrelated capabilities

대응

Diverse general instruction data 혼합
Lower learning rate
Fewer tokens/epochs
Pretraining-like data 일부 혼합
PEFT 사용 검토
Early stopping based on retention

어떤 방법도 자동 보장은 아닙니다. Retention suite가 필요합니다.

Style Collapse

SFT response가 모두 같은 서론과 bullet 형식을 가지면 model 출력도 획일화됩니다.

common synthetic style:
  "물론입니다! 다음은 ..."
  long headings
  repetitive conclusion

측정

Opening phrase frequency
Response length distribution
Heading count
Lexical diversity
Same prompt의 acceptable style variance
Over-refusal phrase frequency

Style diversity는 correctness를 희생하라는 뜻이 아닙니다. 여러 valid response를 표현할 수 있게 data distribution을 설계합니다.

Safety SFT와 Over-refusal

위험 요청을 모두 같은 “도와드릴 수 없습니다”로 학습하면 benign request도 거절할 수 있습니다.

Paired Data

unsafe request
  → refuse harmful part + offer safe alternative

similar benign request
  → answer normally

Decision boundary 근처의 contrastive pair가 중요합니다.

Evaluate Both

Harmful compliance rate
Correct refusal rate
Benign over-refusal rate
Safe alternative helpfulness
Policy explanation leakage

안전성 하나의 평균 점수로는 과소·과잉 거절을 구분하지 못합니다.

RAG Grounding SFT

RAG model은 context가 있을 때만 답하는 습관을 학습해야 합니다.

Positive Grounding

question + sufficient evidence
  → supported answer + precise citation

Unanswerable

question + irrelevant evidence
  → say evidence is insufficient
  → do not use memorized answer

Partial Evidence

question with two claims
+ evidence for one claim
  → answer supported part
  → mark unsupported part

Contradiction

two sources disagree
  → expose conflict
  → cite both
  → apply source/time policy

Citation Target

Citation text가 존재하기만 하면 충분하지 않습니다. Claim과 source span의 support를 검증합니다.

Tool-use SFT Coverage

Case	Desired behavior
tool needed	correct name + arguments
no tool needed	answer without call
no suitable tool	abstain or explain
missing required arg	ask clarification
parallel calls	independent calls together
dependent calls	use previous result before next
tool error	retry only if safe and useful
malicious result	treat output as untrusted data

성공 call만 넣으면 error handling을 학습하지 못합니다.

Evaluation Stack

Deterministic

JSON parse success
JSON schema validity
exact tool name
required argument presence
citation ID existence
requested length·count
language match

Reference-based

Exact match/F1 where appropriate
Unit test
Code execution sandbox
Calculator result
Expected tool trajectory

Human

Ambiguous instruction adherence
Domain correctness
Helpfulness
Tone
Safety boundary

Model Judge

Semantic correctness
Claim support
Completeness
Comparative preference

Judge는 frozen prompt, version, human calibration을 가집니다.

Train Loss가 알려 주지 않는 것

low train loss can mean:
  learned task pattern
  memorized responses
  learned template artifacts
  overfit easy majority slice

Validation도 near duplicate면 같은 문제가 있습니다.

Release Dashboard

dashboard:
  training:
    - response_loss
    - supervised_tokens
    - gradient_norm
  behavior:
    - unseen_instruction_pass_rate
    - schema_validity
    - tool_argument_accuracy
    - grounding_claim_support
  safety:
    - harmful_compliance
    - benign_over_refusal
  retention:
    - base_language_loss
    - code_eval
    - korean_eval
  operations:
    - response_length
    - latency

SFT Experiment Manifest

run_id: sft-rag-agent-v4
base_model:
  checkpoint_hash: sha256:...
tokenizer:
  artifact_hash: sha256:...
chat_template:
  version: chat-v3
  template_hash: sha256:...
data:
  dataset_version: instruct-v8
  mixture_hash: sha256:...
  split_manifest: split-v5
labels:
  response_only: true
  train_assistant_role_token: false
  train_end_of_turn: true
packing:
  max_length: 8192
  cross_sample_attention: false
optimization:
  method: full_finetune
  learning_rate: 2e-5
  global_batch_tokens: 1048576
  epochs: 2
evaluation:
  suite: rag-agent-sft-v6

값은 예시입니다. Manifest가 training script의 실제 resolved config와 같아야 합니다.

최소 구현 순서

Phase 1. 1,000개 Golden Data

명시적 conversation schema
한 개 versioned chat template
response-only label golden test
task·language·format coverage
human verification

Phase 2. Baseline SFT

Full or PEFT 방식 하나
Train/validation group split
Train loss + behavior eval
Base retention suite
Exact reproducibility

Phase 3. Tool·RAG Data

Structured tool calls
Sufficient·insufficient·conflict evidence
Tool error and clarification
Deterministic schema/citation evaluation

Phase 4. Scale Data Carefully

Synthetic generator provenance
Dedup and contamination
Capability matrix gap 채우기
Small ablation before full run

흔한 오해와 처방

1. SFT는 새로운 지식을 대량 주입하는 단계다

새 사실을 학습할 수도 있지만 좁은 demonstration이 안정적인 지식 저장을 보장하지 않습니다.

처방: Behavior adaptation, domain adaptation, knowledge update 목적을 분리하고 RAG가 맞는 문제인지 비교합니다.

2. Chat Template는 UI Formatting이다

Model이 학습한 실제 token protocol입니다.

처방: Tokenizer와 template를 하나의 versioned artifact로 배포합니다.

3. Prompt Token에도 전부 Loss를 주면 Data를 더 활용한다

긴 prompt가 desired response signal을 압도할 수 있습니다.

처방: 목적에 맞는 mask를 정하고 supervised token ratio를 측정합니다.

4. Assistant Text만 Target이면 끝이다

EOT/EOS를 빼면 종료 behavior가 약해질 수 있습니다.

처방: Role prefix와 stop token의 train/serve 경계를 unit-test합니다.

5. 데이터가 많을수록 좋다

중복·오답·한 가지 style이 학습을 지배할 수 있습니다.

처방: Coverage, quality, diversity, effective repetitions, small ablation을 봅니다.

6. Synthetic Judge가 통과시켰으니 정답이다

Generator와 judge가 같은 오류를 공유할 수 있습니다.

처방: Deterministic verifier, independent judge, sampled human audit를 결합합니다.

7. Train Loss가 낮으면 Instruction Following이 좋다

Memorization과 template matching일 수 있습니다.

처방: Unseen task·constraint·tool·grounding 평가와 retention을 봅니다.

8. Tool Call 성공 예시만 필요하다

No-tool, clarification, error, malicious result를 처리하지 못합니다.

처방: Decision boundary와 failure recovery trajectory를 포함합니다.

Production 체크리스트

스스로 확인하기

Response-only SFT의 loss 식에서 m_t는 system, user, assistant token에 어떻게 적용되는가?
Chat template가 학습과 serving에서 달라지면 어떤 failure가 생길 수 있는가?
Assistant content와 EOT token의 label을 함께 검사해야 하는 이유는 무엇인가?
Synthetic instruction을 split 전에 paraphrase하면 leakage가 생기는 이유는 무엇인가?
RAG Agent SFT에서 tool result를 보통 target이 아니라 context로 다루는 이유는 무엇인가?
Train loss 외에 base capability retention을 측정해야 하는 이유는 무엇인가?

앞 글에서 model 구조를, 이 글에서 supervised behavior를 만들었습니다. 다음 글은 Preference Optimization: RLHF·DPO·GRPO입니다. 하나의 정답 demonstration 대신 여러 응답의 선호, binary desirability, verifiable reward로 policy를 개선하는 방법과 reward hacking·KL drift를 다룹니다.