LLM 성능 평가 (RAGAS)

첫 PoC든 운영 중인 시스템을 개선하는 중이든, LLM이 얼마나 잘 하는지를 알아야 한다. temperature를 바꾸거나 시스템 프롬프트를 고치거나 모델을 통째로 교체할 때, 그 결정의 영향을 지표로 재야 판단할 수 있다. 이번 편은 LLM 단계의 성능을 재는 방법을 정리한다.

 

 

1. LLM의 역할부터 분리하기

LLM은 복잡한 시스템 안에서 동작하므로, 먼저 LLM이 책임지는 과제를 분명히 해야 한다. retriever의 일은 knowledge base에서 관련 정보를 찾는 것이고, LLM의 일은 그 정보로 좋은 응답을 구성하는 것이다. 따라서 LLM을 조정·교체할 때 쓰는 지표는 전체 파이프라인 중 LLM의 역할에 초점을 맞춰야 한다. 문제가 사실 retriever에 있다면, 시스템 프롬프트를 다시 쓰느라 시간을 낭비하면 안 된다.

그림 1. retriever(검색) vs LLM(응답 구성). LLM 지표는 LLM의 역할에 초점을 맞춰야 한다.

 

retriever가 잘 동작한다고 보면, 대체로 관련 정보에 약간의 무관한 문서가 섞여 온다. 그럼 LLM의 일은 사용자 질문에 답하되 관련 정보를 녹이고 적절히 인용하며, 섞인 무관한 정보에 흔들리지 않는 것이다. 문제는 이런 행동이 대부분 주관적이라는 점 — "질문에 잘 답했다/무관 정보를 잘 무시했다"를 어떻게 정량화할까? 그래서 대부분의 LLM 지표는 다른 LLM으로 응답 품질을 평가한다. 평가에 LLM을 끼우면 주관성을 확장 가능한 방식으로 다룰 수 있다.

그림 2. LLM의 책임 — 관련 정보 반영·인용, 무관 정보 무시. 이런 주관적 품질은 RAGAS 같은 LLM 기반 지표로 잰다.

 

 

2. Response Relevancy (응답 관련성)

오픈소스 RAGAS 라이브러리가 이런 RAG 지표의 좋은 출처다. 첫 지표 Response Relevancy는 응답이 실제로 사용자 프롬프트와 관련 있는지를(사실 정확성과 무관하게) 잰다. 방식은 이렇다 — ① 시스템이 낸 응답을 새 LLM에 주고 그 응답을 낳았을 법한 예시 프롬프트 여러 개를 생성한다. ② 원래 사용자 프롬프트와 이 예시 프롬프트들을 임베딩한다. ③ 원래 프롬프트와 각 예시의 코사인 유사도를 구해 ④ 평균 낸다. 이 값이 응답 관련성이다. 사실성을 보장하진 않지만, 응답에서 원래 프롬프트로 합리적으로 거슬러 올라갈 수 있는지를 확인한다.

그림 3. Response Relevancy — 응답으로부터 역으로 예시 프롬프트를 만들고, 원 프롬프트와의 코사인 유사도를 평균낸다.

 

 

 

3. Faithfulness (충실성)

LLM이 검색 정보를 실제로 사용했는지는 Faithfulness 지표로 잰다. 언어 모델로 응답 속 모든 사실 주장(factual claims)을 식별하고, 추가 LLM 호출로 그 주장들이 검색된 정보 조각에 의해 얼마나 뒷받침되는지를 판정한다. 뒷받침되는 주장의 비율이 그 (프롬프트·검색·응답)에 대한 충실성이다.

그림 4. Faithfulness — 응답의 사실 주장 중 검색 정보로 뒷받침되는 비율.

 

 

4. 그 밖의 RAGAS 지표

RAGAS의 다른 지표들도 비슷한 방식으로, 검색된 무관 정보에 대한 민감도나 정확한 출처 인용 능력 같은 것을 평가한다. 공통 패턴은, 평가 과정 어딘가에서 LLM 호출에 의존하고 때로는 ground truth 정답 예시도 필요하다는 것이다. 이는 RAG에서 LLM의 역할이 복잡해 단순한 자동 지표로는 평가가 어렵다는 사실을 말해 준다.

그림 5. 그 밖의 RAGAS 지표 — 무관 정보 민감도·인용 정확성 등. 모두 어딘가에서 LLM 호출에 의존한다.

 

 

 

5. 간접 측정 — 시스템 전체 지표 + A/B

LLM 전용 eval 외에, 시스템 전체를 관통하는 지표로 LLM 성능을 간접 측정할 수도 있다. 예를 들어 사용자가 응답에 thumbs up/down을 남길 수 있다면, 시스템 프롬프트 변경을 A/B 테스트해 전체 만족도에 어떤 영향을 주는지 볼 수 있다. 핵심은 시스템 전체 성능을 재되 변경을 LLM 설정으로만 국한해, 성능 변화를 그 변경에 귀속시키는 것이다.

그림 6. 간접 측정 — 시스템 전체 피드백(thumbs)과 A/B 테스트로 LLM 설정 변경의 효과를 격리한다.

 

요점. LLM 응답 품질은 다소 주관적이므로, LLM-as-a-judge 기반 eval 또는 사람 피드백을 쓰는 것을 전제로 계획한다. 이 둘을 조합하면 LLM이 얼마나 잘 동작하는지 확신을 갖고 평가할 수 있다.

 

다음 글에서는 고정된 파이프라인을 넘어, LLM이 스스로 검색·판단·도구 사용을 조율하는 Agentic RAG를 다룬다.