RAG 구축에 있어서 고려해야 할 점들

RAG(Retrieval-Augmented Generation)은 LLM의 성능을 간접적으로 향상시키는 기술입니다. 외부의 데이터 소스에서 관련 정보를 검색하므로써 모델의 정확성과 관련성, 최신성을 향상시킬 수 있습니다.

"컷오버"된 모델은 최신 데이터를 가지고있지 않으며, Foundation Model 자체가 General한 데이터에 대해 학습되었기때문에, 만약 특정 도메인 관련한 챗봇 혹은 LLM Driven 시스템을 구축해야 하는 경우 파인튜닝에 더불어 필수로 구축해야하는 부분이 RAG입니다.

RAG의 구현 단계

일반적으로 RAG시스템의 구축 프로세스의 경우 다음과 같은 단계를 거쳐야 합니다.

1. 데이터 저장소 및 데이터의 유형 결정

2. 데이터 준비 및 업데이트 프로세스의 설계 (파이프라인 구성이 될 수도 있습니다.)

3. 검색을 진행하고 검색된 문서에 대해 재순위화 로직의 구현 (재순위화; Re-rank의 경우 생략되는경우도 있습니다.)

데이터 저장소와 데이터의 유형 결정

데이터 저장소

RAG시스템에서 데이터 저장소는 외부의 지식(혹은 사용자의 의도에 맞도록 설계된 외부 문서)를 저장하고 검색하는 역할을 주로 하게 됩니다. 또한 이 데이터저장소의 다양한 옵션이 있으며 이 옵션의 고유한 특징과 장단점을 가지고있습니다. 다음은 AWS에서 제공하는 3가지 서비스 (Amazon Kendra, Amazon OpenSearch(Vector DB + Search Engine), VectorDB(PostgreSQL)에 대한 예시입니다.

(1) Amazon Kendra (https://aws.amazon.com/ko/kendra/)

자연어 질문에 대한 답변 자체를 찾는데 특화된 서비스이고, 해당 서비스는 GenAI(LLM)이 핫해지기 이전에도 간혹 사용되는 서비스였습니다. 추가적인 ML모델 없이 파일을 업로드 하면 자동으로 인덱싱이 되며, Source로 타사 솔루션이나 DB등을 지정할 수 있기때문에 간편하게 사용할 수 있습니다. 비용은 조금 비싼 편. RAG사용사례에 맞게 Retrieve API도 제공 됩니다. 한국은 25년 4월 현재 정식으로 사용할 수는 없으며 근처 도쿄리전에서 사용 가능합니다.

 

kendra에서 지원되는 커넥터 예시. 현재 50여개의 관리형 커넥터를 지원하고 Marketplace에 등록된 써드파티도 지원된다.

 

(2) Amazon OpenSearch (https://aws.amazon.com/ko/opensearch-service/)

개인적으로 가장 추천하는 서비스입니다. 기본적으로 SearchEngine으로 시작하기때문에 성능이 압도적입니다. 대신 비용부담이 약간 큰 편입니다.

OpenSearch는 Elasticsearch가 오픈소스에서 상용라이센스로 변경이되면서 오픈소스를 포크하여 새롭게 진행된 프로젝트입니다. 25년 4월기준 다시 Elastic이 오픈소스 라이센스로 변경되면서 포지셔닝이 애매해졌지만 강력한 서치엔진임은 틀림없습니다.

오픈서치는 기본적으로 벡터 타입의 데이터를 지원하고 유사도검색, 하이브리드 검색등을 효율적으로 수행할 수 있습니다.

개인적으로는 OpenSearch + AWS의 강력한 RBAC이 보안적 측면에서 꼼꼼한 느낌이라 프로덕션에서 활용하기 좋지 않나 싶습니다.

서버리스 기반도 사용할 수 있고 이때는 OCU라는 인덱싱 용량 단위를 활용합니다.

 

(3) 일반적인 벡터데이터베이스 (PostgreSQL RDS + pgVector등)

https://aws.amazon.com/ko/about-aws/whats-new/2024/11/amazon-rds-for-postgresql-pgvector-080/

Amazon RDS for PostgreSQL에서 pgvector 0.8.0 지원 - AWS

PostgreSQL과 같이 기본적인 RDBMS 환경에 pgVector등을 활용하여 사용하는 방법입니다.

EC2처럼 일반적인 컴퓨트머신에 설치하여 사용하는것도 좋지만, RDS라는 완전관리형 서비스가 존재하므로 이를 추천합니다.

따로 장애가 발생하고, AutoScaling을 수행하는등 유지 보수 관리측면에서의 포인트가 많이 줄어듭니다.

데이터 유형

RAG에 사용할 데이터 유형은 텍스트를 비롯하여 이미지나 비디오등 다양할 수 있습니다. 이에 따라서 적합한 벡터스토어를 선택하는것이 중요합니다. 텍스트 데이터는 오픈서치에 저장하고, 이미지 데이터는 따로 저장하여 메타데이터로 구성하고 URI를 기록하는것도 방법이 될 수 있겠습니다. 혹은 원본저장이 필요없는경우 이미지에서 의미론적인 description을 추출, 이를 저장하는 방법도 있습니다.

 

검색면에서도 생각해야 할 것들이 있는데,

1. 비벡터 : TF-IDF, BM25와 같은 전통적인 방법을 사용하여 텍스트 데이터를 인덱싱하고 검색할 것인지

2. 벡터 : 텍스트와 이미지등을 임베딩 모델 혹은 알고리즘을 통해서 변환하고 이를 저장하여 유사도 검색을 수행할 것인지

각자 장단점이 있지만 일반적으로 벡터 검색이 더 효율적이므로 벡터 검색을 사용하는것이 일반적입니다.

 

데이터 준비 및 업데이트

RAG시스템은 데이터의 품질에 크게 의존하기때문에 데이터를 준비하고 업데이트하는 프로세스를 모두 고민하고 설계를 해야합니다.

전처리 (pre-processing)

전처리 파이프라인은 개인적인 의견이지만 텍스트 데이터인지, 텍스트 외 데이터를 활용해야하는지를 먼저 결정해야합니다.

 

텍스트

텍스트의 경우 LLM 혹은 임베딩 모델이 이를 처리할 수 있는 단위로 분할하는 과정인 청킹을 진행해야하며, 데이터에 대한 데이터를 기록해야하는경우 이때 추가적으로 메타데이터를 구성해야 합니다.

 

텍스트 외 (이미지/비디오)

텍스트 외의 이미지와 비디오와 같은 데이터의 경우 크기를 조정하거나, 형식을 변환하거나 메타데이터 추가등을 수행합니다.

가장 추천하는 방식은 오브젝트스토리지와의 결합이며 AWS의 경우 S3에 원본파일을 업로드하고, 이 원본에 대한 description을 활용하거나, 도큐먼트에 텍스트 외의 데이터가 존재하는경우, 이 도큐먼트의 메타데이터에 URI를 첨부하는식으로 구성할 수 있습니다.

리랭킹 (Re-ranking, 재순위화)

재순위화 기법은 리트리버에 의해 검색된 문서의 순위를 조정하여 LLM에 context로 넘겨줄 때 더 높은 관련성 정보를 가진 문서를 제공하는데 사용합니다. 다양한 리랭킹 기법이 있으며 다음은 대표적인 기법인 TF-IDF, BM25, Hybrid, RRF의 개념과 장단점을 표로 정리하였습니다.

구분	개념	장단점
TF-IDF	단어 빈도와 역 문서 빈도를 활용하여 중요도 계산	간단하고 효율적이지만, 단어의 의미론적 관계 고려 불가
BM25	TF-IDF를 개선하여 길이와 빈도를 고려하여 순위화	정확도가 높지만, 여전히 완전한 단어의 의미론적 관계 고려 불가
Hybrid	키워드기반과 벡터기반을 결합하여 정확도를 높임	키워드 검색의 정확성 + 벡터검색의 의미론적 이해를 결합
RRF	여러 검색결과를 통합하여 최종순위 생성	서로 다른 데이터셋이나 알고리즘의 경우에도 효과적으로 결합 가능

 

이 리랭킹의 성능 측정하는 부분에 대해서는 추후 설명하겠지만 다음과 같은 지표가 활용됩니다.

• NDCG (Normalized Discounted Cumulative Gain): 검색 결과의 순위를 고려하여 정확도를 측정
• MAP (Mean Average Precision): 각 쿼리에 대한 평균 정밀도를 계산
• MRR (Mean Reciprocal Rank): 첫 번째 관련 문서의 순위를 기반으로 성능을 측정

그래서 결론적으로 뭘 고려해야하는데?

최종적으로 RAG파이프라인에 대한 워크플로우는 다음과 같습니다.

기본적인 RAG 파이프라인 워크플로우

1. 사용자의 질문을 받아서 임베딩 모델이 쿼리 벡터를 생성하고, 이 생성된 벡터를 활용하여 유사도기반으로 문서를 검색한다.

2. 검색된 문서와 유저의 질문을 다시 비교하여 재순위화한다. 이때 검색된 문서 리스트가 재정렬된다.

3. 재 정렬된 문서를 context로 LLM에 전달하고, LLM은 이 도큐먼트를 기반으로 대답을 생성한다.

 

이 부분에서 고려해야할것들은 위에서 설명하였습니다. (모델 사용에 대한 부분은 RAG문서이므로 제외한다.)

• 쿼리벡터의 생성단계에 있어서 데이터 유형을 설정하고 이를 어떻게 처리할건지에 대한 부분 (인제스쳔과 서치 둘다)
• 유사도 검색에 필요한 벡터스토어를 어떤것을 사용할건지에 대한 부분
• 재순위화에 사용되는 알고리즘과 그 장단점 (리랭킹 성능 측정부분은 따로 작성하겠다)

다시 정리하자면,

데이터 전처리가 가장 중요한데, 이때 정제한 결과물이 어떤 데이터형식이며

어떤 메타데이터를 구성해야하는지가 중요하며

벡터데이터베이스(스토어)를 어떤것을 활용할것인지

재순위화를 어떤 알고리즘을 통해 적용할것인지

 

에 대해 생각해보면 나름 기본적인것들에 대한 준비는 완료되지 않나 싶습니다. (주관적 견해가 섞여있음)

이 RAG를 기반으로 구성된 컴포넌트를 여러 기법으로 확장하면 Advanced이고 Modular이고 구성이 가능합니다.