2024.09.12 - [RAG Project] - [RAG Project] GlobalMacro QA chatbot - Embedding&Vectorstore (6)
[RAG Project] GlobalMacro QA chatbot - Embedding&Vectorstore (6)
2024.09.11 - [RAG Project] - [RAG Project] GlobalMacro QA chatbot - Data Preprocessing - GraphState (5) [RAG Project] GlobalMacro QA chatbot - Data Preprocessing - GraphState (5)2024.09.10 - [RAG Project] - [RAG Project] GlobalMacro QA chatbot - Data Prep
hibyeys.tistory.com
지난 포스팅까지 해서 데이터를 처리는 완료했다. 이번에는 여러 Retriever를 테스트하고 RAG chain을 선택해 볼 것이다.
1. Retriever, 넘어서 RAG의 성능을 어떻게 평가할 것인가?
지난 포스팅에서 데이터를 적재할 때 어떤 Retriever를 사용할지를 고려하여 데이터 저장 방식을 결정하였다.
그렇다면 각 Retriever에 맞게 QA chain을 만들었다면 각각의 chain의 성능을 어떻게 평가해서 Retriever를 선택할 수 있을까?
단순하게 같은 질문을 넣고 retriever 된 문서를 일일이 확인하고 생성된 대답을 확인할 수도 있다.
물론 이런 정성적 평가도 필요하지만 시간이 많이 소요되고 평가하는 사람의 능력도 중요하다.
그렇지만 나에게 충분한 시간이 주어지지 않기에 이번 프로젝트에서는 정량적 평가에 높은 비중을 두어 테스트할 것이다.
정량적 평가를 할 수 있는 여러 가지 라이브러리가 있지만 그중에서 나는 AutoRAG와 RASAS를 사용해 평가할 것이다.
1.1 AutoRAG
AutoRAG는 국내 스타트업 Marker AI에서 개발한 오픈소스 라이브러리이다. 아직 alpha version이지만 꽤 많은 github star를 받았다. (링크) AutoRAG의 철학은 최고의 파이프라인을 찾는것이 아닌 최적의 파이프라인을 찾는 것 이다.
각 노드를 조합해서 파이프라인을 찾는 것이 아니라, 이전 노드를 평가하여 얻은 최상의 결과를 다음노드의 입력으로 전달하는 방식이다.
각 node별로 평가해서 점진적으로 원하는 체인을 구성하는데 좋을 것 같아서 AutoRAG를 사용할 생각이다.
(AutoRAG에서 제공하는 metric이나 작동방식에 대해 더 자세히 알고 싶다면 documentation 이나 blog를 확인하세요.)
1.2 RAGAS
RAGAS 도 마찬가지로 오픈소스 라이브러리로 아마 RAG Evaluation에 가장 많이 쓰이는 라이브러리가 아닌가 싶다.
아래의 4가지 평가 지표를 통해 답변의 성능을 평가한다. 주로 QA chain을 평가할 때 사용한다.
AutoRAG를 통해 파이프라인 구성요소를 선택하고 RAGAS를 통해 파이프라인을 평가하면 좋겠다 생각하여 RAGAS를 선택하게 되었다.
(지표에 관련해서는 포스팅이 잘되어 있는 것이 많기에 생략하겠다. documentation)
1.3. Evaluation Flow
Test DataSet 준비 -> AutoRAG를 통해 전에 선택한 3가지 Retriever에 맞는 각각 파이프라인 구성 -> RAGAS를 통해 각 파이프라인을 평가 비교
2. Test
2.1 Test DataSet 준비
첫 단계부터 고통받고 있다. 자꾸 Too Many Requests를 내뱉으면서 계속 뺑뺑이 돌다가 에러가 나서 멈추는 현상이 발생했다.
RAGAS는 Test Dataset을 만들기 위해 여러 Agent들이 들어가 있어서 open ai에 요청량이 많다.
open ai는 Tier에 따라 보낼 수 있는 요청량을 정해놓았는데, Tier 1의 RPM (request per minute), RPD (request per day) 양을 넘어서는 것 같다.
처음에 그것도 모르고 패키지를 뜯어보며 num_workers도 줄여보고 chunk 된 데이터를 작은 token 범위로 잘라 넣어보고 random sampling 해서 데이터수를 조금씩 줄여가며 테스트해 보았다. 결과는 계속 오류.. (이 테스트에만 3~4 달러 정도 썼다.. 커피 한잔 안 먹는 걸로 하겠다.)
Tier의 존재를 알게 되고 과감히 $50 달러를 결제해 Tier2가 되었다. (RPM 500 -> RPM 5000)
산 넘어 산이라고 requests 에러는 해결했지만 또 다른 에러들이 기다리고 있었다.
결론적으로 말하자면 LLM 성능의 문제로 인해 에러들이 발생했다. RAGAS를 까보니 LLM prompt에 format을 강제하는 장치들이 많이 들어가 있는데, 그 구조대로 잘 생성하지 못해서 validation error 나 값이 전달이 안 돼서 score error가 나던 것이었다.
gpt-4o-mini에서 gpt-4o로 모델을 교체해 주는 것으로 에러를 해결했다.
다만 데이터셋 100개를 생성하는데 $27를 소비하였다. 돈은 돈대로 시간은 시간대로 낭비한 쓰라린 시간이었다.
2.2 Retriever Chain
다음으로 저번에 선택한 [BM25 , Multivector, ParentDocument] retriever들을 사용해 테스트할 수 있게 각각의 chain을 생성하였다. 그리고 전 단계에서 만들어둔 TestSet에서 question과 ground truth만 가져와 chain의 성능을 테스트할 데이터셋으로 다시 만들었다.
2.3 Evaluation
데이터 생성에 너무 고생해서일까. 빨리 검증하고 치워버리고 싶은 마음에 허겁지겁 코드를 돌렸다.
그런데 아래와 같이 너무 처참한 점수가 나왔다. (다른 retriever 들도 크게 다르지 않았다)
원래 점수가 이렇게 짜게 나오나라고 잠시 생각했지만 그러기에는 0점이 너무 많아서 생성한 데이터셋을 한번 들여다보았다.
역시나 데이터셋에 문제가 있었다. simple question에는 "probabilistic event를 한국어로 번역하면 무엇인가요?" 같은 이상한 질문들이 있었고, 생성된 데이터 대부분이 ground truth에 주어진 질문에 대한 답변이 없다고 적혀있었다.
3. Conclusion
Evaluation 하기 전에 chain을 만들어서 몇 가지 질문을 해보았는데 꽤 괜찮을 답변을 받아서
이대로 Evaluation 하면서 다른 Module 붙여나가면 잘될 것 같은 기대감이 있었다.
하지만 이런 결과가 나와서 많이 허탈했다. 테스트 셋 만드는데 소비한 시간과 비용이 생각났다..
(차라리 그 시간에 직접 테스트 셋을 구축했으면..)
이것도 경험이라고 생각하고 다음 step을 진행하는 수밖에 없었다.
시간이 많지 않기에 결국 질문 과정당 한두 가지에 대해서만 테스트 셋을 만들기로 결정했다.
(추후에 사용하면서 계속 데이터셋을 업데이트할 것이다.)
P.S. 직접 데이터셋 만들게 되면 아쉽지만 AutoRAG를 사용하기 힘들어진다.
이유는 일일이 Context 문서를 붙여줘야 해서 시간이 더 많이 소요되기 때문이다.
(RAGAS는 question과 ground truth만 있으면 된다.)
나중에 Data Generation 부분에 대대적인 업데이트가 있을 것이라고 하니 다음을 기약해 보자.
그래서 다음 과정에서는 chain을 사용하면서 결론에 도출하기 위한 질문 Process를 정의하고,
동시에 정성적 평가와 테스트 셋을 만들기를 진행해보겠다.