LLM 평가: 지표, 프레임워크, 모범 사례



목차

LLM 평가를 위한 핵심 지표

전통적 통계 지표

퍼플렉서티: 언어 모델이 샘플을 얼마나 잘 예측하는지를 측정하는 일반적인 지표입니다. 형식적으로는 테스트 데이터의 평균 음의 로그 우도에 지수를 취한 값입니다. 직관적으로는 퍼플렉서티가 낮을수록 모델이 테스트 데이터를 덜 “놀랍다”고 느낀다는 뜻이며(따라서 더 잘 맞는다는 뜻입니다), 예를 들어 어떤 LLM이 한 말뭉치에서 퍼플렉서티 20을 보인다면, 평균적으로 각 단어마다 동등한 확률의 20가지 선택지 중에서 고르는 정도의 불확실성을 가진다는 의미입니다. 값이 낮을수록 좋으며, 모델이 단어를 더 자신 있게 예측할 수 있음을 나타냅니다. 퍼플렉서티는 종종 학습 중이거나 언어 모델 간 비교에 사용되지만, 그 자체로 출력이 유용하거나 정확한지를 말해 주지는 않고, 전형적인 언어 패턴과 얼마나 잘 맞는지만 보여 줍니다.
BLEU(이중언어 평가 대리자): 원래 기계 번역을 위해 개발된 정밀도 기반 지표입니다. BLEU는 모델 출력과 하나 이상의 기준(reference) 텍스트 사이에서 n그램(연속된 n개 단어)의 겹침 정도를 확인합니다. BLEU 점수가 높을수록 생성된 텍스트가 기준과 더 많은 구문을 공유한다는 뜻이며, 기대하는 출력에 더 가깝다는 것을 시사합니다. 예를 들어 번역 평가에서는 종종 BLEU-4 점수(최대 4그램 겹침)가 보고됩니다. BLEU는 특정 기준 표현과의 비교에는 유용하지만, 기준 문구와 다르게 표현된 타당한 바꿔 말하기나 창의적인 답변을 불리하게 평가할 수 있습니다. 단일한 정답이 없는 개방형 생성 과제에는 유용성이 떨어집니다.
ROUGE(요약 평가를 위한 재현율 지향 지표): 주로 요약 과제에 사용되는 지표 집합입니다. ROUGE-N은 BLEU와 유사하지만 재현율에 초점을 둡니다. 기준(reference) 텍스트의 n그램 중 얼마나 많은 것이 생성된 출력에 포함되었는지를 측정합니다. ROUGE-L도 있는데, 출력과 기준 사이의 최장 공통 부분 수열(LCS) 길이를 측정하여 문장 수준의 구조적 유사성을 포착합니다. 요약에서는 ROUGE 점수가 높을수록 모델 출력이 사람 작성 요약과 동일한 정보(단어/구문)를 많이 담고 있음을 의미합니다. BLEU와 마찬가지로 ROUGE는 계산이 간단하고 기준 텍스트가 있을 때 유용하지만, 응집성이나 사실 정확성을 반드시 반영하지는 않습니다.
METEOR(명시적 순서를 고려한 번역 평가 지표): 번역과 요약을 위한 또 다른 지표로, BLEU의 한계를 보완하는 것을 목표로 합니다. METEOR는 유연한 매칭 전략을 사용합니다. 생성 텍스트와 기준(reference)을 정렬할 때 정확히 같은 단어뿐 아니��� 어간과 동의어까지 일치로 인정합니다. 그런 다음 이러한 정렬의 정밀도와 재현율을 바탕으로 점수를 계산하며, 단어 순서 차이 등에는 패널티를 부여합니다. 의미가 같은 다른 단어 사용에도 모델에 점수를 부여하기 때문에, 언어 생성 과제에서는 METEOR가 BLEU보다 사람 평가와 더 높은 상관을 보이는 경우가 많습니다. 점수는 보통 0–1(또는 0–100%) 범위로 산출되며, 높을수록 좋습니다.
F1 점수: 출력을 항목의 집합으로 볼 수 있는 과제(예: 추출된 엔티티, 또는 QA의 정답 일치)에서 흔히 사용됩니다. F1 점수는 정밀도(모델 출력 중 정답의 비율)와 재현율(원하는 정답 중 모델이 찾아낸 비율)의 조화 평균입니다. 두 값을 균형 있게 반영하며, 정밀도와 재현율이 모두 충분히 높을 때에만 F1도 높아집니다. 관련 문서 검색이나 키워드 집합 예측처럼 정보 검색·추출형 평가에서 F1이 자주 쓰입니다. 예를 들어 QA 문맥에서 특정 핵심 사실을 포함하면 정답으로 간주한다고 할 때, 정밀도는 답변의 사실 중 올바른 비율을, 재현율은 기준 사실 중 답변이 포괄한 비율을 뜻하며, F1은 이를 결합합니다. 완전한 F1(1.0 또는 100%)은 모델이 잘못된 정보를 추가하지 않고 필요한 올바른 정보를 모두 찾아냈음을 의미합니다. (수식: F1 = 2 * (정밀도 * 재현율) / (정밀도 + 재현율))

비교를 위해 기준 출력(정답)이 필요한 경우가 많습니다. 개방형 대화나 창작 글쓰기처럼 열린 과제에서는 기준을 명확히 정의하기가 어렵습니다.
대체로 표면적 유사성만 평가합니다. 모델 출력이 기준과 다른 표현을 쓰더라도 의미가 같을 수 있는데, 이 경우에도 BLEU/ROUGE 점수는 낮게 나올 수 있습니다. 반대로 맥락에 부적절하거나 비일관적이어도 기준을 베껴 쓰면 높은 점수를 받을 수 있습니다.
사실 정확성, 논리적 일관성, 문체의 적절성 같은 속성은 직접 측정하지 못합니다. 예를 들어, 문법적으로 완벽하지만 사실과 다른 문장이 기준 문장과 단어가 많이 겹치면 BLEU 점수에서는 여전히 높게 평가될 수 있습니다.
이러한 지표만을 목표로 최적화하면 해당 지표에 과적합되는 문제가 생길 수 있습니다(모델이 실제 품질을 높이기보다 지표를 ‘요령껏’ 올리는 법을 학습함). 그럼에도 불구하고 BLEU, ROUGE 등은 기준 텍스트가 있는 과제(번역, 요약 등)에서 품질을 가늠하는 거친 대리 지표로 논문에서 여전히 널리 보고됩니다. 가장 바람직한 활용법은 다른 평가 방법과 병행하는 것입니다.

모델 기반 평가 지표

BERTScore: 사전 학습된 언어 모델 임베딩(BERT)을 사용해 텍스트 유사도를 평가하는 지표입니다. 정확한 문자열 일치 대신, BERTScore는 BERT의 의미 공간에서의 벡터 유사도를 기준으로 후보 출력의 각 단어를 기준(reference) 문장의 단어와 정렬합니다. 그런 다음 토큰 임베딩 수준에서 정밀도(precision), 재현율(recall), F1을 계산합니다. 직관적으로, 모델 출력이 기준과 다른 단어를 쓰더라도 같은 의미를 전달하면 해당 단어들의 BERT 문맥 임베딩이 서로 가깝게 나타나므로 BERTScore가 높게 나옵니다. 이 지표는 단순히 표면적 단어 일치를 넘어 의미를 포착하기 때문에, 요약과 같은 과제에서 BLEU나 ROUGE보다 사람 판단과 더 잘 상관하는 것으로 보고되었습니다. 점수는 보통 정밀도/재현율/F1(또는 F1만) 형태로 0~1 범위에서 보고되며, 값이 높을수록 더 좋습니다.
COMET: 기계 번역을 위해 Unbabel이 만든 학습형 평가 지표로, 신경망을 직접 학습시켜 MT 출력의 품질 점수를 매기도록 한 방식입니다. COMET(Crosslingual Optimized Metric)은 소스 입력, 모델의 번역, 기준(reference) 번역(또는 버전에 따라 소스와 번역만)을 입력으로 받아 품질 점수를 출력합니다. 사람 평가 점수로 라벨링된 번역 예시로 학습되기 때문에, 사람 평가를 모사하는 점수를 예측하도록 배웁니다. 학습 기반 지표이므로, 단순 중복 지표가 놓치는 오류(일부 단어가 겹치더라도 오번역인 경우 등)를 포착할 수 있습니다. 학술 MT 평가에서 사실상의 새로운 표준으로 자리 잡았으며, 종종 BLEU보다 사람 판단과의 상관이 더 높게 보고됩니다. 참조 없이 평가하는 설정 등 다양한 변형도 존재합니다. COMET은 주로 번역 과제에 쓰이지만, 모델을 학습시켜 텍스트를 평가하도록 하는 접근은 다른 과제에도 확장될 수 있으며, 요약 등에서 유사한 시도가 이루어지고 있습니다.
BLEURT, PRISM, BARTScore 등: 이들은 유사한 학습형 지표입니다. BLEURT는 합성 데이터와 사람 평가 데이터로 BERT를 미세 조정해 후보와 기준(reference) 간의 점수를 예측합니다. PRISM은 다국어 모델을 사용해 기준이 주어졌을 때 후보의 확률과 그 반대 방향의 확률을 측정합니다. BARTScore는 사전 학습된 시퀀스-투-시퀀스 모델(BART)을 사용해 복원 가능도에 기반하여 후보가 기준의 패러프레이즈일 가능성을 점수화합니다. 이들 지표는 모두 정확 일치를 넘어, 대형 모델의 능력을 활용해 텍스트 품질을 판단하는 것을 목표로 합니다.
GPT 점수 / LLM 기반 스코어링: GPT-3와 GPT-4 같은 강력한 LLM의 등장으로, LLM 자체를 평가자로 활용하는 추세가 생겼습니다. 예를 들어 특정 작업 프롬프트가 주어졌을 때, GPT-4에게 두 모델의 출력을 비교 평가하게 하거나 단일 출력을 기준에 따라 점수화하도록 요청할 수 있습니다(좋은 답변의 기준에 대한 지침을 함께 제공할 수 있습니다). 이에 대한 예로 G-Eval이 있는데, 이는 GPT-4에 상세한 평가 루브릭을 제공하여 프롬프트하고 연쇄적 사고 추론 NLG 출력물을 채점하는 방식입니다. 예를 들어 프롬프트에 “다음 답변의 정확성과 명확성을 평가하시오”라고 지시하면, GPT-4가 점수와 함께 설명을 제공합니다. G-Eval은 특히 연쇄적 사고 프롬프트(LLM이 자신의 추론을 설명하게 함)를 사용해 신뢰도를 높였을 때, GPT-4의 이해 능력을 활용하여 콘텐츠를 평가함으로써 사람 평가자와의 합치도가 더 높게 나타났습니다. 요컨대 LLM을 심판으로 사용하는 것입니다.

이들은 기반이 되는 모델로부터 편향을 물려받을 수 있습니다. 모델(BERT나 GPT-4처럼)에 특정한 사각지대가 있다면, 그 한계가 평가 결과에도 그대로 드러날 수 있습니다.
세심한 보정이 필요합니다. 채점에 사용되는 LLM은 올바른 기준에 따라 평가하도록 보장하는 프롬프트가 필요할 수 있습니다. 프롬프트 표현을 달리하면 서로 다른 점수가 나올 수 있습니다.
훈련에 이러한 학습형 지표를 사용하면 모델이 그 지표에 과적합될 위험이 있습니다. 예를 들어, GPT-4를 심판으로 삼아 점수를 높이도록 응답을 최적화하면, 심판 모델이 설명을 선호하기 때문에 지나치게 장황한 답변으로 이어질 수 있습니다.
그럼에도 불구하고 이러한 지표들은 BLEU/ROUGE보다 사람의 선호와 더 잘 부합하는 경우가 많기 때문에 연구에서 매우 널리 사용되고 있습니다. 예를 들어, 새로운 요약 모델이 기준선보다 BERTScore와 GPT-4 심판 점수가 모두 높다면, 실제로 더 사람다운 요약을 생성한다는 강력한 신호입니다(물론 사람 평가로도 확인해야 합니다).

사람 평가 방법

선호도 테스트(쌍대 비교): 평가자(대개 크라우드 워커나 도메인 전문가)는 동일한 프롬프트에 대해 두 개의 서로 다른 모델(또는 모델과 기준 답안)의 출력을 보고 어느 쪽을 더 선호하는지 선택합니다. 이렇게 하면 선호 비율이 산출됩니다. 예: “모델 A의 답변이 모델 B보다 70%의 비율로 선호되었다.” 쌍대 비교 테스트는 모델 변형 간 의사결정에 매우 유용합니다. 절대 점수를 매기는 것보다 주석자에게 더 간단하고, 어느 출력이 상대적으로 더 나은지 직접적으로 알려줍니다. 많은 기업(예: OpenAI, DeepMind)은 쌍대 비교를 광범위하게 활용합니다. 예를 들어, 파인튜닝 모델 사람 피드백을 활용한 강화 학습(RLHF)에서는 사람이 출력물을 비교해 선호도 모델을 학습시킵니다. 평가에서도 한 모델이 다른 모델을 이기는 승률은 강력한 지표입니다(예를 들어 OpenAI의 GPT-4 논문은 GPT-4가 GPT-3.5보다 더 선호된다는 것을 이 지표로 보여줍니다).
리커트 척도 평정: 주석자는 특정 기준에 대해 고정된 척도로 출력을 평가합니다. 예를 들어, 품질을 1~5로, 응답의 정보성 또는 유해성을 1~7로 매깁니다. 이렇게 하면 여러 축에서 더 세밀한 평가가 가능합니다. 챗봇 평가에서는 전체 만족도, 답변의 정확성, 공손함 등을 사람들에게 평가하게 할 수 있습니다. 평균 점수(및 분포)는 모델의 현재 수준을 보여줍니다. 리커트 척도는 이진 승패 비교보다 더 많은 정보를 제공하지만, 일관성을 확보하기가 더 어려울 수 있습니다. 한 사람의 “4”가 다른 사람의 “3”일 수 있기 때문입니다. 명확한 가이드라인과 평가자용 학습 예시를 제공하면 이러한 문제를 완화할 수 있습니다.
스칼라 또는 순위형 출력: 여러 모델을 한꺼번에 비교할 때는 출력물을 최상부터 최하까지 순위를 매기거나, 0–10 같은 수치 점수를 부여하기도 합니다. 이는 리커트 척도와 유사하지만 “매우 동의함” 같은 라벨이 붙은 범주에 제한되지 않습니다. 예를 들어, 평가자가 가독성을 0–100 척도로 요약문에 점수를 매길 수 있습니다. 다만 보통은 일관성을 유지하기 위해 범위가 정해진 리커트 척도를 사용합니다.
최종 사용자 대상 A/B 테스트: 운영 중인 시스템에서는 일부 사용자에게는 모델 A를, 다른 일부에게는 모델 B를 배포하고, 암묵적 또는 명시적 피드백을 활용해 어느 쪽이 더 잘 작동하는지 판단하는 것이 궁극적인 테스트입니다. 예를 들어, 검색 질의 응답 모델의 두 가지 버전을 배포할 수 있습니다. 하나는 새로운 LLM을, 다른 하나는 기존 모델을 사용한 뒤 실제 환경에서 어느 버전이 더 높은 사용자 참여도나 만족도 평점을 내는지 확인합니다. 이는 대규모 인간 평가의 한 형태로, “사용자를 심사위원으로” 삼는 접근입니다. 사용자 클릭이나 과업 성공률처럼 실제 현실의 성공 기준을 측정하므로 매우 강력합니다. 단점은 배포 이후에만 가능하다는 점으로, 실제 사용자에게 시험해도 안전하다고 판단되는 모델에 한해서만 수행할 수 있습니다.

정확도/정합성: 출력이 기준 정답 또는 검증된 사실에 비해 사실 오류나 실수를 포함하나요?
관련성: 출력이 주제에 맞고 사용자의 질문이나 프롬프트를 제대로 다루고 있나요?
유창성/자연스러움: 텍스트가 문법적으로 올바르고 자연스럽게 들리나요?
일관성: 출력이 전체적으로 말이 되나요? (특히 긴 출력의 경우에 해당합니다. 예: 이야기의 플롯이 일관적인가요? 에세이의 논지가 논리적으로 전개되나요?)
유용성: 어시스턴트 같은 애플리케이션에서, 그 답변은 도움이 되었나요?
유해성/독성: 출력에 불쾌하거나 안전하지 않은 내용이 포함되어 있나요?
공정성: 편향을 평가할 때는 사람이 출력물을 검토하여 편향된 가정이나 고정관념이 있는지 확인하세요.

맞춤형 작업별 지표

사실 정확도 지표: 사실 정확성이 핵심인 작업(예: 질의응답, 지식 베이스 검색, 사실 문서 요약)에서는, 팀이 올바른 사실의 비율을 점수화하는 방법을 설계합니다. 폐쇄형 질문의 경우에는 단순히 정답과의 완전 일치 정확도(모델이 기대한 답을 정확히 출력했는가)를 사용할 수 있고, 더 복잡하게는 지식 그래프 사실에 대한 정밀도/재현율을 사용할 수도 있습니다. 요약에서는 원문과의 일관성을 자동으로 점검하는 FactCC, Q² 같은 지표가 있습니다. 다른 접근으로는 정보 검색 시스템을 활용하는 방법이 있습니다. LLM이 출력에서 제시한 각 주장에 대해 신뢰할 수 있는 데이터베이스나 위키피디아에서 근거를 찾을 수 있는지 확인하는 것입니다. 찾지 못하면 해당 주장은 부정확할 수 있습니다. 이러한 지표들은 환각을 잡아내려는 시도입니다. 예를 들어, TruthfulQA는 모델이 진실한 답변을 내는지, 아니면 흔한 오개념에 빠지는지를 확인하도록 설계된 질문 세트를 제공하는 벤치마크로, 점수는 진실하게 답한 질문의 비율(%)입니다.
응집성과 일관성 지표: 긴 문단의 응집성을 측정하려면 담화 응집성 점수를 사용할 수 있습니다. 학계에서는 엔터티 그리드(entity grid)나 주제 전이 확률을 활용한 지표들이 제안되어 왔습니다. 언어학 분야의 Coh-Metrix처럼 다양한 응집성 지표를 계산해 주는 도구도 있습니다. 일관성(특히 대화나 스토리텔링에서)을 위해서는 모델이 자기모순을 일으키는지 확인할 수 있습니다. 예를 들어, 한 이야기에서 어떤 인물의 머리카락을 한 단락에서는 금발로, 다른 단락에서는 검정으로 묘사했다면 이는 불일치이며, 맞춤형 스크립트로 이러한 사례를 표시할 수 있습니다. 대화의 경우에도, 모델의 답변이 이전에 한 말과 충돌하지 않는지 확인하는 것이 또 다른 일관성 점검입니다. 이러한 방법은 대개 규칙 기반이거나 콘텐츠의 의미 분석을 요구합니다. 자동화가 쉽지는 않지만, 부정 표현이나 모순을 나타내는 단어를 탐지하는 등의 간단한 검사만으로도 논리적 일관성을 정량화하는 데 도움이 됩니다.
구체성 / 관련성 대화 시스템에서는 USR(Unsupervised and Reference-free evaluation)라는 지표가 프롬프트에 대한 응답이 구체적인지(예: “잘 모르겠습니다” 같은 상투적 답변이나 주제에서 벗어난 응답이 아닌지) 확인하는 구성 요소를 포함합니다. 관련성을 평가할 때는 응답의 임베딩과 질의의 임베딩을 비교할 수 있습니다. 두 임베딩이 매우 관련성이 낮다면, 답변이 주제에서 벗어났을 가능성이 있습니다. 이러한 지표는 장황하게 빙빙 도는 답변이나 회피성 응답에 감점을 주는 데 활용될 수 있습니다.
길이 기반 지표: 일부 작업은 간결한 답변을 요구하고, 다른 작업은 상세한 설명이 필요합니다. 예를 들어, 요약은 원문 정보를 유지하면서 얼마나 짧아졌는지를 나타내는 압축 비율로 평가할 수 있습니다. 또는 코드 생성 작업은 생성된 올바른 코드 줄 수로 측정할 수 있습니다. 만약 간결함이나 장황함이 품질에 중요한 요소라면, 출력 길이나 압축률 같은 단순한 지표를 포함할 수 있습니다.
사용자 참여 지표: 대화형 시스템에서는 사용자 행동 자체가 간접 지표가 될 수 있습니다. 예를 들어, 도움말 챗봇의 경우 하나의 지표로 ‘컨테인먼트 비율’을 사용할 수 있습니다. 이는 사람에게 이관하지 않고 봇이 자체적으로 처리한 대화의 비율(%)을 의미합니다. 전통적인 “NLP” 지표는 아니지만, 해당 시스템의 실제 성공 지표입니다. 혹은 문제 해결까지 걸린 시간, 대화 종료 시점의 사용자 만족도 평가 등도 활용할 수 있습니다. 이러한 지표들은 배포된 시스템에서만 측정할 수 있지만, 실무적 평가에 핵심적입니다.
안전성 지표: 안전한 동작을 평가하려면 테스트 세트에서 위험한 출력의 개수를 세면 됩니다(탐지를 위해 분류기를 사용할 수 있습니다). 예를 들어, 도발적이거나 민감한 프롬프트 묶음에 모델을 실행하고, 독성 탐지기를 사용해 독성 응답이 몇 개 발생했는지 확인합니다. “독성으로 표시된 출력 비율(%)”과 같은 지표를 사용할 수 있으며, 값이 낮을수록 좋습니다. 마찬가지로 편향은 특정 테스트로 평가할 수 있습니다. 예: 서로 다른 인구집단에 대해 동일한 질문을 제시하고, 응답에 감성 분석기를 적용해 집단 간 격차가 있는지 확인합니다. 이때 지표는 집단 간 감성 점수 차이일 수 있으며, 공정한 모델이라면 이상적으로 0에 가까워야 합니다.
코드 전용 지표: 코드를 생성하는 LLM의 경우 표준 소프트웨어 지표를 사용합니다. 예: 단위 테스트 통과율(테스트 케이스를 제공하고 생성된 코드가 이를 통과하는지 확인), 알려진 프로그래밍 과제에 대한 기능적 정확도(예: Codeforces나 LeetCode에서 해결한 문제 비율). 이런 경우 출력이 실행 시 기대한 결과를 내면 “정답”으로 간주되며, 매우 명확한 지표가 됩니다.

평가 방법론

자동화된 벤치마크와 데이터셋

GLUE와 SuperGLUE: General Language Understanding Evaluation(GLUE)는 감성 분석, 의미 중복(패러프레이즈) 검출, 질의응답, 텍스트 함의 등 여러 영어 과제로 구성된 벤치마크 모음입니다. 모델의 성능은 과제별 정확도나 F1 점수로 측정하며, 종종 통합 점수도 함께 보고합니다. SuperGLUE는 더 어려운 과제와 불균형한 클래스 분포를 포함해 단순한 편법 풀이를 막도록 설계된 강화 버전입니다. 이들 벤치마크는 LLM 이전 시대(예: BERT, RoBERTa, T5)에 널리 사용되었으며, 현재도 LLM이 기본적인 언어 이해 능력을 갖추었는지 확인하는 데 유용합니다. 연구자들은 GLUE/SuperGLUE와 같은 벤치마크를 통해 서로 다른 LLM이 다양한 언어 과제를 얼마나 잘 처리하는지 비교할 수 있습니다. 최신 LLM(예: GPT-3+ 등)은 종종 매우 높은, 때로는 인간 수준에 가까운 성능을 보이지만, 여전히 기초 역량을 점검하는 합리성 검증(sanity check) 지표로 가치가 있습니다.
MMLU(대규모 멀티태스크 언어 이해): 역사와 문학부터 수학과 생물학에 이르는 57개 다양한 과목 전반의 지식과 추론 능력을 평가하기 위해 도입된 벤치마크입니다. 각 과목은 객관식 문항으로 구성되어 있습니다. 목표는 모델이 학습 데이터에서 익혔을 법한 지식과 추론 능력을 어느 정도 보유했는지 확인하는 것입니다. MMLU는 상당히 어려워서, 모델은 대규모 퀴즈/지식 시험을 치르는 것과 비슷한 상황에 놓입니다. 지식의 폭과 깊이를 평가하는 표준으로 자리 잡았으며, 예를 들어 GPT-4의 높은 MMLU 점수는 광범한 지식을 갖추었다는 근거로 인용되었습니다. 본질적으로, LLM이 학습 과정에서 습득했을 것으로 기대되는 분야에서 문제를 해결하거나 질문에 답하는 능력을 얼마나 잘 발휘하는지를 측정합니다.
HellaSwag, PIQA, WinoGrande 등:" 이들은 상식 추론과 논리를 겨냥한 특화 벤치마크입니다. HellaSwag은 이야기 조각의 가장 그럴듯한 다음 전개를 고르는 과제로, 상식적 기반을 평가합니다. PIQA(Physical IQA)는 “X를 사용해 Y를 어떻게 할 것인가” 같은 상식적 물리 추론 질문을 묻습니다. WinoGrande는 대규모 Winograd Schema 데이터셋으로, 상식을 활용한 대명사 해소를 통해 상황 이해와 중의성 해소 능력을 평가합니다. LLM은 이들 과제에서의 정확도로 평가되며, 모델이 인간의 일상적 추론 능력을 갖추었는지 탐색합니다. 초기에 난도가 높았지만, 더 큰 모델이 등장하면서 성능이 크게 개선되었습니다.
BIG-bench(Beyond the Imitation Game): 연구 커뮤니티가 기여한 매우 다양하고 창의적인 과제 모음(약 200개)으로, 현재 모델들에게 어려움을 주도록 특별히 설계되었습니다. 과제는 초등 수학부터 논리 추론 퍼즐, 고대어 번역에 이르기까지 폭넓게 포함합니다. BIG-bench의 목적은 우리가 보통 시험하지 않는 능력을 탐색하는 데 있습니다. 모델은 이 과제들에 대해 평가되며(대개 과제별 맞춤 지표를 사용), 모델의 전체 BIG-bench 성능은 특이한 도전 과제에서 emergent 능력이 나타나는지 여부를 가늠하는 데 도움을 줍니다. 표준 벤치마크에서는 좋은 성능을 보이더라도, 복잡한 계획 수립이나 농담 이해가 필요한 BIG-bench 과제에서 실패하는 등 블라인드 스팟을 확인하는 데 유용합니다.
언어 모델의 총체적 평가(HELM): 이는 스탠퍼드에서 시작된 비교적 새로운 이니셔티브로, 단순한 데이터셋이 아니라 평가 프레임워크입니다. HELM은 정확도, 강건성, 캘리브레이션, 공정성, 편향, 독성, 효율성 등의 범주 전반에 걸친 광범위한 “시나리오”(과제와 도메인)와 지표를 정의합니다. 핵심 아이디어는 모델을 다차원 축에서 동시에 비교할 수 있는 종합 리더보드를 제공하는 것입니다. 예를 들어, HELM은 모델이 특정 과제에서 얼마나 잘하는지만 보고하지 않고, 확률 캘리브레이션이 얼마나 잘 되어 있는지, 입력이 노이즈를 포함할 때 어떻게 동작하는지, 속도는 어떤지, 공격적이거나 부적절한 출력을 얼마나 자주 내는지까지 함께 보고합니다. 이는 단일 점수를 넘어 다차원 평가가 필요하다는 요구를 충족합니다. HELM은 고정된 벤치마크라기보다 평가 플랫폼에 가깝고, 새로운 모델과 지표가 등장하면 지속적으로 업데이트됩니다.
OpenAI Evals / 사용자 지정 벤치마크: 많은 조직이 자사 제품과 관련된 내부 벤치마크를 직접 구축합니다. 예를 들어 OpenAI는 openai-evals 프레임워크로, 사용자 지정 평가 로직을 직접 지정할 수 있습니다(예: ChatGPT의 답변에 핵심 정보가 포함되어 있는지 확인하는 Python 스크립트). 이런 평가들은 대개 코딩, 수학 서술형 문제 등 특정 사용 사례에 맞춰 설계됩니다. 시간이 지나면서 일부는 공개되거나 사실상 표준 벤치마크로 자리 잡습니다. 코딩 분야에는 주어진 명세에 맞는 올바른 프로그램을 작성하는지를 평가하는 HumanEval, Massive Multitask Programming Problems인 MBPP 등이 있으��, 코드 출력의 기능적 정합성을 측정합니다.

휴먼 평가 기법과 과제

홀드아웃 데이터셋을 사용하세요. 특히 중요하거나 개발에 사용된 질문·과제가 있다면, 모델이 아직 맞춰지지 않은 새로운 세트를 따로 준비해 그 항목들에 대해 사람이 출력을 평가하도록 하세요. 이렇게 하면 새로운 입력에 대해 편향되지 않은 측정을 보장할 수 있습니다.
크라우드소싱: Amazon Mechanical Turk, Appen, Scale AI 같은 플랫폼을 활용해 사람의 판단을 수집하는 경우가 많습니다. 응답에서 무엇을 볼지에 대한 가이드라인과 좋은/나쁜 출력 예시를 미리 준비합니다. 그런 다음 여러 명의 어노테이터가 각 출력을 평가하도록 합니다. 항목별로 여러 어노테이터를 배정해 합의 여부를 확인하거나 불일치를 표시하는 것이 중요합니다. 흔한 방법으로는 각 출력에 대해 3~5명이 평가하도록 하고, 선호도 테스트의 경우 다수결을, 평정 척도의 경우 평균 점수를 최종 결과로 사용하는 방식이 있습니다.
전문가 평가: 의료나 법률처럼 전문성이 필요한 분야에서는 정답성을 판단할 수 있는 전문가가 필요할 수 있습니다. 예를 들어, 의료 관련 답변은 의사가 정확한지 검증해야 합니다. 이는 더 느리고 비용이 많이 들지만, 위험도가 높은 도메인에서는 필수적입니다. 비용 문제로 인해 보통은 더 작은 샘플을 전문가가 평가합니다.
레드 팀 운영: 이는 전문가가 모델을 ‘깨뜨리려’ 시도하는 유형의 휴먼 평가입니다. 즉, 해롭거나 말이 안 되는 출력을 유발하는 입력을 찾아내는 방식입니다. 레드 팀은 안전 취약점이나 논리적 실패처럼 모델의 약점을 의도적으로 파고듭니다. 엄밀한 의미의 ‘지표’는 아니지만, “질문 X에 대해 모델이 위험한 조언을 했다”와 같은 레드 팀의 발견 사항은 모델이 충분히 안전한지 정성적으로 판단하는 데 활용됩니다.

선호 승률(예: 모델 A가 모델 B와의 비교에서 60%의 사례에서 더 선호됨).
각 기준에 대한 평균 평점과 표준편차.
평가의 일관성을 확인하기 위한 평가자 간 합의도. 분류형 평가의 경우 Cohen의 카파나 Krippendorff의 알파 같은 지표를 계산할 수 있습니다. 합의도가 높으면 결과에 대한 신뢰도가 높아지고, 합의도가 낮으면 과제가 모호했거나 가이드라인이 명확하지 않았음을 시사합니다.

비용과 확장성: 앞서 언급했듯이, 인간 평가는 확장성이 떨어집니다. 모델을 조금만 수정할 때마다 철저한 인간 평가를 수행하는 것은 비현실적입니다. 그래서 팀들은 보통 최종 비교나 정기 점검에만 인간 평가를 사용하고, 그 사이에는 자동화된 지표에 의존합니다(곧 하이브리드 접근법도 다루겠습니다).
시간: 인간 주석을 수집하는 데는 과제 설정, 실행, 결과 정제까지 며칠에서 몇 주가 걸릴 수 있습니다. 그사이에 모델이 바뀌었을 수도 있습니다. 따라서 피드백 루프에 지연이 발생합니다.
품질 관리: 크라우드소싱 평가자는 지침을 오해하거나 충분히 주의를 기울이지 않을 수 있습니다. 품질이 낮은 작업을 걸러내기 위해, 정답이 이미 알려져 있거나 기대되는 판단이 명확한 테스트 문항을 포함하는 것이 중요합니다. 많은 평가 설정에서는 “감시(sentinel)” 문항을 일부 포함하며, 작업자가 이 문항들을 틀릴 경우 해당 작업자의 다른 응답도 폐기될 수 있습니다.
주관성: 일부 과제에서는 인간끼리도 무엇이 최선인지 합의하지 못합니다. 예를 들어, 이야기의 “창의성”을 평가하는 것은 주관적입니다. 이를 다루는 한 가지 방법은 모호한 “얼마나 창의적인가?” 대신 “이야기에 명확한 결말이 있었는가? 예/아니오”처럼 더 객관적인 질문을 평가자에게 제시하는 것입니다. 다른 방법으로는 주관성을 인정하되, 평균적인 경향이 드러날 만큼 충분한 표본을 확보하는 것입니다.
주석자 편향: 앞서 언급했듯이, 사람에게는 편향이 있습니다. 어떤 사람은 더 관대하고, 어떤 사람은 더 비판적일 수 있습니다. 주석자 집단이 다양하지 않다면 결과가 한쪽으로 치우칠 수 있습니다. 예를 들어, 모든 주석자가 한 국가 출신의 유창한 영어 화자라면 “공손함”에 대한 판단이 다른 문화권과 다를 수 있습니다. 모델의 전 세계적 사용자 기반을 가정할 때, 공손함이나 전반적 유용성처럼 문화적 맥락이 큰 요소를 평가한다면 다양한 배경을 가진 주석자 집단을 구성하는 것이 바람직한 관행입니다.
과제 구성 방식: 주석자에게 과제를 어떻게 제시하느냐에 따라 결과가 달라질 수 있습니다. “모델 A는 더 간결하도록 튜닝되었습니다. 어느 쪽이 더 낫나요?”라고 말하면 간결성을 선호하도록 유도하게 됩니다. 따라서 “두 개의 답이 있습니다. 어느 답을 더 선호하는지와 그 이유를 간략히 적어 주세요.”처럼 중립적으로 구성해야 합니다. 또한, 평가 목표에 따라 여러 측면(또는 핵심 측면)을 고려하도록 지시해야 합니다. 때로는 한 사람이 기준을 뒤섞지 않도록, 서로 다른 측면을 평가할 때 주석자 그룹을 분리해 운영하기도 합니다.

판사형 LLM 접근법과 한계

LLM 판사는 특히 평가 기준이 명확할 때 특정 도메인에서 인간의 선호를 상당히 잘 근사할 수 있습니다. 또한 주어진 루브릭을 적용하는 방식이 매우 일관되며, 프롬프트 자체에 무작위성이 있지 않는 한 주석자의 기분 변화나 피로 같은 요인이 개입하지 않습니다.
모델만 준비되면 평가 속도가 매우 빠르고 비용도 저렴합니다. 특히 오픈소스 LLM을 판사로 쓰거나 GPT-4 같은 API를 사용할 경우(무료는 아니지만) 인간보다 훨씬 빠르게 수천 쌍을 평가할 수 있습니다.

일관성 부족과 프롬프트 민감성: LLM 평가자는 일관성이 떨어질 수 있습니다. 예를 들어, 평가 프롬프트의 문구를 조금만 바꿔도 결과가 달라질 수 있어, 평가자로서의 견고성이 충분하지 않음을 시사합니다. 또한 출력을 독립적으로 점수화하도록 하면, 고정된 척도를 유지하지 못할 수 있습니다. 같은 응답이 어느 날은 “8/10”, 다른 날은 “7/10”을 받는 식인데, 이는 프롬프트로 강제하지 않는 한 모델이 지속적인 루브릭 기억을 갖고 있지 않기 때문입니다. 일부 연구에서는 절대 점수 부여보다 쌍대 비교(A 대 B)를 시키는 방식이 더 안정적이라고 보고합니다.
편향과 정렬 LLM은 학습 과정에서의 편향을 그대로 지닐 수 있습니다. 출력물을 평가하도록 요청하면, 더 장황하거나 형식적인 답변을 선호하는 편향을 보일 수 있고, 내용 측면에서도 편향을 반영할 수 있습니다(예: 학습 데이터에서 다수 의견과 더 잘 맞는 답변을 선호). 한 연구에서는 LLM 기반 평가가 인간 평가와 유사한 편향에 취약하다고 지적했는데, LLM이 인간이 작성한 콘텐츠와 인간의 선호에 맞춰 학습되었기 때문입니다. 더 나아가, 평가 대상 모델과 평가자 모델이 유사한 약점을 공유할 경우, 평가자가 특정 오류를 놓칠 수 있습니다. 예를 들어, 둘 다 미묘하게 틀린 진술을 사실로 오인하는 경향이 있다면, LLM 판사는 다른 모델의 거짓 진술을 오류로 표시하지 못할 수 있습니다.
설명의 정직성: LLM 판사가 근거를 제시할 때, 실제로는 특정 출력을 선호한 진짜 이유가 아님에도 그럴듯하게 들리는 설명을 만들어낼 수 있습니다. 즉, 우연한 패턴에 의해 내려진 선택을 사후적으로 합리화할 가능성이 있습니다. 따라서 LLM 판사의 설명을 읽을 때에는 주의가 필요합니다. 이들이 인간과 같은 의미의 “사고 과정”을 갖고 있는 것이 아니라, 그저 그럴듯한 텍스트를 생성할 뿐이므로, 설명이 실제 판단 과정을 보장하지는 않습니다. 그럼에도 이러한 설명은 여전히 유용할 수 있으며, 기준에서 벗어난 설명은 평가 과정에 문제가 있음을 시사하는 신호가 될 수 있습니다.
랭킹 vs 레이팅: 경험적 근거에 따르면, LLM 판사는 절대 점수를 매길 때보다 두 출력 중 하나를 선택할 때 더 잘 작동하는 경향이 있습니다. 쌍대 비교 설정에서는 GPT-4 같은 모델이 어느 답변이 더 정확하거나 더 잘 작성되었는지를 비교적 높은 정확도로 판별할 수 있습니다. 반면, 단일 답변에 대해 척도 기반 점수를 매기게 하면 척도 드리프트가 나타날 수 있습니다. 예를 들어, 전반적으로 인간보다 높게 평가하는 경향을 보이거나, 모든 점수를 좁은 구간으로 압축해 버리는 식입니다. 이를 완화하기 위해 일부 프레임워크는 다수의 쌍대 비교를 수행한 뒤 그 결과로부터 모델의 랭킹을 추정하기 위해 Elo 레이팅이나 TrueSkill을 사용합니다.
자가 평가: 동일한 모델로 자신을 평가하게 하면 문제가 생길 수 있습니다. 지나치게 관대해지거나, 자신의 혼란을 그대로 반영할 수 있기 때문입니다. 모델이 스스로 작성한 답변의 오류를 보지 못해, 그 답변이 좋다고 오판할 수도 있습니다. 따라서 평가자는 더 강력하거나 최소한 다른 모델을 쓰는 것이 바람직합니다. 예를 들어, GPT-3.5나 다른 모델의 출력을 GPT-4로 판정하게 하는 방식입니다. 또는 판정자 앙상블을 사용할 수도 있습니다(GPT-4 + 규칙 기반 평가 + 또 다른 LLM). LLM 평가자를 앙상블로 구성하거나, 일부 인간 피드백으로 보정해 신뢰성을 높이는 연구들도 있습니다.
LLM 판사를 속이기 권위적인 어조나 가짜 참고 문헌을 넣어 LLM 판사를 속이는, 질적으로 더 낮은 답변 사례들이 관찰된 바 있습니다. 예를 들어, 한 답변이 (틀린) 사실을 단정적으로 말하고 다른 답변이 확신이 없는 태도를 보일 때, 프롬프트에서 사실 검증을 명확히 지시하지 않으면 LLM 판사는 자신감 있는(하지만 틀린) 답변을 선호할 수 있습니다. 요컨대 LLM 판사는 답변의 스타일에 영향을 받을 수 있습니다. 정확성을 최우선으로 하라고 지시하지 않으면, 짧지만 정확한 답변보다 장황하고 공손한 답변을 더 좋게 평가할 수 있습니다. 이러한 함정을 피하도록 판사 프롬프트를 설계하는 일은 지속적으로 미세 조정이 필요한 영역입니다.

한 가지 접근법은 LLM 보정 소수의 인간 평가 예시를 함께 제공해(퓨샷 프롬프트나 소규모 평가 데이터셋으로 파인튜닝) 인간의 기준을 더 잘 모방하도록 합니다.
또 다른 하나는 합의 검증중요한 평가의 경우, 서로 다른 프롬프트나 모델을 사용한 다수의 LLM 판사를 두고, 높은 수준의 다수 의견이 일치할 때만 결과를 신뢰하세요. 의견이 엇갈리면 해당 사례는 인간 검토가 필요할 수 있습니다.
다음 기법들 순서 편향을 줄이다예: 출력 순서를 무작위로 제시하거나, 텍스트를 섞어 블라인드 평가를 하도록 LLM 판사에게 맡기는 방법도 있습니다(다만 구현이 어렵습니다).
사용하기 서로 다른 프롬프트 먼저 LLM 판사에게 구체적인 질문을 던진 뒤(“답변 A는 사실관계가 정확한가요? 답변 B는 사실관계가 정확한가요? 어느 쪽이 지시를 더 잘 따랐나요?”), 그 응답을 취합해 최종 결정을 내리는 방식입니다. 이런 구조화된 접근법은 평가를 더 체계적으로 만들어 줍니다.

하이브리드 평가 방법

사람 참여형 + 자동화: 자동 지표나 LLM 판사를 활용해 출력물을 사전 선별하거나 순위를 매긴 뒤, 사람은 까다로운 사례에 집중하세요. 예를 들어 1,000개의 출력을 평가해야 한다면, 독성 분류기를 사용해 명백히 유해한 출력을 자동으로 표시하고(발견되면 모델을 탈락 처리), LLM 판사로 응집성을 점수화해 하위 100개를 표시한 다음, 인간 평가자가 그 100개를 면밀히 검토하되 나머지에서도 무작위 표본을 뽑아 스팟 체크를 수행합니다. 이렇게 하면 인간의 노력을 모델에 문제가 있을 가능��이 높은 부분에 집중시켜 효율을 높일 수 있습니다.
정성적·정량적 혼합:" 전체 자동화 지표 점수로 성능을 요약해 제시하되, 인간 평가의 정성적 분석도 함께 포함하세요. 많은 연구 논문이 이런 방식을 택합니다. “모델 X는 BLEU 0.25를 달성해 모델 Y의 0.27에 근접했습니다. 더 깊이 이해하기 위해 인간 평가를 수행한 결과, 평가자들은 55%의 경우 모델 X를 선호했는데, BLEU는 다소 낮았지만 사실 일치성이 더 높다고 밝혔습니다.” 이렇게 결합하면 훨씬 더 완전한 그림을 얻을 수 있습니다.
LLM 보조 인간 평가: 흥미롭게도 LLM은 인간 평가를 도울 수도 있습니다. 예를 들어, 사람이 긴 텍스트(모델이 쓴 5페이지 분량의 이야기 등)를 평가할 때는 모든 내용을 일일이 기억하고 비교하기가 어렵습니다. 이럴 때 LLM이 이야기를 요약하거나 잠재적 문제를 하이라이트할 수 있습니다(예: “3단락에서 1단락의 내용과 모순되는 부분이 있습니다”). 그러면 사람은 이러한 포인터를 바탕으로 최종 판단을 내립니다. 최종 판사는 여전히 인간이지만, AI가 과정을 더 빠르게 만들어 줍니다.
반복적 평가와 개선: 하이브리드 평가는 개발 주기의 일부로 포함될 수 있습니다. 예를 들어, 워크플로는 다음과 같을 수 있습니다:
새로운 모델 버전을 개발하세요.
자동 테스트와 벤치마크(퍼플렉서티, BLEU 등)를 실행하세요. 이 지표들에서 이전보다 나빠졌다면 회귀이므로 되돌아가 수정하세요.
통과했다면, 다양한 프롬프트에 대해 이전 모델과 LLM 판정 비교를 실행해 빠르게 승패를 파악하세요.
새 모델이 더 낫거나 비슷해 보인다면, 품질을 확인하기 위해 핵심 지표에 대해 소규모 인간 평가를 수행하세요.
모든 점검이 끝났다면, 소규모 사용자 그룹에 배포하고 실제 상호작용을 모니터링하세요(예: 사용자 평점 같은 지표를 사용하거나, 이전 모델이 실패했던 질문에 새 모델이 답하는지 측정). 이러한 실제 환경의 데이터는 추가 평가 자료로 활용됩니다.
그 결과가 긍정적이라면, 모델을 전면 출시하세요.
이 주기에서는 자동 평가와 인간 평가가 서로 다른 단계에서, 서로 다른 범위로 진행됩니다(오프라인 대 온라인, 소규모 대 대규모).
지속적 피드백 루프: 프로덕션 환경에서는 인간 평가와 자동 평가를 루프로 결합해 모델 성능을 유지할 수 있습니다. 예를 들어, 일부 고객 지원 봇은 사용자가 답변을 평점으로 평가하거나 “도움이 되지 않았습니다”라고 표시할 수 있게 합니다. 이러한 신호를 모아(인간 피드백의 자동 분석) 실패 패턴을 찾을 수 있습니다. 그런 다음 사람이나 LLM이 그 실패 사례를 검토하여 범주화할 수 있습니다(예: “실패의 상당수가 봇이 처리하지 못한 기술적 질문에 관한 것”). 이는 다음 학습 반복이나 프롬프트 조정에 반영될 수 있습니다. 이때 사용자(인간) 피드백은 평가의 일부이며, 그 피드백에 대한 자동 분석은 개선이 필요한 지점을 식별하는 데 도움을 줍니다.
앙상블링 평가자: 또 다른 하이브리드 아이디어는 동일한 출력에 대해 여러 평가 방법을 적용하고, 그 결과를 조합하여 판단하는 것입니다. 예를 들어, 새 모델이 최소 하나의 자동 지표에서 개선을 보이되 다른 지표를 악화시키지 않아야 하며, 동시에 인간 평가자에게도 더 선호되는 것을 요구할 수 있습니다. 이러한 다각도의 기준은 하나의 지표만 맹목적으로 최적화하지 않도록 보장해 줍니다. 만약 어떤 출력이 모든 자동 점검을 통과했는데(무독성, 참조와의 높은 유사도 등)도 불구하고 인간이 여전히 선호하지 않는다면, 이는 자동 지표가 놓친 부분이 있음을 시사합니다.
작업별 하이브리드 지표: 때로는 지표 자체가 하이브리드일 수 있습니다. 예를 들어, 대화 시스템을 평가한다고 가정해 봅시다. 참조 답변과의 의미적 유사도 부분(BERTScore 사용), 규칙 위반에 대한 패널티(금지 표현을 사용했는지 여부를 정규식 또는 분류기로 검출), 그리고 공손한 표현을 사용했을 때의 소폭 보너스(공손 표현 목록 기반)를 포함한 복합 점수를 만들 수 있습니다. 이런 지표는 인간의 우선순위(정확성, 안전성, 공손함)를 반영하는 자동화 구성요소(임베딩 유사도, 분류)를 혼합합니다. 최종 “점수”는 인간의 총체적 판단을 근사하려는 시도입니다. 적절히 튜닝한다면, 이러한 복합 지표는 최종 인간 검토에 앞서 모델들을 순위화하는 데 유용할 수 있습니다.
벤치마크 + 인간 시너지: 벤치마크로 약점을 진단한 뒤, 새로운 테스트는 인간의 창의성으로 설계하세요. 예를 들어, 모델이 표준 수학 문제에서는 만점을 받지만 사용자는 여전히 까다로운 언어 퍼즐에서 어려움을 겪는다고 느낀다면, 평가자는 새로운 적대적 예시를(수작업으로 혹은 LLM의 도움을 받아) 만들어 평가 세트에 추가할 수 있습니다. 시간이 지남에 따라 이렇게 하면 자동화된 벤치마크가 인간이 확인한 엣지 케이스들을 포함하도록 풍부해집니다.

의료 데이터셋에서 가져온 100개의 알려진 질문–답변 쌍으로 테스트하고, 자동화 지표로 Exact Match 또는 F1을 측정합니다.
또한 참조 답변과의 BERTScore 또는 의미적 유사도를 측정합니다(자동화).
의료 전문가가 답변 50개를 검토해 정확성을 평가합니다(인간 평가).
와 같은 LLM을 사용하세요 GPT-4 그 답변도 다시 한 번 교차 확인합니다(LLM 판정).
전문가의 리뷰와 GPT-4의 리뷰를 비교해 두 평가가 대체로 일치하면, 더 많은 질문을 1차 선별하는 역할을 GPT-4에 맡길 수 있습니다.
배포 후에는 사용자 피드백을 모니터링��� 낮은 평점을 받은 답변을 수집합니다. 주기적으로 사람이 그 사례들을 검토해 무엇이 잘못됐는지 확인합니다(예: 답변이 실제로 틀렸는지, 아니면 맞았지만 사용자가 이해하지 못했는지).
그 결과를 모델 개선에 반영하고, 다음 버전을 위한 평가 세트에도 포함해 평가 선순환을 완성합니다.

LLM 모델 평가 vs. LLM 시스템 평가

모든 모델에 동일한 프롬프트 형식을 사용합니다(예: 제로샷 프롬프트 또는 퓨샷 프롬프트).
외부 도구를 사용하지 않고, 모델이 학습한 지식에 의존합니다.
모델이 생성한 작업 출력에 대해 정확도, BLEU 등과 같은 직접 지표를 측정합니다.

특정 프롬프트 전략(잘 설계된 지시문이나 모델의 출력을 유도하기 위한 퓨샷 예시 컨텍스트 등).
모델이 답변을 생성하기 전에 시스템이 데이터베이스에서 관련 문서를 검색해 프롬프트에 포함시키는, RAG(검색 증강 생성) 구성일 수도 있습니다.
모델의 원시 출력을 수정하는 후처리 또는 필터(예: 답변 형식화, 특정 콘텐츠 검열).
사용자 상호작용 루프: 예를 들어, 과거 대화를 기억하는 챗봇(프롬프트에 채팅 기록이 포함되어 시스템 상태의 일부가 됨)이나 최종 답변을 생성하는 과정에서 계산기 같은 외부 API를 호출할 수 있는 도구 활용 에이전트.

독립형 모델은 보통 통제된 프롬프트 하에서 고정형 벤치마크로 평가하는 반면, 전체 시스템은 대개 시뮬레이션된 또는 실제 사용자 시나리오에서, 경우에 따라 상호작용 방식이나 맞춤형 테스트 하네스를 사용해 평가합니다.
시스템에서는 프롬프트 엔지니어링이 “해결책”의 일부로 간주됩니다. 프롬프트 엔지니어링이 뛰어난 약한 모델이, 프롬프트가 부실한 강한 모델보다 특정 작업에서 더 나은 성능을 낼 수 있습니다. 따라서 시스템 평가는 모델과 프롬프트의 시너지를 측정합니다.
시스템에서는 모델 출력 품질 외에도 추가 지표를 두는 경우가 많습니다. 예를 들어, RAG 시스템에서는 검색된 문서의 품질(리트리버가 올바른 정보를 찾았는지)을 측정할 수 있습니다. 멀티턴 시스템에서는 대화 길이나 작업 완료 성공률(예: 대화를 통해 항공편을 예약하는 경우)을 측정할 수 있습니다.
시스템을 평가한다는 것은 때때로 그것을 블랙박스로 취급하는 것을 의미합니다. 즉, 입력을 제공하고(사용자 대화나 지식 베이스 질의처럼 복잡할 수 있음) 최종 출력이나 결과를 확인하는 방식입니다.

프롬프트 엔지니어링: LLM에 어떤 프롬프트를 주느냐에 따라 성능이 크게 달라질 수 있습니다. 따라서 시스템을 평가할 때는 최적이거나 의도한 프롬프트를 사용하고 있는지 반드시 확인해야 합니다. 예를 들어, GPT-3는 순진한 프롬프트로는 질문을 틀릴 수 있지만, “단계를 나눠서 생각해 보자” 같은 지시와 후속 응답 형식을 추가하면 정답을 맞힐 수도 있습니다. 시스템에서는 이러한 프롬프트 조정이 설계의 일부가 됩니다. 그래서 시스템을 평가하면, 프롬프트 없이 기본 모델을 평가할 때보다 정확도가 훨씬 높게 나올 수 있습니다. 이는 프롬프트 해킹을 활용해 모델의 약점을 보완하기 때문에, 시스템 평가가 때로는 더 낙관적으로 보일 수 있음을 의미합니다. 평가에는 사용한 프롬프트를 문서화해야 합니다. 프롬프트가 달라지면 사실상 다른 모델을 평가하는 것과 비슷하기 때문입니다. 본질적으로 프롬프트는 시스템 동작의 핵심 요소이며, 코드와 같습니다. 따라서 시스템 평가는 프롬프트 튜닝 단계를 거친 뒤, 테스트 시 그 프롬프트를 고정하는 절차를 포함할 수 있습니다. 시스템 간 비교를 할 때는 공통 프롬프트를 강제하기보다는, 각 시스템이 최적의 프롬프트를 사용하도록 하는 것이 바람직합니다. 이 시점에서의 목표는 모델 간 형평성이 아니라 최종 품질이기 때문입니다.
검색 증강 생성(RAG): RAG 시스템에서는 모델이 모든 지식을 내부에 갖고 있을 것으로 기대하지 않고, 대신 외부 소스(예: 위키피디아나 기업 문서 저장소)에서 정보를 가져옵니다. 따라서 RAG 시스템을 평가할 때는 검색 성능과 생성 성능을 모두 고려해야 합니다.
Recall@K 같은 검색 지표를 측정할 수 있습니다(상위 K개의 검색 문서에 정답이 포함되었는가?). 검색기가 실패하면, 모델 자체 성능이 아무리 좋아도 잘못된 정보를 출력할 가능성이 큽니다.
최종 답변도 평가합니다. 정답이었고 형식이 적절했나요? 모델이 관련 문서를 갖고 있었다면, 그것을 올바르게 활용했나요?
때로는 출처 표기를 평가하기도 합니다. 시스템이 검색을 통해 얻은 정보의 출처를 올바르게 인용하는가를 확인하는 것이죠. 그것이 요구사항이라면(예: Bing의 검색 기반 챗봇이 출처를 인용하는 경우처럼), 평가에서는 제시된 출처가 실제로 답변을 뒷받침하는지까지 검증할 수 있습니다.
한 가지 난점은, 시스템이 정답을 맞혔다면 그것이 모델이 원래 알고 있어서였는지, 아니면 검색으로 정보를 찾아서였는지 구분하기 어렵다는 점입니다. 반대로 틀렸다면 모델의 환각 때문인지, 검색기의 오류 때문인지도 가려야 합니다. 이를 명확히 하기 위해 평가자들은 종종 어블레이션을 수행합니다. 즉, 데이터셋에 대해 검색기만 따로 평가하여 정보검색 지표를 측정하고, 정답 문서(골드 문서)를 제공한 상태에서 생성기를 평가해 올바른 정보가 주어졌을 때 모델의 능력을 확인합니다. 이렇게 하면 시스템의 실패가 검색 누락 때문인지, 생성 과정의 실수 때문인지 구분할 수 있습니다. 예를 들어, 어떤 연구가 다음과 같이 보고할 수 있습니다. “우리의 RAG 시스템은 전체 질문의 85%에 정답을 냈다. 올바른 문서를 검색한 경우 그 중 95%를 정확히 답했지만, 관련 문서가 누락되면 완전히 실패했다. 검색기의 Recall@5는 90%였으며, 이는 대다수 실패가 소수의 질의에서 검색이 실패했기 때문임을 시사한다.” 이러한 통찰은 검색 성능을 개선하면 시스템 전체 성능을 더 크게 끌어올릴 수 있음을 보여 줍니다.
파이프라인 최적화: 많은 시스템은 여러 단계로 이루어진 파이프라인을 갖습니다. 예를 들어:
사용자 질의를 사전 처리합니다(의도를 분류할 수도 있음).
필요하면 문서를 검색하십시오.
해당 문서들을 포함해 LLM에 전달할 프롬프트를 작성하십시오.
답변을 생성한 뒤 후처리를 수행하세요(예: 허용되지 않은 콘텐츠를 제거).
마지막 점검 단계로, 답변이 명백히 틀리거나 공격적이지 않은지 확인하는 작은 모델을 두는 것도 좋습니다.
이러한 파이프라인을 평가하려면 각 단계마다 단위 테스트를 수행하고(1단계 분류기 평가, 2단계 검색기 평가 등) 최종적으로 전체 테스트를 병행해야 합니다. 이는 소프트웨어 테스트와 유사합니다. 구성 요소에 대한 단위 테스트와 전체 시스템에 대한 통합 테스트를 함께 진행하는 방식입니다. LLM 시스템의 경우:
파이프라인이 다양한 유형의 질의를 얼마나 잘 처리하는지 평가할 수 있습니다. 예를 들어, 시스템이 수학 질문을 계산기 도구로 올바르게 라우팅하는지 확인합니다. 몇 가지 수학 질의를 테스트해 1단계에서 수학으로 분류했는지, 3단계에서 계산기 사용을 포함했는지 살펴보면 됩니다. 이는 LLM 자체만 평가하는 것이 아니라, 그 주변의 의사 결정 로직도 함께 평가하는 것입니다.
파이프라인에서의 프롬프트 최적화: 많은 파이프라인은 여러 단계에서 프롬프트를 사용합니다(예: 검색을 위해 사용자 질의를 정규화하는 프롬프트, 최종 답변을 위한 프롬프트 템플릿). 이들 각 프롬프트는 튜닝될 수 있으며, 평가 시점에는 고정해야 합니다. 프롬프트를 업데이트했다면, 동작이 크게 바뀔 수 있으므로 반드시 다시 평가해야 합니다.
통합 지표: 시스템 평가는 복합 지표를 활용할 수 있습니다. 예를 들어 QA 시스템의 경우, 출처 인용을 포함한 정답 정확도와 같은 지표를 정의할 수 있습니다. 즉, 정답을 맞히는 것뿐 아니라 그 정답을 포함하는 출처 문서를 함께 인용했을 때에만 정답으로 간주합니다. 이러한 지표는 단순히 맞는지 여부뿐 아니라 답변을 정당화하는 능력까지 평가합니다. 기본 모델만으로는 이런 방식으로 평가하지 않겠지만, 출처 인용이 시스템 기능이기 때문에 시스템 평가는 해당 기준을 적용합니다.
사용자 경험 요소 시스템 평가는 종종 UX에 중요한 지표를 포함합니다. 예를 들어 지연 시간(응답 속도가 충분히 빠른가?), 일관성(대화 전반에 걸쳐 페르소나/톤을 유지하는가?), 문맥 처리(이전에 사용자가 말한 내용을 기억하는가?) 등이 있습니다. 예를 들어, 채팅 시스템을 평가할 때는 모델이 문맥을 제대로 기억하는지 확인하기 위해 멀티턴 대화를 사용합니다. 기본 모델은 단일 턴의 질의응답에는 강할 수 있지만, 대화형 시스템 맥락에서 평가해 보면 세심한 관리가 없으면 두 턴 전에 준 지시를 잊는 문제가 드러날 수 있습니다. 따라서 프롬프트의 대화 이력이나 메모리 모듈을 갖춘 시스템을 더 긴 상호작용에서 평가합니다. 예컨대 5턴 대화에서 사용자가 정보를 다시 말해 줘야 하는 빈도 대비 모델이 스스로 기억해 내는 비율을 측정해 문맥 유지율로 삼을 수 있습니다.

단독 평가: 어떤 도움도 없이 모델을 상식 퀴즈로 시험해 봅니다. 모델 매개변수에 일부 사실이 없어서 정답률이 30%에 그칠 수도 있습니다.
시스템 평가: 모델이 웹 검색(RAG)을 사용할 수 있게 합니다. 이제 정답을 조회할 수 있으므로 정확도가 80%까지 오를 수 있습니다. 동일한 모델이라도 도구를 덧붙이면 시스템은 훨씬 좋아집니다. 따라서 단독 평가만 보면 실제로 배포된 시스템의 능력을 과소평가하게 됩니다. 반대로, 시스템에 결함이 있다면(예: 느린 검색으로 인한 지연, 간헐적으로 오작동하는 프롬프트 등), 시스템 평가는 단독 평가에서 놓칠 문제들을 포착합니다.

온라인 평가와 오프라인 평가 전략

오프라인 평가(출시 전 및 통제된 테스트)

과거 데이터나 특별히 준비된 데이터를 대상으로 수행됩니다.
환경이 통제되어 있습니다. 입력은 명확히 파악되어 있고, 평가 기준은 미리 정해져 있습니다.
사용자와의 실시간 상호작용은 없으며, 단방향 평가입니다. 우리가 입력을 주고 출력 결과를 관찰한 뒤, 정답(그라운드 트루스)이나 목표하는 속성에 비춰 성능을 측정합니다.

안전과 위험 완화: 검증되지 않은 모델의 행동을 사용자에게 노출하지 않게 됩니다. 모델에 심각한 결함이 있다면(예: 공격적인 콘텐츠를 생성하거나 매우 틀린 답을 내는 경우), 사용자에게 피해를 주거나 회사의 평판을 해치기 전에 오프라인에서 이를 발견할 수 있습니다. 사람이 운전하기 전에 더미로 자동차 충돌 테스트를 하는 것과 같습니다.
재현성: 각 모델 변형을 동일한 데이터셋으로 평가할 수 있어 공정한 비교가 가능하고 통계적 유의성 계산도 더 쉬워집니다. 오프라인 테스트는 반복 가능하므로, 평가가 자동화되어 있다면 원하는 만큼 여러 번 실행할 수 있습니다.
분석의 깊이: 실환경에서는 어려운 정교한 평가 데이터셋과 절차를 충분히 준비할 수 있습니다. 예를 들어, 수많은 엣지 케이스, 긴 입력, 드문 시나리오 등을 포함해 모델을 강도 높게 스트레스 테스트할 수 있습니다. 오프라인 환경에서는 출력물을 철저히 분석할 수 있으며, 필요하다면 수작업으로 직접 검토하는 것도 가능합니다.
커버리지: 오프라인 테스트에서 중요한 입력 범주들이 반드시 포함되도록 보장할 수 있습니다(실제 트래픽에서는 드물더라도). 예를 들어, 비서가 의료 조언과 관련된 질문을 안전하게 처리할 수 있는지 확실히 하고 싶다면, 사용자가 그런 질문을 하기를 기다리며 기대하는 대신 해당 항목들을 오프라인 테스트 세트에 포함하면 됩니다.
반복적 개발: 오프라인 평가는 빠른 실험을 가능하게 합니다. 동일한 데이터셋에서 여러 모델 변형을 병렬로 테스트해, 각각을 사용자에게 배포하지 않고도 어떤 것이 최적인지 즉시 확인할 수 있습니다. 이는 개발 속도를 높여 줍니다.

완전한 대표성을 갖지 않음: 아무리 테스트 세트가 훌륭해도 실제 사용자 질의의 전체 다양성이나 분포를 완전히 담지 못할 수 있습니다. 모델이 오프라인에서는 뛰어나더라도 운영 환경에서 예기치 않은 입력을 만나 흔들릴 수 있습니다. 예를 들어, 테스트 질문에는 속어가 전혀 없었지만 실제 사용자는 속어를 쓸 수 있습니다. 오프라인 평가는 이런 점을 놓칠 수 있습니다.
정적: 오프라인 테스트는 종종 정답이 하나이거나, 무엇이 좋은지에 대한 정적인 기준만을 가집니다. 또한 상호작용적 측면을 포착하지 못할 수 있습니다. 예를 들어, 답��이 불명확하면 사용자가 질문을 다시 표현할 수 있는데, 오프라인 평가는 보통 이러한 주고받는 과정을 시뮬레이션하지 않습니다.
평가에 과적합하기 개발자가 오프라인 데이터셋(이미 알고 있는)에 맞춰 모델이나 프롬프트를 과도하게 조정하면, 사실상 테스트 세트에 과적합될 위험이 있습니다. 이렇게 되면 모델이 테스트 문항에는 유독 잘 맞지만 일반화 성능은 떨어질 수 있습니다(일종의 ‘시험 대비식 가르치기’와 유사). 따라서 크고 다양한 평가 세트를 갖추고, 이를 학습 과정에 유출하지 않는 것이 중요합니다.
실제 사용자 판단의 부재: 오프라인 지표에서는 모델이 더 낫다고 나오더라도, 사용자는 그 차이를 체감하지 못할 수 있습니다. 예를 들어, 새로운 모델이 정확도 점수는 더 높게 나오지만, 사용자들이 싫어하는 말투를 가질 수도 있습니다. 이런 문제는 온라인 평가를 하기 전까지 드러나지 않습니다.

XSum 같은 요약 데이터셋의 검증 세트 전체에 모델을 실행하고 ROUGE 점수를 계산하기.
배포 전에 전적으로 사내에서 진행하여, 큐레이션한 1,000개 프롬프트 세트를 사용하고 외부 평가 인력을 통한 출력물의 평균 인간 평점을 두 모델 버전 간 비교하기.
적대적 테스트: 문제를 일으키는 것으로 알려진 함정 질문이나 입력 목록을 만들어, 모델이 각 항목을 어떻게 처리하는지 확인합니다(체크리스트 형식의 평가로 각 시나리오에 대해 통과/실패를 표시).
평가 하니스: EleutherAI의 Language Model Evaluation Harness나 HuggingFace의 평가 라이브러리 같은 도구를 사용하면 다양한 태스크를 오프라인에서 손쉽게 실행할 수 있습니다. 개발자는 이를 활용해 수십 가지 벤치마크에서 모델의 성적표를 빠르게 오프라인으로 받아볼 수 있습니다.

온라인 평가(실시간 배포 및 사용자 피드백)

실제 사용자나 라이브 데이터 스트림에서 발생합니다. 사용자는 자신이 평가에 참여하고 있다는 사실을 모를 수도 있습니다. 두 버전의 A/B 테스트라면, 사용자가 보는 것은 평소처럼 작동하는 제품뿐이기 때문입니다.
성공 기준은 실제 사용자 행동이나 피드백입니다. 애플리케이션에 따라 클릭, 평점, 전환, 체류 시간, 오류율 등이 해당됩니다.
온라인 평가는 제품이 운영되는 한 계속됩니다. 서비스가 라이브인 동안에는 평가 데이터를 지속적으로 수집할 수 있습니다. 반면 오프라인 평가는 고정된 데이터셋으로 한 번 수행하는 방식입니다.

현실 검증: 온라인 평가는 실제 사용에서 벌어지는 모든 것을 포착합니다. 질의 분포, 사용 맥락, 그리고 사용자의 진짜 선호까지 포함합니다. 결국 핵심 질문에 답합니다. 모델이 실제로 사용자 경험을 더 좋게 만드는가? 객관적으로 더 똑똑한 새 모델임에도, 어떤 이유로 사용자들이 예전 모델을 더 선호한 사례들이 있습니다(예: 새 모델이 느리거나 과도하게 장황함). 이런 사실은 온라인 테스트를 통해서만 드러납니다.
알려지지 않은 위험 발견하기: 사용자는 창의적이고 다양합니다. 개발자가 예상하지 못한 입력 패턴이나 엣지 케이스를 찾아낼 가능성이 큽니다. 온라인 모니터링을 통해 새로운 실패 양상이 드러날 수 있습니다(예: “사용자들이 계속 이상한 질문을 하고, 모델이 엉뚱한 답을 내놓네 — 오프라인에서는 한 번도 테스트하지 않았어!”). 이는 모델이 현실의 모든 복잡성과 직접 맞닥뜨리게 하여, 보다 정직한 상태를 유지하도록 합니다.
비즈니스 지표 측정하기: LLM이 제품의 일부라면 사용자 유지율, 작업 성공률, 고객 만족도 점수, 매출 등 핵심 지표를 갖고 있을 수 있습니다. 모델 변경과 이러한 지표의 변화를 연관 지어 분석할 수 있습니다. 예를 들어 가상 비서 모델을 개선했더니 사용자가 고객 지원 센터에 전화하는 빈도가 10% 감소했다면, 이는 온라인 배포를 통해서만 드러나는 매우 큰 성과입니다.
지속적 개선: 온라인 평가는 지속적인 피드백 루프를 가능하게 합니다. 상호작용 로그와 같은 데이터를 꾸준히 수집하여 파인튜닝이나 프롬프트 수정 등을 통해 모델을 개선할 수 있습니다. 이는 단순한 평가를 넘어, 학습을 위한 데이터 수집이기도 합니다. 실제로 많은 배포 시스템은 주기적으로 로그를 필터링·라벨링한 뒤 재학습하여 성능을 높입니다. 그런 의미에서 평가와 학습은 맞물립니다. 적절한 절차를 거치면 사용자 피드백이 곧 학습 데이터가 됩니다.

위험:" 충분히 검증되지 않은 모델을 사용자에게 배포하면 피해가 발생할 수 있습니다. 모델이 사용자에게 불쾌감을 주거나 잘못된 내용을 말하면 실제 비용이 듭니다(사용자를 불쾌하게 하거나 허위 정보를 확산시키는 등). 그래서 온라인 평가는 보통 점진적으로 진행합니다. 예를 들어 잠재적 피해를 줄이기 위해 전체 사용자 중 1%부터 시작하는 카나리 배포를 적용합니다.
노이즈와 변동성: 사용자 행태에는 분산이 크고 외부 요인의 영향도 많습니다. 예를 들어 새 모델 버전을 배포했는데 동시에 무관한 사건으로 서비스 이용자가 늘거나, 공휴일 주간 때문에 사용 패턴이 바뀌면, 모델 변경의 효과만 따로 떼어 확인하기가 어렵습니다. 그래서 무작위 배정과 통계 분석을 갖춘 정교한 A/B 테스트가 결론을 내리는 데 필요합니다. 또한 지표에서 통계적으로 유의미한 결과를 얻으려면 충분한 표본 크기가 필요하며, 이는 시간이 걸릴 수 있습니다.
지연되거나 암묵적인 피드백: 오프라인 평가에서는 즉시 점수를 얻습니다. 온라인에서는 피드백이 암묵적일 수 있습니다. 예를 들어 사용자가 답변에 불만이 있으면 질문을 다르게 바꾸어 묻거나 대화를 중단할 수 있는데, 이런 신호로부터 불만을 추론해야 합니다. 명시적 피드백(엄지척/내림 버튼 등)은 유용하지만 모든 사용자가 활용하지는 않습니다. 또한 어떤 결과는 장기적으로 나타납니다(다음 주에 사용자가 다시 돌아왔는가? 이는 AI가 유용했는지 여부를 시사할 수 있습니다). 따라서 모델 성능을 이러한 지표들과 연결하는 일은 복잡하며, 보통 정교한 로깅과 분석이 필요합니다.
지속적인 분포 변화: 현실 세계는 정적이지 않습니다. 오늘의 사용자 질의는 한 달 뒤와 달라질 수 있습니다(트렌드, 뉴스, 계절성 등). 세상이 변하면 모델 성능이 점차 떨어질 수도 있습니다(예: 새로운 속어가 등장하거나 모델이 알지 못하는 새로운 사건이 발생하는 경우). 이러한 드리프트를 포착하려면 온라인 평가가 필요합니다. 다만 언제 모델의 성능 변화가 의미 있는 수준에 이르렀는지 판단해야 하므로 어려움이 있습니다. 그 판단은 업데이트 필요성을 촉발할 수 있습니다. 요컨대 온라인 평가는 한 번으로 끝나는 일이 아니라, 계속 이어지는 과정입니다.
사용자 프라이버시와 윤리: 실제 사용자 데이터를 평가에 활용할 때는 프라이버시를 존중하도록 세심하게 진행해야 합니다. 로그를 분석한다면 개인 데이터가 적절히 처리되도록(익명화, 필요 시 옵트아웃 제공 등) 보장해야 합니다. 실험을 수행하는 경우, 일반적으로 서비스 약관을 통해 사용자에게 고지하는 것이 바람직합니다(많은 기업이 “품질 향상을 위해 서비스의 다양한 버전을 테스트할 수 있습니다”와 같은 조항을 포함합니다). 특히 민감한 도메인에서는 윤리적 검토가 필요할 수 있습니다.

평균 응답 길이, 평균 응답 시간.
사용자가 질문을 다시 표현한 세션의 비율(초기 응답 품질이 낮았음을 시사할 수 있음).
에스컬레이션 빈도(지원 봇인 경우, 실패하여 인간 상담원에게 넘기는 비율).
시간에 따른 사용자 평점
플래그된 콘텐츠(가능한 정책 위반을 자동 필터가 표시하는 경우, 해당 경고가 얼마나 자주 발생하는지도 모니터링).

1단계: 오프라인 평가(통과 기준 필수)
2단계: 내부 테스트(임직원 또는 신뢰할 수 있는 소규모 사용자 그룹).
3단계: 소수의 사용자에게 온라인 A/B 테스트를 수행합니다.
4단계: 지표가 양호하면 점진적으로 더 많은 사용자에게 확대합니다.
5단계: 검증이 완료되면 전면 배포.
전면 배포 이후에도 예기치 않은 문제가 발생해 롤백이 필요할 수 있으니, 이전 모델 등으로 대체할 수 있는 폴백을 항상 준비해 두세요.

오프라인의 장점: 통제된 환경, 빠른 반복, 낮은 비용, 사용자 위험 없음.
오프라인의 단점: 실제 사용자 요구나 모델의 실제 사용 성능을 반영하지 않을 수 있습니다.
온라인의 장점: 실제 피드백, 궁극적으로 중요한 것(사용자 만족도와 성공)을 측정합니다.
온라인의 단점: 위험, 복잡성, 결과 도출 지연(충분한 사용자와 시간이 필요), 견고한 모니터링 인프라 필요.

W&B Weave를 활용한 LLM 평가

W&B Weave 개요와 주요 기능

LLM 실행 흐름 추적:" Weave는 LLM 애플리케이션이 거치는 일련의 단계를 포착할 수 있습니다. 예를 들어, 모델에 제공된 프롬프트, 모델의 출력, 그리고 중간 계산 과정까지 기록할 수 있습니다. 애플리케이션이 체인 오브 소트(chain-of-thought)나 도구를 사용하는 에이전트를 활용한다면, Weave는 에이전트가 수행하는 각 함수 호출을 로깅합니다. 개발자는 한 줄의 코드나 데코레이터만 추가하면 되고, Weave가 해당 함수들의 입력과 출력(즉, LLM의 추론 흔적)을 자동으로 기록합니다. 그 결과 살펴볼 수 있는 트레이스 트리(trace tree)가 생성됩니다. 다시 말해, Weave는 중간 단계부터 최종 출력까지 포함해 LLM의 실행 흐름을 시각화하고 점검할 수 있도록 도와줍니다.
프롬프트와 응답의 자동 로깅: Weave를 사용하면 프롬프트와 모델 답변을 분석하려고 일일이 출력하고 복사해 붙여넣을 필요가 없습니다. LLM에 보낸 모든 프롬프트와 받은 응답을 모델 이름, 타임스탬프, 온도와 같은 파라미터 등 메타데이터와 함께 자동으로 로깅합니다. 이는 각 테스트 케이스에서 무엇을 물었고 무엇이 답변되었는지 정확히 검토할 수 있으므로 평가에 매우 유용합니다. 프롬프트를 서로 비교하고, 미세한 프롬프트 변경이 출력에 어떤 영향을 미치는지도 확인할 수 있습니다.
주요 LLM 라이브러리 지원: Weave는 OpenAI API, Anthropic API, LangChain, LlamaIndex 등의 라이브러리와 API와 통합됩니다. 이러한 도구를 사용한다면, Weave는 많은 추가 코드 없이도 해당 호출에 후킹할 수 있습니다. 예를 들어, LangChain으로 대화를 관리할 경우, Weave는 체인의 각 단계를 포착할 수 있습니다. 이는 곧 이러한 도구를 사용하는 시스템을 평가할 때, Weave가 각 구성 요소의 입력과 출력(예: 검색된 내용과 생성된 내용)을 모두 기록한다는 뜻입니다.
사용자 지정 지표 로깅: Weave는 W&B의 로깅을 기반으로 하므로 임의의 값이나 지표를 기록할 수 있습니다. 예를 들어, 답변을 생성한 뒤 그 답변에 대해 BERTScore 또는 유해성 점수(toxicity score)를 계산해 로깅할 수 있습니다. Weave는 이러한 지표를 트레이스와 함께 저장합니다. 이렇게 하면 나중에 해당 지표로 출력물을 필터링하거나 정렬할 수 있습니다. 예: 유해성 점수가 높은 모든 사례를 찾아 UI에서 그 출력들을 자세히 검토할 수 있습니다.
비교와 벤치마킹: Weave는 서로 다른 런을 비교할 수 있는 UI를 제공합니다. 런은 특정 입력 집합에 대해 모델 또는 시스템 버전을 평가한 결과에 해당할 수 있습니다. 예를 들어 런 A(모델 v1을 테스트 세트에 적용)와 런 B(같은 테스트 세트에 모델 v2 적용)가 있을 때, UI는 두 런의 집계 지표를 보여주고 각 입력에 대한 출력을 나란히 비교할 수 있게 해줍니다. 각 행이 테스트 프롬프트이고, 열에는 모델 v1 출력과 모델 v2 출력, 그리고 필요하다면 인간 기준 답변 또는 점수가 표시되는 표로 확인할 수도 있습니다. 이를 통해 어떤 지점에서 한 모델이 다른 모델보다 더 잘했는지 쉽게 파악할 수 있습니다. 요컨대, Weave는 모든 모델 버전과 프롬프트 변형을 위한 벤치마킹 대시보드처럼 동작합니다.
시각화와 검색: 구조화된 방식으로 데이터를 로깅하므로 조회할 수 있습니다. 예를 들어, 정답 여부에 대한 플래그나 지표가 있다면 모델의 답변이 틀린 사례만 필터링할 수 있습니다. 또는 모델 출력에서 특정 키워드를 검색해 특정 오류나 문구가 나타난 모든 사례를 찾을 수도 있습니다. UI에는 차트도 제공됩니다. 예: 지표의 분포. 예컨대 답변 길이 또는 지연(latency)을 로깅했다면, 해당 값들의 히스토그램이나 시계열 그래프를 확인할 수 있습니다. 이는 효율성 지표나 변동성을 평가하는 데 도움이 됩니다.
트레이스와 패널: Weave UI에서는 LLM 호출의 트레이스(특히 다단계인 경우)를 시각화할 수 있습니다. 예를 들어, 에이전트가 추론을 위해 자기 자신과 대화를 나누는 방식(스크래치패드)을 사용했다면, Weave가 해당 chain-of-thought을 보여줄 수 있습니다. 이는 평가 시 모델이 특정 답을 내놓은 이유를 이해하는 데 유용합니다. 트레이스에서 잘못된 문서를 검색해 그 결과 오답이 나온 것을 확인할 수도 있는데, 이러한 분석은 시스템 개선에 큰 가치를 제공합니다. 프롬프트, 검색, 생성 중 어디에서 문제가 발생했는지 정확히 짚어내는 Weave의 능력은 평가자에게 매우 큰 도움이 됩니다.
협업과 보고서: Weave는 호스팅형(또는 자체 호스팅 가능)이므로 팀원이 로그인하여 평가 결과를 확인할 수 있습니다. 특정 비교 화면의 링크를 공유하거나 보고서를 만들 수도 있습니다. 이는 평가 진행 상황을 추적하는 데 유용합니다. 예: “우리 평가 세트에서의 모델 v2 vs v1 — v2가 여전히 실패하는 예시를 확인하세요”와 같이 요약한 보고서를 만들 수 있습니다. 이런 자료는 문서화 용도로도 쓰이며, 나중에 다시 참조할 수 있습니다.

자동 추적, 벤치마킹, 시각화를 위한 Weave 활용

코드에 Weave 설정하기: 스크립트나 애플리케이션을 시작할 때 Weave를 초기화합니다(예: weave.init(project="LLM_eval", run="experiment_42")). LLM을 호출하거나 중요한 단계를 수행하는 함수가 있다면, 해당 함수에 주석을 달아 표시합니다(Weave는 이를 위한 @weave.op 데코레이터를 제공합니다). 이렇게 하면 해당 함수 호출이 Weave에 자동으로 기록됩니다. 예를 들어, 함수가 있다면 get_answer(prompt): ... 모델을 호출해 답을 반환하는 함수에 데코레이터를 적용하면 입력(프롬프트)과 출력(응답)이 기록됩니다. 이렇게 최소한의 코드 변경만으로도 매우 풍부한 로그 정보를 얻을 수 있습니다.
평가 데이터세트를 모델에 실행하기: 예를 들어 테스트 문항이 100개 있다고 가정해 봅시다. 당신은 자신의 get_answer 각 항목에 대해 해당 함수를 실행합니다(예: 루프에서). 실행되는 동안 Weave가 각 호출을 캡처합니다. 또한 각 답변 후에 메트릭을 기록할 수도 있습니다(예: wandb.log({"accuracy": correctness}) 점수를 매길 방법이 있다면). 이렇게 수집된 모든 데이터(프롬프트, 답변, 메트릭)는 W&B 백엔드로 전송됩니다.
Weave UI에서 결과 살펴보기: 이제 W&B 대시보드에서 해당 런을 엽니다. 각 호출이 객체로 기록된 인터페이스가 보일 수 있습니다. 특정 입력을 클릭하면 상세 정보를 확인할 수 있습니다. 예: Prompt = "Who is the CEO of OpenAI?" -> Model Output = "Sam Altman." 정답이므로 correctness = True를 기록했을 수도 있습니다. Weave를 사용하면 모든 예시를 쉽게 스크롤하며 살펴볼 수 있습니다. 출력이 잘못된 것처럼 보이면 태그를 달거나 메모를 남길 수 있습니다. 이는 로그를 수동으로 확인하는 것보다 훨씬 효율적입니다. 깔끔한 목록이 있고, 기록해 두었다면 참고 정답도 함께 볼 수 있기 때문입니다.
여러 번의 실행 벤치마킹: 새로운 프롬프트 형식이나 새로운 모델을 시도한다고 가정해 봅시다. 동일한 테스트 문항으로 다시 한 번 실행합니다. 이제 Weave에서 런 A와 런 B를 비교할 수 있습니다. 인터페이스에는 다음과 같은 방식으로 표시될 수 있습니다:
질문 5: "프랑스의 수도는 무엇인가요?"
런 A 답변: "파리."
런 B 답변: "프랑스의 수도는 파리입니다."
둘 다 정답입니다(accuracy = True). 하지만 런 B가 더 장황할 수 있습니다. 간결함이 목표였다면 그 점을 기록해 둡니다.
또는 다른 문항에서는 런 A가 틀리고 런 B가 맞을 수도 있습니다. 그런 경우만 필터링하여 어떤 유형의 질문에서 성능이 개선되었는지 확인할 수 있습니다. 이런 비교는 개선 폭을 정량화하는 데 도움이 될 뿐 아니라, 실제 출력을 나란히 읽어 보며 정성적으로도 이해하는 데 도움이 됩니다.
전체 지표도 확인할 수 있습니다. 예를 들어 런 A는 100문항 중 80문항 정답, 런 B는 100문항 중 90문항 정답을 얻었을 수 있습니다. Weave는 이를 보여 줍니다(문항별 accuracy를 로깅했기 때문에 UI나 리포트에서 손쉽게 집계할 수 있습니다). 따라서 상위 수준의 지표와 이를 뒷받침하는 세부 예시를 모두 갖게 됩니다. LLM 평가에서는 단일 총점만으로는 전체 맥락을 설명하기 어려운 경우가 많아, 이런 유형의 분석이 매우 중요합니다.
시각화: 각 답변에 대한 응답 시간이나 토큰 사용량도 로깅했다고 가정해 봅시다(Weave는 모델 출력을 캡처할 수 있으며, 타임스탬프 차이를 계산해 지연 시간 등을 얻을 수 있습니다). 그러면 W&B UI에서 “프롬프트 길이별 정렬된 답변당 토큰 사용량”과 같은 플롯을 만들어 효율성을 평가할 수 있습니다. 또는 문항 유형에 라벨을 붙였다면, 범주별로 분해한 정확도를 막대그래프로 볼 수도 있습니다. Weave는 커스텀 패널을 지원하므로, 범주로 예시를 필터링하고 정확도를 보여 주는 패널을 만들 수 있습니다. 예를 들어 라벨을 달아 두었다면 “과학 질문 vs 역사 질문 정확도” 같은 비교가 가능합니다. 만약 모델이 과학 분야에서 훨씬 나쁘게 나온다면, 그 부분에 집중해야 한다는 신호를 얻을 수 있습니다. 이러한 시각 분석은 수동으로는 어렵지만, 모든 데이터를 구조적으로 로깅해 두면 간단합니다.
사례 연구 / LLMOps 파이프라인 통합: LLMOps 맥락(LLM의 지속적 통합)에서는 새 모델을 학습하거나 프롬프트를 바꿀 때마다 평가 런을 실행하고 Weave에 로깅하도록 설정할 수 있습니다. 시간이 지나면 여러 런이 쌓여 실험 기록처럼 누적됩니다. Weave는 모델 동작의 저장소가 됩니다. 누군가 “최신 모델에서 질문 X 관련 이슈가 해결됐나요?”라고 물으면, 최신 런에서 그 질문을 그대로 검색해 답을 확인할 수 있습니다. 혹은 지금의 답과 3개 버전 전의 답을 나란히 비교할 수도 있죠—모두 손쉽게 접근 가능합니다. 이런 이력 기반 벤치마킹은 실제로 진전을 내고 있는지, 과거 오류를 다시 도입하지 않았는지 확인하는 데 매우 유용합니다.
현장 사례: 코딩 어시스턴트를 만드는 한 AI 스타트업은 Weave를 활용해 새 모델 버전이 동일한 프로그래밍 문제 집합을 어떻게 처리하는지 추적할 수 있습니다. 각 문제에 대해 프롬프트, 코드 출력, 실행 성공 여부, 오류 여부 등을 로깅합니다. Weave에서는 각 버전이 어떤 문제에서 실패하는지 빠르게 파악할 수 있습니다. 예를 들어 버전 1에서 풀었던 문제가 버전 2에서 실패하기 시작했음을 발견할 수 있는데, 특정 지시문 처리 방식에서 회귀가 발생했기 때문일 수 있습니다. 이런 인사이트를 통해 릴리스 전에 문제를 수정할 수 있습니다. Weave가 없었다면 이러한 회귀를 놓쳤을 가능성이 큽니다.

조직: 모든 평가 데이터를 한곳에.
벤치마킹: 실행 간 손쉬운 비교.
시각화: 메트릭과 출력에 대한 차트와 표.
추적 가능성: 로그된 트레이스 덕분에 오류를 특정 단계까지 추적할 수 있는 기능.
협업: 결과를 팀과 공유하고, 노트를 추가하며, 모델 동작에 대한 지식 베이스를 구축하세요.

사용 사례: LLMOps에서의 Weave 활용 사례

사용 사례 1: 챗봇 품질 모니터링 한 ��사가 LLM으로 구동되는 고객 지원 챗봇을 운영하고 있다. 이들은 챗봇을 지속적으로 평가하고 개선하고자 한다. 스테이징 환경에 Weave를 설정하고 테스트 대화 기록을 연결한다. 매일 밤 배포되는 봇의 빌드를 50개의 시뮬레이션 대화 세트(요금 청구 이슈, 기술 지원 등 다양한 주제 포함)를 통해 실행한다. Weave는 대화 흐름을 기록한다: 사용자 메시지 → 봇 응답(내부적으로 사고하는 프롬프트를 사용하기 때문에 체인 오브 소치는 숨김 처리). 다음 날 아침, 팀은 Weave 대시보드를 확인한다. 특정 시나리오(비밀번호 재설정)에서 봇 성능이 하락한 것을 발견한다(혼란스러운 답변을 제공함). 트레이스를 점검한 결과, 지식 베이스 검색에서 오래된 문서를 가져온 것을 알아낸다. 이를 통해 지식 소스를 업데이트하거나 검색 쿼리를 조정해야 한다는 방향을 잡는다. 같은 대시보드에서, 최근 적용한 수정 이후 정중함 점수(분류기로 측정했을 수 있음)가 전반적으로 소폭 개선된 것도 확인한다. 이들은 이러한 발견을 정리해 제품 관리자와 공유할 Weave 보고서를 작성한다. 이 워크플로우는 반복되며, Weave는 문제를 조기에 포착하고 개선을 입증할 데이터를 확보하도록 보장한다.
사용 사례 2: Weave를 활용한 프롬프트 엔지니어링 - 한 개발자가 요약 작업을 위한 프롬프트를 최적화하려고 한다. 후보 프롬프트 템플릿이 5개 있다. 소수의 예시에 대해 일일이 시도하는 대신, 100개 기사 세트에 모든 프롬프트 5개를 실행하고 결과를 Weave에 로깅하는 루프를 만든다(각 프롬프트 변형을 별도의 런으로 기록하거나, 하나의 런에서 그룹 태그를 사용해 구분). Weave에서는 이제 각 기사별로 요약 결과를 나란히 비교할 수 있다. 예를 들어, 프롬프트 C는 가장 짧은 요약을 내지만 핵심 내용을 놓치는 경우가 있고, 프롬프트 A는 더 길지만 더 완전한 요약을 제공할 수 있다. 이들은 일부 샘플에 대해 ROUGE와 인간 선호 점수도 함께 로깅했다. Weave는 프롬프트 B의 ROUGE가 가장 높게 나왔음을 보여주지만, 인간 선호(동료 3명이 Weave의 UI 또는 내보낸 표를 통해 빠르게 평가)에 따르면 가독성 측면에서는 프롬프트 D가 실제로 더 선호되었다. 이러한 근거를 바탕으로, 이들은 균형 잡힌 최종 프롬프트를 결정한다. Weave는 다수의 프롬프트를 테스트하고 결과를 집계하는 복잡성을 관리하는 데 도움을 주었다.
사용 사례 3: 회귀 테스트 모델이 업데이트될 때 중요한 사례에서 성능이 나빠지지 않도록 보장하는 것은 매우 중요합니다. Weave를 회귀 테스트 하네스로 활용할 수 있습니다. 예를 들어, 모델이 반드시 정확히 처리해야 하는 “중요 테스트 케이스” 목록(직접 선별한 200개 질문 등)을 가지고 있다고 합시다. 모델을 업데이트할 때마다 이 케이스들을 실행하고, 해당 버전 라벨을 붙여 Weave 런으로 로깅합니다. 그러면 Weave가 과거에는 통과하던 테스트가 지금은 실패하는지 빠르게 강조해 보여줍니다. 예를 들어, 버전 1은 케이스 37번을 맞췄지만 버전 2는 틀렸을 수 있습니다. 런을 비교하면 이런 차이가 드러납니다. 이를 잡지 못하면 그 회귀가 그대로 프로덕션에 반영될 수 있습니다. Weave를 사용하면 이를 조기에 발견하고 수정할 수 있습니다(특정 프롬프트 조정을 통합하거나 해당 시나리오를 학습 데이터에 추가하는 방식 등). 시간이 지날수록 견고한 회귀 테스트 스위트를 구축하게 되고, Weave의 인터페이스 덕분에 출력물을 수동으로 비교하는 것보다 훨씬 쉽게 점검할 수 있습니다.

구현 예시: Weave로 LLM 출력 평가하기

1단계: Weave로 코드 계측하기

import weave
weave.init(project="trivia-bot-eval", name="model_v1_eval")

# Suppose we have a function that calls the LLM API
@weave.op()  # This will log calls to this function
def get_answer(question: str) -> str:
    # Call the LLM (pseudo-code, could be OpenAI API or others)
    response = llm_api.ask(question)
    return response

2단계: 평가 실행 및 메트릭 기록

# Example test set
test_questions = [
    {"q": "Who is the CEO of OpenAI?", "expected": "Sam Altman"},
    {"q": "What is the capital of France?", "expected": "Paris"},
    # ... more questions
]

import wandb
correct_count = 0
for item in test_questions:
    ques, expected = item["q"], item["expected"]
    answer = get_answer(ques)
    # Simple accuracy metric:
    is_correct = (expected.lower() in answer.lower())
    correct_count += 1 if is_correct else 0
    # Log the result as an artifact of this call
    wandb.log({
        "question": ques,
        "model_answer": answer,
        "expected_answer": expected,
        "correct": is_correct
    })
    
# After loop, log overall accuracy
accuracy = correct_count / len(test_questions)
wandb.summary["overall_accuracy"] = accuracy
weave.finish()  # ensure all data is flushed

각 질문은 트리거됩니다 get_answer, 이는 Weave가 프롬프트와 결과를 함께 기록합니다.
그다음 우리는 사용합니다 wandb.log 일부 필드를 기록합니다. question, model_answer, expected, correct를 기록하는 점에 주목하세요. 매번 동일한 키를 사용하므로, W&B는 이 기록 항목들로 표를 구성합니다.
전체 정확도를 위한 요약 메트릭도 설정합니다.

기록된 모든 예시를 표로 보여 주며, question, model_answer, expected_answer, correct(True/False)을 확인할 수 있습니다. 또한 우리는 사용했기 때문에 @weave.op, 트레이스 get_answer 역시 함께 기록됩니다(이 간단한 경우에는 함수의 입력과 출력만 보입니다. 하위 단계가 있었다면 그것들도 표시됩니다).
Weave가 자동으로 다음 위치를 강조 표시할 수 있습니다 correct 은 False입니다(부울형 메트릭이기 때문입니다).
이번 실행에 대한 요약 정확도 수치가 있습니다.

3단계: Weave에서 결과 시각화와 해석

전체 정확도가 예를 들어 90%로 나타날 수 있습니다.
테이블을 살펴보며 각 질문, 모델의 답변, 기대되는 정답, 그리고 정답 여부를 확인할 수 있습니다.
예를 들어, 오답으로 표시된 항목을 하나 확인해 봅시다: 질문: “OpenAI의 CEO는 누구인가요?” - 기대 정답: “Sam Altman” - 모델 답변: “2021년 기준 OpenAI의 CEO는 Sam Altman입니다.” 이 답변에는 “Sam Altman”이 포함되어 있으므로, 구현 방식에 따라서는 우리의 간단한 확인 로직이 정답으로 처리할 수도 있습니다. 만약 오답으로 처리됐다면 모델이 잘못된 이름을 제시했을 가능성이 있습니다.
모델이 오답을 냈다면 해당 항목을 클릭해 확인할 수 있습니다. 트레이스에는 함수 호출만 표시될 수도 있습니다. 여기서는 직접 호출이라 내부 정보가 많지 않습니다. 하지만 더 복잡한 파이프라인이라면 어디에서 오류가 발생했는지(예: 잘못된 정보를 검색함)까지 확인할 수 있습니다.
필터를 추가할 수 있습니다: correct == False. 이렇게 하면 모델이 틀린 질문만 표시됩니다. 그러면 어떤 유형의 질문에서 오류가 났는지 빠르게 파악할 수 있습니다. 예를 들어, 모델이 “Google의 CEO는 누구인가요?”라는 질문에 틀린 답을 했다면(가정) 아마도 오래된 이름을 제시했을 수 있습니다. 이는 일부 영역에서 지식이 오래되었음을 시사합니다.
그럼 해당 문제를 해결하도록 모델을 파인튜닝하거나 프롬프트를 조정하는 계획을 세울 수 있습니다.
질문 등으로 정렬하거나 검색할 수도 있습니다. 예를 들어 “France”를 검색하면 프랑스 관련 질문을 찾아 답변을 확인할 수 있습니다.

위 과정을 다시 실행하되, name="model_v2_eval"로 설정해 봅니다.
이제 프로젝트에는 실행이 두 개 있습니다. Weave는 이 둘을 비교할 수 있습니다. 예를 들어, 각 질문별로 model_v1과 model_v2를 비교해 볼 수 있습니다.
model_v2가 이전에 틀렸던 답변을 일부 수정했다면, 이제 해당 항목들은 올바른 것으로 표시됩니다.
model_v2가 새로운 오류를 일으킨 경우에도 해당 항목이 표시됩니다.
model_v2의 전체 정확도가 95%라고 가정해 봅시다. 추가로 맞은 답변들이 강조 표시된 것을 확인함으로써 그 개선을 검증할 수 있습니다.

Weave의 이점 요약

체계적 로깅: 출력이나 지표 기록을 빠뜨리지 않습니다. 모든 것이 로그로 남아 일화에 의존한 평가를 피할 수 있습니다.
재현성: 평가는 언제든지 다시 실행하여 과거 실행 결과와 비교할 수 있습니다. Weave는 기록을 보관합니다.
모델 내부에 대한 통찰: 중간 단계(예: 사고의 연쇄, 검색된 문서 등)를 기록하면 해석 가능성이 높아져, 모델을 단순한 블랙박스로 보지 않고 오류를 이해하는 모범 사례를 따를 수 있습니다.
시각화와 협업:" 플롯과 표가 자동으로 생성되며, 팀원들과 이를 함께 논의해 모델 품질에 대한 합의를 이루는 데 도움을 줍니다.
효율성: 맞춤형 평가 스크립트를 작성하고 리포트를 만드는 데 드는 시간을 줄여 줍니다. 절약된 시간은 평가 범위를 넓히는 데(더 많은 테스트 케이스, 더 많은 지표) 쓰거나, 실제로 발견된 문제를 바로잡는 데 활용할 수 있습니다.

LLM 평가의 모범 사례와 흔한 함정

견고한 LLM 평가를 위한 모범 사례

명확한 평가 목표 정의하기: 먼저 모델에서 무엇을 가장 중요하게 여기는지 정하고, 그에 맞는 지표와 방법을 선택하세요. 사실 정확성이 최우선인가요? 사용자 만족도가 최종 기준인가요? 목표에 따라 평가 설정은 달라져야 합니다. 예를 들어, 진실성이 핵심인 경우(의료 어시스턴트처럼) 사실 정확성 평가를 포함하고 환각을 강하게 감점하는 방식을 고려하세요. 반대로 창의성이 중요한 경우(이야기 생성기처럼) 단일 자동 지표보다 인간의 주관적 평가에 더 의존할 수 있습니다. 목표를 명확히 하면 실제 성공을 반영하지 못하는 “지표 따라가기”를 피할 수 있습니다.
여러 지표를 함께 사용하기(총체적 평가) 단 하나의 지표로는 LLM의 모든 측면을 포착할 수 없습니다. 최선의 방법은 여러 차원에서 평가하는 것입니다.* 예를 들어, 챗봇을 평가할 때는 다음을 측정하세요:
작업 성공 여부: 정답을 제시했는가? (정확도/F1 또는 인간 평가)
유창성: 문장이 잘 형성되었는가? (예: 문법 점수 또는 인간 평가)
도움성: 사용자의 의도를 충실히 반영했는가? (인간 평가)
안전성: 유해 표현을 피했는가? (유해성 분류기 점수)
효율성: 충분히 간결했는가? (길이 또는 사용자 피드백) 이 모든 지표를 한눈에 볼 수 있는 대시보드를 통해 전체적인 상태를 파악할 수 있습니다. 종종 상충관계가 존재합니다(예: 어떤 모델은 더 정확하지만 다른 모델보다 더 장황할 수 있음). 여러 지표를 함께 사용하면 이러한 균형을 맞추거나, 적어도 한 지표를 최적화하느라 다른 지표를 희생하는 일을 피할 수 있습니다. HELM 프레임워크는 투명성을 위해 다중 지표 평가를 특히 권장합니다.
자동 평가와 인간 평가를 결합하기 앞서 논의했듯이, 자동 평가는 규모와 속도 면에서 매우 유용하지만, 많은 측면에서 인간 평가는 여전히 금표준입니다. 모범 사례는 자동화가 신뢰성 있게 측정할 수 있는 속성에 자동 지표를 사용하고(예: 참조와의 유사도에는 BLEU, 유해성 탐지에는 분류기), 주관적이거나 미묘한 측면에는 인간 판단을 사용하는 것입니다. 예를 들어, 자동 지표로 명백히 잘못된 답변을 걸러낸 뒤, 남은 결과를 인간이 품질 관점에서 평가합니다. 또는 LLM 판정을 통해 출력물을 순위화하되, 최종 상위 항목은 인간이 검증합니다. 이러한 하이브리드 접근법은 자동화의 효율성과 인간 통찰의 섬세함을 함께 활용합니다.
공정하고 대표성 있는 테스트 데이터를 확보하기 평가의 품질은 테스트 데이터의 품질에 달려 있습니다. 모델이 접하게 될 입력 범위를 충분히 포괄하는 다양하고 대표성 있는 데이터셋을 사용하세요. 모델이 전 세계적으로 사용될 예정이라면, 다양한 문화권과 언어(다국어 모델인 경우), 사용자 집단에서 나온 질문이나 프롬프트를 포함하세요. 특정 엣지 케이스가 중요하다면(예: 의료 봇을 위한 희귀 질환 관련 질문), 실제 환경에서 드물더라도 평가에 반드시 포함해야 합니다. 범위가 지나치게 좁거나 너무 쉬운 테스트 세트는 주의하세요. 모델의 한계를 점검하기 위해 도전적이고 적대적인 예제를 일부 포함하는 것이 좋습니다. 또한 새로운 실패 양상이 발견될 때마다 테스트 세트를 지속적으로 업데이트하세요(시간에 따른 진전을 측정할 수 있도록 핵심 안정 세트는 유지하되, 새로운 입력 유형을 위한 섹션을 추가).
평가 일관성 유지(필요한 경우) 모델 버전을 비교할 때는 평가 설정을 가능하면 일관되게 유지하세요. 동일한 테스트 질문, 동일한 프롬프트를 사용해 차이가 평가 방식이 아니라 모델 변경에 기인하도록 해야 합니다. 반면, 평가 기법을 개선했다면(더 나은 지표를 도입하거나 테스트 케이스를 추가하는 등) 이후 평가에 적용하고, 필요하면 이전 모델들도 새 방법으로 재평가해 기준점을 마련하세요. 평가 코드와 데이터를 명확히 버전 관리하여, 어떤 기준으로 모델을 평가했는지 추적 가능하게 하세요. 평가지표의 재현성은 신뢰를 위해 중요합니다. 누군가 동일한 모델에 대해 동일한 평가를 다시 실행하면 같은 결과가 나와야 합니다.
평가에서 현실성을 강조하기 가능하다면 평가에 실제 사용자 데이터를 사용하세요(프라이버시를 준수). 예를 들어, 실제 사용자 질의의 일부를 익명화하여 로그로 수집하고 이를 평가 세트로 활용합니다. 이렇게 하면 깔끔하게 선별된 질문만이 아니라 사람들이 실제로 묻는 내용으로 평가할 수 있습니다. 실제 데이터가 부족한 경우(예: 신규 제품)에는 현실적인 시뮬레이션을 만드세요. 예를 들어, 사용자가 가질 법한 대화를 시뮬레이션합니다. 평가가 현실에 가까울수록, 좋은 평가 결과가 실제 사용자 만족으로 이어질 것이라는 확신이 커집니다. 추가로, 베타 테스트나 사용자 연구를 평가의 일부로 고려하세요. 즉, 대상 사용자 소그룹에 모델을 제공하고 정성적 피드백을 받습니다. 이는 “말투가 불편하다”거나 “정답이지만 설명을 이해하지 못했다”처럼 지표만으로는 드러나지 않을 수 있는 문제를 밝혀낼 수 있습니다.
편향과 공정성 평가하기 공정성의 중요성을 고려하여, 편향을 탐지하는 전용 테스트를 포함하세요. 모범 사례로는 대조 프롬프트를 넣는 방법이 있습니다. 예: “의사에 대해 말해줘”와 “여의사에 대해 말해줘”, “남자의사에 대해 말해줘”에 대한 답변을 비교해 정당화되지 않은 차이나 고정관념이 있는지 확인합니다. 또는 유사한 질문에 서로 다른 민족적 배경의 이름을 넣어 모델을 테스트하고, 반응이 달라지는지 살펴보세요. 검증된 벤치마크를 사용하거나 보호 속성(인종, 성별, 종교 등)을 포괄하는 자체 시나리오를 만들어도 좋습니다. 가능하다면 편향을 정량화하세요(예: “정체성 X vs Y를 프롬프트로 제시했을 때 생성물의 유해성 비교”). 평가 프레임워크에 편향 감사를 포함하는 것은 불공정한 동작을 포착하는 데 핵심입니다. 더 나아가 평가 결과 자체의 공정성(예: 인간 평가자의 구성 다양성 확보 등)도 함께 고려해야 합니다.
시간에 따른 진척도 추적하기 모델 버전과 시간에 걸쳐 지표를 지속적으로 추적하세요. 스프레드시트를 유지하거나, 더 나은 방법으로는 Weave/W&B 프로젝트 같은 곳에 각 모델의 평가 결과를 기록해 두세요. 이렇게 하면 특정 지표에서 수익 체감 구간에 들어섰는지, 혹은 최근 변경으로 인해 어디선가 성능 하락이 발생했는지를 파악하는 데 도움이 됩니다. 이해관계자와 소통할 때도 유용합니다. 예: “지난 3개월 동안 사실 오류율을 15%에서 5%로 낮췄습니다”처럼 모델의 개선 흐름을 근거로 보여줄 수 있습니다. 또한 학습된 교훈이 보존되어 같은 실수를 반복하지 않게 해 줍니다. 예를 들어, 특정 모델에 문제가 있었고 이를 수정했다면, 추적을 통해 그 문제가 눈치채지 못한 사이에 다시 나타나지 않도록 방지할 수 있습니다.
임계값과 기대치 설정하기 중요한 지표에 대해서는 목표 임계값을 설정하세요. 예: “이 핵심 Q&A 쌍에서 모델은 최소 90% 이상을 달성해야 한다” 또는 “100개 응답 중 유해 판정은 1개를 넘지 않아야 한다.” 이러한 기준은 가드레일 역할을 합니다. 모델이 이를 충족하지 못하면 배포 후보에서 제외해야 합니다. 반대로 충분히 상회한다면, 다음에는 다른 측면에 집중할 수 있습니다. 이런 표준을 마련해 두면 “성능이 낮지만 멋져 보이는 새 모델”의 유혹에 휘둘리지 않게 되고, 수용 기준을 공식화할 수 있습니다. 물론 임계값은 사용자 필요와 현재 모델 역량에 맞춰 합리적으로 정하세요. 보통은 달성 가능한 수준에서 시작해, 모델이 개선됨에 따라 점진적으로 높여 가는 방식이 좋습니다.
사용자 피드백을 평가에 반영하기 LLM이 실제로 배포되어 있다면, 지속적인 평가의 한 부분으로 사용자 피드백을 적극적으로 활용하세요(명시적 평점뿐 아니라 사용자가 같은 질문을 다시 했는지와 같은 암묵적 신호 포함). 예를 들어, 사용자가 답변을 별점 1–5로 평가할 수 있다면, 평균 별점을 하나의 지표로 사용하되(사용자 평가가 일관되지 않을 수 있으므로 주의) 세션 중 좋은 평가 대비 나쁜 평가의 비율을 살펴보고 이를 추적하세요. 오프라인 평가에서도, 사용자가 “이건 내가 원하던 게 아니에요”라고 말한 대화 기록을 평가 프롬프트로 사용해 새 모델이 이를 어떻게 처리하는지 확인할 수 있습니다. 요컨대, 배포와 평가를 순환시키면 평가가 실제 사용과 지속적으로 맞물려 유의미하게 유지됩니다.
정기적으로 오류 분석 수행하기 각 평가가 끝날 때마다, 실패 사례의 표본을 대상으로 철저한 오류 분석을 수행하세요. 오류를 분류합니다. 사실 관계 오류는 몇 건인지, 질문의 모호성 때문은 몇 건인지, 서식/형식 문제로 인한 것은 몇 건인지 등으로 나눕니다. 이는 개선 방향(어느 영역을 우선 보완할지)을 정하는 데 도움이 될 뿐 아니라, 지표가 실제로 무엇을 말하고 있는지 제대로 이해하도록 해 줍니다. 예를 들어 두 모델이 모두 정확도 90%를 달성했더라도, 나머지 10%의 오류 성격은 크게 다를 수 있습니다. 한 모델은 가끔 심하게 환각을 일으킬 수 있는 반면, 다른 모델은 수학 문제에서 일관되게 실패할 수 있습니다. 오류 분석은 이러한 패턴을 드러내 줍니다. 이러한 발견 사항을 문서화하여, 프로젝트의 평가 지식 베이스에 포함시키세요.
정량 평가와 정성 평가의 균형 잡기 숫자는 필수이지만, 출력물 자체를 읽는 일도 중요합니다. 항상 모델의 출력물을 좋은 사례와 나쁜 사례 모두 포함해 한 묶음씩 꼼꼼히 읽을 시간을 확보하세요. 이러한 정성적 감각은 지표로는 포착되지 않는 문제를 발견하게 해 줍니다. 예를 들어, 답이 기술적으로는 맞지만 불필요하게 장황하거나 공감이 부족한 경우 등이 그렇습니다. 많은 팀이 ‘블라인드 평가’를 수행합니다. 평가자는 두 모델의 출력물을 나란히 읽되 어느 모델의 것인지 모른 채 선호도를 판단합니다. 이는 정성적 방법이지만 정량적 결과(선호 비율)를 제공합니다. 지표로 후보를 좁히되, 최종 판단은 사람의 눈으로 하세요. 특히 사용자에게 배포할 때는 더욱 그렇습니다.
가능하다면 실제 환경에서 테스트하기: 가능하다면 내부 직원이나 소수의 사용자 그룹을 대상으로 제한적 릴리스를 진행하고, 이를 평가의 일부로 간주하세요. 실제 사용자 환경에서는 분포 변화나 의도적인 스트레스 테스트 때문에 모델이 다르게 동작하는 일이 종종 있습니다. 이를 평가 단계에서 일찍 관찰해 두면 큰 시행착오를 줄일 수 있습니다. 이러한 통제된 베타 테스트에서는 대화 기록과 신고된 이슈를 수집해, 다음 번을 위해 모델과 평가 프로세스를 함께 개선하는 데 반영하세요.
비용과 품질의 트레이드오프 고려하기 프로덕션용 평가에서는 품질 지표만 보지 말고 추론 비용과 지연 시간도 함께 고려해야 합니다. 모델이 성능은 조금 더 좋더라도 속도가 두 배로 느리거나 비용이 두 배로 들 수 있습니다(모델 크기 선택이나 앙상블 vs 단일 모델 선택 시 특히 중요). 평가는 이러한 요소를 포함해야 합니다. 예: 응답 시간을 측정하고 “95%의 요청에서 2초 이내에 응답해야 한다”와 같은 요구 조건을 두세요. 비즈니스 요구에 따라 훨씬 저렴하다면 작은 모델도 수용 가능할 때가 있습니다. 따라서 효율성 지표(속도, 메모리, 쿼리당 비용)를 별개가 아니라 평가 기준의 일부로 취급하세요. W&B Weave 같은 도구는 실행마다 이러한 지표를 함께 로깅할 수 있습니다.
평가 자체를 반복적으로 개선하기:" 평가 환경을 살아 있는 프로젝트로 다루세요. 각 라운드가 끝날 때마다 자문해 보세요. 우리의 평가가 중요한 것을 놓치지 않았는가? 새로 추가해야 할 지표나 테스트가 있는가? 평가 방법론을 지속적으로 개선하십시오. 이는 연구 결과가 인간 판단과 더 잘 상관한다고 입증된 새로운 지표를 도입하거나, 무엇을 봐야 하는지 학습해 가며 사람 평가 가이드라인을 확장하는 것을 의미할 수 있습니다. 한 벌의 지표에 안주하지 마세요. 모델이 발전할수록 기준을 높이거나 더 도전적인 테스트를 추가해야 할 수 있습니다. 예: 사실 정확도가 충분히 높아졌다면, 이제는 일관성이나 스타일처럼 더 미묘한 요소에 집중할 때일 수 있습니다.

LLM 평가에서 피해야 할 일반적인 함정

벤치마크에 과적합하기: 특정 벤치마크 점수를 올리는 데만 지나치게 집중하면, 모델의 개선이 실제 일반화가 아니라 테스트 데이터의 특이점을 파고드는 데서 비롯되는 상황이 발생할 수 있습니다. 이는 굿하트의 법칙의 한 사례입니다. “지표가 목표가 되는 순간, 그 지표는 좋은 지표가 아니게 된다.” 예를 들어, 모델이 파인튜닝 과정에서 방대한 트리비아를 암기해 알려진 데이터셋인 TriviaQA에서 매우 높은 성능을 내도록 학습될 수 있지만, 그렇다고 해서 일반적인 오픈 도메인 QA 능력이 향상되었다는 뜻은 아닙니다. 혹은 요약 모델이 ROUGE를 최대화하려고 원문 문장을 통째로 많이 복사해 겹침을 높임으로써 ROUGE는 높게 나오지만, 읽기에는 덜 매끄러운 요약을 내놓을 수도 있습니다. 이를 피하려면, 다양한 평가 세트와 지표를 사용해 전체 능력을 희생하면서 단일 숫자만 최적화하지 않도록 해야 합니다. 또한 주기적으로 모델이 전혀 보지 않은 새로운 데이터로 상식 검증을 수행하세요. 사소한 변경만으로 벤치마크 점수가 수상할 정도로 급등한다면, 새로운 평가 세트로 재검증하십시오. 가능하다면 팀 내부에서도 일부 평가 데이터를 비공개로 유지해, 진정한 일반화 능력을 시험하세요. 
이상치와 실패 모드를 무시하기 함정은 집계 지표만 보고 ‘롱테일’ 문제를 무시하는 것입니다. LLM의 성공률이 98%일 수 있지만, 나머지 2% 실패에 심각한 이슈(유해한 콘텐츠 생성이나 매우 중대한 오류)가 포함될 수 있습니다. 상위 수준의 지표에만 주목하면 이를 놓치기 쉽습니다. 예를 들어, AI 어시스턴트가 일반적인 질문에는 잘 답하지만 특정 트리거 문구 때문에 가끔 매우 불쾌한 농담을 만들어낼 수 있습니다. 평균 성능만 추적하면, 사용자에게 노출될 경우 큰 문제가 될 그 한 번의 나쁜 사례를 포착하지 못합니다. 해결책: 실패 사례를, 비록 소수라 하더라도, 반드시 들여다보십시오. 치명적 실패를 찾아내기 위한 표적 평가(레드팀 운영)를 수행하세요. 즉, 높은 평균 점수에 안심하지 말고, 최악의 경우 행태도 함께 점검해야 합니다. 한 가지 방법은 “N번의 시도에서 치명적 실패 건수” 같은 지표를 추적하고, 평균 정확도에는 드러나지 않더라도 그 값을 0으로 만드는 것을 목표로 삼는 것입니다.
사람 같은 출력을 정답성과 동일시하기 LLM은 매우 유창하고 자신감 있게 들리는 답변을 내지만, 틀릴 수 있습니다. 주의하지 않으면 평가자가 여기에 속을 수 있으며, 다른 LLM 같은 자동 평가자조차도 속을 수 있습니다. 글이 매끄럽고 자세하다고 해서 정답이라고 가정하지 마십시오. 그래서 사실 기반 과제에서는 검증 가능한 정답(ground truth) 참고 자료나 신뢰할 수 있는 점검 방법이 중요합니다. 이에 관련된 함정으로, BLEU 같은 피상적인 지표만 사용하는 경우가 있습니다. 이런 지표는 맞는 단어를 유창하게 쓰기만 해도 점수가 나올 수 있지만, 실제로 질문에 제대로 답하지 못할 수 있습니다. 사실성은 항상 별도로 재검증하십시오. 이는 LLM-as-judge를 사용할 때도 주의해야 할 점입니다. 겉보기에는 좋아 보이지만 내용상 틀린 답변에 심사 모델이 높은 점수를 줄 수 있습니다. 이를 완화하려면 정답성에 초점을 맞춘 명시적 기준을 두고, 수동으로 표본 점검을 병행하십시오.
부실한 휴먼 평가 설계: 주의 깊은 설계 없이 휴먼 평가를 진행하면 오해를 부를 만한 결과가 나올 수 있습니다. 흔한 문제로는 평가자 지침이 불명확함, 평가자 수가 너무 적어 잡음이 큰 점, 목표 사용자군을 대표하지 못하는 평가자 구성, 혹은 엉뚱한 질문을 하는 경우가 있습니다. 예를 들어 “이 답변이 좋은가?”라고만 묻으면 응답이 일관되지 않을 수 있습니다. 대신 “정답인가? [예/아니오], 충분히 자세한가? [1–5]”처럼 항목을 쪼개면 더 실행 가능한 데이터를 얻을 수 있습니다. 또한 각 항목을 여러 사람이 평가하게 해 개인 편향이 평균화되도록 하십시오. 또 다른 함정은 주석자 교육을 하지 않는 것입니다. 기준이 복잡하다면(예: “논리적 일관성”) 일관적인 출력과 비일관적인 출력의 예시를 제공해 무엇을 봐야 하는지 분명히 알려야 합니다. 이를 소홀히 하면 주석자 고유 성향 때문에 모델이 실제보다 좋아 보이거나 나빠 보이는 신뢰할 수 없는 휴먼 평가 결과가 나올 수 있습니다. 항상 주석자 간 합의도를 검토하고, 합의도가 낮다면 휴먼 평가 설계를 재검토해야 합니다.
단발성 평가: 모델을 한 번 평가하고 끝났다고 보는 것은, 특히 동적인 환경에서는 큰 함정입니다. 모델은 파인튜닝이 더 진행되거나, 컨텍스트가 변하는 온라인 환경에서 사용될 때 드리프트가 발생할 수 있습니다. 지속적으로 평가하지 않으면 입력 분포의 변화나 사소한 모델 업데이트로 성능이 저하되어도 눈치채지 못할 수 있습니다. 우리가 앞서 논의했듯이, 모범 사례는 지속적 또는 최소한 빈번한 재평가입니다. 평가는 모델이 한 번 시험을 통과하고 끝나는 최종 관문이 아니라, 계속되는 과정으로 다뤄야 합니다. 실제 배포된 AI에서 발생하는 많은 실패는, 모니터링 없이 과거 성능이 그대로 유지될 것이라고 가정하는 데서 비롯됩니다. 예를 들어, 새로운 속어가 등장하거나 학습 컷오프 날짜 이후의 정보가 중요해지면서 모델의 정확도가 떨어지는 경우가 이에 해당합니다.
필요할 때 도메인 전문가를 참여시키지 않기 전문 분야용 애플리케이션에서는, 전문가의 시각이 필요한데도 비전문가 평가에 의존하는 것이 흔한 함정입니다. 예를 들어, 법률 문서 요약 모델을 크라우드워커로 평가하면 중요한 법적 쟁점이 보존되었는지 판단하기 어려워 문제가 될 수 있습니다. 마찬가지로, 의료 답변의 정답성은 이상적으로 의료 전문가가 평가해야 합니다. 전문가 비용이 높은 것은 이해하지만, 핵심 항목에 대해서는 최소한 표본이라도 전문가가 검토해 품질 기준을 정하는 것이 좋습니다. 예컨대 크라우드워커로 명백한 사례를 1차 거르고, 경계 사례는 전문가가 판단하도록 하는 방식을 쓸 수 있습니다. 모든 반복 주기마다 도메인 전문가 평가가 불가능하다면, 최소한 주요 버전마다 평가는 받아 모델을 검증해야 합니다. 이를 하지 않으면 비전문가가 “그럴듯하다”고 평가해 모델이 괜찮다고 착각할 수 있지만, 전문가라면 미묘하지만 치명적인 오류를 발견할 수 있습니다.
평가에서 사용자 경험을 소홀히 하기 순수한 기술적 평가만으로는 UX 측면을 놓칠 때가 있습니다. 모델이 정답을 내더라도 사용자 친화적이지 않게 응답할 수 있습니다(너무 장황하거나, 지나치게 짧거나, 충분히 공손하지 않은 경우). 최종 사용자가 스타일과 톤을 중시한다면, 평가에서도 이를 반영해야 합니다. 예를 들어 고객 지원 봇을 평가할 때는 공손함/톤 평가 같은 항목을 포함해야 합니다. 정확도만 평가하면, 무례하거나 기계적으로 느껴지는 봇을 배포할 위험이 있습니다. 평가는 항상 최종 사용자 경험과 연결하세요. 응답 시간(사용자는 대기 시간을 싫어합니다), 형식의 정확성(앱이 JSON을 기대한다면, 항상 유효한 JSON인가?), 사용자 참여 지표 등을 고려하십시오. 예를 들어, 모델 A와 B의 정확도가 비슷하지만, 온라인 테스트에서 사용자가 모델 A에 후속 질문을 30% 더 많이 했다면—아마 답변이 덜 명확했기 때문일 수 있습니다—이는 모델 B가 더 완결성 있는 답변을 제공했다는 신호입니다. 이런 신호를 평가에 반영하십시오. 그렇지 않으면 “문서상으로는 더 나은” 모델이 실제 사용자에게는 더 나쁘게 작동하는 함정에 빠질 수 있습니다.
자동화 점수에 과도하게 의존하기 이미 언급했지만 다시 강조합니다. BLEU, ROUGE, 그리고 BERTScore 같은 학습 기반 지표까지 포함해 이런 메트릭들은 불완전합니다. 인간 판단으로 뒷받침되지 않는 작은 점수 차이에만 의존해 결정을 내리면 안 됩니다. 예를 들어, BLEU가 +0.5 오른다고 해서 실제 품질이 의미 있게 향상된 것은 아닐 수 있습니다. 때로는 팀이 메트릭을 올렸다 내렸다 하며 미세 조정을 반복하지만, 실제 출력은 개선되지 않는 “국소 최적화”에 빠지기도 합니다(BERTScore를 높이려고 표현만 바꾸는 식). 자동화 메트릭은 지침일 뿐 교리가 아닙니다. 바람직한 접근은 다음과 같습니다. 메트릭과 휴먼 평가가 일치하면 신뢰할 수 있습니다. 불일치하면 그 이유를 파고드십시오. 메트릭이 중요하지 않은 요소를 과도하게 페널티 주는 것일 수도 있고, 메트릭이 포착하지 못하는 방식으로 모델이 개선되고 있을 수도 있습니다. 이런 경우에는 인간 판단을 더 신뢰하고, 필요하다면 메트릭을 개선하는 것을 고려하세요.
신뢰도/불확실성 무시하기: LLM은 종종 신뢰도(확신도) ���정이 되어 있지 않습니다. 출력의 정답성만 평가하고, 불확실성을 적절히 신호하는지 평가하지 않는 것은 흔한 함정입니다. 어떤 애플리케이션에서는 모델이 확신이 없을 때 그렇게 밝히거나 답변을 유보하는 것이 중요합니다. 답변을 내놓는지만 평가하면, 모델이 추측일 때도 항상 답하도록 압박하게 되어 유창하지만 잘못된 답변이 늘어날 수 있습니다. 따라서 보정(calibration)을 평가하는 것이 좋습니다. 예: 모델이 “잘 모르겠습니다”라고 말할 때, 실제로 틀렸을 질문이었는가? 반대로 확신을 보일 때(에둘러 말하지 않을 때)는 대체로 맞는가? 일부 평가는 이를 정량화합니다(Brier 점수, 혹은 표명한 확신 수준에 조건부한 정답률 확인 등). 이를 명시적으로 평가하지 않으면, 모델이 모든 질문에 시도해 대부분을 맞혀 겉보기에는 좋아 보일 수 있지만, 틀린 답도 높은 확신으로 단정적으로 말하는 문제가 생깁니다. 많은 실제 상황에서 확신에 찬 오답은 겸손한 무응답보다 더 나쁩니다. 그러니 평가에 이 점을 반드시 포함하세요.
강건성 평가를 하지 않기 모델이 깔끔한 입력에서는 잘 작동하지만, 입력이 조금만 노이즈가 있거나 특이하면 실패할 수 있습니다. 대표적인 함정은 오탈자, 다른 표현 방식, 의도적으로 교란된 문장에 대해 모델이 어떻게 동작하는지 테스트하지 않는 것입니다. 예를 들어 모든 테스트 질문이 문법적으로 잘 정제되어 있다면, 질문에 오탈자가 있거나 구어체로 표현되었을 때 모델이 실패한다는 사실을 놓칠 수 있습니다. 강건성을 가늠하기 위해 평가에 일부 교란된 입력을 포함하는 것이 바람직합니다. 마찬가지로 같은 질문의 변형(패러프레이즈)도 테스트하세요. 강건한 모델이라면 특정 한 가지 표현만이 아니라 모든 표현에 올바르게 답해야 합니다. 한 가지 표현만 테스트하면 모델의 일관성을 과대평가할 수 있습니다. 또 다른 측면은 대화에서의 멀티턴 일관성입니다. 단일 턴만 테스트하면, 턴이 바뀌면서 모델이 스스로 모순되거나 정보를 잊는 문제를 발견하지 못할 수 있습니다. 해당되는 경우 이러한 시나리오까지 평가 범위를 확장하세요. 요지는 입력 변형에 대응하는 능력과 출력 안정성을 함께 검증하라는 것입니다. 그렇지 않으면, 런타임에서의 사소한 변화가 평가에서는 보이지 않던 성능 급락으로 이어질 수 있습니다.

실습 튜토리얼: LLM 평가 파이프라인 구현하기

1단계: 환경과 데이터를 설정하기

LLM에 접근하는 방법(예: OpenAI API 또는 Hugging Face를 통한 로컬 모델).
Weave용 wandb 라이브러리.
기타 평가 보조 라이브러리(필요하다면 BLEU 계산을 위한 nltk, BERTScore를 위한 transformers 등).

# Sample evaluation data
evaluation_data = [
    {
        "question": "Who wrote the novel '1984'?",
        "reference_answer": "George Orwell"
    },
    {
        "question": "What is the largest planet in our solar system?",
        "reference_answer": "Jupiter"
    },
    {
        "question": "In what year did the World War II end?",
        "reference_answer": "1945"
    },
    # ... (more items)
]

2단계: 로깅을 위해 W&B Weave 초기화하기

import wandb
import weave

# Initialize a Weave run for this evaluation
wandb.login()  # if not already logged in (requires W&B API key)
weave.init(project="LLM_evaluation_demo", name="model_v1_eval")

3단계: 로깅을 위한 계측을 포함해 LLM 질의 함수 정의하기

import openai
# Set your OpenAI API key if using OpenAI (or set environment variable)
openai.api_key = "YOUR_OPENAI_API_KEY"
@weave.op()
def get_model_answer(question: str) -> str:
    """Query the LLM to get an answer for the question."""
    # Here we use a simple prompt format: just the question.
    # In a more complex scenario, you might add a system prompt for context or instructions.
    prompt = question
    try:
        response = openai.Completion.create(
            engine="text-davinci-003",  # or another model
            prompt=prompt,
            max_tokens=100,
            temperature=0  # deterministic for evaluation
        )
        answer_text = response['choices'][0]['text'].strip()
    except Exception as e:
        answer_text = f"<ERROR: {e}>"
    return answer_text

우리는 …을(를) 보냅니다 question 모델에 대한 프롬프트로서
우리는 설정합니다 temperature=0 결정적 출력을 얻기 위해서입니다. 평가에서는 재현 가능한 결과를 위해 이런 방식을 자주 사용합니다.
우리는 제한합니다 max_tokens 답변이 너무 길어지지 않도록 하기 위해서입니다.
우리는 API 오류를 모두 포착해 자리표시자 답변으로 반환합니다(어떤 질의가 실패했는지 확인할 수 있도록).

4단계: 평가 루프 실행 및 메트릭 로깅

정확 일치 (단순한 문자열 비교 또는 정규식으로) 정답인지 여부를 판단합니다.
BLEU 점수 각 답변마다 계산합니다(단일 정답만 있는 경우 BLEU는 사실상 의미가 없을 수 있지만, 여기서는 데모를 위해 포함합니다).
답변 길이 추가 정보로 참고하시기 바랍니다.

import nltk
from nltk.translate.bleu_score import sentence_bleu  # If using NLTK BLEU, ensure the resources are downloaded
# nltk.download('punkt')  # if needed for tokenization

results = []  # to store results if we want to use them in code later
total_exact_matches = 0
for item in evaluation_data:
    ques = item["question"]
    ref = item["reference_answer"]
    # Get model's answer (this call is logged by Weave)
    model_ans = get_model_answer(ques)
    
    # Compute Exact Match (case-insensitive containment for simplicity)
    is_exact_match = (ref.lower() == model_ans.strip().lower())
    total_exact_matches += int(is_exact_match)
    
    # Compute BLEU (here using a simplistic approach with the reference as single reference list of tokens)
    ref_tokens = [ref.split()]  # list of one reference list
    ans_tokens = model_ans.split()
    bleu = sentence_bleu(ref_tokens, ans_tokens, weights=(1, 0, 0, 0))  # unigram BLEU for simplicity
    
    # Simulate a human rating: let's say 5 if exact match, 3 if answer contains ref as substring, 1 otherwise
    if ref.lower() in model_ans.lower():
        human_score = 5 if is_exact_match else 3
    else:
        human_score = 1
    
    # Log to W&B
    wandb.log({
        "question": ques,
        "reference": ref,
        "model_answer": model_ans,
        "exact_match": is_exact_match,
        "bleu_unigram": bleu,
        "human_score": human_score,
        "answer_length": len(model_ans.split())
    })
    
    # Save result in list too (if we want to print or analyze in Python)
    results.append({
        "question": ques,
        "reference": ref,
        "model_answer": model_ans,
        "exact_match": is_exact_match,
        "bleu": bleu,
        "human_score": human_score
    })
# After loop, log summary metrics
accuracy = total_exact_matches / len(evaluation_data)
wandb.summary["exact_match_accuracy"] = accuracy
wandb.summary["average_bleu"] = sum(r["bleu"] for r in results) / len(results)
wandb.finish()

각 질문마다 우리는 다음과 같은 방식으로 답변을 얻었습니다 get_model_answer그 함수 호출은 Weave에 의해 로깅됩니다.
그다음 여러 필드를 기록했습니다:
질문, 기준 답안, 모델 답안(로그에서 맥락을 파악할 수 있도록).
exact_match 모델의 답변이 기준 답안과 정확히 일치하는지 여부를 불리언(True/False)으로 표시합니다(단순화를 위해 대소문자 구분 없음의 정확 일치). 실제 QA 평가에서는 정확 일치(Exact Match)나 부분 일치를 위한 F1이 흔히 사용됩니다.
bleu_unigram: 기준 답안과 모델 답안이 짧기 때문에, 토큰의 정밀도(내용어 정확도와 유사)를 측정하는 단일그램 BLEU를 사용했습니다.
human_score: 사람 평가를 흉내 내기 위한 임의의 지표입니다. 실제로는 주석자에게서 얻습니다. 이 단순한 예에서는 정답 여부와의 상관관계를 보도록 설정했습니다.
answer_length: 모델 답변의 토큰 수(단순 개수)로, 장황한지 간결한지 확인합니다.
각 예시에 대해 wandb.log()으로 위 항목들을 기록했습니다. 즉, Weave에서는 각 예시가 이러한 열을 가진 행처럼 저장됩니다. 결과적으로 질문(Q), 기준 답안(ref), 모델 답안(answer), 그리고 평가 지표(metrics)로 이루어진 작은 데이터셋을 만든 셈입니다.
마지막에는 집계 요약도 기록했습니다: 전체 정확도와 평균 BLEU.
데이터가 저장되었는지 확인하기 위해 W&B 실행을 종료했습니다.

로그된 예시들이 표로 표시되어 모든 필드를 확인할 수 있습니다. 해당 필드로 정렬하거나 필터링할 수 있습니다. 예를 들어, 필터를 적용해 exact_match == False 모델이 어떤 질문을 틀렸는지 확인하기 위해.
또한 확인할 수 있습니다 get_model_answer 각 호출에 대한 트레이스가 표시됩니다. 특정 예시를 클릭하면 트레이스 입력과 출력(이 경우에는 질문 -> 답변 텍스트만)을 보여줄 수 있습니다.
그 human_score 우리가 기록한 항목은 다음과 비교할 수 있습니다 exact_match 모의 인간 평가자가 정답성과 대부분 일치했는지 확인하기 위해.
집계값 exact_match_accuracy 요약값은 실행 개요 또는 요약 패널에 표시됩니다. 예를 들어 0.66(66%)이라면, 이 작은 평가 세트에서 모델의 정확도입니다.
average_bleu 비슷하게

for res in results:
    print(f"Q: {res['question']}")
    print(f"Model: {res['model_answer']}  | Reference: {res['reference']}")
    print(f"Exact Match: {res['exact_match']}, BLEU: {res['bleu']:.2f}, Human Score: {res['human_score']}")
    print("----")

5단계: 결과 해석하기

Q: Who wrote the novel '1984'?
Model: George Orwell  | Reference: George Orwell
Exact Match: True, BLEU: 1.00, Human Score: 5
----
Q: What is the largest planet in our solar system?
Model: Jupiter is the largest planet in our solar system.  | Reference: Jupiter
Exact Match: False, BLEU: 1.00, Human Score: 3
----
Q: In what year did the World War II end?
Model: World War II ended in 1945.  | Reference: 1945
Exact Match: False, BLEU: 1.00, Human Score: 3
----

모델은 모든 질문에 대해 올바른 정보를 답했습니다(BLEU 1.0으로 모든 핵심 토큰이 포함되었고, 내용상으로도 확인됨).
하지만 둘 중 하나는 정답을 완전한 문장 형태로 표현해서 기준 답안과 정확히 일치하지 않았습니다(우리의 exact_match 엄격한 검사 표시가 False로 설정되었습니다). 그래서 exact_match_accuracy 엄격한 일치 기준으로 보면 33%(3문제 중 1개 정답)처럼 보일 수 있지만, 실제로는 모델이 모두 맞혔고 단지 불필요한 단어가 덧붙었을 뿐입니다.
사람 평가 점수(시뮬레이션 기준)는 완전한 문장으로 답했더라도 올바른 정보를 포함하고 있었기 때문에 부분 점수(5점 중 3점)를 부여했습니다.
이는 중요한 점을 시사합니다. 우리의 정확 일치 기준이 지나치게 엄격했다는 것입니다. 모델의 출력인 “Jupiter is the largest planet in our solar system.”에는 기술적으로 정답인 “Jupiter”가 포함되어 있습니다. 사람 평가자는 이를 정답으로 간주할 것입니다. 따라서 더 느슨한 기준을 사용해야 함을 알 수 있습니다(예: 기준 답안이 모델 답변의 부분 문자열로 포함되어 있으면 정답으로 처리하거나, SQuAD 평가에서 흔히 쓰이는 F1 겹침을 사용). 이는 결과를 본 뒤 평가 방식을 정교화하는 사례입니다.

exact_match_accuracy 은 0.33으로 낮아서 처음에는 성능이 나빠 보일 수 있지만, BLEU 평균은 1.0으로 높았습니다. BLEU가 1.0이라는 것은 정답에 기준 단어들이 모두 포함되었다는 뜻입니다(이번 경우 기준 답안이 한 단어였으므로, BLEU 1.0은 그 단어가 답변에 존재했음을 의미합니다).
exact_match와 BLEU/사람 평가 간의 이 불일치는, 실제로는 모델이 정답이지만 우리의 정확 일치 지표가 그 성능을 과소평가하고 있음을 보여줍니다.
그래서 평가 방식을 조정합니다. 예를 들어 F1 같은 지표를 사용할 수 있는데, 이런 경우에는 순서를 무시하고 단어 겹침만 보면 모든 단어가 일치하므로 F1 값이 1.0이 됩니다.
이것은 여러 지표를 함께 사용하고 출력 결과를 직접 살펴보는 것이 왜 중요한지 보여줍니다. 단일 지표만 보면 오해를 불러일으킬 수 있습니다.

모델이 무언가를 틀렸다면, 로그에서 확인할 수 있을 것입니다 (exact_match 거짓이며 답변에 기준 답안이 포함되어 있지 않은 경우입니다. 우리는 그것이 어떤 유형의 질문이었는지 기록합니다. 예를 들어, 모델이 “George Orwell”을 잘못하여 “Orwell George”라고 답했다고 가정해 봅시다(다소 특이한 예). 이 경우 exact match는 실패합니다. 우리는 이를 지식 결함이 아니라 형식(포맷팅) 문제로 분류합니다.
또 2차 세계대전 종전 연도를 틀리게 답했다면, 그것은 지식 오류입니다.

더 큰 평가 세트나 다른 유형의 질문으로 평가하세요.
적대적인 표현도 시험해 보세요. 예: “소설 ‘1984’를 쓴 사람은 누구인가요?”처럼 물어봐서 모델이 여전히 정답을 내는지 확인합니다. evaluation_data를 보강한 뒤 다시 실행할 수도 있습니다.

6단계: Weave 시각화와 보고서 통합

W&B 앱에서 간단한 대시보드를 만들어 보세요. 하나의 패널에는 전체 정확도(요약 지표로 기록해 두었습니다)를 표시하고, 다른 패널에는 예시 테이블을 나열합니다. Weave가 이 중 일부를 자동으로 제공할 수도 있습니다.
Weave의 필터를 사용해 오답 사례에 집중하세요.
아마도 …을(를) 만들어 보세요 보고서 (이 블로그 게시글을 링크) 요약: “모델 v1은 정답 일치율이 X%였지만, 지표를 정교화한 뒤에는 실질적으로 Y%가 정답으로 평가됩니다. 답변은 대체로 완전한 문장 형태로 제시됩니다. 모든 답변은 사실적으로 올바랐습니다. 다음 단계로, 보다 개방형 질문이나 여러 문장으로 구성된 답변을 테스트하겠습니다.”

7단계: 연속 평가를 위한 예제 코드 통합

모델 식별자나 프롬프트 변형을 입력값으로 받을 수 있도록 합니다.
이 평가를 실행하세요.
Weights & Biases에 결과를 기록하세요.

8단계: 파이프라인 확장

더 많은 메트릭을 추가하세요. 예를 들어 Perspective API 또는 HuggingFace 모델을 사용한 독성 검사(토시시티 체크)를 적용하고, 각 답변에 대해 toxicity_score를 기록하세요.
속도를 평가하세요: 각 get_model_answer 호출에 걸린 시간을 측정해 기록하세요(Weave가 자동으로 수집하거나 수동으로 기록할 수 있습니다).
여러 모델을 평가해야 한다면(예: GPT-3와 GPT-4 비교), 이 파이프라인을 두 번 실행한 뒤 Weave로 비교할 수 있습니다.
대규모 인간 평가를 위해서는 출력 결과를 기록한 뒤, 별도의 프로세스가 인간 라벨링 서비스에 질의하고 그들의 평점을 다시 기록하는 메커니즘을 구축할 수 있습니다(예를 들어 나중에 human_score 필드를 업데이트하거나 인간 피드백으로 새로운 항목을 추가 기록하는 방식).
다음과 통합하세요 지속적 통합이 작업을 매일 밤 자동으로 실행하도록 스크립트로 구성하고, 정확도가 임계값 아래로 떨어지면 자동으로 플래그를 달도록 설정할 수 있습니다.

평가 세트와 메트릭을 정의하세요.
모델을 실행하고 출력을 수집하세요.
결과를 체계적으로 기록하세요(Weave/Weights & Biases 사용).
출력물을 검토하여 메트릭이 실제 품질과 일치하는지 확인하세요.
인사이트를 활용해 모델이나 평가(또는 둘 다)를 조정하세요.
새로운 모델 버전마다 반복 실행하고, 결과를 비교해 진행 상황을 추적하세요.

LLM 평가의 향후 방향

더 세분화되고 동적인 평가:" 단일 점수 같은 거친 지표 대신, 앞으로의 평가는 모델 행동을 더 풍부하게 묘사하는 프로파일을 만들어 낼 수 있습니다. 예를 들어, 모델에 대한 “능력 보고서”를 생성해 여러 차원에서의 강점과 약점을 자동으로 하이라이트하는 방식입니다. Google의 Eval++ 같은 프로젝트는 모델이 모델을 정교한 기준으로 평가하도록 하는 것을 목표로 합니다. 한 가지 아이디어는 모델들이 서로를 위해 테스트 문항을 생성하게 두어 평가 데이터를 자동으로 확장하는 것입니다. LLM이 평가에 더 깊이 관여할수록, 모델에 적응하는 더 동적인 평가가 나타날 것입니다. 예: 어떤 범주에서 모델이 매우 뛰어나다면, 평가 시스템이 그 범주의 난도를 자동으로 높여 질문을 던지고 능력의 경계를 찾아가는 방식입니다.
AI 지원 평가와 해석 가능성: 우리는 이미 LLM을 심판(평가자)으로 사용하기 시작했지만, 앞으로는 더 정렬된 평가자로 발전할 가능성이 큽니다. 예를 들어, LLM에게 단순히 점수를 매기게 하는 것을 넘어, 특정 문제(논리적 오류나 출력 내 편향 등)를 감지하도록 프롬프트하는 연구가 발전하고 있습니다. 대량의 인간 피드백 데이터로 학습해 다양한 특성에 대해 어떤 출력이든 평가할 수 있는 ‘범용 평가자 모델’ 개념도 있습니다. 이런 모델이 성공한다면(또는 그 앙상블이 성공한다면) 평가는 급격히 가속될 수 있습니다. 각 출력에 대해 사실성 등급, 스타일 등급, 편향 플래그 등을 세밀하게 제시하고, 그 결과가 인간 전문가의 판단과 높은 상관을 보이는 AI 평가 패널을 상상해 보세요. 이는 생성된 문장마다 유닛 테스트를 갖추는 것과 유사한 효과를 낼 수 있습니다. 아직 그 수준에 도달하진 못했지만, 이 방향으로의 진전은 계속되고 있습니다.
지속적이고 실시간의 평가: 모델이 자주, 또는 실시간으로(온라인 학습) 업데이트될 수 있기 때문에 평가는 연속적으로 이루어질 수 있습니다. 대규모의 고정된 평가 이벤트 대신, 도구가 출력 스트림을 지속적으로 모니터링하고 지표를 실시간으로 계산하게 됩니다. 예를 들어, 배포된 챗봇은 대화가 진행될 때마다 만족도 점수가 갱신되고, 주제 편향(드리프트)에 따른 성공률이 변하는 등의 실시간 성능 대시보드를 가질 수 있습니다. 이는 “프로덕션 환경의 평가 파이프라인”이라는 개념으로 나아가는 것으로, 모델이 핵심 기준에 대해 지속적으로 평가되고, 이상이 감지되면 경보를 트리거합니다. 이미 많은 기업이 불량 출력의 급증을 모니터링하고 있으며, 앞으로의 시스템은 이를 더 자동화할 가능성이 큽니다(예: 출력 품질 지표에 대한 이상 감지). 이는 MLOps와도 맞물립니다. 가용성이나 지연 시간을 모니터링하듯, 정확성과 안전성도 함께 모니터링하게 될 것입니다.
사용자 중심·맥락 기반 평가: 평가는 더 사용자 중심으로 발전할 가능성이 있습니다. 예를 들어 개인화의 관점에서, 모델의 성능은 사용자 집단이나 선호도에 따라 다르게 평가되어야 할 수 있습니다. 어시스턴트가 특정 사용자에 맞춰 적응한다면, 평가는 개인 수준의 만족도를 반영해야 합니다. 또한 맥락 인식 측면에서, 1K 토큰과 10K 토큰처럼 다른 컨텍스트 길이를 얼마나 잘 처리하는지, 사용자가 톤 선호를 설정했을 때 모델이 톤을 어떻게 조정하는지를 평가할 필요가 있습니다. 현재의 표준 평가로는 이러한 측면을 충분히 다루지 못합니다. 앞으로의 평가 프레임워크는 페르소나 전환, 대화 도중 언어 전환 등 다양한 사용 맥락을 시뮬레이션하여 적응력을 스트레스 테스트하는 방식을 포함할 수 있습니다.
벤치마크의 진화와 메타 평가: 추론 능력(BIG-bench 과제, MATH·GSM8K 같은 수학 벤치마크), 상식(ASDiv 등), 멀티모달 이해(비전+언어 모델의 확산과 함께) 등 다양한 측면을 시험하는 새로운 벤치마크는 계속 등장할 것입니다. 하지만 흥미로운 방향은 메타 평가, 즉 평가 방법 자체를 평가하는 것입니다. 예를 들어, 다양한 지표가 인간 판단과 얼마나 잘 상관하는지를 탐구하는 연구가 진행되고 있습니다. 이러한 연구는 어떤 지표를 신뢰할 수 있는지 판단하는 데 지침을 제공합니다. 결국 폭넓게 검증된 학습 기반 지표를 사용하게 될 수도 있습니다. 또한 페이스북의 Dynabench나 HuggingFace의 Eval Harnesses 같은 커뮤니티 주도 평가 플랫폼은 어려운 새로운 예시로 벤치마크를 지속적으로 갱신할 수 있게 해 줍니다. 이러한 플랫폼은 더욱 성장해 평가를 커뮤니티 주도의 역동적인 프로세스로 만들 가능성이 큽니다.
해석 가능한 평가와 모델 이해 모델의 해석 가능성(내부 구조를 이해하거나 모델이 왜 그런 답에 도달했는지 설명하는 능력)에 대한 요구가 커지고 있습니다. 앞으로는 평가에 해석 가능성 점검이 포함될 수 있습니다. 예를 들어, 내부 활성화값을 분석해 모델의 오류를 얼마나 잘 예측할 수 있는지, 혹은 모델의 추론 경로가 얼마나 일관적인지를 평가하는 방식입니다. TCAV(Testing with Concept Activation Vectors) 같은 기법이나, 특정 입력으로 모델을 프로빙해 지식이 내재되어 있는지를 확인하는 방법이 평가의 일부가 될 수 있습니다. 예를 들어, 단순히 모델에 질문만 하는 대신 임베딩 공간이나 어텐션 패턴을 탐색해, 비록 정답을 정확히 표현하지 못했더라도 모델이 해당 사실을 “알고” 있는지를 평가할 수 있습니다. 이는 다소 연구 지향적이지만, 해석 가능성 도구가 성숙해짐에 따라 안전이 중요한 시스템에서는 이러한 방법이 평가 도구 상자에 포함될 가능성이 큽니다. 이 경우 출력만이 아니라, 모델의 내부 상태에 위험한 개념이 포함되어 있는지까지 함께 평가하고자 할 수 있습니다.
강건성 및 적대적 테스트: 미래의 평가는 강건성에 더욱 큰 비중을 둘 것입니다. 모델은 약점을 찾아내도록 설계된 적응형 적대자, 즉 다른 AI 시스템을 상대로 평가될 수 있습니다. 예를 들어, 적대적 모델이 LLM을 속여 잘못되었거나 유해한 답변을 내놓도록 만드는 입력을 생성하고, 이러한 스트레스 테스트에서의 실패 빈도를 기록하는 방식입니다. 이는 이미 레드팀 행사(예: Anthropic의 적대적 학습 설정)에서 어느 정도 이루어지고 있으며, 앞으로는 정식 벤치마크로 제도화될 가능성이 큽니다. CLOUDS 프레임워크(Checklist for Language Understanding with Dynamic Substitution)나 기타 적대적 방법론이 평가 스위트의 표준으로 자리 잡아, 모델이 평균적으로만 좋은 것이 아니라 최악의 상황에서도 견고함을 보장하도록 할 수 있습니다.
윤리 및 규제 평가: AI가 규제 대상이 되면서, 법이나 정책에 의해 표준화된 평가 기준이 의무화될 가능성이 있습니다. 예를 들어, 데이터 보호 규정은 모델이 학습 데이터에서 개인 정보를 노출하지 않는지를 평가하도록 요구할 수 있습니다(즉, 개인 정보의 암기 여부를 점검하는 평가가 필요할 수 있습니다). 마찬가지로, 특정 응용 분야에서는 편향과 공정성이 법적으로 필수 평가 요소가 될 수 있습니다(예: 채용에 사용되는 모든 AI는 특정 인구집단을 대상으로 공정성 테스트를 거쳐야 함). 헬스케어 분야에서는 AI에 대해 FDA 임상시험에 준하는 절차가 도입되어, 배포 전에 통과해야 하는 평가 프로토콜이 마련될 수도 있습니다. 이는 보다 엄격하고 편향 없는 평가 프로세스의 개발을 촉진하고, 동시에 투명성도 높일 것입니다(예: 평가 보고서 공개, 또는 주요 평가 차원 전반의 결과를 담은 “영양 성분표”와 같은 라벨을 모델과 함께 제공).
사람‑AI 팀 평가: 많은 응용 분야에서 AI는 인간을 완전히 대체하기보다 함께 협력합니다. 따라서 평가는 사람‑AI 팀의 성과까지 고려해야 합니다. 예를 들어, 의료 진단 상황에서 LLM이 의사를 보조할 수 있습니다. 이런 시스템의 평가는 의사의 정확도나 속도를 얼마나 향상시키는지, 그리고 때때로 의사를 오도하지는 않는지를 함께 확인하는 방식이 될 수 있습니다. 즉, 앞으로의 평가는 사용자가 실제로 AI를 활용하는 사용자 연구를 포함하고, 그 결과 차이를 측정하는 형태가 될 가능성이 큽니다. 이는 UX 평가에 가깝지만 매우 중요합니다. 어떤 모델은 단독으로는 아주 높은 정확도를 보이지 않더라도, 사람이 해석할 수 있는 유용한 힌트를 제공하면 팀의 전체 성과가 높아질 수 있습니다. 반대로, 모델이 정확하더라도 표현 방식이 혼란스러우면 사람이 이를 결합하는 과정에서 오류를 유발할 수 있습니다. 따라서 사람‑AI 상호작용의 결과를 평가하는 것은 새로운 개척지이며, 평가 루프에 HCI(휴먼‑컴퓨터 상호작용) 관점이 결합되는 학제적 접근이 필요합니다.
평가(및 학습)를 위한 합성 데이터: LLM을 통한 합성 데이터 생성 특정 도메인에서 테스트 데이터가 부족한 문제를 LLM 자체가 보완하는 데 도움을 줄 수 있습니다. 예를 들어 다음과 같은 과정이 등장할 수 있습니다:
강력한 LLM을 사용해 틈새 주제에 대한 다수의 질의‑응답 쌍을 생성하고, 이를 신중한 검증 절차를 거쳐 다른 모델의 평가 세트로 활용합니다.
또는 앞서 언급한 대로 적대적 테스트 케이스를 생성합니다.
합성 데이터는 빈틈을 메우는 데에도 활용될 수 있습니다. 예를 들어, 정중한 응답과 무례한 응답으로 구성된 데이터셋을 생성해 스타일 전환 능력을 테스트할 수 있습니다.
LLM이 합성 데이터에 미묘한 편향이나 오류를 주입해 평가 결과를 왜곡할 수 있으므로 주의가 필요합니다. 이에 대한 대응으로, 모델에게 다양하고 편향 없는 테스트 케이스를 생성하도록 지시하고, 이후 사람의 검토를 거치거나 다른 모델로 한 번 더 필터링하는 기법 등이 연구되고 있습니다. 요컨대, LLM이 스스로 도전 과제를 만드는 개념(때로는 봇이 봇을 레드팀한다라고도 부름)이 존재하며, 이는 사람이 단독으로 고안할 수 있는 범위를 넘어 평가의 폭을 비약적으로 확장할 수 있습니다.
교차 모달·체화 평가: LLM이 다른 모달리티(이미지, 비디오, 로보틱스)와 결합됨에 따라 평가도 모달리티를 가로질러 이루어집니다. 예를 들어, 이미지를 설명하는 모델을 평가하려면 이미지 캡셔닝 벤치마크와 비주얼 질의응답(Visual Question Answering) 벤치마크가 필요합니다. 또 가상 환경에서 계획 수립에 LLM을 사용하는 AI 에이전트를 평가하려면 해당 환경 내 과제 수행 성공 여부를 측정해야 합니다. 앞으로는 통합형 평가가 보편화될 가능성이 큽니다. 예: “보고 있는 것을 설명하고, 사실에 근거하며 편향 없이 그에 대한 질문에 답하라”와 같은 시나리오로 시각과 대화를 모두 수행할 수 있는 AI 어시스턴트를 평가하는 방식입니다. 이를 위해서는 NLP 지표와 비전 지표를 결합해야 합니다. VQAv2(시각 Q&A용)나 EAI(시뮬레이터 기반 Embodied AI 과제) 같은 새로운 벤치마크가 중요한 역할을 하며, 멀티모달 모델을 위해 LLM 평가 프레임워크도 이러한 벤치마크를 통합하게 될 것입니다. 요컨대, AI 시스템이 점점 더 범용화됨에 따라 평가의 범위도 확장되고 있습니다.
벤치마크 피로와 새로운 패러다임 벤치마크 피로가 존재한다는 인식이 확산되고 있습니다. 많은 NLP 과제에서 모델이 빠르게 최고 성능에 도달해(이미 인간 수준을 넘어선 경우도 많음) 새로운 평가 패러다임이 필요하다는 뜻입니다. 한 가지 아이디어는 상호작용형 평가입니다. 테스트 세트에서 i.i.d.로 뽑은 질문이 아니라, 모델의 이전 답변에 따라 다음 질문이 달라지는 대화나 상호작용 환경에서 모델을 시험하는 방식입니다. 이는 일관성과 이해의 깊이를 더 잘 검증할 수 있습니다. 또 다른 아이디어는 확률적·분포적 평가입니다. 최고 출력만 보지 않고, 모델이 산출할 수 있는 출력의 분포를 측정해 다양성이나 실패 확률을 평가하는 것입니다. 예를 들어, 모델이 심각하게 틀린 답을 낼 확률이 1%라도 존재하는가? 단일 샘플만 보면 이를 놓칠 수 있지만, 여러 샘플을 평가하거나 특정 토큰의 확률 질량을 분석하면 낮은 확률의 나쁜 결과를 포착할 수 있습니다.
커뮤니티·크라우드소싱 평가: Dynabench 같은 프로젝트에서는 사용자가 모델을 곤란하게 만들 문제를 제시하고, 성공적으로 모델을 실패하게 하면 그 예시가 테스트 세트에 추가됩니다. 이러한 인간 주도의 동적 적대적 접근은 앞으로도 계속될 가능성이 큽니다. 향후에는 모델이 실패하는 사례를 찾아내면 보상을 주는 크라우드소싱 평가 대회가 열리고, 그 사례들이 발전하는 벤치마크의 일부가 될 수 있습니다. 이는 평가를 최신 상태로 유지하고, 모델 개발자들이 긴장을 늦추지 않도록 만드는 데 도움이 됩니다.
평가 기준에서의 설명가능성: 모델이 정답을 맞혔는지뿐 아니라, 답이나 추론 과정을 설명할 수 있는지도 중요하다는 관심이 커지고 있습니다. 앞으로의 평가는 설명의 품질에 따라 모델에 점수를 부여할 수 있습니다. 예를 들어, 모델이 “정답은 X입니다. 왜냐하면 …”이라고 할 때, ‘왜냐하면’ 이하의 부분을 정확성과 일관성 측면에서 평가하는 방식입니다. 이는 모델이 단지 맞는 것에 그치지 않고, 검증 가능하게 맞도록(검증 가능한 추론 단계를 제시하도록) 유도합니다. 현재도 일부 평가 과제(예: Chain-of-Thought Prompting 평가)가 비공식적으로 이러한 방식을 취하고 있지만, 설명과 답변 간의 논리적 일관성을 측정하는 지표나, 설명의 유용성에 대한 인간 평가처럼 보다 공식화된 형태로 발전할 수 있습니다.