마이그레이션 후 품질이 튄다? 결론은 ‘변수 통제’부터
모델을 옮긴 뒤 답변 품질이 갑자기 들쑥날쑥해지면, 대부분 온도나 컨텍스트 길이부터 의심해요.
하지만 실제로 더 자주 원인을 만드는 건 “실험을 어떻게 굴렸는지”의 설계 실수예요.
- 데이터 분할/샘플링이 바뀌었는지
- 프롬프트·전처리·토크나이징 파이프라인이 달라졌는지
- 평가 지표/채점 기준이 실제로 동일한지
- 잘리는 구간(트렁케이션)이 의도와 다른지
- A/B 테스트에서 랜덤성·캐시·누출이 섞였는지
실험 설계 실수 1: 데이터 분할이 바뀐 상태로 비교했다
마이그레이션 전후를 “같은 데이터로 평가”한다고 생각해도, 아래가 조금만 달라져도 품질이 튈 수 있어요.
- 학습/검증/테스트 비율 또는 샘플 선택 방식이 달라짐
- 시간 기반 슬라이싱(최근 데이터 우선)이 앞뒤에서 바뀜
- 중복 제거(중복 문장/쿼리)가 전후 파이프라인에서 다르게 동작
- 클래스/도메인 비율이 목표와 다르게 쏠림
특히 “들쑥날쑥”이면 평균 점수만 보지 말고, 구간별(도메인/언어/길이 버킷)로도 다시 나눠 확인해요.
판단이 쉬운 체크: 전후 비교에 쓰인 데이터에 대해 동일한 id 목록(또는 해시)을 남겨두고, 평가 때마다 정확히 같은지 검증하세요.
실험 설계 실수 2: 프롬프트 템플릿/전처리가 “거의 비슷”하게 달랐다
온도나 컨텍스트를 같게 둬도, 프롬프트가 조금만 달라지면 결과는 바로 흔들려요.
여기서 문제는 “사람이 눈으로 보기엔 비슷”해도, 실제로는 전처리 단계에서 차이가 나는 경우예요.
문장 구분 방식(개행/공백/특수문자)이 달라짐
시스템/사용자 역할 라벨, 참고문서 포맷이 달라짐
토큰 경계가 달라져서 동일 “문자 수”라도 잘리는 위치가 변함
검색 결과를 합치는 규칙(상위 n개/중복 제거/정렬)이 바뀜
특히 RAG에서는 “프롬프트만 바꿔도 답이 안 좋아지는” 케이스가 생기는데, 이런 뉘앙스는 쿼리 리라이팅 쪽에서도 먼저 흔들 수 있어요. AI RAG에서 프롬프트만 바꿔도 답이 안 좋아질 때, 검색 쿼리 리라이팅이 먼저인 이유와 적용법 4가지도 같이 점검해보세요.
“동일 프롬프트”를 문서로만 비교하지 말고, 실제 호출에 들어간 최종 프롬프트 문자열(혹은 빌드 로그)을 전후로 저장해 diff를 확인하세요.
실험 설계 실수 3: 평가 지표/채점 루브릭이 전후로 은근히 바뀌었다
품질이 튄다고 느끼는 순간, 사실 모델이 아니라 채점기가 바뀐 경우가 있어요.
대표적으로 이런 실수가 나옵니다.
- 정답 정의가 달라짐(“부분 정답 허용” 여부 등)
- 거절/중립 응답을 어떻게 처리하는지 기준이 달라짐
- 평가자가 보는 문서/컨텍스트가 전후에서 다름
- 동일 지표라도 계산 로직(전처리/정규화)이 달라짐
가능하면 “모든 항목을 다시 채점”하기보다, 전후 결과를 섞어 놓고 같은 루브릭으로 재평가해보면 원인을 빨리 좁힐 수 있어요.
또, 테스트 설계에서 조건부처럼 보이는 항목(예: 길이/도메인별 난이도)이 섞이면 평균이 흔들리기도 해서, 구간별 지표로 재정렬해보는 게 좋아요.
실험 설계 실수 4: 컨텍스트 길이 “숫자”는 같았는데, 실제 잘림 구간이 달랐다
컨텍스트 길이를 “같게 설정”했는데 품질이 튀면, 진짜로는 “어디서부터 잘리는지”가 달라졌을 가능성이 커요.
특히 마이그레이션 시 파이프라인이 바뀌면 이런 일이 자주 생겨요.
- 대화 히스토리 구성 순서(오래된 문장을 먼저 제거하는지)
- 시스템 메시지/도구 호출 결과가 토큰 예산에서 차지하는 방식
- RAG 문서 삽입 위치(질문 앞/뒤), 문서 포맷 차이
- 토큰 계산 기준이 “문자 수”가 아니라 “토큰 수”로 바뀜
여기서 중요한 건 “온도”를 건드리기 전에, 실제 입력 토큰 로그를 전후로 비교하는 거예요.
간단한 실행 팁: 동일 샘플 3~5개를 골라서, 전후 호출에서 “입력 토큰 총량/잘린 구간 표시/마지막 포함 토큰 위치”를 뽑아보면 차이가 금방 보여요.
실험 설계 실수 5: A/B 테스트에서 랜덤성·캐시·누출이 섞였다
마이그레이션 후 성능이 튄 경우, “어떤 요청에서는 운이 좋고 어떤 요청에서는 운이 나쁜” 식으로 보일 수 있어요.
그런데 그 운이 모델의 변화가 아니라, 실험 환경에서 만들어졌을 때가 있습니다.
- 시드/샘플링 설정이 전후에서 다르거나, 재현 불가능
- 캐시가 일부 요청에만 적용됨(앞뒤 요청 순서에 따라 달라짐)
- 테스트 데이터가 “학습된 설정”이나 다른 실험 결과에 섞여 누출
- 배치 처리 순서/동시성 때문에 전후 로깅이 불완전
이걸 줄이려면 “전후 동일한 순서”로 요청을 재현할 수 있게 준비하거나, 최소한 동일 샘플을 여러 번 돌려 분산(흔들림 폭)을 함께 봐야 해요.
또 호출 속도·캐시·스트리밍 같은 실행 방식이 바뀌면 결과 품질 관찰이 더 어려워질 수 있으니, 먼저 흐름 자체를 정리해두면 좋아요. AI LLM 호출 속도 느려질 때, 캐시·스트리밍·배치 중 무엇부터 바꿔야 하는지 순서 5단계도 참고하면 “환경 차이”를 더 빨리 분리할 수 있어요.
온도·컨텍스트 점검은 그다음: 확인 체크리스트
이제야 “온도/컨텍스트”를 만져볼 타이밍이에요. 다만 이때도 한 번에 하나씩만 바꾸는 게 안전합니다.
- 온도, top_p, max tokens 같은 샘플링 파라미터가 전후 동일한지
- 컨텍스트는 “문자 수”가 아니라 토큰 예산 기준으로 맞췄는지
- 시스템 프롬프트/도구 결과 포함 규칙이 같은지
- 재현성(시드/로그)이 남는지
품질이 튄다면, 먼저 “모델”이 아니라 “실험이 동일했는지”를 확인하는 게 가장 빠릅니다.
| 실험 설계 실수 | 겉으로 보이는 증상 | 가장 빠른 검증 |
|---|---|---|
| 데이터 분할/샘플링 변경 | 특정 도메인에서만 급락·급등 | 전후 평가 id 목록 동일성 확인 |
| 프롬프트/전처리 차이 | 요구 형식 위반, 출력 스타일 변화 | 최종 입력 프롬프트 diff 저장 |
| 평가 루브릭 불일치 | 지표는 낮지만 실제 답은 비슷 | 재평가(동일 루브릭)로 재확인 |
| 잘림 구간/토큰 계산 차이 | 긴 입력에서만 흔들림 | 입력 토큰 로그의 잘림 위치 비교 |
| 랜덤성/캐시/누출 혼합 | 요청마다 편차가 비정상적으로 큼 | 재현 가능한 시드/캐시 조건 통제 |
자주 묻는 질문
온도와 컨텍스트를 이미 고정했는데도 품질이 튄다면, 무엇부터 볼까요?
우선 데이터 id/샘플링이 전후에 동일한지, 그리고 “최종 입력 프롬프트 문자열”이 같은지부터 확인하세요. 평가 루브릭(채점 기준)까지 바뀌었는지도 같이 점검하면 원인을 빨리 좁힐 수 있어요.
평가 지표는 같다고 했는데 결과가 다르면, 어떤 부분이 흔한가요?
정답 판정의 전처리(공백/정규화), 거절/중립 처리 규칙, 그리고 계산 로직이 미세하게 달라지는 경우가 흔합니다. 같은 결과를 두고 “동일 루브릭으로 재채점”해보면 가장 확실해요.
컨텍스트 길이가 같아도 잘리는 위치가 달라질 수 있나요?
네. 토큰 계산 기준이 다르거나, 시스템 메시지/도구 결과/문서 삽입 순서가 달라지면 “총량은 같아도 포함되는 구간”이 달라질 수 있어요. 전후 입력 토큰 로그를 비교해 보세요.
A/B 테스트에서 품질이 들쑥날쑥할 때, 랜덤성 외에 또 뭐가 있나요?
캐시 적용 범위(일부 요청만 캐시 히트), 요청 순서에 따른 부작용, 그리고 실험 데이터 누출(다른 실험/데이터와 섞임) 같은 실험 환경 요인이 원인일 수 있어요.
마무리
마이그레이션 후 품질이 튄다면, 먼저 온도·컨텍스트를 만지기보다 실험 설계가 진짜 동일했는지부터 점검해보세요.
위 5가지(데이터/프롬프트/평가/잘림/A-B 혼합)를 순서대로 확인하면, 원인을 찾는 속도가 확 달라집니다.
