지속적 평가 처리 과정 구축
LLM-as-judge 평가를 CI/CD 처리 과정에 통합하여, 배포 전에 모든 프롬프트 또는 모델 변경 사항을 회귀 시험 모음으로 자동 평가합니다.
지속적 평가 처리 과정 구축은(는) CoddyKit의 무료 AI Engineering Academy 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AI Engineering Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
평가를 지속적으로 수행해야 하는 이유
배포 시 한 번만 평가하는 것으로는 충분하지 않습니다. LLM 품질은 조용히 저하될 수 있습니다. 모델 제공업체가 모델을 업데이트하고, 시스템 프롬프트 변경이 반영되며, 문서 모음이 커지면서 검색 품질이 변하고, 시간에 따라 사용자 질문 분포도 달라집니다. 지속적 평가 파이프라인은 모든 변경 사항과 정해진 일정에 따라 동일한 평가 모음을 실행하므로 품질 회귀를 몇 주가 아니라 몇 시간 안에 발견할 수 있습니다.
파이프라인의 핵심 구성 요소
지속적 평가 파이프라인은 다섯 가지 구성 요소로 이루어집니다. 테스트 데이터 세트(예상 출력이 포함된 선별된 질문), 시스템 실행기(각 테스트 질문에 대해 LLM 파이프라인을 호출), 평가자(각 응답에 점수 부여), 결과 저장소(과거 측정값을 저장하는 데이터베이스 또는 시계열 저장소), 보고 계층(대시보드와 알림)입니다. 각 구성 요소는 서로 독립적으로 업그레이드할 수 있습니다.
# Pipeline architecture:
#
# test_dataset.json
# |
# v
# system_runner.py --> calls your LLM pipeline
# |
# v
# judge.py --> scores each (question, answer) pair
# |
# v
# results_db --> stores timestamped metric history
# |
# v
# dashboard + alert --> Grafana / Slack notification테스트 데이터 세트 구성
평가 테스트 세트를 버전이 관리되는 JSON 또는 YAML 파일로 저장소에 저장하십시오. 각 항목에는 질문, 범주(사실적, 절차적, 범위 외), 선택적 참조 답변이 포함됩니다. 테스트 세트는 코드와 별도로 버전을 관리하십시오. 새로운 테스트 사례를 추가하는 것은 이전 버전과 호환되는 변경이지만, 사례를 제거하면 회귀를 숨길 수 있습니다. 관련된 모든 범주에 걸쳐 200~500개의 사례를 목표로 하십시오.
# eval/test_set_v3.json
# {
# 'version': '3.0',
# 'created': '2026-06-01',
# 'cases': [
# {
# 'id': 'faq_001',
# 'category': 'factual',
# 'question': 'What is the cancellation policy?',
# 'reference': 'Cancellations must be made 24 hours in advance.',
# 'min_correctness': 4
# },
# ...
# ]
# }평가 모음 실행
평가 실행기는 각 테스트 사례에 대해 운영 시스템(또는 스테이징 버전)을 호출하고 응답과 메타데이터를 기록합니다. 각 평가 실행에 고유한 실행 ID, 실행을 유발한 커밋 SHA, 타임스탬프, 테스트 세트 버전을 태그로 지정하십시오. 그러면 실행 결과를 정확히 비교하고 어떤 코드 변경으로 회귀가 발생했는지 진단할 수 있습니다.
import asyncio
import uuid
from datetime import datetime
async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
run_id = str(uuid.uuid4())
results = []
for case in test_set:
response = await system.answer(case['question'])
score = await judge(case['question'], response, case.get('reference'))
results.append({
'run_id': run_id,
'commit_sha': commit_sha,
'case_id': case['id'],
'category': case['category'],
'response': response,
'score': score.model_dump(),
'evaluated_at': datetime.utcnow().isoformat()
})
return {'run_id': run_id, 'results': results}과거 측정값 저장 및 조회
모든 평가 실행 결과를 데이터베이스에 영구 저장하십시오. run_id, commit_sha, case_id, score 필드가 있는 간단한 eval_results 테이블이면 충분합니다. run_id별 집계 점수를 조회하여 실행별 측정값을 계산하십시오. 현재 실행을 main 브랜치의 마지막 성공 실행과 비교하여 회귀를 감지하십시오. InfluxDB와 같은 시계열 데이터베이스는 지속적 모니터링에 적합합니다.
-- PostgreSQL schema
CREATE TABLE eval_runs (
run_id UUID PRIMARY KEY,
commit_sha TEXT NOT NULL,
test_set_version TEXT NOT NULL,
triggered_by TEXT, -- 'ci', 'scheduled', 'manual'
started_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE eval_results (
id SERIAL PRIMARY KEY,
run_id UUID REFERENCES eval_runs(run_id),
case_id TEXT NOT NULL,
category TEXT,
correctness INT,
overall INT,
response TEXT
);
CREATE INDEX idx_run_id ON eval_results(run_id);회귀 자동 감지
각 평가 실행이 끝나면 집계 점수를 기준선(수동으로 승인된 main 브랜치의 마지막 실행)과 비교하십시오. 회귀는 다음과 같이 정의합니다. 어떤 점수 차원이든 기준선보다 5% 넘게 하락하거나, 어떤 범주의 평균 점수든 엄격한 최저 기준보다 낮아지는 경우입니다. 회귀가 발생하면 배포를 차단하고 팀에 알림을 보내야 합니다. 개선 사항은 자동으로 승인할 수 있습니다.
def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
regressions = []
for metric in ['correctness', 'helpfulness', 'clarity']:
delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
if delta_pct < -threshold_pct:
regressions.append({
'metric': metric,
'baseline': baseline[metric],
'current': current[metric],
'delta_pct': round(delta_pct, 1)
})
return {'has_regression': len(regressions) > 0, 'regressions': regressions}CI/CD 통합
모든 PR에서 실행되는 CI 단계로 평가 모음을 추가하십시오. CI 파이프라인은 스테이징 시스템을 호출하고, 평가자를 실행하고, 결과를 저장하고, 회귀를 확인합니다. 회귀가 감지되면 CI 단계가 실패하여 PR 병합을 차단합니다. GitHub 또는 GitLab에서 이를 필수 상태 확인으로 추가하여 누구도 우회할 수 없게 하십시오. PR 확인에서는 50~100개의 사례 하위 집합을 사용하여 평가 실행 시간을 10분 이내로 유지하십시오.
# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
# eval:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v4
# - name: Run eval suite
# run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
# env:
# OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
# - name: Check for regressions
# run: python eval/check_regression.py --run-id $EVAL_RUN_ID예약된 전체 평가 실행
PR 확인 외에도 매일 운영 환경을 대상으로 전체 평가 모음(300개 이상의 모든 사례)을 실행하십시오. 이렇게 하면 단일 변경으로는 발생하지 않는 점진적인 품질 변화를 포착할 수 있습니다. 예를 들어 문서가 추가될수록 벡터 데이터베이스의 재현율이 저하되거나, LLM 제공업체가 모델을 조용히 업데이트하는 경우입니다. 매일 전체 실행을 수행하면 추세를 한눈에 볼 수 있는 품질 시계열이 만들어집니다.
# Separate eval modes:
EVAL_CONFIGS = {
'pr_check': {
'test_cases': 'eval/test_set_core_100.json',
'target': 'staging',
'max_runtime_min': 8
},
'nightly': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'max_runtime_min': 30
},
'weekly_deep': {
'test_cases': 'eval/test_set_full_350.json',
'target': 'production',
'include_pairwise': True,
'max_runtime_min': 90
}
}품질 저하 알림
측정값 추세가 경고 임계값과 심각 임계값을 넘을 때 알림이 발생하도록 구성하십시오. 지난 7일 동안 평균 정확도가 3% 하락하면 경고를 발생시킵니다. 단일 실행에서 10% 하락하면 즉시 알림을 보냅니다. 경고는 팀 Slack 채널로, 심각한 알림은 PagerDuty로 전달하십시오. 모든 알림 메시지에 회귀 분석, 평가 대시보드 링크, 최근 변경 사항에 대한 git blame을 포함하십시오.
import httpx
def send_regression_alert(regression_report: dict, webhook_url: str):
regressions = regression_report['regressions']
blocks = [{
'type': 'section',
'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
}]
for r in regressions:
blocks.append({
'type': 'section',
'text': {'type': 'mrkdwn',
'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
})
httpx.post(webhook_url, json={'blocks': blocks})테스트 세트 확장 관리
실제 운영 환경의 실패 사례를 바탕으로 테스트 세트를 지속적으로 확장하십시오. 사용자가 잘못된 응답을 신고하면 해당 질문을 필요에 따라 익명화하여, 사람이 확인한 예상 답변과 함께 테스트 세트에 추가하십시오. 이렇게 하면 평가 모음이 가상의 사례가 아니라 실제 사용자 요구를 반영하게 됩니다. 테스트 세트를 계속 갱신되는 문서로 취급하고, 분기마다 검토하여 오래된 사례를 제거하십시오.
def add_to_test_set(question: str, reference_answer: str, category: str,
source: str, test_set_path: str):
import json, uuid
with open(test_set_path, 'r') as f:
test_set = json.load(f)
test_set['cases'].append({
'id': f'user_report_{uuid.uuid4().hex[:8]}',
'category': category,
'question': question,
'reference': reference_answer,
'source': source, # 'user_report', 'regression', 'manual'
'added': '2026-06-21'
})
with open(test_set_path, 'w') as f:
json.dump(test_set, f, indent=2)시간에 따른 품질 추세 시각화
주요 측정값을 시간에 따라 표시하는 간단한 품질 대시보드를 구축하십시오. 표시할 항목으로는 평균 정확도 점수, 캐시 적중률, p95 지연 시간, 쿼리당 비용이 있습니다. 표본 수가 적어 발생하는 잡음을 완화하려면 주간 이동 평균을 사용하십시오. 추세 차트를 사용하면 품질 변화를 즉시 확인할 수 있습니다. 6주 동안 점진적으로 3% 하락하는 현상은 개별 실행 보고서에서는 보이지 않지만 시계열 차트에서는 분명하게 드러납니다. Grafana나 간단한 Python matplotlib 스크립트를 사용해도 충분합니다.
import matplotlib.pyplot as plt
import pandas as pd
def plot_quality_trend(eval_history: list):
df = pd.DataFrame(eval_history)
df['date'] = pd.to_datetime(df['evaluated_at'])
df = df.sort_values('date')
# 7-day rolling average
df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
plt.figure(figsize=(12, 4))
plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
plt.legend()
plt.title('LLM Answer Quality Over Time')
plt.savefig('quality_trend.png')빠른 확인
LLM 애플리케이션의 지속적 평가 파이프라인에 대한 이해도를 확인하십시오.
학습 내용 요약
이 학습에서는 다음을 배웠습니다. 지속적 평가 파이프라인은 모든 PR과 매일 정해진 일정에 따라 자동 품질 확인을 실행하여 회귀를 조기에 발견합니다. 회귀 감지는 현재 점수를 기준선과 비교하고 품질이 하락하면 배포를 차단합니다. 또한 실제 실패 사례를 통한 테스트 세트 확장은 평가 모음이 실제 사용자 요구에 기반을 두도록 합니다. 다음 학습에서는 에이전트 실패 유형을 분류하고 복구 전략을 설계합니다.
AI 튜터와 함께 Python을(를) 배우세요 — 무료
브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.
- 코스
- 30
- 레슨
- 120
자주 묻는 질문
“지속적 평가 처리 과정 구축” 강의는 무료인가요?
네 — “지속적 평가 처리 과정 구축” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AI Engineering Academy 강의 전체를 잠금 해제할 수 있습니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“지속적 평가 처리 과정 구축”에서 뭘 배우나요?
LLM-as-judge 평가를 CI/CD 처리 과정에 통합하여, 배포 전에 모든 프롬프트 또는 모델 변경 사항을 회귀 시험 모음으로 자동 평가합니다. 브라우저에서 직접 실행하는 실습 코드로 AI Engineering Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
AI Engineering Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 AI Engineering Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.
“지속적 평가 처리 과정 구축” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 AI Engineering Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 AI Engineering Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- LLM을 평가자로 사용하는 패턴
- 점별 평가와 쌍별 평가
- 평가자 모델을 사람의 판단에 맞게 보정
- 지속적 평가 처리 과정 구축