인스트럭션 · SFT 데이터
원하시는 행동을 보여 주는 프롬프트–응답 쌍. 처음부터 작성하거나 기존 콘텐츠를 다시 씁니다.
- 과제 시연
- 재작성 및 요약 쌍
- 도메인 질의응답
- 형식이 제약된 출력
LLM · 생성형 AI
인스트럭션–응답 쌍, 순위 비교, 멀티턴 대화, 안전성 데이터를 일본 현지 어노테이터가 귀사 팀이 승인한 스타일 가이드에 따라 작성합니다.
일본어 인스트럭션 데이터에서 어려운 것은 답변을 쓰는 일이 아닙니다. 같은 답변을 같은 문체로 만 번 쓰는 일이고, 그 문체를 왜 그렇게 정했는지 문서로 말할 수 있는 일입니다.
여러 사람이 쓴 인스트럭션 데이터는 흔들립니다. 한 어노테이터는 모든 답변을 ですます로 끝내고, 다른 어노테이터는 기술 설명 도중에 である로 바꾸며, 또 다른 어노테이터는 채팅 어시스턴트의 짧은 말투로 씁니다. 그 혼합으로 학습한 모델은 셋 다 괜찮다고 배우고, 그다음에는 그때그때 내키는 것을 내놓습니다 — 일본어 파인튜닝에 대해 저희가 가장 자주 듣는 불만이 바로 이것입니다.
흔들리는 축은 문체만이 아닙니다. 거절은 더 심합니다. 일본어는 완곡하게 거절하고, 거절이 어떤 모습이어야 하는지 듣지 못한 어노테이터는 단호한 お断りします부터 부드러운 それは難しいかもしれません까지 무엇이든 씁니다. 안전성 데이터의 절반이 수락으로 오인될 만큼 부드럽게 거절한다면, 모델은 거절하는 대신 얼버무리는 법을 배웁니다.
그래서 납품물은 결코 데이터만이 아닙니다. 그 데이터를 만들어 낸 문서화된 결정들 — 스타일 가이드, 거절 템플릿, 서식 규칙, 그리고 특정 배치가 따랐던 각 문서의 버전 — 이 함께 갑니다.
한눈에 보기
데이터셋 유형
다섯 가지 데이터셋 계열이며 보통 함께 씁니다. “올바름”의 정의가 각각 다르므로, 저마다 별도의 가이드라인 절과 별도의 검수 단계를 둡니다.
원하시는 행동을 보여 주는 프롬프트–응답 쌍. 처음부터 작성하거나 기존 콘텐츠를 다시 씁니다.
둘 이상의 후보 답변을 문서화된 기준으로 비교하며, 선택의 이유를 추론에 맡기지 않고 기록합니다.
맥락이 쌓이는 대화 — 첫 턴에서 정한 문체가 여덟 번째 턴까지 살아남아야 하며, 대부분의 일본어 대화 데이터는 바로 여기서 무너집니다.
거절해야 하는 프롬프트, 거절해야 할 것처럼 보이지만 거절하면 안 되는 프롬프트, 그리고 둘을 가르는 거절 표현.
질문, 검색된 문서, 근거에 기반한 답변의 삼중항. 문서에 실제로 답이 없는 부정 사례도 함께 만듭니다.
일본어 특유의 문제
내려 두지 않으면, 검수에서는 멀쩡해 보이지만 모델에서는 나쁘게 작동하는 데이터셋을 만들어 내는 네 가지 결정입니다.
일본어는 모든 문장 종결에서 정중함의 선택을 강제합니다. ですます와 である, 보통체는 서로 바꿔 쓸 수 없으며, 혼합된 데이터로 학습한 모델은 하나의 답변 안에서도 이를 섞습니다.
대응 방식 스타일 가이드가 제품 접점마다 기본 문체를 하나 정하고, 예외를 목록화하며, 각각의 예시를 제시합니다. 문체 일관성은 취향의 문제가 아니라 검수에서 채점되는 항목입니다.
それはちょっと難しいです는 어려움에 대한 진술이 아니라 거절입니다. 이를 문자 그대로 라벨링하는 어노테이터는, 거절을 중립적인 발언으로 읽으라고 모델에게 가르치는 셈입니다.
대응 방식 거절 범주와 그 표현, 각각이 의도하는 강도를 사전에 정의합니다. 안전성 데이터는 그 거절이 일본어 화자에게 거절로 읽히는지를 중심으로 검수합니다.
일본어는 맥락상 자명한 주어를 생략합니다. 멀티턴 데이터에서는 지시 대상이 네 턴 앞에 있을 수 있고, 답변을 따로 떼어 작성하는 어노테이터는 잘못 짚게 됩니다.
대응 방식 멀티턴 항목은 턴 단위가 아니라 대화 전체로 작성하고 검수합니다. 지시 대상이 정말로 모호한 경우에는 추측으로 라벨링하지 않고, 대화를 고치거나 폐기합니다.
같은 단어가 한자, 히라가나, 가타카나로 나타나고, 숫자와 문장 부호는 전각이나 반각으로 나타납니다. 통제하지 않으면 서식은 무작위라고 모델에게 가르치게 됩니다.
대응 방식 정규화 규약이 자주 쓰이는 단어의 표기, 숫자, 문장 부호, 로마자 주변 공백, 목록 서식을 다룹니다. 작성 시점에 적용하고 납품 전에 자동으로 검사합니다.
프로세스
파일럿의 목적은 가이드라인 초안을 깨뜨려 보는 것입니다. 더 이상 깨지지 않을 때에만 프로덕션이 시작됩니다.
귀사 제품에서 좋은 답변이 어떤 모습인지 합의합니다. 문체, 길이, 서식, 무엇을 어떻게 거절할지, 그리고 모르는 것에 대해 모델이 어떻게 해야 하는지입니다.
그 결정들을 예시와 반례가 담긴 문서로 만듭니다. 아직 정하지 않으신 모호한 지점은 조용히 흡수되지 않고 여기서 드러납니다.
여러 어노테이터가 소규모 배치를 독립적으로 작성합니다. 결과가 갈리는 곳이 가이드라인이 불명확했던 곳입니다 — 고치는 것은 어노테이터가 아니라 가이드라인입니다.
모든 항목을 한 어노테이터가 쓰고 다른 어노테이터가 검수하며, 시니어 검수자가 표본을 확인하고 이견을 서면으로 판정합니다.
데이터와 가이드라인 버전, 레코드별 이력, QA 리포트, 직전 배치 대비 변경 이력을 함께 납품합니다.
납품
필드는 킥오프에서 합의합니다. 아래는 맞출 기존 스키마가 없을 때의 기본 구조입니다.
| 데이터셋 | 기본 형식 | 레코드에 포함되는 것 |
|---|---|---|
| 인스트럭션 / SFT | JSONL, messages 배열 | system / user / assistant 턴, 과제 태그, 가이드라인 버전 |
| 선호 쌍 | JSONL, chosen + rejected | 두 후보 모두, 기준별 점수, 서면 근거 |
| 멀티턴 대화 | JSONL, 대화 한 건당 한 줄 | 전체 턴 목록, 페르소나 메모, 문체 태그 |
| 안전성과 거절 | JSONL | 프롬프트, 범주, 기대 행동, 사용된 거절 표현 |
| RAG 근거 | JSONL | 질문, 문서, 답변, 인용 구간, 답변 가능 여부 플래그 |
품질
일반적인 어노테이션 QA는 문체 흔들림이나 부드러운 거절을 잡아내지 못합니다. 아래 검사들이 잡아냅니다.
FAQ
첫 일본어 파인튜닝의 범위를 정할 때 팀들이 묻는 질문들.
둘 다 합니다. 일본어에서는 처음부터 작성하는 경우가 흔합니다. 쓸 만한 공개 일본어 인스트럭션 데이터가 드물고, 기계 번역된 데이터는 영어 문장 구조를 모델에 그대로 들여오기 때문입니다. 지원 로그나 매뉴얼, 사내 문서 같은 콘텐츠를 이미 가지고 계신 경우에는 그것을 바탕으로 다시 쓰는 편이 더 많으며, 그렇게 하면 데이터가 실제 도메인에 뿌리내립니다.
예시가 담긴 문서화된 스타일 가이드, 프로덕션 전에 여러 어노테이터가 같은 항목을 독립적으로 작성하는 캘리브레이션 라운드, 그리고 검수에서 명시적으로 채점되는 문체 일관성 항목입니다. 여기서 일관성은 지향점이 아니라 측정 가능한 속성입니다 — 저희가 지켜보는 것은 어노테이터 간의 차이이며, 해소된 차이는 모두 가이드에 다시 기록됩니다.
최종 데이터의 원천으로는 쓰지 않습니다. 번역된 인스트럭션 데이터는 영어의 담화 구조와 영어식 정중함의 전제, 영어식 서식 습관을 물려받고, 그것으로 학습한 모델은 원어민 독자가 번역투라고 표현하는 일본어를 내놓습니다. 프롬프트 아이디어의 발판으로 번역을 쓰기는 하지만, 답변은 일본어 화자가 일본어로 작성합니다.
합의하신 경우에만, 그리고 언제나 사람이 다시 쓰고 검수하는 과정을 얹어서 진행합니다 — 검수 없는 통과는 없습니다. AI 지원을 썼는지 여부는 레코드마다 기록하므로 나중에 필터링하거나 감사하실 수 있습니다. 완전히 사람이 작성한 데이터가 필요하시면 그렇게 프로젝트를 운영하며, 이력 필드가 그것을 증명합니다.
대부분의 팀이 생각하시는 것보다 적습니다. 신중하게 작성되고 문체가 일관된 수천 건이, 노이즈가 많은 열 배의 데이터보다 일본어 파인튜닝을 더 멀리 끌고 가는 경우가 많습니다. 모델이 배우는 것이 과제만큼이나 문체이기 때문입니다. 저희는 먼저 수백 건 규모의 파일럿으로 가이드라인을 검증한 뒤, 그 파일럿이 측정한 결과로 프로덕션 규모를 정합니다.