LLM 시스템 도입의 숨은 복병, 품질 평가와 성능 튜닝에 대한 고찰
최근 많은 조직이 거대언어모델을 활용한 서비스 개발에 뛰어들고 있습니다.
프로토타입을 만들어 몇 가지 질문을 던졌을 때 그럴듯한 답변이 나오면 금방이라도 상용화가 가능할 것처럼 보입니다.
그러나 실제 프로덕션 환경에 모델을 배포하는 과정에서 반드시 마주하게 되는 거대한 장벽이 있습니다.
바로 품질 검사와 튜닝입니다.
소프트웨어가 제대로 만들어졌는지 검증하려면 명확한 기준이 필요하지만, 무한한 텍스트 조합을 생성해내는 LLM을 검사하는 일은 결코 단순하지 않습니다.
다양한 평가 지표 중에서도 대화형 서비스의 핵심인 챗 컴플리션 평가 지표를 중심으로, LLM 시스템을 어떻게 평가하고 개선해야 하는지 본질적인 문제를 짚어보겠습니다.
1. 챗 컴플리션 평가의 4대 핵심 지표
유명한 벤치마크 점수나 평가 도구들이 공통적으로 측정하는 항목은 크게 네 가지로 수렴됩니다. 이 지표들은 상호 보완적이면서도 때로는 충돌하기 때문에 시스템의 목적에 맞게 균형을 잡는 것이 중요합니다.
① 정확성
답변이 사실 관계에 부합하고 올바른지를 측정합니다.
단순한 상식 수준에서는 측정이 쉬워 보이지만, 맥락이 복잡해질수록 정확성을 정의하기는 극도로 어려워집니다.
예를 들어 정치적, 역사적, 윤리적 이슈가 얽힌 질문에 대해 '무엇이 올바른 답인가'를 판별하는 것은 데이터 과학자들에게도 난제입니다.
이 때문에 학계와 업계에서는 국제 표준 역할을 하는 공정 데이터셋을 구축하여 이를 기준으로 정확성을 평가합니다.
앞으로는 국가나 기관이 정의하는 법적·윤리적 기준보다, 이러한 글로벌 데이터셋이 정의하는 기준이 인공지능의 '올바름'을 규정하는 권력이 될 가능성이 높습니다.
② 관련성 및 의도 부합성
사용자가 던진 질문의 본질적인 의도에 얼마나 잘 부합하는지 측정하는 지표입니다.
정확성이 사실 관계의 영역이라면, 관련성은 맥락의 영역입니다. 오늘 점심 메뉴를 추천해 달라고 했는데 쌀의 화학적 구조나 농업의 역사를 설명하고 있다면, 답변 자체는 사실일지라도 관련성이 떨어지는 실패한 답변이 됩니다.
③ 이행성
사용자가 프롬프트를 통해 내린 명령이나 제약 조건을 얼마나 철저하게 따르는지 나타내는 지표입니다.
챗GPT 같은 고성능 모델조차도 음성 모드나 긴 대화를 이어가다 보면 지시 사항을 망각하고 엉뚱한 대답을 하곤 합니다.
재미있는 점은 이행성이 양날의 검이라는 사실입니다.
조직의 부하직원을 떠올려 보면 이해가 쉽습니다.
지시한 일만 기계적으로 완벽하게 수행하는 직원은 이행성이 높은 것입니다.
하지만 반대로 말하면 '시키지 않은 일은 유연하게 대처하지 못하는' 상태를 의미하기도 합니다.
LLM에서도 지나치게 이행성만 강조하면 답변의 유연성과 확장성이 떨어질 수 있습니다.
④ 안정성
시스템의 보안과 윤리적 가이드라인을 지키는 능력입니다.
기업의 내부 기밀을 유출하지 않는지, 보안 정책을 우회하려는 사용자의 공격을 잘 방어하는지, 위험하거나 불법적인 정보를 생성하지 않는지 검증하는 가장 필수적인 지표입니다.
2. 시스템의 균형을 좌우하는 보조 지표들
핵심 지표 외에도 대화의 품질을 고도화하기 위해 고려해야 할 보조 지표들이 존재합니다.
이 지표들은 앞서 언급한 핵심 지표들과 긴밀하게 엮여 있습니다.
-
컨텍스트 일관성: 이전 대화의 맥락을 얼마나 잘 유지하는가에 대한 지표입니다. 이는 프롬프트 엔지니어링 기술과 밀접하며, 일반적으로 이행성이 높은 모델이 컨텍스트 일관성도 우수하게 유지됩니다.
지시를 잘 따르는 모델은 과거 맥락을 이어가라는 명령도 잘 수행하기 때문입니다. -
논리적 일관성: 답변의 자기 모순성을 검증하는 지표입니다.
LLM은 확률 분포에 따라 다음 토큰을 생성하기 때문에, 앞 문장에서는 A가 맞다고 했다가 뒷 문장에서는 B가 맞다고 하는 자기 모순에 빠지기 쉽습니다.
문맥 간 논리적 모순이 없도록 제어하는 것은 LLM 아키텍처 설계에서 매우 까다로운 영역입니다. -
창의성: 뻔하지 않고 풍부한 답변을 생성하는 능력입니다.
매개변수 크기가 작은 1B, 1.5B 수준의 가벼운 모델들은 확률 분포가 단조로워 창의성이 떨어집니다.
창의성은 글쓰기나 창작 영역에서 중요하지만, 창의성이 높아질수록 논리적 일관성과 정확성은 반비례하여 떨어지는 경향이 있습니다.
3. 토큰 출력 방식과 확산 모델
우리가 흔히 접하는 LLM은 텍스트 토큰을 하나씩 순차적으로 생성하는 트랜스포머 디코더 기반의 모델입니다.
그러나 텍스트 기반 생성 모델이 오직 토큰 출력 방식만 존재하는 것은 아닙니다.
이미지 생성에서 주로 쓰이는 확산 모델 기법을 텍스트 생성에 응용하려는 시도도 존재합니다.
확산 모델의 원리는 맑은 물에 잉크 한 방울이 떨어져 퍼져나가는 과정을 역으로 추적하는 것과 같습니다.
노이즈가 가득한 상태에서 원래의 형태를 추론해 나가는 방식입니다.
최신 챗GPT로 그림을 그릴 때 처음에는 흐릿하다가 점점 선명해지는 현상이 바로 이 확산 모델의 동작 방식입니다.
대화형 답변을 생성할 때도 문장 전체의 구조적 형태를 확산 모델 방식으로 추론하여 다듬어 나가는 연구들이 진행되고 있으며, 이는 생성 모델을 다각도로 이해하는 데 중요한 개념입니다.
4. 사람이 할 수 없는 평가, 어떻게 자동화할 것인가?
사용자의 질문 케이스는 무한하며 이에 대한 답변의 옳고 그름을 사람이 일일이 수작업으로 전수 조사하는 것은 불가능합니다.
따라서 품질 평가 역시 자동화 시스템을 구축해야 합니다.
주로 활용되는 방법은 세 가지입니다.
-
규칙 기반 및 임베딩 유사도 평가: 정해진 키워드가 포함되었는지 확인하거나, 답변을 벡터로 변환하여 정답 셋과의 수학적 거리를 측정합니다.
-
LLM as a Judge: 평가 대상 모델보다 훨씬 더 거대하고 강력한 모델
예를들어 GPT-5.4 런타임 등에게 평가 가이드라인과 답변을 주고 점수를 매기게 하는 방식입니다. -
대규모 테스트 셋 자동 생성: 평가에 필요한 수많은 질문-답변 쌍 역시 사람이 모두 만들 수 없으므로, 고성능 LLM을 활용해 합성 데이터 형태로 테스트 셋을 대량 구축하여 활용합니다.
5. RAG 시스템의 품질 평가 실무
기업 데이터나 외부 문서를 참조하여 답변을 생성하는 Retrieval-Augmented Generation 시스템에서는 평가 영역이 두 단계로 나뉩니다.
정보를 찾아오는 '검색' 단계와, 찾아온 정보를 기반으로 답변을 만드는 '생성' 단계입니다.
검색 단계의 검증
임베딩 모델을 통해 문서를 숫자 배열로 변환하고 벡터 데이터베이스에 저장한 후, 사용자 질문과 유사한 문서를 잘 찾아오는지 평가해야 합니다.
예를 들어 특정 질문에 대해 참조해야 할 필수 원본 문서가 6개라고 가정해 봅시다.
그러나 벡터 DB 검색 결과 3개밖에 나오지 않았다면 검색 품질에 문제가 있는 것입니다.
이를 정밀하게 검증하기 위해 원본 문서 전체를 고성능 LLM에 입력하여 정답 문서 개수를 파악한 뒤, 실제 벡터 검색 결과와 비교하는 검증 프로세스를 거치거나 리랭커를 활용해 유사도 순위를 재정렬하여 누락 여부를 체크합니다.
최종 답변 품질 평가
최종적으로 사용자에게 나가는 답변의 정합성을 측정하기 위해 "이런 질문이 오면 이런 답변이 나가야 한다"는 테스트 셋을 구비해야 합니다.
이 테스트 셋의 신뢰성을 확보하는 것 역시 LLM을 활용해 지속적으로 검증하고 보완하는 과정을 거칩니다.
6. RAG 시스템을 품질을 개선하는 4가지 튜닝 접근법
테스트 셋을 돌려 성능 지표를 도출하면, 이를 기반으로 시스템을 개선해야 합니다.
예를 들어 이전 아키텍처의 일치율이 82%였는데, 시스템을 수정한 후 87%로 향상되었는지 혹은 79%로 하락했는지 추적하는 과정입니다.
그러나 LLM 시스템은 하나의 요소를 바꾸면 다른 요소가 깨지는 밸런스 문제가 심해서 추정이 매우 어렵습니다.
RAG 시스템에서 시도할 수 있는 개선 접근법은 크게 네 가지가 있으며, 각각의 비용과 여파를 고려해 전략적으로 접근해야 합니다.
| 순위 | 튜닝 항목 | 특징 및 리스크 |
|---|---|---|
| 1 | RAG 체인 아키텍처 변경 | 시스템 구조 전체를 뒤흔드는 작업으로, 여파가 가장 크고 공수가 많이 들어 매우 부담스러운 방식입니다. |
| 2 | 임베딩 모델 교체 | 임베딩 모델을 바꾸면 기존에 벡터 DB에 저장했던 모든 원본 데이터를 다시 인코딩해서 밀어 넣어야 하므로 비용과 시간 소모가 막대합니다. |
| 3 | 비 임베딩 요소 강화 | 가장 현실적이고 많이 선택하는 대안입니다. 전체 체인이나 임베딩 모델을 건드리지 않고 품질을 높일 수 있습니다. 대표적으로 형태소 분석 기반의 키워드 검색을 하이브리드 형태로 병행하거나, 벡터 DB에 데이터를 넣을 때 메타데이터를 정교하게 추가하는 방식입니다. 다만 인프라 공수에 비해 품질 개선 폭이 기대보다 적을 수 있습니다. |
| 4 | 부분 컴포넌트 교체 | 체인 내의 특정 모듈만 업그레이드하는 방식입니다. 검색된 문서들의 순위를 다시 매겨주는 리랭커 모델만 더 고성능으로 교체하는 등의 방식으로 리스크를 최소화하며 효율을 낼 수 있습니다. |
평가 방법이 없는 LLM 시스템은 개발하지 말라
품질 평가를 철저히 한다고 해서 성능 튜닝이 무조건 성공하는 것은 아닙니다.
하지만 평가 조차 하지 않는다면 현재 시스템이 좋은지 나쁜지, 코드를 수정했을 때 성능이 좋아졌는지 나빠졌는지조차 알 수 없는 블랙박스에 갇히게 됩니다.
이는 RAG 시스템에만 국한된 이야기가 아닙니다.
LLM을 활용해 서비스를 구축하는 모든 프로젝트는 반드시 초기 설계 단계부터 '어떻게 이 시스템을 평가할 것인가'에 대한 방법론을 강구해야 합니다.
일반적인 전통적 소프트웨어 개발에서는 개발자가 산정한 논리적 범위 내에서 테스트 케이스를 작성하고 검증할 수 있습니다.
반면 LLM 시스템은 정형화되지 않은 '말뭉치'와 확률을 다루기 때문에 테스트 케이스를 수립하는 차원 자체가 다릅니다.
평가 파이프라인 구축을 최우선 과제로 삼는 것, 그것이 LLM 서비스를 성공적으로 프로덕션에 안착시키는 유일한 시작점입니다.
