16.3 평가 메트릭 설계 (BLEU, ROUGE, human eval 등)
Chapter 16.3 평가 메트릭 설계 (BLEU, ROUGE, human eval 등)
OpenAI API 기반 서비스를 개발할 때, 성능 향상을 위한 지속적인 개선과 테스트는 필수 요소입니다. 이를 위해서는 명확한 평가 지표(metric)를 설계하고, 이를 기반으로 주기적인 A/B 테스트와 피드백 루프를 운영해야 합니다. 이 절에서는 생성형 AI 시스템 — 특히 언어 모델 기반 애플리케이션의 성능을 객관적이고 일관되게 측정하기 위한 대표적인 평가 메트릭들(BLEU, ROUGE, Human Evaluation 등)을 살펴보고, 각각의 장단점, 활용 사례, 실전 적용 방법에 대해 설명합니다.
📌 그 목적은 단 하나입니다: "[모델이 얼마나 '좋은' 출력을 내고 있는가?]"를 측정하는 기준을 만드는 것.
—
🔍 16.3.1 정량 평가 vs 정성 평가: 자동 평가의 한계와 인간 평가의 중요성
생성형 AI 과업은 정답이 명확히 정해지지 않은 경우가 많으며, 따라서 평가 기준도 전통적인 분류/회귀 모델처럼 단일한 정답 기반 정확도(accuracy)로 측정하기 어렵습니다. 평가 메트릭은 다음 두 가지 방식으로 나눌 수 있습니다:
정량 평가 (Automatic Evaluation)
BLEU, ROUGE, METEOR, BERTScore 등
일반적으로 기준 정답(reference)과 모델 출력(prediction)의 유사도를 측정
정성 평가 (Human Evaluation)
휴먼 저지를 통한 출력의 품질, 정확성, 일관성, 유용성 등을 직접 평가
비용과 시간이 많이 들지만 신뢰도가 매우 높음
⇒ 일반적으로는 두 가지를 병행하여 사용하는 것이 이상적입니다.
—
🔷 16.3.2 BLEU (Bilingual Evaluation Understudy)
BLEU는 기계 번역 평가를 위해 고안된 가장 유명한 자동 평가 지표 중 하나입니다. 번역 결과가 기준 정답(reference)와 얼마나 일치하는지를 정량적으로 측정합니다.
핵심 개념: n-gram precision (모델 출력의 n-gram이 얼마나 참조문에 포함되어 있는지)
튜닝 요소: unigram, bigram, trigram, 4-gram
Precision 중심이며, brevity penalty를 통해 너무 짧은 출력에 페널티를 부여함.
예시: Reference: “The cat is on the mat.” Candidate1: “The cat the cat on the mat.” Candidate2: “The cat is on the mat.”
Candidate1은 반복이 있으나 n-gram이 일치 → 높은 precision, 하지만 brevity penalty로 점수 손실 Candidate2는 완벽히 동일 → 높은 BLEU 점수
장점:
계산이 간단하고 직관적
여러 기준 정답(reference)을 받을 수 있음
한계:
의미 유사보다는 표면적 단어 일치에 기반함
언어적 다양성과 문맥 반영 부족, 한국어 평가에는 부적합할 수 있음
—
🔶 16.3.3 ROUGE (Recall-Oriented Understudy for Gisting Evaluation)
ROUGE는 텍스트 요약 등에서 자주 사용되는 메트릭으로, 생성된 텍스트가 참조 요약과 얼마나 단어 수준에서 일치하는지를 측정합니다.
핵심 개념: n-gram recall (참조 요약의 n-gram이 생성된 요약에 포함되어 있는 비율)
대표 지표: ROUGE-N (n-gram 기반), ROUGE-L (Longest Common Subsequence), ROUGE-S (Skipping bigram)
예시: Reference: “He went to the store to buy milk.” Candidate: “He drove to the supermarket to get milk.”
→ 일부 n-gram은 겹치나 구체적 표현 다름 → ROUGE 점수는 낮을 수 있음
장점:
요약 작업의 Recall 중심 평가에 적합
여러 기준 정답 비교 가능
한계:
단어 표현이 다른 경우 점수 낮아짐
길이가 짧거나 문체가 다른 경우 정확도 저하
✅ BLEU는 Precision 위주, ROUGE는 Recall 위주 → 둘을 함께 보는 것이 바람직
—
🔵 16.3.4 METEOR, BERTScore, BLEURT 등 최신 메트릭
BLEU/ROUGE는 단순한 단어 비교 기반이므로 의미적 유사성(Semantic Similarity)까지 반영하긴 어렵습니다. 이를 보완한 다음과 같은 최신 메트릭들도 많이 사용됩니다.
🚀 METEOR (Metric for Evaluation of Translation with Explicit ORdering)
Synonym/Stemmed word 허용 (WordNet 기반)
가중치 조정 및 재배열 고려
BLEU보다 Correlation with human judgment가 높음
🚀 BERTScore
Transformer(BERT) 기반 문장 임베딩 사용 → 의미적 유사도(Semantic Similarity) 계산
Precision/Recall/F1 모두 측정 가능
“의미는 같지만 표현이 다른 문장”도 높은 점수를 받을 수 있음
🚀 BLEURT (BERT + fine-tuned regression)
BERT 기반 모델을 미리 인간 평가 점수로 학습시켜, 입력쌍(reference, candidate)에 대해 출력 품질 점수를 예측
Human 평가와 상관관계가 가장 높음으로 알려짐 (다만 fine-tuned된 pre-trained model 필요)
—
🧑⚖️ 16.3.5 Human Evaluation의 구성과 운영 방법
자동 메트릭은 간편하지만 실제 사용자 반응을 대변하긴 어렵습니다. 특히 QA 시스템, 대화형 에이전트, 창의적 생성물(에세이, 요약 등)에서는 Human Evaluation이 반드시 병행되어야 합니다.
평가 항목 설계
정확성(Factuality): 생성된 응답이 사실에 부합하는가?
유용성(Usefulness): 사용자 질문에 적절하게 답했는가?
일관성(Coherence): 문장이 논리적이고 연결이 매끄러운가?
간결성(Conciseness): 불필요하게 장황하지 않은가?
스타일/톤 적합성: 맥락에 맞는 말투와 표현인가?
평가자 구성
내부 도메인 전문가: 세부적 사실성과 정밀성 평가
일반 사용자: 자연스러움과 유용성 평가
Crowd-sourcing (Amazon MTurk, Scale AI 등) 활용 가능
스킴(Scheme) 설계
상대적 평가 (A/B 비교): 두 응답 중 어떤 것이 낫습니까?
절대적 평가 (Likert Scale): 1~5점 척도로 평가
블라인드 평가: 평가 대상에 모델 정보 숨김
평가 품질 관리
Inter-Annotator Agreement (Cohen's Kappa, Fleiss' Kappa)
평가자 교육 및 기준 일치화 가이드 제작
📌 팁: 적은 평가 데이터(200~500개)로도 모델 성능 추세 확인 가능 📌 팁: 구글 문서, Airtable, Excel Sheet 기반의 Human Eval Tool 만들기
—
🔁 16.3.6 실전 적용 예시
이메일 자동 작성기
메트릭: BERTScore + Human(유용성, 문체)
금기어 포함 여부 등 커스텀 평가 항목 필수
문서 요약 시스템
메트릭: ROUGE-L, BERTScore
Human: 사실 왜곡 유무, 요약 누락 체크
교육용 Q&A 챗봇
메트릭: BLEU + Answer accuracy (정답템플릿 기반)
Human: 명료성, 온화한 톤, 아동 친화성 평가 포함
—
📊 16.3.7 평가 메트릭 통합 전략
자동 + 휴먼 평가를 병행하여 정량/정성 잣대를 모두 확보
BLEU/ROUGE는 학습/튜닝 단계에 자주 사용
BERTScore/BLEURT는 최종 품질 확인에 적합
Human Eval은 프로덕션 전 must-have!
—
⛳️ 마무리 요약
자동화된 평가 메트릭은 빠르고 일관되지만 의미를 완전히 반영하지는 못함
고성능 서비스를 위한 Human Evaluation은 비용이 들더라도 꼭 진행해야 함
평가 항목 설계는 서비스 목적에 따라 유연하게 구성하되, 일관된 기준을 유지해야 함
BLEU → 번역 정밀도 / ROUGE → 요약 누락 정도 / BERTScore → 의미 유사성 / Human → 진짜 사용자 기준!
다음 절에서는 이러한 평가 결과를 A/B 테스트와 프롬프트 개선 주기에 어떻게 적용할 수 있는지 살펴보겠습니다.
Last updated