온라인 vs 오프라인 LLM 평가: 어느 것이 필요한가 (그리고 언제인가)
온라인 vs 오프라인 LLM 평가는 선택이 아니라 필수입니다. 지난 화요일 우리의 promptfoo 스위트가 이를 증명했습니다: 시스템 프롬프트 하나를 다시 작성하고, 47개 테스트 케이스를 실행한 결과, 신뢰도가 0.91에서 0.74로 떨어졌습니다. 약 90초의 CI 시간이 소요되었습니다. 오프라인 검사가 병합 전에 이 회귀를 포착했습니다. 프로덕션 모니터링이라면 그것을 나중에 지원 스레드로 만난 대신 미리 발견했습니다. 오프라인이든 온라인이든, 결론은 같습니다: 두 가지 차선, 다른 역할입니다.
오프라인 LLM 평가는 배포 전에 고정된 데이터셋에 대해 모델을 실행하여 변경 사항이 측정된 품질을 손상시키지 않았음을 증명합니다. 온라인 평가는 출시 후 실제 프로덕션 트래픽을 점수로 매겨 데이터셋에 포함되지 않은 것들을 노출합니다. 대부분의 팀은 두 가지를 모두 필요로 하며, 순서가 중요합니다: 오프라인이 배포를 제어하고, 온라인이 드리프트를 포착합니다.
핵심 요점
- 오프라인 평가는 배포 전에 고정된 데이터셋에 대해 실행되며, 온라인 평가는 출시 후 실제 트래픽에 대해 점수를 매깁니다.
- 대부분의 팀은 둘 다 필요합니다: 오프라인이 배포를 제어하고, 온라인이 데이터셋에 놓친 것들을 포착합니다.
- 오프라인은 프롬프트 회귀와 형식 손상을 포착합니다. 온라인은 드리프트, 부하 시 지연, 그리고 통합 문제를 포착합니다.
- 오프라인 평가를 CI 병합 게이트로 연결합니다. 프로덕션 추적에서 온라인 점수를 평가 세트로 스트리밍합니다.
온라인 평가와 오프라인 평가는 실제로 어떻게 다른가? (9가지 측면)
두 가지 모드는 9가지 축에서 다르지만, 결정적인 것은 데이터 소스입니다: 오프라인 평가는 배포 전에 고정되고 버전 관리되는 데이터셋을 점수로 매기고, 온라인 평가는 출시 후 실제 트래픽을 점수로 매깁니다. 다른 모든 차이—비용, 지연 시간, 위험, 거버넌스—는 이 분할에서 비롯됩니다.
Label Studio의 학습 센터는 이 쌍을 경쟁 모드가 아닌 상호 보완 모드로 프레임합니다. 우리도 동의합니다. 이 표는 일반적인 ML 버전이 다루지 않는 LLM 특화 메트릭스를 포함하도록 이 프레임을 확장합니다.
우리의 해석: 오프라인 열은 "이 변경이 뭔가를 망쳤나?"라는 질문에 답하고, 온라인 열은 "프로덕션이 우리가 테스트한 것에서 떠나가고 있나?"라는 질문에 답합니다. 메트릭 유형 행은 두 모드가 가장 크게 갈라지는 지점입니다. 우리의 LLM 평가 메트릭스 가이드는 각각을 분석합니다.
각 모드가 포착하는 것과 둘 다에서 빠지는 것은?
각 모드는 다른 모드가 볼 수 없는 고유한 실패 클래스를 가집니다. 오프라인은 당신이 한 변경을 포착하고, 온라인은 당신 주변의 세계가 한 변경을 포착합니다. 비용이 많이 드는 실패, 두 그물을 모두 빠져나가는 실패는 인간의 검토자가 필요합니다. 이 분류는 각 모드가 보고하는 것에 대한 우리의 종합이지, 발행된 표준은 아닙니다.
오프라인 전용 사분면이 CI 게이트가 가치를 발휘하는 곳입니다: 형식 준수를 99%에서 91%로 조용히 낮추는 다시 작성된 프롬프트는 코드 검토에서는 보이지 않지만 47개 케이스의 스위트에서는 명백합니다. 온라인 전용 사분면은 더 교활합니다. 실제 사용자는 당신의 골든 세트가 절대 하지 않았던 방식으로 물어보고, 제3자 API는 스테이징이 절대 맞는 일정에 시간 초과가 되며, 누군가는 40,000자 프롬프트를 당신의 챗봇에 먹이기만 할 것입니다. 그 쪽을 위해, 우리의 프로덕션에서 에이전트 평가 가이드는 단일 출력뿐 아니라 다단계 궤적 점수를 다룹니다.
아래 행은 팀들이 건너뛰는 행이자 그들을 물게 하는 행입니다. 사용자를 잃게 하는 실패는 어느 모드도 혼자서는 포착하지 못하는 것들입니다. 그들은 인간이 필요합니다.
오프라인 평가를 CI 게이트로 연결하는 방법은? (아무도 보여주지 않는 설정)
프롬프트, 모델 또는 검색 구성을 건드리는 모든 풀 요청에 대해 필수 상태 검사로 평가 실행자를 추가합니다. 임계값을 어설션합니다. 그 아래로 병합을 차단합니다. promptfoo는 이 정확한 CI 패턴을 문서화하고 있으며, 이것이 우리가 실행하는 것입니다.
GitHub Actions 단계
우리가 오늘 실행하는 게이트의 축약된 버전:
YAML 설정은 테스트 케이스와 어설션을 선언합니다. eval은 스위트가 임계값 아래로 떨어질 때 0이 아닌 값으로 종료되고, GitHub는 필수 검사를 실패로 표시하며, 병합 버튼은 회색으로 변합니다. 경로 필터가 중요합니다: README 수정은 판사 토큰을 낭비하지 않아야 합니다.
게이트가 실제로 포착하는 것
실제 버전은 모든 프롬프트 영향 PR에서 47개의 골든 케이스에 대해 우리의 지원 에이전트 RAG 체인을 점수로 매깁니다. 전체 실행은 약 90초의 CI 시간이 소요되며, 신뢰도가 0.82 아래로 떨어지면 병합이 자동으로 차단됩니다. 3개월 동안 그렇지 않으면 배송되었을 두 가지 회귀를 포착했습니다: 신뢰도를 0.91에서 0.74로 올린 시스템 프롬프트 다시 쓰기, 그리고 컨텍스트 길이를 두 배로 늘리고 답변 관련성을 임계값 아래로 끌어내린 검색자 변경. 둘 다 검토에서 위험해 보이지 않았습니다.
CI의 신뢰도 게이트는 PR당 90초입니다. 프로덕션의 신뢰도 회귀는 당신에게 지원 스레드와 롤백을 요합니다.
우리는 promptfoo, DeepEval 및 기타를 이 패턴에 연결할 수 있는 실행자와 비교했으며, 우리의 LLM 평가 도구 라운드업에서 비교합니다.
어느 도구가 어느 모드를 실행하나? (도구-모드 매트릭스)
어떤 단일 도구도 두 가지 차선을 깔끔하게 소유하지 않습니다. promptfoo와 DeepEval은 스케줄에 따라 내보낸 프로덕션 데이터를 점수로 매길 수 있는 오프라인 우선 실행자입니다. Langfuse와 LangSmith는 수집된 추적에 LLM-as-judge 점수를 추가하는 온라인 우선 추적 저장소입니다. 매트릭스는 각 벤더의 문서에 대한 우리의 읽음입니다: 해석이지, 복음은 아닙니다.
CI에서 나쁜 프롬프트를 차단하는 병합 게이트가 첫 번째 필요사항이라면 promptfoo 또는 DeepEval을 선택합니다. 실제 트래픽을 점수로 매기는 것이 첫 번째 필요사항이라면 Langfuse 또는 LangSmith를 선택하고, 우리의 Langfuse vs LangSmith 비교는 그 선택에 대해 깊이 있게 다룹니다. OpenAI Evals는 홀로 남습니다: 프로덕션 쪽이 없는 레지스트리 스타일 오프라인 실행자입니다.
promptfoo가 당신의 PR을 게이트합니다. Langfuse가 당신의 프로덕션 추적을 점수로 매깁니다. 둘 다 다른 하나를 대체하지 않습니다.
온라인 실패를 오프라인 테스트로 바꾸는 피드백 루프는 어떻게 작동하나?
낮은 점수의 프로덕션 추적을 샘플링하고, 라벨을 지정하고, 오프라인 평가 세트에 커밋합니다. 회귀 스위트는 프로덕션이 던지는 모든 놀라움과 함께 커지고, 다음 배포는 확장된 세트에서 게이트됩니다. 플라이휠 프레임은 우리의 것입니다. 그것은 대부분의 팀이 절대 구축하지 않는 부분입니다.
우리가 실행하는 사이클은:
- 온라인 점수자들이 0.7 판사 점수 아래의 추적을 표시합니다.
- 우리는 주당 20~30개의 표시된 추적을 샘플링합니다.
- 인간이 각각을 라벨지정합니다: 예상 출력 플러스 실패 클래스입니다.
- 라벨이 지정된 케이스가 새로운 골든 예제로 오프라인 평가 세트에 참여합니다.
- 다음 PR은 확장된 스위트에 대해 실행되고, 루프가 다시 시작됩니다.
샘플링은 당신의 LLM 옵저버빌리티 레이어에서 시작되는데, 추적이 원료이기 때문입니다. 케이던스에서: 월간보다 주간이 낫습니다. 왜냐하면 드리프트가 복합되기 때문입니다. 우리는 주당 10~15개의 케이스를 라벨지정하고, 새로운 라벨이 통과율 이동을 멈출 때 세트는 "충분히 크다"입니다. 좁은 지원 에이전트의 경우 약 150~250개 케이스입니다. 모드 간의 선은 계속 흐릿해집니다: Deepchecks는 Union.ai 엔지니어들이 그들의 "오프라인" 평가를 몇 분마다 스케줄한다고 보고하며, 효과적으로 그들을 거의 실시간 검사로 바꿉니다.
당신의 평가 세트는 고정된 산물이 아닙니다. 프로덕션이 당신을 놀라게 할 때마다 매주 커집니다.
언제 둘 다 필요한가? (단계별 온라인 vs 오프라인 LLM 평가)
출시 주부터 둘 다 필요하지만, 균형은 단계에 따라 변합니다: 오프라인이 배포 전 작업을 혼자 수행하고, 출시 주는 섀도우 또는 카나리 점수를 추가하고, 정상 상태는 온라인 모니터링에 주기적인 오프라인 재실행을 추가하고, 드리프트 경고는 재현된 오프라인 테스트 플러스 더 큰 평가 세트로 끝나야 합니다.
배포 전은 엄격하기 가장 저렴한 곳입니다: 차단된 병합은 분이 소비되고, 나쁜 릴리스는 신뢰를 소비합니다. 출시 주는 팀들이 과소 투자하는 곳이지만, 작은 트래픽 슬라이스에 대한 섀도우 점수는 비용이 적게 들고 골든 세트가 거짓말을 했는지 여부를 노출합니다. 정상 상태는 자만심이 스며드는 곳이므로 재평가를 일정에 넣으십시오.
EU AI 법은 어떤가?
...