What is LLM Evaluation?

https://arize.com/llm-evaluation/
LLM 평가란 무엇인가요?

챕터 요약

개요: 서론에서는 LLM 평가에 대한 개요를 제공하며, LLM 애플리케이션이 사용자 기대를 충족하고 안정적으로 동작하는지 확인하기 위해 평가가 중요함을 강조합니다. 기존 소프트웨어 테스트에서 LLM의 비결정적 특성을 고려한 동적이고 상황에 맞는 평가로의 전환을 강조합니다.

LLM 평가를 시작하려면 제품 문서를 참고하여 효과적인 평가 전략을 구현하는 단계별 안내를 따라보세요.

대형 언어 모델(LLM) 평가란 LLM이 구동하는 애플리케이션의 성능을 체계적으로 평가하는 과정입니다. 이를 통해 관련성, 환각률, 지연 시간, 작업 정확도 등 주요 요소를 이해하고 측정할 수 있습니다.

여러분은 지속적으로 반복 작업을 합니다—프롬프트를 수정하거나, 온도 설정을 조정하거나, 검색 전략을 개선합니다. 하지만 평가가 없다면, 변화가 성능을 향상시키는지, 사용 사례를 망가뜨리는지, 아무런 영향이 없는지 알 수 없습니다.

LLM 평가가 왜 중요한가요?

LLM은 개발자가 레이블이 지정된 데이터를 수집하거나 맞춤형 모델을 학습하지 않고도 지능형 시스템을 구축할 수 있게 해주는 강력한 도구입니다. 프롬프트만으로도 콘텐츠를 생성하고, 구조화된 데이터를 추출하며, 문서를 요약하는 등 다양한 작업이 가능합니다.

이러한 개발의 용이성은 양날의 검입니다. LLM은 데모에서는 잘 동작하지만, 실제 운영 환경에서는 훨씬 더 까다롭습니다. 샌드박스에서 잘 동작하던 프롬프트가 실제 복잡성, 다양한 사용자, 엣지 케이스에서는 실패할 수 있습니다.

이때 평가가 필요합니다. 평가는 다음을 가능하게 합니다:

프롬프트, 파라미터, 검색 방식 등을 반복적으로 개선할 때 향상된 점을 추적할 수 있습니다.
회귀(regression)를 감지하여 사용자에게 영향을 주기 전에 문제를 발견할 수 있습니다.
관련성, 환각률, 일관성, 지연 시간 등 다양한 축에서 품질을 정량화할 수 있습니다.
대안(모델, 전략, 도구 등)을 벤치마킹할 수 있습니다.

하지만 모든 평가가 동일하지는 않습니다. 어떤 데이터셋을 평가에 사용하는지가 매우 중요합니다. 좁은 테스트셋은 좋은 지표를 낼 수 있지만, 그 결과가 실제 운영에 일반화되지는 않습니다. 신뢰할 수 있는 평가를 위해서는 데이터셋이 실제 사용 사례와 사용자 행동을 반영해야 합니다.

이 LLM 평가 가이드에는 무엇이 포함되어 있나요?

Definitive Guide to LLM Evaluation(LLM 평가의 결정판 가이드)은 대형 언어 모델(LLM)이 구동하는 애플리케이션을 평가하고 개선하기 위한 구조화된 접근법을 제공합니다. LLM의 활용이 산업 전반으로 확장됨에 따라, 이 가이드는 효과적인 평가와 개선을 위해 필요한 도구, 프레임워크, 모범 사례를 제시합니다.

가이드는 먼저 LLM as a Judge(LLM이 평가자 역할을 하는 방법)를 소개합니다. 이 접근법은 LLM이 자신의 출력이나 다른 모델의 출력을 평가하는 방식으로, 비용이 많이 드는 인간 주석 작업을 줄이고, 확장 가능하며 일관된 평가를 제공합니다. 이후 토큰 분류, 합성 데이터 평가 등 다양한 평가 유형을 다루며, 특정 사용 사례에 맞는 적절한 접근법 선택의 중요성을 강조합니다.

사전 운영 단계에서는 신뢰할 수 있는 평가를 위해 고품질 데이터셋을 만드는 것이 필수적입니다. 가이드에서는 합성 데이터 생성, 인간 주석, LLM 평가 지표 벤치마킹 등 견고한 테스트 데이터셋을 만드는 방법을 자세히 설명합니다. 이러한 데이터셋은 LLM 평가 벤치마크를 설정하는 데 도움이 되며, 평가 과정이 실제 시나리오와 일치하도록 합니다.

팀이 LLM을 운영 워크플로에 통합할 때는 CI/CD 테스트 프레임워크를 통해 지속적인 반복과 업데이트 검증이 가능합니다. 실험과 자동화된 테스트를 파이프라인에 통합함으로써, 팀은 안정성과 성능을 유지하면서 변화하는 요구에 적응할 수 있습니다.

애플리케이션이 운영에 들어가면, LLM 가드레일은 환각, 유해 응답, 보안 취약점 등 위험을 완화하는 데 중요한 역할을 합니다. 이 섹션에서는 입력 및 출력 검증 전략, 동적 가드, few-shot 프롬프트 기법 등 엣지 케이스와 공격에 대응하는 방법을 다룹니다.

마지막으로, RAG 평가 등 실질적인 사용 사례를 소개합니다. RAG 평가는 문서 관련성과 응답 정확성을 평가하여, 모든 구성 요소에서 원활한 성능을 보장합니다. 지표, AI 가드레일, 벤치마크의 통합적 인사이트를 통해, 팀은 애플리케이션의 성능을 총체적으로 평가하고 비즈니스 목표와의 정렬을 확인할 수 있습니다.

이 가이드는 사전 운영 데이터셋 준비부터 운영 환경의 안전장치, 지속적인 개선 전략까지 LLM을 효과적으로 평가하는 데 필요한 모든 내용을 제공합니다. 신뢰할 수 있고, 안전하며, 영향력 있는 LLM 기반 솔루션을 제공하려는 AI 팀에게 필수적인 자료입니다.

LLM 평가: 시작하기

패러다임의 변화: 통합 테스트와 단위 테스트에서 LLM 평가로

전통적인 소프트웨어 테스트 방식(통합 테스트, 단위 테스트)에서 LLM 애플리케이션 평가로의 전환은 극적으로 보일 수 있지만, 두 접근법 모두 시스템이 기대대로 동작하고 일관되고 신뢰할 수 있는 결과를 제공하는지 확인하는 공통된 목표를 가지고 있습니다. 근본적으로 두 테스트 패러다임 모두 애플리케이션의 기능, 신뢰성, 전반적인 성능을 검증하는 데 중점을 둡니다.

전통적 소프트웨어 엔지니어링에서는:

**단위 테스트(Unit Testing)**는 코드의 개별 구성 요소를 분리하여 각 함수가 독립적으로 올바르게 동작하는지 확인합니다.
**통합 테스트(Integration Testing)**는 서로 다른 모듈이나 서비스가 함께 동작하는 방식을 중점적으로 검증합니다.

LLM 애플리케이션에서는 이러한 목표가 유지되지만, LLM의 비결정적 특성으로 인해 동작의 복잡성이 증가합니다.

동적 동작 평가(Dynamic Behavior Evaluation): 코드 구성 요소를 분리해 테스트하는 대신, LLM 평가는 애플리케이션이 다양한 입력에 실시간으로 어떻게 반응하는지, 정확성뿐 아니라 맥락의 적합성, 일관성, 사용자 경험까지 평가합니다.
작업 중심 평가(Task-Oriented Assessments): 사용자의 특정 작업(질의 해결, 일관된 응답 생성, 외부 시스템과의 원활한 상호작용 등)을 애플리케이션이 얼마나 잘 수행하는지에 초점을 맞춥니다.

두 패러다임 모두 예측 가능성과 일관성을 강조하지만, LLM 애플리케이션은 입력에 따라 출력이 달라질 수 있으므로 동적이고 상황에 맞는 평가가 필요합니다. 그러나 근본 원칙은 동일합니다: 시스템(전통적 코드든, LLM 기반 애플리케이션이든)이 설계대로 동작하고, 엣지 케이스를 처리하며, 안정적으로 가치를 제공하는지 확인하는 것입니다.

LLM 평가 유형

이 섹션에서는 LLM 평가 접근법(LLM as a Judge, 코드 기반 평가, 온라인/오프라인 평가 등)을 살펴봅니다.

LLM as a Judge

LLM as a Judge(LLM이 평가자 역할을 하는 방식)는 AI가 AI를 평가하는 것으로, 한 LLM이 다른 LLM의 출력을 평가하고 설명을 제공합니다.

LLM 지원 평가는 사용자 피드백이나 “정답”이 매우 제한적이거나 거의 없는 경우(가능하더라도 인간 라벨링은 비용이 많이 듦)와 LLM 애플리케이션이 복잡해지기 쉬운 상황에서 필요합니다.

다행히도, LLM의 힘을 활용해 평가를 자동화할 수 있습니다. 이 eBook에서는 이를 어떻게 설정하고 신뢰성 있게 만드는지 자세히 다룹니다.

AI가 AI를 평가하는 것이 순환적이라고 느껴질 수 있지만, 우리는 항상 인간 지능이 인간 지능을 평가해왔습니다(예: 면접, 대학 기말고사 등). 이제 AI 시스템도 다른 AI 시스템을 평가할 수 있게 되었습니다.

이 과정에서는 LLM이 합성된 기준 데이터를 생성하여 다른 시스템을 평가하는 데 사용합니다. 그렇다면 왜 인간 피드백을 직접 사용하지 않을까요? 간단히 말해, 충분한 인간 피드백을 얻는 것이 매우 어렵기 때문입니다.

입력/출력 쌍의 1%에 대해서라도 인간 피드백을 얻는 것은 엄청난 일입니다. 대부분의 팀은 그조차도 얻지 못합니다. 이런 경우 LLM 지원 평가는 운영 전 개발 단계에서 벤치마크와 테스트에 도움이 됩니다. 하지만 이 과정이 진정으로 유용하려면, 모든 LLM 하위 호출에 대해 평가가 이루어져야 합니다. 실제로 하위 호출이 매우 많을 수 있습니다.

질문, 답변, 참고 텍스트가 주어집니다. 참고 텍스트를 기반으로 주어진 답변이 질문에 올바르게 답하는지 판단해야 합니다. 데이터는 다음과 같습니다:

    [BEGIN DATA]
    ************
    [Question]: {question}
    ************
    [Reference]: {context}
    ************
    [Answer]: {sampled_answer}
    [END DATA]

응답은 “correct” 또는 “incorrect” 중 하나의 단어만 포함해야 하며, 그 외의 텍스트나 문자는 포함하지 않아야 합니다. “correct”는 질문이 답변에 의해 올바르고 완전히 답변된 경우를 의미합니다. “incorrect”는 질문이 올바르게 또는 부분적으로만 답변된 경우를 의미합니다.

Learn more LLM-as-a-Judge

LLM 평가 기법 비교 차트

여기서는 다양한 LLM 평가 방법론을 검토하여, 각 방법의 역량과 실제 효과를 평가합니다. 이 표는 LLM을 활용한 평가, 자동화된 코드 기반 평가, 온라인/오프라인 평가 전략 등 주요 평가 방법을 비교합니다.

LLM 평가 기법(LLM as a Judge, 코드 기반 평가, 기준 데이터 비교, 인간 주석, 사용자 피드백 등)과 각 방법의 핵심 원리, 방법 범주, 장점, 단점, 일반적 사용 사례 등 주요 특징을 비교한 차트입니다.

코드 기반 LLM 평가

코드 기반 LLM 평가는 프로그래밍 코드를 활용해 대형 언어 모델(LLM)의 성능, 정확성, 동작을 평가하는 방법입니다. 일반적으로 자동화된 스크립트나 CI/CD 테스트 케이스를 만들어 LLM이 특정 작업이나 데이터셋에서 얼마나 잘 동작하는지 측정합니다. 코드 기반 평가는 본질적으로 파이썬이나 JS/TS 단위 테스트와 유사합니다.

코드 기반 평가는 토큰 사용이나 지연 시간이 발생하지 않아 비용을 줄일 수 있는 방법으로 선호되기도 합니다. 코드 생성과 같은 작업을 평가할 때는 하드코딩이 가능하고, 규칙을 따르므로 코드 기반 평가가 선호됩니다. 하지만 환각과 같이 주관적인 평가가 필요한 경우에는 코드 평가자가 신뢰할 수 있는 라벨을 제공할 수 없으므로, LLM as a Judge가 필요합니다.

코드 기반 평가의 일반적 사용 사례:

LLM 애플리케이션 테스트

코드 기반 평가는 다양한 수준에서 LLM의 성능을 테스트할 수 있습니다—출력이 기대하는 형식에 맞는지, 필요한 데이터를 포함하는지, 구조화된 자동화 테스트를 통과하는지 등을 중점적으로 확인합니다.

출력 구조의 올바름 테스트: 많은 애플리케이션에서 LLM의 출력 구조는 내용만큼이나 중요합니다. 예를 들어, JSON과 같은 응답, 특정 템플릿, 구조화된 답변 등은 다른 시스템과의 통합에 필수적입니다.
출력 내 특정 데이터 테스트: LLM 출력이 특정 데이터 포인트를 포함하거나 일치하는지 검증하는 것은 법률, 의료, 금융 등 사실 정확성이 중요한 분야에서 매우 중요합니다.
구조화된 테스트: 자동화된 구조화 테스트를 통해 LLM이 다양한 시나리오에서 기대대로 동작하는지 검증할 수 있습니다. 이는 출력이 예상 응답과 일치하는지, 엣지 케이스를 처리하는지 등을 확인하는 데 사용됩니다.

평가자 평가

평가 전략의 효과를 평가하는 것은 모델의 성능을 정확하게 측정하고, 편향이나 중요한 실패 사례를 놓치지 않도록 하는 데 중요합니다. 평가자에 대한 코드 기반 평가는 메타 평가를 설정하여 평가자의 성능이나 유효성을 평가하는 방식입니다.

평가자를 평가하려면, 팀은 수작업으로 주석을 단 테스트 데이터셋을 만들어야 합니다. 이 데이터셋은 크기가 클 필요는 없으며, 100개 이상의 예시면 충분합니다. Arize Phoenix에서는 각 평가자에 테스트 데이터셋을 포함하여 각 모델 유형에 대한 성능을 검증할 수 있도록 합니다.

이 가이드를 참고하면 평가자를 개선하고 검증하는 방법을 더 자세히 확인할 수 있습니다.

“평가 전략의 효과를 평가하는 것은 모델의 성능을 정확하게 측정하고, 편향이나 중요한 실패 사례를 놓치지 않도록 하는 데 중요합니다.”

평가 결과 유형

상황에 따라 평가 결과는 다양한 형태로 반환될 수 있습니다:

범주형(이진): 평가 결과가 true/false 또는 yes/no와 같은 이진 출력으로, 1/0으로 쉽게 표현할 수 있습니다. 단순하여 의사결정에 용이하지만, 미묘한 판단을 포착하지는 못합니다.
범주형(다중 클래스): 평가 결과가 여러 사전 정의된 범주나 클래스로, 텍스트 라벨이나 서로 다른 숫자로 표현될 수 있습니다.
연속 점수: 평가 결과가 1~10과 같은 범위 내의 숫자 값으로, 척도 측정이 가능합니다. 이 방식은 추천하지 않습니다.
범주형 점수: 1 또는 0의 값. 범주형 점수는 평균을 낼 수 있어 유용하지만, 연속 범위의 단점은 없습니다.

점수 평가도 옵션이지만, 운영 환경에서는 범주형 평가를 권장합니다. LLM은 연속 척도의 미묘한 차이를 잘 처리하지 못해, 프롬프트가 조금만 바뀌거나 모델이 달라져도 결과가 일관되지 않게 변동될 수 있습니다. 반복 테스트 결과, 점수가 크게 흔들리는 경우가 많아, 대규모 평가에는 적합하지 않습니다.

범주형 평가, 특히 다중 클래스는 단순성과 다양한 평가 결과를 전달할 수 있는 균형을 이루어, 정확하고 일관된 의사결정이 중요한 애플리케이션에 더 적합합니다.

class ExampleResult(Evaluator):
    def evaluate(self, input, output, dataset_row, metadata, **kwargs) -> EvaluationResult:  
        print("Evaluator Using All Inputs")
        return(EvaluationResult(score=score, label=label, explanation=explanation)
        
class ExampleScore(Evaluator):
    def evaluate(self, input, output, dataset_row, metadata, **kwargs) -> EvaluationResult:  
        print("Evaluator Using A float")
        return 1.0
      
class ExampleLabel(Evaluator):
    def evaluate(self, input, output, dataset_row, metadata, **kwargs) -> EvaluationResult:  
        print("Evaluator label")
        return "good"

온라인 vs 오프라인 평가

LLM 애플리케이션의 라이프사이클 전반에 걸쳐서는 오프라인과 온라인의 두 가지 평가 접근법이 필요합니다. 오프라인 LLM 평가는 일반적으로 사전 운영 단계에서 이루어지며, 애플리케이션의 성능을 테스트하기 위해 큐레이션된 데이터셋이나 외부 데이터셋을 사용합니다. 온라인 LLM 평가는 앱이 운영에 들어간 후, 운영 데이터로 평가가 이루어집니다. 동일한 평가자를 온라인과 오프라인 평가 모두에 사용할 수 있습니다.

오프라인 LLM 평가

오프라인 LLM 평가는 일반적으로 애플리케이션 개발 및 테스트 단계에서 이루어집니다. 실제 실시간 데이터와 분리된 통제된 환경에서 모델이나 시스템을 평가합니다. 오프라인 평가의 주요 목적은 운영 전 검증(CI/CD)으로, AI 엔지니어가 미리 정의된 입력(골든 데이터셋 등)에 대해 모델을 테스트하고, 성능 일관성에 대한 인사이트를 얻을 수 있도록 합니다. 이 과정은 다음에 중요합니다:

프롬프트 및 출력 검증: 오프라인 테스트를 통해 팀은 프롬프트 엔지니어링 변경이나 모델 버전을 운영에 반영하기 전에 평가할 수 있습니다. AI 엔지니어는 프롬프트를 다양하게 실험하고, 어떤 변형이 다양한 엣지 케이스에서 가장 좋은 결과를 내는지 평가할 수 있습니다.
골든 데이터셋: 고품질 주석 데이터(골든 데이터셋)로 LLM을 평가하면, 애플리케이션이 알려진 시나리오에서 최적의 성능을 내는지 확인할 수 있습니다. 이러한 데이터셋은 통제된 벤치마크 역할을 하며, LLM 애플리케이션이 특정 입력을 어떻게 처리하는지 명확하게 보여주고, 배포 전 디버깅에 도움이 됩니다.
운영 전 체크: 오프라인 평가는 복잡한 사용자 시나리오를 반영한 데이터셋으로 CI/CD 테스트를 실행하는 데 적합합니다. 엔지니어는 오프라인 테스트 결과를 확인하고, 변경 사항을 운영에 반영하기 전에 검증할 수 있습니다.

“오프라인과 온라인 평가 모두에 하나의 통합 시스템을 사용하면, 두 기법에 대해 일관된 평가자를 쉽게 활용할 수 있습니다.”

참고: “오프라인 평가”의 “오프라인”은 평가에 사용되는 데이터가 운영 전 큐레이션/생성된 데이터임을 의미합니다. 오프라인 평가는 운영 데이터가 아닌 사전 운영 데이터로 평가합니다. 이 때문에 동일한 평가자를 오프라인과 온라인 평가 모두에 사용할 수 있습니다. 오프라인과 온라인 평가 모두에 하나의 통합 시스템을 사용하면, 두 기법에 대해 일관된 평가자를 쉽게 활용할 수 있습니다.

온라인 LLM 평가

온라인 LLM 평가는 운영 환경에서 실시간으로 이루어집니다. 애플리케이션이 배포되면, 실시간 데이터와 실제 사용자와 상호작용하게 되며, 성능을 지속적으로 모니터링해야 합니다. 온라인 평가는 동적이고 예측 불가능한 조건에서 애플리케이션이 어떻게 동작하는지 이해하는 데 필수적입니다. 주요 초점은 다음과 같습니다:

지속적 모니터링: 운영 환경에 배포된 애플리케이션은 성능 저하, 지연 시간 증가, 바람직하지 않은 출력(환각, 유해성 등)과 같은 문제를 지속적으로 모니터링해야 합니다. 자동화된 온라인 평가 시스템은 애플리케이션 출력을 실시간으로 추적하여, 특정 임계값이나 지표가 허용 범위를 벗어나면 엔지니어에게 알립니다.
실시간 가드레일: 민감한 환경에 배포된 LLM은 실시간 가드레일이 필요할 수 있습니다. 이는 부적절하거나 환각된, 편향된 콘텐츠 생성을 모니터링하고 완화하는 역할을 합니다. 온라인 평가 시스템은 이러한 가드레일을 통합하여, LLM 애플리케이션이 사후 대응이 아닌 사전 대응으로 보호받을 수 있도록 합니다.

온라인과 오프라인 LLM 평가 선택

온라인 평가를 보편적으로 적용하는 것이 유리해 보일 수 있지만, 운영 환경에서는 추가 비용이 발생합니다. 온라인 평가 사용 여부는 애플리케이션의 특정 요구와 비즈니스의 실시간 요구에 따라 결정해야 합니다. AI 엔지니어는 일반적으로 평가 필요를 오프라인 평가, 가드레일, 온라인 평가의 세 가지 범주로 나눌 수 있습니다.

오프라인 평가: 오프라인 평가는 LLM 애플리케이션 결과를 운영에 반영하기 전에 확인하는 데 사용됩니다. CI/CD 체크에 오프라인 평가를 활용하세요.
예시: 고객 서비스 챗봇에서 프롬프트를 변경해도 이전에 올바르게 동작하던 응답이 깨지지 않는지 확인하고 싶을 때.
- 가드레일: AI 엔지니어는 문제가 발생하면 즉시 파악하고, 출력을 차단하거나 수정하길 원합니다. 이러한 평가는 실시간으로 실행되어, 시스템이 잘못된 방향으로 벗어나면 출력을 차단하거나 플래그를 표시합니다.
  예시: LLM 애플리케이션이 의료 시스템에서 자동 응답을 생성하는 경우, 가드레일이 의료 조언의 치명적 오류를 실시간으로 감지해, 유해하거나 오해의 소지가 있는 출력이 사용자에게 전달되지 않도록 차단합니다.
온라인 평가: AI 엔지니어는 출력을 차단하거나 수정하길 원하지 않지만, 문제가 발생하면 즉시 파악하길 원합니다. 이 방식은 성능을 지속적으로 추적해야 하지만, 실시간으로 모델 출력을 차단할 필요가 없는 경우에 유용합니다.
예시: LLM 애플리케이션이 개인화된 마케팅 이메일을 생성하는 경우, 톤이나 정확성에 약간의 편차가 있어도 메시지 전송을 차단할 필요는 없습니다. 온라인 평가는 문제를 플래그로 표시해 검토할 수 있도록 하며, 이메일 전송을 중단하지는 않습니다.