이득:
- 모델 성능 저하의 조용한 원인(데이터 드리프트, 개념 드리프트, 업스트림 오류)을 인식하고 3계층(운영, 입력, 출력) 모니터링을 구축하는 능력
- 규칙 확인, LLM 심판 및 인간 평가를 통해 여러 계층의 LLM 시스템을 평가하고 LLM 심판 인간 앵커로 보정하는 기능
- 엣지 및 보안 사례가 포함된 평가 세트를 설계하고 발견된 각 오류를 영구 테스트 사례로 전환하는 기능
모델이 제작에 들어가면 작업이 완료된 것이 아닙니다. 진정한 책임은 이제부터 시작됩니다. 아무도 보지 않을 때 모델이 조용히 무너질 수 있기 때문입니다. 이 단원에서는 평가(모델의 품질을 체계적으로 측정)와 모니터링(생산 중인 모델의 지속적인 모니터링)이라는 두 가지 보완적인 분야를 다룹니다. 특히 LLM 시스템에서 평가는 기존 ML보다 더 어렵고 더 많은 주의가 필요합니다.
생산 모델이 조용히 무너지는 이유
버그가 발생하면 로그가 인쇄되고 알람이 꺼집니다. 반면에 ML 모델은 오류가 발생하지 않고도 잘못될 수 있습니다. 성능 저하의 세 가지 주요 원인:
- 데이터 드리프트: 입력 데이터의 분포는 시간이 지남에 따라 변경됩니다(신제품, 사용자 행동 변화, 계절성). 모델은 동일하지만 세상은 변합니다.
- 개념 드리프트: 입출력 관계가 변경됩니다. 사기 전술과 스팸 패턴은 진화합니다. 어제 옳았던 것이 오늘은 틀릴 것입니다.
- 업스트림 손상: 데이터 소스의 형식이 변경되고 영역이 비어 있게 됩니다. 입력이 손상되어 모델이 조용히 침을 흘립니다.
추적을 통해 이러한 조용한 왜곡이 들리게 됩니다.
볼만한 것: 세 개의 레이어
좋은 모니터링에는 세 가지 계층이 포함됩니다.
- 운영 지표: 지연 시간, 오류율, 요청량, 리소스 사용량. "시스템이 정상인가요?"
- 데이터/입력 측정항목: 입력 분포가 훈련의 분포와 유사합니까? 결측치 비율이 높아졌나요? 새로운 카테고리가 나왔나요? “모델이 익숙한 데이터를 보고 있나요?”
- 모델/출력 측정항목: 예측 분포 로그? 신뢰도 점수가 떨어졌나요? 그리고 가능하다면 실제와 비교했을 때 정확도는 얼마나 됩니까? “모델이 아직도 정확합니까?”
세 번째 계층은 가장 가치가 높지만 가장 어렵습니다. 실제 결과는 일반적으로 지연과 함께 제공되기 때문입니다(대출금 상환 여부는 몇 달 후에 분명해집니다).
팁: 실제 결과가 지연되는 경우 먼저 입력 및 예측 분포를 모니터링하세요. 입력 분포의 변화는 정확도 저하의 초기 징후이며 실제 결과를 기다리지 않고 경보를 울릴 수 있습니다.
LLM 시스템 평가: 특별한 과제
기존 ML에서는 '정답'이 명확합니다(클래스 0 또는 1). 반면에 LLM 결과는 개방형입니다. 동일한 질문에 대해 많은 정답이 있을 수 있으며 "정확성"은 단일 숫자에 맞지 않습니다. LLM 평가 접근 방식:
- 참조 측정항목: 출력을 이상적인 답변과 비교합니다. 제한된; 다르게 표현된 정답을 '틀림'으로 간주할 수 있기 때문입니다.
- 규칙 기반 검사: 출력이 유효한 JSON입니까? 금지된 단어도 있나요? 원하는 필드가 포함되어 있나요? 저렴하고 안정적이며 단단합니다.
- LLM-판사(LLM-as-judge): 모델이 "이 기준에 따라 이 답변이 좋은가요?"라고 묻지 않도록 하세요. 규모는 커지지만 심판 자체를 검증해야 합니다.
- 인적 검토: 표준이지만 비용이 많이 들고 느립니다. 샘플에 사용됩니다.
실제로 이들은 각 출력에 대한 저렴한 규칙 검사, 대규모 샘플에 대한 LLM 판단, 작지만 엄격한 샘플에 대한 인간 평가 등 함께 사용됩니다.
약한 접근 / 강력한 접근
약함: "LLM-심판에게 물었습니다. 우리 답변의 92%가 좋았습니다. 시스템은 훌륭합니다."
Güçlü: "우리는 먼저 사람이 라벨을 붙인 100개의 출력물을 사용했습니다. 우리는 동일한 100개의 출력물에 대해 LLM 심사관을 실행하고 사람과 심사관의 합의를 측정했습니다. 85%의 동의 수준은 허용 가능합니다. 우리는 판사가 체계적으로 어디에서 잘못되었는지(장문의 답을 불공평하게 좋게 찾는 경향) 문서화하고 프롬프트를 수정했습니다. 그런 다음에야 우리는 심사관의 점수를 신뢰했습니다."
차이점: 강력한 접근 방식은 맹목적으로가 아닌 인간의 기준으로 심판을 확인합니다. 검증되지 않은 LLM 심판은 보기에는 좋지만 잘못된 자신감을 줍니다.
주의: LLM 심판도 모델입니다. 환각을 유발하고 편파적(길고/자신감 있는 답변을 선호함), 일관성이 없을 수 있습니다. 생산 결정을 내리기 전에 인간 태그로 심판 점수를 보정하세요.
평가 세트: 신중하게 설계됨
좋은 평가 세트는 다양한 실제 사용법과 어려운 사례를 나타냅니다. 단지 쉬운 예시로만 채워진 평가는 잘못된 확신을 갖게 될 것입니다. 평가 클러스터에 넣어야 합니다.
- 극단적인 경우: 빈 입력, 매우 긴 입력, 특이한 형식.
- 알려진 어려운 사례: 과거에 모델이 실수를 했던 예(회귀 테스트).
- 보안 사고: 즉각적인 삽입 시도, 악의적인 요청, 개인정보 침해 트랩.
평가 클러스터는 시간이 지남에 따라 성장합니다. 프로덕션에서 발견한 각각의 새로운 버그는 다음 평가를 위한 테스트 케이스가 됩니다.
경보 및 개입
경보 없이 모니터링이 불완전한 상태로 유지됩니다. 각각의 중요한 지표에 대한 임계값과 대응 계획이 있어야 합니다. "입력 드리프트가 X를 초과하면 엔지니어에게 알립니다.", "오류율이 Y를 초과하면 자동 롤백"입니다. 경보를 의미 있게 유지하십시오. 허위 경보가 너무 많으면 팀의 민감도가 낮아지고 실제 경보를 놓치게 됩니다.
세 개의 미니 케이스
사례 1 - 조기 경고. 수요 예측 모델의 진정한 정확성은 주말이 되어서야 명백해졌습니다. 팀은 입력 분포를 모니터링하던 중 화요일에 새로운 제품 카테고리가 갑자기 증가하는 것을 확인했습니다. 이는 모델에서 한 번도 본 적이 없는 현상이었습니다. 정확도가 떨어질 때까지 기다리지 않고 모델을 업데이트했습니다. 입력 모니터링으로 일수가 단축되었습니다.
사례 2 - 확인되지 않은 심판. 한 팀은 LLM 리뷰어를 기반으로 "우리의 품질이 우수하다"고 보고했습니다. 고객 불만이 늘어나자 인간 모니터링이 도입되었습니다. 심판은 자신감이 있지만 잘못된 답변을 '좋음'으로 간주했습니다. 심판이 인간 태그로 보정되면 실제 품질이 드러났고 훨씬 낮았습니다. 교훈: 검증하지 않고 심판을 신뢰하지 말라.
사례 3 - 회귀 테스트. 신속한 변경으로 한 가지 문제가 해결되면서 다른 문제도 자동으로 중단되었습니다. 그러나 팀은 평가 버킷에 과거의 버그를 유지했습니다. 이 클러스터에서 새로운 변경 사항을 테스트했을 때 손상된 사례가 즉시 발견되어 변경 사항이 수정되었습니다. 교훈: 모든 수정된 버그는 영구적인 테스트 사례가 되어야 합니다.
복사 가능한 템플릿
이 생산 모델에 대한 추적 계획을 생성합니다. 세 가지 레이어를 다룹니다:1) 운영(지연 시간, 오류율, 볼륨)2) 입력/데이터(분포 변화, 누락된 값, 새 범주)3) 모델/출력(예측 분포, 신뢰도, 가능한 경우 정확도)모델: [설명]. 실제 결과가 도착하는 데 걸리는 시간: [기간]각 지표에 대한 임계값 및 개입 권장 사항을 추가합니다.
이 LLM 시스템에 대한 평가(평가) 전략을 제안합니다.작업: [설명]레이어 결정:- 각 출력에 대해 어떤 규칙 기반 검사를 실행해야 합니까?- LLM 중재자는 어떤 기준을 평가해야 하며 어떻게 검증해야 합니까(인간 앵커)?- 어떤 샘플에서 인간 평가를 수행해야 합니까?평가 세트에 넣어야 하는 가장자리 및 안전 사례를 나열합니다.
이 LLM 심판 프롬프트를 확인하세요.- 평가 기준이 명확하거나 주관적인가요?- 길이/신뢰 편향이 발생하기 쉬운가요?- 휴먼 태그로 심판을 어떻게 보정합니까?심판 프롬프트: [프롬프트]
이 모니터링 경보에 대한 응답 런북을 작성하세요. 경보: [예: 입력 드리프트 임계값 초과]초기 제어 단계, 가능한 원인, 롤백 기준, 알릴 대상을 포함해야 합니다.
열화 원인표
왜곡
증상
조기발견의 길
데이터 드리프트
입력 분포 변경
입력 분포 모니터링
컨셉 전환
정의는 소리 없이 떨어진다
예측 + 실제 비교
업스트림 오류
필드가 비어 있거나 형식이 변경됨
스키마 유효성 검사 + 누락 비율
모델 불일치
출력 분포 이동
출력분포 모니터링
일반적인 실수
- 모니터링을 설정하지 않았습니다. 모델은 조용히 분해되어 아무도 볼 수 없습니다.
- 운영 측정항목만 추적합니다. 시스템은 가동되었지만 예측이 틀릴 수 있습니다.
- 심판을 확인하지 않고 LLM을 사용합니다. 그것은 거짓된 확신을 줍니다.
- 쉬운 예를 들어 평가해 보세요. 실제적인 어려움을 나타내는 것은 아닙니다.
- 평가에 과거 오류를 포함하지 않습니다. 같은 오류가 다시 발생합니다.
- 시끄러운 경보. 팀은 둔감해져서 실제 경보를 놓치게 됩니다.
요약하면
모델은 생산 시 오류를 일으키지 않으면서 부정확할 수 있습니다. 따라서 평가와 모니터링은 개발만큼 중요합니다. 3개 계층(운영, 입력, 출력)에서 모니터링을 설정합니다. 실제 결과가 지연되는 경우 조기 경고로 입력 드리프트를 사용하십시오. LLM 시스템에서 eval은 개방형입니다. 규칙 확인, LLM 심판 및 인간 평가를 함께 사용하십시오. 그러나 인간 앵커를 사용하여 LLM 심판을 검증하십시오. 에지 및 보안 사례로 Eval 클러스터를 강화하고 발견된 모든 오류를 영구 테스트 사례로 전환하세요.
응용과제
프로덕션(또는 프로덕션에 가까운) 모델에 대한 3계층 모니터링 계획을 작성하고 하나 이상의 입력 분포 지표에 대한 임계값 + 경보를 정의합니다. LLM 시스템이 있는 경우: 인간과 함께 30개의 출력에 태그를 지정하고 동일한 출력에 대해 LLM 심판을 실행하고 인간 심판 합의를 측정합니다. 심판의 체계적인 편견에 주목하십시오. 평가 클러스터에 3개 이상의 에지와 2개 이상의 보안 사례를 추가하세요.
체크리스트
- [ ] 모니터링은 세 가지 계층(운영, 입력, 출력)을 모두 포괄합니다.
- [ ] 실제 결과가 지연되는 경우 조기 경고로 입력 드리프트를 사용합니다.
- [ ] 나는 인간 레이블로 LLM 중재자를 보정했습니다.
- [ ] Eval 클러스터에는 엣지 및 보안 사례가 포함되어 있습니다.
- [ ] 나는 내가 발견한 모든 버그를 영구 테스트 사례로 전환했습니다.
- [ ] 각각의 중요한 지표에는 임계값과 대응 계획이 있습니다.