[바미] Recall이 높아지면 사용자는 정말 만족할까?

들어가기 전에

RAG의 검색 성능을 개선하기 위해 새로운 Reranker를 적용했다고 가정해보겠습니다. 오프라인 평가 결과는 좋아졌습니다.

평가	항목적용 전	적용 후
Recall@5	0.78	0.85
NDCG@5	0.72	0.80
답변 정확도	0.74	0.77

 

 정답 문서가 상위 검색 결과에 더 자주 포함되었고, 중요한 문서의 순위도 높아졌습니다. 최종 답변 정확도 역시 조금 개선되었습니다.

이 정도 결과라면 새로운 설정을 운영 환경에 적용해도 될 것처럼 보입니다.

 

그런데 실제 사용자 반응은 예상과 달랐습니다.

 

사용자 행동	적용 전	적용 후
긍정 피드백 비율	72%	69%
재질문 비율	11%	15%
답변 후 업무 완료율	68%	65%
p95 응답 시간	3.2초	6.1초
요청당 평균 비용	12원	21원

 

검색 점수와 답변 정확도는 좋아졌는데 사용자는 오히려 더 자주 질문을 반복했고, 긍정적인 평가도 줄었습니다.

왜 이런 일이 발생했을까요?

 

새로운 Reranker가 더 많은 후보 문서를 꼼꼼하게 비교하면서 응답 시간이 길어졌을 수 있습니다. 검색된 문서가 많아지면서 답변이 지나치게 길어졌거나, 사용자가 원하는 핵심보다 부가 설명이 많아졌을 수도 있습니다.

 

오프라인 평가에서는 답변이 정확한지를 확인했지만, 사용자는 정확도만 보고 서비스를 평가하지 않습니다.

• 원하는 답을 빠르게 얻었는지
• 답변을 이해하기 쉬웠는지
• 다시 질문할 필요가 없었는지
• 실제 업무를 완료할 수 있었는지
• 출처를 신뢰할 수 있었는지
• 기다린 시간에 비해 답변이 유용했는지

이런 경험이 모두 만족도에 영향을 줍니다.

오프라인 점수가 높다는 것은 준비된 평가 데이터에서 잘 동작했다는 뜻이지, 실제 사용자가 더 만족했다는 뜻은 아닙니다.

 

이번 글에서는 운영 환경에서 RAG를 평가하는 Online Evaluation을 살펴보겠습니다.

클릭률, 재질문 비율, 답변 복사율과 사용자 피드백을 어떻게 해석해야 하는지 알아보고, A/B 테스트와 인터리빙 테스트로 두 RAG 설정을 비교하는 방법도 정리해보겠습니다.

오프라인 평가와 온라인 평가는 무엇이 다를까요?

오프라인 평가는 미리 준비한 평가 질문과 정답 데이터를 사용합니다. 예를 들어 다음과 같은 질문을 평가 데이터셋에 넣을 수 있습니다.

입사 1년 미만 직원은 연차가 어떻게 발생하나요?

 

정답 문서와 기대 답변을 미리 정해두고 다음 항목을 계산합니다.

• 정답 문서가 검색되었는지
• 정답 문서가 몇 위에 있었는지
• 답변이 기대 답변과 일치하는지
• 답변이 검색된 문서에 근거하는지

같은 질문을 반복해서 실행할 수 있으므로 여러 설정을 공정하게 비교하기 좋습니다. 하지만 실제 사용자는 평가 데이터와 다르게 질문할 수 있습니다.

• 오타를 포함해 질문할 수 있습니다.
• 필요한 조건을 생략할 수 있습니다.
• 여러 내용을 한 번에 물어볼 수 있습니다.
• 이전 대화를 이어서 짧게 질문할 수 있습니다.
• 문서에 없는 내용을 물어볼 수 있습니다.
• 답변을 읽지 않고 바로 다시 질문할 수 있습니다.
• 정확한 답을 받아도 너무 느리면 서비스를 포기할 수 있습니다.

온라인 평가는 실제 사용자가 RAG를 이용하면서 보인 행동을 바탕으로 품질을 확인합니다.

오프라인 평가	온라인 평가
준비된 질문을 사용함	실제 사용자의 질문을 사용함
정답 데이터와 자동 지표 중심	사용자 행동과 피드백 중심
같은 조건으로 반복하기 쉬움	실제 환경의 다양한 변수가 포함됨
배포 전 비교에 유리함	배포 후 만족도 확인에 유리함
실패 원인을 통제하기 쉬움	실제 사용 경험을 확인하기 쉬움

 

두 평가 방식은 서로 대체하지 않습니다. 오프라인 평가가 나쁜 설정을 배포 전에 걸러내는 역할을 한다면, 온라인 평가는 통과한 설정이 실제 서비스에서도 사용자에게 도움이 되는지 확인하는 역할을 합니다.

오프라인 평가는 “이 시스템이 정답을 잘 찾는가?”를 확인하고, 온라인 평가는 “사용자가 이 시스템으로 원하는 일을 잘 끝냈는가?”를 확인합니다.

사용자 만족은 하나의 숫자로 정의하기 어렵습니다

사용자가 만족했다는 것은 정확히 무엇을 의미할까요? 답변에 좋아요를 눌렀다면 만족했다고 볼 수 있습니다. 하지만 사용자는 만족해도 피드백 버튼을 누르지 않을 수 있습니다.

 

답변을 복사했다면 도움이 되었다고 볼 수도 있습니다. 반대로 잘못된 답을 동료에게 보여주기 위해 복사했을 수도 있습니다.

출처를 클릭했다면 답변을 신뢰하지 못했다는 뜻일 수 있지만, 중요한 내용을 원문에서 자세히 확인하려는 정상적인 행동일 수도 있습니다.

 

따라서 하나의 행동만으로 만족도를 판단하면 잘못된 결론을 내릴 수 있습니다. 사용자 만족은 여러 관점으로 나눠볼 수 있습니다.

답변 품질

• 질문에 정확하게 답했는가
• 필요한 내용을 빠뜨리지 않았는가
• 제공된 문서에 근거했는가
• 문서에 없는 내용을 만들지 않았는가

사용 편의성

• 답변을 이해하기 쉬운가
• 답변이 지나치게 길지 않은가
• 원하는 형식으로 제공되었는가
• 중요한 내용이 잘 보이는가

업무 완료

• 답변을 이용해 실제 업무를 마쳤는가
• 다른 검색이나 상담이 추가로 필요하지 않았는가
• 같은 질문을 반복하지 않았는가

속도와 비용

• 사용자가 기다릴 만한 시간 안에 답했는가
• 서비스 운영 비용이 감당 가능한가
• 느린 요청이 일부 사용자에게 집중되지 않는가

신뢰

• 출처가 명확하게 표시되었는가
• 최신 문서를 사용했는가
• 확인할 수 없는 내용은 솔직하게 말했는가
• 틀린 답을 확신에 차서 말하지 않았는가

서비스마다 중요하게 보는 만족의 기준도 다릅니다.

 

사내 규정 RAG라면 정확성과 최신성이 가장 중요할 수 있습니다. 쇼핑 상담 RAG라면 사용자가 적절한 상품을 찾았는지와 구매까지 이어졌는지가 중요할 수 있습니다. 개발 문서 RAG라면 답변을 복사해 코드에 적용했는지, 같은 오류를 다시 질문하지 않았는지가 중요할 수 있습니다.

온라인 평가를 시작하기 전에 먼저 “사용자가 이 RAG를 이용해 무엇을 완료해야 하는가?”를 정의해야 합니다.

직접 피드백과 행동 신호를 구분해야 합니다

온라인 평가에 사용하는 정보는 크게 직접 피드백과 행동 신호로 나눌 수 있습니다. 직접 피드백은 사용자가 자신의 평가를 명시적으로 표현한 것입니다.

• 좋아요와 싫어요
• 별점
• 만족도 설문
• 답변 오류 신고
• 텍스트 의견
• 더 나은 답변 제안

행동 신호는 사용자가 서비스에서 실제로 한 행동입니다.

• 같은 질문을 다시 입력함
• 표현을 바꿔 재질문함
• 출처 문서를 클릭함
• 답변을 복사함
• 상담원 연결을 요청함
• 답변을 받은 뒤 바로 이탈함
• 답변 이후 특정 기능을 실행함
• 업무 완료 버튼을 누름

직접 피드백은 사용자의 의도를 비교적 명확하게 알 수 있지만 참여율이 낮을 수 있습니다. 행동 신호는 대부분의 요청에서 자동으로 수집할 수 있지만, 행동의 이유를 정확히 알기 어렵습니다.

 

예를 들어 사용자가 답변을 받은 뒤 바로 화면을 닫았습니다. 이 행동은 두 가지로 해석할 수 있습니다. 

• 원하는 답을 바로 얻었기 때문에 종료함
• 답변이 마음에 들지 않아 서비스를 포기함

행동만으로는 두 경우를 구분하기 어렵습니다. 따라서 직접 피드백과 행동 신호를 함께 보는 것이 좋습니다.

좋아요와 싫어요

가장 쉽게 추가할 수 있는 온라인 평가 방식은 답변 아래에 좋아요와 싫어요 버튼을 두는 것입니다.

사용자가 싫어요를 눌렀다면 이유도 선택할 수 있게 만들 수 있습니다.

• 답변이 틀렸어요.
• 질문과 관련 없는 답변이에요.
• 필요한 내용이 빠졌어요.
• 답변이 너무 길어요.
• 답변이 이해하기 어려워요.
• 오래된 정보를 사용했어요.
• 출처가 잘못되었어요.
• 답변이 너무 느렸어요.

단순히 싫어요만 저장하는 것보다 이유를 함께 받으면 개선할 지점을 찾기 쉽습니다. 예를 들어 부정 피드백 중 답변이 틀렸어요가 많다면 정확도 문제를 살펴봐야 합니다. 답변이 너무 길어요가 많다면 검색보다 프롬프트와 답변 형식이 문제일 수 있습니다.

 

좋아요 비율은 다음처럼 계산할 수 있습니다.

• 긍정 피드백 비율 = 좋아요 수 ÷ 전체 피드백 수
• 부정 피드백 비율 = 싫어요 수 ÷ 전체 피드백 수

이때 전체 답변 수가 아니라 피드백을 남긴 답변 수를 기준으로 한다는 점에 주의해야 합니다. 답변 10,000개 중 100개에만 피드백이 달렸고, 그중 80개가 좋아요라면 긍정 피드백 비율은 80%입니다. 하지만 전체 사용자의 80%가 만족했다고 말할 수는 없습니다.

피드백 참여율도 함께 봐야 합니다.

• 피드백 참여율 = 피드백이 등록된 답변 수 ÷ 전체 답변 수

다음과 같은 결과가 나올 수 있습니다.

 

항목	값
전체 답변	10,000개
피드백 등록	100개
좋아요	80개
싫어요	20개
긍정 피드백 비율	80%
피드백 참여율	1%

 

긍정 피드백 비율은 높지만 전체 사용자 중 피드백을 남긴 사람은 1%뿐입니다.

사용자 피드백은 중요한 신호지만, 피드백을 남긴 사용자가 전체 사용자를 대표한다고 가정하면 안 됩니다.

 

불만이 있는 사용자가 피드백을 더 자주 남길 수도 있고, 매우 만족한 사용자만 좋아요를 누를 수도 있습니다.

재질문 비율

RAG의 답변이 충분하지 않으면 사용자는 같은 내용을 다시 질문할 수 있습니다.

예를 들어 다음과 같은 대화가 이어질 수 있습니다.

사용자:

입사 1년 미만 직원의 연차 기준을 알려줘.

RAG:

1개월 개근 시 연차가 발생합니다.

사용자:

그래서 한 달에 며칠 생기는 건데?

첫 답변에 발생 일수가 빠졌기 때문에 사용자가 다시 물었습니다. 재질문 비율은 답변이 사용자의 정보 요구를 한 번에 해결했는지 확인하는 데 도움이 됩니다.

 

다만 무엇을 재질문으로 볼지 기준을 정해야 합니다.

• 일정 시간 안에 같은 질문을 다시 입력함
• 의미가 매우 비슷한 질문을 다시 입력함
• 이전 답변에 포함된 내용을 다시 요청함
• 다시, 정확히, 아니, 그게 아니라와 같은 표현이 포함됨

다음 두 질문은 문장이 다르지만 같은 의도를 가질 수 있습니다.

• 환불 처리 기간은 얼마나 걸리나요?
• 환불받으려면 며칠 기다려야 해요?

문장만 완전히 일치하는지 확인하면 재질문으로 잡히지 않습니다. 임베딩 유사도나 LLM 분류를 사용해 의미가 같은지 판단할 수 있습니다. 하지만 모든 후속 질문이 실패를 의미하는 것은 아닙니다.

 

사용자가 첫 답을 이해한 뒤 더 자세한 내용을 묻는 정상적인 대화일 수도 있습니다. 

 

예를 들어 다음 질문은 자연스러운 확장입니다.

• 첫 질문: 연차는 어떻게 발생하나요?
• 후속 질문: 사용하지 않은 연차는 어떻게 처리되나요?

따라서 후속 질문을 다음처럼 나누는 것이 좋습니다.

• 같은 내용의 반복
• 잘못된 답변에 대한 수정 요청
• 부족한 답변에 대한 보완 요청
• 새로운 주제로 확장한 질문

재질문이 많다는 사실보다 왜 다시 질문했는지를 구분하는 것이 더 중요합니다.

답변 복사율

사용자가 답변을 복사했다면 실제 업무에 활용했을 가능성이 있습니다.

개발자를 위한 RAG라면 생성된 코드를 복사할 수 있습니다. 사내 업무 RAG라면 보고서나 메일에 넣기 위해 답변을 복사할 수 있습니다.

 

답변 복사율은 다음처럼 계산할 수 있습니다.

• 답변 복사율 = 복사 이벤트가 발생한 답변 수 ÷ 전체 답변 수

복사한 범위도 함께 확인할 수 있습니다.

• 답변 전체 복사
• 코드 블록만 복사
• 특정 문단만 복사
• 출처 링크 복사

하지만 복사는 항상 긍정적인 행동은 아닙니다.

• 잘못된 답을 신고하기 위해 복사했을 수 있습니다.
• 동료에게 검토를 요청하기 위해 복사했을 수 있습니다.
• 다른 AI 서비스에 다시 물어보기 위해 복사했을 수 있습니다.

따라서 복사율이 증가했다고 바로 만족도가 높아졌다고 결론 내리기보다 다른 신호와 함께 봐야 합니다.

복사 이후에 업무 완료 이벤트가 발생하거나 긍정 피드백이 이어졌다면 활용 가능성이 더 높다고 볼 수 있습니다.

출처 클릭률

RAG 답변에 출처를 표시한다면 사용자가 어떤 문서를 클릭했는지 확인할 수 있습니다.

출처 클릭은 여러 의미를 가질 수 있습니다.

• 답변을 더 자세히 확인하고 싶음
• 중요한 내용이라 원문 검토가 필요함
• 답변을 신뢰하지 못해 직접 확인함
• 출처 문서에서 다음 업무를 진행하려고 함

따라서 클릭률이 높다고 무조건 좋은 것도 아니고, 낮다고 무조건 나쁜 것도 아닙니다.

짧은 사실 질문에서는 답변만으로 충분해 출처를 클릭하지 않을 수 있습니다.

 

반대로 계약, 법률, 결제와 같이 중요한 질문에서는 정확한 답을 받았더라도 원문을 확인할 가능성이 높습니다.

출처 클릭은 질문 유형과 함께 분석하는 것이 좋습니다.

 

질문 유형출처	클릭의 가능한 의미
단순 사실	답변의 신뢰 확인
업무 절차	원문에서 세부 절차 확인
법률·정책	적용 범위와 원문 검토
기술 문서	전체 예제와 관련 코드 확인
답이 모호한 질문	답변이 부족해 원문 탐색

 

클릭한 문서가 실제 답변 근거로 사용된 문서인지도 확인해야 합니다. 답변에는 문서 A를 근거로 표시했지만 사용자가 문서 B를 계속 클릭한다면, 문서 A만으로는 충분하지 않을 수 있습니다.

답변 후 이탈률

사용자가 답변을 받은 뒤 아무 행동도 하지 않고 서비스를 종료했다면 이를 이탈로 기록할 수 있습니다.

하지만 이탈은 해석하기 특히 어려운 지표입니다.

 

답을 얻었기 때문에 더 할 일이 없어 종료했을 수도 있고, 답변이 불만족스러워 포기했을 수도 있습니다.

검색 서비스에서는 결과를 클릭하지 않고 종료한 행동이 반드시 실패를 의미하지 않습니다. 검색 화면 자체에서 필요한 정보를 얻었다면 클릭할 필요가 없기 때문입니다.

 

RAG도 마찬가지입니다. 답변 하나로 문제가 해결되었다면 후속 행동이 없는 것이 성공일 수 있습니다.

따라서 단순 이탈률보다 다음 신호를 함께 살펴보는 것이 좋습니다.

• 답변을 읽은 시간
• 답변 영역을 끝까지 확인했는지
• 복사 또는 출처 클릭이 있었는지
• 같은 질문을 다른 곳에서 다시 했는지
• 업무 완료 이벤트가 발생했는지
• 부정 피드백이 있었는지

행동이 없다는 사실만으로 만족과 불만족을 구분할 수는 없습니다.

업무 완료율

온라인 평가에서 가장 좋은 지표는 RAG를 사용한 뒤 사용자가 실제 목표를 완료했는지 확인하는 것입니다.

예를 들어 고객지원 RAG의 목표가 반품 신청을 돕는 것이라면 최종적으로 반품 신청이 완료되었는지를 확인할 수 있습니다.

• 반품 신청 완료
• 비밀번호 재설정 완료
• 예약 완료
• 문서 제출 완료
• 오류 해결 완료
• 상담 티켓 종료
• 상품 구매 완료

이를 업무 완료율 또는 Task Completion Rate로 정의할 수 있습니다.

• 업무 완료율 = 목표 행동을 완료한 세션 수 ÷ 해당 업무를 시도한 세션 수

답변에 좋아요를 누르지 않았더라도 반품 신청을 문제없이 완료했다면 RAG가 실제 목적을 달성했다고 볼 수 있습니다.

반대로 좋아요를 눌렀지만 사용자가 끝내 신청을 완료하지 못했다면 설명은 마음에 들었어도 업무에는 충분하지 않았을 수 있습니다.

업무 완료 이벤트를 만들기 어려운 서비스도 있습니다.

 

사내 지식 검색처럼 사용자가 답변을 읽은 뒤 외부 업무를 수행한다면 시스템 안에서 완료 여부를 알 수 없습니다. 이때는 다음과 같은 대체 신호를 사용할 수 있습니다.

• 사용자가 직접 누르는 해결됨 버튼
• 일정 시간 안에 같은 질문이 반복되지 않음
• 상담원 연결 없이 세션이 종료됨
• 답변을 복사하거나 관련 문서를 열어봄
• 짧은 만족도 설문에 완료 여부를 질문함

상담원 연결과 답변 포기

고객지원 서비스에서는 RAG 답변 이후 사람이 처리하는 상담으로 전환되었는지 확인할 수 있습니다.

• 상담원 연결률
• 상담 티켓 생성률
• RAG 답변 후 사람에게 다시 문의한 비율
• 같은 문제로 다시 문의한 비율

상담원 연결률이 높다면 RAG가 문제를 해결하지 못했을 가능성이 있습니다.

하지만 모든 상담원 연결이 실패는 아닙니다.

• 계정 본인 확인이 필요한 업무
• 환불 최종 승인
• 법적 분쟁
• 예외 처리가 필요한 주문
• 사람의 판단이 필요한 상담

이런 업무는 처음부터 상담원 연결이 올바른 결과일 수 있습니다.

따라서 상담원 연결 자체보다 연결 이유를 구분해야 합니다.

• RAG가 답을 찾지 못함
• 사용자가 답을 신뢰하지 않음
• 시스템상 사람이 처리해야 함
• 사용자가 사람과 대화하는 것을 선호함
• 답변 내용이 잘못됨

응답 시간은 품질 지표입니다

RAG의 답변이 정확하더라도 지나치게 느리면 사용자는 만족하지 않을 수 있습니다.

응답 시간은 단순한 서버 성능 지표가 아니라 사용자 경험과 연결된 품질 지표입니다.

다음 값을 함께 확인하는 것이 좋습니다.

• 전체 응답 시간
• 첫 글자가 표시되기까지 걸린 시간
• 검색 시간
• Reranking 시간
• LLM 생성 시간
• 평균 응답 시간
• p95 응답 시간
• p99 응답 시간
• 타임아웃 비율

스트리밍 답변이라면 전체 답변이 끝나는 시간뿐 아니라 첫 토큰이 도착하는 시간도 중요합니다.

사용자가 1초 안에 답변이 시작되는 것을 보면 전체 생성에 시간이 조금 더 걸려도 덜 답답하게 느낄 수 있습니다.

반대로 8초 동안 아무 표시도 없다가 한 번에 답변이 나타나면 서비스가 멈췄다고 생각할 수 있습니다.

온라인 실험에서는 정확도와 함께 속도 지표를 반드시 확인해야 합니다.

주요 온라인 지표를 정리해보겠습니다

 

지표	확인하는 내용	해석할 때 주의할 점
긍정 피드백 비율	피드백 중 좋아요 비율	피드백 참여자가 전체 사용자를 대표하지 않을 수 있음
피드백 참여율	전체 답변 중 피드백 등록 비율	낮으면 긍정 비율만으로 일반화하기 어려움
재질문 비율	같은 요구를 다시 질문한 비율	자연스러운 후속 질문과 구분해야 함
답변 복사율	답변이 복사된 비율	검토나 신고 목적으로 복사할 수도 있음
출처 클릭률	출처 문서를 클릭한 비율	신뢰 확인인지 불만족인지 구분하기 어려움
업무 완료율	목표 행동을 완료한 비율	서비스 안에서 완료 여부를 측정할 수 있어야 함
상담원 전환율	사람의 도움으로 넘어간 비율	원래 사람이 처리해야 하는 업무일 수 있음
답변 보류율	답할 수 없다고 응답한 비율	너무 높으면 실제 답이 있는 질문도 회피할 수 있음
이탈률	답변 후 추가 행동 없이 종료한 비율	답을 얻고 정상 종료한 경우도 포함됨
응답 시간	사용자가 답을 받기까지 걸린 시간	평균뿐 아니라 느린 구간도 확인해야 함
요청당 비용	한 질문을 처리하는 평균 비용	품질 개선 폭과 함께 판단해야 함

 

어떤 지표도 단독으로 사용하면 잘못 해석할 가능성이 있습니다. 서비스의 목표와 질문 유형에 맞는 여러 지표를 조합해야 합니다.

이벤트를 먼저 정의해야 합니다

온라인 지표를 계산하려면 사용자의 행동을 이벤트로 기록해야 합니다.

예를 들어 다음 이벤트가 필요할 수 있습니다.

• answer_shown: 답변이 사용자에게 표시됨
• feedback_positive: 좋아요 선택
• feedback_negative: 싫어요 선택
• answer_copied: 답변 복사
• source_clicked: 출처 클릭
• question_reasked: 같은 의도의 재질문
• task_completed: 목표 업무 완료
• human_escalated: 상담원 연결
• session_abandoned: 세션 중단
• response_timeout: 답변 시간 초과

각 이벤트에는 어떤 답변에서 발생했는지 연결할 수 있는 식별자가 필요합니다. 이전 글에서 살펴본 Trace ID를 활용할 수 있습니다.

{
  "event_id": "event-20260726-00142",
  "event_name": "feedback_negative",
  "trace_id": "4b0cb4c94dfe43f896e1b19088223a11",
  "session_id": "session-82391",
  "user_id": "user-anonymous-184",
  "experiment_id": "reranker-exp-2026-07",
  "variant": "treatment",
  "reason": "answer_too_slow",
  "created_at": "2026-07-26T14:31:20+09:00"
}

이렇게 저장하면 부정 피드백이 남겨진 요청의 검색 결과, Reranking 순위와 최종 Context를 다시 확인할 수 있습니다.

온라인 평가와 Observability가 연결되는 지점입니다.

사용자 식별 정보는 최소한으로 저장해야 합니다

온라인 평가에서는 사용자와 세션을 연결해야 하는 경우가 많습니다. 하지만 이름, 이메일과 전화번호를 그대로 저장할 필요는 없습니다.

• 익명화된 사용자 ID
• 임의로 생성한 세션 ID
• Trace ID
• 실험 그룹
• 질문 유형
• 사용자 언어와 기기 유형

평가에 필요한 최소한의 정보만 저장하는 것이 좋습니다. 질문과 답변 자체에 개인정보가 포함될 수 있으므로 마스킹, 접근 권한과 보관 기간도 정해야 합니다.

사용자 행동을 더 자세히 수집할수록 평가에는 유리하지만, 개인정보 보호에 대한 책임도 함께 커집니다.

하나의 핵심 지표를 정해야 합니다

온라인 평가를 시작하면 수많은 지표를 수집할 수 있습니다.

• 좋아요
• 싫어요
• 재질문
• 복사
• 출처 클릭
• 이탈
• 상담원 연결
• 업무 완료
• 응답 시간
• 비용

모든 지표가 조금씩 다르게 움직이면 어떤 설정이 더 좋은지 판단하기 어려워집니다.

그래서 실험을 시작하기 전에 핵심 지표를 하나 정하는 것이 좋습니다.

이를 Primary Metric이라고 부를 수 있습니다.

예를 들어 사내 업무 RAG의 목표가 직원의 문의 해결이라면 다음 지표를 핵심으로 정할 수 있습니다.

답변 후 10분 안에 같은 의도의 재질문이나 상담원 연결 없이 세션이 종료된 비율

 

쇼핑 안내 RAG라면 상품 상세 페이지 이동이나 구매 완료율을 핵심 지표로 정할 수 있습니다. 고객지원 RAG라면 문제 해결률이나 상담원 전환율을 사용할 수 있습니다.

 

핵심 지표는 서비스가 제공하려는 가치와 직접 연결되어야 합니다.

함께 지켜야 할 보호 지표가 필요합니다

핵심 지표가 좋아져도 다른 중요한 품질이 크게 나빠질 수 있습니다. 이를 막기 위해 Guardrail Metric을 함께 정합니다.

 

예를 들어 업무 완료율을 핵심 지표로 선택했다면 다음 항목을 보호 지표로 둘 수 있습니다.

• 부정 피드백 비율
• 근거 없는 답변 비율
• p95 응답 시간
• 답변당 비용
• 개인정보 노출 사고
• 상담원 전환율
• 답변 보류율

새로운 설정에서 업무 완료율은 높아졌지만 근거 없는 답변이 크게 증가했다면 배포하면 안 됩니다.

답변을 자신 있게 단정할수록 사용자가 빠르게 행동해 업무 완료율이 일시적으로 높아질 수 있기 때문입니다.

온라인 실험은 하나의 숫자를 최대화하는 과정이 아니라, 중요한 품질을 해치지 않으면서 사용자 목표를 더 잘 달성하는 설정을 찾는 과정입니다.

A/B 테스트란 무엇일까요?

A/B 테스트는 사용자를 두 개 이상의 그룹으로 나누고 서로 다른 환경을 제공한 뒤 결과를 비교하는 방법입니다.

기존 설정을 A, 새 설정을 B라고 하겠습니다.

A 그룹

• 기존 임베딩 모델
• 기존 Reranker
• 후보 문서 20개
• 현재 운영 프롬프트

B 그룹

• 기존 임베딩 모델
• 새로운 Reranker
• 후보 문서 20개
• 현재 운영 프롬프트

두 그룹에서 달라지는 것은 Reranker뿐입니다. 사용자는 무작위로 A 또는 B 그룹에 배정됩니다.

일정 기간 동안 다음 항목을 비교합니다.

• 업무 완료율
• 재질문 비율
• 긍정·부정 피드백
• 응답 시간
• 요청당 비용
• 검색과 답변 품질

A/B 테스트를 사용하는 이유는 시간이나 사용자 구성과 같은 다른 요인의 영향을 줄이기 위해서입니다.

월요일에는 A를 운영하고 다음 월요일에는 B를 운영한다면 두 주의 사용자와 업무량, 문서 상태가 달라질 수 있습니다.

같은 기간에 사용자를 무작위로 나누면 외부 조건이 두 그룹에 비슷하게 섞일 가능성이 높아집니다.

실험 가설부터 작성해야 합니다

A/B 테스트는 단순히 두 설정을 켜고 점수를 비교하는 작업이 아닙니다.

먼저 무엇을 기대하는지 가설을 작성해야 합니다.

예를 들면 다음과 같습니다.

새로운 Reranker를 적용하면 정답 근거가 최종 Context에 더 자주 포함되어 업무 완료율이 높아질 것이다. 다만 Reranking 처리 시간이 늘어날 수 있으므로 p95 응답 시간이 1초 이상 증가하지 않는지도 함께 확인한다.

이 가설에는 세 가지가 포함되어 있습니다.

• 무엇을 변경하는가
• 어떤 효과를 기대하는가
• 어떤 부작용을 확인하는가

실험을 시작하기 전에 다음 내용을 정리합니다.

• 변경할 설정
• 기존 설정
• 핵심 지표
• 보호 지표
• 예상하는 변화
• 사용자 배정 방식
• 실험 대상
• 최소 표본 수
• 실험 종료 기준
• 중단해야 하는 위험 기준

사용자를 무작위로 나눠야 합니다

사용자가 직접 새 버전을 선택하게 하면 두 그룹의 특성이 달라질 수 있습니다.

새로운 기능에 관심이 많은 사용자는 B를 더 많이 선택할 수 있습니다. 이 사용자들은 원래부터 서비스를 자주 사용하거나 적극적으로 피드백을 남길 가능성이 있습니다.

 

따라서 시스템이 사용자를 무작위로 배정하는 것이 좋습니다. 같은 사용자는 실험 기간 동안 가능한 한 같은 그룹을 유지해야 합니다.

오늘은 A를 보고 내일은 B를 보면 사용자가 두 경험을 섞어서 사용하게 됩니다. 이전 대화가 이어지는 RAG에서는 특히 문제가 됩니다.

사용자 ID를 기준으로 일정하게 그룹을 배정할 수 있습니다.

• 사용자 A → 항상 기존 설정
• 사용자 B → 항상 새로운 설정
• 사용자 C → 항상 기존 설정

로그인하지 않은 사용자라면 익명 ID나 브라우저 식별값을 사용할 수 있지만 쿠키 삭제와 기기 변경으로 그룹이 바뀔 수 있다는 점을 고려해야 합니다.

실험에 노출된 시점을 기록해야 합니다

사용자가 B 그룹에 배정되었다고 해서 실제로 B 기능을 사용한 것은 아닐 수 있습니다. RAG 화면에 들어오지 않았거나 질문을 보내지 않았을 수 있습니다.

 

따라서 그룹 배정 이벤트와 실제 노출 이벤트를 구분하는 것이 좋습니다.

• experiment_assigned: 실험 그룹이 정해짐
• experiment_exposed: 실제로 해당 설정으로 답변을 받음

온라인 지표는 실제 노출된 사용자를 기준으로 계산해야 하는 경우가 많습니다.

한 번에 하나만 바꿔야 합니다

새 Reranker를 적용하면서 청크 크기, 프롬프트와 LLM까지 함께 변경하면 결과의 원인을 알 수 없습니다.

B 그룹의 업무 완료율이 높아졌더라도 어떤 변경이 효과를 냈는지 알 수 없죠. A/B 테스트에서도 앞에서 다룬 Ablation Study와 같은 원칙이 필요합니다.

• Reranker만 변경
• 프롬프트만 변경
• Context 문서 수만 변경
• 답변 형식만 변경

한 번에 하나의 핵심 요소를 바꾸는 것이 결과를 해석하기 쉽습니다. 여러 변경을 묶어서 출시해야 한다면 전체 묶음을 하나의 제품 변화로 평가할 수는 있지만, 어떤 요소가 효과를 냈는지는 별도의 실험이 필요합니다.

실험 결과를 살펴보겠습니다

새로운 Reranker를 적용한 가상의 A/B 테스트 결과입니다.

평가 항목A	기존 설정B	새 Reranker
사용자 수	5,020명	5,008명
요청 수	18,420건	18,311건
업무 완료율	68.2%	66.5%
긍정 피드백 비율	72.1%	69.4%
재질문 비율	11.3%	15.1%
출처 클릭률	19.8%	24.2%
p95 응답 시간	3.2초	6.1초
요청당 평균 비용	12원	21원
오프라인 Recall@5	0.78	0.85

 

B는 오프라인 Recall@5가 크게 높아졌지만 온라인 지표는 나빠졌습니다. 출처 클릭률은 증가했지만 이를 긍정적으로만 해석하기는 어렵습니다. 사용자가 더 좋은 문서를 확인하려고 클릭했을 수도 있지만 답변을 신뢰하지 못해 원문을 자주 열어봤을 수도 있습니다.

 

Trace를 확인해보니 다음과 같은 변화가 있었을 수 있습니다.

• 후보 문서 수가 늘면서 Reranking 시간이 길어짐
• 최종 Context에 비슷한 문서가 여러 개 포함됨
• 답변 길이가 평균 40% 증가함
• 오래된 문서와 최신 문서가 함께 전달됨
• 사용자가 핵심 답을 찾기 위해 출처를 더 자주 확인함

이 결과에서는 새로운 Reranker를 그대로 전체 배포하기 어렵습니다. 그렇다고 새 Reranker가 무조건 나쁘다는 뜻도 아닙니다.

후보 문서 수를 줄이거나 중복 제거를 개선하면 검색 품질을 유지하면서 응답 시간을 낮출 수 있습니다. 질문 유형에 따라 선택적으로 Reranker를 적용할 수도 있습니다. 온라인 평가 결과는 다음 실험으로 이어집니다.

평균만 보지 말고 사용자와 질문을 나눠봐야 합니다

전체 사용자 평균에서는 B가 나빠 보이지만 일부 질문에서는 큰 개선이 있었을 수 있습니다.

 

질문 유형A	업무 완료율B	업무 완료율
단순 사실	82%	80%
조건·예외	61%	70%
비교 질문	54%	63%
짧은 FAQ	88%	82%
여러 문서 질문	46%	57%

  

새 Reranker는 조건과 비교 질문에서는 효과가 있었지만 단순한 질문에서는 속도만 느리게 만들었습니다.

이 경우 모든 질문에 Reranker를 적용하는 대신 복잡한 질문에만 적용하는 방식을 검토할 수 있습니다.

다음 기준으로 나눠서 분석하면 좋습니다.

• 질문 유형
• 질문 길이
• 필요한 문서 수
• 사용자 언어
• 신규 사용자와 기존 사용자
• 모바일과 데스크톱
• 무료 사용자와 유료 사용자
• 업무 중요도
• 문서 종류
• 모델과 프롬프트 버전

전체 평균만 보면 특정 사용자에게만 발생하는 문제를 놓칠 수 있습니다.

결과가 조금 다르다고 바로 결론 내리면 안 됩니다

A 그룹의 업무 완료율이 68.2%이고 B 그룹이 68.5%라면 B가 더 좋아 보입니다.

하지만 사용자 수가 적다면 우연히 발생한 차이일 수 있습니다.

온라인 실험에서는 표본 수와 결과의 불확실성을 함께 봐야 합니다.

통계에서 자주 사용하는 개념이 신뢰구간과 p-value입니다.

초보자 입장에서는 다음 정도로 이해하면 됩니다.

• 관찰된 차이가 실제 차이인지 우연한 흔들림인지 확인합니다.
• 사용자 수가 적을수록 결과가 크게 흔들릴 수 있습니다.
• 차이가 작을수록 더 많은 데이터가 필요합니다.
• 하나의 숫자보다 가능한 범위를 함께 보는 것이 좋습니다.

예를 들어 B의 업무 완료율이 A보다 0.3% 높지만 신뢰구간이 넓다면 실제로는 더 나쁠 가능성도 있습니다.

 

반대로 5% 차이가 반복적으로 나타나고 신뢰구간도 겹치지 않는다면 실제 차이일 가능성이 커집니다. 실험을 시작하기 전에 최소 표본 수와 종료 기준을 정하는 것이 좋습니다.

결과를 매일 확인하고 유리할 때 멈추면 안 됩니다

실험 첫날에는 B가 좋아 보이고, 둘째 날에는 A가 좋아 보일 수 있습니다.

매일 결과를 확인하다가 B가 유리해진 순간 실험을 중단하면 우연한 변화를 실제 효과로 착각할 가능성이 높아집니다.

 

실험 전에 다음을 정해야 합니다.

• 최소 사용자 수
• 최소 실험 기간
• 종료 시점
• 핵심 지표
• 통계 판단 기준
• 위험 발생 시 조기 중단 조건

평일과 주말의 사용 패턴이 다르다면 둘 다 포함해야 합니다.

급여, 정산과 월말 업무처럼 특정 시기에 질문이 몰리는 서비스라면 업무 주기도 고려해야 합니다.

여러 지표 중 좋은 것만 선택하면 안 됩니다

B 설정에서 다음 결과가 나왔다고 가정해보겠습니다.

• 복사율 증가
• 출처 클릭률 증가
• 긍정 피드백 감소
• 재질문 증가
• 응답 시간 증가

이 중 복사율과 클릭률만 보고 성공이라고 결론 내리면 안 됩니다. 실험 전에 핵심 지표와 보호 지표를 정하지 않으면 결과가 나온 뒤 유리한 숫자만 선택하게 될 수 있습니다.

 

이를 막기 위해 실험 계획을 미리 문서화하는 것이 좋습니다.

새 기능이 신기해서 반응이 달라질 수 있습니다

새로운 답변 UI나 출처 표시 방식을 적용하면 사용자가 처음에는 호기심 때문에 더 많이 클릭할 수 있습니다.

이를 실제 품질 개선으로 착각할 수 있습니다.

 

시간이 지나 익숙해지면 클릭률이 다시 낮아질 수도 있습니다. 반대로 기존 사용자는 익숙한 화면이 바뀌어 처음에 불편함을 느낄 수 있습니다. 따라서 단기 결과와 장기 결과를 구분해야 합니다.

• 실험 초기
• 사용자가 적응한 이후
• 반복 사용자
• 처음 방문한 사용자

장기적인 만족과 재사용률도 중요합니다.

인터리빙 테스트란 무엇일까요?

A/B 테스트에서는 A 그룹이 검색 방식 A의 결과를 보고, B 그룹이 검색 방식 B의 결과를 봅니다. 인터리빙 테스트에서는 두 검색 방식의 결과를 하나의 목록으로 섞어서 같은 사용자에게 보여줍니다.

 

검색 방식 A의 결과가 다음과 같다고 하겠습니다.

• 문서 A
• 문서 B
• 문서 C

검색 방식 B의 결과는 다음과 같습니다.

• 문서 B
• 문서 D
• 문서 A

인터리빙은 두 목록에서 문서를 번갈아 선택해 하나의 결과를 만듭니다.

• 문서 A: 검색 방식 A
• 문서 B: 검색 방식 B
• 문서 D: 검색 방식 B
• 문서 C: 검색 방식 A

중복 문서는 한 번만 표시하고, 사용자가 어떤 문서를 클릭했는지에 따라 어느 검색 방식의 결과를 더 선호했는지 계산합니다.

Team Draft Interleaving은 이름처럼 두 팀이 번갈아 선수를 뽑는 방식으로 이해할 수 있습니다.

• A 검색기가 문서 하나를 선택
• B 검색기가 문서 하나를 선택
• 다시 A가 선택
• 다시 B가 선택

사용자가 클릭한 문서가 어느 검색기에서 선택된 문서인지 점수를 부여합니다.

인터리빙은 언제 유용할까요?

인터리빙은 두 검색 순위의 작은 차이를 비교할 때 유용할 수 있습니다.

A/B 테스트에서는 서로 다른 사용자가 서로 다른 결과를 봅니다. 사용자마다 관심과 행동이 달라 비교에 많은 데이터가 필요할 수 있습니다.

 

인터리빙에서는 한 사용자가 두 검색기의 결과가 섞인 목록을 보므로 같은 질문과 같은 사용자 안에서 두 검색기를 비교할 수 있습니다.

 

다음과 같은 실험에 사용할 수 있습니다.

• BM25와 벡터 검색 순위 비교
• 기존 Reranker와 새 Reranker 비교
• 서로 다른 하이브리드 검색 가중치 비교
• 검색 후보 수 설정 비교
• 문서 최신성 점수 적용 전후 비교

다만 사용자가 검색 문서 목록을 실제로 보고 클릭할 수 있어야 합니다.

RAG가 최종 답변 하나만 보여주고 검색 결과를 숨긴다면 일반적인 인터리빙을 바로 적용하기 어렵습니다.

인터리빙은 완성된 RAG 답변 두 개를 섞는 방법이 아니라, 두 검색기가 만든 문서 순위를 같은 사용자 행동으로 비교하는 방법에 가깝습니다.

 

RAG에서 인터리빙을 사용하려면 다음과 같은 화면이 필요할 수 있습니다.

• 답변 아래에 검색된 출처 목록을 보여줌
• 사용자가 출처를 열어볼 수 있음
• 어떤 검색기가 선택한 문서인지 내부적으로 기록함
• 목록 위치에 따른 클릭 편향을 줄이도록 섞음

생성된 답변은 나란히 비교할 수 있습니다

최종 답변 두 개를 비교하고 싶다면 인터리빙보다 Side-by-Side 비교가 더 자연스러울 수 있습니다. 같은 질문에 대해 A와 B 답변을 모두 만든 뒤 사용자나 평가자에게 나란히 보여줍니다.

어떤 답변이 질문을 해결하는 데 더 도움이 되었나요?

 

선택지는 다음과 같이 구성할 수 있습니다.

• 왼쪽 답변이 더 좋음
• 오른쪽 답변이 더 좋음
• 비슷함
• 둘 다 좋지 않음

위치에 따른 영향을 줄이기 위해 A와 B의 좌우 순서를 무작위로 바꿉니다. 평가자는 어떤 모델이나 설정이 만든 답변인지 알지 못하게 하는 편이 좋습니다.

 

비교 기준도 함께 안내할 수 있습니다.

• 정확성
• 완전성
• 이해하기 쉬운 정도
• 근거의 명확성
• 불필요한 내용의 양
• 실제 업무에 도움이 되는 정도

Side-by-Side 평가는 사용자에게 두 답변을 모두 읽게 하므로 일반 서비스의 모든 요청에 적용하기에는 부담이 큽니다.

일부 사용자나 내부 평가자를 대상으로 제한적으로 사용할 수 있습니다.

Shadow Test부터 시작할 수 있습니다

새로운 RAG 설정을 사용자에게 바로 보여주기 부담스럽다면 Shadow Test를 사용할 수 있습니다.

사용자는 기존 설정 A의 답변만 받습니다.

동시에 뒤에서는 같은 질문을 새로운 설정 B에도 실행합니다.

• 사용자에게 표시: A 답변
• 내부 기록: A 답변과 B 답변
• 비교 대상: 검색 결과, 답변 품질, 응답 시간과 비용

Shadow Test의 장점은 새로운 설정이 사용자 경험에 영향을 주지 않는다는 것입니다.

운영 환경의 실제 질문으로 B를 검증할 수 있습니다.

 

다만 사용자가 B의 답변을 보지 않기 때문에 다음 지표는 측정할 수 없습니다.

• B 답변에 대한 좋아요와 싫어요
• B 사용 후 재질문
• B 사용 후 업무 완료
• B 답변의 실제 사용자 만족도

Shadow Test는 온라인 트래픽을 사용하지만 사용자 행동을 직접 비교하는 온라인 실험은 아닙니다.

주로 배포 전 안정성을 확인하는 단계입니다.

작은 사용자부터 배포할 수 있습니다

Shadow Test에서 문제가 없다면 일부 사용자에게만 새 설정을 보여줄 수 있습니다. 이를 Canary Release라고 부르기도 합니다.

 

예를 들어 다음처럼 확대할 수 있습니다.

• 내부 사용자
• 전체 사용자의 1%
• 전체 사용자의 5%
• 전체 사용자의 20%
• 전체 사용자

각 단계에서 다음 문제가 없는지 확인합니다.

• 오류율 증가
• 응답 시간 급증
• 비용 급증
• 부정 피드백 증가
• 근거 없는 답변 증가
• 특정 사용자 그룹의 성능 저하

위험한 문제가 발견되면 이전 설정으로 되돌립니다.

현실적인 실험 순서

새로운 검색 설정을 배포할 때 다음 순서로 진행할 수 있습니다.

오프라인 평가

• Golden Dataset으로 검색과 답변 품질 비교
• 질문 유형별 성능 확인
• 비용과 지연 시간 측정
• 명확히 나쁜 설정 제외

Shadow Test

• 실제 사용자 질문을 새 설정에도 실행
• 오류와 지연 시간 확인
• 기존 결과와 검색 순위 비교
• 사용자에게는 기존 답변만 표시

내부 사용자 테스트

• 직원이나 베타 사용자가 새 설정 사용
• 직접 피드백과 실패 사례 수집
• 개인정보와 운영 안정성 점검

A/B 테스트

• 사용자를 무작위로 나눠 실제 행동 비교
• 핵심 지표와 보호 지표 확인
• 질문 유형과 사용자 그룹별 분석

점진적 배포

• 작은 비율부터 전체 사용자로 확대
• 배포 단계마다 지표와 Trace 확인
• 문제가 발생하면 롤백

오프라인 점수가 좋아졌다는 이유만으로 바로 전체 배포하기보다, 실제 사용자에게 노출되는 범위를 조금씩 늘리는 편이 안전합니다.

온라인 결과를 다시 평가 데이터에 반영해야 합니다

온라인 평가는 운영 상태를 확인하는 것으로 끝나지 않습니다. 실제 서비스에서 발견된 실패 질문을 오프라인 평가 데이터에 추가해야 합니다.

 

예를 들어 사용자가 다음 질문을 반복해서 실패했다고 하겠습니다.

지난달에 가입했는데 지금 해지하면 위약금이 있어?

기존 평가 데이터에는 문서 표현을 그대로 사용한 질문만 있었을 수 있습니다.

가입 후 30일 이내 해지 시 위약금이 발생하나요?

실제 사용자 표현을 Golden Dataset에 추가하면 다음 변경을 배포하기 전에 같은 문제가 다시 발생하는지 확인할 수 있습니다.

온라인에서 발견된 사례는 다음처럼 분류할 수 있습니다.

• 실제 사용자 질문
• 사용자가 기대한 행동
• 실패 원인
• 사용된 문서
• 수정된 정답
• 질문 유형
• 중요도
• 관련 Trace ID

이렇게 하면 평가 과정이 순환합니다.

• 오프라인 평가로 후보 설정을 검증
• 온라인 실험으로 실제 사용자 반응 확인
• 실패 Trace 분석
• 실패 질문을 평가 데이터에 추가
• 개선된 설정을 다시 오프라인 평가

좋은 온라인 평가는 운영 결과를 보는 데서 끝나는 것이 아니라, 다음 오프라인 평가를 더 현실적으로 만드는 과정까지 포함합니다.

대시보드에서는 무엇을 봐야 할까요?

온라인 평가 대시보드에는 모든 숫자를 한 화면에 넣기보다 목적별로 나누는 것이 좋습니다.

사용자 만족

• 긍정·부정 피드백 비율
• 피드백 참여율
• 재질문 비율
• 업무 완료율
• 상담원 전환율

사용 행동

• 답변 복사율
• 출처 클릭률
• 평균 세션 질문 수
• 같은 의도의 반복 질문
• 세션 이탈률

품질

• 답변 보류율
• 근거 없는 답변 비율
• 최신 문서 사용 비율
• 질문 유형별 실패율
• 사용자 신고 유형

속도와 안정성

• 평균 응답 시간
• p95와 p99 응답 시간
• 타임아웃 비율
• 오류율
• 재시도율

비용

• 요청당 평균 비용
• 사용자당 비용
• 모델별 비용
• 단계별 토큰 사용량
• 재시도로 발생한 비용

다음 기준으로 필터링할 수 있어야 합니다.

• 날짜
• 애플리케이션 버전
• 실험 그룹
• 모델 버전
• 프롬프트 버전
• 질문 유형
• 사용자 언어
• 기기 유형
• 신규 사용자와 기존 사용자

자주 하는 실수

Recall이 높아졌으니 성공했다고 판단합니다

Recall은 정답 문서를 찾는 능력을 보여줍니다. 사용자가 답변을 빠르게 이해하고 실제 업무를 완료했는지는 알려주지 않습니다.

온라인 지표와 함께 확인해야 합니다.

클릭률 하나로 만족도를 판단합니다

클릭은 관심, 검증, 불신과 추가 탐색 등 여러 의미를 가질 수 있습니다. 재질문, 피드백과 업무 완료 같은 신호를 함께 봐야 합니다.

클릭이 없으면 실패라고 판단합니다

답변 자체로 충분했다면 클릭하지 않는 것이 정상입니다. 사용자의 목표와 화면 구조를 고려해야 합니다.

피드백을 남긴 사용자만 분석합니다

피드백 참여율이 낮다면 일부 적극적인 사용자만 반영될 수 있습니다. 행동 신호와 함께 분석해야 합니다.

재질문을 모두 실패로 처리합니다

새로운 내용을 묻는 자연스러운 후속 질문도 있습니다.

반복, 수정 요청과 주제 확장을 구분해야 합니다.

핵심 지표를 정하지 않습니다

여러 지표 중 좋아진 값만 골라 성공이라고 말할 수 있습니다.

실험 전에 핵심 지표와 보호 지표를 정해야 합니다.

여러 설정을 동시에 변경합니다

Reranker, 청크 크기, 프롬프트와 모델을 함께 바꾸면 무엇이 결과를 만들었는지 알 수 없습니다.

가능한 한 하나의 핵심 변경만 비교해야 합니다.

사용자를 무작위로 나누지 않습니다

특정 사용자만 새 기능을 선택하게 하면 두 그룹의 특성이 달라질 수 있습니다. 무작위 배정과 일관된 그룹 유지가 필요합니다.

실험 결과를 너무 일찍 확정합니다

사용자 수가 적으면 결과가 우연히 흔들릴 수 있습니다.

실험 전에 표본 수와 종료 기준을 정해야 합니다.

평균만 확인합니다

전체 평균은 좋아졌지만 중요한 질문 유형이나 특정 사용자 그룹은 나빠질 수 있습니다.

질문과 사용자 특성별로 나눠봐야 합니다.

속도와 비용을 무시합니다

정확도가 조금 높아졌지만 응답 시간이 두 배가 되거나 비용이 지나치게 증가할 수 있습니다.

사용자 경험과 운영 가능성을 함께 봐야 합니다.

행동 데이터를 Trace와 연결하지 않습니다

부정 피드백이 발생해도 어떤 검색과 답변 과정에서 만들어졌는지 알 수 없습니다.

Trace ID, 실험 그룹과 버전을 함께 저장해야 합니다.

중간 정리

오프라인 평가와 온라인 평가의 역할을 정리하면 다음과 같습니다.

 

구분	확인하는 질문
오프라인 검색 평가	정답 문서를 잘 찾았는가
오프라인 답변 평가	정답에 맞고 근거에 충실한가
온라인 행동 평가	사용자가 답변 이후 어떻게 행동했는가
온라인 실험	새 설정이 실제 사용자 경험을 개선했는가
Tracing	해당 행동이 어떤 검색과 답변에서 발생했는가

 

온라인 평가에서 확인할 수 있는 주요 신호는 다음과 같습니다.

• 긍정·부정 피드백
• 피드백 참여율
• 재질문 비율
• 답변 복사율
• 출처 클릭률
• 업무 완료율
• 상담원 전환율
• 답변 보류율
• 이탈률
• 응답 시간
• 요청당 비용

각 신호는 여러 의미로 해석될 수 있으므로 하나의 지표만 보고 만족도를 판단하면 안 됩니다. A/B 테스트를 진행할 때는 다음 원칙이 중요합니다.

• 실험 가설을 먼저 작성합니다.
• 핵심 지표와 보호 지표를 정합니다.
• 사용자를 무작위로 나눕니다.
• 같은 사용자는 같은 그룹을 유지합니다.
• 실제 노출 이벤트를 기록합니다.
• 한 번에 하나의 핵심 요소를 변경합니다.
• 최소 표본 수와 종료 기준을 미리 정합니다.
• 전체 평균과 사용자·질문 유형별 결과를 함께 봅니다.
• 품질뿐 아니라 지연 시간과 비용도 확인합니다.

마치며

Recall이 높아지면 정답 문서가 검색 결과에 들어올 가능성은 커집니다. 하지만 사용자가 원하는 것은 정답 문서가 검색되었다는 사실 자체가 아닙니다. 그 문서를 바탕으로 필요한 답을 빠르고 이해하기 쉬운 형태로 얻고, 실제 문제를 해결하는 것입니다.

검색 Recall이 높아졌더라도 다음과 같은 문제가 생길 수 있습니다.

• 후보 문서가 많아져 답변이 느려짐
• 비슷한 문서가 함께 전달되어 답변이 장황해짐
• 오래된 문서와 최신 문서가 섞임
• 사용자가 핵심 내용을 찾기 어려움
• 처리 비용이 크게 증가함
• 단순한 질문에도 복잡한 검색 과정이 적용됨

그래서 오프라인 지표만으로 최종 배포 여부를 결정하면 안 됩니다. 실제 사용자에게 새 설정을 노출하고 다음 행동을 확인해야 합니다.

• 같은 질문을 다시 했는가
• 답변을 복사하거나 출처를 확인했는가
• 목표 업무를 완료했는가
• 상담원에게 다시 문의했는가
• 답변에 긍정적 또는 부정적 평가를 남겼는가
• 답변을 받기 위해 얼마나 기다렸는가

다만 행동 신호 하나만으로 만족도를 판단해서도 안 됩니다. 출처 클릭은 답변에 대한 관심일 수도 있고 불신일 수도 있습니다. 답변 후 이탈은 문제 해결일 수도 있고 서비스 포기일 수도 있습니다. 복사는 실제 활용일 수도 있고 오류 신고를 위한 행동일 수도 있습니다.

사용자 행동은 정답표가 아니라, 사용자가 어떤 경험을 했는지 추정하기 위한 여러 단서입니다.

 

따라서 서비스 목표에 연결된 핵심 지표를 정하고 품질, 속도, 비용을 지키기 위한 보호 지표를 함께 운영해야 합니다.

 

새로운 설정은 오프라인 평가, Shadow Test, 소규모 배포와 A/B 테스트를 거쳐 점진적으로 적용하는 편이 안전합니다. 검색 순위 자체를 비교하려면 인터리빙을 활용할 수 있고, 완성된 두 답변을 비교하려면 나란히 보여주는 선호도 평가를 사용할 수 있습니다.

온라인 평가 결과는 다시 오프라인 평가 데이터로 돌아가야 합니다.

 

사용자가 반복해서 질문한 사례, 부정 피드백이 발생한 질문과 상담원에게 넘어간 질문을 Golden Dataset에 추가하면 다음 변경을 배포하기 전에 같은 실패를 확인할 수 있습니다.

 

결국 좋은 RAG 평가 과정은 한 번의 점수 계산으로 끝나지 않습니다.

오프라인 평가로 성능을 예측하고, 온라인 평가로 실제 경험을 확인하며, 운영에서 발견한 실패를 다시 평가 데이터에 반영하는 반복 과정입니다.

 

Recall이 높아졌다는 것은 좋은 출발점입니다. 하지만 사용자가 실제로 만족했는지는 사용자가 RAG를 이용해 원하는 일을 더 빠르고 정확하게 끝냈는지까지 확인해야 알 수 있습니다.

참고 자료

• Google Research - Good Abandonment in Mobile and PC Internet Search
• Google Research - Incorporating Clicks, Attention and Satisfaction into a Search Engine Result Page Evaluation Model
• Google Research - Evaluating Web Search Using Task Completion Time
• Google Research - Overlapping Experiment Infrastructure
• Microsoft Learn - Azure App Configuration의 실험
• Microsoft Learn - 실험 키 용어
• Microsoft Research - Optimized Interleaving for Online Retrieval Evaluation
• Large-scale Validation and Analysis of Interleaved Search Evaluation
• LangSmith 공식 문서 - Log User Feedback
• Evaluation of Retrieval-Augmented Generation: A Survey