학습 데이터 설계와 수집 전략

좋은 모델보다 좋은 데이터가 먼저다

파인튜닝에서는 모델 크기보다 데이터의 방향이 더 중요할 때가 많습니다. 모델은 학습 데이터에서 반복적으로 보이는 입력과 출력의 관계를 따라갑니다. 따라서 데이터가 모호하면 답변도 모호해지고, 데이터가 불친절하면 모델도 불친절해집니다.

먼저 정해야 할 것은 "모델이 어떤 상황에서, 어떤 형식으로, 어떤 수준의 답을 해야 하는가"입니다. 이전 장에서 정의한 목표가 여기서 데이터 구조로 바뀝니다. 예를 들어 "고객 문의에 정확히 답하는 모델"이 목표라면, 데이터에는 실제 문의 표현, 필요한 배경 정보, 바람직한 답변 방식이 함께 들어가야 합니다.

instruction-input-output 형식과 대화 형식

가장 단순한 구조는 instruction-input-output 형식입니다. instruction은 해야 할 일, input은 처리할 내용, output은 기대 답변입니다.

예를 들어 다음과 같은 식입니다.

• instruction: 다음 고객 문의에 대해 환불 정책에 맞게 답변하라.

• input: 배송 전 주문을 취소하고 싶습니다.

• output: 배송 전 주문은 마이페이지에서 직접 취소할 수 있습니다. 결제 취소는 카드사에 따라 3~5영업일이 걸릴 수 있습니다.

이 형식은 분류, 요약, 변환, 단일 질문 답변처럼 한 번의 요청과 한 번의 응답으로 끝나는 업무에 적합합니다.

반면 multi-turn conversation 형식은 여러 차례 주고받는 대화를 담습니다. 상담, 튜터링, 문서 작성 보조처럼 사용자의 추가 질문과 모델의 맥락 유지가 중요한 경우에 필요합니다. 이때는 단순히 마지막 답변만 좋으면 안 됩니다. 앞선 발화를 기억하고, 필요한 질문을 되묻고, 잘못된 가정을 수정하는 흐름까지 포함해야 합니다.

원천 자료를 학습 데이터로 바꾸는 법

도메인 문서, 상담 로그, FAQ, 업무 매뉴얼은 그대로 넣는다고 좋은 학습 데이터가 되지 않습니다. 문서는 지식의 저장 형태이고, 파인튜닝 데이터는 행동의 예시입니다. 즉, "무엇을 알고 있는가"보다 "어떤 상황에서 어떻게 답하는가"로 바꿔야 합니다.

업무 매뉴얼은 대표 상황별 지시문과 답변으로 변환합니다. FAQ는 질문 표현을 다양하게 늘리고, 답변은 실제 고객에게 말하듯 정리합니다. 상담 로그는 좋은 응대만 선별해야 합니다. 실제 로그에는 오탈자, 감정적 표현, 불완전한 안내, 내부 직원용 표현이 섞여 있기 때문입니다.

도메인 문서는 그대로 암기시키기보다, 문서 내용을 바탕으로 예상 질문과 모범 답변을 만듭니다. 예를 들어 보안 정책 문서가 있다면 "외부 저장소에 고객 정보를 올려도 되나요?" 같은 실제 질문으로 바꾸고, 답변에는 허용 여부와 이유, 대안을 함께 담습니다.

좋은 예시, 나쁜 예시, 경계 사례를 함께 넣기

좋은 데이터셋은 모범 답변만 모아둔 자료가 아닙니다. 모델이 실수하기 쉬운 상황도 함께 담아야 합니다.

좋은 예시는 원하는 말투, 답변 길이, 판단 기준을 보여줍니다. 나쁜 예시는 학습에 그대로 넣기보다, "이런 요청에는 이렇게 답하면 안 된다"는 비교나 수정 예시로 활용합니다. 예를 들어 근거 없이 환불을 약속하는 답변, 내부 규정을 노출하는 답변, 모르는 내용을 아는 척하는 답변은 반드시 걸러야 합니다.

경계 사례도 중요합니다. 정책상 애매한 요청, 정보가 부족한 질문, 사용자가 잘못 이해한 상황, 답변을 거부해야 하는 요청이 여기에 해당합니다. 이런 사례가 없으면 모델은 모든 질문에 자신 있게 답하려고 합니다. 좋은 모델은 답을 잘하는 모델이기도 하지만, 모를 때 확인 질문을 하고, 위험한 요청에는 선을 긋는 모델이기도 합니다.

수집보다 정제가 더 어렵다

데이터 수집 단계에서는 출처를 명확히 기록해야 합니다. 어떤 문서에서 왔는지, 언제 수집했는지, 사용 권한이 있는지 남겨야 나중에 문제가 생겼을 때 추적할 수 있습니다.

정제 단계에서는 개인정보, 저작권 자료, 회사 기밀을 제거합니다. 이름, 전화번호, 이메일, 주소, 계좌번호, 주문번호 같은 식별 정보는 삭제하거나 가명 처리합니다. 내부 가격 정책, 미공개 전략, 고객사 정보처럼 외부로 나가면 안 되는 내용도 제거해야 합니다.

저작권이 있는 자료는 특히 조심해야 합니다. 인터넷에서 가져온 글을 그대로 학습 예시로 쓰면 법적 문제가 생길 수 있습니다. 필요한 개념만 참고해 새 문장으로 작성하거나, 사용 허가가 있는 자료만 활용해야 합니다.

데이터 설계의 기준

마지막으로 데이터셋을 만들 때는 세 가지를 점검합니다.

첫째, 목표와 맞는가. 실제 서비스에서 들어올 요청과 학습 데이터의 입력이 비슷해야 합니다. 둘째, 출력이 일관적인가. 같은 상황에 대해 답변 형식과 판단 기준이 흔들리면 모델도 흔들립니다. 셋째, 실패를 줄이는 사례가 있는가. 거절, 확인 질문, 예외 처리, 안전한 대안 제시가 포함되어야 합니다.

파인튜닝 데이터는 많이 모으는 것이 아니라 정확히 설계하는 것입니다. 모델에게 보여줄 예시는 곧 모델의 업무 매뉴얼입니다. 좋은 예시를 반복해서 보여주면 모델은 그 방식으로 일하려고 합니다. 이 점을 이해하면 데이터 수집은 단순한 준비 작업이 아니라 파인튜닝 프로젝트의 핵심 설계가 됩니다.