RAG 얼마나 잘 돼요?

KAU-Notice-Hub에 RAG 기반 챗봇을 붙이면서 처음에는 직접 질문을 던져보며 동작을 확인했다.

“장학금 신청 기간 알려줘”, “수강신청 관련 공지 찾아줘”, “기숙사 모집 공지 있어?” 같은 질문을 입력해보고, 관련 공지를 기반으로 자연스럽게 답변이 나오면 어느 정도 잘 동작한다고 생각했다.

그때까지만 해도 평가 시스템을 깊게 고민하지는 않았다.
사용자 질문에 대해 관련 공지를 찾아오고, 답변이 어색하지 않게 생성되면 일단 괜찮은 방향으로 가고 있다고 느꼈다.

그런데 캡스톤 디자인 과목에서 진행한 회사방문이후 생각이 바뀌었다.

당시 서초 AI 챗봇을 구현하고 있는 회사 분과 대화할 기회가 있었다.
그 과정에서 제품을 만들 때는 “수치”가 중요하다는 것을 알게 되었다.

특히 인상 깊었던 말은 평가 지표가 없으면 “얼마나 잘 되나요?”라는 질문에 제대로 답할 수 없다는 것이었다.

평가 지표가 없다면 결국 이렇게 말할 수밖에 없다.

“아주 잘 됩니다.”
“꽤 잘돼요.”
“테스트해보니 괜찮았습니다.”

개발하는 입장에서는 실제로 여러 질문을 넣어봤고, 답변도 꽤 자연스럽게 나온다고 느낄 수 있다.
하지만 제품을 설명하거나 개선 방향을 잡아야 하는 상황에서는 이런 표현만으로는 부족하다.

잘 된다는 말이 어느 정도인지, 이전보다 얼마나 좋아졌는지, 어떤 부분이 아직 약한지 설명할 수 있어야 한다.
그리고 그 설명은 느낌이 아니라 수치와 지표를 기반으로 해야 한다.

이 대화를 통해 KAU-Notice-Hub도 단순히 RAG 챗봇을 구현하는 것에서 끝내면 안 된다는 것을 알게 되었다.
질문에 답변을 생성하는 기능뿐만 아니라, 그 답변이 얼마나 신뢰할 수 있는지 평가하고 개선할 수 있는 구조가 필요했다.

RAG는 왜 평가하기 어려울까?

RAG는 일반적인 LLM 답변 생성과 다르게 두 단계로 나뉜다.

첫 번째는 사용자의 질문과 관련된 문서를 검색하는 단계이고,
두 번째는 검색된 문서를 바탕으로 답변을 생성하는 단계다.

이 구조 때문에 답변이 이상하게 나왔을 때 원인을 단순히 하나로 말하기 어렵다.

1. 검색 단계에서 관련 공지를 찾지 못했을 수도 있다.
2. 관련 공지를 가져왔지만 중요한 정보를 포함한 문서를 놓쳤을 수도 있다.
3. 검색은 잘했지만 LLM이 문서에 없는 내용을 만들어냈을 수도 있다.
4. 답변은 근거가 있지만 사용자의 질문에 직접적으로 답하지 못했을 수도 있다.

예를 들어 사용자가 이렇게 물었다고 해보자.

“2026학년도 1학기 국가장학금 신청 기간 알려줘.”

RAG 시스템이 다음과 같이 답했다고 하자.

“2026학년도 1학기 국가장학금 신청은 12월 1일부터 12월 26일까지 진행됩니다.”

겉으로 보면 답변은 자연스럽다.
하지만 실제로 평가할 때는 더 자세히 봐야 한다.

검색된 문서에 실제로 저 기간이 있었는지, 다른 학기 공지를 잘못 가져온 것은 아닌지, 신청 대상이나 유의사항을 빠뜨리지는 않았는지, 문서에 없는 내용을 임의로 덧붙이지는 않았는지 확인해야 한다.

즉, RAG는 단순히 “답변이 자연스러운가?”만으로 평가하기 어렵다.
검색이 잘 되었는지, 답변이 질문에 맞는지, 답변이 문서에 근거하는지를 나눠서 봐야 한다.

KAU-Notice-Hub처럼 학교 공지를 기반으로 답변하는 서비스에서는 이 점이 특히 중요하다.
공지사항은 장학금, 수강신청, 졸업요건, 모집 기간처럼 사용자의 실제 행동에 영향을 주는 정보이기 때문이다.

직접 평가 프롬프트를 만들면 안 될까?

처음에는 LLM에게 직접 평가를 맡기는 방식도 생각했다.

질문, 검색된 문서, 생성된 답변을 함께 넣고 다음과 같이 요청하면 간단히 점수를 만들 수 있을 것 같았다.

“이 답변이 얼마나 좋은지 0점부터 1점 사이로 평가해줘.”

하지만 이 방식은 생각보다 애매했다.

내가 확인하고 싶은 것은 KAU-Notice-Hub의 RAG 성능이다.
그런데 평가 프롬프트를 직접 만들기 시작하면, 이제는 RAG 시스템뿐만 아니라 “내가 만든 평가 기준이 타당한가?”까지 함께 검증해야 한다.

예를 들어 어떤 답변에 0.8점이 나왔다고 해도 그 점수가 무엇을 의미하는지 알기 어렵다.

검색된 문서가 좋아서 높은 점수를 받은 것인지, 답변이 자연스러워서 높은 점수를 받은 것인지, 문서에 없는 내용을 말했는데도 표현이 그럴듯해서 높은 점수를 받은 것인지 구분하기 어렵다.

결국 나에게 필요한 것은 단순한 “LLM 채점 프롬프트”가 아니었다.
RAG 파이프라인을 검색과 생성 관점에서 나눠 평가할 수 있는 기준이 필요했다.

그래서 이미 RAG 평가를 목적으로 만들어진 라이브러리들을 찾아보기 시작했다.

어떤 평가 도구를 사용할 수 있을까?

RAG나 LLM 애플리케이션을 평가하기 위한 도구는 여러 가지가 있다.
대표적으로 DeepEval, TruLens, Phoenix, LangSmith, RAGAS 같은 도구들이 있다.

각 도구는 모두 LLM 애플리케이션 평가에 사용할 수 있지만, 목적과 강점이 조금씩 다르다.

DeepEval은 LLM 애플리케이션을 테스트하기 위한 프레임워크에 가깝다.
Pytest처럼 테스트 케이스를 작성하고 다양한 평가 지표를 적용할 수 있다는 점이 장점이다.
다만 지금 나에게 필요한 것은 전체 LLM 애플리케이션에 대한 범용 테스트보다 RAG 구조 자체를 검색과 생성으로 나눠 평가하는 것이었다.

TruLens는 context relevance, groundedness, answer relevance처럼 RAG의 핵심 요소를 평가할 수 있다.
RAG 평가에 잘 맞는 도구지만, tracing과 feedback function을 활용하는 관측 도구의 성격도 강하다.
나중에 운영 단계에서 RAG 파이프라인을 더 자세히 추적할 때는 유용할 수 있지만, 지금은 먼저 오프라인 평가 루프를 만드는 것이 우선이었다.

Phoenix도 LLM observability와 evaluation에 강점이 있다.
어떤 요청에서 어떤 검색 결과가 사용되었고 어떤 답변이 생성되었는지 관찰하는 데 유용하다.
하지만 현재 KAU-Notice-Hub는 운영 모니터링 시스템을 크게 붙이기보다, 검색 방식과 프롬프트 변경 전후를 비교할 수 있는 기준 지표가 먼저 필요했다.

LangSmith는 LangChain 생태계에서 실험 관리와 평가에 강력한 도구다.
하지만 현재 내가 원하는 것은 특정 플랫폼에 크게 의존하기보다, 질문, 검색된 context, 생성 답변, 기준 답변, 평가 점수를 DB에 저장하고 비교하는 구조였다.

여러 도구를 비교해보니 현재 KAU-Notice-Hub 단계에서는 RAGAS가 가장 적합하다고 판단했다.

왜 RAGAS인가?

RAGAS를 선택한 이유는 크게 세 가지다.

첫째, RAG 구조에 특화된 지표를 제공한다.
KAU-Notice-Hub에서 필요한 것은 단순한 답변 평가가 아니라 검색과 생성을 나눠서 보는 것이다.
RAGAS는 검색된 문서가 질문과 관련 있는지, 필요한 정보를 놓치지 않았는지, 답변이 질문에 맞는지, 답변이 문서에 근거하는지를 각각 평가할 수 있다.

둘째, 현재 프로젝트 단계에 적합하다.
지금은 대규모 운영 모니터링보다 실험과 개선이 더 중요하다.
키워드 검색, 벡터 검색, 하이브리드 검색, chunk 크기, top-k, 프롬프트 변경을 비교하면서 어떤 방식이 실제로 더 나은지 확인하고 싶다.
RAGAS는 이런 오프라인 평가에 적용하기 좋다.

셋째, DB 기반 평가 파이프라인과 잘 맞는다.
KAU-Notice-Hub에서는 사용자의 질문, 검색된 공지 chunk, 생성된 답변을 저장할 수 있다.
여기에 RAGAS 평가 점수를 함께 저장하면 이후 실험 결과를 비교할 수 있다.

즉, RAGAS는 단순히 “답변에 점수를 매기는 도구”라기보다, RAG 시스템의 어느 부분이 약한지 나눠서 볼 수 있게 해주는 도구에 가깝다.

RAGAS란?

RAGAS는 Retrieval Augmented Generation Assessment의 약자로, RAG 시스템을 평가하기 위한 프레임워크다.

쉽게 말하면 RAG 챗봇이 만든 답변에 대해 다음과 같은 질문을 던지는 도구라고 볼 수 있다.

검색된 문서가 질문과 관련 있었는가?
필요한 문서를 빠뜨리지 않았는가?
답변이 질문에 제대로 대답했는가?
답변이 검색된 문서에 근거하고 있는가?
문서에 없는 내용을 지어내지는 않았는가?

RAGAS에는 여러 지표가 있지만, KAU-Notice-Hub에 우선 적용하고 싶은 지표는 Context Precision, Response Relevancy, Faithfulness다.
(Context Recall은 답안을 직접 작성해야하기 때문에 우선은 보류하였다.)

RAGAS의 핵심 평가 지표

Context Precision

Context Precision은 검색된 문서들 중에서 질문과 관련 있는 문서가 얼마나 앞쪽에 잘 배치되었는지를 평가한다.

예를 들어 사용자가 “기숙사 추가 모집 공지 알려줘”라고 물었는데 검색 결과가 다음과 같다고 해보자.

동아리 모집 공지
항공대 축제 안내
기숙사 추가 모집 공지
등록금 납부 안내
도서관 운영 시간 안내

관련 문서가 있긴 하지만 상위에 있지 않다.
이 경우 검색 결과의 순위 품질이 좋다고 보기 어렵다.

Context Precision이 낮다면 검색 랭킹을 개선하거나, keyword 검색과 vector 검색을 섞는 hybrid search를 고려할 수 있다.

Context Recall

Context Recall은 답변에 필요한 정보를 검색 단계에서 얼마나 빠뜨리지 않고 가져왔는지를 평가한다.

예를 들어 사용자가 “교내 근로장학생 어떻게 신청해?”라고 물었다고 하자.

이 질문에 제대로 답하려면 신청 대상, 신청 기간, 신청 방법, 제출 서류 같은 정보가 필요하다.

그런데 검색 결과에 근로장학금 제도에 대한 일반 안내 문서만 포함되고, 실제 신청 기간이나 제출 방법이 적힌 공지 chunk를 가져오지 못했다면 답변은 불완전해질 수밖에 없다.

예를 들어 답변이 이렇게 나올 수 있다.

“교내 근로장학생은 학교 내 부서에서 근로하며 장학금을 지급받는 제도입니다.”

LLM이 아무리 좋아도 검색 단계에서 필요한 정보를 가져오지 못했기 때문에 제대로 답변하기 어렵다.

Context Recall이 낮다면 chunk 전략, 임베딩 모델, top-k 설정을 다시 확인해야 한다.

이는 검색 단계를 평가할 수 있는 중요한 지표이지만 초기 구현에서는 답안 생성이 필요하기 때문에 배제하게 되었다.

Response Relevancy

Response Relevancy는 생성된 답변이 사용자의 질문에 얼마나 잘 맞는지를 평가한다.

예를 들어 사용자가 “수강신청 정정기간 언제야?”라고 물었는데 답변이 다음과 같다면 어떨까?

“수강신청은 학기 시작 전 진행되며, 정정기간은 학기 시작 후 2~3주 이내입니다.”

틀린 말은 아닐 수 있지만, 사용자가 원한 것은 “정정 기간”이다.
답변이 너무 일반적이고 질문에 직접적으로 답하지 못하고 있다.

Response Relevancy가 낮다면 프롬프트나 답변 형식을 수정해야 한다.
예를 들어 기간을 물어본 질문에는 기간을 먼저 답하고, 대상이나 유의사항은 그 뒤에 덧붙이는 방식으로 개선할 수 있다.

Faithfulness

Faithfulness는 답변이 검색된 문서에 얼마나 충실한지를 평가한다.

RAG에서 가장 위험한 문제 중 하나는 hallucination이다.

즉, LLM이 문서에 없는 내용을 그럴듯하게 만들어내는 것이다.

예를 들어 검색된 공지에는 다음과 같이 적혀 있다고 하자.

“신청 기간: 3.4 ~ 3.8”

그런데 답변이 이렇게 나온다면 문제가 된다.

“신청은 3월 첫주 동안 진행됩니다, 신청은 대면으로 가능합니다.”

이런 답변은 자연스럽게 보여도 신뢰하기 어렵다.

KAU-Notice-Hub처럼 공지 기반 서비스에서는 자연스러운 답변보다 근거 있는 답변이 더 중요하다.
따라서 Faithfulness는 특히 중요하게 봐야 할 지표라고 생각한다.

KAU-Notice-Hub에 어떻게 적용할까?

KAU-Notice-Hub에서는 다음과 같은 평가 파이프라인을 생각하고 있다.

사용자가 질문한다.
검색기가 관련 공지를 가져온다.
LLM이 검색된 문서를 바탕으로 답변을 생성한다.
질문, 검색 결과, 답변을 DB에 저장한다.
RAGAS가 각 답변에 대해 평가 점수를 계산한다.
평가 결과를 DB에 저장한다.
검색 방식, top-k, prompt 변경 전후의 점수를 비교한다.

하나의 평가 데이터는 다음과 같은 형태로 저장할 수 있다.

{
  "user_input": "기숙사 추가 모집 기간 알려줘",
  "retrieved_contexts": [
    "2026학년도 1학기 생활관 추가 모집은 ...",
    "생활관비 납부 안내는 ..."
  ],
  "response": "기숙사 추가 모집은 2월 10일부터 2월 14일까지 진행됩니다.",
  "reference": "2026학년도 1학기 생활관 추가 모집 기간은 2월 10일부터 2월 14일까지입니다.",
  "ragas_scores": {
    "context_precision": 0.82,
    "response_relevancy": 0.91,
    "faithfulness": 0.88
  }
}

이렇게 저장하면 나중에 “이번 프롬프트가 더 좋아졌다”를 감으로 말하지 않아도 된다.

예를 들어 기존 프롬프트의 Faithfulness 평균이 0.72였고, 개선된 프롬프트의 Faithfulness 평균이 0.86이 되었다면 문서에 근거한 답변 생성 능력이 개선되었다고 설명할 수 있다.

검색 방식을 바꾼 뒤 Context Recall이 올라갔다면 기존보다 필요한 공지를 더 잘 찾게 되었다고 말할 수 있다.

즉, RAGAS를 도입하면 “꽤 잘 됩니다”가 아니라 “이 지표가 이만큼 개선되었습니다”라고 말할 수 있다.

RAGAS 점수가 전부는 아니다

물론 RAGAS를 도입한다고 해서 모든 평가 문제가 해결되는 것은 아니다.

RAGAS도 LLM 기반 평가를 활용하는 경우가 많기 때문에 평가 결과가 항상 절대적인 정답은 아니다.

또한 평가 점수가 높다고 해서 사용자 경험이 항상 좋은 것도 아니다.
답변이 정확하더라도 너무 길거나, 사용자가 원하는 정보를 한눈에 보기 어렵다면 서비스 품질은 떨어질 수 있다.

그래서 RAGAS는 최종 정답이라기보다 평가 루프를 만들기 위한 도구에 가깝다.

질문을 만들고, 답변을 생성하고, RAGAS로 평가하고, 낮은 지표를 분석한 뒤 검색기나 프롬프트를 개선한다.
이 반복이 쌓이면 RAG 시스템은 “그럴듯한 챗봇”에서 “근거 기반으로 개선되는 챗봇”이 된다.

정리

RAG를 처음 만들 때는 답변이 자연스럽게 나오는지만 보게 된다.
나도 처음에는 몇 가지 질문을 직접 넣어보고 답변이 괜찮으면 잘 동작한다고 생각했다.

하지만 캡스톤 디자인 회사 방문을 통해 제품을 설명하고 개선하려면 평가 지표가 필요하다는 것을 알게 되었다.
평가 지표가 없으면 “잘 됩니다”라고밖에 말할 수 없지만, 평가 지표가 있으면 “어떤 부분이 얼마나 좋아졌는지”를 설명할 수 있다.

여러 평가 도구를 비교해본 결과, 현재 KAU-Notice-Hub의 단계에서는 RAGAS가 가장 적합하다고 판단했다.

대규모 운영 관측보다 먼저 필요한 것은 검색 방식, chunk 전략, top-k, 프롬프트 변경 전후를 비교할 수 있는 평가 루프였기 때문이다.

결국 RAGAS를 도입한다는 것은 단순히 평가 라이브러리 하나를 추가하는 것이 아니다.

KAU-Notice-Hub의 RAG 시스템을 감으로 운영하지 않고, 데이터와 지표를 기반으로 개선하겠다는 의미에 가깝다.

context recall은 현재 도입이 되지 않았으나 이후 도입을 위해 사용자의 입력과 그 출력을 기록하는 방식을 DB에 저장하는 로직을 추가하였다. 이후 이 데이터를 활용하여 평가 데이터셋을 만들어볼 생각이다.

또한 앞으로는 질문, 검색 결과, 생성 답변, 평가 점수를 함께 저장하고 비교하면서 KAU-Notice-Hub의 RAG 성능을 개선해보려 한다.

다음 포스팅은 elastic search의 도입과 평가 관련 내용이 될 것 같다.

이상!

'고민의 흔적.. > KAU-Notice-Hub' 카테고리의 다른 글

웹, 모니터링 해볼게요(Analytics와 Speed Insights) (0)	2026.07.05
정말 배포하고 홍보해도 될까? (운영 리스크 점검) (0)	2026.06.28
RAG, 꼭 벡터로 해야돼?? (키워드 기반 RAG 구현에 대한 고찰) (0)	2026.05.29
안정적으로 인프라를 구축해보자! (0)	2026.05.23