요약
- 문제: 실시간 금융 정보 RAG에서 retrieval을 “잘했다”는 것을 사람이 매번 판단하기 어려웠다.
- 접근: baseline query와 proposed query의 검색 결과를 LLM-as-a-Judge로 비교하는 자동 평가 파이프라인을 만들었다.
- 배운 점: LLM judge도 순서에 따라 판단이 흔들릴 수 있으므로, retrieval 평가에는 judge 자체의 신뢰도 검증이 같이 필요하다.
상황
학부 연구생 프로그램에서 실시간 금융 정보 RAG의 검색 품질을 평가하는 파이프라인을 만들었다. 목표는 단순했다. 같은 금융 기사 데이터에 대해 baseline query와 proposed query를 만들고, 어떤 쿼리가 더 유용한 검색 결과를 가져오는지 자동으로 비교하고 싶었다.
기존에 했던 이미지 분류나 백엔드 성능 개선은 상대적으로 평가 기준이 명확했다. 정확도를 올리거나, latency를 낮추거나, 에러를 줄이면 된다. 하지만 RAG retrieval은 훨씬 애매했다.
검색 결과가 “좋다”는 것은 단순히 문서가 많이 나왔다는 뜻이 아니다. 질문에 답하는 데 필요한 근거가 있는지, 최신 금융 맥락을 반영하는지, 불필요한 문서가 섞이지 않았는지까지 봐야 한다. 게다가 나는 금융 도메인 전문가가 아니었기 때문에, 모든 결과를 직접 판정하는 방식은 확장성이 낮았다.
문제
처음 마주한 질문은 이것이었다.
RAG에서 retrieval을 잘했다는 기준은 무엇인가?
정답 문서가 미리 라벨링되어 있다면 recall이나 precision을 계산할 수 있다. 하지만 실험 상황에서는 쿼리마다 정답 문서 세트가 명확히 주어져 있지 않았다. 결국 “두 검색 결과 중 어떤 쪽이 더 쓸 만한가”를 비교해야 했다.
그래서 LLM을 심판으로 세웠다. 여기서 중요한 점은 모델을 파인튜닝한 것이 아니라, 평가 기준과 출력 형식을 프롬프트로 설계해 LLM judge처럼 사용했다는 점이다. Gemini API 공식 문서 기준으로도 Gemini API 직접 fine-tuning은 현재 지원 모델이 없으며, tuning은 Vertex AI 쪽 지원으로 구분된다. 그래서 이 글에서는 “파인튜닝한 평가자”가 아니라 “프롬프트 기반 LLM judge”라고 부르는 것이 더 정확하다.
평가 파이프라인
실험 파이프라인은 다음처럼 구성했다.
- 금융 기사 텍스트 데이터를 로드한다.
- 같은 입력에서 baseline query와 proposed query를 만든다.
- 두 쿼리로 각각 검색 결과를 가져온다.
- LLM judge가 두 검색 결과를 비교한다.
- 동일한 쌍을 A/B, B/A 순서로 한 번씩 평가한다.
- 두 평가가 일관될 때만 승패로 인정한다.
초기 proposed query는 단순한 키워드 검색보다 역할 부여, 단계적 사고, 금융 맥락을 포함하도록 설계했다. 기대는 명확했다. 프롬프트 기법을 적용한 쿼리가 단순 쿼리보다 더 유용한 검색 결과를 가져올 것이라고 봤다.
첫 결과
초기 judge 결과만 보면 proposed query가 어느 정도 우위였다.
| Decision | Count | Ratio |
|---|---|---|
| Proposed win | 38 | 59.4% |
| Baseline win | 25 | 39.1% |
| Tie | 1 | 1.6% |
처음에는 이 결과를 보고 “proposed query가 baseline보다 낫다”고 말할 수 있을 것 같았다. 하지만 곧 더 중요한 문제가 보였다.
심판이 정말 공정한가?
위치 편향 실험
LLM judge가 두 결과를 비교할 때, 같은 두 답변이라도 어느 쪽을 먼저 보여주느냐에 따라 판단이 달라질 수 있다. 이를 확인하기 위해 swap test를 했다.
방법은 단순하다.
- 첫 번째 평가에서는
A vs B순서로 judge에게 보여준다. - 두 번째 평가에서는 같은 내용을
B vs A순서로 바꿔 보여준다. - 두 결과가 같은 의미의 승자를 가리키면 consistent로 본다.
- 순서를 바꿨더니 승자가 바뀌면 biased로 본다.
최종 발표자료 기준으로는 약 81%의 경우에서 위치 편향이 발생했다. 즉, 내가 만든 LLM judge는 검색 품질 평가자로 바로 믿기 어려웠다.
이 결과는 꽤 충격적이었다. RAG 평가를 자동화하려고 judge를 만들었는데, 정작 judge 자체가 불안정했다. 이 상태에서 proposed query가 이겼다고 결론내리면, 검색 전략이 좋아진 것인지 judge가 순서에 흔들린 것인지 구분할 수 없다.
원인 분석
위치 편향은 무작위로만 발생한 것이 아니었다. 두 결과의 품질 차이가 클 때보다, 두 결과가 비슷하게 좋아 보일 때 더 자주 발생했다.
이를 답변 품질 격차(answer quality gap) 문제로 볼 수 있다. A와 B의 차이가 명확하면 judge가 어느 쪽이 더 좋은지 비교적 안정적으로 판단한다. 하지만 둘 다 그럴듯하고 품질 차이가 작으면, judge는 실제 retrieval 품질보다 다음 요소에 더 흔들릴 수 있다.
- 먼저 제시된 답변
- 더 최근 정보처럼 보이는 답변
- 더 길고 구조화된 답변
- 더 자신감 있게 작성된 답변
- judge prompt의 미세한 표현 차이
이 지점에서 중요한 교훈이 나왔다. LLM-as-a-Judge는 사람 평가를 완전히 대체하는 정답 기계가 아니다. 비용이 낮고 확장 가능한 평가 도구지만, 그 판단을 그대로 신뢰하려면 안 된다.
해결한 방식
그래서 평가 파이프라인을 더 보수적으로 바꿨다.
첫 번째 규칙은 양방향 평가다. 모든 답변 쌍을 A vs B, B vs A로 두 번 평가한다. 한 번의 결과만으로 승패를 내리지 않는다.
두 번째 규칙은 일관성 기반 판단이다. 두 평가가 같은 승자를 가리킬 때만 승리로 인정한다. 예를 들어 첫 평가에서 A가 이기고, 순서를 바꾼 두 번째 평가에서도 같은 실제 답변이 이기면 그때만 A의 승리로 본다.
세 번째 규칙은 보류 처리다. 두 평가가 충돌하면 억지로 승패를 내지 않는다. 이 경우는 tie 또는 review-needed로 처리한다. 이렇게 하면 승패 수는 줄어들지만, 남은 결과의 신뢰도는 올라간다.
정리하면 최종 판단은 다음처럼 바뀐다.
| A/B result | B/A result | Final decision |
|---|---|---|
| A wins | A wins | A wins |
| B wins | B wins | B wins |
| A wins | B wins | Review needed |
| Tie | Any | Review needed |
| Any | Tie | Review needed |
이 방식은 공격적으로 많은 결론을 내리는 방식이 아니다. 대신 “judge가 흔들린 케이스를 결과에서 분리한다”는 데 의미가 있다.
배운 점
가장 큰 배움은 RAG 평가가 retrieval system만의 문제가 아니라는 점이다. 평가 시스템도 하나의 시스템이고, 그 시스템 역시 오류와 편향을 가진다.
처음에는 “어떤 query strategy가 검색을 더 잘하나”가 핵심 질문이었다. 하지만 실험을 진행하면서 질문이 바뀌었다.
이 평가자는 믿을 수 있는가?
이 질문을 거치지 않으면 LLM-as-a-Judge는 오히려 위험하다. 평가 자동화는 빠르지만, 빠르게 틀릴 수도 있기 때문이다.
그래서 RAG retrieval 평가를 설계할 때는 최소한 다음을 같이 봐야 한다.
- 검색 결과 자체의 relevance
- judge prompt의 평가 기준
- 같은 쌍에 대한 반복 평가 안정성
- 답변 순서를 바꿨을 때의 일관성
- 품질 차이가 작은 케이스를 보류하는 기준
결론
이 프로젝트에서 만든 가장 중요한 결과물은 특정 query가 몇 퍼센트 이겼다는 숫자가 아니었다. 더 중요한 것은 LLM judge를 평가 파이프라인 안에 넣을 때, 그 judge도 다시 검증해야 한다는 기준이었다.
LLM-as-a-Judge는 RAG 평가를 자동화하는 좋은 출발점이다. 하지만 그 자체로 신뢰도 보장이 되지는 않는다. 특히 pairwise comparison에서는 위치 편향이 실제 결론을 바꿀 수 있다.
앞으로 비슷한 평가 시스템을 만든다면, 나는 처음부터 swap test와 일관성 기반 판단을 기본값으로 넣을 것이다. 평가 자동화의 목표는 결론을 빨리 내는 것이 아니라, 믿을 수 없는 결론을 걸러내는 것이다.
