[기타] RAG 수작업 성능 평가에 대한 짧은 고찰

들어가며

 

최근 RAG PoC를 수행하며.. 질문에 대해 직접 평가도 수행해보고 있습니다. 자동화를 시키지 않고 직접 질문을 이해하고, 검색 결과와 생성 결과를 확인하며 평가했는데요. 평가를 하며 얻은 생각들을 정리해보고자 포스트를 작성하였습니다.
 
자동화를 하지 않은 이유는 사람이 직접 확인하고 단계마다 평가해야, 어떤 지점에서 오류가 발생하는지 구체적으로 확인하고 분석할 수 있기 때문이었습니다. 평가를 자동화한다면 어떻게 해야하는지.. 모호한 부분도 있었구요. g-eval을 쓰라고들 하지만,, 분석가라면 응당 직접 평가도 수행해야 개선점을 찾을 수 있지 않을까?? 하여 평가도 나름 진심으로 임했네요. (물론 문제 수가 너무 많다면 LLM에게 시켜야겠지만요ㅠㅠ)

 

출처: pixabay

 
 

평가 항목과 내용

 

수작업으로 하는 성능 평가에서 확인한 항목은 검색, 생성, 관련 문서 유무입니다. 
 
검색은 문서에 있는 내용을 질의에 맞게 잘 검색했는지,
생성은 검색된 내용을 갖고 질의에 맞는 답변을 생성하였는지,
관련 문서 유무는 우리가 검색할 대상에 질의에 맞는 문서가 있는지 없는지 입니다. 
 
아래와 같이 경우의 수를 나눌 수 있습니다. 평가의 편의성을 위해 0 또는 1로 나누었습니다. 0은 실패 또는 없다는 것이고 1은 성공 또는 있다는 뜻입니다.
 

no.	검색	생성	관련 문서 유무
1	1	1
2	1	0
3	0	1	1
4	0	1	0
5	0	0	1
6	0	0	0

 

검색 O & 생성 O

 
정답입니다. RAG가 역할을 너무 잘 수행하여 질의에 맞는 내용도 찾아오고, 검색한 결과로 질의에 맞게 답변도 생성한 경우입니다. 검색 알고리즘도 잘 동작했고, 생성하는 LLM도 제 몫을 다했습니다.

 
 

검색 O & 생성 X

 
문서 상에서 관련 내용을 잘 찾았으나, 질의에 맞는 답변을 생성하지 못한 경우입니다. 질의에 맞는 답변을 생성하지 못하는 경우의 수는 매우 많은데요.
 
간단하게만 제가 본 사례들만 몇 가지 언급해보자면,
 
1) 숫자를 이해하지 못하는 경우: 크기 차이를 비교하지 못하거나 엉뚱한 계산을 합니다
 
2) 요점을 파악하지 못하는 경우: "보상 금액이 얼마인가요"라고 물었지만 "보상 받을 수 있습니다" 수준 정도로만 답변하기도 합니다
 
3) 2가지 이상을 질문했는데 일부만 답하는 경우: "보상 금액과 조건을 알려줘"라고 물었지만 {보상 금액}에만 답변하기도 합니다. 만약에 생성을 단순하게 O, X로 채점하지 않고 5점 척도로 평가한다면 부분 점수는 받을 수 있겠네요.
 
4) 거짓 정보를 제공하는 경우: 가장 문제가 될 수 있는 경우입니다. RAG 사용자는 답변의 거짓 유무를 판단하기 어렵기 때문에, 잘못된 정보를 제공한다면 사용자에게 예측할 수 없는 피해와 법적 문제를 일으킬 수 있습니다.

RAG의 검색 성능은 전체 테스트 질의 중 2.1 + 2.2의 비율로 얘기할 수 있겠습니다.
 
 

검색 X & 생성 O & 문서 O

 
운이 좋게도 LLM이 이미 알고 있는 내용으로 대답했거나, 답변을 찾지 못했다고 솔직하게 고백하는 경우입니다.
 
검색한 결과에서 답변을 찾지 못했다고 답변하는 경우, 검색을 올바르게 하지 못했으니 답변의 내용만 보았을 때 생성 측면에서는 문제가 없습니다. 적어도 이상한 말을 하지는 않았으니까요. 
 
검색을 하지 못하는 경우의 수도 다양한데, 제가 본 사례들을 일부 언급해보자면요,
 
1) 키워드 부재: 질의에 언급되는 키워드가 문서에는 없을 수 있습니다. 이 경우는 특정 키워드가 들어오면 문서에서 사용하는 용어로 대체해야 합니다. 서비스를 사용하는 사용자들이 일상적으로 사용하는 단어와 문서가 너무 특수하여(법률, 의료 등) 그 안에서 사용되는 단어 사이에 간극이 있을 때 필요합니다. 예를 들어 "암(cancer)"이라는 키워드는 전문 의학용어인 "악성신생물"로 대체하는 것이죠. 
 
2) 빈번한 키워드 출현: 질의에서 언급된 키워드가 문서에 너무 자주 등장할 수 있습니다. 너무 빈번하게 등장하는 키워드는 중요도를 낮출 수 있는 검색 알고리즘을 사용해야 합니다. 
 
3) 청크 길이: 청크가 너무 짧아서 답변에 참고해야 하는 내용을 모두 담지 못할 수 있습니다. 그렇다면 그 참고해야 하는 내용이 검색되어야 하는데, 다른 청크들이 더 유사도가 높게 나와서 순위가 밀려 결국 서비스하는 화면에는 제공되지 않을 수 있습니다. 임베딩 모델과 LLM의 토큰 수를 고려하여 적당한 길이를 선정해야 합니다.
 
4) 질문의 모호성 혹은 복잡성: 질문이 너무 모호하다면 적절하게 답변하지 못할 수 있습니다. 질문이 너무 복잡하다면 Multi query나 Multi turn 등 다양한 검색 기술을 적용해 고도화해야 그나마 검색이 될 수 있습니다. 다만 검색을 위해 다른 복잡한 기술이 적용된다면 속도가 느려질 수 있으니 허용 가능한 수준을 생각해봐야 합니다.

다만 질의와 관련된 문서가 있는 것이 확인되었으니, DB 및 서비스에 문서를 추가한다면 이후에 검색될 가능성도 있습니다.
 
 

검색 X & 생성 O & 문서 X

 
2.3과 마찬가지로 역시 답변 자체는 옳은 경우입니다. 다만, 질문에 답변할 수 있는 내용이 현재 시점에 그 어떤 문서에도 존재하지 않기에, 문서가 새롭게 만들어지지 않는 한 검색은 절대로 불가능합니다. 종합적으로 성능을 채점한다고 한다면 이 경우 또한 결과적으로 맞은 경우로 볼 수도 있습니다. 관련된 문서는 구축한 데이터 밖 그 어느 곳에서 찾아봐도 없으니, 결국 답변을 내지 못한 것이 최선이기 때문입니다.
RAG의 생성 성능은 전체 테스트 질의 중 2.1 + 2.3 + 2.4의 비율이라 할 수 있겠습니다.
 
 

검색 X & 생성 X & 문서 O

 
올바르지 않은 검색 결과로 엉뚱한 답변을 생성한 경우입니다. 다만, 질문에 대한 문서가 우리가 구축한 DB에만 없을 뿐, 그 밖에는 존재하는 상황입니다. 이를 추가한다면 검색될 가능성은 있습니다. 정기적인 문서 업데이트, 충분한 데이터 수집이 바탕이 되어야 검색이 올바르게 될 수 있겠습니다.
 
 

검색 X & 생성 X & 문서 X

 
2.5와 마찬가지로 올바르지 않은 검색 결과로 엉뚱한 답변을 생성하였으나, 질문에 해당하는 내용이 그 어디에도 존재하지 않는 경우입니다. 문서가 만들어지지 않는 한 검색, 생성 모두 불가합니다. 예를 들자면.. "이번주 로또 1등 번호와 세계 1짱이 되는 방법과 지구과 멸망하지 않는 방법" 등을 한번에 담은 문서는 없겠죠..?

 
 
 

마치며

 

본 포스트에서는 개인적으로 RAG 과제에서 직접 성능을 평가하며 경험한 기준과 사례를 간단하게 다뤄보았습니다.
 
이분법으로 검색/생성/문서 유무를 나누었지만 좀 더 복잡하게 점수를 매기는 방법도 매우 많습니다. 검색은 등장 여부가 아니라 순위까지 고려해 채점할 수도 있고(NDCG, mAP, MRR etc), 생성도 위에서 언급한 것처럼 어떤 기준을 정의하여 순서 척도를 갖고 채점할 수도 있습니다. 각 척도의 기준은 평가자들 사이에서 잘 합의되고 공유되어야 하며, 평가할 질의가 너무 많다면 LLM을 시켜 평가하도록 할 수도 있습니다. 각 정의가 명확하고, few-shots도 주어 더 잘 이해할 수 있도록 하고, 그 평가 결과를 믿을 수 있다면 말이죠..
 
수작업 채점은 지난한 과정이지만 분석가가 이 과정을 거쳐야 이후 RAG를 고도화할 수 있는 방안이 구체적으로 나올 수 있는 것 같습니다. 왜 이 서비스에서 질의를 이해하기 어려워했는지, 어느 영역에서 생성을 못했는지 등을 확인해야 그 다음 실험 전략을 세울 수 있겠죠. 인내심을 갖고 여러 방면에서 고민하면 점점 나아질 것이라고(서비스도 나도).. 기대합니다..🙏🙏