제 프로젝트 중 하나에는 OCR과 VLM의 하이브리드 컴포넌트가 있습니다. 지난 1년 동안, 이 컴포넌트를 위해 정말로 제대로 작동하는 Eval(평가)을 어떻게 만들 것인가에 대해 계속 고민해 왔습니다.

그 과정에서 얻은 가장 큰 배움은 "어떤 Eval을 사용할 것인가"가 아니었습니다. Eval 설계 자체가 하나의 프로덕트 상의 의사결정이라는 점입니다.

이 기사에서는 이 주제에 대해 특히 중요하다고 느낀 사고방식과 배움을 정리해 보겠습니다.

피드백이나 보충할 점이 있다면 꼭 댓글로 알려주세요!

애초에, 왜 Eval이 필요한가

AI 시스템은 기존의 소프트웨어와 같은 방식으로 평가할 수 없습니다.

기존의 소프트웨어는 기본적으로 불리언(Boolean) 값으로 측정할 수 있습니다.

정답은 하나뿐이며, "작동하는가, 작동하지 않는가"로 판단할 수 있기 때문입니다.

하지만 AI 모델은 조금 더 까다롭습니다.

입력이 무한하다. 예를 들어 OCR이라면, 사용자가 찍는 모든 사진을 파악하는 것은 불가능합니다. 커버리지(Coverage)는 어디까지나 샘플일 뿐이며, 망라할 수는 없습니다. -
출력에 변동이 있다. 같은 이미지를 같은 프롬프트(Prompt)로 던져도, OCR에서 반환되는 텍스트가 달라질 수 있습니다. 반대로 temperature를 0으로 설정하는 등 설정을 고정하면, OCR은 상당히 결정적인 동작에 가까워집니다. 이 부분은 "반드시 흔들리는 것"이 아니라, "설정에 따라 흔들리는 것"이라고 이해하는 것이 정확합니다. -
"정답"은 연속적인 스펙트럼이다. OCR이 100개의 항목 중 98개를 올바르게 가져왔다면, 그것은 "틀린 것"이 아니라 "98% 맞은 것"입니다. -
정확도가 자신의 관리 외 요인으로 변할 수 있다. 프로바이더의 모델이나 API의 동작이 변하면, 그것만으로도 정확도가 움직일 수 있습니다.

이러한 성질이 있기 때문에 전용 평가 메커니즘이 필요합니다. 그것이 바로 Eval입니다.

Eval이란 무엇인가

Eval이란 AI 모델의 성능, 정확도, 안전성을 측정하기 위해 구조화된 프로세스를 말합니다.

측정에는 검증된 정답 데이터를 사용합니다.

이를 "골든 세트(Golden Set)" 또는 "그라운드 트루스(Ground Truth, 정답 데이터)"라고 부릅니다.

Eval은 온라인과 오프라인 양쪽 모두에서 실행할 수 있습니다.

오프라인 Eval은 CI 파이프라인에 포함시킵니다.
새로운 코드를 배포하기 전에, 운영 환경에 내보내도 괜찮은 품질인지 체크하는 역할을 합니다.

반면, 온라인 Eval은 운영 환경에서 실시하며, 레이턴시(Latency)나 운영 비용 등을 트래킹(Tracking)합니다.

리그레션 (Regression)의 개념

새로운 모델이 기존 모델의 성능을 떨어뜨릴 가능성도 있습니다.

이를 **리그레션(Regression, 성능 후퇴)**이라고 부릅니다.

Eval을 사용하면 트랙(Track)과 게이트(Gate)라는 두 종류의 메커니즘을 만들 수 있습니다.

트랙은 경향을 계속 기록하기 위한 것입니다. 프로세스를 차단하지는 않습니다.

게이트는 트랙과 달리, CI 내에서 새로운 머지(Merge)의 배포를 차단하기 위한 것입니다.

무엇을 측정할지에 대해서, AI 시스템은 기본적으로 세 가지 축의 균형을 맞출 필요가 있습니다.

레이턴시, 비용, 그리고 아웃풋(Output)의 품질입니다.
이 기사에서는 개별 Eval을 소개하면서 이 세 가지 축에 대해 다루겠습니다.

Eval 루프

Eval은 모델이 운영 환경에서 작동하는 동안 계속해서 돌면서 성장해 나갑니다.

운영 환경에서는 다양한 실패가 표면으로 드러납니다. 할루시네이션(Hallucination), 데이터 누락, 오판단 등입니다.

루프와 같은 형태로, 발생하는 실패를 골든 세트에 추가합니다.

이 흐름은 대략 다음과 같이 진행됩니다.

a. 운영 환경에서 실패가 발생한다.
b. 그 실패를 Eval이 포착하여 라벨(Label)을 붙인다.
c. 그 실패 데이터를 사용하여 초기 데이터셋을 확장해 나간다.
d. 게이트가 더 똑똑해져서 그 실패를 검지할 수 있도록 학습한다.
e. 다음에 같은 실수가 발생했을 때, 게이트는 그것을 차단할 수 있게 된다.

단 한 번의 평가가 아니라, 운영하면서 똑똑하게 만들어가는 것. 이것이 Eval의 핵심입니다.

Eval의 종류

여기서부터는 실제 Eval의 타입을 살펴보겠습니다.

1. 참조 기반의 정확도 평가 (오프라인 / CI 게이트)

사용 시점: 다국어 시스템, 정규화 레이어(Normalization Layer)를 가진 시스템.

이 타입은 정답을 포함한 검증된 데이터셋이 전제됩니다.

지표는 정밀도(Precision), 재현율(Recall), F1 스코어(F1 Score)입니다.

두 문자열을 '일치'한다고 간주하는 기준을 정하는 방식에 따라 몇 가지 방법으로 나뉩니다.

• 정규화 후 완전 일치 (Exact Match). enum이나 구조화된 필드(Boolean 플래그, 카테고리 등)에 적합합니다.
• 퍼지 매칭 (Fuzzy Matching) (RapidFuzz 같은 패키지 활용). 철자의 미세한 차이를 허용합니다. 모델이 엔티티(Entity)의 95% 정도를 추출하는 OCR 환경에서는 대개 이 방법이 가장 적절한 균형점입니다.
• 임베딩 유사도 (Embedding Similarity). 표현에 변동이 있는 경우에 적합합니다. 의미를 기준으로 대조하기 때문입니다. 다만 임베딩 모델 (Embedding Model)이 필요하므로 그만큼의 오버헤드가 발생합니다.
• LLM-as-judge. 정답 데이터가 아직 없을 때 초기 속도를 높일 수 있어 시작 단계에서는 좋지만, 기본적으로 인간의 더블 체크가 필요합니다. '간편한 출발점'인 동시에 '실제 운영 판정을 완전히 맡기기에는 약하다'는 점을 인지하고 사용하는 것이 좋습니다.

예를 들어, 일본어 단어를 영어 용어에 매핑하는 정규화 레이어 (Normalization Layer)가 있고 그것이 고장 났다고 가정해 봅시다. 이 Eval은 그 고장을 감지해 줍니다.

2. 비전 분류를 위한 가드레일 (Guardrails)

사용 사례: 콘텐츠 모더레이션 (Content Moderation), 범위 외 / 분포 외 (Out-of-distribution) 감지, PII 감지, 스팸 필터, 이미지 품질 게이트, 라우팅용 분류기.

제가 운영하는 멀티 에이전트 (Multi-agent) 구성의 프로덕트에서는 모든 에이전트가 텍스트를 생성하는 것은 아닙니다.

일부는 '입력이 범위 내에 있는지' 또는 '어떤 경로를 통과할지'와 같은 판단을 수행합니다.

이는 생성기가 아니라 분류기 (Classifier)입니다. 따라서 평가 방식도 달라집니다.

여기서 측정하는 것은 분류 정확도와 혼동 행렬 (Confusion Matrix)입니다.

이 Eval의 요소는 다음과 같습니다.

Tier-1: 픽셀 게이트 (Pixel Gate). 결정론적이며, 비용이 들지 않고, 오프라인에서 작동합니다. 너무 어둡거나, 너무 밝거나, 완전히 하얗거나, 흐릿하거나, 읽을 수 없는 이미지 등을 걸러냅니다. 이를 통해 비용과 시간을 절약할 수 있습니다.

Tier-2: 분류기 (Classifier). 모델이 어차피 수행할 VLM 호출 내에 통합합니다 (따라서 추가 비용은 없습니다). content_accuracy, side_accuracy, confidence를 반환합니다.

임계값 캘리브레이션 (Threshold Calibration). Tier-1이 '얼마나 어두워야 너무 어두운 것인지'를 마법처럼 알고 있는 것은 아닙니다.

단순히 휘도를 0~255 범위로 수치화하는 것이므로 튜닝이 필요합니다.

이 Eval은 임계값이나 이미지 전처리 과정에 도입된 변경 사항을 감지합니다.

3. 온라인 Eval: 운영 환경의 옵저버빌리티 (Observability)

이것은 'Ops/Eval'에서 말하는 'Ops' 측면의 이야기입니다.

옵저버빌리티는 크게 세 가지 요소로 구성됩니다.

• 메트릭 (Metrics). 시계열의 단순 집계입니다 (카운트, 실행 시간, 합계 등).
• 트레이스 (Trace). 요청(Request) 하나하나의 흐름입니다. 어떤 노드가 어떤 순서로, 얼마나 많은 시간 동안 작동했는지를 나타냅니다. LangSmith를 사용하면 쉽게 추출할 수 있습니다.
• 로그 (Logs). 나중에 조사하기 위한 구조화된 이벤트 기록입니다.

전형적인 스택은 다음과 같습니다. /metrics 엔드포인트로 메트릭을 내보내면, Prometheus가 이를 스크레이핑(Scrape)하여 시계열로 가져오고, Grafana가 대시보드를 그리는 흐름입니다.

여기서 측정할 수 있는 메트릭은 매우 다양합니다.

• 스캔 수 (초당 / 분당)로 트래픽 양 추적
• status="error" / 전체 스캔 수로 에러율 산출
• 상태별 내역: 스캔이 어떻게 종료되었는지 ( ok, error, rejected (비전 게이트), escalated 등 직접 정의한 상태) 확인. "비전 게이트가 스캔의 40%를 차단하고 있다"라거나 "배포 후 에러가 급증했다"와 같은 상황을 파악할 수 있는 곳이 바로 여기입니다.
• 에스컬레이션 (Escalation) 횟수
• 스캔 각 노드의 실행 시간
• LLM 에이전트의 토큰 비용
• 스캔 1회당 총 비용

4. 레이턴시 (Latency)와 비용

지금까지의 Eval은 운영 (온라인)과 품질 (오프라인)을 다루었습니다.

또 하나 빠질 수 없는 것이 비용과 속도에 대한 벤치마크입니다.

이들은 분포 (Distribution) 형태로 보고합니다. LLM에서 자주 사용하는 지표는 다음과 같습니다.

• TTFT (Time To First Token). 프롬프트를 보내고 나서 첫 번째 토큰이 반환될 때까지의 시간.
• E2E. 응답 완료까지의, 처음부터 끝까지 소요되는 시간.
• TPOT / ITL (Time Per Output Token / 토큰 간 레이턴시 (Inter-token Latency)). 첫 번째 토큰 이후의 생성 속도.
• TPS (Tokens Per Second). 처리량 (Throughput).
• RPS (Requests Per Second). 완료된 요청 수 / 총 초 단위 시간으로 측정하는 시스템의 처리 능력.

각각 p50 (중앙값), p95 (SLA에서 자주 사용), p99 (최악의 경우)의 백분위수 (Percentile)로 보고합니다.

측정 방법은 몇 가지가 있습니다.

• 부하 테스트용 하네스 (Load Testing Harness) (Locust, k6, vegeta). 대량의 동시 요청을 보내서, 포화 상태에서의 처리량 (Throughput)과 레이턴시 (Latency)를 측정합니다. 얼마나 많은 사용자를 처리할 수 있는지 확인하기 위한 것입니다.
• 리플레이 측정 벤치마크 (Replay Measurement Benchmark). 고정된 세트를 한 번 실행하여, 시간당 토큰 수와 실행 시간을 기록하고 그 분포를 산출합니다.
• 클라이언트 측 실측 시간 vs 서버 측 메트릭 (Client-side Measured Time vs Server-side Metrics). 클라이언트 측에는 네트워크와 큐잉 (Queuing)이 포함됩니다 (사용자가 체감하는 것). 서버 측은 계산 처리만을 분리합니다 (본인이 최적화할 수 있는 것).

레이턴시 (Latency)에는 한 가지 주의할 점이 있습니다. 이는 게이트 (Gate)가 아니라 트래킹 (Tracking)으로 다루어야 한다는 것입니다.

레이턴시는 부하, 네트워크, 머신 등 여러 요인에 좌우되므로 비결정적 (Non-deterministic)인 지표이기 때문입니다.

더욱 고도화된 Eval 기법도 있습니다.

예를 들어 eval-diff의 PR 봇이나 nightly canary (nightly canary) 등이 있습니다.

다만, 이것들을 제대로 다루려면 개별적인 글이 필요하므로, 다른 글로 넘기겠습니다. 🙇‍♂️

Discussion