좋은 기회로 HAE-RAE팀의 사이드프로젝트 멤버로 합류하여 실험에 사용될 코드를 작업하게 되었다.
한국어에 특화된 LLM 평가 툴킷을 개발하여 논문으로 발표하는데,
부트캠프에서 갓 배워온 쪼무래기 초보자가 여기에 참여할 수 있다니 말이다.
내 기준으로는 0.001%도 기여했나 싶을 정도로 부끄럽지만
논문 제출 날 내 이름도 함께 올라가 있어서 가족들에게 자랑도 했다. ㅎㅎㅎㅎ
*하단 캡쳐는 다른 분들의 이름도 함께 노출되다 보니 개인정보 이슈로 블러 처리함
그래서 이 논문에 대해 리뷰하는 시간을 가지면서 동시에
어떻게 동작하는지도 테스트 해보고자 한다.
HAE-RAE 소개
HAE-RAE는 한국어 모델의 해석 가능성과 평가에 초점을 맞춘 비영리 오픈소스 단체이다. 이 단체의 미션은 통찰력 있는 벤치마크와 도구로 해당 분야를 발전시키는 것이다.
아래 링크에서 HAE-RAE와 관련된 자세한 정보를 확인할 수 있다. 😉
지금까지 HAERAE-BENCH, KMMLU, csat-qa, k2-eval 등의 벤치마크를 공개했는데,
해당 내용들은 위의 허깅페이스 링크로 들어가면 확인할 수 있다.
이 랩의 랩장은 아래 두 분으로 되어 있다.
두 분 중,
나는 부트캠프에서 멘토로 오셨던 '이한울 AI 엔지니어' 분에게 사이드프로젝트 참여 의사를 밝히어 참여하게 되었다.
논문 리뷰
1. 소개
haerae-evaluation-toolkit 관련 자료 및 영상
- GitHub: https://github.com/HAE-RAE/haerae-evaluation-toolkit
- YouTube: https://www.youtube.com/watch?v=aqWVLKxstHI
논문 제목은
HRET: A Self-Evolving LLM Evaluation Toolkit for Korean으로,
한국어 대형 언어 모델(LLM)에 대해 표준화된 평가환경에서 포괄적인 유효성 검증 기능을 지원하기 위한 오픈소스 라이브러리이다.
주요 특징은 다음과 같다.
- HRET는 주요 한국어 벤치마크((HAE-RAE Bench, KMMLU, KUDGE, HRM8K 등)를 통합
- 평가 기법(문자열 일치, 언어 불일치 패널티, 로그 확률 기반 평가, LLM-as-judge)을 지원
- Test-time-scale(Beam Search, Best-of-N, Self-Consistency Voting)을 제공하여 언어 모델의 성능을 여러 각도로 평가
- HuggingFace를 통한 on-premise 사용뿐만 아니라, litellm, openai-compatible api를 통해 100+개의 online inference와 연동 가능하도록 설계
- HRET는 한국어 NLP 연구의 재현성과 투명성을 향상시키고, 일관된 대규모 실험 환경을 제공하는 것을 목표
그리고 HRET 평가 툴킷의 강점은 Self-Evolving인데,
평가 대상과 방식이 바뀌어도 유연하게 적응하며 자동화된 방식으로 계속해서 진화할 수 있는 점이다.
| 대상 | 설명 |
| 벤치마크 | 새로운 한국어 벤치마크(KMMLU, KUDGE 등)를 계속 추가할 수 있음 |
| 모델/백엔드 | 다양한 LLM 모델(OpenAI, HuggingFace, vLLM 등) 연결 확장 가능 |
| 평가 방식 | 문자열 일치, 언어 불일치 패널티, 로그 확률 기반, LLM-as-a-Judge 등 평가 방식도 지속 추가 가능 |
| 자동화 | 커맨드라인 인터페이스(CLI)와 파이프라인 구성으로 쉽게 업데이트 & 반복 실행 가능 |
즉, 사용자가 새 평가 기준이나 모델을 넣으면 툴킷이 그 구조 안에서 알아서 평가 루틴을 구성하고 실행할 수 있도록 설계되었다.
이 부분이 왜 중요한가 하면,
기존 평가 프레임워크는 아래와 같은 문제점들을
- 새로운 모델이 나올 때마다 코드 수정이 필요함
- 벤치마크 형식이 달라서 재현이 불가능함
- 다양한 평가 방법을 결합하기 어려움
모듈형 구조와 자동화된 파이프라인으로 해결하여 재현성, 확장성, 공정성 있는 평가가 가능하도록 했기 때문이다.
2. 관련 연구 및 배경
'영어' 기반인 LLM생태계는 견고한 평가 프레임워크를 구축한 상태이며(Evalverse, deepeval, lm-evaluation-harness),
이를 기반으로 전 세계의 LLM 개발이 가속화되고 있다. 그리고 중국은 FlagEval(Team, 2025)를 통해 자국 언어 중심의 생태계 발전을 추진하고 있다.
반면, 한국어 자연어처리(NLP) 평가에서는 재현성(reproducibility) 부분에서 적지 않은 문제가 발생하고 있다.
아래 표를 보면,
대표적으로 널리 사용되는 LLM 모델인 Gemma2-27B(Team 외, 2024), Qwen2.5-32B(Yang 외, 2024)에 대해 동일한 벤치마크를 사용했음에도 불구하고 평가 기관에 따라 성능 차이가 크게 발생한 것을 알 수 있다.
이러한 결과는 추론 환경, 프롬프트 엔지니어링, 평가 구현 방식의 차이에서도 비롯되지만
'한국어'의 언어적 특성인 복잡한 형태소, 문맥간 의미 고려, 높임말 체계 등 으로 더욱 심화되었다.
다만,
현존하는 벤치마크에는 '한국어'에 특화된 표준 지침이 부족하고, 평가 관행이 단절되고 있어 한국어 NLP 연구가 더디게 발전하고 있다.
3. HRET 프레임워크
HRET(Haerae Evaluation Toolkit)는
한국어 대형 언어 모델(LLM) 평가에서 발생하는 재현성과 비교 가능성의 문제를 해결하기 위한 도구로,
한국어 자연어처리(NLP) 연구에서 일관성, 투명성, 접근성을 향상시키는 것을 목표로 한다.
또,
한국어 LLM 평가의 문제를 해결하기 위해 다음과 같은 기능을 도입했다.
3.1 설계 원칙
- 자기 진화 메커니즘 (Self-Evolving)
- 실행 중 새로운 평가 방식, 데이터셋, 추론 백엔드를 자동으로 발견하고 통합
- 핵심 코드 수정 없이 구성요소를 동적으로 통합할 수 있는 구조
- 사전 정의된 워크플로우 없이도 새로운 시나리오에 적응 가능
- 레지스트리 기반 모듈화 (Registry-Based Modularity)
- 데이터셋 로더, 평가 기법, 추론 전략, 모델 백엔드 등 핵심 요소들을 독립적으로 구성
- 코드를 거의 수정하지 않고도 손쉽게 확장 가능
- 동시성 및 확장성
- httpx를 활용한 비동기 HTTP 요청, 멀티스레딩 기반 대규모 평가 처리
- 통합 API 제공
- Evaluator 및 PipelineRunner 인터페이스를 통해 사용자가 쉽게 접근 가능
- 한국어 특화 기능
- 한국어 전용 벤치마크 내장
- 언어 일관성 확인 등 한국어 특유의 평가 요구에 맞춘 기능 제공
3.2 시스템 아키텍처 및 구성요소
HRET는 주요 한국어 NLP 벤치마크에 대해 표준화된 5단계 평가 워크플로우를 제공한다.
- 데이터셋 로딩
- 레지스트리를 통해 다양한 한국어 NLP 데이터셋을 통합 형식으로 제공
- 커스텀 데이터셋도 유연하게 로딩 가능
- 모델 로딩
- HuggingFace, OpenAI 호환, LiteLLM 등 다양한 백엔드와 연동
- 모델 생성, 판단(judge), 보상 기능을 일관된 인터페이스로 제공
- 추론 및 스케일링
- Beam Search, Best-of-N Sampling, Majority Voting 등 고급 추론 기법으로 평가 품질 향상
- 평가
- 스트링 매칭, 로그잇 기반, LLM-as-a-Judge 기반 등 다양한 평가 방법 지원
- 비한국어 응답 감지, 답변 추출 기능 등 평가 향상 기능 포함
- 결과 리포팅
- Runner 및 Evaluator가 전체 파이프라인을 관리
- 단순한 API로 결과 요약 제공
3.3 고급 기능 및 활용
HRET는 다양한 추론 백엔드를 단일 인터페이스로 통합 지원한다.
- HuggingFace Transformers – KoGPT, HyperCLOVA 등 한국어 특화 모델 사용 가능
- vLLM – 대규모 벤치마크에서 높은 처리량 성능 제공
- OpenAI 호환 API – 국내 AI API 서비스와의 호환성 확보
- LiteLLM – 다양한 제공업체와의 통합 비교 가능
또한 PipelineRunner는 다음과 같은 고급 워크플로우를 지원한다.
- 모델 출력 결과를 다음 단계 입력으로 사용하는 다단계 평가
- 다양한 벤치마크 및 메트릭을 활용한 종합 모델 비교
- 한국어 특화 평가를 위한 사용자 정의 워크플로우
- 앙상블 평가를 통한 다중 모델 조합
3.4 사용 예시
간단한 CLI 명령어로 HRET를 사용할 수 있는데, 이 명령은 다음을 수행한다.
- HAE-RAE 벤치마크에서 csat_geo 하위셋 로드
- HuggingFace 모델 로드
- 정확도 기반(string match) 평가 실행
- 결과를 JSON으로 출력
# 예시: HAE-RAE 벤치마크 평가
python -m llm_eval.evaluator \
--model huggingface \
--model_params '{"model_name_or_path": "google/gemma-3-1b-it"}' \
--dataset haerae_bench \
--subset csat_geo \
--split test \
--evaluation_method string_match \
--output_file results.json
4. 시스템 검증 및 로드맵
HERT는 다양한 설정과 이용 사례에서 모든 구성 요소가 높은 신뢰도로 잘 작동하는지 확인하기 위해 기능 테스트를 포함한 QA를 거쳤다.
또, 해당 프레임워크는 HAE-RAE Reasoning Challenge 리더보드의 백엔드 시스템으로 배포되어 다양한 모델 제출과 평가 기준을 수용하는 생산 환경에서도 높은 안정성과 견고성을 입증했다.
그리고 대규모 한국어 벤치마크 데이터셋을 대상으로 광범위한 성능 테스트를 수행하여 비동기 및 멀티스레딩 기능의 성능 향상을 검증했다.
HRET는 현재까지도 활발히 개발 중에 있으며,
향후 플러그인 기반의 레지스트리 아키텍처를 활용한 확장성 향상을 위해 hret-agent의 고도화를 통한 self-evolving 메커니즘을 강화할 예정이다.
5. 실험
HRET가 한국어 LLM 평가에서 직면하는 주요 과제를 어떻게 해결하는지 보여주기 위해 두 가지 실험을 수행했다.
5.1 언어 일관성 평가(Language Penalizer를 활용한 평가)
다국어 모델은 종종 영어로 응답하는 경향이 있기 때문에 '한국어'로 된 과제에서 평과 결과를 왜곡시킬 수 있다.
이에 HRET의 language penalizer는 이러한 응답을 감지하고 처리하여 한국어 능력을 정확히 반영하도록 했다.
| 모델 | 점수 (언어 패널라이저 미사용) |
점수 (언어 패널라이저 사용) |
| Qwen2.5-7B | ↓ | 성능 감소 |
| Qwen2.5-3B | ↓ | 성능 감소 |
| EXAONE-2.4B | → | 성능 유지 |
| Llama-3.1-8B | → | 성능 유지 |
| EXAONE-7.8B | → | 성능 유지 |
5.2 다중 평가 방법(Multi-Method Evaluation)
HRET는 과제 유형에 따라 다양한 평가 방법을 지원한다.
아래 표는 EXAONE-3.5-2.4B 모델을 HRM8K와 CLIcK 벤치마크에서 평가한 결과를 비교한 것이다.
| 벤치마크 | 문자열 위치 (String-Mathc) |
수학 검증 (Math-Verify) |
| HRM8K | 2.21 | 14.11 |
| CLIcK | 27.31 | 28.67 |
핵심 인사이트:
- 수학적 추론이 요구되는 HRM8K의 경우, 평가 방법에 따라 성능 차이가 6.4배까지 발생
- CLIcK처럼 언어 이해 중심 데이터셋은 평가 방법 간 차이가 1.36%로 상대적으로 적음
- 과제 특화된 평가 지표는 모델의 능력을 보다 정확하게 반영함
- HRET은 연구자가 각 한국어 과제에 가장 적합한 평가 방법을 선택할 수 있도록 지원함
6. 결론
정리하면,
HERT는 '한국어 대형 언어 모델(Korean LLM)'을 위해 설계된 self-solving 기반의 모둘형 평가 툴킷으로,
표준화된 평가 방법과 개선된 재현성, 그리고 한국어 특유의 뉘앙스를 반영하여 평가의 정밀도를 높인다.
향후에는
- 특정 도메인(법률, 의학, 과학 등)에 특화된 언어 분석 벤치마크의 확장
- 최신 LLM 오픈소스 라이브러리와의 심화 통합
- 오류 진단을 위한 시각화 도구의 고도화 등
이 진행될 예정이며,
궁극적으로는
HRET은 한국어 자연어처리(NLP) 연구의 탄탄한 기반을 구축하고, 연구 커뮤니티 내의 지속적인 발전과 협업을 지원하는 것을 목표로 한다.
한계점 (Limitations)
HRET은 한국어 LLM을 위한 표준화된 평가 프레임워크를 제공하지만, 다음과 같은 몇 가지 한계가 존재한다.
- 전문 분야 도메인 커버리지 부족: 주요 한국어 벤치마크는 통합했지만, 법률, 의료, 과학 등 특수 분야에 대한 데이터셋은 제한적이다.
- 혼합 언어 처리의 어려움: language penalizer는 영어와 한국어가 혼용되거나 code-switching이 발생하는 경우 정확하게 작동하지 않을 수 있다.
- 계산 자원 요구량: 스케일링 기술(beam search, majority voting 등)은 상당한 자원이 요구되므로, 접근성이 낮아질 수 있다.
- 형태소 특성 미반영 문제: 현재 사용 중인 문자열 일치 기반 평가 방식은 한국어의 복잡한 형태소 구조를 충분히 반영하지 못할 수 있다.
- 지속적인 업데이트 필요: 새로운 한국어 LLM과 벤치마크가 지속적으로 등장함에 따라, 지속적인 호환성 유지가 필요하다.
- 한국어 오류 분석 도구 부족: 한국어 고유의 언어 현상과 관련된 모델 오류를 분석할 수 있는 도구가 제한적이다.
이러한 한계들은 지속적인 개발을 통해 해결해 나가고 있으며, 커뮤니티의 기여를 통해 HRET의 기능을 더욱 향상시키고자 한다.
HRET 테스트
테스트는 HAE-RAE 툴킷 깃헙에서 git clone 한 다음에 테스트 해 볼 수 있다.
README에도 코드가 있지만, tutorial>01-quick-start.md 에서 스텝 바이 스텝으로 실행시켜 볼 수 있다.
다만, 모델 부분에서는 'google/gemma-3-1b-it'로 기재되어 있는데,
허깅페이스의 모델 접근 허용이 어려워서 kanana로 실행했다.
참고로 kanana는 카카오에서 개발한 LLM인데, 이번 기회에 나도 처음 사용해 보았다.
kanana는 카카오에서 개발한 한국어에 특화된 LLM(Large Language Model)입니다.
모델 종류:
- kanana-nano-2.1b-instruct: 21억 파라미터의 작은 모델
- kanana-7b-instruct: 70억 파라미터의 중간 크기 모델
- kanana-13b-instruct: 130억 파라미터의 큰 모델
특징: 한국어에 최적화된 토크나이저 사용, 한국어 데이터로 특별히 학습됨, 인스트럭션(instruction) 형식에 특화, 카카오의 자체 데이터로 학습
성능: 한국어 이해 및 생성에 강점작은 모델(nano)도 한국어 작업에서 좋은 성능인스트럭션 형식의 프롬프트에 잘 반응
장점: 한국어에 특화되어 있어 다른 모델보다 한국어 성능이 좋음, 작은 모델도 사용 가능하여 리소스 요구사항이 낮음, 카카오의 안정적인 지원
단점:영어나 다른 언어에서는 성능이 제한적, 큰 모델은 리소스 요구사항이 높음
python -m llm_eval.evaluator \
--model huggingface \
--model_params '{"model_name_or_path": "kakaocorp/kanana-nano-2.1b-instruct"}' \
--dataset haerae_bench \
--subset standard_nomenclature \
--split test \
--evaluation_method string_match \
--output_file results.json
위 코드를 실행시키면,
results.json 파일이 생성되는데 평가 결과와 평가 정보, 그리고 각 샘플별 결과가 저장된다.
1. 평가 정보 (info):
- dataset_name: "haerae_bench" - HAE-RAE 벤치마크 데이터셋을 사용함
- subset: "standard_nomenclature" - 표준 명명법 관련 하위 데이터셋을 평가함
- split: "test" - 테스트 데이터로 평가했습니다
- model_backend_name: "huggingface" - HuggingFace 모델을 사용함
- evaluation_method_name: "string_match" - 문자열 일치 방식으로 평가함
- elapsed_time_sec: 1902.61 - 평가에 약 31분 42초가 소요됨
"info": {
"dataset_name": "haerae_bench", // 사용된 데이터셋
"subset": "standard_nomenclature", // 하위 데이터셋
"split": "test", // 데이터 분할
"model_backend_name": "huggingface", // 사용된 모델 백엔드
"evaluation_method_name": "string_match", // 평가 방법
"elapsed_time_sec": 1902.61 // 소요 시간
}2. 평가 결과:
각 샘플마다 다음 정보가 포함되어 있다.
- input: 모델에 입력된 질문
- reference: 정답
- prediction: 모델이 예측한 답변
- options: 선택지 (A)~(E)
- language_penalizer: 0.0 - 언어 불일치 페널티가 없음 (한국어로만 답변)
"samples": [
{
"input": "질문 내용", // 입력 질문
"reference": "정답", // 참조 정답
"prediction": "모델의 답변", // 모델이 생성한 답변
"options": ["A", "B", "C", "D"], // 선택지
"language_penalizer": 0.0, // 해당 샘플의 언어 불일치 패널티
"chain_of_thought": "추론 과정", // CoT가 사용된 경우 추론 과정
"logits": [...] // 로그 확률 (log_likelihood 평가 시)
},
// ... 더 많은 샘플들
]3. 성능 지표:
이 결과는 모델이 표준 명명법 관련 테스트 데이터에 대해 얼마나 잘 수행했는지를 보여준다.
특히,
문자열 일치 방식으로 평가되었기 때문에, 모델의 답변이 정확히 정답과 일치해야 점수를 받게 되며,
언어 불일치 패널티가 0이므로, 모델이 한국어로만 답변했다는 것을 의미한다.
- accuracy: 정확도 (예측이 정답과 일치하는 비율)
- language_penalizer_average: 언어 불일치 페널티의 평균값
"metrics": {
"accuracy": 0.7320261437908496, // 정확도 점수
"language_penalizer_average": 0.0 // 언어 불일치 패널티
}
정확도 점수가 0.73으로 나와서, 어떻게 해석해야 하는지 Chatgpt의 도움을 받아보니 아래와 같은
답변을 뱉었다.
73.2%의 정확도는 표준 명명법 평가에서 꽤 좋은 성능입니다.
그 이유는:
1. 평가의 난이도:
- 표준 명명법은 전문적인 용어와 규칙을 포함
- string_match 방식은 정확한 문자열 일치를 요구하는 엄격한 평가 방식
- 작은 모델(kanana-nano-2.1b-instruct)을 사용했다는 점을 고려하면 더욱 좋은 성능
2. 비교 관점:
- 일반적인 한국어 LLM의 표준 명명법 이해도는 보통 50-60% 정도
- 70% 이상은 상위권 성능으로 볼 수 있음
- language_penalizer_average가 0.0인 것은 모델이 일관되게 한국어로만 답변했다는 의미
3. 개선 가능성:
- 더 큰 모델(예: kanana-7b-instruct)을 사용하면 성능이 더 향상될 수 있음
- partial_match 평가 방식을 사용하면 더 높은 점수를 얻을 수 있음
- beam_search나 self_consistency 같은 기법을 적용하면 성능이 개선될 수 있음
전반적으로 73.2%는 표준 명명법 평가에서 매우 좋은 성능이라고 할 수 있습니다. 특히 작은 모델을 사용했다는 점을 고려하면 더욱 그렇습니다.
즉, 작은 모델을 사용했음에도 매우 좋은 성능을 보였으며, 더 큰 모델을 사용한다면 정확도가 더 올라갈 수 있다고 한다.
다만, 이 포스팅에서는 이 포스팅에서는 가장 간단하고 빠른 방법인 quick-start만 진행해 보았으므로
모델과 데이터셋은 하나만 사용해보았다.
그러므로
이 툴킷의 정확도를 더 확인해보고자 한다면 다양한 모델과 데이터셋으로 테스트해 보면 좋을 듯하다.
참고로,
튜토리얼에서 여러 방법으로 테스트를 해볼 수 있다.
논문 리뷰 후기
이 포스팅을 작성하면서
튜토리얼을 통해 처음으로 테스트 해보았다.
결과값이 뚝딱 나오는 것도 신기했고,
길지 않은 시간 동안 이러한 프레임워크를 만들어냈다는 것도,
또 이걸 영어로된 논문까지 작성을 마치기까지 모든 과정이 나에겐 흥미로운 경험이었다.
개인적으로 이런 프로젝트에 참여해 보았다는 경험 자체가 나에겐 큰 도전이자 성과였다. ..! 😇
이 과정에서 멘토님께 코드 리뷰도 받아보고
가이드도 받아보고,
구글밋 회의와 디코 채널에서의 주고받는 대화들을 보면서도 많이 배울 수 있었는데,
특히
협업 방식이다 보니
다른 분들이 작성한 코드가 하나로 정리되고,
모두가 사용할 수 있는 라이브러리로 완성되어 가는 경험을 직간접적으로 해보았다는 것에서 경험치가 꽤 많이 쌓였다.
(하지만 쉽다고는 하지 않았다.. ㅎㅎㅎ배운 지 얼마 안 된 쌩초보가 참여해서 하려니 쉬워 보이는 작업 하나에도 큰 부담으로 다가와서 내 실력이 정말 아쉬웠다 ㅠㅠ)
그리고 첫 논문 리뷰였는데,
영어로 되어 있는 것쯤이야 뚝딱 Chatgpt 돌려서 번역하고 요약해서 작성해야지 생각했지만... 응... 경기도 오산이었다. 😎
본 리뷰는 ACL 2025 Demo Submission으로 등록된 HRET 논문을 기반으로 작성되었습니다.
논문 저작권은 원저자에게 있으며, OpenReview에 등록된 내용을 바탕으로 해석 및 요약하였습니다.