오프라인 평가와 벤치마킹 완벽 가이드

LLM 모델의 성능을 객관적으로 측정하고 평가하는 방법을 배웁니다. HumanEval 벤치마크부터 Pass@k 메트릭, LLM-as-a-Judge까지 실무에서 바로 활용할 수 있는 평가 시스템 구축 방법을 다룹니다.

1. HumanEval 벤치마크 테스트

어느 날 김개발 씨는 회사에서 새로운 프로젝트를 맡게 되었습니다. "우리가 사용하는 LLM 모델이 정말 코드를 잘 생성하는지 객관적으로 측정해보세요." 팀장님의 요청에 김개발 씨는 막막했습니다.

어떻게 AI 모델의 코딩 능력을 측정할 수 있을까요?

HumanEval 벤치마크는 LLM의 코드 생성 능력을 측정하는 표준화된 테스트입니다. 마치 학생들이 시험을 보는 것처럼, AI 모델에게 164개의 프로그래밍 문제를 제시하고 정답률을 측정합니다.

OpenAI가 개발한 이 벤치마크는 전 세계적으로 가장 널리 사용되는 코딩 능력 평가 도구입니다.

다음 코드를 살펴봅시다.

from human_eval.data import read_problems
from human_eval.evaluation import evaluate_functional_correctness

# HumanEval 문제 데이터셋 로드
problems = read_problems()

# 첫 번째 문제 확인
first_problem = problems["HumanEval/0"]
print(f"문제 설명: {first_problem['prompt']}")
print(f"테스트 케이스: {first_problem['test']}")

# LLM 모델로부터 생성된 답안 파일 평가
# sample.jsonl 파일에 모델의 답안이 저장되어 있어야 함
results = evaluate_functional_correctness(
    sample_file="samples.jsonl",
    k=[1, 10, 100],  # Pass@1, Pass@10, Pass@100 계산
    n_workers=4
)

print(f"Pass@1: {results['pass@1']:.2%}")

김개발 씨는 선배 개발자 박시니어 씨를 찾아갔습니다. "시니어님, LLM 모델의 코딩 능력을 어떻게 측정하면 될까요?" 박시니어 씨는 미소를 지으며 대답했습니다.

"HumanEval이라는 좋은 도구가 있지요." HumanEval 벤치마크란 정확히 무엇일까요? 쉽게 비유하자면, HumanEval은 마치 대학 입시 수능시험과 같습니다.

모든 학생이 같은 문제를 풀고 점수를 받듯이, 모든 LLM 모델이 같은 코딩 문제를 풀고 성능을 평가받습니다. 이를 통해 어떤 모델이 더 우수한지 객관적으로 비교할 수 있습니다.

HumanEval이 등장하기 전에는 어땠을까요? 개발자들은 각자 자신만의 방식으로 AI 모델을 평가했습니다.

어떤 팀은 10개 문제로 테스트하고, 다른 팀은 100개 문제로 테스트했습니다. 문제의 난이도도 제각각이었습니다.

이렇게 되니 "우리 모델이 80점을 받았어요"라고 말해도 다른 회사와 비교할 방법이 없었습니다. 더 큰 문제는 신뢰성이었습니다.

쉬운 문제로만 테스트하면 모델이 실제보다 더 좋아 보였고, 어려운 문제로만 테스트하면 과소평가되었습니다. 업계 전체가 혼란스러웠습니다.

바로 이런 문제를 해결하기 위해 HumanEval 벤치마크가 등장했습니다. 2021년 OpenAI가 공개한 HumanEval은 164개의 엄선된 프로그래밍 문제로 구성되어 있습니다.

각 문제는 함수 시그니처와 설명(docstring)이 주어지고, 모델은 함수 본문을 완성해야 합니다. 그리고 미리 작성된 단위 테스트를 통과해야 정답으로 인정됩니다.

예를 들어 "두 숫자의 최대공약수를 구하는 함수를 작성하시오"라는 문제가 주어지면, 모델은 올바른 알고리즘을 구현해야 합니다. 그리고 gcd(12, 8) == 4, gcd(100, 50) == 50 같은 테스트 케이스들을 모두 통과해야 합니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 read_problems() 함수로 164개의 문제를 불러옵니다.

각 문제는 고유한 ID를 가지고 있습니다. 예를 들어 "HumanEval/0"는 첫 번째 문제를 의미합니다.

각 문제에는 prompt(문제 설명)와 test(테스트 케이스) 정보가 들어 있습니다. 다음으로 evaluate_functional_correctness() 함수가 핵심입니다.

이 함수는 모델이 생성한 코드를 실제로 실행해보고, 테스트를 통과하는지 확인합니다. k=[1, 10, 100] 옵션은 뒤에서 배울 Pass@k 메트릭을 계산하기 위한 설정입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 여러분 회사에서 두 개의 LLM 모델 중 하나를 선택해야 한다고 가정해봅시다.

모델 A는 GPT-4 기반이고, 모델 B는 Claude 기반입니다. 둘 다 "코딩을 잘한다"고 광고하지만 어느 것이 정말 나을까요?

이럴 때 HumanEval 벤치마크로 두 모델을 테스트합니다. 모델 A가 Pass@1에서 67%를 받고, 모델 B가 73%를 받았다면 모델 B가 더 우수하다고 객관적으로 판단할 수 있습니다.

많은 AI 기업들이 신규 모델을 발표할 때 HumanEval 점수를 함께 공개하는 이유입니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 HumanEval 점수만 보고 모델을 선택하는 것입니다. HumanEval은 주로 Python 알고리즘 문제에 초점을 맞추고 있습니다.

만약 여러분이 JavaScript 웹 개발이나 SQL 쿼리 생성에 모델을 사용하려면, HumanEval 점수가 실제 성능을 완벽하게 반영하지 못할 수 있습니다. 또한 HumanEval은 함수 레벨의 코드 생성만 평가합니다.

전체 애플리케이션을 설계하거나, 복잡한 리팩토링을 수행하는 능력은 측정하지 못합니다. 따라서 여러 벤치마크를 함께 사용하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다.

"아, 그래서 모델 발표 자료에서 항상 HumanEval 점수를 강조하는 거였군요!" HumanEval 벤치마크를 이해하면 AI 모델의 성능을 객관적으로 비교하고, 프로젝트에 적합한 모델을 선택할 수 있습니다. 이것이 바로 오프라인 평가의 첫걸음입니다.

실전 팁

💡 - HumanEval은 Python 중심이므로, 다른 언어는 MultiPL-E 벤치마크를 함께 활용하세요

실행 시간이 오래 걸릴 수 있으니 n_workers를 적절히 조정하세요
모델 선택 시 Pass@1뿐만 아니라 Pass@10도 함께 확인하면 더 정확합니다

2. 코드 정확도 측정

김개발 씨는 HumanEval 테스트를 돌려봤습니다. 결과를 보니 모델이 생성한 코드 중 일부는 정답이고, 일부는 오답이었습니다.

"그런데 이 정확도를 어떻게 계산하는 거지?" 단순히 정답 개수를 세면 될까요, 아니면 더 복잡한 방법이 있을까요?

코드 정확도 측정은 생성된 코드가 테스트를 통과하는지 자동으로 검증하는 과정입니다. 마치 자동 채점 시스템처럼, 단위 테스트를 실행하고 성공/실패를 집계합니다.

정확도는 단순히 "전체 중 몇 개를 맞췄는가"를 나타내는 핵심 지표입니다.

다음 코드를 살펴봅시다.

import ast
import subprocess
import tempfile

def execute_code_with_test(generated_code, test_cases):
    """생성된 코드를 실제로 실행하고 테스트를 통과하는지 확인"""
    # 임시 파일에 코드 작성
    with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f:
        f.write(generated_code)
        f.write('\n\n')
        f.write(test_cases)
        temp_file = f.name

    try:
        # 코드 실행 (타임아웃 5초)
        result = subprocess.run(
            ['python', temp_file],
            timeout=5,
            capture_output=True,
            text=True
        )
        # 에러 없이 실행되면 통과
        return result.returncode == 0
    except subprocess.TimeoutExpired:
        return False  # 무한루프 등으로 시간 초과
    except Exception as e:
        return False  # 기타 오류

# 정확도 계산
def calculate_accuracy(results):
    """Pass/Fail 결과 리스트로부터 정확도 계산"""
    passed = sum(1 for r in results if r)
    total = len(results)
    accuracy = (passed / total) * 100
    return accuracy, passed, total

# 예시 사용
test_results = [True, True, False, True, False, True, True, True]
acc, p, t = calculate_accuracy(test_results)
print(f"정확도: {acc:.1f}% ({p}/{t})")

김개발 씨가 테스트 결과를 들여다보고 있을 때, 박시니어 씨가 다가왔습니다. "결과가 어떻게 나왔나요?" 김개발 씨는 화면을 가리키며 물었습니다.

"164개 중 108개가 통과했는데, 이게 좋은 건가요?" 박시니어 씨는 고개를 끄덕였습니다. "그럼 정확도는 약 65.9%네요.

나쁘지 않은 점수입니다." 코드 정확도 측정이란 무엇일까요? 쉽게 비유하자면, 코드 정확도는 마치 시험 점수와 같습니다.

100문제 중 80문제를 맞히면 80점이듯이, 164개 문제 중 108개를 맞히면 65.9%의 정확도를 얻습니다. 하지만 일반 시험과 다른 점이 있습니다.

선생님이 일일이 채점하는 것이 아니라, 자동화된 테스트 시스템이 채점한다는 것입니다. 과거에는 어떻게 코드를 평가했을까요?

초창기 AI 모델 평가에서는 사람이 직접 코드를 읽고 판단했습니다. "이 코드는 논리적으로 맞는 것 같아", "저 코드는 버그가 있을 것 같아" 하는 식이었습니다.

문제는 사람마다 판단 기준이 다르다는 점이었습니다. 같은 코드를 보고 누군가는 정답이라 하고, 누군가는 오답이라고 했습니다.

더 심각한 문제는 확장성이었습니다. 코드 1000개를 사람이 일일이 검토하려면 며칠이 걸렸습니다.

모델을 개선할 때마다 재평가해야 하는데, 이렇게 느린 속도로는 불가능했습니다. 바로 이런 문제를 해결하기 위해 자동화된 정확도 측정이 등장했습니다.

핵심 아이디어는 간단합니다. 생성된 코드를 실제로 실행해보고, 미리 작성된 테스트 케이스를 통과하는지 확인하는 것입니다.

테스트를 통과하면 정답(True), 실패하면 오답(False)으로 처리합니다. 이렇게 하면 사람의 주관이 개입하지 않고, 몇 초 만에 수천 개의 코드를 평가할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. execute_code_with_test() 함수가 핵심입니다.

이 함수는 생성된 코드와 테스트 케이스를 임시 파일에 저장하고, Python 인터프리터로 실행합니다. subprocess.run()을 사용하여 별도 프로세스에서 실행하는 이유는 안전성 때문입니다.

만약 생성된 코드에 무한루프가 있거나 시스템을 망가뜨리는 명령이 있어도, 메인 프로그램은 영향을 받지 않습니다. timeout=5 옵션도 중요합니다.

어떤 코드는 잘못 작성되어 무한루프에 빠질 수 있습니다. 5초 안에 실행이 끝나지 않으면 자동으로 실패 처리합니다.

returncode == 0은 코드가 에러 없이 성공적으로 실행되었다는 의미입니다. calculate_accuracy() 함수는 단순하지만 강력합니다.

True/False 리스트를 받아서 True의 개수를 세고, 전체 개수로 나눕니다. 이것이 바로 정확도(Accuracy) 입니다.

결과를 퍼센트로 표시하여 직관적으로 이해할 수 있게 합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 여러분 회사에서 LLM 기반 코드 자동완성 서비스를 개발한다고 가정해봅시다. 모델을 업데이트할 때마다 성능이 개선되었는지 확인해야 합니다.

이전 버전은 정확도 60%였는데, 새 버전은 65%가 나왔다면 명확히 개선되었다고 말할 수 있습니다. 또한 정확도 측정을 통해 병목 지점을 찾을 수 있습니다.

"어떤 유형의 문제에서 모델이 자주 틀리는가?"를 분석하면, 훈련 데이터를 보강하거나 프롬프트를 개선할 수 있습니다. 예를 들어 재귀 함수 문제에서 정확도가 30%밖에 안 나온다면, 재귀 관련 예제를 더 학습시켜야 한다는 신호입니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 정확도만 보고 모델의 품질을 판단하는 것입니다.

코드가 테스트를 통과했다고 해서 항상 좋은 코드는 아닙니다. 비효율적인 알고리즘을 사용했거나, 가독성이 떨어질 수 있습니다.

따라서 정확도는 필요조건이지 충분조건이 아닙니다. 또한 테스트 케이스가 완벽하지 않을 수 있습니다.

엣지 케이스를 놓친 테스트라면, 실제로는 버그가 있는 코드도 통과할 수 있습니다. 반대로 테스트가 너무 엄격하면 올바른 코드도 실패할 수 있습니다.

테스트의 품질도 함께 관리해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨는 계속 설명했습니다. "65.9%라는 숫자는 GPT-3.5 초기 버전과 비슷한 수준입니다.

GPT-4는 보통 85% 이상 나오니까, 아직 개선할 여지가 많네요." 코드 정확도를 제대로 측정하면 모델의 현재 수준을 객관적으로 파악하고, 개선 방향을 명확히 설정할 수 있습니다. 이것이 바로 데이터 기반 의사결정의 시작입니다.

실전 팁

💡 - 타임아웃을 너무 짧게 설정하면 정상적인 코드도 실패할 수 있으니 적절한 값(5-10초)을 사용하세요

보안을 위해 샌드박스 환경에서 코드를 실행하는 것이 좋습니다(Docker, 가상머신 등)
단순 정확도 외에도 실행 시간, 메모리 사용량 등을 함께 측정하면 더 풍부한 평가가 가능합니다

3. Pass@k 메트릭 계산

김개발 씨는 보고서를 작성하다가 이상한 용어를 발견했습니다. "Pass@1은 65%인데, Pass@10은 85%라고요?

같은 모델인데 왜 점수가 다르죠?" 박시니어 씨는 웃으며 말했습니다. "그건 여러 번 시도했을 때의 성공률이에요."

Pass@k 메트릭은 모델이 k번 시도했을 때 최소 한 번 정답을 맞힐 확률을 의미합니다. 마치 주사위를 여러 번 던져서 6이 한 번이라도 나올 확률처럼, 모델에게 여러 번 기회를 줬을 때의 성공률을 측정합니다.

이는 모델의 잠재력을 더 정확하게 평가하는 방법입니다.

다음 코드를 살펴봅시다.

import numpy as np
from collections import defaultdict

def estimate_pass_at_k(num_samples, num_correct, k):
    """
    Pass@k를 계산하는 공식
    n: 전체 샘플 개수
    c: 정답 개수
    k: 시도 횟수
    """
    if num_samples - num_correct < k:
        return 1.0

    # Pass@k = 1 - C(n-c, k) / C(n, k)
    # 조합론을 사용한 정확한 계산
    numerator = 1.0
    denominator = 1.0

    for i in range(k):
        numerator *= (num_samples - num_correct - i)
        denominator *= (num_samples - i)

    pass_at_k = 1.0 - (numerator / denominator)
    return pass_at_k

# 실제 사용 예시
# 한 문제에 대해 100번 생성하고, 그 중 67번 성공한 경우
n_samples = 100
n_correct = 67

# Pass@1, Pass@10, Pass@100 계산
for k in [1, 10, 100]:
    score = estimate_pass_at_k(n_samples, n_correct, k)
    print(f"Pass@{k}: {score:.2%}")

# 전체 문제에 대한 평균 계산
def calculate_average_pass_at_k(results_per_problem, k):
    """여러 문제에 대한 평균 Pass@k 계산"""
    pass_at_k_scores = []

    for n_samples, n_correct in results_per_problem:
        score = estimate_pass_at_k(n_samples, n_correct, k)
        pass_at_k_scores.append(score)

    return np.mean(pass_at_k_scores)

김개발 씨는 고개를 갸웃했습니다. "여러 번 시도한다는 게 무슨 말이에요?

같은 문제를 여러 번 풀게 하나요?" 박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. Pass@k 메트릭이란 정확히 무엇일까요?

쉽게 비유하자면, Pass@k는 마치 농구 자유투와 같습니다. 한 번 던져서 성공하는 확률(Pass@1)과 열 번 던져서 한 번이라도 성공하는 확률(Pass@10)은 다릅니다.

당연히 시도 횟수가 많을수록 성공 확률은 높아집니다. LLM도 마찬가지입니다.

같은 문제를 여러 번 풀게 하면, 그 중 적어도 하나는 정답일 가능성이 높아집니다. 왜 이런 메트릭이 필요할까요?

초기 LLM 평가에서는 Pass@1만 사용했습니다. 한 번 시도해서 맞으면 정답, 틀리면 오답.

간단명료했습니다. 하지만 문제가 있었습니다.

LLM은 본질적으로 확률적입니다. 같은 입력을 줘도 매번 다른 출력을 생성할 수 있습니다.

예를 들어 어떤 문제를 10번 풀게 했을 때, 6번은 정답이고 4번은 오답이라고 가정해봅시다. Pass@1만 보면 60%입니다.

하지만 실제 사용 환경에서는 사용자가 마음에 드는 답을 선택할 수 있습니다. GitHub Copilot처럼 여러 제안을 보여주고 개발자가 선택하는 방식입니다.

이럴 때는 10번 중 한 번이라도 좋은 답이 나오면 되므로, 실제 유용성은 60%보다 훨씬 높습니다. 바로 이런 현실을 반영하기 위해 Pass@k 메트릭이 등장했습니다.

Pass@k는 "k번 생성했을 때, 그 중 적어도 하나가 정답일 확률"을 의미합니다. Pass@1은 전통적인 정확도와 같고, Pass@10은 10번 중 한 번이라도 맞힐 확률입니다.

일반적으로 k가 클수록 점수가 높아집니다. 위의 코드를 한 줄씩 살펴보겠습니다.

estimate_pass_at_k() 함수의 핵심은 조합론 공식입니다. 전체 n개 샘플 중 c개가 정답일 때, k개를 뽑아서 모두 오답일 확률을 계산합니다.

그리고 1에서 빼면 "적어도 하나는 정답일 확률"이 됩니다. 수식으로는 Pass@k = 1 - C(n-c, k) / C(n, k) 입니다.

코드에서는 조합 계산을 직접 구현하지 않고, 반복문으로 분자와 분모를 계산합니다. 이렇게 하면 큰 수의 오버플로우를 방지할 수 있습니다.

if num_samples - num_correct < k 조건은 특수한 경우를 처리합니다. 오답보다 k가 크면 무조건 정답이 포함되므로 1.0을 반환합니다.

실제 사용 예시를 보면, n=100, c=67일 때 Pass@1은 67%, Pass@10은 약 99%, Pass@100은 100%입니다. 10번만 시도해도 거의 확실하게 정답을 얻을 수 있다는 뜻입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 여러분이 AI 코딩 어시스턴트를 개발한다고 가정해봅시다.

사용자에게 제안을 몇 개 보여줄지 결정해야 합니다. Pass@1이 60%인 모델이라면, 1개만 보여주면 사용자 만족도가 낮을 수 있습니다.

하지만 Pass@3이 85%라면, 3개 제안을 보여주면 대부분의 경우 만족스러운 답을 찾을 수 있습니다. 또한 모델 비교에도 유용합니다.

모델 A는 Pass@1이 70%이고 Pass@10이 90%입니다. 모델 B는 Pass@1이 65%이지만 Pass@10이 95%입니다.

어느 모델이 더 나을까요? Pass@1만 보면 A가 낫지만, 여러 제안을 보여주는 환경이라면 B가 더 나을 수 있습니다.

이처럼 사용 시나리오에 따라 적절한 메트릭을 선택해야 합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 Pass@k를 잘못 계산하는 것입니다. 예를 들어 10번 생성해서 6번 성공했다고 Pass@10 = 60%라고 계산하면 안 됩니다.

올바른 Pass@10은 "10번 중 적어도 한 번 성공할 확률"이므로 훨씬 높습니다. 반드시 위의 공식을 사용해야 합니다.

또한 k를 너무 크게 설정하면 의미가 없습니다. Pass@1000 같은 값은 현실적으로 사용자에게 1000개 제안을 보여줄 수 없으므로 실용성이 떨어집니다.

보통 Pass@1, Pass@10, Pass@100 정도를 사용합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 이해했다는 표정을 지었습니다. "아, 그래서 GitHub Copilot이 여러 개 제안을 보여주는 거였군요.

확률을 높이기 위해서!" Pass@k 메트릭을 이해하면 모델의 실제 유용성을 더 정확하게 평가할 수 있습니다. 그리고 제품을 설계할 때 몇 개의 제안을 보여줄지도 데이터 기반으로 결정할 수 있습니다.

실전 팁

💡 - Pass@1과 Pass@10을 함께 보면 모델의 일관성을 파악할 수 있습니다(차이가 크면 불안정)

비용과 성능의 트레이드오프를 고려하세요(k가 클수록 API 비용 증가)
HumanEval 논문에서 제안한 공식을 그대로 사용하는 것이 표준입니다

4. LLM-as-a-Judge로 품질 평가

김개발 씨는 또 다른 문제를 발견했습니다. 테스트를 통과한 코드들을 보니, 어떤 것은 깔끔하고 읽기 쉬운데, 어떤 것은 복잡하고 비효율적이었습니다.

"둘 다 정답인데, 품질은 다른데 이걸 어떻게 평가하죠?" 박시니어 씨는 미소를 지었습니다. "그럴 때는 AI가 AI를 평가하게 하면 됩니다."

LLM-as-a-Judge는 또 다른 LLM 모델을 사용하여 생성된 코드의 품질을 평가하는 방법입니다. 마치 숙련된 개발자가 코드 리뷰를 하듯이, GPT-4 같은 강력한 모델이 코드의 가독성, 효율성, 베스트 프랙티스 준수 여부를 평가합니다.

테스트 통과 여부로는 측정할 수 없는 정성적 품질을 정량화합니다.

다음 코드를 살펴봅시다.

from openai import OpenAI

client = OpenAI()

def llm_judge_code_quality(generated_code, problem_description):
    """LLM을 사용하여 코드 품질을 0-10점으로 평가"""

    prompt = f"""
다음 프로그래밍 문제에 대한 솔루션 코드를 평가해주세요.

문제:
{problem_description}

생성된 코드:
{generated_code}

다음 기준으로 평가하고 0-10점의 점수를 매겨주세요:

4. 베스트 프랙티스: 언어의 관례를 따르는가? (2점)

김개발 씨는 의아한 표정을 지었습니다. "AI가 AI를 평가한다고요?

그게 신뢰할 만한가요?" 박시니어 씨는 자신의 노트북을 열었습니다. "실제로 많은 기업들이 사용하는 방법입니다.

함께 볼까요?" LLM-as-a-Judge란 무엇일까요? 쉽게 비유하자면, LLM-as-a-Judge는 마치 올림픽의 심판과 같습니다.

피겨 스케이팅에서 선수의 연기를 여러 심판이 평가하듯이, 강력한 LLM(예: GPT-4, Claude Opus)이 다른 모델이 생성한 코드를 평가합니다. 단순히 정답/오답만 판단하는 것이 아니라, 얼마나 우아하고 효율적인지도 평가합니다.

전통적인 자동 평가의 한계는 무엇이었을까요? 앞서 배운 HumanEval 같은 방법은 테스트 통과 여부만 확인합니다.

하지만 같은 정답이라도 품질 차이는 엄청날 수 있습니다. 예를 들어 피보나치 수를 계산하는 두 가지 방법이 있습니다.

하나는 재귀로 구현해서 O(2^n) 시간이 걸리고, 다른 하나는 동적 프로그래밍으로 O(n)에 해결합니다. 둘 다 정답이지만, 후자가 훨씬 우수합니다.

또한 변수 이름, 주석, 코드 구조 같은 요소는 테스트로 검증할 수 없습니다. x1, temp, data 같은 이름보다 user_count, sorted_items, api_response 같은 이름이 낫지만, 이런 차이를 자동 테스트로는 포착할 수 없었습니다.

바로 이런 문제를 해결하기 위해 LLM-as-a-Judge가 등장했습니다. 핵심 아이디어는 간단합니다.

GPT-4나 Claude처럼 뛰어난 언어 이해 능력을 가진 모델에게 "이 코드를 평가해줘"라고 요청하는 것입니다. 이 모델들은 수많은 코드를 학습했기 때문에, 좋은 코드와 나쁜 코드를 구분할 수 있습니다.

마치 경험 많은 시니어 개발자가 코드 리뷰를 하는 것처럼 말이죠. 위의 코드를 한 줄씩 살펴보겠습니다.

llm_judge_code_quality() 함수의 핵심은 구조화된 프롬프트입니다. 단순히 "이 코드 좋아요?"라고 묻는 것이 아니라, 명확한 평가 기준을 제시합니다.

정확성 3점, 효율성 3점, 가독성 2점, 베스트 프랙티스 2점으로 세분화하여 총 10점 만점으로 평가합니다. temperature=0.3으로 설정한 이유는 일관성 때문입니다.

같은 코드를 여러 번 평가했을 때, 매번 점수가 크게 달라지면 안 됩니다. 낮은 temperature는 모델이 더 결정론적으로 동작하게 만들어, 평가의 신뢰성을 높입니다.

응답 형식을 엄격하게 지정한 것도 중요합니다. "점수: [0-10]" 형식을 강제하면, 나중에 점수를 추출하기 쉽습니다.

자유 형식으로 답변하게 하면 파싱이 어려워집니다. 예시 코드에서 재귀로 구현한 피보나치 함수는 정확성은 만점이지만, 효율성에서 감점을 받을 것입니다.

Judge 모델은 이렇게 평가할 수 있습니다. "정확성: 3/3 (올바르게 동작함), 효율성: 1/3 (지수 시간 복잡도로 비효율적), 가독성: 2/2 (간결하고 이해하기 쉬움), 베스트 프랙티스: 2/2 (Python 관례를 따름).

총 8/10점." 실제 현업에서는 어떻게 활용할까요? 예를 들어 여러분이 AI 코딩 튜터 서비스를 개발한다고 가정해봅시다.

학생이 제출한 코드가 정답이지만 비효율적이라면, LLM-as-a-Judge로 평가하여 피드백을 제공할 수 있습니다. "당신의 코드는 정답이지만, 시간 복잡도가 O(n^2)입니다.

O(n log n) 알고리즘을 사용해보세요." 또한 여러 모델을 비교할 때도 유용합니다. 모델 A와 모델 B가 모두 Pass@1 70%를 달성했다면, 정확도만으로는 구분할 수 없습니다.

하지만 LLM-as-a-Judge로 코드 품질을 평가하면, 모델 A의 평균 품질 점수가 7.2이고 모델 B가 8.5라면 B가 더 우수하다고 판단할 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 Judge 모델을 맹신하는 것입니다. LLM도 실수할 수 있습니다.

특히 복잡한 알고리즘이나 도메인 특화 코드는 잘못 평가할 수 있습니다. 따라서 중요한 평가에서는 사람의 검토를 함께 사용해야 합니다.

또한 비용 문제도 있습니다. GPT-4 같은 강력한 모델을 Judge로 사용하면 API 비용이 상당합니다.

수천 개의 코드를 평가하면 비용이 급증합니다. 따라서 샘플링 방식(전체의 10%만 평가)이나, 저렴한 모델(GPT-3.5)을 먼저 사용하고 경계 사례만 GPT-4로 재평가하는 전략이 필요합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨가 실제로 코드를 실행해 보였습니다.

재귀 피보나치 코드는 7/10점, 동적 프로그래밍 버전은 10/10점을 받았습니다. 김개발 씨는 감탄했습니다.

"정말 사람처럼 평가하네요!" LLM-as-a-Judge를 활용하면 단순한 정확도를 넘어서 코드의 전반적인 품질을 자동으로 평가할 수 있습니다. 이는 모델 개선의 새로운 방향을 제시합니다.

실전 팁

💡 - 평가 일관성을 높이려면 temperature를 0~0.3으로 낮게 설정하세요

여러 Judge 모델을 사용하여 평가를 교차 검증하면 신뢰성이 높아집니다
평가 기준을 명확하게 정의하고 프롬프트에 포함시키는 것이 핵심입니다

5. 실습: 자동 평가 시스템 구축

김개발 씨는 지금까지 배운 내용을 정리하며 생각했습니다. "HumanEval, Pass@k, LLM-as-a-Judge...

이걸 다 수동으로 실행하려면 너무 복잡한데?" 박시니어 씨가 옆에서 말했습니다. "그래서 자동화된 평가 시스템을 만드는 거죠.

한 번 만들어놓으면 계속 재사용할 수 있어요."

자동 평가 시스템은 모델 평가의 모든 단계를 자동으로 수행하는 파이프라인입니다. 마치 CI/CD 시스템이 코드를 자동으로 테스트하고 배포하듯이, 평가 시스템은 모델 출력을 자동으로 수집하고, 실행하고, 채점하고, 리포트를 생성합니다.

한 번 구축하면 모델 개선 작업의 효율성이 비약적으로 향상됩니다.

다음 코드를 살펴봅시다.

import json
from typing import List, Dict
from dataclasses import dataclass
import time

@dataclass
class EvaluationResult:
    """평가 결과를 담는 데이터 클래스"""
    problem_id: str
    passed: bool
    execution_time: float
    quality_score: float = 0.0
    error_message: str = ""

class AutoEvaluationSystem:
    """자동 평가 시스템의 핵심 클래스"""

    def __init__(self, model_name: str):
        self.model_name = model_name
        self.results: List[EvaluationResult] = []

    def generate_solutions(self, problems: List[Dict]) -> List[str]:
        """LLM으로 문제의 솔루션 생성"""
        solutions = []
        for problem in problems:
            # 여기서는 실제 LLM API 호출 대신 예시
            # 실제로는 OpenAI API, Anthropic API 등을 호출
            solution = self._call_llm(problem['prompt'])
            solutions.append(solution)
        return solutions

    def run_tests(self, solutions: List[str], test_cases: List[str]) -> List[bool]:
        """생성된 솔루션에 대해 테스트 실행"""
        results = []
        for solution, test in zip(solutions, test_cases):
            start_time = time.time()
            passed = execute_code_with_test(solution, test)
            exec_time = time.time() - start_time
            results.append((passed, exec_time))
        return results

    def evaluate_quality(self, solutions: List[str], problems: List[Dict]) -> List[float]:
        """LLM-as-a-Judge로 품질 평가"""
        quality_scores = []
        for solution, problem in zip(solutions, problems):
            score = llm_judge_code_quality(solution, problem['description'])
            quality_scores.append(score['score'])
        return quality_scores

    def run_full_evaluation(self, benchmark_data: Dict) -> Dict:
        """전체 평가 파이프라인 실행"""
        print(f"[{self.model_name}] 평가 시작...")

        problems = benchmark_data['problems']

        # 1단계: 솔루션 생성
        print("1/3: 솔루션 생성 중...")
        solutions = self.generate_solutions(problems)

        # 2단계: 정확성 테스트
        print("2/3: 정확성 테스트 중...")
        test_results = self.run_tests(solutions, benchmark_data['tests'])

        # 3단계: 품질 평가
        print("3/3: 품질 평가 중...")
        quality_scores = self.evaluate_quality(solutions, problems)

        # 결과 집계
        accuracy = sum(r[0] for r in test_results) / len(test_results)
        avg_quality = sum(quality_scores) / len(quality_scores)

        report = {
            'model': self.model_name,
            'accuracy': accuracy,
            'average_quality': avg_quality,
            'total_problems': len(problems),
            'passed': sum(r[0] for r in test_results),
            'timestamp': time.strftime('%Y-%m-%d %H:%M:%S')
        }

        # 결과 저장
        self._save_report(report)

        return report

    def _call_llm(self, prompt: str) -> str:
        """LLM API 호출 (실제 구현 필요)"""
        # 실제로는 OpenAI, Anthropic 등의 API 호출
        pass

    def _save_report(self, report: Dict):
        """평가 결과를 JSON 파일로 저장"""
        filename = f"evaluation_{self.model_name}_{int(time.time())}.json"
        with open(filename, 'w') as f:
            json.dump(report, f, indent=2, ensure_ascii=False)
        print(f"결과 저장: {filename}")

# 사용 예시
benchmark = {
    'problems': [{'id': 'P1', 'prompt': '...', 'description': '...'}],
    'tests': ['test code 1', 'test code 2']
}

evaluator = AutoEvaluationSystem(model_name="GPT-4")
report = evaluator.run_full_evaluation(benchmark)
print(f"정확도: {report['accuracy']:.2%}")
print(f"평균 품질: {report['average_quality']:.1f}/10")

김개발 씨는 노트북을 펼쳤습니다. "자동화 시스템을 만들려면 어디서부터 시작해야 할까요?" 박시니어 씨는 화이트보드에 플로우차트를 그리기 시작했습니다.

자동 평가 시스템이란 무엇일까요? 쉽게 비유하자면, 자동 평가 시스템은 마치 자동차 공장의 조립 라인과 같습니다.

원자재(문제)가 들어가면, 여러 공정(생성, 테스트, 평가)을 거쳐 최종 제품(평가 리포트)이 나옵니다. 사람이 일일이 개입하지 않아도 전체 프로세스가 자동으로 흘러갑니다.

왜 자동화가 필요할까요? 초기에는 모델 평가를 수동으로 했습니다.

개발자가 직접 문제를 복사하고, LLM에 입력하고, 결과를 받아서, 테스트를 돌리고, 점수를 엑셀에 기록했습니다. 문제가 10개면 괜찮습니다.

하지만 HumanEval처럼 164개 문제라면? 하루 종일 걸립니다.

더 심각한 문제는 재현성입니다. 다음 주에 모델을 개선하고 다시 평가하려면, 똑같은 작업을 반복해야 합니다.

실수할 가능성도 높습니다. "어?

이번엔 다른 프롬프트를 사용한 것 같은데?" 하는 식으로 일관성이 깨집니다. 바로 이런 문제를 해결하기 위해 자동 평가 시스템을 구축합니다.

한 번만 제대로 만들어두면, 버튼 하나로 전체 평가를 실행할 수 있습니다. 매번 동일한 방식으로 평가되므로 결과를 신뢰할 수 있습니다.

모델을 개선할 때마다 빠르게 성능을 확인할 수 있어, 실험 속도가 10배 이상 빨라집니다. 위의 코드를 한 줄씩 살펴보겠습니다.

AutoEvaluationSystem 클래스가 전체 시스템의 핵심입니다. 이 클래스는 평가의 모든 단계를 관리합니다.

__init__에서 모델 이름을 받아 어떤 모델을 평가하는지 명확히 합니다. 여러 모델을 비교할 때 유용합니다.

generate_solutions() 메서드는 첫 번째 단계입니다. 문제 리스트를 받아서 LLM에게 솔루션을 생성하도록 요청합니다.

실제 구현에서는 _call_llm() 메서드에서 OpenAI API나 Anthropic API를 호출합니다. 배치 처리를 사용하면 비용과 시간을 절약할 수 있습니다.

run_tests() 메서드는 두 번째 단계입니다. 앞서 배운 execute_code_with_test() 함수를 사용하여 각 솔루션을 실행하고 테스트합니다.

실행 시간도 측정하여 나중에 성능 분석에 활용할 수 있습니다. evaluate_quality() 메서드는 세 번째 단계입니다.

LLM-as-a-Judge를 사용하여 각 솔루션의 품질을 평가합니다. 이 단계는 비용이 많이 들 수 있으므로, 옵션으로 제공하거나 샘플링을 적용할 수 있습니다.

run_full_evaluation() 메서드가 가장 중요합니다. 이 메서드는 전체 파이프라인을 순차적으로 실행합니다.

각 단계마다 진행 상황을 출력하여 사용자가 현재 어디까지 진행되었는지 알 수 있게 합니다. 최종적으로 결과를 집계하고 JSON 파일로 저장합니다.

_save_report() 메서드는 결과를 파일로 저장합니다. 타임스탬프를 포함한 파일명을 사용하여 여러 실험의 결과를 보관할 수 있습니다.

나중에 이 데이터를 분석하거나 시각화할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 여러분이 LLM 기반 스타트업을 운영한다고 가정해봅시다. 매주 모델을 개선하고 있고, 성능이 좋아지는지 확인해야 합니다.

자동 평가 시스템이 있으면 매주 금요일마다 자동으로 평가를 실행하고, 결과를 팀 전체에 공유할 수 있습니다. 또한 A/B 테스트에도 활용할 수 있습니다.

새로운 프롬프트 전략을 시도할 때, 기존 버전과 신규 버전을 모두 자동 평가하여 어느 것이 나은지 데이터로 확인합니다. "느낌적으로 좋아진 것 같아"가 아니라 "정확도가 3% 향상되었습니다"라고 말할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 복잡한 시스템을 처음부터 만들려는 것입니다.

처음에는 간단하게 시작하세요. 정확도 측정만 자동화하고, 품질 평가는 나중에 추가해도 됩니다.

점진적으로 기능을 추가하는 것이 실패 확률을 줄입니다. 또한 에러 핸들링이 중요합니다.

LLM API가 실패하거나, 생성된 코드에 구문 오류가 있거나, 네트워크가 끊길 수 있습니다. 이런 상황에서도 시스템이 멈추지 않고, 에러를 기록하고 계속 진행하도록 설계해야 합니다.

try-except 블록과 로깅을 적극 활용하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨가 실제로 시스템을 실행해 보였습니다. 몇 분 후 JSON 파일이 생성되었고, 깔끔한 리포트가 나왔습니다.

김개발 씨는 감탄했습니다. "이제 매일 평가할 수 있겠네요!" 자동 평가 시스템을 구축하면 모델 개발의 속도와 신뢰성이 크게 향상됩니다.

이것이 바로 MLOps의 핵심 원칙입니다.

실전 팁

💡 - 처음에는 작은 데이터셋으로 테스트하고, 점진적으로 확장하세요

로깅을 충실히 하면 나중에 디버깅이 쉬워집니다
결과를 Git에 커밋하여 버전 관리하면 실험 추적이 가능합니다

6. 실습: 성능 대시보드 만들기

김개발 씨는 여러 번 평가를 실행하고 나서 새로운 문제를 발견했습니다. JSON 파일이 20개가 넘어가니 어느 실험이 가장 좋았는지 한눈에 파악하기 어려웠습니다.

"결과를 시각화할 수 있으면 좋을 텐데..." 박시니어 씨가 옆에서 말했습니다. "대시보드를 만들어봅시다."

성능 대시보드는 평가 결과를 시각적으로 표현하는 웹 인터페이스입니다. 마치 주식 차트처럼, 모델 성능의 변화 추이, 여러 모델 간의 비교, 문제 유형별 정확도를 그래프로 보여줍니다.

데이터를 한눈에 이해할 수 있어 의사결정이 빨라지고, 팀원들과 결과를 공유하기도 쉬워집니다.

다음 코드를 살펴봅시다.

import streamlit as st
import pandas as pd
import plotly.express as px
import plotly.graph_objects as go
from pathlib import Path
import json

def load_evaluation_results(results_dir='./evaluations'):
    """평가 결과 JSON 파일들을 로드"""
    results = []

    for json_file in Path(results_dir).glob('evaluation_*.json'):
        with open(json_file, 'r') as f:
            data = json.load(f)
            results.append(data)

    return pd.DataFrame(results)

def create_accuracy_trend_chart(df):
    """정확도 추이 차트 생성"""
    fig = px.line(
        df,
        x='timestamp',
        y='accuracy',
        color='model',
        title='모델별 정확도 변화 추이',
        labels={'accuracy': '정확도 (%)', 'timestamp': '시간'}
    )
    fig.update_yaxis(range=[0, 1])
    return fig

def create_model_comparison_chart(df):
    """모델 간 비교 차트"""
    latest_results = df.sort_values('timestamp').groupby('model').last()

    fig = go.Figure(data=[
        go.Bar(
            name='정확도',
            x=latest_results.index,
            y=latest_results['accuracy'] * 100,
            yaxis='y',
            offsetgroup=1
        ),
        go.Bar(
            name='품질 점수',
            x=latest_results.index,
            y=latest_results['average_quality'] * 10,
            yaxis='y2',
            offsetgroup=2
        )
    ])

    fig.update_layout(
        title='모델별 성능 비교 (최신 결과)',
        yaxis=dict(title='정확도 (%)'),
        yaxis2=dict(title='품질 점수 (x10)', overlaying='y', side='right'),
        barmode='group'
    )

    return fig

# Streamlit 대시보드
st.set_page_config(page_title='LLM 평가 대시보드', layout='wide')

st.title('🤖 LLM 코드 생성 평가 대시보드')

# 데이터 로드
df = load_evaluation_results()

if df.empty:
    st.warning('평가 결과가 없습니다. 먼저 평가를 실행하세요.')
else:
    # 전체 통계
    col1, col2, col3 = st.columns(3)

    with col1:
        st.metric(
            '총 평가 횟수',
            len(df),
            delta=None
        )

    with col2:
        latest_accuracy = df.sort_values('timestamp').iloc[-1]['accuracy']
        st.metric(
            '최신 정확도',
            f"{latest_accuracy:.1%}",
            delta=f"{(latest_accuracy - df['accuracy'].mean()):.1%}"
        )

    with col3:
        avg_quality = df['average_quality'].mean()
        st.metric(
            '평균 품질 점수',
            f"{avg_quality:.1f}/10"
        )

    # 차트
    st.subheader('📈 정확도 추이')
    st.plotly_chart(create_accuracy_trend_chart(df), use_container_width=True)

    st.subheader('📊 모델 비교')
    st.plotly_chart(create_model_comparison_chart(df), use_container_width=True)

    # 상세 데이터 테이블
    st.subheader('📋 상세 결과')
    st.dataframe(
        df[['model', 'accuracy', 'average_quality', 'passed', 'total_problems', 'timestamp']]
        .sort_values('timestamp', ascending=False),
        use_container_width=True
    )

김개발 씨는 화면 가득 펼쳐진 JSON 파일들을 보며 한숨을 쉬었습니다. "이걸 어떻게 정리하지?" 박시니어 씨가 노트북을 가져와 몇 줄의 코드를 실행했습니다.

순식간에 아름다운 차트가 나타났습니다. 성능 대시보드란 무엇일까요?

쉽게 비유하자면, 성능 대시보드는 마치 자동차의 계기판과 같습니다. 속도계, 연료 게이지, RPM 등을 한눈에 볼 수 있듯이, 대시보드는 모델의 정확도, 품질 점수, 변화 추이를 한 화면에 보여줍니다.

숫자 나열보다 훨씬 직관적으로 이해할 수 있습니다. 데이터 시각화가 왜 중요할까요?

초기에는 평가 결과를 텍스트나 엑셀로 관리했습니다. "GPT-3.5: 0.652, GPT-4: 0.847" 같은 숫자 나열이었습니다.

몇 개는 괜찮지만, 10개 모델을 5번씩 평가하면 50개의 숫자를 봐야 합니다. 어느 모델이 개선되고 있는지, 어느 시점에 성능이 급상승했는지 파악하기 어려웠습니다.

더 큰 문제는 커뮤니케이션입니다. CEO나 PM에게 결과를 보고할 때, 엑셀 파일을 보내면 이해하기 어렵습니다.

"이 숫자가 뭐죠?" "높은 게 좋은 건가요?" 같은 질문을 받습니다. 비기술직 팀원들과 협업하기 어려웠습니다.

바로 이런 문제를 해결하기 위해 성능 대시보드를 만듭니다. 핵심 아이디어는 간단합니다.

데이터를 그림으로 바꾸는 것입니다. 추이는 선 그래프로, 비교는 막대 그래프로, 분포는 히스토그램으로 표현합니다.

사람의 뇌는 시각 정보를 텍스트보다 6만 배 빠르게 처리한다는 연구 결과도 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

load_evaluation_results() 함수는 저장된 JSON 파일들을 모두 읽어 pandas DataFrame으로 변환합니다. DataFrame은 데이터 분석과 시각화의 표준 도구입니다.

Path().glob() 패턴을 사용하여 특정 이름 형식의 파일만 필터링합니다. create_accuracy_trend_chart() 함수는 시간에 따른 변화를 보여줍니다.

Plotly Express의 px.line()을 사용하여 인터랙티브한 선 그래프를 생성합니다. color='model' 옵션으로 모델별로 다른 색상을 사용하여 구분합니다.

이렇게 하면 여러 모델의 개선 추이를 동시에 비교할 수 있습니다. create_model_comparison_chart() 함수는 최신 성능 비교를 보여줍니다.

groupby('model').last()를 사용하여 각 모델의 가장 최근 결과만 추출합니다. 듀얼 축(dual y-axis)을 사용하여 정확도와 품질 점수를 함께 표시합니다.

이렇게 하면 두 지표를 한 번에 비교할 수 있습니다. Streamlit 부분이 대시보드의 핵심입니다.

st.columns(3)으로 화면을 3등분하여 주요 메트릭을 카드 형태로 표시합니다. st.metric()은 숫자와 변화량(delta)을 함께 보여줘서 한눈에 개선 여부를 파악할 수 있습니다.

녹색 화살표는 증가, 빨간색 화살표는 감소를 의미합니다. st.plotly_chart()는 Plotly 차트를 Streamlit 앱에 삽입합니다.

use_container_width=True 옵션으로 화면 너비에 맞게 자동으로 조정됩니다. 사용자는 차트를 확대/축소하거나, 특정 모델을 클릭하여 숨기는 등 인터랙티브하게 탐색할 수 있습니다.

마지막 st.dataframe()은 원본 데이터를 테이블로 표시합니다. 차트로 전체적인 추이를 파악한 후, 정확한 숫자가 필요할 때 참조할 수 있습니다.

sort_values('timestamp', ascending=False)로 최신 결과가 위에 오도록 정렬합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 여러분이 AI 연구팀의 리더라고 가정해봅시다. 매주 월요일 아침 팀 미팅에서 지난주 실험 결과를 공유해야 합니다.

대시보드 URL을 공유하면, 모든 팀원이 동일한 화면을 보며 논의할 수 있습니다. "저번 주 수요일에 급상승했는데, 그때 뭘 바꿨죠?"라는 질문에 즉시 답할 수 있습니다.

또한 경영진 보고에도 유용합니다. CEO가 "우리 모델이 경쟁사보다 나은가요?"라고 물으면, 경쟁사 모델의 공개 벤치마크 결과를 대시보드에 추가하여 비교할 수 있습니다.

그래프 하나로 우위를 명확히 보여줄 수 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 차트를 한 화면에 넣는 것입니다. 정보 과부하가 발생하면 오히려 이해가 어려워집니다.

핵심 지표 3-5개만 메인 대시보드에 배치하고, 나머지는 탭이나 별도 페이지로 분리하세요. 또한 차트 유형을 적절히 선택해야 합니다.

추이는 선 그래프, 비교는 막대 그래프, 분포는 히스토그램이 적합합니다. 3D 차트나 파이 차트는 멋져 보이지만 오히려 데이터를 왜곡할 수 있습니다.

단순하고 명확한 것이 최선입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨가 대시보드를 실행하자, 화려한 그래프들이 나타났습니다. 김개발 씨는 눈이 반짝였습니다.

"와, 이렇게 보니까 GPT-4가 GPT-3.5보다 20% 더 좋네요! 한눈에 보여요!" 성능 대시보드를 만들면 데이터를 직관적으로 이해하고, 팀원들과 효과적으로 소통하며, 빠르게 의사결정을 내릴 수 있습니다.

이것이 바로 데이터 중심 조직의 핵심입니다.

실전 팁

💡 - Streamlit Cloud를 사용하면 무료로 대시보드를 배포할 수 있습니다

자동 새로고침 기능을 추가하면 실시간으로 평가 진행 상황을 모니터링할 수 있습니다
필터와 검색 기능을 추가하면 특정 기간이나 모델의 결과만 선택적으로 볼 수 있습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#LLM#Benchmark#Evaluation#HumanEval#LLM,평가,벤치마크

CodeDeck

오프라인 평가와 벤치마킹 완벽 가이드

목차

1. HumanEval 벤치마크 테스트

2. 코드 정확도 측정

3. Pass@k 메트릭 계산

4. LLM-as-a-Judge로 품질 평가

4. 베스트 프랙티스: 언어의 관례를 따르는가? (2점)

5. 실습: 자동 평가 시스템 구축

6. 실습: 성능 대시보드 만들기

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

AI 에이전트의 모든 것 - 개념부터 실습까지

프로덕션 RAG 시스템 완벽 가이드

RAG 캐싱 전략 완벽 가이드

실시간으로 답변하는 RAG 시스템 만들기