JSONL 학습 데이터 만들기의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.
CONTROLLED EXPLANATION
개념이 이어지는 순서를 직접 살펴보기
자동으로 시작하지 않습니다. 재생하거나 이전·다음 단계를 선택하면 현재 개념과 다음 판단의 연결을 차례로 설명합니다.
현재 설명 · 1/5
Row를 모으기 전에 학습할 행동과 실패 비용 정의하기
SFT dataset은 자료 창고가 아니라 model이 어떤 input에서 어떤 output 행동을 반복하게 할지 보여 주는 검토된 예시 집합이므로 업무 결과·rubric·보류 행동을 먼저 고정합니다.
최신 사실 저장, 검색 근거 제공과 형식·행동 학습을 구분합니다.
다음 연결: Source·권리·개인정보와 삭제 가능한 lineage 만들기에서 이 기준을 이어서 사용합니다.
전체 단계의 글 설명 보기
1. Row를 모으기 전에 학습할 행동과 실패 비용 정의하기
SFT dataset은 자료 창고가 아니라 model이 어떤 input에서 어떤 output 행동을 반복하게 할지 보여 주는 검토된 예시 집합이므로 업무 결과·rubric·보류 행동을 먼저 고정합니다. 최신 사실 저장, 검색 근거 제공과 형식·행동 학습을 구분합니다.
2. Source·권리·개인정보와 삭제 가능한 lineage 만들기
각 row가 어디서 왔고 어떤 목적으로 학습·평가·재배포할 수 있는지, 누구의 개인정보·secret이 포함됐는지를 source record와 review decision으로 연결합니다. 공개 접근과 학습·수정·재배포 허가는 같은 뜻이 아닙니다.
3. JSONL row schema와 model별 chat template 검증하기
JSONL의 file 규칙과 SFT task schema를 분리하고 exact tokenizer·chat template가 role·content를 어떤 token sequence와 loss 대상으로 바꾸는지 확인합니다. UTF-8과 한 줄 한 JSON 값을 지키되 valid JSON만으로 좋은 학습 row라고 판단하지 않습니다.
4. Label rubric·중복·coverage를 자동 검사와 사람 검수로 연결하기
Parse 성공 뒤에는 정답의 의미·일관성, label 분포·길이와 exact·near duplicate, source contamination을 자동 report와 blind 사람 review로 검증합니다. Label disagreement를 임의 다수결로 숨기지 않고 rubric·경계 문제로 분류합니다.
5. Group split·manifest·회귀와 삭제 rollback으로 dataset 승격하기
Row random split 전에 duplicate cluster·고객·문서·사건·시간 group을 정의해 leakage를 막고 frozen test, versioned manifest와 영향받은 artifact 복구를 시험합니다. Split seed만으로 같은 source family의 누출을 막을 수 없습니다.
움직임을 보지 않아도 아래 글 설명에서 같은 내용을 확인할 수 있습니다. 운영체제의 움직임 줄이기 설정도 따릅니다.개념 해설 01
Dataset을 문서 모음이 아니라 학습 행동 계약으로 정의한다
Supervised Fine-Tuning(SFT, 정답 예시 기반 미세조정) dataset은 text를 많이 담는 저장소가 아닙니다. 각 row는 특정 input에서 기대하는 output 행동을 보여 주는 training signal입니다. 회사 규정 PDF를 통째로 row로 바꾼다고 최신 근거를 안정적으로 답하는 system이 되지 않습니다. 자주 바뀌는 사실과 source 인용은 RAG가 맞을 수 있고, category·JSON schema·tone·거절 규칙처럼 반복 행동을 조정할 때 SFT가 후보가 됩니다.
학습 목표는 관찰 가능한 acceptance criterion으로 씁니다. “상담을 잘함” 대신 category가 승인 enum 안에 있음, urgency·reason이 필수, 주문 ID 부족 시 hold, 환불 확정은 하지 않음처럼 정합니다. Base model을 production-like 정상·경계·실패 100건에 먼저 실행해 정확도·형식·critical recall과 사람 correction을 baseline으로 남깁니다. Baseline 없이 training 뒤 좋아진 항목과 잃은 원래 능력을 구분할 수 없습니다.
Error taxonomy에는 잘못된 label, 누락, 근거 없는 추가, PII 재현, unsafe compliance, 형식·language와 지나친 거절을 나눕니다. 돈·권한·안전처럼 피해가 큰 class는 평균 점수로 상쇄하지 않는 독립 gate를 둡니다. 근거가 없거나 label끼리 충돌할 때는 그럴듯하게 하나를 고르는 정답 대신 insufficient·escalate 같은 terminal behavior를 예시로 줍니다.
Data plan은 정상·경계·불충분·거절과 실제 channel·language·길이를 matrix로 만듭니다. 각 cell의 업무 빈도·피해와 현재 failure 수를 보고 row 목표를 잡습니다. 10만 줄 같은 고정 숫자를 품질 목표로 쓰지 않습니다. 처음에는 reviewer가 전부 읽을 수 있는 작은 pilot로 load·template·token·loss·학습·평가 전체를 확인하고, 어떤 failure가 남았는지에 따라 새 원인 사례를 보강합니다.
왜 이런가
학습 행동과 실패 비용이 먼저 있어야 source·schema·label, 필요한 coverage와 평가 set을 한 기준으로 설계할 수 있기 때문입니다.
언제 문제가 되는가
자료를 먼저 긁어 모으면 목표와 무관한 text·권리 불명 row가 늘고 train loss는 내려가도 실제 업무 오류는 설명할 수 없습니다.
초보자가 자주 하는 오해
SFT에 최신 문서를 많이 넣는 것이 versioned RAG와 source 인용을 자동 대체하거나 새로운 일반 능력을 보장하지 않습니다.
직접 확인하는 방법
Base model의 고정 정상·경계·실패 set과 critical gate를 기록하고 각 planned row가 어떤 matrix cell·failure를 보강하는지 연결하십시오.
개념 해설 02
Source provenance와 사용 권리를 row보다 먼저 승인한다
웹에 공개됐거나 동료가 공유했다는 이유만으로 학습·재배포 권리가 생기지 않습니다. Exact license와 terms에서 commercial use, derivative work, redistribution·attribution과 금지 조건을 확인합니다. 상담·email·회의처럼 원래 다른 목적으로 수집한 사내 자료는 개인과 조직의 기대, contract·policy와 consent를 검토합니다. 판단이 필요한 자료를 “아마 가능”으로 train에 넣지 않고 rights_pending 상태로 격리합니다.
Source registry에는 source ID, owner, collected date·revision, acquisition method, rights basis·allowed purpose와 reviewer·expiry를 둡니다. Dataset row는 원문 전체 경로를 노출하기보다 제한된 source reference와 transform version을 연결합니다. Hash는 같은 file을 식별하는 단서지만 legal permission이나 내용 정확성을 증명하지 않습니다. Source와 row의 관계가 여러 대 여러인 경우 lineage table로 명시합니다.
Human-written·crowdsourced·machine-generated·translated·augmented row를 구분합니다. Synthetic output에는 생성 model·prompt·sampling과 사람이 source를 대조한 상태를 남깁니다. Model이 만든 답을 다른 model이 자연스럽다고 채점한 것만으로 gold label을 만들지 않습니다. 같은 source에서 만든 summary·translation·paraphrase는 표현이 달라도 독립 source가 아니므로 duplicate cluster와 split group을 공유합니다.
Dataset Card는 목적, source·구성, license·language·size, 수집·annotation, PII·bias·limitation과 intended·out-of-scope use를 전달합니다. Hugging Face 공식 안내도 card가 responsible use를 위한 context와 license metadata를 제공한다고 설명합니다. Card에 license tag를 썼다는 사실은 source별 rights 검토를 대신하지 않습니다. Rights 변경 trigger와 재검토 owner, 영향을 받은 release·adapter 처리 계획을 함께 기록합니다.
왜 이런가
Dataset은 원문을 변환·혼합하므로 source별 허용 목적과 파생 row·artifact의 영향을 추적해야 철회·오류를 실제로 처리할 수 있습니다.
언제 문제가 되는가
URL과 license tag만 남기면 exact revision·사내 consent와 학습·배포 조건을 알 수 없고 삭제 대상 adapter도 찾을 수 없습니다.
초보자가 자주 하는 오해
공개 접근, open-weight model, dataset card metadata와 hash 존재가 학습·상업 이용·재배포 권리의 자동 승인은 아닙니다.
먼저 필요한 data만 수집합니다. 이름이 없어도 소속·날짜·희귀 사건 조합으로 개인을 추정할 수 있고, conversation 여러 turn을 합치면 가린 값이 다시 드러날 수 있습니다. Email·전화·주소·계정·재무·건강, employee/customer ID와 code의 API key·token·private URL을 inventory합니다. Purpose에 필요 없는 field는 redaction보다 앞선 단계에서 제외합니다.
Microsoft Presidio는 rule·regular expression·NER·checksum과 custom recognizer로 PII 후보를 찾을 수 있지만 공식 안내는 자동 detection이 모든 민감정보를 찾는다고 보장하지 않는다고 경고합니다. Language·country와 사내 ID format별 test fixture를 만들고 secret scanner, entropy·known prefix rule을 함께 씁니다. False negative가 큰 class는 사람이 high-risk·random sample을 원문과 대조합니다.
Redaction 결과는 original span, replacement type·rule version과 reviewer decision을 제한된 ledger에 남깁니다. 동일 인물을 일관된 가명으로 바꿔야 dialog 의미가 보존되는 경우에도 mapping 접근과 retention을 통제합니다. 너무 많이 지워 task signal이 사라지거나 너무 적게 지워 재식별되는 양쪽 실패를 검토합니다. Learner가 보는 JSONL과 원본 검수 storage를 다른 권한 경계로 둡니다.
삭제 workflow는 source ID로 row·duplicate cluster, train/validation/test file, cache·snapshot과 adapter·merged model을 찾습니다. 모든 artifact에서 개별 row 영향을 완전히 제거하려면 재학습이 필요할 수 있으므로 owner가 위험·비용과 서비스 조치를 결정합니다. 삭제 request를 sample로 실행해 query 결과와 남은 copy를 확인하고 previous approved dataset 또는 model로 rollback합니다. NIST Privacy Framework는 이러한 data processing privacy risk를 조직적으로 관리하는 틀로 참고합니다.
왜 이런가
민감정보 탐지는 확률적·문맥 의존적이고 dataset은 여러 copy·cache·artifact로 파생되므로 최소 수집과 삭제 경로가 함께 필요하기 때문입니다.
언제 문제가 되는가
정규식 한 번으로 safe라고 표시하면 한국어 이름·문맥상 비밀·새 secret format과 파생 artifact를 놓칠 수 있습니다.
초보자가 자주 하는 오해
Local training, 별표 redaction 또는 PII scanner pass가 consent·access·retention과 재식별 위험을 자동 해결하지 않습니다.
직접 확인하는 방법
언어·PII·secret별 known fixture와 blind sample을 검사하고 한 source 삭제가 모든 row·split·cache·artifact에 미치는 영향을 lineage query로 확인하십시오.
개념 해설 04
JSONL file 규칙과 training row schema를 분리해 검사한다
JSON Lines(JSONL, 한 줄당 하나의 JSON 값) 공식 설명은 UTF-8 encoding, 각 line의 valid JSON value와 line terminator를 세 기본 요구로 둡니다. Byte Order Mark(BOM)는 넣지 않고 blank line은 valid value가 아닙니다. 문자열 안 줄바꿈은 실제 record separator가 아니라 JSON의 escape로 저장합니다. 마지막 newline은 file을 안전하게 이어 붙이는 데 권장됩니다.
Hugging Face Datasets 문서도 여러 JSON object를 한 줄씩 개별 row로 두는 형식을 효율적인 JSON 형태로 제시합니다. Loader가 file을 읽었다고 SFT schema가 맞는 것은 아닙니다. Parser는 line number, byte·character 위치와 exception을 report하고 partial load를 조용한 성공으로 취급하지 않습니다. Encoding replacement character와 field type inference가 row 사이에서 바뀌는지도 확인합니다.
Task별 schema를 versioning합니다. Conversational SFT라면 messages array, 각 message의 role·content, 허용 role·turn 순서, 최소 한 assistant target과 빈 content 금지를 정의합니다. Prompt-completion이면 prompt와 completion type·필수값을 구분합니다. Metadata에는 source_ref, rights_state, language, label·review와 group ID가 필요할 수 있지만 training input에 들어갈 field와 governance ledger field를 분리합니다.
Schema validator는 additional field, null·number를 string으로 강제 변환하는 loader behavior와 nested content를 검사합니다. Valid 구조 안의 답이 source와 맞는지, label 우선순위가 올바른지와 PII는 별도 검사입니다. Golden valid·invalid row set을 만들어 parser·schema version을 바꿀 때 예상 error code가 유지되는지 회귀합니다. Raw file hash와 validator report를 release manifest에 연결합니다.
왜 이런가
JSONL syntax와 trainer가 기대하는 column·role, 업무 정답은 서로 다른 실패층이므로 분리해야 정확한 복구가 가능하기 때문입니다.
언제 문제가 되는가
JSON.parse 성공만 보면 assistant target 없음·role 역전·빈 답과 rights 불명 같은 학습 실패가 모두 통과합니다.
초보자가 자주 하는 오해
확장자가 .jsonl이거나 Hugging Face loader가 읽었다는 사실은 SFT dataset·chat schema와 품질을 인증하지 않습니다.
Conversational format을 exact chat template와 loss mask로 렌더링한다
TRL 공식 dataset format은 standard와 conversational format, language modeling·prompt-only·prompt-completion·preference처럼 task type별 column을 구분합니다. 같은 messages JSON이라도 trainer가 전체 sequence loss, completion-only 또는 assistant-only loss를 적용할 수 있습니다. Exact TRL·Transformers version과 SFT configuration에서 지원 format과 default를 확인하고 dataset schema만 보고 학습 target을 추정하지 않습니다.
Hugging Face chat template 설명처럼 role·content list는 control token을 포함한 하나의 token sequence로 변환됩니다. 같은 base에서 fine-tune된 model도 서로 다른 role marker를 쓸 수 있고 잘못된 token은 성능을 크게 해칠 수 있습니다. Exact tokenizer revision의 apply_chat_template output을 저장해 system·user·assistant 경계와 end marker를 읽습니다. Training data와 serving prompt가 같은 contract를 쓰는지 비교합니다.
Special token 중복을 검사합니다. Template가 이미 BOS·EOS를 넣는데 tokenizer가 다시 추가하면 sequence가 달라질 수 있습니다. Multi-turn row에서 assistant 시작과 종료, tool turn이나 system placement를 model이 지원하는지 확인합니다. Loss mask를 token 위에 겹쳐 보여 user·system까지 정답으로 학습하는지, 마지막 assistant만 또는 모든 assistant response가 target인지 설정과 의도를 대조합니다.
Rendered token length distribution과 truncation report를 만듭니다. 긴 system이나 history 때문에 마지막 정답이 잘린 row, assistant response 대부분이 max length 밖인 row는 parse가 성공해도 학습 signal이 아닙니다. Character 수가 비슷해도 language·template에 따라 token이 달라집니다. Representative·long·multi-turn·empty/unsupported role golden row로 text·token ID·mask hash를 회귀하고 변경 시 dataset candidate를 다시 평가합니다.
왜 이런가
Causal model은 JSON object가 아니라 token sequence를 학습하고 loss mask가 실제로 업데이트할 위치를 정하기 때문입니다.
언제 문제가 되는가
Messages 모양만 맞추면 다른 model marker·중복 special token과 잘린 assistant target 때문에 예상 행동을 학습하지 못합니다.
초보자가 자주 하는 오해
Role 이름이 user·assistant로 같아도 모든 model·trainer가 같은 template·special token과 loss 범위를 사용하지 않습니다.
직접 확인하는 방법
Golden row를 exact tokenizer/template·trainer config로 렌더링해 token·mask·truncation을 보고 inference의 첫 user request sequence와 비교하십시오.
개념 해설 06
Annotation rubric과 독립 review로 의미 정답을 만든다
Annotation guide는 label 이름만 나열하지 않습니다. 각 class가 무엇인지, 포함·제외 조건, 여러 class가 맞을 때 우선순위, source 부족·충돌과 out-of-scope 행동을 정의합니다. Positive·negative·borderline 예시를 서로 다른 숫자·상황으로 제공합니다. 자유문 답은 필수 fact·금지 addition, tone·format과 거절 조건을 rubric으로 나눠 reviewer가 어느 문장을 고칠지 표시하게 합니다.
Annotator는 source와 충분한 context를 볼 권한과 domain 지식을 가져야 합니다. 개인 판단을 줄이려고 identity가 필요 없는 항목은 blind review하고, model이 만든 답을 그대로 정답처럼 제시하지 않습니다. 일부 overlap sample을 두 명 이상이 독립 검수해 agreement와 class별 confusion을 봅니다. 개인정보를 포함한 disagreement note도 최소화하고 access·retention을 적용합니다.
불일치는 무조건 다수결로 끝내지 않습니다. Source가 모호한지, rubric 경계가 겹치는지, training goal 자체가 여러 행동을 허용하는지 분류합니다. Adjudicator는 최종 label과 이유 code, guide 변경 version을 남깁니다. Guide를 고치면 같은 ambiguity sample과 이미 승인된 영향 row를 재검토합니다. 합의 숫자 하나보다 어떤 critical class에서 왜 갈렸는지가 더 중요합니다.
Review workflow에는 drafted·reviewed·approved·rejected·quarantined 상태와 작성자·검수자 분리를 둡니다. Edit rate, reject·escalate와 defect taxonomy를 source·authoring method별로 집계합니다. 특정 synthetic prompt나 공급자가 높은 오류율을 보이면 row만 지우지 않고 해당 batch 전체를 격리합니다. 최종 gold row는 source·rubric version과 approval을 역추적할 수 있어야 합니다.
왜 이런가
SFT는 label의 반복 패턴을 학습하므로 모호하거나 서로 충돌하는 정답이 model 행동과 평가 기준을 함께 오염시키기 때문입니다.
언제 문제가 되는가
한 사람이 빠르게 작성하고 parse만 검사하면 같은 input에 다른 정책과 근거 없는 자연스러운 답이 gold로 섞입니다.
초보자가 자주 하는 오해
Reviewer agreement가 높거나 model judge가 승인하면 source accuracy·rights와 새 상황의 독립 사람 검토가 자동 완성되는 것은 아닙니다.
직접 확인하는 방법
Blind overlap sample의 class별 disagreement·edit reason을 보고 guide 변경 전후 같은 ambiguity set에서 독립 review를 반복하십시오.
개념 해설 07
Exact·near duplicate와 coverage를 source cluster 단위로 본다
Exact duplicate는 raw bytes와 Unicode normalization, 공백·case·문장부호를 정리한 input·target hash로 찾습니다. Prompt만 같고 답이 다른 충돌, 답은 같지만 질문이 template boilerplate인 경우를 따로 봅니다. Dedup normalization이 code·ID·숫자처럼 의미 있는 차이를 지우지 않는지 sample을 확인합니다. Duplicate 제거 decision과 대표 row ID를 보존합니다.
Near duplicate에는 문장 순서 변경, 번역·요약·paraphrase와 같은 document chunk가 있습니다. Embedding similarity는 후보를 찾는 단서이지 같은 의미의 확정 판정이 아닙니다. Source family·customer event와 generation parent ID를 우선 cluster key로 쓰고 사람이 경계 pair를 검토합니다. Synthetic row가 많아도 같은 prompt·source를 재표현했다면 independent coverage로 세지 않습니다.
Coverage는 전체 row count가 아니라 task matrix로 봅니다. Label, normal·edge·hold·refusal, language·length·channel, source type·time과 privacy/security risk별 approved row·group 수를 표시합니다. Critical class가 적다고 같은 row를 여러 번 복사하면 weight는 늘지만 새 상황은 늘지 않습니다. 실제 failure에서 원인이 다른 source를 수집하거나 class-balanced sampling을 training config에서 투명하게 관리합니다.
자동 report 뒤에는 random, high-risk, longest·shortest, duplicate boundary와 source·author method별 sample을 사람이 읽습니다. Label distribution이 production과 다르면 의도적 oversampling과 왜곡을 구분합니다. Filter가 특정 dialect·언어·짧은 거절을 과도하게 제거하지 않는지 before/after matrix를 비교합니다. Candidate와 previous version의 row·group·coverage diff를 승인 evidence에 포함합니다.
왜 이런가
중복은 특정 패턴을 과도하게 학습시키고 source가 겹친 평가를 만들며, row 총수는 실제 상황 다양성을 보여 주지 못하기 때문입니다.
Embedding similarity가 높으면 항상 중복이거나 row 수가 많고 label 비율이 균형이면 production coverage가 충분한 것은 아닙니다.
직접 확인하는 방법
Normalized hash·source parent·semantic candidate로 cluster를 만들고 matrix cell별 unique group·review pass와 before/after 제거 영향을 확인하십시오.
개념 해설 08
Group·time split과 frozen test로 leakage를 차단한다
Hugging Face Datasets의 train_test_split은 크기와 shuffle을 정해 row를 나누는 편리한 기능입니다. 그러나 같은 ticket의 원문·요약·paraphrase가 다른 row이면 random shuffle은 train과 test에 모두 보낼 수 있습니다. Model이 training에서 본 답의 의미를 다시 맞히면 점수가 일반화보다 높아집니다. Split 함수보다 무엇을 한 group으로 볼지가 먼저입니다.
Scikit-learn GroupShuffleSplit은 임의의 domain group에 따라 index를 분리하는 방법을 제공합니다. 상담은 customer·ticket thread, 문서는 document revision family, code는 repository·issue, 음성은 speaker·recording session을 group으로 삼을 수 있습니다. 같은 group의 모든 row를 한 split에만 둡니다. 한 row에 여러 source가 있으면 가장 넓은 연결 component로 묶는 보수적 경계를 검토합니다.
시간 변화가 핵심이면 과거 train, 다음 기간 validation, 최신 기간 frozen test처럼 time split을 사용합니다. Validation은 schema·data·hyperparameter·checkpoint 선택에 쓰고 test는 최종 candidate 비교에 제한합니다. Test failure를 보고 row를 추가하거나 prompt·threshold를 바꾼 순간 그 test는 development evidence가 됩니다. 새로운 release에는 접근하지 않은 blind set 또는 다음 시간 구간이 필요합니다.
Split 뒤 exact·near duplicate, source·group overlap을 양방향으로 검사하고 0이 아니면 hold합니다. 각 split의 critical label·language·길이·risk coverage와 group 수를 확인합니다. Group 분리로 rare class가 test에 없다면 train row를 test로 복사하지 않고 수집 기간·source를 넓힙니다. Seed·algorithm version, group rule·mapping, split file hash와 test access log를 manifest에 남깁니다.
왜 이런가
표현이 다른 row도 같은 source·사건의 답을 공유하므로 row-level random split은 독립 일반화 평가를 쉽게 깨뜨리기 때문입니다.
언제 문제가 되는가
80:10:10 비율과 seed만 기록하면 같은 고객·문서 family가 세 split에 흩어져 test score가 부풀 수 있습니다.
초보자가 자주 하는 오해
Group splitter 사용 자체가 올바른 group 정의·time boundary, near duplicate 0과 frozen test discipline을 자동 보장하지 않습니다.
직접 확인하는 방법
Train·validation·test의 source/group/duplicate ID 교집합을 계산하고 일부 group을 역추적해 모든 파생 row가 한 split에만 있는지 확인하십시오.
개념 해설 09
Manifest·dataset card·회귀와 삭제 rollback으로 승격한다
Release manifest에는 source snapshot·rights state, raw/clean row·group·split hash, schema·conversion code, PII·secret scan, annotation guide·review report, tokenizer/chat template, rendered token·mask statistics, split algorithm·seed와 Dataset Card를 둡니다. Mutable latest 경로가 아니라 immutable dataset version을 training config에 고정합니다. 한 항목이 바뀌면 영향받는 downstream 평가를 다시 실행합니다.
Gate는 line parse·schema 100%, unsupported role·target truncation 0, critical label threshold, rights_pending·unreviewed PII 0, source/group/duplicate split overlap 0처럼 독립 판정합니다. Coverage와 reviewer edit·agreement, base 대비 frozen task metric·safety와 원래 능력 회귀를 함께 봅니다. 낮은 train loss나 평균 accuracy가 privacy·rights·critical class 실패를 상쇄하지 않습니다. 결과를 본 뒤 threshold를 낮추지 않습니다.
작은 training run으로 load, loss mask·memory, checkpoint·evaluation pipeline을 확인하고 previous dataset과 exact base·config에서 비교합니다. Model·data·training 변수를 동시에 바꾸지 않습니다. 제한 canary에서 실제 correction과 새로운 failure를 수집하되 production input을 consent·review 없이 바로 training row로 되먹이지 않습니다. Failure는 source·schema·label·split·training 중 원인 layer에 연결합니다.
Rollback은 JSONL file만 이전 것으로 바꾸는 일이 아닙니다. Previous dataset manifest, conversion·template, training config·adapter와 serving artifact를 호환되는 묶음으로 복구합니다. Rights 철회·PII 발견 sample에서 affected row·cache·split·artifact를 lineage로 찾고 삭제·재학습 또는 서비스 중단 결정을 시험합니다. Owner, limitation, source·policy·model 변경과 defect trigger를 기록하고 같은 frozen·failure set 재시험 뒤에만 release를 닫습니다.
왜 이런가
Dataset 변경은 token sequence·학습 결과와 privacy·rights까지 바꾸므로 모든 input·code·review와 artifact를 재현·복구 가능한 release로 관리해야 하기 때문입니다.
언제 문제가 되는가
최종.jsonl 이름과 train loss만 남기면 어느 source·template·split으로 만든 model인지, 오류·삭제 때 무엇을 되돌릴지 알 수 없습니다.
초보자가 자주 하는 오해
모든 자동 검사와 frozen score 통과도 실제 권리 승인·초보자 검토를 대신하지 않으며 dataset card가 법적 인증서는 아닙니다.
Messages row를 parse한 뒤 system→user→assistant role·content와 metadata schema를 확인하고 exact tokenizer의 apply_chat_template 결과에서 control token 중복·assistant loss mask·truncation을 golden fixture로 비교합니다.
이 사례에서 확인할 핵심: UTF-8과 한 줄 한 JSON 값을 지키되 valid JSON만으로 좋은 학습 row라고 판단하지 않습니다.
사례 4 · Label rubric·중복·coverage를 자동 검사와 사람 검수로 연결하기
두 reviewer가 독립 label한 100개에서 category conflict와 reason 누락을 보고 adjudication한 뒤 normalized input·output hash와 embedding 유사도로 같은 ticket의 변형을 cluster해 대표 한 묶음으로 관리합니다.
이 사례에서 확인할 핵심: Label disagreement를 임의 다수결로 숨기지 않고 rubric·경계 문제로 분류합니다.
사례 5 · Group split·manifest·회귀와 삭제 rollback으로 dataset 승격하기
같은 고객 ticket의 원문·요약·번역·paraphrase를 하나의 group으로 묶고 과거 월 train, 다음 월 validation, 최신 월 frozen test로 분리해 group overlap 0과 critical class coverage를 확인합니다.
이 사례에서 확인할 핵심: Split seed만으로 같은 source family의 누출을 막을 수 없습니다.
CHAPTER 1 / 5
Row를 모으기 전에 학습할 행동과 실패 비용 정의하기
“우리 문서를 모델에 학습시키자”는 말만으로는 dataset을 설계할 수 없습니다. 원하는 것이 매달 바뀌는 규정의 최신 답인지, 정해진 JSON 형식인지, 특정 tone·거절 행동인지 구분합니다. 최신 사실과 source 인용은 Retrieval-Augmented Generation(RAG, 검색 증강 생성)이 더 적합할 수 있고, Supervised Fine-Tuning(SFT, 정답 예시 기반 미세조정)은 반복되는 형식·판단 경계·응답 스타일을 조정하는 후보입니다. Base model이 이미 못하는 능력을 row 수만으로 만들 수 있다고 가정하지 않습니다.
학습 성과를 관찰 가능한 output으로 씁니다. “친절하게 답함” 대신 승인된 category enum, 필수 reason, 근거 부족 시 hold, 개인정보 요청 거절처럼 parser와 reviewer가 판단할 조건을 정합니다. Production input 100건에서 현재 base의 정확도·형식·거절과 사람 correction을 baseline으로 측정합니다. 어느 오류가 평균에 숨으면 안 되는 critical class인지와 자동 처리·사람 queue 경계를 data 수집 전에 owner가 승인합니다.
Data matrix는 정상만 채우지 않습니다. 짧고 긴 입력, 오타·혼합 언어, 빈 필수값, label 충돌, out-of-scope, 안전 거절과 adversarial 표현을 축으로 둡니다. 각 cell의 실제 빈도와 피해를 보고 목표 개수를 정합니다. 똑같은 문장을 숫자만 바꿔 늘리는 대신 원인이 다른 사례를 모읍니다. 드문 critical class는 별도 recall gate를 두며 전체 accuracy로 상쇄하지 않습니다.
수집 plan에는 source, owner, 작성·검토 방법, 허용 목적과 retention을 연결합니다. Model-generated synthetic row는 생성 model·prompt와 사람 검토를 표시하고 실제 분포를 대표한다고 오인하지 않습니다. Pilot은 50~200개처럼 사람이 전부 읽을 수 있는 규모로 schema→template→tokenization→small training→업무 평가 경로를 먼저 시험합니다. Pipeline이 맞은 뒤 실패 유형을 근거로 확대합니다.
그림 읽는 법 Dataset은 text file 하나가 아니라 목표·source·권리·label·schema·split·평가가 이어지는 versioned release입니다. Row 수는 이 계약을 통과한 결과이지 출발점이 아닙니다.
핵심을 다시 정리하면
최신 사실 저장, 검색 근거 제공과 형식·행동 학습을 구분합니다.
정상·경계·거절·불충분 input의 목표 비율과 합격선을 결과 전에 정합니다.
현실에서 이렇게 연결됩니다
고객 문의를 category·urgency·reason의 JSON으로 분류한다면 일반 문의뿐 아니라 두 category가 충돌하거나 주문 번호가 없는 사례와 unverified 보류 정답을 함께 설계합니다.
CHAPTER 2 / 5
Source·권리·개인정보와 삭제 가능한 lineage 만들기
인터넷에서 읽을 수 있다는 사실은 model training과 결과 재배포 허가를 자동 부여하지 않습니다. Source owner·작성자, exact license·terms, 수집 방식과 commercial use·derivative·redistribution 조건을 실제 계획에 대조합니다. 사내 자료도 직원·고객과 조직 사이의 원래 수집 목적, 동의와 접근 정책을 확인합니다. 법률 판단이 필요한 경우 담당 검토 전에는 사용 가능이라고 표시하지 않고 quarantine 상태로 둡니다.
Row에는 원문 전체를 복제한 URL만 넣기보다 source record, collected date·revision, rights basis, allowed purpose, owner와 review status를 별도 ledger로 연결합니다. Source가 철회·만료되거나 오류가 발견되면 어느 row, split, dataset version과 adapter가 영향을 받는지 역추적해야 합니다. 원본 hash와 변환 code·redaction decision을 보존하되 learner용 JSONL에는 불필요한 식별 metadata를 노출하지 않습니다.
Email·전화·주소·계정 ID, 건강·재무 내용과 API key·password·token을 수집 단계부터 최소화합니다. Presidio 같은 도구는 pattern·NER·checksum으로 여러 PII 후보를 찾을 수 있지만 공식 문서도 자동 탐지가 모든 민감정보를 찾는다고 보증하지 않습니다. 한국어 이름·사내 identifier·문맥상 비밀과 긴 secret은 custom rule·entropy·allowlist/denylist와 사람이 위험 sample을 읽어 보완합니다. 탐지되지 않았다는 결과를 안전 증명으로 쓰지 않습니다.
Redaction은 원문을 별표로 가리는 한 번의 작업이 아닙니다. 같은 사람을 추론할 quasi-identifier 조합, conversation 안의 반복 이름과 attachment metadata를 봅니다. 원본은 최소 권한·암호화·짧은 retention과 audit 아래 분리하고 학습 row에는 목적상 필요한 정보만 남깁니다. 삭제 요청이나 rights 변경 시 source→row→split→artifact를 찾아 제거하고 재학습·배포 판단을 남기는 deletion workflow를 실제로 시험합니다.
핵심을 다시 정리하면
공개 접근과 학습·수정·재배포 허가는 같은 뜻이 아닙니다.
자동 PII·secret scan은 사람 검토와 접근·보존·삭제 통제를 대신하지 않습니다.
현실에서 이렇게 연결됩니다
상담 ticket row에는 원본 record ID의 제한된 hash, consent·license basis, PII scan·사람 review, redaction version과 삭제 요청 시 파생 split·artifact를 찾을 lineage를 남깁니다.
CHAPTER 3 / 5
JSONL row schema와 model별 chat template 검증하기
JSON Lines(JSONL, 한 줄당 하나의 JSON 값) 문서는 UTF-8, 각 줄의 valid JSON value와 line terminator를 기본 요구로 설명합니다. Blank line은 valid value가 아니고 문자열 안 실제 줄바꿈은 JSON escape로 표현해야 합니다. Hugging Face Datasets도 여러 JSON object가 한 줄씩 개별 row인 형식을 효율적인 JSON 형태로 설명합니다. Parser는 line number·byte 위치와 오류 이유를 반환하고 손상 한 줄 때문에 조용히 전체 뒤쪽을 버리지 않게 합니다.
File format과 training schema는 다릅니다. TRL 공식 format 안내는 language-modeling의 text/messages, prompt-only, prompt-completion과 preference처럼 task별 column이 다름을 보여 줍니다. SFT 목적이 assistant response 학습이라면 messages 전체에 loss를 줄지 completion·assistant turn만 줄지 trainer 설정을 확인합니다. Required field·type, 허용 role·순서, 빈 content, unknown key와 metadata version을 schema로 고정합니다.
Chat row는 object 배열 그대로 model에 들어가지 않습니다. Hugging Face chat template 문서처럼 role·content는 model별 control token sequence로 바뀌고 잘못된 token은 성능을 크게 해칠 수 있습니다. Exact base model·tokenizer revision의 template를 적용해 rendered text·token ID, BOS/EOS 중복과 assistant 시작·종료를 확인합니다. Training과 inference가 다른 template를 쓰면 row 내용이 맞아도 배포 행동이 깨집니다.
Length는 character나 file byte가 아니라 rendered token으로 측정합니다. Truncation이 system instruction·user 질문·assistant 정답 중 어느 쪽을 자르는지 표시하고 필수 정답이 잘린 row는 hold합니다. Conversation의 마지막 assistant만 학습할지 모든 assistant turn을 학습할지 mask를 시각화합니다. Exact JSONL bytes, schema·conversion code, tokenizer/template revision과 token statistics를 dataset manifest에 고정합니다.
핵심을 다시 정리하면
UTF-8과 한 줄 한 JSON 값을 지키되 valid JSON만으로 좋은 학습 row라고 판단하지 않습니다.
Standard·conversational, language modeling·prompt-completion 형식을 trainer version과 loss 설정에 맞춥니다.
현실에서 이렇게 연결됩니다
Messages row를 parse한 뒤 system→user→assistant role·content와 metadata schema를 확인하고 exact tokenizer의 apply_chat_template 결과에서 control token 중복·assistant loss mask·truncation을 golden fixture로 비교합니다.
CHAPTER 4 / 5
Label rubric·중복·coverage를 자동 검사와 사람 검수로 연결하기
Schema를 통과한 답도 틀릴 수 있습니다. Annotation guide에는 label 정의, 포함·제외 조건, 우선순위, insufficient·conflict와 예시·반례를 씁니다. Reviewer는 source와 target을 보고 correct·edit·reject·escalate를 선택하고 이유 code를 남깁니다. 일부 overlap sample을 독립적으로 label해 disagreement를 측정하고, 합의가 낮으면 사람을 탓하기 전에 모호한 task·rubric과 source 부족을 고칩니다.
자동 검사에는 parse·schema, role·turn, 빈 값, rendered token min/max·truncation, label·language·source 분포와 금칙·PII·secret scan을 둡니다. Critical output은 JSON schema뿐 아니라 enum·계산·근거와 refusal rule을 확인합니다. 수치 report를 보기 전에 threshold를 정하고 실패 row를 삭제만 하지 말고 source·작성·변환·review stage별 원인을 집계합니다.
중복은 exact text에만 있지 않습니다. Unicode·공백·case·문장부호를 normalize한 hash, prompt·answer를 따로 비교하고 near duplicate·template boilerplate·번역·synthetic paraphrase를 cluster합니다. 같은 source document나 customer event에서 파생된 여러 chunk는 서로 다른 문장이어도 강하게 연결됩니다. Duplicate weight가 특정 label·tone을 과도하게 학습시키고 train·test leakage를 만들 수 있어 cluster ID를 manifest에 보존합니다.
Coverage report는 row 총수보다 task matrix cell을 보여 줍니다. 정상·경계·거절·공격, language·길이·channel, critical class와 source group별 개수·review pass를 비교합니다. 드문 class를 단순 oversampling하면 동일 문장을 외울 수 있어 새로운 원인 사례를 검토해 추가합니다. 무작위 sample, high-risk·high-loss와 자동 flag sample을 사람이 읽고 edit rate와 defect taxonomy를 release evidence로 남깁니다.
핵심을 다시 정리하면
Label disagreement를 임의 다수결로 숨기지 않고 rubric·경계 문제로 분류합니다.
Synthetic·번역·paraphrase row가 같은 source 의미를 반복하면 독립 다양성으로 세지 않습니다.
현실에서 이렇게 연결됩니다
두 reviewer가 독립 label한 100개에서 category conflict와 reason 누락을 보고 adjudication한 뒤 normalized input·output hash와 embedding 유사도로 같은 ticket의 변형을 cluster해 대표 한 묶음으로 관리합니다.
CHAPTER 5 / 5
Group split·manifest·회귀와 삭제 rollback으로 dataset 승격하기
Hugging Face Datasets의 train_test_split은 비율을 정해 split을 만들고 기본으로 shuffle합니다. 하지만 row-level shuffle은 같은 고객·문서·사건에서 나온 near duplicate를 양쪽에 보낼 수 있습니다. Scikit-learn GroupShuffleSplit처럼 domain group을 별도 값으로 제공하면 group 단위로 분리할 수 있습니다. 이 기능을 쓴다는 사실만으로 group ID가 올바른 것은 아니므로 leakage 단위를 업무에서 정의합니다.
고객 상담은 customer 또는 ticket thread, 문서는 document revision family, code는 repository·issue, 시간 변화는 month·release를 group으로 삼을 수 있습니다. 미래 behavior를 평가하려면 time split이 random split보다 현실적일 수 있습니다. Train은 학습, validation은 설정·checkpoint 선택, frozen test는 최종 비교에만 사용합니다. Test를 보고 row·prompt·hyperparameter를 고치면 이미 개발 set이므로 새 blind test가 필요합니다.
Split 뒤 exact·near duplicate와 source/group overlap을 다시 계산합니다. Label·language·길이·critical class coverage가 각 split에 있는지 보고 group 분리 때문에 rare class가 사라지면 기간·수집을 조정하지 row를 몰래 복사하지 않습니다. Dataset Card에는 목적, 구성·source, license·language·size, 수집·annotation, PII·bias·limitation과 intended/out-of-scope use를 기록합니다. Card metadata가 rights 검토 자체를 대신하지는 않습니다.
Release manifest에는 source snapshot, row·group ID와 split hash, schema·conversion, tokenizer/template, scan·review report, seed와 dataset card를 고정합니다. Candidate는 parse·template, critical label, rights·privacy, duplicate/leakage 0과 frozen evaluation을 독립 gate로 통과해야 합니다. Canary training과 base comparison 뒤 문제가 생기면 previous dataset·adapter로 rollback하고 삭제 row가 cache·split·artifact에 남지 않았는지 같은 lineage query로 재검증합니다.
그림 읽는 법 Split 비율보다 누출 단위가 먼저입니다. 같은 source family를 하나의 group으로 묶어 train·validation·frozen test 사이의 exact·near duplicate와 group overlap을 0으로 확인하고, gate 하나라도 실패하면 dataset은 candidate로 남습니다.
핵심을 다시 정리하면
Split seed만으로 같은 source family의 누출을 막을 수 없습니다.
Dataset candidate는 품질·privacy·rights·coverage·leakage gate를 모두 통과해야 승격합니다.
현실에서 이렇게 연결됩니다
같은 고객 ticket의 원문·요약·번역·paraphrase를 하나의 group으로 묶고 과거 월 train, 다음 월 validation, 최신 월 frozen test로 분리해 group overlap 0과 critical class coverage를 확인합니다.
INTERACTIVE LAB 1 / 2
실습 1 · JSONL row·권리·template 계약 실습
브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.
목표·source·JSONL·template와 사람 review로 row 계약 만들기
Valid JSON 한 줄이 아니라 실제 학습 행동과 권리·privacy·rendered token까지 연결된 row인지 판정합니다. 기본값은 일부러 실패합니다.
상황
인터넷과 상담 문장을 모아 text field에 넣었지만 무엇을 학습할지, 사용할 권리와 어느 token이 target인지 알 수 없습니다.
목표
한 개 이상의 conversational JSONL row를 직접 입력하고 관찰 가능한 행동·source·PII·template·review contract를 통과시킵니다.
Dataset 승격 gate 실행 후 합격선을 낮추지 않고 원인 stage를 고쳐 같은 raw snapshot과 frozen test를 재실행합니다.
증빙 한계: 입력값을 판정할 뿐 실제 dataset·scanner·tokenizer·splitter·trainer를 실행하지 않습니다. 통과 화면은 raw report, row/group hash·frozen evaluation, rights·deletion과 rollback 기록을 대신하지 않습니다.
KEY TERMS
이번 단원 핵심 용어
Data contract
학습 목표·row schema·source·권리·label rubric, validation·split과 승인 조건을 version으로 고정한 계약
JSONL
UTF-8 text에서 각 줄을 독립된 valid JSON value로 저장하는 record-oriented 형식
Data leakage
같은 source·정답 또는 강하게 연결된 정보가 train과 평가 split에 함께 들어가 일반화 점수를 부풀리는 현상
Data lineage
원본 source에서 변환·redaction·row·split·dataset과 학습 artifact까지 이어지는 추적 관계
UNIT WORKBOOK
개념을 새로운 상황에 적용하는 문제와 기록지
기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.
기본 문제 1
JSON Lines(JSONL) file과 SFT row contract를 가장 정확하게 구분한 설명은 무엇입니까?
기본 문제 2
Conversational SFT row를 training 전에 확인하는 방법 중 가장 완성된 것은 무엇입니까?
적용 문제 3
상담 ticket으로 dataset을 만들었고 PII scanner가 finding 0건을 보고했습니다. 다음 행동으로 가장 적절한 것은 무엇입니까?
한국어 이름·사내 고객 ID와 희귀 사건이 자유문에 있고 일부 source의 학습·재배포 허가는 아직 확인되지 않았습니다.
적용 문제 4
Critical refund label이 부족해 같은 ticket의 원문·요약·번역·paraphrase를 각각 새 row로 추가했습니다. 가장 적절한 품질 처리는 무엇입니까?
종합 문제 5
Dataset candidate v3을 SFT production 후보로 승격하는 계획 중 가장 완성된 것은 무엇입니까?
미세조정이 필요한 행동을 base baseline으로 증명하고 exact model·template·data·LoRA/QLoRA 설정을 고정해 checkpoint 품질·회귀·재현·rollback으로 adapter를 승인합니다.
난이도
실습
구성
강의 5개 · 실습 2개 · 평가
도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.
NEW HIRE ONBOARDING
첫 업무를 받는 순서로 시작합니다
중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.
01
상황을 한 문장으로 읽기
고객 문의를 category·urgency·reason JSON으로 내는 업무에서 base 형식 준수 71%, critical refund recall 82%를 기록하고, 최신 환불 규정은 RAG로 유지한 채 판단 경계·hold 행동만 SFT 후보로 둡니다.
02
오늘 맡은 일
미세조정이 필요한 행동을 base baseline으로 증명하고 exact model·template·data·LoRA/QLoRA 설정을 고정해 checkpoint 품질·회귀·재현·rollback으로 adapter를 승인합니다.
03
완료를 보여 주는 증거
Checkpoint 선택 metric과 독립 필수 gate를 결과 전에 고정합니다.
04
멈추고 선임에게 확인할 경계
Base license·revision·tokenizer·chat template와 배포 runtime 지원을 시작 전에 고정합니다.
낯선 용어 먼저 풀기
LoRA
Pretrained base weight를 frozen하고 선택한 layer에 작은 low-rank update 행렬을 학습하는 parameter-efficient adaptation 기법
QLoRA
Frozen quantized base를 통과해 gradient를 LoRA adapter에 전달하며 NF4 등으로 base weight memory를 낮추는 fine-tuning 접근
Target module
LoRA adapter를 주입할 실제 architecture layer의 이름과 범위
PREREQUISITE CHECK
본문을 읽기 전에 확인할 세 가지
정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.
1Fine-tuning은 최신 문서를 model이 출처와 함께 답하게 만드는 가장 쉬운 방법입니까?
아닙니다. 자주 바뀌는 사실과 원문 인용은 RAG가 더 관리하기 쉬울 수 있습니다. Fine-tuning은 고정된 input에서 형식·판단 경계·tone·거절처럼 반복되는 output 행동을 조정할 때 후보가 됩니다.
2QLoRA의 4-bit는 base·adapter·gradient·optimizer와 모든 계산이 4-bit라는 뜻입니까?
그렇지 않습니다. QLoRA는 frozen base weight를 4-bit로 표현해 memory를 줄이지만 compute dtype, adapter·gradient·optimizer와 activation은 별도입니다. Exact 설정과 단계별 actual peak를 측정해야 합니다.
3Training loss가 계속 내려가면 마지막 checkpoint가 production에 가장 좋습니까?
보장되지 않습니다. Train·validation loss는 proxy이고 마지막 checkpoint에서 critical refusal·일반 능력과 serving 성능이 악화될 수 있습니다. Base·previous와 같은 frozen 업무·safety·regression gate로 checkpoint를 비교해야 합니다.
TEXTBOOK GUIDE
개념의 배경부터 판단 기준까지 읽는 본문
IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.
CONCEPT FLOW
각 장은 이렇게 연결됩니다
각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.
1장학습 전에 미세조정할 행동과 base baseline 증명하기→
2장LoRA update와 target module·rank를 실제 trainable parameter로 확인하기→
4장Template·loss mask·batch와 clean run을 관측 가능한 training 계약으로 만들기→
5장Best checkpoint를 base·previous 대비 업무·안전 회귀와 rollback으로 승인하기
LoRA·QLoRA 미세조정의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.
CONTROLLED EXPLANATION
개념이 이어지는 순서를 직접 살펴보기
자동으로 시작하지 않습니다. 재생하거나 이전·다음 단계를 선택하면 현재 개념과 다음 판단의 연결을 차례로 설명합니다.
현재 설명 · 1/5
학습 전에 미세조정할 행동과 base baseline 증명하기
Fine-tuning은 최신 사실을 넣는 만능 단계가 아니라 고정된 input에서 반복되는 output 형식·판단·거절 행동을 조정하는 변경이므로 prompt·RAG·rule baseline보다 나은 이유와 실패 비용을 먼저 증명합니다.
Base와 prompt/RAG 후보를 같은 frozen 업무 set에서 비교합니다.
다음 연결: LoRA update와 target module·rank를 실제 trainable parameter로 확인하기에서 이 기준을 이어서 사용합니다.
전체 단계의 글 설명 보기
1. 학습 전에 미세조정할 행동과 base baseline 증명하기
Fine-tuning은 최신 사실을 넣는 만능 단계가 아니라 고정된 input에서 반복되는 output 형식·판단·거절 행동을 조정하는 변경이므로 prompt·RAG·rule baseline보다 나은 이유와 실패 비용을 먼저 증명합니다. Base와 prompt/RAG 후보를 같은 frozen 업무 set에서 비교합니다.
2. LoRA update와 target module·rank를 실제 trainable parameter로 확인하기
LoRA는 frozen base weight 옆에 작은 low-rank update 행렬을 학습하지만 효율성은 자동 품질 보증이 아니며 어느 module에 어떤 rank·alpha를 붙였는지와 실제 trainable parameter를 검증해야 합니다. Rank·alpha·dropout·bias·modules_to_save와 target module 목록을 config와 log에 남깁니다.
QLoRA는 frozen 4-bit quantized base를 통해 gradient를 LoRA adapter로 전달해 weight memory를 낮추지만 activation·gradient·optimizer·workspace가 남으므로 model 크기나 VRAM만으로 실행을 보증하지 않습니다. NF4·double quant·compute dtype과 adapter dtype을 각각 기록합니다.
4. Template·loss mask·batch와 clean run을 관측 가능한 training 계약으로 만들기
학습 row가 exact chat template로 어떤 token sequence가 되고 어느 assistant/completion token에 loss가 적용되는지 고정한 뒤 learning rate·effective batch·steps와 checkpoint·resume를 clean run으로 검증합니다. Training과 serving의 tokenizer·template·special token을 golden fixture로 비교합니다.
5. Best checkpoint를 base·previous 대비 업무·안전 회귀와 rollback으로 승인하기
마지막이나 validation loss가 가장 낮은 checkpoint를 자동 채택하지 않고 frozen 업무·critical·safety·원래 능력·운영 지표를 base와 previous adapter에 비교해 deployable bundle과 복구를 승인합니다. Checkpoint 선택 metric과 독립 필수 gate를 결과 전에 고정합니다.
움직임을 보지 않아도 아래 글 설명에서 같은 내용을 확인할 수 있습니다. 운영체제의 움직임 줄이기 설정도 따릅니다.개념 해설 01
미세조정을 GPU 작업이 아니라 행동 변경 결정으로 시작한다
Fine-tuning(미세조정)은 model을 처음부터 만드는 pretraining의 작은 버전이 아닙니다. 이미 언어 능력이 있는 base model에 검토된 input·target pair를 보여 주어 특정 output 행동을 조정합니다. “회사 자료를 학습시키자”는 요구를 그대로 받아들이지 말고 최신 규정 검색·출처 인용은 Retrieval-Augmented Generation(RAG, 검색 증강 생성), strict JSON 검증은 schema·code, 반복되는 분류 경계·tone·거절은 SFT 후보로 나눕니다. 해결 수단을 먼저 정하면 바뀌는 사실을 adapter에 오래된 채로 굳히거나 deterministic 문제를 확률 model로 어렵게 만들 수 있습니다.
목표는 “좋은 답”이 아니라 관찰 가능한 업무 결과로 씁니다. 문의 category·urgency·reason 필수, 정보 부족 시 hold, 권한 없는 환불 확정 금지처럼 parser와 reviewer가 판단할 condition을 정합니다. 정상·경계·conflict·unsafe input이 있는 frozen set에서 exact base, system prompt·few-shot, RAG·rule 후보를 실행해 업무 성공·critical recall·형식·과잉 거절과 사람 correction을 측정합니다. Adapter candidate가 개선해야 할 최소 차이와 절대 악화되면 안 되는 gate를 결과를 보기 전에 승인합니다.
SFT는 base가 전혀 갖지 않은 일반 능력이나 검증되지 않은 label을 자동으로 만들어 주지 않습니다. Dataset row가 모호하면 model은 모호함을 학습하고, source 권리가 없거나 개인정보가 남으면 작은 adapter라고 책임이 줄지 않습니다. Dataset release의 rights·privacy·schema·template·label review, group leakage와 frozen test를 통과한 immutable version만 training input으로 받습니다. Training 결과를 보고 test row를 고치면 별도 data version과 untouched test를 새로 만들어야 합니다.
완료 조건에는 학습을 하지 않는 결론도 포함합니다. Prompt baseline이 이미 critical gate를 통과하거나 최신 source가 자주 바뀌어 RAG 유지비가 더 낮다면 adapter 계획을 hold합니다. Fine-tuning은 training code뿐 아니라 평가·registry·serving·rollback 책임을 추가합니다. 예상 개선, GPU 시간, reviewer correction 절감과 incident 비용을 함께 보고 owner가 이 변경을 운영할 수 있을 때만 pilot로 이동합니다.
왜 이런가
방법 선택이 틀리면 많은 data와 GPU를 써도 최신성·근거·형식 문제를 해결하지 못하고 새 운영 부채만 만들기 때문입니다.
언제 문제가 되는가
“자료를 넣었다”는 성공 기준으로 시작하면 base 대비 개선·critical 회귀와 언제 adapter를 폐기할지 판단할 수 없습니다.
초보자가 자주 하는 오해
Fine-tuning은 model에 문서를 안전하게 저장하는 database도 아니고 모든 prompt engineering·RAG를 대체하는 단계도 아닙니다.
직접 확인하는 방법
같은 frozen 업무 set에서 base·prompt/RAG와 계획 adapter의 목표를 표로 비교하고 adapter만 해결할 failure와 독립 필수 gate를 말해 보십시오.
개념 해설 02
Exact base·tokenizer·license와 serving 경로를 하나의 계약으로 고정한다
Base 후보는 parameter 크기만으로 고르지 않습니다. Target language·업무의 frozen baseline, instruct 또는 base variant, context와 chat template, architecture·license·acceptable use, source model의 공개 조건과 intended runtime을 함께 봅니다. PEFT가 target module을 주입할 수 있어도 production runtime이 adapter를 동적으로 load하지 못할 수 있고, merge 후 재배포 조건이 달라질 수 있습니다. 최종 실행 방식까지 되짚어 지원되지 않는 training 결과를 만들지 않습니다.
Manifest에는 repository ID, immutable commit·weight hash, config와 tokenizer file hash, chat_template, generation defaults와 code trust setting을 기록합니다. “최신 main”이나 mutable tag는 이후 다른 weight를 가리킬 수 있습니다. Local cache도 manifest hash와 대조하고 다운로드 source·license snapshot을 보존합니다. Base model card의 제한과 평가 범위를 읽되 card 문구가 내 업무의 품질·권리 승인이라고 확대하지 않습니다.
Tokenizer와 template는 adapter behavior의 일부입니다. 같은 architecture라도 instruct family마다 user·assistant control token이 다를 수 있습니다. Training row를 exact template로 render하고 serving runtime이 만드는 token ID를 golden fixture와 비교합니다. BOS/EOS 중복, system role 미지원, special token 추가와 pad token 선택을 기록합니다. Tokenizer vocabulary를 바꾸면 embedding/lm_head를 어떻게 학습·저장할지 명시하고 변경하지 않았다면 그 사실도 manifest에 둡니다.
작은 compatibility smoke test는 base load, template render, one forward, LoRA injection·backward, adapter save·reload와 production-like generation까지 이어집니다. 이 단계에서 architecture layer 이름, quant kernel·dtype, driver와 runtime adapter 지원을 확인합니다. 공식 minimal example 성공은 출발점이며 실제 max length·batch와 배포 endpoint까지 같은 stack에서 통과해야 training plan을 승인합니다.
왜 이런가
Adapter file은 base parameter 자체를 담지 않고 특정 layer·token sequence에 대한 변화만 담으므로 base와 입력 계약이 바뀌면 의미가 달라지기 때문입니다.
언제 문제가 되는가
Model 이름만 남기면 mutable revision·template 변화로 training은 재현되지 않고 production에서 잘못된 control token을 받을 수 있습니다.
초보자가 자주 하는 오해
같은 7B architecture나 같은 tokenizer class라는 사실은 weight revision·chat template·license와 adapter target 호환성을 보증하지 않습니다.
직접 확인하는 방법
Base weight·config·tokenizer/template hash와 license, target runtime에서 adapter load 또는 merge 경로를 manifest와 golden token fixture로 확인하십시오.
개념 해설 03
LoRA의 low-rank update와 frozen base를 실제 parameter에서 검증한다
LoRA 원 논문은 pretrained model weight를 frozen하고 Transformer layer에 trainable rank decomposition matrix를 주입합니다. 기존 matrix W를 직접 바꾸는 대신 output에 low-rank update ΔW를 더하며, 두 작은 matrix가 이 변화를 표현합니다. Full fine-tuning보다 trainable parameter·gradient·optimizer state와 저장량을 줄이는 핵심은 여기에 있습니다. 논문의 특정 GPT-3 실험에서 보고한 절감 배수를 다른 model·optimizer·hardware에 그대로 붙이지 않고 내 run의 trainable count와 peak로 설명합니다.
Rank r은 update matrix의 내부 차원입니다. 높은 rank는 더 많은 trainable parameter와 표현 capacity를 제공하지만 업무 품질이 항상 좋아지거나 overfitting이 사라지는 것은 아닙니다. Alpha는 update scaling에 관여하고 dropout·bias·initialization도 결과를 바꿉니다. Candidate 비교는 동일 dataset·token budget과 가능한 한 같은 seed family에서 rank만 바꾸고 task·critical·general regression과 memory·step time을 함께 봅니다.
Adapter injection 뒤에는 trainable parameter report를 저장합니다. 전체·trainable count와 비율, layer별 target name·shape·rank, modules_to_save를 출력하고 model.named_parameters에서 requires_grad를 검사합니다. 첫 backward 뒤 base parameter gradient가 비어 있는지, optimizer parameter group에 adapter만 들어갔는지도 확인합니다. 잘못된 wildcard로 의도 밖 head나 embedding이 학습되거나 target이 0개인 run을 loss log만 보고 놓치지 않습니다.
Default initialization이 no-op에 가깝게 설계된 경우 adapter 적용 직후 output을 base와 비교하는 smoke test가 유용합니다. New special token·modules_to_save 또는 bias training이 있다면 예상 차이를 별도로 설명합니다. Save 후 fresh process에서 adapter를 reload해 같은 golden input의 logits·generation과 trainable/inference mode를 확인합니다. In-memory object가 동작한 사실만으로 checkpoint가 완성됐다고 판단하지 않습니다.
왜 이런가
LoRA의 장점은 실제 변경 parameter 범위에서 나오며 잘못된 target·optimizer group은 학습 비용과 결과를 근본적으로 바꾸기 때문입니다.
언제 문제가 되는가
Config file만 믿으면 target 0개, 일부 layer 누락 또는 base까지 trainable인 run을 끝까지 실행하고 작은 adapter라는 설명도 검증하지 못합니다.
초보자가 자주 하는 오해
LoRA를 썼다는 사실만으로 full fine-tuning과 동일한 품질, 고정된 memory 절감 또는 base 능력 보존이 자동 보장되지 않습니다.
직접 확인하는 방법
Injection 전후 trainable count·layer 목록, 첫 backward의 gradient와 optimizer group, save·fresh reload 결과를 같은 manifest에 남기십시오.
개념 해설 04
Target module·rank·alpha를 architecture와 업무 비교 실험으로 정한다
PEFT 공식 LoRA 문서는 기본 설정에서 attention의 query·value layer를 대상으로 하는 예를 제공하고 QLoRA-style에는 all-linear를 사용할 수 있다고 설명합니다. 하지만 q_proj·v_proj·query_key_value처럼 이름과 tensor grouping은 architecture마다 다릅니다. model.named_modules, official architecture code와 PEFT mapping을 확인하고 실제 matched layer 수를 기록합니다. Mixture-of-Experts model은 shared·expert FFN과 router가 별도이므로 dense recipe를 그대로 복사하지 않습니다.
좁은 attention target은 parameter와 memory가 작지만 업무 변화가 부족할 수 있고 all-linear는 더 많은 FFN update를 학습해 capacity와 비용이 커질 수 있습니다. 비교 matrix에는 target set, rank·alpha, trainable count, peak memory·tokens/s와 frozen 업무·critical·일반 회귀를 둡니다. Target과 rank, data version·learning rate를 한 run에서 모두 바꾸면 어느 변화가 결과를 만들었는지 알 수 없으므로 실험 축을 분리합니다.
Modules_to_save는 adapter layer 외에 학습·저장할 module을 지정하는 중요한 계약입니다. Classification head, 새 token embedding 또는 lm_head를 바꾼다면 왜 필요한지와 base와 분리 저장되는 방식을 확인합니다. Bias option도 base-equivalence와 merge behavior를 바꿀 수 있습니다. PEFT config에는 rank·alpha·dropout·target·bias·task type과 base reference를 남기고 실제 checkpoint parameter key가 config와 맞는지 검사합니다.
선택 기준은 가장 큰 설정이 아니라 모든 필수 gate를 통과하는 가장 단순한 candidate입니다. Rank 8 attention-only가 업무 93%·critical 97%·회귀 허용 범위이고 rank 32 all-linear가 업무 94%지만 general regression과 memory 상한을 실패한다면 전자를 선택할 수 있습니다. 점수 차이에 반복 변동이 겹치면 더 복잡한 설정을 이겼다고 말하지 않고 추가 seed·failure review를 수행합니다.
왜 이런가
Target과 rank는 trainable 범위·memory·표현력과 checkpoint 구조를 동시에 바꾸므로 architecture 확인과 통제된 비교가 필요하기 때문입니다.
언제 문제가 되는가
Community config를 복사하면 layer 일부가 누락되거나 의도하지 않은 module이 학습되고 높은 rank 비용을 실제 업무 개선으로 오판할 수 있습니다.
초보자가 자주 하는 오해
All-linear나 높은 rank가 항상 더 완전한 LoRA라는 뜻은 아니며 작은 업무와 data에는 더 큰 회귀·overfitting을 만들 수 있습니다.
직접 확인하는 방법
Matched module·trainable parameter report와 한 축씩 바꾼 candidate의 업무·critical·회귀·memory 결과를 나란히 비교하십시오.
개념 해설 05
QLoRA의 4-bit base와 실제 compute·activation memory를 분리한다
QLoRA 원 논문은 frozen 4-bit quantized pretrained model을 통과해 gradient를 LoRA adapter로 전달하고 NF4, double quantization과 paged optimizer로 memory를 다룹니다. 이는 base weight memory를 크게 낮추는 접근이지만 모든 model과 GPU가 특정 크기에서 된다는 표가 아닙니다. 논문의 65B·48GB 결과는 해당 연구의 model·sequence·batch·kernel과 평가 범위의 결과로 인용하고 내 장비에는 exact workload 측정을 요구합니다.
Transformers bitsandbytes 문서는 8·4-bit training이 extra parameter 학습에 지원된다고 설명하고, 4-bit base training에 NF4와 별도 bnb_4bit_compute_dtype 설정을 제공합니다. Manifest에는 quant type, nested/double quant, storage·compute dtype, adapter dtype과 library·CUDA·driver·hardware capability를 적습니다. BF16 support가 부족하거나 operator가 fallback되면 속도·안정성이 달라질 수 있으므로 device placement와 actual kernel execution을 확인합니다.
Memory ledger에는 quantized base weight와 quant metadata, dequantization buffer, adapter parameter·gradient·optimizer, activation, attention workspace와 allocator reserve가 들어갑니다. Activation은 sequence length·micro-batch·hidden·layer에 민감하고 gradient checkpointing은 compute를 더 써 memory를 줄입니다. Packing은 padding 낭비를 줄일 수 있지만 한 packed sequence의 길이와 mask를 확인해야 합니다. Load, first forward, backward, optimizer step, evaluation과 save peak를 분리해 기록합니다.
OOM 복구에서는 목표를 몰래 바꾸지 않습니다. Micro-batch를 낮추고 accumulation으로 effective batch를 유지할지, max length를 줄이면 긴 업무 coverage가 사라지는지, checkpointing·optimizer 변경이 step time과 convergence를 바꾸는지 한 항목씩 봅니다. Warm-up 뒤 peak·tokens/s, host memory·offload I/O와 30분 이상 지속 run을 측정합니다. 목표 dataset 완료, evaluation·save와 interrupted checkpoint resume까지 성공해야 hardware fit를 통과합니다.
왜 이런가
QLoRA는 weight memory만 바꾸고 training의 다른 큰 memory 항목과 hardware·kernel 조건은 남기 때문에 단순 model B·VRAM 표가 자주 실패하기 때문입니다.
언제 문제가 되는가
4-bit라는 이름만 보고 max length·batch를 정하면 backward·evaluation·save에서 OOM이 나고 offload stall로 job 시간이 목표를 벗어날 수 있습니다.
초보자가 자주 하는 오해
QLoRA는 LoRA adapter와 모든 연산을 4-bit로 학습하거나 어떤 16GB GPU에서도 특정 7B model을 보장하는 방법이 아닙니다.
Chat template·loss mask·truncation을 actual token에서 검사한다
Hugging Face chat template 문서는 role·content list가 model마다 다른 control token sequence로 변환되며 잘못된 token이 성능을 크게 떨어뜨릴 수 있다고 설명합니다. Exact tokenizer revision으로 system·user·assistant conversation을 render해 text와 token ID를 보존합니다. BOS/EOS·end-of-message가 중복되는지, system role과 multi-turn이 지원되는지, serving runtime이 같은 sequence를 만드는지 golden fixture로 비교합니다.
TRL SFTTrainer의 assistant_only_loss는 conversational dataset에서 assistant response에만 loss를 계산하도록 할 수 있지만 template가 generation 구간을 지원해야 하는 조건이 있습니다. Prompt-completion dataset의 completion-only default도 actual version·config로 확인합니다. Sample token별 label이 -100인지 target인지 표시해 user 지시·system policy를 model output으로 학습하지 않는지 검토합니다. Config 이름만 켰다고 mask가 원하는 span이라고 가정하지 않습니다.
Length는 raw character가 아니라 rendered token으로 측정합니다. Truncation이 긴 user context만 자르는지, 정답의 마지막 JSON brace·거절 조건을 자르는지와 truncation side를 row별 report로 남깁니다. Target token이 하나라도 critical output에서 잘리면 해당 row를 hold하고 chunk·max length·data를 고칩니다. Packing을 켜면 example boundary, position·attention behavior와 loss mask가 섞이지 않는지 작은 known batch의 token map으로 확인합니다.
Dataset version에는 raw JSONL hash뿐 아니라 conversion code, tokenizer/template hash, max length·packing과 loss configuration을 포함합니다. 같은 row도 이 값이 바뀌면 다른 training input입니다. Training과 inference template을 동시에 바꾸지 않고, template candidate는 base와 previous adapter를 모두 같은 frozen set에서 재평가합니다. Template mismatch는 adapter 품질 문제가 아니면서도 겉으로 같은 model이 이상하게 답하는 대표적인 배포 장애입니다.
왜 이런가
Causal LM은 role object가 아니라 control token sequence와 label mask를 학습하므로 이 변환이 틀리면 올바른 row도 다른 행동을 가르치기 때문입니다.
언제 문제가 되는가
Raw JSON과 train loss만 보면 user prompt 학습, target truncation·special token 중복과 serving template mismatch를 발견하지 못합니다.
초보자가 자주 하는 오해
Messages에 user와 assistant role이 있다는 사실만으로 assistant-only loss와 model별 올바른 token serialization이 보장되지 않습니다.
Learning schedule·effective batch와 clean run을 관측 가능한 실험으로 만든다
Effective batch는 한 GPU의 micro-batch만이 아니라 micro-batch × gradient accumulation × data-parallel worker입니다. Epoch만 기록하면 packing·drop_last·world size 변화로 실제 optimizer step과 본 token 수가 달라질 수 있습니다. Dataset rows·rendered tokens, micro/effective batch, accumulation, max_steps·epoch, warmup, scheduler·learning rate와 seed를 run manifest에 둡니다. 비교 후보는 같은 token budget과 evaluation interval을 유지합니다.
Pilot은 사람이 모든 sample과 output을 볼 수 있는 small dataset으로 forward·backward·optimizer, evaluation, save·fresh reload까지 확인합니다. Full run에서는 training·validation loss, 업무 metric, critical gate, gradient norm·NaN/Inf, learning rate, tokens/s, peak allocated/reserved memory, skipped·truncated row와 checkpoint hash를 같은 global step에 기록합니다. Loss가 내려가도 gradient explosion·throughput collapse나 critical metric 악화가 있으면 중단합니다.
한 번에 target module, rank, learning rate, data version과 max length를 모두 바꾸면 개선 원인을 알 수 없습니다. Baseline config에서 가장 큰 failure 원인 하나를 가설로 정하고 한 축을 변경합니다. Seed 하나의 우연을 피하려면 final 후보는 여러 clean run에서 metric 분포·failure overlap을 봅니다. Framework·kernel은 완전한 bitwise determinism을 보장하지 않을 수 있으므로 허용 범위를 사전 정의하고 reproducibility warning을 숨기지 않습니다.
Checkpoint는 장애 복구까지 시험합니다. Mid-run checkpoint에서 optimizer·scheduler·random state와 sample position을 복원해 이어서 학습하고 uninterrupted reference와 허용 범위를 비교합니다. Disk full, corrupt checkpoint, OOM과 evaluation failure에서 partial artifact를 release로 오인하지 않게 status와 atomic publish를 둡니다. Clean environment에서 dependency lock과 code·config·data hash로 run을 재생할 수 있어야 실험이 개인 notebook을 넘어 승인 가능한 증거가 됩니다.
왜 이런가
Batch·step·schedule과 data order가 optimization을 함께 결정하므로 숫자 몇 개만 남기면 candidate 비교와 장애 resume가 재현되지 않기 때문입니다.
언제 문제가 되는가
마지막 loss screenshot만 남기면 어느 data·token budget·learning rate에서 만든 checkpoint인지와 OOM 뒤 동일 run을 이어갔는지 알 수 없습니다.
초보자가 자주 하는 오해
Seed 하나를 고정하거나 같은 config file을 썼다는 사실만으로 hardware·kernel 차이를 포함한 bitwise 재현과 같은 품질이 자동 보장되지 않습니다.
직접 확인하는 방법
Run manifest와 step별 loss·업무 metric·gradient·memory·throughput, clean 반복과 interrupted resume 결과를 checkpoint hash에 연결하십시오.
개념 해설 08
Checkpoint를 train loss가 아니라 base 대비 업무·critical·일반 회귀로 선택한다
Training loss는 본 row의 next-token target을 맞힌 정도이고 validation loss도 held-out token prediction의 proxy입니다. Production 승격에는 업무 성공·schema, critical class recall·unsafe compliance·근거 없는 답·과잉 거절과 사람 correction을 둡니다. Base, prompt/RAG baseline, previous approved adapter와 각 checkpoint를 같은 frozen set·decoding·runtime에서 실행합니다. Dataset·test에 있는 문구를 그대로 재현하는지 contamination·memorization probe도 포함합니다.
Critical gate는 평균으로 상쇄하지 않습니다. 전체 업무 성공이 2%p 올라도 권한 없는 action refusal이 98%에서 91%로 떨어지면 보류할 수 있습니다. General regression set에는 language·instruction following, 긴 input·code·reasoning 등 base에서 유지하기로 한 대표 능력을 둡니다. Output pair를 blind 사람 reviewer가 rubric으로 비교하고 자동 judge를 사용하면 version·prompt·bias와 사람 disagreement를 별도 evidence로 남깁니다.
Transformers Trainer는 eval strategy와 metric_for_best_model을 사용해 best checkpoint를 load할 수 있지만 어떤 metric을 고르는지는 업무 책임입니다. Best metric 하나와 별도로 must-pass gate를 적용하고 save/eval interval이 같은 checkpoint를 비교하는지 확인합니다. Early stopping은 validation noise·평가 빈도와 patience에 영향을 받으므로 마지막 checkpoint보다 앞선 candidate를 보존하고 failure taxonomy를 step별로 봅니다.
선택 결과에는 confidence와 limitation을 남깁니다. 여러 clean run의 평균·범위와 critical failure 수, base 대비 improvement/regression, memory·latency와 reviewer correction을 한 release table에 둡니다. 결과를 본 뒤 allowed drop을 넓히지 않습니다. Candidate가 실패하면 data·target·schedule 원인으로 돌아가 새 run ID를 만들고 같은 test를 반복 최적화하지 않도록 development validation과 final frozen test를 분리합니다.
왜 이런가
Token loss는 실제 업무·안전·원래 능력의 여러 오류 비용을 한 값에 숨기므로 production 선택에는 독립 gate가 필요하기 때문입니다.
언제 문제가 되는가
마지막 또는 최저 loss checkpoint를 자동 채택하면 앞 단계에서 더 좋았던 업무 metric과 뒤늦게 생긴 refusal·일반 능력 회귀를 놓칩니다.
초보자가 자주 하는 오해
Validation loss가 내려가거나 자동 judge가 선호한다는 사실은 factuality·안전·사람 업무 성공과 data leakage 없음을 보증하지 않습니다.
직접 확인하는 방법
Base·previous·모든 후보를 같은 frozen set에서 blind 비교하고 사전 업무·critical·regression·운영 gate를 모두 적용하십시오.
PEFT checkpoint 문서는 adapter_model.safetensors와 adapter_config.json을 중심으로 설명하며 adapter state에는 base model parameter가 포함되지 않습니다. Config에는 base reference·revision, rank·alpha·target와 기타 설정이 들어갈 수 있지만 모든 provenance를 자동 저장한다고 가정하지 않습니다. Registry에는 exact base·tokenizer/template hash, adapter file hash, PEFT·Transformers·TRL·bitsandbytes와 driver, LoRA/quant/training config, dataset·code commit과 evaluation report를 묶습니다.
Fresh environment에서 bundle을 load해 trainable adapter가 inference mode로 올바르게 붙는지, golden input과 frozen set이 재현되는지 확인합니다. Dynamic adapter load와 merge 배포는 별도 artifact입니다. Merge 전후 logits·업무·critical·latency와 precision을 다시 비교하고 base·adapter license와 redistribution 조건을 재검토합니다. Model card에는 intended·out-of-scope use, data 범위·metric, limitation·known failure와 owner를 기록합니다.
Offline gate 통과 뒤에는 shadow 또는 제한 canary에서 production-like template·generation config로 schema failure, critical incident, 사람 correction·override, p95·memory와 adapter load error를 관측합니다. Canary 기준과 자동 중단, 승인 owner를 사전에 정합니다. 사용자 traffic으로 test count를 채우거나 monitoring이 없는 상태에서 전면 교체하지 않습니다. 새로운 base·data·policy·runtime version은 모두 재검토 trigger입니다.
Rollback은 adapter file을 삭제하는 한 단계가 아닙니다. Previous compatible base revision, tokenizer/template, runtime·quant와 generation config, previous approved adapter를 다시 load하고 cache·worker가 실제로 교체됐는지 확인합니다. Candidate에서 실패한 exact input이 회복되고 정상 regression set도 유지되는지, 목표 복구 시간 안에 반복 시험합니다. Incident에서 어느 run·data source가 영향을 주었는지 lineage로 찾고 hold·retrain·폐기 결정을 evidence에 남겨 release를 닫습니다.
왜 이런가
Adapter는 여러 외부 artifact와 runtime에 종속되고 production 문제는 이 결합에서 생기므로 배포·복구 가능한 bundle로 관리해야 하기 때문입니다.
언제 문제가 되는가
adapter_model.safetensors만 보관하면 base·template가 바뀐 뒤 load는 되어도 행동이 달라지고 previous 상태로 정확히 돌아갈 수 없습니다.
초보자가 자주 하는 오해
작은 adapter이거나 safetensors 형식이라는 사실은 provenance·license·품질·안전과 merge 결과의 동일성을 자동 보장하지 않습니다.
직접 확인하는 방법
Fresh load·merge 전후 평가, canary 기준과 previous full stack rollback에서 같은 failure 회복·정상 회귀·복구 시간을 확인하십시오.
CONCRETE CASES
서로 다른 상황에서 개념을 확인하기
정의를 외우기 전에 개인 PC와 실제 업무에서 어떤 모습으로 나타나는지 비교해 보십시오.
사례 1 · 학습 전에 미세조정할 행동과 base baseline 증명하기
고객 문의를 category·urgency·reason JSON으로 내는 업무에서 base 형식 준수 71%, critical refund recall 82%를 기록하고, 최신 환불 규정은 RAG로 유지한 채 판단 경계·hold 행동만 SFT 후보로 둡니다.
이 사례에서 확인할 핵심: Base와 prompt/RAG 후보를 같은 frozen 업무 set에서 비교합니다.
NF4 base, BF16 compute, all-linear LoRA rank 16 후보에서 batch 1·length 1024와 2048을 각각 warm-up 후 측정해 14.2GiB/20.8GiB peak와 tokens/s를 기록하고 OOM이면 length를 한 항목만 줄입니다.
이 사례에서 확인할 핵심: NF4·double quant·compute dtype과 adapter dtype을 각각 기록합니다.
사례 4 · Template·loss mask·batch와 clean run을 관측 가능한 training 계약으로 만들기
Conversational row 20개를 render해 assistant_only_loss mask가 assistant span만 포함하고 target truncation이 0임을 확인한 뒤 200-row smoke run을 두 번 clean 실행해 동일 설정·step별 metric과 checkpoint load를 비교합니다.
이 사례에서 확인할 핵심: Training과 serving의 tokenizer·template·special token을 golden fixture로 비교합니다.
사례 5 · Best checkpoint를 base·previous 대비 업무·안전 회귀와 rollback으로 승인하기
Step 400이 validation loss는 가장 낮지만 critical refusal 91%로 95% gate를 실패하면, loss가 약간 높아도 업무 94%·refusal 97%·general regression 허용 범위인 step 300을 candidate로 두고 canary와 previous adapter rollback을 시험합니다.
이 사례에서 확인할 핵심: Checkpoint 선택 metric과 독립 필수 gate를 결과 전에 고정합니다.
CHAPTER 1 / 5
학습 전에 미세조정할 행동과 base baseline 증명하기
Pretraining은 광범위한 corpus에서 model의 많은 parameter를 학습하는 대규모 과정이고 Supervised Fine-Tuning(SFT, 정답 예시 기반 미세조정)은 이미 능력을 가진 model에 input·target 예시를 보여 특정 행동을 조정합니다. “사내 지식을 넣는다”는 요구를 그대로 학습으로 번역하지 않습니다. 가격·정책처럼 자주 바뀌고 출처가 필요한 사실은 RAG, deterministic validation이 가능한 형식은 code·schema, 반복되는 응답 구조·판단 경계와 거절은 SFT 후보로 나눕니다.
먼저 production-like 정상·경계·불충분·unsafe input을 frozen evaluation set으로 만들고 exact base model을 실행합니다. 업무 성공, critical class, schema 준수, 근거 없는 답, 과잉 거절과 latency를 남깁니다. System prompt, few-shot, RAG와 rule을 적용한 더 단순한 baseline도 같은 set에서 비교합니다. Adapter가 이 비용과 운영 복잡성을 이길 관찰 가능한 목표가 없으면 학습을 보류하는 것이 완성된 결정입니다.
Base 선택에는 parameter 숫자 외에 language·task baseline, context, architecture, instruct 여부, tokenizer·chat template, license·acceptable use, redistributability와 target runtime을 포함합니다. Model ID만 기록하지 말고 immutable revision·weight hash를 고정합니다. Training library가 해당 architecture의 target module을 어떻게 부르는지와 quantized load·adapter save·serving이 실제 hardware에서 지원되는지 작은 official example로 확인합니다.
Dataset release와 model release는 연결되지만 같은 gate가 아닙니다. Rights·PII·label·group split을 통과한 immutable dataset, exact conversion·template와 frozen test를 입력으로 받습니다. Training을 시작한 뒤 test 결과를 보고 row나 threshold를 고치면 test는 더 이상 blind가 아닙니다. 새 data version과 개발용 validation을 만들고 untouched test는 최종 candidate 비교에만 사용합니다.
그림 읽는 법 미세조정은 GPU가 아니라 학습이 아니어도 되는가에서 시작합니다. base baseline을 증명하고 data·template·adapter 설정, checkpoint 비교와 복구 증거를 차례로 통과시킵니다.
핵심을 다시 정리하면
Base와 prompt/RAG 후보를 같은 frozen 업무 set에서 비교합니다.
Base license·revision·tokenizer·chat template와 배포 runtime 지원을 시작 전에 고정합니다.
현실에서 이렇게 연결됩니다
고객 문의를 category·urgency·reason JSON으로 내는 업무에서 base 형식 준수 71%, critical refund recall 82%를 기록하고, 최신 환불 규정은 RAG로 유지한 채 판단 경계·hold 행동만 SFT 후보로 둡니다.
CHAPTER 2 / 5
LoRA update와 target module·rank를 실제 trainable parameter로 확인하기
LoRA 원 논문은 pretrained weight를 frozen 상태로 두고 layer에 trainable rank decomposition matrix를 주입하는 방식을 제안합니다. 큰 weight W 전체를 갱신하는 대신 변화량 ΔW를 작은 두 행렬의 곱으로 표현합니다. 그래서 gradient·optimizer state가 필요한 trainable parameter와 adapter 저장량을 줄일 수 있습니다. 논문의 특정 GPT-3 조건에서 나온 절감 배수를 모든 architecture·optimizer·hardware에 그대로 적용하지 않고 실제 report와 peak memory로 검증합니다.
Rank r은 update가 표현할 수 있는 차원의 한 축이며 커질수록 trainable parameter와 capacity가 늘지만 업무 품질이 단조롭게 좋아진다는 뜻은 아닙니다. Alpha는 update scaling에 관여하고 dropout·bias·initialization도 결과를 바꿉니다. 낮은 rank가 underfit인지 높은 rank가 noise를 외우는지는 같은 data·seed family·step budget에서 업무 validation과 회귀를 비교해 판단합니다. 한 번에 rank와 target·learning rate를 모두 바꾸지 않습니다.
Target module은 실제 architecture의 linear layer 이름과 맞아야 합니다. PEFT 공식 LoRA 문서는 기본 예에서 attention query·value를 대상으로 하며 QLoRA-style은 all-linear를 지정하는 방식을 설명합니다. q_proj라는 이름을 모든 model에 복사하면 일부 layer가 빠지거나 오류가 날 수 있습니다. Adapter injection 뒤 target별 개수·shape, trainable/total parameter 비율과 requires_grad 목록을 저장하고 의도한 embedding·lm_head가 별도 modules_to_save 대상인지 확인합니다.
Frozen base라는 말도 runtime 상태에서 검증합니다. Optimizer가 adapter parameter만 받는지, gradient가 base에 생기지 않는지 첫 backward 뒤 검사합니다. 새로운 special token을 추가하면 embedding resize와 해당 row 저장이 필요할 수 있고 base tokenizer를 그대로 둔다면 변경 없음도 기록합니다. Adapter load 직후 초기 output이 base와 예상대로 같거나 가까운지 smoke test해 잘못된 initialization·module mapping을 조기에 발견합니다.
핵심을 다시 정리하면
Rank·alpha·dropout·bias·modules_to_save와 target module 목록을 config와 log에 남깁니다.
Architecture 이름을 추측하지 말고 injected layer와 trainable parameter report를 검사합니다.
현실에서 이렇게 연결됩니다
Attention의 q_proj·v_proj만 rank 8로 붙인 후보와 all-linear rank 16 후보를 동일 dataset·steps에서 비교하고, model.named_parameters와 PEFT trainable report로 의도 밖 parameter가 frozen인지 확인합니다.
QLoRA 원 논문은 frozen 4-bit quantized pretrained model을 통과해 LoRA adapter로 gradient를 backpropagate하는 접근을 설명하고 NF4, double quantization과 paged optimizer를 제시합니다. 여기서 4-bit는 base weight의 memory 표현이며 모든 학습 계산과 adapter가 4-bit라는 뜻이 아닙니다. 논문의 65B·48GB 결과는 특정 model·kernel·sequence·batch와 연구 설정의 결과이므로 소비자 GPU 전체의 보증 문구로 바꾸지 않습니다.
Transformers bitsandbytes 공식 문서는 8·4-bit training이 extra parameter 학습에 지원된다고 명시하고 QLoRA용 NF4와 별도 compute dtype 설정을 보여 줍니다. Manifest에는 load_in_4bit, quant_type, double quant, storage·compute dtype, device map과 library·driver version을 기록합니다. Hardware가 BF16을 잘 지원하지 않거나 kernel·operator 조합이 다르면 속도·안정성이 달라질 수 있어 capability와 actual execution을 profiler·log에서 확인합니다.
Weight memory를 줄여도 activation은 sequence length, micro-batch, hidden·layer와 checkpointing에 영향을 받고 adapter gradient·optimizer, dequantization buffer와 allocator fragmentation도 남습니다. “7B는 16GB에서 된다” 같은 표보다 exact model·revision·sequence distribution, packing, micro-batch·gradient accumulation, gradient checkpointing과 optimizer를 manifest로 만들고 load·첫 backward·optimizer step·save의 peak를 각각 측정합니다.
Out Of Memory(OOM, 메모리 부족)가 나면 여러 설정을 동시에 낮추지 않습니다. 우선 micro-batch·max sequence·packing의 긴 sample, checkpointing과 optimizer를 한 항목씩 바꾸고 effective batch가 달라지면 learning schedule도 다시 비교합니다. CPU offload나 paged 방법은 장애를 숨기는 마법이 아니며 step time·host memory·I/O stall을 추가 측정합니다. 통과는 한 step 성공이 아니라 목표 dataset을 반복 완료하고 checkpoint를 resume할 수 있는 상태입니다.
핵심을 다시 정리하면
NF4·double quant·compute dtype과 adapter dtype을 각각 기록합니다.
Sequence·micro-batch·accumulation·checkpointing별 actual peak와 step time을 warm-up 뒤 측정합니다.
현실에서 이렇게 연결됩니다
NF4 base, BF16 compute, all-linear LoRA rank 16 후보에서 batch 1·length 1024와 2048을 각각 warm-up 후 측정해 14.2GiB/20.8GiB peak와 tokens/s를 기록하고 OOM이면 length를 한 항목만 줄입니다.
CHAPTER 4 / 5
Template·loss mask·batch와 clean run을 관측 가능한 training 계약으로 만들기
Messages object는 그대로 causal model에 들어가지 않습니다. Chat template는 role·content를 model별 control token으로 바꾸며 Hugging Face 공식 문서는 잘못된 control token이 성능을 크게 해칠 수 있다고 설명합니다. Exact tokenizer revision의 apply_chat_template output과 token ID, BOS/EOS 중복·assistant 시작/종료를 golden row로 저장합니다. Training과 serving이 다른 template를 쓰면 loss가 내려가도 배포 입력에서는 행동이 재현되지 않습니다.
Loss 범위는 명시해야 합니다. TRL SFTTrainer는 conversational dataset의 assistant_only_loss와 prompt-completion의 completion-only 설정을 제공하지만 assistant mask는 template의 generation 구간 지원 같은 조건이 있습니다. User·system token까지 학습되는지, packing으로 example 경계가 섞이지 않는지와 label -100 mask를 sample별로 시각화합니다. Rendered max token에서 정답·거절 문장이 잘린 row는 training 전에 hold합니다.
Effective batch는 micro-batch × gradient accumulation × data-parallel workers로 계산하고 actual optimizer step 수, warmup·scheduler, learning rate, epoch·max_steps와 seed를 기록합니다. Packing은 짧은 example의 계산 효율을 높일 수 있지만 경계·attention·loss mask를 actual trainer version에서 확인합니다. 비교 실험은 같은 dataset version·sample order·token budget을 유지하고 한 번에 target·rank·learning rate처럼 한 축만 바꿉니다.
Smoke run은 parse 성공이 아니라 forward·backward·optimizer step, evaluation, adapter save·load와 resume까지 확인합니다. NaN/Inf loss, gradient norm, learning rate, tokens/s, peak allocated·reserved memory와 skipped sample을 step별로 기록합니다. Clean environment에서 같은 manifest를 최소 여러 번 실행해 nondeterminism 범위를 남깁니다. PyTorch와 kernel이 완전한 bitwise 재현을 보장하지 않을 수 있으므로 동일 hash가 아니라 사전 metric 허용 범위와 artifact lineage로 판단합니다.
핵심을 다시 정리하면
Training과 serving의 tokenizer·template·special token을 golden fixture로 비교합니다.
Train loss, validation 업무 metric, gradient·memory·throughput과 checkpoint hash를 같은 step에 기록합니다.
현실에서 이렇게 연결됩니다
Conversational row 20개를 render해 assistant_only_loss mask가 assistant span만 포함하고 target truncation이 0임을 확인한 뒤 200-row smoke run을 두 번 clean 실행해 동일 설정·step별 metric과 checkpoint load를 비교합니다.
CHAPTER 5 / 5
Best checkpoint를 base·previous 대비 업무·안전 회귀와 rollback으로 승인하기
Train loss는 본 row를 맞힌 정도이고 validation loss는 held-out token prediction의 proxy입니다. 실제 승격에는 schema·task accuracy, critical class recall, hallucination·unsafe compliance, 지나친 거절과 일반 능력 회귀를 둡니다. Base·prompt baseline, previous approved adapter와 candidate checkpoint를 같은 frozen set·decoding·runtime에서 blind 비교합니다. 평균이 좋아도 필수 안전·권한·숫자 gate 하나가 실패하면 보류합니다.
Transformers Trainer는 evaluation strategy와 metric_for_best_model을 이용한 best checkpoint loading을 지원하지만 기본 metric 선택이 곧 업무 승인 기준은 아닙니다. Save/eval interval이 맞는지, best와 latest가 모두 보존되는지와 interrupted run resume가 같은 sample position·scheduler·optimizer state로 이어지는지 시험합니다. Overfitting은 validation divergence뿐 아니라 train 문구 암기, rare class 악화와 base의 범용 instruction 능력 저하로도 찾습니다.
PEFT checkpoint는 adapter weight와 adapter_config를 중심으로 저장하며 base weight 자체는 포함하지 않습니다. 따라서 base model immutable revision·hash, tokenizer·template·special token, PEFT/Transformers/TRL/bitsandbytes version, LoRA config, dataset·code commit과 평가 report가 함께 있어야 재현됩니다. Model card에는 목적·data 범위·metric·limitation·license·out-of-scope use를 기록하고 merged artifact를 만들면 merge 전후 평가와 재배포 조건을 다시 확인합니다.
Offline 통과 뒤에는 shadow 또는 제한 canary에서 실제 형식 실패·사람 correction·latency·memory와 incident를 관측합니다. Rollback은 adapter file만 제거하는 것이 아니라 compatible base·tokenizer/template·runtime·generation config와 previous approved adapter로 되돌리는 과정입니다. 동일 failure input이 회복되는지, cache·loaded adapter가 교체됐는지 확인합니다. Owner, 재검토 trigger와 base·data·policy 변경 조건을 승인 증빙에 남깁니다.
그림 읽는 법 Loss가 가장 낮은 checkpoint 400은 critical safety 91%와 일반 능력 회귀 −3.1p로 두 gate를 실패해 기각됩니다. 결과 전에 고정한 gate를 모두 통과하고 previous adapter로 8분 안에 복귀한 checkpoint 300만 canary로 넘깁니다.
핵심을 다시 정리하면
Checkpoint 선택 metric과 독립 필수 gate를 결과 전에 고정합니다.
Adapter·base revision·tokenizer/template·config·dataset·code·environment hash와 rollback run을 한 manifest에 묶습니다.
현실에서 이렇게 연결됩니다
Step 400이 validation loss는 가장 낮지만 critical refusal 91%로 95% gate를 실패하면, loss가 약간 높아도 업무 94%·refusal 97%·general regression 허용 범위인 step 300을 candidate로 두고 canary와 previous adapter rollback을 시험합니다.
INTERACTIVE LAB 1 / 2
실습 1 · LoRA·QLoRA 설정·memory 계약 실습
브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.
행동·base·target·precision과 실제 memory로 fine-tuning plan 승인하기
Model B와 VRAM 표가 아니라 학습할 행동, exact input contract, adapter 주입과 end-to-end pilot 증거를 판정합니다. 기본값은 일부러 실패합니다.
상황
7B QLoRA가 16GB에서 된다는 글을 보고 layer 이름을 복사했지만 base revision·loss target과 backward peak를 확인하지 않았습니다.
목표
LoRA 또는 QLoRA candidate의 목적·base·dataset·template, target·rank·precision과 actual memory·pilot을 하나의 계획 gate로 연결합니다.
Fine-tuning 계획 gate 실행 후 목표나 합격선을 낮추지 말고 실패한 계약 한 층을 보강해 다시 실행합니다.
증빙 한계: Adapter 추정은 square projection과 선택한 target 수를 단순화한 교육용 값이며 bias·embedding·MoE·modules_to_save를 포함하지 않습니다. Browser는 model·GPU를 실행하지 않으므로 actual PEFT report·profiler·checkpoint log가 최종 증거입니다.
INTERACTIVE LAB 2 / 2
실습 2 · Checkpoint 품질·회귀·복구 승격 실습
브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.
네 수치와 3회 반복을 통과하고 동일 비교·failure 귀속·fresh reload·full-stack rollback evidence가 확인됩니다.
Candidate 결과를 보기 전에 업무·critical 목표, general allowed drop과 p95 상한을 고정합니다.
같은 frozen set의 candidate 수치·반복과 manifest·failure·fresh load·rollback 증거를 입력합니다.
Checkpoint 승격 gate 실행 후 loss 기준을 바꾸지 말고 실패 checkpoint·data·target·serving 원인을 고쳐 새 run으로 다시 평가합니다.
증빙 한계: Browser는 입력한 수치만 판정하며 model·checkpoint·latency를 실행하지 않습니다. 실제 raw output·run log·artifact hash, blind review와 fresh load·rollback 기록 없이는 production 승인 증거가 아닙니다.
KEY TERMS
이번 단원 핵심 용어
LoRA
Pretrained base weight를 frozen하고 선택한 layer에 작은 low-rank update 행렬을 학습하는 parameter-efficient adaptation 기법
QLoRA
Frozen quantized base를 통과해 gradient를 LoRA adapter에 전달하며 NF4 등으로 base weight memory를 낮추는 fine-tuning 접근
Target module
LoRA adapter를 주입할 실제 architecture layer의 이름과 범위
Effective batch
Micro-batch, gradient accumulation과 data-parallel worker를 곱해 한 optimizer update에 반영되는 example 수
Regression gate
Candidate가 base·previous의 필수 업무·안전·일반 능력과 운영 조건을 허용 범위 밖으로 악화시키지 않는지 판정하는 독립 기준
UNIT WORKBOOK
개념을 새로운 상황에 적용하는 문제와 기록지
기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.
기본 문제 1
Low-Rank Adaptation(LoRA)의 핵심 동작을 가장 정확하게 설명한 것은 무엇입니까?
기본 문제 2
QLoRA training manifest에 반드시 구분해 기록할 precision 설명으로 가장 적절한 것은 무엇입니까?
적용 문제 3
다른 model의 LoRA config를 복사했더니 loss는 내려가지만 의도한 FFN layer가 학습됐는지 알 수 없습니다. 가장 적절한 다음 행동은 무엇입니까?
후보 architecture는 community 예시와 module 이름이 다르고 새 special token도 하나 추가했습니다.
적용 문제 4
Conversational SFT에서 assistant_only_loss를 켰지만 critical JSON 정답 끝부분이 자주 나오지 않습니다. 가장 먼저 확인할 것은 무엇입니까?
종합 문제 5
LoRA candidate checkpoint를 production으로 승격하는 계획 중 가장 완성된 것은 무엇입니까?
사전 gate는 업무 성공 92%, critical refusal 95%, base 대비 일반 능력 하락 3%p 이하, serving p95 1200ms 이하와 previous stack 복구입니다.
PERSONAL WORKSHEET
내 환경에 옮겨 적는 학습 기록지
입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.
