LLM 평가: 메트릭, 프레임워크, 모범 사례



목차

LLM 평가를 위한 핵심 지표

전통적 통계 지표

퍼플렉서티: 언어 모델의 대표적인 지표로, 모델이 샘플을 얼마나 잘 예측하는지를 측정합니다. 형식적으로는 테스트 데이터의 평균 음의 로그 우도에 지수를 취한 값입니다. 직관적으로는 퍼플렉서티가 낮을수록 모델이 테스트 데이터를 덜 “놀랍다”고 느낀다는 뜻이며(즉, 더 잘 맞는 모델), 예를 들어 어떤 LLM의 퍼플렉서티가 한 말뭉치에서 20이라면 평균적으로 각 단어마다 동등한 확률의 20가지 선택지 중에서 고르는 정도의 불확실성을 가진다는 의미입니다. 값이 낮을수록 좋으며, 모델이 단어를 더 자신 있게 예측할 수 있음을 나타냅니다. 퍼플렉서티는 종종 학습 중이거나 언어 모델끼리 비교할 때 사용되지만, 그 자체로 출력이 유용하거나 정확한지를 알려주지는 않습니다. 다만 일반적인 언어 패턴과 얼마나 잘 맞는지를 보여줄 뿐입니다.
BLEU(이중언어 평가 대리자): 원래 기계 번역을 위해 개발된 정밀도 기반 지표입니다. BLEU는 모델 출력과 하나 이상의 기준(reference) 텍스트 사이에서 n그램(연속된 n개의 단어) 겹침을 확인합니다. BLEU 점수가 높을수록 생성된 텍스트가 기준 텍스트와 더 많은 구문을 공유한다는 뜻이며, 기대되는 출력에 더 가깝다는 것을 시사합니다. 예를 들어 번역 평가에서는 종종 4그램까지의 겹침을 보는 BLEU-4 점수가 보고됩니다. BLEU는 특정 기준 문구와의 비교에는 유용하지만, 기준 표현과 달라도 타당한 바꾸어 말하기나 창의적인 답변에는 불리하게 작용할 수 있습니다. 정답이 하나로 정해져 있지 않은 개방형 생성에는 유용성이 떨어집니다.
ROUGE(요약 평가를 위한 재현율 지향 대리 지표): 주로 요약 작업에서 사용하는 지표들의 모음입니다. ROUGE-N은 BLEU와 유사하지만 재현율에 집중하며, 기준(reference) 텍스트의 n그램이 생성된 출력에 얼마나 포함되어 있는지를 측정합니다. 또한 ROUGE-L은 출력과 기준 간의 최장 공통 부분수열(LCS) 길이를 측정해 문장 수준의 구조적 유사성을 포착합니다. 요약에서는 ROUGE 점수가 높을수록 모델 출력이 사람 작성 요약과 동일한 정보(단어/구문)를 많이 담고 있음을 의미합니다. BLEU와 마찬가지로 ROUGE는 계산이 쉽고 기준 텍스트가 있을 때 유용하지만, 응집성이나 사실 정확성을 반드시 반영하지는 못할 수 있습니다.
METEOR(명시적 순서를 고려한 번역 평가 지표): 번역과 요약을 위한 또 다른 지표로, BLEU의 한계를 보완하는 것을 목표로 합니다. METEOR는 유연한 매칭 전략을 사용하여 생성 텍스트와 기준 텍스트를 정렬할 때 정확히 같은 단어뿐 아니라 어간과 동의어까지도 일치로 인정합니다. 그런 다음 이러한 정렬의 정밀도와 재현율을 바탕으로 점수를 계산하며, 단어 순서 차이 같은 요소에는 패널티를 부여합니다. 언어 생성 작업에서 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의 의미 공간에서의 벡터 유사도에 따라 참조 텍스트의 단어와 정렬합니다. 그다음 토큰 임베딩 수준에서 정밀도, 재현율, 그리고 F1을 계산합니다. 직관적으로, 모델 출력이 참조와 다른 단어를 쓰더라도 같은 의미를 전달한다면, 해당 단어들의 BERT 문맥 임베딩이 가깝게 위치하여 높은 BERTScore가 나옵니다. 이 지표는 단순한 표현 일치가 아니라 의미를 포착하므로, 요약 같은 과제에서 BLEU나 ROUGE보다 사람 평가와의 상관이 더 높은 것으로 알려져 있습니다. 점수는 보통 정밀도/재현율/F1(또는 F1만) 형태로 0부터 1까지의 범위로 보고되며, 높을수록 더 좋습니다.
COMET: 기계 번역을 위해 Unbabel이 개발한 학습형 평가 지표로, 신경망을 직접 학습시켜 MT 출력에 점수를 매기도록 한다는 점에서 한 단계 더 나아간 방식입니다. COMET(Crosslingual Optimized Metric)은 원문, 모델 번역, 참조 번역(혹은 일부 버전에서는 원문과 번역만)을 입력으로 받아 품질 점수를 출력합니다. 사람 평가로 라벨링된 번역 예시로 학습되므로, 인간 평가를 모사하는 점수를 예측하도록 배웁니다. 학습 기반이기 때문에, COMET은 단순 중복 지표가 놓치는 오류(일부 단어가 겹치더라도 오역인 경우 등)를 포착할 수 있습니다. 학계의 MT 평가에서 새로운 표준으로 자리 잡았으며, BLEU보다 사람 판단과의 상관이 더 높게 보고되는 경우가 많습니다. 레퍼런스 없이 평가하는 설정 등 다양한 변형도 존재합니다. COMET은 주로 번역 과제에 쓰이지만, 모델을 학습시켜 텍스트를 평가하는 접근법은 다른 과제에도 확장 가능하며, 요약 등에서 유사한 시도가 이루어지고 있습니다.
BLEURT, PRISM, BARTScore 등: 이들은 유사한 학습형 지표입니다. BLEURT는 합성 데이터와 인간 평가 데이터로 BERT를 미세 조정하여 후보와 참조 간의 점수를 예측합니다. 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을, 다른 하나는 기존 LLM을 사용하도록 하고, 실제 환경에서 어느 버전이 더 높은 사용자 참여도나 만족도 점수를 내는지 확인하는 방식입니다. 이는 대규모 인간 평가의 한 형태로, “사용자를 평가자(judges)로 삼는” 접근입니다. 사용자 클릭이나 과제 성공률처럼 실제 현업의 성공 기준을 측정한다는 점에서 매우 강력합니다. 단점은 배포 이후에만 가능하다는 점으로, 실제 사용자와의 테스트에 충분히 안전하다고 판단되는 모델에만 적용해야 합니다.

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

맞춤형 과제별 지표

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

평가 방법론

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

GLUE와 SuperGLUE:" GLUE(General Language Understanding Evaluation)는 감성 분석, 패러프레이즈 탐지, 질의응답, 텍스트 함의 등 다양한 영어 과제로 구성된 벤치마크 모음입니다. 각 과제에서 모델의 성능은 정확도 또는 F1로 측정되며, 종종 종합 점수도 함께 보고됩니다. SuperGLUE는 더 어려운 과제와 단순한 풀이를 막기 위한 불균형 클래스 분포를 포함한 강화판입니다. 이들 벤치마크는 LLM 이전 시대(예: BERT, RoBERTa, T5)에 널리 사용되었으며, 현재도 LLM이 기본적인 언어 이해를 처리할 수 있는지 확인하는 데 유용합니다. 연구자들은 GLUE/SuperGLUE와 같은 벤치마크를 사용해 서로 다른 LLM이 다양한 언어 과제를 얼마나 잘 처리하는지 비교할 수 있습니다. 최신 LLM(GPT-3+ 등)은 종종 인간 수준에 근접할 정도로 매우 높은 성능을 보이지만, 여전히 기초 역량에 대한 합리성 검증 지표로 의미가 있습니다.
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 성과는 이례적인 도전 과제에서의 발현적 능력 유무를 가늠하게 해줍니다. 이는 블라인드 스폿을 식별하는 데 유용합니다. 예를 들어, 어떤 모델은 표준 벤치마크에서는 좋은 성과를 내지만, 복잡한 계획 수립이나 농담 이해를 요구하는 BIG-bench 과제에서는 실패할 수 있습니다.
언어 모델의 총체적 평가(HELM): 이것은 스탠퍼드가 주도한 비교적 새로운 이니셔티브로, 단순한 데이터셋이 아니라 평가 프레임워크입니다. HELM은 정확도, 강건성, 보정(calibration), 공정성, 편향, 유해성, 효율성 등 범주 전반에 걸친 폭넓은 “시나리오”(과제와 도메인)와 지표를 정의합니다. 목표는 여러 축에서 모델을 동시에 비교할 수 있는 종합적인 리더보드를 제공하는 것입니다. 예를 들어, HELM은 모델이 특정 과제에서 얼마나 잘하는지만이 아니라, 확률 보정 상태가 어떤지, 입력이 노이즈를 포함할 때 성능이 어떤지, 속도는 어떤지, 공격적이거나 불쾌한 출력을 얼마나 자주 생성하는지 등을 함께 보고합니다. 이는 단일 점수를 넘어 다차원 평가의 필요성을 충족합니다. HELM은 고정된 벤치마크라기보다 평가 플랫폼에 가깝고, 새로운 모델과 지표가 도입됨에 따라 지속적으로 업데이트됩니다.
OpenAI Evals / 사용자 지정 벤치마크: 많은 조직이 자사 제품과 관련된 내부 벤치마크를 직접 구축합니다. 예를 들어 OpenAI는 openai-evals 사용자 지정 평가 로직을 지정할 수 있는 프레임워크(예: ChatGPT의 답변에 핵심 정보가 포함되어 있는지 확인하는 Python 스크립트처럼)입니다. 이러한 평가들은 종종 코딩, 수학 서술형 문제 등 특정 사용 사례에 맞게 맞춤화됩니다. 시간이 지나면서 일부는 공개되거나 사실상의 벤치마크가 되기도 합니다. 코딩 분야에서는 주어진 명세에 맞는 올바른 프로그램을 작��하는 HumanEval, MBPP(Massive Multitask Programming Problems) 등이 있으며, 코드 출력의 기능적 정확성을 측정합니다.

인간 평가 기법과 과제

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

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

비용과 확장성: 앞서 언급���듯이, 휴먼 평가(human eval)는 확장성이 좋지 않습니다. 모델을 조금만 수정할 때마다 철저한 휴먼 평가를 수행하는 것은 비현실적입니다. 그래서 팀들은 보통 최종 비교나 정기 점검에만 휴먼 평가를 남겨두고, 그 사이에는 자동화 지표에 의존합니다(곧 하이브리드 접근법도 살펴보겠습니다).
시간: 사람 평가를 수집하는 데는 과제 설정, 실행, 결과 정제까지 며칠에서 몇 주가 걸릴 수 있습니다. 그 사이에 모델이 바뀌었을 수도 있습니다. 즉, 피드백 루프에 지연이 발생합니다.
품질 관리: 크라우드소싱 평가자는 지침을 오해하거나 주의를 기울이지 않을 수 있습니다. 저품질 작업을 걸러내기 위해, 정답이 명확히 알려져 있거나 기대되는 판단이 분명한 테스트 문항을 포함하는 것이 중요합니다. 많은 평가 설정에는 이른바 ‘센티널’ 문항이 들어가며, 작업자가 이를 틀릴 경우 그 사람이 제출한 다른 답변도 제외될 수 있습니다.
주관성: 일부 과제에서는 인간조차 무엇이 최선인지 합의하지 못합니다. 예를 들어, 이야기의 “창의성”을 평가하는 것은 주관적입니다. 이를 다루는 한 가지 방법은 “얼마나 창의적인가?”처럼 모호한 질문 대신 “이야기에 명확한 결말이 있었나요? 예/아니오”처럼 더 객관적인 질문을 선택하는 것입니다. 또 다른 방법은 주관성을 인정하되, 평균적인 경향이 드러날 만큼 충분한 표본을 확보하는 것입니다.
평가자 편향: 앞서 언급했듯이, 사람에게는 편향이 있습니다. 어떤 평가는 더 관대하고, 어떤 평가는 더 엄격할 수 있습니다. 주석자 풀의 다양성이 부족하면 결과가 한쪽으로 치우칠 수 있습니다. 예를 들어, 모든 주석자가 한 나라 출신의 유창한 영어 화자들뿐이라면 “정중함”에 대한 판단이 다른 문화권과 다를 수 있습니다. 정중함이나 전반적 유용성처럼 문화적 맥락이 큰 요소를 평가할 때는, 특히 모델의 사용자 기반이 전 세계적이라고 가정한다면, 다양한 배경을 갖춘 주석자 집합을 구성하는 것이 바람직한 관행입니다.
과제 프레이밍: 과제를 평가자에게 어떻게 제시하느냐에 따라 결과가 달라질 수 있습니다. 예를 들어 “모델 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개의 검증된 질문–답변 쌍으로 테스트하고, 정확 일치 또는 F1(자동화)을 측정합니다.
또한 기준 답변과의 BERTScore 또는 의미적 유사도(자동화)를 측정합니다.
의료 전문가가 답변 50개를 검토해 정확성을 확인합니다(인간 평가).
와 같은 LLM을 사용하세요 GPT-4 해당 답변도 이중 확인하세요(LLM 판정).
의료 전문가의 검토 결과와 GPT-4의 검토를 비교하여 두 평가가 대체로 일치한다면, 더 많은 질문을 선별하는 작업을 GPT-4에 맡길 수 있습니다.
배포 후에는 사용자 피드백을 모니터링하여 낮은 평점을 받은 답변을 수집합니다. 주기적으로 사람이 해당 답변들을 검토해 무엇이 문제였는지 확인합니다(예: 답이 실제로 틀렸는지, 아니면 맞았지만 사용자가 이해하지 못했는지).
그 결과를 모델 개선에 반영하고, 다음 버전을 위한 평가 세트에도 포함해 피드백 루프를 닫습니다.

LLM 모델 평가와 LLM 시스템 평가

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

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

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

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

단독 평가: 어떤 도움 없이 잡학 퀴즈로 모델을 테스트합니다. 매개변수에 일부 사실이 부족해서 정답률이 30%에 그칠 수도 있습니다.
시스템 평가: 모델이 웹 검색(RAG)을 사용할 수 있게 하면, 이제 답을 찾아볼 수 있으므로 정답률이 80%까지 올라갈 수 있습니다. 모델은 동일하지만 도구로 보강되었기 때문에 시스템은 훨씬 더 좋아집니다. 따라서 단독 평가만 보면 실제로 배포된 시스템이 할 수 있는 일을 과소평가하게 됩니다. 반대로, 시스템에 결함이 있다면(예: 검색이 느려 지연이 발생하거나 프롬프트가 때때로 오작동하는 경우), 시스템 평가는 단독 평가로는 놓칠 문제들을 포착합니다.

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

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

기록 데이터나 특별히 준비된 데이터로 수행합니다.
환경이 통제되어 있습니다. 입력은 이미 알고 있으며, 평가 기준은 사전에 정의되어 있습니다.
사용자의 능동적 상호작용은 없으며, 단방향 평가입니다. 우리가 입력을 제공하고, 출력물을 관찰한 뒤, 정답 또는 기대하는 속성에 비추어 측정합니다.

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

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

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

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

코드에 Weave 설정하기: 스크립트나 애플리케이션 시작 시 Weave를 초기화합니다(예: weave.init(project="LLM_eval", run="experiment_42")). LLM을 호출하거나 중요한 단계를 수행하는 함수가 있다면, 해당 함수에 주석(annotate)을 달아 표시합니다(Weave는 이를 위한 @weave.op 데코레이터)를 사용합니다. 그러면 Weave가 해당 함수 호출을 자동으로 기록합니다. 예를 들어, 함수가 있다면 get_answer(prompt): ... 모델을 호출해 답을 반환하는 함수에 데코레이터를 적용하면, 입력(프롬프트)과 출력(답변)이 기록됩니다. 이렇게 최소한의 코드 변경만으로도 많은 로그 정보를 얻을 수 있습니다.
평가 데이터세트를 모델에 실행합니다: 예를 들어 테스트 질문이 100개 있다고 가정해 봅시다. 당신은 당신의 get_answer 각 항목에 대해 해당 함수를 실행합니다(예: 루프에서). 실행되는 동안 Weave는 각 호출을 캡처합니다. 또한 각 답변 이후에 메트릭을 기록할 수도 있습니다(예: wandb.log({"accuracy": correctness}) 평가 점수를 매길 방법이 있다면). 이러한 모든 데이터(프롬프트, 답변, 메트릭)는 W&B 백엔드로 전송됩니다.
Weave UI에서 결과 확인하기: 이제 W&B 대시보드에서 해당 런을 엽니다. 각 호출이 객체로 기록된 인터페이스가 보일 수 있습니다. 특정 입력을 클릭하면 상세 정보를 확인할 수 있습니다. 예를 들어: 프롬프트 = "Who is the CEO of OpenAI?" -> 모델 출력 = "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에서 실패하기 시작했음을 발견할 수 있는데, 이는 특정 지시를 처리하는 방식에서 발생한 회귀(regression) 때문일 수 있습니다. 이러한 통찰을 통해 출시 전에 문제를 수정할 수 있습니다. Weave가 없다면 이런 회귀를 놓쳤을지도 모릅니다.

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

사용 사례: LLMOps를 위한 Weave의 실제 활용

사용 사례 1: 챗봇 품질 모니터링 한 회사가 LLM으로 구동되는 고객 지원 챗봇을 운영하고 있으며, 이를 지속적으로 평가하고 개선하고자 한다. 이들은 스테이징 환경에 Weave를 설정하고 테스트용 대화 기록을 준비한다. 매일 밤 챗봇의 빌드마다 50개의 시뮬레이션 대화 세트를 실행한다(청구 문제, 기술 지원 등 다양한 주제를 포함). Weave는 대화 흐름을 기록한다: 사용자 메시지 -> 봇의 응답(내부 추론이 가능하도록 설계된 프롬프트를 사용하므로, chain-of-thought는 비공개 추론으로 숨김). 다음 날 아침 팀은 Weave 대시보드를 확인한다. 특정 시나리오(비밀��호 재설정)에서 봇의 성능이 하락한 것을 발견한다(혼란스러운 답변을 제공함). 트레이스를 확인한 결과, 지식 베이스 검색이 오래된 문서를 가져왔음을 파악한다. 이를 통해 지식 소스를 업데이트하거나 검색 쿼리를 조정해야 한다는 결론에 도달한다. 같은 대시보드에서, 최근에 적용한 조정 이후 정중함 점수(예: 분류기로 측정)가 전반적으로 소폭 개선된 것도 확인한다. 이들은 이러한 발견을 정리해 제품 담당자와 공유할 Weave 보고서를 작성한다. 이 워크플로는 반복되며, Weave는 문제를 조기에 발견하고 개선을 입증할 수 있는 데이터를 확보하도록 도와준다.
사용 사례 2: Weave를 활용한 프롬프트 엔지니어링 - 한 개발자가 요약 작업을 위한 프롬프트를 최적화하려고 한다. 후보 프롬프트 템플릿이 5개 있다. 소수의 예시에 수동으로 적용해 보는 대신, 100개의 기사 세트에 모든 프롬프트 5개를 실행하고 결과를 Weave에 로깅하는 루프를 만든다(각 프롬프트 변형을 별도 런으로 기록하거나, 하나의 런에 그룹 태그를 붙여 구분). Weave에서 이제 각 기사별 요약을 나란히 비교할 수 있다. 예를 들어, 프롬프트 C는 가장 짧은 요약을 내지만 핵심을 놓치는 경우가 있고, 프롬프트 A는 더 길지만 더 완전한 요약을 낸다. 일부 샘플에는 ROUGE와 인간 선호 점수도 함께 기록했다. Weave는 프롬프트 B의 ROUGE가 가장 높다고 보여주지만, 인간 선호를 확인해 보니(Weave의 UI나 내보낸 테이블을 통해 동료 3명이 빠르게 평가) 가독성 측면에서는 프롬프트 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는 이 기록 항목들로 표를 자동으로 생성합니다.
전체 정확도를 위한 요약 지표도 설정합니다.

질문, model_answer, expected_answer, correct(참/거짓)을 보여주는 모든 기록 예시의 표. 또한 우리가 사용했기 때문에 @weave.op, 의 추적 get_answer 역추적도 기록됩니다(이 간단한 경우에는 함수의 입력과 출력만 표시됩니다. 하위 단계가 있다면 그 단계들도 함께 표시됩니다).
Weave가 자동으로 강조 표시할 수 있는 위치 correct 는 False입니다(부울형 지표이기 때문입니다).
이 실행의 요약 정확도 숫자가 있습니다.

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

전체 정확도가 예를 들어 90% 정도로 나타날 수 있습니다.
표를 살펴보며 각 질문, 모델의 답변, 기대 정답, 그리고 정답 여부를 확인할 수 있습니다.
예를 들어, 오답으로 표시된 항목 하나를 살펴봅니다: 질문: “OpenAI의 CEO는 누구인가요?” - 기대 정답: “Sam Altman” - 모델 답변: “OpenAI의 CEO는 2021년 기준 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는 기록을 보관합니다.
모델 내부에 대한 통찰:" 중간 단계(예: chain-of-thought, 검색된 문서 등)를 로깅하면 해석 가능성이 높아져, 모델을 블랙박스로만 취급하지 않고 오류 원인을 파악하는 모범 사례를 실천할 수 있습니다.
시각화와 협업: 플롯과 표가 자동으로 생성되며, 팀원들과 이를 함께 논의할 수 있어 모델 품질에 대한 합의를 이루는 데 중요합니다.
효율성: 맞춤 평가 스크립트를 작성하고 보고서를 만드는 데 드는 시간을 줄여 줍니다. 아낀 시간은 평가 범위를 넓히는 데(더 많은 테스트 케이스, 더 많은 지표) 쓰거나, 발견된 문제를 실제로 수정하는 데 활용할 수 있습니다.

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

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

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

LLM 평가에서 피해야 할 흔한 함정

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

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

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

LLM에 접근할 수 있는 환경(예: OpenAI API 또는 Hugging Face를 통한 로컬 모델)
Weave용 wandb 라이브러리.
다른 평가 보조 라이브러리(필요하다면 nltk의 BLEU, transformers의 BERTScore 등).

# 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 평가에서는 정확 일치나 부분 일치를 위한 F1이 흔히 사용됩니다.
bleu_unigram참조 답안과 모델 답안이 짧기 때문에, 단일그램 BLEU를 사용했습니다(사실상 토큰의 정밀도를 측정하며, 내용어의 정확도와 유사합니다).
human_score: 인간 평가를 흉내 내기 위한 임의의 지표입니다. 실제로는 주석 작성자에게서 얻습니다. 이번 단순한 시나리오에서는 그것을 정답 여부와 상관시키기로 했습니다.
answer_length: 모델의 답변에 포함된 토큰 수만 집계해, 장황한지 간결한지 확인합니다.
각 예제마다 wandb.log()을 사용해 이 항목들을 기록했습니다. 즉, Weave에서는 각 예제가 이러한 열을 가진 하나의 행처럼 취급됩니다. 결과적으로 질문, 기준 답안, 모델 답안, 그리고 메트릭으로 구성된 미니 데이터셋을 만든 셈입니다.
마지막에는 집계 요약도 일부 기록했습니다: 전체 정확도와 평균 BLEU입니다.
데이터가 저장되도록 W&B 실행을 완료했습니다.

로그된 예시들의 표가 표시되어 모든 필드를 볼 수 있습니다. 해당 필드로 정렬하거나 필터링할 수 있습니다. 예를 들어, 필터링하여 exact_match == False 모델이 어떤 질문을 틀렸는지 확인하기 위해.
또한 확인할 수 있습니다 get_model_answer 각 호출의 트레이스를 확인할 수 있습니다. 특정 예시를 클릭하면 트레이스 입력과 출력이 표시되며, 이 경우에는 질문 → 답변 텍스트만 보여줍니다.
The 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점을 부여했습니다.
이 사실은 중요한 점을 알려 줍니다. 우리의 정확 일치(metric)가 지나치게 엄격했다는 것입니다. 모델의 출력인 “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/인간 평가 사이의 이 불일치는 모델이 실제로는 정답이지만 우리의 정확 일치(metric)가 이를 과소평가하고 있음을 보여 줍니다.
그래서 평가 방식을 조정해야 합니다. 예를 들어 F1 같은 지표를 사용할 수 있는데, 이 경우에는 단어의 순서를 무시하고 모두 겹치므로 F1이 1.0이 됩니다.
이는 여러 지표를 함께 사용하고 출력물을 직접 확인하는 것이 왜 중요한지를 보여 줍니다. 단 하나의 지표만으로는 오해를 불러일으킬 수 있습니다.

모델이 무언가를 잘못했다면, 로그에서 확인할 수 있을 것입니다 (exact_match 거짓이고 정답에 기준어가 포함되지 않은 경우입니다. 우리는 질문의 유형을 기록합니다. 예를 들어 모델이 “George Orwell”을 잘못해서 “Orwell George”라고 말했다고 가정해 봅시다(조금 엉뚱한 예이지만). 이 경우 정확 일치는 실패합니다. 우리는 이를 지식 문제가 아니라 형식 문제로 분류합니다.
또는 제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 필드를 업데이트하거나 인간 피드백으로 새 항목을 기록).
다음과 통합하세요 CI이를 야간에 자동 실행하도록 스크립트화하고, 정확도가 임계값 아래로 떨어지면 자동으로 플래그를 달도록 설정할 수 있습니다.

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

LLM 평가의 향후 방향

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