LLM 기반 기능을 출시하기 전 가장 자주 생략되는 단계가 평가입니다. “데모에서 잘 되니까 괜찮겠지”라는 판단은 운영에서 반드시 깨집니다. 이 글에서는 생성형 작업에 맞는 평가 지표를 어떻게 설계하는지 실전 관점에서 정리합니다.
왜 정확도 하나로는 부족한가
분류 문제는 정답이 명확해 정확도로 측정됩니다. 그러나 요약·답변·생성 작업은 정답이 하나가 아니며, 표현이 달라도 옳을 수 있습니다. 단순 문자열 일치율로 측정하면 좋은 답을 틀렸다고 깎고, 그럴듯한 환각을 맞았다고 인정하는 일이 벌어집니다.
작업 유형별 핵심 지표
- RAG 답변: 충실성(근거 일치), 관련성, 출처 정확성
- 요약: 사실 보존율, 누락률, 간결성
- 검색 단계: 적중률(recall@k), 정밀도, MRR
- 분류: 정확도, F1, 혼동 행렬
특히 RAG에서는 검색 단계와 생성 단계를 분리해 평가해야 합니다. 답이 틀렸을 때 검색이 문맥을 못 가져온 것인지, 문맥은 좋은데 생성이 틀린 것인지 구분해야 고칠 곳을 알 수 있기 때문입니다.
LLM-as-judge 활용
사람이 매번 채점하기는 비쌉니다. 그래서 강력한 LLM을 채점자로 쓰는 방법이 널리 쓰입니다. 다만 채점 기준을 명확한 루브릭으로 제시하고, 0~5점 같은 척도와 판단 근거를 함께 출력하게 해야 신뢰할 수 있습니다. 채점자 모델의 편향(긴 답을 선호 등)을 인지하고 보정하는 것도 중요합니다.
판정 기준:
- 충실성(0-5): 답이 제공된 문맥에만 근거하는가
- 관련성(0-5): 질문에 직접 답하는가
출력: {"faithfulness": n, "relevance": n, "reason": "..."}평가셋 만들기
완벽한 대규모 평가셋이 없어도 괜찮습니다. 실제 사용자 질문 50~100개와 기대 답변·근거를 정리한 작은 골든셋만으로도 회귀 테스트가 가능합니다. 프롬프트나 모델을 바꿀 때마다 이 셋으로 점수를 비교하면 “개선했다고 믿었는데 실제로는 나빠진” 상황을 막을 수 있습니다.
측정할 수 없으면 개선할 수 없습니다. 작더라도 고정된 평가셋과 자동 채점 파이프라인을 갖추는 것이 LLM 제품 품질 관리의 출발점입니다.
정리
평가는 작업 유형에 맞는 지표를 고르는 것에서 시작합니다. RAG는 검색과 생성을 분리해 측정하고, 생성 품질은 루브릭 기반 LLM-as-judge로 자동화하며, 작은 골든셋으로 회귀를 막으세요. 평가 체계가 갖춰지면 그제야 개선이 과학이 됩니다.
