AI 모델 업데이트 회귀 테스트 데이터셋 만드는 법
- 학습에 쓰지 않은 대표 사례와 고정 골든셋을 분리해 관리합니다.
- 실패 사례와 경계 조건을 포함해 변경 영향과 취약 구간을 확인합니다.
- 모델·데이터·프롬프트·평가 기준 버전을 함께 기록합니다.
AI 모델 업데이트 후 회귀 테스트를 하려면, 이전 버전에서 확인한 입력과 기대 결과를 고정 데이터셋으로 만들고 새 버전에도 같은 조건으로 실행하면 됩니다. 핵심은 사례를 많이 모으는 것보다 서비스의 중요한 상황을 대표하고, 기대 결과와 판정 기준이 분명한 데이터를 꾸준히 관리하는 것입니다. 분류 모델과 생성형 AI 모두 적용할 수 있지만, 정답을 비교하는 방식은 작업 유형에 맞춰야 합니다.
회귀 테스트 데이터셋은 무엇을 확인하나
회귀 테스트는 모델이나 전처리·프롬프트를 바꾼 뒤, 기존에 잘 처리하던 상황이 나빠지지 않았는지 확인하는 절차입니다. 업데이트 전후 모델에 동일한 입력을 넣고 결과를 비교합니다. 이전보다 전체 점수가 높더라도 특정 사용자군이나 중요한 작업에서 오류가 늘 수 있으므로 전체 평균만으로 통과를 판단하면 안 됩니다.
학습 데이터와 평가 데이터를 분리합니다
테스트 사례가 학습에 포함되었거나 개발 중 반복해서 결과를 보고 수정하는 데 쓰이면, 모델의 새로운 상황 대응력을 제대로 가늠하기 어렵습니다. 가능하면 학습·튜닝에 쓰지 않은 자료를 평가용으로 보관하세요. Google의 데이터 분할 안내도 테스트 데이터를 별도로 두고 학습 데이터와 중복되지 않도록 관리하는 원칙을 설명합니다.
모든 작업에 정답 일치율만 적용하지 않습니다
정해진 라벨을 고르는 분류 모델은 정확도·재현율처럼 작업에 맞는 지표를 쓸 수 있습니다. 생성형 AI는 표현이 달라도 사실관계나 지시 준수 여부가 같을 수 있으므로, 문자열이 똑같은지만 비교하지 마세요. 핵심 주장, 필수 항목 누락, 근거 없는 답변, 형식 준수 등 관찰 가능한 판정 기준을 정하고, 필요한 경우 사람의 검토를 포함합니다. 생성형 AI 결과물 검수 기준과 평가표 만드는 법도 평가 항목을 구체화할 때 참고할 수 있습니다.
데이터셋에 넣을 사례를 고르는 기준
실제 서비스에서 자주 들어오는 입력을 중심으로 하되, 빈도가 낮아도 실패했을 때 영향이 큰 사례를 따로 포함합니다. 운영 로그를 활용한다면 개인정보를 제거하고, 수집 목적과 이용 권한을 확인하세요. 모델이 다뤄서는 안 되는 민감한 정보가 들어간 입력은 안전한 대체 예시로 바꾸는 방식도 고려할 수 있습니다.
- 대표 사례: 주요 사용자 요청, 흔한 입력 형식, 정상적으로 답해야 하는 기본 업무
- 경계 사례: 오탈자, 짧거나 모호한 질문, 긴 입력, 누락된 필드, 여러 조건이 섞인 요청
- 실패 사례: 이전 버전에서 오답·누락·잘못된 형식이 확인된 입력과 수정 여부를 확인할 사례
- 위험 사례: 권한 밖 요청, 민감정보 노출 가능성, 부정확한 답이 큰 피해로 이어질 수 있는 상황
- 변화 사례: 최근 입력 분포나 제품 기능이 바뀌어 새로 등장한 표현과 사용 시나리오
한 사례를 여러 범주에 표시해도 됩니다. 다만 같은 사례가 중복 집계되어 결과를 부풀리지 않도록 고유 ID를 부여하세요. 시간 흐름에 따라 입력이 달라지는 서비스라면 과거 자료만 고정하지 말고, 최근 사례를 별도 묶음으로 추가해 현재 운영 환경과의 차이도 살펴보세요.
업데이트용 데이터셋을 만드는 4단계
1단계: 업데이트 범위와 실패 조건을 정합니다
모델 가중치만 바꾸는지, 프롬프트·검색 자료·전처리·추론 설정까지 함께 바꾸는지 먼저 적습니다. 확인할 문제를 구체적으로 정해야 데이터셋에 필요한 사례도 정할 수 있습니다. 예를 들어 응답 형식 변경이라면 필수 키 누락과 스키마 위반 사례를, 검색 방식 변경이라면 근거 문서가 있는 질문과 없는 질문을 준비합니다.
2단계: 사례를 수집하고 범주를 표시합니다
운영 기록, 고객 문의, 검수 기록, 합성 사례 등 출처를 정하고 각 항목에 사례 ID·출처·수집일·작업 유형·난이도·위험도를 기록합니다. 하나의 유형에 사례가 몰리지 않았는지 살펴보세요. 합성 데이터는 빈틈을 메우는 데 쓸 수 있지만, 실제 사용자가 쓰는 표현과 다를 수 있으므로 실제 사례와 구분해 표시하는 편이 좋습니다.
3단계: 기대 결과와 판정 기준을 작성합니다
각 입력에 정답 라벨 또는 기대 응답의 핵심 조건을 붙입니다. 생성형 AI는 유일한 문장 답안을 강요하기보다 필수 사실, 허용 가능한 변형, 금지할 오류를 명시하세요. 사람의 판단이 필요한 항목은 검수자가 같은 기준을 적용하도록 간단한 채점표와 예시를 둡니다. 의견이 갈린 사례는 억지로 정답을 확정하지 말고 보류 사유와 추가 확인 책임자를 기록합니다.
4단계: 고정본을 만들고 새 버전과 비교합니다
검수된 항목을 읽기 전용의 데이터셋 버전으로 저장하고, 기준 모델과 업데이트 모델에 같은 실행 조건으로 평가합니다. 모델 식별자뿐 아니라 프롬프트, 전처리, 검색 인덱스, 실행 설정, 평가 코드 버전도 남겨야 차이가 생긴 원인을 추적할 수 있습니다.
- 기준 모델을 고정 사례에 실행하고 결과와 지표를 저장합니다.
- 업데이트 모델을 같은 입력·설정으로 실행합니다.
- 전체 지표와 범주별 결과, 새로 발생한 오류를 나눠 비교합니다.
- 사전에 정한 통과 기준을 적용하고 실패 사례는 원인과 조치 내역을 기록합니다.
Google의 배포 테스트 안내는 새 모델에서 갑작스러운 품질 저하를 이전 버전과 비교하고, 여러 업데이트에 걸친 점진적 저하는 고정 기준 데이터셋의 품질 기준으로 확인하는 방법을 설명합니다. 프로덕션 ML 시스템: 배포 테스트를 참고해 비교 평가와 운영 전 점검을 설계할 수 있습니다.
항목별 기록과 통과 기준 설계
데이터 파일에 입력과 정답만 넣으면 나중에 결과를 재현하거나 편향을 찾기 어렵습니다. 아래 필드를 최소 구성으로 삼고, 서비스 특성에 맞춰 확장하세요.
| 필드 | 기록 내용 | 활용 목적 |
|---|---|---|
| case_id | 변경되지 않는 사례 식별자 | 버전 간 결과 연결 |
| input·expected | 입력과 정답 또는 판정 조건 | 동일 조건 평가 |
| category·risk | 유형, 난이도, 영향도 | 하위 집단별 오류 확인 |
| provenance·version | 출처, 데이터셋 버전, 수정 이력 | 재현과 변경 추적 |
통과 기준은 결과를 본 다음 유리하게 바꾸지 않도록 평가 전에 정합니다. 예를 들어 전체 지표의 최소 기준과 함께, 안전·필수 업무 범주의 허용 가능한 오류 조건을 둘 수 있습니다. 숫자 하나로 모든 모델과 업무에 적용할 보편적 통과선을 제시하기는 어렵습니다. 오류 비용, 기존 성능, 검수 역량에 근거해 팀별 기준을 정하고 그 이유를 남기세요.
기억할 기준: 전체 점수가 개선되어도 중요한 하위 범주의 오류가 늘면 그대로 통과시키지 말고, 해당 사례와 원인을 따로 검토하세요.
데이터셋을 오래 쓸 때 생기는 함정
고정 데이터셋은 비교를 가능하게 하지만, 같은 평가 묶음에 맞춰 모델을 반복 수정하면 그 데이터에 과적합될 수 있습니다. 핵심 골든셋은 제한된 담당자만 변경하고, 개발 중 반복 확인할 검증용 묶음과 최종 확인용 묶음을 나누는 방법이 유용합니다. 사례를 추가하거나 정답을 고칠 때도 기존 버전을 덮어쓰지 말고 변경 이력과 새 버전을 남깁니다.
- 중복 문장이나 같은 원문에서 파생된 사례가 학습·평가 양쪽에 섞이지 않았는지 점검합니다.
- 평가 데이터의 정답이나 민감한 원문이 모델 학습 자료·프롬프트에 유출되지 않게 접근을 제한합니다.
- 실서비스 데이터 분포가 달라지면 새 사례 묶음을 보강하되, 과거 결과와 비교 가능한 고정 묶음도 유지합니다.
- 생성 결과가 실행마다 달라지는 모델은 동일한 설정을 기록하고, 한 번의 결과만으로 결론 내리지 않도록 반복성과 사람 검수를 고려합니다.
테스트셋은 영구적으로 대표성을 보장하는 자산이 아닙니다. Google의 데이터 분할 안내도 평가 데이터가 반복 사용되면 신뢰성이 약해질 수 있고, 실제 데이터와 차이가 커지면 평가 자료를 점검해야 한다고 설명합니다. 기준 데이터는 안정적으로 보존하고, 최근 사례를 담은 보충 평가 세트를 병행하면 과거와 현재 변화를 함께 읽을 수 있습니다.
업데이트 배포 전 최종 점검
배포 판단 전에 비교 결과를 재현할 수 있는지 확인하세요. 데이터셋 버전과 모델 버전, 실행 설정이 빠졌거나 변경되었다면 결과 해석이 불명확해질 수 있습니다. Google Cloud의 ML 품질 가이드도 학습·검증·테스트 데이터 분리, 대표성, 전처리 누수 방지와 실험 기록을 권고합니다. 고품질 예측 ML 솔루션 개발 가이드라인에서 데이터 품질 및 테스트 절차를 확인할 수 있습니다.
- 평가 사례가 학습·튜닝에 쓰이지 않았고 중복이 관리되었는지 확인합니다.
- 전체 및 중요 범주별 지표와 대표 오류 사례를 비교합니다.
- 변경된 모델·프롬프트·전처리·평가 기준의 버전을 결과와 함께 저장합니다.
- 실패 기준에 걸린 항목은 원인을 확인하고 수정 후 재평가합니다.
- 데이터셋 변경 사항과 배포 판단 근거를 기록해 다음 업데이트의 기준으로 삼습니다.
주의: 평가 결과는 데이터셋이 대표하는 범위 안에서만 해석해야 합니다. 통과가 모든 실제 입력에서 오류가 없다는 보증은 아닙니다.
자주 묻는 질문
Q. 회귀 테스트 데이터셋은 몇 개 사례로 시작해야 하나요?
정해진 최소 개수는 없습니다. 주요 업무와 위험 상황을 빠짐없이 대표하는지, 범주별 결과를 해석할 수 있는지부터 확인하세요. 사례가 적다면 결과의 불확실성을 함께 기록하고 점진적으로 보강합니다.
Q. 운영 데이터를 그대로 평가에 써도 되나요?
수집 목적과 권한을 확인하고 개인정보를 제거하거나 적절히 비식별화한 뒤 사용할 수 있습니다. 학습·튜닝에 들어간 데이터와 겹치지 않도록 분리 여부를 확인하고, 출처와 처리 이력을 기록하세요.
Q. 생성형 AI 결과는 어떻게 비교하나요?
문장 전체의 일치율보다 사실성, 필수 정보 포함, 지시 준수, 근거 사용, 형식 적합성처럼 업무상 중요한 기준을 정해 평가합니다. 모호하거나 영향이 큰 사례에는 사람 검수를 추가하세요.
Q. 데이터셋은 업데이트마다 바꿔야 하나요?
기존 버전을 덮어쓰지 말고 고정 비교용 묶음을 보존하세요. 새로운 기능·실패 유형·실서비스 입력 변화는 별도 버전이나 보충 세트에 추가하고, 변경 이유와 영향 범위를 기록합니다.
