실무자가 작성한 RAG의 정답 데이터는 '문서 외'를 포함한다: 지우지 않고 나누어 측정하는 평가 방법 설계

서론

안녕하세요, 요코하마 은행 애자일 개발팀의 tonten입니다.

지난 글에서는 AI 구동 개발을 위한 하네스를 갖추고 조회 업무용 AI 챗 서비스를 재구축한 이야기를 했습니다. 이번에는 그 서비스에 내장된 RAG의 정확도 평가에 대한 이야기입니다.

당행 내부 사무 절차 문서(이하 '문서')를 검색하여, LLM이 질문에 답변하는 RAG를 만들고 있습니다. 정확도를 측정하기 위해 업무 부문에 '질문과 모범 답안'을 작성해 달라고 요청했습니다.

그런데 그 모범 답안을 문서 원문과 대조해 보니, 하나의 모범 답안 안에 문서에 적힌 내용과 문서 어디에도 쓰여 있지 않은 내용이 섞여 있었습니다. 이는 업무상의 지식이나 다른 규정에 기반한 판단입니다.

この記事에서 전하고 싶은 것은 다음 세 가지입니다.

• 실무자가 작성한 정답은 검색 대상 문서의 외부 지식을 포함한다. 이것은 정답 데이터의 오류가 아니라, '문서가 실무의 모든 것을 담고 있지 않다'는 사실의 표출입니다.
• 따라서, 문서 외의 부분을 지우지 않고 남겨두고, 정답을 요소별로 나누어 측정합니다. 요소별로 '문서에 있는지', '검색으로 가져올 수 있었는지', '답변에 적을 수 있었는지'를 확인하면, 정확도가 부족한 원인이 검색, 답변, 문서 중 어디에 있는지를 분리할 수 있습니다. 저희의 경우, 검색 설정으로 복구 가능한 부분은 10%도 되지 않았고, 절반은 답변 측의 누락이었으며, 나머지는 문서 측이었습니다.
• 그럼에도 불구하고, 제품의 답변 방식과 다른 정답 요소는 수정합니다. 수정할 때는 기준(물잣대) 수정과 시스템 개선을 보고서에 섞지 않습니다.

1. 우선 전제: RAG의 정확도는 어떻게 측정하는가

RAG 평가를 처음 접하는 분들을 위해, 이 글에서 사용할 용어를 먼저 설명합니다. 알고 계신 분은 2장으로 넘어가 주세요.

RAG는 '검색'과 '답변 생성'의 2단계

RAG(Retrieval-Augmented Generation)는 질문과 관련된 문서를 검색으로 가져와, 그것을 LLM에게 읽히고 답변을 작성하게 하는 메커니즘입니다.

정확도가 낮을 때, 원인이 '검색에서 필요한 문서가 가져와지지 않은 것'인지, 아니면 '가져왔음에도 답변에 적지 못한 것'인지에 따라 수정할 곳이 완전히 다릅니다. 따라서 많은 평가에서는 2단계를 나누어 측정합니다.

정답 데이터 (골드셋)

정확도를 자동으로 측정하려면, '이 질문에는 이렇게 답하는 것이 정답이다'라는 데이터가 필요합니다. 이것을 정답 데이터 또는 골드셋(Gold Set)이라고 부릅니다.

자주 사용되는 두 가지 지표

정답을 '요소'(답변에 포함되어야 할 사실이나 조건 하나하나)로 나누고, 요소가 얼마나 포함되어 있는지를 세는 것이 흔히 사용되는 측정 방식입니다. 오픈소스 평가 라이브러리 Ragas에도 같은 개념의 지표가 있습니다.

요소가 포함되었는지 판정하는 데는 LLM을 채점관(LLM-as-a-Judge)으로 사용합니다.

흔한 정답 데이터 작성 방식과 그 전제

정답 데이터는 평가자가 검색 대상 문서를 읽고, 거기서 질문과 답을 만드는 경우가 많습니다. 이 작성 방식에서는 답변이 반드시 문서 안에 있습니다. 문서에 답변이 없는 질문을 평가에 넣고 싶을 때는, 질문 단위로 '답변 불가'라는 라벨을 붙여두는 것을 권장하는 글이 자주 보입니다.

이 글은, 이러한 전제가 무너졌을 때의 이야기입니다.

2. 업무 부문에 정답을 작성하게 했더니 무슨 일이 일어났나

저희는 실제 행원들로부터 접수된 질문에 대해, 업무 부문이 모범 답안을 붙인 데이터를 사용했습니다. 행원이 실제로 무엇을 문의하는지에 맞추고 싶었기 때문입니다.

처음 자동 채점 결과에서, 문서에 답변이 있어야 할 질문임에도 절반 정도만 정답을 커버하고 있는 결과가 무시할 수 있는 비율로 나왔습니다. 검색 로그를 보니, 관계없는 문서를 섞어 놓은 흔적은 없었습니다. 그래서 점수가 낮은 질문의 모범 답안을, 문서 원문과 한 문장씩 대조해 보았습니다.

자세히 확인한 6건은 모든 모범 답안에 문서에 쓰여 있지 않은 내용이 섞여 있었습니다. 전부가 문서 출처의 모범 답안도, 전부가 문서 외부의 모범 답안도 아니었습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

이것은 누구의 실수도 아니다

담당자는 단순히 문서를 넘어, 관련 규정이나 통지, 업무상의 지식을 종합하여 평가 시점에서 타당하다고 판단한 답변을 작성했습니다. 실무에서는 문서・법령・통지・업무상 지식을 조합하여 판단하는 것이 일반적이며, '문서에 적힌 내용만으로 답해주세요'라고 요청하지 않았습니다. 설사 요청했더라도, 어느 부분이 문서에서 유래했는지 구분하며 작성하는 것은 실무자에게 큰 부담입니다.

모범 답변은 '실무상의 정답'이었지, '문서로부터 도출 가능한 정답'이 아니었습니다. 평가의 전제였던 정답의 의미와 업무 부서가 작성한 정답의 의미가 어긋났던 것입니다.

3. 문서 외 부분을 지우지 않는 이유

가장 먼저 떠오르는 생각은 '문서에 적힌 부분만으로 정답을 다시 만들어달라'는 것이었습니다. 하지만 이는 채택되지 않았습니다.

그래서 문서 외의 부분을 정답으로 남겨두고, 어떤 요소가 문서 외인지 평가할 때마다 판별하기로 했습니다.

남긴다고 해서 RAG의 정확도에 문서 부족분을 섞어서 측정하는 것은 아닙니다. 다음 장에서 설명하듯이 요소별로 '검색으로 가져왔는지', '문서에 있는지'를 판단하여 분리할 수 있기 때문에, 검색/답변 측면의 정확도와 문서 측면의 부족분은 따로 읽을 수 있습니다. 지표 정의는 Ragas와 동일합니다. 바뀐 점은 요소 구분 방식을 고정했다는 것과, 가져올 수 없었던 요소에 판정을 하나 추가했다는 것입니다.

4. 정답을 요소로 나누고, 요소별로 3가지 판별하기

이 메커니즘은 두 가지 변경 사항으로 구성되어 있습니다.

정답을 요소로 분할하고 고정하기

모범 답변을 LLM으로 요소 단위로 나누고, 그 결과를 저장하여 고정합니다. 채점할 때마다 다시 나누면, LLM의 구분 방식 변화가 이전/이후 비교에 섞여 들어갈 수 있기 때문입니다. 세분화된 정도(granularity)는 '하나의 사실이나 조건이 하나의 요소'이며, 298개의 질문을 분할하면 1,093개의 요소가 되어, 질문당 평균 3.7개 요소(1~8개 요소)가 되었습니다.

질문 단위의 레이블(답변 가능/불가능)로는 이 '앞부분은 가져왔고 뒷부분은 가져오지 못하는' 상황을 표현할 수 없습니다. 요소 단위로 바꾼 이유는 하나의 모범 답변 안에 여러 것이 섞여 있기 때문입니다.

'문서에 있는지 여부'는 평가할 때마다 검색으로 확인하기

요소가 검색으로 가져와지지 않았을 때, 그것이 '찾는 방법이 잘못되었는지' 아니면 '애초에 적혀있지 않은 것인지'를 정적인 레이블이 아닌, 매번 평가할 때 판별합니다. 실제 환경과 동일한 조건에서 요소의 60% 미만만 가져온 질문에 대해서는 조건을 완화하여 다시 검색하고, 같은 채점 담당자가 대조합니다. 조건을 완화하는 것은 두 가지입니다. 첫째, 실전에서는 검색 엔진 측 점수로 탈락 처리하던 것을 제외하고, 둘째, 대조할 문서를 실제 환경에서 LLM에게 전달하는 상위 10건에서 상위 20건으로 범위를 넓힙니다. 쿼리는 실전과 동일합니다.

채점 담당자는 서로 다른 두 개의 LLM에 같은 판정을 맡겨 평균을 내고, 둘의 결과가 갈린 케이스는 결과에 기록하여 나중에 검토할 수 있도록 했습니다. 판정의 타당성은 사람이 지정한 107개의 레이블과 대조하여 보정했습니다.

완화해도 가져올 수 없는 것은 문서에 없다는 증거가 되지 못합니다. 다른 표현으로 쓰여서 놓쳤을 가능성이 남아있기 때문에, '의심'으로 취급합니다.

판정 결과는 질문별로 다음 형태로 남습니다. 요소 단위로 '실전에서 가져옴', '완화해서 가져옴', '완화해도 가져오지 못함'이 구분됩니다.

{
"id": "q-0xx",
"result_label": "문서 측의 의심",
...

부족한 부분을 수정할 장소별로 분배하기

이 두 가지를 중첩하면, 답변에 부족한 요소를 수정할 장소별로 분배할 수 있습니다. 298건으로 늘린 평가 세트에서, 문서에 답이 있다고 여겨지는 질문의 '부족한 부분'을 분배한 결과를 분기(branch)에 비율로 표시한 것이 다음 그림입니다.

검색을 개선하면 정확도가 올라갈 것이라고 생각하기 쉽지만, 검색 설정만으로 되찾아온 부분은 1할에 미치지 못했습니다. 절반은 '근거는 가지고 있지만, 조건이나 예외를 빠뜨리고 작성한' 답변 측의 문제였고, 나머지 거의 절반은 문서 자체의 문제입니다.
이러한 분류 작업이 없었다면, 검색 파라미터를 찾는 데 시간을 썼을 것이라고 생각합니다.

5. 그래도 수정해야 할 정답이 있다

문서 외의 요소는 지우지 않겠다고 했지만, 수정한 요소도 있습니다.

일부 모범 답안에는 '자세한 내용은 OO 규정집 > 결재 권한 > △△를 참고하십시오'와 같은 규정 소재 안내가 요소로 포함되어 있었습니다. 그런데 이 RAG의 답변은 출처를 본문 번호와 인용 목록으로 표시하는 구조입니다. 소재를 본문에 쓸 필요는 없으며, 쓰게 하면 검색에서 올바른 절을 끌어오지 못했을 때 잘못된 소재를 안내하게 됩니다.

즉, 이 요소는 답변이 정확하더라도 충족할 수 없는 잣대였습니다. 문서 외의 지식과는 달리, 제품의 답변 방식과 상충하는 요소입니다. 이를 제거했습니다.

• 제거한 것: 소재 안내만 있는 요소와, 소재 절 이름을 'OO은 △△에 해당한다'라고 바꿔서 표현한 것만 있는 요소
• 남긴 것: 화면 조작 경로처럼, 장소 자체가 답이 되는 요소

시스템에는 아무것도 손대지 않았는데도, 소재 안내를 많이 포함했던 질문군(25개)의 포괄률은 약 0.13 상승했습니다. 잣대의 결함이 그대로 '이 군은 정확도가 낮다'는 시각을 만들고 있었던 것입니다. 정답 측의 결함이 측정값을 왜곡하는 것은 RAG에만 국한된 이야기가 아니며, 벤치마크 MMLU에서도 약 6.5%의 문항에 오류나 미비점이 있어, 수정하여 다시 측정하면 모델 순위가 바뀐다고 보고되었습니다 (Gema et al.).

잣대의 수정과 시스템 개선을 섞지 않기

정답을 수정한 후 전체 건을 다시 측정하면, 아무것도 변경하지 않은 질문군까지도 측정의 흔들림으로 약간 움직입니다. 흔들림의 주원인은 답변을 생성하는 LLM이며, 같은 구성을 두 번 측정할 경우 질문 단위 포괄률은 표준편차로 약 0.14 정도 변동합니다. 전체 298문항 평균이라면 우연에 의해 움직이는 폭은 약 ±0.015이지만, 25개 문항 군에서는 약 ±0.05까지 넓어집니다. 저희의 경우에도 변경하지 않은 군이 0.02 정도 상승했습니다. 이를 그대로 보고하면, 개선되지 않았는데도 '상승했다'고 읽힐 수 있습니다.

그래서 정답을 수정한 질문 행만 다시 측정하여, 기준 결과를 대체하기로 했습니다. 보고서에 제시할 숫자도 이 대체된 기준으로 집계합니다. 어느 행을 언제 다시 측정했는지는 결과 파일에 기록해 둡니다. 결과를 보고 나서 편리한 것을 고르는 것이 아니라, 절차로서 미리 정해두는 것이 중요하다고 생각합니다.

6. 요약

• 실무자가 작성한 정답에는 문서 외의 지식이 요소 단위로 하나의 답변 안에 혼재한다. 이는 정답 데이터의 오류가 아니라, 문서가 실무의 모든 것을 담고 있지 못하다는 반영이다.
• 문서 외부 부분을 삭제하면, 이용자 경험과 수치가 어긋나며, 규정을 포함할지 전문 지식을 기록할지라는 정보도 사라진다.
• 정답을 요소로 분리하여 고정하고, 요소별로 '검색으로 가져올 수 있는지', '완화하면 가져올 수 있는지'를 평가할 때마다 판정하면, 부족한 부분을 검색·답변·문서에 배분할 수 있다. 저희의 경우, 검색 설정만으로 되찾을 수 있는 것은 1할 미만이었고, 답변 측과 문서 측이 대부분이었다.
• 제품의 답변 방식과 상충하는 정답 요소는 수정한다. 이때는 수정한 행만 다시 측정하고, 잣대의 수정과 시스템 개선을 보고서에서 혼합하지 않는다.

코퍼스에서 만든 질문만으로 평가하면 답은 반드시 문서 안에 있으며, 이러한 문제는 표면화되지 않습니다. 실제 질문과 실무자의 정답을 사용함으로써, 평가 결과가 'RAG의 정확도'뿐 아니라 '문서에 쓰여 있지 않은 업무 지식이 얼마나 출제되었는지'도 보여주게 되었습니다.

참고 문헌

• Ragas,