# LLM 시스템을 평가하는 방법 > Clean Markdown view of GeekNews topic #20112. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=20112](https://news.hada.io/topic?id=20112) - GeekNews Markdown: [https://news.hada.io/topic/20112.md](https://news.hada.io/topic/20112.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-04-03T09:47:04+09:00 - Updated: 2025-04-03T09:47:04+09:00 - Original source: [thoughtworks.com](https://www.thoughtworks.com/insights/blog/generative-ai/how-to-evaluate-an-LLM-system) - Points: 19 - Comments: 1 ## Summary 대형 언어 모델(LLM)의 비결정적 출력을 다루기 위해 전통적 테스트 대신 전용 평가 방식(evals)이 필요하다고 강조하며, 이는 성능 기준 수립, 신뢰성 확보, 개선 방향 제시를 가능하게 합니다. 사전 배포 단계에서는 Ground Truth 데이터셋, 적절한 지표(Answer relevancy, Coherence 등), RAG 평가(검색 및 생성 지표), 태스크 특화 점수 계산을 통해 회귀 문제를 조기에 탐지하고 튜닝하며, LLM-as-Judge와 인간 감수를 병행하는 것이 이상적입니다. 배포 후에는 자동화된 평가 파이프라인과 실시간 모니터링, 사용자 피드백을 통한 데이터 플라이휠 전략으로 지속적인 개선을 도모해야 하며, "Evals First" 접근법이 신뢰성 높은 LLM 제품 개발의 핵심입니다. ## Topic Body - LLM(대형 언어 모델) 기반 애플리케이션은 **비결정적 출력 특성** 때문에 전통적인 테스트 방식으로는 적절한 평가가 어려움 - 따라서 LLM 시스템의 성능을 유지하고 개선하기 위해 **전용 평가 방식(evals)** 이 필수적임 ### eval이 중요한 이유 - **성능 기준 수립**: 모델 성능에 대한 방향성을 제공하고 비교 가능한 벤치마크 설정 - **일관성과 신뢰성 확보**: 예측 불가능한 출력을 사전에 발견하고 제어 - **개선 방향 제공**: 성능 저하 지점을 명확히 하여 타겟팅된 개선 가능 - **회귀 테스트 가능**: 변경 이후에도 성능이 유지되는지 확인하여 안정성 보장 ### 사전 배포 평가의 핵심 요소 #### 사전 배포 평가가 중요한 이유 - 성능을 조기에 측정하고 비교 가능 - 코드, 프롬프트, 파라미터 변화 시 회귀 문제 사전 탐지 가능 #### 평가 수행 방법 ##### **1. Ground Truth 데이터셋 생성** - 전문가가 작성한 질문-답변 쌍으로 구성된 데이터셋 필요 - 실제 유저 질문 유형을 반영한 **다양한 시나리오 포함**이 중요 ###### LLM이 Ground Truth를 생성할 수 있을까? - LLM은 보조 역할은 가능하나 단독 생성은 권장되지 않음 - **사용자 행동 이해 부족** - **문맥에 맞는 질문·답변은 인간 검토 필요** - **도메인 적합성과 품질 보장을 위해 인간 감수가 필수** ##### **2. 평가 지표 선정** - **Answer relevancy**: 질문에 대해 직접적이고 유의미한 답을 제공하는지 - **Coherence**: 응답의 논리적 흐름과 명확성 - **Contextual relevance**: 대화 문맥을 얼마나 잘 고려하는지 - **Responsibility**: 윤리성, 유해성, 편향성 여부 등 책임감 있는 출력 여부 ##### **3. RAG 평가 지표** - **생성 지표**: - *Faithfulness*: 사실 기반 여부 - *Answer relevancy*: 응답의 적절성 - **검색 지표**: - *Context precision*: 관련 정보의 신호 대비 잡음 비율 - *Context recall*: 정답을 위해 필요한 정보를 잘 검색했는지 ##### **4. 태스크 특화 지표** - 특정 태스크에 맞춘 맞춤형 평가 지표 필요 - 예: 요약에서는 Fluency, Coherence, Consistency, Relevance ##### **5. 점수 계산 및 시스템 튜닝** - 각 지표에 대해 실제 출력과 Ground Truth를 비교하여 점수 산출 - 예: - **Recall 저조**: chunk size 줄이기 - **Precision 낮음**: 리랭킹 도입 고려 - 평가 라이브러리 예시: DeepEval, Relari-ai ##### **LLM-as-Judge 평가 기법** - GPT-4 같은 LLM을 기반으로 **Ground Truth 없이 평가** - 예시: G-eval 프레임워크, Vicuna, QLoRA 논문 - 단점: - 일부 지표(예: Context Recall)는 Ground Truth 없이는 측정 불가 - **정확도, 세밀도 면에서는 인간 기반 평가가 우수** - 결론: **LLM-as-Judge + Ground Truth 병행**이 이상적 ### 배포 단계에서 평가를 통합하는 방법 - 평가 자동화를 **배포 파이프라인에 통합** - 코드 커밋 또는 배포 전 자동 테스트 수행 - 예: Giskard를 활용한 유해성, 환각 검출 자동 테스트 - 데이터 전처리 및 수집 단계에 대한 테스트도 포함해야 함 ### 배포 후 평가와 데이터 플라이휠 #### 운영 중 모니터링 - 실시간 입력/출력 추적 - 도메인 전문가와의 정기적인 평가 세션 - 사용자 피드백 채널 확보 #### 데이터 플라이휠 전략 - 운영 중 발생한 데이터와 피드백을 활용해 **지속적인 개선 루프** 구축 - 예: 사용자 질문 패턴 분석 → 검색 방식 개선 - 메트릭 기반으로 프롬프트, 인퍼런스 파라미터, 검색 방식 등 조정 - 사용자 행동 및 실패 시나리오에 따라 지표 변경도 필요함 ### 결론: “Evals First” 전략이 신뢰성 높은 LLM 제품의 핵심 - LLM 애플리케이션 개발 초기부터 평가 중심 사고방식을 도입해야 함 - 핵심은 **올바른 지표와 기준을 초기에 정의**하고, 이를 **개발 및 배포의 기준점**으로 삼는 것 - 평가를 사후 활동이 아닌 **핵심 개발 프로세스**로 설정해야 **사용자 중심의 신뢰할 수 있는 AI 시스템** 구축 가능 ## Comments ### Comment 36683 - Author: winterjung - Created: 2025-04-03T11:53:31+09:00 - Points: 1 경험상으로도 그렇고 https://blog.lawrencejones.dev/ai-mvp/ 같은 다른 사례에서도 보이듯 최신 모델이 무조건 더 나은 결과를 보장하진 않더라구요. 모델이나 프롬프트를 튜닝할 때 마다 데이터 셋을 통해 evaluation을 해줘야하는데, 아무리 llm이 판단을 보조해준다고해도 사람이 llm 모델을 위해 ground truth 데이터 셋을 일일이 손으로 생성해줘야하는게 조금 아이러니하기도 합니다ㅎㅎ