.svg)
%201.svg)
%201.svg){kind=icon}
담당자가 프로모션 코드를 발송해 드립니다.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
WhaTap AI를 경험해 보세요.
AI 모델 드리프트란? LLM 성능 저하 원인과 탐지 방법
서비스에 챗봇이나 문서 요약 기능을 붙일 때는 LLM(대규모 언어 모델) API를 불러 씁니다. OpenAI나 Anthropic 같은 회사가 제공하는 API입니다. 코드에는 gpt-4o처럼 사용할 모델의 이름을 적어 두고, 이후로는 그 이름으로 계속 호출합니다.
그런데 이름을 고정해 두었다고 해서 그 이름이 가리키는 모델이 지난달과 같은 모델이라는 보장은 없습니다. 모델을 만들어 API로 제공하는 회사(제공사)가 뒤에서 모델을 조정하거나 버전을 정리하기 때문입니다. 그래서 배포도 프롬프트도 건드리지 않았는데 답변 형식이 일정하지 않다는 제보가 들어옵니다. 배포 이력에는 아무 변화가 없는데 문의가 늘거나, 같은 질문을 넣었는데 답변이 지난달과 달라졌다면 원인을 우리 쪽 밖에서 찾아야 합니다.
모델 드리프트(model drift)는 모델을 그대로 두었는데 시간이 지나며 응답 품질이 떨어지는 현상입니다. 모델이 배운 세상과 실제 세상이 어긋나면서 생깁니다. 원인은 모델에 들어오는 입력의 분포가 달라지는 데이터 드리프트와, 입력과 실제 결과 사이의 관계가 달라지는 컨셉 드리프트로 나눠 봅니다.
API로 LLM을 받아 쓸 때는 이것과 다른 일도 생깁니다. 제공사가 모델을 새 버전으로 바꾸면 모델 자체가 달라진 것이라 답이 달라집니다. 서서히 어긋나는 드리프트와는 성격이 다릅니다. 문제는 둘이 겉으로 똑같아 보인다는 점입니다. 어느 쪽이든 우리 쪽에서는 아무것도 바꾸지 않았는데 답이 달라집니다. 이 글은 그 둘을 구분하는 방법을 다룹니다.
코드를 안 바꿔도 LLM 응답이 달라지는 이유
원인은 크게 둘입니다. 하나는 모델 자체가 달라지는 경우이고, 다른 하나는 쓰던 버전이 종료돼 새 모델로 옮겨야 하는 경우입니다.
첫째, 같은 이름의 모델이 계속 같은 모델은 아닙니다. 모델 이름에는 gpt-4o처럼 날짜가 없는 이름과 gpt-4o-2024-08-06처럼 날짜가 붙은 이름이 있습니다. 날짜가 붙은 쪽을 스냅숏이라고 합니다. OpenAI는 스냅숏을 지정해야 성능과 동작이 일정하게 유지된다고 문서에 적어 두었습니다. 바꿔 말하면 날짜 없는 이름으로 부를 때는 어느 버전이 답할지 쓰는 쪽에서 정하지 않은 상태입니다. 이름을 고정해 써도 그 뒤에서 무엇이 응답하는지는 달라질 수 있습니다.
실제로 측정한 결과가 있습니다. 하버드 데이터 과학 리뷰에 실린 스탠퍼드·UC버클리 연구진의 조사입니다. 2023년 3월과 6월, 같은 API를 고정해 쓴 채로 세 달 간격을 두고 측정했습니다. 수학 문제를 푸는 정확도와 민감한 질문에 답하는 방식이 크게 달라졌습니다. 나아진 항목도 있었고 나빠진 항목도 있었습니다. 어느 쪽이든 시간이 지나면 응답 특성은 달라집니다.
둘째, 쓰던 버전이 종료됩니다. 제공사는 구형 모델을 정리하는 지원 중단 정책(deprecation)을 두고 있습니다. OpenAI는 정식 출시(GA) 모델은 최소 6개월 전, 특정 용도로 파생한 모델은 최소 3개월 전에 종료를 예고합니다. 이름에 preview가 붙은 시험판 모델은 2주 수준의 짧은 예고로도 종료할 수 있다고 밝힙니다.
예고 기간이 있으니 대개 준비할 시간이 있습니다. 다만 안전이나 규제 문제가 걸리면 더 빠르게 종료할 수 있다고 밝히고 있습니다. 원하지 않아도 주기적으로 새 모델로 옮겨야 하고, 옮기는 순간 같은 프롬프트의 출력이 달라집니다.
모델 쪽 변화에 서비스 쪽 변화까지 겹치면 원인을 구분하기가 더 어려워집니다. 검색 증강 생성(RAG)처럼 찾아온 문서를 프롬프트에 넣어 주는 구조에서 그 문서가 바뀌었을 때도 답은 달라집니다. 대화가 길어져 모델이 한 번에 볼 수 있는 분량을 넘기면서 앞부분이 빠졌을 때도 마찬가지입니다. 따라서 LLM 응답 변화는 모델 자체의 변화와, 프롬프트·RAG·배포 같은 서비스 구성 변화로 나누어 보면 원인을 좁힐 수 있습니다.
모델 드리프트를 탐지하기 위해 기록해야 할 4가지
답이 달라졌다는 제보를 받고 가장 먼저 막히는 것은 비교할 기록이 없다는 점입니다. 달라진 것 같다는 인상은 있는데 예전 답을 다시 볼 수 없습니다. 그러면 원인을 확인하지 못한 채 넘어갑니다.
기록할 4가지 항목
- 세부 버전 식별자와 호출 설정값: 요청할 때 적은 이름(
gpt-4o)만이 아니라 세부 버전(gpt-4o-2024-05-13)까지 남깁니다. 제공사가 응답에 버전 정보를 함께 준다면 그 값도 남깁니다. 온도(temperature)처럼 답의 폭을 정하는 설정값도 같이 남깁니다. 우리 쪽에서 같은 설정으로 호출했다는 것이 확인돼야, 답이 달라진 원인이 우리 설정에 있는지 모델 쪽에 있는지 가려낼 수 있습니다. - 프롬프트와 응답 원문 표본: 전부 저장할 필요는 없습니다. 표본 비율을 정해 일부만 남겨도 비교는 됩니다.
- 출력 지표: 응답 길이, 지정한 형식을 지켰는지 여부, 품질 점수처럼 숫자로 셀 수 있는 값입니다. 품질 점수는 사람이 평가한 값일 수도 있고, 별도의 평가 프롬프트나 규칙으로 계산한 값일 수도 있습니다.
- 호출 시각: 배포 이력과 시간을 함께 남깁니다.
지표를 그래프로 보는 예시
그래프로 그릴 값은 출력 지표 2개면 충분합니다. 응답 길이 중앙값과 형식 준수율입니다.
응답 길이는 품질을 직접 재는 값은 아니지만 모델이 바뀔 때 가장 먼저 움직입니다. 같은 프롬프트에 답이 갑자기 길어지거나 짧아지면 요약하는 방식이나 형식 지시를 따르는 정도가 달라졌다는 신호입니다. 평균보다 중앙값(길이를 크기 순으로 줄 세웠을 때 가운데 오는 값)을 쓰는 편이 좋습니다. 아주 긴 답 몇 건에 평균이 끌려가기 때문입니다.
형식 준수율은 요구한 형식을 지킨 응답의 비율입니다. JSON으로 답하라고 했는데 설명을 덧붙였거나, 항목 3개를 달라고 했는데 2개만 왔다면 지키지 못한 것으로 셉니다. 사람이 읽지 않고도 셀 수 있어서 자동 알림에 바로 쓸 수 있습니다.
값 2개는 호출이 끝난 직후에 계산해 4가지 기록 중 출력 지표로 남깁니다. 원문 표본은 일부만 남기지만 응답 길이와 형식 준수 여부는 호출마다 남겨야 중앙값과 비율이 나옵니다.
- 응답 길이
응답 문자 수를 세도 되고, API가 응답과 함께 돌려주는 출력 토큰 수(모델이 글을 잘게 나눠 세는 단위)를 그대로 써도 됩니다. 다만 글을 토큰으로 나누는 방식(토크나이저)에 따라 언어별로 글자당 토큰 수가 몇 배씩 차이 나고, 모델이 바뀌면 나누는 기준도 함께 달라집니다. 모델 교체 전후를 비교할 때는 같은 언어 조건에서 문자 수와 토큰 수를 함께 봅니다. 어느 쪽을 쓰든 기준을 하나로 정해 두고, 날짜별로 모은 값을 줄 세워 가운데 값을 씁니다. - 형식 준수율
호출마다 형식을 지켰는지 참과 거짓으로 남깁니다. JSON을 요구했다면 응답을 프로그램이 그대로 읽어 들일 수 있는지, 필요한 항목이 다 있는지 확인하는 정도로 충분합니다. 날짜별로 참인 건수를 전체 건수로 나누면 준수율입니다.
응답 길이와 형식 준수율은 예시입니다. 서비스에 맞는 값이 따로 있으면 그 값을 씁니다. 분류 작업이라면 특정 라벨이 나오는 비율, 요약이라면 원문 대비 압축률을 볼 수 있습니다. 날마다 같은 방식으로 자동 집계할 수 있는 값을 2개에서 3개 정도 정해 두면 됩니다.
먼저 출력 지표를 날짜별 그래프로 그립니다.
다음으로 같은 시간축에 배포 이력과 세부 버전이 바뀐 시점을 표시합니다. 지표 2개가 같은 날 꺾였는데 그날 배포 이력은 없고 세부 버전 변경만 있다면 모델 쪽 변화로 봅니다.
마지막으로 꺾인 구간 전후의 원문 표본을 몇 건 꺼내 실제로 무엇이 달라졌는지 읽어 봅니다.
알림 기준은 특정 숫자로 고정하지 않는 편이 좋습니다. 응답 길이가 500자를 넘으면 알리는 식으로 두면 계속 울립니다. 지난 2주 평균에서 20% 이상 벌어질 때 알리면 불필요한 알림이 줄어듭니다.
안전한 모델 교체를 위한 사전 검증 방법
폐기 예고를 받으면 언젠가는 모델을 변경해야 합니다. 예고를 받고 바로 교체한 뒤 문제가 생기면 대응하는 방식도 있지만, 순서를 정해 두면 교체가 훨씬 수월해집니다.
- 고정 질문 세트
실제로 들어오는 질문 가운데 유형별로 30개에서 50개를 골라 파일로 둡니다. 자주 들어오는 질문, 답이 명확한 질문, 예전에 틀렸던 질문을 섞습니다. 이렇게 모은 질문이 회귀 검증 재료입니다. 회귀 검증은 모델을 바꾼 뒤에도 전에 잘 되던 것이 그대로 되는지 확인하는 일입니다. - 지표 비교
같은 질문 세트를 새 모델과 기존 모델에 각각 돌립니다. 호출마다 남긴 응답 길이, 형식 준수율, 품질 점수를 같은 지표로 비교합니다. 눈으로 다 읽지 못하니 숫자로 먼저 걸러 내고 벌어진 항목만 사람이 확인합니다. - 롤백 조건
예를 들어 '형식 준수율이 5% 이상 떨어지면 되돌린다'처럼 숫자로 정해 둡니다. 몇 퍼센트가 맞는지는 서비스마다 다르니 처음에는 넉넉하게 잡고 운영하면서 기준을 좁힙니다. 기준이 없으면 교체 후에 애매한 상태로 며칠을 보냅니다.
질문 세트, 지표 비교, 롤백 조건. 이 세 단계는 첫 교체 때부터 적용하는 편이 낫습니다.
자주 묻는 질문
모델 드리프트와 환각은 같은 문제인가요?
다릅니다. 환각(hallucination)은 근거가 없는 내용을 만들어 내는 현상입니다. 드리프트는 모델을 그대로 두었는데 응답 품질이 시간에 따라 떨어지는 현상입니다. 환각률이 그대로여도 드리프트는 일어날 수 있고, 반대로 드리프트 때문에 환각이 늘기도 합니다.
자체 호스팅 모델을 쓰면 드리프트가 없나요?
제공사가 모델을 바꾸는 일은 없어집니다. 모델 파일(가중치)을 직접 갖고 있으니 모델 자체는 고정됩니다. 다만 드리프트는 그대로 남습니다. 모델을 고정해 두어도 들어오는 질문의 성격이 달라지면 품질은 떨어집니다. 검색해서 넣어 주는 문서가 바뀌거나 프롬프트를 수정할 때도 응답은 달라집니다. 남겨야 할 기록은 같습니다.
온도(temperature)를 0으로 두면 해결되나요?
온도는 답변의 다양성을 조절하는 값입니다. 값이 낮으면 매번 비슷한 답이 나오고, 높으면 표현이 더 다양해집니다. 0으로 두면 같은 입력에 같은 답이 나올 확률은 올라가지만 완전히 고정되지는 않습니다. 온도 설정은 제공사가 모델을 갱신하는 일과 별개입니다. 모델이 바뀌면 온도가 0이어도 답은 달라집니다.
원문 표본은 몇 퍼센트를 남겨야 하나요?
정해진 값은 없습니다. 하루 호출량이 적으면 전수로 두고, 많으면 1%에서 5% 사이로 시작해 조정하는 편이 무리가 없습니다. 비율과 별개로 두 가지는 빠짐없이 남기는 편이 안전합니다. 오류로 끝난 호출과 품질 점수가 기준 아래로 떨어진 호출입니다. 문제를 확인해야 할 때 필요한 것이 바로 그 호출의 원문입니다.
데이터 드리프트와 모델 드리프트는 무엇이 다른가요?
나란히 놓고 비교하는 개념이 아닙니다. 데이터 드리프트는 모델 드리프트의 원인 가운데 하나입니다. 모델 드리프트는 모델을 그대로 두었는데 응답 품질이 떨어지는 결과를 가리키고, 그 원인으로 입력 분포가 달라지는 데이터 드리프트와 입력과 실제 결과의 관계가 달라지는 컨셉 드리프트를 나눠 봅니다. 제공사가 모델을 새 버전으로 바꾸는 것은 여기에 들어가지 않습니다. 모델이 어긋난 것이 아니라 모델 자체가 달라진 것이라 드리프트로 보지 않습니다. 확인 순서도 다릅니다. 드리프트를 의심할 때는 입력 통계를 먼저 보고, 모델이 바뀌었는지는 세부 버전을 먼저 봅니다.
응답이 느려진 것도 모델 드리프트인가요?
LLM 성능 저하라는 말은 두 가지로 쓰입니다. 응답이 느려지는 속도 문제와, 답 내용이 나빠지는 품질 문제입니다. 이 글이 다루는 쪽은 품질입니다. 속도만 느려졌다면 먼저 볼 것은 첫 토큰까지 걸린 시간과 출력 토큰 수, 재시도 횟수입니다. 모델을 바꾼 뒤 속도와 품질이 함께 나빠지는 경우도 있으니 교체 전후 비교에는 지연 시간도 같이 넣습니다.
마치며
코드를 바꾸지 않았는데 답이 달라지는 일은 LLM을 쓰는 서비스에서 드물지 않게 일어납니다. 응답이 달라지는 것 자체를 막을 방법은 없습니다. 세부 버전과 출력 지표를 남겨 두면 언제부터 무엇이 달라졌는지는 확인할 수 있습니다.
모델별 호출과 토큰 사용량, 응답 지표를 한 화면에서 보고 싶다면 와탭 LLM Observability에서 확인해 보실 수 있습니다.
더 읽을거리
