스킬캠퍼스

오늘 끝나면

평가·모니터링

  • 평가·모니터링의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 평가이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

품질·환각·관측성 — 운영 중 감시 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

Enterprise LLM · 14

평가·
모니터링

품질, 환각, 지연, 비용은 배포 뒤 운영 중에도 계속 흔들린다.
무엇을 어떻게 재고, 무너지면 어떻게 잡아채는지가 14강의 주제다.

P.01Enterprise LLM · 14

무엇을 재는가, 네 개의 지표

“잘 돌아가요?” 느낌으로 답하면 안 된다. 운영은 숫자로 봐야 한다.

사내 LLM에서 항상 보는 네 지표가 있다.
품질은 답이 맞고 쓸 만한지를 본다.
환각은 없는 사실을 지어내는 비율이다.

지연은 답이 돌아오는 시간이다. 평균이 아니라 p95로 본다. 100명 중 95번째로 느린 사람도 견딜 만한지를 따진다.
비용은 13강에서 본 토큰 단가에 사용량을 곱한 값이다.

이 넷은 서로 당긴다. 더 큰 모델을 쓰면 품질은 오르지만 지연과 비용은 나빠진다.
그래서 하나만 보면 안 되고 넷을 한 화면에서 같이 봐야 한다.

품질 · 환각 · 지연 · 비용
운영 중 항상 보는 네 지표
품질골든셋 점수

답이 맞고 쓸 만한가

환각심사 모델·신고

없는 사실을 지어내는 비율

지연트레이스 측정

답이 돌아오는 시간 (p95)

비용호출 로그 집계

토큰 단가 × 사용량

서로 당긴다. 하나만 보면 다른 게 무너진다
P.02Enterprise LLM · 14

골든셋, 정답을 고정해 두고 잰다

품질을 객관적으로 재려면 기준이 필요하다. 그 기준이 골든셋이다.

골든셋은 사내 대표 질문 수십에서 수백 개와 그 정답을 사람이 미리 묶어 둔 평가용 데이터다.
모델이 바뀌거나 프롬프트를 고칠 때마다 이 묶음을 다시 돌려 점수를 비교한다.

채점은 사람이 다 할 수 없다. 그래서 보통 LLM-as-judge를 쓴다. 다른 모델이 정답과 답을 비교해 점수를 매긴다.
정답이 딱 떨어지는 추출과 분류는 자동 채점하고, 서술형은 심사 모델로 나눠 처리한다.

핵심은 같은 셋을 반복해서 돌리는 것이다.
어제 87점이던 게 오늘 79점이면 무언가 나빠졌다는 신호다. 이게 회귀 감지의 출발점이다.

질문·정답 묶음으로 점수를 매긴다
골든셋, 질문 + 정답 묶음
Q1환불 규정 알려줘
정답구매 14일 내 미개봉…통과
Q2연차 며칠 남았어
정답(시스템 조회 후) 7일통과
Q3이 계약서 위험 조항
정답제3조 면책 범위…회귀
87
어제 점수
79
오늘, 떨어졌다
P.03Enterprise LLM · 14

사용자 피드백, 실사용이 골든셋을 채운다

골든셋은 우리가 상상한 질문이다. 진짜 질문은 사용자한테서 온다.

답마다 좋아요/싫어요 버튼, 신고, 정정 요청을 붙여 둔다.
이 신호가 어떤 질문에서 모델이 약한지 알려준다.

싫어요와 신고가 몰린 답은 사람이 검토해서 정답을 단 뒤 골든셋에 추가한다.
그러면 평가셋이 실제 사용 분포에 가까워지고, 같은 실수를 다음 배포 전에 잡게 된다.

피드백은 즉시 고치는 용도가 아니라 데이터를 모으는 채널이다.
상상한 평가인 골든셋과 현장 평가인 피드백, 둘이 돌면서 평가셋이 계속 살아 움직인다.

좋아요·신고가 다음 골든셋이 된다
피드백 → 골든셋 순환
실사용사용자가 답에 좋아요·싫어요·신고를 남긴다
모음싫어요·신고가 몰린 답을 추려낸다
검토사람이 정답을 달아 라벨링한다
추가골든셋에 합류해 평가셋이 커진다

상상한 질문과 현장 질문이 모여 살아 움직이는 평가셋이 된다

P.04Enterprise LLM · 14

대시보드, 한 화면에서 같이 본다

오른쪽이 운영 평가 대시보드다. 노브를 움직이면 세 게이지가 같이 흔들린다.

각 지표엔 목표 임계인 SLO가 걸려 있다.
정확도가 90% 아래로 떨어지거나, 환각률이 5%를 넘거나, p95 지연이 2,500ms를 넘으면 그 게이지가 경보로 바뀐다.

검색 적중률을 낮춰 보면 정확도가 떨어지고 환각이 같이 튄다.
트래픽 부하만 올리면 지연이 먼저 SLO를 넘긴다.
한쪽을 누르면 다른 쪽이 튀는 게 보인다. 그래서 넷을 동시에 봐야 한다는 말이다.

경보는 사람을 부르는 신호다. 임계를 넘으면 알림이 가고, 누군가 원인을 본다. 검색이 빗나갔는지, 부하가 몰렸는지, 모델이 바뀌었는지를 확인한다.

게이지가 SLO를 넘으면 경보가 뜬다
운영 평가 대시보드 · 실시간경보 1
정확도
80%
목표 ≥ 90%
경보
환각률
5%
목표 ≤ 5%
양호
p95 지연
2,090ms
목표 ≤ 2,500ms
양호
정확도 80% < 90%, 검색 근거 점검
운영 상황, 노브를 움직여 본다
어려운 질문 비율30%

복잡한 질문이 많으면 정확도 ↓ · 지연 ↑

검색 적중률80%

RAG 근거가 좋을수록 정확도 ↑ · 환각 ↓

트래픽 부하40%

부하가 높으면 p95 지연 ↑

한쪽을 누르면 다른 쪽이 튄다. 검색 적중률을 낮추면 정확도와 환각이 같이 무너지고, 부하만 올리면 지연이 먼저 SLO를 넘는다. 운영 평가는 이 세 게이지를 동시에 보는 일이다.

P.05Enterprise LLM · 14

관측성, 무너졌을 때 원인을 추적한다

경보가 떠도 어디가 문제인지 추적할 단서가 없으면 고치지 못한다.

그래서 관측성을 깐다.
로그는 무슨 일이 있었는지를 기록한다. 질문, 검색 결과, 답, 지연, 비용이 다 남는다.
트레이스는 한 요청이 검색, 프롬프트 조립, 모델 호출, 후처리를 거치는 전 구간을 단계별 시간으로 이어 준다.

트레이스를 까면 병목이 드러난다.
지연이 튀었으면 어느 단계가 느렸는지, 환각이 났으면 검색이 엉뚱한 문서를 끌어왔는지 한눈에 보인다.

여기에 회귀 감지가 붙는다. 배포 전 골든셋 점수를 자동 비교해, 새 버전이 옛 버전보다 떨어지면 배포를 막는다.
지표로 측정하고, 관측성으로 추적하고, 회귀로 차단하는 세 가지가 한 묶음으로 돌아야 운영이 무너지지 않는다.

Q. 배포할 때 잘 됐는데 왜 운영 중에도 계속 평가해야 하나? (한 번 통과했으면 끝 · 품질과 환각이 시간·데이터에 따라 변한다 · 코드가 안 바뀌어서 · 사용자가 줄어서)정답은 품질과 환각이 시간·데이터에 따라 변한다이다.
코드가 그대로여도 들어오는 질문 분포가 바뀌고, 외부 모델과 검색 인덱스, 사내 문서가 갱신되면서 답의 품질이 흔들린다.
배포 시점에 골든셋을 한 번 통과한 게 다음 달까지 보장되지 않는다.
그래서 골든셋을 주기적으로 다시 돌리고, 실시간 지표와 경보로 흔들림을 잡아채야 한다. 평가는 출시 게이트가 아니라 상시 운영이다.
로그·트레이스로 한 답을 끝까지 따라간다
트레이스, 한 요청의 전 구간2,110ms
검색120ms · 벡터DB 조회
프롬프트 조립30ms · 근거 끼워 넣기
모델 호출1900ms · 토큰 생성, 병목
후처리60ms · 포맷·출처 부착
병목이 어디인지 단계별로 드러난다

3줄 요약

  1. 1품질·환각·관측성 — 운영 중 감시
  2. 2평가·모니터링은 도입 방식 → RAG·연동 → SAP → 보안·거버넌스 → 운영 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

평가

품질·환각·관측성 — 운영 중 감시

RAG

사내 문서를 검색해 답을 보강하는 방식

임베딩

의미를 숫자 벡터로 바꾼 표현