LLM evaluation harness — 분기마다 챗봇 품질을 자동 평가하는 공장
챗봇·에이전트가 운영에 들어가면 한 번 평가가 아니라 분기 자동 평가가 필요합니다. 골든셋·regression·hyperparameter A/B를 묶는 evaluation harness 설계와 마케팅 자리에서의 적용.
RAG 챗봇·LLM 에이전트가 운영에 들어가면 한 번 평가하고 끝이 아닙니다. 모델 버전이 바뀌고, 프롬프트가 다듬어지고, 새 컨텍스트가 추가될 때마다 품질이 흔들립니다. evaluation harness는 분기마다 자동으로 모든 변화를 점검하는 공장이고, 사내 챗봇 품질의 운영 안정성을 결정합니다.
마케터가 이 글을 읽어야 하는 이유: 사내 RAG 챗봇·자동화 에이전트가 점점 늘어나는데, 그 품질이 분기마다 어떻게 변하는지 추적이 안 되면 사고가 사용자 보고로만 발견됩니다. evaluation harness는 그 사고를 사전 알림으로 잡는 표준 도구이고, 마케터·운영자가 도구의 골격을 알면 어떤 자리에 도입해야 할지 결정 가능.
1. Evaluation harness의 한 줄 직관
골든셋(질문·기대 답변 묶음)을 입력으로, 여러 LLM 설정(모델·프롬프트·컨텍스트)을 자동 실행하고, 결과 점수를 비교 가능한 형태로 저장하는 시스템.
수동 평가의 한계:
- 사람이 매번 50개 답변을 읽어 점수 매기기 → 분기 1회도 어려움
- 모델·프롬프트 변경마다 처음부터 다시 → 비교 불가능
- 결과가 한 번 보고 사라짐 → 추세 추적 불가
harness는 이 세 가지를 자동화합니다.
2. 4가지 핵심 컴포넌트
2-1. 골든셋(golden set)
질문·기대 답변·컨텍스트의 묶음. 50-200개가 표준. 분기마다 갱신.
| 필드 | 의미 |
|---|---|
| question | 사용자 질문 |
| expected_answer | 기대 답변 또는 핵심 fact |
| context_docs | 답변에 필요한 문서 ID |
| difficulty | easy/medium/hard |
| category | 도메인 분류 (FAQ, 데이터 조회, 액션 등) |
2-2. 실행 엔진(runner)
여러 LLM 설정을 병렬로 실행. 같은 골든셋을 GPT-5 vs Claude Sonnet에 동시 투입해 비교.
2-3. 점수 매기기(scorer)
Ragas 같은 라이브러리로 4개 지표 자동 계산:
- Context relevance
- Context recall
- Faithfulness
- Answer relevance
2-4. 결과 저장·비교(tracker)
각 실행의 결과를 SQL·JSON·MLflow에 저장. 분기 추세·configuration 비교가 자동.
3. 데이터 플로우 표준 흐름
골든셋 (50-200개 질문) │ ▼실행 엔진 — N개 configuration 병렬 ├ GPT-5 + 프롬프트 v1 ├ GPT-5 + 프롬프트 v2 ├ Claude Sonnet + 프롬프트 v1 └ Claude Sonnet + 프롬프트 v2 │ ▼점수 매기기 — 4지표 × N config │ ▼결과 비교 표 config × 지표 매트릭스 │ ▼회귀 비교 — 지난 분기 결과 vs 이번 분기 │ ▼보고 생성 (자동)이 한 흐름이 마케팅 챗봇의 분기 품질 보고를 자동화.
4. 코드 한 묶음 — Pytest 스타일 harness
이게 글에 박는 유일한 코드입니다.
import jsonimport pytestfrom ragas import evaluatefrom ragas.metrics import faithfulness, answer_relevancy, context_relevancy
# 골든셋 로드with open("golden_set.json") as f: GOLDEN = json.load(f) # 50개 {question, expected, contexts, difficulty}
# Configuration 매트릭스CONFIGS = [ {"model": "gpt-5", "prompt": "v1"}, {"model": "gpt-5", "prompt": "v2"}, {"model": "claude-sonnet-4-6", "prompt": "v1"},]
@pytest.mark.parametrize("config", CONFIGS)def test_golden_set(config): """각 config로 골든셋 전체 실행 + 점수 검증.""" answers = [run_chatbot(item["question"], **config) for item in GOLDEN] df = pd.DataFrame({ "question": [g["question"] for g in GOLDEN], "answer": answers, "contexts": [g["contexts"] for g in GOLDEN], "ground_truth": [g["expected"] for g in GOLDEN], }) scores = evaluate(df, metrics=[faithfulness, answer_relevancy, context_relevancy]) # 분기 baseline 대비 5%p 이상 떨어지면 fail assert scores["faithfulness"] >= LAST_QUARTER_BASELINE - 0.05 save_to_tracker(config, scores)이 한 묶음이 evaluation harness의 골격. CI에 묶어서 매번 실행하면 자동 회귀 보호.
5. 마케팅 자리의 적용 4가지
5-1. RAG 챗봇 품질 추적
분기마다 골든셋 50개 실행 → 4지표 변화 추적. faithfulness 0.85 → 0.78로 떨어졌으면 모델·프롬프트·문서 변화 의심.
5-2. 모델 비교 (GPT-5 vs Claude)
같은 골든셋을 두 모델에 돌려 비용 대비 품질 비교. LLM token economics 결합으로 ROI 계산.
5-3. 프롬프트 A/B
새 시스템 프롬프트 도입 전 골든셋으로 ON/OFF 비교. 5%p 이상 개선되면 production 도입.
5-4. 컨텍스트 변경의 영향
문서·컨텍스트 길이 변경이 답변 품질에 어떻게 영향을 주는지 자동 측정. context engineering 결정의 근거.
| 자리 | harness 출력 |
|---|---|
| 분기 품질 추적 | 4지표 추세 |
| 모델 비교 | 비용·품질 매트릭스 |
| 프롬프트 A/B | before/after 5%p 차이 |
| 컨텍스트 실험 | 길이별 품질 변화 |
6. 골든셋 운영 룰 5가지
골든셋 자체가 살아있는 데이터입니다.
6-1. 분기마다 갱신
새 사용자 질문 패턴·새 도메인 영역을 추가. 오래된 질문은 유지하되 평균 30%는 분기마다 새로.
6-2. 다양성 강제
RAG 평가에서 다룬 4분면(사실형/해석형 × 단순/복합) 균등 분배.
6-3. 실패 케이스 우선 보존
지난 분기 사용자가 👎 했던 질문·환각이 났던 질문은 골든셋에 보존. 같은 사고 재발 방지.
6-4. 라벨링 책임자 명시
각 골든셋 항목에 “정답 작성자” 필드. 도메인 변화 시 추적 가능.
6-5. 외부 검증
분기에 한 번 사람 평가자가 LLM-as-judge 점수와 일치도 확인. 일치도 0.8 이하면 골든셋 또는 평가자 모델 점검.
7. 분기 보고에 박을 표 양식
분기 챗봇 품질 보고의 표준.
| Configuration | Faithfulness | Recall | Relevance | 지난 분기 대비 |
|---|---|---|---|---|
| GPT-5 + 프롬프트 v3 (현재) | 0.91 | 0.88 | 0.85 | +0.04 / +0.02 / +0.01 |
| GPT-5 + 프롬프트 v2 | 0.86 | 0.85 | 0.83 | (이전) |
| Claude Sonnet 4.6 + v3 | 0.93 | 0.86 | 0.87 | 신규 |
| GPT-5-mini + v3 | 0.79 | 0.82 | 0.78 | 비용 1/10, 품질 8%p 낮음 |
이 표가 회의에서 모델·프롬프트 결정의 입력. “Claude Sonnet으로 교체 검토” 같은 결정이 데이터로.
8. 마치며 — 챗봇 품질의 운영 인프라
LLM 자동화가 운영의 표준 도구가 되면 evaluation harness가 그 인프라의 핵심이 됩니다. 골든셋·실행 엔진·점수 매기기·결과 추적 4개 컴포넌트가 묶이면 모델·프롬프트가 바뀔 때마다 자동으로 품질이 점검되고, 사고가 사용자 보고보다 먼저 발견됩니다. 마케터가 그 골격을 알면 사내 챗봇 도입의 운영 신뢰도를 분기 단위로 관리 가능.
다음 분기에 한 번만 시도해 볼 만한 것은 가장 큰 LLM 자동화 한 자리에 골든셋 50개를 작성하고 분기 1회 자동 실행을 CI에 넣는 흐름입니다. 그 한 자리에서 운영 사고의 절반이 사라지는 케이스가 흔합니다.
다음에 읽을 글
- RAG 평가 — 4가지 평가 지표
- LLM token economics — 비용·품질 매트릭스
- Context engineering — 컨텍스트 변경 실험
참고
- Ragas: https://docs.ragas.io/
- “LLM evaluation harness” (EleutherAI): https://github.com/EleutherAI/lm-evaluation-harness
- LangSmith: https://docs.smith.langchain.com/
- Langfuse: https://langfuse.com/
- “Trustworthy LLM evaluation” (Anthropic): https://www.anthropic.com/research
AI·LLM 카테고리의 다른 글
전체 보기 →-
2026·05·16
LLM 운영 비용 폭주를 막는 6가지 guardrail — 마케팅 자동화의 cost·latency·품질 동시 관리
LLM을 운영에 올리면 어느 날 갑자기 비용이 10배로 튑니다. retry storm·프롬프트 폭증·모델 자동 승격·context 누적 등 폭주 패턴 6가지와 그것을 막는 guardrail을 정리합니다.
-
2026·05·09
Context engineering — 200k 토큰 컨텍스트의 설계 원칙 5가지
컨텍스트 창이 200k 토큰까지 커졌지만 단순히 다 넣으면 lost-in-the-middle·비용 폭발·정확도 하락이 옵니다. 마케팅 자동화에 적용하는 5가지 컨텍스트 설계 원칙.
-
2026·05·09
Function calling 설계 패턴 — LLM이 도구를 부를 때 마케터가 점검할 것
LLM이 광고 API·BigQuery·Slack을 직접 부르기 시작하면, 답변 품질보다 "어느 도구를 언제 부를지"가 운영 사고의 진앙이 됩니다. function calling의 한 줄 직관과 마케터가 점검할 5가지.
-
2026·05·09
LLM token economics — 자동화의 단위 경제학을 분기 보고로 끌고 가기
LLM 자동화의 비용은 호출 수 × 입력 토큰 × 단가로 빠르게 커집니다. 호출별 비용·일일 합계·모델별 단위 경제학을 분기 보고에 박는 한 가지 표 양식.